做毕设那会儿最深的体会不是“深度学习有多难”而是整套系统真正能跑起来、能在实时画面里稳定检测出疲劳状态比想象中需要更多细节。疲劳检测、驾驶行为检测这类项目看着就是“摄像头加算法”实际上从人脸检测、关键点提取、PERCLOS指标计算到行为分类和告警联动每一环都有坑。这篇把我从选型到落地、从训练到打包的完整经验整理出来给正在做相关课题的同学和想上手计算机视觉实战的开发者一份可直接照做的参考方案。整个项目最终的形态是一个运行在普通笔记本上的实时检测系统调用摄像头对视频流逐帧做人脸检测和人脸关键点定位计算眼睛纵横比、嘴巴纵横比、头部姿态角度并根据这些指标综合判定疲劳状态和驾驶行为闭眼、打哈欠、低头、打电话、抽烟等。判定结果实时显示在画面左上角命中疲劳标准时触发声音告警并保存截图。基于这套框架换数据集、加行为类别、替换更轻量的模型都不需要动主干逻辑适合作为毕业设计也可以作为智能座舱相关产品的一个算法原型。1. 项目整体拆解与方案选型1.1 一个完整的疲劳检测系统由哪些环节组成很多人拿到这类课题第一反应是“找个模型训练一下”这是最容易走偏的地方。实际工程项目里模型只是中间一环。拆开来看整套系统由五个环节构成视频输入与抽帧、人脸检测与跟踪、关键点定位与指标计算、疲劳判定与行为分类、结果输出与告警。毕业设计答辩时老师问得最多的不是“你用了什么网络”而是“整个系统怎么组织、各个模块怎么协作的”。输入输出环节涉及摄像头调用、帧率控制和画面叠加人脸检测环节负责从整帧中定位人脸区域这里要重点解决漏检和误检的平衡关键点定位环节输出人眼、嘴巴、头部姿态相关的坐标信息指标计算环节把坐标转成有物理意义的数值比如EAR、MAR、欧拉角最后的判定环节则要回答“积累多少帧闭眼算疲劳”“连续多少次低头算分神”。如果把这些环节想清楚了项目就已经成功了一大半。我见过不少同学把全部精力放在调模型精度上最后系统放到真实摄像头前帧率不足10FPS或者误报率高到没法用这个其实不是模型的问题而是系统没有分层设计。每一层只做一件事层与层之间用数据接口衔接这样无论替换模型还是调整策略改动范围都能被限制住。1.2 方案选型为什么放弃“纯传统图像处理”路线技术方案我前后对比过三种纯OpenCV传统图像处理、传统算法与深度学习混合、全深度学习方案。第一种完全基于肤色分割和模板匹配做人眼定位优点是部署轻、速度快但光照一变、人脸角度一偏关键点就飘得厉害第二种用深度学习模型做人脸检测和关键点提取用传统几何方法算疲劳指标这是目前工业界最常见的方案稳定性和开发成本平衡得很好第三种端到端直接用分类网络判断“疲劳/正常”思路简单但需要大量标注数据而且很难解释“为什么判定疲劳”毕设答辩时容易被追问到死角。我最终选了第二种路线原因有三点一是检测精度有保障人脸关键点模型在公开数据集上的误差通常只有几个像素二是中间指标可解释性强EAR曲线、头部姿态角度这些数值能直观展示疲劳程度的变化过程论文里也能画出漂亮的曲线图三是扩展性更好往后加一个“打电话检测”只需在判定模块里多写一个分支不需要重新训练主模型。传统方法我也保留了用来做光照不足时的兜底方案不过实测下来实际意义不大不如把摄像头对准光源方向来得实在。1.3 模型选型轻量级关键点模型是核心关键点检测模型是整个系统的视觉基础我对比过几套方案以热力图回归为代表的精度向方案比如HRNet非常准确但参数量大、推理速度不够理想以坐标回归为代表的轻量向方案比如PFLD、MobileFaceNet的变体速度快但精度会有一定下降还有把人脸检测和关键点放在一起的多任务模型比如MTCNN、RetinaFace。综合评估下来我选择了一个基于轻量骨干网络的关键点模型输出的关键点数量是68点部署在CPU上也能跑到30FPS以上。这里特别想聊一下“速度优先”的取舍逻辑。疲劳检测的判定依据是闭眼、打哈欠这类持续动作单帧偶尔检错还能靠时间维度来平滑但如果帧率掉到10FPS以下时间窗口内的采样帧数严重不足判定的可靠性会大幅下降。与其追求极端精度不如保证稳定的帧率。实测中这个模型在普通笔记本CPU上单人场景能稳定跑到35FPS加上判定与绘制逻辑整体约25FPS到30FPS完全满足实时性要求。如果你手头硬件更好可以换ResNet50做骨干进一步提精度如果要部署到嵌入式设备可以把骨干替换成更轻的结构做量化压缩。2. 核心算法原理解读从关键点到疲劳指标2.1 EAR与MAR关键点坐标怎么变成“疲劳指标”拿到68个人脸关键点之后最直接的问题就是怎么从这些坐标判断眼睛是否闭上、嘴巴是否张开直接算欧氏距离对比显然不可靠因为人脸离摄像头远近不同像素距离没有绝对意义。这里就要用到论文里最常见的两个指标眼睛纵横比EAREye Aspect Ratio和嘴巴纵横比MARMouth Aspect Ratio。EAR的计算公式非常简单用眼睛六个关键点的垂直距离之和除以水平距离。为什么用纵横比而不是纯距离因为纵横比是一个比值天然不受人脸缩放的影响同一个人的眼睛睁大时EAR大约是0.3到0.35闭眼时EAR会掉到0.1以下这个分布非常稳定。MAR则是用嘴巴周围六个关键点的垂直距离除以水平距离打哈欠时嘴巴张大MAR会明显升高。两个指标的计算量几乎可以忽略不计在每一帧上算一次也就是几十次浮点运算。我封装关键点转指标时做了两个小优化一是EAR和MAR都做平滑滤波用滑动窗口均值替代原始值避免单帧抖动导致误判二是把左右眼的EAR分开计算并取较小值因为疲劳时可能单侧眼睛先出现下垂取最小值能更早捕捉到疲劳征兆。2.2 头部姿态估计判断“低头分神”的几何方法疲劳驾驶往往伴随着头部姿态变化最常见的是频繁低头和长时间低头。头部姿态估计的基本思路是用二维关键点和三维标准模型之间的对应关系求解相机外参得到旋转向量然后转换成欧拉角俯仰角pitch、偏航角yaw、滚转角roll。实现上有现成函数可以直接调用关键在于三维标准模型的坐标要准。三维标准模型是一个通用的人脸坐标集合定义的是鼻尖、下巴、左右眼外眼角等关键点在三维空间的位置。由于每个人的脸型不同这个通用模型会产生一定的姿态角度误差但对疲劳检测来说完全够用。以俯仰角为例正脸时pitch接近0度低头时pitch变负抬头时变正它们的判据和眼睛疲劳指标是正交的无论眼镜遮挡也好、光线不足导致关键点稍微漂移也好头部姿态依然能提供有用的信息。2.3 疲劳判定标准PERCLOS的计算方法PERCLOSPercentage of Eyelid Closure是疲劳检测领域公认有效的判定标准它统计的是单位时间内眼睛闭合时间所占的百分比。实际实现时我用滑动时间窗口内的闭眼帧数除以总帧数来计算PERCLOS值统计最近60帧EAR低于闭眼阈值的帧数超过某个比例就判定为疲劳。这里的一个关键设计是“闭眼帧数”不能单靠一帧就认定闭眼应该以连续闭眼持续帧数作为辅助条件。因为一个人正常眨眼也有闭眼瞬间眨眼造成的闭眼一般不会超过5帧按30FPS计算约0.15秒而真正疲劳时的闭眼会持续更长时间。判定逻辑可以写成这样当EAR低于阈值且持续超过一定帧数时闭眼计数加一如果只是瞬间低于阈值不进入疲劳统计。单独使用PERCLOS或者结合MAR计的哈欠频率会大大降低误报率。我的默认策略是PERCLOS超过40%或者连续低头pitch角小于某个负值超过一定时长就触发疲劳告警实测下来比单纯看EAR准确得多。判定模块的具体逻辑后面会再展开这里想强调设计思路单一指标永远不如多维指标可靠这也是用关键点做疲劳检测相比端到端分类最大的优势之一因为每个指标都有明确的物理含义哪一项超标、哪一项诱发了告警一眼就可以从日志里判断出来。3. 系统架构设计与核心代码实现3.1 多线程架构为什么不能把检测放在主循环里新手最容易犯的错误是把摄像头读取、模型推理、结果显示全部串行放在一个无限循环里。这样做的直接后果是帧率和判定逻辑强耦合模型推理一慢界面就卡顿告警阻塞画面就停止更新。我的做法是拆成三个线程加一个共享状态区采集线程只管读取摄像头帧并把最新帧放入队列推理线程从队列取帧做人脸检测、关键点提取和指标计算把结果写入共享状态主线程负责渲染界面、处理键盘输入和触发告警。线程之间用锁或原子操作保护共享状态队列限制长度并及时丢帧。这三个线程的设计有一个容易忽略的细节推理线程的速度跟不上采集速度时应该“丢弃旧帧”而不是“阻塞采集”。原因是疲劳检测判断的是变化趋势偶尔丢一帧不影响时间窗口统计但如果阻塞采集摄像头缓冲区会积压旧帧画面延迟会越来越大。实测下来把队列最大长度设为2满了就丢弃最旧的一帧延迟能控制在100毫秒以内。3.2 数据流与关键数据结构各模块之间通过一个全局状态结构体传递数据核心字段如下frame是当前显示帧faces是检测到的人脸列表landmarks是每个人脸的68点坐标数组ear和mar分别是计算后的指标pitch/yaw/roll是头部姿态角timer和status分别控制窗口计时和当前状态。class DriverState: def __init__(self): self.frame None self.faces [] self.landmarks [] self.ear 0.0 self.mar 0.0 self.pitch 0.0 self.yaw 0.0 self.roll 0.0 self.timer 0 self.status Normal这个结构体像系统全局的“黑板”各个线程往上面写不同字段主线程统一读取。避免在多个线程中直接操作复杂对象尽量只更新基本类型字段能减少很多同步问题的出现。3.3 推理线程核心逻辑推理线程的主循环比较固定从队列取帧、人脸检测、关键点提取、指标计算、写入状态。其中指标计算部分我用了一个自定义的FaceAnalyzer类里面实现了EAR、MAR和头部姿态角三个方法这样替换算法或者调整阈值都在这个类里完成不影响其他模块。人脸检测我用了一个轻量级的检测接口返回的是一组边界框。这里有个细节在进行下一步关键点提取之前我会先把人脸区域扩边约30%这样关键点模型能看到完整的脸部轮廓特别是下巴附近的点如果不扩边嘴巴和下巴边缘的关键点经常偏移很大。同时把裁剪出的人脸区域resize到固定尺寸送入关键点模型再把输出坐标按缩放比例映射回原图。3.4 闭眼与哈欠判定代码EAR和MAR的判定我单独封装了一个函数。核心逻辑是先计算当前帧的ear值如果小于阈值则进入“疑似闭眼”状态开始累计连续帧数当连续帧数超过一定值时才确认一次闭眼事件同理MAR超过阈值并维持一段时间判定一次打哈欠。这里要特别注意不要用“瞬时值超过阈值”直接判定因为用户说话、大笑都会让MAR短暂超过阈值必须加时间持续条件。def is_eye_closed(ear, threshold0.22): return ear threshold class FatigueCounter: def __init__(self, close_frames4, yawn_frames10): self.eye_closed_streak 0 self.yawn_streak 0 self.close_frames close_frames self.yawn_frames yawn_frames def update(self, ear, mar): if ear 0.22: self.eye_closed_streak 1 else: self.eye_closed_streak 0 if mar 0.55: self.yawn_streak 0 else: self.yawn_streak 1 eye_confirm self.eye_closed_streak self.close_frames yawn_confirm self.yawn_streak self.yawn_frames return eye_confirm, yawn_confirm3.5 驾驶行为识别分支驾驶行为识别我用了两个分支。第一个分支是头部行为在前面提到的头部姿态判定模块中完成。第二个分支是手持电话和抽烟检测这个不是靠人脸关键点能解决的需要检测人手和嘴部区域的交互。考虑到毕设课题的完整度我是用了一个额外的轻量目标检测模型来识别手部和吸烟相关物体检测到目标后判断其边界框与脸部区域的交叠程度交叠面积超过一定比例才判定为“疑似打电话”或“疑似抽烟”。实测下来这个交叠判定方案在单人驾驶位场景下效果尚可但是光照差、手部离脸近时误报会偏多。如果你做的是驾驶员状态监测相关的扩展课题建议使用专门的行为识别模型或者引入手部关键点模型来做更精细的判定。例如检测到手机且手部关键点呈现出“举到耳边”的姿态才能判定为打电话这样可以显著降低误报。4. 完整实操过程与效果调试4.1 环境准备与项目结构我建议直接用Anaconda创建独立环境避免和其他项目冲突。依赖主要是PyTorch或ONNX Runtime、OpenCV、NumPy以及界面库。我自己用的是ONNX Runtime做推理它跨平台、部署方便模型转换后不需要安装完整的深度学习框架。环境准备好之后项目目录分得清晰一点scripts放推理和训练脚本models放模型文件和配置文件utils放公共逻辑output存日志和告警截图。我强烈建议按这个结构组织而不是把所有代码堆在入口文件里。就我自己的经历而言第一次做的时候图方便把检测、判定、界面全写在一个脚本里到后来加行为分支的时候修改成本非常高。重构一次以后逻辑清晰了很多排查问题时也能直接定位到具体模块。在环境配置阶段有几个版本坑值得注意OpenCV的contrib包和主包要对应同一个版本否则人脸检测接口导入就会失败ONNX Runtime的CPU版本和GPU版本不能同时安装Python版本建议用3.8到3.10之间的稳定版本太新的版本容易遇到一些库尚未适配的冲突。4.2 数据集准备与模型训练公开的人脸关键点数据集可以直接下载使用里面有标注好的关键点坐标。如果要做行为分类比如打电话和抽烟可以结合公开的目标检测数据集来用。对于毕设来说模型一般不需要从零训练更建议用预训练权重做微调因为从头训练关键点模型的收敛难度较大每个点位的loss权重如果处理不好很容易出现部分点偏移。我在微调时重点做了数据增强随机亮度扰动、左右翻转、轻微旋转、随机遮挡。其中随机遮挡这个技巧比较实用模拟了驾驶员低头时部分关键点被遮挡的情况对提升检测稳定性很有帮助。训练集和验证集按8:2划分训练到验证集loss不再下降即可不需要追求极致的精度因为后续指标计算已经引入了时间窗口平滑对单帧关键点精度有一定容忍度。4.3 关键参数配置与调优过程调参部分是整个项目里最有价值的阶段。我把需要调的核心参数整理成了一张表闭眼EAR阈值0.20确认闭眼帧数4帧哈欠MAR阈值0.55确认哈欠帧数10帧疲劳PERCLOS窗口60帧疲劳阈值40%低头pitch角阈值小于-18度持续时间3秒以上触发分神告警图像缩放比例输入帧的短边resize到480至640像素之间。这些参数怎么来的我先在正常状态下统计10分钟内EAR的分布确定正常睁眼和正常眨眼的最低值区间再模拟闭眼动作观察闭眼时的EAR数值区间取两类分布的交界处作为初始阈值。然后用一段包含正常驾驶和疲劳动作的测试视频去验证统计误报率和漏报率反向微调阈值。这里有一个我自己很有感触的教训阈值不要追求理论最优而要考虑实际使用中的用户差异比如单眼皮用户的眼睛EAR整体偏低固定阈值需要根据不同人的标定结果做个性化调整。单人场景调好的阈值换个人可能就不太好用原因在于每个人的眼睑形状和头部比例不同。所以我也顺手写了一个简单的“自动标定”功能启动后前3秒作为初始化窗口采集正常睁眼时的EAR平均值把阈值自动设置为平均值的60%。这个功能在答辩演示时非常加分最终测下来的判定可靠性也提升了不少。4.4 告警与UI把检测结果“可视化”告警模块我用声音加界面闪烁的方式实现。声音告警用的是系统自带提示音多线程里设置了告警标志主线程检测到标志后连续播放一段音效直到用户按空格键解除。界面侧显示的信息包括实时画面、逻辑帧率、各指标的数值条、当前状态文字、累计疲劳事件数和最近一次告警时间。UI实现上我没有用完全实时渲染的重型框架而是用OpenCV自带的绘图函数直接在画面帧上叠加矩形框、关键点连线、指标文字。这样做的好处是不用适配不同平台的GUI环境在带摄像头的任何电脑上都能直接运行。关键点可视化我用了不同颜色区分眼睛、嘴巴和脸部轮廓线条方便效果展示论文里插入截图也会显得更直观。写界面时有个值得说明的细节状态文字不要频繁刷新文案比如每秒只更新几次避免文字闪烁导致看不清。我用的是“普通驾驶中、疑似疲劳、疲劳警告、分神提醒”四档状态每次状态切换时在日志里记录时间戳和触发指标方便事后回溯哪些帧导致了状态变化。4.5 性能优化与瓶颈定位性能优化是整个项目里收益最明显的部分。先分析耗时分布再针对性优化人脸检测通常占用CPU推理的大部分时间因此我会先用较小的输入尺寸做人脸检测再把人脸区域放大做关键点推理这样总耗时反而低于大尺寸输入。关键点模型我选择了轻量骨干网络并转为ONNX格式避免了框架运行时开销。此外把EAR、MAR、姿态计算和绘图显示拆分到不同线程绘图操作不会阻塞推理计算。实际在笔记本CPU上测出来的性能数据如下人脸检测约10毫秒关键点推理约12毫秒指标计算和判定小于0.5毫秒整帧处理约25毫秒对应约30到40FPS。显卡支持可用可不用但用显卡时需要多做一个GPU耗时检查以免模型加载失败后静默回退到CPU导致掉帧而难以察觉。优化准则总结起来就一句话先做剖面分析再改瓶颈不要凭感觉提前优化。5. 常见问题与避坑经验速查问题现象可能原因排查与解决摄像头画面很暗或人脸偏色摄像头自动白平衡和曝光策略不适合室内用OpenCV参数关闭自动曝光或对画面做直方图均衡化关键点偶尔跳到背景物体上人脸检测框抖动或扩边不足对检测框坐标做一阶低通滤波同时适当扩大检测框眨眼被误判为疲劳确认闭眼帧数设置过短把确认闭眼帧数从2帧提高到4-5帧防止瞬时误判长时间闭眼不告警PERCLOS统计窗口和触发阈值不匹配确认闭眼事件统计的是连续闭眼状态而不是眨眼次数打哈欠被漏检嘴部关键点受遮挡或MAR阈值偏高在关键点映射后单独裁剪嘴部区域调整MAR阈值并加长确认帧数推理速度达不到实时输入尺寸过大或模型太重先缩小检测输入再尝试换更轻的骨干模型最后考虑量化打包成exe后模型找不到模型路径被硬编码为相对路径用绝对路径或运行时动态获取打包后的临时目录5.1 漏检和误检的平衡技巧疲劳检测系统的整体可用性实际上是在误报率和漏报率之间做权衡。阈值调严例如EAR阈值更小、确认帧数更长漏报率会上升但误报率下降阈值调松则相反。我建议把闭眼确认帧数作为一个优先调节旋钮因为它对感受影响最直接然后把判定结果在时间维上做“触发锁存”——一旦触发疲劳告警至少维持5秒避免状态在边界值附近频繁跳变。还有一个经常被忽略的场景是戴眼镜的用户。普通眼镜对关键点检测影响不大但墨镜会把眼睛完全遮住EAR指标直接失效这时候需要切换到以头部姿态为主的判定模式。我在系统里根据两个指标的有效性做了简单的动态权重调整检测到眼部关键点置信度低时自动降低EAR权重并提高姿态角权重这个机制在答辩展示“特殊场景处理”时是很好的加分项。5.2 光线变化一个持续存在的挑战在车内场景中逆光和隧道光照变化导致的关键点漂移是实际使用中最难处理的问题之一。我用了几种手段缓解局部直方图均衡化提升面部区域对比度EAR和姿态角做滑动平均对闭眼判定增加最小持续时长。这些手段叠加下来在一般室内和模拟驾驶环境下表现稳定但彻底解决光照问题需要更复杂的图像增强网络作为毕设课题做到这个程度已经足够了。6. 开源发布与后续扩展方向6.1 项目开源时需要注意的事项毕业设计开源现在已经很普遍但开源不是简单把代码推到代码托管平台就完事了。我自己的经验是一个合格的开源项目至少需要README说明文档项目简介、运行环境、快速开始步骤、效果演示录屏、清晰的目录结构、LICENSE许可证说明、示例代码和数据集获取方式说明。如果数据集不能直接公开需要写明获取渠道和训练脚本用法。此外代码质量也要保持在“别人能看懂”的水平关键函数写清楚注释不要出现没有说明的魔法数字。这里我可以直接建议准备一个“模型转换脚本”放在tools目录下把训练得到的模型转成推理格式这样下载者不需要搭建深度学习训练环境就能直接跑通推理只有想继续微调的开发者才需要额外的数据准备。6.2 低成本硬件部署的可能路径把项目部署到低成本硬件上是一个常见的扩展方向。检测模型压缩的关键点在于量化把浮点模型转成整数精度模型后体积能减少到原来的四分之一左右推理速度在支持优化的平台上也有明显提升。实测在低成本边缘设备上双线程可以跑到15FPS左右虽然相比PC性能有所下降但作为实时监测原型已经够用。如果想在更低端的设备上跑可以考虑进一步精简方案放弃检测多人只追踪最靠近画面中心的人脸关键点模型替换成更小的结构把输入分辨率降到256像素级别同时将告警阈值调高。这些手段叠加后整体推理耗时能降到原来的一半左右速度和检测性能之间的取舍需要你根据自己的硬件型号反复尝试。6.3 从毕设到产品原型的思路扩展做完这套系统以后实际让我觉得最有延展空间的不是模型本身而是“多模态融合”和“个性化自适应”这两个方向。多模态融合是把摄像头数据、方向盘转向角度、车速、驾驶时长等数据融合起来做综合判断而不仅是依赖图像特征。个性化自适应是让系统根据每个用户的历史行为数据自动调整阈值参数比如有人天生眼睛小有人习惯性低头这些个体差异只有长时间数据积累才能被模型学到。另外这套代码还可以扩展到课堂专注度检测、远程面试状态分析、电竞选手疲劳提醒等场景。把视频源从摄像头换成本地视频文件再把告警模块改成数据上报接口就能很快改造成一个通用的“状态监测服务”。这一点在论文最后一章“展望”部分写起来很出效果也展示了项目框架的可复用性。6.4 一点个人经验如何把项目讲清楚到了答辩或者展示的时候最重要的不是算法细节背得多熟而是把“为什么做这些选择”讲清楚。比如为什么用关键点方法而不是端到端分类因为可解释性和实时性更好为什么阈值是这个值因为来自真实动作的统计分布为什么需要多线程因为实时系统的流畅度和判定逻辑需要解耦。把这些为什么逐个想明白整个项目的能力呈现就完整了。说话的方式上我建议配合实时演示来讲先用一个正常状态让指标曲线保持平稳再现场模拟闭眼、打哈欠和低头动作让告警触发的过程被评委直观看到。准备好一段展示时间线比如“启动系统、正常驾驶、模拟疲劳、触发告警、系统恢复”五个阶段各需要多少秒这样演示不会拖沓又有说服力。这套疲惫检测项目其实还有很大的继续开发空间真正让我收获最大的是通过完整实践理解了实时视觉系统里的一个基本道理模型能力只是边界系统设计和使用体验才决定产品效果。希望这篇经验整理能让你少走一些弯路也期待看到你基于这个框架做出更有意思的应用。