尧图网页设计 
简介基于YOLOv8的社区消防通道占用预警系统是一套可直接落地的毕业设计项目面向计算机相关专业学生、老师及企业开发者用于消防通道占用检测与可视化预警。压缩包内共97个文件涵盖70个Python源码、12个编译缓存pyc、5个XML配置、4个模型权重pt文件及说明文档等整体仅24.21MB。源码包含可视化界面、检测服务、模型训练与推理模块提供best.pt权重、数据集及部署教程可生成核心指标曲线、混淆矩阵、F1分数曲线、PR曲线、验证集预测结果和标签分布图满足毕设答辩或课程设计演示需求。项目代码经测试运行成功已有139人学习使用。配套README与操作说明便于上手适合需要完整目标检测项目、快速搭建系统或基于YOLO做改进的读者。1. 社区消防通道占用预警为什么值得用 YOLOv8 做消防通道被私家车占用靠物业保安巡查永远有死角靠摄像头人工盯屏又盯不过来。这个项目做的就是一件事把监控画面接进来用 YOLOv8 实时检测通道内是否出现车辆或大型障碍物一旦占用超过设定时间自动弹窗、记录截图、触发告警。它解决的是“发现占用”这个最耗人力的环节适合用来做小区消防通道、园区内部道路、商场安全出口的占用监测原型。整套系统包含四块YOLOv8 检测模型、标注好的训练数据集、带视频预览和告警记录的可视化界面、以及从环境配置到模型部署的完整教程。对毕设和课程设计来说它的价值在于链路完整——不是只跑通一个detect.py而是从数据标注、模型训练到 GUI 展示、告警联动全部打通。新手拿到的是可复现的工程老手可以拿它当脚手架把检测类别、告警策略、界面交互换成自己业务需要的部分。下面按我一个做机器视觉落地项目的习惯把这个系统的每个关键环节拆开讲。2. 系统拆解YOLOv8 选型理由、目录结构与告警主流程拿到这类项目第一步不是跑代码而是先看懂它由哪几块组成。整个预警系统的数据流是视频流摄像头或本地视频→ YOLOv8 逐帧推理 → 目标过滤与占用判断 → 界面显示与告警记录。这一章先把选型理由、代码目录和组织方式讲清楚再给一个最精简的推理主流程。2.1 为什么是 YOLOv8而不是 SSD、Faster R-CNN 或 YOLOv5消防通道占用检测有一个特点目标是静止或缓行的车辆背景相对固定但光线变化大白天逆光、夜间车灯、阴雨天而且对误报率敏感。如果频繁把行人或影子当成车物业人员很快就会关掉告警。YOLOv8 在这个场景下是性价比最高的选择。对比 Faster R-CNN它是单阶段检测推理速度快在普通 GTX 1660 Ti 这类显卡上跑 640×640 输入s 模型能做到 60 FPS 以上完全够用对比 YOLOv5v8 用 Anchor-Free 的解耦头把分类和回归分成两个分支对小目标和遮挡目标的召回率更好训练收敛也更稳。更重要的是YOLOv8 自带 export 工具可以导出 ONNX、TensorRT 格式后续如果要部署到 RK3588 这类边缘设备迁移成本低。在这个项目里检测类别不需要多通常就三类car占用通道的车辆、obstacle堆物、石墩等、fire_hydrant消防设施用于排除误报。类别越少模型越好训练误检率也越低。我一个习惯宁可先只做“车辆”一类跑通全流程再加第二类。类别多了标注量成倍上涨反而不利于毕设周期。2.2 标准目录结构模型、数据、界面、工具分开放这类带 GUI 的检测项目目录结构通常按“模型权重 / 数据集 / 界面代码 / 工具脚本”划分。我拿到手的项目一般长这样fire_channel_yolov8/ ├── weights/ # 训练好的权重best.pt 和 last.pt ├── data/ │ ├── images/ # 原图train/val 按子目录分 │ └── labels/ # YOLO 格式的 txt 标注 ├── datasets/ │ └── fire_channel.yaml # 数据配置文件 ├── ui/ │ ├── main_window.py # PyQt5 主界面 │ └── resources/ # 图标、qss 样式 ├── tools/ │ ├── convert_labelme.py # labelme 转 YOLO 格式 │ └── split_dataset.py # 按比例划分训练验证集 ├── detect.py # 命令行推理脚本 └── requirements.txt # 依赖清单这个拆分的核心思想是“数据和代码分离”。训练时只改data.yaml界面和推理脚本不碰数据目录weights单独放换模型只换文件不改代码。很多翻车的项目都是把图片、标注、脚本混在一个文件夹里训练到一半想重新划分数据集就得手动搬文件非常容易出错。requirements.txt是这类项目最先要看的东西常见依赖包括ultralytics、torch、torchvision、opencv-python、PyQt5、numpy。如果有onnx、onnxruntime-gpu说明项目还带导出和加速推理的链路。2.3 推理主流程检测—过滤—占用判断—告警界面和告警逻辑都建立在推理结果上。YOLOv8 的model.predict()返回的是一个Results对象列表里面包含检测框坐标、类别 id 和置信度。但直接拿去用会踩坑它返回的是归一化坐标xywhn画框和判断都需要转换。我一般自己写一个轻量封装import cv2 from ultralytics import YOLO class FireChannelDetector: def __init__(self, weights_path, conf_thres0.35): self.model YOLO(weights_path) self.conf_thres conf_thres self.target_classes [0, 1] # 0:car 1:obstacle def detect_frame(self, frame): 输入 BGR 帧返回所有命中目标的框列表 results self.model.predict( sourceframe, confself.conf_thres, verboseFalse )[0] boxes [] for box in results.boxes: cls_id int(box.cls[0]) conf float(box.conf[0]) if cls_id not in self.target_classes: continue x1, y1, x2, y2 box.xyxy[0].tolist() boxes.append({ class: cls_id, conf: conf, bbox: [int(x1), int(y1), int(x2), int(y2)] }) return boxes这段代码里有两个关键设计conf_thres0.35是占用检测的常用起始阈值比通用检测的 0.25 要高因为消防通道场景宁可漏检也不可频繁误报verboseFalse是必须的否则 YOLOv8 每次推理都会往终端打印一行日志跑视频时日志会刷屏界面也容易卡。拿到boxes之后做什么常见做法是先判断目标是否落在“通道区域”内也就是用多边形或矩形划定一个 ROI只有中心点落在 ROI 里的目标才参与占用统计。然后是连续帧确认——单帧检出不算告警连续 N 帧通常 15~30 帧都检出同一位置有目标才触发占用告警。这个逻辑放在下一章的告警策略里细讲。提示YOLOv8 的坐标是相对于原图尺寸的像素值不是归一化值画框直接用即可。但如果你用results[0].boxes.xywhn就得乘回图像的宽高。3. 环境部署、数据集准备与模型训练从零跑通全链路这一章是整个项目最重的部分。先建环境再做数据集最后跑训练。很多人急着先跑train.py结果要么 CUDA 版本不对要么数据集格式是 VOC 的跑不起来。按顺序来每一步都能验证出问题也好定位。3.1 环境搭建用 conda 隔离环境避免污染系统 Python这类项目最常见的运行环境是 Windows 10/11 或 Ubuntu 20.04GPU 用 NVIDIA 显卡CUDA 11.8 或 12.x。我一般建议用 conda 创建独立环境Python 版本选 3.9 或 3.10不要用 3.12因为 PyTorch 对 3.12 的支持曾经有段时间不稳定。# 创建环境并指定 Python 版本 conda create -n fire_channel python3.10 -y conda activate fire_channel # 安装 PyTorch这里用 cu118 版本对应 CUDA 11.8 pip install torch2.1.2 torchvision0.16.2 --index-url https://download.pytorch.org/whl/cu118 # 安装 YOLOv8 依赖和界面库 pip install ultralytics opencv-python PyQt5 pandas # 验证安装 python -c import torch; print(torch.cuda.is_available())关键点在于 PyTorch 和 CUDA 的版本匹配。torch.cuda.is_available()输出True才能用 GPU 训练否则会静默回退到 CPU训练速度慢几十倍很多人误以为程序卡死了。CPU 版本也能跑但训练 100 轮可能要好几天不建议。Ultralytics 会自动安装匹配的 torch 版本但它在某些情况下会装 CPU 版所以我习惯先手动装好 torch再装 ultralytics这样不会覆盖 torch。这是个血泪经验顺序反了后面torch.cuda.is_available()可能变成False。3.2 标注与格式转换Labelme 标注结果如何变成 YOLOv8 能吃的 txtYOLOv8 训练需要的数据格式是每张图片对应一个同名 txt 文件放在labels目录下每行内容是类别id 中心x 中心y 宽度 高度全部归一化到 0~1。而大家标注时常用 Labelme它导出的是 JSON 文件里面存的是多边形顶点坐标格式完全不同。所以必须有一个转换脚本。import json import os import cv2 def labelme_to_yolo(json_path, save_dir, class_map): 把 labelme 的 json 标注转成 YOLO 格式 txt with open(json_path, r, encodingutf-8) as f: data json.load(f) image_path os.path.join(os.path.dirname(json_path), data[imagePath]) img cv2.imread(image_path) if img is None: print(f无法读取图片: {image_path}) return False h, w img.shape[:2] txt_name os.path.basename(json_path).replace(.json, .txt) txt_path os.path.join(save_dir, txt_name) with open(txt_path, w, encodingutf-8) as out: for shape in data[shapes]: label shape[label] if label not in class_map: continue cls_id class_map[label] points shape[points] # 多边形顶点 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) # 转成 YOLO 的 xywh 归一化格式 box_w (x_max - x_min) / w box_h (y_max - y_min) / h cx ((x_min x_max) / 2) / w cy ((y_min y_max) / 2) / h out.write(f{cls_id} {cx:.6f} {cy:.6f} {box_w:.6f} {box_h:.6f}\n) return True class_map {car: 0, obstacle: 1, fire_hydrant: 2}这段脚本的核心是把 labelme 的多边形外接矩形转成 YOLO 格式的框。注意class_map必须和后面的data.yaml保持一致这是新手最容易忽略的标注里的类别名和 yaml 里 classes 的顺序对不上训练出来的类别就全乱了。另外一个常见问题是 json 里imagePath可能只存了文件名而不是完整路径脚本里做了拼接但要求 json 和图片在同一目录或者imagePath是相对路径。跑转换脚本前先打印几个 json 的imagePath字段确认路径拼得对。3.3 数据集划分与 data.yaml训练前最后一关数据集准备好之后要按照 8:2 或 9:1 划分训练集和验证集。划分时要保证同一场景的图片不全堆在训练集里否则验证集太简单mAP 虚高。写一个简单的划分脚本# 在项目根目录下执行 python tools/split_dataset.py --images data/images --labels data/labels --val_ratio 0.2脚本逻辑很简单遍历images目录下的图片按比例随机抽到train和val两个子目录同时把对应的 txt 标注也复制过去。注意是按图片名成对复制不是分别随机抽否则会出现“图片在训练集、标注在验证集”这种错位情况。之后写data.yamlpath: /绝对路径/fire_channel # 数据集根目录 train: images/train val: images/val names: 0: car 1: obstacle 2: fire_hydrant核心要点有两个path必须是绝对路径或者训练时用--data传入相对路径但工作目录必须在项目根names的索引顺序必须和转换脚本里的class_map完全一致。这俩对不上是训练阶段报错或者类别错乱的最主要原因遇到这类问题优先检查 yaml。3.4 训练参数怎么设拿默认值起步再调三个关键项训练命令本身不长但参数含义值得细说。以这个消防通道数据集为例假设约 2000 张图# 在项目根目录执行 yolo detect train \ datadatasets/fire_channel.yaml \ modelyolov8s.pt \ epochs100 \ imgsz640 \ batch16 \ patience20 \ projectruns/train \ nameexp_fire_channel \ device0参数含义我的建议model预训练权重数据量小就选yolov8s.pt别上来就用yolov8xepochs训练轮数100 起步mAP 不再涨就提前停imgsz输入分辨率640 是速度和精度的平衡点batch批次大小显存不够就 16 改 8或调小 imgszpatience早停耐心值20~30防止过拟合和浪费时间训练过程中最重要的观测指标不是 loss而是验证集上的mAP50和mAP50-95。我一般每 10 轮看一眼runs/train/exp_fire_channel/results.png这个图里包含了 loss 曲线、PR 曲线和 mAP 曲线。如果 loss 一直降但 mAP 不动基本就是数据集有问题比如标注框严重不准或者训练集和验证集分布差异过大。yolov8s在这个数据集上跑 100 轮通常 mAP50 能达到 90% 以上。如果只有 60% 多先别调参回去检查标注。模型结构对这类单场景检测来说好坏不是决定因素数据质量才是。4. 可视化界面与告警链路把模型接到能用的面板上模型训练完只是第一步对这个项目来说能交到用户手里的是一套有界面、能看实时画面的系统。这一章讲界面怎么做、推理线程怎么处理、告警怎么触发。4.1 界面功能拆分一个“能用”的预警界面至少要有这些这类项目的界面核心功能是固定的视频显示区、检测状态栏、告警记录表、参数控制区。我用 PyQt5 做界面常见布局如下左侧大区域QLabel或QGraphicsView显示实时视频帧检测框画在上面右侧面板模型路径选择、置信度滑条、告警状态指示灯下方表格QTableWidget记录告警时间、目标类别、置信度、截图路径底部按钮开始/停止检测、选择视频或摄像头、导出告警记录按钮和业务逻辑分开是界面代码的核心组织方式。每个按钮只做一件事开始按钮启动推理线程停止按钮请求线程退出不要在同一个槽函数里既开线程又读视频。否则界面会在点击按钮的瞬间卡死。4.2 用一个线程跑推理保证界面不卡的唯一可靠办法PyQt 界面卡死的最常见原因是把model.predict()直接放进了 UI 线程。YOLOv8 的单帧推理在 GPU 上虽然只要几十毫秒但读取视频帧、缩放、后处理加起来再加上 GUI 事件循环界面就会肉眼可见地掉帧。正确做法是开一个独立的QThread做推理通过信号把结果传回主线程。from PyQt5.QtCore import QThread, pyqtSignal import cv2 from detection.core import FireChannelDetector class DetectThread(QThread): frame_ready pyqtSignal(object, list) # 原始帧 和 检测框列表 alarm_triggered pyqtSignal(dict) # 告警信息 def __init__(self, video_source0, weights_pathweights/best.pt): super().__init__() self.video_source video_source self.detector FireChannelDetector(weights_path) self.running True def run(self): cap cv2.VideoCapture(self.video_source) while self.running and cap.isOpened(): ret, frame cap.read() if not ret: break boxes self.detector.detect_frame(frame) self.frame_ready.emit(frame, boxes) self.check_alarm(boxes) cap.release() def stop(self): self.running False def check_alarm(self, boxes): # 连续帧确认逻辑满足条件就 emit pass这里有个设计容易被忽略stop()里只改了running标志没有强制终止线程这是为了让当前帧处理完再退出避免cv2.VideoCapture释放时崩溃。如果你用thread.terminate()强行杀掉线程十次有八次会卡死在视频资源的释放上这是 PyQt 多线程里的一个经典坑。主线程里连接信号self.detect_thread.frame_ready.connect(self.update_frame) self.detect_thread.alarm_triggered.connect(self.show_alarm) def update_frame(self, frame, boxes): 在 QLabel 上画框并刷新显示 for box in boxes: x1, y1, x2, y2 box[bbox] cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 0, 255), 2) cv2.putText(frame, fconf:{box[conf]:.2f}, (x1, y1 - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 0, 255), 2) h, w frame.shape[:2] # 把 OpenCV 的 BGR 帧转成 QImage 显示 rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) qimg QImage(rgb.data, w, h, rgb.strides[0], QImage.Format_RGB888) self.video_label.setPixmap(QPixmap.fromImage(qimg))要点是cv2.rectangle直接在frame上画然后整个传给界面显示。不要在信号里传frame的同时再传一份复制内存开销大而且容易引入不一致。另一个细节是QImage(rgb.data, ...)里的rgb.strides[0]这是图像行字节数漏掉它会显示成斜的或花屏OpenCV 的图像在内存里是连续存储的但 PyQt 需要知道每行字节数才能正确解析。4.3 告警策略连续帧确认防止误报惊动物业单纯“检测到车”就告警会带来大量误报。真实场景里一辆车从通道口缓慢经过或者行人带着大件行李路过都会触发一次检测。物业值班人员被骚扰几次之后告警就没人看了。我常用的策略是“连续 N 帧确认 位置保持”具体规则参数取值说明连续帧数15约 0.5 秒30 FPS 下过滤瞬间通过的物体位置漂移阈值框中心位移 50px目标是占用不是移动物体经过告警冷却时间60 秒同一位置告警后冷却期内不重复弹窗实现上就是在DetectThread里维护一个“目标轨迹表”每次检测到目标就累加连续命中计数一旦计数到 15 且位置变化不大就发alarm_triggered信号然后清空计数。代码不复杂但这个逻辑是系统“功能完善”的关键。只做检测不做确认的预警系统基本不可能在实际场景里稳定运行。def check_alarm(self, boxes): current_time time.time() for box in boxes: cx (box[bbox][0] box[bbox][2]) / 2 cy (box[bbox][1] box[bbox][3]) / 2 for track in self.tracks: prev_cx, prev_cy track[center] if abs(cx - prev_cx) 50 and abs(cy - prev_cy) 50: track[count] 1 track[center] (cx, cy) if track[count] 15 and current_time - track[last_alarm] 60: self.alarm_triggered.emit({ time: time.strftime(%Y-%m-%d %H:%M:%S), class: box[class], conf: box[conf] }) track[last_alarm] current_time track[count] 0 break else: self.tracks.append({ center: (cx, cy), count: 1, last_alarm: 0 })这个遍历逻辑里有个细节for...else...的else在匹配不到已有轨迹时执行用来新建轨迹。last_alarm初始为 0保证第一次占用立刻能告警之后 60 秒内不再重复既覆盖了占用持续场景又不会刷屏。5. 部署避坑环境、界面、训练中最容易翻车的 5 个问题这一章集中写我在这类项目上反复踩过的坑。每一条都是真实场景按“现象→原因→解决”的方式整理看完能省几天的排查时间。5.1 新电脑上跑不起来提示 torch 的 CUDA 版本不对现象项目在别人电脑上能跑在自己电脑上import torch报错或者torch.cuda.is_available()是False训练时 CPU 占用拉满、GPU 不动。原因PyTorch 是编译好的二进制包它依赖的 CUDA runtime 和显卡驱动不完全是一回事。很多情况是显卡驱动太老或者装 torch 时装了 CPU 版或者 CUDA 版本和 torch 不配套。解决先运行nvidia-smi查看驱动支持的 CUDA 版本然后按这个版本去 PyTorch 官网选对应安装命令。最常见的是 CUDA 11.8 配torch2.1.2或者 CUDA 12.1 配torch2.3.1。不要贪新装 torch 2.5ultralytics 和 PyQt5 这些库未必跟得上。装完务必执行python -c import torch; print(torch.cuda.is_available())确认是True再继续。5.2 PyQt 界面一开就“无响应”或者点开始按钮就转圈现象界面能打开但点击“开始检测”后整个窗口卡死标题栏显示“未响应”几秒后强制关闭。原因推理和界面刷新跑在同一个线程里。model.predict()每帧都要几十毫秒加上视频读取、画框、刷新 QLabel主线程的事件循环被阻塞界面自然就卡了。有时候不是卡死是视频读取速度跟不上但主线程还在忙表现也差不多。解决把推理放到QThread子线程主线程只负责接收信号刷新界面。注意视频读取cap.read()也要放在子线程里因为读视频也是阻塞操作。如果你发现QThread里跑YOLO模型偶尔崩溃先在子线程的run()方法开头加一行self.model YOLO(weights)——不要把模型作为构造参数传进去再赋值确保模型在子线程内部创建避免 QThread 和模型内部的 OpenMP 线程冲突。5.3 训练 loss 降得很好验证集 mAP 却一直很低现象训练时边界框损失和分类损失都在下降但验证集上的 mAP50 卡在 40%~60%怎么加 epochs 都没用。原因八成是数据集划分出问题。比如同一段监控视频抽帧出来的图片全部或者大部分进了训练集验证集里全是不一样场景的画面再或者标注框画得不一致——有的把整车框住有的只框了车身模型学到的框形状本身就矛盾。另一个常见原因是类别名和data.yaml顺序不一致导致验证集标注全部对不上。解决先查看runs/train/exp/val_batch0_pred.jpg这个是预测和真实标注的对比图能直观看出是漏检还是框偏。如果框偏回去检查转换脚本里归一化是否正确如果对不上检查class_map和 yaml 的映射顺序。划分数据集时用sklearn.model_selection.train_test_split按视频片段分组划分不要按单张图片随机分保证同一段视频的帧不跨训练验证。5.4 视频检测时闪退提示 cuda out of memory现象单张图片推理没问题跑视频或者摄像头实时检测时运行几十秒后弹 CUDA 内存不足。原因视频流源源不断推理一次没问题但 OpenCV 的VideoCapture缓冲了过多帧积压在内存里加上显卡显存被 YOLO 模型和图像张量占用最后爆掉。还有一种情况是代码里每帧都调model.predict()内部反复创建张量没有显式释放。解决给model.predict()传入单帧而不是整个视频路径这样每一帧独立推理帧与帧之间不会有累积。cv2.VideoCapture的设置加上cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)让视频缓冲只保留一帧。如果还爆显存把imgsz从 640 降到 480或者把batch显式设为 1。5.5 onnx 导出成功但推理结果与 .pt 不一致现象yolo export modelbest.pt formatonnx导出成功用onnxruntime加载后检测结果和目标数量都对不上或者类别顺序乱了。原因YOLOv8 导出的 ONNX 输出是一个[1, 84, 8400]的张量前 4 个值是框坐标后面 80 个是各类别分数。很多人在后处理时忘了做“非极大值抑制NMS”或者对输出维度做了错误的转置。再者ONNX 模型默认输入是 RGB 且归一化过的用 OpenCV 读进去的 BGR 帧直接喂给 ONNX 会差很多。解决如果只是毕设展示直接用.pt就够了ONNX 导出这一步可以放一放。如果确实要导出记得记录模型的输入格式并在 ONNX 推理代码里做一遍-[..., ::-1]的 BGR 转 RGB 操作之后除以 255 归一化。后处理务必用现成的 NMS 函数比如cv2.dnn.NMSBoxes不要自己写循环去重写错概率极高。提示这类项目的部署教程里如果提到“导出 ONNX 加速”你先确认自己的需求是不是真的需要跨平台部署。只是课堂演示或论文验证直接用YOLO(best.pt)就够了少一个环节少一个坑。6. 进阶从“跑通”到“好用”的三个针对性优化模型能跑通、界面能显示只是起点。消防通道占用场景有它自己的难点白天和夜间光线差异极大、通道尽头常停着正常车辆、监控视角有畸变。把这三个问题处理好整个系统的可用性会明显上一个台阶。第一个优化是针对夜间场景的数据增强。白天训练的模型直接跑夜间监控漏检率会明显升高。解决方法是训练时开启hsv_h、hsv_s、hsv_v增强并额外标注 200~300 张夜间图。如果不想额外标注可以用albumentations在训练管线里对图片做随机亮度对比度调整把白天图“模拟”成夜间效果。实测对夜间召回率提升 5~10 个百分点代价是白天场景的误报可能略增。我一般会先把夜间图单独做一个小验证集专门对比增强前后的 mAP。第二个优化是 ROI 区域限定。消防通道的监控通常有固定的摄像头视角通道区域在画面里占一块固定区域。在推理代码里预先配置一个多边形 ROI检测框中心点落在 ROI 外的直接丢弃能过滤掉大量误报。这个逻辑加在detect_frame()的返回结果过滤阶段用cv2.pointPolygonTest判断即可。实际上比增加模型复杂度更有效的误报抑制手段就是这个。第三个优化是告警截图与日志联动。每次触发告警时把当前帧保存为带时间戳的图片同时把一条记录写入 CSV 或 SQLite。展示时用表格或日历视图回放历史这个功能在答辩演示里很加分因为评审老师一眼就能看出系统“有闭环”而不是只在画面上画框。说起来这类系统我做过不只一次最深的体会是模型训练占三成时间数据整理和界面联调占七成。训练参数调来调去远不如把标注质量提高、把告警逻辑做严谨更有效。建议你拿到这个项目先跑通默认流程再按自己所在地的真实消防通道环境补一批图片重新训练效果一定比直接用现成权重好。希望帮到你。本文还有配套的精品资源点击获取 YOLOv8实战：消防通道占用预警系统开发与部署
简介基于YOLOv8的社区消防通道占用预警系统是一套可直接落地的毕业设计项目面向计算机相关专业学生、老师及企业开发者用于消防通道占用检测与可视化预警。压缩包内共97个文件涵盖70个Python源码、12个编译缓存pyc、5个XML配置、4个模型权重pt文件及说明文档等整体仅24.21MB。源码包含可视化界面、检测服务、模型训练与推理模块提供best.pt权重、数据集及部署教程可生成核心指标曲线、混淆矩阵、F1分数曲线、PR曲线、验证集预测结果和标签分布图满足毕设答辩或课程设计演示需求。项目代码经测试运行成功已有139人学习使用。配套README与操作说明便于上手适合需要完整目标检测项目、快速搭建系统或基于YOLO做改进的读者。1. 社区消防通道占用预警为什么值得用 YOLOv8 做消防通道被私家车占用靠物业保安巡查永远有死角靠摄像头人工盯屏又盯不过来。这个项目做的就是一件事把监控画面接进来用 YOLOv8 实时检测通道内是否出现车辆或大型障碍物一旦占用超过设定时间自动弹窗、记录截图、触发告警。它解决的是“发现占用”这个最耗人力的环节适合用来做小区消防通道、园区内部道路、商场安全出口的占用监测原型。整套系统包含四块YOLOv8 检测模型、标注好的训练数据集、带视频预览和告警记录的可视化界面、以及从环境配置到模型部署的完整教程。对毕设和课程设计来说它的价值在于链路完整——不是只跑通一个detect.py而是从数据标注、模型训练到 GUI 展示、告警联动全部打通。新手拿到的是可复现的工程老手可以拿它当脚手架把检测类别、告警策略、界面交互换成自己业务需要的部分。下面按我一个做机器视觉落地项目的习惯把这个系统的每个关键环节拆开讲。2. 系统拆解YOLOv8 选型理由、目录结构与告警主流程拿到这类项目第一步不是跑代码而是先看懂它由哪几块组成。整个预警系统的数据流是视频流摄像头或本地视频→ YOLOv8 逐帧推理 → 目标过滤与占用判断 → 界面显示与告警记录。这一章先把选型理由、代码目录和组织方式讲清楚再给一个最精简的推理主流程。2.1 为什么是 YOLOv8而不是 SSD、Faster R-CNN 或 YOLOv5消防通道占用检测有一个特点目标是静止或缓行的车辆背景相对固定但光线变化大白天逆光、夜间车灯、阴雨天而且对误报率敏感。如果频繁把行人或影子当成车物业人员很快就会关掉告警。YOLOv8 在这个场景下是性价比最高的选择。对比 Faster R-CNN它是单阶段检测推理速度快在普通 GTX 1660 Ti 这类显卡上跑 640×640 输入s 模型能做到 60 FPS 以上完全够用对比 YOLOv5v8 用 Anchor-Free 的解耦头把分类和回归分成两个分支对小目标和遮挡目标的召回率更好训练收敛也更稳。更重要的是YOLOv8 自带 export 工具可以导出 ONNX、TensorRT 格式后续如果要部署到 RK3588 这类边缘设备迁移成本低。在这个项目里检测类别不需要多通常就三类car占用通道的车辆、obstacle堆物、石墩等、fire_hydrant消防设施用于排除误报。类别越少模型越好训练误检率也越低。我一个习惯宁可先只做“车辆”一类跑通全流程再加第二类。类别多了标注量成倍上涨反而不利于毕设周期。2.2 标准目录结构模型、数据、界面、工具分开放这类带 GUI 的检测项目目录结构通常按“模型权重 / 数据集 / 界面代码 / 工具脚本”划分。我拿到手的项目一般长这样fire_channel_yolov8/ ├── weights/ # 训练好的权重best.pt 和 last.pt ├── data/ │ ├── images/ # 原图train/val 按子目录分 │ └── labels/ # YOLO 格式的 txt 标注 ├── datasets/ │ └── fire_channel.yaml # 数据配置文件 ├── ui/ │ ├── main_window.py # PyQt5 主界面 │ └── resources/ # 图标、qss 样式 ├── tools/ │ ├── convert_labelme.py # labelme 转 YOLO 格式 │ └── split_dataset.py # 按比例划分训练验证集 ├── detect.py # 命令行推理脚本 └── requirements.txt # 依赖清单这个拆分的核心思想是“数据和代码分离”。训练时只改data.yaml界面和推理脚本不碰数据目录weights单独放换模型只换文件不改代码。很多翻车的项目都是把图片、标注、脚本混在一个文件夹里训练到一半想重新划分数据集就得手动搬文件非常容易出错。requirements.txt是这类项目最先要看的东西常见依赖包括ultralytics、torch、torchvision、opencv-python、PyQt5、numpy。如果有onnx、onnxruntime-gpu说明项目还带导出和加速推理的链路。2.3 推理主流程检测—过滤—占用判断—告警界面和告警逻辑都建立在推理结果上。YOLOv8 的model.predict()返回的是一个Results对象列表里面包含检测框坐标、类别 id 和置信度。但直接拿去用会踩坑它返回的是归一化坐标xywhn画框和判断都需要转换。我一般自己写一个轻量封装import cv2 from ultralytics import YOLO class FireChannelDetector: def __init__(self, weights_path, conf_thres0.35): self.model YOLO(weights_path) self.conf_thres conf_thres self.target_classes [0, 1] # 0:car 1:obstacle def detect_frame(self, frame): 输入 BGR 帧返回所有命中目标的框列表 results self.model.predict( sourceframe, confself.conf_thres, verboseFalse )[0] boxes [] for box in results.boxes: cls_id int(box.cls[0]) conf float(box.conf[0]) if cls_id not in self.target_classes: continue x1, y1, x2, y2 box.xyxy[0].tolist() boxes.append({ class: cls_id, conf: conf, bbox: [int(x1), int(y1), int(x2), int(y2)] }) return boxes这段代码里有两个关键设计conf_thres0.35是占用检测的常用起始阈值比通用检测的 0.25 要高因为消防通道场景宁可漏检也不可频繁误报verboseFalse是必须的否则 YOLOv8 每次推理都会往终端打印一行日志跑视频时日志会刷屏界面也容易卡。拿到boxes之后做什么常见做法是先判断目标是否落在“通道区域”内也就是用多边形或矩形划定一个 ROI只有中心点落在 ROI 里的目标才参与占用统计。然后是连续帧确认——单帧检出不算告警连续 N 帧通常 15~30 帧都检出同一位置有目标才触发占用告警。这个逻辑放在下一章的告警策略里细讲。提示YOLOv8 的坐标是相对于原图尺寸的像素值不是归一化值画框直接用即可。但如果你用results[0].boxes.xywhn就得乘回图像的宽高。3. 环境部署、数据集准备与模型训练从零跑通全链路这一章是整个项目最重的部分。先建环境再做数据集最后跑训练。很多人急着先跑train.py结果要么 CUDA 版本不对要么数据集格式是 VOC 的跑不起来。按顺序来每一步都能验证出问题也好定位。3.1 环境搭建用 conda 隔离环境避免污染系统 Python这类项目最常见的运行环境是 Windows 10/11 或 Ubuntu 20.04GPU 用 NVIDIA 显卡CUDA 11.8 或 12.x。我一般建议用 conda 创建独立环境Python 版本选 3.9 或 3.10不要用 3.12因为 PyTorch 对 3.12 的支持曾经有段时间不稳定。# 创建环境并指定 Python 版本 conda create -n fire_channel python3.10 -y conda activate fire_channel # 安装 PyTorch这里用 cu118 版本对应 CUDA 11.8 pip install torch2.1.2 torchvision0.16.2 --index-url https://download.pytorch.org/whl/cu118 # 安装 YOLOv8 依赖和界面库 pip install ultralytics opencv-python PyQt5 pandas # 验证安装 python -c import torch; print(torch.cuda.is_available())关键点在于 PyTorch 和 CUDA 的版本匹配。torch.cuda.is_available()输出True才能用 GPU 训练否则会静默回退到 CPU训练速度慢几十倍很多人误以为程序卡死了。CPU 版本也能跑但训练 100 轮可能要好几天不建议。Ultralytics 会自动安装匹配的 torch 版本但它在某些情况下会装 CPU 版所以我习惯先手动装好 torch再装 ultralytics这样不会覆盖 torch。这是个血泪经验顺序反了后面torch.cuda.is_available()可能变成False。3.2 标注与格式转换Labelme 标注结果如何变成 YOLOv8 能吃的 txtYOLOv8 训练需要的数据格式是每张图片对应一个同名 txt 文件放在labels目录下每行内容是类别id 中心x 中心y 宽度 高度全部归一化到 0~1。而大家标注时常用 Labelme它导出的是 JSON 文件里面存的是多边形顶点坐标格式完全不同。所以必须有一个转换脚本。import json import os import cv2 def labelme_to_yolo(json_path, save_dir, class_map): 把 labelme 的 json 标注转成 YOLO 格式 txt with open(json_path, r, encodingutf-8) as f: data json.load(f) image_path os.path.join(os.path.dirname(json_path), data[imagePath]) img cv2.imread(image_path) if img is None: print(f无法读取图片: {image_path}) return False h, w img.shape[:2] txt_name os.path.basename(json_path).replace(.json, .txt) txt_path os.path.join(save_dir, txt_name) with open(txt_path, w, encodingutf-8) as out: for shape in data[shapes]: label shape[label] if label not in class_map: continue cls_id class_map[label] points shape[points] # 多边形顶点 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) # 转成 YOLO 的 xywh 归一化格式 box_w (x_max - x_min) / w box_h (y_max - y_min) / h cx ((x_min x_max) / 2) / w cy ((y_min y_max) / 2) / h out.write(f{cls_id} {cx:.6f} {cy:.6f} {box_w:.6f} {box_h:.6f}\n) return True class_map {car: 0, obstacle: 1, fire_hydrant: 2}这段脚本的核心是把 labelme 的多边形外接矩形转成 YOLO 格式的框。注意class_map必须和后面的data.yaml保持一致这是新手最容易忽略的标注里的类别名和 yaml 里 classes 的顺序对不上训练出来的类别就全乱了。另外一个常见问题是 json 里imagePath可能只存了文件名而不是完整路径脚本里做了拼接但要求 json 和图片在同一目录或者imagePath是相对路径。跑转换脚本前先打印几个 json 的imagePath字段确认路径拼得对。3.3 数据集划分与 data.yaml训练前最后一关数据集准备好之后要按照 8:2 或 9:1 划分训练集和验证集。划分时要保证同一场景的图片不全堆在训练集里否则验证集太简单mAP 虚高。写一个简单的划分脚本# 在项目根目录下执行 python tools/split_dataset.py --images data/images --labels data/labels --val_ratio 0.2脚本逻辑很简单遍历images目录下的图片按比例随机抽到train和val两个子目录同时把对应的 txt 标注也复制过去。注意是按图片名成对复制不是分别随机抽否则会出现“图片在训练集、标注在验证集”这种错位情况。之后写data.yamlpath: /绝对路径/fire_channel # 数据集根目录 train: images/train val: images/val names: 0: car 1: obstacle 2: fire_hydrant核心要点有两个path必须是绝对路径或者训练时用--data传入相对路径但工作目录必须在项目根names的索引顺序必须和转换脚本里的class_map完全一致。这俩对不上是训练阶段报错或者类别错乱的最主要原因遇到这类问题优先检查 yaml。3.4 训练参数怎么设拿默认值起步再调三个关键项训练命令本身不长但参数含义值得细说。以这个消防通道数据集为例假设约 2000 张图# 在项目根目录执行 yolo detect train \ datadatasets/fire_channel.yaml \ modelyolov8s.pt \ epochs100 \ imgsz640 \ batch16 \ patience20 \ projectruns/train \ nameexp_fire_channel \ device0参数含义我的建议model预训练权重数据量小就选yolov8s.pt别上来就用yolov8xepochs训练轮数100 起步mAP 不再涨就提前停imgsz输入分辨率640 是速度和精度的平衡点batch批次大小显存不够就 16 改 8或调小 imgszpatience早停耐心值20~30防止过拟合和浪费时间训练过程中最重要的观测指标不是 loss而是验证集上的mAP50和mAP50-95。我一般每 10 轮看一眼runs/train/exp_fire_channel/results.png这个图里包含了 loss 曲线、PR 曲线和 mAP 曲线。如果 loss 一直降但 mAP 不动基本就是数据集有问题比如标注框严重不准或者训练集和验证集分布差异过大。yolov8s在这个数据集上跑 100 轮通常 mAP50 能达到 90% 以上。如果只有 60% 多先别调参回去检查标注。模型结构对这类单场景检测来说好坏不是决定因素数据质量才是。4. 可视化界面与告警链路把模型接到能用的面板上模型训练完只是第一步对这个项目来说能交到用户手里的是一套有界面、能看实时画面的系统。这一章讲界面怎么做、推理线程怎么处理、告警怎么触发。4.1 界面功能拆分一个“能用”的预警界面至少要有这些这类项目的界面核心功能是固定的视频显示区、检测状态栏、告警记录表、参数控制区。我用 PyQt5 做界面常见布局如下左侧大区域QLabel或QGraphicsView显示实时视频帧检测框画在上面右侧面板模型路径选择、置信度滑条、告警状态指示灯下方表格QTableWidget记录告警时间、目标类别、置信度、截图路径底部按钮开始/停止检测、选择视频或摄像头、导出告警记录按钮和业务逻辑分开是界面代码的核心组织方式。每个按钮只做一件事开始按钮启动推理线程停止按钮请求线程退出不要在同一个槽函数里既开线程又读视频。否则界面会在点击按钮的瞬间卡死。4.2 用一个线程跑推理保证界面不卡的唯一可靠办法PyQt 界面卡死的最常见原因是把model.predict()直接放进了 UI 线程。YOLOv8 的单帧推理在 GPU 上虽然只要几十毫秒但读取视频帧、缩放、后处理加起来再加上 GUI 事件循环界面就会肉眼可见地掉帧。正确做法是开一个独立的QThread做推理通过信号把结果传回主线程。from PyQt5.QtCore import QThread, pyqtSignal import cv2 from detection.core import FireChannelDetector class DetectThread(QThread): frame_ready pyqtSignal(object, list) # 原始帧 和 检测框列表 alarm_triggered pyqtSignal(dict) # 告警信息 def __init__(self, video_source0, weights_pathweights/best.pt): super().__init__() self.video_source video_source self.detector FireChannelDetector(weights_path) self.running True def run(self): cap cv2.VideoCapture(self.video_source) while self.running and cap.isOpened(): ret, frame cap.read() if not ret: break boxes self.detector.detect_frame(frame) self.frame_ready.emit(frame, boxes) self.check_alarm(boxes) cap.release() def stop(self): self.running False def check_alarm(self, boxes): # 连续帧确认逻辑满足条件就 emit pass这里有个设计容易被忽略stop()里只改了running标志没有强制终止线程这是为了让当前帧处理完再退出避免cv2.VideoCapture释放时崩溃。如果你用thread.terminate()强行杀掉线程十次有八次会卡死在视频资源的释放上这是 PyQt 多线程里的一个经典坑。主线程里连接信号self.detect_thread.frame_ready.connect(self.update_frame) self.detect_thread.alarm_triggered.connect(self.show_alarm) def update_frame(self, frame, boxes): 在 QLabel 上画框并刷新显示 for box in boxes: x1, y1, x2, y2 box[bbox] cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 0, 255), 2) cv2.putText(frame, fconf:{box[conf]:.2f}, (x1, y1 - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 0, 255), 2) h, w frame.shape[:2] # 把 OpenCV 的 BGR 帧转成 QImage 显示 rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) qimg QImage(rgb.data, w, h, rgb.strides[0], QImage.Format_RGB888) self.video_label.setPixmap(QPixmap.fromImage(qimg))要点是cv2.rectangle直接在frame上画然后整个传给界面显示。不要在信号里传frame的同时再传一份复制内存开销大而且容易引入不一致。另一个细节是QImage(rgb.data, ...)里的rgb.strides[0]这是图像行字节数漏掉它会显示成斜的或花屏OpenCV 的图像在内存里是连续存储的但 PyQt 需要知道每行字节数才能正确解析。4.3 告警策略连续帧确认防止误报惊动物业单纯“检测到车”就告警会带来大量误报。真实场景里一辆车从通道口缓慢经过或者行人带着大件行李路过都会触发一次检测。物业值班人员被骚扰几次之后告警就没人看了。我常用的策略是“连续 N 帧确认 位置保持”具体规则参数取值说明连续帧数15约 0.5 秒30 FPS 下过滤瞬间通过的物体位置漂移阈值框中心位移 50px目标是占用不是移动物体经过告警冷却时间60 秒同一位置告警后冷却期内不重复弹窗实现上就是在DetectThread里维护一个“目标轨迹表”每次检测到目标就累加连续命中计数一旦计数到 15 且位置变化不大就发alarm_triggered信号然后清空计数。代码不复杂但这个逻辑是系统“功能完善”的关键。只做检测不做确认的预警系统基本不可能在实际场景里稳定运行。def check_alarm(self, boxes): current_time time.time() for box in boxes: cx (box[bbox][0] box[bbox][2]) / 2 cy (box[bbox][1] box[bbox][3]) / 2 for track in self.tracks: prev_cx, prev_cy track[center] if abs(cx - prev_cx) 50 and abs(cy - prev_cy) 50: track[count] 1 track[center] (cx, cy) if track[count] 15 and current_time - track[last_alarm] 60: self.alarm_triggered.emit({ time: time.strftime(%Y-%m-%d %H:%M:%S), class: box[class], conf: box[conf] }) track[last_alarm] current_time track[count] 0 break else: self.tracks.append({ center: (cx, cy), count: 1, last_alarm: 0 })这个遍历逻辑里有个细节for...else...的else在匹配不到已有轨迹时执行用来新建轨迹。last_alarm初始为 0保证第一次占用立刻能告警之后 60 秒内不再重复既覆盖了占用持续场景又不会刷屏。5. 部署避坑环境、界面、训练中最容易翻车的 5 个问题这一章集中写我在这类项目上反复踩过的坑。每一条都是真实场景按“现象→原因→解决”的方式整理看完能省几天的排查时间。5.1 新电脑上跑不起来提示 torch 的 CUDA 版本不对现象项目在别人电脑上能跑在自己电脑上import torch报错或者torch.cuda.is_available()是False训练时 CPU 占用拉满、GPU 不动。原因PyTorch 是编译好的二进制包它依赖的 CUDA runtime 和显卡驱动不完全是一回事。很多情况是显卡驱动太老或者装 torch 时装了 CPU 版或者 CUDA 版本和 torch 不配套。解决先运行nvidia-smi查看驱动支持的 CUDA 版本然后按这个版本去 PyTorch 官网选对应安装命令。最常见的是 CUDA 11.8 配torch2.1.2或者 CUDA 12.1 配torch2.3.1。不要贪新装 torch 2.5ultralytics 和 PyQt5 这些库未必跟得上。装完务必执行python -c import torch; print(torch.cuda.is_available())确认是True再继续。5.2 PyQt 界面一开就“无响应”或者点开始按钮就转圈现象界面能打开但点击“开始检测”后整个窗口卡死标题栏显示“未响应”几秒后强制关闭。原因推理和界面刷新跑在同一个线程里。model.predict()每帧都要几十毫秒加上视频读取、画框、刷新 QLabel主线程的事件循环被阻塞界面自然就卡了。有时候不是卡死是视频读取速度跟不上但主线程还在忙表现也差不多。解决把推理放到QThread子线程主线程只负责接收信号刷新界面。注意视频读取cap.read()也要放在子线程里因为读视频也是阻塞操作。如果你发现QThread里跑YOLO模型偶尔崩溃先在子线程的run()方法开头加一行self.model YOLO(weights)——不要把模型作为构造参数传进去再赋值确保模型在子线程内部创建避免 QThread 和模型内部的 OpenMP 线程冲突。5.3 训练 loss 降得很好验证集 mAP 却一直很低现象训练时边界框损失和分类损失都在下降但验证集上的 mAP50 卡在 40%~60%怎么加 epochs 都没用。原因八成是数据集划分出问题。比如同一段监控视频抽帧出来的图片全部或者大部分进了训练集验证集里全是不一样场景的画面再或者标注框画得不一致——有的把整车框住有的只框了车身模型学到的框形状本身就矛盾。另一个常见原因是类别名和data.yaml顺序不一致导致验证集标注全部对不上。解决先查看runs/train/exp/val_batch0_pred.jpg这个是预测和真实标注的对比图能直观看出是漏检还是框偏。如果框偏回去检查转换脚本里归一化是否正确如果对不上检查class_map和 yaml 的映射顺序。划分数据集时用sklearn.model_selection.train_test_split按视频片段分组划分不要按单张图片随机分保证同一段视频的帧不跨训练验证。5.4 视频检测时闪退提示 cuda out of memory现象单张图片推理没问题跑视频或者摄像头实时检测时运行几十秒后弹 CUDA 内存不足。原因视频流源源不断推理一次没问题但 OpenCV 的VideoCapture缓冲了过多帧积压在内存里加上显卡显存被 YOLO 模型和图像张量占用最后爆掉。还有一种情况是代码里每帧都调model.predict()内部反复创建张量没有显式释放。解决给model.predict()传入单帧而不是整个视频路径这样每一帧独立推理帧与帧之间不会有累积。cv2.VideoCapture的设置加上cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)让视频缓冲只保留一帧。如果还爆显存把imgsz从 640 降到 480或者把batch显式设为 1。5.5 onnx 导出成功但推理结果与 .pt 不一致现象yolo export modelbest.pt formatonnx导出成功用onnxruntime加载后检测结果和目标数量都对不上或者类别顺序乱了。原因YOLOv8 导出的 ONNX 输出是一个[1, 84, 8400]的张量前 4 个值是框坐标后面 80 个是各类别分数。很多人在后处理时忘了做“非极大值抑制NMS”或者对输出维度做了错误的转置。再者ONNX 模型默认输入是 RGB 且归一化过的用 OpenCV 读进去的 BGR 帧直接喂给 ONNX 会差很多。解决如果只是毕设展示直接用.pt就够了ONNX 导出这一步可以放一放。如果确实要导出记得记录模型的输入格式并在 ONNX 推理代码里做一遍-[..., ::-1]的 BGR 转 RGB 操作之后除以 255 归一化。后处理务必用现成的 NMS 函数比如cv2.dnn.NMSBoxes不要自己写循环去重写错概率极高。提示这类项目的部署教程里如果提到“导出 ONNX 加速”你先确认自己的需求是不是真的需要跨平台部署。只是课堂演示或论文验证直接用YOLO(best.pt)就够了少一个环节少一个坑。6. 进阶从“跑通”到“好用”的三个针对性优化模型能跑通、界面能显示只是起点。消防通道占用场景有它自己的难点白天和夜间光线差异极大、通道尽头常停着正常车辆、监控视角有畸变。把这三个问题处理好整个系统的可用性会明显上一个台阶。第一个优化是针对夜间场景的数据增强。白天训练的模型直接跑夜间监控漏检率会明显升高。解决方法是训练时开启hsv_h、hsv_s、hsv_v增强并额外标注 200~300 张夜间图。如果不想额外标注可以用albumentations在训练管线里对图片做随机亮度对比度调整把白天图“模拟”成夜间效果。实测对夜间召回率提升 5~10 个百分点代价是白天场景的误报可能略增。我一般会先把夜间图单独做一个小验证集专门对比增强前后的 mAP。第二个优化是 ROI 区域限定。消防通道的监控通常有固定的摄像头视角通道区域在画面里占一块固定区域。在推理代码里预先配置一个多边形 ROI检测框中心点落在 ROI 外的直接丢弃能过滤掉大量误报。这个逻辑加在detect_frame()的返回结果过滤阶段用cv2.pointPolygonTest判断即可。实际上比增加模型复杂度更有效的误报抑制手段就是这个。第三个优化是告警截图与日志联动。每次触发告警时把当前帧保存为带时间戳的图片同时把一条记录写入 CSV 或 SQLite。展示时用表格或日历视图回放历史这个功能在答辩演示里很加分因为评审老师一眼就能看出系统“有闭环”而不是只在画面上画框。说起来这类系统我做过不只一次最深的体会是模型训练占三成时间数据整理和界面联调占七成。训练参数调来调去远不如把标注质量提高、把告警逻辑做严谨更有效。建议你拿到这个项目先跑通默认流程再按自己所在地的真实消防通道环境补一批图片重新训练效果一定比直接用现成权重好。希望帮到你。本文还有配套的精品资源点击获取