相机图像用 Service 请求,机器人移动命令用 Topic 发一次,任务执行却没有反馈,这些接口都能“跑起来”,后面却很难处理超时、取消和节点重启。ROS 2 的四类常用通信方式解决的是不同问题,先按数据语义选择,代码会简单很多。
先用 CLI 看一套正在运行的系统
1 | ros2 node list |
进一步检查单个节点:
1 | ros2 node info /robot_controller |
CLI 只能告诉你接口是否存在和类型是什么。是否过期、谁拥有状态、失败后怎样恢复,还要看消息字段、QoS 和任务设计。
Topic 适合连续数据
相机、IMU、里程计、诊断和速度命令通常用 Topic。发布者把消息送进 DDS,订阅者按自己的节奏接收。Topic 不天然提供“执行完成”,收到 /cmd_vel 也不代表底盘已经达到速度。
周期状态应带时间戳和有效标志。控制器还要设置 watchdog:一段时间没收到新命令就减速或停车,而不是永远执行最后一条消息。
1 | ros2 topic info /cmd_vel --verbose |
Service 适合短请求
Service 有明确的 request 和 response,适合读取一次状态、触发短操作或修改配置。服务回调如果需要几十秒,客户端很难知道进度,也不容易取消;这种任务应改用 Action。
1 | ros2 service type /reset_odometry |
服务成功返回只说明服务器处理了请求。设备是否真的复位、外部动作是否完成,仍应通过响应字段或状态 Topic 验证。
Action 为长任务保留反馈和取消
导航、抓取和轨迹执行可能持续数秒甚至更久。Action 把一次任务拆成 goal、feedback、result 和 cancel。客户端可以看到进度,也可以请求取消。
1 | ros2 action info /navigate_to_pose |
取消请求不等于设备已经停止。Action 服务器要把取消传到底层控制器,并在安全状态确认后返回最终结果。
Parameter 是配置,不是消息队列
Parameter 适合阈值、模式和静态配置。高频变化的目标位置或传感器数据不应靠反复改参数传输。参数更新还要验证范围和组合一致性,避免只改一半配置。
1 | ros2 param get /controller max_speed |
一个简单选择表
| 需求 | 推荐接口 | 仍要补充 |
|---|---|---|
| 连续传感器数据 | Topic | 时间戳、QoS、过期策略 |
| 一次快速查询 | Service | 超时、错误码、幂等性 |
| 导航或抓取任务 | Action | 反馈、取消、安全停止 |
| 节点配置 | Parameter | schema、范围、版本迁移 |
确定接口类型以后,Topic 还要继续选择可靠性、队列深度和 durability。长任务如果需要把“请求取消”落实到“设备已经停下”,可以对照VLA 任务执行状态机里的 CancelRequested、Canceling 和 Canceled 三个状态。
参考资料
证据边界:接口选择表是通用设计建议,不代表某个机器人包的唯一实现。命令名称和接口类型要以目标 ROS 2 系统为准。