移動(dòng)遠(yuǎn)程視頻監(jiān)控系統(tǒng)①

李少偉,張可宣

(江漢大學(xué) 人工智能學(xué)院,武漢 430056)

為了降低生產(chǎn)生活領(lǐng)域中災(zāi)難事故發(fā)生的概率,提高安全生產(chǎn)效率,視頻監(jiān)控系統(tǒng)已被廣泛應(yīng)用于包括實(shí)驗(yàn)室、工廠、農(nóng)業(yè)以及軍工等各個(gè)領(lǐng)域.傳統(tǒng)視頻監(jiān)控系統(tǒng)存在使用成本高、布線復(fù)雜等問題,設(shè)計(jì)一種性能優(yōu)良、使用靈活且成本低廉的視頻監(jiān)控系統(tǒng)已成為一種迫切的需要.文獻(xiàn)[1]提出了一種基于C/S模式的遠(yuǎn)程視頻監(jiān)控系統(tǒng),該系統(tǒng)使用特定硬件完成對(duì)視頻數(shù)據(jù)的采集、加密,并通過特定的網(wǎng)絡(luò)鏈路將數(shù)據(jù)傳輸至遠(yuǎn)程服務(wù)器.服務(wù)器完成對(duì)視頻數(shù)據(jù)的解碼后將數(shù)據(jù)在本地網(wǎng)絡(luò)進(jìn)行廣播.這種方式雖然實(shí)現(xiàn)了視頻的遠(yuǎn)程監(jiān)控,但其硬件使用成本高,且客戶端必須與接收數(shù)據(jù)的服務(wù)器處于同一網(wǎng)絡(luò),并不適用于普通民用大范圍推廣;黃新等[2]使用基于ARM+Linux的嵌入式系統(tǒng)并結(jié)合V4L2 接口完成對(duì)視頻數(shù)據(jù)的采集,同時(shí)在系統(tǒng)中安裝有基于Boa 的Web 服務(wù)器,實(shí)現(xiàn)了基于Web 方式的遠(yuǎn)程視頻訪問.該方法降低了硬件使用成本,但由于直接在嵌入端運(yùn)行Web 服務(wù)器,為了維持嵌入端的系統(tǒng)性能,勢(shì)必對(duì)連接客戶端的數(shù)量有所限制,因此僅適用于小范圍應(yīng)用;為了擴(kuò)大單個(gè)攝像頭的監(jiān)控范圍,陳國(guó)俊等[3–5]提出了一種ARM+Linux+移動(dòng)智能車的視頻監(jiān)控模式,可以通過控制智能車的移動(dòng),實(shí)現(xiàn)單個(gè)攝像頭對(duì)不同場(chǎng)景的監(jiān)控,同時(shí)通過WiFi 將采集到的數(shù)據(jù)發(fā)送至遠(yuǎn)程監(jiān)控終端;卜振江等[6–9]提出了基于Android 的移動(dòng)視頻監(jiān)控客戶端.通過連接流媒體服務(wù)器實(shí)時(shí)獲取視頻數(shù)據(jù),同時(shí)將收到的視頻數(shù)據(jù)顯示于Android 手機(jī)客戶端.該方法所使用的軟硬件技術(shù)成熟,開發(fā)成本低,具有較高的普及性;Zhou 等[10]設(shè)計(jì)了一種基于Raspberry Pi 的移動(dòng)式視頻監(jiān)控系統(tǒng),但其采集到的數(shù)據(jù)僅能發(fā)送到擁有指定IP 的設(shè)備;Azeta 等[11]提出的基于Android 的視頻監(jiān)控系統(tǒng)可以通過手機(jī)控制搭載有攝像頭的智能車,但必須要求手機(jī)與智能車控制系統(tǒng)處于同一WiFi 網(wǎng)絡(luò)中.

綜合對(duì)上述現(xiàn)有視頻監(jiān)控系統(tǒng)的分析,本文提出了一種移動(dòng)遠(yuǎn)程視頻監(jiān)控系統(tǒng).該系統(tǒng)中的攝像頭不再固定于某個(gè)位置,而是安裝于可遠(yuǎn)程操縱的移動(dòng)智能車上,大大增加了視頻監(jiān)控范圍;利用Linux 系統(tǒng)中的V4L2 接口以及套接字技術(shù),極大的方便了視頻數(shù)據(jù)的采集與發(fā)送;利用桌面機(jī)的強(qiáng)大處理能力,實(shí)現(xiàn)數(shù)據(jù)轉(zhuǎn)發(fā)、存儲(chǔ)及客戶端連接,方便任意網(wǎng)絡(luò)設(shè)備對(duì)視頻監(jiān)控系統(tǒng)的訪問;運(yùn)行于Android/桌面系統(tǒng)的應(yīng)用程序使得用戶在任意時(shí)刻均可實(shí)現(xiàn)對(duì)視頻的訪問,并且可以實(shí)現(xiàn)對(duì)智能車運(yùn)動(dòng)的操控.該系統(tǒng)在提高了視頻數(shù)據(jù)采集的靈活性,同時(shí),簡(jiǎn)化了攝像頭的部署,提高了系統(tǒng)可擴(kuò)展性,實(shí)現(xiàn)移動(dòng)端對(duì)監(jiān)控系統(tǒng)的遠(yuǎn)程訪問.

1 系統(tǒng)模型

由圖1可知,整個(gè)系統(tǒng)由車載移動(dòng)式攝像頭、視頻采集系統(tǒng)、服務(wù)器以及客戶終端組成,其組成與功能如下:

圖1 系統(tǒng)結(jié)構(gòu)框圖

(1) 攝像頭搭載于履帶式智能車上,并由Arduino系統(tǒng)通過串行端口接收用戶控制指令,控制智能車的運(yùn)動(dòng),從而實(shí)現(xiàn)單個(gè)攝像頭對(duì)不同區(qū)域的場(chǎng)景進(jìn)行視頻采集.

(2) 安裝有嵌入式Linux 的ARM 系統(tǒng)實(shí)現(xiàn)視頻數(shù)據(jù)采集、轉(zhuǎn)發(fā)以及接收控制指令的功能.一方面,系統(tǒng)通過V4L2 接口完成對(duì)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) 運(yùn)行于Android 端的APP 通過網(wǎng)絡(luò)連接至數(shù)據(jù)服務(wù)器,實(shí)時(shí)顯示收到的視頻數(shù)據(jù)并提供用戶控制界面以操作智能車的運(yùn)動(dòng).

2 系統(tǒng)關(guān)鍵技術(shù)研究

2.1 指令控制協(xié)議

表1列明了系統(tǒng)中使用的控制指令協(xié)議.指令通過TCP 通道,由客戶終端經(jīng)過服務(wù)器發(fā)送至視頻采集系統(tǒng),實(shí)現(xiàn)對(duì)車輛移動(dòng)的控制、攝像頭參數(shù)的調(diào)整以及用戶登錄.

表1 控制協(xié)議

由表1中的控制協(xié)議可知,攝像頭參數(shù)中僅包含亮度及對(duì)比度調(diào)整,取值范圍均為“0–99”.除結(jié)尾的0x10為十六進(jìn)制數(shù)以外,其他部分均采用ASCII 碼表示.整個(gè)控制協(xié)議分為三大類,分別為智能車控制協(xié)議、攝像頭參數(shù)控制協(xié)議以及用戶登錄協(xié)議.需要注意的是,視頻采集轉(zhuǎn)發(fā)模塊在收到智能車控制協(xié)議后并不會(huì)進(jìn)一步解碼,而是將其直接通過串口轉(zhuǎn)發(fā)至Arduino 系統(tǒng),從而控制車輛運(yùn)動(dòng);而對(duì)于攝像頭參數(shù)調(diào)整指令,會(huì)使用相關(guān)API 完成參數(shù)調(diào)整.

2.2 基于Arduino 的智能車控制系統(tǒng)

智能車由左右電機(jī)帶動(dòng)履帶運(yùn)行,采用左右車輪轉(zhuǎn)速差的方式控制車輛的轉(zhuǎn)向,其運(yùn)動(dòng)受到上位機(jī)指令的控制.

圖2展示了智能車運(yùn)動(dòng)控制結(jié)構(gòu)模型.Arduino 系統(tǒng)與基于ARM 的視頻采集轉(zhuǎn)發(fā)系統(tǒng)通過串行端口連接并交換數(shù)據(jù).由于兩者均采用TTL 串口的方式,因此只需將雙方的RX/TX 交叉對(duì)接即可;Arduino 控制板一旦接收到來自視頻采集系統(tǒng)的指令,即通過產(chǎn)生PWM 信號(hào),控制左右電機(jī)驅(qū)動(dòng)器的工作,使得車輛能夠按照預(yù)定的軌跡運(yùn)動(dòng),實(shí)現(xiàn)移動(dòng)視頻采集功能.

圖2 智能車控制結(jié)構(gòu)

需要注意的是,為了降低系統(tǒng)工作量,ARM 控制端一旦接收到控制命令后即向Arduino 系統(tǒng)進(jìn)行發(fā)送,不會(huì)做出額外的操作.

2.3 視頻數(shù)據(jù)分包傳輸

對(duì)于本系統(tǒng)所使用的嵌入式ARM+Linux 系統(tǒng),UDP 協(xié)議數(shù)據(jù)包一次最大數(shù)據(jù)傳輸量約為50 kB,對(duì)于某些設(shè)備而言,無法一次性將采集到的一幀數(shù)據(jù)傳輸至服務(wù)器,因此必須對(duì)每一幀數(shù)據(jù)進(jìn)行分包處理.由于視頻采集與服務(wù)器均處于同一局域網(wǎng)中,數(shù)據(jù)傳輸速率高且錯(cuò)誤率低,故本系統(tǒng)采用表2所示的簡(jiǎn)單協(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ù)塊的接收后會(huì)首先解碼是否為數(shù)據(jù)頭,然后分如下兩種情況完成對(duì)接收數(shù)據(jù)的操作:

(1) 當(dāng)前數(shù)據(jù)塊為數(shù)據(jù)頭.將上次數(shù)據(jù)頭與本次數(shù)據(jù)頭之間收到的數(shù)據(jù)拼接成為完成的jpeg 文件,準(zhǔn)備轉(zhuǎn)發(fā)、存儲(chǔ)或顯示.

(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ò)傳輸速度,在實(shí)際應(yīng)用中確定.

2.4 網(wǎng)絡(luò)結(jié)構(gòu)及數(shù)據(jù)轉(zhuǎn)發(fā)

根據(jù)圖3所示的系統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu)可知,系統(tǒng)中各個(gè)模塊(除控制智能車的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 端口實(shí)現(xiàn)監(jiān)聽并接收來自客戶端的指令.UDP 通道則通過8000 端口負(fù)責(zé)向外發(fā)送采集到的視頻數(shù)據(jù).本模塊一旦啟動(dòng)即開始數(shù)據(jù)采集,并通過UDP通道向服務(wù)器端發(fā)送視頻數(shù)據(jù).

(2) 客戶端使用TCP與UDP 協(xié)議(8001 端口)連接至服務(wù)器,發(fā)送控制指令同時(shí)獲取視頻數(shù)據(jù).需要注意的是,由于UDP 采用了無連接傳輸方式,因此當(dāng)客戶端需要獲取視頻數(shù)據(jù)時(shí),必須顯示的告知服務(wù)器,而當(dāng)程序退出時(shí),則需要告知服務(wù)器本地程序已關(guān)閉,從而節(jié)約網(wǎng)絡(luò)資源.當(dāng)客戶端程序?qū)崿F(xiàn)啟動(dòng)/退出動(dòng)作時(shí),會(huì)根據(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)聽并與客戶端連接,實(shí)現(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ā)視頻時(shí)會(huì)遍歷客戶端信息表,向表中所有的客戶端發(fā)送視頻數(shù)據(jù).

圖4 客戶端鏈表結(jié)構(gòu)

3 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

3.1 視頻采集參數(shù)設(shè)定

由于視頻采集系統(tǒng)中安裝有嵌入式Linux 系統(tǒng),因此可以使用V4L2 接口方便的完成視頻數(shù)據(jù)的采集與攝像頭參數(shù)的調(diào)整.根據(jù)Linux 開發(fā)文檔,結(jié)合圖5所展示的視頻數(shù)據(jù)采集與參數(shù)設(shè)定工作流程,可以快捷的完成對(duì)視頻數(shù)據(jù)的采集.

圖5 視頻采集系統(tǒng)工作流程

采集得到的視頻參數(shù)主要包括圖像分辨率、視頻格式等信息,其參數(shù)信息存儲(chǔ)于v4l2_format 數(shù)據(jù)結(jié)構(gòu)中;緩沖區(qū)初始化則需要指定緩沖區(qū)數(shù)量、緩沖區(qū)類型、捕獲模式以及內(nèi)存區(qū)的使用方式,其參數(shù)存儲(chǔ)v4l2_requestbuffers 數(shù)據(jù)結(jié)構(gòu)中.根據(jù)所選用的硬件,本系統(tǒng)選用表3中列明的參數(shù)完成視頻數(shù)據(jù)的采集.

表3 視頻采集參數(shù)

3.2 服務(wù)器數(shù)據(jù)存儲(chǔ)與顯示

服務(wù)器接收來自視頻采集系統(tǒng)的數(shù)據(jù),然后將其轉(zhuǎn)發(fā)至客戶端,除此以外,為了方便管理人員的使用,服務(wù)器會(huì)在本地存儲(chǔ)視頻數(shù)據(jù)并在顯示器上向管理員實(shí)時(shí)展示當(dāng)前視頻.

為了完成上述功能,服務(wù)器本地創(chuàng)建有兩個(gè)幀緩沖區(qū)分別用于接收數(shù)據(jù)塊,當(dāng)服務(wù)器收到數(shù)據(jù)后,會(huì)選擇將其存入空閑緩沖區(qū)中,此時(shí)服務(wù)器會(huì)對(duì)另一個(gè)緩沖區(qū)中的有效數(shù)據(jù)進(jìn)行存儲(chǔ)與顯示操作,上述操作過程詳細(xì)展示于圖6中.由于MJPEG 中的每一幀數(shù)據(jù)為獨(dú)立的jpg 格式數(shù)據(jù),因此本系統(tǒng)引入OpenCV 庫(kù),將jpg 數(shù)據(jù)流合并為avi 格式的視頻數(shù)據(jù);圖像的顯示則利用了VC2012 中的CImage 對(duì)象實(shí)現(xiàn).需要注意的是,視頻采集端將幀數(shù)據(jù)進(jìn)行了切分處理,所以服務(wù)器每次收到的數(shù)據(jù)僅為一幀數(shù)據(jù)的一部分,在對(duì)相關(guān)數(shù)據(jù)進(jìn)行處理前,必須對(duì)數(shù)據(jù)塊進(jìn)行拼接,從而得到完整的幀數(shù)據(jù).

圖6 視頻數(shù)據(jù)存儲(chǔ)與顯示

由服務(wù)器程序設(shè)計(jì)流程及方法可知,客戶端通過TCP 協(xié)議連接至CMD Channel,即指令通道;通過UDP 協(xié)議連接至Data Channel,即數(shù)據(jù)通道.連接后,客戶相關(guān)信息均顯示在圖7所示的客戶端登錄界面中.需要注意的是,客戶端可以根據(jù)需要,僅連接至其中的一個(gè)通道.

圖7 客戶端登錄信息

服務(wù)器端除承擔(dān)數(shù)據(jù)轉(zhuǎn)發(fā)功能外,亦可以實(shí)現(xiàn)對(duì)視頻數(shù)據(jù)的顯示與存儲(chǔ).

3.3 移動(dòng)端視頻顯示與指令控制

圖8中所示的移動(dòng)端工作流程分別展示了程序在UDP 通道的視頻接收顯示過程及在TCP 通道的指令發(fā)送過程.客戶端程序啟動(dòng)時(shí),基于TCP 協(xié)議的指令通道會(huì)自動(dòng)連接至服務(wù)器指定端口,該通道僅用于指令信息從移動(dòng)端至服務(wù)器端的單向流動(dòng);當(dāng)用戶需要查看視頻數(shù)據(jù)時(shí),則需要手動(dòng)點(diǎn)擊按鈕LOGIN 連接至基于UDP 協(xié)議的數(shù)據(jù)通道,該通道僅用于視頻數(shù)據(jù)從服務(wù)器端向移動(dòng)終端單向流動(dòng).

圖8 移動(dòng)端工作流程

根據(jù)圖8中的移動(dòng)端程序工作流程,利用Unity 作為移動(dòng)端開發(fā)工具,使得程序具備跨平臺(tái)的特性,可運(yùn)行于Android、IOS、Windows 以及Linux 等操作系統(tǒng).

在本系統(tǒng)中,程序以Android 系統(tǒng)作為測(cè)試平臺(tái),將得到的APK 文件安裝到手機(jī)客戶端中,得到圖9所示的移動(dòng)端顯示界面.用戶在第一個(gè)配置界面中輸入服務(wù)器IP 地址及端口,完成后,即可進(jìn)入第二個(gè)視頻顯示及操作界面;在視頻顯示及操作界面中,用戶點(diǎn)擊LOGIN 完成登錄,系統(tǒng)即可實(shí)現(xiàn)視頻的顯示及控制指令的發(fā)送.

圖9 移動(dòng)客戶端界面

3.4 智能車控制

本系統(tǒng)采用履帶型車輛作為監(jiān)控系統(tǒng)的移動(dòng)載體,車輛的移動(dòng)控制由Arduino 系統(tǒng)控制.視頻信號(hào)采集板與Arduino 系統(tǒng)之間通過RS232 總線連接.

圖10中的信號(hào)采集系統(tǒng)通過TCP 通道獲取客戶端指令,通過RS232 轉(zhuǎn)發(fā)至Arduino 控制板;控制板解析用戶指令并將指令信號(hào)轉(zhuǎn)換為左右兩輪的PWM 信號(hào),控制驅(qū)動(dòng)板的工作,從而帶動(dòng)車輛的正確移動(dòng).

圖10 車輛控制流程

4 系統(tǒng)應(yīng)用與性能分析

為了驗(yàn)證該系統(tǒng)的實(shí)用性,同時(shí)分析系統(tǒng)的運(yùn)行效率,將本系統(tǒng)采集部分(載有視頻采集系統(tǒng)的履帶車)、數(shù)據(jù)服務(wù)器以及移動(dòng)客戶端均部署于江漢大學(xué)實(shí)驗(yàn)室內(nèi),得到圖11所示的履帶式移動(dòng)遠(yuǎn)程視頻監(jiān)控系統(tǒng).

圖11 移動(dòng)視頻采集系統(tǒng)

系統(tǒng)在工作過程中,利用服務(wù)器程序?qū)崿F(xiàn)對(duì)數(shù)據(jù)包的監(jiān)控可知,在此工作環(huán)境下,視頻傳輸幀率約為20 fps,同時(shí)移動(dòng)監(jiān)控端可以正確顯示視頻信息,并能夠控制智能車的前后左右四個(gè)方向的運(yùn)動(dòng).

5 結(jié)論與展望

本文提出了一種移動(dòng)遠(yuǎn)程視頻監(jiān)控系統(tǒng).該系統(tǒng)由以下部分組成:搭載有攝像頭的智能車與ARM+Linux系統(tǒng)結(jié)合,實(shí)現(xiàn)對(duì)視頻數(shù)據(jù)的實(shí)時(shí)采集;利用PC 機(jī)作為服務(wù)器,實(shí)現(xiàn)數(shù)據(jù)在采集端與移動(dòng)監(jiān)控端之間的交互;用戶通過操作基于Android 的移動(dòng)端程序,完成對(duì)視頻的監(jiān)控,并可以發(fā)送指令至采集端,控制智能車的運(yùn)行.各個(gè)模塊之間通過TCP/UDP 協(xié)議實(shí)現(xiàn)連接,使得系統(tǒng)具有較強(qiáng)的通用性.與現(xiàn)有技術(shù)相比,該系統(tǒng)部署方便,使用成本低,使用靈活,方便了對(duì)場(chǎng)景的實(shí)時(shí)監(jiān)控,適合于絕大多數(shù)具備網(wǎng)絡(luò)連接的室內(nèi)場(chǎng)合.在下一步工作中,可以嘗試將多個(gè)攝像模塊加入系統(tǒng),實(shí)現(xiàn)一套系統(tǒng)對(duì)不同場(chǎng)景的監(jiān)控切換,從而實(shí)現(xiàn)對(duì)更大范圍的有效視頻監(jiān)控.