尧图网站建设 
简介基于YOLOv7与Deepsort的智慧交通系统项目实践资源面向计算机视觉学习者、智慧交通方向开发者以及需要完成课程设计或毕业设计的高校学生可有效解决从零搭建目标检测与多目标跟踪系统的技术门槛。资源包共17个文件以Python源码脚本和PNG/JPEG效果图为主其中源码实现从模型调用到跟踪输出的完整流程图片展示不同交通场景下的运行效果整体压缩包8.15MB体积紧凑便于直接下载与查阅。目前已有213人学习下载适合作为课程项目、算法验证或竞赛参考。内容包含实际可运行的YOLOv7Deepsort工程代码、配套教程说明与效果图表可帮助读者理解车辆/行人检测、特征提取、轨迹关联等关键环节的工程落地细节并在此基础上扩展车流量统计、违章检测、智能调度等智慧交通应用。1. 一套能跑的智慧交通系统源码到底解决了什么问题一个学弟拿 YOLOv5 跑通车辆检测后过来问我“框是出来了但我怎么知道画面里那辆白色 SUV 停了几秒”这就是从目标检测到智慧交通系统的分水岭检测只回答“每一帧里有什么”而智慧交通要回答“这辆车是谁、从哪来、到哪去、停了多久”。基于 YOLOv7 和 DeepSORT 的智慧交通系统做的就是这套串联工作——YOLOv7 负责把车辆、行人、非机动车从画面里框出来DeepSORT 负责给每个框一个身份 ID 并追着它走完整个视野。这两年人工智能正从尝鲜工具变成日常帮手交通视频分析是落得最实的场景之一。源码包里装的不是某个单独模型而是一条从检测、跟踪到车流统计、违章判别的完整链路。适合拿来当人工智能大作业、毕设选题也适合已有检测模型但缺跟踪层和业务逻辑的从业者做二次开发。这一篇就把这条链路拆开原理讲透参数给全踩坑记录逐条写。2. YOLOv7 作检测引擎为什么选它以及部署前必须搞懂的三个原理2.1 E-ELAN 与重参数化YOLOv7 的算力账怎么算YOLOv7 在 2022 年发布时打的就是“精度与速度兼顾”这张牌直到今天仍是智慧交通项目里出现频率最高的检测器之一。核心结构叫 E-ELANExtended Efficient Layer Aggregation Network做的事很直白把 feature map 按通道拆成几组每组做不同卷积再跨层拼接让梯度在深层网络里有多条路径回传。翻译成落地语言就是——同样的参数量梯度不消失训练更稳小目标远处车辆不容易被丢掉。重参数化是第二个关键点。训练时网络里并了好几路卷积分支推理前把它们合并成一条单路卷积。数学上就是卷积的可加性两个同尺寸卷积核作用于同一输入结果等于把卷积核相加后再做一次卷积。YOLOv7 的RepConv在训练时是 3×3 加 1×1 加分支的复合结构导出权重时合并成单 3×3推理速度立刻上去一截。很多新手在export.py里看到模型结构变了就疑惑是不是代码写错了——那是正常现象重参数化模块在train.py里活着在deploy.py里就合并了。2.2 aux head 与动态标签分配辅助头在训练时做了什么YOLOv7 的辅助头aux head是最容易误解的设计。训练时它多算一路 loss让浅层特征也收到梯度信号推理时辅助头直接剪掉只保留 lead head 输出。所以你在训练日志里看到aux_loss在降不要试图在推理代码里找它——它只在反向传播里存在。对应到命令行参数是--no-aug之外的--no-aux如果你想用 YOLOv7 做纯检测微调且数据集很小开着 aux 容易过拟合可以关掉赌一把更快收敛。动态标签分配是另一个容易被忽略的点。YOLOv7 用 coarse-to-fine 两级分配先粗筛候选框再精细匹配避免一个 GT 框被多个标签重复指派、也避免高质量预测被低质量匹配拖累。这带来的调试习惯是训练完看mAP0.5之外务必看mAP0.5:0.95的曲线形态。交通场景里远处车辆往往只有十几个像素如果 0.5 阈值下精度高但 0.95 下掉得厉害说明框定位不稳。2.3 从 .pt 到 TensorRT三种部署方式的取舍拿到仓库里现成的训练好的 YOLOv7 权重部署路径有三条直接用 PyTorch 推理.pt文件加载改起来最快但显存占用高、延迟不稳。转 ONNX ONNX Runtimeexport.py --grid --simplify导出CPU/GPU 都能跑适合快速验证。TensorRT FP16/INT8转型速度最快但依赖 NVIDIA GPU 和 CUDA 版本engine文件和显卡强绑定换卡要重构建。我一般先用 ONNX 跑通全流程确认业务逻辑没问题再上 TensorRT。这个顺序能避开“模型转换后行为变了却分不清是跟踪器还是转换器的问题”。下面是最小推理片段跑通它再谈后续import cv2 import torch # 加载 YOLOv7 训练好的权重构建模型 model torch.hub.load(WongKinYiu/yolov7, custom, yolov7.pt, trust_repoTrue) model.eval() frame cv2.imread(street.jpg) # BGR 读入 # letterbox 保持宽高比缩放避免目标被拉伸变形 from utils.general import letterbox boxed, ratio, (dw, dh) letterbox(frame, new_shape640, autoFalse) tensor torch.from_numpy(boxed[:, :, ::-1].transpose(2, 0, 1)).float() / 255.0 tensor tensor.unsqueeze(0).to(next(model.parameters()).device) with torch.no_grad(): pred model(tensor)[0] # [batch, num_anchors, 85]这段代码的关键在letterbox不做这一步检测框会系统性偏移。new_shape640是 YOLOv7 默认训练尺寸改小到 416 能提速但小目标召回率下降autoFalse强制保证宽高都能被 stride 整除避免维度对齐错误。pred的最后一维 85 是 4 个框坐标、1 个置信度、80 类 COCO 得分你后续要接 DeepSORT就得先把这些原始预测经 NMS 转成(x1, y1, x2, y2, score, class_id)的列表。3. DeepSORT 作跟踪层参数不是玄学是卡尔曼滤波和级联匹配的配合3.1 跟踪的本质检测框如何变成一条连续轨迹DeepSORT 在智慧交通里的角色是把 YOLOv7 输出的零散检测框变成有编号的轨迹。它的内部有两套账本一套是卡尔曼滤波维护每个目标的位置和速度另一套是 ReID 特征库记录每个目标的外观向量。卡尔曼滤波的状态向量是 8 维(cx, cy, r, h, vx, vy, vr, vh)前四个是中心点、宽高比、高度后四个是对应速度。每帧检测进来卡尔曼滤波先拿上一帧的状态做一次运动预测得到预测框再和当前帧实际检测框做匹配匹配上用检测框修正预测没匹配上就继续在预测状态里外推。外观匹配用的是余弦距离DeepSORT 里每个检测框会过一个 ReID 网络输出一个 128 维特征向量轨迹的历史特征存成一个集合新检测框的特征和这个集合的最近距离就是它的“长相分”。运动匹配管着“你下一步该出现在哪”外观匹配管着“你是不是之前那辆车”两个信号叠加成代价矩阵再做匈牙利匹配。这就是为什么 DeepSORT 在车辆遮挡后还能把 ID 找回来——运动不行了靠长相兜底。3.2 五个必调参数max_dist、max_iou_distance、max_age、n_init、min_confDeepSORT 的公开实现里参数都集中在tracker.py和deep_sort_app.py顶部下面这张表是车辆场景下的推荐初值参数推荐值作用调参方向max_dist0.2外观余弦距离阈值超过则拒绝匹配车辆 ReID 相似度高改大到 0.3 能减少 ID 切换改小更严格但易丢max_iou_distance0.7IoU 匹配门槛低于则视为不重叠遮挡严重时改大到 0.8max_age70轨迹丢失后最多存活帧数出视野后仍要计数就加大车辆横穿十字路口需要 90n_init3连续 3 帧命中才确认轨迹防误检导致幽灵轨迹改大能滤噪但延迟确认min_conf0.5检测置信度过滤夜间漏检时降到 0.4但会引入误检需搭配 NMS 调整每次只改一个参数记录确认轨迹数和 ID 切换次数两个指标。max_age加大的代价是车辆早就离开画面轨迹还在内存里存活计费逻辑如果把轨迹首次出现当成一次计数就会把同一辆车在画面两端重新入场重复计两次。3.3 deepsort 改进ReID 特征和检测质量的耦合网上流传的各类“deepsort 改进”绕不开三个地方ReID 网络替换、匹配策略改造、检测框质量耦合。最容易见效的是第一个——把原版ckpt.t7的 ReID 网络换成针对车辆数据集微调过的轻量模型比如基于 ResNet18 的输出 256 维特征再 L2 归一化。车辆和行人不同同品牌同型号的车可能外观几乎一样128 维特征根本不够区分换成 256 维后余弦距离的分辨力显著提升。第二个常见改造是给级联匹配加“检测置信度门控”高置信度检测框优先匹配低置信度框只能匹配已确认轨迹。原版 DeepSORT 的min_conf是前置过滤把它挪进代价矩阵里让 0.4 置信度的框有机会参与匹配但不污染新建轨迹对夜间场景友好。第三个改造不碰算法——直接把 YOLOv7 的检测框做一次xyxy到cxcywh的格式转换时保留原始置信度并传给tracker.update避免在封装层丢掉这个信息。接入跟踪器的核心代码是这样的from deep_sort import DeepSort # 参数对应上表车辆场景初值 tracker DeepSort(max_dist0.2, max_iou_distance0.7, max_age70, n_init3, nn_budget100) def process_frame(frame, results): # results: YOLOv7 输出的 [x1, y1, x2, y2, score, class_id] dets [] for det in results: if det[4] 0.5: # min_conf 过滤 dets.append([det[0], det[1], det[2], det[3], det[4]]) if len(dets) 0: return tracker.update([], frame) return tracker.update(dets, frame) # 返回 [x1, y1, x2, y2, track_id]nn_budget100是 ReID 特征库存放的历史上限超过后会随机丢掉旧特征。车辆在画面里走得久、特征增长快这个值设太小会让外观信息丢失设太大则内存涨得快100 对单路口场景合理。tracker.update的第二个参数是原始帧图像DeepSORT 的 ReID 网络需要在这里重新提特征意味着每帧多一次前向推理——这也是 CPU 机器上 DeepSORT 比检测器还慢的常见原因。4. 把源码跑起来的完整链路数据准备、训练、业务逻辑4.1 VOC 格式转 YOLO 格式转换脚本与四个边界坑源码仓库里通常自带标注好的交通数据集或者给了 UA-DETRAC 之类的公开数据集说明。拿到手第一步是把标注统一成 YOLO 格式每张图对应一个.txt每行class_id cx cy w h坐标是相对于宽高的比例值。如果数据集是 VOC 的.xml标注就得先转一次import xml.etree.ElementTree as ET import os def voc_to_yolo(xml_path, out_dir, class_map): tree ET.parse(xml_path) root tree.getroot() size root.find(size) w, h int(size.find(width).text), int(size.find(height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_map: # 只保留需要的类别 continue box obj.find(bndbox) x1, y1 float(box.find(xmin).text), float(box.find(ymin).text) x2, y2 float(box.find(xmax).text), float(box.find(ymax).text) # YOLO 格式要求中心点和宽高全部除以图像尺寸做归一化 cx (x1 x2) / 2 / w cy (y1 y2) / 2 / h bw (x2 - x1) / w bh (y2 - y1) / h lines.append(f{class_map[name]} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) with open(os.path.join(out_dir, os.path.basename(xml_path).replace(.xml, .txt)), w) as f: f.write(\n.join(lines))四个边界坑每个都踩过class_id必须从 0 开始连续编号。.xml里类名是字符串转的时候要手工建class_map漏一个类就会导致所有后续类别偏移一位训练时 mAP 诡异下降。框坐标不能越界。部分标注工具的x2/y2会标到图像外直接除会产生大于 1 的宽高比YOLOv7 训练时会警告并丢弃这些框先做max(0, min(w, x2))钳制。训练列表文件里的路径不能带绝对路径前缀。仓库自带的train.txt常是/home/user/...开头换机器后要么改路径要么统一改成相对路径再训练。图片和标注文件名必须完全一致不能出现同一张图有两个标注文件或一个标注落在空图上——训练脚本会静默跳过不配对的数据让你误以为是模型没训好。4.2 车流量计数虚拟线和轨迹 ID哪个更稳车流量统计是这个项目最核心的业务出口。两种常见做法一种是在画面上画一条虚拟线车辆中心点跨过这条线的瞬间计数另一种是轨迹 ID 首次出现时计数。虚拟线法稳在“物理意义直观”坏在跨线判定要处理方向车辆从左往右和从右往左都跨线同一个计数点不能只数一个方向。轨迹 ID 首帧计数不用管方向但视野边缘的误检会产生幽灵 ID计数虚高。我一般混合用以虚拟线为主计数轨迹 ID 只做去重兜底。import cv2 import numpy as np line_y 360 # 虚拟线放在车道中间偏上 counted_ids set() car_count 0 def count_crossing(tracks, prev_pos): global car_count for track in tracks: x1, y1, x2, y2, track_id track cx, cy (x1 x2) / 2, (y1 y2) / 2 # 车辆中心点跨越虚拟线 if prev_pos.get(track_id) is not None: prev_y prev_pos[track_id][1] if prev_y line_y cy or prev_y line_y cy: if track_id not in counted_ids: car_count 1 counted_ids.add(track_id) prev_pos[track_id] (cx, cy)逻辑说明prev_pos保存上一帧每个 ID 的中心点当前帧中心点和上一帧中心点分别位于虚拟线两侧就判定为跨线。用两个方向的判定条件是为了让车辆反向行驶时也能正确计数。参数说明line_y的位置直接影响计数准确性放太靠近检测框出现的位置画面底部车辆刚出现时中心点已经跨线漏计放太高车辆还没完全进入视野就被截停造成重复计数。摄像头固定后先录制一段 5 分钟视频用带时间戳的帧逐帧检查虚拟线位置再定稿。4.3 逆行、违停、拥堵基于轨迹的业务逻辑拆解轨迹串起来之后交通违章判定就是纯业务逻辑。逆行判断一辆车的轨迹方向向量和车道允许方向夹角超过 90 度就判定逆行。违停判断轨迹 ID 持续 30 帧以上位移小于阈值。拥堵判断区域内的平均速度低于设定值且车辆密度超过阈值。这块代码不复杂但需要注意单位换算def calc_speed(track, fps, px_per_meter): # track: 某 ID 最近两帧的 [cx, cy] x1, y1 track[-2] x2, y2 track[-1] pixel_dist np.hypot(x2 - x1, y2 - y1) return pixel_dist / px_per_meter * fps # 单位m/s def detect_wrong_way(speed_vec, lane_dir): # speed_vec 可以取连续两帧的位移向量 cos_angle np.dot(speed_vec, lane_dir) / ( np.linalg.norm(speed_vec) * np.linalg.norm(lane_dir)) return cos_angle -0.1 # 夹角超过约 95 度即为逆行fps取视频实际帧率而不是设定帧率——很多监控视频标称 25fps实际存储时掉到 20速度计算会系统性偏快 20%。px_per_meter需要标定找到画面里一段已知真实长度的道路比如车道虚线长度 6 米量出像素长度相除。这个值在画面不同位置是不一样的摄像头有俯仰角时尤其明显严格做法是只对 ROI 区域内取平均值。逆行判定里设置cos_angle -0.1而不是 0是留出 5 度左右的容差避免车辆轻微变道被误判。5. 落地避坑与排查从「能跑」到「稳定跑」的 5 条血泪记录5.1 现象检测框乱跳ID 频繁切换刚把 YOLOv7 和 DeepSORT 接起来最容易看到的效果是车头刚出画面再回来 ID 就变了一个车在 3 秒内被分配了 5 个 ID。原因通常不是算法坏了而是min_conf0.3太低——夜间或逆光下置信度低的误检框被送进跟踪器匹配矩阵被大量低质量检测污染。解决把min_conf提到 0.5同时把n_init从 3 改成 3 不变但检查max_age是否过大这两步能消掉六成 ID 切换问题。真正顽固的 ID 切换来自 ReID 特征太弱就得回到 3.3 节换更强的 ReID 网络。5.2 现象白天识别率高雨天夜间断崖下跌这是交通检测的通病跟源码包无关是训练数据偏置。YOLOv7 的预训练权重在 COCO 上见过大量白天晴天样本雨天/夜间的车辆样本稀少。解决思路分两路一是数据增强在train.py里打开--augment并混入 mosaic、mixup让模型看到更多背景扰动二是针对性补数据从公开夜间车辆数据集抽几百张夜间图和现有训练集混合后微调。注意别整批重训用--weights yolov7.pt --freeze 50冻结前 50 层只训头数据量小时更稳。5.3 现象车流量计数比人工数偏大计数偏大九成来自重复计数。虚拟线法的典型错误线画在画面底部车辆刚出现时中心点已在线的另一侧但跟踪器还没确认轨迹前 3 帧是 unconfirmed 状态等到轨迹确认时中心点已经再次跨线触发第二次计数。解决把虚拟线往画面中间挪避开前后 50 帧内可能反复横跳的热区同时计数逻辑里加一个last_count_frame记录同一 ID 判定跨线后进入 10 帧冷却期避免卡在线上抖动触发多次计数。5.4 现象GPU 利用率只有 25%帧率还不如 CPU 快先查是不是每帧都在做预处理letterbox、numpy转 tensor、颜色通道转换这些如果放在 Python 层做GPU 每帧要等 CPU利用率必然上不去。解决把预处理管线改成异步或者用torch.cuda.Stream把数据拷贝和推理重叠再查是否用了固定尺寸推理而没有做 batch 推理——交通场景一帧里同时有几十辆车batch1 显然浪费把连续几帧拼成一个 batch 再用吞吐能涨一倍以上。最后检查torch.backends.cudnn.benchmark True场景不变时让 cuDNN 自动选最优卷积算法。5.5 现象CPU 机器上跑 YOLOv7-tiny 还是卡成 PPT有些毕设机器没有独显这时 Notion 是不要硬跑.pt转 ONNX 后换 ONNX Runtime 的 CPU 执行器再把输入分辨率降到 416通常能从 5fps 提到 12fps 左右。还不够就上 INT8 量化——但量化后检测精度会掉只对 detect 头里的卷积做量化保留 NMS 在浮点。注意export.py导出的 ONNX 默认包含原始 NMS 节点去重后转 INT8 时 NMS 层容易不支持量化干脆导出时不带 NMS用 Python 侧cv2.dnn.NMSBoxes替代。这个改法能把帧率推到 20fps 上下代价是 CPU 占用接近拉满。6. 进阶验证TensorRT 加速、速度估计与 ROI 裁剪技巧源码跑通、业务逻辑稳定后剩下的工作全是性能优化。最容易出效果的是上 TensorRT用trtexec --fp16 --minShapesimages:1x3x640x640 --optShapesimages:4x3x640x640构建 engine加载时用context.execute_async_v2绑定显存实测单路 1080p 视频可以跑到 50fps 以上。注意engine文件绑 CUDA 版本和显卡算力换机器就重新构建别把.engine当模型文件拷贝。速度估计的进阶做法不依赖标定用 DeepSORT 卡尔曼滤波里的vx, vy状态量它就是帧间速度的平滑值配合车道虚线的实际长度做分段标定比纯像素换算稳定得多。一个实用的 ROI 裁剪技巧是监控画面里真正有车的区域往往只占三分之一把帧先按 ROI 裁剪再送进 YOLOv7 检测既减少误检又提高帧率。我现在的习惯是先把摄像头架高让视野里的车尽量以俯视角度出现减少遮挡导致的 ID 切换再把虚拟线放在画面 60% 高度位置计数和速度估计都稳定很多。这一步看起来小却能省下后续调参的绝大部分时间希望帮到你。本文还有配套的精品资源点击获取 YOLOv7+DeepSORT智慧交通系统源码解析：从车辆检测到车流统计
简介基于YOLOv7与Deepsort的智慧交通系统项目实践资源面向计算机视觉学习者、智慧交通方向开发者以及需要完成课程设计或毕业设计的高校学生可有效解决从零搭建目标检测与多目标跟踪系统的技术门槛。资源包共17个文件以Python源码脚本和PNG/JPEG效果图为主其中源码实现从模型调用到跟踪输出的完整流程图片展示不同交通场景下的运行效果整体压缩包8.15MB体积紧凑便于直接下载与查阅。目前已有213人学习下载适合作为课程项目、算法验证或竞赛参考。内容包含实际可运行的YOLOv7Deepsort工程代码、配套教程说明与效果图表可帮助读者理解车辆/行人检测、特征提取、轨迹关联等关键环节的工程落地细节并在此基础上扩展车流量统计、违章检测、智能调度等智慧交通应用。1. 一套能跑的智慧交通系统源码到底解决了什么问题一个学弟拿 YOLOv5 跑通车辆检测后过来问我“框是出来了但我怎么知道画面里那辆白色 SUV 停了几秒”这就是从目标检测到智慧交通系统的分水岭检测只回答“每一帧里有什么”而智慧交通要回答“这辆车是谁、从哪来、到哪去、停了多久”。基于 YOLOv7 和 DeepSORT 的智慧交通系统做的就是这套串联工作——YOLOv7 负责把车辆、行人、非机动车从画面里框出来DeepSORT 负责给每个框一个身份 ID 并追着它走完整个视野。这两年人工智能正从尝鲜工具变成日常帮手交通视频分析是落得最实的场景之一。源码包里装的不是某个单独模型而是一条从检测、跟踪到车流统计、违章判别的完整链路。适合拿来当人工智能大作业、毕设选题也适合已有检测模型但缺跟踪层和业务逻辑的从业者做二次开发。这一篇就把这条链路拆开原理讲透参数给全踩坑记录逐条写。2. YOLOv7 作检测引擎为什么选它以及部署前必须搞懂的三个原理2.1 E-ELAN 与重参数化YOLOv7 的算力账怎么算YOLOv7 在 2022 年发布时打的就是“精度与速度兼顾”这张牌直到今天仍是智慧交通项目里出现频率最高的检测器之一。核心结构叫 E-ELANExtended Efficient Layer Aggregation Network做的事很直白把 feature map 按通道拆成几组每组做不同卷积再跨层拼接让梯度在深层网络里有多条路径回传。翻译成落地语言就是——同样的参数量梯度不消失训练更稳小目标远处车辆不容易被丢掉。重参数化是第二个关键点。训练时网络里并了好几路卷积分支推理前把它们合并成一条单路卷积。数学上就是卷积的可加性两个同尺寸卷积核作用于同一输入结果等于把卷积核相加后再做一次卷积。YOLOv7 的RepConv在训练时是 3×3 加 1×1 加分支的复合结构导出权重时合并成单 3×3推理速度立刻上去一截。很多新手在export.py里看到模型结构变了就疑惑是不是代码写错了——那是正常现象重参数化模块在train.py里活着在deploy.py里就合并了。2.2 aux head 与动态标签分配辅助头在训练时做了什么YOLOv7 的辅助头aux head是最容易误解的设计。训练时它多算一路 loss让浅层特征也收到梯度信号推理时辅助头直接剪掉只保留 lead head 输出。所以你在训练日志里看到aux_loss在降不要试图在推理代码里找它——它只在反向传播里存在。对应到命令行参数是--no-aug之外的--no-aux如果你想用 YOLOv7 做纯检测微调且数据集很小开着 aux 容易过拟合可以关掉赌一把更快收敛。动态标签分配是另一个容易被忽略的点。YOLOv7 用 coarse-to-fine 两级分配先粗筛候选框再精细匹配避免一个 GT 框被多个标签重复指派、也避免高质量预测被低质量匹配拖累。这带来的调试习惯是训练完看mAP0.5之外务必看mAP0.5:0.95的曲线形态。交通场景里远处车辆往往只有十几个像素如果 0.5 阈值下精度高但 0.95 下掉得厉害说明框定位不稳。2.3 从 .pt 到 TensorRT三种部署方式的取舍拿到仓库里现成的训练好的 YOLOv7 权重部署路径有三条直接用 PyTorch 推理.pt文件加载改起来最快但显存占用高、延迟不稳。转 ONNX ONNX Runtimeexport.py --grid --simplify导出CPU/GPU 都能跑适合快速验证。TensorRT FP16/INT8转型速度最快但依赖 NVIDIA GPU 和 CUDA 版本engine文件和显卡强绑定换卡要重构建。我一般先用 ONNX 跑通全流程确认业务逻辑没问题再上 TensorRT。这个顺序能避开“模型转换后行为变了却分不清是跟踪器还是转换器的问题”。下面是最小推理片段跑通它再谈后续import cv2 import torch # 加载 YOLOv7 训练好的权重构建模型 model torch.hub.load(WongKinYiu/yolov7, custom, yolov7.pt, trust_repoTrue) model.eval() frame cv2.imread(street.jpg) # BGR 读入 # letterbox 保持宽高比缩放避免目标被拉伸变形 from utils.general import letterbox boxed, ratio, (dw, dh) letterbox(frame, new_shape640, autoFalse) tensor torch.from_numpy(boxed[:, :, ::-1].transpose(2, 0, 1)).float() / 255.0 tensor tensor.unsqueeze(0).to(next(model.parameters()).device) with torch.no_grad(): pred model(tensor)[0] # [batch, num_anchors, 85]这段代码的关键在letterbox不做这一步检测框会系统性偏移。new_shape640是 YOLOv7 默认训练尺寸改小到 416 能提速但小目标召回率下降autoFalse强制保证宽高都能被 stride 整除避免维度对齐错误。pred的最后一维 85 是 4 个框坐标、1 个置信度、80 类 COCO 得分你后续要接 DeepSORT就得先把这些原始预测经 NMS 转成(x1, y1, x2, y2, score, class_id)的列表。3. DeepSORT 作跟踪层参数不是玄学是卡尔曼滤波和级联匹配的配合3.1 跟踪的本质检测框如何变成一条连续轨迹DeepSORT 在智慧交通里的角色是把 YOLOv7 输出的零散检测框变成有编号的轨迹。它的内部有两套账本一套是卡尔曼滤波维护每个目标的位置和速度另一套是 ReID 特征库记录每个目标的外观向量。卡尔曼滤波的状态向量是 8 维(cx, cy, r, h, vx, vy, vr, vh)前四个是中心点、宽高比、高度后四个是对应速度。每帧检测进来卡尔曼滤波先拿上一帧的状态做一次运动预测得到预测框再和当前帧实际检测框做匹配匹配上用检测框修正预测没匹配上就继续在预测状态里外推。外观匹配用的是余弦距离DeepSORT 里每个检测框会过一个 ReID 网络输出一个 128 维特征向量轨迹的历史特征存成一个集合新检测框的特征和这个集合的最近距离就是它的“长相分”。运动匹配管着“你下一步该出现在哪”外观匹配管着“你是不是之前那辆车”两个信号叠加成代价矩阵再做匈牙利匹配。这就是为什么 DeepSORT 在车辆遮挡后还能把 ID 找回来——运动不行了靠长相兜底。3.2 五个必调参数max_dist、max_iou_distance、max_age、n_init、min_confDeepSORT 的公开实现里参数都集中在tracker.py和deep_sort_app.py顶部下面这张表是车辆场景下的推荐初值参数推荐值作用调参方向max_dist0.2外观余弦距离阈值超过则拒绝匹配车辆 ReID 相似度高改大到 0.3 能减少 ID 切换改小更严格但易丢max_iou_distance0.7IoU 匹配门槛低于则视为不重叠遮挡严重时改大到 0.8max_age70轨迹丢失后最多存活帧数出视野后仍要计数就加大车辆横穿十字路口需要 90n_init3连续 3 帧命中才确认轨迹防误检导致幽灵轨迹改大能滤噪但延迟确认min_conf0.5检测置信度过滤夜间漏检时降到 0.4但会引入误检需搭配 NMS 调整每次只改一个参数记录确认轨迹数和 ID 切换次数两个指标。max_age加大的代价是车辆早就离开画面轨迹还在内存里存活计费逻辑如果把轨迹首次出现当成一次计数就会把同一辆车在画面两端重新入场重复计两次。3.3 deepsort 改进ReID 特征和检测质量的耦合网上流传的各类“deepsort 改进”绕不开三个地方ReID 网络替换、匹配策略改造、检测框质量耦合。最容易见效的是第一个——把原版ckpt.t7的 ReID 网络换成针对车辆数据集微调过的轻量模型比如基于 ResNet18 的输出 256 维特征再 L2 归一化。车辆和行人不同同品牌同型号的车可能外观几乎一样128 维特征根本不够区分换成 256 维后余弦距离的分辨力显著提升。第二个常见改造是给级联匹配加“检测置信度门控”高置信度检测框优先匹配低置信度框只能匹配已确认轨迹。原版 DeepSORT 的min_conf是前置过滤把它挪进代价矩阵里让 0.4 置信度的框有机会参与匹配但不污染新建轨迹对夜间场景友好。第三个改造不碰算法——直接把 YOLOv7 的检测框做一次xyxy到cxcywh的格式转换时保留原始置信度并传给tracker.update避免在封装层丢掉这个信息。接入跟踪器的核心代码是这样的from deep_sort import DeepSort # 参数对应上表车辆场景初值 tracker DeepSort(max_dist0.2, max_iou_distance0.7, max_age70, n_init3, nn_budget100) def process_frame(frame, results): # results: YOLOv7 输出的 [x1, y1, x2, y2, score, class_id] dets [] for det in results: if det[4] 0.5: # min_conf 过滤 dets.append([det[0], det[1], det[2], det[3], det[4]]) if len(dets) 0: return tracker.update([], frame) return tracker.update(dets, frame) # 返回 [x1, y1, x2, y2, track_id]nn_budget100是 ReID 特征库存放的历史上限超过后会随机丢掉旧特征。车辆在画面里走得久、特征增长快这个值设太小会让外观信息丢失设太大则内存涨得快100 对单路口场景合理。tracker.update的第二个参数是原始帧图像DeepSORT 的 ReID 网络需要在这里重新提特征意味着每帧多一次前向推理——这也是 CPU 机器上 DeepSORT 比检测器还慢的常见原因。4. 把源码跑起来的完整链路数据准备、训练、业务逻辑4.1 VOC 格式转 YOLO 格式转换脚本与四个边界坑源码仓库里通常自带标注好的交通数据集或者给了 UA-DETRAC 之类的公开数据集说明。拿到手第一步是把标注统一成 YOLO 格式每张图对应一个.txt每行class_id cx cy w h坐标是相对于宽高的比例值。如果数据集是 VOC 的.xml标注就得先转一次import xml.etree.ElementTree as ET import os def voc_to_yolo(xml_path, out_dir, class_map): tree ET.parse(xml_path) root tree.getroot() size root.find(size) w, h int(size.find(width).text), int(size.find(height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_map: # 只保留需要的类别 continue box obj.find(bndbox) x1, y1 float(box.find(xmin).text), float(box.find(ymin).text) x2, y2 float(box.find(xmax).text), float(box.find(ymax).text) # YOLO 格式要求中心点和宽高全部除以图像尺寸做归一化 cx (x1 x2) / 2 / w cy (y1 y2) / 2 / h bw (x2 - x1) / w bh (y2 - y1) / h lines.append(f{class_map[name]} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) with open(os.path.join(out_dir, os.path.basename(xml_path).replace(.xml, .txt)), w) as f: f.write(\n.join(lines))四个边界坑每个都踩过class_id必须从 0 开始连续编号。.xml里类名是字符串转的时候要手工建class_map漏一个类就会导致所有后续类别偏移一位训练时 mAP 诡异下降。框坐标不能越界。部分标注工具的x2/y2会标到图像外直接除会产生大于 1 的宽高比YOLOv7 训练时会警告并丢弃这些框先做max(0, min(w, x2))钳制。训练列表文件里的路径不能带绝对路径前缀。仓库自带的train.txt常是/home/user/...开头换机器后要么改路径要么统一改成相对路径再训练。图片和标注文件名必须完全一致不能出现同一张图有两个标注文件或一个标注落在空图上——训练脚本会静默跳过不配对的数据让你误以为是模型没训好。4.2 车流量计数虚拟线和轨迹 ID哪个更稳车流量统计是这个项目最核心的业务出口。两种常见做法一种是在画面上画一条虚拟线车辆中心点跨过这条线的瞬间计数另一种是轨迹 ID 首次出现时计数。虚拟线法稳在“物理意义直观”坏在跨线判定要处理方向车辆从左往右和从右往左都跨线同一个计数点不能只数一个方向。轨迹 ID 首帧计数不用管方向但视野边缘的误检会产生幽灵 ID计数虚高。我一般混合用以虚拟线为主计数轨迹 ID 只做去重兜底。import cv2 import numpy as np line_y 360 # 虚拟线放在车道中间偏上 counted_ids set() car_count 0 def count_crossing(tracks, prev_pos): global car_count for track in tracks: x1, y1, x2, y2, track_id track cx, cy (x1 x2) / 2, (y1 y2) / 2 # 车辆中心点跨越虚拟线 if prev_pos.get(track_id) is not None: prev_y prev_pos[track_id][1] if prev_y line_y cy or prev_y line_y cy: if track_id not in counted_ids: car_count 1 counted_ids.add(track_id) prev_pos[track_id] (cx, cy)逻辑说明prev_pos保存上一帧每个 ID 的中心点当前帧中心点和上一帧中心点分别位于虚拟线两侧就判定为跨线。用两个方向的判定条件是为了让车辆反向行驶时也能正确计数。参数说明line_y的位置直接影响计数准确性放太靠近检测框出现的位置画面底部车辆刚出现时中心点已经跨线漏计放太高车辆还没完全进入视野就被截停造成重复计数。摄像头固定后先录制一段 5 分钟视频用带时间戳的帧逐帧检查虚拟线位置再定稿。4.3 逆行、违停、拥堵基于轨迹的业务逻辑拆解轨迹串起来之后交通违章判定就是纯业务逻辑。逆行判断一辆车的轨迹方向向量和车道允许方向夹角超过 90 度就判定逆行。违停判断轨迹 ID 持续 30 帧以上位移小于阈值。拥堵判断区域内的平均速度低于设定值且车辆密度超过阈值。这块代码不复杂但需要注意单位换算def calc_speed(track, fps, px_per_meter): # track: 某 ID 最近两帧的 [cx, cy] x1, y1 track[-2] x2, y2 track[-1] pixel_dist np.hypot(x2 - x1, y2 - y1) return pixel_dist / px_per_meter * fps # 单位m/s def detect_wrong_way(speed_vec, lane_dir): # speed_vec 可以取连续两帧的位移向量 cos_angle np.dot(speed_vec, lane_dir) / ( np.linalg.norm(speed_vec) * np.linalg.norm(lane_dir)) return cos_angle -0.1 # 夹角超过约 95 度即为逆行fps取视频实际帧率而不是设定帧率——很多监控视频标称 25fps实际存储时掉到 20速度计算会系统性偏快 20%。px_per_meter需要标定找到画面里一段已知真实长度的道路比如车道虚线长度 6 米量出像素长度相除。这个值在画面不同位置是不一样的摄像头有俯仰角时尤其明显严格做法是只对 ROI 区域内取平均值。逆行判定里设置cos_angle -0.1而不是 0是留出 5 度左右的容差避免车辆轻微变道被误判。5. 落地避坑与排查从「能跑」到「稳定跑」的 5 条血泪记录5.1 现象检测框乱跳ID 频繁切换刚把 YOLOv7 和 DeepSORT 接起来最容易看到的效果是车头刚出画面再回来 ID 就变了一个车在 3 秒内被分配了 5 个 ID。原因通常不是算法坏了而是min_conf0.3太低——夜间或逆光下置信度低的误检框被送进跟踪器匹配矩阵被大量低质量检测污染。解决把min_conf提到 0.5同时把n_init从 3 改成 3 不变但检查max_age是否过大这两步能消掉六成 ID 切换问题。真正顽固的 ID 切换来自 ReID 特征太弱就得回到 3.3 节换更强的 ReID 网络。5.2 现象白天识别率高雨天夜间断崖下跌这是交通检测的通病跟源码包无关是训练数据偏置。YOLOv7 的预训练权重在 COCO 上见过大量白天晴天样本雨天/夜间的车辆样本稀少。解决思路分两路一是数据增强在train.py里打开--augment并混入 mosaic、mixup让模型看到更多背景扰动二是针对性补数据从公开夜间车辆数据集抽几百张夜间图和现有训练集混合后微调。注意别整批重训用--weights yolov7.pt --freeze 50冻结前 50 层只训头数据量小时更稳。5.3 现象车流量计数比人工数偏大计数偏大九成来自重复计数。虚拟线法的典型错误线画在画面底部车辆刚出现时中心点已在线的另一侧但跟踪器还没确认轨迹前 3 帧是 unconfirmed 状态等到轨迹确认时中心点已经再次跨线触发第二次计数。解决把虚拟线往画面中间挪避开前后 50 帧内可能反复横跳的热区同时计数逻辑里加一个last_count_frame记录同一 ID 判定跨线后进入 10 帧冷却期避免卡在线上抖动触发多次计数。5.4 现象GPU 利用率只有 25%帧率还不如 CPU 快先查是不是每帧都在做预处理letterbox、numpy转 tensor、颜色通道转换这些如果放在 Python 层做GPU 每帧要等 CPU利用率必然上不去。解决把预处理管线改成异步或者用torch.cuda.Stream把数据拷贝和推理重叠再查是否用了固定尺寸推理而没有做 batch 推理——交通场景一帧里同时有几十辆车batch1 显然浪费把连续几帧拼成一个 batch 再用吞吐能涨一倍以上。最后检查torch.backends.cudnn.benchmark True场景不变时让 cuDNN 自动选最优卷积算法。5.5 现象CPU 机器上跑 YOLOv7-tiny 还是卡成 PPT有些毕设机器没有独显这时 Notion 是不要硬跑.pt转 ONNX 后换 ONNX Runtime 的 CPU 执行器再把输入分辨率降到 416通常能从 5fps 提到 12fps 左右。还不够就上 INT8 量化——但量化后检测精度会掉只对 detect 头里的卷积做量化保留 NMS 在浮点。注意export.py导出的 ONNX 默认包含原始 NMS 节点去重后转 INT8 时 NMS 层容易不支持量化干脆导出时不带 NMS用 Python 侧cv2.dnn.NMSBoxes替代。这个改法能把帧率推到 20fps 上下代价是 CPU 占用接近拉满。6. 进阶验证TensorRT 加速、速度估计与 ROI 裁剪技巧源码跑通、业务逻辑稳定后剩下的工作全是性能优化。最容易出效果的是上 TensorRT用trtexec --fp16 --minShapesimages:1x3x640x640 --optShapesimages:4x3x640x640构建 engine加载时用context.execute_async_v2绑定显存实测单路 1080p 视频可以跑到 50fps 以上。注意engine文件绑 CUDA 版本和显卡算力换机器就重新构建别把.engine当模型文件拷贝。速度估计的进阶做法不依赖标定用 DeepSORT 卡尔曼滤波里的vx, vy状态量它就是帧间速度的平滑值配合车道虚线的实际长度做分段标定比纯像素换算稳定得多。一个实用的 ROI 裁剪技巧是监控画面里真正有车的区域往往只占三分之一把帧先按 ROI 裁剪再送进 YOLOv7 检测既减少误检又提高帧率。我现在的习惯是先把摄像头架高让视野里的车尽量以俯视角度出现减少遮挡导致的 ID 切换再把虚拟线放在画面 60% 高度位置计数和速度估计都稳定很多。这一步看起来小却能省下后续调参的绝大部分时间希望帮到你。本文还有配套的精品资源点击获取