2. 自动驾驶系统基础

自动驾驶系统是一个典型的“端-云”协同计算系统。理解其基础架构，首先需要厘清车端（车载计算平台）上三大核心模块——感知、决策、控制——各自的职责边界与数据流转逻辑，同时明确哪些计算必须在毫秒级内于车端完成，哪些任务可以卸载到云端进行非实时或准实时的处理。本章将围绕这一核心命题，构建一个从物理世界到执行器动作的完整数据闭环视图，并深入剖析车端与云端在数据流中的分工边界。

上图展示了自动驾驶系统车端与云端协同工作的完整数据流拓扑。车端负责实时性要求极高的闭环控制，云端则承担数据汇聚、模型迭代与全局优化。下面我们将逐一拆解各模块的核心原理、数据接口与工程实现要点。

2.1 感知模块：从物理信号到语义理解

核心原理

感知模块是自动驾驶系统的“眼睛”和“耳朵”，其任务是将传感器采集的物理信号（光强、反射波、电磁波）转换为结构化、语义化的环境模型。典型的感知子任务包括：

• 目标检测与分类：识别车辆、行人、骑行者、障碍物等动态目标，输出其2D/3D边界框、类别与置信度。
• 语义分割：对图像或点云进行像素级/点级分类，区分可行驶区域、车道线、路沿、交通标志等静态元素。
• 多目标跟踪（MOT）：在时间序列上关联检测结果，维持目标的ID一致性，估计其速度与加速度。
• 轨迹预测：基于目标历史运动状态与交互上下文，预测未来3-5秒的候选轨迹及其概率分布。

在工程实现上，现代感知系统普遍采用“多传感器融合”策略。摄像头提供丰富的纹理与颜色信息，激光雷达提供精确的深度与几何信息，毫米波雷达则在恶劣天气下提供鲁棒的速度测量。融合可以在数据级（早期融合）、特征级（中期融合）或目标级（后期融合）进行，各有优劣。

判断方法与关键指标

评估感知模块性能不能只看单一指标，需要综合考量以下维度：

案例拆解：夜间城市道路的感知挑战

某L4级自动驾驶项目在夜间城市道路测试中发现，感知系统对远处（>80m）横穿马路的行人漏检率高达12%。通过分析数据日志发现：

1. 现象：摄像头在低照度下ISO过高导致噪点增加，2D检测器置信度下降；激光雷达点云在远距离处过于稀疏，难以形成有效聚类。
2. 分析：融合策略采用“摄像头优先”的后期融合，当摄像头置信度低于0.5时直接丢弃该目标，而毫米波雷达虽然检测到了微弱回波，但未被纳入融合逻辑。
3. 优化：将融合策略改为“概率栅格融合”，将毫米波雷达的检测结果作为先验，在图像对应区域放大ROI重新推理；同时引入红外摄像头补充夜间视觉。
4. 结果：漏检率从12%降至2.3%，但GPU负载增加了18%。通过模型剪枝与TensorRT INT8量化，最终将延迟控制在95ms以内。

2.2 决策规划模块：从环境理解到行为生成

核心原理

决策规划模块是自动驾驶的“大脑”，负责根据感知结果、高精地图、车辆状态与交通规则，生成安全、舒适、高效的行驶轨迹。其内部通常分为三个层级：

• 任务决策（Route Planning）：全局路径规划，从起点到终点的道路级导航，通常由云端或车端导航引擎完成，频率较低（1Hz）。
• 行为决策（Behavior Decision）：处理交互场景，如跟车、变道、超车、让行、通过路口等。输出离散的行为指令，频率约10Hz。
• 运动规划（Motion Planning）：在行为指令约束下，生成平滑、无碰撞的轨迹曲线（路径+速度），频率约20-50Hz。

运动规划的核心挑战在于“时空联合优化”。不仅要规划一条几何路径，还要为路径上的每个点分配速度与加速度，确保在动态环境中满足安全距离、舒适度（加加速度限制）与动力学约束。

操作流程与算法选型

一个典型的运动规划流程如下：

1. 环境栅格化：将感知输出的障碍物、车道线等投影到Frenet坐标系（以道路中心线为参考）。
2. 候选轨迹生成：采用“采样+优化”或“路径-速度解耦”方法生成候选轨迹集合。常用方法包括：Lattice Planner、EM Planner、多项式曲线拟合。
3. 代价评估：对每条候选轨迹计算综合代价，包括：碰撞风险、偏离参考线距离、加速度变化率、车道保持倾向等。
4. 轨迹选择与平滑：选择代价最低的轨迹，并通过二次规划或样条插值进一步平滑。

# 横向偏移采样范围
d_lat = [-3.0, -1.5, 0.0, 1.5, 3.0]  # 单位：米
# 纵向速度采样范围
v_long = [5.0, 8.0, 10.0, 12.0]      # 单位：m/s
# 时间窗口
T = [2.0, 3.0, 4.0, 5.0]             # 单位：秒
# 代价权重
w_collision = 100.0
w_jerk = 1.5
w_lat_offset = 0.8

实战场景：城市路口无保护左转

无保护左转是决策规划模块最具挑战性的场景之一。车辆需要在没有专用左转信号灯的情况下，穿越对向直行车流。工程实现中需要：

• 博弈建模：不能简单假设对向车辆会减速让行，需要基于其速度、加速度与历史行为预测其意图。
• 安全边界：定义“动态安全距离”，即对向车辆以当前速度行驶，我方完成左转所需的最小时间窗口。
• 决策树：当时间窗口大于阈值（如4.5秒）时，启动左转；否则停车等待。等待期间持续评估窗口变化。

实际路测中，某团队发现其决策模块在高峰期左转成功率仅为68%。通过分析数据，发现主要原因是预测模块对“对向车辆加速抢行”的意图识别滞后。优化方案是引入“交互式轨迹预测”，将自车的候选左转轨迹作为输入，预测对向车辆在不同自车行为下的反应，形成闭环博弈。优化后成功率提升至91%，但单帧决策计算时间从80ms增加到120ms，需通过GPU并行化或简化预测模型来平衡。

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

核心原理

控制模块是自动驾驶系统的“小脑”，负责将决策模块输出的目标轨迹（包含位置、速度、加速度、曲率）转换为具体的转向角、油门开度与制动压力指令。主流控制算法分为两类：

• 基于模型的控制：如MPC（模型预测控制），通过建立车辆动力学模型，在预测时域内求解最优控制序列。MPC能显式处理约束（如转向角限位、加速度限制），但计算量大。
• 基于误差反馈的控制：如PID控制，根据当前车辆状态与目标状态的偏差（横向偏差、航向偏差、速度偏差）计算控制量。PID结构简单、计算快，但难以处理强非线性与耦合。

在实际工程中，通常采用“串级控制”架构：外层位置环（PI控制器）输出期望加速度与期望横摆角速度，内层执行器环（PID或前馈+反馈）跟踪这些中间量。

控制链路与调参要点

控制模块的输入输出链路如下：

1. 输入：目标轨迹点序列（时间戳、x/y坐标、速度、航向角、曲率）。
2. 状态估计：融合IMU、轮速计、GNSS信号，估计当前车辆的位置、速度、横摆角速度。
3. 误差计算：将当前状态投影到目标轨迹上，计算横向偏差、航向偏差与速度偏差。
4. 控制律计算：根据偏差计算前轮转角指令（横向控制）与油门/制动指令（纵向控制）。
5. 执行器接口：通过CAN总线将指令发送至EPS（电动助力转向）、VCU（整车控制器）或ESP（车身稳定系统）。

案例复盘：高速弯道中的横向控制振荡

某测试车辆在高速（100km/h）弯道中，方向盘出现频率约2Hz的轻微振荡。通过CAN日志分析发现：

• 现象：横向偏差在±15cm范围内波动，但航向偏差变化剧烈。
• 根因：纯跟踪算法的前视距离Ld设置为固定值12m，在高速弯道中，车辆实际行驶轨迹的曲率变化快于前视点的更新，导致控制指令滞后。
• 优化：将Ld改为车速的函数：Ld = k * v + Ld_min，其中k=0.3s，Ld_min=8m。同时增加一个低通滤波器，对转向指令进行平滑。
• 结果：振荡消除，横向偏差控制在±5cm以内。但发现车辆在弯道中略微切弯（内偏），通过增加航向偏差的积分项解决了该问题。

2.4 车端与云端的分工边界与数据闭环

核心原理：为什么需要“端-云”协同？

车端计算资源受限于功耗、散热与成本，无法承载大规模训练任务；而云端拥有弹性计算资源，但网络延迟（通常50-200ms）无法满足实时控制需求。因此，车端与云端的分工遵循以下原则：

• 实时性要求：感知、决策、控制必须在车端完成，端到端延迟目标通常为300ms以内（从传感器曝光到执行器响应）。
• 数据规模：原始传感器数据量巨大（一辆测试车每天可产生4TB数据），全部上传不现实。云端只接收“有价值”的数据片段。
• 模型迭代：云端利用海量数据训练新模型，通过OTA（Over-The-Air）将更新后的模型参数下发至车端。

数据闭环的关键流程

一个完整的数据闭环包含以下环节：

1. 数据采集（车端）：在“影子模式”下，车辆正常行驶，系统后台持续运行感知与决策算法，但不介入控制。当检测到“疑似危险场景”或“模型置信度低”时，触发数据录制。
2. 数据上传（车端→云端）：通过4G/5G网络上传触发片段，通常包含：传感器原始数据（压缩后）、感知输出、决策日志、车辆状态、天气与时间戳。
3. 数据挖掘与标注（云端）：云端对上传数据进行自动清洗、去重、场景聚类。对于需要标注的数据，采用“预标注+人工修正”模式，将标注成本降低60%以上。
4. 模型训练与评测（云端）：在GPU集群上进行分布式训练，并在云端仿真环境中进行大规模回归测试，确保新模型在历史数据集上不出现性能退化。
5. OTA下发（云端→车端）：通过差分升级技术，仅下发模型权重文件的增量部分，减少流量消耗。下发后需进行灰度发布，先在小批量车辆上验证，再逐步扩大范围。

实战案例：基于数据闭环的“鬼探头”场景优化

某Robotaxi车队在运营中发现，面对“鬼探头”（行人从遮挡物后突然冲出）场景，系统的紧急制动触发率仅为70%。通过数据闭环分析：

• 数据采集：在100辆测试车上部署了增强型影子模式，当感知模块检测到“行人+遮挡物”同时存在且相对距离小于20m时，自动录制前后10秒数据。
• 云端分析：两周内收集了1,200个相关片段。通过场景聚类发现，80%的漏报发生在“行人从静止车辆后方冲出”的场景，且行人速度超过5m/s。
• 模型优化：在云端使用这些数据对感知模型进行微调，重点增强对“部分遮挡行人”的特征提取能力。同时，在决策模块中增加“遮挡物后盲区”的速度限制策略。
• 结果：OTA下发后，紧急制动触发率提升至95%，但误触发率（无风险时急刹）从0.5%上升至1.2%。通过调整触发阈值，最终将误触发率控制在0.8%以内。

常见误区与总结复盘

• 误区一：将所有数据都上传云端。这会导致带宽成本激增且云端处理延迟。正确做法是“边缘筛选+云端精炼”，在车端完成初步的场景价值判断。
• 误区二：车端与云端模型完全一致。车端模型需要针对嵌入式平台进行量化、剪枝，精度会略有下降。云端模型可以更大、更复杂。两者应保持“逻辑一致，实现不同”的关系。
• 误区三：忽视控制模块的云端协同。控制参数（如PID增益）通常不需要频繁更新，但针对特定车型或特定路况（如冰雪路面），云端可以下发不同的控制参数集。