ROS 2 仿真和回放时间不一致：从时钟来源开始排查

机器人在真实设备上运行正常，换到仿真或录包回放后却出现等待、数据时间对不上，原因不一定是算法失效。一个容易忽略的问题是：不同节点可能正在使用不同的时间来源。本文围绕 ROS 2 的时间设计，介绍如何在测试环境里梳理时间来源、暂停与回放，不把仿真现象直接当成设备故障。

先画出系统里的时间来源

检查时先列出参与节点、消息时间戳的产生方，以及仿真器或回放程序是否提供时钟。系统时间与 ROS 时间承担的用途不同；同一条数据从传感器经过处理再到可视化，若各节点对时间来源的理解不同，就可能造成看起来数据很新、另一处却认为数据过期的情况。不要仅凭电脑右下角的时间判断节点所用的时钟。

ROS 2 官方的时钟与时间设计说明介绍了系统时间、稳态时间和 ROS 时间，以及节点启用 use_sim_time 后 ROS 时间的行为。具体功能仍需结合正在使用的 ROS 发行版和节点实现核实。

逐个节点核对仿真时间配置

把参与测试的节点列成表，分别记录名称、命名空间、use_sim_time 的实际值和启动方式。不要只检查启动文件里是否写过这个参数：实际运行时可能有节点未接收到配置，也可能有后来启动的节点使用了不同配置。对关键数据记录消息的时间戳和接收方的当前时间，确认它们是否属于同一时间基准。

若启用了仿真时间，再确认系统里是否存在预期的 /clock 来源、数据是否持续更新。尚未收到时间时，ROS 时间可能处于未初始化状态；因此启动顺序和等待条件需要明确。测试记录应写清楚谁发布时钟以及何时开始发布，避免把短暂的初始化等待误认成永久卡死。

暂停、加速与回跳都要单独测试

仿真时钟可以跟随仿真推进，暂停时可能停止；回放或重置也可能使时间发生跳变。因此，用仿真时间计算间隔的程序，不应默认它总是像现实世界里的秒表一样连续向前。准备三组小测试：正常运行后暂停再恢复、改变播放速度、重置或从较早的位置重新开始。每次记录事件、相关节点和时间戳变化，检查缓存、超时逻辑与界面是否按设计处理。

举一个假设场景：仿真暂停时，界面中的状态时间不再前进，而电脑系统时间仍在变化。此时应先核对状态组件是否使用仿真时钟，再决定这是不是产品缺陷。对于需要约束实际设备等待时长的逻辑，也应由负责人审查所选时间源和安全要求，不能仅因为仿真方便就随意更换。

回放时区分数据与时钟

录包能重放消息，但不能假设每一种回放配置都会以相同方式提供时钟。查看当前版本的工具选项，并记录数据包本身是否包含时钟话题、回放过程是否另行发布时钟。ROS 2 的 rosbag2 播放选项定义列出了与时钟发布相关的配置；不同发行版的可用选项和命令界面应以对应版本文档为准。

排查时先关闭无关系统，在隔离测试环境中回放一小段数据，观察时钟与一个关键消息的时间戳。再逐个加入处理节点，找出第一个出现时间差异的环节。若需要让多个进程共享一个测试时钟，先确认不会有多个来源互相干扰，并记录版本和启动顺序，便于他人复现。

形成可交接的排查记录

一份有效记录至少包括 ROS 版本、节点列表、每个节点的时间配置、时钟发布方、回放数据来源、暂停或重置的操作，以及观察到的时间戳。记录异常开始前后的原始信息，并区分“没有消息”“时钟没有更新”和“消息时间与接收方不一致”这几种现象。解决后重复同一测试，说明哪些现象消失、哪些仍有待确认。