為什么我選擇并且推崇用ROS開發(fā)機器人？

如果我們現(xiàn)在想研發(fā)一款機器人，應該選擇哪一個操作系統(tǒng)呢?其實我們大家平常接觸到的操作系統(tǒng)寥寥無幾，Windows，MacOS，Linux，iOS，Andoird。ROS雖然全名是Robot Operating System，但本質(zhì)上不是操作系統(tǒng)，是Linux發(fā)行版Ubuntu下的一個用來開發(fā)機器人的Middleware，這個沒有什么好辯駁的。Android雖然意思是人形機器人，但是我覺得這就只是名字而已，Andy Rubin難道真的是想通過智能手機探秘智能機器人?而且機器人學里的人形機器人一般寫成Humanoid。為了規(guī)避因“操作系統(tǒng)”產(chǎn)生的歧義，本文中我們討論研發(fā)一款機器人需要怎樣的“環(huán)境配置”?所以很多概念沒有區(qū)分是否稱得上操作系統(tǒng)。

選擇怎樣的環(huán)境配置，有幾點是我們先要搞清楚的。首先我們需要知道實時性是不是必須的。簡單的說，如果在系統(tǒng)中是關鍵變量，系統(tǒng)就需要實時，例如雙足機器人動態(tài)行走系統(tǒng)就必須實時，但是靜態(tài)行走的話其實不實時也可以。如果實時性是必須的，我們可以選擇Windows + VxWorks，這是在傳統(tǒng)運動控制領域非常常見的一個組合。也可以選擇QNX操作系統(tǒng)，或者LabView，不過這兩個實時的我并沒有很多經(jīng)驗。我最早接觸的實時操作系統(tǒng)是Windows + Ardence RTX，后來應該改名為IntervalZero。還有就是是否系統(tǒng)需要整體上實時?我們在做雙足機器人的時候，運動控制就用到了RTX，但是圖像處理并沒有。后來我們將運動控制的部分移到了一個ARM7的下位機，上位機的Windows只需要發(fā)送action的指令。所以，即便是需要實時，架構也是很靈活的。上位機是沒有實時性的強需求的。

當我們希望稍微提高一下機器人復雜度的時候，就會發(fā)現(xiàn)另一個需要考慮的問題，進程間通信。在我們用Windows + RTX的時候，進程間通信使用RTX提供的shared memory，不過都是比較慢的圖像處理進程向shared memory中寫數(shù)據(jù)，決策和運動控制進程讀數(shù)據(jù)。shared memory顯然并不是很好的通信方式，這里不再多加討論。ROS則使用了一個很好的通信架構，并且是ROS整個框架的一個基礎(不論是對于ROS中的topic，service，plugin，actionlib等基礎概念還是rviz，navigation package等功能包。想了解這些概念最近多關注下@Top Liu)，所以很多人簡單的理解ROS只不過是做了一個通信的架構而已。我必須說明下，進程間通信并不是ROS能夠占領機器人開發(fā)環(huán)境的主要原因。在2010年，我們開發(fā)一款類似Atlas的大型人形軍用機器人的時候，就用到了進程間通信工具IPC。IPC就是Inter ProCESs Communication，開發(fā)者是CMU的Reid Simmons，應該是出現(xiàn)在2000年左右。后來我在幫助本科生參加RoboCup Standard Platform League的時候用過Nao的操作系統(tǒng)NAOqi，這個系統(tǒng)大概是出現(xiàn)在2006年。在NAOqi中，整個通信的架構和ROS非常像了，ROS中的Node在NAOqi中叫一個broker，都是占用一個系統(tǒng)的端口。所以，2010年ROS正式發(fā)布Box turtle的時候，通信架構并不是顛覆性的。Android的進程間通信的機制據(jù)我了解也是非常強悍的。根據(jù)@邵天蘭 之前的一次講座，我也了解到ROS的通信機制放到現(xiàn)在看其實已經(jīng)有點過時了。所以僅僅從通信機制上評價ROS，意義不大。再有，ROS中的通信機制并不是說不能繞過，其程序本質(zhì)上還是C++和Python。

我認為ROS最大的貢獻就是制定了機器人開發(fā)的統(tǒng)一接口標準。因為Willow Garage當年是做移動服務機器人，所以這些標準是首先在移動機器人界統(tǒng)一的。所以ROS的意義，我概括的時候就是六個字，“書同文，車同軌”，極大加速了交流與進步。也是因為這樣，機器人學界才慢慢能夠形成一些BenchMarking，能夠在開源社區(qū)形成百花齊放的態(tài)勢，能夠讓大家不再深陷于又要搭建硬件又要搭建軟件的重復造輪子的困境。其實最主要就是ROS的message，看起來不過是一些頭文件，但是可以讓我們輕松的替換各種傳感器和執(zhí)行機構，替換軟件中的各個算法，現(xiàn)在搭建機器人在我們眼中，就像玩樂高積木，組裝一臺電腦。

當然，作為一個開發(fā)工具，只做到這里是不夠的。我看過LabView的開發(fā)工具，支持硬件很多，應該標準也很好。Microsoft Robotics Developer Studio是個不錯的開發(fā)工具，可惜掛掉了，也算是流行了一段時間。針對機器人開發(fā)，ROS則提供了很好的可視化、模擬仿真和Debug的工具，專業(yè)上講是非常developer friendly，這也是很多人說為什么ROS適合學習和做研發(fā)的原因。不過我覺得這不能支持ROS不適合做產(chǎn)品開發(fā)的觀點，因為產(chǎn)品成型后，這些調(diào)試工具平時都是可以去掉的。關于可視化工具Rviz，模擬仿真的Gazebo，Debug的log等級以及在線調(diào)參的rosparam和rqt等等，ROS星火計劃都有詳細的講解。

最后，就要說說基因，社區(qū)，支持和人才的問題。ROS的基因是移動式服務機器人，LabView的基因是NI，Android的基因是Google和智能手機。ROS社區(qū)還算是活躍，雖然機器人的高端玩家比較多，但是整體開發(fā)者數(shù)量估計也就在十萬的量級(ROS answer注冊用戶也就三萬吧)，總量不能和如日中天的Android相比，也是現(xiàn)在背后支持OSRF和google的差距。我也在不同場合聊過很多次，硅谷的機器人創(chuàng)業(yè)公司基于ROS開發(fā)的比較多(相對國內(nèi)而言，具體比例不清楚，從RosCon的支持廠商就能看到一些端倪)，但是國內(nèi)用Android的公司明顯在數(shù)量上占據(jù)上風 。

所以最后要支持本文論點了。不討論工業(yè)機器人(以及類工業(yè)機器人的醫(yī)療機器人等，以控制為核心)，我們把剩下的機器人品類再劃分的細致一些。首先，教育機器人(這里指學習機器人的套件等，不是說用來學習英文或者唐詩的對話機器人，這個歸屬到情感陪護類)，主要面向k-12的學生，也就是我國高等教育之前的學生，大多就是scratch+單片機，不需要什么系統(tǒng)。不過我覺得這種情況會在未來不久發(fā)生改變，主要是教育機器人業(yè)內(nèi)已經(jīng)有人發(fā)現(xiàn)機器人教育和機器人開發(fā)的脫節(jié)是個問題，那么也就是個商機，但是要等到產(chǎn)業(yè)足夠大。玩具類機器人不需要開發(fā)環(huán)境，所以就是玩各種單片機。這些都不是支撐機器人能成為一項顛覆性技術的方向。所以以下主要分析用Android和ROS開發(fā)的機器人。