STM32F407+OpenMV视觉识别小车封装模块实战

简介：这是一套基于意法半导体STM32F407微控制器与OpenMV机器视觉模块的循迹小车完整工程，面向电子设计竞赛、课程设计以及毕业设计等场景。项目在经典循迹功能的基础上，通过OpenMV摄像头实时识别矩形、圆形、三角形等基本几何形状，并能够区分红、绿、蓝三种颜色，将识别结果经串口发送给STM32F407主控，进而控制电机完成相应动作。系统还整合了MPU6050六轴姿态传感器、超声波避障模块、OLED/LCD显示屏以及PWM调速输出，形成从感知、决策到执行的全流程闭环，非常利于学习者理解嵌入式视觉小车的整体架构。压缩包共276个文件，主要包含C语言源文件与头文件、Keil工程配置文件（uvprojx/uvoptx）、编译生成的中间文件（如o、d、crf）等，整体大小仅9.14MB，目录划分清楚，其中已封装好各个硬件模块的驱动代码，可快速移植到同类项目中。已有9194人学习或下载，是获取完整工程代码、学习模块封装与二次开发思路的便捷途径。

1. 这个标题到底在解决什么事

很多人做智能车、课程设计或者入门嵌入式视觉时，都会卡在同一个地方：想让小车沿着路线跑，又想让它认出沿途的图形和颜色，最后发现“既是运动控制，又是图像处理”这件事，单靠一块 MCU 往往顾此失彼。STM32F407 的浮点算力和外设足够做电机控制，但把颜色阈值、形状判断这种图像任务也塞进主循环里，别说帧率上不去，控制周期都会被拖得一抖一抖。而 OpenMV 这种自带摄像头的视觉模块，优势在于图像处理生态成熟、改阈值方便，把它专门用来做“看东西”的活，再把结果丢给 STM32F407 去“跑腿”，是这一类小车里很顺手的分工。标题里“内含封装好的模块”指的是把颜色识别、形状识别、串口发送这些动作封装成可复用的函数，不是拿不到源码，而是你直接改参数就能用。适合正在做循迹小车、想加上视觉识别又不想从零调图像算法的人，以及准备参赛想快速验证方案的队伍。

2. 系统架构与模块选型：STM32F407 和 OpenMV 各管哪一段

2.1 为什么是“双处理器”而不是单芯片硬扛

先说一个容易被低估的问题：图像识别到底有多吃资源。在 OpenMV 上，一帧 QQVGA（160×120）的画面，找色块、算形状特征，用 MicroPython 写起来几十行，但背后是像素遍历和阈值比较。放到 STM32F407 上，即使主频有 168MHz，裸奔去读摄像头数据再做同样的计算，CPU 占用会非常难看；更麻烦的是，小车需要在 1ms 到 10ms 级别稳定刷新电机 PWM，图像处理说不准哪一帧就卡一下，控制周期一抖，循迹就会画出明显的大波浪。反过来，若只靠 OpenMV 去输出两路 PWM 驱动电机，它对定时器、编码器、ADC 的支持又远不如 STM32 顺手，而且 MicroPython 的循环不适合做高频 PID。

所以这个组合的核心思路是：OpenMV 负责一切与“看”相关的任务，跑它的传感器、图像处理库；STM32F407 负责一切与“动”相关的任务，读循迹灰度传感器、解算电机控制、执行视觉事件。两者之间只有一个串口在交换信息，数据量很小，延迟可控。就算哪天想换更强的主控，OpenMV 端代码基本不用动，只要把串口协议保持一致就行。这也是“封装好的模块”带来的实际好处：视觉端是一个独立单元，跟主控型号没有强绑定。

2.2 OpenMV 与 STM32 的 UART 通信协议设计

两个设备之间说话，必须约定好“语法”。串口通信最常见的问题不是波特率，而是双方对数据帧的理解不一致。这里我一般会定义一个非常简单的帧格式：帧头 + 数据 + 校验，不用复杂协议，因为视觉识别结果就几个数字而已。

校验和算法很简单，把第 0 字节到第 5 字节加起来，再对 256 取余，放在最后一个字节。STM32 收到数据后，把前 6 个字节同样求和取低字节，和收到的校验和对比，一致才认为是一帧有效数据。这个协议的可扩展性也不错：如果以后要加角度、长宽比，可以在帧头和颜色 ID 之间插入长度字节，但当前这个固定长度已经够用。波特率选 115200，8 位数据位、1 位停止位、无校验，双方一致即可。距离超过十几厘米的场景建议把线绕短一点，或者降低到 57600，减少干扰。

2.3 “封装好的模块”究竟怎么组织

标题里“内含封装好的模块”这句话，落到实际操作中是指代码文件的结构。我习惯把 OpenMV 端分成四个文件：color_thresholds.py存放颜色阈值，shape_detect.py封装形状识别函数，uart_send.py封装串口发送，main.py负责主循环。这样调参时只需要改第一个文件，不需要翻主逻辑。STM32 端则拆成motor.c/h、line_follower.c/h、vision_cmd.c/h，分别对应电机驱动、循迹算法、视觉指令解析。

这个拆法最大的价值是“换场景不用重写”：换一块场地，只需要重新标定颜色阈值；换一组电机，只需要改motor.c里的定时器配置；想从三路循迹改成五路循迹，也只需要动line_follower.c。视觉识别和运动控制之间的耦合只通过串口协议，不通过全局变量，这也是模块化设计的一个基本约束。

3. OpenMV 端实现：颜色识别、形状识别与串口打包

3.1 颜色识别：LAB 阈值与 find_blobs 的封装

在 OpenMV 里做颜色识别，绕不开 LAB 色彩空间。LAB 的 L 分量表示亮度，A 分量化表红绿色差，B 分量化表黄蓝色差。RGB 空间里，同一颜色在不同光照下三个通道的值会同时变化，很难用一个立方体框住；LAB 空间把亮度单独拆开，所以调阈值时，亮度的范围可以放宽，A 和 B 通道的限制才是真正区分颜色的关键。

下面这段代码是颜色识别模块的最小实现，并在main.py中被调用：

# uart_send.py import sensor from pyb import UART # 初始化串口3：P4(TX) P5(RX) uart = UART(3, 115200) uart.init(115200, bits=8, parity=None, stop=1) # color_thresholds.py # 红色阈值 (L_min, L_max, A_min, A_max, B_min, B_max) RED_THRESHOLD = (10, 100, 20, 80, -10, 60) GREEN_THRESHOLD = (10, 100, -80, -20, 10, 60) # shape_detect.py import math def find_color_blob(img, threshold, pixels_min=100): # 查找符合阈值颜色的色块，并返回面积最大的一个 blobs = img.find_blobs([threshold], pixels_threshold=pixels_min, merge=True) if blobs: # 面积最大色块通常是最可能的目标 return max(blobs, key=lambda b: b.area()) return None def shape_detect(blob): # 根据外接矩形面积与像素面积的比值判断形状 w = blob.w() h = blob.h() if w == 0 or h == 0: return "unknown" area_ratio = blob.area() / (w * h) wh_ratio = w / h if (0.6 < area_ratio <= 0.9) and (0.8 < wh_ratio < 1.2): return "circle" elif area_ratio > 0.9 or (area_ratio > 0.8 and (wh_ratio > 1.5 or wh_ratio < 0.67)): return "rectangle" elif 0.4 < area_ratio <= 0.6: return "triangle" return "unknown"

逻辑说明：find_blobs遍历图像中所有符合阈值的像素块，pixels_threshold用来过滤掉面积小于 100 像素的噪点，merge=True会把相邻且颜色接近的色块合并成一个大色块，避免因为目标被分割成多块而漏检。blob.area()返回色块实际覆盖的像素数，blob.w()和blob.h()是外接矩形的宽和高。

参数说明：RED_THRESHOLD里的六个值，前两个是亮度范围，后四组是 A、B 通道范围。不同光照环境下这个值差别很大，建议先用 OpenMV IDE 里的“阈值调试器”打开一张实际拍摄的图片，手动拖动滑块，直到目标区域变成白色，其他区域变成黑色时，把得到的值填进来。pixels_min的取值取决于目标大小，目标太小就把这个值调低，但太低会带入大量噪点；目标大时调高能明显提升稳定性。

3.2 形状识别：用面积比和宽高比区分矩形、圆形、三角形

OpenMV 没有直接给出“这是三角形”的 API，但实际项目中不需要追求通用视觉识别，只需要在固定高度、固定角度下区分几种简单图形。这里用数学特征做简化判断：圆形和它的外接矩形面积比约是 π/4，也就是 0.785 左右；矩形和它的外接矩形面积比接近 1，但因为透视和边缘锯齿，通常会落在 0.9 到 0.98 之间；三角形和它的外接矩形面积比正好是 0.5。再结合宽高比，就能把三种常见形状分开。

上面的shape_detect函数就是基于这个原理写的。需要说明的是，area_ratio的阈值范围是有讲究的。圆形不会严格等于 0.785，因为色块边缘有锯齿，目标旋转角度也可能影响外接矩形的面积，所以我留了 0.6 到 0.9 的宽松区间。矩形识别则要求面积比接近 1，或者面积比在 0.8 以上且长宽比明显偏离 1，这是为了排除“扁椭圆”被误判成矩形。三角形一般面积比在 0.45 到 0.55 之间，如果目标带圆角，可能略高于 0.5，所以取 0.4 到 0.6。

如果你想进一步提高准确率，可以在这个函数之前对图像做一次膨胀腐蚀，消除边缘锯齿。OpenMV 的img.morph能实现这个操作，但会增加一帧的处理时间。需要注意的是，这个形状判断方法最怕的是目标被遮挡。比如小车从侧面看一个三角形，看到的可能只是一个很窄的楔形，面积比会变得很低，导致误判。因此实际使用中尽量让摄像头俯视，并且让目标在画面中央出现后才输出结果。

3.3 串口发送模块：把识别结果编码成数据帧

OpenMV 端识别完成后，要把结果通过串口发给 STM32。下面这个函数把颜色 ID、形状 ID、坐标和尺寸打包成 7 个字节，并计算校验和：

# uart_send.py def uart_send(uart, color_id, shape_id, x, y, size): # size 需要缩放到 0~255，避免超过一个字节 size = int(size) if size > 255: size = 255 data = bytearray([0xA5, color_id, shape_id, x & 0xFF, y & 0xFF]) # 计算校验和：帧头+前5个数据字节求和后取低字节 checksum = sum(data) & 0xFF data.append(checksum) uart.write(data)

逻辑说明：x & 0xFF是取低 8 位。QQVGA 分辨率是 160×120，x 的范围是 0 到 159，y 的范围是 0 到 119，所以单字节完全够用，不需要高低字节拆分。size是目标面积，可能很大，直接& 0xFF会把高位置丢掉，所以我先压到 0 到 255。校验和用 Python 内置的sum(data)对 bytes 求和，再& 0xFF取低 8 位，和 STM32 端计算的逻辑保持一致。

参数说明：uart.write是 MicroPython 的阻塞式写发送，正常情况下会把数据全部送出发送缓冲区。但如果一帧内连续调用很多次，下一帧的数据可能会因为缓冲区未满而立即返回，实际上还在后台发送，这在高频率发送时偶尔会造成字节交错。所以我习惯在main.py的循环里加一点time.sleep(20)，让发送节奏稳定在几十毫秒一帧，这对小车控制来说完全够实时了。

3.4 主循环：把识别和发送串起来

# main.py import sensor, image, time from pyb import UART from uart_send import uart_send from color_thresholds import RED_THRESHOLD, GREEN_THRESHOLD from shape_detect import find_color_blob, shape_detect sensor.reset() sensor.set_pixformat(sensor.RGB565) sensor.set_framesize(sensor.QQVGA) sensor.skip_frames(time=2000) sensor.set_auto_whitebal(False) # 关闭自动白平衡，避免色偏抖动 uart = UART(3, 115200) while True: img = sensor.snapshot() # 优先查找红色目标，如果红色没有，再尝试绿色 blob = find_color_blob(img, RED_THRESHOLD, pixels_min=150) color_id = 0 shape_id = 0 if blob: shape = shape_detect(blob) if shape == "circle": shape_id = 1 elif shape == "rectangle": shape_id = 2 elif shape == "triangle": shape_id = 3 color_id = 1 # 红色 uart_send(uart, color_id, shape_id, blob.cx(), blob.cy(), blob.area()) else: blob = find_color_blob(img, GREEN_THRESHOLD, pixels_min=150) if blob: shape = shape_detect(blob) if shape == "circle": shape_id = 1 elif shape == "rectangle": shape_id = 2 elif shape == "triangle": shape_id = 3 color_id = 2 # 绿色 uart_send(uart, color_id, shape_id, blob.cx(), blob.cy(), blob.area()) time.sleep(20)

逻辑说明：每 20 毫秒抓一帧图像，先找红色，再找绿色，这个优先级可以根据竞赛规则调整。sensor.set_auto_whitebal(False)特别重要。OpenMV 的自动白平衡会根据画面整体色偏不断调整，会导致同一颜色在不同帧里的 LAB 值飘来飘去，阈值明明调准了也会偶尔丢失目标。如果你在室内固定灯光下做实验，直接关掉它。

4. STM32F407 端实现：循迹控制与视觉指令的执行

4.1 定时器 PWM 和编码器接口的配置

STM32F407 的电机控制离不开定时器。我一般用 TIM4 输出两路 PWM 给普通直流电机驱动器，用 TIM3 做编码器模式读取车轮转速。PWM 频率我习惯设成 10kHz 以上，太低了电机会发出明显的啸叫，太高了开关损耗增加，而且对驱动的栅极驱动芯片要求也会变高。

以 HAL 库为例，PWM 初始化代码如下：

// motor.c #include "stm32f4xx_hal.h" TIM_HandleTypeDef htim4; TIM_OC_InitTypeDef sConfigOC; void Motor_PWM_Init(void) { __HAL_RCC_TIM4_CLK_ENABLE(); __HAL_RCC_GPIOB_CLK_ENABLE(); GPIO_InitTypeDef GPIO_InitStruct; GPIO_InitStruct.Pin = GPIO_PIN_6 | GPIO_PIN_7; // PB6/PB7 映射到 TIM4_CH1/CH2 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; GPIO_InitStruct.Alternate = GPIO_AF2_TIM4; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); __HAL_RCC_TIM4_CLK_ENABLE(); htim4.Instance = TIM4; htim4.Init.Prescaler = 168 - 1; // 168MHz / 168 = 1MHz htim4.Init.CounterMode = TIM_COUNTERMODE_UP; htim4.Init.Period = 100 - 1; // 1MHz / 100 = 10kHz htim4.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; HAL_TIM_PWM_Init(&htim4); sConfigOC.OCMode = TIM_OCMODE_PWM1; sConfigOC.Pulse = 0; // 初始占空比 0% sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH; sConfigOC.OCFastMode = TIM_OCFAST_DISABLE; HAL_TIM_PWM_ConfigChannel(&htim4, &sConfigOC, TIM_CHANNEL_1); HAL_TIM_PWM_ConfigChannel(&htim4, &sConfigOC, TIM_CHANNEL_2); HAL_TIM_PWM_Start(&htim4, TIM_CHANNEL_1); HAL_TIM_PWM_Start(&htim4, TIM_CHANNEL_2); }

参数说明：Prescaler 和 Period 共同决定 PWM 频率。STM32F407 的定时器时钟是 168MHz，先除以 168 得到 1MHz 的计数频率，再除以 100，得到 10kHz。这个参数组合是实际项目里很常用的。Pulse是占空比寄存器，数值范围是 0 到 99，比如写入 50 就是 50% 占空比。编码器初始化代码与此类似，TIM3 启用编码器接口模式，直接读取计数值就能得到电机转速和方向。

4.2 循迹传感器读取与偏差计算

循迹传感器通常使用三路或五路灰度传感器。三路比较简单，读三个 GPIO 的电平就能得到左、中、右三个位置是否有黑线。这里要注意“黑线是高电平还是低电平”取决于传感器模块的设计，常见淘系模块一般输出数字高电平表示检测到黑线，也有反的，所以要先用万用表确认一下。

下面是一个三路循迹的偏差计算代码：

// line_follower.c #define LINE_LEFT_PIN GPIO_PIN_8 #define LINE_LEFT_PORT GPIOA #define LINE_MID_PIN GPIO_PIN_9 #define LINE_MID_PORT GPIOA #define LINE_RIGHT_PIN GPIO_PIN_10 #define LINE_RIGHT_PORT GPIOA int Line_GetError(void) { uint8_t left = HAL_GPIO_ReadPin(LINE_LEFT_PORT, LINE_LEFT_PIN); uint8_t mid = HAL_GPIO_ReadPin(LINE_MID_PORT, LINE_MID_PIN); uint8_t right = HAL_GPIO_ReadPin(LINE_RIGHT_PORT, LINE_RIGHT_PIN); if (left == 1 && mid == 1 && right == 0) { return 2; // 小车偏左，黑线在右侧 } else if (left == 0 && mid == 1 && right == 1) { return -2; // 小车偏右，黑线在左侧 } else if (mid == 1) { return 0; // 黑线在正中间 } else if (left == 0 && right == 0) { return 0; // 丢线或十字路口，保持上次方向 } return 0; }

逻辑说明：返回值作为 PID 控制器的误差输入，负值表示小车需要向左修正，正值需要向右修正。因为只有三路，误差分辨率很低，所以我把偏差跳变设为 ±2，比 ±1 更敏感。当左右同时为 0 时，可能是摄像头已经越过十字路口，也可能是完全出线，这里保守地返回 0，等待下一帧数据恢复。如果你用五路传感器，误差范围可以做到 -4 到 +4，控制曲线会平滑得多。

4.3 视觉指令解析与状态机

STM32 端通过串口 2 接收 OpenMV 发来的数据。为了不阻塞中断，我在中断服务函数里只做一件事：把收到的字节放进环形缓冲区。解析逻辑放到主循环里做。

// vision_cmd.c #define RX_BUFFER_SIZE 64 volatile uint8_t rx_buffer[RX_BUFFER_SIZE]; volatile uint8_t rx_head = 0; volatile uint8_t rx_tail = 0; volatile uint8_t rx_byte; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART2) { uint8_t next_index = (rx_tail + 1) % RX_BUFFER_SIZE; if (next_index != rx_head) { // 缓冲区满了就丢弃新字节 rx_buffer[rx_tail] = rx_byte; rx_tail = next_index; } HAL_UART_Receive_IT(&huart2, &rx_byte, 1); } }

解析函数如下：

typedef struct { uint8_t color_id; uint8_t shape_id; uint8_t x; uint8_t y; uint8_t size; } VisionFrame; volatile VisionFrame current_frame; volatile uint8_t vision_valid = 0; void Vision_Parse(void) { static uint8_t frame_buf[7]; static uint8_t buf_len = 0; while (rx_head != rx_tail) { uint8_t ch = rx_buffer[rx_head]; rx_head = (rx_head + 1) % RX_BUFFER_SIZE; if (buf_len == 0 && ch != 0xA5) { continue; // 等待帧头 } frame_buf[buf_len++] = ch; if (buf_len == 7) { // 校验和检查 uint8_t sum = 0; for (uint8_t i = 0; i < 6; i++) { sum += frame_buf[i]; } if ((sum & 0xFF) == frame_buf[6]) { current_frame.color_id = frame_buf[1]; current_frame.shape_id = frame_buf[2]; current_frame.x = frame_buf[3]; current_frame.y = frame_buf[4]; current_frame.size = frame_buf[5]; vision_valid = 1; } buf_len = 0; // 无论成功与否，重新开始找帧头 } } }

说明：这个解析逻辑的精髓在于“不试图恢复错位的帧”。如果一帧数据中间丢了一个字节，后面所有字节都会错位，直到碰巧凑够 7 字节且校验和通过，或者直接等下一个帧头。实际测试下来，每秒钟最多有十几帧数据，偶尔丢掉几帧对小车控制没有明显影响，重要的是不要因为解析逻辑的 bug 造成卡死。

4.4 控制循环：让循迹动作和视觉事件协同

主循环的常见做法是先执行循迹 PID，再检查视觉数据是否有效，如果有有效指令且满足动作优先级，就临时覆盖当前动作，执行完后恢复。下面是一个简单状态机：

// main.c while (1) { int error = Line_GetError(); int speed = Speed_PID(error); // 这里只做占位说明，实际是PID运算 // 视觉指令每20ms刷新一次，用vision_valid标志判断新数据 if (vision_valid) { vision_valid = 0; if (current_frame.color_id == 1 && current_frame.shape_id == 1) { // 红色圆形：停车1秒 Motor_SetSpeed(0, 0); HAL_Delay(1000); } else if (current_frame.color_id == 1 && current_frame.shape_id == 3) { // 红色三角形：左转 Motor_SetSpeed(-40, 40); HAL_Delay(300); } } // 正常循迹，使用PD控制器 int p = error * 10; int d = error - last_error; last_error = error; Motor_SetSpeed(BASE_SPEED + p + d, BASE_SPEED - p - d); HAL_Delay(10); }

这里HAL_Delay(1000)会阻塞主循环一秒钟，期间 GPIO 灰度传感器不再被读取。这是有意为之，因为停车这个动作本身就是希望小车不再继续跑。但如果动作延迟要求更高，建议用一个非阻塞的定时器状态机，而不是直接HAL_Delay。初版这样写能快速验证功能，后续再优化成 tick 状态机。

5. 联调中的常见问题与避坑指南

5.1 现象：串口数据乱码或偶发丢字节

原因排查：最常见的是两端波特率不一致，比如 STM32 这边用了 115200，OpenMV 那边初始化时写成了 9600。还有一个很容易被忽略的是“共地问题”，OpenMV 和 STM32 如果不接 GND，串口电平没有公共参考点，收到的数据会随机错位。另外，如果 STM32 的接收中断没有及时连续调用HAL_UART_Receive_IT，那么第一帧数据之后的中断就断了，表现为只有第一条有效，后面的全丢。

解决方法是先确认 GND 连接，再把两端波特率统一到一个值。接着在 STM32 调试器里设断点到HAL_UART_RxCpltCallback，每收到一字节就应该停一次。如果一次都不停，那是接线错误；如果停了几次后不再停，就是没有重新调用HAL_UART_Receive_IT。我之前犯过这个错，中断回调里写了解析逻辑，但忘了重新开启接收，导致程序看起来一切正常就是不收数据。建议把“重新开启接收”这行代码放在回调函数的第一行。

5.2 现象：颜色阈值调好之后，换个环境就失效

原因分析：LAB 空间虽然比 RGB 耐光照，但不同灯光的色温差异会明显改变 A、B 通道的数值。比如室内暖光灯下，白色地面会偏黄，B 通道会偏小；室外阴天又偏蓝。OpenMV 的自动白平衡会努力把画面拉回“标准白”，但这个调整是按整幅画面统计的，目标颜色和背景一旦比例变化，白平衡结果也会跟着变，于是同一目标在画面中的 LAB 值就飘了。

解决：在 OpenMV 初始化代码中关掉自动白平衡，也就是sensor.set_auto_whitebal(False)。然后分别打开室内、室外两次取阈值，把两组阈值都存下来，写一个简单的切换开关，根据工作环境选择使用哪一组。如果你希望模块更智能，可以在上位机或者拨码开关上留一个引脚选择“场景 ID”，这样在比赛场地换灯的时候，不用重新烧代码。

5.3 现象：小车循迹在弯道处反复冲出跑道

原因分析：循迹性能不佳通常不是某个单一参数问题，而是三个因素叠加：灰度传感器的安装高度太高，导致黑线在采样的区域内反射光面积太小；PWM 频率太低，电机响应迟钝；视觉识别带来的控制中断打断了循迹的连续性。

解决：先把灰度传感器降低到距地面 1.5 厘米到 2.5 厘米之间，让黑线的宽度在传感器视野里至少占到 1/3。再把 PWM 频率从 1kHz 提到 10kHz 以上，频率提高后，电机的电流纹波变小，响应更线性。关于视觉中断，我强烈建议不要用“识别到目标就打断循迹”，而是把视觉识别结果作为一个小状态机里的“事件条件”，优先完成当前 20ms 的控制周期，下一周期再响应视觉动作。这样能避免在弯道循迹时，摄像头因为目标偏出视野而继续执行上一帧动作，导致车冲出赛道。

5.4 现象：形状识别误判很多，矩形被识别成圆形

原因分析：面积比方法本身有取舍。比如一个正方形在画面里带了一点透视，它的实际像素面积会略小于外接矩形面积，如果阈值区间太窄，就容易滑到圆形区间。另一个常见情况是目标距离镜头太远，色块只有几十个像素，面积比波动非常大。

解决：在find_color_blob的调用里把pixels_min从 100 提高到 200 或 300，让过小的目标直接不参与形状判断。同时，在shape_detect函数的矩形分支里加入更严格的长宽比判断，比如要求abs(w/h - 1.0)小于 0.4，或者反过来，当area_ratio在 0.75 到 0.85 之间且长宽比也非常接近 1 时才允许判定为圆形。如果目标确实容易和圆形混淆，最简单的办法是加入一个“目标尺寸”的约束，比如尺寸太小时直接返回unknown。

5.5 现象：STM32 串口中断里做了耗时操作，导致整个系统卡顿

原因分析：这是很多刚接触 HAL 库的人会踩的坑。HAL_UART_RxCpltCallback是在中断上下文里执行的，如果在这个函数里调用printf到串口调试工具、或者调用HAL_Delay，那么中断会被阻塞几十甚至上百毫秒。电机控制用的定时器中断虽然优先级可能更高，但同一个 CPU 在处理完当前中断之前不会去响应别的中断，所以电机 PWM 波形可能会出现瞬间断裂，听起来就是电机“咔咔”响。

解决：严格遵守“中断只负责收数据，一切解析和执行放到主循环”的原则。上面代码里的HAL_UART_RxCpltCallback只做了存缓冲区，这个函数执行时间在微秒级别，不会影响任何高优先级中断。如果以后想更高效，可以用 DMA 接收加空闲中断，让 CPU 完全不用逐字节处理串口接收，只在收到完整一帧时进入一次中断。初版不推荐直接上 DMA，先把逻辑调通，再考虑性能优化。

6. 进阶用法与验证技巧：让“封装好的模块”真正可复用

当你把颜色、形状、串口都封装好之后，下一步不是急着加更多功能，而是先建立一套“可重复验证”的方法。我习惯做一个小工具：用 USB 转 TTL 线把 OpenMV 的串口接到 PC，写一个最简单的 Python 脚本读串口数据，打印出颜色 ID 和形状 ID。这样不用每次都在 STM32 那边点灯验证，效率高很多。

import serial ser = serial.Serial('COM5', 115200, timeout=0.5) buffer = b'' while True: data = ser.read(64) if data: buffer += data # 在缓冲区里查找帧头 0xA5 和后续6字节 while len(buffer) >= 7: idx = buffer.find(b'\xA5') if idx == -1: buffer = b'' break if idx > 0: buffer = buffer[idx:] if len(buffer) < 7: break frame = buffer[:7] if sum(frame[:6]) & 0xFF == frame[6]: color_id = frame[1] shape_id = frame[2] x = frame[3] y = frame[4] size = frame[5] print(f"color={color_id}, shape={shape_id}, x={x}, y={y}, size={size}") buffer = buffer[7:] else: buffer = buffer[1:]

这段脚本的价值在于，它和 STM32 端的解析逻辑完全一致，能帮你快速确认 OpenMV 发送的数据是否可靠。接下来，你可以把这个脚本换成你最喜欢的串口调试助手，或者直接在 OpenMV IDE 的串口终端里观察原始字节，都能达到同样的效果。

再一个进阶方向是“阈值动态配置”。OpenMV 的 MicroPython 支持操作文件系统，你可以把阈值存成 JSON 文件，上电时读取，然后通过串口命令在线修改。我一般会在main.py开头加一段逻辑：

import json, io try: f = open('thresholds.json', 'r') params = json.load(f) f.close() RED_THRESHOLD = tuple(params['red']) except: RED_THRESHOLD = (10, 100, 20, 80, -10, 60)

这样在比赛场地临时换灯，只需要在 OpenMV 里打开一个文件改六个数字，不用反复烧录。如果你想让“封装好的模块”对新手更友好，可以在shape_detect.py里加一个debug参数，为 True 时在图像上绘制外接矩形和文字，方便现场观察阈值切得对不对。

这些看似零碎的习惯，正是避免“换了地方就翻车”的有效手段。我现在每调一个新场景，都会先关掉自动白平衡，用直方图工具拉一遍阈值，再跑一遍 PC 端串口验证脚本，最后才上到小车里联调。这套流程帮我省掉了很多无谓的玄学调参。希望你能把本文里的协议、代码和坑都当成一个起点，把手头的小车变成一个真正能稳定识别、快速复用的验证平台，希望帮到你。

本文还有配套的精品资源，点击获取