简介YOLO11-DeepSORT驾驶员疲劳检测与跟踪系统资源包面向智能驾驶安全、车联网及计算机视觉方向的研究者和工程师解决驾驶途中疲劳状态实时监测与预警问题。方案融合YOLO11目标检测与DeepSORT多目标跟踪算法可对面部特征、眼睛闭合程度及头部姿态进行持续检测与追踪并形成连续轨迹提升预警稳定性。压缩包内共93个文件以Python脚本.py/.pyc、预训练模型.pt、.t7、YAML配置、JPG/PNG示例图、MP4演示视频及PDF运行步骤说明为主体积181.01MB。其中含训练好的yolo11n.pt与DeepSORT权重ckpt.t7无需重新训练即可直接调用附带带标注的驾驶员疲劳数据集覆盖不同光照、角度与表情场景便于二次训练与泛化验证。资源包还提供完整运行步骤文档和演示视频已吸引69人学习查看适合具备一定深度学习基础、希望快速搭建驾驶疲劳预警原型的开发者使用。1. YOLO11-DeepSORT驾驶员疲劳检测一个开箱即用的驾驶预警系统不止是毕设如果你手头正好有一个叫“YOLO11-DeepSORT驾驶员疲劳检测和跟踪”的项目包里面带数据集、训练好的检测模型那你大概率已经在接触当前最主流的一条驾驶员监测技术路线用YOLO11检测人脸、眼睛和嘴部用DeepSORT把检测结果跨帧关联成轨迹再结合PERCLOS等规则判断疲劳状态。它能解决的问题很具体——驾驶员闭眼、打哈欠、低头这三个危险动作的实时识别和预警。适合三类人做毕设的学生、要快速验证方案的工程师、想把疲劳监测模块塞进现有ADAS系统的开发团队。这篇文章把这条链路从头拆到尾给出能直接复现的命令和参数也告诉你哪里容易翻车。2. 先把原理立住YOLO11负责“看见”DeepSORT负责“不跟丢”疲劳判定靠规则2.1 检测和跟踪为什么要拆成两步单帧检测在“眨眼”时最容易丢目标很多人第一次看到这个项目标题会问YOLO11不是已经把眼睛和嘴检测出来了吗为什么还要接一个DeepSORT直接让YOLO11逐帧输出框不就行了问题恰恰出在“逐帧”上。疲劳判定需要的是连续时序而不是孤立的几帧。摄像头在车内的安装位置通常偏低、偏斜光线变化大驾驶员戴眼镜、低头、转头都会让单帧检测的置信度突然掉到0.3以下。如果你只依赖单帧检测闭眼那一瞬间人脸框往往会丢失连续闭眼帧数就统计不上来而PERCLOS恰恰需要的是“闭眼帧数/总帧数”。更麻烦的是没有跟踪就没法稳定绑定ID前一秒这个人脸还是A下一秒检测框跳到旁边就变成B疲劳数据全乱。DeepSORT做的事就是跨帧关联。它对你每个检测框做外观特征提取和运动预测上一帧驾驶员在位置(100, 200)这一帧摄像头震了一下检测框质量变差但卡尔曼滤波可以根据历史速度预测出当前位置仍然把ID绑住。等到下一帧检测正常了再重新修正轨迹。这就是“检测负责看见跟踪负责记住”。所以这条链路里的核心不是单个模型有多强而是检测和跟踪的配合。YOLO11把每一帧里“人脸、睁眼、闭眼、张嘴、闭嘴”这些类别找出来DeepSORT把同一个人跨帧串成一条轨迹最后在轨迹层面统计疲劳指标。这样即使某几帧检测被遮挡、模糊疲劳判断也不会断。2.2 疲劳指标怎么算PERCLOS、打哈欠频率和头部下坠三者配合疲劳监测系统不是“看到闭眼就报警”那样误报率会高到没法用。行业内最通用的做法是用多个指标做规则融合我这里讲最常见的三个。第一个是PERCLOS即眼睛闭合时间比例。工程实现上用的是P80标准眼睑遮住瞳孔超过80%就算一帧闭眼然后统计滑动窗口内闭眼帧数占比。窗口一般取60秒阈值设为0.4也就是一分钟里24秒以上是闭眼状态就判定为疲劳。但连续闭眼更危险所以多数系统会叠加一个“短时间内连续闭眼帧数”计数器比如10秒内连续闭眼超过30帧按30帧/秒算即1秒直接触发预警。第二个是打哈欠频率。哈欠表现为嘴部张开且持续一段时间可以用嘴部纵横比MAR来衡量原理和眼睑纵横比EAR类似。计算嘴部关键点的纵向距离除以横向距离连续15帧以上MAR大于0.6记作一次哈欠5分钟内超过3次判定为疲倦倾向。第三个是头部下坠。驾驶员疲劳时的典型动作是点头、低头。工程上可以用人脸检测框中心的垂直坐标变化来判断连续若干帧人脸中心y坐标下降超过一定像素且后续没有恢复则认为是低头。有些方案会用头部姿态估计模型输出俯仰角但在这个项目里用YOLO11的人脸框位置做近似就够用了。这三类指标在代码里会被组合成一个优先级连续闭眼 低头 哈欠频率。只要其中一个触发就写一条预警日志并调用声音提示。注意这些阈值一定要暴露成配置文件因为不同摄像头的帧率和安装角度对数值影响很大写死的话换个环境就翻车。2.3 数据集与训练好的检测模型直接用还是重新训练取决于你的摄像头角度项目包里的“数据集”通常是把驾驶场景视频按帧抽出来用LabelImg或X-AnyLabeling标注成YOLO格式。类别一般是五个或六个face、eye_open、eye_close、mouth_open、mouth_close有的会加上phone。训练好的检测模型则是拿这个数据集跑YOLO11得到的权重文件常见的是PyTorch的.pt格式推理端可能还有TensorRT的.engine格式。拿到手的第一步不是急着搭环境而是先检查数据集的类别分布。常见做法是写一个脚本统计每个类别的框数量顺便看看标注框尺寸分布因为我见过不少项目包里“eye_close”这类样本只有几百张其他类别上万张类别不均衡直接导致闭眼漏检。import os from collections import Counter label_dir dataset/labels # YOLO格式的txt标注目录 cls_names {0: face, 1: eye_open, 2: eye_close, 3: mouth_open, 4: mouth_close} cls_counter Counter() obj_counter 0 for f in os.listdir(label_dir): if not f.endswith(.txt): continue with open(os.path.join(label_dir, f), r, encodingutf-8) as fp: for line in fp: parts line.strip().split() if not parts: continue cls_id int(parts[0]) cls_counter[cls_id] 1 obj_counter 1 print(f总标注框数: {obj_counter}) for cls_id, cnt in sorted(cls_counter.items()): print(f{cls_names.get(cls_id, cls_id)}: {cnt} 框)这个脚本的核心是用Counter统计每个类别的出现次数因为YOLO格式每行是“class cx cy w h”第一个字段就是类别id。逻辑说明类别id和名称的对应关系一般写在data.yaml里别靠猜。参数说明如果你发现eye_close数量远少于其他类别那这个“训练好的检测模型”在闭眼状态下的泛化能力就要打折扣最稳妥的办法是把视频里闭眼片段再补抽几帧用半自动标注工具补一批数据重新训练。至于训练好的模型能不能直接用要看你的摄像头视角和训练集视角差多少。同一个模型装在挡风玻璃正上方和装在仪表盘右侧人脸的角度、遮挡、光照完全不同。我一般会先用训练好的模型跑一段我自己的摄像头视频如果检测框在多数帧上稳定就继续用如果漏检率超过两成就不要硬扛重新训练一个YOLO11模型。别迷信“训练好的”这三个字它只在和你场景相似的前提下才成立。3. 跑起来从解压到实时预警的完整落地过程3.1 环境搭建Python、CUDA和两个核心依赖的版本搭配这个项目的环境依赖说简单也简单说坑也坑。最核心的是两套东西跑YOLO11的ultralytics包和跑DeepSORT的deep_sort_realtime或自己编译的deepsort。我建议直接使用deep_sort_realtime这个开源包因为它不需要编译caffe或torchreid少踩很多坑。环境版本上Python请用3.9到3.11之间的版本CUDA对应11.8或12.1PyTorch装2.x。不要装最新的Python 3.12ultralytics和deep_sort_realtime的某些依赖索引在3.12上容易翻车。如果你只有CPU机器也可以跑只是帧率会掉到个位数调试代码够用实时预警不现实。conda create -n fatigue python3.10 -y conda activate fatigue pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics deep-sort-realtime opencv-python numpy命令逻辑第一行创建隔离环境避免和你其他项目打架。第二行指定安装CUDA 11.8编译的PyTorch这里不要装CPU版否则后面DeepSORT的矩阵运算慢得让你怀疑人生。第三行一次性装齐YOLO11、DeepSORT库和其他基础依赖。参数说明deep-sort-realtime这个名字在PyPI里是带短横线还是下划线安装时用短横线import时用下划线别记混了。装完之后验证一下打开Python输入import torch; print(torch.cuda.is_available())输出True就说明GPU可用。我见过一半以上的环境问题都出在PyTorch装成了CPU版但自己不知道所以这步检查别省。3.2 拿到训练好的检测模型先跑通单张图片检测环境就绪后先用一张图片验证训练好的检测模型能不能正常加载。这个项目里的模型文件一般是best.pt或last.pt放在weights目录下。单张图片推理是排查问题最快的路径如果这一步都出错就别急着接摄像头。import cv2 from ultralytics import YOLO model_path weights/best.pt img_path sample.jpg model YOLO(model_path) results model.predict( sourceimg_path, conf0.3, imgsz640, verboseFalse, ) for r in results: boxes r.boxes.xyxy.cpu().numpy() # 像素坐标的检测框 classes r.boxes.cls.cpu().numpy().astype(int) confs r.boxes.conf.cpu().numpy() for box, cls, conf in zip(boxes, classes, confs): x1, y1, x2, y2 [int(v) for v in box] print(f类别{cls} 置信度{conf:.2f} 坐标({x1},{y1},{x2},{y2})) cv2.rectangle(img, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.imwrite(sample_out.jpg, img)这个脚本的逻辑分三段第一段创建YOLO对象并加载权重第二段传图片进去推理得到的结果是一个Results对象里面的boxes.xyxy是左上右下角的像素坐标cls是类别idconf是置信度第三段把框画到图上并保存。参数说明conf0.3是检测置信度阈值调低能减少漏检但会增加误检imgsz640是输入分辨率如果原图很大改成800能提升对小眼睛、嘴部的检测代价是推理变慢。跑通之后把sample_out.jpg打开用肉眼看框的位置对不对。常见问题是框只框住了人脸但眼睛和嘴的框没出来——这说明训练的类别可能只有face或者眼睛/嘴的置信度低于阈值。这时候把conf降到0.1再跑一次如果出来了说明模型能检测只是置信度偏低如果还是什么都没有就得检查模型本身了。3.3 接上DeepSORT逐帧检测到轨迹跟踪的代码骨架这是整个项目最核心的一段代码。你要做的就是把YOLO11的检测结果转换成一个DeepSORT能吃的格式然后逐帧更新。deep_sort_realtime的update接口要求传入一个列表每个元素是[left, top, right, bottom, confidence, class_id]坐标是像素值且不能是归一化的否则卡尔曼滤波的位置预测会完全错乱。import cv2 from ultralytics import YOLO from deep_sort_realtime.deepsort_tracker import DeepSort model YOLO(weights/best.pt) tracker DeepSort(max_age30, n_init3, nn_budget100, override_track_classNone) video_path driver_01.mp4 cap cv2.VideoCapture(video_path) out cv2.VideoWriter(driver_01_out.mp4, cv2.VideoWriter_fourcc(*mp4v), 30, (int(cap.get(3)), int(cap.get(4)))) detections [] prev_positions {} while cap.isOpened(): ret, frame cap.read() if not ret: break results model.predict(sourceframe, conf0.3, imgsz640, verboseFalse)[0] boxes results.boxes.xyxy.cpu().numpy() confs results.boxes.conf.cpu().numpy() class_ids results.boxes.cls.cpu().numpy().astype(int) detections [] for box, conf, cls_id in zip(boxes, confs, class_ids): x1, y1, x2, y2 [float(v) for v in box] detections.append([x1, y1, x2, y2, conf, cls_id]) tracks tracker.update_tracks(detections, frameframe) for track in tracks: if not track.is_confirmed(): continue track_id track.track_id ltrb track.to_ltrb() # [left, top, right, bottom] x1, y1, x2, y2 [int(v) for v in ltrb] # 记录每个人脸的持续信息用于后续疲劳统计 prev_positions[track_id] [(x1 x2) // 2, (y1 y2) // 2] cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText(frame, fID:{track_id}, (x1, y1 - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2) out.write(frame) cap.release() out.release()这段代码的逻辑很直白每一帧先用YOLO11检测然后把所有框连同置信度和类别id一起传给tracker.update_tracks。DeepSORT内部会先做级联匹配再对未匹配上的检测框初始化新轨迹最后返回维护中的轨迹列表。参数说明max_age30表示一个轨迹最多能连续丢失30帧不被删除这个值越大ID越稳定但可能导致消失的人脸迟迟不释放n_init3表示轨迹至少要连续确认3帧才会被标记为confirmed太低的n_init会让短暂噪声框变成假轨迹nn_budget100是外观特征队列的大小数值越小越省内存但ID Switch概率会上升。这里有个容易踩的坑detections里如果传了class_idDeepSORT会按类别做外观特征区分。如果你的YOLO11模型同时检测face和eye两类框会在同一帧里出现建议把detections列表里只放face类的框或者把类别id映射到统一值否则DeepSORT会把同一张脸上的眼睛和嘴巴也当成独立目标跟踪产生一堆幽灵ID。3.4 预警触发与记录是弹窗、声音还是写日志配置优先级跟踪拿到stable轨迹后下一步就是从轨迹上提取疲劳状态。这个项目的“预警”不是随便写个if判断而是要设计成可配置的模块。我一般会用一个疲劳判断类输入每个track近60帧的检测置信度序列输出是否预警。class FatigueDetector: def __init__(self, perclos_threshold0.4, close_frames_alert30): self.perclos_threshold perclos_threshold self.close_frames_alert close_frames_alert self.eye_close_frames {} def update(self, track_id, is_eye_close): if track_id not in self.eye_close_frames: self.eye_close_frames[track_id] [] self.eye_close_frames[track_id].append(int(is_eye_close)) frames self.eye_close_frames[track_id][-60:] # 滑动窗口60帧 close_ratio sum(frames) / len(frames) if close_ratio self.perclos_threshold: return perclos_alarm consecutive max(self._consecutive_ones(frames) or [0]) if consecutive self.close_frames_alert: return continuous_close_alarm return normal staticmethod def _consecutive_ones(arr): counts, cur [], 0 for v in arr: if v: cur 1 else: if cur: counts.append(cur) cur 0 if cur: counts.append(cur) return counts逻辑说明这个类用滑动窗口保存每帧眼睛是否闭合的状态闭眼状态怎么来在上一节DeepSORT跟踪到的每个人脸框内部再运行YOLO11的eye_close检测或者直接用模型输出的eye_close类别置信度作为输入。参数说明perclos_threshold0.4就是前面讲的PERCLOS阈值close_frames_alert30表示连续闭眼30帧约1秒直接触发。这两个参数要放在配置文件里因为摄像头帧率不同30帧的实际时长完全不同。预警输出优先级我个人建议写日志 声音提示 弹窗。弹窗在真实驾驶场景里反而最危险因为司机低头看弹窗本身就是分心。代码里预警时调用logging.warning(track %s: perclos alarm, track_id)同时用winsound.Beep(1000, 500)发出提示音这样事后复盘也有据可查。4. 避坑笔记驾驶员疲劳检测项目最常见的5个翻车现场4.1 现象模型检测正常但跟踪框乱跳ID频繁切换这是接DeepSORT后最常见的翻车。明明是同一个驾驶员几秒内ID从2跳到7人脸上同时叠了好几个框。原因有两个一是输入DeepSORT的检测框坐标和原图分辨率不一致比如YOLO11推理时imgsz640但原图是1920x1080你直接把640尺寸下的坐标传给DeepSORT导致卡尔曼滤波的位置预测错乱。二是检测框质量不稳定conf阈值设太低比如0.15导致同一个眼睛位置产生多个噪音框。解决确认传给DeepSORT的坐标一定是原图坐标。YOLO11在predict时如果不传原图返回的坐标是相对于模型的输入尺寸的需要乘以缩放系数还原。我在上节代码里直接用原始frame推理所以results的坐标就是原图坐标这一步不能省。另外conf阈值建议不低于0.25宁可漏几帧也比一堆假轨迹强。4.2 现象加载训练好的检测模型后每个目标都漏检你拿的是项目包里“训练好的检测模型”但一跑连人脸都检测不到。最常见的原因是类别id没对上。那个模型是用数据集的类别训练出来的它的类别0可能是face而你的脚本里类别0是eye_open而且你只画了eye_open的框当然什么都画不出来。解决用前面那个统计脚本把数据集的类别映射找出来然后加载模型后打印model.names看看当前模型实际识别的类别名。如果和你的预期不一致直接把model.names的值对照着改不要试图去改模型权重。另一个原因是模型是TensorRT的engine格式必须在同样的GPU型号和TensorRT版本上加载换成电脑可能直接报错这种情况就去项目包里找有没有.pt原版权重。4.3 现象GPU占用率上不去只有20%帧率还不到15很多人以为用了GPU就万事大吉结果跑起来GPU占有率还不如CPU高。原因大概率是视频读取和预处理变成了瓶颈进程在等CPU解码视频帧。疲劳检测这种场景一般用摄像头或视频文件Opencv的VideoCapture默认把解码放在主线程一帧一帧阻塞GPU自然闲得慌。解决最简单的办法是生产者消费者模式一个线程用VideoCapture读帧放进队列另一个线程从队列取帧交给YOLO11推理。队列长度控制在一定范围内比如32避免内存暴涨。另外把YOLO11的imgsz从640改成480推理时间差不多能降三分之一对眼睛这种小目标影响不大但对帧率改善非常明显。import queue, threading, cv2 q queue.Queue(maxsize32) def reader(cap): while cap.isOpened(): ret, frame cap.read() if not ret: q.put(None) break q.put(frame) cap cv2.VideoCapture(driver_01.mp4) t threading.Thread(targetreader, args(cap,), daemonTrue) t.start() while True: frame q.get() if frame is None: break # 推理和跟踪逻辑照常这段代码的逻辑是创建了一个读帧线程把视频帧预读进队列主线程拿帧的速度不再被解码速度拖累。参数说明队列maxsize32是缓冲区上限太大内存会涨太小线程切换频繁32在大多数机器上是平衡点。4.4 现象闭眼状态明明有疲劳预警却死活不触发我调试过一个项目视频里驾驶员明显闭眼两三秒系统毫无反应。把frame里的检测结果打印出来发现闭眼帧检测到了但类别id是2而疲劳判断代码里写死了判断“eye_close”没看label映射于是逻辑永远进不去。另一个更隐蔽的原因是眼睛检测框和闭眼置信度是分离的眼睛检测框还在但内部闭眼类别的置信度可能被嘴巴类别挤掉了。解决是在触发预警时做多条件保障只要眼睛区域检测框存在且eye_close的置信度大于0.5就计一帧闭眼如果eye_close没检测到但eye_open置信度也远低于阈值也可视为疑似闭眼。疲劳判定不能只依赖单一类别的结果。4.5 现象打包给别人运行报“No module named torch”等一堆错项目跑通了你想打包成exe或放在另一台电脑上结果对方双击运行直接黑屏或报ModuleNotFoundError。这基本都是因为conda环境没有完全打包PyTorch这种大包依赖特别容易丢。解决不要太依赖PyInstaller自动收集依赖我建议在requirements.txt里把所有依赖写死版本然后给对方一个一键安装脚本让他自己装conda环境。如果你真想打包exe不要用conda环境直接打包新建一个干净虚拟环境只安装运行所需依赖然后用PyInstaller加--collect-all ultralytics和--collect-all deep_sort_realtime。就算这样打包出来的exe体积也会超过2GB而且启动慢所以最靠谱的交付方式是源码加脚本这也是这类项目包最常见的形态。5. 进阶调优从“能跑”到“敢用”的关键改动5.1 yolo11改进的方向眼睛和嘴部这类小目标为什么容易漏检原始YOLO11的neck层对80x80以上的目标效果很好但眼睛和嘴部在640分辨率下往往只有20x20甚至更小。如果你发现数据集里大量目标的宽度小于32像素就要考虑给YOLO11加一个更浅的检测头把输入分辨率从640提升到800或者把SPPF模块改成SPPCSPC以增强小目标特征聚合。常见做法是在yaml配置里增加一个P3级别的输出层并把anchor或动态anchor的目标尺度适当调小。这一改动会牺牲约20%的帧率但对闭眼、哈欠的召回率提升显著。另外把Face和eye_open合并成统一人脸检测再单独检测eye_close和mouth_open可以减少漏检的传递。5.2 DeepSORT参数调整max_age、n_init和iou_threshold怎么配合DeepSORT并不是安装后就能用好的黑盒。我见过很多人在真实场景里把max_age调到100认为ID会稳定结果是驾驶员转头回来后重影ID一大堆。原因是max_age过大旧的轨迹状态一直没有消亡重新出现的人脸和旧轨迹竞争导致ID漂移。合适的一组起点值是max_age30、n_init3、iou_threshold0.3如果你发现ID切换频繁优先调高max_age到40而不是调低如果你发现轨迹延迟太长则调低max_age到20。iou_threshold是检测框和预测框匹配时IoU的最低要求太高会导致同一目标被两次匹配太低会导致漏匹配建议维持在0.3附近。这些参数每次只动一个改完跑同一段视频统计ID切换次数否则你根本不知道是哪项改动起了作用。5.3 验证方法用一段带标准答案的视频统计误报率和漏报率调优之前一定要有验证基准。我建议从原始视频里截取3段每段5分钟覆盖白天、逆光、戴眼镜三种场景然后人工标注每一秒属于“正常、闭眼、哈欠、低头”。运行系统后对比输出统计误报率和漏报率。一个能实际部署的系统至少要达到漏报率低于10%误报率低于5%。如果你的误报率高先把PERCLOS阈值从0.4提高到0.45如果漏报率高优先把眼睛检测分辨率加大而不是盲目调跟踪参数。疲劳监测这东西宁可少报也不能乱报因为误报会让驾驶员在十分钟内就关掉系统这是我在调过几次现场后总结的一条血泪经验。验证的时候还有一个技巧对同一段视频跑三次取每次的疲劳事件数量平均值。因为DeepSORT的随机性会让结果有轻微波动如果三次结果相差超过两倍说明跟踪没调好先去解决ID切换问题再回来谈疲劳判断。希望这套调优路径能帮到你少走我当年走过的弯路。本文还有配套的精品资源点击获取