简介面向深度学习初、中级开发者及计算机视觉学习者这套资源提供基于深度学习的驾驶员状态识别完整项目解决从图像输入到十种驾驶状态概率输出的多分类问题。项目内含数据集划分脚本、基准模型代码、VGG16、ResNet50、InceptionV3、Xception四种经典网络的单模型微调实现以及混合模型输入生成与最终执行代码并附有一份详细的项目报告帮助理解迁移学习、模型融合和图像分类的完整流程。压缩包共37个文件以Jupyter笔记ipynb和Python脚本py为核心辅以HTML可视化页面、Markdown说明、PDF/Word报告和演示动图整体大小约65.2MB目录结构清晰便于按步骤复现实验。目前已有118人学习读者可参考完整代码架构与赛题方案也可直接基于现有模型进行二次开发非常适合需要快速搭建驾驶员检测系统或深入掌握卷积神经网络微调技巧的研究者与工程师。1. 驾驶员状态识别除了闭眼和打哈欠这套系统到底在检测什么很多人看到“驾驶员状态识别”六个字第一反应就是“检测闭眼、打哈欠”但真正动手做过的人会知道最难的不是模型能不能认出眼睛和嘴巴而是“状态”本身怎么定义、阈值怎么定、在车载处理器那么有限的算力下怎么不掉帧。这篇文章要拆的就是一套基于 Python 和深度学习的驾驶员状态识别系统涵盖源码结构、模型训练、报告生成三个交付物并把我复现和改代码时踩过的坑一并说清楚。这套东西适合做课程设计、毕业设计的同学也适合想在企业里做疲劳驾驶预警原型但又不想从零造轮子的工程师。我默认你已经装好了 Python 和 OpenCV如果还没有先把环境配好再往下看。2. 状态识别链路与模型选型先解决“检测什么”再谈算法2.1 为什么说“闭眼检测”和“疲劳判定”是两回事我最早接触驾驶员状态识别时一头扎进“怎么用 CNN 识别闭眼”结果发现真正落地时系统里跑的不只是一个深度学习模型而是一整条链路视频帧输入、人脸检测、眼睛和嘴巴关键点定位、计算 EAR/MAR 指标、连续帧判定、报警输出、统计记录。这里最关键的一点是深度学习模型负责的是“感知”也就是找到人脸、找到眼睛嘴巴而“疲劳判定”本身是规则逻辑。一个常见的做法是使用眼睛纵横比EAR来判断闭眼。EAR 的计算基于眼睛周围 6 个关键点的距离比值闭眼时 EAR 会明显变小。这个公式在 OpenCV 和 dlib 的示例里很常见但驾驶场景下不能直接用单帧 EAR 低于阈值就报警因为正常眨眼也会瞬间闭眼。你需要把它变成“闭眼持续帧数”或“单位时间闭眼占比”才能真正反映疲劳状态。源码里这层逻辑往往藏在检测循环里我建议你先找到这段帧计数代码再改阈值。下面是一段 EAR 计算函数这类代码几乎每个开源项目里都有但很多新手直接复制不知道参数为什么要这样设import numpy as np def eye_aspect_ratio(eye_points): # eye_points: 按顺序排列的 6 个眼部关键点坐标 # 竖直方向两对距离 p2_minus_p6 np.linalg.norm(eye_points[1] - eye_points[5]) p3_minus_p5 np.linalg.norm(eye_points[2] - eye_points[4]) # 水平方向一对距离 p1_minus_p4 np.linalg.norm(eye_points[0] - eye_points[3]) ear (p2_minus_p6 p3_minus_p5) / (2.0 * p1_minus_p4) return ear这段代码的关键点是关键点顺序必须固定。如果你的模型输出的是 68 点人脸关键点左眼索引通常是 36 到 41右眼是 42 到 47顺序不对 EAR 计算出来就是乱的。EAR 的正常值大概在 0.2 到 0.35 之间闭眼时降到 0.1 以下但实际阈值要看你用的摄像头畸变程度和坐姿不能照抄网上所谓的“通用 0.2”。2.2 模型选型人脸检测用轻量模型状态分类用 CNN别迷信单一大模型驾驶员状态识别里人脸检测是最先跑的模块。你不可能把整张 1080p 图像塞进分类模型去判断闭眼那样背景干扰太多计算量也大。常见做法是先用一个人脸检测器框出人脸区域裁剪后送入后面状态分类或关键点网络。这里的人脸检测器选型很有讲究。如果跑在普通电脑上OpenCV 自带的人脸检测器速度块但漏检多在嵌入式平台上常见的选择是 YOLOv5s 这种轻量目标检测模型或者 MTCNN。我之前在树莓派 4B 上试过 YOLOv5s推理时间能控制在 150 毫秒左右勉强可以跑 5 到 7 帧但再叠加疲劳判定逻辑就吃力了。我自己更推荐“轻量人脸检测 分类网络”的组合而不是端到端疲劳识别模型。原因有两个第一疲劳状态的公开数据集很少且标注标准不统一直接训练端到端模型容易过拟合第二实际项目里疲劳判定依赖时间上下文你把闭眼和打哈欠分别用 CNN 分类再在决策层叠加时长逻辑比让一个网络去学“疲劳”要稳得多。很多开源项目里就是先用 MTCNN 检测人脸并提取眼睛嘴角区域再单独训练一个小的 CNN 分类器判断眼睛闭合和嘴巴张开。2.3 帧率、阈值和连续帧参数这三个参数决定报警准不准同样一套模型帧率不同报警的判定逻辑就必须跟着变。假如你的摄像头读取是 30 FPS但人脸检测加关键点定位实际只处理了 10 帧/秒那么代码里“连续 5 帧闭眼”实际对应的是 0.5 秒而不是你期望的 0.17 秒。所以你在调参时一定要把实际处理帧率打印出来再反推帧数阈值。下面是一个典型的判定循环伪代码用来帮助你理解帧数与时间的关系CLOSED_EYE_THRESH 0.18 # EAR 阈值低于它视为闭眼 CONSEC_FRAMES 12 # 连续闭眼帧数用于触发疲劳报警 fps 12.0 # 实际推理帧率需提前实测 def judge_fatigue(ear, frame_count): # 正常眨眼一般持续 1~2 帧疲劳闭眼会超过 10 帧 if ear CLOSED_EYE_THRESH: frame_count 1 else: frame_count 0 if frame_count CONSEC_FRAMES: close_time frame_count / fps print(f疑似疲劳闭眼: {close_time:.2f}s) frame_count 0 return frame_count这里的CONSEC_FRAMES要按你的实际推理帧率换算如果你希望 1 秒内持续闭眼报警而帧率只有 12那么阈值就是 12 帧。另外 EAR 阈值不要只设一个固定值因为不同人眼睛大小和佩戴眼镜情况差异很大更好的做法是先用一个“正常睁眼”阶段的 EAR 均值做动态校准再设一个相对偏移阈值。3. 数据集准备与 CNN 模型训练手把手跑通闭眼/张嘴分类器3.1 预处理人脸裁剪、归一化、数据增强怎么做很多开源项目里模型训练部分并不是端到端人脸检测而是针对“眼睛区域”和“嘴巴区域”训练两个分类器。训练数据一般来自公开数据集比如闭眼数据集和打哈欠数据集但你在复现时经常要自己从原图里裁人脸关键点区域生成样本。裁剪时要注意两点一是区域不能只取眼睛本身最好包含一部分眉毛或眼周皮肤让 CNN 能学到更丰富的纹理特征二是尺寸要统一常见的是 24x24 或 32x32 的小图小尺寸有利于在边缘设备上推理。预处理代码中我常用的流程是读取原图、用 dlib/OpenCV 检测人脸关关键点、周期性提取眼部 ROI 和嘴部 ROI、归一化到 0~1 或 128~127然后把图片存成 NumPy 数组以便训练。这里的一个大坑是嘴巴区域和眼睛区域的提取比例要按人脸框的宽度来动态计算不能固定像素大小因为摄像头距离人脸远近会导致人脸尺寸变化大。为了让你少走弯路我给一个最简单的训练数据生成片段import cv2 import numpy as np from imutils import face_utils def extract_mouth_roi(gray, landmarks): # 假设 landmarks 是 dlib 68 点模型的输出 mouth face_utils.shape_to_np(landmarks) # 嘴部外侧点通常从索引 48 到 59 之间 (x, y, w, h) cv2.boundingRect(mouth[48:60]) # 扩大 30% 区域避免裁剪太紧导致嘴唇边缘信息丢失 x max(0, x - int(w * 0.15)) y max(0, y - int(h * 0.15)) w min(gray.shape[1], w int(w * 0.3)) h min(gray.shape[0], h int(h * 0.3)) roi gray[y:yh, x:xw] return cv2.resize(roi, (32, 32))注意mouth[48:60]只覆盖了嘴部外轮廓如果你的模型输出的关键点是 MediaPipe 而不是 dlib索引会完全不同。这个代码的前提是你在数据集预处理阶段先有人脸关键点模型可用很多时候它就是源码自带的推理模型。3.2 用 PyTorch 训练一个轻量闭眼分类器最小可跑代码训练状态分类器时我不建议直接拿一个超大模型来跑。我常用的做法是用一个非常简单的 CNN类似 LeNet-5 的小结构输入 32x32 灰度图输出 2 类或 3 类。因为你要分类的是“眼睛闭/开”这样简单的视觉差异复杂模型反而更容易过拟合推理也慢。下面是一个用 PyTorch 训练闭眼分类器的示例为了保证你能直接跑我做了最小化处理import torch import torch.nn as nn from torch.utils.data import Dataset, DataLoader import cv2 import numpy as np class EyeClosureCNN(nn.Module): def __init__(self): super().__init__() self.features nn.Sequential( nn.Conv2d(1, 32, kernel_size3, padding1), nn.ReLU(), nn.MaxPool2d(2), nn.Conv2d(32, 64, kernel_size3, padding1), nn.ReLU(), nn.MaxPool2d(2) ) self.classifier nn.Sequential( nn.Flatten(), nn.Linear(64 * 8 * 8, 128), nn.ReLU(), nn.Dropout(0.3), nn.Linear(128, 2) ) def forward(self, x): return self.classifier(self.features(x))这里输入是 32x32 单通道图经过两层卷积和池化后特征图尺寸变成 8x8所以全连接层输入维度是64 * 8 * 8。如果你的输入尺寸改成 48x48这个维度也要重新算。很多人直接用网上的代码尺寸一改就会在forward时报维度错误解决办法是打印features(x).shape查看实际输出维度。训练循环里常用的交叉熵损失和 SGD 优化器如下model EyeClosureCNN() criterion nn.CrossEntropyLoss() optimizer torch.optim.Adam(model.parameters(), lr1e-3) dataset EyeDataset(eye_train) # 自定义 Dataset返回 (img, label) loader DataLoader(dataset, batch_size32, shuffleTrue, num_workers2) for epoch in range(20): running_loss 0.0 for imgs, labels in loader: optimizer.zero_grad() outputs model(imgs) loss criterion(outputs, labels) loss.backward() optimizer.step() running_loss loss.item() print(fepoch {epoch1}, loss: {running_loss/len(loader):.4f})这段代码里batch_size32是入门级选择如果你的显存小可以降到 16 或 8。学习率 1e-3 用 Adam 是安全的但训练后期如果 loss 震荡往往需要降到 5e-5 或改用 SGD 配合学习率衰减。我遇到最多的翻车现场是数据没做归一化像素值 0-255 直接输入模型导致 loss 一直不降。所以你的 Dataset 里一定要除以 255 或做标准化。3.3 数据集平衡与精准率/召回率指标准确率不是越高越好疲劳状态分类的数据集通常重度不平衡——睁眼正常状态的图片远多于闭眼和哈欠图片。如果你直接训练模型会学会“无脑输出正常状态”因为这样准确率可能高达 90%。但这类项目真正关心的是“疲劳状态有没有被漏掉”也就是召回率。我一般采用两种方式处理。第一种是数据增强对少数的闭眼/张嘴图片做水平翻转、小角度旋转、亮度调节把少数类扩充到和多数类接近第二种是在损失函数里给少数类加权。PyTorch 里CrossEntropyLoss支持weight参数你可以在计算标签分布后传入权重。下面是一个典型的数据增强思路import cv2 import numpy as np def augment_image(img): # 水平翻转 flipped cv2.flip(img, 1) # 随机旋转 -10 到 10 度 angle np.random.uniform(-10, 10) matrix cv2.getRotationMatrix2D((img.shape[1]//2, img.shape[0]//2), angle, 1.0) rotated cv2.warpAffine(img, matrix, (img.shape[1], img.shape[0])) # 随机调整亮度 brightness np.random.uniform(0.8, 1.2) adjusted cv2.convertScaleAbs(img, alphabrightness, beta0) return [flipped, rotated, adjusted]增强之后训练集里少数类的样本量会成倍增加但要注意增强幅度不要太大旋转超过 15 度可能会让眼睛区域看起来不自然模型学到的是角度不变性而非闭眼特征。数据集平衡之后评估指标不要再只看 accuracy我会看每个类别的 precision、recall 和 F1-score尤其是“闭眼”类的 recall。如果 recall 低于 0.9说明系统会把真实闭眼漏掉这在驾驶场景下是不可接受的。4. 实战中高频踩坑的 5 个细节现象、原因与解决4.1 现象戴眼镜的人闭眼识别率骤降你在测试时找几个戴眼镜的同学一试往往发现闭眼判不出来。原因不是模型没学会而是眼镜反光、镜框遮挡导致关键点偏移EAR 计算比正常情况高很多闭眼时依然超过阈值。解决的办法有三层一是在训练数据里加入戴眼镜样本哪怕用图像合成的方式把眼镜框叠加到人脸区域二是把 EAR 阈值调低同时改用动态基线也就是先让被测人在正常睁眼状态下录制 30 帧用这些帧的 EAR 均值作为个人阈值闭眼阈值设为均值乘以 0.6三是增加“视线方向”或“头部姿态”作为辅助特征不单靠 EAR。我实际测试中动态基线法效果提升最明显代码改动也不大。4.2 现象摄像头实测时 CPU 占用高帧率掉到个位数很多人把项目源码跑起来发现电脑风扇狂转画面卡得不行。原因往往是人脸检测模型处理了过大分辨率图像或是在主线程里做了同步推理没有跳过重复帧。解决思路有两个。一是把摄像头输入尺寸缩小到 640x480人脸检测区只在这个尺寸上跑二是在检测循环里引入“跳帧机制”比如每 3 帧才跑一次完整人脸检测和关键点中间帧直接沿用上一次结果。这个跳帧数量要根据帧率实测调整——如果你能跑到 15 FPS跳 1 帧已经够如果只有 8 FPS那就跳 3 帧并降低判定阈值对帧数的要求。不要小看跳帧它是我把卡顿项目救活最主要的操作。4.3 现象报告里时间戳和检测结果对不上系统生成了状态统计报告但你会发现报告里记录的时间戳是按处理帧数累加的而不是真实时间导致疲劳时段的定位不准。原因是很多源码里frame_count只是计数器而实际处理帧率受设备负载影响上下波动直接用帧数除以设定的 FPS 会失真。解决方法是每次进入检测循环时用time.time()记录真实时间报告里保存的是时间戳而不是帧序号。我还会把报警事件单独存成 CSV每行包含开始时间、持续秒数、闭眼或哈欠类型、平均 EAR 值这样报告梳理起来就清楚得多。4.4 现象模型加载慢、首次推理耗时特别长如果你拿大模型跑第一次推理就会明显卡顿尤其是用 CPU 跑 PyTorch 时。原因是模型初始化和权重加载需要时间有些源码还默认在 GPU 上分配显存而你的机器没有 NVIDIA GPU导致每次都触发回退。解决方法是设置明确的设备判断逻辑强制优先使用 CPU 或cuda:0可用时才用 GPU。另外可以重新保存一份不带优化器状态的模型权重只保存 state_dict这样加载会快很多。我经常看到有人用torch.save(model, ...)保存整个模型加载时就特别慢而用torch.save(model.state_dict(), ...)是更专业的做法。移动端部署时还要把模型转换成 ONNX再套用推理框架能进一步减少启动时间。4.5 现象验证集 loss 不降、训练集 loss 却很低这是典型的过拟合。前面说了疲劳状态数据集往往很小如果网络参数多、训练轮次又大模型会把训练集背下来。我在一个闭眼分类器上遇到过准确率 99%但验证集只有 82%。解决办法一是加大数据增强力度尤其对少数类做更强的随机裁剪和颜色扰动二是加入 Dropout 并提前停止训练观察验证集 loss 在哪个 epoch 开始上升取那个 epoch 前的权重三是如果条件允许用 OpenCV 合成一些人脸贴图把眼睛区域替换成闭眼效果补充合成样本。过拟合这个东西靠玄学是没用的必须从数据量和模型容量两头压制。5. 最后一步把识别结果整理成报告并验证你的系统到底行不行5.1 报告生成帧统计、事件表与图表输出一个完整的“源码 模型 报告”交付物里报告并不是简单的日志而是能说明系统有效性的一份可读文件。我一般让程序把检测结果输出成 CSV 和简单的图表CSV 用于二次分析图表用于展示闭环结果。下面是一个轻量的 CSV 写入模式你可以在自己的源码里参考import csv def write_report(event_list, output_pathfatigue_report.csv): # event_list 中的每一条是一个 (start_time, duration, event_type, confidence) 元组 with open(output_path, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([start_time, duration_s, event_type, confidence]) for event in event_list: writer.writerow(event)这个 CSV 里的start_time必须是真实时间戳duration_s是持续秒数confidence是模型输出置信度或 EAR/MAR 得分。报告页面上同步统计总疲劳次数、累计疲劳秒数、平均每次闭眼持续时间这些指标能直接说明系统有没有实际监测价值。图表部分我习惯用 Matplotlib 画一个时间轴上的状态条横轴时间、纵轴状态类别比表格直观得多。5.2 模型验证的三个指标混淆矩阵、F1-score 与鲁棒性测试报告里如果不能给出验证指标别人很难信任你的系统。我至少会交付一张混淆矩阵和一份分类报告。混淆矩阵可以直接用 sklearn 的confusion_matrix和classification_report生成并注明测试集来源。除了常规指标一定要做鲁棒性测试换不同光线、换不同人脸角度、让被测人戴帽子或闭一只眼。记录其中哪些样本被误判并把这些失败样本挑出来放进训练集这是把系统从“能跑”推到“能交付”的关键。我自己的习惯是保留一个专门的三类测试集睁眼眨眼、打哈欠、正常说话。每次调完参后跑一遍这个测试集看三类样本的召回率变化。如果打哈欠的召回率提升了但正常说话的误报多了我会回到嘴部 ROI 提取逻辑上调整阈值而不是继续加训练轮次。5.3 一个收尾的小技巧把判定阈值暴露成配置文件最后有个小建议永远不要把 EAR、MAR、连续帧数这些参数硬编码在源码里。把它们放到一个config.py或config.yaml里调用时读取配置。我之前吃过一次亏改完阈值重新训练模型代码全乱了找参数找了一个小时。配置化的好处是你能快速对比不同参数组合下的表现也能让报告里附上参数版本方便复现。这套从环境、数据、训练到报告的路子我走了不少弯路最深的体会是驾驶员状态识别系统真正的难点不在模型结构而在你对时间、阈值和异常情况的处理。试到后来你会发现能稳定跑 12 小时不出错的才是好系统。希望帮到你。本文还有配套的精品资源点击获取