话题存在与数据可达是两回事
相机驱动已经启动，话题列表里也有图像名称，但视觉节点始终没有回调。此时直接修改识别模型通常没有帮助。应先确认话题名称、类型、网络发现和发布端是否真的在发送，再看发布与订阅采用的通信约定是否兼容。
ROS 2 允许发布端和订阅端独立设置 QoS。兼容关系采用请求与提供的模型：发布端提供的能力要满足订阅端请求。以可靠性为例，best effort 发布端无法满足 reliable 订阅端，而 reliable 发布端可以与 best effort 订阅端连接。其他影响兼容性的策略也要同时满足。来源：ROS 2 官方 QoS 兼容表。
先关注几项影响明显的策略
| 策略 | 含义 | 实际问题 |
|---|---|---|
| Reliability | 尽力传输或带重传的可靠传输 | 请求是否超过发布端提供能力 |
| History / Depth | 缓存历史样本的方式与数量 | 消费者变慢后是否积压旧消息 |
| Durability | 是否为后来加入的订阅端保留数据 | 启动顺序是否影响读取已有状态 |
官方文档为传感器数据提供偏重及时性的预设，使用 best effort 和较小队列。它不是任何相机、网络和任务都必须采用的唯一配置。对于具体设备，先读取驱动实际提供的 QoS，再依据任务是否容忍丢帧、是否需要旧数据作选择。
从端点信息开始检查
在已经加载对应 ROS 环境的终端中，可以先使用以下只读命令观察端点。话题名需要替换成实际名称；不同发行版的命令选项应以本机帮助为准。
ros2 topic list -t
ros2 topic info /camera/image_raw --verbose
ros2 topic echo --help检查发布者与订阅者是否都出现在端点信息中，再对照可靠性、持久性等字段。如果驱动提供 best effort，而自写节点默认请求 reliable，先让两边匹配，再检查图像内容。命令行工具本身也可能采用不同的订阅设置，因此“命令能看到”或“命令看不到”都需要连同其 QoS 一起解释。
收到数据之后，还要确认是否过时
假设相机每秒发布 30 帧，而视觉推理只能处理 10 帧。若每条消息都按顺序排队，算法可能持续识别数秒前的画面。此时平均帧率看起来正常，机器人却总是在物体移动后慢半拍。增加队列深度只能延后丢弃，不一定解决延迟。
建议在回调入口记录消息采集时间、接收时间和处理结束时间，分别查看消息年龄与计算耗时。跨设备比较时间戳前，要确认时钟基准。对于以当前状态决策的视觉任务，可以评估保留最新观测的处理方式；对于必须完整保存的采集任务，则需要单独验证写入吞吐和丢帧情况。
把三类故障分开处理
- 没有建立连接：核对话题、类型、发现范围及 QoS 兼容性。
- 建立连接但数据不完整：观察发送频率、网络负载、接收丢失与记录链路。
- 数据到达但反应迟缓：检查队列、线程阻塞、图像预处理与模型推理时间。
每次只改变一项配置，并保留前后端点信息和时间统计。不要同时修改队列、网络和模型，然后只凭主观感觉认定问题已解决。若要判断网络重传的影响，应在相同场景与负载下比较，而不是使用两段不同任务的视频。
用任务需要定义验收条件
最终验收可以写成：连续运行一段约定时间，记录有效消息数、消息年龄分布、异常事件和节点重启后的恢复情况。允许的延迟上限来自任务速度与控制需求，不能只用“没有报错”代替。QoS 是通信策略的一部分，不会自动提供机器人系统的实时性保证。
资料来源与延伸阅读
整理更新：2026-10-26。本文基于以上公开资料，经 AI 辅助整理与扩写；实践方案为编辑建议，未作为本站实测结果发布。工具接口请结合所用版本核对。