XPlorer 2

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

[inka]

klar darfst du dich einmischen

wenn ich es richtig verstehe, misst du mit drei kombinationen von IR sender und empfänger den abstand schräg zum boden. Wenn dieser sich abrupt ändert -- grösser == loch, kleiner == hindernis -- weichst du aus, stoppst oder was auch immer...

- gab es da keine störungen der kombinationen untereinander?
- liesse sich das auch mit ultraschall lösen? IR ist draussen wohl nicht die erste wahl, oder?

btw. ich habe deine colabüchse schon damals bewundert

[Rabenauge]

@inka: nein, derartiges ist auch gar nicht vorgesehen.
Der XPlorer2 soll ja quasi nur ein FPV-Vehikel (allerdings nachttauglich) werden.

Die IR-Cut-Kamera, die ich habe, funktioniert auch im stockdunklen _ausreichend_ gut, dass man eine Treppe bemerken sollte, ehe man runter fällt.
Wenn s vom Platz her noch geht, will ich die auch schwenkbar (in X ) machen, so dass man etwas nach oben/unten schauen kann.
Idealerweise sogar stabilsiert (weiss ich noch nicht, ob das klappen wird).
Mehr kriegt der nicht.

[oberallgeier]

.. Wenn dieser sich abrupt ändert -- grösser == loch, kleiner == hindernis -- weichst du aus, stoppst oder was auch immer ..

Sozusagen. Es gibt natürlich Regeln: Mittensensor spricht an => weiche nach rechts aus <=> wenn Sensor rechts NICHT auf freie Fahrt steht, weiche nach links aus und <=> wenn links auch besetzt ist, dann fahre mal ne viertel Kreisbogen zurück und versuchs nochmal. !!! Das Zurückstoßen ist kritisch - da gibts keinen Sensor, es wird einfach blind zurückgefahren.

..
- gab es da keine störungen der kombinationen untereinander? ..

Ne. Eher wenig bis kaum, aber siehe unten.
Einmal senden die IR-Dioden in verschiedene Richtungen - entsprechend der IR-typischen Lichtkeule. ABER primär: Es werden die drei Sensoren nur umlaufend abgefragt. Wenn einer sensoriert haben die andern Pause. Das geht folgendermaßen. ALLE IR-Diode werden zur Abfrage gechirpt. Z.B. - es werden alle drei gleichzeitig gechirpt, aber nur ein IR-Empfänger wird abgefragt. Chirpen bzw. CIR - siehe hier (danke an Sterntaler). Ich versuchs kurz zu erläutern: die IR-LED(s) werden per PWM betrieben.
Anm.: Soweit ich mich erinnere gaben PWMs über 128 manchmal ähnliche Ergebnisse wie PWM (256 minus aktueller dc - so ne Art komplementäre Signalform).

1ter Schritt: Die IR-LED sendet einen Burst (mehrere Pulse) mit duty cycle dc-64. Abfrage mit Empfänger: Antwort da oder nicht.
......o Empfänger sagt "da": Der Burst war zu "stark" = duty cycle zu lang => nächstes Mal Pulse schwächer=kürzer, also Ddc-alt)-32.
......o Nicht da: Der Burst war zu "schwach" = kurz => nächstes Mal Pulse stärker=länger, also (dc-alt)+32
2ter Schritt:
....a) PWM sendet dc-32 (dc-alt)-32. Abfrage mit Empfänger: Antwort da oder nicht.
......o Da: Der Puls war zu "stark" = lang => nächster Puls schwächer=kürzer, also dc-16.
......o Nicht da: Der Puls war zu "schwach" = kurz => nächster Puls mit dc-48.
....b) PWM sendet dc-96 (dc-alt)+32. Abfrage mit Empfänger: sinngemäß wie oben
3ter Schritt: hier wird sinngemäß weiter nach dem "zu schwachen" letzten Puls gesucht - aufwärts zu 128 oder abwärts zu PWM DC-1 - immer mitten zwischen zwei mögliche Werte. Somit ist man nach wenigen Schritten (hier nach sechs) bei der richtigen Pulslänge bis zum Erkennen des "richtigen" Messwertes - es sei denn, die Entfernung (Reichweite) ist über- oder unterschritten.

Fehler sind natürlich möglich. Wenn die Coladose sehr schräg an eine fallende Stufe fährt (oder Tischkante) kann sie runterfallen. Eher bei Vorwärtsfahrt aber auch z.B. wenn mal die Rückwärtskurve zur falschen Seite erfolgt . . . Aber bei Vorführungen fuhr miniD0

..
- liesse sich das auch mit ultraschall lösen? IR ist draussen wohl nicht die erste wahl, oder? ..

Hmmm, der grundlegende Sensoraufbau sollte ähnlich funktionieren, aber dann wohl nur mit jeweils nur einem Sensor gleichzeitig und ner Zwangspause zwischen zwei Abfragen damit nicht Echos von fernen Gegenständen die Abfrage des jeweiligen Sensors stört . . . (mal so auf die Schnelle formuliert).
Klar, IR ist draussen nicht wirklich die erste Wahl weils verschmutzt. Die IR-Empfänger sind draussen auch verwendbar - es wird ja mit jeweils 36 kHz gepulst und man muss einige (bei meinen Empfängern mind 6) Pulse abwarten bis der Empfänger das Ergebnis "glaubt"

.. btw. .. colabüchse ..

Danke. Mir gefällt das schicke Dingelchen auch. War ursprünglich entwickelt worden . . . aber das dürfte ja bekannt sein. Die kleine miniD0 - nur 0,15 Liter <=> D=54mm, H=80 - habe ich mitunter vorgestellt als sich selbst servierende Getränkebüchse. Sozusagen Prototyp zur Neuentwicklung der Getränkefirma.