| 大約距今30年前，就在人類踏上月球後沒多久，所有的科幻作品充滿了太空世界與機器人的遠景，還有對於當時『新興科技』--電腦的恐懼與想像。70年代的時候，第四代的電腦出現，蘋果電腦也在此時創立；到了80年代時，電腦則大量的進入一般人的生活中。除了硬體上技術的進步使得價格下降以外，讓電腦到達現在這麼普及程度的重要關鍵之一，就是共通的介面與溝通方式。簡單來說，由個人電腦市場龍頭所組成的聯盟，共同制定了電腦週邊設備與介面的軟、硬體標準規格，讓各家廠商都有機會投入這市場，可以開發各種不同的硬體與軟體。
尤其是軟體平台的建立，有著統一的標準，使得沒有能力開發硬體的小公司或是個人，都可以發揮一己之長，生產出可用在不同電腦上的應用軟體，頓時讓整個市場擴展到世界的各個角落。而在形成這局面之前，某大企業老闆還曾經說過：『誰家裡會需要一台個人電腦？』不過在現在看來，電腦的確已經和你我的日常生活緊密結合了。
這又不禁讓人聯想到，既然電腦只花了30年就從想像中走到我們的面前，甚至普及到可以在便利商店買周邊；那麼，『機器人』又要花多少時間才能在3C賣場買的到？換句話說，要到哪一天，機器人才會有完整又泛用的產品？
就客觀來看，現今機器人科技的發展，就像三十年前的電腦科技一樣處於萌芽期：各項技術剛起步、有初期的產品，可是還未普及、大小公司接續創立，想要搶攻市場、各國政府也投入資金研發相關技術；比較大的差異是，現在的資訊交流密度與速度和三十年前完全不能比較，硬體方面也有目前電腦與自動工具機的現成產品與技術作為後盾，因此開發過程中不如當年電腦發展那樣無所依靠。
所以，我們是否可以預見不遠的未來，機器人會和電腦一樣充滿你我的身旁？這似乎是必然發生的願景。不過，雖然硬體有現成的產品與技術，開發者們卻仍舊苦於機電整合所需花費的功夫，機器人通常由視覺、移動、控制、傳輸、供電等多種不同的模組所組成，光是這些模組間的IO點、訊號表等的整合就是一大工程，而在從事部分模組替換時，更需要一而再再而三地重覆整合動作。
就連軟體方面，由於沒有使用共通的底層平台，不管機器人是在什麼OS上開發，換一組人來修改，幾乎都要重頭到尾完整研究過程式，才能清楚的了解整個架構。因此，不同機器人應用軟體開發的經驗也難以順利交流。即使我寫好了某個應用功能（例如導航），拿到別台機器人上之後，由於架構不同，可能整個程式架構都要完全重寫，這些都是不必要花費的精力。
所以對機器人軟體開發人員來說，最重要的就是能夠有一個共通的軟體平台架構，讓所有的開發都能夠依循一定的規定或手法，只要有過一次的開發經驗，看到其他使用同樣架構的機器人，我們也能夠快速的了解要去哪邊找或是放入對應的程式碼，在最短的時間、最小的力氣下完成開發與修改。這就像是使用VC 6的程式設計師看的懂彼此的Windows程式，使用BCB、.Net、CVI的也看得懂彼此的程式。
很幸運的，目前世界上已經有多個組織在進行此類共通軟體平台的研發，除了早年就已經開始的各項計畫，2006年中，世界最大的軟體公司Microsoft發表了Robotics Studio 1.0版；而在2007年初，世界最有名的清潔機器人製造公司iRobot也發表了Create系列產品。這些指標性公司的加入在在顯示了他們對機器人共通軟體平台的重視。雖然所謂『共通的』標準依舊很多，但至少使用者可以依據你的硬體設備限制，或是拿手的開發環境來選擇最適合的軟體平台來使用。
一般來說，如果是學術或研究單位所開發出來的軟體平台，通常會使用Open Source的方式，免費提供使用者使用；若是公司行號所發表的，則收費方式不一定。依照這些平台的特性，可以將其分為兩大類：Platform與Middleware。 （一）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與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），而不限定使用者該如何開發自己的應用程式，其主要架構圖如圖一所示：
圖一 Player Project架構圖
Player System Architecture（圖片取材自Player手冊） （二）ARIA
ARIA是MobileRobots公司（Pioneer機器人的出品公司）為該公司機器人所提供的Object Oriented （OO） Interface。開發環境為Linux或Windows作業系統，適合的開發語言為C ，所以MS Visual C .NET （7.1）或g 3.x是支援的；此軟體平台還提供Robot模擬環境“MOBILESIM”並採用Client/Server的架構，其主要架構圖如圖二所示：
圖二 ARIA API的架構（圖片取材自MobileRobots網頁） （三）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的架構圖則如圖三所示。
圖三 ERSP 的架構（圖片取材自ER網頁） 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 。
圖四 Behavior Composer（圖片取材自ER網頁） 表二為Player Project、ARIA、ERSP之開發者或開發公司、開發作業系統、適合的開發語言、以及特色之整理表。 表二 Platform比較表 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）的程式。圖五與圖六分別為一個常見的Robot Service關係圖以及CCR Architecture。
圖五 一個常見的Robot Service關係圖（圖片取材自MSRS網頁）
圖六 CCR Architecture（圖片取材自MSRS網頁）
（二）OpenRTM-AIST
OpenRTM-AIST之開發是基於為了構築因應廣泛需要之機器人系統，而推進基盤技術RT Middleware的開發。對於這些模組化的元件稱之為RTComponent，由三個部分構成RTComponent Object、Inport Object、Outport Object。RTComponent以CORBA建構，目前OpenRTM可運行的作業系統為Linux，未來有朝符合Windows作業系統及.NET C 和JAVA的方向進行中。圖七與圖八分別為基本的RT Component架構以及RT Component Manager GUI（Graphical User Interface）。
圖七 基本的RT Component架構（圖片取材自AIST網頁）
圖八 RT Component Manager GUI（圖片取材自AIST網頁）
（三）OROCOS（Open RObot COntrol Software）
主要由the Flanders Mechatronics Technology Center所開發。OROCOS計畫建立一套泛用型的Freeware 可以有模組化的framework能運用於機台或工業機器人的即時（real-time）控制。圖九為OROCOS計畫預想的架構圖。OROCOS主要有四個C 的函式庫（Library）分別如下：
－Real-Time Toolkit（RTT）
－Orocos Component Library（OCL）
－Kinematics and Dynamics Library（KDL）
－Bayesian Filtering Library（BFL）
圖九 OROCOS計畫預想的架構（圖片取材自OROCOS網頁） （四）ORCA
ORCA等於是OROCOS的相關計畫，因為OROCOS的控制軟體設計強調real time，對於已經開發完成但無關real time 的Component則歸ORCA計畫。ORCA又分為ORCA-1及ORCA-2，差別在於ORCA-1並未設定Component的建構方式，ORCA-2則採用Ice（Internet Communication Engine）。圖十為ORCA Software Architecture。
圖十 ORCA Software Architecture （圖片取材自ORCA網頁） （五）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年初將會釋出提供合作單位使用，相信屆時必能成為國內機器人的發展的推手之一。 誌謝
本文研究成果主要來自經濟部技術處“智慧機器人技術研究發展”科技專案計畫。 |
