本文链接地址:www.guyuehome.com/805
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整体架构的对比，我们来一左一右找不同：
ROS1主要构建于Linux系统之上，一定有很多同学希望在windows或者RTOS上应用ROS开发机器人，原来这个期望是很难实现的，但是ROS2带来了改变，支持构建的系统包括Linux、windows、Mac、RTOS，甚至没有操作系统的裸机。
ROS1的通讯系统基于TCPROS/UDPROS，强依赖于master节点的处理，可以想像master一挂，整个系统会面临如何的窘境。但是从右边ROS2的架构中我们可以发现，之前让人耿耿于怀的master终于消失了，ROS2的通讯系统是基于DDS的（至于什么是DDS，下节详解），同时在ROS2内部提供了DDS的抽象层实现，有了这个抽象层，用户就可以不去关注底层的DDS使用了哪个商家的API。
ROS中最重要的一个概念就是“节点”，基于发布/订阅模型的节点使用，可以让开发者并行开发低耦合的功能模块，并且便于进行二次复用。得益于DDS的加入，ROS2的发布/订阅模型也会发生改变，具体下节再讲。
你肯定还关注到了两个很重要的独立模块，那就是“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中的模型就人性化多了：
参与者（Domain Participant）：一个参与者Participant就是一个容器，对应于一个使用DDS的用户，任何DDS的用户都必须通过Participant来访问全局数据空间。
发布者（Publisher）：数据发布的执行者，支持多种数据类型的发布，可以与多个数据写入器（DataWriter）相联，发布一种或多种主题（Topic）的消息。
订阅者（Subscriber）：数据订阅的执行者，支持多种数据类型的订阅，可以与多个数据读取器（DataReader）相联，订阅一种或多种主题（Topic）的消息。
数据写入器（DataWriter）：应用向发布者更新数据的对象，每个数据写入器对应一个特定的Topic，类似于ROS1中的一个消息发布者。
数据读取器（DataReader）：应用从订阅者读取数据的对象，每个数据读取器对应一个特定的Topic，类似于ROS1中的一个消息订阅者。
主题（Topic）：这个和ROS1中的Topic概念一致，一个Topic包含一个名称和一种数据结构。
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版本。
厚脸无耻的盗用一些对比结果：
如果对这个比较感兴趣的同学，可以下载这篇论文仔细看一下，其中还有作者的对比解释，我就不在这里赘述了（啃了两个多小时，看完即忘完），只说一下我的几点感想：
根据作者的对比数据，我们可以发现ROS2的性能在不同数据量的场景下，表现呈指数级变化，应该是大数据在底层传输的一些处理时间导致的。
不同厂商的DDS产品性能表现，相差巨大，应该根据不同的应用场景选用最佳的DDS产品。
QoS提供了多种配置选项，同样需要根据不同的应用场景，选择最适合自己的配置。
ROS1会丢失初始数据，这一点我只前还没有发现，ROS2看上去在这一点上好了不少。
ROS2目前的整体性能（论文中使用的Alpha版本）并不如ROS1，毕竟还处于开发阶段，而且对DDS的特性支持有限，但是毕竟潜力在那里。
OK，本文洋洋洒洒就到这里，路漫漫其修远兮，吾将上下而求索。最后再来一张图片，Why should I want to use ROS2?
参考资料：
ROS 2.0 Design：http://design.ros2.org/
《Exploring the Performance of ROS2》：http://ieeexplore.ieee.org/document/7743223/
Changes between ROS 1 and ROS 2：http://design.ros2.org/articles/changes.html
数据分发服务DDS技术研究：http://www.appsoft.com.cn/2014/0207/555.html
数据分发服务及其应用：http://www.docin.com/p-771553937.html
