毕设选“基于深度学习的驾驶行为检测(玩手机)”这个题目的人不少但能把项目从数据集一路做到可现场演示原型、在答辩时真正跑起来的其实不多。不是模型本身多难而是这个课题把数据采集、标注、训练、部署、演示每个环节都压了一遍任何一环没处理好最后呈现效果都会大打折扣。我完整跑过一版也帮人排查过同类项目今天把整体思路、关键参数、代码实现和踩过的坑一次性整理出来。这篇内容适合刚接触目标检测、会用Python但没完整做过项目的人也适合想快速在公司内部做驾驶行为预警小原型的开发者参考。文章不会堆概念全部围绕“能跑起来、能讲清楚、能应对答辩”来讲。1. 项目背景与需求拆解1.1 为什么“玩手机检测”值得做驾驶场景中低头看手机、单手打电话、刷视频都可能导致注意力分散进而引发交通事故。传统手段主要靠人眼巡查或事后查监控很难做到实时主动预警。深度学习图像识别出现后这个场景可以直接用摄像头自动检测“驾驶员手里有没有手机”一旦发现持续玩手机行为就触发报警这给车载辅助系统提供了一个低成本、可落地的方案。从毕业设计角度看这个题目也特别合适。它不是一个空泛的“做一个AI Demo”而是典型的目标检测完整链路数据采集、标注、模型微调、性能评估、实时推理、报警联动。做完这个项目学生对图像分类、目标检测、模型部署、UI展示都有实际认知答辩时能讲的东西非常丰富。而且检测目标不算复杂手机、手部、方向盘都是在驾驶员区域内的常见目标单阶段检测器可以稳定胜任不需要额外部署复杂的姿态估计或动作识别模型项目周期可控。1.2 检测方案选型传统图像处理为什么不行一开始可能有人会想手机检测是不是用传统图像处理就能做比如根据肤色分割手部区域再找矩形轮廓判断手机或者用边缘检测、HOG特征加SVM分类器识别手机。这些方案在实验室的固定背景、固定光照下确实能跑通但一到真实驾驶室环境就崩阳光直射导致过曝、夜间仪表盘强光、手机屏幕反射、手部遮挡方向盘都会让特征失效。传统方法最大的问题是特征需要人工设计而驾驶室场景变化太多规则写不完。深度学习方案里又分成两阶段检测器和单阶段检测器。Faster R-CNN这类两阶段检测器精度高但推理速度慢实时性差不适合部署在普通CPU或低端显卡上做演示。SSD、YOLO这系列单阶段检测器走的是“只看一次”的路线速度和精度平衡得比较好。尤其是YOLO系列社区生态成熟预训练权重丰富训练和部署都有完整工具链。我用了一张对比表方便理解方案精度实时速度部署难度适合场景肤色检测 轮廓规则低受光照影响大快低固定摄像头固定光照HOG SVM中等特征表达弱中中目标形态固定Faster R-CNN高慢高离线分析、时间不敏感SSD中高较快中移动端、嵌入式YOLOv8高快低实时视频流分析最终选择YOLOv8理由很直接它对小目标检测做了优化训练时支持自动锚框和尺度变化还有开箱即用的Python接口。做毕业设计不是从零复现论文最怕环境配置耗时太长YOLOv8配合官方库可以减少大量工程化时间把精力集中在数据和处理逻辑上。2. 数据集准备与标注工程2.1 数据从哪来、类别怎么定很多同学拿到这个题目的第一反应是去网上找开源数据集找了一圈发现五花八门类别也不统一。这里先说明我的建议不要追求一个庞大的公开数据集也不要只靠自己录十几分钟视频硬扛最佳做法是“公开场景数据 少量自采数据”配合然后统一清洗和标注。类别设计上最简单清晰的做法是二分类normal和phone_use。normal表示正常驾驶、双手握方向盘、没有手持手机phone_use表示手拿手机放在耳边、低头看手机、操作手机屏幕等行为。如果细分接电话和看消息可以将phone_use拆成call和browse但建议先做两分类跑通再看效果。类别的语义会直接影响训练结果检测目标是“手和手机的接触区域”也就是标注框应该同时包住手机和握手机的那只手而不是只框手机。“手拿手机”这个状态从语义上看是人使用手机但从图像上看手机本身才是稳定可检测的视觉目标手的状态可以帮助判断。将手机和手看作一个整体目标框模型就能学到“手握住手机”的视觉模式而不是单纯检测手机屏幕这样也能减少把“副驾驶座上的手机”误判成驾驶员玩手机的风险。2.2 标注时最容易犯的几个错标注质量决定模型上限这个环节踩的坑最多。我见过很多训练集AP值上不去最后回去找原因发现是标注框乱、标签错、图片重复导致的。标注和清洗阶段我总结出几个必须注意的点标注框不要太大。有些标注工具默认框会吸附到整个物体边缘但手和手机接触后形态不规则正确的做法是让框尽量贴合手和手机的外轮廓不要把周围方向盘、座椅纹理包进去。太大的框会给模型带来大量背景噪声导致误检率上升。看不清的图直接删除。遮挡超过一半、运动模糊严重、夜间只有一片轮廓的图片不要硬标。模型不是超人标注一两张极端模糊的图反而会干扰特征学习。类别不要反复横跳。同一段视频里手刚刚碰手机但没拿起到底算不算phone_use这需要在标注规范里提前定义清楚。我的标准是“手机离开方向盘区域并且手部有明显接触”才算违规普通触摸中控屏幕不算。防止数据泄漏。很多自采数据是连续视频帧如果直接随机切分成训练集和验证集同一段场景的相似帧会同时出现在两个集合导致验证集分数虚高答辩时被问“为什么测试效果这么好”很容易翻车。正确做法是按视频片段划分或者按场景划分保证同一组连续画面只进入一个集合。标注工具方面常用的开源工具完全够用导出YOLO格式的txt文件时需要确认类别顺序是否正确。标注完成后我会再写一个小脚本统计每张图片的标注框面积、类别数量看看有没有异常。比如某一张图上标了20个phone_use那基本是标错了因为驾驶室内同时出现20个人拿手机并不现实。3. 核心模型设计与训练3.1 模型选型YOLOv8n还是YOLOv8s模型选型要结合“演示环境”来定。如果你的电脑有中高端显卡用YOLOv8s训练的熟练度会更高精度也更好但答辩现场大概率用的是你自己带的笔记本CPU推理YOLOv8s会明显掉帧。我的建议是训练和推理都直接使用YOLOv8n它参数量小、推理快在GTX 1650级别的显卡上做实时推理毫无压力CPU上也能跑出可用的帧率。很多人担心YOLOv8n精度低实际上驾驶室场景目标不算特别小手机在画面中通常占几十到上百像素YOLOv8n配合合适的输入分辨率完全够用。如果希望提升小目标检测能力可以把输入分辨率从640提升到960但训练时间和推理时间都会增加。对毕业设计来说先用imgsz640做第一版如果漏检严重再提高到960千万不要一上来就追求高分辨率容易让整个流程变得极慢。另外要强调迁移学习。直接用COCO预训练权重做初始化网络已经具备通用特征提取能力我们只是做迁移微调收敛速度会快很多。不要随机初始化权重从头训练毕设数据量不够效果很差。3.2 训练参数与配置假设项目目录是phone_detect需要准备一个数据集配置文件。前期的标注结果要整理成下面的目录结构datasets/phone/ images/ train/ val/ labels/ train/ val/配置文件内容如下# phone_detect.yaml path: ./datasets/phone train: images/train val: images/val names: 0: normal 1: phone_use注意path建议填绝对路径或项目相对路径避免训练时因为路径不对报错。类别顺序必须和标注文件里的类别ID一致。然后执行训练yolo detect train dataphone_detect.yaml modelyolov8n.pt epochs120 imgsz640 batch16 device0 patience20这里解释几个关键参数epochs120对于目标检测任务120轮可以稳定收敛。如果是自采数据迁移学习下可能80轮就能收敛但多跑一点没关系配合早停不会过拟合。batch16显卡显存不够时优先调低batch不要调低分辨率。16是一个比较稳妥的值显存不够就降到8。patience20连续20轮验证集指标没有提升就自动停止避免浪费时间也可以防止过拟合。device0指定显卡。如果没有GPU改成devicecpu但训练会很慢建议至少用云GPU跑一版。训练过程中不要只盯着 loss 下降重点看验证集上的mAP50-95以及训练结束后生成的混淆矩阵。我在训练时习惯把每轮输出的results.png定期打开看一下如果某个类的recall特别低说明标注数据里那个类的样本可能太少或者标注框本身有问题。训练结束后best.pt会自动保存在runs/detect/train/weights/下面这就是用于后续推理的模型。4. 系统实现与报警联动4.1 整体流程采集、检测、判定、报警、记录模型训练好只是第一步毕设要展示的是一个完整系统至少包含实时画面、检测结果、报警提示、事件记录几部分。我的整体流程设计如下摄像头读取视频帧。将当前帧传入YOLO模型做推理得到每个目标的类别、置信度和边界框。过滤置信度低于阈值的框只保留phone_use类别的检测结果。判定模块做时序判断连续多帧出现phone_use才认为驾驶员确实在玩手机。触发报警屏幕显示红色警示、播放提示音、保存当前画面。记录模块把报警前后的视频片段保存下来便于回看。为什么不单帧检测到手机就直接报警因为摄像头画面存在抖动、手部短暂靠近手机、遮挡等干扰单帧误检率会很高。连续N帧判断相当于加了一个低通滤波器能过滤掉绝大多数偶发误报。这个策略在真实场景中非常管用属于便宜又有效的工程技巧。4.2 实时检测和报警的代码实现我这里用ultralytics库写一个可运行的简化版本。代码结构不复杂重点看几个逻辑import cv2 from ultralytics import YOLO # 加载训练好的模型 model YOLO(runs/detect/train/weights/best.pt) cap cv2.VideoCapture(0) # 0代表默认摄像头 CONF_THRESHOLD 0.6 ALARM_CONSECUTIVE 3 # 连续多少帧触发报警 COOLDOWN_FRAMES 30 # 报警后暂停多少帧防止频繁触发 alarm_count 0 cooldown 0 alarm_flag False while True: ret, frame cap.read() if not ret: break results model.predict(frame, imgsz640, confCONF_THRESHOLD, verboseFalse)[0] phone_detected False for box in results.boxes: cls_id int(box.cls[0]) conf float(box.conf[0]) if cls_id 1 and conf CONF_THRESHOLD: phone_detected True break if cooldown 0: cooldown - 1 phone_detected False if phone_detected: alarm_count 1 else: alarm_count 0 if alarm_count ALARM_CONSECUTIVE and not alarm_flag: alarm_flag True cooldown COOLDOWN_FRAMES cv2.putText(frame, WARNING: PHONE USE DETECTED, (50, 50), cv2.FONT_HERSHEY_SIMPLEX, 1.0, (0, 0, 255), 2) cv2.imwrite(alarm_screenshot.jpg, frame) # 这里可以接入提示音或消息推送 if alarm_count ALARM_CONSECUTIVE: alarm_flag True else: alarm_flag False annotated results.plot() cv2.putText(annotated, fAlarm count: {alarm_count}, (50, 100), cv2.FONT_HERSHEY_SIMPLEX, 0.8, (255, 255, 0), 2) cv2.imshow(Driving Behavior Detection, annotated) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()代码里几个容易出问题的地方我单独说明。model.predict默认开启验证模式会做NMS但每次调用都会做图像预处理和后处理如果摄像头帧率很高建议先开两个缓冲区用多线程读取否则显示画面会卡顿。这里为了直观先写单线程版本现场演示时视频源用预先录好的测试片段比实时摄像头更稳定。置信度阈值CONF_THRESHOLD不是越大越好。设太大漏检严重手稍微被方向盘挡住就检测不到设太小误检多容易把仪表盘、水杯、卡片误判成手机。我的经验是0.5到0.7之间比较平衡可以先在验证集上画Precision-Recall曲线选择精确率和召回率交叉较好的点作为阈值。4.3 现场演示的小技巧答辩现场最怕摄像头画面不清晰、模型推理卡顿、报警声突然很大吓到全场。我建议准备两条演示路径一条是实时摄像头演示用于展示“模型能实时识别手拿手机”另一条是提前录好的短视频或图片序列用于展示夜间、复杂背景下的识别效果。如果现场网络或驱动出问题至少还能用离线视频兜底。UI层面用OpenCV窗口显示检测框和FPS已经足够不需要做一个花哨的Web界面。如果想加分可以加一个统计面板比如实时FPS、累计报警次数、最近一次报警截图用PyQt或Flask都行但功能一定要稳定不要为了UI牺牲核心逻辑。演示前一定要把摄像头驱动装好笔记本自带的摄像头和部分外接USB摄像头在OpenCV中的读取方式不同提前用一张测试图确认画面能正常显示。5. 常见问题与避坑指南5.1 训练效果不好loss不降、mAP低这个问题在群里被问得最多。模型在训练集上精度高、验证集上精度低说明过拟合解决思路是增加数据量、调大增强、减少训练轮数。反过来训练集和验证集精度都低首先检查标注文件类别ID有没有和配置文件对齐标注框有没有出现零点几像素的异常值再用可视化工具把标签画到原图上检查一遍。很多看起来像模型问题最后都发现是标签文件损坏或路径混乱。如果正负样本比例悬殊比如normal类有5000张phone_use只有300张模型会把所有目标都猜成normal。这种情况下可以做一些简单的类别均衡少样本类别做复制增强、Mosaic增强和随机旋转或者用大分辨率重新标注难例数据。不要依赖单一技巧通常要组合使用。我整理了一个快速排查表现象可能原因优先检查项loss不下降学习率过高/数据问题学习率曲线、标签可视化验证集mAP高但实际推理差数据泄漏按视频片段划分不按帧phone_use召回很低少样本/遮挡增加正样本、提高imgsznormal误报成phone_use背景干扰/标注框过大清洗标注、收紧标注框夜间效果差数据分布偏差加入夜间逆光增强5.2 误检与漏检手机漏了方向盘却被当成手机推理阶段遇到的问题和训练不太一样我实际跑的时候最常见是两类一类是漏检。手机屏幕没有点亮、深色手机壳贴着手掌模型很容易把这个整体识别成“普通手部”此时可以从两个方向优化把输入分辨率从640提到768或960增加包含“手机壳颜色接近皮肤”的负样本和正样本。不要盲目加数据先看漏检的图片长什么样针对性地补充对应的光照、角度和遮挡情况。另一类是误检方向盘、水杯、手套、卡片都会在某个角度和手部组成看起来像“拿手机”的区域。降低置信度阈值会让误检变多提高阈值又影响召回。稳妥的做法是保留一个“候选预警”阈值和一个“确定报警”阈值比如置信度大于0.75才触发声音报警大于0.5但小于0.75时只记录提示不响铃。这种两级报警在现场演示时也能体现工程思考不会被当成单纯调参。多目标重叠的情况也要注意。如果车内人脸检测和手机检测同时做手机划过脸部的瞬间可能出现框的抖动。可以在后处理中加入简单的目标跟踪或帧间平滑例如对检测框中心坐标做指数移动平均避免报警状态频繁跳变。5.3 性能与部署Demo卡顿模型太大怎么办毕业设计大多在笔记本上演示如果推理只有3到5帧每秒画面会非常卡。先检查有没有开GPU推理YOLO默认会调用CUDA但部分环境没有正确安装torch的GPU版本。可以用torch.cuda.is_available()确认。确认GPU没问题后再看输入分辨率。实际在CPU上做演示时把imgsz从640降到480帧率能提升很多精度损失肉眼很难察觉。如果项目还有余力建议把模型导出为ONNX格式再用ONNX Runtime推理这样能减少依赖、加快速度。导出命令yolo export modelruns/detect/train/weights/best.pt formatonnx imgsz640 opset12导出后可以用onnxruntime加载模型在CPU上推理通常比原版PyTorch快不少。如果再进一步可以尝试把模型量化为FP16或INT8但量化过程容易掉精度毕设不一定需要冒险。部署时要考虑模型文件大小。YOLOv8n大约6MBYOLOv8s大约22MB对演示项目来说都不算大。但如果你在训练时不小心把epochs拉满又不做早停最终best.pt可能有几十个版本正式使用前记得清理只保留一个文件并入项目目录时别带上一堆中间权重。如果用这个题目做毕设我的建议是别一上来就调模型结构先把数据管好再把演示主线跑通。拿我的实际测试经验来说训练集里混入大量光照极暗、重复度高的图片模型AP会掉得莫名其妙我花了两天才排查到源头最后发现只是几张标错类别、连续重复的帧。遇到问题先怀疑数据再怀疑参数最后才动网络结构这个顺序能帮你省下大量时间也更容易在答辩前把项目打磨到能现场演示的状态。