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.
Las ejecuciones físicas repetidas modifican tanto las entradas como la configuración. rosbag2 puede mantener fijas las entradas grabadas, pero la reproducción no reproduce un robot completo de forma determinista. Este procedimiento se verificó con las fuentes primarias de ROS 2 Jazzy el 7 de septiembre de 2026; no se ha ejecutado en hardware ROS ni en una instalación de ROS en funcionamiento.
Definir el límite de comparación
Considere un localizador que utiliza datos LiDAR y odometría de ruedas. Grabe /scan, /odom y los datos necesarios /tf y /tf_static. Guarde la salida del localizador por separado como resultado de comparación, no como dato de referencia. Los experimentos con cámara también requieren información de cámara coincidente.
El README de Jazzy documenta la grabación, la inspección y las anulaciones de QoS. Guarda las versiones de los paquetes instalados y la salida de ros2 bag record --help y ros2 bag play --help con cada experimento.
Registrar entradas y configuración
Los nombres de temas y nodos que aparecen a continuación son ejemplos. Descubre los tuyos con ros2 topic list y ros2 node list, y luego graba mientras las entradas estén activas:
ros2 topic info /scan --verbose
ros2 bag record -o replay-input --topics /scan /odom /tf /tf_static
Detén la grabación correctamente con Ctrl+C y luego inspecciona:
ros2 bag info replay-input
ros2 param dump /localizer > localizer-A.yaml
Reemplaza /localizer con tu nodo. Conserva también los archivos de lanzamiento, mapas, URDF, calibración externa, confirmación de software y pose inicial. Un recuento de mensajes distinto de cero no garantiza que existan todas las entradas necesarias durante el intervalo de fallo. Examina las diferencias de tiempo y los huecos por sensor.
Usar una fuente de tiempo y un publicador por transformación
En un entorno de análisis con los publicadores de entrada en tiempo real detenidos, configure el nodo de destino y RViz con use_sim_time=true. Los detalles de inicio dependen del paquete; luego, reproduzca:
ros2 bag play replay-input --clock 100 --rate 1.0
La implementación del reproductor Jazzy define la opción de reloj. No ejecute otro publicador /clock simultáneamente. Grabar con --use-sim-time y publicar un reloj durante la reproducción tienen funciones diferentes.
Un tema /tf puede contener varias transformaciones. Si el nodo evaluado ahora genera map→odom, no reproduzca también el map→odom grabado. Es posible que la entrada requerida odom→base_link aún necesite reproducirse. Por lo tanto, excluir el tema completo puede ser insuficiente: separe la salida en el momento de la grabación o filtre las transformaciones individuales. Consulte REP-105 para obtener información sobre las funciones de los marcos.
Diagnóstico de la salida faltante
| Síntoma | Primera comprobación |
|---|---|
| Los mensajes existen en la bolsa, pero no se reciben | Nombres, tipos y QoS del publicador/suscriptor |
| La nube aparece, pero la pose salta | Publicadores duplicados de la misma transformación |
| Extrapolación de TF al pasado o al futuro | Tiempos de encabezado, tiempo de simulación y cobertura de TF registrada |
| Solo la segunda reproducción difiere | Estado del estimador, mapas y manejo de saltos de tiempo hacia atrás |
QoS describe la fiabilidad y el historial de entrega. Compruebe la compatibilidad con topic info --verbose; no asigne indiscriminadamente la fiabilidad a todos los temas. Aplique el YAML de anulación solo cuando sea necesario. Los cambios en la durabilidad de TF estática también requieren comprobar la entrega a los suscriptores tardíos.
Diseñar una hoja de ejecución A/B
Detener A, reiniciar el estado e iniciar B con una configuración modificada. Mantener fijos la bolsa, la velocidad de reproducción, la pose inicial, el mapa y el intervalo evaluado. Guardar la trayectoria, la latencia de procesamiento, las entradas faltantes y los tiempos de fallo. Repetir las condiciones sin cambios para revelar efectos de programación o aleatoriedad.
Esto evalúa las reacciones a observaciones fijas. Un comando de control diferente cambiaría las futuras observaciones reales, por lo que la reproducción de sensores pregrabados no permite establecer el rendimiento de conducción en bucle cerrado.
Criterios de finalización
La comparación está lista cuando llegan las entradas requeridas, cada transformación tiene un publicador, el tiempo es consistente y las diferencias de configuración explican el cambio probado. Continuar con la evaluación SLAM para la alineación temporal y los errores de trayectoria.
Comentarios
Inicia sesión para continuar.
Todavía no hay datos.