2.3 QoS不匹配与发现失败排错实录
2.3 QoS 不匹配与发现失败排错实录
本节摘要：第 1.3 节用五层排查法解决过"收不到消息"，本节回到同一症状的更深处：一次发布端与订阅端 QoS 合约谈崩的完整排错。你将看到合约不匹配如何制造出"双方都在运行、互相却不存在"的静默现场，如何用两行命令让真相显形，以及发现失败与匹配失败这两类近亲故障的鉴别诊断。本节是 2.2 理论的现场验收。
一个必须先建立的预期
先给一个反直觉的预期：QoS 不匹配不报任何错。没有异常、没有日志、没有红字，DDS 在发现阶段就把这对发布者与订阅者判定为"不合适"，双方各自安静运行。这个设计在协议层面合理——不匹配不是错误而是合法的分歧——但给调试者挖了大坑。所以本节的排错起点不是看日志，而是养成一个条件反射：收不到消息，先看两端的 QoS。
一、背景：相机驱动与识别节点互相失联
现场是一台巡检机器人的视觉链路。驱动节点发布 10 Hz 的相机流，新写的识别节点订阅它做缺陷检测。上电后识别节点日志显示"等待图像数据"，RViz 里图像窗口黑着，但驱动自己的预览窗口一切正常——图像它自己看得见。
问过交接的同事，得到两条线索：驱动是从厂商 SDK 封装的，QoS 用了 sensor_data 预设；识别节点的订阅代码是从教程里抄的，用了默认 QoS。两条线索放在一起，病灶已经呼之欲出，但当时的排查者并不知道默认 QoS 与 sensor_data 预设的差异意味着什么，于是有了下面这段完整过程。
二、操作：三步让静默的合约破裂显形
第一步，从订阅侧确认"DDS 眼里有没有这个发布者"。 在识别节点的机器上：
ros2 topic info /camera/image_raw -v # 关键输出摘录 # Type: sensor_msgs/msg/Image # Publisher count: 1 # Subscription count: 1 # # Node name: camera_driver # Reliability: BEST_EFFORT # Durability: VOLATILE # # Node name: defect_detector # Reliability: RELIABLE # Durability: VOLATILE
这一步的信息量极大：DDS 的发现协议工作正常——双方都发现了彼此，Publisher count 与 Subscription count 都是 1；但两端的可靠性合约一栏并排写着 BEST_EFFORT 与 RELIABLE。按 2.2 节的判定规则：订阅方要求 reliable，发布方只承诺 best_effort，要求强于承诺，连接不建立。发现成功、匹配失败——这就是"看得见、连不上"的完整解释。
第二步，验证判断。 把订阅端改成 best_effort 再跑，图像立刻出现在识别节点。或者不改代码，用命令行临时验证：
ros2 topic echo /camera/image_raw --qos-reliability best_effort --once # 能打印出一帧图像，证实发布端数据流本身是好的
第三步，确认这类故障的一般形态。 把发现与匹配两个阶段画在一张时序图上，故障发生在哪一环一目了然：
三、结果与解读
最终修复是一次双向重构，而不是简单把订阅端改成 best_effort 了事。识别链路要的是"稳定拿到每帧做检测"，对丢帧其实敏感，于是驱动端保留 best_effort（相机流补旧帧无意义），识别节点订阅改为 sensor_data 预设并加上 deadline 监测——若连续超时未到帧，日志报警而不是沉默等待。驱动侧另开了一条低频的参数话题用 reliable，承载配置类指令。修完的链路在断网 30 秒再恢复的测试里表现正常。
解读这段现场，有三层认识值得沉淀。第一层，发现与匹配是两件事。 topic list 能看到话题、info -v 能数出双方，都只证明发现层正常；数据流是否建立取决于合约审查。1.3 节排查的域与组播问题发生在发现层，本节的 QoS 问题发生在匹配层，同一症状、不同病灶，鉴别工具就是 info -v 的计数与合约栏。第二层，静默失败是 QoS 机制的固有属性。 协议认为"你要求的我给不了"是合法立场，所以不报错。要对抗静默，只能靠流程：所有新建的发布订阅，写完立刻用 info -v 对一遍两端合约，把验证做在集成阶段而不是现场。第三层，修复要顺着数据语义，而不是顺着报错。 因为没有报错，所以"改成能通就行"的诱惑很大，但可靠性与否的选择本质是业务问题——这条数据丢一帧代价是什么，答案不同，QoS 就不同。
四、变式：合约破裂的三张近亲面孔
变式一：durability 不匹配。 订阅方要求 transient_local（想拿到最近一帧），发布方是 volatile。症状同样是静默，常见于静态 TF 与地图话题：晚启动的节点永远等不到首帧。鉴别方法是看 info -v 的 durability 栏。
变式二：历史深度相关的伪丢包。 合约匹配、连接建立，但订阅端 depth 太浅且回调太慢，队列里旧数据被不断顶替，表现为"偶发跳帧"。它与 QoS 不匹配的区别在于：不是收不到，而是收不全。解法在回调效率而非 QoS，属于第 3.1 节执行器的话题。
变式三：发现层失败再回首。 若 info -v 的计数有一方为零（而不是双方都在但合约相左），那说明问题在发现层——回到 1.3 节的域、实现、组播三连查。两类故障用同一条命令完成鉴别，这正是把它排进第一步的原因。
⚠️ 常见坑：不同 ROS2 发行版的默认 QoS 有过调整，从旧教程抄来的订阅代码可能带着过时预设。升级发行版后传感器流"突然看不见"，先把新旧两端的 QoS 逐字段对一遍。
本节要点回顾
- QoS 不匹配零报错：发现成功、匹配失败，双方互不感知，info -v 是唯一显影工具；
- 鉴别口诀：计数双全看合约栏，计数为零回发现层，两条路线在一条命令处分叉；
- topic echo 的临时 QoS 参数可不改代码快速验证发布端数据流健康；
- 修复顺着数据语义走：丢一帧的代价决定可靠性选择，而不是"能通就行"；
- 把合约核对做进集成流程，是对抗静默失败的唯一系统性手段。
通信基座已经拆到底了。下一章回到你写代码的那一层，看四种通信模式各自该怎么选、怎么用。