1. 项目概述1.1 核心需求解析做施工现场安全检测说白了就是解决人盯人管不过来的问题。一个工地几百号人安全员不可能每分钟都盯着每个角落更别说高空作业区、塔吊下方这些危险区域了。传统视频监控虽然装了但大多只是录下来事后回放出了事情才能查根本起不到实时预警的作用。这个项目的核心需求就是用深度学习模型自动识别施工现场的视频画面第一时间发现未戴安全帽、未穿反光衣等违规行为及时报警。我拿到这个标题时第一反应是这里面的施工安全最经典、最落地的一个切入点就是安全帽佩戴检测。当然你也可以扩展到反光衣检测、人员闯入危险区域识别甚至抽烟行为检测但安全帽一定是起步阶段性价比最高的一个。因为安全帽目标相对固定、特征清晰、公开数据集最多做出来的效果也比较容易达到实用的水平。1.2 系统整体功能定位这套系统的定位不是一个纯算法demo而是一个能从数据集出发、训练出模型、跑通检测、最终通过UI界面交互使用的完整闭环。拆开来看包含这几层第一层是数据层。标题里写明了YOLO数据集也就是说你要么自己标注要么使用公开的安全帽数据集按YOLO格式组织成训练集、验证集、测试集。这一步是整个项目的粮仓数据质量直接决定模型上限。第二层是模型层。基于YOLOv8训练目标检测模型识别画面中的人和帽子同时判断人是戴了帽子还是没戴。这一步涉及数据配置、模型选型、训练参数调整等核心工作。第三层是应用层。训练好的模型需要在PyTorch环境下做推理然后通过UI界面让安全员能直接使用。UI界面可以基于Python的桌面框架做也可以做成Web版这个后面细讲。第四层是交付层。标题里有Python项目源码模型意味着最终交付的是一个完整项目别人拉下来能跑、能训练、能检测。要做好这一点环境依赖管理、路径组织、封装程度都要花心思。整个系统的工作流程一句话概括摄像头捕获画面后把每一帧喂给YOLOv8模型模型输出目标边界框人、戴安全帽、未戴安全帽然后后端判断是否存在违规如果违规就触发UI弹窗报警并记录截图。整个过程可以做到实时的25到30帧每秒在普通办公电脑上加GPU都能跑。1.3 适合谁来看这个项目如果你是刚入门的算法工程师或者计算机视觉方向的学生这个项目适合你因为它把数据集准备、模型训练、工程部署一条龙走完了看完能建立一个完整的目标检测项目认知框架。如果你是工地安全管理人员或信息化部门的从业者也适合你了解这套系统的能力边界和部署成本知道该提什么需求、怎么验收供应商交付的模型。如果你是想接私活或者做产品原型的开发者这套架构同样有参考价值。YOLOv8加UI的套路你可以迁移到工厂安全检测、校园防欺凌异常行为识别、仓库禁烟检测等大量场景改数据、换标签、重训一遍就行。这里有一个基础认知我要先讲清楚YOLOv8检测的是画面中的目标是什么、在哪里它不是一个规则引擎。它不像传统程序那样写死如果某区域出现红色物体就报警它是通过成百上千张标注图片自动学习到没戴安全帽的人应该长什么样。这也就意味着数据怎么标、标了多少、画面对不对得准最后都会实打实地反映到效果上。2. 技术选型与方案设计思路2.1 为什么选YOLOv8而不是YOLOv5或Faster R-CNN这个问题几乎每个做目标检测的人都会问一遍我直接给出结论性的对比再说为什么在这个场景里选YOLOv8。先看Faster R-CNN这是两阶段检测器的代表作。它的特点就是一个字准。但因为要先把候选区域找出来再逐框分类速度上必然吃亏在GPU上跑视频流很难达到实时。而施工现场安全检测我们最终要接的是摄像头实时视频流实时性是刚需而不是加分项。一帧画面如果处理时间是200毫秒那人的一个危险动作可能已经过去了报警就会延迟这个场景里延迟的代价是很大的。再看YOLOv5它支持工程化做得很好部署资料丰富在很长一段时间里是行业首选。但YOLOv5是2020年发布的在训练技巧、模型结构上是上一代方案。YOLOv8把C2f模块引入到了骨干网络替换掉了原来YOLOv5的C3结构简单说就是让模型在同样的计算量下能提取到更丰富的梯度流信息特征融合能力更强。加上它自带的Anchor-Free解耦检测头训练收敛速度更快小目标检测能力比如远处的小安全帽也有提升。YOLOv8还有一个很重要的优势是它在官方仓库里把训练、验证、预测、导出一条龙脚本都写得非常直白文档清晰社区活跃。对于需要把它封装进完整项目系统的我们来说YOLOv8这种开箱即用的体验能节省大量开发精力可以把更多时间投入到UI和业务逻辑上。2.2 检测类别的设定思路施工现场安全检测的类别设计说起来简单但很多人在这里踩过坑。我见过有同学一上来就标了几十个类别红帽子、白帽子、蓝帽子、黄色反光衣、红色反光衣、安全绳……结果训练出来的模型一团糟原因在于标注的类别越细每个类别需要的样本量就越多。分类越细类间差异越小模型学起来越吃力。对这个系统来说我建议第一版方案回归最稳妥的四分类目标检测模型类别0person人类别1helmet戴了安全帽类别2no_helmet没戴安全帽如果你要加反光衣检测那就再加两个类别vest和no_vest。但注意加了类别不是简单地多几个标注框每个类别至少需要一两千个有效实例才能保证基本的泛化能力。盲目堆类别是新手最容易犯的错误。这里还要解释一下为什么会存在helmet和no_helmet同时作为类别的设计。很多人一开始的想法是只检测no_helmet没戴帽子的人但这样有一个问题模型学到的特征是人这个整体而不是帽子这个局部模型难以同时兼顾两者的区别。把戴帽和没戴帽都作为独立类别来标本质上是在帮助模型建立人的头部区域与周围环境是否存在安全帽特征的判别边界。推理的时候模型中no_helmet的输出置信度达到了阈值系统就判定违规。2.3 UI界面方案选型对比UI界面是这套系统能不能给安全员实际使用的关键但很多人不重视觉得有个模型就行了。实际从落地角度看UI的重要性不亚于模型效果。我对比过三个方案的主要差异第一个方案是PyQt5/PySide6桌面客户端。PySide6是Qt官方支持Python绑定的版本做出来的界面原生感强支持多线程、定时器、拖拽布局适合做单机版工具。缺点是打包分发比较麻烦PyInstaller打包时依赖处理不处理好会体积大且运行报错。第二个方案是Streamlit纯Web界面。Streamlit的优势是开发极快一个脚本跑起来浏览器里就能操作。只需要几十行代码就可以搞出文件上传、摄像头切换、检测结果展示和置信度滑条这些功能。缺点是不适合做复杂的界面布局权限管理、多页面联动做起来比较别扭。第三个方案是Flask/FastAPI加前端页面。这是生产环境最正统的搭配。FastAPI做模型推理服务前端负责视频流展示和交互。但开发量比较大需要同时处理前后端两端。我给这个项目选的是PySide6桌面端。理由有三点第一工地安全员操作电脑的习惯更接近桌面软件打开就能用第二视频流实时显示、报警弹窗、历史记录这些功能在Qt框架下有现成的组件和成熟的信号槽机制逻辑清晰第三作为一个标题中标明UI界面的交付项目桌面端UI视觉效果更可控截图展示和录制讲解都方便。2.4 项目整体技术架构按我上述的决策整体技术栈如下表所示层次技术选型职责说明开发语言Python 3.9算法库生态最完整UI库绑定成熟深度学习框架PyTorch 2.xYOLOv8官方训练和推理的基础框架模型结构YOLOv8s或YOLOv8n平衡检测速度与精度的两个候选模型推理实现ultralytics YOLO库封装好的load模型、predict接口UI框架PySide6桌面界面、摄像头调用、报警交互数据集格式YOLO txt格式每张图片对应一个txt标注文件界面调用摄像头OpenCV视频流采集、帧预处理、图像保存整个流程可以概括为四个阶段数据处理阶段把标注数据整理为训练集和验证集训练阶段在GPU上完成YOLOv8模型训练处理阶段把模型导出为适合部署的格式并封装推理类最后是UI阶段把推理类嵌入到PySide6界面中形成完整系统。架构上有一个关键决策要提前定UI界面只负责展示和交互不直接承载模型推理逻辑。我会单独抽象一个Detector类负责加载权重、预处理图像、解析模型输出、返回检测结果列表。UI和Detector之间只通过这个类的方法交互。这样做的目的是便于后续做并发测试、接入真实监控流时替换成异步推理服务而不用动UI层。3. 数据集准备与标注要点3.1 数据来源与选型方法YOLOv8的数据集组织本身不复杂难的是数据的丰富度和标注质量。很多同学问数据集从哪来我梳理一下几条路第一条路是用公开数据集。安全帽检测最常用的是一个公开的工业安全数据集包含几千张不同场景的工地图片标注了人的位置和安全帽佩戴状态。这类数据集的优点是量大、已标注好缺点是场景相对单一摄像头角度多为平视对俯拍、逆光、夜间场景的覆盖不够。第二条路是自己采集标注。用手机或者工地监控系统的历史视频截帧从视频里每隔几秒抽一帧获得原始图片然后用labellmg或者X-AnyLabeling之类的工具手动画框标注。这条路最费时间但数据最有价值因为你自己的工地环境和数据集场景一定不一样模型最后的泛化能力一大半靠这些现场数据撑起来。第三条路是公开数据集加自采数据混合。我个人强烈推荐这种方式。用公开数据集做base保证基本泛化能力再采集200到500张你目标场景的现场图片做补充让模型适应真实环境光照、角度和背景。最终效果通常比单一来源好很多。3.2 YOLO格式标注详解YOLO的标注格式很多人第一次接触会懵每张图片对应一个同名txt文件一行表示一个目标框五个数字依次是类别编号、中心点x坐标归一化、中心点y坐标归一化、框宽w归一化、框高h归一化。举个例子假如一张1920x1080的图片中一个人头顶框的左上角坐标是(200, 150)右下角是(260, 300)那么这个框对应到YOLO格式要这样换算中心x是(200260)/2230除以宽1920得到0.1198中心y是(150300)/2225除以高1080得到0.2083宽是60除以1920等于0.0313高是150除以1080等于0.1389。最后这一行是1 0.1198 0.2083 0.0313 0.1389。我见过太多同学在这个环节出错。第一坐标必须归一化直接填像素坐标模型会报错第二类别编号从0开始别想着从1开始数No_helmet如果定义成类别0就统一写0第三txt文件命名必须跟图片完全一致包括扩展名之前的文件名部分。标注是体力活要有心理准备。我建议用X-AnyLabeling这类半自动标注工具它可以先加载一个预训练模型做自动标注人工只需要修正框的位置和类别效率能提高一倍以上。3.3 数据集目录组织与训练集划分一个标准的YOLOv8数据集项目目录长这样dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yamldata.yaml里面指定了类别数量和类别名path: dataset_path # 数据集根目录 train: images/train # 训练图片路径 val: images/val # 验证图片路径 nc: 3 # 类别数 names: [no_helmet, helmet, person] # 类别名顺序和标注编号对应这里有个细节要注意训练脚本不会自动校验你的类别名和标注文件里的类别编号是否对应。如果你标注时规定0是helmet1是no_helmet但data.yaml里names的顺序反了模型训练的时候不会报任何错误但验证效果和后期推理时你会看到预测结果张冠李戴。这一步写一个小的校验脚本遍历所有labels下的txt文件看类别编号的最大值是否等于nc-1能帮你提前规避这种问题。训练的划分比例我一般用训练集占80%验证集占10%测试集占10%左右。如果数据量比较少至少保证验证集不少于100张且验证集图片与训练集不能有重叠。还要注意一点不要把所有来自同一段视频的连续帧全都放进训练集否则模型学到的是同一个场景的画面特征验证集稍微有点不同效果就掉下来。这一点在制作数据集时就要有意识地打散。4. YOLOv8训练实操与模型优化4.1 环境搭建先把训练环境搭建明白。我的推荐配置是Python 3.9以上PyTorch 2.x版本具体指令对新手来说直接按官方文档来的最靠谱pip install ultralytics torch torchvision opencv-python注意一点ultralytics这个库本身会把训练依赖都带进来包括tensorboard、pandas这些所以理论上你只需要装它就能跑通了。但如果你要训练GPU支持是必要条件。CPU能跑训练但一个几百张的数据集在CPU上训练几十个小时是很正常的事几乎不可接受。有条件至少上NVIDIA显卡哪怕是GTX 1660这种老将训练速度也比CPU强一个量级。检测一下CUDA环境是否可用import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))4.2 模型选型n还是sYOLOv8有n/s/m/l/x五个模型规格有什么区别呢简单说n是nano微型版参数大约320万速度最快精度最低s是small小版参数约1110万速度和精度的平衡点在要求不高时最舒服再往上m、l、x越跑越慢对小数据集还容易过拟合。对施工现场安全检测来说我的建议是先上YOLOv8s原因是安全帽是一个相对简单的目标类别s模型的容量已经完全够用它比n在精度上通常能高出几个百分点而速度依然可以跑到50毫秒一帧以内。如果是部署到嵌入式设备或者边缘计算盒子那再换回n用TensorRT加速后也能有不错的表现。4.3 训练命令与关键参数解析YOLOv8的训练命令在ultralytics里就是一行yolo detect train datadataset/data.yaml modelyolov8s.pt epochs100 imgsz640 batch16 device0但每个参数背后的逻辑要讲透batch批次大小在合理的范围内能大尽量大。batch太小会导致梯度的估计噪声大收敛不稳定batch太大又对显存要求高。一块12GB显存跑YOLOv8simgsz640下batch用16是稳的显存紧张就降到8。新手常犯的错误是imgsz设631这种奇葩数YOLOv8做Mosaic增强时要求输入尺寸能被32整除你用640或者672千万别用随机数。epochs训练轮数这个参数经验性很强。小数据集300-500张图100轮足够收敛了数据集到几千张的话建议加到150-200轮。不是越多越好轮数过多会在验证集上出现过拟合具体表现为训练损失持续下降但验证精度不再提升。imgsz输入分辨率640是默认值也是性价比最高的值。提高到1280可以看到更远的细节但训练速度和推理速度都翻倍往上涨。对安全帽这种中等大小的目标640就够不必贪高。训练过程中重点看两个指标val/box_loss持续下降说明边界框回归进展正常val/cls_loss持续下降说明分类学得不错。等到60轮左右每轮结束后验证集上会输出mAP50和mAP50-95如果mAP50已经达到95%以上后面几十轮基本只是在微调可以提前停止。4.4 训练后模型评估与调优路径训练完成后模型会存在runs/detect/train/weights/目录下best.pt是验证集表现最好的权重last.pt是最后一轮的权重。实际部署用best.pt没有第二个选择。用验证集评估看一下每类别的表现from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) metrics model.val(datadataset/data.yaml) print(metrics.box.map) # mAP50-95 print(metrics.box.map50) # mAP50 print(metrics.box.ap) # 每个类别的AP常见的调优路径分几种情况如果所有类别的mAP都低先怀疑数据量不足或标注质量有问题回去补数据而不是调参如果某个类别的AP明显低于其他类别比如no_helmet总是比helmet低10个点这说明这个类别的标注框数量太少或者图片中这类目标的形态差异太大需要去统计数据集里该类别的目标数量不够就定向补充删掉置信度过低的、漏标的框重新训练。还有一个容易被忽视的点检查模型是不是对帽子和头同时打框。这种情况通常出现在同一目标被不同标注者标了多个框或者模型分不清一个安全帽同时框了两个人。解决方法是标注时明确规则戴帽的情况只框帽子区域不戴帽只框头部区域。框的大小尽量一致不要有些标签框得紧、有些框得特别松。4.5 模型导出与推理封装训练好的best.pt在推理时可以直接使用但它加载的是PyTorch的权重格式有依赖PyTorch环境的限制。实际部署时我会导出成一个纯ONNX格式或者直接导出engine格式做TensorRT加速按需求来。导出ONNXyolo export modelruns/detect/train/weights/best.pt formatonnx imgsz640导出之后建议用ONNX Runtime验证一下推理结果和原来PyTorch的差异确保导出过程没有把图结构搞坏。我踩过一次坑导出时imgsz写了640但代码里推理时喂了1280的输入ONNX Runtime直接报维度不匹配的错排查半天才搞清楚。推理代码的核心其实很简洁from ultralytics import YOLO model YOLO(best.pt) results model.predict(frame, conf0.45, imgsz640, verboseFalse) boxes results[0].boxes for box in boxes: cls int(box.cls[0]) conf float(box.conf[0]) xyxy box.xyxy[0].tolist()conf阈值是一个需要体会的参数。设得太低比如0.25模型会输出很多误报框把背景里的帽子形状物体当成安全帽设得太高比如0.8又会有不少漏检真没戴帽的人不被报警。在安全检测这种宁可多报不可漏报的场景里我通常把conf设在0.4到0.5之间再用一个后置逻辑过滤对同一个目标连续若干帧持续报警避免单帧误检导致的抖动。5. UI界面设计与系统集成5.1 界面功能规划UI界面的开发在这个项目里的地位不低。安全员不是程序员界面要做到打开就会用的程度才算合格。我规划的界面布局分四大块顶部是状态栏显示当前视频源本机摄像头还是视频文件、模型文件路径、推理耗时。左侧是主视频显示区实时画面上面叠加检测框戴帽的人显示绿色框未戴帽的人显示红色框。检测框的绘制用OpenCV完成的把模型输出的坐标转成画图操作直接叠加在帧上cv2.rectangle(frame, (x1, y1), (x2, y2), color, thickness2) cv2.putText(frame, f{label} {conf:.2f}, (x1, y1-5), cv2.FONT_HERSHEY_SIMPLEX, 0.6, color, 2)右侧是报警信息面板显示报警时间、违规人数、截图缩略图。一旦有no_helmet目标出现系统会立即抓帧保存到存档目录同时在界面上弹出提醒。底部是控制区包括开始检测停止检测选择视频打开摄像头调整置信度阈值的滑条等按钮。5.2 多线程处理架构UI界面最怕的一件事就是点击开始检测后整个窗口卡死鼠标都动不了。这是因为视频帧处理和目标检测都是耗时操作如果放在UI主线程里执行主线程被阻塞界面就无法响应事件。解决办法是多线程。PySide6中有一个QThread机制把视频读取和推理循环放到一个工作线程里这个线程每处理完一帧图像就通过信号把结果发回主线程主线程只负责更新界面。这样即使推理速度比较慢界面依然可以响应停止按钮、滑条等交互。偷懒的方案是用Python的threading模块来起一个后台线程但线程内部如果要去修改Qt的界面元素会导致很多莫名其妙的崩溃。Qt控件只能在主线程操作跨线程操作是Qt框架的硬性约束这一点务必记住。5.3 信号槽通信的关键实现一个简化版的Qt线程逻辑可以这么写class DetectionThread(QThread): frame_processed Signal(QImage, list) # 处理后的画面 检测结果 def run(self): while self.running: ret, frame cap.read() if not ret: break results detector.predict(frame) drawn draw_boxes(frame, results) self.frame_processed.emit(to_qimage(drawn), results)主界面里这样连接self.detection_thread.frame_processed.connect(self.update_display)update_display方法里只需要做两件事把传过来的QImage显示到QLabel上以及把检测结果更新到报警列表里。这套架构写完之后整个系统跑起来界面非常流畅。退出程序时还有一个坑多线程还在跑循环主窗口直接close会出现程序无法正常退出的现象。标准的做法是在closeEvent里先设置一个结束标志位然后调用thread.wait()等待线程退出后再结束进程。5.4 报警逻辑与信息留存报警逻辑看似简单其实需要设计。如果连续几十帧都检测到未戴帽的人员每次都触发弹窗那安全员会崩溃。我实现了一套基于时间窗口的去重机制以10秒为窗口同一个类别连续触发时只在第一次触发和最后一次触发时记录报警中间过程只在列表里刷新次数。报警信息要能追溯。截图的保存路径建议按日期和时间分层组织alerts/ ├── 2025-06-10/ │ ├── 08_25_13_no_helmet.jpg │ ├── 08_25_23_no_helmet.jpg文件名精确到秒方便事后回溯。连同检测置信度和目标框坐标可以一并写入一个csv日志后续做周报统计值班的人也能用。这里有一个设计上的取舍报警是立即弹出还是等待确认。我见过一些商用系统做的是检测到违规后先语音播报再弹窗安全员点确认后关闭。语音播报用Qt的QSoundEffect播放一个预先录制好的提示音即可成本低、效果好。6. 实操过程与核心环节实现6.1 完整实操流程概览下面把这个项目的全过程按照时间线和操作步骤梳理一遍你可以对照着准备你的开发环境。第1步准备数据集。下载公开安全帽数据集或者混合自己采集的现场图片把目录整理成images和labels结构确认data.yaml配置正确。第2步训练模型。用yolo detect train命令跑起来观察训练日志确认mAP50和mAP50-95达标。第3步模型评估与调优。在验证集上逐类别看精度指标如果第2步结果不理想回到第1步补数据或修标注重训。第4步搭建推理服务模块。新建一个detector.py文件封装YOLO模型的加载和predict方法并写几个单元级别的测试确认推理输出格式。第5步开发UI界面。创建PySide6工程先做出主窗口布局再嵌入摄像头读取和推理线程调试报警逻辑。第6步系统联调。用一段工地监控视频文件先跑通全流程再切换到真实摄像头测试。确认报警截图正确存档界面无卡死退出无残留进程。第7步打包交付。使用PyInstaller对项目进行打包生成可执行文件在未安装Python环境的机器上测试。这是一条标准路径每一步之间都存在依赖关系跳步骤大概率导致返工。我在第4步和第5步之间体会最深如果先把推理模块独立开发好测试通过后再接UI排错效率会高很多反过来边写UI边调模型输出格式两个问题搅在一起找bug的时间会翻倍。6.2 detector.py核心实现详解封装推理模块是我强烈建议做对的第一步。一个合格的detector.py至少要实现两个方法class Detector: def __init__(self, model_path, conf_threshold0.45, devicecpu): self.model YOLO(model_path) self.conf_threshold conf_threshold def predict(self, frame): results self.model.predict( frame, confself.conf_threshold, imgsz640, verboseFalse ) boxes results[0].boxes detections [] for box in boxes: detections.append({ bbox: box.xyxy[0].tolist(), cls: int(box.cls[0]), conf: float(box.conf[0]), }) return detections这里有一个经验点初始化时加载模型不要在每一帧predict时都加载一次模型。YOLO对象内部加载权重和构建网络图的耗时大概在几百毫秒到1秒之间如果每帧都干一次整个系统直接没法跑。模型实例只创建一次其他所有地方都复用这个实例。device参数也要想清楚。你开发时GPU跑得好好的打包给别人用的时候那台机器可能没有NVIDIA显卡也没有CUDA。代码里用一个环境检测逻辑来自动选择设备更加稳妥import torch device cuda if torch.cuda.is_available() else cpu6.3 摄像头读取与视频文件处理的差异摄像头读取用OpenCV的VideoCapture(0)打开第0个索引的摄像头。需要注意摄像头设备索引在不同系统上不一致有的工地上USB摄像头插在主机上会使用设备索引1或者2建议做一个摄像头选择下拉框让用户自己选而不是写死。处理视频文件和摄像头之间的一个重要差别是视频文件是有明确帧率的处理速度和播放速度会相互影响。你处理完一帧下一帧还没准备好直接循环读会造成视频播放过快。一个常见做法是使用time.sleep控制每帧间隔或者简单地在UI里增加一个视频倍率滑条。还有一个摄像头特有的问题解码帧率的波动。OpenCV读取摄像头时如果前一帧还没处理完缓冲区里会堆好几帧界面画面会感觉越来越卡。一个简单的策略是每次循环里直接把cap.grab()的结果丢掉只处理最新的那一帧保证界面显示的是相对实时的画面for _ in range(5): cap.grab() ret, frame cap.read()6.4 UI界面代码实例下面给一个完整的UI核心骨架你在运行时只需要填充Detector类和资源路径。import sys from PySide6.QtWidgets import QApplication, QMainWindow, QLabel, QPushButton, QVBoxLayout, QWidget from PySide6.QtCore import Qt, QThread, Signal from PySide6.QtGui import QImage, QPixmap import cv2 from detector import Detector class DetectionThread(QThread): frame_processed Signal(QImage, list) def __init__(self, video_source0, model_pathbest.pt): super().__init__() self.video_source video_source self.detector Detector(model_path) self.running False def run(self): cap cv2.VideoCapture(self.video_source) while self.running: ret, frame cap.read() if not ret: break detections self.detector.predict(frame) frame self.draw_boxes(frame, detections) qimage self.cv2_to_qimage(frame) self.frame_processed.emit(qimage, detections) cap.release() def draw_boxes(self, frame, detections): for det in detections: x1, y1, x2, y2 det[bbox] cls det[cls] conf det[conf] if cls 1: # helmet color (0, 255, 0) label fhelmet {conf:.2f} else: color (0, 0, 255) label fNO_HELMET {conf:.2f} cv2.rectangle(frame, (int(x1), int(y1)), (int(x2), int(y2)), color, 2) cv2.putText(frame, label, (int(x1), int(y1) - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.6, color, 2) return frame def cv2_to_qimage(self, frame): rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w, ch rgb.shape return QImage(rgb.data, w, h, ch * w, QImage.Format_RGB888).copy() def stop(self): self.running False self.wait()这段代码有一个值得强调的细节cv2_to_qimage返回的时候用了copy()。原因是QImage和BGR数组是共享内存的如果cv2帧后续被覆盖QImage的数据也会被一起改掉导致界面显示花屏。copy之后生成一个独立的图像对象这个坑就被绕开了。窗口主类里只需要把按钮和线程连接起来注意线程里所有的model.predict调用会占用GPU和CPU不影响UI线程的响应这是因为QThread已经把它扔到了后台线程。6.5 打包装配经验把所有代码写完、测试通过之后最后的交付问题是怎么让别人跑起来。第一种方式是纯源代码交付附一个requirements.txt对方自己在Python环境里pip install然后运行main.py。这种方式开发过程最舒服但对方如果不太懂Python会抱怨一堆环境问题。第二种方式是打包成exe。用PyInstaller命令大致如下pyinstaller --onefile --windowed --name SafetyDetection main.py注意如果UI里用到资源文件比如图标、提示音要加到打包配置里。还有YOLO模型权重文件建议不要打进exe而是一并放在旁边目录里这样即便后续重新训练更新模型也不需要重新打包exe。exe运行时通过相对路径加载模型文件这也是一个工程上的习惯把配置和权重做外置化不让主程序变成一个拿着维护的巨无霸。第三种方式是打Docker镜像。这个适合放在服务器后台长期跑。但不是所有工地现场都有Docker环境桌面版仍是这个阶段的主流。7. 常见问题与排查技巧实录7.1 训练阶段常见问题速查训练跑起来不报错是运气好报各种莫名其妙的错才是常态。按频率排序我遇到过的几类问题训练时numpy版本冲突ultralytics对numpy的版本有要求如果你本地已经装了一个版本高的或者低的可能加载数据时就崩了。推荐在虚拟环境里安装。顺带一说这个项目强烈建议用Python虚拟环境或conda环境不要直接装在系统Python里不然你下次跑别的项目时就会互相污染依赖项。数据集路径包含中文Windows下如果数据集目录或者项目路径里带中文某些代码读取文件时会编码错误导致训练中断。开发环境尽量统一用英文路径。这一点在接到别人给的代码时特别容易出现因为网上下载的压缩包解压后常常带着中文文件夹名。显存不足CUDA out of memory报错信息最后一行几乎都是CUDA out of memory。解决办法优先级降低batch size降低imgsz换更小的模型yolov8s改为yolov8n。不要一开始就买新显卡工程上先调整这两三个参数往往就能解决。训练过程中loss显示为nan一般有两个原因一是学习率设置过大导致训练不收敛二是标注数据里有空文件或者畸形标注框。先用脚本检查labels里是不是有空的txt文件以及有没有纯0坐标的框。空文件直接删除畸形框重新标注。7.2 推理与部署阶段高频问题模型推理速度很慢先确认是不是真的用上了GPU。很多人跑推理时默认用CPU即便电脑有显卡也没启用。去任务管理器看GPU占用率推理时GPU能不能跑起来。然后确认用的不是nano模型却配了imgsz1280输入放大一倍计算量涨了好几倍。最后看是不是每帧都在重新实例化模型前面说过的老坑。实时画面卡顿严重UI卡顿和画面卡顿分开看。如果画面卡但是UI按钮能点说明推理线程处理速度跟不上视频帧率压低imize或换小模型。如果UI按钮都点不动那就是Qt主线程被阻塞了说明有耗时操作没放在子线程里回到5.2节检查。检测结果不稳定有时戴帽报没戴帽这里有个经验法则检查你的阈值。同一个人置信度在0.45附近抖动很正常所以单帧判定必然会误报。我的过滤策略是对同一个目标跟踪多帧再报警或者降低阈值的同时要求连续两帧都检出才算数。前者需要写跟踪逻辑工作量大后者简单有效在相隔几帧的两帧上都检出同一位置的no_helmet才触发报警能大幅减少误报。摄像头无法打开常见原因是摄像头被其他程序占用或者Windows的摄像头权限设置阻止了软件访问。先在系统自带的相机应用里确认摄像头本身能用再用OpenCV的cap.isOpened()判断返回值。如果设备索引错误没有检测到任何摄像头cap.isOpened()直接返回False不要继续读帧。7.3 一份问题排查速查表现象可能原因解决方案训练时报CUDA out of memorybatch过大或imgsz过大降低batch到4imgsz降到640以下训练loss恒定为nan标注框异常或学习率过高检查labels里的非法数据降低lr模型推理全部是空检测类别映射错乱或阈值过高核对data.yaml类别顺序调低conf界面点击开始后卡死推理操作占用主线程把推理挪到QThread子线程显示画面黑白或偏色BGR/RGB通道顺序错乱检查cvtColor的顺序OpenCV默认BGR打包后exe无法识别模型权重文件路径错误使用绝对路径或相对路径计算函数定位摄像头画面延迟巨大缓冲区帧堆积使用grab()丢帧策略跳帧处理报警重复刷屏没有去重机制使用时间窗口去重10秒内只报一次7.4 一条实际排错经验记录我记得有一次给一个项目做联调现场摄像头画面里不断有人走动但模型总是把反光衣上的反光条识别成安全帽。一开始我怀疑是置信度阈值太低调高阈值之后误报减少了一些但漏检又变多了反而更不好用了。后来分析发现问题根源在于训练数据集中几乎没有反光衣的样本。模型没见过反光衣就把它的特征和学习到的安全帽特征中的某些边缘纹理混在一起了。这说明模型泛化的薄弱环节不在模型结构而在训练数据分布。我给数据集加了几百张有反光衣的图片重新训练误报问题基本消失。这个经历给我的教训是模型效果不好时先别只会调阈值。仔细看模型到底错在哪里把错误样本打出来统计是类别混淆还是目标太小还是遮挡严重再决定补数据还是换模型。8. 从项目到落地的扩展思考8.1 性能优化进阶方向如果你的系统未来要接到多个摄像头的视频流上单线程逐个处理肯定扛不住。几个可以进阶的方向一是使用多进程或者多线程并行推理。GPU推理通常是吞吐能力大于单路视频需求的可以起两个线程各处理一路视频流共享同一份模型权重推理队列分开。二是使用TensorRT加速。YOLOv8s在TensorRT加持下推理速度能比PyTorch下的原始推理快2到3倍在嵌入式平台上尤其明显。NVIDIA的TensorRT需要按你的显卡型号选定引擎版本导出engine文件后推理代码里加载方式跟ONNX不同。三是引入ByteTrack之类的目标跟踪算法。跟踪之后同一目标在不同帧之间的关联就有了安全员能看到这个违规人员从画面左边走到右边的完整轨迹报警也更准确。8.2 同类型场景复制这套系统的价值不只在工地。换一个场景标注不同数据就能迁移到很多其他领域化工厂危险区域人员闯入检测、电力作业现场安全帽检测、物流仓库叉车区域人体检测、医院手术室无菌帽佩戴检测。核心的变化点只有数据集和类别定义UI、报警、推理、多线程架构这些代码几乎原封不动复用。这也是我坚持在项目里把Detector模块独立封装的原因。真正能迁移复用的从来不是某一个模型而是整个工程框架。模型会过时但工程设计和模块划分的思路长期有效。8.3 系统可靠性与伦理考量任何安全系统都只能作为辅助手段不能作为安全管理的唯一依赖。机器学习模型存在漏检的可能光线变化、遮挡严重、摄像头角度不对都可能导致检测不到违规行为。这就需要在UI和报警设计中明确说明系统报警是提醒辅助安全员仍需对现场安全负责。数据采集和留存方面工地监控画面涉及人员隐私。报警截图建议设定保留期限不要在本地长期累积所有人员画面。合规方面的具体规定不同地区有差异但作为开发者最基本的做法是在系统部署时明确告知相关人员监控区域和用途。做一个工程系统不只是把它写出来能跑还要花时间想清楚它的边界在哪里。这样交付出去的方案别人才敢放心用。这个项目从YOLOv8模型训练到PySide6界面集成的完整链路走下来我的一个体会是真正耗时间的从来不是写代码而是数据质量和工程化细节。模型代码你可以从官方仓库直接调但标注出的数据集才是决定项目成败的隐形门槛。还有一点想分享这种安全检测系统的第一版本效果通常不会一上来就完美关键是建立起从数据到训练到部署的迭代闭环。模型误报、漏报就回去看错误案例、补数据、调整标注规则多迭代几轮效果会从量变走到质变。后续如果要接更多路摄像头可以考虑引入TensorRT加速和ByteTrack跟踪保持系统在更大规模下的实时性和可追溯性。
