简介面向驾驶员疲劳检测的YOLO数据集专为计算机视觉与智能驾驶安全场景设计适合算法工程师、研究人员及学生用于疲劳行为识别模型的训练与评估。数据集聚焦真实驾驶场景包含驾驶员闭眼、打哈欠等不同疲劳状态的面部样本为检测模型提供多姿态、多状态的正负样本TXT标注以简洁文本记录边界框坐标与类别XML标注额外提供结构化元数据两种格式均可直接导入YOLO训练流程方便对比不同标注规范对模型收敛的影响。压缩包共8744个文件其中2915张JPG图像对应2915个TXT与2914个XML标注整体大小约256.88MB文件层级规整、命名规律适合脚本批量划分训练集与验证集YOLO单阶段检测特性使其能同时捕捉闭眼、打哈欠等多类疲劳特征适配实时预警场景。已有2926人学习下载资源覆盖疲劳检测典型任务可用于数据增强实验、模型微调、多目标并行检测效果验证以及车载实时预警系统原型开发。利用该数据集可有效减少自行采集和标注疲劳图像的周期同时帮助理解YOLO在高帧率监控场景中的实际应用流程。1. 一次打盹只给 0.5 秒反应YOLO 驾驶员疲劳检测到底在研究什么第一次在自己车上跑疲劳检测心里有两个翻车预警怕模型把眨眼当闭眼也怕眼睛目标太小、在 640 输入下直接消失。一套 yolo算法驾驶员疲劳检测数据集 要解决的其实就三件事用什么样本让 YOLO 认出闭眼和打哈欠怎么训出一个不会在夜间失灵的检测器以及怎么把检测框换算成“要不要报警”。这里有个反直觉的判断YOLO 不负责判断疲劳它只输出眼睛和嘴部的状态框是否疲劳由闭眼时间比例PERCLOS和眨眼频率这些时序指标决定。这个方向适合做车载边缘盒子、驾校培训、车队司机状态预警的开发者。核心思路是数据、模型、时序判定三段各管好再拼起来。2. 驾驶员疲劳检测数据集公开基准、自采流程与标注规范提到疲劳检测数据集很多人第一反应是找一堆“打哈欠的人脸”直接开训。我一般会把任务拆成三个子问题眼睛闭没闭、嘴部张开程度算不算哈欠、光线和遮挡是否扛得住。这三个子问题对应完全不同的采集和标注策略。如果把“疲劳”直接做成一个类别标注员的主观判断会不一致模型学到的也不是可复现的视觉状态后面做时序判定时更是一团乱麻。2.1 疲劳检测做“可观察状态”分类别做语义直接的疲劳分类疲劳是一种内部状态给它打标签天然不稳定但“眼皮是否遮住瞳孔”“嘴是否张大”是可观察的。所以常见的类别设计是把任务拆成眼部和嘴部两个子任务。下面是一份我常用的类别表子任务类别判定标准标注注意眼睛状态eye_open眼睑没有明显遮住瞳孔正常平视、低头看手机也要标眼睛状态eye_closed眼睑遮住瞳孔面积超过 80%眨眼瞬间的闭眼也算但后续要靠时序过滤嘴部状态mouth_open嘴部张开幅度明显接近哈欠形态说话、吃东西时的张嘴也要标防止混淆嘴部状态mouth_closed嘴部闭合或仅有轻微动作戴口罩时按嘴部不可见处理辅助face完整人脸框用于先人脸裁剪、再检测眼睛的两级方案为什么不只做 eye_closed 一个类别因为 YOLO 训练时背景样本太多模型会把“没有检测到睁眼”误当成闭眼。把睁眼、闭眼、张嘴、闭嘴都变成显式类别模型才能学到真正的视觉差异。2.2 公开数据集如何选YawDD 预训练、DROZY 做回归、NTHU-DDD 验泛化公开数据集的角色定位很重要。YawDD 是装在车内后视镜附近的摄像头拍的驾驶视频含打哈欠、正常驾驶、不同驾驶员等场景适合做冷启动预训练但分辨率不高眼睛区域小直接拿它训练出来的模型对近距离小目标不友好。DROZY 含同步脑电信号和困倦等级标注适合研究“疲劳程度怎么回归”不适合直接喂给 YOLO 做目标检测因为它的标注粒度是实验等级而不是目标框。NTHU-DDD 覆盖多人、戴眼镜、墨镜、日夜场景适合当泛化验证集用它测试模型换人之后会不会失灵。我的经验是公开数据集只用来做预训练和验证最终部署前一定要拿自己车上的摄像头和安装角度补采一批数据。常见错误是拿公开集训练完直接上线结果车的座椅高度、摄像头视角一变检测框就开始飘。另一个容易掉进去的坑是把 BDD100K 这种交通目标数据集拿来做疲劳检测——它的人物框很多但没有人眼状态标签转过来没有意义。2.3 自采流程与比例分配抽帧、动作脚本、遮挡覆盖自采时我会让驾驶员在静止车辆里按脚本做动作正常睁眼注视前方、正常眨眼、缓慢闭眼并保持 1 到 3 秒、打哈欠、说话、低头看手机。每段动作持续 20 秒左右中间留 5 秒正常驾驶状态方便后续抽帧时区分边界。摄像头位置按实际部署位置来常见做法是装在仪表台或内后视镜附近俯视角度能同时看到眼睛和嘴。抽帧不能每帧都留。连续帧高度相似会导致训练集背景严重冗余。我一般每隔 5 到 10 帧取一帧并且用视频剪辑软件先把动作片段切出来再抽帧。比例上睁眼帧约占六成闭眼帧占两成嘴部张开的哈欠帧占两成。墨镜、口罩、侧脸、低头这些极端样本单独留出不参与主体比例分配。标注工具用 LabelImg 或 labelme 都行但导出前要统一类别名这一点在下一节会踩坑。2.4 VOC 转 YOLO 格式转换脚本与三个边界坑LabelImg 默认导出 PASCAL VOC 的 XMLYOLO 需要归一化的 txt。转换逻辑不复杂但边界情况多。下面这个脚本我一直在用import xml.etree.ElementTree as ET from pathlib import Path class_names [eye_open, eye_closed, mouth_open, mouth_closed] def voc_to_yolo_txt(xml_file, out_dir): root ET.parse(xml_file).getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.findall(object): name obj.find(name).text if name not in class_names: continue bbox obj.find(bndbox) x1 min(max(float(bbox.find(xmin).text), 0), img_w - 1) y1 min(max(float(bbox.find(ymin).text), 0), img_h - 1) x2 min(max(float(bbox.find(xmax).text), 0), img_w - 1) y2 min(max(float(bbox.find(ymax).text), 0), img_h - 1) if x2 x1 or y2 y1: continue cx ((x1 x2) / 2) / img_w cy ((y1 y2) / 2) / img_h w (x2 - x1) / img_w h (y2 - y1) / img_h lines.append(f{class_names.index(name)} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) txt_path Path(out_dir) / (Path(xml_file).stem .txt) if lines: txt_path.write_text(\n.join(lines) \n, encodingutf-8) else: txt_path.unlink(missing_okTrue)这段脚本做了三件额外的事坐标越界时按图像边界裁剪防止出现负数和超界框x2 小于 x1 的退化框直接跳过空标注 XML 不生成空 txt 而是直接删除避免训练时报“label 为空”的错觉。三个边界坑值得单独说。第一类别名大小写不一致比如有的标注员写 eye_closed有的写 Eye_Closed脚本里name not in class_names会静默跳过训练时闭眼类别直接少一半样本。第二LabelImg 偶尔会把坐标标出图像边界不 clip 的话归一化坐标会大于 1YOLO 训练时容易报错。第三数据集划分要按驾驶员 ID 切不能按文件名随机切否则同一个人同时出现在训练集和验证集验证集指标虚高换人就现原形。3. 用 YOLOv8 跑通疲劳检测训练模型选型、data.yaml 与关键参数环境搭建不复杂用 PyCharm 或终端都行pip install ultralytics装好就能跑。项目到后期要导出 ONNX、在 AGX Orin 这类设备上部署时再考虑源码编译的事。前中期不要自己从源码编译改起来费时间还容易引入环境差异。如果你用的是 NVIDIA 显卡确保 CUDA 和 PyTorch 版本对得上否则训练时device0会直接报错。3.1 从 YOLOv8n 起步的原因算力、目标大小与帧率需求模型选型先看部署算力再看目标尺寸。同一个输入分辨率下YOLOv8n 参数量约 3M、FLOPs 约 9G是速度最快的选择YOLOv8s 精度更高但推理耗时接近翻倍。疲劳检测本质上只关心眼睛和嘴两个小区域对语义理解要求不高n 模型往往够用先把流程跑通再根据漏报情况升级。真正影响精度的不是模型大小而是输入分辨率。摄像头装在顶棚时人脸可能只占画面 1/10眼睛只有十几个像素。这种情况不管用 n 还是 x640 输入都容易丢目标。常见做法是在车机上部署时用 960 输入或者在检测流程里加一步人脸裁剪先检测人脸再把眼部区域放大后送进眼态检测模型。后者的计算量更小是产品化方案里更常见的设计。3.2 配置 data.yaml 并启动训练命令逐参数拆解数据集结构建议统一成 Ultralytics 约定的形式images/train、images/val和对应的labels/train、labels/val。data.yaml 里路径、类别数量和类别名写清楚。path: /data/fatigue_yolo train: images/train val: images/val nc: 4 names: 0: eye_open 1: eye_closed 2: mouth_open 3: mouth_closed训练命令我常用的配置是这样yolo detect train \ modelyolov8n.pt \ datafatigue.yaml \ imgsz640 \ epochs120 \ batch32 \ patience20 \ optimizerAdamW \ lr00.01 \ lrf0.01 \ cls0.7 \ box7.5 \ dfl1.5 \ close_mosaic10 \ device0几个参数按实际项目调整。epochs 设 120 是给早停留余量疲劳数据集一般不过万张训练到 80 到 100 轮就会收敛patience20 表示 20 个 epoch 没提升就停。batch 大小取决于显存12G 显存跑 640 输入、batch 32 基本是上限显存不够先降到 16。优化器选 AdamW 是因为它在小数据集上通常比 SGD 更稳学习率衰减更平滑。close_mosaic10的意思是最后 10 个 epoch 关闭 Mosaic 增强因为 Mosaic 把四张图拼在一起边界框容易错位最后几个 epoch 关掉能让模型稳定下来。3.3 损失函数与类别不平衡cls、box、dfl 的调法YOLOv8 的损失函数由三块组成分类损失用 BCE边界框回归用 CIoU 加 DFL。DFL 的作用是把边界框的分布建模得更细对小目标回归有帮助。调参时不要一上来就动学习率先看类别分布。疲劳检测里闭眼帧天然比睁眼帧少模型会偏向预测睁眼闭眼类别的召回率惨不忍睹。遇到这种情况我一般把cls从默认的 0.5 提到 0.7 或 1.0让分类错误的惩罚更大。box默认 7.5如果眼睛框位置偏差明显可以提高到 10但不要超过 12否则训练初期损失会震荡。dfl默认 1.5小目标多时可以提到 2.0。如果你用的是 Ultralytics 的新版本还可以开cls_focalTrue用 Focal Loss 处理难例代价是训练时间变长。闭眼帧特别少的时候直接做数据过采样比重调损失函数更直接。3.4 训练日志的判读方法mAP50、混淆矩阵和过拟合特征每次训练结束先看两个文件results.csv和confusion_matrix.png。结果曲线里重点看 val/mAP50-95 和 val/mAP50 两条线。疲劳检测这种任务mAP50 比 mAP50-95 更有参考价值因为眼睛框的 IoU 波动很大严格阈值会低估真实性能。闭眼类别的召回率低于 0.85基本可以判断是数据问题而不是模型问题。过拟合的特征是 train loss 持续下降但 val loss 到一定程度开始反弹。这种情况先关掉数据增强里的mixup和degrees然后把dropout加在 head 层。还有一个容易被忽略的指标验证集和训练集如果按视频随机分一个人会同时出现在两边混淆矩阵会异常漂亮但上车实测就崩。按驾驶员 ID 划分数据之后mAP 会掉 3 到 5 个点这才是真实水平。4. 从检测框到疲劳判定EAR 指标、滑动窗口与报警触发模型训好后输出的是每一帧的眼睛和嘴部状态框。如果直接用单帧结果触发报警十次里有八次是误报。原因是正常眨眼也会产生闭眼帧单帧分类器无法区分“眨眼”和“疲劳闭眼”。疲劳判定必须落在时序上这一章讲怎么把检测框变成可用的疲劳指标。4.1 判定标准为什么首选 PERCLOS P80而不是简单数闭眼帧PERCLOS 是眼睑闭合时间的百分比P80 标准指眼睑遮住瞳孔面积超过 80% 就计为闭眼统计单位时间内闭眼时长占比。工程上把 EAR 低于预设阈值的一帧视为闭眼帧然后算闭眼帧占滑动窗口内总帧数的比例。正常眨眼每次持续 0.2 到 0.4 秒PERCLOS 不会因为这个短暂闭合而显著升高疲劳时闭眼会持续 0.5 秒以上甚至数秒PERCLOS 会快速拉升。阈值怎么定我一般取 30 秒为一个窗口PERCLOS 超过 0.4 触发一级报警。这个值参考了驾驶疲劳研究的常见设定但因为每个人的眼型差异部署前最好用目标驾驶员做一次 30 秒正常驾驶的基线标定。车内光线变化剧烈固定阈值不够稳基线标定的意义是把每个人的“正常 EAR 下限”记下来。4.2 EAR从眼部关键点得到连续值以及阈值标定EAREye Aspect Ratio使用眼睛的六个关键点计算公式是垂直方向两个距离之和除以水平距离的两倍。下面是标准实现import numpy as np def eye_aspect_ratio(eye_landmarks): # eye_landmarks 为单眼 6 个关键点按顺序排列 p0, p1, p2, p3, p4, p5 eye_landmarks vertical_a np.linalg.norm(p1 - p5) vertical_b np.linalg.norm(p2 - p4) horizontal np.linalg.norm(p0 - p3) return (vertical_a vertical_b) / (2.0 * horizontal)睁眼时 EAR 大约在 0.25 到 0.35闭眼时接近 0。阈值取 0.2 是一个常见起点但每个人眼型不同双眼皮、单眼皮、眯眼习惯都会改变分布。我一般让驾驶员正常睁眼 15 秒取 EAR 均值乘以 0.75 作为该驾驶员的闭眼阈值。如果没有关键点模型也可以用 YOLO 的眼部检测框的高度和宽度比值近似替代虽然精度差一些但胜在实现简单。4.3 滑动窗口状态机把眨眼过滤掉把真闭眼留下来拿到 EAR 后用状态机做连续帧判定。以下面的简化逻辑为例class FatigueJudge: def __init__(self, ear_threshold0.2, close_trigger20, yawn_trigger45): self.ear_threshold ear_threshold self.close_trigger close_trigger self.yawn_trigger yawn_trigger self.close_count 0 self.yawn_count 0 self.fatigue_warning False def update(self, ear, mouth_open): if ear is None: self.close_count 0 return self.fatigue_warning if ear self.ear_threshold: self.close_count 1 else: self.close_count 0 if mouth_open: self.yawn_count 1 else: self.yawn_count 0 if self.close_count self.close_trigger or self.yawn_count self.yawn_trigger: self.fatigue_warning True else: self.fatigue_warning False return self.fatigue_warning在 30 FPS 下close_trigger20表示闭眼持续约 0.67 秒才触发正常眨眼约 0.2 到 0.4 秒计数达不到 20 就被清零所以能过滤眨眼。yawn_trigger45表示嘴部持续张开 1.5 秒才算哈欠说话、吃东西时的张嘴不会误触发。实际部署时我会把这段逻辑再包一层 10 秒滑动平均避免单帧检测抖动导致报警闪烁。状态机的优势是逻辑透明出了问题可以直接对着帧号回放。4.4 夜间低照度场景红外补光与灰度域训练疲劳检测最容易出问题的是夜间。没有补光时RGB 摄像头在低照度下拍到的眼睛是一片黑模型要么漏检要么把暗光误判成闭眼。常见做法是换用带红外补光的摄像头红外光下瞳孔区域和眼白对比更明显闭眼状态反而更稳定。训练侧也要配合。如果部署目标是红外摄像头自采数据时就用红外图像如果没有条件可以在训练时对 RGB 图像做灰度化增强把三通道都替换成亮度值模拟单色红外效果。另一个有效手段是 gamma 变换增强暗部细节让模型学会在低亮度下仍然依赖眼部轮廓而不是整张脸的平均亮度。只依赖 RGB 训练的模型拿到红外视频上大概率直接崩这一点要在项目早期就决定摄像头方案。5. 疲劳检测项目最容易踩的五个坑数据、训练与部署排查这一章把我在项目里反复踩过的坑列出来。每一条都是“现象 → 原因 → 解决”的结构可以参考对比自己遇到的问题。5.1 眨眼被识别成闭眼导致系统性误报现象系统在白天正常驾驶时频繁报警回看视频发现每次报警都对应一次快速眨眼。原因单帧分类器只能看到“这一帧眼睛闭着”无法判断这次闭眼持续了多久眨眼和疲劳闭眼在单帧图像上表现完全一致。解决把判定逻辑挪到时序层用close_trigger计数过滤短暂闭眼。如果误报仍然明显进一步统计每分钟眨眼次数疲劳状态下眨眼频率会从正常每分钟 15 到 20 次降到 5 次以下把眨眼频率纳入评分能显著减少单一指标带来的误报。5.2 墨镜和镜片反光让眼睛目标直接丢失现象驾驶员戴墨镜时系统完全不报警即使人已经明显点头打瞌睡。原因训练集以裸眼为主模型没见过镜片遮挡下的眼部特征检测框直接丢失反光场景下镜片上的高光会被模型当成眼睛纹理输出错误的关键点。解决数据侧补墨镜、近视镜、偏光镜样本每天拍一段戴镜驾驶视频回灌训练集部署侧优先选红外摄像头红外光能穿透部分镜片瞳孔轮廓依然可见。不要指望用图像增强完全解决物理上补光是正路。5.3 眼睛区域太小mAP 高但实车检测不到现象验证集 mAP50 有 0.92装到车上后闭眼召回率不到一半。原因训练集里的眼睛框占比大摄像头安装角度变化后眼睛只有十几个像素小目标特征在下采样过程中丢失。解决两级检测方案最常见先用一个轻量人脸检测器定出人脸框裁剪放大后再跑眼态检测或者把输入分辨率从 640 提升到 960代价是推理帧率下降。不要为了帧率一味压低分辨率疲劳检测对实时性的要求是 25 FPS 以上低于这个值宁可砍一半检测频率也要保住目标。5.4 闭眼样本太少模型偏向预测睁眼现象训练曲线显示整体 mAP 不错但混淆矩阵里闭眼那一行大量漏检预测结果几乎都落在 eye_open。原因睁眼帧占比过高类别不平衡导致模型学到了最小化损失的最优解也就是把一切预测成睁眼。解决过采样闭眼帧按帧数配平到睁眼的 1/3 以上配合cls0.7提高分类损失权重如果使用 Focal Loss把难例挖掘的重点放在闭眼和哈欠两类上。最后别忘了按驾驶员划分验证集否则类别不平衡的问题会被数据泄漏掩盖。5.5 导出 ONNX/TensorRT 后精度掉点现象PyTorch 推理一切正常导出到 TensorRT 后闭眼检测率掉 2 到 5 个百分点。原因INT8 量化校准集只有普通场景闭眼帧和低照度帧没有被充分覆盖导出时动态输入尺寸导致 NMS 行为变化。解决先用 FP16 跑性能通常翻倍且精度基本无损要用 INT8 时校准集单独准备两百张以上包含闭眼、哈欠、夜间、反光的帧。导出时固定imgsz不要开大的动态尺寸范围测试通过后再考虑动态 batch。这个坑在 AGX Orin 上尤其常见TensorRT 版本和 PyTorch 的算子兼容性也要提前验证。6. 进阶玩法把模型剪枝量化到车载盒子用数据闭环持续验证疲劳检测项目走到部署阶段才算真正开始。模型剪枝和量化是车载盒子绕不开的两步但落地顺序上我建议先量化、后考虑剪枝。YOLOv8n 本身已经很小剪枝省下的参数有限而 TensorRT 的 FP16/INT8 量化通常能直接让帧率翻倍。训练好的模型导出 ONNX再转到 TensorRT engine命令的一头一尾都不复杂真正麻烦的是量化校准集。6.1 量化校准集需要“疲劳帧”不是随便抽 128 张INT8 量化校准集决定了量化后的精度表现。如果只从正常驾驶片段抽帧校准集里几乎没有闭眼和低照度样本量化后这些稀有类别的激活分布会被截断掉点全掉在闭眼类别上。我会单独整理一套校准集闭眼帧、哈欠帧、夜间帧、反光帧各占四分之一总量控制在 300 张左右。校准集不需要标注但必须覆盖目标场景的尾部特征尤其是那些模型本来就容易翻车的帧。量化后做一次对比测试FP16 和 INT8 在同一条夜间行驶录像上的漏报率差异应控制在 1 次以内。6.2 误报和漏报回灌重训疲劳检测的数据闭环模型上线后的最优操作是把每一次误报和漏报对应的视频片段自动存下来。车载盒子存储有限我会在触发报警前后来一段 10 秒录像连同检测结果一起存到 SD 卡每周人工筛一遍把确认的难例补进数据集的训练与验证部分然后增量训练。这个流程跑三轮之后模型对目标的适应能力会明显超过纯静态训练。一次翻车案例是某驾驶员常年在副驾驶位放一个玩偶模型学到的背景特征迁移到新车上开始漏检回灌重训两周后恢复。这比调任何超参都管用也是疲劳检测系统长期稳定运行的最后一道保障。希望帮到你。本文还有配套的精品资源点击获取