2. ROS2基础回顾
在自动驾驶仿真与实车联调中,ROS2 是连接感知、定位、规划、控制与车辆执行层的“神经系统”。理解 ROS2 的通信模型,不只是记住几个命令,而是要在调试时能迅速判断:数据为什么没到、延迟卡在哪、参数是否生效、多个进程如何跨机器协同。本节把节点、话题、服务、动作、参数、Launch 文件与分布式通信机制串成一条完整的工程认知链。
一、核心原理:计算图与六种通信要素
ROS2 的运行视图称为计算图。计算图由节点、话题、服务、动作、参数和 Launch 文件共同构成。节点是基本执行单元,通常一个节点负责一个相对独立的职责,例如激光雷达驱动、点云滤波、路径规划或底盘控制。节点之间不直接持有对方指针,而是通过中间件(默认 DDS)以“发布/订阅”“请求/响应”“目标/反馈/结果”等方式交互。
话题是单向、异步、多对多的数据流,适合高频连续数据,如 /scan、/imu/data、/tf、/cmd_vel。服务是双向、同步、一对一的请求响应,适合“查询一次、执行一次”的操作,如清空代价地图、保存地图、切换模式。动作则面向长耗时任务,包含目标、反馈、结果三阶段,并支持取消,适合“导航到目标点”“泊车入位”这类需要过程反馈的任务。参数是节点的配置项,可在启动时设置,也可运行时动态调整。Launch 文件负责把多个节点、参数、命名空间、重映射和条件逻辑组织成一次可复现的启动过程。
二、方法流程:从单节点调试到多机联调
工程上建议按“先单节点、再话题、后服务动作、最后 Launch 与分布式”的顺序推进。第一步,用 ros2 run 单独启动节点,确认节点能正常初始化;第二步,用 ros2 topic list、ros2 topic echo、ros2 topic hz 检查话题是否存在、数据是否连续、频率是否达标;第三步,用 ros2 service list 与 ros2 action list 验证服务与动作接口;第四步,用 ros2 param list、ros2 param get/set 检查参数;第五步,用 Launch 文件把上述过程固化,并通过 ROS_DOMAIN_ID 与 DDS 配置实现跨机器通信。
# 查看节点与话题
ros2 node list
ros2 topic list -t
ros2 topic hz /scan
ros2 topic echo /imu/data --once
# 查看服务与动作
ros2 service list
ros2 action list
ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose "{pose: ...}"
# 参数操作
ros2 param list /controller
ros2 param get /controller max_speed
ros2 param set /controller max_speed 3.0
# 分布式通信
export ROS_DOMAIN_ID=42
export ROS_LOCALHOST_ONLY=0
ros2 run demo_nodes_cpp talker
三、案例场景:仿真与实车联调中的通信链路
在自动驾驶仿真中,常见链路是:仿真器发布 /scan、/imu/data、/camera/image_raw 与 /tf;感知节点订阅这些话题并输出障碍物列表;规划节点订阅障碍物与定位信息,输出局部路径;控制节点订阅路径并发布 /cmd_vel;车辆接口节点订阅 /cmd_vel,转换为 CAN 报文驱动实车。若实车不动,排查顺序应是:/cmd_vel 是否有数据、控制节点是否收到路径、规划是否收到定位、/tf 树是否完整、DDS 域是否一致。这个顺序能避免“盲目重启”。
ros2 topic hz /cmd_vel 与 ros2 topic echo /tf,再检查参数与命名空间。多数“实车不动”问题来自话题重映射错误或 use_sim_time 不一致。四、误区与复盘:常见坑位清单
| 误区 | 现象 | 正确做法 |
|---|---|---|
| 把服务当话题用 | 高频数据用服务导致阻塞 | 高频连续数据用话题,一次性操作才用服务 |
| 忽略命名空间 | 节点订阅不到话题 | 用 ros2 topic list 确认完整话题名,Launch 中统一命名空间 |
| 参数未生效 | 改了 YAML 但节点行为不变 | 确认参数文件被 Launch 加载,必要时用 ros2 param get 验证 |
| DDS 域不一致 | 跨机器看不到节点 | 统一 ROS_DOMAIN_ID,检查防火墙与组播 |
| 动作未处理取消 | 任务无法中断 | 在动作服务端实现取消回调与状态清理 |
ROS_DOMAIN_ID 相同并不代表一定能通,还需确认 DDS 实现、网络组播、防火墙与 ROS_LOCALHOST_ONLY 设置。实车联调建议先用 ros2 multicast send/receive 验证底层连通性。复盘时建议把每次联调抽象为“节点—话题—服务/动作—参数—Launch—DDS”六层检查表,并记录每层的关键命令与观测结果。这样,ROS2 基础就不再是零散命令,而是一套可复用的工程排障框架。