大概一年多前我陪一位视障朋友走了段夜路。他拄着盲杖走得小心但路边一个被风吹倒的共享单车他还是差点撞上去。那一刻我意识到盲杖能探测地面却探测不了齐腰高的障碍物。后来我查了很多资料发现市面上并非没有辅助设备但要么贵得离谱要么笨重得像科幻道具。于是我做了一个叫My Eye的原型项目本质上是一台 AI 驱动的穿戴式设备挂在胸前或别在领口通过摄像头实时感知周围环境再把关键信息通过骨传导耳机小声地告诉他。这篇文章我想把这个项目的完整思路、硬件选型、模型部署、交互设计以及我踩过的各种坑原原本本拆给你们。无论是想给家人朋友做一个还是对边缘 AI 穿戴设备感兴趣希望这篇能给你一些能直接落地的参考而不是停留在概念上的演示PPT。1. 项目整体设计与思路拆解1.1 核心需求解析视障者需要的不是超能力而是安全感做这类项目最容易犯的错就是把识别的能力和需要的能力画等号。技术圈的人拿到摄像头和模型往往本能地想把它做成一个万物识别机恨不得把看到的所有东西都报出来。但真实用户场景里视障朋友需要的不是你告诉我面前有二十样东西而是哪样东西会让我绊倒、撞到、走错方向。所以我定义的核心需求优先级很明确第一是安全规避第二是空间理解第三才是信息获取。安全规避就是我朋友遇到的那种场景胸前的小盒子要在几百毫秒内告诉他左前方 1.2 米有一辆倒地的共享单车注意绕行。空间理解是说清楚台阶、斜坡、电梯门的开关状态这种会直接影响移动路线的信息。第三类信息获取比如前面的门牌号是多少、这瓶药的说明书上写着什么这些对行走安全并非必须但对独立生活至关重要。三类需求的处理频率和优先级是逐级递减的这直接影响后面模型的任务分配。这个需求排序也决定了整套系统不能做成全知型问答而要做成主动告警按需查询的机制。设备平时处于低功耗监听状态只有当检测到危险级别高的目标时才打断用户的听觉立即播报。普通信息不主动开口用户想查询时再按键触发。这个交互哲学是从头到尾贯穿整个项目的。另外还要明白一点视障用户的学习成本极高。他们习惯一套行动方式之后不会轻易接受需要大量操作和学习的设备。所以设备交互上我坚持只用一个物理按键长按查询双击切换模式没有任何屏幕和菜单。刚开始可能不习惯但一旦记住几乎没有退出的理由。1.2 为什么必须是穿戴式边缘AI而不是手机App云端可能有人会问现在手机拍照识别已经很成熟了为什么还要专门做穿戴设备原因有三个每一个都在真实场景里是致命的。首先是手持遮挡问题。视障用户通常一手拄盲杖一手可能要扶墙或拎东西让他在行走中一直举着手机对着前方既不安全也不现实。穿戴式设备解放双手摄像头装在胸前高度正好模拟人眼平视角度比手机随手举起来稳定得多。其次是实时性问题。手机App做云端识别一次完整的拍照→上传→推理→返回→播报耗时通常在 2 到 5 秒视障用户每秒大约走 0.8 米五秒就是四米等提示音出来人早就撞上去了。穿戴设备必须把端到端延迟压到 1 秒以内最好 500 毫秒上下。这个数字后面会详细展开。最后是隐私问题。摄像头一直在看着周围环境如果视频流不停上传云端用户心里那关就过不去。视障用户对隐私的敏感程度并不比普通人低甚至更高因为他们无法确认谁在看我的画面。边缘 AI 保证所有视觉数据在本地处理只有用户主动触发查询时才可能上传这是建立信任的基础。1.3 整体架构感知层—推理层—反馈层整套系统拆开就三大块和做互联网应用的三层架构一个道理。感知层是摄像头加 IMU惯性测量单元负责获取 RGB 画面和设备的姿态角度。推理层是边缘计算模组跑着几个轻量化神经网络负责做目标检测、深度估算、光流分析这些任务。反馈层最特殊除了骨传导耳机播报语音还有一组微型线性马达分布在锁骨下方的壳体两侧用不同的震动节奏表示左避让右避让停下。这个语音震动双通道设计很关键。纯语音的问题在于它占用的是用户的听觉通道但视障用户的听觉是用来听车流声、脚步声、红绿灯提示音的不能一直被设备的语音打断。震动可以提醒危险方向和距离不打断环境声音语音可以补充细节描述比如前方是上行的扶梯。两个通道配合才能做到既有效又安全。2. 硬件选型与穿戴式结构设计2.1 摄像头选型视角、分辨率与低光性能的取舍器材党选摄像头喜欢追高分辨率但在这个项目里分辨率恰恰不是最关键的指标。我的经验是优先保证宽动态范围和低光灵敏度再考虑视角和像素。视障用户经常在户外行走晨昏、树荫、建筑阴影这些光线剧烈变化的场景很常见。逆光的时候如果摄像头动态范围不够画面里天空中一片死白地面一团漆黑模型再强也白搭。我选型的优先顺序是这样传感器尺寸 单像素面积 宽动态范围 分辨率 视角。最终我选了 IMX317 传感器方案的模组1/2.8 英寸支持 HDR分辨率在视频模式下跑 1920x1080 足够。有人问为什么不上 4K道理很简单4K 帧率上不去推理延迟吃不消而 1080P 下目标检测任务完全够用。至于视角一开始我选了 120 度超广角后来发现畸变严重边缘物体检测不稳定换回 90 度主流视角后才正常。建议大家不要盲目迷信广角。2.2 边缘计算平台的选择算力、功耗和生态的综合博弈推理层是整个设备的大脑选型过程我前后对比了三家方案NVIDIA Jetson Nano、Google Coral、以及基于瑞芯微 RK3588 的国产模组。差异非常明显。用 Jetson Nano 做原型开发最舒服CUDA 生态成熟到几乎任何模型都能跑但功耗太难看官方标称 5-10W实际满载轻松吃满 15W。对于一台挂在胸前的小设备来说这就意味着要么挂个充电宝似的电池包要么半小时烫得没法贴身佩戴。Google Coral 的 Edge TPU 算力功耗比确实漂亮跑 MobileNet 系列非常快但问题出在工具链封闭很多在 PyTorch 里训练好的模型转成 TFLite 再转 Edge TPU 编译经常因为算子不支持卡壳。对快速迭代的原型项目来说这种模型天花板太憋屈。最后选瑞芯微 RK3588八核 A76A55 架构内置 6 TOPS 算力的 NPU还有独立的 ISP图像信号处理器。最关键的是它支持混合精度推理INT8 和 FP16 可以混着跑。功耗实测整板约 4-6W比 Jetson Nano 低不少而且提供了 MIPI CSI 摄像头接口直连不需要 USB 转接省掉一个瓶颈。这块板子的软件文档虽然比不上英伟达但近两年生态进展很快我用的 RKNN-Toolkit2 已经能比较丝滑地完成大多数视觉模型转换。2.3 交互与续航骨传导、震动马达与电源管理细节输出硬件上骨传导耳机是首选。普通入耳式耳机把耳朵堵住等于把环境音都屏蔽了对视障用户来说这是非常危险的。骨传导通过颅骨振动传递声音外耳道保持开放能同时听到语音提示和周围环境声。市面上几百块的骨传导运动耳机就能用蓝牙 5.0 低延迟模式下实测音频延迟可以做到 100 毫秒以内不影响交互体验。震动马达选了扁平线性马达和手机震动同款安装在壳体正面内侧左右各一个。左边震动表示障碍物在左侧方向右边震动表示右侧双边同时快速震动表示必须立即停止。由于贴身穿戴马达的振幅不用太大3.3V 驱动下做到 1.0G 左右的加速度即可太大反而会让用户无所适从。电源部分是整机设计里最吃劲的。RK3588 启动峰值功耗接近 15W正常用 5W 上下摄像头加模组加耳机整机额定功耗大约 6-7W。我配了两节 18650 电池共约 5000mAh放在一个独立的小腰包里通过一节 Type-C 线连接到主机。这样电池离开发热源也方便换电。实际测试待机 6-8 小时纯连续推理 3 小时左右。这个结果能接受但不理想后面优化方向是从 NPU 动态调频入手跑轻量级任务时主动降频。3. 软件核心多任务视觉感知与实时推理链路3.1 模型选型不止一个模型而是一条任务管线很多人以为一个大模型能包打天下但在边缘设备上这么做既不经济也不现实。我的做法是拆分任务各用最优的小模型。第一路是障碍物检测用 YOLOv5s 或者 YOLOv8n 这类轻量目标检测网络训练数据融合了 COCO 里的 person、bicycle、bench、traffic light 这些高风险类别另外我自己采集了一批共享单车倒地施工路障玻璃门这些本地化场景补充进去。这一步输出的是类别边框置信度用于实时避让。第二路是深度估算用了基于 MobileNet 做编码器的自监督单目深度模型不需要昂贵的深度摄像头只依赖 RGB 图像就能估算每个像素的大致距离。虽然绝对精度比不上 LiDAR但判别人与障碍物的空间远近、识别盲道边缘和台阶足够了。它的作用是把检测框变成可行动的引导光知道前面有东西不够还要知道东西在三米外还是三十公分外。第三路是文本识别PP-OCR 的轻量版 pico 模型用在用户主动查询模式下。摄像头对准一栋楼的门牌或者一盒药的包装模型把文字区域识别成文本再通过 TTS 播报出来。三路模型之间不是串行跑的而是并行调度。NPU 支持多任务并发我在 RKNN 的调度里给障碍物检测分配最高优先级固定占用一部分算力深度估算在中优先级文本识别只在被查询时才启动。这个分工让整体 FPS 维持在了每秒钟 15-20 帧已经完全满足佩戴行走的需要。3.2 模型轻量化的关键操作剪枝、量化和算子适配模型从服务器级训练环境搬到 NPU 上跑最核心的操作是量化。训练用 FP32 精度的 PyTorch 模型转成 RKNN 格式时默认是 INT8 量化。我踩过一个大坑一上来直接把所有层都量化成 INT8跑检测任务时模型精度掉得厉害原来能检出的目标尤其是小目标直接消失。排查后发现罪魁祸首是每个层的量化敏感度不一样。检测头的最后一层卷积以及和坐标回归相关的全连接层对数值精度极其敏感一旦强行 INT8输出的边框直接歪掉。解决办法是对这些敏感层单独跳过量化保持 FP16 精度其余卷积层做 INT8。在 RKNN-Toolkit2 里这对应混合量化配置操作上就是把某些层的quantized_dtype显式指定为float16。另外一个容易被忽视的点是算子兼容性。PyTorch 里很常用的torch.stack、torch.view在 NPU 上不一定有原生实现转模型时 RKNN 工具链会自动插入一些 CPU 辅助算子。如果这些算子排在推理热路径上性能会暴跌几十毫秒。我的经验是转完模型后跑一遍 profiling把所有非 NPU 的算子都找出来回 PyTorch 侧用更底层的方式改写脚本结构比如把stack操作移动到后处理阶段用 numpy 做这样 NPU 上就是纯卷积和激活函数了。3.3 延迟预算拆解从摄像头曝光到声音播放花了多少毫秒很多人做穿戴设备只看模型推理时间这是典型的本末倒置。端到端延迟是整条链路的总和我实际一帧数据跑下来的时间分配是这样的摄像头曝光加 ISP 处理约 33ms30 帧模式轮到处理的哪一帧本身已经等了 16ms图像预处理缩放、归一化、通道重排8ms用 RGA 硬件加速模块CPU 绕开NPU 推理障碍物检测耗时约 75ms深度估算约 120ms两个并行取瓶颈快的是 120ms后处理加决策逻辑20ms包括 NMS、深度值聚合、距离换算TTS 合成与播放220ms这是整条链路里最大的瓶颈加起来单帧处理乐观估计约 300ms 出头但如果从用户环境变化到提示音入耳还要算上摄像头采集间隔和排队的等待实际端到端约 450ms 左右。这个水平满足500 毫秒内告警的设计目标。如果想再压低延迟下一步可以直接优化 TTS 模块选更快的中文语音合成引擎或者用预录制短语拼接的方式绕开实时合成。预录制短语的问题是灵活度差但延迟能降到 80ms 以内自己做原型时可以按场景权衡。3.4 主动告警决策如何避免狼来了式的信息轰炸信息的价值不在于多而在于在正确的时机打断用户。一开始我的告警逻辑很粗暴检测到一个人就播报前方有人检测到一辆车也播报结果在稍微热闹一点的街道上设备几乎每隔十几秒就响一次朋友直接吐槽像坐进了一台失控的扶梯。后来我把告警策略改成**基于碰撞时间TTC的分级触发**。TTC 不是简单的距离而是距离与相对速度的比值。如果目标在 5 米外静止TTC 很大不播报如果目标在 3 米外且用户正朝它靠近相对速度明显TTC 小于 2 秒就触发低级震动如果 TTC 小于 1 秒立即全频报警加语音停下。这个算法不复杂但效果天壤之别设备终于从话痨变成了靠谱的安全员。触发后还有一个**确认即沉默**机制用户听到提示后如果按下确认键表示我知道了设备针对这个目标短暂静默 30 秒避免同一障碍物反复提醒。如果用户不确认则 5 秒后再次播报一次。这些交互细节决定了真实可用性建议大家认真对待而不是把模型结果原样抛给用户。4. 音频交互与穿戴体验的实战打磨4.1 空间音频反馈左耳与右耳不再只是一个声道一开始接到骨传导之后我就是普通地做双声道音频播报。后来发现一个细节普通耳机的左右声道映射到骨传导耳机后左右感会弱很多因为传输方式不同声像定位不如常规耳机精准。于是我用软件给声音加上了简单的 HRTF头部相关传输函数滤波让提示音听起来来自特定方向左侧的障碍物听起来就在左侧。这个方向感的提升对使用体验是巨大的。用户不用先花时间理解左前方这个词他的空间直觉直接告诉他该往哪偏一点。实测下来加了 HRTF 之后用户躲避障碍物的反应速度提高了约 40%。代价是算法层面多了一次卷积处理但音频采样率只有 48kHz单帧音频的数据量远小于图像所以延迟几乎可以不考虑。4.2 语音内容的表达习惯短句、动词开头、具体方向语音播报不是聊天它是行动指令。AI 生成的文本如果表述啰嗦用户走三步了还没听完重点就失去了意义。我在反复测试中总结了一套自己的播报模板效果很好。原则是动词开头、方向紧随、距离在 3 米内报出、物体类别最后补充。举个对比。系统原来会说检测到正前方约两米处有一辆倒在地上的共享单车请小心绕行。优化后变成停左前方一米单车。前者信息全但需要 3 秒才能听完后者 1.5 秒内听清用户能立刻反应。当然停这种紧急指令针对的是 TTC 小于 1 秒的高危场景中低优先级仍然保留完整的描述性句子比如前方右侧 5 米有下行楼梯。语音内容不能做句句关键而是该简短时简短该描述时描述。这个分寸需要在实际路测中反复调。做这类项目的朋友建议找真人用户试听各种播报模板而不是工程师自己猜。4.3 整机散热与佩戴稳定性被低估的工程难点穿戴设备的工程难点往往不在功能实现而在细节到让人忽略的舒适性。RK3588 满载时芯片表面温度能到 70 摄氏度以上隔着外壳都能感觉到明显的发热贴身佩戴会有灼烧感。这个我在 V1 版本上吃过苦头当时朋友戴出去走二十多分钟就跑回来把设备摘了。V2 我做了三件事解决加了一块铜均热板贴在芯片背面把热量传导到外壳上半部扩大散热面积外壳侧面开了辅助散热格栅利用自然对流限制 NPU 连续满载运行时自动降频到 60% 性能。最终表面温度控制在 42 度以下夏天长时间佩戴勉强可以接受。佩戴稳定性同样关键。设备挂在胸前走路时会随着身体晃动画面抖动会让深度估算结果跳变严重的还会让检测框漂移。我调了 IMU 的六轴数据做被动防抖以 200Hz 频率采样在帧输出时利用姿态角做简单的坐标补偿。最直接的方法则是机械层面的壳体内壁加了一块配重把重心压向人体一侧这样走路晃动幅度明显减小。很多看似软件的问题最后是靠机械设计解决的这点挺值得注意。5. 常见问题与排查技巧实录5.1 模型转换后在 NPU 上精度暴跌这个问题我前面在量化部分提过这里再单列出来因为它是复现率最高的问题。排查步骤可以这样分先用单张测试图对比 PyTorch FP32 输出和 RKNN 输出的差异看是分类错还是边框偏。分类错大概率是 BN 层折叠出问题需要在转换前把 BN 层转到卷积里再导出。边框偏大概率是检测头的量化太激进改成混合精度即可。还有一个小技巧NPU 推理输出前先跑一次 CPU 上相同的后处理逻辑确定差异是模型计算引入还是后处理引入。很多时候问题出在你自己写的前后处理精度上比如归一化参数搞错了。5.2 行走时识别结果跳变不稳定识别结果时有时无这通常不是模型的问题而是画面模糊或目标尺度剧烈变化导致的。解决思路有两条路。第一在算法层面对齐多帧检测结果用跟踪算法ByteTrack 这类轻量版给同一目标分配稳定的 ID并用历史轨迹预测下一帧的位置即使有一两帧漏检也能保持输出。第二在设备层检查摄像头快门速度。户外光线强时摄像头自动曝光会倾向短快门图像更清晰但视障场景很多是室内和傍晚光线不足时自动曝光会把 ISO 拉高帧间噪声变大。我在固件里把 ISO 上限限制在 800 以内配合 ISP 的降噪功能稳定性提升明显。这种问题最后都是系统问题不是单一模块的锅。5.3 骨传导耳机连接不稳定导致提示音断续蓝牙耳机配对手机一般没问题但嵌入式 Linux 主板的蓝牙连接容易受到干扰。一开始我以为是耳机问题后来用频谱仪扫发现是主板上的 MIPI CSI 信号对 2.4G 频段产生了电磁干扰。解决办法是在 MIPI 排线外层贴了铜箔胶带接地蓝牙天线的位置从主板底部移到了壳体上方。硬件干扰处理完后蓝牙连接就稳定多了。如果不想深究硬件也可以先用有线骨传导耳机顶着虽然多一根线但可靠性最高。5.4 电池续航焦虑标称 3 小时够用但实际只有 2 小时电池标称值和实际值之间的落差是行业通病。我的设备标称 3 小时但在冬天户外实测只有 2 小时出头原因是低温导致锂电池活性下降电压压降加快系统在低于 3.5V 时触发低电压保护直接关机。续航焦虑对穿戴设备来说是致命的因为用户出远门一次可能就是大半天。我现在在考虑双电池热切换方案一块没电时无缝切到另一块并且系统加了一种极简模式关闭深度估算只保留障碍物检测整机功耗能降到 3W 左右续航直接翻倍。紧急情况下这比性能重要得多。6. 项目迭代展望与个人总结My Eye 做到 V3 版本我最大的感受是这项目的技术难点不在于某个模型精度做到多高而在于把一堆八十分的技术组装成一个九十分的系统。摄像头选型、NPU 部署、告警策略、骨传导交互、散热结构每个单点都有成熟方案但把它们拧在一起之后处处都是意想不到的问题。做工程师的人很容易陷入优化模型 mAP 0.5 个点的执念但真实用户根本不在乎 mAP 提升了多少他只在乎提示音来不来得及、准不准、烦不烦。后续我想往两个方向试着扩展。第一是给设备加入简单的导航能力利用 IMU 做航位推算结合用户预先设置的终点在路口提供转向提示。视觉加上惯性导航本质上就是给视障朋友做一套低成本、本地化的地图大脑。第二是把告警模型扩展成环境语义结构的概念不只是识别有哪些物体而是理解这条路可不可以走、该靠左还是靠右这对长距离户外行走更有价值。最后再分享一个小经验这类设备做原型容易做产品难。原型的重点永远是让用户真实戴着走一次而且是从早上走到晚上而不是在办公室里对着演示视频反复看。只有真实的长期佩戴才会暴露散热、续航、误报、电池低温衰减这些教科书不写的问题。做 AI 辅助设备最大的敬畏心就是别把用户当测试用例。