MaixCam2+Yolo11实现60FPS实时小球检测的嵌入式竞赛方案-北京尧图网络

1. 赛题复盘与整体方案1.1 视觉竞赛 H 题中的小球检测究竟难在哪这次要复盘的项目是一套在视觉类竞赛 H 题中拿到省级一等奖、所有小问全部满分的方案使用 MaixCam2 边缘 AI 开发板配合 Yolo11 模型完成对小球目标的高速实时检测最终在设备端跑到了接近 60 FPS 的流畅帧率。很多队伍看到“小球检测”四个字第一反应是“目标检测很简单”但真正上手后才发现嵌入式 AI 比赛里的难点从来不在“能不能检测到”而在“检测得稳不稳、快不快、能不能在低算力设备上稳定输出”。从比赛实际过程看小球检测任务至少包含三个层面的挑战。第一小球属于小目标。一个球在画面中可能只占几十甚至十几个像素如果直接把采样分辨率设置成 640×640很容易出现漏检第二现场灯光、球体反光、运动模糊都会让检测置信度波动单独一个模型很难覆盖所有边界情况第三嵌入式设备算力有限MaixCam2 这类 AI 开发板不能像 PC 上的 GPU 那样随意跑大模型如果直接把 YOLOv8s 或更大模型部署上去帧率会掉到个位数根本无法满足比赛对实时性的要求。本次比赛最后的实现结果比较理想基于 MaixCam2 作为端侧主控使用 Yolo11n 作为基础检测模型配合输入分辨率压缩、模型量化、摄像头缓存队列、动态 ROI 预处理等手段最终设备端可以稳定运行在 50~60 FPS并且能够同时完成“球体是否出现”“球体坐标位置”“指定颜色小球识别与追踪”等多个子任务。比赛现场每个小问都能拿到满分关键在于技术方案不是盲目堆精度而是把每一帧的处理时间、每一轮检测的误判情况都做了量化控制。1.2 系统整体架构与技术链路整个项目从数据到部署可以拆成四条链路数据链路负责采集、抽帧、标注和增强训练链路负责在 PC 上完成 Yolo11 模型的训练与评估转换链路负责把训练好的 PyTorch 权重转换为边缘设备可以加载的模型格式部署链路负责在 MaixCam2 上实现摄像头采集、模型推理、小球坐标输出和串口/屏幕展示。层级主要工具/技术职责说明任务层球体检测、坐标回归、多球计数、目标追踪根据题目要求拆解功能点算法层Yolo11n、颜色阈值辅助、IoU 后处理输出目标框、类别和置信度部署层MaixCam2、摄像头、LCD/串口图像采集、模型推理、结果输出调优层输入分辨率、ROI 区域、帧缓冲队列控制端侧帧率与延迟从技术分工看Yolo11 负责“语义理解”也就是告诉系统画面里有哪些小球、什么类别、在什么位置MaixCam2 负责“物理世界接入”它接收摄像头画面运行模型再把结果以坐标或方框的形式输出。两条主线在比赛里互相配合前期绝大多数时间花在数据采集和模型训练上后期则集中在模型小型化和推理速度优化上。2. MaixCam2 与 Yolo11 选型思路2.1 MaixCam2 是一块怎样的边缘 AI 板子MaixCam2 是 Sipeed 系列中面向嵌入式 AI 视觉应用推出的开发板整体定位非常适合竞赛场景。它集成了摄像头、显示屏、音频、无线通信等模块开发者不需要自己外接一大堆传感器打开套件就能开始图像采集和模型部署。这类设备通常使用 RISC-V 架构或带 NPU 的 SoC能够在低功耗条件下做神经网络推理适合做现场演示类比赛题目。在画面采集上MaixCam2 自带摄像头支持不同分辨率的图像输入RGB 画面可以直接送给模型做预处理。比赛常见做法是让设备通过屏幕实时显示检测结果同时把小球坐标通过串口或网络发送给其他模块。由于题目要求“小球检测”必须足够快MaixCam2 的硬件算力无法与 PC 显卡相比所以模型不能选得太大这也是最终选择 Yolo11n 而不是 YOLOv8x 的原因。2.2 Yolo11 与 YOLOv8 的核心差异Yolo11 是 Ultralytics 在 YOLOv8 基础上更新的目标检测系列模型它在模型结构上做了明显的轻量化改造。很多人会问既然已经有 YOLOv8 了为什么还要换 Yolo11从实际比赛体验来看Yolo11 的使用方式和 YOLOv8 完全一致调用 API 几乎可以无缝迁移但网络结构发生了一些关键变化。首先是主干网络中使用了 C3K2 结构替代了部分 C2f 结构这样可以减少模块内部的分支数量降低计算量和参数量同时保留足够的梯度流动能力。其次是高层特征提取引入了 C2PSA 模块类似注意力机制可以在不显著增加推理耗时的情况下增强模型对全局信息的感知。除此之外Yolo11 仍然采用 Anchor-Free 检测头不依赖预设锚框后处理逻辑和 YOLOv8 兼容性很高这就让模型导出和部署阶段的工程量小了很多。Yolo11 系列给出了 n、s、m、l、x 等多个尺度版本其中 yolo11n 是最轻量的版本。对于 640×640 输入yolo11n 的模型体积只有几 MB量化后更适合直接放进端侧 NPU。对于小球检测这种目标语义非常简单的任务yolo11n 的表达能力已经足够盲目升级到 yolo11m 或 yolo11l 反而会因为推理时间过长导致整体方案失败。2.3 为什么这套组合能拿到满分很多队伍误以为“分数不够是因为模型不够好”但在嵌入式 AI 竞赛中决定最终成绩的往往是系统性工程能力。MaixCam2 负责处理图像采集和演示闭环Yolo11n 负责给出稳定的小球置信度两者叠加起来再配合帧缓冲技术与 ROI 巡检策略才真正解决了“实时检测”这个核心矛盾。从比赛结果看这套组合能够拿到所有小问满分并不是因为某一个模型的 mAP 特别高而是因为方案里每一步都被量化过每帧推理耗时是多少、漏检率是多少、丢失目标后能不能自动恢复检测、输出坐标是否经过滤波。这些点恰恰是评委和现场测试最关注的内容。3. 比赛环境准备与工程目录3.1 训练端环境本项目训练端使用 PC 完成操作系统为 Windows 10/11显卡使用支持 CUDA 的 NVIDIA GPU。如果你没有独立显卡Yolo11n 也可以使用 CPU 训练只是训练时间会比较长。环境版本上PyTorch 与 CUDA 需要匹配常见组合是 CUDA 12.4 搭配对应版本的 PyTorch如果显卡驱动版本较老则使用 CUDA 11.8 更稳妥。Yolo11 的训练依赖主要是 ultralytics 包安装方式如下pip install ultralytics安装完成后可以在 Python 中确认版本import ultralytics print(ultralytics.__version__)这里需要说明的是Yolo11 版本迭代比较快不同小版本的超参数和导出行为可能存在差异。比赛项目建议固定一个已经稳定运行的版本不要训练到一半随意升级包否则容易出现权重不兼容或导出失败的问题。3.2 设备端环境设备端使用的是 MaixCam2 出厂环境。具体到固件版本不同批次可能不太一样比赛开始前一定要确认相机、屏幕和模型加载接口都能正常使用。MaixCam2 支持通过 USB 连接 PC 进行文件传输也可以直接在其屏幕菜单中操作。模型文件的放置目录、命名规则需要参考官方出厂说明不能随便放一个文件夹就完事。3.3 工程目录规划一个好的工程目录可以避免比赛现场手忙脚乱。项目开始前就按照“数据、训练、部署”三个维度建立文件夹H-ball-detection/ ├── dataset/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── scripts/ │ ├── collect_frames.py │ ├── split_dataset.py │ └── test_fps.py ├── models/ │ ├── yolov11n_pretrain.pt │ └── best.pt └── deploy/ └── kmodel/images 目录存放训练图片labels 目录存放与图片同名的 txt 标签文件scripts 目录保存采集、训练、测试脚本models 目录统一管理训练出的权重deploy 目录存放转换后的端侧模型。这样组织后每次实验的输入输出都有固定位置多人协作时不容易把文件弄乱。4. 第 1 步构建高质量小球数据集4.1 现场环境视频抽帧竞赛场景下通常没有现成公开数据集可以下载最可靠的方式就是用现场摄像头自行采集。比赛现场的光线、背景、小球颜色与网上数据集差别很大如果直接使用 COCO 预训练权重跑小球检测经常出现漏检和误检。采集思路是改变小球位置、改变球的数量、改变光照强度、改变摄像头高度尽可能模拟比赛时的真实画面。采集时直接录一段视频后续用脚本按固定间隔抽帧可以大幅减少人工按快门的时间。下面是一个基于 OpenCV 的抽帧脚本关键参数是每帧间隔和输出尺寸。# 文件路径scripts/collect_frames.py import cv2 import os video_path ball_demo.mp4 output_dir dataset/raw_frames os.makedirs(output_dir, exist_okTrue) cap cv2.VideoCapture(video_path) fps cap.get(cv2.CAP_PROP_FPS) frame_interval int(fps // 5) # 每秒保留约 5 帧 count 0 saved 0 while True: ret, frame cap.read() if not ret: break if count % frame_interval 0: # 适当压缩分辨率避免标注超大图 frame_resized cv2.resize(frame, (640, 480)) cv2.imwrite(os.path.join(output_dir, fframe_{saved:04d}.jpg), frame_resized) saved 1 count 1 cap.release() print(ftotal saved: {saved})抽帧时需要注意不要把视频里所有相似画面全部保存否则数据集会存在大量重复。比赛现场如果小球只是缓慢移动连续两帧之间的差异非常小按固定间隔抽 1 秒 2~5 帧即可如果小球运动很快则要适当提高抽帧频率保证数据集中包含运动模糊样本。对于这类目标非常单一的项目500~1000 张训练图片往往就已经够用。比起数量更重要的是覆盖“困难场景”小球贴边、小球重叠、小球被手部分遮挡、小球运动过快导致拖影。这些场景直接影响比赛现场漏检数据集里必须有意识地补充。4.2 使用 YOLO 格式标注Yolo11 训练使用的标签格式是 YOLO txt 格式。每一张图片对应一个同名的 txt 文件文件里每一行代表一个目标类别id 中心点x 中心点y 目标宽度目标高度其中坐标值都是基于图片宽度和高度的归一化比例取值范围在 0 到 1 之间。例如一张 640×480 图片中有一个小球中心点落在像素坐标 (320, 240)目标宽高约为 40×40则标签行为0 0.50 0.50 0.0625 0.0833标签的时候我建议用 LabelImg 或 X-AnyLabeling 这类图形化标注工具标注结果直接导出 YOLO 格式。对于“小球”这种圆形目标框不要打得过大尽量紧贴小球边缘如果图片中有多个小球且需要区分颜色可以在标注时建立多个类别例如 0 代表红球、1 代表蓝球、2 代表绿球。检测类别越少模型训练难度越低但如果赛题要求区分颜色就必须在数据集中体现颜色差异而不是靠后期颜色阈值处理硬拆。4.3 数据划分与训练集分布图片全部标注完成后还需要把数据划分成训练集和验证集。划分时注意避免同一个连续视频片段产生的相似图片全部进入测试集否则验证结果会虚高模型到了比赛现场却表现一般。# 文件路径scripts/split_dataset.py import os import random import shutil random.seed(42) image_dir dataset/images train_ratio 0.9 all_images [f for f in os.listdir(image_dir) if f.endswith(.jpg)] random.shuffle(all_images) train_count int(len(all_images) * train_ratio) train_images all_images[:train_count] val_images all_images[train_count:] for split, imgs in [(train, train_images), (val, val_images)]: os.makedirs(fdataset/images/{split}, exist_okTrue) os.makedirs(fdataset/labels/{split}, exist_okTrue) for img_name in imgs: src_img os.path.join(image_dir, img_name) src_label os.path.join(dataset/labels, img_name.replace(.jpg, .txt)) dst_img os.path.join(fdataset/images/{split}, img_name) dst_label os.path.join(fdataset/labels/{split}, img_name.replace(.jpg, .txt)) shutil.copy(src_img, dst_img) if os.path.exists(src_label): shutil.copy(src_label, dst_label) print(ftrain: {len(train_images)}, val: {len(val_images)})在比赛实践中我建议至少留出 10% 的数据作为验证集同时额外录制一小段现场视频专门用来检查模型的泛化能力。训练集和验证集的分布不要完全一致例如验证集里要包含一些训练时没出现的背景这样才能暴露真实环境里的误检问题。5. 第 2 步训练 Yolo11 模型5.1 编写 data.yaml使用 ultralytics 训练时第一步要准备一个 YAML 配置文件描述数据路径和类别名称。路径建议尽量使用相对路径避免换电脑后无法训练。# 文件路径dataset/ball.yaml path: ../dataset train: images/train val: images/val names: 0: red_ball 1: blue_ball 2: green_ball这里 path 写的是相对于当前工作目录的路径实际训练命令一般在项目根目录运行。如果你的 label 类别只有“小球”一个类别names 就只写一行 0 0: ball。在比赛里我倾向于把颜色类别直接交给 Yolo11 识别而不是全部切成二分类再靠颜色判断因为不同颜色球在不同光照下颜色变化很大交给模型学习特征往往更稳定。5.2 编写训练脚本训练阶段我通常使用 yolo11n.pt 作为预训练权重在此基础上做迁移学习。对于小球检测这种目标语义不复杂的任务从头训练也可以但预训练权重可以让收敛明显加快早期验证分数也会更高。# 文件路径scripts/train.py from ultralytics import YOLO # 加载官方预训练权重 model YOLO(yolo11n.pt) # 开始训练 model.train( datadataset/ball.yaml, epochs100, imgsz320, # 训练输入分辨率 batch16, device0, # 使用 GPU patience20, # 早停 projectruns/detect, nameball_yolo11n, verboseTrue )训练输入分辨率这里设置了 320×320而不是更常见的 640×640。原因在于部署端最终跑的是 320 分辨率训练端用相同分辨率可以有效避免尺度迁移带来的精度损失。如果你的球场画面较大、小球像素很少可以先在 640 分辨率上训练然后在端侧用 320 分辨率做测试权衡准确率与帧率。训练过程中程序会输出 mAP50、mAP50-95、precision、recall 等指标。球类目标通常收敛很快几十轮后 mAP50 就能达到 95% 以上。如果发现验证集 loss 下降缓慢或指标不稳定应该优先检查数据标注是否错误、类别是否平衡、训练与验证图片分布是否差异过大而不是急着调学习率。5.3 验证与导出权重训练结束后best.pt 通常保存在 runs/detect/ball_yolo11n/weights/best.pt。下一步可以使用验证集对模型做快速评估yolo val modelruns/detect/ball_yolo11n/weights/best.pt datadataset/ball.yaml imgsz320确认指标没问题后再导出为 ONNX 格式作为后续转端侧模型的中间文件。导出时指定 opset 版本如果导出过程报算子不兼容可以尝试降低 opset。yolo export modelruns/detect/ball_yolo11n/weights/best.pt formatonnx imgsz320 opset12导出得到的 best.onnx 已经脱离 PyTorch 环境很多边缘平台都支持 ONNX 导入。在后续开发中保留好 best.pt、best.onnx 和转换后的端侧模型三个版本方便随时回溯定位问题。6. 第 3 步让检测流程跑到 60 帧6.1 帧率瓶颈到底在哪在 MaixCam2 这类嵌入式设备上目标检测的帧率并不完全等于模型推理时间。一个完整的检测循环包括摄像头采集、图像缩放、颜色空间转换、神经网络推理、后处理和画面显示。很多队伍实测模型推理只有 20ms但整体帧率却只有 20 FPS原因是采集和显示阻塞了推理线程。因此60 帧优化不能只盯着模型。必须从“总延迟”的角度分析每一帧经历了什么。举例来说如果摄像头采集一帧需要 10ms模型推理 640×640 需要 40ms画面显示又需要 15ms那么无论模型多快整体循环都会超过 65ms。要跑到 60 FPS意味着每帧平均处理时间必须控制在 16~17ms 以内这就要求模型推理时间至少低于 10ms同时把采集、显示与推理分离到不同线程中。6.2 降低分辨率与模型轻量化处理 320×320 输入时计算量只有 640×640 的约四分之一。小球检测任务不需要太高分辨率背景信息模型只要能看清小球轮廓即可。实际测试中Yolo11n 在 320×320 输入下推理耗时通常远低于 640×640而且精度下降往往不明显。如果画面中小球很小可以改用 352×352 或 384×384这些尺寸更适合端侧 NPU 并行计算。另一个常用手段是模型量化。训练得到的权重是 FP32 精度推理时转换为 INT8 或 INT16可以大幅减少计算量和内存占用。量化后模型的精度会有轻微损失但小球这类低语义复杂度目标往往仍然能够保持 90% 以上的检测性能。量化需要对验证集做校准避免极端情况下出现大面积漏检。6.3 帧缓冲队列与摄像头缓存策略模型推理速度足够快之后下一个瓶颈往往来自摄像头驱动。实时视频流永远不会等人如果上一帧还没推理完摄像头缓冲区就堆积了很多帧系统会越来越卡。常见解法是在采集线程里不断把最新帧放入一个固定长度的队列推理线程每次只取队列中最新的一帧如果队列中已经有积压则直接丢弃旧帧。这种策略可以保证系统始终处理的是“最新画面”也避免延迟越来越大。# 文件路径scripts/frame_queue_demo.py # 该示例演示“只处理最新帧”的缓冲思路 import cv2 import queue import threading frame_queue queue.Queue(maxsize2) def capture_thread(cap): while True: ret, frame cap.read() if not ret: break if frame_queue.full(): try: frame_queue.get_nowait() except queue.Empty: pass frame_queue.put(frame) def inference_thread(model): while True: try: frame frame_queue.get(timeout0.1) except queue.Empty: continue results model.predict(frame, imgsz320, verboseFalse) # 绘制并显示这种方式在比赛中需要注意一个细节如果只处理最新帧那么 CPU 主控同步读取检测结果时有可能连续读到同一个目标的重复结果。因此输出小球坐标前建议增加一个简单的时间戳去重或者记录上一帧检测的时间戳。6.4 动态 ROI 巡检策略当画面中只有一个小球、而且小球大概率出现在某个区域时全图检测是浪费算力的。比赛中一个很实用的策略是“粗检测 ROI 细检测”。先以较低分辨率做一次全图预测粗略找到小球位置找到后下一帧直接裁剪小球周围的局部区域送给模型做精确检测。这样做既可以降低算力需求也能减少背景误检。以 320×320 全图检测为例如果上一帧小球在中心位置下一帧就可以只检测中心附近 160×160 的区域目标突然丢失时再回到全图检测。这个策略相当于用时间连续性换取帧率非常适合小球运动轨迹相对平滑的赛题。实现时要注意如果小球速度极快ROI 区域太小可能导致目标直接跑出区域外因此 ROI 边长需要根据小球最大运动速度设定。6.5 使用 FPS 脚本自测优化效果跑在 MaixCam2 端侧之前可以在 PC 上先排查模型推理层面的帧率问题。下面脚本用于测试不同输入尺寸下的推理耗时帮助确定端侧模型的分辨率档位。# 文件路径scripts/test_fps.py import time import cv2 from ultralytics import YOLO model YOLO(runs/detect/ball_yolo11n/weights/best.pt) cap cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) imgsz 320 total_time 0 frame_count 100 for i in range(frame_count): ret, frame cap.read() if not ret: continue start time.time() results model.predict(frame, imgszimgsz, device0, verboseFalse) end time.time() total_time end - start if i % 10 0: annotated results[0].plot() cv2.imshow(demo, annotated) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows() fps frame_count / total_time print(faverage fps: {fps:.2f})需要说明的是PC 端 FPS 不能代表 MaixCam2 端侧真实表现但它能直观反映输入分辨率对推理速度的影响。比赛调试时我会先固定一个理想帧率目标然后测试 256、320、384 三档分辨率记录每一档的检测置信度与耗时最后选一个性价比最高的档位迁移到设备端。7. 第 4 步部署到 MaixCam27.1 模型转换的通用流程不同版本的 MaixCam2 官方工具链可能存在差异通常流程是训练好的 best.pt 先导出为 ONNX再通过官方模型转换工具转换成端侧可加载的模型格式。转换过程中要重点关注几个方面算子的兼容性、输入输出的命名与形状、量化方式。一般来说Yolo11 模型导出 ONNX 时可以选择带 NMS 或不带 NMS。端侧设备如果自带后处理接口建议导出不带 NMS 的原始输出把解码和 NMS 放到设备端完成如果端侧 SDK 只支持完整检测结果就要在导出时内置 NMS。具体选择取决于 MaixCam2 出厂推理框架无法一概而论。比赛前最好先做一个最小模型转换测试确认链路通了再训练完整模型。7.2 端侧部署的核心逻辑由于不同固件接口差异较大这里不直接写死某个 SDK 的函数而是给出部署端最常见的三段式框架初始化模型、读取画面、前处理推理后处理。伪代码如下# 文件路径deploy/main.py # 这是端侧部署伪代码请根据 MaixCam2 官方 API 做适配 import time import cv2 import numpy as np # step1: 初始化模型与摄像头 model load_model(ball_yolo11n.kmodel) camera Camera(width640, height480) # 记录上一帧目标位置用于 ROI 巡检 last_box None while True: frame camera.capture() if last_box is not None: # 在上次目标周围扩大裁剪 x1 max(0, last_box[0] - 50) y1 max(0, last_box[1] - 50) x2 min(frame.shape[1], last_box[2] 50) y2 min(frame.shape[0], last_box[3] 50) roi frame[y1:y2, x1:x2] input_img preprocess(roi, size(320, 320)) boxes model.detect(input_img, conf_thresh0.5) # 将裁剪区域坐标映射回原图 else: # 未找到目标时全图检测 input_img preprocess(frame, size(320, 320)) boxes model.detect(input_img, conf_thresh0.5) last_box choose_main_box(boxes) draw_boxes(frame, boxes) screen.show(frame) fps calc_fps(time.time()) print(fps:, fps)部署代码中最容易出问题的点是坐标映射。当使用 ROI 裁剪后模型输出的坐标是裁剪图上的坐标必须加上裁剪区域的偏移量才能映射回原图。如果比赛时发现检测框位置偏了优先检查这一步坐标映射是否正确。7.3 端侧性能检查清单迁移到 MaixCam2 后建议逐项检查以下内容第一摄像头采集分辨率是否过高。如果只需要 640×480就不要把采集分辨率设为 1920×1080否则 ISP 缩放和内存拷贝都会吃掉大量时间。第二模型输入尺寸是否与训练一致。虽然模型可以接受动态输入但尽量固定成一个尺寸以便 NPU 优化推理计算图。第三后处理是否过于复杂。Yolo11 的 NMS 在端侧 CPU 上运行如果检测目标数量很少可以手动简化 NMS 逻辑例如当画面中只有一个目标时直接取最高置信度框不再做交并比抑制。第四显示刷新是否阻塞推理。屏幕绘制往往比较耗时可以将绘制结果放到单独线程推理线程只负责输出坐标避免你看到画面帧率很高实际控制延迟却偏大的情况。8. 赛题各小问满分实现思路8.1 把“小球检测”拆成可评分子问题H 题通常不会只要求“实时显示检测框”而是由多个小问组成例如判断画面中有没有小球输出小球中心像素坐标区分指定颜色的小球数量在小球移动时稳定跟踪特定条件下执行声光或串口输出。拿到题目后不要直接开始训练模型而是把所有可验证的输出点列出来。每一个小问对应一个可控的测试流程。例如第一问是“画面中无球/有球判断”那么就要保证模型在阈值上足够灵敏宁可把背景误检控制得低一些也不能让有球画面漏判第二问是“输出坐标”那么坐标不仅要准还要考虑画面尺寸与原图坐标的映射关系第三问是“指定小球”就需要类别标签准确区分颜色同时避免颜色相近误判。8.2 检测准确率如何做到不丢分“检测准确率满分”最怕两类错误有球不报、无球乱报。为了避免有球不报我采用的思路是把最终决策阈值放宽到 0.25~0.3再通过面积过滤和位置连续性判定把误检过滤掉。因为现场画面中真正的球通常会有较小且稳定的目标面积而误检框往往是零散噪声很难连续多帧维持稳定。同时还要注意模型的训练数据里不能只包含“理想画面”。如果小球滚到桌子边缘出现半个球被遮挡的情况模型很可能把它当成背景。比赛前要专门录制遮挡、弱光、强反光样本加入训练集后现场容错能力会明显提升。8.3 坐标输出精度做到满分的关键很多队伍输出坐标时只是简单把检测框中心作为小球中心。如果画面里小球比较小这种近似没有问题但如果小球靠近画面边缘或者图像存在镜头畸变中心点可能与真实球心存在数个像素偏差。为了让坐标输出稳定可以采用检测框中心、颜色质心、多帧滤波三者结合的方法。# 使用检测框中心附近区域再计算颜色质心 def refine_center(frame, cx, cy, radius10): roi frame[cy - radius:cy radius, cx - radius:cx radius] hsv cv2.cvtColor(roi, cv2.COLOR_BGR2HSV) # 以红球为例红色在 HSV 中通常分布在两个区间 mask1 cv2.inRange(hsv, (0, 100, 100), (10, 255, 255)) mask2 cv2.inRange(hsv, (156, 100, 100), (180, 255, 255)) mask cv2.bitwise_or(mask1, mask2) moments cv2.moments(mask) if moments[m00] 100: refined_x int(moments[m10] / moments[m00]) cx - radius refined_y int(moments[m01] / moments[m00]) cy - radius return refined_x, refined_y return cx, cy这种方法本质上是把 Yolo11 的定位结果当作一个粗定位再用颜色特征在局部小范围内做精修。对圆形、颜色单一的小球特别有效坐标输出可以稳定在亚像素级别。需要注意的是如果球本身颜色变化很大或球体表面带复杂图案这种精修方式可能失效必须先在验证集上测试。8.4 实时跟踪与异常恢复小球移动速度较快时如果每一帧都全图检测延迟会明显增加。可以采用“检测跟踪”两条腿走路Yolo11 负责每秒若干帧的确认其余帧利用小球运动连续性预测位置。跟踪算法不一定需要引入 ByteTrack 这类复杂模块简单的卡尔曼滤波或位置平滑就可以满足比赛要求。还要考虑目标丢失后的恢复策略。一旦连续 n 帧没有检测到小球立即把跟踪状态清空下一次回到全图检测模式。现场出现短暂遮挡、快速漂移时系统能自动恢复这比单模型硬扛更可靠。9. 高频坑点与排查思路9.1 常见问题汇总表比赛过程中最容易踩到的问题我整理成了一张表。遇到报错时先对照现象再按优先级排查能省下大量时间。问题现象常见原因解决思路训练时提示 CUDA out of memorybatch size 太大或分辨率太高降低 batch或使用 imgsz320训练指标很高但端侧严重漏检训练分辨率与推理分辨率不一致统一两端输入尺寸模型导出 ONNX 报算子不支持ultralytics 或 PyTorch 版本过旧/过新固定版本尝试降低 opset端侧推理线程卡死摄像头缓冲队列积压旧帧改成只读取最新帧策略检测框偏移实际小球使用 ROI 后没有加坐标偏移统一坐标映射函数并单独测试现场演示时画面卡顿显示绘制与推理在同一线程将绘制放入独立线程推理只输出状态量化后漏检明显增加校准集数量不足或分布偏差增加验证集图片使用典型场景完成量化校准标签类别与模型输出不对应data.yaml 中 names 顺序混乱训练前检查 labels 与 names 一一对应9.2 一个典型的部署崩溃案例有一轮比赛测试中系统在小球静止时表现正常小球快速运动时画面会突然卡住几秒后又恢复。排查后发现不是模型推理变慢而是快速运动时摄像头画面变化过快主循环里不断入队积压了上百帧图像内存占用持续增加最终系统触发保护机制。解决方案并不复杂把队列长度限制为 2当队列满时先丢弃最旧的一帧再入队。这样推理线程永远只处理最新画面。修改后系统连续运行半小时也没有出现卡顿。这个案例说明嵌入式端实时视觉系统里数据流设计往往比模型精度更影响用户体验。9.3 如何避免“训练环境没问题现场环境翻车”比赛现场的光线、桌面色、小球颜色可能与训练环境存在明显差异。最稳妥的办法是提前携带一块与比赛相近的背景布在现场录制数据并做最后一轮微调。如果现场无法提前接触则训练集里要刻意加入亮度扰动、色偏扰动、模糊扰动。Yolo11 自带的增强参数虽然有用但不如直接在数据集中加入真实背景扰动有效。10. 竞赛工程化建议与后续优化方向10.1 先跑通最小闭环再谈精度优化比赛第一天最容易犯的错误是花大量时间纠结模型选型结果连摄像头画面都还没能成功显示。嵌入式 AI 竞赛的正确节奏是先让系统在一小时内跑通“摄像头拍摄 - 模型加载 - 框出小球 - 屏幕显示”的最小闭环。哪怕这个模型还是官方预训练权重、不能识别你的球也可以验证 SDK 调用、画面显示、文件传输这些基础链路。只有最小闭环跑通后续替换数据和模型才有稳定的测试平台。10.2 每个小问都要做回归版本在算法项目里“优化 A 导致 B 变差”是非常常见的事。比赛期间每个小问实现后都要导出一份固定版本权重和一份对应部署代码记录测试帧率、漏检率、最大延迟。不要把所有版本的权重都命名为 best.pt否则最后根本分不清哪份权重对应的哪套策略。我的建议是每次提交前都要在本地跑一遍完整的回归脚本确认之前满分的功能没有被新功能破坏。10.3 软硬件结合把劣势变成优势很多队伍认为 MaixCam2 算力低所以不敢选择 Yolo11宁愿用传统图像处理。但实际上传统颜色阈值方案在光照变化大时非常不稳定几乎没有泛化能力。Yolo11 虽然模型需要额外训练但一旦收敛对新场景的适应能力远超手工特征。真正聪明的做法是利用 MaixCam2 的 NPU 跑轻量 Yolo11n再结合颜色、运动信息做后处理做到帧率高、误检少、鲁棒性好。更进一步可以在小球检测基础上扩展到多目标计数、轨迹预测、异常状态判断等方向。比如利用检测出的中心坐标序列预测小球下一步落点或者统计单位时间内小球穿过指定区域的次数。这些扩展并不需要更换模型只需要在部署端增加相应逻辑却能让方案在答辩和评分时体现出更高的完成度。如果你也在准备类似使用 MaixCam2 或 Yolo11 的视觉竞赛项目希望这篇复盘能帮你少走一些弯路。比赛最忌临场发挥所有模块都提前压测过、所有边界情况都提前验证过现场才不会手忙脚乱。欢迎在评论区交流你的赛题方案和踩坑经历。

MaixCam2+Yolo11实现60FPS实时小球检测的嵌入式竞赛方案

相关推荐

Gopeed BT 下载路径配置手册：3 步修正保存位置

Ice 菜单栏管理指南：3 种方式隐藏图标，拖拽排序一步到位

睡前助眠拉伸的关键不是拉筋，而是让身体安静下来

更多资讯

AI生成代码仅需几秒，为何验证要半个月？嵌入式安全开发全解析

AI智能体开发框架核心技术解析与实践指南

AI智能体开发框架解析与应用实践

Linux kernel日志解析：定位底层故障的核心技术

Linux kernel日志原理与实战：从dmesg到故障根因分析

架构图之外：常见软件架构模式的依赖约束与选型

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？