博客

转自：http://blog.exbot.net/archives/3182

ROS已经走过九个年头，伴随着机器人技术的大发展，ROS也得到了极大的推广和应用。尽管ROS还存在不少的局限性，但是ROS社区内的功能包还是逐年呈指数级上涨，为机器人开发者带来了巨大的便利。不少开发者和研究机构还针对ROS的局限性进行了改良，这些局部功能的改善往往很难带来整体性能的提升，机器人开发者对新一代ROS的呼声越来越大，ROS2.0的消息也不绝于耳，终于在ROSCon 2014上，ROS正式发布了新一代ROS的设计架构（




Next-generation ROS: Building on DDS






），2015年8月第一个ROS2.0的




alpha版本






落地，在经过一年多的开发，2016年12月19日，ROS2.0的




beta版本






正式发布。众多新技术和新概念应用到了新一代的ROS之中，不仅带来了整体架构的颠覆，更是增强了ROS2.0的综合性能。

上图是ROS2的目标，也是目前存在与ROS1中的问题，至于如何解决，就让我们慢慢探索ROS2.0时代到底带来了哪些改变。

一、


ROS2.0


的架构

上图所示是ROS2与ROS1整体架构的对比，我们来一左一右找不同：

1. 
   ROS1主要构建于Linux系统之上，一定有很多同学希望在windows或者RTOS上应用ROS开发机器人，原来这个期望是很难实现的，但是ROS2带来了改变，支持构建的系统包括Linux、windows、Mac、RTOS，甚至没有操作系统的裸机。
   
2. 
   ROS1的通讯系统基于TCPROS/UDPROS，强依赖于master节点的处理，可以想像master一挂，整个系统会面临如何的窘境。但是从右边ROS2的架构中我们可以发现，之前让人耿耿于怀的master终于消失了，ROS2的通讯系统是基于DDS的（至于什么是DDS，下节详解），同时在ROS2内部提供了DDS的抽象层实现，有了这个抽象层，用户就可以不去关注底层的DDS使用了哪个商家的API。
   
3. 
   ROS中最重要的一个概念就是
   
   
   “
   
   
   节点
   
   
   ”
   
   
   ，基于发布/订阅模型的节点使用，可以让开发者并行开发低耦合的功能模块，并且便于进行二次复用。得益于DDS的加入，ROS2的发布/订阅模型也会发生改变，具体下节再讲。
   
4. 
   你肯定还关注到了两个很重要的独立模块，那就是
   
   
   “
   
   
   Nodelet
   
   
   ”
   
   
   和
   
   
   “
   
   
   Intra-process
   
   
   ”
   
   
   。在ROS1的架构中
   
   
   
   
   Nodelet
   
   
   
   
   
   
   和TCPROS/UDPROS是并列的层次，当然也是负责通讯的，实际上Nodelet是为同一个进程中的多个节点提供一种更优化的数据传输方式。ROS2中也保留了这种数据传输方式，只不过换了一个名字，叫
   
   
   “
   
   
   Intra-process
   
   
   ”
   
   
   ，同样也是独立于DDS。
   

可以看到，架构的大部分不同都是应为DDS的引入，那么到底什么是DDS？DDS又有什么超能力可以改变ROS呢？

二、


DDS


是何方神圣

DDS


的全称是


Data Distribution Service


，即数据分发服务。这个


DDS


也并不是一个很新鲜的东东，大概在十几年前就已经出生了，应该属于


00


后。它是对象管理组织


OMG


（哦买嘎！


Object Management Group


）在


2004


年正式发布的一个专门为实时系统设计的数据分发


/


订阅标准，最早应用于美国海军，


解决舰船复杂网络环境中大量软件升级的兼容性问题，目前已经成为美国国防部的强制标准，同时广泛应用于国防、民航、工业控制等领域，


成为分布式实时系统中数据发布


/


订阅的标准解决方案。

DDS


的技术核心是以数据为核心的发布订阅模型（


Data-Centric Publish-Subscribe


，


DCPS


），这种


DCPS


模型创建了一个


“


全局数据空间


”


（


global data space


）的概念，所有独立的应用都可以去访问。在


DDS


中，每一个发布者或者订阅者都成为参与者（


participant


），类似于


ROS


中节点的概念。每一个参与者都可以使用某种定义好的数据类型来读写全局数据空间。看到这里，你是不是想起来了


ROS1


中的订阅发布


/


模拟模型，是不是感觉好像和


DDS


也差不了多少。那就让我们来对比一下两者的模型，看看到底差多少？

上图左边是


ROS1


的订阅


/


发布模型，右边是


ROS2


使用的


DDS


的订阅


/


发布模型，乍一眼看上去，感觉就是


DDS


增加了更多的框框，那么这些框框是干什么的呢？

我们先来回顾一下。在原来的


ROS1


中，一个节点想要发布消息，需要现在


master


中注册一下，让


master


知道你这个节点要干什么。另外一个节点想要订阅消息，那么他就需要去问问


master


哪里有这个消息，


master


发现这两个节点相互之间


“


有意思


”


，于是就当个月老牵个线，把


IP


地址告诉他们，接下来两个节点就开始私聊，也就没有


master


什么事了，就算两个节点闹矛盾联系不上，


master


也管不着。

DDS


中的模型就人性化多了：

1. 
   参与者（
   
   
   Domain Participant
   
   
   ）：一个参与者
   
   
   Participant
   
   
   就是一个容器，对应于一个使用
   
   
   DDS
   
   
   的用户，任何
   
   
   DDS
   
   
   的用户都必须通过
   
   
   Participant
   
   
   来访问全局数据空间。
   
2. 
   发布者（
   
   
   Publisher
   
   
   ）：数据发布的执行者，支持多种数据类型的发布，可以与多个数据写入器（
   
   
   DataWriter
   
   
   ）相联，发布一种或多种主题（
   
   
   Topic
   
   
   ）的消息。
   
3. 
   订阅者（
   
   
   Subscriber
   
   
   ）：数据订阅的执行者，支持多种数据类型的订阅，可以与多个数据读取器（
   
   
   DataReader
   
   
   ）相联，订阅一种或多种主题（
   
   
   Topic
   
   
   ）的消息。
   
4. 
   数据写入器（
   
   
   DataWriter
   
   
   ）：应用向发布者更新数据的对象，每个数据写入器对应一个特定的
   
   
   Topic
   
   
   ，类似于
   
   
   ROS1
   
   
   中的一个消息发布者。
   
5. 
   数据读取器（
   
   
   DataReader
   
   
   ）：应用从订阅者读取数据的对象，每个数据读取器对应一个特定的
   
   
   Topic
   
   
   ，类似于
   
   
   ROS1
   
   
   中的一个消息订阅者。
   
6. 
   主题（
   
   
   Topic
   
   
   ）：这个和
   
   
   ROS1
   
   
   中的
   
   
   Topic
   
   
   概念一致，一个
   
   
   Topic
   
   
   包含一个名称和一种数据结构。
   
7. 
   QoS Policy
   
   
   ：
   
   
   Quality of Service
   
   
   ，质量服务原则，这个模块在
   
   
   ROS1
   
   
   中可从没见过，看名称就猜测应该是负责数据质量的。
   
   
   QoS
   
   
   是
   
   
   DDS
   
   
   中非常重要的一环，控制了各方面与底层的通讯机制，主要从时间限制、可靠性、持续性、历史记录几个方面，满足用户针对不同场景的数据应用需求，可以参考下边的图片和表格，看一下这几个原则可以哪些配置。
   

从上边


DDS


的几个重要概念中，我们就可以看到


ROS2


相比于


ROS1


，在以下方面有所提升：

• 
  实时性增强：数据必须在
  
  
  deadline
  
  
  之前完成更新。
  
• 
  持续性增强：
  
  
  ROS1
  
  
  尽管存在数据队列的概念，但是还有很大的局限，订阅者无法接收到加入网络之前的数据；
  
  
  DDS
  
  
  可以为
  
  
  ROS
  
  
  提供数据历史的服务，就算新加入的节点，也可以获取发布的所有历史数据。
  
• 
  可靠性增强：通过
  
  
  DDS
  
  
  配置可靠性原则，用户可以根据需求选择性能模式（
  
  
  BEST_EFFORT
  
  
  ）或者稳定模式（
  
  
  RELIABLE
  
  
  ）。
  

到此为止，我们应该已经对


ROS2


有一个大概的认知了，具体的很多技术细节今后再慢慢探索。

三、


ROS2 vs ROS1

框架看来终觉浅，本文的最后一节，我们来看看目前


ROS2


与


ROS1


相比，性能到底如何？这里的所有对比数据和图片来自于论文《


Exploring the Performance of ROS2


》。

在这篇论文中，作者针对


ROS1


和


ROS2


在延时、吞吐量、线程数、内存消耗等几个方面的性能进行了量化对比，数据量从


256byte


到


4M


，实验条件覆盖了


ROS


分布式的多种使用场景，具有一定的参考价值，也是目前对


ROS2


性能方面量化分析的唯一论文，不过需要注意的是论文使用的


ROS2


是


Alpha


版本。

厚脸无耻的盗用一些对比结果：

如果对这个比较感兴趣的同学，可以下载这篇论文仔细看一下，其中还有作者的对比解释，我就不在这里赘述了（啃了两个多小时，看完即忘完），只说一下我的几点感想：

1. 
   根据作者的对比数据，我们可以发现
   
   
   ROS2
   
   
   的性能在不同数据量的场景下，表现呈指数级变化，应该是大数据在底层传输的一些处理时间导致的。
   
2. 
   不同厂商的
   
   
   DDS
   
   
   产品性能表现，相差巨大，应该根据不同的应用场景选用最佳的
   
   
   DDS
   
   
   产品。
   

3. 
   QoS
   
   
   提供了多种配置选项，同样需要根据不同的应用场景，选择最适合自己的配置。
   
4. 
   ROS1
   
   
   会丢失初始数据，这一点我只前还没有发现，
   
   
   ROS2
   
   
   看上去在这一点上好了不少。
   
5. 
   ROS2
   
   
   目前的整体性能（论文中使用的
   
   
   Alpha
   
   
   版本）并不如
   
   
   ROS1
   
   
   ，毕竟还处于开发阶段，而且对
   
   
   DDS
   
   
   的特性支持有限，但是毕竟潜力在那里。
   

OK


，本文洋洋洒洒就到这里，路漫漫其修远兮，吾将上下而求索。最后再来一张图片，


Why should I want to use ROS2?

参考资料：

ROS 2.0 Design


：




http://design.ros2.org/

数据分发服务


DDS


技术研究：




http://www.appsoft.com.cn/2014/0207/555.html

数据分发服务


DDS


的研究：




http://wenku.baidu.com/link?url=_wsmh0QzQBBs0ewsNEHJemz7dmnYLb9H_mEDr2otpGbfkIsQFGP1o6lRrOr22TlNifL54vqogqpc1Z6x2d9IJkw63mq323TTtXor2yGC21u

数据分发服务及其应用：




http://www.docin.com/p-771553937.html