一、Nav2概览与调试思维
大家好，我是你们的导航算法讲师。今天咱们聊聊Nav2的整体架构和调试思路。说实话，我刚开始接触Nav2时也被它庞大的体系搞得有点懵——组件太多了，不知道从哪下手。后来踩了不少坑，才慢慢摸清门道。
这一节，我会带你快速建立Nav2的全局认知，同时分享一套实用的调试方法论。你想想看，如果连系统里有哪些零件、它们怎么配合都不知道，出了问题肯定抓瞎。
1.1 Nav2架构核心组件
Nav2本质上是一个行为树驱动的导航框架。嗯，这里要划重点——行为树是它的灵魂。我见过不少开发者把Nav2当成黑盒来用，结果一遇到异常就束手无策。
咱们先看一张整体架构图，把各个组件的关系理清楚：
这张图我画了好几次才满意。你看，BT Navigator是大脑，它根据行为树逻辑调度Planner、Controller和Recovery。说白了，就是它决定什么时候规划路径、什么时候跟踪路径、什么时候执行恢复动作。
核心组件速览：
- BT Navigator：导航行为的总调度器，加载行为树XML文件
- Planner：全局路径规划，从起点到目标点找一条可行路径
- Controller：局部路径跟踪，把全局路径转化为速度指令
- Recovery：异常恢复，卡住时尝试旋转、后退等动作
1.2 常见故障分类
调试Nav2之前，得先知道问题可能出在哪。我个人习惯把故障分成四类，这样排查起来思路清晰：
| 故障类别 | 典型表现 | 常见原因 |
|---|---|---|
| 建图问题 | 地图有重影、边界模糊 | 激光雷达标定不准、里程计漂移 |
| 定位问题 | 机器人不知道自己在哪、定位跳变 | AMCL参数不当、初始位姿不对 |
| 规划问题 | 路径绕远路、规划失败 | 代价地图膨胀半径太小、障碍物信息错误 |
| 控制问题 | 机器人抖动、过冲、撞墙 | PID参数不合适、加速度限制太松 |
我在项目中遇到过最头疼的一次，是机器人明明地图建得很好，但导航时总往墙上撞。排查了两天，最后发现是代价地图的膨胀层参数设得太小了。嗯，这种问题光看代码很难发现，得结合日志和可视化工具一起分析。
1.3 调试方法论与日志分析入门
调试Nav2，我总结了一套「三板斧」：
- 看日志：打开
ros2 run nav2_bt_navigator ... --ros-args --log-level debug，把日志级别调到debug - 看可视化：用RViz2打开
/map、/plan、/local_plan等话题 - 看行为树：用
ros2 topic echo /bt_navigator/transition_event观察行为树状态切换
调试小技巧：
我曾经在调试一个仓库AGV时，发现机器人总是在同一个位置卡住。打开行为树日志一看，原来是Backup恢复行为执行后，Planner重新规划时用了过时的代价地图。解决办法很简单——在行为树里加一个ClearCostmap节点。
日志分析这块，我建议你重点关注这几个关键词：
[BT Navigator]— 行为树执行状态[Planner]— 规划成功/失败信息[Controller]— 控制指令输出[Costmap]— 代价地图更新情况[Recovery]— 恢复行为触发记录
注意：不要一上来就调参数。我见过太多人遇到问题先改max_vel_x、acc_lim_x，结果越调越乱。正确的做法是：先确认数据流是否正常，再定位具体模块，最后才调参数。
举个例子，当机器人导航失败时，你可以这样排查：
# 1. 检查定位是否准确
ros2 topic echo /amcl_pose
# 2. 检查全局路径是否生成
ros2 topic echo /plan
# 3. 检查局部路径是否合理
ros2 topic echo /local_plan
# 4. 检查速度指令是否异常
ros2 topic echo /cmd_vel说白了，调试就是沿着数据流一路查下去。哪一步的数据不对，问题就出在哪。这个方法我用了好几年，屡试不爽。
最后说一句，Nav2的日志其实写得挺清楚的，只是很多人不习惯看。你想想看，如果连[WARN] [1723456789.123]: No valid plan found这种信息都忽略，那调试就无从谈起了。
好了，这一节的内容就到这里。记住这个架构图和调试思路，后面我们会一步步深入每个组件的细节。