Ubuntu下ROS變種ROCOS的系統架構①

杜晉華,杜 剛,張 虎

1(中國地質大學(北京) 信息工程學院,北京 100083)

2(湖北大學 物理與電子科學學院,武漢 430062)

近年來,伴隨人工智能技術和傳感技術等新型技術的快速發展,智能機器人技術獲得了突飛猛進的進步.與之對應的是機器人相關體系結構和操作系統迎來了發展的黃金時期,出現了以ROS為代表的專用于機器人的操作系統[1].

鑒于ROS 操作系統在架構的模塊化與層次化上的良好表現,國內外很多學者都基于ROS 進行了有關研究與技術實現,如基于ROS 實現機器人的各子功能部件的三維建模與開發[2]有效降低了工作復雜度、使用ROS 作為機器人控制的嵌入式底層避免了對策略核心的重復設計與實現[3]、通過ROS 提供的各種功能包來進行二次開發[4]以期減少成本投入以及使用ROS 進行相關仿真實驗[5]取代實際重復性或長周期的實地實驗,并能保證更高精度的數據獲取等.除此之外,國外研究大多集中于具體ROS 應用的實現,包括但不限于基于ROS的仿人雙臂機器人PR2[6]的實現、汽車自動駕駛路徑規劃與導航[7]的實現、家用服務型機器人系統[8]的實現、醫療輔助式機器人交互邏輯[9]的實現等.

除直接基于ROS 操作系統進行機器人方面的工作外,也有部分開發人員考慮借鑒ROS的邏輯,為專門化的機器人提供相應的操作系統,這種操作系統在保留ROS的主要功能和特點的前提下,都會在某一特定方面做出一定優化,以期更好地控制與服務于相關機器人.其中有代表性的是ROCOS 操作系統,主要實現了多臺機器人的配合調度.

本文將對ROS和其變種ROCOS 做簡要介紹,并詳細對比分析兩者的架構邏輯,希望對有關機器人系統研究方面的人員提供一定的參考價值.

1 系統簡介

1.1 機器人操作系統ROS

ROS (Robot Operating System),即機器人操作系統,是用于編寫機器人軟件程序的一種具有高度靈活性的軟件架構,是一個適用于機器人的開源的元操作系統.它提供了操作系統應有的服務,包括硬件抽象,底層設備控制,常用函數的實現,進程間消息傳遞,以及包管理.它也提供用于獲取、編譯、編寫和跨計算機運行代碼所需的工具和庫函數.

在它誕生之前,很多專家致力于實現一個能夠自我感知、自我導航和自我控制的復雜機器人設計.過程中,大家發現很多現有資源難以共享或者直接使用,所以都認為機器人研究需要一個開放式的協作框架,用以整合和提高各種資源的利用率.所以在這樣的需求下,2007年ROS 自斯坦福大學誕生,并在大量研究人員的共同努力下,逐漸發展和完善.ROS 發展歷史如圖1.

圖1 ROS 發展歷史

目前,ROS 廣泛應用于機器人領域,主要實現機器人的建模、感知、導航和規劃,并能直接和機器人連接通訊,以實現對其物理實體的控制.

1.2 機器人操作系統ROCOS

ROCOS是世界杯機器人操作系統(RObotCup Operating System)的英文縮寫,是以ROS 操作系統為原型,剔除不必要的功能分支,專用于多機器人調度的軟件架構.

它源自機器人世界杯RobotCup,一個為促進人工智能和機器人等相關領域研究的國際項目.該項目是以足球機器人為主要研究平臺,以推進人工智能和機器人研究的國際比賽,旨在研究如何在實時性強,即高動態性和高對抗性的環境中,調度多臺機器人完成指定的工作任務,和實現多機配合的智能化.圖2是RobotCup 賽場實況.

圖2 RobotCup 賽場實況

ROCOS 最先由卡內基梅隆大學(CMU)在1997年發起構建,其核心思路是在控制子系統的實現時按照STP (Skill-Tactic-Play) 框架進行分層開發,之后于2012年對其改版,提出SSPS (Skill-State-Play-Selector)框架,有效提高了各機器人之間的配合度,在響應機器指令方面也有很大提升.

與此同時,世界上其他機器人強校如康奈爾大學等也在積極引進ROCOS 并投入到對其優化與研發中.我國浙江大學也在持續跟進,其控制學院工業控制國家重點實驗室于2003年就著手ROCOS的研究,2020年已形成比較完善的ROCOS 版本,并對ROCOS 實效做了相應的測試與研究[10,11].表1說明了浙江大學現有ROCOS 在世界機器人比賽上的優異表現.

表1 RoboCup SSL 榮譽榜

2 系統架構

2.1 ROS 架構

從硬件實現角度,ROS 系統可分為3個層次:OS層、中間層和應用層.其中OS 層為底層,主要使用Linux 系統實現(如Ubuntu),中間層實現ROS 核心通信機制以及功能庫,應用層通過運行ROS Master (管理者)來負責系統正常運行.

具體到中間層的實現,又可將ROS 架構細分為計算圖層、文件系統層和開源社區層,如圖3.

圖3 ROS 架構

2.1.1 計算圖層

ROS 系統軟件的功能模塊以節點為單位獨立運行,通過端對端的拓撲結構連接.所以ROS 引進計算圖來描述這種拓撲結構,進而體現程序的運行方式.

計算圖的構成方式是:ROS 創建一個連接所有進程(節點)的網絡,其中的任何進程(節點)都可以訪問此網絡,并通過該網絡與其他進程(節點)交互,獲取其他進程(節點)發布的信息,并將自身數據發布到網絡上.其中,構成計算圖網絡的各個節點(node)、主題(topic)、服務(server)等都有唯一的名稱做標識.

1)節點:是主要的計算執行進程,功能包(在第2.1.2 節中詳細定義)中創建的每個可執行程序在被啟動加載到系統進程中后,該進程就是一個ROS 節點,如圖4中的node1、node2等都是節點.節點都是各自獨立的可執行文件,能夠通過主題(topic)、服務(server)或參數服務器(parameter server) 與其他節點通信.ROS 通過使用節點將代碼和功能解耦,提高了系統的容錯力和可維護性.

2)消息:節點通過消息(message)完成彼此的溝通.它是ROS中一個進程(節點)發送到其他進程(節點)的信息.消息類型是消息的數據結構,ROS 系統提供了很多標準類型的消息可以直接使用,如果要使用非標準類型的消息,需要進行自定義.

3)主題:每個消息都必須發布到相應的主題(topic),通過主題來實現在ROS 計算圖網絡中的路由轉發.節點發送數據被稱為該節點正在向主題發布消息.節點可以通過訂閱某個主題,接收來自其他節點的消息.通過主題進行消息路由不需要節點之間直接連接,這意味著發布者節點和訂閱者節點之間不需要知道彼此是否存在,從而保證發布者節點與訂閱者節點之間的解耦合.

4)服務:在一些特殊的場合,節點間需要點對點的高效率通信并及時獲取應答,此時需要用服務的方式進行交互.提供服務的節點被稱為服務端,向服務端發起請求并等待響應的節點被稱為客戶端,客戶端發起一次請求并得到服務端的一次響應就完成了一次服務通信過程.如圖4中node1 向node3 發起一次請求,并得到node3 返回給node1的響應.

圖4 計算圖示例

2.1.2 文件系統層

與其他操作系統類似,一個ROS 程序的不同組件需要被放在不同的文件夾下進行管理,而這些文件夾則根據不同的功能來對文件進行組織,它們構成了ROS的文件系統.

在文件系統中,最基本的管理單元就是功能包.功能包是ROS中軟件組織的基本形式,一個功能包具有用于創建ROS 程序的最小結構和最少內容,它可以包含ROS 運行的進程(節點)和配置文件等.

一個功能包可以按照圖5的方式分為多個部分,其中具體到每個子部分如下文.

圖5 ROS 文件系統中的功能包

1)功能包清單:主要用于記錄功能包的信息以及發行者、功能包之間的依賴關系以及編譯的相關信息等.在功能包中扮演管理者的角色.

2)消息類型:用于描述ROS 采用話題通信時消息的類型,通過該文件可了解這個功能包的相關通信接口.

3)服務類型:用于描述ROS 采用服務通信時服務的類型,通過該文件也可了解這個功能包的相關通信接口.

4)代碼:節點是通過相應的編程語言進行編寫的,其代碼稱作源代碼,存放于特定文件夾中.

其中,由功能包還可以組成更大的功能包,被稱之為元功能包,用以實現更大、更復雜的功能.

而在元功能包之上,還有一層文件夾,被稱作工作空間.工作空間是一個包含功能包、可編譯源文件和編譯包的文件夾,當用戶想同時編譯不同的功能包或保存本地開發包時必須使用這一機制.用戶可根據實際需要創建多個工作空間,在每個工作空間中開發不同用途的功能包.

如圖6所示,工作空間通常由3 種文件夾構成.

圖6 ROS 文件系統中的工作空間示例

1)src 源文件空間:該文件夾放置各個功能包和用于這些功能包的CMake 配置文件CMakeLists.txt.由于ROS中的源碼采用catkin 工具進行編譯,而catkin工具基于CMake 技術,所以在src 源文件空間和各個功能包中都會有CMakeLists.txt,它起編譯配置的作用.

2)build 編譯空間:該文件夾放置CMake和catkin編譯功能包時產生的緩存、配置、中間文件等.

3)devel 開發空間:該文件夾放置編譯好的可執行程序,這些可執行程序不需要安裝就能直接運行.一旦功能包源碼編譯和測試通過后,可以將這些編譯好的可執行文件直接導出與其他開發人員分享.

2.1.3 開源社區層

開源社區層是位于ROS 架構最外面的層次(注意這里討論的范圍還在中間層,其實開源社區上還有應用層).由于ROS的開源讓很多人得以共享資源,這個共享資源的平臺稱之為ROS的開源社區,如圖7.

圖7 ROS 開源社區構成

ROS的開源社區主要由網站、博客和代碼資源構成.因為ROS有各種功能的功能包,但ROS 安裝時只會安裝固定的一部分,所以用戶搭建自己的機器人時,如果需要特定功能的功能包,可以自己寫功能包源碼,也可以從開源社區中尋找,采用軟件源的形式下載別人的功能包來參考使用.

具體的開源社區功能模塊構成如下:

1)發行版(Distribution):ROS 發行版包括一系列帶有版本號、可以直接安裝的功能包.

2)軟件源(Repository):ROS 依賴于共享網絡上的開源代碼,不同的組織機構可以開發或者共享自己的機器人軟件.

3)文檔社區(Wiki):記錄ROS 信息文檔的主要論壇.

4)郵件列表(Mailing list):交流ROS 更新的主要渠道,同時也可以交流ROS 開發的各種疑問.

5)問答社區(Answers):咨詢ROS 相關問題的網站.

6)博客(Blog):發布ROS 社區中的新聞[12]、圖片、視頻等內容.

2.2 ROCOS 架構

因為ROCOS 操作系統是在ROS 系統的基礎之上做出的單方向(多機調度)的優化.所以從實現角度看,其架構與ROS 類似,也可分為3個層次:OS 層、中間層和應用層.其中OS 層為底層,主要使用Linux 系統實現(如Ubuntu),中間層實現ROCOS 核心通信機制以及功能庫,應用層主要通過圖形界面的模式為用戶提供服務.

具體到中間層的實現,ROCOS 更加關注具體的機器人仿真與通訊細節,可將ROS 架構細分為后端策略層、前端控制層、文件系統層和開源社區層,如圖8.

圖8 ROCOS 架構

2.2.1 后端策略層

后端策略層是ROCOS 用于實現機器人操控邏輯、處理I/O 信息(如視覺信息、從機器人傳回的通訊信息、傳感器信息等)和形成指令的控制中心.

在圖9中,機器人的正常運行有賴于多個相互關聯系統的信息交互與功能配合.具體包括:視覺子系統、決策子系統、通訊子系統、機器人硬件子系統以及場地輔助子系統等.其中,ROCOS 操作系統裝載于策略機上,由其后端策略層處理從其他子系統搜集到的實時信息,并進行整合、處理與計算,之后依靠代碼邏輯做出相應的決策和命令,通過通訊機制傳輸給機器人,完成邏輯層與物理層之間的配合.

圖9 ROCOS 在整個大型系統中的位置

為完成相應功能,后端策略層需要依賴外置功能包,并使用合理的框架對功能進行解耦和處理.

涉及到的功能包與運行環境具體包括:

1)開發環境:為有效組織代碼邏輯、合理預留前端控制層需要的接口以及確保應用層較好的可視化效果,選擇具有優良跨平臺特性、面向對象的、含豐富API、支持OpenGL的QT 作為默認集成開發環境.

2)開發語言:在ROCOS中,絕大部分底層邏輯代碼采用C++11 規范完成開發.而考慮到多機器人的調度,使用具有可擴展、簡單高效、與平臺無關等特性的LUA 語言實現相應的功能.(具體實現中需要引入第三方軟件包tolua++)

3)相關庫:后端策略層需要對大批量、實時性數據進行處理,有賴于C++里支持線性代數運算、矩陣和矢量運算、數值分析及其相關的算法的開源模版庫Eigen.另外,為實現后端策略層和前端控制層、前端控制層和通訊子系統的數據傳輸,需要引入與平臺和語言無關、可擴展且輕便高效的序列化數據結構協議Protobuf.

具體而言,后端策略層通過C++和LUA 兩種計算機語言的有機結合,用 C++進行各種基礎算法、動作任務的編寫,LUA 進行上層任務的分配,構建出一個能使機器人從完成一個簡單動作到多個機器人進行相互協調配合的框架.

框架結構如圖10所示.

圖10 ROCOS 后端策略層分層

1)使用C++完成底層skill 動作層的開發:該層主要完成單臺機器人的單個動作,與硬件實現緊密相關,如實現到達指定點、轉體等.

具體實現框架為:

1.#include "src/utils/PlayerTask.h"……

2.extern "C"_declspec(dllexport) PlayerTask

player_plan(const WorldModel* model,int robot_id);

3.enum FourQuadrant{LeftUp,……}area;

4.PlayerTask player_plan(const WorldModel*model,int robot_id){

5.PlayerTask task;

6.……

7.if (ball.y>0) {

8.if (ball.x>0) {area=RightUp;}

9.else {area=RightDown;}

10.}

11.else {……}

12.switch (area){

13.case LeftUp:

14.task.orientate=(ball - goal).angle();//dir

15.task.target_pos=point2f(half_x,-half_y);

16.break;

17.case LeftDown:

18.……}

19.return task;}

2)使用LUA 完成task 任務層的開發:該層主要調用多個skill 函數,并將其封裝為一個完整的task 任務,用以將該任務分配給單臺機器人執行,如足球機器人執行到達指定點拿球的任務(具體包含到達拿球點skill、控球skill、檢測是否拿球skill 等).

具體實現框架為:

1.gPlayTable.CreatePlay{

2.firstState="halt",

3.switch=function()

4.return "halt"

5.end,

6.["halt"]={

7.["Leader"]=task.stop(),

8.["Special"]=task.stop(),

9.match="[LS]"

10.},

11.name="NormalPlayV1",

12.applicable={exp="a",a=true},

13.attribute="attack",

14.timeout=99999

15.}

3)使用LUA 完成play 場景層的開發:該層主要調用多個task 對象,并將其封裝為一個完整的play 場景,用以對多臺機器人進行任務分配,使之并行執行多個任務,如多臺家用機器人處于清掃場景(掃地機器人分配地面清掃任務、擦窗機器人分配玻璃清潔任務等).其實現框架與task 層類似.

如果對策略層做進一步的細化,可將其分為6個工作層:

1)視覺和傳感器的信息處理:將視覺系統傳過來的信息進行分析整合,過濾重復內容.另外,需要對從機器人本體上傳感器(如紅外傳感器)獲得的工作信息進行處理,為后續指令的下達提供依據;

2)運動預測:通過保留過去若干秒內的圖像信息,將位置信息轉化為速度信息,根據數學計算來預測環境中各實體(包括機器人在內)位置,該工作也為機器人合理的路徑規劃打下基礎;

3)路徑規劃:實現機器人的動態避障,在完成移動任務的同時確保機器人不與各類靜止、運動物體發生嚴重碰撞;

4)多層決策協作:實現從一個機器人完成一個動作到多臺機器人協同運作的多決策層的有機配合;

5)場景實現:包括場景動態變換后的任務更新以及動態分配;

6)各種相關的算法:包括基于硬件提供功能的抽象與二次開發.

2.2.2 前端控制層

前端控制層是ROCOS 用于仿真機器人實時場景、提供應用層控制接口以及與通信子系統連接配置等功能的集成.

圖11是足球機器人前端控制層在應用層的圖形頁面,其構成包括左部的環境仿真與右部的控制面板,用以實現對機器人控制的可視化處理.

圖11 ROCOS 前端控制層在應用層的圖形頁面

具體使用過程中,需要在控制面板中設置相關參數、選擇研究模式.如果場地子系統可以提供支持,可選擇實地模式,并在結合下文的通訊子系統后,完成實地圖像在系統上的二維仿真建模與控制;如果場地子系統不提供支持,用戶可以脫機進行研究,在ROCOS中填充自定義的程序實現文件,系統將解析用戶的文件并在環境仿真界面進行仿真運算,可獲得與實地模式同等的研究效果.

圖12是ROCOS 前端控制層功能的另一方面體現,ROCOS 搭載的策略機可直接和信號發射機連接,通過無線、藍牙等技術實現與機器人之間的通訊.其具體實現邏輯仿照無線電系統和無線網絡系統的實現模式:當機器人與策略機連接在同一網段,或兩者頻率收發器均設置為相同的頻點,即可實現自主式非人工連接.

圖12 ROCOS 前端控制層在應用層的圖形頁面

為完成相應功能,前端控制層也需要依賴外置的功能包,并使用合理的框架對功能進行解耦和處理.

值得注意的是:由于前端控制層的框架不是特別清晰,也需要之后隨著ROCOS的版本迭代逐步優化,這里僅對其依賴的功能包做進一步的說明:

1)仿真:為實現機器人環境與實體的三維建模與實時仿真,需要引入開源的圖形函數庫OpenGL 進行場景建模,也需要引入開源的動態引擎庫ODE 提供相應的支持.

2)驅動:需要為ROCOS 配置相應從其他子系統獲取信息和進行I/O 管理的軟件,如與信號通訊相關的發射機驅動、加密狗驅動;與視覺信息捕獲相關的顯卡驅動等.

2.2.3 文件系統層

ROCOS的文件系統層和ROS 沒有特別大的差別,而且在對文件系統管理的文件樹結構也大致相同,均包含基本的文件夾架構:

1)bin:該文件夾保存可執行的程序和命令,大多是在ROCOS的終端界面可直接運行的命令行.

2)include:該文件夾用于放置頭文件.由于ROCOS里面的某一具體的頭文件屬于某一具體的功能包,如果一個功能包需要依賴另外的功能包,自然必須包含另外功能包的頭文件,功能包的頭文件在功能包安裝的時候被直接存放于該文件夾.

3)lib:主要存放一些.so 結尾的可執行程序.

4)etc:主要存放ROS和catkin 配置文件.

5)share:放置ROCOS 里面已經安裝的功能包,主要包含功能包的各種信息,包括其接口、配置信息等.值得注意的是,如果用戶需要真正操作機器人,并不是直接在該文件夾下進行,需要額外建立一個文件夾,即上文提及的工作空間,然后在工作空間下創建自己的功能包,進行一系列開發工作.

2.2.4 開源社區層

由于ROCOS 相對較為小眾,所以并不像ROS 一樣提供一個廣泛開源的社區,它主要依托Git 實現代碼開源與數據共享(Git是目前世界上最先進的分布式版本控制系統).

本文介紹的浙江大學實現的ROCOS,就在應用Git 系統的主流版本管理網站Github 上進行了開源[13],目前有包括筆者在內的多個開發者參與到相關代碼的研發與優化中.

3 仿真與實驗

為檢驗ROCOS 架構的合理性及其在單一實現方向上所展示出的強針對性,分別就ROS 系統和ROCOS系統進行仿真實驗.

由于本文主要針對浙江大學實現的ROCOS 做研究,研究者位處系統的優化人員之列,所以不能估計本ROCOS的構建成本.從浙江大學實驗室獲悉的詳細數據是:ROCOS的初始架構時間花費不到半年,相較ROS 系統直接作為成品或工具而言,其成本偏高.但注意使用ROS的用戶需要花費至少1 到2年的時間學習ROS的基本技術,ROCOS 僅需1個月或者更短,所以從總時間成本投入上,ROCOS 更勝一籌.

而通常情況下,ROCOS是為專門化領域或專門性需求所構建,所以與ROS 普適性構建相比,其與機器人的適配性會更好.

基于上述原因,本次實驗以SSL (Small Size League)小型足球機器人(其二維參數如圖13)為研究對象,在一臺策略機上運行Ubuntu 下ROS 系統、一臺策略機上運行Ubuntu 下ROCOS系統.為保證實驗不受無關因素干擾,確保兩臺機器有相同硬件環境配置:Intel core i5-8300,2.3 GHz,四核,內存 8 GB.并同時接入SSL_Vision 對應顯卡,加載相應視覺軟件.相關參數如圖14.

圖13 小型足球機器人二維參數

圖14 SSL_Vision 配置環境及參數

從圖14可知,初始條件下,數據傳輸率均為0.在仿真實驗中,該值將指征系統的仿真效果以及穩定性.

3.1 多場景適應性仿真

使用5 臺藍色標識標記的足球機器人進行仿真模擬,使用LUA 腳本指定其分別實現多邊形路徑規劃與隊列路徑規劃,檢驗數據傳輸率、ROCOS 計算速度與計算精度以及畫面延時情況.

在圖15中,圖15(a)是初始場景:可以看到數據傳輸率穩定在62 幀/s,靜態仿真效果良好.圖15(b)和圖15(c)分別是多機路徑規劃場景中的多邊形路徑和隊列路徑動態仿真,可以看到數據傳輸率仍舊維持在62 幀/s,所以系統穩定性非常好.

圖15 ROCOS 多場景適應性仿真圖

使用命令行查看CPU 使用情況可以看到(ROCOS沒有提供獨立任務管理器)如圖16.

圖16 Ubuntu 下命令行任務管理器數據

初始靜態仿真時刻CPU 占有率為179.5%,而動態仿真時刻CPU 占有率為145.5% (注意這里占有率超過100%屬系統問題,相對占有率為準確值).可以看出相對占有率不增反降,主要原因在于靜態仿真需要維持機器人仿真二維視圖在可視時間內保持靜止,實際仍在進行計算,所以CPU 占用率較高.

為對比ROCOS的顯著提升效果,在ROS 上做同組對比實驗.

在圖17中,圖17(a)是初始場景:可以看到數據傳輸率穩定在60 幀/s,靜態仿真效果與ROCOS 持平.圖17(b)和圖17(c)分別是多機路徑規劃場景中的多邊形路徑和隊列路徑動態仿真,可以看到數據傳輸率下降較為嚴重,低至30 幀/s 左右,所以系統穩定性不甚理想.

圖17 ROS 多場景適應性仿真圖

同樣使用命令行查看CPU 使用情況如圖18.

圖18 Ubuntu 下ROS 自定義任務管理器數據

初始靜態仿真時刻CPU 占有率為0.3%,而動態仿真時刻CPU 占有率為70.9%.可以看出雖然靜態環境下,ROS 系統的效率極高,但轉為動態環境后CPU 占有率提升70.6%,與ROCOS 不增反降相比,具有普適性的ROS 系統在針對性領域效果不甚理想,由此可以看出ROCOS 系統所具有的強針對性:在專一領域,它的功能更加穩定且效果良好.

3.2 交互式仿真

在機器人領域,給研究人員帶來極大阻礙的就是在程序運行過程中,無法實時查看相關參數.此外,在機器人運行過程中如果出現問題,一般很難立即定位問題來源,極大程度上制約了項目推進速度和效率.

ROS 系統允許用戶根據機器人實際情況,借助系統提供的功能包自行定義交互式輔助軟件.仍以SSL為例.ROS 交互界面如圖19.

圖19 ROS 交互界面

使用ROS 提供的元功能包以及小型足球機器人硬件開發文檔提供的相關接口,實現上述界面,可執行簡單的機器人控制:包括速度、自身行為、動作觸發、多機選擇.但實際使用過程中,一旦出現程序問題,只能確定觸發源為當前時刻的前一條指令,無法確定具體原因.

主要原因在于交互界面不靈活,不能實現用戶“所想即所得”,即實時性動態調整可交互元素.ROCOS 可以實現上述需求.

如圖20,使用ROCOS 搭建系統交互界面,可在可視化窗口中有選擇地或者全部顯示用戶需要獲取的中間參數,在控制面板中,以列表形式提供各參數的設置接口,并允許用戶在使用系統時動態調整列表項.凡系統可從實體機器人硬件或者仿真后臺程序中獲取的參數項,均可在控制面板動態定義.

與此同時,在本次實驗中,ROCOS 系統由于主要針對多機調度,所以從圖20中可以看出,針對每一臺機器人都可以獲取其獨立的參數.為多機系統的設計與控制提供了極大方便.

圖20 ROCOS 交互界面

通過以上對比,可見ROCOS 在交互方面也獲得了較大程度的提升.與ROS 相比,在強針對性領域,顯示出足夠優勢.

4 小結與展望

本文對基于Linux內核(Ubuntu)下的ROS 操作系統和ROCOS 操作系統分別進行了對比式的介紹和說明,并對二者具體的系統架構進行了相對詳盡的描述,最后以對比實驗的方式論證了ROCOS的系統特性與系統優勢.雖然目前ROS的適用范圍仍在不斷擴大,但像ROCOS 這樣從ROS中發展而來的強針對性操作系統才剛剛起步.它在保留ROS 原有的點對點設計、多語言支持、架構精簡、組件化工具包豐富以及免費且開源等特點的基礎上,更強調對某一特定場景的支持(如本文提及的ROCOS 就是對多機調度場景的支持),顯然它會比ROS 更專一,功能更穩定,與特定場景的適配性更好.

截止目前,由于ROCOS 需要的成本投入遠低于ROS,用戶不需要學習ROS中大量復雜而多元的概念,僅需要參照現有ROCOS 實現模式,去實現自己方向的ROCOS 系統,所以其成本更低.基于ROCOS的顯著優勢,隨著近年來人工智能等技術的不斷推向深入,像ROCOS 這樣的操作系統在未來可能會更有市場.雖然目前看來,它還有很長的路要走.