尧图网站建设 
简介一套基于YOLOv5DeepSort的驾驶员分心驾驶行为预警系统面向疲劳驾驶与危险动作实时监测场景可服务于智能座舱研发、车队安全管理及交通安全课题研究。工程集成目标检测、多目标跟踪、人脸关键点提取与UI界面提供从模型推理到结果展示的完整闭环。资源共59个文件约110.69MB20个Python脚本覆盖检测、跟踪、疲劳判定、主窗口逻辑等核心模块18个YAML文件描述YOLOv5系列网络结构与训练参数另含预训练权重、68点人脸关键点模型、UI布局文件、Dockerfile部署配置、演示视频与说明文档代码组织清晰易于二次开发。已有50人学习下载。对于希望快速搭建驾驶行为预警原型、了解YOLOv5工程化落地流程的开发者它能提供可运行的直接参考。1. 分心驾驶预警系统为什么必须用“检测跟踪”两条腿走路驾驶员分心驾驶预警系统摄像头通常装在A柱或仪表盘上方画面里同时出现人脸、手部、手机、香烟和水杯。如果只用单帧目标检测结果会像抽帧一样抖动同一部手机在第12帧被检测到、第13帧消失、第14帧又出现误报率高到没法用。可靠的做法是让YOLOv5负责“识别对象”DeepSORT负责“盯住对象”把单帧检测结果串成轨迹再从轨迹里提取行为持续时间和空间变化。这套系统解决的不是“有没有玩手机”而是“玩手机持续了多久、视线离开路面多久、闭眼频率是否上升”。适合正在搭建车载DMS、做驾驶行为分析、以及想把深度学习模型放到嵌入式设备上的工程师。一个反直觉的结论是预警系统的精度瓶颈往往不在模型分类而在跟踪稳定性。2. YOLOv5分层检测先解决“看见什么”再谈行为判断2.1 从驾驶舱场景反推模型选型为什么用YOLOv5而不是两阶段驾驶舱内的目标尺度差异很大人脸占画面比例大手机可能只有20×30像素再加上隧道、逆光、夜间仪表盘反光模型要同时扛住小目标召回和光照变化。两阶段检测器在COCO上的mAP更高但推理延迟很难在Jetson Nano、RK3588这类设备上跑到30fps。YOLOv5是单阶段模型CSPDarknet主干在相同算力下有更高吞吐PANet特征金字塔对多尺度目标更友好训练和部署生态也是深度学习目标检测方案里最完整的。更重要的是YOLOv5接DeepSORT的成本低检测结果能直接作为跟踪器的输入。实操时先把YOLOv5的repo固定在一个具体分支避免不同分支的权重结构不兼容。2.2 最小可复现的数据准备标注类别与目录结构把危险行为拆成四个类别smoke烟/打火机、phone手机、drink水杯/饮料瓶、distraction手长时间离开方向盘、转头等通用分心动作。疲劳不在一开始交给YOLOv5分类因为“闭眼”和“打哈欠”在单帧图片里是高度相似的状态错误标签会把训练损失拉高疲劳特征放到第4章用人脸关键点做。数据目录按YOLOv5惯例组织datasets/driver/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── driver.yaml标签是归一化txt每行格式class_id x_center y_center width height。用labelImg或Label Studio导出YOLO格式即可。注意类别顺序必须和driver.yaml一致我通常把smoke放0号因为它的标注样本最少先训练一个类别能更快验证数据管线。这里容易犯两个错类别数量比实际多或标注框把手机连手一起框进去导致后面判断“手机是否在手部ROI”时中心点偏移。driver.yaml的内容如下# 类别编号从0开始必须与标注导出一致 train: /data/driver/images/train val: /data/driver/images/val nc: 4 names: [smoke, phone, drink, distraction]2.3 训练自己的数据集yolov5训练命令、超参数与日志环境配置按PyTorch官方匹配CUDA版本装好后进入yolov5目录安装requirements。训练命令可以这样写python train.py \ --data /data/driver/driver.yaml \ --weights yolov5s.pt \ --img 640 \ --batch 16 \ --epochs 100 \ --device 0 \ --workers 4 \ --project runs/driver \ --name run1--img 640是训练分辨率手机在画面里只有几十像素用640能保住小目标特征推理时还可以降到480换帧率。--weights yolov5s.pt做迁移学习比从零训练收敛快。--epochs先设100但不要机械跑完重点看验证集val/mAP_0.5是否还在上升如果80个epoch后就平台期提前早停可以节省时间。训练过程看runs/driver/run1/results.png比loss更值得关注的是val/obj_loss和val/cls_loss。如果obj_loss震荡先检查标签是否错位如果mAP上不去用第一类样本单独训100张验证标注没有明显错误再逐步加类别。显存不足时--batch降到8--img降到512一般不会对驾驶舱检测造成断崖式下降。训练完用best.pt跑一次验证集视频python detect.py --weights runs/driver/run1/weights/best.pt \ --source test.mp4 --conf-thres 0.25 --iou-thres 0.45--conf-thres0.25先保留足够召回后面接DeepSORT时可以把阈值提到0.4漏检由跟踪器补偿。注意detect.py默认做letterbox后续接DeepSORT前要还原坐标。2.4 检测结果如何映射为“危险行为”事件单帧检测只是box列表。判断“玩手机”要设置滑窗在一个时间窗口内连续出现才算一次事件# 假设视频30fps窗口期3秒 window 90 counters {smoke: 0, phone: 0, drink: 0} for frame in frames: dets yolov5_infer(frame) for cls in counters: if any(d[class] cls for d in dets): counters[cls] 1 else: counters[cls] max(0, counters[cls] - 2) if counters[phone] window * 0.6: trigger(phone_use_alert)这里加一帧、减两帧的设计让短暂漏检不会立刻清零0.6的阈值表示3秒窗口内60%以上帧检测到手机才报警。如果把减帧速率改成1单帧误检会让计数器下降太慢报警变多。后面第4章会把这个滑窗和疲劳特征合并。3. DeepSORT接棒跟踪把单帧检测串成连续行为3.1 卡尔曼滤波与匈牙利匹配在驾驶舱里的作用DeepSORT为每个目标维护一条track状态包括位置、宽高比以及速度分量。卡尔曼滤波先用匀速运动模型预测当前帧的box位置再用匈牙利算法把预测结果与YOLOv5的检测框做级联匹配。匹配指标有两部分马氏距离衡量位置运动的规律性余弦距离衡量外观相似度。驾驶舱场景里手机、烟、水杯都很小外观特征不稳定位置预测往往更可靠所以max_dist可以调小。每个track还有确认机制。YOLOv5对手机的confidence在0.2到0.6之间抖动如果直接用单帧检测结果做统计十秒钟能触发十次报警。n_init3让新跟踪目标连续匹配3帧才进入confirmed状态这一条规则就滤掉了大量瞬时误检。3.2 DeepSORT参数推荐用稳定ID减少误检和ID切换实际调参时DeepSORT自带deep_sort.yaml核心参数如下参数典型值说明max_dist0.2马氏距离阈值太小在遮挡后接不上轨迹max_iou_distance0.7检测框重叠度下限驾驶舱小目标可设宽一点max_age30目标消失后保留轨迹的帧数方向盘遮挡常见n_init3确认轨迹所需连续匹配帧数nn_budget100外观特征池容量小目标建议不超过100max_age设30在30fps视频里约1秒手机被手或方向盘遮住1秒内ID不会变设太大轨迹会残影导致目标离开后行为还在计数。max_iou_distance设0.7而不是严格0.6因为手机和手经常自然贴合检测框重心偏移很常见。有了稳定ID行为判断从“这一帧有没有”变成“这个ID持续了多久、移动速度如何”。手机被方向盘遮挡后重新出现ID不变计数器不用清零副驾乘客玩手机因为位置不在司机ROI内不会进入司机行为判定只有2帧的“幽灵框”也因为在n_init前丢失而被扔掉。3.3 与YOLOv5联动的推理管线完整推理时YOLOv5只输出检测框DeepSORT负责维护轨迹用一个简化版代码把两者接起来import numpy as np from yolov5.models.experimental import attempt_load from deep_sort_pytorch.deep_sort import DeepSort model attempt_load(runs/driver/run1/weights/best.pt) deepsort DeepSort(osnet_x0_25.pt, max_dist0.2, max_iou_distance0.7, max_age30, n_init3, nn_budget100) def process_frame(img): dets model(img)[0].cpu().numpy() # 含NMS后的结果 boxes dets[:, :4] # x1 y1 x2 y2 confs dets[:, 4] cls_ids dets[:, 5].astype(int) # 只用跟踪我们关心的4类目标 mask cls_ids 4 boxes, confs, cls_ids boxes[mask], confs[mask], cls_ids[mask] if len(boxes) 0: outputs deepsort.update(boxes, confs, img) else: outputs deepsort.update([], [], img)deepsort.update的输入是当前帧所有检测框和置信度。没有检测时也要调用空更新否则跟踪器内部的帧计数不会推进。另一个坑是YOLOv5推理前对图像做了letterboxmodel(img)输出的box坐标是基于letterbox后图像的直接传给DeepSORT会让轨迹全部漂移。需要先按letterbox的padding和scale还原到原图坐标。osnet_x0_25.pt是DeepSORT默认的外观特征提取网络负责遮挡后找回同一目标。驾驶舱目标少外观特征权重不用开太高但因为脸部转动和手部遮挡随时可能发生完全关掉外观匹配会让ID频繁切换。4. 疲劳状态判定从PERCLOS到融合危险行为的预警策略4.1 用眼部关键点与头部姿态提取疲劳特征YOLOv5只负责框出驾驶员疲劳判定需要更细的人脸关键点。常见做法是在YOLOv5检测到人脸后把人脸框裁剪给一个小型关键点网络提取左右眼的EAR、嘴巴MAR和头部欧拉角。EAR定义EAR (d36-39 d37-40) / (2 * d33-45)睁眼时EAR较大闭眼时趋近于0。注意EAR在眨眼时也会下降因此要先做平滑class SmoothFilter: def __init__(self, alpha0.6): self.alpha alpha self.value None def update(self, v): if self.value is None: self.value v else: self.value self.alpha * self.value (1 - self.alpha) * v return self.valuealpha0.6表示当前帧占40%历史占60%能压掉眨眼瞬间的突变。区分眨眼和疲劳闭眼要靠时间维度眨眼持续0.2秒左右闭眼超过0.5秒才可能算疲劳。这段逻辑不能放在EAR阈值判断里必须放到帧序列统计层。4.2 危险动作的时序判据滑窗 跟踪ID 空间ROI第2章的滑窗是基线工程化时要增加两个条件目标跟踪ID稳定目标位置在驾驶员的ROI内。伪代码如下def merge_alert(closed_frames, phone_hold_frames, smoke_frames): alert 0 # 闭眼连续15帧(30fps下0.5s)先给一级 if closed_frames 15: alert max(alert, 1) # 手机持续出现在手部ROI超过20帧给二级 if phone_hold_frames 20: alert max(alert, 2) # 吸烟轨迹悬停超过30帧也为二级 if smoke_frames 30: alert max(alert, 2) return alert上面的数字不是模型参数是策略参数。如果车内摄像头帧率是25fps而不是30fps15帧对应的时长就变了所以建议直接把单位写成秒在代码里乘fps。另外closed_frames要来自同一个跟踪ID不能多人脸切换否则副驾打个哈欠也会算到司机头上。4.3 预警分级与阈值参数表在DMS项目里阈值需要按车型和摄像头安装位置重新标定。以下是一组能启动的基准值别直接放进量产车指标基准值调试方向EAR阈值0.20镜头离人脸远时调低到0.15闭眼连续帧数15帧0.5秒车内暗光噪声大就加一帧PERCLOS窗口60秒窗口越大越稳但响应变慢玩手机持续帧数20帧0.7秒小于这个数会把掏手机动作算成玩手机吸烟轨迹持续帧数30帧1秒抽烟动作本身有抬手阈值低于1秒误报高一级预警连续2次一级事件防单次眨眼序列触发二级预警3秒内任意危险动作持续触发语音提示和界面闪烁PERCLOS指的是单位时间内眼睛闭合时间占比比单纯连续帧数更抗噪。实际部署时把这些参数做成独立配置文件通过界面或命令行热更新比每次修改后重新训练模型快得多。配置项里至少要包含fps、ear_threshold、closed_seconds、hold_seconds因为不同摄像头的实际帧率和安装高度差异最大。5. 疲劳预警系统从demo到工程落地的验证细节5.1 用离线视频做时间对齐与逐帧复核预警日志必须记录触发时的帧号和系统时间不能只记录循环序号。先用ffmpeg按固定帧率抽帧ffmpeg -i onboard.mp4 -vf fps30 -q:v 2 frames/frame_%05d.jpg然后遍历日志把报警帧号与人工标注的行为区间做交集。关键点在于YOLOv5推理耗时会导致实际处理帧率低于输入帧率报警触发对应的帧号必须是输入帧号而非处理帧号否则所有事件在时间上会整体向后偏移。5.2 用事件级别指标代替帧级指标帧级准确率会严重虚高因为正常驾驶帧占大多数。事件级别统计用时间区间匹配def event_metrics(alarms, annotations, max_gap0.3): tp 0 for t in alarms: if any(ann.start t max_gap and ann.end t - max_gap for ann in annotations): tp 1 fp len(alarms) - tp fn len(annotations) - tp return tp / (tp fp fn)max_gap0.3秒表示报警时刻落在人工标注起止点前后0.3秒内就算命中。事件匹配不看检测框IoU因为分心行为本身没有严格边界。这个指标比mAP更能反映驾驶员分心预警系统的真实误报率。5.3 传感器安装角度决定阈值标定摄像头不要正对仪表盘中央。建议装在方向盘转向柱正上方俯仰角让人脸中心位于画面上1/3同时让方向盘和手部区域落在画面下方。这个角度下的手机框和手部框空间关系最稳定。重新装车后EAR阈值几乎一定会变因为人脸到摄像头距离变了。每辆车上录一小段正常驾驶和疲劳模拟视频用第4章的标定流程重新生成阈值表再进入整车验收。把帧号对齐、事件口径、角度标定这三件事写进验收检查单比再训练三十个epoch有价值得多。本文还有配套的精品资源点击获取 YOLOv5+DeepSORT实战：驾驶员分心预警系统设计与实现
简介一套基于YOLOv5DeepSort的驾驶员分心驾驶行为预警系统面向疲劳驾驶与危险动作实时监测场景可服务于智能座舱研发、车队安全管理及交通安全课题研究。工程集成目标检测、多目标跟踪、人脸关键点提取与UI界面提供从模型推理到结果展示的完整闭环。资源共59个文件约110.69MB20个Python脚本覆盖检测、跟踪、疲劳判定、主窗口逻辑等核心模块18个YAML文件描述YOLOv5系列网络结构与训练参数另含预训练权重、68点人脸关键点模型、UI布局文件、Dockerfile部署配置、演示视频与说明文档代码组织清晰易于二次开发。已有50人学习下载。对于希望快速搭建驾驶行为预警原型、了解YOLOv5工程化落地流程的开发者它能提供可运行的直接参考。1. 分心驾驶预警系统为什么必须用“检测跟踪”两条腿走路驾驶员分心驾驶预警系统摄像头通常装在A柱或仪表盘上方画面里同时出现人脸、手部、手机、香烟和水杯。如果只用单帧目标检测结果会像抽帧一样抖动同一部手机在第12帧被检测到、第13帧消失、第14帧又出现误报率高到没法用。可靠的做法是让YOLOv5负责“识别对象”DeepSORT负责“盯住对象”把单帧检测结果串成轨迹再从轨迹里提取行为持续时间和空间变化。这套系统解决的不是“有没有玩手机”而是“玩手机持续了多久、视线离开路面多久、闭眼频率是否上升”。适合正在搭建车载DMS、做驾驶行为分析、以及想把深度学习模型放到嵌入式设备上的工程师。一个反直觉的结论是预警系统的精度瓶颈往往不在模型分类而在跟踪稳定性。2. YOLOv5分层检测先解决“看见什么”再谈行为判断2.1 从驾驶舱场景反推模型选型为什么用YOLOv5而不是两阶段驾驶舱内的目标尺度差异很大人脸占画面比例大手机可能只有20×30像素再加上隧道、逆光、夜间仪表盘反光模型要同时扛住小目标召回和光照变化。两阶段检测器在COCO上的mAP更高但推理延迟很难在Jetson Nano、RK3588这类设备上跑到30fps。YOLOv5是单阶段模型CSPDarknet主干在相同算力下有更高吞吐PANet特征金字塔对多尺度目标更友好训练和部署生态也是深度学习目标检测方案里最完整的。更重要的是YOLOv5接DeepSORT的成本低检测结果能直接作为跟踪器的输入。实操时先把YOLOv5的repo固定在一个具体分支避免不同分支的权重结构不兼容。2.2 最小可复现的数据准备标注类别与目录结构把危险行为拆成四个类别smoke烟/打火机、phone手机、drink水杯/饮料瓶、distraction手长时间离开方向盘、转头等通用分心动作。疲劳不在一开始交给YOLOv5分类因为“闭眼”和“打哈欠”在单帧图片里是高度相似的状态错误标签会把训练损失拉高疲劳特征放到第4章用人脸关键点做。数据目录按YOLOv5惯例组织datasets/driver/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── driver.yaml标签是归一化txt每行格式class_id x_center y_center width height。用labelImg或Label Studio导出YOLO格式即可。注意类别顺序必须和driver.yaml一致我通常把smoke放0号因为它的标注样本最少先训练一个类别能更快验证数据管线。这里容易犯两个错类别数量比实际多或标注框把手机连手一起框进去导致后面判断“手机是否在手部ROI”时中心点偏移。driver.yaml的内容如下# 类别编号从0开始必须与标注导出一致 train: /data/driver/images/train val: /data/driver/images/val nc: 4 names: [smoke, phone, drink, distraction]2.3 训练自己的数据集yolov5训练命令、超参数与日志环境配置按PyTorch官方匹配CUDA版本装好后进入yolov5目录安装requirements。训练命令可以这样写python train.py \ --data /data/driver/driver.yaml \ --weights yolov5s.pt \ --img 640 \ --batch 16 \ --epochs 100 \ --device 0 \ --workers 4 \ --project runs/driver \ --name run1--img 640是训练分辨率手机在画面里只有几十像素用640能保住小目标特征推理时还可以降到480换帧率。--weights yolov5s.pt做迁移学习比从零训练收敛快。--epochs先设100但不要机械跑完重点看验证集val/mAP_0.5是否还在上升如果80个epoch后就平台期提前早停可以节省时间。训练过程看runs/driver/run1/results.png比loss更值得关注的是val/obj_loss和val/cls_loss。如果obj_loss震荡先检查标签是否错位如果mAP上不去用第一类样本单独训100张验证标注没有明显错误再逐步加类别。显存不足时--batch降到8--img降到512一般不会对驾驶舱检测造成断崖式下降。训练完用best.pt跑一次验证集视频python detect.py --weights runs/driver/run1/weights/best.pt \ --source test.mp4 --conf-thres 0.25 --iou-thres 0.45--conf-thres0.25先保留足够召回后面接DeepSORT时可以把阈值提到0.4漏检由跟踪器补偿。注意detect.py默认做letterbox后续接DeepSORT前要还原坐标。2.4 检测结果如何映射为“危险行为”事件单帧检测只是box列表。判断“玩手机”要设置滑窗在一个时间窗口内连续出现才算一次事件# 假设视频30fps窗口期3秒 window 90 counters {smoke: 0, phone: 0, drink: 0} for frame in frames: dets yolov5_infer(frame) for cls in counters: if any(d[class] cls for d in dets): counters[cls] 1 else: counters[cls] max(0, counters[cls] - 2) if counters[phone] window * 0.6: trigger(phone_use_alert)这里加一帧、减两帧的设计让短暂漏检不会立刻清零0.6的阈值表示3秒窗口内60%以上帧检测到手机才报警。如果把减帧速率改成1单帧误检会让计数器下降太慢报警变多。后面第4章会把这个滑窗和疲劳特征合并。3. DeepSORT接棒跟踪把单帧检测串成连续行为3.1 卡尔曼滤波与匈牙利匹配在驾驶舱里的作用DeepSORT为每个目标维护一条track状态包括位置、宽高比以及速度分量。卡尔曼滤波先用匀速运动模型预测当前帧的box位置再用匈牙利算法把预测结果与YOLOv5的检测框做级联匹配。匹配指标有两部分马氏距离衡量位置运动的规律性余弦距离衡量外观相似度。驾驶舱场景里手机、烟、水杯都很小外观特征不稳定位置预测往往更可靠所以max_dist可以调小。每个track还有确认机制。YOLOv5对手机的confidence在0.2到0.6之间抖动如果直接用单帧检测结果做统计十秒钟能触发十次报警。n_init3让新跟踪目标连续匹配3帧才进入confirmed状态这一条规则就滤掉了大量瞬时误检。3.2 DeepSORT参数推荐用稳定ID减少误检和ID切换实际调参时DeepSORT自带deep_sort.yaml核心参数如下参数典型值说明max_dist0.2马氏距离阈值太小在遮挡后接不上轨迹max_iou_distance0.7检测框重叠度下限驾驶舱小目标可设宽一点max_age30目标消失后保留轨迹的帧数方向盘遮挡常见n_init3确认轨迹所需连续匹配帧数nn_budget100外观特征池容量小目标建议不超过100max_age设30在30fps视频里约1秒手机被手或方向盘遮住1秒内ID不会变设太大轨迹会残影导致目标离开后行为还在计数。max_iou_distance设0.7而不是严格0.6因为手机和手经常自然贴合检测框重心偏移很常见。有了稳定ID行为判断从“这一帧有没有”变成“这个ID持续了多久、移动速度如何”。手机被方向盘遮挡后重新出现ID不变计数器不用清零副驾乘客玩手机因为位置不在司机ROI内不会进入司机行为判定只有2帧的“幽灵框”也因为在n_init前丢失而被扔掉。3.3 与YOLOv5联动的推理管线完整推理时YOLOv5只输出检测框DeepSORT负责维护轨迹用一个简化版代码把两者接起来import numpy as np from yolov5.models.experimental import attempt_load from deep_sort_pytorch.deep_sort import DeepSort model attempt_load(runs/driver/run1/weights/best.pt) deepsort DeepSort(osnet_x0_25.pt, max_dist0.2, max_iou_distance0.7, max_age30, n_init3, nn_budget100) def process_frame(img): dets model(img)[0].cpu().numpy() # 含NMS后的结果 boxes dets[:, :4] # x1 y1 x2 y2 confs dets[:, 4] cls_ids dets[:, 5].astype(int) # 只用跟踪我们关心的4类目标 mask cls_ids 4 boxes, confs, cls_ids boxes[mask], confs[mask], cls_ids[mask] if len(boxes) 0: outputs deepsort.update(boxes, confs, img) else: outputs deepsort.update([], [], img)deepsort.update的输入是当前帧所有检测框和置信度。没有检测时也要调用空更新否则跟踪器内部的帧计数不会推进。另一个坑是YOLOv5推理前对图像做了letterboxmodel(img)输出的box坐标是基于letterbox后图像的直接传给DeepSORT会让轨迹全部漂移。需要先按letterbox的padding和scale还原到原图坐标。osnet_x0_25.pt是DeepSORT默认的外观特征提取网络负责遮挡后找回同一目标。驾驶舱目标少外观特征权重不用开太高但因为脸部转动和手部遮挡随时可能发生完全关掉外观匹配会让ID频繁切换。4. 疲劳状态判定从PERCLOS到融合危险行为的预警策略4.1 用眼部关键点与头部姿态提取疲劳特征YOLOv5只负责框出驾驶员疲劳判定需要更细的人脸关键点。常见做法是在YOLOv5检测到人脸后把人脸框裁剪给一个小型关键点网络提取左右眼的EAR、嘴巴MAR和头部欧拉角。EAR定义EAR (d36-39 d37-40) / (2 * d33-45)睁眼时EAR较大闭眼时趋近于0。注意EAR在眨眼时也会下降因此要先做平滑class SmoothFilter: def __init__(self, alpha0.6): self.alpha alpha self.value None def update(self, v): if self.value is None: self.value v else: self.value self.alpha * self.value (1 - self.alpha) * v return self.valuealpha0.6表示当前帧占40%历史占60%能压掉眨眼瞬间的突变。区分眨眼和疲劳闭眼要靠时间维度眨眼持续0.2秒左右闭眼超过0.5秒才可能算疲劳。这段逻辑不能放在EAR阈值判断里必须放到帧序列统计层。4.2 危险动作的时序判据滑窗 跟踪ID 空间ROI第2章的滑窗是基线工程化时要增加两个条件目标跟踪ID稳定目标位置在驾驶员的ROI内。伪代码如下def merge_alert(closed_frames, phone_hold_frames, smoke_frames): alert 0 # 闭眼连续15帧(30fps下0.5s)先给一级 if closed_frames 15: alert max(alert, 1) # 手机持续出现在手部ROI超过20帧给二级 if phone_hold_frames 20: alert max(alert, 2) # 吸烟轨迹悬停超过30帧也为二级 if smoke_frames 30: alert max(alert, 2) return alert上面的数字不是模型参数是策略参数。如果车内摄像头帧率是25fps而不是30fps15帧对应的时长就变了所以建议直接把单位写成秒在代码里乘fps。另外closed_frames要来自同一个跟踪ID不能多人脸切换否则副驾打个哈欠也会算到司机头上。4.3 预警分级与阈值参数表在DMS项目里阈值需要按车型和摄像头安装位置重新标定。以下是一组能启动的基准值别直接放进量产车指标基准值调试方向EAR阈值0.20镜头离人脸远时调低到0.15闭眼连续帧数15帧0.5秒车内暗光噪声大就加一帧PERCLOS窗口60秒窗口越大越稳但响应变慢玩手机持续帧数20帧0.7秒小于这个数会把掏手机动作算成玩手机吸烟轨迹持续帧数30帧1秒抽烟动作本身有抬手阈值低于1秒误报高一级预警连续2次一级事件防单次眨眼序列触发二级预警3秒内任意危险动作持续触发语音提示和界面闪烁PERCLOS指的是单位时间内眼睛闭合时间占比比单纯连续帧数更抗噪。实际部署时把这些参数做成独立配置文件通过界面或命令行热更新比每次修改后重新训练模型快得多。配置项里至少要包含fps、ear_threshold、closed_seconds、hold_seconds因为不同摄像头的实际帧率和安装高度差异最大。5. 疲劳预警系统从demo到工程落地的验证细节5.1 用离线视频做时间对齐与逐帧复核预警日志必须记录触发时的帧号和系统时间不能只记录循环序号。先用ffmpeg按固定帧率抽帧ffmpeg -i onboard.mp4 -vf fps30 -q:v 2 frames/frame_%05d.jpg然后遍历日志把报警帧号与人工标注的行为区间做交集。关键点在于YOLOv5推理耗时会导致实际处理帧率低于输入帧率报警触发对应的帧号必须是输入帧号而非处理帧号否则所有事件在时间上会整体向后偏移。5.2 用事件级别指标代替帧级指标帧级准确率会严重虚高因为正常驾驶帧占大多数。事件级别统计用时间区间匹配def event_metrics(alarms, annotations, max_gap0.3): tp 0 for t in alarms: if any(ann.start t max_gap and ann.end t - max_gap for ann in annotations): tp 1 fp len(alarms) - tp fn len(annotations) - tp return tp / (tp fp fn)max_gap0.3秒表示报警时刻落在人工标注起止点前后0.3秒内就算命中。事件匹配不看检测框IoU因为分心行为本身没有严格边界。这个指标比mAP更能反映驾驶员分心预警系统的真实误报率。5.3 传感器安装角度决定阈值标定摄像头不要正对仪表盘中央。建议装在方向盘转向柱正上方俯仰角让人脸中心位于画面上1/3同时让方向盘和手部区域落在画面下方。这个角度下的手机框和手部框空间关系最稳定。重新装车后EAR阈值几乎一定会变因为人脸到摄像头距离变了。每辆车上录一小段正常驾驶和疲劳模拟视频用第4章的标定流程重新生成阈值表再进入整车验收。把帧号对齐、事件口径、角度标定这三件事写进验收检查单比再训练三十个epoch有价值得多。本文还有配套的精品资源点击获取