简介这是一套基于 PyQt5、YOLOv5 与 Dlib 的驾驶员行为监控系统课程设计完整源码面向计算机视觉、深度学习和 GUI 开发方向的在校生与开发者可支撑课程设计、毕业设计或驾驶安全预警原型搭建。系统利用 YOLOv5 实时检测人脸与头部姿态结合 Dlib 精准定位眼睛、嘴巴等关键点识别闭眼、张嘴、低头等危险行为并触发警报。压缩包共 105 个文件、约 224MB其中 66 个 Python 源码覆盖视频处理、行为识别、界面与报警逻辑4 个 ui 文件对应 PyQt 界面pt、t7、dat 提供模型权重及人脸关键点模型yaml/json 等为配置参数bat 脚本支持快速启动运行另有 mp3 提示音和说明文档目录结构清晰。已有 273 人学习浏览。借助该资源可得到一套直接可运行的项目方案掌握 YOLOv5 与 Dlib 的工程整合方法并能自行调整模型路径、界面布局和检测阈值为扩展更多驾驶行为识别打下基础。1. 驾驶员行为监控系统到底在监控什么先拆清 yolov5 与 dlib 的分工驾驶员行为监控系统在课程设计里通常不是让你真的去造一个量产车规级产品而是把三样东西串起来yolov5 负责检测手机、手部、水杯这些“分心因素”dlib 负责从人脸 68 点里算出闭眼、打哈欠、低头的疲劳信号pyqt 则把两路结果汇到一块屏幕上并触发声光报警。这个标题挑得好因为它是典型的“检测 状态估计 界面集成”三段式刚好覆盖计算机视觉和 GUI 编程的核心知识点。适合三类人要做课程设计或毕设的学生、想快速搭一套行为分析演示原型的工程师以及想把 yolov5 和 dlib 各自跑熟再串起来的自学者。整套系统做好之后演示效果很直观司机一闭眼超过阈值界面立刻弹报警这也是为什么它是答辩热门题目。当然真正的挑战不在单个模型的精度而在三套工具的生命周期、线程模型和推理延迟怎么互相兼容这篇文章就按这个顺序讲透。2. 整体架构与数据流转yolov5 管手、dlib 管脸pyqt 做那个“看得见”的壳2.1 先定边界yolov5 不负责“看脸”dlib 不负责“看手”新手最容易犯的错是试图让 yolov5 一个人把所有活干完既检测手机又检测眼睛闭合状态。yolov5 本质是目标检测网络它能告诉你“手机在图像里哪个位置”但给不了你“眼睛闭了多少”这种连续状态量——那是关键点估计landmark estimation的领域。dlib 恰好补上这一环它通过 68 个人脸关键点能在 2D 图像上稳定追踪眼睛轮廓和嘴唇轮廓进而计算 EAREye Aspect Ratio和 MARMouth Aspect Ratio。所以在我的方案里分工很明确组件负责的检测输出形式时序要求yolov5手机、手部靠近脸部、水杯类别 置信度 边界框单帧推理约 15-30msdlib人脸关键点、头部姿态68 点坐标、EAR/MAR/Pitch/Yaw单帧约 5-10mspyqt汇总两路结果、判定规则、UI 报警界面状态、声音提示30FPS 刷新即可这个划分不是拍脑袋。yolov5 对“人手里的手机”这类语义目标非常敏感因为它见过的标注数据里手机就是被手攥着的但你要是让它检测“眼睛睁开 0.7 毫米”它就没有直接监督信号了。反过来dlib 的人脸关键点在戴墨镜、侧脸时会乱飘但你还是得靠它做疲劳判定因为这是整套系统里唯一一个不在 GPU 上也能跑得动关键点估计的方案。两者串行跑在同一个视频流上互不干扰是课程设计里性价比最高的组合。2.2 系统文件结构与各个模块的职责我会把项目根目录整理成下面这种结构每个文件夹只干一件事后续出问题也不用到处翻文件driver_monitor/ ├── main.py # pyqt 入口创建主窗口和所有管理器 ├── detector/ │ ├── yolo_detector.py # 封装 yolov5 的 detect 逻辑返回 DetResult │ ├── dlib_worker.py # 封装 dlib 人脸检测 关键点 头部姿态 │ └── rule_engine.py # 疲劳/分心判定规则帧序列投票 ├── ui/ │ ├── main_window.py # pyqt 主窗口布局和刷新 │ └── alarm.py # 声光报警模块 ├── weights/ │ ├── best.pt # yolov5 训练好的权重 │ └── shape_predictor_68_face_landmarks.dat ├── datasets/ │ └── driver_behavior/ # 训练数据合集下章详述 └── runs/ # yolov5 训练输出results.csv 在这里每个模块在代码里就是两个角色yolo_detector 负责把一帧图像变成“有没有分心”的结构化证据比如在屏幕中央偏右位置出现手机置信度 0.82dlib_worker 负责把同一帧图像变成“疲劳信号”左眼 EAR0.18嘴部 MAR0.61Pitch-22 度rule_engine 则把这两类证据按时间序列整合输出最终报警指令。2.3 为什么需要 rule_engine 而不直接 if 判断课程设计做到后期你会发现单帧报警会让系统乱叫司机正常眨眼的 300ms 内 EAR 也会跌破阈值低头看仪表盘的一瞬间 Pitch 也会超限。所以规则引擎必须做成“连续 N 帧投票”而不是“单帧触发”。我用的规则是疲劳报警需要连续 10 帧约 0.3 秒EAR 低于 0.25 且 MAR 高于 0.6分心报警需要连续 8 帧检测到手机类别置信度大于 0.7。判断逻辑可以写在 rule_engine.py 里类初始化维护一个双端队列每帧推入结果同时弹出超过窗口长度的旧帧# rule_engine.py 要点滑窗投票判定 from collections import deque class RuleEngine: def __init__(self, window_frames10): self.window_frames window_frames self.ear_history deque(maxlenwindow_frames) self.phone_history deque(maxlen8) def feed_frame(self, ear_value, mar_value, has_phone, pitch_angle): self.ear_history.append(ear_value 0.25 and mar_value 0.6) self.phone_history.append(has_phone) if sum(self.ear_history) self.window_frames: return fatigue if sum(self.phone_history) 8: return distraction return None这段代码的核心在于deque(maxlenN)天然维护滑动窗口当新数据加入且超过长度时自动丢弃最老的元素sum直接给出窗口内满足条件的帧数。这样不会因为单帧抖动误报警也不会在司机已经放下手机后还持续报警 2 秒。手指头敲完这段基本就理解了什么叫“状态机”而不是“一次性判断”。3. 用 yolov5 训练自己的驾驶员数据集从标注到调参的完整命令3.1 标注数据与格式转换VOC 到 YOLO 格式的转换脚本课程设计场景下你想分类的往往是手机、水杯、烟盒、手部靠近面部这几类。不要指望直接下载一个现成的模型就能识别这些——通用模型你没准能检出 person 和 cell phone但它不太可能稳定地给出“bottle 在方向盘上”这种驾驶语义。所以你需要自己标一小批数据。常见做法是用 labelImg 或 labelme 标完导出 VOC 格式的 XML再转成 YOLO 要的 txt 标注文件。转换脚本是这种格式的门槛我一般这样写# voc2yolo.py把 labelImg 导出的 XML 转成 YOLO txt import xml.etree.ElementTree as ET import os classes [phone, bottle, hand, smoke] def convert_voc_to_yolo(xml_file, output_dir): tree ET.parse(xml_file) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) yolo_lines [] for obj in root.findall(object): cls_name obj.find(name).text if cls_name not in classes: continue cls_id classes.index(cls_name) bbox obj.find(bndbox) x_min float(bbox.find(xmin).text) y_min float(bbox.find(ymin).text) x_max float(bbox.find(xmax).text) y_max float(bbox.find(ymax).text) x_center (x_min x_max) / 2 / img_w y_center (y_min y_max) / 2 / img_h width (x_max - x_min) / img_w height (y_max - y_min) / img_h yolo_lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) if yolo_lines: base_name os.path.splitext(os.path.basename(xml_file))[0] with open(os.path.join(output_dir, base_name .txt), w) as f: f.write(\n.join(yolo_lines))这个脚本干的活就是把 XML 里的绝对像素坐标归一化到 0~1 区间。注意一个坑YOLO 坐标中心点(x_center, y_center)是相对图像宽高的比例不是像素值新手在这里经常不除img_w和img_h导致训练时 loss 一开始就巨大且不下降。转换完记得随机找三张图把 txt 里的坐标再画回原图确认一遍这一步能省掉后面一晚上的排查时间。3.2 训练命令与超参数选择主要调什么次要调什么我用的是 yolov5 官方仓库的 7.0 分支。在命令行里训练自己数据集最精简的启动命令是python train.py --data driver.yaml --weights yolov5s.pt --epochs 100 --batch-size 16 --imgsz 640 --hyp hyp.scratch-low.yaml --cachedriver.yaml里写数据集路径和类别数核心内容大概是train: ./datasets/driver_behavior/images/train val: ./datasets/driver_behavior/images/val nc: 4 names: [phone, bottle, hand, smoke]超参数重点盯几个imgsz在驾驶场景下不要盲目用 1280分辨率越高显卡越吃紧课程设计里 640 足够手机在画面上通常大于 40x40 像素能检出来batch-size按你显存来定6G 显存跑 16 就合适跑不动就降到 8不要硬上epochs在数据量只有几百张的情况下 100 轮足够多了必过拟合。真正影响精度的隐藏参数是hyp.scratch-low.yaml里的lr0初始学习率和mosaic增强概率。yolov5 里mosaic1.0默认开启但驾驶舱背景高度相似mosaic 合成图会和真实验收场景差异很大我一般会改成 0.5。这些参数不在界面上显示改完要重读 yaml 才能生效。另一个值得留意的训练异常是 loss 曲线“假收敛”如果你发现验证集 mAP 很高但实测视频里手机频繁漏检常见原因是训练图和测试图存在数据不平衡——比如白天样本是 80%晚上样本只有 20%。课程设计里建议直接固定一个时间段的数据采集别尝试做全天候系统那是产品级要做的事。3.3 训练完的产物怎么看results.csv 是黑匣子外唯一的窗户训练结束不要只看results.png那张趋势图。runs/train/exp*/results.csv才是你能量化判断的依据。我把关键列列出来对比看指标列正常值参考如果异常train/box_loss0.03~0.06 持续下降不降或上升说明学习率不对val/obj_loss0.02~0.05过拟合时会回升metrics/mAP_0.5 0.85数据不够或标注错误metrics/precision 0.8误报多时看它有一个血泪经验是不要只看mAP_0.5要看mAP_0.5:0.95它对框的精度要求更苛刻。驾驶场景手机遮挡多如果你的mAP_0.5很高但mAP_0.5:0.95低于 0.5说明你的检测框经常半准不准后面接的规则引擎会被“置信度够但位置偏”的框带偏。真遇到这种情况优先检查标注框是不是没贴合目标边缘——换 labelImg 的“自动吸附多边形”工具重标一圈通常比改模型参数见效快。4. 基于 dlib 的疲劳与分心判定68 点关键点、EAR/MAR 与头部姿态阈值4.1 EAR/MAR 的计算公式别抄错边界点别取错dlib 的预训练模型shape_predictor_68_face_landmarks.dat会输出人脸的 68 个关键点其中左眼用点 42~47右眼用点 36~41嘴巴用点 61~67。EAR 的经典公式是EAR (||p2 - p6|| ||p3 - p5||) / (2 * ||p1 - p4||)对应到 dlib 索引上左眼的 p2、p6 是点 43 和 47p3、p5 是 44 和 46p1、p4 是 42 和 45。写代码时最容易把垂直距离算成两两之间的距离和再除以 3实际上分母的 2 是固定的分子是两个垂直距离相加。代码里我这样写# dlib_worker.py 片段EAR 和 MAR 计算 def eye_aspect_ratio(eye_landmarks): # eye_landmarks 是 6 个 Point 对象按 dlib 索引顺序传入 vertical_a euclidean_distance(eye_landmarks[1], eye_landmarks[5]) vertical_b euclidean_distance(eye_landmarks[2], eye_landmarks[4]) horizontal euclidean_distance(eye_landmarks[0], eye_landmarks[3]) return (vertical_a vertical_b) / (2.0 * horizontal 1e-6)加1e-6是为了防止眼睛全闭时水平距离也趋近于 0 导致除零异常这种细节在你跑真实摄像头数据时一定会遇到。MAR 则是嘴部外侧到内侧距离比上嘴部宽度阈值可以设在 0.6 附近但这不是固定不变的我下面会讲抖动问题和处理办法。注意一点dlib 关键点在侧面脸时会因为遮挡导致个别点飘所以阈值判断前要做一个“关键点有效性检查”即六点之间的连线长度是否在合理区间不然侧脸一帧就会把 EAR 打到 0.1。4.2 头部姿态估计Pitch/Yaw/Roll 怎么算出来疲劳检测光靠眼睛闭不闭合不够低头是一个更强的疲劳信号。dlib 本身不给姿态角但我可以用 solvePnP 求解人脸关键点的 3D 投影来算。常规做法是需要一个 3D 人脸模型和相机内参课程设计可以偷个懒用一张标准正面脸的 68 点坐标作为参考 3D 点相机内参用近似值反正我们只需要相对角度而不是绝对标定值。# 头部姿态估计用 5 个标志点做 solvePnP import cv2 import numpy as np # 3D 模型点单位 mm取鼻尖、下巴、左眼左角等经典位置 model_points np.array([ (0.0, 0.0, 0.0), # 鼻尖 (0.0, -63.6, -12.5), # 下巴 (-43.3, 32.7, -26.0), # 左眼左角 (43.3, 32.7, -26.0), # 右眼右角 (0.0, 63.6, -12.5) # 额头中心 ], dtypenp.float64) # image_points 从 68 点中挑对应索引 _, rvec, tvec cv2.solvePnP(model_points, image_points, camera_matrix, dist_coeffs) rmat, _ cv2.Rodrigues(rvec) pitch np.degrees(np.arctan2(rmat[1, 0], rmat[2, 0])) yaw np.degrees(np.arctan2(rmat[1, 2], rmat[2, 2]))实现里最坑的是image_points的选取不要用全部 68 点只选五个角点能避免外围点抖动带来的噪声。Pitch 负值代表低头我一般在pitch -15时判定为低头。这个 15 度阈值没有标准答案和摄像头装的位置关系很大摄像头架在仪表盘上方平视司机阈值可以小到 12 度如果架在挡风玻璃上方俯拍头部正常姿势 Pitch 本身就会偏负不重新标定阈值的话系统会一直误报。4.3 报警规则引擎连续帧投票的阈值修正所有 dlib 的输出EAR/MAR/角度都要过一遍滑窗才可以和 yolov5 的检测结果合并一起决定报不报警。我把这部分的逻辑写在 rule_engine.py 中并用一个辅助函数把单帧健康状态归类def evaluate_frame(ear, mar, pitch, has_phone, conf): fatigue_score 0 if ear 0.25 and mar 0.6: fatigue_score 1 if pitch -15: fatigue_score 1 if fatigue_score 2: return fatigue_level_1 if has_phone and conf 0.7: return distraction return normalevaluate_frame只是单帧判定后面再接滑窗。滑窗的长度要按摄像头帧率适配如果代码跑到 25FPS10 帧窗口约等于 0.4 秒眨眼自然的时长在 0.1~0.2 秒不会误触发如果检测线程跑得慢只有 10FPS10 帧就会变成 1 秒报警会相当迟钝。所以我习惯把滑窗长度做成参数直接跟随实测 FPS 动态计算而不是写死。这也是后期调系统最常翻车的地方很多小组把 window_frames 写死为 10结果运行环境一变疲劳报警忽快忽慢。5. pyqt 界面集成与线程模型为什么你的窗口一检测就“未响应”5.1 线程模型QTimer 驱动 UI 刷新检测必须在子线程很多教程会让你直接在 pyqt 的while True循环里读摄像头并跑检测然后你就看到窗口标题变成“未响应”。原因是主线程被推理阻塞事件循环没法处理鼠标点击和窗口重绘。解决思路是让检测全部跑在QThread里通过信号把结果传回主线程主线程里只做“拿最新结果刷到界面上”。我启动检测线程的方式是这样# main_window.py 要点QThread 跑检测信号回传 UI class DetectThread(QThread): frame_ready pyqtSignal(dict) def run(self): while self.running: frame self.capture.read() det_result yolo.detect(frame) face_metrics dlib_worker.analyze(frame) self.frame_ready.emit({ frame: frame, fatigue: rule_engine.feed(...), distraction: ... })pyqt 里信号frame_ready会在子线程 emit 后由事件循环调度到主线程执行主线程的槽函数里只做 UI 更新不做任何耗时操作。这个模式一旦跑顺窗口再也不会假死。5.2 坑1dlib 模型加载写在init里窗口 10 秒才弹出来现象启动程序后主窗口长时间不出现任务管理器里看到 Python 进程 CPU 100%。原因shape_predictor_68_face_landmarks.dat有接近 100MB在冰凉的磁盘上读取加解析需要 3~10 秒而main_window.__init__()是在主线程里跑的它不结束窗口就不会 show。解决把模型初始化放到DetectThread的run()方法开头反正检测线程启动前也不会收帧或者在主窗口先显示一个加载提示再用单发 QTimer 启动检测线程。我之前觉得无所谓直到演示时评委盯着黑屏窗口等 8 秒才把加载挪到子线程。5.3 坑2摄像头被占用升级版是“OpenCV 崩溃没有任何报错”现象程序跑着跑着摄像头突然断连程序直接退出或卡死无异常信息。原因USB 摄像头被其他软件抢占或者分辨率让摄像头驱动无法稳定输出。pyqt 的槽函数里还在画图底层 OpenCV 却抛了一个 C 异常Python 的 try/except 接不住。解决在主窗口加一个“摄像头发送状态”指示灯读取帧失败时不仅打印日志还要把帧计数置零并自动 reconnect。我习惯的做法是每次read()之后检查返回的ret一旦连续 3 帧失败就关闭对应cv2.VideoCapture并延迟 2 秒重新打开这个行为放在检测线程内而不放在 UI 层因为 UI 层做重连操作会继续卡界面。5.4 坑3单帧推理时间太长QTimer 刷新不过来了现象主窗口用QTimer(30ms)刷新视频标签但实际视频更新可能 300ms 才动一次。原因yolov5 推理在无 GPU 环境下单帧可能 40~80ms加上 dlib 的关键点和姿态估计又是 10~20ms数据生产速率远低于 UI 期望的刷新速率。QTimer 只管“到时间就调用一次槽函数”但槽函数拿到的可能还是旧帧。解决不要在 UI 槽函数里去调检测接口应该由检测线程主动发布“最新帧”UI 槽函数只负责把最新一帧贴到控件里。为了不让信号积压我通常在 emit 后检查self.frame_ready.receivers()如果已经积压超过 2 帧就丢弃旧帧再发新的。这样 UI 的帧率会跟随检测速度动态调整显示效果始终是连贯的没有积累延迟。5.5 坑4EAR 和 MAR 的“玄学阈值”换个人就乱报警现象同一套代码测试同学 A 眼睛大、不爱眨一切正常同学 B 眼睛小、近视镜反光程序全程疲劳报警。原因EAR 阈值是经典论文里基于理想正面光照给的值和实际摄像头分辨率、人脸距离、戴不戴眼镜高度绑定。特别是镜片反光时 dlib 关键点会往镜框上吸轮廓会整体变形。解决做 10 秒静默标定——系统启动后提示司机正面看镜头 10 秒采集这段 EAR/MAR 的均值和方差然后把报警阈值设成“均值减去 2.5 倍标准差”。这样每台机器、每个人都会得到自己的个性化阈值而不是硬编码 0.25。这一招几乎能让误报率下降一半值得写进你们的答辩 PPT。6. 验证与调优三张图判断你的监控系统能不能上演示台课程设计验收时评委最烦听到“我这模型 mAP 可高了”裁判最想看的是“这个系统在真实视频里可靠地报警”。所以我每次做完整套系统后会用三张图做验收第一张是results.csv里提取的 P-R 曲线确认不是过拟合情况训练 loss 降而验证 loss 升。第二张是把一段 2 分钟驾驶视频逐帧标注“是否应该报警”然后跑系统画出实际报警帧和期望报警帧的对比折线。第三张是报警延迟直方图从真实危险动作发生到界面弹出报警的秒数分布。这三张图出来任何评委提问都打不倒你。调优的习惯我沿用了很久每次只改一个变量比如把mosaic从 1.0 调到 0.5其余不动重新训练一轮记录 mAP 变化。不要一上来就调三个参数不然模型变好了你也不知道是谁的功劳——机器学习本质上就是个控制变量实验。另一条经验是 dlib 的输入框不要用整张图先通过 yolov5 的person检测框裁剪出人脸区域再送给 dlib。这会砍掉大约 60% 的背景计算量推理速度立刻提上来。这套系统做完的价值不只是应付一门课程。yolov5 的训练管线、dlib 的状态估计、pyqt 的线程模型刚好是对工业视觉系统三个典型模块的速成练习。往后你在实际项目里做质检、做安防、做交互设备都会碰到同样的问题什么算法负责感知什么算法负责状态估计界面层怎么不卡死。把这三个角色分清楚换任何模型都只是替换接口的事。我的经验是演示之前一定把摄像头架稳、光照调均匀然后让系统先跑 5 分钟不报警证明它不是个“惊弓之鸟”。这个细节救过我一次现场翻车——那次是头顶日光灯频闪dlib 关键点跟着闪疲劳指标周期性跳动差点把一场演示变成闹剧。希望这些调试路径能帮你在同样的位置少花几个晚上毕竟课程设计的最终目标不是模型多强而是你能讲清楚每个环节为什么这么做。希望帮到你。本文还有配套的精品资源点击获取
简介这是一套基于 PyQt5、YOLOv5 与 Dlib 的驾驶员行为监控系统课程设计完整源码面向计算机视觉、深度学习和 GUI 开发方向的在校生与开发者可支撑课程设计、毕业设计或驾驶安全预警原型搭建。系统利用 YOLOv5 实时检测人脸与头部姿态结合 Dlib 精准定位眼睛、嘴巴等关键点识别闭眼、张嘴、低头等危险行为并触发警报。压缩包共 105 个文件、约 224MB其中 66 个 Python 源码覆盖视频处理、行为识别、界面与报警逻辑4 个 ui 文件对应 PyQt 界面pt、t7、dat 提供模型权重及人脸关键点模型yaml/json 等为配置参数bat 脚本支持快速启动运行另有 mp3 提示音和说明文档目录结构清晰。已有 273 人学习浏览。借助该资源可得到一套直接可运行的项目方案掌握 YOLOv5 与 Dlib 的工程整合方法并能自行调整模型路径、界面布局和检测阈值为扩展更多驾驶行为识别打下基础。1. 驾驶员行为监控系统到底在监控什么先拆清 yolov5 与 dlib 的分工驾驶员行为监控系统在课程设计里通常不是让你真的去造一个量产车规级产品而是把三样东西串起来yolov5 负责检测手机、手部、水杯这些“分心因素”dlib 负责从人脸 68 点里算出闭眼、打哈欠、低头的疲劳信号pyqt 则把两路结果汇到一块屏幕上并触发声光报警。这个标题挑得好因为它是典型的“检测 状态估计 界面集成”三段式刚好覆盖计算机视觉和 GUI 编程的核心知识点。适合三类人要做课程设计或毕设的学生、想快速搭一套行为分析演示原型的工程师以及想把 yolov5 和 dlib 各自跑熟再串起来的自学者。整套系统做好之后演示效果很直观司机一闭眼超过阈值界面立刻弹报警这也是为什么它是答辩热门题目。当然真正的挑战不在单个模型的精度而在三套工具的生命周期、线程模型和推理延迟怎么互相兼容这篇文章就按这个顺序讲透。2. 整体架构与数据流转yolov5 管手、dlib 管脸pyqt 做那个“看得见”的壳2.1 先定边界yolov5 不负责“看脸”dlib 不负责“看手”新手最容易犯的错是试图让 yolov5 一个人把所有活干完既检测手机又检测眼睛闭合状态。yolov5 本质是目标检测网络它能告诉你“手机在图像里哪个位置”但给不了你“眼睛闭了多少”这种连续状态量——那是关键点估计landmark estimation的领域。dlib 恰好补上这一环它通过 68 个人脸关键点能在 2D 图像上稳定追踪眼睛轮廓和嘴唇轮廓进而计算 EAREye Aspect Ratio和 MARMouth Aspect Ratio。所以在我的方案里分工很明确组件负责的检测输出形式时序要求yolov5手机、手部靠近脸部、水杯类别 置信度 边界框单帧推理约 15-30msdlib人脸关键点、头部姿态68 点坐标、EAR/MAR/Pitch/Yaw单帧约 5-10mspyqt汇总两路结果、判定规则、UI 报警界面状态、声音提示30FPS 刷新即可这个划分不是拍脑袋。yolov5 对“人手里的手机”这类语义目标非常敏感因为它见过的标注数据里手机就是被手攥着的但你要是让它检测“眼睛睁开 0.7 毫米”它就没有直接监督信号了。反过来dlib 的人脸关键点在戴墨镜、侧脸时会乱飘但你还是得靠它做疲劳判定因为这是整套系统里唯一一个不在 GPU 上也能跑得动关键点估计的方案。两者串行跑在同一个视频流上互不干扰是课程设计里性价比最高的组合。2.2 系统文件结构与各个模块的职责我会把项目根目录整理成下面这种结构每个文件夹只干一件事后续出问题也不用到处翻文件driver_monitor/ ├── main.py # pyqt 入口创建主窗口和所有管理器 ├── detector/ │ ├── yolo_detector.py # 封装 yolov5 的 detect 逻辑返回 DetResult │ ├── dlib_worker.py # 封装 dlib 人脸检测 关键点 头部姿态 │ └── rule_engine.py # 疲劳/分心判定规则帧序列投票 ├── ui/ │ ├── main_window.py # pyqt 主窗口布局和刷新 │ └── alarm.py # 声光报警模块 ├── weights/ │ ├── best.pt # yolov5 训练好的权重 │ └── shape_predictor_68_face_landmarks.dat ├── datasets/ │ └── driver_behavior/ # 训练数据合集下章详述 └── runs/ # yolov5 训练输出results.csv 在这里每个模块在代码里就是两个角色yolo_detector 负责把一帧图像变成“有没有分心”的结构化证据比如在屏幕中央偏右位置出现手机置信度 0.82dlib_worker 负责把同一帧图像变成“疲劳信号”左眼 EAR0.18嘴部 MAR0.61Pitch-22 度rule_engine 则把这两类证据按时间序列整合输出最终报警指令。2.3 为什么需要 rule_engine 而不直接 if 判断课程设计做到后期你会发现单帧报警会让系统乱叫司机正常眨眼的 300ms 内 EAR 也会跌破阈值低头看仪表盘的一瞬间 Pitch 也会超限。所以规则引擎必须做成“连续 N 帧投票”而不是“单帧触发”。我用的规则是疲劳报警需要连续 10 帧约 0.3 秒EAR 低于 0.25 且 MAR 高于 0.6分心报警需要连续 8 帧检测到手机类别置信度大于 0.7。判断逻辑可以写在 rule_engine.py 里类初始化维护一个双端队列每帧推入结果同时弹出超过窗口长度的旧帧# rule_engine.py 要点滑窗投票判定 from collections import deque class RuleEngine: def __init__(self, window_frames10): self.window_frames window_frames self.ear_history deque(maxlenwindow_frames) self.phone_history deque(maxlen8) def feed_frame(self, ear_value, mar_value, has_phone, pitch_angle): self.ear_history.append(ear_value 0.25 and mar_value 0.6) self.phone_history.append(has_phone) if sum(self.ear_history) self.window_frames: return fatigue if sum(self.phone_history) 8: return distraction return None这段代码的核心在于deque(maxlenN)天然维护滑动窗口当新数据加入且超过长度时自动丢弃最老的元素sum直接给出窗口内满足条件的帧数。这样不会因为单帧抖动误报警也不会在司机已经放下手机后还持续报警 2 秒。手指头敲完这段基本就理解了什么叫“状态机”而不是“一次性判断”。3. 用 yolov5 训练自己的驾驶员数据集从标注到调参的完整命令3.1 标注数据与格式转换VOC 到 YOLO 格式的转换脚本课程设计场景下你想分类的往往是手机、水杯、烟盒、手部靠近面部这几类。不要指望直接下载一个现成的模型就能识别这些——通用模型你没准能检出 person 和 cell phone但它不太可能稳定地给出“bottle 在方向盘上”这种驾驶语义。所以你需要自己标一小批数据。常见做法是用 labelImg 或 labelme 标完导出 VOC 格式的 XML再转成 YOLO 要的 txt 标注文件。转换脚本是这种格式的门槛我一般这样写# voc2yolo.py把 labelImg 导出的 XML 转成 YOLO txt import xml.etree.ElementTree as ET import os classes [phone, bottle, hand, smoke] def convert_voc_to_yolo(xml_file, output_dir): tree ET.parse(xml_file) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) yolo_lines [] for obj in root.findall(object): cls_name obj.find(name).text if cls_name not in classes: continue cls_id classes.index(cls_name) bbox obj.find(bndbox) x_min float(bbox.find(xmin).text) y_min float(bbox.find(ymin).text) x_max float(bbox.find(xmax).text) y_max float(bbox.find(ymax).text) x_center (x_min x_max) / 2 / img_w y_center (y_min y_max) / 2 / img_h width (x_max - x_min) / img_w height (y_max - y_min) / img_h yolo_lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) if yolo_lines: base_name os.path.splitext(os.path.basename(xml_file))[0] with open(os.path.join(output_dir, base_name .txt), w) as f: f.write(\n.join(yolo_lines))这个脚本干的活就是把 XML 里的绝对像素坐标归一化到 0~1 区间。注意一个坑YOLO 坐标中心点(x_center, y_center)是相对图像宽高的比例不是像素值新手在这里经常不除img_w和img_h导致训练时 loss 一开始就巨大且不下降。转换完记得随机找三张图把 txt 里的坐标再画回原图确认一遍这一步能省掉后面一晚上的排查时间。3.2 训练命令与超参数选择主要调什么次要调什么我用的是 yolov5 官方仓库的 7.0 分支。在命令行里训练自己数据集最精简的启动命令是python train.py --data driver.yaml --weights yolov5s.pt --epochs 100 --batch-size 16 --imgsz 640 --hyp hyp.scratch-low.yaml --cachedriver.yaml里写数据集路径和类别数核心内容大概是train: ./datasets/driver_behavior/images/train val: ./datasets/driver_behavior/images/val nc: 4 names: [phone, bottle, hand, smoke]超参数重点盯几个imgsz在驾驶场景下不要盲目用 1280分辨率越高显卡越吃紧课程设计里 640 足够手机在画面上通常大于 40x40 像素能检出来batch-size按你显存来定6G 显存跑 16 就合适跑不动就降到 8不要硬上epochs在数据量只有几百张的情况下 100 轮足够多了必过拟合。真正影响精度的隐藏参数是hyp.scratch-low.yaml里的lr0初始学习率和mosaic增强概率。yolov5 里mosaic1.0默认开启但驾驶舱背景高度相似mosaic 合成图会和真实验收场景差异很大我一般会改成 0.5。这些参数不在界面上显示改完要重读 yaml 才能生效。另一个值得留意的训练异常是 loss 曲线“假收敛”如果你发现验证集 mAP 很高但实测视频里手机频繁漏检常见原因是训练图和测试图存在数据不平衡——比如白天样本是 80%晚上样本只有 20%。课程设计里建议直接固定一个时间段的数据采集别尝试做全天候系统那是产品级要做的事。3.3 训练完的产物怎么看results.csv 是黑匣子外唯一的窗户训练结束不要只看results.png那张趋势图。runs/train/exp*/results.csv才是你能量化判断的依据。我把关键列列出来对比看指标列正常值参考如果异常train/box_loss0.03~0.06 持续下降不降或上升说明学习率不对val/obj_loss0.02~0.05过拟合时会回升metrics/mAP_0.5 0.85数据不够或标注错误metrics/precision 0.8误报多时看它有一个血泪经验是不要只看mAP_0.5要看mAP_0.5:0.95它对框的精度要求更苛刻。驾驶场景手机遮挡多如果你的mAP_0.5很高但mAP_0.5:0.95低于 0.5说明你的检测框经常半准不准后面接的规则引擎会被“置信度够但位置偏”的框带偏。真遇到这种情况优先检查标注框是不是没贴合目标边缘——换 labelImg 的“自动吸附多边形”工具重标一圈通常比改模型参数见效快。4. 基于 dlib 的疲劳与分心判定68 点关键点、EAR/MAR 与头部姿态阈值4.1 EAR/MAR 的计算公式别抄错边界点别取错dlib 的预训练模型shape_predictor_68_face_landmarks.dat会输出人脸的 68 个关键点其中左眼用点 42~47右眼用点 36~41嘴巴用点 61~67。EAR 的经典公式是EAR (||p2 - p6|| ||p3 - p5||) / (2 * ||p1 - p4||)对应到 dlib 索引上左眼的 p2、p6 是点 43 和 47p3、p5 是 44 和 46p1、p4 是 42 和 45。写代码时最容易把垂直距离算成两两之间的距离和再除以 3实际上分母的 2 是固定的分子是两个垂直距离相加。代码里我这样写# dlib_worker.py 片段EAR 和 MAR 计算 def eye_aspect_ratio(eye_landmarks): # eye_landmarks 是 6 个 Point 对象按 dlib 索引顺序传入 vertical_a euclidean_distance(eye_landmarks[1], eye_landmarks[5]) vertical_b euclidean_distance(eye_landmarks[2], eye_landmarks[4]) horizontal euclidean_distance(eye_landmarks[0], eye_landmarks[3]) return (vertical_a vertical_b) / (2.0 * horizontal 1e-6)加1e-6是为了防止眼睛全闭时水平距离也趋近于 0 导致除零异常这种细节在你跑真实摄像头数据时一定会遇到。MAR 则是嘴部外侧到内侧距离比上嘴部宽度阈值可以设在 0.6 附近但这不是固定不变的我下面会讲抖动问题和处理办法。注意一点dlib 关键点在侧面脸时会因为遮挡导致个别点飘所以阈值判断前要做一个“关键点有效性检查”即六点之间的连线长度是否在合理区间不然侧脸一帧就会把 EAR 打到 0.1。4.2 头部姿态估计Pitch/Yaw/Roll 怎么算出来疲劳检测光靠眼睛闭不闭合不够低头是一个更强的疲劳信号。dlib 本身不给姿态角但我可以用 solvePnP 求解人脸关键点的 3D 投影来算。常规做法是需要一个 3D 人脸模型和相机内参课程设计可以偷个懒用一张标准正面脸的 68 点坐标作为参考 3D 点相机内参用近似值反正我们只需要相对角度而不是绝对标定值。# 头部姿态估计用 5 个标志点做 solvePnP import cv2 import numpy as np # 3D 模型点单位 mm取鼻尖、下巴、左眼左角等经典位置 model_points np.array([ (0.0, 0.0, 0.0), # 鼻尖 (0.0, -63.6, -12.5), # 下巴 (-43.3, 32.7, -26.0), # 左眼左角 (43.3, 32.7, -26.0), # 右眼右角 (0.0, 63.6, -12.5) # 额头中心 ], dtypenp.float64) # image_points 从 68 点中挑对应索引 _, rvec, tvec cv2.solvePnP(model_points, image_points, camera_matrix, dist_coeffs) rmat, _ cv2.Rodrigues(rvec) pitch np.degrees(np.arctan2(rmat[1, 0], rmat[2, 0])) yaw np.degrees(np.arctan2(rmat[1, 2], rmat[2, 2]))实现里最坑的是image_points的选取不要用全部 68 点只选五个角点能避免外围点抖动带来的噪声。Pitch 负值代表低头我一般在pitch -15时判定为低头。这个 15 度阈值没有标准答案和摄像头装的位置关系很大摄像头架在仪表盘上方平视司机阈值可以小到 12 度如果架在挡风玻璃上方俯拍头部正常姿势 Pitch 本身就会偏负不重新标定阈值的话系统会一直误报。4.3 报警规则引擎连续帧投票的阈值修正所有 dlib 的输出EAR/MAR/角度都要过一遍滑窗才可以和 yolov5 的检测结果合并一起决定报不报警。我把这部分的逻辑写在 rule_engine.py 中并用一个辅助函数把单帧健康状态归类def evaluate_frame(ear, mar, pitch, has_phone, conf): fatigue_score 0 if ear 0.25 and mar 0.6: fatigue_score 1 if pitch -15: fatigue_score 1 if fatigue_score 2: return fatigue_level_1 if has_phone and conf 0.7: return distraction return normalevaluate_frame只是单帧判定后面再接滑窗。滑窗的长度要按摄像头帧率适配如果代码跑到 25FPS10 帧窗口约等于 0.4 秒眨眼自然的时长在 0.1~0.2 秒不会误触发如果检测线程跑得慢只有 10FPS10 帧就会变成 1 秒报警会相当迟钝。所以我习惯把滑窗长度做成参数直接跟随实测 FPS 动态计算而不是写死。这也是后期调系统最常翻车的地方很多小组把 window_frames 写死为 10结果运行环境一变疲劳报警忽快忽慢。5. pyqt 界面集成与线程模型为什么你的窗口一检测就“未响应”5.1 线程模型QTimer 驱动 UI 刷新检测必须在子线程很多教程会让你直接在 pyqt 的while True循环里读摄像头并跑检测然后你就看到窗口标题变成“未响应”。原因是主线程被推理阻塞事件循环没法处理鼠标点击和窗口重绘。解决思路是让检测全部跑在QThread里通过信号把结果传回主线程主线程里只做“拿最新结果刷到界面上”。我启动检测线程的方式是这样# main_window.py 要点QThread 跑检测信号回传 UI class DetectThread(QThread): frame_ready pyqtSignal(dict) def run(self): while self.running: frame self.capture.read() det_result yolo.detect(frame) face_metrics dlib_worker.analyze(frame) self.frame_ready.emit({ frame: frame, fatigue: rule_engine.feed(...), distraction: ... })pyqt 里信号frame_ready会在子线程 emit 后由事件循环调度到主线程执行主线程的槽函数里只做 UI 更新不做任何耗时操作。这个模式一旦跑顺窗口再也不会假死。5.2 坑1dlib 模型加载写在init里窗口 10 秒才弹出来现象启动程序后主窗口长时间不出现任务管理器里看到 Python 进程 CPU 100%。原因shape_predictor_68_face_landmarks.dat有接近 100MB在冰凉的磁盘上读取加解析需要 3~10 秒而main_window.__init__()是在主线程里跑的它不结束窗口就不会 show。解决把模型初始化放到DetectThread的run()方法开头反正检测线程启动前也不会收帧或者在主窗口先显示一个加载提示再用单发 QTimer 启动检测线程。我之前觉得无所谓直到演示时评委盯着黑屏窗口等 8 秒才把加载挪到子线程。5.3 坑2摄像头被占用升级版是“OpenCV 崩溃没有任何报错”现象程序跑着跑着摄像头突然断连程序直接退出或卡死无异常信息。原因USB 摄像头被其他软件抢占或者分辨率让摄像头驱动无法稳定输出。pyqt 的槽函数里还在画图底层 OpenCV 却抛了一个 C 异常Python 的 try/except 接不住。解决在主窗口加一个“摄像头发送状态”指示灯读取帧失败时不仅打印日志还要把帧计数置零并自动 reconnect。我习惯的做法是每次read()之后检查返回的ret一旦连续 3 帧失败就关闭对应cv2.VideoCapture并延迟 2 秒重新打开这个行为放在检测线程内而不放在 UI 层因为 UI 层做重连操作会继续卡界面。5.4 坑3单帧推理时间太长QTimer 刷新不过来了现象主窗口用QTimer(30ms)刷新视频标签但实际视频更新可能 300ms 才动一次。原因yolov5 推理在无 GPU 环境下单帧可能 40~80ms加上 dlib 的关键点和姿态估计又是 10~20ms数据生产速率远低于 UI 期望的刷新速率。QTimer 只管“到时间就调用一次槽函数”但槽函数拿到的可能还是旧帧。解决不要在 UI 槽函数里去调检测接口应该由检测线程主动发布“最新帧”UI 槽函数只负责把最新一帧贴到控件里。为了不让信号积压我通常在 emit 后检查self.frame_ready.receivers()如果已经积压超过 2 帧就丢弃旧帧再发新的。这样 UI 的帧率会跟随检测速度动态调整显示效果始终是连贯的没有积累延迟。5.5 坑4EAR 和 MAR 的“玄学阈值”换个人就乱报警现象同一套代码测试同学 A 眼睛大、不爱眨一切正常同学 B 眼睛小、近视镜反光程序全程疲劳报警。原因EAR 阈值是经典论文里基于理想正面光照给的值和实际摄像头分辨率、人脸距离、戴不戴眼镜高度绑定。特别是镜片反光时 dlib 关键点会往镜框上吸轮廓会整体变形。解决做 10 秒静默标定——系统启动后提示司机正面看镜头 10 秒采集这段 EAR/MAR 的均值和方差然后把报警阈值设成“均值减去 2.5 倍标准差”。这样每台机器、每个人都会得到自己的个性化阈值而不是硬编码 0.25。这一招几乎能让误报率下降一半值得写进你们的答辩 PPT。6. 验证与调优三张图判断你的监控系统能不能上演示台课程设计验收时评委最烦听到“我这模型 mAP 可高了”裁判最想看的是“这个系统在真实视频里可靠地报警”。所以我每次做完整套系统后会用三张图做验收第一张是results.csv里提取的 P-R 曲线确认不是过拟合情况训练 loss 降而验证 loss 升。第二张是把一段 2 分钟驾驶视频逐帧标注“是否应该报警”然后跑系统画出实际报警帧和期望报警帧的对比折线。第三张是报警延迟直方图从真实危险动作发生到界面弹出报警的秒数分布。这三张图出来任何评委提问都打不倒你。调优的习惯我沿用了很久每次只改一个变量比如把mosaic从 1.0 调到 0.5其余不动重新训练一轮记录 mAP 变化。不要一上来就调三个参数不然模型变好了你也不知道是谁的功劳——机器学习本质上就是个控制变量实验。另一条经验是 dlib 的输入框不要用整张图先通过 yolov5 的person检测框裁剪出人脸区域再送给 dlib。这会砍掉大约 60% 的背景计算量推理速度立刻提上来。这套系统做完的价值不只是应付一门课程。yolov5 的训练管线、dlib 的状态估计、pyqt 的线程模型刚好是对工业视觉系统三个典型模块的速成练习。往后你在实际项目里做质检、做安防、做交互设备都会碰到同样的问题什么算法负责感知什么算法负责状态估计界面层怎么不卡死。把这三个角色分清楚换任何模型都只是替换接口的事。我的经验是演示之前一定把摄像头架稳、光照调均匀然后让系统先跑 5 分钟不报警证明它不是个“惊弓之鸟”。这个细节救过我一次现场翻车——那次是头顶日光灯频闪dlib 关键点跟着闪疲劳指标周期性跳动差点把一场演示变成闹剧。希望这些调试路径能帮你在同样的位置少花几个晚上毕竟课程设计的最终目标不是模型多强而是你能讲清楚每个环节为什么这么做。希望帮到你。本文还有配套的精品资源点击获取
