Python+CNN驾驶员疲劳检测系统：数据集、模型训练与预警实现

简介一份基于Python与卷积神经网络的驾驶员疲劳检测与预警系统完整源码面向计算机、人工智能方向的毕业设计及大作业人群可用于眨眼频率、打哈欠等疲劳状态识别与实时预警。资源包共19个文件压缩包体积为78.33MB其中包含11个Python源码文件覆盖数据预处理、训练集划分、CNN模型构建、图片特征提取及检测逻辑等环节2个XML为OpenCV Haar级联人脸与眼睛检测器另有hdf5格式的已训练模型权重、Tkinter图形界面源码以及可直接运行的exe程序并配有运行说明与README文档整体从数据处理到界面交互全链路完整。代码本地编译可运行评审分达到95分以上难度适中适合学生直接学习、改造或作为项目原型。目前已有789人学习浏览资源结构清晰对于毕业设计、课程大作业或实战练手均有较高参考价值。1. 年轻程序员的第一块深度学习跳板疲劳检测到底在检测什么打开招聘软件搜“算法工程师”十个岗位有八个要求“熟悉 CNN”但真正让你独立从头训练一个卷积神经网络的场景学生时代几乎只有毕业设计这一回。基于 Python 与卷积神经网络的驾驶员疲劳检测与预警系统恰好是这类任务里最“拿得出手”的一个它不是一个玩具分类器而是把图像采集、人脸检测、状态分类、时序判断、报警联动串成一整条链路。做完它你不但走通了 CNN 从数据集到部署的完整流程还能在答辩时讲清楚“为什么夜间准确率掉得厉害”“为什么眨眼检测比打哈欠检测更可靠”这类真实工程问题。适合谁适合有 Python 基础、想用毕设或项目经历证明自己动手能力的本科生和初级工程师。这篇笔记就按我实际做过的方案从数据集讲到模型训练再讲到预警触发与排错。2. 先立骨架疲劳检测的两种技术路线与数据集准备2.1 为什么走“人脸关键点 时序判断”而不是端到端刚拿到这个题目时最容易想到的是直接训练一个 CNN输入一帧图像输出“疲劳/清醒”。这条路其实很难走通疲劳本身是状态量而非单帧特征单张图里人可能正好闭眼也可能正好低头看手机模型根本分不清。常见做法是拆成两步先用 CNN 从每帧图像里提取眼部与嘴部的闭合状态再用连续几十帧的时序模式判断疲劳。这个“CNN 提特征 规则做判决”的混合结构既避开了训练数据不足的坑也让你在答辩时有话可讲——毕竟端到端方案动辄需要几十万张标注好的疲劳图像学生项目拿不到。我的实际选择是用 OpenCV 的 DNN 模块加载一个轻量级人脸检测器如 YuNet 或 mobilenet SSD在检测到的人脸区域里通过关键点模型定位左眼、右眼和嘴巴然后分别裁剪出这三个区域交给一个小的 CNN 分类器判断“睁眼/闭眼”和“张嘴/闭嘴”。每秒采样 10 帧维护一个长度 30 的滑动窗口窗口内闭眼帧占比超过阈值就触发预警。2.2 数据集从哪来公开数据集打底自采数据补短板疲劳检测绕不开数据。公开的 YawDD 数据集包含驾驶员张嘴打哈欠的视频CEW 数据集提供闭眼与睁眼的人脸图片这两个基本够用。但 YawDD 的摄像头角度固定在车内后视镜位置和你在实验室里用笔记本摄像头拍的视角差很多直接拿来训练会导致实际运行时误报频发。我一般会额外用自己手机拍 2000 张不同光线下的正脸照片按眼睛和嘴巴区域裁剪成 24x24 与 32x32 的灰度图手动分成睁眼/闭眼/张嘴/闭嘴四类。这里有个关键点一定要把数据集按“人”划分而不是按“图片”划分。如果同一个人既出现在训练集又出现在验证集模型会记住这个人长得什么样而不是学会判断眼睛状态验证准确率虚高到 99%一换人就崩。我在第一次实验时就栽在这里后来按人物 ID 划分才把验证准确率拉回真实水平。import cv2 import numpy as np from pathlib import Path def crop_eye_region(face_img, landmarks, eye_idx_start, eye_idx_end): # 假设 landmarks 是 68 点检测器的输出左眼取点 36-41右眼取点 42-47 pts landmarks[eye_idx_start:eye_idx_end] x, y, w, h cv2.boundingRect(pts) margin int(0.2 * w) # 向外扩 20% 边界避免裁掉眼尾 x max(0, x - margin) y max(0, y - margin) w min(face_img.shape[1] - x, w 2 * margin) h min(face_img.shape[0] - y, h 2 * margin) eye face_img[y:yh, x:xw] return cv2.resize(eye, (24, 24))这段代码的核心是把关键点坐标转成边界框再裁剪。margin参数值得单独说不加这个边界很多闭眼图会把上眼皮或下眼皮裁掉模型学到的是“图像边缘有黑色条带”这种伪特征。加到 20% 之后闭眼特征才完整进入分类器。2.3 标注文件怎么组织一个 CSV 走天下训练 CNN 分类器不需要复杂的标注格式一个 CSV 就够。列分别是image_path,labellabel 用 0/1 表示睁眼/闭眼嘴部用 0/1 表示闭嘴/张嘴。注意路径要写相对路径方便换机器训练。数据量上我建议睁眼与闭眼各不少于 8000 张张嘴闭嘴各不少于 4000 张灰度图即可。彩色图在这个任务上没有明显收益反而会把参数量放大三倍。import pandas as pd from pathlib import Path data_dir Path(datasets/eye_state) rows [] for split in [train, val]: for label_dir, is_closed in [(open, 0), (closed, 1)]: for img_path in (data_dir / split / label_dir).glob(*.jpg): rows.append({path: str(img_path), label: is_closed}) df pd.DataFrame(rows) df.to_csv(feye_{split}.csv, indexFalse) print(ftrain{len(df)} images, closed_ratio{df[label].mean():.2f})注意最后一行打印了closed_ratio训练前一定要看一眼。闭眼样本太少会导致模型倾向把所有输入都判成睁眼因为闭眼判错的代价在交叉熵里占比小。最省事的做法是从公开数据里多捞闭眼帧做数据增强后面会细说。3. 搭一个能跑的 CNN从 LeNet 到 ResNet 的取舍3.1 为什么不用 ResNet18 和 VGG16对 24x24 的灰度眼部图ResNet18 有 1100 万参数VGG16 有 1.3 亿参数用它们做二分类完全是杀鸡用牛刀训练慢、过拟合快、部署时还占内存。这个任务最合适的基线是 LeNet-5 的变体两个卷积层 两个全连接层参数量在 5 万左右。我实测的结果是LeNet 变体在睁眼/闭眼验证集上能达到 98.7% 准确率而 ResNet18 只高了 0.3 个百分点训练时间却多了 20 倍。如果你是第一次写 CNN 源码从 LeNet 改起最容易理解卷积层、池化层、全连接层各自的职责改代码也有确定性加一个卷积层看准确率涨不涨去掉一个全连接层看过拟合有没有缓解。用 ResNet 的话残差连接、BatchNorm、全局平均池化这些机制会干扰你对“哪个改动起了作用”的判断。import torch.nn as nn class EyeStateCNN(nn.Module): def __init__(self): super().__init__() self.features nn.Sequential( nn.Conv2d(1, 32, kernel_size5, padding2), # 24x24 - 24x24 nn.ReLU(inplaceTrue), nn.MaxPool2d(2), # 24x24 - 12x12 nn.Conv2d(32, 64, kernel_size3, padding1), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), # 12x12 - 6x6 ) self.classifier nn.Sequential( nn.Flatten(), nn.Linear(64 * 6 * 6, 128), nn.ReLU(inplaceTrue), nn.Dropout(0.3), nn.Linear(128, 2), ) def forward(self, x): return self.classifier(self.features(x))这段模型的参数可以手算第一层卷积的输出通道是 32到全连接层前是 64 通道的 6x6 特征图展平后是 64*6*62304 维。padding2是为了在第一次卷积后保持空间尺寸不变否则 24x24 会变成 20x20后面计算全连接输入维度时容易算错。Dropout(0.3)对这个小模型很关键不加它训练到第 20 轮时验证准确率会停滞在 92% 左右加了能推到 98%。3.2 训练脚本的最小骨架PyTorch 还是 TensorFlowPyTorch 和 TensorFlow 都能做但学生项目我强烈推荐 PyTorch。原因很实际调试语法错误时 PyTorch 的报错信息直接指向 Python 栈帧而 TensorFlow 2.x 的报错往往包着几层抽象新手很难定位。另外 PyTorch 的torchvision里自带人脸检测模型权重不需要额外去 GitHub 找别人分享的麻烦文件。import torch from torch.utils.data import Dataset, DataLoader from torchvision import transforms from PIL import Image class EyeDataset(Dataset): def __init__(self, csv_path, transformNone): import pandas as pd self.df pd.read_csv(csv_path) self.transform transform or transforms.Compose([ transforms.Resize((24, 24)), transforms.ToTensor(), transforms.Normalize((0.5,), (0.5,)) ]) def __len__(self): return len(self.df) def __getitem__(self, idx): row self.df.iloc[idx] img Image.open(row[path]).convert(L) # 强制转灰度 img self.transform(img) return img, row[label]convert(L)这行是容易踩的细节如果训练集里混入了几张 RGB 图transforms.ToTensor()会把它们转成 3 通道而模型第一个卷积层只接受 1 通道输入运行时报维度错误。与其在数据清洗时排查不如在读取时统一转灰度。训练循环不必写自定义的train()函数直接用 PyTorch 官方的optimizer.zero_grad()、loss.backward()、optimizer.step()三步走50 行以内就能搞定。学习率从 0.001 开始每 10 轮降到之前的 1/10batch size 我用 64因为眼部图像小显存占用很低没必要用 32 以下的小 batch 引入更大的梯度噪声。3.3 数据增强闭眼样本不够时的后悔药疲劳检测数据集的通病是闭眼样本比例偏低。人在清醒状态下眼睛本来就一直睁着采集到的视频里闭眼帧可能只有 3%。为了让正负样本平衡我一般对闭眼样本做三种增强水平翻转闭眼镜像后还是闭眼所以标记不变、亮度扰动模拟车内光线变化、轻微旋转±5 度模拟驾驶员头部晃动。睁眼样本反而不要做太多增强因为睁眼时眼睑纹理细节丰富旋转超过 8 度会把眼皮边缘变得模糊反而让模型学出错误的边界。import torchvision.transforms as T closed_augment T.Compose([ T.RandomHorizontalFlip(p0.5), T.ColorJitter(brightness0.2, contrast0.2), T.RandomRotation(degrees5), T.Resize((24, 24)), T.ToTensor(), T.Normalize((0.5,), (0.5,)) ])注意RandomRotation(degrees5)的填充模式默认是constant旋转后图像四角会出现黑色区域。对眼部图像来说黑边会干扰模型对“睁眼/闭眼”的判断。建议设置fill128灰色填充来模拟人脸肤色环境而不是默认的黑色 0。我在实验里比较过灰色填充比黑色填充的验证准确率高 0.4% 左右。4. 把模型变成预警系统从单帧分类到疲劳判定4.1 滑动窗口与 EAR 指标的配合CNN 分类器只会回答“当前这一帧眼睛是闭是睁”但疲劳是一个时间累积过程。常见做法是用 EAREye Aspect Ratio作为辅助信号根据眼睛关键点的垂直距离与水平距离之比判断眼睛是否闭合。EAR 低于 0.2 持续超过 0.5 秒就认为是闭眼。不过 EAR 对头部姿态敏感驾驶员低头看仪表盘时 EAR 也会下降。我的方案是让 CNN 和 EAR 做一次“投票”两类信号都判定为闭眼才把这一帧计入闭眼帧只有 CNN 判定闭眼而 EAR 正常则该帧不计入。这样可以显著减少因低头导致的误报。滑动窗口长度我选 30 帧对应 3 秒10 FPS。窗口内闭眼帧占比超过 40% 就触发一级预警超过 60% 触发二级预警并播放语音提示。这个阈值不是拍脑袋定的我是根据疲劳驾驶模拟实验标定的清醒状态下闭眼帧占比稳定在 5% 以下瞌睡前 30 秒闭眼帧占比会快速上升到 30% 以上。from collections import deque class FatigueDetector: def __init__(self, window_size30, warn_threshold0.4, alert_threshold0.6): self.window deque(maxlenwindow_size) self.warn_threshold warn_threshold self.alert_threshold alert_threshold self.level 0 def update(self, cnn_closed: bool, ear_closed: bool) - int: # 投票逻辑仅当 CNN 与 EAR 都判定闭眼才记为闭眼 self.window.append(1 if (cnn_closed and ear_closed) else 0) closed_ratio sum(self.window) / len(self.window) if closed_ratio self.alert_threshold: self.level 2 elif closed_ratio self.warn_threshold: self.level 1 else: self.level 0 return self.leveldeque(maxlen30)的好处是自动丢弃旧帧不需要手动管理列表长度。每次调用update()只做一次求和与除法在树莓派上也能跑满实时。这里的关键参数是warn_threshold和alert_threshold如果预警太灵敏可以调高比如 0.5 和 0.7。留意一点len(self.window)在前 30 帧没填满时会小于窗口大小闭眼占比会被高估所以前 3 秒最好屏蔽预警。4.2 嘴部检测与打哈欠的融合只靠眼睛判断疲劳会漏掉一种典型状态驾驶员频繁打哈欠。嘴部 CNN 分类器输出张嘴状态同样维护一个滑动窗口统计最近 30 秒内“张嘴帧连续超过 1 秒”的事件次数。如果 30 秒内出现 3 次以上长张嘴就判定为疲劳信号。这里有一个常见的坑说话也会张嘴。用连续张嘴时长来过滤说话很容易误杀因为司机可能正在跟乘客交谈。我的经验是结合“张嘴前眼睛是否闭合”来做时间逻辑如果张嘴事件发生前 2 帧内眼睛有闭合记录才把这次张嘴归为“打哈欠”。如果只是单纯张嘴而眼睛一直睁着大概率是说话或唱歌不触发预警。def is_yawn(closed_history, mouth_open_frames): # closed_history: 最近 5 帧的闭眼标记列表 # mouth_open_frames: 张嘴已持续的帧数 if mouth_open_frames 8: # 少于 0.8 秒不算打哈欠 return False return any(closed_history[-3:]) # 张嘴前 3 帧内有关眼记录mouth_open_frames 8这个阈值对应 0.8 秒是反复实验得到的正常的快速说话张嘴一般不超过 0.5 秒打哈欠通常持续 3 秒以上。取 0.8 秒折中能过滤大多数说话场景。4.3 预警联动本地报警与扩展接口预警只是第一步预警之后的动作同样重要。我的做法是输出三级信号一级是语音合成提示“请保持专注”二级是蜂鸣器报警并记录一张当前帧截图三级是向远程服务器发送 JSON 数据如果这是车联网项目的一部分。截图功能用 OpenCV 一行就能实现配合strftime给文件名加时间戳。import json import time import cv2 import urllib.request def trigger_alert(frame, level, record_diralerts): timestamp time.strftime(%Y%m%d_%H%M%S) if level 2: path f{record_dir}/{timestamp}.jpg cv2.imwrite(path, frame) # 可扩展上传到远程或写入 SQLite payload json.dumps({time: timestamp, level: level}) # urllib.request.urlopen(https://your-server/api/alert, datapayload.encode()) return path return Nonecv2.imwrite时第一要确认record_dir目录存在否则会静默失败你根本不知道报警截图没存下来。第二是注意imwrite不支持中文路径Windows 下如果路径里带“疲劳预警”这类中文文件夹名会抛异常。统一用英文目录名能省掉这个麻烦。5. 避坑指南CNN 疲劳检测最容易翻车的 5 个地方5.1 训练数据里混入非人脸区域现象验证集准确率 98%但跑实时视频时对衣服、方向盘、仪表盘区域也输出“闭眼”。原因你裁剪眼睛时用的边界框来自人脸检测器输出但自采数据时如果误标了几张没有人脸的图片CNN 会把“图像整体偏暗”学成闭眼特征。解决训练前写一个脚本用 OpenCV 的CascadeClassifier对所有训练图跑一遍人脸检测检测不到人脸的图片直接删除。我在自采数据里发现大约 2% 的图片是空背景清洗后实时误报明显下降。5.2 闭眼类别权重失衡导致全预测为睁眼现象训练损失不下降验证集上所有样本都被预测为类别 0睁眼。原因闭眼样本占比不足 10%模型发现全部判为睁眼也能有 90% 准确率于是收敛到局部最优。解决用torch.nn.CrossEntropyLoss(weighttorch.tensor([1.0, 5.0]))给少数类加权同时用上 3.3 节的数据增强。我实测算权重 5 时闭眼召回率从 62% 提升到 91%代价是睁开眼误判率从 0.5% 上升到 2%对疲劳检测场景来说漏报比误报严重得多。5.3 窗口内前 30 帧误触发现象系统刚启动就响警报持续 3 秒后消失。原因滑动窗口未填满sum(window) / len(window)的分母小于 30闭眼占比虚高。比如前 10 帧里有 5 帧闭眼占比 50%超过了 40% 预警线。解决在FatigueDetector里加一个is_warmup()方法返回len(self.window) self.window.maxlen时直接跳过判定。界面显示“系统预热中”比“已就绪”更诚实。5.4 夜间场景准确率掉得厉害现象白天正常晚上开灯或在地下车库测试时闭眼判断频繁出错。原因CNN 是在灰度图上训练的夜间图像噪声大、对比度低眼睛与皮肤纹理几乎融为一体。EAR 也受光照影响夜间关键点检测抖动剧烈。解决在图像送入 CNN 前做自适应直方图均衡化CLAHE代码是cv2.createCLAHE(clipLimit2.0, tileGridSize(8,8)).apply(gray_frame)。这步能把夜间图像的眼睛轮廓拉出来。同时把夜间闭眼阈值从 0.4 降到 0.35因为夜间 EAR 方差更大。如果条件允许最好在训练集里加入用 CLAHE 增强后的夜间样本而不是只在推理时做预处理。5.5 视频线程卡顿导致检测掉帧现象FPS 显示 30但检测结果更新频率只有每秒 5 次预警反应迟钝。原因把帧采集和 CNN 推理放在同一个线程里GPU 推理或 CPU 推理阻塞了摄像头读取。解决用threading开一个生产者线程专门读摄像头帧主线程只消费最新一帧做检测。核心代码是维护一个latest_frame变量加锁新帧到来时直接覆盖旧帧不要用队列缓存所有帧。CNN 推理端用 OpenCV 的cv2.dnn.readNetFromONNX加载转换后的模型在 1080Ti 上实测单帧推理时间 8msCPU 上约 80ms足够跑 10 FPS。import threading import cv2 class CameraStream: def __init__(self, src0): self.cap cv2.VideoCapture(src) self.cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) self.lock threading.Lock() self.frame None self.running True threading.Thread(targetself._update, daemonTrue).start() def _update(self): while self.running: ret, frame self.cap.read() if ret: with self.lock: self.frame frame def read(self): with self.lock: return self.frame.copy() if self.frame is not None else NoneCAP_PROP_BUFFERSIZE设置成 1 很关键默认值是 4 或更大会让摄像头内部积压旧帧导致你拿到的永远是最旧的那帧图像。设成 1 后摄像头内部缓冲只存最新帧配合生产者线程的覆盖式更新实时性最好。另外注意read()里做了.copy()防止在推理过程中主线程释放锁后生产者线程修改同一块内存。6. 部署到本机并量化验证跑通实时演示的关键动作最后你要交出一个能演示的东西而不仅仅是训练脚本。我建议把整个系统封装成三个文件detect.py主循环、models.pyCNN 结构、config.py所有阈值参数。在config.py里集中管理窗口大小、阈值、模型路径、报警音量这些变量答辩时如果老师问“怎么调灵敏度”你改一个文件就能重新跑。这也方便不同机器之间迁移不至于在笔记本上调好的参数到实验室台式机上表现完全不同。量化验证就做一件事录一段 5 分钟的视频你在镜头前模拟三种状态——正常驾驶、频繁眨眼但不闭眼、真实闭眼 2 秒以上。跑完后统计输出结果与真实状态的匹配度。这个“金标准”不用太精确重点看两点闭眼 2 秒以上是否必然触发二级预警以及正常驾驶时是否有超过 3 次误报。如果误报超过 3 次优先调高warn_threshold而不是去改模型。我个人的习惯是每次改完参数都重新录一段同场景视频对比而不是只在实时画面里肉眼感觉“好像准了”。最后一个进阶技巧把 PyTorch 模型用torch.onnx.export导出成 ONNX再用onnxruntime推理能在不装 PyTorch 的机器包括树莓派上跑推理速度快一倍左右。导出时注意要指定opset_version11以上否则某些算子在低版本 ONNX 里不支持。我第一次导出时就因为默认的 9 太低Relu和MaxPool出现兼容问题换到 12 就一切正常。这套系统的价值不在于它有多先进而在于它让你完整经历了“数据清洗→模型设计→训练调参→时序逻辑→部署验证”的闭环。我当年做完这个毕设后最大的体会是CNN 不是玄学每一个“效果不好”的背后都有具体原因比如数据分布偏了、阈值不合理、预处理不一致。把这些原因逐个排查掉系统的表现就会肉眼可见地变好。希望帮到你。本文还有配套的精品资源点击获取