聊 ROS 2 底层架构，绕不开“中间件”这三个字。用ros2 topic echo用得很爽的人很多，但数据到底是怎么从发布者手里跑到订阅者手里的，未必每个人都说得清楚。ROS 2 跟 ROS 1 最大的区别，恰恰就在于把通信这件事从“自研轮子”换成了“标准化中间件”。这篇我打算把这层架构彻底拆开，讲清楚中间件在 ROS 2 里扮演什么角色、底层用了什么协议、不同中间件实现之间怎么切换，以及延伸到 Micro-ROS、ESP32 这类嵌入式场景时中间件架构会怎么变形。想深入理解 ROS 2 或者正在做多机、嵌入式方案选型的朋友，这篇应该能省下不少查资料的功夫。
1. 为什么 ROS 2 要把“中间件”当作头等大事
1.1 ROS 1 的通信痛点：自研总线撑不住分布式场景
在聊 ROS 2 的中间件架构之前，得先回头看 ROS 1 是怎么做的。ROS 1 的通信核心是 ROS Master 加 XML-RPC，再加上一条基于 TCPROS/UDPROS 的自研传输通道。节点启动之后，先跟 Master 注册，说自己叫什么名字、发布哪些话题、订阅哪些话题，然后由 Master 帮忙牵线，让发布者和订阅者直接建立点对点连接。
这套机制在小规模机器人上跑起来没问题，但一旦进入多机、动态拓扑、弱网环境，问题就暴露了。Master 是单点，挂了整个系统就废了；节点之间直接建连，没有完整的 QoS 保障；发现机制太简单，节点频繁上下线时很容易出现信息不一致。更要命的是这套协议没有行业标准，别的中间件、别的语言生态想接入，基本只能重写一套兼容层。ROS 1 的通信更像一个“实验室内部工具”，而不是一套经得起工业部署考验的通信基础设施。
1.2 ROS 2 的答案：直接站在标准化 DDS 中间件之上
ROS 2 设计者的思路很明确：通信这块不自己造轮子了，直接用 DDS（Data Distribution Service，数据分发服务）。DDS 是 OMG 组织定的标准，核心特征是无中心化的发布订阅模型、支持丰富的 QoS 策略、天生为分布式实时系统设计。它的设计初衷就是解决大型分布式系统中数据可靠、实时、灵活分发的问题，跟机器人这种多节点、强实时、需要动态发现的场景天然契合。
于是 ROS 2 从零开始就不再依赖 Master 节点了，节点发现、数据路由、可靠性保障全交给 DDS 中间件去处理。也就是说，你在 ROS 2 里写的Publisher、Subscriber，底层对应的其实是 DDS 的DataWriter、DataReader，话题名称和数据类型则映射为 DDS 的 Topic 和 Type。这层替换不是小修小补，而是整个通信架构的范式转移：有了 DDS，ROS 2 天然支持多机分布式、支持动态发现、支持细粒度的可靠性配置，也终于能跟其他非 ROS 系统共享同一套通信标准了。
2. 中间件架构的核心：RMW 抽象层
2.1 RMW 是什么，它管了哪些事
DDS 只是一个规范，落实到代码上有多个实现。ROS 2 官方默认用的是 Eclipse 的 Fast DDS，此外还有 Cyclone DDS、RTI Connext DDS、GurumDDS 等。如果 ROS 2 的每一层都直接跟某一个 DDS 实现深度绑定，那整个生态就被锁死了。所以 ROS 2 在应用层和具体 DDS 实现之间加了一层抽象接口，叫 RMW，全称是 ROS Middleware Interface。
这层抽象的作用，简单说就是把“ROS 2 的 API 调用”翻译成“具体 DDS 实现的 API 调用”。你在代码里写的create_publisher，RMW 层会把它转成对应 DDS 的create_datawriter，publish会转成write。这层翻译包含节点创建、话题创建、发布订阅创建、消息序列化、QoS 配置下发等几乎所有通信相关操作。RMW 的接口设计是通用的，所以理论上任何符合 DDS 标准的实现，只要有人写了对应的 RMW 适配层，就能无缝接进 ROS 2。
这种“应用-抽象层-具体实现”的三层结构，带来的实际好处是：切换底层中间件时，你的业务代码一行都不用改。ROS 2 中负责把消息序列化成字节流的rmw_serialized_message_t、负责维护节点图的graph管理等，全部被隔离在 RMW 之下，对上层保持稳定。
2.2 从代码到 DDS 的实体映射关系
具体来看，ROS 2 的实体和 DDS 实体并不是一一对应到“同一个类”，而是层层派生和封装的关系。一个 ROS 2Node在 DDS 层会对应一个DomainParticipant，这个 Participant 标识了节点属于哪个通信域。话题发布方和订阅方各自创建自己的 DDSPublisher/Subscriber以及DataWriter/DataReader，话题和消息类型则对应Topic与TypeSupport。
理解这层映射对排查问题很有用。比如你建立一个订阅，但迟迟收不到数据，那问题可能不在你的回调函数写错，而在于 DDS 层的数据写入根本没发生，或 QoS 不兼容导致匹配失败。RMW 层把所有 DDS 的错误返回转换成 ROS 2 的错误码和日志，但有些细节（比如 RTPS 包的发送情况）还是得去 DDS 层日志才能看到。用ros2 doctor --report可以查看当前 RMW、中间件实现和网络接口的情况，这是定位问题时的第一手信息。
2.3 域（Domain）与节点隔离
DDS 的 “域”（Domain） 是 RMW 层一个非常关键的概念。同一域内的 Participant 才能互相通信，不同域之间天然隔离。ROS 2 通过环境变量ROS_DOMAIN_ID来控制，默认值是 0。如果你同时跑多个互不干扰的 ROS 2 系统，最直接的做法就是把它们的 domain_id 设成不同值。
这个设计在教室、实验室或赛事场景特别实用。比如一个 6 人小组，每人手里一台机器人小车，如果都用默认 domain 0，那 A 的话题命令可能会被 B 的小车收到，数据互相串台。把每台车的ROS_DOMAIN_ID分别设成 1、2、3、4、5、6，系统就完全隔离了。需要注意，domain_id 的选择要考虑 DDS 实现默认使用的端口范围，有些实现允许设到 100 以上，但特殊端口在部分网络环境下可能有冲突。务实做法是先用 0 到 100 之间的值，避免踩到端口分配的坑。
3. DDS 中间件的核心机制拆解
3.1 RTPS 协议：发布订阅的底层“语言”
DDS 规范本身不绑定具体的线上传输协议，但 ROS 2 最常用的 DDS 实现都实现了 RTPS（Real-Time Publish-Subscribe）协议。RTPS 是 OMG 针对 DDS 制定的线下互操作协议，定义了数据在网络上传输时的格式、交换规则，以及发现、可靠性等机制。
RTPS 协议的报文由多个子消息组成，比如HEARTBEAT、ACKNACK、DATA等。发布端周期性发送HEARTBEAT，告诉订阅端自己有哪些序列号的数据可以发；订阅端用ACKNACK回应，告知自己缺哪些数据。在这个机制下，即使网络存在丢包，可靠模式下也能通过重传把数据补上。这个设计在机器人控制中很关键，因为传输的不只是传感器数据，还有可能是运动指令。如果指令丢了，轻则控制卡顿，重则撞机。RTPS 的可靠模式就是为了在这种场景下兜底。
RTPS 协议可以跑在 TCP 或 UDP 上，默认实现（Fast DDS）主要走 UDP。为什么用 UDP 而不是 TCP？因为 DDS 系统通常需要支持组播和低延迟通信，UDP 在这两方面性能更强，可靠性丢给 RTPS 层的 ACK/NACK 机制来处理，是一种更灵活的折中方案。
3.2 发现协议：节点是怎么“找到彼此”的
DDS 的发现分为两个阶段：参与者发现（SPDP，Simple Participant Discovery Protocol）和端点发现（SEDP，Simple Endpoint Discovery Protocol）。SPDP 阶段，每个 DDS Participant 周期性向网络上的特定端口（通常是 7400 段的组播地址）广播自己的存在。节点拿到对方 Participant 的信息后，再通过点对点通信交换更详细的端点信息（话题名、数据类型、QoS），这就是 SEDP。
发现机制直接决定了系统的动态性。新节点上线，不需要手动配置任何人，几分钟内就能被集群内其他节点发现，这对机器人这种经常“随时增删模块”的场景非常重要。但组播也带来了网络层面的依赖：如果运行环境不允许组播（比如很多云主机、部分 WSL2 网络、某些容器网络），发现就完不成，节点找不到对方，表现为“我明明 echo 不到，但它确实在跑”。
解决的方式通常有两种：一是把 DDS 的发现模式从组播改成单播，并把已知的对端地址写死进配置文件；二是配置 DDS 实现自带的“ Discovery Server”（Fast DDS 支持将发现流量集中到一个轻量级服务端，客户端直连它）。这台服务器不是 ROS 1 时代那样的中心化 Master，它只负责撮合，数据仍然走点对点，所以可靠性不会因此打折。
3.3 QoS 策略：决定通信行为的一组“旋钮”
QoS（Quality of Service）是 DDS 中间件最强大的地方，也是 ROS 2 里最容易踩坑的地方。ROS 2 的Quality of Service类在中间件层被翻译成一组 DDS QoS Policy。常见的几个维度包括：
- Reliability：值为
RELIABLE时保证不丢数据（通过重传），值为BEST_EFFORT时不保证。传感器图像、点云这类能容忍偶尔丢帧的高带宽数据，通常用BEST_EFFORT；命令、状态这类重要消息用RELIABLE。 - Durability：控制“后加入的订阅者是否能拿到历史数据”。
TRANSIENT_LOCAL模式允许后订阅的节点拿到最新的那一条数据（类似共享变量），VOLATILE则不保留。 - History：
KEEP_LAST配合depth参数，只保留最近若干条历史，超出则丢弃；KEEP_ALL则会缓存全部未消费的数据，代价是内存暴涨。 - Deadline：约定数据必须在一定时间内更新一次，超时则触发回调，这常用于心跳检测。
发布方和订阅方的 QoS 必须“可以兼容”才能通信。具体规则是：订阅方要求的可靠性级别不能低于发布方提供的；Durability 也一样。如果发布方是BEST_EFFORT，订阅方想用RELIABLE，不兼容，通信就会静默失败。这个坑在 ROS 2 里特别常见，很多新手明明代码看着没问题，数据就是不通，QoS 不匹配是头号嫌疑。
4. 中间件选型与切换实战
4.1 主流 RMW 实现横向对比
目前实际用过且社区讨论最多的 RMW 实现有三家：Fast DDS、Cyclone DDS、RTI Connext DDS。Fast DDS 是默认选择，开箱即用，文档多，遇到问题社区资料最好找。Cyclone DDS 在延迟和资源占用上表现更好，尤其在低功耗嵌入式平台上明显更轻。RTI Connext 是商业产品，性能和可靠性都很强，但 License 费用较高，一般工业项目才会选它。
我自己在 Intel i7 的普通 PC 上测过 Fast DDS 和 Cyclone DDS 在同一个话题上的吞吐表现，Cyclone DDS 的延迟通常更低，尤其在BEST_EFFORT模式下更明显。如果你是做一个对延迟敏感的实时控制类项目，我建议试试 Cyclone DDS；如果只是学习、写示例代码，直接用默认的 Fast DDS 就好，没必要折腾。
4.2 切换 RMW 的具体操作
切换中间件实现，在二进制安装的 ROS 2 里不算难。先安装对应的 RMW 包，比如用 Cyclone DDS：
sudo apt install ros-humble-rmw-cyclonedds-cpp安装完成后，设置环境变量：
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp然后在同一个终端里再启动节点，后续所有节点都会使用 Cyclone DDS 进行通信。要检查当前环境用的是哪个 RMW，可以执行：
ros2 doctor --report输出里会有Middleware implementation一行标出具体是哪个实现。如果你临时想切回默认，直接在终端里unset RMW_IMPLEMENTATION即可。这里要注意的是，通信双方必须使用“互操作兼容”的中间件。虽然 RTPS 是标准协议，不同实现之间理论能互通，但实际受版本、配置影响，跨实现通信经常出怪问题。稳妥做法是同一个系统里统一用一个 DDS 实现，别 A 机用 Fast DDS、B 机用 Cyclone DDS，容易遇到“能发现但收不到数据”这种模糊故障。
配置文件的写法也值得掌握。Cyclone DDS 的配置是一个 XML 文件，最常用的场景是改网络接口和组播设置：
<CycloneDDS xmlns="https://cdds.io/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd"> <Domain> <General> <Interfaces> <NetworkInterface name="eth0"/> </Interfaces> <AllowMulticast>true</AllowMulticast> </General> </Domain> </CycloneDDS>保存为cyclonedds.xml，然后通过环境变量加载：
export CYCLONEDDS_URI=file:///path/to/cyclonedds.xmlFast DDS 也有类似的 XML 配置，通过FASTDDS_DEFAULT_PROFILES_FILE环境变量指定。配置文件是把多机通信调稳定的关键工具，很多“跨机器找不到对方”的诡异问题，最后都是靠指定网卡解决的。
4.3 多机通信的中间件配置思路
多机场景下，中间件配置的第一原则是“保证端口可达”。Fast DDS 默认使用 UDP 端口范围通常是 7400 到 7500 段，Cyclone DDS 类似。如果你在机器人上部署系统，要确保同一局域网内这些 UDP 端口不被防火墙拦截。某些安全策略较严的办公网络会把非标准端口的 UDP 禁掉，表现就是所有节点都能起来，但互相之间完全发现不了。
其次要处理的是网卡选择。机器人平台通常有多块网卡：有线以太网、WiFi、USB 网卡等。DDS 实现会默认选一个“最优”网卡广播，但如果选错了网络（比如选了 USB 虚拟网卡，或者选了 Docker 的虚拟网卡），就会导致局域网内其他设备根本收不到它的广播。标准的解决方式是在配置里强制指定物理网卡的 IP 或网卡名。
我自己在一次机器人调试中就遇到了这种情况：笔记本 WiFi 连着机器人的 AP，机器人本身通过有线接着 Jetson，两边代码都对，就是发现不了。最后在 DDS 配置里把两边都固定到各自的物理网卡后，问题瞬间消失。这类问题排查的固定套路就是：先看 IP 在同一网段，再在配置里锁定网卡，然后再看组播。
5. 嵌入式场景：Micro-ROS 与 ESP32 的中间件变形
5.1 Micro-ROS 为什么不用完整 DDS
ROS 2 本身依赖的完整 DDS 栈对资源的要求很高，一个完整的 Fast DDS Participant 可能要吃掉几十 MB 内存，这在 Jetson 或树莓派上没问题，但放到 ESP32、STM32 这样的单片机上就完全不可接受了。所以 Micro-ROS 的设计思路是把“完整 DDS 客户端”换成一个超轻量级的 DDS 兼容层，叫 Micro XRCE-DDS。
这个机制是客户端-服务器模式：MCU 上跑 Micro XRCE-DDS Client，上位机（通常是开发板或 PC）上跑 Micro XRCE-DDS Agent，Client 通过串口、WiFi 或 UDP 通信，把数据交到 Agent，由 Agent 接入完整 DDS 网络。你的 ROS 2 节点实际上订阅的是 Agent 发出来的数据，而不是 MCU 直接发布的。对上层 ROS 2 系统来说，MCU 上的传感器也好，控制指令也好，看起来就是一个普通的 ROS 2 节点，区别只在于这个节点“借用”了 Agent 的 DDS 身份。
这种架构的巧妙之处在于，MCU 端不需要实现完整的 RTPS 协议栈，只需要实现一层轻量级的序列化和传输协议，协议开销小到可以在 ESP32 上跑得动。代价是实时性和可靠性受限于 Client-Agent 之间的传输链。如果走 WiFi，延迟会有明显波动，做闭环控制时要特别评估。
5.2 ESP32 上跑 Micro-ROS 的工程配置
用 ESP32 跑 Micro-ROS 的常见方案是直接用官方维护的micro_ros_espidf_component。这个组件本质上是为 ESP-IDF（Espressif IoT Development Framework）封装好的一个库，把 micro_ros 的源码、依赖和默认配置都打包好了，省去手动交叉编译的麻烦。
使用流程大概是：先准备好一个 ESP-IDF 工程，用idf.py create-project创建项目，然后把micro_ros_espidf_component作为 ESP-IDF 的 component 放进工程的 components 目录里。接下来，设置 Micro-ROS 的传输方式和 Agent 的地址，比如通过 WiFi 网络传输，那就要配置 WiFi SSID、密码，以及 Agent 端的 IP 和端口：
#include <micro_ros_platformio.h> // 或者 ESP-IDF 版本使用 micro_ros_espidf_component 的头文件关键是在程序启动时把传输层初始化好，常见做法是用官方示例里的transport初始化函数，它内部会完成 WiFi 连接和 UDP 传输的建立。然后就可以像写普通 ROS 2 节点一样创建Node、Publisher、Subscriber了。但这里有三点要特别小心：
第一，消息类型在编译时就必须到 ESP-IDF 的 micro_ros 库里去生成，不能动态加载消息类型；第二，RMW_IMPLEMENTATION在 Micro-ROS 里已经预编译成 Micro XRCE-DDS，不要手动改；第三，ESP32 的 RAM 资源有限，参与通信的话题数量尽量不要太多，不然内存不足会导致程序随机重启。
5.3 实测中的几个关键坑
在 ESP32 上跑 Micro-ROS，最大的坑是 WiFi 传输的稳定性。Micro XRCE-DDS 走 WiFi 时，如果信号强度不稳，很容易出现 Agent 侧“Client 断连”的日志，表现为 ROS 2 端的话题一会儿有数据一会儿没有。这里的处理建议有两个：一是把 WiFi 省电模式关掉，ESP-IDF 里可以通过esp_wifi_set_ps(WIFI_PS_NONE)实现，省电模式会周期性休眠网卡，对实时通信是致命的；二是增大 Agent 端的超时容忍值，给 WiFi 的抖动留出余量。
另一个问题：Agent 和 Client 的固件版本必须兼容。Micro-ROS 的 Client 代码是跟 Agent 程序配套编译的，如果你用主分支的最新 Agent，但 ESP32 里的 Client 是半年前编译的，双方握手时很容易失败或通信错乱。务实的做法是 Agent 端也直接跑官方提供的 Docker 镜像，版本号跟 ESP32 使用的micro_ros_espidf_component保持一致，不要混用。
还有一点，ESP32 作为嵌入式 Micro-ROS 节点时，断线重连逻辑最好自定义实现。默认情况下，设备初始化阶段如果连不上 Agent，程序会一直阻塞在rmw_init里，如果你希望设备在 Agent 掉线后自动重启并重连，需要自己写一个看门狗逻辑，检测到初始化失败或通信超时后主动调用重启。
6. 常见问题与排查技巧实录
6.1 通信失败的快速排查速查表
和中间件相关的问题，我给自己总结了一套固定排查流程，效率比瞎试高得多。建议你在机器人或工程环境里遇到通信问题时，也按这个顺序来：
| 症状 | 排查步骤 | 典型原因 |
|---|---|---|
| 节点互相看不到 | 1.ros2 node list对比两端节点；2.ros2 domain list查域；3. 查看/etc/hosts或 DDS 配置网卡 | 域不一致、网卡选择错误、组播被禁 |
| 能看到节点但收不到话题 | 1.ros2 topic list看话题是否存在；2.ros2 topic info /topic -v查 QoS；3. 对比发布/订阅的 QoS 策略 | QoS 不兼容、数据类型不匹配 |
| 话题时有时无 | 1.ros2 doctor查网络统计；2. 检查 WiFi/以太网丢包；3. 查看中间件日志 | 网络不稳定、DDS 心跳超时 |
| 多机环境互相发现不了 | 1. 互相 ping 通；2. 检查防火墙是否放行 DDS 端口；3. 在 DDS 配置中锁定网卡 | 安全策略/UDP 被拦、网段隔离、组播不通过 |
每个步骤都要实际看输出，不要凭感觉猜。比如ros2 topic info /chatter -v的输出里会同时给出发布端和订阅端的 QoS 值，一眼就能判断是否匹配，这比反复改代码强多了。
6.2 QoS 不匹配的判定与处理
QoS 不匹配是 ROS 2 中间件层最容易踩、又最隐蔽的坑。表现通常是：节点启动时没有任何报错，日志也不出现 error，但数据就是不通。用 DDS 术语说，就是 DataWriter 和 DataReader 的 QoS 不相容，RTPS 协议无法建立匹配关系。
用ros2 topic info /topic -v可以看到当前所有发布端和订阅端各用的 QoS。你需要注意的字段有Reliability、Durability、History。比如发布端是BEST_EFFORT、VOLATILE、KEEP_LAST(10)，订阅端写的是RELIABLE、VOLATILE、KEEP_LAST(10)，发布和订阅不兼容，订阅端就收不到数据。解决办法是把订阅端的Reliability改成BEST_EFFORT，或者反过来把发布端改成RELIABLE。
如果你在写自定义节点，建议在创建订阅器或发布器时，显式定义 QoS 而不是用默认值。默认值虽然大多数场景可用，但一旦和其他节点配合时，谁用的默认值不同，就会产生完全不透明的冲突。尤其是rclcpp::QoS(10)这个写法，默认是RELIABLE+KEEP_LAST，而ros2 topic echo等工具默认反而可能是BEST_EFFORT，两边要是不一致，echo 不出数据是很正常的。
6.3 WSL2、容器与虚拟机里的中间件怪问题
开发环境如果用 WSL2 或者 Docker，中间件这层很容易出现“只在真机上正常”的情况。核心原因是 WSL2 和部分容器网络默认不支持组播或 UDP 广播，而 DDS 的自动发现强依赖组播。
有几种可行的处理方式。如果你在 WSL2 里跑 ROS 2，最简单的方法是设置环境变量让 DDS 使用单播发现模式，或者干脆把 DDS 的组播开关关掉，改成 TCP 传输。Fast DDS 支持通过 XML 配置关闭组播并指定单播地址列表，可以在开发时把两个 WSL2 实例作为已知节点写死进去，一样能通信。
容器场景类似，关键是不要在容器内使用默认的 bridge 网络模式跑多个 DDS 容器，那会导致容器彼此之间完全无法发现。常见的做法是用 host 网络模式跑容器，或者给容器显式添加网络端口映射，并在 DDS 配置里指定本机可用的网卡。如果你只是本机开发调试，最简单的办法就是把容器改成 host 网络，省掉一堆网络层面的麻烦。
另外一个很常见的坑是时间不同步。多机 DDS 通信对时间一致性有要求，如果两台机器系统时间差异过大，某些 QoS 策略（比如 Deadline）会直接触发超时，表现为明明数据在发，但订阅端回调不触发。所以多机部署前，务必用 chrony 或 NTP 把时间对齐。这个问题很多人根本想不到，我自己就在一次多机演示前吃过亏，现场演示时怎么都不出数据，结果一查，两台机器的系统时间差了几分钟。
7. 中间件架构的未来方向与我的选择
DDS 目前是 ROS 2 中间件层的主流答案，但并不是唯一答案。Eclipse 的 Zenoh 协议在机器人社区里的关注度越来越高，它主打极低延迟和超低资源占用，在嵌入式场景和广域网传输上有很强的优势。ROS 2 官方也有对应的rmw_zenoh实现，目前还在活跃迭代中。如果项目对延迟敏感，且部署环境跨越多个网段甚至公网，Zenoh 这类替代中间件值得关注。不过现阶段选型还是以稳定为主，DDS 生态成熟度和资料丰富度明显更高，生产环境我仍然首选 Fast DDS 或 Cyclone DDS。
就我个人而言，现在接手新的 ROS 2 项目时，不管是做机器人原型还是做多机演示，第一步都会先把中间件版本、DDS 配置、domain_id、QoS 策略这些都固定下来，写进项目的 README 里。很多人不重视这些“环境性”配置，结果一到现场联调就出幺蛾子。中间件是整个 ROS 2 系统里最容易“看不见摸不着”但又最能决定成败的部分，花点时间把它的架构搞清楚，比多写一百行业务代码都值。
