简介压缩包内含一套用于疲劳状态检测的C语言源程序与配套库文件面向从事心电信号分析、驾驶员状态监测的嵌入式开发者或算法研究人员。方案围绕ECG信号采集与处理展开覆盖心率变异性HRV计算、RR间期提取、滤波及模式识别等环节可用于搭建从数据预处理到疲劳判别的完整流程。包内共150个文件以.h头文件、.c源文件、.o目标文件以及.pbi等编译中间文件为主另有filtfilt.c、ecg_detect.c等核心源码结构清晰便于在IAR等环境中重新编译与调试。压缩包整体仅1.51MB适合轻量级实验验证。该资源已吸引95人浏览学习对需要参考ECG信号处理工程实现或快速搭建疲劳检测原型的研究者具有实用参考价值可帮助理解心电图数据从底层读取到特征判断的代码级落地方式。1. 疲劳度检测从“源程序跑通”开始而不是从模型训练开始标题里那串日期和“用源程序及库文件”已经交代了这类工程最真实的形态拿到手的是一份编译好的工程骨架加一堆库文件你要做的是把它跑起来、调准参数、让它适配自己的场景。疲劳度检测这个方向业界几乎不会自己从零训练网络而是走一条更务实的路线用开源的人脸检测和关键点提取库拿到面部特征点再把眼睛的开合程度随时间的变化量化成指标。这个指标要么叫PERCLOS要么叫眨眼频率它们共同构成了疲劳度检测的事实标准。这套方案的好处在于不依赖特殊硬件一个普通USB摄像头就够。它能直接落地的业务包括驾驶员疲劳预警、在线学习专注度分析、以及需要长时间注视屏幕的岗位状态监测。适合的读者是已经在用OpenCV、有基本图像处理概念、但不想从头造轮的工程师。下面不分析任何具体源码包的内部结构只把这类项目最常见的工程路径、阈值设置和翻车点讲清楚。你拿到任何一份类似的源程序和库文件包都能按这套方法把它盘活。2. 疲劳度检测的系统骨架dlib 关键点提取是源程序里的第一道工序2.1 为什么疲劳度检测要用人脸关键点而不是直接图像分类疲劳度检测的核心不是判断“人脸在哪”而是判断“眼睛开合到什么程度”。直接训练一个分类网络判断疲劳与否最大的问题是缺乏物理解释同一个人的眨眼习惯不同、戴眼镜与否都会让模型失效。传统方案里更稳定的是先把人脸关键点提取出来再用几何关系计算眼睛的开合度。这个几何关系在学术界有个标准名字叫眼睛纵横比Eye Aspect Ratio, EAR。它只用关键点坐标就能算出来不需要任何复杂的网络推理而且对光照和肤色的鲁棒性远高于直接灰度判断。这也是为什么几乎所有用源程序分发的疲劳度检测项目内部核心都是围绕关键点检测库展开的。2.2 库文件怎么选OpenCV 负责采集dlib 负责定位疲劳度检测工程里最常见的技术组合是 OpenCV 加 dlib。两个库分工非常明确OpenCV 从摄像头读取帧、做图像预处理、画结果框dlib 负责做人脸检测和人脸关键点定位。dlib 配合其官方发布的 68 点人脸关键点模型shape_predictor_68_face_landmarks.dat能稳定输出眉毛、眼睛、鼻子、嘴巴轮廓的特征点坐标。拿到源程序包后第一件事不是打开代码而是先把库文件归属认清楚。.dat结尾的是 dlib 的模型文件不是动态链接库.dll或.so结尾的是编译好的运行库.lib结尾的是 Windows 下的导入库。很多人在第一步就把三者混为一谈导致程序在load_model那一步反复报错。记住一条经验先把模型文件路径改成绝对路径确认它能被读到再谈后续的代码逻辑。2.3 用 dlib 提取眼睛区域并计算 EAR最小可运行源程序假设 dlib 已经装好且shape_predictor_68_face_landmarks.dat已经下载到当前目录下面这段代码就是从摄像头图像里计算单帧的眼睛纵横比。这是整个疲劳度检测项目里最核心的脚手架。import cv2 import dlib detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) def eye_aspect_ratio(eye): # 垂直方向上的两组关键点距离 vertical_1 ((eye[1][0] - eye[5][0]) ** 2 (eye[1][1] - eye[5][1]) ** 2) ** 0.5 vertical_2 ((eye[2][0] - eye[4][0]) ** 2 (eye[2][1] - eye[4][1]) ** 2) ** 0.5 # 水平方向上的关键点距离 horizontal ((eye[0][0] - eye[3][0]) ** 2 (eye[0][1] - eye[3][1]) ** 2) ** 0.5 ear (vertical_1 vertical_2) / (2.0 * horizontal) return ear def get_frame_ear(frame): gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) faces detector(gray, 1) if len(faces) 0: return None shape predictor(gray, faces[0]) # dlib 68点模型中左眼是36-41右眼是42-47 left_eye [(shape.part(i).x, shape.part(i).y) for i in range(36, 42)] right_eye [(shape.part(i).x, shape.part(i).y) for i in range(42, 48)] ear (eye_aspect_ratio(left_eye) eye_aspect_ratio(right_eye)) / 2.0 return ear cap cv2.VideoCapture(0) while True: ret, frame cap.read() if not ret: break ear get_frame_ear(frame) if ear is not None: # 正常睁眼时EAR约在0.25以上闭眼时约在0.1附近 cv2.putText(frame, fEAR: {ear:.3f}, (30, 30), cv2.FONT_HERSHEY_SIMPLEX, 0.8, (0, 255, 0), 2) cv2.imshow(frame, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()eye_aspect_ratio函数里eye[0]到eye[5]是六个点的坐标。垂直距离取了上下眼睑两组点取平均值做分子水平距离是内外眼角之间的距离做分母。这个比值的物理意义就是眼睛睁开的宽高比例。睁眼时垂直距离占水平距离的比例大EAR 一般在 0.25 到 0.35 之间闭眼时垂直距离几乎为零EAR 会骤降到 0.1 以下。get_frame_ear里先转灰度是因为 dlib 的检测器对灰度图处理更稳定。detector(gray, 1)的第二个参数是上采样次数数值越大越能检测到更小的人脸但推理耗时翻倍。在普通笔记本上默认取 1 就好取 2 的话帧率会明显下降。人脸检测失败时返回None调用方必须处理这个分支否则程序会崩在predictor那一步。2.4 光照和尺度变化时源程序里必须做的预处理疲劳度检测最容易翻车的地方不是算法不够高级而是输入图像质量不稳定。摄像头画面里常见的干扰有逆光导致脸部过暗、侧光导致半边脸有阴影、人脸距离摄像头忽远忽近导致脸部尺寸变化。dlib 的人脸检测器对光照还算容忍但关键点定位的精度会明显受光照影响。一个常用的加固措施是自适应直方图均衡化代码就一行但效果非常明显import cv2 gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) clahe cv2.createCLAHE(clipLimit2.0, tileGridSize(8, 8)) gray clahe.apply(gray)clipLimit控制对比度放大的上限设小了等于没处理设大了会出现噪点。tileGridSize把图像分成小块分别做直方图均衡8x8 是经验值能有效改善局部光照不均同时又不会把整张图的亮度扯变形。在源程序里加这一步的成本极低但对后续 EAR 计算的稳定性提升是肉眼可见的。3. 疲劳度检测的阈值与时间窗口这是源程序调参的重灾区3.1 单帧 EAR 值不能直接判定疲劳必须引入时间维度拿到单帧的 EAR 只能判断“这一刻眼睛开合度”但疲劳检测讲的是“一段时间内的状态”。正常人每几分钟都会有一次无意识眨眼眨眼瞬间 EAR 会短暂跌到阈值以下。如果按单帧低于阈值就报警系统会把所有正常眨眼都当成疲劳事件误报率高到没法用。所以工程里真正会做的是两件事第一设定一个 EAR 阈值来判断眼睛是否闭合第二设定一个持续时间窗口来判断“闭合是否持续了异常长的时间”。眨眼通常持续 100 到 200 毫秒在 25 帧率摄像头下大约占 3 到 5 帧疲劳状态下的闭眼动作持续时间会长很多通常超过 500 毫秒也就是 12 帧以上。3.2 阈值和持续帧数怎么配先看参数表再做个体校准下面是这类系统里一组被反复验证过的初始参数直接抄进源程序里作为默认值就能用。但注意这只是起点每条业务都有自己的特殊性最终阈值必须在实际场景里用录像回放来标定。参数推荐初始值调节方向说明EAR 闭合阈值0.22值越小越不敏感低于该值判定眼睛为闭合状态闭合持续帧数阈值8 帧值越大越抗短暂眨眼连续闭合超过该帧数才判为疲劳闭眼PERCLOS 统计窗口60 秒驾驶员场景建议 60 秒统计窗口内眼睛闭合帧数占比PERCLOS 报警阈值0.4值越大越难触发闭合帧数占比超过 40% 判为疲劳EAR 闭合阈值不建议直接取 0.1那是完全闭合的值取在 0.2 到 0.25 之间是为了留出过渡区间的余量。闭合持续帧数阈值在 25 帧率下取 8 帧对应约 320 毫秒能过滤掉大部分正常眨眼。如果摄像头帧率是 30这个值要相应调整到 10 帧左右。3.3 用状态机统计眨眼次数和闭眼时长与其用一堆 if-else 堆逻辑不如用一个简单状态机来管理“睁眼→闭眼→睁眼”的过程。这样既能统计眨眼次数也能精确计量每次闭眼持续了多少帧为后面的 PERCLOS 计算提供数据基础。class BlinkState: def __init__(self): self.eye_closed_frames 0 self.total_closed_frames 0 self.total_frames 0 self.blink_count 0 self._last_state open def update(self, ear, ear_threshold0.22, close_frames8): self.total_frames 1 if ear ear_threshold: self.eye_closed_frames 1 self.total_closed_frames 1 self._last_state closed else: # 之前是闭眼状态且闭眼帧数超过阈值记为一次眨眼 if self._last_state closed and self.eye_closed_frames close_frames: self.blink_count 1 self._last_state open self.eye_closed_frames 0 return self.blink_count这套状态机里_last_state记录上一帧的状态只有从闭眼跳转到睁眼时才结算一次眨眼。这里有一个容易踩坑的地方眨眼次数的结算时机。如果在眼睛刚闭上的时候就结算那一次长时间闭眼会被重复计算多次。正确做法是看“闭眼结束”这个事件而不是看“闭眼开始”。上面的代码就是在_last_state closed且当前帧睁眼时才把计数加一这样一次闭眼动作无论持续多久都只会被记录一次。3.4 PERCLOS 的计算逻辑和滑动窗口实现PERCLOS 的标准定义是单位时间内眼睛闭合帧数占总帧数的比例。这个概念看着简单实现时有一个隐藏问题用从程序启动开始的全量统计还是用最近 N 秒的滑动窗口全量统计的问题在于用户刚开始精神很好前十分钟的睁眼数据会把平均值拉高导致后面真正疲劳的时候 PERCLOS 涨不上去。必须用滑动窗口。from collections import deque class PerclosCalculator: def __init__(self, window_seconds60, fps25): self.window_size window_seconds * fps self.frame_queue deque(maxlenself.window_size) self.fps fps def add_frame(self, is_closed): # 入队时把判断结果转成 1 或 0 self.frame_queue.append(1 if is_closed else 0) def get_perclos(self): if len(self.frame_queue) self.window_size: return None # 数据不足返回 None 表示窗口未填满 closed_rate sum(self.frame_queue) / len(self.frame_queue) return closed_ratedeque(maxlenN)是最适合做这种滑动窗口的数据结构超过窗口长度时旧数据自动出队不需要手动维护索引。get_perclos在窗口未填满时返回None这是有意的设计避免系统一启动就基于少量数据给出错误的疲劳判断。4. 疲劳度检测的实战升级眨眼频率、打哈欠和头部姿态的三路融合4.1 打哈欠检测嘴部纵横比 MAR 的加入纯靠眼睛开合度判断疲劳有一个盲区有的人疲劳时并不频繁闭眼而是表现为频繁打哈欠。打哈欠检测的思路和眼睛完全对称用嘴部关键点算一个嘴部纵横比Mouth Aspect Ratio, MAR。dlib 的 68 点模型里嘴部轮廓点是第 48 到 68 号。内嘴唇点 61、62、63 和 67、66、65 构成上下嘴唇64 和 68 是嘴角点。def mouth_aspect_ratio(mouth): # 垂直方向两组点 v1 ((mouth[2][0] - mouth[0][0]) ** 2 (mouth[2][1] - mouth[0][1]) ** 2) ** 0.5 v2 ((mouth[3][0] - mouth[1][0]) ** 2 (mouth[3][1] - mouth[1][1]) ** 2) ** 0.5 # 水平方向 h ((mouth[4][0] - mouth[5][0]) ** 2 (mouth[4][1] - mouth[5][1]) ** 2) ** 0.5 return (v1 v2) / (2.0 * h)嘴部纵横比的计算逻辑和 EAR 完全一致但阈值完全不同。嘴巴自然闭合时 MAR 接近 0说话或者在打哈欠时 MAR 会明显抬高。工程上通常取 0.5 以上为张嘴状态连续张嘴超过 2 秒认为是一次哈欠。因为说话也会让嘴部 MAR 波动实际系统里可以用张嘴持续时长来过滤普通说话很少会连续 2 秒大张嘴。4.2 头部姿态估计疲劳时人会不自觉地低头除了眼部和嘴部头部姿态是疲劳检测的第三路信号。疲劳状态下人的头部会逐渐下垂然后突然回正形成一种“点头”模式。dlib 的 68 点模型配合 OpenCV 的solvePnP可以算出头部在三维空间里的旋转角但这个做法需要摄像头的内参矩阵标定比较麻烦。更轻量级的做法是直接用关键点之间的几何关系估计俯仰角比如计算鼻尖到左右耳连线的垂直距离变化人低头时鼻尖位置相对于两眼的连线会下移。这种方式虽然不够精确但胜在不需要相机标定而且对疲劳检测这种只关心相对变化的场景足够了。多种信号组合时一般给眼睛状态最高权重因为 PERCLOS 是文献支持最充分的指标哈欠检测次之头部姿态最后。4.3 三路判断的逻辑组合一票触发还是加权计算把三路信号融合有一票触发和加权评分两种策略。一票触发即眼睛、哈欠、头部任一指标超限就报警优点是召回率高缺点是误报也高戴眼镜、遮挡等情况会引入干扰。加权评分是给各个指标分配权重综合得分超过阈值才报警抗干扰能力更强。常见的经验权重是PERCLOS 占 0.5哈欠频率占 0.3低头频率占 0.2。这个比例不是拍脑袋定的它背后依据是文献中眼部指标和疲劳程度的相关性最强。实际项目里可以通过配一个简单的权重表来做灰度调节让业务方根据现场反馈调整。需要特别注意的是头部姿态检测受摄像头安装位置影响非常大摄像头装正前方和斜上方低头时的几何变化方向完全不同所以这一路信号在落地到不同场景时往往需要单独调试。5. 疲劳度检测的验证方法与误报抑制的实用技巧5.1 录制视频回放把参数标定从现场搬到电脑上调参最大的误区是在实验室对着摄像头反复模拟眨眼这既没法复现又浪费时间。正确的做法是录制三段带有时间戳的视频一段正常状态、一段模拟疲劳状态刻意放慢眨眼、频繁打哈欠、一段正常状态但伴随频繁揉眼睛和低头看手机。然后把疲劳度检测源程序改造成支持读取视频文件而不是摄像头跑这三段视频把 EAR、MAR 和 PERCLOS 的曲线导出来用图像看曲线的形态再决定阈值取多少。视频回放还有一个额外的价值可以逐帧检查关键点定位是否准确。疲劳度检测的所有指标都建立在关键点坐标之上如果关键点漂移了后面的计算再精确也失去意义。在关键点上叠加显示坐标用视频慢放观察几个典型的困难帧通常能发现人脸侧转超过 60 度或者手遮挡脸部时关键点会乱跳这类帧要么过滤掉要么标记为无效帧。5.2 针对不同人做基线校准避免阈值一刀切EAR 的绝对值因人而异眼睛大的人和眼睛小的人在正常睁眼状态下 EAR 可能相差 0.05 以上。如果用一个固定的闭合阈值眼睛小的人可能还没眨眼就被误判为闭合。更科学的做法是每次检测开始前做一个三秒钟的校准环节让用户正常睁眼看镜头系统记录这段时期的平均 EAR 作为基线闭合阈值取基线的 60% 到 70%。校准期间计算的眨眼频率基线也有用。正常情况下成人的眨眼频率是每分钟 10 到 20 次但疲劳状态下有两个典型变化方向一是眨眼频率骤降降到每分钟 5 次以下二是单个眨眼的持续时间拉长从正常的 100 到 200 毫秒变成 400 毫秒以上。把这两个特征都纳入判断误报率会比只看阈值低很多。5.3 用时间序列平滑消除瞬间跳变从摄像头原始帧算出来的 EAR 是带噪声的光照波动、面部肌肉微小抖动都会让数值出现瞬间跳变。常见的处理方式是做一个轻量级的一阶低通滤波smoothed_ear alpha * current_ear (1 - alpha) * smoothed_ear其中alpha取 0.3 到 0.5 比较合适。alpha越大响应越快但噪声也越大越小曲线越平滑但会引入明显延迟。在疲劳检测这种对实时性要求不高的场景里宁可让响应稍微慢半秒也要保证曲线的稳定性避免在图像处理流水线里引入不必要的误触发。最后一条经验疲劳度检测系统上线前至少要跑满一个完整的 10 分钟视频数据集统计出误报次数和漏报次数再根据错误类型反向调整参数而不是边跑边改。这样才能把源程序里的各个参数从“能跑”变成“靠谱”。本文还有配套的精品资源点击获取
疲劳度检测工程实战：dlib关键点提取与EAR/PERCLOS阈值调优
简介压缩包内含一套用于疲劳状态检测的C语言源程序与配套库文件面向从事心电信号分析、驾驶员状态监测的嵌入式开发者或算法研究人员。方案围绕ECG信号采集与处理展开覆盖心率变异性HRV计算、RR间期提取、滤波及模式识别等环节可用于搭建从数据预处理到疲劳判别的完整流程。包内共150个文件以.h头文件、.c源文件、.o目标文件以及.pbi等编译中间文件为主另有filtfilt.c、ecg_detect.c等核心源码结构清晰便于在IAR等环境中重新编译与调试。压缩包整体仅1.51MB适合轻量级实验验证。该资源已吸引95人浏览学习对需要参考ECG信号处理工程实现或快速搭建疲劳检测原型的研究者具有实用参考价值可帮助理解心电图数据从底层读取到特征判断的代码级落地方式。1. 疲劳度检测从“源程序跑通”开始而不是从模型训练开始标题里那串日期和“用源程序及库文件”已经交代了这类工程最真实的形态拿到手的是一份编译好的工程骨架加一堆库文件你要做的是把它跑起来、调准参数、让它适配自己的场景。疲劳度检测这个方向业界几乎不会自己从零训练网络而是走一条更务实的路线用开源的人脸检测和关键点提取库拿到面部特征点再把眼睛的开合程度随时间的变化量化成指标。这个指标要么叫PERCLOS要么叫眨眼频率它们共同构成了疲劳度检测的事实标准。这套方案的好处在于不依赖特殊硬件一个普通USB摄像头就够。它能直接落地的业务包括驾驶员疲劳预警、在线学习专注度分析、以及需要长时间注视屏幕的岗位状态监测。适合的读者是已经在用OpenCV、有基本图像处理概念、但不想从头造轮的工程师。下面不分析任何具体源码包的内部结构只把这类项目最常见的工程路径、阈值设置和翻车点讲清楚。你拿到任何一份类似的源程序和库文件包都能按这套方法把它盘活。2. 疲劳度检测的系统骨架dlib 关键点提取是源程序里的第一道工序2.1 为什么疲劳度检测要用人脸关键点而不是直接图像分类疲劳度检测的核心不是判断“人脸在哪”而是判断“眼睛开合到什么程度”。直接训练一个分类网络判断疲劳与否最大的问题是缺乏物理解释同一个人的眨眼习惯不同、戴眼镜与否都会让模型失效。传统方案里更稳定的是先把人脸关键点提取出来再用几何关系计算眼睛的开合度。这个几何关系在学术界有个标准名字叫眼睛纵横比Eye Aspect Ratio, EAR。它只用关键点坐标就能算出来不需要任何复杂的网络推理而且对光照和肤色的鲁棒性远高于直接灰度判断。这也是为什么几乎所有用源程序分发的疲劳度检测项目内部核心都是围绕关键点检测库展开的。2.2 库文件怎么选OpenCV 负责采集dlib 负责定位疲劳度检测工程里最常见的技术组合是 OpenCV 加 dlib。两个库分工非常明确OpenCV 从摄像头读取帧、做图像预处理、画结果框dlib 负责做人脸检测和人脸关键点定位。dlib 配合其官方发布的 68 点人脸关键点模型shape_predictor_68_face_landmarks.dat能稳定输出眉毛、眼睛、鼻子、嘴巴轮廓的特征点坐标。拿到源程序包后第一件事不是打开代码而是先把库文件归属认清楚。.dat结尾的是 dlib 的模型文件不是动态链接库.dll或.so结尾的是编译好的运行库.lib结尾的是 Windows 下的导入库。很多人在第一步就把三者混为一谈导致程序在load_model那一步反复报错。记住一条经验先把模型文件路径改成绝对路径确认它能被读到再谈后续的代码逻辑。2.3 用 dlib 提取眼睛区域并计算 EAR最小可运行源程序假设 dlib 已经装好且shape_predictor_68_face_landmarks.dat已经下载到当前目录下面这段代码就是从摄像头图像里计算单帧的眼睛纵横比。这是整个疲劳度检测项目里最核心的脚手架。import cv2 import dlib detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) def eye_aspect_ratio(eye): # 垂直方向上的两组关键点距离 vertical_1 ((eye[1][0] - eye[5][0]) ** 2 (eye[1][1] - eye[5][1]) ** 2) ** 0.5 vertical_2 ((eye[2][0] - eye[4][0]) ** 2 (eye[2][1] - eye[4][1]) ** 2) ** 0.5 # 水平方向上的关键点距离 horizontal ((eye[0][0] - eye[3][0]) ** 2 (eye[0][1] - eye[3][1]) ** 2) ** 0.5 ear (vertical_1 vertical_2) / (2.0 * horizontal) return ear def get_frame_ear(frame): gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) faces detector(gray, 1) if len(faces) 0: return None shape predictor(gray, faces[0]) # dlib 68点模型中左眼是36-41右眼是42-47 left_eye [(shape.part(i).x, shape.part(i).y) for i in range(36, 42)] right_eye [(shape.part(i).x, shape.part(i).y) for i in range(42, 48)] ear (eye_aspect_ratio(left_eye) eye_aspect_ratio(right_eye)) / 2.0 return ear cap cv2.VideoCapture(0) while True: ret, frame cap.read() if not ret: break ear get_frame_ear(frame) if ear is not None: # 正常睁眼时EAR约在0.25以上闭眼时约在0.1附近 cv2.putText(frame, fEAR: {ear:.3f}, (30, 30), cv2.FONT_HERSHEY_SIMPLEX, 0.8, (0, 255, 0), 2) cv2.imshow(frame, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()eye_aspect_ratio函数里eye[0]到eye[5]是六个点的坐标。垂直距离取了上下眼睑两组点取平均值做分子水平距离是内外眼角之间的距离做分母。这个比值的物理意义就是眼睛睁开的宽高比例。睁眼时垂直距离占水平距离的比例大EAR 一般在 0.25 到 0.35 之间闭眼时垂直距离几乎为零EAR 会骤降到 0.1 以下。get_frame_ear里先转灰度是因为 dlib 的检测器对灰度图处理更稳定。detector(gray, 1)的第二个参数是上采样次数数值越大越能检测到更小的人脸但推理耗时翻倍。在普通笔记本上默认取 1 就好取 2 的话帧率会明显下降。人脸检测失败时返回None调用方必须处理这个分支否则程序会崩在predictor那一步。2.4 光照和尺度变化时源程序里必须做的预处理疲劳度检测最容易翻车的地方不是算法不够高级而是输入图像质量不稳定。摄像头画面里常见的干扰有逆光导致脸部过暗、侧光导致半边脸有阴影、人脸距离摄像头忽远忽近导致脸部尺寸变化。dlib 的人脸检测器对光照还算容忍但关键点定位的精度会明显受光照影响。一个常用的加固措施是自适应直方图均衡化代码就一行但效果非常明显import cv2 gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) clahe cv2.createCLAHE(clipLimit2.0, tileGridSize(8, 8)) gray clahe.apply(gray)clipLimit控制对比度放大的上限设小了等于没处理设大了会出现噪点。tileGridSize把图像分成小块分别做直方图均衡8x8 是经验值能有效改善局部光照不均同时又不会把整张图的亮度扯变形。在源程序里加这一步的成本极低但对后续 EAR 计算的稳定性提升是肉眼可见的。3. 疲劳度检测的阈值与时间窗口这是源程序调参的重灾区3.1 单帧 EAR 值不能直接判定疲劳必须引入时间维度拿到单帧的 EAR 只能判断“这一刻眼睛开合度”但疲劳检测讲的是“一段时间内的状态”。正常人每几分钟都会有一次无意识眨眼眨眼瞬间 EAR 会短暂跌到阈值以下。如果按单帧低于阈值就报警系统会把所有正常眨眼都当成疲劳事件误报率高到没法用。所以工程里真正会做的是两件事第一设定一个 EAR 阈值来判断眼睛是否闭合第二设定一个持续时间窗口来判断“闭合是否持续了异常长的时间”。眨眼通常持续 100 到 200 毫秒在 25 帧率摄像头下大约占 3 到 5 帧疲劳状态下的闭眼动作持续时间会长很多通常超过 500 毫秒也就是 12 帧以上。3.2 阈值和持续帧数怎么配先看参数表再做个体校准下面是这类系统里一组被反复验证过的初始参数直接抄进源程序里作为默认值就能用。但注意这只是起点每条业务都有自己的特殊性最终阈值必须在实际场景里用录像回放来标定。参数推荐初始值调节方向说明EAR 闭合阈值0.22值越小越不敏感低于该值判定眼睛为闭合状态闭合持续帧数阈值8 帧值越大越抗短暂眨眼连续闭合超过该帧数才判为疲劳闭眼PERCLOS 统计窗口60 秒驾驶员场景建议 60 秒统计窗口内眼睛闭合帧数占比PERCLOS 报警阈值0.4值越大越难触发闭合帧数占比超过 40% 判为疲劳EAR 闭合阈值不建议直接取 0.1那是完全闭合的值取在 0.2 到 0.25 之间是为了留出过渡区间的余量。闭合持续帧数阈值在 25 帧率下取 8 帧对应约 320 毫秒能过滤掉大部分正常眨眼。如果摄像头帧率是 30这个值要相应调整到 10 帧左右。3.3 用状态机统计眨眼次数和闭眼时长与其用一堆 if-else 堆逻辑不如用一个简单状态机来管理“睁眼→闭眼→睁眼”的过程。这样既能统计眨眼次数也能精确计量每次闭眼持续了多少帧为后面的 PERCLOS 计算提供数据基础。class BlinkState: def __init__(self): self.eye_closed_frames 0 self.total_closed_frames 0 self.total_frames 0 self.blink_count 0 self._last_state open def update(self, ear, ear_threshold0.22, close_frames8): self.total_frames 1 if ear ear_threshold: self.eye_closed_frames 1 self.total_closed_frames 1 self._last_state closed else: # 之前是闭眼状态且闭眼帧数超过阈值记为一次眨眼 if self._last_state closed and self.eye_closed_frames close_frames: self.blink_count 1 self._last_state open self.eye_closed_frames 0 return self.blink_count这套状态机里_last_state记录上一帧的状态只有从闭眼跳转到睁眼时才结算一次眨眼。这里有一个容易踩坑的地方眨眼次数的结算时机。如果在眼睛刚闭上的时候就结算那一次长时间闭眼会被重复计算多次。正确做法是看“闭眼结束”这个事件而不是看“闭眼开始”。上面的代码就是在_last_state closed且当前帧睁眼时才把计数加一这样一次闭眼动作无论持续多久都只会被记录一次。3.4 PERCLOS 的计算逻辑和滑动窗口实现PERCLOS 的标准定义是单位时间内眼睛闭合帧数占总帧数的比例。这个概念看着简单实现时有一个隐藏问题用从程序启动开始的全量统计还是用最近 N 秒的滑动窗口全量统计的问题在于用户刚开始精神很好前十分钟的睁眼数据会把平均值拉高导致后面真正疲劳的时候 PERCLOS 涨不上去。必须用滑动窗口。from collections import deque class PerclosCalculator: def __init__(self, window_seconds60, fps25): self.window_size window_seconds * fps self.frame_queue deque(maxlenself.window_size) self.fps fps def add_frame(self, is_closed): # 入队时把判断结果转成 1 或 0 self.frame_queue.append(1 if is_closed else 0) def get_perclos(self): if len(self.frame_queue) self.window_size: return None # 数据不足返回 None 表示窗口未填满 closed_rate sum(self.frame_queue) / len(self.frame_queue) return closed_ratedeque(maxlenN)是最适合做这种滑动窗口的数据结构超过窗口长度时旧数据自动出队不需要手动维护索引。get_perclos在窗口未填满时返回None这是有意的设计避免系统一启动就基于少量数据给出错误的疲劳判断。4. 疲劳度检测的实战升级眨眼频率、打哈欠和头部姿态的三路融合4.1 打哈欠检测嘴部纵横比 MAR 的加入纯靠眼睛开合度判断疲劳有一个盲区有的人疲劳时并不频繁闭眼而是表现为频繁打哈欠。打哈欠检测的思路和眼睛完全对称用嘴部关键点算一个嘴部纵横比Mouth Aspect Ratio, MAR。dlib 的 68 点模型里嘴部轮廓点是第 48 到 68 号。内嘴唇点 61、62、63 和 67、66、65 构成上下嘴唇64 和 68 是嘴角点。def mouth_aspect_ratio(mouth): # 垂直方向两组点 v1 ((mouth[2][0] - mouth[0][0]) ** 2 (mouth[2][1] - mouth[0][1]) ** 2) ** 0.5 v2 ((mouth[3][0] - mouth[1][0]) ** 2 (mouth[3][1] - mouth[1][1]) ** 2) ** 0.5 # 水平方向 h ((mouth[4][0] - mouth[5][0]) ** 2 (mouth[4][1] - mouth[5][1]) ** 2) ** 0.5 return (v1 v2) / (2.0 * h)嘴部纵横比的计算逻辑和 EAR 完全一致但阈值完全不同。嘴巴自然闭合时 MAR 接近 0说话或者在打哈欠时 MAR 会明显抬高。工程上通常取 0.5 以上为张嘴状态连续张嘴超过 2 秒认为是一次哈欠。因为说话也会让嘴部 MAR 波动实际系统里可以用张嘴持续时长来过滤普通说话很少会连续 2 秒大张嘴。4.2 头部姿态估计疲劳时人会不自觉地低头除了眼部和嘴部头部姿态是疲劳检测的第三路信号。疲劳状态下人的头部会逐渐下垂然后突然回正形成一种“点头”模式。dlib 的 68 点模型配合 OpenCV 的solvePnP可以算出头部在三维空间里的旋转角但这个做法需要摄像头的内参矩阵标定比较麻烦。更轻量级的做法是直接用关键点之间的几何关系估计俯仰角比如计算鼻尖到左右耳连线的垂直距离变化人低头时鼻尖位置相对于两眼的连线会下移。这种方式虽然不够精确但胜在不需要相机标定而且对疲劳检测这种只关心相对变化的场景足够了。多种信号组合时一般给眼睛状态最高权重因为 PERCLOS 是文献支持最充分的指标哈欠检测次之头部姿态最后。4.3 三路判断的逻辑组合一票触发还是加权计算把三路信号融合有一票触发和加权评分两种策略。一票触发即眼睛、哈欠、头部任一指标超限就报警优点是召回率高缺点是误报也高戴眼镜、遮挡等情况会引入干扰。加权评分是给各个指标分配权重综合得分超过阈值才报警抗干扰能力更强。常见的经验权重是PERCLOS 占 0.5哈欠频率占 0.3低头频率占 0.2。这个比例不是拍脑袋定的它背后依据是文献中眼部指标和疲劳程度的相关性最强。实际项目里可以通过配一个简单的权重表来做灰度调节让业务方根据现场反馈调整。需要特别注意的是头部姿态检测受摄像头安装位置影响非常大摄像头装正前方和斜上方低头时的几何变化方向完全不同所以这一路信号在落地到不同场景时往往需要单独调试。5. 疲劳度检测的验证方法与误报抑制的实用技巧5.1 录制视频回放把参数标定从现场搬到电脑上调参最大的误区是在实验室对着摄像头反复模拟眨眼这既没法复现又浪费时间。正确的做法是录制三段带有时间戳的视频一段正常状态、一段模拟疲劳状态刻意放慢眨眼、频繁打哈欠、一段正常状态但伴随频繁揉眼睛和低头看手机。然后把疲劳度检测源程序改造成支持读取视频文件而不是摄像头跑这三段视频把 EAR、MAR 和 PERCLOS 的曲线导出来用图像看曲线的形态再决定阈值取多少。视频回放还有一个额外的价值可以逐帧检查关键点定位是否准确。疲劳度检测的所有指标都建立在关键点坐标之上如果关键点漂移了后面的计算再精确也失去意义。在关键点上叠加显示坐标用视频慢放观察几个典型的困难帧通常能发现人脸侧转超过 60 度或者手遮挡脸部时关键点会乱跳这类帧要么过滤掉要么标记为无效帧。5.2 针对不同人做基线校准避免阈值一刀切EAR 的绝对值因人而异眼睛大的人和眼睛小的人在正常睁眼状态下 EAR 可能相差 0.05 以上。如果用一个固定的闭合阈值眼睛小的人可能还没眨眼就被误判为闭合。更科学的做法是每次检测开始前做一个三秒钟的校准环节让用户正常睁眼看镜头系统记录这段时期的平均 EAR 作为基线闭合阈值取基线的 60% 到 70%。校准期间计算的眨眼频率基线也有用。正常情况下成人的眨眼频率是每分钟 10 到 20 次但疲劳状态下有两个典型变化方向一是眨眼频率骤降降到每分钟 5 次以下二是单个眨眼的持续时间拉长从正常的 100 到 200 毫秒变成 400 毫秒以上。把这两个特征都纳入判断误报率会比只看阈值低很多。5.3 用时间序列平滑消除瞬间跳变从摄像头原始帧算出来的 EAR 是带噪声的光照波动、面部肌肉微小抖动都会让数值出现瞬间跳变。常见的处理方式是做一个轻量级的一阶低通滤波smoothed_ear alpha * current_ear (1 - alpha) * smoothed_ear其中alpha取 0.3 到 0.5 比较合适。alpha越大响应越快但噪声也越大越小曲线越平滑但会引入明显延迟。在疲劳检测这种对实时性要求不高的场景里宁可让响应稍微慢半秒也要保证曲线的稳定性避免在图像处理流水线里引入不必要的误触发。最后一条经验疲劳度检测系统上线前至少要跑满一个完整的 10 分钟视频数据集统计出误报次数和漏报次数再根据错误类型反向调整参数而不是边跑边改。这样才能把源程序里的各个参数从“能跑”变成“靠谱”。本文还有配套的精品资源点击获取
