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