Xiraffe桅桿上的智能野生動物觀測站

cd ~/IVAS_TRD/Vitis-In-Depth-Tutorial/Runtime_and_System_Optimization/Design_Tutorials/02-ivas-ml
cd hw_src/Vitis_Libraries

patch -p1 < ../vision_lib_area_resize_ii_fix.patch

然后構建設計

cd ../..
cd hw_src
make

此時，我意識到我需要先安裝 Vitis-AI 庫，然后再繼續。為此，我需要先安裝 petalinux。對于 petalinux，我從這篇文章中獲得了指導，并立即安裝了它。

之后，我按照此頁面上的說明安裝了 Vitis-AI 。

制作安裝目錄

mkdir ~/petalinux_sdk

之后，下載安裝腳本（sdk-2020.1.0.0.sh）并執行

./sdk-2020.1.0.0.sh

出現提示時，我按照頁面上的說明提供了以下安裝路徑：~/petalinux_sdk

完成后，獲取腳本

source ~/petalinux_sdk/environment-setup-aarch64-xilinx-linux

下載 Vitis-AI 壓縮文件并解壓

tar -xzvf vitis_ai_2020.1-r1.2.0.tar.gz -C ~/petalinux_sdk/sysroots/aarch64-xilinx-linux

在這個階段，Vitis-AI 庫已經建立。盡管 IVAS 設計不需要，但我繼續執行頁面上的其余說明以嘗試示例。

現在，我需要安裝 Vitis-AI docker 容器才能編譯 densebox 和 reid 模型。要安裝這些，我按照這里的簡單步驟進行操作，沒有任何問題（我使用了預構建的 docker 映像）。我還在這里找到了 Vitis-AI v1.2 的一些很好的資源，這些資源在接下來的幾天里非常有用。

要下載 AI 模型，我從AI 模型動物園下載了模型

為了編譯，我遵循了 Vitis-AI 指南。比如densebox模型，從model zoo下載模型，解壓到~/Vitis-AI/AI-Model-Zoo/models/（其實也可以放到別的地方）。接下來，切換到 quantized/edge 目錄

cd ~/Vitis-AI/AI-Model-Zoo/models/cf_densebox_wider_360_640_1.11G_1.2/quantized/Edge

現在，運行 docker 鏡像，激活 conda 環境并編譯模型

. ~/Vitis-AI/docker_run.sh xilinx/vitis-ai:latest

conda activate vitis-ai-caffe

vai_c_caffe --prototxt ./deploy.prototxt --caffemodel ./deploy.caffemodel --arch /opt/vitis_ai/compiler/arch/DPUCZDX8G/ZCU104/arch.json --output_dir compiled_model --net_name densebox_640_360

編譯后的.elf 文件將位于“compiled_model 文件夾”下。請注意，我能夠成功編譯 tensorflow 模型，但對 Caffe 模型沒有同樣的運氣。我在這里和這里尋求幫助。出于IVAS 的目的，Xilinx 工程師非常友好地為我提供了模型編譯后的 elf 文件，以便我繼續前進。

為此，我從一個全新的終端（賽靈思強烈推薦）開始，并獲取了環境設置腳本

cd ~/IVAS_TRD/Vitis-In-Depth-Tutorial/Runtime_and_System_Optimization/Design_Tutorials/02-ivas-ml/platform/repo/xilinx_zcu104_vcu_202010_1/sysroot
source ./environment-setup-aarch64-xilinx-linux

接下來，我在適當的地方做了一個目錄

cd ~/IVAS_TRD/Vitis-In-Depth-Tutorial/Runtime_and_System_Optimization/Design_Tutorials/02-ivas-ml/

mkdir ml_models

然后將兩個elf文件復制到ml_models文件夾中。現在我需要做的就是運行最終的腳本來執行魔法并創建 SD 卡映像：

./go.sh

一旦完成而沒有錯誤，我使用etcher將以下位置的圖像刻錄到sdcard：hw_src/sd_card_zcu104/sd_card.img

在此之后，我按照此處的最后幾個步驟直到頁面結束，并且最終能夠運行示例應用程序。

我說“最終”是因為這對我來說并不順利，事實上我花了整整 2 天的時間才弄清楚。最初我嘗試運行應用程序，但屏幕上什么也沒有顯示。我開始進行故障排除并閱讀。讓 DisplayPort 輸出正常工作的一個非常有用的資源是DP Linux 驅動程序頁面，其中包含有關顯示端口 DRM 驅動程序的大量信息。

我發現的一件事是我的顯示器的分辨率為 2560x1440，要在屏幕上看到輸出，發送到顯示器的圖像/視頻必須是完全相同的分辨率。經過大量閱讀和嘗試不同的事情后，我找到了將分辨率設置為 1920x1080 的解決方法，但它也啟動了測試模式生成器（42 是來自 modetest -m xlnx 的連接器的 id）

modetest -M xlnx -s 42:1920x1080@RG16 &

接下來，為了解決測試模式的問題，我將終端層的不透明度設置為零

modetest -M xlnx -w 39:alpha:0

這樣做的副作用是終端層會消失，但這不是問題，因為無論如何我都是通過串行 uart 登錄到板子的，并且對視頻本身更感興趣。現在，我可以成功運行 1920x1080 分辨率的輸出，我使用以下 gstreamer 管道使用視頻測試源對其進行了測試：

gst-launch-1.0 videotestsrc ! "video/x-raw, width=1920, height=1080" ! queue ! videoscale ! "video/x-raw, width=2560, height=1440" ! queue ! kmssink driver-name=xlnx sync=false

請注意，autovideosink 也適用于 kmssink 驅動程序

gst-launch-1.0 videotestsrc ! "video/x-raw, width=1920, height=1080, format=YUY2" ! queue ! autovideosink sync=false

在此之后，我設法從屏幕上顯示的 USB3 攝像頭獲取實時視頻：

gst-launch-1.0 v4l2src device=/dev/video0 ! "video/x-raw, width=1920, height=1080" ! videoconvert ! queue ! autovideosink

最后，我可以運行 IVAS 演示應用程序：

gst-launch-1.0 -v \
	filesrc location=/home/root/videos/dahua2.mp4 ! \
	qtdemux ! \
	h264parse ! \
	omxh264dec internal-entropy-buffers=3 !  \
	tee name=t0 t0.src_0 ! \
		queue ! \
		ivas_xm2m kconfig="/home/root/jsons/kernel_resize_bgr.json" ! \
		ivas_xfilter kernels-config="/home/root/jsons/kernel_densebox_640_360.json" ! \
		scalem0.sink_master ivas_xmetaaffixer name=scalem0 scalem0.src_master ! \
		fakesink \
	t0.src_1 ! \
		scalem0.sink_slave_0 scalem0.src_slave_0 ! \
		queue ! \
		ivas_xfilter kernels-config="/home/root/jsons/kernel_crop.json" ! \
		ivas_xfilter kernels-config="/home/root/jsons/kernel_reid.json" ! \
		ivas_xfilter kernels-config="/home/root/jsons/kernel_swbbox.json" ! \
		queue ! kmssink driver-name=xlnx sync=false

獎勵：要使用任何管道顯示 fps，您可以將最后一個元素更改為： fpsdisplaysink sync=false text-overlay=true fullscreen-overlay=1

例如，在以下管道中，我設法讓相同的應用程序處理實時視頻：

gst-launch-1.0 -v v4l2src device=/dev/video0 io-mode=dmabuf ! "video/x-raw, width=1920, height=1080" ! videoconvert ! video/x-raw,format=NV12 ! tee name=t0 \
	 t0.src_0 ! \
		queue ! \
		ivas_xm2m kconfig="/home/root/jsons/kernel_resize_bgr.json" ! \
		ivas_xfilter kernels-config="/home/root/jsons/kernel_densebox_640_360.json" ! \
		scalem0.sink_master ivas_xmetaaffixer name=scalem0 scalem0.src_master ! \
		fakesink \
	t0.src_1 ! \
		scalem0.sink_slave_0 scalem0.src_slave_0 ! \
		queue ! \
		ivas_xfilter kernels-config="/home/root/jsons/kernel_crop.json" ! \
		ivas_xfilter kernels-config="/home/root/jsons/kernel_reid.json" ! \
		ivas_xfilter kernels-config="/home/root/jsons/kernel_swbbox.json" ! \
		queue ! fpsdisplaysink video-sink="kmssink driver-name=xlnx" sync=false text-overlay=true

重要提示：對于所有管道，在使用 kmssink（xilinx DRM 驅動程序）時，確保最后一個元素的視頻與顯示器上設置的分辨率相同非常重要！

VideoCompression：此時，我使用 gstreamer 在 VPU 中的視頻解碼工作正常，并且還想嘗試視頻編碼。這是我遇到障礙的地方。我已經在Xilinx 論壇上寫過它。我需要進一步調查。

你可以用我能想到的最簡單的編解碼管道來試試

gst-launch-1.0 videotestsrc ! "video/x-raw, width=1920, height=1080" ! omxh264enc ! h264parse ! omxh264dec ! queue max-size-bytes=0 ! autovideosink

此時，我想知道如何將 VPU 集成到我的 C++/python 應用程序中，最終我想出了一個非常簡單的方法：在我的應用程序中使用 gstreamer。

例如，要使用 VCU 解碼 H.264/265 文件或 RTSP 流，請在 opencv 應用程序中使用以下管道（為清楚起見已簡化）：

<壓縮文件/流源> ! omxh264dec ！應用程序rc

要從應用程序中編碼（壓縮）視頻幀，請使用以下（簡化的）gstreamer 管道將它們發送到 VCU：

應用程序！omxh264enc !....

您可以通過查看此處的代碼以及我的項目 github頁面上的 C++ 文件來了解更多信息。希望能幫助到你！

把這一切放在一起

現在我已經弄清楚并測試了所有的組成部分，并且距離提交截止日期還有幾天，我開始將這些部分放在一起。

我制定了一個構建我的應用程序的計劃，如下所示：- 在 python 中構建主應用程序，在 IVAS 參考設計圖像之上運行- 使用帶有“appsink”元素的 gstreamer 管道將視頻帶入 OpenCV 域。這樣，視頻可以在來自攝像機的實時視頻<或>來自文件或 RTSP 流的壓縮視頻之間快速切換，由 VPU 解碼（使用 gstreamer 管道中的 omxh264dec 元素）。- 在 opencv-python 中預處理視頻幀- 使用與 DPU 對話的 Vitis-AI python 綁定——對數據和視頻幀進行后處理。使用opencv生成覆蓋圖形-使用gstreamer管道使用“appsink”元素顯示帶有覆蓋圖形的幀，并使用“kmssink”元素發送到displayPort。-此外，使用gstreamer“tee” 管道中的元素使用“omxh264enc”元素將此最終圖像發送到 VPU，并作為 RTSP 流發送到 UDP 接收器。盡管在這方面我的編碼器驅動程序出現了問題，如前所述，并且在這里。

由于 IVAS 示例純粹是在 gstreamer 中，DPU 處理部分也構建為 gstreamer 管道，這對我來說不是很有用。我通過查看 C++ 示例開始在 python 中編寫我的應用程序，這花了我很多時間，而且我在后處理 DPU 數據方面遇到了很多問題（您必須執行幾個操作來確定邊界框的位置，例如例子）。值得慶幸的是，我在Avnet 的 Mario Bergeron 上找到了一個類似的優秀示例。由于后處理（確定邊界框的位置）是相同的，我使用了他的代碼作為起點并將其修改為使用 gstreamer 輸入，使用為 zcu104 編譯的密集盒模型進行處理，并使用 gstreamer 輸出到 displayport。很高興終于可以正常工作，如下面的視頻剪輯所示：

請注意，在此視頻中，我通過 gstreamer 管道使用來自攝像機的實時視頻。相機安裝了 35 毫米鏡頭，指向我的手機屏幕，播放來自 YouTube 的隨機視頻，里面有人物。運行的代碼和說明可以在我的 github 鏈接上找到。

進入下一步，因為我實際上需要一個對象檢測器而不是人臉檢測器，所以我開始修改代碼以使用 SSD 對象檢測器。嘗試運行代碼時，我的應用程序會掛起（并超時）等待 DPU。最初我懷疑我的應用程序存在問題，因此我查看了示例以使用相同的對象檢測器找到合適的示例。我從 Xilinx 找到了一個使用相同 SSD 模型的 VART 示例，盡管它是用 C++ 編寫的。原始代碼使用原始（webm）文件進行輸入，因此我將其修改為使用 gstreamer 輸入和輸出，如源代碼文件開頭所示：

VideoCapture cap("v4l2src device=/dev/video0 io-mode=dmabuf ! video/x-raw, width=1920, height=1080, format=UYVY ! videoconvert ! appsink", CAP_GSTREAMER);

VideoWriter writer("appsrc ! queue ! autovideosink sync=false",
		0,		// fourcc 
		30,		// fps
		Size(1920, 1080), 
		true);	// isColor

我首先使用運行良好的 gstreamer 管道測試了我的輸入和輸出，然后開始修改其余代碼以使用 gstreamer 數據而不是視頻幀中的幀。然而此時，在編譯并運行應用程序后，我發現它也在等待 DPU 響應。在論壇搜索之后，我能想到的唯一可能的問題是，我使用的 model.elf 文件可能是針對與我的 IVAS 設計的 DPU 不同的 DPU 架構編譯的。所以我開始從模型動物園下載模型并嘗試在我的主機上重新編譯它。這也是我之前在使用 Caffee 模型時遇到的一些問題的地方。我已經發布了在論壇上尋求幫助并等待回復。考慮到那里可能存在版本控制問題，我嘗試運行量化，但也遇到了一些問題，我主要歸咎于我目前使用 AI 模型的有限經驗。我修改后的代碼可以在我的 github頁面上找到。

距離提交截止日期還有一天，我決定在這里暫停一下，并在 hackster 上完成項目進度的記錄。

未來的計劃

由于我的想法與一個實際項目有關，我希望繼續努力，希望也能在其他項目中重用這些知識。一些要點：
- 通過模型編譯和測試完整系統來解決問題。
- 更深入地研究 AI 模型的技術細節，尤其是在后處理方面
- 在動物身上訓練我自己的模型，甚至可能在旅行恢復后獲取我自己的一些數據。
- 在 PL 中實現視頻加速內核（圖像大小調整、DPU 預處理等），以實現更快的端到端加速 - 在 FPGA 端進行視頻穩定，以增強云臺穩定并獲得最流暢的視頻輸出。

最后的想法

在開始這個項目時，考慮到 FPGA 項目通常的學習曲線，我已經意識到時間會很緊。我嘗試逐步構建，將項目劃分為更小的邏輯模塊，并在此過程中進行原型設計和學習。盡管最終在達到所有目標之前已經沒有時間了，但我對自己取得的進步感到滿意。時間限制也幫助我以比通常的“探索”速度更快的速度學習事物。它還幫助我在嵌入式領域學到了很多新東西，并幫助我確定了我未來需要投入更多時間的領域（例如，人工智能）。感謝 Hackster 和 Xilinx 提供這次學習機會。這確實是一次很棒的經歷。