简介：面向目标检测实验的YOLO交通标志与交通信号灯数据集，提供877张高清PNG图像及对应的761个XML标注文件，标注对象涵盖限速牌、交通警告牌、红灯、绿灯、黄灯等常见道路元素。所有标注由LabelImg工具人工完成，并已转换为YOLO训练所需的TXT格式，包含目标类别编号及四角坐标信息，可直接用于训练、验证或迁移学习。资源包共1641个文件，以PNG图像和XML标注为主体，另附2个类别映射TXT和1个Python处理脚本，整体压缩包约217.98MB，文件命名规律清晰，便于批量读取与按需筛选。目前已有475人学习/浏览该资源，适合需要现成标注数据开展交通目标检测实操的开发者快速上手。
1. YOLO 交通标志与红绿灯检测数据集：训练前先搞懂这套格式
做目标检测实验最烦的不是调参，而是找数据。你下载了一个「YOLO 交通标志 交通信号灯 红绿灯 检测数据集」，解压出来发现里面有 xml 还有一堆 txt，如果直接扔进 YOLO 训练，大概率第一轮就报错。这套格式本质上是两套标注体系：xml 是 Pascal VOC 格式，txt 是 YOLO 自己用的归一化格式。很多开源数据集会把两种格式都带上，方便你在不同框架间切换。这份方案的真正价值在于，你不用再满世界找标注工具重新标一遍红绿灯和交通标志，拿到手把格式理顺、把标注质量筛一遍，就能直接进 YOLO 训练流程。适合正在做自动驾驶感知、交通场景目标检测毕业设计或横向项目的同学，也适合想用现成数据快速验证 YOLO 改进点效果的工程师。
2. 把 XML 和 TXT 理清楚：Pascal VOC 到 YOLO 的格式转换
2.1 先搞懂两种标注格式的差异
xml 文件是 Pascal VOC 的标准产物。用 LabelImg 标注工具保存时，每张图片对应一个同名 xml，里面用<object>标签包裹每个目标，包含name（类别名）、bndbox（xmin、ymin、xmax、ymax 四个像素坐标）。这套格式的好处是可读性强，用任何文本编辑器都能直接看，xml 文件怎么打开和编辑这个问题，本质上就是用记事本或 VS Code 看一眼<object>块里的坐标对不对。坏处是 YOLO 训练时不会直接读 xml，它要求每张图对应一个同名 txt，每行格式是class_id x_center y_center width height，四个数值全部归一化到 0~1 区间，必须用像素宽度和高度分别做除法。
这里有个新手常踩的坑：VOC 的坐标是xmin, ymin, xmax, ymax，YOLO 要的是中心点坐标和宽高，转换时是先算(xmin + xmax) / 2再除以图像宽度。如果你直接把 xmin 除以宽度当成 x_center，框会全部偏到左下角。另外注意类别 id 不是随便编的，它取决于你训练时data.yaml里类别列表的顺序。比如classes: ['traffic light', 'stop sign', 'speed limit']，那么 traffic light 就是 0，stop sign 是 1。如果自信地按类别名字典序排，且数据集里的类别顺序和你 YAML 不一致，训练不会报错，但 mAP 会惨不忍睹，因为网络学到的类别映射整体错位。
2.2 写一个 XML 转 YOLO TXT 的脚本：核心逻辑与参数
常见的做法是写一个 Python 脚本批量转换，我一般会把转换、过滤、统计做在一个脚本里。转换脚本不复杂，但必须在三个环节加上防御：xml 文件损坏时跳过、坐标越界时裁剪、图像文件不存在时跳过。下面这个脚本可以直接用，放在数据集根目录下运行。
import os import xml.etree.ElementTree as ET from PIL import Image # 类别列表，顺序必须和训练用的 data.yaml 保持一致 class_list = ["traffic light", "stop sign", "speed limit", "crosswalk", "yield sign", "no entry"] def xml_to_yolo(xml_path, img_path, out_path): tree = ET.parse(xml_path) root = tree.getroot() # 有些数据集 xml 里没有 image 节点，需要从外面传图片路径 img = Image.open(img_path) img_w, img_h = img.size lines = [] for obj in root.findall("object"): name = obj.find("name").text if name not in class_list: print(f"跳过未知类别: {name} in {xml_path}") continue cls_id = class_list.index(name) bndbox = obj.find("bndbox") xmin = float(bndbox.find("xmin").text) ymin = float(bndbox.find("ymin").text) xmax = float(bndbox.find("xmax").text) ymax = float(bndbox.find("ymax").text) # 边界防御：有些标注框坐标超出图像边界，直接裁剪 xmin = max(0, min(xmin, img_w)) xmax = max(0, min(xmax, img_w)) ymin = max(0, min(ymin, img_h)) ymax = max(0, min(ymax, img_h)) # 过滤掉退化成一条线或一个点的框 if xmax - xmin <= 0 or ymax - ymin <= 0: print(f"跳过退化框: {xml_path}") continue 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}") if lines: with open(out_path, "w") as f: f.write("\n".join(lines)) else: # 没有有效目标时生成空文件，训练时会自动跳过 open(out_path, "w").close() def main(): for xml_name in os.listdir("xml"): if not xml_name.endswith(".xml"): continue stem = xml_name[:-4] xml_path = os.path.join("xml", xml_name) img_path = os.path.join("images", stem + ".jpg") out_path = os.path.join("labels", stem + ".txt") if not os.path.exists(img_path): print(f"图片缺失: {img_path}") continue try: xml_to_yolo(xml_path, img_path, out_path) except ET.ParseError as e: print(f"xml 解析失败: {xml_path} -> {e}") except Exception as e: print(f"其他错误: {xml_path} -> {e}") if __name__ == "__main__": main()脚本逻辑是逐行读 xml，把每个object的类别名映射成数字 id，再算归一化中心点坐标和宽高。打印未知类别和退化框的意义在于：你看一眼输出，就能知道这个数据集里除了红绿灯和交通标志之外，还有没有混入其他乱七八糟的类别，以及有没有标注框本身就画错了的。
这里重点说两个参数细节。第一个是类别列表class_list，这个顺序就是训练时data.yaml里的顺序。如果你只做红绿灯检测，可以把类别精简成["traffic light", "traffic sign"]，但前提是你要确认 xml 里的 name 字段是否统一。很多数据集里 red light、green light、yellow_light 是分开标的，也有统一标成 traffic_light 的，这里不能想当然，必须实际抽查几个 xml。第二个是输出路径labels目录，YOLO 训练时会去 images 的相邻目录找 labels，目录结构必须严格配对，我在实际项目里见过把 labels 放在子目录里导致训练时所有样本都成了无标签图，损失直接不收敛。
2.3 反过来转换：从 TXT 反向验证 XML 的正确性
有一个方向经常被忽略：你不光需要 XML 转 TXT，训练完还要把预测结果转回像素坐标去画框。DO：写一个反向的小工具，从 YOLO txt 读取归一化坐标，乘回图像宽高，转成 xmin/ymin/xmax/ymax 供 OpenCV 画框。这个工具本质上是上面脚本的逆运算，逻辑极简单，但能救很多次命。每次训练完可视化预测结果，我都是用这个工具把 txt 框画到图上，肉眼确认框的位置对不对。
import cv2 def draw_yolo_txt(img_path, txt_path, class_list): img = cv2.imread(img_path) h, w = img.shape[:2] with open(txt_path, "r") as f: for line in f: parts = line.strip().split() if len(parts) != 5: continue cls_id = int(parts[0]) x_c = float(parts[1]) * w y_c = float(parts[2]) * h bw = float(parts[3]) * w bh = float(parts[4]) * h xmin = int(x_c - bw / 2) ymin = int(y_c - bh / 2) xmax = int(x_c + bw / 2) ymax = int(y_c + bh / 2) cv2.rectangle(img, (xmin, ymin), (xmax, ymax), (0, 0, 255), 2) cv2.putText(img, class_list[cls_id], (xmin, max(0, ymin - 5)), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 0, 255), 2) return img这个反向脚本不需要额外安装 YOLO 环境，只要 OpenCV。我在检查数据集时经常跑一遍，把所有标注框可视化到图上再连续翻图，比任何脚本都能更快发现问题。比如框的中心点整体偏左上，说明归一化坐标算错了；框比目标大一圈，说明标注时把背景也框进去了。这些从数值上很难看出来，画出来一眼就懂。
3. 标注质量决定模型上限：用脚本筛查坏框与漏标
3.1 类别一致性检查：一个数据集里三种红绿灯写法
交通场景数据集最普遍的问题是类别标注口径不统一。同一个数据集里，有的 xml 写traffic light，有的写trafficLight，有的把红灯、绿灯、黄灯拆成三个类，还有的连行人红绿灯和车辆红绿灯都标成了同一个名字。这种不一致如果不清理，模型训练时等于把同一个目标当成多个类别去学，最后每一个类都学不好。
我处理这种数据集的顺序是：先做一次全量类别名统计，把name字段的所有取值打印出来，然后人工归并。归并策略要看你的实验目的——如果目标是「检测出所有红绿灯」，就统一成traffic light一个类；如果目标是「区分红灯、绿灯、黄灯状态」，才拆成多个类。交通标志同理，常见的归并口径有按形状归并（圆形、矩形、三角形），也有按语义归并（限速、禁止、警告）。这里没有一个绝对正确的答案，完全由任务决定，但有一点是铁律：训练和验证必须用同一套类别口径，绝对不能在训练集里用 5 类、在验证集里用 8 类。
import os import xml.etree.ElementTree as ET from collections import Counter counter = Counter() bad_xml = [] for xml_name in os.listdir("xml"): if not xml_name.endswith(".xml"): continue path = os.path.join("xml", xml_name) try: tree = ET.parse(path) root = tree.getroot() for obj in root.findall("object"): name = obj.find("name").text.strip() counter[name] += 1 except Exception as e: bad_xml.append((xml_name, str(e))) print("类别统计:") for name, cnt in counter.most_common(): print(f" {name}: {cnt}") print(f"损坏 xml 数量: {len(bad_xml)}")跑完这个脚本你大概率会发现实际类别数和 README 里写的不一样。这不是数据集作者故意骗你，而是标注人员中途改变了标注规范。碰见这种情况不要慌，按上面说的口径归并即可。归并时要顺手检查一下，有没有「unknown」或者「misc」这类垃圾类别，这类对象在训练中纯粹制造噪声，直接删掉比保留更省心。
3.2 越界框与退化框筛查：标注框坐标越界的三种情况
标注框越界听着像是在 xml 文件里坐公交车超线，其实是坐标超过了图片宽高。产生原因多半是标注工具在缩放图片时鼠标点歪了，或者数据集做过裁剪后没有同步更新标注坐标。这种坏框对训练的影响比你想的大，因为 YOLO 在计算 loss 时会把中心点坐标算到图像外面去，梯度方向直接乱掉。出血的解决办法不是简单地 clamp，而是分三种情况处理。
第一种是轻微越界，比如 xmax 比宽度大几十个像素，直接 clamp 回边界即可。第二种是严重越界，比如整个框有一半在外面，直接删掉更稳妥，因为这种框多半是标注错误而不是裁剪残留。第三种是框的宽或高小于几个像素，这种退化框对 loss 的贡献只有噪声，因为下采样后这个目标在特征图上只剩一个点，模型根本学不到有意义的形状特征。可以设定一个最小面积阈值，比如去掉面积小于 20 像素的框。
import os import xml.etree.ElementTree as ET from PIL import Image def check_boxes(): for xml_name in os.listdir("xml"): if not xml_name.endswith(".xml"): continue stem = xml_name[:-4] img_path = os.path.join("images", stem + ".jpg") if not os.path.exists(img_path): continue img_w, img_h = Image.open(img_path).size tree = ET.parse(os.path.join("xml", xml_name)) root = tree.getroot() for obj in root.findall("object"): b = obj.find("bndbox") xmin = float(b.find("xmin").text) ymin = float(b.find("ymin").text) xmax = float(b.find("xmax").text) ymax = float(b.find("ymax").text) if xmax > img_w or ymax > img_h or xmin < 0 or ymin < 0: print(f"越界: {xml_name} -> {xmin},{ymin},{xmax},{ymax}") if xmax - xmin < 3 or ymax - ymin < 3: print(f"退化: {xml_name} -> {xmin},{ymin},{xmax},{ymax}") check_boxes()跑完这个脚本，你会发现交通场景数据集里退化框特别多，因为红绿灯在画面里经常只有十几像素高。这里要特别提醒：不要一刀切把所有小框删掉。如果任务本身就是远距离检测红绿灯，小框恰恰是宝贵样本。你要做的是把小于 20 像素的框单独统计出来，看看数量占比，再决定是删除还是保留。占比超过 20% 时，建议训练时把输入分辨率调高，比如从 640 提到 1280，不然这些小目标经过下采样后直接消失。
3.3 训练集、验证集、测试集划分：按场景划分而不是随机划分
划分数据集是另一个看起来简单但实际容易翻车的环节。如果只是random.shuffle后按 8:1:1 切分，模型在验证集上的分数会虚高约 2~3 个百分点，因为同一路口的画面会同时出现在训练集和验证集里。正确做法是按场景划分，保证同一地点的图片不会跨集合。
交通数据集的常见组织方式是目录上有scene1/、scene2/这样的场景文件夹，或者文件名带地点编号。如果没有，只能退而求其次：按时间连续段切分，比如前 80% 时间段的图像做训练，后 20% 做验证。还有一种做法是按图像分辨率分组，因为很多数据集里白天 1280 分辨率的图多、夜间 640 分辨率的图少，随机划分会导致夜间图像全部跑到训练集，验证集里全是白天。这些问题真实存在，我在实验里见过最离谱的一次是验证集 mAP 高达 0.87，换到夜间测试视频上直接掉到 0.31。划分离不开对数据的整体感知，处理交通数据前先把图片按光线条件分一下组，这是最省力的捷径。
4. 用这份数据集训练 YOLO：三个必调参数与五个常见问题排查
4.1 三个必调参数：imgsz、batch、anchor
拿到这份交通标志和红绿灯数据集，训练参数不能直接抄 COCO 的默认配置。红绿灯目标尺寸差异极大，路口的红灯可能占 300 像素，远处看到的可能只有 15 像素，这导致默认的 anchor 完全不适合。常见做法是训练前用 k-means 重新聚类 anchor，YOLO 里自带这个工具，在 ultralytics 框架下跑一下就能得到新的 anchor 尺寸。
第一个必调参数是imgsz。默认 640 对大多数目标够用，但红绿灯这种小目标建议调到 960 或 1280。代价是显存占用变大，batch 被迫调小，训练时间变长。这里有个经验值：如果你发现验证集上小目标的 recall 很低，把 imgsz 从 640 提到 960 通常能带来 3~5 个点的提升，比改任何网络结构都见效快。第二个必调参数是batch。batch 大小直接关联 BN 层的稳定性，交通数据集里白天和夜间图片混在一起，颜色分布差异大，batch 太小会导致 BN 的均值和方差估计抖动剧烈，表现为 loss 忽高忽低。建议 batch 至少 16，显存不够就把 imgsz 降下来，而不是牺牲 batch。第三个参数是anchor。如果用 YOLOv8 这类自动 anchor 的版本，可以在配置里多训练几个 epoch 让 anchor 自适应；如果用 YOLOv5 这类需要预置 anchor 的版本，必须重新聚类，否则红绿灯这种极端长宽比的目标框初始 IoU 就低，前几十个 epoch 全在纠正 anchor 偏移上，白白浪费算力。
一个实用的参数组合是imgsz=960 batch=16 epochs=150，初始学习率 0.01，权重衰减 0.0005。这是比较稳的起点，之后根据训练曲线再微调。
4.2 常见问题排查：从玄学到有章可循
问题 1：训练到一半 loss 突然变 NaN
现象：训练曲线前几十个 epoch 正常，某一步 loss 直接变成 nan，之后无法恢复。
原因：最常见的是学习率过大导致的梯度爆炸，其次是 BN 层在高学习率下统计量失去稳态，图像里出现纯黑或纯白的大片区域也会放大这个问题。交通场景里夜间图像经常有纯黑背景，配合高学习率容易爆。
解决：先降到学习率 0.001 试跑 20 个 epoch，如果稳定再调回 0.01。如果降低学习率仍然 NaN，检查是否有标注框的中心点落在图像外，这种异常坐标会在 loss 计算时产生巨大的梯度。另外，开启 AMP 混合精度训练也能有效缓解梯度爆炸。
问题 2：训练损失收敛但 mAP 极低
现象：train loss 掉到 0.05 以下，看起来学得很好，但 val mAP 只有 0.2。
原因：十有八九是类别映射错位或标签路径配错导致训练时读到了错误的 txt。比如data.yaml里 classes 顺序和 txt 里的 class_id 不一致，模型学习到的类别语义全乱了。
解决：随机抽样生成可视化标注图，把 txt 框画到原图上人工比对。如果框的位置正确但类别名对不上，那就在这里。这种错误最坑的地方在于训练过程完全不报错，只能靠可视化排查。
问题 3：混淆矩阵总和不为 1
现象：验证完打印混淆矩阵，发现每一行的值加起来不是 1。
原因：这是 YOLO 验证逻辑里的正常现象。一个真实框可能被多个预测框同时命中，也被计入了多个格子；背景预测和漏检在矩阵里的归属方式在不同版本间有差异。所以不是 bug，不要花费精力去调整。真正要关心的是对角线数值是否足够大，以及漏检集中出现在哪一行。
解决：按类别单独看 recall 和 precision 的曲线，比盯着归一化混淆矩阵的数值更有价值。红绿灯检测的典型表现是红灯类的 recall 高但 precision 低，因为刹车灯会被误检成红灯。建议把混淆矩阵当作定位问题的工具，不要当作评估指标。
问题 4：夜间场景 mAP 崩盘
现象：白天测试效果不错，夜间视频里漏检一半以上的红绿灯和标志。
原因：数据集里夜间样本占比不足，或者夜间图像的曝光差异过大。模型学到的特征偏向白天的高饱和颜色和强纹理，夜间低照度下目标特征衰减严重。
解决：两条路线并行。第一是数据层面，补充夜间的红绿灯图像，如果没有额外数据，用图像增强模拟夜间效果：随机降低亮度、增加高斯噪声、模拟过曝车灯的光晕。增强比例控制在 20%~30%，太多会破坏白天特征。第二是模型层面，把输入归一化方式从简单的除以 255 改为基于数据集统计的标准化，能让夜间图像的特征分布更接近训练分布。
问题 5：验证时预测框大量重叠在同一个小目标上
现象：一个红绿灯上叠了五六个预测框，置信度都挺高，NMS 也去不掉。
原因：NMS 的 IoU 阈值设置过高，默认 0.5 时，多个框的 IoU 超过 0.5 才会被抑制。红绿灯目标小，预测框之间的 IoU 天然偏高，但去除阈值设低会误删正确框。也可能是 anchor 设置不够精细，导致多个 anchor 同时激活。
解决：把 NMS 的 IoU 阈值从 0.5 调到 0.4，同时检查 anchor 聚类结果，如果红绿灯目标的宽高比集中在少数几类，手动补充细长型的 anchor。这个坑在交通信号灯这种小目标场景里非常常见，本质上是目标形态在数据集中处于长尾分布。
5. 验证不只看 mAP：用预测脚本和混淆矩阵判断能不能部署
训练完模型后，mAP 只是起点，工程上还要过两关：一是预测脚本能不能跑通推理流程，二是可视化结果能不能说服自己。先用 Ultralytics 提供的 predict 接口做批量推理，把结果存成带标注的图片，再写一个脚本统计预测框和真实框的匹配情况。
验证脚本的核心是 IoU 匹配逻辑：遍历全部 prediction 和 ground truth，IoU 超过 0.5 且类别相同的算 True Positive，IoU 低于阈值但类别相同的预测算 False Positive，没有对应预测的真实框算 False Negative。统计三类数量，比 mAP 更能直接反映部署时的体验。实际中我发现 mAP 0.8 的模型在连续视频帧上的表现可能很差，因为每一帧的独立检测结果之间抖动严重。更好的验证方式是取一段连续视频，按帧跑预测，把每个目标的中心点轨迹画出来。如果轨迹忽左忽右，说明定位不稳定；如果轨迹连续但中间断了几帧，说明 recall 不够。这是判断模型能否用于量产车端的最基础测试，也是我在实验里的习惯：项目交付前先跑十分钟现场视频，这一关过了再谈模型结构优化。
部署前的最后一个技巧是置信度阈值的选择。验证集上置信度阈值取 0.25 和 0.5 的 mAP 差不了多少，但在实际场景里差别很大。交通标志检测建议阈值取 0.4 以上，宁可漏检也不要误检，因为误检的停车标志会诱导车辆危险操作。这个决策不是模型能帮你做的，只能靠你在验证阶段观察不同阈值下的 precision-recall 曲线来定。希望帮到你。
本文还有配套的精品资源，点击获取
