嵌入式多旋翼機載車輛跟隨系統(tǒng)研究與設(shè)計

王嘯天，于 洋，趙亞威，劉冠楠

(沈陽理工大學(xué) 自動化與電氣工程學(xué)院，沈陽110159)

多旋翼因其控制簡單、成本低、易維護等優(yōu)點廣泛應(yīng)用于各行各業(yè)，但由于其負(fù)載能力有限，單架多旋翼的應(yīng)用通常與視覺傳感器相關(guān)，如交通狀況監(jiān)測、輸電線路巡檢等[1]；在多旋翼編隊系統(tǒng)中，需要利用視覺信息實現(xiàn)避障與定位[2]。針對多旋翼的實時目標(biāo)檢測與識別問題，研究提高識別效率的硬件解決方案具有重要應(yīng)用價值。

我國雖然在多旋翼無人機的研究方面起步較晚，但發(fā)展迅速。大疆在2012年發(fā)布小精靈，該四旋翼控制簡單并具備拍攝功能，使多旋翼在國內(nèi)普及[3]。2015年鮮斌等在四旋翼上搭載了英特爾ATOM計算機，利用兩幀圖像特征點的差值實現(xiàn)對物體的運動估計，根據(jù)光流法實現(xiàn)四旋翼在無GPS條件下的定位，但受限于ATOM計算機的性能限制，所用的視覺模塊分辨率僅為480P，因此定位誤差較大[4]。文獻[5-6]在四旋翼上搭載網(wǎng)絡(luò)攝像機采集地面信息，并提出相應(yīng)的管理系統(tǒng)與目標(biāo)檢測算法，實現(xiàn)地面目標(biāo)檢測。邱鵬瑞等將飛行控制器和攝像機采集的數(shù)據(jù)傳輸至地面站，結(jié)合目標(biāo)檢測算法定位參考物體，計算多旋翼的位置參數(shù)信息[7]，雖然精度較高，但完全依賴于無線通信的鏈路質(zhì)量。姚俊等使用基于賽揚的單板計算機進行障礙物檢測，但該板尺寸較大，且與鮮斌教授所用的計算機性能相近[8]。

為保證目標(biāo)檢測精度，同時提高系統(tǒng)的實時性，本文對多旋翼在目標(biāo)車輛跟隨應(yīng)用中的處理流程進行分析；針對其問題，利用嵌入式計算機設(shè)計多旋翼機載目標(biāo)檢測系統(tǒng)，并結(jié)合物理模型給出選用標(biāo)準(zhǔn)，同時討論該系統(tǒng)對多旋翼續(xù)航的影響。

1 目標(biāo)車輛跟隨與問題分析

1.1 車輛跟隨系統(tǒng)流程及原理

通常多旋翼對目標(biāo)車輛跟隨需要進行圖像數(shù)據(jù)采集、目標(biāo)車輛檢測、飛行坐標(biāo)計算等處理，具體流程如圖1所示。

圖1 目標(biāo)車輛跟隨處理流程圖

具體原理如圖2所示。

圖2 目標(biāo)車輛跟隨示意圖

根據(jù)GPS與氣壓計等傳感器可估計多旋翼當(dāng)前位置為(X，Y，Z)，其中Z=hair，并且通過實際測量獲得可跟隨車輛的高度hcar。當(dāng)滿足Dcam=hair-hcar時，多旋翼在車輛正上方，此時不需要跟隨；若不滿足該條件，則需要計算飛行坐標(biāo)。在水平跟隨時，使用勾股定理能夠求得

(1)

最終得到飛行坐標(biāo)為(X+Dexp，Y，Z)。

1.2 問題分析

據(jù)車輛跟隨系統(tǒng)流程分析，系統(tǒng)運行時的通信流程如圖3所示。首先，多旋翼實時上報采集的圖像信息至地面端；然后，地面端發(fā)送位置與姿態(tài)傳感器數(shù)據(jù)采集指令，并接收相應(yīng)數(shù)據(jù)；最后，計算完成后地面端發(fā)送控制指令。在上述過程中，多旋翼與地面端使用無線鏈路進行交互。

圖3 傳統(tǒng)的車輛跟隨系統(tǒng)通信流程圖

由于原始圖像數(shù)據(jù)遠(yuǎn)大于1500字節(jié)，所以傳輸時需要壓縮并進行分包處理；為減少空中交互次數(shù)，通常采用無握手機制的UDP傳輸協(xié)議，但該協(xié)議缺點為接收端無法檢測丟包。另外無線圖像傳輸?shù)难訒r通常高于50ms，而當(dāng)前目標(biāo)檢測算法的單幀圖像檢測時間已低于35ms[9]。因此，導(dǎo)致車輛跟隨系統(tǒng)實時性較低的主要影響因素是無線傳輸?shù)母哐訒r。

2 系統(tǒng)設(shè)計

2.1 系統(tǒng)硬件設(shè)計

多旋翼的機載處理系統(tǒng)由兩部分組成：底層控制端、機載處理端。底層控制端對多旋翼飛行進行控制，采集并存儲傳感器測量的位置與姿態(tài)，接收來自數(shù)據(jù)處理模塊的控制和讀取指令。機載處理端讀取視覺模塊與底層控制端的數(shù)據(jù)，進行目標(biāo)檢測與跟隨控制。底層控制端和機載處理端使用通用串行接口(UART)進行數(shù)據(jù)交互。地面端只監(jiān)控多旋翼的運行狀態(tài)，并在機載處理系統(tǒng)工作異常時直接控制降落，提高系統(tǒng)的安全性。本系統(tǒng)的硬件設(shè)計如圖4所示。

祛濕化瘀方藥液由上海中醫(yī)藥大學(xué)科技中心制備，冷藏備用[該方所用藥材茵陳、虎杖、田基黃、姜黃、生山梔均購自上海華宇藥業(yè)有限公司，有明確的原產(chǎn)地，經(jīng)生藥學(xué)專家鑒定均為真品。上述藥材按4∶4∶3∶2∶2的質(zhì)量比配伍；茵陳、虎杖、姜黃以75%乙醇提取3次，濾過，回收乙醇，留取藥液；生山梔、田基黃進行水提醇沉處理；合并上述藥液，濃縮，使終質(zhì)量濃度為0.93 g/mL（按生藥計）]。

圖4 多旋翼機載目標(biāo)車輛跟隨系統(tǒng)硬件示意圖

本文設(shè)計的目標(biāo)車輛跟隨系統(tǒng)以4S鋰電池組(額定電壓為16.8V)作為能源供給，其中電源管理模塊負(fù)責(zé)為動力單元與飛行控制器供電，同時檢測鋰電池組的剩余電量；直流電壓轉(zhuǎn)換模塊僅進行降壓處理，該模塊按照4A電流設(shè)計。為避免欠壓運行，調(diào)整飛行控制器與嵌入式計算機的供電電壓為5.3V。

底層控制端包括飛行控制器、動力模塊、外置定位模塊。飛行控制模塊根據(jù)IMU測量數(shù)據(jù)估計當(dāng)前多旋翼的飛行姿態(tài)，按照期望姿態(tài)輸入計算PWM頻率，調(diào)整各無刷電機的轉(zhuǎn)速，通過拉力的變化控制飛行姿態(tài)；其內(nèi)置的MS5611定高精度為10cm，可提供準(zhǔn)確的高度信息。動力模塊包括無刷電機與電子調(diào)速器，電子調(diào)速器根據(jù)飛行控制器給出的油門比例調(diào)整無刷電機的轉(zhuǎn)速，為多旋翼提供飛行動力。外置定位模塊包含電子羅盤與偏航角，分別測量多旋翼的偏航角和地球坐標(biāo)系下的位置信息。

機載處理端包括嵌入式計算機、攝像機。嵌入式計算機是本系統(tǒng)的中央處理單元，板載3個USB接口、無線網(wǎng)卡與存儲介質(zhì)；通過CH340將計算機的USB1轉(zhuǎn)換為通用串行接口(UART)，用于機載處理端與底層控制端的數(shù)據(jù)交互。攝像機接入計算機的USB2接口，需支持USB Video Class(即UVC協(xié)議)或具備Linux驅(qū)動；USB3為預(yù)留的擴展接口；存儲介質(zhì)中移植Ubuntu操作系統(tǒng)，并安裝ROS系統(tǒng)作為軟件框架，在該框架基礎(chǔ)上實現(xiàn)檢測與多旋翼位置控制。

地面監(jiān)控端不包含在本文所設(shè)計的目標(biāo)車輛跟隨系統(tǒng)中，僅按監(jiān)控需求查詢機載處理端與底層控制端的工作狀態(tài)，獲取任務(wù)結(jié)果和多旋翼運行參數(shù)。圖5為多旋翼機載目標(biāo)車輛跟隨系統(tǒng)通信流程圖。

圖5 多旋翼機載目標(biāo)車輛跟隨系統(tǒng)通信流程圖

圖5中的機載目標(biāo)車輛跟隨系統(tǒng)內(nèi)部的數(shù)據(jù)交互均通過有線鏈路，能夠有效減少通信延時，增加數(shù)據(jù)傳輸?shù)目煽啃浴SB3.0與USB2.0的傳輸速率分別為5Gbps和480Mbps，均滿足傳輸攝像機所采集的原始圖像數(shù)據(jù)，給目標(biāo)車輛檢測提供有利支撐。地面端不再參與車輛跟隨任務(wù)流程，僅作為任務(wù)下發(fā)與運行狀態(tài)監(jiān)控的交互設(shè)備，因此可使用更為輕便的手持設(shè)備作為地面端。

2.2 機載處理端限制條件

為保證多旋翼在適配機載處理端后能夠正常飛行，需對機載處理端的尺寸與重量進行限制，本節(jié)以四旋翼為例推導(dǎo)限制條件，并將其推廣至多旋翼。

2.2.1 尺寸限制

通常多旋翼需要盡可能地保證重心位于其形心，這樣能有效減少起飛后向重心偏移方向的傾斜量[10]；同時若槳葉受到遮擋，則會影響多旋翼的飛行性能[11]。本文假設(shè)機載處理端的密度均勻，安裝于規(guī)則的方形機箱內(nèi)，其形心與多旋翼的重心相重合，四旋翼的安裝俯視圖如圖6所示。

圖6 機載處理端安裝位置示意圖

根據(jù)勾股定理可計算機載處理端的最大尺寸為

(2)

式中：D與Rrotor分別是多旋翼的軸距與螺旋槳半徑，mm；α是機臂和機載處理端側(cè)邊的水平夾角，(°)。若機載處理端為一般矩形，則最長邊小于Cmax即可，該公式直接用于多旋翼。

2.2.2 重量限制

圖7為多旋翼前飛受力分析圖。由圖7可知，當(dāng)俯仰角達(dá)到最大值θmax時，動力系統(tǒng)提供的總拉力Fall在垂直方向的分力FZ最小。為保持平飛，應(yīng)滿足FZ=mmaxg(g為重力加速度)，故可求得多旋翼最大重量mmax為

圖7 多旋翼前飛受力分析

(3)

所適配的機載處理端重量應(yīng)滿足

mAE≤mmax-mbef

(4)

式中mbef為安裝機載處理系統(tǒng)前的多旋翼空載重量，g。為保留系統(tǒng)控制余量，應(yīng)限制最大油門比例為σmax，所以實際總拉力Fall≤4σmaxF(F是單個旋翼產(chǎn)生的最大拉力)。機載處理系統(tǒng)的最大重量限制為

(5)

將式(5)推廣至多旋翼時，假設(shè)多旋翼的電機個數(shù)為，所適配的機載處理端的重量應(yīng)滿足

(6)

式中：mAE為機載處理系統(tǒng)的重量；n為旋翼個數(shù)。根據(jù)多旋翼的運動原理，最大平飛速度由油門比例σ和最大俯仰角θmax決定。在限制條件中，重力加速度g為固定常量，最大拉力F和適配機載處理系統(tǒng)前的重量mbef也為可測量值，因此機載處理端的重量限制條件只與多旋翼的最大平飛速度相關(guān)。

2.3 續(xù)航影響計算

在本文所針對的目標(biāo)車輛跟隨場景中，多旋翼工作在前飛或懸停模式，由于前飛速度由地面車輛決定，無法估計跟隨過程中的續(xù)航時間。為確定適配機載處理端所帶來的續(xù)航影響，建立懸停模式下的續(xù)航計算公式，懸停模式的受力分析如圖8所示。

圖8 多旋翼懸停受力分析圖

多旋翼懸停所需拉力為

(7)

式中懸停狀態(tài)下F1=…=Fi=…=Fn，故單個電機提供的拉力為Fall/n。根據(jù)電機廠家提供的力效表可查找該拉力對應(yīng)的電機工作電流Ie，因此適配機載處理端后，系統(tǒng)的總電流為

Iall=nIe+IAE+Iother

(8)

式中：IAE為所適配的機載處理端工作電流，A；Iother為底層控制端工作電流，A。由于機載處理端經(jīng)過降壓處理，實際IAE可表示為

(9)

式中：Um為鋰電池組供電電壓，V；IPC為嵌入式計算機與其外部設(shè)備的工作電流，A。設(shè)鋰電池組最大容量為Cmax，根據(jù)式(8)與式(9)可推導(dǎo)安裝機載處理系統(tǒng)后，理論懸停時間為

(10)

3 實驗結(jié)果測試

實驗選用軸距為410mm的四旋翼進行，動力單元使用AIR GEAR 450電機搭配1045螺旋槳，由4S 4300mah鋰電池供電，其力效如表1所示。機載處理系統(tǒng)使用分辨率為720pixel、幀率為30fps的奧比中光Astra PRO深度相機；經(jīng)過測量，該多旋翼適配機載處理系統(tǒng)前后質(zhì)量分別為1.4kg和1.75kg。嵌入式機載計算機的系統(tǒng)環(huán)境為Ubuntu 18.04 arm64和ROS melodic，內(nèi)置OpenCV3.2.0，程序基于Python2.7語言編寫，使用對稱差分算法實現(xiàn)目標(biāo)檢測[12]。

表1 AIR GEAR 450力效表

3.1 可行性測試

選用重量均為46g的Raspberry Pi 3B+與Orange Pi Lite2分別作為機載處理端的中央處理單元進行對比(后續(xù)簡稱為3B+和Lite2)。選用的兩款嵌入式計算機主要參數(shù)如表2所示。

表2 嵌入式計算機主要參數(shù)表

實驗數(shù)據(jù)使用資源占用較低的HTOP工具進行讀取，分別測試在無任務(wù)、通過ROS節(jié)點采集圖像數(shù)據(jù)、進行目標(biāo)檢測三個場景的資源占用情況。在進行算法仿真時需要開啟視圖窗口觀察檢測結(jié)果，而多旋翼實際運行過程中則無須開啟視圖窗口，故分別進行測試。實驗過程中資源占用與功耗均為動態(tài)值，本文為證明其可行性，各工作狀態(tài)均取測試過程中的最大值。圖9為資源占用測試結(jié)果，橫坐標(biāo)為工作狀態(tài)，縱坐標(biāo)為相應(yīng)計算資源的占用情況。

圖9 資源占用測試結(jié)果

由圖9可以看出，即使在資源占用最高的工作狀態(tài)(開啟視圖)，所選用的兩款嵌入式計算機均可在CPU占用率低于80%，內(nèi)存占用小于700MByte時完成相應(yīng)目標(biāo)檢測任務(wù)。結(jié)合表2給出的嵌入式計算機硬件參數(shù)，此時資源裕量較為充足，系統(tǒng)可流暢運行，證明本文所設(shè)計的機載處理系統(tǒng)實際可行。

3.2 續(xù)航測試

據(jù)表1繪制推力-電流曲線，如圖10所示，用于根據(jù)多旋翼重量查找電機的理論工作電流Ie。

圖10 推力-電流曲線

結(jié)合多旋翼的工作原理，電機所產(chǎn)生推力與多旋翼的重量相等時能夠保持懸停狀態(tài)。實驗所選用的多旋翼安裝前后單個電機應(yīng)提供350g和440g的推力。由圖10曲線可查得單個的工作電流Ie分別為2.8 A和3.5 A。在進行可行性測試時，同時使用KWS-1705A電流計對機載處理端的工作電流IPC和其余負(fù)載的工作電流Iother進行測量，測試結(jié)果如表3所示。根據(jù)表3和公式(10)可計算理論續(xù)航值，實驗測試結(jié)果如表4所示。

表3 理論續(xù)航值計算參數(shù) A

表4 懸停續(xù)航測試結(jié)果 min

受實際情況影響，多旋翼懸停需不斷調(diào)整油門比例才能保證固定位置，而理論計算中通常懸停油門比例保持不變；油門比例決定了電機的轉(zhuǎn)速，與其產(chǎn)生的推力成正比關(guān)系，結(jié)合表1的力效和圖10曲線的斜率，能夠發(fā)現(xiàn)當(dāng)所需推力越大時，力效越低、斜率越大，單位推力所消耗的能量越多；反之，當(dāng)所需推力越小時，力效越高、斜率越小，單位推力所消耗的能量越少。因此，表4中實際續(xù)航時間的測試值低于依據(jù)表3與算式(10)所計算的理論值。另外，表4的測試數(shù)據(jù)中，安裝3B+與Lite2實際續(xù)航相差僅為10s左右，結(jié)合表3數(shù)據(jù)，兩者僅工作電流有所區(qū)別，其余條件均相同，因此中央處理單元的功耗并不是影響系統(tǒng)續(xù)航下降的主要因素，所以在選擇中央處理單元時可優(yōu)先考慮其性能是否滿足任務(wù)需求。

3.3 目標(biāo)檢測延時測試

為保證單一變量，實驗選用Tello無人機作為非機載處理系統(tǒng)的對照組，該無人機傳輸至地面端的圖像分辨率與Astra PRO相機同為720p，避免處理數(shù)據(jù)量的不同影響目標(biāo)檢測時間；同時采用ROS功能包Tello_driver采集圖像數(shù)據(jù)并用對稱差分算法進行目標(biāo)檢測，避免算法和軟件框架對目標(biāo)檢測時間的影響。通過在場景中放置計時設(shè)備，再將系統(tǒng)時間進行校準(zhǔn)，并將目標(biāo)檢測完成的系統(tǒng)時間輸出至視圖窗口中，由此測量目標(biāo)檢測所用的時間。表5為目標(biāo)檢測時間的測試結(jié)果。

表5 目標(biāo)檢測時間 ms

表5的測試數(shù)據(jù)表明，本文所設(shè)計的多旋翼機載目標(biāo)車輛跟隨系統(tǒng)相比于非機載系統(tǒng)，目標(biāo)檢測的時間平均縮短了135ms。對比同為機載處理系統(tǒng)，但中央處理單元分別為3B+與Lite2，結(jié)合表2給出的接口參數(shù)，通過延時更低的USB3.0接口對攝像頭進行數(shù)據(jù)采集，能夠進一步縮短延時時間。

4 結(jié)束語

以移植Ubuntu操作系統(tǒng)的嵌入式計算機作為中央處理單元，使用ROS系統(tǒng)作為軟件框架，設(shè)計了多旋翼目標(biāo)車輛跟隨系統(tǒng)。在實際飛行過程中，目標(biāo)檢測與位置控制均在嵌入式計算機中運行，可避免圖像數(shù)據(jù)的無線傳輸延時。實驗結(jié)果表明，在所設(shè)計的車輛跟隨系統(tǒng)中，通過減少圖像傳輸延時，使目標(biāo)車輛檢測的時間平均縮短了135ms，有效提高了多旋翼車輛跟隨系統(tǒng)的實時性。另外，根據(jù)多旋翼的物理模型，本文提出了機載目標(biāo)檢測系統(tǒng)的尺寸與重量限制條件，并給出理論續(xù)航計算公式。通過對實驗數(shù)據(jù)進行分析，多旋翼機載車輛跟隨系統(tǒng)續(xù)航下降的主要因素是機載處理系統(tǒng)的重量。