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.
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
/clockvalue 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. Withuse_sim_timebut 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 recordedodom → base_link; “all recorded transforms” adds a secondmap → odompublisher; “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.
Le ripetute esecuzioni fisiche modificano sia gli input che le impostazioni. rosbag2 può mantenere fissi gli input registrati, ma la riproduzione non riproduce un intero robot in modo deterministico. Questa procedura è stata verificata rispetto ai sorgenti primari di ROS 2 Jazzy il 07/09/2026; non è stata eseguita su hardware ROS o su un'installazione ROS in esecuzione.
Definizione del confine di confronto
Si consideri un localizzatore che utilizza LiDAR e odometria delle ruote. Registrare /scan, /odom e i valori richiesti /tf e /tf_static. Salvare l'output del localizzatore separatamente come risultato del confronto, non come valore di riferimento. Anche gli esperimenti con la telecamera richiedono la corrispondenza di CameraInfo.
Il README di Jazzy documenta la registrazione, l'ispezione e le sovrascritture QoS. Salva le versioni dei pacchetti installati e l'output di ros2 bag record --help e ros2 bag play --help per ogni esperimento.
Registrazione degli input e della configurazione
I nomi di argomenti e nodi riportati di seguito sono esempi. Scopri i tuoi con ros2 topic list e ros2 node list, quindi registra mentre gli input sono attivi:
ros2 topic info /scan --verbose
ros2 bag record -o replay-input --topics /scan /odom /tf /tf_static
Interrompi correttamente con Ctrl+C, quindi esamina:
ros2 bag info replay-input
ros2 param dump /localizer > localizer-A.yaml
Sostituisci /localizer con il tuo nodo. Conserva anche i file di avvio, le mappe, i file URDF, la calibrazione esterna, il commit software e la posizione iniziale. Un conteggio dei messaggi diverso da zero non garantisce che tutti gli input necessari siano presenti durante l'intervallo di errore. Esamina gli offset e gli intervalli temporali per ciascun sensore.
Utilizzare una sola sorgente temporale e un solo publisher per ogni trasformazione
In un ambiente di analisi con i publisher di input live fermi, configurare il nodo di destinazione e RViz con use_sim_time=true . I dettagli di avvio dipendono dal pacchetto, quindi riprodurre:
ros2 bag play replay-input --clock 100 --rate 1.0
L'implementazione del player Jazzy definisce l'opzione clock. Non eseguire contemporaneamente un altro publisher /clock. La registrazione con --use-sim-time e la pubblicazione di un clock durante la riproduzione hanno ruoli diversi.
Un argomento /tf può contenere più trasformazioni. Se il nodo valutato genera ora map→odom, non riprodurre anche la map→odom registrata. L'input richiesto odom→base_link potrebbe comunque necessitare di una nuova riproduzione. Escludere l'intero argomento potrebbe quindi non essere sufficiente: è necessario separare l'output al momento della registrazione o filtrare le singole trasformazioni. Vedere REP-105 per i ruoli dei frame.
Diagnosi dell'output mancante
| Sintomo | Primo controllo |
|---|---|
| I messaggi sono presenti nel bag ma non vengono ricevuti | Nomi, tipi e QoS del publisher/subscriber |
| La nuvola appare ma la posa salta | Publisher duplicati della stessa trasformazione |
| Estrapolazione della TF nel passato o nel futuro | Tempi di intestazione, tempo di simulazione e copertura della TF registrata |
| Solo la seconda riproduzione è diversa | Stato dell'estimatore, mappe e gestione dei salti temporali all'indietro |
La QoS descrive l'affidabilità e la cronologia della consegna. Verificare la compatibilità utilizzando topic info --verbose ; non rendere affidabile ogni argomento indiscriminatamente. Applicare l'override YAML solo dove necessario. Le modifiche alla durabilità delle trasformazioni statiche richiedono anche la verifica della consegna agli abbonati in ritardo.
Progettazione di un foglio di esecuzione A/B
Interrompere A, ripristinare lo stato e avviare B con un'impostazione modificata. Mantenere fissi il sacco, la frequenza di riproduzione, la posizione iniziale, la mappa e l'intervallo valutato. Salvare la traiettoria, la latenza di elaborazione, gli input mancanti e i tempi di errore. Ripetere le condizioni invariate per rivelare gli effetti della pianificazione o della casualità.
Questo valuta le reazioni a osservazioni fisse. Un comando di controllo diverso modificherebbe le future osservazioni reali, quindi la riproduzione di sensori preregistrati non può stabilire le prestazioni di guida a circuito chiuso.
Criteri di completamento
Il confronto è pronto quando arrivano gli input richiesti, ogni trasformazione ha un solo editore, il tempo è coerente e le differenze di configurazione spiegano la modifica testata. Proseguire con la valutazione SLAM per l'allineamento temporale e gli errori di traiettoria.
Criteri di completamento
Il confronto è pronto quando arrivano gli input richiesti, ogni trasformazione ha un solo editore, il tempo è coerente e le differenze di configurazione spiegano la modifica testata.
Commenti
Accedi per continuare.
Nessun dato disponibile.