簡介這套YOLOv5打電話行為檢測方案面向需要快速落地行為識(shí)別項(xiàng)目的開發(fā)者與算法學(xué)習(xí)者解決模型訓(xùn)練門檻高、數(shù)據(jù)標(biāo)注繁瑣的問題。包內(nèi)含訓(xùn)練好的.pt權(quán)重文件、YOLOv5工程源碼、配套數(shù)據(jù)集標(biāo)簽同時(shí)提供txt與xml兩種格式可靈活用于YOLO系列訓(xùn)練或VOC格式處理PyQt5界面支持圖片、視頻和攝像頭實(shí)時(shí)檢測開箱即用適合課堂實(shí)訓(xùn)、畢業(yè)設(shè)計(jì)或安防場景二次開發(fā)。資源共165個(gè)文件以Python腳本、pyc、yaml配置、jpg/png圖像樣本、xml/txt標(biāo)簽、pt模型和ui界面文件為主另有mp4演示視頻整體約433.91MB。目前已有604人學(xué)習(xí)/瀏覽完整工程結(jié)構(gòu)便于按目錄復(fù)現(xiàn)訓(xùn)練流程參考博客還可查看數(shù)據(jù)集與檢測結(jié)果能幫助節(jié)省大量整理和調(diào)參時(shí)間。1. 一套能直接跑的YOLOv5打電話行為檢測方案難的不是訓(xùn)練而是這三樣先說結(jié)論YOLOv5打電話行為檢測這個(gè)組合項(xiàng)目結(jié)構(gòu)拆開就是“YOLOv5模型 訓(xùn)練好的權(quán)重 打電話數(shù)據(jù)集 PyQt界面”四塊聽著像拼積木真正落地時(shí)模型訓(xùn)練只占三分之一工作量數(shù)據(jù)集的質(zhì)量和PyQt界面能不能流暢跑起來才是大頭。我見過不少團(tuán)隊(duì)拿開源模型跑兩天就換方案翻車點(diǎn)根本不在mAP而在“打電話”這個(gè)動(dòng)作怎么定義——是手機(jī)出現(xiàn)在畫面里就算還是手機(jī)必須貼著耳朵才算這個(gè)標(biāo)準(zhǔn)沒定清楚訓(xùn)練出來的模型就處在薛定諤的可用狀態(tài)。這篇文章把我做過的方案講透從打電話數(shù)據(jù)集的構(gòu)成、標(biāo)注規(guī)則、YOLOv5訓(xùn)練參數(shù)到PyQt界面怎么不卡殼地實(shí)時(shí)出框再到驗(yàn)收時(shí)看什么指標(biāo)、發(fā)布埋了哪些雷。適合做運(yùn)輸安全監(jiān)控、工地紀(jì)律檢測、考場行為分析以及想把手頭YOLOv5模型接進(jìn)桌面程序的工程師照著復(fù)現(xiàn)。2. 打電話行為檢測的技術(shù)選型為什么用YOLOv5而不是圖像分類2.1 打電話檢測不是圖像分類先定檢測目標(biāo)再談?lì)悇e“檢測打電話”在計(jì)算機(jī)視覺里其實(shí)是一個(gè)復(fù)合任務(wù)它同時(shí)包含兩個(gè)子問題人在哪里以及這個(gè)人是否處于打電話狀態(tài)。純圖像分類模型只能回答“這張圖里有沒有人打電話”回答不了“畫面里三個(gè)正在打電話的人分別在哪個(gè)位置”更扛不住攝像頭視野里同時(shí)出現(xiàn)多人、多姿態(tài)的場景。YOLOv5是單階段目標(biāo)檢測模型一個(gè)模型同時(shí)輸出目標(biāo)框、類別和置信度天然適合“定位分類”的需求所以拿來做打電話行為檢測是合理的。真正讓這個(gè)任務(wù)難的不是模型選型而是“打電話”這個(gè)類別的類內(nèi)差異。打電話的姿態(tài)至少有三種手機(jī)緊貼耳朵、手機(jī)舉在耳邊還沒貼上、拿著手機(jī)低頭看屏幕負(fù)樣本更麻煩手拿飲料、手夾煙、手扶方向盤、摸頭發(fā)都可能被模型誤判成“手持手機(jī)”。也就是說模型要學(xué)的是“手機(jī)與頭部區(qū)域的空間關(guān)系”而不是“畫面里有沒有一塊矩形物體”。很多新手直接把公開的人手檢測模型拿來當(dāng)打電話檢測用結(jié)果誤報(bào)率高得沒法看原因就在這個(gè)建模思路上。所以在做數(shù)據(jù)集標(biāo)注之前得先把類別體系想清楚。我的做法是拆成三個(gè)類別phone手持手機(jī)但沒打電話、call手機(jī)貼耳或舉在耳邊、person人體全身框。不要只標(biāo)一個(gè)“打電話”類別因?yàn)闃?biāo)注的人對(duì)“打電話”的判斷標(biāo)準(zhǔn)不一致模型學(xué)到的邊界就會(huì)漂移。多一個(gè)phone做硬負(fù)樣本等于主動(dòng)告訴模型“手里有東西和正在打電話是兩回事”。2.2 YOLOv5s、v5m、v5l怎么選顯存、幀率與精度的天平Y(jié)OLOv5官方倉庫提供了s、m、l、x四檔模型對(duì)應(yīng)參數(shù)量和推理速度的取舍。打電話檢測場景通常部署在監(jiān)控工控機(jī)或者普通辦公電腦上很少用得上x檔。我一般只在s和m之間選訓(xùn)練好的模型權(quán)重文件也不大分發(fā)成本低。模型參數(shù)量權(quán)重大小640分辨率算力我的最低顯存建議YOLOv5s7.2M14MB16.5 GFLOPs4GB可跑batch 16YOLOv5m21.2M42MB49.0 GFLOPs6GB以上穩(wěn)妥YOLOv5l46.5M92MB109.1 GFLOPs8GB勉強(qiáng)不推薦這里的GFLOPs是YOLOv5官方給出的640分辨率下的理論計(jì)算量實(shí)際部署時(shí)還受顯卡、輸入分辨率影響。選擇邏輯很簡單打電話檢測對(duì)框的精細(xì)程度要求不高但對(duì)幀率敏感因?yàn)楹罄m(xù)還要做時(shí)序判定幀率低于10FPS會(huì)導(dǎo)致“打電話”這個(gè)狀態(tài)在連續(xù)幀上斷斷續(xù)續(xù)。攝像頭分辨率是1080P時(shí)推流到模型前通常要縮到640×640YOLOv5s在GTX 1660上能跑到40FPS以上m檔會(huì)掉到25FPS左右。如果部署機(jī)器只有核顯或者老式工控機(jī)s檔幾乎是唯一選擇。低顯存環(huán)境下還有一條路訓(xùn)練時(shí)用s檔推理時(shí)把輸入分辨率從640降到480顯存占用能再降三分之一。代價(jià)是小目標(biāo)遠(yuǎn)處的手機(jī)漏檢率上升適合人物離攝像頭較近的室內(nèi)場景。如果你手里的機(jī)器連4GB顯存都沒有那別碰m和l老老實(shí)實(shí)s檔加CPU推理后面講PyQt界面時(shí)會(huì)給出對(duì)應(yīng)的優(yōu)化策略。2.3 三件套的分工檢測模型負(fù)責(zé)看見邏輯層負(fù)責(zé)判讀界面負(fù)責(zé)交互整個(gè)YOLOv5打電話檢測項(xiàng)目的主流程可以畫成一條線視頻幀進(jìn)入YOLOv5模型輸出每個(gè)人的框、每個(gè)手機(jī)的框以及它們的類別接著進(jìn)入一段后處理邏輯判斷手機(jī)框和人體框或頭部區(qū)域之間的位置關(guān)系記錄連續(xù)多幀的檢測結(jié)果最后PyQt界面負(fù)責(zé)把畫面、檢測框、狀態(tài)文字實(shí)時(shí)渲染出來。這里有個(gè)關(guān)鍵設(shè)計(jì)決定打電話判定的空間基準(zhǔn)到底用人體框還是頭部框。如果攝像機(jī)安裝角度是平視或微俯視頭部區(qū)域大約在人體框的上三分之一處直接用人體框的比例去估算耳朵位置即可如果攝像頭是高位俯拍比如走廊頂裝攝像頭手機(jī)遮擋頭部嚴(yán)重人體框的上邊緣根本對(duì)不準(zhǔn)耳朵這時(shí)候得單獨(dú)訓(xùn)練一個(gè)人頭檢測器配合使用。做運(yùn)輸監(jiān)控時(shí)我常用的是人體框方案因?yàn)榈缆窐寵C(jī)抓的是車身中景人頭上方有較多留白估出來的頭部區(qū)域還算穩(wěn)定。時(shí)序判定是容易被忽略的一層。單幀模型輸出噪聲很大一個(gè)“手拿手機(jī)”的姿態(tài)可能連續(xù)幾幀被誤判為“call”單幀就報(bào)警的話系統(tǒng)會(huì)不停誤報(bào)。常見的做法是維護(hù)一個(gè)長度為10幀的滑動(dòng)窗口窗口內(nèi)call類別出現(xiàn)7幀以上才確認(rèn)一次“正在打電話”連續(xù)3幀無call則解除狀態(tài)。這一層邏輯放在檢測模型的輸出之后、PyQt界面渲染之前代碼量不大但能把誤報(bào)率壓下去一大截。3. 從打電話數(shù)據(jù)集到能用的模型數(shù)據(jù)清洗、標(biāo)注規(guī)則與訓(xùn)練參數(shù)全流程3.1 數(shù)據(jù)從哪里來、怎么篩公開數(shù)據(jù)集與自采數(shù)據(jù)混排打電話數(shù)據(jù)集可以從兩個(gè)渠道湊齊公開數(shù)據(jù)集和自采數(shù)據(jù)。公開的駕駛分心數(shù)據(jù)集比如Kaggle上的State Farm Distracted Driver Detection里有大量“打電話”和“發(fā)短信”的標(biāo)注圖片畫面是車內(nèi)攝像頭對(duì)著駕駛員拍的類別和“打電話”高度相關(guān)另一種常見來源是國內(nèi)博客和網(wǎng)盤上有人整理過的“打電話行為檢測”數(shù)據(jù)集下載后注意看清楚標(biāo)注格式有的是VOC的XML有的是COCO的JSON需要統(tǒng)一轉(zhuǎn)成YOLO需要的txt格式才能訓(xùn)練。先把公開數(shù)據(jù)集拉過來看一遍篩掉清晰度太差、過曝、目標(biāo)被大面積遮擋的圖片。自采數(shù)據(jù)的價(jià)值在于對(duì)齊部署場景。公開數(shù)據(jù)集大多是車內(nèi)視角如果你要監(jiān)控的是辦公室或者工地畫面里人物大小、攝像頭俯仰角都和公開數(shù)據(jù)集差很遠(yuǎn)直接用公開數(shù)據(jù)訓(xùn)練換個(gè)場景就漏檢。我的做法是拿手機(jī)在學(xué)校附近天橋、辦公室通道錄幾段5到10分鐘的視頻人走動(dòng)、打電話、玩手機(jī)、正常行走混著來抽幀后加入數(shù)據(jù)集讓模型見過目標(biāo)場景的真實(shí)光線和視角。自采數(shù)據(jù)不用太多占到總量的20%到30%就能明顯改善場景遷移的落差。數(shù)據(jù)清洗定三條硬規(guī)則第一刪除有明顯噪點(diǎn)、運(yùn)動(dòng)模糊到看不出手機(jī)輪廓的圖片這類樣本會(huì)讓模型在訓(xùn)練時(shí)學(xué)習(xí)到錯(cuò)誤的紋理特征第二檢查有沒有“標(biāo)簽與畫面完全對(duì)不上”的臟數(shù)據(jù)公開數(shù)據(jù)集里時(shí)?；熘鴺?biāo)簽錯(cuò)位的樣本不篩掉的話訓(xùn)練損失會(huì)異常抖動(dòng)第三正負(fù)樣本比例控制住正樣本call和負(fù)樣本沒在打電話的人至少要做到1比3純正樣本訓(xùn)練出來的模型會(huì)把一切手部動(dòng)作都當(dāng)成打電話。3.2 標(biāo)注規(guī)則三個(gè)類別的邊界怎么劃才不翻車標(biāo)注環(huán)節(jié)是整個(gè)項(xiàng)目里最耗時(shí)也最影響上限的步驟。我推薦用CVAT或者labelImg工具不重要規(guī)則才重要。三個(gè)類別的判定標(biāo)準(zhǔn)在動(dòng)手標(biāo)注前就要和參與標(biāo)注的人對(duì)齊否則每個(gè)人標(biāo)出來的框五花八門。phone類手機(jī)出現(xiàn)在畫面里無論手持、放在桌上、放在腿上都算但只要手機(jī)清晰可見就得框。這個(gè)類別存在的意義是給模型提供“手機(jī)”這個(gè)物體的基礎(chǔ)特征讓模型先學(xué)會(huì)找手機(jī)再去判斷手機(jī)和頭部的關(guān)系。call類手機(jī)貼耳、手機(jī)與耳朵在同一焦平面并發(fā)生遮擋關(guān)系、手機(jī)舉著但明顯停在耳邊位置這三種姿態(tài)都算call。關(guān)鍵判斷點(diǎn)是“手機(jī)是否在頭部區(qū)域內(nèi)或緊貼頭部邊緣”而不是“手有沒有抬起來”因?yàn)榇鞫鷻C(jī)打電話手可以完全垂著。person類全身框不需要框得太緊背后的一些背景可以帶進(jìn)來這有助于模型理解人物和遠(yuǎn)景之間的關(guān)系。還有一個(gè)容易犯的錯(cuò)誤是框的范圍。手機(jī)框一定要只標(biāo)手機(jī)本體不要包住整只手。很多人圖省事把手機(jī)和手一起框成一個(gè)大矩形訓(xùn)練出來的模型會(huì)對(duì)“手的形狀”產(chǎn)生過擬合換個(gè)人戴不同顏色的手套就開始漏檢。call類的框也是這樣只需要把手機(jī)框住不需要體現(xiàn)手或臉的位置空間關(guān)系由模型自己去學(xué)習(xí)。一張圖里界乎于“靠近但沒貼耳”的模糊姿態(tài)寧可標(biāo)成phone也不要標(biāo)call這樣可以訓(xùn)練出更嚴(yán)格的分類邊界。3.3 數(shù)據(jù)劃分腳本一份可以抄的YOLO格式切分代碼YOLOv5訓(xùn)練時(shí)要求圖片和標(biāo)簽文件同名圖片放在images目錄標(biāo)簽放在labels目錄目錄結(jié)構(gòu)按數(shù)據(jù)集劃分成train和val即可。這個(gè)腳本把原始圖片目錄和標(biāo)注目錄按比例隨機(jī)切分到新的數(shù)據(jù)集目錄固定隨機(jī)種子保證每次劃分結(jié)果一致。import os import random import shutil def split_dataset(image_dir, label_dir, output_dir, val_ratio0.15, test_ratio0.05, seed42): random.seed(seed) images [f for f in os.listdir(image_dir) if f.endswith((.jpg, .png, .jpeg))] random.shuffle(images) n len(images) n_val int(n * val_ratio) n_test int(n * test_ratio) splits { train: images[n_val n_test:], val: images[:n_val], test: images[n_val:n_val n_test], } for split_name, imgs in splits.items(): img_out_dir os.path.join(output_dir, split_name, images) lbl_out_dir os.path.join(output_dir, split_name, labels) os.makedirs(img_out_dir, exist_okTrue) os.makedirs(lbl_out_dir, exist_okTrue) for img_name in imgs: base os.path.splitext(img_name)[0] shutil.copy2(os.path.join(image_dir, img_name), os.path.join(img_out_dir, img_name)) shutil.copy2(os.path.join(label_dir, base .txt), os.path.join(lbl_out_dir, base .txt)) for split_name, imgs in splits.items(): print(f{split_name}: {len(imgs)} 張) if split_name val: print(f驗(yàn)證集圖片總數(shù): {len(imgs)}) if __name__ __main__: split_dataset(raw_images/, raw_labels/, phone_dataset/)腳本邏輯不復(fù)雜但有幾個(gè)細(xì)節(jié)值得說明。隨機(jī)種子固定為42這樣反復(fù)執(zhí)行切分結(jié)果一致團(tuán)隊(duì)協(xié)作時(shí)不會(huì)各切各的。圖片和標(biāo)簽用copy2而不是rename保留原始數(shù)據(jù)做備份因?yàn)楹笃诎l(fā)現(xiàn)標(biāo)注錯(cuò)誤還要回頭改。驗(yàn)證集比例取15%對(duì)幾千張的中等規(guī)模數(shù)據(jù)集夠用了測試集單獨(dú)切出一份5%放一邊最后驗(yàn)收模型時(shí)才用避免訓(xùn)練過程里反復(fù)看測試集導(dǎo)致過度擬合。3.4 寫data.yaml并啟動(dòng)訓(xùn)練這些超參值得一個(gè)個(gè)調(diào)數(shù)據(jù)準(zhǔn)備好后寫一個(gè)data.yaml描述數(shù)據(jù)集路徑和類別信息train: ./phone_dataset/train/images val: ./phone_dataset/val/images test: ./phone_dataset/test/images nc: 3 names: [phone, call, person]路徑用相對(duì)路徑時(shí)要確保是相對(duì)于你執(zhí)行訓(xùn)練命令的目錄而言建議直接在YOLOv5倉庫根目錄下運(yùn)行data.yaml放在根目錄或指定路徑都可以。names的順序必須與標(biāo)注txt里的類別編號(hào)一一對(duì)應(yīng)這里phone是0call是1person是2標(biāo)注腳本里生成txt時(shí)就要按這個(gè)編號(hào)寫入。訓(xùn)練命令如下python train.py \ --data phone_data.yaml \ --weights yolov5s.pt \ --img 640 \ --batch 16 \ --epochs 100 \ --cache ram \ --patience 20逐項(xiàng)拆解參數(shù)的含義。--weights yolov5s.pt表示加載COCO預(yù)訓(xùn)練權(quán)重這不是偷懶而是用別人已經(jīng)學(xué)好的底層視覺特征做初始化能大幅縮短訓(xùn)練時(shí)間在中小規(guī)模數(shù)據(jù)集上幾乎不會(huì)帶來負(fù)面效果。--img 640是訓(xùn)練時(shí)隨機(jī)縮放的基準(zhǔn)分辨率如果攝像頭畫面里手機(jī)目標(biāo)很小可以提高到960或1280但顯存占用和推理延遲都翻倍建議先用640跑通全流程再調(diào)這個(gè)值。--cache ram把訓(xùn)練集圖片一次性緩存到內(nèi)存中避免每個(gè)epoch都從磁盤重新讀圖訓(xùn)練速度提升明顯前提是內(nèi)存夠大幾千張圖大概需要8GB到12GB內(nèi)存。--patience 20是早停機(jī)制連續(xù)20個(gè)epoch驗(yàn)證集損失沒有下降就自動(dòng)停止訓(xùn)練防止模型過擬合之后還繼續(xù)空轉(zhuǎn)。關(guān)于超參數(shù)YOLOv5默認(rèn)的anchor基本不用調(diào)打電話數(shù)據(jù)集的物體比例非常穩(wěn)定默認(rèn)anchor能覆蓋大部分框的形狀。真正值得動(dòng)的是mosaic增強(qiáng)的開啟程度如果訓(xùn)練數(shù)據(jù)來自同一個(gè)監(jiān)控?cái)z像頭場景高度重復(fù)可以把mosaic保持默認(rèn)并在訓(xùn)練后期用--multi-scale增強(qiáng)尺度多樣性如果數(shù)據(jù)來自多個(gè)不同場景mosaic的作用就沒那么大了。3.5 訓(xùn)練后看什么指標(biāo)別只盯著loss訓(xùn)練結(jié)束后YOLOv5會(huì)在runs/train/exp/weights/目錄下生成best.pt和last.ptbest.pt是驗(yàn)證集上表現(xiàn)最好的權(quán)重last.pt是最后一個(gè)epoch的權(quán)重部署時(shí)一定選best.pt。打開runs/train/exp目錄下的results.png重點(diǎn)看三條曲線訓(xùn)練損失、驗(yàn)證損失、驗(yàn)證集mAP0.5。對(duì)打電話檢測這個(gè)任務(wù)我通常把mAP0.5作為主要驗(yàn)收指標(biāo)0.5的交并比閾值意味著不需要框非常精準(zhǔn)只要大概框住手機(jī)就能算對(duì)的框。實(shí)際部署時(shí)置信度閾值會(huì)卡在0.25到0.4之間所以mAP0.5比mAP0.5:0.95更有參考意義。另一個(gè)要重點(diǎn)看的是混淆矩陣YOLOv5訓(xùn)練結(jié)束會(huì)在runs/train/exp目錄下輸出confusion_matrix.png如果call類別大量被識(shí)別成phone說明標(biāo)注里“貼耳”和“沒貼耳”的邊界樣本太少回去補(bǔ)充這類數(shù)據(jù)比調(diào)參有用得多。4. 把訓(xùn)練好的YOLOv5接進(jìn)PyQt界面視頻流、QThread與實(shí)時(shí)畫框4.1 PyQt界面的三個(gè)基本件窗口、畫面標(biāo)簽、控制按鈕PyQt部分不用做得多花哨一個(gè)能工作的桌面工具只需要三樣?xùn)|西主窗口QMainWindow、顯示視頻畫面的QLabel、控制啟停的QPushButton。主窗口左側(cè)放按鈕和狀態(tài)信息右側(cè)放畫面標(biāo)簽布局用QVBoxLayout或者QHBoxLayout都可以。攝像頭來源可以直接用OpenCV的VideoCapture設(shè)備號(hào)0表示第一個(gè)攝像頭也可以支持傳入視頻文件路徑方便直接用錄制好的測試視頻驗(yàn)證模型效果。界面邏輯上要注意的一點(diǎn)模型加載放在界面初始化階段而不是點(diǎn)擊“開始檢測”之后。YOLOv5模型初始化需要加載權(quán)重、構(gòu)建網(wǎng)絡(luò)結(jié)構(gòu)耗時(shí)從幾秒到十幾秒不等放在按鈕響應(yīng)里會(huì)讓界面陷入無響應(yīng)狀態(tài)。更規(guī)范的寫法是初始化界面時(shí)就把模型加載成全局或類成員變量點(diǎn)擊按鈕后只是拉起一個(gè)視頻循環(huán)線程。這樣用戶打開程序后點(diǎn)擊開始就能立刻看到畫面體驗(yàn)好很多。狀態(tài)信息區(qū)可以放兩個(gè)標(biāo)簽一個(gè)是實(shí)時(shí)推理耗時(shí)顯示每幀處理多少毫秒另一個(gè)是檢測狀態(tài)顯示當(dāng)前是否判定為“正在打電話”。這兩個(gè)數(shù)據(jù)對(duì)調(diào)試和驗(yàn)收都非常重要推理耗時(shí)能直觀反映模型和分辨率選型是否合理檢測狀態(tài)則能驗(yàn)證時(shí)序判定邏輯是否生效。4.2 用QThread跑推理為什么不能把detect寫在UI線程PyQt最經(jīng)典的翻車現(xiàn)場就是新手把while循環(huán)和模型推理直接寫進(jìn)按鈕的槽函數(shù)結(jié)果程序一啟動(dòng)攝像頭畫面就卡住窗口拖不動(dòng)、按鈕點(diǎn)不了。原因是UI線程被推理循環(huán)阻塞住了Qt的事件循環(huán)無法處理窗口繪制和鼠標(biāo)事件。解決辦法是把視頻讀取和模型推理放進(jìn)QThread子線程通過信號(hào)把結(jié)果傳回主線程更新界面。import cv2 import time from PyQt5.QtCore import QThread, pyqtSignal class DetectWorker(QThread): frame_ready pyqtSignal(object, list, float) error pyqtSignal(str) def __init__(self, model, source0, parentNone): super().__init__(parent) self.model model self.source source self.running True def run(self): cap cv2.VideoCapture(self.source) if not cap.isOpened(): self.error.emit(無法打開攝像頭或視頻文件) return while self.running: ok, frame cap.read() if not ok: break t0 time.time() results self.model(frame) # 提取 x1, y1, x2, y2, confidence, class_id dets results.xyxy[0].cpu().numpy() spend time.time() - t0 self.frame_ready.emit(frame, dets, spend) cap.release() def stop(self): self.running False self.wait()這段代碼里值得注意的地方有幾個(gè)。results.xyxy[0]返回的是一個(gè)包含所有檢測結(jié)果的tensor維度是N×6分別是x1、y1、x2、y2、置信度、類別索引。.cpu().numpy()把它轉(zhuǎn)成numpy數(shù)組方便在主線程直接遍歷。這里沒有用pandas().xyxy[0]因?yàn)閜andas解析會(huì)慢一些在實(shí)時(shí)推理循環(huán)里每幀多花幾毫秒對(duì)幀率敏感的場景屬于不必要的開銷。frame_ready信號(hào)攜帶原始幀、檢測結(jié)果、推理耗時(shí)三個(gè)數(shù)據(jù)一次性傳給主線程避免多信號(hào)之間的時(shí)序錯(cuò)亂。線程停止的寫法也需要注意。self.running False只是一個(gè)標(biāo)志位如果模型推理一幀超過幾秒比如CPU推理大圖stop()方法里的wait()會(huì)等到當(dāng)前循環(huán)結(jié)束才返回界面會(huì)短暫無響應(yīng)。改進(jìn)方式是設(shè)置一個(gè)超時(shí)時(shí)間或者在run循環(huán)里多次檢查running標(biāo)志但實(shí)際場景中幾百毫秒的等待用戶基本無感可接受。4.3 主線程畫框坐標(biāo)映射的坑檢測結(jié)果里的坐標(biāo)是相對(duì)于原始視頻幀的而QLabel顯示的尺寸很可能和原始幀不匹配尤其是用戶拖拽窗口改變布局后。直接在原始坐標(biāo)上畫矩形再縮放顯示會(huì)導(dǎo)致框的偏移和變形。必須先計(jì)算顯示區(qū)域的縮放比例再映射坐標(biāo)。def update_frame(self, frame, dets, spend): h, w frame.shape[:2] label_w self.video_label.width() label_h self.video_label.height() scale_x label_w / w scale_y label_h / h # OpenCV讀進(jìn)來的是BGRQImage需要RGB display cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) for det in dets: conf det[4] cls_id int(det[5]) if conf 0.35: continue x1, y1 int(det[0] * scale_x), int(det[1] * scale_y) x2, y2 int(det[2] * scale_x), int(det[3] * scale_y) # 類別1對(duì)應(yīng)call綠色顯示其他類別黃色 color (0, 255, 0) if cls_id 1 else (0, 255, 255) cv2.rectangle(display, (x1, y1), (x2, y2), color, 2) label_text f{self.names[cls_id]} {conf:.2f} cv2.putText(display, label_text, (x1, max(0, y1 - 8)), cv2.FONT_HERSHEY_SIMPLEX, 0.6, color, 2) h2, w2 display.shape[:2] qimg QImage(display.data, w2, h2, 3 * w2, QImage.Format_RGB888) self.video_label.setPixmap(QPixmap.fromImage(qimg).scaled( self.video_label.size(), Qt.KeepAspectRatio, Qt.SmoothTransformation))坐標(biāo)映射的關(guān)鍵在于scale_x和scale_y這兩個(gè)值是用顯示控件當(dāng)前尺寸除以原始幀的寬高得到的。使用QLabel的當(dāng)前寬高而不是固定值是為了支持窗口縮放后框依然對(duì)齊。顏色按類別區(qū)分很實(shí)用call類用綠色phone類用黃色一眼就能看出模型當(dāng)前狀態(tài)下正在檢測什么。cv2.putText的坐標(biāo)Y方向需要減去一個(gè)像素偏移否則文字會(huì)蓋在框線上閱讀體驗(yàn)差。QImage構(gòu)造函數(shù)的第三個(gè)參數(shù)傳入3 * w2表示每一行像素占用的字節(jié)數(shù)。這里最容易踩坑的是忘了把BGR轉(zhuǎn)成RGB直接拿OpenCV的原始幀構(gòu)造QImage畫面會(huì)出現(xiàn)偏藍(lán)和偏橙的詭異顏色。轉(zhuǎn)換那行cv2.cvtColor不能省。4.4 打電話狀態(tài)的時(shí)序確認(rèn)邏輯模型輸出的是單幀的檢測結(jié)果直接用會(huì)導(dǎo)致報(bào)警狀態(tài)頻繁抖動(dòng)。我在前面提到滑動(dòng)窗口的時(shí)序判定這里給出具體代碼實(shí)現(xiàn)class CallStateJudge: def __init__(self, window_size10, threshold7): self.window [] self.window_size window_size self.threshold threshold def update(self, has_call): 每幀調(diào)用一次傳入本幀是否檢測到call類別 self.window.append(has_call) if len(self.window) self.window_size: self.window.pop(0) confirmed sum(self.window) self.threshold return confirmed使用方式是在主線程的update_frame槽函數(shù)里判斷當(dāng)前幀是否存在類別為call的檢測結(jié)果把布爾值傳給CallStateJudge.update()。返回True時(shí)界面狀態(tài)欄顯示“正在打電話”同時(shí)可以觸發(fā)寫入日志或抓圖保存。窗口大小10幀、閾值7幀這兩個(gè)參數(shù)對(duì)應(yīng)的是“10幀里至少7幀檢出call才確認(rèn)”的規(guī)則既過濾了偶發(fā)誤檢又能容忍單幀漏檢。如果攝像頭幀率是30FPS這個(gè)窗口對(duì)應(yīng)約0.33秒確認(rèn)延遲是可以接受的。5. 避坑YOLOv5打電話檢測項(xiàng)目里最具迷惑性的5個(gè)坑5.1 “手機(jī)放桌上”也被識(shí)別為call類別邊界標(biāo)歪了現(xiàn)象模型訓(xùn)練完推理時(shí)一個(gè)放在桌面上、沒人碰觸的手機(jī)被標(biāo)成call觸發(fā)報(bào)警。最開始我以為是模型過擬合把置信度閾值從0.25調(diào)到0.5也擋不住。原因查了訓(xùn)練集的標(biāo)注后發(fā)現(xiàn)標(biāo)注的人把“手機(jī)在畫面中靠近人物”的樣本都標(biāo)成了call而沒有嚴(yán)格按照“手機(jī)與頭部接觸”的標(biāo)準(zhǔn)。模型的注意力被帶偏學(xué)到的是“畫面里有手機(jī)且離人近”就是call桌面手機(jī)自然中招。解決把這類樣本的標(biāo)注全部改回phone同時(shí)補(bǔ)充一批“手機(jī)在桌面、在手里但沒有舉到耳邊”的負(fù)樣本。改完之后重新訓(xùn)練call混淆到phone的量明顯下降。這個(gè)事說明標(biāo)注規(guī)則手冊必須細(xì)化到“貼耳才算call”這種程度否則交付的模型就是薛定諤的。5.2 低頭看手機(jī)完全漏檢手機(jī)屏幕被遮擋現(xiàn)象正面機(jī)位拍到的畫面里人物低頭看手機(jī)模型既沒檢出phone也沒檢出call直接放過去了。從人體姿態(tài)來看人確實(shí)在操作手機(jī)但目標(biāo)檢測模型依賴的是手機(jī)這個(gè)物體本身的外形特征。原因低頭場景下手機(jī)屏幕與攝像頭視角接近垂直屏幕紋理丟失手機(jī)的輪廓幾乎是一條線加上手部遮擋模型提取不到足夠特征。這不是模型訓(xùn)練的問題是成像角度造成的物理限制。解決常見做法是調(diào)整攝像頭安裝位置用下壓式俯拍或側(cè)方機(jī)位讓手機(jī)屏幕不被完全遮擋如果機(jī)位固定沒法調(diào)整就要在界面邏輯里加入姿態(tài)輔助判定比如“長時(shí)間低頭且雙手靠攏”也作為疑似打電話的提示但結(jié)果標(biāo)記為待人工確認(rèn)而不是直接報(bào)警。將檢測和判定做成兩個(gè)層面能降低漏報(bào)帶來的安全風(fēng)險(xiǎn)。5.3 訓(xùn)練loss能降到0.02測試集上誤報(bào)卻一個(gè)接一個(gè)現(xiàn)象訓(xùn)練過程看起來非常漂亮loss曲線一路下降mAP0.5超過0.9但換一段真實(shí)攝像頭錄的視頻跑誤報(bào)率高到不堪入目。這應(yīng)該是很多人在訓(xùn)練自己的數(shù)據(jù)集時(shí)碰到過的最困惑的問題。原因把驗(yàn)證集和測試集切成同分布了驗(yàn)證集圖像和訓(xùn)練集圖像來自同一批數(shù)據(jù)模型從這里學(xué)到了復(fù)制粘貼式的記憶而非泛化能力。前面切分腳本里專門保留5%的test目錄就是用來做這個(gè)隔離的。解決訓(xùn)練完成后把test目錄里的圖片單獨(dú)跑一遍推理統(tǒng)計(jì)結(jié)果。如果test上的mAP明顯低于val說明模型過擬合訓(xùn)練集分布回去補(bǔ)數(shù)據(jù)或增強(qiáng)正則化。更進(jìn)一步用錄制的一段真實(shí)場景視頻跑端到端測試不只看mAP還要統(tǒng)計(jì)誤報(bào)數(shù)和漏報(bào)數(shù)這才是發(fā)布的真實(shí)基線。5.4 PyQt界面花屏或顏色怪異RGB與BGR沒轉(zhuǎn)現(xiàn)象界面能顯示畫面但整個(gè)圖像顏色嚴(yán)重偏藍(lán)、發(fā)黃或者出現(xiàn)像素錯(cuò)位的花屏。有時(shí)窗口一拖動(dòng)畫面直接變成橫條紋像是編碼格式錯(cuò)了。原因OpenCV讀取視頻幀返回的是BGR三通道排列而QImage默認(rèn)接收的是RGB排列直接構(gòu)造QImage不轉(zhuǎn)換通道順序就會(huì)偏色QImage構(gòu)造時(shí)第三個(gè)參數(shù)每行字節(jié)數(shù)寫錯(cuò)比如寫成3而不是3*w就會(huì)導(dǎo)致每一行像素錯(cuò)位成花屏。解決構(gòu)造QImage之前先cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)。每行字節(jié)數(shù)寫成3 * w對(duì)RGB888格式來說是固定的。如果用了QPixmap.fromImage(qimg)顯示后畫面方向不對(duì)檢查VideoCapture的寬高設(shè)置再不行就用qimage.mirrored()修正鏡像。5.5 推理循環(huán)越來越慢最終只剩3FPS現(xiàn)象開頭的50幀運(yùn)行流暢后面越來越卡接近一分鐘時(shí)幀率掉到個(gè)位數(shù)CPU占用接近滿載。看起來像是模型推理本身的問題其實(shí)是內(nèi)存管理問題。原因YOLOv5模型每幀推理產(chǎn)生的tensor對(duì)象沒有得到有效的回收累計(jì)在內(nèi)存里。另一個(gè)可能因素是OpenCV的VideoCapture緩沖隊(duì)列積壓攝像頭幀不斷往內(nèi)存塞推理速度跟不上讀取速度積壓越來越多。解決在run循環(huán)里把每幀的中間變量用局部變量接收不持有引用推理結(jié)果通過signal傳給主線程后立即釋放。對(duì)視頻文件讀取用cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)把緩沖隊(duì)列壓到最小讓攝像頭幀只保留最新一幀丟掉處理不過來的舊幀。還有一個(gè)實(shí)用的做法是每次循環(huán)末尾調(diào)用cv2.waitKey(1)釋放底層資源這個(gè)函數(shù)會(huì)觸發(fā)OpenCV內(nèi)部事件處理幫助釋放部分緩存。6. 發(fā)布前的最后一公里精度復(fù)測、ONNX導(dǎo)出與模型瘦身6.1 用一段沒見過的真實(shí)視頻做端到端驗(yàn)收測試集圖測完不等于模型可以上線真正的驗(yàn)收是錄一段部署場景的視頻逐幀跑完整推理鏈路統(tǒng)計(jì)兩個(gè)核心數(shù)字誤報(bào)次數(shù)和漏報(bào)次數(shù)。我的習(xí)慣是錄5分鐘正樣本視頻和5分鐘負(fù)樣本視頻正樣本視頻里人在正常打電話、玩手機(jī)、喝水負(fù)樣本視頻里人只是走路交談、看文件。跑一遍后如果負(fù)樣本視頻里觸發(fā)報(bào)警超過2次就需要回到時(shí)序判定層去提高確認(rèn)閾值如果正樣本視頻里“打電話”狀態(tài)的檢出幀數(shù)低于80%就說明模型的召回不夠要考慮降低置信度閾值或補(bǔ)充訓(xùn)練數(shù)據(jù)。這個(gè)階段要記錄的信息不止報(bào)警次數(shù)還有一個(gè)容易被忽略的指標(biāo)確認(rèn)延遲。從畫面里人物第一次把手機(jī)舉到耳邊到界面亮出報(bào)警中間經(jīng)過了多少幀。延遲過長會(huì)讓保安或管理人員覺得系統(tǒng)不靈敏一般目標(biāo)控制在0.5秒以內(nèi)。如果延遲超標(biāo)檢查是不是時(shí)序確認(rèn)窗口設(shè)得太長或者推理幀率太低導(dǎo)致狀態(tài)切換變慢。6.2 導(dǎo)出ONNX并切換成CPU推理PyTorch模型文件在部署機(jī)器上跑推理需要安裝對(duì)應(yīng)版本的PyTorch依賴體積大且顯存占用高。導(dǎo)出成ONNX后可以用ONNX Runtime做推理CPU和GPU都能跑依賴小很多啟動(dòng)速度也更快。YOLOv5官方倉庫直接提供導(dǎo)出腳本。python export.py --weights best.pt --include onnx --opset 12opset 12是ONNX算子集的版本新版ONNX Runtime對(duì)opset 12的支持非常成熟不會(huì)出現(xiàn)算子兼容問題。導(dǎo)出后會(huì)生成best.onnx文件在Python里加載推理import onnxruntime as ort import numpy as np session ort.InferenceSession(best.onnx, providers[CPUExecutionProvider]) def infer_onnx(frame): # 預(yù)處理縮放、歸一化、通道轉(zhuǎn)換 img cv2.resize(frame, (640, 640)) img img[:, :, ::-1].transpose(2, 0, 1)[None].astype(np.float32) / 255.0 outputs session.run(None, {session.get_inputs()[0].name: img}) return outputs[0]這段推理代碼返回的outputs[0]形狀是1×25200×6其中25200是YOLOv5在640分辨率下的默認(rèn)anchor數(shù)量需要經(jīng)過非極大值抑制才能得到最終的框。ONNX Runtime在無顯卡的工控機(jī)上跑YOLOv5s的640分辨率通常能達(dá)到15到25FPS對(duì)打電話檢測這種人員動(dòng)作變化慢的場景已經(jīng)夠用。如果你部署的機(jī)器是樹莓派或其他ARM開發(fā)板這個(gè)導(dǎo)出方案同樣適用性能取決于內(nèi)存帶寬和CPU核心數(shù)。6.3 模型瘦身與幀間隔策略模型部署的前沿優(yōu)化有三個(gè)方向按投入產(chǎn)出比排序。第一是降低輸入分辨率把640降到480推理時(shí)間能縮短三成到四成代價(jià)是遠(yuǎn)距離小目標(biāo)的召回下降。在做通話檢測時(shí)如果攝像頭距離人物在3米以內(nèi)降到480完全可接受。第二是跳幀檢測每2幀做一次完整推理中間幀直接復(fù)用上一幀的檢測框配合簡單的IoU追蹤用戶看起來畫面是連貫的實(shí)際推理量減半。這個(gè)方案部署成本最低普通工控機(jī)也能跑出實(shí)時(shí)效果。第三是INT8量化用ONNX Runtime的量化接口把模型從FP32壓到INT8體積縮小為原來的四分之一推理速度在CPU上能再翻一倍打電話檢測對(duì)框精度不敏感量化掉的那點(diǎn)精度損失幾乎無感推薦做。每次模型更新迭代之后保留上一次的best.pt和量化后的ONNX文件在驗(yàn)證視頻上做回歸測試確認(rèn)新版本沒有引入新的誤報(bào)類型。這個(gè)習(xí)慣幫我擋掉過好幾次上線前才發(fā)現(xiàn)的反向回歸。最后說一個(gè)個(gè)人習(xí)慣交付給別人的項(xiàng)目我一定會(huì)在界面里留下一個(gè)debug模式開關(guān)打開后顯示原始檢測框和置信度方便現(xiàn)場調(diào)試時(shí)一眼看出是模型漏檢還是后處理邏輯在搗亂。這套YOLOv5打電話檢測方案做完之后最大的體會(huì)是工業(yè)場景里模型的mAP不是核心數(shù)據(jù)邊界定義、線程穩(wěn)定性、坐標(biāo)轉(zhuǎn)換這些擺在明面上的工程細(xì)節(jié)才是決定項(xiàng)目能不能用起來的關(guān)鍵。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取