RuView：用 WiFi 信号做无摄像头空间感知的开源平台

RuView 是 ruvnet 开源的 WiFi 空间感知平台。

它的目标很有想象力：不用摄像头、不用可穿戴设备，只依赖普通 WiFi 信号和低成本 ESP32-S3 传感节点，从 Channel State Information，也就是 CSI，里提取人体存在、移动、呼吸、心率、活动模式、房间状态和姿态估计信息。

项目地址：https://github.com/ruvnet/RuView

先说结论

RuView 值得关注，但也要冷静看待。

它不是一个普通 Web 应用，也不是装上 Docker 就能直接“看穿墙”的成品监控系统。更准确地说，RuView 是一个围绕 WiFi CSI、ESP32-S3、边缘推理、空间感知和多模态融合的研究型开源平台。

它适合这些场景：

学习 WiFi CSI 感知和无线信号处理。
用 ESP32-S3 做存在检测、动作检测和生命体征原型。
研究无摄像头空间感知方案。
探索养老、医疗、智能建筑、零售客流、安防、机器人安全等边缘感知应用。
在隐私敏感场景里测试“非视频感知”的可能性。

它暂时不适合这些期待：

买一块板子就稳定替代医疗设备。
单个 ESP32 节点实现高精度室内三维定位。
在任意房间里无调参、无校准地精确识别每个人。
用 RSSI 普通 WiFi 笔记本获得完整 CSI 能力。
把 beta 项目直接部署到高风险生产场景。

项目 README 也明确提醒：RuView 仍是 beta 软件，API 和固件可能变化；ESP32-C3 和原版 ESP32 不支持；单 ESP32 部署空间分辨率有限；无摄像头姿态估计精度也有明显限制。

RuView 是什么

RuView 的核心思路是把 WiFi 信号当成空间传感器。

WiFi 路由器会在空间里持续发射无线电波。人体移动、呼吸、坐下、起身，都会让这些信号发生细微变化。传统 WiFi 主要关心“能不能联网”和“信号强不强”，而 RuView 关注的是更底层的 Channel State Information。

CSI 可以理解为无线链路在不同子载波、不同时间点上的细粒度状态。相比普通 RSSI，CSI 信息量更大，可以用于分析：

房间里有没有人。
人大概在什么区域。
是否有人走动、坐下、跌倒。
呼吸频率是否存在异常。
心率信号是否可估计。
房间的无线指纹是否发生变化。
多节点之间的空间关系是否支持更细定位。

RuView 试图把这些原始无线信号处理成可用的空间智能数据。

它能感知什么

按项目 README 的描述，RuView 关注的感知能力包括：

Presence and occupancy：检测是否有人、人数变化、进入和离开。
Vital signs：非接触式呼吸率和心率估计。
Activity recognition：行走、坐下、手势、跌倒等活动识别。
Environment mapping：房间 RF 指纹、家具移动、新物体变化。
Sleep quality：夜间监测、睡眠阶段和呼吸暂停筛查方向。
Pose estimation：基于 WiFi CSI 的人体关键点估计。

其中最容易落地的是存在检测、活动变化和粗粒度占用判断。呼吸、心率和姿态估计对硬件部署、环境、信号质量、模型和校准要求更高。

所以不要把所有功能看成同等成熟度。一个项目能跑通研究管线，和在真实家庭、医院、酒店、仓库里长期稳定运行，中间还有很长工程距离。

为什么是 ESP32-S3

RuView 推荐使用 ESP32-S3 作为低成本 CSI 采集节点。

README 里明确提到：

ESP32-C3 不支持。
原版 ESP32 不支持。
原因是单核和算力不足，不适合 CSI DSP 需求。
单 ESP32 部署空间分辨率有限。
更好的效果需要 2 个以上节点，或配合 Cognitum Seed。

这点很重要。很多人看到“WiFi 感知”会误以为普通电脑、普通路由器、任意 ESP32 都能完整实现。实际上，完整 CSI 能力依赖硬件、固件和采集方式。

项目也给出了不同硬件路径：

Docker 模拟数据：不需要硬件，适合评估处理管线。
ESP32-S3 节点：低成本实时采集，适合原型。
ESP32 mesh：多个节点提升空间分辨率。
ESP32-S3 + Cognitum Seed：用于持久记忆、kNN、见证链和 AI 集成。
研究网卡：如 Intel 5300 / Atheros AR9580，用于更完整 CSI 研究。
普通 WiFi 笔记本：通常只有 RSSI，能力很有限。

快速体验

如果只是想看系统界面和模拟数据，可以先用 Docker：

1
2


docker pull ruvnet/wifi-densepose:latest
docker run -p 3000:3000 ruvnet/wifi-densepose:latest

然后打开：

1

http://localhost:3000

如果要接真实 ESP32-S3 硬件，就要刷写固件并配置 WiFi：

1
2
3


python -m esptool --chip esp32s3 --port COM9 --baud 460800 \
  write_flash 0x0 bootloader.bin 0x8000 partition-table.bin \
  0xf000 ota_data_initial.bin 0x20000 esp32-csi-node.bin

配置网络和目标地址：

1
2


python firmware/esp32-csi-node/provision.py --port COM9 \
  --ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20

项目里还提供了多个实时处理脚本，例如：

1
2
3


node scripts/rf-scan.js --port 5006
node scripts/snn-csi-processor.js --port 5006
node scripts/mincut-person-counter.js --port 5006

这些命令适合开发者按 README 逐步验证管线。普通用户如果没有无线信号处理或嵌入式经验，直接上手会有门槛。

它的处理管线

RuView 的基本处理链路可以理解为：

WiFi 信号穿过房间。
人体和物体改变无线传播路径。
ESP32-S3 mesh 采集 CSI。
多频段、多子载波、多节点链路融合。
信号清洗和特征提取。
RuVector / AI Backbone 做表示、压缩、检索和建模。
神经网络输出人体关键点、生命体征和房间模型。
上层应用用于告警、统计、可视化或自动化控制。

这里涉及很多技术点：

CSI 子载波幅度和相位。
多径传播。
Fresnel zone 几何。
呼吸和心率频段滤波。
Hampel filter、SpotFi、BVP、spectrogram 等信号处理。
图算法、attention、spiking neural networks。
多节点 mesh 和跨视角融合。

这也是为什么 RuView 更像研究平台，而不是普通 IoT 小工具。它把无线信号处理、边缘硬件、AI 推理、空间建模和应用层模块都放在一起了。

可以用在哪些场景

RuView README 里列了很多应用场景，可以大致分成几类。

第一类是养老和医疗辅助：

老人房间存在检测。
跌倒检测。
夜间活动监测。
睡眠时呼吸率观察。
非关键病床的呼吸和心率辅助监测。

这类场景最吸引人，因为它不需要摄像头，也不要求用户一直佩戴设备。但医疗相关用途必须非常谨慎，不能把研究项目直接当医疗设备使用。

第二类是智能建筑和商业空间：

办公室工位和会议室占用。
HVAC 按真实存在状态调节。
酒店房间空置和节能。
餐厅排队和桌台周转。
零售客流、驻留时间和区域热度。

这类应用更接近“空间占用和行为统计”，对隐私友好性要求高，对厘米级姿态精度要求相对低，可能更容易先落地。

第三类是安全和工业：

周界入侵检测。
仓库人员安全区域。
叉车接近提醒。
封闭空间人员存在。
施工现场跌倒和人员计数。

这些场景需要低延迟和可靠告警，但也必须处理误报、漏报和责任边界。

第四类是机器人和复杂环境：

机器人在摄像头受限场景下感知人类。
烟尘、雾、遮挡、货架背后的人体存在。
灾害搜救中的呼吸信号探测。
地下、矿井、船舱等光学传感器困难场景。

这类场景很有研究价值，但工程化难度也更高。

隐私优势和新风险

RuView 的一个重要卖点是无摄像头。

在养老、医院、学校、办公室、酒店、餐厅、公共卫生间等场景里，摄像头会带来明显隐私压力。WiFi 感知不记录图像，也不需要可穿戴设备，从设计上减少了很多视觉隐私问题。

但“没有摄像头”不等于“没有隐私风险”。

WiFi 感知仍然可能推断：

房间里有没有人。
人什么时候进入和离开。
睡眠、呼吸和活动模式。
是否跌倒或长时间静止。
某些空间里的行为规律。

这些同样属于敏感数据。部署 RuView 这类系统时，仍然需要明确告知、权限控制、数据保留策略、加密存储、最小化采集和访问审计。

和摄像头、PIR、毫米波雷达的差别

摄像头的优势是信息丰富、直观、可解释，但隐私压力最大，也依赖光照和视线。

PIR 传感器成本低、部署简单，但只能感知热释电变化，容易出现“人静止就检测不到”的问题，空间分辨率也有限。

毫米波雷达适合非接触生命体征和存在检测，精度和稳定性较好，但通常需要额外硬件，部署成本高于复用现有 WiFi。

WiFi 感知的优势是：

WiFi 基础设施普遍存在。
能穿过部分墙体和遮挡。
不采集图像。
ESP32-S3 节点成本低。
可以和现有网络环境结合。

短板是：

信号受环境影响大。
部署位置、节点数量、墙体材料都会影响效果。
多人场景更复杂。
高精度姿态和生命体征估计仍然难。
工程化验证比普通摄像头方案更难。

当前限制

README 里已经列出几个关键限制，使用前要认真看：

项目仍是 beta 软件。
API 和固件可能变化。
ESP32-C3 和原版 ESP32 不支持。
单 ESP32 部署空间分辨率有限。
推荐使用 2 个以上节点或 Cognitum Seed。
无摄像头姿态估计当前精度有限。
摄像头监督训练管线已实现，但数据采集和评估阶段仍在推进。
Docker 示例使用模拟数据，不代表真实硬件效果。

这类项目最容易被标题带偏。WiFi 感知确实有很强的技术潜力，但实际效果取决于硬件、环境、部署密度、模型、校准和应用容错。

如果你要做原型验证，建议先从存在检测和简单活动识别开始，不要一上来就要求高精度姿态、心率和多人三维跟踪。

适合怎么入门

比较稳妥的学习路径是：

先跑 Docker 模拟数据，理解 UI 和处理管线。
阅读 README 和 docs 里的架构说明。
准备 ESP32-S3，而不是 ESP32-C3 或原版 ESP32。
从单节点 CSI 采集开始，确认数据流稳定。
再增加到 2 到 4 个节点，观察空间分辨率变化。
先验证 presence、movement、breathing 这类基础能力。
最后再尝试 pose estimation、edge modules 和多模态融合。

如果目标是产品化，还要额外考虑：

设备安装位置。
网络安全。
数据加密和保留周期。
告警误报率。
用户告知和授权。
硬件批量维护。
断网和断电行为。
OTA 升级和固件回滚。

总结

RuView 是一个很有野心的 WiFi CSI 空间感知项目。它尝试把低成本 ESP32-S3、无线信号处理、边缘 AI、生命体征估计、姿态识别和无摄像头空间监测放到同一套平台里。

它最有价值的地方，是把“WiFi 不只是联网工具，也可以成为空间传感器”这件事做成了可运行的开源工程。对于研究者、硬件开发者、智能建筑团队、隐私敏感场景的产品原型来说，它值得研究。

但它仍处在 beta 阶段，不能把 README 里的所有能力直接等同于稳定产品能力。单节点效果有限，硬件有要求，真实环境会带来噪声，多人和高精度姿态估计仍然困难。更合理的态度是：把 RuView 当成一个 WiFi 感知实验平台，从模拟数据和基础存在检测开始，逐步验证它在具体空间里的可用性。

参考链接：