Universelle Fernsteuerung mit Bluetooth

[Rabenauge]

Hallöle.

Da ja doch ein bisschen Interesse da war, hier mal ein eigener Faden dazu.

Für die, die nicht im XPlorer-Faden mitlesen:

Ich will eine eigene Fernsteuerung haben. Für den XPlorer, aber auch für alle möglichen, anderen Projekte später.
Sowas kann man doch immer mal brauchen, und ein Bluetooth-Modul ist schnell irgendwo angestöpselt (und kann nachher genauso einfach wieder entfernt werden), von daher lohnt es, ein bisschen mehr Aufwand zu treiben, als aufm Steckbrettl mal nen Joystick an einen Minirechner zu stöpseln.

Damit keiner den Schaltplan erst irgendwo suchen muss (im XPlorer-Faden ist da was zu), werd ich den, später, hier noch mal aktuell einstellen (es wird noch kleinere Änderungen geben, hauptsächlich wegen dem, etwas speziellen Button).

Erstmal zwei Bilders vom JETZT-Zustand der Sache:





Alles wichtige ist schonmal drauf: zwei Joysticks (analog X und Y, plus jeweils ein Button), ein Drehencoder (auch mit zusätzlichem Button), ein grosses Display, grafikfähig mit 128x64 Pixeln, links der Taster muss später in den Deckel eingebaut werden, in der unteren Ecke liegt- noch lose- das HC 5-Modul, und die Streifenraster-Platine trägt schonmal den Arduino Nano.
Der Taster, der da links steht, hat noch nen beleuteten, roten Ring drin...den kann man also ervorragend als Notaus-Scharfschalt-oder wasauchimmer-Taster benutzen. Auch ist es denkbar, die LED-Beleuchtung separat zu steuern (funktioniert, die hat nen eigenen Anschluss).

Der ist aber bisher nur aufgesteckt, ich hab die Platine so zurechtgeschnitten, dass sie unter das Display passt, und zwar so, dass später der USB-Port noch von aussen erreichbar sein wird.
Das runde, silberne Ding unten ist der Tank- ne kleine USB-Powerbank mit 2600mAh. Davon hab ich zwei Stück, sollte also eine mal leer gespielt werden, kann ich sie rausziehen und die nächste rein stecken.
Dazu wird einfach ein "übriges" USB-Kabel zerlegt, und der Stecker, mitsamt nem Stück Kabel, fest auf die Grundplatte geklebt (ich werds vermutlich mit meinem 3D-Stift verschweissen, das hab ich wo anders auch schonmal gemacht, funktioniert gut).

Alles ist auf dem gedruckten Unterteil fest verschraubt (3x8mm Spaxe), das hält bombensicher.
Später wird noch ein Rahmen drumherum kommen (im Unterteil sind schon sechs M3-Muttern eingelassen, um alles später verschrauben zu können), und dann ein Deckel rauf, damits auch schick aussieht.
Der Rahmen wird Aussparungen bekommen, einen für die Powerbank, einen für den USB-Anschluss-damit man das Ding später auch mal umprogrammieren kann, ohne erst alles zerlegen zu müssen (da kommt evtl. ein Stöpsel aus TPU rauf, mal gucken).

Auf die Platine wird nicht sehr viel mehr kommen, die ist nur so gross, damit ich alle Pins des NANO nach einer Seite wegführen kann.
Das bringt zwar später nen ordentlichen Kabelsalat im Gehäuse, aber den sieht ja keiner, hehe.
Spannungsteiler (oder Levelshifter, vermutlich aber ersteres) werd ich noch rauf bauen, für das BT-Modul, aber ansonsten dient die eigentlich eher der Verkabelung.
Die hat keine angedruckte Halterung auf dem Gehäuse-Unterteil, die drucke ich separat und kleb sie später ein, so bin ich da flexibler.
Die Eingabe-Geräte werden dann alle einfach mit Steckern an die Platine angeschlossen, und fertig ist die Laube.

Abmessungen des Unterteils: 19x12.5 cm. Kleiner wirds nicht- sonst krieg ich nicht alles rein.
Die Gesamthöhe wird später irgendwas zwischen 45 und 50mm betragen.
Wenn man wollte, könnte man das Teil allerdings auch auf der halben Grösse (mit den selben Funktionen, aber anderen Joysticks und nem anderen Display) bauen- ich find die Grösse ok so.

Frage in die Runde:
ist das Interesse an so nem Ding gross genug, dass ich den Aufbau noch universeller machen sollte?
Zum Nachbauen, meine ich....es geht nämlich noch flexibler:
-die Halterung für die Powerbank kann auch durchaus separat angesetzt werden, so könnte man z.B. die Stromversorgung auch anders lösen.
Ich hab kein Problem mit, die Zeichnungen rauszurücken, weiss aber, dass viele nicht gern mit Blender arbeiten, daher werden nachträgliche Änderungen nicht unbedingt einfach sein, für viele...
Für mich ist das kein Problem, die beiden Clipse separat zu zeichnen-die kann man dann später einkleben, wenn man will.
Wenn ein bisschen Interesse da ist, würd ich das machen....
Wären dann weitere Änderungen (anderes Display, z.B.) gewünscht?

Sonst irgendwelche Anregungen, Kommentare....?

[Moppi]

Hallo,

ich will bloß mal ein paar Gedanken einbringen, die mein Anforderungsprofil betreffen.
Wenn Du das Teil so baust, wird es für Dich in Ordnung sein und Du hast Deine Gründe, es so, mit diesen elekt. Bauteilen zu bauen.

Joysticks zur Richtungssteuerung sind i.O.
Drehencoder für Auswahlen in Menüs (?): Taster wären praktischer.

Für die Platine, bei einer Fernsteuerung (die Größe würde ich nicht so ins Unendliche treiben wollen) bieten sich der kompakte Nano 33 BLE und der MKR 1010 WiFi an - würde ich jedenfalls meinen.

Die 3D-Files müssen nicht von einem bestimmten Programm sein. Du kannst die STL-Files zur Verfügung stellen. Zwecks Änderungen an den 3D-Teilen. Die müssen nicht unbedingt geändert werden können. Sämtliche Teile könnten auch einzeln ausgestaltet sein, um sie dann auch einzeln zu drucken und anschließend (das beliebte Thema ) zusammenzukleben, bei PLA funtkioniert das ja doch super.


MfG

[inka]

ich war wohl derjenigerwelcher, der interesse gezeigt hat ... Nun bin ich in mich gegangen und habe überlegt was ich bisher gemacht habe...

Sowas z.b.

damit konnte ich ein mini-roboter-arm mit 4 Servos steuern, ging, für die ersten versuche. Ansonsten würde sich so eine fernbedienung, wie Du jetzt bauen willst, besser eignen...
Ich habe dann allerdings den einfacheren weg gewählt und eine app (Arduino-remote-lite) auf meinem smartphone für diese zwecke umprogrammiert, ging besser als mit der fest verdrahteten...

Zweite anwendung war die defekte steuerung an meinem e-bike, die konnte ich mit der verwendung eines nano und ebenfalls eines HC05 moduls lösen. Allerdings auch hier wieder mit einer android app als steuerung...

alles in allem betrachtet, smartphone habe ich eigentlich immer zur hand, auch gibt es halterungen dafür für alle möglichen gelegenheiten...

für mich stellt sich nun die frage: was hätte eine selbstgebaute fernbedienung - ausser dem spass beim bauen - für vorteile?

[Rabenauge]

für mich stellt sich nun die frage: was hätte eine selbstgebaute fernbedienung - ausser dem spass beim bauen - für vorteile?

Schonmal eine Drohne per Handysteuerung geflogen?
Und anschliessend zu Vergleichszwecken mit nem _richtigen_ Controller?
Ich hab zwei Drohnen, die beides können...das mit dem Handy funktioniert auch, aber: Touchscreen höchstens mittelmässig, per Neigung....zufriedenstellend.
Niemals aber ist es möglich, per Handy auch nur einigermassen präzise zu fliegen.
Auch nicht bei durchaus hochwertigeren Drohnen und Handys (in meinem Fall ne Bebop2 und ein Galaxy S).
Spätestens dann, wenn mehrere Achsen gleichzeitig gesteuert werden sollen, versagt die Geschichte ziemlich kläglich....das kannst du mit dem Roboterarm ja mal ausprobieren. Fahr _irgendeinen_ Punkt mal effizient (so dass er sich in mehreren Achsen gleichzeitig bewegt) an..viel Spass.
Ich fand die Steuerung mit Handy schon beim XP(1) einfach nur gruselig.

Wenn man einfach mal nen Motor testen will, oder so einfache Geschichten, hast du natürlich recht.

Dazu kommt dann noch, dass so manche der Apps zumindest..fragwürdig..sind, in Bezug auf Datenschutz, Berechtigungen usw. Bei einigen schrillen meine Alarmglocken sogar sehr deutlich....
Dem Braten trau ich nur, wenn ich ihn selber programmiert habe, und ich kann dieses Java-Gerümpel einfach nicht ausstehn.

@Moppi: der Drehencoder kann auch ganz andere Sachen erledigen, beispielsweise die Z-Achse eines Roboterarms, einer Drohne oder auch eines XPlorer steuern.
Wie man den nutzt, ist dem Ding egal...der Fernsteuerung im übrigen auch.
Bin noch nicht dazu gekommen, weiter zu machen, aber ich plane, dass die Fernsteuerung lediglich die aktuellen Positionen der Eingabe-Geräte sendet.
Was der jeweilige Roboter dann damit anfängt, muss er selber wissen.
So ist die nämlich mal _wirklich_ universell- und genau das will ich haben.
Die soll nich an jedes einzelne Projekt neu angepasst werden....daher auch gleich der zweite Stick: für den XPlorer völlig unnötig.
Aber beispielsweise ein Hexa (oder der openDog) kann den sehr gut gebrauchen, um Körper und Beine separat steuern zu können.

Insofern gibt es gar nicht viel an Menüs, was man braucht: Displaykontrast (denen, die den Schaltplan angesehen haben, wird aufgefallen sein, dass es keinen Kontrast-Poti gibt, mal gucken, ob das überhaupt funktioniert), und vielleicht noch irgendwelche Zuordnungen an Telemetrie, oder vorgefertigte Masken, um die Positionen der Sticks (oder Trimmungen) zu viualisieren...viel wird das nicht.

Mehr Buttons?
Nein..es sind ja schon drei da- der vierte liegt im Moment daneben. Aber die freie Fläche oberhalb des linken Sticks kann auch für weitere genutzt werden, ich will das Gehäuse-Oberteil eh so zeichnen, dass man diese Teile separat einsetzt, so ist man auch da flexibel.
Da liesse sich auch ein (kleines) Tastenfeld unterbringen.

Die Halterung für die Powerbank als separate Teile zu zeichnen ist kein Ding, aber die Halterungen für Display, Sticks und Encoder....die müssten, um später auch _wirklich_ zu halten, dann schon nen Rahmen unten haben. Das kostet Platz...das sind nämlich im Grunde nur einfache Kegelstümpfe mit ner Sackbohrung.
Einzeln aufgeklebt hält das nur nen Bruchteil der Last aus...glaub mir das.

Ausserdem macht es keinen Sinn mehr, ein Gehäuse zu zeichnen, wenn diese Positionen nicht wirklich fest vorgegeben sind.
Damit das passt, müsstest du diese ganzen Halter dann ja trotzdem millimetergenau positioniert verkleben...

Was sinnvoll wäre, sind blinde Abdeckungen (anstatt denen wo später die Sticks raussehen usw.)- so kann man diese Teile bei Nicht-Bedarf auch weglassen, und das Gehäuse trotzdem zu machen.

Diesen Nano BLE kannte ich noch gar nicht- nette Idee, gleich eine IMU mit zu verbauen (die hatte ich auch, aber von dem BLE wusste ich nix)- allerdings treibt das den Software-Aufwand enorm in die Höhe- hast du schonmal mit so einer IMU gespielt?
Ich schon: eine Achse krieg ich halbwegs hin, danach wirds _knifflig_.
Aber man könnte den natürlich, anstatt meinem Nano Normalo, verwenden, klar.
Ein Pi Zero passt auch unters Display...und hätte ggf. schon Bluetooth und Wifi an Bord.

Auf meine Hauptplatine wird übrigens nicht viel rauf kommen: im wesentlichen ist die nur dafür gedacht, alle Pins des NANO auf eine Seite zu kriegen (ob das die allerbeste Idee ist, weiss ich auch nicht, aber wenn man das nicht macht, wirds nen ziemlichen Nudelsalat unterm Display geben), vielleicht kommen noch zwei Widerstände rauf (Spannungsteiler für das HC-05), oder alternativ ein Levelshifter (der eher nicht, weil die, die ich hab, allesamt mindestens vier Leitungen haben, die brauch ich einfach nicht).
Ansonsten ist die nur zur besseren Verkablung gedacht, und zur Befestigung: die Nanos haben nämlich nur _eine_ Montagebohrung, und die hat, glaub ich, nur 1.6mm-das hält nich viel.
Am liebsten würde ich den Nano sogar sockeln (im XPlorer hab ich das gemacht), aber das wird in der Höhe dann sehr eng- mal gucken.

Bevor ich aber jetzt weiter baue, werd ich das Display erstmal aufs Steckbrett tackern, und mit nem Uno zusammen, rausfinden, welche Pins das Ding _wirklich_ braucht (ich hab ne Anleitung dazu, nach der ich in den bisherigen Skizzen auch vorgegangen bin, aber wenns auch übersichtlicher geht...), und die Frage, ob der Kontrast auch per PWM einstellbar ist, muss auch geklärt werden (einige sagen, es geht, andere sagen, es geht nicht, also erforsch ich das halt selber).

[inka]

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

nein, habe nur eine mini-drohne mit dazugehöriger FB...

Wenn man einfach mal nen Motor testen will, oder so einfache Geschichten, hast du natürlich recht.

darüber hinaus bin ich nie gekommen, für das was ich vorhatte, hats gereicht

Aber beispielsweise ein Hexa (oder der openDog) kann den sehr gut gebrauchen, um Körper und Beine separat steuern zu können.

das ist auch für mich noch ein thema...

Bevor ich aber jetzt weiter baue, werd ich das Display erstmal aufs Steckbrett tackern, und mit nem Uno zusammen, rausfinden, welche Pins das Ding _wirklich_ braucht (ich hab ne Anleitung dazu, nach der ich in den bisherigen Skizzen auch vorgegangen bin, aber wenns auch übersichtlicher geht...), und die Frage, ob der Kontrast auch per PWM einstellbar ist, muss auch geklärt werden (einige sagen, es geht, andere sagen, es geht nicht, also erforsch ich das halt selber).

mach mal ... werde aufmeksam lesen und ab und zu mal eine dumme frage stellen Zu gegebener zeit wäre eine bauteileliste hilfreich...

[Moppi]

allerdings treibt das den Software-Aufwand enorm in die Höhe- hast du schonmal mit so einer IMU gespielt?

Nein,an das Ding habe ich auch gar nicht gedacht.

Mit dem Drehencoder kann man auch andere Sachen machen, ja, ist mir dann auch eingefallen.

Die Gesamthöhe wird später irgendwas zwischen 45 und 50mm betragen.

Das ist schon heftig. Reichen 30-35mm nicht aus?




MfG

[Rabenauge]

Die Joysticks sind insgesamt (mitsamt dem Button, den man noch runter nehmen könnte) knapp 40mm hoch.
Niedriger wirds also nicht, auch nicht, wenn man die in die Bodenplatte einlässt.
Ich hab sie bewusst ein wenig höher gesetzt um unter dem Display genug Platz zu haben, aber nur etwas erhöht, weil ich will, dass die Daumen-Sticks auch möglichst wenig über das Gehäuse raus ragen, später (die sollen dann in Vertiefungen sitzen).
Da ich recht oft nur zu Fuss unterwegs bin, solll das Teil rucksacktauglich werden, und da gibts kaum was blöderes, als weit vorstehende Steuerknüppel.


Was aber geht: man kann eine Mini-Version bauen.
Mit anderen Joysticks, z.B die von der PlayStation portable.
Sind deutlich kleiner, und nur 13mm hoch (samt Platine)- allerdings haben die _nicht_ die Präzision der grösseren, die ich verbaut hab. So einen hab ich auch da, auf meiner Universal-Test-Platine, da müsst ich mal gucken, wie hoch der eigentlich auflöst (lange her...).
Zur Mini-Version würde ich dann auch das Display tauschen (meine Sturheit, diesen Klotz zu benutzen, macht das Ganze unnötig gross, das weiss ich eh), man kann das grosse blaue Ungetüm ohne weiteres gegen ein Mini-Oled in Briefmarkengrösse tauschen-die haben genau die selbe Auflösung und mindestens auch so hohen Kontrast. Man braucht halt ne ordentliche Brille (oder längere Arme, je nachdem....).
Dann kriegt man die Fernsteuerung in..na sagen wir....Zigarettenschachtelgrösse hin.
Bei annähernd den selben Funktionen (nen so kleinen Drehencoder zu finden, könnte schwerig werden, aber zumindest die Welle lässt sich bei meinem problemlos noch etwas kürzen).
Vielleicht mach ich das später mal, so aus Spass...

[Klebwax]

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.

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.

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

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

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

[HaWe]

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.