摘要：原型阶段用 ROS 2 搭系统又快又香，但一到量产评审，几乎每个团队都会被同一个问题问住："这套东西能量产吗？“这篇文章把 ROS 2 从发布者到回调的完整链路拆成五个环节，逐段分析延迟和抖动从哪里来、调优能到哪一步、量产还有哪些坑，最后给出一个明确的结论：ROS 2 能上量产，但不是"原样上”——它是机器人系统的神经系统，不是脊髓。

---

一、Demo 里很香，量产前心虚

先说一个典型的现场。团队用 ROS 2 搭起了整套机器人软件：感知节点、规划节点、控制节点、可视化、数据回放，一周内跑通全流程。仿真里流畅，真机上也能动。然后量产评审来了，问题很朴素：

“这套东西的延迟是多少？抖动多大？”

“……我们跑起来挺流畅的。”

“依赖包有多少个？升级 ROS 2 版本要多久？”

“……没统计过。”

会议室安静了。这不是团队水平问题——ROS 2 把"快速搭起来"这件事做到了极致，代价是把"确定性"和"可控性"留给了使用者。 而这两样东西，恰恰是量产评审要看的。

先给结论的轮廓：ROS 2 的默认配置离硬实时很远，但它的可调优空间比大多数人以为的大；调优到头之后，还有一条"绕过"的路。这篇文章就沿着这条路径走一遍。

二、把 ROS 2 的实时链路拆开：五个环节

2.1 一条消息的旅程

一条 ROS 2 消息从发布者到回调函数，要经过这样一条链路：

Publisher → rclcpp → rmw → DDS 中间件 → 传输层 → DDS → rmw → rclcpp → Executor → 回调函数

链路上每一环都可能引入延迟和抖动。好消息是每一环都有对应的调优手段；坏消息是，五环都调对，才可能得到一个确定性的结果——只调其中一环，收益会被其他环吃掉。

2.2 环节一：QoS 配置——“可靠"不等于"实时”

这是第一个反直觉的地方：RELIABLE（可靠传输）对实时性往往是负面的。 可靠传输意味着丢包重传，重传带来的是延迟尖峰和抖动——对控制话题来说，"晚到的旧数据"比"丢失"更糟。

给控制类话题的推荐配置组合：

• Reliability: BEST_EFFORT——不重传，允许丢，应用层保证用最新值；
• History: KEEP_LAST，depth = 1——永远只关心最新一帧，旧数据没有价值；
• Durability: VOLATILE——不需要为晚加入的订阅者补历史；
• 配合 Deadline / Liveliness——用 QoS 的监控机制做"数据新鲜度"检测，超时触发兜底策略。

这套组合的哲学和我们在第 2 篇讲的"意图接口"完全一致：控制链路上，数据的新鲜度比完整性重要。

2.3 环节二：传输层——UDP 回环还是共享内存

ROS 2 默认走 UDP（本机通信就是 UDP 回环）。UDP 路径要经过内核网络栈，延迟和抖动都在较高量级。主流 DDS 实现（Cyclone DDS、Fast DDS）都提供共享内存（SHM）传输选项，把同一台机器内的通信从"网络栈路径"切换成"共享内存路径"，延迟和抖动都能下降一个量级左右。

对于"控制和感知在同一台机器上"的机器人——也就是绝大多数人形机器人——开 SHM 是投入产出比最高的一项调优，改动小，收益立竿见影。

还有一个常被忽略的细节：DDS 的发现机制。默认的动态发现靠组播交换端点信息，启动瞬间会有一波"发现风暴"，网络上的其他设备也会看到这些报文。量产系统里建议改用静态配置（在 XML 里写死对端端点），收益有三：启动更快、网络更干净、启动时序可预测——最后一条对"上电后 N 秒必须进入安全状态"这类需求尤其重要。

2.4 环节三：Executor——最被低估的瓶颈

消息到了，谁来回调它？这就是 Executor 的工作，也是 ROS 2 实时性讨论里最容易被低估的一环。

• 单线程 Executor：一个回调堵住，全都堵住。确定性"看起来"好，但一个慢回调就能打乱整个节奏；
• 多线程 Executor：线程池并行回调，吞吐上去了，但优先级反转随之而来——低优先级回调占着线程，高优先级回调却在排队；
• 回调组（Callback Group）：互斥组（Mutually Exclusive）还是可重入组（Reentrant），决定了哪些回调之间有锁语义。设计错了，控制回调和日志回调就会互相等待。

举个具体的优先级反转场景：控制回调（SCHED_FIFO、优先级 99）和日志回调共享同一个线程池，某次日志回调先抢到线程、在里面等磁盘 I/O，控制回调只能排队——高优先级任务的确定性，被低优先级任务的内核阻塞吃掉了。 这类问题在 trace 里才看得见，在代码评审里完全看不见。

社区有专门的"实时 Executor"方案在推进，但坦率说：到现在为止，最确定性的做法不是把 Executor 调好，而是让关键控制路径不走 Executor（后面第 3.5 节展开）。

2.5 环节四：线程调度——中间件线程不是实时线程

DDS 在后台会创建一批线程（收发、发现、计时器），默认优先级、默认调度策略、默认亲和性。ROS 2 的回调线程也是普通的 Linux 线程（CFS）。

想让关键回调准时，必须做三件事：把它设成 SCHED_FIFO、绑到隔离核、并且确认它不会被中间件线程的锁挡住。而"确认不被锁挡住"恰恰是最难的部分——DDS 内部的锁竞争行为，不是文档上能看出来的，得靠实测。

2.6 环节五：CPU 与内存管理

ROS 2 生态默认假设"资源不紧张"：消息动态分配、序列化产生临时对象、线程数量随节点数增长。在实时路径上，这些都要处理：

• 消息预分配（用带分配器的消息类型或对象池）；
• 序列化零拷贝（SHM 的 loaned message 机制）；
• 实时路径上禁止任何动态分配，和我们在第 5 篇讲的部署纪律一致。

三、调优能到哪一步？量产的三个顾虑

3.1 调优阶梯：每一级换一个量级

把上面的手段按阶梯排列，端到端的量级大致如此（以下均为工程经验区间，用于建立量级判断，具体以自测为准）：

配置层级	端到端延迟（典型）	抖动（P99 量级）
默认 ROS 2（UDP 回环、默认 QoS）	200µs–2ms	百µs–ms
+ 共享内存传输（SHM）	50–200µs	几十µs
+ 关键线程 FIFO/绑核 + 消息预分配	30–100µs	10–50µs
+ 绕过 Executor 的自定义实时环	10–50µs	几µs–十µs

这张表的读法：每加一级纪律，大约换回一个数量级；但没有哪一级是"免费的午餐"——SHM 要配置三处（发布端、订阅端、DDS 配置文件），线程调优要实测，绕过 Executor 等于放弃了一半的 ROS 2 便利性。

更重要的是这张表的边界：最后一行的"自定义实时环"，其实已经不是 ROS 2 了。它借用 ROS 2 的接口和生态，但核心是一个 1kHz 的确定性循环。这就是第九篇要展开的"绕过"思路，也是行业量产方案的主流形态。

3.2 量产顾虑一：依赖与体积

ROS 2 完整安装动辄几个 GB，依赖树深（rclcpp、rmw、DDS 厂商实现、插件体系、命令行工具）。量产镜像必须裁剪——裁到只留运行时需要的部分。裁剪本身不难，难的是每次升级都要重新验证裁剪清单，这份维护成本要在立项时就算进预算。

3.3 量产顾虑二：资源占用

两个容易被忽略的数字：线程数和内存基线。 每个节点、每个 DDS 参与者都会带来若干后台线程；节点一多，几十上百个线程很常见。这些线程平时人畜无害，但在隔离核的边缘、在功耗受限的板子上，都会变成实打实的资源账。量产前要把"空载基线"（线程数、内存、CPU）测出来，写进验收指标。

3.4 量产顾虑三：生态迭代与升级成本

ROS 2 是"发行版制"：Humble、Iron、Jazzy……每个发行版有生命周期，到期后安全补丁停止。这意味着一个五到十年的产品周期里，至少要经历一次大的 ROS 2 版本迁移。API 变化、DDS 默认实现切换、行为差异，都会传导到你的代码和测试用例。

升级成本不是"要不要付"的问题，是"什么时候付、付多少"的问题。立项时把版本迁移计划写进产品路线图，比量产三年后被迫升级要便宜得多。

3.5 结论：ROS 2 的定位是神经系统，不是脊髓

把上面的分析收拢，给一个明确的分层结论：

ROS 2 在外，实时环在内。

• 外层（神经系统）：感知、规划、任务管理、人机交互、多机通信、数据回放、调试工具——ROS 2 的优势区，放心用；
• 内层（脊髓）：1kHz 控制环、总线主站、安全逻辑——直写原生代码，共享内存直连，绑定隔离核，不看 Executor 一眼；
• 中间（意图接口）：两层之间的接口，低频、高层语义、可兜底——这正是第 2 篇定义的"意图通道"。

判断一个话题该放外层还是内层，只需要一个数：它的抖动预算。 预算在毫秒级，ROS 2 直连没问题；预算在百微秒以内，至少上 SHM 和线程调优；预算在十微秒级，别犹豫，绕过它。

四、结论

把这篇压成一句话：

ROS 2 能上量产，但不是"原样上"——把它放在神经系统层，别让它进脊髓层。

它把"快速搭系统"的收益做到了极致，而确定性需要你用自己的纪律去换。这不是 ROS 2 的缺点，是定位问题——用神经系统去干脊髓的活，再好的神经也会抖。

五、检查清单：ROS 2 上量产的八项检查

1. 画出"实时域话题"清单。 判据是抖动预算：P99 预算小于多少？把超过百微秒要求的全部标出来。
2. 实时域话题换 QoS。 BEST_EFFORT + KEEP_LAST(1) + VOLATILE，配合 Deadline 监控。
3. 本机通信开 SHM。 发布端、订阅端、DDS 配置三处都要确认生效（用 DDS 自带工具验证走的是共享内存路径）。
4. 关键回调线程设 FIFO + 绑核。 并实测确认不被中间件线程阻塞。
5. 实时路径消息预分配、零拷贝。 禁止动态分配、禁止序列化产生的临时拷贝。
6. 测空载基线。 线程数、内存、CPU 占用写进验收指标，作为后续回归的基准。
7. 锁定 ROS 2 版本并写迁移计划。 记录当前发行版的 EOL 日期，把它放进产品路线图。
8. 维护分界文档。 哪些功能走 ROS 2、哪些走共享内存直连、接口怎么定义——和"双系统"的边界协议一样，这份文档是长期资产。

六、留一个问题给你

量产机器人该不该用 ROS 2？

• 站"该用"的：生态和效率无可替代，确定性靠纪律补；
• 站"慎用"的：量产就是要求确定性，神经系统和脊髓必须分开。

评论区说说你们的实际做法——尤其是已经量产的团队，你们的实时环是怎么处理的？下一篇，我们进入落地清单篇：《从传感器到关节出力：一条实时链路的完整延迟预算》。

---