RC-Auto ohne RC-Monstertruck autonom

[Rabenauge]

@robosapiens: das Navilock-Mäuschen, was du da verlinkt hast, verliert in jeder Kategorie (die dabeisteht) haushoch gegen das Ublox.
Und das für den vierfachen Preis....
Ich bin mir sicher, dasss ich nur noch nicht die optimalen Einstellungen gefunden habe, vermutlich hängt es mit dem eigebauten "Odometer" zusammen, das kann man auf etliche Arten konfigurieren (und alles mögliche und unmögliche sonst auch am Ublox).
Nen Panzerchassis wollte ich erst auch verwenden, aber ich hab solche Dinger und weiss: so ohne weiteres sind die 1:16er auch nicht wirklich Wildnistauglich, es geht, aber nicht so gut wie ich es will (früher oder später werd ich mir, wohl auf Basis dieser Panzer, mal ein _richtiges_ Chassis bauen, wenn man nicht auf die Vorbildtreue angewiesen ist, geht da was).

@pig: hatte ich ja auch so angefangen, mit nem Spielzeug-Buggy. Den hab ich aber ausgemustert, weil er für outdoor soo tauglich auch wieder nicht ist- der Monstertruck schafft Bordsteine auch noch aufwärts. Und da ich mir nicht sicher war (und es noch immer nicht bin) wie genau es mit GPS _wirklich_ zu schaffen ist, rechne ich nicht damit, immer guten Untergrund zu haben. Unter "Laborbedingungen" geht vieles weit einfacher, aber genau davon wollte ich eben weg.

[Rabenauge]

Sodele.
Bisschenwas ist heute auch geworden (weniger als geplant, aber das ist ja irgendwie normal): ich hab noch nen Stück Hardware verbaut.
Neee-natürlich nix wichtiges- eine Hupe.
Genaugenommen nur ein chinesischer Buzzer (mit jämmerlichster Klangqualität, wenn mir mal was besseres in die Finger kommt, wird das Elend ausgetauscht), aber den wollte ich so ziemlich zu Anfang schon haben. Damit er ein bisschen Sinn macht ("Spieltrieb" klingt immer irgendwie komisch, wenn mans nem Fremden erklärt), darf er gewisse Dinge auspiepsen.
Beispielsweise wird nun, ehe die Antriebe aktiviert werden, dreimal gepiepst- das ist echt praktisch, so kann man noch die Finger vom Vorderrad wegbekommen ehe die Kiste los marschiert. Wenn man will, kann man alles "sinnvoll" reden, oder?

Aber was gescheits ist auch geworden (genaugenommen sitze ich noch dran): die vorderen US-Sensoren laufen nun im GPS2Home-Programm mit.
Somit ist immerhin der Grundstein für eine erfolgreiche Hinderniserkennung schonmal gelegt.
Allerdings gibts ein Problem: bei 15 km/h (das dürfte in etwa Höchstgeschwindigkeit sein, ich hab die kürzere Untersetzung drin, glaub ich ) haben wir etwas über 4m/s- und vier Meter schaffen die US-Sensoren grade noch sicher. Manche auch fünf-aber da verlasse ich mich besser wohl nicht drauf. Ausweichen wird also knapp- das muss sehr schnell gehn.
Glücklicherweise kann das Auto bei _dem_ Tempo (ich könnts auch mit 12V fahren, dann aber könnte ich die Sache vergessen) selbst bei Vollgas noch kräftige Lenkeinschläge schaffen, ohne gleich umzukippen-werds brauchen.
Ne vernünftige Bremsstrategie hab ich nämlich noch nicht, da der Regler sich beim umschalten von Vorwärts auf Bremse enorm zickig gibt.
Nun frage ich mich grade, ob es überhaupt noch Sinn macht, bei Hinderniserkennung proportional zu lenken, oder einfach "rum bis der Weg wieder frei ist"- letzteres ist eigentlich nicht meine Art, ich mags geschmeidiger.

[Rabenauge]

So-ich werd erstmal die "rum-bis-frei-Methode" testen.
Der Grund: um an den Sensorergebnissen noch lange rumzufiltern fehlt die Zeit. Ich möchte nämlich nicht unbedingt schon auf 4m anfangen, Hindernissen aus dem Wege zu gehn- auf den üblichen Teststrecken (Fusswege, max. Radwege, auf öffentliche Strassen will ich logischerweise nicht) ist 4m zu lang- das ergibt ja nur rumgekurve.
Wenn ich den Modus getestet habe werde (heute wird das nix mehr), werd ich wissen, ob das so praktikabel ist-oder nicht. Und auch, ob da noch genug Luft bleibt, ums zu verbessern (bei nur 2m Reichweite spar ich ja doch einiges an Messzeit).
Zusätzlich habe ich die Sensorresultate (ich lass die gleich in cm umrechnen, das braucht der Roboter nicht, aber dem Menschen hilfts) verunschärft- alles was innerhalb 5cm Toleranz passiert, wird nich ernst genommen.
Das ist deshalb nötig, weil die Sensoren mit der verwendeten Bibliothek soo genau auch wieder nich arbeiten, selbst bei völlig freier Sicht wackelt die Ausgabe nen bisschen.
Vermutlich hats der Ersteller (wenn ich mal gaaaanz viel Lust hab guck ich mal in die Bibliothek rein, momentan nich) etwas zu gut gemeint mit seiner Zeitbegrenzung.

Nenbenbei hab ich die beiden vorderen US-Sensoren mechanisch noch stabiler angebaut, die hat es mir beim hantieren immer mal nach hinten gebogen (die waren praktisch nur an den Anschlussstiften verlötet)- dauerndes hin-und-herbiegen kann auch nich gut sein.
Allerdings werden sie jetzt bei nem guten Frontalcrash zerstört, da sie nicht mehr nachgeben können-da muss dann mal noch nen Schutzbügel vor, wenn mir was passendes in die Finger fällt.
Ausserdem: genau den Crash sollen sie ja verhindern-also solln die dinger gefälligst ihren Job machen, dann passiert auch nix.

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