自动驾驶：硬件平台

OceanStar的学习笔记

已于 2022-11-20 15:09:43 修改

阅读量1.3k

点赞数 4

分类专栏： ROS 文章标签：人工智能自动驾驶

于 2022-11-20 13:50:37 首次发布

原文链接：https://mp.weixin.qq.com/s?__biz=MzI1NjkxOTMyNQ==&mid=2247486437&idx=1&sn=52692e9c12dc65c3432de3df2e07a60d&chksm=ea1e1997dd69908123b1145d41abac6ba62bccaeb37b0f8dbe50acc7776d2c41abf563b6e572&scene=178&cur_album_id=1452711164328476676#rd

版权

ROS 专栏收录该内容

84 篇文章 46 订阅

订阅专栏

自动驾驶的研发流程

大致可以分为以下4个步骤：

软件在环软件在环是基于仿真和模拟的软件仿真，类似于赛车类游戏。即是在软件系统里仿真模拟出真实的道路环境如光照、天气等自然环境，开发者可将自动驾驶代码开发完毕后，在仿真系统内运行，测试是否可以实现目标。
硬件在环硬件在环是基于必要的硬件平台。在第一步的软件仿真结束后，将所有的仿真结果与传感器、计算单元集合在一起，在硬件环境里测试。
车辆在环车辆在环是基于车辆执行。在第二步硬件环境里测试完成后实施的第三步，即在一个封闭环境中测试开发者所开发功能，封闭环境中不会有交通流的干扰。
司机在环司机在环是基于实际道路。在第三步测试成功后进入到司机在环，司机在环主要是研究人——车——路——交通四者之间的相互作用，它不仅测试自动驾驶的程序代码，还能获得专业司机的评判。

以上四步是整个自动驾驶研发的流程，按照以上的流程研发能够保证自动驾驶足够的安全性。

在这里插入图片描述

自动驾驶的硬件系统

整个自动驾驶硬件系统的构架如下：
在这里插入图片描述
自动驾驶分为三大系统：感知、决策和控制，每个系统里有对应的硬件系统。

感知系统分为汽车运动、环境感知和驾驶员监测三部分。

车辆运动主要分为惯性导航、速度传感器、角度传感器和全球定位系统。
环境感知主要分为激光雷达、超声波、摄像头、毫米波雷达、V2X。
驾驶员监测主要分为摄像头和生物电传感。

决策系统分为计算单元、T-BOX和黑匣子三部分。

计算单元里是自动驾驶感知决策控制的算法。目前自动驾驶用的是X86结构的服务器或工控机。
T-BOX即Telematics BOX，是车联网的通讯网关，它上接互联网下接CAN总线。例如手机上APP发送的开关门指令，都是通过T-BOX网关将操作指令发送到CAN总线来进行操控的。
黑匣子是用来记录无人驾驶过程中所有的信息和状态。

控制系统部分分为车辆控制和警告系统。

车辆控制主要分为制动、转向、发动机和变速箱。
警告系统主要分为声音、图像和震动。

自动驾驶汽车的感知类传感器

安装位置

自动驾驶汽车传感器的安装位置一般是：

激光雷达是360°旋转的，所以它都是安装在车顶；
毫米波雷达的指向性很强，所以的它一般安装在前后保险杠上；
考虑到车身在道路上的俯仰和姿态的干扰，所以组合导航系统一般是安装在两个后车轮的中轴线上；
车身的360°都会安装摄像头。

在这里插入图片描述

传感器

在这里插入图片描述
上图总结了自动驾驶所使用到的传感器。

自动巡航ACC、应急制动AEB、行人检测FD都是L1、L2级的功能。
对于AEB(应急制动)
- 欧洲的标准是2017年强制性具备AEB功能的车辆；
- 美国的标准是让到2020年让所有的车具备辅助驾驶、车道偏离和AEB功能；
- 中国的标准是到2018年将自动驾驶L1级的功能AEB列为强制标准，这些强制标准主要是用于商用车、卡车和客车。

下面简单介绍L1、L2目前量产的方案和百度以及很多人工智能公司研发的L3＋以上的方案的差异。

L1、L2级别最怕的是传感器误检，例如正在开车时传感器发生误检，随后急刹车会让驾驶感受很差。L1、L2的算法会避免一定的误检率。
L3以上关注的是传感器漏检，驾驶的主体是一个系统，一定不能让系统的传感器段出现漏检情况。

这是目前传统车企和一些AI公司在自动驾驶上针对传感器两个重大的理念差异。

目前L4的适应范围是城市道路和高速路的一些自动驾驶，我国的高速路的限速是120km/h，根据道路摩擦系数可计算出不同速度下的刹车距离。加上整个系统反应时间，根据数学公式计算出下表。
在这里插入图片描述
目前自动驾驶的整个系统反应时间会在500毫秒之内，车辆制动是液压需要0.3~0.5秒，卡车用的气刹需要0.8秒。

目前市面上在售车，绝大多数都是低于这个技术指标，说明在售车性能都很好。从目前来看，对于传感器的要求，能测到150米已足够。
在这里插入图片描述

这是一个三角函数反正切函数，但是这个公式会多除以一个2，是为了避免漏检。
当激光雷达的两束线的角度之间有一个物体，正好处于检测边缘它会产生一定的漏检，除以2是为了保证在每一个角度上都不会产生漏检。
在0.4°这个分辨率之下我们在100米外其实就可以检测到一个人、车或骑行者。
在0.1°这个分辨率之下我们在400米外其实就可以检测到一个人、车或骑行者。
但是能检测到并不意味着自动驾驶系统能识别出来，只有一条线的这种成像或者低分辨率的成像，自动驾驶还是识别不了。

目前百度Apollo平台，在同一车上用激光雷达4到5根线才可以很好地对障碍物进行分类。

现在像Velodyne 64线的激光雷达，0.4°分辨率下他的物体感知距离是50米。

未来自动驾驶传感器的趋势：自动驾驶传感器离不开多传感器的融合。激光雷达和摄像头都属于光学类的传感器，它们核心零部件和处理电路很相似，未来有可能将激光雷达和摄像头前端融合到一起，直接输出RGB、 XYZ融合后的颜色加点云信息，然后传输到后端的计算来进行处理。

美国创业公司Aeye开发的iRADAR系统，它不仅能真实的体现出二维世界的彩色信息，而且能将点云的信息叠加，每个像素点不仅有颜色信息还有空间坐标信息。

自动驾驶汽车的计算单元

在这里插入图片描述
上图是自动驾驶汽车的计算单元架构。

在自动驾驶汽车的计算单元部分，需要考量整体的车规、电磁干扰和振动方面的设计以及ISO-26262标准的要求。

所有的CPU、GPU、FPGA、MCU和总线都要做冗余设计，以防止单点故障。

目前计算单元都是集中式的架构，即将所有的工作都放到一个工控机当中。
这种架构的缺点是体积大、功耗高，不适应未来的量产；优点是方便代码的快速迭代，工控机卡槽的设计方便硬件更新和扩展。
由于集中式的缺点，未来将会考虑嵌入式的方案。将各传感器的原始数据先融合到一个Sensor Box中，在其中完成数据融合，然后将融合后的数据给到后端计算平台处理。

Sensor Box作用：

目前所用传感器给出的原始数据该如何判断融合完成后是否是判断同一个目标，需要有一个时间戳同步，保证这个时间戳下每个传感器探测的都是同一个坐标系，时间戳的同步是在Sensor Box里面完成的。
这种方案将原来集中式计算的功能拆解出来，可以降低整体系统的功耗，但是不足以面向更多的量产化。

在这里插入图片描述
下面介绍芯片的设计流程。

我们现在开发的自动驾驶算法，当感知算法固化后可以做成专用的芯片。
ASIC的芯片是基于特定需求的特殊定制芯片，它的优点是比普通的GPU和FPGA体积更小、功耗更低、性能稳定和可量产。
现在的半导体产业非常成熟。自动驾驶算法公司只需做好芯片的前端设计，比如将算法固化下来，然后选择适用的IP核，最后进行EDA （电子自动化设计），将芯片设计完的电路图再交由后端，像台积电这种芯片制造企业进行流片的生产。
芯片设计流程整体分为芯片设计、芯片制造、芯片封装三部分。现在整个半导体产业正在从深紫外（DOV）向极紫外（EUV）发展。
半导体正步入7纳米时代，新工艺对性能带来很大提升。对比16纳米工艺，7纳米工艺可提升40%性能，节省60%能耗。

自动驾驶汽车的线控系统

在这里插入图片描述
自动驾驶线控系统（control by wire）指的是汽车的控制是由一些简单命令完成的，而不是由物理操作完成的。

线控部分相当于人的手和脚，在线控系统里执行上端的命令。主要分为三大部分：减速控制、转向控制和加速控制。

Apollo硬件开发平台

2018年7月4日，Apollo硬件开发平台正式发布，新增15家硬件厂商选型，也发布了Apollo传感器单元。

添加底层的抽象层后（将原来的硬件参考设计升级为硬件开发平台），硬件开发平台内容更加丰富了。

在这里插入图片描述
在百度目前提供的参考设计中，分为Apollo平台认证及Apollo硬件开发平台认证。

Apollo平台认证是指百度目前正在使用的传感器经认证后公布出来。例如Velodyne 64线激光雷达就属于Apollo平台认证产品，Apollo会基于正在使用的传感器提供数据集。
Apollo硬件开发平台认证，则是在Apollo代码层面进行验证，如感知模块的数据化采集标注和模型的训练的额外工作，还需要开发者自己完成。

Apollo传感器单元（Sensor Box）

传感器单元（Sensor Box）将所有的传感器信息融合到传感器单元中，完成整个时间戳的对准，将前处理的数据传输到后端的工控机计算单元上进行处理.
这是根据百度在使用传感器开发出来的，不一定适用所有开发者。后续Apollo将推出AXU扩展单元，附带PCI卡槽的单元将更加灵活。

在这里插入图片描述
在Apollo的抽象层中，有硬件接口，比如说内核驱动、USP Library（用户空间库）等。

USP Library（用户空间库）主要用在Can总线协议中。因为每个车厂/车型/批次其Can总线协议都不同，将控制指令信息写在USP Library中进行操控。
Apollo开发平台中，还有HAL硬件抽象层，这为了防止单一硬件短路而导致整个系统硬件内核崩溃的中间开发层。不同的硬件厂家可以选择开放所有源代码，或将编译后的代码发布在Apollo平台上。
Apollo完成代码核入的工作后会发布在GitHub上，开发者不需要针对不同硬件选型去开发不同的驱动。