Universelle Fernsteuerung mit Bluetooth

Zitat:

---

Zitat von Rabenauge

von daher lohnt es, ein bisschen mehr Aufwand zu treiben, als aufm Steckbrettl mal nen Joystick an einen Minirechner zu stöpseln.

---

Ich nehme mal an, das bezieht sich auf das vom mir gezeigte Bild.

Zitat:

---

Zitat von Rabenauge

Schonmal eine Drohne per Handysteuerung geflogen?
Und anschliessend zu Vergleichszwecken mit nem _richtigen_ Controller?

---

Das ist nun nicht mein Ziel. Mir geht es eigentlich nicht darum im klassischen Sinn ein Modell fernzusteuern, sondern einen drahtlosen Zugang zu einem Fahrzeug zu haben. Wenn ich ein Fahrzeug oder auch ganz generell eine Elektronik baue, startet alles auf dem Tisch an Labornetzteil, Scope und Debugger. Da ist ein Zugriff noch leicht, Netzteil abschalten oder SW stoppen. Irgendwann kommt aber der Punkt, wo ein Motor auch mal etwas bewegen soll. Um dafür ein User-Interface zu haben, nehme ich gerne einen Nunchuk. Da ich eigentlich immer den I2C Bus verwende, ist dafür nur ein passender Stecker und etwas SW nötig. So kann man dann mit einer "Drahtfernbedienung" ein Fahrzeug steuern und prüfen, ob man mit seinem Motoren, Getrieben, Rädern und der Stromversorgung richtig liegt.

Nun will man ja nicht dauernd hinter dem Fahrzeug hinterherrennen. Da kommt jetzt die Fernsteuerung ins Spiel. Wenn es nur darum geht, das Kabel am Joystick durch Funk zu ersetzen, hat man ziemlich freie Auswahl. Da aber mein Ziel nicht vorrangig die manuelle Steuerung ist, habe ich das Fahrzeug in mein LAN via WiFi eingebunden. Mit den ESP ist das am Ende billiger und einfacher als über Ethernet, ich verwende sie auch für stationäre Geräte. Jetzt kann man also das Fahrzeug von jedem Rechner in meinem LAN steuern.

Wenn es aber ins Freie geht, will ich nicht mit dem Laptop rumrennen. Ich habe daher eine meiner Platinen, die einen ESP und Akku hat um einem Adapter für den Nunchuk erweitert und damit eine Art "Funkfersteuerung" gebaut. Dabei funken Fahrzeug und Fernsteuerung nicht direkt miteinander, sondern alles geht übers LAN. Bei Gelegenheit werd ich für die Wlan-Fernsteuerung eine neue Platine machen. Das Ziel ist, den Hauptteil in die Tasche zu stecken oder an den Gürtel zu klemmen und eine Hand frei zu haben. Dazu ist mir der gezeigte Aufbau zu wacklig. Ich behalte mir gerne die Möglichkeit vor, das Fahrzeug einfach festzuhalten, bevor es sich in den Kellerschacht stürzt. Und dazu hab ich gerne eine Hand frei und dafür ist ein Nunchuk ja gedacht (in der anderen Hand hat man die WiiMote).

Mir geht es primär nicht darum, ein Fahrzeug fernzusteuern. Das ist nur ein Nebeneffekt. Am Ende geht es darum, daß und wie ein mehr oder weniger autonomes Fahrzeug mit seiner elektronischen Umwelt, und die steckt bei mir im LAN, kommuniziert. Um das an einem Beispiel zu beschreiben, das irgendwann (hoffentlich) autonome Fahrzeug öffnet über Wlan, genau wie ich mit dem Handsender, die Garagentür um dort einzuparken.

Zitat:

---

Zitat von Rabenauge

Das Protokoll ist überhaupt kein Problem: die HC-05-Module sprechen seriell.

---

Wie oft ich das in meinem Leben schon gehört habe.

Zitat:

---

Zitat von HaWe

aber es hakt eben immer an der Plattformunabhängigkeit, Datenübertragungsfehlern, Datenübertragungsabbrüchen, gegenseitiger Störung paralleler Prozesse hoher Prio oder der Nutzerfreundlichkeit und -Verständlichkeit samt einfacher individueller Implementierung.

---

Am Ende ist aus dem "einfach asynchron seriell" dann doch ein aufwendiges Protokoll geworden. Das OSI-Modell für die Datenübertragung ist nicht ganz umsonst entwickelt worden.

Und es muß auch nicht immer in voller Schönheit jede der 7 Schichten implementiert werden. Im LAN muß man es nicht selber machen. Man kann dort auf TCP oder, wie ich es mache, auf UDP aufsetzen. Damit hat man sich schon mal die übelsten Probleme vom Hals geschafft.

@Rabenauge
Zusammengefasst ist mein Ziel ein anderes als deins. Daher sind auch die Implementierungen unterschiedlich.

MfG Klebwax

Ich halte tatsächlich auch Seriell/BT ohne Transport-Control-Protokoll für zu fehleranfällig und nicht ausreichend übertragungssicher, v.a. wenn auf der Zielplattform noch weitere zeitintensive Threads mit hoher Prio laufen.

Mit ESP WiFi und Webserver Libs habe ich andererseits zwar eine sichere, aber noch nie eine Kommunikation mit Echtzeitfähigkeit hinbekommen.

Gelänge es, die PS2X_lib für das 2,4GHz Empfangsmodul so umzuschreiben, dass man es direkt an einem ESP32 anschließen kann (ESP32: Dualcore mit std::thread Implementierung), dann hätte man 3 Fliegen mit 1 Klappe erwischt:
- eine etablierte, gut funktionierende Lib, bei der man sich keine Gedanken machen muss, wie der Empfänger der PS2-Signale der Buttons und Joysticks empfängt + auswertet,
- eine MT-fähige Plattform, die neben der Echtzeitabfrage und -verarbeitung auch weitere Threads in Echtzeit parallel abarbeiten kann, sogar mit verschiedenen prios, und
- eine ESP-MCU. die Telemetriedaten per WiFi synchron zurückschicken kann (an einen an den PS2 Controller angeklebten ESP8266 mit Display), zur Visualisierung, und da das synchron zur 2.4GHz Richtung geht, auch ohne gegenseitige Behinderung der Datenübertragung.
Leider ist die PS2X_lib aber nur für AVRs, nicht für ARMs und nicht für ESPs (wegen vieler AVR-spezifischer low level Befehle oder Registernamen etc., und auch die verwendeten Pins müssten ggf. umbelegt werden).

Eventuell könnte man statt dem ESP32 auch einen der neuen WiFi-fähigen Arduino MKR-Boards verwenden.

Eine Alternative wäre auch, deine Fernbedienung Marke Eigenbau mit einer ähnlichen Lib auszustatten wie die PS2X_lib für den PS2 Controller, womit man dann bei identischer Syntax genau so einfach und genau so universell den Zustand aller Buttons+Sticks abfragen kann, wie es die PS2X_lib tut.

Zitat:

---

Zitat von HaWe

Mit ESP WiFi und Webserver Libs habe ich andererseits zwar eine sichere, aber noch nie eine Kommunikation mit Echtzeitfähigkeit hinbekommen.

---

Das ist pflichtgemäß so. Ethernet ist nicht echtzeitfähig, WiFi erst recht nicht. Da braucht nur ein Sender, der noch nicht mal zum eigenen Netz gehören muß, einen Kanal zu blockieren und schon hat man ein Delay. Webserver heißt http und das ist Schicht 7 im OSI Modell. Da kommen also zu Ethernet/WiFi noch die Latenzen von den 7 Schichten dazu. Wenn man den http-Overhead, der einem am Ende nichts bringt, wenn man kein Webserver oder Browser ist, weglässt, wirds schon mal besser.

Eine klassischen Fernsteuerungen hat eine Framerate von ca. 20ms. Wenn man direkt auf Sockets programmiert, kann man mit WiFi ähnliches erreichen. Mit gelegentlichen Überschreitungen der 20ms muß man aber schon rechnen. Der Verlust eines Frames kommt aber auch bei einer Funkfernsteuerung vor und bleibt dort typisch unbemerkt. Für den Menschen mag das Echtzeit sein, das reicht auch für Kunstflug. Von dem, was man technisch bei Echtzeit erwartet, ist das meilenweit entfernt.

MfG Klebwax

Sodele.
Das Display läuft.
Momentan nur ein Test-Beispiel (ne abgewandelte Version vom Graphics-Test der U8g2lib), aber der tut es.
Und: der Kontrast _lässt_ sich per PWM einstellen- mit Einschränkungen.
Der Kontrast-Pin hängt erstmal auf Pin D9, und ab etwa PWM 170 werden die Zeichen "sichtbar".
Allerdings noch sehr schwach, und eher rötlich, als weiss.
Bei PWM 200 kann man sie schon sehr gut erkennen, aber immernoch rötlich und...flackernd wie ein alter Bildschirm.
Kurz gesagt: es ist eher unnötig bei meinem, da jemals _irgendwas_ dran rum zu stellen: PWM 255 und gut.
Das ergibt blitzsaubere, weisse Pixel (eigentlich könnt man sich den Pin auch sparen, und einfach 5V ran legen).
Ich schaue mir das heute abend im Dunklen noch mal an, aber wenn es dann auch so schön aussieht, kommt der Kontrast-Pin einfach an die 5V-Schiene und fertig.
Umso mehr bleibt für Erweiterungen übrig, hehe.

Angeschlossen hab ich das Teil mometan an nem Uno (der ist halt mein Knecht fürs Steckbrett), nach dem Schema der Anleitung von AZ-Delivery.
Das E-Book gibts gratis bei denen, wer Interesse hat...hier rein werfen möcht ich es nicht.

Als nächstes teste ich mal, ob es auch mit anderen Pins so gut geht, ich denke aber, schon, da die Pins im Programm definiert werden.
Dazu gäbs keinen Grund, wenn man sie nicht ändern könnte.

Sodele.
Inzwischen habe ich noch ein bisschen mit dem Display gespielt- und es gibt einige Erkenntnisse:

1.: wenn mans _richtig_ anschliesst, funktioniert die Sache mit dem Kontrast per PWM _besser_.
Ich hatte doch tatsächlich den 5V der LED-Beleuchtung an den Kontrastpin angeschlossen-daher das Geflackere.

2.: der Plan geht auf: ich kann im Bedarfsfall die AltSoftSerial-Bibliothek benutzen (die normale SoftSerial ist recht...unzuverlässig), da es kein Problem ist, die Pins 8 und 9 dafür freizuhalten.

3. man _könnte_ den CS-Pin auch noch frei bekommen, indem man den entsprechenden Pin vom Display einfach auf 5V legt- funktioniert!
Ob es ne gute Idee ist, weiss ich nicht....
Das hätte z.B. die Einschränkung, dass man dann den SPI-Bus nicht noch für andere SPI-Geräte benutzen kann. Da es ausreichend freie Pins geben wird, lass ich den CS auf Pin 10, und gut.
Das Display braucht trotzdem insgesamt nur vier Pins: Kontrast (12), CLk(13), MOSI(11) und CS(10).
Ist doch ganz erträglich.

Ich häng mal das Anschlusschema an. Der Übersicht wegen hab ich mal die ganzen Leitungen für die Eingabegeräte und das BT-Modul rausgenommen.

Anhang 34901

Hallo Sly,

vergiss Software Serial beim Nano am besten. Was damit funktioniert ist das Senden in eine Richtung, Halbduplex. Bei Vollduplex kannst Du Probleme bekommen. Das AltSoftSerial ist da nicht viel besser, habe ich auch ausprobiert. Aber dazu hat man ja den UART, um Daten zuverlässig zu übertragen. Grundsätzlich musst Du aber immer damit rechnen, dass bei einer Seriellen Übertragung der Datenstrom gestört werden kann. Ob der UART da mit Prüfsummen/-bits Abhilfe schafft, weiß ich allerdings nicht. Von UART zu UART seriell zu übertragen, ist auch kein Problem, wenn Du einen DIP-Schalter (oder einen anderen) einsetzt, mit dem Du die serielle Verbindung unterbrechen kannst, um Software auf die Geräte, per USB-Kabel, aufzuspielen.

MfG

Ich habs befürchtet- du hast damit (schlechte) Erfahrungen?
Getestet hatte ich die Kommunikation neulich zwischen dem XPlorer (der hat ja inzwischen auch ein HC 05 drin) und nem Uno, auf beiden SoftSerial....auf dem UNO lief es tadellos, aber der NANO zickte etwas.
Allerdings hatte der UNO auch nix weiter zu tun, während auf dem Nano ja "nebenbei" die XP2-Software läuft.

Schalter einbauen (um USB weiter nutzen zu können) wäre eigentlich Plan B gewesen- aber vielleicht sollte ich _den_ tatsächlich zu Plan A erklären?

Zitat:

---

auf dem UNO lief es tadellos, aber der NANO zickte etwas

---

Da haben wir dieselben Erfahrungen gesammelt. Mit dem 328P vom UNO hatte ich nie Probleme, aber mit dem vom NANO. Deswegen habe ich das dann bleiben lassen, mit SoftwareSerial. Allerdings, Halbduplex scheint damit auch auf dem NANO gut zu funktionieren. Also erst in eine Richtung senden und danach in die Gegenrichtung. Per UART und Schalter dazwischen ist die beste Lösung - jedenfalls für meine Bedürfnisse. ZUmal Du dadurch Pins freihältst, für was anderes.

MfG

Hm- hab das heute morgen mit nem Kumpel mal diskutiert, und es scheint sich ne noch cleverere Lösung aufzutun, zum abschalten:

Das Modul kommt an Rx1/Tx1, aber die Stromversorgung des HC 05 läuft über nen Transistor.
Der wiederum liegt an einem freien Pin- ich muss noch mal genauer in den Schaltplan gucken, aber da dürften noch einige frei sein.
Das wäre-wenns funktioniert-die eleganteste Lösung: man kann dann einfach per Software (z.B. beim Einschalten) zwischen USB-und BT-Betrieb wählen.

Ich werd aufm Steckbrett mal testen, was das HC 05 macht, wenn es "abgeschalten" ist aber auf den Logik-Leitungen Signale anliegen....mit etwas Glück funktioniert das.
Ein Transistor sollte reichen, so hoch ist ja die Stromaufnahme der BT-Module nicht..mit nem ESP würd ich das so nicht versuchen..

Aktueller Stand: das Display ist in die Fernsteuerung eingebaut und an den Nano angeschlossen, läuft.
Grad drucke ich mir ne kleine Halterung, mit der ich nen USB-Stecker (mit nem bisschen Kabel dran) in die Fernsteuerung schweissen kann, damit ich das Ding schonmal per Powerbank versorgen kann.

Nachtrag: Die Powerbank ist angeschlossen.
Den USB-Stecker zu verkleben, war gar nicht nötig, wenn man genau genug misst und druckt, passt der Stecker fest genug in den Halter.
Das Ding läuft nun auch standalone.
Ein-und ausgeschalten wird einfach, indem man die Powerbank rauszieht-oder reinschiebt.

Inzwischen gibt es auch ein Boot-Logo auf dem Display...frisst abartig Speicher, aber notfalls kann ich es noch ein paar Byte eindampfen. Wenn es ganz schlimm komt, kann ich _das_ auch noch aus Linien zusammencoden, das dürfte den Verbrauch auch senken, aber evtl ist das auch gar nicht nötig, mal sehn.

Etwas Ärger hat mir noch der Kontrast gemacht: erst klappte es gar nicht, den zu verstellen, bis ich drauf kam, dass Pin 12 bei den Nanos gar keine PWM kann.
Umgebaut auf Pin10 (12 ist nun CS, dem isses Wurst)...und ein schönes Flimmern *grummel
Hab dann Timer1 auf irgendwas mit 30KHz eingestellt, nun gehts- flimmern sieht man nur noch bei recht niedrigen Kontrasteinstellungen, aber da ist die Anzeige schon braun, statt weiss...

Die Betriebsdauer mit der kleinen Powerbank beträgt locker 1-2 Stunden (so lange lief die schon mit der einen, die hat inzwischen abgeschalten, aber ich weiss nicht, wie voll die vorher war) , und da ich von den Dingern zwei hab, halte ich das allemal für ausreichend.

Anhang 34911

Sodele.
Ich bin etwas weiter- und es gibt bisschenwas zu begucken.
Im Wesentlichen (*) steht die Hardware- und das Gehäuse nun seit vorhin auch zum grössten Teil.

Angeschlossen (und auch in die Software eingepflegt) sind die beiden Joysticks (X, Y und "Klick", so wie der Drehencoder (der noch nen schöneren Button kriegen wird), der kann bis 255 zählen vorwärts (im Uhrzeigersinn) oder von 255 bis 0 rückwärts- das funktioniert beliebig in beide Richtungen.
Da der auch ne Klick-Funktion hat, benutze ich die im Moment, um den Dreh-Zähler sofort wieder auf 0 setzen zu können...

Das Bluetooth-Modul hängt an Serial0, kann aber, wie weiter oben geschrieben, beim Start wahlweise aktiviert werden oder nicht (ich hoffe, man erkennts auf dem entsprechenden Foto)- momentan wird das einfach mit nem Klick auf den linken oder rechten Joystick entschieden.
So behält man die volle USB-Funktionalität, und kann die Ausgaben, anstatt sie zu funken, auch einfach auf den Monitor schicken.
Gesteuert wird das tatsächlich einfach über nen Transistor an einem freien Pin, der halt die Stromversorgung des BT-Moduls kappt oder zuschaltet.

Die Joysticks werden beim Einschalten automatisch kalibriert- es erscheint der Hinweis "Pfoten weg" auf dem Display, und ne halbe Sekunde später werden die Sticks ausgelesen, und der gelesene Wert als "Mitte" interpretiert.
Daraus wird ein Offset berechnet....das musste ich so machen, weil sich zeigte, dass die beiden keineswegs exakt die selben Werte liefern, in Mittelstellung..

Das silberne Ding, was auf dem ersten Foto daneben liegt, ist eine der beiden kleinen Powerbänke, die ich als Akku benutze-die wird einfach unten rein geschoben und muss dann nur so lange gedreht werden, bis sie in den eingebauten USB-Stecker rutscht.
Zum Ausschalten zieht man sie einfach ein Stückchen raus- die hält trotzdem im Gehäuse noch.

An der Rückseite gibt es noch ne Aussparung in dem blauen Teil-dort ist der USB-Anschluss des Nano dahinter, man kann den also auch umprogrammieren, ohne das Gehäuse öffnen zu müssen.
Vielleicht druck ich da noch nen Deckel aus TPU- mal gucken.

Zusammengehalten wird alles mit sechs M3-Imbusschrauben, in der Bodenplatte sind dazu sechs selbstsichernde M3-Muttis eingelassen.

Das letzte Bild zeigt den eigentlichen Steuer-Bildschirm- dort sollen dann noch weitere Infos rauf (Telemetrie, je nachdem, was der entsprechende Rbooter halt zurückschickt), und auch die Stellungen der Sticks und des Encoders werden grafisch angezeigt: mit den beiden Kreuzchen in der Mitte der Felder (die zu nem grösseren Punkt werden, wenn man klickt) kann man jetzt schon Pong spielen, hehe- im Kreis rechts oben wird der aktuelle Wert des Drehencoders angezeigt- auch der wird gefüllt dargestellt, wenn man den Encoder drückt.
Links kommt noch was ähnliches hin für den Button...

*) Kleinteile fehlen noch: natürlich kommen um die Joysticks noch ordentliche Abdeck-Blenden. Das grosse viereckige Loch vorne links-dort kommt auch eine rein, in die dann noch der grosse, beleuchtete Taster eingebaut wird.
Auch kriegt das Display noch nen anständigen Rahmen..

Für Moppi: Gesamthöhe der Fernsteuerung ist 45mm. Das ist aber vom Tisch bis zu den Joy-Sticks gemessen, also das höchste, was sie hat.
Das Gehäuse selber ist nur 37mm.