Apollo 技术栈深度解析：架构、感知、定位、规划

本页聚焦 Apollo 的核心技术结构与工程实现要点，包括软件运行时架构、感知融合策略、定位方案与规划控制分层设计。

---

1. 软件与运行时架构

1.1 Apollo 整体架构

Apollo 软件栈分层架构：

┌──────────────────────────────────────────────────────┐
│                 应用层（Application Layer）            │
│  HMI · Dreamview · 仿真工具（Apollo Sim）· 数据工具   │
├──────────────────────────────────────────────────────┤
│                 功能模块层（Module Layer）              │
│                                                      │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌───────────┐  │
│  │Perception│ │Prediction│ │Planning │ │  Control  │  │
│  │（感知）  │ │（预测）  │ │（规划）  │ │（控制）   │  │
│  └─────────┘ └─────────┘ └─────────┘ └───────────┘  │
│                                                      │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐               │
│  │Localization│ │HD Map  │ │Monitor  │               │
│  │（定位）  │ │（高精图）│ │（监控）  │               │
│  └─────────┘ └─────────┘ └─────────┘               │
├──────────────────────────────────────────────────────┤
│                 中间件层（Cyber RT）                   │
│  · 消息通信（基于共享内存 + 序列化）                  │
│  · 任务调度（实时协程调度器）                         │
│  · 模块生命周期管理（启动 / 停止 / 热重载）           │
│  · 数据录制（Cyber Recorder）                        │
├──────────────────────────────────────────────────────┤
│                 驱动层（Driver Layer）                 │
│  Camera · LiDAR · Radar · GNSS · CAN 总线驱动       │
└──────────────────────────────────────────────────────┘

1.2 Cyber RT 通信机制

Cyber RT 是 Apollo 自研的实时通信框架，在 ROS 基础上做了大量工程优化：

特性	ROS 1	Cyber RT
通信机制	TCP/IP + ROS Master	共享内存 + 零拷贝
序列化	ROS Msg（自定义）	Protobuf 3
调度模型	回调线程池	协程（Coroutine）调度
实时性	较差（TCP 抖动）	更好（共享内存，μs 级时延）
录制回放	rosbag	Cyber Recorder（带时间精确性）
发现机制	Master 注册	去中心化（类 DDS）

Cyber RT 关键 API（简化示例）：

// 发布者
auto writer = node->CreateWriter<Obstacle>("/apollo/perception/obstacles");

// 订阅者
auto reader = node->CreateReader<LocalizationEstimate>(
    "/apollo/localization/pose",
    [](const std::shared_ptr<LocalizationEstimate>& msg) {
        // 回调处理（在调度器线程执行）
        ProcessLocalization(*msg);
    });

// 定时器
auto timer = node->CreateTimer(10ms, []() {
    // 10ms 周期任务
    PublishControlCommand();
});

---

2. 感知融合策略

2.1 多传感器配置（典型 Apollo 车辆）

Apollo 传感器方案（L4 Robotaxi，如 Apollo 6.0+）：

顶部旋转 LiDAR（Velodyne HDL-64E 或自研 Apollo LiDAR）：
  · 360° FOV，64 线，200 m 探测距离
  · 10 Hz，产出主 3D 环境感知点云

补充固态 LiDAR（前/后/左/右）：
  · 覆盖短距盲区（< 10 m）

前视/环视摄像头（8 路 GMSL）：
  · 前视长焦（100 m+）
  · 环视短焦（泊车 / 路口目标）

毫米波雷达（4 角 + 1 前向）：
  · 全天候速度测量，补充 LiDAR 雨雾弱场景

GNSS / IMU：
  · RTK GNSS（厘米级绝对位置）
  · 高精 IMU（高频位姿更新）

2.2 感知模块处理流程

感知主流程（Apollo Perception）：

原始传感器数据
    │
    ↓ 传感器预处理（去噪、时间对齐）
    │
    ├─ LiDAR 通道：
    │   点云分割（地面/非地面）→ 聚类 → 目标跟踪
    │   模型：PointPillars / CenterPoint（Apollo 版）
    │
    ├─ 相机通道：
    │   BEV 特征提取（或 2D 检测 + 深度估计）
    │   识别：车辆 / 行人 / 非机动车 / 交通灯 / 车道线
    │
    └─ Radar 通道：
        速度滤波 → 目标关联

融合层：
    时空对齐 → 多模态目标关联 → 联合跟踪（扩展卡尔曼滤波 EKF）
    输出：3D 障碍物列表（位置、速度、类别、置信度）

2.3 交通灯检测特殊处理

交通灯检测是自动驾驶的难点，Apollo 采用"地图先验 + 摄像头确认"策略：

交通灯检测流程：

1. 查询高精地图（HD Map）：
   根据当前位置，获取前方 100 m 内的所有信号灯位置（3D 坐标）

2. 投影到图像：
   将信号灯 3D 坐标 → 投影到前视摄像头图像坐标
   得到 ROI（感兴趣区域）

3. 图像分类：
   在 ROI 内运行分类模型：红 / 绿 / 黄 / 闪烁 / 未知

4. 验证：
   与 HD Map 中的信号灯类型一致性校验
   时序滤波（防抖：至少 3 帧一致才切换状态）

优点：
  · 大幅减少误检（无需在全图搜索信号灯）
  · 在摄像头 FOV 受限或逆光时通过地图先验提高鲁棒性

---

3. 定位与地图协同

3.1 Apollo 定位方案（GNSS + LiDAR + IMU）

Apollo MSF（Multi-Sensor Fusion）定位方案：

输入：
  · GNSS RTK（厘米级，10–20 Hz）
  · LiDAR 点云（10 Hz）
  · IMU（100–1000 Hz）

三段融合流程：

1. IMU 高频积分（1000 Hz 输出）：
   提供两帧 LiDAR 之间的高频位姿更新
   使用 Pre-integration 避免重复计算

2. LiDAR-Map 匹配（10 Hz 校正）：
   NDT（正态分布变换）点云匹配
   输出：相对于事先构建的 HD Map 的精确位姿
   精度：横向 < 5 cm，纵向 < 10 cm

3. GNSS 全局约束（10–20 Hz）：
   消除 IMU 长程漂移
   城市峡谷场景下降级使用（信号遮挡时 GNSS 误差可达 3–10 m）

输出：
  50 Hz 高频位姿（IMU 内插），精度：
  · 高速公路：< 5 cm（RTK + NDT）
  · 城市：< 20 cm（GNSS 信号差时）

3.2 HD Map 在定位中的作用

Apollo HD Map 辅助定位功能：

1. LiDAR 语义地图：
   预先扫描路面点云，过滤动态目标，生成静态点云地图
   车辆行驶时用当前点云与地图匹配（NDT/ICP）

2. 语义特征匹配：
   车道线、路边石、标志牌在地图中有精确位置
   视觉检测到这些语义特征时，与地图对齐修正位姿

3. 先验约束：
   知道当前在哪条车道，IMU 积分的侧向漂移可用车道约束校正

HD Map 坐标系：
  WGS84 → UTM 投影（米制，适合地面导航）
  精度：横向 20 cm，高程 10 cm（基于 Mobile Mapping 采集）

---

4. 规划模块架构

4.1 分层规划设计

Apollo Planning 三层架构：

┌─────────────────────────────────────────┐
│  行为规划（Scenario-Based Planning）     │
│  · 识别当前驾驶场景（巡航/路口/泊车）   │
│  · 选择对应的决策 Scenario 处理器       │
│  · 输出：行为决策（换道/跟车/通行）     │
└─────────────────────────────────────────┘
                      │
                      ↓ 10 Hz
┌─────────────────────────────────────────┐
│  轨迹规划（Path + Speed Decoupled）      │
│  · Path：Frenet 坐标系中的路径优化      │
│    方法：QP（二次规划）+ 平滑处理       │
│  · Speed：S-T 图上的速度优化            │
│    方法：DP（动态规划）+ QP 精化         │
│  · 输出：1–5 s 时域内的可行轨迹         │
└─────────────────────────────────────────┘
                      │
                      ↓ 10 Hz
┌─────────────────────────────────────────┐
│  轨迹选择与后处理                        │
│  · 安全性验证（碰撞检测）               │
│  · 舒适性评分（jerk、加速度平滑性）     │
│  · 输出：最终轨迹（100+ 个时间点）      │
└─────────────────────────────────────────┘

4.2 场景化规划（Scenario-Based）

Apollo 将驾驶行为分解为具体场景，每个场景有专属处理逻辑：

场景类型	触发条件	特殊处理
Lane Follow	默认场景，直行	跟随车道线，速度跟车
Lane Change	导航换道需求 + 条件满足	Gap 搜索 + 合并轨迹
Intersection	距路口 < 100 m	信号灯等待，让行逻辑
Pull Over	目的地到达	慢速靠边，精确停车
Emergency Stop	障碍物碰撞风险	最短距离制动
Bare Intersection	无信号路口	蠕行 + 感知等待
Valet Parking	封闭停车场	低速精确泊车

---

5. 控制模块

5.1 Apollo 控制策略

Apollo Control 双控制器方案：

横向控制（Lateral Control）：
  LQR（线性二次调节器）为主
  输入：横向误差 e_y、航向误差 e_ψ 及其变化率
  输出：目标转向角 δ_target

  Preview 预瞄：前瞻 t_preview 秒（通常 0.5–1.5 s）位置误差
  自适应增益：根据车速调整 LQR 权重矩阵 Q、R

纵向控制（Longitudinal Control）：
  分层 PID：
    外环：速度控制（目标速度 → 目标加速度）
    内环：加速度控制（目标加速度 → 油门/制动量）

  Feedforward + Feedback：
    前馈：根据目标加速度 + 坡度估计计算基础油门
    反馈：PID 校正实际加速度偏差

底盘接口：
  EPS CAN 报文（10 ms 周期）：目标转向角 + 使能信号
  EHB CAN 报文（10 ms 周期）：目标加速度 + 档位

---

6. 工程亮点与主要挑战

6.1 工程亮点

亮点	描述
仿真工具链	Apollo Sim（LGSVL/CARLA 集成），支持场景回放、边界场景生成
数据闭环	Apollo Data Platform：数据采集→标注→训练→部署全链路
模块化设计	每个模块独立进程，接口清晰，便于 A/B 测试与迭代
开源生态	GitHub 开放核心代码，吸引 150+ 合作伙伴、全球社区贡献
云端协同	Apollo Cloud 提供离线训练、地图服务、OTA 管理

6.2 主要挑战

挑战	详细描述
跨车型适配	不同底盘的线控接口、动力响应特性差异大，适配成本高
长尾场景	城市复杂场景（逆行、施工、异常行为）覆盖不完整，持续需要数据
开源与商业能力差距	开源版（Apollo 9.0+）与商业 Robotaxi 版之间仍存在功能差距
实时性保证	深度学习模型推理时延抖动，在异构硬件上的实时性保证仍有挑战
定位在 GNSS 弱场	地下车库、城市峡谷中纯 LiDAR 地图定位的鲁棒性需持续改进