简介基于OpenMV与STM32F103C8T6的物料搬运机器人代码包专为工程训练竞赛场景设计面向需要快速上手视觉导航与机械臂控制的嵌入式开发者。代码采用C语言编写OpenMV负责物料识别与定位STM32完成运动控制与决策两者通过串口通信协同构成完整的视觉搬运闭环。压缩包共287个文件大小6.62MB主要包含C源码、H头文件、编译生成的O目标文件及D依赖文件另有工程配置文件、链接脚本和Hex烧录文件便于直接打开工程、编译调试与下载固件。已有1643人学习该资源适合作为备赛参考或入门项目。内容覆盖OpenMV图像预处理、STM32外设驱动、多任务调度与中断处理代码结构清晰且注释较完整资源描述还提示32位单片机代码可移植至其他型号只需调整参数对想要扩展硬件平台或深入理解嵌入式视觉控制的开发者颇具参考价值。1. OpenMV 与 STM32F103C8T6 搭物料搬运机器人视觉识别不再只是黑匣子OpenMV STM32F103C8T6 实现的物料搬运机器人是我拆过的最适合入门视觉分拣的一套组合。OpenMV 负责看——识别物料的颜色、位置、尺寸STM32F103C8T6 负责动——驱动舵机、步进电机完成抓取和搬运。整套逻辑不需要跑 Linux不需要额外部署上位机一块摄像头加一颗 Cortex-M3 单片机就能把分拣流程跑通。这套资源适合正在做课程设计或产线模拟项目的从业者也适合想搞懂“视觉模块到底怎么跟运动控制联动”的嵌入式开发者。它的价值不在算法多深而是把视觉识别、串口通信、状态机控制串成了一条完整链路。2. 系统框架与选型逻辑为什么 OpenMV 负责看、STM32 负责动2.1 物料搬运的典型硬件拓扑视觉端与控制端各司其职物料搬运机器人的硬件拓扑常见做法是“上位视觉 下位运动”的双芯片架构。OpenMV 摄像头模块内置了 Micropython 解释器图像处理库封装了色块识别、模板匹配、 AprilTag 检测等功能开发者不需要在单片机里折腾像素级运算。STM32F103C8T6 这边64KB Flash、20KB RAM 的资源跑图像算法太勉强但跑电机控制、串口解析、舵机 PWM 输出绰绰有余。我一般把系统拆成四个单元视觉采集单元OpenMV、通信链路UART 串口、运动执行单元舵机/步进电机、主控决策单元STM32F103C8T6。OpenMV 识别到物料后把目标坐标和尺寸打包成固定格式的字节流通过串口发给 STM32STM32 解析出坐标后根据预设的抓取逻辑计算脉冲数或 PWM 占空比驱动机械臂移动到位、夹爪闭合、提升、搬运、释放。双芯片的好处是隔离故障。视觉识别受环境光照影响大代码调试时会反复改阈值、改 ROI如果跟运动控制混在一块每次改参数都得重新编译下载整个工程。分开之后OpenMV 出问题只动 OpenMV 的代码STM32 出问题只动 C 工程联调时定位缺陷快很多。2.2 STM32F103C8T6 的资源配置与 C 语言工程框架STM32F103C8T6 是 LQFP48 封装20KB SRAM 和 64KB Flash。物料分拣场景里我建议的内存分配策略是串口接收缓冲区分配 32 字节就够一帧数据最长 10 字节运动控制状态变量分配 50 字节以内剩下的留给堆栈和中间变量。工程框架上常见有标准外设库和 HAL 库两种选择。标准外设库代码执行效率高、寄存器操作清晰适合定时器 PWM 输出这种实时性要求高的场景HAL 库抽象层厚适合快速开发但有额外的函数调用开销。我的习惯是用标准外设库因为物料搬运涉及舵机角度控制PWM 周期和占空比需要精细调整标准库的TIM_SetCompare1()这类接口操作直观出问题也好查寄存器。C 语言工程的核心模块按功能拆成三个文件uart_protocol.c负责串口接收解析motion_ctrl.c负责电机和舵机控制main.c只做状态调度。这套结构的好处是每个文件职责单一后续加功能不用推倒重来。2.3 OpenMV 与 STM32 的通信协议帧头、帧尾、校验位一个都不能少视觉数据传输出问题是联调时最容易翻车的地方。很多初学者直接把 OpenMV 的 print 输出当串口数据发结果 STM32 那边收到的字节乱成一团。正确做法是定义一套私有协议帧我用的是这样的格式字节偏移内容说明00xAA帧头110x55帧头22-3X 坐标16位大端序4-5Y 坐标16位大端序6-7宽度 W16位大端序80x0D帧尾190x0A帧尾2选双字节帧头0xAA 0x55是因为这两个值不容易在正常数据里出现帧尾用 CRLF 是惯例方便用串口调试助手直接看。每个坐标用两个字节是为了预留扩展空间——如果物料种类变多还可以往帧里塞颜色 ID 字段。通信格式可变但帧头判断必须在接收状态机里最先处理这是后面排查错帧问题的关键。3. OpenMV 端视觉识别把物料位置变成 STM32 能读的坐标3.1 初始化配置与颜色阈值标定用 LAB 而不是 RGBOpenMV 的初始化代码里有个细节直接影响识别稳定性把白平衡关掉。RGB 颜色空间对光照敏感同一个物料在上午和下午拍出来的 RGB 值完全不同LAB 空间把亮度和颜色分离L 通道管亮度A、B 通道管色度固定光源下阈值不容易漂移。一个典型的初始化函数是这样写的import sensor, image, time from pyb import UART # 复位并配置摄像头 sensor.reset() sensor.set_pixformat(sensor.RGB565) # RGB565格式色彩信息完整 sensor.set_framesize(sensor.QVGA) # 320x240分辨率够用且处理快 sensor.skip_frames(20) # 跳过前20帧让自动曝光稳定 sensor.set_auto_whitebal(False) # 关闭自动白平衡 # 串口3初始化波特率1152008位数据无校验 uart UART(3, 115200, timeout_char1000) # 红色物料的LAB阈值实际取值用OpenMV IDE的阈值编辑器调 red_threshold (25, 60, 30, 70, 30, 70)这段代码里set_auto_whitebal(False)是关键。如果开着白平衡摄像头会自动补偿环境光的色温变化导致同一个物料在识别时阈值时好时坏。阈值编辑器里有六个值对应 LAB 的 L 最小值、L 最大值、A 最小值、A 最大值、B 最小值、B 最大值。参数选择方面QVGA分辨率抓帧速度比VGA快一倍对物料定位够用如果物料很小或者拍摄距离远再调高分辨率。skip_frames太少会导致第一帧过曝或欠曝建议至少跳过 20 帧让自动曝光收敛。3.2 色块识别与坐标提取面积过滤避免误抓OpenMV 的find_blobs()是色块识别的核心接口它会扫描图像中所有符合阈值条件的连通域返回一个 blob 对象列表。实际场景里画面中可能有反光点、阴影边缘、甚至杂物标签所以需要用pixels_threshold和area_threshold过滤掉小面积噪点。坐标提取与发送的典型代码是这样的while True: img sensor.snapshot() # 查找所有符合红色阈值的色块过滤掉小于150像素的目标 blobs img.find_blobs([red_threshold], pixels_threshold150, area_threshold150) if blobs: # 取面积最大的色块作为目标避免多个杂物干扰 blob max(blobs, keylambda b: b.area()) x blob.cx() # 色块中心x坐标 y blob.cy() # 色块中心y坐标 w blob.w() # 色块宽度可用于估算物料大小 # 按协议帧格式打包帧头 坐标(大端序) 帧尾 frame bytearray([0xAA, 0x55, x 8, x 0xFF, y 8, y 0xFF, w 8, w 0xFF, 0x0D, 0x0A]) uart.write(frame)这段代码里的max(blobs, keylambda b: b.area())是处理多目标的常用手段。当画面里同时出现两个物料时取面积最大的那个也就是离摄像头最近或者体积最大的目标。如果场景固定也可以用blobs[0]但面积排序更稳。坐标字节用x 8和x 0xFF拆成高位、低位确保 STM32 端能按大端序重组。帧头、帧尾的字节值必须和 STM32 端 C 语言里的宏定义完全一致差一个字节都会导致接收状态机卡死。3.3 多类型物料扩展颜色分类与摄像机安装角度补偿如果物料的颜色不止一种可以在 OpenMV 端定义多个阈值组识别结果里加一个颜色 ID 字段。把阈值定义成列表# 每种颜色一组阈值按顺序编ID color_thresholds [ (25, 60, 30, 70, 30, 70), # 0: 红色 (0, 40, 0, 40, 60, 120), # 1: 蓝色 ] color_id 0 for i, th in enumerate(color_thresholds): blobs img.find_blobs([th], pixels_threshold150) if blobs: color_id i blob max(blobs, keylambda b: b.area()) break摄像机安装角度也会影响坐标精度。如果 OpenMV 镜头垂直朝下正对物料抓取区图像坐标和机械臂坐标是近似线性映射如果镜头有倾斜画面边缘的物料坐标会偏移明显。我的处理办法是只相信图像中心区域的识别结果在 STM32 端设定工作区域边界超出边界的坐标直接丢弃避免机械臂空跑。4. STM32F103C8T6 端 C 语言实现串口解析与运动状态机4.1 C 语言工程框架串口中断接收 主循环状态调度STM32F103C8T6 端的核心是搞明白“数据从哪来、要去哪”。一个成熟的方案是串口中断只负责收字节并存入缓冲区主循环负责解析和运动控制。这样做的好处是中断服务函数短小、不阻塞其他中断解析逻辑出错也不会拖垮系统。先定义协议相关的常量和目标数据结构/* uart_protocol.h */ #define FRAME_HEAD1 0xAA #define FRAME_HEAD2 0x55 #define FRAME_TAIL1 0x0D #define FRAME_TAIL2 0x0A #define RX_BUFFER_SIZE 16 typedef struct { uint16_t x; /* 物料中心的图像x坐标 */ uint16_t y; /* 物料中心的图像y坐标 */ uint16_t width; /* 物料色块宽度 */ uint8_t valid; /* 1表示收到有效目标 */ } target_info_t; extern volatile target_info_t g_target;用volatile修饰全局目标结构体是因为它会在中断里被写、在主循环里被读没有这个修饰符编译器可能把变量优化到寄存器里导致主循环读到的是一份过期缓存。4.2 串口接收状态机手写解析比 HAL 库的阻塞接收靠谱很多新手用HAL_UART_Receive()做阻塞接收结果主循环卡在等待数据上电机转不了、舵机不动。正确做法是把串口接收做成一个简单的状态机中断每收到一个字节就推进一次状态/* uart_protocol.c */ static uint8_t rx_buf[RX_BUFFER_SIZE]; static uint8_t rx_index 0; static uint8_t rx_state 0; void UART_IRQHandler(void) { uint8_t ch; if (USART_GetITStatus(USART1, USART_IT_RXNE)) { ch USART_ReceiveData(USART1); switch (rx_state) { case 0: /* 等待帧头1 */ if (ch FRAME_HEAD1) rx_state 1; break; case 1: /* 等待帧头2 */ if (ch FRAME_HEAD2) { rx_state 2; rx_index 0; } else rx_state 0; break; case 2: /* 接收6字节数据 */ rx_buf[rx_index] ch; if (rx_index 6) rx_state 3; break; case 3: /* 等待帧尾1 */ if (ch FRAME_TAIL1) rx_state 4; else { rx_state 0; rx_index 0; } break; case 4: /* 等待帧尾2 */ if (ch FRAME_TAIL2) { g_target.x (rx_buf[0] 8) | rx_buf[1]; g_target.y (rx_buf[2] 8) | rx_buf[3]; g_target.width (rx_buf[4] 8) | rx_buf[5]; g_target.valid 1; } rx_state 0; rx_index 0; break; default: rx_state 0; rx_index 0; break; } } }这个状态机的核心逻辑是“逐个字节推进”。任何一个字节不符合预期都会让状态机回到初始状态避免粘包导致后续数据全乱。另一个细节是rx_index在进入数据接收状态时清零防止上一帧的残留数据污染。g_target.valid标志位很重要主循环发现它为 1 就执行抓取动作执行完后必须手动清零否则会重复抓同一个目标。4.3 运动控制状态机用 switch-case 管理抓取流程机械臂的抓取流程不是一次动作而是“到位-夹紧-提升-搬运-释放”的连续动作序列。用状态机管理每个状态只做一件事事件完成后切到下一个状态。状态机比顺序延时写法好在可维护中间任何一步失败都能定位到具体状态。/* motion_ctrl.c */ typedef enum { MOVE_TO_TARGET, /* 水平移动至物料上方 */ GRASP_CLOSE, /* 夹爪闭合 */ LIFT_UP, /* 垂直提升 */ MOVE_TO_PLACE, /* 平移至放置区 */ RELEASE_OPEN, /* 夹爪打开 */ MOVE_TO_RESET, /* 回到初始位置 */ } motion_state_t; void motion_task(void) { static motion_state_t state MOVE_TO_RESET; switch (state) { case MOVE_TO_TARGET: if (g_target.valid) { /* 把图像x坐标映射为步进电机脉冲数 */ uint16_t pulses (uint16_t)((float)g_target.x / 320.0f * 2000.0f); stepper_move_to(pulses); state GRASP_CLOSE; } break; case GRASP_CLOSE: /* 舵机PWM占空比调至夹紧角度 */ servo_set_angle(GRASP_SERVO, 150); delay_ms(300); /* 等待夹爪完全闭合 */ state LIFT_UP; break; case LIFT_UP: stepper_move_rel(200); /* 提升200脉冲 */ state MOVE_TO_PLACE; break; case MOVE_TO_PLACE: stepper_move_to(PLACE_POS); state RELEASE_OPEN; break; case RELEASE_OPEN: servo_set_angle(GRASP_SERVO, 60); delay_ms(200); g_target.valid 0; /* 清除目标防止重复抓取 */ state MOVE_TO_RESET; break; case MOVE_TO_RESET: if (stepper_is_stopped()) state MOVE_TO_TARGET; break; default: state MOVE_TO_RESET; break; } }这个状态机的关键设计点是delay_ms(300)的时长选择。舵机从 60 度转到 150 度需要时间如果切换得太快夹爪还没闭合就进入提拉动作物料会在半路掉下来。300ms 是一个保守值具体数值根据舵机型号调整扭矩小的舵机适当延长到 400ms。另一个容易忽略的点是g_target.valid清零要放在RELEASE_OPEN状态里而不是MOVE_TO_TARGET刚开始时。如果提前清零机械臂还没走完流程、新目标又进来状态机就会被新数据打断出现“抓手在半空中乱晃”的失控现象。5. 避坑指南串口丢帧、舵机抖动、坐标偏移的排查记录5.1 串口收到的数据全是乱码或错帧现象用串口调试助手看 OpenMV 发来的数据帧头对不上或者 STM32 解析出的 X、Y 坐标忽大忽小机械臂动作完全随机。原因我排查的第一个项目里OpenMV 的串口 TX 接了 STM32 的 RX但两个模块的 GND 没有接在一起。串口通信是电平参考制参考地不同导致信号电平漂移此外 OpenMV 和 STM32 的波特率实际值有偏差尤其是内部 RC 振荡器误差可能到 2%长时间传输后累积错位。解决统一共地是第一原则OpenMV 的 GND 和 STM32 的 GND 之间必须连一根杜邦线。波特率方面在 STM32 端改用外部晶振或者校准过的 HSE 时钟源同时把串口帧设计成上文的“双帧头双帧尾”结构任何一个字节不匹配就丢弃整帧能挡住大部分错位问题。5.2 舵机抖动、夹爪定位不准现象舵机上电后一直嗡嗡响夹爪角度不稳定或者夹爪动作时好时坏有时候夹得紧有时候夹不紧。原因这类问题九成是电源不足。物料搬运机器人里STM32、OpenMV、舵机、步进电机全部从同一个 USB 口供电时舵机启动瞬间电流可能到 1A 以上瞬间拉低电压导致 STM32 复位或者舵机控制信号毛刺。解决舵机和主控分开供电。我现在的做法是主控和 OpenMV 用 5V 稳压供电舵机和电机用单独的 6V/2A 以上电源适配器同时电源地共地。调试现场如果只有一路电源就在舵机电源引脚旁边并联一个 470uF 电解电容和 0.1uF 陶瓷电容能明显抑制启动瞬间的电压跌落。5.3 识别到的坐标明明是对的机械臂却抓不准现象OpenMV 端打印的坐标和物料实际位置一致图像中心的物料就在画面中央但机械臂过去后偏了 2-3 厘米。原因这是坐标系映射问题。OpenMV 的图像分辨率是 320×240图像中心点在 (160, 120)而机械臂的原点不一定是图像中心可能是机械臂底座位置。直接把图像坐标当机械臂坐标用原点不一致偏移就必然存在。解决做一次三点标定。让机械臂分别移动到画面左上、中心、右下三个位置记录机械臂的实际坐标和对应的图像坐标算出一个线性映射关系。实际使用时把图像坐标通过这个映射转换成机械臂坐标。项目里代码可以这样粗略转换/* 假设标定得到图像x与机械臂脉冲数的线性关系 */ float k 12.5f; /* 每像素对应的脉冲数由标定计算 */ float b -800.0f; /* 原点偏移补偿值 */ uint16_t pulses (uint16_t)(k * g_target.x b);比例系数 k 和偏置 b 没有万能值因为机械臂的机械结构、步距角、传动比、摄像头安装高度都会影响结果。每换一次安装位置标定数据就必须重测一组。5.4 STM32 程序跑飞或死循环现象机械臂执行几次抓取后突然不动了重按复位键又能跑一会儿但反复出现没有固定规律。原因排查到最后发现是主循环和串口中断共用了一个全局变量中断写数据时主循环正在读旧数据出现了数据撕裂。在 32 位平台下16 位变量的写操作不是原子的g_target.x可能在写高位时被主循环读走低位。解决尽量把协议解析和运动控制的数据交换简化为一个单独的标志位。我在上面的代码里用valid标志并且只在主循环确认抓到目标后才清零中断里的原始字节用volatile修饰防止编译器缓存。更严格的方案是关中断读数据但在这种低速场景下一个volatile标志位加合理时序已经足够。5.5 OpenMV 偶尔识别不到物料重启后又好现象设备工作十几分钟后OpenMV 画面里明明有物料但串口就是不发数据手动重启 OpenMV 后又能正常一段时间。原因这是摄像头感光元件发热导致的参数漂移。OpenMV 长时间运行后传感器温度升高同一颜色在画面里的 LAB 值会变化。阈值设置得刚好卡在边界上时温度一高就识别不到。解决阈值不要调到临界值。用 OpenMV IDE 的直方图工具观察目标颜色的分布范围阈值范围比实测值放宽 15%-20%。比如实测红色物料的 A 通道范围是 35-60就在代码里用 30-65 作为判断范围。另外在物料抓取区加一固定光源减少环境光的随机变化识别稳定性明显提高。6. 进阶给机械臂装上“预判”——传送带动态物料抓取静态物料抓取的流程是“看到再抓”但真实产线里物料往往在传送带上运动等机械臂到位时物料已经跑远了。这个场景的常见解法是加预判逻辑OpenMV 连续两帧采样同一个物料算出它在图像中的运动速度再用这个速度估算机械臂动作完成时物料的新位置。速度估算在 OpenMV 端就能做。维护一个上一帧的目标中心坐标两帧时间间隔由sensor.get_fb()的帧率推算last_x 0 last_t time.ticks_ms() while True: img sensor.snapshot() blobs img.find_blobs([red_threshold], pixels_threshold150) if blobs: target max(blobs, keylambda b: b.area()) now time.ticks_ms() dt time.ticks_diff(now, last_t) / 1000.0 if last_x ! 0 and dt 0: velocity_x (target.cx() - last_x) / dt # 预测未来0.5秒的位置0.5是机械臂动作完成时间 predict_x target.cx() int(velocity_x * 0.5) # 把预测后的坐标通过串口发送 last_x target.cx() last_t now这个预测里的 0.5 秒不是拍脑袋得实测机械臂从接收到坐标到完成夹爪闭合的时间。做法是让机械臂空跑一次完整抓取流程用示波器或定时器记录耗时取平均值。传送带速度变化不大的情况下这个线性预测的精度足够用。灰度异常检测也是这个系统的实用扩展。有些物料表面有破损但颜色没变色块识别看不出来。OpenMV 的img.get_pixel()可以取单个像素的灰度值在识别到的色块区域内随机采样几个点计算灰度平均值和方差。完好的物料表面灰度均匀方差小破损物料的灰度方差会明显偏大。STM32 端收到方差值后超过阈值就跳过抓取把物料归入次品区。这套代码的资源包我复现过一次从解压、接线、烧录到跑通静态分拣最快半天时间。从那以后我再做视觉相关的控制项目都会强制走一遍完整闭环——先验证通信链路再调视觉阈值最后才碰运动控制顺序反了排查成本会翻好几倍。希望帮到你。本文还有配套的精品资源点击获取