簡介面向計算機視覺方向畢業(yè)設(shè)計的一套完整目標跟蹤源碼將YOLOv9檢測與DeepSORT多目標跟蹤結(jié)合適合需要完成實時檢測跟蹤課題或?qū)W習多目標關(guān)聯(lián)算法的學生與開發(fā)者。壓縮包共8個文件約16.85MB含Python執(zhí)行腳本、Jupyter分步示例、類別映射表、依賴清單、環(huán)境配置與說明文檔及2個演示gif等便于快速搭建環(huán)境并查看運行效果。已有549人學習。源碼貫穿數(shù)據(jù)預(yù)處理、YOLOv9模型加載、卡爾曼濾波初始化、特征提取與相似度度量、逐幀跟蹤關(guān)聯(lián)及可視化后處理等關(guān)鍵環(huán)節(jié)配合Jupyter逐段演示可幫助理解檢測頭輸出如何進入跟蹤器、如何利用重識別特征抑制ID Switch等問題既能直接支撐畢業(yè)設(shè)計實驗也能作為深入掌握檢測與跟蹤工程化實現(xiàn)的練習項目。該組合方案在實時性與精度之間取得較好平衡可擴展到行人、車輛等常見目標的持續(xù)跟蹤場景。1. YOLOv9DeepSort目標跟蹤源碼先解釋為什么檢測和跟蹤要分開看做過視頻目標跟蹤的人多半都撞過這個畫面檢測框畫得挺準但同一個目標在連續(xù)幀里一會兒是ID 3過兩幀又變成ID 17剛穩(wěn)下來又消失。這不是檢測模型不行而是目標跟蹤這一段沒接通。這套畢業(yè)設(shè)計級的YOLOv9DeepSort Python源碼就是用來解決這個斷點的。它用YOLOv9做檢測前端逐幀出框DeepSort做后端把框關(guān)聯(lián)成連續(xù)軌跡包里object_tracking.py能直接跑視頻YOLOv9_DeepSORT.ipynb適合分段調(diào)試configs和coco.names都備齊conda環(huán)境一鍵建。適合畢業(yè)設(shè)計、視覺課設(shè)以及想快速驗證檢測加跟蹤效果的工程師。2. 檢測與跟蹤的分工邏輯YOLOv9出框DeepSort關(guān)聯(lián)成軌跡2.1 YOLOv9為什么適合當檢測前端先分清兩件事檢測回答這一幀里有什么跟蹤回答上一幀那個目標現(xiàn)在在哪兒。這套源碼選擇YOLOv9不是因為它名字新而是因為它在速度和漏檢率之間取的平衡點比較穩(wěn)。YOLOv9沒在前向推理路徑上堆太多冗余模塊而是把重心放在backbone的梯度流動上可編程梯度信息PGI在反向傳播時用輔助分支保住淺層特征GELAN塊又把跨層信息和高效計算拼到同一條鏈路。實際跑起來的感覺是人群、車輛這類COCO通用場景小目標不輕易丟低置信度的真實物體也有機會被下一幀撈回來這對跟蹤是友好的。因為跟蹤邏輯再順檢測漏一幀就得多等一個生命周期。工程上我更關(guān)心它的輸出形態(tài)YOLOv9的bbox帶著坐標和置信度直接能轉(zhuǎn)給跟蹤器。這個源碼里檢測結(jié)果被整理成統(tǒng)一列表跟蹤端不關(guān)心你是否換了檢測器。如果一個算法封裝得干凈檢測和跟蹤分別是兩個函數(shù)錯誤邊界清楚誰出問題一查就定位這是畢業(yè)設(shè)計最想要的工程結(jié)構(gòu)。很多人一上來就鉆進網(wǎng)絡(luò)結(jié)構(gòu)其實對于復現(xiàn)這套源碼先把出框和關(guān)聯(lián)拆開理解比背一堆結(jié)構(gòu)名有用得多。2.2 DeepSort的關(guān)聯(lián)鏈路預(yù)測、門控、匹配三步走DeepSort的核心鏈路可以拆成三步。第一步是卡爾曼濾波預(yù)測每個track維護一組狀態(tài)包括中心位置、長寬比、高度和對應(yīng)的速度新幀到來前先按線性運動模型推算出這個目標大概會在畫面的哪個位置。注意這一步預(yù)測的不是隨機猜測而是基于歷史狀態(tài)做時間更新所以當目標被遮擋、YOLO暫時沒有輸出時track還能靠預(yù)測值和后續(xù)觀測做關(guān)聯(lián)。第二步是門控新一幀的檢測框要和每個預(yù)測做比較運動馬氏距離離得太遠的先淘汰外觀上用ReID網(wǎng)絡(luò)抽出一個embedding跟這個track的歷史特征隊列做余弦距離比較。第三步是匹配DeepSort把馬氏距離和余弦距離加權(quán)成綜合代價矩陣交給匈牙利算法一次性分配分配不完的檢測先暫存連續(xù)多幀沒有被匹配的track判定為丟失。為什么不能只做IOU匹配因為目標一旦出畫再入畫位置跳變很大IOU直接歸零但ReID的外觀embedding還能保持相似。DeepSort訓練ReID時用了度量學習約束同一目標不同幀的embedding拉近不同目標互相推遠這是它比傳統(tǒng)顏色直方圖方法強的根本原因。這套源碼中ReID特征提取在helpers層預(yù)訓練權(quán)重一并提供通用場景直接沿用沒問題自定義數(shù)據(jù)集效果不好時需要把這個特征網(wǎng)絡(luò)換掉我在第4.3節(jié)講更換方法。還有個容易誤解的地方DeepSort并不是每幀都把檢測結(jié)果和所有track全量比較一遍。實際實現(xiàn)是先按已確認track和未確認track分兩級級聯(lián)匹配里先處理外觀穩(wěn)定、剛更新過的軌跡再去補匹配不上的。這樣做計算量小也能避免新track頻繁搶舊track的ID。幀循環(huán)里速度慢的瓶頸往往不在算法本身而在ReID推理和畫框。2.3 源碼包里的文件別只當檔案看這套資源里不是只有一段訓練腳本而是完整檢測跟蹤管道。拿到手建議先按職責拆開別只盯著一個主腳本。壓縮包內(nèi)文件可以對應(yīng)到幾個層次data是輸入素材位configs和coco.names管配置object_tracking.py和helpers是核心conda.yml和requirements.txt是環(huán)境。我習慣先畫一張文件職責表排查時好定位。文件/目錄在管道中的職責排查時看什么object_tracking.py主流程讀幀、檢測、跟蹤、畫框輸出報錯在上半段還是下半段YOLOv9_DeepSORT.ipynb分段演示檢測和跟蹤過程單段調(diào)試確認哪一層出問題helpers/DeepSort封裝、畫框和工具函數(shù)卡跟蹤邏輯就翻這里configs/模型路徑、尺寸、跟蹤參數(shù)調(diào)參基本都落在這層coco.namesCOCO 80類類別名稱類別和權(quán)重不匹配時先查它conda.yml / requirements.txt依賴清單雙軌環(huán)境問題先對齊這兩份文件名擺在這兒不是讓你背而是為了報錯時不慌。比如哪天運行object_tracking.py時提示找不到某個配置優(yōu)先看configs里路徑變量八成是相對路徑問題而不是代碼崩了。把跟蹤器當黑匣子扔著不管、只看最終畫框是這套源碼最容易被浪費掉的部分。愿意打開看一眼后面調(diào)參就是有依據(jù)的。2.4 單幀里的完整流動從frame到track把上面概念落到一個幀循環(huán)里順序是這樣的OpenCV讀取一幀BGR圖像圖像被resize和歸一化后進YOLOv9YOLO輸出原始預(yù)測經(jīng)過conf閾值和NMS過濾留下若干bbox每框從[x1,y1,x2,y2]轉(zhuǎn)成中心坐標和寬高的xywh格式連同score和class拼成數(shù)組數(shù)組和原圖一起交給tracker.updatetracker內(nèi)部先卡爾曼預(yù)測再和檢測做匹配返回已確認track的ID、坐標和置信度最后把track結(jié)果畫到圖上并寫進輸出視頻。這個過程在源碼里就是object_tracking.py主循環(huán)并不需要你去動網(wǎng)絡(luò)結(jié)構(gòu)。新手最容易懵的是為什么最終顯示的不是YOLO畫的框而是tracker畫的框。原因很簡單顯示層要的是ID加框的整體結(jié)果所以源碼里畫圖函數(shù)取的是DeepSort的track輸出而不是檢測器的原始輸出如果你自己改代碼時畫了兩遍把ID疊加在檢測框上視覺上就會混亂。打開helpers里的draw邏輯很快能看懂這一層。3. 跑通環(huán)境的三件事conda雙軌依賴、權(quán)重放位、兩種運行入口3.1 conda.yml和requirements.txt到底該按哪個來這類視覺工程最常見的環(huán)境坑是兩份依賴清單各有各的版本主張。conda.yml通常把python版本和基礎(chǔ)包固定住requirements.txt則補齊了cv2、torch、munkres之類的依賴。常見做法是以conda.yml為準建虛擬環(huán)境再用requirements.txt補裝。我建議的執(zhí)行順序是這樣的conda env create -f conda.yml conda activate yolov9_deepsort # 實際環(huán)境名以conda.yml里的name字段為準 pip install -r requirements.txt python -c import torch, cv2; print(torch.__version__, cv2.__version__, torch.cuda.is_available())第一行創(chuàng)建環(huán)境第二行激活第三行補pip依賴第四行是驗證。最后一行最關(guān)鍵如果torch.cuda.is_available()返回False說明GPU檢測沒生效。這時候別急著往下跑視頻否則模型推理會在CPU上慢慢爬你會以為是源碼性能差其實只是環(huán)境問題。常見做法是停在這里按機器CUDA版本重裝對應(yīng)torch再跑一次同樣驗證。3.2 權(quán)重文件和coco.names對齊才是模型能加載的前提源碼包本身是工程實現(xiàn)但YOLOv9預(yù)訓練權(quán)重一般是單獨放的。拿到手后先建一個weights目錄把權(quán)重統(tǒng)一放進去命名與configs里的變量保持一致。這一步遺漏最常見的報錯就是加載模型時直接提示文件不存在或者給你一個看起來莫名其妙的open blob錯誤。# 當前目錄是工程根目錄先建權(quán)重目錄 mkdir -p weights # 權(quán)重準備好之后放到配置里寫好的路徑 cp ~/Downloads/yolov9-c.pt weights/ ls -lh weights/這段操作不是玄學而是為了讓相對路徑固定下來。我習慣把coco.names和weights都放在工程根目錄下不搞散落式路徑。排查別人代碼時卡在路徑上的時間往往比卡在參數(shù)上的還多。coco.names要跟預(yù)訓練權(quán)重配套如果你自己訓練的模型只有幾個類別卻仍然用80類的coco.names后面畫框和解析類別時就會對不上號。3.3 跑通第一段視頻先走最短命令別一上來就調(diào)參第一次跑不要開一堆復雜參數(shù)就選一段5到10秒的短視頻把置信度和輸出路徑指定好其余用默認。這是為了確認管道是通的不是為了讓結(jié)果好看。命令行參數(shù)名在不同版本的object_tracking.py里可能略有差異運行前先看一眼入口函數(shù)的parse_args或者執(zhí)行python object_tracking.py --help確認這是最穩(wěn)的做法。我一般這么跑python object_tracking.py \ --source data/demo.mp4 \ --weights weights/yolov9-c.pt \ --conf 0.5 \ --output outputs/demo_result.mp4參數(shù)不復雜--source是輸入視頻--weights是檢測模型路徑--conf是檢測置信度閾值--output是結(jié)果保存位置。第一次跑就盯著終端里的FPS和track數(shù)量看FPS過低先考慮降分辨率或換tiny權(quán)重track數(shù)量一直是0說明目標還沒被確認成軌跡要去看置信度和n_init這兩個參數(shù)。如果程序正常走完打開結(jié)果視頻確認里面每輛車的ID在連續(xù)幀之間沒有頻繁跳變這個工程就算立住了。3.4 notebook入口適合拆開看但別依賴它做性能測試YOLOv9_DeepSORT.ipynb的作用是把整條管道拆成逐格步驟加載權(quán)重、跑單幀檢測、初始化tracker、循環(huán)視頻。如果直接跑object_tracking.py拋錯我建議先在notebook里逐格執(zhí)行定位是加載段還是更新段的問題。notebook的坑在于循環(huán)幀時顯示邏輯和保存邏輯會拖慢速度用它測出來的FPS不代表真實性能。所以我的習慣是排查用notebook性能驗證用object_tracking.py兩條路徑互不替代。4. 調(diào)參實操置信度、NMS和DeepSort的max_age這樣配4.1 YOLOv9側(cè)的兩個截門conf和nms_iou檢測階段有兩個參數(shù)直接影響跟蹤質(zhì)量一個是conf一個是NMS的iou閾值。conf設(shè)得高框更干凈但容易漏檢設(shè)得低遮擋目標能檢出來但會產(chǎn)生一堆碎框干擾跟蹤。這個取舍沒有萬能數(shù)得按場景給。我自己的參數(shù)區(qū)間是這樣的參數(shù)常見區(qū)間場景判斷conf0.25 ~ 0.5人群、密集商城場景寧多勿漏conf0.5 ~ 0.7車輛稀疏場景要求框少而準nms_iou0.45 ~ 0.7重疊目標多時調(diào)低避免框互相吞并這張表只當起點。血淚經(jīng)驗是如果跟蹤結(jié)果里目標走走停停斷斷續(xù)續(xù)先回頭查conf而不是一上來就動DeepSort參數(shù)。因為很多track之所以被判定消失根本不是跟蹤器的錯而是檢測階段壓根沒在這個目標上輸出框。檢測端的漏檢跟蹤器背不了這個鍋。4.2 DeepSort側(cè)參數(shù)max_age、n_init和max_distDeepSort參數(shù)通常聚合在跟蹤器初始化的配置里字段名各有差異但邏輯上逃不開幾個關(guān)鍵的。以下面這段常見配置為例我一般先不動這些值跑完一輪再根據(jù)效果改# 開源工程里很常見的DeepSort初始化參數(shù)字段名以你手上的版本為準 tracker_args { model_path: weights/deepsort.onnx, # ReID特征模型 max_dist: 0.3, # 外觀特征余弦距離上限越大越容易關(guān)聯(lián) min_confidence: 0.3, # 送入跟蹤器的檢測最低置信度 max_iou_distance: 0.7, # 外觀匹配不上時用的IOU兜底閾值 max_age: 70, # 軌跡連續(xù)丟多少幀后刪除 n_init: 3, # 連續(xù)匹配多少幀后確認新軌跡 nn_budget: 100, # 軌跡特征樣本總數(shù)上限 }逐個說透max_age是軌跡存活期目標消失后track會再等max_age幀這段時間內(nèi)如果目標重新出現(xiàn)還能續(xù)上舊ID調(diào)大它ID切換會減少但代價是誤關(guān)聯(lián)的可能性也會變高。n_init是新目標轉(zhuǎn)正需要的連續(xù)命中幀數(shù)調(diào)小能讓新軌跡更快出現(xiàn)但震蕩框更容易被當成目標。max_dist控制外觀匹配的寬容度調(diào)大特征不太像的兩個框也可能配上對調(diào)小ReID嚴格ID容易斷多目標交錯時不容易交換身份。max_iou_distance是兜底方案外觀匹配不上時tracker會退化用位置IOU續(xù)命。實戰(zhàn)中我最常做的調(diào)整是這三步ID頻繁斷就把max_age加到100以上max_dist調(diào)到0.35先看ID切換是否下降誤匹配多把max_dist收回0.25同時調(diào)大n_init到5讓噪聲框不被立即確認目標出畫再入畫總是換ID就要加更強的ReID模型。每次只改一個參數(shù)保留同段視頻做驗證不然你根本不知道是哪個參數(shù)起了作用。4.3 把YOLOv9換成自己的檢測器接縫只看這里有些用戶想用自己的數(shù)據(jù)集替換檢測權(quán)重后發(fā)現(xiàn)跟蹤還是按原邏輯跑。其實DeepSort并不關(guān)心分類模型長什么樣它只接收檢測框列表。這份源碼里YOLOv9檢測輸出被轉(zhuǎn)成跟蹤器輸入是在主循環(huán)里完成的一小段格式一般是這種結(jié)構(gòu)# 將檢測結(jié)果統(tǒng)一轉(zhuǎn)換為[x1, y1, x2, y2, score, class]數(shù)組 bbox_xywh np.array( [[x1, y1, x2 - x1, y2 - y1, score, class_id], ...], dtypenp.float32, ) tracker.update(bbox_xywh, frame)要注意兩點坐標務(wù)必轉(zhuǎn)成xywh置信度留在score位最后的class_id傳給DeepSort后只在可視化時用于顯示不影響匹配邏輯。所以你自己訓練的模型只要在這個位置把YOLO的result對象換成統(tǒng)一列表后面的ReID和卡爾曼濾波原樣復用工程改動量很小。5. 避坑與排查從OOM到ID跳變的五條踩坑記錄5.1 剛跑幾十幀就CUDA error: out of memory現(xiàn)象object_tracking.py啟動后前幾幀正常過了幾十幀直接報CUDA out of memory退出。原因這類視頻工程的默認輸入尺寸往往設(shè)得很大比如把1080p源放到960以上分辨率推理顯存占用隨分辨率呈平方級增長小卡很快就滿。還有一個隱蔽因素ReID特征網(wǎng)絡(luò)也在GPU上同時跑兩段顯存疊加后直接頂穿。解決先把檢測輸入尺寸降到640很多實現(xiàn)里是一個imgsz參數(shù)如果還不行換成yolov9-tiny這類小權(quán)重。我的底線是6G顯存以下640加tiny優(yōu)先不開大batch檢測和ReID盡量保持同一個推理會話不要同時開多個進程。5.2 目標過遮擋后ID跳變不?，F(xiàn)象目標被柱子遮住幾幀再出現(xiàn)后ID從5跳到12群體行走時更明顯。原因ReID提取外觀特征時遮擋后的畫面與遮擋前差異大余弦距離超過max_dist新舊狀態(tài)匹配不上卡爾曼濾波在目標被擋住后會繼續(xù)外推位置偏移也逐漸加大雙重因素導致舊track被判死、新track建立。解決第一選擇是調(diào)大max_age讓track多活一段時間出障礙后還有機會匹配回來第二看max_dist如果恢復效果差就把距離上限調(diào)大一點比如0.3調(diào)0.35。這兩個方向本質(zhì)都是放寬關(guān)聯(lián)已經(jīng)頻繁出現(xiàn)ID交換時不要兩個同時亂調(diào)先動max_age。5.3 檢測每幀都有框tracker輸出卻一直是0現(xiàn)象畫面上彩色檢測框正常在動但標注的ID和軌跡數(shù)量全是零日志里track數(shù)量不漲。原因跟蹤器的min_confidence把低置信度檢測過濾掉了或者n_init設(shè)置得比較大新track連續(xù)三幀才能被確認而視頻里的目標一直在動中途某幀掉檢就永遠轉(zhuǎn)不正。更常見的是檢測置信度閾值和min_confidence設(shè)了同一檔緊卡著臨界值檢測結(jié)果送不進跟蹤器。解決先把跟蹤器里的min_confidence調(diào)到0.1做一次驗證一般就能看到ID出現(xiàn)再把n_init從默認3暫時降到1盡快確認新track。邏輯是先把驗證鏈路打通再逐檔把閾值拉回正常而不是全靠猜。5.4 部分視頻格式讀取后幀序錯亂、時間戳卡住現(xiàn)象跑MP4一切正常換了一組AVI視頻軌跡忽前忽后甚至視頻后半段直接卡死。原因OpenCV底層的視頻解碼對不同編碼格式支持不一致。同樣是.aviMJPEG編碼和H264編碼走的是不同解碼分支處理速度和幀序表現(xiàn)差別很大。解決我的做法是統(tǒng)一先轉(zhuǎn)成H264的MP4再送進源碼ffmpeg -i input.avi -c:v libx264 -pix_fmt yuv420p -crf 23 input_conv.mp4輸出用yuv420p是為了兼容老播放器crf 23是畫質(zhì)和碼率的平衡點。轉(zhuǎn)碼后直接把--source指到新文件幀序問題基本消失。5.5 裝完requirements后torch被覆蓋cuda不能用現(xiàn)象本來在conda環(huán)境驗證torch.cuda.is_available()是True執(zhí)行pip install -r requirements.txt后變False推理速度驟降。原因requirements.txt里可能固定了基于CPU的torch或某個舊版本pip在安裝時把已有cuda版torch覆蓋掉了。這是雙軌依賴最常見的坑conda和pip版本主張打架pip后裝就贏了。解決先按conda.yml建環(huán)境再用pip補裝requirements發(fā)現(xiàn)覆蓋后重新指定cuda版本重裝# 重新安裝適用于本機CUDA的torch版本號以官方索引為準 pip install torch --index-url https://download.pytorch.org/whl/cu121注意這一步不能盲抄先看nvidia-smi里DRIVER版本支持的CUDA再選對應(yīng)cu版本。我見過太多人環(huán)境一崩就重裝整套環(huán)境其實只要固定好torch這一根線其他就順了。6. 進階把跟蹤結(jié)果變成業(yè)務(wù)數(shù)據(jù)——跨線計數(shù)與軌跡驗證跟蹤的真正價值不在花哨的框而在每個track_id連續(xù)帶出的位置序列。拿這套源碼跑通后我建議你往下走一步把每幀跟蹤輸出里的track_id和中心點記錄成結(jié)構(gòu)化數(shù)據(jù)再在這個序列上做業(yè)務(wù)判斷。比如跨線計數(shù)是視頻車流統(tǒng)計里最常見的需求而它其實不需要額外模型邏輯非常樸素判斷一個目標的中心點從參考線上方落到下方且該track_id從未被計數(shù)過就記一次向下穿越。import csv from collections import defaultdict line_y 720 # 參考線在畫面中的縱坐標 crossed set() # 已穿越的track_id trajectories defaultdict(list) with open(crossing_count.csv, w, newline) as f: writer csv.writer(f) writer.writerow([frame_id, track_id, cx, cy, event]) for frame_id, track_boxes in enumerate(frame_outputs): for box in track_boxes: track_id box[track_id] cx, cy box[center] trajectories[track_id].append((cx, cy)) if len(trajectories[track_id]) 2: continue prev_y trajectories[track_id][-2][1] if prev_y line_y cy and track_id not in crossed: crossed.add(track_id) writer.writerow([frame_id, track_id, cx, cy, down])這段代碼每來一個track_id就把中心點追加進軌跡判定條件看前一個點和當前點是否跨過參考線。兩點說明frame_outputs在源碼里是每幀tracker返回的已確認軌跡更新結(jié)果直接從那份輸出提取就行crossed集合保證同一個ID只在第一次穿越時計數(shù)不會因為后續(xù)振蕩多次累加。如果你在真實場景里發(fā)現(xiàn)計數(shù)偏多大概率是檢測框在參考線附近抖動導致軌跡反復穿越只要保留track_id集合去重絕大多數(shù)誤報能擋掉。驗證方法也回到這個思路用同一段視頻跑兩遍每次看兩條曲線的ID數(shù)量和跨線事件是否一致如果不一致先回去看檢測幀再看max_age而不是懷疑計數(shù)邏輯。從那以后我每次拿到一套檢測加跟蹤的源碼都會強迫自己先跑一遍固定視頻的ID軌跡連續(xù)性記錄切換次數(shù)再動參數(shù)。這套流程能擋住八成瞎調(diào)。希望幫到你。本文還有配套的精品資源點擊獲取