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

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

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

0 引言

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

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

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

1 系統的整體框架

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

圖1 CloudROS系統

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

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

b.云端服務以ROS節點的形式提供。ROS節點間通信方式非常適合分布式架構，本地和云端建立以話題為基礎的節點通信，避免了數據通信的格式轉換。另一方面，ROS系統集成了豐富的開源算法包，能夠實現機器人應用服務的快速部署。

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

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

2 系統的實現

2.1 計算環境和平臺

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

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

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

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

2.3 ROS網絡的動態拓撲

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

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

2.4 本地端/云端的橋節點

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

2.5 調度機制

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

圖2 服務請求和調度工作流程

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

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

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

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

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

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

g.處理后，服務運行狀態在數據庫中更新。

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

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

圖3 QoS監測和調節機制

3.1 QoS指標

3.1.1 往返延時

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

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

(1)

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

3.1.2 數據發布頻率

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

(2)

Nqueue為隊列的大小。

為了避免引入新的延遲時間，應該盡量保持rsrc和rdst近似相等。而由數據發布頻率產生的云服務質量影響為

(3)

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

(4)

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

3.1.3 數據的壓縮率

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

(5)

Sbest為質量最好時的壓縮系數或者沒有壓縮時的壓縮系數；Snow為當前的壓縮系數。

3.2 QoS的計算算法

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

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

(6)

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

(7)

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

表1 QoS等級劃分

當云機器人系統運行時，許多不確定因素可能會影響服務質量，如信號質量差，網絡環境擁擠，服務請求擁擠以及服務器負載沉重等，導致QoS動態變化。根據上述規則，可以評估當前的服務質量，采取適當的策略來確保穩定和高質量的服務，具體的調整策略如表2所示。

表2 云端服務動態調節措施

如果QoS Level = 1，表示云端服務處于良好狀態。可以實現低延時和高幀率傳輸。因此，在當前配置下無需進行任何更改。

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

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

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

4 實驗

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

4.1 實驗平臺

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

圖4 實驗平臺

4.1.1 云服務器

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

4.1.2 移動機器人

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

4.1.3 基準測試任務

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

圖5 視覺處理任務

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

4.2.1 本地服務模式

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

圖6 本地服務模式下的實驗結果

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

4.2.2 云服務模式

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

圖7 云服務模式下的實驗結果

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

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

4.3 QoS有效性實驗

QoS機制就是為了監控動態網絡條件下服務質量并進行服務質量動態優化的。下面將對比不采取動態調整措施和采取動態調整的QoS結果。

4.3.1 不采取調整措施

在不采取動態調整措施的情況下QoS的變化情況如圖8所示。

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

圖8 不采取調整措施的QoS實驗結果

4.3.2 采取調整措施

之前不采取調整措施的QoS實驗證明了QoS的變化依賴網絡條件。采取調整措施的QoS實驗結果如圖9所示。

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

圖9 采取調整措施的QoS實驗結果

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

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

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

5 結束語

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