- Mon Jul 01, 2019 3:01 am
#82960
protocol-discussion: rc-car with ESP8266: Websockets, TCP, UDP, RF: which one?
this is a protocol-discussion: a rc-car that makes use of ESP8266 and the: Websockets, TCP, UDP, RF
which one to take..?
The aim of this project is to build a transmitter and a receiver by using a cheap and easy to use component such as ESP8266,(...or alternatively Arduino UNO, Arduino Nano, and nRF24L01 transceiver.)
This project should be a good start point for beginners. One of the main questions is the question of the architecture and the protocols to choose:
note: I am a beginner in this field and would like some direction - what approach do I take that will allow me to keep the cost low (e.g. no bluetooth modules)? especially the question which protocoll i should use with the ESP8266 is a question: should i us Websockets / TCP or UDP or RF
how would you decide?
i want to create an ESP8266 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 - which materials do i need:
- an ESP8266 / (or alternatively Arduino UNO, Arduino Nano, and nRF24L01)
(well i would say - Arduino uno and esp-01 module is difficult and more expensive that choosing a Wemos Mini or a nodeMCU board. advantages; this will be smaller, cheaper and easier to use than e e)
- an L298N motor driver - H-bridge
- an LF33CV 3.3V regulator
- an RC car
- also batteries, that meet our needs
regarding the protocolls - not yet every decision is made: the protocols are thinkable: Websockets, TCP, UDP, RF
- which protocol should i use!?
- Websockets, TCP, UDP, RF - protocoll?
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 - systematically 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.
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 ...
conlusio: 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.
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 about 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, the relative positions of which are translated by the receiver into a variable-width control pulse-signal. 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 -the rc car app :: see https://www.roboremo.com/esp8266-wifi-rc-car.html )
to send pulses out the headphone jack, which are then used to key a simple RF transmitter on a standard RC control frequency.
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.
so based on the above mentioned ideas _ which protocol would you use!
this is a protocol-discussion: a rc-car that makes use of ESP8266 and the: Websockets, TCP, UDP, RF
which one to take..?
The aim of this project is to build a transmitter and a receiver by using a cheap and easy to use component such as ESP8266,(...or alternatively Arduino UNO, Arduino Nano, and nRF24L01 transceiver.)
This project should be a good start point for beginners. One of the main questions is the question of the architecture and the protocols to choose:
note: I am a beginner in this field and would like some direction - what approach do I take that will allow me to keep the cost low (e.g. no bluetooth modules)? especially the question which protocoll i should use with the ESP8266 is a question: should i us Websockets / TCP or UDP or RF
how would you decide?
i want to create an ESP8266 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 - which materials do i need:
- an ESP8266 / (or alternatively Arduino UNO, Arduino Nano, and nRF24L01)
(well i would say - Arduino uno and esp-01 module is difficult and more expensive that choosing a Wemos Mini or a nodeMCU board. advantages; this will be smaller, cheaper and easier to use than e e)
- an L298N motor driver - H-bridge
- an LF33CV 3.3V regulator
- an RC car
- also batteries, that meet our needs
regarding the protocolls - not yet every decision is made: the protocols are thinkable: Websockets, TCP, UDP, RF
- which protocol should i use!?
- Websockets, TCP, UDP, RF - protocoll?
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 - systematically 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.
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 ...
conlusio: 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.
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 about 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, the relative positions of which are translated by the receiver into a variable-width control pulse-signal. 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 -the rc car app :: see https://www.roboremo.com/esp8266-wifi-rc-car.html )
to send pulses out the headphone jack, which are then used to key a simple RF transmitter on a standard RC control frequency.
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.
so based on the above mentioned ideas _ which protocol would you use!
