覃石昌
(中國(guó)直升機(jī)設(shè)計(jì)研究所無(wú)人機(jī)事業(yè)部,江西景德鎮(zhèn),333001)
對(duì)于無(wú)人直升機(jī)來(lái)說(shuō),其在飛行過(guò)程中,需要接收地面控制站對(duì)其發(fā)送飛行控制指令進(jìn)行姿態(tài)調(diào)控;需要接收任務(wù)控制指令執(zhí)行相應(yīng)任務(wù);需要向地面站回傳遙測(cè)數(shù)據(jù)顯示飛行狀態(tài),操作人員根據(jù)遙測(cè)數(shù)據(jù)判斷飛機(jī)飛行姿態(tài),向無(wú)人機(jī)發(fā)送相應(yīng)的遙控指令。因此,在無(wú)人直升機(jī)飛行過(guò)程中,地面控制站內(nèi)部之間、內(nèi)部與外部都會(huì)會(huì)有大量的數(shù)據(jù)交互,因而需要穩(wěn)定可靠的數(shù)據(jù)傳送通道。DDS 是分布式系統(tǒng)實(shí)時(shí)應(yīng)用程序的通訊中間件,DDS 能夠滿足非常復(fù)雜、非常靈活的數(shù)據(jù)流要求。本文利用QT 搭建無(wú)人直升機(jī)地面站[1-2]綜合處理軟件運(yùn)行框架,基于DDS 實(shí)現(xiàn)軟件對(duì)外數(shù)據(jù)通信。
無(wú)人直升機(jī)綜合處理軟件采用C++編程語(yǔ)言進(jìn)行設(shè)計(jì)與開(kāi)發(fā)。軟件采用模塊化設(shè)計(jì),具有良好的擴(kuò)展性。軟件架構(gòu)如圖1 所示。軟件包含通信、復(fù)合指令解析、綜合管理、遙測(cè)數(shù)據(jù)解析、席位管理、協(xié)議處理、日志管理等七個(gè)主要功能模塊。
圖1 無(wú)人直升機(jī)綜合處理軟件架構(gòu)圖
其中基于DDS 的通信模塊是其他功能模塊的基礎(chǔ),其他功能模塊依賴于通信處理模塊提供數(shù)據(jù)接收和數(shù)據(jù)發(fā)送通道。
DDS 是由RTI 公司研發(fā)的通信中間件,其廣泛應(yīng)用于復(fù)雜的分布式應(yīng)用、系統(tǒng)工程集成、控制自動(dòng)化等領(lǐng)域。DDS 是一個(gè)可以解決時(shí)間苛刻和數(shù)據(jù)苛刻難題的通信中間件。DDS 獨(dú)立于操作系統(tǒng)和編程語(yǔ)言,可以實(shí)現(xiàn)不同系統(tǒng)之間的通信。其傳輸方式包括以太網(wǎng)、共享內(nèi)存或其他連接方式。另外DDS 具有多種服務(wù)質(zhì)量策略(QoS)參數(shù)可供調(diào)整,方便用戶調(diào)整使應(yīng)用程序達(dá)到性能和資源利用的最佳組合。
無(wú)人機(jī)地面站內(nèi)部數(shù)據(jù)交互具有數(shù)據(jù)量大、異構(gòu)系統(tǒng)多、編程語(yǔ)言多樣化、對(duì)數(shù)據(jù)傳輸質(zhì)量要求多樣化等特點(diǎn),因而綜合處理軟件通信模塊需要選擇一個(gè)與系統(tǒng)、編程語(yǔ)言無(wú)關(guān),調(diào)試方便靈活,容易解耦的通信中間件,所以本模塊基于DDS 進(jìn)行開(kāi)發(fā),以生成源文件形式供主程序調(diào)用。
DDS 主要有兩種數(shù)據(jù)傳輸模式:主題模式和回調(diào)模式。
(1)主題模式原理如圖2 所示:通信端點(diǎn)之間創(chuàng)建域來(lái)進(jìn)行資源集中配置,每個(gè)域中有若干主題,注冊(cè)在同一個(gè)主題內(nèi)的訂閱者可以獲得發(fā)布者發(fā)布的信息。
圖2 DDS 主題模式原理圖
(2)回調(diào)模式原理如圖3 所示:調(diào)用端和服務(wù)端也需要處于相同的域和主題之下,它們之間的通信交互和普通函數(shù)回調(diào)一樣,調(diào)用端發(fā)送請(qǐng)求,服務(wù)端反饋請(qǐng)求結(jié)果。
圖3 DDS 回調(diào)模式原理圖
DDS 兩種傳輸模式下每個(gè)主題都有獨(dú)立的服務(wù)質(zhì)量策略(QoS)文件,從而針對(duì)不同的應(yīng)用場(chǎng)景對(duì)傳輸質(zhì)量和傳輸速率之間進(jìn)行優(yōu)化配置。
DDS 開(kāi)發(fā)分為以下幾個(gè)步驟,流程圖如圖4 所示:
圖4 基于DDS 通信模塊開(kāi)發(fā)步驟圖
(1)編寫(xiě)IDL(interface description language)文件;
(2)在服務(wù)端和客戶端編譯IDL 文件,生成獨(dú)立C++頭文件、源文件;
(3)在項(xiàng)目中引入生成的源文件,配置DDS 服務(wù)策略(QoS),編寫(xiě)通信處理函數(shù);
(4)代碼編譯;
(5)測(cè)試與集成。
根據(jù)軟件的應(yīng)用場(chǎng)景,軟件的DDS 通信需求分為主題模式與回調(diào)模式,席位管理指令采用回調(diào)模式,其他指令數(shù)據(jù)采用主題模式。
(1)采用回調(diào)模式的用戶登陸指令調(diào)用數(shù)據(jù)格式如下:
數(shù)據(jù)內(nèi)容為用戶名、密碼、用戶角色,密碼采用哈希加密保證數(shù)據(jù)安全,角色代表當(dāng)前登陸用戶的角色。
服務(wù)端反饋指令數(shù)據(jù)格式如下:
數(shù)據(jù)內(nèi)容為操作結(jié)果標(biāo)志,失敗原因(如果操作結(jié)果失敗,此項(xiàng)填寫(xiě)原因,成功則置空)。
(2)采用主題模式的遙控指令數(shù)據(jù)格式如下:
其中struct_header 是統(tǒng)一的數(shù)據(jù)包頭,里面包含信源、信宿、指令長(zhǎng)度等常規(guī)信息,fmCode 為指令碼,fmData為指令內(nèi)容。
通過(guò)類似上述的數(shù)據(jù)結(jié)構(gòu)的定義,創(chuàng)建了具有12 個(gè)席位管理指令數(shù)據(jù)結(jié)構(gòu)與32 個(gè)飛行指令數(shù)據(jù)結(jié)構(gòu)的IDL 文件。
打開(kāi)DDS 客戶端Launcher 界面,在code Generator子界面打開(kāi)創(chuàng)建的IDL 文件,選擇源文件輸出文件夾,編程語(yǔ)言選擇Modern c++11,運(yùn)行庫(kù)平臺(tái)選擇X64Vs2017,點(diǎn)擊運(yùn)行,可以在源文件輸出文件夾得到如圖5 所示生成的四個(gè)c++文件。
圖5 生成的源文件
在QT 創(chuàng)建的項(xiàng)目工程中導(dǎo)入生成的四個(gè)c++文件,并在環(huán)境變量配置DDS 頭文件目錄與lib 目錄。
席位管理指令要求傳輸可靠,響應(yīng)速度快,請(qǐng)求和接收同步處理,因而采用 DDS的 RELIABILITY(可靠性)Qos策略,可以保障發(fā)布的數(shù)據(jù)內(nèi)容能夠可靠的傳輸。
其他一般的指令數(shù)據(jù)特點(diǎn)是數(shù)據(jù)傳輸不可靠,數(shù)據(jù)量較大,且傳輸頻率高,因而采用DDS 的 BEST_EFFORT(高效)Qos 策略,可以保障數(shù)據(jù)寫(xiě)入者能夠以最高效的方式將數(shù)據(jù)發(fā)送出去,不會(huì)阻塞在函數(shù)調(diào)用上,提升發(fā)送者者的數(shù)據(jù)處理和發(fā)送能力。
為保證綜合處理軟件的并發(fā)處理能力,通信線程由數(shù)據(jù)接收線程(RecvThread)、數(shù)據(jù)處理線程(DealThread),數(shù)據(jù)發(fā)送線程(SendThread),回調(diào)處理線程(RRThread)四個(gè)子線程組成。
(1)為了實(shí)現(xiàn)主題模式下數(shù)據(jù)接收、發(fā)送與數(shù)據(jù)處理之間的同步,并提高數(shù)據(jù)交互效率,在RecvThread 與DealThread 之間和SendThread 與DealThread 之間均采用了采用無(wú)鎖緩沖區(qū)交換信息。
主題模式下通信處理流程如圖6 所示。
圖6 主題模式數(shù)據(jù)處理流程
(a)數(shù)據(jù)接收子線程(RecvThread)、數(shù)據(jù)處理子線程(DealThread)、數(shù)據(jù)發(fā)送子線程(SendThread)初始化完畢;
(b)RecvThread 通過(guò)類WaitSet 的wait()方法阻塞線程,直到接口接收到新數(shù)據(jù),通過(guò)DDSReader 對(duì)象接收新數(shù)據(jù);
(c)RecvThread 接收到新數(shù)據(jù)后,解析數(shù)據(jù)幀,從幀頭讀取數(shù)據(jù)信源、信宿等屬性,根據(jù)信宿分發(fā)到不同的接收緩沖區(qū);
(d)DealThread 循環(huán)處理接收緩沖區(qū)的數(shù)據(jù),分發(fā)到對(duì)應(yīng)的處理數(shù)據(jù)緩沖區(qū);
(e)SendThread 從處理緩沖區(qū)取出數(shù)據(jù),通過(guò)DDS發(fā)送出去。
(2)回調(diào)處理線程(RRThread)負(fù)責(zé)處理回調(diào)模式的數(shù)據(jù)請(qǐng)求,如圖7 所示,針對(duì)每一種類型回調(diào)指令,通過(guò)實(shí)例化一個(gè)監(jiān)聽(tīng)器(ReplierListener 類對(duì)象)來(lái)監(jiān)聽(tīng)數(shù)據(jù)接收接口,并最終在ReplierListener 類內(nèi)的on_request_available()方法內(nèi)實(shí)現(xiàn)數(shù)據(jù)處理邏輯,最后返回處理結(jié)果。
圖7 回調(diào)模式處理流程
在通信模塊設(shè)計(jì)實(shí)現(xiàn)完成后,使用QT Creator 進(jìn)行軟件其他功能模塊開(kāi)發(fā),其他的功能模塊有:
(1)席位管理模塊:管理各個(gè)控制臺(tái)席位的登陸、注銷、狀態(tài)管理,權(quán)限管理;
(2)日志管理模塊:記錄軟件運(yùn)行期間的運(yùn)行狀態(tài)數(shù)據(jù),記錄上行的遙控指令幀,下行的遙測(cè)數(shù)據(jù)幀;
(3)協(xié)議處理模塊:讀取協(xié)議文件,對(duì)上行遙控指令、下行遙測(cè)數(shù)據(jù)進(jìn)行協(xié)議解析;
(4)復(fù)合指令解析模塊:解析上行飛行遙控指令、上行遙調(diào)指令、連續(xù)量指令等,組成復(fù)合幀,發(fā)送到無(wú)人機(jī);
(5)遙測(cè)數(shù)據(jù)解析模塊:解析下行遙測(cè)數(shù)據(jù),轉(zhuǎn)發(fā)到地面控制站各個(gè)設(shè)備;
(6)綜合管理模塊:完成系統(tǒng)初始化配置,運(yùn)行狀態(tài)自檢,各個(gè)通信通道冗余切換等功能。
以上功能模塊與通信模塊通過(guò)內(nèi)部接口進(jìn)行數(shù)據(jù)交互、相互調(diào)用,共同實(shí)現(xiàn)了綜合處理軟件的主體功能。
在U-Y 型無(wú)人直升機(jī)地面站服務(wù)器內(nèi)部署該綜合處理軟件。在軟件正常啟動(dòng)后:
(1)控制臺(tái)席位均可以正常登陸,注銷,超時(shí)下線,站內(nèi)各個(gè)設(shè)備可以定時(shí)接收到綜合處理軟件發(fā)送的控制站自檢狀態(tài)數(shù)據(jù);
(2)只有具有權(quán)限的計(jì)算機(jī)才可以發(fā)送遙控,遙調(diào)指令;
(3)U-Y 無(wú)人直升機(jī) 接收到的遙控復(fù)合指令幀數(shù)據(jù)校驗(yàn)合格,指令幀傳輸時(shí)延符合設(shè)計(jì)要求;
(4)站內(nèi)設(shè)備均可接收到綜合處理軟件轉(zhuǎn)發(fā)的U-Y 無(wú)人直升機(jī)發(fā)送的遙測(cè)數(shù)據(jù);數(shù)據(jù)校驗(yàn)和時(shí)延均符合設(shè)計(jì)要求;
(5)查看日志文件,完整記錄了系統(tǒng)運(yùn)行期間的狀態(tài)與各種上行、下行數(shù)據(jù)。
綜上所述,在U-Y 無(wú)人直升機(jī)地面試驗(yàn)或飛行操作中,綜合處理軟件運(yùn)行穩(wěn)定,完全符合設(shè)計(jì)要求。
本文詳細(xì)介紹了基于DDS 的無(wú)人直升機(jī)綜合處理軟件的設(shè)計(jì)實(shí)現(xiàn)過(guò)程。用本文方法編制的綜合處理軟件,經(jīng)過(guò)在U-Y 無(wú)人直升機(jī)地面站實(shí)際運(yùn)行驗(yàn)證,該綜合處理軟件能夠完成控制臺(tái)管理、指令發(fā)送、遙測(cè)數(shù)據(jù)轉(zhuǎn)發(fā)等功能,具有運(yùn)行穩(wěn)定,運(yùn)行效率高等特點(diǎn),為U-Y 無(wú)人直升機(jī)的飛行提供了必要的幫助。日后從提高軟件通用性的角度出發(fā),將大功能部件模塊化,生成庫(kù)文件,達(dá)到其他軟件可以迅速?gòu)?fù)用的效果。