徐卓菲1. ROS2动作概念入门：从零开始理解核心机制
第一次接触ROS2的动作概念时，我完全被官方文档中那些抽象的术语搞晕了。直到在实际项目中尝试用动作控制机械臂抓取物体，才真正理解这个机制的精妙之处。ROS2的动作（Action）是介于话题（Topic）和服务（Service）之间的一种高级通信机制，它完美解决了长时间运行任务的监控需求。
想象一下这样的场景：你需要让机器人移动到房间的某个位置。如果使用服务调用，你只能发送一个"去那里"的请求，然后干等着直到完成（或超时）。而动作允许你持续获取机器人移动的进度反馈，必要时还能中途取消任务——这就是动作的核心价值。
提示：ROS2的动作基于ROS1的actionlib改进而来，但在接口定义和实现细节上有显著优化，特别是与DDS的深度集成。
1.1 动作的三大核心组件
每个ROS2动作由三个关键部分组成：
- 目标（Goal）：定义要执行的任务参数，比如"移动到坐标(x=1.0, y=2.0)"
- 反馈（Feedback）：持续更新的进度信息，比如"当前已移动50%距离"
- 结果（Result）：任务完成后的最终输出，比如"成功到达目标，耗时5.3秒"
这种结构特别适合需要持续监控的长时间运行任务，比如：
- 机械臂轨迹跟踪
- 导航路径执行
- 复杂计算任务
- 大文件传输
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动作VS服务VS话题：如何正确选择通信机制
刚开始学习ROS2时，我经常纠结该用哪种通信方式。通过一个实际项目中的错误选择，我总结出了这张对比表：
| 特性 | 话题(Topic) | 服务(Service) | 动作(Action) |
|---|---|---|---|
| 通信模式 | 单向/持续 | 双向/一次性 | 双向/长时间 |
| 适用场景 | 传感器数据流 | 快速查询/命令 | 可监控的长任务 |
| 反馈机制 | 无 | 仅最终响应 | 持续反馈+最终结果 |
| 典型延迟 | 低 | 中 | 高 |
| 可取消性 | 不可 | 不可 | 可 |
2.1 从实际案例看选择依据
在我的机械臂控制项目中，最初错误地使用了服务来控制抓取动作。当遇到以下情况时问题就出现了：
- 无法获取实时的抓取力度反馈
- 无法在抓取过程中根据新指令调整策略
- 超时设置不合理导致整个系统阻塞
改用动作接口后，我们能够：
- 实时监控夹爪的力度反馈
- 在接近物体时动态调整速度
- 随时取消当前动作转应急模式
3. 手把手创建第一个动作：移动机器人案例
让我们通过一个具体的移动机器人案例，一步步实现完整的动作交互。这个例子基于ROS2 Humble版本，但核心概念适用于所有ROS2版本。
3.1 定义动作接口文件
首先创建RobotMovement.action文件：
code复制# 目标定义
geometry_msgs/Point target_position
float32 max_speed
---
# 结果定义
float32 total_time
bool success
---
# 反馈定义
geometry_msgs/Point current_position
float32 progress
这个文件定义了：
- 目标：包含目标位置和最大速度限制
- 结果：返回总耗时和成功状态
- 反馈：持续提供当前位置和进度百分比
3.2 编写动作服务器代码
关键部分代码解析（Python示例）：
python复制class MoveRobotActionServer(Node):
def __init__(self):
super().__init__('move_robot_server')
self._action_server = ActionServer(
self,
RobotMovement,
'move_robot',
self.execute_callback)
async def execute_callback(self, goal_handle):
self.get_logger().info('开始执行移动命令...')
feedback_msg = RobotMovement.Feedback()
# 模拟移动过程
total_distance = calculate_distance(initial_pos, goal_handle.request.target_position)
current_pos = initial_pos
while not reached_target(current_pos, goal_handle.request.target_position):
# 检查是否收到取消请求
if goal_handle.is_cancel_requested:
goal_handle.canceled()
return RobotMovement.Result()
# 更新位置和进度
current_pos = move_step(current_pos, goal_handle.request)
feedback_msg.current_position = current_pos
feedback_msg.progress = calculate_progress(current_pos, total_distance)
# 发布反馈
goal_handle.publish_feedback(feedback_msg)
await asyncio.sleep(0.1) # 控制反馈频率
# 完成任务
goal_handle.succeed()
result = RobotMovement.Result()
result.total_time = time_used
result.success = True
return result
3.3 实现动作客户端
客户端的关键操作流程：
- 发送目标
- 处理反馈
- 接收结果
python复制def send_goal(self):
goal_msg = RobotMovement.Goal()
goal_msg.target_position = Point(x=1.0, y=2.0, z=0.0)
goal_msg.max_speed = 0.5
self._send_goal_future = self._action_client.send_goal_async(
goal_msg,
feedback_callback=self.feedback_callback)
self._send_goal_future.add_done_callback(self.goal_response_callback)
def feedback_callback(self, feedback_msg):
self.get_logger().info(
f'当前进度: {feedback_msg.progress*100:.1f}%'
f'当前位置: x={feedback_msg.current_position.x:.2f},'
f'y={feedback_msg.current_position.y:.2f}')
4. 动作实战中的高级技巧与避坑指南
在实际项目中使用动作接口时，我积累了一些宝贵的经验教训，这些在官方文档中往往不会提及。
4.1 反馈频率的黄金法则
反馈不是越多越好！经过多次测试，我发现最佳实践是：
- 机械控制：50-100Hz（与控制循环同步）
- 导航任务：5-10Hz
- 计算任务：1-2Hz
过高的频率会导致：
- 网络拥堵
- 不必要的CPU开销
- 客户端处理瓶颈
4.2 超时设置的常见陷阱
新手常犯的错误是使用统一的超时设置。实际上应该：
-
根据任务类型分层设置：
- 目标接收超时（通常2-5秒）
- 执行超时（根据任务复杂度）
- 反馈间隔超时（通常3倍于预期间隔）
-
在客户端和服务端都实现超时处理：
python复制# 客户端超时检查
async def goal_response_callback(self, future):
try:
goal_handle = future.result(timeout=5.0)
except asyncio.TimeoutError:
self.get_logger().warn('服务器响应超时')
return
4.3 取消机制的正确实现
可靠的取消功能需要处理三种情况：
- 正常取消流程
- 取消请求超时
- 取消过程中的异常
推荐模式：
python复制def handle_cancel(self, goal_handle):
# 1. 立即停止执行器
self.executor.stop()
# 2. 清理资源
self.cleanup_resources()
# 3. 返回取消结果
goal_handle.canceled()
return CancelResponse.ACCEPT
4.4 动作命名的最佳实践
糟糕的动作命名会导致系统难以维护。我采用的命名规范：
- 动词开头表示意图：
move_to_position优于position_command - 包含执行主体：
arm_move_joint区别于base_move_to - 版本控制：对于重大变更，添加v2后缀
5. 调试动作接口的实用技巧
当动作通信出现问题时，这些调试方法可以节省大量时间。
5.1 命令行工具的使用
ROS2提供了强大的命令行工具来检查动作：
bash复制# 列出所有动作
ros2 action list
# 查看动作类型
ros2 action info /move_robot
# 手动发送目标
ros2 action send_goal /move_robot robot_interfaces/action/RobotMovement "{target_position: {x: 1.0, y: 2.0}, max_speed: 0.5}" --feedback
5.2 可视化工具推荐
- rqt_action：图形化界面发送和监控动作
- Foxglove Studio：专业级的ROS2数据可视化
- PlotJuggler：反馈数据的时序分析
5.3 常见错误代码速查表
| 错误代码 | 含义 | 典型解决方案 |
|---|---|---|
| ABORTED | 服务器异常终止 | 检查服务器日志 |
| REJECTED | 目标被拒绝 | 验证目标参数 |
| CANCELED | 成功取消 | 正常流程 |
| UNKNOWN | 状态异常 | 重启参与者 |
6. 性能优化：让动作通信更高效
在大规模机器人系统中，动作接口的性能优化至关重要。
6.1 序列化优化技巧
默认的CDR序列化可能不是最高效的。可以考虑：
- 使用自定义类型替代标准类型
- 减少反馈消息中的冗余字段
- 采用更紧凑的浮点表示
6.2 DDS配置调优
在colcon.meta中添加：
json复制{
"names": {
"rmw_fastrtps_cpp": {
"qos": {
"action": {
"reliability": "reliable",
"durability": "volatile",
"history": "keep_last",
"depth": 10
}
}
}
}
}
6.3 多动作并行处理
对于需要同时处理多个动作请求的场景：
python复制from concurrent.futures import ThreadPoolExecutor
class MultiActionServer:
def __init__(self):
self.executor = ThreadPoolExecutor(max_workers=4)
def handle_goal(self, goal):
future = self.executor.submit(self.process_goal, goal)
return future
7. 真实项目案例：仓储机器人导航系统
在我参与的自动化仓储项目中，动作接口用于协调多机器人导航。系统架构如下：
- 任务调度层：通过
dispatch_navigation动作接收运输任务 - 路径规划层：
plan_path动作生成最优路径 - 运动控制层：
execute_movement动作控制底层驱动
关键创新点：
- 采用动作链实现复杂任务分解
- 动态优先级调整机制
- 故障恢复的嵌套动作设计
性能指标：
- 平均任务响应时间：<200ms
- 99%的反馈延迟：<50ms
- 系统可用性：99.98%
8. 扩展学习：动作与行为树的结合
对于更复杂的决策逻辑，可以将ROS2动作与行为树结合：
python复制from py_trees.behaviour import Behaviour
import rclpy.action
class MoveToPosition(Behaviour):
def __init__(self, name, action_client, target):
super().__init__(name)
self._client = action_client
self._goal = RobotMovement.Goal()
self._goal.target_position = target
def update(self):
if not self._client.wait_for_server(timeout_sec=0.5):
return Status.FAILURE
self._send_goal_future = self._client.send_goal_async(self._goal)
return Status.RUNNING
这种模式特别适合：
- 混合自主性系统
- 可中断的任务流程
- 多条件触发的复杂行为