近几年，机器人和人工智能繁荣发展，曾经运行在实验室的机器人已经逐渐走入千家万户的生活。作为机器人开发利器的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资料：
▼
基于ROS的机器人产品有不少已经投入使用，除上边提到的百度无人驾驶汽车，还有另外一个开源无人驾驶汽车平台Autoware、NASA部署在国际空间站的Robonaut 2机器人等，目前很多大公司的开源部门也在推进ROS的产品化应用。
综观这些机器人产品和平台，都可以说是基于ROS开发的，但是在ROS通信机制部分，也都进行大量的优化和改良。
这种做法对于创业型的公司来讲，如果不是以ROS的改良作为产品的话，往往都不愿意去干这件事情，费时费力。那么对于小公司来讲，如果不想去动ROS的核心通信部分，应该怎么做呢？
▼
这就要说回笔者在创业过程中的实践了。大概有两种方法：
第一种：自己不愿意做，就用别人做好的呗；
ROS是一个庞大的开源社区，上边提到的那些ROS优化，基本上都可以在社区中找到开源实现，或是找其他公司做好的成熟产品，站在别人的肩膀上继续前进。
但是这样也有问题，一方面，别人实现的功能不一定完全符合自己的需求，另外一方面，这些实现的相关文档不多，有问题还得从源码上解决。
那就请使用第二种方法!
第二种：自己不愿意做，也不想基于其他平台做，那就别强求了。
这就是笔者创业公司采用的策略——放弃ROS的核心通信机制部分。这句话说来容易，做起来难！毕竟机器人系统还是需要通信功能的，于是我们重新设计了一个。。。
（未完待续）
PS. 下篇预告：浅谈ROS的产品化探索（二）——开发工具篇
