简介面向计算机专业毕业设计及课程项目的多目标跟踪算法源码包基于YOLOv8与DeepSORT实现提供可运行的完整工程。适合正在筹备毕设、期末大作业或需要实战练习的计算机相关学生也适用于目标检测与多目标跟踪方向的入门与进阶实践。压缩包共696个文件大小47.14MB包含194个Python源码、56个YAML配置文件、162个PYC缓存以及大量PNG图片资源另有界面UI、QSS样式、文档手册和演示GIF等从模型配置、算法逻辑到界面展示均有覆盖项目经调试确保可运行。包内附使用手册、演示录屏及测试图片方便对照理解检测与跟踪流程可直接基于源码二次开发或作为毕业设计主体成果。无论用于本科毕设答辩还是课题研究均能提供直接可用的工程基础。目前已有802人学习下载是快速落地目标跟踪项目的实用参考。1. 多目标跟踪算法把检测变成时序任务YOLOv8DeepSORT的分工多目标跟踪算法MOTMulti-Object Tracking和单帧目标检测的区别一句话就能讲清检测回答“这一帧里谁在哪儿”跟踪回答“这一帧的人和上一帧的人是不是同一个人”。标题里的 YOLOv8DeepSORT 组合是目前源码公开、复现成本最低的 MOT 方案之一——YOLOv8 负责把每一帧变成一组带置信度的检测框DeepSORT 负责给这些框分配 ID 并跨帧维护轨迹。适合交通监控、行人计数、工业巡检这类“不能漏跟”的场景也适合拿来做毕业设计或面试项目。对 IT 从业者来说这套组合更实用的地方在于检测器可以换成自己训练的任何模型跟踪部分的代码不需要重写。2. 搭建可复现的YOLOv8DeepSORT环境检测框怎么喂给跟踪器网上能搜到大量 YOLOv8DeepSORT 源码包但解压之后各有各的依赖版本和目录习惯。不要被“项目源码”四个字带偏先把最小闭环跑通检测器输出 → 转成标准检测框结构 → 交给跟踪器 → 画 ID 框。这一步通了剩下才是调参数。2.1 为什么常用DeepSORT而不是ByteTrack或BoT-SORTDeepSORT 是 SORT 的延续SORT 只用卡尔曼滤波加匈牙利匹配一遇到遮挡就丢 IDDeepSORT 在匹配代价里加入了外观特征Re-ID embedding用一个小型卷积网络把检测框内的目标编码成特征向量再和轨迹历史特征做余弦相似度。这解决了“目标被挡几帧后重新出现”的经典场景。ByteTrack 的思路完全不同它把低置信度检测框也保留下来参与匹配在检测器很强的场景下效果好而且几乎没有 Re-ID 网络开销在瑞芯微 RK3588、Jetson 这类边缘设备上更省资源。BoT-SORT 又额外引入了相机运动补偿CMC适合摄像头抖动厉害的室外场景。但单论落地资料量、调试案例数和“换检测器不动跟踪器”的兼容性DeepSORT 仍然是最稳的选择。标题既然锁定了 YOLOv8DeepSORT就按这个组合往下走。2.2 最小依赖安装命令与版本搭配源码包里的 requirements.txt 各家写得不一样但核心依赖就三个ultralytics、deep-sort-realtime、opencv-python。deep-sort-realtime 是 PyPI 上一个维护较新的 DeepSORT 封装比老牌的 deep_sort_pytorch依赖旧版 torch容易在 Ubuntu 20.04 上编译失败更适合新项目。# 建议先建独立环境python 3.9 或 3.10 均可 conda create -n mot python3.10 -y conda activate mot pip install ultralytics deep-sort-realtime opencv-python # CPU 机器上想先验证逻辑装 CPU 版 torch 就够 pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu这里要注意deep-sort-realtime 在 pip 安装时会把 torch、opencv 作为依赖自动带上如果显卡驱动和 CUDA 版本不匹配建议先把 torch 单独装好再装 deep-sort-realtime 并加上--no-deps避免依赖冲突。装完后验证一下 import# 验证核心包能否正常加载 from ultralytics import YOLO from deep_sort_realtime.deepsort_tracker import DeepSort model YOLO(yolov8n.pt) # 首次运行会自动下载权重 print(YOLOv8 ready)yolov8n.pt是最小的 nano 版本官方 COCO 权重约 6MB适合先跑通流程确定要用于生产后再换yolov8s.pt或自训练权重。deep-sort-realtime 的 import 路径是固定的很多教程里写from deep_sort import DeepSort那是旧项目结构按这个 import 会报 ModuleNotFoundError。2.3 检测框转跟踪框一份可直接跑的最小串联代码先明确一个关键点DeepSORT 接收的检测框格式和 YOLOv8 的输出格式不一样。YOLOv8 的results对象里是box.xyxy、box.conf、box.cls而 DeepSORT 的update_tracks需要([x1, y1, x2, y2], conf, cls)三元组组成的列表。这个转换是整条链路最容易写错的地方。# track.py: YOLOv8 检测 DeepSORT 跟踪的最小闭环 import cv2 from ultralytics import YOLO from deep_sort_realtime.deepsort_tracker import DeepSort # 检测端权重路径可换成自己训练出的 best.pt detector YOLO(yolov8n.pt, taskdetect) # 跟踪端参数先按经验值起步后面逐个调 tracker DeepSort( max_age30, # 轨迹失联多少帧后删除 n_init3, # 连续匹配多少帧后确认为正式轨迹 max_cosine_distance0.2, # 外观特征余弦距离上界 nn_budget100, # Re-ID 特征队列长度 max_iou_distance0.7, # 未确认轨迹的 IoU 门控 max_dist0.2, # 马氏距离门控阈值 embeddermobilenet, # Re-ID 网络可用 torchreid 换更强的 halfTrue # GPU 推理用 FP16CPU 必须改 False ) cap cv2.VideoCapture(0) # 0 是 USB 摄像头可换视频文件路径 while cap.isOpened(): ok, frame cap.read() if not ok: break # YOLOv8 推理返回的是封装好的 Results 对象 results detector(frame, conf0.4, iou0.5, verboseFalse) # 把检测结果转成 deep-sort-realtime 需要的 list dets [] for r in results: for box in r.boxes: x1, y1, x2, y2 box.xyxy[0].tolist() conf box.conf.item() cls int(box.cls.item()) dets.append(([x1, y1, x2, y2], conf, cls)) # 跟踪器内部完成卡尔曼预测、级联匹配、轨迹更新 tracks tracker.update_tracks(dets, frameframe) for t in tracks: if not t.is_confirmed(): continue # 未确认轨迹不画框减少闪烁 x1, y1, x2, y2 t.to_ltrb() cv2.rectangle(frame, (int(x1), int(y1)), (int(x2), int(y2)), (0, 255, 0), 2) cv2.putText(frame, fID-{t.track_id}, (int(x1), int(y1) - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2) cv2.imshow(YOLOv8DeepSORT, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()代码里conf0.4是检测阶段的置信度阈值控制进入跟踪器的误检数量iou0.5是 NMS 阈值控制重叠框的保留策略。is_confirmed()对应 DeepSORT 里的 n_init 机制新检测框并不立即获得正式 ID而是先做 3 帧连续匹配确认是稳定目标后才对外暴露防止单帧误检污染轨迹。to_ltrb()返回的是 left-top-right-bottom 格式的坐标和 YOLOv8 的 xyxy 格式一致。提示CPU 环境务必把halfTrue改为halfFalse否则 Re-ID 网络在 CPU 上会因 FP16 算子不支持而报错或明显变慢。2.4 换自训练检测器时跟踪代码一行都不用动如果目标不是通用 80 类而是行人、车辆或某一类工业缺陷训练自己的 YOLOv8 数据集后把权重路径换成runs/detect/train/weights/best.pt即可。自训练模型的nc会改变但box.xyxy的输出格式不变跟踪器感知不到类别数量。对 YOLOv8 的 C2f 结构做过替换、加过 GFPN 或调整过损失函数的改进版本只要仍走 Ultralytics 的推理接口下游跟踪逻辑也完全不受影响。这也是这套架构在生产里最让人省心的地方检测端随便优化跟踪端稳定不动。3. DeepSORT的关联机制卡尔曼预测、外观距离与级联匹配怎么配合很多人把 DeepSORT 当成“目标跟踪算法”直接用却没搞清楚它内部的三个核心组件卡尔曼滤波器、Re-ID 特征提取器、级联匹配。这三个组件共同决定了 ID 会不会跳变ID Switch也决定了那些看起来没意义的参数到底在管什么。3.1 状态空间与卡尔曼滤波观测是4维状态是8维DeepSORT 里每个轨迹维护一个 8 维状态向量[cx, cy, r, h, vx, vy, vr, vh]前四维是检测框的中心点 x、中心点 y、宽高比 r、高度 h后四维是对应的速度。卡尔曼滤波在这里做两件事预测轨迹在当前帧可能出现的位置再用当前帧的检测结果修正预测。运动模型默认是匀速直线观测模型直接把 8 维状态投影到 4 维测量空间。为什么不用加速度模型目标跟踪的帧间隔通常是 30ms 到 100ms在这个时间尺度上行人或车辆的运动近似线性引入二阶项反而会增加噪声也会让卡尔曼增益的调参更麻烦。边缘部署时卡尔曼滤波本身只是几个矩阵乘法开销很小瓶颈几乎都在 Re-ID 网络和检测器上。实际工程里要关注的不是卡尔曼公式本身而是“预测位置和实际检测位置的偏差”怎么度量。DeepSORT 用的是马氏距离d1(i, j) (d_j - y_i)^T * S_i^{-1} * (d_j - y_i)其中y_i是轨迹 i 的预测观测位置d_j是检测框 j 的位置S_i是预测协方差矩阵。马氏距离相比欧氏距离的优势是考虑了协方差相当于在不同方向上给距离做了归一化。这个值超过一定阈值就认为“检测框不可能属于这条轨迹”直接跳过匹配。原论文里取四维卡方分布的 95% 分位点约 9.4877这就是max_dist参数在多数实现里默认 0.2 左右的原因。3.2 外观距离与代价合并马氏距离管能不能余弦距离管像不像只用马氏距离的话遇到遮挡或目标靠近时很容易串 ID。DeepSORT 的改进在于引入第二个代价外观距离。每个检测框经过 Re-ID 网络得到一个特征向量f_j每条轨迹保存最近若干帧的特征集合R_i外观距离定义为d2(i, j) min { 1 - f_i^T * f_j | f_i in R_i }这里取的是“轨迹历史特征中与当前检测最相似的那个”而不是平均特征。这样做的原因是目标在运动过程中外观会连续变化比如行人转身最近几帧里总有和当前姿态接近的特征。最终匹配代价是两者的加权c(i, j) λ * d1(i, j) (1 - λ) * d2(i, j)DeepSORT 原论文和多数开源实现里把λ设为 0即只使用外观距离参与排序马氏距离退化为门控条件。理解这一点很重要max_dist限制的是“运动上允许多远的匹配”max_cosine_distance限制的是“外观上允许多像才算匹配”。摄像头视角固定时max_dist可以放松目标外观相似度高比如统一工服的人员时max_cosine_distance要收紧。参数默认值作用调参建议max_dist0.2马氏距离门控阈值决定运动预测和检测位置的允许偏差摄像头抖动大时调到 0.3~0.4max_cosine_distance0.2外观特征余弦距离上界目标外观区分度低时调到 0.15max_iou_distance0.7未确认轨迹关联时的 IoU 门控检测框不稳定时调大到 0.8max_age30轨迹失联保留帧数低速遮挡场景调到 45~60n_init3连续匹配帧数达到多少才确认轨迹误检多时调到 4~5nn_budget100每条轨迹保留的历史特征数内存紧张时降到 50这套参数直接影响的是“一个目标被打断后能否续上”。max_age调大能容忍更长时间的遮挡但代价是轨迹删除变慢ID 数量会虚高nn_budget调大历史特征更多样匹配更准但内存和计算量线性上涨。3.3 级联匹配的顺序先处理失联短的轨迹DeepSORT 与普通匈牙利匹配最大的不同是匹配顺序。如果所有轨迹同时参与匹配失联时间长的轨迹和失联时间短的轨迹会争夺同一个检测框而前者因为预测误差大更容易匹配错。级联匹配的做法是把所有已确认轨迹按time_since_update升序排列失联帧数越少越优先。对每一条轨迹用马氏距离和外貌距离计算与所有未匹配检测框的代价值并做门控。用匈牙利算法求解当前批次的最优匹配。匹配剩下的未确认轨迹和未匹配检测框用 IoU 关联。未匹配的检测框初始化新轨迹未匹配的轨迹time_since_update加一超过max_age就删除。这个顺序保证了“刚丢一帧的轨迹”优先找回“丢了几十帧的轨迹”最后才处理有效减少了长期失联轨迹的误匹配。如果源码包里看到的级联匹配实现没有按失联时间排序那基本是简化版ID Switch 会明显增多。4. 摄像头下的实战调参每帧只识别一次、ROI计数与硬件取舍跑通最小闭环之后真正会遇到的场景是接摄像头要么做进出人数统计要么做区域入侵报警要么做“某个目标经过一次只记录一次”的计数系统。这些需求都绕不开一个工程问题怎么让跟踪结果稳定地对外输出。4.1 视频源的三种接法与RTSP延迟处理# 方式1: USB 摄像头 cap cv2.VideoCapture(0) # 方式2: 本地视频文件 cap cv2.VideoCapture(test.mp4) # 方式3: RTSP 网络摄像头 cap cv2.VideoCapture(rtsp://192.168.1.64:554/stream1) # 降低解码缓冲减少延迟 cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)RTSP 流最常见的问题是延迟越来越大原因是 OpenCV 读到的是解码器缓冲里旧帧而cap.read()是同步阻塞的处理速度跟不上就会积压。常见做法是另开一个线程只做cap.read()把帧放进队列主线程负责检测和跟踪更简单的临时方案就是上面那行CAP_PROP_BUFFERSIZE, 1把缓冲压到最小代价是画面会有轻微的跳动感。注意这个属性不是所有摄像头驱动都支持设置后可以打印实际值确认是否生效。4.2 “经过时只识别一次”的实现检测去重和跟踪ID锁存是两回事这个需求对应的就是热词里那个“运动的物体经过摄像头只识别一次”。如果直接依赖检测结果同一目标在连续 30 帧里会被识别 30 次必须用跟踪 ID 做锁存。流程是预先画一条虚拟线或一个 ROI 区域当某个track_id第一次满足条件时触发计数并把该 ID 加入已计数集合之后同一 ID 再次出现直接跳过。# 基于上一节的跟踪循环加入单次计数逻辑 ROI_LINE_Y 480 # 虚拟线所在 y 坐标 counted_ids set() # 已计数 ID 集合 total_count 0 # 在遍历 tracks 的位置补上计数逻辑 for t in tracks: if not t.is_confirmed(): continue x1, y1, x2, y2 t.to_ltrb() cx, cy int((x1 x2) / 2), int((y1 y2) / 2) if cy ROI_LINE_Y and t.track_id not in counted_ids: counted_ids.add(t.track_id) total_count 1 print(fID-{t.track_id} crossed, total {total_count}) cv2.circle(frame, (cx, cy), 4, (0, 0, 255), -1)counted_ids集合必须用track_id做键不能用检测框或坐标。如果摄像头画面里目标近距离相互遮挡DeepSORT 可能会给同一目标换新 ID新 ID 不在集合里就会重复计数。这时候要配合max_age和max_cosine_distance调整目标是让轨迹在遮挡后仍然能续上而不是简单调大计数集合。4.3 性能预算中端显卡与边缘设备怎么分配任务DeepSORT 的大部分耗时不在卡尔曼滤波而在 Re-ID 特征提取。一个 mobilenet 大小的 embedder 在 CPU 上跑一帧大约需要 15ms 到 25ms具体看分辨率和线程数。YOLOv8n 在 GTX 1660Ti 这类中端显卡上约 25ms 到 40ms1080pNMS 的耗时也会随着目标数量上升。整体帧率通常在 12 到 20 FPS 之间。设备检测部分跟踪部分可用性GTX 1660Ti / 1080pYOLOv8nFP16embedder 跑 CPU12~20 FPS够演示和轻量计数Jetson Orin NanoTensorRT FP16 版 YOLOv8nembedder 转 ONNX 上 GPU可跑实时注意 NMS 插件版本RK3588RKNN 版 YOLOv8nembedder 跑 CPU720p~800p 可用目标多时会掉帧如果单帧检测目标超过 20 个Re-ID 的 batch 推理可以合并成一次前向而不是逐个目标跑deep-sort-realtime 内部已经做了这个优化如果在源码包里看到的是 for 循环逐个提取特征的实现建议改成 batch 输入。Jetson 和 RK3588 上部署时检测部分通常换成 TensorRT 或 RKNN 格式跟踪部分保留原始 PyTorch 反而最简单因为跟踪器的计算量只占小头真正吃掉算力的是检测器和逐帧 NMS。5. ID-Switch怎么压轨迹状态缓冲与批量验证脚本多目标跟踪做得好不好的硬指标是 ID Switch 次数也就是一个真实目标被拆成多少个 ID。它不直接等于“算法坏了”但会直接拉胯计数准确率。最后的这部分给两个实用手段一个是工程上给 DeepSORT 补历史特征另一个是写一个小脚本量化 ID Switch。5.1 给特征库加短时缓冲弥补遮挡后的特征断层DeepSORT 的nn_budget只保留最近 100 帧的特征目标被长遮挡后重新出现时轨迹特征集里的内容可能已经偏离当前外观。常见做法是在外部额外维护一份轨迹特征历史# 在跟踪循环外维护一个特征缓冲 from collections import deque import numpy as np feature_history {} # 每次拿到 confirmed track 时手动把当前帧特征塞进队列 # 这里的 feat 可以来自 embedder 输出也可以用检测框内图像直方图降维 feature_history.setdefault(t.track_id, deque(maxlen60)).append(feat) def match_with_history(new_feat, track_id): 用历史特征计算平均相似度辅助判断 ID 是否续接 hist feature_history.get(track_id) if not hist: return 0.0 return np.mean([f new_feat for f in hist], axis0)这个做法不是 DeepSORT 官方流程但它在计数类项目里非常实用。原来的匹配只看最近特征加了外部缓冲后跨 30 帧以上的遮挡场景也能找回同一 ID。注意deque(maxlen60)控制了内存上界每帧往队列里塞的特征如果超过 512 维十多个轨迹同时存在也才几十 KB开销可以忽略。5.2 批量算轨迹断裂的验证脚本评估 ID Switch 不能靠肉眼盯画面先把跟踪结果落盘成 CSV再统计每个 ID 的时间轴断裂情况。# save_tracks.py: 把跟踪结果追加写入 CSV # 在遍历 tracks 的循环中加入 # with open(tracks.csv, a) as f: # f.write(f{frame_id},{t.track_id},{x1},{y1},{x2},{y2}\n)拿到 CSV 后用下面的脚本统计每个 ID 的断裂帧数import csv from collections import defaultdict gaps defaultdict(list) last_frame {} with open(tracks.csv) as f: for row in csv.reader(f): frame_id, tid int(row[0]), int(row[1]) if tid in last_frame: gap frame_id - last_frame[tid] - 1 if gap 0: gaps[tid].append(gap) last_frame[tid] frame_id for tid, g in sorted(gaps.items(), keylambda x: -len(x[1]))[:10]: avg_gap sum(g) / len(g) print(fID-{tid}: {len(g)} fragments, avg gap {avg_gap:.1f} frames)断裂次数多说明轨迹经常被打断要么是检测框连续漏检要么是 Re-ID 特征匹配不上。把断裂时刻的视频片段剪出来对齐看就能定位问题在检测端还是跟踪端若 gap 集中在遮挡区间优先提升 Re-ID 特征质量若 gap 散布在整段视频里先把检测置信度从 0.4 提到 0.5减少低质量检测框对跟踪队列的干扰。本文还有配套的精品资源点击获取