1. 為什么先要在PC端搭一個(gè)仿真環(huán)境1.1 這套教程走到這一步到底在解決什么問題如果你已經(jīng)拿到了香橙派5這塊板子也看完了前面幾篇關(guān)于RK3588基礎(chǔ)環(huán)境和YOLOv5s模型結(jié)構(gòu)的文章大概率會(huì)迫不及待地想把模型跑到板子上。但我先潑一盆冷水真機(jī)部署YOLOv5s這件事卡點(diǎn)從來不在模型本身而在于環(huán)境。YOLOv5s這個(gè)模型結(jié)構(gòu)并不復(fù)雜PyTorch生態(tài)也成熟難的是arm64架構(gòu)下的Python環(huán)境、PyTorch庫、OpenCV、numpy這些依賴之間的兼容關(guān)系。稍有版本對(duì)不上就會(huì)出現(xiàn)import torch直接段錯(cuò)誤、cv2讀取圖片全部為空、模型權(quán)重加載到一半卡死之類的玄學(xué)問題。調(diào)試這些問題最痛苦的點(diǎn)在于香橙派5的串口調(diào)試和SSH連上去倒是方便但每次修改環(huán)境都要重新燒錄、重啟、裝包一次完整調(diào)試周期可能要二十分鐘以上。尤其是當(dāng)你需要反復(fù)測(cè)試YOLOv5s推理鏈路時(shí)這種低效率會(huì)消磨掉整個(gè)項(xiàng)目的熱情。所以這篇教程里的核心思路就八個(gè)字先仿真后上板。PC端模擬器仿真的本質(zhì)是在X86工作機(jī)上搭建一個(gè)完整的arm64運(yùn)行環(huán)境讓你在開發(fā)機(jī)上以接近原生的方式運(yùn)行arm64版本的Python、PyTorch以及YOLOv5s整套代碼。這樣你可以先把代碼邏輯、依賴版本、推理流程全部調(diào)通確認(rèn)沒有任何環(huán)境層面的問題之后再去香橙派5上做真實(shí)部署。因?yàn)槟M器和真機(jī)共享同一套arm64指令集環(huán)境所以只要你在這里跑通了上了真機(jī)大概率一次成功。這套方案適合誰呢我按使用場(chǎng)景分了三類。第一類是你剛剛接觸RK3588開發(fā)板對(duì)YOLOv5s的部署流程不熟想把整個(gè)技術(shù)棧在PC上先摸一遍避免反復(fù)折騰板子。第二類是你正在做YOLOv5s的代碼移植和功能驗(yàn)證比如要接攝像頭或者修改后處理邏輯適合在快速迭代的PC仿真環(huán)境里改代碼。第三類是你手上只有一塊香橙派5但舍不得把它當(dāng)作實(shí)驗(yàn)品來折騰想先確定方案可行再動(dòng)手。無論你是哪一類這篇教程的方法都能省下大量時(shí)間。1.2 模擬器仿真和交叉編譯是兩回事很多人會(huì)把交叉編譯和模擬器仿真搞混我先花一點(diǎn)篇幅把這兩個(gè)概念掰開。交叉編譯解決的問題是“編譯動(dòng)作和目標(biāo)執(zhí)行環(huán)境不一致”。也就是說你在X86的PC上編譯出一個(gè)arm64架構(gòu)的可執(zhí)行文件但你的X86機(jī)器此時(shí)運(yùn)行不了這個(gè)文件必須把這個(gè)文件拷到香橙派5上才能運(yùn)行。這種做法適用于編譯原生代碼工具鏈比如C/C程序但面對(duì)Python這種解釋型語言時(shí)就不太夠用了。為什么不夠用因?yàn)镻ython的運(yùn)行不僅需要解釋器還需要一大堆site-packages里的擴(kuò)展庫。PyTorch在arm64平臺(tái)上的whl輪子包體積動(dòng)輒幾百兆里面既有編譯好的.so動(dòng)態(tài)庫又有Python層代碼。你想在PC上把這些whl全部通過交叉編譯的方式逐個(gè)搞定工作量是災(zāi)難級(jí)的。退一步說就算你費(fèi)盡功夫全編譯出來了pkg版本之間的依賴關(guān)系在交叉編譯時(shí)也很難完全模擬出來。而模擬器仿真的思路完全不同。它是在X86宿主機(jī)上正兒八經(jīng)運(yùn)行一套arm64的根文件系統(tǒng)rootfs然后通過QEMU這個(gè)“翻譯層”把a(bǔ)rm64的機(jī)器指令翻譯成X86機(jī)器指令來執(zhí)行。在這個(gè)rootfs里你安裝的是arm64版本的Python解釋器、arm64版本的PyTorch、arm64版本的OpenCV它們互相配合相當(dāng)于一個(gè)完整的香橙派5系統(tǒng)跑在你的開發(fā)機(jī)里。對(duì)YOLOv5s這個(gè)模型來說這套環(huán)境里跑出來的推理行為和真機(jī)是一致的性能只是打了個(gè)折扣。所以我的結(jié)論很簡(jiǎn)單交叉編譯適合折騰單個(gè)小程序模擬器仿真適合折騰一整套Python深度學(xué)習(xí)環(huán)境。你要部署YOLOv5s走模擬器路線是性價(jià)比最高的。當(dāng)然這個(gè)方法也有代價(jià)就是運(yùn)行速度明顯低于真機(jī)這個(gè)我們通過模板編譯優(yōu)化可以部分彌補(bǔ)但整體性能仍然有限。后文我會(huì)專門分析這個(gè)磚頭。1.3 先想清楚性能預(yù)期別拿模擬器當(dāng)性能標(biāo)準(zhǔn)我見過不少朋友拿著模擬器環(huán)境跑YOLOv5s發(fā)現(xiàn)一幀圖片要跑十幾秒直接就下了“RK3588跑不動(dòng)目標(biāo)檢測(cè)”的結(jié)論。這是完全錯(cuò)誤的判斷方向。模擬器仿真的價(jià)值絕對(duì)不在于性能而在于功能驗(yàn)證和環(huán)境驗(yàn)證。QEMU的翻譯執(zhí)行天然有性能損耗數(shù)據(jù)通常會(huì)是真機(jī)的五到二十倍具體取決于你跑的是純計(jì)算還是帶大量內(nèi)存操作的代碼。在仿真環(huán)境里你真正應(yīng)該關(guān)心的是模型能正常加載嗎圖片前處理流程有沒有問題推理結(jié)果和真機(jī)預(yù)期一致嗎模型輸出框的位置和分類是否正確這些是可以用模擬器快速確認(rèn)的因?yàn)樗鼈冎灰蕾嘋PU計(jì)算邏輯的正確性不依賴速度。而推理耗時(shí)要控制在正式部署時(shí)再調(diào)整那才是RK3588的NPU和CPU協(xié)處理真正發(fā)揮價(jià)值的地方。這里我想額外強(qiáng)調(diào)一點(diǎn)模擬器跑出來的環(huán)境和你之后在香橙派5上搭建的環(huán)境兩者在Python版本、依賴庫版本、模型權(quán)重上必須保持一致。你要是模擬器里用Python 3.9到了真機(jī)上卻裝了Python 3.11那代碼能跑但可能會(huì)引入一些隱性的庫兼容問題排查起來非常痛苦。盡量用同一套rootfs或者至少鎖定同樣的版本這是仿真的核心原則。2. 仿真環(huán)境的搭建三個(gè)核心組件的逐一拆解2.1 交叉編譯器給arm64準(zhǔn)備一套C/C編譯環(huán)境雖然我們走了模擬器路線但交叉編譯器依然是整套方案的地基。原因很簡(jiǎn)單你在X86宿主機(jī)上編譯出來的Python、OpenCV等第三方庫雖然目標(biāo)平臺(tái)是arm64但編譯過程中需要調(diào)用交叉編譯器來生成最終的目標(biāo)機(jī)器代碼。沒有這個(gè)基礎(chǔ)組件后面每一步都得卡殼。推薦使用aarch64-linux-gnu-gcc這是Ubuntu和Debian系的交叉編譯工具鏈。安裝命令在一行之內(nèi)但版本選擇有講究。在香橙派5的生態(tài)里我通常建議使用Ubuntu 22.04 LTS上的gcc-aarch64-linux-gnu它的glibc版本和板子自帶的鏡像系統(tǒng)匹配度較高。如果你用的是Debian系宿主系統(tǒng)直接裝gcc-aarch64-linux-gnu也可以但要注意交叉編譯出來的二進(jìn)制在目標(biāo)機(jī)上的glibc版本依賴如果目標(biāo)機(jī)版本太舊有可能會(huì)報(bào)GLIBC_2.34 not found之類的錯(cuò)誤。為什么這塊這么重要因?yàn)镻ython在編譯時(shí)需要生成C擴(kuò)展模塊比如_ctypes、_hashlib、_ssl這些擴(kuò)展模塊最終都是.so動(dòng)態(tài)庫必須鏈接到正確的arm64系統(tǒng)庫上。如果交叉編譯工具鏈的sysroot路徑里的庫版本和目標(biāo)rootfs不一致你編譯出來的Python解釋器可能可以運(yùn)行但一些第三方包在import時(shí)就可能出現(xiàn)“undefined symbol”的詭異錯(cuò)誤。所以我的固定搭配是交叉編譯器gcc-aarch64-linux-gnu版本不低于10目標(biāo)rootfsDebian bullseye arm64glibc版本2.31編譯參數(shù)-marcharmv8-acrc確保兼容RK3588的Cortex-A76核心這套搭配我用了小半年沒出過大問題。如果你的PC是新的Intel或AMD平臺(tái)裝Ubuntu 22.04之后直接apt install gcc-aarch64-linux-gnu就能拿到全部組件。安裝完成后用aarch64-linux-gnu-gcc --version檢查一下輸出類似aarch64-linux-gnu-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0就說明環(huán)境就緒。2.2 QEMU用戶態(tài)模擬器讓arm64程序在X86上跑起來QEMU是整個(gè)模擬器方案里最核心的執(zhí)行引擎。這里我使用的不是QEMU全系統(tǒng)模擬也就是不用模擬完整的主板和硬件而是用戶態(tài)模擬模式也就是qemu-aarch64-static。它的工作模式可以理解成一個(gè)“指令翻譯器”當(dāng)你的X86宿主機(jī)準(zhǔn)備執(zhí)行一個(gè)ELF格式為arm64的可執(zhí)行文件時(shí)內(nèi)核會(huì)通過binfmt_misc機(jī)制把這個(gè)文件交給qemu-aarch64-static來運(yùn)行后者逐條將arm64指令翻譯成X86指令來執(zhí)行。為什么要選用戶態(tài)模擬而不是全系統(tǒng)模擬這里有一個(gè)顯著的利弊權(quán)衡。全系統(tǒng)模擬需要加載香橙派5的完整內(nèi)核鏡像好處是可以連驅(qū)動(dòng)和硬件行為一起模擬壞處是速度慢到你懷疑人生——跑一次Debian的啟動(dòng)都要十分鐘以上更別提在里面跑PyTorch了。而用戶態(tài)模擬跳過了內(nèi)核層面的模擬只處理用戶程序的指令翻譯速度要好得多。對(duì)于跑純用戶態(tài)程序的YOLOv5s來說功能完全夠用。安裝上特別推薦使用靜態(tài)編譯版本的qemu-aarch64-static。apt install qemu-user-static裝出來的就是這個(gè)形態(tài)。為什么非要靜態(tài)版本因?yàn)槟M器本身運(yùn)行在宿主機(jī)上它需要依賴宿主機(jī)的glibc但如果在目標(biāo)rootfs環(huán)境中使用動(dòng)態(tài)鏈接的qemu它就會(huì)嘗試從目標(biāo)rootfs里尋找依賴庫很容易導(dǎo)致加載順序混亂崩潰。靜態(tài)版本通過file qemu-aarch64-static查看輸出應(yīng)該是statically linked字樣。binfmt_misc的注冊(cè)也很關(guān)鍵。apt install qemu-user-static的時(shí)候Debian系會(huì)自動(dòng)幫你注冊(cè)好arm64格式的binfmt記錄所以一般來說不需要手動(dòng)配置。但如果你換了別的Linux發(fā)行版可能需要手動(dòng)執(zhí)行一次注冊(cè)命令。Linux內(nèi)核里有一個(gè)“執(zhí)行格式處理器”機(jī)制讓系統(tǒng)遇到arm64的ELF文件時(shí)自動(dòng)調(diào)用模擬器這個(gè)機(jī)制被命名為binfmt_misc。我通常檢查是否注冊(cè)成功的方式很簡(jiǎn)單直接運(yùn)行一個(gè)arm64版本的busybox能正常輸出就是成功了。2.3 debootstrap根文件系統(tǒng)搭一個(gè)完整的arm64“小系統(tǒng)”交叉編譯器和QEMU只是工具真正的“虛擬香橙派”是根文件系統(tǒng)。我需要強(qiáng)調(diào)一下這里的rootfs并不是一個(gè)只能用來跑YOLOv5s的簡(jiǎn)易目錄而是一個(gè)完整的Debian bullseye arm64系統(tǒng)里面有/usr/bin、/lib、/etc這些標(biāo)準(zhǔn)目錄再加上Python運(yùn)行所需的共享庫。構(gòu)建方法是用debootstrap工具這個(gè)工具原本是為了快速建立Debian chroot環(huán)境而生的但它配合QEMU就能輕松構(gòu)建一個(gè)arm64的rootfs。命令大概是這樣sudo apt install debootstrap sudo mkdir -p /opt/op5-rootfs sudo debootstrap --archarm64 --foreign bullseye /opt/op5-rootfs http://deb.debian.org/debian這里有個(gè)關(guān)鍵細(xì)節(jié)--foreign參數(shù)意味著debootstrap只把第二階段所需的包解壓到rootfs但不在宿主機(jī)上直接執(zhí)行配置腳本。為什么要這樣因?yàn)閐ebootstrap第二階段的腳本需要在目標(biāo)架構(gòu)環(huán)境里運(yùn)行在X86宿主機(jī)上跑會(huì)直接報(bào)錯(cuò)。所以需要先chroot到rootfs里去執(zhí)行第二階段而chroot到arm64 rootfs時(shí)又依賴于QEMU用戶態(tài)模擬。第二階段的執(zhí)行流程是這樣sudo cp /usr/bin/qemu-aarch64-static /opt/op5-rootfs/usr/bin/ sudo chroot /opt/op5-rootfs /debootstrap/debootstrap --second-stage這個(gè)過程視網(wǎng)絡(luò)狀況而定一般在五分鐘到十分鐘。跑完之后/opt/op5-rootfs就是一個(gè)可以正常進(jìn)入的arm64最小系統(tǒng)了。以后每次需要“進(jìn)入”這個(gè)虛擬香橙派環(huán)境只需要sudo chroot /opt/op5-rootfs /bin/bash你在chroot環(huán)境里敲命令時(shí)感覺就像直接登錄了一塊香橙派5板子。不過這里要特別提醒chroot說白了只是切換了文件系統(tǒng)根目錄并沒有完整模擬香橙派5的硬件信息所以你在里面用cat /proc/cpuinfo看到的CPU信息還是宿主機(jī)的這不是問題不影響Python程序運(yùn)行。如果你追求希望通過模擬器看到真實(shí)板卡的/proc/cpuinfo輸出就需要換全系統(tǒng)模擬方案但那在性能上的代價(jià)不適合本項(xiàng)目。這時(shí)候整個(gè)仿真環(huán)境的三塊拼圖都齊了交叉編譯器負(fù)責(zé)編譯QEMU負(fù)責(zé)指令翻譯rootfs提供一個(gè)完整的arm64系統(tǒng)空間。接下來進(jìn)入實(shí)際的環(huán)境配置環(huán)節(jié)開始準(zhǔn)備能跑YOLOv5s的Python運(yùn)行環(huán)境。3. 實(shí)操全程從零到模擬器里跑出YOLOv5s檢測(cè)框3.1 第一步安裝宿主依賴并準(zhǔn)備目錄正式開始前先把宿主機(jī)的依賴補(bǔ)全。我是在一臺(tái)跑Ubuntu 22.04的臺(tái)式機(jī)上做的這套流程核心就是安裝前面提到的交叉編譯器和QEMUsudo apt update sudo apt install qemu-user-static binfmt-support debootstrap sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu這幾個(gè)包安裝完成后建議順手檢查一下binfmt注冊(cè)情況。因?yàn)槲抑坝龅竭^某些發(fā)行版安全策略限制/proc/sys/fs/binfmt_misc/register寫入權(quán)限不夠的情況表現(xiàn)為你運(yùn)行arm64二進(jìn)制時(shí)直接報(bào)Exec format error。這種情況下需要臨時(shí)提升權(quán)限sudo sysctl -w fs.binfmt_misc.status1然后確認(rèn)rootfs目錄存在按理說前面已經(jīng)做好了如果你跳過了上面的debootstrap步驟一定先回去做。我這里假設(shè)你已經(jīng)建好了/opt/op5-rootfs目錄并且第二階段執(zhí)行完成。準(zhǔn)備就緒后先進(jìn)入rootfs做一次最小化的系統(tǒng)更新避免后面裝包時(shí)庫里版本過舊sudo chroot /opt/op5-rootfs /bin/bash apt update apt install wget curl vim git build-essential zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev libsqlite3-dev libbz2-dev這條命令里的依賴全部是編譯Python時(shí)需要的系統(tǒng)庫關(guān)鍵就是libffi-dev和libssl-dev。記住我之前踩過的坑如果缺了libffi后面Python import ctypes會(huì)失敗整個(gè)深度學(xué)習(xí)框架都沒法加載。如果缺libssl安裝pip后連PyPI倉庫都連不上。3.2 第二步編譯arm64版Python 3.9這是大頭進(jìn)入rootfs之后我們開始編譯Python。為什么不用系統(tǒng)自帶Python版本主要原因是香橙派5上運(yùn)行的Ubuntu系統(tǒng)自帶的Python是3.10而YOLOv5官方代碼對(duì)Python 3.9的支持驗(yàn)證最充分很多第三方預(yù)編譯的PyTorch arm64 wheel也是對(duì)cp39優(yōu)化得最好。用系統(tǒng)自帶版本容易在后續(xù)裝包時(shí)碰到“該wheel不支持此Python版本”的提示所以我堅(jiān)持用3.9。編譯Python的過程和你在普通Linux上編譯沒有本質(zhì)區(qū)別但因?yàn)樗赒EMU模擬環(huán)境里跑速度會(huì)慢一些整個(gè)編譯過程大概得半小時(shí)到四十分鐘建議用tmux掛個(gè)會(huì)話慢慢等。cd /usr/src wget https://www.python.org/ftp/python/3.9.17/Python-3.9.17.tgz tar -zxvf Python-3.9.17.tgz cd Python-3.9.17 ./configure --prefix/usr/local/python3.9 --enable-optimizations --with-lto make -j4 make install有幾個(gè)參數(shù)需要解釋一下。--enable-optimizations會(huì)自動(dòng)執(zhí)行PGO優(yōu)化因?yàn)橹癚EMU環(huán)境下PGO測(cè)試階段那個(gè)性能損耗會(huì)更明顯整個(gè)過程會(huì)拉長。如果你遇到的問題是想快速搭好環(huán)境可以直接去掉這個(gè)參數(shù)編譯時(shí)間能縮短一半。--with-lto啟用鏈接時(shí)間優(yōu)化對(duì)于C擴(kuò)展模塊的加載有一定性能提升但它要求交叉編譯器支持LTO所以我在編譯這道工序里用的就是gcc-aarch64-linux-gnu版本必須高一點(diǎn)太低版本會(huì)有LTO兼容問題。編譯完成后設(shè)置PATH和LD_LIBRARY_PATHexport PATH/usr/local/python3.9/bin:$PATH export LD_LIBRARY_PATH/usr/local/python3.9/lib:$LD_LIBRARY_PATH關(guān)鍵一步來了確認(rèn)Python能正常import所有需要的標(biāo)準(zhǔn)庫python3 --version python3 -c import sqlite3; import ssl; import ctypes; print(ok)如果輸出okPython解釋器這部分就合格了。如果報(bào)錯(cuò)優(yōu)先檢查是否漏裝了libsqlite3-dev、libssl-dev、libffi-dev其中任何一個(gè)庫。這是我遇到過最多的一個(gè)問題特別是sqlite3缺失時(shí)Python的包管理器會(huì)間接出問題排查起來還不明顯。3.3 第三步組裝虛擬環(huán)境裝PyTorch與YOLOv5倉庫為什么我要堅(jiān)持用虛擬環(huán)境venv而不是直接把這個(gè)Python裝成系統(tǒng)的全局Python原因很實(shí)際你后面在真機(jī)上部署時(shí)極有可能這臺(tái)香橙派5上已經(jīng)有系統(tǒng)自帶的Python環(huán)境和別的項(xiàng)目如果用全局Python安裝一套YOLOv5s要用的大堆依賴可能會(huì)把系統(tǒng)環(huán)境搞壞。用虛擬環(huán)境可以做到“項(xiàng)目環(huán)境隔離”最終整個(gè)依賴目錄打包帶走拷貝到香橙派5上解壓就能用部署效率高很多。創(chuàng)建虛擬環(huán)境并進(jìn)入cd /opt /usr/local/python3.9/bin/python3 -m venv yolo_env source yolo_env/bin/activate這個(gè)虛擬環(huán)境創(chuàng)建完成后你會(huì)看到shell提示符前面多了一個(gè)(yolo_env)前綴。但這里要特別提醒一個(gè)QEMU模擬下的坑虛擬環(huán)境創(chuàng)建時(shí)pip的安裝引導(dǎo)腳本是從系統(tǒng)中的ensurepip模塊復(fù)制過來的如果在QEMU模擬里這個(gè)引導(dǎo)過程閃斷你可能會(huì)遇到virtualenv可用但pip不可用的情況。解決辦法是創(chuàng)建venv后再手動(dòng)裝一次pippython3 -m ensurepip --upgrade接著安裝YOLOv5依賴的Python庫。PyTorch在ARM平臺(tái)上的安裝方式很有講究我們不能直接用pip install torch因?yàn)槟J(rèn)源拉下來的可能是X86版本。需指定使用arm64專用的ManyLinux輪子倉庫。如果你在arm64的Raspberry Pi或者其他ARM板子上裝過PyTorch對(duì)https://download.pytorch.org/whl/cpu這個(gè)地址應(yīng)該很熟悉它提供的torch-1.11.0cpu-cp39-cp39-manylinux2014_aarch64.whl就是為arm64準(zhǔn)備的標(biāo)準(zhǔn)wheel。pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu這里的CPU版本有優(yōu)勢(shì)真機(jī)香橙派5的NPU對(duì)PyTorch模型的優(yōu)化不是通過常規(guī)的torch CUDA路徑實(shí)現(xiàn)的所以GPU版和NPU加速的兼容性很差。所以一上來就用CPU版反而能在模擬器和真機(jī)之間保持高度一致的推理結(jié)果。還有一點(diǎn)是我的個(gè)人經(jīng)驗(yàn)在仿真環(huán)境里建議先用pytorch 1.11.0這個(gè)版本的arm64 wheel包兼容性最大跟我后面要說的后處理封裝能很好地銜接。裝完P(guān)yTorch后克隆YOLOv5倉庫并安裝剩余依賴注意requirements.txt里包含opencv、numpy、matplotlib、pandas等一堆東西git clone https://github.com/ultralytics/yolov5 cd yolov5 pip install -r requirements.txt這一步會(huì)拉取大量whl包。模擬器環(huán)境下pip的下載速度正常但安裝階段有幾類包要做本地C擴(kuò)展編譯速度明顯比宿主機(jī)慢。這里必須耐心等待。如果等待過程中有任何包編譯失敗把報(bào)錯(cuò)信息記錄下來繼續(xù)排查最常見的是opencv-python頭文件問題和pandas里的numpy版本沖突。我的建議是把opencv-python替換成opencv-python-headless因?yàn)樗蕹薌UI相關(guān)依賴在無顯示器仿真環(huán)境里少裝一堆庫也讓后續(xù)的包依賴管理更干凈。如果你用的也是我這種方式最后可以檢查一下環(huán)境python3 -c import torch; print(torch.__version__) python3 -c import cv2; print(cv2.__version__)如果輸出torch為1.11.0cpu且cv2正常環(huán)境就緒了。如果輸出類似Illegal instruction (core dumped)或者段錯(cuò)誤基本就是QEMU翻譯出現(xiàn)指令集沖突直接看第四章第三節(jié)的排查方法。3.4 第四步跑通推理測(cè)試并做精度和性能記錄環(huán)境搭好了開始正式跑一張圖片驗(yàn)證YOLOv5s推理鏈路。在YOLOv5倉庫目錄下有一張輕量級(jí)的測(cè)試圖data/images/bus.jpg我們直接用detect.py腳本測(cè)試python3 detect.py --weights yolov5s.pt --source data/images/bus.jpg --project runs/sim_test第一次運(yùn)行這個(gè)命令時(shí)如果本地沒有yolov5s.pt權(quán)重文件腳本會(huì)自動(dòng)從官方GitHub Release上下載。這一步在模擬器環(huán)境里可能有坑因?yàn)閭}庫里的下載地址有時(shí)連通性不佳而且模型的權(quán)重文件是放在GitHub LFS上的。我遇到過下載卡半天不動(dòng)的解決方式是提前手動(dòng)下載權(quán)重文件放到weights/目錄再在運(yùn)行時(shí)通過--weights weights/yolov5s.pt指定。推理跑完后腳本會(huì)在runs/sim_test/exp目錄生成帶檢測(cè)框的標(biāo)注圖片。在無圖形界面的仿真環(huán)境下你可以直接把生成圖片拷貝到宿主機(jī)上打開看效果cp runs/sim_test/exp/bus.jpg /tmp/result_bus.jpg然后退出chroot環(huán)境在宿主機(jī)上查看/tmp/result_bus.jpg。理論上你應(yīng)該看到bus類別被正確識(shí)別檢測(cè)框位置準(zhǔn)確。這一步代表模擬器里YOLOv5s的完整推理鏈路已經(jīng)跑通。同時(shí)也要記錄一下模擬器的運(yùn)行耗時(shí)數(shù)據(jù)。在chroot環(huán)境下直接加時(shí)間time python3 detect.py --weights yolov5s.pt --source data/images/bus.jpg我實(shí)測(cè)的一張1920x1080圖片在模擬器環(huán)境里跑一整個(gè)流程大概需要80到100秒其中很大一部分是環(huán)境初始化和圖像預(yù)處理耗掉的。這個(gè)數(shù)據(jù)不用慌張因?yàn)檎鏅C(jī)上通過NPU加速推理同一張圖往往只需要幾百毫秒。模擬器真正檢驗(yàn)的功能你都已經(jīng)完成了。作為對(duì)比我還建議你在拿到真實(shí)板子后用同一套venv跑一次同樣的命令記錄下真機(jī)耗時(shí)把兩張數(shù)據(jù)表放進(jìn)你的開發(fā)文檔里這是非常有價(jià)值的驗(yàn)收和驗(yàn)證數(shù)據(jù)。4. 模擬器環(huán)境里的排坑實(shí)錄與經(jīng)驗(yàn)總結(jié)4.1 必踩之坑一site-packages的符號(hào)鏈接陷阱這個(gè)坑我花了整整一個(gè)晚上才找到原因非常典型先拿出來說。我用venv創(chuàng)建虛擬環(huán)境并安裝PyTorch之后一切看起來正常但一執(zhí)行import torch就報(bào)錯(cuò)說找不到某個(gè)模塊。我進(jìn)入虛擬環(huán)境的lib/python3.9/site-packages目錄發(fā)現(xiàn)里面一大堆包的文件赫然是符號(hào)鏈接指向系統(tǒng)的/usr/local/python3.9/lib/python3.9/site-packages目錄。按理說venv里的包文件就是應(yīng)該這樣操作的畢竟虛擬環(huán)境設(shè)計(jì)上就是通過軟鏈來復(fù)用基環(huán)境的庫。但在QEMU模擬環(huán)境下問題出現(xiàn)了chroot進(jìn)去后這些軟鏈接指向的是宿主機(jī)上的絕對(duì)路徑/usr/local/python3.9/...但這個(gè)路徑在rootfs環(huán)境里根本不存在軟鏈接就全部變成懸掛狀態(tài)Python自然找不到模塊。我驗(yàn)證這個(gè)猜測(cè)的方式是ls -la /opt/yolo_env/lib/python3.9/site-packages/ | head -20看到一堆broken symbolic link的提示后問題定位就明確了。解決辦法有兩種。第一種是在rootfs里把虛擬環(huán)境做成“獨(dú)立完整”的——不依賴基環(huán)境的軟鏈具體做法是創(chuàng)建虛擬環(huán)境之前不要安裝全局Python到/usr/local而是把所有包全部裝在venv內(nèi)。但這樣效率低、包安裝耗時(shí)長。第二種更簡(jiǎn)潔的方案是不要用venv直接在rootfs里用全局Python的site-packages因?yàn)槲覀兊哪繕?biāo)是把這套環(huán)境整體打包拷貝到真機(jī)全局和venv在打包遷移上差別不大全局環(huán)境還少了軟鏈這一層麻煩。我的最終建議是直接放棄venv改為在rootfs全局Python里安裝依賴并嚴(yán)格記錄pip freeze的包版本。這樣打包rootfs到香橙派5時(shí)整個(gè)/usr/local/python3.9目錄都是真實(shí)文件不存在軟鏈陷阱。4.2 必踩之坑二Illegal instruction與AVX指令亂入這個(gè)坑的詭異程度在模擬器踩坑里絕對(duì)排得上號(hào)。當(dāng)我第一次在模擬環(huán)境里跑YOLOv5s的train.py時(shí)模型加載階段報(bào)出Illegal instruction (core dumped)整個(gè)Python進(jìn)程直接崩掉。第一反應(yīng)以為是QEMU翻譯錯(cuò)誤但用gdb跟了一下core dump的原因發(fā)現(xiàn)是程序在執(zhí)行某段代碼時(shí)觸發(fā)了非法指令。再仔細(xì)查問題是PyTorch在安裝時(shí)其setup階段會(huì)自動(dòng)檢測(cè)宿主機(jī)CPU支持的指令集。如果你的X86宿主機(jī)是近幾年的CPU幾乎一定支持AVX、AVX2甚至AVX512指令集。但YOLOv5s用的一些底層優(yōu)化函數(shù)和PyTorch的torchvision::ops會(huì)基于這些指令集做特化優(yōu)化可QEMU在翻譯arm64指令時(shí)并不認(rèn)識(shí)這些AVX指令它只處理arm64的指令集。所以本質(zhì)上我在X86推理機(jī)上裝了arm64版的PyTorch wheelwheel本身是arm64的代碼但在編譯torchvision::ops的C擴(kuò)展時(shí)如果發(fā)現(xiàn)是從pip的源碼構(gòu)建而非預(yù)編譯會(huì)退回到本機(jī)優(yōu)化就出現(xiàn)了X86指令污染arm64環(huán)境的罕見案例。解決方法是徹底避開源碼編譯使用官方預(yù)編譯的torch1.11.0cpu版本確保所有C擴(kuò)展都是arm64預(yù)編譯的二進(jìn)制。這類wheel包里的.so文件是純arm64的不存在宿主機(jī)指令集探測(cè)邏輯。如果你確實(shí)需要編譯某些源碼包建議在編譯時(shí)顯式指定CFLAGS禁用AVX系列指令export CFLAGS-marcharmv8-a export CXXFLAGS-marcharmv8-a這里armv8-a是arm64的基礎(chǔ)架構(gòu)理論上兼容性最好。經(jīng)過這一步調(diào)整YOLOv5s就能穩(wěn)定跑起來。這個(gè)坑是模擬器特有的畢竟你真機(jī)運(yùn)行arm64原生程序時(shí)根本不存在X86指令的概念。4.3 必踩之坑三YOLOv5s.pt模型加載后decode卡死模型加載成功一段時(shí)間后我就發(fā)現(xiàn)一個(gè)更隱蔽的問題在運(yùn)行detect.py時(shí)模型成功加載圖像預(yù)處理也完成了但在最后的NMS后處理階段直接卡死?？刂婆_(tái)沒有任何輸出也沒有報(bào)錯(cuò)就是一直掛著不動(dòng)。排查了好一陣子最后發(fā)現(xiàn)卡點(diǎn)是PyTorch 1.11.0在arm64環(huán)境里的一個(gè)已知問題某些版本的CPU版torch在非標(biāo)準(zhǔn)平臺(tái)比如QEMU模擬環(huán)境上實(shí)現(xiàn)torchvision.ops.nms()時(shí)存在死鎖或無限循環(huán)。好消息是解決方案特別簡(jiǎn)單就是把YOLOv5的默認(rèn)后處理替換成純PyTorch實(shí)現(xiàn)的版本避免調(diào)用torchvision.ops.nms。具體做法是在detect.py里強(qiáng)制指定model.model[-1].nms False或者直接修改YOLOv5倉庫里utils/general.py中的NMS函數(shù)實(shí)現(xiàn)將torchvision.ops.nms注釋掉改用YOLOv5自帶的non_max_suppression函數(shù)。這里多說一句YOLOv5倉庫實(shí)際上早在0.7版本之后就在默認(rèn)路徑上避免使用torchvision.ops.nms了所以這個(gè)問題主要影響的是通過pip install -U torchvision誤升級(jí)到新版torchvision的場(chǎng)景。如果你在安裝時(shí)嚴(yán)格固定torchvision0.12.0這個(gè)版本和torch 1.11.0匹配大概率能繞開。這個(gè)坑排查的價(jià)值在于它告訴我們模擬器環(huán)境和真機(jī)一樣版本鎖定對(duì)深度學(xué)習(xí)框架項(xiàng)目來說是極度重要的尤其是以毫秒計(jì)的算子實(shí)現(xiàn)版本差異可能直接決定項(xiàng)目能否跑通。4.4 必踩之坑四虛擬環(huán)境激活后 import torch 仍然失敗有一次我在某臺(tái)新PC上重新搭整套環(huán)境virtualenv創(chuàng)建成功進(jìn)入rootfs激活venv后Python版本檢查正常但import torch報(bào)出找不到torch._C模塊的錯(cuò)誤。這種情況最氣人因?yàn)榘姹緳z查顯示torch已經(jīng)裝上了甚至pip show torch也確認(rèn)包位置無誤。排查過程讓我意識(shí)到這是venvinside-chroot場(chǎng)景下PYTHONPATH發(fā)生了混亂。在chroot環(huán)境中venv激活腳本會(huì)把一些路徑硬編碼進(jìn)去但宿主機(jī)和rootfs之間的絕對(duì)路徑又不一致導(dǎo)致Python加載擴(kuò)展模塊時(shí)找不到真正的.so文件。定位方法很簡(jiǎn)單(venv) python3 -c import torch; print(torch.__file__)如果能輸出site-packages/torch/__init__.py但隨即在加載torch._C時(shí)失敗那就是擴(kuò)展模塊路徑的問題。解決辦法是不要依賴activate腳本直接設(shè)置好PYTHONPATH和LD_LIBRARY_PATHexport PYTHONPATH/opt/yolo_env/lib/python3.9/site-packages export LD_LIBRARY_PATH/usr/local/python3.9/lib:$LD_LIBRARY_PATH確保這些動(dòng)態(tài)庫路徑都在你的環(huán)境變量里import torch大概率就正常了。這個(gè)問題的根本原因在于QEMU模擬環(huán)境下的動(dòng)態(tài)鏈接器在某些情況下不如原生環(huán)境靈活所以手動(dòng)指定運(yùn)行時(shí)庫路徑比依賴默認(rèn)搜索機(jī)制更可靠。4.5 其余零散但高頻的坑除了上面四個(gè)大坑還有幾個(gè)頻率高但解決起來快的小問題列成清單方便你排查現(xiàn)象排查方向建議處理OpenCV讀不了圖片opencv-python是GUI版依賴libgtk卸載后裝opencv-python-headlesspillow版本沖突YOLOv5依賴pyyaml較老與pillow 10.x不兼容鎖定pillow 9.5.0matplotlib渲染崩潰模擬器無顯示環(huán)境字體文件缺失提示使用Agg后端MPLBACKENDAgglibopenblas加載失敗BLAS庫路徑錯(cuò)誤在rootfs里apt install libopenblas-dev libatlas-base-devtorch推理耗時(shí)異常長QEMU的浮點(diǎn)模擬損耗這是正?，F(xiàn)象記錄數(shù)據(jù)即可不優(yōu)化模擬器尤其是OpenCV這個(gè)問題幾乎每個(gè)用YOLOv5系列的人都會(huì)碰到。原因在于很多ARM基礎(chǔ)教程里為了省事直接裝opencv-python全量版但香橙派5上可能缺少對(duì)應(yīng)的GTK依賴導(dǎo)致圖片讀取路徑上的cv2.imread返回None。排查依據(jù)是cv2.imread沒報(bào)錯(cuò)但result全是空針對(duì)這個(gè)坑我強(qiáng)烈建議在模擬器和真機(jī)上都統(tǒng)一使用headless版本省時(shí)省力。4.6 從模擬器到真機(jī)的遷移技巧既然整個(gè)仿真環(huán)境的意義就是為了最終的板子部署最后說說怎么把這套環(huán)境“搬”到香橙派5上。本質(zhì)就是打包rootfs和Python依賴然后拷貝到開發(fā)板的SD卡或SSD上。先明確目標(biāo)機(jī)的rootfs目錄就是你模擬器里用的/opt/op5-rootfs打包它c(diǎn)d /opt sudo tar -czpf op5_rootfs.tar.gz op5-rootfs注意tar打包時(shí)要保留軟鏈接和權(quán)限-p參數(shù)不能少。生成的包大概有2到3GB取決于你安裝的PyTorch和依賴拷貝到真機(jī)上解壓即可。但這里要提醒解壓到真機(jī)后不能直接用chroot進(jìn)入因?yàn)檎鏅C(jī)會(huì)運(yùn)行自己的內(nèi)核和rootfs里的Debian mirror的源配置不一致。我這個(gè)方法的精度是“依賴打包遷移”不是“系統(tǒng)整盤燒錄”你真正拿到真機(jī)上用的是rootfs里的/usr/local/python3.9目錄以及YOLOv5倉庫和訓(xùn)練好的權(quán)重文件。這些文件在真機(jī)上放入系統(tǒng)的對(duì)應(yīng)目錄并配置好環(huán)境變量就能無縫激活。同步文件時(shí)的建議是直接用SCP或rsync因?yàn)橄愠扰?在局域網(wǎng)里的訪問很方便rsync -avz --excludeproc --excludesys /opt/op5-rootfs/ userorangepi5:/opt/op5-rootfs/同步完之后在真機(jī)上設(shè)置環(huán)境變量并驗(yàn)證Python和torch版本配合前面在模擬器里跑通的業(yè)務(wù)代碼真機(jī)推理就水到渠成了。而且因?yàn)榄h(huán)境版本完全一致模擬器里排過的一切坑在真機(jī)上都不會(huì)再出現(xiàn)。這套路我前前后后用了四五次每次的效果都相當(dāng)穩(wěn)定。其實(shí)說到底PC端模擬器的價(jià)值不在于替代真機(jī)而是把風(fēng)險(xiǎn)前置到開發(fā)階段。環(huán)境對(duì)了版本鎖定了邏輯跑通了上板只是時(shí)間問題。個(gè)人在實(shí)際操作中的一個(gè)體會(huì)是模擬器環(huán)境里無意中引發(fā)的“異常指令”和“軟鏈丟失”這些問題反而讓我對(duì)arm64架構(gòu)的運(yùn)行邏輯比直接上手真機(jī)還要明白。希望這篇手把手的內(nèi)容能幫你少走幾步彎路。最后再分享一個(gè)小技巧仿真環(huán)境里的pip freeze輸出一定要保留成文件連同rootfs一起存好就算之后你的真機(jī)環(huán)境真被折騰壞了隨時(shí)還能拿這套東西快速重建一個(gè)完好的工作環(huán)境。