1. 項目概述電賽E題的挑戰(zhàn)與應(yīng)對全國大學(xué)生電子設(shè)計競賽電賽的E題歷來是視覺識別與控制類賽題的“重災(zāi)區(qū)”也是最能拉開隊伍差距的戰(zhàn)場。2023年的E題不出意外地再次將視覺處理、運動控制和系統(tǒng)集成推到了聚光燈下。題目要求看似明確——識別特定目標(biāo)、控制執(zhí)行機構(gòu)完成動作——但背后隱藏的“坑”卻一個比一個深。從核心的視覺識別模塊選型K210、OpenMV、樹莓派、Jetson Nano到它們與主控如STM32的穩(wěn)定通信再到整個系統(tǒng)的實時性與魯棒性每一步都可能成為壓垮駱駝的最后一根稻草。我見過太多隊伍硬件焊得漂亮代碼邏輯清晰卻在比賽現(xiàn)場因為圖像傳輸丟幀、串口通信亂碼、算法延遲過高這些“小問題”而功虧一簣。這篇文章就是基于我和身邊朋友們多次參賽、備賽的血淚教訓(xùn)系統(tǒng)性地梳理在2023年電賽E題以及類似視覺控制題目中你極大概率會遇到的典型問題并提供經(jīng)過實戰(zhàn)檢驗的、可操作的解決方法。無論你是第一次參賽的新手還是想優(yōu)化方案的老手這些從泥坑里爬出來的經(jīng)驗或許能幫你少走一半的彎路。2. 核心視覺模塊的選型陷阱與避坑指南視覺是E題的“眼睛”選錯了“眼睛”后續(xù)所有工作都事倍功半。K210、OpenMV、樹莓派、Jetson Nano是當(dāng)前最主流的四個選項但它們各有各的脾氣絕不是簡單的性能高低排序。2.1 K210極致性價比下的“握手”難題K210以其內(nèi)置的KPU神經(jīng)網(wǎng)絡(luò)處理器和極低的功耗成為識別固定、簡單目標(biāo)的性價比之王。但它最大的“坑”在于開發(fā)環(huán)境與固件下載。問題一固件下載“握手失敗”這是新手遇到的第一道攔路虎。當(dāng)你興致勃勃地連接K210打開K-Flash工具選擇好固件.bin或.kfpkg文件點擊下載卻彈出一個冰冷的“握手失敗”提示。99%的原因出在驅(qū)動和串口占用上。K210在下載模式按住BOOT鍵再上電下會變成一個USB串口設(shè)備如果系統(tǒng)沒有正確安裝驅(qū)動或者這個串口被其他軟件如你之前打開的串口調(diào)試助手、OpenMV IDE等占用握手就會失敗。解決方法實錄驅(qū)動是根基務(wù)必使用官方或社區(qū)推薦的CH340/CH341驅(qū)動。在設(shè)備管理器中當(dāng)K210進(jìn)入下載模式后你應(yīng)該能看到一個“USB-SERIAL CH340”之類的端口。如果顯示為未知設(shè)備就手動指定驅(qū)動安裝。獨占式操作進(jìn)行下載操作前關(guān)閉一切可能占用該串口的軟件包括但不限于Thonny、OpenMV IDE、串口調(diào)試助手、VSCode的串口插件等。在Windows下甚至可以去“設(shè)備管理器”里確認(rèn)該端口沒有被標(biāo)記為“正在使用”。硬件操作要精準(zhǔn)先按住板子上的BOOT或BTL鍵不松手再給板子上電或按復(fù)位鍵最后再點擊下載軟件的開始按鈕。這個時序很重要松手太早芯片就進(jìn)入正常運行模式了。固件匹配是關(guān)鍵確認(rèn)你下載的固件版本與你的開發(fā)板以及你打算使用的SDK如MaixPy、NNCASE相匹配。用錯了固件即使下載成功也無法運行。注意有些K210開發(fā)板如Sipeed的Maix系列會使用JTAG接口進(jìn)行下載這就需要用到專門的調(diào)試器如FT2232并配置OpenOCD等工具其復(fù)雜程度遠(yuǎn)超USB下載。比賽時間有限強烈建議選擇USB下載方案清晰的板卡。問題二圖像識別模型部署后的性能不達(dá)標(biāo)你成功訓(xùn)練了一個識別準(zhǔn)確率99%的模型轉(zhuǎn)換成K210支持的.kmodel格式后在開發(fā)板上跑起來卻發(fā)現(xiàn)幀率極低或者識別框亂跳。這往往不是模型問題而是預(yù)處理和后處理代碼效率太低。實操心得 K210的KPU負(fù)責(zé)前向推理快但CPU雙核64位RISC-V處理圖像縮放、顏色空間轉(zhuǎn)換、畫框等操作的能力相對較弱。務(wù)必在PC端完成所有圖像預(yù)處理如縮放到模型輸入尺寸224x224并將預(yù)處理步驟如裁剪、縮放參數(shù)固定下來避免在K210上做動態(tài)計算。畫框和輸出等操作盡量使用硬件加速的LCD顯示函數(shù)或者直接輸出坐標(biāo)數(shù)據(jù)減少在圖像矩陣上的Python級操作。2.2 OpenMV簡單易用背后的“內(nèi)存墻”O(jiān)penMV的IDE和豐富的庫函數(shù)讓它上手極快對于顏色追蹤、二維碼識別等任務(wù)幾乎是開箱即用。但其基于STM32H7的核心性能和內(nèi)存是硬傷。問題一運行復(fù)雜腳本時提示“內(nèi)存不足”O(jiān)penMV Cam H7 Plus雖然有32MB外部RAM但當(dāng)你同時啟用高分辨率圖像采集、顏色識別、特征點檢測和串口通信時很容易就碰到內(nèi)存天花板。錯誤提示可能直接是“MemoryError”或者表現(xiàn)為程序莫名重啟。解決方法實錄圖像分辨率是內(nèi)存消耗大戶除非必要否則不要使用全分辨率如OV7725的640x480。對于巡線或識別特定色塊QVGA320x240甚至QQVGA160x120分辨率完全足夠且處理速度會快數(shù)倍。使用sensor.set_windowing函數(shù)可以進(jìn)一步裁剪感興趣區(qū)域ROI這是節(jié)省內(nèi)存和提升速度最有效的方法。及時釋放不再使用的對象在循環(huán)中創(chuàng)建的圖像對象、列表、字典等如果不再使用可以手動將其賦值為None或者利用函數(shù)作用域使其被自動回收。凍結(jié)模塊OpenMV IDE允許你將常用的庫如pyb、sensor凍結(jié)編譯到固件中這樣可以節(jié)省寶貴的RAM空間。在項目-設(shè)置中可以進(jìn)行此操作。流式處理避免緩存對于圖像傳輸使用image.compress()進(jìn)行JPEG壓縮后再通過串口發(fā)送而不是發(fā)送原始的RGB565字節(jié)流能極大減少內(nèi)存壓力和傳輸時間。問題二與STM32通信數(shù)據(jù)錯亂OpenMV通過UART發(fā)送數(shù)據(jù)給STM32STM32卻收到一堆亂碼或者數(shù)據(jù)包拼接錯誤。這是串口異步通信最經(jīng)典的問題。實操心得制定嚴(yán)格的通信協(xié)議絕不能只發(fā)送純數(shù)字。推薦使用幀頭數(shù)據(jù)校驗和幀尾的格式。例如0xAA幀頭 [x_high, x_low, y_high, y_low]2字節(jié)x坐標(biāo)2字節(jié)y坐標(biāo) checksum前面所有字節(jié)的和的低8位 0x55幀尾。STM32端以狀態(tài)機的方式解析只有收到完整且校驗正確的幀才進(jìn)行處理。統(tǒng)一波特率與設(shè)置雙方波特率如115200必須一致。同時數(shù)據(jù)位8、停止位1、奇偶校驗位無這些參數(shù)也要在初始化時明確設(shè)置并確保一致。清空緩沖區(qū)在每次發(fā)送或接收關(guān)鍵指令前可以嘗試清空串口緩沖區(qū)避免舊數(shù)據(jù)干擾。2.3 樹莓派強大生態(tài)與供電的“平衡木”樹莓派4B運行完整的Linux系統(tǒng)和OpenCV處理能力強大但隨之而來的是功耗、穩(wěn)定性和實時性的挑戰(zhàn)。問題一樹莓派4B在比賽中無故死機或重啟這幾乎是電源問題導(dǎo)致的。樹莓派4B滿載時峰值電流可達(dá)3A官方推薦使用5V/3A的Type-C電源。許多隊伍使用移動電源或劣質(zhì)電源適配器在攝像頭啟動、電機轉(zhuǎn)動等大電流瞬間電壓被拉低導(dǎo)致樹莓派欠壓重啟此時紅燈會閃爍。解決方法實錄電源是生命線務(wù)必使用足額5V/3A以上且質(zhì)量可靠的電源適配器。檢查電源線劣質(zhì)線材內(nèi)阻大也會導(dǎo)致壓降?？梢灾苯佑萌f用表測量樹莓派40Pin引腳上的5V和GND之間的電壓在滿載時不應(yīng)低于4.8V。外設(shè)供電分離如果驅(qū)動電機、舵機等大功率負(fù)載絕對不要從樹莓派的GPIO或USB口取電必須使用獨立的電機驅(qū)動模塊和電源為執(zhí)行機構(gòu)供電樹莓派只提供控制信號PWM/GPIO。電源地GND需要共接。軟件降頻保穩(wěn)定如果任務(wù)不復(fù)雜可以適當(dāng)降低CPU頻率在/boot/config.txt中設(shè)置arm_freq1200默認(rèn)是1500或關(guān)閉不必要的服務(wù)如藍(lán)牙、HDMI以減少功耗和發(fā)熱。問題二攝像頭圖像采集延遲高或不穩(wěn)定使用picamera或cv2.VideoCapture讀取CSI攝像頭時感覺畫面“卡頓”或者處理幀率遠(yuǎn)低于攝像頭標(biāo)稱值。實操心得選擇正確的庫和參數(shù)對于樹莓派專用CSI攝像頭picamera2庫基于libcamera是目前性能最佳的選擇它提供了更底層的控制。設(shè)置分辨率時不要盲目追求最高。處理640x480的圖像比處理1080p快得多。使用Picamera2時可以配置controls中的FrameRate來限制幀率匹配你的處理能力。啟用硬件加速確保在/boot/config.txt中開啟了GPU內(nèi)存分配如gpu_mem128。對于H.264編碼等操作硬件加速能極大減輕CPU負(fù)擔(dān)。多線程/多進(jìn)程處理將圖像采集放在一個獨立的線程中不斷更新一個全局圖像變量處理線程從該變量中讀取最新幀進(jìn)行處理。這可以避免因處理算法耗時導(dǎo)致的采集阻塞。但要注意線程間同步如使用鎖防止讀到不完整的圖像。2.4 Jetson Nano性能怪獸與散熱困境Jetson Nano擁有128核GPU能跑YOLOv5這樣的現(xiàn)代檢測模型但它的功耗和散熱問題在封閉的比賽環(huán)境中尤為突出。問題一運行一段時間后性能驟降甚至卡死這是典型的過熱降頻Thermal Throttling。Jetson Nano在核心溫度超過閾值約70°C后會自動降低CPU和GPU頻率以保護(hù)硬件導(dǎo)致程序變慢惡性循環(huán)直至卡死。解決方法實錄主動散熱是必須的官方套件里的散熱片根本不夠用。必須加裝風(fēng)扇并且要確保風(fēng)道暢通。你可以通過命令tegrastats實時監(jiān)控溫度和各核心頻率。一旦看到溫度持續(xù)在60°C以上頻率開始波動就是降頻的前兆。調(diào)整電源模式Jetson Nano有5W和10W兩種模式。默認(rèn)是5W模式以控制發(fā)熱。如果你需要全力性能可以切換到10W模式使用sudo nvpmodel -m 0但務(wù)必配合強力的主動散熱。比賽時如果任務(wù)不是持續(xù)滿載可以嘗試在/etc/nvpmodel.conf中自定義一個中間模式在性能和發(fā)熱間取得平衡。優(yōu)化推理負(fù)載使用TensorRT對訓(xùn)練好的YOLO模型進(jìn)行優(yōu)化和量化如FP16或INT8不僅能大幅提升推理速度還能降低GPU占用和發(fā)熱。這是發(fā)揮Jetson潛力的關(guān)鍵一步。問題二部署YOLOv5等復(fù)雜模型時環(huán)境配置復(fù)雜在Jetson Nano的ARM架構(gòu)上安裝PyTorch、TorchVision以及各種依賴常常因為網(wǎng)絡(luò)問題或版本沖突失敗。實操心得使用NVIDIA官方提供的輪子這是最穩(wěn)妥的方法。NVIDIA為不同版本的JetPack SDK提供了預(yù)編譯的PyTorch、TorchVision等wheel包。先去NVIDIA開發(fā)者論壇找到與你JetPack版本如4.6匹配的PyTorch版本如1.10.0的下載鏈接用wget下載后再用pip install安裝比直接用pip從源下載編譯要快得多也穩(wěn)定得多。換源加速基礎(chǔ)安裝在安裝其他Python包或系統(tǒng)包時將Ubuntu的apt源和pip源換成國內(nèi)鏡像如清華、中科大源能極大提升成功率節(jié)省寶貴的比賽時間。對于sudo apt-get update失敗的問題檢查/etc/apt/sources.list和/etc/apt/sources.list.d/下的文件中的源地址是否正確。3. 系統(tǒng)集成與通信的致命細(xì)節(jié)視覺模塊穩(wěn)定了只是萬里長征第一步。如何讓它與主控通常是STM32穩(wěn)定、高效地“對話”是整個系統(tǒng)流暢運行的關(guān)鍵。3.1 通信協(xié)議設(shè)計從“能用”到“可靠”很多隊伍直接用串口發(fā)送一個數(shù)字比如printf(“%d”, x_coordinate)這在實驗室靜態(tài)測試時可能沒問題但到了比賽現(xiàn)場電磁環(huán)境復(fù)雜一個干擾就可能讓STM32收到“12345”的一部分“12”或“345”導(dǎo)致坐標(biāo)解析完全錯誤。解決方案自定義輕量級幀協(xié)議這里給出一個經(jīng)過驗證的、簡單有效的協(xié)議格式適用于UART通信[幀頭1] [幀頭2] [數(shù)據(jù)長度] [命令字] [數(shù)據(jù)區(qū)] [校驗和]幀頭固定兩個字節(jié)如0xAA和0x55用于標(biāo)識一幀的開始。使用兩個字節(jié)可以降低數(shù)據(jù)區(qū)中偶然出現(xiàn)幀頭值的概率。數(shù)據(jù)長度1個字節(jié)表示命令字?jǐn)?shù)據(jù)區(qū)的總字節(jié)數(shù)。方便接收方動態(tài)解析。命令字1個字節(jié)標(biāo)識數(shù)據(jù)類型。例如0x01代表目標(biāo)坐標(biāo)0x02代表系統(tǒng)狀態(tài)0x03代表控制指令。數(shù)據(jù)區(qū)可變長度根據(jù)命令字來定義。例如對于坐標(biāo)(x, y)可以用4個字節(jié)表示前兩字節(jié)為x后兩字節(jié)為y。校驗和1個字節(jié)通常為從幀頭1到數(shù)據(jù)區(qū)最后一個字節(jié)的所有字節(jié)的累加和或異或和的低8位。用于驗證數(shù)據(jù)在傳輸過程中是否出錯。在STM32端的解析器狀態(tài)機偽代碼思路typedef enum {STATE_HEADER1, STATE_HEADER2, STATE_LENGTH, STATE_CMD, STATE_DATA, STATE_CHECKSUM} UART_State; UART_State state STATE_HEADER1; uint8_t rx_buffer[MAX_LEN]; uint8_t data_len, data_index, cmd; uint8_t calculated_checksum, received_checksum; void UART_IRQ_Handler() { uint8_t byte USART_ReceiveData(); switch(state) { case STATE_HEADER1: if(byte 0xAA) state STATE_HEADER2; break; case STATE_HEADER2: if(byte 0x55) state STATE_LENGTH; else state STATE_HEADER1; // 同步失敗回溯 break; case STATE_LENGTH: data_len byte; data_index 0; state STATE_CMD; break; case STATE_CMD: cmd byte; data_len--; if(data_len 0) state STATE_DATA; else state STATE_CHECKSUM; break; case STATE_DATA: rx_buffer[data_index] byte; if(--data_len 0) state STATE_CHECKSUM; break; case STATE_CHECKSUM: received_checksum byte; calculated_checksum ... // 計算之前所有字節(jié)的校驗和 if(calculated_checksum received_checksum) { // 校驗通過處理有效數(shù)據(jù)包 process_packet(cmd, rx_buffer); } state STATE_HEADER1; // 無論對錯回到初始狀態(tài)尋找下一幀 break; } }這個狀態(tài)機確保了只有完整、正確的幀才會被處理有效抵抗了數(shù)據(jù)錯位和干擾。3.2 實時性保障當(dāng)視覺遇到控制視覺處理需要時間幾十到幾百毫秒而控制周期如PID控制往往要求更快幾毫秒到幾十毫秒。直接讓STM32等待視覺數(shù)據(jù)再進(jìn)行控制必然導(dǎo)致系統(tǒng)響應(yīng)遲緩、卡頓。解決方案雙緩沖區(qū)與時間戳機制在STM32側(cè)建立數(shù)據(jù)雙緩沖區(qū)定義兩個結(jié)構(gòu)體緩沖區(qū)BufferA和BufferB以及一個指向當(dāng)前可讀緩沖區(qū)的指針pCurrentData。非阻塞接收與更新在串口中斷中當(dāng)解析完一包有效的視覺數(shù)據(jù)后不直接用于控制計算而是將其寫入非當(dāng)前的緩沖區(qū)例如如果pCurrentData指向BufferA則新數(shù)據(jù)寫入BufferB。原子性切換寫入完成后在一個安全的地方如主循環(huán)開始或一個定時中斷中快速地、原子性地切換pCurrentData指針指向新的緩沖區(qū)指向BufferB。這個操作必須極快且不能被中斷打斷通?？梢酝ㄟ^暫時關(guān)閉全局中斷來實現(xiàn)。控制循環(huán)使用穩(wěn)定數(shù)據(jù)控制算法PID計算始終從pCurrentData指向的緩沖區(qū)讀取數(shù)據(jù)。這樣控制循環(huán)總能用到“最新且完整”的一幀數(shù)據(jù)而不會讀到正在被更新的半成品數(shù)據(jù)。視覺數(shù)據(jù)的更新和控制循環(huán)的執(zhí)行在時間上就解耦了。加入時間戳在視覺數(shù)據(jù)包中附帶一個由視覺模塊生成的、單調(diào)遞增的時間戳或幀編號。STM32在收到數(shù)據(jù)后記錄其時間戳?？刂扑惴ú粌H可以讀取坐標(biāo)還可以根據(jù)當(dāng)前時間與數(shù)據(jù)時間戳的差值估算出數(shù)據(jù)的“新鮮度”。如果數(shù)據(jù)過于陳舊比如超過200ms控制算法可以切換到安全模式如停止運動或維持上一時刻的控制量避免使用過時的信息導(dǎo)致失控。4. 環(huán)境適應(yīng)性與現(xiàn)場調(diào)試技巧比賽現(xiàn)場的光線、場地顏色、電磁環(huán)境都與實驗室不同你的算法必須具有一定的魯棒性。4.1 光線變化應(yīng)對策略問題實驗室用臺燈打光顏色閾值調(diào)得完美。到了比賽現(xiàn)場屋頂日光燈甚至窗戶自然光下識別全亂。解決方法拋棄固定閾值擁抱動態(tài)閾值或模型對于顏色識別不要用inRange(hsv, (low_H, low_S, low_V), (high_H, high_S, high_V))這種固定閾值。改用cv2.inRange結(jié)合cv2.adaptiveThreshold或者直接計算圖像中特定顏色區(qū)域的HSV均值±一個容差范圍作為閾值。更好的方法是訓(xùn)練一個簡單的二分類神經(jīng)網(wǎng)絡(luò)哪怕是幾層的全連接網(wǎng)絡(luò)輸入歸一化后的HSV直方圖或顏色矩讓模型去判斷其抗光照變化能力遠(yuǎn)強于固定閾值。顏色空間選擇HSV空間比RGB對光照更魯棒但V亮度分量依然敏感?？梢試L試使用歸一化的rg色度空間rR/(RGB), gG/(RGB)它能一定程度上消除亮度變化的影響。或者使用YCrCb空間利用Cr和Cb分量進(jìn)行膚色或特定顏色識別。現(xiàn)場快速校準(zhǔn)在程序里設(shè)計一個“校準(zhǔn)模式”。上電后將目標(biāo)物放在攝像頭前按下一個按鍵程序自動采集若干幀圖像計算目標(biāo)區(qū)域顏色的HSV統(tǒng)計特征均值、標(biāo)準(zhǔn)差并自動保存為本次運行的閾值參數(shù)。這樣你只需要在比賽開始前花10秒鐘做一次校準(zhǔn)。4.2 電磁干擾與硬件穩(wěn)定性問題電機一轉(zhuǎn)動串口通信就亂碼或者整個系統(tǒng)偶爾會復(fù)位。解決方法電源隔離與濾波電機驅(qū)動模塊的電源必須與單片機、攝像頭模塊的電源物理隔離。使用獨立的電池或穩(wěn)壓模塊供電。在電源入口處增加大容量電解電容如1000uF儲能并并聯(lián)多個小容量陶瓷電容0.1uF, 10uF濾除高頻噪聲。信號隔離如果條件允許在STM32與電機驅(qū)動模塊的控制信號線如PWM、方向DIR上使用光耦進(jìn)行隔離徹底切斷地線環(huán)路引入的干擾。通信線抗干擾UART通信線盡量使用雙絞線并遠(yuǎn)離電機電源線?？梢栽赟TM32的UART接收引腳RX上對地接一個20-50pF的小電容濾除高頻毛刺。看門狗定時器務(wù)必在STM32和高級模塊如樹莓派中啟用硬件看門狗WDT。STM32的IWDG獨立看門狗或WWDG窗口看門狗能在程序跑飛或死鎖時自動復(fù)位系統(tǒng)。在樹莓派上可以啟用硬件看門狗模塊bcm2835_wdt或編寫一個守護(hù)進(jìn)程定時喂狗。這是系統(tǒng)最后的“救命稻草”。5. 軟件工程與比賽流程優(yōu)化在緊張的比賽時間內(nèi)如何高效地開發(fā)、調(diào)試和交付本身就是一項重要的能力。5.1 模塊化與版本管理切忌在一個main.c或一個.py文件里寫到底。將代碼按功能模塊拆分vision_module.py/vision.c負(fù)責(zé)圖像采集、處理、識別算法。communication.py/uart.c負(fù)責(zé)通信協(xié)議封裝、數(shù)據(jù)打包解包。control.c負(fù)責(zé)PID控制算法、電機驅(qū)動邏輯。main.py/main.c主循環(huán)調(diào)度各個模塊。使用Git進(jìn)行版本管理哪怕只是本地倉庫。每次實現(xiàn)一個穩(wěn)定功能就提交一次。當(dāng)你在現(xiàn)場修改參數(shù)把系統(tǒng)調(diào)崩了可以輕松地git reset --hard回退到上一個穩(wěn)定版本而不是對著代碼抓狂。5.2 設(shè)計豐富的調(diào)試接口與日志系統(tǒng)不要依賴IDE的調(diào)試器比賽現(xiàn)場你可能只有串口顯示器。在代碼中植入豐富的調(diào)試信息輸出。在STM32上除了主通信串口專門分配一個串口或USB虛擬串口作為調(diào)試輸出使用printf重定向?qū)崟r打印系統(tǒng)狀態(tài)、傳感器數(shù)據(jù)、控制量、錯誤碼。在樹莓派/Jetson上使用Python的logging模塊將不同等級的信息INFO, DEBUG, ERROR輸出到控制臺和文件?？梢栽O(shè)計一個Web界面用Flask簡單搭建實時顯示攝像頭畫面、識別結(jié)果和系統(tǒng)狀態(tài)這樣可以用手機或筆記本無線訪問調(diào)試起來非常方便。關(guān)鍵數(shù)據(jù)可視化在OpenMV或樹莓派的圖像上實時畫出識別框、巡線路徑、目標(biāo)點等信息。一眼就能看出算法是否在正常工作。5.3 制定現(xiàn)場調(diào)試清單比賽開始后時間以分鐘計。提前準(zhǔn)備好一份按順序執(zhí)行的調(diào)試清單能避免手忙腳亂上電前檢查所有電源線、信號線連接牢固電機電源與邏輯電源隔離各模塊供電電壓是否正確第一階段模塊獨立調(diào)試給視覺模塊上電通過自帶顯示器或調(diào)試串口確認(rèn)攝像頭能打開并能看到實時圖像。運行最基本的識別程序確認(rèn)能輸出數(shù)據(jù)。給STM32上電通過調(diào)試串口確認(rèn)程序運行能收到按鍵等輸入。手動給STM32發(fā)送模擬的視覺數(shù)據(jù)包可以用串口調(diào)試助手確認(rèn)電機/舵機能正確響應(yīng)。第二階段系統(tǒng)聯(lián)調(diào)連接視覺模塊與STM32的通信線。在STM32端查看是否收到格式正確的數(shù)據(jù)包。放置目標(biāo)物觀察STM32的控制輸出是否合理。進(jìn)行閉環(huán)測試從簡單場景開始如目標(biāo)靜止逐步增加難度目標(biāo)移動。第三階段環(huán)境適應(yīng)性調(diào)整在現(xiàn)場光線下運行顏色校準(zhǔn)程序如果有。測試不同距離、角度下的識別穩(wěn)定性。進(jìn)行壓力測試快速移動目標(biāo)觀察系統(tǒng)跟蹤能力制造輕微遮擋觀察系統(tǒng)恢復(fù)能力。把這份清單和關(guān)鍵的調(diào)試命令如啟動腳本的命令、查看日志的命令寫在記事本里貼在墻上。冷靜、按步驟執(zhí)行能最大程度減少失誤。電賽E題乃至所有嵌入式視覺控制題目比拼的從來不只是誰的算法更先進(jìn)更是誰的系統(tǒng)更穩(wěn)定、誰的工程實現(xiàn)更扎實、誰的現(xiàn)場應(yīng)變更迅速。把這些“坑”提前填平把解決方案變成肌肉記憶你才能在四天三夜的極限挑戰(zhàn)中把精力真正聚焦在解決題目本身而不是和你的設(shè)備“斗智斗勇”。最后記住一點最簡單的、能穩(wěn)定跑完整個比賽流程的方案遠(yuǎn)勝過復(fù)雜但脆弱的“炫技”方案。可靠性永遠(yuǎn)是第一位的。