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

然后構(gòu)建設(shè)計(jì)

cd ../..
cd hw_src
make

此時(shí)，我意識(shí)到我需要先安裝 Vitis-AI 庫(kù)，然后再繼續(xù)。為此，我需要先安裝 petalinux。對(duì)于 petalinux，我從這篇文章中獲得了指導(dǎo)，并立即安裝了它。

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

制作安裝目錄

mkdir ~/petalinux_sdk

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

./sdk-2020.1.0.0.sh

出現(xiàn)提示時(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

在這個(gè)階段，Vitis-AI 庫(kù)已經(jīng)建立。盡管 IVAS 設(shè)計(jì)不需要，但我繼續(xù)執(zhí)行頁面上的其余說明以嘗試示例。

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

要下載 AI 模型，我從AI 模型動(dòng)物園下載了模型

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

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

現(xiàn)在，運(yùn)行 docker 鏡像，激活 conda 環(huán)境并編譯模型

. ~/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 文件夾”下。請(qǐng)注意，我能夠成功編譯 tensorflow 模型，但對(duì) Caffe 模型沒有同樣的運(yùn)氣。我在這里和這里尋求幫助。出于IVAS 的目的，Xilinx 工程師非常友好地為我提供了模型編譯后的 elf 文件，以便我繼續(xù)前進(jìn)。

為此，我從一個(gè)全新的終端（賽靈思強(qiáng)烈推薦）開始，并獲取了環(huán)境設(shè)置腳本

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

接下來，我在適當(dāng)?shù)牡胤阶隽艘粋€(gè)目錄

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

mkdir ml_models

然后將兩個(gè)elf文件復(fù)制到ml_models文件夾中。現(xiàn)在我需要做的就是運(yùn)行最終的腳本來執(zhí)行魔法并創(chuàng)建 SD 卡映像：

./go.sh

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

在此之后，我按照此處的最后幾個(gè)步驟直到頁面結(jié)束，并且最終能夠運(yùn)行示例應(yīng)用程序。

我說“最終”是因?yàn)檫@對(duì)我來說并不順利，事實(shí)上我花了整整 2 天的時(shí)間才弄清楚。最初我嘗試運(yùn)行應(yīng)用程序，但屏幕上什么也沒有顯示。我開始進(jìn)行故障排除并閱讀。讓 DisplayPort 輸出正常工作的一個(gè)非常有用的資源是DP Linux 驅(qū)動(dòng)程序頁面，其中包含有關(guān)顯示端口 DRM 驅(qū)動(dòng)程序的大量信息。

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

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

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

modetest -M xlnx -w 39:alpha:0

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

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

請(qǐng)注意，autovideosink 也適用于 kmssink 驅(qū)動(dòng)程序

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

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

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

最后，我可以運(yùn)行 IVAS 演示應(yīng)用程序：

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

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

例如，在以下管道中，我設(shè)法讓相同的應(yīng)用程序處理實(shí)時(shí)視頻：

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

重要提示：對(duì)于所有管道，在使用 kmssink（xilinx DRM 驅(qū)動(dòng)程序）時(shí)，確保最后一個(gè)元素的視頻與顯示器上設(shè)置的分辨率相同非常重要！

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

你可以用我能想到的最簡(jiǎn)單的編解碼管道來試試

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

此時(shí)，我想知道如何將 VPU 集成到我的 C++/python 應(yīng)用程序中，最終我想出了一個(gè)非常簡(jiǎn)單的方法：在我的應(yīng)用程序中使用 gstreamer。

例如，要使用 VCU 解碼 H.264/265 文件或 RTSP 流，請(qǐng)?jiān)?opencv 應(yīng)用程序中使用以下管道（為清楚起見已簡(jiǎn)化）：

<壓縮文件/流源> ! omxh264dec ！應(yīng)用程序rc

要從應(yīng)用程序中編碼（壓縮）視頻幀，請(qǐng)使用以下（簡(jiǎn)化的）gstreamer 管道將它們發(fā)送到 VCU：

應(yīng)用程序！omxh264enc !....

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

把這一切放在一起

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

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

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

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

進(jìn)入下一步，因?yàn)槲覍?shí)際上需要一個(gè)對(duì)象檢測(cè)器而不是人臉檢測(cè)器，所以我開始修改代碼以使用 SSD 對(duì)象檢測(cè)器。嘗試運(yùn)行代碼時(shí)，我的應(yīng)用程序會(huì)掛起（并超時(shí)）等待 DPU。最初我懷疑我的應(yīng)用程序存在問題，因此我查看了示例以使用相同的對(duì)象檢測(cè)器找到合適的示例。我從 Xilinx 找到了一個(gè)使用相同 SSD 模型的 VART 示例，盡管它是用 C++ 編寫的。原始代碼使用原始（webm）文件進(jìn)行輸入，因此我將其修改為使用 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

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

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

未來的計(jì)劃

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

最后的想法

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