从老压缩包到可用系统：视觉疲劳度检测的完整复跑指南

简介：面向疲劳度检测开发的完整源码与库文件包，适用于从事心电信号分析、驾驶安全监控或嵌入式算法研究的工程师与学生，也可作为生物医学工程课程设计与毕业设计的参考项目。压缩包共150个文件，大小约1.51MB，包含C语言源文件、头文件、编译生成的目标文件与静态库文件，以及工程配置、调试映射和批处理脚本，整体结构清晰，便于直接查看和二次编译。已有95人学习。内容覆盖心电信号预处理、基线漂移与高频干扰滤波、RR间期提取、心率变异性计算，以及基于特征分类的疲劳状态判别，完整串联从原始信号到最终检测结果的流程。源码在滤波、特征提取和模式识别等环节均采用模块化实现，并在分类部分预留经典机器学习算法接口，可帮助学习者快速建立疲劳检测的系统认识，也为后续移植到嵌入式平台或扩展实时监测功能提供可参考的工程基础。

1. 一个老压缩包背后的疲劳度检测工程：它在解决什么问题

打开老硬盘翻项目的时候，经常会看到类似“2017_10_27用源程序及库文件.rar_疲劳_疲劳度检测”这种命名的压缩包。这类包很典型：一个日期快照，一段源程序，一堆第三方库文件，目标就是做基于视觉的疲劳度检测。疲劳度检测的核心是透过摄像头判断人是否疲劳，最常见的做法是盯住眼睛——人疲劳之后眨眼变慢、眼睑闭合时间变长，用PERCLOS这类指标量化。它不需要脑电电极，成本低、复现快，所以一直是毕设、课程设计和预研项目里的常客。但真正把老包跑起来并不轻松：库文件版本对不上、阈值照抄论文、路径里带中文，处处都可能翻车。这篇笔记就按这种老包的完整路径讲：从解压到跑通，再把阈值调成能用的状态。

2. 把 rar 安全打开：源程序与库文件的解压、选型与目录核对

拿到老工程 rar 包，先别急着双击压缩包里的 exe。第一个分水岭就是 rar 解压软件。如果你电脑里只装了系统自带资源管理器，遇到稍微老一点的 rar 格式就经常解压失败，或者只解出一部分就报错。常见做法是装 7-Zip 或 WinRAR。我一般优先用 7-Zip，原因很朴素：完全免费、没有任何弹窗广告，不会在每次解压的间隙给你展示一个 rar 广告。总有人问 7zip 可以解压 rar 文件吗，答案是可以，7-Zip 对 RAR 格式的解压支持已经很成熟，右键菜单直接提取即可。WinRAR 当然也能解，但试用版会在退出时弹广告，这也是很多老工程师最终只留 7-Zip 的原因。

2.1 7-Zip 还是 WinRAR：rar 解压与密码包先避坑

在下载源程序包这件事上，我踩过一次印象很深的坑：包名写着“源代码”，解压到一半提示需要密码，于是去搜“rar密码移除”之类的工具，结果全是挂着羊头卖狗肉的捆绑安装包，不但解不开原包，还差点把电脑搞出一堆弹窗。正经的项目源程序包极少设置压缩密码，凡是要求“关注公众号获取解压密码”的资源站压缩包，内容往往是从别处搬运的残缺版本，不值得为它花时间。免费且无广告的 7-Zip 能处理绝大多数 rar 解压需求，只有少数用了特殊算法的压缩包会解不开，这时再临时装 WinRAR 也不迟。

除了工具选择，解压前最好先让杀毒软件扫一遍包。老工程的库文件经常被杀毒误报，尤其是 dll 和旧版编译器生成的可执行文件。先扫描再解压，比解压后库文件被吞掉再排查要省心得多。如果你用的压缩软件支持“解压后校验”，也顺手打开，防止从网盘拉下来的包本身已经损坏。

2.2 解压后先做的三件事：目录结构、库文件版本、缺不缺关键文件

解压完成之后不要马上双击 exe。打开目录先看三样东西：目录结构是谁写的、库文件版本是多少、关键模型文件在不在。老工程通常长这样：

• src或code目录：源程序，可能是.cpp、.py、.m，也可能是一整个 Visual Studio 工程。
• lib、library或third_party目录：库文件，常见的有opencv_world330.dll、opencv_core2410.dll、libdlib.so之类。
• model或data目录：模型文件，比如shape_predictor_68_face_landmarks.dat、haarcascade_frontalface_default.xml。
• doc或readme目录：说明文档、实验报告、依赖清单。

我自己在核对时会先列一张文件清单，按“作用、缺失后果”标注好：

核对文件清单最直接的方法是列目录。Windows 下用tree /F，Linux/macOS 下用find。这个操作快，能立刻看出源程序、库文件、模型文件的比例是否正常。

# Windows 命令行，列出解压目录下所有文件 tree /F # Linux / macOS 下，显示前 3 层文件 find . -maxdepth 3 -type f | sort

tree /F的好处是能看到完整路径，方便你发现把库文件放到model目录这种错位问题。find走的是纯文件路径，适合脚本继续处理。看到文件清单后，最重要的一件事是核对库文件版本号。很多老包的库文件名里直接带版本，比如opencv_world330.dll对应 OpenCV 3.3.0，opencv_core2410.dll对应 OpenCV 2.4.10；如果 readme 说工程基于 OpenCV 2.4，但解压出来的库是 3.x，那就不要急着跑，先按版本补齐依赖。2017 年前后的疲劳度检测工程，很大比例是 OpenCV 2.4/3.x 加 dlib 18/19 的组合，这些版本之间接口差异很大，后面编译或导入阶段一定会暴露出来。

缺关键文件时，不要直接在搜索引擎里搜“某 dll 下载”。网上那些单独的 dll 下载站可能就是捆绑和病毒源。正确做法是回到原始 rar 包里看看是否被杀毒软件吞了，或者找开发机上的原始库文件目录复制。老工程讲究的是“环境匹配”，不是“版本最新”。

3. 跑通疲劳度检测的最小闭环：人脸关键点、眼睑开合与 PERCLOS

解压完、文件核对完，就开始理解这个包里的核心逻辑。疲劳度检测程序做了这么多年，十有八九是基于眼睑闭合程度来判定疲劳的，再扩展一点会加入哈欠检测、头部姿态估计。核心链路不复杂：先做人脸检测，再从人脸上定位眼睛轮廓，接着根据眼睑开合距离判断眼睛有没有闭，最后统计单位时间闭眼占比，超过阈值就报警。这个闭眼占比，在论文里叫 PERCLOS，是疲劳度检测里被验证最充分的指标。

3.1 为什么要盯着眼睛看：疲劳状态到 EAR 的映射

人清醒时每分钟眨眼约 15 到 20 次，每次闭眼时间只有 100 到 150 毫秒。进入疲劳状态后，眨眼频率会下降，但单次闭眼持续时间明显变长，有时会超过 500 毫秒。PERCLOS 就是利用这个时长差：在一段统计窗口内，计算“眼睑遮住瞳孔面积超过 80%”的帧数占总帧数的比例，闭眼时间越长，比例越高，也就越疲劳。

不过，老工程里的源程序很少直接测量瞳孔面积，因为摄像头分辨率不够稳定，瞳孔分割容易受反光干扰。更普遍的做法是用关键点坐标算一个眼睛纵横比 EAR，也就是 Eye Aspect Ratio。计算方式是从眼睛周围取 6 个关键点，计算眼睑垂直距离与水平距离的比。眼睛睁开时 EAR 大约在 0.25 到 0.35 之间，闭眼时降到 0.1 以下。用 EAR 替代瞳孔面积，好处是计算稳定，只需要一个 68 点关键点模型，这正好是 dlib 和 OpenCV 时代最常见的技术栈。

你可以理解为：源程序先检测人脸，然后把人脸区域的灰度图传给关键点模型，拿到 68 个点之后，只取左右眼的 6 个点算 EAR。EAR 低于预设阈值，就认为当前帧是闭眼帧。接着用一个统计窗口计算闭眼帧占比，占比超过设定值就触发疲劳报警。这也是为什么“疲劳度检测”和“眨眼检测”经常出现在同一套代码里——它们共用同一个 EAR 计算过程。

3.2 老工程里最常见的三种实现框架

看老包源码时，先判断它属于哪一类实现，再决定怎么调。2017 年左右的源程序，集中在三种框架：

第一种，OpenCV Haar 级联检测人脸，再通过肤色或边缘检测找眼睛，最后用瞳孔黑色区域面积判断闭合。这类实现依赖haarcascade_frontalface_default.xml和haarcascade_eye.xml，优点是源码短、OpenCV 直接自带模型，缺点是戴眼镜或光线偏暗时误检率很高。

第二种，Dlib 检测人脸关键点，用 68 点模型算 EAR，再按 PERCLOS 判定。这是目前存量代码里最常见的一类，代码里通常会出现shape_predictor_68_face_landmarks.dat，这也是为什么我会第一时间确认这个模型文件在不在。

第三种，用卷积网络直接分类“睁眼/闭眼”，需要训练数据和显卡，2017 年的课程设计或工业 demo 很少见，除非是论文开源代码。

大部分压缩包里的“源程序及库文件”，对应的是第二种。你可以先搜源码里的函数名确认：出现dlib::shape_predictor、get_frontal_face_detector是第二种；出现cvHaarDetectObjects或CascadeClassifier是第一种。区分清楚之后，后面调参的方向就明确多了。

3.3 最小启动代码：加载库文件和模型，输出每一帧的疲劳分数

假设你按老工程思路自己搭一套最小可跑的代码，最现实的方式是用 Python 配 OpenCV 和 dlib。这段代码不是让你直接替换老源码，而是用来验证“源程序 + 库文件 + 模型”这套组合是否工作正常。

import cv2 import dlib from math import hypot # 加载库文件和模型 detector = dlib.get_frontal_face_detector() predictor = dlib.shape_predictor("model/shape_predictor_68_face_landmarks.dat") def eye_aspect_ratio(eye): # 眼睛垂直方向两点距离 A、B，水平方向两点距离 C A = hypot(eye[1].x - eye[5].x, eye[1].y - eye[5].y) B = hypot(eye[2].x - eye[4].x, eye[2].y - eye[4].y) C = hypot(eye[0].x - eye[3].x, eye[0].y - eye[3].y) return (A + B) / (2.0 * C) # 主循环：读取摄像头帧 cap = cv2.VideoCapture(0) closed_frames = 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: landmarks = predictor(gray, face) left_eye = landmarks.parts()[42:48] right_eye = landmarks.parts()[36:42] ear_left = eye_aspect_ratio(left_eye) ear_right = eye_aspect_ratio(right_eye) ear = (ear_left + ear_right) / 2.0 # EAR 低于阈值，累加闭眼帧数 if ear < 0.25: closed_frames += 1 else: closed_frames = 0 # 用最近 20 帧窗口近似 PERCLOS fatigue_score = closed_frames / 20.0 print(f"EAR={ear:.2f} fatigue_score={fatigue_score:.2f}")

逻辑说明：detector是 dlib 自带的人脸检测器，不需要额外库文件，但predictor必须加载shape_predictor_68_face_landmarks.dat，这个模型文件就是老包里最容易缺失的资源。eye_aspect_ratio按 6 个关键点计算 EAR，左右眼各算一次再取平均，能抵消部分左右脸光照不一致带来的偏差。ear < 0.25是初始阈值，当低于阈值时closed_frames累加，一旦睁眼立刻清零。fatigue_score是“最近 20 帧里闭眼帧的占比”，这是一种很简化的 PERCLOS 近似。

这段代码的参数不是标准答案。阈值 0.25 只是起点，窗口 20 帧也取决于摄像头帧率。如果摄像头是 30 帧每秒，20 帧窗口只对应 0.67 秒，实际疲劳判定至少要看 10 秒以上。所以这段最小代码一方面用来验证光路、库文件、模型都没问题，另一方面是让你打印 EAR 的真实现值，为后面调参数提供依据。

如果老工程的源程序是 C++ 写的，思路完全一样。库文件对应opencv_world330.dll和dlib.lib，函数名只是从 Python 的cv2变成cv::VideoCapture，从dlib.shape_predictor变成dlib::shape_predictor。你不需要重新发明算法，只需要把自己的摄像头索引、模型路径、EAR 阈值替换进去。

4. 把参数钉死：EAR 阈值、连续帧数和库文件路径

疲劳度检测的算法框架基本固定，项目能不能用，拼的是参数。很多老源码里的默认参数是从论文照抄的，不一定适合你的摄像头、光照和被测人。我自己接手这种包，每次都先查四个东西：EAR 阈值、连续闭眼帧数、统计窗口长度、库文件路径。前三个决定检测准不准，第四个决定能不能启动。

4.1 三个必调参数：EAR 阈值、连续帧数和检测窗口

先给一张参数速查表，这是调参时的出发点，不是终点：

EAR 阈值是最关键的一项。网上很多源码直接写死 0.25，但 0.25 不一定适合你。离摄像头远一点，眼睛区域分辨率下降，EAR 噪声变大；戴眼镜的人镜片反光会让关键点抖动，睁眼时 EAR 也可能掉到 0.2 以下。正确做法是录一段正常睁眼的视频，把每一帧的 EAR 值打印出来，取最后一段平滑后的均值，再乘 0.7 到 0.8 作为闭眼阈值。我调过的现场系统里，有人睁眼 EAR 是 0.31，有人只有 0.22，用同一个阈值一定会误报。

连续闭眼帧数是很多新手忽略的参数。它的意思是：只有连续 N 帧 EAR 都低于阈值，才认为发生了一次闭眼。不加这个参数，快速眨眼的瞬间 EAR 掉一下就会记一次“闭眼”，疲劳度会被拉高。30 帧每秒的摄像头，3 帧对应 100 毫秒，正好能过滤正常眨眼；60 帧每秒就要放到 5 帧左右。如果摄像头实际帧率只有 15 帧，N 设在 2 以下才合适。

PERCLOS 统计窗口决定了疲劳判定是“快而敏感”还是“稳而迟钝”。老包里的常见值是 60 秒：在 1 分钟里闭眼占比超过比如 20%，就判定疲劳。但如果你做的是实时驾驶预警，30 秒更合适；如果做员工状态统计，120 秒也不为过。窗口调短会让单次闭眼打哈欠就触发报警，窗口太长又会让人明显疲劳了还不报警。建议先保留源码默认值，跑一天日志出来再改。

4.2 库文件路径与动态链接库加载：为什么总报“找不到”

参数再准，程序启动不了也没用。老包最常见的问题是动态链接库加载失败。Windows 下加载 dll 有一套搜索顺序：exe 所在目录、系统目录、PATH 环境变量。很多人没有把lib目录和 exe 放在一起，也没有加 PATH，程序一启动就会弹“找不到 opencv_world330.dll”。

解决方式有三种，按推荐程度排序：

第一种，把动态库直接放在 exe 同级目录，这是最简单也最不会污染系统的做法。老包解压后 exe 通常就在根目录，只要把opencv_world330.dll、opencv_core330.dll这些文件复制过去即可。

第二种，把库文件目录加进 PATH 环境变量。适合不想复制多个 dll 的场景，但要注意 PATH 里如果有多个 OpenCV 版本，可能加载到错误版本。

第三种，在 Visual Studio 工程里配置“附加库目录”，编译期链接.lib，运行期仍然需要.dll。C++ 老工程里，还容易遇到 Debug 和 Release 库混用的问题：debug 模式要链接带d后缀的库，比如opencv_core330d.lib，release 模式用不带d的版本。如果系统里同时存在两个，链接器选了错的那个，就会在运行时出现一堆诡异崩溃。

Linux 下也类似，用ldd能直接看到依赖情况：

# 查看可执行文件的动态库依赖 ldd ./fatigue_detector | grep "not found"

输出里有not found的项，说明某个库文件路径没被系统找到。这时可以用export LD_LIBRARY_PATH=/解压目录/lib:$LD_LIBRARY_PATH临时指定，确认程序能跑之后再写进 shell 配置。这里要提醒一句：不要为了省事把老版本 OpenCV 的 dll 覆盖系统目录里的同名文件，这会让其它程序遭殃，属于老工程师口中“后悔药都救不回来”的操作。

4.3 从“能出框”到“能报警”：日志、帧率与错检率

一个疲劳度检测程序能在画面上画出人脸框，跟它能稳定报警，中间还隔着“帧率”和“错检率”两个坎。老工程的库文件版本匹配后，程序能跑，但经常出现画面卡顿，判断结果忽高忽低。这往往不是算法问题，是帧率太低导致 EAR 序列失真。

建议在源码主循环里加两行日志：一行统计处理耗时，一行统计当前帧率。下面是伪代码模板：

start = cv2.getTickCount() # 处理当前帧，例如人脸检测、EAR 计算 faces = detector(gray, 0) # 处理结束后估算帧率 fps = cv2.getTickFrequency() / (cv2.getTickCount() - start) print(f"fps={fps:.1f}")

逻辑说明：getTickCount是 OpenCV 的高精度计时接口，处理后取差值再除以getTickFrequency得到秒数，最后换算成帧率。打印出的 fps 如果低于 20，疲劳判定里的“连续闭眼帧数”就需要重新换算：在 10 帧每秒下，3 帧闭眼等于 300 毫秒，这和正常眨眼接近，会导致误判。这时先把输入分辨率降到 640x480，或者每隔一帧做一次检测，优先保住帧率。人脸区域外的部分不需要全分辨率参与计算，把检测框裁切到固定 200x200 再传给关键点模型，也能明显提升速度。

日志里除了 fps，还应该输出每次“闭眼事件”的起止时间。只输出一个最终报警很难判断阈值是否合理；如果能看到“第 12.3 秒开始闭眼，持续 0.8 秒”，就可以反推连续帧数和 EAR 阈值从哪里调。这也是后面第 5 章要讲的各种翻车现场，大多数都能靠这种方式定位。

5. 疲劳度检测最常见的 5 个翻车现场与排查步骤

老工程跑起来的路上，坑比预想多。这里按“现象、原因、解决”的格式整理五个我见过最多的翻车现场，覆盖解压、库文件、模型、参数、摄像头和环境路径。

5.1 杀毒软件把库文件当病毒清掉

现象：解压后的目录里 dll 或 exe 数量明显比文件清单少，程序启动时提示“无法启动此程序，因为计算机中丢失某某.dll”，但明明刚刚解压时还在。

原因：老工程里的库文件是旧版编译器生成的，个别 dll 带有加壳或过期签名，容易被杀毒软件标记为可疑文件。2017 年的 OpenCV 库文件在那段时间误报率尤其高。

解决：解压前先给压缩包目录添加信任白名单，然后重新解压一次。缺失的单个 dll 可以从原始 rar 包单独释放，不要从网上下载裸 dll。如果杀毒软件已经隔离，从隔离区恢复后放到 exe 同级目录即可。

5.2 OpenCV/Dlib 版本和源码不匹配

现象：编译时报一堆 LNK2019 未解析外部符号，或运行时在cv::imread、dlib::deserialize处崩溃，提示版本不兼容。

原因：源码写的是 OpenCV 2.4 的IplImage、cvFindContours接口，库文件却是 OpenCV 3.x，头文件声明和库文件导出符号对不上；或者 dlib 版本从 18 跳到 19，序列化格式和 API 都变了。

解决：先看源码开头的#include行。出现opencv2/core/core_c.h且大量使用cv::Mat之外的老结构，优先找 OpenCV 2.4.x 库文件；出现cv::Mat和opencv2/opencv.hpp则用 OpenCV 3.x。dlib 19.x 之后模型文件格式也变化过，如果老人脸模型加载报错，需要重新用对版本的shape_predictor导出。不要混着替换单个 dll，要整套库文件一起切换。

5.3 EAR 阈值照抄论文导致误报频发

现象：人正常睁眼盯着屏幕，程序每十分钟就误报一次疲劳；或者人已经靠在椅子上闭眼两秒，程序却毫无反应。

原因：0.25 的 EAR 阈值来自通用数据集，摄像头高度、人脸距离、眼镜反光都会改变睁眼时的 EAR 基线。有人睁眼 EAR 均值 0.3，有人只有 0.22，用固定阈值一定翻车。

解决：录一段“睁眼—闭眼—睁眼”的标定视频，提取每一帧 EAR 数值。睁眼状态 EAR 的最小值作为上限，闭眼状态 EAR 的最大值作为下限，如果两者有间隔，取中间值作为阈值。如果关键点抖动明显，先对 EAR 做低通滤波：ear_smooth = 0.7 * ear_smooth + 0.3 * ear_current，比直接改阈值更管用。

5.4 摄像头打不开与帧率过低

现象：程序运行后窗口黑屏，cap.read()一直返回 False；或者能出画面但 fps 只有 5。

原因：OpenCV 默认从V4L2或旧 DirectShow 读取摄像头，Windows 10 之后部分摄像头默认被系统相机应用占用，后端选择不当就会打不开。720p 下还会因为 dlib 人脸检测太慢导致帧率暴跌。

解决：Windows 下显式指定后端：

cap = cv2.VideoCapture(0, cv2.CAP_DSHOW)

如果仍然打不开，先关掉系统相机测试工具，释放摄像头占用。帧率低时把输入分辨率降到 640x480，并将读到的图像直接缩小再送入检测器。老源码里如果写了detector(gray, 1)，表示对灰度图做一次上采样，检测会更准但更慢，帧率紧张时改成0。

5.5 中文路径导致库文件和模型加载失败

现象：模型文件明明存在，shape_predictor("D:\\数据\\疲劳检测\\shape_predictor_68_face_landmarks.dat")却报错；或者视频文件读不出来。

原因：老版 C/C++ 的fopen和部分 Python 版本在 Windows 中文编码下无法正确处理带中文的绝对路径。很多下载包默认带“疲劳_疲劳度检测”这种中文目录名，源程序里没做宽字符转换，自然读不到。

解决：把整个工程目录移到纯英文路径下，比如D:\fatigue_det或/home/user/fatigue_det，并把压缩包解压时夹带的空格去掉。路径里不要用中文、不要用带空格的文件夹名，这是花一分钟能少受两小时气的事。模型路径最好写成相对路径，保证别人拿到源程序后不用改配置也能跑。

6. 把老工程变成自己的疲劳检测工具：验证方法、自建阈值和一点血泪经验

老工程跑通只是第一步，真把它用到自己的场景里，一定要有自己的验证方法。我建议先做三段回归视频：一段正常睁眼盯着屏幕，一段频繁眨眼，一段模拟疲劳闭眼一到两秒。分别跑一遍源程序，记录误报次数和漏报时长。判断参数调得好不好，不看准确率这一个数字，看“误报间隔”和“漏报时长”。在疲劳预警场景里，漏报一次比误报十次都危险，因为它直接关系到人身安全。

自建阈值不要太随意。先录 30 秒正常状态视频，统计每帧 EAR 的均值和最小值；再录 30 秒闭眼状态视频，统计最大值。如果两者不重叠，取中点是合理做法；如果重叠，说明分辨率或关键点抖动太严重，优先做滤波而不是硬调阈值。下面是简化的离线标定伪代码：

# 离线标定：从正常状态视频计算 EAR 下限 ears = [] for frame in video: ear = compute_ear(frame) ears.append(ear) # 睁眼阈值取正常状态最小值的 80%，留一点余量 eye_open_threshold = min(ears) * 0.8

逻辑说明：eye_open_threshold只代表睁眼状态的下界，实际闭眼判定还需要结合连续帧数和窗口。不要把这段离线计算的阈值直接写成固定值，每个人脸型和摄像头角度都会让基线偏移。

调试这类老工程时，我还养成了一个习惯：每次改参数前先把原始配置和 EAR 曲线图存下来。这样改崩了还能回到之前的状态，不至于靠记忆调参数。如果你接的是真实预警场景，不要只盯着眼睛，最好把头部姿态、工作时长合在一起综合判断。我当年调试一套设备疲劳预警时，只依赖 EAR 导致午休趴桌被反复报警，后来改成“闭眼持续超过 2 秒且头部下垂角度大于 30 度”才算一次潜在疲劳，误报立刻降了下来。这个经验不一定适合你的场景，但方向是对的：老源码是基础算法，业务规则要自己加。

希望这些从解压到调参的路径能帮到你，至少让你拿到这类老 rar 包时，少走一段我走过的弯路。

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