3. DDS核心概念
在ROS2中，节点之间的通信并不是直接“点对点”完成的，而是建立在DDS（Data Distribution Service）这套数据为中心的中间件之上。理解DDS的核心概念，是掌握ROS2实时通信与QoS调优的第一步。本节将围绕八个关键对象展开：域（Domain）、参与者（Participant）、发布者（Publisher）、订阅者（Subscriber）、数据写入者（DataWriter）、数据读取者（DataReader）、主题（Topic）与数据类型（Type）。它们共同构成了一张从“进程隔离”到“数据落地”的完整通信拓扑。
一、从域到参与者：通信的边界与入口
域（Domain）是DDS中最外层的隔离边界。每个域由一个整数Domain ID标识，只有处于同一Domain ID下的参与者才能互相发现和通信。ROS2默认使用Domain 0，但多机器人系统、仿真与实机并行调试时，常通过ROS_DOMAIN_ID环境变量隔离不同系统，避免话题互相干扰。
参与者（Participant）是DDS通信的入口对象，通常一个ROS2节点对应一个Participant。Participant加入某个域后，会通过DDS的发现协议（如SPDP/SEDP）自动寻找同域内的其他Participant，并交换主题、类型、QoS等信息。Participant本身不直接收发数据，而是作为发布者和订阅者的容器存在。
# 查看当前域ID
echo $ROS_DOMAIN_ID
# 临时切换到域 42 运行节点
export ROS_DOMAIN_ID=42
ros2 run demo_nodes_cpp talker二、发布者与订阅者：通信的角色容器
发布者（Publisher）和订阅者（Subscriber）是Participant内部的两个角色对象。Publisher负责管理一组DataWriter，Subscriber负责管理一组DataReader。它们本身不承载具体数据，而是提供QoS继承、分组管理和生命周期控制的容器。一个Participant可以创建多个Publisher和Subscriber，一个Publisher也可以创建多个DataWriter。
这种分层设计的意义在于：QoS策略可以在Publisher/Subscriber层统一设置，再被下层DataWriter/DataReader继承或覆盖。例如，一个Publisher设置RELIABLE，其下所有DataWriter默认可靠传输；若某个DataWriter需要BEST_EFFORT，可以单独覆盖。
三、数据写入者与数据读取者：真正干活的端点
数据写入者（DataWriter）是实际发送数据的端点，数据读取者（DataReader）是实际接收数据的端点。它们才是DDS中真正与主题绑定的对象。每个DataWriter必须绑定一个主题和数据类型，DataReader同理。只有当DataWriter与DataReader的主题名、数据类型以及QoS策略都兼容时，DDS才会在两者之间建立匹配关系，数据才开始流动。
在ROS2中，我们平时写的create_publisher和create_subscription，底层就是创建了Publisher/Subscriber，再进一步创建DataWriter/DataReader。理解这一层，有助于排查“话题存在但收不到数据”的问题——往往不是话题没建，而是DataWriter与DataReader的QoS不兼容，导致匹配失败。
四、主题与数据类型：匹配的契约
主题（Topic）是数据的逻辑通道名称，例如/chatter、/cmd_vel、/scan。主题名必须完全一致才能匹配。数据类型（Type）是主题上传输数据的结构定义，例如std_msgs/msg/String、geometry_msgs/msg/Twist。类型不一致时，即使主题名相同，DDS也不会建立连接。
ROS2使用.msg文件定义类型，并通过IDL映射到DDS的类型系统。类型名在DDS中通常带有命名空间前缀，例如std_msgs::msg::dds_::String_。这也是为什么跨语言、跨厂商DDS互通时，类型兼容性是一个关键检查点。
| 概念 | 作用 | 是否直接收发数据 | 关键匹配条件 |
|---|---|---|---|
| 域 Domain | 最外层隔离边界 | 否 | Domain ID 相同 |
| 参与者 Participant | 通信入口与发现主体 | 否 | 同域内自动发现 |
| 发布者 Publisher | DataWriter 容器 | 否 | QoS 继承与分组 |
| 订阅者 Subscriber | DataReader 容器 | 否 | QoS 继承与分组 |
| 数据写入者 DataWriter | 发送端点 | 是 | 主题 + 类型 + QoS |
| 数据读取者 DataReader | 接收端点 | 是 | 主题 + 类型 + QoS |
| 主题 Topic | 数据逻辑通道 | 否 | 名称完全一致 |
| 数据类型 Type | 数据结构契约 | 否 | 类型定义兼容 |
五、案例：一个激光雷达节点的通信链路
假设有一个激光雷达节点/lidar_node，它发布/scan话题，类型为sensor_msgs/msg/LaserScan。其内部结构如下：
- Participant 加入 Domain 0；
- 创建一个 Publisher，QoS 设置为
BEST_EFFORT、KEEP_LAST(5)； - Publisher 创建一个 DataWriter，绑定主题
/scan和类型LaserScan； - 订阅端节点创建 Subscriber 和 DataReader，主题与类型相同；
- DDS 发现两者 QoS 兼容后，建立匹配，激光数据开始流动。
如果订阅端把 QoS 改成 RELIABLE，而发布端是 BEST_EFFORT，则两者不兼容，DataReader 收不到数据。此时ros2 topic list仍能看到/scan，但ros2 topic echo /scan无输出。这是ROS2工程中最常见的“话题在、数据无”问题之一。
ros2 topic info /scan --verbose 查看发布端与订阅端的 QoS 配置，再对比主题名和类型是否一致。
六、误区与复盘
误区一：把节点等同于Participant。在ROS2默认实现中，一个节点通常对应一个Participant，但并非绝对。某些中间件允许一个Participant承载多个节点，或一个节点创建多个Participant。理解这一点有助于分析资源占用和发现行为。
误区二：认为主题名相同就能通信。主题名只是匹配条件之一，类型和QoS同样关键。类型不匹配时，DDS会直接拒绝匹配；QoS不兼容时，匹配失败但不会报错，表现为“静默无数据”。
误区三：忽略Domain ID。在多机、多仿真环境并行时，Domain ID冲突会导致不同系统的节点互相发现，产生串扰。工程上建议为每个机器人或每个仿真实例分配独立Domain ID。
复盘要点：遇到通信问题时，按“域 → 参与者发现 → 主题名 → 数据类型 → QoS兼容性 → DataWriter/DataReader匹配”的顺序逐层排查，可以快速定位问题层级，而不是盲目重启节点。