ROS探索总结-42.ROS产品化探索之通信机制篇

ROS1/一代机器人系统 少儿编程 851浏览 0评论
ROS探索总结

本文转载自古月居,原作者古月,原文链接:https://www.guyuehome.com/1534。

ROS探索总结-42.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探索总结-42.ROS产品化探索之通信机制篇

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

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

  • 首先来看第一个部分:

通信机制

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

ROS探索总结-42.ROS产品化探索之通信机制篇

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

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

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

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

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

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

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

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

  • 首先聊聊百度

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

ROS探索总结-42.ROS产品化探索之通信机制篇

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

http://link.zhihu.com/?target=https%3A//github.com/ApolloAuto/apollo-platform

或者参考这篇解读: 干货曝光(二)|资深架构师首次解密Apollo ROS有何不同!

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

ROS探索总结-42.ROS产品化探索之通信机制篇

  1. 去中心化,也就是干掉ROS Master,这部分使用了DDS技术;
  • DDS虽然提供的也是发布/订阅模型的通信机制,但商用版本可以达到军工标准,国际上有几家大公司也在推进DDS在ROS 2.0中的应用。

ROS探索总结-42.ROS产品化探索之通信机制篇

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

ROS探索总结-42.ROS产品化探索之通信机制篇

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

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

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

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

ROS探索总结-42.ROS产品化探索之通信机制篇

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

ROS探索总结-42.ROS产品化探索之通信机制篇

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

ROS探索总结-42.ROS产品化探索之通信机制篇

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

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

ROS探索总结-42.ROS产品化探索之通信机制篇

个人看法

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

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

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

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

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

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

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

  • 那就请使用第二种方法!

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

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

您必须 登录 才能发表评论!