2、自动驾驶系统概述：感知、决策、规划、控制等模块的功能划分与数据流关系

自动驾驶系统本质上是一个“感知-决策-执行”的闭环实时控制系统。要理解其软件架构，首先需要建立对整车功能逻辑的清晰认知。本章将从功能模块划分入手，剖析感知、决策、规划、控制四大核心模块的职责边界，并重点阐述它们之间通过中间件（如ROS 2、AUTOSAR Adaptive）进行数据流转的机制。理解这一层关系，是后续学习通信中间件、功能安全设计以及算力调度的基础。

上图展示了自动驾驶系统的核心数据流闭环。感知模块负责将物理世界转化为数字化的环境模型；决策规划模块基于该模型进行行为决策与轨迹生成；控制模块将轨迹转化为具体的执行指令；而车辆执行器与传感器反馈则构成了系统的闭环。中间件层（ROS 2、AUTOSAR Adaptive）贯穿始终，负责在不同计算节点间高效、可靠地传递消息，并管理服务生命周期。

2.1 感知模块：从原始数据到环境模型

核心原理

感知模块是自动驾驶的“眼睛”和“耳朵”，其核心任务是将多种异构传感器（摄像头、激光雷达、毫米波雷达、超声波、GNSS/IMU）的原始数据，通过信号处理、深度学习算法和状态估计，转化为统一、结构化、带时间戳的环境描述。该描述通常包括：动态障碍物列表（类型、位置、速度、朝向、加速度）、静态环境要素（车道线、路沿、交通标志、停止线）、可行驶区域以及自车精确位姿（位置、姿态、速度）。感知模块的输出质量直接决定了决策规划的上限。

判断方法与操作流程

在实际工程中，感知模块通常采用“多传感器融合”策略，而非单一传感器依赖。其典型处理流程如下：

1. 传感器数据预处理：对图像进行畸变校正、时间同步；对点云进行降采样、地面滤除；对毫米波雷达进行目标聚类与跟踪。
2. 目标检测与分类：基于深度神经网络（如YOLO系列、PointPillars）识别障碍物，输出2D/3D边界框及类别置信度。
3. 多传感器融合：在目标级或特征级将视觉、激光雷达、毫米波数据进行关联与融合，利用卡尔曼滤波或扩展卡尔曼滤波进行目标跟踪，输出稳定的障碍物轨迹。
4. 自车定位：融合GNSS、IMU、轮速计以及激光雷达点云与高精地图的匹配结果（NDT/ICP），输出厘米级定位精度。

案例拆解：城市路口感知融合

在某L4级Robotaxi项目中，车辆行驶至复杂十字路口，同时面临横穿行人、左转车辆、路边静止障碍物以及强逆光环境。单一摄像头在逆光下对行人检测置信度降至0.6，且距离估计误差达2米。此时，系统通过中间件（ROS 2）将摄像头检测框与激光雷达点云进行空间对齐，利用点云在图像投影区域的密度和形状特征，将行人置信度提升至0.95，并修正距离误差至0.3米。同时，毫米波雷达的多普勒速度信息为行人轨迹预测提供了关键径向速度输入。最终，感知模块输出了一份包含12个动态目标、3条车道线、1个施工区域的完整环境模型，供决策模块使用。

常见误区与复盘

• 误区一：认为传感器越多越好。实际上，冗余数据若未经过有效的融合算法，反而会增加计算负载和误报率。应基于场景需求设计传感器配置。
• 误区二：忽略感知模块的“不确定性”表达。仅输出目标位置而不输出协方差矩阵，会导致后续决策模块无法进行风险量化评估。
• 复盘要点：感知模块的评测不能仅看“检测精度”，更要关注“数据流延迟”和“输出稳定性”。在架构设计时，应预留感知结果的“降级模式”（如摄像头失效时仅依赖激光雷达）。

2.2 决策与规划模块：从意图到轨迹

核心原理

决策与规划模块是自动驾驶的“大脑”，负责解决“接下来该怎么走”的问题。它通常被细分为三个层级：全局路径规划（Route Planning）、行为决策（Behavior Decision）和运动规划（Motion Planning）。全局路径规划负责从起点到终点的宏观道路级路径搜索（如A*算法、Dijkstra算法）；行为决策负责处理交通场景中的交互博弈，决定跟车、换道、停车、让行等驾驶行为；运动规划则在行为决策的约束下，生成一条平滑、安全、满足车辆动力学约束的轨迹（包含路径点序列和速度曲线）。

判断方法与操作流程

运动规划是其中技术难度最高、与下游控制耦合最紧密的部分。其标准流程包括：

1. 环境约束构建：将感知输出的障碍物、车道线、交通规则（如红灯）转化为规划空间的代价地图（Cost Map）。
2. 轨迹搜索/采样：在Frenet坐标系下进行横向（d）与纵向（s）的采样，生成候选轨迹簇。
3. 轨迹评估与选择：基于安全性（碰撞距离）、舒适性（加速度/加加速度）、效率（通行时间）等代价函数，对候选轨迹进行评分，选出最优轨迹。
4. 轨迹平滑与下发：对选中的轨迹进行二次优化（如基于二次规划的平滑），确保曲率连续，然后以固定频率（如20Hz）发布给控制模块。

案例拆解：高速NOA自动变道决策

在高速领航辅助（NOA）场景中，自车以120km/h行驶在中间车道，前方有一辆大货车以80km/h行驶。行为决策模块首先判断跟车不经济，触发变道意图。此时，决策模块需要评估左侧车道后方来车情况。感知模块提供左后方目标车相对速度+5m/s，距离80m。决策模块通过“安全距离模型”计算：若自车以0.3g加速度变道，需要约3.5秒完成，期间纵向位移约120m。根据相对速度，目标车在3.5秒后距离自车约62.5m，大于安全阈值50m，因此决策允许变道。随后，运动规划模块生成一条平滑的S形轨迹，并下发至控制模块。整个过程从决策到轨迹下发耗时约80ms。

常见误区与总结

• 误区：将全局路径规划与运动规划混为一谈。全局规划输出的是道路级路径点（不包含速度），而运动规划输出的是车辆可执行的轨迹（包含精确的位姿、速度、加速度）。
• 误区：忽视规划模块的“实时性”与“稳定性”矛盾。规划算法必须在有限时间（通常100ms）内给出结果，且连续帧之间的轨迹不能有跳变。这要求算法具备“渐进最优”特性。
• 总结：决策规划模块是自动驾驶软件架构中“最复杂”的部分，它需要与感知、控制模块进行高频、低延迟的数据交互，对中间件的实时通信能力提出了极高要求。

2.3 控制模块：从轨迹到执行指令

核心原理

控制模块是自动驾驶的“手脚”，其核心任务是让车辆精确地跟踪运动规划模块生成的轨迹。它通常分为横向控制（控制方向盘转角）和纵向控制（控制油门/制动）。经典算法包括PID控制、纯跟踪（Pure Pursuit）、模型预测控制（MPC）以及线性二次调节器（LQR）。其中，MPC因其能够显式处理车辆动力学约束和多目标优化，在L4级系统中应用最广。

判断方法与操作流程

控制模块的输入是目标轨迹（包含参考路径和参考速度），输出是具体的执行器指令。其工作流程如下：

1. 状态反馈获取：通过中间件获取车辆当前的实际状态（车速、横摆角速度、纵向加速度、方向盘转角）。
2. 误差计算：计算车辆当前位置与目标轨迹之间的横向偏差（lateral error）、航向偏差（heading error）以及速度偏差。
3. 控制律解算：根据控制算法（如MPC）计算前轮转角控制量和纵向加速度/减速度请求。
4. 指令转换与下发：将控制量转换为底盘CAN总线可执行的指令（如转向扭矩、制动主缸压力、驱动扭矩百分比），并通过AUTOSAR Adaptive或ROS 2的CAN接口下发。

案例拆解：泊车场景下的低速精确控制

在自动泊车场景中，车辆需要以不超过5km/h的速度在狭小空间内反复前进/后退。由于车速极低，轮胎侧偏特性不明显，且存在较大的转向系统摩擦。此时，若采用高速场景下的动力学模型（如自行车模型），控制误差会显著增大。工程上，通常采用“运动学模型+前馈补偿”的方式。控制模块首先通过轮速传感器和IMU融合获得精确的车辆位姿（精度±2cm），然后利用纯跟踪算法生成前轮转角指令，同时叠加一个基于转向阻力矩估算的前馈补偿值。通过中间件将控制频率提升至100Hz，最终实现了±5cm的泊车精度。

常见误区与复盘

• 误区一：忽视执行器延迟。转向系统、制动系统均存在固有延迟（通常100-300ms）。控制算法必须考虑该延迟，否则会导致系统振荡。解决方案是引入“Smith预估器”或采用“预测控制”。
• 误区二：控制模块与规划模块的接口定义不清晰。例如，规划模块下发的轨迹点间隔（如0.5m）与控制模块的控制周期（如20ms）不匹配，导致控制输入不平滑。应在中间件层定义标准轨迹消息格式（如autoware_auto_msgs/Trajectory）。
• 复盘：控制模块的标定工作（如转向比、制动踏板特性）是软件架构中不可忽视的一环。标定数据应作为参数文件管理，并通过中间件配置服务动态加载。

2.4 模块间数据流与中间件的角色

核心原理

上述四大模块并非孤立运行，而是通过中间件构成一个紧密耦合的实时数据流网络。中间件（ROS 2、AUTOSAR Adaptive）在此扮演了“数据总线”和“服务框架”的双重角色。它定义了消息传递的规范（如DDS、SOME-IP），管理了节点间的通信拓扑（发布/订阅、服务/客户端），并提供了服务质量（QoS）策略（如Best Effort、Reliable）来平衡延迟与可靠性。

判断方法与操作流程

在设计模块间数据流时，需遵循以下原则：

1. 明确数据所有权：每个消息只能有一个“生产者”（Writer），避免多写冲突。
2. 定义清晰的接口规范：使用IDL（接口描述语言）定义消息结构，确保跨语言、跨平台兼容。
3. 配置合理的QoS：对于控制指令等关键数据，应使用“Reliable”策略并设置超时检测；对于感知图像等大数据，可使用“Best Effort”策略以降低延迟。
4. 实施监控与诊断：中间件应提供数据流监控工具（如ROS 2的topic hz、topic delay），用于实时查看各链路频率和延迟。

案例拆解：中间件故障对数据流的影响

在某测试车辆上，工程师通过ROS 2的rqt_graph工具发现“规划→控制”的轨迹话题订阅频率从20Hz骤降至2Hz。初步排查发现，控制模块的CPU占用率过高，导致其处理线程被阻塞。进一步分析发现，控制模块订阅了过多的感知可视化话题（如点云、图像），这些高频大数据消息占用了大量网络带宽和CPU资源。解决方案是：在中间件层为控制模块设置独立的DDS域（Domain），仅允许其订阅必要的轨迹和车辆状态话题，将可视化数据隔离在另一个域中。调整后，控制频率恢复至20Hz，端到端延迟降低40%。

常见误区与总结

• 误区：认为中间件只是简单的“消息转发”。实际上，中间件的QoS配置、网络拓扑、序列化方式（如CDR、Protobuf）直接影响系统实时性。
• 误区：忽视数据流中的“背压”问题。当消费者处理速度慢于生产者时，会导致消息积压和延迟增加。应使用有界队列和丢弃策略（如Drop Oldest）来保护实时性。
• 总结：自动驾驶软件架构的本质是“数据流架构”。理解各模块的数据需求、时序约束和容错要求，是设计高效、可靠中间件通信方案的前提。本章所阐述的模块划分与数据流关系，为后续深入学习ROS 2的通信机制、AUTOSAR Adaptive的服务模型以及系统级的时间同步与功能安全设计奠定了坚实的系统认知基础。