3. DDS基础：标准、核心概念与QoS策略

在深入ROS 2的通信配置之前，必须先理解其底层基石——DDS（Data Distribution Service，数据分发服务）。ROS 2之所以放弃ROS 1的TCP/UDP直连式通信，转而采用DDS，核心原因在于DDS提供了去中心化的实时数据分发、丰富的QoS策略以及跨平台/跨语言的标准化接口。本节将拆解DDS的体系结构，厘清域、参与者、主题、发布订阅等核心概念，并重点剖析QoS策略如何决定通信行为。

3.1 DDS标准体系：OMG与实现层次

DDS由对象管理组织（OMG）制定标准，并非单一协议，而是一组规范的集合。理解其分层有助于后续配置时定位问题。

• DDSI-RTPS（Real-Time Publish-Subscribe Protocol）：位于传输层之上的线协议，定义了数据在网络上如何序列化、寻址和传输。它基于UDP/IP，支持组播和单播，是不同DDS实现之间互操作的基石。
• DDS核心规范：定义了以数据为中心的发布-订阅（DCPS）模型，即我们常说的域、参与者、主题、发布者、订阅者等API接口。
• DDS-XTypes：定义了数据类型系统，确保不同语言（C++、Python等）描述的数据结构在网络上能一致地序列化与反序列化。

目前ROS 2默认使用的DDS实现包括Fast DDS（eProsima）、Cyclone DDS（Eclipse）、RTI Connext等。它们都遵循上述标准，但默认的QoS策略映射和传输参数略有差异，这会导致跨厂商通信时出现“看似连接成功，但数据不通”的现象。

3.2 核心概念：从域到发布订阅

DDS的模型是围绕“全局数据空间”构建的。下图展示了DDS的核心概念及其关系，这是理解通信配置的基础。

图中展示了两个域参与者（通常对应ROS 2中的两个节点）通过主题进行数据交换的逻辑结构。核心概念定义如下：

• 域（Domain）：一个逻辑隔离的网络分区。只有处于相同域ID的参与者才能通信。ROS 2中通过环境变量ROS_DOMAIN_ID设置，默认值为0。不同域之间物理隔离，即使在同一台机器上也不会互相干扰。
• 域参与者（DomainParticipant）：域通信的入口。一个进程可以创建多个参与者，但通常一个ROS 2节点对应一个参与者。它负责管理所有发布者、订阅者和主题对象。
• 主题（Topic）：数据流的命名通道。主题由名称和数据类型唯一标识。发布者和订阅者必须同时匹配名称和类型才能建立连接。
• 发布者（Publisher）与数据写入器（DataWriter）：发布者负责创建和管理DataWriter。DataWriter是实际发送数据的对象，它将应用程序的数据序列化并写入DDS全局数据空间。
• 订阅者（Subscriber）与数据读取器（DataReader）：订阅者创建DataReader，后者监听主题数据，并将接收到的数据反序列化后交给应用程序回调。

3.3 QoS策略：通信行为的“契约”

QoS（Quality of Service）是DDS最强大的特性，它定义了数据发送和接收的行为约束。ROS 2将常用的QoS组合封装为QoS配置文件（如sensor_data、parameters、services_default），但底层仍对应DDS的独立策略。以下是最关键的几种策略：

3.4 案例：传感器数据链路中的QoS配置

假设我们有一个移动机器人，包含一个激光雷达节点（发布/scan）和一个导航节点（订阅/scan）。若导航节点使用默认的RELIABLE策略，而雷达节点发布时使用BEST_EFFORT，则两者不兼容，导航节点将收不到任何数据。正确的配置应如下：

// 雷达节点（发布者）
rclcpp::QoS qos_scan(10); // History深度为10
qos_scan.best_effort();   // 设置BEST_EFFORT可靠性
qos_scan.durability_volatile(); // 不保留历史
pub_scan = node->create_publisher<sensor_msgs::msg::LaserScan>("/scan", qos_scan);

// 导航节点（订阅者）
rclcpp::QoS qos_sub(10);
qos_sub.best_effort();    // 必须与发布者匹配
sub_scan = node->create_subscription<sensor_msgs::msg::LaserScan>("/scan", qos_sub, callback);

对于地图数据（如/map），我们希望晚加入的定位节点能立即获取地图，因此发布者应使用TRANSIENT_LOCAL持久性：

rclcpp::QoS qos_map(1);
qos_map.reliable();
qos_map.transient_local(); // 保存最新一份地图，供后加入的订阅者获取
pub_map = node->create_publisher<nav_msgs::msg::OccupancyGrid>("/map", qos_map);

3.5 误区与复盘：QoS不匹配的典型症状

复盘一个真实排障案例：某团队在调试时发现，/imu/data话题在rqt_graph中显示节点已连接，但订阅者回调从未触发。排查步骤：

1. 使用ros2 topic info /imu/data --verbose查看发布者和订阅者的QoS配置。
2. 发现发布者使用了默认的RELIABLE，而订阅者代码中误设置了best_effort()。
3. 由于订阅者请求的可靠性低于发布者提供的可靠性，这实际上是兼容的，数据应能收到。进一步检查发现，问题出在DURABILITY：发布者设置为VOLATILE，而订阅者请求TRANSIENT_LOCAL，导致兼容性失败。
4. 修正订阅者的DURABILITY为VOLATILE后，通信立即恢复。

这个案例说明，QoS兼容性检查是逐策略独立判断的，任何一个策略不匹配都可能导致通信失败。在ROS 2中，可以使用ros2 doctor或ros2 topic delay等工具辅助诊断，但最根本的方法还是理解各策略的兼容矩阵。