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

[dil_bert]

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?

Quote

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?

[kicken]

Websocket's require a lot of extra overhead for an arduino.  You'd have to implement (or find a library for) a webserver with HTTP and websocket support.  All that overhead is going to be eating up your available memory leaving less for your actual car controlling code to work with.

A simple UDP setup would be best probably.  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 use TCP instead.

Keep things simple.

[dil_bert]

hello dear Kicken,

many many thanks for the quick reply - great to hear from you.

convinced : A simple UDP setup would be best probably. 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 use TCP instead. With that i can keep things simple.
with the UDP i can make use of the great ESP8266 - choosing a Wemos Mini or a nodeMCU board.

But wait: 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. what do you say?

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 so called 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-/

 

well kicken - what  would you say!?  should i use udf or rf protocol !?

love to hear from you

 

 

 

 

[kicken]

Depends I suppose on what your goal is.

If you want to make use of existing RC stuff and all that stuff is geared to work with an RF based protocol then use that.

If you want to use a smartphone / tablet / PC to control the car then WiFi would be a better fit as those devices are likely to already have a WiFi card.

I've only dabbled in Arduino/hardware and done pretty much nothing with regards to RC/RF stuff so can't really say much more than the above.