您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
浅谈ROS的产品化探索(一)—— 通信机制篇
 
   次浏览      
 2018-5-28 
 
编辑推荐:

本文于exbot,介绍了ROS1.0能否产品化?通信机制,百度All in人工智能隐藏的ROS身影,研究者对ROS中的解决方案等。

近几年,机器人和人工智能繁荣发展,曾经运行在实验室的机器人已经逐渐走入千家万户的生活。作为机器人开发利器的ROS也得到了非常广泛的应用,成为机器人领域的普遍标准。

ROS原本针对科研领域的PR2机器人开发,这种大繁荣的景象远远超过ROS的最初目标,也使得ROS的缺陷在广泛应用的同时暴露无遗:

1. 缺乏构建多机器人系统的标准方法;

2. 在Windows、MacOS、RTOS等系统上无法应用或者功能有限;

3. 缺少实时性方面的设计;

4. 需要良好的网络环境保证数据的完整性,而且网络没有数据加密、安全防护等功能;

5. ROS 1的稳定性欠佳,研究开发与上市产品之间的过渡艰难;

正是由于ROS1存在种种问题,才促使ROS2.0的出现。ROS2.0虽然从根本上解决了ROS1.0的许多问题,但是却无法短时间替代ROS1.0在庞大生态系统中的关键位置,只能借助越来越多的关键开发者逐渐推进。所以从目前ROS2.0的情况来看,近几年ROS1.0的应用还会是主流。

ROS1.0能否产品化?

那么目前的ROS1.0到底能不能在机器人的产品化过程中应用?如果可以,又该如何应用于机器人产品的开发?

笔者不才,使用ROS进行了两年的机器人产品开发,过程当中也总结了一些经验,就简单谈一谈对于这个问题的看法。

在谈ROS的产品化前,我们需要明确一个问题,ROS到底是什么,可以参考之前的文章:

"Powering the world’s robots" 的ROS是什么?

ROS的核心虽然是通信机制,但是如今的ROS已经远远超过通信机制的范畴。总体来讲,ROS包含四个部分:通信机制、开发工具、应用功能、生态系统。

所以在说ROS产品化的时候,我们需要针对这四个方面进行讨论。由于内容较多,这个主题会分为几篇文章分别讨论。

首先来看第一个部分:

通信机制

点对点的分布式通信机制是ROS的核心,使用了基于TCP/IP的通信方式,实现模块间点对点的松耦合连接,可以执行若干种类型的通信,包括基于话题(Topic)的异步数据流通信,基于服务(Service)的同步数据流通信,还有参数服务器上的数据存储等。

但是这种通信机制的实时性和稳定性不好,而且强依赖于中心节点ROS Master。比如我们在机器人产品开发的过程中,就遇到无数类似下边的问题:

1. 在进行压力测试时,系统连续运行一周时间,运行到第四天时(时间不确定),ROS Master莫名宕机,整个系统不再受控,某个节点突然失效也是时有发生的。。。

2. 系统存在大量话题和数据时,本地传输的数据延时大而不确定,远程传输的数据更是经常受到带宽和处理性能的影响。。。

3. 在系统中频繁创建话题时(比如连续创建几百个话题),某些话题的数据莫名就消失了。。。

4. 通信的实时性较差,没办法实现毫秒级的机器人控制。。。

5. 通信数据是开放式的,没有加密,只要在网络中的节点都可以轻松获取。。。

6. 核心机制的性能没有优化,运行在配置较低的ARM上会占用过多资源。。。

这样看来,好像ROS的核心部分在机器人产品中完全没有可用性呀!如何去突破这个瓶颈呢?先来看看部分开发者的改良方法。

首先聊聊百度。

自从百度All in人工智能之后,无人驾驶汽车平台Apollo就被推上了风口浪尖,甚至还登上了2018春晚的舞台。在这个吸睛无数的Apollo平台背后,就隐藏着ROS的身影。

Apollo平台基于ROS开发,但是对通信机制部分进行了众多改变,有兴趣的小伙伴可以看Apollo改良之后的ROS:

https://github.com/ApolloAuto/apollo-platform

或者参考这篇解读:

资深架构师首次解密Apollo ROS有何不同!

总结而言,百度对ROS的优化有以下三点:(咋看上去,这些优化有点像ROS 2.0干的那些事儿)

1. 去中心话,也就是干掉ROS Master,这部分使用了DDS技术;

DDS虽然提供的也是发布/订阅模型的通信机制,但商用版本可以达到军工标准,国际上有几家大公司也在推进DDS在ROS 2.0中的应用。

2. 使用共享内存的方法,优化大数据传输的瓶颈;

共享内存也是ROS2.0中时间敏感型数据通信的方法,吞吐量和传输速度肯定可以得到很大程度的优化,同时占用的CPU资源也比较少。

3. 使用Protobuf优化数据格式的兼容性。

Protobuf是google开源的一种结构化数据存储格式,百度拿它取代了ROS中的Message,可以向后兼容数据协议的扩展。

无人驾驶汽车的稳定性是一个性命攸关的问题,百度敢对ROS进行大刀阔斧的优化,也正说明了ROS的行业认可度和强大生命力。

再来聊聊研究者对ROS中Master宕机、安全性和实时性问题的解决方案。

在ROScon2017上,来自USA Northeastern University的研究者介绍了一个名为“DMCTP”的包,当ROS Master崩溃时,DMCTP会缓存所有状态和数据,并且重启Master完成系统恢复。

同在ROScon2017上,另一群研究者提出了“SROS”的概念,也就是为ROS附加一系列安全增强策略:安全传输层、访问控制层、进程配置层等。

在ROScon2016上,针对实时性问题,还有研究者为ROS增加了实时性扩展,称为——RTROS。

对这几个研究感兴趣的小伙伴可以直接看ROScon历届的分享视频和ppt资料:

https://roscon.ros.org/

基于ROS的机器人产品有不少已经投入使用,除上边提到的百度无人驾驶汽车,还有另外一个开源无人驾驶汽车平台Autoware、NASA部署在国际空间站的Robonaut 2机器人等,目前很多大公司的开源部门也在推进ROS的产品化应用。

综观这些机器人产品和平台,都可以说是基于ROS开发的,但是在ROS通信机制部分,也都进行大量的优化和改良。

这种做法对于创业型的公司来讲,如果不是以ROS的改良作为产品的话,往往都不愿意去干这件事情,费时费力。那么对于小公司来讲,如果不想去动ROS的核心通信部分,应该怎么做呢?

这就要说回笔者在创业过程中的实践了。大概有两种方法:

第一种:自己不愿意做,就用别人做好的呗;

ROS是一个庞大的开源社区,上边提到的那些ROS优化,基本上都可以在社区中找到开源实现,或是找其他公司做好的成熟产品,站在别人的肩膀上继续前进。

但是这样也有问题,一方面,别人实现的功能不一定完全符合自己的需求,另外一方面,这些实现的相关文档不多,有问题还得从源码上解决。

那就请使用第二种方法!

第二种:自己不愿意做,也不想基于其他平台做,那就别强求了。

这就是笔者创业公司采用的策略——放弃ROS的核心通信机制部分。这句话说来容易,做起来难!毕竟机器人系统还是需要通信功能的,于是我们重新设计了一个。。。

 

   
次浏览       
相关文章

基于图卷积网络的图深度学习
自动驾驶中的3D目标检测
工业机器人控制系统架构介绍
项目实战:如何构建知识图谱
 
相关文档

5G人工智能物联网的典型应用
深度学习在自动驾驶中的应用
图神经网络在交叉学科领域的应用研究
无人机系统原理
相关课程

人工智能、机器学习&TensorFlow
机器人软件开发技术
人工智能,机器学习和深度学习
图像处理算法方法与实践