Ein AMR (Autonomous Mobile Robot) soll zuverlässig durch Lagergänge fahren, an Übergabestationen präzise stoppen und dabei Menschen sowie Infrastruktur nicht gefährden. In ROS 2 steht dafür ein ausgereifter Baukasten bereit: ROS 2 Navigation (Nav2) orchestriert Lokalisierung, Pfadplanung und Hindernisvermeidung. Stabil wird das System jedoch erst, wenn Sensorik, Frames, Karten und Regelung zusammenpassen. Der folgende Praxis-Guide erklärt die wichtigsten Stellschrauben und typische Stolperfallen aus realen Integrationen.
Welche Bausteine in Nav2 wirklich zusammenarbeiten mĂĽssen
Nav2 ist kein einzelner Algorithmus, sondern eine Kette aus Knoten (Nodes) mit klaren Zuständigkeiten. Für eine robuste Inbetriebnahme lohnt es sich, diese Kette als Datenfluss zu denken: Sensoren liefern Messwerte, daraus entstehen Karten und Kostenkarten, dann folgen Planung und Regelung bis hin zum Fahrbefehl.
Lokalisierung: Pose-Schätzung ist der Taktgeber
Die Lokalisierung liefert die Roboterpose (x, y, yaw) im Kartenbezug. Wenn die Pose springt oder driftet, wirken Planner und Controller „unberechenbar“, obwohl sie korrekt arbeiten. In ROS 2 sind zwei Pfade üblich: amcl (partikelbasiert auf 2D-Laser) oder SLAM/State-Estimation mit Fusion. Entscheidend ist, dass Zeitstempel und Frames konsistent sind und die Messfrequenzen zur Fahrdynamik passen.
Global Planner vs. Local Controller: Planung und AusfĂĽhrung trennen
Der Global Planner erzeugt einen Pfad über die Karte (z. B. entlang freier Korridore). Der Local Controller setzt diesen Pfad in Geschwindigkeitssollwerte um, reagiert aber zusätzlich auf aktuelle Hindernisse in der Nähe. Probleme zeigen sich oft so: Der Planner findet einen Pfad, der Controller „zittert“ oder bleibt stehen. Dann ist nicht die Karte das Problem, sondern meist Parameter im Controller, der Lookahead-Abstand, die Beschleunigungslimits oder die Kostenkarte im Nahbereich.
Sensorik richtig anbinden: von Laser bis Odometrie
AMRs scheitern selten an „zu wenig KI“, sondern an unklarer Sensorintegration. Nav2 erwartet, dass Sensoren verlässlich und in passenden Koordinaten vorliegen. Das betrifft sowohl 2D-LiDAR als auch Tiefenkameras oder Ultraschall.
LaserScan und PointCloud: Auswahl nach Einsatzumgebung
2D-LiDAR liefert klare Konturen und ist für viele Indoor-AMRs Standard. Tiefenkameras können mehr Struktur liefern, reagieren aber empfindlicher auf Licht, Reflexionen und transparente Objekte. Für Nav2 ist wichtig, dass Hindernisse als LaserScan oder als PointCloud2 in die Kostenkarten einfließen und der Sensor-Frame korrekt im TF-Baum hängt.
Odometrie und IMU: Drift begrenzen statt „wegfiltern“
Odometrie (Radencoder) driftet auf glatten Böden oder bei Schlupf. Eine IMU stabilisiert die Winkelgeschwindigkeit, löst aber keine Radschlupf-Fehler in x/y. Praktisch ist eine saubere Modellierung der Kinematik (Differential, Ackermann, Omnidrive) und ein realistisches Tuning der Covariances. Nur so gewichtet die Fusion Messwerte sinnvoll. Das Ziel ist nicht perfekte Odometrie, sondern eine Pose-Schätzung, die für den Regelkreis ruhig genug ist.
TF-Frames, Zeit und QoS: die häufigsten Ursachen für „unerklärliche“ Bugs
Wenn Nav2 sporadisch stoppt, „No transform“ meldet oder die Kostenkarte flackert, liegt es oft nicht an der Planung, sondern an Systemintegration. Drei Themen treten immer wieder auf.
Frame-Konventionen sauber halten
Ein typisches Minimal-Setup nutzt map → odom → base_link. Sensoren hängen unter base_link (oder base_footprint). Wichtig ist, dass die Transformationskette vollständig und kontinuierlich verfügbar ist. Ein Frame darf nicht „springen“ (z. B. odom neu initialisieren), weil der Controller sonst scheinbar rückwärts fahren oder abrupt abbremsen kann.
Uhren, Sim-Time und Zeitstempel
Nav2 reagiert sensibel auf alte Nachrichten: Wenn Sensor- oder Odometrie-Zeitstempel hinterherhinken, werden Hindernisse als „veraltet“ verworfen. In gemischten Systemen (z. B. externe Mikrocontroller, mehrere Rechner) muss die Zeitbasis konsistent sein. In Simulationen ist /use_sim_time Pflicht, in realen Systemen sind stabile Zeitsynchronisation und plausible Stempel entscheidend.
ROS 2 QoS passend wählen
Bei Sensorstreams zählt Aktualität mehr als perfekte Zustellung. Für Laser und Pointclouds ist „best effort“ oft sinnvoll, während Odometrie und TF zuverlässig sein sollten. Unterschiedliche QoS-Profile zwischen Publisher und Subscriber führen sonst zu stillen Verbindungsproblemen: Es kommt schlicht nichts an, obwohl Topics sichtbar sind. Eine systematische QoS-Prüfung spart hier viel Zeit.
Karte, Kostenkarten und Sicherheitsabstände nachvollziehbar parametrieren
Die meisten „Roboter bleibt hängen“-Probleme lassen sich auf Kostenkarten zurückführen. Nav2 unterscheidet grob zwischen globaler Kostenkarte (für Planung auf der Karte) und lokaler Kostenkarte (für unmittelbare Reaktion). Beides muss zum Footprint und zur Sensorabdeckung passen.
Inflation und Footprint: Abstand ist ein Parameter, keine Annahme
Der Roboter-Umriss (Footprint) bestimmt, wie nah der Pfad an Hindernissen verlaufen darf. Die Inflation erweitert Hindernisse um einen weichen Abstand. Zu geringe Inflation führt zu Kollisionen an Regalkanten; zu hohe Inflation macht enge Passagen „unpassierbar“. Der richtige Wert hängt von Lokalisierungsunsicherheit, Bremsweg, Bodenhaftung und der Genauigkeit der Hinderniserkennung ab.
Obstacle- und Voxel-Layer: was wirklich als Hindernis zählt
Bei 2D-Laser ist der Obstacle-Layer meist ausreichend. Bei 3D-Sensoren wird häufig ein Voxel-Layer verwendet, um Hindernisse über der Bodenebene zu repräsentieren. Wichtig ist, den Sensor-Range realistisch zu setzen und „clearing“ zu aktivieren, damit weggefahrene Hindernisse wieder aus der Kostenkarte verschwinden. Sonst entstehen Geisterhindernisse, die den Planner dauerhaft blockieren.
Controller-Tuning: warum der Roboter „zittert“ oder nicht am Ziel hält
Wenn ein AMR zwar plant, aber schlecht fährt, ist der Regelkreis der Ansatzpunkt. Nav2 bietet verschiedene Controller-Plugins; die Parameter müssen zur Kinematik, zu den Dynamiklimits und zum Footprint passen.
Geschwindigkeits- und Beschleunigungslimits zuerst, dann Feinparameter
Bevor Lookahead, Gains oder Scoring-Funktionen getuned werden, sollten Maximalgeschwindigkeit, Beschleunigung und Verzögerung zur Plattform passen. Ein Controller, der mehr Dynamik fordert als die Hardware liefern kann, erzeugt systematisch Tracking-Fehler. Umgekehrt fühlt sich ein „zu konservatives“ Limit so an, als würde der Roboter unmotiviert stehen bleiben.
Ziel-Annäherung und Rotationsverhalten
Häufige Praxisprobleme sind: Der Roboter erreicht das Ziel nicht innerhalb der Toleranz oder rotiert unnötig im letzten Meter. Ursache sind meist zu enge goal tolerances, ein ungünstiges Rotationsverhalten im Controller oder eine zu grobe Lokalisierung. Ein stabiler Ansatz ist, Positions- und Winkeltoleranzen so zu wählen, dass sie zur Stationierungsaufgabe passen (z. B. Übergabe an Fördertechnik strenger, reine Wegpunkte lockerer), und die finale Ausrichtung explizit zu testen.
Konkretes Vorgehen fĂĽr eine belastbare Inbetriebnahme
In der Praxis hilft ein klarer Ablauf, der jede Schicht einzeln validiert, bevor die nächste dazukommt. Damit lassen sich Fehler eingrenzen, ohne „Parameter-Salat“ zu erzeugen.
Schrittfolge, die sich in Projekten bewährt
- TF-Baum prüfen: map → odom → base_link stabil, Sensorframes korrekt; keine Sprünge oder Lücken.
- Odometrie verifizieren: Geradeausfahrt und Drehung messen, Drift und Schlupf beurteilen; Limits zur Plattform setzen.
- Sensorqualität checken: Laser/Depth liefert plausible Distanzen, keine Ausreißer; Hindernisse werden erkannt und wieder gelöscht.
- Lokalisierung allein testen: Roboter schieben/fahren, Pose folgt ruhig; Relokalisierung nach „Kidnapping“ (versetzen) funktioniert.
- Kostenkarten visualisieren: Footprint, Inflation, Obstacle-Layer; in Engstellen testen, ob Passagen zugehen.
- Erst Global Planner, dann Controller: zunächst langsame Fahrprofile, danach Schritt für Schritt dynamischer.
- Abnahmetests definieren: Not-Aus, langsame Annäherung an Personen, Stopp vor Hindernissen, reproduzierbare Parkmanöver.
Sicherheit in der Umgebung: Abgrenzung zu normativer Funktionalsicherheit
Nav2 kann Hindernisse vermeiden, ist aber nicht automatisch eine Sicherheitsfunktion im Sinne funktionaler Sicherheit. In realen Anlagen braucht es eine klare Trennung zwischen Komfortfunktionen (Navigation) und sicherheitsgerichteten Funktionen (z. B. sicherer Stopp, sichere Geschwindigkeit, abgesicherte Felder). Für stationäre und mobile Roboter gelten in der Praxis häufig etablierte Sicherheitsprozesse, wie sie in ISO 10218 für Industrieroboterumfelder beschrieben werden; bei fahrerlosen Transportsystemen und AMRs kommt zusätzlich der anwendungsspezifische Risikobeurteilungsprozess hinzu. Entscheidend ist: Sicherheitsanforderungen werden aus der Risikobeurteilung abgeleitet und dann mit geeigneter, validierbarer Technik umgesetzt.
Typische technische MaĂźnahmen rund um AMRs
Bewährt sind getrennte Sicherheitssensorik (z. B. Safety-Laserscanner), sichere Ein- und Ausgänge (STO, Safe I/O), definierte Geschwindigkeitsprofile und klar markierte Verkehrsregeln in der Umgebung. Nav2 kann diese Konzepte unterstützen (z. B. durch Zonenparameter und Geschwindigkeitsreduktion), sollte aber nicht als Ersatz für eine sicherheitsgerichtete Abschaltung betrachtet werden.
Praxisnahe Entscheidungshilfe: 2D-LiDAR-Setup oder 3D-Perzeption?
Die Wahl der Perzeption beeinflusst Rechenlast, Konfiguration und Fehlermodi. Eine nĂĽchterne GegenĂĽberstellung erleichtert die Entscheidung vor der Beschaffung und spart Integrationszeit.
| Ansatz | Stärken | Grenzen in der Praxis |
|---|---|---|
| 2D-LiDAR + 2D-Kostenkarten | Robust, gut interpretierbar, geringer Rechenbedarf; einfache Fehlerdiagnose | Überhängende Objekte und niedrige Hindernisse können übersehen werden; Planung bleibt in 2D |
| 3D-Sensor (Depth/LiDAR) + Voxel-Layer | Erkennt Volumenstrukturen, potenziell bessere Abdeckung bei komplexen Objekten | Mehr Parameter, mehr Datenrate; empfindlicher bei Reflexionen/Beleuchtung; Tuning aufwendiger |
| Hybrid (2D-LiDAR für Navigation, 3D für Zusatzfunktionen) | Navigation bleibt stabil, 3D ergänzt z. B. Palettenerkennung oder Freigabeprüfungen | Mehr Systemkomplexität; klare Verantwortlichkeiten zwischen Stacks nötig |
Für viele Indoor-AMRs ist 2D-LiDAR der schnellste Weg zu reproduzierbarer Navigation. 3D lohnt sich dort, wo die Umgebung stark dreidimensional ist (z. B. überstehende Lasten) oder zusätzliche Funktionen (Erkennung von Ladungsträgern) ohnehin eingeplant sind.
Für ein ROS-2-Projekt empfiehlt sich außerdem, Testläufe früh zu skripten (z. B. feste Zielpunkte, definierte Hindernisattrappen, wiederholbare Fahrprofile) und Logdaten konsequent zu archivieren. So lassen sich Parameteränderungen objektiv bewerten, statt „nach Gefühl“ zu tunen.
