RuView WiFlow 浏览器训练器在笔记本摄像头坐标系内把 410 维 WiFi CSI 炼成 17 点人体骨架【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView本文围绕 examples/through-wall/README.md 所描述的 WiFlow Browser Trainerwiflow_browser.html展开它把空房基线校准 → 相机监督采集 → 浏览器内训练 → 纯 WiFi CSI 推骨架这条完整闭环压缩进一个自包含 HTML 页面且全程运行在笔记本摄像头自身的坐标系里使推断出的骨架与相机画面天然对齐。读完本文你将掌握这个四阶段门控流程的每一步设计动机、410 维 CSI 输入向量的精确构成、WebGPU/WASM/WebGL 三级计算后端选择机制以及从构建 sensing-server 到打开页面上手的完整运行步骤。一、一个 HTML 页面的四阶段门控流程WiFlow Browser Trainer 的核心是一个完全自包含的单 HTML 页面仅依赖 CDN 库无打包器它在浏览器中、在笔记本摄像头的坐标系里完成相机监督的 WiFi 姿态学习闭环。页面顶部是一个进度步进条四个阶段逐级解锁上一阶段未完成下一阶段保持锁定0 · CALIBRATE → 1 · CAPTURE → 2 · TRAIN → 3 · INFER从源码结构看门控逻辑集中在 wiflow_browser.html 的stageUnlocked()中四个阶段的解锁条件分别是阶段解锁条件源码依据0 · CALIBRATE始终可用stageUnlocked(calibrate)恒为 true1 · CAPTURE基线校准完成return stageDone.calibrate2 · TRAIN基线完成且样本数 ≥ 200SAMPLES.length 2003 · INFER已存在训练好的模型return !!model这种无基线不可采集、样本不足不可训练、无模型不可推理的硬门控与 Python 侧管线wiflow_capture.py → wiflow_train.py → wiflow_infer.py的诚实设计一脉相承——README 明确指出Cant capture without it / Cant train with 200 samples / Cant infer without a model。阶段 0 · CALIBRATE空房基线ADR-151校准阶段的直觉是房间里静态的 WiFi 信道在绝大部分时间上是恒定的。因此你需要先走出房间页面捕捉约 10 秒的静息态quiescentCSI对这 410 维向量逐特征做在线Welford 均值 标准差累积。此后每一帧 CSI 都被表达为相对基线的偏差x_norm (x − base_mean) / (base_std ε)于是人体的扰动从静态信道中浮了出来。基线结果持久化到 IndexedDB刷新页面后自动恢复CALIBRATED (restored)。实现细节可以从 wiflow_browser.html 看到累积器cw使用Float64Array保存mean与m2Welford 的平方和项避免长序列浮点漂移校准窗口常量BASELINE_SECONDS 10期间只累积新鲜的 live 帧freshLiveCSI()要求source esp32且距上帧 400 ms模拟源帧直接忽略保证基线是真数据点击calibrate baseline后先有一段可配置的get-ready 倒计时默认 5 秒画布上打出大字 STEP OUT OF THE ROOM倒计时结束才开始真正记录——这是给使用者留出离开感测区域的物理时间结束时的标准差取样本标准差sqrt(m2/(n−1))若 20 秒两倍窗口内没有收集到任何 live 帧则报NO LIVE CSI — check esp32并放行重试而不是悄悄产出垃圾基线。阶段 1 · CAPTURE相机监督的配对准入CAPTURE 阶段中MediaPipe Pose 跑在笔记本摄像头上输出 17 个 COCO 关键点作为标签label与之配对的是基线归一化后的 410 维 ESP32 CSI 向量作为输入input。页面内置一套引导式、均衡化的采集流程大号屏幕提示轮播动作指令stand / turn / walk / arms / crouch / sit / reach每段动作前有 get-ready 倒计时、动作后有秒数倒计时并配有逐姿态覆盖度仪表coverage meter防止你采了 2000 帧全是站着不动的偏态数据集。从源码结构看两个设计值得展开配对准入是双条件与。README 的表述是只有当高置信姿态与新鲜的 live esp32 CSI 帧共存时才落盘一对。wiflow_browser.html 的采集循环里每帧先做三重检查latestVis 0.5MediaPipe 平均可见度、freshLiveCSI()sourceesp32且 400 ms 内、baseline存在任何一项失败都会把跳过原因写进状态行no confident pose/CSI not esp32 (sim)/no fresh CSI让你实时知道数据为何没进库。落盘的是基线归一化后的 CSIbaselineNorm(latestCSI.vec) 34 维关键点坐标。交错的多次 pass 解决时间切分 OOD 问题。wiflow_browser.html 定义了 9 个动作桶stand still / turn / walk left / walk right / arms up / arms down / crouch / sit / reach但 README 面向读者概括为 stand / turn / walk / arms / crouch / sit / reach 七类引导提示。采集不是把每个动作采完再换下一个而是多轮交错 passpass1[全部动作] → pass2[全部动作] → …默认 3 轮 × 每段 12 秒均可在页面上调。源码注释写明原因这样每个动作被摊在整个时间轴上时间序 80/20 留出切分中的验证段就与训练段具有相同的活动混合比例——这是针对此前-6pp OOD 留出问题的修复。MediaPipe 推理做了限流单帧在途one-in-flight 约 18 Hz 上限MP_MIN_INTERVAL_MS 55保证 UI 不卡顿。数据集以wiflow-browser-dataset格式提供export/import JSON能力wiflow_browser.html导入时有维度守卫csi.length ! CSI_DIM直接丢弃never fabricate支持多次会话累积数据。阶段 2 · TRAINTensorFlow.js MLP 与必须击败的基线TRAIN 阶段用一个 TensorFlow.js MLP 在浏览器里学习CSI → pose并给出诚实的留出指标PCK0.10、PCK0.05、MPJPE外加一个均值姿态基线mean-pose baseline——模型必须击败它否则页面会直说无可用信号。README 强调这正是本项目的一贯信条no baseline-beating signal, it says so。训练源码 中的关键工程决策时间序 80/20 切分cut floor(n*0.8)验证段是会话最后的 20%从未参与训练——指标不泄漏双重归一化输入先经过基线偏差归一化阶段 0 的产物采集时已做训练时再在仅训练段上估计逐维 μ/σ 做标准化网络结构Dense(384, ReLU, L2 1e-4) → Dropout(0.35) → Dense(192, ReLU) → Dropout(0.35) → Dense(96, ReLU) → Dense(34, Sigmoid)输出 17×2 个 [0,1] 归一化坐标。源码注释解释了为什么是较小容量针对一次诚实负例运行中 train MSE 0.072 vs val MSE 0.161 的过拟合把宽度从 512/256/128 降到 384/192/96 并把宽层 dropout 提到 0.35优化与早停Adamlr 1e-3 MSEbatch 64每 epoch 在验证段上评估 PCK/val-MSE按 patience默认 30早停并恢复历史最佳权重model.setWeights(bestWeights)——报告的是最佳模型不是最后一个基线裁决均值姿态基线 PCK0.10 始终计算并显示最终裁决按 ΔPCK 是否 1 pp二值化页面以绿色/红色横幅明文输出model BEATS mean-pose baseline by X.X pp → real CSI→pose signal或model does NOT beat baseline → no usable signal (honest)。模型与归一化参数μ/σ、留出 PCK一起存入 IndexedDBindexeddb://wiflow-model刷新页面后自动loadModel()恢复INFER 阶段随之解锁。阶段 3 · INFER纯 WiFi CSI 驱动骨架且与画面对齐INFER 阶段中已训练模型仅凭 WiFi CSI基线归一化 → 标准化 → 前向逐帧驱动骨架画在训练时所用的同一个笔记本相机画面上——所以推断骨架与相机图像对齐。README 点明这正是整件事在浏览器里做、而不是另起一个 Python 相机进程做的全部意义That alignment is the entire point of doing this in-browser.inferLoop 中还有两个细节预测关键点经过一阶 EMA 平滑α 0.35抑制抖动骨架颜色由服务端classification.presence决定——在场为绿色无人在场降为灰色。页面提供hide camera开关可在纯黑背景上看仅 CSI 骨架。状态行持续显示实测的 held-out PCK0.10提醒读者推断姿态是粗粒度的。二、为什么放进浏览器Python 管线的坐标帧问题README 的Why in-browser一节交代了浏览器版存在的理由。Python 侧管线wiflow_capture.py → wiflow_train.py → wiflow_infer.py已经证明信号是真的文档记载其留出 PCK0.10 ≈59.5%对比 50% 的均值姿态基线9.4 个百分点。但它训练时用的是另一台相机的坐标系推断出的骨架永远对不齐笔记本摄像头画面。把采集、训练、推理全部放进浏览器、共用同一台相机训练帧与推理帧的坐标系恒等骨架自然对齐。两条管线共享同一份输入约定与诚实标准对比项Python 管线浏览器训练器采集wiflow_capture.pycv2 MediaPipe PoseLandmarker WebSocket 订阅双条件置信姿态 ∧ live esp32 CSI才写 JSONL同一双条件逻辑样本进 IndexedDB配对时间窗--max-skew-ms默认 150 ms源码400 ms 新鲜度阈值freshLiveCSI()姿态可见度门槛--min-vis默认 0.5latestVis 0.5模型PyTorch MLP 512/256/128 → 34wiflow_train.pyTF.js MLP 384/192/96 → 34切分与基线时间序 80/20均值姿态基线Δ1 pp 判 BEATS完全相同wiflow_train.py 与浏览器版同源推理wiflow_infer.py纯 numpy 前向在ws://:8770/pose广播给 HTML 客户端页面内逐帧前向直接画在相机画面上两条管线的 410 维向量构造逐位一致这是跨管线数据可互换的基础见下节。三、410 维 CSI 输入向量的精确构成README 要求浏览器版与 Python 管线完全匹配输入向量其构成如下[ mean_rssi, variance, motion_band_power, breathing_band_power ] # 4 (features.*) for node 9 then node 13: [ mean_rssi, variance, motion_band_power ] # 6 (node_features[].features.*) signal_field.values, padded / truncated to 400 # 400 410-d即4 个全局特征 每节点 3 个特征 × 2 个节点9、13 400 维信号场20×20 410。浏览器侧的csiVector()wiflow_browser.html与 Python 侧的csi_vector()wiflow_capture.py实现同一布局全局features四元组 → 按节点 9 在前、节点 13 在后的node_features[].features三元组 →signal_field.values不足补零、超过截断到 400。README 说明该等价性已用真实 live 帧验证过浏览器csiVector()产生与wiflow_capture.py csi_vector()完全相同的 410 向量node 9 在前、node 13 在后field 零填充。从源码结构看还有一个增强浏览器版的节点集合不是写死的。NODE_IDS [9, 13]只是检测运行前的回退值detectSensors()会嗅探 live 流把在 ≥40% 采样帧中出现且满足最小帧数的node_id锁定为有序集合升序保证模型输入布局跨采集/训练/推理稳定并据此重算CSI_DIM 4 3×|NODE_IDS| 400。若检测到的集合与现有基线/数据不一致页面会明确提示切换将作废已有基线/N 条样本确认后清空重来wiflow_browser.html——因为节点集合定义了模型的输入维度静默变更就是数据污染。四、计算后端WebGPU → WASM-SIMD → WebGL训练与推理都跑在 TensorFlow.js 上页面在启动时自动选择可用后端优先最快者selectBackendWebGPUChrome / Edge安全上下文——localhost满足条件——GPU 计算首选WASM-SIMD回退tfjs-backend-wasm启用 SIMD.wasm文件从 CDN 加载WebGL最后兜底随 tfjs core 自带。选中的后端以徽章形式显示在页头compute: WebGPU/WASM-SIMD/WebGL如实标注实际在跑什么模型代码本身后端无关设备抽象由 tf.js 完成。这与 README 的Honesty (baked in)立场一致——不宣称性能只陈述实际状态。五、内建诚实性设计基线裁决、来源横幅与那次被撤回的 92.9%README 的Honesty (baked in)一节列出的四条设计约束在源码中均可逐一对应颜色即身份CAPTURE 骨架蓝色来自相机是真值ground truth标注为 labelINFER 骨架绿色是纯 CSI 推断标注为 coarse旁边常驻显示实测留出 PCK而非营销数字基线永远在场TRAIN 阶段均值姿态基线始终计算并展示裁决明文说明模型是beats有真实信号还是does not无可用信号。README 特别指出这套检查正是为了防住该项目曾撤回的 92.9% 数字——那个数字正是在基线检查上失败的来源横幅严格互斥LIVE真实source: esp32/SIMULATED — not real任何其他 source/NO-CSI-SERVER。connectCSI 中三态互斥更新断线 1.5 秒自动重连页面从不伪造帧无基线不可采集采集按钮在无基线时禁用训练按钮在样本 200 时禁用推理在无模型时阶段保持锁定。六、运行步骤两个进程、两个端口1. 启动真实 sensing-server提供 :8765 的 CSI WebSocket按 README 的步骤在v2目录下构建并启动 Rust 侧感测服务cd v2 cargo build -p wifi-densepose-sensing-server ./target/debug/sensing-server.exe --ws-port 8765 --udp-port 5005页面期望的已验证 live 端点是ws://localhost:8765/ws/sensing要求帧中source:esp32、节点[9, 13]、features.*、node_features[].features.*与signal_field.values400 个浮点数。要拿到source: esp32即 LIVE 状态必须有一台真实ESP32-S3完成配网并持续推流——固件的构建与配网步骤README 指向仓库的CLAUDE.local.md本目录 README 中的原始引用。2. 用 localhost 静态服务器托管页面相机 WebGPU 需要 localhost/安全源任何 localhost 静态服务器都可以README 示例python -m http.server 8099 # 然后打开: http://localhost:8099/examples/through-wall/wiflow_browser.html注意端口分工8099 只是静态文件服务器8765 是另一个进程CSI WebSocket。浏览器提示时请允许相机访问。仓库还提供了一个带线程与 no-cache 头的专用静态服务器 serve.py默认监听 8080服务仓库根目录其文件头注释解释了为什么不用单线程的python -m http.server浏览器会并行拉取 HTML 与 CDN 资源单线程 SimpleHTTPServer 会让首个连接占住唯一工作线程导致其余请求挂起。指向其他主机上的 CSI 服务器用?ws查询参数覆盖http://localhost:8099/examples/through-wall/wiflow_browser.html?wsws://192.168.1.20:8765/ws/sensing对应源码逻辑页面按https:与否自动选wss/ws并默认连接同主机 8765 端口?ws参数优先wiflow_browser.html。3. 使用流程CAPTURE页签 →enable laptop camera→start guided recording。跟随引导流程stand / turn / walk / arms / crouch / sit。只有高置信姿态 ∧ 新鲜 live esp32 CSI共存时才落一对样本目标量级是数千条。样本存 IndexedDB刷新不丢。TRAIN页签 →train model。观察实时 loss 曲线train 琥珀 / val 蓝、留出 PCK 与基线裁决。模型存入 IndexedDB。INFER页签 → 绿色骨架改由 WiFi CSI 单独驱动对齐叠在你自己的相机画面上。勾选hide camera可在黑底上只看 CSI 骨架。七、依赖与持久化CDN-only 库清单和 IndexedDB 布局页面只依赖 CDN无打包器README 给出的库清单为库CDNTensorFlow.js coretensorflow/tfjs4.22.0/dist/tf.min.jsTF.js WebGPU backendtensorflow/tfjs-backend-webgpu4.22.0/dist/tf-backend-webgpu.min.jsTF.js WASM backendtensorflow/tfjs-backend-wasm4.22.0/dist/tf-backend-wasm.min.jsMediaPipe Pose 0.5 (legacy solutions)mediapipe/pose0.5/pose.js与页面 HTML 头部 实际加载的四个script标签一一对应。页面状态通过 IndexedDB 数据库wiflow-browser对象存储kv持久化wiflow_browser.html键位包括samples数据集、baseline基线 μ/σ/帧数/时间戳、nodeIds检测到的节点集合、norm输入标准化参数 留出 PCK模型本身经 TF.js 存于indexeddb://wiflow-model。启动序列boot固定为连 CSI → 选后端 → 恢复 nodeIds → 恢复基线 → 恢复样本 → 加载模型 → 刷新门控——即上次会话做到哪一步刷新后从哪一步继续。相机选择存 localStorage跨会话记忆。八、适用范围与诚实的边界声明最后必须完整继承 READMEScope / honesty caveats的适用前提这也是使用本方案前必须理解的边界当前验证范围是同一人、同一房间、同一会话未验证跨天、跨房间也未验证真正的隔墙through-wall场景——目录名through-wall指的是实验主题域而非当前已交付的隔墙能力推断姿态是粗粒度的PCK0.05 通常较弱如果模型没有击败均值姿态基线页面会直说——这是特性不是缺陷。这套打不过基线就承认的评估纪律时间序留出、基线对照、来源三态横幅贯穿浏览器与 Python 两条管线是理解本项目姿态估计数字时必须先建立的方法论前提。九、延伸阅读examples/through-wall/README.md本文主体文档四阶段流程与运行说明的权威来源examples/through-wall/wiflow_browser.html1272 行自包含页面含门控、Welford 基线、TF.js 训练与 CSI 推理全部实现examples/through-wall/wiflow_capture.py / wiflow_train.py / wiflow_infer.pyPython 侧采集、训练、推流三件套examples/through-wall/wiflow_ab.py、index.html同目录的 A/B 实验与展示页面examples/through-wall/serve.py线程化 no-cache 静态服务器【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考