ROS2 为什么需要action？

公众号致力于点云处理，SLAM，三维视觉，具身智能，自动驾驶等领域相关内容的干货分享，欢迎各位加入，有兴趣的可联系dianyunpcl@163.com。文章未申请原创，未经过本人允许请勿转载，有意转载联系微信920177957。

摘要

在 ROS2 中，官方并没有把通信机制简单划分为“发布订阅”和“服务调用”。而是同时提供了三种通信接口：

• Topic
• Service
• Action

既然已经有 Topic 和 Service，为什么还要设计一种新的通信方式？ROS2 的 Action 不是从零发明出来的，而是在 ROS1 Actionlib 基础上的一次架构升级。ROS1 的 Action 更像是“基于 Topic 拼出来的任务系统”；而 ROS2 的 Action 已经升级成 DDS 原生支持、具备请求确认、QoS 管理和任务生命周期管理能力的完整任务框架。

机器人系统中的三种交互模式

在 ROS2 官方文档中，Topic、Service、Action 被统称为 Interface（接口）。它们虽然都用于节点之间通信，但解决的问题完全不同。如果从系统工程角度来看，可以把机器人中的交互划分为三个层次。

第一层是数据流。例如激光雷达持续发布点云，IMU 持续发布姿态，相机持续发布图像，编码器持续发布里程计，这些数据源源不断地产生。系统关心的是数据能不能持续传输，而不是某一次消息是否执行成功。因此Topic 成为了最合适的选择

第二层是功能调用。例如保存地图，读取参数，重置里程计，查询机器人状态，这些操作通常持续时间很短。系统需要请求->处理->返回结果，于是 Service 应运而生。

第三层则是任务执行。例如导航到目标点，抓取桌上的水杯，巡检指定区域。人形机器人完成一段动作，这些任务可能持续几十秒；几分钟；甚至更长。期间系统不仅需要知道任务是否完成。还需要知道当前进度，执行状态，是否发生异常，是否需要取消，而这正是 Action 解决的问题。

Topic、Service、Action 的本质区别

可以把它们总结为：

进一步理解：

• Topic = 持续产生数据
• Service = 一次请求一次响应
• Action = 长时间运行任务

所以Action 并不是 Service 的升级版，它实际上是机器人系统中的任务调度接口。

为什么导航系统必须使用 Action？

ROS2 官方教程中使用了一个非常经典的案例Fibonacci Action。这个例子看起来只是计算数列。但本质上是在模拟一个耗时任务。例如客户端发送计算 Fibonacci(10)服务器开始计算。在计算过程中持续返回反馈，最终返回结果。整个过程与导航任务高度相似。如果把 Fibonacci 换成NavigateToPose逻辑几乎完全一致。客户端发送去会议室，服务器开始执行路径规划，开始移动，避障，重新规划，继续移动，期间不断反馈剩余距离，当前位置，导航状态。最终返回导航成功或者导航失败。这也是为什么 Nav2 的核心接口全部基于 Action。

Action 到底由什么组成？

ROS2 官方文档明确指出Action 本质上是建立在 Topic 和 Service 之上的高级抽象。一个 Action 实际由五部分组成：

• Goal Service
• Result Service
• Cancel Service
• Feedback Topic
• Status Topic

架构如下：

从系统设计角度来看：

• Goal Service 负责提交任务。
• Feedback Topic 负责实时进度反馈。
• Result Service 负责返回最终结果。
• Cancel Service 负责终止任务。
• Status Topic 负责同步当前状态。

因此Action 本质上是 ROS2 帮开发者封装好的一套任务管理框架。否则开发者需要自己维护多个 Topic 和 Service。系统复杂度会急剧增加。

一个最小 Action Server 长什么样？

ROS2 官方教程中，一个 Action Server 的核心流程非常简单。首先创建 Server：

action_server_ =
rclcpp_action::create_server<Fibonacci>(
this,
"fibonacci",
handle_goal,
handle_cancel,
handle_accepted);

然后处理 Goal：

handle_goal(...)
{
return ACCEPT_AND_EXECUTE;
}

执行过程中发送 Feedback：

goal_handle->publish_feedback(feedback);

任务结束：

goal_handle->succeed(result);

整个生命周期非常清晰：接收目标->开始执行->反馈进度->返回结果。这正是机器人任务执行最常见的模式。

人形机器人中Action 为什么越来越重要？

过去 ROS 最典型的 Action 场景是导航。但随着具身智能的发展。Action 已经开始成为高层行为控制的重要接口。例如抓取矿泉水瓶，实际上包含：目标识别；轨迹规划；机械臂运动；夹爪闭合；抓取确认，整个过程持续数秒。期间可能出现：目标丢失，路径碰撞，抓取失败，系统需要持续反馈；状态同步；任务取消；结果返回。这些需求与导航任务完全一致。因此MoveIt2以及Nav2未来的人形机器人任务系统几乎都在大量使用 Action。

开发者可能把 Action 理解成带反馈的 Service。这种说法虽然没错。但并不完整，因为 Action 真正体现的是 ROS2 的系统工程思想。在 ROS2 中Topic 解决数据通信；Service 解决功能调用；Action 解决任务管理。三者分别对应：Data Flow，Function Call，Task Execution，这也是 ROS2 相比传统机器人框架更加成熟的地方。它不仅提供通信能力，更提供完整的系统组织能力。

Action 在人形机器人中的核心价值：

• 安全性：可抢占（Preemptable）—— 平衡控制器可以随时取消行走 Action
• 可观测性：Feedback 机制让上层 AI 实时了解执行进度
• 异步非阻塞：行为树引擎可以并发监控多个 Action
• 状态明确：SUCCEEDED / ABORTED / CANCELED 三态结果，便于状态机编排
• 长时间任务支持：从几秒到几分钟的任务都能优雅处理

写在最后

从 Topic 到 Service，再到 Action，ROS2 并不是在不断增加新的通信接口。而是在不断完善机器人系统中的不同交互模式。对于机器人而言激光雷达数据属于 Topic；参数配置属于 Service；导航、抓取、巡检属于 Action。所以Action 并不是一个高级功能。而是现代机器人系统不可缺少的基础设施。尤其是在 Nav2、MoveIt2、具身智能、人形机器人快速发展的今天。Action 正逐渐成为机器人任务执行层的标准接口。最后总结：Topic 负责数据流，Service 负责功能调用，而 Action 负责管理机器人世界中的“长期任务”。

以上内容如有错误请留言评论，欢迎指正交流。如有侵权，请联系删除