做风电叶片巡检的人都知道真正麻烦的不是“飞上去拍照”而是拍完之后的照片处理。一次出动无人机单台风机少说几百张高清图一个风场几十台机组存进硬盘就是上万张靠人工一张张放大找裂纹眼睛看花了不说还容易漏掉关键缺陷。我接触这个“基于 YOLOv26 的风电叶片缺陷检测系统”项目出发点就是想把这最后一道盯屏环节也自动化起来无人机负责采集机载边缘设备负责实时推理地面端负责复核归档形成一条能落地的视觉检测链路。这套系统的核心是 YOLOv26 目标检测框架配合无人机高分辨率采集把叶片表面的裂纹、剥落、前缘腐蚀、雷击损伤等缺陷在照片里直接框出来。它解决的不单是“看照片”的问题而是把巡检从“人海战术”拉回到“数据流管理”让缺陷位置、缺陷类型、巡检时间都能结构化归档。这篇文章我会从方案选型、数据集构建、模型训练、边缘端部署到现场调试把整个项目踩过的坑和验证过有效的做法都写清楚适合风电运维、无人机系统集成、算法工程方向的团队参考也适合正在考虑把视觉检测落到工业场景的开发者。1. 项目背景与需求拆解1.1 风机叶片巡检的核心痛点叶片是风机成本最高的旋转部件长期暴露在风沙、雨蚀、紫外线、雷击环境下表面缺陷一旦没及时发现轻则影响发电效率重则导致叶片开裂甚至断裂。传统巡检手段主要有三种人工爬塔、高空作业车、无人机人工判读。前两种效率低、风险高单台机组巡检成本经常在数千元以上一天做不了几台无人机把采集效率提上去了但判读环节仍然依赖人工而且是在电脑前盯着几千张相似的叶片表面图注意力稍微涣散就会漏掉几毫米宽的早期裂纹。从故障统计看叶片缺陷分布也很有规律前缘腐蚀和砂眼占比最高其次是后缘开裂、雷击损伤、表面剥落。早期缺陷往往只有几厘米甚至几毫米对比度低、背景纹理杂乱这给自动检测算法提出了很高要求。项目启动时我们明确了几条硬指标单张图片推理时间不超过 80 毫秒边缘设备上、裂纹类缺陷召回率不低于 85%、支持 RTK 定位后的缺陷地理映射、能在弱网环境下断点续传数据。这些指标决定了技术选型方向。两阶段检测器精度可能更高但边缘端推理速度撑不住无人机巡航节奏传统图像处理对光照变化又太敏感。最终我们把目标锁在一阶段检测器上YOLO 系列在这条路上积累最厚生态也最完整从训练到部署的工具链很顺这才有了后面整套系统的雏形。1.2 为什么选 YOLOv26 作为检测骨干图像检测框架这几年迭代很快从早期的锚框机制逐步演进到无锚框、动态匹配、注意力特征融合每一代都在解决前代的痛点。YOLOv26 我的理解是它不是某一项单点突破而是把之前分散在各类模块里的经验整合进了统一框架多尺度特征融合更激进、训练时的正负样本匹配更动态、模型结构对部署环境更宽容。真正让我决定把它作为骨干的是它在大分辨率输入、小目标召回、边缘端部署三个方向上的综合表现。叶片裂纹这类缺陷在整张无人机照片里占比经常不到 1% 甚至更小属于典型小目标问题。YOLOv26 的高分辨率特征保留能力比前几代更明显配合多尺度预测头能让模型在 640 输入下也保持对小目标的敏感度。同时它的主干网络结构允许部分模块剪枝量化压缩到 FP16 甚至 INT8 后精度损失可以控制在可接受范围这对跑在机载小盒子上的场景非常关键。还需要考虑工程人的现实训练生态要成熟。YOLOv26 对常见标注格式兼容得很好能直接食用已有的 VOC/COCO 风格标注也能轻松转成边缘端需要的模型格式。我们团队里有人熟悉旧版 YOLO迁移过来的学习成本很低这在大版本迭代时很省事。选型时我也对比过几个其他的检测框架有的精度表格很好看但转换成 TensorRT 后一堆算子不受支持落地时血压拉满YOLO 系列基本不存在这个问题。1.3 系统能力边界与应用场景一套完整的无人机叶片缺陷检测系统不止是一个模型文件而是“采集—推理—定位—归档—复核”的闭环。我们用一张图描述整个系统的输入输出无人机沿规划航线飞行云台相机拍摄叶片正反面、前缘、后缘等多角度图像机载计算单元实时检测缺陷目标检测结果连同无人机 GPS/RTK 坐标、云台姿态角一起下传地面后端把这些信息映射到叶片展向位置生成带缺陷框标注的巡检报告。应用场景上这套系统适合三类用户一是风场运维团队希望把日常巡检从“飞手判图”升级为“自动出报告”二是无人机服务商需要在交付巡检服务时提供量化缺陷清单三是叶片制造商和第三方检测机构需要在质保期内批量检查出厂叶片状态。对这三种角色系统的价值点略有不同运维方看重漏检率服务方看重效率和报告规范检测方看重可复现性和数据留痕。后面所有设计都是围绕这几个价值点展开的。2. 系统总体方案设计2.1 无人机平台与采集参数无人机选型直接决定图像质量下限。我们的原则是“飞行平台稳定优先相机画质优先便携性次之”最终选用六旋翼工业级飞行平台抗风等级 7 级以上搭载 RTK 模块保证厘米级定位精度。相机部分用的是变焦云台相机光学变焦倍数不低于 20 倍传感器尺寸 1/2.3 英寸以上避免用电子变焦放大后画面涂抹感严重。采集参数上踩过几次坑之后总结出比较稳定的配置拍摄距离控制在 6 到 12 米太近了单张覆盖面积小导致数据量爆炸太远了细小裂纹在图像里只剩几个像素云台俯仰角尽量对准叶片表面的法线方向倾角大于 30 度时裂纹容易被叶片弧度压缩检测难度成倍上升。飞行速度建议控制在 4 到 6 米每秒同时设置相邻照片重叠率不低于 60%这样既能保证拼接连续性也能让同一个缺陷在多个视角下出现提高检出置信度。关于光照强烈建议在阴天或者顺光时段作业直射阳光会在叶片表面形成硬高光和死黑阴影缺陷对比度急剧下降。我们实测过同一片裂纹区域顺光与逆光拍摄的检测置信度相差 0.2 以上这个差距在真实巡检中很致命。总结的拍摄参数参考表如下参数项推荐值说明拍摄距离6-12 m根据叶片大小调整巡航速度4-6 m/s保证重叠率与防抖照片重叠率≥60%供复核与拼接云台倾角0-30°尽量接近表面法线相机模式手动曝光锁定快门与 ISO作业天气阴天/多云避免强光直射2.2 边缘推理与数据链路实时检测跑在机载边缘计算单元上我们选用的是带 GPU 的嵌入式平台整机功耗控制在 30 瓦以内背在无人机脚架上不影响重心。图像从相机输出进入边缘设备后先经过硬件解码缩放再送入 TensorRT 优化后的 YOLOv26 模型。这一路如果直接用 CPU 解码延迟会飙到每帧几百毫秒飞手云台稍微一转就掉帧。换成硬件解码后单帧端到端推理时间可以压到 60-80 毫秒能跟上无人机巡检节奏。数据链路分实时和离线两条实时链路只回传“有检出”的关键帧和对应位姿数据数据量小4G/5G 网络足够现场飞手能通过地面站屏幕看到缺陷框叠加画面离线链路在降落或转场时自动同步全量原始图片到地面服务器供后台二次复核、模型迭代训练使用。弱网环境下采用断点续传队列文件按任务批次编号上传失败自动重排不丢数据。这套设计在实测中最大的好处是现场注意力只集中在疑似缺陷帧上不会被几千张正常图片淹没。2.3 软件模块划分与职责系统软件按模块拆开各模块之间通过标准接口通信方便后续替换升级。采集模块负责相机控制、云台角记录、帧缓存推理模块封装模型加载、预处理、检测后处理对外只暴露“输入图像、输出检测框”定位模块接收检测结果与无人机位姿计算出缺陷在叶片展向的相对位置归档模块负责写数据库、生成报告、关联原始图片。我把这套划分讲给团队时用了一个类比就像流水线上两个工人一个只负责把零件放到传送带采集一个只负责拧螺丝推理中间不需要互相喊话只需要传送带速度匹配。模块化带来的直接好处是模型换版本、相机换型号都不需要动整个链路只改对应模块的适配层。代码层面所有模块共用一个数据格式定义文件缺陷框统一为(类别, x_center, y_center, width, height, confidence, frame_id, gps_x, gps_y)结构排查问题的时候非常清晰。3. 数据集构建与样本工程3.1 缺陷类别定义与采集规范任何检测系统都绕不开数据集这道坎风电叶片缺陷检测尤其如此。我们在项目初期定了 6 个主类别裂纹、剥落、前缘腐蚀、雷击损伤、胶缝开裂、表面污损。污损类对运维影响不大但如果不单独建类模型很容易把它误报为裂纹所以宁可在类别上多分一分。每一类我们都制定了拍照规范缺陷处于画面中心、占画面宽度不超过 30%、至少两张不同视角照片、每张照片附带拍摄距离和角度标签。这样建出来的数据集模型学到的是“缺陷本身的样子”而不是“某次任务的拍摄习惯”。原始照片分辨率统一处理为 1280×1280 或 1920×1080太高会让训练显存爆炸太低则丢失裂纹细节。标注格式使用 YOLO 的归一化坐标一个缺陷一个框框尽量贴合缺陷外轮廓。这里有个容易被忽略的点叶片边缘的微小缺陷框非常窄归一化后可能只有 0.005 的宽度训练时如果直接按原尺寸算正样本权重大幅偏小建议对小框做最小尺寸截断保证训练时损失函数不会忽略它们。3.2 样本不均衡处理与增强策略真实叶片上裂纹明显少于污损加上我们按缺陷类别采集天然会形成不均衡。直接喂给模型模型会倾向于把一切不确定区域都归到样本多的类。解决思路分两步先按类别数量做重采样让每类比例不超过 3:1再做针对性离线增强。离线增强不是简单翻转、旋转就完事对叶片场景我重点推荐三种第一个是 Mosaic 拼接把四张图拼成一张再训练。它对小目标提升非常明显相当于变相增加了图像尺寸也让模型在复杂背景下学会区分多个目标第二个是 Copy-Paste从真实样本里把裂纹抠出来贴到背景叶片图上。这种方式比纯组合好的地方在于新样本的缺陷纹理完全真实只是位置背景变化模型学到的泛化性更强第三个是光照扰动模拟不同时段阳光角度和云层遮挡避免模型过拟合到“阴天拍的才是缺陷”。实测下来增强后的训练集在验证集上 mAP 提升了大约 8 个百分点其中 Copy-Paste 贡献最大。要注意增强强度别拉满我们试过把 Mosaic 比例调到 1.0模型对真实单图的预测反而变得不稳定因为训练分布和部署分布差太远了。建议 Mosaic 0.5、Copy-Paste 0.3、光照扰动 0.5效果相对均衡。3.3 标注质量管理数据集的生死线在标注质量。叶片缺陷的边缘模糊、形态细长标注标准稍微不一致模型就会被“教坏”。我们的做法是三段式管理先由标注人员按统一文档标注再由有经验的技术人员对每个样本复审最后把模型预测的难例挑出来加入专家讨论池。标注界面里必须能看到原图放大后的局部细节只给缩略图很容易忽略小裂纹。复审核查时我们用一个简化版 Kappa 系数衡量标注重合度对同一批图请两人分别标注框交并比大于 0.5 才算一致。第一次统计时一致率只有 60% 出头主要分歧在对“疑似裂纹还是正常纹理”的把握上。后来我们决定把模糊样本单独归入“疑似缺陷”类不硬性分成裂纹或剥落模型这个任务的容错率反而上来了。标注过程确实枯燥但这一步偷懒后面训练调参时浪费的时间会是标注时间的数倍。4. 模型训练、评估与调优4.1 迁移学习与训练流程模型训练基于预训练权重做迁移学习不是因为从零训练不可以而是叶片缺陷数据集规模有限从零训练在几万张图上很难收敛到满意的特征表达。预训练权重里对边缘、纹理、光影的底层特征已经很强了我们只希望模型在上层“记住”缺陷的组合模式。训练流程分三步第一阶段冻结主干网络前 80% 层只训练检测头和颈部学习率 1e-3跑 50 个 epoch第二阶段解冻全部层学习率降到 1e-4再跑 50 个 epoch第三阶段用小学习率 2e-5 微调同时打开多尺度训练让模型适应不同拍摄距离带来的尺度变化。训练参数上输入分辨率先设 640单卡批大小 16EMA 启用优化器用带动量的 SGD。为什么要用 SGD 而不是 Adam在检测任务里 SGD 的泛化能力通常更稳Adam 收敛快但容易过拟合小数据集。如果你显存紧张batch size 降到 8学习率按比例降到 5e-4不要强迫自己用大 batch 硬顶。训练时我会同时盯训练损失和验证集 mAP。一个很灵验的信号是如果训练损失下降很快但验证 mAP 迟迟不动基本是过拟合了优先检查增强是否过强、类别是否不平衡如果训练损失和验证 mAP 一起不动才是学习率或模型容量的问题。不要只看最后结果过程中每 10 个 epoch 存一次权重回滚很方便。4.2 小目标检测的针对性优化叶片裂纹的像素占比非常小提升小目标检测是训练调优的重中之重。我的经验是从三个层面一起做数据层、模型层、推理策略层。数据层上面说过用高分辨率输入和 Copy-Paste模型层可以打开高分辨率特征图输出让模型在更浅的层也能生成预测框推理策略层用切图推理。所谓切图推理就是把 1920 大图切成 640×640 的重叠块每块独立推理再合并结果。切图推理会带来推理次数上升但对小目标召回率的提升非常直观。我们实测过直接用 1920 下采样到 640 输入2 厘米宽裂纹的召回率只有 65% 左右切成 640 块推理后召回率涨到 87%。代价是单张图推理耗时从 70 毫秒涨到 400 多毫秒所以现场部署时做成了可选项巡检模式下快速扫查发现低置信度疑似区域后再用切图复核。模型结构上我尝试过在颈部增加一个高分辨率检测头但显存消耗太凶边缘设备扛不住。最后采用更实用的方案保持标准检测头把输入分辨率在训练和部署时统一提高到 960再配合切图效果已经足够。4.3 评估指标与阈值选型模型训练完成后的评估光看 mAP 会骗人。叶片巡检场景下漏检一个裂纹可能导致后续叶片结构失效而误报无非是让机械师多爬一次塔或者多看一张图两者实际代价完全不对等。因此我们评估时聚焦两个指标召回率和精确率并且拉出阈值曲线来看。在阈值 0.25 时系统召回率能做到 90% 以上精确率在 70% 左右阈值提到 0.5精确率涨到 88%但召回率掉到 78%。对运维场景我们最终把置信度阈值设在 0.3宁可后台多几条待复核记录也不要让裂纹漏过去。另一个被忽视的指标是“叶片级召回率”即对一个叶片只要有任一张照片检出了缺陷就算命中。无人机重叠拍摄下同一个缺陷会出现多次模型只要在其中一两帧检出即可。用叶片级召回率评估比图片级更符合业务要求。我们在现场测试中叶片级召回率可以稳定达到 94% 左右这个数字对运维决策来说才有意义。5. 端到端部署与现场验证5.1 模型转换与边缘端加速模型在训练机上跑得再快都没用部署才是硬道理。我们把训练好的权重转到 TensorRT 推理引擎精度先用 FP16如果边缘设备功耗紧张再试 INT8 量化。转换过程中最容易踩坑的是自定义算子的兼容性好在 YOLOv26 的模块基本都是标准算子转换过程比较顺利。INT8 需要校准数据集我们选了 500 张包含各类缺陷的代表性图片做校准量化后 mAP 掉控制在 2 个百分点以内边缘端推理速度比 FP16 快了接近一倍。边缘端推理链路还有几个小细节NMS 后处理要放在 GPU 上做别把检测框结果拷回 CPU 再筛框数据搬运的时间比后处理本身还长预处理环节直接把图像缩放到模型输入尺寸不要先转成 PIL 再转 tensor。要打开硬件解码和异步队列让 GPU 一直在干活而不是等 CPU 慢慢送数据。多线程调度上我用一个生产者-消费者模型采集线程不停入队推理线程从队列取帧推理完成后把结果放入输出队列。队列长度做上限超过上限丢弃最旧帧。这一步是为了防止无人机快速转向时积压延迟现场的实测体验是画面实时性高了很多。5.2 缺陷坐标解算与工单联动检测到缺陷只是第一步运维人员需要知道缺陷在叶片哪个位置否则报告价值大打折扣。我们做了缺陷坐标解算模块通过无人机 RTK 坐标、云台俯仰角、相机视场角和检测框归一化坐标反算出缺陷的大地坐标。再根据风机塔筒坐标和叶片当前方位角把大地坐标转换到叶片展向坐标系输出“距叶根 27.5 米、前缘侧”这样的描述。这个定位精度受姿态角误差影响实测在 1 米左右满足巡检工单的派发需求。有了结构化缺陷记录就可以和各种运维系统对接。我们的输出格式包含缺陷截图、叶片编号、展向位置、缺陷类别、置信度、巡检时间。后端系统自动生成带图片的工单推送给检修班组。班组到现场后先用定位描述找到叶片位置再用截图的高清原图辅助比对整体复核一档缺陷大约需要 10 分钟比传统翻照片找缺陷快一个量级。5.3 现场巡检测试实录项目在某风电场做了三天现场测试选的是 8 台叶片表面缺陷记录比较完整的机组。白天阴天天气按前面说的采集参数飞行每台机组飞行时间约 25 分钟采集照片 500-700 张。边缘设备实时推理地面端同步复核。测试结果以缺陷类型为维度统计检出情况如下缺陷类型已知缺陷数检出数召回率误报数裂纹121191.7%3前缘腐蚀181794.4%2剥落66100%1雷击损伤4375%1裂纹漏检的那一条回看原始图像发现是处于叶片弧面转折处云台角度没对准缺陷被透视压缩得很厉害。雷击损伤漏检一个则是因为损伤痕迹和原有黑色接闪器颜色高度接近模型被判成背景。这两个案例后来都补进了训练集说明现场测试的价值就是不断把边界样本收集回来。误报大多是胶缝开裂类和表面污损混淆人工复核成本仍然可控。6. 常见问题与实战排查6.1 误检与漏检的现象分析判断模型问题先别急着改参数先把错误样本分类。我习惯把误检分成结构混淆型、光照干扰型、背景干扰型三类。结构混淆型最典型的是叶片防雷条被当成裂纹这类问题要靠增加负样本解决把大量正常叶片上的防雷条、排水孔、螺栓罩圈进“背景”类光照干扰型是阳光直射在圆弧表面形成高光带模型误以为边缘通常通过拍摄时避开强光或做图像增强解决背景干扰型是背景树木、地面纹理被误检加大输入裁剪或调整置信度阈值即可缓解。漏检比误检更让人头疼。漏检的常见原因有三个目标过小、目标对比度极低、目标变形严重。目标过小用切图推理对比度低尝试 CLAHE 增强再送模型变形严重适当增加训练集中大角度拍摄样本。排查时要在验证集上按类别、按尺寸、按角度做分层统计确定是哪一类样本拖低了召回再对症下药。不要一上来就调损失函数权重那往往是最后手段。6.2 边缘设备资源瓶颈边缘端跑着跑着出现推理延迟突然飙到几百毫秒甚至上千毫秒的情况第一反应别怀疑模型变慢了看一下设备温度是不是顶到降频线。我们测试时发现机载盒子贴在无人机中心板上散热条件差连续飞行十分钟后 GPU 温度直接冲到 85 摄氏度推理延迟从 65 毫秒涨到 200 毫秒。后来在散热器上加了一个小风扇温度压到 70 度以内延迟稳定在原先水平。还有一次延迟异常是因为队列积压现场飞完一个起落没及时传输数据积压帧越堆越多处理速度被拖垮。加一个“已处理帧数/丢弃帧数”计数器能在现场立刻看出瓶颈在哪。显存不足是另一个典型问题。切图推理开启后显存占用几乎翻倍碰到边缘设备显存只有 4GB 的情况直接爆显存重启。解决办法是控制切图并发批大小、关掉冗余特征图输出、必要时降输入分辨率。优先级是保切图而不是保大输入因为小目标召回比整体分辨率更依赖切图。6.3 图像质控与采集规范检查系统再强也救不了对焦虚掉的图。现场飞行时飞手视角很难时刻盯住画面对焦状态我们干脆在边缘设备上加了一个图像质量评估模块用拉普拉斯方差判断清晰度低于阈值直接标记为“模糊帧”并提示重拍同时统计每张图的直方图过曝或欠曝帧也自动剔除。这个模块看起来简单但给后续数据处理省了很大精力模糊帧不会再混进训练集或报告。采集规范也需要定期检查。我们给飞手配了一张巡检点表记录每次拍摄的距离、角度、风速、云台参数回来以后把参数和照片 EXIF 同步比对偏差超过 20% 的架次标记为无效数据源。数据的可用性比数据量更重要这是我在项目里体会特别深的一点。最后补一句个人经验这个系统后续最值的扩展方向是把缺陷随时间的变化曲线做起来同一片叶片每隔三个月的检测结果叠在一起就能看到裂纹扩展速率那时风机运维才真正从“发现缺陷”升级到“预测缺陷”。做这类项目别只盯着模型精度那点涨跌整条数据链路的稳定性才是现场落地的定盘星。