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.
Background and reading guide
Background A browser for the Lab; ROS 2 topics, parameters and TF for optional Jazzy procedures.
Hands-on · Follow the worked examples and checks under the stated conditions.
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.
Repeated physical runs change inputs as well as settings. rosbag2 can hold recorded inputs fixed, but replay does not reproduce an entire robot deterministically. This is a procedure checked against ROS 2 Jazzy primary sources on 2026-09-07; it has not been executed on ROS hardware or a running ROS installation.
Define the comparison boundary
Consider a localizer consuming LiDAR and wheel odometry. Record /scan, /odom and the required /tf and /tf_static. Save the localizer's output separately as a comparison result, not ground truth. Camera experiments also need matching CameraInfo.
The Jazzy README documents recording, inspection and QoS overrides. Save installed package versions and the output of ros2 bag record --help and ros2 bag play --help with each experiment.
Record inputs and configuration
Topic and node names below are examples. Discover yours with ros2 topic list and ros2 node list, then record while inputs are active:
ros2 topic info /scan --verbose
ros2 bag record -o replay-input --topics /scan /odom /tf /tf_static
Stop cleanly with Ctrl+C, then inspect:
ros2 bag info replay-input
ros2 param dump /localizer > localizer-A.yaml
Replace /localizer with your node. Also preserve launch files, maps, URDF, external calibration, software commit and initial pose. Nonzero message counts do not establish that every necessary input exists during the failure interval. Examine timestamp offsets and gaps per sensor.
Use one time source and one publisher per transform
In an analysis environment with live input publishers stopped, configure the target node and RViz with use_sim_time=true. Launch details depend on the package, then replay:
ros2 bag play replay-input --clock 100 --rate 1.0
The Jazzy player implementation defines the clock option. Do not run another /clock publisher concurrently. Recording with --use-sim-time and publishing a clock during playback have different roles.
A /tf topic can contain multiple transforms. If the evaluated node now generates map→odom, do not also replay the recorded map→odom. Required input odom→base_link may still need replay. Excluding the whole topic may therefore be insufficient: separate output at recording time or filter individual transforms. See REP-105 for frame roles.
Diagnose missing output
| Symptom | First check |
|---|---|
| Messages exist in the bag but are not received | Names, types and publisher/subscriber QoS |
| Cloud appears but pose jumps | Duplicate publishers of the same transform |
| TF extrapolation into past or future | Header times, simulation time and recorded TF coverage |
| Only the second replay differs | Estimator state, maps and handling of backward time jumps |
QoS describes delivery reliability and history. Check compatibility using topic info --verbose; do not blindly make every topic reliable. Apply override YAML only where needed. Changes to static-TF durability also require checking delivery to late subscribers.
Design an A/B run sheet
Stop A, reset state and launch B with one changed setting. Keep the bag, playback rate, initial pose, map and evaluated interval fixed. Save trajectory, processing latency, missing inputs and failure times. Repeat unchanged conditions to reveal scheduling or randomness effects.
This evaluates reactions to fixed observations. A different control command would change future real observations, so replaying prerecorded sensors cannot establish closed-loop driving performance.
Completion criteria
The comparison is ready when required inputs arrive, each transform has one publisher, time is consistent and configuration differences explain the tested change. Continue with SLAM evaluation for temporal alignment and trajectory errors.
Comments
Please log in to post a comment
No comments yet.