RC-Auto ohne RC-Monstertruck autonom

[HannoHupmann]

Hast du dir mal Gedanken über die Laufzeit deiner Sensorsignale gemacht?

Der Erklärbär sagt: Laufzeit bedeutet die Zeit von: "Hindernis erkannt" bis "Rumms" die ist direkt abhängig von a) ab wann kann der Sensor ein Hindernis erkennen und b) mit welcher Geschwindigkeit fährt man darauf zu. Also z.B. erkennen ab 1m und 1m/s ergibt 1sec für a) Auswertung & Verarbeitung der Sensorsignale und b) korregierende Maßnahmen: ausweichen und oder bremsen (hier gilt es die Massenträgheit zu beachten).

Da Roboter in der Regel in der Wohnung nur sehr langsam herumfahren ist das Problem der Laufzeit nicht relevant. Bei outdoor Robotern die doch öfters auf beachtliche Geschwindigkeiten kommen wird das Thema schon spannender.

[Rabenauge]

Ja, hab ich. Und das wird etwas knapp, da mit ungefähr 4m/s Geschwindigkeit zu rechnen ist.
Daher verzichte ich momentan auch drauf, die vorderen Sensoren wirklich zu filtern, oder gar-wurd mir auch schon vorgeschlagen (und ich würds auch machen, wenn die Zeit reichen würde) da einen LongRange-Modus zu nutzten, und wenn der was meldet, genauer zu gucken.
Glücklicherweise reicht etwa ein Meter, um vor nem Hindernis abzudrehen, auch bei höherer Geschwindigkeit, als ich sie momentan fahre (die jetztige ist das minimalste, was auch in niedrigerem Gras noch geht), daher brauch mich mir da nicht viele Sorgen machen aber- schnell gehn muss es trotzdem.
Vermutlich wird dadurch deutlich öfter "ausgewichen" wegen Fehlalarm, aber da bei jedem Schleifendurchlauf eh korrigiert wird, wird sich das bei Fehlalarmen nicht wirklich auswirken. Erleichternd kommt noch hinzu, dass die Lenkung bauartbedingt soo präzise ohnehin nicht ist: dúrch die grossen Räder ist Geradeauslauf schon keine Stärke des Monsters, und der Servosaver ist auch relativ weich.
Als es noch per RC unterwegs war, hatte ich nen Hubschrauber-Kreisel drin, damit fuhr es dann allerdings auch auf richtig grobem Untergrund wie auf Schienen.

Die momentane Strategie sieht folgendermassen aus: aus den Ergebnissen der Kursberechnung (Sollkurs vom GPS, Ist-Kurs vom Kompass) werden notwendige Lenkmanöver berechnet. Dann werden die beiden vorderen US-Sensoren abgefragt, deren Werte "verunschärft" (ich teil sie momentan einfach durch 5, nicht besonders clever aber wirkungsvoll), da Rauschen unterdrückt wird), und dann verglichen.
Nun wird das vom Kursrechner ermittelte Lenken kurzerhand überschrieben, je nachdem, wo mehr Platz ist. Melden die Sensoren nix, wird auch nix überschrieben, und die Kurssteuerung ist aktiv-aber so hat das ausweichen immer Vorrang.
Optimal ist das nicht, denn _wenn_ man (es ist unwahrscheinlich, aber möglich) die beiden Sensoren zum selben Ergebnis kommen, knallts.
Dagegen muss noch was unternommen werden, das ist klar, aber ich hab die Möglichkeit, so erstmal zu testen, wie diese Strategie sich schlägt.
Heute, hoffe ich...

[The Man]

Ah, du benutzt einen elektronischen Kompass? Unerstützen die uBlocks nicht eine Nachricht mit aktuellem Kurs? Gut, der ist natürlich im Stillstand und zu geringer Geschwindigkeit falsch. Aber die GPS Maus kann aus einer Ist- und einer Zielposition einen Sollkurs berechnen?
Mist, hab ich damals wohl nicht nach geschaut und die Zielabweichung im Controller berechnet mit ner LUT für den ArcTangens und einer spezialisierten Divisionsroutine.
Die Kursabweichung hab ich einfach bearbeitet und auf den Lenkservo gegeben, k.A. ob P-I oder sogar nur P - zu lange her.

[Rabenauge]

Klar kann das UBlox auch den aktuellen Kurs errechnen.
Aber wie du schon sagtest: im Stand _überhaupt nicht_ (da ist nicht mal eine Info zu bekommen, in welche Richtung wir "schauen") und bei langsamer Fahrt klappt es auch erst nach etlichen Metern. Dann aber noch immer recht unbrauchbar: ohne weitere Tricks (ppp kann das Neo-6m ärgerlicherweise nicht) hat man eine maximale Genauigkeit von 2m. Bei einer Fahrstrecke von, sagen wir mal 10m kannst du dir leicht ausrechnen, wie "genau" da ein Kurs überhaupt berechnet werden kann: nahezu unbrauchbar.
Durch den Kompass hab ich aber bereits vor dem Losfahren eine völlig ausreichende Orientierung- das Auto kann schon bevor es überhaupt fährt, in die richtige Richtung lenken (und das tut es auch, bzw. zeitglich mit dem losfahren)- und das stimmt dann auch.
Zwar hat auch der HMC5883l ein bisschen Abweichung (er schwankt im Bereich von 3-5 Grad bisschen) aber das macht nix, das genügt völlig um nen Zielpunkt zu finden. Wäre noch besser möglich, wenn man das Ding weiter weg von der restlichen Elektrik montieren würde-aber aus optischen Gründen (da bin ich bissel starrköpfig, es muss gut aussehen) wollt ich auch den Kompass unbedingt unter der Karosserie haben- keine 20 cm weg von einem der Fahrmotoren also. Hab ihn aber ganz ordentlich kalibriert bekommen.

Der Sollkurs dagegen wird natürlich aus den GPS-Daten (den aktuellen Positionsdaten und dem vorgegebenen Zielpunkt) errechnet, ebenso die Entfernung. Aber gesteuert wird der Kurs halt nach dem Kreisel, da das einfach besser funktioniert.
Proportionales lenken hab ich weggelassen-dafür gibts keinen richtigen Grund, denn zum einen fährt so ein RC-Monstertruck sowieso nicht soo präzise (im Gelände erst recht nicht) gradeaus, und zum anderen ist es nicht nötig. Immer, wenn Soll-und IstKurs zu stark abweichen, wird mal ein Lenkeinschlag angeordnet, bis es wieder passt. Davon merkt man während der Fahrt kaum was.

Aktuell versuche ich (da ich mit den US-Sensoren noch nicht weiter komme, muss ich mal Lust zum rumbasteln haben) das Fahrprogramm GPS2Home so zu erweitern, dass ich vordefinierte Routen von der SD-Karte einlesen kann, und die dann Wegpunkt für Wegpunkt abgefahren werden.
Wenn ich das nämlich ausreichend genau schaffe, komm ich (im Prinzip...) ohne Hinderniserkennung aus: ich muss halt nur die Routen so legen, dass feste Hindernisse kurzerhand gleich umfahren werden. Unter Idealbedingungen (keiner parkt unangemeldet aufm Testgelände) sollte das klappen.
Allerdings ist das Ganze ziemlich viel Aufwand, da die Routen (in unbekannter Anzahl, ich will später einfach neue mit ablegen können) jeweils in ner eigenen Datei liegen, mir aber die Namen der Dateien (8.3-Format) zu kurz sind, um ausreichende Infos zu haben, welche Route es nun genau ist.
Von daher muss jede Datei einzeln geöffnet werden, die erste Zeile eingelesen (die enthält den richtigen Routennamen), aufs Display ausgegeben werden (damit ich dann die gewünschte Route wählen kann), und _wenn_ ich dann die richtige gefunden hab, muss die zeilenweise gelesen werden, um so einen Punkt nach dem anderen als "Ziel" zu haben. Ist das "Ziel" erreicht, werden einfach die nächsten Koordinaten geladen.
Ich will nämlich keineswegs immer die gesamte Route in den Speicher laden-irgendwann würd der Platz nicht mehr reichen, und bei dem beschriebenen System können die Routen theoretisch beliebig viele Punkte enthalten.

Das tolle ist, dass ich das Fahrprogramm GPS2Home, was ja schon gut funktioniert, für diesen Fahrmodus gleich mit benutzen kann. Es wird einfach nur immer, wenn ein Punkt erreicht ist, mit neuen Zielkoordinaten wieder gestartet.

[Rabenauge]

So- mit der SD-Karten-Geschichte komme ich recht gut voran (hatte die letzten Tage nicht viel Zeit)- einiges läuft bereits.
Dabei kam mir eine Idee:

Beim einschalten des Autos werden ja gewisse Dinge ausgewählt:
-Fahrmodus (GPS2Home oder RoutenNavigation
-falls ersteres, dann auch, ob ein neuer Startpunkt gesetzt werden soll,
-falls RoutenNavi, welche der vorhandenen Routen ausgewählt werden soll.
Nun kam mir die "bahnbrechende" Idee: was passiert, wenn der Mega mal abstützt oder aber der Akku leer ist, bevor die gestellte Aufgabe erledigt werden konnte?
Im Prinzip: nix, nur wird sie dann nie erledigt.
Das geht aber besser, da ich ja sowieso schon dauernd auf der SD-Karte herumspiele, könnte man es so lösen, dass zu Anfang die gewählten Einstellungen in ne Art *.ini-Datei geschrieben werden.
Die wird gelöscht, wenn die Aufgabe erledigt wurde. Dann brauche ich beim einschalten (halt bei jedem Neustart des Bordrechners) nur nachsehen, ob diese Datei vorhanden ist, und wenn ja kann man ne kleine Entscheidung einbauen, die meinetwegen 5s wartet: soll die Aufgabe fortgesetzt werden oder nicht....
Wenn die Zeit abgelaufen ist, ohne dass eine Planänderung vorgenommen wurde, wird einfach weiter gemacht.
Könnte man im Grunde auch in den EEPROM schreiben, aber dafür bräucht ich dann noch ne Bibliothek- die für die SD-Karte ist sowieso da.

Was meint ihr, macht doch Sinn, oder nicht?

[Rabenauge]

Inzwischen hab ich am RoutenParser mal fleissig gearbeitet.
Zwar läuft der momentan (noch) nur als eigenständiges Programm, aber nur, weils übersichtlicher ist.
Sind immerhin alleine knapp 200 Zeilen (nagut, nen paar leere sind auch drin, ausserdem musste ich den Joystick und das Display einpflegen zud zu debug-Zwecken gibts auch noch etliche serielle Ausgaben).

Ich habs aber so strukturiert, dass ich gar nicht viel mehr tun muss, als das Programm dann ins eigentliche Roboter-Programm einzukopieren.
Was macht der Routenparser?
-zuerst öffnet er das Routen-Unterverzeichnis der SD-Karte.
-dort zählt er die gefundenen Dateien (1 Datei=1 Route) und wartet nun auf eine Eingabe (per Joystick)
-bei jeder Stickbewegung wird der Reihe nach eine der Routen-Dateien geöffnet, und der Routenname, der am Anfang in Klartext steht, auf Display ausgegeben, damit man weiss, welche Route man gewählt hat
-das Ganze in ner Schleife. Ist das Verzeichnis durch, wird von vorn angefangen..
Wird der Stick eine gewisse Zeit nich mehr bewegt, wird die gerade gewählte Route übernommen, indem ihr Dateiname in ner Variablen gespeichert wird.
Nun wird ein Wegpunkt nach dem anderen _einzeln_ eingelesen-bevor der nächste gelesen wird, muss ein Trigger kommen (das wird später sein: Wegpunkt erreicht, momentan ist das einfach nur nen Sekundenzähler).

Damit habe ich nun alles beisammen, was ich für die Routen-Navigation brauche.
Im Grunde muss das Ganze dann nur noch an die Routine von GPS2Home übergeben werden, mit den aktuellen Wegpunkt-Werten als Sollwerte. Dann wird einfach GPS2Home so oft abgearbeitet, bis kein neuer Wegpunkt mehr kommt und-fertig.
Entspannende Bastelei also....

Aber noch gibts kleinere Problemchen: ich kann durch die Routen nur in eine Richtung blättern (weil ich einfach routenDatei = dir.openNextFile(); benutze), da ich keine Idee habe, wie man _einfach_ rückwärts blättern könnte.
Wenn die Routen alle durch sind, wird einfach mit dir.rewindDirectory(); wieder zum Anfang des Verzeichnisses gesprungen.
Genau _dort_ gibts ein Problem:
Dieses rewind.directory() macht etwas Probleme: aus einem unerklärlichen Grund dauert das ne halbe Sekunde, ehe es ausgeführt wird. Wenn man aber während dieser Zeit den Stick bewegt, wird zwar eine Datei eingelesen, aber die dann gelesenen Werte stimmen nicht. Wenn mir dazu ne Idee kommt (oder jemand nen Tipp hat?) würd ichd as gerne noch irgendwie auffangen.
Ansonsten muss ich die Routen auch noch auf Plausiblität überprüfen.....

Das zweite Problemchen ist ziemlich trivial (und kann vernachlässigt werden): der letzte Wegpunkt wird zweimal eingelesen, ehe festgestellt wird: da sind wir schon. Ich möchts trotzdem noch fixen- es ist einfach unschön.

Obendrein überlege ich noch, was sinnvoller ist: momentan wird das Auto _immer_ zuerst zum Anfangspunkt der ausgewählten Route fahren, und sie dann abarbeiten.
Effektiver wärs eigentlich, zuerst zu schauen, welcher Wegpunkt der nächste (vom Start) ist, und direkt den anzusteuern.
Ich find, irgendwie haben beide Methoden was. Ob ich da noch nen Fahrmodus mache? Mal schauen...
Zudem werd ich wohl noch die Plausibilität der ausgewählten Route überprüfen, einfach, indem die Entfernung zwischen aktueller (=Start-)Position und dem Routeneinstieg mal gegengerechnet wird. Ist die gewählte route weitewr weg, als das Auto fahren könnte (soo ewig reicht so ein Akku ja auch nicht), wird die Route gar nicht erst akzeptiert- man kann sich beim auswählen ja mal vertan haben.

[Rabenauge]

Sodele. Das Problem mit den teilweise falsch eingelesenen Dateien ist beseitigt.
Es war mal wieder meine eigene Blödheit....
Es wird nämlich lediglich in der jeweiligen Datei einfach nach "Zahlen" gesucht. Die erste gefundene Zahl ist der erste Wegpunkt, die zweite die dazu gehörige Länge, die dritte die Breite...
Da die Datei aber ganz oben auch nen String enthält (der den Klartext-Name der jeweiligen Route ausgibt), kann nun ein besonderes Schlauköpfchen auf die Idee kommen, mal einen Namen wie "ParkplatzRoute1" zu benutzen.
Und die darin enthaltene 1 wird somit bereits als erste Zahl gefunden, und alles verschiebt sich um eine Position.
Clever, oder?
Klar, man könnte das auffangen, indem man alles auf Plausibilität überprüft (wenn ein GPS-Punkt keine acht Stellen hat, kann er nicht stimmen), aber ich machs mir einfach und werd versuchen, die Textdateien in Zukunft ordentlicher anzulegen.
Das jetztige, noch standalone laufende Routen-Parserprogramm ist nämlich ohnehin schon 170 Zeilen lang- wobei ein grosser Teil davon allerdings nicht zählt (die Joystick-Routine ist ja im Monstertruckprogramm eh drin, die brauch ich also nicht noch mal, ausserdem werden zu Testzwecken im Moment eine Menge Daten auf die Konsole ausgegeben, das fällt dann auch weg), trotzdem isses gross genug.
Werd noch bisschen dran herumtesten, und es dann ins Monstertruck-Programm reinkopieren, ich hab es grundsätzlich gleich so ausgelegt, dass das meiste sich einfach rüberkopieren lässt.