当前位置：首页 > news >正文

挖掘机检测数据集构建实战：4327张COCO标注与91%识别率

news 2026/8/26 23:08:04

简介：目标检测作为计算机视觉的核心任务，在工程机械自动化监管中扮演着关键角色。高质量的数据集是训练可靠检测模型的基础，而COCO格式凭借其丰富的元信息和广泛的框架兼容性，成为主流选择。然而，通用数据集在挖掘机这类特定设备上存在场景覆盖不足、标注标准不一等问题。为此，围绕工地安全、施工进度管理和保险定损等场景，构建了一套包含4327张真实场景图片的挖掘机检测数据集，统一采用COCO JSON标注格式，并基于YOLOv8m模型训练，最终在测试集上达到91.0%的mAP@0.5。本文从数据采集、标注规范、格式转换到模型调优的完整流程展开，分享了构建过程中遇到的典型问题与解决思路，为需要自制目标检测数据集或开展工程机械识别项目的开发者提供了一套可复用的实践参考。挖掘机检测这几年在工地安全、工程进度管理、保险定损这些场景里需求量一直很大。我做这个数据集的原因也简单：市面上公开的工程机械数据集太散，要么标注格式不统一，要么图片质量参差不齐，真正能拿来直接训练模型、跑通流程的少之又少。所以我自己整理了一套挖掘机检测数据集，总共4327张原始图片，标注格式统一转换成COCO JSON，用主流检测框架训练后准确识别率能做到91.0%。这篇文章就把数据集的构建思路、标注细节、训练参数和踩过的坑完整梳理一遍，给准备自己做目标检测数据集或正在找工程机械数据的朋友提供一个可以直接上手的参考。

1. 数据集背后的真实需求：为什么要单独做挖掘机检测

1.1 挖掘机检测的应用场景与行业痛点

挖掘机在建筑工地、矿山、市政工程里是出现频率最高的工程机械之一。围绕它的视觉检测需求，主要集中在几个方向：一是工地安全监管，通过摄像头识别挖掘机是否进入禁入区域、是否违规靠近高压线或基坑边缘；二是施工进度分析，统计挖掘机的作业时长和空闲状态，辅助项目管理；三是保险理赔和资产盘点，对工地上的挖掘机进行自动识别和计数。

这些场景对模型的要求并不完全一样，但有一个共同前提：得先有一个标注质量可靠、场景覆盖足够广的数据集。我之前尝试直接用一些通用目标检测数据集里的工程机械类别来训练，效果很一般。原因也好理解——通用数据集里的挖掘机样本数量少，角度单一，大多是理想光照下的近景拍摄，真正到了工地现场，扬尘、逆光、遮挡、远景小目标这些情况一出现，模型准确率掉得特别厉害。所以单独构建一个挖掘机检测数据集，不是小题大做，而是工程落地的刚需。

1.2 泛化数据集为什么解决不了实际问题

用公开数据集训练出来的模型在真实工地上为什么不好使？我总结下来有四个层面的原因：

第一，类别粒度不匹配。通用数据集里通常只有“excavator”这一个粗粒度类别，但实际场景中可能需要区分大型挖掘机、小型挖掘机、履带式、轮式，这直接决定了模型的输出能不能满足业务需求。

第二，场景分布偏差严重。公开数据集里很多图片来自网络爬取或自动驾驶街景，拍摄视角以平视为主，而工地监控摄像头通常是俯拍视角，设备尺度差异极大。模型在这种分布偏移下，泛化能力会明显变差。

第三，标注框质量参差不齐。我手工抽检过一些开源数据集的标注，发现目标边界框松紧不一，有的把挖掘机前面的挖斗都截掉了，有的把背景里的塔吊也框了进来。这种标注噪声会直接传导给训练过程，最终表现为模型输出的预测框不平滑、置信度不稳定。

第四，特殊工况样本缺失。夜间作业、雨天泥泞、大扬尘、半遮挡、多台设备重叠这些场景，在通用数据集里几乎是空白，但在真实项目里却非常常见。

所以这个数据集在设计之初，就围绕“工地监控视角 + 多变光照 + 多尺度目标”来构建，尽量贴近实际部署环境。

1.3 数据集的设计目标与规模说明

整个数据集最终包含4327张原始图片，全部为真实场景采集，涵盖了不同型号的挖掘机，部分图片中同时存在多台挖掘机，这给模型训练提供了比较充分的正样本。

标注格式统一为COCO JSON，原因后面会专门讲。数据集的类别设计没有做得特别细，只保留了“excavator”单一类别，因为很多安全监测场景只关心挖掘机的位置，不需要细分型号。从数据分布来看，考虑到目标检测模型训练需要充足的正样本，单类别方案可以让每张图片的挖掘机样本都进入训练，最大化利用有限的图片数量。

这个规模放在工业应用里不算大，但用在模型微调、算法验证、小规模部署上完全够用。如果后续需要继续扩充，可以直接在这个基础上迭代。

2. 数据集构建全过程：从原始图片到COCO JSON

2.1 图片采集与筛选策略

数据集的源头是图片采集。我走的路径是公开来源加自采补充结合，但每张图片都经过人工筛选，确保可用性。

采集过程中我主要做了三件事：

第一，明确场景覆盖清单。在动手找图之前，我先列出必须覆盖的场景维度：室内外、白天黑夜、晴天雨天、近距离中距离远距离、单台多台、静止作业中、正对侧对背对。每一张候选图片都会被标记满足哪些维度，最后统计覆盖率。如果某个维度明显缺失，就定向补采。

第二，控制图片质量标准。筛选时我剔除了分辨率过低的图片（长边小于640像素的基本不用）、严重模糊的图片、目标占比过小的图片，以及带有明显水印或遮挡物覆盖挖掘机主体的图片。另外还特意平衡了正样本和负样本——所谓负样本，就是完全没有挖掘机的工地背景图。这类图片数量不需要多，但一定要有，它能有效降低模型的误检率。

第三，考虑数据多样性。除了挖掘机本身的形态变化，我还关注了背景多样性，包括不同颜色的土壤、不同类型的工地围挡、不同季节的植被环境。这些背景信息会作为上下文特征被模型学习，多样化的背景能减少对特定环境纹理的过拟合。

2.2 标注规范的制定：值得认真对待的一步

标注是整个数据集构建中最耗时、也最影响最终模型效果的环节。我强烈建议在开始标注前，先制定一份书面的标注规范，明确边界框的标注原则。别看这个步骤简单，它能避免标注到后期才发现前后标准不一致、需要返工重标的问题。

我的标注规范里有几条核心原则：

边界框必须包含挖掘机的主体结构，包括车体、驾驶室和履带/轮式底盘，挖斗可以包含也可以不包含，但全数据集必须统一选择。我最终选择包含挖斗，因为挖掘机的作业状态主要通过挖斗体现。
如果挖掘机被树木、围挡或其它设备遮挡超过三分之一，该样本仍然标注，但会被标记为遮挡样本；如果遮挡超过一半，通常直接不标注或剔除。
远景中挖掘机像素高度小于32像素的，不标注。这个阈值参考了COCO数据集中小目标的定义，保证标注目标大小对模型训练有意义。
多台挖掘机紧密并排时，每台挖掘机单独标一个框，不允许合并标注。

这些规则看起来简单，实际执行时还是会出现标准漂移，比如标注到后面逐渐把边界框收窄了，或者把旁边的工人、工具误包含进来了。所以定期抽检标注结果，发现偏差及时纠正，很有必要。

2.3 COCO JSON格式逐字段拆解

标注完成后，所有标注结果被汇总成一个COCO JSON文件。COCO格式之所以在目标检测领域这么流行，是因为它比简单的XML或TXT格式信息更完整，结构统一，适配大部分现代检测框架。

一个标准的COCO格式JSON包含三个顶层数组：images、annotations、categories。

images数组里的每个元素描述一张图片，核心字段包括：

id：图片唯一标识，从1开始递增
file_name：图片文件名
width：图片宽度
height：图片高度

annotations数组里的每个元素描述一个标注目标，核心字段包括：

id：标注的唯一标识
image_id：指向所属图片的id
category_id：指向所属类别，这里是“excavator”对应的id
bbox：[x, y, width, height]，即目标边界框的左上角坐标和宽高
area：边界框面积，等于width乘以height
iscrowd：这里固定为0，表示单实例标注

categories数组就简单了，一个类别一个条目，包含id和name字段。如果是多类别数据集，就依次列出。

这里有一个容易出错的地方：COCO格式中bbox的坐标是以像素为单位的绝对坐标，x和y是边界框左上角在原图中的位置。很多人在把其它标注格式转成COCO时，会把坐标搞成归一化值，或者在缩放过图片之后忘了同步修改标注坐标，导致训练时出现大量越界框。转换时最好写一个脚本自动校验，确保所有bbox都在图片范围内。

2.4 标注工具选型与质量校验方法

标注过程中我用了两套工具配合。

第一轮标注用X-AnyLabeling，它支持多边形和矩形框标注，也支持COCO格式的直接导出，效率比较高。第二轮抽检用的是LabelImg，主要用来快速查看XML格式的标注结果，交叉验证一下。

如果你的标注量大且预算充足，可以试试CVAT这类在线标注平台，支持多人协作和自动标注辅助。但个人使用场景下，本地方案更灵活，不需要额外部署服务器或上传数据。

标注完成后的质量校验，我推荐从三个维度做：

几何校验：检查是否存在空标注文件、bbox坐标超出图片范围、bbox宽度或高度为0。
可视化校验：把标注框画在图片上，随机抽500张人工观察，重点看边界框是否贴合目标轮廓、有没有错漏标。
统计校验：统计所有标注框的面积分布、宽高比分布，看有没有异常值。比如挖掘机的宽高比通常集中在0.8到2.0之间，如果某个样本的宽高比到了5.0，大概率是标错了。

2.5 为什么选择COCO JSON而不是其它格式

我知道很多人习惯用YOLO的TXT格式来训练，毕竟YOLO系列是目前目标检测的主流工具。但我还是坚持把数据集的主格式定为COCO JSON，主要有几个考虑：

第一，兼容性更好。YOLO格式虽然方便训练，但很多数据增强工具和模型评估工具只认COCO格式。使用COCO JSON作为主格式，需要YOLO格式时用脚本转一下就行，反过来也一样，但主格式的兼容范围明显更宽。

第二，COCO JSON自带更丰富的元信息。比如每张图片的宽高、每个标注的area、iscrowd，这些信息在做数据分析和模型评估时可以直接用，不需要重新从图片里读取。

第三，生态成熟。Detectron2、MMDetection、PaddleDetection这些主流框架都原生支持COCO格式，OpenMMLab的评估工具也直接支持COCO的AP计算逻辑。选择COCO JSON，相当于省去了一堆适配工作。

3. 基于该数据集的模型训练与调优

3.1 训练方案的选型：框架、模型与超参

数据集准备好了，接下来就是训练。这个数据集我在多个框架上都跑过，包括MMDetection、YOLOv5、YOLOv8，整体表现稳定。这里以YOLOv8为例，讲讲训练细节，因为YOLOv8在易用性和性能之间平衡得很好，对个人开发者和中小团队最友好。

模型版本选择上，我用的是YOLOv8m。为什么不用更轻量的YOLOv8n或更重的YOLOv8x？这是实际对比后的结果。YOLOv8n参数量最小，推理速度最快，但在小目标检测上效果明显差一些；YOLOv8x准确率最高，但对显存的消耗也大，推理速度慢，部署成本高。YOLOv8m达到了一个比较理想的平衡点，在RTX 3060级别的显卡上训练也完全跑得动。

输入分辨率方面，我设置了640x640。这个设置对挖掘机检测场景来说默认够用。如果后续要进一步提升小目标检测效果，可以考虑在训练时用1280x1280。但注意，分辨率提升会明显增加训练和推理耗时，需要根据实际部署设备的算力来权衡。

其它关键的训练超参数如下：

优化器：SGD，momentum设置为0.937
初始学习率：0.01，采用余弦退火调度
batch size：16
训练轮数：300轮（含预热阶段）
数据增强：开启Mosaic、翻转、色彩空间调整、平移旋转等

3.2 数据划分与训练细节

数据划分我采用了8:1:1的比例，即3462张训练、432张验证、433张测试。划分时使用了随机种子保证可重复性，但划分之前先做了按图片分组的处理，确保同一场景下的连续帧图片不会被分到不同集合里，避免数据泄漏。

训练过程中我加了一个额外策略，就是先把预训练权重加载进来，在训练集上做50轮的冻结骨干网络训练，再解冻所有层做完整微调。这样能加快收敛速度，也能让模型在特征提取阶段就掌握通用的视觉特征。

另一点值得提的是验证集的使用方式。训练过程中每一轮都会在验证集上计算mAP@0.5，并保存最佳权重。最终测试阶段，用测试集对最佳权重做最终评估。这个流程能有效避免仅凭训练损失就判断模型好坏导致的误判。

数据增强方面，我开了Mosaic增强，但在训练后期关闭了。原因是Mosaic虽然能显著提升模型对不同尺度和上下文的理解能力，但持续开启也会让模型在真实图片上的表现略微下降。很多训练框架都支持在最后十轮关闭Mosaic，这个细节能稳定提升最终精度。

3.3 91.0%识别率是怎么得来的：评估细节与指标解读

数据集标题中提到的91.0%准确识别率，指的是模型在测试集上的mAP@0.5指标。mAP@0.5的含义是，当预测框与真实标注框的交并比（IoU）大于0.5时，认为该检测结果正确，然后计算所有类别的平均精确率。

之所以用mAP@0.5作为主要衡量指标，是因为它更贴近实际业务场景中的判定标准。在工地安全监控里，只要模型能在目标周围给出一个合理位置的框，就算检测成功，不要求边界框像精细分割那样严丝合缝。当然，我也同时计算了mAP@0.5:0.95作为参考，这个指标更严格，它对边界框的定位精度更敏感。最终两个指标都表现不错，说明模型不仅有较高检测率，定位精度也过关。

如果你在自己的数据集上训练，需要注意一个容易误解的地方：91.0%是mAP@0.5，不代表准确率有91.0%。准确率和mAP是两个评价维度，准确率关注的是检测出来的结果中有多少是正确的，而mAP同时考虑了精确率和召回率。在目标检测任务里，mAP才是更通用的评价标准。

3.4 测试结果实测记录

分享一组我在测试集上的实测结果，方便大家对比参考：

mAP@0.5：91.0%
mAP@0.5:0.95：67.8%
精确率：88.5%
召回率：89.2%

这个精度水平在单类别目标检测数据集上属于中等偏上。考虑到数据集包含大量远景小目标和遮挡样本，我对这个结果还是比较满意的。

要注意的是，不同框架的训练结果会有细微差异，YOLOv5、YOLOv8和MMDetection哪怕用相同的数据集和类似超参，最终指标也会有一两个百分点的浮动。这属于正常现象，不用过度纠结哪个框架一定最好。

4. 常见问题与排查技巧实录

4.1 标注阶段的坑

我把标注过程中遇到的最典型的几个问题列出来，这些坑几乎每个做数据集的人都会踩到。

第一个是标注边界不统一。标注员可能今天按包含挖斗的方式标，明天就只标车体了。这种问题只能通过制定规范加定期抽检解决，没有捷径。我在标注过程中做了两轮全量自查，第一次在标注完成50%时，第二次在全部完成时。

第二个是多目标遮挡时的标注取舍。两台挖掘机重叠时，是只标前面那台，还是两台都标？如果只标前面的，后面的被遮挡部分算不算漏标？我的处理方式是：可见度超过50%的目标都标，并保留完整的边界框，让模型自己去学习遮挡情况下的目标特征。这种方法在实践中效果不错，模型在遮挡场景下的召回率没有明显下降。

第三个是背景误标。挖掘机旁边经常有吊车、装载机、推土机等其它工程机械，外形有一些相似之处。如果没有统一的类别清单，标注员很容易把其它机械也误标成挖掘机。所以在标注规范里我明确列出了挖掘机与相似机械的区分要点，比如挖掘机的标志性结构是驾驶室和挖斗。

4.2 训练阶段的坑

训练时常见的问题集中在数据集格式转换、类别配置和数据加载上。

YOLO格式与COCO格式转换时，最容易出错的是归一化坐标计算。YOLO格式里bbox的坐标值是相对图片宽高的比例值，范围是0到1，而COCO格式是绝对像素值。转换时稍微不留神，就会把相对值当绝对值用，结果就是模型训练时损失函数异常。建议写一个转换脚本，转换后做一次可视化验证，确保框的位置正确。

类别配置也很容易埋坑。COCO格式的category_id从1开始，而YOLO格式的类别编号从0开始。如果直接用脚本转换但不做偏移处理，类别就会全体错位。这个错误在单类别数据集上不容易被发现，因为只有一个类别时偏移了也看不出来，但一旦后续扩充类别，问题就会爆发。

数据加载方面，有时候训练中断后重新开始，发现模型不收敛，排查了半天结果是数据加载器里混入了格式损坏的图片。所以训练前对数据做一次完整性校验很必要，我写了一个简单的脚本，循环读取所有图片文件，发现无法解码的就列出来单独处理。

4.3 落地部署阶段的坑

训练好的模型部署到真实场景时，也有一堆问题需要处理。

最典型的是推理速度与精度的权衡。在边缘设备上跑YOLOv8m，如果算力不够，帧率会很低，根本没法实时检测。这种情况下可以考虑换成YOLOv8s或YOLOv8n，同时把输入分辨率从640降到480，牺牲一些精度换取速度。如果还是不够，就需要用TensorRT或OpenVINO做模型加速，一般能带来1.5到3倍的推理速度提升。

另一个常见问题是模型在真实场景中的误检。训练数据里没有足够多的相似机械负样本时，模型很容易把吊车或装载机误判为挖掘机。解决办法是收集一批困难负样本，加入到训练集中重新微调。这个过程可能要反复几次，每次加入几十张到几百张真实环境下的负样本，模型的误检率就会明显下降。

还有一点是场景变化带来的性能衰减。模型在晴天训练效果好，一到雨天或者夜间，检测精度就会下降。这种问题没有一劳永逸的解决方案，只能通过持续收集新环境的数据并做周期性微调来缓解。