
简介这份基于YOLOv8的智能垃圾桶满溢检测项目面向计算机视觉、人工智能等相关专业的毕业设计与课程设计场景用于实现对垃圾桶溢满状态的自动识别与可视化监控。项目代码经实测可运行包含完整源码、标注数据集、可视化页面与部署说明可生成核心指标曲线、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果及标签分布图等答辩关键材料适合需要快速搭建目标检测演示系统的本科生或研究生。资源包共8个文件包括3个Python脚本负责界面交互、视频检测、模型训练、3个预训练权重文件以及2个说明文档含README整体压缩约15.91MB结构紧凑下载后按说明即可快速部署。目前已有44人学习下载对于毕设、课设或初期立项演示来说是一份拿来即用的一站式方案。1. 智能垃圾桶满溢检测一个能直接跑通的YOLOv8毕设项目做毕设选目标检测方向的人不少但真正卡人的往往不是YOLOv8本身而是“模型训练完了系统在哪”。这个基于YOLOv8的智能垃圾桶满溢检测项目把深度学习模型、完整数据集、可视化界面和部署教程打包在一起解压后按文档走就能跑通正好覆盖“yolov8 目标检测 深度学习 计算机视觉 毕业设计”这套关键词背后的真实诉求。它解决的场景很具体摄像头对着垃圾桶模型实时判断桶内垃圾是否已经满溢满了就在界面上弹红色警报没满则显示当前状态。新手可以直接拿它当毕设框架替换自己的数据集和界面元素熟手可以把训练好的模型权重导出去接到实际的环卫或物业系统里。2. 数据集与标注把真实垃圾桶场景转成YOLOv8能读的格式2.1 类别设计与数据收集先想清楚“满溢”怎么定义这个项目的核心思路是用目标检测框直接带出垃圾桶的状态信息而不是只检测一个“垃圾桶”类别然后再单独写算法去算满溢程度。项目里常见的做法是把类别分成三个normal正常、full接近满溢、overflow已经满溢。摄像头画面里出现一个垃圾桶时模型框住它并输出类别id界面层根据类别id决定要不要触发报警。相比“检测垃圾桶计算垃圾区域面积占比”的方案这种多类别检测的好处是标注和训练都直接答辩时也容易讲清楚——每个状态下检测框的置信度可以直接展示在界面上。数据收集阶段最需要注意的是场景多样性。自己用手机拍摄时室外垃圾桶、室内垃圾桶、不同颜色不同形状的桶都要覆盖光照、角度、远近尽量拉开差距。如果只在一个固定角度拍训练出来的模型换个摄像头位置就会翻车。数据集规模方面每类五百张左右、总计一千五百到两千张是一个稳妥的下限再多一些能让mAP明显提升。需要提醒的是图片统一调整到640x640附近再标注训练时imgsz参数和实际图片尺寸差距太大会增加不必要的显存消耗也会让标注框的坐标换算变复杂。2.2 Labelme标注与JSON转TXT转换脚本与四个边界坑YOLOv8训练时读的是txt格式每行表示一个目标类别id、归一化中心点x、归一化中心点y、归一化宽、归一化高。Labelme默认保存的是JSON格式记录的是多边形或矩形框的像素坐标所以从标注到训练中间必须过一道转换脚本。这一步是数据环节里最容易出问题的地方常见的翻车点包括坐标没有归一化、矩形框两个点的顺序不一致、类别id从1开始数导致训练和推理时类别错位。下面这个脚本负责把Labelme保存的JSON文件批量转成YOLO训练用的txt文件import json import os def convert_labelme_to_yolo(json_path, save_dir, class_names): 将单个Labelme标注文件转换为YOLO格式txt :param json_path: Labelme导出的JSON文件路径 :param save_dir: 转换后的txt保存目录 :param class_names: 类别列表, 顺序即类别id, 必须与data.yaml一致 with open(json_path, r, encodingutf-8) as f: data json.load(f) image_w data[imageWidth] image_h data[imageHeight] if image_w 0 or image_h 0: print(f跳过 {json_path}: 图片尺寸为0) return lines [] for shape in data[shapes]: label shape[label] if label not in class_names: print(f警告: {json_path} 包含未登记类别 {label}, 已跳过) continue class_id class_names.index(label) points shape[points] x1, y1 points[0] x2, y2 points[1] # 矩形框的坐标顺序可能不固定, 统一取左上和右下 x1, x2 min(x1, x2), max(x1, x2) y1, y2 min(y1, y2), max(y1, y2) # 标注有误时可能出现负数坐标或零宽高, 直接过滤 if x2 x1 or y2 y1: print(f警告: {json_path} 出现退化标注框, 已过滤) continue cx ((x1 x2) / 2) / image_w cy ((y1 y2) / 2) / image_h bw (x2 - x1) / image_w bh (y2 - y1) / image_h lines.append(f{class_id} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) if lines: base_name os.path.basename(json_path).replace(.json, .txt) with open(os.path.join(save_dir, base_name), w, encodingutf-8) as f: f.write(\n.join(lines)) print(f已转换: {base_name})这段逻辑分成四块读取JSON和图片宽高、遍历shapes提取类别和坐标、做坐标归一化计算、写txt文件。最关键的参数是class_names的顺序它决定txt第一列的数字对应哪个类别后面训练时data.yaml里的names列表必须和这里完全一致差一位就是灾难性的错位。中心点坐标和宽高都除以了图片宽高这是YOLO格式的硬性要求漏掉归一化会让模型训练时loss降得很低却永远学不会正确位置。2.3 数据集划分与目录结构训练前必须检查的五件事YOLOv8对数据集目录结构有约定images目录放图片labels目录放同名的txt文件train和val分开。项目拿到手后先不要急着训练把目录结构按下面这样理清楚datasets/trash/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── trash.yaml图片和标签文件名必须完全同名只是扩展名不同。划分时用脚本随机分配避免手动拖拽导致某个类别的图片全部集中到训练集或验证集里。我习惯按8:2划分训练前强制检查三件事每一类在train和val里都有样本labels目录里没有空文件txt里的类别id最大值小于类别总数。空文件会被YOLO自动忽略但日志里会刷大量警告id越界会直接报错而且报错位置藏在数据加载内部定位起来很浪费调试时间。trash.yaml内容如下path: /你的绝对路径/datasets/trash train: images/train val: images/val nc: 3 names: [normal, full, overflow]path这一项建议写绝对路径。相对路径在部分环境下也能跑但一旦切换工作目录或者用IDE的调试模式启动就很容易出现“Dataset not found”报错这是训练起步阶段最常见的坑。换机器迁移项目时只需要改path一行其余配置可以原样复用。3. 环境搭建与模型训练从零配置到损失曲线收敛3.1 环境配置CPU版与GPU版的具体差异训练之前先把ultralytics环境装好。最省事的路径是用conda建一个干净环境Python版本建议3.8到3.10之间然后pip安装。conda create -n yolov8 python3.9 -y conda activate yolov8 pip install ultralyticsCPU环境到这里就结束了不需要再装任何CUDA相关的组件。如果是GPU环境提前确认显卡驱动支持的CUDA版本再安装对应版本的torch否则会出现ultralytics装好了但模型训练时还是在CPU上跑的情况。查GPU是否可用在训练前跑这一段import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))输出True和显卡型号说明GPU可用。如果第一行输出False常见原因是torch的CUDA版本和显卡驱动不匹配此时不要动驱动直接卸载torch重新安装带对应cuda的版本更省时间。gtx1660ti这种6GB显存的显卡跑yolov8n没有问题batch调小一点就能稳定训练。CPU不是不能训练只是时间成本高。几百张图的小数据集yolov8n在CPU上跑一百个epoch可能要数个小时适合做功能验证不适合反复调参。如果你的机器只有CPU我更建议先用项目自带的训练好权重跑通推理和界面把精力花在数据增强和界面调试上模型训练放到有GPU的机器上完成。搜索词里有人专门在ubuntu20.04上搭CPU版YOLOv8环境可以明确告诉你CPU版完全能跑通只要不追求训练速度。3.2 训练命令与参数你的batch和epochs真的合适吗环境就绪后训练命令本身很简单核心是把数据集路径、模型骨架、训练轮数、批量大小四个参数设置对yolo detect train \ datadatasets/trash/trash.yaml \ modelyolov8n.pt \ epochs100 \ batch16 \ imgsz640 \ patience20 \ device0modelyolov8n.pt是官方预训练权重它会作为初始参数加载相当于把在COCO数据集上学到的通用特征迁移到你的垃圾桶数据上收敛速度比从零训练快很多。epochs不要拍脑袋写300先按100跑观察损失曲线和mAP变化如果六七十轮后已经收敛再继续跑纯粹浪费时间。batch受显存限制6GB显存跑640分辨率yolov8n下batch16一般能撑住遇到“CUDA out of memory”就减半到8或4。还有一个容易被忽略的是patience20它控制early stopping机制连续20个epoch验证集mAP没有提升就自动停止训练既节省时间又把过拟合风险压下来。小数据集上这个参数非常实用因为垃圾桶满溢的类别少、特征差异大通常七八十个epoch就收敛稳定。如果你要做实验对比不同超参数还可以在命令里加optimizerSGD或optimizerAdamW默认的auto优化器会自己选但手动指定后不同实验之间更有可比性。3.3 训练过程监控损失曲线和mAP怎么读训练结束后项目目录下的runs/detect/train里会生成weights/best.pt和last.pt以及一系列损失曲线图。很多新手直接拿last.pt去部署这是个典型误区。last.pt是最后一个epoch的权重如果后期过拟合了它的泛化能力可能明显比best.pt差。我每次训练完都只认best.ptlast.pt仅用于断点续训。判断权重好坏不要只看loss数字还要结合mAP50和mAP50-95两个指标mAP50表示IoU阈值0.5时的平均精度垃圾分类这种业务场景达到0.9以上已经很好用了mAP50-95更严格适合论文里展示模型精益求精的地方。损失曲线图里重点看box_loss和cls_loss的趋势。如果训练集上一直下降、验证集上先降后升这就是过拟合信号此时应该增加数据增强或者训练更多数据。如果训练集损失正常下降但验证集mAP始终很低问题大概率出在标注质量上先回去检查标注而不是继续调参。训练日志里每个epoch结尾都有单张图片的检测样例图值得翻一翻它比mAP数字更直观地暴露出漏检和误检的问题。4. 可视化界面与实时检测把模型封装成能演示的系统4.1 界面功能拆解图片、视频、摄像头三种输入训练完的模型只是权重文件毕设答辩要演示的是能看的系统。项目里的可视化界面承担的就是这个角色常规设计是左右结构左侧是输入控制区和参数面板右侧是检测结果画面。输入方式一般支持图片、视频文件、摄像头实时画面三种这样答辩时既能现场用摄像头演示也能用录好的视频兜底避免现场摄像头权限问题翻车。界面技术栈通常是PyQt5或Tkinter。PyQt5做出来的界面更接近商用系统的观感控件丰富视频和图像的刷新也好控制Tkinter胜在零额外依赖但实时视频和按钮交互的体验明显粗糙。这个资源里用的是哪套部署教程里会写清楚。如果你打算改成自己的毕设界面建议直接沿用原项目的控件结构只替换主题色和标题栏这样能省下大量开发时间。界面上的关键参数是置信度阈值和IOU阈值通常做成滑块或输入框。阈值调低检出框变多误报增加阈值调高漏检增加。满溢检测这种场景误报比漏报更让人头疼——垃圾桶没满但一直报警用户很快就会忽视系统的提醒所以置信度阈值建议设在0.4到0.5之间做成高中低三档下拉框更方便现场演示。IOU阈值影响的是非极大值抑制的严格程度默认0.5基本不用动调它带来的收益很小。4.2 推理流程与满溢判定从模型输出到界面报警界面逻辑的骨架是初始化一次模型、循环读取画面、把检测结果绘制到画面。关键点在于模型实例只创建一次不要每帧都重新加载否则摄像头模式会卡到没法用。核心推理类的代码一般长这样from ultralytics import YOLO class TrashDetector: def __init__(self, weights_path, conf0.4, iou0.5): self.model YOLO(weights_path) self.conf conf self.iou iou def detect_frame(self, frame): results self.model.predict(frame, confself.conf, iouself.iou, verboseFalse) boxes results[0].boxes status normal overflow_count 0 for box in boxes: cls_id int(box.cls) if cls_id 2: # overflow 对应的类别id overflow_count 1 status overflow break elif cls_id 1: # full 对应的类别id status full return status, boxes满溢判定规则是这个项目的核心业务逻辑。这里的类别id对应trash.yaml里names的顺序即normal为0、full为1、overflow为2。模型输出检测框后程序遍历所有框只要出现overflow类别的检测框界面就进入报警状态同时绘制红色边框和报警文字。如果只有normal或full类别则显示对应状态文本。这样一套规则下来界面的演示效果非常直观——垃圾桶满没满一目了然。摄像头实时推理时画面帧率取决于推理耗时。yolov8n在GPU上单帧推理几十毫秒在CPU上可能到一两百毫秒。界面上显示实时FPS数值比任何文字说明都有说服力答辩时老师看一眼FPS就知道你部署优化的程度。如果要提升流畅度可以在predict时传入imgsz480降低输入分辨率实测帧率提升明显检测精度的损失在垃圾桶这种大目标场景下几乎看不出来。4.3 演示流程设计与答辩亮点准备界面跑通之后下一步是把演示流程设计好。我建议按“本地视频→摄像头→现场互动”的顺序来先播一段视频展示稳定的检测效果再切到摄像头展示实时性最后随机放一个物体到垃圾桶旁边制造“满溢报警”的现场效果。这样做的好处是前两步已经证明系统可用第三步的互动效果无论成功与否都有话题可以展开。答辩时少讲模型结构多讲数据怎么收集、阈值怎么定、误报漏报怎么权衡这些才是老师真正会追问的地方。5. 常见问题与避坑从标注到部署的典型翻车记录5.1 现象训练损失降到很低但检测框全部偏移训练过程看起来一切正常box_loss降得很漂亮但推理时检测框的位置明显偏向图片的左上角或右下角完全对不上垃圾桶。这个问题的原因几乎都是标注文件没有做归一化txt里存的还是像素坐标或者中心点计算时减去的不是宽高的一半而是点坐标。排查方法是找一张训练图片对应的txt文件人工核对如果cx、cy这类归一化坐标出现大于1的值返回转换脚本重新处理。不要试图手动改单个文件要让转换脚本重跑整个标注目录保证所有文件格式一致。5.2 现象训练时报CUDA out of memory6GB显存跑yolov8n还爆显存通常不是模型太大而是batch和imgsz设得过高。batch16爆了就改8还爆就改4或者imgsz从640降到480。如果改了batch仍然不稳定检查一下有没有别的程序占着显存执行nvidia-smi看显存占用情况。我习惯在跑长训练前先看一眼GPU利用率确认没有残留的僵尸进程占用显存。还有一个隐藏因素如果装了多个版本的PyTorch不同版本显存管理方式有差异重装torch可能比调参数更有效。5.3 现象摄像头推理画面严重掉帧界面能跑但画面像幻灯片原因要么是模型每帧重复加载要么是CPU推理扛不住640分辨率的计算量。检查代码里YOLO模型的初始化是不是放在循环外面如果是每帧都执行model YOLO(...)那就是每次推理前都要重新加载权重文件加载一次可能就要一两秒。如果是CPU推理慢把predict时的imgsz降到480甚至320帧率提升非常明显。如果再不够用就先录制一段测试视频放在本地做演示不一定非要依赖实时摄像头很多时候视频演示比现场摄像头还流畅。5.4 现象中文路径导致图片读不出来或乱码Windows下用户名是中文项目又放在桌面上运行时要么图片无法加载要么检测结果无法保存。YOLO和OpenCV对中文路径的支持不好是经典问题网络上一堆帖子教你改编码但最省事的解决方法是把整个项目和数据集的路径改成纯英文比如D:/yolo_trash_project同时确认数据集路径里没有中文字符。这是成本最低的解法不要在代码层面硬解编码问题费时间还不稳定。部署教程里如果提到了这一点说明项目作者已经踩过这个坑。5.5 现象换了数据集训练后类别错乱沿用项目自带的数据集没问题但换成自己的数据集后检测出来的类别标签和实际物体对不上。核心原因是data.yaml里的names顺序和你自己的标注类别顺序不一致模型权重里学到的是类别id不是类别名。训练新数据集时要么新建独立的yaml文件要么把原有yaml里的names从上到下全部改一遍注意nc也要同步修改。这个问题最隐蔽的地方在于loss曲线看起来完全正常模型确实学到了东西只是把“满溢”识别成了“正常”所以换数据集后第一步永远是用几张验证集图片跑一次推理人工确认类别标签正确再继续。6. 进阶模型轻量化、效果验证与部署技巧模型训练收敛后下一步不是急着美化界面而是把模型带到真实场景里去验证。我的习惯是留出一批完全没有参与训练和验证的现场图片单独跑一遍推理统计误检率和漏检率。只盯着训练集上的mAP没有意义垃圾分类场景里一个被漏掉的满溢垃圾桶足以推翻整个演示效果。验证通过后再考虑模型轻量化。yolov8n本身已经是YOLOv8系列最小的骨架进一步的常规做法是导出ONNX再用onnxruntime在CPU上跑推理不依赖PyTorch环境部署时只需要一个onnxruntime运行时对课程设计交付和边缘设备部署都很友好。导出命令一行就够了yolo export modelruns/detect/train/weights/best.pt formatonnx imgsz640导出后拿同一张测试图对比一下PyTorch推理和onnx推理的结果两者检测框和置信度应当基本一致如果差异明显检查导出时是否需要开优化选项。如果目标设备是RK3588这类边缘开发板ONNX还能继续转成OpenVINO或RKNN格式但这是另一个话题毕设阶段做到onnx已经足够展示工程能力。从那以后我每次拿到新的目标检测项目都会强制走一遍“数据检查→短训练验证→真实场景测试”的流程。数据检查花十分钟能省掉后面两天的调参时间真实场景测试能让泛化问题的定位从猜测变成实证。希望这篇拆解能帮你在毕设和课程设计里少踩几个坑把时间花在真正出效果的地方。本文还有配套的精品资源点击获取