笔者之前参与过基于 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_centerDDS中的模型就人性化多了:
- 参与者(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年内难以实现,都是有原因的。 作为科研方向,不知道怎么水论文了