李 達(dá)，謝真良，李坤明，陳詩(shī)華

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

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

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

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

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

2 圖像采集節(jié)點(diǎn)設(shè)計(jì)

2.1 圖像采集節(jié)點(diǎn)硬件設(shè)計(jì)

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

2.2 圖像采集節(jié)點(diǎn)端程序設(shè)計(jì)

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

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

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

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

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

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

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

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

∥ 打開驅(qū)動(dòng)調(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è)計(jì) 本文提出多串口多線程通信實(shí)現(xiàn)圖像信息傳輸。根據(jù)S3C2440擴(kuò)展多個(gè)串口，在主線程里面完成串口初始化，并通過(guò)串口發(fā)送圖像基本信息，新建3個(gè)子線程以查詢方式接收數(shù)據(jù)，并按照?qǐng)D像數(shù)據(jù)協(xié)議回發(fā)圖像數(shù)據(jù)。

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

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

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

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

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

由于ZigBee在物理層傳輸?shù)拿繋瑪?shù)據(jù)最大為127個(gè)字節(jié)［6］，且其中還包括應(yīng)用層、網(wǎng)絡(luò)層、MAC層、物理層的幀頭以及校驗(yàn)位，因此實(shí)際傳輸數(shù)據(jù)時(shí)，每幀數(shù)據(jù)只有約90個(gè)字節(jié)，本文則采用80個(gè)字節(jié)。由于幀頭要有兩個(gè)字節(jié)做應(yīng)答以確定幀的類型，因此，每幀傳輸?shù)挠行?shù)據(jù)為78位。當(dāng)兩個(gè)設(shè)備建立聯(lián)系并初始化串口后，設(shè)備將開始從串口讀取數(shù)據(jù)并將數(shù)據(jù)存入緩沖區(qū)中，當(dāng)數(shù)據(jù)達(dá)到80個(gè)字節(jié)或者是發(fā)送圖像數(shù)據(jù)最后剩余字節(jié)時(shí)，將數(shù)據(jù)發(fā)送到消息隊(duì)列，然后通過(guò)消息發(fā)送機(jī)制將這幀數(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；∥圖像編號(hào)

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

｝Image＿Block

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

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

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

static void rxCB （uint8port，uint8event）

｛

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

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

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

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

｝

if（events＆SEND＿DATA＿EVENT）

｛

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

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

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

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é)點(diǎn)信息數(shù)據(jù)發(fā)送函數(shù)

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

｝

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

3 上位機(jī)測(cè)試程序設(shè)計(jì)

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

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

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

圖6 PC端圖像采集界面

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

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

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

5 結(jié)論

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

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

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

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

［4］ 周立功.ARM＆WinCE實(shí)驗(yàn)與實(shí)踐—基于S3C2410［M］.北京:北京航空航天大學(xué)出版社 ，2007.

［5］ 王小強(qiáng)，歐陽(yáng)駿，黃寧淋.無(wú)線傳感器網(wǎng)絡(luò)設(shè)計(jì)與實(shí)現(xiàn)［M］.北京:化學(xué)工業(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.