简介基于YOLOv8的电梯内电瓶车闯入报警项目面向计算机相关专业学生及毕设、课设人群解决电梯场景下电瓶车违规进入的实时检测与告警问题。资源共8个文件含3个Python脚本可视化界面、视频检测、模型训练、3个模型权重含yolov8n与best.pt、2个说明文档压缩包约15.91MB结构紧凑部署思路清晰。目前已有42人学习下载。除源码与完整数据集外还提供可视化操作页面和部署教程支持输出核心指标曲线、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果及标签分布图便于直接用于答辩展示。项目代码经测试运行成功拿来即可使用也可在此基础上扩展其他目标检测场景是完成毕设或课设的实用参考。1. 电梯内电瓶车闯入报警一个看起来简单、落地全是坑的 YOLOv8 项目这个标题指向的东西很明确用 YOLOv8 检测电梯监控画面里推进来的电瓶车一旦发现就弹窗报警、本地记录顺带给你一套可视化界面和完整数据集。它适合两类人一类是拿它做毕业设计或课程设计的学生需要能跑通、能演示、能写进论文另一类是物业或园区做安防预研的工程师想先花两天验证一下「摄像头本地推理」能不能压住电瓶车进电梯这件事。先给结论这个方向值得做但真正的难点不在训练而在数据分布和报警策略。电梯是个光照、角度、遮挡都极其刁钻的封闭场景电瓶车又和轮椅、大件快递、清洁推车长得足够像。你如果只是把通用 COCO 模型拉起来就上误报率会高到没人愿意用。这篇文章按一条可复现的路径走场景分析 → 数据集整理 → 模型训练 → 界面与报警联动 → 部署排错最后给你几个降低误报的进阶手段。全程基于 CPU 也能跑的配置有显卡更好。2. 场景分析与数据集处理先把「什么是电瓶车」这件事说清楚2.1 电梯监控的特殊性为什么通用模型在这里不靠谱电梯监控和普通道路监控最大的区别是视角和距离。普通路测摄像头是俯视或平视电瓶车是一个完整的侧面或背面轮廓电梯摄像头通常在顶部角落电瓶车从门口推进来时先看到车把和前轮然后才是车身最后车尾对着镜头。这意味着同一个目标在 3 秒内会经历「局部 → 大部分 → 局部」的形态变化模型如果只见过完整车身很容易在目标刚露头时漏检。光照方面更麻烦。电梯门打开时走廊强光涌入轿厢内背光电瓶车正好处在黑色剪影里门关上后轿厢内灯光通常偏冷白车身反光又可能过曝。同一个模型要在这些光照条件下都稳定输出靠的是数据集里包含足够多的「暗光 强背光 反光」样本而不是模型结构本身有多先进。所以做这个项目第一条原则不要直接拿 COCO 预训练权重硬跑。你要么用自己的数据微调要么在已有电瓶车检测数据集上做二次迁移。标题里说了带完整数据集但你在复现时仍然要检查一件事——数据集里的图是不是真的覆盖了电梯视角。如果是网上下载的道路场景电瓶车图用来做预训练还行直接当最终训练集会有明显落差。2.2 数据标注与格式转换从 Labelme 到 YOLO 的完整流程常见做法是用 Labelme 先标注再转成 YOLO 格式。Labelme 输出的是 JSON 多边形坐标YOLO 需要的是归一化的中心点 xywh 和类别 id。转换脚本每家写起来大同小异我给你一版我一直在用的带异常检查至少能帮你少踩一半的坑。import json import os from pathlib import Path def labelme_to_yolo(json_path, save_dir, class_map): 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: print(f[跳过] {json_path}: 图像尺寸为0) return False lines [] for shape in data[shapes]: label shape[label] if label not in class_map: print(f[跳过] 未知标签 {label} 在 {json_path}) continue 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) # 过滤掉标注面积过小或越界的框 if x_max x_min or y_max y_min: continue x_center (x_min x_max) / 2 / img_w y_center (y_min y_max) / 2 / img_h w (x_max - x_min) / img_w h (y_max - y_min) / img_h lines.append(f{class_map[label]} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}) if not lines: print(f[跳过] {json_path}: 没有有效框) return False txt_name Path(json_path).stem .txt out_path Path(save_dir) / txt_name with open(out_path, w) as f: f.write(\n.join(lines)) return True # 使用示例准备一个类别映射0 代表电瓶车 if __name__ __main__: class_map {electric_bicycle: 0} json_dir labelme_jsons yolo_dir labels os.makedirs(yolo_dir, exist_okTrue) for jf in Path(json_dir).glob(*.json): ok labelme_to_yolo(str(jf), yolo_dir, class_map) print(f{jf.name}: {转换成功 if ok else 转换失败/跳过})这段代码的逻辑重点有三个一是按多边形的外接矩形生成框适合电瓶车这类近似矩形的目标二是对空标注、零尺寸、未知类别做了跳过处理避免训练时读到坏标签直接崩三是坐标归一化到 0~1 区间这是 YOLO 训练的必要输入格式。转换完成后还要把每一张图片对应的 txt 检查一遍我通常用一条命令统计没有任何标注的 txt这类文件多半是标了但没存框或者标注时误操作。空标签文件会参与训练但贡献为零白白浪费一个 batch 的位置。find labels -name *.txt -size 0 | wc -l如果这个数字超过训练集的 1%我建议回查标注过程。常见现象是标注完忘了保存或者标注到一半软件闪退。另一个常见问题是标注了「人」和「电瓶车」两个类但转换脚本里没有把「人」映射掉导致类别 id 错位。类别 id 以 class_map 为准训练前先打印一张图的标签文本看看内容是不是符合预期。2.3 训练集划分与数据增强策略标注完成后按 8:1:1 划分 train / val / test。这里强调一个毕设和课设里最容易犯的错直接对整个文件夹用 split 随机划分没有考虑同一段监控视频的相邻帧同时出现在训练集和验证集导致验证指标虚高。正确做法是按视频片段分组划分——同一个视频的连续帧只能进同一个集合。数据增强方面YOLOv8 默认自带 mosaic、平移、旋转、HSV 扰动。电梯场景我建议把 HSV 的饱和度扰动调低一点因为轿厢灯光相对恒定过度改变色相会让模型学到错误的颜色关联。增强参数写在 data.yaml 里YOLOv8 的配置方式如下# data.yaml path: ./elevator_dataset train: images/train val: images/val test: images/test names: 0: electric_bicycle注意一个与网络下载数据集相关的坑很多公共数据集的图片命名是纯数字但里面可能混入了非 ASCII 字符Linux 上训练时路径解析会报错。我先统一重命名全部改为img_0001.jpg这种格式省得后面折腾。3. 用 YOLOv8 训练电梯场景检测模型命令、参数与效果验收3.1 环境搭建CPU 版本与 CUDA 版本怎么选标题里的部署教程大概率面向的是「下个 Anaconda、建个虚拟环境、pip install ultralytics」这条最稳妥的路。你在自己的机器上复现时先看清楚自己的显卡。没有 NVIDIA 显卡或者显卡显存小于 4G就老老实实装 CPU 版。训练慢一点无所谓反正最后推理跑得动就行。有独显但显存 8G 以上装 CUDA 版。这里最容易翻车的不是安装本身而是 torch 和 CUDA 版本不匹配——你按教程装完ultralytics一跑训练直接报AssertionError: CUDA unavailable十有八九是 torch 装成了 CPU 版。我一般这么装# CPU 版最省事兼容性最好 pip install ultralytics # torch 会默认装 CPU 版或通用版不需要额外指定 # CUDA 版先装匹配的 torch再装 ultralytics pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics装完验证一下python -c import torch; print(torch.cuda.is_available())打印True说明 CUDA 可用。这里不展开各版本适配细节不同 CUDA 版本对应的 torch 下载地址不同照着 PyTorch 官网生成命令最靠谱。CPU 版训练同一个数据集时间可能是 GPU 的 10 到 20 倍但毕设场景通常能接受。3.2 训练命令与关键参数含义环境就绪后直接训练。下面这条命令是我在这个项目上最常用的一组参数每项都对着电梯场景调过。yolo detect train \ data./elevator_dataset/data.yaml \ modelyolov8n.pt \ epochs80 \ imgsz640 \ batch8 \ workers4 \ patience15 \ lr00.01 \ augmentTrue \ project./runs \ nameelevator_exp1几个参数的说明modelyolov8n.ptn 是 nano 版参数量最小CPU 推理速度最快。电梯报警不需要检测几百个类别n 级别精度完全够用。如果你有显卡且追求更高准确率换成yolov8s.pt会有小幅提升但推理耗时和显存占用都会上升。imgsz640YOLOv8 默认值。不要盲目调大到 1280电梯摄像头画面里电瓶车通常占画面 20%~40%640 已经能给出足够细节。batch8显存不够就减到 4CPU 训练建议减到 2否则内存先爆。patience15连续 15 个 epoch 验证集 mAP 没有提升就提前终止。这个对时间紧张的毕设很实用我见过不少人训练到 80 epoch 还一直停下来等其实第 40 轮就已经收敛了。augmentTrue默认开启 mosaic 等增强。如果数据集里已经有大量相似场景增强过于激进反而会过拟合到增强分布可以关闭后对比一轮再决定。训练结束后看runs/elevator_exp1/下的results.png和confusion_matrix.png。前者有 loss 曲线和 mAP 曲线后者能直接看出电瓶车被误检成哪类。这里有一个很容易被忽略的点mAP 50 到 0.9 以上并不代表现场可用它只说明模型在测试集上表现好。测试集的图片分布决定了一切。3.3 验证用测试集图片跑一次前向推理训练完别急着做界面先拿测试集图跑一遍人工看图这一步不能省。yolo predict \ model./runs/elevator_exp1/weights/best.pt \ source./elevator_dataset/images/test/ \ conf0.4 \ saveTrue \ project./runs \ nametest_visual跑完后去runs/test_visual/一张张翻检测结果。你要重点看三类图电瓶车在画面边缘的、电瓶车被电梯扶手或人挡一半的、画面里同时有轮椅或大件行李的。这三类是后面误报和漏报的主要来源。如果你翻完 50 张图发现边缘遮挡和背光场景一个都没有说明你的测试集分布偏了。补数据的方法我会在第 5 章展开。现在你只需要确认一件事这个模型放在真实电梯画面里能不能在目标刚露头时给报警留出时间。4. 把模型变成报警系统可视化界面与告警联动怎么做4.1 界面选型为什么用 PySide6 而不是 Streamlit这题有两个主流答案。一个是 PySide6/PyQt 做桌面客户端能嵌入摄像头画面、实时画框、弹窗报警、记录日志表现力最强另一个是 Streamlit 做 Web 页面开发速度快但实时视频流支持比较别扭延迟高不适合安防场景。毕设答辩时一个能现场拖动的桌面窗口说服力远胜一个网页。所以核心界面我推荐 PySide6 OpenCV ultralytics 的组合。技术栈成熟遇到问题都能搜到答案而且所有功能都能在一个进程里跑完不用起 Flask 服务再配 WebSocket省掉一大截调试时间。界面功能上别只做一个「打开视频 → 显示检测框」的壳子。要让人觉得你是认真做过需求分析的至少再加三个东西报警状态指示灯、报警截图自动保存、检测帧率显示。前两个是安防系统的刚需第三个是给答辩老师演示性能用的。4.2 最小可用的报警界面代码下面这个脚本是可以在本地直接跑起来的最小版本它做了四件事读取摄像头或视频文件、YOLOv8 推理、画面叠加检测框和标签、检测到电瓶车时截屏保存。import sys from pathlib import Path import cv2 from PySide6.QtWidgets import ( QApplication, QMainWindow, QLabel, QPushButton, QVBoxLayout, QWidget ) from PySide6.QtGui import QImage, QPixmap from PySide6.QtCore import Qt, QTimer from ultralytics import YOLO class ElevatorApp(QMainWindow): def __init__(self, model_pathruns/elevator_exp1/weights/best.pt): super().__init__() self.model YOLO(model_path) self.cap cv2.VideoCapture(0) # 0 表示本地摄像头视频文件路径也可以 self.cap.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) self.cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) self.image_label QLabel() self.btn QPushButton(停止检测) self.status_label QLabel(状态检测中) layout QVBoxLayout() layout.addWidget(self.image_label) layout.addWidget(self.status_label) layout.addWidget(self.btn) container QWidget() container.setLayout(layout) self.setCentralWidget(container) self.timer QTimer() self.timer.timeout.connect(self.update_frame) self.timer.start(30) # 约 33ms 一帧接近 30FPS self.saved_count 0 self.save_dir Path(./alarm_shots) self.save_dir.mkdir(exist_okTrue) def update_frame(self): ret, frame self.cap.read() if not ret: self.status_label.setText(状态无法读取视频源) return results self.model(frame, conf0.4, devicecpu) alarm False for box in results[0].boxes: x1, y1, x2, y2 box.xyxy[0].tolist() label results[0].names[int(box.cls)] conf float(box.conf) cv2.rectangle(frame, (int(x1), int(y1)), (int(x2), int(y2)), (0, 0, 255), 2) cv2.putText(frame, f{label} {conf:.2f}, (int(x1), int(y1) - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 0, 255), 2) if label electric_bicycle: alarm True if alarm: self.status_label.setText(状态检测到电瓶车) self.saved_count 1 ts time.strftime(%Y%m%d_%H%M%S) cv2.imwrite(str(self.save_dir / falarm_{self.saved_count}_{ts}.jpg), frame) else: self.status_label.setText(状态检测中) rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w, ch rgb.shape qimg QImage(rgb.data, w, h, ch * w, QImage.Format_RGB888) self.image_label.setPixmap(QPixmap.fromImage(qimg)) def closeEvent(self, event): self.cap.release() super().closeEvent(event) if __name__ __main__: app QApplication(sys.argv) win ElevatorApp() win.show() sys.exit(app.exec())这段代码有三个地方值得注意一是self.model(frame, conf0.4, devicecpu)里的device参数。不传它会自动选择设备但在部分机器上 ultralytics 会自动落到 GPU 导致显存不足崩溃。我这里显式指定 CPU保证任何配置都能跑。二是报警保存逻辑。检测到电瓶车就立刻截屏后续你需要根据报警截图挑出误报样本扩充训练集做二次迭代。这里先按下不表第 6 章会讲怎么处理报警风暴。三是cv2.VideoCapture(0)表示本地摄像头。真实项目里多半是 RTSP 网络摄像头直接把0换成rtsp://user:passip:port/stream就行别的逻辑不用动。4.3 报警联动不只是弹个窗报警联动是这个项目能否从「课设作品」进化成「可用系统」的分水岭。至少要做三件事第一报警去重。电瓶车进电梯到出电梯通常持续 10~20 秒如果每帧都触发报警截图会存几十张日志会被刷爆。常见的做法是加一个冷却时间触发报警后 10 秒内不再重复报警。实现方式在update_frame里记录上一次报警时间当前时间与上次间隔小于阈值就跳过。第二报警截图批量保存的目录按日期分子文件夹方便事后检索。这个在安防系统里叫证据留存答辩时也是一个很好的加分点。第三如果有更高追求可以把报警信息通过 HTTP 推送给物业中控台。电梯场景的报警适合做服务端聚合还可以叠加电梯门状态传感器检测到电瓶车且门关闭时才算一次完整事件。但这一步不是标题的必选项属于进阶方向按需加。5. 部署与排查CPU 也能跑但你必须知道的 5 个翻车点5.1 现象一训练时报错找不到标签文件训练启动后立即报错提示某个图片找不到对应的 txt 标签或者dataset is empty。原因通常是数据划分时图片和标签没有一一对应某个子集里出现了只有图片没有标签的样本或者转换脚本输出的目录层级和data.yaml里写的不一致。解决方法是验证目录结构用一行命令检查 labels 目录下所有 txt 是否与 images 目录下所有 jpg 一一对应。我通常先跑yolo detect train前加一段检查脚本for img in $(find images/train -name *.jpg); do base$(basename $img .jpg) if [ ! -f labels/train/$base.txt ]; then echo missing label: $img fi done如果缺失的样本不超过几十张把对应的空 txt 补上也能跑。但更好的做法是检查转换脚本里Path(json_path).stem得到的文件名是不是和图片文件名一致——Labelme 的多边形标注常常导出为xxx_20240101.json而原图叫img_20240101.jpg经过程序处理后可能对不上。5.2 现象二模型对画面边缘的电瓶车漏检严重用训练好的模型跑一段真实电梯视频发现电瓶车在画面边缘时经常检测不到但画面中心能稳定检测。这不是模型坏了是训练数据里边缘样本太少。YOLOv8 的 mosaic 增强会把多张图拼接目标可能出现在任意位置但如果你原始标注数据里边缘分布本来就少增强也救不回来。我一般会做两步第一步把训练集中目标中心点 x 坐标小于 0.15 或大于 0.85 的样本数量统计出来。占比低于 5% 就手动补充标注一批边缘样本。第二步在推理时不对边缘做任何裁剪保持全图输入。如果你为了提帧率而把边缘裁掉那漏检就是你自己的选择。5.3 现象三报警刷屏一秒钟存十几张截图常见原因是报警去重逻辑只加了alarmTrue判断没有加时间阈值。电瓶车从进电梯到出电梯可能持续 20 秒30FPS 下就是 600 帧全部保存等于把磁盘写满。解决办法是在代码里加冷却时间——这是最简单也最有效的。记录上一次报警时间last_alarm_time每次检测到电瓶车时检查当前时间与上次报警时间差小于 10 秒就只更新状态栏不截图不弹窗。5.4 现象四CPU 推理太慢画面明显卡顿电梯报警场景通常用一台普通工控机或旧电脑CPU 推理速度很关键。YOLOv8n 在 Intel i5 上跑 640 输入大约在 100ms 到 200ms也就是 5~10 帧看着会有点卡。有两个优化手段一是把输入尺寸从 640 降到 480速度能提升近一半精度下降不明显电梯场景电瓶车目标足够大二是限制推理频率不必每帧都做检测每 3 帧检测一次中间帧直接显示最近一次检测结果画面和报警延迟都能接受。另外推荐一个最常见的低级失误检查确认model(frame)前 frame 的尺寸没有被人为放大。OpenCV 读出来的 1080p 摄像头画面直接喂给模型ultralytics 会自动按 stride 缩放到 640 附近这是正常的但如果你自己 resize 成了 1920×1080 再做推理模型内部再缩放一次成本就翻倍了。5.5 现象五误把轮椅当电瓶车或者反过来漏掉这是电梯场景最有意思的一个问题。轮椅和电瓶车在俯视视角下都是「一个座位 两个轮子 一个靠背」的组合视觉特征高度相似。解决方向有三条按性价比排序一是检查你的数据集里有多少轮椅样本。如果训练集里没有轮椅模型就不可能学会区分它只能在「像电瓶车」和「不像电瓶车」之间做概率判断。补充 100 张轮椅图片标为 background 或单独一个类误报率立刻下降。二是降低置信度阈值到 0.25~0.3 跑一批测试把所有带 0.3~0.5 置信度的检测框单独抽出来看。你会发现自己模型的「轮椅高置信度误报」长什么样这比盲调阈值有用得多。三是在推理时过滤掉太小或太大的框。电瓶车在 640 输入下宽高比通常在 0.4 到 1.2 之间轮椅更窄更高。加一个基于宽高比的过滤规则能解决大部分边界混淆。6. 让报警更少误报的几个进阶技巧帧级融合与置信度策略如果前面的流程都走通了你现在应该有一个能跑、能报警、能截图的基础系统。但真实场景里电梯门一开一合、光线的突然变化、人推着大纸箱进出都会让单帧检测结果出现抖动。最后这一步我建议引入帧级融合来平滑报警输出。具体做法不复杂不依赖单帧检测结果触发报警而是维护一个长度为 N 的滑动窗口统计最近 N 帧里电瓶车出现的次数占比占比超过阈值才触发报警。比如取 10 帧持续检测到 6 帧以上才确认报警。from collections import deque class AlarmSmoother: def __init__(self, window_size10, threshold0.6): self.window deque(maxlenwindow_size) self.threshold threshold def add(self, detected: bool) - bool: self.window.append(1 if detected else 0) if len(self.window) self.window.maxlen: return False ratio sum(self.window) / len(self.window) return ratio self.threshold这段代码的逻辑很简单window_size10表示最近 10 帧threshold0.6表示至少 6 帧检测到才算真正报警。效果是过滤掉单帧闪烁和偶发误检代价是报警延迟大约增加 300ms。如果用的是每 3 帧检测一次的模式延迟约 1 秒但换来的是可靠性的明显提升。实际使用中我建议window_size取 8~12阈值取 0.5~0.7。太低压不住误报太高会导致电瓶车快速通过时漏报。还有一个细节值得做置信度阈值不要一成不变。电梯场景白天和夜晚的光照差异大同一个模型在夜晚的置信度普遍比白天低 0.1 左右。如果固定 0.4夜晚可能漏报固定 0.3白天误报增多。我一般按时间段切两套阈值比如白天 0.4、夜间 0.3切换逻辑用本地时间判断即可。如果你有精力还可以按电梯门开关状态做联动——门开时延后报警门关后立刻检测这个思路对降低开门瞬间的光照突变误报非常有帮助。最后说一个我自己的血泪经验做毕设项目时我在调帧率、调阈值上花了大量时间总想把每个环节调得尽善尽美。但后来复盘发现真正让这个系统从「能跑」变成「有用」的其实是数据闭环——每次报警截图都定期翻一遍把误报图挑出来补进训练集迭代三轮之后误报率才真正降下来。这也是我建议你务必保留报警截图功能的原因。它不只是一份证据更是你持续优化模型的素材库。目标检测是数据和策略的比赛不是参数调参的玄学。这个方向本身不难把你手上的数据整理好、推理策略打磨稳就能远远领跑那些只做展示的课设作品。希望帮到你。本文还有配套的精品资源点击获取