李少偉,張可宣
(江漢大學(xué) 人工智能學(xué)院,武漢 430056)
為了降低生產(chǎn)生活領(lǐng)域中災(zāi)難事故發(fā)生的概率,提高安全生產(chǎn)效率,視頻監(jiān)控系統(tǒng)已被廣泛應(yīng)用于包括實驗室、工廠、農(nóng)業(yè)以及軍工等各個領(lǐng)域.傳統(tǒng)視頻監(jiān)控系統(tǒng)存在使用成本高、布線復(fù)雜等問題,設(shè)計一種性能優(yōu)良、使用靈活且成本低廉的視頻監(jiān)控系統(tǒng)已成為一種迫切的需要.文獻(xiàn)[1]提出了一種基于C/S模式的遠(yuǎn)程視頻監(jiān)控系統(tǒng),該系統(tǒng)使用特定硬件完成對視頻數(shù)據(jù)的采集、加密,并通過特定的網(wǎng)絡(luò)鏈路將數(shù)據(jù)傳輸至遠(yuǎn)程服務(wù)器.服務(wù)器完成對視頻數(shù)據(jù)的解碼后將數(shù)據(jù)在本地網(wǎng)絡(luò)進(jìn)行廣播.這種方式雖然實現(xiàn)了視頻的遠(yuǎn)程監(jiān)控,但其硬件使用成本高,且客戶端必須與接收數(shù)據(jù)的服務(wù)器處于同一網(wǎng)絡(luò),并不適用于普通民用大范圍推廣;黃新等[2]使用基于ARM+Linux的嵌入式系統(tǒng)并結(jié)合V4L2 接口完成對視頻數(shù)據(jù)的采集,同時在系統(tǒng)中安裝有基于Boa 的Web 服務(wù)器,實現(xiàn)了基于Web 方式的遠(yuǎn)程視頻訪問.該方法降低了硬件使用成本,但由于直接在嵌入端運行Web 服務(wù)器,為了維持嵌入端的系統(tǒng)性能,勢必對連接客戶端的數(shù)量有所限制,因此僅適用于小范圍應(yīng)用;為了擴(kuò)大單個攝像頭的監(jiān)控范圍,陳國俊等[3–5]提出了一種ARM+Linux+移動智能車的視頻監(jiān)控模式,可以通過控制智能車的移動,實現(xiàn)單個攝像頭對不同場景的監(jiān)控,同時通過WiFi 將采集到的數(shù)據(jù)發(fā)送至遠(yuǎn)程監(jiān)控終端;卜振江等[6–9]提出了基于Android 的移動視頻監(jiān)控客戶端.通過連接流媒體服務(wù)器實時獲取視頻數(shù)據(jù),同時將收到的視頻數(shù)據(jù)顯示于Android 手機客戶端.該方法所使用的軟硬件技術(shù)成熟,開發(fā)成本低,具有較高的普及性;Zhou 等[10]設(shè)計了一種基于Raspberry Pi 的移動式視頻監(jiān)控系統(tǒng),但其采集到的數(shù)據(jù)僅能發(fā)送到擁有指定IP 的設(shè)備;Azeta 等[11]提出的基于Android 的視頻監(jiān)控系統(tǒng)可以通過手機控制搭載有攝像頭的智能車,但必須要求手機與智能車控制系統(tǒng)處于同一WiFi 網(wǎng)絡(luò)中.
綜合對上述現(xiàn)有視頻監(jiān)控系統(tǒng)的分析,本文提出了一種移動遠(yuǎn)程視頻監(jiān)控系統(tǒng).該系統(tǒng)中的攝像頭不再固定于某個位置,而是安裝于可遠(yuǎn)程操縱的移動智能車上,大大增加了視頻監(jiān)控范圍;利用Linux 系統(tǒng)中的V4L2 接口以及套接字技術(shù),極大的方便了視頻數(shù)據(jù)的采集與發(fā)送;利用桌面機的強大處理能力,實現(xiàn)數(shù)據(jù)轉(zhuǎn)發(fā)、存儲及客戶端連接,方便任意網(wǎng)絡(luò)設(shè)備對視頻監(jiān)控系統(tǒng)的訪問;運行于Android/桌面系統(tǒng)的應(yīng)用程序使得用戶在任意時刻均可實現(xiàn)對視頻的訪問,并且可以實現(xiàn)對智能車運動的操控.該系統(tǒng)在提高了視頻數(shù)據(jù)采集的靈活性,同時,簡化了攝像頭的部署,提高了系統(tǒng)可擴(kuò)展性,實現(xiàn)移動端對監(jiān)控系統(tǒng)的遠(yuǎn)程訪問.
由圖1可知,整個系統(tǒng)由車載移動式攝像頭、視頻采集系統(tǒng)、服務(wù)器以及客戶終端組成,其組成與功能如下:
圖1 系統(tǒng)結(jié)構(gòu)框圖
(1) 攝像頭搭載于履帶式智能車上,并由Arduino系統(tǒng)通過串行端口接收用戶控制指令,控制智能車的運動,從而實現(xiàn)單個攝像頭對不同區(qū)域的場景進(jìn)行視頻采集.
(2) 安裝有嵌入式Linux 的ARM 系統(tǒng)實現(xiàn)視頻數(shù)據(jù)采集、轉(zhuǎn)發(fā)以及接收控制指令的功能.一方面,系統(tǒng)通過V4L2 接口完成對USB 攝像頭的視頻數(shù)據(jù)采集,并將采集得到的視頻數(shù)據(jù)通過UDP 協(xié)議發(fā)送至數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器;另一方面,通過TCP 協(xié)議接收來自服務(wù)器轉(zhuǎn)發(fā)的控制指令,并通過串行端口傳輸至智能車控制系統(tǒng).
(3) 數(shù)據(jù)服務(wù)器承擔(dān)連接視頻采集系統(tǒng)與客戶端的功能,一方面通過UDP 協(xié)議轉(zhuǎn)發(fā)視頻數(shù)據(jù)至客戶端,另一方面通過TCP 協(xié)議轉(zhuǎn)發(fā)來自客戶端的智能車控制指令至視頻采集系統(tǒng).
(4) 運行于Android 端的APP 通過網(wǎng)絡(luò)連接至數(shù)據(jù)服務(wù)器,實時顯示收到的視頻數(shù)據(jù)并提供用戶控制界面以操作智能車的運動.
表1列明了系統(tǒng)中使用的控制指令協(xié)議.指令通過TCP 通道,由客戶終端經(jīng)過服務(wù)器發(fā)送至視頻采集系統(tǒng),實現(xiàn)對車輛移動的控制、攝像頭參數(shù)的調(diào)整以及用戶登錄.
表1 控制協(xié)議
由表1中的控制協(xié)議可知,攝像頭參數(shù)中僅包含亮度及對比度調(diào)整,取值范圍均為“0–99”.除結(jié)尾的0x10為十六進(jìn)制數(shù)以外,其他部分均采用ASCII 碼表示.整個控制協(xié)議分為三大類,分別為智能車控制協(xié)議、攝像頭參數(shù)控制協(xié)議以及用戶登錄協(xié)議.需要注意的是,視頻采集轉(zhuǎn)發(fā)模塊在收到智能車控制協(xié)議后并不會進(jìn)一步解碼,而是將其直接通過串口轉(zhuǎn)發(fā)至Arduino 系統(tǒng),從而控制車輛運動;而對于攝像頭參數(shù)調(diào)整指令,會使用相關(guān)API 完成參數(shù)調(diào)整.
智能車由左右電機帶動履帶運行,采用左右車輪轉(zhuǎn)速差的方式控制車輛的轉(zhuǎn)向,其運動受到上位機指令的控制.
圖2展示了智能車運動控制結(jié)構(gòu)模型.Arduino 系統(tǒng)與基于ARM 的視頻采集轉(zhuǎn)發(fā)系統(tǒng)通過串行端口連接并交換數(shù)據(jù).由于兩者均采用TTL 串口的方式,因此只需將雙方的RX/TX 交叉對接即可;Arduino 控制板一旦接收到來自視頻采集系統(tǒng)的指令,即通過產(chǎn)生PWM 信號,控制左右電機驅(qū)動器的工作,使得車輛能夠按照預(yù)定的軌跡運動,實現(xiàn)移動視頻采集功能.
圖2 智能車控制結(jié)構(gòu)
需要注意的是,為了降低系統(tǒng)工作量,ARM 控制端一旦接收到控制命令后即向Arduino 系統(tǒng)進(jìn)行發(fā)送,不會做出額外的操作.
對于本系統(tǒng)所使用的嵌入式ARM+Linux 系統(tǒng),UDP 協(xié)議數(shù)據(jù)包一次最大數(shù)據(jù)傳輸量約為50 kB,對于某些設(shè)備而言,無法一次性將采集到的一幀數(shù)據(jù)傳輸至服務(wù)器,因此必須對每一幀數(shù)據(jù)進(jìn)行分包處理.由于視頻采集與服務(wù)器均處于同一局域網(wǎng)中,數(shù)據(jù)傳輸速率高且錯誤率低,故本系統(tǒng)采用表2所示的簡單協(xié)議標(biāo)記幀數(shù)據(jù)的起始,并將數(shù)據(jù)切分為固定大小的塊.
表2 幀拆分協(xié)議
根據(jù)表2中的拆分協(xié)議,發(fā)送端將一幀數(shù)據(jù)切分為大小為mKB (非結(jié)尾數(shù)據(jù)塊,結(jié)尾數(shù)據(jù)塊大小為S–n×mKB,其中S為一幀數(shù)據(jù)的大小,n為非結(jié)尾數(shù)據(jù)塊的數(shù)量)的數(shù)據(jù)塊.在幀數(shù)據(jù)發(fā)送前,首先將數(shù)據(jù)頭進(jìn)行發(fā)送,然后再將塊數(shù)據(jù)按順序向外傳輸;接收端在完成數(shù)據(jù)塊的接收后會首先解碼是否為數(shù)據(jù)頭,然后分如下兩種情況完成對接收數(shù)據(jù)的操作:
(1) 當(dāng)前數(shù)據(jù)塊為數(shù)據(jù)頭.將上次數(shù)據(jù)頭與本次數(shù)據(jù)頭之間收到的數(shù)據(jù)拼接成為完成的jpeg 文件,準(zhǔn)備轉(zhuǎn)發(fā)、存儲或顯示.
(2) 當(dāng)前數(shù)據(jù)塊非數(shù)據(jù)頭.將本次數(shù)據(jù)按接收順序存放于系統(tǒng)指定的緩沖區(qū).
由以上操作可知,兩次數(shù)據(jù)頭之間的數(shù)據(jù)即為完整的圖像數(shù)據(jù)幀;數(shù)據(jù)塊的大小m根據(jù)系統(tǒng)資源以及網(wǎng)絡(luò)傳輸速度,在實際應(yīng)用中確定.
根據(jù)圖3所示的系統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu)可知,系統(tǒng)中各個模塊(除控制智能車的Arduino 系統(tǒng)外)之間的數(shù)據(jù)傳遞均通過TCP/UDP 網(wǎng)絡(luò)完成.
圖3 系統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu)
(1) 基于ARM 的視頻采集與轉(zhuǎn)發(fā)系統(tǒng)通過TCP協(xié)議在8000 端口實現(xiàn)監(jiān)聽并接收來自客戶端的指令.UDP 通道則通過8000 端口負(fù)責(zé)向外發(fā)送采集到的視頻數(shù)據(jù).本模塊一旦啟動即開始數(shù)據(jù)采集,并通過UDP通道向服務(wù)器端發(fā)送視頻數(shù)據(jù).
(2) 客戶端使用TCP與UDP 協(xié)議(8001 端口)連接至服務(wù)器,發(fā)送控制指令同時獲取視頻數(shù)據(jù).需要注意的是,由于UDP 采用了無連接傳輸方式,因此當(dāng)客戶端需要獲取視頻數(shù)據(jù)時,必須顯示的告知服務(wù)器,而當(dāng)程序退出時,則需要告知服務(wù)器本地程序已關(guān)閉,從而節(jié)約網(wǎng)絡(luò)資源.當(dāng)客戶端程序?qū)崿F(xiàn)啟動/退出動作時,會根據(jù)表1中所述指令協(xié)議,通過TCP 通道向服務(wù)器發(fā)送用戶登錄/退出指令.
(3) 服務(wù)器端的功能主要用于指令與視頻數(shù)據(jù)的轉(zhuǎn)發(fā),一方面,服務(wù)器通過TCP與UDP 協(xié)議(均為8001端口) 連接至視頻采集與轉(zhuǎn)發(fā)系統(tǒng),另一方面通過TCP與UDP 協(xié)議(均為8000 端口)進(jìn)行監(jiān)聽并與客戶端連接,實現(xiàn)視頻采集系統(tǒng)與客戶端之間的數(shù)據(jù)轉(zhuǎn)發(fā).服務(wù)器端采用圖4中所示的鏈表結(jié)構(gòu)維持客戶端信息,表中記錄了已向服務(wù)器發(fā)送登錄指令的客戶端信息,包括客戶端的IP 地址、網(wǎng)絡(luò)端口及將來可用到的擴(kuò)展信息.服務(wù)器在轉(zhuǎn)發(fā)視頻時會遍歷客戶端信息表,向表中所有的客戶端發(fā)送視頻數(shù)據(jù).
圖4 客戶端鏈表結(jié)構(gòu)
由于視頻采集系統(tǒng)中安裝有嵌入式Linux 系統(tǒng),因此可以使用V4L2 接口方便的完成視頻數(shù)據(jù)的采集與攝像頭參數(shù)的調(diào)整.根據(jù)Linux 開發(fā)文檔,結(jié)合圖5所展示的視頻數(shù)據(jù)采集與參數(shù)設(shè)定工作流程,可以快捷的完成對視頻數(shù)據(jù)的采集.
圖5 視頻采集系統(tǒng)工作流程
采集得到的視頻參數(shù)主要包括圖像分辨率、視頻格式等信息,其參數(shù)信息存儲于v4l2_format 數(shù)據(jù)結(jié)構(gòu)中;緩沖區(qū)初始化則需要指定緩沖區(qū)數(shù)量、緩沖區(qū)類型、捕獲模式以及內(nèi)存區(qū)的使用方式,其參數(shù)存儲v4l2_requestbuffers 數(shù)據(jù)結(jié)構(gòu)中.根據(jù)所選用的硬件,本系統(tǒng)選用表3中列明的參數(shù)完成視頻數(shù)據(jù)的采集.
表3 視頻采集參數(shù)
服務(wù)器接收來自視頻采集系統(tǒng)的數(shù)據(jù),然后將其轉(zhuǎn)發(fā)至客戶端,除此以外,為了方便管理人員的使用,服務(wù)器會在本地存儲視頻數(shù)據(jù)并在顯示器上向管理員實時展示當(dāng)前視頻.
為了完成上述功能,服務(wù)器本地創(chuàng)建有兩個幀緩沖區(qū)分別用于接收數(shù)據(jù)塊,當(dāng)服務(wù)器收到數(shù)據(jù)后,會選擇將其存入空閑緩沖區(qū)中,此時服務(wù)器會對另一個緩沖區(qū)中的有效數(shù)據(jù)進(jìn)行存儲與顯示操作,上述操作過程詳細(xì)展示于圖6中.由于MJPEG 中的每一幀數(shù)據(jù)為獨立的jpg 格式數(shù)據(jù),因此本系統(tǒng)引入OpenCV 庫,將jpg 數(shù)據(jù)流合并為avi 格式的視頻數(shù)據(jù);圖像的顯示則利用了VC2012 中的CImage 對象實現(xiàn).需要注意的是,視頻采集端將幀數(shù)據(jù)進(jìn)行了切分處理,所以服務(wù)器每次收到的數(shù)據(jù)僅為一幀數(shù)據(jù)的一部分,在對相關(guān)數(shù)據(jù)進(jìn)行處理前,必須對數(shù)據(jù)塊進(jìn)行拼接,從而得到完整的幀數(shù)據(jù).
圖6 視頻數(shù)據(jù)存儲與顯示
由服務(wù)器程序設(shè)計流程及方法可知,客戶端通過TCP 協(xié)議連接至CMD Channel,即指令通道;通過UDP 協(xié)議連接至Data Channel,即數(shù)據(jù)通道.連接后,客戶相關(guān)信息均顯示在圖7所示的客戶端登錄界面中.需要注意的是,客戶端可以根據(jù)需要,僅連接至其中的一個通道.
圖7 客戶端登錄信息
服務(wù)器端除承擔(dān)數(shù)據(jù)轉(zhuǎn)發(fā)功能外,亦可以實現(xiàn)對視頻數(shù)據(jù)的顯示與存儲.
圖8中所示的移動端工作流程分別展示了程序在UDP 通道的視頻接收顯示過程及在TCP 通道的指令發(fā)送過程.客戶端程序啟動時,基于TCP 協(xié)議的指令通道會自動連接至服務(wù)器指定端口,該通道僅用于指令信息從移動端至服務(wù)器端的單向流動;當(dāng)用戶需要查看視頻數(shù)據(jù)時,則需要手動點擊按鈕LOGIN 連接至基于UDP 協(xié)議的數(shù)據(jù)通道,該通道僅用于視頻數(shù)據(jù)從服務(wù)器端向移動終端單向流動.
圖8 移動端工作流程
根據(jù)圖8中的移動端程序工作流程,利用Unity 作為移動端開發(fā)工具,使得程序具備跨平臺的特性,可運行于Android、IOS、Windows 以及Linux 等操作系統(tǒng).
在本系統(tǒng)中,程序以Android 系統(tǒng)作為測試平臺,將得到的APK 文件安裝到手機客戶端中,得到圖9所示的移動端顯示界面.用戶在第一個配置界面中輸入服務(wù)器IP 地址及端口,完成后,即可進(jìn)入第二個視頻顯示及操作界面;在視頻顯示及操作界面中,用戶點擊LOGIN 完成登錄,系統(tǒng)即可實現(xiàn)視頻的顯示及控制指令的發(fā)送.
圖9 移動客戶端界面
本系統(tǒng)采用履帶型車輛作為監(jiān)控系統(tǒng)的移動載體,車輛的移動控制由Arduino 系統(tǒng)控制.視頻信號采集板與Arduino 系統(tǒng)之間通過RS232 總線連接.
圖10中的信號采集系統(tǒng)通過TCP 通道獲取客戶端指令,通過RS232 轉(zhuǎn)發(fā)至Arduino 控制板;控制板解析用戶指令并將指令信號轉(zhuǎn)換為左右兩輪的PWM 信號,控制驅(qū)動板的工作,從而帶動車輛的正確移動.
圖10 車輛控制流程
為了驗證該系統(tǒng)的實用性,同時分析系統(tǒng)的運行效率,將本系統(tǒng)采集部分(載有視頻采集系統(tǒng)的履帶車)、數(shù)據(jù)服務(wù)器以及移動客戶端均部署于江漢大學(xué)實驗室內(nèi),得到圖11所示的履帶式移動遠(yuǎn)程視頻監(jiān)控系統(tǒng).
圖11 移動視頻采集系統(tǒng)
系統(tǒng)在工作過程中,利用服務(wù)器程序?qū)崿F(xiàn)對數(shù)據(jù)包的監(jiān)控可知,在此工作環(huán)境下,視頻傳輸幀率約為20 fps,同時移動監(jiān)控端可以正確顯示視頻信息,并能夠控制智能車的前后左右四個方向的運動.
本文提出了一種移動遠(yuǎn)程視頻監(jiān)控系統(tǒng).該系統(tǒng)由以下部分組成:搭載有攝像頭的智能車與ARM+Linux系統(tǒng)結(jié)合,實現(xiàn)對視頻數(shù)據(jù)的實時采集;利用PC 機作為服務(wù)器,實現(xiàn)數(shù)據(jù)在采集端與移動監(jiān)控端之間的交互;用戶通過操作基于Android 的移動端程序,完成對視頻的監(jiān)控,并可以發(fā)送指令至采集端,控制智能車的運行.各個模塊之間通過TCP/UDP 協(xié)議實現(xiàn)連接,使得系統(tǒng)具有較強的通用性.與現(xiàn)有技術(shù)相比,該系統(tǒng)部署方便,使用成本低,使用靈活,方便了對場景的實時監(jiān)控,適合于絕大多數(shù)具備網(wǎng)絡(luò)連接的室內(nèi)場合.在下一步工作中,可以嘗試將多個攝像模塊加入系統(tǒng),實現(xiàn)一套系統(tǒng)對不同場景的監(jiān)控切換,從而實現(xiàn)對更大范圍的有效視頻監(jiān)控.