YOLOV5实战：垃圾桶满溢检测三类别数据集与部署调优

简介本资源为基于YOLOV5的垃圾桶满溢检测实战项目面向计算机视觉入门与进阶开发者、目标检测课程设计或竞赛参赛者解决城市环卫场景中垃圾桶状态与散落垃圾的自动识别问题。项目包含完整代码、数据集与训练好的权重参数经测试可直接运行。压缩包共约2000个文件以txt标签、py脚本、yaml配置、sh训练脚本及md说明为主整体约450MB。数据集含3类别满溢垃圾桶、未满溢垃圾桶和垃圾训练集2680张图片及对应标签验证集669张图片及对应标签。项目迭代100个epoch最优精度map0.50.91、map0.5:0.950.73runs目录保存了混淆矩阵、PR曲线、F1曲线及推理结果便于复盘训练过程与调参。已有366人学习适合希望快速跑通检测流程、理解数据标注与评估指标的读者参考。1. 垃圾桶满溢检测为什么总在傍晚翻车做过环卫巡检项目的同行大概都有同感垃圾桶满溢检测这个需求听起来简单真跑起来却总在傍晚集中翻车。原因不玄学——傍晚光线斜射、桶体阴影拉长、垃圾袋反光模型把阴影当成溢出物把反光当成空桶误报率直接翻倍。YOLOV5 实战项目垃圾桶满溢检测数据集3类别这个标题讲的正是用三分类目标检测把「空桶 / 半满 / 满溢」区分开落到可部署的巡检方案上。它解决的不是「能不能检测到桶」而是「能不能稳定判断桶的状态」——这直接决定清运车该不该出车、出几趟。适合谁做智慧环卫、园区物业、边缘盒子落地的算法工程师和集成商尤其是手里已经有摄像头、想低成本加一层状态识别的团队。三类别看似简单但类别边界模糊、样本长尾严重恰恰是练数据工程和调参手感的好靶子。2. 三类别标注体系怎么定才不返工2.1 为什么是「空桶 / 半满 / 满溢」而不是「满 / 不满」很多人第一反应是二分类满和不满。我一开始也这么干结果标注到第三批数据就崩了。问题出在「半满」这个中间态——它既不是空也不是满二分类会强迫标注员在边界上做主观判断同一个桶两个人标出两个结果训练集里全是噪声。三类别把中间态显式建模标注员只需要回答「有没有明显垃圾露出桶口」和「垃圾是否接近桶口」判断标准从连续量变成两个离散阈值一致性立刻上来。更关键的是业务侧清运调度关心的不是「满没满」而是「还能撑多久」。半满意味着这趟可以缓一缓满溢意味着必须马上处理。三类别直接对应三档调度策略比二分类多出来的那一类恰恰是省成本的那一类。类别定义建议写成可执行的判定规则而不是形容词类别判定规则满足其一即可典型误标空桶桶内可见底部或垃圾高度低于桶深 1/3把深色桶底当垃圾半满垃圾高度在桶深 1/3 到 4/5 之间未超出桶口把桶沿阴影当垃圾满溢垃圾超出桶口平面或桶盖无法闭合把背景堆物算进桶内这张表要贴在标注工具旁边标注员每标一张对照一次。别嫌麻烦返工一次的成本是首次标注的三倍。2.2 采集清单每个类别至少覆盖这几种场景数据集质量决定上限这话在满溢检测里尤其真。我一般按「类别 × 场景 × 光照」三维度列采集清单避免某一类在某个场景下完全缺失。三类别各准备以下场景每类每场景不少于 150 张空桶标准空桶、刚清运完、桶内有少量积水、桶盖半开半满日常投放后、纸箱类大件、袋装垃圾堆叠、桶口有零星垃圾满溢垃圾高出桶口、桶盖被顶开、桶边散落、多桶并排其中一桶溢出光照维度至少覆盖顺光、逆光、阴天、夜间补光四种。傍晚斜射光单独归一类因为它是误报重灾区样本量要加倍。采集时用固定机位和移动机位各拍一轮固定机位模拟已部署摄像头移动机位补充角度多样性。提示采集阶段就按「场景_光照_序号」命名文件后期切分数据集时能直接按前缀分层抽样省掉大量人工核对。2.3 标注规范框怎么画、遮挡怎么处理标注规范不统一后面调参调到怀疑人生。三条硬规则第一框只框桶体可见部分不框散落在桶外的垃圾。满溢类别的框以桶口为基准向上扩展包含超出桶口的垃圾但不包含地面散落物。第二遮挡超过 50% 的桶直接丢弃不标。遮挡 20% 到 50% 的标但在标签文件里加一个occluded标记位训练时可以选择性加权。第三多桶并排时每个桶单独成框不允许一个大框套多个桶。标签格式用 YOLO 标准class_id x_center y_center width height全部归一化到 0 到 1。类别 id 固定为 0 空桶、1 半满、2 满溢顺序一旦定下就不要改改一次所有历史标签全废。3. 用 YOLOV5 在本地跑通三类别训练3.1 环境与数据目录一次配置到位先确认硬件单卡 8GB 显存起步三类别数据量在 5000 张以内YOLOV5s 足够别一上来就上 x。环境用 conda 隔离避免和系统里的其他框架打架。# 创建环境python 版本按 YOLOV5 官方要求选 3.8 以上 conda create -n trash_detect python3.9 -y conda activate trash_detect # 安装依赖torch 版本按自己 CUDA 版本去官网查对应命令 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install -r requirements.txt # 验证 GPU 可用 python -c import torch; print(torch.cuda.is_available())数据目录按 YOLOV5 约定组织images 和 labels 平行放置文件名一一对应dataset/ images/ train/ val/ test/ labels/ train/ val/ test/ trash.yamltrash.yaml是数据集描述文件内容如下# 数据集根路径建议写绝对路径避免相对路径踩坑 path: /data/trash_dataset train: images/train val: images/val test: images/test # 类别数必须和 names 长度一致写错直接报错 nc: 3 names: [empty, half, full]参数说明path写绝对路径YOLOV5 对相对路径的解析依赖启动目录换目录就找不到数据。nc和names必须严格对应顺序就是标签里的 class_id 顺序。改完 yaml 先用官方脚本校验一遍标签能提前揪出越界坐标和空标签。3.2 训练命令与关键参数怎么设启动训练前先跑一次数据校验确认没有损坏图片和越界标签# 校验数据集会输出每类样本数和标签分布 python utils/general.py --check dataset/trash.yaml正式训练命令python train.py \ --data dataset/trash.yaml \ --weights yolov5s.pt \ --img 640 \ --batch 16 \ --epochs 100 \ --hyp data/hyps/hyp.scratch-low.yaml \ --name trash_v1 \ --cache逐参数说清楚--img 640是输入分辨率满溢检测里桶口细节重要640 是精度和速度的平衡点显存够可以上 768但推理速度会掉三成。--batch 16按显存调8GB 卡跑 640 分辨率 16 是安全值爆显存就降到 8。--epochs 100是上限实际看验证集 mAP 曲线连续 20 轮不涨就可以停。--hyp用 low 增强配置因为满溢场景本身样本少强增强容易把满溢样本增广成半满反而添乱。--cache把图片缓存到内存数据量小于 8000 张时能明显加速内存不够就去掉。训练过程中重点盯三个指标mAP0.5看整体mAP0.5:0.95看定位精度每类的precision和recall分开看。满溢类的 recall 比 precision 重要——漏报一个满溢桶清运车白跑一趟误报一个顶多多派一次车。所以调参时优先保满溢类 recall。3.3 推理与结果可视化先看混淆再谈部署训练完先别急着导出模型用验证集跑一遍混淆矩阵看清楚错在哪# 在验证集上推理生成混淆矩阵和 PR 曲线 python val.py \ --data dataset/trash.yaml \ --weights runs/train/trash_v1/weights/best.pt \ --img 640 \ --conf 0.25 \ --iou 0.45 \ --task val--conf 0.25是置信度阈值低于这个值的框直接丢。满溢检测里建议先设 0.25 看召回如果满溢类漏检多就降到 0.15代价是误报上升。--iou 0.45是 NMS 的 IoU 阈值多桶并排场景下这个值别设太高否则相邻桶的框会被合并0.45 是稳妥起点。混淆矩阵出来后重点看两处满溢被误判成半满的比例以及半满被误判成空桶的比例。前者说明桶口特征学得不够后者说明中间态样本太少。针对性地补样本比盲目加 epoch 有效得多。单张图片推理验证python detect.py \ --weights runs/train/trash_v1/weights/best.pt \ --source test_images/ \ --img 640 \ --conf 0.25 \ --save-txt--save-txt会把检测框坐标存成 txt方便后续和业务系统对接。输出目录在runs/detect/exp下每跑一次序号递增别搞混。4. 满溢检测的避坑与排查清单4.1 坑一满溢类 recall 死活上不去现象训练到 60 轮空桶和半满的 mAP 都过 0.8 了满溢类还在 0.5 徘徊混淆矩阵里大量满溢被标成半满。原因满溢和半满的视觉差异集中在桶口那一小块区域640 分辨率下桶口可能只占几十个像素特征被下采样吃掉。加上满溢样本通常比另外两类少模型倾向于把边界样本判成多数类。解决三步走。第一把满溢样本单独过采样用--oversample或者在 yaml 里复制满溢图片路径让三类样本量接近。第二把输入分辨率提到 768桶口细节能多保留一层特征图。第三在hyp里调高box损失权重让模型更关注定位精度。我一般先做第一步八成情况能拉回来。4.2 坑二傍晚图片误报率飙升现象白天验证集表现正常一换傍晚斜射光的测试集空桶被大量误报成满溢precision 掉到 0.4。原因斜射光在桶内形成长条阴影纹理和垃圾袋高度相似模型把阴影当成了溢出物。这是数据分布问题不是模型问题。解决在采集阶段就补傍晚样本每个类别至少 200 张且要覆盖不同太阳角度。训练时开启 HSV 增强里的hsv_v参数让模型对亮度变化更鲁棒。如果已经训练完才发现用傍晚样本做一轮小学习率微调--lr0设成初始值的十分之一跑 20 轮就能明显改善。4.3 坑三多桶并排时框合并现象两个相邻的桶一个满一个空检测结果只出一个框类别还是满溢。原因NMS 的 IoU 阈值设太高两个桶的框重叠度超过阈值被合并。或者标注时就用了一个大框套两个桶模型学到的就是合并模式。解决先查标注确认每个桶单独成框。然后调低--iou到 0.35让 NMS 更激进地保留独立框。如果还不行在推理后处理里加一层按框中心点距离的分割逻辑距离小于桶宽一半的框强制拆开。4.4 坑四小目标桶检测不到现象远景摄像头里桶只占画面很小一块模型完全没输出。原因YOLOV5 默认的三层检测头最小 stride 是 8对应 640 输入下最小可检测目标约 8 像素。桶小于这个尺寸就丢了。解决换用带 P2 检测头的配置yolov5s-p2.yaml多一层 stride 4 的特征图小目标召回明显提升代价是推理慢 20% 左右。或者把输入分辨率提到 1280但边缘设备基本扛不住。实际项目里我一般建议调整摄像头安装位置让桶占画面高度至少 1/10比改模型划算。4.5 坑五标签类别顺序写反现象训练 loss 正常下降但推理结果全乱空桶被标成满溢。原因yaml 里names顺序和标签文件里的 class_id 对不上。比如 names 写的是[full, half, empty]标签里 0 却是空桶。解决定一个铁律——class_id 0 永远是空桶1 半满2 满溢所有脚本、yaml、标注工具统一。改完 yaml 后跑一次val.py看混淆矩阵对角线是否集中不集中就是顺序错了。5. 从能跑到好用阈值调优与边缘部署的取舍模型跑通只是起点真正决定这套方案值不值得投入的是推理阈值和部署形态的匹配。满溢检测的业务逻辑决定了它不能只追求 mAP 好看得按调度成本反推阈值。先做阈值扫描。写个小脚本在验证集上遍历 conf 从 0.1 到 0.6步长 0.05记录每个阈值下满溢类的 recall 和误报数import numpy as np from pathlib import Path # 假设已经拿到每个检测框的 conf 和是否正确的标记 # confs: 模型输出的置信度数组 # is_correct: 该框是否与真值匹配IoU0.5 且类别正确 confs np.load(val_confs.npy) is_correct np.load(val_correct.npy) for thresh in np.arange(0.1, 0.65, 0.05): # 高于阈值的框才保留 kept confs thresh tp np.sum(kept is_correct) fp np.sum(kept ~is_correct) fn np.sum(~kept is_correct) recall tp / (tp fn 1e-6) precision tp / (tp fp 1e-6) print(fconf{thresh:.2f} recall{recall:.3f} precision{precision:.3f} fp{fp})这段逻辑很直白遍历阈值算每个阈值下的召回和精确率重点看误报数 fp 随阈值的变化曲线。满溢检测里我一般选 recall 不低于 0.9 的前提下 fp 最小的那个阈值。实际项目里这个点通常在 0.2 到 0.3 之间比默认 0.25 略低。再说部署形态。边缘盒子跑 YOLOV5s 在 640 分辨率下主流芯片能到 15 到 30 FPS对垃圾桶巡检这种低频场景绰绰有余。但有两个取舍要注意第一别用 TensorRT 的 FP16 量化去压满溢类量化误差在桶口细节上会被放大我实测过 FP16 下满溢 recall 掉 5 个点用 FP32 或者 INT8 校准更稳。第二如果摄像头是 4G 回传别在边缘做全量推理改成运动触发——画面有变化才推理能省七成流量。最后说一个我踩过的坑别在训练集上验证阈值。训练集 loss 低不代表阈值合适一定要留一个完全独立的测试集按场景分层抽样傍晚样本占比和实际部署环境一致。我吃过一次亏测试集全是白天图阈值调到 0.3 看着很美上线第一周傍晚误报把运维电话打爆。后来养成习惯任何阈值调整都在「傍晚 阴天 夜间」三个子集上分别验证取最差情况做决策。这套流程跑下来三类别满溢检测的误报率能压到可接受范围方案才真正值得投。希望帮到你。本文还有配套的精品资源点击获取