Apollo 低成本方案在TX2 平台针对相对地图的优化

张东爱

（北京大学，北京100871）

0 引言

得益于计算机计算性能的大幅提高和人工智能的高速发展，自动驾驶技术在最近的几年内得到快速的发展[1]。无论是传统车企或者大型互联网公司都开始布局自动驾驶的研发。Apollo 是百度公司于2017 年4月推出的开源的自动驾驶软件平台，旨在向汽车行业及自动驾驶领域的合作伙伴提供一个开放、完整、安全的软件平台，帮助合作伙伴结合车辆和硬件系统，快速搭建一套完整的自动驾驶系统。截止到2019 年1 月已发布5 个版本。其中，2018 年4 月发布的Apollo2.5版本中首次引入了相对地图的实现方案，因其使用的地图模式易采集和制作，非常适合于封闭园区和高速场景的低成本自动驾驶方案。相对地图的路线长度依赖于车辆运行场景的道路长度，道路过长势必会导致路线数据的加载和刷新的效率低下，进而影响计算平台的计算效率，可能导致计算平台无法及时处理传感器数据，造成延迟增大，进而影响自动驾驶车辆的安全性和乘坐体验。因此，本文设计了一种Apollo 相对地图的局部加载方案，该方案不依赖于路线长度，能够保证计算平台在任何时间点只计算部分的，等长的路线，从而节省计算资源且保证计算平台的平稳运行。

1 相对地图方案分析

1.1 现状分析

自动驾驶领域遵循的首要目标是安全[2]。为了让自动驾驶车辆比人类驾驶车辆更加安全，车辆需要能够精确地定位，实时地刷新地图数据，快速感知到周围障碍物和障碍物变化，精确预测障碍物的移动轨迹等。为了达到这个目的，要求车辆的计算平台能够低延迟的完成数据输入、算法运算和数据输出等工作。

Apollo 低成本的自动驾驶方案的软件架构可以分为定位、感知、预测、规划、控制、Canbus、相对地图、人机交互界面等主要模块。各模块间数据通讯流程如图1 所示。

在相对地图的加载方案中，将从车辆当前位置到路线终点的数据全部作为前方的路线进行计算，并发布到下游的计算模块。这导致所有依赖地图数据的模块的数据计算量随着路线长度增加而增加。

另外，低成本的自动驾驶方案的计算平台通常选用安全、小巧且价格相对低廉的嵌入式计算机。但是计算性能却远比不上其他昂贵的工控机[3]。

软件架构复杂，数据量大，计算资源紧缺是目前低成本自动驾驶方案的现状。这可能导致计算平台无法及时处理数据，导致车辆的反应延迟增大，进而增加自动驾驶的危险系数和影响乘坐体验。

图1 模块间数据通讯流程

1.2 相对地图的制作

在使用Apollo 的相对地图方案实施自动驾驶的测试前，首先需要确定车辆运行的场景和路线。相对地图中的地图数据是车辆在人工驾驶的状态下录制的一条数据序列，该数据序列经过平滑处理后作为地图输入数据传输给规划模块，规划模块根据地图数据和当前车辆位置规划出一条车辆可以运行的路线，进而控制车辆的自动驾驶。

在确定运行路线后，首先开启Apollo 的定位模块和Canbus 模块，其中定位模块用来收集车辆的位置数据，Canbus 模块用来收集车辆的底盘状态数据。然后由人工驾驶车辆在一个车道内从起点行驶至终点，为了减少路线的不可控状态，行驶过程中应尽量避免换道。每个车道录制一遍即可。录制的数据会实时保存到地图数据包中，该数据包中记录了车辆行驶过程中定位的位置数据和速度。

地图数据包录制完毕后，使用Apollo 提供的工具生成相对地图的指引线数据。指引线中包含了之前车辆在人工驾驶状态下的位置数据，以每行作为单位记录位置数据，并经过了平滑处理，确保点与点之间的平滑过渡。人工驾驶过程中录入的噪声数据，例如车辆的抖动和不规则换道等，在平滑处理阶段会被剔除掉，以确保自动驾驶阶段的平稳性。生成的地图数据是相对于车的车身坐标系。在车身坐标系下，车辆坐标永远在原点，车头方向永远为0。所以，在地图上表现出来的指引线和人工驾驶阶段的路线是十分吻合的。

1.3 相对地图的加载和发布

在生成了相对地图方案的指引线数据后，可以进行车辆的自动驾驶测试。在Apollo 的相对地图实现方案中，将指引线数据加载进内存，以10Hz 的频率将车辆当前位置到路线终点的地图数据发送到规划模块，规划模块以地图数据为路线基础，结合感知模块感知到的障碍物信息、车道线信息和红绿灯信息，结合预测模块对移动的障碍物的移动轨迹预判结果规划出一条可供车辆运行的路线。规划出的路线数据将发送给控制模块，控制模块根据路线数据和车辆的位置、状态计算出车辆运行的方向（方向盘转角）、速度（油门量和刹车量），将控制指令通过Canbus 模块发送给车辆底盘，进而驱动车辆自动的行驶。

地图数据的加载，路线的规划，车辆的控制形成了一个车辆自动驾驶的数据闭环，确保车辆能够按照相对地图的既定路线安全平稳的行驶到终点。

2 相对地图方案运行效率测试

2.1 测试环境

计算平台采用在人工智能领域应用广泛，并且在Apollo 的低成本方案中推荐的一款单模块计算机：NVIDIA Jetson TX2。其主要性能参数如图2 所示。

图2 NVIDIA Jetson TX2主要性能参数

测试环境选择在封闭园区内200 米的路况进行测试。

2.2 主要性能数据表现

以10Hz 的频率，对200 米的内部道路进行测试后，相对地图方案的主要性能表现详见表1。

表1

3 优化方案分析和实施

根据上述的测试数据可以看出，CPU 一直处于高负荷运载的状态[4-5]，导致无法及时地处理传感器数据和检测车辆的异常状态，存在较大的安全隐患。同时，测试过程中，乘坐体验较差，明显感到车辆无法很快地感知到环境变化并快速做出反应。

其中，相对地图模块、规划模块和刷新模块占用了较多的计算资源，存在很大的优化空间[5]。通过对相对地图模块、规划模块和刷新模块的实现分析得知，这三个模块都强依赖于相对地图的地图数据，地图数据越大则需要处理的数据越多，需要处理的时间则越长。所以，减少相对地图的路线长度会减少需要处理的数据量，减轻相对地图模块、规划模块和刷新模块的数据计算压力。

在车辆自动驾驶的数据闭环中，有一个环节是将从车辆当前位置到路线终点的地图数据发送到规划模块。实现方案是读取指引线数据文件的所有行，相对精确地匹配当前车辆位置和指引线中的某一行，将从这一行开始到文件结尾的所有行作为地图数据发送到规划模块。考虑对此环节进行局部加载的优化。即，将从车辆当前位置到车辆前方一段距离的地图数据发送到规划模块。

实施局部加载的优化方案需要额外解决两个问题。

首先是确定预加载路线的距离。指引线数据文件中记录的是车辆在人工驾驶的位置数据，并且已经经过平滑处理，行与行数据之前的方差很小。该位置数据无法准确地量化到距离数据，但是基本上行数越多表示距离越远。所以，局部加载的数据是从车辆当前位置到前方指引线某些行的地图数据。

其次是使加载长度的配置更加便捷。考虑到不同测试环境会需要不同的局部加载方案，为了方便用户的配置和管理，局部加载的行数配置在配置文件中。

将局部加载的方案应用到相对地图方案中后，以200 米的路况为例，每次刷新前方1500 行的地图数据，车辆自动驾驶状态下的主要性能表现详见表2。

表2

可以看出，实施局部加载方案后，模块的CPU 占用率显著的降低，CPU 总体的利用率也显著降低。测试时乘坐体验也得到很大的改善，车辆能够做到对周围环境的快速感知和反应。

4 结语

本文采用的测试路况环境为封闭的园区环境，是众多开发者经常采用的测试环境；软件架构选用了针对低成本园区方案设计的相对地图方案；计算平台选用支持Apollo 运行的低成本计算平台NVIDIA Jetson TX2。在该测试条件下，未实施本文探讨的优化方案前，计算平台的计算资源几乎被全部占用，无法继续进行有效的开发和测试。在实施优化方案后，显著节省了CPU 资源，可以对自动驾驶方案进行更多方面的改进和测试。读者可以在实施优化方案后对自动驾驶的算法，软件架构进行进一步的优化。