简介这套面向计算机视觉方向毕业设计的驾驶员疲劳检测与预警系统完整项目基于Python3.6与卷积神经网络实现结合dlib人脸68关键点检测通过眼睛宽高比EAR、眨眼频率、嘴巴张合程度、瞳孔朝向等指标综合判断疲劳状态覆盖打哈欠、眨眼、点头三类典型特征适合需要在真实场景中复现并扩展疲劳检测功能的学生或开发者参考。压缩包共20个文件总大小约78.32MB核心为11个Python源文件涵盖数据处理、模型训练与评估、界面交互等模块另有预训练hdf5模型、人脸检测xml配置、exe可执行程序以及系统说明/运行说明/README文档目录按功能拆分便于定位与二次开发。目前已有61人学习项目附带可运行的模型文件和完整使用说明读者可直接运行exe或通过Python源码调用快速上手同时可从数据预处理、CNN模型结构到疲劳判定逻辑逐层理解实现思路为毕业设计或课程设计提供可落地的参考方案。1. 人脸识别驾驶员疲劳检测与预警系统到手先别急着跑先看透这套资源做毕业设计选“人脸识别驾驶员疲劳检测与预警系统”这个题目很多人是冲着“一跑通、能交差”来的。这套基于 Python 和卷积神经网络的完整资源把源码、模型文件、训练资料打包得挺全但我的建议是解压之后千万别直接python main.py环境不对、阈值不准照样翻车。我拆过几套类似的毕业设计这套的价值在于人脸检测、关键点定位、CNN 分类、预警触发全链路都给出了可改的代码不是黑匣子。下面按“原理→跑通→排错→调优”的顺序讲透。2. 系统框架与算法选型从摄像头画面到预警信号中间经过四步处理2.1 整体流程视频帧、人脸检测、关键点、状态分类、疲劳判定怎么串成一条线疲劳检测类系统的第一课是把“画面”变成“状态”。摄像头进来的是连续帧但系统真正关心的是每一帧里司机的眼睛是睁开还是闭合、嘴巴是张开还是合拢。常见做法是先用一个人脸检测模型把人脸框出来再用关键点检测模型找到眼睛和嘴巴的位置最后把局部图像交给卷积神经网络做分类。这个链路听起来长实际跑起来可以做成一个稳定的主循环我习惯用下面的骨架代码来表示import cv2 import numpy as np # 0 表示默认摄像头如果是外接摄像头改成 1 或 2 cap cv2.VideoCapture(0) fps cap.get(cv2.CAP_PROP_FPS) while True: ret, frame cap.read() if not ret: break # 人脸检测conf_threshold 控制最小置信度0.7 是常见取值 faces face_detector.detect(frame, conf_threshold0.7) for (x, y, w, h) in faces: face_roi frame[y:yh, x:xw] # 关键点定位返回眼睛、嘴巴等区域坐标 landmarks landmark_detector.get_landmarks(face_roi) # 裁剪左右眼和嘴巴区域统一缩放到 48x48 left_eye crop_resize(face_roi, landmarks[left_eye], (48, 48)) right_eye crop_resize(face_roi, landmarks[right_eye], (48, 48)) mouth crop_resize(face_roi, landmarks[mouth], (48, 48)) # 两个 CNN 分类器一个管眼睛一个管嘴巴 eye_closed_prob eye_model.predict(left_eye, right_eye) mouth_open_prob mouth_model.predict(mouth) # 结合 PERCLOS 和打哈欠频率做最终判定 alarm fatigue_judge(eye_closed_prob, mouth_open_prob, fps) if alarm: send_alert()代码的逻辑并不复杂真正需要调的是几个参数。conf_threshold0.7的意思是只有置信度高于 0.7 的人脸框才会进入后续流程调高会漏掉侧脸和戴墨镜的人调低会把车窗外的行人当人脸导致后续裁剪区域乱七八糟。48x48是很多小型 CNN 常用的输入尺寸它平衡了计算量和识别精度如果你换更大尺寸训练和推理时间都会明显上涨但对疲劳检测这个场景48 足够用。资源里的实际实现可能用的是 OpenCV DNN 或 MTCNN 做人脸检测分类器也可能接的是两组不同的模型但主循环的骨架一般就是上面这样。拿到代码先定位这个循环再去看每一步调用的函数比从README开始读更高效。另外要注意fps的用法PERCLOS 统计的是闭眼帧占时间窗的比例必须把帧数除以帧率换算成秒否则不同摄像头下同一个闭眼动作会被算成不同的疲劳程度。2.2 为什么选卷积神经网络而不是纯阈值判断精度与实时性的平衡传统疲劳检测里有一个很经典的指标叫眼睛纵横比EAR通过计算上下眼睑关键点距离来判断眼睛闭合程度。这个方法胜在计算量小但它的缺陷也很明显对光照、眼镜、遮挡和摄像头角度极其敏感。同一个人的眼睛在逆光下 EAR 值可能比正常光照低 20%戴黑框眼镜时关键点定位经常偏移这几类情况都会让固定的阈值失效最终表现为“清醒时乱报警、打盹时不报警”的玄学现场。EAR 的计算公式其实很直接假设一只眼睛周围有 6 个关键点纵向距离取平均除以横向距离就能得到一个与图像缩放基本无关的比值。我在调试传统方案时会用下面这段代码它同时也是理解 CNN 分类器输入的好参照# 传统 EAR 计算基于 6 个关键点坐标 def eye_aspect_ratio(landmarks): # 左右眼角 p1 landmarks[0] p4 landmarks[3] # 上下眼睑 p2 landmarks[1] p3 landmarks[2] p5 landmarks[4] p6 landmarks[5] ear (dist(p2, p6) dist(p3, p5)) / (2.0 * dist(p1, p4)) return ear这里的dist是欧氏距离函数可以用numpy.linalg.norm实现。EAR 在清晰正脸、均匀光照下非常灵敏可一旦人脸角度偏转超过 30 度关键点定位就开始漂EAR 值会整体压缩。所以后来这套系统干脆把这张图直接送入 CNN让网络自己学“什么特征算闭眼”。卷积神经网络给出的解法是把眼睛和嘴巴的局部图像直接映射成“闭合/睁开”的概率分布不再依赖手工设计的几何特征。我拆过的这套资源在关键点定位之后接了两个轻量 CNN一个输出眼睛闭合概率一个输出嘴巴张开概率再用这两组概率去算 PERCLOS 和打哈欠频率。相比纯 EAR 方案它对环境变化的容忍度明显更高代价是计算量增加。实际工程里一般不会把整帧图送进 CNN因为你只需要判断眼睛和嘴巴裁剪后送入网络可以省下大量推理时间。下面把两种方案放在一起对比较直观对比项传统阈值法EARCNN分类方案清晰画面下的精度高计算几乎不耗时高但需要更多算力光照/遮挡鲁棒性差阈值一个环境一套好能从图像纹理学习特征实时性高中需要轻量网络配合裁剪调试成本低但每个司机都要重调阈值高需要标签数据与训练流程所以这套资源的选型思路是合理的用关键点定位锁定局部区域再用 CNN 做状态判断两边各取所长。这个组合也是目前车载疲劳检测方案里比较常见的工程落地方案。如果你在答辩时被问到“为什么不用 EAR”直接把这个对比表讲清楚比背概念有用得多。2.3 模型文件解读人脸检测模型和疲劳分类模型各承担什么解压资源后会看到models目录里面通常混着两类文件。一类是人脸检测模型负责“把脸从画面里框出来”它返回的是坐标不关心眼睛状态另一类是疲劳分类模型负责“给定眼睛和嘴巴小图输出状态概率”。这两类模型的输入输出完全不同加载方式也不一样。常见的人脸检测模型有 OpenCV DNN 的 SSD 或 MTCNN输出格式可能是坐标数组疲劳分类模型则是h5、pt或onnx格式输入是固定尺寸的图像张量。如果只把模型文件扔给load_model就完事大概率会踩坑。第一步要确认模型的输入尺寸和通道数。比如疲劳分类模型训练时用的是 48x48 单通道灰度图那推理时就不能送 RGB 三通道图如果训练时用(48, 48, 3)那加载后也要保持同样的预处理。这套资源里通常会在config.yaml里写明这些配置没有的话就得从模型文件的input_shape里反推。这里我一般会直接打印模型结构来确认而不是靠猜from tensorflow.keras.models import load_model model load_model(models/eye_state_cnn.h5, compileFalse) print(model.input_shape) # 期望看到类似 (None, 48, 48, 1) print(model.output_shape) # 期望看到 (None, 2)input_shape里的None是 batch 维度后面三个数字对应高度、宽度、通道。如果打印出来是(None, 48, 48, 3)那代码里读图时就必须用cv2.imread的原格式不能转灰度如果是(None, 48, 48, 1)就得先cv2.cvtColor(... COLOR_BGR2GRAY)再扩维。这个细节经常导致“模型加载成功但预测全错”的玄学问题因为颜色通道反了网络看到的图像和训练时完全不一样。2.4 动手验证模型文件加载权重并做一次前向推理拿到models目录里的模型别急着接摄像头先做一次前向推理能省下很多排查时间。常见做法是先用假输入测通链路再换真实图像。下面这段是我经常会用到的验证脚本from tensorflow.keras.models import load_model import numpy as np # compileFalse 是为了跳过优化器匹配只做推理 model load_model(models/eye_state_cnn.h5, compileFalse) # 构造一张 48x48 单通道假图数值全 0归一化范围 [0,1] dummy np.zeros((1, 48, 48, 1), dtypenp.float32) pred model.predict(dummy) # 输出应该是 (1, 2) 的形状且每个值都在 0~1 之间 print(pred.shape, pred.min(), pred.max())这里有几个参数要解释清楚。(1, 48, 48, 1)的第一个维度是 batch size后三个是高度、宽度、通道数。如果你的模型是训练时使用了三通道最后这个 1 要改成 3否则会直接报维度错误。compileFalse只加载权重不加载优化器适合在纯推理场景用也避开了某些环境里优化器版本不兼容导致的加载失败。如果打印出的pred.max()始终接近 0.5说明模型没有真正训练好或者预处理方向反了这时要回头检查数据集。验证完假输入再用一张真实眼睛图测一下比如把数据集里的某张closed_eye图片读进来走一遍预处理后预测看输出概率是否偏向闭合类。这一步能同时验证图像读取、缩放、归一化、维度扩展整条处理链。如果假输入正常但真实图片输出异常问题几乎都出在预处理代码和模型输入格式不一致上不要急着怀疑模型文件坏了。3. 把资源跑起来环境配置、依赖安装与首次启动训练3.1 环境要求与依赖清单毕业设计资源最让人头疼的部分往往不是代码逻辑而是环境。这套系统依赖的库不算少但版本卡得比较紧尤其是涉及深度学习框架时装错了版本再回来改成本很高。我给读者提供的建议是先建一个干净的虚拟环境再按资源里的依赖列表安装。常见的依赖清单长这样opencv-python4.5.0 numpy1.19.0 tensorflow2.4.0 dlib19.22.0 scikit-learn0.24.0 matplotlib3.3.0 pyyaml5.4.0如果你看到源码里import的是torch而不是tensorflow对应把tensorflow换成torch和torchvision其他依赖基本不变。Python 版本方面3.7 到 3.9 都行我一般用 3.8。用 Python 3.10 以上装 dlib 时经常要现场编译耗时不说还容易失败建议直接装预编译版本或者切回旧版 Python。安装命令就一行pip install -r requirements.txt但要注意虚拟环境内执行避免污染系统环境。有些资源会把模型训练时使用的库版本写在README里如果没有就从代码的 import 行反推。这里有个简单判断方法模型文件是.h5主干是 TensorFlow模型文件是.pt或.pth主干是 PyTorch如果是.onnx那训练框架无所谓加载用onnxruntime就行。这套资源既然叫“Python 卷积神经网络”大概率是 TensorFlow 或 PyTorch 二选一我在实操时会把两者都验证一遍避免出现“代码是 TensorFlow 版却装了 PyTorch”的低级错误。还有个容易忽略的点opencv-python和opencv-contrib-python不能同时装否则会互相覆盖文件导致cv2.dnn读取模型时莫名报错。如果发现自己两个都装了先pip uninstall opencv-python再重装。另外如果用的是 macOS 或 Windowsdlib 的依赖要先确认有 C 编译环境Windows 上直接下载预编译whl最省事。3.2 数据集目录结构与关键代码模块资源里除了代码最大的部分是数据集和模型文件。我拆过的类似资源目录结构一般长这样fatigue_detection/ ├── data/ │ ├── train/ │ │ ├── open_eye/ │ │ ├── closed_eye/ │ │ ├── open_mouth/ │ │ └── closed_mouth/ │ └── test/ │ ├── open_eye/ │ └── closed_eye/ ├── models/ │ ├── face_detector.onnx │ ├── eye_state_cnn.h5 │ └── mouth_state_cnn.h5 ├── src/ │ ├── dataset_loader.py │ ├── train.py │ ├── detect.py │ └── utils.py ├── config.yaml └── README.md这个结构里dataset_loader.py负责把图片文件读进来并转成训练用的张量它决定图像缩放尺寸、归一化方式、标签编码train.py负责构建网络和训练循环主要参数都在config.yaml里detect.py是推理入口打开摄像头或读视频文件后跑上一章那个主循环。utils.py通常是后处理函数比如 PERCLOS 计算、预警消息生成。dataset_loader.py里最核心的就是图像预处理函数我简化后长这样import cv2 import numpy as np def load_image(path, size(48, 48), channels1): # 读取图像 img cv2.imread(path) # 如果模型需要单通道先转灰度 if channels 1: img cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 统一缩放到模型输入尺寸 img cv2.resize(img, size) # 归一化到 [0,1] 并保证 dtype 为 float32 img img.astype(np.float32) / 255.0 # 单通道需要增加通道维度变成 (h, w, 1) if channels 1: img np.expand_dims(img, axis-1) return imgchannels1是灰度输入channels3是彩色输入必须和模型参数一致。/255.0是最常见的归一化方式有些模型用的是 ImageNet 均值方差归一化那种情况就要按模型训练时的设置来否则预测结果会整体偏移。如果你发现训练时准确率合理但推理时很差十有八九是训练代码里的预处理和推理代码不一致滚动一遍load_image就能找到问题。如果你拿到的资源没有config.yaml也不要紧参数一般会被硬编码在train.py里。优先改一个地方数据集路径。资源里常写相对路径data/train一旦你把项目整个移动位置这个路径就会失效导致训练启动后提示找不到图片。我一般会在运行前先打印当前工作目录确认data/train确实存在再用绝对路径覆盖默认值。3.3 启动训练看懂配置文件和命令行参数训练入口的参数直接决定模型能不能收敛也决定你后续调整的空间。以资源里常见的配置为例model: input_size: [48, 48] channels: 1 num_classes: 2 train: batch_size: 32 epochs: 50 learning_rate: 0.001 data_dir: data/train val_split: 0.2 detect: conf_threshold: 0.7 eye_closed_threshold: 0.5 mouth_open_threshold: 0.5 perclos_window: 10input_size和channels必须与模型定义保持一致改这里等于重建网络会牵动预训练权重。batch_size影响训练速度和显存占用显存小就调成 16 或 8。learning_rate从 0.001 起步比较稳如果 loss 一上来就震荡就降到 0.0001 再试。val_split0.2表示从训练集中拿 20% 做验证集用于观察是否过拟合。训练命令一般长这样python src/train.py --config config.yaml --gpu 0如果机器没有 GPU--gpu可以不加但训练时间会明显变长数据集几百张图的话 CPU 也能跑完就是耐心点。训练完会在models/下生成新的权重文件注意别和资源自带的原版模型覆盖掉建议先备份原文件否则调坏之后没有后悔药。训练日志里如果loss在 30 个 epoch 后仍然下降很慢可以手动调低学习率继续训不必每次都从头开始。启动摄像头实时检测的命令python src/detect.py --camera 0 --model models/eye_state_cnn.h5这里的--camera 0是设备编号笔记本自带摄像头一般是 0外接摄像头可能是 1 或 2。--model指定分类器权重路径资源里如果只有一个模型文件那大概率眼睛和嘴巴两路共用同一个网络结构只是训练数据不同。如果启动后画面黑屏先检查摄像头权限Windows 上要允许应用访问摄像头macOS 上要开终端或 IDE 的摄像头权限这些和代码无关但最容易卡住新手。4. 常见问题与避坑训练与部署中的五个典型踩坑现场训练和部署一路走来真正影响进度的往往不是模型设计而是几个看起来不起眼的细节。下面五条是我在复现这套系统时整理出的高频问题每一条都按“现象→原因→解决”来写。4.1 训练时 loss 不下降标签错了一半还硬训现象loss在 0.7 附近震荡准确率始终上不去怎么看都像模型没在学习。 原因最常见的是数据集里“闭眼”和“睁开”的标签贴反了或者两类图片采集时光照差异过大模型学到的是光线而不是眼睛状态。 解决先抽 100 张训练图人工看一遍确认文件夹与标签对应再把测试集预测结果打印成混淆矩阵如果错误集中在一个类别上基本可以判定标签或预处理有问题。这里有个小技巧对训练集做像素均值统计如果闭眼类平均像素明显比睁开类暗说明光照分布不均需要先做归一化再训练。判断标签错了不需要等整个训练跑完跑几个 epoch 后直接看验证集预测结果就行from sklearn.metrics import confusion_matrix y_true [0, 1, 1, 0, 1, 0] # 0 睁眼1 闭眼 y_pred [1, 0, 0, 1, 0, 1] # 假设预测结果全反 print(confusion_matrix(y_true, y_pred)) # 输出 [[0, 3], [3, 0]] 说明预测和真实完全反了如果混淆矩阵的对角线几乎是 0标签反了的可能性很大。解决后重新训练loss 会很快降到 0.3 以下。4.2 实时检测卡顿把整张脸图塞进了大模型现象摄像头预览只有 5 帧每秒CPU 占用拉满系统风扇狂转。 原因人脸检测在整帧上做滑窗分类模型又对每个区域做独立推理两处计算叠加后性能自然撑不住。 解决把送入人脸检测的帧缩放成 320 宽度分类模型只接收裁剪后的 48x48 小图同时做一个“每 N 帧检测一次人脸框中间帧复用上一次坐标”的优化N 取 3 到 5 比较稳。这个优化不会明显影响疲劳判定因为人脸的移动速度远低于帧率。实际优化时可以在主循环里加一个计数器和固定的检测间隔frame_count 0 detect_interval 3 # 每 3 帧检测一次人脸 while True: ret, frame cap.read() if frame_count % detect_interval 0: faces face_detector.detect(frame, conf_threshold0.7) last_faces faces # 保存本次检测结果 else: faces last_faces # 中间帧直接复用 frame_count 1detect_interval3的意思是两帧之间最多只隔 30 到 50 毫秒方向盘转动造成的位移很小复用旧框完全够用。如果想更稳一点把last_faces里的坐标再做一次指数移动平均下一章会提到。4.3 人脸框乱跳检测阈值太低且帧间没有平滑现象同一张脸在不同帧里框的大小和位置忽大忽小导致眼睛区域裁剪不稳定疲劳概率忽高忽低。 原因检测模型的输出本身存在微小的置信度和坐标抖动帧间没有做任何过滤。 解决对人脸框坐标做指数移动平均或者接一个简单的跟踪器。指数移动平均的实现很轻量alpha 0.6 smoothed_box alpha * current_box (1 - alpha) * smoothed_box这里的alpha控制平滑力度。alpha越接近 1跟踪越灵敏但抖动也越明显alpha越小画面越稳但框的准确性会滞后。0.6 是一个折中值实测效果不错。要注意的是current_box和smoothed_box都是[x, y, w, h]的数组直接用numpy数组相加即可。另外还需要防止人脸框移出画面边界当smoothed_box里的坐标落在图像边缘时要夹取到[0, 0, w, h]范围内否则裁剪时数组下标越界。如果资源里已经用了 MTCNN它内部自带五官回归框会比较稳定但如果你用的是 OpenCV DNN 的通用人脸检测器平滑处理基本是必须的。加完平滑后疲劳概率的波动会小很多误报警也会相应减少。4.4 模型文件加载失败路径和输入尺寸不匹配现象启动代码后报错找不到eye_state_cnn.h5或者加载成功但预测时提示维度不匹配。 原因资源里的路径是相对源码目录的解压后项目整体移动位置路径自然就断了另一种情况是模型训练时的输入尺寸和推理代码里的占位符尺寸不一致。 解决在加载模型前用绝对路径拼接的方式固定位置import os BASE_DIR os.path.dirname(os.path.dirname(__file__)) model_path os.path.join(BASE_DIR, models, eye_state_cnn.h5) model load_model(model_path, compileFalse)同时打印model.input_shape把它和上一章dummy的维度对齐。这个步骤能排除 90% 的加载问题。很多时候报错信息里已经写清了维度比如expected ndim4, found ndim3意思就是缺了一个 batch 维用np.expand_dims(img, axis0)补上即可。如果你遇到的是中文路径导致的加载失败不要把项目放在带空格的目录下某些底层库对中文路径支持不好报错会非常隐晦。我一般习惯把项目放在C:\fatigue或~/fatigue这种纯英文路径下省掉这类奇葩问题。4.5 疲劳判定误报高阈值没按实际摄像头角度调现象司机明明睁着眼系统却频繁报警或者真正打哈欠时又不报警。 原因疲劳判定里的eye_closed_threshold和mouth_open_threshold是拿公开数据集标定的摄像头安装高度、俯仰角不同闭眼概率的整体分布会偏移公开集上的阈值并不普适。 解决用正常驾驶和模拟疲劳的两段视频各跑 10 分钟分别统计眼睛闭合概率的均值和分位数把阈值设在两类分布的中间。常见做法是把每个时刻的概率和 PERCLOS 窗口打印成日志观察正常状态下的最大值再按这个值上浮 10%-20% 作为报警线。这一步做完误报率能明显下降。下面这段代码可以用来统计正常视频里的闭合概率分布import numpy as np # 假设已经保存了每一帧的 eye_closed_prob probs np.load(normal_eye_probs.npy) # 正常状态下一般不会超过 0.4 print(mean:, probs.mean(), p95:, np.percentile(probs, 95))如果p95是 0.4那阈值可以设在 0.5 到 0.55 之间留出足够的余量。如果正常状态下p95就已经接近 0.6说明你的数据集里闭眼样本和睁眼样本不够分需要重新收集当前摄像头角度下的图片再微调模型。5. 把模型调到能用的最后一步算指标、调阈值并封装成预警工具5.1 用测试集算准确率、召回率和误报率疲劳检测的评估不能只看准确率。在实车场景里漏报比误报危险得多因为漏报意味着司机真的打盹了系统却没提醒。所以模型调优时我习惯先看召回率和误报率。用测试集做一次完整预测然后打印分类报告from sklearn.metrics import classification_report, confusion_matrix import numpy as np y_true np.load(test_labels.npy) # 真实标签 y_pred np.load(pred_labels.npy) # 模型预测标签 print(classification_report(y_true, y_pred, target_names[清醒, 疲劳])) print(confusion_matrix(y_true, y_pred))classification_report会给出每类的精确率、召回率和 F1confusion_matrix则直接显示有多少样本被混在错误类别里。如果“疲劳”类的召回率低于 90%说明报警阈值太保守应该调低eye_closed_threshold让模型更容易触发报警。5.2 用真实摄像头做一次阈值自校准这个步骤只需要几分钟但能免掉很多现场返工。上车或坐在工位前先把摄像头放到实际要用的角度驾驶员正常睁眼看路记录 30 秒内眼睛闭合概率的平均值再做几次故意闭眼和打哈欠动作记录概率峰值。正常值和闭眼值往往有明显分层取两者中点作为阈值。实际调的时候把配置里的eye_closed_threshold改成这个值再跑一遍测试视频观察报警次数。资源里的detect.py支持通过命令行覆盖配置所以不需要改代码python src/detect.py --camera 0 --eye-threshold 0.62 --mouth-threshold 0.55参数名可能因资源版本不同略有差异打开argparse部分看一眼就行。如果命令行不支持直接在config.yaml里改也可以改完重启进程就能生效。5.3 封装成桌面预警工具如果只是交毕业设计控制台输出足够但如果想让这套系统真正给车队或实验室用建议把它包一个简单的图形界面。常见做法是用tkinter或PyQt做一个“开始检测/停止检测”按钮摄像头循环放在独立线程里主线程负责刷新预览画面和报警提示。需要注意的是cv2.imshow和 UI 框架的循环不能同时写在一个线程里否则会出现窗口无响应的问题。资源里自带的资料如果只是纯脚本你可以把第 3 章的主循环拆成一个detect_worker函数摄像头读取、模型推理都放在里面通过队列把最新一帧传给 UI 线程界面就能实时显示疲劳状态。这个封装工作量不大但会让整个系统的完成度高一个档次。如果你正在做毕业设计完整源码、模型文件和调试笔记都在配套资源包里下载后按第 3 章的顺序跑会比从头摸索省很多时间。从那以后我每次拿到新的疲劳检测模型都会先跑一遍测试集算清楚误报率再规规矩矩对摄像头角度做一次自校准确认阈值可用才收工。这套流程帮我避开了很多“实验室能用、现场就翻车”的尴尬希望帮到你。本文还有配套的精品资源点击获取
