简介基于YOLOv8的停车场车辆占道违停检测项目是一套面向计算机视觉相关专业学生与毕业设计人员的完整可运行方案。项目内含Python源码、可视化交互界面、完整训练数据集与部署教程支持模型训练和视频检测可自动输出核心指标曲线、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果与标签分布图方便答辩时直观展示算法性能。压缩包共8个文件主要包含3个Python脚本、3个PyTorch模型权重文件预训练权重与训练好的best模型以及2个txt说明文档整体大小约15.91MB目录结构清晰按README操作即可快速部署目前已有62人学习下载。代码均经过测试运行成功拿来即用适合毕业设计、课程设计或项目初期演示也可在此基础上升级实现更多检测功能所有指标图像均基于真实训练过程生成可作为答辩评审中的有力支撑。 如果你正在为毕业设计挑题大概率刷到过《基于YOLOv8的停车场车辆占道违停检测》这类资源包带源码、可视化界面、完整数据集、部署教程一句话“简单部署即可运行”。这对时间紧、还要交代码演示的学生诱惑很大。但这类包到底能不能直接用我拆过不少同类的检测工程先给一个反直觉的结论车辆检测本身早就不新鲜了真正让项目从“能识别车”变成“能判定违停”的是检测框后面的区域规则、停留计时和界面联动。这篇实战笔记就按落地路径讲环境怎么配、数据怎么整理、训练参数怎么设、违停规则怎么接、部署有哪些坑。2. 拆开违停检测黑匣子YOLOv8检测链路与组件选型2.1 YOLOv8为什么适合占道违停从模型结构到前后处理YOLOv8是 Ultralytics 在 2023 年初推的检测框架把模型结构、训练、导出、推理全部收敛到一个 pip 包里。它的 Backbone 用的是 C2f 结构Head 改成 anchor-free 解耦头前处理的 letterbox 和后处理的 NMS 都内建了。对做违停检测的开发者来说最大的红利是你不需要自己维护多尺度预测和 NMS 逻辑可以用yolo detect predict先看效果把精力放在规则判定上。占道违停这类场景目标类别通常很单一——只检测车辆甚至只检测小汽车。选择 YOLOv8 而不是 YOLOv5 或 Faster R-CNN我一般会看重三点第一v8 的训练、验证、导出接口高度统一配好环境后基本一条命令从头跑到尾第二模型体积小yolov8s.pt 大约 22.5MB在纯 CPU 机器上也能跑几到十几帧每秒在 GTX 1660 Ti 这种 6GB 显存的老甜点卡上可以跑满实时性第三后续可以无痛导出 ONNX、OpenVINO、TensorRT甚至 RKNN 方向也有社区适配做部署延伸不会卡在最后一公里。验收环境时我会先跑一段最小推理脚本确保 CUDA、PyTorch、ultralytics 三层兼容再进训练from ultralytics import YOLO model YOLO(yolov8s.pt) # 官方预训练权重 results model.predict( parking.jpg, conf0.4, # 置信度阈值低于 0.4 的框直接丢掉 iou0.5, # NMS 的 IoU 阈值值越大保留的框越多 verboseFalse # 关闭逐图日志 ) for r in results: for box in r.boxes: cls int(box.cls[0]) # 类别 IDCOCO 里 car 是 2 conf float(box.conf[0]) x1, y1, x2, y2 box.xyxy[0].tolist() print(cls, round(conf, 2), [round(v, 1) for v in (x1, y1, x2, y2)])这段代码本身不算复杂但参数有几个容易踩坑conf设太严会把停得偏远的车漏掉设太松又全是误报iou默认 0.5 对稀疏的停车场够用如果摄像头视角是斜着的、车辆相互遮挡严重建议降到 0.4 再观察。另外注意 COCO 预训练的类别 IDcar 是 2bus 是 5truck 是 7。如果你的工程在推理后直接取cls0当作车十有八九是后面自己训的模型而不是用预训练权重直接跑。2.2 从“看到车”到“判定违停”三条规则与数据流设计目标检测只能告诉你“哪里有车”不能回答“这辆车是不是违停”。违停判定需要外部规则。常见的工程做法有三条路线区域越界法预先在画面里画一个禁停区多边形取检测框底边中点用cv2.pointPolygonTest判断该点是否落在禁停区内。实现最简单但无法区分“短暂压线”和“长时间停放”。停留时长法用跟踪 ID 记录每一辆车进入禁停区的时间同一 ID 连续停留超过 N 秒就报警。最贴近违停本意也是这类项目最容易出效果的做法。重叠度法计算检测框与禁停区域的 IoU超过阈值触发。适合判定“车头侵占车位线”这种局部越界但计算 IoU 比点判罚要重一点。实际工程里我会把三者组合先用区域越界法锁定候选车辆再用停留时长法过滤临时借道最后按需要叠加重叠度做精细化提示。一个典型的数据流是这样的视频帧 → YOLOv8 推理得出检测框和跟踪 ID → 对每个框做禁停区判罚 → 有 ID 的车维护“进入时间”字典 → 达到阈值触发报警并截图保存。下面这段代码就是最核心的判定循环import numpy as np import cv2 import time from ultralytics import YOLO model YOLO(best.pt) zone np.array([[120, 540], [760, 540], [760, 720], [120, 720]], dtypenp.int32) cap cv2.VideoCapture(parking_video.mp4) enter_time {} # track_id - 进入禁停区的时刻 ALARM_SECONDS 30 while cap.isOpened(): ret, frame cap.read() if not ret: break results model.track(frame, persistTrue, conf0.35, iou0.5, verboseFalse) now time.time() for box in results[0].boxes: if box.id is None: # 没跟踪到 ID 就跳过 continue tid int(box.id.item()) x1, y1, x2, y2 box.xyxy[0].tolist() cx int((x1 x2) / 2) cy int(y2) # 用底边中点更接近车轮接地位置 if cv2.pointPolygonTest(zone, (cx, cy), False) 0: if tid not in enter_time: enter_time[tid] now if now - enter_time[tid] ALARM_SECONDS: cv2.imwrite(falarm_{tid}_{int(now)}.jpg, frame) print(f[ALARM] track_id{tid} 持续违停) else: enter_time.pop(tid, None)这里两个细节容易被忽略。第一model.track(persistTrue)与model.predict的区别在于跨帧给同一个目标分配稳定 ID没有 ID 就无法计时。不要用 predict 套一个自己写的 IOU 匹配那是在重复造轮子。第二判罚点用(cx, y2)而不是(cx, cy)因为矩形中心可能落在车顶方向而底边中点更贴近车辆实际占位。简短借道压线不会触发 30 秒的阈值这本身就是一个消抖机制。3. 把公开数据集炼成可用的违停权重环境配置、标注转换与训练参数3.1 环境配置conda、CUDA 与 ultralytics 的版本对齐绝大多数毕设工程包自带 requirements.txt但直接pip install -r翻车的概率不低。我先给你一套适合小白的超详细环境配置顺序避免在 torch 和 CUDA 版本上耗一整天conda create -n yolopark python3.10 -y conda activate yolopark pip install torch2.0.1 torchvision0.15.1 --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics8.2.0 opencv-python numpy pandas matplotlib为什么先装 torch 再装 ultralytics因为 ultralytics 依赖 torch如果反过来pip 可能顺手给你装一个 CPU 版 torch之后torch.cuda.is_available()永远返回 False这个坑我见得太多了。装完后立刻验证 GPU 可用性python -c import torch; print(torch.cuda.is_available())输出True才算环境过关。如果你的显卡驱动只支持更新的 CUDA比如 12.x就把cu118换成cu121重新装。GTX 1660 Ti 这种 6GB 显存的老卡用 cu118 配 PyTorch 2.0 是兼容性最好的组合别追新。版本对齐是这类项目最容易被忽视的一环。训练和推理的环境里的ultralytics版本必须完全一致否则别人给的best.pt加载时可能报属性错误。常见做法是固定一个版本号比如ultralytics8.2.0并在 requirements.txt 里写死不要写ultralytics8.0。3.2 数据集目录与标签格式VOC 转 YOLO 的脚本拿到完整数据集后第一件事不是训练而是确认标签格式。YOLOv8 要求每个图片对应一个同名的.txt标签文件格式是类别ID 中心x 中心y 宽度 高度坐标都归一化到 0~1。但很多公开数据集给的是 VOC 的 XML 格式或者视频抽帧后只有 JSON这时候需要转换脚本。假设你手里是一批图片加一批 VOC XML 标注下面的脚本可以把它们统一转成 YOLO 格式import xml.etree.ElementTree as ET import os def voc_to_yolo(xml_path, out_dir, classes): tree ET.parse(xml_path) root tree.getroot() size root.find(size) w int(size.find(width).text) h int(size.find(height).text) lines [] for obj in root.iter(object): cls obj.find(name).text if cls not in classes: continue box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) xc (xmin xmax) / 2 / w yc (ymin ymax) / 2 / h bw (xmax - xmin) / w bh (ymax - ymin) / h lines.append(f{classes.index(cls)} {xc:.6f} {yc:.6f} {bw:.6f} {bh:.6f}) if not lines: return out_path os.path.join(out_dir, os.path.basename(xml_path).replace(.xml, .txt)) with open(out_path, w, encodingutf-8) as f: f.write(\n.join(lines)) classes [car] # 只留小汽车类别ID 0 os.makedirs(labels_train, exist_okTrue) for xml in os.listdir(xmls_train): if xml.endswith(.xml): voc_to_yolo(os.path.join(xmls_train, xml), labels_train, classes)注意三个细节第一坐标必须除以图片宽高忘记归一化是训练时 loss 直接 NaN 的常见原因第二classes列表的顺序决定 ID训练和推理必须保持一致第三跳过没有目标的 XML空标签文件会干扰训练。分类别时如果场景里有大型货车但你的数据里没几张宁可全归到car一类也不要硬凑两个类别导致小类过拟合。转换完标签后按 9:1 划分训练集和验证集目录结构长这样datasets/parking/ images/train/ images/val/ labels/train/ labels/val/3.3 训练参数详解train 的 epochs、batch、imgsz 与正则项取舍训练前先建一个parking.yaml这是 YOLOv8 数据集的入口path: ./datasets/parking train: images/train val: images/val nc: 1 names: [car]path是相对于你执行命令位置的路径建议用项目根目录不要用绝对路径换机器部署时能少改一处配置。然后启动训练yolo detect train \ dataparking.yaml \ modelyolov8s.pt \ epochs100 \ batch8 \ imgsz640 \ patience15 \ device0参数含义逐个拆开说modelyolov8s.pt表示从预训练权重继续训而不是随机初始化迁移学习可以大幅缩短收敛时间epochs100配合patience15会让训练在验证集指标连续 15 轮不提升时早早止损不用死等 100 轮batch8是 6GB 显存下比较安全的值1660 Ti 可以试着batch16若爆显存就降回 8imgsz640是速度和精度之间的平衡点停车场摄像头一般架得高、车小如果发现漏检小目标可以提到 768 看效果。如果你发现训练后期 loss 曲线一直在抖可以考虑加两个参数cos_lrTrue让学习率按余弦退火平滑下降close_mosaic10让最后 10 轮关闭马赛克增强。马赛克增强对停车场这种背景单调、目标相对规则的场景不是必需还容易把停在一起的车拼成怪样本。训练结果会保存在runs/detect/trainN下N是第几次实验记得在训练启动前看一眼目录序号别把第一次的 best.pt 当最终权重。4. 从检测框到违停报警规则工程化、可视化界面与模型导出4.1 违停判定逻辑工程化区域标注、跟踪 ID 与报警截图第 2 章里的判定代码是核心闭环但工程化还要补三件事禁停区标定、报警去重、结果落盘。禁停区不能写死在代码里常见做法是做一个简单的鼠标标定模式用cv2.setMouseCallback在画面上点四个点生成多边形存成zone.npy。这样换摄像头视角时不用改代码只换配置文件。报警去重也很重要。上面的代码每帧检测到超时就会打一次日志一秒钟可能刷 30 条。我会加一个warned_ids集合同一 track_id 只报警一次直到目标完全离开禁停区再重置warned_ids set() if now - enter_time[tid] ALARM_SECONDS: if tid not in warned_ids: warned_ids.add(tid) cv2.imwrite(falarm_{tid}_{int(now)}.jpg, frame) # 已报警的 ID 不再重复输出报警截图建议同时把检测框和禁停区画进图里后面写论文或做展示时截图可以直接进报告。截图文件名带 track_id 和时间戳方便排查同一辆车多次违规的情况。还有一个容易被忽略的点视频流处理要控制帧率。摄像头如果 30 FPS而你的模型在 1660 Ti 上只能跑到 25 FPS画面会越来越卡顿。常见做法是跳帧每两帧取一帧做检测或者限制处理帧率为 10 FPS。对违停检测来说10 FPS 完全够用因为停车本身是个慢动作不用追求满帧。4.2 可视化界面PyQt5 与检测线程分离这类工程包只要写“可视化界面”四个字八成用的是 PyQt5。最简单的界面只有三个元素视频显示区、开始按钮、报警状态栏。但很多人直接把推理循环丢进QMainWindow的槽函数里结果一按按钮窗口就无响应这是血泪经验。正确做法是把检测循环放进QThread通过信号把图像帧传给主界面from PyQt5.QtCore import QThread, pyqtSignal from PyQt5.QtGui import QImage import cv2 class VideoThread(QThread): change_frame pyqtSignal(QImage) alarm_message pyqtSignal(str) def __init__(self): super().__init__() self.running False def run(self): cap cv2.VideoCapture(0) self.running True while self.running: ret, frame cap.read() if not ret: continue results self.model.predict(frame, conf0.4) annotated results[0].plot() rgb cv2.cvtColor(annotated, cv2.COLOR_BGR2RGB) h, w, ch rgb.shape qimg QImage(rgb.data, w, h, ch * w, QImage.Format_RGB888) self.change_frame.emit(qimg)为什么必须分线程YOLO 推理是同步阻塞的几帧下来 UI 线程的QTimer就被饿死了窗口自然转圈圈。推理线程只负责算显示交给 Qt 主线程去 draw这样界面再卡也只是掉帧不会假死。开始/停止按钮通过置位self.running来控制线程生命周期不要用terminate()那是最后一种后悔药副作用很大。4.3 速度优化与模型导出ONNX、OpenVINO 与 RKNN 方向训练调参不是终点。毕设答辩时常常要在别人的机器上跑演示那台机器很可能没有 NVIDIA 显卡这时候导出成 CPU 友好格式是救命方案。YOLOv8 导出 ONNX 只需要一条命令yolo export modelruns/detect/train5/weights/best.pt formatonnx opset12 simplifyTrue导出后可以用 ONNX Runtime 或 OpenVINO 跑推理。OpenVINO 在 Intel CPU 上比纯 PyTorch 快一截很多笔记本演示场景够了。如果你的目标是 RK3588 这类 NPU 板子官方路径是先把 .pt 导出为 ONNX再在 PC 上通过 rknn-toolkit2 转成 RKNN 模型最后在板端用 RKNN API 加载。注意一个容易踩的坑RKNN 转换前的 ONNX 不要固定 batch导出时用动态 batch否则板端逐帧推理会报 shape 不匹配。模型导出和部署方向我的建议是先保证 PyTorch 版本的检测结果和 ONNX 版本一致再谈速度优化。常见翻车是导出的模型精度明显下降这时候排查两个位置——opset是不是太低导致算子被替换以及输入尺寸是否与训练时不一致。还有一个隐藏点不要导出后直接拿去板端跑 INT8 量化你必须先在目标板上用真实场景图片做校准否则精度可能砍半。5. 部署避坑指南环境、路径、显存与界面卡死的 5 个排查点5.1 加载 best.pt 就报错AttributeError 与版本不一致现象把工程包里的best.pt放进自己环境执行YOLO(best.pt)时报AttributeError: DetectionModel object has no attribute x之类的错误。原因这个权重是用某个特定版本的 ultralytics 训练并保存的不同版本之间模型类的属性可能在重构中改名或删除。很多工程包作者训练时用的是 8.0 或 8.1而你装的是 8.2 之后的版本加载时就会碰到旧模型里没有的结构。解决按工程包附带的 requirements.txt 原样安装严格锁版本。如果对方没给先看best.pt文件里有没有记录训练参数再用pip index versions ultralytics找几个大版本逐个试。最稳妥的做法是让别人把整个 conda 环境的pip freeze发一份而不是只看 requirements.txt 的第一行。5.2 GTX 1660 Ti 训练爆显存CUDA out of memory现象训练启动后没跑几个 iter报CUDA out of memory在 6GB 显存的 1660 Ti 上特别常见。原因默认参数可能是 batch16 配合 yolov8m这在小显存上是不现实的。训练、验证、混合精度计算都会占显存不是只有 batch 一项。解决把 model 换成yolov8s.pt或yolov8n.ptbatch降到 4 或 8imgsz保持 640。如果还想再挤一点可以在训练命令里加cacheFalse并把数据加载的 worker 数降低。另一个容易被忽视的点是训练时不要同时开着其他吃显存的应用比如 PyCharm 的代码索引不会但浏览器多标签页可能会吃掉不少显存。把batch8配ampTrue默认开是 6GB 卡上最稳的组合。5.3 点击“开始检测”后界面假死线程阻塞现象程序能启动但一点开始按钮窗口立刻无响应鼠标转圈圈过几秒甚至崩溃。原因推理代码写在了按钮的点击事件里YOLO 推理是同步阻塞的主线程被占死Qt 无法处理重绘和鼠标事件。你自己的代码里没有 QThread 或 multiprocessing 隔离。解决按 4.2 的框架把推理循环移到 QThread通过信号回传画面。如果项目本身用了 Tkinter可以用after轮询队列但 QThread 方案更稳。记住一个判断标准任何推理循环都不要写在 UI 事件回调和main函数体里除非你愿意承受假死。5.4 界面中文显示乱码编码与字体现象可视化界面的“违停报警”变成了“杩滃仠”之类的一堆乱码或者控制台日志里的中文乱成一片。原因Windows 控制台默认编码是 GBK而 Python 脚本按 UTF-8 输出中文PyQt 的默认字体也可能不支持某些中文字符。很多毕设工程包是在 Linux 上写好的换到 Windows 就露馅。解决在脚本最顶部加一行sys.stdout.reconfigure(encodingutf-8, errorsreplace)让输出强制走 UTF-8。界面字体不要用默认的SimSun换Microsoft YaHei微软雅黑大部分 Windows 机器都有。如果你在打包成 exe 后仍然乱码检查打包工具的编码参数PyInstaller 需要在 spec 文件里设置codeset_encodingutf-8。5.5 摄像头无法打开OpenCV 后端与 DLL 缺失现象cv2.VideoCapture(0)一直返回False但系统自带相机 App 能正常显示画面。笔记本用户和打包后用户最容易遇到。原因Windows 下 OpenCV 默认使用 MSMF 后端某些摄像头驱动和 MSMF 的兼容性堪忧。另外打包后的 exe 缺少 OpenCV 的视频捕获 DLL也会导致无法打开摄像头。解决将代码改成显式指定后端cv2.VideoCapture(0, cv2.CAP_DSHOW)Windows DirectShow。Linux 上则用cv2.CAP_V4L2。打包时用 PyInstaller 的--collect-binaries cv2参数把 OpenCV 的 DLL 全部收集进来不要手动拷容易漏。视频文件能打开但摄像头打不开往往是后端问题优先排查这一条。6. 进阶把单帧检测升级成可解释、可部署的工程训练完一看runs/detect/train5/目录里面除了权重还有results.csv这是训练过程中自动落盘的指标记录。毕业论文里那两张“损失函数曲线图”就在这里面但会发现 loss 在后半段波动很厉害——这是 GPU 上用了混合精度配合大 batch 的正常现象不是模型没收敛。画图的代码很简单import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/detect/train5/results.csv) for col in [train/box_loss, val/box_loss]: plt.plot(df[col], labelcol) plt.xlabel(epoch) plt.ylabel(loss) plt.legend() plt.savefig(loss_curve.png, dpi200)加上close_mosaic10之后曲线尾部会有一个明显的断崖和回落这是正常的因为最后 10 轮去掉了马赛克增强loss 会在原始分布上重新收敛不是代码 bug。写报告时别把这一段当作训练失败。想再做深一层可以加 GradCAM 类的热力图验证模型关注区域看看它锁定的到底是车身还是背景。这个问题看似小实际是答辩现场高频问题——“你怎么证明模型学的是车而不是地面阴影”我的习惯是训练完至少挑三张照片做可视化一张正常车位、一张斜停、一张逆光。如果热力图高亮区域飘到护栏或树叶上说明数据里有系统性偏置回去补样本比调参更重要。最后说一个 RK3588 板端部署的方向把 yolov8s 转到 RKNN 后在板端用 RKNN Runtime 推理整个检测耗时大约能从 PC 上的几十毫秒优化到个位数毫秒级别但代价是 INT8 量化后掉点。我的经验是先跑 FP16 确认流程跑通再用训练集里挑出的几百张代表性帧做量化校准不要直接把全部训练集灌进去容易让量化统计被大量低质量样本拉偏。还有一点板端的摄像头输入往往是 MIPI 接口驱动层拿到的帧是 YUV不能直接喂给 RKNN要先做 NV12 转 RGB。我自己交过不少学费最值钱的教训是拿到这类工程包先花十分钟把环境、权重版本、数据路径三件事锁死再谈换模型、优化界面的雄心。界面假死那次我调了一晚上模型参数第二天发现只是线程问题。希望帮到你。本文还有配套的精品资源点击获取