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.
Les exécutions physiques répétées modifient les entrées ainsi que les paramètres. rosbag2 peut conserver les entrées enregistrées, mais la relecture ne reproduit pas un robot entier de manière déterministe. Cette procédure a été vérifiée par rapport aux sources principales de ROS 2 Jazzy le 07/09/2026 ; elle n'a pas été exécutée sur du matériel ROS ni sur une installation ROS en cours d'exécution.
Définir la limite de comparaison
Considérons un localisateur utilisant les données LiDAR et l'odométrie des roues. Enregistrez /scan, /odom et les valeurs requises /tf et /tf_static. Enregistrez la sortie du localisateur séparément comme résultat de comparaison, et non comme vérité terrain. Les expériences avec la caméra nécessitent également des informations CameraInfo correspondantes.
Le fichier README de Jazzy documente l'enregistrement, l'inspection et les substitutions QoS. Enregistrez les versions des paquets installés et la sortie de ros2 bag record --help et ros2 bag play --help pour chaque expérience.
Enregistrement des entrées et de la configuration
Les noms de sujets et de nœuds ci-dessous sont des exemples. Identifiez les vôtres avec ros2 topic list et ros2 node list, puis enregistrez les données pendant que les entrées sont actives :
ros2 topic info /scan --verbose
ros2 bag record -o replay-input --topics /scan /odom /tf /tf_static
Arrêtez proprement avec Ctrl+C, puis examinez :
ros2 bag info replay-input
ros2 param dump /localizer > localizer-A.yaml
Remplacez /localizer par votre nœud. Conservez également les fichiers de lancement, les cartes, le fichier URDF, l’étalonnage externe, la validation logicielle et la pose initiale. Un nombre de messages non nul ne garantit pas la présence de toutes les entrées nécessaires pendant l’intervalle de défaillance. Examinez les décalages temporels et les intervalles pour chaque capteur.
Utiliser une source de temps et un éditeur par transformation
Dans un environnement d’analyse où les éditeurs d’entrées en direct sont arrêtés, configurez le nœud cible et RViz avec use_sim_time=true. Les détails de lancement dépendent du package, puis relancez la lecture :
ros2 bag play replay-input --clock 100 --rate 1.0
L’implémentation du lecteur Jazzy définit l’option d’horloge. Ne lancez pas un autre éditeur /clock simultanément. L’enregistrement avec --use-sim-time et la publication d’une horloge pendant la lecture ont des rôles différents.
Un sujet /tf peut contenir plusieurs transformations. Si le nœud évalué génère maintenant map→odom, ne relancez pas également le map→odom enregistré. L’entrée requise odom→base_link peut encore nécessiter une relecture. Exclure l'intégralité du sujet peut donc s'avérer insuffisant : utilisez une sortie séparée lors de l'enregistrement ou filtrez les transformations individuelles. Consultez REP-105 pour connaître les rôles des trames.
Diagnostic des sorties manquantes
| Symptôme | Première vérification |
|---|---|
| Messages présents dans le sac mais non reçus | Noms, types et QoS de l'éditeur/abonné |
| Le nuage apparaît mais la pose présente des sauts | Éditeurs dupliqués de la même transformation |
| Extrapolation TF dans le passé ou le futur | Heures d'en-tête, temps de simulation et couverture TF enregistrée |
| Seule la deuxième relecture diffère | État de l'estimateur, cartes et gestion des sauts temporels en arrière |
La QoS décrit la fiabilité et l'historique de la livraison. Vérifiez la compatibilité à l'aide de topic info --verbose ; ne rendez pas tous les sujets fiables aveuglément. Appliquez le YAML de remplacement uniquement lorsque cela est nécessaire. Les modifications apportées à la durabilité des TF statiques nécessitent également une vérification de la livraison aux abonnés tardifs.
Concevoir une feuille de route A/B
Arrêtez A, réinitialisez l'état et lancez B avec un paramètre modifié. Conservez constants le sac, la fréquence de lecture, la pose initiale, la carte et l'intervalle d'évaluation. Enregistrez la trajectoire, la latence de traitement, les entrées manquantes et les temps d'échec. Répétez l'opération dans les mêmes conditions pour révéler les effets de la planification ou de l'aléatoire.
Ceci évalue les réactions à des observations fixes. Une commande différente modifierait les observations réelles futures ; par conséquent, la relecture des données préenregistrées des capteurs ne permet pas d'établir les performances de conduite en boucle fermée.
Critères d'achèvement
La comparaison est prête lorsque les entrées requises arrivent, que chaque transformation a un seul éditeur, que le temps est cohérent et que les différences de configuration expliquent le changement testé. Poursuivez avec l'évaluation SLAM pour l'alignement temporel et les erreurs de trajectoire.
Commentaires
Veuillez vous connecter.
Aucune entrée pour le moment.