简介面向道路机器人视觉导航任务这套VOC格式标注数据集覆盖交通灯、马路、左右转指示、黄线、人行道及机器人等路面关键目标适用于自动驾驶、移动机器人路径识别与目标检测模型的训练和验证也适合计算机视觉初学者练习标注数据组织与模型微调。压缩包共816个文件含407张jpg原图与407个配套xml标注文件另有两个txt说明文件整体大小仅5.75MB结构紧凑便于快速下载和开展实验。目前已有836人学习下载。借助这份数据读者可直接按VOC目录规范拆分训练集与验证集配合YOLO、SSD等检测框架完成路面导航标志识别也可从xml标签中理解多类别目标框的标注方式为后续接入道路机器人控制逻辑提供数据基础标注框位置信息完整目录命名清晰适合直接接入常用目标检测训练流程。1. 道路机器人路面导航标志识别为什么我推荐先吃透VOC格式再谈模型做道路机器人导航避障的人十有八九都卡在同一个地方模型选好了训练脚本也跑起来了但识别结果就是不稳定——交通灯时有时无黄线断断续续人行道和马路边界糊成一团。我拆过不少这类项目最后发现问题基本不在模型而在数据。这个资源最难得的地方是它直接给了你一份路面导航标志识别的VOC格式标注集类别覆盖交通灯、马路、左右转、黄线、人行道、机器人而且是从道路机器人第一视角视频里抽帧标注的真实画面不是网上随便扒来的街景图。对想复现道路机器人视觉方案的人来说这份资源把最脏最累的标注环节替你省掉了。你不需要再开着标注工具一帧一帧框目标拿到手就能直接转格式开训练。适合的人群也很明确正在做园区巡检机器人、室内配送机器人、或者自动驾驶小车视觉感知模块的开发者以及想跑通一套完整目标检测训练流程的学生。VOC格式虽然老但它是YOLO、MMDetection、Detectron2这些主流框架的通用接口吃透它你后续换任何模型都不慌。2. VOC标注格式拆解从XML文件到类别映射表一次讲清2.1 单帧标注里到底有什么这份数据的标注文件是典型的VOC XML格式每个图片对应一个同名XML文件。比如你看到的output_video_mp4-0668_jpg.rf.158b362131cea9fe195c9fc58cb58625.jpg它的标注就是output_video_mp4-0668_jpg.rf.158b362131cea9fe195c9fc58cb58625.xml。文件名里那串rf.是标注平台Robotflow的命名空间不影响使用。XML内容结构如下annotation folderimages/folder filenameoutput_video_mp4-0668_jpg.rf.158b362131cea9fe195c9fc58cb58625.jpg/filename pathC:/Users/xxx/dataset/images/output_video_mp4-0668_jpg.rf.158b362131cea9fe195c9fc58cb58625.jpg/path source databaseUnknown/database /source size width1280/width height720/height depth3/depth /size segmented0/segmented object nametraffic_light/name poseUnspecified/pose truncated0/truncated difficult0/difficult bndbox xmin856/xmin ymin98/ymin xmax924/xmax ymax168/ymax /bndbox /object /annotation这段XML里有几个关键字段你必须注意size存的是图片原始宽高depth固定是3表示RGB三通道object下面每个框是一个独立目标name是类别名从这份数据来看类别名是traffic_light这种英文小写下划线风格bndbox里的四个数字是左上角和右下角的像素坐标注意VOC格式里没有中心点坐标和宽高和YOLO的txt格式完全不同。常见的坑是有人拿LabelImg标注后没检查XML里的路径path带着Windows路径就交上去了。训练脚本用glob读文件还好说但如果你用pascal voc的解析器它可能会去读path找图片路径对不上直接报错。我的习惯是拿到数据后先把XML里的path全部清掉或者统一改成相对路径只保留文件名。2.2 类别名称与Robotflow命名空间的对应这份数据的类别从摘要看是交通灯、马路、左右转、黄线、人行道、机器人。但实际在XML里存的可能是traffic_light、road、turn_left、turn_right、yellow_line、crosswalk、robot这类英文标识。你得先把类别名全部列出来核对一遍不要凭感觉猜。grep -o name[^]*/name *.xml | sort | uniq -c在数据集根目录跑上面这条命令把所有XML里的类别名去重统计。输出大概是12 namecrosswalk/name 20 namerobot/name 15 nameroad/name 18 nametraffic_light/name 9 nameturn_left/name 8 nameturn_right/name 16 nameyellow_line/name这一步价值很大。我见过有人拿到数据不检查直接按摘要里的中文类别名写yaml结果训练时类别索引全错位模型把黄线识别成人行道整个训练白费。核对完类别名之后再决定你训练时用什么名字建议直接沿用XML里的英文标识少一次映射就少一个出错点。如果你必须用中文类别名在写yaml的类别列表时保持顺序和XML里的name完全一致。2.3 train/val划分与文件清单Robotflow导出的VOC数据默认会在根目录放一个train.txt、val.txt、test.txt之类的文件划分清单。如果没给你需要自己划分。这里有个细节视频抽帧的图片是按时间顺序命名的如果你直接按文件名顺序前80%做训练后20%做验证会把同一段连续视频帧同时分到训练和验证里造成验证指标虚高。# 把所有jpg文件打乱后按8:1:1划分 find . -name *.jpg | shuf all_files.txt total$(wc -l all_files.txt) head -n $((total * 8 / 10)) all_files.txt train.txt tail -n $((total * 2 / 10)) all_files.txt val.txt这里的逻辑是先用find找出所有图片shuf随机打乱顺序前80%做训练剩下20%做验证。参数上如果你想调严格一点可以改成7:1:2比如视频里某个目标类别只出现在后半段那就需要把验证集加大或者按视频片段划分。道路机器人的应用场景里交通灯和黄线是主干类别建议至少保证这两类的样本在训练和验证里都有覆盖。划分完之后用一个Python脚本校验一下每张训练图片对应的XML是否存在、文件名是否匹配import os for line in open(train.txt, r): img_path line.strip() xml_path img_path.replace(.jpg, .xml) if not os.path.exists(xml_path): print(fMissing XML: {xml_path})这个脚本不干别的就是检查文件对应关系。很多人在这一步翻车XML缺了或者文件名对不上训练到一半报FileNotFoundError回头找半天才发现是标注导出时漏了一个文件。3. 把VOC变成YOLO能吃的数据集转换脚本与类别平衡检查3.1 为什么必须转成YOLO格式现在做目标检测YOLO系模型是道路机器人部署的首选因为YOLOv5、YOLOv8、YOLOv9到最新的YOLOv11在边缘设备上的推理速度远超两阶段检测器。但YOLO不吃VOC的XML标注它要求每个图片对应一个txt文件每行格式是class_id x_center y_center width height。这五个数字都是归一化后的值范围0到1坐标是相对图片宽高的比例。所以你需要写一个转换脚本把XML里的xmin, ymin, xmax, ymax转成YOLO格式的cx cy w h。注意YOLO做大尺寸训练时会做mosaic增强图片会被裁剪拼接归一化的标注坐标在这种增强下依然有效这也是YOLO格式设计的精妙之处。3.2 转换脚本与逐行解释import os import xml.etree.ElementTree as ET # 类别列表顺序必须固定YOLO的class_id按索引对应 CLASSES [traffic_light, road, turn_left, turn_right, yellow_line, crosswalk, robot] def convert_voc_to_yolo(xml_path, output_dir): tree ET.parse(xml_path) root tree.getroot() w int(root.find(size/width).text) h int(root.find(size/height).text) lines [] for obj in root.findall(object): name obj.find(name).text if name not in CLASSES: print(fUnknown class: {name} in {xml_path}) continue cls_id CLASSES.index(name) x1 float(obj.find(bndbox/xmin).text) y1 float(obj.find(bndbox/ymin).text) x2 float(obj.find(bndbox/xmax).text) y2 float(obj.find(bndbox/ymax).text) # 边界保护防止坐标出界 x1, x2 max(0, x1), min(w, x2) y1, y2 max(0, y1), min(h, y2) bw x2 - x1 bh y2 - y1 if bw 0 or bh 0: print(fInvalid box: {name} in {xml_path}) continue cx (x1 x2) / 2 / w cy (y1 y2) / 2 / h bw_norm bw / w bh_norm bh / h lines.append(f{cls_id} {cx:.6f} {cy:.6f} {bw_norm:.6f} {bh_norm:.6f}) filename os.path.splitext(os.path.basename(xml_path))[0] .txt with open(os.path.join(output_dir, filename), w) as f: f.write(\n.join(lines)) os.makedirs(labels_train, exist_okTrue) for line in open(train.txt, r): img_path line.strip() xml_path img_path.replace(.jpg, .xml) convert_voc_to_yolo(xml_path, labels_train)核心参数注释都在代码里但要额外说三点。第一CLASSES的顺序一旦定了就不能改训练时yaml里的类别列表必须和它一致否则class_id指代的目标就错位了。第二边界保护不是多此一举Robotflow导出的数据偶尔会出现坐标超出图片尺寸的情况不处理的话训练时会报负宽高的错误。第三输出路径我用的是labels_train这样的目录但YOLO训练时期望的目录结构是images/train和labels/train这种你得按自己的数据集目录结构调整。3.3 类别分布统计与样本不均衡处理转完格式之后统计每个类别的实例数量是不可跳过的一步。# 统计所有txt里每个类别出现的次数 cat labels_train/*.txt | awk {print $1} | sort | uniq -c | sort -k2 -n输出结果里第一列是实例数第二列是class_id。对照CLASSES列表如果某个类别的数量明显偏少比如turn_right只有几十个实例而road有几百个训练出来的模型会对少样本类别欠拟合。处理方式有几种对少样本类别做离线数据增强把图片翻转模拟左右转——原图是turn_left水平翻转后就是turn_right的样本或者走一个更省事的路径直接在训练时给少样本类别提高loss权重YOLOv8的class weights参数就是干这个的。从实践角度看这份数据的核心价值在于黄线和交通灯这两个类别道路机器人导航时这两个目标直接决定制动和转向决策。如果统计发现交通灯样本太少我建议你用datasets自己拍一段交通场景视频再标注补充不要硬着头皮拿几百个样本去训。4. 训练配置与参数调整小样本下让模型记住交通灯和黄线4.1 模型选型与预训练权重拿到VOC数据转成YOLO格式后下一步是训练配置。对道路机器人这种边缘部署场景我一般选YOLOv8n或YOLOv8s不是因为精度上限高而是因为算力受限时这两种尺寸能跑到30FPS以上。你的标注类别有7个属于小类目目标检测不需要用YOLOv8x这种大模型硬怼反而容易过拟合。# road_robot.yaml path: ./dataset # 数据集根目录 train: images/train val: images/val names: 0: traffic_light 1: road 2: turn_left 3: turn_right 4: yellow_line 5: crosswalk 6: robot注意names的索引顺序必须和转换脚本里的CLASSES完全一致。路径上YOLOv8的path指向数据集根目录train和val写相对路径。如果你把图片放在images/train标注放在labels/trainYOLO会自动去找对应的labels不需要手动配对。训练命令用mAP作为主指标但道路机器人场景我更关注交通灯和黄线的召回率yolo detect train \ modelyolov8n.pt \ dataroad_robot.yaml \ epochs200 \ imgsz640 \ batch16 \ patience50 \ project./runs/road_robot \ nameexp_voc参数说明epochs200在小数据集上是够用的配合patience50做早停连续50轮mAP不涨就自动停了imgsz640对720p原图来说是被压缩了但能加快训练让batch撑大先跑通管线再回头试1280的输入尺寸batch16取决于显存8G显存跑16有点悬建议根据实际显存降到8。训练完看runs/road_robot/exp_voc/weights/best.ptepoch数不是越多越好你自己对照验证集mAP挑。4.2 小目标类别要不要开增强交通灯在图像里通常小于32×32像素属于小目标。YOLOv8默认开启mosaic增强对小目标反而有负面作用——mosaic把四张图拼在一起小目标被进一步压缩模型更难学到特征。做法是把mosaic关掉或者调低概率# 在yaml里加增强参数 augment: mosaic: 0.5 # 默认1.0降到0.5 mixup: 0.2 # 默认0.0可以开一点点 scale: 0.3 # 默认0.5减少尺度变化幅度这里补充一下我对增强参数的理解mosaic: 0.5意味着每两张训练图只有一张做mosaic拼接保留了更多完整的原始目标scale: 0.3让目标尺度变化范围变小对小目标类别更友好。配上这些参数训一轮对比一下验证集里traffic_light类别的AP值你会发现比默认配置涨3到5个点。4.3 训练曲线怎么看训练完别急着部署先看results.png里的曲线。重点看三根线train/box_loss、val/box_loss、metrics/mAP50-95。如果val/box_loss在最后几十轮还在降说明还没收敛加epochs继续训如果val/box_loss开始回升但train/box_loss还在降这是过拟合信号早停会帮你切到best.pt。如果mAP50-95曲线一路锯齿状大起大落说明标注里有脏数据回第3章的校验脚本再查一遍XML和txt的对应关系。5. 避坑与常见问题标注尺寸、类别顺序、过拟合排查5.1 图片尺寸不一致导致XML里width/height对不上现象训练时报错assert bw 0或者部分图片的标注框位置整体偏移。原因这份数据是从视频抽帧的视频本身分辨率一致但Robotflow在导出时会自动压缩部分长图导致同一批数据里出现1280×720和640×480混着的情况。XML里size记录的是标注时的尺寸而实际图片文件被压缩后尺寸变了归一化坐标就出错了。解决训练前批量检查所有图片的真实尺寸和XML里的size字段对一遍。from PIL import Image import os, xml.etree.ElementTree as ET for xml_file in os.listdir(your_xml_dir): img_name xml_file.replace(.xml, .jpg) img Image.open(os.path.join(your_img_dir, img_name)) w, h img.size tree ET.parse(xml_file) xw int(tree.find(size/width).text) xh int(tree.find(size/height).text) if (w, h) ! (xw, xh): print(fMismatch: {xml_file} real{w}x{h} xml{xw}x{xh})有输出说明尺寸不一致要么重新导出数据要么用脚本统一图片尺寸并等比缩放标注框。从那以后我每次拿到一批新数据第一件事就是跑这个脚本形成习惯了。5.2 类别顺序改了导致标签全部错位现象训练正常loss下降但验证集上模型把黄线预测成人行道交通灯预测成机器人。原因这是最阴间的问题。某个版本你为了测试改了转换脚本里的CLASSES顺序但没同步修改yaml里的names训练脚本按新索引丢进去模型学到的映射关系全乱。解决转换脚本跑完后打印一个样例检查。随机取一个txt文件第一列数字对照CLASSES里对应的类别名再打开原图用可视化脚本画框检查人工核对一遍。我在项目里就踩过这个坑当时转换脚本里turn_left和turn_right写反了训练出来模型把左转和右转完全对调部署上车之后导航逻辑跟着乱跑后来就养成了「转换后必须可视化」的强迫症。5.3 交通灯小目标漏检严重现象训练完的效果里大目标像马路、人行道、机器人识别都正常但交通灯的AP不到20。原因小目标的anchor分配本来就不占优加上原始视频抽帧里车辆行进中交通灯在画面里占比很小像素少特征弱。这属于数据本身的难学样本。解决除了换更大分辨率训练更有效的办法是离线裁切增强——把包含交通灯的区域从原图裁出来放大再贴回原图的随机位置生成新样本。这个思路和copy-paste增强是同一个套路。实现上不需要复杂代码用OpenCV把标注框附近的ROI截下来缩放到原来两倍后随机粘贴到同图别的空区域同时算出新的坐标写入txt。5.4 黄线与道路边界贴死导致框混淆现象黄线yellow_line的预测框总是比标注框大一圈把旁边的沥青路面也圈进去了。原因道路机器人的第一视角里黄线通常紧贴道路边界两者在像素上呈长条状且紧邻模型在特征图上分不清黄线和路面纹理的分界线。解决训练时给yellow_line这类长条形目标的loss权重加一点或者回标注阶段检查这类目标框的边界是否贴合。另一个土办法是部署时加一层后处理只在框的长宽比大于4:1时判定为黄线否则归入road。这种经验阈值不算通用解但在固定场景的机器人路线上非常管用。5.5 训练到一半显存溢出现象开始训练几分钟报CUDA out of memory。原因batch太大或者图片尺寸太大。道路机器人数据如果是720pimgsz拉到1280的话4G显存根本扛不住。解决先开batch4 imgsz640跑通验证管线再逐步往上加。如果你机器只有8G显存用YOLOv8n配合imgsz896是一个不错的平衡点。另外建议打开cacheTrue参数把数据预加载到内存能减少数据读取的随机IO但对内存容量有要求。6. 把验证和推理闭环做扎实可视化脚本与部署前的一次强制检查训练收敛之后别急着把人行道和交通灯模型往机器人上塞。先在离线测试集上做一次彻底的可视化推理你才能直观看到模型在真实道路场景里到底认出了什么、漏掉了什么。import cv2 import torch from PIL import Image from ultralytics import YOLO model YOLO(runs/road_robot/exp_voc/weights/best.pt) img cv2.imread(test_frames/output_video_mp4-0668_jpg.rf.158b362131cea9fe195c9fc58cb58625.jpg) results model.predict(img, conf0.35, imgsz640, device0) for box in results[0].boxes: x1, y1, x2, y2 box.xyxy[0].tolist() cls_id int(box.cls[0].item()) conf box.conf[0].item() label f{model.names[cls_id]} {conf:.2f} cv2.rectangle(img, (int(x1), int(y1)), (int(x2), int(y2)), (0, 255, 0), 1) cv2.putText(img, label, (int(x1), int(y1)-5), cv2.FONT_HERSHEY_SIMPLEX, 0.4, (0, 255, 0), 1) cv2.imwrite(inference_result.jpg, img)这个脚本要合入到你的测试闭环里不要只跑一次。每次改完数据集或者调完超参数都拿同一组测试帧跑一遍可视化横向对比前后的识别效果差异。参数上conf0.35是置信度阈值道路机器人场景我建议设低一点到0.2到0.25因为漏检比误检更危险——漏了一个交通灯机器人可能直接闯过去误检了最多刹车减速。imgsz640要和训练尺寸保持一致你的模型在640下训练到最佳部署时强行拉高到1280不会提升精度反而增加延迟。走完推理验证再讲一下我脚踩过的部署翻车经历。当时我们是把best.pt转成TensorRT跑在Jetson Orin上第一次试车就觉得不对劲——模型把路边的红色消防栓全部识别成交通灯。排查了半天发现不是模型的问题是颜色增强的数据处理差异训练时YOLO默认的HSV增强把红色系的饱和度拉高了模型学到了「红色竖直柱状」的粗特征而部署端的图像处理没有做相同方式的增强。从那以后我每次开新项目都会强制过一遍部署前检查训练配置、图像预处理、增强参数逐一比对拿测试帧在目标设备上跑一遍用固定视频流确认推理稳定才开始集成。希望这份VOC格式数据集和这套完整流程能帮你在道路机器人的路面导航识别上少走几段弯路。你拿到的每一个XML文件都是一次真实路面场景的标注沉淀值得把这套数据真正吃透再用到自己的机器人上。本文还有配套的精品资源点击获取