无人驾驶 | 自动驾驶技术和机器人技术的对比

这是学习中兴开发者社区金明、郑卫军的总结笔记，感谢大佬的总结，学习记录一下

机器人技术的核心是运动控制，包括定位、导航、感知、决策、跟踪等，可广泛应用在家庭服务机器人、工业自动化机器人等领域。自动驾驶是人工智能领域最炙手可热的方向，互联网巨擎（谷歌、Uber、百度等）、传统汽车大厂商、 Tier1供应商以及很多初创公司都纷纷投入到这场全新的交通运输生态的创建中。截止2017年6月18日以来，共有34家公司获得美国加州路测资格，其中中国背景的公司就有9家。

 

图片来自互联网

通过对自动驾驶的深入了解，发现自动驾驶技术与机器人运动控制技术在框架构成、硬件平台、应用理解、软件核心算法上都基本契合。本文以百度的自动驾驶Apollo技术为例，比较自动驾驶和机器人运动控制技术的异同点。

注：目前自动驾驶技术百度公开的最为彻底，它所用的思想代表了目前做自动驾驶的主流路线。

技术框架对比

 

▍机器人运动控制的技术栈

 

机器人运动控制分为四层技术栈：

 

1. 基础运动平台

一个机器人必须有可以运动的实体，一般来说，对于低速移动的机器人，差分轮式运动底座是比较普遍的选择。它有两个主动轮，可以分别控制转速和转向， 前面有一个被动万向轮。运动底座向上提供的基本接口包括：线速度，角速度或曲率控制， 查询当前里程计信息，完成上层对运动底座的控制和信息查询。

 

2. 硬件平台

 运算单板是硬件部分，与运算单板同层的其它模块，都是感知单元，感知单元涵盖了目前主流的环境感知技术，可按照实际需求进行选取。

 

3. 软件平台

软件平台包括操作系统和上层算法。目前主流的机器人操作系统是ROS，ROS是Willow Garage公司在2010年发布的开源机器人操作系统，由于其具有点对点设计，不依赖于编程语言，分布式架构，强大的硬件抽象，广泛的社区参与贡献，丰富的可复用，知名的开源库资源，已经成为机器人设计的不二选择。对于低速运动场景，原生的ROS环境完全满足设计要求。

 

感知、定位、避障、地图、路径规划、导航、跟踪是封装的软件算法模块，软件算法与感知单元采集的数据配合，完成机器人的各种功能。

 

4. 云服务平台

云服务平台包括仿真、安全、数据平台、训练平台、语音和全局地图功能，数据平台位于云端，通过深度学习和训练，使机器人获得更高的智能水平。仿真平台是做机器人测试的必要工具，用户可以不依赖于真实的机器人和测试环境，而是在仿真平台中建立机器人模型和测试环境，进而验证自己的算法。

 

▍百度自动驾驶Apollo技术框架

 

图片来自互联网

百度的自动驾驶分为四层技术栈：

 

1. 参考汽车平台 

一辆汽车， 必须可以实现电子化的控制，也就是线控。百度目前的参考设计使用的是Lincoln MKZ, enhanced by Autonomous Stuff, 为用户提供了一个无障碍的自动车辆平台。该平台为用户提供了一整套硬件和软件解决方案。用户可以直接获得车辆某些模块控制权限，如档位，速度和指示灯，如下图：

 

 

2. 参考硬件平台

为了实现高性能稳定的计算，百度采用的是工业级PC作为运算单元， 配置6th-Gen Intel® Core™ i7/i5 LGA1151 CPU 和NVIDIA® GeForce® GTX 1050* GPU，可以工作在-25°到60°的工作范围。

 

 

定位采用的是GPS+IMU的融合方案，精度能达到厘米级别。在Apollo 1.0 中没有公开摄像头、Lidar(雷达)和Radar(毫米波雷达)信息，不过根据百度以前无人驾驶车的信息可以看到，它包含一个Velodyn 64线HDL64E雷达，配套一个长距毫米波雷达和中距毫米波雷达，一个鱼眼摄像头和一个摄像机镜头。

 

3. 开源软件平台

开源软件平台包括操作系统和上层算法。Apollo 采用 ROS 操作系统。其中ROS是做了定制化修改的，使得其能更适合自动驾驶的要求，后面的连载文章中会详细介绍。

算法模块的构成与前面运动控制中的算法基本类似，多了端对端和HMI。HMI是百度自动驾驶提供的人机交互界面，方便操作者统计和调试。端对端算法是一种所见即行动的思想，通过深度学习，将感知直接转化为控制，这是一种实验性质的算法，目前还不是主流应用。

 

4. 云服务平台

主要有三个作用,  训练模型， 自动驾驶仿真， 高精地图提供。

 

▍两个技术栈的对比

 

根据上述对机器人运动控制技术和自动驾驶技术栈的描述，可以看到两者之间有颇多相似的地方，同时也有一些差异点，具体分析如下：

 

1. 运动底座 vs 参考汽车平台

二者都是运动的控制主体，为上层算法提供控制接口进行驱动，提供查询接口进行反馈。运动底座和汽车进行控制时都要满足非完整约束，即不向前移动的情况下，无法单独完成横向位移。相比于运动底座，汽车平台的动力学模型会更加复杂，除了速度不是一个量级 ，惯性因素也会使得控制更加复杂。汽车的横向位移（转弯）靠前轮的朝向与前后轮形成直线的夹角的变化，属于自行车模型。机器人运动控制多采用差分轮运动底座，横向位移靠两个轮子相互反方向旋转，靠不同的旋转速度比，来满足不同曲率的要求，在控制算法的选取中，会有不同。

 

2. 运算单元

运动控制平台采用的是嵌入式异构计算单板， 满足低速简单运动场景的感知、决策、控制算法的计算要求。汽车应对的是高速、绝对可靠安全的场景，运算量不是一个量级，目前多采用工业级PC的方案来满足感知对于运算量的要求。各芯片厂商也纷纷推出自己的芯片方案，后续运算单元平台将是百花争艳的局面。

 

3. 感知单元

运动控制平台和自动驾驶采用的传感器大多重叠，也有几个不同地方， 如深度摄像头可以在运动控制平台的室内场景中使用，深度主要靠结构光技术，抗干扰能力差，目前在室外场景下不可靠。自动驾驶多采用双目摄像头来完成深度识别。运动控制平台采用超声和红外完成被动障碍感知， 自动驾驶采用汽车电子方面非常成熟的毫米波雷达方案。

 

4. 操作系统

两者都使用 ROS操作系统，汽车对于实时性、 带宽、分布式要求会更加严苛。原生的ROS 对于这三方面都无法达到自动驾驶的要求，虽然 ROS 2.0 会在这三个方面有很大的提升，但是仍然处于实验阶段。大部分自动驾驶厂商，包括百度，都是在ROS基础上作深度定制。 

 

5. 上层算法

两者的软件算法分类基本相同，所采用的算法实现有很多相互借鉴的地方， 在后面的连载文章中会详细介绍。

 

6. 仿真

运动控制平台的场景相对简单，在一些相对高配置的PC上基本能满足要求。自动驾驶一般要自动驾驶厂商自己搭建仿真平台， 汽车要仿真的环境非常复杂，计算量消耗很大，一般要采用云技术分布式平台。 

 

7. 地图

运动控制平台的地图创建所描绘的场景比较简单， 一般2D 场景地图即可满足要求，在运算单元上可以完成创建和使用。自动驾驶需要高精地图， 三维点云，精确到厘米级别， 其特点是需要花费巨大成本提前用采集车采集，生成的高精地图要随时更新，消耗大量的存储，一般要放在云端，自动驾驶车通过高速无线网络下载当时位置的高精地图满足实时决策要求。 

 

8. 训练

运动控制平台会对某些物体或人有简单的识别要求，模型可以提前在服务器端训练，训练数据相对不多。汽车有海量的数据要进行训练，如果要满足高可靠性的物体识别任务，要在云端进行训练。

 

9. 运动控制平台的多机协作 vs 车联网

运动控制平台涉及多机协作的要求，如多个AGV小车互联互通共同完成调度任务，是车车通信的一种方式。车联网方案是自动驾驶的一条路径，在百度Apollo框架中并没有提及。包含V2V(车车通信）、V2I( 车路通信）、 V2P（车人通信），完成信息共享后的汽车决策和控制算法。目前通信标准主要是欧美主推的DSRC(专用短程通信）和中国主推的5G标准LTE-V。

 

自动驾驶 vs 机器人环境感知

自动驾驶和机器人共同的三大关键技术为：

环境感知是其中最重要、最基础的一环。

自动驾驶和机器人主要通过传感器来获取周围环境信息，同时也会通过高精度地图和IoT技术来扩展环境感知能力。

下面我们来了解一下每类传感器的特性，以及在机器人和自动驾驶汽车中的使用差异。

 

▍一、摄像头

摄像头是机器人或自动驾驶汽车的眼睛，分类如下：

1. 普通单目摄像头

通过图像匹配进行目标识别，再通过目标在图像中的大小去估算目标距离，准确识别是准确估算距离的第一步。

2. 单目结构光深度摄像头

由一个RGB摄像头、结构光投射器(红外)和结构光深度感应器(CMOS)组成，通过投影一个预先设计好的图案作为参考图像(编码光源)，将结构光投射至物体表面，再通过深度感应器接收该物体表面反射的结构光图案。

这样，同样获得了两幅图像，一幅是预先设计的参考图像，另一幅是相机获取的物体表面反射的结构光图案。

由于接收图案会因物体的立体形状而发生变形，因此可以通过该图案在摄像机上的位置和形变程度来计算物体表面的空间信息。

单目结构光 Kinect一代

同样是进行图像匹配，这种方法与双目匹配比较好处在于，参考图像不是获取的，而是经过专门设计的图案，因此特征点是已知的，而且更容易从测试图像中提取。

3. 双目深度摄像头

双目摄像头的测距方式则是通过对图像视差进行计算，直接对前方景物进行距离测量。双目摄像头的原理与人眼相似，人眼能够感知物体的远近，是由于两只眼睛对同一个物体呈现的图像存在差异，也称“视差”。

物体距离越远，视差越小，反之视差越大。视差的大小对应着物体与眼睛之间距离的远近，这也是3D电影能够使人有立体层次感知的原因。

优点

1） 双目系统成本比单目系统要高，但尚处于可接受范围内，并且与激光雷达等方案相比成本较低。

2） 没有识别率的限制，因为从原理上无需先进行识别再进行测算，而是对所有障碍物直接进行测量。

3） 精度比单目高，直接利用视差计算距离。

4） 无需维护样本数据库，因为双目没有样本的概念。

难点

1） 计算量大，对计算单元的性能要求非常高，这使得双目系统的产品化、小型化的难度较大。

2） 匹配，双目匹配采用三角测量原理，完全基于图像处理技术，通过寻找两个图像中相同的特征点得到匹配点，从而得到深度值。

双目测距中光源是环境光或者白光这种没有经过编码的光源，图像识别完全取决于被拍摄的物体本身的特征点，对表面颜色和纹理特征不明显的物体失效，匹配的精度和正确性很难保证，因此出现了结构光技术来解决匹配问题。

因为结构光光源带有很多特征点或者编码，因此提供了很多的匹配角点或者直接的码字，可以很方便的进行特征点的匹配。

4. TOF深度摄像头

TOF是Time of flight的简写，直译为飞行时间的意思。

所谓飞行时间法3D成像，是通过给目标连续发送光脉冲，然后用传感器接收从物体返回的光，通过探测光脉冲的飞行（往返）时间来得到目标物体的距离。这种技术跟3D激光传感器原理基本类似，只不过3D激光传感器是逐点扫描，而TOF相机则是同时得到整幅图像的深度信息。

TOF相机与普通机器视觉成像过程也有类似之处，都是由光源、光学部件、传感器、控制电路以及处理电路等几部单元组成。

单目TOF Kinect二代

各种摄像头性能和成本比较：

由上表对比可知，无论是结构光还是TOF方案，都需要增加主动光，因此，其检测距离受到了光强度的限制，无法适用于远距离的检测，一般只用于机器人的感知，而普通单目和双目摄像头除了在机器人上应用，还可以用于ADAS和自动驾驶汽车上。

 

▍二、激光雷达

激光雷达以激光作为信号源，由激光器发射出的脉冲激光，打到对面物体上，引起散射，一部分光波会反射到激光雷达的接收器上，根据激光测距原理计算，就得到从激光雷达到目标点的距离，脉冲激光不断地扫描目标物，就可以得到目标物上全部目标点的数据，用此数据进行成像处理后，即可得到精确的目标物体图像。

激光雷达分为单线和多线，常见的多线激光雷达有4线，8线，16线，32线和64线。

• 单线激光雷达扫描的区域可以简单定义为一个平面，是一个二维扫描方案。

• 4线、8线雷达纵向扫描范围从3.2°到6.4°，这个范围不能称为一个3D的扫描，一般定义为2.5D扫描方案。

• 64线雷达扫描的整个范围面就比较大，纵向甚至可以一直到30多度，讲究对整个环境、3D的点云数据收集，单位时间内收集到的反馈点数多，数据量大。

 

SICK单线激光雷达

单线二维激光雷达扫描图

Velodyne多线激光雷达

64线三维激光雷达扫描图

激光雷达普遍用于定位、障碍物检测、物体分类、动态物体跟踪等应用，在机器人和自动驾驶汽车上都有使用。

•  由于机器人的工作环境相对来说比较简单，而且迫于成本压力，一般采用单线激光雷达，用于定位和检测周边障碍物。

• 自动驾驶汽车一般采用32线或64线的三维激光雷达置于车顶，完成对车辆四周较远物体的检测分类和跟踪。

  另外，在车灯或者保险杠附近的位置还需要安装4线和8线激光雷达，主要对车顶三维激光雷达进行补盲，对近距离的车辆、行人以及地线、马路牙、路肩、路栏等进行识别。

缺点

激光雷达容易受到大气条件以及工作环境的烟尘的影响，要实现全天候的工作环境是非常困难的事情。

三、毫米波雷达

毫米波是指波长在 1-10mm 之间的电磁波,换算成频率后,毫米波的频率位于30-300GHz 之间。

毫米波的波长介于厘米波和光波之间,因此毫米波兼有微波制导和光电制导的优点:

1. 同厘米波导引头相比, 毫米波导引头具有体积小、质量轻和空间分辨率高的特点。

2. 与红外、激光等光学导引头相比, 毫米波导引头穿透雾、烟、灰尘的能力强,传输距离远,具有全天候全天时的特点，在雨天、大雪天气下，毫米波雷达是非常不错的选择。

3. 性能稳定,不受目标物体形状、颜色等干扰。毫米波雷达很好的弥补了如红外、激光、超声波、摄像头等其它传感器在车载应用中所不具备的使用场景。

目前车载雷达的频率主要分为24GHz频段和77GHz频段，其中77GHz频段代表着未来的趋势，这是国际电信联盟专门划分给车用雷达的频段。

严格来说77GHz的雷达才属于毫米波雷达，但是实际上24GHz的雷达也被称为毫米波雷达。

毫米波雷达在测量目标的距离、速度和角度上展现的性能和其它传感器还是略有区别的。

• 视觉传感器得到的是二维信息，没有深度信息，而毫米波雷达则是具备深度信息的，可以提供目标的距离。

• 激光雷达对于速度并不敏感，而毫米波雷达则对速度非常敏感，可以直接获得目标的速度，因为毫米波雷达会有很明显的多普勒效应，通过检测其多普勒频移可将目标的速度提取出来。

• 毫米波雷达最基本的探测技术是使用FMCW连续线性调频波去探测前方物体的距离，毫米波雷达发射的是连续波，在后端处理上要比激光雷达的运算量大。

毫米波雷达在ADAS领域是很难被取代的传感器，虽然有一些缺点，但是是唯一的全天候工作的传感器。

其测速、测距的精度要远高于视觉，与激光雷达相比，其测速精度会高一些，穿透力会更好。

而对于机器人的应用场景，利用毫米波雷达来探测障碍物，显得有点奢侈了，一般采用更低成本的超声波雷达来替代，但对于一些特殊应用场景的机器人（譬如消防，大型物流），由于需要在复杂环境下支持全天候、全天时作业，就必须采用毫米波雷达来实现避障。

 

▍四、超声波雷达

超声波雷达是利用传感器内的超声波发生器产生 40KHz的超声波,再由接收探头接收经障碍物反射回来的超声波,根据超声波反射接收的时间差计算与障碍物之间的距离。

超声波雷达成本较低,探测距离近，精度高,且不受光线条件的影响,因此常用于泊车系统中。

超声波最大的缺点就是检测角度太小，一辆车需要在不同角度安装好几个，除此以外，都比上面几种方案更好。

优点 

• 防水，防尘，少量的泥沙遮挡也无妨

• 有金属材质的探头，可以与车体外壳结合的很好

• 通常适合3m内的检测，由于其空气损耗大，检测角度又小，因此车辆之间的干扰较小

• 最小的监测距离可达到0.1-0.3m

•  成本不高

对于较常见的40KHz超声波传感器，其测距精度大约是1~3cm左右（取决于后端电路和数据处理性能），这个范围也能满足倒车雷达的要求，所以在倒车雷达的各个方案中，超声波是最容易被用户接受的。

另外，超声波雷达由于成本低，检测距离适中，因此在机器人的避障中应用也很广。汽车相对于绝大部分室内应用的机器人来说，对防护等级要求较高，因此，汽车上用的都是高防护等级的收发一体化的超声波雷达。

 

▍五、红外

红外线的工作原理是利用高频调制的红外线在待测距离上往返产生的相位移推算出光束度越时间△t，从而根据D＝C△t/2得到距离D。红外传感器的测距基本原理为发光管发出红外光，光敏接收管接收前方物体反射光，据此判断前方是否有障碍物。根据发射光的强弱可以判断物体的距离，它的原理是接收管接收的光强随反射物体的距离而变化的，距离近则反射光强，距离远则反射光弱。 

目前，使用较多的一种传感器红外光电开关，它的发射频率一般为38 kHz左右，探测距离一般比较短，通常被用作近距离障碍目标的识别。红外只适合短距离测距，因此基本上只用于低速移动的机器人上防碰撞。

各种传感器的技术指标对比：

 

▍六、IMU

IMU（惯性测量单元）是测量物体三轴姿态角(或角速率)以及加速度的装置。一般一个IMU包含三个单轴的加速度计和三个单轴的陀螺，加速度计检测物体在载体坐标系统独立三轴的加速度信号，而陀螺检测载体相对于导航坐标系的角速度信号，测量物体在三维空间中的角速度和加速度，并以此计算出物体的姿态。

惯性传感器的定位误差会随着运行时间增长，但由于其是高频传感器，在短时间内可以提供稳定的实时位置更新。IMU大多用在需要进行运动控制的设备，如汽车和机器人上，在导航中有着很重要的应用价值。

 

▍七、GPS

GPS由GPS接收机和卫星天线组成，主要通过卫星来计算我们当前的位置和速度。通过测量从卫星上接收信号的时间，设备能够实现精确度大约在10m左右的定位。

一个略为改进过的定位系统上线了，我们可以把它称为差分全球定位系统(DGPS)，因为使用了地面基准站的关系，这个系统的精确度被提升到了1m。但这个精度对机器人和自动驾驶汽车的使用场景来说，都是不够的。因此，GPS一般需要融合IMU实现厘米级的定位。

另外，由于室内无法接收到GPS信号，因此，对于室内机器人则无法使用GPS进行定位。

 

▍八、信息交互

对于自动驾驶汽车来说，还有一类技术虽然不是主动式的探测元件，但是属于协同式的全局数据辅助，可以扩展智能车的环境感知能力，在感知层同样扮演着不可或缺的角色，包括高精度地图、V2X车联网技术。每种类型的感知技术都有自己的优势和弊端，它们相互补充融合，最终使智能车达到驾驶场景下非常高的安全性要求。

 

▍九、结语

传感器是机器人和自动驾驶汽车环境感知的基础，对于各个传感器采集的数据还需要算法来处理，这样才能进行自身的定位和环境障碍的识别，因此，单个传感器数据的处理以及多传感器数据融合的算法非常关键。

 

自动驾驶 vs 机器人操作系统

无论是自动驾驶还是机器人运动控制的技术栈，都有很关键的一层，即操作系统层。该层与下层的硬件平台接口，其上层为软件算法单元，如下图：

▍操作系统的选择

机器人大多选择ROS（robot operation system) indigo, 百度的自动驾驶Apollo在ROS indigo的基础上做了定制。

除了百度的Apollo，日本的tier IV公司也开源了自己的整套自动驾驶算法Autoware, Autoware也是基于ROS。

另外在一些自动驾驶初创公司的公开信息中可以看到，他们的操作系统同样是基于ROS的。

作为对比，我们看到大的车商更倾向于专业的商业解决方案，如宝马将操作系统和中间件的开发工作交给了Intel，我们都知道Intel是一家专业的计算芯片解决方案提供商，但是大部分人不知道2009年Intel 收购了嵌入式操作系统解决方案提供商风河公司。

风河介绍

做过嵌入式系统开发的人，都对这个曾经的霸主有所了解，虽然它在慢慢被人淡忘，因为现在嵌入式设备的操作系统是Linux 和基于Linux 的Anroid的天下。风河公司在加入Intel之后一直没闲着，只是一直隐藏在Intel背后。此前Intel和三星推出的Tizen操作系统，风河就一直参与其中。期望在汽车市场展开第二春的Intel,在软件上的王牌就是风河。

2014年，风河成为谷歌开放汽车联盟的一员，与谷歌共同开发Android For Automotive。风河在汽车操作系统上有天然的优势，它很早就涉足汽车娱乐信息系统、显示屏和车联网业务，与车厂有长期稳定的合作关系，在此基础上，它又提供自动驾驶、高级辅助驾驶和汽车云服务，无缝连接，更值得车厂的信任。

下图是2017年1月风河推出的面向汽车的软件解决方案Helix Chassis产品，该产品依仗的就是其1987年即开发出来的实时操作系统Vxworks。

综上所述，我们可以看到汽车操作系统，基本分为两个阵营：

• 传统车商

他们的路线是商业产品，一直信赖平滑过渡的产品。

• 行业闯入者 

这个阵营如Google的Waymo，Tesla有实力及早布局自己的操作系统解决方案，其它大部分公司会选择ubuntu+ROS 深度定制的方案，加快自己的开发效率。

▍操作系统主要做什么工作？

每个做计算机行业的人对操作系统的概念既熟悉又陌生。程序员的三大浪漫是操作系统、编译系统和图形学。评价一个牛人的标准之一就是：做过一个操作系统内核，能看Linux 内核代码并做贡献。实际中除非工作需要，软件人员一般不会在操作系统上面下功夫， 一个原因是它的确很难，另一个原因是它像水和空气一样，非常重要，但大部分情况下是免费的。

操作系统的价值

我们执行一段程序，其实不仅仅是代码编译好的机器码在执行，而是在操作系统的协助下一起执行，完成某项工作。操作系统会找到你要执行的程序（磁盘管理），将程序码导入内存（内存管理），分配进程，分CPU时间片去调度。 

你的程序若访问其它硬件资源如显示器，操作系统会给你提供接口，把你的请求连接到显示系统进程中去，将请求翻译成显示屏上的像素值，达到显示目标。进程间对相同资源的访问，操作系统会透明地帮你安排好。 

我们可以想象一下，没有操作系统，软件开发者大部分会成为废人，就算是一个高手，也要关注很多细节才能完成一个简单的任务。大部分操作系统都会有存储管理、内存管理、进程管理等一般化的工作。对于不同的需求，也会衍生出不同的有针对性的操作系统。我们的PC工作站，对人机交互体验和进程调用切换要求会更高一些，对于大部分嵌入式设备，CPU资源的占用敏感，实时性则是考虑重点，而不需要考虑人机交互。

开源Linux 给操作系统领域带来的震撼，改变了这个领域的发展格局，在Linux内核的基础上，各个领域的计算机应用可以进行高效地量体裁衣的定制。以Android为例，很多人可能会以为它是一个全新的操作系统，事实上它是建筑在Linux内核基础上，它的应用有自己的特点，要无痛在各种硬件平台架构上无差异的执行，无论是Arm,PowerPC,还是 X86。 

移动设备一般不会使用PC上的存储设备，但Flash，SD卡高效存取是它要着重考虑的。移动设备对能耗非常敏感，对人机交互要求很高，这一系列因素催生了我们所见到的Android的样子。 

▍为什么自动驾驶需要操作系统？

一个汽车驾驶系统运行的软件包括感知、控制、决策、定位等一系列高计算消耗，逻辑十分复杂，对安全可靠性要求特别高的程序，简单的单片机肯定搞不定，需要建立在一个成熟的几乎五脏俱全的通用操作系统基础上，同时要满足实时性、分布式、可靠性、安全性、通用性等要求。从头搞一个操作系统是非常不明智的做法，所以对于没有风河Vxworks家底儿的玩家，首选是Linux，然后在Linux 基础上使用中间件的形式去扩展。  

汽车行业的人可能会第一时间站出来表达不同意见，因为搞汽车电子的最熟悉的嵌入式系统是类Unix的QNX, 以往的汽车电子行业的嵌入式开发集中在汽车娱乐系统控制， QNX 体积小速度快，非常稳定和可靠，因此它占据了汽车电子近75%的份额。但是简单几个问题就能理解为什么它不可选：要做感知，目前公认的解决方案是使用深度学习网络进行识别，有现成的深度学习框架运行在QNX上吗，它能驱动GPU加速吗？ 

操作系统的选择更要考虑开发的难度、后续的扩展性和解决方案的开放性。Linux对于自动驾驶及机器人运动控制而言，可以说够，也可以说不够。因为机器人和自动驾驶汽车的自主运动，有一个很大的共性：各种传感、驱动以及模块是各自独立运作的，决策、感知等算法是完全独立的模块，各自工作，同时要互相交流，使用一种规格一致、统一的交流语言。每个模块需要别的模块配合，也就是我们常说的分布式协作系统。 

如果把每个模块放入一个个独立的进程中，进程间通信将是一个十分重要的考虑因素。我们知道的Linux操作系统提供的一系列进程间通信的手段：信号量、队列、管道、共享内存、套接字，可以去做，但这需要大量的技术编码工作，而我们的注意力是算法，不是通信。那怎么解决这个问题呢？

▍选择ROS操作系统

ROS完全封装了模块之间的通信细节，提供了优雅的方式进行各种类型的交互（ 一对一、多对一、多对多、有返回、无返回、同步、异步），像这种通讯框架，会有很多其它现成的东西可以用。

ROS 巨大的价值不仅如此，因为它出身高贵，前身是斯坦福人工智能实验室的机器人项目STAIR，后来由Willow garage 组织维护。它是免费的开源框架，软件架构清晰一流，提供： 

• 多语言接口支持

• 广泛的库文件实现以机动性、操作控制、感知为主的机器人功能

• 大量的工具组合用以配置、启动、自检、调试、可视化、登录、测试、终止分布式计算系统

 ROS为常用的机器人和传感器提供了硬件驱动接口。从软件架构角度讲，它是 一种基于消息传递通信的、分布式多进程框架。ROS很早就被机器人行业使用，有很多知名的机器人开源库， 例如：

• 基于Quaternion 的坐标转换

• 3D点云处理驱动

• 规划方面的MoveIt

• OpenRAVE 规划库

• 控制方面的OROCOS 实时运动控制库

• 视觉图像处理方面的OpenCV 和PCL开源库

• 定位算法SLAM等

这些良好的特性吸引了成千上万的机器人爱好者加入贡献，提供了机器人相关的各种算法包，各大硬件传感器厂商，会缺省提供ROS的驱动Wrapper。ROS的支持与发展依托着一个强大的社区。ros.org尤其关注兼容性和支持文档，提供了一套“一站式”的方案使得用户得以搜索并学习来自全球开发者数以千计的ROS程序包。这个生态是无价的，正因为这样，ROS基本是科研单位和机器人相关行业的首选，更准确的说法是选择Ubuntu+ROS。 

如今是技术开放的时代，做技术框架选择时，不能一味硬着头皮重复造轮子。在选择上，除了看技术先进性， 更要看技术的生态环境，参与到一个强大、开放、可扩展的技术生态中，从中索取和贡献是更明智的。选择Linux, 是因为生态，选择ROS，更是因为生态。

 ▍ROS在自动驾驶上有什么缺陷？

ROS在机器人运动控制中完全够用，但是用于自动驾驶工程实践，其实是有很多问题的。

1. 单点失败问题

ROS的框架示意图如下，我们可以看到各个节点之所以可以互相认识，互相通信，是因为它们在启动前，把自己的信息告知一个统一的ROS Master，ROS Master 是一个名字服务器。

这样就会造成一个问题， 这样的架构不是一个纯粹的分布式架构，有单点失败问题，这个单点专指 ROS Master, 其它应用节点的损失是互不影响的。这个问题对于自动驾驶这种要求高可靠性，甚至会为此设计冗余备份机制的场景来说是完全不能接受的。 ROS 节点与节点之间的通信是Socket，即使一对多的情况， 也是分解成 N对Socket， 如果是多对多，读者可以想象。

2. 带宽拥塞

自动驾驶有很多传感器，如图：

它对于带宽资源是十分敏感的，以摄像头传感器为例，因为自动驾驶要高速行驶，采样率要高，至少每秒30帧， 以1080P的像素计算，大概为 180M/S，而且传感器的数据不只一个节点感兴趣，见下图：

这个带宽的占用是很恐怖的， 这还只是一个摄像头，一般汽车配置多个摄像头， 还有64线雷达，数据量可想而知。当这种订阅者众多的时候，在ROS当前机制下带宽资源消耗是巨大的。 

3. 消息不支持向前兼容

ROS 传递的消息不支持向前兼容，也就是说在后面应用中，在已经定义的消息类型中，增加一个字段，这样新节点和老节点之间就这个消息进行沟通就会发生错误，准确的讲是md5校验失败。接口兼容性问题会对历史数据的使用造成很大的影响，尤其是自动驾驶领域，海量的历史数据是宝库，不能用了，或者做大量的处理才可以用都是不可接受的。

4. 安全问题

如果一个ROS node 被挟持，黑客可以通过这个node 将资源耗尽，进而将这个系统搞垮。如果ROS node与node之间的消息被截获或者伪造，那么自动驾驶汽车可能会被黑客控制。

这四个主要问题，原生的ROS 1.0 都是无法解决的，ROS 2.0 虽然解决了部分，但还在测试阶段， 自动驾驶玩家是没有时间和耐心去等待ROS 2.0成熟的。

 ▍如何解决上述问题？

1. 单点失败问题的解决

解决单点失败一般有两个思路， 一个思路如百度自动驾驶Apollo 采用的一种叫RTPS 的服务发现协议，通过节点之间的自动发现，完成纯粹意义上的p2p分布式拓扑结构，见下图：

 

ROS 2.0 其实也是用相同的思路去解决这个问题，它采用工业级别的DDS 中间件，节点之间可以自动发现。

另一个思路是ROS Master 这个关键节点采取备份机制，如果ROS Master 宕机了，备份节点会顶上，可以采用开源的分布式协调框架zookeeper 去完成这个功能，见下图：

2. 带宽拥塞问题的解决

对于进程通讯使用socket 造成带宽的拥塞和CPU 的负担，方案很简单，进程通信采用共享内存机制，还是拿摄像机为例子，见下图：

使用共享内存的好处，相比于套接字，越是多对多，对带宽利用的优化越明显。ROS 2.0 采用的DDS 中间件方案，已经考虑了进程间通信采用共享内存。

3. 接口兼容问题的解决

对于接口兼容问题， 百度自动驾驶Apollo 框架采用的方案是使用谷歌开源的protobuf（中间消息结构，类比XML,JSON，包括消息传递，序列化和反序列化机制）封装成ROS msg，来代替原生的ROS msg， protobuf 提供了良好的消息向前兼容性。这样修改不破坏原生ROS msg机制，而且仍然使用这个机制通信的其它ROS 节点，是一个比较干净的侵入修改方案。

4. 安全问题的解决

安全方面的问题，可以采用LXC(linux container) 这种轻量级虚拟化技术，把每个ROS node放入沙盒，限制每个ROS node 权限。节点与节点的通信消息可以进行加密解密处理，防止中间有人攻击。

 ▍结语

以上，我们讲述了为什么自动驾驶和机器人运动控制都采用ubuntu+ROS 作为操作系统的背景和原因，总结了目前原生 ROS 1.0 在自动驾驶场景使用的问题及参考修改方案。希望通过本文的描述，大家会对机器人和自动驾驶的软件操作系统层面有一个大概的了解。