Universelle Fernsteuerung mit Bluetooth

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:

Anhang 34895

Anhang 34896

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

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

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.
Anhang 34898
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?

Zitat:

---

Zitat von inka

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

Zitat:

---

Zitat von Rabenauge

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

---

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

Zitat:

---

Zitat von Rabenauge

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 :-)

Zitat:

---

Zitat von Rabenauge

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

Zitat:

---

Zitat von Rabenauge

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

Zitat:

---

Zitat von Rabenauge

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.

Zitat:

---

Zitat von Rabenauge

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

---

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




MfG

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

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

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

ja, schon klar, dass die BT Module wie Serial sprechen, aber das Problem ist, die ganzen seriellen Daten so zu übertragen und auf der Zielplattform auszuwerten, dass sie problemlos für andere Hardware oder andere Anwender frei und universell portierbar sind samt Protokoll gegen Datenmüll.
Nicht dass ich das nicht schon selber geschrieben habe (Arduino-Arduino, Arduino-NXT, Arduino-Raspi, Arduino-PC, Raspi-PC (mit und ohne GUI), 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.
Aber auch andere Übertragungswege wie WiFi oder LoRa haben in dieser Hinsicht Nachteile, wenn es um all diese Gesichtspunkte geht.

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.

Hallo Sly,
schick schick. Mich interessiert Dein Display - ist noch 128x64? Bitte um Lieferant, Best.Nr und so. Danke im Voraus.

finde ich auch sehr schick!

Hi Sly,

gratulation! Und wie schon erwähnt, denke ich ersnthaft darüber nach das teil nachzubauen, wenn ich denn Deine ideen nutzen darf :-)

Das Teil gibts bei den üblichen Verdächtigen, für ungefähr nen Zehner.
Ich habs vom Eckstein-Shop.
Bei AZ-Delivery gibts das auch, die haben auch ein gratis E-Book, indem die Ansteuerung (nur SPI allerdings) erklärt wird, für Arduino und Raspberry.
Für die Fernsteuerung ist es, hm -wie sage ichs- in Zusammenspiel mit dem "kleinen" Ardunio Nano schon recht grenzwertig, die (scheinbar..ich hab keine andere gefunden) einzige Lib. dafür ist die U8g2- und die braucht Unmengen Speicher!
Für das Display würd ich was mit mehr Speicher unbedingt empfehlen-Teensy vielleicht (der ist mein Plan B, falls es mit dem Nano nicht mehr gehen sollte, aktuell bin ich bei 82% RAM-Auslastung).

Aber ansonsten ist das ein feines Ding, das stimmt.
Kleiner Schönheitsfehler: der eigentliche Anzeigebereich ist kleiner als die blau leuchtende Fläche- und leuchtet "anders" blau.
Das scheint bei den Dingern aber normal zu sein- das an meinem Drucker (baugleich) hat das genauso.
Erkennt man auf den Fotos auch....ich werd versuchen, mir da ne Blende passend zu drucken.

Und: die Idee, den Kontrast per Nano anzusteuern, hab ich wieder verworfen. Es _geht_ grundsätzlich, aber man muss eine möglichst hohe PWM-Frequenz benutzen und so _richtig_ gut funktioniert es trotzdem nicht. Ich hab inzwischen einfach nen 22KOhm-Spindeltrimmer eingebaut.
Da man den nur _einmal_ einstellen muss, reicht das auch, und funktioniert besser.

Dafür schafft es Kontrastwerte jenseits gut und Böse, hat nen ziemlich weiten Blickwinkel (seitlich 45° rauf gucken ist gar kein Problem, spitzere Winkel gehn auch noch) und ist recht flott, obwohl ich es nur im SPI-Modus betreibe (es kann auch parallel angesteuert werden).
Die beiden kleinen Steuerkreuze im Display, die ich mit den Sticks bewegen kann, werden recht simpel gezeichnet: es wird einfach der ganze Bereich "leer" überschrieben und dann das Kreuz an der neuen Position gezeichnet- da sieht man keinerlei Flackern oder Verzögerungen.

Auch per Raspberry lässt sich das Display ansteuern, das ist in dem E-Book ebenfalls beschrieben (man muss die U8g2-Lib für den Pi compilieren).
Hab ich aber nich ausprobiert...

wieviel Zoll Diagonale hat das Display?

Ähm...der nutzbare Bereich hat ~7.5cm Diagonale.
Klick mal auf den Link von Eckstein, den ich oben gepostet hatte, da gibts auch Datenblätter, Zeichnungen und Abmessungen.

@inka: du kannst auch die Daten haben. Druckteile, Schaltplan- wenn ich die mal wieder zerlege (wird demnächst, wenn ich den letzten Button noch verkabele, der ist inzwischen auch reingeschraubt) kann ich dir auch Fotos der Platine machen.
Leider finde ich meine Lochmaster-CD nicht mehr, sonst könnt ich dir sogar nen kompletten Bauplan erstellen...

Von mir aus auch die Software-die allerdings noch nicht fertig ist.
Sei aber gewarnt: mit _diesem_ Display wird es knapp mit dem Speicher des Nano.
Ich hab noch ungefähr 350 Byte RAM frei im Moment....und hoffe, dass es reichen wird.
Immerhin müssen da noch einige Strings hin-und hergeschickt werden....Speicherfresser!

Ich benutze schon für sämtliche Displayausgaben Progmem und das (F)-Makro, um da wenigstens ein bisschen zu sparen- und es gibt eigentlich nahezu nur noch Byte-Variablen.

Allerdings brauchst du für nen 1:1-Nachbau auch diese kleinen Powerbänke, mit 22mm Durchmesser (die hatte ich seinerzeit gekauft, weil es die echt an jeder Ecke gab).
Aber man könnte das auch so abändern, dass z.B. ein 18650er Akku eingebaut werden kann, mit ner USB-Ladeplatine und nem StepUp-Wandler.

Zitat:

---

Zitat von Rabenauge

Allerdings brauchst du für nen 1:1-Nachbau auch diese kleinen Powerbänke, mit 22mm Durchmesser (die hatte ich seinerzeit gekauft, weil es die echt an jeder Ecke gab).
Aber man könnte das auch so abändern, dass z.B. ein 18650er Akku eingebaut werden kann, mit ner USB-Ladeplatine und nem StepUp-Wandler.

---

ich weisss nicht ob ich einen 1:1 nachbau realisieren kann:

- die powerbänke möchte ich durch einen fest eingabauten lipoakku (oder einen anderen) ersetzen und die rückwand des gehäuses würde ich gerne aus einem solarpanel machen... - weiss nicht ob das geht...

meine fernbedienung wäre ja nicht permanent im einsatz, ist ja nur sowas wie die monitore und tastaturen in "Houston/Texas" bei Opportunity :-)

- über das drucken der teile müssten wir noch reden, mein drucker ist zu klein für solche teile :-(

ich verstehe es nicht - warum mühst du dich mit dem mickerigen Nano ab und verwendest nicht von vornherein einen SAMD21/51 oder einen ESP?

Zitat:

---

Zitat von HaWe

ich verstehe es nicht - warum mühst du dich mit dem mickerigen Nano ab und verwendest nicht von vornherein einen SAMD21/51 oder einen ESP?

---

ich weiss nicht ob ich alle gefunden habe - aber für mich wäre es auch eine preisfrage warum ich mich für einen nano oder micro entschieden hätte...

...weil ich den Nano hier habe.
Und weil ich nichts davon halte, mit Kanonen auf Spatzen zu schiessen.
Und weil er wahrscheinlch die Aufgabe bewältigt.
Und weil ich mit denen ganz gut eingearbeitet bin.

Von den ESP halte ich recht wenig- so lange die nicht _komplett_ dokumentiert sind (was die nicht mal annähernd sind) benutze ich die nur, wenn es _unbedingt_ sein muss. Ausserdem taugen die für analoges Einlesen der Sticks nicht wirklich....kriegt man sicher hin, aber mit unnötigem Aufwand.

Wenn man das Display mal weglässt, ist das Ganze doch eigentlich nur Pillepalle...

@inka: das Gehäuse ist 190mm breit- das kriegt doch eigentlich fast jeder Drucker gebacken?
Mit genug Mut und Enthusiasmus (so wie ner Menge Stützstrukturen, hehe) könnte man die grossen Teile auch aufrecht drucken.
Oder alles mittig zerschneiden und hinterher wieder zusammenkleben...

Und, wie ich früher schonmal sagte: man kann das Ding auch sehr viel kleiner bauen, bei der selben Funktionalität. Meins ist eigentlich nur wegen dem Display so gross- die kleinen I2C-fähigen OLED-Displays, die man für nen Fünfer an jeder Ecke kriegt, haben genau die selbe Auflösung, die lib. braucht weniger Speicher, und das Ding ist nicht mal ein viertel so gross.
Wenn man dann noch, statt der recht grossen Sticks die winzigen Analogsticks der PSP benutzt ->Zigarettenschachtelgrösse.
Dann könnte man das Ding auch mit 3.3V betreiben, der HC 05 kann das, einen passenden Arduino findet man auch, den Sticks isses sowieso recht egal, und die kleinen OLED kommen damit auch zurecht.

Am Schaltplan würde das nich viel ändern (ausser dass eben das Display nich an SPI sondern an I2C hängt, und man ggf. noch ne Akku-Überwachung vorsehen sollte)- die Funtionen könnten genau die gleichen sein, sogar die Grafiken kann man 1:1 übernehmen (die sind halt nur, gefühlt, zehnmal kleiner dann).
Vielleicht bau ich die Mini-Ausführung auch mal, nur so aus Spass...

Zitat:

---

Zitat von Rabenauge

...weil ich den Nano hier habe.
Und weil ich nichts davon halte, mit Kanonen auf Spatzen zu schiessen.

---

das Problem ist nicht, mit "Kanonen" auf Spatzen zu schießen, sondern der Glaube, unbedingt mit Wasserpistolen oder Blasrohren auf Strohhalmbasis das Ziel erreichen zu müssen :p
ein SAMD21=M0/Zero ist IMO der ggT zur Problemlösung, oder ein esp8266 mit ADS1115.

Blasrohre sind halt zuverlässiger...
Mal im Ernst: wenn wir uns nicht angewöhnt hätten, jedes Problem einfach mit geballter Rechenpower zu erschlagen, wären uns Seuchen wie Java erspart geblieben...und Windows inzwischen auch.

Ich find es durchaus interessanter, aus so nem schwachbrüstigen Rechner rauszuholen, was geht.
Die können mehr, als man oft meint- wenn man gescheit programmiert (naja....ich benutz ja auch nur die Arduino-IDE, insofern wäre da noch ne Menge Luft...)
Wenn sich rausstellen sollte, dass das Ding instabil läuft (woran ich _noch_ nicht glaube), dann wird sich ziemlich sicher ein Teensy finden, der das Problem aus der Welt schaffen kann.

Wie gesagt:vom ESP halte ich nicht viel- ich weiss zwar die Vorzüge durchaus auch zu schätzen (ein paar von hab ich auch schon verbaut)- aber ich trau den Chinesen einfach nicht. Wenn die nicht mit der Sprache rausrücken wollen, was der in Wirklichkeit noch alles treibt (deutlich mehr als man ihm sagt, das steht fest)-werden sie ihre Gründe haben...auf solche (möglichen) Sicherheitsprobleme reagier ich bisschen allergisch.

was die ESPs gundsätzlich angeht, hast du ntl Recht. Die ESP-cores und -libs für Arduino werden ja auch nur von einer Community privat "oben drauf" entwickelt, nicht von den Chinesen selber, und daher ist vieles noch komplett unfertig. Aber für "nicht trauen" besteht IMO bei denen kein Anlass, man baut sie ja nicht in sicherheitsrelevante IT Systeme mit Datenverschlüsselung ein.

Hätten die Nanos mehr RAM (8? 16kB?), wäre ja auch nichts gegen solche AVRs einzuwenden, aber 2 oder 2,5k sind einfach lächerlich, die werden ja schon von SPI+I2C fast komplett aufgebraucht, sodass kaum noch was für ein Programm übrig bleibt.
Wenn du den aber nur deshalb nimmst, weil er gerade da ist und du nichts besseres hast: klar, dann würde ich es auch erstmal damit versuchen.

Deinen Seitenhieb auf Windows etc verstehe ich aber nicht, cpus müssen mit den Sofwareanforderungen mitwachsen, genau wie hier, und die Preise dafür sinken ja zusehends - kein Grund also, in der IT-Steinzeit zu verweilen. Oder wolltest du ernsthaft auch noch mit CP/M und MSDOS auf deinem Homecomputer herumwerkeln?

Hm -ich benutz einfach Linux.
Schon seit Jahren... unproblematisch, zuverlässig, sicher und mit _weit_ moderateren Hardwareanforderungen.
Tatsächlich hatte ich mal ein Ubuntu (ich glaub, das war noch das 14er) auf nen "Sperrmüll-Rechner" (sah jedenfalls so aus..) ans laufen gebracht, der nicht mal mit XP flüssig lief- das Ding war so schwachbrüstig, dass ich die LXDE nachinstallieren musste, weil nicht mal Unity auf die Beine kam.
Lief dann aber völlig problemlos und überraschend schnell.
Aber lassen wir das- wird nur wieder ein Glaubenskrieg, und ich muss nix glauben.

Inzwischen hat es noch nen netten Rahmen ums Display gegeben (der den überschüssigen, anders-blau leuchtenden Rand fast komplett verdeckt), einen Einbau-Adapter für den letzten Button und nen neuen Drehknopf auch (den mache ich noch mal neu, der ist zu gross).
Wie ich die Joysticks verblenden soll, grüble ich noch...Anhang 34933

Sieht doch schon ganz nett aus (ich weiss, die Farben..... aber ich nehm, was grade da ist).
Muss mal wieder ein paar Rollen Filament besorgen.

Sodele.
Die Hardware dürfte fertig sein (es sei denn, mir fällt noch irgendwas ein).

Heute hab ich endlich mal die letzte Komponente noch verkabelt-der einzelnen Button.
Der ist mehr als ein simpler Knopf: er hat zusätzlich nen roten Ring eingelegt, der leuchten kann.
Den kann man auch separat steuern- ich werde den also als zusätzliche Anzeige benutzen (z.B. kann man ihn aufleuchten lassen, wenn das BT-Modul sich mit irgendwas verbunden hat).
Sehr praktisch- und sehr hübsch.
Damit ich später auch weiss, ob das BT-Modul sich mit _irgendwas_ koppeln konnte, habe ich die State-Leitung vom HC 05 auch noch an nen Digitalpin getüdelt.

Davon sind jetzt noch zwei Stück frei, hehe:

Code:

---

#define clockPin 13                  // SPI Clock
#define csPin 12                      // Chip-Select Display
#define mosiPin 11                  // SPI-MOSI

#define statusPin 8                    // High, wenn gekoppelt
#define bluetoothPin 7                // schaltet BT-Modul ein oder aus
#define ledPin  6                        // die rote LED im Button
#define buttonPin 5                    // der Button
#define encoderButton 4            // Button Encoder
#define encoderPinB 3              // zweiter Pin Encoder
#define encoderPinA 2              // erster Pin Rotationsencoder

#define lX A0                        // X-Achse linker Stick
#define lY A1                        // Y-Achse linker Stick
#define lB A2                        // Button linker Stick
#define rX A7                        // X-Achse rechter Stick
#define rY A6                        // Y-Achse rechter Stick
#define rB A5                        // Button rechter Stick

---

Aber ein paar analoge wären auch noch da, wenn sie gebraucht würden...

Ein bisschen ärgere ich mich jetzt, dass ich den Button nicht mit blauer Beleuchtung genommen hatte- das rot fällt ziemlich auf, hehe- aber man kanns auch sportlich nehmen und sagen "soll es ja auch".

Die Gehäuseteile sind inzwischen auch alle fertig gedruckt- die Abdeckungen für die Sticks waren grausam: bis die leidlich passten, hab ich sechs oder sieben Probeteile gedruckt...aber nun gehts.

Die kleinen Teile hab ich dann mit dem 3D-Stift kurzerhand von innen ins Gehäuse geschweisst.
Die hatte ich bewusst einzeln gezeichnet, und zwar so, dass man sie einsetzen, aber ein wenig hin und herschieben kann- so kann man alles schön anpassen, ohne die gesamte Abdeckplatte 15x zu drucken.
Dadurch, dass sie ihre Öffnungen aussen überlappen, sieht man davon jetzt nichts mehr.

Als nächstes muss jetzt der neue Button auch noch ne Anzeige im Display bekommen, keine grosse Sache: halt nen Kreis, der gefüllt dargestellt wird, wenn man den Button drückt- so ähnlich wie beim Encoder, nur ohne Wert in der Mitte eben.

Wenn die da ist, mach ich wiedermal ein Foto.

Hab eben mal eine Art kleines Video gemacht, von den bisherigen Funktionen.

Klick

Inzwischen bin ich noch ein kleines Stück weiter:
nach dem Einschalten werden die Sticks, nach einer kurzen Wartezeit, kalibriert (Wartezeit, damit man die Pfoten weg nehmen kann, das steht auch im Display), so weit waren wir schon.
Anschliessend fängt der Button an, zu blinken...solange er das macht (einige Sekunden) kann man ihn drücken, und damit die Fernsteuerung in den USB-Modus versetzen: das Bluetooth-Modul wird dann abgeschalten (genauer gesagt, gar nicht erst an), und man kann flashen, oder die seriellen Ausgaben im Monitor verfolgen. Dort kommt dann genau das an, was normal auch per Bluetooth gesendet würde...

Drückt man den Button nicht, wird ganz normal durchgestartet und das BT-Modul eingeschaltet.
Ich denke,das ist so ausreichend praxistauglich: wenn ich das Ding einfach nur benutzen will, schalte ich sie ein und muss mich nicht weiter drum kümmern.
Will ich in den USB-Modus, drücke ich halt mal den Button....

Insgesamt haben wir jetzt also vier analoge Kanäle, drei völlig frei verwendbare Buttons, zusätzlich nen Encoder, der quasi-analog arbeitet (tut er nicht, aber er kann, genau wie die Sticks, Werte zwischen 0 und 255 erzeugen), und den Button des Encoders, der allerdings den Encoder-Wert wieder auf 0 stellt. Daher ist der als Button nur eingeschränkt zu verwenden (wenn man den Encoderwert nich braucht, ist es kein Problem).
Ich denke, damit kann man erst mal eine ganze Menge anfangen...

Ein bisschen hab ich mal weiter codiert:
Es werden jetzt alle Werte tatsächlich auch per BT gesendet, in der Form:
lX128-> X-Achse links hat den Wert 128.
Auf die Weise geht das mit relativ wenigen Daten von statten-es werden _nur_ Änderungen gesendet.
Wenn man nix tut, dann nicht....
Die Auswertung auf der Gegenseite steht noch aus....ich denke aber, sehr schwierig wird das nicht.

Inzwischen merkt die Fernsteuerung auch, wenn sie sich mit irgendwem verbinden konnte (so lange sie das nicht hat, gibts ne Art "Fortschrittsbalken" im Display.
Ermittelt wird das über den STATE-Pin des HC-Moduls.

Das Nächste wird jetzt sein, dass sie, nach erfolgter Koppelung, die Gegenstelle fragt "wer bist du"- ich möchte den Namen des verbundenen Roboters dann im Display stehn haben.
Dazu brauch ich dann aber auch für den "Roboter" erst mal ein Software- Grundgerüst- momentan besteht der lediglich aus nem, neben das Steckbrett gespaxten Uno und einem weiteren HC 05-Modul, was lediglich per AT-Befehle passend konfiguriert ist.

Verbinden klappt-aber mehr kann das noch gar nich...allerdings hab ich die Tage schonmal einen kleinen Parser gebastelt, der Kommandos, die von der seriellen Schnittstelle kommen, auswertet-der muss aber noch aufgebohrt werden, um z.B. die Zahlen aus den eintreffenden Strings extrahieren zu können.

So nebenbei steigen meine Skills im RAM-Sparen, hehe: um diesen Fortschritts-Balken realisieren zu können (es werden einfach 1,2,3,4 Sternchen gezeichnet, und dann fängts von vorne an), brauchte ich ne Variable als Zähler-da hab ich kurzerhand eine der globalen, die an _dieser_ Stelle nicht gebraucht wird, mal eben ausgeliehen.
Somit _kein_ zusätzlicher Speicherverbrauch *freu

Zitat:

---

Zitat von Rabenauge

Ein bisschen hab ich mal weiter codiert:
Es werden jetzt alle Werte tatsächlich auch per BT gesendet, in der Form:
lX128-> X-Achse links hat den Wert 128.
Auf die Weise geht das mit relativ wenigen Daten von statten-es werden _nur_ Änderungen gesendet.
Wenn man nix tut, dann nicht....
Die Auswertung auf der Gegenseite steht noch aus....ich denke aber, sehr schwierig wird das nicht.

---

hallo,
ich halte das für u.U. bedenklich bzw. gefährlich:
Folgender Fall:
wert lX128 gesendet und empfangen => alles ok, Empfänger führt entspr. Befehl aus (z.B. Motor links auf pwm128 )
danach
wert lX0 gesendet aber wegen Unterbrechung oder Block (Serial stream/buffer hardware/software sync/async wire/wireless) nicht empfangen => Empfänger führt immer noch entspr. alten Befehl aus (Motor links auf pwm128 statt 0), da sich für ihn nichts geändert hat.

Ganz abgesehen davon ist es ebenfalls denkbar, dass einzelne Bytes (l,X,1,2,8 ) durch Datenkorruption falsch übertragen bzw. empfangen werden - wie prüfst du auf Datenintegrität und korrekten Empfang? z.B.
wert lX128 gesendet aber wegen Datenkorruption falsch empfangen => Empfänger liest lY128 (anderer Motor auf pwm128 ) oder noch was ganz anderes
(edit: das müsste dann auf heartbeat und timeouts gecheckt und nach Rückmeldung auf Richtigkeit und Vollständigkeit überprüft werden; weitere Stichworte sind message-Startsignal, Ende-Signal, msg-Länge, checksum)

Zur Not kann er noch ein Paritätsbit mitsenden und auf der Gegenseite prüfen. Sehr genau beschrieben ist das hier: https://de.wikipedia.org/wiki/Parit%C3%A4tsbit
Eventuell kann das einfach so umgesetzt werden, dass man nur halbe Wertebereiche überträgt und das höchstwertige Bit als Paritätsbit verwendet.
Sollte kein Problem sein.


MfG

Heartbeat ist schon vorbereitet.
Ich habe schon einen Timer drin, der alle halbe Sekunde einen Tick erzeugt (den setze ich wahrscheinlich noch deutlich runter, in der Zeit), denn es stimmt: wenn das Stop-Signal nicht ankommt, fährt er endlos weiter.
Die HC 05 merken auch erst nach ungefähr zehn Sekunden, wenn die Verbindung weg ist-> zu lange.
Ich will also (wie gesagt, vermutlich wirds am Ende mindestens viermal pro Sekunde passieren) ein "alive" senden, und wenn das, sagen wir, zweimal, nicht kommt, weiss der Empfänger, dass da was faul ist, und kann sein fail-save aktivieren.

Auch richtig: gegen verstümmelte Signale hab ich noch nix...hat aber nicht das BT-Protokoll da sowieso was eingebaut?

Aber gut, dass der Einwand kam, ich werd das beim ausprobieren (vorerst sowieso nur trocken, mit dem UNO als Prügelknaben) mal im Auge behalten.