笔者之前参与过基于 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可以理解为数据提供者和接收者之间的合约。
- 服务质量策略(QoS)。DDS规范定义了丰富的服务质量策略(Quality of Services Policies)，QoS是一种网络传输策略，应用程序指定所需要的网络传输质量行为，QoS服务实现这种行为要求，尽可能地满足客户对通信质量的需求，DDS定义QoS策略使其对复杂网络环境的适应性和鲁棒性大大增强，优化网络传输质量。QoS可以理解为数据提供者和接收者之间的合约。- 参与者（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中非常重要的一环，控制了各方面与底层的通讯机制，主要从时间限制、可靠性、持续性、历史记录几个方面，满足用户针对不同场景的数据应用需求，可以参考下边的图片和表格，看一下这几个原则可以哪些配置
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】
思考
- 目前深度学习和各种算法对于这样的系统感觉像一个资源黑洞，有效的利用 GPU 和 FPGA 加快运算是很重要的
- 当前正在使用的 自动驾驶系统 Waymo 和 百度的系统不知道如何处理这些问题，如何和环境感知，如何使用生产环境下的 深度学习算法， 毕竟论文和实际应用还有着很长的距离。
- 自动驾驶从最初的 2020是自动驾驶元年， 到五年内实现，到现在有些人觉得19年内难以实现，都是有原因的。 作为科研方向，不知道怎么水论文了