ROS 2 rosbag2回放无输入 QoS排查与验证

本文从ROS 2端点兼容性入手，给出文件、端点和原始回调三组证据的检查顺序，并说明QoS覆盖的边界。

做移动机器人实验时，你可能遇到这样的场景：采集结束后，ros2 bag info 能看到传感器话题和消息数量；回放进度也在走，可算法没有输出。第一反应往往是“数据坏了”，或者“再录一次”。

先分清两个问题：算法的订阅回调完全没收到消息，还是已经收到消息，却因时间、坐标变换或输入同步等条件不满足而没有结果？这两种情况的排查入口不同。

本文先看第一类中的常见原因：回放发布端与算法订阅端的 QoS 不兼容。文件里有消息，不代表当前这两个端点一定能通信。[1][2]

图 1｜录制和回放面对不同端点，应分别核对。

适用范围：ROS 2 / rosbag2，示例以 Jazzy 为主；Humble 官方文档也提供 QoS 覆盖方式。不同发行版、补丁版本和 RMW 实现可能存在差异，以本机 --help 和实际端点信息为准。本文不适用于 ROS 1 rosbag，也不预设任何设备的版本、传感器组合或默认 QoS。[2][8]

01 谁提供，谁要求？

录制时，rosbag2 是订阅者；回放时，它变成发布者。算法节点则按自身配置建立订阅。rosbag2 会适配录制与回放的 QoS，并尝试保留原话题提供的策略，但仍需检查当前算法的要求。[2]

reliability 可以理解为通信双方约定的交付方式。best_effort 发布端无法满足 reliable 订阅端；reliable 发布端可以与 best_effort 订阅端匹配。双方不必逐字相同。[1]

| 发布端提供 | 订阅端要求 | 仅看 reliability |

| — | — | — |

| best_effort | best_effort | 兼容 |

| best_effort | reliable | 不兼容 |

| reliable | best_effort | 兼容 |

| reliable | reliable | 兼容 |

表 1｜可靠性兼容关系。最终连接仍需其他相关策略兼容。[1]

durability 也有方向性：volatile 发布端不能满足 transient_local 订阅端；反过来可以匹配，但 volatile 订阅者不因此获得订阅前的历史消息。需要迟加入者接收保留样本时，应检查两端的 transient_local 与历史保留范围。[1]

别把“提高可靠性”当成万能修复

把回放端改成 reliable，不会补回采集时没录下的帧，也不保证算法每帧都能处理。QoS 匹配之后，还要观察队列、资源占用和处理速度。

本文优先查 reliability 和 durability；若项目显式配置了 deadline、liveliness 或 lease duration，也应检查完整兼容规则。history/depth 影响缓存行为，不能仅因两端 depth 不同就判断为不兼容。[1]

对于学习科研项目，建议把采集端点配置、回放命令和算法输入要求一起归档。换电脑或换算法时，这些记录能帮助你确定哪一环发生了变化。

02 用三组证据缩小问题

先在离线实验环境操作。不要把整包直接回放到仍连接执行器的机器人系统，尤其避免重放速度、控制或触发类话题。可先只选择待查传感器话题。下面 /scan、my_bag 和节点名都是占位示例，不代表产品配置。

第一组：文件里有“需要的那一路”吗？

echo "$ROS_DISTRO"
ros2 bag info my_bag
ros2 bag play --help

核对目标话题的完整名称、类型、数量和时长。整包消息很多，不代表需要的那一路存在或完整。若读取报错，先查存储插件、消息类型支持或文件问题，不要先改 QoS。[3]

第二组：回放端和算法端实际是什么？

ros2 topic list -t
ros2 node info /your_algorithm_node
ros2 topic info /scan --verbose

让回放与算法同时运行，再看端点详情：谁在发布，算法是否订阅了相同完整名称，类型是否一致，QoS 各是什么。–verbose 展示端点与 QoS；订阅数量大于零本身不能证明算法收到消息。[4]

看不到目标端点时，先核对进程、命名空间、重映射、ROS_DOMAIN_ID，以及环境的发现与网络配置。不同 Domain ID 的节点不能直接互相发现。[4][7]

第三组：是否进入算法的最前端回调？

在最前端订阅回调处加低频计数日志，再分别观察同步器、TF 查询和输出阶段。若原始回调已经收到数据，应优先向后排查。这是建议的诊断方法，不是某个软件包的固定实现。

ros2 topic echo 是另一个订阅者，可能采用不同 QoS。echo 能打印，只能说明这个观察端收到了；不打印也要先检查其自身 QoS 与启动时机。不要用它替代算法端证据。[4]

03 明确覆盖配置，再做对照

假设已经查到：回放端 /scan 为 best_effort，算法订阅端要求 reliable，其他条件无明显冲突。可在隔离环境中构造回放 QoS 覆盖配置，做前后对照。先记录完整端点 QoS，不能把“YAML 只写少数字段”等同于“只有这些字段发生改变”。[1][2][9]

新建 playback_qos.yaml：

/scan:
  history: keep_last
  depth: 10
  reliability: reliable

单话题诊断回放：

ros2 bag play my_bag --topics /scan \
  --qos-profile-overrides-path playback_qos.yaml

以上只是示例：显式填写 history、depth 和 reliability。Jazzy 的解析路径要求 history/depth 至少有一个被指定；keep_last 需要 depth。这里的 10 不是通用推荐值。[10] 命中覆盖项时，播放器采用该覆盖 profile，而不是逐字段继承原始记录的 QoS。未填写字段可能回退默认，改变 durability 等其他策略。须核对前后全部 QoS，必要时显式保留原值；话题名与缓存深度按实际需求调整。[2][9]

先启动订阅端，确认就绪，再回放。重新检查 --verbose 中全部 QoS 是否符合预期，记录回调计数是否从零增长。若仍为零，保留日志继续查其他条件；不要一口气改多个参数后，仅凭“有输出”宣布根因。

另一条路：调整算法订阅策略

若算法允许丢失少量样本、偏重最新数据，也可评估在算法配置或代码中使用兼容的 best_effort 订阅。是否可改取决于数据需求，不能为了接上话题一律降低要求。两条路线分开试，便于判断因果。

验证链路后，回到完整输入

单话题测试用于验证订阅链路，不一定让完整算法产出。多输入算法需要补齐真正依赖的图像、IMU、里程计或 TF 等，再验证时间与坐标关系。

实验记录至少包括：ROS 发行版与软件包版本、RMW 实现、bag 来源、回放命令、QoS YAML、端点详情及前后回调计数。这里的示例没有在实机上执行，不能作为实测结论。

04 QoS 没问题，还要查什么？

话题、类型或工作空间不一致

检查 bag 里的名称与算法最终订阅名，核对命名空间、remap、消息类型与自定义接口版本；确认终端加载了正确环境。相似名称不等于同一输入。[4]

时间体系没有统一

回放时间戳可能来自过去。若算法按“当前时间”做超时或 TF 查询，检查 use_sim_time、/clock 与数据时间戳是否一致。需要仿真时间时按本机帮助使用回放 --clock，并让相关节点使用同一时间源。–clock 不会自动切换所有节点，也不会替你改写消息 header.stamp。[3][5]

TF 或多输入条件不满足

检查坐标系是否存在、消息时刻能否查到对应变换。缺少必要 TF 时，收到传感器消息也可能无法处理。[6] 同步类算法还应检查各路输入是否齐全、时间戳是否接近、队列是否足够。先看原始回调，再看同步回调，可区分“收不到”与“凑不齐”。

启动晚了，或处理速度跟不上

迟启动可能错过关键初始消息；短包尤其需留意发现与初始化时间。先启动算法再播放，并在隔离环境低速重放，观察 CPU、队列和丢弃日志。慢放改善只能提示时序或负载相关，尚不能单凭此定位根因。

节点本身尚未可用

检查生命周期状态、必需参数、回调执行及异常日志。订阅成功但业务回调被阻塞、等待初始化或主动丢弃，同样可能表现为没有输出。这些分支需项目日志验证。

把“没结果”拆成可以观察的阶段

文件有目标数据 → 发布端可见 → 订阅策略兼容 → 原始回调收到 → 时间与 TF / 同步条件满足 → 算法输出。逐段验证，比反复重录更容易保留证据。

ROS 2 学习科研实践可以从一段短包开始：先复现单个输入，再接回完整算法。每次只改一个变量，把可复现现象与未验证猜测分开记录。

参考来源与版本核对

以下为 ROS 官方文档或官方仓库，查阅日期：2026-11-05。编号对应正文论点；命令按官方接口重新组织，图示与叙述为原创。

[1] Jazzy：Quality of Service settings

https://github.com/ros2/ros2_documentation/blob/jazzy/source/Concepts/Intermediate/About-Quality-of-Service-Settings.rst

[2] Jazzy：rosbag2 QoS 覆盖指南

https://github.com/ros2/ros2_documentation/blob/jazzy/source/How-To-Guides/Overriding-QoS-Policies-For-Recording-And-Playback.rst

[3] rosbag2 Jazzy README

https://github.com/ros2/rosbag2/blob/jazzy/README.md

[4] Jazzy：Understanding topics，含 --verbose

https://github.com/ros2/ros2_documentation/blob/jazzy/source/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst

[5] ROS 2 设计文档：Clock and Time

https://design.ros2.org/articles/clock_and_time.html

[6] Jazzy：Debugging tf2 problems

https://github.com/ros2/ros2_documentation/blob/jazzy/source/Tutorials/Intermediate/Tf2/Debugging-Tf2-Problems.rst

[7] Jazzy：About Domain ID

https://github.com/ros2/ros2_documentation/blob/jazzy/source/Concepts/Intermediate/About-Domain-ID.rst

[8] Humble：QoS 覆盖指南（版本交叉核对）

https://github.com/ros2/ros2_documentation/blob/humble/source/How-To-Guides/Overriding-QoS-Policies-For-Recording-And-Playback.rst

[9] Jazzy player.cpp：publisher_qos_for_topic 覆盖优先级

https://raw.githubusercontent.com/ros2/rosbag2/jazzy/rosbag2_transport/src/rosbag2_transport/player.cpp

[10] Jazzy rclpy qos.py：QoSProfile 参数校验

https://raw.githubusercontent.com/ros2/rclpy/jazzy/rclpy/rclpy/qos.py