做垃圾分拣这个项目的时候，我用YOLOv5 4.0版本从环境配置、数据集制作到模型训练完整走了一遍，把整条业务流里的实操细节和踩过的坑都梳理出来。这套流程不光是跑通了一个Demo，而是真正在分拣产线上跑过、经过业务验证的，适用于任何固定场景的工业目标检测项目。如果你正准备用YOLOv5做物料分拣、缺陷检测这类任务，这篇文章应该能帮你省下至少两周的摸索时间。1. 项目整体设计与算法选型思路1.1 垃圾分拣业务流到底要解决什么做这个项目之前，我先在合作方的分拣中心产线旁蹲了一段时间。传送带上过来的物料大致是这几类：塑料饮料瓶、易拉罐、纸箱碎片、玻璃瓶，还有其他零散杂物。工人在传送带两侧肉眼识别、手动挑拣，一天八小时下来，漏拣率高、劳动强度大，而且人员流动频繁，培训成本也不低。业务方给的指标很直接：识别准确率不低于92%，误检率控制在5%以内，单次推理耗时不超过50毫秒，要能跟上产线1.5米/秒的传送速度，另外设备要能7乘24小时连续跑。这些指标单独看都不算苛刻，但凑到一起就有点麻烦。我一开始试过两阶段检测方案，准确率确实能到95%以上，但推理速度掉到每秒只有几帧，根本跟不上传送带。后来也试过用分类网络先切割再判断的路子，逻辑复杂不说，对遮挡和小目标处理不理想。折腾了几轮之后，我把方案收敛到了YOLOv5 4.0，这是我在精度、速度和工程复杂度之间反复权衡后的选择。这里多说一句，做工业项目跟做竞赛不一样，竞赛刷一个点可能就够了，但产线项目要考虑的是算法能不能长时间稳定跑、出问题好不好排查、换数据好不好迁移。这也是我把版本锁定在4.0而不是追新版本的原因——4.0的生态资料成熟，社区讨论多，出了任何报错基本都能搜到，这对我这种要快速交付的项目来说价值很大。1.2 YOLOv5 4.0的核心特性与选型依据YOLOv5 4.0是单阶段目标检测框架，核心思路是把目标检测当成回归问题直接做：输入一张图，经过骨干网络提取特征，再通过检测头输出目标的类别概率和边界框坐标。跟两阶段方案最大的区别是少了一个候选区域提取环节，所以速度快。4.0版本在结构上有几个特点值得说：Focus模块：对输入图像做切片操作，把空间信息重排到通道维度上，在早期就完成下采样，比传统的卷积分支更省计算。实测在同样输入尺寸下，Focus层能让前向速度提升约10%。CSPNet骨干网络：把底层的梯度流劈成两条路径再合并，减少重复梯度计算，这也是模型能保持轻量的主要原因。PANet特征金字塔：从顶层到底层多路径融合特征，对小目标的召回有明显帮助。垃圾分拣场景里纸箱碎片、瓶盖这些东西尺寸都不大，这个设计很关键。自适应锚框计算：训练时会根据你的数据集自动重新计算锚框尺寸，不用手工调。在模型规模的选型上，我最终选了yolov5s作为主力模型。对比过m和l版本，m的mAP确实比s高一个多点，但推理时间也上去了，在低算力工控机上跑不稳定。s版本在保证92%以上准确率的前提下，单帧推理在GTX 1660上能跑到20毫秒以内，余量很充足。2. 环境配置：从显卡驱动到跑通Demo2.1 硬件环境与CUDA版本配对先说硬件。训练环境我用的是一台双路工作站，配一张RTX 3060显卡，12GB显存。这个配置在当下算是比较入门的深度学习设备了，跑yolov5s用batch-size 16完全没问题。推理环境是产线上的工控机，用的GTX 1660，6GB显存，跑s模型也够。很多人问要不要上更好的卡，我的看法是：起步阶段没必要。YOLOv5s的显存占用不高，6GB以上就能正常训练，12GB就挺宽裕。真正吃显存的是你设置的batch-size和输入分辨率，这两个参数可以根据卡的情况动态调整。与其纠结买什么卡，不如把数据集做好，这个对最终效果的贡献比显卡大得多。版本匹配这块是新手最容易翻车的地方。我踩过一次坑：装好了CUDA 11.8，结果PyTorch装成了CPU版本，训练时GPU利用率始终是0%。后来学乖了，先查PyTorch官方对CUDA版本的支持表，再反推显卡驱动版本。推荐的版本组合是这样一套：组件推荐版本说明显卡驱动510.x及以上向下兼容CUDA11.3与PyTorch 1.10.1对应cuDNN8.2配合CUDA 11.3Python3.8兼容性最稳PyTorch1.10.1对应build版本支持CUDA 11.3这套组合是我实测过的最稳配置。如果你用的PyTorch是更新的版本，就去官网找对应的CUDA版本，遵循"PyTorch决定CUDA，CUDA决定驱动"这个顺序就不会错。2.2 创建虚拟环境与安装依赖环境我建议用conda来管理。深度学习的依赖关系很乱，特别是装过其他项目的话，不同版本互相污染是常有的事。用虚拟环境隔离是必须的。具体步骤：创建Python 3.8环境：conda create -n yolov5 python=3.8激活环境：conda activate yolov5安装PyTorch，这里要注意用官方源给出的CUDA版本对应的命令，比如CUDA 11.3对应的是pip install torch==1.10.1+cu113 torchvision==0.11.2+cu113拉取代码：git clone -b v4.0 https://github.com/ultralytics/yolov5.git，注意加-b v4.0参数，默认分支现在是更新版本，跟4.0的代码结构有差异进入目录后安装依赖：pip install -r requirements.txtrequirements.txt里大部分是常用库，有可能会跟系统里已有的版本冲突。我遇到比较多的是opencv-python和numpy的版本问题，如果安装时报错，可以先单独升级这两个库再继续。装完之后别急着跑训练，先用自带的推理脚本验证一下环境是通的。找一张测试图片，执行python detect.py --source data/images/，如果能在输出目录里看到画了框的结果图，说明前向推理的链路是通的。这一步能过滤掉绝大多数环境配置问题，后面训练报错排查起来范围会小很多。2.3 训练数据目录结构与自检顺便把训练数据的目录结构也讲一下，因为后面所有操作都依赖这个结构。YOLOv5约定的是images和labels两棵目录树：dataset/ ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/每张jpg图片对应一个同名的txt文件，放在labels目录下。txt里每行表示一个目标，格式是：class_id x_center y_center width height注意这里x_center、y_center、width、height都是相对图片宽高的归一化坐标，范围0到1。比如一张640x640的图，某个目标中心在(160, 320)，宽100，高200，对应的一行就是0 0.25 0.5 0.15625 0.3125。不少新手在这里犯迷糊，用绝对像素值写进去，训练的时候loss直接崩掉。我的习惯是先用脚本批量检查一遍txt文件里的坐标是否都在0到1之间，再开始训练。3. 数据集制作：质量比数量更重要3.1 图像采集的现场要点数据集是这整个项目里投入时间最多的环节，也是决定模型上限的环节。算法圈子里有句话叫"垃圾进，垃圾出"，用在垃圾分拣项目上特别贴切。采集图像的时候，我总结了几个关键点：第一，尽量贴近真实部署场景。因为最终要部署到传送带上，所以采集的时候就要在传送带旁边架摄像头，按实际的角度、高度、光线条件来拍。我们在现场用跟部署同型号的工业相机，以45度俯视角拍摄，帧率15fps，连续录了几小时，再抽帧得到原始图像。这样得到的训练数据跟推理时的分布基本一致，模型泛化问题会少很多。第二，要覆盖环境变化。产线白天和晚上的灯光不一样，晴天和阴天的自然光也不一样，甚至传送带新旧程度都会影响反射。所以我分三个时间段去采：上午、下午、晚上，每个时间段各采一批，保证数据里有足够的光线多样性。第三，类别数目要均衡。我们定义了四个主要类别：plastic_bottle、aluminum_can、cardboard、glass_bottle。每个类别采集了大约600张有效图像。如果某个类别数量特别少，模型就会偏向于不预测这个类别，这在分拣业务里是致命的，因为漏拣意味着物料进错通道。每类600张够不够？我的经验是，对于固定场景、类别外观变化不大的任务，每类300到500张是底线，600张以上效果会比较稳定。如果外观变化大的，比如纸箱有各种颜色和折痕，建议每类至少800到1000张。也不用过度追求数量，关键在多样性和标注质量。3.2 标注流程与格式规范标注工具我用的是labelImg，轻量、跨平台、直接支持YOLO格式导出。标注的时候要注意几个细节：边界框要紧贴目标，不要留太多背景。尤其是玻璃瓶这种透明物体，边界模糊，标注标准要统一。我们定了一条规则：以瓶身主体为准，不包含瓶口螺纹部分。遮挡目标的处理。传送带上的物料经常互相叠压，我的原则是：遮挡超过50%的目标不标注，遮挡小于50%的尽量框全。这个规则要保证所有标注员执行一致，不然标注一致性差了，模型学出来的框会很乱。类别标签拼写要统一。我们吃过亏，有人标成plastic_botle，有人标成plastic_bottle，多了一个字母，训练时被当成两个类。建议在标注前把类名模板固定好，复制粘贴填。标注完之后，用脚本把labelImg生成的XML或TXT文件做一次全量检查。重点检查：有没有空文件漏标了、类别ID有没有超出范围、坐标值是否都在0到1之间、有没有重复标注的同一目标。这一步检查在批量操作里可以避免很多后续问题。3.3 数据增强策略与数据集划分YOLOv5 4.0在训练时默认开启了Mosaic数据增强，把四张训练图片随机拼接成一张。这个增强策略对提升小目标检测能力非常有效，因为拼接之后的图里目标尺寸相对变小了，等于变相增加了小目标样本。对垃圾分拣场景，瓶盖、易拉罐拉环这些小目标，Mosaic的贡献很明显。除此之外，我还开了随机水平翻转、HSV色彩抖动（饱和度、亮度、色调各微调）。这里要注意，垃圾分类场景里有些类别对颜色敏感，比如区分新的铝罐和旧的铝罐，所以色彩抖动我调得比较保守，hsv_h=0.015、hsv_s=0.5、hsv_v=0.4，没有用默认的激进值。数据划分我用的是9:1，即90%训练、10%验证。因为总数不算特别大，验证集太小的话评估结果波动会很大。划分的时候用随机种子固定，保证每次实验的可复现性。4. 模型训练：配置、命令与参数调优4.1 自定义数据集配置文件的修改YOLOv5训练前要准备一个数据集yaml文件，告诉程序去哪儿找数据、分几个类。在data目录下新建一个custom.yaml，内容模板是这样：# 自定义数据集配置 train: /path/to/dataset/images/train val: /path/to/dataset/images/val # 类别数量与名称 nc: 4 names: ['plastic_bottle', 'aluminum_can', 'cardboard', 'glass_bottle']train和val路径建议写绝对路径，避免相对路径引发的各种奇奇怪怪的问题。写相对路径的时候，程序的工作目录必须是项目根目录才行，一旦你从别的目录执行命令就会找不到数据。这个yaml文件里最容易出错的地方是nc和names长度不一致。如果nc写了4，names里只有3个，训练时大概率会报IndexError或者训练出来的模型类别错乱。检查方法很简单，写完之后用一个小脚本读一下yaml，确认nc等于len(names)。4.2 训练命令与关键超参数准备工作做完，训练命令长这样：python train.py \ --data data/custom.yaml \ --cfg models/yolov5s.yaml \ --weights weights/yolov5s.pt \ --batch-size 16 \ --epochs 150 \ --img 640 \ --name garbage_sorting_exp1参数逐个解释：--cfg：指定网络结构定义文件。yolov5s.yaml对应的是s模型的结构，如果想要m或l版本，改这里就行。--weights：预训练权重。强烈建议用官方提供的yolov5s.pt做迁移学习初始化，而不是从零训练。预训练模型在COCO上学习过的通用特征，迁移到我们的小数据集上，收敛速度能快好几倍，最终精度也更高。第一次用需要先下载，几十MB的权重文件。--batch-size：受显卡显存限制。RTX 3060跑16没问题，如果显存不够报CUDA out of memory，就降到8。batch太小训练不稳定，但不是越大越好，16到32是比较常用的区间。--epochs：150轮。我试过100轮和200轮，150轮左右就能稳定收敛，到后面loss曲线基本是平的了。如果验证集mAP已经连续20轮不再提升，可以提前停。--img：训练输入分辨率。640是YOLOv5的标准分辨率，速度和精度平衡最好。试过960的，小目标精度确实有提升，但推理时间几乎翻倍，产线实时性受影响，最终定在640。训练过程中，每轮结束后会在runs/train/garbage_sorting_exp1目录下生成当轮的权重文件。注意看控制台输出的指标：val Objectness、val Classification、mAP@0.5这几个值。我重点关注mAP@0.5，垃圾分拣业务对定位精度要求不算极端，框稍微偏一点不影响分拣，所以mAP@0.5达标就行。4.3 Loss曲线与评估指标解读训练结束后，到runs/train/garbage_sorting_exp1目录下看一眼results.png，里面有训练全程的loss曲线和指标曲线。这里分享几个我总结的读图经验：训练loss和验证loss都在下降，且差距不大，说明模型在正常学习，没有过拟合。如果训练loss还在降、验证loss开始反弹，那就是过拟合了，可以降低epochs、增大数据增强强度，或者加dropout。mAP@0.5曲线训练到后期应该会趋于平缓。如果曲线一直上下震荡，波动超过五个点，先检查验证集是不是太小，或者某些类别的样本数太少。我们遇到过一次这种情况，排查发现验证集里glass_bottle只有三四十张，去掉几张难的样本评估结果就剧烈波动，后来把验证集扩充到每类至少80张，曲线才稳定下来。验证阶段还可以用python val.py --data data/custom.yaml --weights runs/train/garbage_sorting_exp1/weights/best.pt来看详细评估。val.py会生成混淆矩阵和PR曲线，混淆矩阵能直观看到哪些类别互相搞混。我们第一版模型里玻璃瓶和塑料瓶的混淆比较严重，后来分析是标注时透明瓶身边界不统一导致的，重新规范标注之后混淆明显降低。这个过程我建议不要省，它告诉你的不是"模型好不好"，而是"数据哪里有问题"。5. 常见问题与排查技巧实录5.1 训练阶段高频报错与解决这一节是我踩坑最多的地方，整理成一个速查表，遇到问题直接对着查就行。问题现象可能原因解决办法CUDA out of memorybatch-size过大或显卡显存不足调小batch-size，或降低img尺寸到416做试探AssertionError: labels require 5 columns标注txt格式错误检查txt是不是每行5个值，类ID是否为整数IndexError: index 5 is out of boundsnc与实际类别数不对应核实yaml里的nc和names长度NaN loss学习率过高、数据里有损坏图片降低初始学习率，用脚本清理损坏图像Training loss正常但mAP为0验证集路径写错，生成的是空数据集检查yaml中val路径是否存在且非空GPU显存占用0%PyTorch装了CPU版本重装对应CUDA的GPU版PyTorchKeyError: 'val'训练中断后恢复断点时找不到验证集确认yaml中val字段存在模型输出框偏移严重标注坐标用了绝对像素值确认txt中坐标为归一化的0到1浮点数除了查表，这里分享一个通用的排查思路：先把问题缩小到数据、配置、环境三个类别之一。怎么缩小？用最小复现法——把训练命令减到最简：单张图片、batch-size 1、epochs 1。如果这样还报错，说明是配置或数据问题；如果跑通了，再逐步加参数，就能定位是哪个环节触发的。5.2 数据集相关的典型问题数据集方面我遇到的最诡异的一个问题：训练到中途报错，说某个图片解码失败。排查发现那张图是从视频抽帧存下来的，文件扩展名是jpg，实际内容却是其他格式编码。YOLOv5的加载器按扩展名解码，遇到这种伪造扩展名的图就会异常。解决方法是写个脚本把所有训练图片重新解码再编码一次，统一转成标准jpg。还有一个典型问题：标注文件与图片文件不完全同名。比如图片叫image_001.jpg，标注文件叫image_001.txt，没问题。但如果有一张图没有对应标注文件，或者标注文件是多余的，训练时有的报错有的直接跳过，行为不一致。我建议训练前跑一个校验脚本，比对两边文件集的差异并输出清单。5.3 推理阶段的问题排查训练好了不等于部署就顺利。我遇到过最多的问题是模型推理正常，但检测框置信度整体偏低，比如都是0.3到0.5的区间。排查下来发现两个原因：一是训练时的输入分辨率和部署推理时的输入分辨率不一致，YOLOv5对分辨率的敏感度比想象中高；二是图像预处理方式不同，训练时做了色彩增强，推理时的原图直接输入反而让模型不适应。解决方法：在推理脚本里保持跟训练一致的前处理流程，尤其是归一化和resize的方式。YOLOv5官方detect.py里的预处理已经处理好了，如果你是自己写的推理逻辑，一定要对照源码保持一致。6. 模型导出与垃圾分拣业务流集成6.1 模型导出：从PyTorch到生产格式训练完成后，需要把PyTorch格式的权重导出为部署格式。垃圾分拣产线上用的是工控机加普通USB工业相机，没有专用的AI加速卡，所以我优先选择ONNX格式，再用ONNX Runtime进行推理。导出命令很简单：python export.py --weights runs/train/garbage_sorting_exp1/weights/best.pt --include onnx --img 640导出后可以用python detect.py --weights best.onnx --source data/images/test.jpg验证ONNX模型推理结果，跟PyTorch模型的输出做对比。我测过，ONNX的推理结果和PyTorch模型基本一致，mAP差距在0.3个点以内，在可接受范围。如果产线上有TensorRT环境，可以进一步导出engine格式。TensorRT能利用GPU的深度优化，推理速度比ONNX Runtime快30%到50%。我们最终在工控机上实测，TensorRT模式下单帧推理时间稳定在12毫秒左右，完全满足50毫秒以内的要求。6.2 业务流串联：相机、检测、分拣控制部署的逻辑不复杂，但注意点不少。整个业务流是一条单行道：工业相机以固定帧率采集传送带画面将当前帧送入检测模型模型输出检测框和类别ID程序根据类别ID和检测框位置，判断目标对应哪个分拣通道将分拣指令通过串口发送给PLC或者分拣机构记录检测日志和统计数据这里要特别注意一个时序问题：从图像采集到分拣机构动作之间，传送带会把目标往前带一段距离，所以程序里必须做"检测位置加传送带速度"的补偿计算。我们用的公式很简单：补偿距离 = 传送带线速度 ×（检测耗时 + 控制耗时）。如果不做这个补偿，分拣机构永远打在目标的前方或后方。这个坑我们在现场调试时专门踩过，一开始以为检测延迟可以忽略，结果发现1.5米/秒的速度下，100毫秒的延迟就会导致15厘米的偏差，框都打在瓶子左边，机构完全抓不到。后来在程序里加了延迟补偿常量，现场调了几组数值才定位准确。置信度阈值也要单独调。训练阶段用的confidence是0.25，这是官方默认，适合展示效果。业务部署时我们调到了0.55，效果立刻干净很多。理由很简单：分拣业务的误检代价比漏检大，因为误检会把正确物料拨错通道，造成二次污染，所以宁可漏检一些低置信度的目标，也不要误检。这个权衡思路分享给大家，不同业务的阈值调优方向是不一样的。7. 写在最后的一些体会项目收尾之后回头看，这套垃圾分拣检测流程能跑通，最核心的不是某一个模型有多强，而是把数据集、模型、部署三个环节的细节都抠到位了。尤其是数据集环节，我花的时间比模型训练多一倍，但回报也是最大的。训练跑了十几个实验版本，最终效果排第一的版本，用的反而是采集质量最高、标注最规范的那套数据。还有一点想提醒后来者：YOLOv5的版本迭代很快，网上搜到的教程经常混着不同版本的代码逻辑，很多命令在4.0上管用，在新版本上就变了。如果你决定用4.0，就认准4.0的官方仓库和文档，不要混用。下载代码时注意加-b v4.0参数，这个细节能帮你避开很多莫名其妙的兼容问题。最后，产线项目永远是"先跑通，再优化"。不要一上来就追求最佳准确率，先用小数据集、小模型把整条业务链路打通，再逐步增加数据量、调整参数。链路通了，后面每一步优化都是可预期、可控的。这套流程不局限于垃圾分拣，任何用YOLOv5做工业检测的固定场景项目，都可以按这个思路来推进。
做垃圾分拣这个项目的时候，我用YOLOv5 4.0版本从环境配置、数据集制作到模型训练完整走了一遍，把整条业务流里的实操细节和踩过的坑都梳理出来。这套流程不光是跑通了一个Demo，而是真正在分拣产线上跑过、经过业务验证的，适用于任何固定场景的工业目标检测项目。如果你正准备用YOLOv5做物料分拣、缺陷检测这类任务，这篇文章应该能帮你省下至少两周的摸索时间。1. 项目整体设计与算法选型思路1.1 垃圾分拣业务流到底要解决什么做这个项目之前，我先在合作方的分拣中心产线旁蹲了一段时间。传送带上过来的物料大致是这几类：塑料饮料瓶、易拉罐、纸箱碎片、玻璃瓶，还有其他零散杂物。工人在传送带两侧肉眼识别、手动挑拣，一天八小时下来，漏拣率高、劳动强度大，而且人员流动频繁，培训成本也不低。业务方给的指标很直接：识别准确率不低于92%，误检率控制在5%以内，单次推理耗时不超过50毫秒，要能跟上产线1.5米/秒的传送速度，另外设备要能7乘24小时连续跑。这些指标单独看都不算苛刻，但凑到一起就有点麻烦。我一开始试过两阶段检测方案，准确率确实能到95%以上，但推理速度掉到每秒只有几帧，根本跟不上传送带。后来也试过用分类网络先切割再判断的路子，逻辑复杂不说，对遮挡和小目标处理不理想。折腾了几轮之后，我把方案收敛到了YOLOv5 4.0，这是我在精度、速度和工程复杂度之间反复权衡后的选择。这里多说一句，做工业项目跟做竞赛不一样，竞赛刷一个点可能就够了，但产线项目要考虑的是算法能不能长时间稳定跑、出问题好不好排查、换数据好不好迁移。这也是我把版本锁定在4.0而不是追新版本的原因——4.0的生态资料成熟，社区讨论多，出了任何报错基本都能搜到，这对我这种要快速交付的项目来说价值很大。1.2 YOLOv5 4.0的核心特性与选型依据YOLOv5 4.0是单阶段目标检测框架，核心思路是把目标检测当成回归问题直接做：输入一张图，经过骨干网络提取特征，再通过检测头输出目标的类别概率和边界框坐标。跟两阶段方案最大的区别是少了一个候选区域提取环节，所以速度快。4.0版本在结构上有几个特点值得说：Focus模块：对输入图像做切片操作，把空间信息重排到通道维度上，在早期就完成下采样，比传统的卷积分支更省计算。实测在同样输入尺寸下，Focus层能让前向速度提升约10%。CSPNet骨干网络：把底层的梯度流劈成两条路径再合并，减少重复梯度计算，这也是模型能保持轻量的主要原因。PANet特征金字塔：从顶层到底层多路径融合特征，对小目标的召回有明显帮助。垃圾分拣场景里纸箱碎片、瓶盖这些东西尺寸都不大，这个设计很关键。自适应锚框计算：训练时会根据你的数据集自动重新计算锚框尺寸，不用手工调。在模型规模的选型上，我最终选了yolov5s作为主力模型。对比过m和l版本，m的mAP确实比s高一个多点，但推理时间也上去了，在低算力工控机上跑不稳定。s版本在保证92%以上准确率的前提下，单帧推理在GTX 1660上能跑到20毫秒以内，余量很充足。2. 环境配置：从显卡驱动到跑通Demo2.1 硬件环境与CUDA版本配对先说硬件。训练环境我用的是一台双路工作站，配一张RTX 3060显卡，12GB显存。这个配置在当下算是比较入门的深度学习设备了，跑yolov5s用batch-size 16完全没问题。推理环境是产线上的工控机，用的GTX 1660，6GB显存，跑s模型也够。很多人问要不要上更好的卡，我的看法是：起步阶段没必要。YOLOv5s的显存占用不高，6GB以上就能正常训练，12GB就挺宽裕。真正吃显存的是你设置的batch-size和输入分辨率，这两个参数可以根据卡的情况动态调整。与其纠结买什么卡，不如把数据集做好，这个对最终效果的贡献比显卡大得多。版本匹配这块是新手最容易翻车的地方。我踩过一次坑：装好了CUDA 11.8，结果PyTorch装成了CPU版本，训练时GPU利用率始终是0%。后来学乖了，先查PyTorch官方对CUDA版本的支持表，再反推显卡驱动版本。推荐的版本组合是这样一套：组件推荐版本说明显卡驱动510.x及以上向下兼容CUDA11.3与PyTorch 1.10.1对应cuDNN8.2配合CUDA 11.3Python3.8兼容性最稳PyTorch1.10.1对应build版本支持CUDA 11.3这套组合是我实测过的最稳配置。如果你用的PyTorch是更新的版本，就去官网找对应的CUDA版本，遵循"PyTorch决定CUDA，CUDA决定驱动"这个顺序就不会错。2.2 创建虚拟环境与安装依赖环境我建议用conda来管理。深度学习的依赖关系很乱，特别是装过其他项目的话，不同版本互相污染是常有的事。用虚拟环境隔离是必须的。具体步骤：创建Python 3.8环境：conda create -n yolov5 python=3.8激活环境：conda activate yolov5安装PyTorch，这里要注意用官方源给出的CUDA版本对应的命令，比如CUDA 11.3对应的是pip install torch==1.10.1+cu113 torchvision==0.11.2+cu113拉取代码：git clone -b v4.0 https://github.com/ultralytics/yolov5.git，注意加-b v4.0参数，默认分支现在是更新版本，跟4.0的代码结构有差异进入目录后安装依赖：pip install -r requirements.txtrequirements.txt里大部分是常用库，有可能会跟系统里已有的版本冲突。我遇到比较多的是opencv-python和numpy的版本问题，如果安装时报错，可以先单独升级这两个库再继续。装完之后别急着跑训练，先用自带的推理脚本验证一下环境是通的。找一张测试图片，执行python detect.py --source data/images/，如果能在输出目录里看到画了框的结果图，说明前向推理的链路是通的。这一步能过滤掉绝大多数环境配置问题，后面训练报错排查起来范围会小很多。2.3 训练数据目录结构与自检顺便把训练数据的目录结构也讲一下，因为后面所有操作都依赖这个结构。YOLOv5约定的是images和labels两棵目录树：dataset/ ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/每张jpg图片对应一个同名的txt文件，放在labels目录下。txt里每行表示一个目标，格式是：class_id x_center y_center width height注意这里x_center、y_center、width、height都是相对图片宽高的归一化坐标，范围0到1。比如一张640x640的图，某个目标中心在(160, 320)，宽100，高200，对应的一行就是0 0.25 0.5 0.15625 0.3125。不少新手在这里犯迷糊，用绝对像素值写进去，训练的时候loss直接崩掉。我的习惯是先用脚本批量检查一遍txt文件里的坐标是否都在0到1之间，再开始训练。3. 数据集制作：质量比数量更重要3.1 图像采集的现场要点数据集是这整个项目里投入时间最多的环节，也是决定模型上限的环节。算法圈子里有句话叫"垃圾进，垃圾出"，用在垃圾分拣项目上特别贴切。采集图像的时候，我总结了几个关键点：第一，尽量贴近真实部署场景。因为最终要部署到传送带上，所以采集的时候就要在传送带旁边架摄像头，按实际的角度、高度、光线条件来拍。我们在现场用跟部署同型号的工业相机，以45度俯视角拍摄，帧率15fps，连续录了几小时，再抽帧得到原始图像。这样得到的训练数据跟推理时的分布基本一致，模型泛化问题会少很多。第二，要覆盖环境变化。产线白天和晚上的灯光不一样，晴天和阴天的自然光也不一样，甚至传送带新旧程度都会影响反射。所以我分三个时间段去采：上午、下午、晚上，每个时间段各采一批，保证数据里有足够的光线多样性。第三，类别数目要均衡。我们定义了四个主要类别：plastic_bottle、aluminum_can、cardboard、glass_bottle。每个类别采集了大约600张有效图像。如果某个类别数量特别少，模型就会偏向于不预测这个类别，这在分拣业务里是致命的，因为漏拣意味着物料进错通道。每类600张够不够？我的经验是，对于固定场景、类别外观变化不大的任务，每类300到500张是底线，600张以上效果会比较稳定。如果外观变化大的，比如纸箱有各种颜色和折痕，建议每类至少800到1000张。也不用过度追求数量，关键在多样性和标注质量。3.2 标注流程与格式规范标注工具我用的是labelImg，轻量、跨平台、直接支持YOLO格式导出。标注的时候要注意几个细节：边界框要紧贴目标，不要留太多背景。尤其是玻璃瓶这种透明物体，边界模糊，标注标准要统一。我们定了一条规则：以瓶身主体为准，不包含瓶口螺纹部分。遮挡目标的处理。传送带上的物料经常互相叠压，我的原则是：遮挡超过50%的目标不标注，遮挡小于50%的尽量框全。这个规则要保证所有标注员执行一致，不然标注一致性差了，模型学出来的框会很乱。类别标签拼写要统一。我们吃过亏，有人标成plastic_botle，有人标成plastic_bottle，多了一个字母，训练时被当成两个类。建议在标注前把类名模板固定好，复制粘贴填。标注完之后，用脚本把labelImg生成的XML或TXT文件做一次全量检查。重点检查：有没有空文件漏标了、类别ID有没有超出范围、坐标值是否都在0到1之间、有没有重复标注的同一目标。这一步检查在批量操作里可以避免很多后续问题。3.3 数据增强策略与数据集划分YOLOv5 4.0在训练时默认开启了Mosaic数据增强，把四张训练图片随机拼接成一张。这个增强策略对提升小目标检测能力非常有效，因为拼接之后的图里目标尺寸相对变小了，等于变相增加了小目标样本。对垃圾分拣场景，瓶盖、易拉罐拉环这些小目标，Mosaic的贡献很明显。除此之外，我还开了随机水平翻转、HSV色彩抖动（饱和度、亮度、色调各微调）。这里要注意，垃圾分类场景里有些类别对颜色敏感，比如区分新的铝罐和旧的铝罐，所以色彩抖动我调得比较保守，hsv_h=0.015、hsv_s=0.5、hsv_v=0.4，没有用默认的激进值。数据划分我用的是9:1，即90%训练、10%验证。因为总数不算特别大，验证集太小的话评估结果波动会很大。划分的时候用随机种子固定，保证每次实验的可复现性。4. 模型训练：配置、命令与参数调优4.1 自定义数据集配置文件的修改YOLOv5训练前要准备一个数据集yaml文件，告诉程序去哪儿找数据、分几个类。在data目录下新建一个custom.yaml，内容模板是这样：# 自定义数据集配置 train: /path/to/dataset/images/train val: /path/to/dataset/images/val # 类别数量与名称 nc: 4 names: ['plastic_bottle', 'aluminum_can', 'cardboard', 'glass_bottle']train和val路径建议写绝对路径，避免相对路径引发的各种奇奇怪怪的问题。写相对路径的时候，程序的工作目录必须是项目根目录才行，一旦你从别的目录执行命令就会找不到数据。这个yaml文件里最容易出错的地方是nc和names长度不一致。如果nc写了4，names里只有3个，训练时大概率会报IndexError或者训练出来的模型类别错乱。检查方法很简单，写完之后用一个小脚本读一下yaml，确认nc等于len(names)。4.2 训练命令与关键超参数准备工作做完，训练命令长这样：python train.py \ --data data/custom.yaml \ --cfg models/yolov5s.yaml \ --weights weights/yolov5s.pt \ --batch-size 16 \ --epochs 150 \ --img 640 \ --name garbage_sorting_exp1参数逐个解释：--cfg：指定网络结构定义文件。yolov5s.yaml对应的是s模型的结构，如果想要m或l版本，改这里就行。--weights：预训练权重。强烈建议用官方提供的yolov5s.pt做迁移学习初始化，而不是从零训练。预训练模型在COCO上学习过的通用特征，迁移到我们的小数据集上，收敛速度能快好几倍，最终精度也更高。第一次用需要先下载，几十MB的权重文件。--batch-size：受显卡显存限制。RTX 3060跑16没问题，如果显存不够报CUDA out of memory，就降到8。batch太小训练不稳定，但不是越大越好，16到32是比较常用的区间。--epochs：150轮。我试过100轮和200轮，150轮左右就能稳定收敛，到后面loss曲线基本是平的了。如果验证集mAP已经连续20轮不再提升，可以提前停。--img：训练输入分辨率。640是YOLOv5的标准分辨率，速度和精度平衡最好。试过960的，小目标精度确实有提升，但推理时间几乎翻倍，产线实时性受影响，最终定在640。训练过程中，每轮结束后会在runs/train/garbage_sorting_exp1目录下生成当轮的权重文件。注意看控制台输出的指标：val Objectness、val Classification、mAP@0.5这几个值。我重点关注mAP@0.5，垃圾分拣业务对定位精度要求不算极端，框稍微偏一点不影响分拣，所以mAP@0.5达标就行。4.3 Loss曲线与评估指标解读训练结束后，到runs/train/garbage_sorting_exp1目录下看一眼results.png，里面有训练全程的loss曲线和指标曲线。这里分享几个我总结的读图经验：训练loss和验证loss都在下降，且差距不大，说明模型在正常学习，没有过拟合。如果训练loss还在降、验证loss开始反弹，那就是过拟合了，可以降低epochs、增大数据增强强度，或者加dropout。mAP@0.5曲线训练到后期应该会趋于平缓。如果曲线一直上下震荡，波动超过五个点，先检查验证集是不是太小，或者某些类别的样本数太少。我们遇到过一次这种情况，排查发现验证集里glass_bottle只有三四十张，去掉几张难的样本评估结果就剧烈波动，后来把验证集扩充到每类至少80张，曲线才稳定下来。验证阶段还可以用python val.py --data data/custom.yaml --weights runs/train/garbage_sorting_exp1/weights/best.pt来看详细评估。val.py会生成混淆矩阵和PR曲线，混淆矩阵能直观看到哪些类别互相搞混。我们第一版模型里玻璃瓶和塑料瓶的混淆比较严重，后来分析是标注时透明瓶身边界不统一导致的，重新规范标注之后混淆明显降低。这个过程我建议不要省，它告诉你的不是"模型好不好"，而是"数据哪里有问题"。5. 常见问题与排查技巧实录5.1 训练阶段高频报错与解决这一节是我踩坑最多的地方，整理成一个速查表，遇到问题直接对着查就行。问题现象可能原因解决办法CUDA out of memorybatch-size过大或显卡显存不足调小batch-size，或降低img尺寸到416做试探AssertionError: labels require 5 columns标注txt格式错误检查txt是不是每行5个值，类ID是否为整数IndexError: index 5 is out of boundsnc与实际类别数不对应核实yaml里的nc和names长度NaN loss学习率过高、数据里有损坏图片降低初始学习率，用脚本清理损坏图像Training loss正常但mAP为0验证集路径写错，生成的是空数据集检查yaml中val路径是否存在且非空GPU显存占用0%PyTorch装了CPU版本重装对应CUDA的GPU版PyTorchKeyError: 'val'训练中断后恢复断点时找不到验证集确认yaml中val字段存在模型输出框偏移严重标注坐标用了绝对像素值确认txt中坐标为归一化的0到1浮点数除了查表，这里分享一个通用的排查思路：先把问题缩小到数据、配置、环境三个类别之一。怎么缩小？用最小复现法——把训练命令减到最简：单张图片、batch-size 1、epochs 1。如果这样还报错，说明是配置或数据问题；如果跑通了，再逐步加参数，就能定位是哪个环节触发的。5.2 数据集相关的典型问题数据集方面我遇到的最诡异的一个问题：训练到中途报错，说某个图片解码失败。排查发现那张图是从视频抽帧存下来的，文件扩展名是jpg，实际内容却是其他格式编码。YOLOv5的加载器按扩展名解码，遇到这种伪造扩展名的图就会异常。解决方法是写个脚本把所有训练图片重新解码再编码一次，统一转成标准jpg。还有一个典型问题：标注文件与图片文件不完全同名。比如图片叫image_001.jpg，标注文件叫image_001.txt，没问题。但如果有一张图没有对应标注文件，或者标注文件是多余的，训练时有的报错有的直接跳过，行为不一致。我建议训练前跑一个校验脚本，比对两边文件集的差异并输出清单。5.3 推理阶段的问题排查训练好了不等于部署就顺利。我遇到过最多的问题是模型推理正常，但检测框置信度整体偏低，比如都是0.3到0.5的区间。排查下来发现两个原因：一是训练时的输入分辨率和部署推理时的输入分辨率不一致，YOLOv5对分辨率的敏感度比想象中高；二是图像预处理方式不同，训练时做了色彩增强，推理时的原图直接输入反而让模型不适应。解决方法：在推理脚本里保持跟训练一致的前处理流程，尤其是归一化和resize的方式。YOLOv5官方detect.py里的预处理已经处理好了，如果你是自己写的推理逻辑，一定要对照源码保持一致。6. 模型导出与垃圾分拣业务流集成6.1 模型导出：从PyTorch到生产格式训练完成后，需要把PyTorch格式的权重导出为部署格式。垃圾分拣产线上用的是工控机加普通USB工业相机，没有专用的AI加速卡，所以我优先选择ONNX格式，再用ONNX Runtime进行推理。导出命令很简单：python export.py --weights runs/train/garbage_sorting_exp1/weights/best.pt --include onnx --img 640导出后可以用python detect.py --weights best.onnx --source data/images/test.jpg验证ONNX模型推理结果，跟PyTorch模型的输出做对比。我测过，ONNX的推理结果和PyTorch模型基本一致，mAP差距在0.3个点以内，在可接受范围。如果产线上有TensorRT环境，可以进一步导出engine格式。TensorRT能利用GPU的深度优化，推理速度比ONNX Runtime快30%到50%。我们最终在工控机上实测，TensorRT模式下单帧推理时间稳定在12毫秒左右，完全满足50毫秒以内的要求。6.2 业务流串联：相机、检测、分拣控制部署的逻辑不复杂，但注意点不少。整个业务流是一条单行道：工业相机以固定帧率采集传送带画面将当前帧送入检测模型模型输出检测框和类别ID程序根据类别ID和检测框位置，判断目标对应哪个分拣通道将分拣指令通过串口发送给PLC或者分拣机构记录检测日志和统计数据这里要特别注意一个时序问题：从图像采集到分拣机构动作之间，传送带会把目标往前带一段距离，所以程序里必须做"检测位置加传送带速度"的补偿计算。我们用的公式很简单：补偿距离 = 传送带线速度 ×（检测耗时 + 控制耗时）。如果不做这个补偿，分拣机构永远打在目标的前方或后方。这个坑我们在现场调试时专门踩过，一开始以为检测延迟可以忽略，结果发现1.5米/秒的速度下，100毫秒的延迟就会导致15厘米的偏差，框都打在瓶子左边，机构完全抓不到。后来在程序里加了延迟补偿常量，现场调了几组数值才定位准确。置信度阈值也要单独调。训练阶段用的confidence是0.25，这是官方默认，适合展示效果。业务部署时我们调到了0.55，效果立刻干净很多。理由很简单：分拣业务的误检代价比漏检大，因为误检会把正确物料拨错通道，造成二次污染，所以宁可漏检一些低置信度的目标，也不要误检。这个权衡思路分享给大家，不同业务的阈值调优方向是不一样的。7. 写在最后的一些体会项目收尾之后回头看，这套垃圾分拣检测流程能跑通，最核心的不是某一个模型有多强，而是把数据集、模型、部署三个环节的细节都抠到位了。尤其是数据集环节，我花的时间比模型训练多一倍，但回报也是最大的。训练跑了十几个实验版本，最终效果排第一的版本，用的反而是采集质量最高、标注最规范的那套数据。还有一点想提醒后来者：YOLOv5的版本迭代很快，网上搜到的教程经常混着不同版本的代码逻辑，很多命令在4.0上管用，在新版本上就变了。如果你决定用4.0，就认准4.0的官方仓库和文档，不要混用。下载代码时注意加-b v4.0参数，这个细节能帮你避开很多莫名其妙的兼容问题。最后，产线项目永远是"先跑通，再优化"。不要一上来就追求最佳准确率，先用小数据集、小模型把整条业务链路打通，再逐步增加数据量、调整参数。链路通了，后面每一步优化都是可预期、可控的。这套流程不局限于垃圾分拣，任何用YOLOv5做工业检测的固定场景项目，都可以按这个思路来推进。