基于ROS和QoS的云機器人研究

張 偉，郝麗娜，程紅太，高 乾

(東北大學機械工程與自動化學院，遼寧 沈陽 110819)

0 引言

自從“云機器人”這個術語首次由James Kuffner在2010年IEEE humanoid大會上提出來以后[1]，許多云機器人架構(gòu)和應用被提出。云機器人主要側(cè)重于存儲和計算功能，如SLAM、數(shù)據(jù)存儲、抓取規(guī)劃、導航以及計算機視覺等[2-5]。

Arumugam 等[6]提出了集成Hadoop集群和ROS消息傳遞框架的云平臺Davinci，在Map/Reduce中實現(xiàn)的FastSLAM算法并在地圖構(gòu)建效率和傳感器需求方面有顯著的改進。Doriya等[7]提出了一個名為Robot-cloud的云機器人系統(tǒng)，通過云為低成本支持ROS的異構(gòu)機器人提供幫助，但云端不支持多個機器人同時訪問同一服務。Mohanarajah等[8]提出了一個基于RoboEarth的開源云機器人框架Rapyuta，通過OpenStack和Docker提供安全的、與ROS兼容的彈性計算環(huán)境，幫助機器人減輕繁重的計算負擔。但是這些機器人通過WebSockets協(xié)議連接到Rapyuta，這與rosbridge類似，它們之間的信息每次都需要轉(zhuǎn)換，并且沒有考慮QoS。胡奔等[9]建了帶QoS感知的基于ROS的云機器人平臺，云端和機器人端使用Jason WebSocket協(xié)議進行消息轉(zhuǎn)換，并根據(jù)云端/本地轉(zhuǎn)換機制處理QoS的動態(tài)變化，但系統(tǒng)僅把請求響應時間(RRT)作為評價Qos的主要因素。楊小桃等[10]組合柔性提出了制造云服務組合的自適應調(diào)整框架、自適應調(diào)整方法以及提升策略等。

雖然上述的幾個云機器人系統(tǒng)可以把機器人的任務卸載到云端，但是對異構(gòu)機器人的兼容性和網(wǎng)絡條件下的魯棒性仍有待提高。因此本文提出了一種基于ROS并帶有QoS調(diào)節(jié)機制的云機器人系統(tǒng)CloudROS。

1 系統(tǒng)的整體框架

云機器人系統(tǒng)是典型的分布式系統(tǒng)，本文基于ROS分布式框架進行了系統(tǒng)設計。如圖1所示，架構(gòu)中有3種角色：云服務端、機器人端和用戶監(jiān)控端。云端是服務資源的提供者；機器人端是服務的請求者，既可以請求計算服務，也可以把自身產(chǎn)生的數(shù)據(jù)進行上傳共享；用戶監(jiān)控端可以幫助用戶監(jiān)控機器人的運行狀態(tài)。

圖1 CloudROS系統(tǒng)

與其他云機器人系統(tǒng)相比，CloudROS具有如下特點：

a.主節(jié)點運行在機器人端。在機器人端運行ROS主節(jié)點，可以對機器人端的ROS節(jié)點和屬于該機器人的云端服務節(jié)點進行統(tǒng)一管理，即使云端服務節(jié)點異常退出時，機器人仍可以在不使用云端服務的情況下提供基本功能，并在網(wǎng)絡恢復時提供高級功能。

b.云端服務以ROS節(jié)點的形式提供。ROS節(jié)點間通信方式非常適合分布式架構(gòu)，本地和云端建立以話題為基礎的節(jié)點通信，避免了數(shù)據(jù)通信的格式轉(zhuǎn)換。另一方面，ROS系統(tǒng)集成了豐富的開源算法包，能夠?qū)崿F(xiàn)機器人應用服務的快速部署。

c.云端/機器人端的切換機制。由于云端服務依賴網(wǎng)絡通信質(zhì)量，所以當網(wǎng)絡質(zhì)量較差的時候，基本的數(shù)據(jù)傳輸無法保證，那么云端服務也無法保持正常運行。所以此時系統(tǒng)自動切換到本地預先設置的基礎服務以保證機器人基本功能的運行，并且當網(wǎng)絡質(zhì)量恢復后，機器人端重新請求云端服務。

d.QoS調(diào)節(jié)機制。云端服務的動態(tài)性能同時受網(wǎng)絡條件(網(wǎng)絡延遲、帶寬等)和計算復雜度的影響，即使云服務正常運行時，也存在服務質(zhì)量等級的劃分，CloudROS系統(tǒng)中建立了QoS的調(diào)控機制，對網(wǎng)絡因素和計算復雜度進行綜合監(jiān)控，并且根據(jù)QoS監(jiān)控結(jié)果進行動態(tài)調(diào)整來保證計算服務度匹配網(wǎng)絡條件，從而保證云端服務正常運行。

2 系統(tǒng)的實現(xiàn)

2.1 計算環(huán)境和平臺

為了確保系統(tǒng)安全性和穩(wěn)定性，云端服務節(jié)點應運行在獨立的容器中。選擇Docker容器作為CloudROS的計算環(huán)境，與其他虛擬化技術相比，Docker容器處于應用程序級別，不需要虛擬化完整的操作系統(tǒng)，就像在主機上運行的進程一樣[11]。

2.2 基于REST API的本地-云端接口

機器人端采用REST API請求云端服務。在CloudROS中，把封裝好的云端服務和操作放入不同的URI中，客戶端通過REST API接口獲取云端服務。

云端計算服務URI可以表示成如下的形式：http://server_ip:port/compute///。其中,“server_ip:port”是云服務器的IP地址和云端服務管理器連續(xù)監(jiān)聽的端口；“compute”字段表示請求一個計算服務；“service”字段是指由云機器人平臺提供的云端計算服務；“action”字段是指控制服務狀態(tài)的特定動作；字段“token”用于云服務請求時的身份驗證。通過以上4個參數(shù)就可以在云端找到相應的資源。

2.3 ROS網(wǎng)絡的動態(tài)拓撲

ROS網(wǎng)絡和主節(jié)點都位于機器人端，云服務器收到機器人端端請求后，云服務節(jié)點想要動態(tài)加入本地ROS網(wǎng)絡以提供服務，需要將其自身注冊到本地的主節(jié)點上。因此，雙方都需要知道彼此的地址。ROS支持分布式主機和網(wǎng)絡，可以使用環(huán)境變量(例如ROS_MASTER_URI和ROS_IP)來定位主節(jié)點并配置主機。通常，每個主機都使用靜態(tài)配置，對于動態(tài)ROS網(wǎng)絡，每個主機僅在需要時配置其自己的環(huán)境變量。

為了使云端服務的 ROS 節(jié)點動態(tài)加入到本地 ROS 網(wǎng)絡中，機器人和云端服務端都需要配置相關的ROS環(huán)境變量。對于機器人端，需要環(huán)境配置文件 bash.rc 中配置 ROS_MASTER_URI 和 ROS_IP。對于云端，從機器人端的 POST請求參數(shù)中獲取ROS_MASTER_URI。并且在服務節(jié)點運行前配置臨時的 ROS_MASTER_URI 和 ROS_IP，在服務運行時才會生效；服務關閉時，臨時的環(huán)境變量也會失效。

2.4 本地端/云端的橋節(jié)點

盡管本地機器人和云端服務都遵循ROS標準，但云端服務加入本地機器人ROS網(wǎng)絡需要一個橋節(jié)點。橋接節(jié)點與rosbridge不同，rosbridge用于將消息從ROS協(xié)議轉(zhuǎn)換為非ROS協(xié)議，而橋接節(jié)點僅傳遞一些重要參數(shù)，建立連接后，所有消息均以ROS標準格式傳輸。

2.5 調(diào)度機制

CloudROS旨在為多個異構(gòu)機器人提供異步并發(fā)服務，可以根據(jù)需要擴展云服務。機器人可以請求多個服務，并且不同的機器人可以同時請求相同的服務。因此，有必要在云中加入調(diào)度機制，以確保其健壯性、穩(wěn)定性和安全性。調(diào)度機制如圖2所示。

圖2 服務請求和調(diào)度工作流程

a.當機器人請求云端服務時，將服務名稱、動作、令牌和本地替代服務節(jié)點的名稱發(fā)送到橋節(jié)點。

b.橋接節(jié)點收到請求后，首先檢查網(wǎng)絡狀況。如果網(wǎng)絡較差并且無法保證對云端服務的最低要求，則啟動相應的本地服務節(jié)點。如果網(wǎng)絡狀況良好，則橋接節(jié)點構(gòu)造REST URI并向云發(fā)起HTTP請求。

c.一旦請求了新的REST URI，云調(diào)度程序首先解析URI并提取參數(shù)(令牌，服務，動作)。

d.云調(diào)度程序檢查機器人的權限。如果機器人未經(jīng)授權或請求超出其權限，則拒絕該請求。

e.授權后，云調(diào)度程序檢查請求的云端服務是否存在。如果該服務不存在，該請求被忽略。如果該服務存在，則云調(diào)度程序檢查所請求服務的狀態(tài)并找到相應容器映像的位置。

f.此信息以及請求的動作被發(fā)送到處理功能。如果請求的服務當前正在運行并且動作為“開始”，則該請求被忽略；如果請求的服務未運行并且操作為“停止”，則該請求被忽略；如果請求的服務未運行且操作為“啟動”，則初始化容器并啟動云端服務節(jié)點；否則，調(diào)用停止腳本以停止云端服務節(jié)點，并且銷毀容器。

g.處理后，服務運行狀態(tài)在數(shù)據(jù)庫中更新。

3 云端服務性能的評估與管理

在此，QoS是基于云端的處理速度和網(wǎng)絡延遲以及處理結(jié)果的質(zhì)量來評估的，不確定的網(wǎng)絡條件和云端承載、負載變化通常都會影響到最終的QoS值。為了準確地計算QoS，本文對QoS指標進行加權計算得到最終QoS，權重可以由用戶根據(jù)任務屬性指定。QoS監(jiān)測和調(diào)節(jié)機制如圖3所示。

圖3 QoS監(jiān)測和調(diào)節(jié)機制

3.1 QoS指標

3.1.1 往返延時

服務延遲由請求響應時間(RRT)來度量，往返延時(RTT)由2個部分組成：網(wǎng)絡響應時間和應用程序響應時間。由于云端通常對同一任務具有恒定的處理時間，因此RRT可以用網(wǎng)絡響應時間來近似。RTT用于表示網(wǎng)絡響應時間，較小的RTT表示較小的網(wǎng)絡延遲。RTT評估網(wǎng)絡連接的質(zhì)量，但該指標不可控，不能按需調(diào)節(jié)。

通過定期“PING”云服務器，可以獲得RTT值的統(tǒng)計結(jié)果。在CloudROS系統(tǒng)中，定義了2個RTT閾值：Tg和Tb分別表示低延遲和高延遲的臨界值。對于RTT影響的Qt的計算描述為

(1)

如果Qt>50%，則處于中等狀態(tài); 如果Qt<50%，那就是狀況不佳。

3.1.2 數(shù)據(jù)發(fā)布頻率

云端服務節(jié)點訂閱一些數(shù)據(jù)源主題，并將處理后的結(jié)果發(fā)布到目標話題上。2個話題都有自己的發(fā)布率。rsrc表示源話題的發(fā)布頻率；rdst表示目標話題的發(fā)布頻率。rsrc和rdst的平衡對于ROS機器人控制系統(tǒng)非常重要。由于ROS系統(tǒng)中的消息傳輸采用先入先出(FIFO)隊列的方式，如果rdst

(2)

Nqueue為隊列的大小。

為了避免引入新的延遲時間，應該盡量保持rsrc和rdst近似相等。而由數(shù)據(jù)發(fā)布頻率產(chǎn)生的云服務質(zhì)量影響為

(3)

對于多個訂閱和發(fā)布者的情況，客戶端可以分配K對話題來評估服務質(zhì)量。

(4)

其中，最小值作為最終的服務質(zhì)量的評分。

3.1.3 數(shù)據(jù)的壓縮率

對于圖像和點云這樣的高帶寬消息，為了減少傳輸和計算復雜度通常使用壓縮技術。對于圖像，提供了圖像傳輸機制從而將原始消息編碼為壓縮格式，例如“JPEG”；對于點云，可以應用一系列過濾器(例如Voxel過濾器，Radius離群值過濾器)來減少點數(shù)。算法中通常有一個比例因子來控制結(jié)果的質(zhì)量和壓縮率。為了協(xié)調(diào)不同因素的影響，進行歸一化處理方式為

(5)

Sbest為質(zhì)量最好時的壓縮系數(shù)或者沒有壓縮時的壓縮系數(shù)；Snow為當前的壓縮系數(shù)。

3.2 QoS的計算算法

對于不同的服務，各個指標的優(yōu)先級不同，最終QoS的值是通過3個指標的加權總和來計算的：

Q(k)=wtQt(k)+wrQr(k)+wsQs(k)

(6)

k為QoS監(jiān)控頻次；wt、wr和ws分別表示RTT、數(shù)據(jù)發(fā)布頻率和數(shù)據(jù)壓縮率影響Q值的權重，wt+wr+ws=1，可以通過分配不同的組合來調(diào)整QoS。由于時間延遲通常會對控制系統(tǒng)造成嚴重的負面影響，因此它具有最大的權重。默認配置為：wt=0.6，wr=0.3，ws=0.1。為了減少Q(mào)oS值的變化，將滑動窗口平均算法應用于Q(k)。

(7)

k表示QoS監(jiān)控頻次，窗口大小為M+1。為了減少Q(mào)oS的監(jiān)測和管理難度，將QoS劃分為4個應對等級：流暢、中等、一般、極差。如表1所示。

表1 QoS等級劃分

當云機器人系統(tǒng)運行時，許多不確定因素可能會影響服務質(zhì)量，如信號質(zhì)量差，網(wǎng)絡環(huán)境擁擠，服務請求擁擠以及服務器負載沉重等，導致QoS動態(tài)變化。根據(jù)上述規(guī)則，可以評估當前的服務質(zhì)量，采取適當?shù)牟呗詠泶_保穩(wěn)定和高質(zhì)量的服務，具體的調(diào)整策略如表2所示。

表2 云端服務動態(tài)調(diào)節(jié)措施

如果QoS Level = 1，表示云端服務處于良好狀態(tài)?？梢詫崿F(xiàn)低延時和高幀率傳輸。因此，在當前配置下無需進行任何更改。

如果QoS Level = 2，表示云端服務的質(zhì)量略低，但相對較好。因此，可以適當降低高帶寬消息的壓縮率，這樣仍然可以保持低延遲和高幀率傳輸。

如果QoS Level = 3，表示云端服務的質(zhì)量已降低到嚴重的低水平。因此，為了繼續(xù)使用云服務，除了降低壓縮率之外，還應該降低發(fā)布率。該系統(tǒng)將以高延遲，低發(fā)布率的狀態(tài)工作。

如果QoS Level = 4，表示延遲嚴重，以至于云端服務無法正常工作。在這種情況下，應當切換到相應的本地服務。

4 實驗

為了驗證CloudROS系統(tǒng)的可行性、有效性和效率，在實物實驗平臺上進行了本地云連接性和QoS調(diào)度機制的性能實驗。

4.1 實驗平臺

實驗平臺如圖4所示，包括1個云服務器、1個移動機器人和1個電腦模擬的客戶端。它們之間通過WiFi連接。

圖4 實驗平臺

4.1.1 云服務器

云服務器是一臺“高性能”的電腦(與機器人相比)，處理器為英特爾酷睿i7-8700，16 GB 內(nèi)存，安裝了 Ubuntu16.04 和 ROS Kinetic 操作系統(tǒng)，還安裝了LXD用于管理Docker容器以及MySQL數(shù)據(jù)庫用于存放容器鏡像。

4.1.2 移動機器人

移動機器人采用3個全向輪驅(qū)動，并配置了樹莓派、雙目攝像頭、觸摸屏、麥克風和揚聲器，如圖4所示。機器人的每個輪子上都有1個編碼器，同時還搭載了1個AHRS慣性傳感器，用于估計機器人的里程信息。樹莓派控制機器人，并與云服務器進行通信，安裝了Ubuntu Mate系統(tǒng)和Hydro版本的ROS。電機控制、里程估計等的低水平任務由Arduino Mega2560完成。Arduino 和樹莓派之間的通信使用Rosserial 接口實現(xiàn)。

4.1.3 基準測試任務

在CloudROS系統(tǒng)中，機器人端和云端同時集成了gmapping功能包、pointcloud_to_laser功能包、stereo_proc包等構(gòu)成本次實驗的雙目構(gòu)圖服務，如圖5所示。雙目構(gòu)圖服務具體完成對左右圖像的立體匹配、三維提取、點云轉(zhuǎn)激光等一系列操作，最終獲取仿激光數(shù)據(jù)，并且由此構(gòu)建二維地圖。

圖5 視覺處理任務

4.2 云服務的連接性和有效性實驗

4.2.1 本地服務模式

在本地服務模式中，圖像采集和處理都在機器人端完成。本地服務模式下的實驗結(jié)果如圖6所示，其中圖6a表示樹莓派CPU的占用率，圖6b表示源圖像數(shù)據(jù)發(fā)布頻率和目標仿激光數(shù)據(jù)發(fā)布頻率的對比情況。

圖6 本地服務模式下的實驗結(jié)果

由圖6a可知：當樹莓派獨立處理雙目圖像時，樹莓派的CPU占用率達到了80%，表明系統(tǒng)運行壓力很大。由圖6b可知：當源圖像數(shù)據(jù)發(fā)布頻率是9 Hz，目標仿激光數(shù)據(jù)的發(fā)布頻率小于1 Hz，絕大多數(shù)圖像在傳輸過程中丟失。說明本地機器人的計算處理能力低效，機器人無法獨立完成計算密集型任務。

4.2.2 云服務模式

在云服務模式中，圖像處理任務在云端完成，機器人只負責圖像數(shù)據(jù)的采集。云服務模式下的實驗結(jié)果如圖7所示。

圖7 云服務模式下的實驗結(jié)果

由圖7a可知：當云端負責處理圖像時，樹莓派系統(tǒng)的CPU占用率大約在30%，這表明系統(tǒng)運行 壓力正常，系統(tǒng)完全有空閑的資源去完成其他任務。由圖7b可知：在圖像處理任務遷移到云端的條件下，源圖像數(shù)據(jù)發(fā)布頻率和目標仿激光數(shù)據(jù)的發(fā)布頻率都近似9 Hz，也就是說雙目圖像任務被高效地完成。實驗結(jié)果說明將計算密集型的計算任務遷移到云端后，釋放了機器人系統(tǒng)的運行壓力，同時云端具有更強的計算能力，處理的效果也遠比機器人更加穩(wěn)定高效。

通過比較本地模式和云服務模式下的處理結(jié)果，驗證了CloudROS系統(tǒng)架構(gòu)的可靠性和高效性。機器人通過訪問云端服務，將計算復雜度較高的任務交由云端處理，提升了機器人的工作性能。

4.3 QoS有效性實驗

QoS機制就是為了監(jiān)控動態(tài)網(wǎng)絡條件下服務質(zhì)量并進行服務質(zhì)量動態(tài)優(yōu)化的。下面將對比不采取動態(tài)調(diào)整措施和采取動態(tài)調(diào)整的QoS結(jié)果。

4.3.1 不采取調(diào)整措施

在不采取動態(tài)調(diào)整措施的情況下QoS的變化情況如圖8所示。

由圖8a可知：網(wǎng)絡傳輸速率在第27次和第42次的監(jiān)控中突然降低，而相應的RTT則有所增加，表示網(wǎng)絡在逐步變差，低的網(wǎng)絡傳輸速率限制了高幀率、高質(zhì)量的數(shù)據(jù)通信，影響云端的服務處理結(jié)果；在第54次監(jiān)控中網(wǎng)絡傳輸速率恢復到高速率值，而RTT也降低初始值左右。由圖8b可知：在第27次監(jiān)控時仿激光數(shù)據(jù)的發(fā)布頻率極速降低到0幀，這說明了數(shù)據(jù)在網(wǎng)絡傳輸過程中完全丟失；在第54次監(jiān)控后，也就是網(wǎng)絡條件恢復到高速狀況時，仿激光數(shù)據(jù)的發(fā)布頻率又達到與源圖像數(shù)據(jù)相近值。由圖8c可知：在網(wǎng)絡變差的過程中，QoS也在逐步下降，說明云服務性能持續(xù)下降；而在網(wǎng)絡恢復后，QoS也得到了提升，說明云服務性能也得到恢復。

圖8 不采取調(diào)整措施的QoS實驗結(jié)果

4.3.2 采取調(diào)整措施

之前不采取調(diào)整措施的QoS實驗證明了QoS的變化依賴網(wǎng)絡條件。采取調(diào)整措施的QoS實驗結(jié)果如圖9所示。

由圖9a可知：網(wǎng)絡在第38次、第76次和第122次監(jiān)控中網(wǎng)絡傳輸速率降低，RTT增加，網(wǎng)絡狀況逐步下降；從第134次監(jiān)控開始，網(wǎng)絡傳輸速率逐步提升，RTT逐步下降，網(wǎng)絡狀況得到持續(xù)改善。圖9b顯示仿激光數(shù)據(jù)發(fā)布頻率在第38次監(jiān)控中突然降低，圖9c顯示QoS也發(fā)生了等級跳躍，降低到等級2的水平，這激發(fā)了QoS調(diào)控機制。根據(jù)表2的動態(tài)調(diào)整措施，此時的源圖像數(shù)據(jù)壓縮比率被動態(tài)降低，從而一定程度上降低了計算復雜度。在進行壓縮比率調(diào)整后，激光數(shù)據(jù)發(fā)布頻率恢復到源圖像數(shù)據(jù)相近值，并且QoS也適當?shù)玫教嵘⒎€(wěn)定在等級為2的區(qū)域。雖然采取措施后，犧牲了數(shù)據(jù)的質(zhì)量，但是保證了云端對高幀率數(shù)據(jù)的流暢處理和服務的穩(wěn)定運行。

圖9 采取調(diào)整措施的QoS實驗結(jié)果

圖9b的仿激光數(shù)據(jù)發(fā)布頻率在第76次監(jiān)控中再次突然降低，圖9c中的QoS同樣發(fā)生了等級跳躍，降低到等級3的水平。說明此時的調(diào)整措施不僅保持低的壓縮比率，還要降低數(shù)據(jù)源圖像數(shù)據(jù)的發(fā)布頻率，從而更進一步地減少計算復雜度，降低網(wǎng)絡中數(shù)據(jù)傳輸壓力。經(jīng)過措施調(diào)整之后，目標仿激光數(shù)據(jù)的發(fā)布頻率得到一定提升并且會穩(wěn)定在與當前源圖像發(fā)布頻率相近的水平。QoS曲線也同樣會得到適當提升并達到一個新的平衡狀態(tài)。

圖9b的仿激光數(shù)據(jù)發(fā)布頻率在第122次監(jiān)控中突然降低到0，圖9c中的QoS同樣發(fā)生了等級跳躍，降低到等級4的水平。根據(jù)表2所示的動態(tài)調(diào)整措施，此時本地服務切換機制觸發(fā)，云端服務節(jié)點關閉，相應的本地服務節(jié)點開啟。但是根據(jù)圖6的結(jié)果，本地無法處理該雙目任務，所以仿激光數(shù)據(jù)發(fā)布頻率小于1。在第134次、第136次、142次的監(jiān)控中，網(wǎng)絡服務質(zhì)量逐漸得到改善，QoS也不斷提升。在第134次監(jiān)控中，QoS升至等級3的水平，說明此時的網(wǎng)絡傳輸能力達到了云端服務的基本要求，此時本地服務節(jié)點停止，云端服務節(jié)點啟動。根據(jù)表2，此時源數(shù)據(jù)的發(fā)布頻率和壓縮比率還是保持一個比較低的水平。目標仿激光數(shù)據(jù)發(fā)布頻率上升。在第136次監(jiān)控中，QoS升至等級2的水平，根據(jù)表2，提高源數(shù)據(jù)的發(fā)布頻率，源數(shù)據(jù)滿足高幀率、低壓縮比率的條件。經(jīng)過措施調(diào)整后，目標仿激光數(shù)據(jù)發(fā)布頻率上升，QoS也得到提升。

通過比較2組實驗結(jié)果可知，網(wǎng)絡條件直接影響了QoS指標且QoS能夠反映服務質(zhì)量。通過QoS動態(tài)調(diào)整機制一定程度上提升云服務質(zhì)量，并當在前的網(wǎng)絡條件下使QoS穩(wěn)定運行，證明該動態(tài)調(diào)整機制是有效的。

5 結(jié)束語

本文提出的CloudROS云機器人系統(tǒng)在引入授權，安全認證和QoS功能的同時，盡可能保持ROS規(guī)范。所有云服務均作為1個或1組ROS節(jié)點提供，這些節(jié)點可以動態(tài)加入到本地機器人上運行的ROS網(wǎng)絡。機器人端只有1個ROS主節(jié)點，為云/本地服務交換功能提供可行性并提升了網(wǎng)絡斷開時的魯棒性。CloudROS中引入了QoS監(jiān)測和控制機制，根據(jù)不同的QoS狀態(tài)可以進行動態(tài)調(diào)整參數(shù)和網(wǎng)絡拓撲，從而保證了在變化的網(wǎng)絡條件下云服務的穩(wěn)定性和流暢性。實驗結(jié)果證明，CloudROS云機器人系統(tǒng)可以將機器計算密集型任務卸載到云端并提高整體性能，還證明了QoS機制在監(jiān)視系統(tǒng)狀態(tài)和控制系統(tǒng)性能方面的有效性。