第二章：ROS2中间件基础：DDS原理、QoS策略、Topic/Service/Action通信模式
各位同学好，我是老张。今天咱们聊聊ROS2最核心的底层——DDS。说实话，我刚从ROS1转到ROS2时，第一反应是：这玩意儿怎么这么复杂？但用久了你会发现，DDS才是ROS2真正牛逼的地方。
2.1 DDS是什么？为什么ROS2选它？
DDS，全称Data Distribution Service，数据分发服务。说白了，它就是一个去中心化的发布-订阅中间件。ROS1用的是自研的TCPROS/UDPROS，节点间通信必须经过Master节点。一旦Master挂了，整个系统就瘫了。
DDS不一样。它没有中心节点，每个节点都直接跟其他节点通信。我在做园区无人配送车项目时，遇到过ROS1 Master节点因为内存泄漏崩溃的情况，整个车队全部失联。换成ROS2+DDS后，单节点挂了完全不影响其他节点继续工作。
核心区别一句话总结：ROS1是星型拓扑，ROS2是去中心化的网状拓扑。
2.2 DDS的核心原理
DDS的工作机制，我习惯用「黑板模型」来理解。想象一块大黑板，谁想写数据就往上写，谁想读数据就去读。写的人不需要知道谁在读，读的人也不需要知道谁在写。
具体到技术层面，DDS有几个关键概念：
- Domain（域）：逻辑隔离的通信空间。同一个域里的节点才能互相通信。我一般把不同子系统分到不同域，比如感知域、规划域、控制域，避免消息串扰。
- DataWriter/DataReader：写者和读者。对应ROS2里的Publisher和Subscriber。
- Topic（主题）：数据的标签。所有写同一个Topic的数据，都会被分发给订阅该Topic的读者。
- Discovery（发现机制）：节点自动发现彼此。不需要手动配置IP地址，DDS通过SPDP（Simple Participant Discovery Protocol）和SEDP（Simple Endpoint Discovery Protocol）自动完成。
嗯，这里要注意：DDS的发现机制会占用一定的网络带宽。我在调试多车协同系统时，发现50个节点同时启动，发现阶段耗时超过10秒。后来通过配置initial_peers和discovery_lease_duration才优化到2秒以内。
2.3 QoS策略：你的消息延迟控制法宝
QoS（Quality of Service）是ROS2里最容易被忽视但又最重要的东西。我见过太多人直接用默认QoS，结果消息延迟高得离谱还不知道为什么。
ROS2的QoS策略包含多个维度，我挑几个最常用的说：
| QoS策略 | 可选值 | 我的建议 |
|---|---|---|
| Reliability（可靠性） | RELIABLE / BEST_EFFORT | 控制指令用RELIABLE，传感器数据用BEST_EFFORT |
| Durability（持久性） | VOLATILE / TRANSIENT_LOCAL | 地图、参数用TRANSIENT_LOCAL，实时数据用VOLATILE |
| History（历史记录） | KEEP_LAST / KEEP_ALL | KEEP_LAST配合深度使用，避免内存爆炸 |
| Deadline（截止时间） | 自定义时间 | 控制环路必须设置，否则延迟不可控 |
避坑指南：我曾经在激光雷达点云Topic上用了RELIABLE策略，结果因为网络丢包重传，导致点云帧率从10Hz掉到2Hz。换成BEST_EFFORT后，帧率稳定了，偶尔丢几帧完全不影响建图效果。
2.4 Topic/Service/Action通信模式
ROS2提供了三种通信模式，各有各的适用场景。我按使用频率排序：
2.4.1 Topic：最常用的发布-订阅模式
Topic是ROS2的基石。发布者往Topic里发消息，订阅者从Topic里收消息。一对多、多对一、多对多都支持。
代码示例：
// 发布者
rclcpp::Publisher<sensor_msgs::msg::LaserScan>::SharedPtr pub_;
pub_ = this->create_publisher<sensor_msgs::msg::LaserScan>("scan", 10);
// 订阅者
rclcpp::Subscription<sensor_msgs::msg::LaserScan>::SharedPtr sub_;
sub_ = this->create_subscription<sensor_msgs::msg::LaserScan>(
"scan", 10, std::bind(&ScanProcessor::callback, this, _1));注意那个数字10，是队列深度。我习惯根据消息频率来设：10Hz的消息设10，100Hz的消息设50。设太小会丢消息，设太大会增加延迟。
2.4.2 Service：请求-响应模式
Service适合需要确认的场景，比如「请给我当前位姿」。客户端发请求，服务端处理完返回响应。
但Service有个坑：它是同步的。客户端发完请求会阻塞等待。我在做路径规划服务时，如果路径计算超过100ms，整个控制循环就被卡住了。后来改成了Action。
2.4.3 Action：带反馈的异步任务
Action是Service的升级版。它支持：
- 发送目标（Goal）
- 接收反馈（Feedback）
- 获取结果（Result）
- 取消任务（Cancel）
举个例子，自动驾驶中的泊车任务：
- 发送目标：请泊入3号车位
- 反馈：当前进度30%，已找到车位
- 结果：泊车成功，最终位姿为...
- 取消：发现障碍物，取消泊车
Action底层其实也是用Topic实现的，但ROS2帮你封装好了反馈和取消机制。我个人强烈建议：任何耗时超过50ms的操作，都用Action而不是Service。
2.5 知识体系总览
下面这张图是我自己画的，把本章的核心知识点串起来了：
这张图从上到下展示了ROS2中间件的三层结构：底层是DDS提供通信基础设施，中间层是QoS策略控制通信行为，上层是三种通信模式满足不同场景需求。
2.6 性能优化小贴士
最后分享几个我在项目中积累的经验：
- QoS不要全用默认值：默认的RELIABLE+VOLATILE组合，在弱网环境下延迟会飙升。根据数据特性单独配置。
- 合理设置队列深度：队列深度=期望频率×允许的最大延迟。比如10Hz的消息，允许100ms延迟，队列深度设1就够了。
- 大消息用零拷贝：ROS2支持
unique_ptr传递消息，避免拷贝开销。我传输512x512的图像时，零拷贝比值拷贝快了3倍。 - 注意发现阶段：大量节点同时启动时，发现风暴会导致CPU飙升。建议分批启动，或者配置静态发现。
警告：千万不要在回调函数里做耗时操作！ROS2的回调是单线程的，一个回调卡住了，其他所有回调都得等着。我见过有人直接在回调里写文件，结果整个节点响应延迟从1ms变成了500ms。
好了，这一章的内容就到这里。DDS和QoS是ROS2性能优化的基石，理解透了后面讲消息延迟分析才能得心应手。
可可精品资料库