簡介面向計算機視覺與圖像處理方向的學習者及相關專業(yè)學生一份PDF技術文獻系統(tǒng)介紹基于計算機視覺的司機駕駛疲勞檢測方案可作為課程設計、畢業(yè)設計或相關研究的參考。內(nèi)容涵蓋人臉識別與人眼定位算法設計、基于dlib庫的六十八個臉部特征點提取、眼部縱橫比EAR值計算以及基于閉眼閾值與連續(xù)幀計數(shù)的疲勞判定流程實驗結果顯示系統(tǒng)成功率高達百分之九十。資源包內(nèi)為單個PDF文檔文件壓縮包大小約2.66MB十分便于離線閱讀截至目前已有165人瀏覽學習。文中還給出了從視頻幀預處理、人臉檢測到EAR判斷的完整實現(xiàn)步驟并討論了不同環(huán)境下檢測可信度及局限性閱讀后可快速把握疲勞駕駛檢測系統(tǒng)的設計與實現(xiàn)要點為后續(xù)改進提供參考。1. 基于計算機視覺的司機駕駛疲勞檢測為什么我要拆這份論文做計算機視覺大作業(yè)的同學十有八九會搜到吉林大學黃永平老師這篇《基于計算機視覺的司機駕駛疲勞檢測系統(tǒng)》。論文思路很清晰先用 dlib 檢測人臉 68 個特征點再用其中 36~47 號眼周特征點計算眼睛縱橫比 EAR通過 EAR 低于閾值的持續(xù)幀數(shù)判斷司機是否閉眼疲勞。系統(tǒng)實驗室內(nèi)成功率能到 90% 上下但論文里也承認實驗室環(huán)境光線穩(wěn)定、駕駛員正對鏡頭一到實際道路場景就會暴露不少問題。這份資源適合兩類人一是做 CV 課程設計、需要一套能跑通并寫進報告的技術路線二是想入門人臉關鍵點檢測、想搞懂 EAR 閾值怎么標定的初學者。我將從選型對比、特征點坐標、EAR 算法推導、代碼落地到參數(shù)坑位逐一拆解。2. 從 haarcascades 到 dlib人臉檢測器的選型理由與特征點坐標解讀2.1 為什么 haarcascades 在人眼閉合時直接翻車論文開頭提到先用了 OpenCV 自帶的 haarcascades 包做人臉檢測和人眼定位效果不理想光線好、眼睛睜大時勉強能用一旦眼睛閉合程度大、人眼區(qū)域在畫面里占比小就經(jīng)常定位不到眼睛甚至人臉都檢測失敗。這個現(xiàn)象我復現(xiàn)過原因在于 haar 特征本質(zhì)是基于像素灰度差異的弱分類器級聯(lián)它對睜開的眼睛這種有明確紋理對比的區(qū)域敏感而閉眼狀態(tài)下眼瞼紋理被皮膚褶皺替代灰度梯度特征消失分類器自然失效。另外 haar 檢測器輸出的是矩形包圍盒不給關鍵點坐標你拿到眼睛框后還得自己從框內(nèi)繼續(xù)找瞳孔或眼瞼位置多做一步就多一個誤差源。所以論文選 dlib 是合理的dlib 的 68 點人臉關鍵點檢測器基于 HOG 特征和線性分類器加上形狀回歸的級聯(lián)思想對局部紋理變化更魯棒且直接輸出每個關鍵點的 (x, y) 坐標省掉了二次定位的麻煩。2.2 68 點模型中 36~47 號點的位置含義與坐標提取dlib 的 68 點模型把面部關鍵區(qū)域劃分為下頜輪廓 0~16左眉 17~21右眉 22~26鼻梁 27~30鼻翼 31~35左眼 36~41右眼 42~47嘴巴 48~67。注意論文里寫36-47 為左右眼的特征點嚴格講是左眼 36~41、右眼 42~47。每個點是按固定語義順序輸出的左眼 36 是外眼角、39 是內(nèi)眼角37、38 是上眼瞼、40、41 是下眼瞼。import dlib import cv2 # 加載預訓練模型shape_predictor_68_face_landmarks.dat 需要另行下載 detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) img cv2.imread(driver_face.jpg) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) faces detector(gray, 0) for face in faces: shape predictor(gray, face) # 打印左眼6個點坐標索引36~41 for i in range(36, 42): pt shape.part(i) print(fPoint {i}: ({pt.x}, {pt.y})) # 打印右眼6個點坐標索引42~47 for i in range(42, 48): pt shape.part(i) print(fPoint {i}: ({pt.x}, {pt.y}))detector(gray, 0)的第二個參數(shù) 0 表示不使用圖像金字塔上采樣檢測速度快但小臉可能漏檢如果攝像頭離人較遠、人臉像素少改成 1 或 2 會增加一次上采樣能多檢出小臉但耗時翻倍。predictor接收灰度圖和檢測到的人臉框輸出 68 個點的坐標集合。這里有個經(jīng)驗輸入圖像分辨率不要太低dlib 官方建議人臉區(qū)域至少 80x80 像素否則關鍵點回歸精度會明顯下降。拿到坐標后別直接拿去做距離計算最好先按人臉框大小做歸一化。因為不同人離攝像頭遠近不同同一雙眼睛在畫面里的絕對像素距離可以差一倍以上直接比絕對值沒有意義。EAR 算法的妙處就在于它是一個比值分子分母同時縮放距離影響被抵消了。2.3 論文沒細說的特征點檢測失敗的常見輸入原因用 dlib 時最容易翻車的不是算法本身而是輸入圖像質(zhì)量?；叶绒D(zhuǎn)換是必須的dlib 的 HOG 檢測器在灰度圖上提取梯度特征彩色圖會被內(nèi)部轉(zhuǎn)灰度提前轉(zhuǎn)換能省一次轉(zhuǎn)換開銷。光照過暗時梯度信息弱檢測器可能整個人臉都框不出來強側光會在面部形成大塊陰影區(qū)關鍵點回歸容易偏移。我實測過當人臉偏航角超過 45 度即司機轉(zhuǎn)頭看右側后視鏡時68 點模型會在可見的半張臉上輸出全部 68 個點其中被遮擋側的點坐標基本是猜的計算出的 EAR 值完全不可信。提示實際做車載場景時優(yōu)先保證正臉采樣。攝像頭裝在方向盤前儀表盤位置比裝在 A 柱更利于關鍵點檢測。3. 核心算法 EAR眼睛縱橫比的計算邏輯與閉眼判定原理3.1 從眼周 6 點到縱橫比公式的推導論文的疲勞判定核心是 EAR全稱 Eye Aspect Ratio眼睛縱橫比。睜眼時上下眼瞼距離大閉眼時上下眼瞼幾乎貼合通過計算上下眼瞼特征點之間的垂直距離與內(nèi)外眼角水平距離的比值就能得到一個對距離不敏感、對睜閉眼狀態(tài)敏感的量。左眼的 6 個特征點編號為 36~41定義如下p36 為左外眼角p39 為左內(nèi)眼角p37、p38 為上眼瞼左右兩點p40、p41 為下眼瞼左右兩點。EAR 公式為EAR (||p37 - p41|| ||p38 - p40||) / (2 * ||p36 - p39||)分子是兩條垂直方向上的眼瞼距離之和分母是眼角水平距離的兩倍。睜眼時分子較大EAR 通常在 0.25~0.35 之間閉眼時分子趨近于零EAR 會掉到 0.1 以下。論文提到一般睜眼時上下特征點距離較大閉眼時上下距離較小說的就是這個幾何關系。兩只眼睛分別計算后取平均能抵消單眼誤檢帶來的抖動。3.2 完整可運行的 EAR 檢測代碼與逐行參數(shù)說明import dlib import cv2 import numpy as np detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) def eye_aspect_ratio(eye_points): # eye_points 是由6個 (x, y) 坐標組成的數(shù)組順序為外眼角到內(nèi)眼角環(huán)繞 p2_p6 np.linalg.norm(eye_points[1] - eye_points[5]) p3_p5 np.linalg.norm(eye_points[2] - eye_points[4]) p1_p4 np.linalg.norm(eye_points[0] - eye_points[3]) ear (p2_p6 p3_p5) / (2.0 * p1_p4) return ear cap cv2.VideoCapture(0) frame_count 0 ear_sum 0.0 while True: ret, frame cap.read() if not ret: break gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) faces detector(gray, 0) for face in faces: shape predictor(gray, face) left_eye [] right_eye [] for i in range(36, 42): pt shape.part(i) left_eye.append((pt.x, pt.y)) for i in range(42, 48): pt shape.part(i) right_eye.append((pt.x, pt.y)) left_ear eye_aspect_ratio(np.array(left_eye, dtypenp.float64)) right_ear eye_aspect_ratio(np.array(right_eye, dtypenp.float64)) ear (left_ear right_ear) / 2.0 cv2.putText(frame, fEAR: {ear:.2f}, (30, 30), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2) cv2.imshow(Fatigue Detection, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()eye_aspect_ratio函數(shù)里eye_points[0]是外眼角、eye_points[3]是內(nèi)眼角這是因為 dlib 輸出順序固定為順時針環(huán)繞眼睛索引 0 對應 36 外眼角索引 3 對應 39 內(nèi)眼角。np.linalg.norm計算兩點間歐氏距離p2_p6對應上眼瞼點 37 到下眼瞼點 41 的距離p3_p5對應 38 到 40 的距離這兩個都是垂直方向。p1_p4是水平方向的內(nèi)外眼角距乘以 2 是為了讓睜眼時的 EAR 值落在 0.25~0.35 這個便于比較的區(qū)間。實時視頻流里我一般直接取相鄰幀的 EAR 值做均值濾波比如滑動窗口取最近 5 幀的平均可以有效抑制單幀抖動。但注意窗口別太大否則閉眼瞬間的 EAR 變化會被平滑掉導致漏檢。3.3 EAR 閾值與連續(xù)幀判定論文流程的兩處關鍵參數(shù)論文的判定流程是EAR 小于閉眼閾值則計數(shù)器加一否則計數(shù)器清零當連續(xù)幀數(shù)大于疲勞閾值時發(fā)出警告。這里有兩個參數(shù)需要標定一個是閉眼閾值另一個是疲勞閾值即連續(xù)多少幀判定為疲勞。閉眼閾值我一般取 0.2~0.25 之間。太大會把正常眨眼誤判為閉眼太小則閉眼不徹底時檢不出來。論文提到眨眼時眼睛的寬度會迅速下降到零但實際視頻流里受幀率和運動模糊影響EAR 很難降到零通常閉眼瞬間 EAR 在 0.1 左右睜眼在 0.3 左右所以閾值取 0.2 是比較穩(wěn)妥的分界線。疲勞閾值和幀率直接相關30fps 下閉眼 0.5 秒就是 15 幀所以連續(xù)幀閾值取 15~20 比較合理。如果攝像頭幀率只有 15fps同等閉眼時長對應幀數(shù)減半疲勞閾值要相應下調(diào)。4. 從視頻流到疲勞報警系統(tǒng)實現(xiàn)的完整流程與邊界條件4.1 六步處理流程的代碼化落地論文 3.1 節(jié)給出的流程可以概括為灰度轉(zhuǎn)換、加載檢測器、檢測人臉、提取眼部特征點、計算 EAR、閾值比較與計數(shù)器累加。用代碼把這幾步串起來加上報警邏輯就是一個最小可用的疲勞檢測系統(tǒng)。import dlib import cv2 import numpy as np detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) EYE_AR_THRESH 0.20 EYE_AR_CONS_FRAMES 15 frame_counter 0 alarm_on False def eye_aspect_ratio(eye): A np.linalg.norm(eye[1] - eye[5]) B np.linalg.norm(eye[2] - eye[4]) C np.linalg.norm(eye[0] - eye[3]) return (A B) / (2.0 * C) cap cv2.VideoCapture(driver_video.mp4) while True: ret, frame cap.read() if not ret: break gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) faces detector(gray, 0) if len(faces) 0: cv2.putText(frame, No face, (30, 30), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 0, 255), 2) for face in faces: shape predictor(gray, face) left_eye np.array([(shape.part(i).x, shape.part(i).y) for i in range(36, 42)], dtypenp.float64) right_eye np.array([(shape.part(i).x, shape.part(i).y) for i in range(42, 48)], dtypenp.float64) ear (eye_aspect_ratio(left_eye) eye_aspect_ratio(right_eye)) / 2.0 if ear EYE_AR_THRESH: frame_counter 1 if frame_counter EYE_AR_CONS_FRAMES: alarm_on True cv2.putText(frame, FATIGUE ALERT!, (100, 100), cv2.FONT_HERSHEY_SIMPLEX, 1.2, (0, 0, 255), 3) else: frame_counter 0 alarm_on False cv2.putText(frame, fEAR: {ear:.2f} Frames: {frame_counter}, (30, 30), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2) cv2.imshow(Fatigue Detection, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()EYE_AR_THRESH和EYE_AR_CONS_FRAMES分別對應論文中的閉眼閾值和疲勞閾值。計數(shù)器邏輯是關鍵每幀 EAR 小于閾值就累加直到達到疲勞閾值才報警這樣一次快速眨眼只有三四幀低于閾值不會觸發(fā)報警而真正打瞌睡時閉眼會持續(xù)半秒以上必然突破連續(xù)幀閾值。這里報警只做了畫面提示實際車載系統(tǒng)可以接蜂鳴器或方向盤震動模塊。4.2 接口與硬件設計論文圖 4 的實際含義論文 3.3 節(jié)提到接口設計雖然沒有給出詳細電路圖但從系統(tǒng)架構能推斷出基本的硬件鏈路USB 攝像頭采集模擬視頻信號通過 USB 接口傳入車載工控機或嵌入式板卡板卡上的 OpenCV/dlib 處理完幀數(shù)據(jù)后通過 GPIO 或串口輸出報警信號給蜂鳴器或震動座椅。我重新搭過一套類似的用的樹莓派 4B 加 USB 攝像頭處理 640x480 分辨率視頻能達到 20fps 左右EAR 計算耗時約 4ms瓶頸在 dlib 的人臉檢測器上。嵌入式部署有一個容易被忽視的問題dlib 模型文件約 60MB加載進內(nèi)存后樹莓派這類設備的內(nèi)存占用會偏高。解決辦法是換用 OpenCV 的 DNN 模塊加載小型人臉檢測模型或者干脆用 MediaPipe 的 Face Mesh它在嵌入式設備上更輕量。但論文場景下的核心算法邏輯是通用的換檢測器不影響 EAR 計算與疲勞判定部分。4.3 論文沒提但必須考慮的多人臉、側臉與遮擋論文實驗環(huán)境是單人正對攝像頭實際駕駛場景會出現(xiàn)副駕駛有人、司機轉(zhuǎn)頭、手部遮擋面部。dlib 檢測器返回的faces是一個列表代碼里for face in faces會遍歷所有人臉如果副駕人臉更靠近鏡頭可能先被處理并占用 EAR 計算資源。需要加一個人臉排序邏輯取畫面中面積最大的臉作為駕駛員。側臉場景更麻煩當偏航角超過 30 度時左右眼特征點會重疊計算出的 EAR 值變得極小可能持續(xù)低于閾值系統(tǒng)誤報疲勞。處理方法是用人臉姿態(tài)估計篩選有效幀我一般用 OpenCV 的solvePnP配合 68 點中的鼻尖、下巴、左右眼角做姿態(tài)解算偏航角超過 30 度的幀直接跳過不參與 EAR 統(tǒng)計。5. 避坑與常見問題我用這份論文方案時踩過的五個坑5.1 幀率不匹配導致連續(xù)幀閾值失效現(xiàn)象按論文參數(shù)設置EYE_AR_CONS_FRAMES 15在低幀率攝像頭下正常眨眼都被報警。原因15 幀這個數(shù)字只有在 30fps 下才對應閉眼 0.5 秒。15fps 攝像頭下 15 幀已經(jīng)是閉眼 1 秒了反而容易漏報如果幀率只有 10fps15 幀對應 1.5 秒漏報更嚴重。反之幀率 60fps 時 15 幀僅對應 0.25 秒正常眨眼就可能觸發(fā)報警。解決處理前先讀取cap.get(cv2.CAP_PROP_FPS)把連續(xù)幀閾值換算成時間按int(fps * 0.5)方式動態(tài)設置。從那以后我每次接入新攝像頭第一件事就是打印幀率再決定閾值取多少。5.2 光照突變導致 EAR 曲線出現(xiàn)斷崖式下跌現(xiàn)象車輛駛出隧道瞬間畫面亮度驟變EAR 值突然從 0.3 掉到 0.1觸發(fā)報警。原因dlib 關鍵點檢測對光照變化敏感光線突變時眼瞼特征點回歸不穩(wěn)定上下眼瞼點可能收斂到同一位置導致分子趨近于零。解決對 EAR 序列做低通濾波我用的是滑動窗口均值窗口大小取 5~7 幀。光照突變引起的異常 EAR 通常只持續(xù)一兩幀均值濾波后會被平抑掉。同時可以檢測畫面整體亮度變化率變化超過 30% 時短暫凍結疲勞判定等光線穩(wěn)定后再恢復。5.3 眼鏡反光讓上眼瞼點漂移現(xiàn)象佩戴反光較強的鏡片時左眼 EAR 正常但右眼 EAR 長期偏低系統(tǒng)頻繁報警。原因眼鏡片反射的燈光或陽光會在眼周區(qū)域形成高光HOG 特征提取時高光區(qū)域梯度極大關鍵點回歸被高光吸引上眼瞼點被拉到鏡片反光位置。解決先用 Haar 檢測眼鏡區(qū)域或者對眼部 ROI 做直方圖均衡化壓低高光影響。更簡單的做法是直接提高閉眼閾值到 0.22并加大連續(xù)幀閾值到 20犧牲一點靈敏度換取穩(wěn)定性。論文沒提眼鏡問題但在中國駕駛員里戴眼鏡的比例很高這一條不做肯定翻車。5.4 人臉檢測器在低分辨率下漏檢現(xiàn)象攝像頭分辨率設為 320x240 時人臉稍遠就檢測不到程序直接輸出No face。原因dlib 的 HOG 人臉檢測器要求人臉區(qū)域至少 80x80 像素320x240 畫面中人的頭部可能只有 60x60 像素。解決把detector(gray, 0)改成detector(gray, 1)開啟一次圖像金字塔上采樣相當于把圖像放大一倍再檢測小臉也能框出來。代價是每幀耗時從約 15ms 漲到約 30ms。另一個方案是縮小輸出畫面但不縮小處理畫面即攝像頭采集 640x480檢測時用完整分辨率顯示時才縮放。5.5 連續(xù)幀計數(shù)器沒有設置上限現(xiàn)象司機確實閉眼睡著了系統(tǒng)報警一次后EAR 一直低于閾值計數(shù)器持續(xù)累加報警邏輯反復觸發(fā)。原因計數(shù)器無上限時閉眼 10 秒和閉眼 1 秒的最終結果一樣都是超過閾值后報警但無法區(qū)分輕微疲勞和深度睡眠。解決為計數(shù)器設置一個最大值比如frame_counter min(frame_counter, EYE_AR_CONS_FRAMES 30)達到最大值后保持報警狀態(tài)但不再累加。更進階的做法是分兩級判定連續(xù) 15 幀觸發(fā)一級警告連續(xù) 40 幀觸發(fā)二級強警告對應論文里閉眼或瞇眼時間過長的表述。6. 進階把 PERCLOS 指標引入系統(tǒng)替換簡單的連續(xù)幀計數(shù)論文用連續(xù)幀計數(shù)判斷疲勞這在工程上過于粗暴。真實駕駛場景中司機可能不會一次性閉眼超過 0.5 秒而是頻繁出現(xiàn)微閉眼每次只持續(xù) 0.2~0.3 秒。這類情況用連續(xù)幀閾值完全檢測不到。我在論文方案基礎上引入 PERCLOS 指標即單位時間內(nèi)眼睛閉合時間占比這是交通心理學研究里公認的疲勞度量。具體做法是計算最近 60 秒內(nèi)眼睛閉合幀數(shù)占總幀數(shù)的比例。統(tǒng)計窗口用 60 秒閉眼幀定義為 EAR 小于 0.2 的幀。當 PERCLOS 超過 0.15即每分鐘閉眼累計 9 秒以上判定為疲勞狀態(tài)。這個指標對頻繁短閉眼更敏感因為它是統(tǒng)計量而不是連續(xù)量。實現(xiàn)上只需要在原有 EAR 循環(huán)里增加一個環(huán)形緩沖區(qū)from collections import deque ear_history deque(maxlen1800) # 30fps下60秒的幀數(shù) closed_frames 0 window_frames 0 while True: # 原有EAR計算邏輯... ear_history.append(ear) if len(ear_history) 1800: closed_frames sum(1 for e in ear_history if e 0.20) perclos closed_frames / 1800 if perclos 0.15: cv2.putText(frame, FATIGUE (PERCLOS), (100, 100), cv2.FONT_HERSHEY_SIMPLEX, 1.0, (0, 0, 255), 3) ear_history.clear()deque(maxlen1800)自動丟棄最老的數(shù)據(jù)幀保持窗口長度為 60 秒省去手動管理列表頭尾的麻煩。perclos 0.15這個閾值參考了駕駛疲勞研究的常模但實際使用時需要根據(jù)目標人群微調(diào)經(jīng)常熬夜的司機的正常閉眼頻率本身就高閾值要放寬到 0.18 左右。驗證這個進階方案是否有效你可以錄制一段 5 分鐘視頻前 3 分鐘正常開車狀態(tài)后 2 分鐘模擬頻繁短閉眼。用原有連續(xù)幀邏輯大概率報不出警換 PERCLOS 后能穩(wěn)定檢出。從那以后我做人臉疲勞檢測默認就是連續(xù)幀閾值加 PERCLOS 雙通道并行判定單一指標太容易出邊界 case。希望幫到你。本文還有配套的精品資源點擊獲取