ESC
输入关键词搜索文章标题和内容

ROS通信三大机制 Topic Service Action怎么选

本文由 linuxROS 整理发布,首发于 linuxros.cn,转载请注明出处。

ROS通信三大机制 Topic Service Action怎么选

导读:ROS节点间怎么对话?Topic、Service、Action三种通信方式各有各的用法——选错轻则效率低,重则系统崩溃。本文用一张对比图讲清三种机制的区别,再配上TF坐标变换与DDS底层支撑,把ROS通信体系一次说透。


一、Topic Service Action 核心机制对比

flowchart TB subgraph TOPIC["Topic 话题通信"] direction TB T1["🔴 Publisher 发布者"] T2["/scan /cmd_vel"] T3["✅ Subscriber 订阅者"] T1 -->|"持续发送"| T2 T2 -->|"随时接收"| T3 end subgraph SERVICE["Service 服务通信"] direction TB S1["🔴 Client 客户端"] S2["/make_plan"] S3["✅ Server 服务端"] S1 -->|"①请求"| S2 S2 -->|"①请求"| S3 S3 -->|"②回复"| S1 S1 -.->|"阻塞等待"| S1 end subgraph ACTION["Action 动作通信"] direction TB A1["🔴 Client 客户端"] A2["/move_base"] A3["✅ Server 服务端"] A1 -->|"①发送目标"| A2 A2 -->|"①发送目标"| A3 A3 -.->|"②持续反馈"| A1 A3 -->|"③最终结果"| A1 end style T1 fill:#E3F2FD,stroke:#1976D2 style T2 fill:#E3F2FD,stroke:#1976D2 style T3 fill:#E3F2FD,stroke:#1976D2 style S1 fill:#FFF8E1,stroke:#F57C00 style S2 fill:#FFF8E1,stroke:#F57C00 style S3 fill:#FFF8E1,stroke:#F57C00 style A1 fill:#E8F5E9,stroke:#388E3C style A2 fill:#E8F5E9,stroke:#388E3C style A3 fill:#E8F5E9,stroke:#388E3C
维度 Topic Service Action
模式 发布/订阅 请求/回复 目标/反馈/结果
同步/异步 异步(各干各的) 同步(等回复再走) 异步(可边干边汇报)
有无返回 无返回 一次返回 持续反馈+最终结果
可取消 不可取消 不可取消 可中途取消
数据特点 高频连续 低频一次性 长周期任务
通俗比喻 📻 收音机广播 📞 打电话 🛵 点外卖(可查进度)
场景 激光数据40Hz 查询路径 导航"去厨房"

二、三种通信方式何时选 典型场景对比

场景1:激光雷达每秒40帧扫描数据

用 Topic。发布者(激光驱动)不停发/scan,订阅者(amcl / costmap)随时收。不需要返回,不需要确认,来了就处理。

输入:sensor_msgs/LaserScan → 输出:无需返回,纯数据流

场景2:临时查询"从当前位置到目标点有没有路径"

用 Service。客户端发请求/make_plan,服务端(navfn)算出路径后一次性返回。客户端等待期间阻塞,直到收到结果才继续运行。

输入:geometry_msgs/PoseStamped(起点+终点) → 输出:nav_msgs/Path(路径点序列)

场景3:导航任务"去厨房,30秒路程"

用 Action。客户端发目标,服务端(move_base)执行过程中持续反馈当前进度(走了多远、剩余距离),任务完成后返回最终结果。如果路上遇到死胡同,客户端可以发取消指令。

来自 linuxros.cn · linuxROS

输入:move_base_msgs/MoveBaseGoal(目标位姿) → 输出:move_base_msgs/MoveBaseFeedback(进度)+ MoveBaseResult(最终结果)


三、TF坐标变换 机器人传感器骨架对齐

所有传感器的数据都在各自的坐标系里——激光在laser坐标,相机在camera坐标,地图在map坐标。TF的作用是把它们统一起来。

flowchart TB MAP["map 地图坐标<br/>amcl发布"] ODOM["odom 里程计坐标<br/>编码器发布"] BASE["base_link 机器人基座"] LASER["laser 激光雷达"] CAMERA["camera 相机"] IMU["imu_link IMU"] MAP -->|"静态变换<br/>定位修正"| ODOM ODOM -->|"动态变换<br/>实时追踪"| BASE BASE -->|"固定偏移<br/>URDF定义"| LASER BASE -->|"固定偏移<br/>URDF定义"| CAMERA BASE -->|"固定偏移<br/>URDF定义"| IMU style MAP fill:#FFF8E1,stroke:#F57C00 style ODOM fill:#E3F2FD,stroke:#1976D2 style BASE fill:#F3E5F5,stroke:#7B1FA2 style LASER fill:#E8F5E9,stroke:#388E3C style CAMERA fill:#E8F5E9,stroke:#388E3C style IMU fill:#E8F5E9,stroke:#388E3C

TF树是父子层级结构:map是最顶层,往下依次是odom → base_link → 各传感器。每个子节点存储相对于父节点的偏移量。当amcl计算出机器人位置后,更新map→odom的关系,所有传感器的位置就自动对齐了。

一句话:TF = 机器人身体的骨架,把各个传感器串成完整的"人体"。


四、总结

场景 用哪个
传感器数据连续传输 Topic
临时查询、一次性请求 Service
长时间任务、需进度 Action

最后记住TF:你的激光数据在"laser"坐标系,地图在"map"坐标系,没有TF做中间人,它们永远对不上号。


五、DDS中间件 通信底层支撑

Topic/Service/Action 的底层都由 DDS(Data Distribution Service)中间件支撑。ROS2 支持多种可替换的中间件实现,开发者可按场景灵活切换。

5.1 常用 DDS 实现 各家中间件特点对比

ROS2 常用的中间件及其获取方式:

中间件 特点 适用场景
FastDDS ROS2 默认,功能完整 通用场景
CycloneDDS 轻量、低延迟 实时性要求高
Iceoryx 共享内存零拷贝 同一主机内高频通信
Zenoh 广域网支持 云边协同
Micro XRCE-DDS 资源占用极小 嵌入式 MCU

说明:通过 git clone 下载源码编译,包含序列化依赖 Fast-CDR、内存管理 foonathan_memory、IDL 代码生成工具 Fast-DDS-Gen 等配套组件。

5.2 DDS 核心特性 对开发者透明可按需切换

  • 对开发者透明:无论用哪种中间件,Topic/Service/Action 的使用方式完全一样——调用 rclcpp/rclpy 接口即可
  • 按需切换:跨主机实时通信用 FastDDS/CycloneDDS,嵌入式设备用 Micro XRCE-DDS,同一主机内高频通信用 Iceoryx

参考来源

  • ROS 2 官方文档(Concepts/About-Interfaces)
  • ROS 2 官方教程(Understanding ROS 2 Actions)
  • micro-coder/ROS-Note 仓库
  • ros-planning/navigation 仓库

版权声明

作者linuxROS
协议本作品采用 CC BY-NC-SA 4.0 许可协议:署名-非商业性使用-相同方式共享
关注欢迎关注微信公众号 linuxROS,获取更多机器人 / 嵌入式 / Linux 干货
返回首页