一種隧道機器人行走遠程控制系統(tǒng)

鄧維迪，朱宏輝

（武漢理工大學 物流工程學院，武漢430063）

自改革開放以來，我國不斷加大了對公路、鐵路隧道建設的投資。但由于對隧道施工環(huán)境的監(jiān)控不足，地質條件發(fā)生變化未能及時作出反應從而導致嚴重地質災害，造成人員傷亡的事故時有發(fā)生。因此超前地質預報工作成為隧道施工過程中必不可少的一個環(huán)節(jié)。在隧道工程中典型的建圖方法有基于魯棒的掃描匹配和3D 導航技巧的HectorSLAM、基于粒子濾波的Gmapping 算法、基于圖論的KartoSLAM以及基于圖優(yōu)化的LagoSLAM 等[1]。HectorSLAM 是利用高更新速率和現(xiàn)代激光雷達距離測量的低噪聲來對機器人的移動進行實時的估計。這種方法沒有使用里程計的數(shù)據(jù)，使得這種方法可以在無人機或者不平地面的機器人中使用。但另一方面，當只有低速激光掃描時或者里程計數(shù)據(jù)準確的時候，HectorSLAM 可能會出現(xiàn)問題[2]；Gmapping 是世界范圍內最為廣泛使用的機器人建圖算法。作為一種粒子濾波算法，Gmapping 通常需要數(shù)量多的粒子才能獲取良好的結果，使得算法需要較高的計算復雜度。同時由于粒子耗盡，即粒子濾波器重新取樣時，粒子的權重被大大減少，會有極小的幾率得不出正確的結果[3]；KartoSLAM 是由SRI International Karto Robotics 開發(fā)的一種基于圖論的建圖算法。這種算法使用了高度優(yōu)化的、非迭代的Cholesky 矩陣分解來解決計算中的線性稀疏矩陣方程?；趫D論的SLAM 建圖算法用圖來表示地圖，具體來說就是每個節(jié)點代表了機器人在移動軌跡上的一個位姿，每個節(jié)點通過代表位姿變化的邊緣進行連接。建圖的過程就是在圖里面添加新的節(jié)點，節(jié)點的位姿受到位姿變化的限制?；趫D論的建圖算法在進行建圖時的特征匹配需要的內存較多，但在保存建好的地圖時需要的內存更少；LagoSLAM 也是另一種基于圖論的建圖算法，不過這種算法是求機器人位姿的非線性非凸函數(shù)的最小代價，在每次迭代計算中，求出最初問題的局部近似解，以此更新圖的性質，直到達到代價函數(shù)的極小值。但是這種優(yōu)化算法只有在一個較好的初始的預估值才能收斂，粒子濾波算法的求解過程如圖1 所示。

圖1 粒子濾波算法演示Fig.1 Demonstration of particle filter algorithm

本文根據(jù)隧道施工安全預警要求，并結合自動控制與物聯(lián)網(wǎng)技術，設計出一種機器人行走遠程控制系統(tǒng)。該系統(tǒng)通過云服務器作為連接用戶和機器人的橋梁，用戶使用瀏覽器，在網(wǎng)上發(fā)出控制指令，云服務器將這些指令發(fā)送到機器人上位機上，通過機器人底盤伺服電機實現(xiàn)機器人不同位姿的精確控制，上位機通過USB 獲取里程計的采集數(shù)據(jù)，將數(shù)據(jù)通過mesh 網(wǎng)絡上傳至遠程服務器進行數(shù)據(jù)分析，將隧道的環(huán)境和機器人的位姿狀態(tài)實時展示給用戶。在實際施工現(xiàn)場對系統(tǒng)進行一系列的測試，驗證了系統(tǒng)的穩(wěn)定性和可運行性。通過網(wǎng)頁可以使幾乎所有的設備作為探測數(shù)據(jù)的查詢終端，可以顯示出機器人的行走位置，從而有效地提高隧道施工監(jiān)測效果。

1 系統(tǒng)總體結構及特點

該探水自動檢測系統(tǒng)是在隧道安全預警小車需求的基礎上提出的。系統(tǒng)要求通過管理員遠程控制小車的移動，并可以實時監(jiān)視小車周圍障礙物的情況。車載傳感器檢測數(shù)據(jù)，并將數(shù)據(jù)傳輸至遠程服務端，同時根據(jù)測量數(shù)據(jù)自動分析出地圖并展示給管理員。系統(tǒng)總體結構主要由云服務器、mesh 路由器、上位機、STM32 單片機、左直流電機、右直流電機、激光雷達以及里程計組成。由于在隧道施工環(huán)境中需要考慮防水需求，故該系統(tǒng)將上位機和STM32 單片機搭載在小車內部，以提高防水等級。直流電機帶動履帶轉動以實現(xiàn)底盤的差動控制，使機器人能靈活控制。考慮到隧道中傳統(tǒng)的4G 和WLAN 有效傳輸距離很短，在隧道施工現(xiàn)場部署了mesh 網(wǎng)絡，保證機器人能有穩(wěn)定的互聯(lián)網(wǎng)接入?？紤]到小車上位機的性能和攜帶電池的容量有限，小車本體只負責從傳感器讀取數(shù)據(jù)，所有的建圖算法都在云服務器上運行?？紤]到管理的方便性以及操作的簡便性，使用網(wǎng)頁通過云服務器連接機器人運動控制裝置以發(fā)送控制指令。同時通過網(wǎng)頁對數(shù)據(jù)分析結果進行展示，小車結構如圖2 所示，底盤位姿控制部分放大圖如圖3 所示。

圖2 小車整體結構Fig.2 Overall structure of trolley

圖3 小車底盤位姿控制部分放大圖Fig.3 Enlarged view of position and attitude control part of trolley chassis

2 系統(tǒng)總體架構

網(wǎng)頁終端通過wifi 或4G 等聯(lián)網(wǎng)方式連接遠程服務器，發(fā)出各種對機器人的控制指令，云服務器上部署了kafka 消息隊列，發(fā)布機器人命令的主題，訂閱機器人狀態(tài)的主題； 機器人上也部署了kafka消息隊列，訂閱了機器人命令的主題，發(fā)布機器人狀態(tài)的主題。每次機器人收到訂閱的消息后，根據(jù)消息的具體命令執(zhí)行對應的操作，收到移動指令后，上位機通過串口對STM32 控制機器人底盤的運動，使機器人前進后退，左右旋轉到達指定的位姿。同時，機器人還讀取里程計的數(shù)據(jù)，通過消息隊列發(fā)送到服務器上，服務器收到機器人發(fā)送的數(shù)據(jù)后，對這些數(shù)據(jù)進行分析后，通過網(wǎng)頁直觀的展示可視化結果。由于服務器有公網(wǎng)ip，各種設備只要能上網(wǎng)，同時能夠通過驗證就可訪問serverless 的nginx 服務器，通過網(wǎng)絡將探測結果顯示到瀏覽器上，系統(tǒng)總體架構如圖4 所示。

圖4 系統(tǒng)總體架構圖Fig.4 System overall architecture diagram

3 機器人底盤位姿控制裝置

系統(tǒng)控制芯片采用STM32F407，通過+5 V 電源對系統(tǒng)進行供電，系統(tǒng)通過USB 串口讀取里程計數(shù)據(jù)，通過GPIO 控制底盤伺服電機的運動并且和上位機通信，接收上位機接收到的云服務器發(fā)送的控制指令并返回機器人的位姿狀態(tài)，底盤位姿控制裝置的硬件系統(tǒng)框圖如圖5 所示。

圖5 硬件系統(tǒng)框圖Fig.5 Hardware system block diagram

3.1 USB 串口控制模塊

USB 串口主要是對里程計和激光雷達數(shù)據(jù)進行讀取。里程計選擇型號為HiPNUC 的MPU9250，運行電壓為5 V； 輸出速率是100 Hz； 測量范圍±2000°/s；非線形度±0.1%；噪聲密度0.08°/s·Hz-1；采樣率1000 Hz。激光雷達選擇型號為思嵐的RPLIDAR A2，高度41 mm；直徑76 mm；重量190 g；測距范圍0.15～18 m；掃描角度為360°；角度分辨率為0.45°。采用115200 波特率的串口輸出，其控制方式為USB 異步串口通信。選擇波特率為115200，無校驗位[4]。里程計和激光雷達接收數(shù)據(jù)格式相同，如圖6所示，其中A 為報頭；B 為保留位；C 為指令包的長度；D 為發(fā)出的命令；E 為命令的參數(shù)；F 為CRC16校驗位。

圖6 里程計和激光雷達接收數(shù)據(jù)格式Fig.6 Odometer and lidar receiving data format

3.2 伺服電機控制模塊

推桿控制模塊主要通過STM32 的2 個GPIO引腳分別控制2 個伺服電機運動。電機的最大轉速為2500 r/min，供電電源為直流24 V。選擇PA10，PA11，PC10，PC11 引腳和GND 連接直流電機正反轉模塊，DC POWER 端連接24 V 電源，電機接線如圖7 所示。

圖7 電機連接圖Fig.7 Motor connection diagram

4 上位機通信模塊

上位機通信模塊主要作用是接收上位機接收到的云服務器發(fā)送的控制指令并返回機器人的位姿狀態(tài)。上位機上面安裝了wifi 模塊，可以連接上隧道中部署的mesh 網(wǎng)絡，連接上互聯(lián)網(wǎng)，運行kafka消息隊列和云服務器保持可靠的通信。和部署在隧道環(huán)境的mesh 路由器進行通信，連接上互聯(lián)網(wǎng)，向服務器發(fā)送數(shù)據(jù)同時接收服務器發(fā)送的命令。上位機運行的是Ubuntu 18.04 LTS 系統(tǒng)，通過GPIO 和機器人底盤位姿控制裝置通信，來控制機器人的位姿并讀取狀態(tài)信息反饋到云服務器上。

4.1 GPIO 通信模塊

GPIO 通信模塊主要作用是和STM32 進行通信，控制機器人底盤的位姿并將數(shù)據(jù)發(fā)送至云服務器進行處理。使用的工控機裝有8 路GPIO，選擇其中的引腳1、 引腳2 和STM32 上的GPIO 引腳進行連接。將STM32 的GPIO 串口設置為主機模式，并將波特率設置為9600，1 位停止位，無校驗位，STM32 引腳接線說明見表1，STM32 引腳接線電路如圖8 所示。

表1 STM32 引腳接線說明Tab.1 STM32 pin wiring instructions

圖8 STM32 引腳接線電路圖Fig.8 STM32 circuit diagram of pin wiring

4.2 kafka 消息隊列模塊

kafka 消息隊列的作用是保證數(shù)據(jù)不被丟失的正常發(fā)送。在隧道中雖然部署了mesh 無線網(wǎng)絡，但是在一些地方信號不好。如果使用傳統(tǒng)的tcp 連接，在信號不好的時候連接會斷開，造成數(shù)據(jù)丟失。使用kafka 消息隊列，數(shù)據(jù)在沒有網(wǎng)的時候會在本地緩存，在有網(wǎng)的時候自動發(fā)送到遠程服務器。同時kafka 的內存占用低，性能高，編程簡單，適合在電池和性能有限的移動機器人中使用。

云服務器和上位機發(fā)布和接收的kafka 主題分別是server_command 和client_response，消息內容為json 定義，如表2 和表3 所示。

表2 發(fā)布消息格式說明Tab.2 Post message format description

表3 接收消息格式說明Tab.3 Receiving message format description

5 網(wǎng)頁控制模塊

網(wǎng)頁的主要作用是完成用戶身份認證；將用戶的輸入轉化為控制命令發(fā)送到機器人；監(jiān)視機器人底盤的運行狀態(tài)以及將結果展示給用戶。當用戶打開網(wǎng)頁后，開始進行身份驗證，如驗證成功，則模塊進入機器人可視化界面，通過使用鍵盤控制機器人的移動并在界面上追蹤機器人的位置。用戶點擊菜單欄中的下拉框查看機器人，選擇所需的機器人進行連接，之后網(wǎng)頁將下拉框收回，進入全屏模式，顯示機器人控制界面，點擊“開始”控制按鈕后，使用鍵盤上的方向鍵便可按指定方向進行運動，網(wǎng)頁界面實時顯示運動位置。不需要手動控制后，可通過點擊停止控制按鈕，機器人將不受用戶的控制。

5.1 用戶身份驗證

用戶身份認證主要通過一個有3 個input 的form 控件實現(xiàn)，3 個input 的類型分別是text，password 和submit，分別對應了用戶名、密碼和提交按鈕。當用戶點擊submit 類型的input 時，獲取text 和password 的input 的身份以及密碼信息，并進行驗證。當驗證通過時，證明該用戶是設備操作人員，同時切換到機器人選擇界面，用戶身份認證界面如圖9 所示。

圖9 用戶身份認證界面Fig.9 User authentication interface

5.2 網(wǎng)頁和服務器通訊

用戶通過身份驗證后，打開新的Dom 元素。在window.onload（）函數(shù)中初始化界面，顯示機器人選擇界面，用戶可以選擇機器人或后退。如選擇后退則程序結束，如選擇某個機器人后，程序繼續(xù)運行，同時程序將向遠程服務器打開一個websocket 鏈接，websocket 注冊onopen，onmessage，onclose 三個回調函數(shù)[5]。通過onopen（）方法向服務器發(fā)送用戶選擇的具體機器人標識號，服務器就會在這條websocket 鏈接上發(fā)送選擇機器人的相關信息。onmessage（）方法則是用來處理服務器發(fā)過來的數(shù)據(jù)，這些數(shù)據(jù)將由另外的函數(shù)處理并繪制在網(wǎng)頁的canvas元素上。當用戶關閉瀏覽器頁面或者點擊“停止”按鈕時，onclose（）負責斷開連接前做出一些清理。同時還會使用setInterval（）函數(shù)使websocket 鏈接定時發(fā)送心跳包，保持客戶端的存活。

當點擊“開始”控制后，用戶的鍵盤操作將可以直接控制機器人的移動，為此還需要使用window.onkeydown（）監(jiān)聽用戶的鍵盤輸入，上下左右4 個方向鍵對應著ArrowUp，ArrowDown，ArrowLeft，ArrowRight。當用戶按下按鍵時，回調函數(shù)會根據(jù)發(fā)生的事件中key 屬性，判斷用戶的點擊按鍵，從而使用websocket的send（）方法向服務器發(fā)送對應的數(shù)據(jù)。當websocket 接收到服務器發(fā)送的消息后，需要在界面上顯示給用戶。使用canvas 的fillRect（），beginPath（），moveTo（），lineTo（），fill（）方法繪制機器人的位姿。網(wǎng)頁websocket 連接流程如圖10 所示。

圖10 用戶瀏覽器和云服務器通訊連接流程Fig.10 User browser and cloud server communication connection flow chart

5.3 網(wǎng)頁可視化界面

可視化界面主要實時顯示機器人的位姿狀態(tài)。主要使用了canvas 進行圖像的動態(tài)繪制、使用web socket 從服務器獲取機器人的實時位姿信息，由一個canvas 元素組成。在遠程服務器搭建Nginx 服務器，在網(wǎng)頁端通過websocket 標準庫對服務器進行Http upgrade 請求，獲取實時消息并顯示在canvas 上[6]。

6 系統(tǒng)驗證與測試

系統(tǒng)軟硬件模塊設計完成后，需要對系統(tǒng)機械結構、硬件運行穩(wěn)定性和網(wǎng)頁功能進行測試。硬件測試主要測試底盤位姿控制裝置能否正常運行，網(wǎng)頁測試主要包括服務器與機器人上位機的通信以及機器人位姿狀態(tài)顯示功能。在貴州桐梓隧道右洞中進行系統(tǒng)測試，桐梓隧道測試現(xiàn)場如圖11 所示。打開網(wǎng)頁，并選擇該機器人，點擊開始控制按鈕，此時遠程控制機器人底盤運動，并將機器人位姿狀態(tài)發(fā)送到手機上，網(wǎng)頁端實時顯示界面如圖12 所示。

圖11 桐梓隧道測試現(xiàn)場Fig.11 Tongzi tunnel test site

圖12 網(wǎng)頁機器人狀態(tài)界面Fig.12 Web robot status interface

當不需要手動控制后，可以通過點擊菜單下的“停止”控制按鈕，結束對機器人的控制，機器人實時行走地圖如圖13 所示。

圖13 機器人實時行走地圖Fig.13 Real-time robot walking map

7 結語

本文將物聯(lián)網(wǎng)技術和云服務相結合，通過分析隧道預警小車的具體需求，設計出一種機器人行走遠程控制系統(tǒng)，通過對軟硬件模塊的設計，實現(xiàn)了隧道環(huán)境中機器人位姿數(shù)據(jù)的自動采集以及傳輸，并通過云服務器分析傳感器數(shù)據(jù)，得出可視化結果，工程技術人員可通過網(wǎng)頁查看機器人目前位姿，并進行手動控制。從而能夠減少隧道施工過程中工人數(shù)量，有效地提高隧道監(jiān)測預警能力，避免發(fā)生意外事故。