简介本资源是一个基于YOLO算法的实时安全带检测系统完整实现面向深度学习初学者、计算机视觉开发者及智能交通安防领域实践者解决车辆驾乘人员未系安全带行为的自动识别与预警问题适用于车载终端、驾校监管、共享汽车安全审计等实际场景。压缩包共17个文件包含7张标注图像jpg、2个模型权重文件best.pt与yolov11.pt、1个核心推理脚本app.py、1个Streamlit配置文件config.toml、1个依赖清单requirements.txt、1个README说明文档及辅助文件整体大小为10.31MB图像与模型文件支撑端到端训练与推理Python脚本封装了数据加载、模型调用与结果可视化全流程。已有61人学习下载资源提供开箱即用的检测能力——无需从零训练可直接运行app.py启动本地检测界面或通过Streamlit快速部署交互式Web演示同时附带典型样本图像与输出示例output.png便于理解输入输出逻辑与模型泛化表现。1. 项目概述与整体设计思路1.1 安全带检测到底在解决什么问题车辆安全带检测这个需求在国内落地场景非常多。最常见的三类一是交通违法抓拍电子眼拍下驾驶位画面后系统自动判断司机有没有系安全带二是运输企业监控两客一危车辆的DMS摄像头每天产生海量视频流靠人工盯屏根本看不过来必须上算法做实时提醒三是施工工地、矿山等特种车辆的作业规范管理要求驾驶员和副驾乘客都必须系安全带这类场景往往还需要联动闸机或报警系统。我最初做这个项目起因是帮一家运输公司做车辆主动安全系统的POC验证。对方的痛点是车队有200多台车每台车装了两个摄像头一个看路面、一个看驾驶室每天回传的视频有几千个小时安全员抽查率不到5%违章行为基本发现不了。当时试过几种传统方案比如基于Haar特征的级联分类器、基于肤色分割的方法效果都很差——问题在于驾驶室内光线变化剧烈逆光、夜间、戴墨镜、穿深色衣服等情况都会让传统特征失效。后来换到YOLO方案用目标检测的思路直接检测安全带区域问题一下子简化了很多。1.2 为什么选用YOLO而不是其他检测方案YOLO在安全带检测上天然有优势这个选择不是拍脑袋。先说两点最直接的速度与精度的平衡安全带检测往往跑在嵌入式设备或实时视频流上比如NVIDIA Jetson Orin、RK3588这类边缘盒子算力有限。YOLO系列从v5到v8、v11在T4或者Orin上轻松跑几百FPS同时mAP能做到80%以上这个指标组合是两阶段检测器如Faster R-CNN很难做到的。工程落地简单YOLO系列的开源生态极其完善从训练到部署都有成熟链路。PyTorch训练、ONNX导出、TensorRT加速、rknn模型转换每一步都有大量现成案例。对于做实际项目的人来说这意味着可以在很短时间内把模型跑到设备上而不是花大量时间调底层实现。另外补充一点安全带检测本质上属于小目标检测问题。在驾驶室画面里安全带斜跨胸口区域占整张图的比例不大而且背景复杂方向盘、中控台、衣物纹理都会干扰。早期我用过YOLOv3效果一般换成YOLOv5s之后漏检率明显下降后来YOLOv8出来把C2f结构和anchor-free头一换小目标的表现又上了一个台阶。现在新出的YOLOv11在边框回归上做了进一步优化检测精度更高实测下来驾驶位场景比v8强不少。1.3 系统整体架构拆解一个完整的安全带检测系统不只是一个模型文件它是一个包含数据采集、标注、训练、部署、告警联动的闭环系统。下面我把整体架构画一下不用图用文字描述。整个系统由四个部分组成数据采集端包括驾驶室内摄像头、视频流接入网关支持RTSP/GB28181协议、视频抽帧模块。算法识别端核心是YOLO检测模型输入单帧图像输出安全带佩戴状态佩戴/未佩戴、置信度、目标框坐标。业务告警端根据检测结果结合业务规则例如车速大于20km/h才告警、单次告警周期内不重复触发生成告警事件推送至管理平台或短信、语音播报。管理后台负责模型发布、阈值配置、告警记录查询、统计分析。用表格概括一下各模块的职责和关键技术选型模块核心职责关键技术/工具数据采集多路视频接入、抽帧存储FFmpeg、OpenCV、海康SDK数据标注目标框标注、标签分类LabelImg、LabelStudio、CVAT模型训练模型迭代优化PyTorch、YOLOv8/YOLOv11推理部署模型加速、实时响应TensorRT、ONNX Runtime、RKNN业务告警规则判定、事件推送自研告警服务、WebSocket标题里带zip说明这是一个完整打包好的工程训练代码、推理脚本、模型权重甚至部署文档都在里面。这种形态对于很多企业来说非常友好至少拿来就能用不用再从零搭环境。2. 数据准备安全带检测模型的基石2.1 数据集从哪来三个来源和一种兜底方案模型的性能上限是由数据决定的这句话在安全带检测这个特定任务上尤其适用。为什么因为安全带检测场景高度固定摄像头安装位置基本固定一般在A柱、后视镜附近或仪表台上方驾驶员位置固定画面角度变化不大。这种场景下数据完全可以用较少但要精准的策略来打。我在实际项目中数据集来自三个渠道公开数据集网上有一些驾驶行为相关的公开数据集比如State Farm Distracted Driver Detection、AUC Distracted Driver Dataset虽然不是专门做安全带检测的但图像里包含了驾驶室场景可以抽取其中能看到安全带的样本手动框一部分做预训练。自采数据这是占比最大的部分。在我们自己的测试车上安装摄像头覆盖不同时间段白天、黄昏、夜间、不同天气晴天、阴天、雨天、不同驾驶员体型差异会影响安全带贴合程度、不同服装深色衣服、浅色衣服、反光面料。网约车/出租车合作数据如果条件允许可以跟运输公司合作获取真实运营场景的车内视频这种数据最贴近实际部署环境。这个渠道需要签订数据使用协议注意隐私合规问题。兜底方案是合成数据。有同事尝试过用Unity或Unreal Engine搭建虚拟驾驶室把不同体型的虚拟人物、不同安全带颜色渲染出来生成带自动标注的合成数据集用来补充边缘场景比如极端逆光、深夜无路灯路段。实测下来合成数据可以提升模型对颜色和遮挡的鲁棒性但对于真实驾驶室的纹理复杂性还是替代不了真实数据。2.2 标注规范和标签体系设计安全带检测的标注规范比想象中有讲究。常见做法是把安全带当成一个整体框出来标注类别叫seatbelt。但这个方案有坑——安全带的实际形态是斜跨胸口的一条带状区域目标框如果只框中间段训练出的模型容易丢失全局上下文导致遮挡时识别不出来。更稳妥的做法我看很多做DMS的同行都在用分段标注类别一belt安全带从肩部到腰部斜跨的整段类别二no_belt未系安全带时从肩部垂落到座椅一侧的空带不推荐的做法是直接标person、belt两个类别然后靠两个框的空间关系判断是否系安全带。因为安全带和人的空间关系比较复杂安全带框不一定完全贴合人的区域额外的逻辑判断会引入新的误差。标注时的几个细节建议目标框要贴合安全带的边缘不要把背景包进去太多否则模型学到的是背景纹理。安全带和衣物颜色相近时要放大图片看清边缘再框宁可多花点时间不要为了速度牺牲标注质量。遮挡场景单独标注比如手搭在方向盘上正好挡住安全带中段的这种样本单独归为belt因为虽然遮挡但从上下段可以推断是系了的但是要确保训练集里这类样本的数量不超过总数的10%-15%否则模型会过度依赖局部特征。夜间样本的标注要特别注意如果红外相机下安全带显示为暗色需要在标注时参考前后几帧比如车门关闭前安全带的可见状态判断是否真的系了。2.3 数据增强与样本平衡技巧安全带检测场景的数据增强和通用目标检测有点不一样。因为驾驶室画面相对固定你不能用太激进的增强策略去破坏画面结构否则模型会在部署时失真。我常用的增强组合如下表所示增强方法参数设置适用原因Mosaicv8/v11内置默认丰富背景多样性增强小目标随机亮度对比度brightness0.2, contrast0.2模拟不同时间段光照变化随机HSV调整hue0.015, sat0.3, val0.3应对不同颜色的衣物和安全带随机旋转最大±10度模拟摄像头安装角度偏差随机透视变换轻微模拟不同车型视角差异Cutout少量模拟方向盘、手臂对安全带的遮挡一个很关键的经验不要去用水平翻转。因为在驾驶位场景中司机座位在左边中国是右舵车则相反水平翻转后画面布局和部署时的实际画面不一致模型学习到的是错误的空间特征实测会掉2-3个点的mAP。另外随机裁剪的幅度也别太大因为驾驶室的目标尺寸本来就小裁剪过多会导致安全带目标变得更小甚至漏出画面。样本平衡方面未系安全带负样本的数量通常比系了安全带正样本少很多这会带来两个问题一是模型对负样本的召回率偏低二是容易把未系安全带的样本误判为正样本。解决办法不是粗暴地复制负样本而是采用离线增强针对负样本单独做亮度抖动、对比度调整、加高斯噪声扩充到正负样本比接近1:1.5。这个比例值是经验值正样本略多没问题因为安全带的特征更稳定负样本往往要覆盖更多不规则情况。3. 模型训练全流程从配置到调优3.1 环境配置与工程目录规划拿到一个打包好的基于YOLO的安全带检测系统.zip第一步当然是解压看目录结构。一般的工程目录大概长这样. ├── data │ ├── images │ │ ├── train │ │ └── val │ ├── labels │ │ ├── train │ │ └── val │ └── dataset.yaml ├── models │ ├── yolo11s-seatbelt.pt │ └── yolo11m-seatbelt.pt ├── runs │ └── detect │ └── train ├── scripts │ ├── label_convert.py │ ├── train.py │ ├── infer_image.py │ ├── infer_video.py │ ├── export_onnx.py │ └── deploy │ ├── trt │ └── rknn ├── requirements.txt └── README.md环境配置建议直接用conda或venv隔离避免污染系统Python。YOLOv8/YOLOv11通过pip install ultralytics安装依赖自动处理。有一点要注意如果训练机是Linux环境且有多张GPUultralytics默认会使用所有可用GPU这在小数据集上反而浪费显存设置device0即可固定第一张卡。数据集目录结构上images和labels应该分别存放图片和txt标注文件txt文件名必须和图片名一一对应。每行标注格式为class_id x_center y_center width height其中坐标都是归一化到0到1的浮点数。这个格式和COCO、VOC都不同所以从公开数据集转过来时写一个转换脚本是必须的。3.2 标签格式转换脚本演练如果之前用的是LabelImg的VOC格式xml转换成YOLO格式的txt需要写个脚本。这一步看起来简单但很多人栽在归一化坐标上所以我把核心代码贴出来边写边解释。import os import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, out_txt_path, classes): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.findall(object): cls_name obj.find(name).text if cls_name not in classes: continue cls_id classes.index(cls_name) bbox obj.find(bndbox) xmin float(bbox.find(xmin).text) ymin float(bbox.find(ymin).text) xmax float(bbox.find(xmax).text) ymax float(bbox.find(ymax).text) x_center (xmin xmax) / 2.0 / img_w y_center (ymin ymax) / 2.0 / img_h width (xmax - xmin) / img_w height (ymax - ymin) / img_h lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) with open(out_txt_path, w, encodingutf-8) as f: f.write(\n.join(lines)) classes [belt, no_belt] for xml_file in os.listdir(xml_annotations): if not xml_file.endswith(.xml): continue xml_path os.path.join(xml_annotations, xml_file) out_txt_path os.path.join(labels, xml_file.replace(.xml, .txt)) voc_to_yolo(xml_path, out_txt_path, classes)注意一个细节x_center、y_center归一化后需要限幅到0-1有些标注工具的规范不严格可能会出现1.0左右的数值比如xmax正好等于图像宽度虽然训练时不会直接报错但在NMS阶段可能导致边界框异常建议在脚本里加上max(min(value, 1.0), 0.0)这样的限幅。3.3 训练参数配置与调参思路数据准备完成后关键就是训练参数。这个项目我推荐从YOLOv8s或YOLOv11s这款轻量模型开始不要一上来就用大模型因为安全带检测的目标小而少大模型容易过拟合而且边缘设备部署时推理延迟会高很多。训练命令的模板yolo detect train data/path/to/dataset.yaml modelyolo11s.pt epochs200 imgsz640 batch16 device0 patience50 optimizerSGD lr00.01 lrf0.01几个关键参数的说明imgsz640对于驾驶室场景640像素足够。再大比如1280会提高对小目标的召回但推理速度下降明显对于边缘设备来说不划算。如果追求极致精度可以尝试用imgsz960训练然后用imgsz640导出但收益不大不如把时间花在数据上。batch根据显存调整8GB显存用816GB用16。如果batch太小BN层统计不稳定容易导致训练震荡。patience50早停机制连续50个epoch验证集没有提升就停止。安全带检测数据集不大一般不到100个epoch就收敛了不要硬跑完200个epoch。optimizerSGDvsAdamW实测SGD余弦退火在YOLO系列上更稳收敛曲线平滑AdamW前期收敛快但后期容易过拟合。class weights如果负样本较少可以在dataset.yaml里配置class_weights: [1.0, 1.5]提高no_belt类别的损失权重让模型更关注未系安全带的样本。训练过程中要重点观察两个曲线train/loss和metrics/mAP50-95(B)。如果loss下降缓慢且mAP曲线存在明显震荡大概率是学习率太大或数据集的标签噪声较高此时不是一味调参而是去检查几百张标注看看有没有框错、漏框的样本。3.4 模型评估标准安全带检测模型的评估不能只看mAP。因为在真实业务中漏报和误报的成本不一样。漏报没系安全带但系统认为系了会影响安全监管误报系了但被判未系会打扰司机推送不必要告警。所以除了mAP还要看未系安全带的召回率Recall of no_belt这个指标必须高我通常要求大于95%。模型如果在这里失守系统就没有实际价值。误报率FP per frame即每帧中系了安全带却被误判为未系的概率。业务上要求低于1%否则一天下来一个车队会产生几百条虚假告警安全员会对系统失去信任。F1-score综合看precision和recall的平衡如果业务告警和人工复核相结合F1维持在0.9以上就可以上线。4. 推理与部署把模型搬到实际场景中4.1 图片与视频流推理脚本模型训练好之后第一件事是拿真实图片测试效果。写一个简单的推理脚本from ultralytics import YOLO import cv2 model YOLO(runs/detect/train/weights/best.pt) # 单张图片推理 results model.predict(test_images/case1.jpg, conf0.35, imgsz640, verboseFalse) # 保存可视化结果 results[0].save(output/case1_result.jpg) # 视频/视频流推理 cap cv2.VideoCapture(rtsp://192.168.1.100:554/stream1) while cap.isOpened(): ret, frame cap.read() if not ret: break results model.predict(frame, conf0.35, imgsz640, verboseFalse) # 结果后处理 for r in results: boxes r.boxes.xyxy.cpu().numpy() cls_ids r.boxes.cls.cpu().numpy() confs r.boxes.conf.cpu().numpy() for box, cls_id, conf in zip(boxes, cls_ids, confs): # class 0 belt, class 1 no_belt label Safe if int(cls_id) 0 else Unsafe cv2.rectangle(frame, (int(box[0]), int(box[1])), (int(box[2]), int(box[3])), (0, 255, 0), 2) cv2.putText(frame, f{label} {conf:.2f}, (int(box[0]), int(box[1]) - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2) cv2.imshow(Seatbelt Detection, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()conf阈值的选择有点讲究。调高了误报少但漏报会增加调低了漏报少但误报增加。经过大量场景测试我发现0.3到0.4之间是最佳区间。如果部署的摄像头安装位置和训练数据差异不大可以设高一点0.4如果部署场景多样建议设低一点0.3靠业务侧的逻辑如时间连续性来过滤误报。一个非常实用的技巧对单帧的告警不要立即触发而是采用多帧确认机制——连续5帧、至少3帧检测为未系安全带才判定为一次事件。这样能有效规避视频流中单帧误检、运动模糊造成的抖动问题。实现起来就是在业务逻辑里加一个计数器成本很低但对用户体验的影响非常大。4.2 导出ONNX并做TensorRT加速为了在边缘设备上达到实时性能导出的pts模型需要先转成ONNX再转成TensorRT的engine文件。转换命令如下yolo export modelbest.pt formatonnx dynamicTrue imgsz640 opset12导出后可以用onnxruntime做一次精度验证import onnxruntime as ort import numpy as np import cv2 session ort.InferenceSession(best.onnx) input_name session.get_inputs()[0].name img cv2.imread(test.jpg) img cv2.resize(img, (640, 640)) img img[:, :, ::-1].transpose(2, 0, 1) # BGR - RGB, HWC - CHW img np.expand_dims(img, 0).astype(np.float32) / 255.0 outputs session.run(None, {input_name: img})在NVIDIA设备上更推荐走TensorRT速度能再提升2到4倍。转换流程ONNX - TensorRT engine可以用trtexec工具做转换trtexec --onnxbest.onnx --saveEnginebest.engine --fp16--fp16半精度推理对精度损失很小实测mAP损失0.3%以内速度提升明显。这里有个小坑TensorRT转换时如果模型包含动态shape需要指定--minShapes、--optShapes、--maxShapes否则推理时会报错。如果摄像头输入分辨率固定比如1080P建议直接用固定shape省事且性能最优。4.3 部署到瑞芯微NPU等边缘设备很大一部分安全带检测项目最终会跑在国产边缘设备上尤其是瑞芯微RK3588、算能盒子这类带NPU的硬件单价低、功耗低、适合车载场景。YOLO模型要转成RKNN格式才能跑在NPU上官方提供了rknn-toolkit2转换工具rknn_convert.py --onnx model.onnx --output model.rknn --target rk3588 --fp16转换时有几个注意事项RK3588的NPU对某些算子的支持有限ONNX里的Resize、Reduce等算子可能会被优化掉但SiLU、Conv这些常规算子没问题。如果转换失败检查一下opset版本建议用opset12太高的算子版本容易出兼容问题。在NPU上跑YOLO时预处理如归一化尽量放在NPU内部完成避免CPU到NPU的数据拷贝浪费带宽。rknn-toolkit2支持在转换时配置mean_values和std_values把/255.0的操作一并融合进模型。多路视频流场景下NPU的算力分配需要注意。RK3588可以同时跑1路1080P30fps的YOLOv8s检测加上一路车辆检测但再多路就会帧率下降。建议用硬件解码模块Mpp先解码再把帧送到NPU不要用OpenCV去软件解码否则CPU会成为瓶颈。5. 常见问题与排查技巧实录5.1 训练指标异常的排查路径情况一loss前期就不下降一直是平的。先检查数据。最常见的原因是标签文件里出现了0值或负数坐标这类脏数据会在反向传播时给模型注入错误的梯度信号。写一个基线检查脚本遍历所有txt文件排除值为0或大于1的坐标行基本能解决。另一个原因是数据集中有大量无法辨认安全带的严重模糊、过曝图片这种图片让人工标注都费劲更别提训练。建议清洗掉。情况二训练loss下降但mAP始终在0.3左右徘徊。大概率是类别不平衡过于严重。比如训练集中belt样本有1万张no_belt只有200张模型学到的几乎全是正样本的特征对负样本几乎没有区分能力。解决方法是回到数据集专门补充未系安全带的样本。如果补充不了就把所有no_belt样本做离线增强复制成5份让这个类别的数量不再边缘化。情况三mAP高但实际视频里有大量漏检。这个问题往往出在anchor设置或输入分辨率上。安全带目标在1080P画面里大约占40x120像素如果以640分辨率输入训练目标被压缩到20x60左右检测头已经很难提取到有效特征。建议训练时用imgsz960或者用SAHI这类切片推理工具对大图先切成小块再检测FPS会下降但召回率提升非常明显。5.2 部署后常见的误检与漏检场景部署环境千差万别训练集永远覆盖不全。我在现场踩过的坑总结如下夜间红外模式很多车内摄像头在夜间自动切红外图像变黑白。但训练集如果以白天彩色图片为主模型在黑白图上泛化很差。解决办法是训练时用hsv_h增强模拟灰度或者在数据集中加入部分红外模拟样本把彩色图转灰度后再叠加噪声。安全带被衣物遮挡冬天驾驶员穿厚外套安全带被完全遮住从视觉上根本无法判断。这种场景无论模型多强都无能为力业务侧需要配置规则比如人脸识别和身体姿态分析辅助判断或者干脆在遮拦严重的时段自动降级为人工抽查。摄像头安装位置偏移有些车辆的摄像头装在A柱外面视角有倾斜安全带框在画面里不再是标准斜线而是接近水平或者被变形。这种安装不规范会导致模型误检率高。建议现场部署时使用标定工具输出摄像头姿态角如果偏移过大业务方要重新调整安装位置。强逆光与车窗反光逆光时车窗部位过曝安全带和背景融合在一起。测试时我遇到过模型完全检测不出来的情况。一个有效的处理在图像预处理阶段先做一次自适应直方图均衡化CLAHE把过暗和过曝区域的细节拉出来。虽然模型推理时间会多2-3ms但摄像头精度提升值不值这个时间自己权衡。5.3 告警逻辑与业务规则优化模型输出的是每一帧的检测结果要变成有业务价值的告警事件还需要规则引擎把关。这里我列出几种实用的过滤规则置信度联动连续多帧平均置信度低于阈值的不告警。这能过滤掉隔帧误检的噪声。时间段过滤车辆熄火后可以通过ACC信号获取不检测一天之内同一辆车同一事件的重复告警只推一次事件开始到结束的时间窗口内。多目标处理驾驶位和副驾位要分别判断。用YOLO检测到一个no_belt框是不够的还需要用目标框的位置坐标判断它落在画面左半边还是右半边从而对应是驾驶员还是乘客。联动验证如果有GPS或车辆CAN总线数据可以加入车速判断。车速为0时一般不告警因为车辆静止时解安全带是合规操作比如等待红绿灯时。这些规则的代码实现不复杂但逻辑梳理一定要在生产前做清楚否则上线后告警噪音会让安全员炸毛。6. 进阶改进方向这个项目做好了基础版本之后有几个方向可以继续深挖我在交付过几个项目后的体会是不要一开始就追求高端玩法把基础版本的数据、标注、模型、部署链路吃透再去考虑复杂改进效率更高。如果数据量已经过万、基础模型效果稳定了以下几个方向值得尝试YOLOv11 注意力机制在C2f模块中加入SE或CBAM注意力模块让模型更聚焦安全带区域抑制背景干扰。改进时需要修改模型结构代码ultralytics官方支持自定义模块但会增加训练时间收敛会更慢需要耐心调参。多任务学习同时检测安全带、手持电话、驾驶员面部状态疲劳/分心一个模型输出多个检测头共享Backbone减少边缘设备上的推理成本。这对锚定在车内的多任务DMS系统非常实用。轨迹跟踪状态判定用ByteTrack或DeepSORT对安全带区域做追踪结合时序信息判断安全带状态是否在连续时间内发生变化比如上高速前系了、中途解开比纯单帧判断更准确。针对小目标优化在Backbone中引入高分辨率特征层或者使用FPN的P2层将小目标的特征融合进来。YOLOv8官方对特定数据集效果有限但可以结合AHI模块或自研的小目标检测头做改进让模型在远距离、小尺寸目标上有更高召回。从我个人做实际项目的经验来看这类视觉检测系统的核心壁垒不在模型结构而在于对场景的理解深度和数据治理能力。模型只会告诉你画面里有没有安全带但真实业务里还要知道摄像头装在哪里、光线什么时候变化、司机什么时候为什么会解开安全带、告警怎么推才不打扰人。把这些想清楚了YOLO这个工具自然能发挥出它该有的价值。如果你正准备上手这个项目我的建议是从一个小范围的POC开始先收集1000张左右驾驶室图片标注20个小时训练一个YOLOv8s跑通推理和告警流程再逐渐扩大数据、优化模型。不要一上来就追求动辄几万张的数据量先跑通闭环再迭代细节这样你才能真正理解每个环节里那些文档里不会写的坑。本文还有配套的精品资源点击获取 基于YOLO的安全带检测系统实战：从数据标注到边缘部署
简介本资源是一个基于YOLO算法的实时安全带检测系统完整实现面向深度学习初学者、计算机视觉开发者及智能交通安防领域实践者解决车辆驾乘人员未系安全带行为的自动识别与预警问题适用于车载终端、驾校监管、共享汽车安全审计等实际场景。压缩包共17个文件包含7张标注图像jpg、2个模型权重文件best.pt与yolov11.pt、1个核心推理脚本app.py、1个Streamlit配置文件config.toml、1个依赖清单requirements.txt、1个README说明文档及辅助文件整体大小为10.31MB图像与模型文件支撑端到端训练与推理Python脚本封装了数据加载、模型调用与结果可视化全流程。已有61人学习下载资源提供开箱即用的检测能力——无需从零训练可直接运行app.py启动本地检测界面或通过Streamlit快速部署交互式Web演示同时附带典型样本图像与输出示例output.png便于理解输入输出逻辑与模型泛化表现。1. 项目概述与整体设计思路1.1 安全带检测到底在解决什么问题车辆安全带检测这个需求在国内落地场景非常多。最常见的三类一是交通违法抓拍电子眼拍下驾驶位画面后系统自动判断司机有没有系安全带二是运输企业监控两客一危车辆的DMS摄像头每天产生海量视频流靠人工盯屏根本看不过来必须上算法做实时提醒三是施工工地、矿山等特种车辆的作业规范管理要求驾驶员和副驾乘客都必须系安全带这类场景往往还需要联动闸机或报警系统。我最初做这个项目起因是帮一家运输公司做车辆主动安全系统的POC验证。对方的痛点是车队有200多台车每台车装了两个摄像头一个看路面、一个看驾驶室每天回传的视频有几千个小时安全员抽查率不到5%违章行为基本发现不了。当时试过几种传统方案比如基于Haar特征的级联分类器、基于肤色分割的方法效果都很差——问题在于驾驶室内光线变化剧烈逆光、夜间、戴墨镜、穿深色衣服等情况都会让传统特征失效。后来换到YOLO方案用目标检测的思路直接检测安全带区域问题一下子简化了很多。1.2 为什么选用YOLO而不是其他检测方案YOLO在安全带检测上天然有优势这个选择不是拍脑袋。先说两点最直接的速度与精度的平衡安全带检测往往跑在嵌入式设备或实时视频流上比如NVIDIA Jetson Orin、RK3588这类边缘盒子算力有限。YOLO系列从v5到v8、v11在T4或者Orin上轻松跑几百FPS同时mAP能做到80%以上这个指标组合是两阶段检测器如Faster R-CNN很难做到的。工程落地简单YOLO系列的开源生态极其完善从训练到部署都有成熟链路。PyTorch训练、ONNX导出、TensorRT加速、rknn模型转换每一步都有大量现成案例。对于做实际项目的人来说这意味着可以在很短时间内把模型跑到设备上而不是花大量时间调底层实现。另外补充一点安全带检测本质上属于小目标检测问题。在驾驶室画面里安全带斜跨胸口区域占整张图的比例不大而且背景复杂方向盘、中控台、衣物纹理都会干扰。早期我用过YOLOv3效果一般换成YOLOv5s之后漏检率明显下降后来YOLOv8出来把C2f结构和anchor-free头一换小目标的表现又上了一个台阶。现在新出的YOLOv11在边框回归上做了进一步优化检测精度更高实测下来驾驶位场景比v8强不少。1.3 系统整体架构拆解一个完整的安全带检测系统不只是一个模型文件它是一个包含数据采集、标注、训练、部署、告警联动的闭环系统。下面我把整体架构画一下不用图用文字描述。整个系统由四个部分组成数据采集端包括驾驶室内摄像头、视频流接入网关支持RTSP/GB28181协议、视频抽帧模块。算法识别端核心是YOLO检测模型输入单帧图像输出安全带佩戴状态佩戴/未佩戴、置信度、目标框坐标。业务告警端根据检测结果结合业务规则例如车速大于20km/h才告警、单次告警周期内不重复触发生成告警事件推送至管理平台或短信、语音播报。管理后台负责模型发布、阈值配置、告警记录查询、统计分析。用表格概括一下各模块的职责和关键技术选型模块核心职责关键技术/工具数据采集多路视频接入、抽帧存储FFmpeg、OpenCV、海康SDK数据标注目标框标注、标签分类LabelImg、LabelStudio、CVAT模型训练模型迭代优化PyTorch、YOLOv8/YOLOv11推理部署模型加速、实时响应TensorRT、ONNX Runtime、RKNN业务告警规则判定、事件推送自研告警服务、WebSocket标题里带zip说明这是一个完整打包好的工程训练代码、推理脚本、模型权重甚至部署文档都在里面。这种形态对于很多企业来说非常友好至少拿来就能用不用再从零搭环境。2. 数据准备安全带检测模型的基石2.1 数据集从哪来三个来源和一种兜底方案模型的性能上限是由数据决定的这句话在安全带检测这个特定任务上尤其适用。为什么因为安全带检测场景高度固定摄像头安装位置基本固定一般在A柱、后视镜附近或仪表台上方驾驶员位置固定画面角度变化不大。这种场景下数据完全可以用较少但要精准的策略来打。我在实际项目中数据集来自三个渠道公开数据集网上有一些驾驶行为相关的公开数据集比如State Farm Distracted Driver Detection、AUC Distracted Driver Dataset虽然不是专门做安全带检测的但图像里包含了驾驶室场景可以抽取其中能看到安全带的样本手动框一部分做预训练。自采数据这是占比最大的部分。在我们自己的测试车上安装摄像头覆盖不同时间段白天、黄昏、夜间、不同天气晴天、阴天、雨天、不同驾驶员体型差异会影响安全带贴合程度、不同服装深色衣服、浅色衣服、反光面料。网约车/出租车合作数据如果条件允许可以跟运输公司合作获取真实运营场景的车内视频这种数据最贴近实际部署环境。这个渠道需要签订数据使用协议注意隐私合规问题。兜底方案是合成数据。有同事尝试过用Unity或Unreal Engine搭建虚拟驾驶室把不同体型的虚拟人物、不同安全带颜色渲染出来生成带自动标注的合成数据集用来补充边缘场景比如极端逆光、深夜无路灯路段。实测下来合成数据可以提升模型对颜色和遮挡的鲁棒性但对于真实驾驶室的纹理复杂性还是替代不了真实数据。2.2 标注规范和标签体系设计安全带检测的标注规范比想象中有讲究。常见做法是把安全带当成一个整体框出来标注类别叫seatbelt。但这个方案有坑——安全带的实际形态是斜跨胸口的一条带状区域目标框如果只框中间段训练出的模型容易丢失全局上下文导致遮挡时识别不出来。更稳妥的做法我看很多做DMS的同行都在用分段标注类别一belt安全带从肩部到腰部斜跨的整段类别二no_belt未系安全带时从肩部垂落到座椅一侧的空带不推荐的做法是直接标person、belt两个类别然后靠两个框的空间关系判断是否系安全带。因为安全带和人的空间关系比较复杂安全带框不一定完全贴合人的区域额外的逻辑判断会引入新的误差。标注时的几个细节建议目标框要贴合安全带的边缘不要把背景包进去太多否则模型学到的是背景纹理。安全带和衣物颜色相近时要放大图片看清边缘再框宁可多花点时间不要为了速度牺牲标注质量。遮挡场景单独标注比如手搭在方向盘上正好挡住安全带中段的这种样本单独归为belt因为虽然遮挡但从上下段可以推断是系了的但是要确保训练集里这类样本的数量不超过总数的10%-15%否则模型会过度依赖局部特征。夜间样本的标注要特别注意如果红外相机下安全带显示为暗色需要在标注时参考前后几帧比如车门关闭前安全带的可见状态判断是否真的系了。2.3 数据增强与样本平衡技巧安全带检测场景的数据增强和通用目标检测有点不一样。因为驾驶室画面相对固定你不能用太激进的增强策略去破坏画面结构否则模型会在部署时失真。我常用的增强组合如下表所示增强方法参数设置适用原因Mosaicv8/v11内置默认丰富背景多样性增强小目标随机亮度对比度brightness0.2, contrast0.2模拟不同时间段光照变化随机HSV调整hue0.015, sat0.3, val0.3应对不同颜色的衣物和安全带随机旋转最大±10度模拟摄像头安装角度偏差随机透视变换轻微模拟不同车型视角差异Cutout少量模拟方向盘、手臂对安全带的遮挡一个很关键的经验不要去用水平翻转。因为在驾驶位场景中司机座位在左边中国是右舵车则相反水平翻转后画面布局和部署时的实际画面不一致模型学习到的是错误的空间特征实测会掉2-3个点的mAP。另外随机裁剪的幅度也别太大因为驾驶室的目标尺寸本来就小裁剪过多会导致安全带目标变得更小甚至漏出画面。样本平衡方面未系安全带负样本的数量通常比系了安全带正样本少很多这会带来两个问题一是模型对负样本的召回率偏低二是容易把未系安全带的样本误判为正样本。解决办法不是粗暴地复制负样本而是采用离线增强针对负样本单独做亮度抖动、对比度调整、加高斯噪声扩充到正负样本比接近1:1.5。这个比例值是经验值正样本略多没问题因为安全带的特征更稳定负样本往往要覆盖更多不规则情况。3. 模型训练全流程从配置到调优3.1 环境配置与工程目录规划拿到一个打包好的基于YOLO的安全带检测系统.zip第一步当然是解压看目录结构。一般的工程目录大概长这样. ├── data │ ├── images │ │ ├── train │ │ └── val │ ├── labels │ │ ├── train │ │ └── val │ └── dataset.yaml ├── models │ ├── yolo11s-seatbelt.pt │ └── yolo11m-seatbelt.pt ├── runs │ └── detect │ └── train ├── scripts │ ├── label_convert.py │ ├── train.py │ ├── infer_image.py │ ├── infer_video.py │ ├── export_onnx.py │ └── deploy │ ├── trt │ └── rknn ├── requirements.txt └── README.md环境配置建议直接用conda或venv隔离避免污染系统Python。YOLOv8/YOLOv11通过pip install ultralytics安装依赖自动处理。有一点要注意如果训练机是Linux环境且有多张GPUultralytics默认会使用所有可用GPU这在小数据集上反而浪费显存设置device0即可固定第一张卡。数据集目录结构上images和labels应该分别存放图片和txt标注文件txt文件名必须和图片名一一对应。每行标注格式为class_id x_center y_center width height其中坐标都是归一化到0到1的浮点数。这个格式和COCO、VOC都不同所以从公开数据集转过来时写一个转换脚本是必须的。3.2 标签格式转换脚本演练如果之前用的是LabelImg的VOC格式xml转换成YOLO格式的txt需要写个脚本。这一步看起来简单但很多人栽在归一化坐标上所以我把核心代码贴出来边写边解释。import os import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, out_txt_path, classes): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.findall(object): cls_name obj.find(name).text if cls_name not in classes: continue cls_id classes.index(cls_name) bbox obj.find(bndbox) xmin float(bbox.find(xmin).text) ymin float(bbox.find(ymin).text) xmax float(bbox.find(xmax).text) ymax float(bbox.find(ymax).text) x_center (xmin xmax) / 2.0 / img_w y_center (ymin ymax) / 2.0 / img_h width (xmax - xmin) / img_w height (ymax - ymin) / img_h lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) with open(out_txt_path, w, encodingutf-8) as f: f.write(\n.join(lines)) classes [belt, no_belt] for xml_file in os.listdir(xml_annotations): if not xml_file.endswith(.xml): continue xml_path os.path.join(xml_annotations, xml_file) out_txt_path os.path.join(labels, xml_file.replace(.xml, .txt)) voc_to_yolo(xml_path, out_txt_path, classes)注意一个细节x_center、y_center归一化后需要限幅到0-1有些标注工具的规范不严格可能会出现1.0左右的数值比如xmax正好等于图像宽度虽然训练时不会直接报错但在NMS阶段可能导致边界框异常建议在脚本里加上max(min(value, 1.0), 0.0)这样的限幅。3.3 训练参数配置与调参思路数据准备完成后关键就是训练参数。这个项目我推荐从YOLOv8s或YOLOv11s这款轻量模型开始不要一上来就用大模型因为安全带检测的目标小而少大模型容易过拟合而且边缘设备部署时推理延迟会高很多。训练命令的模板yolo detect train data/path/to/dataset.yaml modelyolo11s.pt epochs200 imgsz640 batch16 device0 patience50 optimizerSGD lr00.01 lrf0.01几个关键参数的说明imgsz640对于驾驶室场景640像素足够。再大比如1280会提高对小目标的召回但推理速度下降明显对于边缘设备来说不划算。如果追求极致精度可以尝试用imgsz960训练然后用imgsz640导出但收益不大不如把时间花在数据上。batch根据显存调整8GB显存用816GB用16。如果batch太小BN层统计不稳定容易导致训练震荡。patience50早停机制连续50个epoch验证集没有提升就停止。安全带检测数据集不大一般不到100个epoch就收敛了不要硬跑完200个epoch。optimizerSGDvsAdamW实测SGD余弦退火在YOLO系列上更稳收敛曲线平滑AdamW前期收敛快但后期容易过拟合。class weights如果负样本较少可以在dataset.yaml里配置class_weights: [1.0, 1.5]提高no_belt类别的损失权重让模型更关注未系安全带的样本。训练过程中要重点观察两个曲线train/loss和metrics/mAP50-95(B)。如果loss下降缓慢且mAP曲线存在明显震荡大概率是学习率太大或数据集的标签噪声较高此时不是一味调参而是去检查几百张标注看看有没有框错、漏框的样本。3.4 模型评估标准安全带检测模型的评估不能只看mAP。因为在真实业务中漏报和误报的成本不一样。漏报没系安全带但系统认为系了会影响安全监管误报系了但被判未系会打扰司机推送不必要告警。所以除了mAP还要看未系安全带的召回率Recall of no_belt这个指标必须高我通常要求大于95%。模型如果在这里失守系统就没有实际价值。误报率FP per frame即每帧中系了安全带却被误判为未系的概率。业务上要求低于1%否则一天下来一个车队会产生几百条虚假告警安全员会对系统失去信任。F1-score综合看precision和recall的平衡如果业务告警和人工复核相结合F1维持在0.9以上就可以上线。4. 推理与部署把模型搬到实际场景中4.1 图片与视频流推理脚本模型训练好之后第一件事是拿真实图片测试效果。写一个简单的推理脚本from ultralytics import YOLO import cv2 model YOLO(runs/detect/train/weights/best.pt) # 单张图片推理 results model.predict(test_images/case1.jpg, conf0.35, imgsz640, verboseFalse) # 保存可视化结果 results[0].save(output/case1_result.jpg) # 视频/视频流推理 cap cv2.VideoCapture(rtsp://192.168.1.100:554/stream1) while cap.isOpened(): ret, frame cap.read() if not ret: break results model.predict(frame, conf0.35, imgsz640, verboseFalse) # 结果后处理 for r in results: boxes r.boxes.xyxy.cpu().numpy() cls_ids r.boxes.cls.cpu().numpy() confs r.boxes.conf.cpu().numpy() for box, cls_id, conf in zip(boxes, cls_ids, confs): # class 0 belt, class 1 no_belt label Safe if int(cls_id) 0 else Unsafe cv2.rectangle(frame, (int(box[0]), int(box[1])), (int(box[2]), int(box[3])), (0, 255, 0), 2) cv2.putText(frame, f{label} {conf:.2f}, (int(box[0]), int(box[1]) - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2) cv2.imshow(Seatbelt Detection, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()conf阈值的选择有点讲究。调高了误报少但漏报会增加调低了漏报少但误报增加。经过大量场景测试我发现0.3到0.4之间是最佳区间。如果部署的摄像头安装位置和训练数据差异不大可以设高一点0.4如果部署场景多样建议设低一点0.3靠业务侧的逻辑如时间连续性来过滤误报。一个非常实用的技巧对单帧的告警不要立即触发而是采用多帧确认机制——连续5帧、至少3帧检测为未系安全带才判定为一次事件。这样能有效规避视频流中单帧误检、运动模糊造成的抖动问题。实现起来就是在业务逻辑里加一个计数器成本很低但对用户体验的影响非常大。4.2 导出ONNX并做TensorRT加速为了在边缘设备上达到实时性能导出的pts模型需要先转成ONNX再转成TensorRT的engine文件。转换命令如下yolo export modelbest.pt formatonnx dynamicTrue imgsz640 opset12导出后可以用onnxruntime做一次精度验证import onnxruntime as ort import numpy as np import cv2 session ort.InferenceSession(best.onnx) input_name session.get_inputs()[0].name img cv2.imread(test.jpg) img cv2.resize(img, (640, 640)) img img[:, :, ::-1].transpose(2, 0, 1) # BGR - RGB, HWC - CHW img np.expand_dims(img, 0).astype(np.float32) / 255.0 outputs session.run(None, {input_name: img})在NVIDIA设备上更推荐走TensorRT速度能再提升2到4倍。转换流程ONNX - TensorRT engine可以用trtexec工具做转换trtexec --onnxbest.onnx --saveEnginebest.engine --fp16--fp16半精度推理对精度损失很小实测mAP损失0.3%以内速度提升明显。这里有个小坑TensorRT转换时如果模型包含动态shape需要指定--minShapes、--optShapes、--maxShapes否则推理时会报错。如果摄像头输入分辨率固定比如1080P建议直接用固定shape省事且性能最优。4.3 部署到瑞芯微NPU等边缘设备很大一部分安全带检测项目最终会跑在国产边缘设备上尤其是瑞芯微RK3588、算能盒子这类带NPU的硬件单价低、功耗低、适合车载场景。YOLO模型要转成RKNN格式才能跑在NPU上官方提供了rknn-toolkit2转换工具rknn_convert.py --onnx model.onnx --output model.rknn --target rk3588 --fp16转换时有几个注意事项RK3588的NPU对某些算子的支持有限ONNX里的Resize、Reduce等算子可能会被优化掉但SiLU、Conv这些常规算子没问题。如果转换失败检查一下opset版本建议用opset12太高的算子版本容易出兼容问题。在NPU上跑YOLO时预处理如归一化尽量放在NPU内部完成避免CPU到NPU的数据拷贝浪费带宽。rknn-toolkit2支持在转换时配置mean_values和std_values把/255.0的操作一并融合进模型。多路视频流场景下NPU的算力分配需要注意。RK3588可以同时跑1路1080P30fps的YOLOv8s检测加上一路车辆检测但再多路就会帧率下降。建议用硬件解码模块Mpp先解码再把帧送到NPU不要用OpenCV去软件解码否则CPU会成为瓶颈。5. 常见问题与排查技巧实录5.1 训练指标异常的排查路径情况一loss前期就不下降一直是平的。先检查数据。最常见的原因是标签文件里出现了0值或负数坐标这类脏数据会在反向传播时给模型注入错误的梯度信号。写一个基线检查脚本遍历所有txt文件排除值为0或大于1的坐标行基本能解决。另一个原因是数据集中有大量无法辨认安全带的严重模糊、过曝图片这种图片让人工标注都费劲更别提训练。建议清洗掉。情况二训练loss下降但mAP始终在0.3左右徘徊。大概率是类别不平衡过于严重。比如训练集中belt样本有1万张no_belt只有200张模型学到的几乎全是正样本的特征对负样本几乎没有区分能力。解决方法是回到数据集专门补充未系安全带的样本。如果补充不了就把所有no_belt样本做离线增强复制成5份让这个类别的数量不再边缘化。情况三mAP高但实际视频里有大量漏检。这个问题往往出在anchor设置或输入分辨率上。安全带目标在1080P画面里大约占40x120像素如果以640分辨率输入训练目标被压缩到20x60左右检测头已经很难提取到有效特征。建议训练时用imgsz960或者用SAHI这类切片推理工具对大图先切成小块再检测FPS会下降但召回率提升非常明显。5.2 部署后常见的误检与漏检场景部署环境千差万别训练集永远覆盖不全。我在现场踩过的坑总结如下夜间红外模式很多车内摄像头在夜间自动切红外图像变黑白。但训练集如果以白天彩色图片为主模型在黑白图上泛化很差。解决办法是训练时用hsv_h增强模拟灰度或者在数据集中加入部分红外模拟样本把彩色图转灰度后再叠加噪声。安全带被衣物遮挡冬天驾驶员穿厚外套安全带被完全遮住从视觉上根本无法判断。这种场景无论模型多强都无能为力业务侧需要配置规则比如人脸识别和身体姿态分析辅助判断或者干脆在遮拦严重的时段自动降级为人工抽查。摄像头安装位置偏移有些车辆的摄像头装在A柱外面视角有倾斜安全带框在画面里不再是标准斜线而是接近水平或者被变形。这种安装不规范会导致模型误检率高。建议现场部署时使用标定工具输出摄像头姿态角如果偏移过大业务方要重新调整安装位置。强逆光与车窗反光逆光时车窗部位过曝安全带和背景融合在一起。测试时我遇到过模型完全检测不出来的情况。一个有效的处理在图像预处理阶段先做一次自适应直方图均衡化CLAHE把过暗和过曝区域的细节拉出来。虽然模型推理时间会多2-3ms但摄像头精度提升值不值这个时间自己权衡。5.3 告警逻辑与业务规则优化模型输出的是每一帧的检测结果要变成有业务价值的告警事件还需要规则引擎把关。这里我列出几种实用的过滤规则置信度联动连续多帧平均置信度低于阈值的不告警。这能过滤掉隔帧误检的噪声。时间段过滤车辆熄火后可以通过ACC信号获取不检测一天之内同一辆车同一事件的重复告警只推一次事件开始到结束的时间窗口内。多目标处理驾驶位和副驾位要分别判断。用YOLO检测到一个no_belt框是不够的还需要用目标框的位置坐标判断它落在画面左半边还是右半边从而对应是驾驶员还是乘客。联动验证如果有GPS或车辆CAN总线数据可以加入车速判断。车速为0时一般不告警因为车辆静止时解安全带是合规操作比如等待红绿灯时。这些规则的代码实现不复杂但逻辑梳理一定要在生产前做清楚否则上线后告警噪音会让安全员炸毛。6. 进阶改进方向这个项目做好了基础版本之后有几个方向可以继续深挖我在交付过几个项目后的体会是不要一开始就追求高端玩法把基础版本的数据、标注、模型、部署链路吃透再去考虑复杂改进效率更高。如果数据量已经过万、基础模型效果稳定了以下几个方向值得尝试YOLOv11 注意力机制在C2f模块中加入SE或CBAM注意力模块让模型更聚焦安全带区域抑制背景干扰。改进时需要修改模型结构代码ultralytics官方支持自定义模块但会增加训练时间收敛会更慢需要耐心调参。多任务学习同时检测安全带、手持电话、驾驶员面部状态疲劳/分心一个模型输出多个检测头共享Backbone减少边缘设备上的推理成本。这对锚定在车内的多任务DMS系统非常实用。轨迹跟踪状态判定用ByteTrack或DeepSORT对安全带区域做追踪结合时序信息判断安全带状态是否在连续时间内发生变化比如上高速前系了、中途解开比纯单帧判断更准确。针对小目标优化在Backbone中引入高分辨率特征层或者使用FPN的P2层将小目标的特征融合进来。YOLOv8官方对特定数据集效果有限但可以结合AHI模块或自研的小目标检测头做改进让模型在远距离、小尺寸目标上有更高召回。从我个人做实际项目的经验来看这类视觉检测系统的核心壁垒不在模型结构而在于对场景的理解深度和数据治理能力。模型只会告诉你画面里有没有安全带但真实业务里还要知道摄像头装在哪里、光线什么时候变化、司机什么时候为什么会解开安全带、告警怎么推才不打扰人。把这些想清楚了YOLO这个工具自然能发挥出它该有的价值。如果你正准备上手这个项目我的建议是从一个小范围的POC开始先收集1000张左右驾驶室图片标注20个小时训练一个YOLOv8s跑通推理和告警流程再逐渐扩大数据、优化模型。不要一上来就追求动辄几万张的数据量先跑通闭环再迭代细节这样你才能真正理解每个环节里那些文档里不会写的坑。本文还有配套的精品资源点击获取