一、Autoware整体架构概览
各位同学好，我是老张。今天咱们聊聊Autoware的整体架构。
说实话，我第一次接触Autoware时，也被它的模块数量吓了一跳。但别慌，搞清楚了它的设计逻辑，你会发现其实挺清晰的。
1.1 Autoware的模块组成
Autoware的核心模块，我习惯把它分成三大块：
- 感知层：负责“看”和“听”。包括激光雷达点云处理、摄像头图像识别、毫米波雷达目标检测等。
- 决策规划层：负责“想”。包括全局路径规划、行为决策、运动规划。
- 控制层：负责“做”。把规划好的轨迹，变成方向盘、油门、刹车的具体指令。
嗯，这里要注意，Autoware还有一个定位模块，它其实贯穿了感知和规划。我个人习惯把它单独拎出来，因为它太重要了。
核心要点：Autoware的模块划分，本质上是“感知-决策-控制”的经典机器人架构。你想想看，人类开车不也是这个流程吗？
下面这张图，是我自己画的Autoware模块关系图。你看一眼就明白了。
1.2 控制模块在Autoware中的位置
控制模块，说白了就是整个系统的“最后一公里”。
感知模块告诉你前面有车，规划模块告诉你怎么绕过去，但最终能不能安全绕过去，全靠控制模块的执行力。
我在项目中遇到过这样一个情况：规划模块算出了一条非常完美的避障轨迹，但控制模块响应慢了200毫秒，结果车还是蹭上了路沿。嗯，这就是控制模块的重要性。
个人经验：控制模块是Autoware里最“硬”的模块。它直接和车辆硬件打交道，任何延迟或抖动，都会真实地反映在车辆运动上。我建议你在调试时，优先保证控制模块的稳定。
1.3 控制模块与上下游模块的关系
控制模块不是孤岛。它和上下游模块的关系，我总结成一句话：上游给目标，下游给反馈，中间做决策。
| 模块关系 | 输入/输出 | 数据内容 | 典型频率 |
|---|---|---|---|
| 规划模块 → 控制模块 | 输入 | 轨迹点序列（x, y, yaw, v, a） | 10-50 Hz |
| 定位模块 → 控制模块 | 输入 | 当前位姿（x, y, yaw, v） | 50-100 Hz |
| 控制模块 → 车辆底盘 | 输出 | 油门百分比、刹车百分比、转向角 | 50-100 Hz |
| 车辆底盘 → 控制模块 | 反馈 | 实际车速、实际转向角 | 50-100 Hz |
这里有个坑，我必须要提醒你。
避坑指南：我曾经遇到过规划模块和控制模块的频率不匹配。规划模块只发10Hz的轨迹，但控制模块需要50Hz的指令。结果车辆在转弯时一顿一顿的，像在跳机械舞。
解决方案：控制模块内部必须做轨迹插值。把10Hz的轨迹点，插值成50Hz的连续轨迹。否则你的车永远开不平顺。
为什么会这样？你想想看，规划模块算的是宏观路径，它不需要那么高的频率。但控制模块要实时响应车辆动态，频率低了根本控不住。
嗯，这里还有一个细节。控制模块和定位模块之间，其实存在一个隐式依赖。控制模块需要知道车辆当前到底在哪里、跑多快，才能决定下一步怎么控。如果定位模块延迟大，控制模块就会“开盲车”。
我个人习惯的做法是：在控制模块里加一个状态估计器，用车辆底盘的里程计数据做辅助定位。这样即使定位模块偶尔掉帧，控制模块也能撑几秒钟。
小结
今天咱们把Autoware的整体架构捋了一遍。记住三个关键点：
- Autoware是“感知-决策-控制”三层架构
- 控制模块是执行层，直接和车辆硬件打交道
- 控制模块需要处理好上下游的频率匹配和延迟问题
下一章，咱们会深入控制模块内部，看看MPC和PID到底是怎么工作的。