课程导入：学习目标、课程结构、Autoware整体架构与规划控制模块的定位

欢迎进入《Autoware自动驾驶规划控制模块》课程。规划控制模块是自动驾驶系统中承上启下的核心枢纽——它接收来自感知与定位模块的环境理解结果，结合高精地图与全局路径，在满足车辆动力学约束、交通规则和乘员舒适性的前提下，实时生成安全、平滑、可执行的局部轨迹，并输出底层控制指令。本课程将围绕Autoware开源框架，系统拆解规划控制模块的设计思想、核心算法、工程实现与调优方法。本节作为课程导入，首先明确学习目标与课程结构，随后从宏观视角剖析Autoware的整体架构，并精确定位规划控制模块在其中的职责边界与数据交互关系。

1.1 学习目标与课程结构设计

核心原理：从“能跑”到“跑得好”的能力进阶

规划控制模块的工程实践需要开发者同时具备算法理解能力、系统集成能力和问题排查能力。本课程的学习目标并非仅仅停留在“会调用Autoware接口”的层面，而是要求学员能够深入理解每个子模块的算法原理、参数含义和调优方向。具体而言，完成本课程后，学员应能够：第一，清晰描述Autoware规划控制模块的整体数据流和模块间依赖关系；第二，独立完成从高精地图加载、全局路径规划到局部轨迹生成的全流程配置；第三，针对典型场景（如十字路口左转、匝道汇入、行人横穿）进行行为规划参数调整；第四，运用诊断工具分析轨迹不平滑、控制震荡等常见问题，并给出合理的解决方案。

课程结构按照“架构认知 → 算法原理 → 工程实践 → 综合实战”四个层次递进展开，共30个章节。前5章聚焦于Autoware整体框架、ROS 2通信机制、规划控制模块的输入输出接口以及开发环境搭建。第6至15章深入全局规划、行为规划、运动规划三大核心算法，涵盖A*、Hybrid A*、Frenet坐标系、MPC（模型预测控制）等关键方法。第16至25章转向工程实践，包括参数调优、仿真验证、实车部署、故障诊断与性能优化。最后5章通过综合项目实战，将所学知识串联应用于高速公路巡航、城区复杂路口通行、自动泊车等真实场景。

判断方法：如何评估自己对规划控制模块的掌握程度

学员可以通过以下三个维度进行自测：概念清晰度——能否不借助资料准确说出全局规划与局部规划的区别、Frenet坐标系与笛卡尔坐标系的转换关系、MPC中预测时域与控制时域的含义；操作熟练度——能否在30分钟内完成Autoware环境启动、加载地图、设置目标点并让车辆在仿真器中完成一次点到点行驶；问题定位能力——当车辆在仿真中出现“轨迹抖动”或“刹车过猛”时，能否快速判断是规划参数问题、控制参数问题还是感知数据延迟问题。建议学员在每章学习后，用上述三个维度进行自我评分，形成能力成长曲线。

案例拆解：从零开始构建一个最小规划控制闭环

为帮助学员建立直观认知，我们以一个“最小闭环”案例说明规划控制模块在Autoware中的实际运行方式。假设我们使用Autoware Universe版本（基于ROS 2 Humble），在仿真环境AWSIM中运行。初始条件：车辆停靠在某城市道路的起始位置，目标点设置在2公里外的十字路口。操作流程如下：

1. 启动Autoware Launch文件，加载高精地图（Lanelet2格式）和车辆模型参数。
2. 通过Rviz指定目标点，全局规划模块（lane_planner）基于车道级拓扑图搜索出一条全局路径。
3. 车辆开始行驶后，行为规划模块（behavior_planner）根据感知信息判断当前车道是否畅通，决定跟车、变道或停车。
4. 运动规划模块（motion_planner）在Frenet坐标系下生成平滑的局部轨迹，包含位置、速度、加速度曲线。
5. 控制模块（controller）采用MPC算法，将轨迹转化为方向盘转角、油门和刹车指令，通过CAN总线发送至仿真车辆。

在此过程中，学员可以观察到规划控制模块的输入话题包括/perception/object_recognition/objects、/localization/kinematic_state、/map/vector_map，输出话题包括/planning/scenario_planning/trajectory和/control/command/control_cmd。通过rqt_graph可以清晰看到数据从感知到规划再到控制的单向流动，以及控制模块反馈给规划模块的车辆状态信息。

常见误区与总结复盘

初学者最容易陷入的误区包括：误区一，将全局规划与局部规划混为一谈，认为只要设置好目标点车辆就能自动避障——实际上全局规划只负责静态路径搜索，动态避障完全依赖局部规划模块；误区二，忽视坐标变换的重要性，在调试时混淆了map、odom、base_link坐标系，导致轨迹偏移却找不到原因；误区三，盲目调整PID参数而不理解控制模块内部的MPC与PID混合架构，导致车辆出现震荡却无从下手。本课程将在后续章节中逐一针对这些误区进行深入剖析。

1.2 Autoware整体架构与模块间数据交互

核心原理：分层解耦的软件架构

Autoware采用分层解耦的软件架构，从上到下依次为：应用层（包括场景界面、远程监控）、功能层（感知、定位、规划、控制、地图）、中间件层（ROS 2通信框架、TF坐标变换、生命周期管理）、硬件抽象层（传感器驱动、车辆接口）。这种分层设计的核心优势在于：各模块可以独立开发、独立测试、独立替换。例如，当我们需要将感知模块从LiDAR方案替换为纯视觉方案时，只要保证输出话题的格式不变，规划控制模块无需任何修改即可继续工作。

在功能层内部，规划控制模块又细分为四个子模块：全局规划（Route Planning）负责在车道级拓扑图上搜索从起点到终点的宏观路径；行为规划（Behavior Planning）负责根据当前交通场景做出驾驶决策，如跟车、停车、变道、绕行；运动规划（Motion Planning）负责生成满足车辆动力学约束的平滑轨迹；控制（Control）负责将目标轨迹转化为底盘可执行的油门、刹车、转向指令。这四个子模块在Autoware中分别对应不同的ROS 2节点包，通过话题和服务进行通信。

判断方法：通过数据流图理解模块边界

在实际调试中，学员应养成“先看数据流，再查代码”的习惯。当车辆行为异常时，首先使用ros2 topic echo检查关键话题是否有数据、数据频率是否正常、数据内容是否合理。例如，如果车辆无法启动，应依次检查：/localization/kinematic_state是否有位姿输出（定位是否正常）、/planning/scenario_planning/trajectory是否有轨迹发布（规划是否正常）、/control/command/control_cmd是否有控制指令（控制是否正常）。通过这种“逐级排查”的方法，可以快速定位故障模块。

案例拆解：一次典型的十字路口左转场景

我们以十字路口左转为例，详细展示规划控制模块各子模块的协同工作过程。场景描述：自车以40km/h速度接近十字路口，交通灯为绿灯，对向有直行车辆，左侧有行人正在通过人行横道。全局规划模块输出的路径显示需要在前方路口左转。行为规划模块接收到感知信息后，经过状态机判断，决定执行“减速停车等待行人通过，然后左转”的行为。具体决策过程如下：

• 场景识别：行为规划模块根据地图数据和感知结果，识别出当前处于“十字路口”场景，并检测到行人占用冲突区域。
• 状态转移：状态机从“跟随车道”切换到“停止”，生成停车目标点。
• 轨迹生成：运动规划模块在Frenet坐标系下生成一条平滑减速至零的轨迹，同时考虑车辆与行人的安全距离。
• 控制执行：MPC控制器跟踪该轨迹，输出刹车指令，车辆平稳停止。
• 恢复行驶：行人通过后，行为规划模块切换到“左转”状态，运动规划模块生成一条曲率连续的左转轨迹，控制模块驱动车辆完成转向。

在整个过程中，规划控制模块需要实时处理感知数据的延迟（通常100ms左右）、定位数据的噪声（厘米级误差）以及车辆执行机构的响应延迟（转向系统约200ms）。这些工程约束在算法设计中必须被充分考虑，例如运动规划中的轨迹生成需要预留安全余量，控制算法需要具备鲁棒性以应对模型失配。

常见误区与总结复盘

在理解Autoware整体架构时，学员常犯的错误包括：误区一，认为规划控制模块是一个独立的“黑盒”，忽略了它与感知、定位模块之间的强耦合关系——实际上，感知延迟、定位漂移都会直接影响规划控制的效果；误区二，混淆了“场景规划”（Scenario Planning）与“运动规划”（Motion Planning）的层次关系——场景规划负责决策“做什么”，运动规划负责决定“怎么做”；误区三，忽视车辆接口层的重要性——规划控制算法最终需要通过CAN总线与线控底盘交互，不同车型的接口协议差异巨大，这在实车部署时是最大的工程挑战之一。