[GP] mino schrieb:
somit könnte er doch mit einer 360° umdrehung alle sichtpunktabhängigen hindernissse einlesen und sich daraus eine map erstellen. ausgehend von dieser map, könnte er auch leicht herausfinden wo er sich grad befindet und wo sich noch die unbekannten flächen befinden.
Also quasi:
Code:
1. Position bei x=0, y=0, winkel=0 initialisieren
2. Sensordaten zu Karte verarbeiten
3. Fahrzeug bewegen
4. Neue Position mit neuen Sensordaten und der bisherigen Karte bestimmen
GOTO 2
Die Idee ist natürlich schon sehr richtig. So arbeitet zu einem Teil jeder SLAM-Algorithmus. Man nutzt seine unvollständige Karte zur Positionsbestimmung.
Das Problem hierbei ist nur, dass dieses Verfahren nur in einem Robotersimulator funktionieren würde, wo man fehlerfrei messende Sensoren simulieren kann.
In der Realität arbeitet man immer mit Messfehlern.
Zum einen beim ersten einlernen des sichtbaren Teilbereichs und im nächsten Schritt dann bei der nächsten Messung zur Positionsbestimmung werden Messfehler einen unbekannten Fehler in die Positionsbestimmung bringen.
Die gleiche Idee könnte auch lauten:
"Lass dir durch ein
Odometriesystem immer die aktuelle Position geben und nutz diese um die Sensordaten in absolute Koordinaten umzurechnen".
Wenn du deinem Fahrzeug sagst es soll 10m gerade aus fahren, wird es allerdings immer einen leichten Drift haben und somit intern eine andere Position annehmen ("Ich bin doch nur gerade aus gefahren?") als es tatsächlich hat.
Dieser Fehler mag auf den ersten Blick lächerlich klein wirken, wenn man mit guten Sensoren arbeitet - aber er schaukelt sich innerhalb von Sekunden zu unbrauchbaren Ergebnissen hoch. Macht man aufgrund von Messfehlern nur einen Fehler von 0,1° bei der Fahrzeug-Blickrichtungs-Bestimmung bedeutet das für eine Landmarke die auf 20m Entfernung gesehen wird einen absoluten Positionsfehler von ~3,5 cm. Dieser Fehler setzt sich nun aber fort! Denn mit dieser falsch eingespeicherten Landmarke wird ja auch die nächste Position bestimmt.
Solange man bei der Positionsbestimmung nur auf ein einziges System setzt werden die Messfehler zwangsläufig einen Fehler erzeugen, der nicht kompensiert wird.
Der Roboter hat quasi keine Möglichkeit zu merken, dass er einen Fehler macht.
Wie in echt auch: Wenn man sich ausschließlich mit einer politisch einseitigen Zeitung bildet und keine anderen Informationen bekommt um die Artikel kritisch zu hinterfragen nimmt mal sie automatisch als wahr an. Man kann ja ohne andere Zeitungen / Menschen / Fernsehen etc. garnicht merken, dass die einzige Info-Quelle die man nutzt nicht neutral ist.
Oder ein anderes Beispiel: In Geiserbahnen gibts manchmal so kleine Brücken die durch eine drehende Röhre führen. Das Auge sagt dir, dass deine Welt umkippt und du möchtest da gegen steuern. Dein Schwerkraftsensor im Ohr vermittelt dir allerdings, dass alles in Ordnung ist. Diese beiden sich widersprechenden Infos machen einen "Seekrank". Eine einfache Möglichkeit da durch zu kommen ist hier natürlich einfach die einzige fehlerhafte Informationsquelle zu ignorieren, indem man die Augen schließt.
Die Idee ist daher immer auf mindestens 2 Systeme zur Positionsbestimmung zu setzen und diese zB mittels
Extended Kalman filter zu
fusionieren
Wenn du neben einem wahrnehmenden Sensor noch Odometrie hast wäre das:
Code:
1. Position bei x=0, y=0, winkel=0 initialisieren
2. Sensordaten zu Karte verarbeiten
3. Fahrzeug bewegen
3a. Ersten Positionsvorschlag Pos1 durch Odometriesystem generieren
3b. Zweiten Positionsvorschlag Pos2 durch bisherige Karte und Sensordaten generieren
4. Angenommene Position entsprechend der Odometrie setzen
5. Aktuelle Sensordaten nutzen um die Karte zu erweitern.
6. Einen Kompromiss aus Pos1 und Pos2 bilden (EKF) und als aktuelle Position setzen
GOTO 3
Das entspricht dann FastSLAM 2.0 wo der Partikelfilter fehlt, weswegen es "einfach" zu implementieren ist.
Für unter anderem gaussches Sensorrauschen (Fehler mit Mittelwert = 0, StdDev bekannt) kann man hier sogar konvergenz gegen Realität beweisen für unendlich lange fahrten. Das ganze hat O(1) und ist daher auf jeden Fall echtzeitfähig implementierbar bei Datenraten weit über 100Hz. Also muss das Fahrzeug auch nich stockend fahren, weil der Rechner zu langsam ist ;-) Es wird eher so sein, dass der Algorithmus sich langweilt und darauf wartet, dass der Sensor endlich mal wieder gesehene Landmarken liefert.
Die Schwierigkeit steckt noch in Schritt 5: Wie legt man 2 leicht zueinander unterschiedliche Karten übereinander und bildet einen Kompromiss? Das ganze wird ausführlich
hier erklärt.
In Kurzform: Für jede gesehene Landmarke wird überlegt, ob sie bereits bekannt ist. Man berechnet quasi die Wahrscheinlichkeit zu jeder bekannten Landmarke. Wenn diese Wahrscheinlichkeit für keine bekannte Landmarke einen gewissen Schwellwert überschreitet, wird die gesehene Landmarke als "neu" der Karte hinzugefügt. Diese Identifikation hat dann leider O(N) - geht aber in realen Szenarien immernoch schnell genug.
im Moment ist noch Leere bezüglich dieses Themas in meinem Kopf ...
