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

(東北大學(xué)機(jī)械工程與自動(dòng)化學(xué)院，遼寧 沈陽(yáng) 110819)

0 引言

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

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

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

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

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

圖1 CloudROS系統(tǒng)

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

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

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

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

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

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

2.1 計(jì)算環(huán)境和平臺(tái)

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

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

機(jī)器人端采用REST API請(qǐng)求云端服務(wù)。在CloudROS中，把封裝好的云端服務(wù)和操作放入不同的URI中，客戶端通過(guò)REST API接口獲取云端服務(wù)。

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

2.3 ROS網(wǎng)絡(luò)的動(dòng)態(tài)拓?fù)?/h3>

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

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

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

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

2.5 調(diào)度機(jī)制

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

圖2 服務(wù)請(qǐng)求和調(diào)度工作流程

a.當(dāng)機(jī)器人請(qǐng)求云端服務(wù)時(shí)，將服務(wù)名稱、動(dòng)作、令牌和本地替代服務(wù)節(jié)點(diǎn)的名稱發(fā)送到橋節(jié)點(diǎn)。

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

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

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

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

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

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

3 云端服務(wù)性能的評(píng)估與管理

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

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

3.1 QoS指標(biāo)

3.1.1 往返延時(shí)

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

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

(1)

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

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

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

(2)

Nqueue為隊(duì)列的大小。

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

(3)

對(duì)于多個(gè)訂閱和發(fā)布者的情況，客戶端可以分配K對(duì)話題來(lái)評(píng)估服務(wù)質(zhì)量。

(4)

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

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

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

(5)

Sbest為質(zhì)量最好時(shí)的壓縮系數(shù)或者沒(méi)有壓縮時(shí)的壓縮系數(shù)；Snow為當(dāng)前的壓縮系數(shù)。

3.2 QoS的計(jì)算算法

對(duì)于不同的服務(wù)，各個(gè)指標(biāo)的優(yōu)先級(jí)不同，最終QoS的值是通過(guò)3個(gè)指標(biāo)的加權(quán)總和來(lái)計(jì)算的：

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

(6)

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

(7)

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

表1 QoS等級(jí)劃分

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

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

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

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

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

如果QoS Level = 4，表示延遲嚴(yán)重，以至于云端服務(wù)無(wú)法正常工作。在這種情況下，應(yīng)當(dāng)切換到相應(yīng)的本地服務(wù)。

4 實(shí)驗(yàn)

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

4.1 實(shí)驗(yàn)平臺(tái)

實(shí)驗(yàn)平臺(tái)如圖4所示，包括1個(gè)云服務(wù)器、1個(gè)移動(dòng)機(jī)器人和1個(gè)電腦模擬的客戶端。它們之間通過(guò)WiFi連接。

圖4 實(shí)驗(yàn)平臺(tái)

4.1.1 云服務(wù)器

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

4.1.2 移動(dòng)機(jī)器人

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

4.1.3 基準(zhǔn)測(cè)試任務(wù)

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

圖5 視覺(jué)處理任務(wù)

4.2 云服務(wù)的連接性和有效性實(shí)驗(yàn)

4.2.1 本地服務(wù)模式

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

圖6 本地服務(wù)模式下的實(shí)驗(yàn)結(jié)果

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

4.2.2 云服務(wù)模式

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

圖7 云服務(wù)模式下的實(shí)驗(yàn)結(jié)果

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

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

4.3 QoS有效性實(shí)驗(yàn)

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

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

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

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

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

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

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

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

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

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

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

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

5 結(jié)束語(yǔ)

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