自动驾驶优化:从复杂性到实时工程

人们在讨论自动驾驶系统时，往往聚焦于其 AI 能力或高层次的伦理问题。然而，对于构建这些系统的软件架构师和工程师而言，现实却是与延迟、带宽及计算资源限制的博弈。本文深入探讨了自动驾驶（AV）技术栈的端到端技术架构，阐释了从上下文感知传感器融合到模型预测控制（MPC）求解器等优化技术，如何在毫秒级时限内将数千兆字节的原始传感器数据转化为安全的控制指令。

乍一看，自动驾驶系统显得极其复杂。这些系统并非简单的线性流程，而是由感知、预测、规划和控制组成的递归式实时循环。

要了解需要进行优化的环节，首先得分析下数据流。本质上，生产级自动驾驶技术栈是一个由发布 / 订阅组件构成的分布式数据流图（实际应用中通常因反馈和重新规划而呈现循环特性），通常通过 基于 DDS（数据分发服务）的 ROS 2 这样的中间件来实现。该管道必须每秒从摄像头、雷达、激光雷达、GNSS 和 IMU 中采集并处理海量的数据。

图 1 概述了这一端到端架构，涵盖从高采样率传感器输入，到感知 / 定位与融合，再到规划、控制和执行，主要的数据流和计算流一目了然。

  图 1 ：AV 软件高层架构 

感知层负责将原始数据转化为世界模型。一种简单粗暴的方法是按全分辨率和最高采样率处理每个传感器的数据。然而，若以全保真度每秒处理数千兆字节的数据，任何车辆的计算资源都会被耗尽。

感知方面的优化通常意味着基于上下文的优先级排序：调整感知、预处理和推理的资源投入，以便适应当前的运行设计域（ODD）。通常，自动驾驶技术栈会对关键管道阶段的计算成本进行建模，并应用针对精度、延迟和资源使用等因素做过充分权衡的策略（或基于优化的控制器）。

由于感兴趣区域（ROI）窄，所以长距离精度变得至关重要。为此，自动驾驶技术栈通常会优先处理前视激光雷达和长距离摄像头，同时通过降采样、降帧率 / 扫描率或选择性处理感兴趣区域（ROI）等方式，减轻侧视传感器的负载。

对于交叉车流、弱势道路使用者以及复杂的交互场景而言，周边视野的覆盖变得愈发重要。这些系统通常优先采用广角摄像头和侧向传感器，并可能为语义感知和目标追踪分配更多的计算资源。

图 2 ：动态传感器加权逻辑 

在实际应用的自动驾驶程序中，感知管道需要这种灵活的资源分配。许多团队已经突破单阶段目标列表的限制，设计出能够以低延迟处理高帧率传感器数据流的管道，并且涵盖了从早期预处理到推理和跟踪的整个流程。实际上，这种融合通常涉及两个互补的控制机制。首先，通过处理参数（帧率、感兴趣区域、分辨率、模型选择）来管理计算负载。其次是融合权重，用于调节追踪中的测量不确定性（如测量协方差 R）。

正如 Ahn 等人所述，将数据并行执行与选择性 GPU 卸载相结合，可以在保持精度目标的同时，提升感知管道的端到端吞吐量及降低延迟。

为了直观地了解该逻辑在跟踪 / 融合层中的表现，不妨考虑一个基于上下文的权重管理器。在基于卡尔曼滤波器的跟踪器中，传感器可信度可以通过测量协方差矩阵 R 来表示（通常按传感器和测量类型分别计算）：协方差矩阵越大，滤波器对该测量的依赖程度越低；反之，协方差矩阵越小，依赖程度越高。

class SensorFusionManager:    def update_weights(self, vehicle_state, environment_context):        """        根据上下文动态调整传感器可信度（协方差）。        低协方差 = 高可信度。        """        # 基本配置（说明性标量偏差/标度因子）        lidar_cov = 0.1        camera_cov = 0.2        radar_cov = 0.3        # 场景：高速公路        # 更依赖长距离雷达/激光雷达；摄像头可能会出现运动模糊        if vehicle_state.speed > 100.0:  # km/h            radar_cov = 0.1  # 提升对雷达测速的信任            camera_cov = 0.5 # 降低对摄像头的信任        # 场景：城市 / 拥堵        # 利用可信摄像头实现语义理解（行人、交通标志）        elif environment_context.type == 'URBAN_DENSE':            lidar_cov = 0.05 # 在近距离几何建模中充分信任激光雷达            camera_cov = 0.1 # 在目标分类中高度信任摄像头            radar_cov = 0.4  # 在杂波密集的环境中，雷达对某些信号或关联的识别可能不够可靠        return self.kalman_filter.update_covariance(            lidar=lidar_cov,             camera=camera_cov,             radar=radar_cov        )

通常，轨迹生成被视为一个模型预测控制（MPC）问题。工程师们不再采用硬编码规则，而是定义一个成本函数（J），由求解器对其进行最小化（如下图所示）。

求解器必须在满足硬约束的条件下求得 J 的最小值。

执行机构与动力学限制，

如有必要，还得加上速率限制。

安全通道 

规划出的“自我足迹（ ego footprint ）”必须位于可行驶区域内，并与障碍物保持安全距离（通常通过通道边界、符号距离约束或碰撞几何体的凸面近似来表示）。

图 3： MPC 控制循环 

在自动驾驶领域，MPC 被用于在安全响应的同时平衡速度与舒适性。为了满足嵌入式系统的时限要求，开发团队通常依赖于“热启动”求解器：对于凸 MPC 建模，使用 OSQP 等 QP 求解器；对于非线性建模，则使用非线性规划求解器（如 Ipopt）或实时 NMPC 工具链。

Allamaa 等人 在 2024 年的研究中阐明了增强型 MPC 建模和混合优化技术如何实现安全、敏捷的决策。Zhang、Rossi 和 Pavone 于 2015 年发表的早期研究 提供了一个更广泛的例子，展示了 MPC 作为滚动时域决策在车队协调层面的应用，而不局限于一辆车的轨迹控制。此外，Arrigoni、Braghin 和 Cheli 在 2021 年的研究 探索了一种替代方法，即利用遗传算法策略求解 NMPC 轨迹规划器。在实际（通常为 C++）的实现中，优化循环必须具备高效率、可预测性，并需针对最坏的情况进行性能监测。

// 简化的 MPC 成本计算循环doublecalculate_cost(const std::vector<State>& preds,                      const Trajectory& ref_traj,                       const std::vector<Control>& u_seq) {    double total_cost = 0.0;    // 用于调校行为的权重（舒适性与操控性）    const double W_POS = 10.0;   // 位置误差惩罚    const double W_JERK = 50.0;  // 转向抖动将受到严厉惩罚(舒适性/平顺性 Δ转向)    const double W_VEL = 1.0;    // 超速惩罚    for (int t = 0; t < HORIZON_N; ++t) {        // 1. 状态偏差成本（跟踪精度）        const double pos_error = (preds[t].x - ref_traj[t].x);        const double vel_error = (preds[t].v - ref_traj[t].v);        total_cost += W_POS * (pos_error * pos_error);        total_cost += W_VEL * (vel_error * vel_error);        // 2. 控制输入成本（乘客舒适度）        // 转向大幅变化惩罚（delta_delta）        if (t > 0) {            const double steering_delta_penalty = u_seq[t].steer - u_seq[t-1].steer;            total_cost += W_JERK * (steering_delta_penalty * steering_delta_penalty);        }    }    return total_cost;}

自动驾驶系统是一个“繁忙的生态系统”。定位、感知、预测和控制模块均并行运行，争用相同的 CPU 和 GPU 资源。如果感知模块处理图像耗时过长，那么规划模块可能会错过其更新窗口。

为避免这一问题，许多团队将计算预算本身视为一个工程优化问题：他们通过测量执行时间、分配处理器内核、设置优先级以及调整服务质量（QoS）来确保正确的任务在正确的时间执行。最坏情况执行时间（WCET）：每个节点都有一个经过测量（或保守估计）的 WCET 值和一个明确的截止时间预算。确定性调度策略：在安全 / 控制非常关键的领域，通过实时操作系统（RTOS）强制执行实时调度；在通用操作系统上则通过实时调度配置来实现。比较常见的是固定优先级的抢占式调度；诸如优先级继承之类的协议有助于限制对共享资源的阻塞，并保护具有严格截止时间的任务。

在实践中，这些预算采用多速率设计：高级规划通常以大约 10-20 Hz（50-100 ms）的速率运行，而低级控制环路则可在专用控制器上以大约 50-100 Hz（10-20 ms）的速率运行；具体速率取决于平台和安全架构。

表 1：100 毫秒控制周期的延迟预算示例（仅供参考） 

Sun 等人（2023） 强调了这种严谨性的重要性，他们提出了一个综合框架，用于分析多速率自动驾驶软件栈中的端到端延迟，以确保关键任务链能够满足其时限要求。

优化使系统更加智能，但也增加了调试难度。当 MPC 求解器选择一条路径时，它的依据是成本函数的收敛性，而非简单的“如果……那么……”这样的逻辑。

为了解决这个问题，开发团队设计了健壮的日志记录管道。他们会记录所考虑的具体约束条件、权衡取舍过程以及最终选择的路径。

数据格式 

对于时间同步的机器人数据，常见的选项包括容器格式（如广泛用于机器人日志捕获和回放的 MCAP ）以及 Dataset-Oriented 格式（如 HDF5 ），具体使用哪种取决于分析工作流和存储限制。

模式 

许多团队使用 Protocol Buffers 或 FlatBuffers 定义严格的、带版本控制的模式，从而确保类型安全、向前 / 向后兼容性，以及跨组件的可靠工具支持。

message DetectedObject {  // 用于时间一致性的唯一跟踪标识符  uint32 track_id = 1;  // 目标分类  enum Type { UNKNOWN=0; PEDESTRIAN=1; VEHICLE=2; CYCLIST=3; }  Type type = 2;  // 状态向量 [x, y, z, vx, vy, vz, yaw]  repeated float state = 3 [packed=true];  // 三维边界框大小  Vector3 dimensions = 4;  // 传感器融合可信度级别的协方差矩阵（展平后的7×7矩阵）  repeated float covariance = 5 [packed=true];}