基于YOLO11的电动车骑行规范识别系统：从数据标注到部署实战

做毕设选方向的时候，我在“纯算法研究”和“落地应用型系统”之间纠结了很久。最后定下来做这个“电动车骑行规范识别系统”，很大一部分原因是它足够完整：有真实应用场景、有明确的检测目标、能覆盖数据标注到模型训练再到系统部署的全流程，而且难度可控。现在这套项目的源码和论文都已经整理好开源了，我把整个实现过程复盘一遍，从需求拆解、数据处理、模型选型，到训练调参、系统实现、论文写作，以及那些踩过的坑，一次性讲清楚。如果你也在考虑类似的毕设方向，或者想快速上手YOLO系列做实际的视觉检测项目，这篇应该能帮你省下不少时间。

1. 项目定位与核心需求拆解

1.1 这个系统到底要解决什么问题

电动车骑行规范这个场景，实际要管的事情很多：最常见的是骑行者不戴头盔，其次是违规载人、加装遮阳伞、骑行时看手机，甚至逆行。但毕设的体量有限，不可能把每个问题都做成一个完美的算法模块。我在设计时把需求收敛成了两个核心检测任务和一个扩展任务：

• 头盔佩戴检测：确认电动车上的人员是否佩戴头盔。
• 载人识别：判断是否存在搭载额外乘员的情况。
• 扩展任务：骑行人数的统计与超员告警（属于载人识别的一种延伸）。

这个收敛很重要。很多同学做毕设上来就想“全都要”，结果数据集要采集、模型要训练、系统要开发，最后每块都做不深。我直接把需求拆成“看得见的目标检测”和“看得懂的业务规则”两层。目标检测负责把画面中的人、骑手、头盔、手机等物体找出来；业务规则层再根据检测框之间的空间关系做综合判断，比如头盔框是否与头部框匹配，电动车区域里是否出现了两个以上的人。这样既保证了系统的实用性，又把算法训练的难度控制在一个人能完成的范围内。

1.2 为什么选YOLO11而不是其他模型

选型这事我考虑过几种方案。两阶段检测器（比如Faster R-CNN系列）精度确实不错，但推理速度慢，在视频流场景下很难做到实时，而且部署到CPU设备上的体验很糟糕，不适合做成演示系统。一阶段检测器里面，YOLO系列是绕不开的选项。

YOLO11是2024年推出的版本，相比大家更熟悉的YOLOv8，它在结构上做了几处关键改动：骨架网络里用了C3k2模块替代了部分C2f结构，还引入了C2PSA（卷积块加多头自注意力）来增强特征提取能力，同时通过更高效的结构设计把参数量和高延迟降了下来。简单说，就是速度和精度的平衡做得更好了。实际做对比实验的时候，我用相同的数据集训练了YOLOv8n和YOLO11n，YOLO11n在mAP50上高出约1.5到2个百分点，而且推理速度还快了一点。做毕设选它，既有“新模型”的亮点可以写进论文，又不会因为太新而找不到参考资料。

1.3 版本选择和算力约束

YOLO11提供了n、s、m、l、x五个基础版本，还支持pose、seg等扩展版。我做的是目标检测任务，所以用的是yolo11n和yolo11s两个版本。YOLO11n参数只有大概2.6M，计算量很小，CPU也能勉强跑推理；YOLO11s精度更高，适合在GPU机器上跑。毕设场景比较推荐n版起步，先跑通流程，有时间再用s版做高精度实验。切记不要一上来就训练l或x版，显存占用高，训练时间动不动就是n版的数倍，对只有一块入门显卡的学生来说非常不友好。后面我也会给出具体的训练参数建议。

2. 数据准备与标注工程

2.1 数据从哪里来，怎么搭配

深度学习项目里有一句话叫“数据和特征决定了结果的上限”。这个项目的公开数据集并不好找，专门针对电动车的开源数据很少，但摩托车头盔检测的数据集是可以直接借鉴的，因为骑行场景高度相似。我用了几类数据源的组合：

• 公开摩托车头盔检测数据集，主要是标注好的头盔和骑手图片，作为基础数据。
• 网上搜集的电动车骑行图片，覆盖不同城市、不同天气、不同角度。
• 自己拍摄的路口和校园门口视频截帧，这部分是数据集的“灵魂”，保证场景和你最终部署的场景一致。

三个来源的比例大致是4:4:2。这里有个容易被忽略的点：公开数据集大多标注的是“摩托车”，有些图里骑手戴的是全盔或半盔，而城市电动车用户更多戴的是电动自行车头盔，外观差异不小。如果只靠公开数据，模型很容易把“特征感强”的摩托车头盔学得很好，到了电动车场景就疯狂漏检。所以一定要加入自采数据，让模型见到你的目标场景长什么样。

2.2 类别设计：别把问题搞复杂

最初我参考了一些论文，设计了“person”、“rider”、“helmet”、“head”、“phone”五个类别。后来发现类别越多，标注成本越高，且类别之间容易出现混淆（比如戴头盔的head和不戴头盔的head）。多种尝试之后，我把检测类别精简为四个：

这个设计的巧妙之处在于：不直接检测“是否戴头盔”，而是检测“头部”和“头盔”这两个独立目标，然后用逻辑判断它们的位置关系。这样模型只需要学“什么是头盔”和“什么是头部”，不需要去学“戴上头盔的头部”这种复杂语义。数据标注的时候，只要保证头部框和头盔框分开标、不重叠，就能为后面的规则判断提供干净的输入。很多人做这个项目时喜欢直接标“戴盔人/未戴盔人”两类，也不是不行，但遇到骑手手里拎着头盔的场景就会翻车，因为模型会困惑这个头盔到底算戴了还是没戴。

2.3 标注规范和细节

我用的标注工具是LabelImg，导出的格式是XML，之后转成了YOLO格式的TXT。这里有一条很重要的标注规则：头盔遮挡了多少，就标多少，不要凭感觉把被身体挡住的部分也画进框里。因为YOLO这类检测器学的是“框内物体的特征”，如果框里只有露出的半截头盔，你却画了整盔的框，训练时就会给模型灌输错误信息，推理时目标一遮挡就掉检测。

针对电动车骑行场景，我总结了几个具体标注原则：

• 骑手头部被头盔挡住时，头部框仍然要标，并且保持和头盔框的位置基本重合。这样逻辑层才能通过IOU来判断“这个头确实被这个头盔覆盖”。
• 远处的骑手在画面里不到20像素大小时，只标不评选，或者直接忽略，避免给训练集注入大量低质量标签。
• 后面的载人乘客如果只露出半个身体，也要标person，这是载人判断的关键依据。
• 手机目标很小，标注时放大图片再精细框选，框尽量贴合手机边缘。

2.4 数据增强与分析

几轮训练之后，我发现模型对戴头盔的骑手检测很稳，但小目标的头盔框经常漏掉。于是除了Ultralytics自带的增强配置外，我又单独加了两种手段：把输入分辨率从640提升到1280做高分辨率训练（后面细讲），以及针对小目标使用简单的过采样策略——把包含大量小目标的图像复制一份放进训练集。此外还做了亮度增强、随机旋转、水平翻转。水平翻转对头盔检测没影响，不用特意关掉。

数据集的划分上也有讲究。不能简单的随机划分，因为自采的视频截帧往往一帧帧都很相似，随机划分容易让同一时间段的相似画面同时出现在训练集和验证集，导致验证集mAP虚高。我是按视频来源划分的：同一个视频的帧只归入一个集合。这叫做“按组划分”，能真实反映模型见新场景时的表现。这一点写论文的时候也值得单独提出来，说明你的验证结果是可信的。

3. 模型训练与调优过程

3.1 环境搭建和基础训练流程

YOLO11的训练非常简单，因为官方已经把整套流程封装得很完善了。环境上我是用Anaconda建了Python 3.10的虚拟环境，装PyTorch 2.3.0加CUDA 11.8，再安装Ultralytics库。训练命令一条就能跑起来：

yolo train model=yolo11n.pt data=helmet.yaml epochs=150 imgsz=640 batch=16 device=0

需要注意的是，第一次用官方预训练权重（yolo11n.pt），默认是在COCO数据集上训练过的。这个预训练权重直接用来做迁移学习效果很好。训练时默认会冻结前几层，如果数据量比较少（比如只有两千张图），建议保持默认，不要解冻全部层，否则容易过拟合。

yaml文件是数据配置的核心。上来的同学最容易在这里写错路径。data.yaml里的path、train、val都建议用绝对路径，或者统一放在项目根目录下用相对路径。之前我给一个朋友排查训练报错，用“Error opening data file”搜索了半天，最后发现就是yaml里路径写的不对，模型读不到数据集。

3.2 超参数怎么定

这一块直接关系到训练效果，值得重点说。很多教程上来就告诉你“用默认参数就行”，但如果你的数据集和COCO差异大，默认参数不一定最优。我最后定下来的一套参数是：

imgsz为什么选1280而不是640？因为头盔在监控画面里属于小目标，经典YOLO在640分辨率下对二三十像素大小的目标几乎只能靠“猜”。把输入分辨率提高到1280之后，小目标的像素面积相当于扩大了四倍，检测能力明显提升。代价是训练速度和推理速度都受到影响，显存占用也翻倍。我在训练n版的时候，1280分辨率、batch为8，单卡显存占用约10GB，如果你用的是6GB显存的显卡，建议要么降到imgsz=960，要么用梯度累积把batch降下来。梯度累积的设置如下：

from ultralytics import YOLO model = YOLO("yolo11n.pt") model.train( data="helmet.yaml", imgsz=1280, batch=4, epochs=150, optimizer="AdamW", lr0=0.001, weight_decay=0.0005, device=0, amp=True )

你可能会问，batch变小了之后梯度累积怎么体现。Ultralytics库本身没有直接暴露梯度累积参数，在显存不足的时候最简单的方式就是降低batch，然后适当降低学习率，或者增加训练轮次来弥补。我做实验时用batch=8训出的模型比batch=16低了大概0.8个点mAP，属于可接受范围。

3.3 训练过程中的评估指标怎么看

训练结束后，输出目录里会生成一堆结果文件。我不建议只盯着最后的mAP数字，而是要会看weights目录下最有价值的几个图：

• results.png：训练过程中loss曲线、mAP曲线、PR曲线。
• confusion_matrix.png：混淆矩阵，能看到哪两类目标最容易搞混。
• F1_curve.png：不同置信度下的F1值，帮你选最佳阈值。

我训练到大概120轮的时候，mAP50已经不再上涨了，loss还在缓慢下降。这说明模型已经趋于稳定，之后随时可以停止。最终结果大致是这样的：

这个对比实验结果我直接写进了论文，因为它能清晰说明两件事：YOLO11相比上一代模型有可感知的提升；提高输入分辨率对骑行场景的小目标检测有明显收益。论文的对比实验和消融实验都有了素材。

3.4 模型导出和推理优化

训练完只是第一步，毕设答辩时还要现场演示。为了兼容不同部署设备，我把模型导出成了三种格式：

yolo export model=best.pt format=onnx imgsz=1280 yolo export model=best.pt format=openvino imgsz=1280 yolo export model=best.pt format=tensorrt imgsz=1280

ONNX是通用的中间格式，OpenVINO适合在Intel CPU上推理，TensorRT则只能在NVIDIA GPU上使用。实际部署时我主要用ONNX格式加ONNX Runtime推理，速度跟PyTorch原生推理差不多，但不用每次启动都加载整个训练框架，节省内存。如果你要在没有GPU的笔记本上演示，OpenVINO版本会是更好的选择，CPU推理速度比PyTorch快不少。注意导出onnx时也要指定imgsz=1280，因为模型的输入尺寸是在导出时写死的。

4. 系统设计：从检测结果到业务告警

4.1 系统模块怎么划分

检测模型只是系统的心脏，大脑还得靠业务逻辑。整个系统的模块划分大致是这样：

• 数据接入模块：支持视频文件、RTSP摄像头流和单张图片输入。
• 检测推理模块：加载ONNX模型对每一帧做目标检测。
• 业务规则模块：根据检测框计算头盔佩戴状态和载人情况。
• 告警与展示模块：生成告警截图、记录日志、推送前端展示。

线程模型上，我开了三个线程：一个专门做视频帧读取和解码，一个做目标检测，一个做业务逻辑和结果存储。检测线程消费帧队列，每2帧处理一次（跳帧处理），保证在1080p视频流上不掉队。这里有个经验：视频读取本身是耗时的IO操作，如果和检测放在同一个线程里，会出现“显示画面滞后、卡顿”的问题。分开之后整个流就顺畅了。

4.2 头盔佩戴判断的算法逻辑

这是系统最核心的规则部分。我用的判断方法是空间关系匹配法：对于检测到的每个rider_head框，计算它与所有helmet框的IoU（交并比），取最大IoU值。如果最大IoU大于0.4，就判定该骑手佩戴了头盔；否则判定为未佩戴。

为什么要用IoU而不是简单判断“helmet框是否包含head框”？因为实际画面里，头盔框和头部框的标注并不会完全重合，头盔框通常比头部框大一圈，两者是包含关系而不是等同关系。IoU能够容忍一定程度的框偏移，比“包含”判断要稳。如果觉得0.4不好记，也可以改成“helmet框面积中落在head框内的比例”，我用IoU当作统一衡量标准后，误报率比“中心点距离判断”低了不少。

调整阈值时也有讲究。把IoU阈值调小（比如0.2），可以降低漏判，但会把“手里拿头盔”误判为“戴了头盔”；调大到0.6，可以减少误报，但容易把戴了半盔的骑手判成未戴。我最后用验证集做网格搜索，F1值在0.4附近达到峰值，就锁定了这个值。

4.3 载人识别的判断逻辑

载人判断要比头盔判断复杂一些，因为画面里除了骑手，还可能有路过的行人。我的做法是：先设置一个电动车检测区域（在视频画面里用多边形框出车道区域），只统计区域内出现的人体目标。区域内检测到的人体框数量大于1，就判定为载人。为了避免把旁边走路的行人算进来，再用“骑手框”做锚点：找到置信度最高的骑手，计算其他人体框的中心点与骑手框的距离，距离小于骑手框宽度两倍的，才认为是同车乘员。

这个逻辑还触发过几次误报，比如骑手等红灯时旁边站着一个行人，两人的身体框挨得很近，就会被误判成载人。后来我加了宽度比例判断：只有其他人体框宽度明显小于骑手框宽度时，才判定为“后座乘员”，否则很可能是并排行人。虽然也不是完美，但误报率从12%降到了大概4%。

4.4 Web可视化与告警模块

系统用Flask做后端，前端页面通过HTTP接入。登录后可以看到实时监控画面，画面的每一帧上会绘制检测框，并在画面左上角显示当前判定状态。一旦检测到未戴头盔或载人事件，系统就会自动把当前帧保存为告警截图，并把事件写入SQLite数据库，同时触发页面上的告警通知和声音提示。

告警保存为什么用SQLite而不用MySQL？毕设阶段数据量小，SQLite零配置、单文件、移植方便，不用装数据库服务，答辩前部署到新机器上也不容易出问题。如果你后续想接更多路摄像头，再换MySQL不迟。

前端展示我用了Video标签加Canvas绘制检测框，没有用重型框架。每500毫秒从后端拉取一次最新的检测结果JSON，叠加到画布上。这样实现简单、浏览器的CPU占用也低，足以支撑答辩演示。

5. 常见问题与排查实录

5.1 GPU显存不足，训练直接OOM

这是被问得最多的一个问题。训练时报“CUDA out of memory”，基本都是因为显存太小、输入分辨率或batch设得太高。我的排查顺序是：先把batch降到2，如果还报错，再把imgsz降到640。如果两个都降到合理值还是不够，说明该换云平台了。另外检查一下是不是tensorboard或WANDB在后台占用显存做可视化，把它们关掉能省出不少显存。最后记得在train参数里加上amp=True，混合精度训练对显存非常友好。

5.2 小目标头盔漏检严重

如果你在部署监控画面时发现“远处的电动车头盔完全识别不到”，第一反应不应该是调参数，而是回到训练阶段。最有效的手段就是提高输入分辨率，从640提到1280甚至1536。其次是把NMS的置信度阈值调低一些，比如从0.25降到0.15，配合IoU阈值0.45，可以多召回一些小目标。另外，如果视频流分辨率本身是4K，建议做分块推理：把大图切成两个1440x1280区域分别检测再合并。这个方法一般能提升小目标召回率，但实际帧率会下降，需要看情况取舍。

5.3 夜间和阴雨天效果崩坏

现实中的电动车骑行监控，夜晚是个绕不开的坎。如果采集的训练数据全是白天的，模型一到晚上就“半瞎”。我做过一次对比：白天夜间的mAP50分别是93.4%和61.2%，差距巨大。解决思路有两个：一是专门采集夜间、黄昏、雨天的数据放进训练集，让模型见足够多的低光样本；二是做图像预处理，推理前把暗帧做直方图均衡化或自适应亮度增强。实测在加入2000张夜间数据后，夜间mAP50能恢复到接近80%。如果你们学校场地有条件，甚至可以直接在路口架设备采集一整个晚上的视频，效果比任何图像增强算法都管用。

5.4 戴头盔的头部和未戴头盔的头部混淆

这类混淆在混淆矩阵上表现得很清楚。原因往往有两个：数据集里某些人手举头盔，头盔框画得过大，导致IoU让逻辑层判成了“戴头盔”；或者头盔颜色和肤色很接近（比如米白色头盔在强光下发白，和肤色混淆）。针对前者，要在标注时重点把“手持头盔”也标注成单独的情况，或者在规则层增加“头盔是否和头部重叠”的判断。针对后者，可以刻意收集一些浅色头盔的数据，并在训练时稍微增大HSV增强里的饱和度扰动。

5.5 答辩阶段容易被问倒的问题

论文写到最后一章，答辩老师最爱问的问题主要集中在：为什么用这个模型、数据和标注怎么来的、系统的实时性如何保证、这个方案在什么条件下会失效。我的建议是提前准备一份“失败案例分析”，挑三张系统判错的图，准备好解释模型为什么会错、可以通过增加数据还是调整阈值来缓解。比如我手里有一张逆光骑行图，模型把戴头盔的骑手漏检了，原因是头部和头盔在强光下对比度过低，特征丢失。这种真实的失败分析，比堆十页“实验结果良好”更能拿分。论文的实验部分不要只写精度，一定要写pipeline各个模块各自花费的时间，才能支撑“系统满足实时性要求”这个结论。

最后再说一个个人体会。做这个项目最大的收获，不是学会了怎么调参数，而是理解了一个检测模型落地成真实系统需要跨越的多道鸿沟：公开数据和你真实场景的差异、标注质量对模型上限的约束、逻辑规则与目标检测结合时的边界情况、以及部署环境对性能的无情压榨。这些在课堂和教程里很难学到，只有自己把数据标注、训练、部署、答辩的流程完整走一遍，踩几个坑，才能真的懂。

如果你打算做类似的方向，我的建议是不要迷信网上现成的源码包。拿到开源代码后，一定要自己重新标注一部分数据、改写一部分规则、重新调一遍参数。只有经过这个“重新走一遍”的过程，你才能在答辩时自然地讲出每个模块的设计理由，而不是被问两句就露馅。这也是我把源码和论文同步开源的原因——不是让你复制粘贴，而是希望你能站在一个能互相讨论的起点上，快速进入状态，把精力花在真正值得花的地方。