简介面向施工安全场景的个人防护装备检测任务这套资料集成了反光衣、安全帽、工作服、施工人员穿戴识别所需的YOLOv5代码与数据标注工具适合目标检测初学者及安全监控系统开发者使用能够快速搭建PPE检测模型并接入现有流程。压缩包内共48个文件整体仅16.25MB主体为16个Python脚本覆盖数据预处理、模型训练、推理检测全流程14个YAML配置文件预设了反光衣、VOC、COCO等训练参数另有预训练权重、4个Shell一键脚本、6张测试图片、3个中文说明文档、1个Jupyter教程以及标签文件目录结构清晰开箱即用。该资源已有143人学习/下载。除了基础的YOLOv5实现还额外提供TensorRT推理优化示例、CVAT标注工具指南和Python演示并附带了建筑分割、火灾烟雾探测等扩展数据集说明配套中英文README详细介绍了数据格式与调用方式可直接用于工地安全帽佩戴、反光衣穿戴等实际检测项目的训练、调优与部署。1. 反光衣服检测数据集与安全帽检测一个 YOLOv5 穿戴检测项目要解决的真问题一张工地抓拍照片里算法要同时回答三件事人头上有没有安全帽身上有没有反光衣工作服穿没穿对。标题里这个 zip就是典型的施工人员穿戴检测项目——用 YOLOv5 训练目标检测数据集识别安全帽、反光衣、工作服和施工人员这几类目标。它能解决的是安全巡检和视频监控的自动判定把原来靠人盯截图的事交给模型做。适合两类人工地安全管理人员想把手动抽查换成自动识别算法落地工程师想拿现成数据快速跑通 YOLOv5 训练自己的数据集。接下来按数据整理、训练、部署的顺序把每条路走一遍顺带把最容易翻车的几个坑点出来。2. 数据整理是第一道坎把 zip 里的标注变成 YOLO 能吃的格式2.1 解压之后先别急着训练三类文件先看清压缩包解压后常见做法是分成 images、labels 和一个类别配置文件。images 里是现场照片labels 里是每张图片对应的 txt 标注文件txt 每一行代表一个目标框格式是固定的五段式类别ID、归一化中心点x、归一化中心点y、归一化宽、归一化高。类别ID 对应关系通常写在 data.yaml 里比如 0 是安全帽1 是反光衣。很多人拿到数据的第一反应是直接开训结果训练时报错找不到标签或者类别数对不上。我一般会先写个统计脚本看看每类有多少个标注框、图片尺寸分布是什么样心里先有个底。import os from collections import Counter label_dir labels # 存放 txt 标注的目录 stats Counter() total_files 0 for f in os.listdir(label_dir): if not f.endswith(.txt): continue total_files 1 with open(os.path.join(label_dir, f), r) as fp: for line in fp: parts line.strip().split() if len(parts) 5: # 标准的 YOLO 格式class xc yc w h stats[parts[0]] 1 print(标注文件数:, total_files) for cls_id, cnt in stats.most_common(): print(f类别 {cls_id}: {cnt} 个标注框)这段脚本的逻辑很简单遍历 labels 目录下所有 txt按行切分后检查是否正好五段是的话就把类别ID 计数加一。参数上要注意的是有些数据集的 txt 里只有四段那是标注工具导出的坐标没做归一化需要回到原始标注重新转换。统计结果里如果某个类别的框数不到几百个训练出来的模型大概率对那个类不敏感这时候要么补数据要么在后续 loss 权重上做调整。图片尺寸分布也值得看一眼用 OpenCV 读几个图的高宽统计一下。如果绝大多数图片是 1080p 以上而训练输入只有 640x640那么原图上的小目标会被压缩得很难认这会直接影响后面小目标漏检的处理策略。2.2 把 VOC 或 COCO 标注转成 YOLO 格式转换脚本与归一化换算拿到的数据不一定天然是 YOLO 格式。很多公开数据集或设备导出的标注是 VOC 的 xml或者 COCO 的 json。这里最常见的做法是写一个脚本把 xml 里的 xmin、ymin、xmax、ymax 转成归一化的中心点坐标和宽高。import xml.etree.ElementTree as ET # 类别名字到 ID 的映射顺序必须和 data.yaml 一致 class_map { helmet: 0, reflective_clothes: 1, work_uniform: 2, person: 3, } def voc_to_yolo(xml_path, out_txt): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.findall(object): name obj.find(name).text if name not in class_map: continue # 不属于目标类别跳过 box obj.find(bndbox) x1 float(box.find(xmin).text) y1 float(box.find(ymin).text) x2 float(box.find(xmax).text) y2 float(box.find(ymax).text) xc (x1 x2) / 2 / img_w yc (y1 y2) / 2 / img_h bw (x2 - x1) / img_w bh (y2 - y1) / img_h lines.append(f{class_map[name]} {xc:.6f} {yc:.6f} {bw:.6f} {bh:.6f}) with open(out_txt, w) as fp: fp.write(\n.join(lines))核心换算公式就四个中心点 x 是 (xminxmax)/2 再除以图片宽中心点 y 同理框宽高是像素差除以图片宽高。这里有个坑值得单独说xml 里的宽高可能和实际图片不一致如果标注工具写错了 size 字段转换出来的框全部偏离。转换后我习惯抽查几张把 YOLO 坐标换算回像素画框对比原图确认没有系统性偏移再进训练流程。COCO 的 json 转换思路一样只是解析方式不同。注意 COCO 里 bbox 的存储是 [x, y, width, height]本身就是左上角加宽高转 YOLO 时中心点 x 是 x width/2 再除以图宽别把 x 和 y 当成了中心点直接算这是最容易错的一步。2.3 数据清洗反光衣过曝、漏标和类别不一致数据整理里最花时间的其实是清洗不是转换。反光衣这个类有个典型问题强光下反光条过曝整件衣服亮成一片白色标注员自己都分不清边界。这类样本不能扔反而要保留因为现场监控就是这个光照条件。我一般会把过曝样本单独做一个子目录统计一下它在数据集中占比如果超过 15%训练时就得靠数据增强来拉平亮度分布。另一类是漏标。一个工人戴了安全帽也被框出来了但身上反光衣被前一个人挡住一半标注员就漏了。对检测模型来说漏标等于告诉它“这种半遮挡的反光衣不算目标”到现场真的出现半遮挡时它就判不出来。处理办法是低置信度的人工复核用 YOLOv5 预训练模型先跑一遍训练集把模型有置信度但没标注框的位置输出成候选列表人眼过一遍确实漏的就补上。类别不一致也常见。有的数据集把安全帽叫 helmet有的叫 safety_hat有的叫 hard_hat。合并多个来源时两个名字被当成两个类别最后 nc 变成 5 或 6模型在区分“帽子种类”上浪费参数。我遇到过最离谱的是某个数据集把 safety_helmet 拆成了三种颜色对戴帽检测来说这毫无意义徒增训练难度。统一类名是转换前就要做的不要在转换脚本里做映射补丁否则后面加数据时还得再补一次。3. YOLOv5 训练自己的穿戴检测模型从数据集划分到超参数调整3.1 用 conda 把 YOLOv5 环境跑起来YOLOv5 的训练环境本身不复杂卡壳的地方多半在依赖版本上。我习惯用 conda 单独建一个环境不碰系统 Python避免包冲突。conda create -n yolov5 python3.9 -y conda activate yolov5 pip install -r requirements.txtrequirements.txt 里锁定了 torch、torchvision、opencv-python 等核心依赖。PyTorch 的安装命令建议去官方页面对应 CUDA 版本生成cu118 或 cu121 取决于显卡驱动支持哪种。这里有个容易栽跟头的点pip install torch默认装的是 CPU 版训练时慢到怀疑人生。装完先跑一句python -c import torch; print(torch.cuda.is_available())输出 True 再继续。3.2 修改 data.yaml 和模型配置类别数改对是第一件事YOLOv5 训练自己的数据集核心配置文件是 data.yaml 和模型 yaml。data.yaml 告诉训练脚本数据在哪、有几类、类别叫什么模型 yaml 里最重要的是 nc 字段类别数不一致会直接报 AssertionError。# data.yaml train: ./datasets/safety/images/train val: ./datasets/safety/images/val nc: 4 names: [helmet, reflective_clothes, work_uniform, person]train 和 val 路径推荐写相对路径并且数据集目录和 YOLOv5 代码目录放在同一个父目录下跨盘符的绝对路径容易在换机器后全部失效。names 的顺序必须和标注 txt 里的类别 ID 严格一致这一点很多人会漏训练出来才发现类别标反了。模型配置文件选择上我一般从 yolov5s.yaml 改起。s 是 small精度适中、训练快先跑通流程再换 m 或者 l。改的方法是复制一份把 nc 改成自己的类别数别的参数保持默认。不要在这里乱改 depth_multiple 和 width_multiple刚入门时高估自己调参能力改完效果不一定变好反而让后续排错更难。3.3 训练命令与超参数说明batch、epoch、imgsz 怎么定跑训练的命令本身不长真正要理解的是那几个参数对训练结果的影响。python train.py \ --data safety.yaml \ --weights yolov5s.pt \ --img 640 \ --batch 16 \ --epochs 100 \ --device 0--weights 用官网的 yolov5s.pt 做预训练权重比随机初始化收敛快得多最终 mAP 也更高。--img 是训练输入尺寸穿戴检测场景里如果监控画面是远景、人很小640 是底线条件允许可以试 960。--batch 直接决定显存占用16 是一个比较稳妥的起步值显存 8G 的卡也能跑但要看具体情况。--epochs 在穿戴检测这种类别少、场景相对固定的任务上100 轮足够看出趋势不用一上来就 300 轮。超参数方面YOLOv5 默认的 hyp.scratch-low.yaml 已经调得比较均衡不需要大改。实际中我会关注三个lr0 初始学习率默认 0.01如果 loss 震荡厉害就降到 0.005mosaic 增强默认开启对小目标多的数据集效果明显hsv_h 和 hsv_s 控制颜色增强幅度反光衣这类颜色特征强的目标hsv_s 调太高会让反光条的荧光色失真导致模型学到错误的颜色特征。3.4 训练日志怎么看loss 曲线和混淆矩阵训练结束后看 runs 目录下的结果文件重点看两个。第一个是 results.png 里的 loss 曲线和 mAP 曲线。正常情况是 train loss 平滑下降val loss 也同步下降最后趋平。如果 train loss 一直降而 val loss 在某个 epoch 后开始回升那就是过拟合早停或者减小模型规模都比硬撑 epochs 有效。第二个是 confusion_matrix.png可以看到安全帽和反光衣之间谁和谁互相误判。还有一个容易被忽略的是 labels.jpg它把训练集标注框的分布可视化出来。如果框的中心点大量集中在图片中心说明数据采样有偏模型对边缘位置的目标天然不敏感。这时候优先补边缘样本而不是调超参数。4. 穿戴检测最典型的 5 个坑现象、原因、解决4.1 反光衣强光过曝导致漏检现象白天阳光直射时反光条完全过曝模型直接漏检黄昏光线弱时反光衣反而清晰检测正常。原因反光衣的材质决定它在某些角度下亮度极高训练集里这类过曝样本太少模型没见过这种形态。另外YOLOv5 在输入端做归一化过高亮度的像素值会被压缩到接近饱和区特征提取层难以区分。解决从现场监控里专门抽一个小时的过曝片段把画面里能看清反光衣轮廓的帧都截出来补进训练集。同时把数据增强里的亮度扰动调大比如把 hyp 文件里的 hsv_v 从默认 0.4 提到 0.6让模型见过更多明暗变化。4.2 安全帽和头部目标混在一起类别边界不清晰现象模型把戴了安全帽的人同时输出两个框一个安全帽框一个脑袋框或者干脆把安全帽框成了人。原因标注阶段没有统一规则。有的标注员把安全帽和人头都框了有的只框安全帽不框人导致模型学到的“person”特征里包含了戴帽和没戴帽两种形态。解决标注规则里明确person 只框没有被安全帽覆盖的可见身体部分安全帽单独框。已标注的数据用脚本批量检查凡是通过计算发现 person 框和 helmet 框的交并比超过 0.7 的人工确认后删掉其中一个。这样类别边界干净模型收敛也快。4.3 远处小目标几乎全部漏检现象在 1080p 监控画面里远处走过来的工人身高只有几十像素安全帽更小训练集里这类样本即使有模型也学不好。原因YOLOv5 在 stride 32 的特征图上做最大尺寸目标的预测一个小安全帽在原图 640 像素的输入里可能只占 4x4 像素下采样几轮后特征几乎消失。解决训练尺寸提到 960 或 1280显存不够就降 batch。仍然漏检的话把远处目标截出来拼成新图做训练样本或者干脆在部署时用后面讲的滑窗推理不要在 640 的输入上死磕小目标。4.4 训练时显存不足 OOM现象训练到一半报 CUDA out of memorybatch 从 16 降到 8 还是崩。原因显存占用不只是 batch 决定的--img 越大特征图占用越大。960 输入下的 batch 16 可能比 640 输入下的 batch 32 更占显存。解决先降 batch 到 4 确认能跑再逐步往上加。另一个实用做法是开梯度累积YOLOv5 里通过--batch配合默认的 accumulate 机制实现等效大 batch显存不变但效果接近大 batch 训练。注意观察日志里的 Accumulate 次数这个值会随着 batch 变化自动调整。4.5 验证集 mAP 高但现场识别差现象测试集 mAP 到 0.85 以上一到现场监控画面就各种漏检错检看起来完全是两个模型。原因这是数据分布差异问题。训练集里大多是近景、光线好的摆拍或网络图现场是远景、逆光、雨天、镜头带灰尘的画面。模型在见过的地方成绩好在没见过的地方自然翻车。解决现场采集 2 到 3 个小时视频按帧抽图把有代表性的帧人工标注后混入训练集重新训练。这是做穿戴检测绕不开的步骤数据分布拉齐之后mAP 的参考价值才成立。玄学地说这一步比调任何超参数都管用。5. 把训练好的模型部署到现场ONNX 导出与推理验证5.1 导出 ONNX带不带 NMS 怎么选训练完的 .pt 权重不能直接给生产环境用常规做法是导出成 ONNX用 ONNX Runtime 或 TensorRT 做推理部署。YOLOv5 的导出命令很简单python export.py \ --weights runs/train/exp/weights/best.pt \ --include onnx \ --opset 12默认导出的 ONNX 带了 NMS 后处理输出直接就是检测框结果方便快速集成但问题在于动态 shape 支持不好且某些版本的 NMS 算子无法被 TensorRT 加速。如果目标是用 TensorRT 做 INT8 量化建议导出时不带 NMS让模型只输出原始预测结果后处理完全自己写。opset 参数也要注意TensorRT 8.x 对 opset 12 支持比较成熟opset 太高反而可能遇到不支持的算子。导完用onnxsim做一次常量折叠能去掉一部分冗余节点文件更小推理更快。5.2 用 ONNX Runtime 跑一次推理验证输出形状导出之后先别急着上 TensorRT用 CPU 跑一次 ONNX Runtime 推理确认整个链路是通的。import cv2 import numpy as np import onnxruntime as ort sess ort.InferenceSession(best.onnx, providers[CPUExecutionProvider]) input_name sess.get_inputs()[0].name img0 cv2.imread(site.jpg) img cv2.resize(img0, (640, 640)) img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img img.astype(np.float32) / 255.0 img img.transpose(2, 0, 1) img np.expand_dims(img, axis0) outputs sess.run(None, {input_name: img}) print(outputs[0].shape) # 例如 (1, 25200, 9)9 4 个类别 5 个框属性这里要理解输出形状的含义以 nc4 为例输出维度是 1x25200x925200 是三个检测尺度特征图上的候选框总数9 是 x1、y1、x2、y2、objectness、4 个类别置信度。拿到原始输出后要做置信度筛选、按类别做 NMS、再把坐标乘回原图缩放比例。很多人在这一步发现结果全空先查预处理再看置信度阈值常见问题是把 0.5 的阈值直接用在 objectness 上而 YOLOv5 最终置信度是 objectness 乘以类别置信度得先做乘法再阈值过滤。5.3 边缘设备上的取舍树莓派 5、边缘盒子怎么选部署目标决定优化方向。树莓派 5 跑 YOLOv5s 级别的模型CPU 推理 640 分辨率勉强到 2 到 3 FPS适合做定时抓拍检测不适合实时视频流。边缘盒子或 Jetson 系列则可以用 TensorRT 加速FP16 下 YOLOv5s 能跑到 30 FPS 以上。在树莓派 5 上部署自己训练的 YOLOv5 模型一个更实际的做法是用 NCNN 或 ONNX Runtime 的 CPU 版本并且把模型替换成 YOLOv5n参数量只有 s 的十分之一左右。实时性要求高的场景优先考虑带 GPU 的边缘盒子同时把输入尺寸从 640 降到 512 甚至 416虽然精度会掉一点但穿戴检测这类目标本身比较大收益明显。注意 TensorRT 版本和 ONNX 算子兼容性先做 FP16 验证性能不够再上 INT8 量化INT8 需要重新校准数据而且反光衣这类高饱和颜色目标在校准后容易出现颜色相关误检务必用现场数据做校准集。6. 进阶技巧用滑窗推理和 TTA 提升小目标召回率穿戴检测项目到后期瓶颈基本都在小目标上。监控点位距离远的时候一个工人可能只占画面高度的一小部分直接用整图推理效果很差。滑窗推理的思路是把大图切成多个有重叠的 640x640 小块分别推理再把结果映射回原图坐标最后做一次全局 NMS。这样做的好处是目标在输入中所占像素变大特征更明显代价是推理次数翻倍需要根据现场算力决定切窗口还是只切关键区域。TTA测试时增强更简单直接。推理时把图片做一次水平翻转和原图结果合并后再做 NMS能让召回率小幅提升对左右对称的穿戴目标尤其有效。YOLOv5 自带了--augment参数开启 TTA部署阶段自行实现通常只做翻转和缩放两种就够了太多增强反而拉低帧率。for y0 in range(0, H - crop_size, stride): for x0 in range(0, W - crop_size, stride): crop img[y0:y0 crop_size, x0:x0 crop_size] # 推理得到框后坐标加上 (x0, y0) 回填到原图坐标系 # 所有窗口的结果拼在一起做一次全局 NMS滑窗的 stride 参数是关键一般取窗口大小的 1/4 到 1/3太小会导致同一目标被多个窗口重复识别太大又会出现跨窗口的漏检。每张 1080p 图用 640 窗口加 50% 重叠大约产生 12 到 16 个窗口边缘设备的实时性压力会大不少所以实际项目里常用的做法是只在检测到人的区域附近做滑窗放大而不是整图切这样预算可控。我现在每次接到穿戴检测需求都会先问一句监控点位是近景还是远景。远景直接上滑窗别指望模型自己在 640 的输入里找出 20 像素高的人近景就正常训练保持部署简单。数据、训练、部署这条链路里数据永远是最值钱的部分先花时间把标注和质量查清楚后面每一步都顺。希望帮到你。本文还有配套的精品资源点击获取