RC-Auto ohne RC-Monstertruck autonom

[piggituX]

Hi,

ah nun auch endlich hier . habe das im Arduino-Forum schon verfolgt. Ich baue derzeit auch genau an so einer Lösung. Mein Chassis ist aktuelle ein altes Nikko RC, geht nur schleppend voran, da mich mein Sohn auf Trab hält. Bin derzeit bei Hindernis-Erkennung dran, aber ich habe ja Zeit

Wünsch Dir viel Erfolg und ich verfolge das mal weiter

pig

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