rc-car and ESP8266-board: which prtocoll to stuck with
Posted: Tue Jan 29, 2019 9:34 am
good day dear experts,
this is a protocol-discussion for a project: 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 adafruit-motor-shield-v2, 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 adafruit-motor-shield-v2, and nRF24L01 transceiver.) well i would say - 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 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 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: some musings on the communication between the arduino and the servo (1-2ms 20-50Hz) and its relation to the RF data
- the servo control signals are totally separate from the RF link
- the servo control signals must be continuous
- the RF data only changes the timing of the servo control signals
so based on the above mentioned ideas _ which protocol would you use!
this is a protocol-discussion for a project: 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 adafruit-motor-shield-v2, 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 adafruit-motor-shield-v2, and nRF24L01 transceiver.) well i would say - 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 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 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: some musings on the communication between the arduino and the servo (1-2ms 20-50Hz) and its relation to the RF data
- the servo control signals are totally separate from the RF link
- the servo control signals must be continuous
- the RF data only changes the timing of the servo control signals
so based on the above mentioned ideas _ which protocol would you use!