简介：基于YOLOv8与PyQt5构建的共享自行车识别检测系统，面向计算机相关专业学生与算法开发人员，适合课程设计、毕业设计及各类竞赛场景，可对画面中的共享自行车进行识别与计数，并能扩展为违规停放检测告警模块。资源共889个文件，包含304张jpg图像样本、247个txt标注信息、87个py源码文件及47个yaml配置，另有pt模型权重、UI界面文件、部署脚本等，整体压缩包约466.56MB，结构划分清晰，便于按模块查阅与二次开发。目前已有1849人浏览学习，包内提供完整自行车数据集、训练好的YOLOv8模型及评估曲线，GUI界面可直接运行，并附详细部署说明，模型准确率达到98%。代码均经过测试，可在现有基础上扩展违规停放告警、多目标计数等功能，适合快速搭建演示项目或作为进阶学习素材。
1. 共享自行车违停检测系统的资源构成：YOLOv8权重、标注数据集与PyQt5界面
小区门口、景区出入口、地铁站周边，共享单车乱停永远是被投诉最多的场景。想用视觉方案解决，最直接的路径是：训练一个能认出自行车的目标检测模型，再在监控画面里圈出禁停区域，只要有车停留超过N秒就触发告警。这套资源恰好把这整条链路打包齐了——训练好的YOLOv8权重、整理过的共享单车数据集、以及一个基于PyQt5的桌面检测界面。也就是说，你不用从零写检测代码，也不用花几周自己采集图像，环境配好就能跑出识别框和告警弹窗。它适合做毕设、智慧园区演示、物业安保系统原型验证。标题里说的“违规停放检测告警”并不是空概念，而是靠ROI区域与计时判定逻辑落地的实际功能。接下来的章节，我会按“检测原理→训练参数→GUI对接→常见坑”的顺序把这个项目拆开讲。
2. YOLOv8检测链路与数据集结构：先把检测端理解清楚
这个系统能跑通，核心是三个部件：YOLOv8模型权重负责把画面里的自行车框出来，数据集负责让模型认得“共享单车”，PyQt5界面负责把推理结果变成人眼可看的监控画面。先讲检测端，因为它决定了违停告警的准确性上限。
2.1 模块组成与数据流向
从文件组织看，解压后大致包含以下模块：
| 模块 | 内容 | 作用 |
|---|---|---|
| 权重文件 | .pt格式YOLOv8权重 | 输入图像，输出检测框 |
| 数据集 | images目录 + labels目录 | 训练与验证时使用 |
| 界面程序 | PyQt5脚本 | 加载权重、调用模型、显示画面 |
| 配置文件 | dataset.yaml 与参数脚本 | 指定数据路径与界面选项 |
数据流很明确：摄像头或视频文件的每一帧图像被送到YOLOv8模型里做一次前向推理，得到若干候选框，每个框包含类别、置信度、坐标；随后界面程序过滤掉低置信度的框，再判断框的中心点或下边沿是否落在禁停区域内；如果连续若干帧都满足条件，就触发告警。这条链路里，推理耗时集中在模型前向，判定逻辑几乎不消耗时间，所以帧率瓶颈主要看显卡型号与输入分辨率。
选YOLOv8而不是SSD、Faster R-CNN，最直接的理由是它在同档精度下速度更快，且Ultralytics的工程封装把数据加载、数据增强、评估都做完了，对中小项目来说成本最低。对违停场景，共享单车通常是近距离静止目标，尺寸不小，YOLOv8n或YOLOv8s级别就能有不错效果。
2.2 数据集构成：YOLO格式标签与LabelMe转换
这份资源里附带的数据集是整理好的，已经转成YOLO格式。它和COCO那种json标注不同，每张图片对应一个同名txt文件。txt每一行代表一个目标，五个数值依次是：类别id、归一化中心x、归一化中心y、归一化宽度、归一化高度。
比如一个单车目标在1920x1080图像里中心点位于(960, 600)，宽高为(180, 240)，对应标签如下：
0 0.500 0.556 0.094 0.222这里的类别id从0开始编号，如果项目里只有一类“共享单车”，那所有目标行开头都是0。归一化含义是把像素坐标除以图像宽高，让训练时不管输入分辨率如何都能对齐。这种格式最大的好处是训练代码不需要关心绝对像素值，读取速度也快。
如果你手里的素材是LabelMe标注的JSON文件，需要先做转换。常见做法是遍历JSON里的shapes字段，读出多边形所有顶点，算出最小外接矩形，再把矩形坐标归一化后写入txt：
import json def labelme_to_yolo(json_path, out_path, img_w=1920, img_h=1080, class_map={"bike": 0}): with open(json_path, "r", encoding="utf-8") as f: data = json.load(f) lines = [] for shape in data["shapes"]: label = shape["label"] if label not in class_map: 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) cx = ((x_min + x_max) / 2) / img_w cy = ((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]} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}") with open(out_path, "w") as f: f.write("\n".join(lines)) labelme_to_yolo("bike_001.json", "bike_001.txt")这段代码要注意三个点：img_w与img_h必须使用图片真实分辨率，不是标注窗口显示尺寸，否则归一化坐标会整体偏移；LabelMe的points可能是任意数量顶点的多边形，用min和max提取外接矩形即可覆盖常见标注方式；类别映射表class_map决定了最终训练的类别编号，要保持全局一致，不能这个文件里bike是0、那个文件里bike是1。
数据集目录一般按train/val划分组织，YOLO默认读取结构如下：
dataset/ images/ train/ bike_001.jpg val/ bike_010.jpg labels/ train/ bike_001.txt val/ bike_010.txttrain与val的比例按样本量决定。样本只有几百张时留10%到20%做验证集比较合理，样本上万张时5%就够。目录名最好严格用train和val，避免在YAML里额外映射时拼错路径。
2.3 推理链路：置信度过滤与NMS参数
模型加载后，推理端要做的工作不是简单把tensor结果画到图上。YOLOv8的输出是一个形状类似[1, 84, 8400]的张量（具体维度取决于类别数），可以理解为8400个候选预测，每个预测包含坐标与类别概率。处理顺序是通用的：先筛掉置信度小于某个阈值的预测，再做NMS去掉重叠框，最后把归一化坐标乘回原图宽高。
实际项目里用Ultralytics封装时，这块不需要手写。但如果你要把模型部署到没有装Ultralytics的机器上，或是不想引入全家桶，一般会先导出ONNX再写推理脚本。ONNX推理核心部分如下：
import onnxruntime as ort import cv2 import numpy as np sess = ort.InferenceSession("bike.onnx", providers=["CUDAExecutionProvider", "CPUExecutionProvider"]) def detect(frame, conf_thres=0.25, iou_thres=0.45): h, w = frame.shape[:2] input_tensor = cv2.resize(frame, (640, 640)).astype(np.float32) / 255.0 input_tensor = input_tensor.transpose(2, 0, 1)[None] outputs = sess.run(None, {sess.get_inputs()[0].name: input_tensor})[0] preds = outputs[0].T # (8400, 84) boxes_xywh = preds[:, :4] scores = preds[:, 4] if preds.shape[1] == 5 else preds[:, 4:].max(axis=1) mask = scores > conf_thres boxes, scores = boxes_xywh[mask], scores[mask] indices = cv2.dnn.NMSBoxes(boxes.tolist(), scores.tolist(), conf_thres, iou_thres) result = [] for idx in indices: cx, cy, bw, bh = boxes[idx] x1 = int((cx - bw / 2) * w) y1 = int((cy - bh / 2) * h) x2 = int((cx + bw / 2) * w) y2 = int((cy + bh / 2) * h) result.append((x1, y1, x2, y2, float(scores[idx]))) return result代码里有两个关键参数。conf_thres控制召回与误检的平衡：调低会增多误报框，调高会漏掉远处小目标，0.25是综合默认值，落地时按场景浮动到0.15到0.4之间。iou_thres控制两个重叠框是否合并，0.45适合共享单车这类非密集目标，换成0.7会让密集停放的车辆框更分散，但偶尔会把一辆车拆成两个框。预处理时的640是模型输入尺寸，训练和推理保持一致才能发挥最佳精度；如果你训练时用了imgsz=512，推理也要改用512。
还有一个容易忽略的点：导出ONNX时，Ultralytics默认把NMS留在模型外部，所以detect()里的后处理逻辑是必须的，不是可有可无。
3. 用YOLOv8训练自己的共享单车数据集：参数与低显存调法
数据集和推理链路都清楚之后，进入实操环节。我跑这个项目时的体会是：训练能不能收敛，80%在数据质量和参数设置，剩下20%才是代码问题。这章先讲怎么把数据处理成YOLO能直接消费的形式，再讲训练参数取舍，最后说怎么从损失曲线和验证指标里发现问题。
3.1 数据划分与YAML配置
划分数据这步用脚本做，不要手拖文件。常见做法是把所有图片路径读进来，按比例打乱后复制到train/val目录：
import os, random, shutil random.seed(42) src_images = "raw_images" train_dir, val_dir = "dataset/images/train", "dataset/images/val" os.makedirs(train_dir, exist_ok=True) os.makedirs(val_dir, exist_ok=True) imgs = [f for f in os.listdir(src_images) if f.endswith((".jpg", ".png"))] random.shuffle(imgs) val_count = max(1, int(len(imgs) * 0.15)) val_imgs = set(imgs[:val_count]) for img in imgs: dst = val_dir if img in val_imgs else train_dir shutil.copy(os.path.join(src_images, img), os.path.join(dst, img))random.seed(42)保证每次运行划分结果一致。这步很重要，不然每次训练集都不同，前后对比实验结果时没有可比性。比例0.15是共享单车场景的折中选择：样本总量通常只有几百到两三千张，验证集太少会导致mAP波动大，一次训练的结果不可信。
划分完成后，需要一个YAML文件描述数据集位置和类别：
path: ./dataset train: images/train val: images/val names: 0: shared_bike注意path可以写相对路径也可以写绝对路径，但相对路径是相对于当前工作目录，不是YAML文件所在目录，训练命令最好在项目根目录执行，否则容易报“找不到图片”的错误。names的编号顺序必须和标签txt里的类别id一一对应，改顺序等于重新打标签，这是“处理数据集用于yolov8训练”时最常踩的坑之一。
3.2 训练参数含义与低显存方案
训练用Ultralytics提供的高层API最省事。两个入口二选一：命令行yolo train或Python脚本。数据集小、调试频繁的时候我习惯用Python脚本，因为可以顺手把参数变化记录成日志：
from ultralytics import YOLO model = YOLO("yolov8s.pt") model.train( data="dataset.yaml", epochs=100, imgsz=640, batch=8, lr0=0.01, patience=20, workers=2, device="0", project="runs/bike", name="exp1", pretrained=True, mosaic=1.0, )epochs是训练轮数，100轮是中小数据集比较稳妥的起点，样本量少时训练会更早收敛。imgsz决定输入分辨率，640是精度与显存开销的平衡点，显存紧张可以降到512，但框住远处车辆的能力会打折。batch是每次迭代喂入的图片数，显存占用几乎与batch成正比，这也是低显存运行时第一个要动的参数。lr0是初始学习率，0.01对YOLOv8来说是默认且稳的，调成0.001收敛更慢但更稳，调成0.1大概率直接爆loss。patience是早停等待轮数，20代表验证指标连续20轮不提升就自动停止；跑通流程时可以把patience设小些加速测试。workers是数据加载线程数，Windows下建议不超过2，设大了反而因为多进程开销拖慢训练。mosaic控制马赛克增强，1.0表示全程开启，对小目标提升明显；显存不足或数据本身足够多样时可以设为0.5甚至0。
如果你手头只有8GB显存的卡，最直接的低显存组合是：batch=4、imgsz=640、workers=0、mosaic=0.5，模型从yolov8s换成yolov8n.pt。之前我在GTX 1660Ti上跑过类似数据量，这套组合显存占用能压在5GB以内。
提示：
batch不要小于2，否则BN统计不稳定，loss曲线会像心电图一样乱跳。
3.3 看训练结果：损失曲线与mAP
有些人会专门写脚本画损失函数曲线图，其实Ultralytics训练完后自动生成results.png，不用自己画。训练结束后，runs/bike/exp1目录下会出现results.csv、results.png和weights文件夹。results.png自动画出train loss、val loss、mAP50等曲线，打开就能用。
看曲线最常见的两个信号：一是train loss持续下降但val loss在不断反弹，说明过拟合，应增加数据增强、降低lr0或提前停止；二是train loss和val loss都降不下来，mAP50低于0.7，问题通常在数据端，比如标签坐标不准确、类别框太小、训练与推理分辨率不一致，而不是换更大的模型。
results.csv里有更细的数值，直接打开末行就能看到最终指标：
epoch,time,train/box_loss,train/cls_loss,train/dfl_loss,metrics/precision,metrics/recall,metrics/mAP50(B),metrics/mAP50-95(B) 99,4.2,0.62,0.38,0.90,0.91,0.87,0.92,0.71对违停检测来说，mAP50超过0.85就能支撑告警逻辑。precision比recall略高一两个百分点效果更好，因为它意味着误报少。mAP50-95是更严苛的指标，反映框定位质量，0.7以上算合格。如果recall长期偏低，优先检查漏标样本；如果precision偏低，优先调整标注框边界，把紧紧贴合车身的框稍微扩一点，模型学起来反而更稳。
4. PyQt5界面开发：线程模型、ROI判定与告警逻辑
模型训练完成，重头戏转移到界面端。这套资源里最直观的就是PyQt5图形界面：左侧视频画面实时叠加检测框与禁停区域，右侧显示告警记录和时间线。在PyCharm里调试这类GUI工程时，把工程目录作为项目根路径打开，Python解释器指向装好ultralytics、opencv-python、PyQt5和onnxruntime的虚拟环境，就能直接运行。
界面端有个必须从一开始就做对的设计选择：推理计算绝对不能放在Qt的GUI主线程里。
4.1 用QThread把推理从界面线程剥离
PyQt5的槽函数运行在主线程，如果直接在槽里调model.predict()，一帧推理要占几百毫秒，窗口会一直转圈，拖拽、点按钮全部无响应。解决方式是用QThread跑循环采集与推理，再通过信号把结果传回主线程绘制：
import cv2 from PyQt5.QtCore import QThread, pyqtSignal from ultralytics import YOLO class DetectWorker(QThread): frame_signal = pyqtSignal(object, list) # 画面 + 检测框列表 error_signal = pyqtSignal(str) def __init__(self, source, model_path, parent=None): super().__init__(parent) self.source = source self.model = YOLO(model_path) self.running = True def run(self): cap = cv2.VideoCapture(self.source) if not cap.isOpened(): self.error_signal.emit("无法打开视频源") return while self.running: ret, frame = cap.read() if not ret: break results = self.model.predict(frame, conf=0.25, verbose=False) boxes = [] for r in results: for box in r.boxes.xyxy.cpu().numpy(): x1, y1, x2, y2 = [int(v) for v in box] boxes.append((x1, y1, x2, y2)) self.frame_signal.emit(frame, boxes) cap.release() def stop(self): self.running = False self.wait()这里的信号设计值得多说两句。frame_signal携带两个参数：原始帧与检测框列表，主线程拿到后直接在QLabel上绘制；不要试图在子线程里更新控件，Qt控件只能由主线程操作。stop()方法里先置running=False，再wait()等待线程退出，关闭窗口时一定要调用，否则程序退出时会报QThread: Destroyed while thread is still running。
model.predict在循环里每次都会重新做预处理和后处理，演示场景够用，也可以在__init__里用model(source=...)生成一个生成器提升吞吐，不过逐帧调用更直观，也方便在每帧前后打点测帧率。
4.2 ROI禁停区域与停留计时判定
禁停区域最简方式是矩形，用四个数表示：roi = (x_min, y_min, x_max, y_max)。更贴近实际场景的是多边形，比如划掉某段人行道的特定范围，但项目里一般先用矩形接口，多边形留给配置项扩展。
共享单车违停，关键不是“出现在画面里”，而是“停在禁停区域且持续一段时间”。瞬时路过不算违停，时间阈值建议设成5到10秒。判定逻辑需要带状态机：某个检测框连续N帧都满足位置条件才触发警报。
import time class ParkingJudge: def __init__(self, roi, hold_seconds=8, interval_seconds=30): self.roi = roi self.hold_seconds = hold_seconds self.interval_seconds = interval_seconds self._track = {} self._last_alarm = {} def is_inside(self, cx, cy): x_min, y_min, x_max, y_max = self.roi return x_min <= cx <= x_max and y_min <= cy <= y_max def update(self, boxes, now=None): now = now or time.time() alarms = [] current_ids = set() for x1, y1, x2, y2, conf in boxes: cx, cy = (x1 + x2) / 2, (y1 + y2) / 2 if not self.is_inside(cx, cy): continue track_id = abs(hash((x1 // 20, y1 // 20))) # 简化位置哈希 current_ids.add(track_id) if track_id not in self._track: self._track[track_id] = now else: stayed = now - self._track[track_id] if stayed >= self.hold_seconds: gap = now - self._last_alarm.get(track_id, 0) if gap >= self.interval_seconds: alarms.append((track_id, stayed, (cx, cy))) self._last_alarm[track_id] = now self._track = {tid: t for tid, t in self._track.items() if tid in current_ids} return alarms两个设计点容易被忽视。第一个是track_id用x1 // 20做位置哈希，意思是同一辆车在20像素误差范围内移动时视为同一辆，对静止的违停检测场景足够；如果场景里车被完全遮挡再出现，会重新计时，这是简化方案的边界，可接受。第二个是interval_seconds，它防止同一辆车停满10分钟后每隔几秒就重复告警；设为30秒表示同车最多每30秒报一次，告警风暴就不会发生。
注意：
roi和boxes都必须是原始帧像素坐标，不能直接用QLabel上的鼠标坐标。界面有缩放显示时，先按比例把鼠标坐标映射回原图坐标，再传给ParkingJudge。
4.3 告警记录与画面落盘
触发告警后，最少要做三件事：画面截图、日志落盘、界面上弹出一条带时间戳的记录。截图用cv2.imwrite，文件名带时间；日志用标准logging模块就够了：
import cv2, logging from datetime import datetime logging.basicConfig(filename="alarm.log", level=logging.INFO, format="%(asctime)s %(message)s") def save_alarm(frame, track_id, cx, cy): stamp = datetime.now().strftime("%Y%m%d_%H%M%S") ok = cv2.imwrite(f"alarm_{stamp}_{track_id}.jpg", frame) if not ok: logging.error("截图写入失败 track=%s", track_id) return None logging.info("ALARM track=%s pos=(%.1f, %.1f)", track_id, cx, cy) return stamp这段代码逻辑简单，但cv2.imwrite的返回值必须检查。磁盘满了、目录权限不够，写入失败时如果不处理，告警事件就会静默丢失。截图命名里带上track_id，人工复盘时能把同一次停留的多张抓拍串起来。
5. 常见问题排查：训练不收敛、界面卡死与检测框乱跳
这套系统拆过多次，下面五条是遇到频率最高的，每条按现象、原因、解决三个维度记录。
5.1 PyQt5窗口白屏或启动崩溃
现象：运行界面程序后窗口出现但画面区空白，或者程序在启动几秒后崩溃退出。
原因：最常见的是视频源打不开，cv2.VideoCapture返回的ret为False，子线程循环直接跳出，而界面没有任何错误提示。另一种是OpenCV和PyQt5的库冲突，特别是同时装多个opencv版本时，cv2.qt插件加载失败会导致整个窗口白屏。
解决：在run()里加启动自检，cap.isOpened()为False时emit错误信号到主线程弹出QMessageBox，而不是静默跳过。库冲突的问题，统一用opencv-python-headless替代带GUI的opencv包，PyQt5界面自己负责显示，OpenCV的highgui模块完全用不上。
5.2 训练时loss变成NaN
现象：训练到某轮后loss突然变成nan，mAP全部跌到0，后续训练持续nan。
原因：大多数情况是标签里有非法数据，比如归一化后的中心x大于1、宽度为负、txt多一列少一列；少数情况是lr0设得过大导致梯度爆炸。
解决：训练前先扫描一遍标签文件，把非法行找出来：
import glob bad = [] for txt in glob.glob("dataset/labels/**/*.txt", recursive=True): for line in open(txt): parts = line.strip().split() if len(parts) != 5: bad.append((txt, "列数错误")) continue nums = [float(p) for p in parts[1:]] if any(v < 0 or v > 1 for v in nums): bad.append((txt, f"归一化越界 {nums}")) print("异常标签数量:", len(bad)) for item in bad[:10]: print(item)这也能解释为什么要用第2章的转换脚本而不是手工编辑标注文件。标签问题修完，把lr0调回0.01再重新训，基本就能恢复。
5.3 模型检测不到角落里的车
现象：场景里车辆摆放密集、部分遮挡或目标很小，模型漏检严重。
原因：数据集里缺乏这类角度样本，模型没见过“角落视角”和“遮挡状态”的单车；同时imgsz太低，小目标在特征图上只剩十几个像素，难以被识别。
解决：一是往数据集里补入俯拍、斜拍、逆光、部分遮挡的图片；二是训练时把imgsz拉到640；三是在第2章的推理脚本里把conf_thres从0.25降到0.15看召回有没有变化。如果只是演示场景，也可以在摄像头安装角度上把机位放高、角度调斜，让车辆之间重叠最小。
5.4 告警总是误报
现象：行人推着单车路过、机动车短暂停靠，也会触发违停告警。
原因：判定逻辑没有区分“目标类别”和“目标是否静止”。推车路过时检测框中心点依然落在ROI内，停留时间可能因为帧率波动被记满。
解决：在ParkingJudge.update()里加一个速度约束，跟踪同一个track_id的框中心点位移，两帧之间偏移超过一定像素（比如30像素）就认为是运动目标，重置停留时间计数。同时要求检测框类别必须是指定的共享单车类别，别把行人目标当输入。
5.5 GPU显存不足无法训练
现象：torch.cuda.OutOfMemoryError在训练开始阶段就出现，即使batch已经调到2。
原因：除了显存本身小，mosaic增强和workers多进程会额外消耗显存与内存。Windows上workers=8会让数据加载进程各自开辟内存，叠加后直接吃满主机内存。
解决：按第3章的低显存组合走：模型换yolov8n、batch=4、imgsz=640、workers=0、mosaic=0.5。如果还想再压，imgsz降到512，代价是远处小目标精度下降。这个场景不要用device="cpu"硬扛，CPU推理一轮训练可能要几十分钟，性价比太低。
6. 告警闭环与验证技巧：从演示到可部署
基础功能跑通后，要让它从“能用”变成“可交付”，我一般会补上两件事：告警事件往外部系统的推送，以及用视频回放验证误报率。
6.1 告警推送接口
告警推送常见做法是HTTP POST到已有的告警平台或群机器人。把告警快照、时间、位置编码成JSON，用requests发出：
import requests def push_alarm(stamp, track_id, x, y, image_path): payload = { "source": "shared_bike_system", "alarm_time": stamp, "track_id": track_id, "position": [x, y], "image": image_path } try: resp = requests.post("http://your-alarm-server/api/alarm", json=payload, timeout=3) return resp.status_code == 200 except requests.exceptions.RequestException: return Falsetimeout=3是必须的，告警服务端故障时不能阻塞检测线程。推送失败时打印日志并留好本地截图，等人工处理，不要无限重试。
6.2 回放验证与耗时统计
验证环节，我的习惯是用一段真实监控录像跑回放，统计三个数：总帧数、平均单帧推理耗时、告警事件数。单帧耗时用time.time()在predict前后打点即可。目标延迟控制在200毫秒以内，界面操作才不会明显迟滞；超过400毫秒就要考虑换更小模型、降分辨率或换显卡。
误报率统计更依赖人工：把告警截图按时间排列，人工核对哪些是真正违停。共享单车违停场景，误报率能压到10%以下就算可交付；如果总是不稳定，优先检查ROI是否划得太大，把允许临时停放的区域划在ROI外，比任何算法优化都来得快。
我自己做这类项目时有过一次教训：交付前一晚发现告警截图全部是白图，排查半天是OpenCV在高帧率下写磁盘偶发失败，而cv2.imwrite的返回值没有被检查。从那以后我每次在save_alarm里都强制检查写入结果，失败就重试一次并弹窗提示，再没有出现过告警图片丢失的情况。希望这份拆解能帮你把这个共享自行车检测系统跑得更顺。
本文还有配套的精品资源，点击获取
