简介：这是基于YOLOv8的风力发电机叶片裂纹与异物检测系统完整源码，面向风电运维团队、计算机视觉学习者及智能巡检设备开发者，可替代传统人工目视检查，提升检测效率与准确性。压缩包共17个文件，约5.76MB，包含7张jpg测试图、3个Python核心脚本（训练与推理）、yaml模型配置、pt权重文件、requirements依赖清单以及UI界面文件，目录结构清晰，便于直接运行与二次开发。项目完整覆盖数据采集与标注、模型训练优化、基于PyQt5的界面设计及系统集成全流程，支持图片、视频和摄像头实时检测；代码中预留了数据增强、多尺度检测等优化方向，便于迁移至其他缺陷检测场景。同时附有README说明与测试结果图，方便对照结果复现。目前已有125人学习下载，适合想快速上手YOLOv8工业视觉应用、需要端到端项目参考的开发者。 做风机叶片巡检这行当，最头疼的不是风大、塔筒高，而是叶片上那点裂纹、雷击痕、前缘腐蚀，你在地面上拿望远镜根本看不清楚。以前主流做法是无人机飞一圈拍一堆照片，然后人坐在电脑前面一张张过，一个风场几百片叶子，一个下午眼睛就看花了。我接手做这个YOLOv8风机叶片检测项目，核心目标就一句话：把人工看图这个环节省掉，让模型替人先把有疑点的照片筛出来。
我当时直接选了YOLOv8做检测框架，因为它在这类工业缺陷识别任务里属于“开箱即用”的第一梯队，训练、导出、部署一条龙都比较顺。这套源码项目从头到尾包含数据标注、增量训练、模型评估、导出部署几个环节，代码结构比较清晰，适合做工业视觉的团队直接改着用，也适合正在学YOLOv8的开发者拿真实场景练手。本文就把我做这个项目的完整思路、参数配置、踩坑记录全部拆开讲，尽量做到你照着走一遍就能跑通。
1. 项目背景与整体方案选型
1.1 为什么是YOLOv8而不是其他检测框架
我最早其实先用YOLOv5试跑过一批叶片巡检数据，速度和精度都还行，但后来换成YOLOv8后，明显的体感是训练收敛更稳定了，对小目标的召回率也高了一些。YOLOv8相比老版本在C2f模块、Anchor-Free检测头、Decoupled Head这几个结构上做了调整，收敛速度和对小目标的适应能力都有提升。叶片缺陷的尺寸在整张无人机照片里经常只占几个百分点，比如一条细裂纹可能只有几十个像素宽，这种场景下Anchor-Free的设计确实更友好。
另外还要考虑部署环节。叶片检测不会只在服务器上跑，最终是要放到无人机机载的边缘设备或者风场本地的小型工控机上跑推理的。YOLOv8的模型导出到ONNX再到TensorRT的链路非常成熟，换成其他框架比如DETR那一类，虽然精度可能更好，但转部署时折腾成本高很多。在工业项目里，稳定性和可维护性往往比刷那一个点精度更值钱。
1.2 增量训练：叶片场景的特殊需求
这个项目里我特别强调增量训练，因为风机叶片的缺陷数据很难一次收集齐。今天的风场叶片可能有雷击损伤，明天另一个风场可能是前缘腐蚀为主，不同环境、不同机型、不同季节，缺陷形态差异很大。如果每次都把旧数据翻出来重新训练，数据管理成本会非常高。
增量训练的核心思路是让模型在原有能力的基础上，只学习新数据里的新东西，不把旧知识忘掉。但这里有个坑：如果直接用新数据微调，模型很容易产生“灾难性遗忘”，旧类别或者旧场景的检测能力快速退化。我在实际代码里采用了两个做法来缓解这个风险。第一，把旧数据按一定比例采样混入新数据，哪怕每类只有几十张，也能起到“记忆锚点”的作用。第二，微调时把backbone层的学习率调低，只让检测头和neck部分去适应新数据，这样既学到新形态，又不破坏底层特征提取能力。
2. 数据集准备与标注细节
2.1 叶片缺陷数据从哪来
风机叶片检测数据集主要来自两个渠道：无人机航拍和地面长焦拍摄。航拍数据的问题是叶片在画面里角度变化大，又有背景干扰，比如天空、草地、其他风机塔筒；地面长焦拍摄相对稳定，但视角单一，容易过拟合。我建议两类数据按7比3混合，让模型见过不同视角下的同一种缺陷，不然现场换一个拍摄角度，精度掉得很快。
数据采集的时候还有个细节：尽量保留原始照片的EXIF信息。航拍照片里包含飞行高度、云台角度、GPS坐标这些信息，后续如果要做缺陷定位和告警联动，这些信息非常有用。有些团队在标注前会把照片压缩得很厉害，导致缺陷纹理细节丢失，这反而是给自己挖坑。
2.2 标注规范与数据增强策略
标注叶片缺陷的时候，我采用了一套固定类别体系：0表示裂纹、1表示雷击损伤、2表示前缘腐蚀、3表示油污/污渍。这套体系不是随便定的，而是结合了风场运维工程师的巡检记录表，让模型的分类口径和人工巡检保持一致，这样模型输出的结果可以直接进入现有的运维工单系统。
标注工具我用的是X-AnyLabeling，支持半自动辅助标注。先用一个初始版本的模型跑一遍预标注，人工只需要修正漏检和错框，效率能提高三倍左右。但注意，预标注的框要仔细检查，尤其是细长裂纹这种目标，模型经常会只框住裂纹的一部分，人工需要补齐整条裂纹的轮廓。
数据增强方面，除了常规的随机翻转、色彩抖动、尺度变化，我额外加了随机旋转，角度范围设到正负30度。因为无人机航拍时叶片姿态是任意的，模型必须对旋转足够鲁棒。这里有个容易忽略的细节：旋转增强后，标注框会变成倾斜框，但YOLOv8是水平框检测，代码里要保证增强后的标注框仍然用外接水平矩形表示，不然训练时边界框坐标会乱掉。
3. 环境配置与模型训练实操
3.1 环境配置：从零到能跑训练
环境配置这一步看着简单，但版本不对会卡很久。我推荐一套经过验证的组合：Python 3.9 + PyTorch 1.13.1 + CUDA 11.7 + cuDNN 8.5，YOLOv8官方源码用Ultralytics包，直接pip install ultralytics就能装，但不建议无脑装最新版，因为新版本对CUDA版本有额外要求，旧显卡驱动可能跟不上。
如果你手头是GTX 1660 Ti这种6GB显存的卡，训练时要特别注意batch size。我实测下来，输入尺寸640乘640时，batch size设8已经接近显存上限，硬调到16会直接OOM。这种情况下可以开混合精度训练，AMP开启后显存占用能降不少，而且精度几乎不受影响。下面是我项目里的一个典型训练启动脚本。
yolo detect train \ data=blade_defect.yaml \ model=yolov8s.pt \ epochs=100 \ batch=8 \ imgsz=640 \ device=0 \ optimizer=AdamW \ lr0=0.001 \ amp=True \ project=blade_runs \ name=exp_001几个参数的选择逻辑说明一下。model=yolov8s.pt表示用官方预训练权重做起点。叶片检测属于相对专一的场景，不需要从零训练，用ImageNet和COCO上预训练好的权重做微调能大幅缩短收敛时间。lr0=0.001是微调场景下比较稳妥的初始学习率，如果从头训练，一般会用0.01左右。优化器我选了AdamW，它在小数据集上比SGD更容易调到好结果，训练前期loss下降也更顺滑。
3.2 增量训练的具体做法与损失函数曲线解读
增量训练在Ultralytics框架里做起来其实不难。关键是将新数据与旧数据混合后，在预训练权重上继续训练。我在代码里把训练命令改成加载上次训练结束时的last.pt权重，而不是官方预训练权重。
增量训练时的重要技巧是冻结backbone。YOLOv8的backbone负责提取通用特征，比如边缘、纹理、颜色区块，这些特征在旧场景和新场景中是通用的。我在前20个epoch冻结了backbone层，只更新neck和head部分，等到loss下降趋缓后再解冻全部层，用小学习率统一微调。这样做的效果很直观：模型在新数据上学习速度快，同时对旧数据的检测能力基本不衰退。
训练过程中我习惯把损失函数曲线存下来，实时用TensorBoard看。这里分享一个解读曲线的小经验：训练集loss持续下降但验证集loss在某个epoch开始反弹，说明过拟合了，应该提前停止或者加大数据增强；如果训练集loss下降很慢，说明学习率太低或者模型容量不够，可以适当调大学习率或者换更大的模型。如果验证集loss从一开始就不降甚至在涨，先检查数据集有没有标签错乱，这个坑我踩过一次，后来发现是一批新标注的图片类别ID没对上。
3.3 评估指标与阈值选择
训练结束后，评估指标不能只看mAP。叶片缺陷检测场景里，漏检的代价远高于误检，因为漏掉一条裂纹可能导致叶片在强风下扩展成大事故。因此我在评估时重点看Recall，要求模型在保持mAP不低于0.85的前提下，Recall尽量超过0.9。
实际操作中，如果模型偏向保守，很多模糊的缺陷框会被低置信度过滤掉。这时候我会把推理时的conf_thres从默认的0.25下调到0.15，然后让下游人工复核过滤低置信度结果。这种策略在工业场景里非常实用：宁可让模型多标几个疑似框，也不能让它漏掉真正的缺陷。代价是每天多出几百张人工复核量——但相比漏检后的风机停机损失，这个成本完全可以接受。
4. 模型优化与结构改进探索
4.1 引入多头注意力机制MHSA提升小目标召回
YOLOv8自带的检测头对常规尺寸目标效果不错，但风机叶片裂纹这类细长小目标，容易在深层特征图里被“稀释”掉。我在项目里尝试在backbone输出的最后一层特征图后面插入一个多头自注意力模块MHSA，让模型在全局范围内建立像素之间的长距离依赖关系。裂纹虽然像素少，但它的形状是一条连续线，在注意力机制下，这种全局连续特征会被更充分地捕捉。
具体改法是在model的yaml配置文件中，在最后一个C2f模块后加一个MHSA层，输入输出通道保持和特征图一致。我用的是ultralytics.nn.modules里自定义注册的方式，这样不需要改动检测头部分。加入MHSA后，模型参数量会增加大约8%到12%，训练时间也变长了一些，但在我的测试集上，裂纹类别的Recall从0.83提升到了0.88，这个提升针对风电巡检场景是非常值的。
4.2 替换主干网络ConvNeXt V2的尝试与结果
我还试过把YOLOv8的backbone替换成ConvNeXt V2，因为ConvNeXt V2在ImageNet上的分类精度更高，理论上提取到的特征更好。做法是写一个自定义的yaml文件，把backbone部分换成ConvNeXt V2的层配置，同时保证输出的四个特征图尺度（P3到P5）和YOLOv8的neck输入对齐。
实测下来，替换主干后模型的mAP确实涨了大概1.5个百分点，但带来的问题是推理速度明显下降，在GTX 1660 Ti上从原来的35 FPS掉到了22 FPS左右。对于无人机实时巡检来说，这个帧率有点紧张，如果后续考虑部署到边缘设备，会更吃力。所以我最后的结论是：如果你的应用场景对精度要求极高且推理设备算力充足，考虑ConvNeXt V2；如果像我们一样要跑在无人机机载设备上，标准YOLOv8s加MHSA的组合性价比更高。
4.3 与YOLO11的对比评估
最近YOLO11出来之后，我也在相同数据集上跑了一轮对比。YOLO11在结构上做了不少精简优化，同参数量下推理速度更快，训练收敛也更稳定。在我的叶片检测数据集上，YOLO11s相比YOLOv8s，mAP50差不多，但推理速度快了约15%。
但为什么这个项目我还是坚持用YOLOv8？原因是生态兼容性。我们现有的部署脚本、TensorRT导出流程、前端可视化工具都是基于YOLOv8的API写的，YOLO11虽然API大体兼容，但在一些自定义模块上还要重新适配，比如我加的MHSA模块，在YOLO11上就要重新实现。项目工期有限的情况下，换框架带来的收益远小于迁移成本。如果是全新项目，我可能会直接上YOLO11，老项目改造则建议先评估清楚再动。
5. 模型导出与端侧部署落地
5.1 导出ONNX与TensorRT加速
训练好的模型最终要拿到现场去跑推理，我不会只在Python环境里用model.predict()完事。我习惯先把PyTorch权重导出为ONNX，再用TensorRT做一次优化，这样在NVIDIA Jetson系列设备上能获得更好的推理性能。
导出命令很简单：
yolo export model=best.pt format=onnx opset=12 dynamic=False导出后先用ONNX Runtime验证一遍输出和PyTorch是否一致，检查输出shape和数值差异。如果发现数值对不上，先检查是否有自定义模块不支持ONNX导出，比如我加的MHSA模块就需要额外写一个ONNX支持的实现。然后我用TensorRT的trtexec工具把ONNX转成engine文件，FP16精度模式下还能再提一小截速度。
5.2 无人机机载部署的实际经验
叶片检测中，真正落地比较多的部署场景是无人机机载实时检测。机载设备的算力有限，我一般在此基础上进一步做模型裁剪，把输入分辨率从640降到544，精度损失很小但速度提升明显。同时开启TensorRT的INT8量化，需要准备一批校准图片，用500张左右有代表性的叶片图片跑一遍校准，可以让量化精度损失控制在2%以内。
部署时我还会加一个“检测结果缓存”机制，每隔5秒才上报一次检测结果，而不是每一帧都传回地面站。这样能降低无线链路的带宽压力，也减少地面站端的告警风暴。叶片缺陷检测不像自动驾驶需要毫秒级响应，它更看重“抓得到、传得回、标得准”，所以适当降低帧率换稳定性和连续性，是更务实的选择。
6. 常见问题与排查技巧实录
6.1 训练loss不下降或震荡怎么办
训练过程中最常遇到的情况是loss震荡不收敛。我总结下来，最常见的原因是学习率过大和batch size太小。工业场景的数据量本来就少，如果用默认的0.01学习率加batch 8，很容易出现梯度抖动。我建议遇到loss震荡时，先把学习率降到0.001甚至0.0005，观察几个epoch，看曲线是否变得平滑。另外可以开启warmup，让模型在前几个epoch用很小的学习率“热身”，慢慢进入稳定状态。
还有一种情况是训练loss下降正常，但验证集mAP一直上不去。这时优先怀疑数据问题。比如标注框太大或太小、类别不平衡、背景干扰过多。我遇到过一次mAP卡在0.7不涨，排查后发现是数据里面有一批从网上爬来的图片，分辨率极低，叶片纹理全糊了，模型在这批图上反复“挣扎”。把那批低质量图剔除后，mAP很快就上了0.85。
6.2 常见问题速查表
下面这个表是我在项目里实际踩过的坑和对应解决办法，整理出来方便你直接对照。
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 训练时OOM显存不足 | batch size过大 / 输入分辨率过高 | 降低batch到4或8，开启AMP混合精度 |
| 验证集mAP和训练集差很多 | 过拟合 | 增大数据增强强度，增加Dropout，提前停止训练 |
| 小目标（裂纹）检测不到 | 特征图感受野不匹配 | 在backbone后加MHSA，或把输入分辨率调到800 |
| 增量训练后旧场景掉点 | 灾难性遗忘 | 混入旧数据采样，冻结backbone前20个epoch |
| 导出ONNX后推理结果异常 | 自定义模块不支持导出 | 为自定义模块重写forward，用onnx简化工具调试 |
| 边缘设备推理速度慢 | TensorRT未开启FP16/INT8 | 开启量化，降低输入分辨率，裁剪冗余通道 |
6.3 调试技巧：画损失函数曲线与可视化检测结果
调试模型时，画损失函数曲线是第一步，但只看曲线还不够。我习惯每隔5个epoch就把验证集图片的检测结果输出到一张拼图里，存成一个HTML文件，训练过程中随时可以打开看模型正在“关注”哪些区域。这个方法比光看数字直观得多。比如模型如果频繁把背景里的塔筒误检成裂纹，你一看可视化结果就明白了，纯粹是训练数据里塔筒背景图太少，导致模型没学会区分。
我还在代码里加了一个visualize.py脚本，对标注文件和推理结果做逐张对比，用不同颜色区分对检、漏检和误检。这个脚本帮我在项目前期快速定位了一大批标注框错位的问题，当时有将近20%的标注框中心点偏移，模型训练出来精度一直上不去，可视化对比一拉出来，问题一目了然。
最后再分享一个我个人的操作习惯：每次训练结束，除了保存best.pt和last.pt，我还会把训练时的数据yaml、模型yaml、超参配置、数据增强参数全部打包存档。这样做的好处是，一个月后你发现现场反馈回来一批新缺陷形态，想复现当时的基线模型做增量训练时，你不会因为忘了当初用了什么配置而抓瞎。这些“元数据”在项目后期维护中价值非常高，甚至比模型权重本身还重要。
本文还有配套的精品资源，点击获取
