简介YOLO红绿灯目标检测数据集收录真实道路场景中的红绿灯图片1000张标注由LabelImg工具完成框选准确适用于自动驾驶感知、智慧交通等场景也适合作为目标检测入门或课程设计的训练数据。图片与对应标签按目录存放可直接接入YOLOv5、YOLOv8等常用模型训练流程压缩包同时提供Linux和Windows下的环境搭建教程、完整训练案例教程以及3个数据划分脚本可灵活生成训练集、验证集和测试集。包内共2000个文件主要有约1000个xml标签、990个txt标签辅以6个HTML说明文档、3个Python脚本和1个YAML训练配置整体约487.95MB结构清楚便于按需引用。教程从环境安装讲到模型训练与验证步骤清晰能有效减少踩坑时间。目前已有863人学习下载对需要快速获得红绿灯标注数据并跑通YOLO训练流程的读者来说是一份能直接落地的参考资料。1. 红绿灯检测为什么值得用 YOLO以及这份数据集包解决的三件事红绿灯目标检测是自动驾驶和交通监控里最不能出错的感知任务之一而 YOLO 系列因为速度快、落地生态成熟几乎成了这类小目标检测的首选。标题里的“YOLO红绿灯目标检测数据集”看起来只是个打包资源但里面 1000 张图、三种格式标签、划分脚本和训练教程实际上把最多人反复折腾的三件事一次补齐了标注格式不统一、训练集验证集划分混乱、训练流程跑不通。正因为这三件事天天有人踩坑这份包的价值才不只是“有图”而是“拿来能训”。适合谁如果你是刚接触 yolo 的算法工程师或者在做智慧交通项目但手里只有 VOC 格式的老数据这份包能让你跳过大半的预处理环节。如果你是熟手它更大的价值是提供了一个可以直接对比三种格式差异的样例集用来验证自己的转换脚本。一千张图不算多但足够把一套训练-验证-测试流程完整跑通。2. VOC、COCO 与 YOLO 三种标签格式字段差异与互相转换红绿灯数据集的标签同时给了 voc、coco 和 yolo 三种格式这在开源数据包里算相当贴心。但如果你要改标注、合并样本或者接入自己的训练流程最终都得转成 YOLO 格式。这一章把三种格式拆开讲清楚再给两个可以直接改的转换脚本。2.1 VOC 的 XML 结构框坐标是左上右下还是中心点VOC 格式每个图片对应一个 XML 文件根节点是 annotation里面是 filename、size、object。object 下有 name 和 bndboxbndbox 包含 xmin、ymin、xmax、ymax 四个整数坐标。这是绝对像素坐标不是中心点也不是归一化值。红绿灯在车头视角下往往只有几十像素大小解析时如果用 float 而不是 int后续换算很容易出现小数点偏差虽然看起来不大但训练时对框回归损失的影响会被放大。VOC 格式的好处是直观LabelImg 默认就导这种格式。坏处是训练 YOLO 之前几乎都要转成 txt因为 ultralytics 训练管线直接读归一化后的标签文件。很多第一次接触 VOC 的人以为要手写 XML 解析器其实只用 Python 自带的 xml.etree.ElementTree 就能批量处理。我一般会先写一个扫描函数把整个目录下所有 XML 都读一遍顺便统计类别名确认没有拼写不一致的类名再开始转换。2.2 COCO 的 JSON 结构categories、images、annotations 三段式COCO 格式是把整个数据集的标注信息塞进一个 JSON 文件。顶层结构分三块categories 记录类别 id 到名称的映射images 记录每张图的 id、file_name、width、heightannotations 记录每个标注框的 id、image_id、category_id、bbox、area、iscrowd。这里最关键的坑是 bbox 的表示方式COCO 的 bbox 是[x, y, width, height]x 和 y 是左上角坐标width 和 height 是宽高不是右下角坐标。很多从 VOC 迁移过来的人会把 COCO 的 x、y 当成 xmin、ymin然后直接拿 xwidth 当 xmax这样本身没错但要注意 COCO 的坐标可能是浮点数而 VOC 是整数。红绿灯数据集里如果同时给了三种格式你可以拿同一张图的三个标签做交叉验证先算 VOC 的框宽高再和 COCO 的 width 比较对不上就说明标注管线里有一步换算错了。这套校验思路比任何脚本都管用。2.3 从 VOC 转 YOLO归一化坐标换算与脚本示例从 VOC 转 YOLO 的本质是坐标表示换算。YOLO 每行格式是类别id x_center y_center width height其中中心和宽高都是相对图片宽高的比例值范围在 0 到 1 之间。下面这个脚本是我常用的一套骨架可以直接改成自己的路径。import xml.etree.ElementTree as ET import os def voc_to_yolo(xml_path, out_path, class_names): 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): name obj.find(name).text if name not in class_names: continue cls_id class_names.index(name) bndbox obj.find(bndbox) xmin int(bndbox.find(xmin).text) ymin int(bndbox.find(ymin).text) xmax int(bndbox.find(xmax).text) ymax int(bndbox.find(ymax).text) # 做边界裁剪防止标注框越界导致归一化值大于1 xmin max(0, min(xmin, img_w - 1)) xmax max(0, min(xmax, img_w - 1)) ymin max(0, min(ymin, img_h - 1)) ymax max(0, min(ymax, img_h - 1)) box_w xmax - xmin box_h ymax - ymin if box_w 0 or box_h 0: continue # 从左上右下两点换成中心点加宽高再分别除以图宽图高 x_center (xmin xmax) / 2.0 / img_w y_center (ymin ymax) / 2.0 / img_h w_norm box_w / img_w h_norm box_h / img_h lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {w_norm:.6f} {h_norm:.6f}) with open(out_path, w) as f: f.write(\n.join(lines)) class_names [red, green, yellow] # 按项目实际类别顺序调整 voc_to_yolo(0001.xml, 0001.txt, class_names)这段脚本的关键在两点一是先把绝对像素坐标算出来再做归一化二是边界裁剪那几行。红绿灯图片经常出现标注框贴着图片边缘的情况如果不裁归一化后的 width 或 height 可能超过 1训练时 YOLO 的 anchor 匹配会算错轻则警告重则 loss 变成 nan。class_names 的顺序决定了 txt 里第一列的数字这个顺序必须和之后 data.yaml 里的 names 完全一致。红绿灯项目一般就是红色、绿色、黄色三类如果数据包里还细分了左转箭头灯记得先看标注里的类别名别想当然。2.4 从 COCO 转 YOLO按 image_id 关联的常见错误COCO 转 YOLO 的换算逻辑更绕因为标注框分散在 annotations 列表里要先用 image_id 找到图片宽高才能归一化。很多人拿到 COCO 就老老实实遍历 annotations结果发现不知道图片尺寸就是因为漏了 images 这个映射。import json import os def coco_to_yolo(coco_json, out_dir, class_names): with open(coco_json) as f: data json.load(f) # 建立 image_id 到图片信息的映射 img_map {img[id]: img for img in data[images]} # 按图片id聚合所有标注框 ann_map {} for ann in data[annotations]: ann_map.setdefault(ann[image_id], []).append(ann) # 建立类别id到类别名的映射 cat_map {cat[id]: cat[name] for cat in data[categories]} for img_id, anns in ann_map.items(): img img_map[img_id] img_w img[width] img_h img[height] file_name img[file_name] base os.path.splitext(file_name)[0] lines [] for ann in anns: if ann.get(iscrowd, 0) 1: continue # 忽略群体标注 name cat_map[ann[category_id]] if name not in class_names: continue cls_id class_names.index(name) x, y, w, h ann[bbox] # bbox左上角转中心点再归一化 x_center (x w / 2) / img_w y_center (y h / 2) / img_h w_norm w / img_w h_norm h / img_h lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {w_norm:.6f} {h_norm:.6f}) out_path os.path.join(out_dir, base .txt) with open(out_path, w) as f: f.write(\n.join(lines))这段脚本最容易翻车的是 ann[bbox] 里的 w 和 h 可能为 0或者 x、y 超出图片边界。红绿灯在截断的场景里偶尔会出现这种脏标注建议在转换时加一个判断如果 w 或 h 小于 1直接跳过。另一个坑是类别 id 映射COCO 的 categories 里 id 往往不是从 0 开始而是从 1 或 90 开始转换时用 cat_id 先找到类别名再用 class_names.index 重新编号这一步绝不能省。转换完之后建议抽 20 张图把 YOLO 标签画回去。用 OpenCV 读图根据 txt 里的归一化坐标反算像素框与原图叠在一起看。这算是整条流水线里最值得做的一步因为三种格式之间转来转去肉眼直接看到框比任何数值校验都可靠。3. 用划分脚本按比例切分数据集train/val/test 的落盘与校验有了统一格式的标签下一步就是划分数据集。标题里的划分脚本听起来像个小工具但做不好会让后面所有训练结果失真。这一章讲清楚划分脚本的边界条件和常见坑给出可改的代码再讲划分完怎么自查。3.1 划分脚本做的事文件移动、空标签过滤、随机种子划分脚本的实际任务不是简单把文件复制到三个文件夹而是做四件事扫描图片和同名标签过滤没有有效标注的样本按比例随机切分最后生成训练用的 data.yaml。注意划分的最小单位是“图片-标签对”不能只拷图片漏掉 txt否则训练时会报 label not found 的错。另一个容易忽略的是空标签文件。红绿灯数据集中可能有少量背景图没有灯对应 txt 是空的。这些图不该直接丢它们是负样本能帮助模型降低误检。划分脚本要能把空 txt 单独放一组比如放进 val 或 test用来验证模型在无信号灯路口的虚警率。很多新手把空标签文件全部删除结果模型在没灯的场景里疯狂输出框就是缺了这类负样本。固定随机种子是划分脚本里最重要的习惯。不管用 random.seed(42) 还是 numpy 的 RandomState只要固定了每次划分结果都一样。这样后面调整模型时train 和 val 的分布不变比较实验结果才有意义。否则同一份数据换个机器划分结果就变了A 模型比 B 模型高 0.02 个 mAP 都说不清是模型差异还是数据差异。3.2 一套可改的 Python 划分脚本下面是一个通用划分脚本假设图片和标签已经转换成 YOLO 格式并且分别放在两个平铺目录里。import os import random import shutil random.seed(42) # 固定种子保证可复现 source_imgs images source_labels labels out_root dataset split {train: 0.8, val: 0.1, test: 0.1} for fname in os.listdir(source_imgs): if not fname.lower().endswith((.jpg, .jpeg, .png)): continue base os.path.splitext(fname)[0] img_path os.path.join(source_imgs, fname) label_path os.path.join(source_labels, base .txt) if not os.path.exists(label_path): continue # 没有标签的文件不参与训练 r random.random() if r split[train]: target train elif r split[train] split[val]: target val else: target test os.makedirs(os.path.join(out_root, target, images), exist_okTrue) os.makedirs(os.path.join(out_root, target, labels), exist_okTrue) shutil.copy(img_path, os.path.join(out_root, target, images, fname)) shutil.copy(label_path, os.path.join(out_root, target, labels, base .txt))这段脚本的关键参数是 split 字典。1000 张图规模不大8/1/1 是常见选择。如果测试集太小比如只有 50 张评估结果的方差会很大一次验证 mAP 波动 0.05 都很正常。这时候可以把比例改成 8.5/1/0.5但不建议 test 低于 5%。脚本里的随机划分是纯随机它有个缺点某一类灯可能在 test 里一个都没有导致那个类别的 AP 算不出来。红绿灯只有三类更稳妥的是按图片里出现的类别做分层采样先统计每张图包含哪些类再分别从每类里抽一部分进 val 和 test。实现起来不复杂就是在随机分桶之前加一个类别索引。使用脚本时注意目录结构ultralytics 训练时默认按相对路径查找 dataset/train/images 和 dataset/train/labels。所以 out_root 下面必须按 train、val、test 分三层每层下再分 images 和 labels。如果你的图片和 labels 不是平铺目录脚本要先做一轮路径整理把子目录里的文件全部拍平。3.3 划分后必做的三件事检查类别数、图片-标签对齐、测试集不参与训练划分完成后不要急着训练先做三个快速检查。第一统计每个集合的类别分布看有没有哪一类在 val 或 test 里缺失。用一段简单的 bash 就能完成for split in train val test; do echo $split cat dataset/$split/labels/*.txt | awk {print $1} | sort | uniq -c done这段命令逐个统计每个 txt 里的第一列类别 id。如果 train 有 0、1、2 三类而 val 里只有 0 和 1那红灯的验证指标就完全缺失了。第二检查图片和标签数量是否一一对应图片目录里有 800 张 jpglabels 目录里就必须有 800 个 txt多一个少一个都说明划分脚本漏了条件。第三打开生成的 data.yaml确认 train 路径下没有包含 test 目录。很多人图省事把整个 dataset 目录直接给训练脚本导致 test 混进训练mAP 虚高到了真实路口才发现模型对没见过的场景几乎没有泛化能力。检查完这些划分这一步才算真正结束。这也是为什么我建议用脚本而不是手工拖拽文件的原因手工操作漏一个文件很难发现脚本至少能保证规则一致。红绿灯这类小目标数据集的划分做扎实了后面的训练和对比才有可信度。4. 训练教程从环境配置到跑通 YOLO 的完整命令数据准备好进入标题里的训练教程部分。红绿灯检测的训练流程和通用目标检测没有本质区别但有几个参数直接决定小目标能不能被看见。这一章按环境、配置、命令、曲线观察的顺序走一遍。4.1 YOLO 环境配置CUDA、PyTorch 与 ultralytics 版本对齐训练教程最常卡住的不是模型而是环境。YOLO 的常见实现是 ultralytics 包它把训练、验证、导出都集成在命令行里安装命令很简单pip install ultralytics但这里有个隐形成本ultralytics 依赖 PyTorchPyTorch 依赖 CUDA三者版本不对齐训练会出现各种诡异报错。我的建议是先跑 nvidia-smi 看显卡驱动支持的 CUDA Version比如显示 12.1就去 PyTorch 官网装 cu121 对应的版本最后再装 ultralytics。顺序反过来的话pip 很可能装了一个 CPU 版的 torch代码能跑但训练速度慢到怀疑人生。环境装好后用下面这个命令确认 GPU 是否被正确识别python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))输出 True 说明环境没问题。如果输出 False大概率是 torch 装成了 CPU 版本或者 CUDA 环境变量被覆盖。yolo 环境配置这一步真的就是版本对齐不要自己瞎改源码先把这三个版本号打印出来对上。4.2 准备 YOLO 格式的 data.yaml 与目录结构ultralytics 训练前需要一个 data.yaml里面指定数据集路径和类别名。这个文件比想象中严格路径写错一个字母训练就直接报错。模板如下path: dataset # 数据集根目录 train: train/images val: val/images test: test/images nc: 3 names: [red, green, yellow]train、val、test 都是相对于 path 的路径不需要写绝对路径。ultralytics 会自动找与 images 同级的 labels 目录所以文件夹结构必须是 dataset/train/images 和 dataset/train/labels 成对出现。很多人在 yaml 里额外写了一个 labels 路径反而会覆盖默认逻辑导致找不到文件。names 的顺序必须和转换脚本里的 class_names 一致如果这里把 green 放到了第一位而 txt 里的类别 0 是 red模型就会把所有红灯都说成绿灯混淆矩阵里非常刺眼。如果手里有预训练权重可以直接把 model 参数设为 yolov8s.ptultralytics 会自动下载也就是常说的 yolo 预训练模型下载。用 COCO 预训练权重做初始化可以让红绿灯模型的收敛速度快很多尤其是小目标特征提取底层卷积已经有了不错的泛化基础。4.3 训练命令与参数说明epochs、batch、imgsz、workers准备好 data.yaml 后启动训练只需要一行命令yolo train modelyolov8s.pt datared_light.yaml epochs150 batch16 imgsz640 workers4 device0这里每个参数都值得细说。epochs 在红绿灯这种 1000 张图的小数据集上不建议低于 100否则没收敛就停了。batch 大小看显存16G 显存跑 yolov8s 的 640 分辨率batch16 是安全值如果训练中途显存溢出优先把 workers 调低到 2再不行才降 batch。imgsz 是红绿灯项目里最值得调的超参因为灯在画面中经常小于 40x40 像素把 imgsz 从 640 提到 960 能明显提升小目标召回率代价是训练时间和显存占用接近翻倍。如果你只是验证流程先用 640 跑通再抽一晚专门调 imgsz。workers 控制数据加载线程数Linux 下一般可以拉到 8Windows 下建议 4 以内太高容易触发 DataLoader 报错。device0 是单卡 GPU如果你用 CPU 训练别说 1000 张图连预处理都能跑半天。整个训练过程会打印每个 epoch 的 loss 和 mAP还会在 runs/detect/trainN 目录下保存 best.pt 和 last.pt。后续接验证和导出都用 best.pt它是在 val 上表现最好的权重而不是最后一个 epoch。4.4 训练中看什么loss 曲线与 BN 崩溃现象训练不是把命令跑完就结束还要会看指标。YOLO 的损失函数由三部分组成box_loss 负责框回归cls_loss 负责分类dfl_loss 负责框的分布。红绿灯类别少cls_loss 会在前几十轮就降得很低这时候别高兴太早真正需要盯着的是 box_loss 和 dfl_loss 是否持续下降。如果这两个曲线在某个平台期纹丝不动说明框的定位精度到头了要调整 model 大小或 imgsz。训练中另一个常见异常是 loss 变成 nan这是 yolo 训练中 bn 崩溃的典型表现。现象是前面几十轮正常突然某一步 loss 变成 nan之后所有指标都跟着崩。原因多半是 batch 太小或学习率太大导致 BatchNorm 的统计量发散。解决办法第一条是把初始学习率从 0.01 降到 0.001第二条是增大 batch。如果显存不够用 batch8 配合 gradient accumulation 也能模拟大 batch 的效果。我碰到过一次 bn 崩溃是在用 960 imgsz 的时候显存只能塞 batch4BN 统计量完全不稳定换成 batch8 之后问题就消失了。训练日志里还有每个类别的 recall 和 mAP红绿灯项目要特别关注红灯的 recall。很多模型在训练集上绿灯 recall 0.95红灯只有 0.7这就是类别不平衡的早期信号等训练完再处理就晚了。看到这种趋势应该尽早回退到数据层面补红灯样本或者调整类别权重而不是继续堆训练轮数。5. 红绿灯训练常见问题排查从数据翻车到模型不收敛这一章把红绿灯训练里最常见的五类问题列出来每条按现象、原因、解决的思路写。这些问题我基本都遇到过有的翻车翻得印象深刻。5.1 图片里红绿灯太小小目标漏检怎么调现象模型对近处大尺寸的灯框得很准但画面远处的灯完全检测不到输出的置信度很低甚至没有框。原因1000 张原始图片里小目标占比太高YOLO 默认的 anchor 尺度对大目标更友好小目标的特征在深层特征图里已经被压缩没了。解决先把 imgsz 从 640 提到 960 或 1280让小目标在特征图里占据更多像素。如果显存不够第二个选择是使用 yolov8m 这种更深更宽的模型它有更多参数去拟合小目标细节。第三个选择是开启马赛克增强让模型在训练时看到更多不同尺度下的灯。需要注意的是这三种手段都增加训练时间不要同时上一次调一个变量否则很难判断是哪个起了作用。5.2 标签坐标越界或归一化后为负数导致训练中断现象训练到一半报错提示某个标签文件里的坐标值超出 0 到 1 的范围或者出现负数。原因转换脚本没有做边界裁剪或者图片本身有 EXIF 旋转信息读出来的宽高和标注工具里看到的不一致。解决训练前先写一个扫描脚本读取每个 txt 的五个数值检查前四个值是否都在 0 到 1 之间。如果发现问题回到 VOC 或 COCO 原始标注重新转换并且一定要在转换脚本里加边界裁剪。不要直接手改 txt因为一张图可能有多个框手工改容易漏。还有个小技巧训练时如果关闭了 ultralytics 的 cache 参数改完标签后不用清理缓存如果开了 cache 属性改完标签要删掉 runs 目录下的缓存文件否则训练读的还是旧标签。5.3 类别不平衡绿灯样本远多于红灯和黄灯现象混淆矩阵里绿灯的 recall 很高红灯和黄灯的 recall 很低但训练集里红灯明明也有几百个框。原因城市路口绿灯时间最长数据采集时绿灯自然出现得最多如果不做平衡处理模型会倾向于把不确定的框预测成样本量大的类别。解决最直接的方法是补采红灯和黄灯的样本但有时候数据来源受限。更实用的是在划分脚本里做类别加权采样或者使用 ultralytics 的 class weights 参数。具体做法是统计每个类别的边框数量把数量少的类别在损失函数里乘以一个大于 1 的权重。红绿灯只有三类还可以试试把黄灯单独挑出来做一次数据增强比如随机调整饱和度因为黄灯和红灯在部分摄像头色彩偏移下非常容易混淆。5.4 BN 崩溃导致 loss 变成 nan 的处理现象训练曲线前期正常某个 epoch 开始 loss 突然变成 nan之后整个训练过程都无法恢复输出框全消失。原因yolo 训练中 bn 崩溃常见诱因是 batch 太小或学习率太大。红绿灯图片色彩相对接近不像自然图像那么多样BN 统计量本来就容易波动。解决第一步把初始学习率降到 0.001如果还崩就增大有效 batch。所谓有效 batch是把梯度累积步数也算进去比如实际 batch4累积步数设为 4等效 batch16。第二步是加载上次正常的检查点继续训练不要从头开始因为从头再来可能还是会在同一个位置崩溃。如果反复崩换一个随机种子或者去掉 mosaic 增强也有一定概率绕过去。5.5 混淆矩阵总和不是 100% 该怎么读现象验证阶段打印的混淆矩阵每一行加起来不是 100%网上经常有人问 yolo 混淆矩阵总合不唯一是怎么回事。原因混淆矩阵的行代表真实类别列代表预测类别。如果某个目标漏检了没有任何预测框匹配那这个样本就不会出现在矩阵的任何位置所以行和会小于总数。反过来一个目标被重复预测成多个类别或者误检框没有匹配到真实目标列和也可能超过总数。这是目标检测里很正常的现象不是 bug。解决不要看百分比的总和只看对角线上的数值相对大小。对红绿灯项目来说最危险的是红灯被识别成绿灯、绿灯被识别成红灯这种非对角线位置的数字哪怕只有几个也要严肃对待因为它直接导致车控决策翻车。如果出现这种错误优先检查类别顺序是否在转换脚本和 data.yaml 里对齐再检查数据增强里是否用了过强的色彩扰动把红色灯调成了白色。6. 进阶用验证集混淆矩阵和 mAP0.5 判断模型是否真正可用6.1 快速跑一次验证脚本训练完成后用 best.pt 跑一次标准验证命令如下yolo detect val modelruns/detect/train5/best.pt datared_light.yaml splitval这个命令会输出每个类别的 precision、recall、mAP50 和 mAP50-95。红绿灯这个任务里我更看重 mAP50因为灯是交通信号不需要检测出极精确的轮廓框稍微大一点不影响判断mAP50-95 对框位置要求太严格用在红绿灯上会显得特别低新手容易被吓退。验证时还要注意 splitval不要拿 test 集反复调模型test 只能在整个流程结束后跑一次否则测试集信息会通过人工调参泄漏进模型。6.2 我的经验教训先看 recall 再看 precision有一次我调了一周的红绿灯模型precision 从 0.9 涨到 0.97我以为大功告成结果一看 recall 只有 0.62等于四成红灯压根没被框出来。后来我把验证时的 conf 阈值从 0.25 降到 0.1recall 涨到 0.8虽然 precision 掉了一些但这才是真正能用的检测器。红绿灯场景里漏检的后果比误检严重得多因为控制逻辑可以容忍多一个假框但不能容忍看不见红灯。所以我的习惯是每次训练结束固定随机种子重新跑一次 val把混淆矩阵存下来对比不同检查点之间红灯 recall 的变化。这个单类指标比总 mAP 更能反映路口实际感知能力。最后要说的经验是别只盯着训练集上的指标收敛要拿 best.pt 导出 ONNX 或 TensorRT放到真实路口视频上跑一遍。红绿灯模型真正翻车的场景往往是夜间眩光、逆光、雨刷遮挡这些光线下离线指标再好都没用。从数据整理到三种格式转换再到划分脚本和训练排错每一步都比最后调那点学习率更影响效果。希望帮到你。本文还有配套的精品资源点击获取
