关于Apollo3.0 PnC更新以及车辆开放平台的讲解

在本次技术沙龙中，来自Apollo团队计算平台的资深研发工程师-罗琦老师带了关于Apollo3.0 PnC更新以及车辆开放平台的讲解。

这里，我们将整理后的视频资料及内容分享给大家，没能到达现场的开发者可以通过视频和PPT资料来详细了解课程内容。

演讲概要：

安全是自动驾驶前行的保障，尤其是对于 L4 级别的自动驾驶系统，功能安全更是一个全新的领域与挑战。本演讲将分享 Apollo 在功能安全方面的探索。

Apollo3.0 PnC更新以及车辆开放平台介绍

1 Apollo Roadmap

这里分享一下Apollo在3.0里面的相关更新，以及车辆开放平台的一些介绍。

首先为大家介绍下Apollo的Roadmap。今年7月份，Apollo发布了3.0版本，并升级发布了ASU、Hardware Flexibility、Labelled Obstacles。其中在感知模块我们也部署了新的检测方案；而新增加的Guardian-Safety Module是Apollo平台关于功能安全新的尝试；在Monitor也更新了对硬件的检测、软件的功能检测，为了和Guardian系统一起形成一个完整的Functional Safety的尝试；在3.0版本中，我们又接入了新的Sensors——毫米波雷达，以及升级版的Hardware Development Platform。

2Apollo Open Software Platform 更新Guardian & Monitor

首先是 Guardian和Monitor模块。Monitor是状态监控模块，Guardian是在3.0版本中新加入的一个功能模块。这两个模块是开放平台对于Functional Safety和Fault Handling的尝试。

Monitor主要实时监控硬件和软件各个模块的健康状态，比如功能模块——Perception、Prediction、Planning、Control、Roadmap、Localization，同时监测一些信号是否延时，以及是否有收到一些重要的信号。基于此，如果发现一些非正常行为、系统模块报错，就会通知Guardian模块进入安全模式，同时会在Dreamview上通过不同的声音和画面方式提醒驾驶员在10秒钟内需要接管。

之前的Control直接跟CAN Bus模块进行通讯。现在由于接入了 Guardian，在 Guardian下存在两个工作模式。在正常的模式下，Guardian会直接转发Control的Signal到CAN Bus，如果当超声波传感器正常工作并且前方没有检测到障碍物的前提下，尝试在10s内缓缓停车。如果超声波传感器在监测的整个过程中信号没有输出、输出不符合预期或者是Ultrasonic Sensors检测到障碍物，我们会采取紧急措施来防止碰撞。

Relative Map

Relative Map最初是在 Apollo2.5 中发布的，其目的是在一些相对简单的路况上，降低对于高精地图的依赖。在 Apollo 2.0 以及之前的开放版本中，高精地图主要用于3D雷达的监测、2D相机红绿灯监测以及定位模块的多传感器融合和DreamView的显示。这些功能都对高精地图有很强的依赖。在Apollo 2.5中，我们主要依赖摄像头来作为进行障碍物和车道线的监测，同时定位模块主要依赖相对车道线或者GPS定位， 使得我们有机会尝试解耦对于高精地图的高度依赖。

Relative Map是根据周围的环境实时建立的，同时以10hz的频率向外发布，以供预测、规划以及Dreamview使用。有三个不同的工作方式。

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

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

最后一种方案是基于指引线+高精地图模式，这是最精确的解决方案，这样的优点是可以得到最全面和精确的地图定位信息，缺点是部署成本较高。

上面是归纳高精地图在三种模式下的车道应用说明。

Lattice Planner

Lattice Planner一开始在Apollo 2.5时入库，但那时候并没有完全Functional ready，简单来说，Lattice Planner是一种Sample Based Planning的算法，具体的算法为：

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

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

3. 之后，将横纵向的曲线bundle起来形成最终的曲线，根据曲线Bundle后的Cost，从小到大排序，再检查Bundle后的曲线是否符合Gometry Constraint，Comfort Constraint和通过Collision Check。

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

这种方法对比现在的EM Planner来说，优点是在调试性和可理解性上都要容易很多。缺点的话，是跟现有的EM Planner相比，因为轨迹之间是用高阶曲线进行连接，Lattice Planner在特别复杂的条件下表达能力有所欠缺。因此Lattice Planner适合相对比较容易的高速场景以及末端物流场景和园区场景中运行。

这是两种不同的Applications，一种是Relative Map + Lattice Planner在高速场景中的应用，另外一种主要解决方案是HD Map+Lattice Planner在低速物流场景的应用。在Apollo 2.5中Relative Map刚开始发布时主要支持单车道的简单ACC与Lane Keeping，在随后的Apollo 3.0以及以后再次升级了相对地图，以及在此基础上的决策规划与控制的能力，同时提供在Relative Map下的多车道的复杂动作，比如超车与换道。

Fleet Mangement

Fleet Management在第三方平台和云服务平台的之间定义了车辆接口、合作方接口、园区接口、以及起始终点接口。同时，在百度云端服务和车端自动驾驶系统之间，定义了起始点，以及车辆调度指令下发接口和状态收集接口，与量产接口一致，保证了和partner是一套调度接口，方便开发者在此基础上进行开发。

3Open Vehicle Certificate Platform

Open Vehicle Certificate Platform在1.0版本的时候只有一种车型，对于开发者来说选择相对较少。因此在Apollo 3.0当中开放了Open Vehicle Certificate Platform，同时发布了Open Vehicle Certificate Standard，比如把整个的标准跟流程进行发布，更方便不同的开发者快速的把他们相关的能力加入我们的平台中。

Apollo开放认证平台，对于自动驾驶开发者来说更方便、更安全以及更低成本，只需要一套代码就可以支持多种车型，直接进行切换。对于车企和车营商来说，好处在于车辆可以和Apollo平台无缝对接，同时可以接入自动驾驶的开发者，这里我们也希望能够和更多车型、车辆的供应商一起携手建立一套行业标准。

Apollo开放车辆的接口标准主要分为两大部分。首先对于线控系统来说，线控系统会对于功能指标、性能指标、安全指标进行一系列的约定与标准的提出。其次是对于车辆本身的车辆系统，为了支持自动驾驶，我们也对它的功能、性能、安全以及能耗指标制定了一系列约定。

具体来说最常见的刹车和油门，对于它们来说，控制精度、控制力度及这些系统的周期时间、响应时间都有着严格的规定。对于线控系统的安全指标来讲，其中包括指令越界保护和控制的处理，都有着明确约定以及标准化的要求。

对于车辆系统本身，首先希望有相对稳定的CAN通信接口，同时对于这辆车的电源，具体包括电压、功率、最大波动、输出误差都有一系列的规定，能够保证在整个自动驾驶过程中电源输出稳定。

在车辆系统中，我们希望partners能够给我们一些动力学模型，具体来说包括加速动力曲线、刹车动力曲线、以及转向动力曲线。同时，接入的车辆要满足一系列的安全指标，比如车辆碰撞及一些推荐能耗指标，比如车辆排放标准、油耗标准和续航里程标准。

在Apollo 3.0中，我们开放了相关开放车辆的一些工具和文档，这些工具文档包括但并不限于我们的DBC file转化工具，校验工具，以及车辆安全测试工具。同时我们也开放了相关的文档，比如接口需求文档、操作文档，及认证车辆类表。接下来介绍一下整个的车辆操作指南，同时在这个过程中带领大家熟悉一下在Apollo的代码中，我们的接口需求、文档以及各个工具具体的位置以及使用方式。

在一个完整的Open Vehicle Certificate Program的流程里，第一步是Apollo Publish Interface and requirements，这里面包括Interface Documents，也包括我们的Compatible Vehicles，Certification Services以及Apollo Open Source Code，这些都是开始之前预先要做的准备。

第二步是Partners Initiate Process，能够根据接口要求进行自检，并进行一系列的测试，同时我们会相应的提供一些文档和工具的支持。

第三步是一些Process Requirements，以及更多的Tehnical Check和Business Development Process。

第四步是Apollo and Partner Real Vehicle Test。Apollo平台也尽可能提供不同的接口帮助大家完成开发以及对接。首先对于一辆新的vehicle，希望大家在Apollo Github上找到documents，根据流程和文档，和我们开源的demo code和标准，开发者们可以从一个新的车厂DBC file，生成一整系列的code，通过改变很小的一部分code就可以无缝接入我们的Open Vehicle Certificate Program的流程。

期待我们的partner在Open Loop的时候使用一些Verification工具，保证向下的命令可以符合预期。最后开发者应该可以以Apollo 1.0循迹的方式，用新加入的车辆进行Waypoint Following的测试，通过我们在Apollo平台上提供的相关测试标准。

接下来是最后的步骤，首先是Legal Check，将车辆通信协议代码添加到Github上，同时将车辆添加到Apollo车辆平台兼容列表里，就可以完成整个认证流程。