用无人机代替人工去市政道路上跑病害巡检这几年几乎成了很多养护单位的标配动作。但我在这类项目里见过最多的翻车现场不是飞机摔了也不是照片拍糊了而是模型根本不认识路面——拿通用目标检测模型直接往航拍图上套裂缝没框出几条树影、沥青补丁、砖缝反而被标得密密麻麻。归根结底通用数据集里几乎没有专门为“无人机俯拍道路缺陷”准备的正样本模型没见过的东西自然认不出来。所以像“无人机航拍巡检道路缺陷图像数据集”“道路裂缝识别、道路坑洞YOLO格式数据集”这类面向市政道路巡检的专用数据才真正有落地价值。这篇我就以这类数据集为引子聊聊它到底长什么样、为什么用YOLO格式组织、拿到手之后怎么训练出一套能在市政巡检里真正干活的裂缝和坑洞检测器。内容不绕弯子直接说标的和坑。1. 一套面向无人机航拍的病害数据为什么不是“拿现成模型就能凑合”1.1 通用数据集的模型栽在无人机这个视角上先说个很多人容易忽略的事实COCO、VOC这类通用数据集里“路面裂缝”和“路面坑洞”从来都不是主流类别。模型在那个世界里学的是人、车、猫、狗、杯子是一个个边界清晰、有完整轮廓的“东西”。但裂缝是什么它本质上是一条贯穿路面的纹理断裂没有封闭轮廓颜色和背景几乎没差别离开上下文你甚至很难说它是个独立物体。更麻烦的是视角。车载相机拍道路病害是贴地斜视裂缝在画面里是横向展开的长条阴影和车辙干扰相对可控。无人机航拍则是从几十米高空俯拍画面更平、目标更小、纹理更多路面的车道线、新旧沥青接缝、树影、井盖边缘全都混在一起。同一个病害在两种视角下的特征表达完全不同模型在车载数据上练出来的特征拿到俯拍图上基本失效。所以一套“无人机航拍巡检道路缺陷图像数据集”存在的意义不是锦上添花而是解决最根本的正样本缺失问题。它给模型提供的不是泛泛的“特征提取能力”而是“从高空俯拍画面里认出路面病害”这一种被通用数据集体量稀释掉的能力。1.2 专用数据集的三个关键价值类别、口径、可迭代第一是类别体系干净。像这套数据集类别就锁定两类道路裂缝crack和道路坑洞pothole。别觉得两类太少实际工程里把类别控制得越少模型越容易把注意力集中在“病害本身”上。你非要一口气加进去龟裂、沉陷、车辙、拥包每一类的标注样本都得成百上千否则模型学出来就是一团浆糊。第二是标注口径统一。道路病害检测最怕一件事同一个东西在这张图里算裂缝在另一张图里不算。数据集如果由多人标注且没有统一规则模型会学到互相矛盾的特征训练出来的结果就是验证集上指标还行换个路段立刻现原形。所以靠谱的数据集内部一定有一套明确的“什么算裂缝、什么不算”的口径这个我后面会展开讲。第三是可迭代。像标题里的“第10402期”说明这是一套批次化更新的数据资产。市政道路巡检不是一次性项目而是每个月、每个季度都在重复的任务。每一期新的航拍数据产生后可以在旧模型基础上做增量训练同时淘汰过时机型和低质量样本。这种“官网式数据资产”的运营方式恰恰是很多临时采集一次就跑路的项目最缺的。2. YOLO格式的巡检数据集从文件结构到标签内容的完整拆解2.1 最常见的目录组织方式拿到一套YOLO格式的数据集第一件事不是急着解压训练而是先看目录结构。规范化的数据集通常长这样road_defect_10402/ ├── images/ │ ├── train/ │ │ ├── 10402_000001.jpg │ │ ├── 10402_000002.jpg │ │ └── ... │ └── val/ │ ├── 10402_005001.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── 10402_000001.txt │ │ ├── 10402_000002.txt │ │ └── ... │ └── val/ │ ├── 10402_005001.txt │ └── ... └── road_defect.yaml关键点在于images和labels里每一个文件的文件名严格一一对应train和val的划分已经做好了。不用自己再折腾原始的图片和标注文件配对省掉最枯燥的第一步。如果数据集是单目录结构只给一个all文件夹外加train.txt、val.txt两个清单文件也常见。这种情况下清单文件里每一行是一个图片的相对路径训练脚本按清单加载效果一样。你自己做数据集时建议直接采用train/val分开的目录结构因为后面所有训练工具、脚本都是默认兼容这个模式的少写很多自定义逻辑。2.2 标签txt里那一行数字代表什么YOLO格式的标注文件是纯文本每一行对应一个目标实例格式固定为类别ID、归一化中心点x、归一化中心点y、归一化宽度、归一化高度。一个典型的label文件长这样0 0.521034 0.367821 0.082153 0.014672 1 0.118475 0.839201 0.041233 0.031892第一行的含义是类别0即裂缝目标框中心点位于图像宽度方向的52.1%处、高度方向的36.8%处框宽度占整张图宽度的8.2%高度占整张图高度的1.5%。注意几个容易踩的细节。第一所有坐标全部归一化到0到1之间如果你的框本来是用像素坐标画的必须先除以图像宽高否则训练会直接崩。第二如果目标框超出了图像边界标注时应该把超出的部分裁掉再归一化不要留下大于1的数值。第三类别ID从0开始计数不是从1开始这在写配置文件时最容易搞错。配套的配置文件road_defect.yaml是所有训练脚本的人口至少包含路径、类别数、类别名三样东西path: /data/road_defect_10402 train: images/train val: images/val nc: 2 names: 0: crack 1: pothole这个文件里的nc必须和标注文件里的类别ID最大值得对上names的顺序必须和训练时预期的一致。很多人训练到一半才发现names写反了明明数据里裂缝最多模型预测出来的类别1却是坑洞白白浪费两天时间。2.3 数据集的“批次期号”在实操中怎么用“第10402期”这个编号不是摆设。在真实的巡检项目里每一期数据对应着一次具体的巡查任务有航线、有日期、有一个明确的地理覆盖范围。批次号至少能做三件事。第一追溯。模型在新路段上误检了想知道是不是训练数据里缺少同类样本直接按批次号查这一期的原始航线照片看采集条件比在一堆无编号图片里大海捞针效率高得多。第二防止数据泄漏。划分训练集和验证集时如果按文件随机切同一期数据里同一个路段的不同帧会同时进训练和验证指标虚高换路段立刻露馅。正确的做法是按批次或按路段划分保证验证集里的位置信息对模型完全陌生。第三增量训练。新一期航拍数据回来之后只需要在新数据上做增量训练不用把历史数据全部重跑一遍成本低很多。3. 无人机俯拍照里的裂缝和坑洞标注细节决定模型上限3.1 飞行高度决定你能看到多细的裂缝很多团队把无人机照片拍回来了才发现模型怎么训都学不出细裂缝。问题往往不在模型而在照片的地面分辨率。地面分辨率用GSDGround Sample Distance表示物理意义是每个像素对应地面上多大范围。估算公式不复杂GSD等于飞行高度乘以图像传感器像元尺寸再除以镜头等效焦距。举个直觉例子飞行高度50米、常见行业级相机参数下地面分辨率大概在1到2厘米每像素的量级。一条常见的横向裂缝宽度也就是1到2厘米在画面里只占一个像素左右。一个像素宽的裂缝人的肉眼在屏幕上放大还能勉强看出来但对目标检测模型来说它要依赖周围十几个像素的上下文才能形成判断难度陡增。所以标注和训练之前先回看采集参数巡检细裂缝时飞行高度不要一味追求大覆盖面该压低就压低或者使用长焦相机保证病害在画面里至少有5到10个像素的宽度。数据集的图像质量上限从起飞那一刻就定死了标注和训练都改变不了这个物理约束。3.2 裂缝是“长条状”目标坑洞是“块状”目标框法完全不同YOLO格式只能用水平矩形框标注目标但裂缝根本不是个矩形。它可能是一条横跨半幅路的横向裂缝可能是沿着行车方向的纵向裂缝也可能是弯弯曲曲的网状裂纹。用矩形框去框必然会有大量空白区域框进来这是格式本身的固有约束但标注时要尽量控制误差。我的经验是让标注员遵守几条简单规则。横向裂缝和纵向裂缝框要沿着裂缝主轴去拉尽量减少框内无效背景能把一条完整裂缝框进去就不要拆成多段但裂缝长度超过图像宽度三分之一且形状明显不规则时宁可拆成两三段分别标注也不要硬拉一个包含大量背景的大框。拆段的坏处是同一物理裂缝会被计数成多个目标好处是模型学到的框内特征更集中检测精度明显提升。坑洞则是另一回事。坑洞是有边界的塌陷区域形状大体接近圆形或不规则多边形用水平矩形框天然合适。标注坑洞时反而要小心一个情况很多坑洞边缘是破碎的沥青剥落向外发散框是把整个破碎区域都框进去还是只框中间塌陷核心区。我认为只框核心塌陷区更利于训练因为发散状的碎边在俯拍图上和普通裂缝混杂框进去只会让类别特征不清晰。3.3 边界样本该标不该标直接影响模型认知这是标注环节里最重要、也最容易被压缩的部分。无人机俯拍图上有三种东西和裂缝、坑洞长得极其相似新旧沥青路面的拼接缝、路面标线磨损后的不规则边缘、树荫下呈现深色纹理的普通裂缝状阴影。到底算不算病害不能靠标注员个人感觉否则十个人能标出十种结果。数据集在标注时如果没有给出一套边界样本规则训练出来的模型就会把这些“视觉上像、实际上不是”的目标统统学成裂缝。我处理这类问题时会给标注员一张决策表拼接缝宽度均匀、走向规则、延伸距离长不标拼接缝边缘有局部剥落、明显比缝宽更宽的破损按裂缝标并在备注里说明阴影呈连续条状但没有纹理断裂不标阴影下确实能看到路面材料断裂的按裂缝标。这些边界规则看起来麻烦但直接决定了模型在真实巡检画面里的行为。漏标边界样本模型容易把拼接缝当裂缝误报全标进去又会让模型学到错误的裂缝概念。这个度的把握是数据集质量最重要的分水岭。3.4 多人标注的一致性校验如果数据集是多个人标注的一致性校验环节必须有。最简单的做法是抽5%到10%的图做二次标注对比同一张图上两个标注员画出来的框。我习惯用两个指标校验。一是框位置一致性计算两个人标注框之间的IoU裂缝目标IoU低于0.5就要拉出来复核坑洞目标IoU低于0.7也要复核。二是类别一致性同一目标两个人一个标裂缝、一个标坑洞更是必须全部回炉。实际操作中曲线裂缝的框画法差异很大所以裂缝的IoU阈值我会放得宽一些但类别错误一个都不能忍。4. 拿这套数据训练YOLO系检测器的实操路径4.1 数据划分时最容易犯的“区域泄漏”错误训练数据处理好之后第一步永远是划分数据集。不少人有习惯直接用脚本把所有文件随机打乱按8比1比1拆成训练、验证、测试三份。在这类无人机巡检数据上这个习惯很危险。无人机航拍通常是沿着某条道路航线飞行相邻帧之间高度重叠同一路段会被拍到几十张相似的照片。如果随机打乱同一个路段的照片会被同时分到训练集和验证集模型等于提前看过考试答案验证指标会虚高。等部署到一条全新的路上真实效果立刻打折。正确处理方式是按路段目录、按照片采集时间段落来划分确保验证集和测试集里的任意一张图与训练集里所有图像在地理位置上都不重叠。数据集的批次编号在这个时候就有用了直接按批次切训练集用前几期验证和测试用最后两期这样测出来的指标才反映模型的真实泛化能力。4.2 大图不能直接硬缩切片推理才是正路无人机单张原图通常达到4000×3000甚至更高直接缩放到模型输入尺寸等于把裂缝目标按比例缩小成几个像素模型再强也白搭。拆分思路是训练前先把原图切成1280×1280的tile相邻tile之间留出10%到20%的重叠再喂给模型。切片的最大价值不止是保住分辨率还在于解决了小目标密集的问题。道路场景里大片路面往往没有病害直接全图缩放会让“无目标”背景占绝对主导模型学得很慢。切片之后每个tile里的正样本占比明显提高训练效率完全不是一个量级。切片时要注意同步切标注。如果原图标注是像素坐标直接按tile的坐标偏移换算即可如果数据集本身已经是YOLO格式的归一化坐标可以先还原成像素坐标切完再归一化回去。重叠区域的意义在于目标如果恰好落在tile边界附近只被切成半截模型大概率认不出来留出重叠后同一个目标至少在一个完整tile里出现过检测天然更稳。4.3 训练参数与评估指标的经验设置起步用中等规模的预训练模型最合适。小模型跑得快但对细裂缝这种小目标特征表达能力偏弱超大模型训练慢部署也费劲在嵌入式设备上根本跑不动。以YOLO系列为例我会优先试s或m规格imgsz设为1280batch大小根据显存调整。训练轮次建议设在200个epoch左右配合早停机制。无人机航拍数据集通常样本量不大往往训练到150个epoch左右验证集指标就触顶了继续硬跑反而过拟合。优化器用默认的AdamW或SGD均可但学习率不要图快开大初始学习率调低配合warmup会稳得多。数据增强方面Mosaic和MixUp保留HSV扰动加大饱和度变化范围因为无人机巡检跨季节、跨天时光照差异非常大。评估指标不要只看mAP。裂缝检测场景我更关注两个维度一是小目标的AP直接反映细裂缝检出能力二是置信度阈值变化时误检的数量这一步决定模型上线后会被现场人员骂多少次。另外正负样本极度不均衡是这类数据的常态AP50和AP50-95都要看只看AP50容易被大目标的高分带偏。我还习惯在测试阶段统计每个类别在不同置信度阈值下的检测数量曲线曲线越陡越好。如果0.15阈值下有几百个检测框、0.5阈值下只剩几十个说明模型虽然学了些特征但置信度不稳定落地时要非常谨慎。5. 模型过了验证集真正上路后会遇到的坑5.1 市区巡检现场的误检高发场景模型在验证集上mAP漂亮不代表进了市区就靠谱。无人机航拍市政道路的最大特点是背景极度复杂我把自己反复遇到过的误检场景整理了一下。误检表现常见原因我的处理对策新旧沥青拼接处被框成裂缝纹理断裂形成的连续线状特征与裂缝太像专门收集拼接缝样本做难例挖掘同时降低检测置信度阈值验证真实误检率树影、路灯阴影被框成坑洞深色区域和坑洞颜色特征接近训练时加入更多阴天、逆光、树影覆盖样本必要时用颜色空间特征做后处理过滤车道标线磨损边缘被框成裂缝标线边缘不规则、呈细长条状尝试加入“标线破损”类别或手动收集负样本让模型学会区分井盖、检修孔边缘被框成坑洞圆形边界和深色填充与坑洞高度相似依赖上下文判断训练时不要裁剪掉井盖周围的完整路面结构处理误检的核心思路不是调大置信度阈值阈值调高了裂缝也跟着漏检得不偿失。真正有效的是做难例挖掘把现场误检的图片收集回来补充到训练集里重新训练。这就是为什么数据集要持续更新单靠一次性数据打天下的时代早就过去了。5.2 从单帧检测到连续视频巡检的稳定性处理无人机巡检拍的是连续视频模型逐帧检测时会出现一个很现实的问题这一帧框出来了下一帧又没了来回跳变。给养护部门看的成果如果忽有忽无信任度会大打折扣。我处理跳变会用两个办法。第一个是帧间重叠检测优化因为航拍视频相邻帧重叠率高同一病害在连续几帧里都会被检测到统计每个病害在连续帧里出现的频次出现次数低于阈值的直接丢弃保留高频稳定出现的检测结果。第二个是对检测框中心点做轻量级平滑用相邻帧的位置做均值滤波防止单帧定位大幅跳动。还有一个操作细节病害如果连续几帧都被检测到只需要保留一次检测结果并记录它的首次出现时间和持续帧数。这个信息对后续生成巡检报告很有用一次病害的严重程度不能只看单张照片连续多帧都被模型锁定比单独一张图更有说服力。5.3 输出给养护部门之前你还需要做的一件事检测模型输出的只是像素坐标系里的矩形框养护部门拿到手没法直接派工。要让检测结果真正进入市政养护流程必须把目标框映射到地理坐标。无人机巡检影像本身就带POS数据每一帧图像的位置、姿态都是已知的。检测到病害后取目标框中心点像素坐标结合本帧的位姿数据和相机参数可以解算出病害对应的经纬度。再把经纬度输出成标准表格或工单系统能直接读取的格式养护人员就能带着设备直接去现场复核修补。这一步做不做决定了整个巡检方案是“演示级”还是“生产级”。很多项目卡在最后一公里模型会跑、检测会出但成果落不了地问题就出在坐标映射没有打通。我在项目里习惯把病害中心点的地理坐标作为必填字段和类别、置信度、图像编号一起输出宁可多花一天调坐标转换也不让下游多跑一趟冤枉路。最后分享一个我的习惯模型训练完我从来不看验证集报告直接收工而是带着模型跑一段从没去过的新采集航拍视频模拟一次完整巡检。连续帧上会不会跳变、拼接缝是否误报、细裂缝能不能锁住这些问题只有到了这一轮盲测里才会现原形。数据集是起点但这个起点能不能变成好用的模型最终考验的还是从采集、标注到落地这一整条链路上有没有耐心把细节抠干净。