Roboterfehler mit rosbag2 reproduzieren: Eingaben, TF und Zeit

Contents — find the section you need

Change parameters and verify

Open the panel, then press Run to load Python. You can stop execution and reset parameters. Results are computed on this device. No Python installation is required.

Local execution steps below are optional for reproducing the source results; they are not required for the browser experiment.

The experiment controls are in English.

Open experiment panel in a new tab

Download reproduction source

Audit a fixed replay in your browser

Use the panel above to compare clock settings, timestamp offsets, reliability QoS and TF selection. The Lab computes a synthetic replay audit, not ROS, DDS, tf2, a localizer or a robot simulation. It opens no bag files and connects to no robot. The ROS commands below are optional follow-up procedures.

Every run uses eleven scan records at bag times 10.0–12.0 s, spaced 0.2 s apart. Recorded input odom → base_link samples span 9.8–12.2 s at the same spacing. These are invented teaching fixtures, not hardware measurements. The timestamp control adds an offset to scan headers only; bag recording times and TF stamps stay fixed. It represents a differently stamped sensor fixture, not a rosbag2 playback option. Elapsed playback time is (bag time − 10 s) / rate. At 2×, the scan span becomes 1 s while the headers remain in their original time domain.

Read the four checks separately

Modeled receipt: choose the publisher's offered and subscriber's requested reliability independently. Best-effort offered to reliable requested is incompatible; the other three combinations are compatible. Topic names/types and every other QoS policy are assumed compatible. All compatible scans arrive in this loss-free model. This does not promise real best-effort delivery, establish actual rosbag2 auto-selected QoS, or model queues, deadlines, lifespan, discovery or late subscribers.
Recorded TF coverage: the scan header must fall within the recorded input TF interval, including endpoints. This is an audit of the complete recording, even when the modeled subscriber receives no scans. It does not simulate tf2's live cache, arrival ordering, interpolation, waiting, or transform availability at a callback. A stamp inside the interval is therefore not proof that a live lookup succeeds.
Clock difference: the replay-clock fixture sets the node's latest /clock value equal to each scan's bag time, assuming a clock update arrives before each scan. The system-clock fixture starts at the arbitrary value 1000 s and advances by elapsed playback time. With use_sim_time but no received clock, node time is zero and the diagnostic is not evaluated, shown as a dash. For initialized clocks, the Lab counts |node now − scan header| ≤ 150 ms. That symmetric window is a teaching diagnostic, not a ROS validity rule, tf2 tolerance or localizer timeout. It is independent of receipt and TF coverage.
TF publishers: the evaluated localizer is configured to publish map → odom. “Input transforms only” keeps recorded odom → base_link; “all recorded transforms” adds a second map → odom publisher; “exclude all recorded TF” removes the required input edge. Counts describe configured sources, not a computed localization result. Duplicate-source behavior and static-TF durability are not simulated.

Save the default as A and try B with 2× playback, a +400 ms header offset, no clock, a reliability mismatch, or a different TF selection. The plots use common A/B axes. With +400 ms, the last scan is beyond the recorded TF interval; all eleven scans lie outside the teaching clock window. With a missing clock, that window's count is unavailable rather than zero. Neither finding predicts trajectory error. The data table and JSON retain each scan's recording time, header, elapsed time, node time and independent check outcomes.

Reference and scope

The model's rules were reviewed on 2026-09-20 against the rosbag2 Jazzy README, Jazzy player options, Jazzy QoS documentation source, ROS clock design, Jazzy tf2 time tutorial source and REP-105 frame roles. No ROS installation was executed for this Lab.

Each A/B run starts fresh. Scheduling, packet loss, estimator memory, backward time jumps, multiple clock publishers, calibration, static TF, map accuracy and closed-loop driving remain outside this exercise. Use the SLAM evaluation Lab for a separate trajectory-error exercise. Browser checks do not replace the real replay checks below.

Wiederholte physikalische Läufe verändern sowohl die Eingaben als auch die Einstellungen. rosbag2 kann aufgezeichnete Eingaben fixieren, die Wiedergabe reproduziert jedoch nicht deterministisch einen kompletten Roboter. Dieses Verfahren wurde am 07.09.2026 anhand der primären ROS 2 Jazzy-Quellen geprüft; es wurde nicht auf ROS-Hardware oder einer laufenden ROS-Installation ausgeführt.

Vergleichsgrenze definieren

Betrachten Sie einen Lokalisator, der LiDAR- und Radodometriedaten verwendet. Zeichnen Sie /scan, /odom sowie die erforderlichen /tf und /tf_static auf. Speichern Sie die Ausgabe des Lokalisators separat als Vergleichsergebnis, nicht als Referenzwert. Kameraexperimente benötigen außerdem passende CameraInfo-Daten.

Die Jazzy README dokumentiert Aufzeichnung, Inspektion und QoS-Überschreibungen. Speichern Sie die installierten Paketversionen und die Ausgabe von ros2 bag record --help und ros2 bag play --help nach jedem Experiment.

Eingaben und Konfiguration aufzeichnen

Die unten aufgeführten Themen- und Knotennamen sind Beispiele. Ermitteln Sie Ihre Knoten mit ros2 topic list und ros2 node list und zeichnen Sie die Daten auf, während die Eingaben aktiv sind:

ros2 topic info /scan --verbose
ros2 bag record -o replay-input --topics /scan /odom /tf /tf_static

Beenden Sie den Vorgang ordnungsgemäß mit Strg+C und überprüfen Sie anschließend:

ros2 bag info replay-input
ros2 param dump /localizer > localizer-A.yaml

Ersetzen Sie /localizer durch Ihren Knoten. Speichern Sie außerdem Startdateien, Karten, URDF-Dateien, externe Kalibrierung, Software-Commit und die Ausgangsposition. Eine Anzahl von Nachrichten ungleich Null bedeutet nicht, dass alle erforderlichen Eingaben während des Fehlerintervalls vorhanden sind. Überprüfen Sie Zeitstempel-Offsets und Lücken pro Sensor.

Pro Transformation eine Zeitquelle und einen Publisher verwenden

Workflow von der Aufzeichnung der Eingaben bis zum Vergleich der Ausgaben.

In einer Analyseumgebung, in der Live-Input-Publisher gestoppt sind, konfigurieren Sie den Zielknoten und RViz mit use_sim_time=true. Die Startdetails hängen vom Paket ab. Anschließend wiedergeben:

ros2 bag play replay-input --clock 100 --rate 1.0

Die Jazzy-Player-Implementierung definiert die Clock-Option. Führen Sie keinen weiteren /clock-Publisher gleichzeitig aus. Aufzeichnung mit --use-sim-time und das Veröffentlichen eines Clocks während der Wiedergabe haben unterschiedliche Funktionen.

Ein /tf-Topic kann mehrere Transformationen enthalten. Wenn der ausgewertete Knoten nun map→odom generiert, geben Sie die aufgezeichnete map→odom nicht erneut wieder. Die erforderliche Eingabe odom→base_link muss möglicherweise weiterhin wiedergegeben werden. Das Ausschließen des gesamten Themas ist daher möglicherweise nicht ausreichend: Trennen Sie die Ausgabe während der Aufzeichnung oder filtern Sie einzelne Transformationen. Siehe REP-105 für Frame-Rollen.

Fehlende Ausgabe diagnostizieren

Symptom	Erste Prüfung
Nachrichten sind im Bag vorhanden, werden aber nicht empfangen	Namen, Typen und Publisher-/Subscriber-QoS
Cloud erscheint, aber Pose springt	Doppelte Publisher derselben Transformation

TF-Extrapolation in die Vergangenheit oder Zukunft | Header-Zeiten, Simulationszeit und aufgezeichnete TF-Abdeckung |

Nur die zweite Wiedergabe weicht ab | Estimator-Status, Maps und Behandlung von Zeitsprüngen in die Vergangenheit |

QoS beschreibt die Zustellungszuverlässigkeit und -historie. Überprüfen Sie die Kompatibilität mit topic info --verbose; machen Sie nicht blindlings jedes Thema zuverlässig. Wenden Sie Override-YAML nur bei Bedarf an. Änderungen an der statischen TF-Dauerhaftigkeit erfordern auch eine Überprüfung der Zustellung an verspätete Subscriber.

Entwurf eines A/B-Vergleichsprotokolls

Stoppen Sie A, setzen Sie den Zustand zurück und starten Sie B mit einer geänderten Einstellung. Halten Sie die Größe des Beutels, die Wiedergaberate, die Ausgangsposition, die Karte und das Auswertungsintervall konstant. Speichern Sie die Trajektorie, die Verarbeitungslatenz, fehlende Eingaben und Fehlerzeiten. Wiederholen Sie die unveränderten Bedingungen, um Planungs- oder Zufallseffekte aufzudecken.

Dies bewertet Reaktionen auf festgelegte Beobachtungen. Ein anderer Steuerbefehl würde zukünftige reale Beobachtungen verändern, daher kann die Wiedergabe vorab aufgezeichneter Sensoren keine Closed-Loop-Fahrleistung ermitteln.

Abschlusskriterien

Der Vergleich ist abgeschlossen, wenn die erforderlichen Eingaben eintreffen, jede Transformation genau einen Publisher hat, die Zeit konsistent ist und die Konfigurationsunterschiede die getestete Änderung erklären. Fahren Sie mit der SLAM-Evaluierung für die zeitliche Ausrichtung und die Trajektorienfehler fort.