做无障碍辅助这类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 Mobile | TensorFlow Lite |
|---|---|---|
| PyTorch模型迁移 | 直接导出onnx | 需先转onnx再转tflite |
| 算子覆盖 | 较全，动态shape支持好 | 部分动态层需要约定shape |
| 量化工具 | 动态/静态/混合量化 | QAT与PTQ支持好 |
| 移动端兼容 | Android/iOS都有成熟API | Android优先，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视觉产品，我的建议是先找一栋楼、戴着眼罩走一遍，你就知道哪些功能是该优先做的了。
