资讯动态

YOLO11车辆检测数据集实战:三格式标签与一键训练脚本

发布时间:2026/9/29 12:33:55 来源:尧图企业网站定制
简介面向目标检测与车辆检测算法训练的数据集配套资料涵盖城市道路、高速道路、农村道路以及车辆遮挡、严重遮挡等真实场景图片一千张分为 Auto、Bus、Car、LCV、Motorcycle、Multi-Axle、Tractor、Truck 八个类别使用 labelimg 完成高质量标注并提供 VOC(xml)、COCO(json)、YOLO(txt) 三种常见格式可直接用于 YOLO 等算法训练也适合交通道路监控车辆检测项目及监控通用车辆数据集补充。由于原始图片数据量较大资源以单个 PDF 文档交付大小约 7.19MB文档内包含数据集介绍及百度网盘获取方式。目前已有 1332 人学习。除标注数据外还附赠 YOLO11 一键训练脚本支持 GPU(GPUs)、CPU、Mac(M芯片) 多平台运行并提供训练结果日志供参考可帮助快速搭建车辆检测训练流程便于实际项目快速验证与落地。1. YOLO11车辆检测数据集实战1000张真实图三格式标签还带跨平台训练脚本车辆检测项目里真正耗时间的从来不是调模型而是数据。标注、格式转换、类别校对这三件事能吃掉你三分之二的工期。这份车辆检测数据集把1000张真实道路场景的车辆图按8个类别标好同时给了VOC/COCO/YOLO三种格式标签还附赠一个GPU/CPU/Mac三平台都能跑的YOLO11一键训练脚本对做交通监控项目的人来说确实省去不少前期准备时间。适合正在做道路车辆检测、监控场景目标识别、或者需要一份现成车辆数据做算法预研的开发者。下面我从数据本身讲起落到训练脚本的配置和踩坑记录保证你拿到资源后能复现出可用的模型。2. 数据集结构拆解8类车辆的标签体系与三格式转换逻辑2.1 八类目标定义与场景分布数据集里车辆类别一共8类Auto、Bus、Car、LCV、Motorcycle、Multi-Axle、Tractor、Truck。这个分类本身是偏监控视角的不是COCO那种通用分类。举个例子LCV是轻型商用车的缩写就是那种封闭式厢式货车Multi-Axle是多轴车指的是挂车、重载卡车这一类。如果你做的是城市道路卡口监控这类细分比单纯的car/truck二分类更接近生产需求。场景覆盖上数据集包含城市道路、高速道路、农村道路还有不少遮挡样本包括车辆被路灯杆、树木、前车遮挡的情况。这一点对训练鲁棒性很重要因为实际监控里遮挡是常态纯正面无遮挡的车一抓一大把但被挡了一半的车才是真正考验模型的地方。我的建议是训练时把遮挡样本单独抽出来做验证集专门看你模型的抗遮挡能力。2.2 VOC/COCO/YOLO三格式字段对照这套数据集用labelimg标注同时导出三种格式。很多人分不清这三种格式的坐标定义我直接给你对照表这是做格式转换前必须看懂的东西。格式存放方式坐标定义类别定义VOC(xml)每张图对应一个xml文件bndbox记录xmin/ymin/xmax/ymax左上角原点像素坐标object节点里的name字段是字符串COCO(json)单文件包含全部标注annotations里bbox是[x, y, width, height]绝对像素坐标categories里id从1开始name对应字符串YOLO(txt)每张图对应一个txt文件每行class_id x_center y_center width height全部归一化到0~1class_id就是数字索引从0开始三者转换的核心公式就一个把VOC的左上角右下角转成YOLO的中心点加宽高# VOC像素坐标 xmin,ymin,xmax,ymax - YOLO归一化坐标 def voc_to_yolo(xmin, ymin, xmax, ymax, img_w, img_h): cx (xmin xmax) / 2.0 / img_w cy (ymin ymax) / 2.0 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h return cx, cy, w, h注意YOLO格式里类别编号必须从0开始而COCO的category_id通常从1开始转换时别忘记减1。另一个容易翻车的地方是VOC的bbox没有校验可能出现xmin大于xmax这种脏数据所以转换脚本里一定要加上宽高合法性判断。2.3 拿到资源后的三步校验流程我拿到任何数据集的第一件事不是训练而是校验。三格式同时给也存在一个隐患三种格式由labelimg导出来的时候是一致的但如果你自己跑过转换脚本转坏了是看不出来的。我的校验流程分三步。第一步统计每个类别的目标数量。用YOLO格式的txt统计第一列数字分布这一列应该只有0到7而且每个类别的数量应该在合理范围不会出现某个类别只有一两张图这种极端不平衡。第二步随机抽20张图把YOLO的归一化坐标还原成像素坐标画框人工扫一遍框的位置对不对这一步能抓住标签错位问题。第三步检查三格式之间的坐标一致性随机抽5张图把xml和txt的同名目标坐标对比。# 抽取一张图的三种标签做一致性核对 import xml.etree.ElementTree as ET def check_consistency(xml_path, txt_path, img_w, img_h): tree ET.parse(xml_path) xml_boxes [] for obj in tree.findall(object): bnd obj.find(bndbox) xml_boxes.append([ float(bnd.find(xmin).text), float(bnd.find(ymin).text), float(bnd.find(xmax).text), float(bnd.find(ymax).text) ]) txt_boxes [] with open(txt_path) as f: for line in f: parts line.strip().split() cx, cy, w, h map(float, parts[1:]) xmin (cx - w/2) * img_w ymin (cy - h/2) * img_h xmax (cx w/2) * img_w ymax (cy h/2) * img_h txt_boxes.append([xmin, ymin, xmax, ymax]) # 对比两组bbox的IoU低于0.9说明标签不一致 print(fxml框数量: {len(xml_boxes)}, txt框数量: {len(txt_boxes)})这段代码里最关键的是把归一化坐标还原时不要忘记乘以对应边的宽高。如果发现xml里8个框txt里只有7个大概率是labelimg导出后有人手动删过标签又没同步这种脏数据进训练就是无声的祸害。实际跑下来我这套校验脚本大概耗时几分钟能把后面训练翻车的概率降下来很多。3. 从环境配置到一键训练YOLO11脚本落地的完整记录3.1 三平台依赖安装与环境差异资源附带的YOLO11训练脚本是一款基于ultralytics框架的封装脚本。所谓支持GPU/CPU/Mac其实就是device参数的选择问题。我按我最常用的配置流程走一遍。# 创建虚拟环境python版本建议3.10及以上 conda create -n yolo11 python3.10 conda activate yolo11 # 安装基础框架 pip install ultralytics # GPU机器需要安装cuda版pytorch注意版本对应 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 # CPU和Mac直接装官方默认版即可 pip install torch torchvision这里有个细节很多人装完ultralytics后直接敲yolo命令报“不是内部或外部命令”。Windows下多半是Python的Scripts目录没加入PATHLinux下则是当前shell没有rehash。遇到这种情况直接用python -m ultralytics调用最可靠不用纠结环境变量。Mac M芯片的机器安装时则要注意官方torch的arm64版本普通pip安装一般会自动选择正确的版本。3.2 训练脚本的数据组织方式一键训练脚本的核心不是训练那行命令而是data.yaml的写法。这份数据集从目录结构上已经按YOLO的标准做了划分直接指向对应目录即可。# vehicle.yaml 数据集配置文件 path: /path/to/vehicle_dataset train: images/train val: images/val nc: 8 names: 0: Auto 1: Bus 2: Car 3: LCV 4: Motorcycle 5: Multi-Axle 6: Tractor 7: Trucknames的顺序直接决定模型输出的类别顺序必须严格对齐txt标签里第一列的数字索引。常见的坑是有人发现跑出来的模型Car和Truck互相混淆十有八九是这里names顺序和标注索引没对齐。拿到数据集后先打印一张图的txt内容看一眼第一列最大值再做一遍类别统计确保是0到7而不是1到8。3.3 跑通第一次训练的完整命令序列训练脚本我建议你直接看它封装的参数透传逻辑。很多这类脚本的问题在于把超参数写死在代码里你想改batch都要去翻源码。从实用角度我更习惯直接用ultralytics的原生命令来训练这样才能灵活调整参数。# 训练入口命令model可换成yolo11s.pt/yolo11m.pt # device0 表示第一张GPUcpu表示CPUmps表示Mac M芯片 python -m ultralytics yolo train \ modelyolo11n.pt \ datavehicle.yaml \ epochs100 \ imgsz640 \ batch16 \ device0 \ projectruns/vehicle \ nameexp_base \ patience20主要参数含义epochs控制训练轮数100轮是这个体量数据集比较合理的起点imgsz是输入分辨率640是YOLO11默认值车辆目标本身不算小物体不需要刻意上调batch是批量大小显存不够就降到8CPU训练建议直接降到4patience是早停轮数连续20轮验证指标不上升就自动停止。第一次训练建议你用yolo11n这个最小模型跑通全流程看loss曲线正常了再换大模型。GPU机器上100轮大概两小时左右CPU机器就不好说了跑十几个小时也正常。Mac M芯片的MPS加速和GPU差距没那么大可以先试devicemps加速。训练完会在runs/vehicle/exp_base目录下生成weights/best.pt和last.ptbest.pt就是验证集上表现最好的模型。4. 训练踩坑与常见问题排查五条反复出现的翻车现场4.1 高频踩坑记录我把用这套数据集反复遇到的五个问题列出来每一条都是实际翻车后总结的建议你对照排查。踩坑一训练中途loss变成NaN。现象是前面几轮loss正常下降跑着跑着box_loss变成nan验证集mAP直接归零。原因是前面提到的那3张图存在非法坐标转为YOLO格式后生成了负数宽高反向传播时梯度爆炸。解决方法是训练前用标签体检脚本把w0或h0的行直接排查出来看一下是标错了还是转换错了。踩坑二类别识别错位Truck显示成BusAuto显示成Tractor。现象是验证集上看到的预测框位置正确但类别名张冠李戴。原因几乎都是names列表顺序和txt里第一列数字索引没对齐。解决方法是统一用我前面那段xml和txt交叉比对的脚本按xml里object的先后顺序重建映射确保数字索引和names严格一一对应。踩坑三Mac上第一次启动训练报cuda错误。现象是M芯片的Mac上device参数填了0直接报CUDA not available。原因是不少人习惯了GPU机器上的写法直接抄过来。解决方法是Mac统一用devicemps如果mps下训练几个epoch后loss不降或剧烈抖动就退回devicecpu并把batch降到4稳定优先。踩坑四验证集mAP高但实际照片识别很差。现象是训练日志里mAP50有0.9以上但拿手机拍的路口照片去测几乎全miss。原因大概率是验证集里混进了训练集的图片或者验证集和训练集来自同一段视频的连续帧。解决方法是检查数据集划分逻辑按文件名前缀或时间戳做去重确保同一辆车不会既在训练集又在验证集。实际做法是把数据集按8:1:1重新随机划分划分前先对文件名做hash去重。踩坑五标注框把目标框得太大边缘残缺。现象是训练出来的模型在目标有遮挡时置信度突然掉到0.5以下。原因是labelimg标注时框的是可见部分遮挡情况下可见区域很小。解决方法是不要改动标签而是在训练时开启数据增强的随机遮挡YOLO11里用augment参数控制另外可以把这类遮挡样本单独抽出来做个子集用它来评估模型的抗遮挡能力。4.2 标签体检脚本把坑拦在训练之前上面这些坑实际上全部可以通过一个标签体检脚本在训练前提前暴露。我习惯在每次训练前强制跑一遍花两分钟换回来的是几小时的白白等待。# 标签体检脚本检查所有YOLO格式txt的合法性 import os from pathlib import Path def check_yolo_txt(txt_dir): bad_files [] total_boxes 0 for txt_path in Path(txt_dir).glob(*.txt): with open(txt_path) as f: for line in f: parts line.strip().split() if len(parts) ! 5: bad_files.append((txt_path.name, 字段数不为5)) continue cls, cx, cy, w, h parts cx, cy, w, h float(cx), float(cy), float(w), float(h) # 归一化坐标必须在0~1宽高必须为正 if not (0 cx 1 and 0 cy 1): bad_files.append((txt_path.name, 中心点越界)) if w 0 or h 0: bad_files.append((txt_path.name, 宽高为负)) total_boxes 1 print(f共检查 {total_boxes} 个目标框) if bad_files: print(发现问题标签) for name, reason in bad_files[:20]: print(f {name}: {reason}) else: print(全部标签合法) check_yolo_txt(/path/to/vehicle_dataset/labels/train)这个脚本只做三件事检查字段数量、检查坐标是否在0到1区间、检查宽高是否为正。字段数量不是5说明这行被污染了多半是转格式时有数据串行。中心点越界大概率是归一化时用了错误的图像尺寸。宽高为负就是实体框翻转。三个检查跑完剩下的事交给训练就行至少这一类坑是不会再见了。5. 训练调参与效果验证从loss曲线到mAP指标的完整解读5.1 超参数选择的经验值1000张图、8个类别的数据集规模不算大超参数设得太激进会过拟合设得太保守又收敛太慢。我建议从下面这组参数起步再根据训练日志调整。参数建议值说明modelyolo11s.pt或yolo11m.pt1000张图用yolo11n起步验证代码没问题再换sepochs100有早停保护跑不满100轮没关系batchGPU 16 / CPU 4 / MPS 8按显存调整OOM就减半imgsz640默认值车辆目标不需要更高分辨率lr00.01默认值新手不建议动patience20连续20轮没提升就停augmentTrue开启内置马赛克增强弥补数据量不足5.2 训练日志里的指标怎么读训练结束后看runs/vehicle/exp_base目录下的results.csv里面逐行记录了每个epoch的指标。关键看四样东西train/box_loss、train/cls_loss、metrics/precision、metrics/mAP50。loss下降但mAP不涨说明模型在过拟合训练集的噪声mAP50在80%以上但mAP50-95只有50%左右说明框位置还不够精细这时候可以尝试提高imgsz或者换更大模型。博主附带的训练日志里也是这几个指标在逐行变化你可以拿自己的结果和它对比如果mAP50差太多优先检查数据划分和标签质量。5.3 数据增强的取舍YOLO11默认开启马赛克增强这对1000张图的数据量来说算是白送的免费午餐。但车辆检测场景里有一个特殊问题车辆不是旋转对称的车头车尾如果翻转语义就变了。默认增强里flipud是关闭的fliplr建议也关闭不然模型会学到“车头朝左的车翻转后也合理”这种错误逻辑。对车辆检测来说我一般会关掉fliplr把增强预算留给hsv_h和translation这两个参数这样既增加了多样性又不会破坏语义。# 关闭水平翻转强化颜色和位移增强 python -m ultralytics yolo train \ modelyolo11s.pt \ datavehicle.yaml \ epochs100 \ imgsz640 \ batch16 \ device0 \ flipud0.0 \ fliplr0.0 \ hsv_h0.02 \ translate0.2这个配置的核心逻辑是车辆检测中目标本身有强烈的先验形状颜色变化和像素位移不会破坏语义而水平翻转会。实际验证下来关闭fliplr之后mAP50往往有小幅提升尤其是Tractor和Motorcycle这两个类别因为它们的方向性特征更强。5.4 验证集表现与真实场景的差异训练结束时看到mAP50有0.9别急着开心。监控场景的测试和公开数据集评测是两回事因为真实摄像头角度、光照、遮挡分布和数据集分布并不完全一致。我的习惯是把训练好的模型用一段没有出现在训练集里的监控视频跑一遍抽几帧画框看效果。重点看三种情况远距离小目标能不能稳定触发置信度阈值、严重遮挡时会不会出现置信度震荡、夜间光照变化大时框的位置是否会漂移。车辆检测项目生产环境里用户根本不看mAP只看你在真实监控画面上框得准不准。6. 训练完的最后一公里模型导出、推理验证与后续习惯训练得到best.pt之后离部署还差一步。ultralytics框架训练的模型不能直接放进生产环境跑我一般先导出成ONNX格式这样后续无论是TensorRT加速还是OpenVINO部署都有回旋余地。# 导出ONNXopset12兼容性最好 python -m ultralytics yolo export \ modelruns/vehicle/exp_base/weights/best.pt \ formatonnx \ opset12 # 用导出后的onnx做推理验证 python -m ultralytics yolo predict \ modelruns/vehicle/exp_base/weights/best.pt \ sourcetest_images/ \ saveTrue \ conf0.25验证时conf不要设太高0.25更接近真实场景你看的是模型在低置信度阈值下的表现不是只看高置信度的理想结果。如果这一步发现小目标漏检明显回到训练阶段把imgsz调到960分辨率提升对小目标很有效代价是训练时间变长。如果在Mac上部署可以导出CoreML格式M芯片跑CoreML比ONNX更顺ultralytics对这两个格式的导出都做了支持。从那以后我每次换数据集都会把标签体检脚本和一致性校验脚本作为训练前强制走一遍的固定流程再去碰训练参数。这习惯帮我省下的时间远大于脚本本身的几行代码。希望帮到你。本文还有配套的精品资源点击获取

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑