Apollo 3.0自动驾驶技术全解读：从研发到量产经历了什么？

7 月 4 日，第二届百度 AI 开发者大会如期而至，在此次发布会中，全球首款 L4 级量产自动驾驶巴士“阿波龙”宣布量产下线。在这突破性的背后，揭示着 Apollo 平台的快速提升。一年前，百度 Apollo 平台发布，当时 Apollo1.0 有 35000 行代码。经过一年的发展，Apollo 3.0 的代码已经长了 6 倍之多，达到了 220000 多行代码。

7 月 28 日，由百度开发者中心主办，极客邦科技承办的第 80 期百度技术沙龙邀请了来自百度 Apollo 技术布道师胡旷、百度 Apollo 控制／车辆交互技术负责人罗琦、百度自动驾驶技术部高级产品经理王石峰、百度自动驾驶技术部资深研发工程师杨凯、百度自动驾驶事业部资深架构师杨凡五位讲师，从车辆认证平台、硬件开发平台、功能安全及量产解决方案四个方面着手，为大家全面解读 Apollo 3.0 从研发到量产的技术原理。

1 Apollo3.0 自动驾驶开放平台介绍

百度 Apollo 技术布道师胡旷做了开场演讲。他首先介绍了百度 Apollo 的发展历程。在今年 7 月 Apollo3.0 推出前，Apollo 已经在一年里迭代了 4 个版本，最新的版本不仅更新了激光雷达、摄像头、毫米波雷达、组合导航系统以及超声波雷达等硬件设施， 还在自动驾驶的感知、定位、规划、决策以及控制等技术上进行了升级。

随后，胡旷对百度 Apollo 3.0 的新特性进行了详细介绍，包括 Apollo 3.0 的架构升级以及新推出的核心能力。如下图所示，首先在云服务平台以及软件平台方面，Apollo 3.0 针对量产低速园区场景全面升级七大能力：低速园区感知算法、低速园区规划算法、低速园区控制方案、赋能量产安全监控、赋能量产 HMI 调试工具、赋能量产开发者接口、开发者贡献相对地图。在硬件开发方面，Apollo 3.0 从参考硬件升级为硬件开发平台，新增了 15 种硬件选型，发布了 Apollo 传感器单元，并添加底层软件抽象层，旨在为用户提供更多接口的同时还可以做时间戳同步及空间数据的融合。在车辆方面，Apollo 3.0 从车辆参考平台升级为车辆认证平台，链接车企与开发者需求，加速无人驾驶的部署和量产。

2 Apollo3.0 PnC 更新以及车辆认证平台介绍

百度 Apollo 控制、车辆交互技术负责人罗琦在此次分享中介绍了 Apollo3.0 软件平台更新以及车辆认证平台。

Apollo 软件平台更新

Monitor/Guardian

在演讲中，罗琦首先对 Apollo 3.0 Monitor 状态监控模块的升级和 Guardian 新模块的加入进行了介绍。他表示，Monitor 模块和 Guardian 模块是对于 Functional safety 和 Fault handling 的初步尝试。其主要的工作方式为：Monitor 系统实时监测硬件及软件各个模块的健康状态，以及是否收到一些最重要的信号。一旦发现障碍物，Monitor 就会通知 Guardian 模块，同时在 Dreamview 上通过声音和图像的方式提示接管。紧接着， Guardian 模块会根据 Monitor 发来的信息，进行一系列的动作。当超声波传感器正常工作并且前方没有检测到障碍物的前提下，尝试在 10s 内缓缓停车；当超声波传感器不正常工作或者监测到有障碍物，会为了防止碰撞紧急刹车。

相对地图

相对地图最初是在 Apollo2.5 中发布。目的是在一些相对简单的路况上，降低对于高精地图的依赖。在 Apollo 2.0 以及之前的开放中，高精地图主要用于 3D 雷达的监测，2D 相机红绿灯监测， 以及定位模块的多传感器融合。 在 Apollo2.5 中，百度主要依赖相机进行障碍物和车道线的监测，同时定位模块主要依赖相对车道线或者 GPS 定位。

相对地图总共有三种工作模式：

第一种是直接由实时的感知模块监测到的道路边界，以 10hz 的频率生成。好处是完全脱离对高精地图和高精定位的依赖，且部署成本较低；坏处是这种工况对于车道线本身的车道线标注是否清晰依赖度较高，同时在这种工况下只能进行简单的 ACC 和 lane keeping.

第二种是指引线加上相对地图。这样的方式对于定位有较强依赖，而对车道线本身标注的清晰程度依赖较低。同时，可以不基于高精地图，仍然保持较为灵活的部署方式。

第三种是基于指引线 + 高精地图模式，也就是说和原本 2.0 的方案兼容。这样的好处就是得到最全面和精确的地图定位信息，但部署成本较高。

Apollo 2.5 发布的是只支持单车道的方案，在 Apollo 3.0 以及 3.0 以后中，为了支持合作伙伴在这种相对地图模式下的超车、换道等需求，百度加入了多车道的相对地图支持。

Lattice planner

Lattice planner 是一种 sample based planning 的算法，具体的算法过程为：

1. 横向和纵向分别撒点， 根据实时的决策目标，比如跟车或者停止，在车辆的状态空间内取不同的终点。用高阶曲线链接起点和不同状态的终点。

2. 根据体感，是否达到终点状态等，对于横向和纵向的曲线 assign 不同的 cost。

3. 将横纵向的曲线 bundle 起来形成最终的曲线，之后根据曲线 bundle 后的 cost，从小到大排序，再检查 bundler 后的曲线是否符合各种 gometry constraint 和通过 collision check。

4. 最终输出满足条件的最优的解。

同样， Lattice planner 也有其独特的优势及劣势。与现在的 em planner 对比，Lattice planner 在调试性和可理解性上都要容易很多。但是与现有的 planner 相比，因为轨迹之间是用高阶曲线进行连接，所以 Lattice planner 在特别复杂的条件下表达能力有所欠缺。更适合相对比较容易的高速场景以及末端物流场景。

Fleet Management

百度定义了第三方平台和云服务平台的车辆接口、合作方接口、园区接口、以及起始终点接口。同时在百度云端服务和车端自动驾驶系统中，定义了起始点、车辆调度整合、聚焦车辆接口以及状态收集接口，这些接口和量产接口保持一致，保证了和合作方是一套调度接口，可以进行一些功能的实现。

Apollo 开放车辆标准

下图为 Apollo 开放车辆接口标准，主要分为两大部分：线控系统和车辆系统。对于线控系统，百度对接入的系统有着功能，性能，安全指标等一系列要求。对于车辆系统本身，百度也对其中的一些功能指标，性能指标，安全指标，能耗指标具有一系列的要求。

3 自动驾驶硬件系统及 Apollo 硬件开发平台的简介

第三个主题由百度自动驾驶技术部高级产品经理王石峰讲述，王石峰从传感器的产品定义出发介绍了整体自动驾驶的硬件系统，使开发者能根据自身的自动驾驶 ODD 选择更加适用的硬件选型和方案。

自动驾驶的硬件系统

从整体看自动驾驶的硬件系统，可粗略分为感知、决策、控制三大模块。

在车辆感知上，一方面要从车辆运动考虑到车的速度和转角信息，另一方面还要考虑到环境感知，例如激光雷达、超声波、摄像头，毫米波雷达等传感器的使用。另外，驾驶员监测主要是通过摄像头和生物电传感器，生物电传感器集成在方向盘里面，可判断驾驶员的手是否脱离方向盘。与此同时，生物电传感器也可以检测驾驶员的精神状态。

在车辆决策上，主要就是计算单元，各类传感器信息统一到计算单元处理。T-BOX 向上接互联网，向下接 CAN 总线，可实现远程对车辆的控制。黑匣子记录车辆控制和行驶信息，可提供信息对事故进行判定。

在车辆控制上，主要有制动、转向、发动机、变速箱，以及警告系统，声音、图像、振动。

接下来具体到自动驾驶硬件系统中的传感器、计算单元及车辆线控。

传感器

自动驾驶使用的感知类的传感器，主要有激光雷达、毫米波雷达、摄像头、组合导航。激光雷达安装在车顶，360 度同轴旋转，可以提供周围一圈的点云信息。另外，激光雷达不光用于感知，也可用在定位和高精度地图的测绘。毫米波雷达安装在保险杠上，与激光雷达原理类似，通过观察电磁波回波入射波的差异来计算速度和距离。组合导航分为两部分，一部分是 GNSS 板卡，另一部分是 INS。当车辆行驶到林荫路或是建筑物附近，GPS 会产生偏移或是信号屏蔽的情况，这时可通过与 INS 进行组合运算解决问题。

计算单元

说到自动驾驶汽车的计算单元，首先必须考虑到冗余设计。在计算单元中，所有的 CPU、GPU、FPGA 都是双冗余备份，总线上包括 PCIE 和 Ethernet 也都是双冗余。当所有系统失效的情况下，还可通过 MCU 发出控制指令到车辆控制单元刹车制动，保证安全性。这种中央集中式的计算有利于算法快速迭代，但也有缺点：整个单元体积比较大，功耗比较高。那有什么办法可以降低功耗和体积？可以考虑分布式边缘计算架构。以激光雷达算法的公司 Dibotics 为例，将 SLAM 算法写到 Renesas 的 R-Car 芯片上，再将芯片植入到传感器中。另外，自动驾驶的芯片车规是在封装过程中完成，其主要指标是功耗、算力和面积。目前整个芯片制造正从 16 纳米向 7 纳米迭代，7 纳米对比 16 纳米整个运算率会提升 40%，功耗会降低 60%。

线控系统

自动驾驶的线控系统分为减速、转向和加速三大部分。线控 1.0 版对车辆的踏板以及方向盘进行改装；线控 2.0 版对车辆的 ADAS 系统进行借用，如 MKZ 的自动泊车以及 ACC；线控 3.0 版对车辆进行定制，所有系统均可线控和手动控制。

4 Apollo 3.0 硬件开发平台

下图为 Apollo 3.0 硬件开发平台结构图。Apollo3.0 将 Apollo 参考硬件全面升级为 Apollo 硬件开发平台。成功适配并增加了 15 种以上的设备，添加底层硬件抽象层。可适配多种数据格式，定义通用的 API 接口，无缝衔接 Apollo 上层软件，使得多种硬件设备在 Apollo 平台上实现即插即用。极大的方便了开发者，合作伙伴和硬件厂商，节省了大家对 Apollo 平台的开发适配时间。

5 Apollo 3.0 功能安全探索

安全是自动驾驶前行的保障，尤其是对于 L4 级别的自动驾驶系统，功能安全更是一个全新的领域与挑战。基于此，百度自动驾驶计算平台资深研发工程师杨凯现场分享了百度 Apollo 在功能安全方面的探索。

功能安全是什么

无人车主要分为两大块，一块是网络安全，另一块就是功能安全。网络安全主要是指驾驶软件信息不被黑客窃取。而功能安全是指通过冗余、多样性手段构建功能安全子系统，极大限度召回软硬件故障，使得损害风险降低到可接受的水平。

功能安全如何做

在自动驾驶的功能安全上，百度采用了电子电器行业标准 ISO26262。但是目前看，市面上的功能安全还存在很多挑战：目前业界并无标准可循，不存在为自动驾驶制定的功能安全标准。传统的汽车电子电气开发遵守国际标准 ISO 26262。另外，目前大部分研发自动驾驶的厂商还是聚焦在自动驾驶功能本身，只有少数在参考 ISO 26262 的思路，结合自动驾驶系统的特点，探索自动驾驶的功能安全机制。

面对挑战，百度从两个方面出发：从全局看，落实 ISO26262，搭建安全流程，系统地分析解决系统风险点；从局部看，建立无人驾驶安全子系统，召回软硬件故障，建立安全防线。

功能安全子系统

下图为功能安全的主系统思路。百度把自动驾驶主系统比作成一个人，感知是大脑，控制是手和脚。当驾驶员遇到突发状况而面临安全风险时，系统会根据情况做故障检测和故障处理。故障处理分为 5 个等级：第一个等级警告，不是特别严重；第二个等级是减速，当系统延迟比较大的时候，会相应地做降速行使；第三个等级停车，比如传感器失效，就需要紧急停车；第四个等级是靠边停车，不过是否能够靠边停车是由它发生的故障决定，比如感知系统失效就不能进行靠边停车；第五个等级就是继续行驶，无碰撞风险障碍。

熔断机制 & 碰撞检测

在杨凯介绍功能安全的熔断机制时，他说道：“在没有功能安全这个机制的时候，系统需要把感知发给规划，规划再发给行动，进而行动再控制车辆。我们把主系统的控制权拿过来让安全系统直接进行接管。”如下图所示，右面是碰撞检测，绿色区域是规划距离，也就是正常的车在规划过程中会与行车保持一个安全距离，而这个安全距离要远于功能安全的检测距离。红色区域是安全检测的碰撞区域，比如下面的公式，参考 mobilSS。第一部分 VR 是 round。第二部分是当前在 R 的时间内有可能的加速度，也就是你最大可能加速的时候可以行进多少距离。公式第三部分是后车加速到一个速度之后，它用极小的速度减速，往前运行。第四部分是突然减速，后车的距离。这四部分就是我们能够刹住车的安全距离，在达到安全距离这种情况下我们就需要立即停车，保障避免风险。

另外在碰撞的时候，除了刚才强调的冗余机制、碰撞检测之外，还有多样性的感知算法，比如说 CNN 感知算法。

6 Apollo3.0 演进与 Apollo Pilot 量产园区解决方案详解

从实验室走向量产需要解决哪些问题？杨凡从安全、智能、量产及经济四个方面为大家进行了讲解，并提出了为量产车辆量身打造的一站式解决方案。

量产园区自动驾驶解决方案

首先，最重要的一点是安全，安全不管是 Apollo 发布还是在日常工作中都是最核心的事情，Apollo 大量的工作或直接或间接都是安全。在这其中，百度最关注的就是从整体设计上的安全。因此，百度作出了一个独立的物理隔离的安全功能，另外还提供了网络安全、所有的验证安全，以及对行使过程中的安全和运营进行多方面的考虑。

接下来是智能，百度完成量产是为了和市场合作，真正把它做成一个产品。所以，它应该是足够智能的，能够解决它在路上所有实际应用需求的工况，并要有实际的可应用价值，还需要与人有足够多的互动。

第三点是量产，我们知道做第一辆车很简单，因为其具有的独特性，只要用最好的仪器和设施就可以，如果出现问题，可随时用更好的工具进行调整。但是如果是量产的东西，就会出现经常说到的召回的概念。但事实上，如果真正有问题了，特别是现在在很多产业通用化的前提下，一个平台召回可能是几十万辆车，这是非常巨大并且不可能承受的成本。所以在量产上，需要防患于未然，在量产设计之前要把翻案和可行性做到切实，并且在生产过程中需要让每一个工人可以使用有效的方式来简洁明确的把这个东西生产到位，这就是与实验室的不同。

最后是经济，价格必须要降到足够便宜。关注 Apollo 的朋友应该知道，一开始的价格都是比较高昂，包括 2B 的消费者可能都不见得能承受这样的产品。而现如今，刚刚推出的 Apollo 两款产品，一个是阿波龙，一个是 L4 小车，都是可以完成量产，这是一个突破，实现则需要渗透到方方面面。也就是说在设计阶段要考虑合理的成本，还要有高能力的配合，然后在具体供货阶段要考虑这些供货必须是市场上稳定的，才是一个稳定有保障的解决方案。

Apollo Pilot MiniBus 和 MicroCar 方案都包括自动驾驶套件、安全保障体系、人机交互方案、量产工具组件、高效运营方案。

自动驾驶套件包括结合车型的硬件方案和软件方案。在安全保障体系中，百度对网络安全、功能安全、验证与测试及风险应对机制等方面进行了全面升级，为自动驾驶量产打造了全生命周期保护。除此之外，百度还提供了智能人机交互方案，为优质和安全的用户体验保驾护航。量产工具组件可以将以往需要工程师实施的高精工作让产线工人大批量高可靠地完成。

最后，杨凡分享了百度对 Apollo 3.0 高效的运营方案。从 OTA 更新和车队管理入手，为用户提供自动驾驶套件及高精地图，对车辆及模块状态进行监控和远程控制、提供站点播报和多媒体内容管理，并开放 API。在未来，量产解决方案将助力合作伙伴实现更高、更强的自动驾驶能力。