做无障碍辅助这类AI视觉产品不少人第一反应就是“给用户装个导航App喊个口号就能带着人走”。但真把设备拿到一栋大型商场或者陌生写字楼里测一圈你会发现室内场景和室外完全不是一个量级的问题。Lumi 这个项目就是冲着这个难点去的——它是一套用于室内无障碍场景的AI视觉助手系统通过手机摄像头实时感知门、楼梯、扶手、障碍物、文字标识等环境信息再转换成语音和触觉反馈帮助视障用户和行动不便的用户在室内安全行走。这篇文章我会把Lumi从场景分析、系统架构、模型选型到部署优化的完整思路拆开来讲适合正在做AI视觉应用、无障碍产品或者想把深度学习模型真正落地到移动端的开发者参考。1. 为什么室内才是无障碍AI最难啃的骨头1.1 GPS失效之后位置感知的底层逻辑变了室外无障碍导航的核心是GPS配合地图数据误差在几米到十几米之间其实可以接受因为道路是连续、有明确边界且相对稳定的。但室内完全不同——GPS信号在钢筋混凝土结构里衰减严重基本没法用蓝牙信标和WiFi RTT虽然能提供室内定位但精度通常在1到3米而且需要提前部署基础设施。一栋楼宇如果没有做过信标铺设这套方案就完全失效。所以Lumi从一开始就没有把“绝对定位”作为核心路径而是转向了“相对感知”。说白了就是我不需要知道你现在在经纬度哪个点、对应地图上哪一层我只需要知道你眼前是什么、有没有台阶、前方路能不能走、左边那扇门是不是出口。这种思路的本质是把定位问题变成感知问题靠视觉模型实时理解环境而不是靠一张静态地图去套。这也是AI视觉在室内无障碍场景里最独特的价值——它不依赖任何预先架设的基础设施。1.2 无障碍的核心从到达变成了安全接近室外导航说“前方50米右转”用户走到路口自然能看到路牌因为室外空间相对开阔。室内却不行——走廊里可能堆着杂物楼梯口可能没有警示条电梯按钮高度各不相同门可能是一扇透明的玻璃门。对视障用户来说这些问题每一个都可能是安全隐患。最典型的例子是“到达门口”这个动作。室外导航把你带到楼栋入口附近就算完成任务但室内场景里用户需要的是“走到门前、把手在右边、门是推还是拉、门内有没有障碍物挡住”。这已经完全超出了传统导航的范畴需要的是细粒度的环境理解。Lumi把任务拆成几类检测门和楼梯这类结构性元素分割出可通行的地面区域识别门牌和楼层文字估算前方障碍物的距离。每一类任务解决一个具体的“安全接近”问题而不是简单地“带你去某个坐标”。1.3 室内外场景的工程约束差异维度室外室内Lumi面对的场景定位信号GPS可用GPS不可用信标依赖部署光照变化白天、夜间、逆光走廊顶灯、昏暗楼梯间、窗户反光环境结构道路边界清晰墙、门、玻璃、家具混杂动态物车、人行人、购物车、保洁设备导航目标到达坐标点安全接近目标物并执行动作模型训练数据公开数据丰富室内无障碍数据分散且难找设备状态手机可横屏/手持用户可能单手拄盲杖设备佩戴方式特殊这张表是Lumi立项分析时的核心依据。前四行决定了技术选型方向后三行直接决定模型的训练和数据收集策略。说实话之前我也觉得“不就是做个视觉识别嘛”但真正在商场里用轮椅和眼罩做模拟测试之后才意识到每一行差距都会变成实际产品里的一个坑。2. Lumi系统架构从摄像头到语音的全链路设计2.1 感知硬件选型为什么第一版选择手机端Lumi第一版没有做定制硬件而是选择手机作为载体。原因很实际手机内置了高分辨率摄像头、高性能处理器、扬声器、麦克风、振动马达开发成本低用户也基本人手一台。相比之下智能眼镜形态虽然解放双手但算力和散热有限摄像头角度固定而且价格门槛高拐杖传感器方案则无法感知到头部高度的信息遇到悬挂类障碍物容易漏检。不过手机方案也有明显的麻烦——持握方式和摄像头角度不可控。用户可能把手机挂在胸前也可能举在手里还可能侧放在口袋边缘。这些都会导致画面的视角变化。Lumi的应对方式是让模型对视角保持一定鲁棒性训练数据里加入了不同高度、不同倾斜角的画面。实测下来挂在胸前比拿在手里效果更稳定因为画面水平且抖动小手持时摄像头会随步伐上下晃动需要算法层面额外做时域平滑。2.2 主干处理流程帧率、延迟与并发任务调度Lumi的感知管线是一条典型的多任务流水线摄像头取帧 → 目标检测 → 语义分割 → 文字识别 → 深度估计 → 多路结果融合 → 规则引擎判断优先级 → 语音或振动输出。这里最容易犯的错误是“每一帧都要跑完全部任务”。假设每一帧都跑检测、分割、OCR、深度估计四个模型哪怕每个模型只耗时30毫秒串行就是120毫秒加上前后处理一秒钟只能处理七八帧延迟根本压不住。而且四路模型同时跑CPU和NPU可能存在争抢帧率反而更不稳定。Lumi的做法是分帧调度目标检测作为主任务每帧执行因为它负责“看到什么”语义分割和深度估计按关键帧执行每3到5帧跑一次因为地面区域和深度变化在短时间内是连续的OCR检测则放到专门的触发流程里只有当用户按“读文字”按钮或者系统判断当前画面中存在门牌类区域时才会执行。这样既保证了核心任务的实时性又给了重模型足够的计算窗口。模块执行频率单次耗时预算说明取帧与预处理每帧10ms缩放到640x480目标检测每帧25-35ms主感知任务语义分割每3-5帧30ms判断可通行区域深度估计每3-5帧35ms测量障碍物距离OCR触发式150-300ms识别门牌、楼层文字语音合成事件驱动80-120ms短句优先2.3 模块划分哪些任务必须端侧实时完成在模块边界设计上Lumi坚持一条原则一切涉及安全判断的任务必须端侧实时完成。端侧推理没有网络延迟、没有流量消耗、数据不出设备这是无障碍场景的底线——你不能在用户下楼梯的时候等云端返回结果。OCR这类任务相对重但如果需要识别的文字就在眼前端侧也能撑起来。真正需要网络的主要是两类场景一是地图数据拉取比如进入一栋新商场时获取楼层基础信息二是模型更新比如夜间WiFi环境下下载新版本模型。除此之外视觉推理全链路都跑在端侧。这个架构带来的额外好处是隐私保护变得非常自然——视频流从头到尾没有离开过用户的手机也就不用费力去解释“你的摄像头画面被传到了哪里”。3. 四类视觉模型的拆解从检测到深度估计3.1 目标检测识别门、楼梯、扶手、障碍物检测模型是整个系统的“眼睛”它决定用户能感知到哪些环境元素。Lumi检测类别设计得比较克制按优先级分成三级第一级是安全类——楼梯、台阶、坡道、障碍物第二级是结构类——门、电梯、扶手、走廊第三级是信息类——卫生间标识、出口标识、盲道。类别不是越多越好每加一个类别就会引入更多误检风险尤其是视觉上相似的对象比如电梯门和普通门、坡道和平面地板类别太细反而会降低实用价值。模型结构上第一版试过YOLOv8n和NanoDet后来定在YOLOv8n。理由很简单它在手机端的单帧推理耗时能控制在30毫秒左右参数量不大而且针对小目标做了多尺度检测门缝里的消防栓、走廊尽头的出口灯箱这类小物体也能框出来。输入分辨率用的640x480没有上1280——分辨率翻倍意味着计算量翻几倍而640级别已经能识别出门、楼梯等主要目标。需要特别留意的是NMS阈值的设置。在密集的室内环境下同一扇玻璃门会产生很多重叠框阈值设太高会漏检设太低又导致重复播报“前方有门”。实测下来置信度阈值定在0.4到0.45之间最舒服既不会把墙上的反光当门框也不会漏掉半开的门。3.2 语义分割判断地面能不能走检测框能告诉你“那里有一扇门、这里有楼梯”但它回答不了“眼前这片区域能不能走”的问题。比如一条走廊中间放着一个矮墩检测模型如果没把它框出来用户直接走上去就麻烦了。语义分割解决的就是这个“可通行区域”的判断问题。Lumi用的分割模型是MobileNetV3-Large作为backbone的LRASPP结构输出分辨率是输入的四分之一对地面、墙、楼梯、障碍物四个类别做像素级分类。这里我没有选择高分辨率的DeepLabV3因为移动端推理速度扛不住也没有选择纯二分类可通行/不可通行因为“楼梯”和“障碍物”对用户来说是完全不同的反馈——楼梯需要提示“上下楼”障碍物则是“绕行或者停下”。分割模型在实际测试中暴露的最大问题是反光地面。商场里的大理石地面在灯光下会产生镜面反射模型会误把倒影区域当成“空腔”或“不可通行区域”。这个坑到最后也没完全消除只能通过训练数据里加入大量反光地面的标注样本来缓解。如果你也在做这个方向强烈建议收集素材时专门拍一部分亮面地板、湿地面、阳光直射区域。3.3 OCR与文字检测门牌变导航点室内环境的文字信息密度远高于室外——门牌号、楼层号、安全出口、卫生间标识、电梯按钮上方的数字。对看得到的用户来说这些信息扫一眼就有对视障用户来说这些文字恰恰是建立空间认知的关键锚点。Lumi的OCR链路是先用一个轻量的文字区域检测模型找到画面中出现文字的区域再裁剪出来送到识别模型。PaddleOCR的Mobile系列在这个任务上表现不错实测识别中文、数字混合的门牌准确率在光线充足时能到85%以上但遇到老旧楼宇的暗色金属门牌就很吃力因为反光和磨损会让文字特征变得模糊。OCR结果接入播报系统时有个重要的细节不能直接朗读原始文字。比如识别结果是“B1 08 会议室”系统要先判断这是楼层编号还是门牌号然后转换成口语化的表达——“地下一层零八号会议室”。否则用户听的是碎片化字符理解起来反而更费劲。Lumi定义了一套很简单的规则遇到以字母B开头且后跟数字的词组自动映射成“B”楼层遇到3到5位数字断成“零几”之类的自然读法。3.4 单目深度估计不用额外硬件测距离测距这个需求很多人第一反应是用ToF或者双目摄像头。但普通手机没有ToF双目需要两个同步摄像头在移动端实现起来成本高、标定麻烦。Lumi最后走的是单目深度估计路线——只靠单张RGB图像推算出每个像素的深度信息。这里用的是Depth Anything系列模型精度在室内场景够用而且经过去掉离群点和时域中值滤波之后单帧噪声被大幅压低。深度估计最关键的工程问题是“绝对尺度缺失”。单目模型输出的是相对深度不是真实米数直接拿去做距离播报会给出错误信息。Lumi的校准方案是把目标检测框的已知物理高度比如门的平均高度2米、楼梯扶手高度0.9米作为锚点反推整个画面深度图的尺度系数。实测下来距离3米以内的障碍物误差能控制在10%到20%左右足够支撑“前方有障碍物”这类定性播报但离“精确到厘米”还有距离所以播报时也刻意避开了具体数字只说“近”“较近”“远”避免误导。4. 数据从哪里来公开数据集、自采与仿真增强的三板斧4.1 现有开源数据集的适配性分析训练一个面向室内无障碍的感知模型最大的痛点从来不是模型结构而是数据。公开数据集里COCO包含80类日常物体但“台阶”“坡道”“盲道”“电梯按钮”这些无障碍关键类别基本没有ADE20K有室内语义分割标注但类别粒度是“地板”“墙”“门”缺少“可通行区域”这种任务导向的语义NYU Depth V2提供了室内深度图和语义标签但采集年份较早分辨率低场景偏向大学教室和宿舍。所以Lumi的做法不是押注单个公开数据集而是把它们当作底座在上面做类别映射和清洗COCO里的“门”类和“椅子”类保留“人”类弱化ADE20K里的“地板”和“墙”映射到分割任务背景NYU Depth V2用来给深度估计模型做预训练初始化。这种方式的好处是训练成本可控坏处是清洗和映射的工程量相当大需要花几周时间才能跑通。4.2 自采数据与标注流水线公开数据之外必须自采。Lumi自采数据的原则是“场景得多、光照得乱、角度得怪”。团队在几类典型室内环境里采集大型商场、写字楼走廊、地铁站换乘通道、老旧居民楼。每个场景分成三个时段拍摄白天靠窗区域、阴天走廊、晚上低照度区域。这样采集的数据才能覆盖室内光照变化的大半部分。设备挂载方式会影响数据分布采集时也做了两种一种是把手机夹在肩带或胸前支架上模拟真实用户佩戴另一种是手持低角度拍摄模拟盲杖用户习惯性低头看路的状态。标注工具用的是CVAT配合SAM做预标注能省不少人力但还是需要一个专门的质检环节因为SAM在门缝和玻璃反光处会画出大量错误掩膜。标标注规范里有条特殊要求玻璃门必须单独标“透明门”这个类别因为它是单靠语义分割最容易漏掉的障碍物。4.3 数据增强策略从亮度扰动到场景合成数据增强是室内数据不足时最有效的补充手段。Lumi把增强分成两层一层是传统的像素级增强包括亮度扰动、对比度变化、高斯模糊和随机色温偏移用来模拟室内不同照明条件另一层是几何增强比如随机水平翻转、小角度旋转、随机缩放让模型对视角变化更鲁棒。传统增强只能把已有数据“变着花样用”真正的增量来自合成数据。Lumi尝试过用BlenderProc在程序化生成的室内场景里渲染大量图像自动产出检测框、分割掩膜和深度图。合成数据最大的问题是域差异——渲染出来的材质、光照和真实室内环境有明显不同直接把合成数据放进训练集模型精度可能反而下降。实际有效的做法是“合成数据预训练 真实数据微调”而且合成数据的占比不要超过30%。如果你打算走这条路我建议在Blender里大量使用PBR材质并把光照场景设置成混合光源减少后期迁移难度。5. 把模型塞进手机量化、剪枝与推理调度的实战记录5.1 部署框架选型ONNX Runtime与TensorFlow Lite的对比模型训练完之后部署环节是另一个战场。Lumi最初在ONNX Runtime和TensorFlow Lite之间纠结了挺久最后选了ONNX Runtime Mobile。直接说结论如果你的模型链路来自PyTorch生态ONNX Runtime的转换路径最顺从torch导出到onnx几乎是零成本TensorFlow Lite在TFLite格式下也支持PyTorch转换但中间隔了一层遇到自定义算子时排查起来很麻烦。维度ONNX Runtime MobileTensorFlow LitePyTorch模型迁移直接导出onnx需先转onnx再转tflite算子覆盖较全动态shape支持好部分动态层需要约定shape量化工具动态/静态/混合量化QAT与PTQ支持好移动端兼容Android/iOS都有成熟APIAndroid优先iOS略弱多模型并发支持多session隔离需要自行管理解释器实例真正影响选择的是多模型并发场景。Lumi的管线上要跑四个模型如果用TFLite多个解释器实例对线程池的争抢会更明显ONNX Runtime的多session管理更干净可以给不同模型分配不同的CPU线程数实际体验更稳。5.2 INT8量化后的精度测试哪个模型可以忍模型参数量大的问题在手机端必须靠量化解决。Lumi做了INT8静态量化用500张校准图片确定每个激活层的动态范围。量化前先测了一遍原始FP32精度作为基线量化后再测一遍。检测模型YOLOv8n的mAP从0.482降到0.464掉了大约1.8个点室内场景里直观感受是检测框抖动变多但关键类别门、楼梯的召回率基本没变可以接受。分割模型LRASPP的mIOU从0.743降到0.716掉了2.7个点主要影响的是玻璃区域的分类边界边缘更毛糙但不影响“可通行区域”判断。深度估计模型是量化中损失最大的因为深度输出本身是稠密连续值量化后边缘细节有明显损失但经过去离群点和时域平滑后可用的测距精度保住了。这里有个经验量化校准集的选取一定要贴近真实使用场景这里我们一开始用了全白天数据做校准结果量化后的模型在晚上低光环境下分割效果明显变差后来改成白天晚上各一半的校准集问题就缓解了。5.3 多任务共享算力的调度策略多模型同时跑的时候算力调度比单个模型性能更影响用户体验。Lumi最初的做法是四个模型串行跑单帧延迟接近150毫秒一秒钟只能处理六七帧而且手机发热严重。后来改成并行调度方案检测模型独占主线程分割和深度模型跑在后台线程池OCR模型在触发时临时抢占资源。这么做之后核心检测任务的帧率从7fps提回到15fps左右。一个很实用的调度技巧是引入目标跟踪。检测模型不需要每一帧都跑通过轻量的IOU跟踪器即便检测模型每隔一帧跑一次也能保持连续的目标ID和位置信息。这样分割模型有更多时间去处理精细的地面边界整体管线的延迟反而降低了。实测下来这个调度的组合拳把端到端延迟从原来的400毫秒压到了250毫秒左右对用户来说体感提升非常明显语音播报不再像“卡带”一样了。6. 交互细节与真实测试中的暗坑6.1 语音反馈的信息密度控制视觉模型输出再多信息最终能表达给用户的只有语音和振动两个通道。语音如果不节制就成了又一个“噪音轰炸机”。Lumi的语音播报策略有一个固定的优先级安全警告 路径指示 环境描述。前方有楼梯系统只说“前方三米有下行楼梯请放慢脚步”前方没有障碍时才报告“走廊直行左侧有门”供用户按需选用。信息密度控制的另一个重点是减少不必要的重复播报。同一扇门如果被连续十帧检测到系统不会重复说十遍而是等用户走过该区域后就不再提示。Lumi维护了一个简单的“最近已播报目标”队列每个目标播报一次后进入冷却时间60秒内不会再报。这套机制虽然简单但大大降低了用户的听觉疲劳感是测试中用户反馈最强烈的优化点之一。6.2 触觉编码不用耳朵也能理解环境语音反馈有一个天然的问题——声音无法在嘈杂环境中保证有效接收而且对听障用户不友好。所以振动反馈不是替代方案而是必要通道。Lumi定义了四类振动模式通过马达的节奏和持续时间来编码不同含义含义振动模式使用场景前方有障碍物停下高频连续震动触发一次检测到正前方1米内有障碍物需要转向单次长震 短暂停顿走廊尽头需要左转或右转已到达目标两次短震识别到目标门、电梯或卫生间系统错误/低电量三段式间歇震动需要用户特别注意有用户在测试后反馈他们学会这套编码之后反而比语音更依赖振动因为振动不需要切换注意力。不过振动马达的强度在不同手机上差异很大安卓手机常见的线性马达和转子马达体感完全不同设计模式时要用强度手感居中的手机实测不能只看参数。6.3 在真实楼宇测试中反复出现的问题清单Lumi做了多轮真实环境测试以下问题是反复出现、几乎每个场景都会踩到的坑列出来供大家做同类产品时提前规避玻璃门检测透明玻璃门在画面上近似“没有内容”检测模型和分割模型都可能漏检。目前处理方案是检测门框的轮廓线和把手而不是门本体。反光地板误判商场大理石地板倒映出吊灯和指示牌分割模型会把倒影区域划分成不可通行。只能通过训练数据里大量增加反光地板样本来改善。昏暗楼梯间夜间或者老旧楼宇的楼梯间光照极低检测置信度普遍下降15%到20%需要依赖深度估计的“前方突然出现阶梯状深度变化”来做兜底判断。电梯按钮太小OCR能识别楼层数字但按钮本身是密集小目标检测模型在1米外很难稳定框出。实际产品里改为提示“你的右手边是电梯面板”把精确点击交给用户完成。临时障碍物商场里的防撞柱、临时促销桌、保洁拖把车这些在训练数据里很少见检测模型容易漏。目前只能靠分割模型的“非地面区域”兜底提醒用户绕行。真实测试揭示了一个残酷的事实任何模型在实验室里的指标都不能代表实际体验。光照、视角、动态物体、特殊材料等因素叠加起来才构成用户真正面对的世界。这也是Lumi后续迭代最大的方向——不是把单个模型精度做到极致而是把多模型融合和交互反馈做得更稳定因为对使用者来说一次正确的避障提示远远胜过一百次锦上添花的环境描述。如果你正打算在室内无障碍方向做AI视觉产品我的建议是先找一栋楼、戴着眼罩走一遍你就知道哪些功能是该优先做的了。
