國外機器人軟體平台發展介紹

（本文轉錄自機器人世界情報網）

我們是可以預見不遠的未來，機器人會和電腦一樣充滿你我的身旁，這似乎是必然發生的願景。不過，雖然硬體有現成的產品與技術，開發者們卻仍舊苦於機電整合所需花費的功夫，機器人通常由視覺、移動、控制、傳輸、供電等多種不同的模組所組成，光是這些模組間的IO點、訊號表等的整合就是一大工程，而在從事部分模組替換時，更需要一而再再而三地重覆整合動作。

就連軟體方面，由於沒有使用共通的底層平台，不管機器人是在什麼OS上開發，換一組人來修改，幾乎都要重頭到尾完整研究過程式，才能清楚的瞭解整個架構。因此，不同機器人應用軟體開發的經驗也難以順利交流。即使我寫好了某個應用功能（例如導航），拿到別台機器人上之後，由於架構不同，可能整個程式架構都要完全重寫，這些都是不必要花費的精力。

所以對機器人軟體開發人員來說，最重要的就是能夠有一個共通的軟體平台架構，讓所有的開發都能夠依循一定的規定或手法，只要有過一次的開發經驗，看到其他使用同樣架構的機器人，我們也能夠快速的瞭解要去哪邊找或是放入對應的程式碼，在最短的時間、最小的力氣下完成開發與修改。這就像是使用VC 6的程式設計師看的懂彼此的Windows程式，使用BCB、.Net、CVI的也看得懂彼此的程式。

很幸運的，目前世界上已經有多個組織在進行此類共通軟體平台的研發，除了早年就已經開始的各項計畫，2006年中，世界最大的軟體公司Microsoft發表了Robotics Studio 1.0版；而在2007年初，世界最有名的清潔機器人製造公司iRobot也發表了Create系列產品。這些指標性公司的加入在在顯示了他們對機器人共通軟體平台的重視。雖然所謂『共通的』標準依舊很多，但至少使用者可以依據你的硬體設備限制，或是拿手的開發環境來選擇最適合的軟體平台來使用。
一般來說，如果是學術或研究單位所開發出來的軟體平台，通常會使用Open Source的方式，免費提供使用者使用；若是公司行號所發表的，則收費方式不一定。依照這些平台的特性，可以將其分為兩大類：Platform與Middleware。
##CONTINUE##

（一）Platform
Platform指的通常在開發的初期就已經預設要用在某一台特定的機器人或是裝置（Device）上，且對於要如何新增其Device Driver有明確的定義。也比較強調機器人本身的行為特性，如特定的避障、導航、空間定位等功能。

Platform給人的感覺會比較像是一個機器人的SDK（Software Development Toolkit），包含有各種預先設立好的功能可以使用，且彈性可能較低，即有一個完整的規範，使用者不管要新增或是修改任何功能都必須要緊緊綁在既有的架構下去做，未來改變與擴充的彈性較差。

（二）Middleware
Middle的走向通常較為開放，願景中會希望最後的成品不用受到作業系統或是語言的影響，可以完全依照使用者的喜好來開發，同時又能夠達到共通軟體平台『將軟體元件模組化』的需求。
Middleware不會特別指定要在哪一台機器人上使用、或是要具備什麼硬體，其所講求的是泛用性，最好能夠適用在各種類型的機器人上。所以Middleware通常看起來會比較像是一個架構與概念，配合最基本的程式核心，其餘周邊與硬體可以一切交由使用者們去開發與交流；當然，一切都要合乎此Middleware最初設計的SOP Rule，所以整體的彈性也較大，事實上也有些Middleware是由其他Middleware修改後所衍生出來的。

（三）Platform v.s. Middleware
使用Platform就像是我們在一棟建築物中蓋隔間或是裝潢，而使用Middleware則如同在地基上依照施工規範向上蓋，當然有時候也會向旁邊蓋或是跑去裝潢。前者雖然使用者也可以修改，但是要對照現有的水電路圖說，不過不管怎麼施工，對整體結構不會有太大影像；後者則有很高的自由度，但相對的如果使用者水準不一，則有機會蓋出奇形怪狀的房子，但卻可能更符合業主的期望。

就此來看，在這機器人萌芽的階段，尚無法定論孰優孰劣，不過兩者最終的目的相同，使用者應看情況挑選適合的解決方案才是上上之策。下表一為Platform與Middleware之特性比較。

代表性的共通平台軟體介紹：

Platform

（一）Player Project
Player是Brian Gerkey、Richard Vaughan、Kasper Stoy、Andrew Howard在南加大（USC）就讀時，為了實驗室的Pioneer機器人所開發出的 interface/driver abstraction framework。主要透過Linux作業系統開發，適合的開發語言為C、C 跟Python，屬於Open Source的Freeware；採用Client/Server的架構建立，中間則以TCP連線來傳遞Actuator命令及回傳Sensor狀態，並以Configuration File的形式來選定要使用的Device；提供2D Robot模擬環境「Stage」。綜合以上各特色，Player Project只是提供一個硬體抽象層（Hardware Abstraction Layer），而不限定使用者該如何開發自己的應用程式。

（二）ARIA
ARIA是MobileRobots公司（Pioneer機器人的出品公司）為該公司機器人所提供的Object Oriented （OO） Interface。開發環境為Linux或Windows作業系統，適合的開發語言為C ，所以MS Visual C .NET （7.1）或g 3.x是支援的；此軟體平台還提供Robot模擬環境「MOBILESIM」並採用Client/Server的架構。

（三）ERSP
ERSP是Evolution Robotics 公司所發展的一套機器人控制軟體發展工具。所支援的Robot除了該公司的ER1及Scorpion機器人外，也支援MobileRobot的Pioneer機器人。ERSP不同於Player Project和ARIA只提供使用者HAL（Hardware Abstraction Layer）的功能；ERSP提供使用者一個三層架構分別為硬體抽象層HAL（Hardware Abstraction Layer）、行為執行層BEL（Behavior Execution Layer）、以及任務實行層TEL（Task Execution Layer）。

ERSP也有視覺化的編輯程式Behavior Composer，可以將一些建立好的Behavior透過拖曳（Drag and Drop）的方式及屬性頁（Property Panel）的參數編輯方式，連結自己的Behavior Network。Behavior Network簡單的來說就是Task的基礎原型（Primitives）。TEL是以事件驅動（Event driven）的高階控制工作。Tasks可以觸發新的事件（events），並可以平行進行多個Task及設定離開條件（exit conditions）。使用者也可以呼叫Task類別（Class）的API（Application Program Interface）組合成適用的應用程式。ERSP對於新增Resource Driver、Behavior、Task都有相關的範例程式，適用的作業系統有Linux及Windows，適合的開發環境為.NET 2003及g 。

Middleware

（一）MSRS
MSRS是微軟公司跨足機器人領域的產品，於2006/12/16釋出正式版（1.0），並於2007/04/04釋出MSRS 1.5（CTP April 2007），供非商業用途免費使用。如果是商業用途則論套計價，一套約美金400元。此外，微軟公司更在2007/07/12推出了升級版的Robotics Studio平台，新增了對Windows Embedded CE 6.0和Windows Mobile的支援。MSRS 並沒有去定義或安排硬體抽象層（HAL）的設計，以Service為導向來思考並設計這個共用平台，並使用DSSP與CCR的概念。MSRS整合了AGEIA公司的物理計算引擎（PhysX）及繪製方面的DirectX Runtime，提供3D的機器人模擬環境，以及視覺化的Robot程式編輯軟體VPL（Visual Programming Language）。
DSSP（Decentralized Software Services Protocol），是一種簡化的 SOAP-based應用協定，DSSP用來解決Robot分散式應用的問題。另一方面，CCR（Concurrency and Coordination Runtime）為C#2.0所開發的Port-Based concurrency函式庫，用來解決以往的多工問題。使用者不須去撰寫多執行緒（Multi Thread）的程式。

（二）OpenRTM-AIST
OpenRTM-AIST之開發是基於為了構築因應廣泛需要之機器人系統，而推進基盤技術RT Middleware的開發。對於這些模組化的元件稱之為RTComponent，由三個部分構成RTComponent Object、Inport Object、Outport Object。RTComponent以CORBA建構，目前OpenRTM可運行的作業系統為Linux，未來有朝符合Windows作業系統及.NET C 和JAVA的方向進行中。

（三）OROCOS（Open RObot COntrol Software）
主要由the Flanders Mechatronics Technology Center所開發。OROCOS計畫建立一套泛用型的Freeware 可以有模組化的framework能運用於機台或工業機器人的即時（real-time）控制。OROCOS主要有四個C 的函式庫（Library）分別如下：
－Real-Time Toolkit（RTT）
－Orocos Component Library（OCL）
－Kinematics and Dynamics Library（KDL）
－Bayesian Filtering Library（BFL）

（四）ORCA
ORCA等於是OROCOS的相關計畫，因為OROCOS的控制軟體設計強調real time，對於已經開發完成但無關real time 的Component則歸ORCA計畫。ORCA又分為ORCA-1及ORCA-2，差別在於ORCA-1並未設定Component的建構方式，ORCA-2則採用Ice（Internet Communication Engine）。

（五）RSCA（Robotic Software Communications Architecture）
URC（Ubiquitous Robotic Companion）是目前韓國正在進行的機器人發展計畫，參與的團隊為韓國的ETRI、Samsung、KIST and MIC，目的在於將原先的聯網服務（networked service）機器人能整合起來克服目前家用服務機器人所碰到的技術難題。作法是採用SDR（Software Defined Radio）領域中的一個現有中介層軟體架構SCA（Software Communications Architecture），將之衍生運用到URC計畫中，稱之為RSCA。

結論

就如同國與國間要交流，語言和觀念必須能夠互通，未來機器人的開發上若要能夠交流其中的技術與資訊，發展共通的軟體平台是勢在必行。現在已經有多種軟體平台發展出來，這些開路先鋒雖然各有其優劣之處，但是仍舊提供廣大的使用者不同的選擇，使用者應該依照本身環境與能力的需求來選擇適合的軟體平台。

有鑑於國外各機關組織已然發展出多種不同共通平台軟體，在吸收其優劣之處與使用經驗後，目前國內工研院的科專計畫正在發展一套機器人軟體平台，預計在2008年初將會釋出提供合作單位使用，相信屆時必能成為國內機器人的發展的推手之一。

誌謝
本文研究成果主要來自經濟部技術處「智慧機器人技術研究發展」科技專案計畫。