第2章 DDS中间件

第2章：DDS中间件：DDS协议栈原理、QoS策略配置、RTPS协议在ROS2中的应用

好，咱们直接进入正题。DDS中间件，说白了就是ROS2的「神经系统」。没有它，节点之间就是聋子和哑巴。我刚开始接触ROS2时，总觉得DDS是个黑盒子，直到有一次在项目中遇到数据丢包问题，才逼着自己把协议栈啃了一遍。嗯，今天咱们就把这层窗户纸捅破。

2.1 DDS协议栈：三层架构

DDS的全称是Data Distribution Service，数据分发服务。它不是一个单一协议，而是一套完整的协议栈。我个人习惯把它分成三层来看：

DCPS层（Data-Centric Publish-Subscribe）：这是最上层，面向开发者。你写代码时用的Publisher、Subscriber、Topic、DataWriter、DataReader，都属于这一层。说白了，就是API层。
DLRL层（Data Local Reconstruction Layer）：这一层在ROS2里用得不多，它负责把分布式数据映射成本地对象。我几乎没碰过它，跳过也无妨。
RTPS层（Real-Time Publish-Subscribe）：这是核心传输层。ROS2的底层通信全靠它。后面我会专门讲。

关键点：DCPS是「做什么」，RTPS是「怎么做」。你写代码时只关心DCPS，但出了问题，得去RTPS层找原因。

2.2 QoS策略：别让数据「裸奔」

QoS（Quality of Service）是DDS最强大的特性之一。我在项目中遇到过最典型的场景：机器人导航节点发布路径数据，如果QoS设置不对，订阅方收到的路径是残缺的，机器人直接撞墙。嗯，这锅得QoS背。

ROS2里常用的QoS策略有这些：

策略名称	作用	我常用的值
Reliability	可靠性：保证数据送达还是允许丢包	RELIABLE（关键数据）/ BEST_EFFORT（传感器流）
Durability	持久性：晚来的订阅者能否收到历史数据	TRANSIENT_LOCAL（地图等静态数据）/ VOLATILE（实时数据）
History	历史深度：保留最近多少条数据	KEEP_LAST（10）/ KEEP_ALL（慎用，内存爆炸警告）
Deadline	截止时间：数据发布频率不能低于这个值	100ms（控制指令）/ 1s（状态反馈）
Liveliness	活性：检测节点是否还活着	AUTOMATIC（默认）/ MANUAL_BY_TOPIC（精细控制）

我的经验：如果你不确定怎么配，就用ROS2默认的QoS配置（rclcpp::QoS(10)）。它兼顾了可靠性和性能。等出了问题再针对性调整。

举个例子，配置一个可靠的、保留最近5条数据的发布者：

#include <rclcpp/rclcpp.hpp>
#include <std_msgs/msg/string.hpp>

auto qos = rclcpp::QoS(rclcpp::KeepLast(5))
    .reliable()
    .transient_local();

auto publisher = node->create_publisher<std_msgs::msg::String>("chatter", qos);

为什么会这样配？你想想看，如果订阅方启动晚了，它还能收到之前发布的5条消息。这在机器人启动时加载地图数据特别有用。

2.3 RTPS协议：DDS的「快递员」

RTPS（Real-Time Publish-Subscribe Protocol）是DDS在传输层的具体实现。它定义了数据怎么打包、怎么寻址、怎么确认。我记得第一次看RTPS协议文档时，头都大了。后来发现，你只需要理解几个核心机制：

发现机制（Discovery）：节点启动时，通过SPDP（Simple Participant Discovery Protocol）互相发现。说白了就是广播一声「我来了，我发什么话题，我订阅什么话题」。
数据交换：发现之后，通过SEDP（Simple Endpoint Discovery Protocol）建立连接。然后数据就走RTPS的Writer/Reader通道了。
心跳与确认：可靠模式下，发送方会发心跳包，接收方回复ACK。如果丢包，发送方会重传。

避坑指南：我曾经在一个多机器人系统中，发现节点之间互相发现不了。查了半天，原来是防火墙把SPDP的UDP广播端口（7400-7500）给封了。记住，ROS2的发现机制依赖UDP广播，网络隔离环境要手动配置发现服务器。

2.4 ROS2中的RTPS应用：Fast DDS vs Cyclone DDS

ROS2默认支持多种DDS实现。目前主流的是Fast DDS（eProsima）和Cyclone DDS（Eclipse）。我个人更倾向Fast DDS，因为它的文档更全，社区更活跃。但Cyclone DDS在嵌入式平台上表现更好。

切换DDS实现很简单，设置环境变量就行：

# 使用Fast DDS（默认）
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp

# 使用Cyclone DDS
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

你可以在启动脚本里加上这句。我习惯在launch文件里写死，避免不同终端环境不一致导致奇怪的问题。

2.5 实战：用QoS解决数据同步问题

最后，咱们看一个真实场景。假设你有一个激光雷达节点发布点云数据，一个建图节点订阅它。如果QoS设置不当，建图节点收到的点云可能不完整，地图就歪了。

正确的做法：

激光雷达发布者：用BEST_EFFORT + KEEP_LAST(1)。因为点云数据量大，丢几帧没关系，但要最新的。
建图订阅者：也用BEST_EFFORT + KEEP_LAST(1)。保持匹配。

代码示例：

// 发布者
auto lidar_qos = rclcpp::QoS(rclcpp::KeepLast(1))
    .best_effort();
auto lidar_pub = node->create_publisher<sensor_msgs::msg::LaserScan>("scan", lidar_qos);

// 订阅者
auto map_qos = rclcpp::QoS(rclcpp::KeepLast(1))
    .best_effort();
auto map_sub = node->create_subscription<sensor_msgs::msg::LaserScan>("scan", map_qos, callback);

记住：发布者和订阅者的QoS必须兼容。如果发布者是RELIABLE，订阅者是BEST_EFFORT，那订阅者只能收到尽力而为的数据，可靠性就白设了。ROS2在连接时会做兼容性检查，不兼容会报warning。

好了，这一章就到这里。DDS中间件是ROS2的基石，理解它，你就能驾驭ROS2的通信。下一章咱们聊聊话题与服务的选择，以及什么时候该用动作。

📚 课程目录