基于YOLOv5与PyQt5的行人车辆检测计数系统实战解析

1. 需求与系统框架梳理

先说说这个系统的核心价值。做算法的人都知道，模型训练只是第一步，真正要落地使用，必须有个能交互、能实时看到效果的界面。这套系统做的就是“模型 + 界面 + 应用场景”的完整闭环：用深度学习卷积网络作为底层算法支撑，以YOLOv5作为目标检测核心，提供PyQt可视化操作界面，在COCO数据集上完成训练，最终在行人车辆检测计数场景中落地。

我在实际开发中体验最深的一点是：这类系统最大的痛点从来不是模型精度，而是从训练到部署的链路太长。训练好的权重文件要转成可用的推理模块，推理模块要接进界面线程，界面操作要实时反馈检测结果，计数逻辑还要区分目标类别……任何一个环节卡住，整个系统都跑不起来。这篇文章就把我踩过的坑、验证过的做法完整拆开讲。

系统整体由四层构成：

• 算法层：YOLOv5模型（卷积神经网络提取特征），承担目标检测推理任务
• 数据层：COCO数据集（涵盖80类常见物体，本项目重点使用person、car等类别），承担模型训练与验证
• 交互层：PyQt5编写的桌面界面，承担视频/图片输入、检测控制、结果可视化等用户操作
• 应用层：行人车辆计数逻辑，承担对检测结果的结构化处理与统计

这个架构的合理之处在于每一层都可以独立替换。模型可以换成YOLOv8或者更轻量的版本，界面可以从PyQt换成Web前端，数据集也可以替换成自定义数据，互不干扰。做系统设计的时候，这种松耦合思路能省很多后期维护的力气。

2. 目标检测与YOLOv5技术点解析

2.1 卷积网络在YOLOv5中扮演什么角色

卷积神经网络是YOLOv5的骨干结构。简单理解，卷积层做的事情就是对图像进行“特征提取”：低层卷积识别边缘、颜色、纹理，高层卷积组合出物体部件、整体轮廓，最终在特征图上形成有判别力的语义信息。

YOLOv5采用CSPDarknet作为骨干网络，在COCO数据集上表现优秀。它有一个很实用的设计：CSP结构（Cross Stage Partial）把特征图分成两部分，一部分经过卷积块处理，另一部分直接拼接，最后融合输出。这个设计在不明显增加计算量的前提下，增强了梯度流动和信息复用，训练时候收敛速度比单纯堆层快很多。

YOLOv5输出的特征图有三个尺度，分别对应大、中、小目标。以640x640输入为例，预测特征图大小为80x80、40x40、20x20，每个grid cell会生成3个锚框，匹配不同尺寸的目标。对于行人车辆这类尺度变化明显的目标，多尺度预测是非常关键的——远处的行人可能只占十几像素，近处的车辆却可能占据大半幅画面，单一尺度的检测头根本吃不消。

2.2 模型选型与权重配置：s/m/l/x该怎么选

YOLOv5提供了多个版本，参数规模从轻到重。我用COCO数据集实际对比过各版本在行人车辆任务上的表现，这里直接给参考结论：

我做这个系统选的是YOLOv5s和YOLOv5m两个版本。原因并不复杂：界面系统讲究的是交互流畅性，如果一帧检测要卡几百毫秒，鼠标操作都跟手，用户体验会大打折扣。同时，行人车辆这两类目标在COCO里样本量大、类别特征相对清晰，s和m版本的容量完全够用。一个从零开始的小目标检测任务盲目上x版本，反而容易过拟合训练数据，推理速度也会拖垮整个界面。

训练好的模型文件是.pt格式，部署时直接加载。官方也支持导出为ONNX，方便跨平台部署，但在这个PyQt系统的场景下，直接加载PyTorch权重最简单稳妥，不需要额外引入推理引擎依赖。

2.3 COCO数据集在训练中的实际使用方式

COCO数据集是一个大规模物体检测数据集，包含80个物体类别、超过20万张图片和几十万个标注实例。本项目重点使用其中的人和车辆相关类别。

实际操作中，直接整个加载COCO数据集是不现实的，因为训练数据过于庞大，单机训练周期很长。更明智的做法是写一个脚本，从COCO的标注文件（instances_train2017.json）中自动提取含person、car、truck、bus等类别的图片和对应标注，重新组织成YOLO格式的训练集。

YOLO格式的标注需要将COCO的[x1, y1, width, height]绝对坐标转换为归一化的[x_center, y_center, width, height]，类别ID也要从COCO的80类索引映射到自定义类别索引：

import json import os import shutil from pathlib import Path # COCO类别名称到ID的映射（只保留行人车辆相关类） coco_classes = { 'person': 0, 'car': 1, 'truck': 2, 'bus': 3, 'bicycle': 4, 'motorcycle': 5 } # 这里需要根据实际COCO标注中类别名称到ID的映射自行补充 # coco_class_id_lookup = {...} with open('annotations/instances_train2017.json', 'r') as f: coco_data = json.load(f) # 1. 建立图片id到文件名的映射 images = {img['id']: img['file_name'] for img in coco_data['images']} # 2. 过滤出我们需要的类别标注 target_anns = {} for ann in coco_data['annotations']: cat_id = ann['category_id'] cat_name = id_to_name[cat_id] # 需要先把COCO类别id转成名称 if cat_name in coco_classes: img_id = ann['image_id'] # 转换成YOLO格式：xywh归一化 x, y, w, h = ann['bbox'] img_w = images_info[img_id]['width'] img_h = images_info[img_id]['height'] x_center = (x + w / 2) / img_w y_center = (y + h / 2) / img_h norm_w = w / img_w norm_h = h / img_h class_idx = coco_classes[cat_name] target_anns.setdefault(img_id, []).append( f"{class_idx} {x_center:.6f} {y_center:.6f} {norm_w:.6f} {norm_h:.6f}" ) # 3. 只拷贝包含目标类别的图片 for img_id, lines in target_anns.items(): src = os.path.join('train2017', images[img_id]) dst_img = os.path.join('custom_dataset/images/train', images[img_id]) dst_txt = os.path.join('custom_dataset/labels/train', images[img_id].replace('.jpg', '.txt')) shutil.copy(src, dst_img) with open(dst_txt, 'w') as f: f.write('\n'.join(lines))

这个脚本跑完后，得到的自定义数据集远比完整COCO轻量，训练时间从几天降到几个小时，效果依然能满足行人车辆检测的需求。提取时候要注意一个细节：尽量保留不同场景、光照、角度下的样本，保证数据多样性，否则训练出来的模型很容易在特定环境下失效。

3. 模型训练实践篇：参数调节与精度提升

3.1 训练环境配置与数据准备

训练环境方面，我用的是一张8GB显存的独立显卡，PyTorch版本与CUDA版本对应。第一次跑训练前，先花10分钟做一个“冒烟测试”——只训练几个batch，确认前向反向传播没有报错，再启动完整训练流程，能省下很多排查时间。

数据集准备好后，需要写一个数据配置文件，告诉YOLOv5去哪里找图片、labels，以及类别名称。我习惯严格按这个模板来：

# custom_data.yaml train: ../custom_dataset/images/train val: ../custom_dataset/images/val nc: 6 names: ['person', 'car', 'truck', 'bus', 'bicycle', 'motorcycle']

数据划分比例我一般用8:1:1（训练：验证：测试），并且保证划分是根据视频序列或者场景分层采样，而不是简单随机分割，这样能避免同一个路口画面既出现在训练集又出现在测试集，造成虚高的评估分数。

3.2 训练参数调节的实际经验

训练命令不复杂，难的是把参数调到合适。我常用的启动命令是这样：

python train.py --img 640 --batch 16 --epochs 100 --data custom_data.yaml \ --weights yolov5s.pt --device 0 --cache

几个关键参数的选择逻辑，我认为值得明确说清楚：

Batch size：理论上越大越好，梯度方向更稳定。但受显存限制，8GB卡跑batch 16配合640分辨率已经是上限。如果显存不够，也可以降到batch 8，配合梯度累积，效果接近大batch。

Image size：训练尺寸我用640，评测尺寸也用640，保持输入分布一致。实际部署如果摄像头是720p或1080p，图像会被缩放，细小的行人在缩放后信息可能有损失，这一点需要考虑是否使用更高分辨率重新训练。

学习率：YOLOv5默认使用余弦退火调度。我一般用默认初始学习率0.01，但会把最终学习率降为原先的0.1倍，这样后期收敛更精细。前3个epoch使用warmup，让模型从稳定的初始状态出发，避免一开始就大幅震荡。

Epochs：COCO数据集类别多，一般100个epoch左右可以充分收敛。在自定义小数据集上，我习惯先跑50个epoch观察验证集损失曲线，如果还在明显下降，就继续加到100甚至150。训练时通过验证集的mAP曲线判断，而不是固定死轮数。

Flags：--cache参数在第一次读取数据集时把图片缓存到内存，大幅缩短训练IO等待。数据量不大时强烈推荐，可以让显卡利用率明显提升。

3.3 训练过程中如何观察和调优

训练到一半，怎么判断模型能不能用？我一般关注三个指标：

• 验证集mAP@0.5：这个值反映在IOU阈值0.5下的平均精度，行人车辆这类大目标，mAP达到0.85以上就算很不错的水平
• Precision（精确率）：检测出的框有多少是真正的目标，数值偏低说明误检多，常见原因是有大量相似背景干扰
• Recall（召回率）：实际目标有多少被检测出来，数值偏低说明漏检多，常见原因是目标太小或者遮挡严重

我实际训过一次只跑了80个epoch的模型，mAP@0.5到了0.87，但P和R不均衡（P高R低），表现为界面上偶尔漏检穿深色衣服的行人。解决办法是增加包含暗光、逆光场景的训练图片，同时稍微调低置信度阈值，让模型“敢于”多输出候选框，再做NMS后处理筛选。

还有一个容易被忽略的点：数据增强参数。YOLOv5默认开启了马赛克增强、随机仿射变换、HSV扰动等。对于行人车辆这类形态相对固定的目标，我建议保留马赛克增强但把仿射变换的旋转角限制在±10度以内——车辆在路面场景中不会出现大面积翻转，过强的旋转增强反而会让模型学到不真实的目标形态。

3.4 多类别训练时的损失函数与样本均衡

COCO训练出的模型有多类别输出，训练过程中会计算三个分支的损失：分类损失（BCE）、置信度损失（BCE）和定位损失（CIoU）。

多类别带来的一个实际问题是类别不均衡。一个路口场景中，行人出现的频次通常低于车辆，bus、truck、motorcycle这些类别样本更少。YOLOv5默认会对每个类别的损失做一定的权重平衡，我在实践中会根据各类别样本量比例调整超参数cls_pw。如果样本数相差超过10倍，建议在数据准备阶段做类别重采样，而不是完全依赖损失函数层面的平衡。

训练结束后得到的best.pt就是验证集表现最好的权重文件。在界面开发阶段，把这个权重加载进模型，后续所有逻辑都围绕它展开。

4. PyQt界面开发完整实战

4.1 界面布局与功能规划

界面开发这块，我走了不少弯路。一开始试图把所有功能塞进一个窗口，结果控件堆叠、逻辑混乱，后来重构成了清晰的三区块布局：

• 左侧：控制面板，包括模型选择下拉框、置信度阈值滑块、视频/图片加载按钮、摄像头开启按钮、检测暂停/恢复按钮
• 中间：检测画面实时显示区，原图和检测结果叠加显示，框体颜色区分不同类别
• 底部：统计信息栏，实时显示画面中行人数、车辆数，以及历史累计计数

PyQt5的信号槽机制是这个界面开发的核心。检测线程每完成一帧推理，就发射一个信号，主界面接收到信号后更新画面和计数。坚决不能在主线程里做推理，否则界面会卡死到完全无法操作。这一点我认为值得划重点。

import sys import cv2 import torch from PyQt5.QtCore import QThread, pyqtSignal from PyQt5.QtGui import QImage, QPixmap from PyQt5.QtWidgets import QApplication, QMainWindow, QLabel, QPushButton, QVBoxLayout, QWidget class DetectThread(QThread): # 定义信号：帧数据、检测结果、计数统计 frame_signal = pyqtSignal(QImage) count_signal = pyqtSignal(dict) def __init__(self): super().__init__() self.model = None self.cap = None self.running = True def run(self): while self.running: ret, frame = self.cap.read() if not ret: break # 推理 results = self.model(frame) # 解析结果，画框 ... # 统计计数 ... # 转换格式发信号 ... pass def stop(self): self.running = False self.wait()

这里的核心设计模式是：界面只负责展示，线程只负责任务。深度学习推理放在后台QThread，不会阻塞界面刷新；界面通过信号接收结果更新UI，也天然解决了线程安全问题。

4.2 模型加载与推理模块编写

在界面中加载YOLOv5模型，我推荐直接使用torch.hub.load的方式，简单稳定：

import torch # 本地加载方式：指定本地yolov5仓库路径 model = torch.hub.load('yolov5', 'custom', path='runs/train/exp/best.pt', source='local') # 推理设置 model.conf = 0.35 # 置信度阈值 model.iou = 0.45 # NMS的IOU阈值 model.classes = [0, 1, 2, 3, 4, 5] # 只检测行人车辆相关类别 model.max_det = 100 # 单帧最多检测目标数

torch.hub.load的第一个参数指向本地目录，第二个参数传入custom表示加载自定义权重，第三个参数指定权重文件路径。这样加载进来的模型跟训练时完全一致，包括预处理流程和锚框设置，不需要自己再写预处理逻辑。

推理时，输入可以是BGR通道的numpy数组（OpenCV读出来的图像），YOLOv5内部会做好letterboxresize和归一化。推理输出的results对象包含results.pandas().xyxy[0]这样的表格，可以直接拿到每个目标的坐标、置信度、类别名，非常方便做界面展示：

results = model(frame) df = results.pandas().xyxy[0] person_count = 0 vehicle_count = 0 for _, row in df.iterrows(): x1, y1, x2, y2 = int(row['xmin']), int(row['ymin']), int(row['xmax']), int(row['ymax']) label = row['name'] conf = row['confidence'] if label == 'person': person_count += 1 color = (0, 255, 0) # 绿色框 elif label in ['car', 'truck', 'bus', 'bicycle', 'motorcycle']: vehicle_count += 1 color = (0, 0, 255) # 红色框 cv2.rectangle(frame, (x1, y1), (x2, y2), color, 2) cv2.putText(frame, f'{label} {conf:.2f}', (x1, y1 - 6), cv2.FONT_HERSHEY_SIMPLEX, 0.7, color, 2) cv2.putText(frame, f'Person: {person_count} Vehicle: {vehicle_count}', (20, 40), cv2.FONT_HERSHEY_SIMPLEX, 1, (255, 255, 255), 2)

这段代码的逻辑很直接：遍历检测结果，按类别设置不同颜色画框，同时按类别计数，最后把计数文字显示在图像左上角。界面上显示的就是这个叠加了检测框和计数的画面。

4.3 实时画面显示与计数逻辑优化

从OpenCV的Mat格式转换到QImage显示，有一段固定翻译代码：

rgb_image = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w, ch = rgb_image.shape bytes_per_line = ch * w qimage = QImage(rgb_image.data, w, h, bytes_per_line, QImage.Format_RGB888) QPixmap.fromImage(qimage)

这里有个曾经踩过的坑：QImage引用的数据必须是连续内存且在使用期间存活。如果直接在局部变量中创建QImage然后通过信号传递，底层buffer可能被回收，导致界面上出现花屏或崩溃。稳妥做法是在信号发出前创建深拷贝rgb_image.copy()，或者把QImage本身作为值类型传递，避免引用野指针。

计数逻辑方面，视频流中同一批行人可能会在连续帧中被重复计数。如果是统计“当前画面人数”，只需统计当前帧的检测框数量，不需要跨帧追踪。但如果要做“累计通过人数”，就必须引入跟踪逻辑，判断某个目标是否已经统计过。最简单的做法是基于目标中心点在相邻帧的位移，设定一个匹配阈值，位移小于阈值的视为同一目标，不重复计数。更鲁棒的方案是接入ByteTrack或DeepSORT，但对界面系统来说，基于IOU匹配的轻量追踪已经够用。

4.4 并发处理：摄像头读取、推理、界面刷新不卡顿

一个容易忽略的瓶颈是视频解码与模型推理都在同一线程里的处理速度差异。摄像头的帧率可能是30FPS，但模型的推理速度可能只有10-15FPS。如果不加控制，队列会不断堆积帧，检测画面的时间戳越来越落后于真实时间，看着就像一个“迟到的直播”。

我的处理方式是双线程流水线：一个线程读取视频帧并放入循环队列（只保留最新帧），另一个线程从队列取帧做推理和显示。这样即使推理速度慢于视频帧率，界面展示的依然是最近的画面，而不是积压的旧帧。实现时用带锁的deque，长度上限设置为1-2，读取线程发现队列满就直接覆盖旧帧。

from collections import deque from threading import Lock frame_buffer = deque(maxlen=2) buffer_lock = Lock() # 读取线程 def capture_frames(cap): while True: ret, frame = cap.read() if not ret: break with buffer_lock: frame_buffer.append(frame) # 推理线程 def inference_loop(model): while True: with buffer_lock: if len(frame_buffer) == 0: continue frame = frame_buffer.pop() results = model(frame) # 显示与统计...

这个模式下，读取线程和推理线程各干各的，互不等待，界面实时性有了很大改善。

5. 功能联调与系统测试记录

5.1 本地图片检测效果测试

训练完成后，我先用一组测试图片验证系统的基础识别能力。测试图片包含三种典型场景：白天城市道路、夜间灯光下的路口、阴天行人密集的人行道。

实测结果：白天场景下，行人检测框稳定，置信度普遍在0.7-0.9区间，车辆框准确贴合车身轮廓。夜间场景里，部分暗处行人的置信度掉到0.3以下，通过把置信度阈值从0.35下调到0.25，能找回一部分漏检目标，但代价是误检增加。阴天场景表现良好，无遮挡的检测基本没有漏检，遮挡严重的会有漏检，这是同类模型的通病。

5.2 视频流与摄像头实时检测

接入摄像头后，我重点测试了帧率与延迟表现。YOLOv5s在这台设备上推理平均耗时约8ms，加上前后处理和界面绘制，整体不超过15ms，视觉上画面流畅，没有明显迟滞。测试中还发现，摄像头分辨率越低，处理越流畅，但小目标的检测精度也会下降——1080p画面上一个5米外行人的高度约为50个像素，缩到640推理尺寸后只剩约18个像素，信息量大幅缩减，所以实际部署时需要根据场景选择合适的工作分辨率。

5.3 多类别识别与计数准确性

人群密度中等的路口场景下，系统对行人的计数准确率高于车辆，因为车辆之间存在遮挡时漏检率更高。走查了一些测试视频的日志，发现一个规律：车辆密集排队时，前车和跟车紧贴，两车之间的特征区分度下降，容易被合并成一个框。这个现象在视觉上表现为车身长度比实际长。缓解办法是适当调低NMS的IOU阈值，让重叠的目标更容易保留多个框，代价是重叠部分的误检可能增加。

另外，我测试了包含骑行者（骑摩托车/自行车的人）的画面。COCO数据集里bicycle和motorcycle单独标注，但person类也覆盖骑行者，所以模型有时会把骑行者和车辆各框一个框，有时只给车辆一个框、漏掉骑行者个人。这个场景的精度，取决于训练样本里这类图片的数量和多样性。

5.4 界面交互完整流程测试

我从一个用户视角完整走了一遍操作流程：打开界面，选择模型，加载视频文件，点击开始检测，拖动置信度阈值滑块，观察画面计数的实时变化，暂停检测，退出系统。

测试过程中发现两个需要优化的细节：

一是模型加载期间的界面假死。加载best.pt到GPU需要几秒时间，如果同步执行，界面会无响应。解决方式是在进入检测前弹出一个“模型加载中”的过渡状态，或者把模型加载也放进线程中异步处理。

二是滑块调节的响应速度。直接把滑块变化连接到推理参数更新，在检测进行时可能出现参数频繁变化的闪烁。更好的做法是滑块松开时（sliderReleased事件）才更新模型参数，避免拖动过程中不断更新。

优化后，整个操作链路顺畅，检测结果实时更新，计数统计准确，系统达到了实用性标准。

6. 常见问题排查与脱坑记录表

电脑跑实际项目过程中，总会遇到各种问题，我整理了一个高频问题表，都是亲身遭遇过的：

关于显存优化，有个很实用的参数--cache。如果显存不够，可以先加载模型到GPU，推理时再传给GPU计算，每次传输有耗时，但显存占用大幅降低。在PyQt界面里，一帧一帧推理时这个传输开销可以接受，换来的是系统稳定不崩。

另一个值得记录的细节是NumPy数组版本兼容问题。YOLOv5依赖的某些API在新版NumPy中改了签名，会出现奇怪的报错。我的建议是固定环境版本，训练和部署使用同一套依赖列表，不要一个是新环境一个是旧环境。

7. 从技术验证到落地部署的个人体会

做了几轮试验后，最大的收获不是我“会跑通了一个项目”，而是理解了目标检测系统从模型到产品需要跨越多少工程细节。模型的效果再好，如果不能以友好的方式呈现给使用者，不能稳定地在实际环境中运行，就始终停留在算法Demo阶段。

另一个比较深的体会是关于数据集的价值。用COCO预训练权重做初始化，再用小数据集微调，效率远高于从头训练。这种做法背后的逻辑是：COCO提供了丰富的通用特征，微调只是让模型关注行人车辆的特殊模式。这也解释了为什么即使类别不一样，预训练权重也有很好的迁移效果——底层卷积核提取的边缘、纹理、形状信息是通用的。

最后想单独提醒一点：系统测试时一定要拿真实的视频数据验证，而不是只在测试集图片上看效果。视频中目标的大小变化、光照波动、运动模糊、遮挡持续存在，这些动态特征是静态图片无法体现的。我的测试经验是，把同一个模型放在静态图片测试集和动态视频流里，指标至少差5-10个百分点，动态环境始终是检测系统的主要挑战。后面在做类似系统的时候，建议把视频测试作为验收的必选项，提前发现并处理动态场景下才会暴露的问题。