Apollo自动驾驶进阶课（3）—

1.高精度地图与自动驾驶

在SAE的六等级分类方法中，L0级别是人类驾驶，L1到L3级别是辅助驾驶，L3以上是自动驾驶。L3级别以下不需要高精地图，但在L3、L4级别，高精地图是标配。

1.1高精度地图

HD Map （high definition map）高分辨率地图
HAD Map（highly automated driving map）高度自动驾驶地图

高精度地图最显著特点：表征路面特征的精准全面性。
高精度地图精度达到Line级别，描述车道、车道边界线、道路上的交通设施和人行横道等，即把所有东西、所有人能看到的影响交通驾驶行为的特征。
更高的实时性。
高精地图并不是特指精度，它在描述上更加的全面，对实时性的要求更高。

1.2无人驾驶的核心基础模块

高精地图可以作为自动驾驶的“大脑”。“大脑”里面最主要是地图、感知、定位、预测、规划、安全。综合处理成自动驾驶车辆能接受的外部信息，并统一运行在实时的操作系统上。

ROS是业界普遍接受的实时操作系统，百度内部也在研发自己的操作系统。

在2019CES的Apollo 3.5发布会上，Apollo正式发布首个自动驾驶高性能开源计算框架 Cyber RT。
Apollo Cyber RT系统是 Apollo 开源软件平台层的一部分，作为运行时计算框架，处于实时操作系统 (RTOS) 和应用模块之间。
Apollo Cyber RT作为基础平台，支持流畅高效的运行所有应用模块。

车上配备的传感器类似于人的感知系统，用来感知外部环境；自动驾驶车辆会把感知的结果通过「大脑」处理后发送给控制系统。

HMI人机交互接口前期主要用于内部调试，后期当自动驾驶车辆量产后，需要用户输入目的地等信息。

因此，高精地图对于感知、定位、规划、决策、仿真和安全都是不可缺少的。

1.3高精度地图与导航地图

电子导航地图
“有向图”的表述形式，类似百度地图、高德地图、谷歌地图的做法。
只提供方向性引导，根据人的行为习惯来设计的。识别标志牌、入口复杂情况、行人等都由驾驶员完成。

高精地图完全为机器设计的。
右边的图是比较典型的复杂路口，包括人行横道、红绿灯、限速标牌、车道左转右转类型。图中的路口中间有虚拟的连接线，真实道路中并不存在，连接线是为了让车辆更好的去理解环境，并在高精地图上表示出来。通过这一步，在人类构建的交通设施环境下，自动驾驶车辆便能运行。

1.4高精度地图与安全

安全的维度有很多。驾驶算法的稳定性和对场景的处理能力也属于安全范畴。
自动驾驶车辆有很多传感器，联网的自动驾驶车辆可能被攻击。

自动驾驶车辆可能遭受4个维度的攻击：传感器、操作系统、控制系统和通信系统。
传感器是自动驾驶车辆辆上通用的模块，相当于IMU惯性测量单元，它对于磁场是非常敏感。
轮速器也有风险。车轮变形和损坏都会影响测量精度。
激光雷达依赖于激光反射。如果我们在周围环境上加载人工的反射物或假的红绿灯，就会让我们的车直接停下。假的GPS信号和激光也会对系统造成干扰。
定位模块依赖于高精地图提供的信息来做运动学的约束；激光雷达依赖高精地图做一些三维点的扫描。

Apollo提供的定位方案基于激光雷达反射值。反射值不准确就会对定位精度有影响，红绿灯对规划决策控制也有很大的影响。针对任何一种攻击，目前来说，还很难有全面有效的方法来防止问题发生。

高精地图能提供离线的标准信息。比如说，激光雷达在场景中扫描到物体，通过与高精地图中的信息进行对比匹配。如果结果不一致，可以大概率地认为此地有问题，这就是通过多传感器的融合来解决安全问题。

1.5高精度地图与仿真系统

仿真系统是自动驾驶非常重要的模块。

自动驾驶车辆的成本很高。车辆的成本几十万，64线激光雷达的成本在8万美元。实际情况中，开发者很难把所有的策略迭代都放在车上去测试，所以需要非常强大的仿真系统。

仿真的主要问题是「真实」。
Apollo的仿真系统主要是基于高精地图/真实场景来构建。仿真场景回放后，和真实上路的实际情况相比，可以基本保证Gap不会很大。
在实际测试的过程中，Apollo的测试人员也会录一些Bag，记录实测中遇到的一些问题，并放到仿真系统里去做测试。

高精地图为仿真地图提供了最底层的基础结构，能让仿真系统更好的去模拟真实道路的场景。
没有高精地图的高可靠性，L3/L4自动驾驶无法落地。

1.6高精度地图的作用

(1)静态的Perception

上图是几个非常典型的、难理解的场景。
第一是在重庆的某地。路网非常复杂，目前的技术从算法层面无法理解如此复杂的交通场景。
第二个是雪天。雪天是非常难解的场景，雪天时路上的车道线全部被盖住了，不管是基于视觉还是雷达都无法正常运行。
2018年谷歌IO大会上提出了通过深度学习能够解决雪天的场景。在下雪过程中，激光雷达在扫描到雪花之后会误报出很多障碍物，通过深度学习能够把激光雷达上检测到的雪花障碍物过滤掉，最终得到跟没有下雪的场景一样，但是具体效果怎么样，并没有具体的数据披露。
第三个是复杂的红绿灯。

高精地图是静态的Perception。机器理解不了，我们可以把人理解的经验赋予给驾驶系统，相当于把人的经验传授给它。
(2)弥补系统性缺陷
自动驾驶需要非常复杂的计算系统，4G的传输速度并不能满足现阶段自动驾驶的海量数据传输需求。 64线激光雷达、Camera和其他传感器，每时每刻都会产生巨量的数据，这些数据不能传回云端，就不能采用互联网的模式：通过云端计算把结果发送给终端。 5G是否能达到数据传输的要求还需要再验证。目前从5G的宣传层面来看，能够达到数据实时传输的效果，但是5G的普及还需要时间。所以现在把大量的数据都放在终端。

Apollo的自动驾驶车辆后面有非常大的计算单元。基于英特尔工控机，Apollo把所有的计算都放在车上，这会对计算速度和实时性有很大的影响。但是自动驾驶车辆的计算量太大，想要达到实时级的响应，仍需其他模块的辅助。
例如，高精地图告诉感知/控制模块，在双向通行的车道中有栅栏隔离，对向车道的车不可能过来，系统就可以放弃检测对向车道上的障碍物，有效地降低系统负担。

传感器有局限，但高精地图给自动驾驶提供了超视觉、超过传感器边界的远距离感知。

2.高精度地图的采集与生产

2.1采集所需传感器

GPS

空间点位置的计算原理（通过GPS）：
空间点位置是一个三维坐标，有三个变量，需要三个方程。
通过观测三颗卫星与空间点位置的距离，利用三角测量法，就可以准确地得到地球上任何一点的空间位置。但三颗卫星的测量方案在实际应用中，可能会存在误差。因此，在空间点位置的计算过程中，要检测四颗或四颗以上卫星，才能实现精确的定位。

例如，在高速路等非常空旷的地方时，自动驾驶汽车所能接收到的GPS的信号好，不需要复杂的策略，就能得到很好的定位结果。因此，空旷地带的GPS精确、好用。这就是为什么很多公司刚进入自动驾驶领域研发时，都会选择「高速路线」的原因。
而在城市道路环境下，GPS将会非常难用。由于高楼等障碍物遮挡，导致自动驾驶汽车所能接收到的GPS信号发生偏移。一般来说，GPS在城市中定位的「平均偏差」在50米左右。

IMU

目前 IMU （惯性测量单元）是自动驾驶汽车的标配。
IMU是测量三轴加速度的一个装置，通过算出积分，得到任意两帧间的相对运动。
IMU有高端和低端之分。高端IMU能保持较长时间的计算精确度，而低端IMU在GPS信号丢失的情况下，能够维持比较精确的时间非常短。
实际工作中，由于不可避免的各种干扰因素，如果不对该运动加以校正，IMU的误差会就随着时间的推移变得越来越大。

轮速计

轮速计本身存在缺陷。目前，轮速计的使用非常普遍，很多汽车都配备了轮速计。
在现代汽车技术的应用中，轮速计被用来做「运动约束」，如从A点到B点，汽车行驶的距离。
但是由于车型差异、地面交通路况不同，如地面结冰与水泥路面，路况不同，路面的摩擦系数也不一样，就会导致轮速计统计结果的差异。
这是为什么轮速计本身存在缺陷的原因所在。

2.3采集中的制图方案

目前主流的制图方案有基于激光雷达和 Camera融合激光雷达两种方案。

方案一激光雷达

激光雷达通过发射和接收激光光束得到两点之间的距离，因此精确度非常高。

激光雷达内部的扫描部件与光学部件，通过收集反射点与反射点发生的时间和水平角度，从而得出任意一点的空间信息和光强度。该坐标信息扫描的是某个局部，通过一定的坐标转换，能够形成一个全局的坐标系。

无论是GPS，还是IMU、轮速计，各个传感器都存在一定的缺陷，无法仅运用单一的传感器，采集出一个精确的数据。所以要综合运用各种传感器。

通过将GPS、IMU和轮速计测出的数据进行融合，再运用Slam算法，对Pose进行矫正，最终才能得出一个相对精确的Pose。最后把空间信息通过激光雷达扫描出三维点，转换成一个连续的三维结构，从而实现整个空间结构的三维重建。

通过扫描的激光点和GPS、IMU的测量数据综合运用，能够计算出一个预测结果与实际结果最小差距的数值信息。
但这只是在高精地图采集过程中一个最优化的计算模型，实际情况比这个要复杂得多。

方案二 Camera融合激光雷达

激光雷达采集的信息非常精确，但信息少，无法提供像图像那样丰富的语义信息、颜色信息。因此，目前主流自动驾驶研发公司，如百度，采用的是 Camera融合激光雷达的方案。
通过融合二者的优势，综合运用丰富的图像信息和精确的激光雷达数据，最终得出一个非常精确的高精地图。

其他方案

高精地图生产的方案供应商还有：

英伟达 做GPU出身，其计算硬件非常强大。
宽凳科技（国内）用纯视觉制图，精度能做到20厘米，能够通过在线检测实时生成制图。
DeepMotion 运用的也是纯视觉制图方案，其理论精度可达厘米级。
Level 5 公司（国外），运用车载行车记录仪或手机上较低端的Camera就能够实现众包制图，但具体效果还不是很明确。

3.高精度地图的格式规范

3.1分类

高精地图的格式规范，即对采集到的地图如何进行一个完整的表述。
对此，目前最主流的通用格式规范分NDS和OpenDRIVE两种。此外还有日本OMP公司的格式规范。

NDS格式规范

NDS是一种非常全面的地图表述方式，其数据库可以细分且运用了Level两种技术，非常到位。

细分数据库。NDS有上百页格式文档，把数据库做了细分，每个细分后的产品都能够独立更新升级。最典型表现是一个NDS不仅包括基本导航技术数据、B公司的POI数据（即地图上的一个点，地图上每一家商家店铺都可以被称之为一个POI数据点），还支持局部更新，即使是对一个国家或者省市的相关内容进行局部更新，都十分便捷。
NDS还提供语音、经纬度等描述功能。
Level。尺度，类似于传统手机地图功能中的比例尺。通过放大或缩小比例尺，来浏览全国或某个区域、某栋楼的地图信息。
分块技术也被应用到Level中。由于地图的范围非常大，利用Level把整个地图切成小格子，在每个小格子中填充数据。这一规范技术目前在国内尚未普及，国外使用则相对较普遍，特别是宝马等大厂商使用较多。

OpenDRIVE格式规范

OpenDRIVE是目前国际上较通用的一种格式规范，由一家德国公司制定。
百度Apollo中也开发了自己的OpenDRIVE，与德国的OpenDRIVE有所不同。

在运用OpenDRIVE格式规范表述道路时，会涉及一下四个概念：

Section。一条道路可以被切分为很多个Section。按照道路车道数量变化、道路实线和虚线的变化、道路属性的变化的原则来对道路进行切分。无论车道线变少或变多，都是从中间的灰线切分。切分之后的地图分为Section A、Section B和Section C三部分。
Lane。Reference Line在OpenDRIVE规范中非常重要。基于Reference Line，向左表示ID向左递增，向右则递减，是格式规范的标准之一，也是固定的、不可更改的。比如，Reference Line的ID为0，向左是1、2、3，向右是−1、−2、−3。
Junction。是OpenDRIVE格式规范中的路口概念，Junction中包含虚拟路，虚拟路用来连接可通行方向，用红色虚线来表示。
在一张地图中，对路口的表述要用虚拟线来连接道路的可通行方向连，以便无人驾驶车辆明确行进路线。
Tracking。是基于Reference Line和偏移量条件下的应用。Tracking的坐标系是ST，S代表车道Reference Line起点的偏移量，T代表基于Reference Line的横向偏移量。前者是纵向的，后者是横向的。此外，还有一些概念，如Heading、Pitch和Roll等。

在OpenDRIVE里，所有对车道线的描述都基于Reference Line的偏移量。

这个车道线可以通过方程来描述，其他属性如车道线左右的坡度，也可以通过一个基于Reference Line偏移的方程来描述。
这种形式非常复杂，在实际操作中困难重重。

百度在Open Derive格式规范中对该技术进行了改进。

4.业界的高精度地图产品

4.1HERE HD Live Map

HERE最早是诺基亚旗下的一家公司，被诺基亚作为自己的高精地图使用，早起在欧美地区大概有80%的市场占有量。
在2013年微软收购诺基亚时，并未一并收购HERE，之后在2015年，HERE被宝马、奥迪、戴姆勒以30亿美金收购，再后来几经周折，被腾讯、四维相继入股。
HERE做地图之间长久，经历了由导航地图到高精地图的发展，整个体系相对完善。

HERE已能把地图做成一种基于云端的服务，精度高更新快。

特征

基础地图设计，是高清实时地图的基础。采集车辆配有GPS、激光雷达、相机等，每天采集28T的数据量，精度可达厘米。基于激光雷达、相机，建立16线程的Base Map。
众包更新（基于图像），利用众包车辆传感器采集行车路径、车道标志、道路边缘、路标、路面标志等。结合卫星图像等多种数据源，保持高清地图的新鲜感。
在云计算中映射学习，车辆大小、传感器设置和行驶路径不同。这些变化导致许多观察到的路边物体是相同的。这里的机器学习将这些变化的传感器数据聚合起来，以确定路边工件的精确位置。
更新地图，创建并添加到地图数据库后，在这里将其发布到HD Live地图，并将必要的平面图发送回车辆，以便车辆能够准确和实时地表示路网。

Map Collection

HERE采集车，集成了16线激光雷达+ Camera + RTK天线+IMU。
HERE采集车会对地图进行预先制作，在数据采集后进行数据统计，经人工识别检查后，最后更新在地图中。

Crowdsourced Update

HERE地图采集的众包，可以做到非常高频的更新。
车端通过Sensor进行信息采集（可认为一种视觉方案），可对点、道路、标志标牌通过Feature进行提取，可有效帮助我们更快的对地图进行更新。
HERE有很好基础优势。作为一家传统图商，他的用户基数可以保证地图以更快的速度和形式更新。

Learning

不同于利用神经网络的图像处理方法，HERE利用点云分割技术对Features进行分析。
在多次采集后，可将同一区域的点云补齐，但目前的图像处理方法已较为成熟。
而点云技术（点云SLAM、点云分割、点云特征提取等）仍需完善发展。

Product

HERE对地图做了4个分层结构：

第一层是Road & Lane Model Layer（车道边界和区分界线）A highly precise representation of road network.
第二层是Localization Model Layer（基于Camera或点云）Help a vehicle to find its exact Position of lane it is driving in.
第三层是Activity Layer（动态信息层、道路实时信息）Understanding dynamic events in the road network.
第四层是Analytics Layer（司机驾驶习惯分析）Tell how humans actually behave in a piece of road.

在HERE的解决方案中，可以通过检测与定位约束纵向行驶信息，车道线约束横向行驶信息。

4.2MobileEye

MobileEye号称为全球25家知名车厂合作商提供更安全的技术解决方案，有2500万车辆在使用他们的技术，13家车厂正在使用MobileEye的技术在攻关自动驾驶。
相比于HERE，MobileEye更侧重于使用Camera，在图像处理方面也做得更好，使用视觉信息来进行辅助驾驶，是一种基于众包的视觉制图。

Pillars of Autonomous Driving

MobileEye技术的三个层次：

感知
Mobileye的软件可以进行传感器融合——从摄像机传感器、雷达和激光雷达传感器中解读数据。
在图像处理方面，Mobileye经验丰富，使用独有算法是用来检测对象，确保安全行驶和系统决策。L3以上取决于使用的是基于Lidar还是Camera的方案了。
映射
自动驾驶汽车需要大量的系统冗余处理无法预料的情况。在所有条件下，车辆相对于道路边界和交叉口的精确定位都需要高精地图。
Mobileye提供基于REM的框架(REM™)，使用众包的策略。让用户能低成本地构建和快速更新高清地图。
驾驶策略
在Mobileye的驾驶策略中，自动驾驶汽车能够感知周围的场景并在地图上进行定位，接下来就是学习和共享人类司机的驾驶策略。
Mobileye声称，传感、测绘和强大的计算能力赋予了自动驾驶车辆超人的视觉和反应时间。Mobileye对驾驶策略的强化学习，将提供多变量情况的分析方案，并且尽可能地逼近人类的行为和判断方式。
这证明Mobileye对于复制人类的驾驶行为还是很看重的，至少把其单独地作为一个数据层去阐述处理。

Map as back-up sensors

说到Mobileye，要重点提及的就有他们的制图方案。
Mobileye的众包流程方案: 收集数据——上传云端——处理——下发车端,这和HERE类似，只不过他们的方案更多是基于视觉来做。

Mobileye的REM系统（道路经验管理系统）非常知名，提供实时匿名众包的汽车数据，用于高精度地图的制作和使用。
Mobileye的REM解决方案由三层组成：

采集器（任何装有摄影机的车辆）；
云端；
自动驾驶车辆。
相比HERE来说，MobilEye基于视觉的方案，缺点是就是道路线的判断不连续。这会造成没有车道线了，车辆不知道怎么走了。
在复杂道路中，一旦出现红路灯等难以识别的物体，MobilEye所推崇的单靠视觉信息的解决方案难以支撑全自动驾驶技术。

RoadBook

MobilEye把REM采集、发送云端、处理、发回车端的过程称为“路书”。

搭载MobilEye的车端首先会对环境进行识别，然后进行语义分析和几何形状提取，将其压缩后打包上传，这个过程称为RSD。
经过REM系统采集处理的RSDs，其数据包大小可以达到10k/1公里，并达到“高精度低延时”的效果。

MobilEye还会将不同路段的数据打断上传。
这就是MobilEye的众包方案：所有的数据都在云端，所有人贡献相关数据，并且获得更好（高精度低延时）的数据回馈。
正是由于激光雷达的解决方案存在诸多的限制：高成本、低规模化和点云算法尚不完善。在现行的网络条件下，MobilEye的RSD方案“至少”看起来让自动驾驶这件事儿变得更加可行了。

在更复杂的环境中，其解决方案还是存在局限性。

4.3Google Waymo

谷歌业内知名，但是其对外披露的信息极少。

谷歌的地图解决方案中，谷歌将地图提供的静态环境和基于感知的动态环境（人物、车辆、道路标志）等信息结合在一起，使搭载Waymo的无人车完成对环境的感知。将红绿灯感知为框体，并且将人行横道的识别放在非常重要的位置。将根据地图提供的静态信息确定红绿灯的位置，基于感知到的红路灯状态为其打上标签（红灯禁止或者是绿灯通行），再为车辆决策提供依据，并且有蓝色的预测轨迹为车辆规划行驶路径。

在谷歌对于高精地图的阐述中认为，仅有矢量数据是不够的，更期待自己能够研发出栅格式的高精地图。
这种地图记录了所有道路上的物体信息，并且将不存于静态地图中的动态物体自动过滤，由此降低车端感知识别的难度，达到更好的检测效果。
至于谷歌所透露出来的环境地图，其红绿灯和停止线的设置，跟业界的标准基本一致。

谷歌Waymo的实验车顶部可能搭载了激光雷达+视觉系统，车辆四周搭载了激光雷达。其整体方案也是为激光雷达+视觉融合。
但是谷歌自研的激光雷达据称可以检测到两个足球场（240米）外的物体数据。并且整体的生产成本比Velodyne的64线激光雷达的售价（8万美元）低90%左右，这对于开发者来说是非常诱人的价格。

5.Apollo地图采集方案

TomTom的高精度地图和RoadDNA

TomTom NV是一家主营业务为地图、导航和GPS设备的荷兰公司，总部位于阿姆斯特丹，在静态地图方面有多年的开发经验。早在2015年，TomTom的移动测量车队就已实现相当程度的自动化数据采集。
TomTom的移动测量车队通过配备有1台Velodyne激光雷达相机、1台360度全景相机、2台SICK雷达和兼容GPS/GLONASS的高精度天线的福特翼虎，让驾驶员可以独自完成采集任务。

能否保证地图的即时和精准，是衡量一个图商专业性的重要依据。TomTom选择通过前装的方式完成“众包”工作。
在线路径规划技术方面，TomTom利用云端处理能力，RoadDNA定位方案，快速制定并向车载导航系统发送备用的行驶路径。
集合电动车服务，TomTom还可为驾驶员提供其车辆电量耗尽前所能行驶的距离信息，并为其规划最高效的行驶路径，在恰当的时机提供实用的服务。
RoadDNA的技术原理是通过将原本的3D地图数据转换成2D视图，在对地图数据进行压缩的同时，还能保留道路上的关键要素，进行对比定位。从而达到节省空间，使自动驾驶汽车对道路信息的处理速度更快的目的。

18年11月，TomTom牵手百度推出了全新地图服务AutoStream。
AutoStream是一套针对地图更新机制开发的数据传输软件。车厂开放接口后，车辆可在行驶过程中把其感测到的相关地理信息，通过地图引擎的传输单元上传到云端，AutoStream在编译解读道路数据后再回传给汽车，最终完成高精地图实时更新工作。

5.1采集方案

该方案的基础传感器配置有：平装的64线激光雷达，用于道路路面采集。
由于平装的64线激光雷达扫描高度比较低，还需要一个斜向上装的16线激光雷达，用于检测较高处的红绿灯、标牌等信息。
该方案的其他传感器还有GPS、IMU、长焦相机以及短焦相机。

基站搭建

百度采用的GPS传感器并非一个单纯的GPS，而采用的是RTK的方案。RTK相较于单纯的GPS，能提供更高的精度。
地面上建立的观测站一般会选择在开阔无遮挡的楼顶，这样能保证观测信号良好。

在RTK方案中，观测站通过长时间在某个位置不断地进行定点观测卫星、观测计算，是一个静态的观测站点。而无人车相当于一个动态的站点，通过车辆移动监测卫星信号。

GPS在传输过程中，可能会受到多径效应、电离层大气层、反射折射等各种元素的影响。但一定范围内的不同基站，受到的影响相对一致。
基于该原理，RTK方案通过观测站之间载波信号的差分就可以得到厘米级的定位效果。
RTK方案需要基站在无遮挡的情况下，才能提供非常准确的位置。
但车辆在城市中行驶，容易受到高楼的遮挡，采集到的数据会受影响。

采集硬件方案

进行地图采集的两个先决条件：

传感器工作状态正常。
在Apollo提供的地图采集页面中，左侧有监控传感器状态的图标。采集过程中，首先要看左侧各个传感器图标的状态，绿色表示状态正常，红色或黄色表示传感器出现问题了。如果出现状态不对，开发者可以检查传感器的线是否松了，或有其他状况。
传感器已被标定。
Camera内部参数和外部参数不一致，会导致采集的数据不准确，从而作废。相应的，不同厂家生产的激光雷达，其参数设定也会不一致。
同一厂家生产的激光雷达，参数设定一致时，采集的数据可能有效；不同厂家生产的激光雷达，由于地面点反射值不一样，参数设定不一样，就会导致数据采集出现偏差。
因此，Camera和激光雷达都需要被标定。

采集过程中，无人车需要双向车道全覆盖3—5遍，最好是5遍。
如果车辆搭载64线激光雷达，那么完成地图采集目标所需要的全覆盖圈数可以减少。16线激光雷达则需要跑更多圈，才会得到更为精准有效的数据。

Apollo地图采集对车速并无明确要求，但为确保采集效果，时速低于60千米为宜。
Apollo采集路口红绿灯时使用的是Riegl传感器。在路口采集时，不需要将车停下来进行静态扫描。这种行为本身十分危险并且违反交通法规。车载Riegl可以保持在正常行驶状态下，就能够采集到路口红绿灯的信息。

一次采集行为完成后，所有的结果会形成数据包。其中包含点云、车辆标定参数、定位结果等信息。

地图数据服务平台

Apollo地图数据服务平台提供包括数据管理体系、制图任务创建、制图进度跟踪和制图结果下载等服务。
开发者可将采集到的数据提供给Apollo，由Apollo来进行后续系列制图服务。
制图过程是离线的，百度对Pose做校正和视觉图像处理，完成最终的制图后，会将全套地图提供给开发者。

5.2生产技术

在城市道路环境下，高精地图生产分为数据采集、数据处理、元素识别、人工验证四个环节。

（1）数据采集

百度采取的是激光雷达和Camera二者相结合的制图方案。

Apollo2.5版本中，百度已经发布了其地图采集方案。
该方案的基础传感器配置有：平装的64线激光雷达和16线激光雷达。
其中，64线激光雷达用于道路路面采集。由于其扫描高度比较低，还需要一个斜向上装的16线激光雷达，用于检测较高处的红绿灯、标牌等信息。
其他传感器有GPS、IMU、长焦相机以及短焦相机。

（2）数据处理

传感器采集到的数据分为点云和图像两大类。
L4级自动驾驶汽车对地图的精度要求非常高。Apollo在制图过程中处理的数据也以点云为主。

采用RTK的先决条件，即在开阔无遮挡的情况下，才能取得相对准确的信号。因此，在获取点云之后需要对其进行拼接处理。
点云拼接：采集过程中出现信号不稳定时，需借助SLAM或其他方案，对Pose进行优化，才能将点云信息拼接，并形成一个完整的点云信息。
反射地图：点云拼接后，可将其压缩成可做标注、高度精确的反射地图，甚至基于反射地图来绘制高清地图。其生产过程与定位地图的制图方式一样。

（3）元素识别

bai元素识别包括基于深度学习的元素识别和基于深度学习的点云分类。

基于点云压缩成的图像进行车道线的识别，得出准确的车道线级别的道路形状特征。另外还需要提炼道路的虚实线、黄白线、路牌标识等，来完善道路特征。
通过对收集到的图像等进行深度学习，即可提炼出道路相关元素放到高精地图中。

数据采集、数据处理、元素识别三个流程是高精地图自动化的必要环节但是自动化仍无法解决所有问题，存在信息补齐和逻辑关联的缺陷。
一方面，无人驾驶车辆无法处理没有车道线的道路。这一步需要离线并用人工手段补齐相关信息。
其次，涉及到逻辑信息的处理时，无人车无法判断。例如在某一路口遭遇红绿灯时，车端应该识别哪个交通信号灯，也需要人工手段关联停止线与红绿灯。

（4）人工验证

人工验证的环节包括识别车道线是否正确、对信号灯、标志牌进行逻辑处理、路口虚拟道路逻辑线的生成等。

全自动数据融合加工

百度高精地图依托模式识别、深度学习、三维重建、点云信息处理等世界领先的技术，其数据自动化处理程度已达到90%，相对精度达0.1-0.2米，准确率高达95%以上。
简单的说，采集到的这些每秒 10 帧左右的图像，识别和融合都是自动化的。把 GPS、点云、图像等数据叠加到一起后，将进行道路标线、路沿、路牌、交通标志等等道路元素的识别。
另外，诸如同一条道路上下行双向采集之后造成的数据重复问题，也会在这一步里被自动整合，剔除重复内容。

目前百度对于城市复杂场景及环境的制图效果较好，可以精细刻画上百种道路要素和属性。

基于深度学习的地图要素识别

地图要素的识别包含两个层面：

第一个层面，能否根据点云分割从中提取精确的Feature。
第二个层面，尝试从点云中提取车道线、灯杆、红绿灯。如灯杆可以用来做视觉定位的Feature。

人工验证生产

百度把高精度地图制作分为外业和内业两部分，共三个步骤，分别是外采、后台数据化处理、人工验证以及发布。
因为自动化处理不可能做到百分之百的准确，所以得再进行一轮人工验证。验证人员从云端下载需要验证的路段数据，然后把自动处理之后的高精度地图数据和对应位置的图像信息作比对，找出错误的地方并进行更正。每人/天修正的数据量在 30-50 公里左右。
修正后的数据不会保存在本地，而是需要上传到云端。最终的高精度地图成品，也会通过云平台进行下发。
高精地图是基于反射地图生产的。通过融合底图数据、图像数据、点云数据，整合生成高精地图数据，将可形成一份相对完整精确的自动驾驶地图数据。

地图成果

目前Apollo高精地图主要应用在高精定位、环境感知、决策规划、仿真运行四大场景。
定位地图类似于整齐排列的小格子，存储了坐标信息和反射强度信息等，用于点云定位。
点云定位是Apollo中的一个定位方案，在高精地图各个模块都会应用到。
路径规划地图主要用于车道级别规划。
仿真地图主要用于基于高精地图的仿真。

5.3Apollo高精度地图

表征元素

Apollo高精地图能够表征的元素包括：

道路，包括左边界右边界。分为两个层次：道路级别和Lane(车道)级别。
每个Lane都有左边、右边界；道路也有道路边界，是强约束，即自动驾驶的时候，道路边界是永远不能压的。车道线理只有在紧急情况下可以压，比如说可以越过虚黄线进行借道超车。
路口，一个相对复杂的场景，可以细分为路口边界和虚拟车道。路口边界主要用于感知。可以通过路口的边界，对感知进行过滤。如果感知识别到的静态物体不在地图的路口边界之内，可以暂时忽略。虚拟车道主要是用来路口的行驶引导。
交通信号灯，分为红绿灯和其他道路标志。高精地图会为红绿灯提供一个三维空间位置，其次也会提供红绿灯跟车道之间的关联关系，即告知当前所在车道，应该看哪个灯。
道路标志主要包括人行横道，停止线以及一些路上的文字信息。这些信息可以用于各个模块，例如感知、PNC等。
逻辑关系表述，当前，地图中各个元素之间的关系并没有嵌入到元素的表述中，而是使用overlap来表述两个元素之间的关系。
Overlap主要是用来描述两个元素的空间关系。Lane和Junction在空间上有重叠，它们之间就会有Overlap。

Apollo车道模型

Apollo的车道模型及其相关描述元素与openDRIVE大致的规则是一样的，把纵向切成Section，横向还是使用Lane分割。

该车道模型包含了很多元素属性。Left road_sample主要用来描述中心线到两个边界的距离，该边界指的是车道线边界。Left road sample和Right road sample主要用来表述车道中心线到道路的物理边界的距离。

路口表述：路口分为真实路口和十字路口。
实践过程中，在车道数变化的时候需要感知周围有没有车辆，Apollo高精地图里面也把这种情况处理成一个路口。Junction边界能够给感知提供一个检测的约束。这也是In road和Cross road的区别。

UTM坐标系

UTM坐标系把全球分成60个区域带（Zone），每个Zone里面都是相当于Zone中心的一个局部坐标系，如上所示。
UTM坐标系描述的位置十分精确。目前，Apollo内部主要采用UTM坐标系。

84坐标系

84坐标系是一套全球经纬度，也是高精地图里面使用的坐标系。
在该坐标系中，把整个地球想象成是一个椭球，地面的高度是相对于椭球面的一个偏移。高由正数表示，低由负数表示。

Track坐标系

Track坐标系是基于st的，如上图所示。s是纵向，t是横向。这个坐标系用来表述一个元素跟Lane之间关系，描述它位于Lane的什么位置，相对于Lane起点的偏移量是多少。

Apollo openDRIVE规范

Apollo OpenDRIVE把所有元素做了归类。
类似于Road和Junction。路上的所有的地面标识都归属为Objects，所有的标牌都归属为Signal，并通过Overlap把它们关联起来。
Apollo的OpenDRIVE相对于标准OpenDRIVE的改动：

元素形状的表达方式。
标准OpenDRIVE是基于参考线加偏移，并采用方程来描述。
Apollo OpenDRIVE采用绝对坐标点序列描述边界形状。坐标点的方式，数据量会稍大。
好处：用点表示对于下游的计算非常友好，不需要再重新通过线去做点的采样；在道路急于转弯的地方，原始的OpenDRIVE把基于Reference Line的方式还原成点的方式，会导致道路上存在毛刺，会导致无人驾驶车猛打方向盘。
元素类型的扩展。
比如增加了禁停区，人行横道、减速带等元素的描述。
扩展了元素之间相互关系的描述。
比如新增了Junction与Junction内元素的关联关系。
增加了诸如停止线与红绿灯的关联关系，中心线到边界的距离等的描述。

HDMAP引擎

HDMAP引擎是Apollo里面用于从HDMAP里面提取相关元素给下游的一个模块。

HDMAP 引擎可以通过ID去检索一个元素，也可以通过空间位置查找元素，比如给定一个点和半径，可以把这个范围之内所有的红绿灯都提出来。

在国内，采集地图属于国家机密事项。采集地图，必须要经过国家测绘部门/安全部门的审批。
同时，测绘得到的数据需要进行加密。高程、曲率、坡度等在高精地图里面是不允许表述的，但这些数据对于无人驾驶又是必须的。如何在符合国家安全要求和技术需求之间找到平衡，这仍是自动驾驶发展所需要正视、解决的问题。