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

简介

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

端到端架构：从传感器到执行器

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

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

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

图 1 ：AV 软件高层架构

典型数据吞吐量

• 激光雷达：大约 0.3–260 万点/秒（通常每个传感器大约 35–255 Mbps，具体取决于配置）。

• 摄像头：4K/60fps 视频流（全彩无压缩视频可能需要大约 12 Gbps；生产系统通常采用 RAW 格式和/或压缩技术）。

• 雷达：稀疏检测/轨迹（通常带宽低、刷新率高）。

优化感知管道：资源动态分配

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

基于上下文的传感器优先级排序

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

高速公路场景

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

城市场景

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

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

[点击这里查看大图]

技术实现：从预处理到融合

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

• 激光雷达数据处理

  原始点云（ x , y , z , 强度）通常会进行离散化处理（体素化或柱状化），随后由 3D 检测网络（如 VoxelNet 系列方法或 PointPillars ）进行处理。体素/柱状的分辨率是空间保真度与推理延迟/计算之间的关键权衡点。

• 雷达数据处理

  雷达测量数据（距离、方位角、距离变化率）常被用于获取可靠的速度信息以及支持车辆在恶劣天气条件下行驶；其不确定性可根据具体上下文和杂波特性进行调整。

• 工具

  部署管道通常会使用 TensorRT 等推理加速器，在嵌入式 GPU 平台上（例如 NVIDIA Xavier 级系统；新一代产品还支持 Orin 系列硬件）对深度学习模型进行优化和运行。模型选择会随技术栈而变化，但在计算机视觉领域，标准骨干网络（如 ResNet ）和检测器家族（如 YOLO 风格）被广泛采用；而在自动驾驶领域，则同时采用 3D/BEV 专用架构。

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

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

伪代码：动态传感器加权（Python）

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 的数学原理

感知处理的是概率，而规划处理的是约束条件。规划模块会生成一条可行的轨迹，通常是以状态和控制值序列的形式（如下图所示），在一个固定的控制周期内对整个规划时域进行参数化。

$\{ x_k, u_k \}_{k=0}^{N}$

通常情况下，这一时间在数十毫秒到大约一百毫秒之间，具体取决于技术栈和平台。如果未能在此时限内完成，则将导致响应速度下降。

优化问题

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

$J = \sum_{k=0}^{N-1} \left( \| x_k - x_k^{\text{ref}} \|_Q^2 + \| u_k \|_R^2 \right) + \left\| x_N - x_N^{\text{ref}} \right\|_P^2$

其中，$\{ x_k^{\text{ref}} \}_{k=0}^{N}$表示预测时段内的参考轨迹。

• $x_k$：第 k 步的状态向量（位置、速度、偏航角）。

• $u_k$：第 k 步的控制输入（转向角、加速度）。

• $x_k^{\text{ref}}$：第 k 步的参考状态（即某个时点的期望位置/航向/速度），通常由更高层次的规划器、路由或行为模块提供。

• $x_N^{\text{ref}}$：预测期结束时的终端参考状态（即第 N 步的参考状态），用于促使系统朝着预期的终点状态条件收敛。

• Q 、 R 和 P ：权重矩阵。通过调整 Q、R 和 P，工程师们在“主动性”与“舒适性”之间进行优化。

基于约束条件求解

求解器必须在满足硬约束的条件下求得 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 成本函数（ C++ ）

// 简化的 MPC 成本计算循环double calculate_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 定义严格的、带版本控制的模式，从而确保类型安全、向前/向后兼容性，以及跨组件的可靠工具支持。

示例：感知对象模式（ Protobuf ）

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];}

这些数据结构是可解释性的核心。Suresh Kolekar 等人（2022）的研究表明，Grad-CAM 等可视化工具为人们提供了一个窗口，让人们可以了解 AI 模型是如何看待世界的。这种洞察不仅有助于安全检查，还能在解释模型行为时提升透明度。

小结

对于自动驾驶车辆而言，优化不仅仅是一种数学方法，而是维系整个系统运转的纽带。它决定了感知任务如何调度与加速（包括在适时进行的 GPU 内核级和图级优化），规划过程中的受约束优化问题如何建模和求解，以及实时调度策略和中间件服务质量（QoS）如何配置以满足延迟和安全要求。

对于软件工程师而言，结论不言而喻：开发自动驾驶技术栈不仅仅是编写遵循逻辑的代码，更是构建一个能够同时管理资源、时间和物理约束的系统。在行业不断突破自动驾驶边界的过程中，优化这些权衡的能力仍将是决定性的核心技能。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/articles/optimization-in-automated-driving/