在這裏插入圖片描述# 軟件架構
前文(參考鏈接1和2)中針對我們在整個項目中需要用到的一些技術進行了描述，現在我們說回到產品應用部分的流程，並梳理以下整個軟件架構。
整個軟件功能分三部分：圖像預處理、目標識別算法處理和識別結果可視化。
由於我們使用的主芯片是海思的Hi3516D，一款流媒體方案的SoC，所以本文會涉及一些關於海思的SDK的實現邏輯和流程，如果是沒有接觸過海思方案的讀者可能會有些疑惑。
圖像預處理
圖像預處理功能其實很簡單，分爲三步操作：
- 獲取相機前端視頻輸入，視頻輸入的分辨率爲1920 x 1080。
- 由於我們使用的Tiny YOLO V2的網絡，輸入層張量維度爲[416, 416, 3]，所以我們需要將圖像下采樣至416 x 416的分辨率。
- 將下采樣之後的圖像編碼成jpg格式。
下采樣和圖像編碼都不可能用軟件在ARM上面運行完成，因爲耗時比較大。所以我們通過SoC內部集成的ISS核和VSS核來進行處理。
下采樣部分，我們通過調用SDK來增加一條vpss channel，綁定到系統中的VI通道，該vpss channel的輸出分辨率即爲我們需要下采樣的目標分辨率 416 x 416，這樣使用硬件去處理的話可以根據相機的幀率達到實時效果。
編碼部分，我們新增一條VENC編碼通道，編碼格式爲JPEG，直接將下采樣使用的vpss channel 和這條VENC通道進行綁定。
這樣，軟件層面我們就可以從VENC中循環獲取預處理完成的JPG圖片，然後將圖片中的RGB數據送到算法模塊，進行算法處理即可。
算法處理
算法處理邏輯和流程前面兩篇博文已經提及過，所以這裏只需要將算法處理部分移植過來就可以了，處理時需要避免Movidius的device handle 和 計算圖graph handle重複創建，避免重複寫入相同的計算圖數據，以消除一些不必要的耗時。
結果可視化
這款相機原本有兩個程序，一個程序用於前端採集數據並將視頻流編碼爲H.264/H.265格式，另一個程序是獲取視頻流，然後通過live555封裝rtsp協議，以便PC端可以通過VLC或者其他支持rtsp協議的軟件工具查看適時視頻。
同樣，我們的軟件也會獨立於這兩個程序，作爲一個新的服務組件存在於系統之中，這樣降低了各個組件之間的耦合性。
要使算法結果可視化，我們需要在實時視頻流上面增加OSD，以便查看。所以我們需要調用海思SDK中的RGN功能，增加overlay和cover_ex兩種類型的RGN，一種用於顯示目標的類別標籤，另一種用於顯示目標的box。
以上，就是我們整個軟件的架構邏輯，整個流程也不算複雜。
效果分析
下面，我們看看初步調試出來的效果。
由於測試條件有限，目前我只能通過手機打開檢測圖片，然後將手機放置在鏡頭前面，讓程序去識別手機圖片中的目標信息。
實際上，這樣的操作方式對算法識別的準確率影響其實是很大的，如果因爲手機屏幕擺放角度造成光線反射量不同，導致畫面上曝光程度不一致，對效果的影響很大。
如下兩張圖，分別用來識別人和小汽車。
圖一
圖二
從圖一的效果來看，準確率和召回率都還基本滿足需求，但是檢測的座標有不太準確，會有一些偏差。圖二也是同樣的情況，部分結果中座標偏差較大。這個效果確實有待優化。
算法效率
算法效率方面，測試VPU的計算耗時爲90ms，也就是每秒能處理10幀左右，這個效率還是無法達到實時。
設備性能
相傳VPU的芯片功耗很低，但是在測試過程中，發現USB頻繁出現斷連的情況，算法運行一段時間之後，USB會就disconnect了，無論VPU連接PC機還是智能相機時都有這個問題。目前還沒找到故障原因。
總結
到目前爲止，項目整個功能就已經實現了，同時也實現了效果可視化。後面的工作就是對算法mAP的調優以及耗時方面的優化。力求達到一個不錯的效果。所以，博文的更新暫告一個段落，效果優化之後再更新後續內容。
參考鏈接
1、ARM+Movidius VPU 目標識別調試筆記（一）
2、ARM+Movidius VPU 目標識別調試筆記（二）
3、Movidius VPU移植ssd_mobilenet問題記錄