Localization

Hallo.

Ich habe einen Roboter basierend auf zwei Arduinos, einem Raspberry Pi und einem Laserscanner (RP-Lidar).
Der Roboter ist über das Internet auf seinem Webinterface erreichbar.

Dank des Laserscanners und der Stepper Motoren (Dead Reconing) kann ich eine ziemlich gute Karte erstellen (probability map, danke der hohen Frequenz des Scanners sind Fehler auch schnell korrigiert) und darin navigieren (A*). Auch die Localization per Dead Reconing funktioniert recht gut, solange nichts gerammt wird. Etwas Drift tritt mit der Zeit natürlich auf. Um die zu korrigieren brauche ich einen pragmatischen Ansatz.

SLAM scheidet aufgrund der geringen Rechenleistung des PI aus.

Ein Ansatz wäre, sich am Startpunkt an einer Wand auszurichten und den Abstand zu dieser und zur 90° versetzen Wand zu messen (der Robot startet in einer Ecke). Dann kann sich der Robot nach einer Zeit wieder dorthin begeben, sich ausrichten (Orientierung korrigiert) und die Abstände messen (x/y korrigiert).
Die Korrektur findet dann halt selten statt. Aber das ist erstmal ok.


Aber da gibt es doch bestimmt noch einen besseren Ansatz. Montecarlo localization ist glaube ich auch zu aufwändig.

Hat da jemand Erfahrung und/oder eine gute Idee?

Robert

Hey, nur um dich mal im Vorraus zu warnen. Die Frage geht vermutlich darüber hinaus was die meisten Leute hier im Forum bauen.
Wie du gesagt hast. Drift kann man eigentlich nur korrigieren wenn man referenz Messwerte hat. Was man jedoch versuchen kann, ist den Drift möglichst weit zu kompensieren bzw. zu korrigieren.
Ein ganz einfaches Beispiel hierfür. Zur Bestimmung der Orientierung im Raum werden gerne Kombinationen aus Gyro und Beschleunigungssensor genommen. Gyros reagieren schnell und genau auf kleine, schnell Änderungen , driften dafür aber stark über längere Zeit. Beschleunigungssensoren reagieren dafür nicht so schnell, driften aber weniger. Hier kann man z.B. durch eine intelligente Filterung wie z.B. Komplementär oder Kalman Filter ansetzen um den Drift des Gyros zu kompensieren.

In diese Richtung zielt auch mein Vorschlag, der insbesondere im Zusammenhang mit Mapping einfach umzusetzen sein sollte. In die Richtung gehst du ja bereits durch deine Kombination aus Laserscanner und Stepper Motor Pack mehr Sensoren drauf mit Hilfe deren du deine Position bestimmen kannst bzw die du in die Map gewichtet einrechnen kannst. Dadurch kannst du den Drift einzelner Sensoren im idealfall mindern.

Danke für die schnelle Antwort. Zusätzliche Sensoren sind natürlich ein Weg. Dann muss ich mich mal in die Filterung einarbeiten.
Ein Ansatz die vorhandene Map und die Laserscanner Daten zu nutzen wäre auch noch gut.

Den einzigen meines Wissens nach möglichen Weg mit den vorhandenen Sensoren um eben den Drift zu kompensieren ist die Messung einer bekannten Größe, also der Weg den du bereits vorgeschlagen hast.

Was daran aber zu optimieren möglich wäre, wäre eine Messung und Map Bildung an einer beliebigen Stelle am Raum. Wenn du nun z.B. deine Lidar Messung durch Filtern vieler einzelner Messwerte an dieser Stelle möglichst präzise machst (Da gibt es schöne Ansätze die von einer Gausverteilung der Lidarmesswerte ausgehen) kannst du versuchen die Messwerte die du an der Stelle hast eindeutig in deiner Map zu verorten. Dadurch könntest du Fehler bezüglich deiner derzeitigen Position beheben.

Ich sehe schon .. wird nicht einfach. Danke für den Input.

Hmm, mir schwebt schon seit längerem vor:
- Linien/Ecken aus Scandaten als prägnante Merkmale extrahieren
- Neue Position berechnen, an der Du Linien/Ecken noch erkennen kannst
- Position ansteuern
- Anhand des Vergleiches von Linien/Ecken die Position korrigieren.
- Erst danach neue Merkmale aus Sicht der neuen Position in die Map eintragen

Das wäre also eine Rückkopplung des aktuellen Scans auf das Fahrverhalten (fahre gezielt dorthin, wo Du genug Anhaltspunkte zur Orientierung hast). Ob man beim Durchqueren einer Wohnung allerdings diesen unschönen Drift über lange Zeit wegbekommt? Wohl eher dadurch, dass man das ClosedLoop-Problem auf kleinere Loops begrenzt (Also ggf. so lange einen Raumteil oder einen Raum befährt, bis sich ein schlüssiges(***) Bild ergibt und sich erst danach neuem zu explorierenden Terrain widmet). Auch das wäre sicherlich ein Argument, das Fahrverhalten beim Explorieren von Terrain zu nutzen.


(*** Ich glaube "schlüssig" ist bei GridMaps generell das Kernproblem. Vektorbasierte Maps lassen ggf. eine bessere Fehlerkorrektur zu. Wenn Du z.B. einer Wand folgst, dadurch zwei teilüberlagernde Linien in zwei aufeinanderfolgenden Scans ermittelst, ist es doch eigentlich ganz gut, wenn Du den ermittelten Winkelfehler von 0,5° in der Map wegoptimierst und stattdessen den Winkel des BOTS korrigieren kannst.)


Gruß
Horst

Wie wäre es den Pi2 zu nehmen und dann mit ROS SLAM umzusetzen?
Kostet auch nur ca 35€, A7-Quadcore

Das auslesen von Merkmalen geht ja schon Richtung SLAM. Nur, dass es nicht permanent gemacht wird.
Mit dem Pi2 wird SLAM langsam möglich. Wäre zu überlegen.