SLAM, Kartierung, Lokalisierung und Odometriedrift

Ein mobiler Roboter braucht zwei verbundene Antworten: Wie sieht die Umgebung aus, und wo ist der Roboter darin? Simultane Lokalisierung und Kartierung (SLAM) schätzt beides, während der Roboter erkundet. Sobald eine stabile Karte existiert, kann ein Lokalisierungssystem die Pose gegen diese feste Karte schätzen, ohne sie neu aufzubauen.

SLAM ersetzt keine Odometrie. Es nutzt lokale Bewegungsschätzungen, um Sensorbeobachtungen zu verbinden – und korrigiert dann ihre aufgestaute Drift, sobald die Umgebung genug Evidenz liefert.

Die vier Jobs trennen

Die Begriffe fallen leichter, wenn jeder eine klare Ausgabe hat:

• Odometrie: weiche lokale Bewegung aus Radencodern, Trägheitsmessung, visueller Bewegung oder deren Fusion. Sie driftet über Zeit.
• Kartierung: Eine Repräsentation wie ein Belegungsraster aus Sensorbeobachtungen und Posen aufbauen.
• Lokalisierung: Roboterpose in einer existierenden Karte schätzen.
• SLAM: Die Karte bauen, während Posen geschätzt und vergangene Schätzungen revidiert werden.

Navigation fügt Planung und Regelung obendrauf. Eine gute Karte erzeugt allein noch keinen sicheren Geschwindigkeitsbefehl.

Der Information durchs System folgen

Für zweidimensionales Innenraum-SLAM ist ein gängiger Datenfluss:

1. Radencoder und Trägheitsmesseinheit schätzen lokale Bewegung.
2. Ein Lidar publiziert Entfernungsscans mit Zeitstempeln und Sensorframe.
3. TF2 bezieht den Sensor auf base_link und lokale Pose auf odom.
4. Scanmatching richtet neue Beobachtungen an jüngsten Scans oder der wachsenden Karte aus.
5. Das Backend optimiert einen Graphen aus Posen und Zwangsbedingungen.
6. Ein Belegungsraster wird aus korrigierten Posen und Entfernungsdaten aktualisiert.

Odometrie liefert eine brauchbare Startschätzung. Ohne sie durchsucht Scanmatching einen weit größeren Raum oder richtet an falscher wiederholter Struktur aus. Ohne externe Beobachtungen bleiben Odometriefehler unbegrenzt. Diese Schranke entscheidet, ob ein Roboter einen Boden in parallelen Reihen kehren kann: Die Reihen hören nach etwa zehn auf, parallel zu sein – weshalb eine Maschine, die ihre Abdeckung plant, auch ein Gyro, eine Deckenkamera oder eine Bake trägt. Draußen fällt derselbe Job an GPS, fusioniert statt verfolgt.

Scanmatching und Loop Closure verstehen

Scanmatching findet eine relative Pose, die aktuelle Entfernungsmessungen bestmöglich an existierender Struktur ausrichtet. Es kann kleinen Radschlupf und Maßstabsfehler korrigieren – braucht aber geometrische Merkmale. Ein langer merkmalloser Korridor, Glaswand, bewegte Menge oder stark repetitives Regal können mehrere Posen gleich aussehen lassen.

Ein Loop Closure geschieht, wenn das System einen zuvor besuchten Ort erkennt und eine Zwangsbedingung zwischen aktueller Pose und älterer Pose hinzufügt. Diese Zwangsbedingung zu optimieren kann aufgestauten Fehler über die Trajektorie verteilen und Wände wieder fluchten lassen.

Ein Loop Closure ist nicht automatisch korrekt. Eine falsche Zuordnung in zwei ähnlichen Korridoren kann die Karte falten oder zerreißen. Robuste Systeme nutzen geometrische Prüfungen, Scores und konfigurierbare Annahmeschwellen. Verdächtige große Korrekturen prüfen statt jeden geschlossenen Loop feiern.

Den Roboter vorbereiten, bevor man SLAM abstimmt

SLAM kann keinen gebrochenen Eingabevertrag kompensieren. Diese zuerst verifizieren:

• Encoderichtung, -maßstab und -zeitstempel;
• vernünftige lokale Odometrie bei Gerade- und Drehtests;
• korrekte odom → base_link → Sensor-Transforms;
• Entfernungsdaten in korrekten Einheiten mit erkannten ungültigen Messwerten;
• Uhrenübereinstimmung über Nodes;
• eine steife Sensorhalterung;
• genug Reichweite und Sichtfeld für die Umgebung.

Langsam fahren, während man die Basislinie etabliert. Bewegungsverzerrung und spärliche Scans werden mit steigender Drehgeschwindigkeit schwerer. Wenn Sensor oder Treiber Zeitkompensation unterstützen, aus vermessenem Verhalten konfigurieren statt anzunehmen, sie sei unnötig.

Eine Karte absichtlich aufbauen

An merkmalreichem Ort starten und durch Schleifen bewegen statt nur langer Hin-und-her-Wege. Weich rotieren, damit der Scanner dieselben Strukturen aus überlappenden Blickwinkeln beobachtet. Während der Kartierung keine großen Objekte neben dem Roboter tragen oder bewegen.

Die Livekarte auf verdoppelte Wände, verschmierte Ecken, Sprünge und getrennte Räume überwachen. Das sind Evidenz, keine Kosmetikprobleme:

• verdoppelte parallele Wände deuten Pose- oder Timingfehler an;
• gekrümmte Wände bei Drehung deuten falsche Transforms oder Bewegungsverzerrung an;
• graduelle Maßstabsdrift deutet Radkalibrierung oder schwache Scanzwänge an;
• plötzliche globale Umlagerung deutet Loop Closure an, korrekt oder falsch.

Die Karte erst speichern, nachdem geprüft ist, dass wichtige Korridore bei gewählter Auflösung befahrbar bleiben. Ein feineres Raster kostet Speicher und kann Sensorrauschen konservieren; ein grobes kann enge Durchgänge schließen.

In der gespeicherten Karte lokalisieren

Nach Kartierung in Lokalisierungsmodus gegen die gespeicherte Karte wechseln. Ein Partikelfilter-Lokalisierer wie Adaptive Monte Carlo Localization (AMCL) schätzt Pose aus Entfernungsbeobachtungen und Bewegung. Er braucht weiter ein vernünftiges Sensormodell, Transforms und Odometrie.

Eine Startpose nahe genug geben, damit das System den korrekten Ort erkennt – besonders in symmetrischen Umgebungen. Erholung testen, indem man mit kleinen Posefehlern beginnt, dann größeren. „Entführter Roboter“-Erholung ist eine separate Anforderung – nichts, was man annimmt, weil normales Tracking funktioniert.

Im Standard-Framemodell publiziert lokale Odometrie odom → base_link, während SLAM oder Lokalisierung map → odom publiziert. Der globale Transform korrigiert Drift, ohne den lokal glatten Regelungsframe springen zu lassen.

Genauigkeit und Wiederholbarkeit messen

Physische Landmarken mit vermessenen oder sorgfältig gemessenen Positionen verwenden. Die geschätzte Pose aufzeichnen, wenn der Roboter an jeder Landmarke aus verschiedenen Anfahrrichtungen stoppt. Trennen:

• Wiederholbarkeit am selben Ort;
• kurzfristige lokale Drift;
• globale Kartenkonsistenz nach einer Schleife;
• Erholzeit nach vorübergehendem Sensorverlust.

Die Karte mit bekannten Strecken vergleichen – aber nicht nur nach hübschem Bild urteilen. Navigation braucht korrekten Freiraum, Hindernisgrenzen und Posenstabilität mehr als hübsche Wandstärke.

Scans, Odometrie, Transforms und SLAM-Ausgaben loggen, damit ein Fehler wiederabspielbar ist. Ein Nur-live-Problem ist weit schwerer zu diagnostizieren.

Gängige SLAM-Fehler diagnostizieren

• Wände verdoppeln sich bei Geradeausfahrt: Odometriemaßstab, Sensorzeit oder Scanmatching inkonsistent.
• Die Karte biegt sich bei Drehung: Sensortransform, Winkelodometrie oder Bewegungsverzerrung falsch.
• Pose springt in wiederholten Korridoren: Scanmatching oder Loop Closure akzeptierte eine mehrdeutige Ausrichtung.
• Kein Loop schließt: Route ohne Überlappung, Beobachtungen zu spärlich oder Annahmeschwellen zu streng.
• Lokalisierung funktioniert nur nahe der Startpose: Umgebung symmetrisch oder globale Erholung nicht konfiguriert.
• Die Karte sieht korrekt aus, aber Navigation streift Wände: Footprint, Aufblähung oder Costmap-Konfiguration falsch.
• Jedes SLAM-Parameterdrehen ändert nichts: Der vorgelagerte Odometrie-/TF-/Sensorvertrag ist weiter gebrochen.

Mit Quadraturencoder-Kalibrierung und Differenzial-Odometrie anfangen, dann mit ROS-2-TF2-Koordinatenframes die geometrische Kette verifizieren. Der Sensorsimulator zeigt, warum sich Bias und Drift per schlichtem Glätten allein nicht beseitigen lassen.