★ FEATURED ARTICLE 做矿下视觉识别项目时最头疼的往往不是模型结构怎么选而是数据从哪里来。矿井场景光照差、粉尘多、设备杂通用数据集训练出来的检测模型一下井就“水土不服”。我手里这套带标注的矿井下数据集正好覆盖了安全帽、指示器、人、自救器四类目标识别率做到96.3%还同步导出了YOLO、COCO JSON、PASCAL VOC XML三种格式基本属于拿过来就能直接开训的“一站式”资源。下面我把这套数据集的来龙去脉、标注细节、格式用法和训练调优经验全部摊开讲一遍给正准备做矿下安全视觉识别的朋友做个参考。1. 矿下视觉场景最缺的是什么1.1 为什么单独建一套矿井下数据集市面上开源的目标检测数据集不少通用场景的、自动驾驶的、园区安防的都有一大堆但真正贴合矿井下环境的非常少。矿下有几个天然难点一是光照极度不均匀有的区域几乎全黑有的区域被矿灯直射产生强反光二是粉尘和水雾导致图像对比度低目标的边缘经常是糊的三是作业人员穿戴装备后人体的外观特征被大量遮挡只露半张脸或者半个身子是常态。用通用数据集训练的模型在实验室测试效果不错一部署到井下的摄像头画面上漏检率和误检率立刻飙上去。这套数据集就是冲着这些问题来的。图像全部取自真实矿井下的监控画面和巡检抓拍涵盖不同采掘面、不同照明条件、不同粉尘浓度下的场景。也就是说模型从一开始看到的就是“井下长什么样”而不是“马路上长什么样”。对做矿下安全检测的团队来说省掉了大量数据采集和二次清洗的时间直接可以用作基线数据集来跑通整套检测流程。1.2 四类目标选得刚刚好很多人在做矿井安全检测时一上来就想检测十几种乃至几十种目标结果标注成本爆炸类别不均衡严重最终模型什么都想学什么都没学精。这套数据集只锁定四类目标每一类都有明确的业务含义安全帽矿下安全管理的核心对象检测人员是否按规定佩戴。人员判断作业区域内是否有人员活动支撑区域入侵、滞留、跌倒等衍生告警。自救器矿用应急救援装备规定下井必须随身携带。检测自救器是否存在比单纯检测人员是否在场更进一步。指示器巷道内的信号指示设备、仪表盘等用于判断设备状态是否正常也可以作为场景定位和辅助判别的参照物。四类目标的数量配比也做过刻意设计。安全帽和人员属于高频目标样本量最大自救器相对较少但单独扩充了一批正样本指示器形态比较固定样本量适中。这样训练出来的模型在“人员安全帽自救器”组合检测场景下表现最稳这也是矿下安全检查最常用到的组合。如果后续要扩展其他目标类别这套数据集也可以作为基础在预训练权重上做增量训练。2. 标注质量与96.3%识别率怎么来的2.1 数据采集与清洗数据集不是把监控视频随便抽帧就行的。采集阶段要特别注意场景覆盖度不然标注得再认真模型也会因为场景单一而过拟合。我当时整理这套数据时按三个维度做了分层采样不同采掘面掘进面、回采面、运输巷、不同光照明亮区、昏暗区、逆光区、不同作业状态正常作业、检修、交接班聚集。每个维度都保证有足够的样本量避免模型只认某一种固定画面。抽帧之后还要做一轮人工清洗。井下画面里经常有大面积的黑色背景、运动模糊、镜头脏污导致的固定噪点这些低质量图像占比过高时会严重影响训练收敛。清洗规则我定得比较死目标模糊到人眼都难以判断的删掉目标占比过小且没有周围上下文信息的删掉画面严重过曝或过暗导致目标完全不可辨的删掉。清洗后的数据量大概是原始抽帧量的六成左右留下的都是“能看懂、能标注、能学习”的有效帧。2.2 标注规范标注质量直接决定模型性能上限这个环节不能省。四类目标用的都是矩形包围框标注框的贴合度要求比较严格安全帽和自救器这类刚性物体框要贴合目标外沿不能多留背景人员目标在井下经常出现遮挡这时框按可见部分标注保证框内目标主体清晰可辨指示器目标形态相对固定标注时要把整个设备主体包含进去而不是只框其中的指示灯部分。标注完成之后我额外做了一次交叉复核。所有标注结果由两人独立走一遍出现框偏移超过目标尺寸5%的情况就重新调整类别标错的直接打回。这套流程走下来标注质量基本稳定在“可直接用于训练”的水平。很多开源数据集看起来样本量很大但标注质量参差不齐训练时模型很容易学到噪声。数据量固然重要但干净的一致性标注能让每个样本都发挥价值。2.3 评估口径96.3%到底是哪个指标96.3%这个数值需要说清楚口径不然很容易被误读。在目标检测任务里常说的识别率可以是分类准确率、mAP0.5、mAP0.5:0.95等多种指标的俗称。这套数据集的96.3%指的是mAP0.5也就是在IoU阈值为0.5的情况下四类目标的平均检测精度。测试集是独立划分的训练过程完全未使用这部分图像。如果拆开看各类别的AP安全帽和人员的AP都比较高因为样本充足且目标特征稳定自救器的AP略低一些主要受目标体积小和部分遮挡的影响指示器在固定场景下表现很稳但换个光照条件会有轻微波动。所以实际使用时要根据业务侧重点来解读这个数字比如安全告警场景更关心的其实是安全帽的漏检率和自救器的召回率而不只是整体mAP。整体96.3%可以当作数据集的基线能力参考具体到项目交付还是得在自己划分的验证集上做最终评估。3. YOLO、COCO、VOC三种格式一次讲清3.1 YOLO TXT格式的核心YOLO格式是最常见的检测标注格式也是用YOLO系列模型训练时最省事的一种。每个标注文件是纯文本的txt一行对应一个目标框内容依次是类别编号、归一化后的中心点x坐标、中心点y坐标、归一化后的框宽度w、框高度h。所有坐标都做了归一化处理取值范围在0到1之间不受原始图像尺寸影响。0 0.4562 0.3211 0.1204 0.2315 1 0.6231 0.5125 0.0930 0.1879 2 0.7689 0.4410 0.0654 0.1200这里的“归一化”是新手最容易栽跟头的地方。假设一张图的宽是1920高是1080某个目标框的左上角坐标为(600, 300)右下角为(800, 550)那么宽高分别是200和250中心点坐标是(700, 425)。换算公式为x_center 700 / 1920 ≈ 0.3646 y_center 425 / 1080 ≈ 0.3935 box_w 200 / 1920 ≈ 0.1042 box_h 250 / 1080 ≈ 0.2315实测中常见的错误是先算中心点再分别除以宽高结果顺序搞反导致训练时目标框完全错位。还有一种错误是直接用像素坐标写入txt没有归一化模型训练时偶尔能收敛但换一张分辨率不同的图像就彻底失效。在整理数据集时我额外写了校验脚本自动检查每个txt中所有数值是否都在0到1之间超出范围就报警提示省去了大量人工排查时间。3.2 COCO JSON格式的结构COCO格式用单个JSON文件承载所有标注信息结构上分为images、annotations、categories三个顶层数组。images数组记录每张图像的id、文件名、宽高categories数组定义类别列表从1开始编号annotations数组是核心每条记录包含标注框的id、所属图像id、类别id、边界框位置以及分割mask等字段。COCO的bbox格式与YOLO不同它的四个数值分别是左上角x坐标、左上角y坐标、框宽度w、框高度h单位是像素不做归一化。COCO格式最大的优势是生态完善很多检测框架和评估工具原生支持COCO API。用pycocotools可以直接计算mAP、召回率等指标做模型对比时非常方便。缺点是单文件结构放在大样本量场景下会比较笨重比如几万张图像的标注全塞进一个JSON文件里读写速度会明显下降。所以在使用时要先确认数据量级再决定是否需要按子集拆分。3.3 PASCAL VOC XML格式的结构PASCAL VOC格式是最经典的目标检测标注格式每个图像对应一个同名XML文件。XML内部以annotation为根节点包含folder、filename、source、size等基本信息然后是多个object节点每个object节点里记录目标类别name、pose、truncated、difficult以及bndbox中的xmin、ymin、xmax、ymax四个像素坐标值。VOC格式的优点是结构直观用文本编辑器打开就能看懂也方便做逐条检查。很多老牌目标检测项目都基于VOC格式组织数据兼容性很好。但它同样有缺点每个目标的信息分散在多级节点里解析效率比COCO的JSON低数据量大了以后文件数量非常多管理和传输都不够轻量。所以VOC格式更适合中小规模项目、教学演示以及需要人工逐条校对标注的场景大规模训练更多还是用YOLO或COCO。3.4 三格式互转的思路与脚本拿到一套兼容三种格式的数据集实际使用时还是经常要做格式转换因为不同训练框架的输入要求不一样。转换的核心就是围绕“类别ID对应关系”和“坐标表达方式”两个点做映射。以COCO转YOLO为例核心思路很简单从COCO JSON里读出每张图的宽高和目标框的像素坐标然后按归一化公式换算写到对应的txt文件里。import json with open(annotations.json) as f: coco json.load(f) img_info {img[id]: img for img in coco[images]} for ann in coco[annotations]: img img_info[ann[image_id]] w img[width] h img[height] x, y, box_w, box_h ann[bbox] x_center (x box_w / 2) / w y_center (y box_h / 2) / h ann[x_center] x_center ann[y_center] y_center ann[w_norm] box_w / w ann[h_norm] box_h / h with open(labels.txt, w) as f: for ann in coco[annotations]: f.write(f{ann[category_id] - 1} {ann[x_center]:.6f} {ann[y_center]:.6f} f{ann[w_norm]:.6f} {ann[h_norm]:.6f}\n)这个脚本只是最简版本真实项目里还要处理类别ID的偏移COCO类别从1开始YOLO从0开始、图像文件名与标注文件的对应关系、以及验证集划分等问题。VOC转YOLO的路径类似用xml.etree.ElementTree解析XML里的bndbox节点再按同样的归一化方式输出txt。掌握这几种转换逻辑之后不管拿到什么格式的数据都能快速适配到自己的训练框架里。4. 用这套数据集实操一次目标检测训练4.1 组织数据目录拿到数据集之后第一步不是急着训练而是把目录结构整理清楚。YOLO系列的训练框架通常要求图像和标注txt分目录存放且相同前缀名的图像与txt一一对应。我习惯用下面的结构组织datasets/ images/ train/ val/ labels/ train/ val/ data.yamldata.yaml里面定义类别数量、类别名称以及训练验证集的图像路径。矿下场景经常有图像文件名与标签文件名大小写不一致、后缀不一致的情况整理时最好写一个脚本统一检查一遍。train: ./datasets/images/train val: ./datasets/images/val nc: 4 names: [helmet, person, self-rescuer, indicator]检查逻辑包括每个train/val下的图像是否都有对应txt文件反向再查一遍是否有孤立txt读取每个txt里的类别编号是否都在0到3范围内超过就说明标注文件与类别配置不匹配抽查几个框的坐标确认目标大概在图像有效区域内而不是异常偏移。这几项检查做完训练前的数据侧风险基本就控制住了。4.2 训练参数设置训练参数直接影响模型收敛速度和最终精度。我在这套数据集上用YOLOv5系列做测试时比较稳定的配置是输入图像尺寸640×640初始预训练权重使用YOLOv5s训练轮次设置在120到150之间batch size根据显存容量调整单卡12G显存跑batch 16比较稳妥。学习率初始值设为0.01配合余弦退火调度到0.002左右。输入尺寸的选择需要说明一下。640×640是速度和精度之间的平衡点矿下监控画面大多是1920×1080或1280×720原图直接缩放640训练模型能看到足够的上下文信息训练耗时也可控。如果主要检测目标是体积很小的自救器可以尝试把输入尺寸提高到768甚至896但代价是显存占用和训练时间大幅上升需要根据实际显卡条件来权衡。实测下来448输入尺寸在矿下小目标场景会明显掉点1280输入尺寸在部署到低算力设备时又很难跑满帧率所以640在实际项目中性价比最高。训练命令可以直接按官方仓库的标准写法执行python train.py --img 640 --batch 16 --epochs 120 \ --data data.yaml --weights yolov5s.pt --cache--cache参数可以把图像数据缓存到内存训练速度提升明显前提是内存容量足够。训练过程中要盯着loss曲线和验证集的mAP走势正常情况下mAP在前期快速上升后期趋于平缓。如果mAP在中途出现明显震荡优先检查学习率是否过高和数据是否有异常样本。4.3 模型评估与导出训练完成后不能只看训练集的loss要看独立测试集的评估结果。YOLO框架训练完模型后可以运行val.py对验证集做评估输出各类别的AP和整体mAP。拿到结果表之后重点分析哪一类目标AP偏低结合矿下场景推断原因是样本太少、标注不一致还是目标本身过小。这类分析能指导后续数据补充的方向而不是盲目增加训练轮次。模型导出部署时根据目标硬件选格式。常规服务器上跑直接用PyTorch权重即可要接到边缘设备或WEB服务里一般导出为ONNX或TensorRT。导出前务必做一次精度对比确认导出后的模型与原始PyTorch模型的mAP差距在可接受范围内通常差1个点以内算正常差距过大就要检查输入尺寸、归一化方式是否一致。我见过不少项目在导出环节因为预处理不一致导致部署后性能明显劣化。5. 训练过程中的高频问题和排查方法5.1 类别不平衡自救器样本太少怎么办四类目标里安全帽和人员数量多模型学得很快自救器数量相对少前期训练时mAP明显拖后腿。这是典型的类别不平衡问题单纯加训练轮次解决不了。我尝试过几种方案效果比较好的是组合策略。第一对自救器样本做复制粘贴增强把小块的自救器目标随机粘贴到不包含自救器的图像上同时生成新的标注框。这个方法能直接增加正样本数量但要注意粘贴时的尺度合理性和位置合理性不能把自救器贴到墙上或悬在半空否则模型会学到不真实的上下文。第二在loss层面提高自救器类别的权重让模型在训练时对这类目标更敏感。多数检测框架支持按类别设置loss权重在配置里把自救器的权重调高实测能缓解漏检。第三必要时对自救器图像做低保真增强旋转、缩放、亮度扰动让模型学到更多形态变化而不是死记硬背那几张特定图像。5.2 漏检和安全帽误检并存整张图像尺寸偏大且目标密集时漏检是最常见的问题。矿下作业面人员集中安全帽目标小且彼此挨得近模型在默认检测层上经常漏掉一部分。排查顺序从数据开始先看标注框是否完整有没有漏标目标导致模型学到“这些目标不需要检测”的错误信号再看anchor尺寸是否匹配YOLO默认anchor不一定适配矿下目标分布如果目标普遍偏小可以在训练前用k-means算法重新聚类anchor最后再看NMS阈值阈值设置过低容易把相邻的同类目标合并成一个大框导致漏检。安全帽误检又是另一种情况。矿下常有一些圆形设备、管道接头或灯光反光区域外形上和佩戴状态的安全帽有些相似模型就会出现误检。处理误检的思路不能靠调阈值硬压阈值调高了误检少了但真正的小目标召回也会掉下去。正确做法是检查误检区域的共性特征补一批包含这些干扰物的负样本图像让模型见过“这些不是安全帽”的反例误检率会明显下降。5.3 粉尘和低照度下的增强策略矿下场景的粉尘和低照度对模型泛化影响非常大。同一个检测框在明亮环境下识别准确换到粉尘弥漫的画面里就可能失效。数据增强是改善这类场景泛化最直接的手段我把常用增强策略分成两组对照过。第一组是色彩与光照扰动随机调整亮度、对比度、饱和度模拟井下不同照明条件加入高斯噪声模拟低照度下的传感器噪点。第二组是几何扰动随机旋转、平移、缩放、Mosaic增强让模型适应不同视角和尺度。实测在矿下场景亮度扰动和对比度扰动的收益最大因为井下画面跨度从近乎全黑到强反光模型如果只见过中间亮度分布换环境后性能会明显波动。增强幅度要控制好扰动过重会让目标本身都失真强行学反而会降低模型在正常场景下的精度。建议先在验证集上做小规模对比实验找到适合自己数据分布的增强组合。6. 从数据集到矿下实际落地的几个方向6.1 安全监控系统的接入方式数据集和模型最终要落到实际业务里。矿下安全监控系统最常见的接入方式是摄像头采集画面推理服务实时检测检测结果推给告警平台。整体流程一般分为视频流解码、抽帧推理、告警逻辑、结果存储四部分。抽帧策略要根据业务场景定连续检测可以每帧都做但算力消耗高定时巡检则每2秒抽一帧即可矿下人员移动速度不快两秒一帧不会漏掉关键动作。告警逻辑不能只做单帧判定否则姿态变化、瞬时遮挡都会触发误报。我实际落地时做过两次确认机制单帧检测到目标缺失后连续确认3帧再触发告警告警去重用目标所在的检测框区域做匹配同一目标区域短时间内只上报一次。这套机制能把误报率压得很低。模型输出的类别、置信度、框坐标以及摄像头编号、时间戳都要记录下来方便事后回溯和追责。6.2 边缘设备上的推理部署矿下机房环境不一定适合放大型GPU服务器很多项目要求模型跑在边缘设备上。部署时优先考虑ONNX Runtime和TensorRT两条路径。ONNX Runtime兼容性好CPU和GPU都能跑TensorRT在N卡上经过层融合和量化后推理延迟能降低不少。量化是边缘部署时比较关键的一步从FP32量化到FP16精度损失通常可以忽略速度提升明显再往下到INT8就要谨慎了矿下的暗光环境对量化误差敏感需要先做大量实测再决定是否启用。模型输入尺寸在部署阶段也要重新评估。训练用640×640部署时如果边缘设备算力不足可以降到416×416甚至320×320但小目标检测能力会同步下降。实际项目里我一般保留640输入用TensorRT优化来换取速度而不是直接砍输入尺寸。6.3 数据集的可持续迭代数据集不是一次性资源而是需要持续迭代的资产。矿下场景会随着作业面推进、设备更替、光照布置调整而持续变化固定数据集训练的模型在运行一段时间后会出现精度回退。建议在部署系统里设置数据回流机制把现场置信度在0.3到0.7之间的模糊样本、以及告警平台标记的错误样本定期收集起来经过人工复核后扩充到数据集中每1到2个月做一次增量训练。增量训练时要控制新旧数据的比例新样本占比过高容易破坏原有特征建议每次新增数据量控制在总数量的10%到20%用原有数据一起混合训练。长期坚持下来模型会越来越适应当前矿下环境识别率也会逐步爬升。最后说点我的个人体会。做矿下视觉识别项目踩过最大的坑就是一开始迷信模型结构反复折腾网络结构却忽略了一个根本事实数据质量决定了模型性能的天花板。这套带标注的矿井下数据集价值不在于96.3%这个漂亮的数字而在于它把最容易出问题的数据和标注环节已经提前处理好了让你能直接专注于网络调优和业务逻辑。拿到数据集之后建议先花一晚上把图像、标注、格式这三件套完整过一遍跑一次基线训练再根据你实际场景里最关注的类别做针对性优化。矿下环境远比实验室复杂提前把数据底座打牢后续的模型迭代和应用落地都会顺很多。
阅读完成 · 觉得有帮助？
