RC Auto mit ESP8266 fernsteuern: Welches Protokoll verwenden - TCP / UDP oder RF

L I V E Stammtisch ab 20:30 Uhr im Chat
  • guten Abend community,

    heute mal wieder etwas Neues - ich will eine ferngesteuertes Auto bauen - und hierzu ein ESP 8266 verwenden.

    Okay - ggf. wärs ja auch cool gewesen das ganze mit MicroPython u. dem ESP32 zu machen - aber ich konzentriere mich jetzt mal auf den ESP8266.

    BTW: dieser ist hier in dem Forum ja auch kein ganz unbekannter - wird auch oefter besprochen ( z.B. hier: ESP8266 mit ULN2003 und 12V Relais )

    Bestandteile sind also:

    - ein ESP 8266

    - NodeMCU Board / bzw. Wemos

    - ein L293 oder L296 nebst shield.

    Die Frage ist, welches Protokoll ich hier verwenden soll.

    Websockets: Websockets haben eine menge an Extra overhead für einen Arduino. man muss erstmal eine passende library für einen webserver mit HTTP und websocket support finden.

    Dieser overhead frisst viel Speicherplatz und kostet das System einiges an Performanz. Ein einfacher UDP-setup ist hier viel viel schlanker. Damit kann man einige Daten Pakete mit den Kommandos an den Wagen senden.

    TCP: und das UDP oder User Datagram Protocol.

    Das TCP ist verbindungsorrientiert - wenn eine Verbindung eingerichtet ist dann können die Daten bidirectional gesendet werden.

    UDP ist simpler - ein Verbindungsloses Internet protocol. Die Messages werden als Packete im UDP geschickt. Dabei können schon auch ein paar Pakete verloren gehen.

    Dann gäbe es noch das RF-Protokoll.


    Ein Ansatz:

    Wenn man das Ganze am Ende mit einem Smartphone / Tablet / PC steuern will dann ist WiFi schon eine prima Sache, denn diese Geräte haben Wifi ja schon integriert.

    Hmm - vielleicht sollte ich einfach mal ein paar Möglichkeiten ausprobieren. Also z.B. einen Ansatz unter Verwendung von Websockets - es gibt hier auch schon Bibliotheken auf die man zurückgreifen kann. Und dann kann ich ja einen UDP-Ansatz paralell noch verfolgen!?


    Wie würdest Ihr denn vorgehen?

    Freue mich, von Euch zu hören

    viele Grüße

  • RC Auto mit ESP8266 fernsteuern: Welches Protokoll verwenden - TCP / UDP oder RF? Schau mal ob du hier fündig wirst!

  • Ich würde UDP nehmen. Denn TCP ist zwar zuverlässiger, aber bei Verbindungsunterbrechung oder abriss kommt es zu starken verzögerungen, und dann reagiert die Lenkung verzögert, was man nicht will. (es sind noch alte Lenkkommandos im Puffer die irgendwann nach wiederherstellen der Verbindung dann abgearbeitet werden, wobei neuere Kommandos evtl. verlorengegangen sind. ) Also lieber gleich kommandos verlieren, dafür dann aber prompter reagieren. Ein UDP Protokoll kann man auch sehr leicht auf einen 433MHz Sender portieren.

  • hallo und guten Abend Wend,

    vielen Dank für deine sehr schnelle Antwort - die auch einleuchtet.

    Ich würde UDP nehmen. Denn TCP ist zwar zuverlässiger, aber bei Verbindungsunterbrechung oder abriss kommt es zu starken verzögerungen, und dann reagiert die Lenkung verzögert, was man nicht will. (es sind noch alte Lenkkommandos im Puffer die irgendwann nach wiederherstellen der Verbindung dann abgearbeitet werden, wobei neuere Kommandos evtl. verlorengegangen sind. ) Also lieber gleich kommandos verlieren, dafür dann aber prompter reagieren. Ein UDP Protokoll kann man auch sehr leicht auf einen 433MHz Sender portieren.

    Das hab ich auch gelesen, dass es mit TCP zu den von dir beschriebenen Problemen kommen kann (siehe unten).

    Auf den ersten Blick denkt man ja, dass TCP es im Grund absicher dass die Kommandos ankommen am Auto und es eher UDP ist bei dem Pakete verloren gehen könnten. Also mal angenommen - wenn man ein Links Kommando aus einer Serie von Links und Vorwärts verliert und der Wagen dann nur noch vorwärts fährt - und schlicht (aufgrund des Verlusts von Paketen nicht nach auch Links fährt. Aber das ganze hängt wohl von der Implementierung ab. Wenn man das Signal seher oft sendet - und nicht nur bei dem Wechsel der Fahrtrichtung dann dürfte das mit UDP auch gut gehen denn dann wäre der Verlust eines ersten "links" doch verkraftbar, weil es 100ms später dann nochmals ein "links" gesendet wird.

    TCP und Turbulenzen: TCP vs UDP

    Indrek Ots hat dies beschrieben - hier: https://blog.indrek.io/articles/how-t…i-with-esp8266/

    Zitat

    During the first tests I discovered that the car was not very responsive. The car would continue driving even when I had released all keys for example.

    I found that this was due to the fact that the communication was done over TCP. I’m guessing the TCP handshake process and acknowledgements

    introduce some overhead. After I had reengineered the car to use UDP, everything worked flawlessly.

    Indrek hat also echte Turbulenzen gehabt mit TCP - nach dem er dann zum Einsatz von UDP gewechselt ist, ging alles gut. (vgl. https://blog.indrek.io/articles/how-t…i-with-esp8266/ )

    By the way: etwas am Rand - aber dennoch nicht komplett abwegig ist es, an ein "running out of range" zu denken - und an einen Emergency-Stop.

    Zitat

    The car uses several actuators, like servo's, LED's and a DC-motor. Imagine all and everything finally is working 100% smoothly, including the Bluetooth connection. Everlything works as it's supposed to. Nothing more, nothing less. However, what do you do if you notice that when you control the speed and you wanna cut the Bluetooth connection (just stop powering the Bluetooth module), your car keeps on driving. What do you do when it keeps doing so - on and on.. ;) That means when your drive the RC car out of range, it keeps going! Then wen need to program a emergency stop for when Bluetooth connection is lost, cutting the cars acceleration and letting it roll out.

    vgl. hier Arduino https://forum.arduino.cc/index.php?topi…9911#msg4029911


    Dir Wend nochmals vielen Dank für deine Einschätzung.

    Viele Grüße Malaga, ;)

  • Ein automatischen Anhalten, wenn die Verbindung abreisst, ist eigentlich kein Problem, denn man kann leicht den Verbindungsstatus abfragen, jedenfalls wenn das Auto ausser Reichweite geht. Wenn der Sender aus der Reichweite geht, ist es etwas schwieriger zu detektieren.

  • Danke Linus für den Hinweis,

    ... klar gibts µPy auch für den ESP8266 - aber da es halt schon etwas ressourcenhungriger ist, sprechen sich einige dafür aus µPy dann doch eher auf dem 32er einzusetzen. Sicher war diese Annahme auch etwas von Stefan Frings beeinflusst...


    Zitat

    Da es µPy auch für den ESP8266 gibt, verstehe ich diesen Satz nicht. :conf:

    vgl http://stefanfrings.de/esp8266/

    also: µPy läuft sicher auch auf dem kleinen - der Groessere hat halt noch mehr Ressourcen.


    hier nochmals stefan frngs:

    Zitat

    Der ESP32 Chip wird als Nachfolger zum ESP8266 gehandelt: größer, breiter und schneller. Am interessantesten finde ich, dass er Bluetooth und Ethernet kann. Dazu kommen 2x I²C, CAN, ein DAC, 16x PWM, ein Hall Sensor und ein Temperatur Sensor. Leider sind nur sehr wenige Boards mit den für Ethernet nötigen Bauteilen ausgestattet.

    Allerdings schränkt er - stefan frings, (Stand Herbst 18) eher noch ein - darauf zurückzugreifen.

    Zitat

    Leider macht die Software (im Herbst 2018) noch einen sehr unfertigen Eindruck. Sowohl das anfängerfreundliche Arduino Plugin als auch das eher für Profis gedachte IDF (IoT Development Framework) des Herstellers laufen noch sehr instabil. Viele der angekündigten Features sind noch nicht bzw. nur teilweise implementiert. Deswegen kann ich den ESP32 noch nicht empfehlen.

    doch - linus was sind drei Monate in solch schnelllebigen Zeiten...

    Eine halbe Ewigkeit.


    ergo. ... also auch ich hab mir jetzt mal ein paar ESP 32 bestellt .

    an dieser Stelle nochmals vielen vielen Dank - an alle die hier so viel Support leisten: Danke dir Wend fürs Posten - danke für Deinn super Beitrag.

    Du machst das Forum hier zu einem echt wertvollen Platz - einem wertvollen Platz für Ideenaustausch u. Support.

    Das beste was mach machen kann ... vg

    vielen Dank!!!!

    malaga

  • hi Wend

    nein noch nicht aber die kommen noch ... versprochen.

    LG Malaga

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!