4、RTPS协议：实时发布订阅协议详解、发现协议（Simple Discovery）、序列化与反序列化

各位同学，今天我们聊一个自动驾驶中间件里绕不开的核心——RTPS协议。说白了，它就是DDS（数据分发服务）的“传输层灵魂”。你想想看，自动驾驶系统里那么多传感器数据、控制指令，怎么保证它们实时、可靠地到达该去的地方？RTPS就是干这个的。

我个人习惯把RTPS理解成“DDS的快递系统”。它定义了数据怎么打包、怎么找到收件人、怎么在路上跑。今天我们就拆开看看，这个快递系统到底是怎么工作的。

4.1 RTPS协议概览：它到底解决了什么问题？

先问大家一个问题：为什么自动驾驶不能用传统的TCP/IP或者HTTP？

原因很简单——太慢了，而且不够灵活。你想想看，一个激光雷达点云数据，每秒几十万个点，如果用HTTP那种“请求-响应”模式，光是握手就能把系统拖垮。RTPS采用的就是“发布-订阅”模式，数据生产者只管发，消费者只管收，中间由中间件负责路由和调度。

我在项目中遇到过这样一个场景：一辆测试车上有6个激光雷达、4个摄像头、2个毫米波雷达，再加上IMU和GPS。如果每个传感器都单独建立连接，那网络拓扑会乱成一锅粥。RTPS通过全局数据空间（Global Data Space）的概念，让所有节点都能“看见”彼此的数据，而不需要知道对方具体在哪。

核心要点：RTPS协议是DDS的线缆协议（Wire Protocol），它定义了数据在网络上传输的二进制格式和交互流程。它不依赖于特定的传输层（可以用UDP、TCP，甚至共享内存），但最常用的是UDP多播。

4.2 实时发布订阅：数据是怎么流动的？

RTPS的发布订阅机制，我习惯用“黑板模型”来理解。想象一块公共黑板，发布者往上面写数据，订阅者从上面读数据。但这里有几个关键角色：

  • Writer（写者）：发布者端的实体，负责把数据序列化后发送出去。
  • Reader（读者）：订阅者端的实体，负责接收并反序列化数据。
  • CacheChange（缓存变更）：数据的最小传输单元，包含序列化后的数据和元信息。
  • HistoryCache（历史缓存）：每个Writer/Reader都维护一个缓存，用于存储最近的数据变更。

数据流动的流程大致是这样的：

  1. 发布者应用调用write()接口，传入一个数据样本。
  2. RTPS层将数据序列化成CacheChange，存入Writer的HistoryCache。
  3. 根据QoS策略（比如可靠性、时效性），RTPS决定是否立即发送、缓存还是丢弃。
  4. 数据通过网络传输到订阅者端的Reader。
  5. Reader将CacheChange反序列化，存入自己的HistoryCache。
  6. 订阅者应用通过take()或read()接口获取数据。

避坑指南：我曾经在调试一个多传感器融合模块时，发现数据总是丢帧。查了半天，原来是Writer的HistoryCache深度设置得太小，导致高频数据被覆盖了。记住：HistoryCache的深度要根据数据发布频率和订阅者处理速度来合理配置。

4.3 发现协议（Simple Discovery）：节点之间怎么互相认识？

这是RTPS里最巧妙的部分之一。你想，一个自动驾驶系统可能有几十个节点，每个节点都不知道其他节点在哪。发现协议就是用来解决这个“社交问题”的。

RTPS标准定义了两种发现阶段：

发现阶段 作用 协议
参与者发现（SPDP） 发现网络中有哪些DDS参与者（Participant） Simple Participant Discovery Protocol
端点发现（SEDP） 发现每个参与者内部有哪些Writer和Reader Simple Endpoint Discovery Protocol

具体流程是这样的：

  • 每个Participant启动时，会通过UDP多播发送一个SPDP消息，宣告自己的存在。消息里包含Participant的GUID（全局唯一标识符）、传输地址、QoS等信息。
  • 其他Participant收到后，会回复一个SPDP消息，完成双向认识。
  • 然后，每个Participant会通过UDP单播发送SEDP消息，列出自己内部的所有Writer和Reader。
  • 订阅者发现感兴趣的Writer后，就会建立逻辑连接，开始数据传输。

嗯，这里要注意：发现协议默认使用UDP多播，但多播在跨网段时可能会被路由器过滤。我在实际部署中遇到过这个问题，后来改用Discovery Server模式，通过一个中心节点来协调发现，避免了多播的局限性。

重要提醒：发现协议的开销不可忽视。在一个有50个Participant的系统中，SPDP/SEDP的握手消息可能会达到数千条。如果网络带宽有限，建议适当调整发现周期（默认是2.5秒一次），或者使用静态发现机制。

4.4 序列化与反序列化：数据怎么变成二进制流？

这是RTPS协议里最“底层”的部分。你想想看，一个C++结构体，里面有浮点数、字符串、嵌套结构体，怎么在网络上传输？序列化就是把这个结构体变成一串字节，反序列化就是把这串字节还原成结构体。

RTPS标准并没有强制规定序列化格式，但最常用的是CDR（Common Data Representation）编码。CDR有两种模式：

  • Big Endian（大端）：网络字节序，跨平台兼容性好。
  • Little Endian（小端）：x86架构的本地字节序，性能更高。

CDR序列化的核心规则：

  1. 基本类型（int32、float64等）按固定长度编码。
  2. 字符串以4字节长度前缀 + 字符数据的形式编码。
  3. 结构体按成员顺序依次编码，每个成员按4字节对齐。
  4. 数组和序列（Sequence）以4字节长度前缀 + 元素数据的形式编码。

举个例子，假设我们有这样一个结构体：

struct PointCloud {
    uint32 timestamp;    // 4字节
    float points[100];   // 400字节
    string frame_id;     // 变长
};

序列化后的二进制布局大概是：

偏移0: timestamp (4字节, 小端)
偏移4: points[0..99] (400字节, 每个float 4字节)
偏移404: frame_id长度 (4字节)
偏移408: frame_id字符数据 (变长)

个人经验：我曾经在优化序列化性能时，发现CDR的对齐规则会导致大量填充字节（padding）。比如一个结构体包含uint8和uint32，中间会多出3个填充字节。后来我改用零拷贝序列化技术，直接把数据放在共享内存里，避免了序列化开销。当然，这需要硬件支持，不是所有场景都适用。

4.5 实战中的坑与优化建议

讲了这么多理论，最后分享几个我在项目中踩过的坑：

  • 序列化性能瓶颈：CDR序列化在嵌入式平台上可能很慢。我建议对高频数据（比如IMU、轮速）使用扁平化结构体，避免嵌套和变长字段。
  • 发现协议超时：如果网络中有节点频繁上下线，SPDP的超时设置（默认10秒）可能导致系统响应迟钝。我一般会缩短到3秒，但要注意避免误判。
  • 多播风暴：在大型系统中，多播消息可能会淹没网络。我建议对非关键数据使用单播+Discovery Server模式，只在关键控制通道使用多播。
  • 字节序问题：如果系统中有ARM和x86混合部署，一定要确保序列化时使用Big Endian，或者两端协商好字节序。我曾经因为这个问题，导致一个雷达数据在融合模块里解析出乱码。

好了，关于RTPS协议的核心内容就讲到这里。下一章我们会深入DDS的QoS策略，看看怎么通过配置来控制数据的可靠性、时效性和优先级。记住，RTPS是DDS的“骨架”，理解了它，你就掌握了自动驾驶中间件的底层逻辑。

← 上一章 📖 返回目录 下一章 →