基于軟件定義的無人車系統(tǒng)

鄭凱強

（浙江理工大學(xué) 信息學(xué)院， 杭州 310018）

0 引言

隨著萬物互聯(lián)的時代的到來， 大量的軟硬件資源相互聯(lián)通。 各種設(shè)備在互聯(lián)網(wǎng)上連接， 各種新型的應(yīng)用需求層出不窮， 各類新的數(shù)字經(jīng)濟模式也陸續(xù)涌現(xiàn)， 諸如電子商務(wù)、電子政務(wù)、共享經(jīng)濟、人工智能應(yīng)用等。 為了把各類軟硬件的基礎(chǔ)設(shè)施完成數(shù)字化以及定制化， 就要用軟件去重新定義傳統(tǒng)的基礎(chǔ)設(shè)施。 目前， 關(guān)于軟件定義用得最多的就是軟件定義網(wǎng)絡(luò)（SDN）［1－2］， 這是將網(wǎng)絡(luò)分為3 層， 分別是：基礎(chǔ)設(shè)施層、控制層和應(yīng)用層。 其中， 控制層通過接口與基礎(chǔ)設(shè)施層通信， 向路由器和交換機發(fā)送數(shù)據(jù)包， 同時向網(wǎng)絡(luò)管理者接口提供網(wǎng)絡(luò)相關(guān)的可編程接口， 網(wǎng)絡(luò)管理者是通過接口編寫的管理程序來設(shè)定控制層， 從而控制整個軟件定義網(wǎng)絡(luò)中的數(shù)據(jù)發(fā)送。

如今， 軟件定義無人系統(tǒng)的實際應(yīng)用仍是一項難題。 例如， 在DARPA 中的機器人技術(shù)挑戰(zhàn)［3］或無人機控制［4］。 無人系統(tǒng)有著各種軟硬件設(shè)施以及不同式樣的接口與編碼方式， 若想在動態(tài)變化的環(huán)境下調(diào)配和維護好這些資源并非易事， 因此亟待使用軟件定義范式抽象底層內(nèi)容來控制底層設(shè)備， 同時給用戶帶來便捷高效體驗。 本文的重點是提出一個可行的軟件定義無人車系統(tǒng)來支持提供對資源的有效管理和控制或調(diào)整工作流以滿足用戶相關(guān)需求。

本文中， 提出了軟件定義無人車系統(tǒng)的主要架構(gòu)， 使用MAPE－K 結(jié)構(gòu)設(shè)計了軟件定義無人車系統(tǒng)的控制層。 其次， 設(shè)計了搭建此系統(tǒng)的思路并據(jù)此思路開發(fā)搭建了一個有完整功能的無人車系統(tǒng)。然后， 對本文系統(tǒng)進行導(dǎo)航和碰撞實驗。 最后， 對本文所提系統(tǒng)進行了總結(jié)， 并探討了未來可能的改進方向。

1 軟件定義架構(gòu)

1.1 軟件定義無人車的系統(tǒng)架構(gòu)層次設(shè)計

本系統(tǒng)參照軟件定義網(wǎng)絡(luò)的結(jié)構(gòu)， 將系統(tǒng)框架分為3 個層次：硬件執(zhí)行層、控制器層和應(yīng)用層［5］。其中， 硬件執(zhí)行層包含了無人車的各種硬件：激光雷達、里程計、路由器、移動底盤、車輪、非智能化電路板等， 通過調(diào)用相關(guān)硬件可以實現(xiàn)用戶需求。 控制器層包括3D 模擬系統(tǒng)、機器人操作系統(tǒng)（ROS）和動作捕捉系統(tǒng)。 控制器層隱藏了與用戶的需求無關(guān)聯(lián)的硬件細節(jié)和硬件物理構(gòu)造， 如：激光雷達的控制信號、射電激光的口徑、正常工作時的轉(zhuǎn)速等，然后將硬件的基本信息、功能屬性、使用屬性等抽象出來并顯示在應(yīng)用層上， 與此同時， 控制器層提供了相關(guān)接口用來管控硬件執(zhí)行層中基礎(chǔ)硬件。 應(yīng)用層是管理用戶交互的一層， 應(yīng)用層將感知并分析用戶需求以維持系統(tǒng)與用戶的交互， 通常由一系列具體功能所組成。 軟件定義的無人車框架如圖1 所示。

圖1 無人車架構(gòu)Fig. 1 The architecture of the unmanned vehicle

1.2 軟件定義無人車系統(tǒng)核心設(shè)計

控制器層是整個無人系統(tǒng)的關(guān)鍵。 控制器層提供接口完成對下層資源管理和控制。 本文無人車的控制器層的設(shè)計上使用MAPE－K 結(jié)構(gòu)［6］， 使管理器能夠監(jiān)視和控制所需硬件以及下位機。 MAPE－K結(jié)構(gòu)如圖2 所示。 由圖2 可知，MAPE－K 結(jié)構(gòu)由4個組件和一個知識庫組成。 這4 個組件是：監(jiān)視組件、分析組件、計劃組件和執(zhí)行組件。

圖2 MAPE－K 結(jié)構(gòu)示意圖Fig. 2 MAPE－K structure diagram

1.2.1 監(jiān)視組件

監(jiān)視組件（Moniter）在控制器層中起到監(jiān)視作用， 關(guān)于所監(jiān)視的內(nèi)容主要有2 個，即：用戶需求和系統(tǒng)運行時的環(huán)境。 那么在軟件定義的無人車系統(tǒng)里運行環(huán)境即無人車所處的環(huán)境， 而用戶需求即用戶所期望無人車的行動。 當(dāng)然這些信息可能是會隨時變化的， 而這些改變是需要監(jiān)視組件隨時捕捉到的。 為了對系統(tǒng)中的每一個變化都敏感， 監(jiān)視器可以由任何變化事件觸發(fā)、且可隨時隨地觸發(fā)。 監(jiān)視組件是系統(tǒng)變更的依據(jù)， 系統(tǒng)可以根據(jù)捕獲的變更收 集 需 求 變 更 （ collectREInfo ）、 環(huán) 境 變 更（collectENInfo）或資源變更（collectRSInfo）［7］。

在本系統(tǒng)中負責(zé)用戶需求變更收集的是操作界面交互和VR 設(shè)備交互。 前者明確用戶的導(dǎo)航需求， 而后者則負責(zé)用戶對無人車的移動需求。

以上是關(guān)于需求變更的內(nèi)容。 而由于環(huán)境變更對無人車的影響非常重要， 所以關(guān)于環(huán)境變更， 此軟件定義無人車系統(tǒng)用了ROS 和動作捕捉系統(tǒng)來監(jiān)視隨時發(fā)生的變化。 在這其中ROS 主要負責(zé)監(jiān)視掛載在無人車上的傳感器所獲取的信息， 例如激光雷達的掃描信息。 而動作捕捉系統(tǒng)則負責(zé)環(huán)境信息矯正（矯正ROS 上導(dǎo)航系統(tǒng)的偏差）和精確環(huán)境信息（主要是光學(xué)定位， 會比ROS 上的定位要更為準確）。 動作捕捉系統(tǒng)對無人車位置的捕捉如圖3所示。

圖3 系統(tǒng)監(jiān)測過程圖Fig. 3 System monitoring process diagram

1.2.2 分析組件

分析組件（Analyze）主要負責(zé)處理監(jiān)視組件所收集到的信息， 當(dāng)系統(tǒng)或是環(huán)境出現(xiàn)一些變化時，由監(jiān)視組件負責(zé)檢測， 分析組件則從監(jiān)視組件收集的數(shù)據(jù)中提取有用的信息。 為此， 分析組件從需求和環(huán)境信息中提取重要特征， 交由計劃組件將進一步使用這些特征來做出決策。 關(guān)于分析組件的運行過程， 本文用RVIZ 上的坐標轉(zhuǎn)化來舉例， 相對坐標示意如圖4 所示。

圖4 相對坐標示意圖Fig. 4 Schematic diagram of relative coordinates

雷達在底盤坐標系的位置和方向， 可由如下公式進行描述：

RVIZ 組建時雷達在世界坐標系的位置和方向，對此求得的世界坐標系為：

由此推得：

所以， 在RVIZ 使用R、T矩陣時， 雷達的旋轉(zhuǎn)和平移公式見式（4）：

假設(shè)傳感器能檢測到雷達的相對坐標A（a，b，c）， 此坐標是以底座的坐標作為基準坐標系來定的。 現(xiàn)有的無人車需要到達目標地， 當(dāng)前無人車的激光雷達可以探測到目標物的坐標（x，y，z），但是該坐標是以雷達為參考系的， 而實際操作的是無人車的底盤。 此時需要調(diào)用ROS 中的TF（Transform Listener）節(jié)點來負責(zé)分析雷達到底盤的坐標轉(zhuǎn)化關(guān)系。

1.2.3 決策組件

決策組件（Plan）會根據(jù)分析組件提供環(huán)境信息和系統(tǒng)資源的狀態(tài)做出決策。 決策的目的就是使所有的決策都在系統(tǒng)所能提供方式里盡量滿足用戶的需求。 尋求一個在當(dāng)前狀況下的最優(yōu)解，在當(dāng)前系統(tǒng)配置仍然能滿足用戶需求的情況下選擇不變更系統(tǒng)的決策， 反之， 則更改系統(tǒng)的決策。 例如：當(dāng)無人車在沒有靠近障礙物時系統(tǒng)使用的是全局路徑規(guī)劃global＿planner 節(jié)點， 但當(dāng)無人車很接近障礙物時調(diào)用的將會是局部路徑規(guī)劃local＿planner 節(jié)點，碰到障礙后調(diào)用的是自動進行逃離恢復(fù)recovery＿behaviors 結(jié)點等。

1.2.4 執(zhí)行組件

執(zhí)行組件（Execute）根據(jù)上一步分析組件的安排對系統(tǒng)中的資源進行調(diào)度。 執(zhí)行組件會將需要調(diào)用的組件寫成一個工作流程。 通過這個流程來實現(xiàn)資源的調(diào)度。

ROS 對無人車的下位機傳輸運動控制指令前，需要獲取odom 話題中里程計信息以及scan 話題中的激光雷達信息， 然后通過cmd＿vel 話題中的下位機控制接口來實現(xiàn)控制指令發(fā)送， ROS 硬件控制框架如圖5 所示。

圖5 ROS 硬件控制框架Fig. 5 ROS hardware control framework

cmd＿vel 話題將控制消息傳輸?shù)较挛粰C控制接口從而對無人車底盤進行運動控制， 該消息的主要類型為geometry＿msgs／Twist， 該數(shù)據(jù)類型最常用的3 個變量為：linear.x、linear.y和angular.z， 分別表示水平線速度、 垂直線速度以及角速度。

ROS 對無人車的下位機控制原理如圖6 所示，有控制需求的節(jié)點通過cmd＿vel 話題向相關(guān)接口base＿controller 節(jié)點發(fā)送話題信息， 然后base＿controller 節(jié)點會將控制信息通過串口傳輸給控制板（本文無人車中使用的是Adurnio 控制板）。 接下來，下位機根據(jù)相關(guān)運動過程的計算來確定無人車底盤輪胎的轉(zhuǎn)速， 并將轉(zhuǎn)速信息發(fā)給電動機驅(qū)動以達到控制電機轉(zhuǎn)速的效果。 最后，電動機驅(qū)動會計算來自編碼器的電子脈沖速度， 以此對輪子轉(zhuǎn)速進行監(jiān)測并將轉(zhuǎn)速控制在一個定值。

圖6 下位機控制原理圖Fig. 6 Schematic diagram of lower computer control

1.2.5 知識庫

知識庫類似數(shù)據(jù)庫， 主要負責(zé)維護服務(wù)于此系統(tǒng)的4 種信息：可用軟件服務(wù)列表、硬件設(shè)備列表、環(huán)境信息和系統(tǒng)配置信息。 對于前2 種類型的信息， 其中環(huán)境信息和系統(tǒng)配置信息則屬于一種動態(tài)信息。 當(dāng)一些現(xiàn)有的軟件服務(wù)或硬件設(shè)備發(fā)生變化時， 知識庫會對這些變化進行處理和反映， 使知識庫中存儲的信息始終與系統(tǒng)資源的狀態(tài)保持一致［8－9］。

系統(tǒng)有時候需要接入一些新的設(shè)備或者軟件服務(wù)， 此時這些信息需要被注冊在系統(tǒng)之中。 注冊軟件服務(wù)或硬件設(shè)備時， 需要將相關(guān)資源加載到系統(tǒng)中，并由軟件資源池或設(shè)備層來維護。 此時需要借助一個叫RVIZ 的可視化工具， 向用戶展示傳感器的數(shù)據(jù)信息、無人車模型、坐標變化關(guān)系等。 要將相關(guān)的功能信息通過發(fā)送節(jié)點發(fā)送并部署到ROS＿displays 節(jié)點中， 才能將硬件信息展示在RVIZ 界面上。 RVIZ 上激光雷達數(shù)據(jù)如圖7 所示。 RVIZ 訂閱了激光雷達數(shù)據(jù)消息， 并展示激光雷達數(shù)據(jù)。

圖7 RVIZ 上激光雷達數(shù)據(jù)Fig. 7 Lidar data on RVIZ

2 設(shè)計思路與開發(fā)流程

2.1 系統(tǒng)總體框架

系統(tǒng)采用3 層架構(gòu)體系， 由顯示模塊、操作模塊、功能模塊、硬件模塊、物理以及數(shù)字模型模塊、監(jiān)視模塊等6 個模塊組成， 如圖8 所示。 這里， 對系統(tǒng)中各模塊的設(shè)計功能， 將給出剖析概述如下。

圖8 系統(tǒng)總體框架Fig. 8 The framework of the system

（1）顯示模塊。 用戶可以在VR 中看到的效果，包括場景搭建和視角轉(zhuǎn)換。

（2）操作模塊。 該模塊主要實現(xiàn)系統(tǒng)的GUI 界面顯示和人機交互等功能。

（3）功能模塊。 軟件定義的核心模塊， 主要負責(zé)建圖、 導(dǎo)航、 控制無人車移動以及執(zhí)行邏輯等模塊。

（4）硬件模塊。 小車的外接設(shè)備， 以及下位機開發(fā)板。

（5）物理以及數(shù)字模型模塊。 在Unity 中通過編寫C＃腳本、動作捕捉系統(tǒng)中3D 標志物， 對小車的物理模型（Rigidbody）和物理外型的建模；在ROS中則是對小車外型和傳感器等硬件的建模， 以實現(xiàn)無人車的虛擬仿真。

（6）監(jiān)視模塊。 動作捕捉系統(tǒng)對無人車和障礙物位姿的監(jiān)視。

2.2 開發(fā)流程

軟件定義無人車系統(tǒng)主要由VR 系統(tǒng)、3D 模擬系統(tǒng)（Unity 引擎）、機器人操作系統(tǒng)（ROS）、動作捕捉系統(tǒng)、實體無人車五部分組成。 該系統(tǒng)的開發(fā)流程如圖9 所示。 對此擬做闡釋分述如下。

圖9 RVIZ 上激光雷達數(shù)據(jù)系統(tǒng)開發(fā)流程圖Fig. 9 Flow chart of the system development

Step 1完成對實體無人車平臺以及傳感器的搭建。

Step 2在3DXMax 中對障礙物和虛擬無人車進行三維建模并賦予對應(yīng)物理屬性。

Step 3在Unity 中編寫與實體無人車下位機通訊SDK 以及運行邏輯，并與虛擬無人車部件對應(yīng)起來。

Step 4用Unity 對無人車使用場景進行設(shè)計與開發(fā)。

Step 5搭建ROS， 設(shè)置ROS 中各結(jié)點通訊。

Step 6用ROS 對無人車下位機進行通訊， 用URDF 集成RVIZ 建立可用模型、關(guān)節(jié)件之間的邏輯（用于計算導(dǎo)航的相對偏差）。

Step 7在ROS 中布置好SLAM 建圖和導(dǎo)航算法。

Step 8在動作捕捉系統(tǒng)中標注跟蹤點信息，配置跟蹤數(shù)據(jù)， 并用跟蹤點建模剛體作為實體無人車在虛擬中所反映位姿的虛擬模型。

Step 9讓Unity 與動作捕捉系統(tǒng)進行通訊，將動作捕捉系統(tǒng)中的剛體與到Unity 的虛擬無人車模型進行實時通訊。

Step 10配置好VR 設(shè)備， 并編寫調(diào)試關(guān)于VR 設(shè)備的交互系統(tǒng)， 用SteamVR 連接Unity。

3 系統(tǒng)模塊介紹

3.1 虛擬現(xiàn)實

虛擬現(xiàn)實（VR）是以計算機技術(shù)為核心，集逼真的視、聽、觸覺為一體化的虛擬環(huán)境模擬系統(tǒng)。 用戶借助VR 設(shè)備（如特制的頭盔、手套、手柄等）， 以自然方式與虛擬環(huán)境中的客體進行交互， 從而產(chǎn)生身臨其境的體驗［10］， 文中VR 設(shè)備的組成有：1 個頭戴式顯示器和2 個控制器。 控制器是完全無線的，頭盔顯示器通過USB 和HDMI 線連接到電腦。 每個控制器都有一個觸摸板、觸發(fā)器和2 個用戶輸入按鈕。 VR 設(shè)備支持多個游戲和物理引擎， 通過一個名為SteamVR 的SDK 連接到Unity， 且VR 上顯示的內(nèi)容是在Unity 上開發(fā)的。 虛擬現(xiàn)實界面和機架系統(tǒng)也提供了直觀的方法用于將用戶的動作映射到正在控制的機器人［11］。 VR 將模擬世界與物理世界相結(jié)合， 在機器人仿真領(lǐng)域做出了貢獻［12］。

3.2 機器人操作系統(tǒng)

機器人操作系統(tǒng)（ROS）是一種用于機器人的次級操作系統(tǒng)， 包含底層驅(qū)動程序管理、硬件抽象描述、共用功能的執(zhí)行、程序發(fā)行包管理等功能， 其首要設(shè)計目標是在機器人研發(fā)領(lǐng)域提高代碼復(fù)用率。此外， ROS 利用簡單、語言無關(guān)的接口定義語言去描述模塊之間的消息傳遞， 這樣就可支持C／C＋＋、Python、Java 等多種編程語言以實現(xiàn)跨平臺、跨語言的交互。 ROS 將執(zhí)行不同功能的程序進程（稱為節(jié)點）連接起來。 節(jié)點通過在本地TCP 網(wǎng)絡(luò)（稱為ROS 網(wǎng)絡(luò)）上的通道或主題流數(shù)據(jù)進行通信。 節(jié)點創(chuàng)建publisher 對象來在網(wǎng)絡(luò)上發(fā)布話題上的數(shù)據(jù)，或者創(chuàng)建subscriber 對象來訂閱話題。

3.3 Unity

Unity 是一款可視化開發(fā)3D 應(yīng)用工具， 采用C＃編程， 易于開發(fā)， 具有強大的開發(fā)者社區(qū)支持和第三方開發(fā)插件， 兼容所有平臺［13］， Unity 可以用于3D 環(huán)境并允許傳感器建模［14］。 由于內(nèi)置物理引擎， Unity 系統(tǒng)對接觸動力學(xué)以及材料模擬均有相關(guān)技術(shù)支持。 此外， Unity 引擎提供多個著色器和圖形效果來增強3D 虛擬現(xiàn)實的真實性和真實性環(huán)境［15］。

一個開放的 Unity 環(huán)境被稱為場景。GameObject 是場景中的基本單位， 本文所提出的虛擬無人車模型就是由許多個GameObject 組成。 附在每個GameObject 上的是組件， 有數(shù)十種類型的組件， 組件上掛載各種腳本。 腳本是一個小的C＃程序， 在每個渲染幀中執(zhí)行。 Unity 作為本文所提系統(tǒng)的模型和通訊核心的功能就是通過這些C＃腳本實現(xiàn)的。

3.4 無人車

本次實驗使用的無人車是DashGo D1， 在此移動平臺上的硬件有工控機、DashGo D1 移動底盤、Slam 導(dǎo)航模塊、PS1000C 內(nèi)置的IMU 模塊、高精度G4 激光雷達和600 線增量型光電編碼器等。 底盤采用先進的動力平臺懸掛裝置， 有著優(yōu)異的地面適應(yīng)性能。 無人車本體如圖10 所示。

4 系統(tǒng)搭建與實驗過程

4.1 系統(tǒng)搭建及實驗布置

軟件定義無人車系統(tǒng)主要由VR 系統(tǒng)、 Unity 引擎、ROS、 動作捕捉系統(tǒng)、 實體無人車、五部分分組成。 其中，VR 系統(tǒng)主要搭建VR 視角以及用戶的互動操作。 Unity 引擎主要起到連接各系統(tǒng)、以及形成虛擬無人車和無人車的運行環(huán)境。 ROS 用來完成無人車數(shù)據(jù)可視化和提供軟件定義接口完成建圖導(dǎo)航功能調(diào)用。

首先， 3Dmarks 對無人車進行建模， 進行貼圖與渲染形成虛擬無人車模型。 然后，用連接VR 接收器， 布置場地基站， 配置好Unity 上的steamVR（作為SDK）， 連接VR 設(shè)備（頭盔和手柄）到Unity上。 再給小車添加材質(zhì)， 添加模擬地形， 添加攝像機， 添加碰撞體， 添加碰撞事件與監(jiān)控。 通過編寫C＃腳本設(shè)置對實體無人車的、如軟件定義控制接口。 添加物理性質(zhì)的剛體（Rigidbody）和建立物理模型， 實現(xiàn)無人車運行的虛擬仿真。 仿真結(jié)果如圖11 所示。

圖11 無人車主體以及附屬的硬件建模Fig. 11 Hardware modeling of unmanned vehicle

在Unity 中用OptiTrack＿Unity＿Plugin 通訊協(xié)議與動作捕捉系統(tǒng)進行通訊， 接受動作捕捉系統(tǒng)傳來的流捕捉數(shù)據(jù)與剛體模型， 并將數(shù)據(jù)與虛擬無人車進行連接， 以保證虛擬無人車能反映實體無人車和障礙物的位姿。 與VR 進行連接， 編譯用戶交互邏輯和VR 環(huán)境， 保證虛擬圖像能顯示在VR 頭盔上。編寫python 腳本（附帶Arduino 用語的功能包）與實體無人車通訊， 借助Arduino 開發(fā)板獲取小車控制信息。

關(guān)于動作捕捉系統(tǒng)，本研究給無人車與障礙物貼上標志物， 對環(huán)境多次校準并用XML 腳本來描述標志點位置與相對位置信息［9］。 將標志點信息合成剛體Rigid Body 跟蹤模型， 如圖12 所示。 然后， 將跟蹤數(shù)據(jù)保存到文件中（TAK 文件）， 捕獲標志點時， 所有2D 數(shù)據(jù)、實時重建的3D 數(shù)據(jù)和求解的數(shù)據(jù)都會保存到文件中。 最后， 為傳輸數(shù)據(jù)流選擇網(wǎng)絡(luò)適配器（接口、IP 地址）， 與Unity 建立連接，并將TAK 文件賦予虛擬無人車模型。

圖12 動作捕捉系統(tǒng)中的剛體模型Fig. 12 Rigid body model in motion capture system

關(guān)于ROS， 在無人車的開發(fā)板上部署ROS， 并導(dǎo)入一些常用模塊（收發(fā)通信、建模、 坐標變換、操作界面等）， 編譯無人車各部件坐標變換邏輯代碼，用XML 編寫并集成抽象無人車模型（URDF）各部分以及連接關(guān)系。 將抽象過的各硬件數(shù)據(jù)情況部署到RVIZ 上。 在ROS 上布置所需要用到的建圖和自主導(dǎo)航算法。

4.2 導(dǎo)航實驗

本實驗的重點應(yīng)用場景在辦公室， 主要由無人車和一些障礙物組成。 然后， 用戶需要在地圖上給定一個目的地和一個出發(fā)點（一般是無人車當(dāng)前所在位置）。 接著無人車按照既定的算法到達目的地， 中途無人車可能會碰撞上障礙物， 如果無人車碰撞上障礙物， 用戶就可以使用VR 去控制無人車脫離障礙物。

在本文的實驗中， 使用了自己配置的無人車。用戶使用VR 設(shè)備于控制小車或者使用點擊設(shè)置目的地的方式與導(dǎo)航系統(tǒng)進行交互。 VR 可以對無人車的運動狀況進行實時數(shù)字孿生虛模擬［8］， 再將模擬好的環(huán)境和無人車模型顯示在VR 頭盔上。 在無人車運行的過程中也可以通過觀測ROS 中的RVIZ面板來了解小車的實時的狀態(tài)， 而不用通過專業(yè)的儀器運算以及實時監(jiān)測。

圖13 為導(dǎo)航任務(wù)開始時的導(dǎo)航圖， 無人車導(dǎo)航系統(tǒng)已經(jīng)部署了基于A?算法的全局規(guī)劃和基于DWA 算法的局部規(guī)劃。 從中可以看出導(dǎo)航系統(tǒng)對從起點到終點做出的全局規(guī)劃線路， 并使用局部規(guī)劃對第一個地形進行繞行。 圖14 為導(dǎo)航一段時間之后的觀測圖， 可以看出局部路徑規(guī)劃已經(jīng)在起作用， 無人車已經(jīng)順利通過前段地形，并且圖14 中無人車尾部的AMCL 粒子比較集中， 說明此時位姿信息比較準確且定位系統(tǒng)運行穩(wěn)定。

圖13 導(dǎo)航任務(wù)開始Fig. 13 Navigation task start

圖14 導(dǎo)航進行中Fig. 14 Navigation in progress

在無人移動到圖15 顯示的位置之前， 為了測試導(dǎo)航中的局部路徑算法是否能檢測到障礙物位置變化， 將箱子的位置向左移動。 圖13 顯示在SLAM所建的地圖中， 原先箱子擺放的位置靠墻。 因為箱子左側(cè)位置在全局規(guī)劃時默認是可以通過的， 所以按照全局路徑規(guī)劃默認從箱子的左側(cè)位置繞行。 圖15 顯示無人車在箱子附近并未按照原有路線移動，因為無人車在DWA 局部路徑規(guī)劃時檢測到左前方有障礙物且原先的障礙物不在全局路徑規(guī)劃前的位置。 可以通過觀察圖15 淺藍色框了解移動過的障礙物的大體位置， 但是導(dǎo)航系統(tǒng)對障礙物的反映非常不明顯， 無法判斷無人車在越過障礙物時的具體情況。 隨后DWA 局部路徑導(dǎo)航在綜合分析環(huán)境和無人車位姿的情況下， 引導(dǎo)無人車向右邊繞過障礙物。 圖16 顯示無人車按照新規(guī)劃的路線繞過了障礙物。

圖15 導(dǎo)航過程1Fig. 15 Navigation process 1

圖16 導(dǎo)航過程2Fig. 16 Navigation process 2

對比導(dǎo)航系統(tǒng)畫面， 參見圖17。 由圖17 可看到， 在VR 視角下， 由于動作捕捉系統(tǒng)對箱子位姿的捕捉， 可以直觀地看到箱子已經(jīng)移動。 繼續(xù)觀察VR 畫面， 參見圖18。 由圖18 可以觀察到， 局部路徑規(guī)劃的過程中無人車更改相關(guān)路線并向箱子右側(cè)避障， 在觀察到無人車成功避障之后， 因為無人車并未出現(xiàn)異常情況， 故不需要用VR 手柄做出控制操作。

圖17 VR 圖1Fig. 17 VR figure 1

圖18 VR 圖2Fig. 18 VR figure 2

在通過DWA 局部路徑規(guī)劃成功繞過箱子障礙物之后， 仿真結(jié)果如圖19 所示。 在圖19 中， 可以從VR 中觀察到無人車正在逐漸靠近終點。 通過導(dǎo)航系統(tǒng)畫面和本文系統(tǒng)框架中VR 畫面的對比， 可以發(fā)現(xiàn)本文系統(tǒng)框架針對障礙物位置更改的即時反映效果和對無人車避障過程的直觀性要優(yōu)于僅使用導(dǎo)航系統(tǒng)畫面的無人車系統(tǒng)。 圖20 為導(dǎo)航過程實物圖。

圖19 接近終點Fig. 19 Near the end

圖20 導(dǎo)航過程實物圖Fig. 20 Physical map of navigation process

4.3 碰撞處理實驗

無人車碰撞問題是一種在無人車運行過程中的常見問題。 當(dāng)無人車沒有出現(xiàn)在操作人員視野中，發(fā)生碰撞概率較大， 即使在無人車上安裝攝像頭，由于攝像頭視角的問題， 解決碰撞問題難度也較大。 本文系統(tǒng)通過動作捕捉系統(tǒng)對無人車和障礙物位姿信息的捕捉， 能使用戶更好了解碰撞情況和解決碰撞問題。

在實際場景中判斷物體之間是否碰撞十分重要， 所以在虛擬場景中模擬準確的碰撞過程不僅僅需要依靠動作捕捉系統(tǒng)的高速攝像頭所獲取的數(shù)據(jù)， 還需要在Unity 中添加碰撞檢測。 在Unity 的虛擬無人車里加入的碰撞組件和物理剛體， 能對無人車和障礙物碰撞時的物理過程進行模擬。 結(jié)合動作捕捉系統(tǒng)的標志點信息組成的剛體位姿， 能讓VR中得出與真實碰撞情況一致的碰撞結(jié)果， 以便用戶在VR 里就能觀測到實際無人車發(fā)生碰撞后的具體情況， 然后利用VR 控制無人車離開碰撞區(qū)域。 這樣的設(shè)計改善了無人車碰撞后直接停滯和因使用者不了解具體碰撞情況而無法進行后續(xù)操作的問題。

當(dāng)無人車與障礙物發(fā)生碰撞時，碰撞效果如圖21 所示。 由圖21 可看到，導(dǎo)航界面對碰撞后的效果顯示并不明顯。 通過獲取動作捕捉系統(tǒng)的位姿觀測信息， VR 能很好地反映實際的碰撞情況， 下面以無人車碰撞箱子情況為例， 來觀察VR 視角里的碰撞與實際碰撞效果：從圖21～圖23 的對比可以看到相較于普通導(dǎo)航顯示界面， 軟件定義無人車系統(tǒng)的VR 畫面能更直觀地向用戶展示碰撞情況， 且可發(fā)現(xiàn)碰撞情況的表現(xiàn)更加準確。 在此基礎(chǔ)上又研究得到， 圖24、圖25 為動作捕捉系統(tǒng)中的無人車和障礙物的位姿變化。 動作捕捉系統(tǒng)中位姿的變化驗證了VR 中無人車與障礙物相對位置關(guān)系的準確性。進一步得到，圖26、圖27 為實際碰撞情況。

圖21 碰撞效果圖1Fig. 21 Impact effect drawing 1

圖23 碰撞效果圖3Fig. 23 Impact effect drawing 3

圖24 動作捕捉圖1Fig. 24 Motion capture figure 1

圖25 動作捕捉圖2Fig. 25 Motion capture figure 2

圖26 實際碰撞情況1Fig. 26 Actual collision 1

圖27 實際碰撞情況2Fig. 27 Actual collision 2

無人車移動出碰撞區(qū)域如圖28 所示。 由圖28可看到， 在發(fā)生碰撞后， 由于在VR 中能觀察到具體碰撞情況， 所以可通過VR 手柄控制的方式， 將無人車安全移動出發(fā)生碰撞的區(qū)域， 從而避免后續(xù)問題。

圖28 無人車移動出碰撞區(qū)域Fig. 28 Unmanned vehicle moves out of the collision area

5 結(jié)束語

為了驗證該系統(tǒng)能否滿足用戶的簡單要求， 并測試系統(tǒng)對非專業(yè)用戶的友好性。 研究時邀請了非相關(guān)技術(shù)的10 名學(xué)生對基于軟件定義的無人車系統(tǒng)進行測試。 通過與10 名學(xué)生的共同測試與交流表明， 該系統(tǒng)功能模塊完整， 并且無人車能夠按照用戶的遠程的控制指令實時運動， 無停頓感， 系統(tǒng)運行流暢， 具有較強的交互性能， 導(dǎo)航功能順暢。測試結(jié)果通過對軟件定義的核心MAPE－K 框架來評價系統(tǒng)的完成度。 系統(tǒng)測試結(jié)果見表1。

表1 系統(tǒng)測試結(jié)果Tab. 1 Test results of the system

本文設(shè)計了一個軟件定義的框架。 該框架涉及2 個關(guān)鍵方面。 一個是軟件定義的軟件服務(wù)和硬件設(shè)備， 另一個是基于MAPE－K 的控制器。 前者用于對無人系統(tǒng)的軟硬件資源進行抽象并提供控制接口， 后者負責(zé)對資源進行管理， 并對完成給定任務(wù)的工作流程進行調(diào)度。 本系統(tǒng)對原有的自主導(dǎo)航系統(tǒng)來說， 添加了監(jiān)視器也就是動作捕捉系統(tǒng)， 針對性地提高了監(jiān)視器的精準度和導(dǎo)航過程的可驗證性， 此外還通過VR 的方式增強系統(tǒng)對用戶的交互感和使用體驗， 降低了新用戶的上手難度。 此系統(tǒng)也有一定的不足， 首先是小車模型過于單一的問題， 導(dǎo)致此系統(tǒng)軟件定義資源虛擬化的時候并沒有許多可供操作的內(nèi)容， 系統(tǒng)沒有帶有3D 全景攝像頭和圖像識別的內(nèi)容， 用戶交互界面比較簡單。 研究按照提出的軟件定義體系結(jié)構(gòu)為原型設(shè)計了一個無人車以及系統(tǒng)， 并通過一個應(yīng)用場景驗證了其可行性。 在將來， 將通過考慮其有效性， 以及無人系統(tǒng)的可靠性和可擴展性來做深入研究，則已成為下一階段的工作。