Python违规驾驶行为识别系统：基于YOLO的目标检测与疲劳判定实战

简介这套Python违规驾驶行为识别系统源码以计算机视觉和深度学习为基础面向需要完成毕业设计或课程项目的学生及开发者可快速搭建驾驶行为检测与分析框架覆盖数据读取、模型训练、实时推理等常见环节。压缩包共128个文件总大小64.93MB其中81个.py源码文件是核心另有8个.sh脚本便于自动化运行2个.pth与4个.pkl保存模型权重5个.md和4个.txt提供项目说明6个.png图片展示检测效果2个.npy数据文件用于辅助测试还包含pyx扩展模块与License等完整工程配置。已有1061人浏览学习。使用这份源码可节省从零搭建项目的时间直接获得一套可运行的毕设原型。目录结构清晰便于按需修改模型结构、替换训练数据或扩展识别类别适合作为视觉识别方向毕业设计的参考实现。1. 一张图说清这个毕设系统摄像头画面怎么变成“打电话、疲劳”告警很多人拿到“Python违规驾驶行为识别系统源码”这个题目第一反应是研究轨迹预测或者传感器融合真正落地时发现那条路根本走不通传感器买不到、数据要自己标、答辩还讲不清楚。最常见的毕设做法是纯视觉方案——用车内摄像头读视频帧目标检测模型定位“手、手机、人脸、嘴巴、眼睛”再用行为判定逻辑得出“打电话、疲劳驾驶、正常驾驶”三类结果最后在画面上打框、弹告警。这套系统的核心难点不在“检测”而在“判定”单帧检出打电话不算本事连续帧怎么去抖、怎么平衡漏检和误报、怎么把置信度阈值调到答辩现场不出丑才是真正拉开档次的环节。适合谁做计算机、软件工程、人工智能方向的本科生毕设或者智能座舱、车联网方向想快速出 demo 练手的人。2. 违规驾驶行为识别系统架构从视频帧到行为标签的四层流水线一个能拿去答辩而不是拿去糊弄的系统内部一定是四层输入层摄像头或离线视频、目标检测层人脸/手部/手机、行为判定层时序阈值、输出层告警框、状态统计、报表。这四层每层都有独立的坑下面逐层拆开讲。2.1 为什么选 YOLO 做检测推理速度与精度的平衡点毕设项目的检测部分属于“目标检测 局部特征分析”混合场景可选方案不少但真正适合在普通笔记本上跑、还要现场演示不卡的主流就那几类。我一般建议检测主干直接选 YOLO 系列理由很实际推理速度能压到几十毫秒一帧训练和部署的资料多到翻不完出错时随便搜一下就有人踩过同一个坑。方案定位任务依赖重量推理速度毕设适用度YOLOv5 / YOLOv8人手、手机、人脸、嘴巴torch/onnxruntime中等高几十 ms/帧高MediaPipe人脸 468 点、手势 21 点自带模型轻量高中但行为标签需要二次加工Dlib人脸 68 点编译依赖重中低安装容易劝退OpenPose全身骨架模型大、依赖重低低演示容易卡成幻灯片选 YOLO 还有一层原因打电话、抽烟这类行为本质上是“小目标 遮挡 手部与脸部交汇”YOLO 在小目标上配合 tiling 或提高输入分辨率效果比传统 HOG、肤色检测靠谱得多。检测层输出的是归一化坐标和类别行为判定层拿这些坐标继续做时序统计两层解耦后换模型品牌只影响前面一层不影响后面逻辑这也是毕设里很容易被老师追问的“模块化设计”提前想好这句话答辩时能省很多尴尬。2.2 每一帧是怎么流出告警的核心代码骨架逐段拆解检测层拿到一帧图像后经过 resize 到 640x640、归一化、模型推理得到一批检测框。行为判定层要做的不是直接画框而是先过滤低置信度目标再按类别组合判断。下面这段代码是主循环的最小骨架去掉平台无关的细节后大概长这样import cv2 import numpy as np class DetectPipeline: def __init__(self, conf_thres0.4): # conf_thres 控制检测框保留阈值调低会变灵敏但误报变多 self.conf_thres conf_thres def preprocess(self, frame): # 统一缩放到 640x640推理引擎通常要求固定输入尺寸 img cv2.resize(frame, (640, 640)) img img.astype(np.float32) / 255.0 return img def run(self, frame): # 实际项目中这里由 onnxruntime / torch 推理填充 # 返回格式: [cls_id, x1, y1, x2, y2, score] return [] cap cv2.VideoCapture(0) pipe DetectPipeline(conf_thres0.4) while True: ok, frame cap.read() if not ok: break dets pipe.run(frame) for det in dets: # 假设 cls_id2 是打电话类别score 大于阈值才展示 if det[0] 2 and det[5] pipe.conf_thres: x1, y1, x2, y2 map(int, det[1:5]) cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 0, 255), 2) cv2.putText(frame, CALLING, (x1, y1 - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.8, (0, 0, 255), 2) cv2.imshow(driving_demo, frame) if cv2.waitKey(1) 27: break cap.release() cv2.destroyAllWindows()逻辑说明这套主循环并不复杂关键是run()内部返回的检测框格式必须统一否则行为判定层没法稳定对接。代码里conf_thres用的是 0.4这是毕设项目里一个比较折中的值——调低到 0.25 会把方向盘、后视镜误检成人手调高到 0.6 又会在暗光环境下漏掉真实的打电话动作。waitKey(1)是 OpenCV 渲染窗口的刷新间隔单位毫秒设为 1 能让主循环跑满摄像头帧率。参数说明det[5]是置信度分数很多新手直接拿检测框画图忘了过阈值结果画面上全是低置信度的虚线框答辩时非常难看。det[0]是类别索引各类别与训练数据集里的classes.txt顺序对应改标签文件时一定要连同这里一起改否则会发生“框对了但文字标错”的翻车现场。2.3 训练自己的行为数据标注格式与类别体系怎么设计类别体系建议从四类起步person驾驶员整体、phone手机、face人脸、mouth嘴巴区域。检测模型只管这四个目标的定位行为判定层再根据“手上是否拿手机”和“嘴巴是否张大”组合出“打电话”和“打哈欠”。这样设计的好处是解耦如果只标注“打电话”一个类别模型学到的其实是“手机手的组合形态”换个手型就漏检拆开后手拿手机是空间关系打哈欠是嘴巴的形态变化各自独立训练召回率明显更稳。标注工具用 LabelImg 或 X-AnyLabeling 都可以输出 YOLO 格式的 txt 文件。如果你手头的数据集是 VOC 的 XML 格式需要转一下常见做法是写一段解析脚本核心逻辑是把bndbox坐标转成归一化的中心点坐标import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, class_index): tree ET.parse(xml_path) root tree.getroot() size root.find(size) w, h int(size.find(width).text), int(size.find(height).text) lines [] for obj in root.findall(object): cls obj.find(name).text if cls not in class_index: continue box obj.find(bndbox) x1, y1 float(box.find(xmin).text), float(box.find(ymin).text) x2, y2 float(box.find(xmax).text), float(box.find(ymax).text) dw, dh 1.0 / w, 1.0 / h cx, cy (x1 x2) / 2.0 * dw, (y1 y2) / 2.0 * dh bw, bh (x2 - x1) * dw, (y2 - y1) * dh lines.append(f{class_index[cls]} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) return lines这段脚本有个容易被忽略的边界w和h必须取自原图尺寸而不是训练时的输入尺寸 640。如果拿缩放后的图尺寸去归一化得到的坐标会整体偏移训练时 mAP 看起来正常实际推理时检测框全部偏到左上角这种问题不打印原图坐标很难发现属于那种“查半天查不出原因”的玄学 bug。数据配比上我建议正样本打电话、打哈欠、闭眼与负样本正常驾驶、手摸脸、摸耳朵比例控制在 3:1 左右。负样本太少模型会把“手靠近下巴”也判成打电话这一类误报在答辩现场特别容易发生因为评委老师的动作本身就是双手撑着下巴听你讲。3. 跑通最小系统环境、目录和启动参数的实操清单拿到压缩包之后第一步不是急着调模型而是把环境和目录结构理清楚。这个步骤做踏实了后面至少省掉一半排查时间。3.1 解压与 python 环境搭好zip 在 Windows 和 Linux 下的正确打开方式源码包是 zip 格式听起来简单实际第一步就会拦下一批人。先校验压缩包完整性再解压顺序不能反。# Linux / macOS 下校验 zip 是否完整 zip -T python_driving_project.zip # 解压到 project 目录 unzip python_driving_project.zip -d ./projectWindows 下用 7-Zip 右键解压即可但如果解压时提示需要密码先别急着找密码很多毕设源码包是“zip 伪加密”——文件本身没有加密只是 zip 头部一个标志位被改掉了。用 7-Zip 打开后直接拖出文件通常就行或者用 Python 读一下zipfile模块的报错信息确认是伪加密还是真加密。真加密只能找发包人要密码伪加密可以自己做个小脚本把标志位改回去这个功能在应急时非常有用。解压完成后创建虚拟环境这一步能避免你把自己电脑的 Python 环境搞成“黑匣子”。不同毕设项目依赖的 Python 版本差异很大有的老代码还在用tf1.x有的新版已经切到torch2.x混在一起装早晚冲突。conda create -n driving python3.8 -y conda activate driving # 安装项目依赖注意看 requirements.txt 里是否有版本锁定 pip install -r requirements.txt # 如果缺 cv2单独装 opencv-python 即可 pip install opencv-python关于 Python 版本我的建议是优先按requirements.txt里的说明来没说明就选 3.8 或 3.10。太新的 3.12 对torch、dlib这类带编译产物的包支持还不完善装到一半报编译错误会非常折磨。cv2装不上也是高频问题常见原因是 pip 源里没有对应版本换清华镜像源基本能解决。3.2 主程序运行流程摄像头实时检测与离线视频回放模式毕设项目的主程序一般叫detect.py或main.py启动前先看目录下有没有weights/文件夹以及里面的权重文件。很多源码包只带代码、不带权重因为权重文件太大不好传启动时提示找不到.pt或.onnx文件的话需要用项目自带的小工具或去模型仓库重新下载对应权重。启动方式区分两种输入源代码里一般通过--source参数控制# 方式一摄像头实时检测0 表示默认摄像头 python detect.py --source 0 --weights weights/best.pt --conf-thres 0.4 # 方式二离线视频回放跑测试集看效果 python detect.py --source test_video.mp4 --weights weights/best.pt --conf-thres 0.4 --save-result # 方式三打开摄像头前先列出所有可用设备索引 python -c import cv2; print([i for i in range(5) if cv2.VideoCapture(i).read()[0]])参数说明--source 0是设备索引笔记本自带摄像头一般是 0外接 USB 摄像头经常是 1 或 2不确认时用方式三先探测。--save-result表示把带标注的结果视频保存到results/目录这个文件夹里面生成的内容就是答辩时不需现场演示、也能展示系统能力的素材。--conf-thres与代码里conf_thres是同一个值命令行优先级更高。很多新手会犯一个懒人错误直接拿cv2.VideoCapture(0)启动摄像头不管是否成功就进入循环。结果答辩现场摄像头索引冲突画面死活出不来。稳妥的写法是先cap.isOpened()判断失败时打印具体原因并退出而不是让程序卡死在一个黑窗口里。3.3 三个必调参数置信度、采样间隔与连续帧判定行为识别系统里比模型本身更影响观感的三个参数是检测置信度阈值、帧采样间隔和连续帧判定窗口。这三者相互配合调好了系统稳如老狗调差了现场翻车。置信度阈值前面说过0.35 到 0.45 之间比较安全。暗光环境适当下调白天场景保持默认。帧采样间隔的意思是不需要每一帧都跑模型比如每 3 帧检测一次、中间帧沿用上一次检测结果。原因很实际——模型推理耗时如果大于 40ms在 30fps 视频下就会累计延迟视频画面像 PPT 一样一卡一卡评委看着都难受。跳帧处理后告警消息跟上画面顺滑其实观感反而更好。连续帧判定是去掉“单帧误报”的关键。一张正常驾驶的图片里驾驶员手摸后脑勺的瞬间模型很容易觉得那是“手拿手机”。解决思路是滑窗计数只有连续 N 帧都检测到同一类行为才触发告警。# 滑窗判定连续 5 帧检测到打电话才触发告警 calling_count 0 ALARM_THRESHOLD 5 for det in dets: if det[0] 2 and det[5] conf_thres: calling_count 1 else: calling_count max(0, calling_count - 1) if calling_count ALARM_THRESHOLD: alarm_triggered True逻辑说明calling_count不是简单的累加而是“加一帧减一帧”——模型偶尔误报一帧不会误触发但真实打电话时手部动作持续几秒计数器自然突破阈值。参数 5 对应约 0.3 秒的持续时长如果觉得延时太大可以改为 3觉得误报压不住改为 8 或 10。这个参数是行为识别系统里性价比最高的调节旋钮答辩时讲一句“我用滑窗去抖替代单帧判定误报率降低约三成”比吹模型指标更有说服力。4. 训练与评估把模型的准确率从“能跑”拉到“能答辩”源码包里如果自带了训练好的权重跑通 demo 很快。但很多毕设要求里“必须有自己的训练过程”这一章解决的就是这部分数据从哪来、参数怎么设、结果怎么向评委证明。4.1 准备数据集公开数据与自采数据的配比以及 VOC 转 YOLO 的边界坑行为识别领域没有统一的大规模“驾驶行为数据集”直接拿来用常见做法是混合公开的人脸关键点数据集、手部数据集、车辆内场景数据集各取一部分再加上自己录制的模拟驾驶视频比例可以控制在 7:3。自采数据不是用来刷指标的而是用来补充“你这个场景”的特定样本——比如你用的摄像头装在高位和低位视角不同模型看到的手部形态完全不同。录制自采数据时找一个同学坐在驾驶位模拟打电话、打哈欠、闭眼、正常驾驶四类动作手机横屏录制 10 到 20 秒的短视频不要只录静态姿势要有“低头看手机—抬头—再低头”的动态过程。每段视频抽帧后筛选清晰样本标注。不需要抽太多每个类别 500 到 800 张配合公开数据足够完成训练。数据格式老旧或标注不统一是训练环节最常见的返工原因。上一章给了 VOC 转 YOLO 的脚本这里补两个容易踩的坑一是 XML 里图片路径写成绝对路径换机器训练时找不到图二是class_index字典的顺序必须和训练配置文件里的names列表一致比如names: [person, phone, face, mouth]那class_index里 person 就是 0phone 是 1顺序弄反模型学到的类别和检测结果会对不上mAP 还会虚高——因为它确实把“人”识别成“人”了只是标签换了。4.2 训练参数与 GPU 选择显存不够时怎么让训练跑起来在笔记本上训练检测模型目标是尽快拿到一个能用的权重而不是刷到 SOTA。下面这套参数是我常用的起点方案适合显存 6GB 到 8GB 的笔记本参数名建议值说明输入尺寸 imgsz640太大显存不够太小小目标漏检batch size166GB 显存建议 16OOM 就降到 8训练轮数 epoch120看 loss 是否还在降降就继续初始学习率 lr00.01预热后衰减用默认策略即可优化器SGD 或 AdamW数据量小选 AdamW 省心数据增强mosaic hsv默认开启注意 mosaic 在最后 10 轮关闭以 YOLOv8 为例训练命令长这样yolo detect train \ datadatasets/driving.yaml \ modelyolov8n.pt \ epochs120 \ imgsz640 \ batch16 \ lr00.01 # 如果显存溢出把 batch 降到 8并把 imgsz 降到 512driving.yaml是数据配置里面写清楚训练集、验证集路径和类别名这个是 YOLO 训练前的必填项。如果训练时一直报AssertionError: train: No labels in ...不用怀疑就是标签文件没放对目录或者图片和标签文件没有同名同目录。显存不够时的后悔药不止降 batch。把model从前缀换成yolov8n这种轻量版参数量直接少一个数量级训练输出里开启ampTrue混合精度显存占用再降一截而精度损失在毕设场景几乎看不出。4.3 用 mAP 和混淆矩阵卡住答辩评估的量化证据往哪看训练结束后验证集上的mAP0.5是一个直观的指标但答辩时真正能证明系统能力的是混淆矩阵。打电话、打哈欠、正常驾驶这三维类别里最容易混淆的是“打电话”和“正常驾驶”——手部靠近脸部的正常动作被误判为打电话。矩阵里这一格的数字才是你真正需要重点调优的地方。# 验证集评估输出 mAP、PR 曲线和混淆矩阵 yolo detect val \ modelruns/detect/train/weights/best.pt \ datadatasets/driving.yaml评估完之后把runs/detect/val/confusion_matrix.png和PR_curve.png两张图导出放进答辩 PPT 的附录页。比起裸贴一个0.87的 mAP展示“哪些类容易混淆、我是怎么用时序去抖压掉误报的”是更立体的答辩素材。我个人的习惯是额外保留一段带检测框标注的验证集视频长度 1 分钟左右里面同时包含正确检测和漏检的片段。这段视频的用法不是炫耀而是为了让评委知道系统的边界在哪。主动讲“哪种光源条件下会漏检”比被评委问住再支支吾吾体面得多。5. 毕设人最容易翻车的六个坑从解压到答辩演示的现场排查这一章是实战踩坑记录每条都是“现象 → 原因 → 解决”三段式情景基本都是从这个毕设方向高频出问题的地方选的。5.1 模型权重文件缺失或路径写错启动即闪退现象运行python detect.py后立刻报类似FileNotFoundError: best.pt does not exist的错误或者程序退出码非零画面一闪而过。原因源码包里通常只放代码不放权重或者代码里写的是weights/best.pt但权重文件实际放在项目根目录。解决先看目录里.pt、.onnx文件的实际位置确认后再检查代码里加载路径是相对路径还是绝对路径。我见过一个项目权重放在了runs/detect/exp/里代码却在weights/下找把命令启动改为手动传参--weights runs/detect/exp/best.pt就好了。5.2 摄像头打开失败cv2.VideoCapture 一直返回 False现象代码不报错但cap.read()返回的ok始终为 False程序卡在循环里或直接退出。原因笔记本摄像头被其他软件占用比如已经打开的腾讯会议/相机 App或者设备索引不是 0。解决先用前面第 3.2 节里的探测命令列出所有可用索引确认后再改--source参数。如果都试过还是不行大概率是摄像头隐私权限没给到 PythonWindows 在“设置 → 隐私 → 相机”里把“允许桌面应用访问相机”打开Linux 下确认当前用户加入了video组。5.3 GPU 显存不足RuntimeError: CUDA out of memory现象训练或推理时报 CUDA 内存不足程序直接中断。原因作为毕设项目你自己的笔记本显存只有 6GB代码默认 batch 或推理尺寸偏大。解决训练时按第 4.2 节把 batch 降到 8、imgsz 降到 512并且开启 AMP 混合精度。推理时如果不涉及训练可以在代码里强制使用devicecpu虽然慢一点但最稳。这里有一条血泪经验不要在答辩现场当着评委的面跑实时训练老实用验证集视频回放或者提前把结果视频录好。5.4 zip 伪加密与解压报错压缩包里的项目文件怎么救现象解压源码包时提示需要密码或者 7-Zip 能打开但 Windows 自带解压报出错。原因很多分享出来的源码 zip 包带了“伪加密”标志位本质是把 zip 头部的加密标志设成 1文件数据本身没有用 AES 加密。解决用 7-Zip 打开压缩包选中全部文件后直接拖拽到文件夹通常可以绕开密码校验真正打不开时用 Python 手动把文件头的加密标志位改掉再解压。这个坑几乎不会在项目文档里写但网上流传的毕设源码包有一小半都有类似问题先学会救项目再谈改代码。5.5 视频处理帧率低画面卡成 PPT现象运行实时检测时画面明显延迟动作像慢放。原因模型推理耗时太长、每帧都做全流程预处理、没有跳帧。解决优先开跳帧每 2 帧或 3 帧做一次推理中间帧直接复制上一帧结果。另外检查代码里是否对每帧都做了letterbox和颜色转换这些操作如果没做缓存也会吃掉大量 CPU。我通常会先把推理侧耗时打出来看瓶颈python detect.py --source 0 --benchmark # 输出每阶段耗时如果预处理显示耗时超过 20ms可以考虑只在跳帧后的一帧里执行预处理如果推理本身超过 100ms就只能换轻量模型或者改用 ONNX 格式部署。5.6 答辩现场光线差检测框乱跳和漏检同时出现现象现场投影仪的强光或头顶射灯造成暗部和亮部同时存在检测框时有时无。原因模型训练数据里的光照变化不够暗光下人脸和手部对比度太低。解决不要赌现场的实时效果优先用提前录好的视频回放录的时候模拟几种光线条件如果要实时演示给视频帧做简单的亮度直方图均衡化通常能明显改善暗光漏检。这类问题没法只靠调参根治实践证明“在输入侧做光照预处理”比分枝调模型权重管用得多属于那种看着不起眼实际很值钱的小技巧。6. 把毕设做成能用的系统疲劳驾驶检测子模块的工程化守住“能答辩”之后如果想多拿一点分把疲劳检测从“闭眼布尔值”升级成“PERCLOS 持续统计”是性价比最高的改进方向。6.1 用眼睛纵横比计算闭合帧占比告别单帧闭眼误判常见的疲劳检测只是判断“眼睛是否闭合”然后输出一个状态。工程化一点的做法是用眼睛纵横比EAR曲线来判断。当 EAR 值低于某个阈值并持续一段时间才算一次闭眼接着统计一个滑动窗口内闭眼帧的占比这个占比就是 PERCLOS 值超过阈值才触发疲劳告警。def eye_aspect_ratio(eye_landmarks): A np.linalg.norm(eye_landmarks[1] - eye_landmarks[5]) B np.linalg.norm(eye_landmarks[2] - eye_landmarks[4]) C np.linalg.norm(eye_landmarks[0] - eye_landmarks[3]) return (A B) / (2.0 * C) ear eye_aspect_ratio(eye_pts) if ear 0.2: close_frames 1 else: close_frames 0 window_size 50 perc close_frames / window_size if perc 0.25: alarm_count 1逻辑说明close_frames在 EAR 恢复后清零window_size是统计窗口50 帧约 2 秒。perc 0.25意味着窗口内闭眼时长超过四分之一这说明驾驶者处于明显疲劳状态。这套逻辑比“连续 5 帧闭眼告警”更稳因为真实的疲劳过程里闭眼是间歇出现的短窗口根本卡不住。6.2 三个方向验证鲁棒性离线回放、亮度补偿、多线程队列把毕设系统从“能跑”推到“能验证”我有三个常用习惯你也可以照做。第一任何实时演示之前先跑一遍离线视频回放确认低级错误不存在了再上现场。第二在输入预处理阶段加一段可开关的亮度补偿代码效果参考试第 5.6 节的直方图均衡化。第三把摄像头读取和模型推理拆到两个线程中间用队列衔接避免读取阻塞拖慢推理。这个技巧在车端边缘设备上尤其关键当时我在一台低功耗开发板上调试单线程帧率只有 12fps拆成双线程后稳定到 24fps等于白捡一倍的性能。还得说一句实话很多毕设项目最终没进评审的“优秀论文”名单不是模型不够好而是演示环节出岔子。被问到一个边界问题回答说“没测过”其实没那么严重严重的是连自己的系统能力边界在哪里都说不清。我自己的习惯是给系统留一个--edge-mode参数专门在低性能设备上开启轻量推理答辩时主动讲“这是为了后续边缘部署预留的开关”这种细节点往往比繁杂的技术堆叠更有说服力。希望这份记录能帮你少走几段弯路也祝你的系统在演示那天稳如磐石——最好带上提前录好的视频作为兜底方案现场出什么乱子都不慌。本文还有配套的精品资源点击获取