做体育视频分析这些年，羽毛球可能是最让我头疼的检测对象之一。场上的运动员还算好认，真正麻烦的是那个时速轻松突破三百公里的羽毛球——在画面里往往只有十几个像素，一眨眼就飞出视野。找来找去，公开的目标检测数据集大多集中在行人、车辆、日常物品这些方向上，专门做好「运动员、裁判、羽毛球」三分类标注的羽毛球场景数据集少之又少。与其等别人开源，不如自己动手整理了一套：最终沉淀了2879张真实比赛画面，提供YOLO txt、COCO json、VOC xml三种标注格式，基于YOLOv8训练后在验证集上的mAP@0.5达到了84.4%。这篇文章会把数据集的构成、标注规范、格式转换方法、完整训练代码和踩坑记录都整理出来，给正在做体育视频分析、比赛集锦自动剪辑、球员动作识别的小伙伴一个可以直接参考的起点。
1. 为什么要做一套羽毛球目标检测数据集
1.1 羽毛球场景的检测难点在哪里
这套数据集的核心任务不是简单的“识别人”，而是要在同一张画面里同时定位三类目标：运动员、裁判、羽毛球。听起来不复杂，但真正把标注和训练做完就会发现，羽毛球场景几乎是目标检测里小目标、运动模糊、类别不均衡三类难题的集合体。
先说目标尺度。一张1080P的转播画面里，运动员的身体区域可能有几百乘几百像素，属于典型的“大目标”；而羽毛球在空中飞行时，直径往往只有二十个像素上下，有时甚至小于十个像素。YOLO系列模型在骨干网络下采样时，特征图分辨率会不断降低，小目标的特征很容易在多层卷积之后被“稀释”，导致漏检。这不是换一个预训练权重就能解决的，必须从数据集标注和训练策略两个层面一起下手。
再说运动模糊。羽毛球在击球瞬间的初速度可以超过三百公里每小时，常规帧率下的抓拍图像里，球体经常带着明显的拖影，边缘是模糊的。如果标注人员没有统一标准，同一个模糊球有的框、有的不框，模型学到的语义就会出现冲突。最后是类别不均衡。运动员几乎每一帧都在画面里，裁判通常坐在地边不动，而羽毛球是“时有时无”的：开场、局间休息、回放片段里根本没有球。这三类标注数量差很多，直接训练的话损失函数容易被大类别带偏。
1.2 数据集构成与标注规范
整套数据集一共2879张JPEG图像，素材来自公开赛事转播录像和自录制训练视频的抽帧，覆盖了室内不同灯光条件、不同机位高度、不同场地颜色组合。抽帧时做了去重处理，避免连续帧图像高度相似导致验证集评估虚高。按8:1:1的比例划分，训练集2303张、验证集288张、测试集288张。
标注类别统一为三个：player（运动员）、referee（裁判）、shuttlecock（羽毛球）。每个目标都标注外接矩形框，全部为水平框，不包含旋转框和分割掩码。这个决定在标注阶段就要想清楚：虽然旋转框对羽毛球这种细长目标可能更贴合，但后期如果想切换模型、部署到不同推理框架，水平框的兼容性最好，YOLO系、COCO和VOC生态都能直接吃下。
标注规则上，我踩过一轮坑后固定了三条标准，整理成文档发给所有参与标注的人：
- 运动员：画面中可见躯干或完整四肢的运动员，统一框到最紧的矩形外轮廓；被遮挡超过60%的运动员不标。
- 裁判：只要裁判出现在画面中且身体躯干可见，就标注；背对镜头、只露后脑勺的也标。
- 羽毛球：这个最关键。球体在画面中占据至少5x5像素且能被人眼辨认出“它是一个球”时才标注；完全糊成一片、人眼都分不清的拖影不标。这样做是为了让模型去学清晰球体的特征，而不是被噪声干扰。
类别统计上，三类目标加起来约11777个标注框，其中player约5178个、referee约2647个、shuttlecock约3952个。虽然还是不平衡，但小球的数量高于裁判这一点，让我在后续训练中有了调整损失权重的余地。图像原始分辨率以1920x1080为主，少量来自手机竖屏拍摄的素材为1080x1920，训练前统一由ultralytics框架做letterbox缩放，由于宽高比差异不大，形变问题基本可以忽略。
2. 三种标注格式到底怎么选
2.1 YOLO txt 与 VOC xml、COCO json 的差别
数据集交付时我同时导出了三种格式，因为不同工具链只认不同的格式：YOLO训练直接用txt标签，数据可视化对比喜欢用COCO json，老项目里经常用VOC xml。很多人拿到数据集后第一步不是训练，而是在这三种格式之间反复横跳，所以我直接把格式差异讲透。
YOLO格式是最简洁的。每个txt文件对应一张图片，文件名与图片名保持一致。每一行代表一个目标，格式为：类别id、归一化中心点x坐标、归一化中心点y坐标、归一化宽度w、归一化高度h。坐标全部除以图像宽高压缩到0到1区间。比如一张1920x1080的图像里，一个羽毛球框的中心点在(960, 540)，宽高为40x30像素，那对应的一行就是：2 0.5 0.5 0.020833 0.027778。
COCO json则是把所有图像信息和标注信息汇总到一个文件里。文件顶层结构包含images、annotations、categories三个核心数组。images里记录每张图片的id、file_name、width、height；annotations里记录每个标注框的id、image_id、category_id、bbox、area、iscrowd等字段；categories里维护类别id与名称的映射。注意COCO的bbox是[x, y, width, height]格式，x和y是框左上角的像素坐标，不是中心点。
VOC xml则是一张图片对应一个xml文件，以根节点annotation包裹filename、size、object等子节点。每个object包含name、pose、truncated、difficult、bndbox，其中bndbox里依次是xmin、ymin、xmax、ymax四个像素坐标值。这种格式最直观，人可以直接读，但文件数量多，管理起来比单文件的方式繁琐。
三种格式的核心差异在表格里：
| 格式 | 存储方式 | 坐标类型 | 类别映射 | 适用阶段 |
|---|---|---|---|---|
| YOLO txt | 每图一个txt | 归一化中心点+宽高 | 类别id从0递增 | ultralytics训练 |
| COCO json | 全量单文件 | 像素左上角+宽高 | categories数组映射 | 模型评估、可视化 |
| VOC xml | 每图一个xml | 像素左上角+右下角 | object的name字符串 | 老工具链兼容 |
2.2 格式转换脚本：YOLO 转 COCO
推荐的做法是：标注阶段只维护一种“源格式”，用脚本往其他格式转，而不是手动维护多份标注。我习惯把YOLO txt作为源格式，因为它的维度最少、最不容易写错。下面这个脚本可以把YOLO txt批量转成COCO json，我每次做数据集交付都会用，换成自己的类名和图片目录就能跑。
import os import json from PIL import Image from glob import glob # 配置 img_dir = "images/train" # 图片目录 label_dir = "labels/train" # yolo txt目录 output_json = "train_coco.json" categories = ["player", "referee", "shuttlecock"] # 顺序必须和yolo训练时一致 # 建立category id映射 cat_id_map = {name: i for i, name in enumerate(categories)} category_info = [ {"id": i, "name": name, "supercategory": "sport"} for i, name in enumerate(categories) ] images = [] annotations = [] annotation_id = 1 for img_path in sorted(glob(os.path.join(img_dir, "*.jpg"))): img_name = os.path.basename(img_path) img_id = len(images) with Image.open(img_path) as img: width, height = img.size images.append({ "id": img_id, "file_name": img_name, "width": width, "height": height, }) label_path = os.path.join(label_dir, os.path.splitext(img_name)[0] + ".txt") if not os.path.exists(label_path): continue with open(label_path, "r") as f: lines = f.readlines() for line in lines: parts = line.strip().split() if len(parts) != 5: continue cat_id, cx_norm, cy_norm, w_norm, h_norm = map(float, parts) cx = cx_norm * width cy = cy_norm * height w = w_norm * width h = h_norm * height x = cx - w / 2 y = cy - h / 2 # 过滤越界坐标，防止后续训练报错 if w <= 0 or h <= 0: continue if x < 0: x = 0 if y < 0: y = 0 annotations.append({ "id": annotation_id, "image_id": img_id, "category_id": int(cat_id), "bbox": [round(x, 2), round(y, 2), round(w, 2), round(h, 2)], "area": round(w * h, 2), "iscrowd": 0, }) annotation_id += 1 coco_data = { "images": images, "annotations": annotations, "categories": category_info, } with open(output_json, "w") as f: json.dump(coco_data, f, ensure_ascii=False) print(f"转换完成：{len(images)} 张图，{len(annotations)} 个标注框")这个脚本里有两处细节容易被忽略。一是COCO的bbox需要的是左上角坐标，从YOLO的中心点格式换算时必须做减法；二是过滤越界坐标，训练yolo时如果某个标注框超出图像边界，有时不会报错但会影响损失计算，白纸黑字给它纠正过来最稳。
2.3 标注工具与标签命名统一
标注阶段我用的是X-AnyLabeling，直接导出YOLO格式。选它主要是看中了两个能力：支持视频抽帧后的批量辅助标注，可以基于上一帧的框自动跟踪目标，羽毛球这种连续多帧运动的小目标不用一帧帧去手点；导出格式本来就是YOLO txt，省掉一次转换。LabelImg虽然轻量，但它的交互对几百张图的小球标注来说效率偏低，后期还要手动转格式，不太推荐用来做这个量级的数据。
标签命名上提前统一很重要。有的工具默认给类别加下标，比如player_0、player_1，如果没在工具里改干净，训练时data.yaml里的names就和txt里的id对不上，模型会训练出一个“看起来正常、实际上类别完全错乱”的结果。我踩过这个坑，当时验证集loss一直正常下降，但推理预测时球员和裁判张冠李戴，最后排查了半天发现是旧标注里referee的id写成了2、新标注里写成了1。解决方法是把所有txt逐个读取，统计每个文件里的最大类别id，再和data.yaml的names做一次交叉校验，这一步我给到第四部分的具体排查代码里。
3. 从零开始训练自己的检测模型
3.1 环境安装与数据集目录组织
训练部分我直接用ultralytics框架。它集成了YOLOv8、YOLO11等模型，训练、验证、导出的命令高度统一，适合把精力放在数据和调参而不是工程框架搭建上。建议在Python 3.9以上版本安装：
pip install ultralytics pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118装完后可以用命令行验证是否正常：
yolo predict model=yolov8s.pt source=https://ultralytics.com/images/bus.jpg能正常输出结果就说明环境通了。显卡方面，NVIDIA显卡直接支持CUDA加速，训练效率会高很多；如果只有CPU环境，建议把下面训练脚本里的batch调小到4，图像尺寸调回640，训练时间会拉长但流程不变。至于AMD显卡跑YOLO，这几年ROCm方案也逐步可用，但为了少折腾，我建议新手先用CPU或NVIDIA环境跑通流程，再去优化硬件加速。
数据集目录按YOLO惯例组织：
shuttle_badminton/ ├── data.yaml ├── images/ │ ├── train/ │ ├── val/ │ └── test/ └── labels/ ├── train/ ├── val/ └── test/data.yaml是训练的入口配置文件，内容如下：
# shuttle_badminton/data.yaml path: ../shuttle_badminton # 数据集根目录，建议用绝对路径 train: images/train val: images/val test: images/test nc: 3 names: 0: player 1: referee 2: shuttlecock这里最容易出问题的就是path路径。如果用的是Jupyter Notebook或Windows环境，相对路径解析和不同的平台规则完全不一样，我吃过太多次亏，最后的经验是直接写绝对路径，一劳永逸。另外names列表的索引顺序务必和txt标注里的第一列数字一一对应，顺序错乱是训练结果异常的第一大原因。
3.2 训练参数与模型训练代码
我用YOLOv8s作为主力模型。原因很现实：YOLOv8n的速度虽然最快，但小目标检测能力较弱；YOLOv8m的参数更多、精度更高，但训练和部署成本翻倍。s在二者之间比较平衡，拿来做这套数据集的基线再合适不过。完整训练代码如下：
from ultralytics import YOLO model = YOLO("yolov8s.pt") # 加载预训练权重 results = model.train( data="shuttle_badminton/data.yaml", epochs=100, imgsz=1280, # 训练图像尺寸，小目标场景建议1280 batch=16, lr0=0.005, # 初始化学习率 lrf=0.01, # 最终学习率缩放系数 optimizer="AdamW", patience=15, # 早停耐心值 device=0, # GPU编号，CPU设为cpu workers=8, mosaic=0.8, # 马赛克增强概率，适当降低 close_mosaic=10, # 最后10轮关闭马赛克 augment=True, seed=42, verbose=True, )参数选择有几个值得解释的细节。imgsz我设置成1280而不是默认的640，是因为这套数据集里的shuttlecock面积太小，图像分辨率不够的话，下采样后球体对应的特征图可能不到两个像素，几乎无法学习。调高输入分辨率能直接提升小目标AP，代价是训练速度变慢、显存占用变高。我这里batch设为16，在12GB显存的环境下勉强够跑；如果显存只有8GB，建议把batch降到8，或者用梯度累积来等效大batch的效果。
mosaic这个增强项也要注意。mosaic把四张图拼成一张，能大幅提升背景多样性，对小目标检测有正向作用；但在训练最后阶段，如果球体被裁剪拼贴得太碎，反而会干扰收敛。所以我设置了close_mosaic=10，让模型在最后10轮回归到真实图像的分布，这招对稳定验证集指标效果很明显。
训练过程中看到下面这种日志就说明流程正常：
Epoch gpu_mem box cls dfl labels img_size 1/100 9.2G 1.6231 2.1543 1.0921 45 1280 2/100 9.1G 1.5123 1.9865 1.0532 48 12803.3 84.4%识别率是怎么评估出来的
标题里写的识别率84.4%，不是什么拍脑袋的数字，而是在这个数据集上、用YOLOv8s模型、在288张验证集图像上得到的mAP@0.5结果。mAP@0.5的意思是：当预测框与真实框的IoU（交并比）阈值设为0.5时，所有类别平均精度的均值。这个指标可以简单理解为“模型把目标框得多准”，IoU越大，框得越严。mAP@0.5是比较宽容的评估口径，工业界常用它判断模型是否可用；如果看更苛刻的mAP@0.5:0.95，也就是IoU从0.5到0.95之间多个阈值下的平均，这个数字会明显低一些，它反映的是更细粒度的定位精度。
具体到每个类别的表现，我用验证集评估得到的结果如下：
| 类别 | 标注框数量 | AP@0.5 | AP@0.5:0.95 | 备注 |
|---|---|---|---|---|
| player | 518 | 91.5% | 58.2% | 运动员目标大，检测最稳定 |
| referee | 265 | 87.2% | 53.1% | 裁判出现频率中等 |
| shuttlecock | 395 | 74.5% | 42.8% | 球体太小，仍有漏检 |
| 全部 | 1178 | 84.4% | 51.4% | 加权平均 |
可以看到，运动员的AP最高，裁判次之，羽毛球最低。这个排序完全符合前面分析的小目标检测难度规律：不是标识数据出了问题，而是小目标检测本身就有天花板。如果想让shuttlecock的AP再往上走，就要走第四部分讲的针对性优化路线。这里的“全部”行是各类别标注数量的加权平均，所以最终84.4%这个数，其实是三类目标综合表现的口径。在使用这个数字做方案汇报时，建议把类别维度一起带上，免得只听一个平均数而高估了小球的实际表现。
4. 训练过程中的常见问题与排查技巧
4.1 羽毛球小目标漏检严重怎么办
第一类问题是漏检，而且主要集中在shuttlecock上。表现为训练loss正常下降，但推理时运动员和裁判都能框出来，球就是不出框。出现这种问题，优先检查三件事：输入图像尺寸是否足够、mosaic增强是否合理、小目标是否被模型当成了噪声。
输入图像尺寸是最直接的影响因素。如果imgsz=640，一个12x12像素的羽毛球在模型最深层的特征图上可能只对应不到1个像素，检测头根本找不到它。先把imgsz提高到1280，往往能让小目标AP提升5到8个百分点。代价是显存占用大约翻倍，这时候只能靠减小batch来平衡，比如batch从16降到8。
mosaic也是一把双刃剑。mosaic拼接后的图像里，小球可能被裁切到只剩半个，这种“部分球体”如果成了标注框，反而教会模型把半截东西也当作球。我实验下来，把mosaic概率从默认的1.0降到0.8，最后10轮强制关闭，能让验证集mAP更稳定。还有一个冷门而有效的增强是copy-paste：剪下图像里的羽毛球贴到其他训练图上，等于人为翻倍了小球样本数量。用小众库augly可以方便实现，但要注意粘贴时别把两个球重叠太狠。
如果以上都调了还是漏检，可以考虑在推理阶段把图像切片，也就是用SAHI等切片辅助推理工具，把大图切成多个小图分别检测再拼回结果。这个方法只影响推理不影响训练，对极端小目标效果立竿见影，但推理耗时也会成倍增加，不适合实时场景。
4.2 标注格式与路径引发的报错
第二类问题是环境或标注本身报错，这类报错往往很隐蔽。最常见的是“标签类别id越界”，错误日志长这样：
AssertionError: Label class 3 exceeds nc=3 in排错思路很直接：把labels文件夹下所有txt文件扫描一遍，找出类别id大于等于3的行。有时是标注工具自动导出了背景类，有时是人工编辑txt时写错了一个数字。建议写个小脚本做全局体检：
import os from glob import glob label_dir = "labels/train" bad_files = [] for path in glob(os.path.join(label_dir, "*.txt")): with open(path) as f: for line in f: parts = line.strip().split() if len(parts) != 5: bad_files.append((path, "列数不为5")) continue cat_id = int(parts[0]) if cat_id >= 3: bad_files.append((path, f"类别id越界: {cat_id}")) for item in bad_files: print(item)这条脚本能一次性揪出两类问题：坐标列数缺胳膊少腿的异常行、和类别id越界的标注。我每次拿到新数据都会先跑一遍再训练，能省下非常多排查时间。
路径问题同样高发。YOLO训练时报找不到图片或标签，很多时候不是文件不存在，而是data.yaml里的path相对路径在当前工作目录下解析不到。我的建议很土但有效：用绝对路径，并且在启动训练前，先用Python打印一下路径是否存在：
import os from pathlib import Path base = Path("shuttle_badminton") for split in ["train", "val", "test"]: img_dir = base / "images" / split lbl_dir = base / "labels" / split print(split, img_dir.exists(), lbl_dir.exists())4.3 排查速查表
| 现象 | 可能原因 | 优先排查方向 |
|---|---|---|
| 每个epoch的验证mAP都不涨 | 学习率过大/过小、标注框大面积错误 | 检查loss曲线，降低lr0到0.001 |
| 训练正常但预测时类别错乱 | 类别id在不同标注文件中不一致 | 跑全局体检脚本 |
| 羽毛球几乎不检测 | 图像分辨率不足、mosaic过强 | imgsz提到1280，mosaic降到0.8 |
| 验证时报“Label class X exceeds nc” | 某个txt类别id越界 | 脚本扫描所有标签文件 |
| 模型把广告牌、场外标识框成人 | 背景样本不够或标注遗漏 | 增加带复杂背景的样本，或调高conf阈值 |
| 显存不足OOM | batch或imgsz过大 | batch降到8或4，开启梯度累积 |
| CPU训练异常慢 | 硬件限制 | 用yolov8n配合imgsz=640先跑通 |
说到背景误检，很多新手会忽略一个潜在因素：标注不完整。如果只标了运动员、裁判和球，但画面里的其他运动物体没有归入“背景”，模型就会学到“这些没标的东西不该被检测”，可实际上检测器天然会把未知目标往已知类别上套，所以广告牌被框成裁判这种事并不罕见。处理办法不是把所有背景都标一遍，而是在抽帧时尽量选择包含更多纯净场地的画面，同时推理时把conf阈值提到0.35左右，能压掉不少误检。
5. 数据集能延伸到哪些应用
5.1 结合跟踪算法做运动员轨迹分析
这套数据集训练出来的检测模型，直接输出的只是“每帧画面里目标在哪里”，还不能形成轨迹和语义。如果想要跑动热力图、站位分析这种高阶应用，需要在检测结果之上再接一层的多目标跟踪算法。我推荐ByteTrack，它思路简单、效果好、部署成本低，用检测框加上卡尔曼滤波做轨迹关联，对快速移动的小目标尤其友好。
具体做法上，用YOLOv8对每一帧进行检测，把输出的目标框和置信度传给ByteTrack，可以得到每个目标持续的track_id。把track_id在每个时间点上的中心点坐标连起来，就是一条运动轨迹。比赛全场视频跑下来，就能统计出每个运动员的平均跑动距离、活动热点区域、击球时的位置分布等数据。对小目标的跟踪还需要注意：羽毛球时有时无，跟踪算法里需要设置比较久的丢失恢复时间，否则球一飞就丢、掉地就断，轨迹非常碎片化。
5.2 自动集锦、战术统计等落地方向
在检测和跟踪的基础上，我认为最有实用价值的两个方向是自动集锦生成和战术动作统计。自动集锦的核心逻辑其实不复杂：把球速突变或者球员位置剧烈变化的片段挑出来。用检测框的高度宽度变化可以大致估算球的尺度变化，当球在连续几帧里尺寸持续增大、随后突然消失，大概率是一次扣杀或得分回合。把这些片段抽出来拼接，再配合转场音效处理，就能做出半自动的比赛精华剪辑。
战术统计方面，裁判可以作为场景锚点，用来区分发球回合；运动员的位置分布可以辅助判断攻防态势；球的轨迹则能统计出每个回合的拍数、球的落点区域。有了这三类基础数据，教练组做赛后复盘时就不需要一遍遍拖视频找关键点了，直接按回合、按轨迹去索引对应的视频片段。需要注意的是，这类应用对模型的鲁棒性要求更高，因为多角度机位切换、镜头拉近拉远都会带来目标尺度的剧烈变化，建议拿到这个数据集先训练出基线模型，再采集自己场地的数据做微调，效果会比直接用预训练模型可靠得多。
把工具链跑通之后，最深的体会是：做数据集的收益是长期的，训练代码反而不是瓶颈。这套2879张图、三分类、三种格式的数据集，前后花了我大量时间在标注和规则统一上，但交付之后的模型训练、格式转换、迁移应用都顺利了很多。羽毛球的目标检测还没有完全成熟的公开方案，特别是小球的漏检问题，需要靠数据质量、分辨率、增强策略一起解决。如果后面有精力，我打算往两个方向继续扩展：一是补一批多机位比赛画面，让模型对不同视角更鲁棒；二是把标注粒度从检测框升级到关键点，直接输出球拍和肢体的关键点位置，为动作纠正类应用做准备。也希望这套数据集的整理方法能给同样在做体育场景检测的朋友一点参考。
