简介一份面向计算机专业毕业设计与人脸识别实战学习者的完整项目基于卷积神经网络实现驾驶员疲劳状态检测与预警覆盖人脸/眼睛检测、疲劳判别和界面告警等典型环节可直接作为毕设或课程设计的基础版本。资源共19个文件压缩包约78.33MB类型以Python源码、模型权重、配置文件和运行说明为主11个py文件涵盖数据加载、模型训练、评估、人脸提取与图形界面等模块hdf5保存训练好的网络权重xml为OpenCV级联分类器exe可免环境直接启动演示。项目经过严格调试可运行已有491人学习下载。作者随包提供完整源码与配套数据集、运行说明、依赖清单和README帮助快速还原环境按模块拆解可用于算法对比、参数调优与二次开发兼顾答辩演示与后续扩展。1. 深夜跑高速的人需要这套系统吗基于卷积神经网络的驾驶员疲劳检测与预警系统在解决什么深夜两点跑高速眼睛半闭、车道偏移很多事故就是这么发生的。基于卷积神经网络的人脸识别驾驶员疲劳检测与预警系统做的就是拿摄像头对着驾驶员的脸实时判断“这人是不是困了”并在危险出现前用声音或灯光把人叫醒。它和人脸识别门禁机有本质区别门禁只关心你是谁疲劳检测要回答的是你现在的状态困不困这个状态没有固定长相只能靠眼睛闭合程度、嘴巴张开幅度、点头频率这些微弱信号去推断。这个系统最常见的落地形态是 Python 写的OpenCV 或 Dlib 负责抓人脸和关键点CNN 卷积神经网络负责把闭眼、张嘴、点头这些疲劳信号分类出来最后接一个报警模块。对于做毕业设计的学生来说它是视觉、深度学习和工程化结合的完整项目对于想切入车载安全赛道的从业者它是一个能验证算法到产品链路的最小系统。后面所有内容都围绕“怎么做出来、参数怎么调、坑在哪”展开不写空话。2. 疲劳检测的系统架构与判定逻辑为什么纯 CNN 不够还要 EAR/MAR 这些几何特征2.1 整体链路从摄像头到报警器分成几段我经手的疲劳检测项目无论论文里写得多花哨落地链路基本都是五段。第一段是视频采集笔记本摄像头或者车载 USB 摄像头分辨率 720p 就能用不需要太高。第二段是人脸检测常见选 Dlib 的 HOG 检测器或者 MTCNN、RetinaFace这一段决定后面所有步骤的稳定性。第三段是人脸关键点定位通常用 Dlib 的 68 点模型通过关键点我们能精确算出眼睛开合度和嘴巴开度。第四段是状态分类这里 CNN 正式登场把裁剪出的眼睛区域、嘴巴区域判定为闭眼/睁眼、张嘴/闭嘴。第五段是疲劳决策与预警用一个滑动窗口统计闭眼占比超过阈值就触发声音报警。为什么不让 CNN 直接看整张脸输出“疲劳/清醒”我试过效果翻车概率很高。疲劳是连续过程端到端分类需要海量标注视频而且 CNN 很容易学偏比如学到背景亮度或坐姿变化而不是眼睛状态。所以更可靠的做法是分工几何特征负责量化CNN 负责状态识别规则层负责决策。2.2 EAR、MAR、PERCLOS 三个指标的计算与含义眼睛开合度用 EAR 表示全称 Eye Aspect Ratio公式是眼睛纵向距离和横向距离的比值。Dlib 68 点模型里左眼索引是 36 到 41右眼索引是 42 到 47下面计算均按 0-based 索引。EAR 的典型值在 0.25 到 0.35 之间闭眼时会掉到 0.1 以下。def calculate_ear(eye_points): # eye_points 是 dlib shape 里的 6 个点按 0-based 索引取出 p1, p2, p3, p4, p5, p6 eye_points # 纵向距离p2-p6 和 p3-p5 vert_a dist(p2, p6) vert_b dist(p3, p5) # 横向距离p1-p4 horiz dist(p1, p4) # 加一个极小值防止除零 return (vert_a vert_b) / (2.0 * horiz 1e-6)嘴巴开合度 MAR 的逻辑类似取嘴部外圈 6 个点左嘴角、右嘴角、上唇中间、下唇中间以及内唇上下点。打哈欠时嘴巴张大且持续时间长MAR 通常超过 0.6而正常说话时的 MAR 峰值高但持续时间短后面会讲怎么利用这个差异去过滤误报。PERCLOS 是疲劳判定领域最经典的标准含义是单位时间内眼睛闭合时间所占比例。判断单帧是否闭眼就是看 EAR 是否低于阈值然后统计过去 10 秒内闭眼帧数占比超过 40% 就判定为疲劳。这三个指标结合 CNN 的逐帧状态分类已经能覆盖绝大部分驾驶场景。2.3 CNN 在这个系统里到底承担什么活CNN 卷积神经网络在这个项目里不是用来识别整张脸是谁而是做人脸表情识别的一个子任务区分闭眼与睁眼、张嘴与闭嘴。人脸识别门禁机里那个 CNN 提取的是身份特征这里 CNN 提取的是状态特征两者训练数据完全不同。一个明显的好处是纯几何阈值方案在换人之后容易失效。有的人天生眼睛细EAR 睁眼只有 0.22闭眼 0.12固定阈值 0.2 就误判有的人戴深色框眼镜关键点偶尔被遮挡。CNN 处理的是裁剪后的局部图像它能看到瞳孔、眼白、睫毛这些细节纹理对个体差异的鲁棒性比单看几何距离强很多。常见做法是把它训练成一个二分类器输入 48×48 的眼睛图像输出睁眼/闭眼概率嘴巴区域同理。实时推理时对概率做阈值判断再喂给 PERCLOS 规则层。3. 数据集从哪来公开数据集、自采标注与人脸区域批量裁剪脚本3.1 数据集都有哪些选择一张表看清三个常用来源疲劳检测数据集没有 ImageNet 那种统一大而全的选项都是分散的。我整理过可用的来源主要有三类专门驾驶数据集、闭眼表情数据集、自采数据集。数据集名称内容方向适合用途注意点NTHU-DDD驾驶模拟器下的疲劳视频疲劳状态整体判定视频分辨率不高需自己抽帧标关键点YawDD驾驶员打哈欠视频嘴部开合分类视角正对驾驶员可用性高CEW闭眼/睁眼图像对训练闭眼分类器静态图像需自行扩增Kaggle Driver Drowsiness多种场景驾驶图像快速验证模型结构类别不平衡明显用这些数据集时别直接拿过来训练最好先过一遍筛掉低质量帧。公开数据集主要用来做预训练和冷启动真正让系统适配你自己的场景还是需要自采数据。3.2 自采数据与标注录 5 分钟视频就能开干自采的流程并不复杂。找一台带摄像头的笔记本录制三类视频正常驾驶模拟状态看前方、偶尔眨眼、转头观察疲劳状态模拟频繁闭眼持续 2 到 3 秒、打哈欠、点头说话聊天状态用于防止哈欠误报。每段 3 到 5 分钟三个不同的人录数据基本够用。接下来写脚本把视频抽帧再用 Dlib 批量检测人脸和关键点裁剪出左眼、右眼、嘴巴三个区域命名保存。标签从视频段名称继承视频段叫 fatigue这一段抽出的帧标签就是 1正常段是 0。这样不需要逐帧手工标注省力很多。3.3 批量裁剪脚本与四个容易翻车的细节下面这个脚本我一般放在项目 preprocessing 目录下跑一次能把整个视频文件夹处理成训练集。import cv2 import dlib import os detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) def crop_eye_mouth(frame): gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) faces detector(gray, 0) if len(faces) 0: return None shape predictor(gray, faces[0]) points [(shape.part(i).x, shape.part(i).y) for i in range(68)] # 按 0-based 索引取左右眼和嘴巴的边界框并向外扩 20% 作为余量 left_eye points[36:42] right_eye points[42:48] mouth points[48:68] eye_w max(max(p[0] for p in left_eye) - min(p[0] for p in left_eye), 1) # 实际裁剪时以两眼中心为基准保证左右眼对称 return crop_with_margin(frame, left_eye, eye_w), crop_with_margin(frame, right_eye, eye_w), crop_with_margin(frame, mouth)逻辑说明先检测人脸再用 Dlib 取 68 个关键点按索引切片得到左右眼和嘴巴的坐标组。crop_with_margin 是我封装的一个函数作用是根据坐标组的 min/max 算出包围盒再向外扩 20% 像素后裁剪。为什么要扩如果不扩裁剪出的眼睛区域会紧贴眼睑丢失眉毛和眼周肌肉纹理CNN 能学到的判别信息就少了很多训练出来的模型在实时场景下很脆。这个脚本最容易翻车的四个点全部是血泪经验。第一Dlib 的索引是 0-based 的左右眼分别是 36 到 41、42 到 47网上很多博客写成 1-based 的 37 到 48照着抄必错。第二有人直接用左眼 bounding box 单独裁导致左右眼尺寸不一致训练时被迫 resize 拉伸眼睛比例变形准确率掉几个点。我一般直接用左右眼的组合区域裁一张图让两只眼睛保持原始相对位置。第三打哈欠时嘴巴变形大包围盒扩得太小会把舌头截掉模型学到的不是张嘴而是舌头露出来多少这个特征在新数据上完全不可用扩边至少要 30%。第四抽帧用固定间隔遇到视频中有人眨眼结束瞬间会把半闭眼状态抽进来标签冲突最好在抽帧后人工快速过一遍删掉模糊帧。4. 轻量 CNN 模型训练PyTorch 代码、迁移学习与关键超参4.1 不要从零搭大网络一个 3 层卷积的模型足够用疲劳状态分类任务相对简单输入是 48×48 的小图和 ImageNet 那种千分类任务难度差了好几个量级。自己设计复杂网络反而容易过拟合参数量大、推理慢、部署困难。我习惯用三层卷积加全连接的结构参数量在几十万级别CPU 上单帧推理不超过 10 毫秒。import torch.nn as nn class FatigueCNN(nn.Module): def __init__(self, num_classes2): super().__init__() self.features nn.Sequential( nn.Conv2d(3, 16, 3, padding1), nn.BatchNorm2d(16), nn.ReLU(inplaceTrue), nn.Conv2d(16, 16, 3, padding1), nn.BatchNorm2d(16), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), nn.Conv2d(16, 32, 3, padding1), nn.BatchNorm2d(32), nn.ReLU(inplaceTrue), nn.Conv2d(32, 32, 3, padding1), nn.BatchNorm2d(32), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), nn.Conv2d(32, 64, 3, padding1), nn.BatchNorm2d(64), nn.ReLU(inplaceTrue), nn.MaxPool2d(2) ) self.classifier nn.Sequential( nn.AdaptiveAvgPool2d(1), nn.Flatten(), nn.Dropout(0.5), nn.Linear(64, num_classes) ) def forward(self, x): return self.classifier(self.features(x))逻辑说明输入图像经过两层卷积加池化后尺寸从 48×48 降到 12×12再经过第三层卷积和池化降到 3×3最后用全局平均池化把特征压缩成一个 64 维向量。AdaptiveAvgPool2d(1) 的好处是无论输入尺寸怎么变全连接层的输入维度都固定方便后面把模型换到不同分辨率上测试。参数说明第一层卷积核数量 16第二层 32第三层 64每层都重复卷积两次让感受野更充分。BatchNorm 放在卷积后可以缓解梯度消失也能容忍稍大的学习率。Dropout 0.5 是防过拟合的关键我用过 0.3 和 0.70.5 在疲劳二分类上是最稳的。4.2 训练脚本的核心片段与超参表训练代码别看论文里写得复杂核心部分其实就那几行。用 PyTorch 写训练循环时有一个细节验证集指标一定要看 F1 而不是准确率因为疲劳数据里清醒帧往往占大多数模型全预测清醒也能有 70% 准确率但完全不报警这种模型没有意义。for epoch in range(epochs): model.train() for images, labels in train_loader: images, labels images.to(device), labels.to(device) optimizer.zero_grad() outputs model(images) loss nn.functional.cross_entropy(outputs, labels) loss.backward() optimizer.step() # 验证阶段记录 F1、召回率、混淆矩阵 # 保存最优模型而非最后一轮的早停 patience 设为 5 torch.save(model.state_dict(), fatigue_cnn_best.pt)关键超参我列一张表照着这套参数跑30 个 epoch 内能看到收敛参数取值说明输入尺寸48×48×3太小丢纹理太大费算力batch size32显存不够就降到 16学习率1e-3Adam 优化器推荐初始值学习率衰减每 10 轮 × 0.1后期收敛更稳Dropout0.5全连接前防过拟合早停 patience5验证集 F1 连续 5 轮不升就停数据增强翻转、亮度、噪声模拟夜间和光线变化场景4.3 迁移学习的正确姿势用 MobileNetV3 微调从零训练几十万参数的模型虽然可行但效果上限有限。如果自采的数据集只有几千张图我一般从预训练 MobileNetV3 开始微调最后一层甚至最后两层。ImageNet 预训练模型对纹理敏感而眼睛区域的瞳孔、睫毛、眼白纹理恰恰是区分闭眼和睁眼的关键。import torchvision.models as models model models.mobilenet_v3_small(weightsmodels.MobileNet_V3_Small_Weights.IMAGENET1K_V1) model.classifier[3] nn.Linear(model.classifier[3].in_features, 2)逻辑说明torchvision 0.15 以上版本推荐用 weights 参数指定预训练权重替代旧版的 pretrainedTrue。MobileNetV3 的 classifier 是一个 Sequential 结构最后一项是输出层替换成 2 类输出即可。迁移学习有个细节微调时不要一开始就用大学习率更新全部参数我惯用的做法是冻结特征提取层只训练分类头 10 轮再解冻全部层用 1e-4 的学习率训练 10 轮这样既保留通用特征又避免前期震荡。4.4 训练时最隐蔽的一个坑模型训练完准确率 98%放到实时视频里却发现闭眼检测慢半拍甚至漏报这种翻车我遇到过不止一次。根子往往出在训练数据预处理和实时推理预处理不一致。训练脚本对裁剪图做了 OpenCV 的 BGR 转 RGB、归一化到 0 到 1实时推理时如果忘了做同样处理模型看到的分布完全不同。另一个隐蔽问题是 Dlib 检测框在视频里会有轻微抖动同一只眼睛这一帧框大一点下一帧框小一点裁剪区域内容变化大。所以训练阶段就要对 ROI 做适量缩放和偏移增强模型才能扛住真实场景的框抖动。5. 实时预警链路与 5 个必踩的坑帧率、阈值到误报排查5.1 实时推理流水线抽帧、检测、分类、滑动窗口把训练好的模型部署到实时视频流核心是控制每一帧的处理耗时。车载或笔记本环境计算资源有限每一帧都跑人脸检测加关键点加 CNN 分类CPU 直接拉满。我惯用的方案是每 3 帧做一次完整推理中间 2 帧以上一帧的结果近似代替。这个频率在 30 FPS 的视频下等效 10 FPS 的检测率对疲劳这种分钟级变化的状态完全足够。滑动窗口用 deque 实现长度 60正好对应 10 秒的判定窗口。每个状态闭眼或张嘴进入队列统计闭眼帧占比超过 40% 就触发疲劳预警。这里还需要一个去抖机制连续 3 次触发才真正报警防止瞬时低头看手机误报。实测下来误报率能降低一半以上。state_queue deque(maxlen60) def update_state(is_eye_closed): state_queue.append(is_eye_closed) if sum(state_queue) / len(state_queue) 0.4: return True return False5.2 阈值参数表不是抄来的是标出来的网上很多文章直接写 EAR 阈值 0.2、MAR 阈值 0.5照抄的人十个有八个报警不触发。原因很简单EAR 受脸型、眼型、摄像头高度影响极大。正确做法是先录一段自己正常驾驶的视频计算睁眼 EAR 的均值和标准差取均值减去 3 倍标准差作为闭眼阈值。这个阈值是个人化的换人必须重新标定。参数建议初值调节方向EAR 闭眼阈值均值减 3 倍标准差误报多就调低漏报多就调高MAR 张嘴阈值0.5说话误报多就调高闭眼连续帧数10 帧夜间容易漏报就调低PERCLOS 窗口10 秒高速场景可缩短到 8 秒疲劳报警占比40%灵敏度不够就降到 35%5.3 避坑一夜间红外噪点导致检测框狂抖现象是白天运行正常晚上开着车灯或进入隧道后报警开始乱触发。原因是夜间噪点让 Dlib 人脸检测框每帧都在微调关键点随之抖动裁剪出来的眼睛区域忽大忽小CNN 分类输出在临界值附近震荡。解决分两步。第一步做图像预处理用 CLAHE 对亮度图做自适应直方图均衡抑制阴影和噪点第二步对关键点坐标做时间平滑保存最近 5 帧的坐标取中值而不是均值。均值会被极端值带偏中值更稳。这两步做完夜间误报基本能压住。5.4 避坑二戴眼镜的人闭眼被判定成睁眼这是疲劳检测的经典黑匣子问题。镜片反光会在眼睛位置形成高光区块CNN 看到高光纹理就以为是眼白输出睁眼概率偏高。训练集里没有眼镜样本的话戴眼镜的用户闭眼时系统完全没有反应。解决方向有两个都建议做。第一数据增强里加入高斯亮斑模拟随机在眼睛区域叠加圆形光斑让模型学会忽略反射光。第二自采数据专门录一段戴眼镜闭眼的视频放入训练集给模型一个明确的“眼镜照常闭眼”示例。做完再测闭眼召回率明显提升。5.5 避坑三训练准确率 98%实时却不报警我早期翻过这个车。训练集用离线视频裁剪裁剪框来自手动标注的关键点准确稳定实时推理时我用 OpenCV 的 Haar 人脸检测器做人脸框再按比例切出眼睛区域两种方式产生的图像内容特征不同模型等于是被换了输入分布。解决方法是让训练和推理共用一套裁剪函数。我把关键点裁剪封装成独立模块训练前处理直接调用它生成数据集实时推理也调用它保证喂给 CNN 的图像来源一致。这个坑解决后离线指标和实时表现终于对上了。5.6 避坑四说话被当成打哈欠张嘴检测最头疼的误报来源就是说话。说话时嘴也会张大MAR 偶尔超过 0.5如果只看单帧状态聊几句话就能触发一次哈欠报警。解决要加两个条件。第一持续时间约束哈欠的“张大口”状态至少持续 1.5 秒说话时的张合通常是 0.2 到 0.5 秒一次用状态队列统计连续张嘴时长即可区分。第二嘴型约束哈欠是上下张开说话时嘴唇有多种形状可以在训练时给 CNN 增加一个“说话”类别强制模型学习哈欠和说话在嘴型上的差异。5.7 避坑五笔记本风扇狂转CPU 占满把训练好的模型直接跑实时推理帧率 2 到 3 帧CPU 100%这种情况说明模型太肥了。常见原因是对一个二分类任务用了 ResNet 甚至 ResNet50完全没必要。解决方法是换轻量骨干网络并用半精度推理。MobileNetV3 或刚才的三层卷积模型是合适的。再进一步拿到 ONNX 后用 OpenVINO 推理CPU 上能再提速 50% 以上。推理精度用 FP16 就够了疲劳检测本身对数值精度不敏感实测准确率几乎无损耗。6. 验证模型有没有用标定、误报日志与轻量化部署的进阶技巧模型训练完不能说“准确率 98% 所以项目完成了”要验证的是事件级别指标每 100 分钟驾驶误报几次真实疲劳事件漏报几次。我习惯录一段 10 分钟自拍视频标记出闭眼和打哈欠的起止时间跑完整套系统后对比输出计算事件召回率和每小时误报数。这两个指标比帧级准确率更能说明系统是否可用。部署方面我最近常用的流程是 PyTorch 转 ONNX 再转 OpenVINO。torch.onnx.export 导出时固定输入尺寸为 48×48opset 设为 11 以上导出后用 onnxruntime 验证输出一致性最后用 OpenVINO 的 Model Optimizer 转换。这一步做完原来的 PyTorch 模型在 CPU 上的推理时间直接下降一截笔记本跑实时检测不再掉帧。torch.onnx.export( model, dummy_input, fatigue_cnn.onnx, input_names[input], output_names[output], opset_version11, dynamic_axes{input: {0: batch}} )另一个我坚持做的细节是预警日志。每次触发报警时把前后 5 帧图像连同一个时间戳存到日志目录事后回看这些图能快速判断是真实疲劳还是误报用误报样本补充训练集形成正循环。很多项目做完就扔在一边问题是不积累数据模型永远原地踏步。最后说一个教训阈值这种东西永远不要拍脑袋定一个数就上线。我自己刚开始做一个疲劳项目时嫌标定麻烦直接抄了网上的 EAR 0.2结果换了三个人测一个人疯狂误报一个人漏报一大半。后来老老实实让每个人做一遍睁眼闭眼标定把阈值范围算出来再取中间值误报漏报才平衡下来。疲劳检测是强个体差异问题给用户留一个简单的标定入口比任何花哨的网络结构都管用。希望这些思路能帮你把这个系统从“能跑”推到“能用”的状态。本文还有配套的精品资源点击获取
简介一份面向计算机专业毕业设计与人脸识别实战学习者的完整项目基于卷积神经网络实现驾驶员疲劳状态检测与预警覆盖人脸/眼睛检测、疲劳判别和界面告警等典型环节可直接作为毕设或课程设计的基础版本。资源共19个文件压缩包约78.33MB类型以Python源码、模型权重、配置文件和运行说明为主11个py文件涵盖数据加载、模型训练、评估、人脸提取与图形界面等模块hdf5保存训练好的网络权重xml为OpenCV级联分类器exe可免环境直接启动演示。项目经过严格调试可运行已有491人学习下载。作者随包提供完整源码与配套数据集、运行说明、依赖清单和README帮助快速还原环境按模块拆解可用于算法对比、参数调优与二次开发兼顾答辩演示与后续扩展。1. 深夜跑高速的人需要这套系统吗基于卷积神经网络的驾驶员疲劳检测与预警系统在解决什么深夜两点跑高速眼睛半闭、车道偏移很多事故就是这么发生的。基于卷积神经网络的人脸识别驾驶员疲劳检测与预警系统做的就是拿摄像头对着驾驶员的脸实时判断“这人是不是困了”并在危险出现前用声音或灯光把人叫醒。它和人脸识别门禁机有本质区别门禁只关心你是谁疲劳检测要回答的是你现在的状态困不困这个状态没有固定长相只能靠眼睛闭合程度、嘴巴张开幅度、点头频率这些微弱信号去推断。这个系统最常见的落地形态是 Python 写的OpenCV 或 Dlib 负责抓人脸和关键点CNN 卷积神经网络负责把闭眼、张嘴、点头这些疲劳信号分类出来最后接一个报警模块。对于做毕业设计的学生来说它是视觉、深度学习和工程化结合的完整项目对于想切入车载安全赛道的从业者它是一个能验证算法到产品链路的最小系统。后面所有内容都围绕“怎么做出来、参数怎么调、坑在哪”展开不写空话。2. 疲劳检测的系统架构与判定逻辑为什么纯 CNN 不够还要 EAR/MAR 这些几何特征2.1 整体链路从摄像头到报警器分成几段我经手的疲劳检测项目无论论文里写得多花哨落地链路基本都是五段。第一段是视频采集笔记本摄像头或者车载 USB 摄像头分辨率 720p 就能用不需要太高。第二段是人脸检测常见选 Dlib 的 HOG 检测器或者 MTCNN、RetinaFace这一段决定后面所有步骤的稳定性。第三段是人脸关键点定位通常用 Dlib 的 68 点模型通过关键点我们能精确算出眼睛开合度和嘴巴开度。第四段是状态分类这里 CNN 正式登场把裁剪出的眼睛区域、嘴巴区域判定为闭眼/睁眼、张嘴/闭嘴。第五段是疲劳决策与预警用一个滑动窗口统计闭眼占比超过阈值就触发声音报警。为什么不让 CNN 直接看整张脸输出“疲劳/清醒”我试过效果翻车概率很高。疲劳是连续过程端到端分类需要海量标注视频而且 CNN 很容易学偏比如学到背景亮度或坐姿变化而不是眼睛状态。所以更可靠的做法是分工几何特征负责量化CNN 负责状态识别规则层负责决策。2.2 EAR、MAR、PERCLOS 三个指标的计算与含义眼睛开合度用 EAR 表示全称 Eye Aspect Ratio公式是眼睛纵向距离和横向距离的比值。Dlib 68 点模型里左眼索引是 36 到 41右眼索引是 42 到 47下面计算均按 0-based 索引。EAR 的典型值在 0.25 到 0.35 之间闭眼时会掉到 0.1 以下。def calculate_ear(eye_points): # eye_points 是 dlib shape 里的 6 个点按 0-based 索引取出 p1, p2, p3, p4, p5, p6 eye_points # 纵向距离p2-p6 和 p3-p5 vert_a dist(p2, p6) vert_b dist(p3, p5) # 横向距离p1-p4 horiz dist(p1, p4) # 加一个极小值防止除零 return (vert_a vert_b) / (2.0 * horiz 1e-6)嘴巴开合度 MAR 的逻辑类似取嘴部外圈 6 个点左嘴角、右嘴角、上唇中间、下唇中间以及内唇上下点。打哈欠时嘴巴张大且持续时间长MAR 通常超过 0.6而正常说话时的 MAR 峰值高但持续时间短后面会讲怎么利用这个差异去过滤误报。PERCLOS 是疲劳判定领域最经典的标准含义是单位时间内眼睛闭合时间所占比例。判断单帧是否闭眼就是看 EAR 是否低于阈值然后统计过去 10 秒内闭眼帧数占比超过 40% 就判定为疲劳。这三个指标结合 CNN 的逐帧状态分类已经能覆盖绝大部分驾驶场景。2.3 CNN 在这个系统里到底承担什么活CNN 卷积神经网络在这个项目里不是用来识别整张脸是谁而是做人脸表情识别的一个子任务区分闭眼与睁眼、张嘴与闭嘴。人脸识别门禁机里那个 CNN 提取的是身份特征这里 CNN 提取的是状态特征两者训练数据完全不同。一个明显的好处是纯几何阈值方案在换人之后容易失效。有的人天生眼睛细EAR 睁眼只有 0.22闭眼 0.12固定阈值 0.2 就误判有的人戴深色框眼镜关键点偶尔被遮挡。CNN 处理的是裁剪后的局部图像它能看到瞳孔、眼白、睫毛这些细节纹理对个体差异的鲁棒性比单看几何距离强很多。常见做法是把它训练成一个二分类器输入 48×48 的眼睛图像输出睁眼/闭眼概率嘴巴区域同理。实时推理时对概率做阈值判断再喂给 PERCLOS 规则层。3. 数据集从哪来公开数据集、自采标注与人脸区域批量裁剪脚本3.1 数据集都有哪些选择一张表看清三个常用来源疲劳检测数据集没有 ImageNet 那种统一大而全的选项都是分散的。我整理过可用的来源主要有三类专门驾驶数据集、闭眼表情数据集、自采数据集。数据集名称内容方向适合用途注意点NTHU-DDD驾驶模拟器下的疲劳视频疲劳状态整体判定视频分辨率不高需自己抽帧标关键点YawDD驾驶员打哈欠视频嘴部开合分类视角正对驾驶员可用性高CEW闭眼/睁眼图像对训练闭眼分类器静态图像需自行扩增Kaggle Driver Drowsiness多种场景驾驶图像快速验证模型结构类别不平衡明显用这些数据集时别直接拿过来训练最好先过一遍筛掉低质量帧。公开数据集主要用来做预训练和冷启动真正让系统适配你自己的场景还是需要自采数据。3.2 自采数据与标注录 5 分钟视频就能开干自采的流程并不复杂。找一台带摄像头的笔记本录制三类视频正常驾驶模拟状态看前方、偶尔眨眼、转头观察疲劳状态模拟频繁闭眼持续 2 到 3 秒、打哈欠、点头说话聊天状态用于防止哈欠误报。每段 3 到 5 分钟三个不同的人录数据基本够用。接下来写脚本把视频抽帧再用 Dlib 批量检测人脸和关键点裁剪出左眼、右眼、嘴巴三个区域命名保存。标签从视频段名称继承视频段叫 fatigue这一段抽出的帧标签就是 1正常段是 0。这样不需要逐帧手工标注省力很多。3.3 批量裁剪脚本与四个容易翻车的细节下面这个脚本我一般放在项目 preprocessing 目录下跑一次能把整个视频文件夹处理成训练集。import cv2 import dlib import os detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) def crop_eye_mouth(frame): gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) faces detector(gray, 0) if len(faces) 0: return None shape predictor(gray, faces[0]) points [(shape.part(i).x, shape.part(i).y) for i in range(68)] # 按 0-based 索引取左右眼和嘴巴的边界框并向外扩 20% 作为余量 left_eye points[36:42] right_eye points[42:48] mouth points[48:68] eye_w max(max(p[0] for p in left_eye) - min(p[0] for p in left_eye), 1) # 实际裁剪时以两眼中心为基准保证左右眼对称 return crop_with_margin(frame, left_eye, eye_w), crop_with_margin(frame, right_eye, eye_w), crop_with_margin(frame, mouth)逻辑说明先检测人脸再用 Dlib 取 68 个关键点按索引切片得到左右眼和嘴巴的坐标组。crop_with_margin 是我封装的一个函数作用是根据坐标组的 min/max 算出包围盒再向外扩 20% 像素后裁剪。为什么要扩如果不扩裁剪出的眼睛区域会紧贴眼睑丢失眉毛和眼周肌肉纹理CNN 能学到的判别信息就少了很多训练出来的模型在实时场景下很脆。这个脚本最容易翻车的四个点全部是血泪经验。第一Dlib 的索引是 0-based 的左右眼分别是 36 到 41、42 到 47网上很多博客写成 1-based 的 37 到 48照着抄必错。第二有人直接用左眼 bounding box 单独裁导致左右眼尺寸不一致训练时被迫 resize 拉伸眼睛比例变形准确率掉几个点。我一般直接用左右眼的组合区域裁一张图让两只眼睛保持原始相对位置。第三打哈欠时嘴巴变形大包围盒扩得太小会把舌头截掉模型学到的不是张嘴而是舌头露出来多少这个特征在新数据上完全不可用扩边至少要 30%。第四抽帧用固定间隔遇到视频中有人眨眼结束瞬间会把半闭眼状态抽进来标签冲突最好在抽帧后人工快速过一遍删掉模糊帧。4. 轻量 CNN 模型训练PyTorch 代码、迁移学习与关键超参4.1 不要从零搭大网络一个 3 层卷积的模型足够用疲劳状态分类任务相对简单输入是 48×48 的小图和 ImageNet 那种千分类任务难度差了好几个量级。自己设计复杂网络反而容易过拟合参数量大、推理慢、部署困难。我习惯用三层卷积加全连接的结构参数量在几十万级别CPU 上单帧推理不超过 10 毫秒。import torch.nn as nn class FatigueCNN(nn.Module): def __init__(self, num_classes2): super().__init__() self.features nn.Sequential( nn.Conv2d(3, 16, 3, padding1), nn.BatchNorm2d(16), nn.ReLU(inplaceTrue), nn.Conv2d(16, 16, 3, padding1), nn.BatchNorm2d(16), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), nn.Conv2d(16, 32, 3, padding1), nn.BatchNorm2d(32), nn.ReLU(inplaceTrue), nn.Conv2d(32, 32, 3, padding1), nn.BatchNorm2d(32), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), nn.Conv2d(32, 64, 3, padding1), nn.BatchNorm2d(64), nn.ReLU(inplaceTrue), nn.MaxPool2d(2) ) self.classifier nn.Sequential( nn.AdaptiveAvgPool2d(1), nn.Flatten(), nn.Dropout(0.5), nn.Linear(64, num_classes) ) def forward(self, x): return self.classifier(self.features(x))逻辑说明输入图像经过两层卷积加池化后尺寸从 48×48 降到 12×12再经过第三层卷积和池化降到 3×3最后用全局平均池化把特征压缩成一个 64 维向量。AdaptiveAvgPool2d(1) 的好处是无论输入尺寸怎么变全连接层的输入维度都固定方便后面把模型换到不同分辨率上测试。参数说明第一层卷积核数量 16第二层 32第三层 64每层都重复卷积两次让感受野更充分。BatchNorm 放在卷积后可以缓解梯度消失也能容忍稍大的学习率。Dropout 0.5 是防过拟合的关键我用过 0.3 和 0.70.5 在疲劳二分类上是最稳的。4.2 训练脚本的核心片段与超参表训练代码别看论文里写得复杂核心部分其实就那几行。用 PyTorch 写训练循环时有一个细节验证集指标一定要看 F1 而不是准确率因为疲劳数据里清醒帧往往占大多数模型全预测清醒也能有 70% 准确率但完全不报警这种模型没有意义。for epoch in range(epochs): model.train() for images, labels in train_loader: images, labels images.to(device), labels.to(device) optimizer.zero_grad() outputs model(images) loss nn.functional.cross_entropy(outputs, labels) loss.backward() optimizer.step() # 验证阶段记录 F1、召回率、混淆矩阵 # 保存最优模型而非最后一轮的早停 patience 设为 5 torch.save(model.state_dict(), fatigue_cnn_best.pt)关键超参我列一张表照着这套参数跑30 个 epoch 内能看到收敛参数取值说明输入尺寸48×48×3太小丢纹理太大费算力batch size32显存不够就降到 16学习率1e-3Adam 优化器推荐初始值学习率衰减每 10 轮 × 0.1后期收敛更稳Dropout0.5全连接前防过拟合早停 patience5验证集 F1 连续 5 轮不升就停数据增强翻转、亮度、噪声模拟夜间和光线变化场景4.3 迁移学习的正确姿势用 MobileNetV3 微调从零训练几十万参数的模型虽然可行但效果上限有限。如果自采的数据集只有几千张图我一般从预训练 MobileNetV3 开始微调最后一层甚至最后两层。ImageNet 预训练模型对纹理敏感而眼睛区域的瞳孔、睫毛、眼白纹理恰恰是区分闭眼和睁眼的关键。import torchvision.models as models model models.mobilenet_v3_small(weightsmodels.MobileNet_V3_Small_Weights.IMAGENET1K_V1) model.classifier[3] nn.Linear(model.classifier[3].in_features, 2)逻辑说明torchvision 0.15 以上版本推荐用 weights 参数指定预训练权重替代旧版的 pretrainedTrue。MobileNetV3 的 classifier 是一个 Sequential 结构最后一项是输出层替换成 2 类输出即可。迁移学习有个细节微调时不要一开始就用大学习率更新全部参数我惯用的做法是冻结特征提取层只训练分类头 10 轮再解冻全部层用 1e-4 的学习率训练 10 轮这样既保留通用特征又避免前期震荡。4.4 训练时最隐蔽的一个坑模型训练完准确率 98%放到实时视频里却发现闭眼检测慢半拍甚至漏报这种翻车我遇到过不止一次。根子往往出在训练数据预处理和实时推理预处理不一致。训练脚本对裁剪图做了 OpenCV 的 BGR 转 RGB、归一化到 0 到 1实时推理时如果忘了做同样处理模型看到的分布完全不同。另一个隐蔽问题是 Dlib 检测框在视频里会有轻微抖动同一只眼睛这一帧框大一点下一帧框小一点裁剪区域内容变化大。所以训练阶段就要对 ROI 做适量缩放和偏移增强模型才能扛住真实场景的框抖动。5. 实时预警链路与 5 个必踩的坑帧率、阈值到误报排查5.1 实时推理流水线抽帧、检测、分类、滑动窗口把训练好的模型部署到实时视频流核心是控制每一帧的处理耗时。车载或笔记本环境计算资源有限每一帧都跑人脸检测加关键点加 CNN 分类CPU 直接拉满。我惯用的方案是每 3 帧做一次完整推理中间 2 帧以上一帧的结果近似代替。这个频率在 30 FPS 的视频下等效 10 FPS 的检测率对疲劳这种分钟级变化的状态完全足够。滑动窗口用 deque 实现长度 60正好对应 10 秒的判定窗口。每个状态闭眼或张嘴进入队列统计闭眼帧占比超过 40% 就触发疲劳预警。这里还需要一个去抖机制连续 3 次触发才真正报警防止瞬时低头看手机误报。实测下来误报率能降低一半以上。state_queue deque(maxlen60) def update_state(is_eye_closed): state_queue.append(is_eye_closed) if sum(state_queue) / len(state_queue) 0.4: return True return False5.2 阈值参数表不是抄来的是标出来的网上很多文章直接写 EAR 阈值 0.2、MAR 阈值 0.5照抄的人十个有八个报警不触发。原因很简单EAR 受脸型、眼型、摄像头高度影响极大。正确做法是先录一段自己正常驾驶的视频计算睁眼 EAR 的均值和标准差取均值减去 3 倍标准差作为闭眼阈值。这个阈值是个人化的换人必须重新标定。参数建议初值调节方向EAR 闭眼阈值均值减 3 倍标准差误报多就调低漏报多就调高MAR 张嘴阈值0.5说话误报多就调高闭眼连续帧数10 帧夜间容易漏报就调低PERCLOS 窗口10 秒高速场景可缩短到 8 秒疲劳报警占比40%灵敏度不够就降到 35%5.3 避坑一夜间红外噪点导致检测框狂抖现象是白天运行正常晚上开着车灯或进入隧道后报警开始乱触发。原因是夜间噪点让 Dlib 人脸检测框每帧都在微调关键点随之抖动裁剪出来的眼睛区域忽大忽小CNN 分类输出在临界值附近震荡。解决分两步。第一步做图像预处理用 CLAHE 对亮度图做自适应直方图均衡抑制阴影和噪点第二步对关键点坐标做时间平滑保存最近 5 帧的坐标取中值而不是均值。均值会被极端值带偏中值更稳。这两步做完夜间误报基本能压住。5.4 避坑二戴眼镜的人闭眼被判定成睁眼这是疲劳检测的经典黑匣子问题。镜片反光会在眼睛位置形成高光区块CNN 看到高光纹理就以为是眼白输出睁眼概率偏高。训练集里没有眼镜样本的话戴眼镜的用户闭眼时系统完全没有反应。解决方向有两个都建议做。第一数据增强里加入高斯亮斑模拟随机在眼睛区域叠加圆形光斑让模型学会忽略反射光。第二自采数据专门录一段戴眼镜闭眼的视频放入训练集给模型一个明确的“眼镜照常闭眼”示例。做完再测闭眼召回率明显提升。5.5 避坑三训练准确率 98%实时却不报警我早期翻过这个车。训练集用离线视频裁剪裁剪框来自手动标注的关键点准确稳定实时推理时我用 OpenCV 的 Haar 人脸检测器做人脸框再按比例切出眼睛区域两种方式产生的图像内容特征不同模型等于是被换了输入分布。解决方法是让训练和推理共用一套裁剪函数。我把关键点裁剪封装成独立模块训练前处理直接调用它生成数据集实时推理也调用它保证喂给 CNN 的图像来源一致。这个坑解决后离线指标和实时表现终于对上了。5.6 避坑四说话被当成打哈欠张嘴检测最头疼的误报来源就是说话。说话时嘴也会张大MAR 偶尔超过 0.5如果只看单帧状态聊几句话就能触发一次哈欠报警。解决要加两个条件。第一持续时间约束哈欠的“张大口”状态至少持续 1.5 秒说话时的张合通常是 0.2 到 0.5 秒一次用状态队列统计连续张嘴时长即可区分。第二嘴型约束哈欠是上下张开说话时嘴唇有多种形状可以在训练时给 CNN 增加一个“说话”类别强制模型学习哈欠和说话在嘴型上的差异。5.7 避坑五笔记本风扇狂转CPU 占满把训练好的模型直接跑实时推理帧率 2 到 3 帧CPU 100%这种情况说明模型太肥了。常见原因是对一个二分类任务用了 ResNet 甚至 ResNet50完全没必要。解决方法是换轻量骨干网络并用半精度推理。MobileNetV3 或刚才的三层卷积模型是合适的。再进一步拿到 ONNX 后用 OpenVINO 推理CPU 上能再提速 50% 以上。推理精度用 FP16 就够了疲劳检测本身对数值精度不敏感实测准确率几乎无损耗。6. 验证模型有没有用标定、误报日志与轻量化部署的进阶技巧模型训练完不能说“准确率 98% 所以项目完成了”要验证的是事件级别指标每 100 分钟驾驶误报几次真实疲劳事件漏报几次。我习惯录一段 10 分钟自拍视频标记出闭眼和打哈欠的起止时间跑完整套系统后对比输出计算事件召回率和每小时误报数。这两个指标比帧级准确率更能说明系统是否可用。部署方面我最近常用的流程是 PyTorch 转 ONNX 再转 OpenVINO。torch.onnx.export 导出时固定输入尺寸为 48×48opset 设为 11 以上导出后用 onnxruntime 验证输出一致性最后用 OpenVINO 的 Model Optimizer 转换。这一步做完原来的 PyTorch 模型在 CPU 上的推理时间直接下降一截笔记本跑实时检测不再掉帧。torch.onnx.export( model, dummy_input, fatigue_cnn.onnx, input_names[input], output_names[output], opset_version11, dynamic_axes{input: {0: batch}} )另一个我坚持做的细节是预警日志。每次触发报警时把前后 5 帧图像连同一个时间戳存到日志目录事后回看这些图能快速判断是真实疲劳还是误报用误报样本补充训练集形成正循环。很多项目做完就扔在一边问题是不积累数据模型永远原地踏步。最后说一个教训阈值这种东西永远不要拍脑袋定一个数就上线。我自己刚开始做一个疲劳项目时嫌标定麻烦直接抄了网上的 EAR 0.2结果换了三个人测一个人疯狂误报一个人漏报一大半。后来老老实实让每个人做一遍睁眼闭眼标定把阈值范围算出来再取中间值误报漏报才平衡下来。疲劳检测是强个体差异问题给用户留一个简单的标定入口比任何花哨的网络结构都管用。希望这些思路能帮你把这个系统从“能跑”推到“能用”的状态。本文还有配套的精品资源点击获取
