盲道识别实战：从语义分割数据集构建到端侧部署全流程

简介语义分割是计算机视觉中实现像素级场景理解的核心技术它通过对图像中每个像素进行分类精确区分不同物体与区域的边界。在道路要素感知与无障碍设施识别中这一技术能有效解决传统目标检测难以应对的细长或不规则目标问题。构建高质量自建数据集是模型性能的关键结合Cityscapes预训练迁移学习与SAM辅助标注可显著提升模型收敛速度与标注效率。语义分割模型的选型需在精度与速度间权衡DeepLabV3适合离线高精度分析STDC等轻量网络则能通过TensorRT加速实现端侧实时推理。该技术可广泛应用于助盲工具、市政盲道普查、无障碍地图构建等场景为城市精细化治理提供底层数据支撑。 盲道识别这个项目最初我是把它当成一个普通的地面要素检测任务来做的。真正动手以后才发现现实里的盲道远比想象中复杂砖块颜色被晒得发白、被电动车压碎、被树根顶起、中段断掉盲道尽头直接接上马路牙子标成什么形状的都有。所以我从目标检测一路换到语义分割最后沉淀了一套从数据集构建、模型训练到端侧部署的完整流程。这篇就把整个过程中的思路、选型和踩坑记录都整理出来希望能给同样在折腾无障碍识别、道路要素感知或者城市级语义分割数据集的读者一些参考。这个项目能用来做什么往小里说可以做成手机端的助盲工具检测到前方盲道被占用或者中断就语音提醒往大里说可以做市政盲道普查的数据生产也可以为无障碍地图提供底层图层。所以如果你是做计算机视觉方向课题的学生或者准备把语义分割模型落地到边缘设备的工程师这篇内容会比较对路。接下来按我实际做项目的顺序来聊先拆需求再讲数据集然后说模型训练和部署最后聊聊那些真正让人熬夜的问题。1. 项目整体设计思路拆解1.1 盲道识别为什么是件难事很多人第一次接触盲道的计算机视觉项目时会觉得“盲道不就是一条黄色砖带吗按颜色过滤不就行了”。等你真到街上拍一圈照片回来就会发现这个想法有多天真。首先盲道的颜色极其不稳定。标准盲道砖确实多为黄色但经过几年的风吹日晒雨淋浅黄、灰白、甚至接近水泥地面的颜色都普遍存在。不同城市的盲道砖材质和颜色也不一样有的铺红色砖有的铺灰色砖有的表面已经被磨得几乎看不出凸起条纹。单纯靠颜色阈值或者边缘检测第一轮就会被淘汰。其次是形状的断裂问题。盲道在路口、小区门口、店铺入口处经常被截断或者接连水泥斜坡或者被井盖打断。再加上树根鼓起造成砖面碎裂、施工后回填不规整、摊贩长期占道导致局部磨损严重模型如果只学习“完整盲道砖”的特征在真实场景下会漏掉大量样本。还有一个很麻烦的点是遮挡。电动自行车停在盲道上是最常见的场景其次是共享单车、摊位、垃圾桶、施工围挡。有些遮挡物面积很大比如一整排共享单车把盲道完全盖住图像里只能看到车轮和车架盲道砖暴露出来的部分可能只有零星几块。这时候模型不仅要识别盲道本身还要判断盲道区域里有哪些东西占用了它任务就从“分类”变成了“场景理解”。光照和拍摄视角也不可控。同一段盲道在晴天正午、阴天傍晚、雨后反光状态下的外观差异非常大。手机拍摄高度和俯仰角的变化会让盲道砖的透视形状完全不同。如果数据采集阶段没有刻意覆盖这些变化模型基本上一换城市就废。1.2 为什么选语义分割而不是目标检测一开始我确实先试的目标检测方案用YOLOv8标注盲道的矩形框跑出来的结果只能说是“能看出个意思”。问题出在目标检测的本质上它输出的是矩形包围框。盲道是连续长条的不规则区域矩形框会把大量非盲道像素包进来。我框一条长度十米的盲道段目标框里可能有一半面积是旁边的普通地砖、绿化带甚至马路。检测模型虽然能告诉你“这里有一条盲道”但没法告诉你“盲道具体占哪些像素”“盲道的哪一段被堵住了”。语义分割就完全不一样。它是对图像中的每一个像素进行分类输出的是一张和输入图像尺寸一致的分割掩码每个像素点被标记为“盲道”“障碍物”“行人”“车辆”等类别。我拿到分割结果后能够精确到像素级地分析盲道区域哪些地方是连续的、哪些地方被其他类别的物体遮挡或占用。举个具体例子。在无障碍导航场景中我希望知道“盲道前面有没有被电动车占住”。如果用目标检测我只能得到“一张图里有一辆电动车”和“一条盲道”两个框至于电动车是不是真的压在盲道上得靠矩形框的IoU重叠程度去猜。用语义分割的话我直接取“电动车”类别掩码和“盲道”类别掩码做像素交集交叠区域落在盲道掩码内的面积比例一算答案就非常明确。还有一点是可视化效果。分割结果可以直接以半透明色块叠加在原始图像上给人看的时候非常直观。给非技术背景的同事或者合作方展示时一张像素级的分割图比几十个检测框的说服力强得多。不需要实例分割的原因也很简单盲道、人行道、普通地面的个体之间没有明确的区分边界我不需要知道“这是第几段盲道”只需要知道“这些像素属于盲道类别”。所以纯语义分割就能满足需求省掉实例分割的大量开销。1.3 技术路线选择方案定下来之后我在技术路线上做了两个方向的规划。第一个是离线高精度路线用于城市级盲道普查数据生产。这里的场景是拍完大量街景视频后做批量分析对单张图片的推理延迟不敏感更看重mIoU和边界质量。模型可以选大一些比如DeepLabV3配合ResNet101骨干网络或者SegFormer-B3。一张图推理几十毫秒到几百毫秒都可以接受最终输出的是整条街道的盲道覆盖图和破损、占用标记。第二个是在线轻量路线用于手机端或者嵌入式设备的实时识别。这里受算力限制需要选STDC、BiSeNet这类轻量级语义分割网络结合TensorRT或者ONNX Runtime加速输入分辨率也降到512x512甚至更低。分割结果实时反馈给语音播报模块做到“前方盲道被占用请绕行”这种级别的交互。两条路线共用同一套数据集和标注体系只是训练时的输入尺寸、模型规模、推理后端不同。这种设计的好处是数据集只需要维护一份算法演进时不用重复标注。配套的数据生产环节我放在了数据集部分详细说明先不展开。2. 计算机视觉数据集构建从公开数据到自建数据2.1 公开数据集能帮上什么忙先说一个残酷的现实目前公开的计算机视觉数据集中专门针对盲道语义分割的几乎没有。我翻过Cityscapes、BDD100K、Mapillary Vistas这几个大型街景数据集驾驶视角下的数据为主盲道在这些数据集里很多时候根本看不清更没有单独的标注类别。那么公开数据集还有没有用有但用处在于预训练而不是直接训练。我用Cityscapes的19类分割权重作为预训练模型然后在自建数据集上做迁移学习。虽然Cityscapes里没有盲道类别但它训练出的骨干网络已经学会了区分道路、人行道、车辆、行人、建筑等基础语义信息这些低层特征对盲道识别非常有帮助。尤其是边缘纹理和空间上下文迁移过来之后模型收敛速度快很多最终精度也更高。也试过直接用ImageNet预训练权重对比发现Cityscapes预训练确实比ImageNet预训练在mIoU上高一到两个点。原因不难理解ImageNet分类任务学到的是物体外观的全局特征而Cityscapes让模型从一开始就在密集预测的语境下学习特征对空间细节更敏感。还有一个可以参考的数据集是Aeroscapes但它是航空视角的地面物体尺度差异太大基本只能用来做数据增强的补充不能作为主数据源。我的建议是调研公开数据时可以放宽关键词去搜“sidewalk segmentation”“curb detection”这些类别虽然没有盲道但地面分割的标注逻辑和盲道场景非常接近。2.2 自建数据集的采集与标注规范既然公开数据不满足要求就只能自己建。数据采集的方案我是这么定的用手机和GoPro在市区选取多个路段覆盖商业区、居民区、学校周边、公园步道等不同场景拍摄时段分为白天、傍晚和阴天保证光照多样性。采集时要注意几个细节。手机尽量固定在腰间或者用自拍杆前伸模拟盲人手持手机的高度不要站在高处俯拍。每段路拍完后回头检查一遍删掉曝光严重不足的模糊帧。快进的视频要逐帧抽帧一般每隔2到3秒抽一帧避免相邻图片重复度过高导致数据集不平衡。类别设计上我没有只标“盲道”一类而是定了五类background普通地面、建筑、天空等tactile_paving盲道barrier固定障碍物石墩、栏杆、电线杆、花坛vehicle机动车、电动自行车、共享单车person行人为什么要单独加barrier、vehicle、person这三类因为如果只标盲道模型对“什么不是盲道”的学习完全依赖背景类别遇到一个没见过的物体很容易误判。把这些常见占用物标注出来模型就知道“盲道区域里出现的电动车轮廓是什么样子的”到后面做盲道被占用判断时有直接帮助。标注工具我用的是Labelme适合单人小规模标注。如果团队超过三个人建议直接用CVAT支持在线协同、标签审查和自动保存效率差很多。多人标注时最大的坑是标注标准不统一比如同一个被树根顶碎的盲道区域一个人标成盲道破损另一个人直接标成背景。所以在正式标注之前一定要写一份标注规范并在标注过程中持续抽检。几个实用的标注规范多边形必须闭合盲道边界要与砖块边缘对齐如果有遮挡物遮挡物内部留空不要强行把看不见的盲道轮廓脑补出来。盲道被落叶覆盖时仍然按可见的砖块轮廓标注为盲道因为物理上盲道仍然存在。盲道被电动车大面积挡住时先标电动车为vehicle再把露出来的盲道部分单独标成tactile_paving不需要为看不见的盲道部分猜测轮廓。对整张图片中面积小于5x5像素的碎块类目标直接标为背景不强行标注不然会引入大量标注噪声。2.3 SAM辅助标注与数据增强策略自建数据集中最耗时的环节就是标注。我一开始全手动标注一张1080p图片要半小时左右大量时间花在沿着盲道砖的边缘一点点描点上。后来试了用Segment Anything ModelSAM做辅助预标注效率提升非常明显。具体操作流程是这样的。先把图片扔给SAM用自动分割模式生成全图的分割候选掩码这一步通常能比较准确地把盲道区域切出来因为盲道砖的纹理和普通地面有明显区别。然后我在Labelme或X-AnyLabeling里加载SAM生成的掩码人工检查修正边缘。对于SAM漏掉的区域配合“点提示”或者“框提示”重新生成局部掩码。这样一张图从半小时缩短到五分钟左右。当然SAM也不是万能的。遇到盲道和旁边浅色地面颜色很接近的图片SAM会直接把两边合并成一个连通域需要人工把边界重新描出来。还有就是遮挡场景SAM能正确标出电动车的掩码但电动车下面只露出几块碎砖的盲道SAM经常识别不出来。这一部分没什么捷径只能手动补标。数据增强方面我用的组合比较常规随机水平翻转、随机缩放、随机裁剪、亮度对比度扰动、HSV色域抖动。因为盲道在图像中经常呈长条状分布在图像中下部随机裁剪时要注意裁剪区域必须包含训练样本的主要类别不然一批裁剪样本全是背景模型就学到了“把所有东西都预测成背景”。类别不平衡问题也在这里暴露得很明显。通常一张城市街景图中背景像素占比可能超过七成blin道像素占比在10%到20%之间barrier、vehicle、person这些类别的像素占比往往不到5%。如果直接用原始交叉熵损失函数训练模型会倾向于把所有像素都预测成背景因为这样能获得很低的损失。后面训练章节会专门讲损失函数和加权策略这里提一句数据增强阶段还可以对包含少数类的小图块做过采样让模型在训练时多看到这些类别。3. 语义分割模型选型与实操训练3.1 模型对比与选型建议语义分割模型这几年迭代得很快但选型逻辑其实很清晰。我把常见模型按“精度优先”和“速度优先”分了两组来对比。精度优先组DeepLabV3、SegFormer、OCRNet。DeepLabV3是CNN时代的集大成者ASPP空洞空间金字塔池化模块能有效扩大感受野对盲道这种细长形目标特别友好。SegFormer是Transformer架构自注意力机制在全局语义理解上更强但显存占用和推理延迟都偏高。OCRNet通过上下文信息增强目标区域的分割效果对细长物体有额外加成不过训练时需要调参的项也更多。速度优先组BiSeNet、STDC。BiSeNet用双分支结构兼顾空间细节和语义信息是轻量级分割网络的老牌选择。STDC是BiSeNet的改进版用结构重复的卷积模块替换复杂分支在同等精度下参数量更小推理速度更快。STDC在Cityscapes上能跑到接近60%的mIoU对于实时场景完全够用。我实际用下来盲道识别这种结构相对规则的地面目标模型的“天花板”并不高。DeepLabV3配ResNet50在自建数据集上就能跑到78%到80%的mIoU换成SegFormer-B2能再高一点但提升幅度有限。部署到手机上时STDC1配合TensorRT在720p输入下能做到10到20毫秒的推理延迟可以做到实时提醒。选型建议可以按这个表格来参考模型骨干网络mIoU自建数据集实测1080p推理延迟适用场景DeepLabV3ResNet5078%-80%约30-50msGPU离线批量分析DeepLabV3ResNet10180%-82%约50-80msGPU高精度离线分析SegFormer-B2Mix-Tiny80%-82%约60-100msGPU精度优先、算力充足OCRNetHRNet-W1881%-83%约70-120msGPU精度优先的场景STDC1STDC170%-74%约10-20msTensorRT端侧实时推理BiSeNetV2BiSeNetV272%-76%约25-40msTensorRT端侧实时推理3.2 训练工程细节与关键参数训练配置我直接用MMSegmentation做了一套基准。数据格式是标准的图片文件夹加语义分割掩码文件夹掩码是PNG格式的单通道图像像素值从0到4对应五个类别。这里有个特别容易踩的坑掩码图如果用JPEG保存压缩会产生伪影类别标签之间会混入中间值训练时莫名其妙的报错大概率是数据格式问题。修改脚本的时候有两点值得提掩码图必须用PNG保存训练前检查一下像素值的取值集合是不是完整的0到4。如果出现了255通常是标注工具导出时把背景填充值写成了255。输入尺寸的选择直接影响显存占用和感受野。全尺寸1080p输入在普通显卡上根本跑不动我退到512x1024和512x512两个档位实验最终选择了512x512。这样虽然丢失了一些小目标细节但对盲道这种大尺寸区域影响有限。损失函数层面我用的是交叉熵损失加Dice损失的组合。交叉熵是语义分割的标配Dice损失能缓解类别不平衡问题它对预测值和真值之间的重叠度更直接地优化对少数类更友好。我自己在4个类别不平衡的配置里启用这两个损失后barrier类别的IoU涨幅最为明显从不到30%涨到接近55%。优化器和学习率我用SGDmomentum0.9weight_decay0.0005初始学习率0.01配合Poly学习率衰减策略让学习率在训练后期平滑下降到接近0。Poly策略比固定学习率在分割任务上稳定得多不容易出现后期在最优解附近震荡的情况。迭代次数我的数据集规模在2000张左右设置epoch为80batch size为8在一张RTX 3090上训练大约3到4个小时能收敛。如果数据量到了5000张以上可以适当增加到120个epoch但务必在验证集上监控每个epoch的mIoU避免过拟合。训练时还有一个重要的监控指标每类的IoU而不只是总mIoU。总mIoU高并不意味着所有类别都好。我见过某个模型整体mIoU在75%但person类别IoU只有20%的情况。这种模型放到真实场景里遇到行人根本拦不住。模型框架的选用不是必须用MMSegmentation。如果团队更熟悉PyTorch用segmentation-models-pytorch这套库也可以快速完成类似实验。它的接口更简洁封装了U-Net、DeepLabV3、FPN等主流架构适合快速验证想法。对初学者来说我反而更推荐先用segmentation-models-pytorch跑通流程再根据需要对某个结构做自定义修改。3.3 从训练到部署如何保证实时性离线模式的部署比较简单直接把训练好的权重在服务器上用PyTorch跑推理或者转成ONNX格式用ONNX Runtime加载运行。麻烦的是端侧实时推理这里涉及模型压缩和推理加速两部分。模型压缩我做了两种尝试。一是TensorRT的FP16量化精度几乎不掉推理速度提升一倍以上。二是INT8量化速度快但mIoU掉3到5个点对盲道这种边缘细节敏感的任务影响比较明显盲道边缘会变得更粗糙所以我优先推荐FP16而不是INT8。剪枝也试过。结构剪枝掉一部分不重要的卷积通道后STDC模型的参数量减少三分之一推理延迟从20毫秒降到13毫秒但mIoU从74%掉到70%以下边缘质量下降得比精度数字看起来更严重。最终结论是端侧部署用STDC原始权重加TensorRT FP16就够了不需过度压缩。端侧硬件上我分别测了Jetson Nano和手机端的骁龙平台。Jetson Nano上STDC跑512x512输入TensorRT FP16推理约80到100毫秒勉强到10 FPS不能算流畅。手机端骁龙8系配合NPU或者GPU推理引擎能把延迟压到30到50毫秒交互体验好很多。如果目标设备是低算力平台建议把输入分辨率降到320x320实测精度下降不多但实时性立刻上来。还有一个很关键的部署策略是“截断式推理”。不是每一帧都跑完整模型而是只在检测到画面变化较大或者用户主动触发时才执行推理。静态场景下直接复用上一帧的分割结果。这个策略在助盲APP场景下很实用既省电又流畅。4. 常见问题与排查技巧实录4.1 训练集效果不错验证集却崩了这是语义分割项目里最常遇到的第一个坎。模型在训练集上mIoU 85%一到验证集直接掉到60%以下。我一开始怀疑是数据量不够拼命加数据增强结果提升有限。后来检查发现问题出在数据分布不一致上。我在采集数据时某个路段的图片因为连续抽帧出现了几百张高度相似的图片并且全部被分到了训练集。验证集里出现的是另一个完全陌生的路段。模型相当于“背”下了训练集的场景而不是学到了“盲道长什么样”。解决办法是把数据集按路段维度划分保证同一个路段的图像只出现在训练集或验证集中不能跨集混入。划分比例大概训练集85%、验证集15%。另一个常见原因是验证集标注质量差。我手工抽检了验证集掩码发现有些图里盲道的边缘被标歪了AI模型再准和标注不一致也拉不高IoU。这种问题只能靠重新仔细检查修正标签解决。4.2 盲道边缘锯齿、断裂严重怎么办分割结果边缘出现锯齿或者小块断裂跟几个因素有关系。模型感受野不足是一个方面。盲道在图像里虽然是大区域但边缘像素的上下文信息很有限尤其当盲道旁边緊挨着花坛或者楼梯时模型很容易把边缘像素预测错。我在骨干网络里增加一个辅助分割头让模型在训练时同时关注中层的细节特征边缘质量提升了不少。后处理也能改善断裂问题。我用条件随机场CRF对分割结果做边缘平滑效果有一些但会增加推理时间。考虑到实时场景后来更常使用的是“连通域分析”对盲道掩码做连通域提取把面积小于一定阈值的碎块过滤掉再把同一连通域中的空洞填补。这样虽然在单像素精度上不如CRF但视觉上整洁得多速度优势明显。4.3 盲道被占用的判断逻辑分割结果拿到手以后很多人以为直接看“盲道掩码旁边有没有车辆掩码”就行实际上需要更精确的逻辑。我方框定了一个“盲道区域”的判定标准将tactile_paving类别的掩码膨胀5到10个像素作为盲道的有效缓冲区域。然后计算vehicle、person、barrier三类掩码与这个缓冲区域的重叠面积占该物体总面积的百分比。超过阈值比如15%就判定该物体占用了盲道。这个逻辑能避免误判。因为行人从盲道旁边走过、暂时迈过盲道和电动车长时间停在盲道上是两种完全不同的情况。前者在时间序列上不连续后者通常连续多帧都成立。加入一个多帧投票机制后误报率明显下降。口播提醒的触发条件也做了分级盲道被占用面积很小只记录不提醒占用面积达到30%以上才触发语音警告。这样可以避免助盲工具变成“复读机”用户体验反而更差。4.4 部署在低算力设备上的性能优化低算力设备上做实时分割最大的感受是“瓶颈往往不在模型而在数据管线和运行时调度”。图像采集、预处理缩放、归一化、色彩空间转换、推理、后处理、语音播报整个链路中任何一环慢了都会拖累整体节奏。我在Jetson Nano上调试时发现图像缩放用了CPU的opencv函数单帧耗时几十毫秒比模型推理本身还慢。换成GPU硬加速的预处理流程后从“摄像头采集到结果回传”的端到端延迟从300毫秒降到了150毫秒以内。内存方面也要注意。分割模型的中间特征图占用显存512x512输入在Jetson Nano上还好但开启多个分支或者batch_size设成2显存就吃紧了。只推理单帧时强制释放中间变量可以多留出一些显存给系统UI。还有一个经验是把模型输出从Float32转成Uint8之后再传给后续逻辑模块。这样后续的连通域分析和OCR之类的模块可以直接用整数操作数据省去类型转换的内存拷贝开销。细节很小但真实项目中积少成多值得注意。写在最后跑完这一整套流程后我最大的感受是盲道识别这类项目难点从来不在模型结构而在数据和落地场景的适配。公开数据集帮不了太多忙的时候自建数据集的质量、标注规范和训练策略就成了决定项目成败的关键。想把精度从70%推到85%多找数据、多修标注比换一个更大的模型划算得多。如果你正打算做类似的地面要素识别或者无障碍设施方向我建议小步快跑。先选一个城市的一个区域把数据流和标注流程跑通拿到一版能用的模型再逐步扩展区域和类别。最后再分享一个小技巧模型训练完之后别急着部署先在模型预测结果上叠一层“可通行性热力图”盲道连续性、障碍物占用情况一目了然这个图无论给算法调优还是给外部演示都很有用。后续如果想继续往下深挖可以往无障碍路线规划方向做把分割的语义信息作为路径生成的输入那将会是另一个有意思的课题。本文还有配套的精品资源点击获取