Universelle Fernsteuerung mit Bluetooth

[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...

[HaWe]

Ein Problem sind ja bei Eigenbauten oft die Entwicklung guter, universeller Übertragungsprotokolle (v.a. auch für andere Nutzer universell geeignet), und als Fernsteuerungskonsole finde ich ja die PS2-WL Controller ungeschlagen, mit einem perfekten Handling - für die gibt es auch Arduino-kompatible Empfangsmodule und sogar komplette passende Shields. Als fertige Lib dafür gibt es die PS2X_lib bei github (leider nur für AVRs).

https://www.conrad.de/de/p/arduino-e...SABEgIr7vD_BwE (Schei** Conrad urls!)

https://www.googleadservices.com/pag...gQICxBB&adurl=

https://www.ebay.de/itm/Arduino-Moto...53.m1438.l2649

Leider fehlt hier ein Display für die Rückübermittlung und Anzeige von Werten.
Vlt könnte man speziell dafür auch ESP8266's mit aufgesteckten Displays via WiFi verwenden, zum oben/seitlich Dranheften an die PS2-Control (z.B. Klettband), z.B. von Adafruit
https://www.adafruit.com/product/3045

[Rabenauge]

Das Protokoll ist überhaupt kein Problem: die HC-05-Module sprechen seriell.
Also: Klartext rein, Klartext raus- so simpel wie ne Strippe ohne Kabel...
Das hat den Vorteil, dass man auch Odometriedaten problemlos im Klartext übertragen kann, der Empfänger (also der Rechner in der Fernsteuerung) braucht die nicht mal aufzudröseln, der kann das Gequassele einfach direkt aufs Display werfen, wenn man will.
Wenn man so vorgeht, ist es völlig Wurst, welche Telemetriedaten der jeweils aktuelle Roboter sendet.

Einzig nervig ist, dass die meisten Arduinos nur eine serielle Schnittstelle haben (und ich nun nicht unbedingt nen Mega da rein stopfen möchte).
SoftSerial funktioniert- mitunter.
AltSoftSerial wiederum geht nur an bestimmten Pins..

[HaWe]

wenn man KEIN Display will und NUR AVRs verwenden will für die Robot-Zielplattform, sind die PS2 Controller ungeschlagen.
ICH SELBER würde aber Wert legen sowohl auf Display als auch auf ESP oder M4 Controller im Robot, KEINE AVRs.

Ein Problem sind ja bei Eigenbauten oft die Entwicklung guter, universeller Übertragungsprotokolle (v.a. auch für andere Nutzer universell geeignet), und als Fernsteuerungskonsole finde ich ja die PS2-WL Controller ungeschlagen, mit einem perfekten Handling - für die gibt es auch Arduino-kompatible Empfangsmodule und sogar komplette passende Shields. Als fertige Lib dafür gibt es die PS2X_lib bei github (leider nur für AVRs).

https://www.conrad.de/de/p/arduino-e...SABEgIr7vD_BwE (Schei** Conrad urls!)

https://www.googleadservices.com/pag...gQICxBB&adurl=

https://www.ebay.de/itm/Arduino-Moto...53.m1438.l2649

Leider fehlt hier ein Display für die Rückübermittlung und Anzeige von Werten.
Vlt könnte man speziell dafür auch ESP8266's mit aufgesteckten Displays via WiFi verwenden, zum oben/seitlich Dranheften an die PS2-Control (z.B. Klettband), z.B. von Adafruit
https://www.adafruit.com/product/3045

[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