|
引言 據媒體報道，我國由于后視鏡盲區造成的交通事故約占30%。而且，隨著“考駕照”熱不降溫的現象出現，未來的汽車后視鏡盲區問題更是不容小覷。數字社會的形成為數字化實時監控提供了契機，汽車后視場景的數字化實時監控成為解決后視鏡盲區問題的研究熱點。 目前，市場上已經出現了一些數字化的汽車監控系統，常見的有分屏顯示的監控系統、有縫拼接的監控系統和第8代“衛星”全景行車安全系統。分屏顯示的監控系統只是對圖像進行簡單的分屏顯示，不能實時地將車輛周圍的景象顯示在屏幕上；有縫拼接的監控系統不是將圖像簡單地疊加，而是對圖像拼接處理，形成中間是車子，周圍是圖像的全景圖，缺點在于四個圖像拼接之處存在明顯的拼接縫；第8代“衛星”全景行車安全系統采用超廣角攝像頭，它能夠更好地消除圖像拼接之處的拼接縫，形成汽車全景俯視圖。 Android系統具有平臺開放性，而且谷歌的“開放汽車聯盟（OAA）”致力于實現汽車與Android設備的無縫連接以及直接在汽車上內置Android車載系統；DM3730 集成了1GHz的ARM Cortex-A8核和800MHz的TMS320C64x+ DSP核，DSP在數字信號處理上具有無可比擬的優勢，更適合進行圖像處理。因此，基于Android和DM3730設計的車載分布式視頻監控系統有著廣闊的應用前景。 車載分布式視頻監控系統集成了Android平臺的開放性、ARM+DSP的高性能、以太網的可擴展性和USB攝像頭的即插即用性，對實現汽車數字化實時監控有研究意義和應用價值。 1系統的整體設計 車載分布式視頻監控系統由視頻采集模塊、視頻傳輸模塊、視頻拼接模塊和視頻顯示模塊四個模塊組成。圖1展示了系統的整體設計，圖2展示了系統各模塊之間的硬件接口。 圖1 車載分布式視頻監控系統整體設計示意圖 圖2 車載分布式視頻監控系統硬件接口框圖 ① 視頻采集模塊：AM3715開發板通過USB-HOST接口外接USB攝像頭，通過Android操作系統的Java本地調用接口[3]（JNI）和V4L2 (video 4 linux 2)視頻驅動框架實時采集視頻并顯示。 ② 視頻傳輸模塊：兩個（或多個）AM3715和DM3730開發板之間通過以太網相連，利用RTP組播協議和自定義同步機制將USB攝像頭采集的圖像實時傳輸至DM3730開發板的ARM端。 ③ 視頻拼接模塊：DM3730開發板的ARM端運行嵌入式Linux操作系統（或Android操作系統），通過TI Codec Engine模塊同時在ARM端和DSP端映射共享內存，使得同步接收的兩幅（或多幅）圖像能夠被ARM和DSP同時訪問。針對車載應用擴充嵌入式計算視覺庫（EMCV），并移植和優化SURF開源項目OpenSURF，DSP端能夠實時拼接兩幅（或多幅）圖像，最后將拼接結果由共享內存返回ARM端。 ④ 視頻顯示模塊：視頻顯示是通過跨平臺多媒體庫SDL（Simple DirectMedia Layer）來完成的。其中，AM3715開發板顯示分離的USB攝像頭圖像，DM3730開發板顯示拼接完成的圖像。 2 視頻采集傳輸和顯示 2.1 Android V4L2視頻采集模塊 V4L2從Linux 2.5.x版本的內核開始出現，為使能UVC驅動和V4L2編程框架，首先需檢查Android內核配置選項，以生成視頻設備文件/dev/videoX（X表示次設備號）。 利用V4L2進行USB攝像頭視頻采集的流程[7]包括：（1）打開視頻設備文件；（2）檢查設備屬性；（3）設置視頻格式；（4）幀緩沖區管理；（5）循環采集視頻；（6）關閉視頻設備。 V4L2介于應用程序和硬件設備之間，應用程序可以通過三種方式訪問內核層的數據：直接讀/寫方式、內存映射方式和用戶指針方式。直接讀/寫方式需要在用戶空間和內核空間不斷拷貝數據，效率低下；內存映射方式把內核地址映射到用戶地址空間，進程可以直接讀寫內存，避免了數據的拷貝，具有較高的效率；用戶指針方式的內存片段是由應用程序自己分配的。 車載分布式視頻監控系統采用效率較高的內存映射方式，系統調用mmap()能夠將內核地址映射到用戶地址空間。 2.2 RTP視頻傳輸模塊 鑒于以太網具有高速的傳輸能力和良好的可擴展性能，車載分布式視頻監控系統通過RTP組播的方式在Android系統與嵌入式Linux系統之間傳輸USB攝像頭采集的圖像。文獻[8]描述了利用RTP庫JRTPLIB實現視頻實時傳輸的過程。為了確保兩個AM3715開發板與DM3730開發板之間圖像傳輸的同步性，車載分布式視頻監控系統設計了同步傳輸協議，協議描述如下： (1)發送端 ① 每個發送端等待來自接收端的視頻幀請求命令’R’，否則不執行發送操作。 ② 收到幀請求命令后，發送端首先向組播地址發送視頻幀傳輸開始標識0xFE，以標識一幀視頻傳輸的開始。 ③ 將YUY2格式的圖像依次向組播地址傳輸，每次傳輸m行，傳輸n次，并在每個RTP數據包的首字節位置添加RTP包傳輸序號（序號從0開始，依次增1）。假設YUY2圖像寬度為width，高度為height，由于平均一個像素占2B，所以每次傳輸的RTP包數據大小為(2m*width+1)B，傳輸次數n = height/m。 ④ 傳輸結束時，向組播地址發送視頻幀傳輸結束標識0xFF，以標志一幀視頻傳輸的結束。 （2）接收端 ① 接收端向組播地址發送幀請求命令’R’，然后啟動軟件電子狗，并處于阻塞等待狀態。 ② 若軟件電子狗計時結束時仍未被喂狗，說明網絡通信出現故障，重新向組播地址發送幀請求命令’R’，并重啟軟件電子狗。 ③ 依次接收來自每個發送端的RTP數據包，并根據IP地址和RTP包傳輸序號還原每幀視頻，直至收到視頻幀傳輸結束標識0xFF。 2.3 SDL視頻顯示模塊 YUV格式在存儲方式上分為打包格式（Packed Format）和平面格式（Planner Format），打包格式的Y、U、V三個分量連續交叉存儲，而平面格式的Y、U、V三個分量分開存儲。實驗中USB攝像頭采集的圖像格式是YUY2格式，而經過拼接完成的圖像是YV12格式。YUY2格式是一種打包格式，以4:2:2方式打包，每個像素保留Y分量，而UV分量在水平方向上的采樣率僅為Y分量的1/2，即存儲順序為[Y0 U0 Y1 V0] [Y2 U2 Y3 V2] ……[Y2n U2n Y2n+1 V2n]。YV12是一種平面格式，UV分量在水平方向和垂直方向上的采樣率均為Y分量的1/2。特殊地，YV12格式在UV提取時，需先將圖像劃分為若干個2 x 2的方陣，然后在每個方陣上提取一個U分量和一個V分量。例如，對于6x4的圖像，YV12的采樣方式如下圖所示，其存儲順序為[Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8 Y9 Y10 Y11 Y12 Y13 Y14 Y15 Y16 Y17 Y18 Y19 Y20 Y21 Y22 Y23] [U0 U1 U2 U3 U4 U5] [V0 V1 V2 V3 V4 V5 V6]。 YV12采樣方式示意圖 SDL支持FrameBuffer，利用SDL可以在Android和Linux上直接顯示YUY2和YV12格式的圖像，不需要經過YUV格式到RGB格式的轉換。不同的是，標準Linux的FrameBuffer設備文件為/dev/fb0，而Android Linux的FrameBuffer設備文件是/dev/graphics/fb0。利用SDL顯示YUV格式圖像的流程包括：（1）初始化視頻設備；（2）設置視頻顯示模式；（3）創建YUV覆蓋層；（4）輪詢事件處理；（5）繪制YUV覆蓋層；（6）顯示YUV覆蓋層；（7）釋放YUV覆蓋層；（8）退出SDL。 3 ARM+DSP雙核視頻拼接模塊 3.1 Codec Engine雙核通信設計 Codec Engine是ARM和DSP通信的橋梁，采用遠程過程調用（RPC）的思想。ARM端作為客戶端，DSP端作為服務器端，ARM和DSP之間的通信鏈路是共享內存，通信協議是DSP Link。Codec Engine有專門的內存管理驅動CMEM來管理ARM和DSP之間的共享內存，CMEM以內存池或內存堆的方式管理一個或者多個連續的物理塊內存并提供地址轉換（虛擬地址和物理地址之間的轉換）功能。 Codec Engine有核心引擎接口和VISA接口。核心引擎接口包括引擎的初始化接口、引擎運行狀態的控制接口和內存的系統抽象層接口；VISA接口包括視頻編/解碼接口、音頻編/解碼接口、圖像編/解碼接口和語音編/解碼接口。VISA接口的使用分為VISA創建、VISA控制、VISA處理和VISA刪除四部分，圖3展示了通過VISA控制/處理的流程。 圖3 VISA 控制/處理示意圖 Codec Engine的使用分為創建應用程序、實現Codec算法和集成Codec Server三部分。應用程序運行在ARM端，通過調用核心引擎接口和VISA接口與DSP進行通信；對于符合XDM（eXpressDSP Digital Media）規范的Codec算法，Codec Engine的VISA接口不需要附加條件就能支持遠端運行，對于符合XDAIS（eXpressDSP Algorithm Interface Standard）規范的非XDM算法，必須提供Codec Engine的存根和骨架中間件才能支持遠端運行；Codec Server運行在DSP端，負責管理調度不同的Codec算法。 車載分布式視頻監控系統接收端使用視頻編碼接口（VIDENC_）實現ARM端調用DSP端基于SURF的圖像拼接算法。應用程序的執行流程如圖4所示。 圖4 車載分布式視頻監控系統接收端應用程序流程圖 3.2基于SURF的視頻拼接 系統采用SURF算法檢測特征點和描述特征點。SURF具有尺度和旋轉不變性，對光照和視點變換具有不錯的魯棒性，并且經過優化后可以滿足實時性要求。根據特征點之間的歐氏距離進行粗匹配，使用RANSAC（隨機一致性）方法去除錯匹配點，計算圖像之間的透視變換矩陣，最終采用漸入漸出平均法融合圖像。 針對本系統，可以對算法進行進一步的優化，提高系統的實時性。由于系統中攝像頭的位置相對固定，因而可以預先計算圖像之間的重疊位置，不需檢測完全沒有圖像重疊的區域；同時，由于攝像頭相對位置不變，圖像之間的透視變化矩陣不會變化，因此可以只計算一次透視變化矩陣，后續拼接使用第一次的透視變化矩陣，可進一步提高實時性。 （1）SURF特征點檢測 SURF特征點檢測是在尺度空間中進行的，并使用Hessian矩陣行列式值檢測特征點，尺度為σ的點X(x,y)的Hessian矩陣H(X,σ)定義如式（3-1），其中Lxx (X,σ)，Lxy (X,σ)，Lyy (X,σ)為在尺度σ下的高斯函數的二階偏導數在圖像點X處的卷積。 SURF使用基于積分圖的盒型濾波器（box filter）近似此高斯卷積過程，圖3-2所示為9*9盒型濾波器對分別對x，y，xy方向的二維高斯濾波的近似。通過近似，將在點X(x,y)的二維高斯卷積轉化為對其周圍的加權計算過程，在此加權計算過程中，使用積分圖計算圖3-2中黑色矩形區域和白色矩形區域灰度值之和，將高斯濾波中的大量的乘法運算轉換為簡單的加減運算。 設對x，y，xy方向的二維高斯卷積的近似分別用Dxx，Dyy，Dxy表示，則可以通過式（3-2）近似Hessian矩陣H(X,σ)行列式值，其中w通常取0.9。當Det(H(X,σ))>0時，Dxx>0時，點X(x,y)為局部極小值點；Dxxxx*Dyy-(w*Dxy)2 （3-2） （2）SURF特征點描述 特征點描述主要分兩步：第一步是獲取特征點的主方向，主要目的是為了保證旋轉不變性。第二步是生成64維的特征點描述符，主要目的是描述特征點的特征。 為了獲取特征點的主方向，計算以特征點為中心，半徑為6σ（σ為特征點所在的尺度）內的所有點在x，y方向的Harr小波響應。并選取一個大小為60度的扇形窗口旋轉整個圓形區域，將窗口內所有x，y方向的響應值相加得到一個新矢量，最終以最長的矢量所在的方向作為特征點的主方向。 特征點描述需要將坐標軸旋轉到主方向上，并將以特征點為中心的邊長為20σ的區域劃分為4×4個子窗口，每個子窗口分為5×5個采樣點，計算每個采樣點的沿主方向和垂直主方向的Harr小波響應，記為d_x和d_y，最終生成一個4維矢量v=(∑dx,∑dy ,∑|dx|,∑|dy|)，并將其歸一化。總共4×4個子窗口，生成64維的描述符。 3.3 SURF在DM3730上的移植和優化 （1）SURF的移植 SURF算法實現基于OpenCV1.0,OpenCV庫針對x86架構作了許多優化，在DSP上的執行效率難以得到保證。EMCV是一個可運行在DSP上的OpenCV庫，但只實現了部分OpenCV的數據結構和庫函數。因此，車載分布式視頻監控系統需要擴充EMCV庫，以支持SURF在DM3730上的運行。擴充的庫函數包括：cvAdd、cvAddWeighted、cvConvertScale、cvCvtColor、cvGEMM、cvInvert、cvMerge、cvResetImageROI、cvResize、cvSVD、cvSetImageROI、cvSplit、cvWarpPerspective。 為了便于EMCV庫的擴充和優化，EMCV庫通過CCS（Code Composer Studio）軟件以lib靜態庫的形式提供給Codec算法使用，如下所示： [package.bld] packageti.sdo.ce.examples.codecs.videnc_mosaic.emcv{ } [package.xs] functiongetLibs(prog){ var name = null; if (prog.build.target.isa == "64P") { var name = "emcv.lib"; print(" will link with " + this.$name + ":" + name); } return (name); } 此外，為了消除SURF對C++標準模板庫的依賴，車載分布式視頻監控系統設計了專門的容器結構和相應的操作，主要代碼如下： typedefstruct _Vector{ void *pdata; // 數據塊首地址 int count; // 數據塊元素數目 int size; // 數據塊已用大小 int totalSize; // 數據塊總大小 }Vector; #define PRE_CALLOC_SIZE 20 // 預分配元素個數 /* 添加nElem個元素，每個元素大小elSize */ intvector_pushback( Vector *pVector, intnElem, intelSize ){ int n = nElem> PRE_CALLOC_SIZE? nElem:PRE_CALLOC_SIZE; if(pVector->size + nElem*elSizetotalSize ){ pVector->size += nElem*elSize; pVector->count += nElem; return 0; }else{ // 預分配的內存不足，需重新分配內存 pVector->totalSize += n*elSize; void *pNewData = (void*)realloc( pVector->pdata, pVector->totalSize ); if(pNewData ){ pVector->pdata = pNewData; pVector->size += nElem*elSize; pVector->count += nElem; return 0; }else{ // 內存分配失敗 return -1; } } } /* 銷毀容器，釋放內存 */ voidvector_destroy( Vector*pVector ){ if(pVector->pdata ){ free(pVector->pdata ); pVector->pdata = NULL; } pVector->size = pVector->count = pVector->totalSize = 0; } （2）SURF在DM3730上的優化 SURF在DM3730上的優化分為項目級優化、指令級優化和緩存優化三個方面。項目級優化是通過合理地選擇和配置相關的編譯器優化選項，主要包括：調試模式選項（Debugging Model）、優化等級選項（opt_level）、代碼大小選項（opt_for_sapce）、代碼速度選項（opt_for_speed）、程序級優化(-op)等。為了最大限度地提高代碼的執行效率，車載分布式視頻監控系統選擇的編譯器優化選項為-o3、-ms0、-mf5、-op2、-mt、-mh、-mw。指令級優化包括選擇合適的數據類型，消除指令和數據之間的相關性，使用內聯（intrinsic）函數以及改善軟件流水等。緩存優化是將CPU近期訪問過的數據或者程序放置在Cache中，以提高CPU的執行速度。 4 測試結果及分析 圖6展示了車載分布式視頻監控系統的拼接效果，表1比較了SURF和SIFT算法在DM3730和PC機上的拼接效率。從拼接效果可以看出，車載分布式視頻監控系統能適應圖像的平移、旋轉和縮放等特性。圖6中的兩幅待拼接的圖像存在明顯的旋轉特性，并且拼接完成的圖像有一定的縮放效果。從表1中可以看出，車載分布式視頻監控系統在視頻采集、視頻傳輸和視頻顯示上總耗時約為257ms，遠遠小于視頻拼接所需時間3264ms。這是由于視頻拼接模塊使用了許多EMCV和OpenCV庫函數，它們在DM3730處理器上還有待進一步被優化。作為SIFT算法的加速版，SURF算法的執行效率要遠遠大于SIFT算法的執行效率。從本次測試結果看，在DM3730上，SURF算法的執行效率是SIFT算法執行效率的3.68倍左右；而在以Intel Core2 Duo T5870為處理器的PC機上，SURF算法的執行效率是SIFT算法執行效率的1.40倍左右。 在攝像頭相對位置固定情況下，圖像之間的透視變化矩陣固定，因此只需計算一次透視變化矩陣，后續的圖像拼接只需進行圖像配準和融合。表2中列出了DM3730上SURF算法的時間組成，其中SURF算法透視變換矩陣計算時間占95%以上，實際的圖像拼接時間為圖像配準和如何時間，平均時間約為66ms。 結語 本文從視頻采集、視頻傳輸、視頻拼接和視頻顯示等四個方面詳細闡述了基于Android和DM3730的汽車分布式視頻監控系統的設計原理和優勢。從測試結果看，車載分布式視頻監控系統基本上能達到實時采集、實時傳輸、實時顯示，經過優化后，圖像拼接的效率基本能滿足實時性要求，但系統整體性能還有待提高，可以采用多核處理器代替單核處理器，進一步提高系統的實時性。 參考文獻 [1] Google launches the Android-based Open Automotive Alliance with Audi, Honda, GM, and more, The Verge, January 6, 2014. [2] Instruments T. DM3730, DM3725 Digital Media Processors[R]. Tech. Rep. July, 2011. [3] Lee Y H, Chandrian P, Li B. Efficient java native interface for android based mobile devices[C]//Trust, Security and Privacy in Computing and Communications (TrustCom), 2011 IEEE 10th International Conference on. IEEE, 2011: 1202-1209. [4] 龔澤摯, 藍曉柯, 鄭雅羽. 基于 Android 和 DM3730 的視頻編碼軟件開發[J]. 電視技術, 2013, 37(17): 76-79. [5] 胡楠. EMCV 庫擴充及車輛檢測系統的嵌入式實現[D]. 大連海事大學, 2011. [6] 于海. OpenSURF在TI DM642上的移植[J]. 電子科技, 2012, 25(5): 133-136. [7] 王飛, 孔聰. 基于 V4L2 的 Linux 攝像頭驅動的實現[J]. 電子科技, 2012, 25(2): 86-87. [8] 趙學良. 基于 Android 的流媒體引擎設計與實現[D]. 電子科技大學, 2012. [9] Bay H, Tuytelaars T, Van Gool L. Surf: Speeded up robust features[M]//Computer Vision–ECCV 2006. Springer Berlin Heidelberg, 2006: 404-417. [10] 楊小輝, 王敏. 基于 ASIFT 的無縫圖像拼接方法[J]. 計算機工程, 2013, 39(2): 241-244. [11] 劉旭. 多圖像全景拼接技術研究[D]. 武漢理工大學, 2012. |
