简介：这是一套面向驾驶员状态监测的V1.0版本深度学习项目源码，系统核心目标在于解决行车场景中的疲劳驾驶与分心行为识别问题。方案整体包含两大检测部分：疲劳检测部分借助人脸关键点定位技术，计算眼睛和嘴巴的开合指标，进而判断是否存在闭眼或打哈欠，同时利用疲劳程度评估模型量化倦怠水平；危险行为检测部分则基于YOLOv5网络识别玩手机、抽烟、喝水三类常见分心动作，并结合DeepSort多目标跟踪算法提升连续帧判别的稳定性。压缩包内共有五十八个文件，涵盖模型训练脚本、参数配置文件、界面设计文件、预训练权重、人脸关键点模型、演示动画、环境部署配置及说明文档等，整体体积为八十九兆字节，能够为二次开发提供完整的基础环境与可运行样例。当前已有七百二十九人进行学习或下载，适合需要快速搭建驾驶行为预警原型的工程技术人员和高校学生参考。

1. 只做单帧检测的预警系统，为什么必然翻车

驾驶员分心驾驶预警这类项目，最容易犯的错，是拿 YOLOv5 对每一帧画面独立做目标检测，检测到“打电话”“闭眼”就立刻报警。实际跑几天就会发现，误报多到让人想砸设备：驾驶员只是转头看了一眼后视镜，系统报一次“分心”；光线闪了一下，系统又报一次“疲劳”。原因很简单，分心和疲劳是连续的时间行为，不是单帧快照能定义的。打哈欠持续 3 秒，闭眼持续 0.8 秒，低头看手机持续 5 秒，这些都必须依赖跨帧的连续信息来判断，而 DeepSORT 在这个系统里就是用来补上时间维度的。这篇文章按我实际落地这类预警系统的经验，把 YOLOv5 和 DeepSORT 如何分工、数据集怎么标、参数怎么调、坑在哪，一条条讲清楚。

2. 预警系统的完整架构：为什么是 YOLOv5+DeepSORT 的组合

2.1 检测和跟踪的分工边界：为什么危险行为必须看连续动作

YOLOv5 的目标检测是单帧任务，输入一张图，输出所有目标框和类别。它天然不知道“上一秒这个人也在打电话”。如果只凭单帧检测结果做预警，就会出现两个致命问题。

第一是抖动。YOLOv5 对同一个目标的输出不是每帧都稳定的，恰好某一帧漏检或置信度低于阈值，报警就中断。驾驶舱场景里摄像头是固定的，但驾驶员头部转动、手部遮挡、光照突变，都会让检测框忽大忽小，置信度在 0.3 到 0.9 之间跳。第二是语义缺失。“疲劳”这个判断根本上就不是目标检测能独立完成的，它需要知道眼睛开合状态维持了多久。DeepSORT 在这里的作用，是把 YOLOv5 输出的逐帧检测框关联成一条条轨迹，给每个目标一个稳定的身份 ID，并且通过卡尔曼滤波预测下一帧位置，即使某帧漏检，也能靠轨迹延续判断。

DeepSORT 全称 Deep Simple Online and Realtime Tracking，核心由三部分构成：卡尔曼滤波做运动预测，匈牙利算法做检测框和轨迹的匹配，加上一个小的 ReID 特征提取网络做外观重识别。在驾驶员监控场景下，外观特征的作用被弱化，因为驾驶员就一个人，真正吃紧的是运动预测的鲁棒性和轨迹生命周期管理。

我一般会把检测和跟踪的分工边界划得非常清楚：YOLOv5 只回答“这一帧画面里有没有打电话、有没有闭眼、有没有打哈欠”，DeepSORT 只回答“这一系列检测框是不是同一个人、这个人保持这个状态多久了”。预警系统的核心逻辑放在这两者的输出之上。

2.2 三类信号和融合策略：YOLO 分类、人脸关键点、时序状态

完整的分心驾驶预警，通常要融合三类信号。

第一类是危险行为识别，直接由 YOLOv5 的分类分支承担，包括打电话、看手机、喝水、吃东西、伸手拿后排物品等。这类行为有明确的物体和姿态特征，适合用目标检测框来标定。

第二类是疲劳状态识别，包括闭眼、打哈欠、频繁点头。这些如果直接用 YOLOv5 检测整个人脸框，粒度太粗，因为“眼睛闭了”和“嘴巴张开”需要更精细的位置信息。常见做法是先用 YOLOv5 检测驾驶员人脸区域，再在裁剪出的人脸区域里跑一个轻量人脸关键点模型，提取 68 点或 5 点关键点，计算 EAR（眼睛纵横比）、MAR（嘴巴纵横比）和头部姿态角。EAR 低于阈值且持续一段时间，判定为闭眼；MAR 超过阈值且持续一段时间，判定为打哈欠。

第三类是时序状态，由 DeepSORT 维护的轨迹提供。每条轨迹记录目标 ID、类别、出现帧数、连续检测置信度、最近一次位置。判断“危险行为”时，不只是看当前帧类别，而是看这条轨迹连续多少帧保持同一类别。比如“打电话”需要同一条轨迹连续 5 帧以上保持 phone 类别且轨迹存活时间超过 1 秒，才触发报警。这样单帧误检被天然过滤掉。

在这三类信号之上，还要加一个决策级别的融合规则，典型的是状态机。当前没有报警、正在确认、正在报警、报警解除。从检测到报警有一个确认时间窗，这能避免“检测到异常就报警、下一帧正常就撤警”的频繁抖动。

2.3 模块划分与完整数据流

整个系统我拆成 5 个模块，按数据流顺序排列如下。

图像采集模块负责接入摄像头画面，做缩放、帧率控制、ROI 区域裁剪。检测模块负责 YOLOv5 推理，输出目标框、类别、置信度、检测框内的人脸区域。跟踪模块负责 DeepSORT 对检测框的关联，维护轨迹 ID。状态融合模块负责接收每条轨迹的状态，结合关键点指标和持续时间，判断是否进入报警状态。预警输出模块负责把报警信息推送到车载终端或监控平台。

一个 IOU（交并比）阈值决定匹配时检测框和预测框的贴合度，一般设 0.3 到 0.5；置信度阈值决定哪些检测结果被送进跟踪器，一般设 0.4 到 0.6。这两个参数一个在 YOLOv5 后处理阶段，一个在 DeepSORT 匹配阶段，它们是整个系统误报率和漏报率的直接开关。

数据流上每帧的处理顺序是：读帧、YOLOv5 推理、后处理过滤低置信度框、把检测框坐标从 xyxy 转成 xywh 并送入 DeepSORT、DeepSORT 返回轨迹列表、轨迹状态更新、融合判断、输出报警。这套顺序里最怕的是前面检测漏了后面全乱，所以我会在检测模块和跟踪模块之间加一个“轨迹兜底”的缓冲逻辑。

3. 训练自己的检测模型：从数据采集到 YOLOv5 超参数调优

3.1 数据从哪来、标签怎么定

分心驾驶检测模型能用的开源数据集不算少，国内外都有公开的驾驶员行为数据集，但真正落地的项目里，几乎都要补充自采数据，因为公开数据集的拍摄视角、摄像头安装位置和车型座舱布局，与你的实际部署环境大概率不匹配。视角差异对检测模型的影响非常大，侧装摄像头和正装摄像头看到的手部位置完全不同，模型迁移效果很差。

我接触过的项目里，数据来源通常是三个组合：公开数据集做预训练和基础类别学习；自己在实车座舱里录制视频，抽帧后标注；针对夜间、逆光、戴墨镜等特殊工况单独录制。录制时摄像头安装在车内后视镜位置或 A 柱位置，分辨率 1080p，帧率 15fps 到 30fps，覆盖白天、夜间、隧道、雨天。

标签类别的设计要遵循“动作可见、边界清晰”的原则。危险行为类标签我通常设计成这几个：use_phone（打电话）、look_phone（看手机）、drink（喝水）、eat（吃东西）、turn_head（转头），疲劳类标签设计成 closed_eye（闭眼）、yawning（打哈欠）。注意，闭眼和打哈欠的标注对象是人脸而不是整个人体，否则小目标检测难度会急剧上升。

标注格式建议直接用 YOLOv5 默认的 txt 格式，一行一个目标，格式是 class_id, x_center, y_center, width, height，坐标值归一化到 0 到 1。每个类别样本量建议不低于 2000 个实例，且正样本和负样本的比例不能太悬殊。我见过一个项目里 phone 类别有 5 万框，drink 类别只有 800 框，训练出来喝水的漏检率惨不忍睹。

3.2 用 YOLOv5 训练自己的数据集：命令、超参数和判读指标

训练前先把环境配好，这一步是新手最容易卡住的地方。YOLOv5 的依赖主要就是 PyTorch，建议用 conda 建一个独立环境，Python 3.8 到 3.10 都可以，PyTorch 版本根据显卡驱动选，CUDA 版本和 torch 版本必须对得上。我第一次配置时在这里翻过车，torch 装成了 CPU 版本，训练速度慢了几十倍，后来检查 torch.cuda.is_available() 才发现问题。

数据集目录按 YOLOv5 的规范组织，images 和 labels 两个目录，各自分 train、val、test 三个子目录。然后写一个数据集配置文件，内容大致如下：

train: /data/driver/images/train val: /data/driver/images/val test: /data/driver/images/test nc: 7 names: ["use_phone", "look_phone", "drink", "eat", "turn_head", "closed_eye", "yawning"]

nc 是类别数量，names 是类别名称列表，顺序必须和标注文件里的 class_id 对应。这里最容易犯的错是把 names 顺序写错，模型训练出来所有类别全乱。

训练命令按 YOLOv5 官方脚本直接跑：

python train.py \ --data /data/driver.yaml \ --weights yolov5s.pt \ --img 640 \ --batch-size 16 \ --epochs 100 \ --device 0

yolov5s.pt 是 COCO 预训练权重，用它的原因是迁移学习能让模型收敛更快，尤其当你的自采数据量不够大的时候。训练时 YOLOv5 会自动做自适应锚框计算，把默认 anchor 重新聚类到符合你的目标尺寸分布。图片尺寸 640 是精度和速度的平衡点，如果对速度要求更高，可以降到 416，但小目标检测能力会明显下降。驾驶员场景里手部动作、嘴部状态都是小目标，我一般保持 640 不变。

训练完成后，重点看三个指标。一是 val 集上的 mAP@0.5，这个值低于 0.85 说明某类样本显著不够或标注质量有问题。二是每个类别的 PR 曲线，看哪个类别的召回率偏低，召回率低通常意味着该类别样本量不够、遮挡严重、或者背景太复杂。三是混淆矩阵，重点看 use_phone 和 look_phone 之间有没有大量互相误判，这两个类别的动作相似度很高，如果混淆严重，就要考虑合并类别或增加区分性样本。

3.3 YOLOv5 后处理和置信度阈值为什么不能照搬默认配置

训练出的模型在推理时的后处理阶段，有两个阈值直接影响预警系统表现：conf_thres（置信度阈值）和 iou_thres（NMS 时的 IoU 阈值），还有 max_det 决定单帧最多输出多少个检测框。

很多人直接沿用 detect.py 里的默认参数 conf_thres=0.25，放到驾驶员预警场景里就会出问题。驾驶舱场景中打电话、闭眼这些行为的检测置信度分布和通用目标检测不一样，部署时我会先用一组真实场景视频做阈值扫描。做法是把 conf_thres 从 0.25 到 0.7 按 0.05 间隔跑一遍，统计每个阈值下的误报数和漏报数。选阈值的原则是宁可漏报率稍微高一点，也要把误报率压到最低。因为漏报还能靠下一帧轨迹补回来，误报一旦触发声光报警，驾驶员对系统的信任就没了。

后处理部分还要关掉没用的输出。用 YOLOv5 的 export 导出模型时，把端到端推理的 batch size 固定为 1，避免动态 shape 在部署时引入额外开销。如果只检测驾驶员一个目标，max_det 直接设 2 或 3 就行，让后处理少遍历一些框。

这里的核心认知是：后处理参数不是模型训练的一部分，但它是系统体验的一部分。训练时模型自己用默认参数，部署时必须针对实际场景重新标定。

4. 把 DeepSORT 接到 YOLOv5 上：轨迹、状态与预警判定

4.1 DeepSORT 在驾驶员场景下的实际作用，以及改进方向

DeepSORT 在这里不是要做多目标的行人跟踪，它的目标就一个驾驶员，但要稳定跟踪这个人可能出现的姿态变化、快速转头和短暂离开检测区。当驾驶员低头拿东西时，YOLOv5 可能连续几帧检测不到人脸，但 DeepSORT 的卡尔曼滤波器会预测轨迹继续存在，只要在 max_age 允许的帧数内重新检测到目标，轨迹就不中断，预警状态也能延续。

很多人问 DeepSORT 要不要改造，我的看法是：原版逻辑在单目标场景下基本够用，但要改两个地方。第一，ReID 特征提取网络在驾驶员场景里区分度不高，因为目标只有一个人，特征网络反而可能把不同姿态下的同一个人判成不同 ID，这时可以把外观特征匹配的权重调低，甚至直接关闭外观分支，只靠运动预测和位置匹配。第二，DeepSORT 默认的匹配级联逻辑对遮挡后的目标重识别有保护，但驾驶员突然转头导致的检测框位置跳跃，会让马氏距离失效，建议把门控距离阈值放大一些。

如果项目用的是原版 deep_sort_pytorch 实现，改动成本主要在配置参数上，不需要动底层代码。现在很多工业项目也会把 DeepSORT 换成 ByteTrack，因为 ByteTrack 对检测框质量要求更低，在低置信度目标处理上更有优势。但考虑到标题场景里有大量“已有 YOLOv5 部署、想快速加跟踪”的历史包袱，DeepSORT 的资料和代码上手成本还是最低的。

4.2 把 YOLOv5 的检测输出接入 DeepSORT 的代码骨架

这一段给出我在项目里使用的接入代码骨架，核心逻辑是每帧把 YOLOv5 的检测结果交给 DeepSORT 的 update 方法，更新轨迹列表。

import cv2 import torch import numpy as np # 假设 detector 是封装好的 YOLOv5 推理类 # tracker 是封装好的 DeepSORT 实例 detector = load_yolov5_model() tracker = DeepSort(weights="ckpt.t7", max_dist=0.3, max_age=30) cap = cv2.VideoCapture("driver_video.mp4") while cap.isOpened(): ret, frame = cap.read() if not ret: break # 1. YOLOv5 推理，得到检测框、类别、置信度 detections = detector.predict(frame) # 每项为 [x1, y1, x2, y2, conf, cls_id] # 2. 过滤低置信度检测框 conf_threshold = 0.5 detections = [d for d in detections if d[4] >= conf_threshold] # 3. 构造 DeepSORT 需要的输入格式：xywh + conf + cls bbox_xywh = [] confs = [] clss = [] for x1, y1, x2, y2, conf, cls_id in detections: w = x2 - x1 h = y2 - y1 bbox_xywh.append([x1, y1, w, h]) confs.append(conf) clss.append(cls_id) bbox_xywh = np.array(bbox_xywh) if bbox_xywh else np.zeros((0, 4)) confs = np.array(confs) if confs else np.zeros(0) clss = np.array(clss) if clss else np.zeros(0) # 4. DeepSORT 更新轨迹 outputs = tracker.update(bbox_xywh, confs, clss, frame) # outputs 每项为 [x1, y1, x2, y2, track_id, cls_id] # 5. 轨迹状态统计 track_state_map = {} for output in outputs: x1, y1, x2, y2, track_id, cls_id = output track_state_key = (track_id, cls_id) if track_state_key not in track_state_map: track_state_map[track_state_key] = 0 track_state_map[track_state_key] += 1 # 6. 连续帧判定：同一轨迹同一类别累计超过 N 帧才报 alarm_frame = 5 for (track_id, cls_id), count in track_state_map.items(): if count >= alarm_frame: trigger_alarm(track_id, cls_id)

逻辑说明：第 2 步的置信度过滤必须在送入 DeepSORT 之前完成，因为低置信度框会让跟踪器产生大量噪声轨迹。第 4 步是核心， tracker.update 接受检测框列表、置信度数组、类别数组和原始图像，返回带 track_id 的轨迹结果。第 6 步的连续帧计数是整个防误报的关键，只有同一个 track_id 保持同一个 cls_id 超过 5 帧才触发报警。

参数说明：tracker 构造里的 max_dist=0.3 是匹配时的最大距离阈值，值越大越容易把不同目标关联到一起，值越小越容易丢轨迹。max_age=30 表示轨迹在丢失目标后最多保留 30 帧，超过 30 帧找不到匹配目标就删掉轨迹。驾驶员监控场景里，30 帧在 25fps 的摄像头下约等于 1.2 秒，转头后重新回到画面基本不会断轨迹。

4.3 两个必调参数：max_age 和 max_dist

max_age 决定了轨迹的“记忆力”。驾驶员低头、转头，人脸可能消失零点几秒，如果 max_age 设置太小，轨迹马上删除，重新检测到人时又分配一个新 ID，累计帧数全部清零。如果设置太大，人已经下车了，轨迹还占着内存，后续新检测框可能被错误关联到旧轨迹上。我一般先按帧率的 75% 到 100% 来估算，25fps 视频取 20 到 30 之间。

max_dist 决定匹配的严格程度。在驾驶舱这种摄像头固定、目标单一的场景里，运动和位置信息比外观更可靠，max_dist 可以稍微放大到 0.3 到 0.4，减少因姿态变化导致的匹配失败。如果场景是多人网约车，前座后座都有乘客，目标数量和遮挡复杂度上升，max_dist 就必须收紧到 0.2 以下，否则不同乘客之间会频繁串 ID。

这些参数没有固定值，停车调试时必须拿一段包含正常驾驶、打电话、打哈欠、转头、遮挡的连续视频，跑一遍看轨迹 ID 的变化曲线。如果发现 ID 频繁跳变，先看 max_age；如果发现两个目标被绑定成一条轨迹，先看 max_dist。

5. 预警系统避坑：5 条血泪经验

5.1 误报集中在 3 秒内：轨迹确认机制没做好

现象：系统在驾驶员只是摸了一下嘴、揉了揉眼睛时频繁报警，单次报警持续不到 3 秒就自动消失，驾驶员被吓一跳。

原因：单帧检测的置信度不稳定，加上 YOLOv5 把“手靠近嘴”识别成“喝水”，但下一帧又恢复正常，预警逻辑只要检测到就立即响应。

解决：所有报警必须加确认机制。确认条件有两个维度，同一 track_id 保持同一 cls_id 连续超过 N 帧，且轨迹存活时间超过 T 秒。N 通常取 5 到 10 帧，T 取 1 到 2 秒。把这两个条件做成可配置项写入配置文件，实测时按误报率调整。

5.2 夜间和逆光下检测能力断崖下跌

现象：白天 mAP 有 0.9 的模型，到了夜间隧道环境下漏检率超过 30%，闭眼检测基本失效。

原因：训练数据里白天样本占绝对大头，夜间样本不足。摄像头在弱光下的自动增益导致画面噪点增多，YOLOv5 的检测特征被噪声干扰。逆光时驾驶员面部整体过暗，检测框能出来但置信度极低。

解决：采集数据阶段就按光照工况分开建目录，白天、夜间、隧道、逆光各占一部分。训练时加入数据增强，重点是亮度扰动、对比度扰动和随机噪声。部署阶段不要在原始图像上直接推理，先做一次轻量的自适应直方图均衡化。另外夜间场景可以切换红外摄像头，红外下驾驶员面部特征比可见光清晰得多，但要注意红外图像的色调偏移会让白天训练的模型失效，必须单独微调。

5.3 打哈欠被误判成说话

现象：驾驶员正常说话时嘴巴张合较大，系统交替报“打哈欠”，误报率极高。

原因：MAR 阈值设得太低，且判定窗口太短。嘴部张开的幅度在说话和打哈欠之间有大量重叠，仅靠嘴巴张开高度无法区分，必须结合持续时间判断。一次打哈欠通常持续 3 到 6 秒，而说话时嘴部张合是短促且高频的。

解决：MAR 判定需要两个条件，嘴部打开的累计时间超过 1.5 秒，且在这个时间段内没有检测到短促的闭合动作。实际逻辑可以是：连续 15 帧 MAR 超过阈值，且这 15 帧中嘴部开合次数小于 2 次，才判定为打哈欠。说话时嘴部会不断闭合，开合次数指标能有效把说话和打哈欠分开。

5.4 驾驶员大角度转头后轨迹 ID 丢失

现象：驾驶员转头看右侧盲区超过 2 秒，再转回正面时，系统把同一个人识别成新 ID，已经累计的报警计数清零。

原因：DeepSORT 的 ReID 特征在大角度面部变化下区分能力不足，且当人脸检测框消失时间超过 max_age，轨迹被删除，重新检测时只能新建轨迹。

解决：两个方向同时做。一是调大 max_age，让轨迹在目标短暂消失时保留更久，我通常设到 45 帧左右。二是改进 ReID 特征，把原版外观特征替换成更鲁棒的 ArcFace 特征，但这需要额外的人脸识别训练数据。如果项目时间紧，最实用的方案是增加一个“位置先验”：驾驶员座椅位置基本固定，目标消失再出现时，如果新轨迹的起始位置和旧轨迹的最后位置距离在 50 像素以内，就把轨迹 ID 继承下来。

5.5 标注数据不干净，模型训练起来很痛

现象：模型训练完 mAP 很高，但实际场景里频繁漏检，细看发现某个类别的训练标签大量标错，比如把“看手机”标成了“打电话”，把“揉眼睛”标成了“闭眼”。

原因：分心驾驶行为本身有很强的连续性，抽帧标注时如果没有视频上下文，单帧画面上手拿手机和手贴近耳边很容易混淆，标注员只能靠猜。

解决：标注阶段要求标注员必须看连续帧，不能只看单帧图片判断。每张标注帧要附带前后 5 帧的缩略图作为辅助判断。训练完成后做一次“标签清洗”：把训练集预测结果和标注框比对，找出置信度低但标注存在的框，人工复核。这个清洗过程能筛掉相当比例的错误标签，清洗后模型精度提升往往比换网络结构还明显。

6. 部署与验收：用一段连续视频判断系统能不能用

6.1 三个验收指标和一个表

模型训练完了、跟踪接上了、阈值也调了，最后必须回答一个问题：这套系统到底能不能用。我不会看单帧 mAP，而是用一段 20 分钟真实驾驶视频做整体验收。视频里预先人工标注好所有报警事件的起止时间，然后跑完整推理流程，统计三个指标。

第一个是事件检出率，系统正确报警的事件数占人工标注事件总数的比例，要求不低于 85%。第二个是误报次数，报警了但人工标注里没有对应事件，理想情况下 20 分钟不超过 3 次。第三个是报警时延，从事件真正发生到系统发出报警的时间差，分心驾驶场景要求在 3 秒以内。

记录格式我固定用下面这个表：

一张表拉完，系统的真实水平就藏不住了。漏报集中在哪几类事件，误报集中在哪个时间段，都能定位到具体模块。

6.2 验证时的一个具体技巧和我的验收习惯

最后说一个我常用的验证技巧：报警日志里一定要带 track_id 和置信度。没有 track_id 的报警日志没法回溯是同一个目标连续报警还是多个目标各自报警，置信度记录则能帮你判断是降低阈值还是加强确认逻辑。我会在推理代码里把每一帧的检测框、置信度、track_id、报警状态全部写成 CSV，出问题时用表格软件筛一遍就能定位到是检测问题还是跟踪问题。

模型导出方面，我现在的习惯是训练完先跑完上面的验收表，确认逻辑没问题，再做模型压缩和部署。压缩顺序是：先用 ONNX 做第一层导出，再用 TensorRT 做 FP16 或 INT8 量化。量化后必须重新跑一遍验收表，因为 INT8 量化对小目标检测的精度损失明显，有时 mAP 只降 1%，但闭眼漏检率翻倍。

部署目标平台如果是车载嵌入式设备，内存和算力受限，YOLOv5 的模型规模也要压缩。我用的最稳妥方案是 yolov5n 或 yolov5s 配合 TensorRT FP16，实测 1080p 输入裁剪到 640 后，可以跑在 30fps 以上。盲目选 yolov5x 只会让设备发热降频，体验远不如小模型加流畅的帧率。

这套东西我做了几轮之后，最大的教训是：预警系统的瓶颈永远不在检测精度，而在对误报的容忍度。驾驶员可以接受偶尔漏报，但不能接受频繁误报，一次误报就可能让整个系统被关掉。所以验收表的误报次数这一列，永远是我第一个看的数字。把这条记住，能帮你少走很多弯路，希望帮到你。

本文还有配套的精品资源，点击获取