2.2 DDS核心原理与QoS策略

2.2 DDS 核心原理与 QoS 策略

本节摘要：DDS 是 ROS2 的通信基座，也是多数"诡异通信行为"的最终解释。本节承接 2.1 的分层地图，钻进抽象层之下的世界：以数据为中心的模型、两阶段发现协议，以及 reliability、durability、history 等核心 QoS 的精确语义。读完本节，你能对任意一对发布订阅的兼容性做出判断，这是 2.3 排错实录的理论弹药。

QoS 不是参数，是合约

初学者常把 QoS 当成"一堆可调参数"，调不对就试另一组——这是把它用错了。QoS 的本质是发布方与订阅方之间的合约：发布方声明"我承诺怎样发"，订阅方声明"我要求怎样收"，DDS 在发现阶段就审查双方是否匹配，不匹配就不建立连接。把这一层想透，"为什么收不到消息还毫无报错"就从一个玄学问题变成了一个可推导的结论：合约谈崩了。

一、以数据为中心：DDS 与消息队列的根本区别

DDS 全称数据分发服务，它的设计立场藏在名字里：中心是数据，不是消息。传统消息队列（如各类 MQ）的模型是"生产者把消息投进队列，消费者从队列取"，队列是中介。DDS 里没有队列中介：发布者声明"我负责更新名为 chatter 的数据"，订阅者声明"我关心名为 chatter 的数据"，双方在网络里直接对上，共享的与其说是消息流，不如说是一个分布式"主题数据空间"。

这个立场带来三个可观察的行为差异。第一，发现是双向对等的：双方各自广播自己的能力，不经过任何中介，这与 1.1 节说的去中心化一脉相承。第二，数据可以被"记住"：主题可配置为保留最新几条或最后一条，新加入的订阅者能立刻拿到历史数据——传感器数据流里"晚加入立刻拿到最近一帧位姿"就是这么实现的。第三，QoS 是主题级别的属性而非传输的附属品，这让"可靠性、时效性"成为可声明的合约。

DDS 生态里有几个角色名词值得认识：参与者（participant，一个进程内的通信容器）、写者（writer，发布端的话题出口）、读者（reader，订阅端的话题入口）。ros2 daemon 在后台就跑着这样一个参与者，替命令行工具探听全网话题——这也是为什么 daemon 偶尔抽风时 topic list 会显示过期信息，重启 daemon 即可解决。

二、两阶段发现协议

没有中央服务器，节点怎么知道彼此的存在？答案是组播加两阶段握手。第一阶段叫 SPDP：每个参与者周期性地向预定义组播地址广播自己的"自我介绍"——参与者 ID、所在域、提供与需要哪些主题。第二阶段叫 SEDP：双方就共同感兴趣的主题交换更详细的信息——具体类型、QoS 合约、单播地址，随后建立点对点数据通道。

节点A进程                          节点B进程
   |SPDP 广播自我介绍 -->            |
   |           <-- SPDP 广播自我介绍 |（周期性，默认几秒一轮）
   |SEDP 就 chatter 主题协商 -->     |
   |        <-- SEDP 协商确认        |
   |单播数据通道建立，开始传数据      |
​

这套机制的工程含义有三条。组播必须可用——1.3 节里 AP 过滤组播导致的失联，掐断的就是 SPDP。发现需要时间——节点启动后通常要几百毫秒到几秒才互相可见，"启动后立刻发布第一条消息没人收"是新手常见误判，不全是故障。域隔离发生在 SPDP 层——不同域的自我介绍互相忽略，所以域不一致时连"发现失败"的痕迹都找不到，只有沉默。

三、核心 QoS 逐条拆解

QoS 策略有一二十种，日常真正决定行为的就六种。逐条说语义与典型选择。

reliability（可靠性）：reliable 承诺重传补齐，best_effort 不承诺。控制指令、任务目标必须 reliable；高频传感器流通常 best_effort——丢一帧点云无所谓，为补一帧旧点云排队才是灾难。

durability（持久性）：volatile 不留历史，晚到的订阅者从加入时刻开始收；transient_local 保留最后若干条，晚到者立刻拿到。这是"晚加入拿不到 map 或 tf 静态数据"问题的答案：静态坐标变换的发布者必须用 transient_local。

history 与 depth（历史）：keep_last 加深度 N 表示每个读者缓存最新 N 条，写快读慢时旧数据被挤掉；keep_all 尽量全留。深度是内存与时效的权衡：传感器流 depth 设 1 到 5 足够，攒队列反而是过时数据堆积。

deadline（截止期）：双方约定"每隔 T 必须有一帧新数据"，超时触发事件。这是做健康监测的现成钩子：位姿流承诺 10 Hz，超过 0.5 秒没来，订阅端能感知并触发保护动作，而不是傻等。

lifespan（寿命）：每条数据自带过期时间，过期即弃。适合"时效即价值"的数据：一秒前的障碍物距离没有意义，与其发给下游不如丢弃。

liveliness（存活）：双方约定存活报告方式，失联时订阅端收到通知。它与 deadline 的分工：deadline 管“数据来没来”，liveliness 管“对方还在不在”。

图 2-2：传感器流与控制流的不同 QoS 组合

四、兼容性判定与代码写法

合约审查的规则一句话：订阅方要求什么，发布方就得承诺什么，只能更强不能更弱。订阅方要 reliable，发布方只肯 best_effort，不匹配，连接不建立；反过来订阅方只要 best_effort、发布方是 reliable，可以匹配，多余的承诺被降级使用。durability 同理：订阅方要 transient_local，发布方是 volatile，不匹配。注意"不匹配"的表现不是报错，而是双方互相看不见对方的存在——这就是 2.3 节排错实录里那个静默现场的成因。

# Python 端写法：给订阅者声明 sensor 风格 QoS
from rclpy.qos import qos_profile_sensor_data, QoSProfile, ReliabilityPolicy

sub = node.create_subscription(
    LaserScan, 'scan', on_scan, qos_profile_sensor_data)
# qos_profile_sensor_data 即 best_effort 加 keep_last 深度 5 的预设

# 自定义：控制指令要可靠
qos = QoSProfile(reliability=ReliabilityPolicy.RELIABLE, depth=5)
cmd_sub = node.create_subscription(Twist, 'cmd_vel', on_cmd, qos)
​

ROS2 为常见场景准备了预设：sensor_data、系统默认（reliable 加 volatile 深度 10）、参数服务等。用预设能避开八成配置错误；需要偏离预设时，从预设出发改单字段，别从零手搓。

⚠️ 常见坑：把订阅端 QoS 写成 reliable 去收传感器驱动默认 best_effort 的数据流，是"驱动明明在跑、RViz 就是不显示"的头号成因。RViz 里显示不出传感器数据时，先查它的可靠性设置再怀疑别的。

本节要点回顾

• 数据为中心：主题双方直接对上，可保留历史，QoS 是主题级合约而非传输附属品；
• 发现两阶段：组播自我介绍在先，单播细节协商在后，组播不可用则一切沉默；
• 六大 QoS：可靠性管补不补，持久性管留不留，历史管存几条，截止期与存活管健康感知；
• 兼容规则：订阅方要求、发布方承诺，只能更强；不匹配的代价是静默互不可见；
• 用预设 QoS 起步，偏离时逐字段修改，能避开绝大多数配置错误。

下一节把本节的合约机制放回现场：一次真实的 QoS 不匹配排错，你会看到合约破裂时的完整症状链。