WiFi CSI感知与OpenHarmony融合：从人体姿态估计到智慧家居落地实践

WiFi信号穿墙而过除了承载数据还能做什么这个问题我在三年前第一次接触CSI信道状态信息采集时就想过。当时用一块开发板抓了几组原始CSI数据看着那些随人体移动而剧烈波动的子载波幅值曲线脑子里冒出的第一个念头是这东西能不能用来做人体姿态估计后来看到WiFi-DensePose这篇工作的思路把WiFi信号反射的多径效应映射到人体密集姿态确实让人眼前一亮。而OpenHarmony这两年在设备互联和分布式软总线上的推进速度很快把这两件事捏在一起做智慧家居场景的融合就成了一件很自然的事。这篇内容适合对无线感知、端侧AI部署、OpenHarmony设备开发有一定了解想动手把CSI感知能力落到实际家居场景里的朋友。我会从原理拆解讲到实操链路把踩过的坑和验证过的方案都摊开说。1. 为什么WiFi能看见人体姿态1.1 从RSSI到CSI信息粒度的质变大多数人接触WiFi感知是从RSSI接收信号强度指示开始的。RSSI就是一个标量表示接收到的信号总功率用它做人体检测本质上只能判断有没有东西挡住了信号精度非常粗糙。你在路由器旁边走动RSSI会波动但你无法从这一个数字里区分出你是站着还是蹲着更别说手臂的位置。CSI则完全不同。在OFDM正交频分复用系统里一个WiFi信道被划分成几十甚至上百个子载波每个子载波都有自己的幅值和相位。CSI就是这一组复数矩阵维度通常是天线对数 × 子载波数 × 时间采样点。以常见的Intel 5300网卡为例可以拿到30个子载波的CSI用一些支持802.11ac的开发板子载波数量能到56甚至更多。这意味着同一时刻你拿到的是几十条并行的信号切片每一条都携带了信号在传播路径上经历的反射、衍射、散射信息。人体主要由水构成对2.4GHz和5GHz的电磁波有很强的反射能力。当人站在发射端和接收端之间人体的不同部位躯干、四肢、头部会对不同子载波产生不同的多径调制。胸腔的起伏、手臂的摆动都会在CSI的幅值和相位上留下独特的指纹。WiFi-DensePose的核心洞察就在这里如果能把这种高维CSI时序信号和人体密集姿态建立映射理论上就能从WiFi信号反推出人体姿态。1.2 DensePose与CSI的映射逻辑DensePose本身是计算机视觉领域的一个任务目标是把人体二维图像上的每个像素映射到人体三维表面的对应点输出的是一个人体表面的密集对应图IUV图Index、U、V三个通道。相比传统的关键点检测只输出十几个关节坐标DensePose提供的是全身表面的稠密信息对姿态的刻画精细得多。WiFi-DensePose要做的是建立一个从CSI时序到DensePose输出的跨模态映射。这个映射的难点在于CSI是射频域的物理量DensePose是视觉域的人体表面表示两者之间没有直接的几何对应关系。目前主流做法是构造一个编码器-解码器结构编码器把CSI序列压缩成隐向量解码器再把隐向量展开成DensePose的IUV图。训练时需要用同步采集的CSI数据和视觉DensePose标注作为监督信号。这里有个关键点很多人会忽略CSI对环境的依赖极强。同一个动作在客厅和卧室采集到的CSI模式可能完全不同因为多径环境变了。所以WiFi-DensePose在实际部署时要么做环境自适应要么在目标环境里重新采集一批标定数据。我在实测中发现哪怕只是把沙发挪动半米之前训练的模型精度就会掉一截。这个特性决定了它不可能像摄像头那样即插即用必须针对具体空间做适配。1.3 智慧家居场景下CSI感知的独特价值摄像头做姿态估计已经很成熟了为什么还要用WiFi答案在隐私和覆盖。卧室、卫生间这些私密空间用户对摄像头的接受度很低。WiFi信号不采集图像只采集射频反射信息天然具备隐私友好性。而且WiFi信号能穿墙一个路由器加几个接收节点就能覆盖整套房子的多个房间不需要每个房间都装摄像头。在智慧家居里CSI感知能落地的场景包括老人跌倒检测通过姿态突变判断、睡眠姿势监测通过呼吸引起的微弱CSI波动、手势控制家电通过手部动作的CSI模式识别、以及 occupancy 检测判断房间里有没有人、有几个人。这些场景的共同点是不需要高精度的人脸或身份识别只需要姿态和动作层面的信息正好落在CSI感知的能力区间内。2. OpenHarmony在感知链路里扮演什么角色2.1 分布式软总线解决多节点CSI汇聚WiFi-DensePose的CSI采集通常需要多个接收节点因为单节点的视角有限多节点才能覆盖不同方向的人体反射。传统做法是用一台PC通过有线网络汇聚所有节点的数据部署起来很笨重。OpenHarmony的分布式软总线提供了一种更轻量的方案把每个CSI采集节点做成一个OpenHarmony设备通过软总线自动发现和组网数据可以在设备间直接流转。具体来说每个采集节点跑一个轻量级的CSI采集服务把原始CSI数据做初步的滤波和降采样然后通过分布式数据对象Distributed Data Object同步到一个主控节点。主控节点负责把多路CSI做时间对齐和空间融合再送入姿态估计模型。软总线的优势在于它屏蔽了底层传输细节节点之间可以用类似本地调用的方式交换数据省去了自己写socket通信和心跳维护的功夫。不过这里有个坑分布式软总线默认的传输优先级是面向控制指令的大数据量的CSI流如果直接走默认通道延迟会比较高。我的做法是把CSI数据做分片每片控制在几KB然后用可靠传输模式实测下来端到端延迟能压到50ms以内对于姿态估计这种准实时场景够用了。2.2 LiteOS-M在采集端的低功耗优势CSI采集节点如果是电池供电的功耗就是硬约束。OpenHarmony生态里的LiteOS-M内核面向轻量级设备内存占用可以做到几KB级别非常适合做CSI采集这种采集-预处理-发送的简单任务。我在一块基于LiteOS-M的开发板上做过测试采集端只做CSI原始数据读取和简单的滑动平均滤波CPU占用率不到15%配合低功耗WiFi模组用两节AA电池能撑好几天。这里要注意的是LiteOS-M上跑不了复杂的神经网络推理所以姿态估计的重活必须放在主控节点或者边缘服务器上。采集端的定位就是哑终端只负责把干净的CSI数据传出去不做任何智能判断。这种分工在工程上更稳妥也更容易做故障隔离——某个采集节点挂了换一个就行不影响整个系统。2.3 设备兼容性测评带来的选型约束OpenHarmony的设备兼容性测评XTS测试对能接入生态的设备有明确要求。如果你打算用现成的OpenHarmony开发板做CSI采集选型时一定要先确认它是否通过了兼容性测评以及它的WiFi模组是否开放了CSI获取接口。很多开发板的WiFi驱动是闭源的根本不给你CSI数据这种板子买回来就是废的。我踩过的坑是某款宣称支持OpenHarmony的开发板WiFi模组用的是某厂商的闭源固件虽然能正常联网但CSI接口被锁死了只能拿到RSSI。后来换了一款基于开源WiFi驱动的板子才顺利拿到CSI。所以选型时的第一件事不是看CPU多强、内存多大而是确认CSI接口是否可用。这个信息在开发板的规格书里通常不会写得去社区或者直接问厂商FAE。3. 从CSI原始数据到姿态输出的完整链路3.1 CSI数据采集与预处理拿到CSI原始数据后第一步是预处理。原始CSI里混杂了大量噪声发射端的功率波动、接收端的AGC自动增益控制调整、以及环境里的其他WiFi设备干扰。如果不做处理直接送进模型精度会很差。预处理的标准流程是先用Hampel滤波器去除脉冲噪声那些突然跳变的异常值然后做相位解缠因为CSI相位是卷绕在[-π, π]之间的直接使用会引入跳变接着用滑动窗口做时间维度的平滑。相位这块特别关键很多初学者直接拿原始相位去训练结果模型完全学不到东西就是因为相位卷绕把有效信息破坏了。采样率的选择也有讲究。人体动作的主要频率成分在0.5Hz到10Hz之间根据奈奎斯特采样定理采样率至少要20Hz。但实际中为了捕捉快速动作比如挥手我一般会把采样率设到50Hz到100Hz。代价是数据量变大对传输和存储的压力增加。折中方案是采集端做50Hz采样但在发送前做一次降采样到25Hz这样既保留了动作细节又控制了数据量。3.2 多节点CSI的时间对齐与空间融合多节点采集最大的问题是时间不同步。每个节点的本地时钟有漂移如果不做对齐融合出来的CSI会错位姿态估计就会抖动。我的做法是在每个采集节点上跑一个轻量的NTP客户端定期和主控节点对时把时钟偏差控制在1ms以内。然后在主控节点上用一个参考信号比如所有节点都能收到的某个AP的beacon帧做粗对齐再用互相关做精对齐。空间融合的思路是把多个节点的CSI拼成一个更大的特征矩阵。假设有3个接收节点每个节点有30个子载波融合后的特征维度就是90。但直接拼接效果不好因为不同节点的信道特性不同。更好的做法是先对每个节点的CSI做独立的特征提取然后在特征层面做融合。我试过用注意力机制让模型自己学习不同节点的权重效果比简单拼接好不少尤其是在某个节点被遮挡的情况下模型能自动降低该节点的权重。3.3 姿态估计模型的端侧部署模型训练通常在PC或服务器上完成但推理要放到OpenHarmony主控节点上。这就涉及模型压缩和端侧部署。WiFi-DensePose的原始模型参数量不小直接搬到端侧不现实。我的做法是先用知识蒸馏把大模型的能力迁移到一个小模型上然后对小模型做INT8量化最后用OpenHarmony的AI推理框架加载。量化这一步要小心CSI特征的动态范围比较大如果量化参数选得不好精度会掉得很厉害。我的经验是先用一批标定数据统计CSI特征的分布然后根据分布来确定量化的scale和zero_point而不是用默认参数。实测下来经过精细量化的模型精度损失能控制在3%以内而模型体积缩小到原来的四分之一推理速度提升了两倍多。4. 实测中那些文档不会告诉你的坑4.1 环境变化导致的模型失效前面提过CSI对环境极度敏感但实际影响比想象中更大。我在一个客厅场景里训练好的模型白天用着好好的晚上开了灯之后精度就掉了。一开始以为是巧合后来排查发现是灯光的变化影响了WiFi信号的反射特性——虽然灯光本身不发射2.4GHz信号但灯具的金属外壳和位置改变了多径环境。解决办法有两个方向一是做在线自适应让模型在运行过程中根据CSI的统计特性变化动态调整二是做数据增强在训练时人为加入各种环境扰动的模拟数据。我目前用的是混合方案模型里加一个轻量的环境编码器把当前CSI的统计特征均值、方差、峰度编码成一个环境向量姿态解码器根据这个向量做条件生成。这样模型对环境的鲁棒性好了很多但代价是训练复杂度上升。4.2 多人场景下的信号混叠单人姿态估计相对好做多人场景就麻烦了。多个人体的反射信号在CSI里混叠在一起模型很难区分哪个反射来自哪个人。目前学术界有一些尝试比如用盲源分离先把不同人的信号分开但效果都不太理想尤其是在人挨得比较近的时候。我的务实做法是在智慧家居场景里先做人数检测如果检测到多人就退化成区域占用粗略动作的输出不强行做每个人的精细姿态。等人数降到一人时再切换到精细姿态估计模式。这种降级策略在实际产品里比追求多人精细姿态更靠谱因为用户真正需要的往往不是每个人的精确姿态而是房间里有没有人、在做什么这种粗粒度信息。4.3 采集节点的布放位置CSI采集节点的位置对精度影响巨大。理想情况下接收节点应该分布在人体的不同方向这样才能捕捉到不同角度的反射。但实际家居环境里插座位置、家具遮挡都会限制布放。我试过几种典型布局把接收节点放在房间的四个角精度最好放在同一面墙上精度明显下降因为所有节点看到的人体反射角度太接近。一个实用的技巧是至少保证有一个接收节点和发射节点之间没有直射路径NLOS因为NLOS路径上的CSI对人体反射更敏感。如果所有节点都是直射路径人体反射会被直射信号淹没。我在一个L形客厅里把发射节点放在一端两个接收节点分别放在直射路径和拐角后的NLOS路径上融合后的精度比全直射布局提升了将近20%。5. 把感知能力接入OpenHarmony应用层5.1 用分布式数据对象做姿态结果分发姿态估计的结果最终要送到应用层去消费比如触发灯光调节、空调风向调整、或者跌倒报警。OpenHarmony的分布式数据对象很适合做这件事主控节点把姿态结果写成一个分布式数据对象订阅了这个对象的应用就能自动收到更新不需要自己维护通信连接。具体实现上我把姿态结果封装成一个结构体包含时间戳、人数、每个人的关键点坐标和置信度。这个结构体序列化后写入分布式数据对象应用层通过监听数据变更事件来获取最新姿态。实测下来从姿态估计完成到应用层收到更新延迟在20ms左右对于家居控制场景完全够用。5.2 原子化服务封装感知能力OpenHarmony的原子化服务Atomic Service是一种轻量级的服务形态不需要安装就能使用。我把CSI感知能力封装成一个原子化服务其他应用通过服务卡片就能调用姿态估计功能不需要关心底层的CSI采集和模型推理细节。这样做的好处是解耦感知能力的升级不影响上层应用上层应用的迭代也不需要重新适配感知接口。封装时要注意接口的粒度。太细的接口比如暴露原始CSI数据会让上层应用负担很重太粗的接口比如只给一个有人/没人的布尔值又限制了应用场景。我目前提供的接口包括人数检测、人体包围盒、关键点坐标、动作分类结果。这几个接口覆盖了大部分家居场景的需求同时保持了足够的抽象层次。5.3 隐私保护的设计考量虽然CSI不采集图像但它仍然是一种感知数据涉及隐私。我在设计时遵循几个原则第一原始CSI数据只在采集节点和主控节点之间传输不上云第二姿态结果在本地消费不存储原始数据第三提供物理开关用户可以通过一个硬件按钮彻底切断CSI采集。另外CSI数据本身虽然不包含图像但理论上可以通过分析CSI的变化反推出一些敏感信息比如用户的作息规律。所以我在数据留存策略上做了限制姿态结果只保留最近5分钟用于实时控制历史数据只保留聚合后的统计信息比如今天下午3点到4点客厅有人不保留逐帧的姿态数据。6. 性能调优与稳定性保障6.1 推理延迟的优化路径端侧推理延迟直接影响用户体验。我实测下来一个未经优化的模型在OpenHarmony主控节点上推理一帧要80ms左右加上CSI采集和传输的延迟端到端超过150ms做实时手势控制就有点卡。优化路径有几条模型量化前面提过能提速两倍多、算子融合把连续的卷积和激活函数合并成一个算子、以及多线程流水线采集、预处理、推理分到不同线程重叠执行。我最终把端到端延迟压到了60ms左右具体做法是采集端50Hz采样每20ms发一批数据主控节点收到后立即做预处理和推理推理和下一批数据的接收并行进行。这样流水线跑起来之后吞吐量上去了单帧延迟也降下来了。6.2 长时间运行的稳定性问题CSI感知系统需要7×24小时运行稳定性比峰值性能更重要。我遇到过几个稳定性问题一是内存泄漏跑几天之后主控节点内存耗尽二是WiFi模组过热导致CSI采集中断三是分布式软总线的连接在路由器重启后没有自动恢复。内存泄漏的排查花了不少时间最后定位到是CSI数据缓冲区没有及时释放。修复方法是在每次推理完成后显式释放缓冲区并加一个内存监控线程超过阈值就触发垃圾回收。WiFi模组过热的问题通过加散热片和降低采样率缓解。软总线重连的问题需要在应用层加一个心跳检测发现连接断了就主动重新组网。6.3 精度与功耗的平衡采集节点的功耗和精度是一对矛盾。采样率越高、发送越频繁精度越好但功耗也越大。我在电池供电的节点上做了一个自适应策略当检测到房间没人时采样率降到10Hz发送间隔拉长到1秒当检测到有人时自动升到50Hz。这样在保证有人时精度的同时没人时把功耗降到最低。实测下来电池寿命从原来的2天延长到了7天左右。这个自适应策略的关键是有人/没人的检测要足够轻量不能依赖复杂的模型。我用的是一个基于CSI方差阈值的简单检测器计算量极小在LiteOS-M上跑毫无压力。虽然偶尔会有误判比如窗帘飘动引起的CSI波动但配合一个短时间的确认窗口误判率可以控制在可接受范围内。7. 这套方案还能往哪些方向延伸7.1 从姿态到行为理解的跃迁姿态估计只是第一步更有价值的是行为理解。比如从手臂抬起的姿态序列推断出在喝水或在打电话这样的高层行为。这需要在姿态估计之上再加一层时序模型把姿态序列映射到行为标签。我目前在做的一个尝试是用一个轻量的时序卷积网络输入是最近2秒的姿态关键点序列输出是行为分类结果。初步测试下来对喝水看手机起身这几个常见行为的识别准确率能到85%以上。行为理解的价值在于它能驱动更智能的家居控制。比如识别到在看手机自动把灯光调暗识别到在吃饭自动打开餐厅的换气扇。这些场景比单纯的姿态显示有用得多也更接近用户真正愿意买单的功能。7.2 多模态融合的可能性CSI感知有它的局限空间分辨率不如摄像头对细微动作的捕捉能力有限。如果能和摄像头、毫米波雷达等其他传感器融合就能互补短板。比如用摄像头做高精度的姿态估计用CSI做隐私敏感区域的覆盖用毫米波雷达做穿墙检测。OpenHarmony的分布式能力正好适合做这种多模态融合不同传感器作为不同的设备接入数据在软总线上汇聚。融合的难点在于时间对齐和置信度加权。不同传感器的采样率和延迟不同需要做精细的时间同步。置信度加权则需要根据场景动态调整比如在光线好的时候多用摄像头光线差的时候多用CSI。这块我还在探索阶段目前只做了CSI和毫米波雷达的简单融合效果比单模态有提升但离产品化还有距离。7.3 端侧模型持续学习的工程挑战环境会变模型也需要跟着变。理想情况下系统能在运行过程中持续学习自动适应环境变化。但端侧持续学习有几个工程挑战一是计算资源有限不能做大规模的反向传播二是需要解决灾难性遗忘学了新环境不能忘了旧环境三是需要设计合理的触发机制什么时候该学、什么时候不该学。我目前的方案是做一个轻量的在线微调只更新模型的最后一层用最近采集的数据做小批量梯度下降。触发条件是检测到CSI统计特性发生显著变化比如均值偏移超过阈值。这个方案能在一定程度上适应环境变化但效果有限更彻底的方案还需要进一步研究。这套WiFi-DensePose和OpenHarmony的融合方案我从最初的概念验证做到现在能稳定跑起来前后花了大概半年时间。最大的体会是射频感知和视觉感知的差距比想象中大不能简单地把视觉领域的方案搬过来用。CSI有它自己的物理特性必须尊重这些特性来设计算法和系统。另外OpenHarmony的分布式能力确实能简化多节点系统的开发但前提是你要把设备选型和接口设计做扎实否则后面会踩很多不必要的坑。如果你也在做类似的方向建议先从单节点、单场景做起把CSI采集和预处理的链路跑通再逐步扩展到多节点和多场景。