简介这是一份面向深度学习初学者与计算机视觉开发者的驾驶员状态识别项目基于Python与Keras构建输入彩色图片即可输出十种驾驶状态的概率适合课程设计、毕业设计或智能驾驶相关竞赛参考。压缩包共37个文件大小约65.2MB其中代码以Jupyter Notebook和Python脚本为主另有运行结果网页、说明文档及PDF/Word报告代码与报告相互对应便于对照学习。项目完整覆盖数据集划分、基准模型搭建、四种经典网络VGG16、ResNet50、InceptionV3、Xception的单模型微调、混合模型特征融合与最终模型执行还提供了数据拆分脚本和瓶颈特征生成工具帮助理解混合模型输入的构造方式从简单到复杂逐步展开迁移学习实践路径可直接复现并扩展。目前已有118人学习下载适合希望系统掌握图像分类、模型微调与集成方法的开发者。1. 驾驶员状态识别系统从一张脸判断疲劳与分心Python 深度学习怎么做疲劳驾驶是交通事故的主要诱因而驾驶员状态识别正是把深度学习落到车载视觉里的典型任务。这个项目围绕Python 驾驶员状态识别系统交付源码、预训练模型和技术报告输入是摄像头帧输出是正常、疲劳、分心这类状态覆盖从数据准备到模型部署的完整链路。它特别适合三类人做毕业设计需要完整作品的学生做边缘盒子的嵌入式工程师以及想在实车上验证视觉检测方案的算法岗。这里没有黑匣子下面把关键选型、训练参数、落地坑位和报告写法逐层拆开。2. 系统架构与核心选型摄像头帧到驾驶状态的完整链路2.1 为什么选视觉方案而不是方向盘信号驾驶员状态识别在工程上有两条常见路线一条读取方向盘转角、车道偏移、行车速度等车辆信号用规则或简单统计模型判断异常另一条用摄像头采集驾驶员面部图像用深度学习直接推断疲劳、分心、打电话等行为。车辆信号方案胜在稳定不受光照影响但它只能间接反映人可能疲劳了比如车道偏移增大却无法区分闭眼和低头看手机。视觉方案则直接观测人本身能给出闭眼时长、打哈欠频率、视线方向等可解释的中间量这也是当前主流和论文里最常见的做法。在实际车载场景里视觉方案要面对抖动、逆光、眼镜反光和夜间红外补光。所以完整的系统不是单模型而是人脸检测、关键点定位、状态分类、时序平滑、报警决策五级流水线。前两级负责把脸和五官框出来第三级负责对眼睛和嘴巴做状态分类第四级把单帧结果变成一段时间的统计量第五级决定什么时候触发报警。标题里说的模型通常指第三级中的分类网络但工程交付时一定要把前后处理一起给出否则别人拿到手根本跑不起来。2.2 推理链路的Python最小实现OpenCV PyTorch先给一个能单帧跑通的最简推理链路。为了照顾 CPU 环境人脸检测用 OpenCV 的 Haar 级联眼部分类用一个小型 CNN。注意这只是一个脚手架实际要接 MediaPipe 或 RetinaFace 以提升鲁棒性。# 单帧推理人脸检测 眼部ROI提取 状态分类 import cv2 import torch import numpy as np from models.eye_state import EyeStateCNN net EyeStateCNN(num_classes3) # 0睁眼, 1闭眼, 2半睁 net.load_state_dict(torch.load(checkpoints/eye_state.pth, map_locationcpu)) net.eval() face_cascade cv2.CascadeClassifier( models/haarcascade_frontalface_default.xml ) def infer_frame(frame): gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) faces face_cascade.detectMultiScale(gray, 1.1, 5, minSize(80, 80)) if len(faces) 0: return no_face # 取最大人脸保证离摄像头最近的人优先 x, y, w, h max(faces, keylambda f: f[2] * f[3]) face gray[y:y h, x:x w] # 眼部ROI先粗略取人脸上半部后续用关键点精修 eye_roi face[:int(h * 0.4), int(w * 0.1):int(w * 0.9)] eye_roi cv2.resize(eye_roi, (64, 32)) # 归一化到 0~1加 batch 和 channel 维度 tensor torch.from_numpy(eye_roi / 255.0).float().unsqueeze(0).unsqueeze(0) with torch.no_grad(): logits net(tensor) state torch.argmax(logits, dim1).item() return [open, closed, half][state]这段代码有三个关键点。一是detectMultiScale的参数scaleFactor1.1表示每次缩放 10%越小检测越精细但越慢minNeighbors5表示候选框至少要有 5 个相邻矩形才算人脸调大能减少误检但人脸太小时会漏检。二是眼部 ROI 直接取人脸高度的前 40%在正脸且没有低头角度时够用一旦出现侧头和俯仰就必须换成关键点坐标。三是输入尺寸 64x32这是为了匹配分类网络实际工程中建议用 96x48保留更多纹理。2.3 模型选型对比CNN分类、关键点回归与序列模型这里有一个容易翻车的认知不是模型越深越准。驾驶员状态识别是近景单目标任务模型要同时兼顾精度和实时性。常见做法是三类第一类是图像分类网络输入眼部或嘴部 ROI输出状态。代表是 MobileNetV3、EfficientNet-Lite、ShuffleNetV2。这类网络最适合快速出成果因为可以直接用 ImageNet 预训练权重做迁移学习训练时间短推理也快。缺点是中间需要稳定的人脸关键点来生成 ROI否则模型看到的是歪的眼眶。第二类是关键点回归模型比如 MediaPipe Face Mesh 或 OpenFace输出 468 或 68 个点然后根据上下眼皮距离、嘴部开合度计算 EAR、MAR。这类方法不直接分类闭眼而是先算几何特征再用阈值判断。好处是对光照鲁棒因为几何量不依赖纹理坏处是当人脸被遮挡、眼镜反光或侧脸超过 45 度时关键点本身会漂移。第三类是序列模型把连续的 16~32 帧眼睛状态作为时间序列用 LSTM 或 Temporal Convolution 判断疲劳趋势。疲劳不是单帧闭眼而是闭眼频率和时长累积的结果。常见做法是先让 CNN 提取单帧特征再丢给时序层。这个方案适合做论文但工程落地时首先考虑的问题不是精度而是延迟——你必须等完一个序列才能输出结果导致报警滞后 1~2 秒。选择哪类取决于你要跑在什么设备上。如果 CPU 边缘盒子就选第一类加 Haar 级联如果有 Jetson 或独立显卡可以上 MediaPipe 关键点加分类头。我个人倾向的折中方案是用关键点模型出 ROI用轻量 CNN 做状态分类最后用滑动窗口统计 PERCLOS眼睛闭合时间比例。这样每个模块职责单一出了问题也容易单独排查。3. 数据与预处理疲劳数据集怎么找、怎么扩充、怎么喂给模型3.1 公开数据集与自采数据标注字段和协议训练驾驶员状态识别模型绕不开数据集。公开常用的有 NTHU 疲劳驾驶数据集、YawDD、Drowsy Driving Dataset 等。NTHU 包含不同光照、不同人种、戴眼镜和不戴眼镜的闭眼张嘴视频YawDD 是安装在车内后视镜下方的摄像头拍摄场景更接近真实。注意这些数据集的**:**:作者、原始链接和许可协议各不相同用于毕业设计或内部演示问题不大商用前一定要逐条核对。更可控的做法是自采数据。你需要一个普通 USB 摄像头或手机前置摄像头录制三类视频正常驾驶眼睛睁开嘴巴闭合偶尔说话持续 10 分钟以上疲劳状态模拟或真实闭眼画面里频繁出现闭眼 2 秒以上、打哈欠、点头分心状态低头看手机、转头看侧窗、打手势。录制时让被测者戴上/摘下眼镜在白天/黄昏/夜间红外出分别拍一段。因为疲劳状态往往出现在夜间而夜间图像纹理和白天差异极大数据里一定要有红外补光下的样本。标注字段不要只写闭眼/睁眼要记录帧序号、人脸框坐标、左右眼中心、嘴部中心、眼睛状态、嘴巴状态、头部姿态偏航角。后三个字段是给分类器和报告里做消融实验用的。标注工具常见做法是用 LabelImg 或开源的 keypoint 标注器。如果只标眼睛和嘴巴状态LabelImg 就够了如果要标关键点用 CVAT 更省力。标注协议要提前定死比如半睁的定义是眼皮覆盖瞳孔 30%~70%打哈欠定义为嘴巴张开且上下唇间距超过 20 像素。协议不统一后面训练出来的模型就带着标注噪声评价指标再高也是假的。3.2 人脸/眼部/嘴部ROI的提取与对齐原始视频不能直接喂给分类网络。第一步做人脸检测第二步做人脸关键点检测第三步根据关键点把眼部、嘴部裁剪成固定尺寸再做仿射变换对齐。这里最容易忽略的是对齐方向左右眼在图像里方向相反如果不把右眼水平翻转成和左眼同方向网络就会把左眼样本和右眼样本当成两个完全不同类别导致数据量被隐形减半。下面给一个基于 MediaPipe 的 ROI 提取示例它比 Haar 级联稳定得多。import cv2 import mediapipe as mp mp_face_mesh mp.solutions.face_mesh mesh mp_face_mesh.FaceMesh( static_image_modeTrue, max_num_faces1, refine_landmarksTrue, # 输出额外眼部关键点 min_detection_confidence0.5 ) # 关键点索引按FaceMesh标准 LEFT_EYE list(range(33, 40)) RIGHT_EYE list(range(263, 270)) MOUTH list(range(61, 68)) list(range(49, 55)) def extract_rois(image): results mesh.process(cv2.cvtColor(image, cv2.COLOR_BGR2RGB)) if not results.multi_face_landmarks: return None landmarks results.multi_face_landmarks[0].landmark h, w image.shape[:2] def bbox_from_idx(idx): xs [landmarks[i].x * w for i in idx] ys [landmarks[i].y * h for i in idx] left, right int(min(xs)), int(max(xs)) top, bottom int(min(ys)), int(max(ys)) pad int((right - left) * 0.3) left max(0, left - pad) right min(w, right pad) top max(0, top - int((bottom - top) * 0.5)) bottom min(h, bottom int((bottom - top) * 0.5)) return (left, top, right, bottom) L bbox_from_idx(LEFT_EYE) R bbox_from_idx(RIGHT_EYE) M bbox_from_idx(MOUTH) return L, R, M这里的核心是refine_landmarksTrue它会在原 468 点基础上额外给出眼部精细关键点让眼睛上下睑距离算得更准。min_detection_confidence0.5是个折中值调高会漏检侧面脸调低会引入误检框。实际项目中推荐在图像上叠加阴影和夜间红外样本后再调这个值因为纯白天视频调出来的置信度阈值拿到夜间直接漏一半人脸。ROI 裁剪后必须做尺寸统一。眼部建议 64x24 或 96x32嘴巴建议 64x24。分辨率不是越大越好因为夜间图像噪声多分辨率越高网络越容易过拟合斑点噪声。同时要保留足够多的边框上下文不要剪到眼皮边缘否则网络学到的不是闭眼而是边界处的黑色条带。3.3 数据增强与样本平衡别让闭眼总在夜间出现数据增强决定了模型能不能在真实场景里扛住。常见做法有亮度抖动真实车内有逆光、阴影、高斯模糊模拟运动模糊、随机水平翻转左右眼对齐、轻微旋转±5 度模拟头部姿势、以及随机遮挡模拟方向盘遮挡。注意不要用太大的几何增强因为眼睛状态对空间结构极度敏感旋转 15 度以上会把睁眼变成侧视标签反而错误。另一个隐蔽问题是样本不平衡。正常驾驶 10 分钟里闭眼总时长可能只有几十秒嘴巴张开次数更少。直接训练会让模型把所有样本都判为睁眼因为这样准确率已经 95% 以上。常见解决办法是用类别加权损失或者对闭眼、打哈欠样本做过采样拷贝。但过采样不能简单复制同一帧要在增强空间里随机生成变体否则模型会记住特定噪声。更实际的做法是按视频片段切块不要按单帧采样。因为疲劳是一个持续状态连续 60 帧中后 30 帧的闭眼和前面 30 帧的睁眼往往属于同一次疲劳过程。按片段切出来后训练集和验证集要按视频而不是按帧划分否则同一视频的相邻帧会被分进训练和验证指标虚高实车翻车。4. 模型训练与调参从MobileNet微调到PERCLOS指标落地4.1 分类头设计眼睛状态、嘴巴状态与头部姿态驾驶员状态识别通常不是单分类任务而是多个并行任务。眼睛状态、嘴巴状态、头部姿态、视线方向各需要不同层级的抽象。常见做法是共享一个骨干网络然后接多个分类/回归头这样显著减少计算量也更容易训练。比如眼睛头三分类睁眼/半睁/闭眼嘴巴头二分类正常/张大姿态头回归偏航角 yaw 和俯仰角 pitch用于判断低头和转头。如果从头训练这些头需要大量标注姿态数据。简单做法是冻结骨干只训练分类头。很多公开模型已经用大规模人脸关键点数据训练过骨干拿来做特征提取器就够了。代码层面分类头其实就是一个全连接层加 Softmax。但注意损失函数不要全部用 CrossEntropy。对于眼睛状态半睁与闭眼是模糊边界用标签平滑label smoothing能避免网络过度自信帮助收敛。姿态头用 MSE 或 Smooth L1。4.2 训练脚本与参数解释batch、lr、早停与数据增强下面给一个完整训练脚本的骨架用 MobileNetV3-Small 做骨干在自采的眼睛数据集上微调。import torch import torch.nn as nn from torch.utils.data import DataLoader from torchvision.models import mobilenet_v3_small class EyeStateNet(nn.Module): def __init__(self, num_classes3): super().__init__() m mobilenet_v3_small(weightsIMAGENET1K_V1) self.features m.features self.avgpool nn.AdaptiveAvgPool2d((1, 1)) self.fc nn.Sequential( nn.Dropout(0.2), # 防止闭眼样本过拟合 nn.Linear(576, num_classes) ) def forward(self, x): x self.features(x) x self.avgpool(x) x x.view(x.size(0), -1) return self.fc(x) model EyeStateNet(num_classes3) # 前3层特征不需要反向传播省显存 for name, param in model.features[:3].named_parameters(): param.requires_grad False train_loader DataLoader(train_set, batch_size32, shuffleTrue, num_workers4, pin_memoryTrue) criterion nn.CrossEntropyLoss(label_smoothing0.1) optimizer torch.optim.AdamW(model.parameters(), lr3e-4, weight_decay1e-5) scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max20) for epoch in range(20): model.train() running_loss 0.0 for images, labels in train_loader: optimizer.zero_grad() outputs model(images) loss criterion(outputs, labels) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), 5.0) optimizer.step() running_loss loss.item() scheduler.step() print(fepoch {epoch1}: loss{running_loss/len(train_loader):.4f}) # 每个epoch后在验证集上算准确率和F1几个参数的实践值batch_size32在 CPU 上偏大建议 16lr3e-4是微调阶段的稳定值若从头训练则要用 1e-3 并配合 Warmupweight_decay1e-5对这类图像任务够了过大会欠拟合。label_smoothing0.1很关键闭眼和半睁的边界本身有噪声平滑后模型输出的概率不会变成 0 或 1后续统计 PERCLOS 时也更稳定。梯度裁剪max_norm5.0是防野样本的后悔药训练数据里常有过度曝光的坏帧不裁剪的话一个 batch 就能把权重拉偏。4.3 评估指标准确率不够要看误报率和延迟分布很多项目用验证集准确率 98%来宣传但实际装车后天天误报。原因在于准确率对类别不平衡极度不敏感。如果驾驶员 99% 时间正常模型即使把疲劳全漏掉准确率也有 99%。正确做法是看每类别的 Precision、Recall、F1尤其是闭眼的 Rec调用以及系统的误报率。我建议额外做两个评估维度。一是时间窗口指标把连续 30 秒的视频切成段模拟实车场景看系统能否在闭眼 3 秒内触发报警只看单帧指标会忽略时序平滑带来的延迟。二是光照分组指标按白天、黄昏、夜间红外把验证集分层分别报告准确率。很多时候整体指标被白天拉高夜里的模型早就失效了。训练完记得把每帧预测结果落盘成一个 CSVfps 和置信度也记录下来后期做误报分析全靠它。5. 工程落地避坑与实时性排查5个让我熬夜的坑5.1 坑一夜间红外下的肤色偏移导致人脸丢失现象白天检测一切正常夜间开启红外补光后模型频繁输出no_face有时连续 10 秒无人脸报警完全失效。原因Haar 级联和部分人脸检测模型是在 RGB 肤色分布上训练的红外图像里人脸是灰白色纹理和亮度分布完全不同。很多人只做转换灰度图这一步但灰度分布本身已经被红外改变检测器自然拒绝。解决不要只用 Haar 级联至少换成 MediaPipe它对人脸姿态和光照的鲁棒性更好。同时做针对性微调用红外夜间视频截取 2000 张图片标注人脸框后微调检测模型。如果不想训练就用红外镜头自带的 RAW 格式做直方图均衡化通常能救回一半漏检。5.2 坑二戴墨镜/眼镜反光时眼部ROI全是噪声现象戴墨镜时眼睛完全看不见模型把墨镜框判成闭眼一直报警戴透明眼镜在侧光下反光眼部 ROI 出现高光斑块模型概率在睁眼和闭眼之间震荡。原因分类网络学的是眼睑覆盖瞳孔这一视觉模式墨镜替换了整个眼部模式反光又覆盖了瞳孔区域。这两类样本在公开数据集里很少模型没机会学。解决明确业务边界——墨镜直接判定为无法检测不要输出疲劳状态让系统发出请摘除墨镜提示而不是疲劳报警。反光样本要专门采集并在增强里加入随机高光斑点模拟反光。如果条件允许优先用红外摄像头IR 补光下透明眼镜的反光大幅度减弱。5.3 坑三训练集闭眼视频是慢动作真实眨眼只有0.1秒现象训练集里闭眼样本平均持续 1 秒模型学到的闭眼是眼皮完全垂下且维持不变真实驾驶员正常眨眼只有 0.1~0.2 秒模型将其判为半睁或短暂疲劳误触发率高。原因录疲劳视频时被测者为了配合会故意慢动作闭眼导致闭眼帧在时间上拉长。模型对持续时间没有概念但后端用 PERCLOS 统计时会放大这种差异。解决采集数据时不要刻意慢放让被测者按正常节律眨眼。训练阶段把眨眼瞬间附近的帧闭眼前 3 帧、后 3 帧也标注为半睁而不是睁眼。这样模型才能区分自然眨眼和疲劳闭眼的边界。后端还要加最短持续时间过滤闭眼持续少于 200ms 的片段直接忽略。5.4 坑四CPU推理帧率只有8FPS报警滞后2秒现象i5 笔记本上跑 MediaPipe 加 CNN 分类单帧处理 120ms再加上滑动窗口统计从闭眼到报警要 2 秒以上。高速行驶时 2 秒已经超出反应窗口。原因MediaPipe 的 FaceMesh 在 CPU 上要 20~30msCNN 分类又要 15ms但真正翻车的是每帧都在做全尺寸人脸检测且检测框里包含背景网络被迫处理大量无关像素。解决做区域缓存——上一帧检测到人脸后下一帧在上一帧人脸位置周围扩大 20% 的区域内搜索只有连续丢失 5 帧才重新全局检测。模型输入改为 96x48关闭 backbone 中不必要的 BatchNorm 融合。再进一步用 OpenVINO 或 ONNX Runtime 做图优化通常能把 CPU 推理时间压到 30ms 以内。报警端不要用滑动平均改成3 秒内闭眼总时长超过 1 秒的滚动计数复杂度低且灵敏度可控。5.5 坑五混淆矩阵很漂亮实车却疯狂误报现象验证集 F1 0.95装到驾驶模拟器上每分钟误报 2~3 次而且集中在看后视镜、低头看档位的瞬间。原因验证集是坐姿端正面对摄像头的样本实车中驾驶员会转头、点头人脸姿态变化后眼部 ROI 里包含的不再是正面的眼睛而是侧眼角和部分眉毛分类器把这种新分布误判为半睁。解决评估集里必须包含头部偏转 ±30 度、俯仰 ±15 度的样本。训练时加入姿态感知头用关键点算出的 yaw/pitch 作为额外输入让分类器明确知道当前是侧脸眼部特征不可信。更保险的策略当人脸偏航角大于 25 度时不输出眼睛状态只保留头部姿态特征用于判断分心。因为低头看手机和疲劳点头在姿态头里是有明显区分的不要试图用眼部分类去解决姿态问题。6. 技术报告与源码交付让这套系统能答辩、能交接、能继续迭代6.1 报告结构实验对比与图表是评审第一眼技术报告不是代码注释的堆叠而是要让评审或接手的人快速建立信任。我的常用结构分五块问题定义与数据说明、基线模型与方案对比、关键模块设计、实验结果、局限与后续工作。其中实验对比表最重要至少要包含模型名称、参数量、CPU 推理耗时、准确率、闭眼误报率、夜间/白天分别表现。报告里再给一张混淆矩阵热力图和几张典型误报样例图比写三百字配置说明更有说服力。数据集整理成来源、时长、人数、光照条件、标注字段的小节让读者知道你的数据边界在哪。6.2 源码组织依赖锁定、README与可复现实验源码交付最怕在我电脑上能跑。常见做法是必须在项目根目录放requirements.txt并锁定版本比如torch2.0.1、opencv-python4.8.0.74、mediapipe0.10.7。模型权重单独放checkpoints/不要 git 上传大文件但要在 README 里写清楚权重文件的放置位置和 SHA256 校验值。训练和推理要分成两个入口train.py只做训练infer.py做实时推理公共模块放models/、data/。再加一个config.yaml把模型尺寸、学习率、路径集中管理。这份整理对答辩和交接都省力——别人能按你写的方式复现才会怀疑你系统里的任何问题。6.3 一个进阶习惯把误报样本沉淀成扩展集做这个项目一年来我最后悔的是没有从一开始就把实车场景里的误报帧存下来。误报是系统的黑匣子每次翻车都是一个免费标注机会。现在我会在推理端加一个开关当模型输出的置信度低于 0.6 或连续三帧状态频繁跳变时自动保存这段原始视频片段和当时的预测结果每周人工过一遍挑出有代表性的负样本补进训练集。这个习惯让系统每周都在变稳比反复调阈值有效得多。希望你也能把能跑通的 demo变成经得起实车折腾的系统这套链路每一步都不玄学问题都能定位到具体模块。希望帮到你。本文还有配套的精品资源点击获取