wifi-densepose 是一个围绕 WiFi 感知做实验的开源项目，地址如下：
https://github.com/ruvnet/wifi-densepose
它想解决的问题很有吸引力：不用摄像头，只利用 WiFi 信号的变化，判断房间里是否有人、人的姿态大概是什么样，甚至进一步估计呼吸率、心率等生命体征。
这个方向并不是玄学。WiFi 信号在室内传播时，会被墙壁、家具、人体反射和散射。人体移动、手臂摆动、胸腔呼吸起伏，都会改变无线信道的状态。只要硬件能拿到足够细的信号变化，再配合信号处理和机器学习模型，就有机会从这些变化中恢复人体活动信息。
但要把“有信号变化”变成“论文级 DensePose 人体表面还原”，中间隔着硬件、数据集、标注、训练、泛化能力等一整套复杂工程。wifi-densepose 当前更适合作为 WiFi 感知 Demo 或研究原型来体验，不应直接当作已经成熟可落地的穿墙人体 DensePose 系统。
CSI 是什么：WiFi 感知真正依赖的数据
普通应用通常只能拿到 WiFi 信号强度，比如手机上显示的几格信号。这类信息太粗，最多反映“信号强不强”，很难支撑细粒度人体动作分析。
WiFi 感知更依赖 Channel State Information（信道状态信息，CSI）。CSI 描述的是无线信号从发射端到接收端经过信道后的变化情况，通常包含每个子载波上的：
| 数据 | 含义 | 用途 |
|---|---|---|
| 幅度 | 信号在该子载波上的强弱变化 | 反映遮挡、反射、路径衰减 |
| 相位 | 信号波形相对于参考的偏移 | 对微小位移更敏感，但也更容易受硬件误差影响 |
| 天线对信息 | 多发多收天线之间的信道差异 | 提供空间维度信息 |
| RSSI | Received Signal Strength Indicator（接收信号强度指示） | 可作为辅助特征，但粒度不如 CSI |
可以把 CSI 理解成“WiFi 信号穿过房间后的细粒度指纹”。当人站在不同位置、摆出不同动作、胸腔有微小起伏时，这个指纹会发生变化。
整体流程大致如下：
flowchart LR
A[WiFi 发射端] --> B[室内环境]
B --> C[人体反射/遮挡/散射]
C --> D[WiFi 接收端]
D --> E[采集 CSI 幅度和相位]
E --> F[滤波/校准/特征提取]
F --> G[机器学习或深度学习模型]
G --> H[存在检测]
G --> I[人体姿态估计]
G --> J[呼吸率/心率估计]
这里最关键的一点是：普通 WiFi 设备不一定能直接导出 CSI。很多消费级路由器和电脑网卡只向系统暴露 RSSI，不开放每个子载波的 CSI 数据。要做稳定实验，通常需要支持 CSI 导出的网卡、固件、驱动，或者使用 ESP32 等可采集 CSI 的设备。
DensePose 与普通姿态估计有什么区别
人体姿态估计有很多层级。
最简单的是存在检测：房间里有没有人。
再进一步是关键点检测：识别头、肩、肘、膝等骨架点。
DensePose 更难。DensePose 的目标不是只找几个关节点，而是把人体可见区域映射到三维人体表面的坐标系统中。典型 DensePose 会把人体分成多个区域，并为人体表面点预测 UV 坐标。
| 能力层级 | 输出结果 | 难度 |
|---|---|---|
| 存在检测 | 是否有人、是否有人移动 | 较低 |
| 活动识别 | 走路、坐下、挥手等类别 | 中等 |
| 关键点姿态 | 头、肩、肘、膝等 2D/3D 关节 | 较高 |
| DensePose | 人体表面区域与 UV 坐标映射 | 很高 |
| 生命体征 | 呼吸率、心率 | 对信噪比和静止条件要求高 |
CMU 曾有研究探索 DensePose From WiFi：使用深度神经网络，把 WiFi CSI 的幅度和相位映射到人体表面区域与 UV 坐标。这类方案想达到较好效果，需要满足几个条件：
- 有能稳定输出 CSI 的专用硬件；
- 室内环境、发射端、接收端位置要经过设计；
- 需要采集大量 WiFi CSI 数据；
- 需要同步摄像头或其他传感器生成姿态标注；
- 模型训练需要大量迭代、复杂损失函数和验证集；
- 换房间、换设备、换人群后，效果可能明显下降。
也就是说，论文级 DensePose from WiFi 是一个完整研究系统，不是简单启动一个 Web 页面就能完成的功能。
wifi-densepose 当前更接近什么
wifi-densepose 的 README 描述了不少目标能力，比如人体姿态、生命体征、存在检测等。从技术方向看，这些目标都属于 WiFi 感知范畴；但从项目状态看，当前实现与“完整 DensePose-quality estimation”仍有距离。
项目维护者在 Issue #39 中明确说明，Full DensePose-quality estimation 还没有完成，相关神经网络训练仍处于 roadmap 阶段。
因此，对它的定位更合理：
| 项目形态 | 更接近的描述 |
|---|---|
| 已经成熟的穿墙 DensePose 系统 | 不适合这样理解 |
| 可直接替代摄像头的人体姿态产品 | 不适合这样理解 |
| WiFi CSI 感知实验框架 | 更接近 |
| 带可视化界面的研究 Demo | 更接近 |
| 用于理解 CSI 数据流和端到端流程 | 适合 |
换句话说，它可以帮助理解 WiFi 感知系统如何搭建数据流、如何展示结果、如何接入测试信号，但不能把 README 中的远期目标等同于当前已经完整实现的能力。
一个 WiFi 姿态估计系统通常怎么工作
为了避免把概念讲虚，可以把 WiFi DensePose 类系统拆成四层：硬件采集层、信号处理层、模型推理层、可视化层。
flowchart TB
subgraph Hardware[硬件采集层]
TX[WiFi 发射端]
RX[支持 CSI 的接收端]
end
subgraph Signal[信号处理层]
CSI[CSI 原始数据]
Clean[相位校准/去噪/滤波]
Feature[特征窗口]
end
subgraph Model[模型推理层]
Presence[存在检测模型]
Pose[姿态估计模型]
Vital[生命体征估计]
end
subgraph UI[可视化层]
Web[Web Dashboard]
Skeleton[2D/3D 姿态展示]
Metrics[呼吸率/心率指标]
end
TX --> RX
RX --> CSI
CSI --> Clean
Clean --> Feature
Feature --> Presence
Feature --> Pose
Feature --> Vital
Presence --> Web
Pose --> Skeleton
Vital --> Metrics
1. 硬件采集层
WiFi 发射端持续发包，接收端采集 CSI。理想情况下，接收端能拿到多个子载波、多个天线对上的幅度和相位。
如果只有 RSSI，信息量通常不够。RSSI 是整体强度，CSI 才是细粒度信道状态。
2. 信号处理层
CSI 原始数据不能直接喂给模型。相位会受到硬件时钟、载波频偏、采样偏移影响，幅度也会有噪声和环境扰动，所以通常要做处理：
flowchart LR
A[原始 CSI] --> B[异常值剔除]
B --> C[相位展开与校准]
C --> D[滤波去噪]
D --> E[滑动时间窗口]
E --> F[幅度/相位特征]
F --> G[模型输入张量]
常见问题包括：
- 人没动时也会有噪声；
- WiFi 设备自身会带来相位漂移；
- 多径反射让同一个动作在不同房间呈现不同 CSI 模式；
- 人体姿态变化和环境变化可能混在一起；
- 多人场景比单人场景复杂很多。
3. 模型推理层
模型可以做不同任务：
- 二分类：是否有人；
- 多分类：动作类别；
- 回归：呼吸率、心率；
- 关键点估计：输出关节坐标；
- DensePose：输出人体区域与 UV 坐标。
任务越细，训练数据越难准备。尤其 DensePose 需要对齐 WiFi CSI 与视觉标注，数据采集成本远高于普通分类任务。
4. 可视化层
wifi-densepose 提供 Web 可视化界面，用来展示姿态或指标结果。这个界面对理解端到端数据流很有帮助，但 UI 能显示骨架或人体模型，不代表底层模型已经达到论文级精度。
生命体征监测为什么更难
呼吸和心跳确实会影响 WiFi 信号。呼吸带来的胸腔周期性起伏相对明显，心跳引起的位移更小，对信噪比要求更高。
典型生命体征估计流程类似这样：
flowchart LR
A[CSI 时间序列] --> B[选择稳定子载波]
B --> C[去除人体大幅运动]
C --> D[带通滤波]
D --> E[频谱分析]
E --> F[呼吸率/心率估计]
这类能力通常有苛刻条件：
| 指标 | 相对难度 | 典型要求 |
|---|---|---|
| 呼吸率 | 中等 | 人尽量静止，环境干扰较少 |
| 心率 | 高 | 信噪比更高，硬件稳定性更强 |
| 多人生命体征 | 很高 | 需要区分不同人体反射路径 |
| 穿墙生命体征 | 很高 | 墙体衰减、多径和噪声更严重 |
如果人在走动、转身、挥手，大幅动作会淹没呼吸和心跳造成的微弱周期信号。生命体征监测更适合静止场景，比如坐着或躺着，而不是复杂活动场景。
什么时候适合尝试 wifi-densepose
| 场景 | 是否适合 | 原因 |
|---|---|---|
| 学习 CSI 数据流 | 适合 | 可以理解 WiFi 感知系统的输入、处理和输出 |
| 做 WiFi sensing Demo | 适合 | Web 可视化能帮助快速体验流程 |
| 验证 Docker 部署流程 | 适合 | 官方镜像可以快速启动界面 |
| 复现论文级 DensePose 效果 | 不适合直接期待 | 完整 DensePose-quality estimation 尚未实现 |
| 生产环境人体监控 | 不适合 | 稳定性、泛化、隐私和合规都需要额外工程 |
| 医疗级生命体征监测 | 不适合 | 精度、认证、硬件条件都达不到医疗要求 |
它最适合的用法是：把它当成 WiFi 感知方向的入口项目，理解 CSI、信号流、可视化和硬件接入方式，而不是把它当成成熟人体姿态产品。
Docker 快速体验
如果只是想先看 Web 界面和项目结构，可以使用 Docker 启动。
docker pull ruvnet/wifi-densepose:latest
docker run --rm \
-p 3000:3000 \
-p 3001:3001 \
-p 5005:5005/udp \
ruvnet/wifi-densepose:latest
启动后访问：
http://localhost:3000
端口含义可以按这个方式理解：
| 端口 | 协议 | 作用 |
|---|---|---|
| 3000 | TCP | Web 可视化界面 |
| 3001 | TCP | 可能用于前后端通信或辅助服务 |
| 5005 | UDP | 接收外部 CSI 或测试数据流 |
如果还没有 ESP32 或支持 CSI 的网卡，可以先使用项目内置的测试信号或录制数据，确认容器、界面、数据流能够跑通。等流程没问题后，再投入时间配置硬件。
接入真实硬件前要确认的事
真实 CSI 采集比启动 Docker 麻烦得多。动手前最好确认这些问题：
| 检查项 | 需要确认什么 |
|---|---|
| 网卡或开发板 | 是否能导出 CSI，而不是只能读 RSSI |
| 驱动和固件 | 是否支持 CSI 采样、频段、带宽、天线配置 |
| 数据格式 | 输出的 CSI 是否能被项目解析 |
| 时间同步 | CSI 与姿态标签或参考信号是否能对齐 |
| 环境稳定性 | 房间布局、发射端和接收端位置是否固定 |
| 人数和动作 | 单人、多人、静止、运动场景要分开验证 |
| 标注数据 | 若要训练模型，是否有可靠姿态标签 |
很多 WiFi 感知实验失败，不是模型代码写错，而是 CSI 数据质量不够。相位没有校准、采样不稳定、环境变化太大，都会让模型输出变得不可用。
关键限制
普通 WiFi 不等于可用 CSI
“用 WiFi 检测人体”容易让人误解成只要家里有路由器就能做。实际不是这样。系统需要的是可导出的 CSI 数据，而不是普通系统 API 里的 WiFi 信号强度。
换环境后效果可能大幅下降
WiFi 信号受房间结构影响很大。同一个动作在不同房间、不同家具布局、不同路由器位置下，CSI 模式可能完全不同。模型如果只在少量场景训练，泛化能力通常有限。
DensePose 需要大量标注
DensePose 不是普通分类任务。要训练这类模型，需要把 CSI 时间片和人体表面标注对应起来，通常需要同步摄像头或其他传感器提供标签。没有数据集和训练过程，很难凭空得到高质量 DensePose 输出。
生命体征不是医疗级能力
呼吸率和心率估计对静止条件、信噪比、采样质量都很敏感。它可以作为研究方向探索，但不能直接用于医疗诊断或安全关键场景。
隐私问题仍然存在
不用摄像头不代表没有隐私风险。WiFi 感知可以推断房间内是否有人、人在做什么动作，这类数据仍然属于敏感信息。实验和部署都应取得明确授权。
对 wifi-densepose 的合理预期
wifi-densepose 展示了一个有趣方向：WiFi 不只是联网工具，也可以作为环境感知传感器。它背后的技术核心是 CSI，通过分析信道幅度和相位变化，推断人体存在、运动、姿态和微弱生命体征。
不过，当前开源实现与论文级 DensePose from WiFi 之间仍有明显距离。更合适的使用方式是：
- 用 Docker 跑通界面和流程；
- 用测试数据理解 CSI 到可视化的链路；
- 准备支持 CSI 的硬件；
- 小范围验证存在检测或简单动作识别；
- 再考虑复杂姿态估计和生命体征任务。
如果目标是学习 WiFi 感知，它是一个不错的入口；如果目标是直接得到稳定的穿墙全身 DensePose，还需要硬件、数据集、模型训练和大量实验验证。