2. ROS2基础与调试工具：掌握ros2 topic、ros2 service、ros2 param、ros2 node等命令行工具

说实话，很多做Nav2的朋友一上来就盯着导航算法调参，结果遇到机器人不动、话题没数据、节点挂掉这类问题，往往手足无措。我个人习惯是——先把手里的命令行工具玩熟。ROS2的命令行工具链，说白了就是你调试Nav2的“听诊器”和“手术刀”。

ROS2 CLI 调试工具链 ros2 node 节点生命周期 ros2 topic 数据流监控 ros2 service 请求/响应 ros2 param 动态参数调优 ros2 bag 数据录制回放 Nav2调试的五大核心命令行工具

2.1 ros2 node：先搞清楚谁在干活

调试Nav2的第一步，不是看代码，而是先看看节点有没有跑起来。你想想看，如果/amcl节点都没启动，那定位肯定是一团糟。

常用命令速查：

  • ros2 node list —— 列出所有活跃节点
  • ros2 node info /node_name —— 查看节点的订阅、发布、服务详情
  • ros2 node count —— 统计节点数量

我记得有一次在现场调试，机器人导航就是不走。我习惯性地先跑了个ros2 node list，发现/bt_navigator节点根本没出现。嗯，这就好办了——启动文件里少了个executable参数，补上就解决了。

我的小技巧： 每次启动Nav2后，先执行ros2 node list | grep -E "controller|planner|amcl"，快速确认核心节点是否在线。这比盯着终端日志翻页高效多了。

2.2 ros2 topic：看数据流，找问题根源

节点跑起来了，但机器人不动？这时候就要看话题数据了。Nav2里最核心的话题就那么几个：/odom、/scan、/cmd_vel、/map。

我个人排查问题的顺序是这样的：

  1. 先看输入：ros2 topic echo /scan --once，确认激光雷达有数据
  2. 再看输出：ros2 topic echo /cmd_vel，看控制器有没有发速度指令
  3. 最后看频率：ros2 topic hz /odom，里程计频率是否稳定

避坑指南： 我曾经遇到过一个问题——/cmd_vel话题有数据，但机器人就是不动。后来发现是/cmd_vel的QoS设置不匹配，发布端是RELIABLE，订阅端是BEST_EFFORT，数据根本传不过去。用ros2 topic info /cmd_vel --verbose就能看到QoS配置。

这里有个实用命令，我几乎每天都会用：

# 查看话题的发布频率，判断是否正常
ros2 topic hz /amcl_pose

# 查看话题带宽占用，排查网络瓶颈
ros2 topic bw /scan

# 查看话题的详细类型和QoS配置
ros2 topic info /map --verbose

2.3 ros2 service：触发动作，验证功能

话题是“推”模式，服务是“请求-响应”模式。在Nav2调试中，服务调用特别适合做功能验证。比如你想看看全局规划器能不能正常工作，直接调服务比跑导航快得多。

服务名称 功能说明 调试场景
/navigate_to_pose 触发导航到目标点 验证规划+控制链路
/compute_path_to_pose 仅计算全局路径 单独测试规划器
/clear_costmap 清除代价地图 解决地图卡死问题
/get_loggers 获取节点日志级别 调整调试信息输出

实战示例： 当机器人导航卡住时，我通常会先调/compute_path_to_pose服务，看看规划器能不能算出路径。如果服务返回空路径，那就是规划器的问题；如果路径正常但机器人不走，那就是控制器或执行器的问题。这一招帮我省了不少排查时间。

# 调用计算路径服务（需要先安装ros2cli扩展）
ros2 service call /compute_path_to_pose nav2_msgs/srv/ComputePathToPose "{start: {header: {frame_id: 'map'}, pose: {position: {x: 0.0, y: 0.0}, orientation: {w: 1.0}}}, goal: {header: {frame_id: 'map'}, pose: {position: {x: 2.0, y: 1.0}, orientation: {w: 1.0}}}}"

2.4 ros2 param：动态调参，不用重启

Nav2的参数多到让人头疼——规划器的、控制器的、代价地图的……如果每次改参数都要重启节点，那调试效率就太低了。ROS2的参数服务允许你在运行时动态修改参数，这个功能在调PID、调代价地图膨胀半径时特别有用。

我的调参习惯： 先用ros2 param dump /controller_server把当前参数保存下来，然后逐个修改关键参数，比如max_vel_x、min_vel_x。改完后用ros2 param set /controller_server max_vel_x 0.5实时生效。如果效果不好，直接ros2 param load /controller_server backup.yaml恢复。

# 列出所有参数
ros2 param list /controller_server

# 获取单个参数值
ros2 param get /controller_server max_vel_x

# 设置参数（立即生效）
ros2 param set /controller_server max_vel_x 0.5

# 保存所有参数到文件
ros2 param dump /controller_server --output-dir ./nav2_params

注意： 不是所有参数都支持动态修改。有些参数（比如robot_base_frame）在节点初始化时固定了，改了也不会生效。用ros2 param describe /controller_server max_vel_x可以查看参数是否可动态修改。

2.5 ros2 bag：录数据，复现问题

调试中最头疼的是什么？是问题随机出现，你盯着终端看半天它就是不重现。这时候就需要ros2 bag了。把现场数据录下来，回去慢慢分析。

我一般会录制这几个关键话题：

  • /tf 和 /tf_static —— 坐标变换
  • /odom —— 里程计数据
  • /scan —— 激光雷达数据
  • /cmd_vel —— 速度指令
  • /amcl_pose —— 定位结果
# 录制指定话题（推荐，避免数据量过大）
ros2 bag record /tf /odom /scan /cmd_vel /amcl_pose -o nav2_debug_bag

# 回放数据（可以控制速度）
ros2 bag play nav2_debug_bag --rate 0.5

# 查看bag信息
ros2 bag info nav2_debug_bag

实战经验： 有一次客户现场机器人导航偶尔会撞墙，但我在实验室复现不了。后来让客户录了一段/scan和/cmd_vel的bag发给我。回放时发现，在某个特定角度下激光雷达会出现短暂的数据丢失，导致代价地图瞬间失效。这就是典型的传感器间歇性故障，没有bag数据根本抓不到。

好了，这五个命令行工具就是你在Nav2调试中的“五虎上将”。别急着往下走，先打开终端，对着你的机器人跑一遍这些命令。你会发现，很多之前觉得玄学的问题，其实都是数据流上的小毛病。