簡介本資源是一個面向智能交通與車載AI開發(fā)者的疲勞駕駛實時監(jiān)測系統(tǒng)實現(xiàn)方案聚焦駕駛員狀態(tài)識別與分心行為檢測兩大核心任務(wù)適用于輔助駕駛系統(tǒng)研發(fā)、DMS算法驗證及計算機視覺課程實踐。壓縮包共12個文件含10張模型測試效果示意圖展示Perclos眼閉合分析、哈欠/喝水/抽煙/打電話等YOLOv7檢測結(jié)果、1個關(guān)鍵處理腳本Concat.py用于多源行為特征融合或幀級結(jié)果拼接及1份README.md說明文檔整體體積4.7MB輕量易部署。已有148人學(xué)習(xí)下載適合具備Python與PyTorch基礎(chǔ)的中級開發(fā)者快速復(fù)現(xiàn)完整流程。讀者可直接獲取基于改進YOLOv7的多行為檢測模型推理邏輯、Perclos計算模塊集成方式、典型場景下的可視化檢測輸出樣例以及系統(tǒng)級聯(lián)設(shè)計思路為后續(xù)嵌入式移植或預(yù)警策略開發(fā)提供可運行基線代碼與結(jié)構(gòu)化參考。 做車載視覺這幾年我接到過最多的需求就是“把疲勞駕駛檢測落地”。這類DMSDriver Monitoring System項目最核心的坑不在算法本身多高深而在于怎么把眼睛的疲勞狀態(tài)判斷和嘴巴、手部的行為識別在一個不算寬裕的算力上穩(wěn)住幀率。我這套方案用的是Perclos做疲勞核心指標(biāo)用改進版YOLOv7做目標(biāo)感知層覆蓋哈欠、喝水、抽煙、打電話四個場景算是目前行業(yè)內(nèi)比較主流、也比較平衡的一套打法。如果你正準(zhǔn)備做DMS相關(guān)的課題或產(chǎn)品原型或者手里已經(jīng)有一套目標(biāo)檢測代碼但不知道怎么把它組織成完整的疲勞駕駛系統(tǒng)這篇整理應(yīng)該能幫你省不少彎路。1. 項目整體認知與技術(shù)選型分析1.1 疲勞駕駛檢測的核心邏輯疲勞駕駛檢測從技術(shù)路徑上分三類生理信號類、車輛行為類、視覺行為類。生理信號類腦電、肌電、心率準(zhǔn)確度高但需要接觸式穿戴設(shè)備前裝車型很少直接用車輛行為類方向盤轉(zhuǎn)角、車道偏離、跟車時距間接反映駕駛員狀態(tài)但依賴車輛信號和道路條件且判斷滯后視覺行為類是當(dāng)前DMS的主流用一個攝像頭對著駕駛員通過圖像判斷眼睛閉合、嘴部動作、頭部姿態(tài)和手部行為非接觸、成本低、可解釋性強?；谝曈X的疲勞檢測核心要拆成兩層感知層回答“眼睛在哪、嘴在哪、手在哪、有沒有手機、煙、水杯”決策層回答“眼睛有沒有持續(xù)閉合、嘴巴是不是在打哈欠、是不是在打電話”。目標(biāo)檢測模型負責(zé)前者Perclos和時序規(guī)則負責(zé)后者。這里最忌諱的是把兩層混在一起直接拿分類網(wǎng)絡(luò)做“疲勞/不疲勞”二分類要么在復(fù)雜光線下效果崩塌要么無法輸出中間證據(jù)出了問題連排查都無從下手。1.2 為什么是Perclos YOLOv7的組合Perclos全稱Percent of Eye Closure指單位時間內(nèi)眼睛閉合時間所占百分比是疲勞判別領(lǐng)域公認的指標(biāo)。它不像很多人想的那樣是個AI算法而是一個帶有明確物理含義的統(tǒng)計量。研究普遍采用P80準(zhǔn)則眼皮遮擋瞳孔面積超過80%就算眼睛閉合當(dāng)Perclos值超過0.4時判定為疲勞狀態(tài)。YOLOv7在這里的角色是給Perclos提供“眼睛狀態(tài)”的可靠輸入。原版YOLOv7在通用檢測任務(wù)上精度和速度的平衡度很好結(jié)構(gòu)上有ELAN高效聚合模塊、重參數(shù)化卷積、輔助訓(xùn)練頭、SPPCSPC金字塔池化理論功底和工程底子都扎實。但原版模型對“眼睛”“煙”“手機”這類小目標(biāo)、小物體不夠敏感直接部署到Jetson一類邊緣設(shè)備實時性也吃緊。所以項目標(biāo)題里的“改進”是必須的不是錦上添花。說得直白一點Perclos負責(zé)“累不累”的判斷YOLOv7負責(zé)“看到了什么”去掉任何一個這套系統(tǒng)都不成立。只靠傳統(tǒng)Perclos框架沒有深度模型眼睛定位在車輛晃動、光照變化下會崩只靠通用YOLOv7不解決小目標(biāo)和實時性跑起來又慢又漏檢。1.3 改進版YOLOv7的幾個方向?qū)嶋H落地時我見過最多、也最穩(wěn)妥的改進組合是三條輕量化主干、注意力模塊、小目標(biāo)檢測層。輕量化主干解決速度問題。原始Backbone的ELAN模塊在GPU上效率不錯但在Jetson Nano、RK3588這類嵌入式芯片上還有壓縮空間常用做法是引入MobileNetV3、GhostNet或者把普通卷積替換成GhostConv、DSConv在可控精度損失下?lián)Q回20%到40%的幀率提升。注意力模塊解決精度問題。DMS場景的背景是車內(nèi)環(huán)境相對單一但駕駛員可能戴墨鏡、帽子、口罩逆光和隧道光變化劇烈。在主干最后幾層或Neck部分插入CACoordinate Attention、CBAM這類輕量注意力對眼睛和手部小目標(biāo)的特征提取更聚焦。小目標(biāo)檢測層解決漏檢問題。原始模型在P3、P4、P5三個尺度輸出最小檢測層的步長為8對于一張640x640的圖眼睛區(qū)域可能只有十幾個像素。常見做法是增加P2層融合更高分辨率的特征圖或者在成本允許時把輸入分辨率提到960。P2層帶來的顯存和計算開銷不小需要按設(shè)備算力取舍。這三個方向的具體做法我后面逐個展開。2. 數(shù)據(jù)準(zhǔn)備與標(biāo)注規(guī)范2.1 數(shù)據(jù)采集方案數(shù)據(jù)質(zhì)量決定模型上限。采集時我會刻意覆蓋幾個維度不同人種、性別、年齡段、是否戴眼鏡、墨鏡、帽子、口罩不同光線條件包含白天強光、逆光、夜晚紅外補光、隧道內(nèi)連續(xù)變化光不同姿態(tài)包含正常駕駛、轉(zhuǎn)頭看后視鏡、低頭看手機、仰頭喝水、打哈欠、抽煙手勢等。攝像頭機位建議放在方向盤轉(zhuǎn)向柱上方或儀表盤中央偏上略微俯拍角度大概10到20度能夠同時看到完整臉部、雙手和部分飲料杯。分辨率不需要特別高1280x720即可采樣幀率在25到30幀每秒。同一個人連續(xù)錄制的視頻不能直接全進訓(xùn)練集需要做抽幀去冗余否則模型會對特定角度和光照過擬合。2.2 標(biāo)注類別與工具類別設(shè)計會直接影響決策層邏輯。我習(xí)慣把目標(biāo)拆細一點eye_open睜眼eye_closed閉眼mouth_open張嘴用于哈欠判斷mouth_closed閉嘴face人臉框輔助區(qū)域約束phone手機cigarette香煙drink水杯/飲料瓶細拆的好處是Perclos能直接讀取eye_open和eye_closed兩類目標(biāo)的置信度與坐標(biāo)不用再單獨做分類。如果標(biāo)注時只籠統(tǒng)地標(biāo)“喝水”“抽煙”整體行為框后面做規(guī)則判斷時反而拿不到“水杯位置”和“嘴部位置”的關(guān)系可擴展性很差。標(biāo)注工具用LabelImg最省事多人協(xié)作建議用CVAT或X-AnyLabeling支持視頻標(biāo)注和自動追蹤能省不少重復(fù)勞動。眼睛這類小目標(biāo)標(biāo)注要格外小心框一定要緊貼目標(biāo)寧可略小不要留白因為框太大或背景占比高正樣本的特征會被干擾訓(xùn)練后框的回歸精度也會變差。2.3 數(shù)據(jù)增強與樣本均衡車內(nèi)場景的負樣本遠多于正樣本駕駛員大部分時間是正常駕駛哈欠、喝水、抽煙都是小概率事件。如果不做人工干預(yù)模型會嚴(yán)重偏向“不張嘴、沒有手機”這類背景類測試時誤檢低但召回也低實車場景漏報會非常嚴(yán)重。我的做法是對哈欠、抽煙、喝水樣本做5到10倍過采樣同時配合Mosaic、MixUp、隨機HSV擾動、運動模糊、隨機遮擋等在線增強。Mosaic能把四張圖拼在一起訓(xùn)練變相增大batch size還能讓模型在小目標(biāo)上看到更多上下文。特別提醒抽煙和喝水這類動作往往幅度大但持續(xù)時間短標(biāo)注時最好把“拿起”“放下”的中間過程也標(biāo)進去讓模型見到更完整的動作序列決策層做時序判斷時才有連續(xù)輸入。增強后的數(shù)據(jù)集中每類目標(biāo)建議不少于3000個實例數(shù)量太少的話訓(xùn)練出來的置信度會很不穩(wěn)定。3. 改進YOLOv7網(wǎng)絡(luò)結(jié)構(gòu)解析3.1 YOLOv7網(wǎng)絡(luò)結(jié)構(gòu)圖全拆解ELAN、SPPCSPC與檢測頭先回顧原版YOLOv7結(jié)構(gòu)后面說改進才有參照。輸入圖像經(jīng)過Stem卷積進入BackboneBackbone的核心是ELAN模塊全稱Efficient Layer Aggregation Network。它通過長跨度特征聚合把不同層輸出按通道拼接讓信息流動更充分同時控制梯度消失。下采樣用MPConv模塊在步長為2的卷積旁路并聯(lián)一個MaxPool分支再把結(jié)果拼接。Backbone末端接SPPCSPC空間金字塔池化用不同池化核尺寸捕捉多尺度特征。Neck部分使用PANet結(jié)構(gòu)自頂向下和自底向上各融合一輪把高層語義信息和低層空間信息交替結(jié)合。頭部是三個尺度的Detect檢測頭分別負責(zé)小、中、大目標(biāo)配合訓(xùn)練時的輔助頭和推理時的重參數(shù)化卷積原版性能確實能打。但注意原版在COCO這類通用數(shù)據(jù)上表現(xiàn)好直接搬到DMS場景有明顯短板小目標(biāo)弱、模型偏重。整個結(jié)構(gòu)里最值得改的是Backbone的卷積深度、主干選擇以及檢測頭的尺度范圍。3.2 改進方案一輕量化Backbone替換我在類似項目里常用一個平衡方案不整個換成MobileNet而是只把Backbone尾部幾層做輕量化替換。全換MobileNet的好處是FPS高但精度損失太大眼睛的小目標(biāo)信息容易在高層特征圖中丟失只替換尾部前面保留ELAN的高效聚合能力速度和精度的平衡更好。具體做法可以參考基層保留原ELAN模塊到P4、P5層時把標(biāo)準(zhǔn)3x3卷積替換為GhostConv用一次普通卷積生成內(nèi)在特征再用線性變換生成冗余特征把計算量壓下來。同時激活函數(shù)統(tǒng)一換成SiLU和原結(jié)構(gòu)保持一致。這樣改完同等輸入分辨率下模型GFLOPs大約能降15%到25%幀率明顯提升mAP只下降1到2個百分點可接受。3.3 改進方案二CA注意力機制插入位置注意力模塊插入位置很關(guān)鍵。我試過在Backbone每一層后都插CA效果提升不明顯訓(xùn)練還變慢也試過只在Neck末層插改善有限。最后效果比較穩(wěn)的落點是兩處一處是Backbone輸出到SPPCSPC之前另一處是PANet上采樣融合之后。CA坐標(biāo)注意力比SE通道注意力更適合這個場景因為SE只建模通道關(guān)系CA還能把空間位置信息編碼進來。眼睛、手機、香煙在畫面里的位置相對固定CA學(xué)習(xí)到的位置先驗?zāi)茱@著減少誤檢。比如把方向盤按鍵誤檢成手機、把車內(nèi)裝飾紋理誤檢成香煙這類問題加入CA后有效改善。3.4 改進方案三小目標(biāo)檢測層眼神狀態(tài)判斷依賴眼睛小目標(biāo)這是整個系統(tǒng)精度最敏感的地方。原版輸入640x640時最小特征圖是80x80眼睛框往往只有十幾像素在深層特征圖里已經(jīng)很難區(qū)分。改進方案是增加一個160x160的P2檢測頭利用特征金字塔把淺層高分辨率特征送進檢測。代價是后處理耗時增加、顯存上漲所以我只在推理端按需開啟P2分支訓(xùn)練時仍用完整多尺度讓網(wǎng)絡(luò)學(xué)到更豐富的細節(jié)。如果設(shè)備實在吃緊還有個折中方案把輸入從640x640提到960x960只保留P3及以上檢測頭檢測效果接近P2層速度相對好一些。4. 模型訓(xùn)練與調(diào)參經(jīng)驗4.1 訓(xùn)練環(huán)境與依賴代碼以官方y(tǒng)olov7倉庫為基礎(chǔ)。環(huán)境一般是Python 3.8以上PyTorch 1.10到1.13之間CUDA 11.x。核心依賴如下pip install torch1.13.1 torchvision0.14.1 opencv-python numpy matplotlib pyyaml tqdm顯卡建議顯存至少8G。我常用RTX 3070或3080訓(xùn)練batch size在16左右云端A10或A100訓(xùn)練體驗更好但混合精度在小目標(biāo)上要注意保留關(guān)鍵層的FP32梯度避免loss震蕩。訓(xùn)練前把數(shù)據(jù)集組織成標(biāo)準(zhǔn)結(jié)構(gòu)images/train、images/val、labels/train、labels/val標(biāo)簽用YOLO格式每行“class cx cy w h”坐標(biāo)歸一化到0到1。類別文件data.yaml里寫清楚names列表順序必須與標(biāo)注時的class id一致這一步錯了后面全白搭。4.2 超參數(shù)與訓(xùn)練策略輸入分辨率設(shè)640x640訓(xùn)練輪數(shù)我一般跑200輪但真正有效的判定是看val mAP曲線的收斂平臺不一定非要跑滿。優(yōu)化器用SGD加momentum 0.937初始學(xué)習(xí)率0.01warmup在3輪內(nèi)完成后面用余弦退火慢慢降到0.0001。權(quán)重衰減設(shè)0.0005這是官方默認也比較穩(wěn)。遇到小數(shù)據(jù)集時凍結(jié)Backbone前幾層只訓(xùn)練Neck和Head可以顯著防止過擬合。我的習(xí)慣是前30輪凍結(jié)等loss降下來再解凍全部參數(shù)?；旌暇纫?jǐn)慎DMS場景里小目標(biāo)的梯度幅度小FP16容易丟失信息建議用torch.cuda.amp時關(guān)閉對檢測頭前兩層的半精度或者直接用FP32訓(xùn)練加FP16推理穩(wěn)定性更好。4.3 評估指標(biāo)與驗收標(biāo)準(zhǔn)不能只看mAP要看具體類別。小目標(biāo)的mAP.5:.95往往比mAP.5低10個百分點以上這是正常的。對于這個系統(tǒng)我重點關(guān)注eye_closed類別的AP、phone、cigarette、drink的誤檢次數(shù)以及整鏈路端到端幀率。指標(biāo)驗收參考值說明眼睛閉合AP0.5≥90%疲勞判斷的關(guān)鍵輸入哈欠動作召回率≥85%覆蓋張嘴到閉合完整過程分心行為誤報率≤1次/小時按實拍整車場景統(tǒng)計端到端幀率≥15FPSJetson Orin Nano級別這個表里的數(shù)值不是拍腦袋是綜合多個DMS公開數(shù)據(jù)集和自采數(shù)據(jù)交叉驗證后得到的基準(zhǔn)區(qū)間你可以按自己的場景調(diào)整。5. Perclos疲勞判定與多行為決策邏輯5.1 Perclos計算與閾值設(shè)定YOLOv7輸出眼睛框后Perclos按如下公式計算Perclos 閉眼幀數(shù) / 統(tǒng)計窗口總幀數(shù)判定單幀“閉眼”用P80準(zhǔn)則眼皮遮擋瞳孔面積超過80%視為閉眼。工程上可以簡化處理用眼睛框的寬高比或EAREye Aspect Ratio替代瞳孔遮擋面積。但純EAR對頭部姿態(tài)比較敏感駕駛員低頭時比例劇變誤判嚴(yán)重。我實際的方案是眼睛框?qū)捀弑扰c目標(biāo)置信度結(jié)合如果eye_open置信度低于閾值且eye_closed置信度高于閾值判為閉眼。統(tǒng)計窗口用60秒滑動窗口每0.5秒計算一次當(dāng)窗口內(nèi)Perclos值超過0.4時觸發(fā)疲勞告警。這個數(shù)值來自經(jīng)典文獻0.4到0.5之間是疲勞警戒區(qū)間。不同光照條件下需要微調(diào)夜間紅外人眼特征明顯閉眼判斷更準(zhǔn)閾值可以適當(dāng)收緊。5.2 哈欠、喝水、抽煙、打電話的時序判斷邏輯目標(biāo)檢測只能給出“這一刻畫面里有什么”無法表達“正在做什么”這個連續(xù)動作所以決策層必須帶時序。我采用的規(guī)則如下。哈欠mouth_open持續(xù)超過1.5秒且張嘴幅度大觸發(fā)哈欠計數(shù)配合頭部上揚動作可降低誤報。哈欠在60秒內(nèi)超過3次判定疲勞概率增加。喝水檢測到drink目標(biāo)且drink框與面部區(qū)域有接觸或接近持續(xù)2秒以上才算喝水動作。如果只檢測到水杯放在杯架上不能算喝水這一點很關(guān)鍵否則誤報會非常多。抽煙檢測到cigarette目標(biāo)且cigarette框與嘴部區(qū)域有重疊或距離很近持續(xù)若干幀判斷為吸煙動作。點煙、夾煙都不算避免過于敏感。打電話檢測到phone目標(biāo)且phone框與耳朵區(qū)域距離小于一定閾值同時結(jié)合面部角度如果手機出現(xiàn)在方向盤附近而人沒靠近不算打電話。這套規(guī)則的缺點是邊界參數(shù)多調(diào)起來繁瑣。優(yōu)點是可解釋、可調(diào)、不依賴額外訓(xùn)練成本。如果你希望更智能可以在規(guī)則之上加一個輕量GRU或LSTM把檢測結(jié)果序列映射到行為類別但參數(shù)可解釋性會下降。5.3 綜合疲勞評分與多級報警單一Perclos不好覆蓋所有疲勞形態(tài)。有人開車時眼皮一直微瞇但閉眼比例不高有人頻繁哈欠但眼睛狀態(tài)尚可。所以我把指標(biāo)做加權(quán)綜合疲勞分 0.4 * Perclos歸一化值 0.3 * 哈欠頻率歸一化值 0.3 * 分心行為頻次歸一化值分心行為包括喝水、抽煙、打電話單位時間內(nèi)各計一次?？偡殖^閾值后按等級觸發(fā)提醒一級用語音提示“請勿疲勞駕駛”二級增加聲光報警和座椅震動信號三級通過網(wǎng)絡(luò)上報給車隊管理平臺并抓拍現(xiàn)場照片。這個三級設(shè)計不是技術(shù)難點但很影響項目驗收客戶往往最看重報警鏈路的完整性和可回溯性。6. 部署與工程化實踐6.1 推理優(yōu)化與邊緣設(shè)備部署訓(xùn)練用的模型不能直接部署到嵌入式設(shè)備一般要過一遍TensorRT。FP16精度下模型推理速度通常能提升1.5到2.5倍INT8量化提升更多但小目標(biāo)精度下降明顯眼睛檢測尤其容易崩所以我不建議對眼睛檢測頭做量化可以保留FP16只對Backbone做INT8或混合量化。我在Jetson Orin Nano上部署時端到端幀率能做到25到30FPS前提是輸入分辨率控制在640、開啟TensorRT的DLA加速、把NMS的后處理移到GPU上。RK3588的NPU對YOLOv7支持也不錯但要注意算子的兼容性某些自定義模塊如重參數(shù)化卷積在NPU上要預(yù)先折疊成普通卷積否則跑不起來。這一步經(jīng)常是項目進度的最大坑建議先用SDK自帶的demo驗證算子支持再動模型。6.2 攝像頭選型與光照魯棒性夜間是DMS的主戰(zhàn)場普通RGB攝像頭在夜晚基本不可用。要選帶紅外補光的近紅外攝像頭常見波長850nm或940nm。850nm效果更好但會有輕微可見紅爆940nm完全不可見但傳感器靈敏度略低。安裝在駕駛位時我推薦850nm窄帶濾光片方案。攝像頭安裝高度最好與駕駛員眼睛平齊或略高俯仰角微俯5到15度避免仰拍導(dǎo)致眼眶陰影過重。鏡頭視野要覆蓋駕駛員面部區(qū)域和部分方向盤區(qū)域同時盡量別拍到中控屏否則屏幕亮度會干擾紅外成像。安裝固定也非常重要車輛震動導(dǎo)致畫面抖動的話后續(xù)所有識別都會變得不穩(wěn)定。6.3 系統(tǒng)架構(gòu)與線程模型實時檢測系統(tǒng)不能寫成一個main里循環(huán)跑完的demo。我建議分成采集線程、檢測推理線程、邏輯決策線程、報警通信線程。采集線程通過V4L2或RTSP收幀帶時間戳壓入隊列推理線程單幀或小批量處理輸出目標(biāo)數(shù)組邏輯線程跑Perclos和規(guī)則時間窗口獨立報警線程負責(zé)播報語音、寫入數(shù)據(jù)庫或上報平臺。用時間戳對齊而不是幀數(shù)對齊因為預(yù)處理、推理、后處理的耗時會漂移如果按幀排序邏輯層的“1秒前”和實際時間就對不上了。日志也要記錄檢測框原始輸出和決策結(jié)果方便事后回放分析誤報這一點在調(diào)車階段能救命。7. 常見問題與排查技巧實錄7.1 眼睛小目標(biāo)漏檢嚴(yán)重怎么辦先別急著改網(wǎng)絡(luò)先看標(biāo)注和預(yù)處理。眼睛框是不是標(biāo)得過大、背景占比高有沒有做類別均衡這兩點沒問題再看訓(xùn)練配置。如果還是漏檢依次嘗試提高輸入分辨率到960、增加P2檢測頭、把Mosaic增強的隨機縮放范圍改小、在數(shù)據(jù)集中增加眼睛特寫裁剪樣本。不要一上來就換Backbone那是最后手段。7.2 訓(xùn)練時Loss出現(xiàn)NaN原因通常是學(xué)習(xí)率太大或標(biāo)簽異常、框尺寸超出圖像邊界。優(yōu)先做數(shù)據(jù)校驗統(tǒng)計所有標(biāo)簽的cx、cy是否在0到1范圍內(nèi)、w和h是否為正。然后確認warmup沒有失效。最后檢查混合精度如果用了AMP試試FP32訓(xùn)練驗證是不是小目標(biāo)梯度回傳時溢出。7.3 實車測試誤報高誤報來源一般是兩類一類是檢測層把方向盤按鍵、方向盤織物紋理誤檢成手機、香煙另一類是決策層把放杯子的動作誤判為喝水。前者在數(shù)據(jù)集里補充大量無目標(biāo)負樣本和方向盤特寫加CA注意力后者靠邏輯層加“接觸面積、持續(xù)時間”雙重條件明顯緩解。還有一個容易被忽略的點車輛顛簸造成的畫面抖動會讓小目標(biāo)在幀間忽隱忽現(xiàn)需要在邏輯層加去抖計數(shù)器同一行為連續(xù)出現(xiàn)3幀以上才算。7.4 幀率不達標(biāo)優(yōu)先看推理耗時分布。如果主要耗時在后處理和NMS考慮降分辨率、減少檢測類別數(shù)量、用更早的置信度閾值在NMS之前過濾大量低分框。如果主要耗時在Backbone再考慮框架優(yōu)化和量化。切忌盲目換輕量網(wǎng)絡(luò)。我多次看到有人一上來就把YOLOv7換成更小的網(wǎng)絡(luò)速度是夠了精度崩了回頭又花大量時間調(diào)數(shù)據(jù)集得不償失。7.5 戴墨鏡和口罩場景怎么處理戴普通墨鏡時紅外攝像頭透不過鏡片Perclos直接失效。我的處理是增加一個“墨鏡遮擋”分類狀態(tài)如果檢測到墨鏡且長時間無法獲取眼部特征按“疑似疲勞”降額判定并提示駕駛員摘下墨鏡。更高級的做法是改用透紅外鏡片但成本高一般只在高端前裝項目里用。戴口罩時嘴部被遮擋哈欠檢測失效可以改成用眼部閉合和額頭皺紋配合判定。額頭皺紋檢測需要更高清的ROI區(qū)域?qū)嶋H部署中效果有限。比較務(wù)實的方案是把“持續(xù)性眼睛閉合”作為戴口罩情況下的主要疲勞指標(biāo)哈欠檢測暫時降級。8. 寫在最后的一點體會做DMS系統(tǒng)算法只是其中一半另一半是數(shù)據(jù)采集和邏輯層的邊界打磨。Perclos加YOLOv7這套組合勝在成熟、可控、好解釋。真正上線前一定要花大量時間在實車場景里錄制數(shù)據(jù)、跑干擾測試把誤報率壓到能接受的范圍否則再高的mAP在車主面前都會被一句“怎么又瞎報警”打回原形。如果后續(xù)想繼續(xù)擴展可以在現(xiàn)有基礎(chǔ)上加方向盤握持檢測、駕駛員身份識別以及基于毫米波雷達的呼吸和心率檢測做成多模態(tài)融合方案。這個方向這幾年行業(yè)關(guān)注度很高技術(shù)路徑也基本跑通了值得持續(xù)投入。本文還有配套的精品資源點擊獲取