Apollo自动驾驶进阶课（2）——Apollo开源模块
1.无人驾驶车
这一部分相当于对入门课程（1）无人驾驶概览的补充。
无人驾驶对安全精度和各种复杂技术的集成程度要求非常高
无人驾驶车一定是线控车。线控（by-wire），就是被电脑控制。
为了保证无人驾驶车的安全性，当它在路上行驶的时候，必须做到它跟云端是有连接的。无人驾驶车并不需要时时跟云端汇报接下来会如何处理，而是要告诉云端它的位置以及行驶规划。
1.1高精度地图
高精度地图对于无人车的非同寻常的价值：
- 高精度地图能够给无人车很多预判的空间。 当无人车通过高精度地图知道前方的路况和交通标识信息后，能够提前做行驶规划，保证了行车的平稳性和经济性。
- 高精地图能够帮助无人车减少计算量。 当无人车需要通过路口时，需要提前感知前方信号灯的状态，这时高精地图就可以帮助它定位到信号灯所在的特定区域，从而有效降低了全范围扫描识别的计算量。
- 减少无人车对静态障碍物的算法处理。 高精地图将道路及周围的所有静态障碍物进行收集。
1.2定位
GPS定位
- GPS定位原理是相对定位。
- GPS定位是有误差的，精度只能达到米级。（由于电离层和反射作用等因素的干扰）
- GPS定位是跳动的。GPS定位是时刻根据当前的时间去算的，容易出现计算结果不准的情况。为了抹平GPS的跳变，需要用到IMU（惯性导航），一般来说GPS和IMU是一块用的，GPS不停的去给IMU一个方向去校准，然后IMU再给GPS一个方向。
- 无人车在接收不到GPS信号的情况下，需要用到另一个技术——几何定位。
几何定位
几何定位的原理和GPS原理类似。在道路上选几个feature，根据这些feature计算无人车所在的位置。
几何定位的精度很高，可以精确地算出无人车所在的位置。
目前比较流行的定位技术就是GPS、IMU和几何定位等一系列技术的融合。
RTK技术
RTK技术是为了提高GPS的精度高达10厘米。
RTK是一个静止站，接收卫星信号。无人车与RTK相隔不太远的情况下，对二者之间的干扰信号用差分抹平，就可以认为无人车和RTK收到的信号是一样的。
RTK技术的限制是，要求基站与车的距离在16公里以内。
1.3感知
摄像头
Camera，主要优点是辨别颜色，对信号灯和交通标识等进行颜色识别；但缺乏对距离的判断能力。
雷达
Radar，利用电磁波探测目标。雷达发射电磁波对目标进行照射并接收其回波，由此获得目标至电磁波发射点的距离、距离变化率（径向速度）、方位、高度等信息。雷达对速度的判断尤其准，但对静态物体的误报较多。
雷达的应用场景是全天候的，由于电磁波可以绕过一些东西，所以准确性并不太高。
激光雷达
Lidar，以发射激光束探测目标的位置、速度等特征量。
工作原理：向目标发射探测信号，然后将接收到的从目标反射回来的信号与发射信号进行比较，作适当处理后，就可获得目标的有关信息。
激光雷达的最大优点是对距离的判断非常精准；
缺点是对环境的要求非常高，比如在雾霾天气里激光雷达的精准度就会降低很多。价格昂贵，种类繁多。
无人车上不停旋转的Lidar，是机械雷达。需要不停旋转，本身也又大又重，机械损耗较大，容易出现问题。基于机械雷达的新的激光雷达，比如MEMS lidar、flash lidar等。
传感器融合，就是要把所有传感器看到的信息综合在一起，这样无人车就能够更加全面具体地感知外界环境。
1.4规划
无人车在约束条件之下（避让、停止、超车），规划出一条可行路线。
无人车的轨迹规划：
- 一是要满足所有的约束条件。
- 二是要保证车辆运动的平滑。所谓平滑，是要保证车子的速度不能跳变。
- 加速度平滑。
- 最终目的是，在人类可感知的范围，车子行驶是顺畅的，没有不平滑不顺的情况。
1.5控制
实现对无人车的控制，需要知道踩刹车和减速的关系、踩油门和加速的关系等，当无人车拿到一些控制学参数后，就可以实现电脑对无人车的控制。
1.6云端
百度在云端后台有个巨大的仿真空间，每一辆无人车可以将自己遇到的复杂路况上传到云端，因此网上就有了一个非常大的数据库。
当无人驾驶的算法有更新时，就可以在云端的仿真场景中跑一下，检验是否能够应对云端的这些路况。这个步骤，就是为了确保每个无人车都称得上是“有经验的司机”。
2.ISO-26262
2.1概述
安全方面最基础的一个模块ISO-26262。
ISO-26262是一个非常复杂、非常结构化的标准。比如说，如果一个硬件达到了ASIL D级别的要求，那么它的故障率是10 fit （Failures In Time, in one billion device-hours of operation），即10亿个小时里面出一次故障。这个故障率要比windows蓝屏的概率低很多。
ISO-26262是一个行业规范而不是一个例法，只覆盖Safety，不覆盖Security。Safety包含两个方面：
- 系统性故障 Systematic Faults 。在设计汽车的时候就存在的缺陷。每次运行的时候，都一定会发现问题。软件和硬件都有可能存在系统性故障。
- 随机故障 Random Faults 。由不可控的因素造成的故障，不一定会出现。一般情况下，只有硬件会出现随机故障。
Security涉及的不是车自身的问题，而是系统被攻占的问题。有了无人驾驶技术以后，车总是和网络相连，让车变得特别容易被攻击。
2.2认证流程
通过ISO-26262的认证是一个特别慎重的流程。
- 首先，明确车具备哪些功能以及这些功能由哪些零部件完成。
- 其次，考虑对于车的每个功能是否会出现故障，一旦出现问题是什么级别的问题。
有两种问题，例如做车的加速系统：一种问题是车在人没有意识的情况下加速了。另一种是，需要车加速的时候它没有加速。需要把这些问题放到具体的情景中去考虑最严重的问题是哪一种，对于判断一个问题是否严重，ISO-26262给了三个判断标准：
- Separately是指车和人分离，出事故后有多少概率会造成人员伤亡。
- Exposure是指这件事情是否常见。
- Controllable是指车出现了问题，驾驶员是否有机会接管。
ISO-26262的认证过程是一个“V型”。首先要看是什么开发环境，其次要分析问题的等级是怎么样的。如果是一个很高的等级需要判断这个问题出现的概率有多大。然后考虑这个问题具体要怎么解决。也就是先做High Level层级的，再到Function层级，然后到Technique层级。
Technique层级涉及软件和硬件。软件硬件确保了安全性后，再返回往上去做验证。对于ISO-26262更高级别的要求，它会要求有很多Redundant system。如果现行的系统坏了，下面还有一套系统。如果出现问题，另外这个系统具备使它停下来的机制。
2.3优缺点
ISO-26262代表了汽车行业在安全方面可以做到的极限，在汽车行业有很高的威望。
- 首先，它是对技术的一个引导。毋庸置疑它会使车更加安全。
- 其次，它有很高的商业附加值。通过这个认证最多的车是德系车，德系车价格远高于同行。
- 第三，它涉及法律中权责的问题。
汽车行业是一个复杂的行业。车厂要把汽车组装起来，需要对供应商提各种各样的要求。一旦汽车出现了安全问题，供应硬件零件如果符合安全要求，车厂就要承担责任。而汽车的召回一般都是十亿美金这个量级的。所以这个认证它虽然不是法律，但它在打官司的时候特别有用。
- 它的认证过程很繁杂（Very Heavy Process)，不符合敏捷开发的需求。ISO-26262一定是每一层的文档都准备完毕，才可以做下一层。
（做一个APP可能以月计迭代都算慢的，但是做车可能需要十年的规划，我们现在开的车可能就是他们十年前规划出来的。）
3.Apollo平台技术框架
百度Apollo的技术框架包括四层：线控车辆平台（Reference Vehicle Platform）、参考硬件平台（Reference Hardware Platform）、软件开放平台（Open Software Platform）、云端服务平台（Cloud Service Platform）。
- 线控车辆平台（Reference Vehicle Platform），最底层，所有的东西都需要装载在线控车辆上才可以跑起来。
- 参考硬件平台（Reference Hardware Platform），里面包含一个计算平台（computing unit）用于计算传感器传递的各类信息，例如英伟达的芯片Drive PX。这一层还包含各种传感器。例如：Camera摄像头、lidar、radar、GPS mu等。
之所以需要各种不同的传感器，是因为它们的波长和感知范围不同。像Radar毫米波雷达，可以穿透毫米级别的障碍物。Lidar是一种纳米级别的激光波，现在比较流行的有两种：905纳米和1550纳米。1550纳米由于其波长与可见光相差的更远，对眼睛伤害更小，所以我们通常把它的功率调的比较大。相比905纳米，1550纳米可以打得更远，价格也更贵。
除了计算单元和各类传感器之外，硬件平台还包括用于人机交互的HMI Device和用于记录信息、技术迭代的黑匣子。 - 软件开放平台（Open Software Platform），这整块是开源的，可以在Github上看到。它们实际是在一个实时操作系统上运行，可以看作一个操作系统的底层框架加一个消息的分发机制。软件开放平台还包括map engine，定位、感知、规划、控制等技术模块。
- 云端服务平台（Cloud Service Platform），最上一层，车在路上跑需要和云端有一定的交互，云端计算出模型再把它下发到车上。
所以云端包含这些服务：HD Map，百度子公司有采集地图的资质。Simulation，帮助我们理解路况。此外还有，Data Platform、Security、OTA、DuerOS。
Apollo版本迭代
2017年7月发布Apollo 1.0 循迹自动驾驶。
所谓循迹自动驾驶就是人开一段，然后车记录下人开的轨迹，再沿着这个轨迹不停的回放。Apollo 1.0典型的代表是农用机器人——阿波牛。在Apollo 1.0里不需要camera，也不需要Sensor，只需要一个GPS。也不需要做规划，有精准的定位就行。Apollo 1.0在内部用的时候，只是用来测量车的线控系统是否完备、运动学参数是否匹配。
2017年9月发布了Apollo 1.5 固定车道自动驾驶。
所谓固定车道自动驾驶，就是指在不变道的情况下处理一个车道内的所有行为，比如跟车、在车道内行进等。1.5版本有很多技术进步，加上了Lidar、Map、Perception、Planning等。基于Apollo 1.5也有合作伙伴，比如专门为老年人或残障人士设计的漫步车。
Apollo 2.0 简单城市道路自动驾驶。Apollo 2.0 几乎把所有的模块都点亮了，我们加入了Camera、Radar、Security、OTA等。
到2.5版本的时候，Apollo已经成长为全球最大最活跃的无人驾驶社区了。
长沙智能研究院结合 Apollo 2.5 限定区域高速自动驾驶发布了高速物流卡车自动驾驶解决方案。
最近发布的Apollo 3.0是一个里程碑式的进步。
加入了量产解决方案。Apollo 3.0相当于迈出了商业应用的一步。虽然场景只限定在园区内，但自动接驳小巴、自主泊车这些确实都是通过量产的方式进行的。
在Apollo 3.0我们除了量产解决方案之外，同时还发布了量产安全套件、量产解决方案套件，可以让开发者自行配置。
同时把硬件开发平台和车辆运行平台进行了升级，只要符合要求都可以进入。这样接入Apollo的成本会大大降低，开发者也会有更多的选择。
4.Apollo硬件开发平台
Uber事故原因分析
2018年3月18日晚间，一辆正在进行无人驾驶测试的Uber车在美国亚利桑那州Tempe市撞上一名行人。该行人被送医，随后被宣告抢救无效死亡。
根据初步调查结果，Uber车辆在撞上该名行人时，正处在自动驾驶状态，这是史上首例自动驾驶车辆在公开路面撞伤行人致死的案例。此事件，对无人驾驶敲响关于安全的警钟。
2018年6月22日美国公路委员会发布事故报告：在事故发生的前6秒，系统的传感器已经发现行人；在事故发生的前1秒，原车的应急制动AEB已经启动，但汽车并没有实施制动，原因是Uber在改装沃尔沃cx90时，对原车的刹车系统进行截断，由后续改装的电脑来发射控制指令，进行刹车。
- 系统没有一个完全闭环的状态（主因）；
- 交互设计缺陷，驾驶员低头在玩手机，系统检测到行人后没有发出警告；
- 自动驾驶和基础设施是相关的，事故发生前4秒路面的照明不足导致从照片上看不出行人。
Uber之前还发生过其他交通问题，比如车辆剐蹭，直接侧翻等。
原因在于，Uber后来加装的车辆传感器（Velodyne 64线）比较重，并且SUV中心点较高，加装传感器后重心上移，转急弯时容易侧翻。
4.1安全
自动驾驶的第一天条。
从自动驾驶研发的流程角度看，大致可以分为以下4个步骤：
- 软件在环 软件在环是基于仿真和模拟的软件仿真，类似于赛车类游戏。即是在软件系统里仿真模拟出真实的道路环境如光照、天气等自然环境，开发者可将自动驾驶代码开发完毕后，在仿真系统内运行，测试是否可以实现目标。
- 硬件在环 硬件在环是基于必要的硬件平台。在第一步的软件仿真结束后，将所有的仿真结果与传感器、计算单元集合在一起，在硬件环境里测试。
- 车辆在环 车辆在环是基于车辆执行。在第二步硬件环境里测试完成后实施的第三步，即在一个封闭环境中测试开发者所开发功能，封闭环境中不会有交通流的干扰。
- 司机在环 司机在环是基于实际道路。在第三步测试成功后进入到司机在环，司机在环主要是研究人——车——路——交通四者之间的相互作用，它不仅测试自动驾驶的程序代码，还能获得专业司机的评判。
4.2自动驾驶汽车的硬件系统
自动驾驶分为三大系统：感知、决策和控制，每个系统里有对应的硬件系统。
感知系统分为三部分：
- 车辆运动主要分为惯性导航、速度传感器、角度传感器和全球定位系统。
- 环境感知主要分为激光雷达、超声波、摄像头、毫米波雷达、V2X。
- 驾驶员监测主要分为摄像头和生物电传感。
决策系统分为三部分：
- 计算单元里是自动驾驶感知决策控制的算法。目前自动驾驶用的是X86结构的服务器或工控机。
- T-BOX即Telematics BOX，是车联网的通讯网关，它上接互联网下接CAN总线。例如手机上APP发送的开关门指令，都是通过T-BOX网关将操作指令发送到CAN总线来进行操控的。
- 黑匣子是用来记录无人驾驶过程中所有的信息和状态。
控制系统部分分为车辆控制和警告系统。
车辆控制主要分为制动、转向、发动机和变速箱。警告系统主要分为声音、图像和震动 。以上是整个自动驾驶硬件系统的构架。
4.3自动驾驶汽车感知类传感器
摄像头主要是用于车道线、交通标识牌、红绿灯、车辆和行人的检测。它的优点是检测信息全面且价格便宜，缺点是性能受天气影响较大。
摄像头主要由镜头、镜头的模组、滤光片、CMOS/CCD、ISP和数据传输这几部分组成。摄像头分为单目和双目。
摄像头的基本工作原理：光线通过摄像头前面的镜头和滤光片聚焦到后面的CMOS的Sensor上.Sensor将光信号进行曝光转化成电信号，然后通过ISP图像处理器转化成标准的RGB或者YUV的数据格式，最后传输到后端的计算机进行处理。
双目摄像头原理：通过两个图像之间视觉差计算，对任意障碍物提出警告和标识。
激光雷达的核心原理是TOF(Time of Flight)，即一束光射出后碰到障碍物后，光会发生回波，并在APD上进行接收和计算光折返的距离。
根据它的扫描原理激光雷达可以分为同轴旋转、棱镜旋转、MEMS、OPA相控阵以及Flash。
激光雷达作用：用于感知、地图类的测绘和定位。
毫米波雷达主要用于交通车辆的检测。毫米波雷达主要是由射频天线、芯片和算法组成，基本原理是发射一束电磁波，然后观察电磁波回波的摄入差异来计算距离和速度。主要分为远距离77G和近距离24G两种。
它的优点是检测速度快且较准确，不受天气情况干扰，缺点是不能对车道线进行识别检测。
组合导航是通过GNSS板卡接收所有可见的GPS卫星信号并进行计算，从而得出被检物体在大地坐标系中的空间位置。
当车辆通过隧道、有建筑物群和树荫遮挡等路段时，GPS信号会产生遮挡不能提供很好的结算和实时导航，所以这种情况下需要融合惯性导航的信息。
惯性导航是一个完全封闭的系统，不受外界影响，可以直接给出车身的位置、速度和姿态。
自动驾驶汽车传感器的安装位置一般是：
- 激光雷达是360°旋转的，所以它都是安装在车顶；
- 毫米波雷达的指向性很强，所以的它一般安装在前后保险杠上；
- 考虑到车身在道路上的俯仰和姿态的干扰，所以组合导航系统一般是安装在两个后车轮的中轴线上；
- 车身的360°都会安装摄像头。
4.4自动驾驶汽车的传感器
目前传统车企和一些AI公司在自动驾驶上针对传感器两个重大的理念差异：
- L1、L2级别最怕的是传感器误检；
- L3以上关注的是传感器漏检；
目前L4的适应范围是城市道路和高速路的一些自动驾驶，我国的高速路的限速是120km/h，根据道路摩擦系数可计算出不同速度下的刹车距离。加上整个系统反应时间，根据数学公式计算出下表。
目前自动驾驶的整个系统反应时间会在500毫秒之内，车辆制动是液压需要0.3~0.5秒，卡车用的气刹需要0.8秒。
目前市面上在售车，绝大多数都是低于这个技术指标，说明在售车性能都很好。从目前来看，对于传感器的要求，能测到150米已足够。
这是一个三角函数反正切函数，但是这个公式会多除以一个2，是为了避免漏检。
当激光雷达的两束线的角度之间有一个物体， 正好处于检测边缘它会产生一定的漏检，除以2是为了保证在每一个角度上都不会产生漏检。
检测到≠能识别。
目前百度Apollo平台，在同一车上用激光雷达4到5根线才可以很好地对障碍物进行分类。
现在像Velodyne 64线的激光雷达，0.4°分辨率下他的物体感知距离是50米。
未来自动驾驶传感器的趋势：自动驾驶传感器离不开多传感器的融合。激光雷达和摄像头都属于光学类的传感器，它们核心零部件和处理电路很相似，未来有可能将激光雷达和摄像头前端融合到一起，直接输出RGB、 XYZ融合后的颜色加点云信息，然后传输到后端的计算来进行处理。
美国创业公司Aeye开发的iRADAR系统，它不仅能真实的体现出二维世界的彩色信息，而且能将点云的信息叠加，每个像素点不仅有颜色信息还有空间坐标信息。
4.5自动驾驶汽车的计算单元
在自动驾驶汽车的计算单元部分，需要考量整体的车规、电磁干扰和振动方面的设计以及ISO-26262标准的要求。
防止单点故障：所有的CPU、GPU、FPGA、MCU和总线都要做冗余设计。
计算单元的集中式架构：将所有的工作都放到一个工控机当中。
这种架构的缺点是体积大、功耗高，不适应未来的量产；优点是方便代码的快速迭代，工控机卡槽的设计方便硬件更新和扩展 。
由于集中式的缺点，、将会考虑嵌入式的方案。将各传感器的原始数据先融合到一个Sensor Box中，在其中完成数据融合， 然后将融合后的数据给到后端计算平台处理。
Sensor Box作用：完成时间戳同步。目前所用传感器给出的原始数据该如何判断融合完成后是否是判断同一个目标，需要有一个时间戳同步，保证这个时间戳下每个传感器探测的都是同一个坐标系。
这种方案将原来集中式计算的功能拆解出来，可以降低整体系统的功耗，但是不足以面向更多的量产化。
芯片设计
ASIC的芯片是基于特定需求的特殊定制芯片，优点是比普通的GPU和FPGA体积更小、功耗更低、性能稳定和可量产。
现在的半导体产业非常成熟。自动驾驶算法公司只需做好芯片的前端设计，比如将算法固化下来，然后选择适用的IP核，最后进行EDA （电子自动化设计）， 将芯片设计完的电路图再交由后端，像台积电这种芯片制造企业进行流片的生产。
芯片设计流程整体分为芯片设计、芯片制造、芯片封装三部分。现在整个半导体产业正在从深紫外（DOV）向极紫外（EUV）发展。
半导体正步入7纳米时代，新工艺对性能带来很大提升。对比16纳米工艺，7纳米工艺可提升40%性能，节省60%能耗。
4.6自动驾驶汽车的线性系统
自动驾驶线控系统（control by wire）指的是汽车的控制是由一些简单命令完成的，而不是由物理操作完成的。
线控部分相当于人的手和脚，在线控系统里执行上端的命令。主要分为三大部分：减速控制、转向控制和加速控制。
传统汽车的这些控制由液压系统和真空助力泵协助完成，自动驾驶汽车的线控需要用电控化的零部件来完成，如电子液压制动系统（EHB）。
上图是大陆制动的解决方案。它的MK C1集成液压和制动的模块，利用紧凑且轻重量的设计节省制动单元，通过电信号发出的制动信号也使制动距离更短。
MK100使用的ESC（车身电子稳定系统）可与MK C1之间进行相互备份。当MK C1系统失效时由MK100来接管。
大陆制动的所有的供电、执行、线路和管路图都是双备份的，极大地提高安全性，但是该系统只适用于乘用车。像卡车、客车等商用车都是通过气刹系统制动的。
目前很多自动驾驶车都使用EPS（电子助力转向系统）。EPS直接使用转向管柱与下面的齿条相结合，没有采用电控制。
英菲尼迪Q50的转向系统中，由离合器进行转向管柱的截断，当车辆启动时离合器松开，所有的自动驾驶指令都通过ECU（电子控制元件）发送控制指令到下端两个转向电机上，进行转向控制。
线控油门是对自动驾驶车辆加速度的控制，减速刹车踏板上有位置传感器可检测到刹车深浅度，该传感器传送指令到EMS（发动机制动系统）后，气门进气量越多，加速度即越快。
自动驾驶汽车目前大多是新能源车，新能源车通过驱动电机的扭力控制来完成对加速度的控制，从整个线控化来看，分为三个阶段：
- 1.0 对原车的方向盘踏板进行改装，将一些转向管柱截断后，加装转向电机，通过控制电机进行转向，缺点是未经过原车系统测试验证，存在安全隐患。
- 2.0 基于原车的辅助驾驶系统，对Can总线协议进行破解，通过原车总线指令控制车的转向和制动。
- 3.0 从车底盘开始开发的一套系统，转向线控完全按照自动驾驶需求定制，与2.0的区别在于考虑到冗余和备份的需求。
4.7Apollo硬件开发平台
在百度目前提供的参考设计分为：
- Apollo平台认证是指百度目前正在使用的传感器经认证后公布出来。例如Velodyne 64线激光雷达就属于Apollo平台认证产品，基于正在使用的传感器提供数据集。
- Apollo硬件开发平台认证，则是在Apollo代码层面进行验证，如感知模块的数据化采集标注和模型的训练的额外工作，还需要开发者自己完成。
后续Apollo会继续丰富生态圈，继续提供芯片和传感器的支持及选型。
传感器单元（Sensor Box）将所有的传感器信息融合到传感器单元中，完成整个时间戳的对准，将前处理的数据传输到后端的工控机计算单元上进行处理.
这是根据百度在使用传感器开发出来的，不一定适用所有开发者。后续Apollo将推出AXU扩展单元，附带PCI卡槽的单元将更加灵活。
在Apollo的抽象层中，有硬件接口，比如说内核驱动、USP Library（用户空间库）等。
USP Library（用户空间库）主要用在Can总线协议中。因为每个车厂/车型/批次其Can总线协议都不同，将控制指令信息写在USP Library中进行操控。
Apollo开发平台中，还有HAL硬件抽象层，这为了防止单一硬件短路而导致整个系统硬件内核崩溃的中间开发层。不同的硬件厂家可以选择开放所有源代码，或将编译后的代码发布在Apollo平台上。
Apollo完成代码核入的工作后会发布在GitHub上，开发者不需要针对不同硬件选型去开发不同的驱动。
最后，是VSI发布的自动驾驶产业链布局图。
自动驾驶产业是汽车新能源、IT、交通通讯、半导体人工智能、移动互联网等多个10万规模产业亿聚的大型聚合产业。
自动驾驶汽车是物质流、能量流、信息流的聚合体，需要软硬件行业的深度整合和合作才能保证自动驾驶产业的成功落地。