简介面向风电运维与计算机视觉检测场景提供一份采用COCO JSON格式标注的风力叶片缺陷检测数据集覆盖排水孔受损、雷击、污垢、漏油、PU胶带、表面裂纹、侵蚀等缺陷类型适用于目标检测、实例分割等模型的训练与算法验证。标注内容对应2249张图像。资源包共2000个文件含1997张jpg现场图像与3个json标注文件压缩包约74.32MB可帮助研发者跳过数据采集和人工标注环节直接用于缺陷识别实验。对于从事风机巡检智能化、缺陷自动判读的工程师和研究人员这是一份结构清晰、格式标准的数据基础。目前已有820人学习下载适合作为模型训练、算法对比或毕业设计/课题研究的数据支撑。1. 2249 张图的风力叶片缺陷检测数据集到底能不能让缺陷模型直接落地叶片巡检一年拍回成千上万张图靠人眼盯着屏幕看到眼酸漏检和误判全凭个人状态这是风机运维团队的常态。缺的往往不是拍摄设备而是一份“把缺陷讲清楚”的标注数据。标题里这组数据的价值就在这2249 张实拍图用 COCO JSON 格式标注覆盖排水孔受损、雷击、污垢、漏油、PU 胶带、表面裂纹、侵蚀七类高频缺陷。它要解决的不只是“有个数据集可以下载”而是让目标检测模型从冷启动阶段就站在一个定义相对完整的缺陷体系上省掉自己整理原始图、定标注规范、做格式迁移的漫长前置工作。这组数据适合三类人风电巡检硬件或软件厂商的算法岗正在做缺陷检测方向的研究团队以及想给运维团队搭“机检人工复核”流程的平台开发者。如果你只想要一个能快速出 demo、能跑通训练推理闭环的起点这种带统一格式、类别成体系的数据集是效率最高的选择。接下来我会从缺陷谱系和标注逻辑讲起带你完成数据体检、格式转换、训练调参再把我踩过的坑逐个拆开讲。2. 读懂缺陷谱系与 COCO 标注7 类缺陷怎么定义、为什么这样标2.1 七类缺陷的物理成因与视觉判据缺陷检测难难在同类缺陷在不同距离、天气、叶片弧面上的表现差异很大。标注体系若没有物理语义支撑算法学到的只是颜色块和纹理换一个现场就失效。先从成因建立标尺。缺陷类别形成原因视觉表现检测难点排水孔受损叶片内腔冷凝水经排水孔排出孔口密封件老化、脱落或受外力破坏孔口边缘破损、封盖缺失、出现不规则黑色缺口目标面积极小靠近根部与叶尖均有分布容易被当噪点雷击接闪后雷电流沿叶片表面泄放留下烧蚀通道黑褐色烧蚀斑、碳化层、局部表层脱落常带枝状蔓延形态不规则颜色与油污、污垢高度重合污垢盐雾、尘土、昆虫残骸在表面沉积前缘或流线方向上的深色片状、条带状附着物边界模糊光照与阴影会改变对比度漏油齿轮箱或液压系统渗漏油液沿表面流挂深褐至黑色条带多从法兰、连接螺栓处向下延伸面积大、边缘渐进框选边界主观PU 胶带前缘保护胶带老化、起翘、撕裂前缘细长亮色条带破损端部翘起或整段缺失长宽比极大常规锚框很难框齐表面裂纹应力集中或制造缺陷导致结构开裂线状、折线状、网状裂纹多见于后缘与蒙皮接缝细长目标低分辨率下会断成碎段侵蚀风沙雨水长期冲蚀前缘材料流失亮色基材变粗糙、麻点状、失去光泽渐变式变化边界极难画样本内差异大注意一个关键区分雷击属于“破坏性缺陷”基材被烧蚀污垢只是“表面附着物”基材没坏侵蚀则是“材料流失”露出玻璃纤维或胶衣。三类在颜色上接近但运维处置完全不同。数据集把这三类分开标注本质是在逼模型区分破坏性缺陷和表面附着物这是巡检结果能否被信任的前提——雷击要停机排查污垢清洗即可。2.2 COCO 格式的骨架怎么读COCO JSON 的顶层结构由 images、annotations、categories 三块组成。拿到数据先看三者的数量是否自洽再做后续处理。一个典型的结构长这样{ images: [ {id: 1, file_name: IMG_0001.jpg, width: 4000, height: 3000} ], annotations: [ { id: 1, image_id: 1, category_id: 5, bbox: [1234, 567, 89, 45], area: 4005, iscrowd: 0 } ], categories: [ {id: 1, name: drain_hole_damage}, {id: 2, name: lightning_strike} ] }关键字段逐个说明images 里的 file_name 是原图的相对路径或文件名width 和 height 是原始像素尺寸后续归一化都要用它annotations 里一个标注框对应一个目标bbox 用 [x, y, width, height] 表示单位是像素坐标原点在图像左上角area 一般等于框面积评测时会按目标面积分小、中、大组分别计算iscrowd 为 0 表示普通目标为 1 表示密集人群类目标很多训练管线会直接过滤掉 iscrowd1 的框categories 的 id 允许不从 0 开始、允许不连续训练前必须单独建立 id 到训练序号的映射。COCO 的通用性在于生态成熟可视化、标注、评测工具链都认识它不代表它没有边界。这个数据只有 bbox没有 segmentation mask。如果后续要做“雷击烧蚀面积统计”或“裂纹长度估算”bbox 不够用需要在原标注基础上补 mask。这一点早想清楚可以避免模型选型时埋下返工风险。2.3 类别不平衡2249 张图里的隐藏杠杆巡检场景里雷击、排水孔受损这类缺陷天然稀有污垢、侵蚀则常见得多。2249 张图这个规模假设平均每张图 2~5 个框总量大约在 5000 到 10000 个目标之间。问题在于分布不会均匀常见类别可能占一半以上稀有类别可能只有几十个实例。类别不平衡在缺陷检测里不是小事它会让模型在训练时偏向多数类推理时对稀有类的 recall 极低。拿到数据后的第一个动作不是急着训练而是把每个类别的实例数统计成条形图。如果最小类少于 50 个实例第 4 章的采样策略和损失权重就要提前设计。很多团队在这里吃过亏先跑个基线发现雷击 mAP 只有 0.05再回头查数据才发现雷击总共只有 20 个框。数据体检应该在训练前完成而不是等训练结果来提醒。3. 从 JSON 到可视化用脚本吃透 2249 张图的标注分布3.1 写一个 COCO 统计脚本验证数据集最忌“我打开几张图看了看觉得标得还行”。我一般会先跑一个统计脚本把所有类别数量、每张图的框数分布打出来用数字代替感觉。脚本如下import json from collections import Counter with open(annotations.json, r, encodingutf-8) as f: coco json.load(f) imgs coco[images] anns coco[annotations] cats {c[id]: c[name] for c in coco[categories]} print(影像数量:, len(imgs)) print(标注框数量:, len(anns)) # 按类别统计实例数 per_cat Counter(ann[category_id] for ann in anns) for cid, cnt in per_cat.most_common(): print(f{cats[cid]:20} {cnt:6}) # 每张图的框数分布 per_img Counter(ann[image_id] for ann in anns) print(单图框数分布: 最少, min(per_img.values()), 最多, max(per_img.values()))这段脚本的核心输出有两个类别实例数列表和单图框数分布。前者用来判断类别是否极端不平衡后者用来判断图像是“单缺陷图”还是“多缺陷密集图”。如果最大单图框数超过 30这类图在训练时容易让 mosaic 增强后的标签叠加过多需要单独关注。注意 categories 的 id 可能不连续统计时用 category_id 直接计数即可不要假定它等于数组下标。再补一个 bbox 几何尺寸统计用来判断小目标比例import numpy as np boxes np.array([a[bbox] for a in anns], dtypenp.float32) w boxes[:, 2] h boxes[:, 3] print(框宽中位数: %.1f px % np.median(w)) print(框高中位数: %.1f px % np.median(h)) print(框宽小于32px占比: %.2f%% % ((w 32).mean() * 100))这一步很关键。如果原图是 4000×3000 分辨率而框宽中位数只有 40px说明缺陷在原始尺寸下就很小。训练时输入若缩到 640px这类目标会被进一步缩小六倍基本不可检。看到这个数字你就知道训练输入尺寸至少该设到 1280或者直接走切图训练路线。这个判断越早做后面返工越少。3.2 把标注框画回原图做人工抽检统计数字只能说明数量关系框标得好不好、类别贴不贴切必须靠肉眼抽检。用 OpenCV 把框画回原图import cv2 def draw_boxes(img_path, anns, cats, out_path): img cv2.imread(img_path) if img is None: print(图片读不到:, img_path) return for ann in anns: x, y, w, h [int(v) for v in ann[bbox]] color (0, 255, 0) cv2.rectangle(img, (x, y), (x w, y h), color, 3) label cats[ann[category_id]] cv2.putText(img, label, (x, max(0, y - 8)), cv2.FONT_HERSHEY_SIMPLEX, 0.8, color, 2) cv2.imwrite(out_path, img)这段代码里要注意两点OpenCV 的 imread 默认按 BGR 读入画框颜色元组 (0, 255, 0) 对应的是绿色原图 4000×3000 直接画框保存一张图十几 MB肉眼检查不方便建议先缩到 1600 宽再画。2249 张图全部渲染不现实我通常只挑三类看每类随机抽 10 张、单图框数最多的 10 张、框面积最大的 10 张。这三叠图基本就能暴露标注尺度不统一和目标过密的问题。3.3 数据一致性排雷三件套标注数据最常见的三类问题file_name 对应不上磁盘文件、bbox 越出图像边界、框宽高比异常。用一个脚本集中排查import os root /data/blade/images missing [p[file_name] for p in imgs if not os.path.exists(os.path.join(root, p[file_name]))] print(缺图数量:, len(missing)) img_w_h {img[id]: (img[width], img[height]) for img in imgs} violated [] for ann in anns: x, y, w, h ann[bbox] W, H img_w_h[ann[image_id]] if x 0 or y 0 or x w W or y h H: violated.append((ann[id], ann[image_id])) print(出界框数量:, len(violated)) extreme [ann[id] for ann in anns if max(ann[bbox][2], ann[bbox][3]) / (min(ann[bbox][2], ann[bbox][3]) 1e-5) 30] print(长宽比大于30的框:, len(extreme))这类问题大多是标注软件导出设置不当造成的。如果出界框大量出现先检查 JSON 里的 width、height 是否和原图实际分辨率一致而不是急着修单个框。长宽比异常这项要单独看PU 胶带本身长宽比就大但普通缺陷如果长宽比超过 30大概率是框松了或者误标这类框会让模型学到大量背景特征对细长目标的定位精度伤害比想象中更大。4. 用数据集训出可用的缺陷检测模型格式迁移与参数调优4.1 从 COCO JSON 转到 YOLO 格式的脚本训练缺陷检测模型当前最省事的路线是转成 YOLO 系列格式每个标注框对应一行 class_id cx cy w h全部归一化到 0~1。转换脚本如下import json import os with open(annotations.json, r, encodingutf-8) as f: coco json.load(f) order [drain_hole_damage, lightning_strike, dirt, oil_leak, pu_tape, surface_crack, erosion] name2id {name: idx for idx, name in enumerate(order)} cat_map {c[id]: name2id[c[name]] for c in coco[categories]} img_map {img[id]: img for img in coco[images]} os.makedirs(labels, exist_okTrue) for ann in coco[annotations]: img img_map[ann[image_id]] x, y, w, h ann[bbox] x, y, w, h max(0, x), max(0, y), abs(w), abs(h) cx (x w / 2) / img[width] cy (y h / 2) / img[height] nw w / img[width] nh h / img[height] line f{cat_map[ann[category_id]]} {cx:.6f} {cy:.6f} {nw:.6f} {nh:.6f} out_path flabels/{os.path.splitext(img[file_name])[0]}.txt with open(out_path, a, encodingutf-8) as fo: fo.write(line \n)逻辑说明order 列表把七个类别按固定顺序映射到 0~6这一步必须手工维护并写进数据集文档因为 COCO 的 category_id 不保证连续bbox 转成中心点加宽高的归一化形式分母用的是每张图自己的 width 和 height所以不同分辨率相机拍出的图可以混训对 x、y 做了 max(0, ·) 裁剪避免负坐标让 YOLO 解析出错。转换后记得做一次校验把 labels 目录里每个类别的行数统计出来和 COCO 的 per_cat 结果逐类比对不一致说明存在漏转换或文件名冲突。4.2 数据划分与 dataset.yaml数据划分最容易犯的错是随机切分。同一架次无人机拍的图光照、角度、背景高度相似随机切分会让这些高度相似的图同时出现在训练集和验证集里模型学到的是“拍摄环境”而不是“缺陷本身”验证指标虚高。我一般按拍摄批次分组整组分割import os import shutil from collections import defaultdict # 按文件名的目录前缀分组例如 batch_20250101_001.jpg 属于 batch_20250101 groups defaultdict(list) for img in coco[images]: prefix _.join(img[file_name].split(_)[:2]) groups[prefix].append(img[file_name]) group_names list(groups.keys()) # 假设前 80% 的批次进入训练后 20% 进入验证 split int(len(group_names) * 0.8) train_groups set(group_names[:split]) for g, files in groups.items(): target images/train if g in train_groups else images/val for f in files: shutil.copy(os.path.join(root, f), os.path.join(target, f))这种按批次划分的方式至少能避免“同一批照片被拆进两边”。如果数据里有来自不同风场或不同季节的目录优先按风场或月份整组分割效果更好。训练只暴露 8 成批次剩余 2 成做验证最接近真实更换场地的评测环境。dataset.yaml 内容如下path: /data/blade_defect train: images/train val: images/val names: 0: drain_hole_damage 1: lightning_strike 2: dirt 3: oil_leak 4: pu_tape 5: surface_crack 6: erosion这里 names 的索引必须和转换脚本里 order 的顺序完全一致。后续如果新增缺陷类别只在末尾追加索引不要插到中间否则历史标签全部错位这是血泪教训。4.3 训练命令与关键参数以一张 24GB 显存显卡为例训练命令可以这样起yolo detect train \ datablade.yaml \ modelyolo11n.pt \ imgsz1280 \ epochs200 \ batch16 \ lr00.01 \ optimizerAdamW \ cls1.0 \ seed2025逐个参数说清楚imgsz 设 1280 而不是 640是考虑到裂纹、排水孔这类小目标在 640 输入下只剩几个像素特征会被下采样抹掉如果显存只有 12GB设 960 并配合关掉部分 mosaic 增强来减少显存占用。model 用 n 体型是速度和精度的折中叶片缺陷图单张目标密度不高n 型推理快、适合快速迭代资源充足可以换 s 或 m 型冲更高精度。epochs 200 配合早停 patience30 使用缺陷类别少的情况下 60~100 轮往往已收敛两三百轮容易在尾部轻微过拟合。cls1.0 让分类分支帮助区分污垢与雷击这类视觉相似目标类别不平衡严重时调到 2.0。还有一个参数容易被忽略fliplr。叶片前缘缺陷有方向性水平翻转会把前缘目标镜像到后缘引入特征冲突。常见做法是把 fliplr0.0 关掉或者调低到 0.1。训练完先看 val 的 mAP50 和 mAP50-95 两条曲线如果 mAP50 有 80 以上而 mAP50-95 只有 30 上下说明定位框精度差优先回查标注框是否太松而不是盲目加深网络。5. 缺陷检测落地避坑数据与训练阶段的五个典型翻车现场坑 1类别编号错位训练不报错但结果全错现象训练 loss 正常下降但预测时“雷击”标签出现在“排水孔受损”的位置mAP 一塌糊涂。 原因COCO 的 category_id 不连续也不保证从 0 开始直接把 category_id 当 YOLO 的 class index 传入类别索引跑到 8、9越界不报错模型学到的标签全乱了。 解决转换脚本必须显式建立 name 到 0~6 的映射表转换后统计 labels 目录里每类行数与 COCO 逐类对照完全一致再进入训练。坑 2裂纹、排水孔这类小目标在 640 输入下直接消失现象验证集里裂纹和排水孔的 recall 只有 0.1 左右基本检不出。 原因拍摄距离远裂纹在原始 4000px 图里只有 20~30px缩到 640 后再小五倍以上只剩几个像素特征被下采样抹掉。 解决训练输入升到 1280 是第一步更彻底的办法是切图训练把 4000×3000 原图切成 4~9 块带 overlap 的子图标注框同步平移后落到子图坐标系推理阶段用同款切图策略做切片推理。这一步对细长目标的 recall 提升非常明显。坑 3雷击和污垢互相误标现象晴天沾土的叶片被标成雷击雷击后的碳化区被漏检。 原因两类颜色接近都是黑褐色雷击样本天然偏少模型没有足够正样本学“烧蚀纹理”和“污垢附着”的区别。 解决三个层面同时做。输入层加 HSV 增强重点扰动饱和度和明度让污垢颜色褪掉部分数据层把雷击样本做 90/180/270 度旋转和缩放拼贴扩充到 300 张以上训练层把 cls_loss 加大到 1.5~2.0。这三步合起来通常能把雷击 recall 拉回 10 个点以上。坑 4同一批次照片被拆进训练和验证指标虚高现象验证集 mAP 很高带到实际新场景就崩模型像是“背下了构图”。 原因随机划分让同一拍摄批次的图同时出现在训练和验证里模型把背景、光照当特征记忆验证时捡了便宜。 解决按拍摄批次或目录整组划分 train/val工程交付时额外留一个“全新批次”做最终验收整个调参过程只碰一次。这个习惯比大多数超参数调优都值钱。坑 5标注框框得太松背景污染输入现象测试时定位精度差细长裂纹的预测框比目标宽一倍以上。 原因标注时习惯性地给整条裂纹线上下左右留余量对长宽比大的目标框内 90% 面积是背景模型学到的是“周围环境”而不是“线状纹理”。 解决重新标注或半自动修正时用“紧贴目标允许切边”的原则收紧裂纹和 PU 胶带的框统计框面积与最小外接矩形面积的比值把异常松弛的框挑出来在标注工具里修正。6. 再往上走半步评估口径、难例回流与批次纪律训练完不等于交付。缺陷检测的评估不能只看一个 mAP因为漏检雷击和漏检污垢的代价完全不同。我习惯按类别打一张 recall 表低于 0.8 的类别单独开课题处理。mAP 高但某类 recall 低在运维侧就是不信任按类别交付沟通成本最低。难例回流是当前性价比最高的迭代路线。把模型在几千张未标注新图上的低置信度预测导出置信度在 0.3~0.7 之间的框交给人工看一遍把“模型觉得像又不太像”的框转成正样本补齐后重新训练。这类样本的边际收益远高于随机补图因为模型已经在高置信度区做得够好只有难例才能推动边界外推。多数团队把精力花在换网络、调 loss 上实际上先跑两轮难例回流两周内提升通常比“把模型换大一号”更稳。最后讲个我自己的习惯2249 张图开工前先花半小时看一遍文件名或拍摄时间。为什么因为拍摄时间代表季节和光照分布。如果数据集中在夏季晴天冬天低角度光照场景下模型效果大概率打回原形。数据增强能缓解分布缺口但补不了根本。条件允许就尽早补拍一批阴天或多云光照的图只放进测试集测一次真实的“季节泛化”。这个步骤谁都能做只有愿意在标注前多花半小时的人能避开后期返工。这个方向值不值得做我的结论是值得尤其对风电巡检这类长尾行业。缺陷检测不是一锤子买卖2249 张图的真实意义是冷启动引信先把七类缺陷的检出跑通再靠难例回流和数据积累滚雪球。把 mAP 从 60 追到 90大概率靠的不是换模型骨架而是稳定可靠的标注闭环、按批次分割的纪律以及对小目标和类别混淆的持续治理。希望这些数据体检和训练排坑的经验能帮到你少走我踩过的弯路。本文还有配套的精品资源点击获取