2. Apollo平台概览
Apollo 是面向自动驾驶的开放平台，其核心价值不只是提供若干算法，而是把感知、定位、预测、规划、控制、车辆执行等能力组织成一条可运行、可调试、可扩展的工程链路。理解 Apollo 架构，关键是理解“数据如何从传感器进入，经过哪些模块加工，最终变成底盘控制指令”。在联调工程中，预测、规划、控制三个模块位于决策链路的中后段，是感知世界与车辆动作之间的桥梁。
一、Apollo 的分层架构与模块划分
从工程视角看，Apollo 可以划分为五层：硬件/传感器层、驱动与数据抽象层、感知定位层、决策规划层、控制执行层。各层之间通过 Cyber RT 通信中间件解耦，模块以组件（Component）形式运行，通过 Channel 发布和订阅消息。
- 硬件与传感器层：激光雷达、摄像头、毫米波雷达、组合惯导、GNSS、底盘 CAN 等，负责原始数据采集。
- 驱动与数据抽象层：将不同厂商传感器统一为 Apollo 消息格式，如 PointCloud、Image、GnssBestPose、Chassis 等。
- 感知与定位层：输出障碍物、车道线、交通灯、自车定位与姿态，是预测和规划的环境输入。
- 决策规划层：预测模块推断他车/行人未来轨迹，规划模块生成安全、舒适、可执行的行驶轨迹。
- 控制执行层：控制模块把轨迹转换为油门、刹车、转向指令，经 CAN 总线发送到底盘。
在联调中，最常打交道的模块包括 prediction、planning、control、localization、perception 和 canbus。它们通过明确的 Topic 连接，任何一个 Topic 的数据异常都会导致下游模块行为异常。
二、预测、规划、控制的定位与数据流
预测模块的定位是“理解他车意图”。它订阅感知障碍物、定位、地图和高精地图信息，输出预测轨迹与意图概率。规划模块的定位是“决定自车怎么走”，它综合预测结果、路由、地图、定位和交通规则，输出一条带速度信息的轨迹。控制模块的定位是“让车按轨迹走”，它订阅规划轨迹和底盘反馈，输出控制命令。
三者的数据流可以概括为：感知 → 预测 → 规划 → 控制 → 底盘，同时定位和地图作为公共输入贯穿全链路。联调时，我们通常沿着这条链路逐级排查：先确认感知障碍物是否稳定，再确认预测轨迹是否合理，然后确认规划轨迹是否可通行，最后确认控制指令是否被底盘正确执行。
三、典型联调场景：从感知异常到控制抖动
假设车辆在跟车场景中出现轻微“点头”现象。按照数据流排查，首先查看感知障碍物是否出现位置跳变；若感知稳定，再查看预测模块是否给出前后不一致的轨迹；若预测稳定，再检查规划模块是否频繁切换决策，例如在“跟车”和“绕行”之间反复横跳；最后检查控制模块的纵向控制参数是否过于激进。这个过程说明，预测、规划、控制虽然各自独立，但在联调中必须按数据流顺序逐级定位。
cyber_monitor 观察各 Topic 频率，使用 cyber_recorder 录制回放，使用 Dreamview 可视化预测轨迹、规划轨迹和控制指令。先确认数据“有没有”，再确认数据“对不对”，最后确认数据“稳不稳”。
四、常见误区与复盘要点
| 误区 | 表现 | 复盘要点 |
|---|---|---|
| 只看规划不看预测 | 规划轨迹异常，直接调规划参数 | 先确认预测输入是否合理，避免下游背锅 |
| 忽略定位与地图 | 规划轨迹整体偏移或错乱 | 检查定位跳变、地图版本与路由一致性 |
| 控制参数孤立调优 | 抖动、超调、响应迟滞 | 结合规划轨迹曲率与速度剖面联合分析 |
| Topic 频率不匹配 | 模块超时、数据陈旧 | 用 cyber_monitor 核对频率与时间戳 |
掌握 Apollo 架构与预测、规划、控制的数据流，是后续联调工作的基础。只有明确每个模块的输入输出、依赖关系和典型故障表现，才能在复杂问题面前快速缩小范围，把“感觉不对”转化为“可验证、可定位、可修复”的工程问题。