简介：这是一套面向计算机视觉课程设计、毕业设计及 PyQt 入门者的驾驶员行为监控系统完整工程。系统以 PyQt5 搭建可视化界面，联合 YOLOv5 完成人脸与目标实时检测，并借助 Dlib 人脸关键点模型定位眼部、嘴部特征，进而识别闭眼、低头、分心驾驶等危险状态，在设定阈值后触发声音与界面告警。资源包共 105 个文件、约 224MB，包含 66 个 Python 源码、4 个 UI 界面文件、训练权重（.pt/.hdf5）、Dlib 模型文件（.dat）、yaml 配置、报警 mp3 音频，以及 run_torch 等一键启动脚本；目录划分清晰，涵盖视频采集、OpenCV 预处理、模型推理、GUI 展示、告警触发与日志记录完整链路。已有 273 人学习下载，适合希望掌握深度学习与桌面应用集成、需要快速搭建可演示课程设计原型的读者，也可作为扩展更多驾驶员状态识别功能的起点。系统整体结构完整，适合用于课程设计答辩与演示。
1. 驾驶员行为监控系统到底在做什么：课程设计版的功能边界
如果你接过"基于PyQt、YOLOv5、dlib的驾驶员行为监控系统"这类课题，第一反应多半是"又是一个把三个热门词拼在一起的课设题目"。但真把它拆开，你会发现它其实是一条完整的视觉处理流水线：dlib负责框出人脸并定位68个关键点，YOLOv5负责检测方向盘、手机、香烟这类物体，PyQt则把这两路检测结果汇总成实时警告界面。课程设计要的不是一个能上车的产品，而是你能把这套流程跑通、讲清楚、调出合理参数。常见做法是只取"疲劳驾驶"作为核心：闭眼、打哈欠由dlib关键点判，玩手机、抽烟交给YOLOv5判，最后用PyQt弹出疲劳等级。这套方案适合自动化、计算机、软件工程专业的课设或毕设，硬件成本只要一台带摄像头的电脑，难点不在模型训练，而在"两套模型如何协同、如何不互相拖垮帧率"。我见过太多人把时间耗在训练自定义YOLOv5模型上，结果界面还停在草稿阶段——这个方向最现实的做法，是把YOLOv5当作开箱即用的检测器，把精力留给逻辑层和UI层。
2. 从课题到可运行系统：用YOLOv5与dlib搭出最小检测框架
拿到课题后，建议先画一张数据流图：摄像头帧先分两路，一路送YOLOv5做目标检测，另一路送dlib做关键点定位，两条线程的结果在PyQt主线程里汇合，再按判定规则输出警告。很多课设翻车就翻在"一路跑完再跑另一路"，帧率直接降到个位数，答辩演示时卡成PPT。这一章先解决单帧处理和组合策略，界面放在下一章。
2.1 为什么是这个组合：两套模型的分工与选型理由
YOLOv5的新版本在COCO预训练权重上能直接识别人、手机、瓶子等80类物体，不需要你重新训练就能覆盖"玩手机"场景。但因为YOLOv5不做关键点回归，你拿不到眼睛、嘴巴的精细坐标，无法算EAR（眼部纵横比）和MAR（嘴部纵横比）。dlib恰好补这个缺口，它的人脸检测器配合68点预测模型能在普通CPU上跑到20~30毫秒一帧，足够支撑疲劳判定。选型上还有一层考虑：dlib的HOG人脸检测对正面人脸很稳，但对大幅转头比较敏感，此时恰好可以把它当作"分心检测"的信号——连人脸都丢了，说明驾驶员注意力大概率不在前方。这套分工比单独用YOLOv5做全套要少写大量训练代码，也比纯dlib方案多了一层物体级检测能力，是课设性价比最高的组合。
如果机器性能允许，也可以考虑用YOLOv8做替换，但课设答辩时老师更关心你对"为什么选这两者"的解释，而不是版本新旧。
2.2 环境准备与依赖安装：PyTorch、dlib与PyQt5的版本配平
环境配置是第一个大坑。建议用Python 3.8或3.9，配合PyTorch 1.13左右，dlib用19.24.x版本。dlib在Windows上直接用pip install dlib经常报CMake编译错误，常见做法是先安装Visual Studio Build Tools的C++生成工具，或者直接使用预编译的wheel包。PyQt5用5.15.x版本即可，注意Python 3.10以上某些PyQt5旧版本会缺少对应cp310的wheel。
# 建议顺序执行，避免依赖冲突 pip install torch==1.13.1 torchvision==0.14.1 --index-url https://download.pytorch.org/whl/cu117 pip install dlib==19.24.0 pip install pyqt5==5.15.9 pip install opencv-python==4.8.0.76 pip install pandas numpy逻辑说明：先装PyTorch是因为它体积最大，且YOLOv5会从torch.hub拉取模型；dlib单独装能第一时间暴露编译问题。--index-url指定CUDA 11.7的轮子源，纯CPU机器可去掉这行，但检测速度会明显下降。opencv-python的版本建议锁定4.8.x，因为新版4.10在某些环境下与PyQt5的QImage转换存在字节序兼容问题。安装完成后运行python -c "import dlib, torch, PyQt5; print('ok')"做冒烟验证。
2.3 加载YOLOv5检测器：用torch.hub而不是克隆仓库
很多教程会让你git cloneYOLOv5仓库，这在课程设计里其实不必要。直接用torch.hub加载官方权重，代码更短且依赖更少。检测器的封装要留出"置信度阈值"和"IOU阈值"两个接口，因为玩手机检测与普通物体检测的最佳阈值不一样。
import torch class YOLOv5Detector: def __init__(self, weights="yolov5s.pt", conf_thres=0.4, iou_thres=0.5): self.model = torch.hub.load("ultralytics/yolov5", "custom", path=weights, force_reload=False) self.model.conf = conf_thres self.model.iou = iou_thres self.class_names = self.model.names def detect_objects(self, frame_bgr, target_classes=(67,)): """返回目标物体中心点列表，默认只检测手机（COCO类别67）""" results = self.model(frame_bgr, size=640) detections = [] for *xyxy, conf, cls in results.xyxy[0].tolist(): if int(cls) in target_classes and conf >= self.model.conf: x_center = (xyxy[0] + xyxy[2]) / 2 y_center = (xyxy[1] + xyxy[3]) / 2 detections.append({ "class": self.class_names[int(cls)], "confidence": conf, "center": (x_center, y_center), "box": [int(v) for v in xyxy] }) return detections逻辑说明：torch.hub.load会从ultralytics仓库加载模型定义，custom参数指向本地权重文件。force_reload=False表示本地缓存存在时直接用，反复加载权重会造成启动卡顿。results.xyxy[0]是形状为[N, 6]的Tensor，每行依次是x1、y1、x2、y2、置信度、类别ID。target_classes=(67,)对应COCO数据集里"cell phone"这一类别，如果以后要扩展检测香烟，就把类别ID加进元组，比如(67, 0)加人，(67,)保持只检测手机。这里故意不放缩放到results.pandas().xyxy，是因为Tensor格式在循环里取值速度更快。
2.4 dlib人脸关键点定位：封装68点检测器并计算EAR
dlib和OpenCV的人脸框坐标体系都是"左上角+宽高"，可以直接互通。dlib需要一张灰度图，检测到人脸后用shape_predictor输出68个关键点，常见做法是把关键点数组转成NumPy矩阵，便于后续计算欧氏距离。注意：dlib的检测器对小分辨率人脸不敏感，如果摄像头距离超过1.5米，人脸像素面积太小，容易出现"时检测到时检测不到"的现象。
import dlib import numpy as np import cv2 class DlibLandmarkDetector: def __init__(self, predictor_path="shape_predictor_68_face_landmarks.dat"): self.detector = dlib.get_frontal_face_detector() self.predictor = dlib.shape_predictor(predictor_path) def get_landmarks(self, frame_bgr): gray = cv2.cvtColor(frame_bgr, cv2.COLOR_BGR2GRAY) faces = self.detector(gray, 1) if len(faces) == 0: return None, None # 取面积最大的人脸，避免远处小脸干扰 main_face = max(faces, key=lambda r: r.width() * r.height()) shape = self.predictor(gray, main_face) points = np.array([(p.x, p.y) for p in shape.parts()]) return main_face, points @staticmethod def eye_aspect_ratio(landmarks, eye_indices): """EAR = 垂直距离均值 / 水平距离，闭眼时数值趋近于0""" left, right = eye_indices[0]], eye_indices[1] vertical = np.linalg.norm(landmarks[left[1]] - landmarks[left[5]]) + \ np.linalg.norm(landmarks[left[2]] - landmarks[left[4]]) horizontal = np.linalg.norm(landmarks[left[0]] - landmarks[left[3]]) return vertical / (2.0 * horizontal)逻辑说明：get_frontal_face_detector(gray, 1)的第二个参数表示图像上采样次数，设为1会先把图像放大一倍再检测，小脸召回率更高但速度变慢。detector返回人脸矩形列表，乘以宽高选出最大人脸，是为了防止后排乘客的脸被错误当成驾驶员。eye_aspect_ratio中eye_indices是包含两个眼睛索引数组的元组，左眼索引为[36, 37, 38, 39, 40, 41]，右眼为[42, 43, 44, 45, 46, 47]，代码里eye_indices[0]代表左眼。这个EAR计算方法源自论文的六个关键点方案，正常平视大概在0.25~0.35，闭眼时跌到0.1以下，阈值通常设在0.2。
3. 用PyQt5把检测结果变成可交互的监控界面
模型层就绪后，需要解决"画面显示、警告弹窗、参数调整"三件事。PyQt5在这里不只做界面，它还要充当线程管理和事件分发的角色。常见错误是在主线程里跑while循环读摄像头，导致界面假死。正确做法是把视频流和检测放进QThread，通过信号把图像和检测结果发回主线程更新控件。
3.1 界面布局与实时视频显示：QThread、QImage与信号槽
建议用三个主要区域：左侧QLabel显示摄像头画面并叠加检测框，右侧用QTableWidget展示当前检测状态（人脸是否缺失、是否是疲劳、是否检测到手机），下面放一个QPushButton用于开始/停止检测。画面不要直接在子线程里操作QLabel，因为Qt的UI操作必须发生在主线程。子线程只管把图像转换成QImage后emit出去，主线程的槽函数负责setPixmap。
import sys import cv2 from PyQt5.QtCore import QThread, pyqtSignal from PyQt5.QtGui import QImage, QPixmap from PyQt5.QtWidgets import QMainWindow, QLabel, QPushButton, QVBoxLayout, QWidget class VideoThread(QThread): change_pixmap_signal = pyqtSignal(QImage) detection_status_signal = pyqtSignal(dict) def __init__(self): super().__init__() self.running = True self.yolo = YOLOv5Detector() self.landmark = DlibLandmarkDetector() def run(self): cap = cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) while self.running: ret, frame = cap.read() if not ret: continue status = self.process_frame(frame) self.detection_status_signal.emit(status) rgb_image = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w, ch = rgb_image.shape bytes_per_line = ch * w qt_image = QImage(rgb_image.data, w, h, bytes_per_line, QImage.Format_RGB888) self.change_pixmap_signal.emit(qt_image.copy()) self.msleep(30) cap.release()逻辑说明：change_pixmap_signal携带QImage是因为QPixmap不能在非主线程创建，而QImage是值类型可以跨线程传递。qt_image.copy()很关键，因为rgb_image.data指向的缓冲在下一帧会被覆盖，不拷贝会出现画面闪烁或花屏。msleep(30)控制帧率到33fps左右，留出时间给界面刷新。detection_status_signal用字典把"是否疲劳""是否分心"等布尔值打包传递，避免为每种状态单独定义信号。跑起来后如果界面卡顿，优先检查是不是在主线程里调用了frame.read()，而不是先怀疑模型太慢。
3.2 叠加检测框与警告状态：把YOLOv5和dlib结果画到同一帧上
YOLOv5返回的坐标是相对于传入帧的像素坐标，dlib的坐标也基于同一帧，可以直接画在同一张图上。建议用不同颜色区分来源：YOLOv5的物体框用红色，dlib的人脸关键点用绿色圆点，疲劳时把眼睛区域用黄色高亮。画完后把这一帧发给UI显示，同时在状态栏用文字提示当前风险等级。
def process_frame(self, frame_bgr): face_rect, landmarks = self.landmark.get_landmarks(frame_bgr) objects = self.yolo.detect_objects(frame_bgr, target_classes=(67,)) status = {"face_detected": face_rect is not None, "phone_detected": len(objects) > 0, "ear": 0.0, "fatigue": False} if face_rect is not None: ear = self.landmark.eye_aspect_ratio(landmarks, EYE_INDICES) status["ear"] = round(ear, 3) status["fatigue"] = ear < EYE_CLOSE_THRESHOLD # 画人脸框 x, y, w, h = face_rect.left(), face_rect.top(), face_rect.width(), face_rect.height() cv2.rectangle(frame_bgr, (x, y), (x + w, y + h), (0, 255, 0), 2) for point in landmarks: cv2.circle(frame_bgr, tuple(point), 1, (0, 255, 0), -1) for obj in objects: x1, y1, x2, y2 = obj["box"] cv2.rectangle(frame_bgr, (x1, y1), (x2, y2), (0, 0, 255), 2) label = f"{obj['class']} {obj['confidence']:.2f}" cv2.putText(frame_bgr, label, (x1, y1 - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 0, 255), 1) return status逻辑说明：process_frame返回的status字典通过信号发给主线程，主线程里的QLabel和表格直接读这个字典刷新。EAR阈值EYE_CLOSE_THRESHOLD建议设为0.2，但是注意：不同人眼型差异很大，戴眼镜和没戴眼镜的EAR基础值不一样。课程设计答辩时最好把阈值做成可调项，否则评委戴上眼镜模拟测试时，系统可能把正常眨眼误判成疲劳。如果你打算跑通"疲劳检测"之外的动作识别，也可以把objects里yk的检测类别扩展成包含香烟（类别ID为74），但COCO里香烟样本少，误检率会比手机高不少，需要额外处理。
4. 疲劳与分心判定逻辑：参数怎么调才能真正"可用"
检测模型只是眼睛，判定逻辑才是大脑。很多系统的翻车点是"检测到了但判定策略太蠢"，比如闭眼超过0.5秒就报警，结果驾驶员正常眨眼也会闹脾气。这一章从状态机和时间窗口两个角度说明怎么设计判定流程，让"监测"变成"监控"。
4.1 疲劳判定不再靠单帧：引入"连续N帧"窗口逻辑
单帧EAR低于阈值只能说明那一刻闭眼，不能说明疲劳。正常眨眼约100~400毫秒，如果摄像头30fps，一帧约33毫秒，所以眨眼也就持续3~12帧。疲劳的特征是闭眼时间显著变长，或者频繁打哈欠。常见做法是把最近30帧的EAR数据缓存起来，统计其中低于阈值的帧占比，超过某一比例才触发疲劳预警。这才符合"眼睑闭合程度"的PERCLOS疲劳评价标准。
from collections import deque class FatigueJudge: def __init__(self, ear_threshold=0.2, window_size=30, closed_ratio=0.3): self.ear_threshold = ear_threshold self.window = deque(maxlen=window_size) self.closed_ratio = closed_ratio def update(self, ear_value, face_missing=False): if face_missing: self.window.append(1.0) # 无人脸按闭眼处理，保守一点 else: self.window.append(1.0 if ear_value < self.ear_threshold else 0.0) closed_ratio = sum(self.window) / len(self.window) return closed_ratio >= self.closed_ratio, closed_ratio逻辑说明：队列长度为30帧，若30帧里有30%即9帧处于闭眼状态，就判定为疲劳。face_missing=True时记录为1.0，是考虑到疲劳时驾驶员头部下垂容易脱离画面，把它当成闭眼处理能减少漏报。window_size的调整逻辑：帧率低时不宜设太大，否则迟缓严重；帧率稳定在30fps时，30帧就是1秒窗口，阈值0.3即累计0.3秒闭眼触发，这个参数接近真实驾驶疲劳监测设备的标准。如果是在树莓派4b上部署YOLOv5，帧率可能掉到10fps，建议把window_size减到15，否则要3秒才能触发一次报警。closed_ratio是核心超参数，答辩时可以现场演示增大到0.6后会明显减少误报，用来展示你对"误报漏报权衡"的理解。
4.2 分心判定逻辑：人脸跟踪丢失与目标检测持续性
分心比疲劳更难定义。常见做法是同时监测三件事：人脸框中心是否长时间偏离画面中心区域，YOLOv5是否在连续帧中检测到手机，人脸是否完全消失超过设定时间。人脸丢失这件事要小心处理——驾驶员偶尔低头看仪表盘也会丢脸，一丢就报警会被当成狼来了。建议为"丢脸"设置独立阈值，例如连续15帧（约0.5秒）无人脸才触发"视线偏离"警告。
另一条主线是手机检测的去抖。YOLOv5单帧检测经常出现"前五帧检测到、第六帧消失"的闪烁现象，原因是置信度在阈值附近抖动。常见做法是维护一个"连续命中帧数"计数器，累计超过5帧才判定"正在使用手机"，并使用更激进的低置信度阈值0.25来保证召回率。但低阈值也会带来误检，所以还要加一个就近原则：手机框中心与人脸框中心的距离必须在200像素内，不然副驾驶玩手机会被误判成驾驶员玩手机。
class DistractionJudge: def __init__(self, missing_threshold=15, phone_threshold=5): self.missing_frame_count = 0 self.phone_hit_count = 0 self.distracted = False def update(self, face_rect, phone_detected, face_center_near_phone=True): if face_rect is None: self.missing_frame_count += 1 self.phone_hit_count = 0 else: self.missing_frame_count = 0 if phone_detected and face_center_near_phone: self.phone_hit_count += 1 else: self.phone_hit_count = 0 if self.missing_frame_count >= 15 or self.phone_hit_count >= 5: self.distracted = True else: self.distracted = False return self.distracted逻辑说明：missing_frame_count与phone_hit_count分两条计数，互不干扰。face_center_near_phone需要由外部根据两个中心点的距离布尔值传入，这样可以把几何判断与状态计数解耦。这里的阈值都是"帧数"而不是"秒数"，答辩时记得强调：监控系统里时间单位用帧是有意的设计，因为不同机器帧率不同，同样的秒数会导致报警灵敏度完全不同；帧计数方案天然与帧率同步。如果摄像头在强光下出现严重拖影，YOLOv5检测手机闪烁得更厉害，此时把phone_threshold提高到8帧，避免误报。
4.3 头顶和掉线的边界：缺帧、无人脸、摄像头被遮挡时的保底策略
课程设计答辩现场最容易翻车的不是算法错，而是摄像头被拔了、画面全黑、人脸角度太偏。典型场景：评委坐得离摄像头很近，把驾驶员人脸挡住，系统瞬间判定为"疲劳或分心"，触发连续报警，场面一度失控。所以保底策略必须和正常人脸逻辑分开写。
常见做法是维护一个"数据健康状态"枚举：相机正常、相机断开、画面黑暗、无人脸超过5秒、人脸正常。这个状态不进疲劳判定逻辑，而是直接显示在界面右上角的状态指示灯里。同时，如果读取帧失败超过1秒，应自动暂停检测线程并弹出提示，而不是继续用上一帧数据硬算。dlib检测器在处理极端侧脸时会返回无人脸，这不算BUG，但要在界面上区分"无人脸（侧面）"和"摄像头断开"两种情况，前者提示驾驶员，后者提示系统管理员。
def check_health(self, ret, frame_bgr, face_rect): if not ret: return "camera_disconnected" gray_mean = cv2.mean(cv2.cvtColor(frame_bgr, cv2.COLOR_BGR2GRAY))[0] if gray_mean < 18: return "scene_too_dark" if face_rect is None: # 超过5秒无人脸由外部计数器决定是否报分心 return "no_face_detected" return "healthy"逻辑说明：gray_mean < 18这个阈值来自经验值，正常室内环境灰度均值约80~150，盖上镜头盖约5~10，阳光直射可能超过200。阈值设18是为了避免夜间行车时系统崩溃，因为夜间路灯下灰度均值也能有30~60。camera_disconnected状态下应停止后续检测模型的调用，因为OpenCV会返回空帧导致dlib抛异常。课设验收时，主动演示"遮挡摄像头→系统提示环境异常"比让评委偶然触发出错要有说服力得多。
5. 课程设计避坑手册：答辩前必须解决的五个实际障碍
写系统只占一半工作量，另一半是排错和适配环境。这里把我在多台机器上跑类似课设时踩过的坑集中列出来，每一条都是"现象→原因→解决"的结构，你不一定全遇到，但遇到时可以直接照方抓药。
5.1 dlib编译失败与"卡死式安装"：别在dlib上浪费太多时间
现象：Windows终端执行pip install dlib后长时间停在Building wheel，最后报错CMake was unable to find a build program。
原因：dlib需要编译C++代码，系统缺VS Build Tools。这不是Python问题，是C++工具链问题。同样的问题也会出现在只装了MinGW但没配环境变量的机器上。
解决：直接下载预编译的.whl文件使用，常见渠道是PyPI的备用镜像或微软维护的dlib-19.24.0-cp38-cp38-win_amd64.whl。如果你用的是Python 3.10，建议先降级到3.8再装，因为部分预编译wheel不覆盖3.10。另一点：装不上dlib时可以退一步用OpenCV的人脸检测器加face_recognition库替代关键点定位，但face_recognition库本身也依赖dlib，换汤不换药，不如直接解决编译问题。
5.2 YOLOv5启动奇慢与torch.hub拉取卡住
现象：程序启动后界面白屏十几秒，日志停在Downloading...或Checking file。
原因：torch.hub.load首次执行会检测缓存，内置的force_reload=False虽不强制下载，但若权重文件路径写错或缓存被清，它会重新从GitHub拉取，墙内网络环境下常常卡住。
解决：训练或首次运行前手动下载yolov5s.pt并放到项目根目录，再将torch.hub.load的cache_dir参数指向本地缓存目录。具体做法是torch.hub.set_dir("./yolo_cache")，这样断网也能跑。如果已经卡住GitHub连接，在工程里额外检查DNS设置，或者把git clone的仓库整个放本地，用torch.hub.load("./yolov5", "custom", path="...")加载本地源码。答辩现场没有稳定外网，这一点务必提前确认。
5.3 PyQt5界面"未响应"：问题出在阻塞主线程
现象：点击"开始检测"后窗口立刻变白，鼠标转圈，几秒后提示"程序未响应"。
原因：把VideoThread里的cap.read()和detect循环直接写在了按钮的槽函数里，主线程被掉进死循环，Qt事件循环无法处理重绘和按键消息。
解决：检查代码里是否所有耗时操作都在自定义QThread的run()方法中，且通过pyqtSignal传数据。常见错误写法是在while循环里调用QApplication.processEvents()来"补救"，这会让界面刷新与检测抢CPU时间，越补越卡。正确做法是子线程msleep(30)，主线程只负责setPixmap，两边的队列交给Qt信号槽机制自动排队。如果仍有间歇性卡顿，检查信号参数是否传递了大尺寸QPixmap而不是小尺寸QImage，图像对象跨线程赋值会触发深拷贝。
5.4 dlib检测框时有时无：摄像头分辨率与采样上采样参数的博弈
现象：同一个场景下，人脸检测框一会儿有、一会儿没有，尤其人离摄像头稍远时。
原因：dlib的HOG检测器对目标最小尺寸有约束，输入图分辨率太低时人脸缩小到难以检出，detector接收的灰度图来自cv2.VideoCapture默认的640x480时效果尚可，但如果你把它缩放成320x240就不行了。
解决：把传给get_landmarks的图像保持640x480或更高，同时把detector(gray, 1)的缩放系数从1提到0（不上采样）来提升速度。如果人脸框确实不稳定，给检测结果加一个"最近人脸位置记忆"：上一帧有框而这一帧突然丢失且间隔小于3帧，就沿用上一帧框的位置继续算关键点，能明显缓解闪烁。注意别用脸部追踪器替代检测器，OpenCV的tracker在长时间运行时会漂移，最后框住背景黑板，场面更尴尬。
5.5 摄像头被占用导致cap.isOpened()为False
现象：程序打开摄像头时直接报错，但单独测试摄像头明明是好的。
原因：Windows下多个进程同时占用同一个摄像头，常见于调试时前一个Python进程没退出，或微信/腾讯会议等软件还占着摄像头通道。
解决：关掉所有可能占用摄像头的软件，在任务管理器里确认没有残留的python.exe。如果通过cv2.VideoCapture(0)打开失败，有一个小技巧：先cap.release()再cv2.destroyAllWindows()，等待0.5秒重试两次。另外，某些笔记本人脸识别驱动会虚拟出多个摄像头索引，cv2.VideoCapture(0)不一定是物理摄像头，申请加一个下拉框选设备索引会显得更专业。
5.6 界面显示花屏/颜色发绿
现象：OpenCV画面在QLabel里显示出绿色或蓝色异常色块，人脸皮肤呈紫红色。
原因：OpenCV的BGR通道顺序和Qt的RGB顺序不一致，没有做颜色空间转换就构造QImage。
解决：构造QImage之前必须cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)，这条代码在第三节代码里已经写了。如果仍花屏，检查bytes_per_line是否用w*3而不是ch*w，元组顺序错误会导致显示图像有斜切感。顺手提一句：不要为了省事直接改cv2的存储顺序，那会导致YOLOv5和dlib的检测结果全都错位。
6. 答辩演示与能力延伸：用"超参数影响分析"和"长时间稳定性"证明你懂的这行
模型跑通、界面能弹窗只是及格线，答辩拿高分靠的是你对自己系统的边界说得出个所以然。这一章重点讲两件事：如何设计一套可复现的验证流程，以及从课设延伸到生产环境要补哪些东西。
6.1 用录制视频而不是摄像头做验收测试
答辩前强烈建议录一段3分钟的视频：包含正常驾驶（睁眼、平视）、闭眼5秒、打哈欠、拿起手机接听、低头看手机五个片段。测试时把VideoCapture(0)替换成VideoCapture("demo.mp4")，把同样的检测代码跑一遍并记录报警帧时间点。这样一个好处是结果可重复，你在答辩时可以随时重放，不用看评委脸色；另一个好处是方便你调整阈值后对比，同一个片段在不同ear_threshold下的表现差异就是你讲"参数如何影响结果"的素材。
# 用视频文件替代摄像头的完整骨架 cap = cv2.VideoCapture("demo.mp4") fps = cap.get(cv2.CAP_PROP_FPS) frame_count = 0 alarm_events = [] while cap.isOpened(): ret, frame = cap.read() if not ret: break frame_count += 1 status = process_frame(frame) if status["fatigue"]: alarm_events.append({ "time_sec": round(frame_count / fps, 2), "type": "fatigue", "ear": status["ear"] }) cap.release() print(alarm_events)逻辑说明：用文件测试时，fps是根据视频元数据读出来的，千万不要硬编码30，因为录屏或手机视频的帧率可能是25或60。alarm_events记录了事件发生的时间点和当时的EAR，答辩时可以列出表格说明系统在第4.2秒首次触发疲劳报警、在第6.5秒停止报警——这种精确到秒的分析能让评委相信你的系统具备真实的监控能力，而不是"演示看起来好像不错"。如果条件允许，可以准备两段视频：一段阈值0.2，一段阈值0.25，对比报警时长的变化，以此展示你在超参数上确实做了实验。
6.2 超参数怎么调才叫"会调"：EAR阈值、置信度阈值与窗口大小
YOLOv5训练自己的数据集是另一个大话题，课设一般不需要走到那一步。但答辩时老师很可能问："你的conf_thres=0.4是怎么来的？"你要能回答：先用results.xyxy打印出所有检测结果的置信度，观察正确检测和误检的分布，选择一个两者重叠最少的值。同理，ear_threshold=0.2不是拍脑袋，而是录下自己平视、眨眼、闭眼时EAR的均值与极值，通常平视0.35、闭眼0.08、眨眼瞬间0.15，取0.2刚好能区分。把这些实验记录整理成一张简单的3行表格放进答辩PPT，比放十张检测截图更有说服力。
# 用一段测试脚本统计EAR分布 python ear_statistics.py --video demo.mp4 --output ear_report.csvear_statistics.py的核心逻辑是把每帧的EAR写入CSV，再用pandas做描述性统计。这里有个小技巧：戴眼镜的人EAR基线会偏高，因为眼镜框边缘有时候会被识别成眼睛轮廓，建议录三段不同人员的视频做均值对比，结论是"阈值需要按人微调，系统里预留了参数接口"。这套思路也能用来解释YOLOv5网络结构图和超参数文档里那些抽象概念——你不需要背出C3模块的结构，但你能说明白自己的系统在哪一层引入了什么误差。
6.3 从课设到"长期现场稳定性"：还差哪几步
如果这个课题要被改造成真正能跑的驾驶监控设备，只靠PyQt程序是不够的。pyqt长期现场稳定性测试这个词背后涉及的是内存泄漏、日志回滚、断线重连、电源异常恢复等等。我在做完课设后做过一次72小时连续运行测试，首日一切正常，第二天开始内存持续增长，最后定位到两个问题：一是QImage.copy()在信号槽里没被及时释放，二是opencv的视频缓冲没有定期清空。解决方法是用weakref封装UI引用，并在每次cap.read()后判断frame是否为None再送入检测；日志模块要用RotatingFileHandler限制体积，否则一晚上日志就能写满一张128G存储卡。如果部署到树莓派4b这类ARM平台，YOLOv5的推理时间会从30ms暴涨到200~300ms，此时需要将window_size从30下调到10，并把检测帧间隔从1改成2，相当于牺牲时间分辨率换取可运行的帧率。yolov5量化rk3568这类边缘端优化，课设阶段不必做，但你要知道：模型从x86换到ARM后，默认浮点权重直接加载会非常慢，需要对模型做INT8量化，同时验证量化后手机检测置信度是否明显下降——这个"部署后精度回调"的思路，本身就是答辩时展示工程素养的好素材。
我在做类似课题时养成了一个习惯：所有调过的参数都写进config.py而不是散落在代码里，跑完测试后把每组参数对应的报警时间点导出成JSON存档。这个习惯在答辩现场帮了大忙——评委问"你试过哪些阈值"时，我能直接调过去对比，而不是支支吾吾说"我大概试了试"。这也是我建议你动手前先建好的"后悔药"机制：参数错了可以回滚，报告里也有据可查，希望帮到你，毕竟课设是拿来学东西的，不只是拿来过的。
本文还有配套的精品资源，点击获取
