简介面向高校计算机与人工智能专业学生的毕业设计及期末大作业需求这套基于深度学习的学生面部表情疲劳检测在线课堂系统源码利用计算机视觉技术分析眼睛开合状态与面部表情特征实现课堂场景下的疲劳状态识别。压缩包共2000个文件以JPG人脸图像数据集为主包含6个Python脚本、2个CSV数据表、PNG示意图与Markdown说明文档整体约47.44MB。目录覆盖datasets数据集、dataloader数据加载器、models模型定义、train.py训练脚本、result结果输出与README文档构成从数据到评估的完整工程结构。已有179人学习下载适合具备Python基础并希望系统掌握PyTorch与计算机视觉应用流程的读者。项目各模块分工明确可对照学习数据预处理、模型训练与验证评估的具体写法理解CNN等模型在疲劳特征识别中的实际应用同时为课程设计或论文实验提供可直接运行的参考源码。1. 在线课堂的“低头族”为什么疲劳检测必须从学生面部表情入手在线课堂里老师面对几十路摄像头画面能看到的只是一排静止或偶尔晃动的头像学生是真在听讲、还是已经闭眼睡了三分钟单靠肉眼根本盯不过来。基于学生面部表情的疲劳检测就是把这块盲区补上深度学习模型实时分析摄像头帧先定位人脸和关键点再计算眨眼频率、闭眼时长和打哈欠次数最后结合表情分类输出一个可解释的疲劳状态。这套系统解决的是在线教学场景最普遍的痛点——课堂参与度不可见也天然适合当毕业设计或期末大作业因为链路完整采集、检测、判定、告警、报表全都有算法不必做得多深每一步又都有明确的优化空间和可讲的故事。2. 疲劳不是玄学眨眼、PERCLOS 和打哈欠背后的计算逻辑2.1 能从面部表情里挖出的三个疲劳信号疲劳状态在生理上会表现为几个可测量的行为特征其中最适合摄像头捕捉的是这三条眨眼频率下降、单次闭眼时间变长、打哈欠次数增多。情绪上则表现为表情呆滞、缺乏变化对应表情分类模型输出长期偏向“中性”或“厌恶”很少出现“开心”“惊讶”这类高唤醒表情。这三类信号不是并列关系可靠程度差别很大判定权重也不能给一样。眨眼和闭眼是最可靠的硬指标。正常成人每分钟眨眼 15 到 20 次单次闭眼时间 0.1 到 0.2 秒疲劳时眨眼会变稀疏或者反过来变成频繁的“慢眨眼”单次闭眼超过 0.5 秒这就是非常典型的犯困信号。打哈欠虽然常见于疲劳状态但每个人正常状态下也会打单独用来判疲劳误报很高只能做辅助特征。表情分类则更主观同一个学生专注时的“中性脸”和走神时的“中性脸”几乎没有区别所以表情只能当旁证不能当主判据否则答辩时随便一个面无表情的评委都能让你的系统当场翻车。所谓“可测量”落到工程上就是一组数字眼睛纵横比EAR、嘴巴纵横比MAR、单次闭眼秒数、每分钟眨眼次数、每分钟哈欠次数。这些数字实时产出定时累计最后合成一个疲劳评分。比起让模型直接输出“疲劳/不疲劳”的二分类这种基于中间特征的做法稳定得多而且每一帧得到什么、为什么得到这个结果都能在日志里翻出来这对毕业设计答辩特别重要——评委一定会问“这个阈值怎么来的”。2.2 PERCLOS 阈值与滑动窗口什么才算“疲劳闭眼”PERCLOSPercentage of Eyelid Closure是疲劳检测领域沿用最久的指标定义是一段时间内眼睛闭合程度达到 80% 以上的时间占比。工程上算它有两种口径按帧累计和按事件累计。按帧累计最简单——统计这一分钟里 EAR 低于阈值的帧数占总帧数的比例按事件累计则是把每次“睁眼→闭眼→睁眼”记作一次闭眼事件记录持续帧数再除以帧率换算成秒。这两种口径描述的是同一个现象但实现起来差别很大我建议只用按帧累计因为事件累计依赖眨眼状态机的参数状态机一旦调偏PERCLOS 跟着错。阈值怎么设直接决定系统是“睁眼说瞎话”还是“动不动误报”。我常用的一组经验值给在下面。注意这组值的适用前提是 640x480 分辨率、室内均匀光、学生正脸朝摄像头斜脸、逆光、戴深色镜框时全部要重新标定。指标判定方式疲劳阈值经验值PERCLOS-P80闭眼帧数 / 总帧数单分钟 0.4 判疲劳单次闭眼时长闭眼连续帧数 / 帧率连续 0.5 秒记一次瞌睡事件眨眼频率总眨眼次数 / 分钟低于 7 次或高于 35 次提示异常哈欠频率总哈欠次数 / 分钟连续 3 分钟内 2 次提示这里 P80 计算用的 EAR 阈值我一般取 0.2 到 0.25。睁眼时 EAR 通常在 0.3 以上完全闭眼时接近 0.05中间这一段在 0.1 到 0.2 之间的就是“眯眼”眯眼能不能被正确归类是后面避坑章的硬骨头。另外 PERCLOS 不要用单帧判决至少累计 30 到 60 秒窗口才有统计意义。窗口短于 30 秒学生低头看手机的两秒就会被误判成闭眼睡觉窗口长于 60 秒告警延迟到让人怀疑系统没在工作。我一般固定 60 秒滑动窗口每帧更新不做重叠清零。2.3 检测链路的分工为什么关键点方法比端到端网络更适合课堂明确了信号和阈值整条链路就能固定下来摄像头采集 → 抽帧压缩 → 人脸检测 → 人脸关键点提取 → 计算 EAR/MAR → 状态机判决眨眼/哈欠 → 滑动窗口累计 PERCLOS → 融合表情评分 → 写入告警队列。链路每一环都是独立模块这是我的习惯不要把“人脸检测”和“疲劳判定”写死在同一个函数里否则后面调阈值、换模型时你会改到怀疑人生。选型上有个常见的分歧既然标题写的是“深度学习”为什么不用一个端到端卷积网络直接输出疲劳概率非要绕一圈做关键点加阈值我的回答是课堂场景下关键点方法明显更稳。第一可解释性——端到端网络输出一个 0.87 的数字你没法说清它是看眼睛还是看嘴巴得出的关键点方法则能明确指出是闭眼超时还是哈欠频繁。第二样本效率——端到端疲劳模型需要大量带“疲劳”标注的课堂视频这种数据极难凑而 FER2013、YawDD 这类公开数据集正好能喂给关键点加分类的组合方案。第三调参自由——课堂上你大概率要根据教室光线、摄像头角度调灵敏度关键点方法改成一行阈值端到端就得重训。人脸检测和关键点提取是链路里最吃算力也最影响准确率的一环。可选方案有三个MTCNN 加 Dlib 68 点、OpenCV DNN 加 MediaPipe、纯 MediaPipe FaceMesh。三者里 MediaPipe 集成度最高一次调用同时输出人脸框、468 个三维关键点和头部姿态做课设性价比最高。Dlib 的 68 点方案论文里最常见、引用好讲故事但关键点模型在低分辨率小脸上明显弱于 MediaPipe。OpenCV DNN 适合完全离线部署关键点还得外接模型多一层麻烦。我一般主力用 MediaPipeDlib 只做对比实验写进论文。3. 在线课堂系统架构从摄像头帧到教师端告警的完整数据流3.1 拿到 zip 后先看目录源码包里的模块职责与运行前提拿到这类网上流传的源码包第一步永远是解压后先看目录结构而不是双击运行。很多版本的代码长得差不多核心模块就这几块算法检测模块、后端接口模块、前端展示模块、训练与数据处理模块。我见过最常见的组织方式大概是这样如果你手里的包结构不同按功能找对应文件就行。online_class_fatigue/ ├── app/ │ ├── main.py # Flask 入口注册路由与启动服务 │ ├── detector/ │ │ ├── face_engine.py # 人脸检测 关键点封装 │ │ ├── fatigue.py # EAR / PERCLOS / 眨眼状态机 │ │ ├── emotion.py # 表情分类模型加载与推理 │ │ └── pipeline.py # 单帧综合分析输出完整结果 │ ├── templates/ # 教师端 HTML 页面 │ └── static/ # JS、图表库、样式 ├── models/ # 训练好的 .pt / .onnx 权重文件 ├── dataset/ # FER2013、YawDD 等原始数据 ├── train/ # 表情分类训练脚本 ├── scripts/ # 视频流转发、数据转换等工具 ├── requirements.txt └── README.md这个结构对应“前后端分离但同一进程部署”的单机方案也是在线课堂类课设最常见的形态。核心全在 detector 的四个文件里face_engine 管“人脸在哪、关键点在哪”fatigue 管“疲劳特征怎么算”emotion 管“表情分类给旁证”pipeline 负责把前三个的输出合并成一个可接口化的结果字典。main.py 只做 HTTP 接口适配不写算法逻辑你拿到手先通读 pipeline.py基本就能理解作者的设计思路。有一点要特别提醒很多包的 requirements.txt 是作者当时环境的快照版本互相没验证过尤其是 opencv-python、numpy、protobuf 这三个新老版本 API 差异大报错时根本定位不到是哪个版本引入的。另外 models 目录里经常是空的README 写“运行 train 脚本生成权重”但训练脚本又依赖你没下载的数据集。拿到包别急着装全量依赖先建干净环境Python 用 3.9 或 3.10 最稳再按需求逐个安装每装一个就 import 测试一次确认 torch、opencv、mediapipe 都能加载再往下走。3.2 帧管道与接口设计抽帧、压缩、提交与断流恢复在线课堂系统的数据流本质是一条“帧管道”。学生端摄像头以 25 到 30 帧每秒的原始帧率在跑但这帧率对后台检测毫无意义——单人单帧做完整推理CPU 上通常只有 10 到 15 fps 的余量30 fps 进来必然排队积压。所以工程上第一件事就是前端抽帧我一般抽到每 300 毫秒一帧也就是约 3 fps。对眨眼检测来说 3 fps 其实偏保守一次眨眼 0.1 到 0.2 秒3 fps 只够抓到两三帧闭眼事件要求连续 2 帧以上才算刚好卡在边界。稳妥一点抽到 5 fps也就是每 200 毫秒一帧眨眼和哈欠都能覆盖。帧从浏览器到后端常见两种方式一种是前端把 JPEG 帧 base64 编码后 POST 给后端后端解码再送算法模块另一种是 WebSocket 长连接帧随到随推。前者实现简单适合当毕业设计问题在于多路并发时 HTTP 连接建立开销会拉高延迟后者更接近真实产品形态。但无论哪种前端都必须先把帧压缩到 320x240JPEG 质量压到 70 到 80否则一路 1080p 的 base64 字符串动辄几百 KB局域网里都能感受到延迟。网络断流是在线课堂比本地检测多出来的麻烦。学生端 Wi-Fi 抖动、切后台、电脑休眠都可能让帧管道断裂。我在后端约定一个规则超过 5 秒没有收到某学生的帧就把他标记为“离线”记录离开时间而不是把旧数据继续累计。等新帧到达时重置窗口避免断流前后段时间拼出一个错误的 PERCLOS。前端则做指数退避重连不要每 100 毫秒重试一次把后端打崩。后端算法模块处理完单帧输出结构化字典人脸框坐标、左右眼 EAR、嘴巴 MAR、当前状态正常/闭眼/哈欠、累计眨眼次数、最近 60 秒 PERCLOS。这个字典有两个去向作为 API 响应返回教师端页面每 5 秒刷新一次学生状态同时写入数据库作为生成课堂报告的数据源。接口设计上只暴露一个 POST /api/fatigue请求体是学生 ID 加压缩帧返回值是上面那个字典前端和算法模块就不互相绑架了。3.3 告警判定与 SQLite 存储什么时候该触发一次真正告警告警不能直接在算法模块里做必须有一层独立判定逻辑。原因是算法模块每秒产生 3 到 5 条记录如果每条都实时推送教师端会被“疑似闭眼”“疑似哈欠”刷屏等真出问题时反而没人看。我的做法是后端维护一个 60 秒滑动窗口窗口内 PERCLOS 超过 0.4、闭眼事件不少于两次才触发一次告警同一学生三分钟内不重复。这样既不刷屏又保证有事件可查。# 告警判定独立于算法模块只做策略判断 def check_alarm(student_id, window_data): perclos compute_perclos(window_data) # 来自 fatigue 模块 close_events count_close_events(window_data) if perclos 0.4 and close_events 2: return { student_id: student_id, level: warning, reason: fPERCLOS{perclos:.2f}, 闭眼事件{close_events}次 } return None这段代码的要点是把 compute_perclos 和 count_close_events 留在 fatigue 模块check_alarm 只做阈值比较不碰像素。这样调整告警策略只改一个函数不用把整个检测流程翻出来重读。实际项目里 check_alarm 还要接一个 last_alarm_time 字典做三分钟去重防止同一个学生连续触发。存储方面这类项目几乎全是 SQLite——数据量小、零配置、好迁移几个文件拷走就能演示。表结构不要设计得太复杂三张表足够学生表存 ID 和姓名检测记录表每 5 秒存一条汇总告警表存触发时间、原因和处理状态。写入频率控制在每 5 秒一条而不是每帧一条数据库一年也长不到几百 MB。如果你拿到的源码包用的是 MySQL也没问题但本地跑起来多一步服务配置做课设没必要增加这个负担。4. 用 PyTorch 落地人脸表情疲劳检测的最小可运行代码4.1 人脸关键点MediaPipe FaceMesh 的最小调用与参数选择先把最基础的“拿到人脸关键点”跑通。FaceMesh 输出一组归一化坐标范围 0 到 1使用时乘上帧宽高就是像素坐标。默认输出 468 个点开 refine_landmarks 后是 478 个多了 10 个虹膜点。做眨眼检测用默认 468 点就够了开虹膜会让索引表变复杂徒增踩坑概率。import cv2 import mediapipe as mp mp_face_mesh mp.solutions.face_mesh face_mesh mp_face_mesh.FaceMesh( max_num_faces1, # 课堂场景单人脸性能更好 refine_landmarksFalse, # 保持 468 点默认索引 min_detection_confidence0.5, min_tracking_confidence0.5 ) def get_landmarks(frame): rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w frame.shape[:2] results face_mesh.process(rgb) if not results.multi_face_landmarks: return None pts results.multi_face_landmarks[0].landmark return [(p.x * w, p.y * h) for p in pts] cap cv2.VideoCapture(0) while True: ret, frame cap.read() if not ret: break pts get_landmarks(frame) if pts is not None: # 画一条左眼外眼角到内眼角的线验证关键点是否准 cv2.line(frame, tuple(map(int, pts[33])), tuple(map(int, pts[133])), (0, 255, 0), 2) cv2.imshow(face, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这段代码里两个置信度参数值得解释。min_detection_confidence 控制人脸检测置信度调到 0.3 能提升检出率但侧脸和模糊脸也会混进来min_tracking_confidence 控制关键点跟踪置信度调低时快速转头不掉点但点会漂。一般保持默认教室光线差就降到 0.4。pts 是按 FaceMesh 官方索引排列的眼睛、嘴巴、眉毛都有固定编号区间使用前一定要写个画点脚本把每个索引打印到脸上核对不能想当然。4.2 疲劳特征计算EAR 与 MAR 的公式实现拿到关键点后疲劳特征就是纯粹的坐标运算。眼睛纵横比 EAR 的定义是眼睛垂直方向两个距离的平均值除以水平方向距离睁眼时比值大、闭眼时比值小。嘴巴纵横比 MAR 同理用内唇的嘴唇间距除以嘴宽。这两个公式都不依赖人脸大小因为做了归一化。import math LEFT_EYE [33, 160, 158, 133, 153, 144] # 左眼 6 个关键点 RIGHT_EYE [362, 385, 387, 263, 373, 380] # 右眼 6 个关键点 MOUTH_INNER [61, 39, 91, 81, 17, 84] # 内唇 6 点版本不同索引有出入 def euclidean(p1, p2): return math.hypot(p1[0] - p2[0], p1[1] - p2[1]) def eye_aspect_ratio(pts, eye_idx): # 垂直方向取两对点水平方向取一对点 v1 euclidean(pts[eye_idx[1]], pts[eye_idx[5]]) v2 euclidean(pts[eye_idx[2]], pts[eye_idx[4]]) h euclidean(pts[eye_idx[0]], pts[eye_idx[3]]) return (v1 v2) / (2.0 * h) def mouth_aspect_ratio(pts): # 闭嘴时 MAR 接近 0.1张嘴超过 0.5 视为张嘴边 v euclidean(pts[MOUTH_INNER[1]], pts[MOUTH_INNER[5]]) h euclidean(pts[MOUTH_INNER[0]], pts[MOUTH_INNER[3]]) return v / h # 单帧示例两只眼睛的 EAR 取均值 ear (eye_aspect_ratio(pts, LEFT_EYE) eye_aspect_ratio(pts, RIGHT_EYE)) / 2.0 mar mouth_aspect_ratio(pts)EAR 的数值范围不固定它跟人脸大小无关但受关键点精度影响很大侧脸时关键点压缩、EAR 整体变小戴眼镜框时垂直距离被抬高、EAR 变大。所以绝对阈值只能做参考真正部署要按人头校准这个放到避坑章节细说。MAR 判断哈欠也不能只看单帧说话时 MAR 也会周期性超过 0.5必须叠加“张嘴持续超过 1 秒”的条件才能把哈欠和说话区分开。4.3 眨眼事件状态机把阈值抖动过滤成可靠事件有了 EAR 之后最关键的是把一帧一帧的数值变成“事件”。初级做法是 EAR 小于阈值就记一次闭眼结果学生眨一下眼就被记录为疲劳闭眼——因为眨眼过程本来就有几帧低于阈值。正确做法是用状态机只有从睁眼进入闭眼、闭眼持续超过 N 帧才算一次有效闭眼事件闭眼结束后再睁开超过 N 帧才确认退出。EAR_THRESH 0.22 # EAR 低于此值视为闭眼 CLOSED_FRAMES_NEEDED 2 # 连续 2 帧闭眼才进入 CLOSED 态 OPEN_FRAMES_NEEDED 2 # 连续 2 帧睁眼才退出 CLOSED 态 state OPEN # OPEN / CLOSING / CLOSED closed_frames 0 open_frames 0 blink_count 0 def update_eye_state(ear): global state, closed_frames, open_frames, blink_count if ear EAR_THRESH: if state OPEN: state CLOSING closed_frames 1 elif state CLOSING: closed_frames 1 if closed_frames CLOSED_FRAMES_NEEDED: state CLOSED elif state CLOSED: closed_frames 1 open_frames 0 else: if state CLOSED: open_frames 1 if open_frames OPEN_FRAMES_NEEDED: blink_count 1 state OPEN closed_frames 0 elif state CLOSING: closed_frames 0 state OPEN return blink_count这段代码里 CLOSED_FRAMES_NEEDED 取 2 的前提是帧率 5 fps对应闭眼至少 0.4 秒能过滤掉正常眨眼。如果帧率降到 3 fps这个数就得妥协取 1 太敏感、取 2 漏报太多所以我建议帧率低于 4 fps 时直接改用“闭眼帧数累计”而不是事件判定。实际工程里这些全局变量要封装成 EyeState 类每个学生一个实例避免多路视频时状态互相串。4.4 表情分类兜底训练 TinyEmotionNet 的完整流程疲劳特征之外表情分类给整个系统一个“状态佐证”。我的做法是不用 ResNet 这种大网络FER2013 这种数据集用小网络反而训得更快、泛化也不差。TinyEmotionNet 三个卷积块加一个全连接参数量不到两百万单帧推理 CPU 上大约 3 毫秒对在线课堂绰绰有余。import torch import torch.nn as nn from torch.utils.data import Dataset, DataLoader import numpy as np import pandas as pd class TinyEmotionNet(nn.Module): def __init__(self, num_classes7): super().__init__() self.features nn.Sequential( nn.Conv2d(1, 32, 3, padding1), nn.BatchNorm2d(32), nn.ReLU(), nn.MaxPool2d(2), # 48x48 - 24x24 nn.Conv2d(32, 64, 3, padding1), nn.BatchNorm2d(64), nn.ReLU(), nn.MaxPool2d(2), # 24x24 - 12x12 nn.Conv2d(64, 128, 3, padding1), nn.BatchNorm2d(128), nn.ReLU(), nn.AdaptiveAvgPool2d(1), ) self.classifier nn.Linear(128, num_classes) def forward(self, x): x self.features(x) return self.classifier(x.view(x.size(0), -1)) # FER2013 是 CSV 格式pixels 列是 48x48 灰度像素的字符串 df pd.read_csv(fer2013.csv) def parse(row): arr np.array(row[pixels].split(), dtypenp.uint8).reshape(48, 48) return arr.astype(np.float32) / 255.0, row[emotion] class FerDataset(Dataset): def __init__(self, df): self.items [parse(r) for _, r in df.iterrows()] def __len__(self): return len(self.items) def __getitem__(self, i): img, label self.items[i] return torch.from_numpy(img).unsqueeze(0), torch.tensor(label, dtypetorch.long) train_ds FerDataset(df[df[Usage] Training]) loader DataLoader(train_ds, batch_size64, shuffleTrue, num_workers0) model TinyEmotionNet(7) optimizer torch.optim.Adam(model.parameters(), lr1e-3) criterion nn.CrossEntropyLoss() for epoch in range(20): total_loss 0.0 for x, y in loader: optimizer.zero_grad() loss criterion(model(x), y) loss.backward() optimizer.step() total_loss loss.item() * x.size(0) print(fepoch {epoch1}, loss {total_loss / len(train_ds):.4f})这里有两个容易卡住的点。一是 DataLoader 的 num_workers 在 Windows 上必须设成 0否则多进程加载会反复崩溃二是 FER2013 是单通道灰度图所以第一个卷积层输入是 1 通道用 OpenCV 读彩色摄像头帧时记得先转灰度再 Resize 到 48x48 才能喂给这个模型。20 个 epoch 在 CPU 上约一小时七分类准确率能到 65% 左右足够演示。想再体面一点就用 RAF-DB 微调或加随机裁剪、旋转做数据增强这部分可以写进论文的“改进点”。4.5 综合判定与接口输出把多维特征合并成一个疲劳分疲劳特征算出后最后一步是把各维度合并。我给的权重是PERCLOS 占 0.5闭眼事件频率占 0.3表情呆滞占 0.1哈欠占 0.1。这个权重是拍脑袋定的你可以根据自己采集的数据调只要在文档里说清调整过程和效果就好。表情这部分要说明FER2013 分类模型输出的“中性”占比过高本身就是一个信号长时间不出现“开心”“惊讶”类高唤醒表情参与度就要扣分。from flask import Flask, request, jsonify import base64 import numpy as np app Flask(__name__) def compute_fatigue_score(perclos, blink_rate, yawn_count, emotion_label): score 0.0 score 0.5 * min(perclos / 0.4, 1.0) # 归一化到 0~1 score 0.3 * min(blink_rate / 40.0, 1.0) # 眨眼频率异常 if yawn_count 2: score 0.1 if emotion_label in (neutral, sad): score 0.1 * 0.5 return round(score, 2) app.route(/api/fatigue, methods[POST]) def fatigue_api(): data request.get_json() img_bytes base64.b64decode(data[image]) frame cv2.imdecode(np.frombuffer(img_bytes, np.uint8), cv2.IMREAD_COLOR) result pipeline(frame) # detector/pipeline.py 输出的结果字典 result[fatigue_score] compute_fatigue_score( result[perclos], result[blink_rate], result[yawn_count], result[emotion_label] ) return jsonify(result)这段代码把算法和接口分离了pipeline 做纯视觉计算compute_fatigue_score 做纯策略计算。接口层不关心关键点在哪个索引只负责解码请求、调算法、回结果。注意 imdecode 返回的是 BGR 图pipeline 内部如果按 RGB 处理要先翻转通道这是 OpenCV 和 MediaPipe 之间最常见的错位点。5. 避坑在线课堂疲劳检测项目的 5 个高频翻车点5.1 依赖装不上版本冲突先于代码问题出现现象按 README 执行 pip install -r requirements.txt报一堆版本冲突numpy 和 opencv 对不上MediaPipe 装不上protobuf 报错。原因这类源码包的依赖列表经常是作者当时环境的快照各版本之间没有互相验证。尤其 opencv-python、numpy、protobuf 这三个新老版本 API 差异大报错时根本定位不到是哪个包引入的。解决不要一次性装全量依赖。先建干净虚拟环境Python 用 3.9 或 3.10再逐个安装。MediaPipe 装不上基本是 Python 版本太高降版本就好。装完先跑 import 测试确认 opencv、torch、mediapipe 可加载再继续。这个步骤看着浪费时间实际能省下后续两小时的玄学排错。5.2 逆光与眼镜导致关键点漂移现象白天窗边逆光时检测框在人脸边缘反复跳动EAR 忽高忽低眨眼统计完全失真戴眼镜的学生压测时闭眼检测基本失效。原因MediaPipe 关键点回归模型是在正脸、均匀光照数据上训练的逆光让脸部对比度过低特征点滑到脸颊轮廓上眼镜框则把眼睛区域的梯度弄乱关键点被框边吸走。解决预处理加 CLAHE 自适应直方图均衡化把灰度对比度拉平再送模型。这个操作在光线差的教室实测能把关键点漂移减少一半以上。眼镜问题没有可靠解法深色镜框和反光镜片是硬伤只能降低期望并在文档里写明“建议学生调整摄像头角度或摘掉深色镜框”。别指望换模型能根治这是数据分布问题不是网络结构问题。5.3 正常眨眼被当闭眼睡着反而漏报现象学生正常眨一下眼日志里就记一次闭眼事件真趴在桌上闭眼两秒却只记了一次因为闭眼状态尚未达到判定时长就被打断了。原因两个阈值互相影响。EAR_THRESH 设得太高正常眨眼中间帧的 EAR 掉进闭眼区间CLOSED_FRAMES_NEEDED 设得太短眨眼的两帧刚好凑够。这俩是联动的只调一个没用。解决按人头校准是正路。每个学生首次进入课堂时采集 100 帧正常睁眼状态算 EAR 均值个人阈值设为这个均值的 0.75。这样近视眼同学天生眼睛小也不会被系统当成一直闭眼。闭眼事件结束的判定条件要比进入条件更严格——进入闭眼要连续 2 帧低于阈值退出则要连续 3 帧高于阈值能抑制眯眼状态反复横跳。5.4 摄像头里没人脸等于静默漏检现象学生低头找东西或中途离开座位前端还在传帧后端检测不到人脸系统就当无事发生一段疲劳状态被静默跳过。原因人脸检测返回空列表时pipeline 直接返回 None丢失了“无脸状态”这个信息。在在线课堂里长时间无脸本身就是一种参与度异常丢掉它等于少了一路信号。解决给 pipeline 加一个 lost_frame_count 计数器。检测不到人脸时间隔小于 3 秒的视为低头动作忽略超过 3 秒记录一次离席事件降低参与度评分。离席事件对教师端的价值不亚于疲劳告警而且不少源码包没做加上就是你的增量亮点答辩时能多讲一个设计决策。5.5 多路视频卡顿CPU 推理排队导致结果滞后现象演示时开 4 个学生窗口后端 CPU 被打满帧排起长队前端看到的检测结果滞后十几秒学生早就抬头了系统还在告警。原因每帧人脸检测、关键点提取、表情分类串行执行单人单帧 CPU 上要 60 到 100 毫秒4 路 5 fps 就是每秒 20 帧单线程扛不住。解决两个方向。先把推理做轻——表情分类模型转 ONNX Runtime 推理通常比 PyTorch Eager 快一倍人脸检测和关键点保持 MediaPipe 不动。再把抽帧降到 2 fps 并给每帧打时间戳迟到帧直接丢不排队累积。演示时不要开满 8 路开 3 到 4 路留出性能余量解释时说明“实际部署通过 GPU 或进程池扩展”即可评委不会为难这个。6. 演示答辩技巧用 FFmpeg 模拟多路课堂视频流多路摄像头不是每个人都有条件现场搭的答辩时也不可能拉来八个同学坐一排当演员。我的常用做法是用 FFmpeg 把录好的课堂视频循环推流让系统以为有多个学生在线。测试脚本极简单一个视频对应一路流循环播放检测模块完全无感。ffmpeg -re -stream_loop -1 -i student_a.mp4 -f rtsp -rtsp_transport tcp rtsp://127.0.0.1:8554/a-re 表示按视频原始帧率读取-stream_loop -1 无限循环推流后再写一个 5 fps 抽帧的采集器接住即可。这个方式最大的好处是可控——提前录一段“坐直听课 40 秒、趴桌闭眼 10 秒、打哈欠 2 次”的标准素材答辩时每次跑的检测结果都一致数据可复现别人问起来也能讲清楚测试条件。演示时我会同时开三个窗口左侧是学生视频流原始画面中间是检测框加 EAR/MAR 实时数值右侧把 PERCLOS 和眨眼累计次数画成滚动折线。评委一眼就能看出系统真的在读帧而不是放录像。折线峰值对应闭眼时段告警日志同步出现“学生 A 疲劳告警PERCLOS 0.52”这就是完整的证据链。最后说一个我的习惯先把“闭眼 3 秒必告警”的最小闭环做到能反复演示再去补报表、历史查询这些外围功能。否则答辩前夜还在调 EAR 阈值那种翻车我经历过不止一次。做这类系统闭环演示比算法指标更能说明工程能力也更容易让评委跟着你的节奏走。希望帮到你。本文还有配套的精品资源点击获取