a Wi-Fi rc-car that makes use of Arduino UNO, ESP8266 and Websockets or UDP

dear community

a Wi-Fi controlled using Arduino UNO, ESP8266 RC car using Websockets or UDP

how would you decide?

i want to create an Arduino project about a Wi-Fi controlled (ESP8266) RC car using. - with a tight budget you can’t really buy everything you need at once.

what is needed:

An Arduino UNO An ESP8266 An L298N motor driver - with or without H-bridge An LF33CV 3.3V regulator An RC car Also batteries that meet your needs / much better: a power-pack

regarding the protocolls - not yet every decision is made:

  • which protocol should i use!?
  • WebSocket protocol or UDP-protocoll?

i need to figure out what else is needed to run this project with ESP8266 / NodeMCU one.

what is WebSocket Protocol?

WebSockets are a bi-directional, full-duplex, persistent connection from a web browser to a server. Once a WebSocket connection is established the connection stays open until the client or server decides to close this connection. With this open connection, the client or server can send a message at any given time to the other.

guess that i first will try out to go with the WebSocket-approach

but furthermore: well after setting up all with a WebSocket-approach i afterwards will also try controlling the car with other protocols like HTTP or UDP to see the difference, if any.

what do you think?

First of all I would say don’t use an Uno and an esp-01 module. This makes life more difficult. Choose a Wemos Mini or a nodeMCU board. This will be smaller, cheaper and easier to use.

Secondly, choose a less old-fashioned motor driver than the 298. Newer designs will work well with 3.3V circuits, be more efficient and maybe use fewer pins (which may be important when using the Wemos/nodeMCU).

An L298N motor driver - with or without H-bridge

This is a strange thing to say. I guess they are not your words. Whoever wrote them may not have as much understanding of electronics as you may imagine. The 298 is itself an h-bridge. You don’t need to add an h-bridge and you can’t not have an h-bridge.

An LF33CV 3.3V regulator

You may not need this if using a Wemos or nodeMCU, depending on the other components you plan to use.

Also batteries that meet your needs / much better: a power-pack

This also sounds strange. What is this “power-pack”, some kind of nuclear fusion device? No. It’s just another battery.

Hi, I'm new to Adruino developing, so may answer only software-related question as I have some experience developing client-server systems for PCs (including high-load).

UDP is a protocol without typical connection, but also without delivery control. If the packet will be lost - nobody cares. TCP has strong delivery control, but connection process causes some delay if the server is down or network quality is bad (low WiFi signal, xxx-torrents taking all bandwidth etc). Also TCP has some overhead (SYN, ACK...) so it is not recommended if your server should accept thousands packets simiultaneously.

Resuming. If you will decide to use TCP - you should open single connection from your PC or smartphone car control application to your Arduino car, send commands through the socket and receive replies. Do not close the connection after each command (keep-alive mode). You may use WebServer example to implement something similar to HTTP or REST protocol, or use raw tcp with your own packet format. Here you must also re-connect if connection failed or WiFi signal was lost. Common problem for Winsock is that TCP is a flow, so if you would send raw packet of 10kb and next packet of 15kb nobody guarantee the other side will not receive it splitted as 12kb+13kb, so you should use short packets or control command start and command end signatures.

UDP is much better if for the case, for example, if you will continiously (each second?) send the packets of the following format: moving direction, moving speed (or 0 to stop) and not wait for reply. Even if your packet will be lost, next will contain the same or updated instruction. Of course your car may reply and you should read such replies. Also do not try to send UDP packets of huge size since it could be blocked by some routers. I'm not sure but maybe WiFi shield will send each byte in a separate UDP packet, this is not optimal (huge overhead) but you can't change the hardware. If somebody tested it - please report eithere the length of the packet payload is 1 byte or some real size. Once I wrote a control software for Windows that queries some microcontroller connected via Ethernet (it was not Arduino, but maybe some Atmel-based, I dont know since it was a black box) and it sent replies exactly 1 byte in a packet...

hello dear mmessiah and PaulRB,

many maby thanks for the reply - great to hear from you. I am very glad.

regarding the driver-stage: An L298N motor driver - has a H-bridge . sure thing... Thanks for the reminder

regarding the protocolls - many thanks for all the ideas - to both of you - and especially to you mmessiah:

since i am quiet a beginner here - i want to recapitulate the options we have here:

There are two types of Internet Protocol (IP) traffic. They are TCP or Transmission Control Protocol and UDP or User Datagram Protocol. TCP is connection oriented – once a connection is established, data can be sent bidirectional. UDP is a simpler, connectionless Internet protocol. Multiple messages are sent as packets in chunks using UDP.

The Websocket's require to be frank - sistematically an extra overhead for an arduino and esp8266 The issue is that we need to implement (or find a library for) a webserver with HTTP and websocket support.

a side effect; All that overhead is going to be eating up the available memory leaving less for my actual car controlling code to work with.

UDP is a protocol without typical connection, but also without delivery control. I guess that the UDP is protocol of choice: - If the packet will be lost-nobody cares.

conclusino; i guess that a simple UDP setup would be best probably. That means that i can just fire off some data packets with commands for the car. With UDP there's a chance some may get lost in transit, if that's a problem then i also might make use TCP instead....i will take into consideration the options ...

with that i can keep it simple... i keep you posted



why remote control over WiFi? some simpler RF protocol would be faster

hello daer juraj, hello dear all.

many thanks dear juraj you have spelled it out: why should i use remote control over WiFi? There are way that are even easier; why shouldn ´t i take some simpler RF protocol? That would be even faster.

the RF protocol?

some recaps:

What if i am going to design a remote controlled car and one of the aims is for the controller to be a smartphone. With this i an make use of a transmitter plugged into the headphone jack (that is a Audio-Headphone-signal) which would interpret audio signals that are being sent from a certain controller-app on the mobile phone and then send an appropriate signal to the system of the rc-car.

Some musings bout the needed tasks: what has to be controlled on the RC-Car: To sumarize all, that needs to be controlled is the the mode of motion:

  • forwards/backwards-motion and the steering (i.e. turning left or right):
  • Ideally it would be able to have speed control - not just forwards and backwards.

Well my initial idea was to make usage of something like this for radio transmission: but then it would mean doing some kind of sinal transformation that looks quite annoying: in fact: i have the signal-processing that goes like this: analog -> digital and sending digital data with some kind of protocol, so then I thought of sending just the analog data but I'm not sure how that would separate the signal fo the two control-cirquits: i.e. forward/backward and right/left.

Some possible solutions: Well the socalled standard RC protocol is to transmit bursts of AM /(FM) pulses, whereas the relative positions of which are translated by the receiving side will turn into a variable-width control pulse-signal subsequently. And subsequently this signal is going to be sent to the variouls servos.Well i guess, that it should be pretty straightforward for a (let me say) smartphone app (see for example roboremo or others -the rc car app :: see https://www.roboremo.com/esp8266-wifi-rc-car.html ) to send such mentioned pulses out the headphone jack, which are then used to key a simple RF transmitter on a standard RC control frequency like xyz.

one of the main advantages: we would be able to use in the car comodity of the shelf things: we 'd use an off-the-shelf RC receiver and servos to control the car.

  • The servo-side of the game: a standard RC servo requires a control-pulse-signal that has a variable width of 1-2 ms (sometimes this may be extended to 0.5-2.5 ms) and repeats at a 20-50 Hz rate.
  • a basic RC car might have as few as two servos, note a plane might have more each of which needs its independently-controlled pulse-signal.

btw. see a rf-solution: https://www.instructables.com/id/RF-Control-System-For-RC-Vehicle-Based-On-Arduino-/

conclusio: well now we have many protocols to choose

good day dear experts

here i am back - again many many thanks dear jurai for the help!

many thanks for the reply and for your ideas - thanks for encouraging me to step ahead.

steps that have to be done:

i just have the car expect one command every second. If it does not receive one, it stops.

what do you think about this idea: i think that this is good idea - i like this idea!

regarding the connection type: i guess i can make use of the connection type that fits my existing hardware or use-case best. Once we have decided that, the search for a good connection library starts.

if i choose some [/b]roboremote or alike controlled solution:[/b]

well - if i want to go with some web-app or pc controlled thing then i should choose TCP/IP / WIFI or bluetooth ( with ESP 32)

regardingt the hardware:

firstly: I would say that i don't make use of an Uno and an esp-01 module. This makes life much more difficult. i think that i should choose a Wemos Mini D1 or a nodeMCU board. This will be smaller, cheaper and easier to use.

secondly perhaps i should choose a less old-fashioned motor driver than the 298. These will work well with 3.3V circuits, be more efficient and maybe use fewer pins (which may be important when using the Wemos/nodeMCU). What do you think about this idea.

btw regarding the use of MicroPython i have found an interesting approach here: written by david golak: https://hackaday.io/project/27444-remote-control-car-via-wifi How to build RC Car with the esp8266.

see the code https://github.com/dgolak/esp8266/blob/master/main.py

import machine
import time
class engines:

[b]see more at github[/b]

def main(E,micropython_optimize=False):
    s = socket.socket()
    ai = socket.getaddrinfo("", 80)
    addr = ai[0][-1]
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    while True:
        res = s.accept()
        if not micropython_optimize:
            client_stream = client_sock.makefile("rwb")
            client_stream = client_sock
        req = client_stream.readline()
        get = req.split()[1].decode('utf-8')
        if get == '/?action=forward':
        elif get == '/?action=left_up':
        elif get == '/?action=right_up':
        elif get == '/?action=left_down':
        elif get == '/?action=right_down':
        elif get == '/?action=backward':
        elif get == '/?action=stop':
        elif get == '/?action=led_on':
        elif get == '/?action=led_off':
        elif get == '/?action=light_on':
        elif get == '/?action=light_off':
        while True:
            h = client_stream.readline()
            if h == b"" or h == b"\r\n":
        if led.value() == 1:
            led_icon = "alarm_off.jpg"
        client_stream.write(CONTENT % (wlan.ifconfig()[0],led_icon))
        if not micropython_optimize:

see https://github.com/dgolak/esp8266/blob/master/main.py

well i guess that this is a straingthforward approach...

cf: david golak: https://hackaday.io/project/27444-remote-control-car-via-wifi How to build RC Car with the esp8266.

btw: my car has got a option of a steering axle - in other words - i have a slightly different car - than David has. But that i think does not make a big difference.. I have to change the code at some places to fit.

i will have a closer look at this.