XPlorer 2

[Defiant]

Wegen der Fernsteuerung: Das du mit relativ wenig Aufwand einen gekauften Game-Controller per Bluetooth an einen rpi anbinden kannst, ist dir bewusst? Du könntest vor allem das Nebenprojekt Fernsteuerung vermeiden und dich auf dem Roboter an sich konzentrieren.

[Rabenauge]

Ja- weiss ich.
Wobei "wenig Aufwand"...ich hab so ein Ding hier- der funktioniert mitunter wochenlang _nicht_ (verbindet sich nicht), dann geht er mal wieder einige Monate (zugegeben, das ist so'n 20€-Ding), der funktioniert, wenn ers denn tut, mit Handy, Tablet und dem Laptop- im Moment aber nur mit dem Handy.

Der Pi soll aber später nich per Bluetooth, sondern per Wlan gesteuert werden-der Reichweite wegen.
Und: der Pi ist noch gar nicht an Bord.
Wie ich ja schon schrieb, soll das mein Einstiegsprojekt für Raspberry-Programmierung werden- das wird also dauern, bis die Fernsteuerung per Pi dann auch läuft.

Mit dieser Fernsteuerung hab ich zum einen die Möglichkeit, das Fahrwerk schonmal gründlich auszuprobieren (und zwar auch draussen), und zum anderen hatte ich schon öfter Basteleien, wo ich mir so eine Fernsteuerung gewünscht hätte. Da hab ich mir dann mit RC-Fernsteuerungen (sowas hab ich ausreichend rumliegen) mehr oder weniger beholfen.

Ich sehe einfach ein paar Vorteile in so einer Universal-Fernsteuerung: da alles über simple serielle Kommandos läuft (und zwar in beide Richtungen!) ist die sehr simpel zu programmieren, kann aber so ausgelegt werden, dass sie enorm viele Möglichkeiten bietet (die man bei einer RC-Fernsteuerung erst mit höherem Aufwand oder gar nicht haben kann). Beispielsweise lassen sich die Steuerkomandos (welche Eingabe was bewirkt) in den jeweiligen Robotern hinterlegen, so dass sie nach dem Pairing automatisch richtig eingestellt wird (Stickmode z.B.), man kann recht einfach beliebige Telemetriedaten übertragen, usw), man hat beliebig viele "Kanäle" zur Verfügung....und da Ganze für, na sagen wir mal 30 Mäuse (dafür kriegt man im RC-Bereich nicht viel vernünftiges).

Und da der XP2 im Slave-Modus arbeiten wird, brauch ich da nur ne vierpolige Buchse einbauen (seriell&Strom, mit Levelshifter), die ich später für die Kommunikation mit dem Pi gleich weiter benutzen kann.
Das soll ja auch seriell laufen, wenn ich es also clever genug anstelle, brauch ich später nicht mal die Firmware auf dem Nano ändern, sondern einfach nur das BT-Modul gegen den Pi austauschen.
Der muss dann nur die selben Kommandos schicken, wie die BT-Fernsteuerung....ich bau also am XPlorer nichts um, was ich nicht sowieso noch machen müsste.

Und hab später, als Bonus, noch diese Fernsteuerung für den XP3 (falls es den geben wird, aber einige Anzeichen am Horizont deuten drauf hin).
Für andere Basteleien auch....die ist also ne Langzeit-Investition.
Sicher für andere auch interessant...

[inka]

Für andere Basteleien auch....die ist also ne Langzeit-Investition.
Sicher für andere auch interessant...

auf jeden fall! Einen extra thread aufmachen?

[Klebwax]

Was haltet ihr von dem Entwurf- besonders unter Berücksichtigung der Tatsache, dass diese Fernsteuerung möglichst universell sein soll?

Ich beschreibe mal, was ich mir ausgedacht und zum Teil auch schon realisiert habe.

Als Funk benutze ich Wlan. Für die vielen bei mir vorhandenen Geräte ist es sowieso da. Sollte es im Freien nicht jeden Punkt erreichen, rüste ich mit einem Outdoor-AP zur Not nach.

Der Anschluß an mein LAN ermöglicht es, daß jeder Rechner mit dem mobilen Teil über das gleiche Medium kommunizieren kann. Das war für mich eine wichtige Überlegung. Die Protokolle sind zwar komplex, sie sind aber vorhanden und ich muß mich nicht wirklich darum kümmern. Auf einem Rechner habe ich Sockets, die kann ich aus C, Javascript, Python oder eigentlich jeder Sprache direkt ansprechen. Und sollte ich da mal Probleme haben, stehen bei mir ein halbes Dutzend Bücher im Regal. Praktisch ist das möglich geworden, seit es die ESP preiswert gibt. Auch dort muß ich mich nicht um die Komplexität von (W)Lan kümmern. Ich kann dort auf das bekannten Konzept der Sockets aufsetzen.

Was bietet das für Vorteile? Eine (W)Lan-Verbindung bietet prinzipiell die Möglichkeit, mehrere Kommunikationskanäle gleichzeitig und in jeder Richtung zu nutzen. Über den einen Socket kann ich Fernsteuerkommandos schicken, währen über einen anderen Socket z.B. Telemetriedaten an einen Server in meinem Netz gehen. Und der Programmieraufwand hält sich in Grenzen, einen Socket auszulesen und die Daten in einem für Gnuplot oder Excel passenden Format in eine Datei zu schreiben ist in wenigen Zeilen gescriptet.

Jeder Rechner kann die Funktion des "Fersteuersenders" übernehmen, interaktiv oder als Programm. So lässt sich eine automatische Steuerung realisieren. Zusammen mit der Möglichkeit des Rückkanals kann sie auch intelligent sein. Es kann während der Entwicklung auch die größere Rechenleistung eines PCs genutzt werden.

Nun fehlt nur noch ein "richtiger" Sender. Ich hab mir einen gebastelt.



Das ist ein ESP mit einem Akku und einem Nunchuk als Steuerknüppel. Ich hab mal an anderer Stelle einen meiner Prototypen gezeigt. Für die ersten Versuche hab ich dort den Nunchuk direkt angeschlossen, später kamen die Nunchukdaten über Wlan. Die nächste Platine des Senders wird dann in ein Gehäuse passen.

Wie ist das mit dem ESP realisiert? Im Prinzip kann man die SW, die von Hause drauf ist, verwenden. Die ganze Wlan Angelegenheit kann man, wie bei einem klassischen Modem, über AT-Kommandos auf der seriellen steuern. Ich bin kein großer Fan der AT-Schnittstelle. Ich habe daher eine Art allgemeines Wlan-Modem auf der lua-Firmware für den ESP programmiert. Die Kommunikation läuft dort bidirektional, die Parameter wie die IP-Adresse werden über die gleiche serielle eingestellt. So kommt es als Empfänger zum Einsatz. Für einen Sender, der keinen eigenen µC hat, kommt dann noch I2C für den Nunchuk dazu. Für aufwändigere Sendern, den Umbau eines alten RC-Senders z.B., kann man die die gleiche Firmware wie im Empfänger verwenden und einem µC die Arbeit überlassen.

Soweit mein Konzept. Die ESP sind so billig, billiger als eine RJ45 Buchse mit eingebautem Trafo, daß ich auch eigentlich stationäre Steuerung wie Rollläden so ansteuere. Die Firmware auf dem ESP bleibt (im Wesentlichen) immer die Gleiche. Sie passt auch in den Flash eines ESP-01. Wenn ich auf einer µC-Schaltung, die ich baue den Platz für die 8-Polige Stiftleiste übrig und einen UART frei habe, layoute ich das mit rein. Später fällt einem möglicherweise eine Anwendung dazu ein oder man bestückt es nicht.

MfG Klebwax

P.S.

Wie ich grad sehe, hast du ähnliche Überlegungen angestellt.

[Rabenauge]

Cool.
Allerdings..ein bisschen mehr möchte ich haben (an Bedienelementen).
Etwas cooler aussehen darfs auch, hehe..die Idee kam mir bei James Bruton.
In der Playlist zum openDog taucht sowas gelegentlich auf....ich kann nur nicht begreifen, wieso der es nicht geschafft hat, da nen Akku einzubauen (das Gemurkse mit der Powerbank da unten drunter ist gruselig).
Der hat übrigens die grossen 3-achsigen Sticks verbaut, die ich etwas weiter oben erwähnte. Würd es sowas in deutlich kleiner (und bezahlbar) geben, wären die ne bessere Wahl. Aber die Monster sind mir zu klobig...

Mein Problem ist: WLAN ist mir zu..."gross" für den Moment. Ich hab schon einiges mit Wifi-Modulen (ESP..) gebaut, und das funktioniert auch, aber ich bin weit davon entfernt, zu behaupten: ich kann sowas.
Der XP(1) hatte einen NodeMCU als Funkempfänger.
Da hab ich mit Müh und Not (so schlimm wars auch wieder nicht, es hat funktioniert) ne Steuerung per Handy hinbekommen.
Bei der Telemetrie bin ich gescheitert....

Bluetooth ist ganz einfach: was du vorne rein schiebst, kommt hinten auch wieder raus.
Was du hinten rein schiebst, kommt vorne raus.
Ende der Geschichte.
Funktioniert so easy, wie z.B. ein Nextion-Display.
Und so ein Ding läuft bei mir inzwischen seit..hm, zwei Jahren bestimmt.
Krieg ich also zeitnah hin.

@Inka: können wir machen, klar!

[Klebwax]

Mein Problem ist: WLAN ist mir zu..."gross" für den Moment. Ich hab schon einiges mit Wifi-Modulen (ESP..) gebaut, und das funktioniert auch, aber ich bin weit davon entfernt, zu behaupten: ich kann sowas.

Mit Sockets. d.h. TCP/IP von PC zu PC hatte ich schon Erfahrungen. Da kann man auch schön Testen, z.B. mit Wireshark und netcat. Ob die Rechner über Ethernet oder Wlan am Netz hängen ist dabei gleichgültig. Mit Wlan selbst oder dem TCP-Stack auf einem PC habe ich nichts gemacht, es nur benutzt. Auf dem ESP habe ich mir eine Marscherleichterung gegönnt und die lua Firmware benutzt. Das Programmieren direkt auf dem SDK war mir zu aufwendig und eine Arduino Umgebung gabs da noch nicht. lua kannte ich schon (wobei so gradlinige Sachen fast so aussehen wie in anderen Sprachen auch) und das Wlan wird auch dort über Sockets angesprochen.

Wenn man Sockets einmal kapiert hat, kann man sie auf jedem vernetzten Gerät einsetzen, ob mit oder ohne Kabel. Man muß ja dabei nicht jeden Trick anwenden. Und ein Linuxrechner wie der PI kann das natürlich auch von Hause aus. Für ein größeres Teil würd ich möglicherweise auch auf den ESP verzichten und gleich mit dem PI über Wlan reden. Da muß dann im Sender noch nicht mal was verändert werden.

Der ESP hat ja nicht viel IO. In der lua Firmware kann man einen I2C Treiber haben, da wars leicht einen Nunchuk an zwei IOs zu schalten. Hat man aber im Sender einen eigenen µC und benutzt den ESP nur zum Senden, kann man alles anschließen, Joysticks, Schieberegler und Schalter jeder Größe und Form. Packt man noch ein Display ran, kann man Telemetriedaten direkt anzeigen. Da sie im Netz verfügbar sind, kann sie ein Rechner dort zusätzlich aufzeichnen. Die Flexibilität, die sich daraus ergibt, daß die Daten überall in meinem Netz verfügbar sind, war mir wichtig. Und zum Debuggen kann man immer etwas nehmen, das ein volles Display und mächtige Tools hat.

MfG Klebwax

[Rabenauge]

Ich bin da anspruchsvoll.
Der XP(1) hat natürlich ne eigene, selber gebaute App- wenn auch "nur" mit dem MIT App-Inventor zusammengebastelt, aber besser als diese ganzen Blinkys usw (bei denen weiss man nie, was die noch alles treiben).

Der XP2 soll auch ein grafisches Interface bekommen, und daher weiss ich: das _wird_ dauern!
Der Plan sieht vor, ein Programm (eben mit grafischer Oberfläche) direkt auf dem Pi laufen zu haben- und dann mittels VNC von _irgendeinem_ Endgerät darauf zuzugreifen.
Bis zu dem Punkt bin ich auch schon, ich komme per Handy, Tablet oder Laptop auf den Pi Desktop.

Bluetooth ist halt kinderleicht: einfach seriell senden, was immer man senden will-das funktioniert in beide Richtungen.
So kann man beliebige Kommandos hin- und beliebige Telemetriedaten zurückschicken.
Die Fernsteuerung wirft die einfach nur aufs Display, die muss nicht mal verstehen, was sie da bekommt.
Der Roboter braucht nur nen String zu senden "Akku: 4.5V"- und schon steht das _genauso_ auf dem Display- einfacher gehts nicht.
Fahrkommandos kann man genauso einfach senden:
"X=255", und dann den Wert aus dem String extrahieren.
Sowas hab ich in ner Woche zusammengebaut- bei der Pi-Anwendung werden das Monate...

Lua- neee..nix für mich....ich hab schon ne gewisse Abneigung gegen Python ( Java verursacht Krämpfe, hehe)...ich bin mir recht sicher, dass ich es auf dem Pi mit C versuchen werde.
Python wäre Plan B....

[Rabenauge]

Erfolgserlebnis:
eins der HC-05-Module hab ich heute in den XPlorer eingebaut- schön, mit nem Levelshifter, sicher ist sicher (man sagt, die vertragen auch auf der Logik die 5V problemlos)- aber spätestens für den RasPi brauch ich dann ja sowieso 3.3. Also kann ich den auch gleich einbauen...

Blöd dabei war: der Levelshifter hat vier Leitungen, und die sind so angeordnet, dass auch die EN-Leitung vom BT-Modul mit am Levelshifter angesteckt war.
Eingestellt hatte ich das Modul vorher mit nem Arduino UNO, einem sehr simplen Programm (im Grunde werden da nur Eingaben der seriellen Konsole zur zweiten seriellen Schnittstelle durchgereicht und umgedreht), schön in den Slave-Mode, Passwort und Name angepasst...und es lief auch.
Als ich den XPlorer einschalte, blinkte es langsam...
Es war dauernd im AT-Mode!
Hat bissel gedauert, bis ich drauf kam: der Levelshifter hat Pullups drauf!
Vorerst hab ich also kurzerhand die EN-Leitung gekappt, mir fiele jetzt nichts ein, wofür ich die sinnvoll im XPlorer benutzen könnte, daher gibts auch keinen Grund, die bis zu nem Pin weiter zu führen (mit dem ich dann zwischen AT- und BT-Modus umschalten könnte).

Inzwischen sitzt der zweite HC 05 am UNO auf dem Steckbrett- als Master konfiguriert, und beide verbinden sich direkt nach dem einschalten.
Klappt wunderbar....den XP2 hab ich inzwischen mehrere Runden durch die ganze Wohnung getragen, die Verbindung bricht nirgends ab (auch nich, wenn ne Betonwand dazwischen ist und geschlossene Türen)- super.
Da haben wir draussen ganz sicher mehr als 10m..es wird mir genügen.

Als nächstes werd ich jetzt mal ein bisschen Code schreiben, der irgendwelche "Nutzdaten" hin und herschickt. Mal gucken, ob das genauso einfach ist (die dann auch auszuwerten, vor allem)- aber ich denke schon.

Was die Fernsteuerung angeht: ich bin nochmal gründlich in mich gegangen und hab mich entschieden: es wird erstmal nur _einen_ zusätzlichen Button geben.
Der kriegt aber dafür nen interupt-fähigen Pin.
Den anderen Interruptpin brauch ich halt für den Drehencoder (der nicht verhandelbar ist, auch wenn ich den, um den XP2 probezufahren, nicht brauchen werd).
Die beiden analogen Sticks haben ja auch noch Buttons drin, beim Encoder weiss ich es grade nicht (der ist auf dem Weg zu mir, zusammen mit dem anderen Kram, aber eben noch nicht da), ich hab also sowieso drei Buttons.
Dazu XYLinks und XYRechts, und den Drehencoder- fürs Erste genug.
Man kann ja zusätzliche Funktionen trotzdem problemlos reallisieren, über ein Software-Menü, wenn nötig.
Oder den separaten Taster als "Shift-Taste" nutzen....
Auch ein Umbau auf mehr Buttons (falls sich dazu ne Notwendigkeit ergeben sollte) ist nachträglich kein Problem.

Warum abgespeckt: ich hab mich an die Krämpfe erinnert, die mir jedesmal bevorstehen, wenn ich meine MX-RC-Fernsteuerung mal wieder (ich benutz die nur noch selten) in die Hand nehme: ..zig Funktionen auf zwei Sticks und sechs Schaltern überall verteilt- kein Mensch merkt sich das über längere Zeit.
Jedes Mal, wenn ich die brauche, muss ich erst ne Stunde üben, die Fernsteuerung richtig zu bedienen *grusel
Weniger ist mehr.

Aber vielleicht baue ich noch einige programmierbare RGB-LED's ein, die ich dann als Statusanzeigen für "irgendwas" benutzen kann.
Hab da noch nen paar schöne, grosse in 8mm irgendwo rumschwirren....aber SMD (5050) auch massenhaft.

[inka]

gut, dass es so funktioniert

bei den vorgängern des outdoor's roboters habe ich auch schon "datenübertragung" über BT realisiert, in anführungszeichen deshalb, weil es sich dabei in allen fällen um übertragung zwischen PC und dem MEGA gehandet hat, in den meisten fällen ging es um meldungen des roboters an den PC, also im seriellen monitor, aber auch ums fernbedienen - da allerdings vom smartphone aus.

Die versuche, den arduiono über BT zu programmieren sind - auch wenn es im netz viel darüber zum lesen gibt - allesamt gescheitert. Siehst Du da einen weg?

Eine andere frage: Hast Du Dir schon überlegt, wie Du verhindern willst, dass dein roboter in ein plötzlich auftauchendes loch (oder eine stufe z.b.) fällt?

[oberallgeier]

.. Hast Du Dir schon überlegt, wie Du verhindern willst, dass dein roboter in ein plötzlich auftauchendes loch (oder eine stufe z.b.) fällt?

Da geb ich mal meinen Senf dazu.

Diese Frage nach dem "Treppenende" oder Absturz hatte ich mit einem Sensoraufbau der Familie "Blindenstock" gelöst. Dazu hier ein Posting zu den ersten Überlegungen, hier die (erste funktionierende) Lösung mit/auf der 0,33-l-Dose, hier die Lösung mit/auf/in der 0,15-Liter-Dose "minid015" und noch´n Video von nem Testlauf . . .

Der wesentliche Trick dabei ist, dass der von "oben" - etwa 100 mm über Fahrbahn-(Tisch-)Oberfläche schräg nach vorn-unten testende IR-Lichtstrahl durch ein Fenster drei Abschnitte definierte: Nahfeld bei etwa 50 mm..60 mm : alles drunter ist "unmittelbare Crashgefahr", Fernfeld ca > 200 mm : alles drüber ist Absturzgefahr - dazwischen ist im Rahmen diese Abstände freie Fahrt. Weitere Abstände könn(t)en gesondert erfasst werden.