为什么我选择并且推崇用ROS开发机器人？

如果我们现在想研发一款机器人，应该选择哪一个操作系统呢?其实我们大家平常接触到的操作系统寥寥无几，Windows，MacOS，Linux，iOS，Andoird。ROS虽然全名是Robot Operating System，但本质上不是操作系统，是Linux发行版Ubuntu下的一个用来开发机器人的Middleware，这个没有什么好辩驳的。Android虽然意思是人形机器人，但是我觉得这就只是名字而已，Andy Rubin难道真的是想通过智能手机探秘智能机器人?而且机器人学里的人形机器人一般写成Humanoid。为了规避因“操作系统”产生的歧义，本文中我们讨论研发一款机器人需要怎样的“环境配置”?所以很多概念没有区分是否称得上操作系统。

选择怎样的环境配置，有几点是我们先要搞清楚的。首先我们需要知道实时性是不是必须的。简单的说，如果在系统中是关键变量，系统就需要实时，例如双足机器人动态行走系统就必须实时，但是静态行走的话其实不实时也可以。如果实时性是必须的，我们可以选择Windows + VxWorks，这是在传统运动控制领域非常常见的一个组合。也可以选择QNX操作系统，或者LabView，不过这两个实时的我并没有很多经验。我最早接触的实时操作系统是Windows + Ardence RTX，后来应该改名为IntervalZero。还有就是是否系统需要整体上实时?我们在做双足机器人的时候，运动控制就用到了RTX，但是图像处理并没有。后来我们将运动控制的部分移到了一个ARM7的下位机，上位机的Windows只需要发送action的指令。所以，即便是需要实时，架构也是很灵活的。上位机是没有实时性的强需求的。

当我们希望稍微提高一下机器人复杂度的时候，就会发现另一个需要考虑的问题，进程间通信。在我们用Windows + RTX的时候，进程间通信使用RTX提供的shared memory，不过都是比较慢的图像处理进程向shared memory中写数据，决策和运动控制进程读数据。shared memory显然并不是很好的通信方式，这里不再多加讨论。ROS则使用了一个很好的通信架构，并且是ROS整个框架的一个基础(不论是对于ROS中的topic，service，plugin，actionlib等基础概念还是rviz，navigation package等功能包。想了解这些概念最近多关注下@Top Liu)，所以很多人简单的理解ROS只不过是做了一个通信的架构而已。我必须说明下，进程间通信并不是ROS能够占领机器人开发环境的主要原因。在2010年，我们开发一款类似Atlas的大型人形军用机器人的时候，就用到了进程间通信工具IPC。IPC就是Inter ProCESs Communication，开发者是CMU的Reid Simmons，应该是出现在2000年左右。后来我在帮助本科生参加RoboCup Standard Platform League的时候用过Nao的操作系统NAOqi，这个系统大概是出现在2006年。在NAOqi中，整个通信的架构和ROS非常像了，ROS中的Node在NAOqi中叫一个broker，都是占用一个系统的端口。所以，2010年ROS正式发布Box turtle的时候，通信架构并不是颠覆性的。Android的进程间通信的机制据我了解也是非常强悍的。根据@邵天兰 之前的一次讲座，我也了解到ROS的通信机制放到现在看其实已经有点过时了。所以仅仅从通信机制上评价ROS，意义不大。再有，ROS中的通信机制并不是说不能绕过，其程序本质上还是C++和Python。

我认为ROS最大的贡献就是制定了机器人开发的统一接口标准。因为Willow Garage当年是做移动服务机器人，所以这些标准是首先在移动机器人界统一的。所以ROS的意义，我概括的时候就是六个字，“书同文，车同轨”，极大加速了交流与进步。也是因为这样，机器人学界才慢慢能够形成一些BenchMarking，能够在开源社区形成百花齐放的态势，能够让大家不再深陷于又要搭建硬件又要搭建软件的重复造轮子的困境。其实最主要就是ROS的message，看起来不过是一些头文件，但是可以让我们轻松的替换各种传感器和执行机构，替换软件中的各个算法，现在搭建机器人在我们眼中，就像玩乐高积木，组装一台电脑。

当然，作为一个开发工具，只做到这里是不够的。我看过LabView的开发工具，支持硬件很多，应该标准也很好。Microsoft Robotics Developer Studio是个不错的开发工具，可惜挂掉了，也算是流行了一段时间。针对机器人开发，ROS则提供了很好的可视化、模拟仿真和Debug的工具，专业上讲是非常developer friendly，这也是很多人说为什么ROS适合学习和做研发的原因。不过我觉得这不能支持ROS不适合做产品开发的观点，因为产品成型后，这些调试工具平时都是可以去掉的。关于可视化工具Rviz，模拟仿真的Gazebo，Debug的log等级以及在线调参的rosparam和rqt等等，ROS星火计划都有详细的讲解。

最后，就要说说基因，社区，支持和人才的问题。ROS的基因是移动式服务机器人，LabView的基因是NI，Android的基因是Google和智能手机。ROS社区还算是活跃，虽然机器人的高端玩家比较多，但是整体开发者数量估计也就在十万的量级(ROS answer注册用户也就三万吧)，总量不能和如日中天的Android相比，也是现在背后支持OSRF和google的差距。我也在不同场合聊过很多次，硅谷的机器人创业公司基于ROS开发的比较多(相对国内而言，具体比例不清楚，从RosCon的支持厂商就能看到一些端倪)，但是国内用Android的公司明显在数量上占据上风 。

所以最后要支持本文论点了。不讨论工业机器人(以及类工业机器人的医疗机器人等，以控制为核心)，我们把剩下的机器人品类再划分的细致一些。首先，教育机器人(这里指学习机器人的套件等，不是说用来学习英文或者唐诗的对话机器人，这个归属到情感陪护类)，主要面向k-12的学生，也就是我国高等教育之前的学生，大多就是scratch+单片机，不需要什么系统。不过我觉得这种情况会在未来不久发生改变，主要是教育机器人业内已经有人发现机器人教育和机器人开发的脱节是个问题，那么也就是个商机，但是要等到产业足够大。玩具类机器人不需要开发环境，所以就是玩各种单片机。这些都不是支撑机器人能成为一项颠覆性技术的方向。所以以下主要分析用Android和ROS开发的机器人。[!--empirenews.page--]

情感陪护类机器人，从学术上讲是social robotics，也是研究了很久的一个方向，不过作为这两年机器人产业的一个爆点，也就是@机器人孔博士 提到的消费级服务机器人，我在2014年以前是从来没想到过的。因为整体上来说，机器人的智能还不足以支撑情感陪护这个概念。但是，借助智能手机的发展，尤其是现在集成了大量传感器的智能手机，使Android对硬件比如摄像头、IMU、麦克、通讯元件等等支持很好;其次，一直在致力于改变人机交互方式的巨头们做出了很多惊人的贡献，语音对话取得突破性进展(没有语音的话，触屏交互或者触摸交互也还能将就下。在交互这一点上，基于Linux的ROS很吃亏);再有，因为Android系统的一些附属产品的发展，Android平板、智能家居产品、故事机等，使得儿童陪护机器人整个产业链从硬件到内容都非常完善，一切的一切造就了儿童情感陪护类的机器人爆发。其实从需求和市场上来讲，老年陪护类的机器人应该是未来更大的蛋糕。无论如何，这两年做情感陪护机器人，Android应该是Donimating(要用dota配音去念!)了。

但是，若要进入机器人行业，趁着机器人行业的爆发飞起来，把机器人作为一生的事业，用Android怕是不够的。

首先，由于Android的基因，我们发现情感陪护机器人的大多功能都是手机和平板能够实现的，虽然集成了更多的传感器，比手机这种被动设备在主动性上进步了一些，但是对于实现复杂的功能上和ROS相比后劲不足，也导致产品同质化比较明显。第二，情感陪护类机器人这两年增长确实很快，算在机器人行业里是非常大的体量，但是如果算在Android的阵营呢?机器人行业整体很小，中国服务机器人市场2016年销售额大概100多亿人民币，占大头儿的还是扫地机器人，而华为2016年消费者业务销售额1780亿人民币，我理解主要就是Android手机业务。所以，作为Anroid的衍生品，情感陪护类机器人在这个存量市场的份额并不大，是否能颠覆这个市场?未知数。 最后，面向行业的服务机器人， 前几日我分享的算法并不决定一切!迅雷创始人程浩谈国内机器人创业，其中有观点谈到短期内创业To B的机器人更容易实现，暗含的意思To B的机器人在短期内会迎来爆发(投资人认为适合创业，一定是要爆发的)。那让我们看看国内外做To B的服务机器人的公司，做酒店运送的Savioke和云迹科技，做Mobile Manipulation的Fetch Robotics和蓝胖子，做机械臂的Baxter，应该还有一些做物流机器人的公司。这些公司的共同点就是产品直接应用在第二和第三产业，目标都是直接推动生产力，如果真正降低成本，是毋庸置疑的刚性需求。这些机器人技术难度比较高，沿袭了机器人学的发展，用ROS开发有很大的优势。

对机器人产业来说，需要有足够的开发人员，需要有一小撮精英的研究人员做出技术突破。对于机器人开发人员来说，不仅仅要选择一个开发的系统和环境，还需要通过整个体系了解机器人运作的原理，即使未来最主流的机器人操作系统不是ROS，一定会有ROS深深的烙印。