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.
Execuções físicas repetidas alteram as entradas, bem como as configurações. O rosbag2 pode manter as entradas gravadas fixas, mas a reprodução não reproduz um robô inteiro de forma determinística. Este procedimento foi verificado com base nos códigos-fonte primários do ROS 2 Jazzy em 07/09/2026; ele não foi executado em hardware ROS ou em uma instalação ROS em execução.
Defina o limite de comparação
Considere um localizador que utiliza LiDAR e odometria de rodas. Registre /scan, /odom e os valores necessários /tf e /tf_static. Salve a saída do localizador separadamente como um resultado de comparação, não como um valor de referência. Experimentos com câmeras também precisam de CameraInfo correspondente.
O README do Jazzy documenta a gravação, a inspeção e as configurações de QoS. Salve as versões dos pacotes instalados e a saída de ros2 bag record --help e ros2 bag play --help a cada experimento.
Registre as entradas e a configuração
Os nomes de tópicos e nós abaixo são exemplos. Descubra os seus com ros2 topic list e ros2 node list, e então grave enquanto as entradas estiverem ativas:
ros2 topic info /scan --verbose
ros2 bag record -o replay-input --topics /scan /odom /tf /tf_static
Encerre o experimento corretamente com Ctrl+C e então inspecione:
ros2 bag info replay-input
ros2 param dump /localizer > localizer-A.yaml
Substitua /localizer pelo seu nó. Preserve também os arquivos de inicialização, mapas, URDF, calibração externa, confirmação de software e pose inicial. Contagens de mensagens diferentes de zero não garantem que todas as entradas necessárias existam durante o intervalo de falha. Examine os deslocamentos e lacunas de carimbo de data/hora por sensor.
Use uma fonte de tempo e um publicador por transformação
Em um ambiente de análise com publicadores de entrada ao vivo interrompidos, configure o nó de destino e o RViz com use_sim_time=true . Os detalhes de inicialização dependem do pacote e, em seguida, reproduza:
ros2 bag play replay-input --clock 100 --rate 1.0
A implementação do reprodutor Jazzy define a opção de relógio. Não execute outro publicador /clock simultaneamente. A gravação com --use-sim-time e a publicação de um relógio durante a reprodução têm funções diferentes.
Um tópico /tf pode conter várias transformações. Se o nó avaliado gerar map→odom, não reproduza também o map→odom gravado. A entrada necessária odom→base_link ainda pode precisar de reprodução. Portanto, excluir todo o tópico pode ser insuficiente: separe a saída no momento da gravação ou filtre transformações individuais. Consulte REP-105 para obter informações sobre as funções dos quadros.
Diagnóstico de saída ausente
| Sintoma | Primeira verificação |
|---|---|
| Mensagens existem no pacote, mas não são recebidas | Nomes, tipos e QoS do publicador/assinante |
| Nuvem aparece, mas apresenta saltos de pose | Publicadores duplicados da mesma transformação |
| Extrapolação de TF para o passado ou futuro | Horários do cabeçalho, tempo de simulação e cobertura de TF registrada |
| Apenas a segunda reprodução difere | Estado do estimador, mapas e tratamento de saltos de tempo para trás |
QoS descreve a confiabilidade e o histórico de entrega. Verifique a compatibilidade usando topic info --verbose ; não torne todos os tópicos confiáveis indiscriminadamente. Aplique o YAML de substituição somente quando necessário. Alterações na durabilidade do TF estático também exigem a verificação da entrega aos assinantes atrasados.
Elabore uma planilha de teste A/B
Pare o veículo A, reinicie o estado e inicie o veículo B com uma configuração alterada. Mantenha fixos o conjunto de dados, a taxa de reprodução, a pose inicial, o mapa e o intervalo avaliado. Salve a trajetória, a latência de processamento, as entradas ausentes e os tempos de falha. Repita as condições inalteradas para revelar os efeitos de agendamento ou aleatoriedade.
Isso avalia as reações a observações fixas. Um comando de controle diferente alteraria as observações reais futuras, portanto, reproduzir sensores pré-gravados não pode estabelecer o desempenho de direção em malha fechada.
Critérios de conclusão
A comparação está pronta quando as entradas necessárias chegam, cada transformação tem um publicador, o tempo é consistente e as diferenças de configuração explicam a mudança testada. Continue com a avaliação SLAM para alinhamento temporal e erros de trajetória.
Comentários
Entre na sua conta para continuar.
Ainda não há dados.