Python疲劳检测系统源码：从面部特征到分级报警的毕设完整方案

简介：这份资源是一套基于Python开发的驾驶员面部特征疲劳检测系统源码，面向计算机相关专业学生、毕业设计选题者以及需要人脸识别与状态监测方案的开发者。系统通过摄像头采集驾驶员面部图像，识别其疲劳状态并判断是否需要休息，可迁移至交警摄像头、高速收费站等场景，用于排查疲劳驾驶隐患。压缩包共24个文件，以10个xml配置、5个py核心脚本为主，另含iml工程文件、md说明、docx文档、dat数据与mp3提示音等，整体约68.33MB，下载解压后即可运行。目前已有1359人学习下载，说明该方案在同类毕业设计选题中具备一定参考价值。源码目录结构完整，涵盖人脸检测、特征提取与疲劳判定等模块，读者可据此理解从图像采集到状态输出的完整链路，并在此基础上调整阈值、替换模型或扩展报警逻辑，快速形成可演示、可答辩的项目成果。

1. 从一次答辩被问到哑口无言的经历说起

去年帮一个学弟看毕业设计答辩预演，他做的正是基于驾驶员面部特征的疲劳检测系统。功能演示很流畅，摄像头一开，绿框标出人脸，眼睛闭合超过阈值就弹报警。台下导师问了三个问题：EAR 阈值怎么定的？夜间红外图像怎么处理？误报率测过没有？他一个都答不上来。这个场景我印象太深了，因为绝大多数做疲劳检测毕设的同学，卡的不是代码能不能跑，而是说不清设计依据在哪。

这套 Python 疲劳检测系统源码要解决的，就是让做毕业设计或课程设计的人，拿到一份从特征提取到报警逻辑都能讲清楚来龙去脉的完整方案。它适合两类人：一是需要交出一份能通过答辩的毕设作品的学生，二是想快速搭一个驾驶员状态监测原型的开发者。核心链路是摄像头采集、人脸检测、关键点定位、疲劳特征计算、分级报警，每一环都有可调参数和可解释的设计理由。

2. 需求拆解与技术选型：为什么是面部特征而不是别的方案

2.1 疲劳检测的三条技术路线对比

做疲劳检测，摆在面前的路其实有三条：基于车辆行为（方向盘转角、车道偏移）、基于生理信号（脑电、心电）、基于面部视觉特征。毕设场景下选哪条，不是拍脑袋决定的。

技术路线	数据来源	实现难度	硬件成本	毕设适配度
车辆行为分析	方向盘、车道线	中	需车辆或模拟器	低，难复现
生理信号检测	脑电/心电传感器	高	高，需接触式设备	低，设备门槛高
面部视觉特征	普通摄像头	中	低，一个摄像头即可	高，易演示

面部视觉特征这条路，最大的优势是数据获取门槛低。一个普通 USB 摄像头就能采集，不需要接触式传感器，也不需要真实车辆。对毕设来说，能演示、能复现、能讲清楚原理，比技术多先进重要得多。

2.2 技术栈的取舍逻辑

这套方案的技术栈是 Python + OpenCV + Dlib（或 MediaPipe）+ NumPy。为什么不用深度学习端到端的方案？因为毕设答辩时，端到端模型是个黑匣子，导师问“为什么判定为疲劳”，你只能回答“模型输出的”。而基于面部几何特征的方法，每一步都有明确的数学定义，EAR（眼睛纵横比）、MAR（嘴巴纵横比）、头部姿态角，这些指标可以画曲线、可以设阈值、可以解释。

# 面部关键点索引定义（基于68点模型） # 左眼：36-41，右眼：42-47，嘴巴：48-67 LEFT_EYE = list(range(36, 42)) RIGHT_EYE = list(range(42, 48)) MOUTH = list(range(48, 68)) def eye_aspect_ratio(eye_points): """ 计算眼睛纵横比 EAR eye_points: 6个关键点的坐标列表 [(x1,y1), ..., (x6,y6)] 原理：眼睛睁开时垂直距离大，闭合时垂直距离趋近于0 """ # 垂直方向两个距离 A = dist(eye_points[1], eye_points[5]) B = dist(eye_points[2], eye_points[4]) # 水平方向距离 C = dist(eye_points[0], eye_points[3]) ear = (A + B) / (2.0 * C) return ear

这段代码是整个系统的核心。EAR 的计算逻辑是：眼睛睁开时，上下眼睑的垂直距离较大，EAR 值通常在 0.25 到 0.35 之间；眼睛闭合时，垂直距离趋近于零，EAR 值会降到 0.15 以下。这个阈值不是固定的，不同人种、不同光照条件下会有偏移，所以实际部署时通常要做一次基线校准。

提示：EAR 阈值建议在 0.18 到 0.22 之间做初始值，然后根据实际测试微调。不要直接抄网上的 0.3，那个值对亚洲人眼型偏大。

2.3 疲劳判定的多指标融合策略

单靠 EAR 判定疲劳，翻车概率很高。打哈欠的时候眼睛是睁着的，低头看仪表盘的时候眼睛也是睁着的，但这些都可能是疲劳前兆。所以这套方案用了三个指标融合：

• PERCLOS：单位时间内眼睛闭合时间占比，这是疲劳检测的黄金指标，通常取 30 秒或 60 秒窗口
• MAR：嘴巴纵横比，用于检测打哈欠，MAR 超过 0.6 且持续 2 秒以上判定为哈欠
• 头部姿态：通过 solvePnP 计算头部俯仰角和偏航角，低头超过 15 度且持续 3 秒判定为分神

三个指标各自有独立的计数器和阈值，最终报警等级由三者加权决定。这样设计的好处是，答辩时你可以画一张融合逻辑图，每个分支都有依据。

3. 系统总体设计：从摄像头到报警的完整数据流

3.1 四层架构与模块职责划分

整个系统按数据流分成四层，每层职责单一，方便调试和替换。

采集层负责从摄像头读取视频帧，做灰度化和直方图均衡化。这里有个细节：夜间或逆光环境下，直接灰度化会导致人脸检测失败，所以通常的做法是先做自适应直方图均衡化（CLAHE），再送入检测器。

检测层用人脸检测器定位人脸区域，再用关键点预测器提取 68 个面部关键点。Dlib 的检测器精度高但速度慢，MediaPipe 速度快但关键点定义不同。毕设演示用 Dlib 足够，如果追求实时性可以换 MediaPipe。

分析层是核心，计算 EAR、MAR、头部姿态角，维护滑动窗口计数器，输出疲劳状态标志位。

报警层根据疲劳等级触发不同响应：一级疲劳（轻度）在画面上叠加黄色警告文字，二级疲劳（中度）播放提示音，三级疲劳（重度）持续蜂鸣并记录日志。

# 疲劳状态机核心逻辑 class FatigueStateMachine: def __init__(self, ear_thresh=0.2, mar_thresh=0.6, consec_frames=20, yawn_frames=15): self.ear_thresh = ear_thresh # EAR阈值 self.mar_thresh = mar_thresh # MAR阈值 self.consec_frames = consec_frames # 闭眼持续帧数阈值 self.yawn_frames = yawn_frames # 哈欠持续帧数阈值 self.eye_counter = 0 # 闭眼帧计数器 self.yawn_counter = 0 # 哈欠帧计数器 self.fatigue_level = 0 # 0正常 1轻度 2中度 3重度 def update(self, ear, mar, pitch_angle): # 闭眼判定 if ear < self.ear_thresh: self.eye_counter += 1 else: self.eye_counter = 0 # 哈欠判定 if mar > self.mar_thresh: self.yawn_counter += 1 else: self.yawn_counter = 0 # 分级报警 if self.eye_counter > self.consec_frames * 2: self.fatigue_level = 3 elif self.eye_counter > self.consec_frames: self.fatigue_level = 2 elif self.yawn_counter > self.yawn_frames or abs(pitch_angle) > 15: self.fatigue_level = 1 else: self.fatigue_level = 0 return self.fatigue_level

这段状态机代码是整个系统的决策中枢。consec_frames设为 20 意味着在 30fps 下约 0.67 秒的持续闭眼才触发报警，这个值不能太小，否则正常眨眼会误报；也不能太大，否则疲劳响应延迟。yawn_frames设为 15 对应约 0.5 秒的哈欠动作，实际测试中打哈欠通常持续 1 到 3 秒，所以这个阈值偏保守，可以根据场景调整。

3.2 关键参数配置与调优方法

系统里有一组参数直接决定检测灵敏度和误报率，我一般会把这些参数集中放在一个配置文件里，方便答辩时展示调参过程。

# config.py 参数配置表 CONFIG = { "camera_id": 0, # 摄像头编号 "frame_width": 640, # 处理帧宽 "frame_height": 480, # 处理帧高 "ear_threshold": 0.20, # EAR闭眼阈值 "mar_threshold": 0.60, # MAR哈欠阈值 "consec_frames": 20, # 闭眼持续帧数 "yawn_frames": 15, # 哈欠持续帧数 "pitch_threshold": 15, # 低头角度阈值 "perclos_window": 900, # PERCLOS窗口帧数(30秒@30fps) "alarm_sound": True, # 是否开启声音报警 "log_path": "fatigue_log.csv" # 日志保存路径 }

调参的顺序通常是：先固定 MAR 和头部姿态参数，单独调 EAR 阈值，用录制好的睁眼/闭眼视频测试，找到误报和漏报的平衡点；然后调 PERCLOS 窗口大小，窗口越大越稳定但响应越慢；最后调报警分级阈值。这个过程在毕设论文里可以写成“参数敏感性分析”一节，是加分项。

4. 核心模块实现：人脸检测、特征计算与报警触发

4.1 人脸检测与关键点定位的工程细节

人脸检测这一步，很多人直接调库就完事了，但实际跑起来会发现两个问题：一是侧脸检测不到，二是戴眼镜时关键点漂移。这两个问题不解决，演示时摄像头稍微偏一点就翻车。

处理侧脸问题的做法是：先用 Dlib 的正脸检测器，如果连续 N 帧检测不到人脸，切换到基于 CNN 的检测器或者 MediaPipe 的 BlazeFace，后者对侧脸鲁棒性更好。代价是速度慢一些，但毕设演示对实时性要求没那么苛刻。

import dlib import cv2 detector = dlib.get_frontal_face_detector() predictor = dlib.shape_predictor("shape_predictor_68_face_landmarks.dat") def detect_landmarks(frame): """检测人脸并返回68个关键点坐标""" gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) # CLAHE增强对比度，改善逆光检测 clahe = cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8,8)) gray = clahe.apply(gray) faces = detector(gray, 0) if len(faces) == 0: return None, None # 取最大人脸（假设驾驶员是画面中最大的人脸） face = max(faces, key=lambda r: r.width() * r.height()) landmarks = predictor(gray, face) points = [(landmarks.part(i).x, landmarks.part(i).y) for i in range(68)] return face, points

CLAHE 的clipLimit设为 2.0 是经验值，太大反而会放大噪声。tileGridSize设为 8x8 意味着把图像分成 8x8 的块分别做均衡化，这个粒度对 640x480 的图像比较合适。如果摄像头分辨率更高，可以适当增大。

4.2 头部姿态估计的实现

头部姿态用 solvePnP 求解，需要 3D 人脸模型点和对应的 2D 图像点。3D 模型点可以用标准人脸模型的几个关键位置：鼻尖、下巴、左右眼角、左右嘴角，共 6 个点。

import numpy as np # 3D人脸模型参考点（单位：毫米，近似值） MODEL_POINTS = np.array([ (0.0, 0.0, 0.0), # 鼻尖 (0.0, -63.6, -12.5), # 下巴 (-43.3, 32.7, -26.0), # 左眼角 (43.3, 32.7, -26.0), # 右眼角 (-28.9, -28.9, -24.1), # 左嘴角 (28.9, -28.9, -24.1) # 右嘴角 ], dtype=np.float64) # 对应的68点模型索引 LANDMARK_IDS = [30, 8, 36, 45, 48, 54] def estimate_head_pose(landmarks, frame_shape): """估计头部姿态角，返回pitch/yaw/roll""" h, w = frame_shape[:2] focal_length = w center = (w / 2, h / 2) camera_matrix = np.array([ [focal_length, 0, center[0]], [0, focal_length, center[1]], [0, 0, 1] ], dtype=np.float64) dist_coeffs = np.zeros((4, 1)) image_points = np.array([landmarks[i] for i in LANDMARK_IDS], dtype=np.float64) success, rotation_vec, translation_vec = cv2.solvePnP( MODEL_POINTS, image_points, camera_matrix, dist_coeffs, flags=cv2.SOLVEPNP_ITERATIVE ) if not success: return None rotation_mat, _ = cv2.Rodrigues(rotation_vec) # 从旋转矩阵提取欧拉角 pitch = np.arctan2(rotation_mat[2][1], rotation_mat[2][2]) * 180 / np.pi yaw = np.arctan2(-rotation_mat[2][0], np.sqrt(rotation_mat[2][1]**2 + rotation_mat[2][2]**2)) * 180 / np.pi roll = np.arctan2(rotation_mat[1][0], rotation_mat[0][0]) * 180 / np.pi return pitch, yaw, roll

focal_length直接用图像宽度近似，这在没有相机标定数据时是常用做法。SOLVEPNP_ITERATIVE适合点数较少的情况，如果关键点更多可以用SOLVEPNP_EPNP。pitch 角为负值表示低头，正值表示抬头，实际判定疲劳时关注的是低头角度。

4.3 报警触发与日志记录

报警模块要处理两件事：实时画面叠加和日志持久化。画面叠加用 OpenCV 的 putText 和 rectangle，日志用 CSV 格式方便后续分析。

import csv from datetime import datetime class AlarmLogger: def __init__(self, log_path): self.log_path = log_path # 写入表头 with open(log_path, 'w', newline='') as f: writer = csv.writer(f) writer.writerow(['timestamp', 'ear', 'mar', 'pitch', 'fatigue_level', 'event']) def log(self, ear, mar, pitch, level): event_map = {0: 'normal', 1: 'mild', 2: 'moderate', 3: 'severe'} with open(self.log_path, 'a', newline='') as f: writer = csv.writer(f) writer.writerow([ datetime.now().strftime('%Y-%m-%d %H:%M:%S.%f')[:-3], round(ear, 4), round(mar, 4), round(pitch, 2), level, event_map[level] ])

日志里记录时间戳和原始指标值，答辩时可以把 CSV 导入 Excel 画曲线图，展示疲劳发生前后的 EAR 变化趋势。这比单纯说“系统能检测疲劳”有说服力得多。

5. 避坑与常见问题排查：那些演示时最容易翻车的点

5.1 摄像头打不开或画面卡死

现象：程序启动后摄像头指示灯亮但画面全黑，或者运行几秒后卡死。

原因：通常是摄像头被其他程序占用，或者 OpenCV 的 VideoCapture 后端选择不对。Windows 上默认用 MSMF 后端有时会出问题，Linux 上可能是权限问题。

解决：先确认没有其他程序在用摄像头。代码里显式指定后端，Windows 用cv2.CAP_DSHOW，Linux 用cv2.CAP_V4L2。如果还是卡死，加一个帧读取超时判断，连续 10 帧读取失败就释放重连。

cap = cv2.VideoCapture(0, cv2.CAP_DSHOW) # Windows # cap = cv2.VideoCapture(0, cv2.CAP_V4L2) # Linux cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) fail_count = 0 while True: ret, frame = cap.read() if not ret: fail_count += 1 if fail_count > 10: cap.release() cap = cv2.VideoCapture(0, cv2.CAP_DSHOW) fail_count = 0 continue fail_count = 0 # 后续处理...

5.2 正常眨眼被误判为疲劳

现象：人正常眨眼时系统频繁触发一级报警，演示时很尴尬。

原因：consec_frames设得太小，或者 EAR 阈值偏高。正常眨眼持续时间约 0.1 到 0.4 秒，30fps 下对应 3 到 12 帧。如果consec_frames设为 10，刚好卡在眨眼和闭眼的边界上。

解决：把consec_frames提高到 20 以上，确保只有持续闭眼才触发。同时检查 EAR 阈值，如果正常睁眼时 EAR 就在 0.22 左右，阈值设 0.25 会导致频繁误报。建议先跑一段睁眼视频，统计 EAR 的均值和标准差，阈值设为均值减去 2 倍标准差。

5.3 戴眼镜时关键点漂移

现象：戴眼镜的测试者，眼睛关键点定位到镜框上，EAR 计算完全失准。

原因：Dlib 的 68 点模型训练数据中戴眼镜样本偏少，镜框反光会干扰关键点回归。

解决：换用 MediaPipe Face Mesh，它输出 468 个关键点，对眼镜的鲁棒性更好。或者在做关键点定位前，先做一个眼镜检测，如果检测到眼镜，对眼部区域做额外的对比度增强。毕设场景下，最简单的做法是让测试者摘掉眼镜演示，同时在论文里说明这个局限性。

5.4 夜间或暗光环境下检测失效

现象：白天演示正常，晚上或拉窗帘后摄像头画面噪点大，人脸检测直接失败。

原因：普通 RGB 摄像头在低照度下信噪比急剧下降，灰度化后人脸特征几乎不可见。

解决：软件层面加 CLAHE 增强，同时降低检测器的阈值。如果条件允许，用带红外补光的摄像头，这是工程上最直接的方案。毕设论文里可以把“光照鲁棒性”作为一个讨论点，分析不同光照条件下的检测成功率。

5.5 多张人脸时误检

现象：画面里出现两个人时，系统在两张脸之间跳来跳去，报警逻辑混乱。

原因：没有做目标跟踪，每帧独立检测，取最大人脸策略在两人脸大小接近时会抖动。

解决：加一个简单的 IOU 跟踪器，维护上一帧的人脸位置，当前帧选择与上一帧 IOU 最大的人脸。如果 IOU 低于阈值再重新全局检测。这样保证始终跟踪同一个人。

6. 验收与答辩：怎么证明这套系统真的能跑

6.1 功能验收清单

答辩前自己先过一遍这份清单，每项都能演示且能解释原理，基本就稳了。

验收项	操作步骤	预期结果	对应论文章节
人脸检测	正对摄像头	绿框标出人脸	检测层设计
关键点定位	观察眼部区域	68点覆盖五官	特征提取
闭眼报警	闭眼3秒	触发二级报警	状态机逻辑
哈欠报警	张嘴打哈欠	触发一级报警	MAR计算
低头报警	低头看下方	触发一级报警	头部姿态
日志记录	触发报警后查看CSV	有对应时间戳记录	数据持久化
参数可调	修改config后重启	灵敏度变化	参数配置

6.2 答辩时导师最可能问的五个问题

第一个问题通常是“你的疲劳判定依据是什么”。回答时不要只说 EAR，要把 PERCLOS、MAR、头部姿态三个指标都讲出来，说明为什么单指标不够。

第二个问题是“阈值怎么确定的”。这里要展示你的调参过程，比如用录制视频统计 EAR 分布，画直方图找分界点。有数据支撑的阈值比拍脑袋的阈值可信得多。

第三个问题是“误报率多少”。毕设不要求你做大规模测试，但至少要有 5 到 10 个测试样本的统计。可以自己录几段视频，一段正常驾驶、一段模拟疲劳，统计报警次数和实际疲劳次数的比值。

第四个问题是“实时性怎么样”。用time.time()在代码里打点，统计每帧处理耗时，算出 FPS。Dlib 在普通笔记本上大概 10 到 15 FPS，MediaPipe 能到 25 以上。如果 FPS 太低，说明需要优化或者换轻量模型。

第五个问题是“和现有方案比有什么改进”。这个问题比较开放，可以从多指标融合、分级报警、参数可配置这几个角度回答。如果论文里做了对比实验，直接拿数据说话。

6.3 一个让答辩加分的小技巧

答辩演示时，不要只放实时摄像头画面。提前录一段模拟疲劳的视频，用系统跑一遍，把 EAR 曲线和报警时刻标注在同一张图上。这张图能直观展示“疲劳发生时 EAR 下降、系统在 N 帧后触发报警”的完整因果链。导师看到这张图，基本不会再追问判定逻辑的问题。

我自己的习惯是，每次交付这类系统前，都会用三段视频做回归测试：一段正常睁眼、一段频繁眨眼、一段模拟疲劳。三段都跑通，才敢拿去演示。从那以后我每次做视觉类项目都强制走一遍这个流程，省了很多答辩现场翻车的机会。希望这套方案和源码能帮到你，把毕设稳稳拿下。

本文还有配套的精品资源，点击获取