疲劳度检测工程实战：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, f"EAR: {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(clipLimit=2.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.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_threshold=0.22, close_frames=8): 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_seconds=60, fps=25): self.window_size = window_seconds * fps self.frame_queue = deque(maxlen=self.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_rate

deque(maxlen=N)是最适合做这种滑动窗口的数据结构，超过窗口长度时旧数据自动出队，不需要手动维护索引。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 分钟视频数据集，统计出误报次数和漏报次数，再根据错误类型反向调整参数，而不是边跑边改。这样才能把源程序里的各个参数从“能跑”变成“靠谱”。

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