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