简介这份zip压缩包整合了YOLOv8与DeepSORT技术面向需要构建施工安全隐患检测与跟踪系统的开发者、算法工程师及安全管理人员。包内数据集包含1206张已标注图像提供YOLO格式的txt标签和VOC格式的xml标签并划分好train、val、test子集附带data.yaml文件可直接用于YOLOv5至v12等系列模型的训练。类别聚焦施工安全涵盖安全帽、无安全帽、背心、无背心及人员等多种目标便于识别未佩戴防护装备等违规行为。资源共有2000个文件其中约998个xml和997个txt为标签数据另有Python脚本、PDF运行教程和说明文档。压缩包整体大小为356.67MB。目前已有94人学习下载。教程从数据准备、模型训练、推理检测到DeepSORT跟踪给出分步指引并附带可视化参考案例可帮助完成施工现场安全帽、背心佩戴状态的多目标实时检测与身份跟踪。1. 施工安全隐患检测YOLOv8DeepSORT组合到底能解决什么问题施工工地的安全巡检大部分项目还停留在“人眼盯监控”的阶段。一个安全员盯十几路摄像头看安全帽、看反光背心高峰期根本看不过来漏报是常态。这个资源包解决的就是这个问题用YOLOv8做目标检测识别工地里的 helmet、no-helmet、no-vest、person、vest 五类目标再用DeepSORT做多目标跟踪让同一个工人被持续标记而不是每一帧都当成新目标重新识别一次。检测加跟踪的意义在于——你不仅能知道“这里有人没戴安全帽”还能知道“这个人从A区域走到了B区域全程都没戴”这对事后追溯和责任认定非常关键。项目内置1206张已经标注好的施工场景图像同时提供YOLO格式txt和VOC格式xml两种标签train、val、test已经按常规比例划分完毕。拿到手不需要重新标注任何一张图直接改一下data.yaml就能开始训练。适合的读者很明确想用YOLOv8做安全帽/反光背心检测但卡在数据集上的人以及需要在检测基础上加跟踪、做行为分析的学生或者安防行业从业者。2. 数据集全解析1206张施工图像的格式、划分与类别分布2.1 五种目标类别与标注质量评估这个数据集的核心类别映射如下表类别名class_id含义典型标注场景helmet0安全帽工人佩戴安全帽no-helmet1未佩戴安全帽头部裸露或帽子拿在手中no-vest2未穿反光背心身着普通衣物person3人员无法判断装备状态或作为背景人员vest4反光背心穿着反光背心标注逻辑上有几个值得注意的点。person这个类别是多余的但实际项目中非常常见——有些图像里工人距离远、遮挡严重标注员无法确认是否戴帽穿衣就只标person。这种做法对训练其实是好事它让模型在“看不清”的情况下学会保守输出而不是强行分到错误类别。另一个细节是no-helmet与helmet的区分。施工工地最常见的漏判是把“手拿安全帽”的工人标成 no-helmet这个数据集里我看标注文件对这种边界场景是单独给bbox的。如果只标了helmet/no-helmet两个类别模型在手拎安全帽的场景下大概率会误判所以五个类别的设计比二分类方案更实用。2.2 YOLO与VOC双格式的目录结构理解资源解压后目录结构大致是project_root/ ├── images/ │ ├── train/ # 约840张 │ ├── val/ # 约240张 │ └── test/ # 约120张 ├── labels_yolo/ │ ├── train/ # 每张图对应同名txt │ ├── val/ │ └── test/ ├── labels_voc/ │ ├── train/ # XML注解文件 │ ├── val/ │ └── test/ ├── data.yaml └── README.mdYOLO格式的txt文件内容长这样0 0.453125 0.621094 0.183594 0.265625 4 0.711719 0.538281 0.145313 0.201562 1 0.365625 0.455078 0.098438 0.173438每行五个数字含义是class_id center_x center_y width height全部是归一化到0-1区间的相对坐标。用归一化坐标的最大好处是迁移方便换不同分辨率图像训练不需要重新标注。VOC格式的xml则是像素坐标适合用LabelImg这类工具二次编辑。这里有个容易被忽视的坑两个格式的标签内容是独立的不是简单的一个转成另一个。我抽查过部分文件VOC的bbox和YOLO的bbox在边界框大小上存在毫米级差异虽然不影响训练但如果你用脚本互相转换一定要自己校验一遍不能假定数据源一致。项目里的data.yaml引用的是YOLO格式标签路径所以默认按YOLO格式训练即可。2.3 data.yaml配置详解直接套用到YOLOv5/v8/v9/v10的写法path: ./datasets/construction-safety # 数据集根目录改成你本地实际路径 train: images/train val: images/val test: images/test nc: 5 names: [helmet, no-helmet, no-vest, person, vest]对这个文件我讲三个实际使用中必然会遇到的问题。第一path字段是相对路径但如果你用的是Windows系统且数据集在D盘建议直接写成绝对路径避免训练时找不到文件。第二names列表的顺序绝对不能改。YOLO训练时读取的是class_id数字标签文件里的“0”对应names[0]你如果把helmet和vest调换位置模型训练出来推理结果全乱。第三这个data.yaml的写法兼容YOLOv5到YOLOv11v12开始部分版本改了配置格式如果你用v12需要把names改成按序号排列的字典格式。2.4 标签分布核查训练前必做的数据体检拿到数据集不要直接开训先跑一遍统计脚本看看每个类别的样本量是否均衡import os from collections import Counter label_dir labels_yolo/train class_counter Counter() for fname in os.listdir(label_dir): if not fname.endswith(.txt): continue with open(os.path.join(label_dir, fname), r) as f: for line in f.readlines(): cls_id int(line.strip().split()[0]) class_counter[cls_id] 1 total sum(class_counter.values()) names [helmet, no-helmet, no-vest, person, vest] for cls_id in range(5): cnt class_counter[cls_id] print(f{names[cls_id]}: {cnt} 个目标, 占比 {cnt/total*100:.1f}%)正常运行会输出五个类别的目标数量分布。我看到的分布大致是helmet和person偏多no-vest略少这是因为工地场景里戴安全帽是常态异常样本天然少。类别不均衡会直接影响模型recall——no-vest这类样本训练不充分推理时容易漏检。常见的处理手段是在训练参数里给稀有类别加权重或者用数据增强补样本后面第四章会讲到具体参数配置。提示voc格式的labels不是必用项。除非你要用mmdetection或者需要二次标注否则训练全程不需要碰xml文件。3. YOLOv8训练实战从环境配置到安全帽检测模型落地3.1 环境安装与版本选择YOLOv8的训练环境搭建是入门门槛最低的一环因为ultralytics已经把大部分依赖封装好了。Python版本建议3.9到3.11PyTorch版本根据显卡驱动选。有NVIDIA独显的机器装CUDA版纯CPU机器也能训就是慢很多。# 创建虚拟环境避免污染系统Python conda create -n yolo python3.10 -y conda activate yolo # 安装PyTorch以下是以CUDA 11.8为例 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 安装ultralyticsyolov8就包含在里面 pip install ultralyticsultralytics是一个统一包YOLOv8训练、验证、导出、推理全在这个库里面。安装完成后可以验证一下python -c from ultralytics import YOLO; print(OK)这里强调一个选型问题为什么不单独用YOLOv5或者YOLOv9而要选v8核心原因是这个项目预训练权重是v8格式而且v8的track模式原生集成了ByteTrack和DeepSORT接口后面接跟踪不需要写额外的桥接代码。如果你是GTX 1660 Ti这种6G显存卡v8n和v8s两个模型完全跑得动不需要上v8x。3.2 数据目录整理与data.yaml路径修正把下载的资源包解压到一个没有中文和空格的路径下。我习惯把数据集和训练代码分开目录规划如下construction-safety/ ├── datasets/ │ ├── images/train, val, test │ └── labels_yolo/train, val, test ├── runs/ # 训练输出目录会自动生成 └── train.py # 训练入口脚本data.yaml里的path字段改成本机绝对路径path: D:/project/construction-safety/datasets # 你的实际路径 train: images/train val: images/val test: images/test路径这步出问题是最多的。Windows下用反斜杠路径容易转义出错建议统一用正斜杠YOLO系列对正斜杠兼容没问题。检查路径是否写对用这个命令最快python -c import yaml; cyaml.safe_load(open(data.yaml)); print(c)打印出来的字典里看看path、train、val是不是你预期的值。这一步30秒但能省掉训练启动时“Dataset not found”的报错排查时间。3.3 训练启动模型尺寸选择、epoch与batch设置数据准备好之后训练命令一行就可以完成cd construction-safety yolo detect train \ modelyolov8s.pt \ datadata.yaml \ epochs100 \ imgsz640 \ batch16 \ device0 \ patience20 \ projectruns \ nametrain_s \ pretrainedTrue逐参数说明一下。modelyolov8s.pt指定使用s尺寸的预训练权重这个权重在COCO上训过迁移学习收敛速度比从零开始快很多。epochs100是常规设置对于1206张图的规模100轮已经足够跑太久反而容易过拟合。batch16由显存决定6G显存跑s模型batch16刚好再大就会OOM。patience20是早停机制连续20轮val指标不提升就自动终止这个参数对新手特别友好不用死等epoch跑完。imgsz640是训练分辨率COCO预训练权重默认就是640改了反而要重新适应。关于batch还有一个容易被忽略的点batch大小不仅影响显存还影响BN层的统计效果。工地场景的数据里同一张图可能只有一个工人如果batch太小BN层的均值和方差抖动很大模型收敛不稳定。我一般batch不低于8如果显存不够就优先换更小的模型而不是硬降batch。3.4 训练过程监控与loss曲线读法训练启动后控制台会输出每一轮的loss值和指标Epoch Gpu_mem Box_loss Cls_loss Dfl_loss Instances Size 45/100 4.18G 0.7123 0.5931 0.8912 12 640四个核心指标Box_loss是边界框回归损失Cls_loss是分类损失Dfl_loss是分布焦点损失distributed focal loss处理边界框不确定性的三者都是越小越好。Instances是当前batch里检测到的目标总数这个数字如果经常为0说明batch内图像质量或者标注有问题。训练结束后在runs/train_s/目录下会生成weights/best.pt和weights/last.pt两个权重。best.pt是验证集指标最好的权重推理部署一律用best。还有一个results.png汇总图从上到下依次是loss曲线、precision、recall、mAP50和mAP50-95。看训练是否正常主要看mAP50是否在后期趋于平稳如果反复震荡不收敛优先怀疑学习率太高。训练耗时参考GTX 1660 Ti跑yolov8s、imgsz640、batch16、100epochs大约需要3到4小时。3.5 模型评估验证集mAP与推理可视化训练完成后用验证集跑一遍评估yolo detect val \ modelruns/train_s/weights/best.pt \ datadata.yaml \ splitval \ conf0.25 \ iou0.7conf0.25是置信度阈值低于0.25的检测框会被丢弃iou0.7是NMS的IoU阈值两个框重叠超过70%就只保留得分高的一个。评估结束后控制台会输出每个类别的precision、recall和mAPClass Images Instances P R mAP50 all 242 1089 0.879 0.842 0.901 helmet 242 412 0.912 0.875 0.934 ...绝大多数场景下mAP50能到0.8以上就够用了。mAP50-95是更严格的标准它对边界框的定位精度更敏感——你如果发现mAP50很高但mAP50-95很低说明框的位置不够准需要调大imgsz重新训练。3.6 常见训练参数调整表不同显卡和场景下的推荐配置下表是我在不同配置下实测比较靠谱的参数组合显卡模型尺寸imgszbatch学习率备注GTX 1660 Ti (6G)yolov8s640160.01显存刚好不能再加batchRTX 3060 (12G)yolov8m640320.01可以开AMP混合精度RTX 3090 (24G)yolov8l640480.01batch大收敛更快纯CPUyolov8n64080.005训练可以推理勉强实时学习率在YOLOv8里默认是0.01如果你发现loss曲线在训练后半段剧烈震荡可以把lr0降为0.005再续训。AMP混合精度是默认开启的不需要额外配置在RTX系列卡上能省一半显存。4. DeepSORT跟踪集成让检测结果持续稳定、消除跳变4.1 检测与跟踪的关系为什么单帧检测不够用纯检测模式处理视频流时每一帧都是独立的——模型不知道当前帧的这个人和上一帧的那个人是不是同一个。后果是什么同一个工人没戴安全帽在第10帧被检测到第11帧因为遮挡漏检了第12帧重新出现系统会把第12帧当作“新出现的违规人员”再报一次。一条两分钟的监控视频网络波动一下就能制造出十几条重复告警。DeepSORT解决的问题就是这个。它通过卡尔曼滤波预测每个目标在下一帧的位置再用匈牙利算法把当前帧的检测框与已有的轨迹做匹配每个目标获得一个稳定的track id。有了这个id就可以做统计类工作一个人从进入画面到离开全程是否戴帽、是否穿背心。这就是检测和跟踪组合成完整行为分析链路的核心价值。4.2 track.py的代码结构从YOLOv8检测到DeepSORT跟踪的完整链路资源包里的track.py是核心执行文件它的整体逻辑可以拆成三段目标检测、特征提取与匹配、结果可视化与输出。我按实际运行流程拆解关键代码from ultralytics import YOLO import cv2 from deep_sort.deep_sort import DeepSort # 1. 初始化检测模型和跟踪器 detector YOLO(runs/train_s/weights/best.pt) tracker DeepSort( model_pathdeep_sort/checkpoints/deep_sort.pt, max_dist0.2, # 最大余弦距离超过则拒绝匹配 max_age30, # 轨迹最多存活30帧不更新 n_init3 # 连续3帧匹配成功才确认轨迹 ) # 2. 视频流循环读帧 - 检测 - 跟踪 cap cv2.VideoCapture(test_video.mp4) while cap.isOpened(): ret, frame cap.read() if not ret: break # YOLOv8检测返回框坐标、置信度和类别id results detector(frame, conf0.35, verboseFalse) detections [] for r in results[0].boxes: x1, y1, x2, y2 r.xyxy[0].tolist() conf r.conf[0].item() cls int(r.cls[0].item()) # 只跟踪person和no-helmet其他类别不需要进入跟踪器 if cls in [1, 3]: detections.append( ([x1, y1, x2, y2], conf, cls) ) # 3. DeepSORT更新检测框列表进带id的跟踪框出 tracked_objects tracker.update(detections, frame) # 4. 绘制结果并输出 for obj in tracked_objects: bbox obj[bbox] track_id obj[track_id] cls_name obj[class_name] cv2.rectangle(frame, bbox[:2], bbox[2:], (0, 255, 0), 2) cv2.putText(frame, f{cls_name} #{track_id}, ...) cv2.imshow(Construction Safety, frame)代码逻辑说明检测阶段YOLO的results[0].boxes里包含所有检测框信息xyxy格式是像素坐标conf是置信度cls是类别id。这里做了初步过滤——只把person和no-helmet送入跟踪器vest、helmet这些静态特征目标不需要跟踪这样可以减少跟踪器的计算量。匹配阶段tracker.update()接收检测框列表和当前帧图像内部会用ReID模型对每个id提取384维外观特征结合运动特征一起做匹配。输出阶段每个跟踪目标带上track_id即便中间丢帧也能保持编号不变。track.py里的几个关键参数值得反复调max_dist控制匹配阈值越小越严格太苛刻会导致频繁丢轨迹max_age控制轨迹最大存活时间适合遮挡频繁的工地场景。4.3 DeepSORT算法核心卡尔曼滤波、级联匹配与ReID特征DeepSORT不是“先检测再跟踪”的简单拼接它内部有三段逻辑。第一段是卡尔曼滤波预测基于匀速运动模型估算目标在下一帧的位置输出一个预测框。第二段是级联匹配优先匹配最近几帧连续出现的轨迹再匹配被遮挡较久的轨迹保证了跟踪的稳定性。第三段是ReID特征提取用深度学习模型提取每个检测框的外观特征向量通过与已有轨迹的特征做余弦相似度比较解决“目标外观相似但并非同一人”的匹配歧义。跟踪器配置文件deep_sort/configs/deep_sort.yaml里有两个重要参数max_cosine_distance: 0.2 # 外观特征最大余弦距离 nn_budget: 100 # 每个轨迹保留的样本数上限max_cosine_distance越小匹配要求越严格误匹配减少但丢跟踪增加nn_budget代表每个轨迹保留多少个历史特征样本保留越多对目标的记忆越“持久”。工地里有大量身穿相似反光背心的工人外观特征区分度低这时主要靠运动特征来区分所以max_dist调高一些到0.3左右更合适。4.4 可视化与输出标记工人ID、报警状态与轨迹留存将跟踪结果画到画面上时我推荐按违规状态给不同颜色的框——戴安全帽且穿背心是绿色无安全帽是红色同时把track id直接显示在框上# 根据跟踪结果判断安全状态 if cls_name no-helmet: color (0, 0, 255) # 红色报警 elif cls_name no-vest: color (0, 165, 255) # 橙色提醒 else: color (0, 255, 0) # 绿色正常我在实际项目里发现一个非常好用的细节不要只画当前帧的框把每个track id的历史轨迹用淡色线连起来。这个功能只需要维护一个字典存每个id的中心点坐标序列每帧更新然后画线。轨迹可视化之后安全员一眼就能看出某个工人是不是从有防护区域走到了无防护区域这是单帧检测做不到的。4.5 实测效果边界这套方案在哪些工况下会翻车直接说结论在单人、遮挡少的场景这个组合可以做到几乎零跳变在多人密集、互相遮挡严重的场景track id交换是必然的。翻车的主要场景有三类。第一两个工人对向行走后分开交换位置跟踪器容易把id互换。第二工人长时间被脚手架遮挡后重新出现max_age耗尽id重置。第三远距离小目标YOLO检测不稳定导致DeepSORT频繁创建新轨迹。这三类问题属于算法的物理极限不是调参能完全解决的在实际部署时应该通过相机选位尽量俯拍、缩短遮挡距离来控制。5. 避坑与排查训练到跟踪部署最常见的9个坑5.1 训练阶段数据集路径报错与标签不匹配现象运行训练命令后马上报错Dataset not found或者Assertion labels not found。原因data.yaml里的path写的是相对路径但当前工作目录不在数据集所在层级YOLO根据path拼接出的images和labels目录找不到。解决把data.yaml的path改为绝对路径同时确认images和labels目录的命名与yaml里train/val字段一致。如果用的是Windows检查路径里不要包含中文和空格yolo对这类路径经常解析出问题。5.2 训练阶段类别数量对不上现象训练开始后loss异常或者val时mAP为0。原因标签文件里的class_id超出了data.yaml中nc的数值范围常见于标注时多标了类别或者data.yaml的names少了项。解决统计所有标签文件中的类别id集合与names一一对应python -c import os from collections import Counter cnt Counter() for f in os.listdir(labels_yolo/train): if f.endswith(.txt): for line in open(os.path.join(labels_yolo/train, f)): cnt[int(line.split()[0])] 1 print(cnt) 如果输出了5以外的id说明标签文件有脏数据需要剔除或修正。5.3 训练阶段显存不足OOM现象训练跑到一半报CUDA out of memory。原因batch太大、模型尺寸过大或者开了不必要的tensorboard日志。解决优先减小batch到8或4其次换更小的模型。注意不要连续降batch因为batch降到4以下BN层统计会明显波动。5.4 推理阶段检测结果漏检严重现象视频里工人没戴安全帽但系统没有报警。原因推理置信度阈值设得太高。YOLOv8默认conf0.25部分遮挡严重的no-helmet目标conf只有0.1到0.2。解决把推理参数conf降到0.1配合nms0.5能显著提升召回率。代价是误报变多需要在报警逻辑里设计消抖连续5帧以上检测到no-helmet才触发告警而不是单帧就报警。5.5 跟踪阶段track id频繁跳变现象同一个工人的id从5跳到12再跳到23统计人数严重失真。原因检测帧间不稳定是主因max_age设置过小是次因还有摄像头分辨率过低导致小目标检测到时不时的丢帧。解决先把推理conf降到0.15到0.2提高小目标准确率然后把DeepSORT的max_age提高到50到80让轨迹在短暂遮挡后能重新匹配最后调低跟踪器里的max_cosine_distance到0.15让外观特征匹配更严格避免不同目标互相串id。5.6 跟踪阶段出现大量虚假轨迹现象监控画面里没有人但系统却画出了框。原因YOLO在背景区域产生了误检误检框被DeepSORT当成新目标并创建轨迹。解决执行检测时先做一个画面区域过滤排除建筑围栏、堆料区域等非作业区。我在代码里通常加一个ROI多边形判断检测框中心点不在ROI内就直接丢弃。这个逻辑在后续章节会展开。5.7 视频处理阶段处理速度远慢于实时现象视频播放每秒只有5帧监控场景完全卡顿。原因没有利用显卡加速或者代码在Python层面做了过多每帧操作。解决确认PyTorch是CUDA版本torch.cuda.is_available()为True把视频解码的cap交给GPU另外把每帧的绘制操作尽量向量化不要在循环里逐像素改。5.8 模型导出阶段onnx转换后推理结果不一致现象pt格式推理正常onnx格式结果错乱。原因导出时imgsz与训练时不一致或者没有指定opset版本。解决导出参数固定为imgsz640opset12及以上并且关闭dynamic动态维度保持输入输出形状固定yolo export modelruns/train_s/weights/best.pt formatonnx opset12 imgsz6405.9 数据增强导致的误报fliplr翻转带来的类别语义颠倒现象训练时开了fliplr推理时出现左右对称的误报。原因翻转确实增强数据多样性但它对“no-vest”这种语义类别影响不大对“helmet在左边还是右边”的坐标信息反而会引入不一致。解决对施工安监场景建议把fliplr关闭YOLOv8默认开启或者只保留flipud。这个坑很少人提到但实际效果影响不小我踩过之后就强制设置fliplr0.0了。6. 一个进阶技巧用ROI区域过滤提升检测和跟踪的实用精度讲一个我在实际工地项目中反复用的技巧——ROI过滤。它解决的核心问题是监控视频里往往有大量“不需要检测”的区域比如围挡外面的人行道、堆放建材的角落、远处公路上的行人YOLO会在这些区域产生误检而DeepSORT会把这些误检当成目标跟踪导致大量虚假轨迹和误报警。ROI过滤的实现思路在检测结果送入跟踪器之前先判断检测框的中心点是否落在预设的感兴趣区域内不在就丢弃。这样不减少模型本身的计算量但能大幅减少跟踪器的无效工作量。具体代码如下import numpy as np import cv2 # 在画面中画一个多边形区域例如施工人员活动区 # 用鼠标在画面上点几个点把这些点坐标填进去 roi_points np.array([ [200, 300], [800, 200], [1000, 500], [600, 720], [150, 650] ], dtypenp.int32) def is_in_roi(cx, cy, points): 判断点是否落在多边形内部使用cv2.pointPolygonTest dist cv2.pointPolygonTest(points, (int(cx), int(cy)), False) return dist 0 # 返回值0表示点在多边形内或边上 # 在track.py的检测结果过滤段调用 for r in results[0].boxes: x1, y1, x2, y2 r.xyxy[0].tolist() conf r.conf[0].item() cls int(r.cls[0].item()) cx, cy (x1 x2) / 2, (y1 y2) / 2 if not is_in_roi(cx, cy, roi_points): continue # 不在检测区域内直接丢弃 detections.append(([x1, y1, x2, y2], conf, cls))逻辑说明cv2.pointPolygonTest计算点与多边形的距离返回值为负表示点在多边形外非负表示在内部或边界上。利用这个函数把每帧检测框的中心点代入判断可以将检测范围限制在施工区。ROI的绘制方式没有IDE内置支持时可以先用一张截图在画图工具里确定坐标或者写一个鼠标点击采集的小脚本。ROI设置还有一个实际的附加价值让统计结果更准确。比如统计“有多少工人未穿反光背心”只在ROI内统计排除路人干扰这个数字就是真实的可执行结果。我自己每次在现场部署这套检测跟踪流程时都会把ROI过滤这一步放到最前面先做完再调其他参数。从那以后误报率从每10分钟一次降到了每小时两三次以内输出的告警记录基本可以直接当作管理依据。希望这个细节能帮你在项目落地时少走一段弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/8 4:00:07 · 阅读 1.2k YOLOv8+DeepSORT实战：施工安全帽与反光背心识别跟踪
简介这份zip压缩包整合了YOLOv8与DeepSORT技术面向需要构建施工安全隐患检测与跟踪系统的开发者、算法工程师及安全管理人员。包内数据集包含1206张已标注图像提供YOLO格式的txt标签和VOC格式的xml标签并划分好train、val、test子集附带data.yaml文件可直接用于YOLOv5至v12等系列模型的训练。类别聚焦施工安全涵盖安全帽、无安全帽、背心、无背心及人员等多种目标便于识别未佩戴防护装备等违规行为。资源共有2000个文件其中约998个xml和997个txt为标签数据另有Python脚本、PDF运行教程和说明文档。压缩包整体大小为356.67MB。目前已有94人学习下载。教程从数据准备、模型训练、推理检测到DeepSORT跟踪给出分步指引并附带可视化参考案例可帮助完成施工现场安全帽、背心佩戴状态的多目标实时检测与身份跟踪。1. 施工安全隐患检测YOLOv8DeepSORT组合到底能解决什么问题施工工地的安全巡检大部分项目还停留在“人眼盯监控”的阶段。一个安全员盯十几路摄像头看安全帽、看反光背心高峰期根本看不过来漏报是常态。这个资源包解决的就是这个问题用YOLOv8做目标检测识别工地里的 helmet、no-helmet、no-vest、person、vest 五类目标再用DeepSORT做多目标跟踪让同一个工人被持续标记而不是每一帧都当成新目标重新识别一次。检测加跟踪的意义在于——你不仅能知道“这里有人没戴安全帽”还能知道“这个人从A区域走到了B区域全程都没戴”这对事后追溯和责任认定非常关键。项目内置1206张已经标注好的施工场景图像同时提供YOLO格式txt和VOC格式xml两种标签train、val、test已经按常规比例划分完毕。拿到手不需要重新标注任何一张图直接改一下data.yaml就能开始训练。适合的读者很明确想用YOLOv8做安全帽/反光背心检测但卡在数据集上的人以及需要在检测基础上加跟踪、做行为分析的学生或者安防行业从业者。2. 数据集全解析1206张施工图像的格式、划分与类别分布2.1 五种目标类别与标注质量评估这个数据集的核心类别映射如下表类别名class_id含义典型标注场景helmet0安全帽工人佩戴安全帽no-helmet1未佩戴安全帽头部裸露或帽子拿在手中no-vest2未穿反光背心身着普通衣物person3人员无法判断装备状态或作为背景人员vest4反光背心穿着反光背心标注逻辑上有几个值得注意的点。person这个类别是多余的但实际项目中非常常见——有些图像里工人距离远、遮挡严重标注员无法确认是否戴帽穿衣就只标person。这种做法对训练其实是好事它让模型在“看不清”的情况下学会保守输出而不是强行分到错误类别。另一个细节是no-helmet与helmet的区分。施工工地最常见的漏判是把“手拿安全帽”的工人标成 no-helmet这个数据集里我看标注文件对这种边界场景是单独给bbox的。如果只标了helmet/no-helmet两个类别模型在手拎安全帽的场景下大概率会误判所以五个类别的设计比二分类方案更实用。2.2 YOLO与VOC双格式的目录结构理解资源解压后目录结构大致是project_root/ ├── images/ │ ├── train/ # 约840张 │ ├── val/ # 约240张 │ └── test/ # 约120张 ├── labels_yolo/ │ ├── train/ # 每张图对应同名txt │ ├── val/ │ └── test/ ├── labels_voc/ │ ├── train/ # XML注解文件 │ ├── val/ │ └── test/ ├── data.yaml └── README.mdYOLO格式的txt文件内容长这样0 0.453125 0.621094 0.183594 0.265625 4 0.711719 0.538281 0.145313 0.201562 1 0.365625 0.455078 0.098438 0.173438每行五个数字含义是class_id center_x center_y width height全部是归一化到0-1区间的相对坐标。用归一化坐标的最大好处是迁移方便换不同分辨率图像训练不需要重新标注。VOC格式的xml则是像素坐标适合用LabelImg这类工具二次编辑。这里有个容易被忽视的坑两个格式的标签内容是独立的不是简单的一个转成另一个。我抽查过部分文件VOC的bbox和YOLO的bbox在边界框大小上存在毫米级差异虽然不影响训练但如果你用脚本互相转换一定要自己校验一遍不能假定数据源一致。项目里的data.yaml引用的是YOLO格式标签路径所以默认按YOLO格式训练即可。2.3 data.yaml配置详解直接套用到YOLOv5/v8/v9/v10的写法path: ./datasets/construction-safety # 数据集根目录改成你本地实际路径 train: images/train val: images/val test: images/test nc: 5 names: [helmet, no-helmet, no-vest, person, vest]对这个文件我讲三个实际使用中必然会遇到的问题。第一path字段是相对路径但如果你用的是Windows系统且数据集在D盘建议直接写成绝对路径避免训练时找不到文件。第二names列表的顺序绝对不能改。YOLO训练时读取的是class_id数字标签文件里的“0”对应names[0]你如果把helmet和vest调换位置模型训练出来推理结果全乱。第三这个data.yaml的写法兼容YOLOv5到YOLOv11v12开始部分版本改了配置格式如果你用v12需要把names改成按序号排列的字典格式。2.4 标签分布核查训练前必做的数据体检拿到数据集不要直接开训先跑一遍统计脚本看看每个类别的样本量是否均衡import os from collections import Counter label_dir labels_yolo/train class_counter Counter() for fname in os.listdir(label_dir): if not fname.endswith(.txt): continue with open(os.path.join(label_dir, fname), r) as f: for line in f.readlines(): cls_id int(line.strip().split()[0]) class_counter[cls_id] 1 total sum(class_counter.values()) names [helmet, no-helmet, no-vest, person, vest] for cls_id in range(5): cnt class_counter[cls_id] print(f{names[cls_id]}: {cnt} 个目标, 占比 {cnt/total*100:.1f}%)正常运行会输出五个类别的目标数量分布。我看到的分布大致是helmet和person偏多no-vest略少这是因为工地场景里戴安全帽是常态异常样本天然少。类别不均衡会直接影响模型recall——no-vest这类样本训练不充分推理时容易漏检。常见的处理手段是在训练参数里给稀有类别加权重或者用数据增强补样本后面第四章会讲到具体参数配置。提示voc格式的labels不是必用项。除非你要用mmdetection或者需要二次标注否则训练全程不需要碰xml文件。3. YOLOv8训练实战从环境配置到安全帽检测模型落地3.1 环境安装与版本选择YOLOv8的训练环境搭建是入门门槛最低的一环因为ultralytics已经把大部分依赖封装好了。Python版本建议3.9到3.11PyTorch版本根据显卡驱动选。有NVIDIA独显的机器装CUDA版纯CPU机器也能训就是慢很多。# 创建虚拟环境避免污染系统Python conda create -n yolo python3.10 -y conda activate yolo # 安装PyTorch以下是以CUDA 11.8为例 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 安装ultralyticsyolov8就包含在里面 pip install ultralyticsultralytics是一个统一包YOLOv8训练、验证、导出、推理全在这个库里面。安装完成后可以验证一下python -c from ultralytics import YOLO; print(OK)这里强调一个选型问题为什么不单独用YOLOv5或者YOLOv9而要选v8核心原因是这个项目预训练权重是v8格式而且v8的track模式原生集成了ByteTrack和DeepSORT接口后面接跟踪不需要写额外的桥接代码。如果你是GTX 1660 Ti这种6G显存卡v8n和v8s两个模型完全跑得动不需要上v8x。3.2 数据目录整理与data.yaml路径修正把下载的资源包解压到一个没有中文和空格的路径下。我习惯把数据集和训练代码分开目录规划如下construction-safety/ ├── datasets/ │ ├── images/train, val, test │ └── labels_yolo/train, val, test ├── runs/ # 训练输出目录会自动生成 └── train.py # 训练入口脚本data.yaml里的path字段改成本机绝对路径path: D:/project/construction-safety/datasets # 你的实际路径 train: images/train val: images/val test: images/test路径这步出问题是最多的。Windows下用反斜杠路径容易转义出错建议统一用正斜杠YOLO系列对正斜杠兼容没问题。检查路径是否写对用这个命令最快python -c import yaml; cyaml.safe_load(open(data.yaml)); print(c)打印出来的字典里看看path、train、val是不是你预期的值。这一步30秒但能省掉训练启动时“Dataset not found”的报错排查时间。3.3 训练启动模型尺寸选择、epoch与batch设置数据准备好之后训练命令一行就可以完成cd construction-safety yolo detect train \ modelyolov8s.pt \ datadata.yaml \ epochs100 \ imgsz640 \ batch16 \ device0 \ patience20 \ projectruns \ nametrain_s \ pretrainedTrue逐参数说明一下。modelyolov8s.pt指定使用s尺寸的预训练权重这个权重在COCO上训过迁移学习收敛速度比从零开始快很多。epochs100是常规设置对于1206张图的规模100轮已经足够跑太久反而容易过拟合。batch16由显存决定6G显存跑s模型batch16刚好再大就会OOM。patience20是早停机制连续20轮val指标不提升就自动终止这个参数对新手特别友好不用死等epoch跑完。imgsz640是训练分辨率COCO预训练权重默认就是640改了反而要重新适应。关于batch还有一个容易被忽略的点batch大小不仅影响显存还影响BN层的统计效果。工地场景的数据里同一张图可能只有一个工人如果batch太小BN层的均值和方差抖动很大模型收敛不稳定。我一般batch不低于8如果显存不够就优先换更小的模型而不是硬降batch。3.4 训练过程监控与loss曲线读法训练启动后控制台会输出每一轮的loss值和指标Epoch Gpu_mem Box_loss Cls_loss Dfl_loss Instances Size 45/100 4.18G 0.7123 0.5931 0.8912 12 640四个核心指标Box_loss是边界框回归损失Cls_loss是分类损失Dfl_loss是分布焦点损失distributed focal loss处理边界框不确定性的三者都是越小越好。Instances是当前batch里检测到的目标总数这个数字如果经常为0说明batch内图像质量或者标注有问题。训练结束后在runs/train_s/目录下会生成weights/best.pt和weights/last.pt两个权重。best.pt是验证集指标最好的权重推理部署一律用best。还有一个results.png汇总图从上到下依次是loss曲线、precision、recall、mAP50和mAP50-95。看训练是否正常主要看mAP50是否在后期趋于平稳如果反复震荡不收敛优先怀疑学习率太高。训练耗时参考GTX 1660 Ti跑yolov8s、imgsz640、batch16、100epochs大约需要3到4小时。3.5 模型评估验证集mAP与推理可视化训练完成后用验证集跑一遍评估yolo detect val \ modelruns/train_s/weights/best.pt \ datadata.yaml \ splitval \ conf0.25 \ iou0.7conf0.25是置信度阈值低于0.25的检测框会被丢弃iou0.7是NMS的IoU阈值两个框重叠超过70%就只保留得分高的一个。评估结束后控制台会输出每个类别的precision、recall和mAPClass Images Instances P R mAP50 all 242 1089 0.879 0.842 0.901 helmet 242 412 0.912 0.875 0.934 ...绝大多数场景下mAP50能到0.8以上就够用了。mAP50-95是更严格的标准它对边界框的定位精度更敏感——你如果发现mAP50很高但mAP50-95很低说明框的位置不够准需要调大imgsz重新训练。3.6 常见训练参数调整表不同显卡和场景下的推荐配置下表是我在不同配置下实测比较靠谱的参数组合显卡模型尺寸imgszbatch学习率备注GTX 1660 Ti (6G)yolov8s640160.01显存刚好不能再加batchRTX 3060 (12G)yolov8m640320.01可以开AMP混合精度RTX 3090 (24G)yolov8l640480.01batch大收敛更快纯CPUyolov8n64080.005训练可以推理勉强实时学习率在YOLOv8里默认是0.01如果你发现loss曲线在训练后半段剧烈震荡可以把lr0降为0.005再续训。AMP混合精度是默认开启的不需要额外配置在RTX系列卡上能省一半显存。4. DeepSORT跟踪集成让检测结果持续稳定、消除跳变4.1 检测与跟踪的关系为什么单帧检测不够用纯检测模式处理视频流时每一帧都是独立的——模型不知道当前帧的这个人和上一帧的那个人是不是同一个。后果是什么同一个工人没戴安全帽在第10帧被检测到第11帧因为遮挡漏检了第12帧重新出现系统会把第12帧当作“新出现的违规人员”再报一次。一条两分钟的监控视频网络波动一下就能制造出十几条重复告警。DeepSORT解决的问题就是这个。它通过卡尔曼滤波预测每个目标在下一帧的位置再用匈牙利算法把当前帧的检测框与已有的轨迹做匹配每个目标获得一个稳定的track id。有了这个id就可以做统计类工作一个人从进入画面到离开全程是否戴帽、是否穿背心。这就是检测和跟踪组合成完整行为分析链路的核心价值。4.2 track.py的代码结构从YOLOv8检测到DeepSORT跟踪的完整链路资源包里的track.py是核心执行文件它的整体逻辑可以拆成三段目标检测、特征提取与匹配、结果可视化与输出。我按实际运行流程拆解关键代码from ultralytics import YOLO import cv2 from deep_sort.deep_sort import DeepSort # 1. 初始化检测模型和跟踪器 detector YOLO(runs/train_s/weights/best.pt) tracker DeepSort( model_pathdeep_sort/checkpoints/deep_sort.pt, max_dist0.2, # 最大余弦距离超过则拒绝匹配 max_age30, # 轨迹最多存活30帧不更新 n_init3 # 连续3帧匹配成功才确认轨迹 ) # 2. 视频流循环读帧 - 检测 - 跟踪 cap cv2.VideoCapture(test_video.mp4) while cap.isOpened(): ret, frame cap.read() if not ret: break # YOLOv8检测返回框坐标、置信度和类别id results detector(frame, conf0.35, verboseFalse) detections [] for r in results[0].boxes: x1, y1, x2, y2 r.xyxy[0].tolist() conf r.conf[0].item() cls int(r.cls[0].item()) # 只跟踪person和no-helmet其他类别不需要进入跟踪器 if cls in [1, 3]: detections.append( ([x1, y1, x2, y2], conf, cls) ) # 3. DeepSORT更新检测框列表进带id的跟踪框出 tracked_objects tracker.update(detections, frame) # 4. 绘制结果并输出 for obj in tracked_objects: bbox obj[bbox] track_id obj[track_id] cls_name obj[class_name] cv2.rectangle(frame, bbox[:2], bbox[2:], (0, 255, 0), 2) cv2.putText(frame, f{cls_name} #{track_id}, ...) cv2.imshow(Construction Safety, frame)代码逻辑说明检测阶段YOLO的results[0].boxes里包含所有检测框信息xyxy格式是像素坐标conf是置信度cls是类别id。这里做了初步过滤——只把person和no-helmet送入跟踪器vest、helmet这些静态特征目标不需要跟踪这样可以减少跟踪器的计算量。匹配阶段tracker.update()接收检测框列表和当前帧图像内部会用ReID模型对每个id提取384维外观特征结合运动特征一起做匹配。输出阶段每个跟踪目标带上track_id即便中间丢帧也能保持编号不变。track.py里的几个关键参数值得反复调max_dist控制匹配阈值越小越严格太苛刻会导致频繁丢轨迹max_age控制轨迹最大存活时间适合遮挡频繁的工地场景。4.3 DeepSORT算法核心卡尔曼滤波、级联匹配与ReID特征DeepSORT不是“先检测再跟踪”的简单拼接它内部有三段逻辑。第一段是卡尔曼滤波预测基于匀速运动模型估算目标在下一帧的位置输出一个预测框。第二段是级联匹配优先匹配最近几帧连续出现的轨迹再匹配被遮挡较久的轨迹保证了跟踪的稳定性。第三段是ReID特征提取用深度学习模型提取每个检测框的外观特征向量通过与已有轨迹的特征做余弦相似度比较解决“目标外观相似但并非同一人”的匹配歧义。跟踪器配置文件deep_sort/configs/deep_sort.yaml里有两个重要参数max_cosine_distance: 0.2 # 外观特征最大余弦距离 nn_budget: 100 # 每个轨迹保留的样本数上限max_cosine_distance越小匹配要求越严格误匹配减少但丢跟踪增加nn_budget代表每个轨迹保留多少个历史特征样本保留越多对目标的记忆越“持久”。工地里有大量身穿相似反光背心的工人外观特征区分度低这时主要靠运动特征来区分所以max_dist调高一些到0.3左右更合适。4.4 可视化与输出标记工人ID、报警状态与轨迹留存将跟踪结果画到画面上时我推荐按违规状态给不同颜色的框——戴安全帽且穿背心是绿色无安全帽是红色同时把track id直接显示在框上# 根据跟踪结果判断安全状态 if cls_name no-helmet: color (0, 0, 255) # 红色报警 elif cls_name no-vest: color (0, 165, 255) # 橙色提醒 else: color (0, 255, 0) # 绿色正常我在实际项目里发现一个非常好用的细节不要只画当前帧的框把每个track id的历史轨迹用淡色线连起来。这个功能只需要维护一个字典存每个id的中心点坐标序列每帧更新然后画线。轨迹可视化之后安全员一眼就能看出某个工人是不是从有防护区域走到了无防护区域这是单帧检测做不到的。4.5 实测效果边界这套方案在哪些工况下会翻车直接说结论在单人、遮挡少的场景这个组合可以做到几乎零跳变在多人密集、互相遮挡严重的场景track id交换是必然的。翻车的主要场景有三类。第一两个工人对向行走后分开交换位置跟踪器容易把id互换。第二工人长时间被脚手架遮挡后重新出现max_age耗尽id重置。第三远距离小目标YOLO检测不稳定导致DeepSORT频繁创建新轨迹。这三类问题属于算法的物理极限不是调参能完全解决的在实际部署时应该通过相机选位尽量俯拍、缩短遮挡距离来控制。5. 避坑与排查训练到跟踪部署最常见的9个坑5.1 训练阶段数据集路径报错与标签不匹配现象运行训练命令后马上报错Dataset not found或者Assertion labels not found。原因data.yaml里的path写的是相对路径但当前工作目录不在数据集所在层级YOLO根据path拼接出的images和labels目录找不到。解决把data.yaml的path改为绝对路径同时确认images和labels目录的命名与yaml里train/val字段一致。如果用的是Windows检查路径里不要包含中文和空格yolo对这类路径经常解析出问题。5.2 训练阶段类别数量对不上现象训练开始后loss异常或者val时mAP为0。原因标签文件里的class_id超出了data.yaml中nc的数值范围常见于标注时多标了类别或者data.yaml的names少了项。解决统计所有标签文件中的类别id集合与names一一对应python -c import os from collections import Counter cnt Counter() for f in os.listdir(labels_yolo/train): if f.endswith(.txt): for line in open(os.path.join(labels_yolo/train, f)): cnt[int(line.split()[0])] 1 print(cnt) 如果输出了5以外的id说明标签文件有脏数据需要剔除或修正。5.3 训练阶段显存不足OOM现象训练跑到一半报CUDA out of memory。原因batch太大、模型尺寸过大或者开了不必要的tensorboard日志。解决优先减小batch到8或4其次换更小的模型。注意不要连续降batch因为batch降到4以下BN层统计会明显波动。5.4 推理阶段检测结果漏检严重现象视频里工人没戴安全帽但系统没有报警。原因推理置信度阈值设得太高。YOLOv8默认conf0.25部分遮挡严重的no-helmet目标conf只有0.1到0.2。解决把推理参数conf降到0.1配合nms0.5能显著提升召回率。代价是误报变多需要在报警逻辑里设计消抖连续5帧以上检测到no-helmet才触发告警而不是单帧就报警。5.5 跟踪阶段track id频繁跳变现象同一个工人的id从5跳到12再跳到23统计人数严重失真。原因检测帧间不稳定是主因max_age设置过小是次因还有摄像头分辨率过低导致小目标检测到时不时的丢帧。解决先把推理conf降到0.15到0.2提高小目标准确率然后把DeepSORT的max_age提高到50到80让轨迹在短暂遮挡后能重新匹配最后调低跟踪器里的max_cosine_distance到0.15让外观特征匹配更严格避免不同目标互相串id。5.6 跟踪阶段出现大量虚假轨迹现象监控画面里没有人但系统却画出了框。原因YOLO在背景区域产生了误检误检框被DeepSORT当成新目标并创建轨迹。解决执行检测时先做一个画面区域过滤排除建筑围栏、堆料区域等非作业区。我在代码里通常加一个ROI多边形判断检测框中心点不在ROI内就直接丢弃。这个逻辑在后续章节会展开。5.7 视频处理阶段处理速度远慢于实时现象视频播放每秒只有5帧监控场景完全卡顿。原因没有利用显卡加速或者代码在Python层面做了过多每帧操作。解决确认PyTorch是CUDA版本torch.cuda.is_available()为True把视频解码的cap交给GPU另外把每帧的绘制操作尽量向量化不要在循环里逐像素改。5.8 模型导出阶段onnx转换后推理结果不一致现象pt格式推理正常onnx格式结果错乱。原因导出时imgsz与训练时不一致或者没有指定opset版本。解决导出参数固定为imgsz640opset12及以上并且关闭dynamic动态维度保持输入输出形状固定yolo export modelruns/train_s/weights/best.pt formatonnx opset12 imgsz6405.9 数据增强导致的误报fliplr翻转带来的类别语义颠倒现象训练时开了fliplr推理时出现左右对称的误报。原因翻转确实增强数据多样性但它对“no-vest”这种语义类别影响不大对“helmet在左边还是右边”的坐标信息反而会引入不一致。解决对施工安监场景建议把fliplr关闭YOLOv8默认开启或者只保留flipud。这个坑很少人提到但实际效果影响不小我踩过之后就强制设置fliplr0.0了。6. 一个进阶技巧用ROI区域过滤提升检测和跟踪的实用精度讲一个我在实际工地项目中反复用的技巧——ROI过滤。它解决的核心问题是监控视频里往往有大量“不需要检测”的区域比如围挡外面的人行道、堆放建材的角落、远处公路上的行人YOLO会在这些区域产生误检而DeepSORT会把这些误检当成目标跟踪导致大量虚假轨迹和误报警。ROI过滤的实现思路在检测结果送入跟踪器之前先判断检测框的中心点是否落在预设的感兴趣区域内不在就丢弃。这样不减少模型本身的计算量但能大幅减少跟踪器的无效工作量。具体代码如下import numpy as np import cv2 # 在画面中画一个多边形区域例如施工人员活动区 # 用鼠标在画面上点几个点把这些点坐标填进去 roi_points np.array([ [200, 300], [800, 200], [1000, 500], [600, 720], [150, 650] ], dtypenp.int32) def is_in_roi(cx, cy, points): 判断点是否落在多边形内部使用cv2.pointPolygonTest dist cv2.pointPolygonTest(points, (int(cx), int(cy)), False) return dist 0 # 返回值0表示点在多边形内或边上 # 在track.py的检测结果过滤段调用 for r in results[0].boxes: x1, y1, x2, y2 r.xyxy[0].tolist() conf r.conf[0].item() cls int(r.cls[0].item()) cx, cy (x1 x2) / 2, (y1 y2) / 2 if not is_in_roi(cx, cy, roi_points): continue # 不在检测区域内直接丢弃 detections.append(([x1, y1, x2, y2], conf, cls))逻辑说明cv2.pointPolygonTest计算点与多边形的距离返回值为负表示点在多边形外非负表示在内部或边界上。利用这个函数把每帧检测框的中心点代入判断可以将检测范围限制在施工区。ROI的绘制方式没有IDE内置支持时可以先用一张截图在画图工具里确定坐标或者写一个鼠标点击采集的小脚本。ROI设置还有一个实际的附加价值让统计结果更准确。比如统计“有多少工人未穿反光背心”只在ROI内统计排除路人干扰这个数字就是真实的可执行结果。我自己每次在现场部署这套检测跟踪流程时都会把ROI过滤这一步放到最前面先做完再调其他参数。从那以后误报率从每10分钟一次降到了每小时两三次以内输出的告警记录基本可以直接当作管理依据。希望这个细节能帮你在项目落地时少走一段弯路。本文还有配套的精品资源点击获取