OpenMV与STM32F103C8T6串口通信实现物料搬运机器人视觉控制

简介这份资源面向参加工程训练类比赛的学生与嵌入式初学者提供一套基于OpenMV视觉模块与STM32F103C8T6微控制器的物料搬运机器人完整代码方案用C语言实现图像识别、目标定位与运动控制的协同解决机器人自主识别物料并完成抓取搬运的问题。压缩包共287个文件约6.62MB以c源文件与h头文件构成主要逻辑配合s启动文件、uvproj与uvopt工程配置、hex与axf烧录产物及map、lst等编译中间文件另有少量txt说明与bat脚本目录结构贴近真实Keil工程便于直接打开与二次修改。资源已有1648人学习下载说明其在赛题实践中有一定参考价值。读者可从中获得视觉与主控通信、外设驱动、任务调度与调试排错的完整实现思路并借助代码良好的可移植性在修改参数后迁移到其他型号单片机适合作为备赛与嵌入式入门的实战参考。1. 从一堆散装代码到能跑起来的搬运机器人这套 OpenMV STM32F103C8T6 方案到底解决什么问题很多人第一次做物料搬运机器人卡住的地方不是算法而是“眼睛”和“手”对不上OpenMV 在那边识别到色块STM32 这边电机还在原地打转串口日志刷得飞快机械臂却纹丝不动。这套代码包就是冲着这个痛点来的——用 OpenMV 做视觉识别STM32F103C8T6 做运动控制与任务调度C 语言把两边串起来形成一条“看到物料 → 定位坐标 → 下发指令 → 舵机/电机执行搬运”的完整链路。它适合正在做课程设计、竞赛小车或产线搬运 Demo 的开发者尤其是手里已经有 OpenMV 和一块蓝色药丸板、想把它们真正联调起来的人。代码结构不花哨但该有的串口协议、坐标映射、动作状态机都在拿来做二次开发的底子比从零搭要省不少事。2. 系统架构与目录结构视觉端、控制端、通信链路怎么分工2.1 两端一链路的整体设计这套项目的架构可以拆成三层感知层、决策层、执行层。感知层是 OpenMV 摄像头模块负责图像采集、颜色阈值分割、色块查找输出物料在画面中的像素坐标决策层是 STM32F103C8T6负责接收坐标、做像素到机械臂坐标的映射、维护搬运任务状态机执行层是舵机云台加夹爪或轮式底盘加机械臂由 STM32 的定时器 PWM 驱动。两端之间走 UART 串口帧格式通常是“帧头 坐标 校验 帧尾”波特率常见配 115200。为什么选 STM32F103C8T6 而不是更高端的片子这个场景下它够用72MHz 主频、64KB Flash、20KB RAM跑一个状态机加几路 PWM 绰绰有余而且成本低、资料多翻车了也好查。OpenMV 那边用 MicroPython 写视觉逻辑STM32 这边用 C 语言写控制逻辑分工清晰各自干擅长的事。2.2 目录结构长什么样代码包解压后大致是下面这种组织方式不同人整理习惯会有差异但核心文件跑不掉物料搬运机器人/ ├── openmv/ │ ├── main.py # 视觉主程序初始化、找色块、发串口 │ ├── color_config.py # 颜色阈值配置 │ └── pid.py # 云台/底盘闭环可选 ├── stm32/ │ ├── Core/ │ │ ├── Src/ │ │ │ ├── main.c # 主循环、任务调度 │ │ │ ├── usart.c # 串口收发与协议解析 │ │ │ ├── tim.c # PWM 输出、定时器中断 │ │ │ └── gpio.c # 限位、使能、方向引脚 │ │ └── Inc/ │ ├── Drivers/ # HAL 库 │ └── MDK-ARM/ # Keil 工程文件 └── docs/ └── 接线说明.mdOpenMV 端只有一个main.py是真正要改的颜色阈值和串口发送都在这STM32 端是标准 HAL 工程main.c里放主循环usart.c里放中断接收和协议解析tim.c里放 PWM 初始化。接线说明一般会写清楚 OpenMV 的 P4/P5 接 STM32 的 PA10/PA9交叉接TX 对 RX共地必须接否则串口数据就是玄学。2.3 通信协议与坐标映射串口帧我一般会设计成定长方便解析。比如 8 字节一帧/* 帧格式: 0xAA 0x55 | x_h x_l | y_h y_l | flag | checksum */ #define FRAME_HEAD1 0xAA #define FRAME_HEAD2 0x55 #define FRAME_LEN 8 typedef struct { int16_t x; int16_t y; uint8_t flag; // 0无物料 1检测到物料 } VisionData_t;解析时在串口中断里逐字节收收到帧头就进状态机收满 8 字节校验和通过再置标志位主循环里消费。这样做的原因是中断里不做耗时操作避免丢帧。坐标映射则是把 OpenMV 的像素坐标比如 320x240 画面线性映射到舵机角度范围/* 像素坐标 - 舵机角度假设画面宽320舵机范围0~180度 */ int16_t pixel_to_servo_x(int16_t px) { int32_t angle (int32_t)px * 180 / 320; if (angle 0) angle 0; if (angle 180) angle 180; return (int16_t)angle; }这段映射看着简单但实际调试时你会发现画面中心和机械臂中心不一定重合得加一个偏移量offset这个值只能靠实测标定没有捷径。3. 核心模块拆解OpenMV 找色块与 STM32 串口解析的完整链路3.1 OpenMV 端阈值分割与色块查找视觉端的核心就三件事设阈值、找色块、发坐标。main.py里典型写法是这样import sensor, image, time from pyb import UART sensor.reset() sensor.set_pixformat(sensor.RGB565) sensor.set_framesize(sensor.QVGA) # 320x240 sensor.skip_frames(time2000) # 红色物料阈值 (L, A, B) 范围需按实际光照调 red_threshold (30, 100, 15, 127, 15, 127) uart UART(3, 115200) while True: img sensor.snapshot() blobs img.find_blobs([red_threshold], pixels_threshold200, area_threshold200) if blobs: b max(blobs, keylambda x: x.pixels()) # 取最大色块 cx, cy b.cx(), b.cy() # 帧: 0xAA 0x55 x_h x_l y_h y_l flag checksum data bytearray([0xAA, 0x55, (cx 8) 0xFF, cx 0xFF, (cy 8) 0xFF, cy 0xFF, 1, 0]) data[7] sum(data[0:7]) 0xFF uart.write(data) else: uart.write(bytearray([0xAA, 0x55, 0, 0, 0, 0, 0, 0xAA ^ 0x55])) time.sleep_ms(50)pixels_threshold和area_threshold是过滤噪点的关键参数设太小会把反光当物料设太大又漏检小目标。find_blobs返回的cx/cy是色块中心像素坐标直接塞进帧里。发送间隔 50ms 是经验值太快 STM32 处理不过来太慢机械臂动作会一顿一顿。3.2 STM32 端串口中断接收与协议状态机STM32 这边用 HAL 库的HAL_UART_Receive_IT逐字节收中断回调里跑状态机/* usart.c 中的接收状态机 */ typedef enum { WAIT_H1, WAIT_H2, RECV_DATA, RECV_SUM } RxState_t; static RxState_t rx_state WAIT_H1; static uint8_t rx_buf[FRAME_LEN]; static uint8_t rx_idx 0; volatile VisionData_t g_vision {0}; volatile uint8_t g_new_data 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { uint8_t byte rx_buf[0]; // 单字节接收缓冲 switch (rx_state) { case WAIT_H1: if (byte FRAME_HEAD1) rx_state WAIT_H2; break; case WAIT_H2: rx_state (byte FRAME_HEAD2) ? RECV_DATA : WAIT_H1; rx_idx 0; break; case RECV_DATA: rx_buf[rx_idx] byte; if (rx_idx 6) rx_state RECV_SUM; break; case RECV_SUM: { uint8_t sum 0; for (int i 0; i 6; i) sum rx_buf[i]; if (sum byte) { g_vision.x (rx_buf[0] 8) | rx_buf[1]; g_vision.y (rx_buf[2] 8) | rx_buf[3]; g_vision.flag rx_buf[4]; g_new_data 1; } rx_state WAIT_H1; break; } } HAL_UART_Receive_IT(huart, rx_buf, 1); // 重新挂接收 }这里有个容易翻车的点rx_buf既当单字节缓冲又当数据缓冲逻辑上要分清。更稳妥的做法是单独开一个uint8_t rx_byte给中断用数据存到另一个数组。校验和用累加和就够别上 CRC16小项目没必要。3.3 主循环任务状态机与动作执行主循环不阻塞靠g_new_data标志驱动typedef enum { IDLE, MOVE_TO_TARGET, GRAB, LIFT, PLACE } TaskState_t; static TaskState_t state IDLE; while (1) { if (g_new_data g_vision.flag) { g_new_data 0; int16_t angle_x pixel_to_servo_x(g_vision.x); int16_t angle_y pixel_to_servo_y(g_vision.y); servo_set(SERVO_X, angle_x); servo_set(SERVO_Y, angle_y); state MOVE_TO_TARGET; } switch (state) { case MOVE_TO_TARGET: if (servo_arrived()) state GRAB; break; case GRAB: grab_close(); HAL_Delay(300); state LIFT; break; /* ... 后续状态 ... */ } }servo_arrived()靠定时器计数判断舵机是否到位HAL_Delay在状态机里要慎用会拖慢响应更好的做法是用HAL_GetTick()做非阻塞延时。4. 跑起来环境搭建、烧录与联调步骤4.1 OpenMV 端环境与烧录OpenMV IDE 装好后把main.py和color_config.py拷到 SD 卡或直接通过 IDE 保存到模块 Flash。上电后先别急着接 STM32单独跑视觉在 IDE 里看帧缓冲用“阈值编辑器”工具拖滑块调红色范围直到画面里只有物料被框住。这一步偷懒后面全是坑——光照一变阈值就废所以最好在最终场地调。调好后把串口线接上OpenMV 的 P4(TX) 接 STM32 的 PA10(RX)P5(RX) 接 PA9(TX)GND 对 GND。注意 OpenMV 是 3.3V 电平STM32F103 也是 3.3V直连没问题别接 5V。4.2 STM32 端编译与下载用 Keil MDK 打开MDK-ARM下的工程确认芯片选的是 STM32F103C8。编译前检查usart.c里波特率是不是 115200、引脚是不是 PA9/PA10。下载用 ST-Link接线 SWDIO/SWCLK/GND/3.3V 四根。烧录后先别装机械臂用串口助手看 STM32 有没有把收到的坐标打印出来确认链路通了再上执行机构。4.3 联调顺序与验证方法联调我一般按这个顺序走先单独验 OpenMV 串口输出用 USB-TTL 接电脑看帧再单独验 STM32 串口接收发假帧测试最后合起来。合起来时先让机械臂空载动看云台能不能跟着色块走再加夹爪。每一步都留日志STM32 上用printf重定向到串口OpenMV 上用print出问题先看日志再猜硬件。提示共地是串口通信的第一前提很多人调半天以为是协议问题其实是两块板子没共地。5. 避坑与常见问题排查那些调了两天才想明白的事5.1 串口收不到数据或全是乱码现象STM32 串口助手一片乱码或者干脆没反应。原因通常是三选一波特率不一致、TX/RX 没交叉、没共地。解决先用示波器或逻辑分析仪看 OpenMV TX 脚有没有波形有波形但乱码就查波特率没波形就查接线。另外 OpenMV 的 UART(3) 对应 P4/P5别接错到别的引脚。5.2 色块识别忽有忽无现象物料明明在画面里find_blobs有时返回空。原因多半是阈值范围太窄或光照变化。解决把pixels_threshold降到 100 试试同时在color_config.py里把阈值范围放宽但别放太宽否则背景会被误识别。更稳的做法是加一个img.binary()预处理或者用find_blobs的mergeTrue合并相邻色块。5.3 舵机抖动或不动现象PWM 给了但舵机嗡嗡响不转或者转到位后抖。原因PWM 频率不对舵机一般要 50Hz、占空比范围超了0.5ms~2.5ms 对应 0~180 度、供电不足。解决查tim.c里预分频和重装载值算出来的频率是不是 50Hz舵机单独供电别从 STM32 的 3.3V 取电电流不够会拉低电压导致复位。5.4 坐标映射偏得离谱现象色块在画面左边机械臂却往右走。原因像素坐标和舵机角度的方向没对齐或者画面中心没标定。解决在pixel_to_servo_x里加方向取反和偏移量拿一个已知位置的物料实测记下偏差值填进去。这个标定每个机械臂都不一样抄不了别人的参数。5.5 主循环卡死或复位现象跑一会儿 STM32 重启。原因中断里做了耗时操作、栈溢出、或者电机干扰导致电源跌落。解决中断里只置标志位解析放主循环检查HAL_Delay是不是在中断里被调用电机电源和 MCU 电源分开走加个大电容。6. 二次开发把搬运逻辑改成你自己的任务流这套代码的扩展点其实很集中改的地方无非三处视觉端加识别类别、通信协议加字段、STM32 端改状态机。比如你要从“搬红色方块”变成“分红蓝两色分拣”OpenMV 端就多设一组蓝色阈值帧里flag字段从 1 位扩成 2 位表示颜色类别# 扩展flag 低2位表示颜色 01红 10蓝 if red_blobs: color_flag 0x01 elif blue_blobs: color_flag 0x02STM32 端解析时按flag 0x03分支红料走 A 仓位、蓝料走 B 仓位状态机里加一个target_bin变量就行。再进一步如果要做多物料连续搬运把IDLE状态改成队列消费OpenMV 每识别一个就入队STM32 按队列顺序执行这样不会因为视觉刷新快而丢任务。验证改造是否成功我习惯用“假帧注入”法写个串口助手脚本按协议定时发不同坐标和 flag 的帧看机械臂动作是否符合预期这样能把视觉和控制的耦合拆开测。下面这个 Python 脚本可以直接用import serial, time, struct ser serial.Serial(COM3, 115200, timeout1) def send_frame(x, y, flag): frame bytearray([0xAA, 0x55, (x 8) 0xFF, x 0xFF, (y 8) 0xFF, y 0xFF, flag, 0]) frame[7] sum(frame[0:7]) 0xFF ser.write(frame) # 模拟物料从画面左移到右 for px in range(0, 320, 20): send_frame(px, 120, 1) time.sleep(0.2)跑通这个脚本说明 STM32 端的协议解析和动作映射没问题剩下的就是视觉端调阈值。改造时还有个小技巧把像素到角度的映射参数偏移、比例、方向抽成宏定义放头文件里换机械臂时只改这几个数不用翻main.c。血泪经验是我每次改完协议字段都忘了同步改校验和的计算范围结果 STM32 一直丢帧查了两小时才发现是sum少加了一个字节。从那以后我每次动协议都先用假帧脚本跑一遍全字段确认收发一致再上真机。希望这套拆解能帮你少走点弯路把 OpenMV 和 STM32 这对组合真正跑顺。本文还有配套的精品资源点击获取