简介这是一份面向道路机器人视觉识别与自动驾驶导航场景的YOLOv11标注数据集资源适合目标检测入门学习者、机器人开发者以及交通标志识别算法研究人员使用。资源涵盖407张真实道路场景图像这些图像多取自路面视频抽帧包含交通灯、马路、左右转标识、黄线、人行道以及路面机器人等常见导航标志每张图片均配有对应的txt格式YOLO标注框文件可直接用于模型训练、验证与微调。同时附带yaml配置便于快速搭建数据集结构和设置训练参数。压缩包共815个文件整体仅5.52MB轻量易下载适合在本地快速跑通YOLOv11训练流程。文件按图像与标注一一对应组织目录结构清晰已有746人学习/下载可作为路面导航标志检测实践的实用起点也可作为课程设计、算法对比实验的现成数据集便于深入理解YOLOv11的训练配置与标注格式。1. 路面导航标志识别为什么这份YOLOv11标注数据能直接开训做道路机器人的导航识别时最容易被忽视的往往是路面视觉标志交通灯在哪个相位、黄线能不能压、左转箭头什么时候进入视野。平时大家讨论导航都在讲路径规划算法但真到园区实测机器人被一段黄线或一个斑马线拦下来是常有的事。这个项目把交通灯、马路、左右转箭头、黄线、人行道和机器人本体六类目标从视频帧里抽出来用Roboflow标成YOLO格式标记目标就是YOLOv11。它解决的是机器人「看不懂地面」的问题拿来即训即测。适合正在做视觉导航、想跳过标注阶段直接验证YOLOv11效果的工程师和学生。2. 数据集结构拆解Roboflow导出文件的读法与容易漏掉的分布问题训练开始前先花半小时把解压后的文件夹摸清楚。这个数据集的文件名、labels目录、data.yaml三样东西决定了你后面训练脚本怎么写也决定了验证指标有没有参考价值。很多人上来就改data.yaml里几个路径然后直接train结果指标虚高、实拍拉胯root cause往往就在这一层。2.1 从视频帧到jpg.rf.命名到底告诉了你什么看到output_video_mp4-0668_jpg.rf.158b362131cea9fe195c9fc58cb58625.jpg这样的文件名第一反应不是「好长」而是拆段读output_video_mp4源文件是一个mp4视频说明这些图片是从实拍视频里连续抽帧得到的不是散图拼的0668帧序号后面的0671、0669、0661说明相邻帧之间只隔几帧画面内容高度相似jpg抽帧后统一转成了jpg压缩格式对训练影响不大但要注意质量别太低.rf.Roboflow处理过的标记rf后面的长串md5是图片内容的哈希用于去重和版本追踪。这个命名的实际价值在于它提醒你这份数据存在明显的时间相关性。如果解压后直接用Roboflow默认的random split极大概率会把0648、0649这种相邻帧一个分到train、一个分到valid模型在验证集上的mAP会显得虚高真到实拍视频上却大跌眼镜。所以我拿到任何带帧号的数据集第一件事就是把帧号区间按8:2切成两段前段训练后段验证宁可少几张训练图也要保证验证集是真正没见过的画面。2.2 labels目录与data.yaml先看懂格式再动手改路径解压后典型的目录结构是这样dataset/ ├── train/ │ ├── images/ # jpg 原图 │ └── labels/ # 同名 txt 标注 ├── valid/ │ ├── images/ │ └── labels/ ├── test/ │ └── images/ └── data.yamlRoboflow导出YOLO格式时每个txt和原图同名每行代表一个目标框格式是类别ID x_center y_center width height坐标全部做了归一化除以图片宽高范围在0到1之间。和VOC的xml、COCO的json比YOLO的txt是最省事的读起来直接就是训练器能吃的输入。data.yaml里的names字段定义了类别顺序这个顺序就是txt里类别ID的映射来源path: ./dataset train: train/images val: valid/images test: test/images names: 0: traffic_light 1: road 2: left_turn 3: right_turn 4: yellow_line 5: crosswalk 6: robot注意这份yaml是Roboflow导出的里面path字段经常写的是导出那台机器的绝对路径比如C:/Users/xxx/Desktop/rf-xx。换机器直接训练会报「数据集路径不存在」。我一般会把它改成相对路径也就是上面这样以data.yaml所在目录为基准。2.3 类别分布统计先数一遍框再定训练策略不统计直接开训是对数据集最大的不尊重。六类目标里黄线、马路这种大目标可能占了大半标注框而人行道、远处的交通灯可能只有零头。类别不平衡会让YOLOv11把弱势类别直接学成背景。这个脚本不需要任何第三方库Python标准库就能跑from pathlib import Path import collections label_dir Path(dataset/train/labels) counts collections.Counter() box_total 0 for label_file in label_dir.glob(*.txt): lines [l.strip() for l in label_file.read_text().splitlines() if l.strip()] box_total len(lines) for line in lines: cls int(line.split()[0]) counts[cls] 1 print(f标注框总数: {box_total}) print(各类别框数:, dict(counts))逻辑说明脚本遍历train/labels下所有txt逐行读取用空格拆分取第一个字段作为类别IDCounter统计每个类的框数。目的是在训练前就发现两类问题一是某些类别框数过少后面要优先做针对性增强二是标注本身有错比如某个类只有1个框通常是漏标或标错类。参数说明label_dir改成你自己的labels路径如果你的yaml里类别顺序和上面不同记得对照数据集的data.yaml确认ID编号不要想当然。统计完之后如果发现crosswalk只有几十个框我一般会先给它做随机旋转、亮度扰动增强而不是期望模型自己学出来。这章整体下来摸清文件名、标签格式、类别分布后面训练才不是盲调。3. YOLOv11训练实操环境配置、参数含义与一段能跑的训命令YOLOv11已经内置在ultralytics包里用起来和之前的v8几乎一致。但环境装不对、参数看不懂照样会在第一个epoch就卡住。这章把从建环境到看训练曲线这一段路完整走一遍每一步都解释参数为什么这么设。3.1 环境安装ultralytics版本与torch的CUDA对应关系常见做法是先建一个干净的conda环境Python版本选3.10或3.11然后装pytorch和ultralytics。我这里以CUDA 11.8为例conda create -n yolo11 python3.10 -y conda activate yolo11 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics逻辑说明torch和torchvision必须从pytorch官方源装装成CPU版会导致后面训练慢一个数量级。ultralytics包本身不挑版本但建议装完后执行yolo version确认一下代码能import成功才算环境OK。CUDA版本和显卡驱动有关先查一下nvidia-smi里的最高驱动版本再去选cu118还是cu121。参数说明如果你的机器没有NVIDIA显卡或者驱动版本太低把--index-url那行去掉直接pip install torch torchvision会装CPU版训练小数据集勉强能跑但imgsz640、batch16会非常吃力。我一般会建议先拿CPU版跑通流程再换GPU。注意先查nvidia-smi再选CUDA版本装错只能删了重来没有后悔药。3.2 训练命令与核心参数不是越大越好数据集和yaml都准备好了就可以开训。我这里用的是yolo11ss是small对这个六类导航标志任务已经够用yolo detect train \ datadataset/data.yaml \ modelyolo11s.pt \ epochs100 \ imgsz640 \ batch16 \ device0 \ patience20 \ projectruns/road_nav \ nametrain_v1逻辑说明yolo detect train是ultralytics CLI的统一入口。modelyolo11s.pt会自动下载官方在COCO上预训练的权重作为初始值比随机初始化收敛快得多。patience20表示验证集mAP连续20个epoch不涨就自动停防止熬夜等一个没必要跑完的100轮。参数说明imgsz默认640交通灯箭头这种小目标如果训练时总漏检可以提到960代价是显存和训练时间都涨约一倍。batch16在8G显存左右的卡上比较稳妥12G以上可以试32。device0是单卡多卡再写device0,1。project和name只是组织输出目录用的建议每次实验换name别全堆在默认runs/detect/train里。3.3 训练过程的观测results.csv是实时的体检报告训练过程中ultralytics会实时更新runs/road_nav/train_v1/results.csv每一行是一个epoch的完整指标。这是判断训练是否健康的第一手资料别只看终端上那个进度条。常见指标含义指标含义健康范围train/box_loss框回归损失持续下降train/cls_loss分类损失持续下降metrics/precision(B)所有类别的平均精度0.7以上metrics/recall(B)所有类别的平均召回0.7以上metrics/mAP50(B)IoU阈值0.5下的平均AP越接近1越好metrics/mAP50-95(B)严格IoU下的平均AP比mAP50低0.1~0.3正常训练结束后真正要用的是best.pt而不是last.pt。best是按照验证集mAP挑出来的那个权重装在runs/road_nav/train_v1/weights/best.pt。需要特别注意的是如果train loss一路降到0.01而val loss还在0.2附近徘徊说明过拟合了常见原因是数据集太小、图片太少或同类帧太多而不是模型太大。反过来train loss和val loss都不降先回去检查data.yaml的names顺序和txt里的类别ID对不对得上这个错是最隐性的。很多人觉得调参是玄学其实大部分翻车都出在数据没对齐上先查数据再看参数。4. 推理与结果保存把检测框接进机器人导航决策训练完不是终点导航识别最终要落到实拍视频或摄像头实时帧上。这章讲推理代码怎么写、结果怎么保存、以及检测结果怎么转成机器人能用的导航信息。这个项目的数据来自视频帧所以推理环节也直接用视频演示最贴近实际。4.1 模型加载与推理一行predict也能干很多事ultralytics的predict接口可以吃视频、图片、目录甚至摄像头。这里先处理一段新视频from ultralytics import YOLO model YOLO(runs/road_nav/train_v1/weights/best.pt) results model.predict( sourcenew_route.mp4, conf0.25, imgsz640, saveTrue, save_txtTrue, projectruns/infer, namenav_test )逻辑说明model是加载训练好的best.pt的推理器。predict把视频逐帧推理。saveTrue会在runs/infer/nav_test下生成带标注框的输出视频save_txtTrue会把每一帧的检测结果按YOLO txt格式落盘文件名和帧对应方便后续脚本单独读。参数说明conf0.25是置信度阈值想少漏检就调到0.15代价是误检变多想少误检就调到0.4代价是小目标更容易丢。imgsz要跟训练时的值一致否则模型输入分布会变推理精度可能掉。source如果不给默认走摄像头这在机器人上做实机测试时常用。4.2 结构化输出把检测框变成导航决策能读的数据save_txt存的txt适合人眼排查但导航程序要的是结构化结果。用Python接口直接拿框坐标更干净from ultralytics import YOLO model YOLO(runs/road_nav/train_v1/weights/best.pt) frame_path frame_0342.jpg result model.predict(frame_path, conf0.3, imgsz640)[0] nav_info {left_turn: [], right_turn: [], yellow_line: [], crosswalk: [], robot: []} for box in result.boxes: cls int(box.cls.item()) name result.names[cls] x1, y1, x2, y2 [float(v) for v in box.xyxy[0]] center_x (x1 x2) / 2 center_y (y1 y2) / 2 area (x2 - x1) * (y2 - y1) nav_info[name].append({ bbox: [x1, y1, x2, y2], center_x: center_x, center_y: center_y, area: area, }) print(nav_info)逻辑说明遍历result.boxes每个box包含类别ID、置信度和像素坐标。xyxy是像素坐标center_x和center_y通过边界框均值算出area用于判断目标远近面积越大说明离机器人越近。参数说明result.names是data.yaml里的类别名映射训练时定义的0到6对应到这里。注意如果names顺序和txt不一致这一步的name会错位训练前核对names才是治本。4.3 一个够用的导航决策小逻辑拿到结构化框之后导航程序其实不需要理解「这是黄线」只需要知道「黄线在画面什么位置、占多大面积」。一个简单但有效的判断方式是检测结果决策含义yellow_line 中心点在下1/3、面积大于阈值前方有禁压黄线减速或停车crosswalk 出现且面积增大接近人行道让行或停车left_turn 出现在画面左半侧可以左转robot 出现在行进方向且距离近避障绕行具体落地时我一般会设两个阈值一个是conf一个是面积下限。面积太小的框可以丢弃避免远处芝麻大的误检干扰导航。下面这段是把上一步的nav_info转成决策字符串的示例def decide(nav_info, frame_w640, frame_h640): for marker in nav_info[yellow_line]: if marker[center_y] frame_h * 0.66 and marker[area] 5000: return STOP: yellow line ahead for marker in nav_info[crosswalk]: if marker[area] 8000: return SLOW: crosswalk approaching for marker in nav_info[left_turn]: if marker[center_x] frame_w * 0.5: return TURN LEFT for marker in nav_info[robot]: if marker[area] 10000: return AVOID: robot nearby return FORWARD逻辑说明按优先级从高到低判断黄线禁压 人行道让行 左转指示 机器人避障。frame_h*0.66表示画面下方三分之一区域只有目标出现在这里才有决策意义。area阈值根据实际画面分辨率调分辨率越高阈值越大。参数说明这个逻辑只适合作为原型真实机器人上还要结合激光雷达和速度控制。但作为演示用来验证「模型的输出能不能被下游消费」足够了。5. 训练与部署避坑五个最常见的翻车点与排查记录这个项目我前前后后跑了好几遍踩的坑比训练本身还精彩。按现象、原因、解决的格式整理出五条基本都是YOLOv11加载类数据集时的高频问题新手老手都可能碰上。5.1 验证集mAP虚高实拍视频却疯狂漏检现象训练时Valid mAP达到0.95模型在测试视频上表现却惨不忍睹交通灯频繁丢黄线断断续续。原因这份数据来自连续视频帧直接random split后相邻帧被分到train和valid验证集和训练集画面几乎一样模型是「背题」而不是「做题」。解决按帧号区间切分而不是随机切。我一般会写一个脚本检测文件名里的帧号按8:2切分成train和valid。这样验证集里的画面在训练时完全没见过指标才可信。5.2 黄线和马路互相误检现象模型把大片路面报成yellow_line把黄线报成road两者混淆严重。原因标注协议不统一。黄线画在马路区域内两个类别天然重叠模型学到的特征互相干扰。Roboflow里如果同一个目标被标成两个类模型就会在这两个类之间摇摆。解决统一标注边界一个目标只属于一个类。黄线只标线体本身不标它底下的路面整块路面才标road。如果你用的数据里已经有这种错标唯一的后悔药就是重新过一遍labels把重叠框按优先级清理。5.3 远处的交通灯和左转箭头完全检测不到现象近距离目标检测正常画面里超过20米的交通灯直接消失左转小箭头也频繁漏检。原因小目标在640分辨率下只有几个像素下采样几层之后特征就没了这是YOLO类模型的通病不是权重问题。解决训练时把imgsz从640提到960或1280推理时保持同样的尺寸。如果显存放不下就换用切片推理把画面切成320的块分别检测再合并对远处小目标非常有效具体做法在第6章。5.4 训练到一半OOM进程被杀现象epoch跑到30左右终端报OutOfMemoryError或者直接kill。原因batch16加imgsz640在8G显存上本来就紧张数据加载worker一多更容易爆。解决batch对半砍到8workers设为4还不行就用yolo11nnano版本显存占用低一大截先跑通再说。OOM不是模型的问题是预算和硬件不匹配别硬扛。5.5 Roboflow导出的data.yaml路径失效现象训练一启动就报Dataset not found或图片读不到但文件夹明明在。原因Roboflow导出时把path写成了导出机器上的绝对路径换机器后路径失效。这个问题在Windows导出、Linux训练的场景下尤其高频。解决训练前强制把data.yaml的path改成相对路径以yaml所在目录为基准。我每次都会顺手打开data.yaml检查一遍path字段已经成了肌肉记忆。6. 进阶小目标优化与Jetson部署的真实边界小目标问题在这个导航场景里很典型交通灯在画面里可能只占20个像素imgsz640时下采样几轮就没了。切片推理SAHI是我用得最多的补救手段它把大图切成小切片分别检测再合并交通灯这类小目标检出率能提升一个档次from sahi.model import Yolov8DetectionModel from sahi.predict import get_sliced_prediction model Yolov8DetectionModel( model_pathruns/road_nav/train_v1/weights/best.pt, confidence_threshold0.3, ) result get_sliced_prediction( frame_0342.jpg, model, slice_height320, slice_width320, overlap_height_ratio0.2, overlap_width_ratio0.2, )逻辑说明SAHI把原图裁剪成320x320的切片相邻切片有20%重叠保证目标不会正好卡在边界被截断各切片独立推理后再合并NMS。代价是推理时间几乎按切片数成倍增加适合对离线视频做分析实时导航时要谨慎。参数说明slice_height和slice_width越小小目标效果越好但耗时越久。overlap ratio取0.2即可太小会漏目标太大NMS会把同一目标重复压掉。部署边界是我最想提醒的一点。很多人想把YOLOv11直接推到Jetson Nano上跑但Nano上TensorRT导出engine后FP16精度下黄线和阴影的对比度差异会被压缩误检率比PC上高。我踩过这个坑之后在Nano上坚持用FP32推理帧率从15掉到9但至少不会把树影当黄线。导航识别这种事误检比漏检更危险。实时性上Jetson Nano跑yolo11s只能做到10帧上下切片推理根本跑不动。我一般会先降级到yolo11n再把输入分辨率压到480才能拼到接近20帧。如果还不行就得考虑换Orin或把检测频率降到5Hz中间帧用运动模型补。从那以后我每次拿到导航数据集第一件事不是写训练脚本而是先跑一遍帧号区间统计和类别分布部署到嵌入式设备前也会强制用小目标切片推理验证一轮才算完。这套流程帮我把很多翻车提前挡在了训练阶段希望帮到你。本文还有配套的精品资源点击获取