简介一套基于Python与Dlib的驾驶员疲劳检测系统能实时识别眨眼、打哈欠、瞌睡点头三类疲劳特征并展示可视化界面。面向计算机、人工智能、通信工程等专业的在校生与开发者适合作为毕业设计、课程设计或项目初期演示的完整参考。压缩包共17个文件内含6个Python源码主程序及眼睛、嘴巴、点头检测模块、2个Jupyter Notebook调试脚本、预训练人脸关键点模型dat文件另有界面演示视频、可执行安装包、运行效果图和UI设计文件整体大小85.92MB目录清晰便于直接运行和二次开发。目前已有232人学习下载代码经过测试可正常运行附有README说明与在线答疑支持。下载后可获得完整项目源码、模型参数、UI配置和测试视频有助于快速理解疲劳检测全流程也可自行扩展为更丰富的安全预警应用。1. 疲劳检测不是玄学用 Python Dlib 把「困意」变成可量化的数字一提到基于 PythonDlib 的驾驶员疲劳检测眨眼、打哈欠、瞌睡点头、可视化界面很多人第一反应是「这又是深度学习吧得跑个 YOLO 加 LSTM」。但真正做下来你会发现一个能在本地实时跑 30FPS 的疲劳检测核心反而是老牌的 Dlib 人脸关键点加几条几何规则。Dlib 的 68 点模型负责把人脸五官位置稳定地抠出来然后我们用眼睛宽高比、嘴巴宽高比、头部姿态角这三组数字去定义「困意」。这套方案没有 GPU 也能跑适合做毕业设计也适合做原型验证而且每个环节都能肉眼看到效果出了问题也知道去哪找。下面我按自己搭这套系统的顺序把原理、代码、参数和坑一次讲完。2. Dlib 人脸关键点疲劳检测的地基怎么搭模型与输入输出2.1 为什么选 Dlib 68 点模型而不是 YOLO 或 OpenCV 级联分类器疲劳检测的第一步是把人脸和五官定位出来这一步选错工具后面全白搭。OpenCV 自带的 Haar 级联分类器虽然安装省事但它输出的是人脸矩形框拿不到眼睛和嘴巴的精细坐标做眨眼检测基本得靠猜。YOLO 这类目标检测能框出人脸同样给不了关键点除非再叠加一个关键点模型部署成本直接翻倍。Dlib 的 68 点模型是专门为面部关键点设计的输入一张 RGB 图输出 68 个坐标点覆盖眉毛、眼睛、鼻子、嘴巴和下巴轮廓。它不挑显卡CPU 上单张 640×480 图像也能跑到十几毫秒。更关键的是 Dlib 的模型文件只有 60MB 左右训练好的权重开箱即用不需要自己准备标注数据这对没有 GPU 和大量数据集的个人项目来说是最稳的起点。2.2 最小可运行代码检测人脸并画出 68 个关键点先跑通一个最小闭环读图、检测关键点、画出来。以下是我的 baseline 代码每一步都做了注释。import dlib import cv2 # 加载预训练的人脸检测器基于 HOG 特征 detector dlib.get_frontal_face_detector() # 加载 68 点关键点模型模型文件要放在当前目录 predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) img cv2.imread(driver.jpg) # Dlib 内部用的是 RGB 顺序OpenCV 读进来是 BGR需要转换 rgb_img cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # 第 2 个参数是上采样次数1 表示对输入图像放大一倍再检测小脸也能找到 faces detector(rgb_img, 1) for face in faces: # 传入图像和检测到的人脸矩形框返回 68 个点 shape predictor(rgb_img, face) for i in range(68): x shape.part(i).x y shape.part(i).y # 用空心的点画出来不要用 cv2.circle 默认实心避免遮挡特征 cv2.circle(img, (x, y), 2, (0, 255, 0), -1) cv2.putText(img, str(i), (x, y), cv2.FONT_HERSHEY_SIMPLEX, 0.3, (0, 0, 255), 1) cv2.imshow(landmarks, img) cv2.waitKey(0)这段代码里有三个容易忽略的小点第一detector(rgb_img, 1)里的上采样参数1不是固定值。如果摄像头画面里人脸离得远、尺寸小把这个参数调成2可以提高召回率但推理时间会增加一倍左右。第二Dlib 的形状预测器要求输入是 RGB 顺序而 OpenCV 读入的是 BGR不转换的话关键点位置会整体偏移尤其在肤色区域。第三shape.part(i)返回的是dlib.point对象直接访问.x和.y就行千万别尝试用shape[i]那是另一个库的写法新手最容易在这翻车。2.3 坐标系与特征点索引左眼右眼嘴巴下巴的编号对应关系68 点模型的坐标索引不是随机排的它有固定语义。以人脸朝正前方、图像原点在左上角为例0 到 16从左侧下颚到右侧下颚的轮廓点其中 8 号点是下巴尖。36 到 41左眼外眼角到内眼角按顺时针排列的 6 个点。42 到 47右眼 6 个点。48 到 67外嘴唇 12 个点60 到 67 是内嘴唇上下嘴唇接触线的 8 个点。关键点索引表要记牢因为后面计算眼睛宽高比时36、37、38、39、40、41 这几个数字要反复用。另外注意 Dlib 的索引是 0 开始和 OpenCV 的cv2.polylines等函数配合时点集类型要转成numpy.ndarray。我一般会在代码里维护一个字典把索引分组方便后面复用import numpy as np FACE_POINTS { left_eye: list(range(36, 42)), right_eye: list(range(42, 48)), mouth_out: list(range(48, 60)), mouth_in: list(range(61, 68)), } def get_points(shape, indices): return np.array([[shape.part(i).x, shape.part(i).y] for i in indices], dtypenp.float32)这样后面写眨眼、打哈欠的判断函数时代码会干净很多。注意mouth_in的起点不是 60 而是 61因为 60 号点是左上嘴角而内嘴唇闭合线从 61 开始更稳定具体到不同姿势和表情这点差异会影响 MAR 计算的鲁棒性后面会说。3. 眨眼检测EAR 阈值法与判定状态机别让一帧误报炸掉整个系统3.1 EAR 的计算公式与为什么它比「眼皮距离」更抗抖动眨眼检测最常见的指标叫 EAREye Aspect Ratio眼睛纵横比它是一个比值不依赖绝对像素距离所以不同人脸大小、不同摄像头分辨率下都能用同一个阈值。EAR 的计算公式是把眼睛上下眼睑各两个点之间的欧氏距离求平均再除以左右眼角点的水平距离。用代码表示左眼 36-41 的点EAR 等于(||P37-P41|| ||P38-P40||) / (2 * ||P36-P39||)。为什么要用两组垂直距离的平均因为单用一组垂直距离当人眼转动或者侧脸时某一边会测量不准平均之后可以抵消一部分旋转误差。水平距离用的是眼角点眼角在眨眼时几乎不动所以作为分母很稳定。相比直接测量眼皮之间的像素高度EAR 最大的好处是尺度不变。摄像头离人脸 50 厘米和 70 厘米眼睛的绝对像素高度可能差一倍但 EAR 的值几乎不变。这也是为什么它能从 Dlib 输出里直接算不需要标定摄像头。3.2 实现眨眼计数连续 3 帧低于阈值才算一次眨眼如果只看单帧的 EAR 小于阈值就立刻计数十次有九次是误报。因为人脸检测本身有抖动关键点在某些角度下会轻微漂移EAR 也会有噪声。所以眨眼判定必须做成状态机先进入「闭眼」状态连续几帧都满足条件再离开「闭眼」状态这时候才认为完成一次眨眼。下面是我稳定使用的一段代码包含完整的眨眼计数逻辑def eye_aspect_ratio(eye_points): # 计算两组垂直距离的平均值 A np.linalg.norm(eye_points[1] - eye_points[5]) B np.linalg.norm(eye_points[2] - eye_points[4]) # 水平距离作为分母 C np.linalg.norm(eye_points[0] - eye_points[3]) return (A B) / (2.0 * C) # 状态变量放在主循环外面 EYE_AR_THRESH 0.2 # EAR 小于这个值认为眼睛闭合 EYE_AR_CONSEC_FRAMES 3 # 连续 3 帧闭合才确认闭眼状态 blink_counter 0 # 用于记录连续闭合帧数 blink_total 0 # 眨眼总次数 eye_closed False # 当前是否处于闭眼状态 # 主循环内每帧拿到 shape 后运行这段逻辑 left_eye get_points(shape, FACE_POINTS[left_eye]) right_eye get_points(shape, FACE_POINTS[right_eye]) ear (eye_aspect_ratio(left_eye) eye_aspect_ratio(right_eye)) / 2.0 if ear EYE_AR_THRESH: blink_counter 1 else: # 只有当计数器达到阈值时才把「闭眼状态」解除并计一次眨眼 if blink_counter EYE_AR_CONSEC_FRAMES: blink_total 1 eye_closed False # 这里只是简单地还原状态 blink_counter 0 # 实时显示当前 EAR 和累计眨眼次数 cv2.putText(img, fEAR: {ear:.2f}, (10, 30), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (255, 255, 255), 2) cv2.putText(img, fBlink: {blink_total}, (10, 60), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2)这里有一个关键点闭眼状态的标记eye_closed我故意没有用在判断里只保留了计数逻辑。为什么因为真正判断「一次眨眼」的完整状态机需要检测闭眼状态从无到有、再从有到无的完整过程。上面这段简化版只能统计「闭眼次数」它会把眼睛眯着超过 3 帧但还没完全闭合的情况也算进去。如果想区分瞬间眨眼和长时间闭眼嗜睡得加一个时间戳记录进入闭眼状态的时刻超过某个秒数就提示「闭眼时间过长」。3.3 参数调优EAR 阈值 0.2 与最小帧数的联动关系很多教程直接告诉你 EAR 阈值用 0.2、最小帧数用 3但不解释这两个参数是一对联动值。EAR 阈值设得太小比如 0.15只有真正用力紧闭时才会触发轻微疲劳半闭眼就不会被测到。设得太大比如 0.3可能把眼睛正常睁开但略微下垂因为脸朝下误判为闭眼。正确做法是先用正常睁眼状态下录一段 10 秒视频算一下 EAR 的均值mean_ear和标准差std_ear然后让阈值等于mean_ear - 2 * std_ear。这样能适应不同人的眼型。最小帧数的作用是滤掉瞬时噪声但它和眨眼速度有关。正常人一次眨眼大概持续 100-200 毫秒如果摄像头是 30FPS那就有 3-6 帧处于闭眼过程。设 3 帧比较合适但如果摄像头只有 15FPS3 帧就对应 200 毫秒可能会把快速轻眨漏掉这时可以改成 2 帧同时把 EAR 阈值稍微调低一点。我建议把这两个参数做成配置文件而不是写死在代码里。因为毕业设计答辩时老师可能会用你的电脑当场测试不同人脸的 EAR 分布差很多。要做到换张脸还能稳定检测就得有自动校准。校准很简单让测试者正常睁眼 20 秒取 EAR 序列的最小值作为参考下限再手动眨三次眼记录峰值把阈值设在两者之间。这一步能省掉后面很多调参的烦恼。4. 打哈欠与瞌睡点头MAR 与姿态角两个容易翻车的补充特征4.1 MAR 打哈欠判定嘴巴宽高比与帧数窗口眨眼之外打哈欠是另一个经典疲劳信号。和 EAR 类似我们用嘴巴纵横比 MARMouth Aspect Ratio来判断嘴巴张开程度。计算公式是上嘴唇中点与下嘴唇中点之间的距离除以嘴角宽度。Dlib 的 48 到 68 点里我用 61 号点和 67 号点左右嘴角内侧之间的距离做分母用 62 号和 66 号点的垂直距离做分子这样能避开嘴唇外轮廓的干扰。但打哈欠有一个特殊性说话、大笑也会让嘴巴张开MAR 会飙升。所以不能只看 MAR 超过阈值就判定打哈欠还需要时间窗口。一个自然的哈欠通常持续 3-5 秒其中嘴巴张到最大的持续期超过 1 秒。我的判定规则是MAR 连续 15 帧假设 30FPS 即 0.5 秒超过阈值并且这期间没有检测到说话特征比如 MAR 的波动频率不高才计一次哈欠。代码实现里建议用一个环形缓冲区来存近 30 帧的 MAR 值计算窗口内的均值与峰值。说人话版判断逻辑如下MAR_THRESH 0.55 # 不同人脸有差异建议先录一段正常说话视频标定 YAWN_MIN_FRAMES 15 mar_history deque(maxlen30) # 用 collections.deque 保持最近 30 帧 # 每帧计算 mouth_mar mouth_outer get_points(shape, FACE_POINTS[mouth_out]) # 62 号与 66 号是上下嘴唇内侧点61 和 67 是嘴角 upper mouth_outer[9] # 索引偏移要按实际编号换算 lower mouth_outer[13] left_corner mouth_outer[3] right_corner mouth_outer[11] vertical np.linalg.norm(upper - lower) horizontal np.linalg.norm(left_corner - right_corner) mar vertical / horizontal mar_history.append(mar) current_mean sum(mar_history) / len(mar_history) # 当 MAR 持续高且没有剧烈的上下波动说话时 MAR 波动大 if current_mean MAR_THRESH and len(mar_history) YAWN_MIN_FRAMES: if max(mar_history) - min(mar_history) 0.3: # 波动幅度小更像哈欠不是说话 yawn_total 1 mar_history.clear() # 计数后清空避免同一哈欠重复计注意mar_history用deque(maxlen30)的好处是自动丢弃旧数据不需要手动弹出。判定哈欠的关键不是单帧 MAR而是「高均值 低波动」这个组合。说话时 MAR 上下跳动能超过 0.3而哈欠的张开过程相对平滑。4.2 瞌睡点头检测用 Dlib 特征点算头部姿态角Pitch点头是疲劳驾驶里最危险也最直接的动作。检测点头有两种思路一种是跟踪鼻子尖或下巴尖的轨迹看它是否出现周期性快速下移另一种是计算头部俯仰角Pitch。用 Dlib 关键点算 Pitch 需要借助solvePnP属于 3D-2D 姿态估计听起来复杂但 OpenCV 已经封装好了。思路是把 Dlib 68 点里的一些点映射到 3D 人脸上已知坐标比如鼻尖、下巴、左眼角、右眼角、左嘴角、右嘴角再用cv2.solvePnP解出旋转向量然后把旋转向量转成欧拉角取 Pitch 分量。Pitch 角度负值代表低头正值代表仰头。疲劳点头通常表现为 Pitch 在短时间内快速下降到某个负值然后快速回到正常。这里最容易犯的错是直接用 Dlib 的 2D 像素坐标传给solvePnP忘了做相机内参。没有内参时结果不准确但疲劳检测只需要相对角度变化所以可以假设一个单位焦距的简化内参矩阵也能得到可用的 Pitch 变化趋势。下面是我踩过坑之后写的简化代码import cv2 import numpy as np # 3D 人脸标准坐标单位mm对应 Dlib 68 点里的索引 model_3d np.array([ [0.0, 0.0, 0.0], # 鼻尖 30 号 [0.0, -63.6, -12.5], # 下巴 8 号 [-43.3, 32.7, -26.0], # 左眼角 36 号 [43.3, 32.7, -26.0], # 右眼角 45 号 [-28.9, -28.9, -24.1], # 左嘴角 48 号 [28.9, -28.9, -24.1], # 右嘴角 54 号 ], dtypenp.float32) # 简化相机内参假设焦距 f500主点位于图像中心 focal_length 500.0 center (frame_width / 2, frame_height / 2) camera_matrix np.array([ [focal_length, 0, center[0]], [0, focal_length, center[1]], [0, 0, 1] ], dtypenp.float32) dist_coeffs np.zeros((4, 1)) # 假设无畸变 # 每一帧从 shape 取对应的 2D 点 image_points np.array([ [shape.part(30).x, shape.part(30).y], [shape.part(8).x, shape.part(8).y], [shape.part(36).x, shape.part(36).y], [shape.part(45).x, shape.part(45).y], [shape.part(48).x, shape.part(48).y], [shape.part(54).x, shape.part(54).y], ], dtypenp.float32) success, rotation_vector, translation_vector cv2.solvePnP( model_3d, image_points, camera_matrix, dist_coeffs) # 旋转向量转旋转矩阵再转欧拉角 rotation_matrix, _ cv2.Rodrigues(rotation_vector) pitch np.degrees(np.arcsin(-rotation_matrix[1, 2]))为什么只取这 6 个点因为微笑、歪头对它们的相对位置影响较小而且solvePnP最少只要 4 个不共面的点6 个点足够稳定。注意代码里camera_matrix里的frame_width和frame_height必须是实际图像的尺寸否则主点位置不对Pitch 会整体偏移。4.3 多特征融合策略加权投票避免单项误报眨眼、哈欠、点头三个信号单独看都会误报。比如看手机时低头会被识别成点头吃零食时嘴巴张合会被识别成哈欠。所以整套系统不能只靠一个特征触发告警。我常用的融合方式是加权评分把时间窗口比如 60 秒内的眨眼频率、闭眼时长、哈欠次数、点头次数各自归一化再乘权重。权重怎么定我参考过一些文献普通驾驶时每分钟眨眼约 15-20 次疲劳时眨眼频率下降但单次闭眼时长变长同时点头和哈欠频率上升。所以我在评分函数里把「单次闭眼超过 0.8 秒」的权重加到最大其次是「3 秒内 Pitch 低头超过 15 度」的点头事件哈欠权重最低。这段评分代码不需要复杂的模型用几个if就能完成。重点是中国有个容易被忽略的细节多特征的时序同步。比如哈欠动作通常伴随头部后仰点头动作是前倾如果两个特征在同一帧触发说明姿态数据有问题。我一般会加一个互斥规则——同一时刻只允许一个主要动作生效优先等级为闭眼 点头 哈欠。这个规则能过滤掉大量「打哈欠时头自然下垂」导致的误报。5. 疲劳检测避坑指南Dlib 编译失败、摄像头卡顿、光照过曝 5 个真实翻车现场5.1 Dlib 安装失败CMake 与编译器版本不匹配现象在 Windows 上执行pip install dlib等待半天后报错C compilation failed或者提示找不到 CMake。原因Dlib 从 19.x 版本开始有预编译轮子但旧版本或 Python 版本太新时pip 会尝试从源码编译。编译需要 CMake、VS Build Tools 和 Python 开发头文件任何一个版本不匹配都会中途失败。解决优先用官方预编译轮子指定版本安装比如pip install dlib19.24.x具体版本号以你所在 Python 版本支持的为准。如果实在要源码编译Windows 上必须安装 Visual Studio 2019 或 2022 的“使用 C 的桌面开发”工作负载然后在控制台里设好VSINSTALLDIR环境变量再执行python setup.py install。Linux 上则要先装libboost-all-dev和cmake。5.2 摄像头帧率只有 5FPS图像缩放与推理频率分离现象摄像头画面卡顿显示 FPS 只有 5眨眼计数跳数特别慢。原因Dlib 的 HOG 人脸检测在 1280×720 的原始图像上速度只有几帧而关键点检测还需要在检测到的框上再算一遍CPU 算力被拖死。解决不要直接对原始帧做检测。先缩小到 320×240 或 480×360在缩小图上做人脸检测得到人脸框坐标后再映射回原始尺寸关键点预测仍在原始尺寸上做。这样人脸检测速度能快 3-5 倍。另外把检测频率和关键点计算频率分离每 3 帧做一次人脸检测中间 2 帧直接沿用上一次的人脸框坐标去算关键点。因为驾驶员头部移动不会一帧内跳变太大这个技巧能在不损失跟踪连续性的情况下把 FPS 拉回 20 以上。5.3 夜晚/逆光人脸检测不到直方图均衡化的正确用法现象白天检测正常一进隧道或晚上开灯摄像头画面里人脸轮廓还在但 Dlib 就是检测不到人脸。原因HOG 特征对光照变化敏感人脸区域过暗或过曝时梯度方向分布被破坏。解决在送入检测器之前对灰度图做 CLAHE对比度受限自适应直方图均衡化它比普通均衡化更能保留局部细节。注意 CLAHE 要在灰度图上做而且要限制对比度参数否则肤色区域会出现颗粒状噪声。我的做法是把clipLimit设为 2.0、网格大小设为 8×8效果比全局直方图均衡化稳得多。另外如果摄像头有自动增益切到手动曝光模式把曝光时间固定在 8-12ms能减少帧间亮度跳变。5.4 眨眼误报率偏高只看 EAR 不看 EAR 变化曲线现象系统频繁报眨眼实际测试者只是眼睛眯着在笑或者在低头看手机时眼睛本来就小。原因单帧 EAR 小于阈值不代表眨眼。真正眨眼是「睁开 → 闭合 → 睁开」的完整过程EAR 会先快速下降再快速上升。而眯眼笑或正常睁眼视线上看时EAR 可能一直保持较低但不会出现明显的「V 形」变化。解决不要只用一个阈值做二值判断改成记录 EAR 最近的 20 帧序列计算序列的标准差。眨眼时 EAR 标准差会明显大于持续低值时。增加一个条件只有当 EAR 从高于 0.25 降到阈值以下再经过 3-5 帧又回到 0.25 以上时才计一次眨眼。这个「V 形」检测能过滤掉大部分眯眼误报。5.5 打哈欠误判成眨眼特征区域重叠时的判定顺序现象测试者打了个大哈欠系统眨眼次数瞬间增加了 2-3 次。原因打哈欠时面部肌肉剧烈运动Dlib 关键点在眼睛附近的点会被拉扯EAR 计算值短暂下降触发了眨眼逻辑。解决两个信号先做区域互斥。打哈欠期间嘴巴张开MAR 值必然升高所以在每一帧先判断 MAR 是否处于高值区间如果 MAR 超过 0.3就冻结眨眼计数逻辑不更新blink_counter。反过来如果 EAR 已经很低也暂时跳过哈欠判断。按「闭眼 哈欠 点头」的优先级执行同一帧只允许一种状态变更这样两个特征不会互相抢数据。6. 把算法封装成可视化界面PyQt5 的实时监控面板与告警逻辑疲劳检测做到最后必须让使用者「看得见」。一套只有黑框控制台的系统答辩和演示都不占优势。我用 PyQt5 OpenCV 做了一个实时监控界面左边显示摄像头画面右边用曲线图实时画 EAR 和 MAR 的变化底下一行标签显示眨眼总数、哈欠总数、点头次数和当前疲劳等级。核心技巧是不要在主线程里跑图像处理否则界面会卡死。# 界面刷新用 QTimer图像处理放在另一个线程里通过信号传结果 class FatigueWorker(QThread): frame_ready pyqtSignal(object, dict) def run(self): cap cv2.VideoCapture(0) while not self.isInterruptionRequested(): ret, frame cap.read() if not ret: continue # 这里调用前面实现的检测函数 drawed, metrics self.detect_fatigue(frame) self.frame_ready.emit(drawed, metrics) self.msleep(30) # 约 33FPS class MainWindow(QMainWindow): def __init__(self): super().__init__() self.worker FatigueWorker() self.worker.frame_ready.connect(self.update_ui) def update_ui(self, frame, metrics): # 把 OpenCV BGR 转 QImage 显示 rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w, c rgb.shape qimg QImage(rgb.data, w, h, c * w, QImage.Format_RGB888) self.video_label.setPixmap(QPixmap.fromImage(qimg)) self.lbl_blink.setText(f眨眼: {metrics[blink]}) self.lbl_yawn.setText(f哈欠: {metrics[yawn]}) self.lbl_nod.setText(f点头: {metrics[nod]})这套界面的关键点有两个第一工作线程里不能碰任何 Qt 控件只能通过pyqtSignal把图像和指标发回主线程否则随机崩溃第二图像转换成QImage时必须把 BGR 转成 RGB而且bytesPerLine要手动算成c * w这行错了图像会呈现斜纹。另外疲劳评分超过 80 分时我习惯在界面上弹出一个红色的覆盖层提示「建议休息」这比单纯的数字更能刺激用户反应。带图形的界面开发完以后回头总结一下我踩得最多的坑不是算法而是线程与摄像头释放。程序退出时不主动cap.release()摄像头灯会一直亮着第二次启动就会报Device or resource busy。所以在closeEvent里一定要请求线程中断、等待线程结束、再释放摄像头这个习惯让我少走了很多弯路。希望这套从关键点到可视化界面的全流程能让你少熬几个夜做调试。本文还有配套的精品资源点击获取