做嵌入式視覺、尤其是拿到一塊陌生的 ARM 開發(fā)板時(shí)“移植 OpenCV”一定避不開。這一篇循序漸進(jìn)的實(shí)操記錄人數(shù)我不單獨(dú)展開直接從我在一塊 Cortex-A 級別 ARM Linux 板子上移植 OpenCV 4.x 的過程中抽出的核心步驟按環(huán)境、依賴、編譯、上線運(yùn)行、性能調(diào)優(yōu)的順序?qū)?。先交代兩個(gè)前提宿主機(jī)器是 x86_64 的 Linux 環(huán)境目標(biāo)板是 ARM 架構(gòu)的 Linux 系統(tǒng)這是目前最常見的“宿主機(jī)編譯、目標(biāo)板運(yùn)行”的嵌入式開發(fā)場景。如果你目標(biāo)是 AArch64也就是 arm64 架構(gòu)除了工具鏈前綴和個(gè)別參數(shù)不同流程完全一樣。想強(qiáng)調(diào)的是移植不等于把 OpenCV 源碼放到板子里直接 make。ARM 板大多受限于存儲空間和處理能力在板上編譯既慢又容易卡死更可靠的手段是交叉編譯在性能強(qiáng)大的宿主機(jī)器上生成目標(biāo)板可執(zhí)行的庫文件與可執(zhí)行程序最后拷貝到板子上驗(yàn)證。這篇文章會陪你走完全部流程最后一小節(jié)還有我自己反復(fù)踩過幾輪的調(diào)優(yōu)心得。系列前一篇已經(jīng)提過幾處通用“經(jīng)驗(yàn)包”這一篇?jiǎng)t是完整版以一次獨(dú)立的板級移植作為眼下唯一主線。1. 移植前必須確認(rèn)的硬件與工具鏈?zhǔn)聦?shí)拿到一臺 ARM 板子多數(shù)人第一反應(yīng)是找 datusheet看處理器能跑多快、內(nèi)存多大這當(dāng)然對但開始動 CMake 之前還有更關(guān)鍵的問題工具鏈與板子是否匹配。工具鏈版本、處理器架構(gòu)、跟浮點(diǎn)運(yùn)算相關(guān)的 ABI 約定任何一項(xiàng)對不上都會讓后續(xù)的編譯過程出現(xiàn)一系列怪異錯(cuò)誤。1.1 交叉編譯是移植的起點(diǎn)不是唯一選項(xiàng)交叉編譯的原理很簡單在主機(jī)上用一套針對 ARM 目標(biāo)的編譯器生成代碼目標(biāo)板只負(fù)責(zé)運(yùn)行。OpenCV 本身是 C/C 項(xiàng)目源碼用到的編譯器特性不會特別新但依賴的第三方庫在交叉編譯時(shí)是真正的難點(diǎn)因?yàn)槊總€(gè)庫都需要用目標(biāo)層的工具鏈重新編譯一遍這是很多人開始沒有心理準(zhǔn)備的地方。 為什么不直接到板子上編譯我在某型號 ARM 板子試過4 核處理器2GB 內(nèi)存編譯一個(gè)完整 OpenCV 大概需要 poke 近半小時(shí)而且編到中途內(nèi)存耗盡常見得很。板子系統(tǒng)里還沒有完整 build-essential 工具鏈的也大有人在所以交叉編譯“更大幾率”是對的做法。當(dāng)然如果板子內(nèi)存充足、系統(tǒng)里已有可用的編譯環(huán)境直接在板上編也是可行的但如果你做的是產(chǎn)品預(yù)研后續(xù)需要反復(fù)改配置、加模塊交叉編譯的整個(gè)流程更可控。1.2 建立符合目標(biāo)板的根文件系統(tǒng)交叉編譯的 OpenCV 編譯期環(huán)境需要基礎(chǔ) C/C 庫和系統(tǒng)頭文件這些來自目標(biāo)板的系統(tǒng)根目錄。建議構(gòu)造一個(gè)專門的主機(jī)目錄例如 /opt/arm-rootfs用板子的根文件系統(tǒng)內(nèi)容填充它至少要包含 lib、usr/lib、usr/include 這幾個(gè)關(guān)鍵目錄。在這個(gè)目錄里目標(biāo)板的 libc.so、pthread、dl 等基礎(chǔ)庫和頭文件都會使用到。 很多供應(yīng)商發(fā)布的 SDK 包里已經(jīng)自帶根文件系統(tǒng)或工具鏈目錄用起來也比較穩(wěn)妥。如果沒有現(xiàn)成的就從板子上直接把整個(gè)根文件系統(tǒng)打包過來再解包到這個(gè)目錄。拿板子系統(tǒng)時(shí)要注意不要只拷貝 /lib 和 /usr/lib因?yàn)楹芏鄮旌皖^文件在 /usr/local 下尤其是你自己之前裝過的依賴。干脆把整塊根文件系統(tǒng)鏡像掛載或解包避免遺漏。1.3 工具鏈接口與處理器特性的常見誤區(qū)我犯過也用一件事編譯器用 arm-linux-gnueabihf 開頭代表 ARMv7 硬浮點(diǎn)如果板子其實(shí)是 AArch64那么必須使用 aarch64-linux-gnu 前綴。多個(gè)工具鏈前綴不要亂挑最好的辦法是檢查板子的內(nèi)核信息或者供應(yīng)商 SDK 文檔一次性給自己記錄下面這些參數(shù)。檢查項(xiàng)命令/方法對 OpenCV 的影響處理器架構(gòu)板內(nèi)執(zhí)行uname -m決定工具鏈前綴與 -march 參數(shù)是否支持 NEON查看 /proc/cpuinfo 里的 Features包含 neon 才行影響 CPU_BASELINE 與 NEON 使能浮點(diǎn) ABI工具鏈名稱含 hf 通常是 hardfp但最好用readelf -A驗(yàn)證決定鏈接時(shí)是否報(bào) VFP 寄存器錯(cuò)誤根文件系統(tǒng) libc 版本板內(nèi)執(zhí)行l(wèi)dd --version工具鏈 sysroot 的 libc 不能比板子新太多工具鏈和系統(tǒng)根目錄還有兩個(gè)容易踩進(jìn)去的坑。第一個(gè)是工具鏈自帶的 sysroot 與板子的 libc 版本不匹配通常會出現(xiàn) cannot find -lstdc 或 GLIBC_2.34 not found 這類運(yùn)行時(shí)報(bào)錯(cuò)解決方法是盡量采用供應(yīng)商配套 SDK。第二個(gè)是不要用主機(jī)的 /usr/lib 來滿足交叉編譯的查找種下的錯(cuò)誤會在鏈接后期才爆發(fā)后面第四部分會專門展開。2. 依賴庫的順序排列與版本鎖定剛開始接觸 OpenCV 時(shí)我一直以為它是個(gè)自包含的庫直到有一天在板子上跑 imread 讀取常規(guī)圖片返回的 Mat 是空的才明白它如果想讀 jpg/png就必須在編譯期看到對應(yīng)的解碼后端。這個(gè)道理在交叉編譯場景里更嚴(yán)峻主機(jī)的這些后端庫不能直接復(fù)用必須在編譯 OpenCV 前為目標(biāo)板準(zhǔn)備一套 ARM 版本。2.1 先弄清楚完整依賴圖譜再動手OpenCV 的模塊化結(jié)構(gòu)決定了依賴“按需引入”的魅力。不開 DNN 就不用碰 protobuf不開 GUI 窗口就不用編譯高層的圖形工具庫不加視頻采集功能就不需要外接視頻后端。先做一個(gè)清單再決定每個(gè)模塊要不要。 我日常最常保底的一組是核心、圖像處理、圖像編碼、視頻采集和窗口顯示模塊。圍繞它們依賴可分為以下幾類基本壓縮庫任何帶壓縮性質(zhì)的圖片格式都繞不開的底層庫先編它后面的依賴都直接或間接需要它。圖片格式解碼庫PNG、JPEG、TIFF 三個(gè)常用格式的解碼庫編碼解碼都靠它們完成。攝像頭采集后端V4L2 相關(guān)接口庫Linux 下攝像頭幀采集的標(biāo)準(zhǔn)入口。并行庫選項(xiàng)TBB 這類庫屬于可選項(xiàng)不開啟也可以用 pthread 完成并行但板子核多且性能關(guān)鍵時(shí)往往會加它。我的建議是為了減少環(huán)境不確定第一版編譯只保留核心、圖像處理、圖像編碼、視頻采集這四個(gè)模塊將界面和 DNN 全部關(guān)閉。等版子在板上能跑通最小 Demo再往里加其他模塊。編譯期減少依賴驗(yàn)證周期短出問題時(shí)定位也大幅度快于一次性全量。2.2 交叉編譯依賴庫的通用操作流程依賴庫的構(gòu)建方式各不相同但大體遵循一個(gè)固定姿勢先 configure再 make再 install 到根文件系統(tǒng)目錄。以常見的圖片格式解碼庫為例通常你會見到這樣的功能步驟tar -xzf libxxx.tar.gz cd libxxx ./configure --prefix/opt/arm-rootfs/usr --hostarm-linux-gnueabihf --enable-shared make -j4 make install有一部分庫用 cmake 構(gòu)建的也很常見只要注意兩點(diǎn)指定 CMAKE_INSTALL_PREFIX 指向系統(tǒng)根目錄并讓 cmake 找到同一套交叉工具鏈。在做這一步時(shí)我習(xí)慣用一個(gè)臨時(shí)環(huán)境變量把工具鏈地址帶出來既避免反復(fù)寫活活的路徑也能保證依賴庫之間使用同一條編譯鏈。 編譯順序基本按依賴箭頭反向來最底層的基礎(chǔ)壓縮庫最先編圖片格式解碼庫在上層OpenCV 最后。貪方便打亂順序常常導(dǎo)致鏈接階段 libxxx.so 引用了一堆 undefined reference。如果你發(fā)現(xiàn)一個(gè)庫鏈接時(shí)依賴另一個(gè)庫就回頭重新排一下順序沒有捷徑。2.3 版本選擇的三個(gè)原則依賴庫版本與 OpenCV 版本之間的兼容問題比大多數(shù)人想象的更關(guān)鍵。某次我為了性能直接選了很新的圖片格式解碼庫結(jié)果 OpenCV 的接口調(diào)用方式跟不上報(bào)了一堆隱晦的 undefined symbol。后來換回板子上常用的大版本舊一點(diǎn)的分支立刻安靜下來?？偨Y(jié)出三條可行的原則第一依賴庫版本不要超過 OpenCV 源碼官方分支里對應(yīng)的 README 推薦版本。第二以板子系統(tǒng)里已有庫的版本為中心優(yōu)先匹配主版本一致如果板子已經(jīng)有人驗(yàn)過某個(gè)版本你直接沿用是最安全的。第三編譯依賴庫時(shí)保留窗口的configure參數(shù)日志避免日后需要重建時(shí)無據(jù)可依。環(huán)境變量也可以幫上大忙。交叉編譯時(shí)把 PKG_CONFIG_LIBDIR 指向 /opt/arm-rootfs/usr/lib/pkgconfig并且讓它只定位到系統(tǒng)根目錄里的 .pc 文件這樣 OpenCV 在查依賴時(shí)就不會撞到主機(jī)上的同名文件。在我某次操作中這個(gè)變量一度是腳本里最關(guān)鍵的一行少了它再標(biāo)準(zhǔn)的前綴設(shè)置都可能前功盡棄。3. 用構(gòu)建系統(tǒng)配置 OpenCV 的關(guān)鍵參數(shù)OpenCV 從 3.x 時(shí)代開始全面轉(zhuǎn)向 CMake到了 4.x 幾乎只有 CMake 一條路。交叉編譯時(shí)CMake 的配置參數(shù)直接決定生成的庫是給 x86 用的還是給 ARM 用的。很多第一次搞的人打開 CMake 界面就蒙我就把最關(guān)鍵的一組參數(shù)與一個(gè)可復(fù)用的配置文件寫下來這套配置翻過整個(gè) ARM 團(tuán)隊(duì)后還會繼續(xù)用到。3.1 一份可用的交叉編譯配置文件在 OpenCV 源碼目錄之外放一個(gè)單獨(dú)的文件名字就叫 toolchain.arm.cmake內(nèi)容大致如下set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(TOOLCHAIN_PREFIX arm-linux-gnueabihf) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}-gcc) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}-g) set(CMAKE_SYSROOT /opt/arm-rootfs) set(CMAKE_FIND_ROOT_PATH /opt/arm-rootfs) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)也許你會問這第九行是什么意思前三行明確目標(biāo)系統(tǒng)是 ARM Linux告訴 CMake 不要走 x86 的文件路徑第四到第六行把編譯器切換成交叉工具鏈第七行設(shè)置系統(tǒng)根目錄最后四行限定查找程序、庫、頭文件、包時(shí)的路徑模式。PROGRAM NEVER 保證它去找主機(jī)命令而不是在根文件系統(tǒng)里找開發(fā)工具后面三個(gè) ONLY 則強(qiáng)制所有庫和頭文件只從目標(biāo)根文件系統(tǒng)里找隔離主機(jī)干擾。 如果用 AArch64 板子只需要把 TOOLCHAIN_PREFIX 換成 aarch64-linux-gnu。關(guān)于 arm-linux-gnueabihf 和 arm-linux-gnueabi 的區(qū)別簡單講gnueabi 對應(yīng)軟浮點(diǎn)gnueabihf 對應(yīng)硬浮點(diǎn)絕大多數(shù)現(xiàn)代 ARM Linux 系統(tǒng)都用硬浮點(diǎn)工具鏈但老版本內(nèi)核和舊板子可能只有軟浮點(diǎn)版本這從 boot 時(shí)打印的 CPU 信息能看出來。3.2 決定最終產(chǎn)物的模塊選項(xiàng)配置的時(shí)候OpenCV 默認(rèn)會嘗試把能編的模塊都編上這可能不是你想要的。用 BUILD_LIST 壓縮模塊集合往往能省下大量時(shí)間與磁盤空間還能減少被依賴的第三方庫范圍。我的這組參數(shù)一直拿來反復(fù)用cmake -S . -B build-arm \ -DCMAKE_TOOLCHAIN_FILE../toolchain.arm.cmake \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX/usr/local/opencv-arm \ -DBUILD_LISTcore,imgproc,imgcodecs,videoio,highgui \ -DWITH_OPENCLOFF \ -DWITH_OPENMPOFF \ -DWITH_TBBOFF \ -DWITH_GTKOFF \ -DWITH_V4LON \ -DBUILD_SHARED_LIBSON關(guān)鍵選項(xiàng)的含義我列個(gè)表比事后猜含義方便參數(shù)取值作用與理由BUILD_LISTcore,imgproc,...只編譯必要的模塊減少依賴與體積WITH_GTKOFF不編 GUI 后端絕大多數(shù)無屏幕板子用不到WITH_V4LON打開 Linux 視頻采集后端攝像頭場景需要BUILD_SHARED_LIBSON默認(rèn)生成 .so方便排查問題后面可再改靜態(tài)方案WITH_OPENMP按需板子核心多且追求速度才開多核小內(nèi)存慎用WITH_TBB按需引入并行庫會帶來額外依賴先 OFF跑通后再試如果你之后需要用 OpenCV 的 DNN 模塊跑神經(jīng)網(wǎng)絡(luò)還得把 DNN 加入 BUILD_LIST同時(shí)準(zhǔn)備 protobuf 依賴。建議第一版全部關(guān)閉穩(wěn)字當(dāng)頭。3.3 指令集優(yōu)化NEON 與 VFPv4 的啟用邊界ARM 平臺的性能優(yōu)化往往繞不開 NEON 指令集OpenCV 4.x 在 CMake 里對 ARM 優(yōu)化有比較直觀的控制方式。局部板子若是 ARMv7通常會在命令行加上 -DCPU_BASELINENEON,VFPV3 或類似參數(shù)如果板子支持 VFPv4則寫成 NEON,VFPV4。過早地全局泛化會出問題尤其當(dāng)你手里的板子其實(shí)不支持某些指令時(shí)貿(mào)然打開 NEON 會讓編譯出的庫在運(yùn)行階段直接非法指令。 我有一個(gè)穩(wěn)妥做法先在板內(nèi)看 /proc/cpuinfo 的 Features 是否包含 neon再決定要不要開啟。若包含在 CMake 參數(shù)里加上 NEON若不包含寧可什么也別動用通用編譯參數(shù)。對于 AArch64 架構(gòu)NEON 是默認(rèn)啟用且沒有選擇的余地再去手動加反而多余。 還要特別提醒一個(gè)坑不要在交叉編譯環(huán)境里使用 -mcpunative它會把編譯器所在的主機(jī) CPU 特性當(dāng)成目標(biāo) CPU 特性釀成的在板子上必崩無疑。目標(biāo)板具體用什么 CPU就寫什么 CPU比如明確指定 -mcpucortex-a7而不是依賴宿主機(jī)自動探測。4. 編譯鏈接階段最容易踩的坑依賴就緒、CMake 參數(shù)入湖進(jìn)入真正 make 階段好戲才剛開始。在 x86 上非常正常的命令到了 ARM 交叉編譯環(huán)境卻可能冒出一整套秀存在感的報(bào)錯(cuò)。這一節(jié)記下我自己遇到的三類真問題不看報(bào)錯(cuò)本身先看環(huán)境因素。4.1 編譯崩潰不一定是內(nèi)存不足我第一次在筆記本電腦上跑 OpenCV 全量交叉編譯時(shí)順手用了 make -j12結(jié)果編到中段 GCC 進(jìn)程莫名被殺死終端輸出一欄一欄的 Killed。當(dāng)時(shí)下意識覺得是磁盤空間問題后來用 free -h 看到是內(nèi)存耗盡大量并行編譯進(jìn)程占滿內(nèi)存系統(tǒng)開始把編譯進(jìn)程殺掉控制臺卻不報(bào)詳細(xì)的編譯錯(cuò)誤。 交叉編譯對主機(jī)內(nèi)存的要求往往被低估尤其 OpenCV 這類 C 模板大戶每個(gè)編譯單元都可能讓人內(nèi)存達(dá)到一兩百 MB。解圍辦法很簡單先降到 make -j4如果還是被殺死就降 -j2同時(shí)確認(rèn) temp 分區(qū)剩余內(nèi)存足夠。后續(xù)我組包里特意保留自主板的多次 -j4極少再出問題。附加建議關(guān)閉其他大量占用內(nèi)存的應(yīng)用再用 make -j$(nproc) 直接胡來的情況必須忍住只在你確認(rèn)內(nèi)存充裕時(shí)才用。4.2 鏈接 error 時(shí)先檢查文件屬性而非看錯(cuò)信息提示錯(cuò)誤大多數(shù)是 undefined reference to xxx或者 cannot find -lxxx。這倆時(shí)候第一反應(yīng)是去補(bǔ)什么包那就容易誤判。真正原因經(jīng)常是它在系統(tǒng)根目錄里找到的庫文件其實(shí)是 x86 版本或者是兩個(gè)不同架構(gòu)的庫被 CMake 串在一起。 我的排查順序先定位報(bào)錯(cuò)里涉及的 .so 文件在哪個(gè)目錄然后執(zhí)行 file /路徑/libxxx.so看輸出的架構(gòu)描述。它應(yīng)該是類似 ELF 32-bit LSB shared object, ARM, EABI5 這樣的結(jié)果。如果看到 x86-64就說明庫是從主機(jī)帶進(jìn)去的交叉編譯過程根本不該用。此時(shí)回到依賴庫編譯安裝那一步重新在系統(tǒng)根目錄里安裝 ARM 版本。 第二個(gè)反復(fù)遇到的鏈接問題是某個(gè)依賴庫確實(shí)編好了但 OpenCV 仍然說找不到。這通常是 CMAKE_FIND_ROOT_PATH 沒設(shè)置或者設(shè)置了配置里少加了 ONLY 模式。系統(tǒng)根目錄里明明有對應(yīng)版本卻找不到優(yōu)先回看 3.1 節(jié)里的配置文件把查找模式的四個(gè)參數(shù)一個(gè)一個(gè)對齊。4.3 運(yùn)行時(shí)非法指令常見誘因編譯鏈接順利通過并不代表萬事大吉。復(fù)制到板子上一分鐘跑程序直接崩掉后臺常常給出 Illegal instruction (core dumped)這就是典型的編譯時(shí)啟用了目標(biāo)板不支持指令的表現(xiàn)。我經(jīng)歷過一次狼狽。某塊核芯其實(shí)支持 Cortex-A7但我在編譯參數(shù)里寫了更適合更新處理器的 NEON 變體運(yùn)行時(shí)直接打到非法指令上。 這類問題的排查邏輯是反向的先確認(rèn)編譯時(shí)開過哪些指令優(yōu)化參數(shù)再核對板子 /proc/cpuinfo 里的 Features。如果編譯時(shí)啟用 NEON但板子的 Features 里連 neon 都沒有那么程序大概率就是這樣崩去掉相關(guān)參數(shù)重編即可。另一個(gè)更省事的辦法在板子上執(zhí)行 readelf -A 可執(zhí)行文件名查看 Tag_CPU_arch 和 Tag_NEON_preserved 之類的標(biāo)記對比板子的實(shí)際能力你很快就知道自己編出了什么水平的產(chǎn)物。 有時(shí)候非法指令與可用變量不夠有關(guān)系比如低版本內(nèi)核配高版本編譯庫但這很少見。先從指令集、從工具鏈和板子的匹配度排查是永遠(yuǎn)用在最前面的方向。5. 部署到 ARM 板上的驗(yàn)證方法等 make 完成你的構(gòu)建目錄里會生成一批 .so 和可執(zhí)行程序。不要急著把整個(gè)目錄復(fù)制到板子上更好的思路是設(shè)定一個(gè)清晰的目標(biāo)目錄結(jié)構(gòu)把需要的東西統(tǒng)一收集起來再同步過去。這一節(jié)講講安裝階段和上板驗(yàn)證的細(xì)節(jié)。5.1 兩個(gè)安裝路徑的區(qū)別在 CMake 配置里有兩個(gè)容易弄混的概念CMAKE_INSTALL_PREFIX 決定安裝到哪個(gè)前綴目錄DESTDIR 是臨時(shí)把一個(gè)安裝過程重定向到指定根目錄的手段。 我的習(xí)慣是先指定 CMAKE_INSTALL_PREFIX/usr/local/opencv-arm然后在 make 完成后的安裝階段使用臨時(shí)目錄make install DESTDIR/tmp/opencv-arm-target/這會在 /tmp/opencv-arm-target/usr/local/opencv-arm 下生成完整的頭文件與動態(tài)庫。然后我只需要把 /tmp/opencv-arm-target/ 里的內(nèi)容按目錄結(jié)構(gòu)拷貝到板子根目錄再在板子上把 /usr/local/opencv-arm/lib 加入動態(tài)庫搜索路徑即可。 當(dāng)初一開始用的是直接把安裝前綴指向系統(tǒng)根目錄 /usr后來發(fā)現(xiàn)這樣極易污染宿主機(jī)的環(huán)境也不方便多版本管理。用 DESTDIR 的臨時(shí)目錄做法宿主機(jī)完全隔離板子端也隨時(shí)可以刪掉整個(gè)目錄不需要重裝系統(tǒng)驗(yàn)證。5.2 編譯一個(gè)最小驗(yàn)證程序到了這一步最急迫的就是用一段足夠簡單、又能覆蓋基礎(chǔ)功能的程序驗(yàn)證 OpenCV 是否真正可用。我多次用來驗(yàn)證的就是圖像讀取加灰度轉(zhuǎn)換#include stdio.h #include opencv2/opencv.hpp int main(int argc, char** argv) { if (argc 2) { printf(usage: %s image.jpg\n, argv[0]); return 1; } cv::Mat img cv::imread(argv[1]); if (img.empty()) { printf(imread failed\n); return 1; } cv::Mat gray; cv::cvtColor(img, gray, cv::COLOR_BGR2GRAY); printf(image size: %d x %d\n, img.cols, img.rows); printf(gray pixel[0,0]: %d\n, gray.atuchar(0, 0)); return 0; }編譯時(shí)直接指定 OpenCV 的頭文件和庫目錄至少這種明確路徑不依賴板子上的 pkg-config便于排查問題arm-linux-gnueabihf-g demo.cpp \ -I/tmp/opencv-arm-target/usr/local/opencv-arm/include/opencv4 \ -L/tmp/opencv-arm-target/usr/local/opencv-arm/lib \ -lopencv_core -lopencv_imgproc -lopencv_imgcodecs \ -o vision_demo把 vision_demo 與一張普通圖片 copy 到板子執(zhí)行 /vision_demo test.jpg。如果打印 output 正常說明最核心的 core、imgproc、imgcodecs 模塊二次鏈接無誤到這一步Arm 移植流程就基本跑通了。5.3 運(yùn)行時(shí)依賴是否齊全怎么判斷上板運(yùn)行也常有看到 error while loading shared libraries: libopencv_core.so.408: cannot open shared object file 之類輸出。這并不一定是 OpenCV 沒安裝到位而是系統(tǒng)動態(tài)鏈接器沒找到庫路徑。 在板子上執(zhí)行 ldd vision_demo會列出程序依賴的每個(gè)動態(tài)庫及搜索到的位置。像 libopencv_core.so.408 或 libstdc.so.6 顯示 not found就證明路徑配置不完整。簡單直接的方案是在板子上的 /etc/ld.so.conf 里加入一行 /usr/local/opencv-arm/lib再執(zhí)行 ldconfig讓系統(tǒng)重新掃描并建立鏈接緩存。 用 ldd 時(shí)順帶看一下 librt、libpthread 等依賴的指向如果某些基礎(chǔ)庫指向宿主機(jī)的 x86 版本抓取到板子上無意義需要回根文件系統(tǒng)里替換。判定是否標(biāo)準(zhǔn)首先要看目標(biāo)板系統(tǒng)根目錄里的同名庫版本與工具鏈自帶的 sysroot 是否同源如果版本不一致重新編譯對應(yīng)依賴庫是穩(wěn)妥路線。6. 圍繞性能與二次開發(fā)的實(shí)際調(diào)優(yōu)建議一旦最小 Demo 跑通剩下的問題就轉(zhuǎn)到“怎么更快、更省地方”。OpenCV 在 ARM 上有不少可以擠壓的余地但前提是要尊重板子本身的能力不要盲目跟風(fēng)開優(yōu)化選項(xiàng)。6.1 先測量再開啟優(yōu)化我有一次非常典型的經(jīng)歷在項(xiàng)目里聽說 NEON 對圖像處理加速效果明顯直接全量 NEON 編譯滿心以為板子上的圖像縮放性能會翻倍結(jié)果實(shí)測發(fā)現(xiàn)提升比預(yù)期低很多因?yàn)樗惴ù蟛糠謺r(shí)間卡在內(nèi)存拷貝上甚至有些場景因隨機(jī)訪問反而更慢。 所以任何優(yōu)化都要先有一個(gè)基準(zhǔn)數(shù)據(jù)。在板子上執(zhí)行一輪簡單的計(jì)時(shí)比如對同一張 720x480 圖片做 100 次縮放或?yàn)V波記錄平均耗時(shí)。之后開啟優(yōu)化選項(xiàng)再跑同一套數(shù)據(jù)對比才有效。不要依賴直觀感受圖像縮放這類操作在 ARM 上用 NEON 確實(shí)能快不少但如果瓶頸在內(nèi)存帶寬盲目 NEON 不會帶來質(zhì)變。 并行方面也有同樣的原則。TBB 或 OpenMP 都要產(chǎn)生線程管理成本若板子是二核四核且算法圖像較小你需要考慮開并行帶來的收益。我一般先關(guān)掉并行測試一次再打開并行對比一次確認(rèn)真正快了才會保留配置。這一原則對嵌入式視覺相當(dāng)有效。6.2 裁剪模塊與控制動態(tài)庫數(shù)量嵌入式產(chǎn)品發(fā)布時(shí)最關(guān)心可執(zhí)行產(chǎn)物體積與依賴數(shù)量。完整版 OpenCV 動態(tài)庫非常多安裝目錄動輒幾百 MB 甚至更大這在醫(yī)療、工業(yè)級設(shè)備上可以接受但在存儲緊張的板子上就遭罪了。我的建議根據(jù)項(xiàng)目實(shí)際算法邏輯精確設(shè)計(jì)模塊剪紙凡是沒用到的模塊一律不要編進(jìn)去。 BUILD_LIST 就是裁剪的有效入口。我自己的例子只留 core、imgproc、imgcodecs、videoio、highgui 五個(gè)模塊后安裝目錄體積能下降到幾百 MB 的四分之一左右。若后續(xù)不需要視頻捕獲把 videoio 去掉還能再少一截。DNN 如果不涉及神經(jīng)網(wǎng)絡(luò)推理堅(jiān)決不納入。 動態(tài)鏈接庫太多也影響啟動時(shí)間。產(chǎn)品最終形態(tài)可以把 OpenCV 與主程序一起靜態(tài)鏈接生成單個(gè)可執(zhí)行文件方便拷貝部署但開發(fā)階段保持動態(tài)庫方式更舒服出錯(cuò)時(shí)不必反復(fù)重編。我在驗(yàn)證階段用動態(tài)庫出產(chǎn)品時(shí)再默認(rèn)調(diào)成靜態(tài)是相對平衡的方案。6.3 值得固化的移植流程走過的彎路都折騰完后建議把所有步驟沉淀成腳本否則三個(gè)月后再升級版本又要重新踩一遍。參考下列一個(gè)極簡腳本結(jié)構(gòu)把主干留下來#!/bin/bash export ROOTFS/opt/arm-rootfs export TOOLCHAINarm-linux-gnueabihf export PKG_CONFIG_LIBDIR${ROOTFS}/usr/lib/pkgconfig build_dep() { cd $1 ./configure --prefix${ROOTFS}/usr --host${TOOLCHAIN} make -j4 make install } build_dep zlib build_dep libpng build_dep libjpeg # 其余依賴類似 cmake -S opencv -B build-arm \ -DCMAKE_TOOLCHAIN_FILEtoolchain.arm.cmake \ -DCMAKE_BUILD_TYPERelease \ -DBUILD_LISTcore,imgproc,imgcodecs,videoio,highgui \ -DWITH_V4LON -DWITH_GTKOFF cmake --build build-arm -j4 make install DESTDIR/tmp/opencv-arm-target再配合拉一頁簡單的記錄寫明各依賴庫的版本號、CMake選項(xiàng)、測試結(jié)果以后在不同板子間復(fù)用摩目時(shí)會順很多。我上一輪完全照著這套腳本從一個(gè)平臺復(fù)刻到另一個(gè)相同架構(gòu)的板子除了工具鏈路徑略改幾乎沒有再花一個(gè)下午一起去調(diào)環(huán)境。如果你手頭還有幾塊不同板子正等著部署可以把這個(gè)流程當(dāng)作繼續(xù)往下走的模板。