简介面向计算机视觉与深度学习开发者这份工程车目标检测数据集可用于训练YOLOv8模型。资源聚焦施工车辆场景覆盖装载机、搅拌车、挖掘机、拉土车等多类工程车适合智慧工地、车辆识别与交通管理等项目实践。压缩包共2000个文件含661张JPG图片和1338个配套TXT标注文件YOLO格式以及1个YAML配置文件总大小约92.06MB目录组织清晰便于数据划分和批处理可快速接入YOLOv8训练流程。作为带标签的完整数据集读者可直接用于模型训练与验证省去自行采集和标注的时间同时也有助于理解目标检测标注格式、数据组织方式和模型调参过程。多样化的施工场景样本可为模型提供不同角度、光照和遮挡条件下的训练数据从而提升检测鲁棒性。目前已有762人学习下载适合希望动手训练目标检测模型、积累工程车识别经验的学习者与算法工程师。1. 施工车辆识别不是“多个单类模型”是数据工程问题工地上需要识别的不只是“有没有车”而是车里到底是装载机、搅拌车、挖掘机还是拉土车。同样是黄色车身、同样停在基坑边上挖掘机和装载机的轮廓差异没有想象中那么大单靠“运动检测 轮廓判断”的规则方案在扬尘、逆光、夜间补光不足的现场基本会翻车。一个反直觉的结论是这类工程车识别项目模型训练只占两到三成工作量真正决定上线效果的是数据采集、类别定义和标注一致性——也就是把“工地场景”翻译成“YOLOv8 能学懂的标注样本”的过程。这篇笔记面向准备用 YOLOv8 落地施工车辆识别的开发者覆盖准备数据集、训练参数、损失曲线排查、边缘设备部署以及一些只有跑过工地数据才会遇到的坑。2. 先把工地场景变成YOLOv8能学的东西数据采集、清洗与标注2.1 类别定义越细模型越难收敛先想清楚识别边界不少项目在需求阶段就把类别写成了“装载机、搅拌车、挖掘机、拉土车”但到了标注现场才发现同一个“搅拌车”在不同工地长得并不一样有圆筒搅拌罐的混凝土搅拌车也有带臂架的混凝土泵车拉土车可能是重型自卸车也可能是农用翻斗车。类别定义得越细模型收敛越慢、误检越多。常见做法是先把大类定死每类独立建模不搞子类。比如“挖掘机”就统一覆盖轮式挖掘机和履带式挖掘机“装载机”统一覆盖铲斗装载机和滑移装载机而搅拌车只指带搅拌罐的车型。如果现场还需要区分泵车那就单独再加一个类别不要放在搅拌车里混着标。类别数量直接决定数据量下限。单类起步建议不少于 500 张有效样本四类一起做的时候每类至少 800 到 1000 张且要覆盖不同角度、不同距离、不同光照。纯靠网上下载的图片训练到现场基本是“训练时准确、测试时崩”的状态因为工地背景和网络图片背景差异太大。比较好的采集组合是工地自有监控截图占六成现场补拍占两到三成网络图片只做补充。2.2 标注一致性检查同一个目标两个人的框不一样数据清洗不只是删模糊图。检测模型对标注框的抖动非常敏感同一辆挖掘机一个人框的是整车含挖臂另一个人只框了车身模型就会学出两个互相打架的“挖掘机模板”。标注前要定死一套规则并写进任务说明里装载机、挖掘机这类带工作臂的车辆框必须包含完整工作臂和铲斗不能只框主体搅拌车的框包含搅拌罐和车头但不能把后方正在作业的泵管框进去拉土车如果正在卸货车厢翘起状态也要框成完整车体。筛选标准上目标像素小于 32×32 的样本直接扔掉运动模糊、逆光到看不清轮廓的图不保留。用 Labelme 标注完成后建议写个脚本统计每张图的框宽高分布把异常大的框、超出图像边界的框、宽高比小于 0.2 或大于 5 的框全部列出来人工复查。2.3 从Labelme标注到YOLO格式转换脚本与四个边界坑Labelme 导出的是 JSON 格式YOLOv8 训练需要的是 txt 格式每行一个目标格式为class_id x_center y_center width height坐标全部归一化到 0 到 1。转换脚本的核心逻辑是读入 JSON 里的shapes提取多边形边界框并换算。下面是一个可直接使用的转换脚本import json import os from glob import glob def convert_labelme_to_yolo(json_path, class_names, output_dir): with open(json_path, r, encodingutf-8) as f: data json.load(f) img_w data[imageWidth] img_h data[imageHeight] lines [] for shape in data[shapes]: label shape[label] if label not in class_names: continue class_id class_names.index(label) points shape[points] xs [p[0] for p in points] ys [p[1] for p in points] xmin, xmax min(xs), max(xs) ymin, ymax min(ys), max(ys) # 归一化并转为中心点坐标 x_center (xmin xmax) / 2 / img_w y_center (ymin ymax) / 2 / img_h width (xmax - xmin) / img_w height (ymax - ymin) / img_h lines.append(f{class_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) txt_path os.path.join(output_dir, os.path.basename(json_path).replace(.json, .txt)) with open(txt_path, w) as f: f.write(\n.join(lines)) class_names [loader, mixer, excavator, tipper] json_files glob(labels/*.json) os.makedirs(labels_txt, exist_okTrue) for json_file in json_files: convert_labelme_to_yolo(json_file, class_names, labels_txt)这段脚本里最容易踩坑的是两处一是 Labelme 的多边形点数可能超过 4 个直接取点的 min/max 生成外接矩形是合理做法二是归一化后坐标位数保留 6 位小数足够太多反而让 txt 文件变大。上面提到的边界坑分别是图像 EXIF 方向导致宽高读取不一致、JSON 中有重复 label 名、多边形自交叉导致坐标出现负数、输出目录和原图目录不一致导致训练时找不到对应 txt。前三个靠脚本内做异常判断或人工复查解决第四个要靠固定的目录组织来避免。2.4 用随机翻转和 HSV 增强模拟工地光线变化工地的光照条件远比网络数据集复杂正午强光、傍晚逆光、夜间补光、雨天泥水反光都会影响检测。数据增强是弥补样本量不足最省钱的手段。建议在dataset.yaml文件里做配置而不是预处理阶段手工增强——YOLOv8 训练时会自动在每次迭代中做增强相当于每一轮都在用不同的“虚拟样本”训练这比离线扩充图片更省显存和磁盘。# dataset.yaml path: /data/construction_vehicle train: images/train val: images/val nc: 4 names: [loader, mixer, excavator, tipper] # 训练参数中增强相关项 # fliplr: 0.5 左右翻转 # hsv_h: 0.015 色相变化幅度 # hsv_s: 0.7 饱和度变化幅度 # hsv_v: 0.4 亮度变化幅度工地场景我一般会把hsv_v调高到 0.4模拟早晚逆光和夜间灯光下的亮度变化hsv_s调到 0.7因为工地上的黄色、橙色工程车在灰尘覆盖后饱和度变化极大。fliplr保持默认 0.5 即可。千万别开mosaic以外的随机裁剪增强工程车经常只有一辆在画面中央裁剪会把目标切掉一半。3. 用YOLOv8训练工程车识别模型参数取舍与损失曲线解读3.1 训练命令与模型选型n/s/m 三种规模的差距YOLOv8 提供yolov8n.pt、yolov8s.pt、yolov8m.pt等预训练权重。选择哪个不是看显存够不够而是看部署端能承受多大算力。工地边缘设备如果是 rk3588 这类芯片建议直接训练yolov8s或yolov8n如果是服务器推理或性能足够高的工控机可以上yolov8m。单从工程车识别精度看n到s的提升最明显s到m的提升会迅速变小而推理耗时则成倍上涨。我的经验是先用yolov8s跑通全流程记录 baseline再判断是否值得为那 2% 的 mAP 换m模型。# 训练前先确认数据集目录结构 # images/train 和 labels/train 一一对应 # 启动训练batch 根据显存调整8G 显存用 batch 8 yolo detect train \ modelyolov8s.pt \ data/data/construction_vehicle/dataset.yaml \ epochs100 \ batch8 \ imgsz640 \ workers4 \ device0 \ projectrun_vehicle \ nameexp_loader \ pretrainedTrue \ optimizerautoimgsz640是精度与速度的平衡点。工程车不是小目标在监控画面里通常占 100 像素以上不需要像检测行人那样上 1280 分辨率。device0指定第一张 GPU多卡可以写0,1。optimizerauto会让 YOLOv8 根据模型自动选择优化器新手不需要手动改成 SGD 或 AdamW。训练过程中要注意日志里Box(P),Box(R),mAP50,mAP50-95四个指标mAP50只统计 IoU 阈值为 0.5 的预测适合看粗定位能力mAP50-95对定位精度更严格工程车这类大目标mAP50-95做到 0.7 以上是比较健康的水平。3.2 必调的四个训练参数epoch、batch、patience 和 seedepochs100不是越多越好。工程车数据集规模不大通常 60 轮左右就收敛100 轮的目的是留出足够的余量配合patience自动早停。patience20表示验证集指标连续 20 轮没有提升就停止避免为最后一两个点的提升烧掉大量时间。batch的选取不止看显存还要看样本量总样本量除以 batch 得到每个 epoch 的迭代步数建议每步不低于 100否则 BN 层的统计量不稳模型容易震荡。样本少的项目可以把 batch 调大来弥补。seed0固定随机种子是为了实验可复现换模型或调增强参数时只有固定了 seed对比才有效。# 断点续训从上次中断的权重继续跑 yolo detect train \ modelrun_vehicle/exp_loader/weights/last.pt \ data/data/construction_vehicle/dataset.yaml \ epochs100 \ batch8 \ resumeTrue训练中断是常态掉电、显存溢出、宿主机重启都会让训练中断。YOLOv8 的resumeTrue会读取last.pt里保存的 epoch、优化器状态和随机数状态恢复到中断那一刻的状态。需要注意model参数必须指向last.pt而不是best.pt因为best.pt不保存优化器状态恢复后学习率会回到初始值可能出现指标断层。3.3 损失函数曲线图怎么看不是所有下降都是好消息训练结束后run_vehicle/exp_loader/下会生成results.csv和results.png里面包含train/box_loss、train/cls_loss、train/dfl_loss以及对应的验证集指标曲线。看曲线有个容易被忽略的点训练 loss 不断下降但验证 mAP 停滞或倒退说明过拟合这时要看数据增强是否过强或标签噪声是否过大验证 loss 出现 nan 或断崖式上升先查学习率和 batch 是否合理再查数据集里是否有空的 txt 文件。# 用 pandas 快速提取 loss 曲线最低点 import pandas as pd df pd.read_csv(run_vehicle/exp_loader/results.csv) df.columns [c.strip() for c in df.columns] # 查看验证集 mAP50 在哪一轮达到峰值 best_epoch df[val_mAP50].idxmax() 1 best_map df[val_mAP50].max() print(fbest mAP50 at epoch {best_epoch}, value {best_map:.4f})工地数据常见的过拟合信号是mAP50 到 0.9 以上但 mAP50-95 只有 0.6 左右说明模型把“车辆大致位置”学得很好但框的边界不够准。这时优先检查标注框是否贴合目标边缘尤其是挖掘机工作臂的细长部分标注粗糙会让 mAP50-95 上不去。3.4 预训练权重下载与本地加载网络不好时的替代路径yolov8s.pt需要从官方 release 下载国内网络不好的时候经常卡在下载这一步。替代做法是直接走模型库镜像或者让同事在有网络的机器上下载后拷贝过来。预训练权重的选择有个常见误解pretrainedTrue不是必须搭配yolov8s.pt才能用如果只有yolov8n.pt也可以用它在模型定义里改成yolov8s结构但权重通道不匹配加载时会报错。# 离线加载预训练权重并继续训练 from ultralytics import YOLO model YOLO(yolov8s.pt) # 本地有该文件则不会走网络下载 results model.train( data/data/construction_vehicle/dataset.yaml, epochs100, batch8, imgsz640, cacheTrue, )cacheTrue会把图像提前缓存到内存或磁盘减少训练时反复读图的开销。样本量在几千张时内存缓存完全够用如果图像分辨率高、总量过万建议用cachedisk避免内存溢出把整个训练进程杀掉。4. 部署到工地边缘设备模型导出、量化与推理4.1 导出ONNX再转成边缘芯片格式不要直接部署pt文件训练得到的.pt权重不能直接上边缘设备rk3588 的 NPU 支持的是 RKNN 格式其他平台的 TensorRT 也要先转 ONNX 再转 engine。常见做法是分两步走pt → onnx → rknn/tensorrt engine。YOLOv8 的导出命令很简单但有几个参数直接决定部署性能。# 导出 ONNX动态输入尺寸 简化算子 yolo export modelrun_vehicle/exp_loader/weights/best.pt formatonnx dynamicTrue simplifyTrue opset12 # 导出的 onnx 文件在当前目录下 # 用 onnxruntime 先在本机验证精度 python -c import onnxruntime as ort import numpy as np sess ort.InferenceSession(best.onnx) x np.random.rand(1,3,640,640).astype(np.float32) out sess.run(None, {images: x}) print([o.shape for o in out]) 导出后第一个要确认的是输出形状。YOLOv8 的 ONNX 默认输出是三个头的原始预测shape 是(1, 84, 8400)这种形式84 是 4 个框坐标加 80 个 COCO 类别。改成自己的四类数据后类别数变成 4输出应变为(1, 8, 8400)。如果输出 shape 还是 84说明导出时用的权重不是训练好的best.pt而是官方 COCO 预训练权重这会导致推理结果类别名完全对不上。4.2 rk3588 部署的量化误差和精度校准rk3588 部署要经过onnx → rknn的转换这个过程最影响精度的是量化。RKNN 工具默认用 int8 量化对工程车这种大目标影响不算严重但如果工地背景复杂、车辆间距小量化后可能出现漏检。常见做法是开启数据集校准# rknn 量化校准脚本片段 from rknn.api import RKNN rknn RKNN() rknn.config( mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3588 ) rknn.load_onnx(modelbest.onnx) # 量化校准数据集建议取训练集中不同场景的图各 5~10 张 rknn.build(do_quantizationTrue, datasetquant_dataset.txt) rknn.export_rknn(best_fp16.rknn)校准数据集不要用验证集这点容易搞错。量化校准的目的是让模型适配真实输入的数值分布如果拿验证集去校准会高估量化后模型的实际精度部署到现场后掉点更明显。另外 RKNN 支持fp16导出如果现场算力余量够用 fp16 比 int8 精度高不少几乎无损。4.3 后处理里的 NMS 参数对工程车密集场景的影响YOLOv8 的 ONNX 输出是未经过 NMS 的原始预测需要在部署代码里自己实现 NMS 或用自带的后处理。工地场景的特点是车辆集中、相互遮挡NMS 的 IoU 阈值直接决定挨在一起的两辆车是保留两个框还是合并成一个。阈值iou_thres调太高接近 1会把遮挡车辆输出成多个重叠框调太低0.3 以下又容易把一辆车切成两个框。我一般把conf_thres设为 0.25、iou_thres设为 0.45作为工程车场景的起步值具体数值要根据现场摄像头高度和车辆密度实测调整。# 部署端后处理逻辑示例 results model.predict( sourcertsp://192.168.1.100:554/stream, conf0.25, # 置信度阈值 iou0.45, # NMS IoU 阈值 imgsz640, devicecpu, # 部署端如果是 CPU 推理 classes[0, 1, 2, 3] # 只检测四类工程车 )摄像头画面里的工程车经常是斜停、侧停、倒车入库姿态和训练集里的正侧视角差异大。遇到这类漏检先不要怀疑模型结构回到数据层补拍对应姿态的样本比调阈值有效得多。5. 施工车辆识别实战避坑5条高频踩坑记录5.1 训练集里“拉土车”全是空载状态现场满载翻车现象训练时 mAP50 有 0.92现场满载的拉土车频繁漏检或者把车厢识别成车头。原因标注样本里全是空载状态车厢高度低、轮廓平直满载后车厢升起、货物遮挡车身主体特征分布超出训练分布。解决补拍满载和卸货状态的拉土车样本标注时车厢升起的也要完整框入。如果实在补不到把训练集里空载和满载的比例控制在 3:1 到 4:1 之间避免模型把“空载拉土车”当成唯一模板。5.2 挖掘机工作臂没框进去模型只认“车身”现象检测框只覆盖履带和驾驶室工作臂漏在框外导致和装载机在部分角度下混淆。原因标注规则执行不严多人标注时有的框含工作臂、有的不含模型学到的形状模板不完整。解决复查标注图片统一框选规则。对已训练完的模型最好的修复方式不是改标注重训一版而是把所有“不含工作臂”的框找出来修正后合并到训练集增量训练几十轮。5.3 夜间补光后颜色偏移HSV增强没覆盖现象白天场景识别稳定夜间补光场景识别率掉一半尤其是装载机和挖掘机互相误检。原因夜间补光灯偏黄偏暗图像整体色温偏移训练时的hsv_h增强幅度不够。解决把hsv_h从默认 0.015 调到 0.05hsv_v调低模拟暗光另外采集夜间样本混入训练集让模型学到“暗光下的车仍是我要的车”。5.4 rk3588 量化后精度掉点 5% 以上先怀疑校准集现象RKNN 量化后 mAP 从 0.9 掉到 0.84车辆检测框偏移明显。原因量化校准数据集只有 10 张图且全是白天的干净场景没有覆盖夜间和遮挡场景。解决从训练集里抽 50 张图混合校验集组成校准集覆盖不同时段、不同天气、不同机位。如果还掉点检查导出 ONNX 时是否开了simplify未简化的模型里可能出现量化工具不适用的算子。5.5 类别标签顺序对不上部署结果张冠李戴现象本地验证一切正常部署后模型把挖掘机识别成装载机把拉土车识别成搅拌车。原因训练时的class_names顺序和部署端后处理里classes数组没对齐比如训练时excavator是索引 2部署代码里却按索引 2 取loader的标签。解决部署代码里硬编码一个类别映射表写注释注明与训练时dataset.yaml的names顺序一致。不要在部署端动态读取名称数组否则后续重训时顺序一变就无声出错。6. 精度验证与现场调优用混淆矩阵和视频抽帧定位问题训练完成后不要只看 mAP 曲线要对工地视频做抽帧验证。从现场录一段 10 分钟的视频按 5 秒间隔抽帧逐帧跑模型统计每一类的 TP、FP、FN。这个做法能发现 mAP 隐藏的问题比如挖掘机在基坑里只露上半身时频繁漏检搅拌车在拐弯时被误检成装载机。from ultralytics import YOLO model YOLO(run_vehicle/exp_loader/weights/best.pt) # 对现场视频抽帧推理保存检测结果 results model.predict( sourcesite_video.mp4, conf0.25, iou0.45, saveTrue, save_txtTrue, stride5 )抽帧结果的统计口径比测试集更有参考价值。工地视频里的车辆角度、遮挡、光照是连续的模型在测试集上的得分高不代表在连续帧上稳定——如果同一个挖掘机在相邻 10 帧里有 3 帧漏检说明模型对某些姿态的响应不稳定要回数据层补样本。精度已经够用的情况下想进一步压推理耗时优先看输入尺寸和量化imgsz从 640 降到 480 能省约三成推理时间工程车这类大目标在 480 分辨率下也不会严重掉精度int8 量化配合 HALF 输出在 rk3588 上是收益最明显的组合。现场还有一个容易被忽略的细节多路摄像头机位角度不同固定一个训练集去适配所有机位往往不够。我习惯在部署后按机位各录一段视频单独统计每路视频的漏检率漏检率超过 5% 的机位就把该机位的画面抽帧补进训练集。这套流程跑过两个工地以后你会明显感觉到调模型的时间越来越少补数据的时间越来越多——这才是工程车识别项目进入良性循环的标志。希望这些经验能帮你在自己的工地场景里少走几趟弯路。本文还有配套的精品资源点击获取