简介面向目标检测与交通监控场景的车辆检测数据集配套说明文档采用PDF形式提供共1个文件约7.19MB内含数据集基本情况介绍与百度网盘获取方式。该数据集包含1000张真实场景高质量图片覆盖城市道路、高速道路、农村道路以及车辆遮挡、严重遮挡等复杂情形类别涵盖Auto、Bus、Car、LCV、Motorcycle、Multi-Axle、Tractor、Truck共8类适用于交通道路监控车辆检测项目也可作为通用监控车辆检测数据的补充。标注采用labelimg工具完成质量较高同时提供VOC(xml)、COCO(json)、YOLO(txt)三种常见目标检测格式可直接用于YOLO等算法训练免去格式转换的麻烦。随附的YOLO11一键训练脚本支持GPU(GPUs)、CPU、Mac(M芯片)多平台运行并提供博主训练结果日志供参考方便初学者快速跑通训练流程。目前已有1330人学习适合需要快速开展车辆检测实验或落地监控场景应用的开发者。1. 车辆检测数据集1000张真实图、三种格式标签附YOLO11三平台训练脚本做目标检测项目最耗时间的往往不是调模型而是整理数据集。这份车辆检测数据集收录1000张真实场景图片给出 VOC(xml)、COCO(json)、YOLO(txt) 三种格式标签省去格式转换并附赠 YOLO11 一键训练脚本覆盖 GPU(GPUs)、CPU、Mac(M芯片) 三平台。类别为 Auto、Bus、Car、LCV、Motorcycle、Multi-Axle、Tractor、Truck 共8类场景含城市道路、高速道路、农村道路、车辆遮挡和严重遮挡数据。适合两类人一是做交通道路监控车辆检测、缺一套能直接开训数据的工程师二是需要补充遮挡样本做监控场景数据集扩充的熟手。资源以PDF文档分发数据在网盘文档内附说明与获取方式。下面按数据核对、脚本运行、踩坑排查、结果验证依次拆讲。2. 数据集结构拆解八个类别与VOC/COCO/YOLO三种标签的对应关系2.1 八个类别与场景覆盖先看类别。八个类里Auto 和 Car 同时出现是这类真实车辆数据集的常见设计。从工程角度理解Car 一般对应狭义的小型乘用车轿车、两厢车、SUVAuto 在这里更像是对机动车的大类泛指两者具体语义差异需要以打开图片为准。LCV 是 Light Commercial Vehicle 轻型商用车通常指皮卡、面包车、轻客这类Multi-Axle 多轴车辆对应重型挂车、多轴特种车Tractor 是拖拉机与牵引车Truck 是卡车。Bus 和 Motorcycle 语义清楚不展开。场景覆盖是这份数据比较值钱的地方。城市道路和高速道路是常规项农村道路样本能明显提升泛化能力——很多公开车辆数据集在城市场景丰富但农村道路和严遮挡样本偏少。而车辆遮挡和严重遮挡这两类数据恰恰是交通监控项目里最难收集的栏杆、绿化带、前车尾部的部分遮挡会让 YOLO11 这种单阶段检测器在特征提取时丢信息。数据集里如果有相当比例的遮挡样本训练时不要全部被 mixup 增强替换掉要保留一部分原始遮挡样本让模型学。我的习惯是拿到数据集先不急着训练跑一遍类别统计脚本看每类有多少实例。1000张图8个类别小类LCV、Tractor、Multi-Axle的实例数通常远少于 Car。如果某类只有几十个实例后面训练就要考虑类别权重或复制增强。2.2 三种标签格式的对应关系同一张图对应三个文件这是这份数据省时间的地方。VOC 是 xml每个 object 节点带 name 和 bndbox 的 xmin/ymin/xmax/ymax 像素坐标COCO 是 jsonannotations 数组里每条记录 image_id、category_id、bbox[x,y,width,height]YOLO 是 txt每行五个数第一个是 class id后面是归一化后的 x_center、y_center、width、height。对应关系如下格式文件后缀坐标表示训练时所用VOC.xmlxmin, ymin, xmax, ymax像素需转 YOLO 或 COCOCOCO.jsonbbox[x, y, w, h]像素MMDetection、Detectron2YOLO.txtclass, x_center, y_center, w, h0~1归一化YOLO 系列直接使用举例一张 1920x1080 的图里有一辆 Car框出像素区域是 xmin100、ymin200、xmax500、ymax600那么 YOLO txt 里对应行是0 0.15625 0.370370 0.208333 0.370370。第一个 0 表示 class id 是0按 names 顺序对应x_center(100500)/2/19200.15625y_center(200600)/2/1080≈0.370width(500-100)/1920≈0.208height(600-200)/1080≈0.370。如果 class id 排序和 names 列表对不上训练的 loss 照样收敛但预测结果全部错位这是后面避坑章要重点讲的。实际训练时三个格式只用其一Ultralytics 只吃 YOLO 格式所以这份数据里 txt 是主角xml 和 json 是备份。很多人拿到三格式数据会纠结用哪个我的建议跑 YOLO11 直接用 txt以后要切 MMDetection 或 Detectron2优先用 COCO json一个文件含全部图片与标注信息比逐张找 xml 方便。反过来从 json 重新生成 txt 时注意COCO 的 bbox 是像素 x,y,w,h要先除以图像宽高再转中心点坐标公式和上面那张表一致。2.3 用 labelimg 核对标注质量先跑一遍坐标与类别校验这份数据的标注工具是 labelimg导出的 VOC 格式质量一般比较稳但训练前我会先跑一个校验脚本检查每个 txt 的坐标是否在[0,1]区间、class id 是否超出类别数、文件是否为空。脚本如下import os from pathlib import Path label_dir Path(labels/train) # 按你的目录改 num_classes 8 # Auto/Bus/Car/LCV/Motorcycle/Multi-Axle/Tractor/Truck errors [] for txt in label_dir.glob(*.txt): lines txt.read_text().strip().splitlines() if not lines: errors.append((txt.name, empty label file)) continue for line in lines: parts line.split() if len(parts) ! 5: errors.append((txt.name, finvalid line length: {line})) continue cls_id, xc, yc, w, h map(float, parts) if cls_id num_classes or cls_id 0: errors.append((txt.name, fclass id out of range: {cls_id})) for v in (xc, yc, w, h): if v 0 or v 1: errors.append((txt.name, fcoord out of [0,1]: {line})) print(ftotal errors: {len(errors)}) for name, msg in errors[:20]: print(name, msg)脚本逻辑很简单逐行解析YOLO格式先保证每行恰好5个字段再检查类别 id 在0~7之间、四个坐标值在0~1之间最后把空标签文件单独标记出来。空文件在YOLO训练里不会报错但等于那张图没有框会影响损失统计该删就删。跑完没有错误再随机挑10张图把框画在原图上人工扫一眼这一步花不到5分钟能拦住后面八成训练出来结果全错位的问题。提示校验脚本输入的 labels 目录应该和训练时的 data.yaml 指向同一份数据避免那边改了目录这边没同步。3. YOLO11三平台训练脚本GPU、CPU、Mac的启动方式与参数3.1 环境准备与目录布局训练脚本基于 Ultralytics YOLO11。环境这一步常见做法是 conda 建独立环境Python 3.10 比较省心然后按平台装 torch 和 ultralytics。GPU 平台NVIDIA安装命令conda create -n yolo11 python3.10 -y conda activate yolo11 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralyticsMac(M芯片) 平台装正常 CPU 版 torch 即可PyTorch 在 macOS 上默认通过 MPS 后端调用 GPUCPU 平台同理直接 pip install torch。装完验证一下 torch 能不能看到设备import torch print(torch.__version__) print(CUDA available:, torch.cuda.is_available()) print(MPS available:, torch.backends.mps.is_available())GPU 机器上 CUDA available 是 False 的话后面所有训练都会落到 CPU速度差几十倍Mac 上要多看 MPS available这个值决定你能不能跑 devicemps。如果本机没有 NVIDIA GPU最常见的方案是租一块云端 GPU4GB 显存起步就能跑 yolo11n训练完下载权重即可。数据集目录按 YOLO 惯例组织成 images 和 labels 两棵树train/val 划分建议 8:2dataset/ ├── data.yaml ├── images/ │ ├── train/ # 800张 │ └── val/ # 200张 └── labels/ ├── train/ # 对应800个txt └── val/ # 对应200个txtdata.yaml 里写 path、train、val 相对路径和 names 列表8个名称顺序不能乱。我一般直接把 names 写成这8个英文类别原名模型输出的类别序号就和源数据保持一致。3.2 GPU 平台显存预算与 batch 参数GPU 训练脚本核心命令以 yolo11s 为例yolo train \ modelyolo11s.pt \ datadata.yaml \ epochs100 \ imgsz640 \ batch16 \ device0 \ projectruns/train \ namevehicle_det \ workers8逐项看参数modelyolo11s.pt 会从官方权重启动迁移学习而不是随机初始化这对1000张数据量级很重要epochs100 对中等规模数据偏够用后面看 loss 曲线决定是否延到150imgsz640 是 YOLO 系列默认训练分辨率监控画面如果原始分辨率更高建议保持640先跑通别一上来就上1280batch16 是显存敏感参数device0 指第一张 GPU。显存和 batch 的经验值8G 显存跑 yolo11s imgsz640batch 上限一般是1612G 可以到24~32如果是 yolo11n8G 显存能开到32。拿不准就从 batch8 起步观察有没有 CUDA out of memory 报错再下调。workers8 是数据加载线程数Windows 上如果报 DataLoader worker 错误改成 workers2 或 0 是最快的解决办法。3.3 CPU 与 Mac 平台参数降级方案CPU 训练 YOLO11 现实吗现实只是慢。1000张 imgsz640、epochs100桌面级 CPU 大概要十几个小时起但能跑。命令关键是降参数yolo train \ modelyolo11n.pt \ datadata.yaml \ epochs100 \ imgsz416 \ batch8 \ devicecpu \ workers2三个关键改动模型换最小号 yolo11n、imgsz 降到416、batch 降到8。416 分辨率在监控场景下会损失小目标召回尤其远处摩托车但作为验证流程足够等跑通了再上 GPU 刷高分辨率。workers 在 CPU 训练时意义不大反而可能和主进程抢 CPU设2就好。Mac(M芯片) 平台用 MPS 后端主体命令和 GPU 一致只换 deviceyolo train \ modelyolo11n.pt \ datadata.yaml \ epochs100 \ imgsz640 \ batch8 \ devicempsM芯片上 batch4 到8 比较稳。需要说明MPS 是苹果的图形计算加速后端PyTorch 对它的算子覆盖已经比较全但偶发某个算子不支持导致训练中断。我的处理办法是脚本里捕获异常自动回退 CPU或者先在 yolo11n 上验证全套流程确认数据没问题再换更大模型。Mac 上训练速度比同价位笔记本 CPU 快2~4倍但和桌面 GPU 没法比训练作业放后台挂着第二天看结果。3.4 训练日志怎么读从第一行到收敛训练一启动终端第一行会打印模型摘要显示层数和参数量比如 yolo11s 大约 940 万参数然后是每个 epoch 一行训练指标。重点关注五列box_loss、cls_loss、dfl_loss三个损失precision精确率、recall召回率、mAP50 和 mAP50-95两个评估指标。mAP50 是 IoU 阈值0.5的平均精度mAP50-95 是0.5到0.95每步0.05取平均后者更严格、对边框位置更敏感。看日志判断收敛要分两步先看 loss 在前30个 epoch 是否持续下降如果10个 epoch 内 loss 几乎不动优先怀疑学习率再看 mAP50-95 是否进入平台期连续20个 epoch 涨幅小于0.5%基本可以提前停。Ultralytics 自带 early-stop训练命令加 patience20 的意思是20个 epoch 内 val 指标没提升就自动截断。附带训练日志里一般能看到训练时间同样是1000张图GPU 单卡跑完100 epoch 通常1~2小时CPU 是小时到天级别Mac M系列取中间值。日志每行还有速度信息比如 0.681s/it 表示每轮迭代耗时可以估算总时长总迭代数 epoch数 × 训练集图片数 / batch。800张图、batch16、100 epoch总迭代约5000次按每次0.7秒算大约1小时。心里有这笔账就不干等日志了。4. 车辆检测训练避坑五个高频坑与排查记录4.1 现象训练能跑mAP 一直是0训练流程完整走完loss 在降但 val 阶段 mAP50 显示 0.000基本可以断定 data.yaml 的 names 顺序和 txt 里 class id 对不上。原因是标签里第一列是 id比如0代表 Tractor而 data.yaml names 顺序里0对应的是 Auto模型学到的映射和标注完全错位。解决方法是先读标签统计 id 分布再和 data.yaml 对一遍import yaml from pathlib import Path from collections import Counter cfg yaml.safe_load(open(data.yaml)) id_counter Counter() for txt in Path(labels/train).glob(*.txt): for line in txt.read_text().strip().splitlines(): id_counter[int(line.split()[0])] 1 for i in range(len(cfg[names])): print(i, cfg[names][i], id_counter.get(i, 0))输出里如果发现某个 id 的样本数为0或者 id 分布和 names 明显错位直接修正 data.yaml。这个脚本只花十几秒却是排查这类问题最快的手段。4.2 现象坐标全在[0,1]之外或框位置不对训练前校验脚本过了但验证集画框位置偏。原因是三格式转换时坐标计算错误最常见的是从 VOC 转 YOLO 时把分子分母写反x_center 用了 (xminxmax)/w 而不是先除2。解决方式是画框可视化写脚本把 txt 框画回原图import cv2 from pathlib import Path img_path Path(images/train/000001.jpg) txt_path Path(labels/train/000001.txt) img cv2.imread(str(img_path)) h, w img.shape[:2] for line in txt_path.read_text().strip().splitlines(): cls_id, xc, yc, bw, bh map(float, line.split()) x1 int((xc - bw / 2) * w) y1 int((yc - bh / 2) * h) x2 int((xc bw / 2) * w) y2 int((yc bh / 2) * h) cv2.rectangle(img, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText(img, str(int(cls_id)), (x1, y1 - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 0, 255), 2) cv2.imwrite(check_000001.jpg, img)注意换算公式x1(xc - w/2) * img_widthy2(yc h/2) * img_height对应 VOC 的 xmax/ymax。画出来框明显跑偏就是标签换算问题比对同图的 xml 文件就清楚了。文本里给的三格式是同一标注源生成的正常情况下不会出问题但后期自己用脚本转格式这一步必做。4.3 现象CUDA out of memory训练直接中断显存溢出是 GPU 训练最常见的翻车现场。原因是 batch 设得太大或 DataLoader 缓存数据同时占显存。解决分两步先把 batch 降到8imgsz 降到640还不行就换 yolo11n 模型参数量只有 yolo11s 的约四分之一yolo train modelyolo11s.pt datadata.yaml epochs100 batch8 imgsz640 device0 workers4比 batch16 少一半显存开销。如果显存只有6G直接 yolo11n imgsz512。另外 Windows 上 workers 过大会复现这个报错因为 DataLoader 的缓存也吃内存workers0 能规避大部分内存问题。4.4 现象Auto 与 Car 混淆严重confusion matrix 里两者互相串这两个类别语义接近监控场景里视角变化大侧面、车尾、部分车身被挡时模型很容易混淆。原因不是代码错是类别定义边界不足。解决先看混淆矩阵确认是两个类互串还是单方向串如果 Car 大量被判成 Auto优先检查数据里 Auto 的样本是不是更接近小型乘用车也就是标注本身的边界没切清楚。工程上的处理一般是两种合并这两个类重训或者把容易混淆的样本挑出来补标。少样本类别LCV、Tractor如果和 Truck 混淆一样处理。这类问题属于数据质量层面脚本改参数救不了需要回到 labelimg 里看图片。4.5 现象Mac 上 MPS 训练中途报错或速度异常慢M芯片跑 devicemps有时训练到一半报某个算子 not implemented或者前几个 epoch 极快后面突然变慢。原因是 PyTorch 的 MPS 后端对部分操作走 CPU fallback个别场景下 fallback 逻辑会卡住。解决最直接的是升级到较新的 torch 版本然后小模型加小 batch 再试。如果持续报算子缺失训练脚本改成 CPU fallback 不可耻慢一点但能出结果。另外 cacheTrue 参数在 Mac 上偶尔有问题。Ultralytics 的 cache 选项是把图片预加载到内存Mac 内存带宽虽大但共用建议训练命令里显式 cacheFalse省掉这层麻烦。提示以上五个坑按出现频率排。前两个属于数据层后三个属于运行层。训练前跑一遍第2章的校验脚本加第3章的环境验证可以拦掉一半以上。5. 训练结果验证mAP之外还要看的四项指标5.1 用 val 命令跑一次正式验证训练完成后用 best.pt 单独跑验证集而不是看训练过程里最后几个 epoch 的指标才能确认模型真实水平yolo val \ modelruns/train/vehicle_det/weights/best.pt \ datadata.yaml \ batch16 \ imgsz640 \ device0训练过程中的 val 指标是每个 epoch 在验证集上实时算的模型还在变单独用 best.pt 跑 val 命令等于给最终模型做一次体检两者数据来源不同。正式汇报或部署前统一用后者。batch16 只是推理时的批大小不吃显存的话可以调大不影响精度imgsz640 要和训练一致你训练用416、验证用640得到的指标没有可比性。输出会给出每个类别的 Precision、Recall、mAP50、mAP50-95 列表。重点看每类 AP 分布而不是总体均值。比如总体 mAP50 有0.85但 Tractor 只有0.4说明小样本类别严重拖后腿。1000张的数据集类别不均很常见这时宁可单类看也不看均值。5.2 confusion matrix 与失败样本分析验证输出里会生成 confusion_matrix.png这是必看的一张图。横轴是真实类别纵轴是预测类别对角线越亮越好。看两个地方一是非对角线的高亮格二是 background 那一列的值。background 列高说明模型把背景误检成车监控场景里路灯杆、树影、路边设施容易出现这种误报部署时可以用置信度阈值往下压。每类 AP 的参考线没有绝对标准但监控场景里我习惯拿0.5做分界mAP50 低于0.5的类别进了部署值得怀疑。此时先别急着加数据看清是召回低还是精度低——recall 低说明该类样本少或难例多precision 低说明误检多处理方向完全不同。混淆矩阵里两个车辆类互相串属于边界定义问题回到 labelimg 核对原图背景误检多调高 conf 阈值就有效。失败样本分析我用 predict 跑一批验证集图片把置信度低于0.5但确实有车的找出来看遮挡和远距离小目标占多少yolo predict \ modelruns/train/vehicle_det/weights/best.pt \ sourceimages/val \ conf0.25 \ saveTrue然后到 runs/detect 目录里翻图。遇到严重遮挡漏检如果这类样本在数据集里占有一定比例值得回训练数据里补如果只是个别不用为它牺牲整体精度。5.3 导出模型与部署尺寸选择验证通过后部署前把模型导成 ONNX 或 TensorRT 引擎yolo export modelruns/train/vehicle_det/weights/best.pt formatonnx opset12导出 ONNX 时两个参数值得注意opset 太老会丢新算子opset12 以上比较稳妥导出默认固定输入尺寸部署端如果用动态尺寸导出的 onnx 要带 dynamic_axes 配置否则推理端换分辨率直接报错。TensorRT 导出需要 NVIDIA GPU 环境在目标机器上做转换精度一般比 ONNX 更稳部署帧率也更高。导出时注意输入尺寸训练用 imgsz640导出也保持640推理如果部署端为了速度改成416小目标召回会明显下降。监控场景摄像头画面是1080P我一般裁剪或缩放而不是直接压到416。导出后可以用 onnxruntime 或 TensorRT 在目标机器上跑推理验证精度和训练时 val 的结果偏差在可接受范围。验证的习惯是从数据校验延续下来的先看数字再看图数字决定模型能不能用图决定问题在哪。6. 迁移学习与数据增强把通用车辆数据集用出项目级效果6.1 从预训练权重开始的迁移学习训练脚本默认从 yolo11s.pt 启动这本身就是 COCO 预训练权重的迁移学习。1000张车辆图对 YOLO11 来说数据量不算大从预训练权重起步比随机初始化收敛快、精度也高Ultralytics 默认行为就是加载官方权重不用额外参数。真正需要决策的是要不要冻结骨干网络前几层数据量偏少时冻结浅层可以压过拟合数据够用时放开让它跟着任务调整。我一般先完整跑50个 epoch 看趋势val loss 后期反弹再加冻结不提前赌。6.2 数据增强参数与车辆检测场景的平衡YOLO11 的增强参数集中在训练命令里yolo train modelyolo11s.pt datadata.yaml epochs150 imgsz640 batch16 \ hsv_h0.02 hsv_s0.7 hsv_v0.4 \ degrees0.0 fliplr0.5 \ mosaic1.0 mixup0.1hsv 三项控制颜色抖动监控场景受光照和时间影响大hsv_s0.7 的饱和度扰动帮助模型适应不同天气degrees0.0 不旋转道路交通车辆基本都是水平姿态转了反而引入噪声fliplr0.5 水平翻转几乎所有车辆数据集都开mosaic 保持1.0它把四张图拼一起训练对遮挡和小目标特别有用mixup 只开0.1车辆目标形状差异大mixup 太高会导致边界模糊。这份数据本身带遮挡样本所以 mosaic 别关。如果要试更高上限把 imgsz 提到800比较划算遮挡小目标受益明显代价是训练时间上涨。以上参数组合是我在这类监控数据集上验证过的起点属于保守好用的一组不是最优但不会翻车。6.3 一句话教训真实项目里九成问题出在数据而非模型。那次我在新场景图上直接跑默认参数mAP50 看似0.8部署后连续误报一查是训练集和验证集来自同一批场景泛化被高估。从那以后每次换数据集我都强制走一遍校验脚本、独立场景验证、混淆矩阵三步再急也不跳。希望这份数据集和脚本能帮你把第一步走稳后面少踩点坑获取方式在配套 PDF 文档里按文档说明下载即可。本文还有配套的精品资源点击获取
