无人机、路面坑洼检测、目标检测这三个词放在一起很多人第一反应是“不就是拿相机拍路嘛”。但真正做过落地项目的人心里清楚这条链路每一步都是坑无人机飞多高才能兼顾覆盖率和分辨率光照和阴影怎么处理坑洼和阴影怎么区分裂缝细到几个像素了还能不能标标注完的数据喂给模型又该怎么调参才不掉点。这套流程我前前后后跑了三个多月中途返工重标了两次才攒出一个能用的数据集。这篇就把整个过程中的设计思路、标注细节、训练实测和踩过的坑一次性说透。1. 为什么无人机路面检测需要专门的数据集路面损伤检测这件事传统做法是人工巡检或者车载相机巡检。人工巡检的痛点显而易见人走路看路的覆盖效率太低高速公路几十公里跑下来要耗费大量人力时间而且每个人对“损伤”的主观判断标准还不一样不同人复检结果经常对不上。车载相机的问题在于视角太矮对坑洼的立体深度感知很弱两轮之间的小坑很容易被车体遮挡而且汽车能到达的路段本身就有限桥下、边坡、封闭施工区域这些地方根本进不去。无人机把视角抬到了空中视角变化带来的问题也随之而来。同一处坑洼无人机在20米高度看到的特征和30米高度完全不一样云层飘过导致的阴影变化会让模型把阴影误判成凹陷路面标线、修补痕迹、水渍在俯视视角下展示出来的形态也大相径庭。这套数据如果直接拿公开的地面车载数据来训练在无人机视角上实测精度会断崖式下跌。这背后是典型的域偏移问题——训练数据的分布和实际应用场景的数据分布不一致。所以这个数据集的定位从一开始就很明确专门服务无人机低空视角下的路面坑洼检测任务目标是让模型在看惯了俯视路面影像之后能够稳定识别出坑洼、裂缝、修补区域这三类核心损伤。面向的受众也不只是做路政养护的团队还包括做智慧城市巡检、港口码头地面管理、园区内部道路巡查、还有做无人机算法开发的公司。如果你正在做类似的方向或者正准备给手里的无人机加装一套视觉识别能力这套数据集的构建思路可以直接拿去做参考。2. 数据集的整体设计与构建思路2.1 数据维度与场景覆盖规划设计数据集的第一步不是急着采集素材而是先把“这个数据集要给模型解决什么问题”完全想清楚。我当时的做法是先拉一张需求清单列清楚模型上线后要见的场景再往回倒推数据集该怎么设计。在场景覆盖上我把路面状况切成了这几个维度天气与光照条件晴天直射、阴天漫射、晨昏侧光、路面材质沥青、水泥、碎石、损伤程度微裂缝、中度坑洼、严重损毁、背景复杂度干净路面、有标线、有落叶杂物、有积水反光。每个维度都对应着实际巡检中一定会遇到的状况漏掉一个模型在真实场景中就会多一类致命失误。航线高度也是一个必须单独考虑的变量。无人机太低单张图片覆盖区域小巡检一遍的成本会翻几倍飞太高坑洼在画面中只占十几个像素检测网络根本提不到有效特征。所以采集过程中我把高度分成了15米、20米、30米三个档位对应着不同巡检任务对分辨率的需求。俯仰角上则主要保持60度到90度垂直向下之间——平视视角对无人机巡检没有参考价值但是带一点角度可以让坑洼的侧壁结构显现出来对深度判断有帮助。2.2 采集设备与环境选择设备方面我用的是行业级四旋翼无人机搭配4K云台相机镜头焦距等效24mm传感器尺寸1英寸。这套组合的优点是画质好、畸变可控、云台稳定精度高缺点是机身和载荷都偏重一些续航被压到只有25分钟左右。经验是宁可多备两块电池也别图轻便换小传感器——坑洼检测属于典型的小目标检测任务传感器画质直接决定了你能不能在小像素区域分辨出纹理突变。采集环境选择上我划了几个典型的区域一段车流量少的郊区柏油路、一段老化的水泥厂区道路、一个刚做完全统一样画线的路口区域、还有一段有明显修补痕迹的旧路面。选择这些地点不是随机拍的而是因为路上能收集到的损伤类型在形态上有明显区分裂缝集中在涂层老化集中的区域坑洼出现在重车碾压多的路段修补区域则集中在管线开挖过的地方。2.3 数据预处理与质量控制原始视频材料回传到电脑后先按帧抽图。抽帧策略不是均匀抽取而是以“画面中出现目标区域”为触发条件进行场景切换抽取——云台在转动时画面是虚的均匀抽帧会混入大量模糊图白白浪费标注产能。抽出来的有效帧再经过三重筛选清晰度不足的去掉、目标占比过小的去掉、和已有样本视觉重复度太高的去掉。最后保留下来大约4200张有效图片每张分辨率控制在4000×3000左右处理后统一缩放到1280×1280用于训练。2.4 数据集结构划分划分训练集、验证集、测试集的时候我特别强调了一个原则同一路段的连续帧必须放进同一个集合不能随机散落到训练集和测试集两边。原因是无人机连续拍摄的抽帧之间高度相似如果同一场景的图两边都有模型在测试集上的表现会虚高看起来精度很漂亮实际上泛化能力根本没有验证到。按照路段分组后最终的比例大约是训练集2900张、验证集700张、测试集600张。3. 标注规范与质量把控3.1 标注类别定义标注是整个数据集构建过程中矛盾最集中的环节。团队内部对“什么样算坑洼”“裂缝和正常路面纹理的分界线在哪里”争论过很多次。最后我们定下来的类别定义是这样的pothole路面材料脱落形成的凹陷有明显边界底面与路面的高度差肉眼可辨最小判定尺寸是长边不小于15像素。crack线状损伤单条或多条分支宽度1像素以上、长度30像素以上才允许标注宽度过小的纹理噪声不标。patch人工修补区域应为在影像中与周边新旧程度有明显差异、边界清晰可见的矩形或不规则区域。类别定义看起来简单实际执行才是难点。裂缝的末端往往是渐隐的标注员很难判断该在哪里收笔坑洼的阴影边缘容易截断成一条假裂缝修补区域如果修得比较精细和原路面的色差其实很小。这些情况如果不提前统一标准三个人标出来的框可能完全不在一个位置上。3.2 标注工具选择与流程配置标注工具用的是某开源图像标注平台功能覆盖框选标注、多边形标注和分类标签支持多人协同。我们在平台里配置了固定的标签体系并且关闭了自定义标签权限防止标注员手滑打错类别名。每条标注记录必须包含图片ID、类别、四角坐标、归属标注员ID以及一条可选的备注字段用于记录模糊边界的情况。标注流程上我设定的是两轮标注加一轮复核。“两轮”指原始标注员完成标注后第二位标注员完全独立地对同一批图重新标一遍然后通过脚本计算两份标注的IoU交并比两者低于0.5的样本强制进入人工仲裁。这一步在实操中非常关键否则你以为标注完成了实际上不同标注员之间对标准的理解差异根本没有被暴露出来。仲裁由我本人完成逐张核对差异较大的样本确认后把统一意见同步为标注规范的新增条款。3.3 质量评估与抽查标注完成后做了一次覆盖全量的自动校验检查四项指标目标框是否超出图像边界、坐标是否出现负值、类别是否在合法集合内、像素面积是否低于最小容许尺寸。自动校验通过后再采用随机分层抽样每类抽取约100张图人工复查。坑洼类复检平均精度达到96.2%裂缝类偏难一些93.8%修补类因边界较多只有90.5%于是针对修补类做了一次定向返工。一个我在实际操作中体会特别深的点不要只盯着平均精度看单类精度才是真正的镜子。整体精度被大类拉高之后小类目标的质量问题很容易被平均数掩盖。复查一定要按类别分层抽样单独看每一类的精度到底多少。4. 目标检测模型训练实测4.1 模型选型与训练配置数据集最终的检验方式还是要放进模型里跑一遍看能不能稳定检测出三类目标。模型选的是YOLOv8m这个中等体积的版本权重初始化用MS COCO的预训练模型。选择YOLO系而不是两阶段检测器的原因是无人机巡检应用对端侧部署要求很高YOLO在推理速度、模型体积、精度三者之间的平衡性最好后续转到TensorRT量化也更平滑。训练时输入尺寸定为1280×1280batch size设了8初始学习率0.01使用SGD优化器配合余弦退火调度总共训练了180个epoch。显存方面单张推理卡即可跑通实测下来20G显存是起步配置如果你手里的卡只有8G那输入尺寸必须降到960或者调低batch size否则会直接爆显存。这里有一个细节值得多讲一点训练前做数据增强策略的时候我刻意没有使用随机旋转和水平翻转。原因很直接——无人机在没有特殊任务的时候基本都是保持一个大致朝向飞行的横滚视角的样本在实际采集数据里占比很小。如果大量使用旋转增强相当于人为制造了模型在真实部署时几乎遇不到的视角样本这些增强数据不仅不会提升精度反而可能引起边界误判。4.2 训练过程与精度表现训练过程中的收敛情况比较理想前60个epoch内各类损失都在快速下降到120个epoch之后损失曲线基本平稳。最终在测试集上的mAP50表现是0.612mAP50-95是0.394。这个数字看起来不算惊艳但你要考虑到三类目标的形态差异坑洼和裂缝是两种截然不同的视觉结构一起优化本身就要互相妥协加上无人机俯拍视角下的目标平均像素又小能跑到这个水平已经具备初步实用价值。把类别分开来看坑洼类精度最高mAP50到了0.68左右。原因是坑洼边缘在俯视下有明显的阴影过渡特征相对稳定。裂缝类差距比较大mAP50在0.52附近核心难点在于裂缝在40米高度下往往只有两三个像素宽特征太细很容易被背景纹理干扰。修补类介于两者之间mAP50约0.56。4.3 推理速度与部署评估推理速度上在单张推理卡上跑TensorRT FP16的批处理耗时大约是每帧23毫秒换算下来接近43FPS的吞吐能力。单纯看算力绰绰有余但实际部署在无人机边缘设备上时还要打折扣因为边缘设备的算力通常只有推理卡的十分之一不到而且还要同时承担飞控、图传、避障的计算任务。如果用Jetson级别的低功耗设备实测推理耗时大约在90~110毫秒单帧处于勉强可用的边缘状态。一个我在实际使用中的经验目标检测模型在数据集上的指标只能证明“有潜力”真正落地还要看两个容易被忽视的指标——小目标召回率和误报率。坑洼检测这类任务里误报比漏检更让人头疼因为漏检可以靠多飞几个架次补误报会让人工复核的人疯掉。如果误报太高宁可牺牲一部分精度也要把置信度阈值往上拉。5. 常见问题与排查技巧实录5.1 标注阶段典型问题汇总标注阶段的总耗时远远超出预期问题集中在下面几个点第一个高频问题是“阴影当作坑洼”——阳光斜射时路面上凸起的颗粒或者标线会在下风方向拖一条阴影阴影形状恰好是圆形或者椭圆形标注员会惯性当成坑洼框出来。这类错误在晴天晨昏拍摄的图片中占比特别高。应对方案是要求标注员开启原图的阴影增强显示同时观察目标区域的纹理连续性——坑洼底面是有材料质感的阴影区域内原有内容仍然可辨。第二个高频问题是裂缝和多条裂缝的合并关系。裂缝交错成网状时标注员经常标成多个检测框实际上分支裂缝属于同一个损伤区域。这种问题在IoU仲裁环节根本发现不了因为两份标注可能都很“准”只是对“一个目标还是多个目标”的理解不一致。我后来在规范里加了明确约束裂缝主干和分支之间的夹角小于30度时视为同一目标大于45度且具有独立延伸方向的视为两个目标。第三个问题是坑洼与修补区域的混淆。老化的修补材料经过一段时间后会碎裂碎裂区域周边又出现了新坑洼视觉上边界互相重叠。规范上的处理逻辑是修补材料覆盖的范围全部归patch材料边缘外新生成的破损区域如果是独立的凹陷可以标为pothole但框不能跨过patch边界。5.2 训练过程遇到的问题记录训练阶段最让团队头疼的是裂缝类目标的前景背景不平衡问题。裂缝在一张1280×1280的图中可能只占几十个像素损失函数中正负样本的比例严重失衡模型训练倾向把所有区域都预测为背景导致裂缝类的召回率极低。我尝试过调整损失函数里的正样本权重参数把裂缝类的前景权重提高0.5个数量级召回率略有提升但坑洼类的误报率同时上升了不少。最终采取的组合方案是平衡采样加裁剪增强从训练集中裁出包含裂缝的小块区域单独作为增强副本加入训练同时把这些区域的复制次数加大到正常样本的三倍。这个操作让裂缝类的召回率从初始的41%提升到了59%代价是多花了大约30%的训练时间但效果确实明显。还有一个值得记录的调试经验是关于分辨率选择的。最开始实验用过640×640的输入尺寸训练速度快但坑洼小目标在特征图最后一层的下采样倍数下只剩大约2×2像素基本属于不可检测范围。升到1280×1280之后小目标对应的特征图面积扩大到16倍检测能力直接质变。代价是显存占用大幅上涨训练时间几乎翻倍但为了小目标检测效果这个代价是必须付的。5.3 实际部署中出现的问题部署到无人机平台联调时出现了一个很有意思的现象视频流中相邻两帧对同一个坑洼的检测结果不稳定上一帧检测到、下一帧又丢失导致画面里检测框闪烁。模型精度没有问题问题在于视频流推理时每一帧是独立的模型对检测对象边缘处的目标天然存在置信度波动置信度一旦越过阈值就会出现抖动。解决思路有两个方向一是调低置信度阈值让边缘状态的目标也能通过检测但这样会多出很多误报二是加入时序平滑机制视频流中连续三帧有超过一帧检测到目标就保持显示连续丢失超过三帧才判定目标确实消失。实际部署时我选了第二个方案并且把检测框的坐标做了一次均值滤波显示稳定性提升非常明显。6. 从数据集到工程落地的几点心得回到最初的问题无人机计算机视觉数据集到底应该怎么建才能对落地有实际价值我觉得最关键的一点是数据集构建必须以终为始从模型部署的真实场景往回推需要什么数据、什么标注、什么质量标准。如果只是把图收集回来、标注完、训练完就结束那这个数据集只能写在报告里如果你的目标和我一样是做出实际能用的方案那每一步都要以部署场景为准绳去校准。成本和规模之间也有一笔账要算。数据集的规模取决于目标任务本身的复杂度而不是盲目追求数量。4200张图够不够用从实验结果看训练出的模型已经具备了初步可用性但要达到真正稳定商用的水平至少还需要再翻一倍的数据量尤其是裂缝类的数据。标注成本在整体项目中占到的比重比很多人想象中高得多一个熟练标注员一天有效标注量大约只有150张图左右——对你没看错就是这么低——所以数据预算的大头往往在人工标注上采集反而只是一小部分。最后分享两个我后来才知道的扩展方向。这个数据集不仅可以用来训练目标检测模型还可以抽出一部分数据做语义分割标注把坑洼的边界从矩形框细化到像素级。分割模型的检测精度不一定比检测框高但它能提供更精确的磨损面积信息对工程养护的施工量核算价值很大。另一个方向是用合成图像来做数据扩充——用3D渲染引擎生成路面损伤的仿真图片配合域随机化技术可以大幅补充卷积网络对极端光照和雨雾天气的适应能力真实数据加仿真数据结合是解决数据短缺的重要解法。如果你手头正在规划类似的数据集这两个方向值得尽早考虑进去。