智慧城市人行道检测实战：自建YOLO数据集与边缘部署全流程-北京尧图网络

四月份接了个智慧城市项目要在几十个路口和重点路段部署人行道场景检测系统。我一开始的思路很直接拿现成的YOLO模型跑一遍看效果再说。结果一到真实场景就露馅了——行人和电动自行车框得歪歪扭扭井盖、路锥、路面裂缝这类市政设施目标基本认不出来树荫底下稍微遮挡一点就漏检。后来我下了个决心不再指望通用模型花了三周多时间自己整理了一套人行道场景检测数据集一共10300张图全部转成YOLO格式从采集、清洗、标注到训练、部署完整走了一遍。这篇不卖课也不卖数据纯粹是把中间踩过的坑和实际能复用的路径记录下来给同样在做智慧城市、道路巡检、违停识别方向的同行一个参考。通篇围绕为什么必须自建场景数据集数据怎么攒怎么清洗标注规范怎么定用什么版本的YOLO训练部署到边缘设备会遇到什么这几个问题来写提到的参数、策略都是我实测过的虽然不是唯一解但至少是能落地的解。1. 通用数据集在人行道场景下的失灵点很多人会问COCO、BDD100K这些公开数据集规模不是挺大的吗直接用它们训练不就行了我一开始也这么想但真正把人行道场景的需求拆开之后发现通用数据集和这个场景之间有明显的错位而且不是靠调参能弥合的。1.1 类别错位通用模型认不全人行道的目标COCO有80类看着不少但落到人行道场景里真正用得上的类别就那几样person、bicycle、car、traffic light、stop sign剩下的基本都在数星星。问题在于人行道场景里数量占绝对大头的是电动自行车、外卖车、共享单车和三轮车这些在COCO里根本没有对应类别。BDD100K的类别相对接近自动驾驶场景有rider这类标签但同样缺井盖、路锥、垃圾桶、施工围挡这些市政设施细类。做智慧城市项目的人应该都知道业务需求通常是两条线并行的一条是交管视角要看行人和非机动车有没有违规、有没有汽车闯上人行道另一条是市政视角要看井盖有没有破损、路面有没有裂缝、有没有占道堆物。想用一套通用模型同时满足这两条线只能拆成好几个模型去处理数据之间还存在重叠和冲突。自己定义一个贴合业务的标签体系才是最省事的做法。1.2 视角差异立杆俯拍与行车视角的错配这是我在实际测试里感触最深的一个点。公开数据集里的大部分图像来自行车记录仪、车内摄像头或者手持设备拍摄视角基本是平视或者轻微俯视目标在画面里比较完整、比例正常。但智慧城市项目里摄像头一般装在6到8米的立杆上往下倾斜30到45度俯拍行人、车辆在画面里是头顶小、肩膀宽的形态比例很怪。同一个行人在COCO训练出来的模型认知里可能是100x200像素左右的直立框到了立杆俯拍画面里往往缩成40x60像素而且还经常被街边大树、广告牌、公交站台遮挡。直接把通用模型拿来推理漏检率一下子飙上去处理起来非常难受。这个视角差异是客观存在的不是简单的数据增强能覆盖的问题——本质上模型需要在俯视广角高密度遮挡的数据分布里重新学习目标特征。1.3 场景复杂度树荫、遮挡与高密度行人的干扰人行道是我做过的最脏的视觉场景之一。背景里什么都有树荫光斑、广告牌、公交站台、施工围挡、外卖柜、共享单车停放区再加上行人和车辆互相遮挡一个目标经常只露出半边甚至三分之一。通用数据集里的图像通常背景相对干净就算有遮挡目标之间也不会像人行道早晚高峰那样重叠到离谱。这种高密度遮挡场景下通用模型的precision和recall都不太稳定要么把消防栓当成人要么把树影里的电瓶车漏掉。直接部署到算力有限的边缘盒子上误检率根本压不住因为后处理再怎么调阈值也是顾此失彼。说到底场景和数据的匹配程度比模型结构本身更决定上限。注意不是说公开数据集没有用它们非常适合做预训练基座。我强烈建议的思路是——先在公开数据集上训一版通用模型用它做预标注和负样本挖掘再用自建的人行道数据去微调。这样效率比完全从零开始快得多。2. 10300张图的来源构成公开筛图、自采与清洗数据集的规模不是拍脑袋定的。项目要求覆盖至少三个目标场景且每个大类别目标数量不能太少否则模型学不深。我当时初步攒了大概12500张原始图经过清洗、去重、筛劣之后剩下10300张这个量级对于人行道场景来说是足够启动一轮训练的。2.1 数据来源的三条渠道第一条渠道是从公开数据集里筛图。我主要翻了Cityscapes和BDD100K重点挑选人行道占比高、摄像机安装位置较高的帧。公开数据里的图像质量和标注规范都不错能省下不少功夫。不过需要提醒一句很多公开数据集的License只允许学术用途商业项目要用的话需要逐条确认别等上线了才发现授权有问题。第二条渠道是自行采集。这个是数据质量的下限保障。我安排团队在不同城市、不同时段早高峰、晚高峰、夜间、雨天拍摄了路口、商业街、学校门口、医院门口这几类典型位置大概产出4600多张有效图。拍摄时尽量用接近立杆高度的机位和俯拍角度同时留意不要拍到人脸特写和车辆车牌信息后续商用合规风险会小很多。第三条渠道是合作伙伴提供的存量素材。市政养护单位的日常巡检记录里有大量工程视角的行人道照片和视频片段我挑了约1900张用于补充路面病害和施工围挡这类细类。这类素材的特点是真实、稀缺、外界很难自行采集缺点是构图和光照条件不稳定清洗时要格外留心。2.2 清洗流程清掉哪些图、留下哪些图清洗不是看一眼不好看就删得有可复现的标准。我给自己定了几条硬性指标清晰度用拉普拉斯方差评估数值小于某个阈值的视为模糊帧直接删掉。具体阈值要根据数据集整体分布去定我当时先用50张样本试跑确定在100左右比较合适。曝光与光照夜间过曝到纯白、强逆光导致目标完全淹没在高光里的图少量保留可以增强鲁棒性但不能占比超过5%否则模型会被带偏。重复帧视频抽帧时会产生大量相似度极高的相邻帧用SSIM和上一帧做对比相似度超过0.9的剔除否则训练集里全是高度自相关的数据验证集指标会虚高。分辨率统一不低于1920x1080低于这个分辨率的图对于密集小目标检测基本没什么训练价值。清洗后的10300张图类别分布上行人、电动自行车、汽车、井盖、路锥这几类偏多路面病害和施工围挡相对少一些。说实话类别不平衡在这个场景是常态后面可以通过采样策略和损失函数去缓解不用一开始追求完美均衡。2.3 train/val/test划分不能被忽略的细节划分数据集的时候大多数人直接随机split这是个隐蔽的坑。我的做法是按摄像头点位和目录来划分保证同一个摄像机视角下的连续帧不会同时出现在训练集和验证集里。原因很简单如果同一路视频的相邻帧被拆到两个集合里模型相当于提前见过答案验证精度会虚高好几个点等到部署到新点位立马现出原形。我的划分比例是7:2:1训练集约7210张验证集约2060张测试集约1030张。测试集单独锁起来整个训练调参期间不允许看它的效果只在最后评估一轮。这样才能真实反映模型在新点位上的表现。提示数据集的划分记录一定要留档。后面迭代时经常要回答为什么这个版本在某个点位掉点的问题没有划分记录几乎是无法定位的。3. 标注规则才是这类数据集的隐藏主线做过数据项目的朋友应该都有体会标注规范写得不细后患无穷。尤其是人行道这种目标类别多、遮挡频繁、对象边界模糊的场景如果两个标注员对同一张图的框法不一致模型学到的就是一团矛盾。我在做这套数据集时前前后后改了四版标注规范下面把最终定下来的一套关键规则列出来。3.1 标签体系的业务化设计标签不是越多越好而是要为业务判定服务。我最终定了11个类别设计逻辑遵循交管市政双线需求类别ID标签名覆盖对象业务用途0pedestrian行人含走路、站立、推婴儿车、推行轮椅的人行人流量统计、闯红灯判定1cyclist骑自行车的人人和车整体框入非机动车违章2e-bike电动自行车、摩托车、三轮车人和车整体框入非机动车违章、外卖车管理3vehicle汽车包括违规驶入或停入园路的车违停检测4traffic_light红绿灯灯体只标灯头不标杆件信号灯识别5sign交通标志、禁令标志含杆件区域一起框标志可见性巡检6roadblock路锥、水马、雪糕筒、隔离桩施工占道判断7manhole井盖只标可见的圆形区域市政设施巡检8dumpster垃圾桶、垃圾箱、垃圾袋市容环境问题9pavement_damage路面坑槽、明显裂缝、破损地砖市政病害巡检10construction施工围挡、护栏、堆物占道施工监测这个设计有几个讲究。一是cyclist和e-bike都是人车整体框而不是分别标人和车。好处是业务上直接就能判断是哪类非机动车坏处是当人离开车的时候比如快递员上楼送件模型会把人标成pedestrian把车标成e-bike逻辑上需要后处理去配对。二是manhole和pavement_damage这两个类别业务很重标注时稍不留神就会跑偏所以边界规则必须写死。3.2 边界规则怎么定才不会撕标注规则不写清楚最终一定会出现同一目标被标成不同类别的扯皮。我这里列几条亲自踩过坑后定下的规矩遮挡超过50%的目标不标注。刚被大树挡住一半以上的行人宁可不标也不要给出一个歪歪扭扭的框否则模型学着学着就迷茫了。目标最小可见尺寸不低于15像素短边。太小的目标不是不能识别而是标注精确度没有保障在智慧城市场景里15像素以下的远处目标对业务判定意义也不大。骑行者一律把人和车整体框入不拆开。如果只有车没人标vehicle类共享单车停放在路边如果只有人推着车走标pedestrian。红绿灯只标灯头发光面不标黑杆。杆件太长会把画面里其他小目标全部挤掉给边框回归造成误差。井盖只标注圆形的可见区域被落叶、积水盖住超过一半就不标。路面病害只标看得到的边缘不脑补裂缝走向裂缝断开就标多个独立框不要硬连成一条。每一条规则我都能说出一条具体的失败案例。比如红绿灯不标黑杆这条就是因为在第一版标注里把杆子一起框进去了导致模型学出来的框很长和行人框重叠严重后处理NMS直接把行人干掉了。3.3 标注工具与半自动加速工具选型上小团队单机作业我推荐X-AnyLabeling它是开源的支持加载YOLO模型做预标注然后人工在预标注结果上修正。整套流程下来一张复杂人行道图的标注时间能从纯手工的3分钟以上压到40秒左右效率提升非常明显。多人协作的话用CVAT会更顺手尤其是在线分配任务、多人同时标注、冲突管理这些功能很成熟。不过CVAT的部署和运维有学习成本一个人干小项目的话稍显重。我最后是蛇形走位先本地批量预标注再在CVAT上做交叉校验和修正兼顾效率和一致性。到这里插一句心里话10300张图、合计两万多个目标框听上去是个大工程但流程理顺之后比想象中快得多。真正耗时间的不是画框而是反复统一标准、review争议样本、给标注规则打补丁。3.4 抽检和交叉一致性校验标注完不等于可以训练了必须做质量抽检。我的做法是按批次抽5%的图交给两名标注员完全独立地重新标一遍然后用Kappa系数评估一致性。阈值定在0.7以上才算通过低于这个数就说明标注标准还没有统一需要回头重看规范、对齐典型争议图。这个环节非常值得花时间。我第一次抽检时Kappa只有0.62问题集中出现在推婴儿车的人算不算pedestrian施工围挡和roadblock怎么区分这两个点上。开会逐张对齐后第二轮Kappa升到0.81后面模型训练的效果也明显稳了。4. 用不同YOLO版本的实测对比和损失函数观察数据准备好了接下来就是模型训练。我先后用YOLOv8、YOLO11的几个尺寸做了对比实验。这一节把配置、结果和对损失函数的一些观察整理出来方便你们复现和对照。4.1 训练环境与超参配置硬件是两台RTX 4090显存24GB操作系统Ubuntu 22.04。训练脚本基于Ultralytics的CLI核心参数如下batch size16输入分辨率1280x1280小目标密集场景下比640提升明显代价是训练和推理都变慢优化器SGDmomentum0.937初始学习率0.01配合cosine decayepochs200开了早停mosaic前180个epoch开启最后20个epoch关闭类别权重因为存在类别不平衡给manhole和pavement_damage各乘了1.2的权重系数这里提一下mosaic的调整逻辑。Ultralytics默认全程开mosaic但在人行道这种高密度遮挡场景里mosaic会把大量行人裁切成半个身子、一个头或者一条腿模型学到的一堆残缺目标特征测试时遇到完整目标反而框不准。后来我改成前期开mosaic增强多样性和稳定收敛后期关掉mosaic精修小目标的recall有明显回升。4.2 四个模型版本的实测成绩我用同一份划分好的数据分别跑了YOLOv8s、YOLOv8m、YOLO11s、YOLO11m指标对比如下自测参考值具体会因为硬件和数据划分略有浮动模型输入分辨率mAP50mAP50-95参数量单帧推理耗时(640输入, RTX 4090)YOLOv8s12800.7410.51211.2M约3.1msYOLOv8m12800.7930.55825.9M约5.5msYOLO11s12800.7580.5299.4M约2.8msYOLO11m12800.8140.58220.0M约4.7ms结论很明确在同等输入分辨率下YOLO11m是本数据集上精度和速度平衡最好的一个参数量不算大mAP50接近0.82mAP50-95拉到0.58以上。YOLOv8s适合算力特别紧张、只求实时跑通现场验证的场景YOLOv8m则是一个够用但不够精的中间选项如果要部署新点位对精度要求高我不会选它。还有一点需要说明上面表格里的单帧推理耗时是640输入在RTX 4090上跑出来的真实部署到Jetson这类边缘设备上完全不是这个数后面第5节会单独聊。4.3 损失函数不是调参的全部YOLO的损失函数组成是分类损失BCE 定位损失IoU系列置信度损失BCE。默认情况下YOLOv8和YOLO11用的是CIoU作为回归损失它综合了重叠面积、中心点距离和宽高比。我在密集人行道场景里观察到一个现象CIoU在目标互相重叠的情况下边界框回归容易被挤偏。举个例子一个人站在电动自行车旁边车把和行人手臂在画面里重叠CIoU会倾向于让框尽量贴合中心点结果两个框相互妥协哪个都不准。后来我实验了一组SIoU考虑角度惩罚密集行人场景的box稳定了一些框和目标的贴合度肉眼可见地变好但换来的是部分小目标分类漂移增加整体mAP只提升了0.3左右训练时间却拉长了将近20%。这个投入产出比不算划算所以最终我还是回归了默认的CIoU把精力更多放在数据增强和输入分辨率上。说实话损失函数在这个项目里不是决定性因素。真正拉高mAP的是1280输入分辨率、关闭后期mosaic、针对性补充失败案例数据这三件事。损失函数属于锦上添花不是雪中送炭。对外讲技术方案时我一般先讲数据再讲损失函数顺序不能反。4.4 几个让精度大幅变化的失败案例失败的案例往往比成功指标更有参考价值。这里挑三个印象最深的第一个是蓝色雨棚问题。一开始模型频繁把遮雨棚下的电动自行车误检成vehicle把卖菜摊位的蓝色棚子误检成manhole。原因很直接训练集里带雨棚、遮阳棚的样本太少了模型只能靠颜色和形状去猜。补了大概300张带棚子场景的图之后这两类误检直接降了70%。第二个是放学场景的小目标。小学门口晚高峰远处行人在1280分辨率下也只有20x40像素左右640输入基本全漏。把输入升到1280后小目标recall提了一大截但边缘设备的推理压力也随之而来。这个属于典型的精度-速度trade-off业务上要自己权衡。第三个是树荫误检。树影摇曳导致地面光斑不断变化模型一度把地面上的树影轮廓认成路面裂缝。这问题不是加数据能彻底解决的最后是通过时序滤波把连续帧中目标停留时间不足0.5秒的检测结果过滤掉才把误报压下去。5. 从训练服务器到AGX Orin边缘部署的落地观察模型在RTX 4090上跑得快不算本事部署到边缘盒子还能维持可用的精度和帧率才是智慧城市项目的真正挑战。这一节记录我在Jetson AGX Orin上部署实测的一手数据和一些工程细节。5.1 导出ONNX与TensorRT加速的关键点训练完的模型不能直接拿去部署格式需要转一圈。我的导出流程是yolo export modelyolo11m.pt formatonnx dynamicTrue opset16导出后的ONNX模型在Jetson上用trtexec转成TensorRT引擎trtexec --onnxyolo11m.onnx --saveEngineyolo11m_fp16.engine --fp16这个步骤里有一个值得提醒的坑YOLOv8和YOLO11导出的ONNX默认不包含NMS非极大值抑制层。NMS需要放在模型外部也就是说推理流程是模型出框 - 自己做NMS。如果你习惯直接套用某个框架的端到端部署包很可能在NMS这一步被卡住等于是把产出结果托管在应用层代码里处理。另外FP16量化在精度上几乎没有感知损失mAP50大约只掉0.5个百分点换来的是推理速度提升接近一倍在人行道场景完全值得开。5.2 AGX Orin上的推理速度与取舍在Jetson AGX Orin32GB版本上TensorRT FP16引擎的实测速度如下模型输入分辨率单帧推理耗时约合帧率YOLOv8s960约25ms40 FPSYOLOv8m1280约65ms15 FPSYOLO11m1280约55ms18 FPSYOLO11m960约35ms28 FPS如果是单路视频流YOLO11m在1280输入下18FPS基本够用如果一路摄像头要覆盖多车道和人行道两个方向建议降到960输入帧率直接升到28FPS精度损失在密集小目标上也能接受。多路摄像头同时推理是另一个故事。十几路视频同时上AGX OrinYOLO11m想都跑满肯定不现实。我的工程策略是给每路视频分配独立的推理队列非关键帧按1/2或1/3抽帧处理关键帧比如检测到目标后的确认帧走全分辨率。这样在保证不漏大事的前提下总算力勉强够撑住。5.3 检测框之外业务规则和多模态分析的衔接部署阶段最容易犯的错误是以为模型输出几个框业务就闭环了。实际上目标检测只是智慧城市感知链路的前半段。比如违规占用人行道这个判断不能单凭一帧里有个vehicle框就报警——车可能只是路过或者正短暂停靠有人上下车。我习惯在模型外面再包一层规则引擎目标框在连续多帧中都存在且中心点位移小于阈值判定为停留。停留的vehicle框与禁停区域预先用多边形标注计算IoU超过0.5才触发违停告警。相邻帧的同一个目标用跟踪算法如ByteTrack关联避免重复计数和误报。另外只靠矩形框分类确实无法回答这个人是骑行还是推行这辆送货车是正在卸货还是违章停放这类细粒度问题。这两年我注意到基于目标检测多模态AI分析的趋势越来越明显拿CLIP或者多模态VLM去读检测框里的内容做语义理解能让业务判定从是什么升级到在做什么。这个方向在智慧交通和智慧市政场景里很有落地空间但这套数据集本身仍然是最底层的地基。5.4 模型持续迭代hard example回流数据集做到10300张不是终点真正的长期工作是把部署后采集到的hard example持续回流到训练集里。我现在的做法是每个点位保留最近一个月的误检和漏检截图每月做一次筛选挑出对模型提升最有价值的几百张图补充标注重新微调一轮。这个循环机制一开始看不见明显效果但跑三个多月后新点位首测的误报率基本能降一半。比我一开始花大把时间追求完美标注划算得多。模型需要的是在错误中不断长出适应现场数据的能力这个思路放在哪里都不会错。最后分享一个体会。我做完这个项目最大的收获不是模型精度最终刷到了多少而是意识到智慧城市算法这条链路里真正决定成败的往往不是模型结构多复杂、算力堆得多高而是数据和业务标签体系设计得是否贴合场景。训练一个能用的YOLO模型一周时间足够了但把数据、标注、清洗、部署、回流这条链路跑顺才是一个项目真正耗费心力的地方。如果你们也在做人行道检测或者类似的道路场景项目我的建议是先从最容易获得数据的几个摄像机点位开始跑通一遍采集-清洗-标注-训练-部署闭环再谈扩大规模和优化精度。就我的经验来看十个点位的高质量增量数据带来收益远比十次复杂的模型改动大。

智慧城市人行道检测实战：自建YOLO数据集与边缘部署全流程

相关推荐

Log Explorer for SQL Server：事务日志解析与UNDO脚本生成实战

DC-4靶机实战解析：Linux权限提升与漏洞链式推理

SSD生命周期预测：从SMART数据到机器学习实战

更多资讯

Qwen-Image-2.1云GPU服务器部署保姆级教程：从环境到API

Qwen-Image-2.1云端部署保姆级教程：从GPU选型到vLLM服务落地

Qwen-Image-2.1：本地可控的视觉指令编辑引擎

PDF里没有表格，PDF转Excel行列是靠什么对上的？

C#调用BarTender打印标签：COM与命令行双方案详解

Java语言基础入门与开发环境配置指南

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？