简介本资源面向智能交通、智慧工地及计算机视觉初学者与工程实践者提供一套开箱即用的施工车辆细粒度识别数据集与YOLOv8训练支持方案解决工程现场多类型重型机械自动识别与分类难题。资源包共2000个文件含661张施工现场真实采集的工程车图像jpg、1338份对应YOLO格式标注文件txt及1个结构清晰的data.yaml配置文件总大小92.06MB覆盖装载机、挖掘机、混凝土搅拌车、拉土车等典型施工车辆类别图像经合理裁剪与标注适配YOLOv8系列模型端到端训练。目前已有761人学习下载资源可直接用于模型训练、推理测试与项目部署附带完整目录组织与标准标注规范显著降低数据预处理门槛助力快速构建高精度工程车辆识别系统。 做智慧工地项目的朋友应该都有这种体会以前工地大门对工程车管理基本靠保安师傅拿本子记记了也不一定准车一多就乱。最近我接了一个需求要把进出工地的装载机、搅拌车、挖掘机、拉土车自动识别出来联动道闸和统计报表。我选了YOLOv8来做最终打包成一个可以直接运行的训练加识别项目包。这篇文章就从需求分析、数据准备、模型训练到部署落地完整拆一遍我是怎么把这个工程车类型识别模型做出来的包括中间踩过哪些坑、哪些参数是试出来的、哪些环节最花时间。不管你是正在做智慧工地、智慧物流还是刚开始接触YOLOv8做自己的目标检测项目这篇内容应该都能用得上。1. 项目整体设计先搞清楚要解决什么再谈选模型1.1 工地场景下的真实需求工程车类型识别这个需求通常出现在几个环节里。最常见的是工地出入口车辆要进场作业闸机需要自动放行不同车型对应的通道、卸料区域、计费规则都不一样。搅拌车要进搅拌站拉土车要进土方区挖掘机和装载机主要在场地内流动但进出场也要登记。如果还涉及土方计量拉土车拉了多少车、搅拌车送了多少方混凝土都需要按车型自动统计。另一个场景是工地围挡上的全景监控用来判断某个区域当前有没有违规作业或者用于保险定损、车辆调度分析。这种场景下检测目标更小、视角更复杂对模型的鲁棒性要求更高。我在这个项目里把识别类别固定为四类挖掘机excavator、装载机loader、搅拌车mixer_truck、拉土车dump_truck。有人会把压路机、推土机、吊车也加进来但从源头工地的进出场统计来说这四类是需求最集中的先把核心类别做稳再慢慢扩展才是正路。1.2 为什么是YOLOv8而不是YOLOv5或DETR选型的时候我仔细对比过。YOLOv5已经发布好几年社区生态成熟但它的训练流程和后续的部署链路不如YOLOv8干净。YOLOv8把训练、验证、导出、预测全部统一成了ultralytics的API无论你是用命令行还是Python脚本一套接口走到底这对做项目的人来说太重要了。DETR这类Transformer方案精度上限确实高尤其是处理密集遮挡场景的时候。但工程车识别是典型的固定摄像头监控场景实时性要求高部署资源有限DETR的推理复杂度和工程化成本都不划算。YOLOv8在速度和精度之间的平衡最好C2f结构能在不算大的模型体量下提取到足够的细节特征而且官方直接支持导出ONNX、TensorRT、RKNN等格式这对后续要放到边缘设备上的需求非常友好。还有一点很关键YOLOv8的预训练权重在COCO上表现扎实。工程车虽然是特定领域目标但迁移学习用COCO权重初始化收敛速度比从零训练快得多我在小数据量实验里验证过用预训练权重训练50轮的mAP比从零训练200轮还高。1.3 项目包的整体结构这个项目包我最终整理出来的结构大概是这样的construction_yolo/ ├── data/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── construction.yaml ├── train.py ├── detect.py ├── export.py ├── weights/ │ ├── yolov8s.pt │ └── best.pt └── runs/data目录放图片和标注文件construction.yaml是数据集配置文件train.py和detect.py分别是训练和推理脚本weights里放预训练权重和训练产出的最佳权重。麻雀虽小但一个完整项目该有的东西都有了别人拿到手之后用自己的数据把construction.yaml里的路径一改就能接着练。2. 数据集准备决定模型上限的第一道关卡2.1 四类车型的视觉特征拆解做数据之前我先把四类工程车在监控画面里的视觉特征彻底梳理了一遍。这决定了后面标注标准怎么定也决定了模型能不能学对东西。挖掘机的辨识度其实很高前提是它处于工作状态。履带式底盘、可360度旋转的上车体、粗壮的动臂和斗杆、末端挂着铲斗这几个特征组合在一起非常明显。但挖掘机一旦停在那里收臂、铲斗落地正面看过去整个机体缩成一团反而容易和装载机混淆。装载机的特征和挖掘机刚好相反。它整体显得更敦实前方是一个大铲斗举升臂在车体前方两侧驾驶室在正中间没有旋转平台。轮胎特别大车身离地间隙高。侧面看的时候铲斗和举升臂形成一个明显的“Z”字形结构。搅拌车最好认身后斜背着一个大圆罐罐体上通常还有螺旋纹路工作中罐体还在转动。但搅拌车在夜间或者逆光环境下罐体和车身颜色接近轮廓会糊在一起这时候模型容易把整个车识别成一个大目标或者干脆漏检。拉土车的问题在于它和普通自卸货车太像了。最可靠的区分点是货厢形态工地上常见的拉土车是上宽下窄的斗形货厢后面有可以翻转卸货的液压结构而且车身上一般有明显的泥土痕迹。如果标注时不做严格区分拉土车类别里混进普通货车模型精度会掉得很厉害。2.2 数据来源与清洗方法工程车没有特别好的公开数据集这一点和行人检测、车辆检测完全不一样。我花了不少时间在数据来源上最终用了四路第一路是从监控视频抽帧。我手上有几个工地现场的录像分别装在出入口、料场、主干道三个位置。视频抽帧用FFmpeg按5秒一帧抽抽完用脚本做去重不然相邻帧几乎一样训练起来等于把同一张图重复了几十遍。第二路是从图片搜索引擎抓取。这方面要注意版权问题抓来的图片只用于内部训练验证不能直接商用发布。搜索关键词按类别拆开搜比如“excavator construction site”、“loader wheel loader”、“concrete mixer truck”、“dump truck工地”尽量让背景、角度、光照都多样化。第三路是用现有开源数据集交叉补充。Open Images里有部分挖掘机和装载机数据一些学术数据集也包含工程车辆类别把它们提取出来转成YOLO格式。第四路是对已有图片做二次筛选。这一步最重要因为来源杂很多图片存在水印、目标过小、严重遮挡、目标不完整等问题。我的清洗标准是目标在画面里占的比例低于2%的直接删掉目标被遮挡超过一半的删掉水印严重干扰检测的删掉。宁可少也不要脏脏数据对模型精度的影响远大于少数据。最后四类整理下来一共4300多张有效图片。我按9比1分了训练集和验证集训练集约3900张验证集约400张。2.3 标注标准与工具选择标注是另一个花时间的大头。我用的是X-AnyLabeling这个工具支持SAM辅助标注勾选区域的时候能半自动贴合目标边缘工程车这种硬朗轮廓的目标用起来效率很高。LabelImg也可以用但没有辅助分割功能纯手动框会比较累。标注标准我定了三条反复叮嘱一起标注的同事按这个执行第一条框选范围以车辆主体为准但要把明显伸出的工作装置包含进去。挖掘机动臂举起来的时候如果框只框车身而不框大臂和铲斗模型学到的是“一团黄乎乎的东西”而不是“有长臂的挖掘机”识别率会明显下降。装载机铲斗朝前时要把铲斗算进去。第二条遮挡情况下只框可见部分。两辆车并排停着相互遮挡就把两辆车各自能看见的部分分别标出来不要用一个框把两辆车包在一起。如果一辆车被挡住超过一半直接不标。第三条严格限定类别边界。拉土车只标工地常见的非封闭式自卸货车普通厢式货车一律不标看到也当作背景。挖掘机和装载机如果从某个角度实在分不清优先画框让对方人工二次学习不要随手标一个类别进去错误标注比不标注危害大得多。标注完还要做一轮格式检查。YOLO格式的标注文件是txt每行格式为 class_id center_x center_y width height全部归一化到0到1。我写了个脚本检查常见问题坐标超界、宽高为0、类别ID超出配置范围、标签文件和图片文件对不上。这种检查在训练前必须做一遍能省下后面排查问题的大量时间。3. 训练环境与参数6G显存也能跑得动3.1 环境配置清单先说配置环境。Python我用的3.10PyTorch用的2.1搭配CUDA 11.8。实际测试下来torch 2.0到2.3之间都能稳定跑ultralytics不需要追求最新版PyTorch版本本身对YOLOv8的训练几乎没有影响。安装步骤写一下conda create -n yolo python3.10 -y conda activate yolo pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralyticsultralytics会自动拉取所需的依赖包括opencv-python、numpy、pandas、matplotlib等。如果机器上已经装了老版本的ultralytics升级一下再跑有些新参数只在较新版本里才有。这里要注意一个版本陷阱ultralytics版本太老的话部分训练参数名字不一样比如旧版本用label_smoothing新版本写法没变但默认值不同。如果训练时报参数错误先看版本别急着改代码。3.2 显卡资源有限时的训练策略我手头的显卡是GTX 1660Ti6G显存在2024年跑目标检测训练属于入门档。一开始我也担心带不动实际上只要合理配参YOLOv8s在6G显存上绰绰有余。具体配置yolo train modelyolov8s.pt dataconstruction.yaml epochs200 imgsz640 batch4 device0 optimizerAdamW lr00.001模型用yolov8s不要用m或ls在工程车识别场景下精度和速度兼顾。batch设为46G显存跑640分辨率的yolov8sbatch 4完全没问题。如果显存更小可以把batch降到2然后开启梯度累积效果基本能补回来。imgsz用640。如果你负责的监控画面里目标普遍很小可以尝试用800训练但推理时也要保持800否则训练和部署分辨率不一致精度会打折。epochs按200来设配合早停ultralytics默认有early stopping模型到不了200轮自己就停了。我另外尝试过batch 8加显存优化器但1660Ti上训练速度提升不明显反而经常爆显存后来就一直用batch 4稳定省心。3.3 数据集配置文件与类名顺序数据集配置文件construction.yaml是最容易出错的地方。路径必须写对尤其是Windows下反斜杠和正斜杠的问题建议统一用正斜杠不容易踩坑。path: /home/user/construction_yolo train: images/train val: images/val names: 0: excavator 1: loader 2: mixer_truck 3: dump_trucknames的顺序和标注文件里的class_id一一对应不要随手改。如果你在别的项目里下载过类似配置一定要检查类别顺序是否一致否则会出现挖掘机标成搅拌车的尴尬局面。训练工作目录下会自动生成runs目录每跑一次训练会生成runs/train/exp、exp2、exp3这样的文件夹序列模型权重、训练曲线图、验证结果都在里面。我习惯在训练命令里加上项目名和名称参数方便区分不同的实验yolo train modelyolov8s.pt dataconstruction.yaml projectconstruction_runs namebase_v1这样每次实验都有独立的文件夹不会出现想找上一次的best.pt结果翻半天的情况。3.4 怎么判断训练收敛了训练到一半最关心的就是模型到底在不在学东西。ultralytics在训练结束后会自动生成results.png图里包含训练集和验证集的loss曲线、precision、recall、mAP50、mAP50-95等指标。我看训练曲线主要看三点。第一看train/box_loss和train/cls_loss是不是持续下降如果下降几步又反弹说明学习率太高或者数据里有脏样本。第二看val/box_loss和val/cls_loss验证集loss比训练集loss高是正常的但如果高太多或者出现明显上升那就是过拟合了需要增加数据增强或者调低epoch。第三看mAP50和mAP50-95曲线一般到训练后1/3段就进入平台期如果到最后还是直线上升可以适当增加epoch继续训练。如果不想等到训练结束才看可以开TensorBoard实时监控tensorboard --logdir runs/trainultralytics会把日志写到runs/train里面TensorBoard里能看到比results.png更细的曲线变化。我第一次训练的时候就是因为及时在TensorBoard里发现val/box_loss异常才发现是某个类别的标注文件里混入了几张标签错位的图及时清理之后重新训练精度一下子提上来了。4. 训练结果诊断与常见问题排查4.1 先看整体指标再看分类别指标训练完成后先用验证集跑一次评估yolo val modelruns/train/exp/weights/best.pt dataconstruction.yaml输出会给出整体mAP50、mAP50-95、precision、recall还会给每个类别的AP值。这次项目最初的实验结果是mAP50约0.912看起来还行但拆开看类别后发现拉土车的AP只有0.83明显拖后腿。问题定位在混淆样本上。拉土车在侧面静止状态下和普通自卸货车非常接近标注时虽然定了标准但清洗阶段没有把混进来的普通货车照片彻底删掉模型学混了。解决方法是把验证集里所有拉土车的预测结果和真实标签导出来按置信度排序人眼巡检预测错误的图片把确实标错的重新标注把采集阶段误入的普通货车照片从训练集里清除。这类问题用混淆矩阵看最直观ultralytics会自动生成confusion_matrix.png。如果发现某个类别经常被预测成另一个类别就去检查这两类训练样本的视觉差异是否足够明显必要时补充难例。4.2 小目标漏检的解决办法工地监控恰恰是典型的小目标场景。摄像机架在5米高的杆子上一台挖掘机在画面里可能只有40乘30像素。YOLOv8s在640分辨率下对这种小目标的检测能力一般我第一次验证时漏检最严重的就是距离摄像头远端的拉土车。我做了三个调整。第一个是把训练分辨率从640提到800小目标的特征图分辨率高一些检测效果有改善但显存占用上升batch只能降到2。第二个是增加了数据增强里的随机裁剪让模型看到更多“目标占画面比例较小”的样本。第三个是在业务层做切图推理把监控画面分成左上、右上、左下、右下四块分别推理小目标被放大后识别率明显提升代价是推理耗时增加到原来的4倍。实际项目里我最后用的是640分辨率加切图推理的组合因为监控场景对实时性要求没那么苛刻每秒处理一帧就够了准确率优先。4.3 夜间、雨天、逆光场景怎么补数据工程车识别绕不过恶劣天气。我在清洗阶段就特意保留了一些夜间红外监控画面和雨天带水雾的画面但一开始占比太少模型在白天表现好晚上就疯狂漏检。解决办法是专门从夜间录像里再抽了一批帧补充进训练集同时对已有的白天图片做数据增强模拟夜间效果。ultralytics默认带HSV增强把饱和度降低、亮度区间拉大等于免费扩充了一部分在不同光照条件下的样本。这里有个小心得如果想增强夜间泛化能力对BGR通道单独做亮度扰动比统一调HSV更有效。因为监控相机在夜间的色彩失真不是均匀的红外模式下画面是黑白的此时颜色信息对模型来说反而是噪声。我的数据集里专门分出了一部分黑白红外图像让模型学到“没有颜色也能识别”的能力。4.4 视角单一导致的跨场景失灵一个很深刻的教训是模型在一个工地表现很好换到另一个工地效果立刻下降。原因是第一个工地的所有训练图像几乎都来自同一个摄像头视角背景、角度、距离都高度一致模型学到了很多和车型无关的背景特征。这个问题的本质是过拟合。我现在做工程车项目数据集里一定会混入至少三个不同场景的样本出入口近景、场区中景、高杆全景。如果条件允许再补充一些不同品牌、不同配色的同型号车因为工程车的涂装差异很大同一个挖掘机品牌有黄色、红色、白色多种配色模型必须对这些颜色不敏感只看结构。5. 部署落地从权重文件到可用系统5.1 导出ONNX和TensorRT训练好的best.pt不能直接扔给生产环境PyTorch推理效率太低。ultralytics官方提供了统一的导出接口yolo export modelweights/best.pt formatonnx opset12 simplifyTrue导出后得到一个best.onnx可以用ONNX Runtime或者TensorRT做推理。如果显卡是NVIDIA的建议继续转成TensorRT engine速度和延迟都有明显优化yolo export modelweights/best.pt formatengine device0 halfTruehalfTrue表示使用FP16精度精度损失很小速度提升约1.5到2倍。我在1660Ti上实测yolov8s的onnx推理大约20毫秒一帧转成TensorRT FP16后大约12毫秒一帧对实时监控来说区别很明显。另外提醒一句导出TensorRT engine时工作的显卡和部署的显卡尽量一致否则可能出现不兼容。不同显卡架构Ampere、Turing、Ada生成的engine不能互相直接用要在目标机器上重新导出。5.2 边缘设备部署以RK3588为例很多工地把服务器放在机房不现实更常见的做法是边缘盒子。我最近测试了RK3588平台6TOPS NPU算力跑YOLOv8s转成的INT8模型实时性完全够用。RK3588部署链路是先把best.pt导出为onnx再用RKNN-Toolkit2把onnx转成.rknn格式。转换过程中要做INT8量化建议用一批真实场景的图片作为量化校准数据集不要用训练集原图或者随机噪声否则量化后精度会掉得很厉害。我实测用200张工地现场图片做校准mAP50下降大概2到3个百分点在可接受范围内但推理速度提升了约3倍。推荐在PC上先完成rknn模型转换和模拟推理验证精度再交叉编译到开发板上跑。板上推理用RKNN官方Python接口或C接口都行工程上建议用C接口内存占用更可控稳定性更好。5.3 识别结果怎么接业务逻辑模型输出只是坐标框和类别落到业务层面需要做几件事。首先是用跟踪器把同一辆车跨帧关联起来我用的是ByteTrack它和YOLO配合得很顺手。跟踪完成之后就可以设置虚拟围栏或虚拟线当目标的轨迹跨越设定线段时计一次出入同时记录车型、时间、置信度、截图。这一步比很多刚入门的朋友想的重要。直接对每一帧做识别不加跟踪一辆车在画面里停留10秒就会重复计数十几次统计报表完全没法用。加上跟踪器后一辆车最多触发一次入场和一次出场。触发记录时截图保存底图后面如果出现纠纷可以按时间索引回看。整个识别服务我用FastAPI封装成HTTP接口输入图片路径或视频流地址输出检测数据JSON这样前端、闸机系统、报表系统都能方便对接。5.4 帧率与并发处理的经验值实际部署时单路视频流检测用640分辨率加TensorRT FP161660Ti上能稳定跑35到50帧每秒完全满足实时监控需求。如果同时接入多路视频我建议不要逐路开独立推理线程而是用队列把多路帧汇聚后批量推理GPU利用率更高。批量推理在YOLOv8的Python API里可以通过传入一个图片列表实现一次处理4到8帧吞吐量比单帧循环高很多。如果用ONNX Runtime注意输入张量的batch维度要一致图片尺寸也要做letterbox预处理不然推理结果会错位。这里有一个实操细节监控视频的RTSP流如果出现断流OpenCV的VideoCapture会一直阻塞在读帧上要在程序里加超时重连机制。我写了一个探测线程如果连续10秒没有新帧就自动重新连接RTSP地址否则服务跑一晚上就凉了。6. 最后说几句实在话工程车识别这个项目做到最后我最深的体会是模型训练只占整个项目三分之一的工作量真正耗时间的是数据清洗、标注标准、部署联调这些东西。很多人拿到YOLOv8就开始跑训练跑出来发现换了个现场就不准回去补数据补完再训来回几次才明白数据集质量才是决定上限的那只手。如果你拿到手的是类似这个标题里的“yolov8.zip”项目包先别急着全量重训。用里面的权重在自己现场的图上跑一遍预测统计一下哪些场景漏检多、哪些类别容易混然后针对性补充数据做微调这种迭代方式比盲目追求更多训练轮数高效得多。最后分享一个小技巧训练和推理的预处理参数一定要保持一致。YOLOv8默认的letterbox会把图片缩放到640乘640并填充灰边如果你的业务代码里读帧后直接resize成640乘640而不做等比例填充推理出来的坐标框会整体偏移看起来就像是模型失灵了。这个坑我帮人排查过好几次每次都是从这里翻车。后续如果想扩展这个项目可以考虑增加反光衣检测、车牌识别、挖掘机工作状态判断这些方向。工程车识别本身是一个很好的基础能力接上不同的业务逻辑就能在不同场景里发挥价值。本文还有配套的精品资源点击获取