人行道场景检测数据集：10300张YOLO标注图像与智慧城市落地实践

人行道场景检测数据集，听起来没有自动驾驶那么高大上，但真正做过智慧城市项目的人都知道，马路上那一套模型搬到人行道上基本是废的。机动车道检测的目标是车辆、车道线、交通标志，视角固定、光照相对整齐；人行道则完全不同——行人逆光走来、电瓶车从画面边缘窜出、共享单车歪在盲道上、外卖箱和广告牌把目标挡个严严实实。我这次整理的这个10300张YOLO格式人行道场景检测数据集，就是把智慧城市项目里最难啃的一块地皮啃下来的过程记录。

这个数据集不是随手截一堆监控画面那么简单。10300张图像，覆盖白天、夜间、阴雨、逆光等多种天气，包含行人、非机动车、机动车、交通设施、市政设施五大类共15个细分类别，全部用YOLO txt格式标注，直接能喂给YOLOv5/YOLOv8训练。它的定位很明确：给智慧城市的人行道治理场景提供一套可复现的基线数据，不管是做违规占道识别、盲道占用告警，还是做非机动车逆行检测，都可以拿它当作起点。这篇文章适合正在做智慧城市算法项目的工程师、准备用YOLO入门目标检测的学生、以及被“数据集难凑”困扰的开发者——我会把从数据采集、标注规范到训练调参、部署上边缘设备的一整条路线都拆开讲。

1. 为什么人行道场景是智慧城市的第一道考题

1.1 人行道场景的“脏乱差”，恰恰是目标检测的试金石

我做这个数据集的初衷，是在一次智慧城管项目验收现场被现实教育了。当时用通用目标检测模型（COCO预训练权重直接迁移）去检测人行道上的占道经营，结果检测出最多的不是商贩的三轮车，而是路边的树干和垃圾桶——召回率低得没法看。后来复盘才发现，问题不在模型，在场景本身。

人行道场景和道路场景的差异，用三句话就能说清楚：

• 目标尺度极端不均衡。一个画面里既可能有近处整辆电瓶车那么大（几百像素），也可能有人行道尽头一个行人那么小（二十几个像素）。通用模型在COCO上训练的锚框设计，根本覆盖不了这种尺度跨度。
• 遮挡是常态而不是例外。行人会被路牌、灯柱、遮阳棚、树冠遮挡，共享单车经常被另一辆共享单车压住半边。模型要学的是“半截车也是车”。
• 光照和天气没有规律。逆光下的人脸是死黑的，雨天地面反光会把电瓶车和汽车的颜色搅在一起，夜间路灯的光晕经常把目标边缘糊掉。

这些恰恰是智慧城市项目里最真实的数据分布。我管这个叫“脏乱差红利”——正是因为它难，训练出来的模型才真正能在城市治理场景落地，而不是在测试集上自嗨。

1.2 10300张的规模是怎么定下来的

做数据集第一步不是拿起标注工具就干，而是先想清楚“这个项目需要多少数据”。我当时的考虑是这样的：

第一，目标任务复杂度。我们项目要覆盖行人检测、非机动车检测（两轮车/三轮车）、机动车违停、市政设施（垃圾桶/窨井盖/盲道）等，相当于一个多分类目标检测任务。类别越多，每个类别需要的学习样本就越多，尤其像“三轮车”“盲道破损”这种长尾类别，少于几百张压根学不出泛化能力。

第二，训练/验证/测试的结构性需求。我最终把10300张图像按7:2:1划分为训练集7210张、验证集2060张、测试集1030张。很多新手容易犯的错是只在训练集上观察指标，等到部署才发现过拟合；我在划分时就刻意把部分夜间、雨天的样本只放进测试集，保证测试集比训练集“更难”，这样能看到模型的真实下限。

第三，YOLO系列模型对数据量的消化能力。经验上，YOLOv5s在一个全新场景的小目标检测任务上，训练集低于5000张时mAP会明显受限于数据量，超过8000张后收益曲线变平。10300张是一个“不太浪费标注成本，又能喂饱模型”的甜点位。

我之前也对比过公开数据集——Cityscapes有精标注的语义分割图像，但它的城市道路场景多、人行道场景少，分辨率也偏向驾驶视角；BDD100K规模大，但类目偏向自动驾驶。这些公开集都解决不了“人行道上的市政治理”这个细分方向。与其拿五六个数据集拼凑再费劲清洗，不如针对自己的场景采集、标注一个干净的数据集，工程上反而更高效。

2. 数据集构成与类别体系拆解

2.1 类别体系：从“人车物”到“事件级标签”的设计

数据集的类别设计直接决定了模型能回答什么问题。我一开始只打算做“行人 + 电瓶车”二分类，但跟城管业务方聊了之后发现，他们真正要的不是“这里有电瓶车”，而是“电瓶车是不是骑上了人行道”“三轮车是不是占道经营了”——这是事件、是关系，不是单纯的类别。

所以我把类别体系分成了两层。底层由目标检测模型输出物体类别，顶层由业务规则或者后续的多模态AI判断事件。这样数据集的可复用性最高，一套检测模型能同时支撑好几个业务。

最终定的15个类别如下：

有两点需要特别说明。一个是rider单独的类别，这是我从实际项目里总结出来的经验：如果只检测person或者只检测motorcycle，行人推着电瓶车走的时候分不清是骑车还是推行；分两类的做法在后续做“非机动车逆行”“闯红灯”判断时非常方便，可以通过rider和motorcycle的检测框重叠关系直接推断骑行状态。

另一个是obstacle类，覆盖了各种不好细分但又真实存在的占道物，比如施工铁皮、石球墩、广告牌。这类目标对城市管理来说反而是重点，不能因为“不好分类”就丢掉。在标注规范里，我对obstacle的约定是：凡是体积大于一个成年人、位置明显占用人行通道、且不属于其他14类的人造物体，全部归入obstacle。宁可让这个类别“杂”，也不能漏掉它。

2.2 场景分布与采集策略

数据不是越多越好，而是越“覆盖”越好。我给10300张图像设计了四个采集维度，每个维度都有明确的工程出发点：

• 时间分布：白天60%、夜间25%、晨昏15%。夜间样本里面特别要求有路灯直射和完全无路灯两种情况，否则模型在暗光下会疯狂漏检。
• 天气分布：晴天55%、阴天25%、雨天15%、雪天/雾天5%。雨雪天样本全靠运气积累，所以平时要留意归档，不能等做项目时再去补。
• 地域分布：商业街35%、居住区30%、学校周边20%、城市主干道周边15%。商业街对应占道经营场景，居住区和学校周边对应违规停车和非机动车乱停。
• 视角分布：高位枪机40%、低位枪机35%、手机平视25%。这一点很多经验不足的团队会忽略——同一台设备装的高度不同，目标的长宽比和透视关系完全不同，只用一种视角训练出来的模型换个安装高度就失灵。

采集来源上，我们把城市已有的摄像头录像抽帧、团队自行用手机/运动相机采集、以及部分有授权的开放数据混合起来。抽帧时有一个重要技巧：同一段视频不要连续抽帧，要隔几十帧抽一帧，否则相邻帧几乎一模一样，相当于变相降低了数据多样性。我大概从原始视频里抽了大约4万帧，经过去重和清晰度筛选之后才剩下最后的有效图像。

标注规范这块也踩过不少坑。比如“自行车和电瓶车同时出现且距离很近时，遮挡部分是否标注”——我们的标准是：目标可见面积超过30%就必须标框，低于30%就放弃。框的质量则是统一要求检测框贴着目标轮廓，宁可框得紧一些也不要大面积留白，项目的统一做法是：框的四个边离目标可见最外缘不超过框宽的2%。这样标准化之后，多人协作标注的框质量才能保证一致性。

3. YOLO选型与训练配置实操

3.1 标注格式转换与目录组织

数据清洗和格式转换是整个流程里最琐碎但又最影响训练效果的一环。我用的标注工具是X-AnyLabeling，它是YOLO系列生态里比较顺手的工具，支持自动预标注、手动精修，导出格式直接就是YOLO txt格式。如果你用的是LabelImg，导出的是XML（Pascal VOC格式），需要再做一次转换，这一步可以用Python脚本批量处理，原理很简单——把XML里的坐标从绝对像素转换为归一化的中心点坐标 + 宽高：

import xml.etree.ElementTree as ET def voc_to_yolo(xml_file, class_names, img_w, img_h): tree = ET.parse(xml_file) root = tree.getroot() boxes = [] 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 = float(bndbox.find("xmin").text) ymin = float(bndbox.find("ymin").text) xmax = float(bndbox.find("xmax").text) ymax = float(bndbox.find("ymax").text) # 转换为YOLO格式：归一化的中心坐标 x_center = ((xmin + xmax) / 2) / img_w y_center = ((ymin + ymax) / 2) / img_h w = (xmax - xmin) / img_w h = (ymax - ymin) / img_h boxes.append(f"{cls_id} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}") return boxes

转换脚本虽然简单，但有两个隐藏的坑：一是分辨率一定要从图片文件读取，不能从XML里读，否则某些图片旋转或裁剪后分辨率对不上；二是class_names的顺序必须和训练时的data yaml保持一致，否则类别张冠李戴，模型性能再高也白搭。

目录结构我统一采用YOLO生态的标准布局：

dataset/ ├── images/ │ ├── train/ # 7210张 │ ├── val/ # 2060张 │ └── test/ # 1030张 ├── labels/ │ ├── train/ # 对应的txt标注 │ ├── val/ │ └── test/ └── data.yaml # 类别定义与路径配置

data.yaml里的内容也很关键，nc必须和names里的数量一致，名字顺序必须严格匹配。我项目里用的是：

path: dataset train: images/train val: images/val test: images/test nc: 15 names: 0: person 1: bicycle 2: motorcycle 3: tricycle 4: car 5: truck 6: bus 7: rider 8: traffic_light 9: traffic_sign 10: pole 11: trash_can 12: manhole_cover 13: hydrant 14: obstacle

3.2 模型选型、超参数与训练流程

模型选型上，我的建议是先用YOLOv5s或YOLOv8s跑一个基线，跑通整条链路后再考虑要不要换成m或l。不要一上来就上最大的模型，因为你根本不知道问题是出在模型容量还是数据质量上。我实际比较过YOLOv5s、YOLOv8s、YOLOv8m在这个数据集上的表现，最终部署选了YOLOv8s的ONNX版本，原因很直接：在Jetson Orin这类边缘设备上，v8s的推理延迟只有m版本的一半不到，而mAP差距大约只有1.2个百分点。

超参数方面，我的初始配置是这样的：

训练命令我用的是YOLOv5的主流写法，YOLOv8命令结构类似：

python train.py --data data.yaml \ --weights yolov5s.pt \ --img 960 \ --batch 16 \ --epochs 150 \ --device 0

我在PyCharm里跑这套训练已经跑了很多遍，给入门者的建议是：不要用默认Python解释器直接跑train.py而不配置工作目录，把Run Configuration的Working directory设置为项目根目录，同时确认data.yaml里的路径是相对路径，否则会出现“找不到数据集”这种新手第一坑。

mosaic增强这里值得多说一句。YOLO系列默认把mosaic开满，它在前期能极大提升模型对小目标的鲁棒性，因为mosaic把四张图拼接在一起，相当于把每个目标“缩小”了，模型被迫去学小尺度特征。但训练后期还开着mosaic会有一个问题：拼接图里的目标局部分布和真实场景差异较大，导致模型在真实分布上表现不稳。所以后期关闭mosaic已经成为训练的关键技巧（YOLOv5自带close_mosaic参数，YOLOv8也有类似机制），我们项目里在最后10轮关闭后，验证集mAP大概能再涨1到2个点。

4. 训练过程的关键参数与损失函数调优

4.1 从损失函数的角度理解YOLO在学什么

YOLO的目标检测损失是一个多任务加权组合，理解它的构成才能知道训练中每个指标的含义。以YOLOv5为例，总损失是三部分的和：

L = λ_box · L_box + λ_cls · L_cls + λ_obj · L_obj

• L_box是边框回归损失（这里用的是CIoU Loss），它同时考虑预测框和真实框的重叠率、中心点距离和长宽比三个维度。当mAP的AP50高但AP50:95明显偏低时，往往是边框回归还不够精细，可以考虑增大λ_box或者提高输入分辨率。
• L_cls是分类损失，这里用的是BCEWithLogitsLoss，逐类别二分类。类别不均衡时，某个稀有类别的loss基本被高频类别淹没，这时候就要靠数据采样或者损失重新加权。
• L_obj是置信度损失，它负责判断“这个位置网格到底有没有目标”。这个损失极其重要——很多新手只看mAP，不看obj_loss，结果模型预测框很多但都是低置信度，一调低阈值就出一堆误检，问题多半就出在obj_loss没有收敛到足够低。

到了YOLOv8，损失函数设计又变了。v8抛弃了基于锚框的检测头，改用anchor-free结构，分类损失换成了BCE，边框回归换成了DFL（Distribution Focal Loss）+ CIoU的组合。DFL的核心思想是把框的四个边每个位置建模成一个概率分布，而不是直接回归一个确定的坐标值。这样做的好处是模型对模糊边界（恰好被遮挡一半的目标、运动模糊的目标）能给出更平滑的预测；代价是训练时对分布尾部更敏感，训练迭代数一般要比v5多20%左右才能充分收敛。

我在调参时遇到过几次典型的损失异常。比如训练到50轮左右，box_loss还在降，但obj_loss突然抬头，验证集mAP也跟着往下走——最后查出来是标注数据里有大量超过图像边界的大目标，导致回归目标width/height大于1，置信度的监督信号被搞坏了。那个教训让我后面无论用哪个数据集，都会先做一轮标注合法性校验：检查txt里w、h是否在0到1之间、坐标是否为负、类别索引是否越界。

4.2 从YOLOv5到YOLOv8的迁移经验和对比

很多朋友问我同一个问题：同一个数据集，该用v5还是v8？我的综合感受是：v8的anchor-free结构让它在小目标、密集场景上天然有优势，训练收敛后的AP50:95通常会比v5s高1到2个点；但v5的生态成熟度更高，第三方部署教程多，且对显存更友好。如果团队刚上手，用v5跑通流程再迁移v8，是最稳妥的路线。

我在这个数据集上还专门做过一次同数据集对比实验，用同一个验证集评测：

我选YOLOv8s作为最终方案，就是因为它和v8m的差距远小于推理耗时的差距。边缘设备上每帧多20毫秒，意味着能跑的路数少一半，这对智慧城市项目是致命的。

还有一点是关于anchors的。如果还在用YOLOv5，建议训练前用数据集重新聚类锚框，不要直接沿用COCO的锚框。COCO的锚框偏大（适合检测整辆车、整只狗），人行道上的行人和电瓶车平均占图比例小，锚框设置不合理会直接限制检测器对小目标的上限。YOLOv5在train.py里带了一个自动计算锚框的功能，置True后会自动跑k-means聚类，我建议保持打开；YOLOv8是anchor-free，没有这个问题，这也是我最终偏向v8的原因之一。

5. 部署侧：从验证集到智慧城市落地

5.1 导出ONNX和边缘设备部署实录

数据集和模型最终要落到盒子上跑。我们这版部署环境是Jetson AGX Orin，用TensorRT做推理加速。YOLOv8导出ONNX的命令非常成熟：

yolo export model=runs/train/exp/weights/best.pt format=onnx imgsz=960 opset=12 simplify=True

导出ONNX之后，在AGX Orin上搭建运行环境时我踩过一个大坑：如果直接用pip安装的onnxruntime跑fp32模型，Orin的GPU根本跑不满；你需要用JetPack自带的TensorRT，把ONNX转成engine文件，再加载。一个可参考的执行思路是：直接用YOLOv8的export format=engine转到TensorRT engine，device指定为0。第一次build engine会非常慢（10分钟级别），但之后加载就是秒级了。

D435i深度相机和YOLO的搭配，我也测试过。因为我们要做“人行道占用率”分析，需要知道非机动车距离道路边缘的物理距离，单纯用2D框算不准。做法是把YOLO输出的目标中心点像素坐标映射到D435i的深度图对应位置，读取该像素的深度值，再联合相机的内外参数换算成实际距离。注意深度图上的目标边缘会有空洞和飞点，取深度值时要取框内部多个像素的中位数，而不是单点值。

5.2 检测和多模态AI分析的联动思路

智慧城市项目里，YOLO通常只是感知前端，后面的业务判定才是重头。我这边做了一个“事件判定管线”：YOLO负责输出所有目标的类别和位置，然后由一个轻量的多模态AI（用图像大模型做VQA问答）来回答业务问题，比如“人行道上是否存在三轮车占道经营”“盲道是否被车辆占用”“消防通道是否有堆积物”。这样做有一个巨大的好处：事件判定的逻辑用自然语言写，业务方改需求时算法工程师不用重新训练模型，只改提示词和规则就行。

具体流程是这样的：

1. YOLO先做全图检测，生成目标列表和大致区域；
2. 对检测到的可疑区域（如三轮车检测框重叠堆叠、垃圾桶附近有大批杂物）做局部裁剪；
3. 把裁剪后的图像送到多模态AI，同时传入一个结构化的Prompt：“结合这个目标检测列表，判断该区域是否存在占道堆放或违规设摊行为，回答yes/no并给出置信度”；
4. 把结论写入城市治理的事件工单系统。

这一套联动方案能覆盖“检测模型没有训练过的事件类型”，这是纯检测模型做不到的。比如说，“几个石墩围起来占路”这个事件，YOLO只能检测到obstacle，但无法判断它们是否有占路意图；多模态AI加上上下文，就能给出更高层的判断。不过要注意，多模态AI的推理延迟一般比较长，生产环境要做异步队列或者只对YOLO触发的高危区域调用，不能全图逐帧硬跑。

6. 常见问题与排查技巧实录

6.1 数据集层面的坑，80%都不该花时间去解决模型

先说一下踩过最多的数据集问题，以及对应的解决办法：

• 类别不均衡。person和car数量占绝对大头，tricycle和manhole_cover样本不足800张。直接训练会导致稀有类别AP很低。我的做法是给稀有类别做简单的复制增强（复制样本并随机调整位置粘贴，注意别把复制目标叠到其他人身上），或者靠mosaic增强本身的多图拼接特性，稀有类别在拼接图里出现的概率会自然提高。
• 小目标漏检。人行道远处行人经常只有十几个像素，960分辨率下训练也还是漏。后来我加了两种增强：一个是在训练时随机裁剪放大局部区域（相当于把远处行人“放大”了）；另一个是把测试集里小目标占比高的图片单独拉出来做补充评估，而不是只在整体mAP上自我感动。
• 标签过界。标注时如果目标被图像边缘截断，标注框会超出图像边界，训练时loss会出现剧烈波动。我在预处理脚本里统一把这些框先裁剪到图像范围内，宽高不足原框20%的直接丢弃。
• 画面模糊。夜间视频抽帧有大量动态模糊，人眼能认出来但模型学不进去。我的筛图标准是：人工过一遍，把模糊帧、过度曝光帧、重复帧全部剔除。这个动作看似费人工，实际上能省掉后面调模型的一周时间。

6.2 训练和部署阶段的一些实测心得

训练阶段，我最想提醒的一点是：验证集必须从训练“流程”里独立出去。我们一开始图省事，用训练集抽样当验证集，结果模型在验证集上mAP高达92%，一上真实监控就崩到48%。后来严格把夜间、雨天、特定视角的数据只留在测试集，才真正反映了模型在真实环境下的水平。

部署阶段的坑主要在NMS和置信度阈值。YOLO默认conf_thres=0.25、iou_thres=0.45，但人行道场景遮挡多，目标之间大量重叠，默认IoU阈值会导致两个紧挨的行人被合并成一个框。我调的时候把iou_thres降到0.4，conf_thres根据场景需求分别设置：抓违规停车用0.5（宁可漏检不能误报），安全监控用0.3（宁可误报不能漏检）。阈值没有绝对正确，必须根据后端处理逻辑和业务容忍度来定，这点建议在项目早期就跟业务方对齐。

另外，关于D435i深度相机加YOLO的测距组合，补充一个细节：深度图对齐到RGB图时，如果用的是rs2.align_to，一定要先确保YOLO推理的图像分辨率跟深度图分辨率保持一致，最好统一到640或960后再对齐，否则像素坐标偏移几个像素，在5米外的目标上可能产生几十厘米的深度误差。

7. 最后说几句实在话

这个数据集做完，我自己最大的感受是：目标检测项目的天花板，根本不是模型结构，而是数据集质量。10300张图听上去不少，但真正洗净之后能稳定贡献梯度的有效样本可能只有七八成。训练一个YOLOv8s模型只需要几个小时，但数据采集、清洗、标注、校验花掉了几倍的时间。如果你正准备做人行道场景或者类似的智慧城市项目，我的建议是先从1000张图的小样本跑通全流程，把标注规范、数据校验、训练评估基线定下来，再扩量到全量数据，这样能少走很多弯路。这个数据集后续我还会继续补一些新的恶劣天气样本和对应的多模态标注，争取把“人行道事件检测”这个方向做成一个可以开箱即用的基线。