3. Autoware规划控制模块总览：规划与控制的功能划分、数据流及核心模块
Autoware作为开源自动驾驶软件栈的标杆，其规划控制（Planning & Control）模块承担着将感知结果转化为车辆实际运动的核心职责。在实车部署中，规划控制模块的稳定性与实时性直接决定了车辆行驶的安全性与舒适性。本章将从功能划分、数据流、核心模块及接口定义四个维度，系统梳理Autoware规划控制模块的整体架构，帮助开发者建立从感知输入到控制输出的完整链路认知。
3.1 规划与控制的功能边界划分
在Autoware的模块化架构中，规划（Planning）与控制（Control）虽然紧密协作，但职责边界清晰。规划模块负责"决定做什么"——基于感知、定位、地图信息，生成一条从当前时刻到未来若干秒内安全、可行、舒适的行驶轨迹；控制模块则负责"如何执行"——将规划输出的目标轨迹转化为具体的油门、刹车、转向指令，并克服车辆动力学、路面摩擦等不确定性因素，使实际行驶轨迹尽可能贴合规划轨迹。
从时间尺度上看，规划模块的运行频率通常为10~30Hz，规划时域（Trajectory Horizon）一般为5~10秒；而控制模块的运行频率更高，通常为50~100Hz，以满足车辆底层执行机构的响应需求。这种频率差异决定了两个模块在算法选型和资源消耗上的不同侧重：规划更关注全局最优与场景理解，控制更关注实时跟踪精度与鲁棒性。
| 对比维度 | 规划模块 (Planning) | 控制模块 (Control) |
|---|---|---|
| 核心任务 | 行为决策 + 轨迹生成 | 轨迹跟踪 + 执行指令输出 |
| 输入数据 | 感知目标、地图、定位、预测 | 规划轨迹、车辆状态反馈 |
| 输出数据 | 轨迹点序列 (x, y, v, a, yaw) | 转向角、油门/刹车百分比 |
| 运行频率 | 10~30 Hz | 50~100 Hz |
| 算法特点 | 搜索、优化、状态机、场景识别 | PID、MPC、前馈+反馈 |
| 失效影响 | 无轨迹输出 → 车辆停车 | 指令异常 → 车辆失控 |
3.2 数据流全景：从感知到执行的完整链路
Autoware规划控制模块的数据流遵循"感知→规划→控制→执行→反馈"的单向主链路，同时存在多条反馈回路。理解这条数据流是进行模块开发与调试的基础。
3.2.1 主数据链路
- 感知输出：感知模块通过Topic发布动态目标列表（/perception/object_recognition/objects）、占用栅格（/perception/occupancy_grid_map）以及交通灯状态（/perception/traffic_light_recognition/traffic_light_state）。这些消息以10~20Hz的频率发布，包含目标的类别、位置、速度、朝向及置信度。
- 规划输入：Behavior Planner订阅感知目标、地图数据（/map/vector_map）以及当前车辆状态（/localization/kinematic_state），经过场景识别与行为决策后，输出行为状态（如"跟随车道"、"变道"、"停车等待"）。
- 轨迹生成：Motion Planner接收行为状态与感知目标，结合路径规划与速度规划算法，生成未来5~10秒的轨迹点序列，发布到/planning/trajectory。每个轨迹点包含位置（x, y）、航向角（yaw）、期望速度（v）、期望加速度（a）及时间戳。
- 控制执行：Controller订阅轨迹与车辆状态反馈（/vehicle/status），通过横向控制算法（如Pure Pursuit、MPC）计算前轮转角，通过纵向控制算法（如PID）计算油门/刹车值，最终发布到/control/command。
3.2.2 反馈回路
除了主链路外，还存在两条关键反馈回路：一是车辆状态反馈回路，Controller通过IMU、轮速计、GNSS获取实际速度与横摆角速度，用于闭环修正；二是规划-控制协调回路，当Controller检测到跟踪误差过大或执行饱和时，会通过/planning/coordination话题通知规划模块降低期望速度或重新规划。
# 查看规划控制相关Topic（ROS2 CLI示例）
ros2 topic list | grep -E "planning|control|perception"
# 典型输出：
# /perception/object_recognition/objects
# /planning/trajectory
# /planning/behavior_state
# /control/command
# /vehicle/status3.3 核心模块深度解析
3.3.1 Behavior Planner（行为规划器）
Behavior Planner是规划模块的"大脑"，负责理解当前驾驶场景并做出高层决策。它基于有限状态机（FSM）或场景管理器（Scenario Manager）实现，典型状态包括：车道保持（Lane Driving）、变道（Lane Change）、交叉口通行（Intersection）、靠边停车（Pull Over）等。
在Autoware中，Behavior Planner的核心输入包括：
- 感知目标列表（动态障碍物）
- 矢量地图（车道线、停止线、限速标志）
- 当前车辆状态（位置、速度、航向）
- 路由信息（来自全局规划模块的路线）
其输出为行为状态（Behavior State）与场景标签（Scenario），这些信息通过/planning/behavior_state和/planning/scenario话题发布，供Motion Planner及上层监控使用。
3.3.2 Motion Planner（运动规划器）
Motion Planner负责将行为决策转化为具体的、满足车辆运动学约束的轨迹。它通常包含两个子模块：路径规划（Path Planning）与速度规划（Velocity Planning）。路径规划在Frenet坐标系下进行，生成一条避开障碍物的几何路径；速度规划则基于路径曲率、限速、障碍物距离等因素，生成平滑的速度曲线。
Autoware中Motion Planner的典型输出为Trajectory消息，其定义如下：
# Trajectory.msg (简化)
std_msgs/Header header
TrajectoryPoint[] points
# TrajectoryPoint.msg
geometry_msgs/Pose pose # 位置与朝向
float64 velocity # 期望速度 (m/s)
float64 acceleration # 期望加速度 (m/s²)
float64 heading_rate # 航向角变化率 (rad/s)
builtin_interfaces/Duration time_from_start # 相对时间戳3.3.3 Controller（控制器）
Controller是规划与控制链路的最后一环，直接与车辆底盘交互。Autoware提供了多种控制算法实现，包括：
- Pure Pursuit：基于几何追踪的横向控制算法，简单可靠，适合低速场景。
- MPC（模型预测控制）：基于车辆动力学模型的优化控制，可同时处理横向与纵向约束，适合高速场景。
- PID + 前馈：常用于纵向速度控制，配合前馈项提高响应速度。
Controller的输出为AckermannControlCommand或RawControlCommand，包含转向角（steering_angle）、油门（throttle）与刹车（brake）值。这些指令通过CAN或Ethernet发送至车辆执行器。
| 模块 | 输入Topic | 输出Topic | 关键参数 |
|---|---|---|---|
| Behavior Planner | /perception/objects, /map/vector_map, /localization/kinematic_state | /planning/behavior_state, /planning/scenario | 状态机配置、场景切换阈值 |
| Motion Planner | /planning/behavior_state, /perception/objects, /planning/route | /planning/trajectory | 规划时域、采样分辨率、优化权重 |
| Controller | /planning/trajectory, /vehicle/status | /control/command | PID增益、MPC预测时域、执行频率 |
3.4 实战案例：规划控制链路联调与排障
下面通过一个典型的实车调试案例，展示规划控制模块的联调流程与常见问题排查方法。
3.4.1 案例背景与现象
某团队在园区低速自动驾驶车辆上部署Autoware，车辆在直线行驶时表现正常，但在进入弯道时出现明显的"切弯"现象——车辆轨迹偏向弯道内侧，且方向盘出现小幅振荡。通过录制ROS2 Bag包分析，发现规划轨迹正常，但控制模块输出的转向角存在约0.3秒的延迟。
3.4.2 分析过程
- 数据回放：使用
ros2 bag play回放数据，对比/planning/trajectory与/control/command的时间戳，发现控制指令滞后于轨迹约300ms。 - 链路排查：检查Controller节点处理耗时，发现MPC求解器平均耗时约80ms，但话题传输与回调队列存在积压。
- 参数检查：查看Controller的QoS设置，发现订阅轨迹时使用了Reliable策略，导致网络波动时消息重传，增加了延迟。
3.4.3 解决方案
- 将Controller订阅轨迹的QoS策略改为Best Effort，降低传输延迟。
- 优化MPC求解器配置，将预测时域从2.0s缩短至1.5s，求解频率从20Hz提升至30Hz。
- 在Controller中增加前馈项，基于轨迹曲率预补偿转向角，减小跟踪误差。
3.4.4 结果与复盘
优化后，控制延迟降低至约100ms，弯道跟踪误差从0.35m减小至0.12m，方向盘振荡消失。复盘经验：规划控制联调中，时间同步与QoS策略是容易被忽视但影响显著的因素；此外，MPC等优化算法需要根据实际硬件算力进行参数调优，不能直接使用默认配置。
ros2 topic hz和ros2 topic delay命令定期检查各关键Topic的频率与延迟，建立系统健康度基线。当车辆行为异常时，优先检查数据链路而非算法逻辑。
3.5 接口定义与开发注意事项
Autoware规划控制模块的接口设计遵循ROS2的Topic/Service/Action模式。开发者需要重点关注以下接口约定：
- 轨迹消息：Trajectory消息中的时间戳必须单调递增，且第一个点的时间偏移应为0，表示当前时刻。
- 控制指令：ControlCommand中的油门与刹车值范围通常为0~1，且两者不能同时非零。
- 状态反馈：车辆状态消息应包含速度、前轮转角、横摆角速度等，且频率不低于控制频率。
在开发过程中，建议使用ros2 interface show命令查看消息定义，并通过rqt_graph可视化节点连接关系，确保数据流正确。