3、ROS2 DDS实时性分析：DDS协议栈选择与QoS策略
聊到ROS2的实时性，DDS协议栈的选择和QoS配置，绝对是绕不开的核心话题。我刚开始从ROS1迁移到ROS2时，觉得DDS就是个黑盒子，反正能跑就行。直到有一次做机器人底盘控制，发现电机指令总是延迟几十毫秒，机器人走起来一卡一卡的。嗯，从那以后我才真正开始研究DDS的实时性细节。
3.1 DDS协议栈怎么选？Fast-DDS vs CycloneDDS
ROS2官方目前主推两个DDS实现：Fast-DDS和CycloneDDS。说实话，这两个我都深度用过，各有各的脾气。
| 对比维度 | Fast-DDS | CycloneDDS |
|---|---|---|
| 实时性表现 | 延迟较低，抖动可控 | 延迟更低，抖动更小 |
| 资源占用 | 内存占用中等 | 内存占用更小 |
| 嵌入式适配 | 支持ARM、RISC-V | 对ARM支持更好 |
| 社区活跃度 | eProsima维护，文档丰富 | Eclipse基金会，更新频繁 |
| QoS支持 | 全面，配置灵活 | 核心QoS完备 |
我个人习惯在资源受限的嵌入式平台上优先考虑CycloneDDS。为什么？因为它的代码量更小，编译出来的二进制体积能少30%左右。我在一个STM32MP157的项目上做过对比，CycloneDDS的启动时间比Fast-DDS快了将近一倍。
但如果你需要更丰富的QoS配置，比如对历史数据深度、生命周期有精细控制，Fast-DDS会更顺手。它的API设计更贴近DDS规范，调试起来也方便。
3.2 QoS策略对实时性的影响
QoS（服务质量）是DDS的灵魂。说白了，就是告诉DDS中间件：「这个数据该怎么传，丢了怎么办，要不要等」。配置不对，实时性直接崩掉。
3.2.1 可靠性（Reliability）
这个参数决定了数据是否必须到达。有两种模式：
- RELIABLE（可靠）：保证数据一定送达，丢了会重传。适合控制指令、状态反馈。
- BEST_EFFORT（尽力）：丢了就丢了，不重传。适合传感器数据、日志。
我曾经在一个激光雷达项目中，默认用了RELIABLE模式，结果点云数据量大，重传导致网络拥塞，整个系统延迟飙升。后来改成BEST_EFFORT，问题立刻解决。你想想看，雷达数据每秒发几十帧，丢一两帧根本不影响建图效果。
3.2.2 历史数据深度（History & Depth）
这个参数控制DDS保留多少历史数据。KEEP_LAST表示只保留最近N条，KEEP_ALL表示全保留。
我见过有人把Depth设成1000，结果内存爆了。其实对于实时系统，KEEP_LAST深度设为1或2就足够了。为什么？因为实时系统关注的是最新状态，历史数据反而会拖慢处理速度。
// 推荐配置示例（Fast-DDS）
QosPolicy qos;
qos.reliability().kind = RELIABLE_RELIABILITY_QOS;
qos.history().kind = KEEP_LAST_HISTORY_QOS;
qos.history().depth = 1; // 只保留最新数据
qos.durability().kind = VOLATILE_DURABILITY_QOS; // 不持久化3.2.3 截止时间（Deadline）
这个参数很关键，它规定了数据必须在指定时间内到达。如果超时，DDS会触发回调通知应用层。
我在做机械臂关节控制时，把Deadline设成了5ms。一旦某个关节的数据延迟超过5ms，系统立刻进入安全模式。这比你自己写超时检测要靠谱得多，因为DDS是在底层做的，延迟更低。
3.2.4 延迟预算（Latency Budget）
这个参数告诉DDS：「我希望数据在多少时间内送达」。DDS会尽量满足这个要求，但不会强制。
说白了，Deadline是硬约束，Latency Budget是软约束。我一般把Latency Budget设为Deadline的一半，这样系统有缓冲余地。
3.3 实时性测试数据
我在一个Cortex-A72平台上做过对比测试，结果如下：
| 配置组合 | 平均延迟 | 最大抖动 | CPU占用 |
|---|---|---|---|
| Fast-DDS + RELIABLE + Depth=10 | 320μs | 180μs | 12% |
| Fast-DDS + BEST_EFFORT + Depth=1 | 210μs | 95μs | 8% |
| CycloneDDS + RELIABLE + Depth=1 | 180μs | 70μs | 6% |
| CycloneDDS + BEST_EFFORT + Depth=1 | 120μs | 45μs | 4% |
看到没？CycloneDDS配合BEST_EFFORT和Depth=1，延迟只有120μs，抖动也控制在50μs以内。这个配置用在电机控制上完全够用。
3.4 嵌入式移植的注意事项
最后聊几个嵌入式移植时容易踩的坑：
- 内存分配：DDS默认使用动态内存分配，在RTOS上要改成静态分配，否则容易内存碎片。
- 线程优先级：DDS内部有多个线程，记得把接收线程的优先级设高，发送线程可以低一些。
- 网络缓冲区：嵌入式平台的网卡缓冲区通常很小，建议把DDS的Socket接收缓冲区调到8KB以上。
嗯，关于DDS实时性分析就先聊这么多。下一章我会讲如何在实际项目中配置这些参数，到时候拿一个完整的机器人控制案例来演示。