2. Apollo平台概述

Apollo 是百度在 2017 年发布的自动驾驶开源平台,其目标并不是提供一个“开箱即用”的整车产品,而是把自动驾驶研发中最通用、最复杂、最需要协同的部分抽象成可复用的软件与工具链,让开发者能够把精力集中在场景、算法和车辆适配等差异化工作上。理解 Apollo 平台,需要同时看清三条线索:它经历了怎样的开放演进、它的架构如何分层、以及车辆平台集成在整个体系中处于什么位置。

一、发展历程:从开放代码到开放生态

Apollo 的发展大致可以划分为几个阶段。早期阶段以“开放能力”为主,重点是把感知、定位、规划、控制等核心模块开源,并提供仿真与数据平台,降低自动驾驶研发的起步门槛。随后进入“平台化”阶段,Apollo 逐步形成清晰的版本节奏与模块边界,推出面向不同计算平台的适配方案,并强化了标定、诊断、OTA 等工程能力。再往后是“生态化”阶段,平台开始强调车路协同、量产合作与开发者社区,形成从代码到工具、从仿真到实车的完整闭环。

对车辆平台集成工程师而言,发展历程的意义在于:Apollo 的接口与模块划分并非一成不变,不同版本在传感器接入方式、底盘通信协议、标定流程上可能存在差异。因此在实际项目中,第一步往往不是写代码,而是确认所用 Apollo 版本的能力边界与集成约定。

二、架构组成:分层解耦是核心思想

Apollo 采用典型的分层架构,从下到上大致包括硬件/车辆平台层、驱动与抽象层、感知与定位层、规划与控制层、以及上层应用与工具层。各层之间通过明确的接口通信,最常用的中间件是 Cyber RT,它负责节点管理、消息传递与调度。

这种分层带来的直接好处是“可替换”。例如,激光雷达从 16 线换成 128 线,主要影响驱动与感知配置;底盘从某品牌线控平台换成另一品牌,主要影响车辆平台适配层与标定参数。只要接口契约稳定,上层算法不必大改。这也是 Apollo 能够支撑多种车型与多种传感器组合的基础。

Apollo 平台分层架构与车辆平台集成定位 应用与工具层 Dreamview 可视化 · 仿真平台 · 数据流水线 · 标定工具 · 诊断与 OTA 规划与控制层 Routing · Planning · Prediction · Control · 底盘指令生成 感知与定位层 Camera / LiDAR / Radar 感知 · 融合 · GNSS+IMU+地图定位 驱动与抽象层(Cyber RT 中间件) 传感器驱动 · 消息总线 · 节点调度 · 时间同步 · 接口抽象 车辆平台层(集成核心) 线控底盘 · CAN/以太网通信 · 车辆信号 · 执行器 · 安全冗余 标定参数 · 车辆配置文件 · 底盘协议适配 · 故障诊断 数据流与控制流方向 集成关注点:接口契约 标定 · 时序 · 安全 · 诊断

三、核心模块:各司其职又彼此约束

Apollo 的核心模块可以按“感知—定位—规划—控制”主线来理解。感知模块负责把原始传感器数据转化为障碍物、车道线、交通标志等结构化信息;定位模块融合 GNSS、IMU、激光雷达与高精地图,输出车辆在全局坐标系中的位姿;规划模块根据路由、地图与感知结果生成安全、平滑、可执行的轨迹;控制模块则把轨迹转化为油门、刹车、转向等底盘指令。

此外还有几个容易被忽视但非常关键的模块:标定模块负责传感器内外参与车辆坐标系的对齐;诊断模块监控各节点与硬件状态;HMI 与 Dreamview 提供可视化与调试入口;Cyber RT 作为运行时底座,决定消息如何流转。车辆平台集成并不是只对接“控制”一个模块,而是同时影响标定、诊断、时间同步与安全策略。

模块 主要职责 与车辆平台的关系
感知 目标检测、跟踪、融合 依赖传感器安装位置与外参标定
定位 全局位姿估计 依赖车辆运动学参数与 IMU 安装
规划 路径与速度决策 受车辆尺寸、转弯半径、动力学约束
控制 轨迹跟踪与执行器指令 直接对接线控底盘协议与响应特性
标定 传感器与车辆坐标系对齐 决定感知与控制的一致性
诊断 状态监控与故障上报 读取底盘故障码与车辆信号

四、车辆平台集成的基本定位

在 Apollo 体系中,车辆平台集成处于“承上启下”的位置。向上,它要为规划控制提供稳定、低延迟、语义明确的车辆状态与执行接口;向下,它要理解底盘厂商的 CAN 矩阵、线控协议、使能条件与安全逻辑。换句话说,集成工程师既不是纯算法开发者,也不是纯底盘工程师,而是两者之间的“翻译层”和“保障层”。

集成工作的典型内容包括:确认底盘是否支持线控转向、线控制动与线控驱动;梳理 CAN 报文与信号定义;配置车辆参数文件;完成传感器安装与外参标定;验证控制指令的响应延迟与精度;建立故障降级与安全停车策略。这些工作直接决定自动驾驶系统能否从仿真走向实车。

集成定位一句话总结:车辆平台集成是把 Apollo 的“算法意图”翻译成“底盘动作”,并把底盘的“真实状态”反馈给算法的工程桥梁。

五、典型场景与常见误区

以一个园区低速接驳车项目为例:车辆采用某品牌线控底盘,Apollo 运行在工控机上。集成流程通常是先读取底盘 CAN 协议,确认转向、制动、驱动的控制报文与反馈报文;再在 Apollo 中配置车辆参数与底盘适配节点;随后进行静态标定与低速直线、转向测试;最后接入规划控制,验证轨迹跟踪效果。整个过程往往需要反复调整控制增益与延迟补偿。

常见误区:一是认为“接上 CAN 就能跑”,忽视使能条件、心跳报文与安全校验;二是只关注控制指令下发,忽略底盘反馈的时序与单位;三是标定一次就长期使用,未考虑传感器松动、轮胎更换与载荷变化;四是把仿真通过等同于实车通过,忽略通信延迟与执行器非线性。

建议:在集成初期就建立“接口清单 + 标定记录 + 测试用例”三件套,把车辆平台当作一个需要持续验证的子系统,而不是一次性配置项。

六、配置示例:车辆参数片段

Apollo 中车辆相关参数通常以配置文件形式存在,下面是一个简化示例,用于说明集成时需要关注的字段类型:

vehicle_config:
  vehicle_id: "park_shuttle_01"
  vehicle_type: "L4_shuttle"
  chassis:
    protocol: "can"
    can_channel: "can0"
    enable_heartbeat: true
    heartbeat_interval_ms: 100
  geometry:
    length_m: 4.2
    width_m: 1.8
    wheelbase_m: 2.6
    min_turning_radius_m: 5.0
  control:
    steering_ratio: 16.0
    max_steering_angle_deg: 30.0
    brake_deadzone: 0.05
    throttle_deadzone: 0.03
  calibration:
    camera_front_extrinsic: [0.0, 0.0, 1.5, 0.0, 0.0, 0.0]
    lidar_top_extrinsic: [0.0, 0.0, 1.8, 0.0, 0.0, 0.0]

这些参数并不是“填完即可”,而是需要结合实车测试不断修正。例如转向比、死区、最大转角会直接影响控制精度;外参误差会同时影响感知与定位。理解 Apollo 平台架构与车辆平台集成的定位,最终要落到这些具体参数与验证动作上,才能形成可交付的工程能力。