一、Autoware规划调试入门：从整体架构到核心挑战
大家好，我是你们这趟Autoware调试之旅的向导。说实话，我刚开始接触Autoware的时候，也被它庞大的代码库吓了一跳。但别担心，咱们一步步来，先把这头「大象」的骨架摸清楚。
1.1 Autoware整体架构概览
Autoware，说白了，就是一套开源的自动驾驶软件栈。它把一辆普通车变成能自己跑的车，靠的是几个核心模块的协同工作。我个人习惯把它的架构分成三层：感知层、规划层、控制层。
- 感知层：负责「看」和「认」。激光雷达、摄像头、毫米波雷达的数据进来，它告诉你前面是车、是行人、还是路沿。
- 规划层：负责「想」和「定」。知道周围有什么之后，它来决定下一步怎么走——是直行、转弯、还是停车。
- 控制层：负责「做」。规划层给出指令，控制层去踩油门、打方向盘、踩刹车。
嗯，这里要注意，规划层是连接感知和控制的「大脑」。如果规划层出了问题，车要么乱走，要么不动。
核心观点：Autoware的规划模块，是整个系统的决策中枢。调试规划模块，本质上是在调试「车该怎么开」这个核心问题。
下面这张图，是我自己画的Autoware规划模块的简化流程。你看，数据从感知进来，经过层层处理，最后变成控制指令。
1.2 规划模块在自动驾驶中的角色
规划模块到底有多重要？我举个例子。有一次我在测试一个园区场景，感知模块明明检测到了前面的锥桶，但规划模块就是没反应，车直接撞上去了。排查了半天，发现是规划模块的「障碍物过滤」参数设得太宽松了。
规划模块的角色，可以拆成三个层次：
- 全局路径规划：从A点到B点，走哪条路？这就像你用高德地图导航，先定个大方向。
- 行为规划：在某个路段，该做什么动作？比如「前方路口右转」、「当前车道跟车」、「遇到红灯停车」。
- 运动规划：具体怎么执行这个动作？方向盘打多少度？油门踩多深？轨迹要平滑，不能吓到乘客。
我的经验：调试时，我习惯先看行为规划的输出。如果行为决策错了，运动规划再完美也没用。就像你决定要撞墙，刹车踩得再稳也是白搭。
1.3 规划调试的核心目标与挑战
规划调试，说白了就是让车「开得对、开得稳、开得安全」。但说起来容易，做起来坑不少。
核心目标
- 正确性：规划结果必须符合交通规则和场景语义。红灯不停？不行。实线变道？不行。
- 平滑性：轨迹不能有急转弯或急加减速。乘客晕车了，这系统就失败了。
- 实时性：规划周期通常要求100ms以内。你想想看，如果车都开到路口了，规划还没算完，那后果...
- 鲁棒性：传感器有噪声、定位有漂移，规划模块得扛得住这些干扰。
主要挑战
我在项目中遇到过不少头疼的问题，这里列几个典型的：
| 挑战 | 具体表现 | 调试难度 |
|---|---|---|
| 参数敏感 | 一个权重参数调不好，轨迹就飘了 | ⭐⭐⭐ |
| 场景覆盖不全 | 测试时好好的，上路就出问题 | ⭐⭐⭐⭐⭐ |
| 模块间耦合 | 感知延迟导致规划误判 | ⭐⭐⭐⭐ |
| 实时性瓶颈 | 复杂场景计算超时 | ⭐⭐⭐ |
避坑指南：我曾经花了一周时间调一个轨迹跟踪的PID参数，结果发现是上游定位模块的时间戳没对齐。所以，调试规划问题时，先检查数据流，别一上来就改参数。
1.4 调试工具与基本方法
工欲善其事，必先利其器。Autoware规划调试，我常用的工具就这几样：
- rviz2：可视化调试利器。路径、轨迹、障碍物，一目了然。
- ros2 bag：录数据、回放数据。现场复现问题全靠它。
- rqt_graph：看节点间的数据流。哪个节点断了，一眼就能发现。
- logging：在代码里加打印，输出关键变量的值。老办法，但管用。
举个例子，当你发现车在某个路口不走直线时，可以这样调试：
# 1. 录下现场数据
ros2 bag record -a -o problem_scenario
# 2. 回放数据
ros2 bag play problem_scenario
# 3. 在rviz2中查看规划轨迹
ros2 run rviz2 rviz2 -d autoware.rviz
# 4. 检查规划模块的输出topic
ros2 topic echo /planning/scenario_planning/trajectory嗯，这里要注意，录数据时尽量多录几秒，把问题发生前后的上下文都抓下来。我刚开始调试时，经常只录了问题发生的那一瞬间，结果回放时根本看不出前因后果。
调试心法：先确认「输入对不对」，再检查「处理逻辑对不对」，最后看「输出对不对」。这个顺序，能帮你省下一半的排查时间。
好了，这一章我们聊了Autoware的整体架构、规划模块的角色，以及调试的核心目标和挑战。说白了，规划调试就是一场和「不确定性」的博弈。下一章，我们会深入规划模块的内部，看看那些代码到底在干什么。