基于ARM的8通道視頻高速同步采集

胡躍輝　石珩臻　金韜　謝凌銳　康吳偉　方勇

摘要：多通道同步視頻采集技術(shù)在機(jī)器視覺領(lǐng)域有著重要的應(yīng)用，論文給出了一種基于全志H5的8通道視頻同步采集設(shè)計(jì)和實(shí)現(xiàn)，結(jié)果表明，這種設(shè)計(jì)能夠以不超過10微秒的同步延遲，實(shí)現(xiàn)約90幀/秒的640X480彩色視頻的8通道高速采集，具有性價(jià)比高、實(shí)現(xiàn)簡(jiǎn)單、外設(shè)接口豐富且具備一定的視頻數(shù)據(jù)后處理能力的特點(diǎn)。

關(guān)鍵詞：多通道同步視頻采集；嵌入式操作系統(tǒng)；UVC攝像頭；GPIO

中圖分類號(hào)： TP391 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2018）18-0020-04

High Speed Synchronous Acquisition of 8 Channel Video Based on ARM

HU Yao-hui1，SHI Heng-zhen1，2，JIN Tao1，2，XIE Ling-rui1，3，KANG Wu-wei1，2，F(xiàn)ANG Yong1

（1.Academy of Photoelectric Technology，Hefei University of Technology，Hefei 230009，China； 2.School of Computer & Information， Hefei University of Technology，Hefei 230009，China； 3.School of Instrument Science & Opto-electronics Engineering， Hefei University of Technology，Hefei 230009，China）

Abstract： Multi channel synchronous video acquisition technology has an important application in the field of machine vision. The design scheme and implementation of 8 channel video synchronization acquisition based on ALLWINNER H5 were presented in this paper. The result shows that the design can achieve 8 channels high speed acquisition of 640X480 color video at a rate of about 90 fps， with a synchronization delay less than 10 microseconds. It has the characteristics of high cost performance， simple implementation， rich peripheral interface and certain post-processing ability of video data.

Key words： multi-channel synchronous video acquisition； embedded operating system； UVC camera； GPIO

1 引言

為了實(shí)現(xiàn)基于視覺的實(shí)時(shí)目標(biāo)的三維重建及復(fù)現(xiàn)[1]，絕大多數(shù)情況下都需要對(duì)目標(biāo)進(jìn)行多個(gè)不同方位的視頻采集。如果條件允許，則設(shè)置的圖像傳感器越多，同步采集的速率越快，則目標(biāo)三維重建時(shí)的所能達(dá)到的精度才可能越高。

本文介紹了一種8通道的同步實(shí)時(shí)視頻采集子系統(tǒng)，該系統(tǒng)作為實(shí)時(shí)視頻源應(yīng)用在一個(gè)8視點(diǎn)柱鏡式立體顯示系統(tǒng)中。該采集系統(tǒng)要求實(shí)現(xiàn)以不低于60FPS（frame per second FPS 幀/秒）VGA（640X480）高速同步采集，同時(shí)還要具有成本低、便攜性好、現(xiàn)場(chǎng)容易配置和部署的特點(diǎn)。

2 設(shè)計(jì)

2.1圖像傳感器及接口總線

圖像傳感器模組的接口總線[2-3]可以大致分為兩類，一類是專用總線CSI，一類是通用總線比如UVC（USB video class）。

采用專用總線的圖像采集系統(tǒng)，采集速度最快，能夠充分挖掘出圖像傳感器本身的全部性能，但是往往具有總線長(zhǎng)度太短，不適合長(zhǎng)距離現(xiàn)場(chǎng)部署，以及兼容性差，需要專門設(shè)計(jì)，移植性不好的缺點(diǎn)。

采用通用總線，則有可能受限于總線的帶寬，并且要和總線上其他的設(shè)備競(jìng)爭(zhēng)帶寬資源，所以每秒采集的像素點(diǎn)數(shù)是受限的，并且多個(gè)設(shè)備特別是同類設(shè)備同時(shí)接入的人情況下，同步性難以預(yù)測(cè)和控制。

通過上述討論分析，我們選擇了支持UVC協(xié)議的基于USB總線的圖像傳感器模塊（以下稱攝像頭），以便實(shí)現(xiàn)低成本、便于現(xiàn)場(chǎng)部署和配置的要求，同時(shí)省略了專門總線設(shè)計(jì)從而還解決了兼容性、移植性的問題。攝像頭的圖像傳感器芯片為OV2710[4]，這是一款獲得廣泛應(yīng)用的高速CMOS廉價(jià)彩色圖像傳感器，理論上在VGA模式下具有120FPS的采集速率。

但是，受限于攝像頭的圖像處理芯片及方案，不一定能夠?qū)崿F(xiàn)圖像傳感器數(shù)據(jù)手冊(cè)中的全部功能和模式，所能實(shí)現(xiàn)的采集模式需要進(jìn)行實(shí)際測(cè)試才能確定。比如我們所采用的這款基于OV2710的攝像頭，在VGA下可以實(shí)現(xiàn)的模式為120FPS@MJPEG，或60FPS@YUV422。另外，后期實(shí)測(cè)表明，在較低速度的YUV模式下，其圖像質(zhì)量明顯比MJPEG編碼模式要好。

2.2處理機(jī)及操作系統(tǒng)

當(dāng)確定攝像頭采用UVC協(xié)議之后，由于各大主流操作系統(tǒng)均提供了設(shè)備驅(qū)動(dòng)支持，包括微軟操作系統(tǒng)、Linux操作系統(tǒng)、Mac OS和Android等等，所以平臺(tái)兼容性是非常好的，UVC攝像頭甚至因此被稱為“免驅(qū)攝像頭”。

但是，盡管目前UVC1.5協(xié)議已支持到USB3.0總線，但目前廉價(jià)的UVC攝像頭大都還是只支持到USB2.0，所以只要是所有的攝像頭最終都連接在一個(gè)USB HOST上再進(jìn)入主機(jī)進(jìn)行處理，則在考慮到USB2.0的實(shí)際運(yùn)行有效總線帶寬和各掛載USB設(shè)備帶寬競(jìng)爭(zhēng)的情況下，目前支持到2路 VGA@100FPS采集就已經(jīng)是非常不錯(cuò)了，但遠(yuǎn)遠(yuǎn)不能滿足我們系統(tǒng)所要求的8路采集要求。

所以我們采用了ARM+攝像頭的結(jié)構(gòu)方式來實(shí)現(xiàn)每一路視頻采集，這里的ARM為基于全志H5（64位，4核Cortex A53）的廉價(jià)開發(fā)板NanoPi NEO Plus2（長(zhǎng)X寬=52mmX40mm，以下簡(jiǎn)稱NEO+2）[5]，主要技術(shù)參數(shù)為1GB DDR3 RAM、8GB eMMC、USB2.0X3、千兆以太有線網(wǎng)口X1以及WIFI和藍(lán)牙等模塊各一。相比購(gòu)買IP攝像頭來實(shí)現(xiàn)每一路圖像采集通道，自行配置的ARM+攝像頭，本身就可以作為處理器進(jìn)行更為自由的視頻后處理工作。

進(jìn)一步的，我們采用了開源操作系統(tǒng)Ubuntu來運(yùn)行視頻采集系統(tǒng)，實(shí)驗(yàn)中采用了每塊H5開發(fā)板各配置一個(gè)攝像頭的方式。這是因?yàn)?，雖然如前所述，在USB 2.0總線下可以支持2路 100FPS@VGA，但是未來如果分辨率從VGA提升到1024X768，甚至更高，則存在實(shí)際傳輸帶寬不能滿足的可能性；并且，視頻采集同時(shí)都伴隨著海量視頻圖像實(shí)時(shí)處理任務(wù)，單板對(duì)單路視頻采集算力更為充裕，對(duì)于NEO+2而言，也是非常廉價(jià)的。

此外，采用Ubuntu系統(tǒng)不僅可以支持上述H5視頻采集子系統(tǒng)的并行協(xié)同計(jì)算，對(duì)于采用Linux系統(tǒng)的上位機(jī)，也可以同樣支持異構(gòu)協(xié)同計(jì)算[6-7]。這里的各子系統(tǒng)的互聯(lián)互通可以基于千兆網(wǎng)或者無線協(xié)議，NEO+2也都是直接支持的。

2.3同步設(shè)計(jì)

不采用IP攝像頭的方式的另一個(gè)主要原因是以太網(wǎng)的網(wǎng)絡(luò)延遲問題，這個(gè)延遲量不僅是隨機(jī)的，而且平均值也在1ms以上，廉價(jià)的解決方案幾乎無可能降低到1ms以下。所以如果可能的話，還是盡量避免采用IP方式來同步各互聯(lián)采集通道。

采用ARM+攝像頭的方式，則可以利用開發(fā)板上GPIO端口資源，來實(shí)現(xiàn)硬件觸發(fā)同步，從而實(shí)現(xiàn)微秒級(jí)的同步。

當(dāng)需要同步的攝像頭是8個(gè)時(shí)，可以將一路攝像頭所在的NEO+2 開發(fā)板設(shè)為主機(jī)Host，另外7路設(shè)為從機(jī)Slavei（i=0，1，…，6）。如果設(shè)置一個(gè)信號(hào)線為命令線CMDline，從Host輸出連接至各從機(jī)，再設(shè)置一根信號(hào)線為狀態(tài)線STATline，由各從機(jī)發(fā)出由Host接收，則通過設(shè)計(jì)并實(shí)現(xiàn)主從機(jī)之間命令線、狀態(tài)線的交互時(shí)序，就可以實(shí)現(xiàn)同步的視頻采集。

3 實(shí)現(xiàn)

3.1同步總線

NEO+2 提供了WiringPi函數(shù)庫[5]，可以很方便地實(shí)現(xiàn)對(duì)GPIO的操作訪問，在root模式下，利用gpio readall 命令就可以獲得可用的如圖1（a）所示的 GPIO端口列表。參考圖1（a）及文獻(xiàn)[5]，可以得到符合上述總線要求的一種配置如圖1（b）所示，圖1（b）中Out表示對(duì)應(yīng)的GPIO管腳被設(shè)置為輸出信號(hào)，In則表示設(shè)置為輸入信號(hào)。

圖2給出了主從機(jī)狀態(tài)線、命令線的時(shí)序邏輯。由于各采集通道異步運(yùn)行，所以在啟動(dòng)后進(jìn)入循環(huán)前首先需要進(jìn)行等待以便完成首次同步，即主機(jī)啟動(dòng)后命令線置高，各從機(jī)啟動(dòng)后狀態(tài)線置低，主機(jī)檢測(cè)到所有從機(jī)狀態(tài)線均為低之后，置命令線為低，而后再進(jìn)入采集同步循環(huán)。

從機(jī)在檢測(cè)到主機(jī)命令線為低之后，開始進(jìn)行一幀圖像的同步采集和處理，處理完畢后設(shè)置狀態(tài)線為高，并等待命令線由低變高。主機(jī)在完成一幀圖像的采集和處理之后設(shè)置命令線為高，然后進(jìn)行狀態(tài)線檢測(cè)，如此循環(huán)，直至按照要求完成視頻采集和處理任務(wù)。

3.2高速采集

如前所述可知，在Ubuntu下UVC攝像頭的開發(fā)是基于V4L（video for linux）框架的USB攝像頭來實(shí)現(xiàn)的，目前采用的V4l2則是V4l的改進(jìn)版本，這個(gè)版本克服了早期V4l版本的很多缺陷，不僅向前兼容V4l，而且還支持更多的硬件設(shè)備。相關(guān)V4l開發(fā)的文獻(xiàn)有很多[8-10]，這里就不再贅述，為了捕獲程序的可靠高速運(yùn)行，我們需要注意以下幾個(gè)方面問題：

1）利用open函數(shù)打開設(shè)備fd時(shí)，需要設(shè)置為非阻塞工作模式即應(yīng)包含O_NONBLOCK參數(shù)。

2）捕獲數(shù)據(jù)的訪問方式應(yīng)采用MMAP方式即內(nèi)存映射模式。

3）對(duì)設(shè)備fd，建議采用select函數(shù)實(shí)現(xiàn)非阻塞監(jiān)聽模式。

上述三個(gè)方面可以很大程度上避免對(duì)攝像頭訪問因各種原因造成的死機(jī)阻塞現(xiàn)象。

4 結(jié)果與討論

圖3（a）為本文所用搭建的8個(gè)NEO+2 ARM處理器陣列，用于實(shí)現(xiàn)8通道視頻同步采集與處理，其中1元硬幣作為尺寸參照物，ARM的操作系統(tǒng)為Ubuntu16.04，同步信號(hào)利用GPIO實(shí)現(xiàn)。圖3（b）為基于OV2710的8攝像頭陣列，采用USB2.0接口和分別與對(duì)應(yīng)的處理器陣列相連接，目標(biāo)為仿真半身塑膠人像。所選UVC協(xié)議攝像頭，在VGA模式下，具有120FPS@MJPEG的標(biāo)稱采樣速度。

首先利用V4L實(shí)現(xiàn)了單通道的120FPS@MJPEG VGA視頻的捕獲，連續(xù)采集100幀（不做其他任務(wù)）時(shí)獲得實(shí)際采集速率為98.7FPS，結(jié)果可以接受。

然后利用示波器觀察測(cè)量了最快情況下的GPIO讀寫操作，讀寫操作利用WiringPi實(shí)現(xiàn)，測(cè)量結(jié)果表明利用WiringPi實(shí)現(xiàn)的GPIO的信號(hào)轉(zhuǎn)換速度不超過1微秒。結(jié)合圖2可以看出，在進(jìn)入循環(huán)周期之后，每個(gè)周期需要的狀態(tài)翻轉(zhuǎn)次數(shù)最多為3次，因此同步信號(hào)引發(fā)的同步延遲僅為3微秒以內(nèi)。其他的延遲可以認(rèn)為都來自各通道的各自采集周期的時(shí)間上差異性。

最后，測(cè)試了連續(xù)1000幀同步條件下8通道采集實(shí)驗(yàn)，采集參數(shù)為120FPS@MJPEG VGA，在采集數(shù)據(jù)不做轉(zhuǎn)儲(chǔ)的條件下，同步采集速度達(dá)到了91.7FPS，如圖4所示，圖中上半部的紅框部分為運(yùn)行的攝像頭及系統(tǒng)的基本狀態(tài)。下半部黃框部分為運(yùn)行統(tǒng)計(jì)結(jié)果，可以看到，進(jìn)入同步狀態(tài)需要一定的時(shí)間，不到2秒。

相比I2C（Inter-Integrated Circuit 集成電路總線）等總線方式的同步，這種方式顯然也具有一定的不足性，這是因?yàn)楸痉桨笇?shí)際上是采用硬件總線握手方式（利用GPIO）來實(shí)現(xiàn)的，因?yàn)橹挥?根總線（指主機(jī)和單個(gè)從機(jī)之間），所以對(duì)更復(fù)雜一些運(yùn)行機(jī)制缺乏足夠的協(xié)議支持。

而I2C總線雖然表現(xiàn)為硬件總線方式通訊，但是實(shí)際上卻可以建立起足夠的命令寄存器、狀態(tài)寄存器，實(shí)現(xiàn)完備的軟件同步通訊協(xié)議，從而可靠的完成高速同步任務(wù)，但I(xiàn)2C從模式驅(qū)動(dòng)需要自行實(shí)現(xiàn)，開發(fā)難度相對(duì)較大。并且如果是基于寄存器方式實(shí)現(xiàn)同步，即使是命令和狀態(tài)寄存器各為8位寄存器，由于是串行通信，最少需要16個(gè)時(shí)鐘周期（指GPIO平均讀寫周期，約1微秒），才能完成一次數(shù)據(jù)通訊（8位地址+8位寄存器）。

所以，如果是8通道情況即每通道都有一個(gè)8同步寄存器，則完成1次同步信息交互最少需要16*8=128個(gè)時(shí)鐘周期，相比本文方案的最多需要3個(gè)時(shí)鐘周期3微秒，I2C方案的同步開銷要在130微秒以上。

因此，從開發(fā)難度和同步延遲而言，本文方案仍然相較I2C為優(yōu)。而且試驗(yàn)也表明，這種GPIO信號(hào)線硬同步方式，穩(wěn)定性也是很好的，整個(gè)試驗(yàn)過程中未發(fā)現(xiàn)同步故障，能夠滿足短時(shí)應(yīng)用要求。

5 結(jié)論

本文討論了一種便于實(shí)現(xiàn)的廉價(jià)高速同步高速視頻采集方案，該方案基于UVC攝像頭及NEO+2 開發(fā)板，實(shí)現(xiàn)了90FPS以上同步視頻采集（@VGA）。方案所選取的NEO+2本身具有的64位多核處理能力和豐富外設(shè)接口，可以滿足需要采用多通道高速視頻采集系統(tǒng)的現(xiàn)場(chǎng)應(yīng)用和工程評(píng)估場(chǎng)合，特別是對(duì)機(jī)器視覺和三維重建研究。利用類似的方案，特別適合于需要快捷實(shí)現(xiàn)高速多通道同步視頻采集系統(tǒng)搭建和配置，而不需要了解更多的設(shè)備驅(qū)動(dòng)細(xì)節(jié)，從而使得工程研究人員更加聚焦視覺算法本身研究的場(chǎng)合。

參考文獻(xiàn)：

[1] 佟帥，徐曉剛，易成濤，邵承永.基于視覺的三維重建技術(shù)綜述[J].計(jì)算機(jī)應(yīng)用研究， 2011，28（07）：2411-2417.

[2] MIPI Alliance， Inc. MIPI Alliance Specification for Camera Serial Interface 2[EB/OL]. [2009-12-15].https：//www.mipi.org.

[3] USB-IF. USB Device Class Definition for Video Devices，Revision1.5 [EB/OL]. [2012-08-09]. https：//www.usb.org/developers/docs/devclass_docs.

[4] Omni Vision Technologies Inc.. OV2710數(shù)據(jù)手冊(cè)，version 2.03[EB/OL].[2011-04-06]. https：//wenku.baidu.com/view/9072d680770bf78a652954d4.html.

[5] FriendlyARM. NanoPi NEO Plus2， [EB/OL]. [2018-04-24].http：//wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Plus2.

[6] 盧風(fēng)順， 宋君強(qiáng)， 銀?？?，等. CPU/GPU協(xié)同并行計(jì)算研究綜述[J]. 計(jì)算機(jī)科學(xué)， 2011， 38（3）：5-9.

[7] 楊洪余， 李成明， 王小平，等. CPU/GPU異構(gòu)環(huán)境下圖像協(xié)同并行處理模型[J]. 集成技術(shù)， 2017， 6（5）：8-18.

[8] 涂繼輝， 余厚全， 佘新平. 基于ARM的視頻監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J]. 長(zhǎng)江大學(xué)學(xué)報(bào)（自科版）， 2010， 07（2）：89-91.

[9]王元偉， 劉國(guó)秀. 基于V4L的視頻采集系統(tǒng)的設(shè)計(jì)[J]. 鐵路計(jì) 算機(jī)應(yīng)用， 2010， 19（7）：30-34.

[10] Mei D. Web Camera Design Based On Embedded Linux[J]. Microcomputer Information， 2007.