智能汽车中机器人操作系统的解析-电子发烧友网

ROS与智能驾驶

ROS全称Robot Operating System，直接翻译就是机器人操作系统。虽然名字里含有“操作系统”的字眼，但ROS与Windows和Linux等操作系统不一样，它实际上是一套软件库和工具，可以帮助用户快速建立机器人应用程序。在软件层面上，ROS是一种中间件。什么是中间件？中间是相对的，有“上”和有“下”的时候就有“中间”。这感觉就像是“中产阶级”，没有严格界限。所以在有上层软件和底层软件的语境下，这中间的软件就是“中间件”。ROS就是介于底层操作系统（如Linux）和上层业务应用软件（如OpenCV）之间的中间件。

那么ROS能出现在焉知智能汽车的公众号里，它跟智能汽车又有什么关系呢？实际上智能汽车就是一种机器人。举个例子，您有没有觉得家里的扫地机器人和智能驾驶汽车非常像？近年来，智能驾驶无疑是汽车工业的当红炸子鸡，而汽车的智能驾驶化实质上也是汽车的机器人化。我们常说的“感知”、“决策”和“规控”等，其实也是来自于机器人领域。智能网联汽车的功能域控制器划分，电子电气架构的演变都能或多或少看到机器人的影子。甚至有些公司就是借用机器人传统术语来作为传统车企智能化改革的口号和产品蓝图。

机器人是多专业知识交叉的学科，通常涉及传感器、驱动程序、多机通信、机械结构、算法等，为了更高效地进行机器人的研究和开发，选择一个通用的开发框架非常必要。而ROS就是最流行的框架之一。当机器人和智能驾驶汽车一相逢，ROS顺理成章的成了很多团队开发智能驾驶的选择，很多智能驾驶的算法应用都是基于ROS来开发的。中国智能驾驶界大名鼎鼎的“Apollo”就是基于ROS二次开发改进的。而从另一个角度来看，近年来ROS也成为了智能网联工程师岗位招聘要求的高频词。熟练掌握ROS的汽车工程师毫无疑问是人才市场上的“香饽饽”。

02 ROS历史简介

首先提一下，ROS有ROS1和ROS2两个大分支。没有特别说明时，一般ROS都指ROS1。简单来说ROS由来已久，进化过程中发现已有架构必须革新才能满足更多需求，于是就开辟了ROS2，并把之前的版本统称ROS1。

展开来看，ROS系统最早起源于2007年斯坦福大学人工智能实验室的STAIR项目与机器人技术公司Willow Garage的个人机器人项目（Personal Robotics Program）之间的合作，2008年之后由Willow Garage公司推动其发展。几番测试后于2010年推出了正式发行版本：ROS Box Turtle。比较有趣的是，ROS各版本均以龟作为发行代号，至今已设计出十多种造型奇特的“ROS龟”。而每一次ROS发布新版都会按照字母顺序改一个名字。例如ROS Box Turtle后是ROS C Turtle，再是Diamondback……2020年5月发布的ROS Noetic Ninjemys则到了字母“N”，也是ROS1的最后一个版本。

图2：4个ROS版本及其ROS龟海报

从2008年至2013年，ROS主要由Willow Garage公司管理维护，但这并不意味着ROS是封闭的系统。相反，ROS由众多学校及科研机构联合开发及维护的，这种联合开发模式也为ROS系统生态的构建与壮大带来有力的促进。2013年，Willow Garage公司被Suitable Technologies公司收购，此前几个月，ROS的开发和维护管理工作被移交给了新成立的开源基金会Open Source Robotics Foundation。而随着ROS的优化和丰富，对ROS的要求也越来越多，一些原始架构和设计已经不能够满足，于是催生了ROS2。经历几个测试版后，2017年ROS2正式发布了Ardent Apalone版本，之后每版升级同样是迭代一个字母和ROS龟海报。最新一版ROS2是今年5月份刚发布的Humble Hawksbill。

03 为什么智能汽车选择ROS

上文提到，智能驾驶汽车就是一种机器人。但是当智能汽车选择开发框架的时候，为什么会这么多人选择ROS呢？肯定不是因为它的名字里有“Robot”这么简单。而结合上文提到的ROS1和ROS2时间线，这个关于智能驾驶的选择肯定在ROS1上开始的。究其原因，有这3个重要因素：

1.已有的开源代码丰富。

许多智能驾驶需要用到的算法，都能在ROS生态中找到已经成熟的代码。例如建立地图的算法，使用激光雷达或GPS定位算法，沿着地图规划路径算法，避开障碍物的算法，摄像头视觉处理算法等等。..。..这些轮式机器人导航所需的算法在ROS上是现成的，几乎都可以直接适用于智能驾驶汽车。

2.具备配套的可视化工具。

ROS自带一套图形工具，可以方便地记录和可视化传感器捕获的数据，并以全面的方式表示车辆的状态。此外，它还提供了一种简单的方法来实现定制化的可视化需求。这在开发控制软件和调试代码时非常有用。如果您曾经在电脑前看过智能驾驶汽车传感器的原始数据，做过调试，相信您会深刻理解一个靠谱的数据可视化工具是有多么重要。

图3：利用ROS RVIZ三维可视化点云数据

3.简单好上手。

在开展一个新领域的时候，没有什么比把东西先做出来更重要了。基于ROS来开发一个智能驾驶汽车项目是比较简单的。例如从一个简单的轮式机器人开始，配备一对轮子、一个摄像头、一个激光扫描仪和ROS导航软件栈，开发者可以在几个小时内就可以完成设置，让小车自主行进避障。这种快速上手也可以帮助新手快速理解整个运作基础和框架，然后再转向更专业更深入的研究。某宝上就有很多基于ROS的智能小车，很多机构也是基于这些套件开展智能驾驶培训的。

04 ROS1在汽车应用上的弱点

当然，ROS并不是完美的，尤其是ROS1应用在智能汽车上存在不少局限性。早年间ROS1应用于智能驾驶研发时，正是由于这些局限性，各大公司都需要在ROS上进行二次开发，以满足智能汽车要求。那ROS1究竟有哪些弱点呢？

1.单点失效。

如下图所示，ROS1的通讯机制是存在主从结构的。也就是节点之间的通讯都依赖于一个Master。在这种集中式通讯方式下，如果Master失效了，那么系统就会崩溃。这在汽车行业功能安全的要求下，无疑是太脆弱了。

图4：ROS1通讯机制示意图

2.实时性差。

ROS1就是基于Linux操作系统之上的。Linux原生不是实时操作系统，ROS1自然也没有实时性的设计考虑。ROS1设计之初更多地从实现最高性能的角度出发，在任务调度和线程切换等机制设计上并没有保证实时性所要求的“确定时间”。例如汽车动力底盘域常见的轮速信号就很容易在原生ROS1中失真。

3.缺乏网络安全机制。

ROS1并没有实现任何安全机制来防止第三方进入ROS1网络并读取节点之间的通信。这意味着任何能够进入汽车网络的人都可以进入ROS1的信息传递并劫持汽车。这在汽车网络安全法规日益严格的背景下，也无疑是力不从心的。

05 ROS1与ROS2

早年间，各大公司都针对ROS1弱点做了很多优化，以让其适用于汽车。而这些研究和改进当然也反馈到ROS组织本身，所以也就有了上文提到的ROS2。那么ROS1和ROS2有什么差别呢？ROS2对这些弱点有改进吗？话不多说，我们先来看看两者的系统架构框图对比。

图5：ROS1和ROS2的系统架构框图对比

由下往上看，在操作系统层，ROS2比ROS1支持的底层操作系统更多，也支持实时操作系统（RTOS）了。这就让ROS2可以支持更多样化的嵌入式硬件，例如汽车应用中一些轻量化的ECU。

在中间层，ROS1更多地依赖TCP和UDP协议，而在ROS2中则引入了DDS。DDS全称是Data Distribution Service 数据分发服务，是一种分布式实时通信中间件协议，也是一个被很多公司实现的工业标准。DDS采用发布/订阅体系架构，强调以数据为中心，提供丰富的服务质量（QoS）策略，以保障数据进行实时、高效、灵活地分发。

正是基于DDS的通讯机制，ROS的应用层就不再需要Master节点。节点之间采用自发现机制，找到彼此，进而建立稳定的通信连接。这对于满足功能安全需求，有很大帮助。当然，ROS1和ROS2的应用层软件接口是匹配的，让ROS1上开发的应用软件能快速复用部署到ROS2上，也是ROS2的设计目标。

由此可见，上文提到的ROS1在汽车应用上的弱点，在ROS2上都得到了针对性甚至是根本性的改善。

06 ROS与AUTOSAR Adaptive

在汽车领域谈软件，自然是离不开AUTOSAR的。这些年汽车硬件和软件的发展本身也是日新月异。AUTOSAR也是在这背景下不断优化和自我革新，AUTOSAR Adaptive就是针对多核动态操作系统的高资源环境在奋起直追，希望站稳汽车软件架构老大的地位。ROS2和AUTOSAR Adaptive都是中间件，那它们在不断升级进化的过程中，有没有朝着某个共同的方向，进而出现交汇点？答案是有的。最明显的就是DDS的通讯机制。

图6：DDS在AUTOSAR Adaptive通讯中的位置

如上图所示，AUTOSAR Adaptive中的通讯管理模块就加入了DDS的部分，并对DDS相应的功能安全和网络安全都作了定义和描述。通过ara：：com可以统一CAN PDU、SOME/IP和DDS的通讯。而DDS就是ROS2中最核心的部分。所以聚焦于这个汇合点，可以结合ROS2和AUTOSAR，取两者之所长。

事实上这个关键点已经被很多公司企业抓住，并开发出了不少商用的产品。例如下图就是Apex.AI公司的产品示意图。Apex.AI将Apex.OS节点（匹配ROS节点）与AUTOSAR Adaptive和AUTOSAR Classic平台连接起来。AUTOSAR arxml（包含数据类型和接口的描述）可以直接作为配置输入。这使得设置可以灵活应对服务定义的变化。ROS Topic的数据最终可以在AUTOSAR ara：：com或RTE中使用。