基于ZigBee的圖像傳輸系統(tǒng)設(shè)計與實現(xiàn)

李 達，謝真良，李坤明，陳詩華

（1湖北工業(yè)大學機械工程學院，湖北 武漢430068；2湖北省農(nóng)業(yè)機械研究設(shè)計院，湖北 武漢430068）

目前已經(jīng)有不少無線傳感器網(wǎng)絡(luò)的應(yīng)用實例，但其應(yīng)用僅局限于溫度、濕度、光照等少量物理數(shù)據(jù)信息的獲取和傳遞。隨著技術(shù)的發(fā)展，人們已經(jīng)無法滿足從環(huán)境中獲取簡單的信息，渴望獲得圖像等更加感性和豐富的信息。在此大背景下，無線多媒體傳感器網(wǎng)絡(luò)（Wireless Multimedia Sensor Net-Work）也就應(yīng)運而生［1］。相比傳統(tǒng)無線傳感器網(wǎng)絡(luò)而言，無線多媒體傳感器網(wǎng)絡(luò)更多地關(guān)注復雜多樣的信息（尤其是視頻圖像等大量數(shù)據(jù)信息）的采集和處理，利用壓縮、識別、融合和重建等多種技術(shù)處理采集到的圖像信息，實現(xiàn)比傳統(tǒng)傳感器更全面的監(jiān)控。ZigBee技術(shù)具有低成本、低功耗和自組網(wǎng)能力強等優(yōu)點，但是ZigBee無線網(wǎng)絡(luò)數(shù)據(jù)傳輸速率較低，不適合傳輸有大量數(shù)據(jù)的圖像信息。本文就ZigBee技術(shù)實現(xiàn)圖像信息傳輸開展研究。

1 圖像采集傳輸系統(tǒng)總體方案

基于ZigBee技術(shù)圖像采集傳輸系統(tǒng)是由圖像采集節(jié)點、路由節(jié)點、協(xié)調(diào)器節(jié)點以及上位機等組成，其中圖像采集節(jié)點端的數(shù)據(jù)量大，數(shù)據(jù)處理復雜。本文提出該節(jié)點采用S3C2440ARM微處理器，USB攝像頭和CC2430ZigBee模塊相連，并采用WinCE［2］作為節(jié)點的操作系統(tǒng)。該節(jié)點具有體積小、功能強大等優(yōu)點，便于采用合理的圖像壓縮方法，減少圖像傳輸數(shù)據(jù)量，以實現(xiàn)圖像數(shù)據(jù)傳輸。與主機相連的CC2530ZigBee模塊作為協(xié)調(diào)器，主要完成網(wǎng)絡(luò)組建、控制終端節(jié)點加入、接收路由節(jié)點和終端節(jié)點發(fā)送過來的數(shù)據(jù)，當接收到數(shù)據(jù)后，通過串口輸出到PC機。由于圖像數(shù)據(jù)量大，一次傳輸圖像數(shù)據(jù)比分組多次傳輸圖像丟失數(shù)據(jù)包概率大，而且長時間占用信道會造成阻塞，影響WSN其他信息的傳輸。而且單節(jié)點頻繁發(fā)送大數(shù)據(jù)量圖像信息也會大大消耗節(jié)點能量，甚至造成節(jié)點死機，降低網(wǎng)絡(luò)通信質(zhì)量。為了使整個WSN負載均衡，避免單條路徑上節(jié)點能量集中消耗，本文結(jié)合圖像傳輸?shù)奶攸c，提出將采集的圖像經(jīng)壓縮處理并分塊，采用多信道多路徑傳輸體系，經(jīng)多串口、多線程［3］以達到數(shù)據(jù)高速傳輸，從而獲得良好圖像。系統(tǒng)總體框架結(jié)構(gòu)如圖1所示。

圖1 系統(tǒng)總體框架圖

2 圖像采集節(jié)點設(shè)計

2.1 圖像采集節(jié)點硬件設(shè)計

圖像采集節(jié)點硬件主要包括S3C2440ARM微處理器、USB攝像頭和多個支持ZigBee協(xié)議的CC2430模塊組成，其硬件原理如圖2所示。

2.2 圖像采集節(jié)點端程序設(shè)計

2.2.1 圖像采集驅(qū)動程序設(shè)計 使用USB接口攝像頭采集圖像。由于S3C2440下USB設(shè)備驅(qū)動開發(fā)只提供一些底層支持，尚未提供WinCE下USB攝像頭驅(qū)動，因此需進行USB攝像頭驅(qū)動開發(fā)。

流式驅(qū)動［4］是 WinCE驅(qū)動程序的一種常規(guī)方式，應(yīng)用程序通過文件系統(tǒng)，透過設(shè)備管理器以訪問文件的形式訪問驅(qū)動程序，調(diào)用IOCTL向驅(qū)動程序下達指令，從而訪問驅(qū)動程序及操作硬件。所有的流式驅(qū)動程序都需實現(xiàn)一組統(tǒng)一的接口。流式驅(qū)動框架如圖3所示。

圖2 圖像采集節(jié)點硬件原理圖

圖3 流式接口驅(qū)動框架

USB攝像頭驅(qū)動函數(shù)編寫，通過添加CAM＿Close，CAM＿Deinit，CAM＿Init，CAM＿IOControl，CAM＿Open，CAM＿PowerDown，CAM＿PowerUp，CAM＿Read，CAM＿Seek及CAM＿Write函數(shù)實現(xiàn)對USB攝像頭的操作。

由于ZigBee數(shù)據(jù)速率比較低，在2.4GHz的頻段只有250Kb/s，而且這只是鏈路上的速率，除掉信道競爭應(yīng)答和重傳等消耗，真正能被利用的速率可能不足100Kb/s，并且余下的速率可能要被鄰近多個節(jié)點和同一個節(jié)點的多個應(yīng)用所瓜分［2］。在不適合做圖像傳輸情況下，本文通過對圖像進行MJPEG圖像壓縮，最大程度減小了圖像的體積，以便于圖像傳輸。開發(fā)軟件平臺為EVC＋＋，核心代碼如下:

f＝ DeviceIoControl（CAMdriver，IOCTL＿CAMERA＿DEVICE＿GETSTILLIMAGE，＆vf，

sizeof （VIDFORMATSTRUCT）， ＊ ppData，dwBuff，＆dwBytes，NULL）；

∥ 打開驅(qū)動調(diào)用獲取圖像

HANDLE hFile ＝ CreateFile （lpszName，GENERIC＿WRITE｜GENERIC＿READ，0，NULL，CREATE＿ALWAYS，0，NULL）；

WriteFile （hFile，bHdr，sizeof （bHdr）， ＆dwBytes，NULL）；∥ 為文件寫入DHT顏色段

WriteFile（hFile，MJPGDHTSeg，sizeof（MJPGDHTSeg），＆dwBytes，NULL）；

∥從圖像中移走AVI頭

2.2.2 ZigBee圖像傳輸程序設(shè)計 本文提出多串口多線程通信實現(xiàn)圖像信息傳輸。根據(jù)S3C2440擴展多個串口，在主線程里面完成串口初始化，并通過串口發(fā)送圖像基本信息，新建3個子線程以查詢方式接收數(shù)據(jù)，并按照圖像數(shù)據(jù)協(xié)議回發(fā)圖像數(shù)據(jù)。

本文無線模塊協(xié)采用TI公司的Z-Stack［5］協(xié)議棧，支持ZigBee2006與ZigBee2007協(xié)議混合通信，其實現(xiàn)方式為修改2006協(xié)議棧里面的安全模式、通信信道和PANID等3個位置，和ZigBee2007保持一致就能解決混合節(jié)點通信的問題。在2006f8wConfig.cfg中修改為:

－DZDAPP＿CONFIG＿PAN＿ID＝0x00FF；∥網(wǎng)絡(luò)標識符

－DDEFAULT＿CHANLIST＝0x00008000；∥修改通信信道

－DSECURE＝0∥使安全性為0；

由于ZigBee傳輸能力有限，當采集到視頻圖像后將圖像分塊并編號，按照相應(yīng)的數(shù)據(jù)傳輸協(xié)議進行多路徑高速傳輸。第一次發(fā)送圖像數(shù)據(jù)時，發(fā)送圖像整體大小、子節(jié)點信息（表1）。圖像傳輸節(jié)點根據(jù)接收上位機數(shù)據(jù)指令發(fā)送下一塊數(shù)據(jù)和相應(yīng)的編號，循環(huán)流式發(fā)送圖像，圖像采集節(jié)點與協(xié)調(diào)器節(jié)點通信流程如圖4和圖5所示。

由于ZigBee在物理層傳輸?shù)拿繋瑪?shù)據(jù)最大為127個字節(jié)［6］，且其中還包括應(yīng)用層、網(wǎng)絡(luò)層、MAC層、物理層的幀頭以及校驗位，因此實際傳輸數(shù)據(jù)時，每幀數(shù)據(jù)只有約90個字節(jié)，本文則采用80個字節(jié)。由于幀頭要有兩個字節(jié)做應(yīng)答以確定幀的類型，因此，每幀傳輸?shù)挠行?shù)據(jù)為78位。當兩個設(shè)備建立聯(lián)系并初始化串口后，設(shè)備將開始從串口讀取數(shù)據(jù)并將數(shù)據(jù)存入緩沖區(qū)中，當數(shù)據(jù)達到80個字節(jié)或者是發(fā)送圖像數(shù)據(jù)最后剩余字節(jié)時，將數(shù)據(jù)發(fā)送到消息隊列，然后通過消息發(fā)送機制將這幀數(shù)據(jù)發(fā)送到指定的設(shè)備，并將緩沖區(qū)尾指針指向區(qū)頭。為了避免發(fā)送相同圖像信息占用寶貴帶寬，先發(fā)送圖像幀描述信息，然后再發(fā)送圖像數(shù)據(jù)信息，其數(shù)據(jù)包結(jié)構(gòu)分別如表1和2所示。

圖4 協(xié)調(diào)器接收端

圖5 圖像采集端

Typedef struct ImageData

｛ unsigned short Image＿number；∥圖像編號

unsigned char Image＿data［78］；∥圖像數(shù)據(jù)

｝Image＿Block

表1 圖像幀描述數(shù)據(jù)包結(jié)構(gòu)

表2 圖像數(shù)據(jù)包結(jié)構(gòu)

圖像采集節(jié)點通過多串口連接多個無線模塊協(xié)作發(fā)送分塊圖像數(shù)據(jù)包。當上位機接收到的圖像信息小于圖像整體大小，或收到數(shù)據(jù)信息有錯誤，就回發(fā)圖像數(shù)據(jù)結(jié)構(gòu)體中應(yīng)答編號給相應(yīng)串口以請求重新發(fā)送該組數(shù)據(jù)，如果沒有錯誤就繼續(xù)發(fā)送下一組圖像數(shù)據(jù)，直到完全接收圖片信息。當上位機接收到全部圖像信息，發(fā)送圖像接收完成確認應(yīng)答給圖像采集端，并請求發(fā)送下一幀圖像數(shù)據(jù)。圖像采集節(jié)點發(fā)送數(shù)據(jù)代碼如下:

static void rxCB （uint8port，uint8event）

｛

HalUARTRead（0，uartbuf，80）； ∥ZigBee讀串口數(shù)據(jù)

形制的新發(fā)展主要體現(xiàn)在：蓋、碗組合基礎(chǔ)上，碗托加入，形成固定的三件結(jié)構(gòu)。功能同從古至今的盞托作用一樣，故使得三件式蓋碗相比兩件式蓋碗，更添了防燙便于端拿，茶湯溢出有所承接的優(yōu)勢。

osal＿set＿event（GenericApp＿TaskID，SEND＿DATA＿EVENT）；

∥發(fā)送端ZigBee對應(yīng)程序當有數(shù)據(jù)的時候設(shè)置事件

｝

if（events＆SEND＿DATA＿EVENT）

｛

afAddrType＿t my＿DstAddr； ∥節(jié)點信息結(jié)構(gòu)體

my＿DstAddr.addrMode＝（afAddrMode＿t）Addr16Bit；∥單播方式發(fā)送數(shù)據(jù)

my＿DstAddr.endPoint＝GENERICAPP＿ENDPOINT；∥節(jié)點為終端節(jié)點

my＿DstAddr.addr.shortAddr＝0x0000；∥協(xié)調(diào)器網(wǎng)絡(luò)地址AF＿DataRequest（＆my＿DstAddr，＆GenericApp＿epDesc，GENERICAPP＿CLUSTERID，

80，uartbuf，＆GenericApp＿TransID，AF＿DISCV＿ROUTE，AF＿DEFAULT＿RADIUS）；

∥節(jié)點信息數(shù)據(jù)發(fā)送函數(shù)

return（events＾SEND＿DATA＿EVENT）；∥事件異或，將處理完事件清除

｝

CC2430模塊通過串口每次接收由ARM板發(fā)送的80個字節(jié)，并加上節(jié)點其他信息，將這些字節(jié)以單播的方式發(fā)送給網(wǎng)絡(luò)地址為0x0000的協(xié)調(diào)器節(jié)點。當發(fā)送節(jié)點接收到協(xié)調(diào)器返回來編號指令后，接著發(fā)送下一塊圖像數(shù)據(jù)，直至整幅圖像數(shù)據(jù)發(fā)送完畢。

3 上位機測試程序設(shè)計

當協(xié)調(diào)器發(fā)送圖像請求指令給圖像采集終端節(jié)點后，終端節(jié)點將該節(jié)點類型、網(wǎng)絡(luò)地址、父節(jié)點信息以及傳感器采集到的圖像信息打包，通過無線傳感器網(wǎng)絡(luò)傳給上位機，采用VC＋＋的MFC繪制節(jié)點網(wǎng)絡(luò)拓撲圖并將獲得的圖像數(shù)據(jù)塊數(shù)據(jù)融合后顯示在PC機的界面上。

由于圖像數(shù)據(jù)量大，需要分塊傳輸，為了提高傳輸穩(wěn)定性，獲得完整圖像，需要在PC端制訂好數(shù)據(jù)接收、確認和重傳機制協(xié)議。由于確認幀ACK在WSN中代價過高，傳統(tǒng)的TCP/UDP協(xié)議無法滿足圖像傳輸。為此，本文結(jié)合TCP和UDP傳輸協(xié)議，在保證傳輸可靠性的同時也避免浪費帶寬，提出了適合WSN圖像傳輸協(xié)議。上位機接收到圖像描述信息后，給全局變量動態(tài)申請內(nèi)存，通過多串口接收圖像數(shù)據(jù)，當接收到圖像數(shù)據(jù)錯誤時，對該圖像數(shù)據(jù)塊進行處理并發(fā)送該數(shù)據(jù)塊編號到終端節(jié)點，請求該數(shù)據(jù)重傳。當接收數(shù)據(jù)正確則提取數(shù)據(jù)填充到全局變量數(shù)組中。

PC機通過多串口接收多個協(xié)調(diào)器數(shù)據(jù)，在MFC中引入Mscomm控件，初始化多個串口。當對應(yīng)串口中達到80個字節(jié)，則通過串口事件消息處理函數(shù)解析數(shù)據(jù)包，提取信息；當收到結(jié)束標志位時即獲得完整的數(shù)據(jù)塊，將接收到數(shù)據(jù)塊融合成圖片，在界面上顯示。對于非圖像數(shù)據(jù)信息，采用 MSFlexGrid控件實時顯示傳感器采集數(shù)據(jù)信息，通過ADO對Access2003數(shù)據(jù)庫操作，以保存信息。通過圖像采集信息表和節(jié)點狀態(tài)信息表，能將圖像信息和節(jié)點狀態(tài)信息保存在PC硬盤中，便于之后的研究分析，圖像采集界面如圖6所示。

圖6 PC端圖像采集界面

4 系統(tǒng)性能分析

采用單串口傳輸，從圖像采集節(jié)點傳輸一張分辨率為160×120，3747字節(jié)圖像，每次傳輸數(shù)據(jù)塊設(shè)置為80字節(jié)，ZigBee理論傳輸速率為250Kb/s，則完成一次完整圖像傳輸理論最短時間為:2×（48×80＋5）×8/115200＋（48×118＋43）×8/250000＝0.7166s。

當采用本文提出的多串口協(xié)作并行通信傳輸，傳輸時間理論上應(yīng)大幅減少。在此搭建實驗平臺，兩個ZigBee串口終端作為圖像傳輸節(jié)點，兩個Zig－Bee節(jié)點作為匯聚節(jié)點與PC交互，無路由節(jié)點。設(shè)置串口與ZigBee連接端波特率為115200bps，每次傳輸數(shù)據(jù)塊為80字節(jié)，通過實驗做50次傳輸，統(tǒng)計接收圖像成功次數(shù)以及每次圖像傳輸時間。結(jié)果成功接收48張，失效2張，接收成功率為96%，傳輸?shù)?0張圖像，平均每張1.156s。雖理論上每張圖像最短傳輸時間為0.3583s，因為圖像是多串口分組并行傳輸，在單核處理器中，并行傳輸在實際運行過程中還是串行執(zhí)行的，而且圖像采集節(jié)點連續(xù)向協(xié)調(diào)器傳輸大量數(shù)據(jù)會造成信道擁塞，可靠信差，為了獲得完整可靠的圖像建立的反饋、重發(fā)機制也占用了一定時間。造成傳輸失效的主要原因是Zig－Bee網(wǎng)絡(luò)不穩(wěn)定，以及傳輸過程的擁塞。

5 結(jié)論

本文構(gòu)建了基于WinCE系統(tǒng)下ZigBee的無線傳感器網(wǎng)絡(luò)的圖像傳輸平臺，在此平臺下實現(xiàn)了圖像采集、傳輸、存儲、顯示。通過設(shè)計硬件節(jié)點及其軟件，與常規(guī)的無線傳感器網(wǎng)絡(luò)的數(shù)據(jù)傳輸方式相比，性能有所提高，但傳輸效率仍較低，其性能還有待進一步完善。

［1］ 劉 磊.基于無線傳感器網(wǎng)絡(luò)的視頻傳輸技術(shù)研究［D］.北京:華北電力大學，2012.

［2］ Muench C.The windows ce technology tutorial:solutions for the developer［M］.北京:中國電力出版社，2001.

［3］ 李 勇.一個多串口多線程數(shù)據(jù)采集系統(tǒng)軟件的設(shè)計與實現(xiàn)［J］.微計算機信息，2006（16）:152-154.

［4］ 周立功.ARM＆WinCE實驗與實踐—基于S3C2410［M］.北京:北京航空航天大學出版社 ，2007.

［5］ 王小強，歐陽駿，黃寧淋.無線傳感器網(wǎng)絡(luò)設(shè)計與實現(xiàn)［M］.北京:化學工業(yè)出版社，2012.

［6］ ZigBee Alliance.EEE 802.15.4－2003Wireless Medium Access Control（MAC）and Physical Layer（PHY）Specifications for Low Rate Wireless Personal Area Networks［S］.2003.