简介基于OpenMV的云台自动追踪项目源码面向嵌入式视觉与自动化控制学习者解决移动或静态目标的识别与实时跟踪问题。项目结合OpenMV摄像头模块与二轴云台通过颜色阈值、边缘检测等图像处理手段识别靶标并利用PID控制器调节云台角度实现闭环追踪代码采用MicroPython编写注释详细便于理解图像预处理、目标定位与串口通信等关键环节同时兼顾实时性与执行效率适合入门到进阶的开发者参考实践。压缩包共2个文件均为py脚本整体仅3KB轻量精炼包含主程序与打靶识别相关逻辑可直接在OpenMV环境中运行调试代码结构清晰便于二次修改与功能拓展。目前已有4186人学习覆盖从OpenMV视觉识别到云台伺服控制的完整流程尤其适合高校课程设计、电子竞赛及机器人兴趣小组借鉴。通过学习这套代码能够快速掌握图像特征提取、PID闭环控制、硬件接口配置等实用技能为后续扩展追踪算法或接入更多传感器打下基础。1. 有人把云台自动追踪做成了摆设问题不在摄像头基于 OpenMV 的云台自动追踪程序看着简单做起来最常见的结果是上电后云台转得飞快目标一出画面就再也追不回来。很多开发者第一反应是 OpenMV 识别不准但调到最后发现摄像头输出坐标挺稳定真正拖后腿的是控制逻辑——目标还在镜头里时算法反应过度目标消失时又不知道该干什么。这个项目本质上是一套“看见目标 → 算出像素偏差 → 驱动舵机 → 目标丢失后重新搜索”的闭环它的价值在于用最少的硬件把视觉与运动控制这条路完整打通适合做机器人对抗赛、低成本视觉跟随小车、定点监控云台这类场景也适合刚接触嵌入式视觉的开发者拿来练手。它不需要你一开始就上深度学习、激光雷达和价位惊人的工控机一个 OpenMV、两个舵机、几根杜邦线就能跑起来但想让它跑得稳得先把下面这套链路讲透。2. 目标识别把“看见什么”变成“偏差坐标”2.1 先选识别方式AprilTag 还是颜色块OpenMV 上做目标识别绕不开两条路颜色块追踪和 AprilTag 识别。颜色块追踪对光照敏感同一个红色小球上午在窗边和下午在灯下LAB 阈值完全不一样环境一变就容易翻车。AprilTag 的抗光照能力明显更强识别时直接转灰度图跑带 ID可以在多个标签里指定锁定某一个缺点是必须先在场景里贴好特定图案的标签。选型看你要追什么追自然物体比如球、人、反光衣用颜色块追固定标记位比如机器人对抗赛的队友标识、AGV 停靠点、巡线小车接驳站用 AprilTag 更省心。维度颜色块追踪AprilTag 追踪抗光照变化弱换环境常要重调阈值强灰度图即可稳定识别多目标区分难只能按面积、位置筛选有 ID可指定锁定某一标签识别距离中取决于色块物理面积可远取决于标签打印尺寸调参成本高LAB 阈值要反复试低打印标签贴好即可典型场景追球、追人、追色标固定站点、比赛标记、标定这里不提神经网络方案不是它不行而是 OpenMV 的内存和算力跑大模型比较吃力在云台这种对实时性要求高的场合传统视觉算法反而是更可靠的起点。我一般会建议先做颜色块把整条链路跑通再切换 AprilTag 做稳定性和多目标验证。2.2 色块追踪最小代码阈值、ROI 与质心坐标刚上手时最容易犯的错是把整个画面交给 find_blobs 去搜分辨率还开到 VGA结果帧率掉到每秒一两帧。代码层面要注意三件事关自动白平衡缩小 ROI过滤小面积噪声。下面这段是最小可运行版本import sensor, image, time sensor.reset() sensor.set_pixformat(sensor.RGB565) sensor.set_framesize(sensor.QVGA) # 320x240兼顾视野和速度 sensor.skip_frames(30) sensor.set_auto_whitebal(False) # 关自动白平衡防止颜色阈值漂移 # 在IDE的阈值编辑器里取色这里以红色为例LAB空间 red_threshold (30, 100, 15, 127, 15, 127) # 只搜索画面中央区域减少误检并提高帧率 roi (60, 40, 200, 160) while True: img sensor.snapshot() blobs img.find_blobs([red_threshold], roiroi, pixels_threshold100, area_threshold100, mergeTrue) if blobs: # 取面积最大的块作为追踪目标避免多目标跳变 largest max(blobs, keylambda b: b.area()) img.draw_rectangle(largest.rect()) img.draw_cross(largest.cx(), largest.cy()) print(cx%d cy%d area%d % (largest.cx(), largest.cy(), largest.area()))逻辑说明关闭自动白平衡是关键否则 OpenMV 会随环境光不停调整色彩映射同一个红色块在画面里的 LAB 值一直在变固定阈值就会失效。find_blobs 里的 red_threshold 是 LAB 空间的六元组L 通道与亮度相关A/B 通道与色度相关比 RGB 空间更抗光照变化。pixels_threshold 和 area_threshold 用来过滤掉零散噪点mergeTrue 表示把相邻的同一颜色块合并成一个整体避免物体被反光切成好几块。选面积最大的 blob 作为追踪目标是处理多目标干扰最简单有效的方式。ROI 参数把搜索范围限制在画面中间区域能明显提升帧率但要注意目标不要跑出 ROI否则云台会突然失去方向实际调试时我会把 ROI 放大到接近全画面再配合云台搜索动作做补偿。调阈值时不要硬编码然后一遍遍烧录试OpenMV IDE 里自带阈值编辑器连接设备后打开工具里的阈值编辑器窗口它会实时显示画面和所选区域的 LAB 值调好后再把数值粘回代码。这一步能省掉大量无效烧录时间属于你迟早会用到的效率技巧。2.3 用 AprilTag 输出稳定坐标ID 筛选与坐标打包AprilTag 的优势是输出结果非常干净直接给你中心点坐标、旋转角度和 ID不需要像颜色块那样反复调阈值。下面代码用灰度图识别 TAG36H11 家族并锁定 ID 为 1 的标签import sensor, image, time sensor.reset() sensor.set_pixformat(sensor.GRAYSCALE) # Tag识别用灰度图更快 sensor.set_framesize(sensor.QQVGA) # 160x120帧率优先 sensor.skip_frames(30) TARGET_ID 1 # 只跟踪这个ID的标签 while True: img sensor.snapshot() tags img.find_apriltags(familiesimage.TAG36H11) for tag in tags: if tag.id() TARGET_ID: img.draw_rectangle(tag.rect()) img.draw_cross(tag.cx(), tag.cy()) # 打印ID、中心坐标和旋转角 print(tag.id(), tag.cx(), tag.cy(), tag.rotation())find_apriltags 默认就能识别 TAG36H11这里显式写出来是提示你可以根据实际标签类型替换。TAG36H11 是 OpenMV 支持的最常用家族标签数量多适合现场为每个站点分配独立 ID。tag.rect() 返回标签外接矩形tag.rotation() 返回的是弧度值表示标签相对镜头的旋转角度云台做特殊任务比如要正对标签时可以拿这个值做闭环。灰度图比 RGB565 快不少分辨率上 QQVGA 能保证基础帧率如果识别距离不够再提到 QVGA代价是处理时间变长。多标签场景下用 ID 筛选可以避免云台在同一帧里左右摇摆——这种跳变在颜色块方案里很常见AprilTag 加 ID 后直接规避掉。下一步要解决的就是怎么把 tag.cx() 和 tag.cy() 变成舵机该转的角度。3. 云台控制链路从像素偏差到舵机角度3.1 架构选择OpenMV 直驱舵机还是视觉主控分离拿到坐标后常见做法有两种OpenMV 直接驱动云台舵机或者 OpenMV 只做视觉识别、把坐标通过串口发给主控、由主控驱动舵机。两种我都用过结论是做原型验证、课设、竞赛快速出效果选直驱做产品或者追求跟踪平滑度选分离。直驱省掉主控和通信协议代码量少但 OpenMV 的 CPU 同时要跑图像处理和控制计算舵机更新频率受帧率影响偶尔会感觉动作一顿一顿。分离式让 OpenMV 专心算坐标舵机控制、PID 计算、保护逻辑全放主控抗干扰能力和扩展性都更好代价是多一块板子和一套通信协议。对比项直驱方案OpenMV → 舵机分离方案OpenMV → 主控 → 舵机硬件成本低只需OpenMV加两个舵机中需额外主控或驱动板接线复杂度低信号线直连中需串口连线控制平滑度受图像帧率影响舵机控制独立平滑度好扩展性差加编码器、IMU困难好可扩展电机闭环适合阶段原型验证、学习Demo产品化、竞赛稳定方案如果你的舵机是模拟舵机直驱时直接用 PWM 输出即可OpenMV 的 PWM 频率设为 50Hz脉宽范围大约 0.5ms 到 2.5ms对应舵机 0 到 180 度。代码层面我下面按直驱方案展开因为对大多数想复现的读者来说这套链路最直接串口分离方案在第 5 章单独讲。3.2 像素到角度的解算死区、限位与增量式更新把目标坐标转换成舵机角度是整个程序里最容易出现“玄学”的部分。同一个程序换一个舵机表现就可能完全不一样根源往往不在代码逻辑而在你没有对角度更新加约束。核心逻辑是计算目标中心与画面中心的像素偏差偏差转成角度增量再叠加到当前舵机角度上。这里有个容易踩的坑是直接算绝对角度比如目标在画面右侧就把舵机打到 120 度结果云台转过去后目标在画面里的位置又变了于是舵机继续转形成追自己影子的死循环。正确做法是增量式更新每次只转一个小的角度步进PAN_CENTER 90 # 云台水平中位角对应正前方 PAN_MIN 30 # 舵机角度下限防止机械限位堵转 PAN_MAX 150 # 舵机角度上限 DEAD_BAND 5 # 像素死区小于这个误差不更新 MAX_DELTA 6 # 每帧最大角度增量防止猛甩 KP 0.25 # 比例系数根据实际调试调整 pan PAN_CENTER # 当前水平角度 tilt 90 # 当前俯仰角度 while True: img sensor.snapshot() tags img.find_apriltags() if tags: tag tags[0] # 计算目标相对画面中心的像素偏差 err_x tag.cx() - img.width() / 2 err_y tag.cy() - img.height() / 2 # 水平轴目标偏右云台向右转角度增大 if abs(err_x) DEAD_BAND: delta int(err_x * KP) delta max(-MAX_DELTA, min(MAX_DELTA, delta)) pan pan - delta pan max(PAN_MIN, min(PAN_MAX, pan)) # 俯仰轴同理 if abs(err_y) DEAD_BAND: delta int(err_y * KP) delta max(-MAX_DELTA, min(MAX_DELTA, delta)) tilt tilt - delta tilt max(30, min(150, tilt)) servo_pan.angle(pan) servo_tilt.angle(tilt)参数说明DEAD_BAND 是像素死区目标已经接近画面中心时误差只有两三个像素如果还继续更新角度舵机会高频微动并发烫设成 5 像素左右能明显改善。MAX_DELTA 是单次最大角度增量当目标突然出现在画面边缘误差可能上百像素如果不限幅舵机会一脚油门打死看起来像抽搐。KP 是比例系数决定云台响应速度一般从 0.1 到 0.3 之间起步响应太慢就加出现来回振荡就减。舵机角度范围限制在 30 到 150 度是为了避免机械限位堵转堵转时间长了会烧舵机电机这个保护必须有。3.3 用 PD 控制替代纯 P 控制消除云台“鬼畜抖动”只加比例控制的云台很容易出现来回穿越目标在中心附近时舵机每次修正角度都偏大结果云台在目标两侧来回小幅摆动看起来像“鬼畜”。这是因为纯 P 控制只对当前误差做反应没有预测误差变化趋势。加上微分项后误差变化越快输出抑制越强云台接近目标时会自动减速。这就是把纯 P 升级成 PDlast_err_x 0 last_err_y 0 kp_x 0.25 kd_x 0.6 while True: img sensor.snapshot() tag get_target(img) # 省略返回当前目标对象或None if tag: err_x tag.cx() - img.width() / 2 err_y tag.cy() - img.height() / 2 # 水平轴误差变化量 当前误差 - 上一帧误差 d_err_x err_x - last_err_x out_x int(kp_x * err_x kd_x * d_err_x) out_x max(-MAX_DELTA, min(MAX_DELTA, out_x)) pan pan - out_x pan max(PAN_MIN, min(PAN_MAX, pan)) # 俯仰轴同理 d_err_y err_y - last_err_y out_y int(kp_y * err_y kd_y * d_err_y) out_y max(-MAX_DELTA, min(MAX_DELTA, out_y)) tilt tilt - out_y tilt max(30, min(150, tilt)) last_err_x err_x last_err_y err_y调参时有个经验Kp 先从小往大调直到云台能跟上目标但不明显滞后然后 Kd 从零往上加观察目标是稳定落在画面中心还是来回穿越。Kd 太大会让云台动作僵硬一有风吹草动就急停太小又压不住振荡。如果目标静止时云台仍然小幅抖动优先检查死区是否太小再考虑给 d_err 加个一阶低通滤波比如取 d_err d_err * 0.8 last_d_err * 0.2这样能滤掉像素噪声带来的突变。PD 参数在不同舵机、不同供电电压下表现差异很大这不是代码玄学而是舵机本身的响应速度不同换舵机后重新调一遍属于预期内的事。4. 云台追踪避坑五个最容易翻车的现场4.1 舵机高频抖动机身发烫现象目标静止时舵机依然发出高频“咔咔”声连续工作几分钟后舵机外壳明显发热。原因主要有两个一是没有设置死区误差只有一两个像素时也在更新角度舵机不停微调二是供电不足USB 供电只能带动 OpenMV舵机启动瞬间电流大把电压拉低后工作不稳定。解决代码里加死区误差绝对值小于 5 像素就跳过更新舵机用独立的 5V 电源供电把 OpenMV 的地和舵机电源的地接到一起否则 PWM 信号没有共同参考点会出现随机抖动。这两个问题在初期项目里出现频率极高。4.2 画面帧率掉到一两帧云台像喝醉现象目标稍微移动画面卡顿明显云台反应迟钝控制动作一卡一卡。原因分辨率设成 VGA 甚至 SVGAfind_blobs 还在全图范围搜索主循环里又加了一堆 print 和图像绘制操作OpenMV 的 CPU 被掏空。解决帧率优先时把分辨率降到 QQVGA160x120ROI 参数限制搜索范围把 print 注释掉绘制图像只在调试和保存证据时保留。AprilTag 识别比 color blob 更耗时间如果识别距离允许优先用灰度图而不是 RGB565能省出不少处理时间。另外 sensor.skip_frames(30) 是在初始化后跳过前 30 帧让自动曝光稳定不要在每帧循环里频繁切换曝光模式那会拖慢帧率。4.3 多个同类目标来回跳变现象画面里有两个颜色相近的物体时云台一会儿追左边一会儿追右边看起来像在选择困难。原因很多示例代码直接取 blobs[0]第一帧可能选中左边的块第二帧右边的块面积更大又被选中导致目标在帧间不断切换。解决按面积排序后只选面积最大的块或者维护一个目标 ID连续多帧都是同一个目标才正式锁定丢失超过一定帧数才允许切换到新目标。用 AprilTag 时直接按 ID 锁定这个问题天然消失。处理多目标跳变是让云台表现得像“追踪”而不是“瞎转”的关键一步。4.4 AprilTag 距离稍远就识别不到现象标签在 1 米内识别正常2 米外就完全丢失或者标签在强光下反光时识别失败。原因分辨率太低导致标签在图像里成像过小AprilTag 解码器对最小尺寸有要求曝光时间过长导致边缘模糊白色光面标签反光让黑白边界对比度下降。解决分辨率从 QQVGA 提升到 QVGA手动关闭自动曝光并把曝光时间调低比如 set_auto_exposure(False) 后 set_exposure_microseconds(3000) 左右让标签边缘更锐利。打印标签时用哑光纸不要用光面铜版纸避免反光。物理标签尺寸也要随识别距离同步放大这属于开局就要算好的硬件参数别指望代码能弥补光学上的不足。4.5 目标丢失后云台一直往一个方向打死现象目标被手遮挡一下云台立刻往一个方向转到极限还会发出堵转的“吱吱”声目标重新出现后它也不回来。原因代码里没有丢失判断目标消失的帧里 tag 变量为空或者还在用上一次的误差继续累加误差一直存在角度就一直往一个方向加最终顶到限位。解决增加越界判断连续 N 帧找不到目标就停止角度更新保持当前角度再追踪不到就进入搜索模式让云台做小范围扫描。这个逻辑单独拿出来写了一个状态机放在第 6 章展开。目标是让云台在目标丢失时像个“有经验的守卫”而不是无头苍蝇。5. 把程序接到串口与上位机追踪数据可视化调试法5.1 设计一个稳定串口帧带校验的二进制坐标协议当你切换到视觉主控分离架构或者想在上位机实时观察追踪数据第一件事是定串口协议。很多人直接发文本字符串比如 “123,456\n”短时间调试没问题但文本解析慢负号、换行符一旦被截断就容易乱帧。我一般用定长二进制帧结构是“帧头 ID 水平偏差 俯仰偏差 帧尾”固定 8 字节解析端先找帧头再按格式解出数据。OpenMV 端发送代码import ustruct from pyb import UART # 串口3波特率115200约每字节87us8字节帧约0.7ms uart UART(3, 115200, timeout_char200) def send_target(tag, img): err_x int(tag.cx() - img.width() / 2) err_y int(tag.cy() - img.height() / 2) # 大端模式; B 无符号字节; H 无符号短整型; h 有符号短整型 frame ustruct.pack(BHhhB, 0xA5, tag.id(), err_x, err_y, 0x5A) uart.write(frame)参数说明帧头 0xA5、帧尾 0x5A 是固定魔数接收端靠它们找到帧边界。ID 用无符号短整型偏差值是带符号的短整型范围 -32768 到 32767对像素偏差来说足够用。大端模式的好处是单片机解析方便和常见通信协议保持一致。每次发送 8 字节在 115200 波特率下耗时不到 1 毫秒对追踪循环的影响可以忽略。如果现场电磁环境差可以在帧尾前再加一个 checksum 字节比如对前 6 字节做异或求和接收端校验不通过就丢弃这一帧我这里为了代码简洁没加量产项目里建议补上。5.2 主控端解析与舵机控制接口接收端如果是另一块 MicroPython 板子解析代码可以这样写import ustruct buffer b def parse_frame(buf): # 帧总长8字节帧头、ID、x偏差、y偏差、帧尾 if len(buf) 8: return None idx buf.find(b\xA5) if idx 0 or len(buf) - idx 8: return None head, tag_id, ex, ey, tail ustruct.unpack(BHhhB, buf[idx:idx8]) if tail ! 0x5A: return None return tag_id, ex, ey # 主循环中不断读取串口字节并尝试解析 while True: if uart.any(): buffer uart.read(uart.any()) frame parse_frame(buffer) if frame: tag_id, ex, ey frame # 这里调用舵机控制函数控制逻辑和第3章一致 update_servo_from_error(ex, ey) buffer buffer[idx8:] # 丢到已解析帧之后这里的常见坑是串口断帧。OpenMV 发送频率可能到每秒十几帧主控如果一次读一个字节再拼接效率低还可能漏读正确做法是先把缓冲区所有可读数据一次性读出来丢进 buffer 再查找帧头。解析成功后要把缓冲区裁剪掉已消费的字节否则 buffer 会越来越大。主控收到偏差后直接传给和第 3 章一样的 PID 更新函数这样视觉循环和控制循环解耦视觉卡一帧不影响舵机的平稳输出。调试时可以把 tag_id 打出来确认锁定的目标是不是预期的那一个。5.3 用 OpenMV IDE 自带的帧可视化验证收敛很多时候你调 PID 参数只看舵机动作很难判断是过度还是不足把追踪过程可视化是最直接的验证手段。OpenMV IDE 的帧缓冲区工具可以实时显示摄像头画面不需要外接屏幕你在主循环里把目标框、中心十字线、画面中线叠加画上去就能肉眼观察目标有没有被稳定压在画面中心while True: img sensor.snapshot() tags img.find_apriltags() if tags: tag tags[0] # 绘制目标外框、目标十字、画面中心参考线 img.draw_rectangle(tag.rect(), color(255, 0, 0)) img.draw_cross(tag.cx(), tag.cy(), color(255, 255, 0)) img.draw_line((img.width()//2, 0, img.width()//2, img.height()), color(0, 255, 0)) img.draw_line((0, img.height()//2, img.width(), img.height()//2), color(0, 255, 0))打开 IDE 的帧缓冲区窗口你就能看到两条绿色参考线把画面分成四象限黄色十字是目标位置。调 Kp 时观察黄色十字的轨迹如果它一直在绿色中线附近小范围打转说明死区不够或者 Kd 偏大如果它总是冲过中线又折返轨迹像正弦波说明 Kd 太小压不住过冲。这套可视化方法比盯着串口数字直观太多我调任何云台程序都会先保证画面里能看到追踪轨迹再决定动哪个参数。等你确认收敛了再把调试用的 draw 和 print 注释掉恢复最高帧率跑正式追踪。6. 目标丢失后的自我救治搜索模式与状态切换技巧我早期做第一版云台追踪时程序没有任何丢失处理演示时目标被手挡了一下云台立刻往一边猛转然后卡在机械限位那里嗡嗡响我只能断电重启。那次翻车之后我养成了一个习惯所有追踪程序都套一个简单的状态机至少区分追踪和搜索两个状态。状态切换的核心是 lost_count连续若干帧找不到目标才切换避免偶尔一两帧识别失败就误判丢失。STATE_TRACK 0 STATE_SEARCH 1 state STATE_TRACK lost_count 0 search_angle 30 search_dir 1 while True: img sensor.snapshot() tag get_target(img) # 自行实现返回目标对象或None if tag is not None: lost_count 0 state STATE_TRACK else: lost_count 1 if lost_count 5: state STATE_SEARCH if state STATE_TRACK: # 正常PD追踪代码同第3章 update_by_pd(tag, img) else: # 搜索模式水平慢速往返扫描每帧只转1.2度 search_angle search_dir * 1.2 if search_angle 150: search_dir -1 elif search_angle 30: search_dir 1 servo_pan.angle(search_angle) servo_tilt.angle(90) # 俯仰保持中位避免漏过上下方向的目标搜索角速度是这里最关键的参数每帧 1 度左右比较合适。云台反过来想目标在画面里出现的时间窗口有限转太快目标会像高速列车一样从画面里“滑”过去OpenMV 根本来不及识别转太慢则搜索周期太长目标重新出现在画面里也要等很久。lost_count 阈值要看你的实际帧率如果帧率 10fps5 帧意味着目标丢失 0.5 秒才切换搜索这个值能过滤掉目标短暂反光、遮挡造成的识别抖动又不会让云台在目标已经跑了之后还傻等。进阶一点还可以在搜索模式里降低 AprilTag 的识别阈值比如允许更小的标签尺寸代价是误检率上升根据场景取舍。这个状态机的价值在于让云台在目标丢失时保持“可恢复”而不是直接瘫痪。我现在做任何追踪类的项目都会先把搜索、追踪、丢失三个分支画出来再写具体的识别和控制代码。追踪算法本身固然重要但一个能在目标消失后自己找回来的系统才是真正能拿去演示和交付的。希望这些踩坑记录和调试习惯能帮到你少走我走过的弯路。本文还有配套的精品资源点击获取