簡介這是一套面向智能小車與機器人視覺導航的OV7670攝像頭循跡工程源碼利用CMOS圖像傳感器采集環(huán)境圖像通過灰度化、二值化、邊緣檢測等預處理突出賽道邊界再結合PID控制算法調節(jié)電機轉速實現(xiàn)穩(wěn)定的路徑跟蹤。資源共204個文件以C語言源文件與頭文件為主包含STM32定時器、ADC、I2C、Flash等外設驅動以及LCD顯示等模塊還附帶編譯生成的Hex、AXF燒錄文件、Keil工程配置和輔助批處理腳本壓縮包約4.91MB。目前已有3688人學習查看該工程特別記錄了將CameraBlackWhiteWarShip項目移植到紀偉最小系統(tǒng)版的過程涉及SPI/I2C通信參數(shù)調整、內存優(yōu)化等細節(jié)有助于開發(fā)者理解不同硬件平臺間的適配思路。通過研讀完整源碼讀者可掌握攝像頭循跡從圖像采集、預處理、邊緣識別到運動控制的完整閉環(huán)并學習中斷處理、外設初始化與實時控制策略適合嵌入式視覺導航方向的開發(fā)者作為實戰(zhàn)參考。1. OV7670攝像頭循跡 程序源碼從花屏到穩(wěn)過環(huán)的完整鏈路OV7670攝像頭循跡最勸退人的地方不是你寫不好算法而是辛辛苦苦燒完程序屏幕上只有雪花、花屏、或者一整片灰。很多第一次做視覺循跡的開發(fā)者拿著現(xiàn)成源碼也跑不出圖像最后只能把車子丟在角落積灰。我早期做模擬項目X時也翻過這個車前后折騰了一個多星期才明白循跡不是“拍一張照再找線”而是一條完整的數(shù)據(jù)鏈路SCCB配置、像素時鐘采集、幀緩沖搬運、二值化與質量中心計算、PID差速輸出每一環(huán)節(jié)都必須同時正確。這篇筆記按“先跑通、再調穩(wěn)”的順序展開適合已經有基本單片機基礎、想從紅外循跡升級到視覺循跡的開發(fā)者也適合準備競賽底車但還沒理清時序的朋友。先別追求畫面多清晰把一幀數(shù)據(jù)穩(wěn)定拿到手后面一切才談得上。2. 硬件連接與SCCB配置先讓OV7670輸出一幀可用圖像很多程序跑不起來不是算法不行是硬件通道根本沒打通。OV7670模塊上有兩條通路一條是SCCB配置總線用來寫寄存器另一條是DVP數(shù)據(jù)通路用來輸出圖像。你燒錄源碼之前必須先把這兩條路的電氣連接和初始化順序理清楚。2.1 接線以外的三件事電源時序、引腳驅動與DVP匹配先把最基礎的引腳映射列出來方便你對照手頭主控板核對攝像頭側主控側作用XCLK定時器復用輸出給攝像頭提供外部時鐘常見頻率為24MHzPCLKDVP像素時鐘輸入每次有效邊沿輸出一個像素VSYNCDVP VSYNC輸入幀同步信號一幀開始或結束的標志HREFDVP HREF輸入行有效信號高電平期間輸出一行像素D0-D7DVP數(shù)據(jù)總線并行圖像數(shù)據(jù)8位SIO_CSCCB SCL配置時鐘SIO_DSCCB SDA配置數(shù)據(jù)接線最容易翻車的不是數(shù)據(jù)線而是 XCLK。我之前接過一個模塊XCLK浮空沒給時鐘SCCB怎么寫都像石沉大海因為攝像頭內部邏輯根本沒跑起來。正確的順序是先保證主控給 XCLK 一個穩(wěn)定的 24MHz 信號再操作 SCCB。另一個容易被忽略的點是 SIO_D 必須接上拉電阻模塊上雖然有上拉但個別開發(fā)板內部上拉很弱最好外接 4.7k 到 3.3V。我一般會在硬件初始化里把引腳分成三組配置代碼骨架如下void ov7670_hw_init(void) { // 第1組XCLK 用定時器復用輸出產生 24MHz 時鐘 gpio_alt_config(XCLK_PIN, GPIO_AF_TIMER); timer_pwm_config(XCLK_TIMER, 24000000); // 第2組SCCB 的 SCL 和 SDA 配置為開漏輸出外部已有上拉 gpio_open_drain_config(SIO_C_PIN); gpio_open_drain_config(SIO_D_PIN); // 第3組DVP 數(shù)據(jù)與同步引腳全部設為輸入注意關閉內部上拉 gpio_input_config(D0_D7_PINS); gpio_input_config(PCLK_PIN); gpio_input_config(VSYNC_PIN); gpio_input_config(HREF_PIN); }這段代碼本身不復雜但順序很重要。如果先初始化 DVP 數(shù)據(jù)腳再給 XCLK模塊上電瞬間可能輸出不穩(wěn)定電平導致主控引腳狀態(tài)混亂。我會把 XCLK 放在第一步確保攝像頭在任何 SCCB 操作之前就有時鐘源。還有一個細節(jié)D0-D7 這組引腳不要開內部上拉數(shù)據(jù)線懸空時容易產生毛刺干擾 DMA 傳輸判斷。電源時序上OV7670 模塊通常 3.3V 供電上電后要等待幾十毫秒再寫 SCCB。有的源碼把軟復位放在寄存器配置最開始這沒問題但復位命令和正常配置之間要留足夠延時否則寄存器可能寫入失敗。你可以用邏輯分析儀測量 SCCB 的波形但更快的辦法是寫一個寄存器讀回函數(shù)寫進去再讀出來對比確認總線真的通了。2.2 SCCB寫寄存器代碼單字節(jié)配置背后的時序門檻SCCB 在單字節(jié)寫場景下和 I2C 很接近但它不是嚴格意義上的 I2C有些模塊不支持連續(xù)讀或者要求第 9 位回應方式不同。為了避免玄學問題我建議你自己寫一個軟件 SCCB把時序握在手里排查起來也直觀。下面是一套最常見的軟件時序實現(xiàn)static void sccb_start(void) { SDA_DIR_OUT(); SCL_LOW(); SDA_HIGH(); delay_us(2); SCL_HIGH(); delay_us(2); SDA_LOW(); // SDA 在 SCL 高電平期間拉低表示起始 delay_us(2); SCL_LOW(); } static void sccb_stop(void) { SDA_DIR_OUT(); SCL_LOW(); SDA_LOW(); delay_us(2); SCL_HIGH(); delay_us(2); SDA_HIGH(); // SCL 高電平期間 SDA 拉高表示停止 delay_us(2); } static uint8_t sccb_write_byte(uint8_t dat) { uint8_t i, ack; for (i 0; i 8; i) { SCL_LOW(); if (dat 0x80) SDA_HIGH(); else SDA_LOW(); delay_us(1); SCL_HIGH(); delay_us(1); dat 1; } // 第9個時鐘用于讀取從設備應答 SCL_LOW(); SDA_DIR_IN(); SCL_HIGH(); delay_us(1); ack SDA_READ(); // 低電平表示應答 SCL_LOW(); SDA_DIR_OUT(); return ack; }這段代碼的關鍵點是位序必須從最高位開始發(fā)OV7670 的寄存器地址和數(shù)據(jù)都是 8 位MSB first 是硬性要求。很多新手把 I2C 的習慣帶進來先發(fā)低位結果寄存器地址完全錯亂畫面輸出就別提了。另外SCCB 的應答位在有些實現(xiàn)里不被檢查但這正是我建議保留的原因配置完某個關鍵寄存器后讀回或者至少在初始化后掃描一遍能快速排除總線問題。寫寄存器函數(shù)按地址加數(shù)據(jù)的格式組織uint8_t ov7670_write_reg(uint8_t reg_addr, uint8_t reg_val) { uint8_t err 0; sccb_start(); err | sccb_write_byte(0x42); // 器件地址寫方向 err | sccb_write_byte(reg_addr); err | sccb_write_byte(reg_val); sccb_stop(); return err; // 0 表示應答正常 }器件地址 0x42 是常見寫法也就是 0x21 左移一位。不同廠商模塊可能有差異如果初始化時發(fā)現(xiàn)寄存器寫不進去第一件事查模塊的器件地址而不是懷疑時序。返回值 err 里任何一位是 1都說明鏈路有異常不要繼續(xù)往下走。2.3 初始化參數(shù)表從RGB565到QQVGA的分辨率取舍配置寄存器沒有統(tǒng)一標準答案但常見初始化流程基本逃不出下面這幾個動作軟復位、設置輸出格式、設置時鐘分頻、設置窗口、關閉或保留自動增益。下面這張表是我做底車時固定下來的最小配置寄存器地址寫入值作用說明0x120x80軟復位0x120x00退出復位狀態(tài)0x110x03PCLK 分頻降低像素時鐘到可用范圍0x400x10RGB565 輸出格式0x170x13水平窗口起點用于設置可視區(qū)域0x180x01水平窗口大小的高位字節(jié)0x190x02垂直窗口起點0x1A0x7A垂直窗口大小這里要強調不要把別人代碼里的寄存器表當成萬能靈藥不同分辨率下窗口寄存器組合差異很大。我一般會先把輸出固定在 160x120 的 QQVGA 尺寸上跑通再考慮往更高分辨率走。選 QQVGA 出于三個理由第一一幀只有 19200 個像素RGB565 下約 38KB普通主控內部 RAM 能裝得下雙緩沖第二像素點少二值化和質量中心計算能在幾毫秒內完成第三攝像頭幀率受 PCLK 分頻影響分辨率越低單位像素時鐘越充裕畫面撕裂的概率越小。初始化代碼中寄存器寫入順序也有講究。建議先復位等穩(wěn)定再寫輸出格式最后改窗口。如果把格式和窗口混在一起寫有概率觸發(fā)內部狀態(tài)機異常。你可以用一個循環(huán)把配置表跑一遍const uint8_t ov7670_init_table[][2] { {0x12, 0x80}, {0x12, 0x00}, {0x11, 0x03}, {0x40, 0x10}, {0x17, 0x13}, {0x18, 0x01}, {0x19, 0x02}, {0x1A, 0x7A}, }; void ov7670_init(void) { for (uint8_t i 0; i sizeof(ov7670_init_table) / 2; i) { ov7670_write_reg(ov7670_init_table[i][0], ov7670_init_table[i][1]); delay_ms(5); // 每個寄存器之間加延時避免寫入過快 } }注釋里那個 5ms 延時是我調試后加的習慣不是必須但能明顯減少寫入失敗率。等初始化全部完成再用一幀 VSYNC 信號確認數(shù)據(jù)通路是否已經活躍。此時如果你有調試手段可以直接讀 PCLK 引腳波形沒有示波器就靠代碼判斷配置完后延時 200ms再輪詢 VSYNC 引腳如果一直是死電平大概率是 XCLK 或 SCCB 配置有問題。3. 幀緩沖與行數(shù)據(jù)從VSYNC到一幀完整畫面的采集機制寄存器配置好了攝像頭開始輸出圖像但主控怎么知道哪一段數(shù)據(jù)是完整一幀這就要吃透 VSYNC、HREF、PCLK 三根線的關系。很多循跡源碼跑出殘影、半邊畫面都是因為幀起始判斷寫錯了。3.1 數(shù)據(jù)流拆解PCLK、HREF、VSYNC各管哪一段一句話描述數(shù)據(jù)流VSYNC 告訴你一幀從哪里開始HREF 告訴你哪些時鐘周期屬于有效像素PCLK 負責一拍一像素地把數(shù)據(jù)吐出來。時序關系是這樣的VSYNC 有效沿到來后緊接著 HREF 會連續(xù)跳變每行有效期間 HREF 維持高電平同時 PCLK 持續(xù)翻轉。在 HREF 為高時每個 PCLK 上升沿對應的 D0-D7 就是一個像素數(shù)據(jù)。HREF 為低時輸出的數(shù)據(jù)要忽略掉那是行消隱區(qū)。我在采集代碼里不會單獨去數(shù) HREF 的脈沖數(shù)那樣太慢。常見做法是讓硬件 DVP 控制器自己處理行同步主控只關心幀開始信號volatile uint8_t frame_ready_flag 0; void vsync_isr(void) { // VSYNC 有效沿表示新的一幀開始 frame_ready_flag 1; // 立刻搬走上一幀的數(shù)據(jù)或者啟動新一幀的DMA接收 dvp_dma_start((uint32_t)frame_buffer[work_index], 160 * 120); }這段代碼的核心思路是“用中斷標記幀開始用 DMA 把像素搬進內存”。不要在中斷里做像素處理中斷服務函數(shù)越短越好。work_index 是一個在雙緩沖里切換的索引后面會講。很多新手在這里犯的錯是在 while 循環(huán)里等待 VSYNC 拉高然后開始讀數(shù)據(jù)。這個做法在低分辨率下勉強能跑但一旦處理耗時超過一幀間隔就會漏幀或者重復處理同一幀。正確做法是讓 VSYNC 觸發(fā)中斷中斷里只改標志位主循環(huán)消費標志位。3.2 用DMA搬運圖像幀雙緩沖防撕裂的代碼寫法如果靠 CPU 一個一個像素去讀 DVP 數(shù)據(jù)寄存器160x120 一幀有 19200 個像素就算每個像素三條指令也是幾萬條指令主控直接卡死在采集上。用 DMA 是標配做法。DMA 配置的關鍵參數(shù)有三個外設地址固定為 DVP 數(shù)據(jù)寄存器內存地址是幀緩沖傳輸長度等于一幀像素數(shù)。下面是一個典型配置骨架void dvp_dma_config(void) { dma_channel_t *ch dma_get_channel(DVP_DMA_CH); dma_reset(ch); dma_periph_addr(ch, (uint32_t)DVP_DATA_REG); dma_memory_addr(ch, (uint32_t)frame_buffer[0]); dma_transfer_count(ch, 160 * 120); // 一幀像素總量 dma_direction_periph_to_mem(ch); dma_memory_size_16bit(ch); // 如果配置為RGB565數(shù)據(jù)寬度16位 dma_enable_transfer_done_interrupt(ch); dma_enable(ch); }注意數(shù)據(jù)寬度。OV7670 在 RGB565 模式下一個像素是兩個 8 位數(shù)據(jù)所以 DMA 數(shù)據(jù)寬度配置成 16 位更合理。如果配成 8 位傳輸計數(shù)要換成 160 * 120 * 2否則只搬了半個像素。傳輸完成中斷里要切換緩沖區(qū)索引避免還在處理舊幀時 DMA 把新數(shù)據(jù)覆蓋進來void dma_isr(void) { // 當前工作緩沖區(qū)已填完切換到另一塊 work_index ^ 1; frame_ready_flag 1; }只有一塊緩沖區(qū)時處理函數(shù)剛讀到一半DMA 又往同一塊內存寫畫面就會出橫向撕裂條紋。雙緩沖就是為了解決這個沖突DMA 寫一塊CPU 讀另一塊讀完再交換。循跡要求實時性撕裂畫面會直接導致中線計算跳變車子左右擺。3.3 幀率預算為什么160x120比VGA更適合循跡有人會問OV7670 最高支持 VGA為什么不用更高分辨率道理很現(xiàn)實分辨率越高單幀數(shù)據(jù)量越大DMA 搬運時間和主控處理時間都線性增長而循跡需要的只是“線在哪”這一個信息。算一筆賬160x120 灰度圖一幀 19200 字節(jié)24MHz PCLK 下純傳輸時間不到 1ms。主控跑圖像處理二值化和質量中心計算大約 2~3ms主頻幾十 MHz 就夠。整幀周期可以控制在 10ms 以內也就是幀率接近 100fps 的采集能力。換成 VGA 640x480單幀數(shù)據(jù)量是 16 倍不要說處理DMA 騰挪內存都夠嗆。所以我的建議是做循跡初始化直接配到 160x120 或者更低別讓分辨率成為流暢度的瓶頸。你需要的是一條線的橫坐標不是一張高清照片。圖像處理里常說的“降采樣”在循跡場景下不如直接從源頭鎖死分辨率。4. 循跡算法與控制輸出從像素中心線到電機差速圖像已經穩(wěn)定進內存了接下來才輪到真正的循跡邏輯。整個控制鏈可以拆成三段從彩色像素到灰度、從灰度到二值線、從線位置到電機差速。本末別倒置代碼不用一次寫完但思路要清晰。4.1 灰度化與自適應閾值背景亮度變了怎么辦OV7670 配置成 RGB565 后每個像素兩個字節(jié)分別是高字節(jié)和低字節(jié)。循跡不需要顏色信息只要亮度。最省算力的近似做法是直接取高字節(jié)當灰度值雖然不精確但響應快對找線完全夠用。static inline uint8_t pixel_gray(uint8_t high_byte, uint8_t low_byte) { (void)low_byte; return high_byte; }如果你要求高一點可以用加權公式但會引入乘法和額外指令。在 160x120 分辨率下全幀算下來差距不大就怕主控還要同時處理電機控制能省的地方盡量省。接下來是二值化。固定閾值最怕環(huán)境光變化上午能看清的黑線下午陽光一斜畫面亮度整體偏移固定閾值直接把線淹了。我一般會做一個簡單的自適應閾值每幀先統(tǒng)計平均亮度再設置一個偏移量uint8_t compute_threshold(uint8_t *gray, uint16_t count, int8_t offset) { uint32_t sum 0; for (uint16_t i 0; i count; i) { sum gray[i]; } uint8_t avg (uint8_t)(sum / count); if (avg 80) avg 80; if (avg 200) avg 200; return avg offset; }avg 被限制在 80 到 200 之間是為了防止極端畫面下閾值飄到完全無效區(qū)間。offset 用來適應線色差異黑線白地offset 通常負 10 到負 30白線黑地offset 可以取正。這個 offset 不用每幀改但你要留出接口方便后期調車。二值化就是對每個像素做一次比較同時輸出線標志static void image_binary(uint8_t *gray, uint8_t *bin, uint16_t count, uint8_t threshold) { for (uint16_t i 0; i count; i) { // 黑色線比地面暗像素值小于閾值判定為線 bin[i] (gray[i] threshold) ? 0xff : 0x00; } }方向別搞反了。如果你的賽道是白線深色地板就把比較符號反過來?？吹饺诨蛉椎亩祱D先檢查符號而不是閾值。4.2 質量中心法提取中線丟線判斷與計算量優(yōu)化二值圖里線像素是 0xff其他是 0x00。最簡單的中線算法是“質量中心法”把所有線像素的橫坐標累加除以線像素總數(shù)得到平均中心。int16_t line_center(uint8_t *bin, uint16_t w, uint16_t h) { uint32_t sum_x 0; uint32_t line_cnt 0; for (uint16_t y 0; y h; y) { for (uint16_t x 0; x w; x) { if (bin[y * w x] 0xff) { sum_x x; line_cnt; } } } if (line_cnt 0) { return -1; // 丟線標志 } return (int16_t)(sum_x / line_cnt); }返回 -1 表示整幀沒有發(fā)現(xiàn)有效線像素。這個信號非常重要它告訴控制邏輯“當前是丟線狀態(tài)”應該強制轉向尋線而不是把上一次中心當作有效輸入繼續(xù)執(zhí)行。差速控制里最怕的就是丟線后還按舊的偏差輸出車直沖出去。質量中心法的好處是抗噪個別噪點對平均值影響很小。如果你用“找每行最亮點”再連線遇到地面反光會非常痛苦。另外可以加一個 ROI 優(yōu)化只統(tǒng)計圖像下半部分。攝像頭安裝后賽道主要在畫面下方上半部分是遠處背景加入計算只會引入干擾。改循環(huán)邊界就行// 從 h*2/3 開始統(tǒng)計只看靠近車頭的位置 for (uint16_t y h * 2 / 3; y h; y) { ... }這個改動同時減少了 1/3 的計算量建議底車階段就加上。4.3 PID與運動控制誤差如何轉換成左右輪差速圖像中心算出來了和畫面中線的偏差就是轉向誤差。假設畫面寬 160目標中心是第 80 列那么誤差就是int16_t err center - 80;如果 err 為正說明線偏右車要向右轉為負則向左。最簡單的轉向輸出可以用比例加微分控制微分項能抑制小車在彎道出口的擺動。static int16_t last_err 0; int16_t pid_output(int16_t err) { int16_t out; // P項決定轉向力度D項抑制突變 out (int16_t)(KP * err KD * (err - last_err)); last_err err; if (out 300) out 300; if (out -300) out -300; return out; }KP 和 KD 的取值沒有絕對標準。我通常從 KP1.0、KD0.5 起步把基礎速度放低先看直道是否穩(wěn)定再逐步提速。轉向輸出要限幅不然差速過大會讓內側輪反轉車在跑道上原地打轉。最終加到底層電機控制int16_t steer pid_output(err); left_speed BASE_SPEED - steer; right_speed BASE_SPEED steer; if (left_speed 0) left_speed 0; if (right_speed 0) right_speed 0; pwm_set_left(left_speed); pwm_set_right(right_speed);BASE_SPEED 是直道時的目標速度我一般設成占空比的 40% 左右太高會讓攝像頭處理跟不上。丟線狀態(tài)要單獨處理if (center -1) { // 按上次誤差方向強制轉動持續(xù)尋線 if (last_err 0) steer 300; else steer -300; }這里用 last_err 方向去轉配合限幅能保證出彎丟線時車不會直沖。等重新找到線PID 重新接管。5. OV7670攝像頭循跡 常見問題與排查手記這一章把我在實際調試中踩過、以及幫別人排查過的高頻問題整理出來每條按照“現(xiàn)象 → 原因 → 解決”展開。這些問題你在任何指南里都會看到不少排除思路但真正落地時細節(jié)往往不一樣。5.1 上電全灰或無圖SCCB握手失敗和XCLK缺失現(xiàn)象寄存器配置流程跑完了VSYNC 引腳有電平變化但圖像緩沖里全是一種顏色沒有任何輪廓。原因最常見是兩個一個是 SCCB 從未真正寫入成功攝像頭還停留在內部默認狀態(tài)另一個是 XCLK 頻率不對攝像頭輸出時序混亂。解決先做一個寄存器回讀測試寫一個寄存器再讀回來對比能立刻定位總線問題。SCCB 初始化之前用 GPIO 翻轉方式分別測試 SIO_C 和 SIO_D 的波形確認主控中斷沒有把引腳占用。XCLK 用示波器或邏輯分析儀量一下頻率沒有儀器就把定時器分頻往低里調再試圖像是否出現(xiàn)。模塊上電前確認電源沒有疊加在數(shù)據(jù)引腳上。5.2 花屏與色彩錯亂數(shù)據(jù)線序、時鐘沿與高低字節(jié)現(xiàn)象畫面不是常見黑白灰而是明顯紅綠或藍綠穿插或者出現(xiàn)彩色噪點線條輪廓根本沒法二值化。原因D0-D7 數(shù)據(jù)線順序接反RGB565 高低字節(jié)順序配反PCLK 采樣的時鐘沿選錯。最常見的是排線從攝像頭到主控中間插了一根杜邦線順序全錯位。解決先用邏輯分析儀抓 D0-D7 和 PCLK 的關系確認采樣沿。如果沒儀器把采集到的 RGB 高字節(jié)和低字節(jié)分別打印出來用串口看數(shù)值規(guī)律。高低字節(jié)反了就把 DMA 搬運的數(shù)據(jù)做一次字節(jié)交換或者直接修改 DMA 數(shù)據(jù)寬度配置。數(shù)據(jù)線順序問題只能靠接線核對解決程序里沒法補救。這塊沒有捷徑耐心對一遍比寫一百行補償代碼都有效。5.3 圖像下半幀丟失或卡死VSYNC檢測與緩沖競爭現(xiàn)象畫面能出但經常只有上半部分或者畫面像被橫切了一刀下半部分是上一幀的殘留。原因VSYNC 中斷觸發(fā)點在幀中間而不是幀頭DMA 啟動時機晚于數(shù)據(jù)輸出導致丟行。另一個原因是緩沖只有一個處理函數(shù)讀到一半新幀覆蓋進來。解決用示波器看 VSYNC 極性部分模塊是下降沿有效部分上升沿配置成對應邊沿觸發(fā)。DMA 啟動放在 VSYNC 中斷后立刻執(zhí)行不要在前面加長延時。正式做循跡務必上雙緩沖雖然多占十幾 KB 內存但能徹底消除撕裂。5.4 循跡丟線亂擺閾值和PID對抗的常見誤區(qū)現(xiàn)象直道還能走一到彎道就沖出賽道或者明明走直道車卻高頻左右擺動。原因閾值偏移設置不對二值圖把大量地面噪點也算成線質量中心被干擾。另一個原因是 PID 的 D 項過大或者處理延遲太高誤差還沒收斂就連續(xù)輸出。解決先把二值圖通過串口上傳到電腦看確認圖像里只有一條線是白色。有噪點就先調整閾值和 ROI別動 PID。如果直道擺動減小 KD再看是不是處理一幀時間太長導致誤差累積。循跡小車跑不穩(wěn)八成不是 PID 問題而是前面圖像數(shù)據(jù)就是臟的。6. 從能跑通到跑得穩(wěn)三個驗證技巧與最后的實話6.1 用串口回傳二值圖肉眼確認圖像數(shù)據(jù)正確調車時沒有屏幕怎么辦把二值圖用串口打出字符畫一幀也就 19200 個像素串口速度 115200 下大概幾百毫秒。我不追求實時只把它當調試手段每觸發(fā)一次按鍵發(fā)一幀。void dump_binary_image(uint8_t *bin, uint16_t w, uint16_t h) { for (uint16_t y 0; y h; y) { for (uint16_t x 0; x w; x) { uart_putch(bin[y * w x] ? * : -); } uart_putch(\n); } }看到字符畫里線是一條干凈的白色豎條二值化和閾值就過關了再去談 PID。這一步能幫你省下大量“玄學調參”時間。6.2 物理調車鏡頭高度、俯仰角與閾值的聯(lián)動鏡頭離地高度直接影響視野寬度。太高線在畫面里變細閾值稍微偏移就丟線太低只能看到近距離一小段彎道來不及反應。我一般先把鏡頭放到離地 6 到 8 厘米俯仰角略微向前傾斜 15 度左右讓車頭前方 10 到 30 厘米的賽道段落在畫面下半部分。調好物理位姿后再重新計算閾值偏移量不要鏡頭動完不動閾值就上賽道。6.3 我走過的一段彎路調參不是調PID先調數(shù)據(jù)源我最開始調模擬項目X時連續(xù)兩天在改 KP、KD車還是在彎道前翻。后來把二值圖打出來才發(fā)現(xiàn)整個畫面下方三分之一的閾值全錯了地面反光被識別成線質量中心被拉到一邊。那一刻我才明白視覺循跡的第一優(yōu)先級永遠是確認輸入數(shù)據(jù)干凈控制算法只是錦上添花。從那以后我每換一個場地第一件事是回傳圖像第二件事才是調 PID。這個順序讓我后來再也沒白熬過夜。如果你正準備做自己的循跡小車先別急著上高級算法把這一幀圖盯明白車自然就能跑穩(wěn)。希望幫到你。本文還有配套的精品資源點擊獲取