简介基于YOLOv8的实验室危险区域电子围栏项目面向计算机相关专业学生与毕业设计/课程设计场景集成目标检测模型、可视化界面、完整数据集与部署教程。资源包含训练脚本、视频检测脚本、可视化页面代码、YOLO系列权重yolov8n.pt、best.pt等及说明文档共8个文件压缩包约15.91MB结构精炼按README指引即可快速运行。模型训练后自动生成核心指标曲线、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果与标签分布图既支撑算法效果验证也方便答辩展示。目前已有70人浏览学习适合需要完整可运行项目参考的初学者或用于课程设计、大作业起步在此基础上可继续修改扩展功能。1. 基于YOLOv8的实验室危险区域电子围栏这套方案值不值得做实验室里贴着黄黑胶带的安全区域经常被人误闯光靠摄像头肉眼盯根本盯不过来。把YOLOv8跑起来用检测框锁定画面中的人再拿一个多边形把危险区圈出来人一旦进入就触发报警——这就是基于YOLOv8的实验室危险区域电子围栏最朴素的实现思路。这类项目包通常会把目标检测、图像标注、坐标算法、桌面可视化界面都串在一起正好覆盖了毕业设计和课程设计的全部得分点。你不需要从头搭环境拿到来直接用唯一要花时间的是理解每一段代码在干什么、参数怎么调、自己的数据怎么替换。2. 数据准备与标注先把要检测的“人”和“区域”定义清楚2.1 电子围栏场景要哪些类别实验室电子围栏的目标很简单检测到“人”再判断这个人的位置和危险区域的关系。不要一上来就把类别拆成“戴安全帽的人”“穿白大褂的人”这些对你最终判定越界没有帮助反而让模型变得更难训练。我建议单类别“person”既能复用COCO预训练权重里的特征又让数据量门槛低很多。如果你用的是已经打包好的项目里面多半已经有一份组织好的数据集。你要做的是先检查它的目录结构再决定要不要用自己的数据重新训练。常见的结构是dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ ├── data.yamldata.yaml 内容是类别定义和路径path: /path/to/dataset train: images/train val: images/val names: 0: person请留意 path 这一段很多人训练时报错“dataset not found”最后查下来是绝对路径写死了别人电脑上的地址。建议改成相对路径或者训练前用 pwd 确认当前目录把 path 设成数据集相对于当前目录的位置。2.2 用 LabelMe 标注并转成 YOLO 格式如果你要用自己的实验室内景图片训练标注工具用 LabelMe 就够了。LabelMe 保存的是 JSON 文件而 YOLOv8 需要的是每个图片对应一个 .txt 标签每行写 class_id 和归一化后的中心坐标、宽高。转换脚本是这类项目里必带的核心代码逻辑并不复杂但要考虑多边形的特殊情况。下面是 JSON 转 YOLO 格式的脚本能处理单个多边形直接转矩形框的情况import json import os from glob import glob def convert_labelme_json(json_path, class_map, output_dir): json_path: LabelMe 生成的 JSON 文件路径 class_map: 类别名到 id 的映射例如 {person: 0} output_dir: 输出的 .txt 标签存放目录 with open(json_path, r, encodingutf-8) as f: data json.load(f) img_w, img_h data[imageWidth], data[imageHeight] if img_w 0 or img_h 0: return lines [] for shape in data[shapes]: label shape[label] if label not in class_map: continue points shape[points] # 多边形顶点列表 # 取多边形的外接矩形转成 YOLO 的 xywh 格式 xs [p[0] for p in points] ys [p[1] for p in points] x_min, x_max min(xs), max(xs) y_min, y_max min(ys), max(ys) box_w x_max - x_min box_h y_max - y_min x_center (x_min x_max) / 2.0 y_center (y_min y_max) / 2.0 # 归一化到 0~1避免越界 x_center / img_w y_center / img_h box_w / img_w box_h / img_h lines.append(f{class_map[label]} {x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}) base_name os.path.splitext(os.path.basename(json_path))[0] label_path os.path.join(output_dir, base_name .txt) with open(label_path, w, encodingutf-8) as f: f.write(\n.join(lines)) # 批量转换示例 class_map {person: 0} os.makedirs(labels, exist_okTrue) for json_file in glob(labelme_json/*.json): convert_labelme_json(json_file, class_map, labels)这段代码用外接矩形把多边形围起来优点是稳定、不会丢目标缺点是框里会塞进一些背景。对于“人”这种接近直立的物体外接矩形的损失很小可以接受。如果你后续想跑实例分割才需要保留多边形顶点坐标那就是另外一套格式了。2.3 数据划分与分布检查训练集和验证集的划分建议 9:1不要用 7:3目标检测的数据量本身就显得少验证集砍太多会影响模型泛化能力评估。划分时还要注意同一个场景的连续帧不能同时出现在训练集和验证集里否则会造成“数据泄漏”验证集分数虚高。按视频帧抽取时每隔几帧抽一张或者按目录分开放都能避免这个问题。划分完以后把每类的图片数量、标注框数量统计出来。如果 person 这类的标注框少于 500 个训练效果会比较勉强。这时优先考虑用一个通用人形检测权重做初始化而不是从零开始训练。3. YOLOv8 训练过程环境配置、超参数与训练日志3.1 环境搭建的两种路径CPU 版本的 YOLOv8 是可以跑的只是速度慢得让人心慌。我用 GTX 1660 Ti 跑过一次 100 epoch 的 person 检测每轮大约 40 秒同配置换纯 CPU 会慢十倍不止。所以第一步先判断手头机器有没有可用 GPU没有的话直接用 CPU 版环境把训练跑通也算一种落地方式。Windows 上推荐用 Python 3.9 PyTorch 2.x 的组合conda create -n yolov8 python3.9 conda activate yolov8 pip install ultralytics -i https://pypi.tuna.tsinghua.edu.cn/simpleUbuntu 20.04 下如果只是 CPU 推理这几行就够pip install ultralytics python -c import torch; print(torch.cuda.is_available())安装完成后先跑这一条验证环境不要直接开训练。torch.cuda.is_available() 返回 False 的话后续所有 GPU 训练命令都会静默回退到 CPU很多人跑了一整天才发现模型根本没上 GPU。还有一套关联问题是 CUDA 版本与 PyTorch 不匹配报错信息里带 “torch._C” 或者找不到 DLL 时回到 PyTorch 官网选对应 CUDA 版本的安装命令重装。3.2 训练命令与每个参数的实际含义训练入口非常简单关键是参数含义要清楚。拿一张 640x640 的输入图模型按结构复杂度分 yolov8n/s/m/l/x 五档实验室电子围栏这种单类别任务yolov8n 或 yolov8s 就够了。更小的模型意味着更快的推理速度对实时报警更有利。yolo train datadata.yaml modelyolov8s.pt epochs100 batch16 imgsz640 device0epochs 设为 100 是常见初值不是越大越好。我一般先用 50 快速跑通确认 loss 在下降后再加大到 100 或 150。batch 受显存限制16G 显存跑 yolov8s 用 16 没有问题显存不够就降到 8。device0 表示第一张 GPU没有 GPU 时写 devicecpu速度慢但能验流程。迁移学习默认是自动的modelyolov8s.pt 会下载 COCO 预训练权重其中包含 person 类的特征这对小数据集帮助很大。如果你的数据集里人形姿态和实验室场景差异特别大可以试一下冻结前几层特征只是电子围栏项目很少需要做到这一步。3.3 损失曲线与训练日志怎么看训练过程会在 runs/detect/train 目录下生成多次实验结果包括混淆矩阵、损失曲线和验证集图片。损失曲线分三部分box_loss 是框回归损失cls_loss 是分类损失dfl_loss 是分布损失。电子围栏项目里最优先看 box_loss因为越界判定完全依赖检测框位置的稳定性。曲线持续下降说明模型在学习如果到第 20 轮以后还在高位震荡优先检查数据标注质量不要急着加训练轮次。还有个常见误区是只盯训练集 loss忽略 val 的 mAP。训练集 loss 降但验证集 mAP 没变化说明模型在过拟合训练集的背景纹理。这时可以加数据增强参数比如yolo train datadata.yaml modelyolov8s.pt epochs100 batch16 imgsz640 hsv_h0.02 hsv_s0.5 hsv_v0.4hsv_h 是色调变化幅度0.02 表示在原来基础上微调改到 0.05 以上颜色畸变明显。电子围栏场景里光照变化比较频繁适当的 hsv_s 饱和度抖动能提升夜间和反光场景的鲁棒性。4. 电子围栏判定逻辑从检测框坐标到越界报警4.1 危险区域怎么标定电子围栏的“围栏”在代码里通常是一个或多个多边形。你可以用鼠标在视频画面上点击顶点也可以写在配置文件里按像素坐标定义顶点。这里有一个坐标系陷阱画面如果是 1280x720推理时缩放成 640x640检测框坐标是相对于缩放后图像的。拿这个框和标定好的多边形比较必须先把两边统一到同一个坐标系。我一般按原始分辨率标定多边形然后把模型推理出的框按比例放大回原始分辨率再判断。具体缩放比例scale_x frame_width / model_width scale_y frame_height / model_height4.2 用 pointPolygonTest 判断检测框与多边形的关系判断一个点是否在多边形内OpenCV 的 pointPolygonTest 是现成的方案。默认判断检测框中心点太粗暴人站在边界外身体探进危险区就漏判。更稳的做法是取检测框底边中心点因为人脚踩的位置最能代表“人实际站在那里”。import cv2 danger_zone np.array([[100, 200], [300, 150], [400, 400], [150, 450]], dtypenp.float32) def is_point_in_zone(point, zone): point: (x, y) 底边中心点 zone: 多边形顶点数组 返回 True 表示点在区域内或边界上 result cv2.pointPolygonTest(zone, point, measureDistFalse) return result 0person 检测框的底边中心点结合了点特征和几何特征比单纯用中心点更符合人类对“站在某处”的直觉。如果你的检测框特别不稳定一帧大一帧小底边坐标会上下抖动这时退一步用中心点和底边中心点的折中位置牺牲一点灵敏度换稳定性。4.3 报警触发与去抖检测偶尔会自动消失一帧就立刻停止报警会让整个系统非常聒噪。至少连续 3 到 5 帧判定“人在区域内”才触发报警这样误报会少很多。这个逻辑用一个计数器就能实现。同样报警发生后人移出区域也建议连续几帧判定安全才复位报警状态避免边界反复横跳时蜂鸣器响个不停。status_buffer [] ALARM_FRAME_COUNT 5 def update_alarm_state(in_zone): in_zone: 当前帧是否在区域内 返回当前应不应该触发报警 status_buffer.append(in_zone) if len(status_buffer) ALARM_FRAME_COUNT: status_buffer.pop(0) if all(status_buffer): return True return Falsestatus_buffer 维持一个长度为 5 的缓冲队列全部为 True 才报警。这个参数配合推理帧率调整如果你每秒只处理 5 帧队列全 True 相当于人已经在区域里待了一秒每秒处理 20 帧的话就相当于 0.25 秒。拿去抖设定的帧数要匹配你的推理速度否则报警延迟会变成一大截。5. 可视化界面与部署五个容易翻车的排查点5.1 PyQt 与 OpenCV 视频流的集成交互可视化界面最常用的组合是 PyQt 做窗口和控件OpenCV 负责取流和显示帧。把推理循环放进界面线程会直接卡死窗口因为模型推理一次可能耗时几十毫秒画面就在那卡着不动。常见做法是单独开一个 QThread 跑视频循环然后用信号把处理好的帧发给主界面刷新。from PyQt5.QtCore import QThread, pyqtSignal import cv2 class VideoThread(QThread): frame_signal pyqtSignal(object) def __init__(self, model, source0): super().__init__() self.model model self.source source self.running True def run(self): cap cv2.VideoCapture(self.source) while self.running: ret, frame cap.read() if not ret: break results self.model(frame, conf0.45, imgsz640) # 这里把检测框和围栏绘制到 frame 上 annotated draw_danger_zone(frame, danger_zone) self.frame_signal.emit(annotated) cap.release()信号传图像对象比传路径更直接刷新频率上限取决于推理速度。如果你的界面显示跟不上可以在 signal.emit 前加一个简单的帧间隔控制用 time.sleep 限流。5.2 部署排查一模型路径与权重不匹配现象训练完跑 demo.py程序报错 “cannot find model”或者加载后检测结果全为空。原因代码里默认加载 runs/detect/train/weights/best.pt但你把项目目录移动过或者复制了项目给同学绝对路径已经失效。另一个关联原因是 torch.load 加载到 CPU 机器上但权重是在 GPU 上训练的也会出现加载报错。解决先确认 best.pt 存在并且用绝对路径试一次加载python -c from ultralytics import YOLO; m YOLO(/abs/path/best.pt); print(ok)输出 ok 再排查界面代码里的相对路径写法。5.3 部署排查二视频流卡死和内存增长现象程序运行几分钟后画面开始卡顿最后直接无响应内存占用一路飙升。原因预览窗口在持续累积新的 QPixmap 对象旧的没有被释放。或者是推理线程把结果发到主线程的速度超过界面刷新速度积压的信号把事件队列堆满了。第二个原因是做电子围栏最容易踩的坑视频帧处理完后没能正确释放 OpenCV 的 Mat 对象。解决不要在 while 循环里反复设置整个 QGraphicsScene 的内容改用 QLabel.setPixmap 直接刷新并确保 frame_signal 连接的是同一个刷新槽函数。最简单的验证方法是打印线程 id看推理线程和 UI 线程是不是同一个同一个就是线程模型写错了。5.4 部署排查三内置摄像头编号不对现象界面能打开但预览画面是黑屏或报 “Unable to open camera”。原因cv2.VideoCapture(0) 的 0 不一定是你的 USB 摄像头笔记本自带摄像头和 USB 外接摄像头的编号在不同驱动下顺序不同。还有一类原因是摄像头被其他软件占用OpenCV 拿不到句柄。解决先单独测一次python -c import cv2; cap cv2.VideoCapture(0); print(cap.isOpened())如果返回 False换 VideoCapture(1) 再试。不要直接在项目代码里面试编号那个过程很折磨人。5.5 部署排查四CPU 机器推理速度过慢现象画面能跑起来但一帧要两秒多报警延迟完全不可接受。原因在纯 CPU 机器上跑了默认的 yolov8s 模型且没有限制输入分辨率。640 输入图在 CPU 上推理一次大约几百毫秒性能较差的 CPU 到一秒以上很正常。解决把模型换成 yolov8n把推理尺寸从 640 降到 480再把推理线程的输出限在一个合理帧率例如每 0.2 秒最多推理一帧。最后的画面流畅度由显示线程负责报警判定基于推理结果所以降低推理频率不会让报警逻辑出错只是让边界判断更新变慢而已。6. 进阶导出 ONNX 做加速附带一个帧率优化思路训练好的 best.pt 在推理脚本里跑没问题但如果你想把核心检测和围栏逻辑移到板端比如 RK3588就得先导出 ONNX。导出指令很简单yolo export modelruns/detect/train/weights/best.pt formatonnx imgsz640 simplifyTruesimplifyTrue 会做计算图融合减少部分算子方便后续转换 RKNN 格式。导出后用 onnxruntime 验证一遍输入输出尺寸确保和 .pt 权重结果一致常见的坑发生在动态尺寸问题上。导出时没有指定固定尺寸推理时输入维度是动态的有些部署框架不支持动态输入建议 export 时加上 dynamicFalse 定死尺寸。如果你只在本地做帧率优化一个成本很低的做法是分开缩放把 640 输入图的检测结果映射回预览画面时预览画面用 960x540 显示。这样推理开销降下来视觉上清晰度也没有明显下降。再配合跳帧推理每隔一帧跑一次模型中间一帧沿用上一帧的检测结果报警抖动的感知几乎没有差别。跑完这些以后你会在 best.pt 的 val 分数、导出模型的一致性和报警延迟上花最多的调试时间。我曾经在一个项目里为了把报警延迟从一秒压到半秒最后发现瓶颈在摄像头自身的 30 帧缓冲而不是模型推理。先测量瓶颈再决定优化位置这是我从这个方案里学到的最大教训希望帮到你。本文还有配套的精品资源点击获取 基于YOLOv8的实验室危险区域电子围栏：从训练到部署全流程
简介基于YOLOv8的实验室危险区域电子围栏项目面向计算机相关专业学生与毕业设计/课程设计场景集成目标检测模型、可视化界面、完整数据集与部署教程。资源包含训练脚本、视频检测脚本、可视化页面代码、YOLO系列权重yolov8n.pt、best.pt等及说明文档共8个文件压缩包约15.91MB结构精炼按README指引即可快速运行。模型训练后自动生成核心指标曲线、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果与标签分布图既支撑算法效果验证也方便答辩展示。目前已有70人浏览学习适合需要完整可运行项目参考的初学者或用于课程设计、大作业起步在此基础上可继续修改扩展功能。1. 基于YOLOv8的实验室危险区域电子围栏这套方案值不值得做实验室里贴着黄黑胶带的安全区域经常被人误闯光靠摄像头肉眼盯根本盯不过来。把YOLOv8跑起来用检测框锁定画面中的人再拿一个多边形把危险区圈出来人一旦进入就触发报警——这就是基于YOLOv8的实验室危险区域电子围栏最朴素的实现思路。这类项目包通常会把目标检测、图像标注、坐标算法、桌面可视化界面都串在一起正好覆盖了毕业设计和课程设计的全部得分点。你不需要从头搭环境拿到来直接用唯一要花时间的是理解每一段代码在干什么、参数怎么调、自己的数据怎么替换。2. 数据准备与标注先把要检测的“人”和“区域”定义清楚2.1 电子围栏场景要哪些类别实验室电子围栏的目标很简单检测到“人”再判断这个人的位置和危险区域的关系。不要一上来就把类别拆成“戴安全帽的人”“穿白大褂的人”这些对你最终判定越界没有帮助反而让模型变得更难训练。我建议单类别“person”既能复用COCO预训练权重里的特征又让数据量门槛低很多。如果你用的是已经打包好的项目里面多半已经有一份组织好的数据集。你要做的是先检查它的目录结构再决定要不要用自己的数据重新训练。常见的结构是dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ ├── data.yamldata.yaml 内容是类别定义和路径path: /path/to/dataset train: images/train val: images/val names: 0: person请留意 path 这一段很多人训练时报错“dataset not found”最后查下来是绝对路径写死了别人电脑上的地址。建议改成相对路径或者训练前用 pwd 确认当前目录把 path 设成数据集相对于当前目录的位置。2.2 用 LabelMe 标注并转成 YOLO 格式如果你要用自己的实验室内景图片训练标注工具用 LabelMe 就够了。LabelMe 保存的是 JSON 文件而 YOLOv8 需要的是每个图片对应一个 .txt 标签每行写 class_id 和归一化后的中心坐标、宽高。转换脚本是这类项目里必带的核心代码逻辑并不复杂但要考虑多边形的特殊情况。下面是 JSON 转 YOLO 格式的脚本能处理单个多边形直接转矩形框的情况import json import os from glob import glob def convert_labelme_json(json_path, class_map, output_dir): json_path: LabelMe 生成的 JSON 文件路径 class_map: 类别名到 id 的映射例如 {person: 0} output_dir: 输出的 .txt 标签存放目录 with open(json_path, r, encodingutf-8) as f: data json.load(f) img_w, img_h data[imageWidth], data[imageHeight] if img_w 0 or img_h 0: return lines [] for shape in data[shapes]: label shape[label] if label not in class_map: continue points shape[points] # 多边形顶点列表 # 取多边形的外接矩形转成 YOLO 的 xywh 格式 xs [p[0] for p in points] ys [p[1] for p in points] x_min, x_max min(xs), max(xs) y_min, y_max min(ys), max(ys) box_w x_max - x_min box_h y_max - y_min x_center (x_min x_max) / 2.0 y_center (y_min y_max) / 2.0 # 归一化到 0~1避免越界 x_center / img_w y_center / img_h box_w / img_w box_h / img_h lines.append(f{class_map[label]} {x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}) base_name os.path.splitext(os.path.basename(json_path))[0] label_path os.path.join(output_dir, base_name .txt) with open(label_path, w, encodingutf-8) as f: f.write(\n.join(lines)) # 批量转换示例 class_map {person: 0} os.makedirs(labels, exist_okTrue) for json_file in glob(labelme_json/*.json): convert_labelme_json(json_file, class_map, labels)这段代码用外接矩形把多边形围起来优点是稳定、不会丢目标缺点是框里会塞进一些背景。对于“人”这种接近直立的物体外接矩形的损失很小可以接受。如果你后续想跑实例分割才需要保留多边形顶点坐标那就是另外一套格式了。2.3 数据划分与分布检查训练集和验证集的划分建议 9:1不要用 7:3目标检测的数据量本身就显得少验证集砍太多会影响模型泛化能力评估。划分时还要注意同一个场景的连续帧不能同时出现在训练集和验证集里否则会造成“数据泄漏”验证集分数虚高。按视频帧抽取时每隔几帧抽一张或者按目录分开放都能避免这个问题。划分完以后把每类的图片数量、标注框数量统计出来。如果 person 这类的标注框少于 500 个训练效果会比较勉强。这时优先考虑用一个通用人形检测权重做初始化而不是从零开始训练。3. YOLOv8 训练过程环境配置、超参数与训练日志3.1 环境搭建的两种路径CPU 版本的 YOLOv8 是可以跑的只是速度慢得让人心慌。我用 GTX 1660 Ti 跑过一次 100 epoch 的 person 检测每轮大约 40 秒同配置换纯 CPU 会慢十倍不止。所以第一步先判断手头机器有没有可用 GPU没有的话直接用 CPU 版环境把训练跑通也算一种落地方式。Windows 上推荐用 Python 3.9 PyTorch 2.x 的组合conda create -n yolov8 python3.9 conda activate yolov8 pip install ultralytics -i https://pypi.tuna.tsinghua.edu.cn/simpleUbuntu 20.04 下如果只是 CPU 推理这几行就够pip install ultralytics python -c import torch; print(torch.cuda.is_available())安装完成后先跑这一条验证环境不要直接开训练。torch.cuda.is_available() 返回 False 的话后续所有 GPU 训练命令都会静默回退到 CPU很多人跑了一整天才发现模型根本没上 GPU。还有一套关联问题是 CUDA 版本与 PyTorch 不匹配报错信息里带 “torch._C” 或者找不到 DLL 时回到 PyTorch 官网选对应 CUDA 版本的安装命令重装。3.2 训练命令与每个参数的实际含义训练入口非常简单关键是参数含义要清楚。拿一张 640x640 的输入图模型按结构复杂度分 yolov8n/s/m/l/x 五档实验室电子围栏这种单类别任务yolov8n 或 yolov8s 就够了。更小的模型意味着更快的推理速度对实时报警更有利。yolo train datadata.yaml modelyolov8s.pt epochs100 batch16 imgsz640 device0epochs 设为 100 是常见初值不是越大越好。我一般先用 50 快速跑通确认 loss 在下降后再加大到 100 或 150。batch 受显存限制16G 显存跑 yolov8s 用 16 没有问题显存不够就降到 8。device0 表示第一张 GPU没有 GPU 时写 devicecpu速度慢但能验流程。迁移学习默认是自动的modelyolov8s.pt 会下载 COCO 预训练权重其中包含 person 类的特征这对小数据集帮助很大。如果你的数据集里人形姿态和实验室场景差异特别大可以试一下冻结前几层特征只是电子围栏项目很少需要做到这一步。3.3 损失曲线与训练日志怎么看训练过程会在 runs/detect/train 目录下生成多次实验结果包括混淆矩阵、损失曲线和验证集图片。损失曲线分三部分box_loss 是框回归损失cls_loss 是分类损失dfl_loss 是分布损失。电子围栏项目里最优先看 box_loss因为越界判定完全依赖检测框位置的稳定性。曲线持续下降说明模型在学习如果到第 20 轮以后还在高位震荡优先检查数据标注质量不要急着加训练轮次。还有个常见误区是只盯训练集 loss忽略 val 的 mAP。训练集 loss 降但验证集 mAP 没变化说明模型在过拟合训练集的背景纹理。这时可以加数据增强参数比如yolo train datadata.yaml modelyolov8s.pt epochs100 batch16 imgsz640 hsv_h0.02 hsv_s0.5 hsv_v0.4hsv_h 是色调变化幅度0.02 表示在原来基础上微调改到 0.05 以上颜色畸变明显。电子围栏场景里光照变化比较频繁适当的 hsv_s 饱和度抖动能提升夜间和反光场景的鲁棒性。4. 电子围栏判定逻辑从检测框坐标到越界报警4.1 危险区域怎么标定电子围栏的“围栏”在代码里通常是一个或多个多边形。你可以用鼠标在视频画面上点击顶点也可以写在配置文件里按像素坐标定义顶点。这里有一个坐标系陷阱画面如果是 1280x720推理时缩放成 640x640检测框坐标是相对于缩放后图像的。拿这个框和标定好的多边形比较必须先把两边统一到同一个坐标系。我一般按原始分辨率标定多边形然后把模型推理出的框按比例放大回原始分辨率再判断。具体缩放比例scale_x frame_width / model_width scale_y frame_height / model_height4.2 用 pointPolygonTest 判断检测框与多边形的关系判断一个点是否在多边形内OpenCV 的 pointPolygonTest 是现成的方案。默认判断检测框中心点太粗暴人站在边界外身体探进危险区就漏判。更稳的做法是取检测框底边中心点因为人脚踩的位置最能代表“人实际站在那里”。import cv2 danger_zone np.array([[100, 200], [300, 150], [400, 400], [150, 450]], dtypenp.float32) def is_point_in_zone(point, zone): point: (x, y) 底边中心点 zone: 多边形顶点数组 返回 True 表示点在区域内或边界上 result cv2.pointPolygonTest(zone, point, measureDistFalse) return result 0person 检测框的底边中心点结合了点特征和几何特征比单纯用中心点更符合人类对“站在某处”的直觉。如果你的检测框特别不稳定一帧大一帧小底边坐标会上下抖动这时退一步用中心点和底边中心点的折中位置牺牲一点灵敏度换稳定性。4.3 报警触发与去抖检测偶尔会自动消失一帧就立刻停止报警会让整个系统非常聒噪。至少连续 3 到 5 帧判定“人在区域内”才触发报警这样误报会少很多。这个逻辑用一个计数器就能实现。同样报警发生后人移出区域也建议连续几帧判定安全才复位报警状态避免边界反复横跳时蜂鸣器响个不停。status_buffer [] ALARM_FRAME_COUNT 5 def update_alarm_state(in_zone): in_zone: 当前帧是否在区域内 返回当前应不应该触发报警 status_buffer.append(in_zone) if len(status_buffer) ALARM_FRAME_COUNT: status_buffer.pop(0) if all(status_buffer): return True return Falsestatus_buffer 维持一个长度为 5 的缓冲队列全部为 True 才报警。这个参数配合推理帧率调整如果你每秒只处理 5 帧队列全 True 相当于人已经在区域里待了一秒每秒处理 20 帧的话就相当于 0.25 秒。拿去抖设定的帧数要匹配你的推理速度否则报警延迟会变成一大截。5. 可视化界面与部署五个容易翻车的排查点5.1 PyQt 与 OpenCV 视频流的集成交互可视化界面最常用的组合是 PyQt 做窗口和控件OpenCV 负责取流和显示帧。把推理循环放进界面线程会直接卡死窗口因为模型推理一次可能耗时几十毫秒画面就在那卡着不动。常见做法是单独开一个 QThread 跑视频循环然后用信号把处理好的帧发给主界面刷新。from PyQt5.QtCore import QThread, pyqtSignal import cv2 class VideoThread(QThread): frame_signal pyqtSignal(object) def __init__(self, model, source0): super().__init__() self.model model self.source source self.running True def run(self): cap cv2.VideoCapture(self.source) while self.running: ret, frame cap.read() if not ret: break results self.model(frame, conf0.45, imgsz640) # 这里把检测框和围栏绘制到 frame 上 annotated draw_danger_zone(frame, danger_zone) self.frame_signal.emit(annotated) cap.release()信号传图像对象比传路径更直接刷新频率上限取决于推理速度。如果你的界面显示跟不上可以在 signal.emit 前加一个简单的帧间隔控制用 time.sleep 限流。5.2 部署排查一模型路径与权重不匹配现象训练完跑 demo.py程序报错 “cannot find model”或者加载后检测结果全为空。原因代码里默认加载 runs/detect/train/weights/best.pt但你把项目目录移动过或者复制了项目给同学绝对路径已经失效。另一个关联原因是 torch.load 加载到 CPU 机器上但权重是在 GPU 上训练的也会出现加载报错。解决先确认 best.pt 存在并且用绝对路径试一次加载python -c from ultralytics import YOLO; m YOLO(/abs/path/best.pt); print(ok)输出 ok 再排查界面代码里的相对路径写法。5.3 部署排查二视频流卡死和内存增长现象程序运行几分钟后画面开始卡顿最后直接无响应内存占用一路飙升。原因预览窗口在持续累积新的 QPixmap 对象旧的没有被释放。或者是推理线程把结果发到主线程的速度超过界面刷新速度积压的信号把事件队列堆满了。第二个原因是做电子围栏最容易踩的坑视频帧处理完后没能正确释放 OpenCV 的 Mat 对象。解决不要在 while 循环里反复设置整个 QGraphicsScene 的内容改用 QLabel.setPixmap 直接刷新并确保 frame_signal 连接的是同一个刷新槽函数。最简单的验证方法是打印线程 id看推理线程和 UI 线程是不是同一个同一个就是线程模型写错了。5.4 部署排查三内置摄像头编号不对现象界面能打开但预览画面是黑屏或报 “Unable to open camera”。原因cv2.VideoCapture(0) 的 0 不一定是你的 USB 摄像头笔记本自带摄像头和 USB 外接摄像头的编号在不同驱动下顺序不同。还有一类原因是摄像头被其他软件占用OpenCV 拿不到句柄。解决先单独测一次python -c import cv2; cap cv2.VideoCapture(0); print(cap.isOpened())如果返回 False换 VideoCapture(1) 再试。不要直接在项目代码里面试编号那个过程很折磨人。5.5 部署排查四CPU 机器推理速度过慢现象画面能跑起来但一帧要两秒多报警延迟完全不可接受。原因在纯 CPU 机器上跑了默认的 yolov8s 模型且没有限制输入分辨率。640 输入图在 CPU 上推理一次大约几百毫秒性能较差的 CPU 到一秒以上很正常。解决把模型换成 yolov8n把推理尺寸从 640 降到 480再把推理线程的输出限在一个合理帧率例如每 0.2 秒最多推理一帧。最后的画面流畅度由显示线程负责报警判定基于推理结果所以降低推理频率不会让报警逻辑出错只是让边界判断更新变慢而已。6. 进阶导出 ONNX 做加速附带一个帧率优化思路训练好的 best.pt 在推理脚本里跑没问题但如果你想把核心检测和围栏逻辑移到板端比如 RK3588就得先导出 ONNX。导出指令很简单yolo export modelruns/detect/train/weights/best.pt formatonnx imgsz640 simplifyTruesimplifyTrue 会做计算图融合减少部分算子方便后续转换 RKNN 格式。导出后用 onnxruntime 验证一遍输入输出尺寸确保和 .pt 权重结果一致常见的坑发生在动态尺寸问题上。导出时没有指定固定尺寸推理时输入维度是动态的有些部署框架不支持动态输入建议 export 时加上 dynamicFalse 定死尺寸。如果你只在本地做帧率优化一个成本很低的做法是分开缩放把 640 输入图的检测结果映射回预览画面时预览画面用 960x540 显示。这样推理开销降下来视觉上清晰度也没有明显下降。再配合跳帧推理每隔一帧跑一次模型中间一帧沿用上一帧的检测结果报警抖动的感知几乎没有差别。跑完这些以后你会在 best.pt 的 val 分数、导出模型的一致性和报警延迟上花最多的调试时间。我曾经在一个项目里为了把报警延迟从一秒压到半秒最后发现瓶颈在摄像头自身的 30 帧缓冲而不是模型推理。先测量瓶颈再决定优化位置这是我从这个方案里学到的最大教训希望帮到你。本文还有配套的精品资源点击获取