YOLOv8电子围栏实战：从目标检测到工厂危险区域人员入侵告警

简介：面向高校毕设与课程设计，基于YOLOv8的智能工厂危险区域电子围栏系统完整工程包，提供实时监控、人员闯入检测与自动告警能力，可快速搭建安全管理系统原型。压缩包共包含97个文件，合计24.21MB，以70个Python脚本为主，辅以12个pyc编译文件、4个模型权重文件、5个XML配置及1段演示视频，覆盖前端界面、后端检测服务与模型训练调用链。目前已有38人学习，资料完整度与可操作性值得参考。资源附带的部署教程与可视化界面简化了安装和监控流程，可运行检测脚本配合预训练权重即可快速体验效果；模型训练目录保留YOLOv8训练脚本与数据集组织方式，便于依据特定工厂场景进行调优与拓展；同时提供UI图标与可视化页面设计，支持对监控界面的个性化调整，适合毕业设计、课程设计以及工厂安全领域技术验证。

1. YOLOv8 电子围栏在智能工厂里真正要解决的问题

把 YOLOv8 接上监控摄像头做危险区域报警，代码十几行就能让检测框跑起来，但整套系统交付时真正卡住人的往往不是模型本身，而是“报警怎么定义”这件事。工厂里的危险区域通常没有物理围栏，或者围栏门长期被打开，靠保安盯屏幕不现实，而一般的人体检测模型只能告诉你“画面里有人”，说不清这个人是在区域外经过还是已经踩进了危险区。基于 YOLOv8 的智能工厂危险区域电子围栏系统，就是把人员检测和区域判定这两件事拆开做：YOLOv8 负责稳定地框出人员目标，区域判定逻辑负责把检测框坐标换算成“进入/离开/滞留”三种状态。这套方案适合两类人：一类是拿它做毕设或课程设计，需要完整跑通全流程；另一类是工厂现场做安全巡检的技术人员，想用最低成本给现有监控系统加一层主动告警。

2. 环境搭建与数据集准备：YOLOv8 配置和工厂场景数据从哪来

2.1 YOLOv8 环境配置的常见做法与版本选择

YOLOv8 是 Ultralytics 团队维护的目标检测框架，环境搭建本身不复杂，但工厂现场的老机器往往卡在依赖版本上。常见做法是用 conda 单独建一个环境，Python 版本选 3.9 或 3.10，PyTorch 按显卡驱动装相应的 CUDA 版本。需要注意的一点是，YOLOv8 的ultralytics包在 8.0.0 之后 API 有过调整，如果训练时报AttributeError: 'YOLO' object has no attribute 'predict'，大概率是混用了网上旧教程的调用写法。

conda create -n yolov8-factory python=3.10 -y conda activate yolov8-factory # 先装 PyTorch，根据显卡驱动选 CUDA 版本，这里以 cu118 为例 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 再装 ultralytics 本体，它会自动拉取 opencv-python、numpy 等依赖 pip install ultralytics

装完后用yolo predict source=test.jpg跑一遍自带的预训练权重，能正常输出检测结果就说明基础链路通了。CPU 机器也能跑，但推理速度会明显慢，后面部署章节会单独说。注意不要在这个环境里装最新版 opencv，opencv-python的 4.9 以上版本偶尔会和ultralytics自带的标注工具冲突，遇到ImportError: libGL.so.1时执行apt install libgl1即可解决。

2.2 工厂自有数据集如何整理成 YOLO 格式

公开的 COCO 数据集里有人这个类别，但电子围栏系统需要的是工厂场景下的“人”，包括穿反光背心的人、弯腰作业的人、部分被设备遮挡的人，这些在 COCO 里的表现并不稳定。要么自己标数据，要么从行业安全数据集里筛选合并。数据标注建议用 LabelImg 或 X-AnyLabeling，后者对视频帧批量标注支持更好。

不管数据来自哪里，最终都要整理成 YOLO 格式的目录结构：

dataset/ ├── train/ │ ├── images/ # 训练图片 │ └── labels/ # 对应标注 txt，每个图片一个同名文件 ├── val/ │ ├── images/ │ └── labels/ └── data.yaml # 数据集配置文件

标注 txt 里的每一行是class_id x_center y_center width height，前四个值都是相对图片宽高的归一化坐标。举个例子，一张 1920x1080 的图上一个人体检测框左上角在 (960, 540)、宽 300、高 600，换算成归一化坐标就是 x_center = (960 + 150) / 1920 = 0.578，y_center = (540 + 300) / 1080 = 0.777，width = 300 / 1920 = 0.156，height = 600 / 1080 = 0.555。手工标容易算错，所以要么用标注工具自动导出的格式，要么写个坐标换算脚本统一处理。

data.yaml的内容很简单：

path: /path/to/dataset train: train/images val: val/images nc: 1 names: ['person']

用这个文件的目的，是让 YOLOv8 在训练时知道去哪里读图片、有几个类别、类别名是什么。这里唯一要避免的坑是path字段用了相对路径，而训练时的当前工作目录又不在 dataset 同级目录下，会直接报文件找不到。

2.3 数据增强策略在电子围栏场景下的取舍

工厂场景的摄像头通常固定机位，视角变化小，但光照变化大，夜班时可能只有低照度或红外补光。针对这些特性，训练时有几个增强参数值得打开。hsv_h、hsv_s、hsv_v这组负责色域扰动，建议小幅调高以增强低照度鲁棒性；degrees旋转增强对固定机位来说意义不大，反而可能引入误检，建议设置成 0。mosaic数据增强在训练初期能显著提升模型对遮挡场景的适应能力，但最后 20 个 epoch 建议关闭，否则模型在真实推理时对小目标的表现会偏弱。YOLOv8 官方默认mosaic=1.0，可以在训练配置里手动控制。

3. 模型训练与参数调优：YOLOv8 的 C2F 结构对电子围栏意味着什么

3.1 从 YOLOv8 网络结构理解该选哪种模型体型

YOLOv8 的 backbone 采用 C2F 模块（Cross Stage Partial with Focus），它把不同层的梯度流拼接起来，在保持轻量的同时让梯度回传更充分。相比 YOLOv5 的 C3 模块，C2F 能更好地融合浅层细节和深层语义，这对电子围栏场景的实际意义是：当工人背对摄像头弯腰作业时，模型从“人的轮廓”和“头盔/工装纹理”两条路径同时提取特征，即使前景与背景对比度不足，也能维持较高的检出率。

模型体型选择上，n / s / m / l / x 五个档位的推理延迟和精度曲线差异很大。从工厂场景出发，如果摄像头点位多、用普通工控机做推断，优先选 yolov8s；如果算力充裕（比如有一块消费级显卡），yolov8m 的漏检率明显更低。用表格对比一下：

需要注意，上面的延迟只是模型推理部分，不含视频解码和前后处理。实际项目里一条流从摄像头取帧到展示结果，约 30% 的开销花在解码和绘制上，所以评估选型时要按整链路算。

3.2 训练命令和关键参数说明

训练命令水到渠成地用 YOLOv8 标准入口跑起来，下面是一个适合工厂人员检测的配置：

yolo detect train \ model=yolov8s.pt \ data=data.yaml \ epochs=150 \ imgsz=640 \ batch=16 \ workers=8 \ optimizer=AdamW \ lr0=0.001 \ patience=20 \ project=runs/train \ name=factory_person

代码逻辑说明：

• model=yolov8s.pt表示加载 COCO 预训练权重，yolov8s 的泛化能力平衡，比 n 高两三个点的 mAP，比 m 快 30%。
• epochs=150是针对中小规模数据集的建议值。现场项目里几千张图，训练到 110~120 epoch 损失就趋于平缓，150 是为了让学习率衰减到足够低，使收敛更充分。
• imgsz=640是精度与速度的折中点。把分辨率提到 960 能改善小目标检测，但训练时间增长约 50%，推理延迟也同步上涨，务必在工控机上实测后再决定。
• batch=16只看显存。8G 显存跑 batch 16 有些吃紧，降到 8 更稳。大多数训练不稳定问题不是学习率太大，是 batch 太小且 lr0 没同步下调。
• patience=20表示验证集指标连续 20 个 epoch 不提升就早停。数据量小的时候建议保留，数据量大时可以关掉。
• optimizer=AdamW和lr0=0.001是配套参数。AdamW 收敛更平滑，但最终精度未必超过 SGD。如果你的数据超过 1 万张，直接用默认 SGD（momentum=0.937、lr0=0.01）效果一样好。

3.3 过拟合判断与损失函数曲线怎么看

训练过程生成的results.png里最值得看的是train/box_loss、val/box_loss和metrics/mAP50这几条曲线。电子围栏场景中常见的情况是 mAP 已经到 95% 以上，但现场部署后误报依然不少，问题往往不在“检不检得到”，而在定位框不准——即box_loss降不下去。这里有一个容易踩的认知误区：只看 mAP 不看回归精度。电子围栏的区域判定是基于“检测框底部中心点”的坐标执行的，如果框的上下偏移超过 20 个像素，判断结果就会在“区域内/区域外”之间抖动，形成反复告警。

处理方法是训练完成后单独看一眼验证集里 person 类别的中心点误差。YOLOv8 没有直接输出这个指标，但可以导出验证集预测结果，拿预测框底边中点和真实标注重心的偏差做一次分布统计，误差超过 15 像素的样本如果占比超过 5%，就说明回归精度不足，可以尝试把imgsz提高到 768，或者把置信度阈值从默认的 0.25 调到 0.5 以后观察漏检率的变化。这里的取舍是：阈值越高、误报越少，但漏检也会越多，实际调参时要录一段现场视频反复回放比对。

3.4 训练结果导出与最佳权重选择

训练结束后检查runs/train/factory_person/weights/下的两个权重文件：best.pt和last.pt。接电子围栏逻辑时用best.pt而不是last.pt，因为早停后 last 权重往往是过拟合后的结果，前期震荡大，mAP 反而低于 best。选定权重后建议先用一段真实监控片段跑一次全链路推流测试，确认检测结果符合预期再进入下一步的区域判断逻辑开发。

4. 电子围栏核心逻辑：从检测框到入侵状态判断

4.1 区域判定的两种方式及选型依据

拿到 YOLOv8 输出的检测框坐标之后，下一步是判断这个框是否越过了电子围栏边界。常见做法有两种：一是矩形区域交集判断，二是基于射线法的多边形区域判断。矩形判断实现简单、计算量小，适用于“传送带两侧禁止进入”“配电柜前方 1 米禁入”等规则清晰的场景；多边形判断适用于任意形状的围栏区域，比如 LNG 储罐区、涂装车间的异形作业面。

实现上推荐用 OpenCV 提供的cv2.pointPolygonTest，它内部就是射线法，直接输入区域多边形顶点和待检测点，返回值大于 0 表示在内部，小于 0 在外部，等于 0 在边界上。

4.2 基于检测框底边中点的侵入判定实现

人站在地面上时，检测框的底边中点最能代表脚部接触地面的位置。如果用检测框中心点来判，人弯腰时躯干前倾、框中心位置上移，就会出现“人已经越过红线但框中心还在区域外”的漏报。底边中点的逻辑是宁可让判断点提前半步入界，也不要迟到一步。

import cv2 def is_point_in_polygon(point, polygon): # point: (x, y) # polygon: 按顺时针或逆时针排列的顶点列表 result = cv2.pointPolygonTest(polygon, point, False) return result >= 0 def check_intrusion(detections, region_polygon, img_height, margin_px=5): """ detections: YOLOv8 推理输出，每项为 [x1, y1, x2, y2, conf, cls] region_polygon: 电子围栏多边形顶点 margin_px: 边界缓冲像素，防止检测框抖动导致频繁触发 """ alerts = [] for det in detections: x1, y1, x2, y2, conf, cls = det # 底边中点：x 方向取框中心，y 方向取 max(y1, y2) 即框底部 foot_x = int((x1 + x2) / 2) foot_y = int(max(y1, y2)) # 把底边中点向下扩展 margin 像素，等同于把边界向外推 foot_point = (foot_x, min(foot_y + margin_px, img_height - 1)) if is_point_in_polygon(foot_point, region_polygon): alerts.append({ "bbox": [x1, y1, x2, y2], "conf": conf, "foot_point": foot_point }) return alerts

逻辑说明：这段代码的输入不是原始图像，而是 YOLOv8 已经执行过 NMS 的检测结果。foot_point才是真正的判据，margin_px参数解决的是检测框在时间轴上轻微跳动导致的误报问题——如果边界判定刚好卡在线上，加 5 个像素缓冲可以让状态切换更平稳。但要注意的是，margin_px不能设置过大，否则围栏外的行人会被提前判为闯入，具体值需要根据实际安装高度和摄像头俯仰角来定。

4.3 状态机设计：解决区域内人员滞留检测的难点

电子围栏系统除了要报警“有人进入”，还要区分“短暂路过”和“持续滞留”。常见的实现是在侵入检测之上叠加一个逗留计时器。当检测框底边中点进入围栏区域时，系统登记当前帧号和进入时间；若该目标连续 N 帧（通常取 5~10 帧）都在区域内，触发告警；若中途连续 M 帧丢失，则重置状态。

和这种计时方案配合时需要一套目标关联机制。最简单的做法是直接用检测框的 IOU（交并比）做帧间匹配：当前帧的检测框集合和上一帧的检测框集合计算 IOU，超过 0.3 则默认是同一个目标，做状态延续。但这个方法有局限——当人体遮挡严重时，检测框大范围漂移甚至短暂消失，IOU 匹配会断链。追求更高鲁棒性的方案是引入 ByteTrack 或 SORT 这类轻量跟踪器，把跟踪 id 带进状态机。由于电子围栏的报警等级与目标 id 强相关，实际交付中建议上跟踪器，代码会增加约 200 行，但换来的是误报量的大幅下降。

4.4 可视化界面和后端服务怎么组织

可视化管理界面的常见实现是用 PyQt5 或 Flask + Web 前端把视频流和检测框叠加展示，同时提供“画围栏”的交互。功能上至少要包含三点：实时视频预览并绘制电子围栏区域、检测框和 id 标注、报警事件的时间轴记录和截图留存。界面逻辑建议独立成模块，和检测推理线程解耦。采集线程只负责推送检测结果到消息队列，UI 线程消费队列并渲染，避免界面拖动时阻塞推理。

ultralytics库本身没有内置围栏绘制工具，画多边形可以直接用cv2.polylines把区域顶点列表画在帧上，再用cv2.fillPoly加半透明填充。一些实现里把多边形面积换算到真实世界坐标做实际面积显示，但这里涉及镜头标定，如果在毕设阶段做，建议直接叠加在像素坐标上，避免引入过大的工程复杂度。

5. 部署提速与误报抑制：RK3588 和低算力设备上的落地技巧

5.1 从 PyTorch 到 TensorRT 的导出与注意事项

工厂现场不一定有 NVIDIA 显卡，很多边缘设备是瑞芯微 RK3588 或地平线旭日派，这类设备不能用标准的yolo export导出 TensorRT 引擎。RK3588 部署 YOLOv8 的常见路径是先把.pt导出成 ONNX，再用瑞芯微提供的 RKNN-Toolkit2 把 ONNX 转成.rknn格式。这中间最常遇见的坑是 OP 不支持，尤其是模型中的SiLU激活函数在部分 RKNN 版本上转不过去，解决思路是改用LeakyReLU激活函数重新训练，或者升级 RKNN-Toolkit2 到较新版本。

一行导出命令如下：

yolo export model=best.pt format=onnx opset=12 simplify=True

导出完成后先用onnxruntime跑一遍推理验证输出一致性。ONNX 的检测输出排列顺序和 PyTorch 不同，拿到输出后务必检查前 4 个数值是xywh还是xyxy。YOLOv8 的导出模型默认是xywh + 类别概率的格式，翻转坐标后接进 NMS 时容易出错。如果发现自带 NMS 太慢，外面加一层cv2.dnn.NMSBoxes做个朴素版本也可以跑，只要保持置信度阈值和 IoU 阈值与训练时一致，精度损失可以忽略。

5.2 误报抑制的三个实用参数

误报多不多，往往不取决于训练阶段，而是部署阶段的阈值调参没跟上实际场景。在电子围栏项目里，容易立竿见影的参数有三个。

第一个是检测置信度阈值conf。室内定焦摄像头建议设为 0.5 以上，室外或逆光场景降到 0.4。阈值过低会让“人体局部特征”触发报警，比如一只手伸出围栏外、或者穿防护服的人因遮挡只剩半个身体。第二个是感知层过滤框的最小宽高。用imgsz=640跑 1920x1080 的画面时，小于 20x30 像素的目标框大概率是远处通道的人，而不是危险区域内的闯入者，直接滤掉能少一半的无效告警。第三个是连续帧确认机制。上文代码里的状态机通过连续 N 帧确认减少单帧检测抖动带来的误报，生产环境建议设 5 帧，5 帧以下的短暂进入（比如低头捡东西、跨步经过）理论上不应产生报警。

# 推理时应用以上参数的示例 results = model.track( frame, conf=0.5, # 检测置信度阈值 iou=0.45, # NMS IoU 阈值 persist=True, # 跨帧保持跟踪 id tracker="bytetrack.yaml", # 使用 ByteTrack 配置 imgsz=640, verbose=False )

这部分逻辑说明：persist=True表示当前帧的检测结果会传递到下一帧做匹配；bytetrack.yaml是 ultralytics 内置的跟踪器配置，里面默认的track_buffer=30表示目标丢失后保持轨迹 30 帧，超过就重新分配 id。电子围栏系统建议把track_buffer调大一些，避免工人被设备短暂遮挡后被打成新 id，导致同样的闯入行为产生两条重复报警。这个参数在ultralytics/cfg/trackers/bytetrack.yaml中直接修改track_buffer字段即可。

5.3 模型阈值选择与推理帧率之间的平衡表

部署时经常要在精度和实时性之间做取舍，下表给出一组实测参考值，具体阈值请按现场录制片段回放微调：

注意表格里的“最小目标宽高”是模型输入分辨率下的像素值，如果你的推理分辨率是 640 而原画面是 1080p，实际画面上的目标面积还要乘以约 1.7 倍。有一种常见误用是直接把参数写在model.track()之外，实际生效的是predict参数，建议用model.predict(..., conf=0.5)的显式传参方式，不要依赖默认配置文件。

5.4 项目交付时的验证手段

系统部署完成后，不要只看“能不能检测到人”就交付，要拿出几段关键场景做对照验证。准备三段视频：正常作业视频（无闯入）、刻意闯入视频（有人走入围栏区域停留 5 秒）、遮挡干扰视频（有人反复经过围栏边缘但不进入）。分别运行系统，统计三个指标：漏报率、误报率、从进入区域到触发报警的延迟。对于一个可交付的电子围栏系统，漏报率应该在 3% 以下，误报率控制在每小时 1 次以内，报警延迟不超过 300ms（体验上接近实时）。达到这三个指标后，系统的状态机逻辑、阈值参数和可视化界面就形成了一个完整闭环，这时候再往服务器上一挂，才敢说“能跑了”。

本文还有配套的精品资源，点击获取