基于YOLOv8的停车场车位识别系统构建与部署指南

简介基于YOLOv8的停车场车位识别系统是一份面向目标检测实践与毕设答辩的完整项目方案适合计算机视觉、人工智能方向的学生或从业者用于课程设计、毕业设计及项目立项演示。资源集成可视化界面、模型训练与视频检测三大核心模块运行后可产出核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果及标签分布图覆盖答辩所需的关键展示材料。压缩包共8个文件总大小15.91MB包含3个Python脚本、3个pt模型权重及2个说明文档其中训练脚本用于模型调优、检测脚本支持视频实时推理、可视化脚本提供图形化操作入口权重文件则涵盖训练结果与常用预训练模型。代码均经过运行测试后上传不同基础的学习者均可按README说明逐步部署也可在现有框架上二次开发扩展更多车位或目标检测应用场景。已有51人学习下载属于功能完善、拿来即用的实操型资源。1. 停车场车位识别为什么毕设选 YOLOv8 而不是 OpenCV 传统方案每年这个季节总有人拿着「停车场车位识别」这个题目来找我。多数人一开口就是 OpenCV 阈值分割、背景差分、霍夫直线检测那一套——代码写起来确实爽两三百行就能出效果但拿去跑真实停车场视频就翻车地库灯光一换、地面反光一变、树影一晃检测框就满天飞。这不是你的算法不行是传统视觉方案本身不适合露天和地库这种光照剧烈变化的场景。YOLOv8 这类深度学习检测模型正好踩在这个痛点上它把「找到车」这件事变成端到端的目标检测问题模型尺度、光照鲁棒性、小目标召回都比传统方案高一个量级而且推理速度快普通办公电脑上没 GPU 也能跑。这篇笔记就按我实际交付这类毕设和课设项目的顺序来写从模型选型逻辑、数据集组织、训练参数、可视化界面到部署排错一步不跳。你拿到的标题里说是「简单部署即可运行」这是结果不是前提——你得先搞清楚模型怎么来、界面怎么接、坑在哪里才谈得上部署后不掉链子。下面每一章都能直接抄作业参数我给到能用的基准值踩坑记录也是真实调式过程中沉淀下来的。2. 选型逻辑YOLOv8 检测思路在车位识别里怎么落地2.1 为什么是「先检测车再判车位」而不是直接检测「空车位」第一次做这个题目的人直觉往往是训练一个模型去检测「空车位」和「占用车位」。出发点没错但落地时会撞上一个数据难题空车位的正样本严重不足。一个停车场里绝大多数时候车位都是满的露天停车场的光影变化还会让空车位的视觉特征车位线颜色、地面纹理变得非常不稳定。反过来看「车」这个目标类别在公开数据集里量级非常充足——COCO 有大量 car 类别样本BDD100K、CCPD 这些车辆数据集也可以做补充训练数据。所以常见的可靠做法是用 YOLOv8 做车辆检测把每辆车的检测框中心点映射到预先标定好的车位多边形Polygon里再用 IoU 或在多边形内点数判断该车位被占用还是空闲。车位线是「先验知识」不需要让模型去学模型只负责回答「哪里有车」这样系统的稳定性、可解释性都更好部署时的算力需求也更低——一个轻量级检测模型就够了。「先检测到底有没有车再和固定车位做匹配」这套思路本质上把「车位识别」拆成了「车辆目标检测」和「车位状态判定」两个子问题。检测部分交给 YOLOv8 这个黑匣子判定部分则用几十行几何计算解决不用重新发明轮子。这个拆分还带来一个额外好处车位划定的位置变了不需要重新训练模型只需要改配置文件里的车位坐标。2.2 损失函数与模型尺度为什么建议优先上 YOLOv8s 而不是 n 或 mYOLOv8 按深度和宽度分成 n / s / m / l / x 五个尺度。毕设题目里很多人默认用 yolov8n因为它最轻、训练最快但 n 模型的参数只有 3.2M在车辆这种目标大、特征明显但场景遮挡多的任务上检测框的稳定性会差一些尤其是车辆遮挡时召回率下降明显。我的建议是训练阶段用 yolov8s参数约 11.2M精度比 n 高出一截而速度衰减可以接受如果你打算把系统部署到 RK3588 这类边缘设备上相关热词里也有人搜「yolov8 部署到 rk3588」那推理端再导出成 ONNX/INT8 量化模型效果比一开始就训练 n 更稳。用 s 做训练、导出时再做量化压缩这是「精度」和「部署速度」之间最省事的平衡点。2.3 车位判定的两种主流方案中心点越界法与 IoU 阈值法拿到车辆检测框之后怎么判断这个车位是否被占用两个方案都有人用我分别说下适用场景。中心点越界法取检测框底边中心点判断该点是否落在车位多边形内。这个方法实现极简一个 point-in-polygon 算法就能完成对「车头朝里、车尾朝里」都鲁棒。缺点是对大型车SUV、货车不太友好如果车跨了两个车位中心点落在哪个车位里就判定哪个车位占用另一个车位实际也被占了但漏报。IoU 阈值法计算车辆检测框和车位多边形可以简单视为一个矩形的交并比设定一个阈值如 0.3超过就判占用。这个方案能处理大车跨两个车位的情况但问题在于阈值对尺度的敏感——车位在图像中的大小不同同样的遮挡比例对应的 IoU 值差异很大。实际工程里我一般用「车位多边形内车辆像素占比」预先给每个车位在图像中标一个 ROI 区域统计区域内检测到车辆的面积占 ROI 面积的比例超过 0.15 即占用。这个值和相机安装高度、车位大小直接相关需要在现场标定一次但一旦调好稳定性远超单点判断。3. 从数据到权重训练一个「够用」的车辆检测模型的完整路径3.1 数据集组织公开数据打底自采数据微调YOLOv8 想要「简单部署即可运行」前提是训练数据质量过关。车辆检测不像车位检测公开资源非常充足常见组合是 COCO 的 car 类别约 6 万张含车图像 BDD100K 的 car 类10 万帧驾驶视频抽帧。不过要注意COCO 和 BDD100K 的车大多是行车视角和停车场俯拍/斜俯拍的视角差异不小直接训练出来的模型在停车场场景容易漏检车头正对镜头的车辆。我一般会在停车场用手机或行车记录仪补采 500 到 1000 张照片用 LabelImg 或 X-AnyLabeling 标注成 YOLO 格式放进去做微调。效果提升非常明显尤其是地库低照度场景「数据不够模型来凑」这句话在停车场场景下是反的。3.2 写一个把公开数据集转成 YOLO 格式的脚本这是做数据准备时一定会遇到的硬骨头——COCO 的标注是 JSON 格式BDD100K 也是 JSON而 YOLOv8 训练要的是每个图像对应一个 txt每行是 class_id, x_center, y_center, width, height归一化坐标。转换脚本网上版本很多但「能跑」和「跑完没坑」是两回事。我一般会写一个精简版核心逻辑如下import json import os from pathlib import Path from PIL import Image def coco_to_yolo(json_path, img_dir, output_dir): with open(json_path, r, encodingutf-8) as f: coco json.load(f) # 先建立 id - 文件名 的索引 id_to_file {img[id]: img[file_name] for img in coco[images]} # 过滤只保留 car 类COCO 中 car 的 id 是 3 car_cat_ids {cat[id] for cat in coco[categories] if cat[name] car} anns [ann for ann in coco[annotations] if ann[category_id] in car_cat_ids] os.makedirs(output_dir, exist_okTrue) for ann in anns: img_file id_to_file[ann[image_id]] img_path os.path.join(img_dir, img_file) if not os.path.exists(img_path): continue with Image.open(img_path) as im: w, h im.size x, y, box_w, box_h ann[bbox] # COCO 的 bbox 是 x, y, width, height # YOLO 需要中心点归一化注意宽高要除以原图尺寸 cx (x box_w / 2) / w cy (y box_h / 2) / h bw box_w / w bh box_h / h txt_name Path(img_file).stem .txt with open(os.path.join(output_dir, txt_name), a) as f: f.write(f0 {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}\n)这段脚本里有几个参数要说明COCO 的 bbox 是左上角坐标加宽高YOLO 需要的是中心点坐标加宽高必须归一化到 0 到 1类别 id 在 COCO 和 BDD100K 中各不相同比如 COCO 的 car 是 3BDD100K 的 car 是 0转换前务必查一次类别映射表否则训练完模型输出的类别和你预期对不上。另外输出 txt 的路径要和图像的相对路径保持一致YOLOv8 是按「图像路径找同名 txt」的机制读取标注的多级目录也不会自动递归查找。转换完以后最好随机挑几张图画框回验一遍——绝大多数数据集转换翻车都发生在这一步比如归一化除以了错误的宽高导致框的位置完全错位模型却照样训练最后 mAP 一塌糊涂不知道问题出在哪。3.3 训练参数一次性给到位的一套基准配置YOLOv8 官方的训练命令看起来简单但参数的「手感」需要多次调实验出来。我直接给一套在车位识别场景下验证过的基准配置yolo train taskdetect \ modelyolov8s.pt \ dataparking.yaml \ epochs150 \ imgsz640 \ batch16 \ lr00.01 \ lrf0.01 \ optimizerSGD \ mosaic0.5 \ close_mosaic10 \ patience20 \ device0逐项说下参数用意epochs 给到 150 不是让你一定能训练完而是配合patience20做早停——验证集 mAP 连续 20 个 epoch 不提升就自动停省时间也防过拟合。mosaic0.5是马赛克增强的概率这个值不要设成 1.0停车场场景里马赛克增强容易把车切成碎块模型学到离谱的纹理特征close_mosaic10表示最后 10 个 epoch 关闭马赛克让模型在正常分布上收敛官方默认就有这个参数但很多人不知道它是干这个的。lr0用 0.01 是基于 SGD 的经验值如果你换 AdamWlr0 要降到 0.001 左右否则前 10 个 epoch loss 会震荡得很厉害。device0指定第一张 GPU没有显卡就留空让它跑 CPU但训练时间会长十倍以上——如果只是毕设演示用也可以跳过训练直接用我后面介绍的方式在预训练权重上做小样本微调。3.4 loss 曲线怎么看不画损失函数曲线等于盲调很多人训练完只看最终的 mAP过程曲线一眼不看这是不对的。YOLOv8 训练时会在runs/detect/train*/目录下生成results.csv里面有每个 epoch 的 box_loss、cls_loss、dfl_loss 和验证集指标。我习惯用一条 Python 命令快速画出来import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/detect/train2/results.csv) plt.figure(figsize(10, 4)) plt.subplot(1, 2, 1) plt.plot(df[epoch], df[train/box_loss], labeltrain_box_loss) plt.plot(df[epoch], df[val/box_loss], labelval_box_loss) plt.xlabel(epoch) plt.ylabel(box_loss) plt.legend() plt.subplot(1, 2, 2) plt.plot(df[epoch], df[metrics/mAP50(B)], labelmAP50) plt.xlabel(epoch) plt.ylabel(mAP50) plt.legend() plt.tight_layout() plt.savefig(loss_curve.png, dpi200)判断标准就三条。第一train 和 val 的 box_loss 都在持续下降且曲线末端趋于平缓——说明模型还在学习epochs 可能不够第二train 持续下降但 val 开始反弹这是过拟合信号Early Stopping 会自己停但你要知道这个语义第三mAP50 曲线如果出现「锯齿状剧烈抖动」通常是 batch size 太小或学习率偏高不是数据的问题先把 lr0 降一半重训。记住曲线是黑匣子的仪表盘看不懂仪表盘就改参数等于盲人开车。4. 可视化界面用 PyQt5 把检测模型包成一个操作简单的桌面工具4.1 界面选型PyQt5 还是 Streamlit所谓的「可视化界面」在毕设答辩场景里承载的任务是展示系统能力不是做一个商业产品。两种主流路线PyQt5 桌面程序或者 Streamlit / Gradio 网页界面。如果目标是「打开就能用、操作要简单」我推荐 PyQt5。理由很现实答辩现场的电脑环境不可控网页界面要起服务、开端口、处理浏览器兼容而 PyQt5 打包成单个 exe电脑上有显卡没显卡都能跑双击就出窗口。Streamlit 的优势是代码量少几十行就能做出一个像样的面板适合快速验证但它的刷新机制导致视频推理流的实时性很差——每次推理结果要 push 到前端组件帧率上不去。4.2 一个能直接跑的最小界面骨架下面这段代码是我给学员做界面时的最小可用版本。它的结构是左侧显示实时画面右侧显示每个车位占用状态底部显示当前空闲车位总数。import sys from PyQt5.QtWidgets import QApplication, QMainWindow, QLabel, QVBoxLayout, QWidget from PyQt5.QtGui import QImage, QPixmap from PyQt5.QtCore import QTimer import cv2 from ultralytics import YOLO class ParkingGUI(QMainWindow): def __init__(self, model_path, video_source): super().__init__() self.model YOLO(model_path) self.cap cv2.VideoCapture(video_source) self.setWindowTitle(停车场车位识别系统) self.image_label QLabel() self.setCentralWidget(self.image_label) self.timer QTimer() self.timer.timeout.connect(self.update_frame) self.timer.start(30) # 每 30 毫秒取一帧约 33 FPS def update_frame(self): ret, frame self.cap.read() if not ret: self.cap.set(cv2.CAP_PROP_POS_FRAMES, 0) # 视频循环播放 return results self.model.predict(frame, conf0.35, verboseFalse) annotated results[0].plot() # ultralytics 自带的画框方法 # OpenCV BGR - Qt RGB rgb cv2.cvtColor(annotated, 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).scaled(960, 540)) if __name__ __main__: app QApplication(sys.argv) gui ParkingGUI(best.pt, parking_lot.mp4) gui.show() sys.exit(app.exec_())这段代码把核心交互全藏着self.model.predict()返回的 results 对象带.plot()方法直接在原图上画检测框和标签不用手动调 cv2.rectangleconf0.35是置信度阈值根据你的场景可以往下探到 0.25但再低就会把阴影、车灯反光也当成车QTimer 的 30 毫秒间隔决定了 UI 刷新率去掉这一层改成 while 循环读视频窗口会卡死因为主线程被阻塞了。界面要显示每个车位的状态就在update_frame里调用上一章写的车位判定函数把结果画在车位中心点旁边这部分属于业务逻辑可以拆到独立模块里界面只负责渲染。4.3 静态图和视频的输入切换界面里的三种数据源毕设演示时通常要面对三种输入单张图片、离线视频、摄像头实时流。三种数据源在代码层面的差别其实只有一个——读帧的方式。图片是一次性推理视频是循环读帧摄像头是 OpenCV 的 VideoCapture(0) 但要注意索引号可能因为 USB 摄像头占用而改变。我建议界面上做成下拉选择框一次性把三种模式都做好答辩时切换展示这比重新跑三个 demo 程序要专业得多。摄像头模式下记得加一个 FPS 显示标签现场演示如果掉帧到 10 FPS 以下能直接看到数字方便解释推理速度和算力的关系。5. 简单部署的真相目录组织、环境配置与运行排错避坑5.1 工程目录应该长什么样「简单部署即可运行」的工程包目录结构是决定用户能不能跑起来的第一关。我见过太多毕设代码数据集散落五六个盘符模型权重用网盘链接分发运行脚本里写死绝对路径——别人拿到手第一步就卡住。一个合格的工程包至少是这种结构parking_system/ ├── weights/ │ └── best.pt # 训练好的模型权重 ├── data/ │ └── test_video.mp4 # 演示视频 ├── utils/ │ ├── detector.py # 封装 YOLO 检测逻辑 │ └── parking_judge.py # 车位判定逻辑 ├── ui/ │ └── main_window.py # PyQt5 界面 ├── requirements.txt └── run.py # 一键启动入口注意 requirements.txt 要锁版本号ultralytics8.0.0,9.0.0这种写作方式比直接写ultralytics好得多—— YOLOv8 在迭代过程中 API 有变化版本跨太大代码里调用的参数名对不上就白跑。我一般还会在根目录放一个README.md把 Python 版本3.9 或 3.10、CUDA 版本、安装命令写清楚。这不是为了好看是给自己省售后时间。5.2 环境配置的最小命令序列一个干净的环境从零到能跑推理应该只有三条命令的事conda create -n parking python3.10 -y conda activate parking pip install ultralytics opencv-python-headless PyQt5没有 GPU 的机器不要装torch的 CUDA 版本PyPI 默认安装的 torch 在 Windows 上会自带 CUDA 依赖包体积大且安装容易因为网络问题失败。CPU 推理就装纯 CPU 版先装好依赖再pip install torch --index-url https://download.pytorch.org/whl/cpu。很多人在这上面翻车——装了一整个 CUDA 工具包跑起来发现没有 N 卡驱动又卸载重装纯浪费时间。5.3 避坑/常见问题部署运行时的 4 个高频踩坑记录踩坑 1模型路径或权重文件名不对界面一闪而过直接崩现象运行 run.py 后窗口弹了一下就没了控制台报FileNotFoundError: best.pt。原因绝大多数是路径写错——代码里用的是绝对路径别人复制到新目录后路径失效或者在 PyCharm 里直接运行工作目录和工程根目录不一致。解决所有路径不要用绝对路径必须基于Path(__file__).parent拼接入口文件里用sys.path.insert(0, os.path.dirname(os.path.abspath(__file__)))把工程根目录塞进模块搜索路径。踩坑 2opencv-python 和 opencv-python-headless 冲突现象装完 requirements 后import cv2 报一堆libGL.so.1之类的错linux 服务器上最常见。原因系统里同时装了 opencv-python 和 opencv-python-headless两个包都带 cv2pip 处理依赖时把库文件覆盖了。解决先pip uninstall opencv-python opencv-python-headless再只装一个——界面程序装 opencv-python纯后端推理装 headless 版本。踩坑 3PyQt5 界面显示但视频不刷新CPU 占用却 100%现象启动后窗口白屏或每点一下才刷新一帧。原因把model.predict()直接放在 QTimer 的槽函数里而预测耗时长过定时器间隔Qt 事件循环被阻塞。解决推理放到 QThread 工作线程界面线程只负责接收结果信号实在图省事把 QTimer 间隔调大到 100 毫秒以上并降低推理分辨率比如imgsz640改成imgsz480也能缓解但治标不治本。踩坑 4onnx 导出后检测框偏移现象model.export(formatonnx)导出成功但用 onnxruntime 推理时框的位置和置信度与 PyTorch 结果明显不一致。原因YOLOv8 的 export 默认保留了模型的预处理归一化但你的推理代码自己又做了一次 /255 归一化数据被双重处理。解决用 Ultralytics 官方提供的推理接口model.predict(source..., imgsz640)不要手工前处理如果一定要用 onnxruntime 手写推理参考官方仓库里的yolov8_onnx.py示例照着它的预处理步骤来不要自己发明。5.4 没有 GPU 的演示机器CPU 推理的提速三板斧毕设答辩的机器往往是教室的旧电脑没有独立显卡是常态。CPU 推理要让帧率不至于太难堪有三板斧第一imgsz从 640 降到 480检测精度下降有限速度提升接近一倍第二conf阈值从 0.35 提到 0.45减少后处理阶段需要画的框数量CPU 上画框也要算时间的第三如果视频源是本地文件直接把视频帧丢帧处理每两帧推理一次连续帧之间用上一次的结果补上。这三板斧上完主流 i5 处理器能将推理帧率从 8 FPS 拉到 15 FPS 左右演示完全够用。6. 进阶把玩从离线检测到实时流再给系统加一只「后悔药」走到这一步你手里已经有一个能跑通全套流程的系统了。但如果只想停留在「毕设答辩」的及格线下面这段可看可不看——如果你想把这个系统延伸成真正的工程级方案或者导师追问「你的系统在真实场景下会不会误报漏报」这几个点是加分的重头戏。第一个进阶方向是实时视频流里的「状态平滑」。单帧检测结果是不稳定的可能出现第 10 帧判定车位占用第 11 帧又变成空闲第 12 帧又占用——这是模型的置信度在阈值边缘抖动。解决思路是给每个车位加一个状态机连续 N 帧判定为占用才更新状态连续 N 帧判定为空闲才释放状态N 取 3 到 5 比较合理。YOLOv8 本身不提供这个能力要用代码实现在业务逻辑层。我之前见过有人直接用缓存帧的推理结果取平均值但车位状态不是流量计数均值会把瞬时遮挡造成的变化也平均进去状态机才是最稳的这也解释了为什么成熟的车位诱导系统在相机视角下依然能做到 99% 以上的准确率——不是模型强而是逻辑层做了滤波。第二个方向是「坏样例回放」。训练模型、部署完系统只是开始。我会在工程里加一个自动保存「低置信度检测结果」的开关当检测框的置信度落在 0.3 到 0.5 之间时把这张图和检测结果存到一个debug/目录。运行一天后翻这个目录比跑一万行评估代码更能告诉你系统在真实场景里看到了什么。这比在模型层面反复调参要高效得多因为所有没检出来的、误检的车位实际上都暴露在低置信度的样本里。迭代三次坏样例后系统基本能达到稳定的可用状态。最后一件事回到标题那句话——「简单部署即可运行」。很多学员拿到工程第一反应是跑跑通了就交付但我会养一个习惯交付前把自己当成一个第一次打开项目的人从新建环境开始用 README 里的命令逐条重新部署一遍记录每一条翻车的地方回到源码里把它修掉。这个习惯帮我在毕设季减少了大量「学长我这边跑不起来」的售后问题。这个方向值不值得做如果你想要的是一门课设高分或者一个能写进简历的完整项目它值得如果你想一步到位做成商业级产品那就把目光从二维图像转向「地磁 摄像头多传感器融合」——那个方向是另一个深水区了。希望本篇的实操路径帮你把当前这套系统稳稳落地参数给到的就先用跑通后再按需求微调剩下的交给现场数据去说话。本文还有配套的精品资源点击获取