裝備無(wú)線(xiàn)自動(dòng)跟蹤攝像頭的警用車(chē)輛支持系統

　　設計介紹

　　本項目有三個(gè)主要目標：首先，提高警用車(chē)輛上收集和解釋數據的能力。其次，在警察大隊與指揮中心之間實(shí)現實(shí)時(shí)的圖像傳送和信息共享。第三，通過(guò)使用 SoPC 的協(xié)調設計來(lái)考慮高性能和經(jīng)濟效率。

　　現有的警察大隊跟蹤系統的攝像頭是固定在車(chē)輛上，因此會(huì )出現在屏幕上丟失嫌疑車(chē)輛的問(wèn)題。本項目提供了一種自動(dòng)跟蹤解決方案，可以將嫌疑車(chē)輛始終鎖定在屏幕上。為了實(shí)現這一目標，我們實(shí)施了可以減輕光效應的自動(dòng)化臨界值計算方法。

　　我們制造了使用步進(jìn)馬達的云臺攝像頭（Pan-Tilt Camera），這種攝像頭可以左右上下移動(dòng)。為了實(shí)現馬達的快速響應，我們還設計了 FPGA 步進(jìn)馬達控制器。FPGA 步進(jìn)馬達控制器的響應時(shí)間比軟件控制器的響應時(shí)間短，因此，即使嫌疑車(chē)輛在快速移動(dòng)，它也可以幫助攝像頭將焦點(diǎn)一直放在嫌疑車(chē)輛上。

　　我們設計了自動(dòng)語(yǔ)音警報系統，該系統可以與跟蹤攝像頭同步運行。我們針對 MPEG 音頻播放實(shí)施了使用 Nios 自定義指令的硬件加速技術(shù)。因此，不需要為 MPEG 音頻解碼提供額外的解碼芯片。我們?yōu)樵?DE2 主板上運行的 WM8731DAC 開(kāi)發(fā)了 uClinux 音頻驅動(dòng)程序

　　我們還設計了 FPGA 合成式 OBD- II 接口，用于獲取車(chē)輛速度之類(lèi)的信息，以及從車(chē)輛控制系統 ECU 獲取故障狀態(tài)。OBD- II 接口可以測量相對速度，并可監控車(chē)輛狀態(tài)，因此它可以代替高成本的激光測量?jì)x器。我們通過(guò) libjpeg 和 Altera 的 C2H 編譯器設計了 JPEG 壓縮模塊，用于進(jìn)行圖像存儲和無(wú)線(xiàn)傳輸。

　　對于 Linux 系統上常用的 libjpeg，我們進(jìn)行了加速。利用 libjpeg 可以不必修改代碼就讓?xiě)贸绦蛱岣邏嚎s性能。此項目的另一個(gè)主要特色是快速的全球無(wú)線(xiàn) HSDPA 協(xié)作。收集到的實(shí)時(shí)數據和圖像信息可以從警察大隊傳送到指揮管制中心。

　　車(chē)內 FPGA 的適用性

　　警察大隊的支持系統是一個(gè)復雜的領(lǐng)域，需要對圖像、語(yǔ)音、通信和傳感器數據進(jìn)行處理。車(chē)輛的系統復雜性越來(lái)越強，因為所加載設備的數量也在逐漸增加。在 OBD 接口中，由于協(xié)議不同，不同的車(chē)輛必須使用不同的系統。FPGA 適合于這個(gè)領(lǐng)域，因為它擁有易用的重組功能和合成功能。

　　我們在 Quarters 和 Nios IDE 7.0 環(huán)境中開(kāi)發(fā)了 SoPC 系統。操作系統和應用程序是使用 GUN 工具實(shí)施的。使用 SoPC 可以方便地配置系統，uClinux 和 GUN 工具鏈可以提供相似的環(huán)境。

　　警用車(chē)輛中的需求

　　根據追蹤制度，追蹤車(chē)輛時(shí)必須在進(jìn)行追蹤時(shí)打開(kāi)警報和記錄設備，并且同時(shí)還要向命令控制中心報告。同時(shí)做幾件事情并不容易，因此需要采用自動(dòng)化的綜合解決方案。我們的項目可以提供解決這些問(wèn)題的解決方案。

　　圖 1：設計概念

 
 
　　功能描述

　　本部分將描述我們的設計所能提供的功能。

　　圖 2：云臺攝像頭模塊

 
　　自動(dòng)跟蹤攝像頭

　　要將目標車(chē)輛始終鎖定在屏幕中央，我們制造了一種可以垂直和水平移動(dòng)的攝像頭模塊。云臺攝像頭模塊的關(guān)鍵部分是響應時(shí)間。響應時(shí)間越短，目標車(chē)輛的丟失率就越低。

　　因此，我們選擇了硬件控制的方法，而不是軟件控制的方法。步進(jìn)馬達控制器是采用 Verilog HDL 開(kāi)發(fā)的。圖像處理模塊發(fā)出的云臺運動(dòng)命令會(huì )直接傳送到 FPGA 上的步進(jìn)馬達控制器。步進(jìn)馬達控制器隨即接收到這些命令，并生成操作信號脈沖。最后，控制器向每個(gè)馬達發(fā)送合適移動(dòng)距離的信號。

　　要進(jìn)入跟蹤模式，需要將攝像頭對準目標車(chē)輛，然后按下 DE2 上的按鈕。隨后，圖像處理模塊將提取目標車(chē)輛的平均色彩特征，并估計目標車(chē)輛的位置。只要車(chē)輛一移動(dòng)，云臺攝像頭就會(huì )跟蹤車(chē)輛。

　　捕獲的 640x400 圖像保存在 USB 存儲中，并同時(shí)傳送給指揮管制中心。自動(dòng)跟蹤攝像頭都經(jīng)過(guò)實(shí)際測試，大多數情況下的工作效果都很好。由于跟蹤算法的根據是色彩的差異，因此我們的跟蹤機制在夜晚時(shí)無(wú)效，在某些色彩上的識別能力較弱。

　　圖 3：道路實(shí)際跟蹤測試

 
 
　　圖 4：車(chē)內嵌入式系統的配置

 
　　自動(dòng)語(yǔ)音警報

　　自動(dòng)跟蹤攝像頭啟動(dòng)跟蹤模式時(shí)，就會(huì )運行自動(dòng)語(yǔ)音警報系統。這可以為車(chē)中的警察帶來(lái)便利。MPEG 音頻數據是通過(guò) Nios II 處理器的自定義指令播放的，無(wú)需任何額外的處理器。Nios II 處理器在 DE2 上以 100 MHz 的速度運行。

　　單片機可以播放 128Kbps 44.1KHz 的 MP3 單聲道音頻，無(wú)需加速。但是，該處理器還是需要減少其負載以便進(jìn)行多任務(wù)處理。因此，我們增加了一個(gè) 64 位倍增器，它可以將播放的能力提高大約 2.5 倍。

　　圖 5：圖像的捕獲、處理和傳輸示意圖

 
　　圖像捕獲模塊

　　攝像頭的模擬圖像信息會(huì )在 DE2 的單片機上轉化成 ITU656 標準的數字流。這種數字流有三種不同的用途：首先，用于控制自動(dòng)跟蹤攝像頭的上下左右移動(dòng)操作。其次，用于版本共享系統以及無(wú)線(xiàn)傳送的 JPEG 壓縮。最后，用于車(chē)內顯示。該圖像捕獲模塊可以在預處理時(shí)修改圖像大小、移除隔行掃描模式以及計算幀緩沖區內存地址。

　　圖 6：在實(shí)驗室中進(jìn)行的跟蹤算法測試

 
　　圖像處理模塊

　　攝像頭的自動(dòng)跟蹤功能需要用到移動(dòng)跟蹤算法。我們開(kāi)發(fā)了經(jīng)過(guò)調整的色彩跟蹤算法，可以很方便地應用于 FPGA。這種算法可以根據方向計算不斷變化的車(chē)輛色彩的平均值，并生成新的二進(jìn)制臨界值。

　　這種算法的設計目的是處理與 FPGA 電路中的顯示輸入模塊合成的線(xiàn)路單元，而無(wú)需進(jìn)行軟件處理。其結果是不再需要外部幀緩沖區內存。這種方法的主要優(yōu)勢就是提高性能。它可以每隔 1/30 秒就向馬達控制器傳送控制命令。

　　圖 7：JPEG 壓縮示意圖

 
　　uClinux 上 C2H 加速的 JPEG 壓縮

　　按 JPEG 標準進(jìn)行的圖像壓縮大小為 640x400。libjpeg 的前向式 DCT 函數被加速器取代；該加速器使用 C2H 編譯器開(kāi)發(fā)而成，可以在 uClinux 環(huán)境中進(jìn)行訪(fǎng)問(wèn)。將 C2H 加速器與 uClinux 結合起來(lái)非常重要，因為它要與其它任務(wù)同時(shí)運行。對 libjpeg（標準庫）進(jìn)行加速使我們可以無(wú)需增加額外的 DSP 芯片或任何常見(jiàn)的軟件就能獲得性能的提升。使用 libjpeg 的應用程序可以通過(guò)重新編譯提高壓縮性能，而不必修改任何代碼。
 
　　圖 8：DE2 擴展設備和 OBD-II 接口

 
　　自定義的 OBD-II 接口

　　車(chē)輛都有一個(gè)用于進(jìn)行系統管理的發(fā)動(dòng)機控制單元（ECU）。警用車(chē)輛上也有這樣的設備。對于新近制造的車(chē)輛來(lái)說(shuō)，ECU 是一個(gè)非常重要的組件，它的作用是將發(fā)動(dòng)機與各種電子控制部件結合起來(lái)。OBD-II 是一個(gè)接口，可以將計算機或診斷工具連接到 ECU 以便進(jìn)行車(chē)輛維護，它可以實(shí)現設備間的通信。

　　OBD 標準有很多種，具體取決于車(chē)輛的制造商。我們的項目所采用的是 ISO9141-2 國際標準。通過(guò) OBD- II，我們可以了解車(chē)輛的行駛速度、燃油狀態(tài)和車(chē)輛的故障情況。它的初始化過(guò)程為 5 波特，通信速度為 10.4k 波特。對于接收到的信息部分字節，必須進(jìn)行補充并將其發(fā)送到 ECU 進(jìn)行通信。在 SoPC 平臺上使用的是 UART 組件，因為它與串行通信類(lèi)似。

　　圖 9：捕獲圖像和 OBD-II 信息屏幕

 
 
　　性能參數

　　本部分將描述我們的設計所能提供的性能參數。

　　表 1 列出了在圖像處理模塊上發(fā)送控制信號，到步進(jìn)馬達上接收初始操作信號之間的時(shí)間間隔。該時(shí)間間隔是通過(guò)示波器測量得出的。通過(guò) GPIO 接口啟動(dòng)步進(jìn)馬達后，在軟件程序控制器中，Nios 處理器會(huì )接收中斷信號，并生成操作信號。

　　表 1：步進(jìn)馬達脈沖生成方法比較

　　汽車(chē)跟蹤攝像頭的速度主要取決于圖像處理性能。下面的表 2 顯示了基于不同平臺的每種跟蹤算法的測試幀速率。實(shí)際上，DE2 的幀速率接近 60 幀/秒，因為圖像處理模塊以隔行掃描模式運行；但是，我們根據有效幀的數量將其標記為 29 幀/秒。

　　表 2：跟蹤算法的性能比較

 
　　另一個(gè)結果是，C2H 加速的 libjpeg 的 DCT 函數可以實(shí)現 JPEG 的快速壓縮。640x400 的 24 位位圖經(jīng)過(guò)了 20 倍強壓縮以實(shí)現精確的測量。使用 C2H 編譯所顯示出來(lái)的性能比這種沒(méi)有加速器設計的性能要差。要解決此問(wèn)題，我們更改了緩沖區管理方法。在修改了 DCT 函數后，性能提升了四倍。

　　表 3：JPEG 壓縮算法的性能比較


 
　　表 4：uClinux 上的 USB HSDPA 調制解調器性能測試
 


　　我們在設計該系統時(shí)，考慮了在 uClinux 系統上使用 USB 調制解調器時(shí)的性能下降問(wèn)題。然而，事實(shí)顯示，網(wǎng)絡(luò )性能與在 PC 環(huán)境中運行的性能幾乎相同。

　　設計的體系結構

　　本部分描述我們系統的設計架構。

　　圖 10：系統的體系結構

 
　　整個(gè)系統由 uClinux 操作系統控制。包括圖像處理模塊在內的攝像頭控制系統和子系統由完整的 FPGA 組成。我們設計的自定義 SoPC 組件將隨我們項目的進(jìn)展被刷成深灰色。

 
　　圖 11：SoPC 配置

 
　　標準 JPEG 庫 libjpeg 的 DCT 函數被更改為 C2H 加速器。圖像處理模塊、VGA 控制器和步進(jìn)馬達控制器被組合成一個(gè)單獨的 SoPC 組件?？偣蚕牧?31000 LE。

　　圖 12：Quartus II 7.0 編譯報告

 
　　圖 13：系統頂層實(shí)體

 
　　圖 14：芯片配置和車(chē)內配置

 
　　設計描述

　　本部分將描述我們設計的實(shí)施方法和步驟。

　　組合 uClinux 和 C2H

　　使用操作系統可以靈活地在復雜的多設備環(huán)境系統中進(jìn)行開(kāi)發(fā)。uClinux 內核是適合于非 MMU 處理器的操作系統內核。由于 uClinux 系統中沒(méi)有內存管理單元，因此可以極大地簡(jiǎn)化基于 Nios 處理器對定制的硬件加速器進(jìn)行訪(fǎng)問(wèn)的應用程序的使用。

　　在 Nios IDE 環(huán)境中編寫(xiě)的代碼經(jīng)過(guò)很少的更改或無(wú)需更改即可在 uClinux 下的多任務(wù)環(huán)境中運行，因為在 uClinux 中對內存映射地址的寫(xiě)操作沒(méi)有限制。

　　我們可以通過(guò)常用的技術(shù)在 uClinux 上使用 C2H 加速器。在本部分，我們將詳細介紹將 C2H 加速器從 Nios IDE 移到 uClinux 上所需的步驟。

　　第一步是生成一個(gè)臨時(shí)項目。然后，在 Nios IDE 中編譯并生成加速器?，F在，我們可以在 Debug 目錄中看到加速器的打包函數。將這些頭文件（Header file）和打包函數復制到 uClinux 開(kāi)發(fā)目錄中。如果您尚未對 FPGA 編程，則進(jìn)行該項編程。

　　下一步是使用 Nios 的 gcc 工具和 elf2flt 選項編譯經(jīng)過(guò)加速的應用程序。確保必需的頭文件（如 system.h 或 io.h）存在。在完成此步驟后，將生成的執行文件復制到單片機上。在大多數情況下，它的速度會(huì )比僅使用軟件的系統要快。

　　可惜的是，我們在將 libjpeg DCT 函數轉換成加速器時(shí)面臨著(zhù)性能方面的問(wèn)題。我們將在接下來(lái)的部分介紹針對性能問(wèn)題的解決方案。

　　圖 15：將 C2H 加速器打包函數從 Nios IDE 移到 uClinux 上

 
　　圖 16：經(jīng)過(guò)優(yōu)化的 DCT 函數示意圖

 
　　優(yōu)化 C2H 編譯器的 JPEG 庫

　　一般情況下，開(kāi)發(fā)人員會(huì )考慮使用 DSP 進(jìn)行 JPEG 壓縮，但 DSP 需要有自己的軟件程序來(lái)提供支持。選擇可以加速 libjpeg 的 C2H 編譯器是一個(gè)正確的決定，因為許多現有應用程序都使用作為 JPEG 標準庫的 libjpeg。

　　但是，在使用 C2H 編譯器轉換原始的 DCT 函數時(shí)，它所顯示的性能比僅使用軟件的設計的性能低。從結構上來(lái)說(shuō)，對數據高速緩存的刷新是一個(gè)問(wèn)題，它的數據處理工作是以 64 個(gè)字節為單位進(jìn)行的。我們設計了適合于 C2H 編譯器的經(jīng)過(guò)優(yōu)化的緩沖區管理系統。這個(gè)管理器實(shí)現了 4 倍的性能提升。

　　創(chuàng )建自定義的 SoPC 組件

　　每個(gè)部件都由 VerilogHDL 單獨設計，并作為一個(gè)組件添加到 SoPC 中。圖像處理模塊、VGA 控制器和步進(jìn)馬達控制器被組合成一個(gè)單獨的 SoPC 組件，因為這些部件相互之間都有密切的關(guān)聯(lián)。這些組件作為 Avalon Master 的組件在 SRAM 上寫(xiě)入圖像數據。

　　圖 17：自定義的 SoPC 組件 


 
　　圖 18：使用 64 位乘法器的自定義指令

　　使用自定義指令對 MPEG 音頻進(jìn)行解碼

　　在使用 Nios II 處理器和 uClinux 的環(huán)境中播放 MPEG 音頻存在三個(gè)主要問(wèn)題：處理器性能、FIFO（先進(jìn)先出）的大小以及在 uClinux 中用于輸出的設備驅動(dòng)程序。

　　我們發(fā)現，100 MHz Nios II 處理器在 Cyclone II 芯片上對立體聲 128Kbps 44.1KHz MP3 音頻進(jìn)行解碼時(shí)會(huì )有性能損失。如果 FIFO 足夠大，則可以在該系統中播放單聲道音頻，但 CPU 會(huì )一直分配用于播放音頻的性能。

　　我們在 Nios 處理器上添加了使用自定義指令的 64 位乘法器以實(shí)現 64 位乘法計算；這種運算方法在 Libmad 庫中經(jīng)常用到。播放的性能提升了大約 2.5 倍，用于計算的時(shí)鐘使用率有所降低。

　　還有其它一些原因使音頻播放質(zhì)量不佳。首先是采樣率不好。其次是緩沖區大小不足。最后是多任務(wù)處理環(huán)境。圖 19 的配置可以解決這個(gè)問(wèn)題，音頻將參考使用 17 MHz 的時(shí)鐘。

 
　　圖 19：44.1 KHz MPEG 音頻的 DAC FIFO 設置


  
　　設計的功能

　　本部分將描述我們的設計所能提供的重要功能。

　　這個(gè)系統最吸引人的指標是其集成性。一個(gè) FPGA 芯片可以處理整個(gè)工作，如圖像處理、壓縮、傳送、MPEG 音頻解碼、步進(jìn)馬達控制和 OBD 通信等。每個(gè)組件都作為一個(gè) SoPC 組件添加，因此很容易在不同的項目中重復利用組件。

　　我們設計了設備驅動(dòng)程序，因此所有系統都可以在 uClinux 環(huán)境中運行。我們開(kāi)發(fā)了訪(fǎng)問(wèn)方法，這些方法可將 uClinux 應用程序與基于自定義指令和 C2H 技術(shù)的加速器關(guān)聯(lián)起來(lái)。軟件和硬件都實(shí)現了統一。

　　圖像處理的主要功能是使內存訪(fǎng)問(wèn)量達到最小。幀緩沖區內存僅用于 JPEG 壓縮，因為圖像處理是由線(xiàn)路單元實(shí)現的。因此，我們最終可以極大地節約 Avalon 總線(xiàn)的帶寬。

　　表 5：重要功能和相關(guān)模塊

 
　　結論

　　我們開(kāi)發(fā)并測試了代表著(zhù)遠程信息處理技術(shù)領(lǐng)域之一的警察大隊支持系統。我們開(kāi)發(fā)了自動(dòng)跟蹤攝像頭；該攝像頭可以追蹤常見(jiàn)的車(chē)輛，并將其一直鎖定在屏幕中央。我們設計了基于 FPGA 技術(shù)的 OBD 接口，用于了解車(chē)輛的狀態(tài)信息。我們開(kāi)發(fā)了可以通過(guò)全球無(wú)線(xiàn) HSDPA 模塊遠程驗證車(chē)輛圖像和狀態(tài)信息的遠程系統。

　　在啟動(dòng)此項目之前，我們在固定的硬件平臺上和資源有限的環(huán)境中進(jìn)行了設計。FPGA 是一項令人驚奇的技術(shù)，它可以輕松地更改設計的配置。即使存在軟件無(wú)法解決的性能問(wèn)題和困難，我們也可以通過(guò)修改硬件設計來(lái)獲得簡(jiǎn)單而有效的設計方法。特別是，FPGA 的優(yōu)勢是圖像處理領(lǐng)域最受歡迎的。

　　我們使用了 ALERA 的 C2H 技術(shù)進(jìn)行 JPEG 壓縮。通過(guò)測試當前使用最為廣泛的經(jīng)過(guò)加速的 libjpeg 的 DCT 函數，高性能得到了驗證。我們認為，可以將 C 程序轉換成 HDL 的 C2H 技術(shù)是改變軟件范例的一個(gè)重要推動(dòng)因素。我們通過(guò)利用 C2H 技術(shù)對 libjpeg 的 DCT 函數進(jìn)行加速來(lái)獲得高性能。C2H 還有一些需要解決的問(wèn)題，但我們預期它會(huì )對軟件到硬件轉換技術(shù)的發(fā)展作出貢獻。