[讨论] ROS1 为何不是可靠的系统

笔者之前参与过基于 ROS1 的机器人开发， 但是如大多数创业公司一样， 这些系统也都仅仅限于demo 阶段。失败的原因一方面是市场的因素， 一方面也是当前的机器人系统并不成熟， 开发者必须在及其有限的资源下 板载 CPU，内存等资源开发一个感知决策系统，但在当前 ROS1 的状况下总是无法做到稳定，接下来是我的讨论，欢迎大家评论中留言。

自动驾驶系统中的数据量越来越大

自动驾驶中用到的传感器很多，每种都有自己的劣势，但也都存在自己的盲区。

• 3D 激光雷达， 只能对三维空间进行稀疏的采样， 线束越多采样点越密集但数据量也加大， 对玻璃无效
• 2D 激光雷达， 只能探测水平面的物体， 无法感知立体，对玻璃等透明物体无效
• RGB 摄像头， 空间感知较差，但纹理丰富，能够对近距离物体实现 分类和识别（机器学习算法), 远距离无效
• odom 轮式里程计， 误差较大
• IMU 惯性测量单元，累计误差较大。

目前的趋势是3D激光线束越来越密集了，探测距离也越来越远，但是数据量也爆炸式的上升， 海量的数据处理对于一个实时操作系统是一个很现实的问题。但这也是目前 鲁棒性较高的方式之一。【 所以稠密点云处理是方向之一？】
所以如此庞大的数据量，需要实时的处理，对系统处理能力和稳定性 要求很高 , 好奇当前成熟的自动驾驶系统处理如此庞大数据量的策略。

ROS1 的缺点

• ROS因为将功能分布在各个节点之中，节点间基于消息机制通信，通讯部分消耗了很多系统资源。尤其是当所有节点位于同一个处理器时，ROS仍然一直执行相应的消息分发，节点间的数据传递通过内存复制，大量的系统资源都浪费在通讯上，使得系统必须选用高性能的处理器和存储系统以弥补损耗。换句话说，利用ROS来实现SLAM，需要配备性能优越的硬件设备，这对于一些小型化嵌入式平台，尤其是实际的机器人产品里，其对计算资源、存储空间的消耗会使成本大幅上升。
• 软硬件数据量过载，由于ROS1 有一个核心的master 节点，如果崩溃后如何修复，以及各个模块如何有效的沟通。

ROS2 - 基于DDS 的消息分发机制

• 系统可靠性 -> 去中心化
• 系统通信性能提升 -> memory-map 机制
• 资源管理和安全 -> 节点划入 Linux Container 中,节点间相互隔离；信息加密防止被劫持

什么是 DDS（Data Distribution Service）

• DDS（Data Distribution Service）是基于以数据为核心的设计思想提出的，定义了描述网络环境下数据内容/交互行为和服务质量要求的标准技术
• DDS (数据分发服务) 工业级别中间件，通信节点动态发现，用shared memory 方式使得通信效率边高
• DDS 使所有节点的通信拓扑结构都依赖于P2P 自我发现模式，无master 中心节点，
• 在该模型下分布式节点在网络上以发布或订阅的方式传输数据，节点可以是发布者或订阅者，或者既是发布者又是订阅者。
• 网络中的数据对象用主题((Topic)做标识，分布式节点在全局数据空间中发布或订阅感兴趣的主题信息。
• 各个节点在逻辑上无主从关系，点与点之间都是对等关系.通信方式可以是点对点、点对多、多对多等，在QoS的控制下建立连接，自动发现和配置网络参数

DDS 缺点：

• DDS 本身的资源消耗
• DDS 接口复杂

DDS组成模型

• DDS内所有的成员都是Entity，DDS中的任两个Entity（实体角色）通信都必须在同一个Domain 内进行交互，即他们初始化时DomainID是同一个，并且不同Domain的DomainID必须唯一。Domain内的DomainParticipant是服务的入口点，任何DDS应用都需首先获取DomainParticipant，然后通过Domain Participant获取其他服务，如Publisher、Subscriber、Topic等。
  - 服务质量策略(QoS)。DDS规范定义了丰富的服务质量策略(Quality of Services Policies)，QoS是一种网络传输策略，应用程序指定所需要的网络传输质量行为，QoS服务实现这种行为要求，尽可能地满足客户对通信质量的需求，DDS定义QoS策略使其对复杂网络环境的适应性和鲁棒性大大增强，优化网络传输质量。QoS可以理解为数据提供者和接收者之间的合约。
  ![在这里插入图片描述](https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMzLnpoaW1nLmNvbS84MC92Mi1jZjJjMDgwMWIzYTU5YjAxNzRmMDNlNDg3M2M3ODhmNl83MjB3LmpwZw?x-oss-process=image/format,png#pic_center

  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中非常重要的一环，控制了各方面与底层的通讯机制，主要从时间限制、可靠性、持续性、历史记录几个方面，满足用户针对不同场景的数据应用需求，可以参考下边的图片和表格，看一下这几个原则可以哪些配置

ROS2 VS ROS1

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

ROS 的 进展

最后我们来看看 ROS2 走到哪一步了， 还有活着吗？ 未来在哪里？

ROS2 发行版本历史

版本名	发行时间	特点
Eloquent Elusor	Nov 22nd, 2019
Dashing Diademata	May 31st, 2019
Crystal Clemmys	December 14th, 2018
Bouncy Bolson	July 2nd, 2018
Ardent Apalone	December 8th, 2017
beta3	September 13th, 2017
beta2	July 5th, 2017
beta1	December 19th, 2016
alpha1 - alpha8	August 31th, 2015

计划中的版本

Distro	Release date	Supported for	Planned changes
Foxy Fitzroy	May 2020	3+ years	Target Ubuntu 20.04
G-turtle	May 2021 ?

• 可以看出每年都会有一个新的版本计划

ROS2 究竟解决了哪些痛点，办到了那些ROS1 不能办到的事情？

【TO DO】

思考

1. 目前深度学习和各种算法对于这样的系统感觉像一个资源黑洞，有效的利用 GPU 和 FPGA 加快运算是很重要的
2. 当前正在使用的 自动驾驶系统 Waymo 和 百度的系统不知道如何处理这些问题，如何和环境感知，如何使用生产环境下的 深度学习算法， 毕竟论文和实际应用还有着很长的距离。
3. 自动驾驶从最初的 2020是自动驾驶元年， 到五年内实现，到现在有些人觉得19年内难以实现，都是有原因的。 作为科研方向，不知道怎么水论文了

参考

• [ ROS2 Design – ROS on DDS ]
• [ROS 1 与 ROS2 表现对比： Exploring the Performance of ROS2 ]
• ROS2测评——探索ROS2的性能
• [MIT : Too many cooks: Coordinating multi-agent collaboration through inverse planning]
• [ROS 2 Documentation]
• 【人脸检测特征点综述】