在上一篇《ROS 2 Node节点详解一个Node从启动到执行到底发生了什么》中我们沿着Node → Process → Thread → Callback → Executor → Linux Scheduler → CPU这条链路对 ROS 2 的运行机制进行了分析。如果说 Node 解决的是“机器人软件应该如何拆分”的问题那么接下来就必须解决另一个更加基础的问题拆开的这些 Node 之间到底如何通信一台真正的机器人很少只有一个程序。一个人形机器人可能同时运行视觉感知、语音交互、环境感知、定位、运动规划、关节控制、状态监控等大量模块一台工业机器人则可能同时存在机器人控制器、伺服驱动、传感器、运动规划、故障诊断等软件模块。这些模块必须持续交换数据。例如摄像头 ↓ 视觉Node ↓ 目标识别 ↓ 规划Node ↓ 控制Node ↓ 执行器如果所有模块都直接调用彼此的函数那么系统会快速形成复杂的依赖关系A → B A → C A → D B → C B → D C → D当机器人软件规模继续扩大以后修改一个模块可能影响多个模块甚至整个系统。ROS 2的重要价值之一就是通过统一的通信机制让不同 Node 之间能够以相对松耦合的方式进行数据交换。而 ROS 2 最核心的三种通信方式就是Topic、Service、Action。很多初学者会简单记忆Topic用于发布订阅Service用于请求响应Action用于长时间任务。这当然没错。但如果真正进入机器人开发就会发现三个问题为什么激光雷达应该使用Topic为什么某些控制操作更适合Service为什么导航任务需要Action而不是普通Service更进一步Topic传输的数据到底经过什么机制QoS为什么会影响机器人通信Reliable和Best Effort到底应该怎么选择通信数据及时到达之后为什么仍然不代表机器人能够及时处理这些问题会把我们从 ROS 2 应用层一路带到 DDS再进一步连接到操作系统实时性。因此这一篇我们不只讲“怎么用”而是从机器人系统设计的角度真正理解 Topic、Service、Action 之间的区别以及它们为什么最终会与实时操作系统产生联系。一、Topic机器人为什么需要一个持续的数据流理解ROS 2通信机制最容易从Topic开始。Topic采用的是经典的Publish / Subscribe也就是发布/订阅模型。假设机器人上有一个激光雷达。激光雷达不断产生扫描数据。那么可以设计/scan │ ↓ ┌───────────────┐ │ Lidar Node │ └───────────────┘ │ Publish │ ↓ ROS 2 Topic │ ┌──────┼───────┐ ↓ ↓ ↓ 定位Node 建图Node 障碍物Node激光雷达Node只负责“我产生数据。”至于谁使用数据它并不需要知道。定位Node可以订阅。建图Node可以订阅。障碍物检测Node也可以订阅。甚至未来增加一个新的AI感知Node也可以直接订阅。这就是Topic最大的价值数据生产者与数据消费者解耦。Topic为什么特别适合传感器因为机器人传感器有一个非常明显的特点持续产生数据。例如摄像头30 FPS激光雷达持续扫描IMU100Hz / 200Hz / 1kHz关节状态持续更新这些数据天然适合形成一个数据流。例如时间 │ ├── t0 → IMU数据 ├── t1 → IMU数据 ├── t2 → IMU数据 ├── t3 → IMU数据 ├── t4 → IMU数据 └── t5 → IMU数据消费者不需要每次主动询问“有没有新数据”而是“有新数据的时候通知我。”这就是发布/订阅模型。Topic带来的第一个优势解耦假设一个机器人有Lidar Node Localization Node Mapping Node Navigation Node传统方式可能需要Lidar → Localization Lidar → Mapping Lidar → Navigation而Topic模式下/scan │ ┌───────┼────────┐ ↓ ↓ ↓ Localization Mapping Navigation激光雷达只需要发布一次。其他Node根据需要订阅。这使得机器人系统可以不断扩展。Topic的问题数据一定要“可靠”吗这里开始进入ROS 2一个非常重要的概念QoS。假设激光雷达每秒发送大量数据。如果网络偶尔丢失一帧Frame 100 Frame 101 Frame 102 ↓ Frame 103 丢失 ↓ Frame 104对于很多实时传感器数据来说系统可能并不需要为了Frame 103而停下来等待。因为机器人马上还会收到Frame 104 Frame 105 Frame 106这种情况下最新的数据可能比历史数据更加重要。这就是为什么机器人通信不能简单地理解成“数据一定要一条不漏。”真正需要考虑的是这个数据的业务语义是什么对于某些传感器实时性 完整性而对于另外一些数据完整性 延迟这就是QoS存在的重要原因。二、Service为什么机器人有些事情不能使用TopicTopic适合持续数据流。但是机器人系统还有另外一种非常典型的需求请求一个操作然后等待结果。这时候Service更加合适。它的模型非常简单Client │ │ Request ↓ Server │ │ Response ↓ Client例如机器人系统 │ ├── 请求清空地图 │ ↓ 地图Node │ └── 返回成功或者请求 读取当前参数 ↓ 参数服务 ↓ 返回 参数值这种通信方式的特点是一次请求对应一次响应。Service适合什么样的机器人场景例如参数设置设置最大速度 设置加速度 设置传感器参数状态查询查询设备状态 查询当前配置简单控制启动设备 停止设备 复位设备这些操作通常并不需要持续反馈。因此Service非常适合。为什么Service不适合长时间任务假设机器人收到一个任务“移动到房间B。”这可能需要20秒。如果使用ServiceRequest ↓ 等待20秒 ↓ Response这时候调用者很难知道机器人到底走到哪里了有没有遇到障碍物任务是不是卡住了还需要多久是否应该取消所以对于机器人这种具有明显任务过程的系统来说Service就显得不够灵活。这就是Action存在的原因。三、Action为什么机器人导航、机械臂运动更适合ActionAction可以理解为专门为长时间、可反馈、可取消的任务设计的通信机制。它的基本逻辑可以理解成Goal ↓ 执行 ↓ Feedback ↓ 执行 ↓ Feedback ↓ Result例如机器人收到前往目标位置。执行过程中可以不断反馈Goal 前往105 ↓ Feedback 当前位置21 ↓ Feedback 当前位置42 ↓ Feedback 当前位置73 ↓ Feedback 当前位置95 ↓ Result 目标到达如果途中出现异常障碍物出现 ↓ 任务暂停 ↓ 重新规划甚至可以Cancel取消任务。这对于机器人非常重要。Action为什么适合机器人因为很多机器人行为本身就是持续一段时间才能完成的任务。例如导航机械臂移动抓取放置对接巡检路径跟踪复杂动作执行这些任务通常都有开始 → 执行 → 反馈 → 完成/取消的过程。所以Action非常符合机器人任务的天然结构。Topic、Service、Action怎么选择可以简单总结成通信机制核心模型典型场景Topic发布/订阅传感器、状态、连续数据Service请求/响应查询、配置、简单操作ActionGoal/Feedback/Result导航、运动、长时间任务但是实际工程中不能只靠“功能名称”选择。还需要考虑数据频率延迟可靠性数据是否允许丢失是否需要反馈是否可以取消网络环境CPU负载实时性要求而这些问题最终又会进入DDS与QoS。四、ROS 2通信为什么离不开DDSQoS又到底解决什么问题如果把ROS 2通信比作一个城市的交通系统那么Topic、Service和Action更像是不同的交通组织方式。而DDS则更接近于负责底层数据通信的基础设施。ROS 2采用中间件抽象将上层ROS 2 API与底层通信实现隔离开。可以简单理解为ROS 2 Application ↓ rclcpp ↓ RMW ↓ DDS ↓ Network / IPC这样开发者使用ROS 2的时候并不需要自己处理底层通信的大量细节。例如publisher-publish(msg);开发者只需要关注“我要发布一条消息。”至于消息如何发现对端、如何传输、如何序列化、如何进行通信管理则由底层中间件负责。这也是ROS 2能够支持复杂机器人系统的重要原因之一。QoS机器人通信不能只有一种模式如果所有机器人数据都采用完全相同的通信策略那么系统很快会出现问题。例如摄像头图像 激光雷达 IMU 控制命令 诊断信息 参数这些数据的重要性、频率和实时性要求完全不同。所以ROS 2提供QoS机制让通信双方能够针对数据类型配置不同的服务质量策略。其中最常见的就是Reliability主要包括Best Effort ReliableBest Effort可以理解为尽可能快速地把数据送出去不强调每一条数据都必须成功送达。Reliable则更加关注数据需要可靠到达。这两种策略没有绝对的“谁更好”。关键取决于数据是什么。例如高速传感器 ↓ Best Effort可能更加合理。因为旧数据 ↓ 意义下降而对于某些关键控制或状态数据Reliable可能更加重要。Durability后来加入的节点要不要看到过去的数据再比如地图地图并不是每毫秒产生一个完全独立的新数据。如果一个新的Node刚刚启动它可能希望获得当前有效的地图信息。这时候就需要考虑数据是否应该被保留这就是Durability相关机制需要解决的问题。History保留多少历史消息例如Keep Last 10表示只保留最近的一定数量消息。对于高频传感器数据而言通常没有必要无限保存。因为旧数据 ↓ 价值降低但是某些数据可能需要更加完整的历史记录。因此History也是需要结合实际应用配置的。Deadline数据多久应该出现一次这对机器人实时性尤其重要。假设IMU 100Hz理论上每10ms应该有一条数据。如果突然10ms 20ms 40ms才收到数据那么系统可能已经出现异常。Deadline可以帮助系统表达这种时间约束。这也是QoS与机器人实时系统开始产生直接联系的地方。五、通信“可靠”不等于机器人“实时”从ROS 2进一步走向望获rtLinux现在把整条通信链路重新画出来传感器 ↓ ROS 2 Node ↓ Topic ↓ QoS ↓ DDS ↓ Executor ↓ Callback ↓ Thread ↓ Linux Scheduler ↓ CPU看到这里一个非常重要的问题就出现了如果DDS已经把数据可靠地传到了Node那么机器人是不是就一定能实时处理答案并不是。因为通信及时到达 ≠ CPU及时执行。例如一个激光雷达数据已经到达DDS ↓ ROS 2 ↓ Callback Ready但此时CPU正在运行AI推理或者图像处理或者网络中断那么控制Callback仍然需要等待CPU。因此数据延迟 调度延迟 Callback执行时间共同决定了机器人任务最终的响应时间。这就是为什么机器人实时系统不能简单理解为“ROS 2通信快所以机器人就是实时的。”实际上机器人实时性至少涉及几个层次通信实时性 ↓ Executor执行及时性 ↓ 线程调度及时性 ↓ CPU资源确定性 ↓ 中断响应 ↓ 内核调度当机器人控制周期进一步缩短以后这些问题会越来越明显。例如机械臂控制1ms甚至更加严格的控制周期。如果控制任务偶尔受到其他任务影响1ms 1ms 1.2ms 1ms 3ms 1ms那么平均值可能看起来仍然不错。但实时系统更加关心的是最坏情况下发生什么这也是实时系统与普通应用系统的重要区别之一。因此当ROS 2逐渐从实验室开发环境走向工业机器人、机械臂、人形机器人和智能制造设备之后系统架构就不能只关注ROS 2 DDS还需要进一步关注ROS 2 ↓ Executor ↓ 实时线程 ↓ 实时调度 ↓ CPU核心隔离 ↓ IRQ隔离 ↓ 实时Linux在这个底层架构中望获 OS 的望获rtLinux可以作为实时操作系统层的一种技术选择。它并不是替代ROS 2。相反更合理的理解是┌───────────────────────────┐ │ AI / 感知 / 规划 / 控制 │ ├───────────────────────────┤ │ ROS 2 │ │ Node / Topic / Action │ │ QoS / Executor │ ├───────────────────────────┤ │ DDS / RMW │ ├───────────────────────────┤ │ 望获rtLinux │ │ 实时调度 / 核心隔离 / 资源管理 │ ├───────────────────────────┤ │ 国产CPU / SoC │ └───────────────────────────┘ROS 2主要解决机器人软件模块之间怎么协作。DDS主要解决数据如何在通信中间件层传输。Executor解决ROS 2的Callback如何组织执行。而实时操作系统进一步解决线程如何获得CPU以及如何减少关键任务受到其他任务的干扰。因此真正面向机器人产品设计时应该把它看成一条完整的技术链应用 → ROS 2 → DDS → Executor → 实时Linux → CPU。其中任何一层出现瓶颈都可能最终影响机器人系统的行为。例如Topic设计不合理 ↓ 数据堆积 QoS配置不合理 ↓ 通信行为异常 Executor设计不合理 ↓ Callback等待 线程优先级不合理 ↓ 控制任务延迟 CPU资源没有隔离 ↓ 后台任务干扰 IRQ没有合理分配 ↓ 中断影响控制 操作系统实时性不足 ↓ Worst-case latency增加这也说明机器人实时性从来不是某一个软件组件单独决定的。它是从应用、通信、中间件、执行器一直到底层操作系统共同形成的系统能力。写在最后Topic、Service、Action只是开始如果只是ROS 2入门那么记住Topic → 发布/订阅 Service → 请求/响应 Action → 长时间任务已经足够。但如果真正进入机器人产品研发就需要进一步理解Topic ↓ QoS ↓ DDS ↓ Executor ↓ Callback ↓ Thread ↓ Scheduler ↓ CPU因为机器人系统真正复杂的地方不是“数据能不能传过去。”而是数据传过去以后能不能在规定的时间内被正确处理。这就是机器人软件从普通分布式应用走向实时系统时最大的变化之一。例如对于摄像头、激光雷达等高频数据系统可能更加关注数据吞吐和新鲜度对于机器人控制任务则更加关注执行周期、最大延迟和抖动对于导航Action则需要考虑任务过程、反馈和取消对于工业机器人还需要进一步考虑长期稳定运行、故障恢复和资源隔离。因此ROS 2通信机制本身只是机器人实时系统的一部分。当我们继续向下研究就会进入一个更加核心的问题ROS 2中的数据已经到了为什么Callback还是可能不能及时执行答案就在Executor和操作系统调度机制中。下一篇我们将进一步进入ROS 2非常核心、同时也非常容易被低估的技术组件《ROS 2 QoS到底是什么Reliability、Durability、History、Deadline一次讲清楚》我们会从QoS的底层逻辑出发分析不同QoS策略对机器人传感器、控制、导航以及实时通信的影响并进一步讨论为什么“Reliable”并不意味着“实时”这也会成为后续深入ROS 2实时性、实时Linux、CPU核心隔离以及望获rtLinux的重要技术基础。
