mirror of
https://github.com/ruvnet/RuView
synced 2026-06-11 10:33:19 +00:00
Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 ruv
|
8f927aaedb | ||
|
ruv
|
635c152e61 |
@@ -1 +0,0 @@
|
||||
{"intelligence":7,"timestamp":1774922079152}
|
||||
@@ -62,32 +62,6 @@ jobs:
|
||||
bandit-report.json
|
||||
safety-report.json
|
||||
|
||||
# Rust Workspace Tests
|
||||
rust-tests:
|
||||
name: Rust Workspace Tests
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Install Rust toolchain
|
||||
uses: dtolnay/rust-toolchain@stable
|
||||
|
||||
- name: Cache cargo
|
||||
uses: actions/cache@v4
|
||||
with:
|
||||
path: |
|
||||
~/.cargo/registry
|
||||
~/.cargo/git
|
||||
rust-port/wifi-densepose-rs/target
|
||||
key: ${{ runner.os }}-cargo-${{ hashFiles('rust-port/wifi-densepose-rs/Cargo.lock') }}
|
||||
restore-keys: |
|
||||
${{ runner.os }}-cargo-
|
||||
|
||||
- name: Run Rust tests
|
||||
working-directory: rust-port/wifi-densepose-rs
|
||||
run: cargo test --workspace --no-default-features
|
||||
|
||||
# Unit and Integration Tests
|
||||
test:
|
||||
name: Tests
|
||||
@@ -209,7 +183,7 @@ jobs:
|
||||
docker-build:
|
||||
name: Docker Build & Test
|
||||
runs-on: ubuntu-latest
|
||||
needs: [code-quality, test, rust-tests]
|
||||
needs: [code-quality, test]
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@v4
|
||||
@@ -308,7 +282,7 @@ jobs:
|
||||
notify:
|
||||
name: Notify
|
||||
runs-on: ubuntu-latest
|
||||
needs: [code-quality, test, rust-tests, performance-test, docker-build, docs]
|
||||
needs: [code-quality, test, performance-test, docker-build, docs]
|
||||
if: always()
|
||||
steps:
|
||||
- name: Notify Slack on success
|
||||
|
||||
@@ -15,7 +15,7 @@ jobs:
|
||||
name: Build ESP32-S3 Firmware
|
||||
runs-on: ubuntu-latest
|
||||
container:
|
||||
image: espressif/idf:v5.4
|
||||
image: espressif/idf:v5.2
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
@@ -54,10 +54,9 @@ jobs:
|
||||
fi
|
||||
|
||||
# Check partition table magic (0xAA50 at offset 0).
|
||||
# Use od instead of xxd (xxd not available in espressif/idf container).
|
||||
PT=build/partition_table/partition-table.bin
|
||||
if [ -f "$PT" ]; then
|
||||
MAGIC=$(od -A n -t x1 -N 2 "$PT" | tr -d ' ')
|
||||
MAGIC=$(xxd -l2 -p "$PT")
|
||||
if [ "$MAGIC" != "aa50" ]; then
|
||||
echo "::warning::Partition table magic mismatch: $MAGIC (expected aa50)"
|
||||
ERRORS=$((ERRORS + 1))
|
||||
@@ -72,7 +71,7 @@ jobs:
|
||||
fi
|
||||
|
||||
# Verify non-zero data in binary (not all 0xFF padding).
|
||||
NONZERO=$(od -A n -t x1 -N 1024 "$BIN" | tr -d ' f\n' | wc -c)
|
||||
NONZERO=$(xxd -l 1024 -p "$BIN" | tr -d 'f' | wc -c)
|
||||
if [ "$NONZERO" -lt 100 ]; then
|
||||
echo "::error::Binary appears to be mostly padding (non-zero chars: $NONZERO)"
|
||||
ERRORS=$((ERRORS + 1))
|
||||
@@ -98,5 +97,4 @@ jobs:
|
||||
firmware/esp32-csi-node/build/esp32-csi-node.bin
|
||||
firmware/esp32-csi-node/build/bootloader/bootloader.bin
|
||||
firmware/esp32-csi-node/build/partition_table/partition-table.bin
|
||||
firmware/esp32-csi-node/build/ota_data_initial.bin
|
||||
retention-days: 90
|
||||
retention-days: 30
|
||||
|
||||
+1
-10
@@ -23,14 +23,6 @@ rust-port/wifi-densepose-rs/data/recordings/
|
||||
nvs.bin
|
||||
nvs_config.csv
|
||||
nvs_provision.bin
|
||||
firmware/esp32-csi-node/nvs_seed.csv
|
||||
firmware/esp32-csi-node/nvs_seed.bin
|
||||
firmware/esp32-csi-node/nvs_config.bin
|
||||
firmware/esp32-csi-node/nvs_wifi.bin
|
||||
firmware/esp32-csi-node/nvs.bin
|
||||
# Catch any other NVS binaries/CSVs with credentials
|
||||
**/nvs_*.bin
|
||||
**/nvs_*.csv
|
||||
|
||||
# Working artifacts that should not land in root
|
||||
/*.wasm
|
||||
@@ -248,5 +240,4 @@ v1/src/sensing/mac_wifi
|
||||
**/node_modules/
|
||||
|
||||
# Local build scripts
|
||||
firmware/esp32-csi-node/build_firmware.batdata/
|
||||
models/
|
||||
firmware/esp32-csi-node/build_firmware.bat
|
||||
@@ -5,88 +5,6 @@ All notable changes to this project will be documented in this file.
|
||||
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
||||
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
||||
|
||||
## [v0.5.4-esp32] — 2026-04-02
|
||||
|
||||
### Added
|
||||
- **ADR-069: ESP32 CSI → Cognitum Seed RVF ingest pipeline** — Live-validated pipeline connecting ESP32-S3 CSI sensing to Cognitum Seed (Pi Zero 2 W) edge intelligence appliance. 339 vectors ingested, 100% kNN validation, SHA-256 witness chain verified.
|
||||
- **Feature vector packet (magic 0xC5110003)** — New 48-byte packet with 8 normalized dimensions (presence, motion, breathing, heart rate, phase variance, person count, fall, RSSI) sent at 1 Hz alongside vitals.
|
||||
- **`scripts/seed_csi_bridge.py`** — Python bridge: UDP listener → HTTPS ingest with bearer token auth, `--validate` (kNN + PIR ground truth), `--stats`, `--compact` modes, hash-based vector IDs, NaN/inf rejection, source IP filtering, retry logic.
|
||||
- **Arena Physica research** — 26 research documents in `docs/research/` covering Maxwell's equations in WiFi sensing, Arena Physica Studio analysis, SOTA WiFi sensing 2025-2026, GOAP implementation plan for ESP32 + Pi Zero.
|
||||
- **Cognitum Seed MCP integration** — 114-tool MCP proxy enables AI assistants to query sensing state, vectors, witness chain, and device status directly.
|
||||
|
||||
### Fixed
|
||||
- **Compressed frame magic collision** — Reassigned compressed frame magic from `0xC5110003` to `0xC5110005` to free `0xC5110003` for feature vectors.
|
||||
- **Uninitialized `s_top_k[0]` read** — Guarded variance computation against `s_top_k_count == 0` in `send_feature_vector()`.
|
||||
- **Presence score normalization** — Bridge now divides by 15.0 instead of clamping, preserving dynamic range for raw values 1.41-14.92.
|
||||
- **Stale magic references** — Updated ADR-039, DDD model to reflect `0xC5110005` for compressed frames.
|
||||
|
||||
### Security
|
||||
- **Credential exposure remediation** — Removed hardcoded WiFi passwords and bearer tokens from source files. Added NVS binary/CSV patterns to `.gitignore`. Environment variable fallback for bearer token.
|
||||
- **NaN/Inf injection prevention** — Bridge validates all feature dimensions are finite before Seed ingest.
|
||||
- **UDP source filtering** — `--allowed-sources` argument restricts packet acceptance to known ESP32 IPs.
|
||||
|
||||
### Changed
|
||||
- Wire format table now includes 6 magic numbers: `0xC5110001` (raw), `0xC5110002` (vitals), `0xC5110003` (features), `0xC5110004` (WASM events), `0xC5110005` (compressed), `0xC5110006` (fused vitals).
|
||||
|
||||
## [v0.5.3-esp32] — 2026-03-30
|
||||
|
||||
### Added
|
||||
- **Cross-node RSSI-weighted feature fusion** — Multiple ESP32 nodes fuse CSI features using RSSI-based weighting. Closer node gets higher weight. Reduces variance noise by 29%, keypoint jitter by 72%.
|
||||
- **DynamicMinCut person separation** — Uses `ruvector_mincut::DynamicMinCut` on the subcarrier temporal correlation graph to detect independent motion clusters. Replaces variance-based heuristic for multi-person counting.
|
||||
- **RSSI-based position tracking** — Skeleton position driven by RSSI differential between nodes. Walk between ESP32s and the skeleton follows you.
|
||||
- **Per-node state pipeline (ADR-068)** — Each ESP32 node gets independent `HashMap<u8, NodeState>` with frame history, classification, vitals, and person count. Fixes #249 (the #1 user-reported issue).
|
||||
- **RuVector Phase 1-3 integration** — Subcarrier importance weighting, temporal keypoint smoothing (EMA), coherence gating, skeleton kinematic constraints (Jakobsen relaxation), compressed pose history.
|
||||
- **Client-side lerp smoothing** — UI keypoints interpolate between frames (alpha=0.15) for fluid skeleton movement.
|
||||
- **Multi-node mesh tests** — 8 integration tests covering 1-255 node configurations.
|
||||
- **`wifi_densepose` Python package** — `from wifi_densepose import WiFiDensePose` now works (#314).
|
||||
|
||||
### Fixed
|
||||
- **Watchdog crash on busy LANs (#321)** — Batch-limited edge_dsp to 4 frames before 20ms yield. Fixed idle-path busy-spin (`pdMS_TO_TICKS(5)==0`).
|
||||
- **No detection from edge vitals (#323)** — Server now generates `sensing_update` from Tier 2+ vitals packets.
|
||||
- **RSSI byte offset mismatch (#332)** — Server parsed RSSI from wrong byte (was reading sequence counter).
|
||||
- **Stack overflow risk** — Moved 4KB of BPM scratch buffers from stack to static storage.
|
||||
- **Stale node memory leak** — `node_states` HashMap evicts nodes inactive >60s.
|
||||
- **Unsafe raw pointer removed** — Replaced with safe `.clone()` for adaptive model borrow.
|
||||
- **Firmware CI** — Upgraded to IDF v5.4, replaced `xxd` with `od` (#327).
|
||||
- **Person count double-counting** — Multi-node aggregation changed from `sum` to `max`.
|
||||
- **Skeleton jitter** — Removed tick-based noise, dampened procedural animation, recalibrated feature scaling for real ESP32 data.
|
||||
|
||||
### Changed
|
||||
- Motion-responsive skeleton: arm swing (0-80px) driven by CSI variance, leg kick (0-50px) by motion_band_power, vertical bob when walking.
|
||||
- Person count thresholds recalibrated for real ESP32 hardware (1→2 at 0.70, EMA alpha 0.04).
|
||||
- Vital sign filtering: larger median window (31), faster EMA (0.05), looser HR jump filter (15 BPM).
|
||||
- Vendored ruvector updated to v2.1.0-40 (316 commits ahead).
|
||||
|
||||
### Benchmarks (2-node mesh, COM6 + COM9, 30s)
|
||||
| Metric | Baseline | v0.5.3 | Improvement |
|
||||
|--------|----------|--------|-------------|
|
||||
| Variance noise | 109.4 | 77.6 | **-29%** |
|
||||
| Feature stability | std=154.1 | std=105.4 | **-32%** |
|
||||
| Keypoint jitter | std=4.5px | std=1.3px | **-72%** |
|
||||
| Confidence | 0.643 | 0.686 | **+7%** |
|
||||
| Presence accuracy | 93.4% | 94.6% | **+1.3pp** |
|
||||
|
||||
### Verified
|
||||
- Real hardware: COM6 (node 1) + COM9 (node 2) on ruv.net WiFi
|
||||
- All 284 Rust tests pass, 352 signal crate tests pass
|
||||
- Firmware builds clean at 843 KB
|
||||
- QEMU CI: 11/11 jobs green
|
||||
|
||||
## [v0.5.2-esp32] — 2026-03-28
|
||||
|
||||
### Fixed
|
||||
- RSSI byte offset in frame parser (#332)
|
||||
- Per-node state pipeline for multi-node sensing (#249)
|
||||
- Firmware CI upgraded to IDF v5.4 (#327)
|
||||
|
||||
## [v0.5.1-esp32] — 2026-03-27
|
||||
|
||||
### Fixed
|
||||
- Watchdog crash on busy LANs (#321)
|
||||
- No detection from edge vitals (#323)
|
||||
- `wifi_densepose` Python package import (#314)
|
||||
- Pre-compiled firmware binaries added to release
|
||||
|
||||
## [v0.5.0-esp32] — 2026-03-15
|
||||
|
||||
### Added
|
||||
|
||||
@@ -6,33 +6,34 @@
|
||||
</a>
|
||||
</p>
|
||||
|
||||
> **Beta Software** — Under active development. APIs and firmware may change. Known limitations:
|
||||
> **Alpha Software** — This project is under active development. APIs, firmware behavior, and documentation may change. Known limitations:
|
||||
> - Multi-node person counting may show identical output regardless of the number of people (#249)
|
||||
> - Training pipeline on MM-Fi dataset may plateau at low PCK (#318) — hyperparameter tuning in progress
|
||||
> - No pre-trained model weights are provided; training from scratch is required
|
||||
> - ESP32-C3 and original ESP32 are not supported (single-core, insufficient for CSI DSP)
|
||||
> - Single ESP32 deployments have limited spatial resolution — use 2+ nodes or add a [Cognitum Seed](https://cognitum.one) for best results
|
||||
> - Camera-free pose accuracy is limited — use [camera ground-truth training](docs/adr/ADR-079-camera-ground-truth-training.md) for 92.9% PCK@20
|
||||
> - Single ESP32 deployments have limited spatial resolution
|
||||
>
|
||||
> Contributions and bug reports welcome at [Issues](https://github.com/ruvnet/RuView/issues).
|
||||
|
||||
## **See through walls with WiFi** ##
|
||||
## **See through walls with WiFi + Ai** ##
|
||||
|
||||
**Turn ordinary WiFi into a sensing system.** Detect people, measure breathing and heart rate, track movement, and monitor rooms — through walls, in the dark, with no cameras or wearables. Just physics.
|
||||
**Perceive the world through signals.** No cameras. No wearables. No Internet. Just physics.
|
||||
|
||||
### π RuView is a WiFi sensing platform that turns radio signals into spatial intelligence.
|
||||
### π RuView is an edge AI perception system that learns directly from the environment around it.
|
||||
|
||||
Every WiFi router already fills your space with radio waves. When people move, breathe, or even sit still, they disturb those waves in measurable ways. RuView captures these disturbances using Channel State Information (CSI) from low-cost ESP32 sensors and turns them into actionable data: who's there, what they're doing, and whether they're okay.
|
||||
Instead of relying on cameras or cloud models, it observes whatever signals exist in a space such as WiFi, radio waves across the spectrum, motion patterns, vibration, sound, or other sensory inputs and builds an understanding of what is happening locally.
|
||||
|
||||
**What it senses:**
|
||||
- **Presence and occupancy** — detect people through walls, count them, track entries and exits
|
||||
- **Vital signs** — breathing rate and heart rate, contactless, while sleeping or sitting
|
||||
- **Activity recognition** — walking, sitting, gestures, falls — from temporal CSI patterns
|
||||
- **Environment mapping** — RF fingerprinting identifies rooms, detects moved furniture, spots new objects
|
||||
- **Sleep quality** — overnight monitoring with sleep stage classification and apnea screening
|
||||
Built on top of [RuVector](https://github.com/ruvnet/ruvector/) Self Learning Vector Memory system and [Cognitum.One](https://Cognitum.One) , the project became widely known for its implementation of WiFi DensePose — a sensing technique first explored in academic research such as Carnegie Mellon University's *DensePose From WiFi* work. That research demonstrated that WiFi signals can be used to reconstruct human pose.
|
||||
|
||||
Built on [RuVector](https://github.com/ruvnet/ruvector/) and [Cognitum Seed](https://cognitum.one), RuView runs entirely on edge hardware — an ESP32 mesh (as low as $9 per node) paired with a Cognitum Seed for persistent memory, cryptographic attestation, and AI integration. No cloud, no cameras, no internet required.
|
||||
RuView extends that concept into a practical edge system. By analyzing Channel State Information (CSI) disturbances caused by human movement, RuView reconstructs body position, breathing rate, heart rate, and presence in real time using physics-based signal processing and machine learning.
|
||||
|
||||
The system learns each environment locally using spiking neural networks that adapt in under 30 seconds, with multi-frequency mesh scanning across 6 WiFi channels that uses your neighbors' routers as free radar illuminators. Every measurement is cryptographically attested via an Ed25519 witness chain.
|
||||
Unlike research systems that rely on synchronized cameras for training, RuView is designed to operate entirely from radio signals and self-learned embeddings at the edge.
|
||||
|
||||
RuView also supports pose estimation (17 COCO keypoints via the WiFlow architecture), trained entirely without cameras using 10 sensor signals — a technique pioneered from the original *DensePose From WiFi* research at Carnegie Mellon University.
|
||||
The system runs entirely on inexpensive hardware such as an ESP32 sensor mesh (as low as ~$1 per node). Small programmable edge modules analyze signals locally and learn the RF signature of a room over time, allowing the system to separate the environment from the activity happening inside it.
|
||||
|
||||
Because RuView learns in proximity to the signals it observes, it improves as it operates. Each deployment develops a local model of its surroundings and continuously adapts without requiring cameras, labeled data, or cloud infrastructure.
|
||||
|
||||
In practice this means ordinary environments gain a new kind of spatial awareness. Rooms, buildings, and devices begin to sense presence, movement, and vital activity using the signals that already fill the space.
|
||||
|
||||
### Built for low-power edge applications
|
||||
|
||||
@@ -40,7 +41,7 @@ RuView also supports pose estimation (17 COCO keypoints via the WiFlow architect
|
||||
|
||||
[](https://www.rust-lang.org/)
|
||||
[](https://opensource.org/licenses/MIT)
|
||||
[](https://github.com/ruvnet/RuView)
|
||||
[](https://github.com/ruvnet/RuView)
|
||||
[](https://hub.docker.com/r/ruvnet/wifi-densepose)
|
||||
[](#vital-sign-detection)
|
||||
[](#esp32-s3-hardware-pipeline)
|
||||
@@ -49,46 +50,27 @@ RuView also supports pose estimation (17 COCO keypoints via the WiFlow architect
|
||||
|
||||
> | What | How | Speed |
|
||||
> |------|-----|-------|
|
||||
> | **Pose estimation** | CSI subcarrier amplitude/phase → 17 COCO keypoints | 171K emb/s (M4 Pro) |
|
||||
> | **Breathing detection** | Bandpass 0.1-0.5 Hz → zero-crossing BPM | 6-30 BPM |
|
||||
> | **Heart rate** | Bandpass 0.8-2.0 Hz → zero-crossing BPM | 40-120 BPM |
|
||||
> | **Presence sensing** | Trained model + PIR fusion — 100% accuracy | 0.012 ms latency |
|
||||
> | **Pose estimation** | CSI subcarrier amplitude/phase → DensePose UV maps | 54K fps (Rust) |
|
||||
> | **Breathing detection** | Bandpass 0.1-0.5 Hz → FFT peak | 6-30 BPM |
|
||||
> | **Heart rate** | Bandpass 0.8-2.0 Hz → FFT peak | 40-120 BPM |
|
||||
> | **Presence sensing** | RSSI variance + motion band power | < 1ms latency |
|
||||
> | **Through-wall** | Fresnel zone geometry + multipath modeling | Up to 5m depth |
|
||||
> | **Edge intelligence** | 8-dim feature vectors + RVF store on Cognitum Seed | $140 total BOM |
|
||||
> | **Camera-free training** | 10 sensor signals, no labels needed | 84s on M4 Pro |
|
||||
> | **Camera-supervised training** | MediaPipe + ESP32 CSI → 92.9% PCK@20 | 19 min on laptop |
|
||||
> | **Multi-frequency mesh** | Channel hopping across 6 bands, neighbor APs as illuminators | 3x sensing bandwidth |
|
||||
|
||||
```bash
|
||||
# Option 1: Docker (simulated data, no hardware needed)
|
||||
# 30 seconds to live sensing — no toolchain required
|
||||
docker pull ruvnet/wifi-densepose:latest
|
||||
docker run -p 3000:3000 ruvnet/wifi-densepose:latest
|
||||
# Open http://localhost:3000
|
||||
|
||||
# Option 2: Live sensing with ESP32-S3 hardware ($9)
|
||||
# Flash firmware, provision WiFi, and start sensing:
|
||||
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
|
||||
python firmware/esp32-csi-node/provision.py --port COM9 \
|
||||
--ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20
|
||||
|
||||
# Option 3: Full system with Cognitum Seed ($140)
|
||||
# ESP32 streams CSI → bridge forwards to Seed for persistent storage + kNN + witness chain
|
||||
node scripts/rf-scan.js --port 5006 # Live RF room scan
|
||||
node scripts/snn-csi-processor.js --port 5006 # SNN real-time learning
|
||||
node scripts/mincut-person-counter.js --port 5006 # Correct person counting
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> **CSI-capable hardware recommended.** Presence, vital signs, through-wall sensing, and all advanced capabilities require Channel State Information (CSI) from an ESP32-S3 ($9) or research NIC. The Docker image runs with simulated data for evaluation. Consumer WiFi laptops provide RSSI-only presence detection.
|
||||
> **CSI-capable hardware required.** Pose estimation, vital signs, and through-wall sensing rely on Channel State Information (CSI) — per-subcarrier amplitude and phase data that standard consumer WiFi does not expose. You need CSI-capable hardware (ESP32-S3 or a research NIC) for full functionality. Consumer WiFi laptops can only provide RSSI-based presence detection, which is significantly less capable.
|
||||
|
||||
> **Hardware options** for live CSI capture:
|
||||
>
|
||||
> | Option | Hardware | Cost | Full CSI | Capabilities |
|
||||
> |--------|----------|------|----------|-------------|
|
||||
> | **ESP32 + Cognitum Seed** (recommended) | ESP32-S3 + [Cognitum Seed](https://cognitum.one) | ~$140 | Yes | Pose, breathing, heartbeat, motion, presence + persistent vector store, kNN search, witness chain, MCP proxy |
|
||||
> | **ESP32 Mesh** | 3-6x ESP32-S3 + WiFi router | ~$54 | Yes | Pose, breathing, heartbeat, motion, presence |
|
||||
> | **ESP32 Mesh** (recommended) | 3-6x ESP32-S3 + WiFi router | ~$54 | Yes | Pose, breathing, heartbeat, motion, presence |
|
||||
> | **Research NIC** | Intel 5300 / Atheros AR9580 | ~$50-100 | Yes | Full CSI with 3x3 MIMO |
|
||||
> | **Any WiFi** | Windows, macOS, or Linux laptop | $0 | No | RSSI-only: coarse presence and motion |
|
||||
>
|
||||
@@ -96,249 +78,13 @@ node scripts/mincut-person-counter.js --port 5006 # Correct person counting
|
||||
>
|
||||
---
|
||||
|
||||
### What's New in v0.7.0
|
||||
|
||||
<details>
|
||||
<summary><strong>Camera Ground-Truth Training — 92.9% PCK@20</strong></summary>
|
||||
|
||||
**v0.7.0 adds camera-supervised pose training** using MediaPipe + real ESP32 CSI data:
|
||||
|
||||
| Capability | What it does | ADR |
|
||||
|-----------|-------------|-----|
|
||||
| **Camera ground-truth collection** | MediaPipe PoseLandmarker captures 17 COCO keypoints at 30fps, synced with ESP32 CSI | [ADR-079](docs/adr/ADR-079-camera-ground-truth-training.md) |
|
||||
| **ruvector subcarrier selection** | Variance-based top-K reduces input by 50% (70→35 subcarriers) | ADR-079 O6 |
|
||||
| **Stoer-Wagner min-cut** | Person-specific subcarrier cluster separation for multi-person training | ADR-079 O8 |
|
||||
| **Scalable WiFlow model** | 4 presets: lite (189K) → small (474K) → medium (800K) → full (7.7M params) | ADR-079 |
|
||||
|
||||
```bash
|
||||
# Collect ground truth (camera + ESP32 simultaneously)
|
||||
python scripts/collect-ground-truth.py --duration 300 --preview
|
||||
python scripts/record-csi-udp.py --duration 300
|
||||
|
||||
# Align CSI windows with camera keypoints
|
||||
node scripts/align-ground-truth.js --gt data/ground-truth/*.jsonl --csi data/recordings/*.csi.jsonl
|
||||
|
||||
# Train WiFlow model (start lite, scale up as data grows)
|
||||
node scripts/train-wiflow-supervised.js --data data/paired/*.jsonl --scale lite
|
||||
|
||||
# Evaluate
|
||||
node scripts/eval-wiflow.js --model models/wiflow-real/wiflow-v1.json --data data/paired/*.jsonl
|
||||
```
|
||||
|
||||
**Result: 92.9% PCK@20** from a 5-minute data collection session with one ESP32-S3 and one webcam.
|
||||
|
||||
| Metric | Before (proxy) | After (camera-supervised) |
|
||||
|--------|----------------|--------------------------|
|
||||
| PCK@20 | 0% | **92.9%** |
|
||||
| Eval loss | 0.700 | **0.082** |
|
||||
| Bone constraint | N/A | **0.008** |
|
||||
| Training time | N/A | **19 minutes** |
|
||||
| Model size | N/A | **974 KB** |
|
||||
|
||||
Pre-trained model: [HuggingFace ruv/ruview/wiflow-v1](https://huggingface.co/ruv/ruview)
|
||||
|
||||
</details>
|
||||
|
||||
### Pre-Trained Models (v0.6.0) — No Training Required
|
||||
|
||||
<details>
|
||||
<summary><strong>Download from HuggingFace and start sensing immediately</strong></summary>
|
||||
|
||||
Pre-trained models are available on HuggingFace:
|
||||
> **https://huggingface.co/ruv/ruview** (primary) | [mirror](https://huggingface.co/ruvnet/wifi-densepose-pretrained)
|
||||
|
||||
Trained on 60,630 real-world samples from an 8-hour overnight collection. Just download and run — no datasets, no GPU, no training needed.
|
||||
|
||||
| Model | Size | What it does |
|
||||
|-------|------|-------------|
|
||||
| `model.safetensors` | 48 KB | Contrastive encoder — 128-dim embeddings for presence, activity, environment |
|
||||
| `model-q4.bin` | 8 KB | 4-bit quantized — fits in ESP32-S3 SRAM for edge inference |
|
||||
| `model-q2.bin` | 4 KB | 2-bit ultra-compact for memory-constrained devices |
|
||||
| `presence-head.json` | 2.6 KB | 100% accurate presence detection head |
|
||||
| `node-1.json` / `node-2.json` | 21 KB | Per-room LoRA adapters (swap for new rooms) |
|
||||
|
||||
```bash
|
||||
# Download and use (Python)
|
||||
pip install huggingface_hub
|
||||
huggingface-cli download ruv/ruview --local-dir models/
|
||||
|
||||
# Or use directly with the sensing pipeline
|
||||
node scripts/train-ruvllm.js --data data/recordings/*.csi.jsonl # retrain on your own data
|
||||
node scripts/benchmark-ruvllm.js --model models/csi-ruvllm # benchmark
|
||||
```
|
||||
|
||||
**Benchmarks (Apple M4 Pro, retrained on overnight data):**
|
||||
|
||||
| What we measured | Result | Why it matters |
|
||||
|-----------------|--------|---------------|
|
||||
| **Presence detection** | **100% accuracy** | Never misses a person, never false alarms |
|
||||
| **Inference speed** | **0.008 ms** per embedding | 125,000x faster than real-time |
|
||||
| **Throughput** | **164,183 embeddings/sec** | One Mac Mini handles 1,600+ ESP32 nodes |
|
||||
| **Contrastive learning** | **51.6% improvement** | Strong pattern learning from real overnight data |
|
||||
| **Model size** | **8 KB** (4-bit quantized) | Fits in ESP32 SRAM — no server needed |
|
||||
| **Total hardware cost** | **$140** | ESP32 ($9) + [Cognitum Seed](https://cognitum.one) ($131) |
|
||||
|
||||
</details>
|
||||
|
||||
### 17 Sensing Applications (v0.6.0)
|
||||
|
||||
<details>
|
||||
<summary><strong>Health, environment, security, and multi-frequency mesh sensing</strong></summary>
|
||||
|
||||
All applications run from a single ESP32 + optional Cognitum Seed. No camera, no cloud, no internet.
|
||||
|
||||
**Health & Wellness:**
|
||||
|
||||
| Application | Script | What it detects |
|
||||
|------------|--------|----------------|
|
||||
| Sleep Monitor | `node scripts/sleep-monitor.js` | Sleep stages (deep/light/REM/awake), efficiency, hypnogram |
|
||||
| Apnea Detector | `node scripts/apnea-detector.js` | Breathing pauses >10s, AHI severity scoring |
|
||||
| Stress Monitor | `node scripts/stress-monitor.js` | Heart rate variability, LF/HF stress ratio |
|
||||
| Gait Analyzer | `node scripts/gait-analyzer.js` | Walking cadence, stride asymmetry, tremor detection |
|
||||
|
||||
**Environment & Security:**
|
||||
|
||||
| Application | Script | What it detects |
|
||||
|------------|--------|----------------|
|
||||
| Person Counter | `node scripts/mincut-person-counter.js` | Correct occupancy count (fixes #348) |
|
||||
| Room Fingerprint | `node scripts/room-fingerprint.js` | Activity state clustering, daily patterns, anomalies |
|
||||
| Material Detector | `node scripts/material-detector.js` | New/moved objects via subcarrier null changes |
|
||||
| Device Fingerprint | `node scripts/device-fingerprint.js` | Electronic device activity (printer, router, etc.) |
|
||||
|
||||
**Multi-Frequency Mesh** (requires `--hop-channels` provisioning):
|
||||
|
||||
| Application | Script | What it detects |
|
||||
|------------|--------|----------------|
|
||||
| RF Tomography | `node scripts/rf-tomography.js` | 2D room imaging via RF backprojection |
|
||||
| Passive Radar | `node scripts/passive-radar.js` | Neighbor WiFi APs as bistatic radar illuminators |
|
||||
| Material Classifier | `node scripts/material-classifier.js` | Metal/water/wood/glass from frequency response |
|
||||
| Through-Wall | `node scripts/through-wall-detector.js` | Motion behind walls using lower-frequency penetration |
|
||||
|
||||
All scripts support `--replay data/recordings/*.csi.jsonl` for offline analysis and `--json` for programmatic output.
|
||||
|
||||
</details>
|
||||
|
||||
### What's New in v0.5.5
|
||||
|
||||
<details>
|
||||
<summary><strong>Advanced Sensing: SNN + MinCut + WiFlow + Multi-Frequency Mesh</strong></summary>
|
||||
|
||||
**v0.5.5 adds four new sensing capabilities** built on the [ruvector](https://github.com/ruvnet/ruvector) ecosystem:
|
||||
|
||||
| Capability | What it does | ADR |
|
||||
|-----------|-------------|-----|
|
||||
| **Spiking Neural Network** | Adapts to your room in <30s with STDP online learning — no labels, no batches, 16-160x less compute | [ADR-074](docs/adr/ADR-074-spiking-neural-csi-sensing.md) |
|
||||
| **MinCut Person Counting** | Stoer-Wagner min-cut on subcarrier correlation graph — **fixes #348** (was always 4, now correct) | [ADR-075](docs/adr/ADR-075-mincut-person-separation.md) |
|
||||
| **CNN Spectrogram Embeddings** | Treat CSI as a 64×20 image → 128-dim embedding for environment fingerprinting (0.95+ similarity) | [ADR-076](docs/adr/ADR-076-csi-spectrogram-embeddings.md) |
|
||||
| **WiFlow SOTA Architecture** | TCN + axial attention + pose decoder → 17 COCO keypoints, 1.8M params (881 KB at 4-bit) | [ADR-072](docs/adr/ADR-072-wiflow-architecture.md) |
|
||||
| **Multi-Frequency Mesh** | Channel hopping across 6 bands, neighbor WiFi as passive radar illuminators | [ADR-073](docs/adr/ADR-073-multifrequency-mesh-scan.md) |
|
||||
|
||||
```bash
|
||||
# Live RF room scan (spectrum visualization)
|
||||
node scripts/rf-scan.js --port 5006 --duration 30
|
||||
|
||||
# Correct person counting (fixes #348)
|
||||
node scripts/mincut-person-counter.js --port 5006
|
||||
|
||||
# SNN real-time adaptation
|
||||
node scripts/snn-csi-processor.js --port 5006
|
||||
|
||||
# CNN spectrogram embeddings
|
||||
node scripts/csi-spectrogram.js --replay data/recordings/*.csi.jsonl
|
||||
|
||||
# WiFlow 17-keypoint pose training
|
||||
node scripts/train-wiflow.js --data data/recordings/*.csi.jsonl
|
||||
|
||||
# Enable channel hopping on ESP32
|
||||
python firmware/esp32-csi-node/provision.py --port COM9 --hop-channels "1,6,11"
|
||||
```
|
||||
|
||||
**Validated benchmarks:**
|
||||
|
||||
| Metric | v0.5.4 | v0.5.5 |
|
||||
|--------|--------|--------|
|
||||
| Person counting | Broken (always 4) | **Correct** (MinCut, 24/24) |
|
||||
| WiFi channels | 1 | **6** (multi-freq hopping) |
|
||||
| Null subcarriers | 19% blocked | **16%** (frequency diversity) |
|
||||
| Pose model | 16K params (FC only) | **1.8M params** (WiFlow) |
|
||||
| Online adaptation | None | **<30s** (SNN STDP) |
|
||||
| Fingerprint dims | 8 | **128** (CNN spectrogram) |
|
||||
| Multi-node fusion | Average | **GATv2 attention** |
|
||||
| New scripts | 0 | **15+** |
|
||||
| New ADRs | 3 | **8** (069-076) |
|
||||
|
||||
</details>
|
||||
|
||||
### What's New in v0.5.4
|
||||
|
||||
<details>
|
||||
<summary><strong>Cognitum Seed Integration + Camera-Free Pose Training</strong></summary>
|
||||
|
||||
**v0.5.4 transforms RuView from a real-time sensing tool into a persistent edge AI system.** Your ESP32 now remembers what it senses, learns without cameras, and proves its data cryptographically.
|
||||
|
||||
| Capability | Details | Hardware |
|
||||
|-----------|---------|----------|
|
||||
| **Persistent vector store** | Every sensing event stored as searchable 8-dim vector in RVF format | ESP32 + [Cognitum Seed](https://cognitum.one) ($140) |
|
||||
| **kNN similarity search** | "Find the 10 most similar states to right now" — anomaly detection, fingerprinting | Cognitum Seed |
|
||||
| **Witness chain** | SHA-256 tamper-evident audit trail for every measurement (1,747 entries validated) | Cognitum Seed |
|
||||
| **Camera-free pose training** | 17 COCO keypoints from 10 sensor signals — PIR, RSSI triangulation, subcarrier asymmetry, vibration, BME280 | 2x ESP32 + Seed |
|
||||
| **Pre-trained model** | 82.8 KB (8 KB at 4-bit quantization), 100% presence accuracy, 0 skeleton violations | Download from release |
|
||||
| **Sub-ms inference** | 0.012 ms latency, 171,472 embeddings/sec on M4 Pro | Any machine with Node.js |
|
||||
| **SONA adaptation** | Adapts to new rooms in <1ms without retraining | ruvllm runtime |
|
||||
| **LoRA room adapters** | Per-node fine-tuning with 2,048 parameters per adapter | Automatic |
|
||||
| **114-tool MCP proxy** | AI assistants (Claude, GPT) query sensors directly via JSON-RPC | Cognitum Seed |
|
||||
| **Multi-frequency mesh** | Channel hopping across ch 1/3/5/6/9/11 — neighbor WiFi as passive radar | 2x ESP32 ($18) |
|
||||
| **RF room scanner** | Real-time spectrum visualization: nulls, reflectors, movement, multipath | `node scripts/rf-scan.js` |
|
||||
| **Security hardened** | Bearer tokens, TLS, source IP filtering, NaN rejection, credential rotation | All components |
|
||||
|
||||
**Training pipeline (ruvllm, no PyTorch needed):**
|
||||
|
||||
```bash
|
||||
# Collect data (2 min, ESP32s must be streaming)
|
||||
python scripts/collect-training-data.py --port 5006 --duration 120
|
||||
|
||||
# Train — contrastive pretraining + task heads + LoRA + quantization + EWC
|
||||
node scripts/train-ruvllm.js --data data/recordings/pretrain-*.csi.jsonl
|
||||
|
||||
# Camera-free 17-keypoint pose (uses PIR + RSSI + vibration + subcarrier asymmetry)
|
||||
node scripts/train-camera-free.js --data data/recordings/pretrain-*.csi.jsonl
|
||||
|
||||
# Benchmark
|
||||
node scripts/benchmark-ruvllm.js --model models/csi-ruvllm
|
||||
```
|
||||
|
||||
**Benchmarks — validated on real hardware (Apple M4 Pro + ESP32-S3 + Cognitum Seed):**
|
||||
|
||||
| What we measured | Result | Why it matters |
|
||||
|-----------------|--------|---------------|
|
||||
| **Presence detection** | **100% accuracy** | Never misses a person, never false alarms |
|
||||
| **Person counting** | **24/24 correct** (MinCut) | Fixed the #1 user-reported issue |
|
||||
| **Inference speed** | **0.012 ms** per embedding | 83,000x faster than real-time |
|
||||
| **Throughput** | **171,472 embeddings/sec** | One Mac Mini handles 1,700+ ESP32 nodes |
|
||||
| **Training time** | **84 seconds** | From zero to trained model in under 2 minutes |
|
||||
| **Contrastive learning** | **33.9% improvement** | Model learns meaningful patterns from CSI |
|
||||
| **Model size** | **8 KB** (4-bit quantized) | Fits in ESP32 SRAM — no server needed |
|
||||
| **Skeleton physics** | **0 violations** in 100 frames | Every pose is anatomically valid |
|
||||
| **Pose keypoints** | **17 COCO keypoints** | Full body pose, no camera required |
|
||||
| **WiFi channels** | **6 simultaneous** | 3x more sensing data than single-channel |
|
||||
| **Online adaptation** | **<30 seconds** (SNN) | Learns a new room without retraining |
|
||||
| **Witness chain** | **2,547 entries** verified | Cryptographic proof every measurement is real |
|
||||
| **Test suite** | **1,463 tests passed** | Rock-solid foundation |
|
||||
| **Total hardware cost** | **$140** | ESP32 ($9) + [Cognitum Seed](https://cognitum.one) ($131) |
|
||||
|
||||
See [ADR-069](docs/adr/ADR-069-cognitum-seed-csi-pipeline.md), [ADR-071](docs/adr/ADR-071-ruvllm-training-pipeline.md), and the [Cognitum Seed tutorial](docs/tutorials/cognitum-seed-pretraining.md) for full details.
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## 📖 Documentation
|
||||
|
||||
| Document | Description |
|
||||
|----------|-------------|
|
||||
| [User Guide](docs/user-guide.md) | Step-by-step guide: installation, first run, API usage, hardware setup, training |
|
||||
| [Build Guide](docs/build-guide.md) | Building from source (Rust and Python) |
|
||||
| [Architecture Decisions](docs/adr/README.md) | 79 ADRs — why each technical choice was made, organized by domain (hardware, signal processing, ML, platform, infrastructure) |
|
||||
| [Architecture Decisions](docs/adr/README.md) | 62 ADRs — why each technical choice was made, organized by domain (hardware, signal processing, ML, platform, infrastructure) |
|
||||
| [Domain Models](docs/ddd/README.md) | 7 DDD models (RuvSense, Signal Processing, Training Pipeline, Hardware Platform, Sensing Server, WiFi-Mat, CHCI) — bounded contexts, aggregates, domain events, and ubiquitous language |
|
||||
| [Desktop App](rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/README.md) | **WIP** — Tauri v2 desktop app for node management, OTA updates, WASM deployment, and mesh visualization |
|
||||
| [Medical Examples](examples/medical/README.md) | Contactless blood pressure, heart rate, breathing rate via 60 GHz mmWave radar — $15 hardware, no wearable |
|
||||
@@ -1311,11 +1057,7 @@ Download a pre-built binary — no build toolchain needed:
|
||||
|
||||
| Release | What's included | Tag |
|
||||
|---------|-----------------|-----|
|
||||
| [v0.7.0](https://github.com/ruvnet/RuView/releases/tag/v0.7.0) | **Latest** — Camera-supervised WiFlow model (92.9% PCK@20), ground-truth training pipeline, ruvector optimizations | `v0.7.0` |
|
||||
| [v0.6.0](https://github.com/ruvnet/RuView/releases/tag/v0.6.0-esp32) | [Pre-trained models on HuggingFace](https://huggingface.co/ruv/ruview), 17 sensing apps, 51.6% contrastive improvement, 0.008ms inference | `v0.6.0-esp32` |
|
||||
| [v0.5.5](https://github.com/ruvnet/RuView/releases/tag/v0.5.5-esp32) | SNN + MinCut (#348 fix) + CNN spectrogram + WiFlow + multi-freq mesh + graph transformer | `v0.5.5-esp32` |
|
||||
| [v0.5.4](https://github.com/ruvnet/RuView/releases/tag/v0.5.4-esp32) | Cognitum Seed integration ([ADR-069](docs/adr/ADR-069-cognitum-seed-csi-pipeline.md)), 8-dim feature vectors, RVF store, witness chain, security hardening | `v0.5.4-esp32` |
|
||||
| [v0.5.0](https://github.com/ruvnet/RuView/releases/tag/v0.5.0-esp32) | mmWave sensor fusion ([ADR-063](docs/adr/ADR-063-mmwave-sensor-fusion.md)), auto-detect MR60BHA2/LD2410, 48-byte fused vitals, all v0.4.3.1 fixes | `v0.5.0-esp32` |
|
||||
| [v0.5.0](https://github.com/ruvnet/RuView/releases/tag/v0.5.0-esp32) | **Stable** — mmWave sensor fusion ([ADR-063](docs/adr/ADR-063-mmwave-sensor-fusion.md)), auto-detect MR60BHA2/LD2410, 48-byte fused vitals, all v0.4.3.1 fixes | `v0.5.0-esp32` |
|
||||
| [v0.4.3.1](https://github.com/ruvnet/RuView/releases/tag/v0.4.3.1-esp32) | Fall detection fix ([#263](https://github.com/ruvnet/RuView/issues/263)), 4MB flash ([#265](https://github.com/ruvnet/RuView/issues/265)), watchdog fix ([#266](https://github.com/ruvnet/RuView/issues/266)) | `v0.4.3.1-esp32` |
|
||||
| [v0.4.1](https://github.com/ruvnet/RuView/releases/tag/v0.4.1-esp32) | CSI build fix, compile guard, AMOLED display, edge intelligence ([ADR-057](docs/adr/ADR-057-firmware-csi-build-guard.md)) | `v0.4.1-esp32` |
|
||||
| [v0.3.0-alpha](https://github.com/ruvnet/RuView/releases/tag/v0.3.0-alpha-esp32) | Alpha — adds on-device edge intelligence and WASM modules ([ADR-039](docs/adr/ADR-039-esp32-edge-intelligence.md), [ADR-040](docs/adr/ADR-040-wasm-programmable-sensing.md)) | `v0.3.0-alpha-esp32` |
|
||||
@@ -1361,34 +1103,6 @@ python firmware/esp32-csi-node/provision.py --port COM8 \
|
||||
|
||||
Nodes can also hop across WiFi channels (1, 6, 11) to increase sensing bandwidth — configured via [ADR-029](docs/adr/ADR-029-ruvsense-multistatic-sensing-mode.md) channel hopping.
|
||||
|
||||
### Cognitum Seed integration (ADR-069)
|
||||
|
||||
Connect an ESP32 to a [Cognitum Seed](https://cognitum.one) ($131) for persistent vector storage, kNN search, cryptographic witness chain, and AI-accessible MCP proxy:
|
||||
|
||||
```
|
||||
ESP32-S3 ($9) ──UDP──> Host bridge ──HTTPS──> Cognitum Seed ($15)
|
||||
CSI capture seed_csi_bridge.py RVF vector store
|
||||
8-dim features @ 1 Hz kNN similarity search
|
||||
Vitals + presence Ed25519 witness chain
|
||||
114-tool MCP proxy
|
||||
```
|
||||
|
||||
```bash
|
||||
# 1. Provision ESP32 to send features to your laptop
|
||||
python firmware/esp32-csi-node/provision.py --port COM9 \
|
||||
--ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20 --target-port 5006
|
||||
|
||||
# 2. Run the bridge (forwards to Seed via HTTPS)
|
||||
export SEED_TOKEN="your-pairing-token"
|
||||
python scripts/seed_csi_bridge.py \
|
||||
--seed-url https://169.254.42.1:8443 --token "$SEED_TOKEN" --validate
|
||||
|
||||
# 3. Check Seed stats
|
||||
python scripts/seed_csi_bridge.py --token "$SEED_TOKEN" --stats
|
||||
```
|
||||
|
||||
The 8-dim feature vector captures: presence, motion, breathing rate, heart rate, phase variance, person count, fall detection, and RSSI — all normalized to [0.0, 1.0]. See [ADR-069](docs/adr/ADR-069-cognitum-seed-csi-pipeline.md) for the full architecture.
|
||||
|
||||
### On-device intelligence (v0.3.0-alpha)
|
||||
|
||||
The alpha firmware can analyze signals locally and send compact results instead of raw data. This means the ESP32 works standalone — no server needed for basic sensing. Disabled by default for backward compatibility.
|
||||
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -1,15 +0,0 @@
|
||||
{
|
||||
"id": "pretrain-1775182186",
|
||||
"name": "pretrain-1775182186",
|
||||
"label": "mixed-activity",
|
||||
"started_at": "2026-04-03T02:09:46Z",
|
||||
"ended_at": "2026-04-03T02:11:46Z",
|
||||
"duration_secs": 120,
|
||||
"frame_count": 5783,
|
||||
"file_size_bytes": 2580539,
|
||||
"file_path": "data/recordings\\pretrain-1775182186.csi.jsonl",
|
||||
"nodes": {
|
||||
"2": 2886,
|
||||
"1": 2897
|
||||
}
|
||||
}
|
||||
@@ -24,7 +24,7 @@ No on-device processing. CSI frames streamed as-is (magic `0xC5110001`).
|
||||
- Phase extraction and unwrapping from I/Q pairs
|
||||
- Welford running variance per subcarrier
|
||||
- Top-K subcarrier selection by variance
|
||||
- Delta compression (XOR + RLE) for 30-50% bandwidth reduction (magic `0xC5110005`, reassigned from `0xC5110003` by ADR-069)
|
||||
- Delta compression (XOR + RLE) for 30-50% bandwidth reduction (magic `0xC5110003`)
|
||||
|
||||
### Tier 2 — Full Edge Intelligence
|
||||
All of Tier 1, plus:
|
||||
@@ -50,7 +50,7 @@ Core 0 (WiFi) Core 1 (DSP)
|
||||
│ Multi-person clustering │
|
||||
│ Delta compression │
|
||||
│ ──▶ UDP vitals (0xC5110002)│
|
||||
│ ──▶ UDP compressed (0x05) │
|
||||
│ ──▶ UDP compressed (0x03) │
|
||||
└──────────────────────────┘
|
||||
```
|
||||
|
||||
@@ -73,11 +73,11 @@ Core 0 (WiFi) Core 1 (DSP)
|
||||
| 24-27 | u32 LE | Timestamp (ms since boot) |
|
||||
| 28-31 | u32 LE | Reserved |
|
||||
|
||||
**Compressed Frame (magic `0xC5110005`, reassigned from `0xC5110003` by ADR-069)**:
|
||||
**Compressed Frame (magic `0xC5110003`)**:
|
||||
|
||||
| Offset | Type | Field |
|
||||
|--------|------|-------|
|
||||
| 0-3 | u32 LE | Magic `0xC5110005` |
|
||||
| 0-3 | u32 LE | Magic `0xC5110003` |
|
||||
| 4 | u8 | Node ID |
|
||||
| 5 | u8 | WiFi channel |
|
||||
| 6-7 | u16 LE | Original I/Q length |
|
||||
|
||||
@@ -265,10 +265,6 @@ python provision.py --port COM8 \
|
||||
- **Pi Zero 2 W limits** — 512 MB RAM, single-core ARM; adequate for 20 nodes but not 100+
|
||||
- **No WASM OTA via Seed** — currently WASM modules are uploaded per-node; future work could use Seed as WASM distribution hub
|
||||
|
||||
### Implementation Progress
|
||||
|
||||
**ADR-069** implements the first stage of this swarm vision with live hardware validation (2026-04-02). A single ESP32-S3 node (COM9, firmware v0.5.2) was validated sending CSI-derived feature vectors through a host-side bridge into the Cognitum Seed's RVF store (firmware v0.8.1). The pipeline confirmed: UDP streaming (211 packets/15s), 8-dim feature extraction, batched HTTPS ingest (4 batches of 5 vectors), and witness chain integrity (193 entries, SHA-256 verified). Multi-node deployment (Phase 4 of ADR-069) is the next step toward the full swarm architecture described here.
|
||||
|
||||
### Future Work
|
||||
|
||||
- **Seed-initiated WASM push** — Seed distributes WASM modules to all nodes via their OTA endpoints
|
||||
|
||||
@@ -171,10 +171,6 @@ Validation plan:
|
||||
- Node ID collisions (mitigated by NVS persistence since v0.5.0)
|
||||
- HashMap growth without cleanup (mitigated by stale-node eviction)
|
||||
|
||||
## Related ADRs
|
||||
|
||||
- **ADR-069** (ESP32 CSI → Cognitum Seed RVF Ingest Pipeline) extends this ADR's per-node state architecture with Cognitum Seed integration. Live hardware validation (2026-04-02) confirmed per-node feature vectors flowing through the bridge into the Seed's RVF store with witness chain attestation.
|
||||
|
||||
## References
|
||||
|
||||
- Issue #249: Detection window same regardless (24 comments)
|
||||
|
||||
@@ -1,403 +0,0 @@
|
||||
# ADR-069: ESP32 CSI → Cognitum Seed RVF Ingest Pipeline
|
||||
|
||||
| Field | Value |
|
||||
|------------|----------------------------------------------------------|
|
||||
| Status | Accepted |
|
||||
| Date | 2026-04-02 |
|
||||
| Authors | rUv, claude-flow |
|
||||
| Drivers | #348 (multinode mesh accuracy), Research: Arena Physica |
|
||||
| Supersedes | — |
|
||||
| Related | ADR-066 (ESP32 swarm + Seed coordinator), ADR-068 (per-node state), ADR-018 (CSI binary protocol), ADR-039 (edge intelligence), ADR-065 (happiness scoring + Seed bridge) |
|
||||
|
||||
## Context
|
||||
|
||||
The wifi-densepose project has two hardware components that need to work as an integrated sensing pipeline:
|
||||
|
||||
1. **ESP32-S3** (COM9 / 192.168.1.105) — Captures WiFi CSI at 100 Hz, runs dual-core DSP pipeline (phase extraction, subcarrier selection, breathing/heart rate estimation, presence/fall detection), and sends ADR-018 binary frames via UDP.
|
||||
|
||||
2. **Cognitum Seed** (USB / 169.254.42.1 / 192.168.1.109) — A Pi Zero 2 W edge intelligence appliance running firmware v0.8.1. It provides:
|
||||
- **RVF vector store** — Append-only binary format with content-addressed IDs, kNN queries (cosine/L2/dot), and kNN graph with boundary analysis
|
||||
- **Witness chain** — SHA-256 tamper-evident audit trail for every write operation
|
||||
- **Ed25519 custody** — Device-bound keypair for cryptographic attestation
|
||||
- **Sensor pipeline** — 5 sensors (reed switch, PIR, vibration, ADS1115 4-ch ADC, BME280), 13 drift detectors, anti-spoofing
|
||||
- **Cognitive container** — Spectral graph analysis with Stoer-Wagner min-cut fragility scoring
|
||||
- **MCP proxy** — 114 tools via JSON-RPC 2.0 for AI assistant integration
|
||||
- **Thermal governor** — DVFS management with zone-based frequency scaling
|
||||
- **Temporal coherence** — Phase boundary detection across vector store evolution
|
||||
- **Swarm sync** — Epoch-based delta replication between peers
|
||||
- **Reflex rules** — 3 rules (fragility alarm, drift cutoff, HD anomaly indicator)
|
||||
- **98 HTTPS API endpoints** with per-client bearer token authentication
|
||||
|
||||
### Current State
|
||||
|
||||
| Component | Status | Details |
|
||||
|-----------|--------|---------|
|
||||
| ESP32 CSI capture | Working | 100 Hz, ADR-018 binary frames via UDP |
|
||||
| ESP32 edge DSP | Working | 10-stage pipeline on Core 1 (phase, variance, vitals, fall) |
|
||||
| ESP32 → sensing-server | Working | UDP port 5005, binary protocol |
|
||||
| Cognitum Seed | Online | v0.8.1, paired, 19 vectors, epoch 25, WiFi connected |
|
||||
| Seed vector store | Working | 8-dim RVF, kNN queries in 85ms for 20k vectors |
|
||||
| Seed MCP proxy | Working | 114 tools, default-deny policy |
|
||||
| ESP32 → Seed pipeline | **Validated** | Bridge on host laptop, UDP 5006 → HTTPS ingest (see Validation Results) |
|
||||
|
||||
### Gap Analysis (from Arena Physica research)
|
||||
|
||||
Arena Physica's approach (Heaviside-0 forward model, Marconi-0 inverse diffusion) demonstrates that neural surrogates for Maxwell's equations are production-viable. Our research identified that:
|
||||
|
||||
1. **Physics-informed intermediate supervision** — Evaluating pipeline stages independently catches failures that end-to-end metrics miss
|
||||
2. **Vector embeddings for EM fields** — Storing CSI features as vectors enables similarity search for environment fingerprinting and anomaly detection
|
||||
3. **Witness chain for sensing integrity** — Tamper-evident audit trails are critical for healthcare/safety applications (fall detection, vital signs)
|
||||
4. **Edge compute for inference** — Pi Zero 2 W can run ~2.5M parameter models at 10+ Hz with INT8 quantization
|
||||
|
||||
### Problem
|
||||
|
||||
There is no pipeline connecting ESP32 CSI sensing to the Cognitum Seed's vector store. The ESP32 sends raw CSI frames to the Rust sensing-server (typically running on a laptop/desktop), but cannot leverage the Seed's:
|
||||
- Persistent vector storage with kNN search
|
||||
- Cryptographic witness chain for data integrity
|
||||
- Cognitive container for structural analysis
|
||||
- Sensor fusion with environmental sensors (BME280 temperature/humidity, PIR motion)
|
||||
- Swarm sync for multi-Seed deployments
|
||||
|
||||
## Decision
|
||||
|
||||
Build a three-stage pipeline connecting ESP32 CSI capture to Cognitum Seed RVF storage:
|
||||
|
||||
### Architecture
|
||||
|
||||
```
|
||||
┌──────────────────────────┐
|
||||
│ ESP32-S3 (COM9) │
|
||||
│ node_id=1 │
|
||||
│ 192.168.1.105 │
|
||||
│ Firmware v0.5.2 │
|
||||
│ ┌──────────────────────┐ │
|
||||
│ │ Core 0: WiFi + CSI │ │
|
||||
│ │ 100 Hz capture │ │
|
||||
│ │ ADR-018 framing │ │
|
||||
│ ├──────────────────────┤ │
|
||||
│ │ Core 1: Edge DSP │ │
|
||||
│ │ Phase extraction │ │
|
||||
│ │ Subcarrier select │ │
|
||||
│ │ Vital signs (HR/BR)│ │
|
||||
│ │ Presence/fall det. │ │
|
||||
│ │ Feature vector │ │◄── 8-dim feature extraction
|
||||
│ └──────────┬───────────┘ │
|
||||
│ │ UDP │
|
||||
└────────────┼─────────────┘
|
||||
│ Port 5005 (raw CSI, magic 0xC5110001)
|
||||
│ + Port 5006 (vitals 0xC5110002 + features 0xC5110003)
|
||||
▼
|
||||
┌────────────────────────────────────────────┐
|
||||
│ Host Laptop (192.168.1.20) │
|
||||
│ Bridge script (Python) │
|
||||
│ ┌────────────────────────────────────────┐ │
|
||||
│ │ Stage 1: CSI Receiver │ │
|
||||
│ │ UDP listener on port 5006 │ │
|
||||
│ │ Parses 0xC5110003 feature packets │ │
|
||||
│ │ (also accepts 0xC5110001/0002) │ │
|
||||
│ │ Batches 10 vectors per ingest │ │
|
||||
│ └──────────┬─────────────────────────────┘ │
|
||||
└────────────┼───────────────────────────────┘
|
||||
│ HTTPS POST (bearer token)
|
||||
▼
|
||||
┌────────────────────────────────────────────┐
|
||||
│ Cognitum Seed (Pi Zero 2 W) │
|
||||
│ 169.254.42.1 / 192.168.1.109 │
|
||||
│ Firmware v0.8.1 │
|
||||
│ ┌────────────────────────────────────────┐ │
|
||||
│ │ Stage 2: RVF Ingest │ │
|
||||
│ │ POST /api/v1/store/ingest │ │
|
||||
│ │ Content-addressed vector ID │ │
|
||||
│ │ Metadata: node_id, timestamp, type │ │
|
||||
│ │ Witness chain entry per batch │ │
|
||||
│ ├────────────────────────────────────────┤ │
|
||||
│ │ Stage 3: Cognitive Analysis │ │
|
||||
│ │ kNN graph rebuild (every 10s) │ │
|
||||
│ │ Boundary analysis (fragility) │ │
|
||||
│ │ Temporal coherence (phase detect) │ │
|
||||
│ │ Reflex rules (alarm triggers) │ │
|
||||
│ ├────────────────────────────────────────┤ │
|
||||
│ │ Existing Sensors │ │
|
||||
│ │ BME280 → temp/humidity/pressure │ │
|
||||
│ │ PIR → motion ground truth │ │
|
||||
│ │ Reed switch → door/window state │ │
|
||||
│ │ ADS1115 → analog inputs │ │
|
||||
│ └────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Outputs: │
|
||||
│ • /api/v1/store/query — kNN search │
|
||||
│ • /api/v1/boundary — fragility score │
|
||||
│ • /api/v1/coherence/profile — phases │
|
||||
│ • /api/v1/cognitive/snapshot — graph │
|
||||
│ • /api/v1/custody/attestation — signed │
|
||||
│ • MCP proxy — 114 tools for AI agents │
|
||||
└────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Stage 1: ESP32 Feature Vector Extraction
|
||||
|
||||
The ESP32 edge processing pipeline (Core 1) already computes all signals needed. We add a compact 8-dimensional feature vector extracted from the existing DSP outputs:
|
||||
|
||||
| Dimension | Feature | Source | Range |
|
||||
|-----------|---------|--------|-------|
|
||||
| 0 | Presence score | `s_presence_score / 10.0` (clamped) | 0.0–1.0 |
|
||||
| 1 | Motion energy | `s_motion_energy / 10.0` (clamped) | 0.0–1.0 |
|
||||
| 2 | Breathing rate | `s_breathing_bpm / 30.0` (clamped) | 0.0–1.0 |
|
||||
| 3 | Heart rate | `s_heartrate_bpm / 120.0` (clamped) | 0.0–1.0 |
|
||||
| 4 | Phase variance (mean) | Top-K subcarrier Welford variance mean | 0.0–1.0 |
|
||||
| 5 | Person count | `n_active_persons / 4.0` (clamped) | 0.0–1.0 |
|
||||
| 6 | Fall detected | Binary: 1.0 if `s_fall_detected`, else 0.0 | 0.0 or 1.0 |
|
||||
| 7 | RSSI (normalized) | `(s_latest_rssi + 100) / 100` (clamped) | 0.0–1.0 |
|
||||
|
||||
This maps directly to the Seed's store dimension of 8, enabling kNN queries like "find the 10 most similar sensing states to the current one."
|
||||
|
||||
**Packet format** (magic `0xC5110003`, defined as `edge_feature_pkt_t` in `edge_processing.h`):
|
||||
|
||||
```c
|
||||
typedef struct __attribute__((packed)) {
|
||||
uint32_t magic; // EDGE_FEATURE_MAGIC = 0xC5110003
|
||||
uint8_t node_id; // ESP32 node identifier
|
||||
uint8_t reserved; // alignment padding
|
||||
uint16_t seq; // sequence number
|
||||
int64_t timestamp_us; // microseconds since boot
|
||||
float features[8]; // 8-dim normalized feature vector (32 bytes)
|
||||
} edge_feature_pkt_t; // Total: 48 bytes (static_assert enforced)
|
||||
```
|
||||
|
||||
**Transmission rate:** 1 Hz (one feature vector per second, aggregated from 100 Hz CSI). This keeps UDP bandwidth under 50 bytes/s per node and avoids overwhelming the Seed's vector store.
|
||||
|
||||
### Stage 2: Seed-Side RVF Ingest
|
||||
|
||||
A lightweight Rust service on the Seed (or a Python bridge script) listens for feature packets on UDP port 5006 and ingests them via the Seed's REST API:
|
||||
|
||||
```bash
|
||||
# Ingest a feature vector with metadata
|
||||
curl -sk -X POST https://169.254.42.1:8443/api/v1/store/ingest \
|
||||
-H "Authorization: Bearer $TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"vectors": [[0, [0.85, 0.3, 0.52, 0.65, 0.4, 0.78, 0.1, -0.45]]],
|
||||
"metadata": {
|
||||
"node_id": 1,
|
||||
"type": "csi_feature",
|
||||
"timestamp": 1775166970
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
**Batching:** Accumulate 10 vectors (10 seconds) per ingest call to reduce HTTP overhead (`--batch-size 10` default in `seed_csi_bridge.py`; also supports time-based flushing via `--flush-interval`). At 1 vector/second per node, a 4-node mesh generates 14,400 vectors/hour (345,600/day). Daily compaction is required to stay within the Seed's 100K vector working set (see Storage Budget).
|
||||
|
||||
**Witness chain:** Each ingest automatically appends a witness entry, providing a tamper-evident record of all sensing data. The epoch increments monotonically, and the SHA-256 chain can be verified at any time via `POST /api/v1/witness/verify`.
|
||||
|
||||
### Stage 3: Cognitive Analysis & Sensor Fusion
|
||||
|
||||
Once CSI feature vectors are in the RVF store, the Seed's existing subsystems activate:
|
||||
|
||||
1. **kNN Graph** — Rebuilt every 10 seconds. Similar sensing states cluster together. Anomalous states (intruder, fall, unusual breathing) appear as outliers.
|
||||
|
||||
2. **Boundary Analysis** — Stoer-Wagner min-cut computes a fragility score (0.0–1.0). High fragility indicates the vector space is splitting — a regime change in the environment (door opened, person entered/left, HVAC state change).
|
||||
|
||||
3. **Temporal Coherence** — Phase boundary detection across the vector store timeline identifies when the environment transitions between states (occupied → empty, day → night, normal → abnormal).
|
||||
|
||||
4. **Reflex Rules** — Three pre-configured rules fire automatically:
|
||||
- `fragility_alarm` (threshold 0.3) → relay actuator for presence alert
|
||||
- `drift_cutoff` (threshold 1.0) → cutoff when sensor drift detected
|
||||
- `hd_anomaly_indicator` (threshold 200) → PWM brightness for anomaly severity
|
||||
|
||||
5. **Sensor Fusion** — The Seed's BME280 (temperature/humidity/pressure) and PIR sensor provide environmental ground truth that correlates with CSI features:
|
||||
- PIR motion validates CSI presence detection
|
||||
- Temperature changes correlate with occupancy
|
||||
- Humidity changes correlate with breathing detection fidelity
|
||||
|
||||
6. **MCP Integration** — AI assistants can query the full pipeline via the 114-tool MCP proxy:
|
||||
```json
|
||||
{"method": "tools/call", "params": {"name": "seed.memory.query", "arguments": {"vector": [0.8, 0.5, 0.4, 0.6, 0.3, 0.7, 0.1, -0.3], "k": 5}}}
|
||||
```
|
||||
|
||||
### ESP32 Provisioning
|
||||
|
||||
The ESP32's existing NVS provisioning system supports configuring the Seed as the target:
|
||||
|
||||
```bash
|
||||
python firmware/esp32-csi-node/provision.py \
|
||||
--port COM9 \
|
||||
--target-ip 192.168.1.20 \
|
||||
--target-port 5006 \
|
||||
--node-id 1
|
||||
```
|
||||
|
||||
Note: `--target-ip` is the host laptop (192.168.1.20), not the Seed IP, because the bridge runs on the host and forwards to the Seed via HTTPS (see Known Issue 4).
|
||||
|
||||
No firmware recompilation needed — the `stream_sender` module reads target IP/port from NVS at boot.
|
||||
|
||||
### Data Flow Rates
|
||||
|
||||
| Path | Rate | Size | Bandwidth |
|
||||
|------|------|------|-----------|
|
||||
| CSI capture → ring buffer | 100 Hz | ~400 B | 40 KB/s (internal) |
|
||||
| Edge DSP → sensing-server | 100 Hz | ~200 B | 20 KB/s (existing) |
|
||||
| Edge DSP → Seed features | 1 Hz | 48 B | 48 B/s (new) |
|
||||
| Seed ingest (batched) | 0.1 Hz | ~500 B | 50 B/s (HTTP) |
|
||||
| Seed kNN graph rebuild | 0.1 Hz | internal | — |
|
||||
| Seed witness chain | per batch | 32 B hash | — |
|
||||
|
||||
### Storage Budget
|
||||
|
||||
| Timeframe | Vectors/node | 4 nodes | RVF size | RAM |
|
||||
|-----------|-------------|---------|----------|-----|
|
||||
| 1 hour | 3,600 | 14,400 | ~580 KB | ~6 MB |
|
||||
| 24 hours | 86,400 | 345,600 | ~14 MB | ~140 MB |
|
||||
| 7 days | 604,800 | 2,419,200 | ~97 MB | exceeds |
|
||||
|
||||
**Compaction policy:** Run `POST /api/v1/store/compact` daily at 03:00, retaining only the last 24 hours of vectors. Archive older vectors to USB drive via `POST /api/v1/store/export` before compaction.
|
||||
|
||||
**Dimension reduction:** For deployments exceeding 100K vectors, reduce feature extraction rate to 0.1 Hz (one vector per 10 seconds) or increase compaction frequency.
|
||||
|
||||
## Validation Results
|
||||
|
||||
**Live hardware test performed 2026-04-02.**
|
||||
|
||||
### Hardware Under Test
|
||||
|
||||
| Component | Port | IP | Firmware | WiFi | RSSI |
|
||||
|-----------|------|----|----------|------|------|
|
||||
| ESP32-S3 (8MB) | COM9 | 192.168.1.105 | v0.5.2 | ruv.net (ch 5) | -34 dBm |
|
||||
| Cognitum Seed | USB | 169.254.42.1 / 192.168.1.109 | v0.8.1 | ruv.net | — |
|
||||
| Host laptop | — | 192.168.1.20 | — | ruv.net | — |
|
||||
|
||||
Seed device_id: `ecaf97dd-fc90-4b0e-b0e7-e9f896b9fbb6`. Pairing token issued to `wifi-densepose-claude`.
|
||||
|
||||
### Pipeline Validated
|
||||
|
||||
1. **UDP streaming** -- 211 packets captured in 15 seconds:
|
||||
- 196 raw CSI frames (magic `0xC5110001`)
|
||||
- 15 vitals frames (magic `0xC5110002`)
|
||||
|
||||
2. **Bridge pipeline** -- 20 vitals packets (`0xC5110002`) parsed, converted to 8-dim feature vectors via the bridge's `parse_vitals_packet()` fallback path, ingested in 4 batches of 5 vectors each (`--batch-size 5`). The native `0xC5110003` feature packet path is implemented in firmware but was not exercised in this validation run (firmware was v0.5.2; the `send_feature_vector()` addition requires a reflash).
|
||||
|
||||
3. **RVF ingest** -- All 20 vectors accepted by Seed. Epochs advanced 88 to 91. Witness chain verified valid (193 entries, SHA-256 chain intact).
|
||||
|
||||
4. **Seed sensors** -- BME280, PIR, reed switch, ADS1115, vibration sensor all present and healthy.
|
||||
|
||||
### Live Vital Signs Captured
|
||||
|
||||
| Metric | Observed Range | Expected | Notes |
|
||||
|--------|---------------|----------|-------|
|
||||
| Presence score | 1.41 -- 14.92 | 0.0 -- 1.0 | **Needs normalization** (see Known Issues) |
|
||||
| Motion energy | 1.41 -- 14.92 | 0.0 -- 1.0 | Same raw value as presence score |
|
||||
| Breathing rate | 19.8 -- 33.5 BPM | 12 -- 25 BPM | Plausible but slightly high |
|
||||
| Heart rate | 75.3 -- 99.1 BPM | 60 -- 100 BPM | Plausible range |
|
||||
| RSSI | -43 to -72 dBm | -30 to -80 dBm | Normal |
|
||||
| Fall detected | No | — | Correct (no falls occurred) |
|
||||
| n_persons | 4 | 1 | **Miscalibrated** (see Known Issues) |
|
||||
|
||||
### Known Issues Found
|
||||
|
||||
1. **`presence_score` exceeds 1.0 in vitals packets** -- Raw values range 1.41 to 14.92 in the vitals packet (`0xC5110002`). The bridge's vitals-to-feature conversion clamps to 1.0 for dim 0 and divides by 10.0 for dim 1 (`motion_energy / 10.0`), but dim 0 clamps without scaling. **Note:** The firmware's native feature vector (`0xC5110003`) already normalizes correctly by dividing `s_presence_score` by 10.0 (see `edge_processing.c` line 657). This issue only affects the vitals-packet fallback path in the bridge.
|
||||
|
||||
2. **`n_persons = 4` with 1 person present** -- The multi-person counting algorithm is miscalibrated for single-occupancy scenarios. The per-node state pipeline (ADR-068) may mitigate this when the baseline is properly trained, but the raw edge count is unreliable.
|
||||
|
||||
3. **Content-addressed vector IDs cause deduplication** -- Similar feature vectors hash to the same ID, causing the Seed to silently drop duplicates. **Fixed in bridge:** `seed_csi_bridge.py` now uses `_make_vector_id()` which generates a SHA-256 hash of `node_id:timestamp_us:seq_counter`, producing unique 32-bit IDs. This was observed during validation and fixed before the final test run.
|
||||
|
||||
4. **Bridge runs on host, not Seed** -- The ESP32 target IP must be the host laptop (192.168.1.20), not the Seed IP. The bridge script on the host forwards to the Seed via HTTPS. This adds a hop but avoids running a UDP listener on the Pi Zero 2 W.
|
||||
|
||||
5. **PIR GPIO read returned 404** -- `GET /api/v1/sensor/gpio/read?pin=6` returned 404. The PIR endpoint may require a different pin number or endpoint format. Ground-truth validation against PIR is deferred to Phase 3.
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
### Phase 1: ESP32 Feature Extraction (firmware change) -- DONE
|
||||
|
||||
Implemented as `send_feature_vector()` in `edge_processing.c` (lines 644-699) and `edge_feature_pkt_t` in `edge_processing.h` (lines 112-124). The function reads from static globals (`s_presence_score`, `s_motion_energy`, `s_breathing_bpm`, `s_heartrate_bpm`, subcarrier Welford variance, person tracker, fall flag, RSSI) and normalizes each dimension to 0.0-1.0 with clamping.
|
||||
|
||||
Called at the same 1 Hz cadence as `send_vitals_packet()` in Step 13 of the edge processing pipeline (line 855). The compressed frame magic was reassigned from `0xC5110003` to `0xC5110005` to free up `0xC5110003` for feature vectors (`EDGE_COMPRESSED_MAGIC` in `edge_processing.h` line 29).
|
||||
|
||||
### Phase 2: Seed Ingest Bridge (Python script on host) -- DONE
|
||||
|
||||
Implemented as `scripts/seed_csi_bridge.py`. The bridge:
|
||||
1. Listens on UDP port 5006 (configurable via `--udp-port`)
|
||||
2. Accepts all three packet formats: `0xC5110003` (ADR-069 features), `0xC5110002` (vitals, converted to 8-dim), and `0xC5110001` (raw CSI, minimal features)
|
||||
3. Generates unique vector IDs via SHA-256 hash of `node_id:timestamp:seq` (avoids content-addressed deduplication -- see Known Issue 3)
|
||||
4. Batches vectors (default 10, configurable via `--batch-size`) with time-based flush fallback (`--flush-interval`)
|
||||
5. POSTs to Seed's `/api/v1/store/ingest` with bearer token
|
||||
6. Supports `--validate` mode (kNN query + PIR comparison after each batch)
|
||||
7. Supports `--stats` mode (print Seed status, boundary, coherence, graph)
|
||||
8. Supports `--compact` mode (trigger store compaction)
|
||||
|
||||
### Phase 3: Validation & Ground Truth -- BLOCKED
|
||||
|
||||
Use the Seed's PIR sensor as ground truth for presence detection:
|
||||
1. Query PIR state: `GET /api/v1/sensor/gpio/read?pin=6`
|
||||
2. Compare with CSI presence score (feature dim 0)
|
||||
3. Log agreement/disagreement rate
|
||||
4. Use kNN to find historical vectors matching current PIR state → validate CSI accuracy
|
||||
|
||||
**Status:** The bridge implements `--validate` mode with PIR comparison (see `_run_validation()` in `seed_csi_bridge.py`). However, the PIR endpoint returned 404 during validation (Known Issue 5). This phase is blocked until the correct PIR API endpoint is identified.
|
||||
|
||||
### Phase 4: Multi-Node Mesh (addresses #348)
|
||||
|
||||
Deploy 3 ESP32 nodes, each sending feature vectors to the bridge host (which forwards to the Seed):
|
||||
- Node 1 (lobby): `--node-id 1 --target-ip 192.168.1.20 --target-port 5006`
|
||||
- Node 2 (hallway): `--node-id 2 --target-ip 192.168.1.20 --target-port 5006`
|
||||
- Node 3 (room): `--node-id 3 --target-ip 192.168.1.20 --target-port 5006`
|
||||
|
||||
All nodes target the host laptop (192.168.1.20) where the bridge script runs. The bridge batches and forwards all nodes' vectors to the Seed via HTTPS. The Seed's kNN graph naturally clusters vectors by node and by sensing state. Cross-node analysis via boundary fragility detects when a person moves between zones.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
1. **Bearer token** — All write operations require the pairing token. Token stored as SHA-256 hash on device.
|
||||
2. **TLS** — All API calls over HTTPS (port 8443) with device-provisioned CA certificate.
|
||||
3. **Witness chain** — Every ingest is cryptographically chained. Tampering detection via `POST /api/v1/witness/verify`.
|
||||
4. **Ed25519 attestation** — Device identity bound to hardware keypair. Attestation includes epoch, vector count, and witness head.
|
||||
5. **Anti-spoofing** — Sensor pipeline has entropy-based spoofing detection (min 0.5 bits entropy, streak threshold 3).
|
||||
6. **USB-only pairing** — Pairing window can only be opened from USB interface (169.254.42.1), not from WiFi.
|
||||
|
||||
## Hardware Bill of Materials
|
||||
|
||||
| Component | Port | IP | Cost |
|
||||
|-----------|------|----|------|
|
||||
| ESP32-S3 (8MB) | COM9 | 192.168.1.105 (DHCP) | ~$9 |
|
||||
| Cognitum Seed (Pi Zero 2W) | USB | 169.254.42.1 / 192.168.1.109 | ~$15 |
|
||||
| USB-C cable (data) | — | — | ~$3 |
|
||||
| **Total** | | | **~$27** |
|
||||
|
||||
### Seed Sensors (included)
|
||||
|
||||
| Sensor | Interface | Channels | Purpose |
|
||||
|--------|-----------|----------|---------|
|
||||
| Reed switch | GPIO 5 | 1 | Door/window state |
|
||||
| PIR motion | GPIO 6 | 1 | Motion ground truth |
|
||||
| Vibration | GPIO 13 | 1 | Structural vibration |
|
||||
| ADS1115 | I2C 0x48 | 4 | Analog inputs (extensible) |
|
||||
| BME280 | I2C 0x76 | 3 | Temperature, humidity, pressure |
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|------|-----------|--------|------------|
|
||||
| Pi Zero thermal throttling at sustained ingest | Medium | Performance degrades | Thermal governor already manages DVFS; 1 Hz ingest is minimal load |
|
||||
| WiFi congestion with ESP32 CSI + UDP | Low | Lost packets | Feature vectors are 48 bytes at 1 Hz; negligible vs CSI traffic |
|
||||
| RVF store exceeds RAM at high vector count | Medium | OOM | Compaction policy + dimension reduction + daily export |
|
||||
| Bearer token exposure | Low | Unauthorized writes | TLS encryption + USB-only pairing + token hashing |
|
||||
| ESP32 NVS corruption | Low | Config lost | NVS is wear-leveled flash with CRC; re-provision via USB |
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
- ESP32 CSI features become persistent, searchable, and cryptographically attested
|
||||
- kNN similarity search enables environment fingerprinting and anomaly detection
|
||||
- PIR + BME280 provide ground truth for CSI validation
|
||||
- MCP proxy enables AI assistants to query sensing state directly
|
||||
- Witness chain provides audit trail for healthcare/safety applications
|
||||
- Architecture aligns with Arena Physica's insight: store embeddings, not raw signals
|
||||
|
||||
### Negative
|
||||
- Additional firmware packet type (48 bytes, trivial)
|
||||
- Bridge script needed on Seed or host machine
|
||||
- Daily compaction required for long-running deployments
|
||||
- Bearer token must be managed (stored securely, rotated if compromised)
|
||||
|
||||
### Neutral
|
||||
- Existing sensing-server pipeline unchanged (ESP32 still sends to port 5005)
|
||||
- Seed's existing sensors continue operating independently
|
||||
- Target IP/port configurable via NVS provisioning (no recompilation for deployment changes)
|
||||
- Firmware recompilation needed once to add `send_feature_vector()` (Phase 1), but subsequent node deployments only need provisioning
|
||||
@@ -1,203 +0,0 @@
|
||||
# ADR-070: Self-Supervised Pretraining from Live ESP32 CSI + Cognitum Seed
|
||||
|
||||
| Field | Value |
|
||||
|------------|----------------------------------------------------------|
|
||||
| Status | Accepted |
|
||||
| Date | 2026-04-02 |
|
||||
| Authors | rUv, claude-flow |
|
||||
| Drivers | README limitation "No pre-trained model weights provided"|
|
||||
| Related | ADR-069 (Cognitum Seed pipeline), ADR-027 (MERIDIAN), ADR-024 (AETHER contrastive), ADR-015 (MM-Fi dataset) |
|
||||
|
||||
## Context
|
||||
|
||||
The README lists "No pre-trained model weights are provided; training from scratch is required" as a known limitation. Users must collect their own CSI dataset and train from scratch, which is a significant barrier to adoption.
|
||||
|
||||
We now have the infrastructure to generate pre-trained weights directly from live hardware:
|
||||
|
||||
- **2 ESP32-S3 nodes** (COM8 node_id=2 at 192.168.1.104, COM9 node_id=1 at 192.168.1.105) streaming CSI + vitals + 8-dim feature vectors at 1 Hz each
|
||||
- **Cognitum Seed** (Pi Zero 2 W) with RVF vector store, kNN search, witness chain, and environmental sensors (BME280, PIR, vibration)
|
||||
- **Recording API** in sensing-server (`POST /api/v1/recording/start`) that saves CSI frames to `.csi.jsonl`
|
||||
- **Self-supervised training** via `rapid_adapt.rs` (contrastive TTT + entropy minimization)
|
||||
- **AETHER contrastive embeddings** (ADR-024) for environment-independent representations
|
||||
|
||||
### Why Self-Supervised?
|
||||
|
||||
No cameras or labels are needed. The system learns from:
|
||||
|
||||
1. **Temporal coherence** — Frames close in time should have similar embeddings (positive pairs), frames far apart should differ (negative pairs)
|
||||
2. **Multi-node consistency** — The same person seen from 2 nodes should produce correlated features, different people should produce decorrelated features
|
||||
3. **Cognitum Seed ground truth** — PIR sensor, BME280 environment changes, and kNN cluster transitions provide weak supervision without human labeling
|
||||
4. **Physical constraints** — Breathing 6-30 BPM, heart rate 40-150 BPM, person count 0-4, RSSI physics
|
||||
|
||||
## Decision
|
||||
|
||||
Implement a 4-phase pretraining pipeline that collects CSI from 2 ESP32 nodes, stores feature vectors in the Cognitum Seed, and produces distributable pre-trained weights.
|
||||
|
||||
### Phase 1: Data Collection (30 min)
|
||||
|
||||
Capture labeled scenarios using the sensing-server recording API and Cognitum Seed:
|
||||
|
||||
| Scenario | Duration | Label | Activity |
|
||||
|----------|----------|-------|----------|
|
||||
| Empty room | 5 min | `empty` | No one present, establish baseline |
|
||||
| 1 person stationary | 5 min | `1p-still` | Sit at desk, normal breathing |
|
||||
| 1 person walking | 5 min | `1p-walk` | Walk around room, varied paths |
|
||||
| 1 person varied | 5 min | `1p-varied` | Stand, sit, wave arms, turn |
|
||||
| 2 people | 5 min | `2p` | Both moving in room |
|
||||
| Transitions | 5 min | `transitions` | Enter/exit room, appear/disappear |
|
||||
|
||||
**Data rate per scenario:**
|
||||
- 2 nodes × 100 Hz CSI = 200 frames/sec = 60,000 frames per 5 min
|
||||
- 2 nodes × 1 Hz features = 2 vectors/sec = 600 vectors per 5 min
|
||||
- Total: 360,000 CSI frames + 3,600 feature vectors per collection run
|
||||
|
||||
**Cognitum Seed role:**
|
||||
- Stores all feature vectors with witness chain attestation
|
||||
- PIR sensor provides binary presence ground truth
|
||||
- BME280 tracks environmental conditions during collection
|
||||
- kNN graph clusters naturally emerge from the vector distribution
|
||||
|
||||
### Phase 2: Contrastive Pretraining
|
||||
|
||||
Train a contrastive encoder on the collected CSI data:
|
||||
|
||||
```
|
||||
Input: Raw CSI frame (128 subcarriers × 2 I/Q = 256 features)
|
||||
↓
|
||||
TCN temporal encoder (3 layers, kernel=7)
|
||||
↓
|
||||
Projection head → 128-dim embedding
|
||||
↓
|
||||
Contrastive loss (InfoNCE):
|
||||
positive: frames within 0.5s window from same node
|
||||
negative: frames >5s apart or from different scenario
|
||||
cross-node positive: same timestamp, different node
|
||||
```
|
||||
|
||||
**Self-supervised signals:**
|
||||
- Temporal adjacency (frames within 500ms = positive pair)
|
||||
- Cross-node agreement (same person seen from 2 viewpoints)
|
||||
- PIR consistency (embedding should cluster by PIR state)
|
||||
- Scenario boundary (embeddings should shift at label transitions)
|
||||
|
||||
### Phase 3: Downstream Head Training
|
||||
|
||||
Attach lightweight heads for each task:
|
||||
|
||||
| Head | Architecture | Output | Supervision |
|
||||
|------|-------------|--------|-------------|
|
||||
| Presence | Linear(128→1) + sigmoid | 0.0-1.0 | PIR sensor (free) |
|
||||
| Person count | Linear(128→4) + softmax | 0-3 people | Scenario labels |
|
||||
| Activity | Linear(128→4) + softmax | still/walk/varied/empty | Scenario labels |
|
||||
| Vital signs | Linear(128→2) | BR, HR (BPM) | ESP32 edge vitals |
|
||||
|
||||
### Phase 4: Package & Distribute
|
||||
|
||||
Produce distributable artifacts:
|
||||
|
||||
| Artifact | Format | Size | Description |
|
||||
|----------|--------|------|-------------|
|
||||
| `pretrained-encoder.onnx` | ONNX | ~2 MB | Contrastive encoder (TCN backbone) |
|
||||
| `pretrained-heads.onnx` | ONNX | ~100 KB | Task-specific heads |
|
||||
| `pretrained.rvf` | RVF | ~500 KB | RuVector format with metadata |
|
||||
| `room-profiles.json` | JSON | ~10 KB | Environment calibration profiles |
|
||||
| `collection-witness.json` | JSON | ~5 KB | Seed witness chain attestation proving data provenance |
|
||||
|
||||
Include in GitHub release alongside firmware binaries. Users download and run:
|
||||
|
||||
```bash
|
||||
# Use pre-trained model (no training needed)
|
||||
cargo run -p wifi-densepose-sensing-server -- --model pretrained.rvf --http-port 3000
|
||||
```
|
||||
|
||||
## Hardware Setup
|
||||
|
||||
```
|
||||
192.168.1.20 (Host laptop)
|
||||
┌──────────────────────────┐
|
||||
│ sensing-server │
|
||||
│ Recording API │
|
||||
│ Training pipeline │
|
||||
│ │
|
||||
│ seed_csi_bridge.py │
|
||||
│ Feature → Seed ingest │
|
||||
└────┬──────────┬───────────┘
|
||||
│ │
|
||||
UDP:5006 │ │ HTTPS:8443
|
||||
┌───────────────────┤ ├───────────────┐
|
||||
│ │ │ │
|
||||
▼ ▼ ▼ │
|
||||
┌──────────┐ ┌──────────┐ ┌──────────────┐ │
|
||||
│ ESP32 #1 │ │ ESP32 #2 │ │Cognitum Seed │◄───┘
|
||||
│ COM9 │ │ COM8 │ │ Pi Zero 2W │
|
||||
│ node=1 │ │ node=2 │ │ USB │
|
||||
│ .1.105 │ │ .1.104 │ │ .42.1/8443 │
|
||||
│ v0.5.4 │ │ v0.5.4 │ │ v0.8.1 │
|
||||
└──────────┘ └──────────┘ │ PIR, BME280 │
|
||||
│ RVF store │
|
||||
│ Witness chain│
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
## Data Collection Protocol
|
||||
|
||||
### Step 1: Start Seed ingest (background)
|
||||
|
||||
```bash
|
||||
export SEED_TOKEN="your-token"
|
||||
python scripts/seed_csi_bridge.py \
|
||||
--seed-url https://169.254.42.1:8443 --token "$SEED_TOKEN" \
|
||||
--udp-port 5006 --batch-size 10 --validate &
|
||||
```
|
||||
|
||||
### Step 2: Start sensing-server with recording
|
||||
|
||||
```bash
|
||||
cargo run -p wifi-densepose-sensing-server -- \
|
||||
--source esp32 --udp-port 5006 --http-port 3000
|
||||
```
|
||||
|
||||
### Step 3: Record each scenario
|
||||
|
||||
```bash
|
||||
# Empty room (leave room for 5 min)
|
||||
curl -X POST http://localhost:3000/api/v1/recording/start \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"session_name":"pretrain-empty","label":"empty","duration_secs":300}'
|
||||
|
||||
# 1 person stationary (sit at desk for 5 min)
|
||||
curl -X POST http://localhost:3000/api/v1/recording/start \
|
||||
-d '{"session_name":"pretrain-1p-still","label":"1p-still","duration_secs":300}'
|
||||
|
||||
# ... repeat for each scenario
|
||||
```
|
||||
|
||||
### Step 4: Verify with Seed
|
||||
|
||||
```bash
|
||||
python scripts/seed_csi_bridge.py --token "$SEED_TOKEN" --stats
|
||||
# Should show 3,600+ vectors from the collection run
|
||||
```
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|------|-----------|--------|------------|
|
||||
| 2 nodes insufficient for spatial diversity | Medium | Lower pretraining quality | Place nodes 3-5m apart at different heights |
|
||||
| PIR sensor has limited range | Low | Weak presence labels | BME280 temp changes + kNN clusters as backup |
|
||||
| Contrastive pretraining collapses | Low | Useless embeddings | Temperature scheduling, hard negative mining |
|
||||
| Model too large for ESP32 inference | N/A | N/A | Inference on host/Seed, not on ESP32 |
|
||||
| Room-specific overfitting | Medium | Poor generalization | MERIDIAN domain randomization (ADR-027), LoRA adaptation |
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
- Users get working model out of the box — no training needed
|
||||
- Witness chain proves data provenance (when/where/which hardware)
|
||||
- Pre-trained encoder transfers to new environments via LoRA fine-tuning
|
||||
- Removes the #1 adoption barrier from the README
|
||||
|
||||
### Negative
|
||||
- 30 min of manual data collection per pretraining run
|
||||
- Pre-trained weights are room-specific without adaptation
|
||||
- ONNX runtime dependency for inference
|
||||
@@ -1,408 +0,0 @@
|
||||
# ADR-071: ruvllm Training Pipeline for CSI Sensing Models
|
||||
|
||||
- **Status**: Proposed
|
||||
- **Date**: 2026-04-02
|
||||
- **Deciders**: ruv
|
||||
- **Relates to**: ADR-069 (Cognitum Seed CSI Pipeline), ADR-070 (Self-Supervised Pretraining), ADR-024 (Contrastive CSI Embedding / AETHER), ADR-016 (RuVector Training Pipeline)
|
||||
|
||||
## Context
|
||||
|
||||
The WiFi-DensePose project needs a training pipeline to convert collected CSI data
|
||||
(`.csi.jsonl` frames from ESP32 nodes) into deployable models for presence detection,
|
||||
activity classification, and vital sign estimation.
|
||||
|
||||
Previous ADRs established the data collection protocol (ADR-070) and Cognitum Seed
|
||||
inference target (ADR-069). What was missing was the actual training, refinement,
|
||||
quantization, and export pipeline connecting raw CSI recordings to deployable models.
|
||||
|
||||
### Why ruvllm instead of PyTorch
|
||||
|
||||
| Criterion | ruvllm | PyTorch | ONNX Runtime |
|
||||
|-----------|--------|---------|--------------|
|
||||
| Runtime dependency | Node.js only | Python + CUDA + pip | C++ runtime |
|
||||
| Install size | ~5 MB (npm) | ~2 GB (torch+cuda) | ~50 MB |
|
||||
| SONA adaptation | <1ms native | N/A | N/A |
|
||||
| Quantization | 2/4/8-bit TurboQuant | INT8/FP16 (separate tool) | INT8 only |
|
||||
| LoRA fine-tuning | Built-in LoraAdapter | Requires PEFT library | N/A |
|
||||
| EWC protection | Built-in EwcManager | Manual implementation | N/A |
|
||||
| SafeTensors export | Native SafeTensorsWriter | Via safetensors library | N/A |
|
||||
| Contrastive training | Built-in ContrastiveTrainer | Manual triplet loss | N/A |
|
||||
| Edge deployment | ESP32, Pi Zero, browser | GPU servers only | ARM (limited) |
|
||||
| M4 Pro performance | 88-135 tok/s native | ~30 tok/s (MPS) | ~50 tok/s |
|
||||
| Ecosystem integration | RuVector, Cognitum Seed | Standalone | Standalone |
|
||||
|
||||
The ruvllm package (`@ruvector/ruvllm` v2.5.4) provides the complete training
|
||||
lifecycle in a single dependency: contrastive pretraining, task head training,
|
||||
LoRA refinement, EWC consolidation, quantization, and SafeTensors/RVF export.
|
||||
No Python dependency means the entire pipeline runs on the same Node.js runtime
|
||||
as the Cognitum Seed inference engine.
|
||||
|
||||
## Decision
|
||||
|
||||
Use ruvllm's `ContrastiveTrainer`, `TrainingPipeline`, `LoraAdapter`, `EwcManager`,
|
||||
`SafeTensorsWriter`, and `ModelExporter` for the complete CSI model training lifecycle.
|
||||
|
||||
### Training Phases
|
||||
|
||||
The pipeline executes five sequential phases:
|
||||
|
||||
#### Phase 1: Contrastive Pretraining
|
||||
|
||||
Learns an embedding space where temporally and spatially similar CSI states are close
|
||||
and dissimilar states are far apart.
|
||||
|
||||
- **Encoder architecture**: 8-dim CSI feature vector -> 64-dim hidden (ReLU) -> 128-dim embedding (L2-normalized)
|
||||
- **Loss functions**: Triplet loss (margin=0.3) + InfoNCE (temperature=0.07)
|
||||
- **Triplet strategies**:
|
||||
- Temporal positive: frames within 1 second (same environment state)
|
||||
- Temporal negative: frames >30 seconds apart (different state)
|
||||
- Cross-node positive: same timestamp from different ESP32 nodes (same person, different viewpoint)
|
||||
- Cross-node negative: different timestamp + different node
|
||||
- Hard negatives: frames near motion energy transition boundaries
|
||||
- **Hyperparameters**: 20 epochs, batch size 32, hard negative ratio 0.7
|
||||
- **Implementation**: `ContrastiveTrainer.addTriplet()` + `.train()`
|
||||
|
||||
#### Phase 2: Task Head Training
|
||||
|
||||
Trains supervised heads on top of the frozen embedding for specific sensing tasks.
|
||||
|
||||
- **Presence head**: 128 -> 1 (sigmoid), threshold at presence_score > 0.3
|
||||
- **Activity head**: 128 -> 3 (softmax: still/moving/empty), derived from motion_energy thresholds
|
||||
- **Vitals head**: 128 -> 2 (linear: breathing BPM, heart rate BPM), normalized targets
|
||||
- **Implementation**: `TrainingPipeline.addData()` + `.train()` with cosine LR scheduler,
|
||||
early stopping (patience=5), and quality-weighted MSE loss
|
||||
|
||||
#### Phase 3: LoRA Refinement
|
||||
|
||||
Per-node LoRA adapters for room-specific adaptation without forgetting the base model.
|
||||
|
||||
- **Configuration**: rank=4, alpha=8, dropout=0.1
|
||||
- **Per-node training**: Each ESP32 node gets its own LoRA adapter trained on
|
||||
node-specific data with reduced learning rate (0.5x base)
|
||||
- **Implementation**: `LoraManager.create()` for each node, `TrainingPipeline` with
|
||||
`LoraAdapter` passed to constructor
|
||||
|
||||
#### Phase 4: Quantization (TurboQuant)
|
||||
|
||||
Reduces model size for edge deployment with minimal quality loss.
|
||||
|
||||
| Bit Width | Compression | Typical RMSE | Target Device |
|
||||
|-----------|-------------|-------------|---------------|
|
||||
| 8-bit | 4x | <0.001 | Cognitum Seed (Pi Zero) |
|
||||
| 4-bit | 8x | <0.01 | Standard edge inference |
|
||||
| 2-bit | 16x | <0.05 | ESP32-S3 feature extraction |
|
||||
|
||||
- **Method**: Uniform affine quantization with scale/zero-point per tensor
|
||||
- **Quality validation**: RMSE between original fp32 and dequantized weights
|
||||
|
||||
#### Phase 5: EWC Consolidation
|
||||
|
||||
Elastic Weight Consolidation prevents catastrophic forgetting when the model
|
||||
is later fine-tuned on new room data or updated CSI conditions.
|
||||
|
||||
- **Fisher information**: Computed from training data gradients
|
||||
- **Lambda**: 2000 (base), 3000 (per-node)
|
||||
- **Tasks registered**: Base pretraining + one per ESP32 node
|
||||
- **Implementation**: `EwcManager.registerTask()` for each training phase
|
||||
|
||||
### Data Pipeline
|
||||
|
||||
```
|
||||
.csi.jsonl files
|
||||
|
|
||||
v
|
||||
Parse frames: feature (8-dim), vitals, raw CSI
|
||||
|
|
||||
v
|
||||
Generate contrastive triplets (temporal, cross-node, hard negatives)
|
||||
|
|
||||
v
|
||||
Encode through CsiEncoder (8 -> 64 -> 128)
|
||||
|
|
||||
v
|
||||
Phase 1: ContrastiveTrainer (triplet + InfoNCE loss)
|
||||
|
|
||||
v
|
||||
Phase 2: TrainingPipeline (presence + activity + vitals heads)
|
||||
|
|
||||
v
|
||||
Phase 3: LoRA per-node refinement
|
||||
|
|
||||
v
|
||||
Phase 4: TurboQuant (2/4/8-bit quantization)
|
||||
|
|
||||
v
|
||||
Phase 5: EWC consolidation
|
||||
|
|
||||
v
|
||||
Export: SafeTensors, JSON config, RVF manifest, per-node LoRA adapters
|
||||
```
|
||||
|
||||
### Export Formats
|
||||
|
||||
| Format | File | Consumer |
|
||||
|--------|------|----------|
|
||||
| SafeTensors | `model.safetensors` | HuggingFace ecosystem, general inference |
|
||||
| JSON config | `config.json` | Model loading metadata |
|
||||
| JSON model | `model.json` | Full model state for Node.js loading |
|
||||
| Quantized binaries | `quantized/model-q{2,4,8}.bin` | Edge deployment |
|
||||
| Per-node LoRA | `lora/node-{id}.json` | Room-specific adaptation |
|
||||
| RVF manifest | `model.rvf.jsonl` | Cognitum Seed ingest (ADR-069) |
|
||||
| Training metrics | `training-metrics.json` | Dashboards, CI validation |
|
||||
|
||||
### Hardware Targets
|
||||
|
||||
| Device | Role | Quantization | Expected Latency |
|
||||
|--------|------|-------------|-----------------|
|
||||
| Mac Mini M4 Pro | Training (primary) | fp32 | <5 min total |
|
||||
| Cognitum Seed Pi Zero | Inference | 4-bit / 8-bit | <10 ms per frame |
|
||||
| ESP32-S3 | Feature extraction only | 2-bit (encoder weights) | <5 ms per frame |
|
||||
| Browser (WASM) | Visualization | 4-bit | <20 ms per frame |
|
||||
|
||||
### Performance Targets
|
||||
|
||||
| Metric | Target | Measured |
|
||||
|--------|--------|----------|
|
||||
| Training time (5,783 frames, M4 Pro) | <5 min | TBD |
|
||||
| Inference latency (M4 Pro) | <1 ms | TBD |
|
||||
| Inference latency (Pi Zero) | <10 ms | TBD |
|
||||
| SONA adaptation | <1 ms | <0.05 ms (ruvllm spec) |
|
||||
| Presence detection accuracy | >85% | TBD |
|
||||
| 4-bit quality loss (RMSE) | <0.01 | TBD |
|
||||
| 2-bit quality loss (RMSE) | <0.05 | TBD |
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- **Zero Python dependency**: The entire training and inference pipeline runs on
|
||||
Node.js, eliminating Python/CUDA/pip dependency management on training and
|
||||
deployment targets.
|
||||
- **Integrated lifecycle**: Contrastive pretraining, task heads, LoRA refinement,
|
||||
EWC consolidation, and quantization in a single script using one library.
|
||||
- **Edge-first**: 2-bit quantization enables running the encoder on ESP32-S3.
|
||||
4-bit quantization fits comfortably on Cognitum Seed Pi Zero.
|
||||
- **Continual learning**: EWC protection means the model can be updated with new
|
||||
room data without losing previously learned patterns.
|
||||
- **Per-node adaptation**: LoRA adapters allow room-specific fine-tuning with
|
||||
minimal storage overhead (rank-4 adapter ~2KB per node).
|
||||
- **HuggingFace compatibility**: SafeTensors export enables sharing models on the
|
||||
HuggingFace Hub and loading in other frameworks.
|
||||
- **Reproducibility**: Seeded encoder initialization and deterministic data pipeline
|
||||
ensure reproducible training runs.
|
||||
|
||||
### Negative
|
||||
|
||||
- **No GPU acceleration**: ruvllm's JS training loop does not use GPU compute.
|
||||
For the small model sizes in CSI sensing (8->64->128), this is acceptable
|
||||
(~seconds on M4 Pro), but would not scale to large vision models.
|
||||
- **Simplified backpropagation**: The LoRA backward pass and contrastive training
|
||||
use approximate gradient updates rather than full automatic differentiation.
|
||||
Sufficient for the target model sizes but not equivalent to PyTorch autograd.
|
||||
- **Quantization is post-training only**: No quantization-aware training (QAT).
|
||||
For 4-bit and 8-bit this produces acceptable quality loss; 2-bit may need
|
||||
QAT in future if quality degrades.
|
||||
|
||||
### Risks
|
||||
|
||||
- **Quality ceiling**: The simplified training may produce lower accuracy than a
|
||||
PyTorch-trained equivalent. Mitigated by: (a) the model is small enough that
|
||||
the training loop converges quickly, (b) SONA adaptation can compensate at
|
||||
inference time, (c) we can switch to PyTorch for training only if needed
|
||||
while keeping ruvllm for inference.
|
||||
- **ruvllm API stability**: The library is at v2.5.4 with active development.
|
||||
Mitigated by vendoring the package in `vendor/ruvector/npm/packages/ruvllm/`.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Scripts
|
||||
|
||||
| Script | Purpose |
|
||||
|--------|---------|
|
||||
| `scripts/train-ruvllm.js` | Full 5-phase training pipeline |
|
||||
| `scripts/benchmark-ruvllm.js` | Model benchmarking (latency, quality, accuracy) |
|
||||
|
||||
### Usage
|
||||
|
||||
```bash
|
||||
# Train on collected CSI data
|
||||
node scripts/train-ruvllm.js \
|
||||
--data data/recordings/pretrain-1775182186.csi.jsonl \
|
||||
--output models/csi-v1 \
|
||||
--epochs 20
|
||||
|
||||
# Train with benchmark
|
||||
node scripts/train-ruvllm.js \
|
||||
--data data/recordings/pretrain-*.csi.jsonl \
|
||||
--output models/csi-v1 \
|
||||
--benchmark
|
||||
|
||||
# Standalone benchmark
|
||||
node scripts/benchmark-ruvllm.js \
|
||||
--model models/csi-v1 \
|
||||
--data data/recordings/pretrain-*.csi.jsonl \
|
||||
--samples 5000 \
|
||||
--json
|
||||
```
|
||||
|
||||
### Output Structure
|
||||
|
||||
```
|
||||
models/csi-v1/
|
||||
model.safetensors # SafeTensors (HuggingFace compatible)
|
||||
config.json # Model configuration
|
||||
model.json # Full JSON model state
|
||||
model.rvf.jsonl # RVF manifest for Cognitum Seed
|
||||
training-metrics.json # Training loss curves, timing, config
|
||||
contrastive/
|
||||
triplets.jsonl # Contrastive training pairs
|
||||
triplets.csv # CSV format for analysis
|
||||
embeddings.json # Embedding matrices
|
||||
quantized/
|
||||
model-q2.bin # 2-bit quantized (ESP32 edge)
|
||||
model-q4.bin # 4-bit quantized (Pi Zero default)
|
||||
model-q8.bin # 8-bit quantized (high quality)
|
||||
lora/
|
||||
node-1.json # LoRA adapter for ESP32 node 1
|
||||
node-2.json # LoRA adapter for ESP32 node 2
|
||||
```
|
||||
|
||||
## Camera-Free Supervision
|
||||
|
||||
### Motivation
|
||||
|
||||
Traditional WiFi-based pose estimation (WiFlow, Person-in-WiFi) requires camera-supervised
|
||||
training: a camera captures ground-truth poses during CSI collection, and the model learns
|
||||
to map CSI to those poses. This creates a deployment paradox — the camera is needed for
|
||||
training but the whole point of WiFi sensing is to avoid cameras.
|
||||
|
||||
The camera-free pipeline (`scripts/train-camera-free.js`) replaces camera supervision with
|
||||
10 sensor signals from the Cognitum Seed and 2 ESP32 nodes, generating weak labels through
|
||||
sensor fusion.
|
||||
|
||||
### 10 Supervision Signals (No Camera)
|
||||
|
||||
| # | Signal | Source | Provides |
|
||||
|---|--------|--------|----------|
|
||||
| 1 | PIR sensor | Seed GPIO 6 | Binary presence ground truth |
|
||||
| 2 | BME280 temperature | Seed I2C 0x76 | Occupancy proxy (temp rises with people) |
|
||||
| 3 | BME280 humidity | Seed I2C 0x76 | Breathing confirmation / zone |
|
||||
| 4 | Cross-node RSSI | 2 ESP32 nodes | Rough XY position (differential triangulation) |
|
||||
| 5 | Vitals stability | ESP32 CSI | HR/BR variance indicates activity level |
|
||||
| 6 | Temporal CSI patterns | ESP32 CSI | Periodic=walking, stable=sitting, flat=empty |
|
||||
| 7 | kNN cluster labels | Seed vector store | Natural groupings in embedding space |
|
||||
| 8 | Boundary fragility | Seed Stoer-Wagner | Regime change detection (entry/exit/activity) |
|
||||
| 9 | Reed switch | Seed GPIO 5 | Door open/close events |
|
||||
| 10 | Vibration sensor | Seed GPIO 13 | Footstep detection |
|
||||
|
||||
### Camera-Free Training Phases
|
||||
|
||||
The pipeline extends the base 5 phases with camera-free-specific phases:
|
||||
|
||||
```
|
||||
Phase 0: Multi-Modal Data Collection
|
||||
├── UDP port 5006 → ESP32 CSI features + vitals
|
||||
├── HTTPS → Seed sensor embeddings (45-dim, every 100ms)
|
||||
├── HTTPS → Seed boundary/coherence (every 10s)
|
||||
└── Build synchronized MultiModalFrame timeline
|
||||
|
||||
Phase 1: Weak Label Generation
|
||||
├── Presence: PIR || CSI_presence > 0.3 || temp_rising > 0.1°C/min
|
||||
├── Position: RSSI differential → 5×5 grid (25 zones)
|
||||
├── Activity: CSI variance + FFT periodicity → stationary/walking/gesture/empty
|
||||
├── Occupancy: max(node1_persons, node2_persons) validated by temp
|
||||
├── Body region: upper/lower subcarrier groups → which body part moves
|
||||
├── Entry/exit: reed_switch + PIR transition + boundary fragility spike
|
||||
├── Breathing zone: humidity change rate → person location
|
||||
└── Pose proxy: 5-keypoint coarse pose from RSSI + subcarrier asymmetry + vibration
|
||||
|
||||
Phase 2: Enhanced Contrastive Pretraining
|
||||
├── Base triplets (temporal, cross-node, transition, scenario boundary)
|
||||
├── Sensor-verified negatives: PIR=0 vs PIR=1 must differ
|
||||
├── Activity boundary: before/after fragility spike must differ
|
||||
└── Cross-modal: CSI embedding ≈ Seed embedding for same state
|
||||
|
||||
Phase 3: Pose Proxy Training (5-keypoint)
|
||||
├── Head: RSSI centroid between 2 nodes
|
||||
├── Hands: per-subcarrier variance asymmetry (left/right from 2 nodes)
|
||||
├── Feet: vibration sensor + RSSI ground reflection
|
||||
└── Skeleton physics constraints (anthropometric bone length limits)
|
||||
|
||||
Phase 4: 17-Keypoint Interpolation
|
||||
├── Shoulders = 0.3 × head + 0.7 × hands
|
||||
├── Elbows = midpoint(shoulder, hand)
|
||||
├── Hips = midpoint(head, feet)
|
||||
├── Knees = midpoint(hip, foot)
|
||||
├── Face = derived from head position
|
||||
└── Iterative bone length constraint projection (3 iterations)
|
||||
|
||||
Phase 5: Self-Refinement Loop (3 rounds)
|
||||
├── Run inference on all collected data
|
||||
├── Keep predictions where temporal consistency confidence > 0.8
|
||||
├── Use as pseudo-labels for next training round
|
||||
└── Decaying learning rate per round (diminishing returns)
|
||||
```
|
||||
|
||||
### Seed API Endpoints Used
|
||||
|
||||
| Endpoint | Data | Collection Rate |
|
||||
|----------|------|----------------|
|
||||
| `GET /api/v1/sensor/stream` | SSE sensor readings | Continuous (100ms) |
|
||||
| `GET /api/v1/sensor/embedding/latest` | 45-dim sensor embedding | Per-frame |
|
||||
| `GET /api/v1/boundary` | Fragility score | Every 10s |
|
||||
| `GET /api/v1/coherence/profile` | Temporal phase boundaries | Every 10s |
|
||||
| `GET /api/v1/store/query` | kNN similarity search | On demand |
|
||||
| `POST /api/v1/boundary/recompute` | Trigger analysis | On regime change |
|
||||
|
||||
### Graceful Degradation
|
||||
|
||||
The pipeline works with or without the Cognitum Seed:
|
||||
|
||||
| Mode | Signals | Pose Quality |
|
||||
|------|---------|-------------|
|
||||
| Full (Seed + 2 ESP32) | 10 signals | 5-keypoint trained, 17-keypoint interpolated |
|
||||
| CSI-only (2 ESP32) | 3 signals (RSSI, vitals, temporal) | Coarser position/activity only |
|
||||
| Single node | 2 signals (vitals, temporal) | Presence + activity only |
|
||||
|
||||
When the Seed API is unreachable, the pipeline automatically falls back to
|
||||
CSI-only training, producing the same output format (SafeTensors, HuggingFace,
|
||||
quantized) with reduced label quality.
|
||||
|
||||
### Output Format
|
||||
|
||||
Same as the base pipeline (SafeTensors + HuggingFace compatible), plus:
|
||||
|
||||
| File | Description |
|
||||
|------|-------------|
|
||||
| `pose-decoder.json` | 5-keypoint pose decoder weights |
|
||||
| `model.rvf.jsonl` | Extended with `camera_free_supervision` record |
|
||||
| `training-metrics.json` | Includes weak label stats and multi-modal triplet counts |
|
||||
|
||||
### Usage
|
||||
|
||||
```bash
|
||||
# Full pipeline with Seed
|
||||
node scripts/train-camera-free.js \
|
||||
--data data/recordings/pretrain-*.csi.jsonl \
|
||||
--seed-url https://169.254.42.1:8443 \
|
||||
--output models/csi-camerafree-v1
|
||||
|
||||
# CSI-only (no Seed)
|
||||
node scripts/train-camera-free.js \
|
||||
--data data/recordings/pretrain-*.csi.jsonl \
|
||||
--no-seed \
|
||||
--output models/csi-camerafree-v1
|
||||
|
||||
# With benchmark
|
||||
node scripts/train-camera-free.js \
|
||||
--data data/recordings/*.csi.jsonl \
|
||||
--benchmark
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
- [ruvllm source](vendor/ruvector/npm/packages/ruvllm/) — v2.5.4
|
||||
- [ADR-069](ADR-069-cognitum-seed-csi-pipeline.md) — Cognitum Seed CSI Pipeline
|
||||
- [ADR-070](ADR-070-self-supervised-pretraining.md) — Self-Supervised Pretraining Protocol
|
||||
- [ADR-024](ADR-024-contrastive-csi-embedding.md) — Contrastive CSI Embedding / AETHER
|
||||
- [ADR-016](ADR-016-ruvector-training-pipeline.md) — RuVector Training Pipeline Integration
|
||||
@@ -1,238 +0,0 @@
|
||||
# ADR-072: WiFlow Pose Estimation Architecture
|
||||
|
||||
- **Status**: Proposed
|
||||
- **Date**: 2026-04-02
|
||||
- **Deciders**: ruv
|
||||
- **Relates to**: ADR-071 (ruvllm Training Pipeline), ADR-070 (Self-Supervised Pretraining), ADR-024 (Contrastive CSI Embedding / AETHER), ADR-069 (Cognitum Seed CSI Pipeline)
|
||||
|
||||
## Context
|
||||
|
||||
The WiFi-DensePose project needs a neural architecture that can convert raw CSI amplitude
|
||||
data into 17-keypoint COCO pose estimates. The existing `train-ruvllm.js` pipeline uses a
|
||||
simple 2-layer FC encoder (8 -> 64 -> 128) that produces contrastive embeddings for
|
||||
presence detection but cannot output spatial keypoint coordinates.
|
||||
|
||||
We evaluated published WiFi-based pose estimation architectures:
|
||||
|
||||
| Architecture | Params | Input | Key Innovation | Publication |
|
||||
|-------------|--------|-------|---------------|-------------|
|
||||
| **WiFlow** | 4.82M | 540x20 | TCN + AsymConv + Axial Attention | arXiv:2602.08661 |
|
||||
| WiPose | 11.2M | 3x3x30x20 | 3D CNN + heatmap regression | CVPR 2021 |
|
||||
| MetaFi++ | 8.6M | 114x30x20 | Transformer + meta-learning | NeurIPS 2023 |
|
||||
| Person-in-WiFi 3D | 15.3M | Multi-antenna | Deformable attention + 3D | CVPR 2024 |
|
||||
|
||||
WiFlow is the lightest published SOTA architecture, designed specifically for commercial
|
||||
WiFi hardware. Its key advantage is operating on CSI amplitude only (no phase), which
|
||||
is critical for ESP32-S3 where phase calibration is unreliable.
|
||||
|
||||
### Why WiFlow
|
||||
|
||||
1. **Lightest SOTA**: 4.82M parameters at original scale; our adaptation targets ~2.5M
|
||||
2. **Amplitude-only**: Discards phase, which is noisy on consumer hardware
|
||||
3. **Published architecture**: Fully specified in arXiv:2602.08661, reproducible
|
||||
4. **Temporal modeling**: TCN with dilated causal convolutions captures motion dynamics
|
||||
5. **Efficient attention**: Axial attention reduces O(H^2W^2) to O(H^2W + HW^2)
|
||||
6. **Proven on commercial WiFi**: Validated on commodity Intel 5300 and Atheros hardware
|
||||
|
||||
## Decision
|
||||
|
||||
Implement the WiFlow architecture in pure JavaScript (ruvllm native) with the following
|
||||
adaptations for our ESP32 single TX/RX deployment.
|
||||
|
||||
### Architecture Overview
|
||||
|
||||
```
|
||||
CSI Amplitude [128, 20]
|
||||
|
|
||||
Stage 1: TCN (Dilated Causal Conv)
|
||||
dilation = (1, 2, 4, 8), kernel = 7
|
||||
128 -> 256 -> 192 -> 128 channels
|
||||
|
|
||||
Stage 2: Asymmetric Conv Encoder
|
||||
1xk conv (k=3), stride (1,2)
|
||||
[1, 128, 20] -> [256, 8, 20]
|
||||
|
|
||||
Stage 3: Axial Self-Attention
|
||||
Width (temporal): 8 heads
|
||||
Height (feature): 8 heads
|
||||
|
|
||||
Decoder: Adaptive Avg Pool + Linear
|
||||
[256, 8, 20] -> pool -> [2048] -> [17, 2]
|
||||
|
|
||||
17 COCO Keypoints [x, y] in [0, 1]
|
||||
```
|
||||
|
||||
### Our Adaptation vs Original WiFlow
|
||||
|
||||
| Aspect | WiFlow Original | Our Adaptation | Reason |
|
||||
|--------|----------------|----------------|--------|
|
||||
| Input channels | 540 (18 links x 30 SC) | 128 (1 TX x 1 RX x 128 SC) | Single ESP32 link |
|
||||
| Time steps | 20 | 20 | Same |
|
||||
| TCN channels | 540 -> 256 -> 128 -> 64 | 128 -> 256 -> 192 -> 128 | Proportional reduction |
|
||||
| Spatial blocks | 4 (stride 2) | 4 (stride 2) | Same |
|
||||
| Attention heads | 8 | 8 | Same |
|
||||
| Parameters | 4.82M | ~1.8M | Fewer input channels |
|
||||
| Input type | Amplitude only | Amplitude only | Same |
|
||||
| Output | 17 x 2 | 17 x 2 | Same |
|
||||
|
||||
### Parameter Budget Breakdown
|
||||
|
||||
| Stage | Parameters | % of Total |
|
||||
|-------|-----------|------------|
|
||||
| TCN (4 blocks, k=7, d=1,2,4,8) | ~969K | 54% |
|
||||
| Asymmetric Conv (4 blocks, 1x3, stride 2) | ~174K | 10% |
|
||||
| Axial Attention (width + height, 8 heads) | ~592K | 33% |
|
||||
| Pose Decoder (pool + linear -> 17x2) | ~70K | 4% |
|
||||
| **Total** | **~1.8M** | **100%** |
|
||||
|
||||
### Loss Function
|
||||
|
||||
```
|
||||
L = L_H + 0.2 * L_B
|
||||
|
||||
L_H = SmoothL1(predicted, target, beta=0.1)
|
||||
L_B = (1/14) * sum_b (bone_length_b - prior_b)^2
|
||||
```
|
||||
|
||||
14 bone connections enforce anatomical constraints:
|
||||
- Nose-eye (x2): 0.06
|
||||
- Eye-ear (x2): 0.06
|
||||
- Shoulder-elbow (x2): 0.15
|
||||
- Elbow-wrist (x2): 0.13
|
||||
- Shoulder-hip (x2): 0.26
|
||||
- Hip-knee (x2): 0.25
|
||||
- Knee-ankle (x2): 0.25
|
||||
- Shoulder width: 0.20
|
||||
|
||||
All lengths normalized to person height.
|
||||
|
||||
### Training Strategy (Camera-Free Pipeline)
|
||||
|
||||
Since we have no ground-truth pose labels from cameras, training proceeds in three phases:
|
||||
|
||||
#### Phase 1: Contrastive Pretraining
|
||||
- Temporal triplets: adjacent windows are positive pairs, distant windows are negative
|
||||
- Cross-node triplets: same-time windows from different ESP32 nodes are positive
|
||||
- Uses ruvllm `ContrastiveTrainer` with triplet + InfoNCE loss
|
||||
- Learns a representation where similar CSI states cluster together
|
||||
|
||||
#### Phase 2: Pose Proxy Training
|
||||
- Generate coarse pose proxies from vitals data:
|
||||
- Person detected (presence > 0.3): place standing skeleton at center
|
||||
- High motion: perturb limb positions proportional to motion energy
|
||||
- Breathing: add micro-oscillation to torso keypoints
|
||||
- Train with SmoothL1 + bone constraint loss
|
||||
- Confidence-weighted updates (higher presence = stronger gradient)
|
||||
|
||||
#### Phase 3: Self-Refinement (Future)
|
||||
- Multi-node consistency: same person seen from different nodes should produce
|
||||
consistent pose after geometric transform
|
||||
- Temporal smoothness: adjacent frames should produce similar poses
|
||||
- Bone constraint tightening: gradually reduce tolerance
|
||||
|
||||
### Integration with Existing Pipeline
|
||||
|
||||
```
|
||||
train-ruvllm.js (ADR-071) train-wiflow.js (ADR-072)
|
||||
| |
|
||||
| 8-dim features | 128-dim raw CSI amplitude
|
||||
| -> 128-dim embedding | -> 17x2 keypoint coordinates
|
||||
| -> presence/activity/vitals | -> bone-constrained pose
|
||||
| |
|
||||
+-- ContrastiveTrainer -----+------+
|
||||
+-- TrainingPipeline -------+------+
|
||||
+-- LoRA per-node ----------+------+
|
||||
+-- TurboQuant quantize ----+------+
|
||||
+-- SafeTensors export -----+------+
|
||||
```
|
||||
|
||||
Both pipelines share the ruvllm infrastructure; WiFlow adds the deeper architecture
|
||||
for direct pose regression while the simple encoder handles embedding tasks.
|
||||
|
||||
### Performance Targets
|
||||
|
||||
| Metric | Target | Notes |
|
||||
|--------|--------|-------|
|
||||
| PCK@20 | > 80% | On lab data with 2+ nodes |
|
||||
| Forward latency | < 50ms | Pi Zero 2W at INT8 |
|
||||
| Model size (INT8) | < 2 MB | TurboQuant |
|
||||
| Bone violation rate | < 10% | 50% tolerance |
|
||||
| Temporal jitter | < 3cm | Exponential smoothing |
|
||||
|
||||
### Risk Assessment
|
||||
|
||||
| Risk | Severity | Mitigation |
|
||||
|------|----------|------------|
|
||||
| Single TX/RX has less spatial info than 18 links | High | 2-node multi-static compensates; cross-node fusion from ADR-029 |
|
||||
| Camera-free labels are coarse | Medium | Bone constraints enforce anatomy; contrastive pretrain provides structure |
|
||||
| Pure JS too slow for real-time | Medium | INT8 quantization; axial attention is O(H^2W+HW^2) not O(H^2W^2) |
|
||||
| Overfitting with ~5K frames | Medium | Temporal augmentation + noise + cross-node interpolation |
|
||||
| Phase not available (amplitude-only) | Low | WiFlow was designed amplitude-only; not a limitation |
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
- Proven SOTA architecture adapted to our hardware constraints
|
||||
- Pure JavaScript implementation runs everywhere ruvllm runs (Node.js, browser WASM)
|
||||
- Bone constraints enforce physically plausible outputs even with noisy inputs
|
||||
- Shares training infrastructure with existing ruvllm pipeline
|
||||
- Modular: each stage (TCN, AsymConv, Axial, Decoder) is independently testable
|
||||
|
||||
### Negative
|
||||
- ~1.8M parameters is 193x larger than simple CsiEncoder (9,344 params)
|
||||
- Forward pass is slower (~50ms vs <1ms for simple encoder)
|
||||
- Camera-free training will produce lower accuracy than supervised WiFlow
|
||||
- No ground-truth PCK evaluation possible without camera labels
|
||||
- Axial attention is O(N^2) within each axis, limiting scalability
|
||||
|
||||
### Neutral
|
||||
- FLOPs dominated by TCN (~48%) due to dilated convolutions
|
||||
- INT8 quantization brings model to ~1.7MB, viable for edge deployment
|
||||
- Architecture is fixed (no NAS); future work could explore lighter variants
|
||||
|
||||
## Implementation
|
||||
|
||||
### Files Created
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `scripts/wiflow-model.js` | WiFlow architecture (all stages, loss, metrics) |
|
||||
| `scripts/train-wiflow.js` | Training pipeline (contrastive + pose proxy + LoRA + quant) |
|
||||
| `scripts/benchmark-wiflow.js` | Benchmarking (latency, params, FLOPs, memory, quality) |
|
||||
| `docs/adr/ADR-072-wiflow-architecture.md` | This document |
|
||||
|
||||
### Usage
|
||||
|
||||
```bash
|
||||
# Train on collected data
|
||||
node scripts/train-wiflow.js --data data/recordings/pretrain-*.csi.jsonl
|
||||
|
||||
# Train with more epochs and custom output
|
||||
node scripts/train-wiflow.js --data data/recordings/*.csi.jsonl --epochs 50 --output models/wiflow-v2
|
||||
|
||||
# Contrastive pretraining only (no labels needed)
|
||||
node scripts/train-wiflow.js --data data/recordings/*.csi.jsonl --contrastive-only
|
||||
|
||||
# Benchmark
|
||||
node scripts/benchmark-wiflow.js
|
||||
|
||||
# Benchmark with trained model
|
||||
node scripts/benchmark-wiflow.js --model models/wiflow-v1
|
||||
```
|
||||
|
||||
### Dependencies
|
||||
|
||||
- ruvllm (vendored at `vendor/ruvector/npm/packages/ruvllm/src/`)
|
||||
- `ContrastiveTrainer`, `tripletLoss`, `infoNCELoss`, `computeGradient`
|
||||
- `TrainingPipeline`
|
||||
- `LoraAdapter`, `LoraManager`
|
||||
- `EwcManager`
|
||||
- `ModelExporter`, `SafeTensorsWriter`
|
||||
- No external ML frameworks (no PyTorch, no TensorFlow, no ONNX Runtime)
|
||||
|
||||
## References
|
||||
|
||||
- WiFlow: arXiv:2602.08661
|
||||
- COCO Keypoints: https://cocodataset.org/#keypoints-2020
|
||||
- Axial Attention: Wang et al., "Axial-DeepLab", ECCV 2020
|
||||
- TCN: Bai et al., "An Empirical Evaluation of Generic Convolutional and Recurrent Networks for Sequence Modeling", 2018
|
||||
@@ -1,202 +0,0 @@
|
||||
# ADR-073: Multi-Frequency Mesh Scanning
|
||||
|
||||
| Field | Value |
|
||||
|-------------|--------------------------------------------|
|
||||
| **Status** | Proposed |
|
||||
| **Date** | 2026-04-02 |
|
||||
| **Authors** | ruv |
|
||||
| **Depends** | ADR-018 (binary frame), ADR-029 (channel hopping), ADR-039 (edge processing), ADR-060 (channel override) |
|
||||
|
||||
## Context
|
||||
|
||||
The current WiFi-DensePose deployment uses 2 ESP32-S3 nodes operating on a single WiFi channel (channel 5, 2432 MHz). A scan of the office environment reveals 9 WiFi networks across 6 distinct channels (1, 3, 5, 6, 9, 11), each broadcasting continuously. These neighbor networks are free RF illuminators whose signals pass through the room and interact with objects, people, and walls.
|
||||
|
||||
**Current single-channel limitations:**
|
||||
|
||||
1. **19% null subcarriers** — metal objects (desk, monitor frame, filing cabinet) create frequency-selective fading that blocks specific subcarriers on channel 5. These nulls are permanent blind spots in the RF map.
|
||||
|
||||
2. **No frequency diversity** — objects that are transparent at 2432 MHz may be opaque at 2412 MHz or 2462 MHz, and vice versa. A metal mesh that blocks one wavelength (122.5 mm at 2432 MHz) may pass another (124.0 mm at 2412 MHz) due to the mesh aperture-to-wavelength ratio.
|
||||
|
||||
3. **Single-perspective CSI** — both nodes see the same 52-64 subcarriers on the same channel. The subcarrier indices map to the same frequency bins, providing no spectral diversity.
|
||||
|
||||
4. **Neighbor illuminator waste** — 6 other APs broadcast continuously in the room. Their signals pass through walls, furniture, and people, creating CSI-measurable reflections that we currently ignore because we only listen on channel 5.
|
||||
|
||||
## Decision
|
||||
|
||||
Implement interleaved multi-frequency channel hopping across the 2 ESP32-S3 nodes, scanning 6 WiFi channels to build a wideband RF map of the room.
|
||||
|
||||
### Channel Allocation Strategy
|
||||
|
||||
The 2.4 GHz ISM band has 3 non-overlapping 20 MHz channels (1, 6, 11) and several partially-overlapping channels between them. We allocate channels to maximize both spectral coverage and illuminator exploitation:
|
||||
|
||||
```
|
||||
Node 1: ch 1, 6, 11 (non-overlapping, full band coverage)
|
||||
Node 2: ch 3, 5, 9 (interleaved, near neighbor APs)
|
||||
```
|
||||
|
||||
**Rationale for this split:**
|
||||
|
||||
| Channel | Freq (MHz) | Node | Neighbor Illuminators | Purpose |
|
||||
|---------|------------|------|----------------------------------------------|-----------------------------------|
|
||||
| 1 | 2412 | 1 | (none visible, but lower freq = better penetration) | Low-frequency penetration |
|
||||
| 3 | 2422 | 2 | conclusion mesh (signal 44) | Exploit neighbor AP as illuminator |
|
||||
| 5 | 2432 | 2 | ruv.net (100), Cohen-Guest (100), HP LaserJet (94) | Primary channel, strongest illuminators |
|
||||
| 6 | 2437 | 1 | Innanen (signal 19) | Center band, non-overlapping |
|
||||
| 9 | 2452 | 2 | NETGEAR72 (42), NETGEAR72-Guest (42) | Exploit dual NETGEAR illuminators |
|
||||
| 11 | 2462 | 1 | COGECO-21B20 (100), COGECO-4321 (30) | High-frequency, strong illuminators |
|
||||
|
||||
Each node dwells on a channel for 250 ms (configurable), collects 3-4 CSI frames, then hops to the next. The 3-channel rotation completes in 750 ms, giving ~1.3 full rotations per second.
|
||||
|
||||
### Physics Basis
|
||||
|
||||
At 2.4 GHz, WiFi wavelength ranges from 122.0 mm (ch 14, 2484 MHz) to 124.0 mm (ch 1, 2412 MHz). While this is a narrow range (~2%), the effect on multipath is significant:
|
||||
|
||||
1. **Frequency-selective fading**: multipath reflections create constructive/destructive interference patterns that vary with frequency. A 2 cm path length difference produces a null at 2432 MHz but constructive interference at 2412 MHz.
|
||||
|
||||
2. **Diffraction around objects**: Huygens-Fresnel diffraction depends on wavelength. Objects smaller than ~lambda/2 (61 mm) scatter differently across the band. Common office objects (monitor bezels, chair legs, cable bundles) are in this range.
|
||||
|
||||
3. **Material transparency**: some materials (wire mesh, perforated metal, PCB ground planes) have frequency-dependent transmission. A monitor's EMI shielding mesh with 5 mm apertures blocks 2.4 GHz signals but the exact attenuation varies with frequency due to slot antenna effects.
|
||||
|
||||
4. **Subcarrier orthogonality**: OFDM subcarriers on different channels are in different frequency bins. A null on subcarrier 15 of channel 5 does not imply a null on subcarrier 15 of channel 1, because they map to different absolute frequencies.
|
||||
|
||||
### Null Diversity Mechanism
|
||||
|
||||
```
|
||||
Channel 5 subcarriers: ▅▆█▇▅▃▁_▁▃▅▆█▇▅▃▁_▁▃▅▆█▇▅▃
|
||||
^ null (metal desk)
|
||||
Channel 1 subcarriers: ▃▅▆█▇▅▃▅▆█▇▅▃▅▆█▇▅▃▅▆█▇▅▃▅▃
|
||||
^ resolved! Different freq = different null pattern
|
||||
|
||||
Channel 11 subcarriers: ▅▃▁_▁▃▅▆█▇▅▃▅▆▅▃▁_▁▃▅▆█▇▅▃▅
|
||||
^ null here instead (shifted by frequency offset)
|
||||
```
|
||||
|
||||
By fusing subcarrier data across channels, nulls that exist on one channel are filled by non-null data from other channels. The remaining nulls (present on ALL channels) represent truly opaque objects — large metal surfaces that block all 2.4 GHz frequencies.
|
||||
|
||||
### Wideband View
|
||||
|
||||
Single channel: ~52-64 subcarriers (20 MHz bandwidth)
|
||||
Multi-channel (6 channels): ~312-384 effective subcarrier observations (120 MHz coverage)
|
||||
|
||||
This is not simply 6x the resolution (the subcarrier spacing within each channel is the same), but it provides:
|
||||
- 6x the spectral diversity for null mitigation
|
||||
- 6x the illuminator variety (different APs = different signal paths)
|
||||
- Frequency-dependent scattering signatures for material classification
|
||||
|
||||
## Integration
|
||||
|
||||
### Firmware (already supported)
|
||||
|
||||
The channel hopping infrastructure is already implemented in the ESP32 firmware (ADR-029):
|
||||
|
||||
```c
|
||||
// csi_collector.h — already exists
|
||||
void csi_collector_set_hop_table(const uint8_t *channels, uint8_t hop_count, uint32_t dwell_ms);
|
||||
void csi_collector_start_hop_timer(void);
|
||||
```
|
||||
|
||||
The ADR-018 binary frame header already includes the channel/frequency field at bytes [8..11], so the server-side parser can distinguish frames from different channels without any firmware changes.
|
||||
|
||||
### Provisioning Commands
|
||||
|
||||
```bash
|
||||
# Node 1 (COM7): non-overlapping channels 1, 6, 11
|
||||
python firmware/esp32-csi-node/provision.py --port COM7 \
|
||||
--ssid "ruv.net" --password "..." --target-ip 192.168.1.20 \
|
||||
--hop-channels 1,6,11 --hop-dwell-ms 250
|
||||
|
||||
# Node 2 (COM_): interleaved channels 3, 5, 9
|
||||
python firmware/esp32-csi-node/provision.py --port COM_ \
|
||||
--ssid "ruv.net" --password "..." --target-ip 192.168.1.20 \
|
||||
--hop-channels 3,5,9 --hop-dwell-ms 250
|
||||
```
|
||||
|
||||
Note: `--hop-channels` and `--hop-dwell-ms` require provision.py support for writing these values to NVS. If not yet implemented, the firmware's `csi_collector_set_hop_table()` can be called directly from the main init code with compile-time constants.
|
||||
|
||||
### Server-Side Processing
|
||||
|
||||
Three new Node.js scripts consume the multi-channel CSI data:
|
||||
|
||||
| Script | Purpose |
|
||||
|--------|---------|
|
||||
| `scripts/rf-scan.js` | Single-channel live RF room scanner with ASCII spectrum |
|
||||
| `scripts/rf-scan-multifreq.js` | Multi-channel scanner with null diversity analysis |
|
||||
| `scripts/benchmark-rf-scan.js` | Quantitative benchmark of multi-channel performance |
|
||||
|
||||
All scripts parse the ADR-018 binary UDP format and use the frequency field to separate frames by channel.
|
||||
|
||||
### Cognitum Seed Integration
|
||||
|
||||
The Cognitum Seed vector store (ADR-069) currently stores 1,605 vectors from single-channel CSI. With multi-frequency scanning:
|
||||
|
||||
1. **Per-channel feature vectors**: store separate 8-dim feature vectors for each channel, tagged with channel number. This increases the vector count to ~9,630 (6 channels x 1,605).
|
||||
|
||||
2. **Wideband feature vector**: concatenate or average per-channel features into a 48-dim wideband vector for richer kNN search. Objects that are ambiguous on one channel may be clearly distinguishable in the wideband representation.
|
||||
|
||||
3. **Null-aware embeddings**: encode null subcarrier patterns as part of the feature vector. The null pattern itself is informative — a consistent null at subcarrier 15 across all channels indicates a large metal object, while a null only on channel 5 indicates a frequency-dependent scatterer.
|
||||
|
||||
## Performance Targets
|
||||
|
||||
| Metric | Single-Channel Baseline | Multi-Channel Target | Method |
|
||||
|--------|------------------------|---------------------|--------|
|
||||
| Subcarrier count | ~52-64 | ~312-384 (6x) | 6 channels x 52-64 subcarriers |
|
||||
| Null gap | 19% | <5% | Null diversity across channels |
|
||||
| Position resolution | ~30 cm | ~15 cm | sqrt(6) improvement from independent observations |
|
||||
| Per-channel FPS | 12 fps | ~4 fps | 250 ms dwell x 3 channels = 750 ms rotation |
|
||||
| Total FPS (all channels) | 12 fps | ~12 fps per node (4 fps x 3 channels) |
|
||||
| Wideband rotation | N/A | ~1.3 Hz | Full 3-channel rotation in 750 ms |
|
||||
|
||||
## Risks
|
||||
|
||||
### Per-Channel Sample Rate Reduction
|
||||
|
||||
Channel hopping reduces the per-channel sample rate from 12 fps (single channel) to approximately 4 fps per channel (250 ms dwell, 3 channels). This affects:
|
||||
|
||||
- **Vitals extraction**: breathing rate (0.1-0.5 Hz) requires at least 2 fps (Nyquist). At 4 fps per channel, this is met. Heart rate (0.8-2.0 Hz) requires at least 4 fps, which is marginal. Mitigation: keep one channel as "primary" with longer dwell for vitals, or fuse phase data across channels.
|
||||
|
||||
- **Motion tracking**: 4 fps is sufficient for walking speed (<2 m/s) but insufficient for fast gestures. If gesture recognition is needed, reduce to 2-channel hopping or increase dwell rate.
|
||||
|
||||
### Channel Hopping Latency
|
||||
|
||||
`esp_wifi_set_channel()` takes ~1-5 ms on ESP32-S3. During the transition, no CSI frames are captured. At 250 ms dwell, this is <2% overhead.
|
||||
|
||||
### AP Disconnection
|
||||
|
||||
Channel hopping may cause the ESP32 to lose connection to the home AP (ruv.net on channel 5) when dwelling on other channels. The STA reconnects automatically, but there may be brief UDP packet loss. Mitigation: the firmware already handles this gracefully — CSI collection works in promiscuous mode regardless of STA connection state.
|
||||
|
||||
### Increased Server Load
|
||||
|
||||
2 nodes x 3 channels x 4 fps = 24 frames/second total UDP traffic. Each frame is ~150-200 bytes (20-byte header + 64 subcarriers x 2 bytes I/Q). Total: ~4.8 KB/s — negligible.
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
1. **5 GHz channels**: ESP32-S3 supports 5 GHz CSI, and the shorter wavelength (60 mm) provides better spatial resolution. Rejected because: (a) no 5 GHz APs visible in the current environment, so no free illuminators; (b) 5 GHz has worse wall penetration, reducing the effective sensing volume.
|
||||
|
||||
2. **More nodes**: adding a 3rd or 4th ESP32 node would increase spatial diversity without channel hopping. Rejected for now due to cost, but this is complementary — more nodes + channel hopping would give both spatial and spectral diversity.
|
||||
|
||||
3. **Wider bandwidth (HT40)**: using 40 MHz channels doubles subcarrier count per channel. Rejected because: (a) HT40 requires a secondary channel, reducing available channels for hopping; (b) many neighbor APs use HT20, so their illumination only covers 20 MHz.
|
||||
|
||||
## SNN Integration (ADR-074)
|
||||
|
||||
Multi-frequency scanning produces subcarrier data across 6 channels, creating temporal patterns that are well-suited for spiking neural network processing. ADR-074 introduces an SNN with STDP learning that consumes the multi-channel CSI stream.
|
||||
|
||||
**Key interactions with multi-frequency data:**
|
||||
|
||||
1. **Null diversity as SNN input**: subcarriers that are null on one channel but active on another produce a distinctive spike pattern (spikes only during certain channel dwells). STDP learns to associate these cross-channel patterns with specific objects or zones — something a single-channel SNN cannot do.
|
||||
|
||||
2. **Channel-interleaved temporal coding**: because each node dwells on 3 channels in a 750ms rotation, the SNN receives subcarrier data in a repeating temporal pattern (ch1 → ch2 → ch3 → ch1 ...). The SNN's LIF membrane dynamics integrate spikes across the rotation, naturally performing cross-channel fusion through temporal summation. A hidden neuron that receives spikes from subcarrier 15 on channel 1 AND subcarrier 15 on channel 6 will fire more strongly than one receiving either alone.
|
||||
|
||||
3. **Expanded input mode**: on the server (not constrained by ESP32 memory), the SNN can use 384 input neurons (6 channels x 64 subcarriers) instead of 128. This provides maximum spectral diversity per frame but requires ~150 KB of weight storage. The `snn-csi-processor.js` script supports this via the `--hidden` flag to scale the network.
|
||||
|
||||
4. **Illuminator fingerprinting**: different neighbor APs have different beamforming patterns and power levels. The SNN learns which subcarrier patterns belong to which illuminator, enabling it to distinguish AP-specific signatures from human-caused perturbations. This is especially useful for the NETGEAR dual-AP setup on channel 9, where two illuminators from different positions create stereo-like RF coverage.
|
||||
|
||||
## References
|
||||
|
||||
- ADR-018: CSI binary frame format
|
||||
- ADR-029: Channel hopping infrastructure
|
||||
- ADR-039: Edge processing pipeline
|
||||
- ADR-060: Channel override provisioning
|
||||
- ADR-069: Cognitum Seed CSI pipeline
|
||||
- ADR-074: Spiking neural network for CSI sensing
|
||||
- IEEE 802.11-2020, Section 21 (OFDM PHY)
|
||||
- ESP-IDF CSI Guide: https://docs.espressif.com/projects/esp-idf/en/v5.4/esp32s3/api-guides/wifi.html#wi-fi-channel-state-information
|
||||
@@ -1,208 +0,0 @@
|
||||
# ADR-074: Spiking Neural Network for CSI Sensing
|
||||
|
||||
| Field | Value |
|
||||
|-------------|--------------------------------------------|
|
||||
| **Status** | Proposed |
|
||||
| **Date** | 2026-04-02 |
|
||||
| **Authors** | ruv |
|
||||
| **Depends** | ADR-018 (binary frame), ADR-029 (channel hopping), ADR-069 (Cognitum Seed), ADR-073 (multi-frequency mesh) |
|
||||
|
||||
## Context
|
||||
|
||||
The current WiFi-DensePose CSI sensing pipeline uses two approaches for interpreting subcarrier data:
|
||||
|
||||
1. **Static thresholds** — presence detection fires when subcarrier variance exceeds a fixed value. This works in calibrated environments but fails when the RF landscape changes (furniture moved, new objects, temperature drift). Recalibration requires manual intervention or batch retraining.
|
||||
|
||||
2. **Batch-trained FC encoder** — the neural network in `wifi-densepose-nn` maps CSI frames to 8-dimensional feature vectors. It requires labeled training data, offline training epochs, and model deployment. The encoder cannot adapt to a new environment without collecting new data and retraining.
|
||||
|
||||
Neither approach handles online adaptation. When an ESP32 node is deployed in a new room, the first hours produce noisy, unreliable output until the thresholds are tuned or a model is trained. In disaster scenarios (ADR MAT), there is no time for calibration.
|
||||
|
||||
**Spiking Neural Networks (SNNs)** offer an alternative. Unlike traditional ANNs that process continuous values in batch mode, SNNs communicate through discrete spike events and learn online via Spike-Timing-Dependent Plasticity (STDP). This is a natural fit for CSI data:
|
||||
|
||||
- CSI subcarrier amplitudes are temporal signals sampled at 12-22 fps
|
||||
- Amplitude changes (not absolute values) carry the information about motion, breathing, and presence
|
||||
- STDP learns temporal correlations between subcarriers without labels
|
||||
- Event-driven processing means idle rooms (no motion) consume near-zero compute
|
||||
|
||||
The `@ruvector/spiking-neural` package (vendored at `vendor/ruvector/npm/packages/spiking-neural/`) provides production-ready LIF neurons, STDP learning, lateral inhibition, and SIMD-optimized vector math in pure JavaScript with zero dependencies.
|
||||
|
||||
## Decision
|
||||
|
||||
Integrate `@ruvector/spiking-neural` into the CSI sensing pipeline as an online unsupervised pattern learner that runs alongside the existing FC encoder. The SNN provides real-time adaptation while the FC encoder provides stable baseline predictions.
|
||||
|
||||
### Network Architecture
|
||||
|
||||
```
|
||||
CSI Frame (128 subcarriers)
|
||||
|
|
||||
v
|
||||
[ Rate Encoding ] -----> 128 input neurons (one per subcarrier)
|
||||
| amplitude delta -> spike rate
|
||||
v
|
||||
[ LIF Hidden Layer ] ---> 64 hidden neurons (tau=20ms)
|
||||
| STDP learns subcarrier correlations
|
||||
| lateral inhibition -> sparse codes
|
||||
v
|
||||
[ LIF Output Layer ] ---> 8 output neurons
|
||||
|
|
||||
v
|
||||
presence | motion | breathing | heart_rate | phase_var | persons | fall | rssi
|
||||
```
|
||||
|
||||
**Layer parameters:**
|
||||
|
||||
| Layer | Neurons | tau (ms) | v_thresh (mV) | Function |
|
||||
|-------|---------|----------|---------------|----------|
|
||||
| Input | 128 | N/A | N/A | Rate-coded spike generation from subcarrier deltas |
|
||||
| Hidden | 64 | 20.0 | -50.0 | STDP learns correlated subcarrier groups |
|
||||
| Output | 8 | 25.0 | -50.0 | Each neuron specializes in one sensing modality |
|
||||
|
||||
**Synapse parameters:**
|
||||
|
||||
| Connection | Count | a_plus | a_minus | w_init | Lateral Inhibition |
|
||||
|------------|-------|--------|---------|--------|-------------------|
|
||||
| Input -> Hidden | 8,192 | 0.005 | 0.005 | 0.3 | No |
|
||||
| Hidden -> Output | 512 | 0.003 | 0.003 | 0.2 | Yes (strength=15.0) |
|
||||
|
||||
Total synapses: 8,704. At 4 bytes per weight, this is 34 KB — fits in ESP32 SRAM.
|
||||
|
||||
### Input Encoding
|
||||
|
||||
CSI amplitudes are converted to spike rates using rate coding:
|
||||
|
||||
1. Compute per-subcarrier amplitude: `amp[i] = sqrt(I[i]^2 + Q[i]^2)` from the ADR-018 binary frame
|
||||
2. Compute amplitude delta from previous frame: `delta[i] = |amp[i] - prev_amp[i]|`
|
||||
3. Normalize deltas to [0, 1] range: `norm[i] = min(delta[i] / max_delta, 1.0)`
|
||||
4. Feed `norm` to `rateEncoding(norm, dt, max_rate)` which produces Poisson spikes
|
||||
|
||||
Higher amplitude changes produce more spikes. Static subcarriers (no motion) produce few or no spikes. This is the key energy advantage: an empty room generates almost no spikes, so the SNN does almost no work.
|
||||
|
||||
### STDP Learning Rule
|
||||
|
||||
STDP strengthens connections between neurons that fire together (within a time window) and weakens connections between neurons that fire out of sync:
|
||||
|
||||
- **LTP (Long-Term Potentiation)**: if a presynaptic neuron fires before a postsynaptic neuron within 20ms, the weight increases by `a_plus * exp(-dt/tau_stdp)`
|
||||
- **LTD (Long-Term Depression)**: if a postsynaptic neuron fires before a presynaptic neuron, the weight decreases by `a_minus * exp(-dt/tau_stdp)`
|
||||
|
||||
Over time, this causes the hidden layer neurons to specialize. Subcarriers that consistently change together (e.g., subcarriers 10-20 affected by a person walking through zone A) become strongly connected to the same hidden neuron. Different motion patterns activate different hidden neuron clusters.
|
||||
|
||||
### Lateral Inhibition (Winner-Take-All)
|
||||
|
||||
The output layer uses lateral inhibition with strength 15.0. When one output neuron fires, it suppresses all others. This forces each output neuron to specialize in a distinct pattern:
|
||||
|
||||
- Output 0: presence (any subcarrier activity above baseline)
|
||||
- Output 1: motion (widespread subcarrier changes, high spike rate)
|
||||
- Output 2: breathing (periodic 0.1-0.5 Hz modulation on chest-area subcarriers)
|
||||
- Output 3: heart rate (periodic 0.8-2.0 Hz modulation, lower amplitude than breathing)
|
||||
- Output 4: phase variance (phase instability across subcarriers)
|
||||
- Output 5: person count (number of distinct active subcarrier clusters)
|
||||
- Output 6: fall (sudden high-amplitude burst followed by silence)
|
||||
- Output 7: RSSI trend (overall signal strength change)
|
||||
|
||||
The neuron-to-label mapping is not fixed by training. Instead, the mapping is discovered by observing which output neuron fires most for each known condition during an optional calibration phase. If no calibration is available, the output is reported as raw spike counts per output neuron, and downstream consumers (Cognitum Seed, SONA) interpret the patterns.
|
||||
|
||||
### Integration with Existing Pipeline
|
||||
|
||||
The SNN does not replace the FC encoder. It runs in parallel:
|
||||
|
||||
```
|
||||
CSI Frame ----+----> FC Encoder --------> 8-dim feature vector (stable, trained)
|
||||
|
|
||||
+----> SNN (STDP) --------> 8-dim spike rate vector (adaptive, online)
|
||||
|
|
||||
+----> SONA Adapter -------> Weighted fusion of both signals
|
||||
```
|
||||
|
||||
SONA (Self-Optimizing Neural Architecture) receives both signals and learns which source is more reliable for each output dimension. In a new environment where the FC encoder has not been retrained, SONA automatically weights the SNN output higher because it adapts faster. As the FC encoder is retrained on local data, SONA shifts weight back toward it.
|
||||
|
||||
### Energy and Compute Budget
|
||||
|
||||
| Metric | FC Encoder | SNN (STDP) | Ratio |
|
||||
|--------|-----------|------------|-------|
|
||||
| Compute per frame (idle room) | 8,192 MACs | ~50 spike events | ~160x less |
|
||||
| Compute per frame (active room) | 8,192 MACs | ~500 spike events | ~16x less |
|
||||
| Memory | 34 KB weights | 34 KB weights | Equal |
|
||||
| Adaptation | Offline retraining | Online, continuous | SNN wins |
|
||||
| Stability | High (frozen weights) | Lower (weights drift) | FC wins |
|
||||
| Latency to first useful output | Hours (needs training data) | ~30 seconds | SNN wins |
|
||||
|
||||
The SNN's event-driven nature means it processes only spikes, not every subcarrier on every frame. In an idle room with no motion, subcarrier deltas are near zero, spike rates drop to near zero, and the SNN consumes negligible compute. This is ideal for battery-powered or thermally constrained deployments (ESP32, Cognitum Seed Pi Zero).
|
||||
|
||||
### Deployment Targets
|
||||
|
||||
| Platform | Runtime | Notes |
|
||||
|----------|---------|-------|
|
||||
| Node.js server | `require('@ruvector/spiking-neural')` | Primary. Receives UDP frames, runs SNN. |
|
||||
| Cognitum Seed (Pi Zero) | Node.js ARM | 34 KB model fits. ~0.06ms per step at 100 neurons. |
|
||||
| ESP32-S3 (WASM) | wasm3 interpreter | Optional. SNN weights exported as flat Float32Array. |
|
||||
| Browser | WebAssembly or JS | Via `wifi-densepose-wasm` crate's JS bindings. |
|
||||
|
||||
### Multi-Channel SNN (ADR-073 Integration)
|
||||
|
||||
With multi-frequency mesh scanning (ADR-073), the SNN input expands:
|
||||
|
||||
- **Single-channel mode**: 128 input neurons (64 subcarriers x 2 for I/Q or amplitude/phase)
|
||||
- **Multi-channel mode**: 128 input neurons, but the subcarrier index rotates across channels. Each channel's subcarriers map to the same neuron indices, but at different time slots. The SNN's temporal dynamics naturally integrate cross-channel information because STDP operates across time.
|
||||
|
||||
Alternatively, for maximum spectral diversity, a wider SNN (384 input neurons for 6 channels x 64 subcarriers) can be used on the server where memory is not constrained.
|
||||
|
||||
## Performance Targets
|
||||
|
||||
| Metric | Target | Method |
|
||||
|--------|--------|--------|
|
||||
| SNN step latency | <0.1ms | 128-64-8 network, ~8,700 synapses |
|
||||
| STDP convergence | <30 seconds | ~360 frames at 12 fps, patterns stabilize |
|
||||
| Output accuracy (after adaptation) | >80% | Compared to manually labeled ground truth |
|
||||
| Memory footprint | <50 KB | Weights + neuron state |
|
||||
| Idle room spike rate | <10 spikes/frame | Event-driven: near-zero compute when nothing moves |
|
||||
| Adaptation to new environment | <2 minutes | STDP relearns subcarrier correlations |
|
||||
|
||||
## Risks
|
||||
|
||||
### Weight Drift
|
||||
|
||||
STDP learning never stops. In a stable environment, weights can slowly drift as the network over-fits to the current RF landscape. Mitigation: implement weight decay (multiply all weights by 0.999 per second) and clamp weights to [w_min, w_max].
|
||||
|
||||
### Output Neuron Reassignment
|
||||
|
||||
If the RF environment changes significantly (new furniture, different room), output neurons may reassign their specialization. The mapping from output neuron index to label (presence, motion, etc.) may change. Mitigation: periodically log the output neuron activity and detect reassignment events. Downstream consumers should use the spike pattern, not the neuron index, for classification.
|
||||
|
||||
### Interference with FC Encoder
|
||||
|
||||
If SONA naively averages the SNN and FC encoder outputs, a poorly adapted SNN could degrade overall accuracy. Mitigation: SONA uses confidence-weighted fusion. The SNN output includes a confidence signal (total spike count / expected spike count). Low confidence = low weight.
|
||||
|
||||
### STDP Learning Rate Sensitivity
|
||||
|
||||
If `a_plus` and `a_minus` are too high, the SNN oscillates and never converges. If too low, adaptation takes too long. The default values (0.005 and 0.003) are conservative. The script includes a `--learning-rate` flag for tuning.
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
1. **Online gradient descent on FC encoder** — backprop through the FC network with each new frame. Rejected because: (a) requires a loss function, which requires labels; (b) continuous gradient updates on a small model lead to catastrophic forgetting of the pretrained representations.
|
||||
|
||||
2. **Adaptive thresholds only** — replace fixed thresholds with exponentially-weighted moving averages. Rejected because: (a) single-variable thresholds cannot capture multi-subcarrier correlations; (b) no representation learning — each subcarrier is still processed independently.
|
||||
|
||||
3. **Reservoir computing (Echo State Network)** — use a fixed random recurrent network as a temporal feature extractor. Partially viable, but: (a) requires a linear readout layer trained with labels; (b) the random reservoir does not adapt to the specific RF environment.
|
||||
|
||||
4. **Train SNN with supervision** — use surrogate gradient methods to train the SNN on labeled data. Rejected because: (a) defeats the purpose of online unsupervised learning; (b) the `@ruvector/spiking-neural` package does not implement surrogate gradients.
|
||||
|
||||
## Implementation
|
||||
|
||||
The integration is implemented in `scripts/snn-csi-processor.js`, a standalone Node.js script that:
|
||||
|
||||
1. Receives live CSI frames via UDP (port 5006, ADR-018 binary format)
|
||||
2. Decodes subcarrier I/Q data and computes amplitude deltas
|
||||
3. Feeds deltas through rate encoding into the SNN
|
||||
4. Applies STDP learning on every frame (online, unsupervised)
|
||||
5. Maps output neuron spike counts to sensing labels
|
||||
6. Prints real-time ASCII visualization of SNN activity
|
||||
7. Optionally forwards learned patterns to Cognitum Seed
|
||||
|
||||
## References
|
||||
|
||||
- ADR-018: CSI binary frame format
|
||||
- ADR-029: Channel hopping infrastructure
|
||||
- ADR-069: Cognitum Seed CSI pipeline
|
||||
- ADR-073: Multi-frequency mesh scanning
|
||||
- Maass, W. (1997). "Networks of spiking neurons: The third generation of neural network models." Neural Networks, 10(9), 1659-1671.
|
||||
- Bi, G. & Poo, M. (1998). "Synaptic modifications in cultured hippocampal neurons: Dependence on spike timing." Journal of Neuroscience, 18(24), 10464-10472.
|
||||
- `@ruvector/spiking-neural` v1.0.1 — LIF, STDP, lateral inhibition, SIMD
|
||||
@@ -1,195 +0,0 @@
|
||||
# ADR-075: Min-Cut Based Person Separation from Subcarrier Correlation
|
||||
|
||||
- **Status:** Proposed
|
||||
- **Date:** 2026-04-02
|
||||
- **Issue:** #348 — `n_persons` always reports 4 regardless of actual occupancy
|
||||
- **Depends on:** ADR-016 (RuVector integration), ADR-041 (person tracking), ADR-073 (multifrequency mesh scan)
|
||||
|
||||
## Context
|
||||
|
||||
### The Bug
|
||||
|
||||
Issue #348 reports that the ESP32 firmware's multi-person counting always reports
|
||||
`n_persons = 4`. The root cause is in the WASM edge module
|
||||
`sig_mincut_person_match.rs`, which uses a fixed `MAX_PERSONS = 4` constant and a
|
||||
threshold-based variance classifier to populate person slots. The classifier bins
|
||||
subcarriers into "dynamic" vs "static" using a single fixed variance threshold
|
||||
(`DYNAMIC_VAR_THRESH = 0.15`). In practice:
|
||||
|
||||
1. The threshold is miscalibrated for real-world CSI data — almost any room with
|
||||
multipath reflections pushes a majority of subcarriers above 0.15 variance.
|
||||
2. The subcarrier-to-person assignment uses a greedy Hungarian-lite matcher that
|
||||
fills all 4 slots once there are >= 4 dynamic subcarriers (which is nearly
|
||||
always the case).
|
||||
3. There is no mechanism to determine how many independent movers exist — the
|
||||
algorithm assumes all 4 slots should be filled.
|
||||
|
||||
### Prior Art
|
||||
|
||||
The Rust crate `ruvector-mincut` (vendored at `vendor/ruvector/crates/ruvector-mincut/`)
|
||||
implements a full dynamic min-cut algorithm with O(n^{o(1)}) amortized update time,
|
||||
Stoer-Wagner exact min-cut, and online edge insert/delete. It is already integrated
|
||||
in the training pipeline (`wifi-densepose-train/src/metrics.rs`) via
|
||||
`DynamicPersonMatcher`.
|
||||
|
||||
### WiFi Sensing Insight
|
||||
|
||||
When a person moves through a room, they perturb the Fresnel zones of specific
|
||||
subcarrier frequencies. Subcarriers whose Fresnel zones overlap the person's body
|
||||
change **together** — their amplitudes are temporally correlated. When two people
|
||||
move independently, they create two **separate** groups of correlated subcarriers.
|
||||
This correlation structure forms a natural graph partitioning problem.
|
||||
|
||||
## Decision
|
||||
|
||||
Replace the fixed-threshold person counter with a spectral min-cut algorithm
|
||||
operating on the subcarrier temporal correlation graph. This runs in the bridge
|
||||
script (`scripts/mincut-person-counter.js`) or on Cognitum Seed, and feeds the
|
||||
corrected person count back to the feature vector before ingest.
|
||||
|
||||
### Algorithm
|
||||
|
||||
1. **Sliding window accumulation**: Maintain the last 2 seconds of subcarrier
|
||||
amplitude data (~40 frames at 20 fps). Each frame provides a 64-element
|
||||
amplitude vector (one per subcarrier).
|
||||
|
||||
2. **Pairwise Pearson correlation**: For all subcarrier pairs (i, j), compute
|
||||
the Pearson correlation coefficient over the sliding window:
|
||||
|
||||
```
|
||||
r(i,j) = cov(amp_i, amp_j) / (std(amp_i) * std(amp_j))
|
||||
```
|
||||
|
||||
This produces a 64x64 correlation matrix.
|
||||
|
||||
3. **Graph construction**: Build a weighted undirected graph:
|
||||
- **Nodes** = subcarriers (64 for single-antenna ESP32-S3, up to 128 for dual)
|
||||
- **Edges** = pairs with |r(i,j)| > 0.3 (correlation threshold)
|
||||
- **Weight** = |r(i,j)| (correlation strength)
|
||||
- Discard null subcarriers (amplitude consistently near zero)
|
||||
- Expected: ~1500-2500 edges for 64 active subcarriers
|
||||
|
||||
4. **Iterative Stoer-Wagner min-cut**: Apply the Stoer-Wagner algorithm to find
|
||||
the global minimum cut. If the min-cut weight is below a separation threshold
|
||||
(empirically 2.0), the cut represents a real boundary between independent
|
||||
movers. Split the graph at the cut and recurse on each partition.
|
||||
|
||||
5. **Person count**: The number of partitions after all valid cuts = number of
|
||||
independent movers = person count. A single connected component with high
|
||||
internal correlation and no low-weight cut = 1 person (or 0 if variance is
|
||||
also low).
|
||||
|
||||
6. **Empty room detection**: If the total variance across all subcarriers is
|
||||
below a noise floor threshold, report 0 persons regardless of graph structure.
|
||||
|
||||
### Stoer-Wagner Algorithm
|
||||
|
||||
Stoer-Wagner finds the exact global minimum cut of an undirected weighted graph
|
||||
in O(V * E) time using a sequence of "minimum cut phases":
|
||||
|
||||
```
|
||||
function stoerWagner(G):
|
||||
best_cut = infinity
|
||||
while |V(G)| > 1:
|
||||
(s, t, cut_of_phase) = minimumCutPhase(G)
|
||||
if cut_of_phase < best_cut:
|
||||
best_cut = cut_of_phase
|
||||
best_partition = partition induced by t
|
||||
merge(s, t) // contract vertices s and t
|
||||
return best_cut, best_partition
|
||||
|
||||
function minimumCutPhase(G):
|
||||
A = {arbitrary start vertex}
|
||||
while A != V(G):
|
||||
z = vertex most tightly connected to A
|
||||
// "most tightly connected" = max sum of edge weights to A
|
||||
add z to A
|
||||
s = second-to-last vertex added
|
||||
t = last vertex added (most tightly connected)
|
||||
cut_of_phase = sum of weights of edges incident to t
|
||||
return (s, t, cut_of_phase)
|
||||
```
|
||||
|
||||
For V=64 subcarriers and E~2000 edges, this runs in ~8 million operations,
|
||||
well under 1ms on modern hardware and under 10ms even on ESP32-S3.
|
||||
|
||||
### Integration Points
|
||||
|
||||
```
|
||||
ESP32 Node 1 ──UDP 5006──┐
|
||||
├──> mincut-person-counter.js ──> corrected n_persons
|
||||
ESP32 Node 2 ──UDP 5006──┘ │
|
||||
├──> seed_csi_bridge.py (feature dim 5 override)
|
||||
└──> csi-graph-visualizer.js (debug view)
|
||||
```
|
||||
|
||||
The person counter runs as a standalone Node.js process alongside the existing
|
||||
`rf-scan.js` and `seed_csi_bridge.py` bridge scripts. It can also replay
|
||||
recorded `.csi.jsonl` files for offline analysis.
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
### 1. Threshold-based peak counting (current, broken)
|
||||
|
||||
Count subcarriers with variance above a threshold, then cluster by proximity.
|
||||
**Problem:** threshold is environment-dependent, miscalibrates easily, and
|
||||
cannot distinguish correlated from independent motion.
|
||||
|
||||
### 2. PCA / spectral clustering on correlation matrix
|
||||
|
||||
Compute eigenvectors of the correlation matrix; the number of large eigenvalues
|
||||
indicates the number of independent sources. **Problem:** requires choosing an
|
||||
eigenvalue gap threshold, which is as fragile as the current variance threshold.
|
||||
Also does not give per-person subcarrier assignments.
|
||||
|
||||
### 3. Min-cut on correlation graph (this ADR)
|
||||
|
||||
**Advantages:**
|
||||
- Directly models the physical structure (Fresnel zone groupings)
|
||||
- Threshold-free person counting (cut weight is a natural separation metric)
|
||||
- Produces per-person subcarrier groups as a side effect
|
||||
- Stoer-Wagner is simple to implement (~100 lines) and runs in polynomial time
|
||||
- Already validated in Rust via `ruvector-mincut` integration
|
||||
|
||||
## Performance
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Graph size | V=64, E~2000 |
|
||||
| Stoer-Wagner complexity | O(V * E) = O(128,000) per cut |
|
||||
| Iterative cuts (max 4) | O(512,000) total |
|
||||
| Wall time (Node.js) | < 5 ms per 2-second window |
|
||||
| Wall time (Rust/WASM) | < 0.5 ms |
|
||||
| Memory | ~32 KB for correlation matrix + graph |
|
||||
| Sliding window | 2 seconds = ~40 frames * 64 subcarriers * 8 bytes = 20 KB |
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- Fixes #348: person count now reflects actual independent movers
|
||||
- Robust across environments (no per-room threshold calibration)
|
||||
- Per-person subcarrier groups enable per-person feature extraction
|
||||
- Graph visualization aids debugging and room mapping
|
||||
- Algorithm is well-understood (Stoer-Wagner, 1997)
|
||||
|
||||
### Negative
|
||||
|
||||
- Adds a new process to the sensing pipeline
|
||||
- 2-second latency for person count changes (sliding window)
|
||||
- Correlation-based: cannot detect stationary persons (no motion = no signal)
|
||||
- Assumes independent motion — two people walking in sync may be counted as one
|
||||
|
||||
### Migration
|
||||
|
||||
1. Deploy `scripts/mincut-person-counter.js` alongside existing bridge
|
||||
2. Override feature vector dimension 5 (`n_persons`) with corrected count
|
||||
3. Once validated, port Stoer-Wagner to C for direct ESP32-S3 firmware integration
|
||||
4. Deprecate the fixed-threshold `PersonMatcher` in `sig_mincut_person_match.rs`
|
||||
|
||||
## References
|
||||
|
||||
- Stoer, M. & Wagner, F. (1997). "A Simple Min-Cut Algorithm." JACM 44(4).
|
||||
- `vendor/ruvector/crates/ruvector-mincut/src/algorithm/mod.rs` — DynamicMinCut API
|
||||
- `rust-port/.../sig_mincut_person_match.rs` — current (broken) WASM edge matcher
|
||||
- `scripts/rf-scan.js` — CSI packet parsing and subcarrier classification
|
||||
@@ -1,259 +0,0 @@
|
||||
# ADR-076: CSI Spectrogram Embeddings via CNN + Graph Transformer
|
||||
|
||||
| Field | Value |
|
||||
|-------------|--------------------------------------------|
|
||||
| **Status** | Proposed |
|
||||
| **Date** | 2026-04-02 |
|
||||
| **Authors** | ruv |
|
||||
| **Depends** | ADR-018 (binary frame), ADR-024 (AETHER contrastive embeddings), ADR-029 (RuvSense), ADR-069 (Cognitum Seed bridge), ADR-073 (multi-frequency mesh scan) |
|
||||
|
||||
## Context
|
||||
|
||||
The current CSI processing pipeline extracts an 8-dimensional hand-crafted feature vector per frame: mean amplitude, amplitude variance, max amplitude, mean phase, phase variance, bandwidth, spectral centroid, and RSSI. These features are effective for basic presence detection and room fingerprinting but discard the rich spatial-frequency structure present in the raw subcarrier data.
|
||||
|
||||
A single CSI frame from an ESP32-S3 contains 64 subcarriers (or 128 in HT40 mode), each with I/Q components. When stacked over time, 20 consecutive frames form a **64x20 subcarrier-by-time matrix** — effectively a grayscale spectrogram image. This matrix encodes:
|
||||
|
||||
1. **Frequency-selective fading** — metal objects create persistent null zones at specific subcarrier indices (visible as dark vertical stripes)
|
||||
2. **Doppler signatures** — human motion produces time-varying amplitude patterns across subcarriers (visible as horizontal wave patterns)
|
||||
3. **Multipath structure** — room geometry creates characteristic interference patterns unique to each environment
|
||||
4. **Activity fingerprints** — walking, sitting, breathing, and falling produce distinct 2D texture patterns in the subcarrier-time matrix
|
||||
|
||||
These 2D structural patterns are invisible to the 8-dim feature vector, which collapses all subcarrier information into scalar statistics. A CNN embedding can preserve this spatial structure.
|
||||
|
||||
### Existing Vendor Libraries
|
||||
|
||||
**@ruvector/cnn** (v0.1.0) provides:
|
||||
- WASM-based CNN feature extraction (~5ms per 224x224 image, ~900KB model)
|
||||
- Configurable embedding dimension (default 512, we use 128 for compact storage)
|
||||
- L2-normalized embeddings with cosine similarity search
|
||||
- Contrastive training via InfoNCE and triplet loss
|
||||
- SIMD-optimized layer operations (batch norm, global average pooling, ReLU)
|
||||
- Works in both Node.js and browser environments
|
||||
|
||||
**ruvector-graph-transformer** provides:
|
||||
- Sublinear O(n log n) graph attention via LSH bucketing and PPR sampling
|
||||
- Proof-gated mutation substrate for verified computations
|
||||
- Temporal causal attention with Granger causality (relevant for CSI time series)
|
||||
- Manifold attention on product spaces S^n x H^m x R^k
|
||||
|
||||
**@ruvector/graph-wasm** (v2.0.2) provides:
|
||||
- Neo4j-compatible property graph database in WASM
|
||||
- Node/edge creation with arbitrary properties and embeddings
|
||||
- Hyperedge support for multi-node relationships
|
||||
- Cypher query language
|
||||
|
||||
### Current Limitations of 8-dim Features
|
||||
|
||||
| Limitation | Impact |
|
||||
|------------|--------|
|
||||
| No subcarrier-level information | Cannot distinguish frequency-selective vs broadband fading |
|
||||
| No temporal pattern encoding | Walking gait (periodic) looks identical to random motion (aperiodic) |
|
||||
| No 2D structure | Room fingerprint reduced to 8 numbers; two rooms with similar statistics are indistinguishable |
|
||||
| No cross-subcarrier correlation | Cannot detect standing waves, node patterns, or multipath clusters |
|
||||
| Poor kNN discrimination | 8 dimensions provides limited hypersphere surface area for separating environments |
|
||||
|
||||
## Decision
|
||||
|
||||
Treat the CSI subcarrier-by-time matrix as a grayscale spectrogram image and apply CNN embedding to produce a 128-dimensional representation that preserves 2D spatial-frequency structure. Use a graph transformer to fuse embeddings across multiple ESP32 nodes.
|
||||
|
||||
### Architecture
|
||||
|
||||
```
|
||||
ESP32 Node 1 ESP32 Node 2
|
||||
| |
|
||||
v v
|
||||
UDP 5006 UDP 5006
|
||||
| |
|
||||
v v
|
||||
[64 subcarriers] [64 subcarriers]
|
||||
[20-frame window] [20-frame window]
|
||||
| |
|
||||
v v
|
||||
64x20 amplitude 64x20 amplitude
|
||||
matrix (grayscale) matrix (grayscale)
|
||||
| |
|
||||
v v
|
||||
@ruvector/cnn @ruvector/cnn
|
||||
CnnEmbedder CnnEmbedder
|
||||
| |
|
||||
v v
|
||||
128-dim vector 128-dim vector
|
||||
| |
|
||||
+-------+ +----------+
|
||||
| |
|
||||
v v
|
||||
Graph Transformer (2-node graph)
|
||||
Edge weight = cross-node correlation
|
||||
|
|
||||
v
|
||||
Fused 128-dim vector
|
||||
|
|
||||
+-------+-------+
|
||||
| |
|
||||
v v
|
||||
Cognitum Seed kNN Search
|
||||
(128-dim store) (similar rooms)
|
||||
```
|
||||
|
||||
### Step 1: CSI-to-Spectrogram Conversion
|
||||
|
||||
Each ESP32 transmits CSI frames via UDP in ADR-018 binary format. The `iq_hex` field contains I/Q pairs for each subcarrier (2 bytes per subcarrier: I + Q as unsigned 8-bit values).
|
||||
|
||||
```
|
||||
Amplitude[sc] = sqrt(I[sc]^2 + Q[sc]^2)
|
||||
```
|
||||
|
||||
A sliding window of 20 frames produces a 64x20 matrix. Normalization to 0-255 grayscale:
|
||||
|
||||
```
|
||||
pixel[sc][t] = clamp(255 * (amplitude[sc][t] - min) / (max - min), 0, 255)
|
||||
```
|
||||
|
||||
Where `min` and `max` are computed over the entire 64x20 window for per-window contrast normalization. This ensures the CNN sees the relative structure regardless of absolute signal strength (which varies with distance, TX power, and environmental absorption).
|
||||
|
||||
### Step 2: CNN Embedding
|
||||
|
||||
The 64x20 grayscale matrix is resized to the CNN's expected input size (224x224 via nearest-neighbor upsampling, since we want to preserve the discrete subcarrier structure rather than blur it with bilinear interpolation). The input is replicated across 3 channels (RGB) since @ruvector/cnn expects RGB input.
|
||||
|
||||
Configuration:
|
||||
- **Input**: 224x224x3 (upsampled from 64x20, grayscale replicated to RGB)
|
||||
- **Embedding dimension**: 128 (reduced from default 512 for compact storage and faster kNN)
|
||||
- **Normalization**: L2-enabled (cosine similarity = dot product on unit sphere)
|
||||
- **Latency**: ~5ms per window on modern hardware
|
||||
|
||||
The 128-dim embedding encodes the 2D structure of the spectrogram: null zones, Doppler patterns, multipath signatures, and activity textures.
|
||||
|
||||
### Step 3: Graph Transformer for Multi-Node Fusion
|
||||
|
||||
With 2 ESP32 nodes (generalizable to N), we construct a graph:
|
||||
|
||||
```
|
||||
Nodes: {Node_1, Node_2}
|
||||
Edges: {(Node_1, Node_2, weight=cross_correlation)}
|
||||
Node features: 128-dim CNN embedding per node
|
||||
```
|
||||
|
||||
The graph attention mechanism learns which node is more informative for each prediction:
|
||||
|
||||
1. **Query/Key/Value** from each node's 128-dim embedding
|
||||
2. **Edge weight** = Pearson cross-correlation between the two nodes' raw amplitude vectors (captures how much their CSI observations agree)
|
||||
3. **Attention score** = softmax(Q_i * K_j / sqrt(d) + edge_weight_bias)
|
||||
4. **Output** = weighted sum of value vectors
|
||||
|
||||
This produces a fused 128-dim vector that combines both nodes' perspectives, automatically weighting the node with cleaner signal (higher SNR, less fading) more heavily.
|
||||
|
||||
**Generalization to 3+ nodes**: Adding a third ESP32 adds one node and 2 edges to the graph. The attention mechanism handles variable-size graphs without architecture changes.
|
||||
|
||||
### Step 4: Storage and Search
|
||||
|
||||
The fused 128-dim embedding is stored in Cognitum Seed (ADR-069) alongside the existing 8-dim features:
|
||||
|
||||
| Store | Dimension | Content | Use Case |
|
||||
|-------|-----------|---------|----------|
|
||||
| `csi-features` | 8-dim | Hand-crafted statistics | Fast presence detection |
|
||||
| `csi-spectrograms` | 128-dim | CNN spectrogram embedding | Environment fingerprinting, anomaly detection |
|
||||
| `csi-spectrograms-fused` | 128-dim | Graph-fused multi-node embedding | Cross-viewpoint room signature |
|
||||
|
||||
kNN search on the 128-dim store finds past spectrograms that "look like" the current one:
|
||||
- **Environment fingerprinting**: "What room does this RF pattern match?"
|
||||
- **Cross-room transfer**: "Which training room is most similar to this deployment room?"
|
||||
- **Anomaly detection**: Low similarity to all known patterns = unknown environment or novel activity
|
||||
- **Temporal segmentation**: Similarity drops = activity transition boundaries
|
||||
|
||||
### Comparison: 8-dim vs 128-dim vs Combined
|
||||
|
||||
| Property | 8-dim hand-crafted | 128-dim CNN | Combined |
|
||||
|----------|-------------------|-------------|----------|
|
||||
| Subcarrier structure | Lost | Preserved | Both available |
|
||||
| Temporal patterns | Lost | Preserved (20-frame window) | Both |
|
||||
| Computation | ~0.1ms | ~5ms | ~5ms |
|
||||
| Storage per vector | 32 bytes | 512 bytes | 544 bytes |
|
||||
| kNN discrimination | Low (8-dim curse) | High (128-dim surface) | Highest |
|
||||
| Interpretability | High (named features) | Low (learned) | Mixed |
|
||||
| Training required | No | Optional (pre-trained works) | Optional |
|
||||
| Multi-node fusion | Average/max | Graph attention | Graph attention |
|
||||
|
||||
### Contrastive Training (Optional Enhancement)
|
||||
|
||||
The CNN embedding works out-of-the-box with the pre-trained weights. For domain-specific improvements, contrastive training with CSI data:
|
||||
|
||||
1. **Positive pairs**: Same room, different time windows (should embed similarly)
|
||||
2. **Negative pairs**: Different rooms or different activities (should embed differently)
|
||||
3. **Loss**: InfoNCE with temperature 0.07 (standard SimCLR)
|
||||
4. **Augmentation**: Time-shift (slide window by 1-5 frames), subcarrier dropout (zero 10% of rows), amplitude jitter (multiply by uniform [0.8, 1.2])
|
||||
|
||||
This teaches the CNN that "same room at different times" should produce similar embeddings, while "different rooms" should produce different embeddings.
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
1. **Richer representation**: 128 dimensions capture 2D structure that 8 dimensions cannot
|
||||
2. **Environment fingerprinting**: kNN on spectrograms can distinguish rooms that look identical in 8-dim feature space
|
||||
3. **Activity detection**: Temporal patterns (gait periodicity, breathing frequency) are encoded in the spectrogram texture
|
||||
4. **Multi-node fusion**: Graph attention automatically weights the most informative node, improving robustness to single-node occlusion or interference
|
||||
5. **Incremental adoption**: 128-dim store operates alongside 8-dim store; no migration needed
|
||||
6. **Browser-compatible**: WASM-based CNN runs in the sensing-server UI for live visualization
|
||||
|
||||
### Negative
|
||||
|
||||
1. **5ms latency per window**: Acceptable for 1.3 Hz update rate (750ms rotation from ADR-073), but constrains real-time applications
|
||||
2. **900KB model download**: One-time cost, cached after first load
|
||||
3. **128-dim storage**: 16x more bytes per vector than 8-dim; mitigated by the fact that we store one embedding per 20-frame window (not per frame)
|
||||
4. **Opaque embeddings**: Unlike named 8-dim features, CNN embeddings are not human-interpretable
|
||||
5. **Input size mismatch**: 64x20 matrix must be upsampled to 224x224; nearest-neighbor preserves structure but wastes computation on padded regions
|
||||
|
||||
### Risks and Mitigations
|
||||
|
||||
| Risk | Mitigation |
|
||||
|------|------------|
|
||||
| CNN embeddings not discriminative enough for CSI | Contrastive fine-tuning on CSI spectrograms; fall back to 8-dim if 128-dim kNN recall is worse |
|
||||
| Graph transformer overhead for 2-node graph | Lightweight attention (single head, no MLP); O(1) for 2 nodes |
|
||||
| Upsampling artifacts from 64x20 to 224x224 | Nearest-neighbor preserves discrete structure; consider training a smaller CNN on native 64x20 input |
|
||||
| WASM initialization delay | Call `init()` at server startup, not per-request |
|
||||
|
||||
## Implementation
|
||||
|
||||
### Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `scripts/csi-spectrogram.js` | CSI-to-spectrogram pipeline with CNN embedding, ASCII visualization, Cognitum Seed ingest |
|
||||
| `scripts/mesh-graph-transformer.js` | Multi-node graph attention fusion using @ruvector/graph-wasm |
|
||||
| `docs/adr/ADR-076-csi-spectrogram-embeddings.md` | This ADR |
|
||||
|
||||
### Dependencies
|
||||
|
||||
| Package | Version | Source |
|
||||
|---------|---------|--------|
|
||||
| `@ruvector/cnn` | 0.1.0 | `vendor/ruvector/npm/packages/ruvector-cnn/` |
|
||||
| `@ruvector/graph-wasm` | 2.0.2 | `vendor/ruvector/npm/packages/graph-wasm/` |
|
||||
|
||||
### Data Format
|
||||
|
||||
CSI JSONL frames from `data/recordings/pretrain-1775182186.csi.jsonl`:
|
||||
|
||||
```json
|
||||
{
|
||||
"timestamp": 1775182186.123,
|
||||
"node_id": 1,
|
||||
"magic": 3289481217,
|
||||
"size": 148,
|
||||
"rssi": -45,
|
||||
"type": "CSI",
|
||||
"iq_hex": "00000f030d030e040d030d030d030c020d020d01...",
|
||||
"subcarriers": 64
|
||||
}
|
||||
```
|
||||
|
||||
`iq_hex` encoding: 2 hex characters per byte, 4 hex characters per subcarrier (I byte + Q byte). Total length = `subcarriers * 4` hex characters.
|
||||
|
||||
## References
|
||||
|
||||
- ADR-018: Binary CSI frame format
|
||||
- ADR-024: AETHER contrastive CSI embeddings (Rust-side)
|
||||
- ADR-029: RuvSense multistatic sensing mode
|
||||
- ADR-069: Cognitum Seed RVF ingest bridge
|
||||
- ADR-073: Multi-frequency mesh scanning
|
||||
- SimCLR: Chen et al., "A Simple Framework for Contrastive Learning of Visual Representations" (2020)
|
||||
- GATv2: Brody et al., "How Attentive are Graph Attention Networks?" (2021)
|
||||
@@ -1,284 +0,0 @@
|
||||
# ADR-077: Novel RF Sensing Applications
|
||||
|
||||
**Status:** Accepted
|
||||
**Date:** 2026-04-02
|
||||
**Authors:** ruv
|
||||
**Depends on:** ADR-018 (CSI binary protocol), ADR-073 (multifrequency mesh scan), ADR-075 (MinCut person separation), ADR-076 (CSI spectrogram embeddings)
|
||||
|
||||
## Context
|
||||
|
||||
The existing ESP32 CSI + Cognitum Seed infrastructure collects rich multi-modal data:
|
||||
- 2 ESP32-S3 nodes streaming CSI at ~22 fps each (64-128 subcarriers, channel hopping ch 1/3/5/6/9/11)
|
||||
- Vitals extraction: breathing rate, heart rate, motion energy, presence score (1 Hz per node)
|
||||
- 8-dimensional feature vectors per frame
|
||||
- Cognitum Seed with BME280 (temp/humidity/pressure), PIR, reed switch, vibration sensor
|
||||
|
||||
No new hardware is required. All 6 applications below derive novel insights from data already being collected via the ADR-018 binary protocol over UDP port 5006.
|
||||
|
||||
## Decision
|
||||
|
||||
Implement 6 novel RF sensing applications as standalone Node.js scripts that process live UDP or replayed `.csi.jsonl` recordings.
|
||||
|
||||
---
|
||||
|
||||
## Application 1: Sleep Quality Monitoring
|
||||
|
||||
### Input
|
||||
Breathing rate (BR) and heart rate (HR) time series from vitals packets (0xC5110002), sampled at ~1 Hz per node over 6-8 hours.
|
||||
|
||||
### Algorithm
|
||||
Sliding window analysis (5-minute windows, 1-minute stride) classifying sleep stages:
|
||||
|
||||
| Stage | BR (BPM) | BR Variance | HR Pattern | Motion |
|
||||
|-------|----------|-------------|------------|--------|
|
||||
| **Deep (N3)** | 6-12 | Very low (<2.0) | Slow, regular | None |
|
||||
| **Light (N1/N2)** | 12-18 | Moderate (2.0-8.0) | Normal | Minimal |
|
||||
| **REM** | 15-25 | High (>8.0), irregular | Elevated | Eyes only (low CSI motion) |
|
||||
| **Awake** | >18 or <6 | Any | Variable | Moderate-high |
|
||||
|
||||
Each 5-minute window is scored by:
|
||||
1. Compute BR mean and variance within the window
|
||||
2. Compute HR mean and coefficient of variation (CV)
|
||||
3. Compute motion energy mean (from vitals `motion_energy` field)
|
||||
4. Classify stage using threshold hierarchy: Awake > REM > Light > Deep
|
||||
|
||||
### Output
|
||||
- Real-time sleep stage classification
|
||||
- ASCII hypnogram (time vs. stage)
|
||||
- Summary: total sleep time, sleep efficiency (TST / time in bed), time per stage
|
||||
- Optional JSON for health app integration
|
||||
|
||||
### Validation
|
||||
Overnight recording (`overnight-1775217646.csi.jsonl`, 113k frames, ~40 min) should show:
|
||||
- Transition from active (awake) to resting states
|
||||
- Decreased motion energy over time
|
||||
- BR stabilization in sleeping segments
|
||||
|
||||
### Clinical Relevance
|
||||
Consumer-grade sleep tracking without wearables. RF-based sensing avoids compliance issues (forgotten wristbands, dead batteries). Not diagnostic; informational only.
|
||||
|
||||
---
|
||||
|
||||
## Application 2: Breathing Disorder Screening (Apnea Detection)
|
||||
|
||||
### Input
|
||||
Breathing rate time series from vitals packets at ~1 Hz.
|
||||
|
||||
### Algorithm
|
||||
Detect respiratory events in the BR time series:
|
||||
|
||||
| Event | Definition | Duration |
|
||||
|-------|-----------|----------|
|
||||
| **Apnea** | BR drops below 3 BPM (effective cessation) | >= 10 seconds |
|
||||
| **Hypopnea** | BR drops > 50% from 5-min rolling baseline | >= 10 seconds |
|
||||
|
||||
Scoring:
|
||||
1. Maintain 5-minute rolling baseline BR (exponential moving average)
|
||||
2. Flag apnea when BR < 3 BPM for >= 10 consecutive seconds
|
||||
3. Flag hypopnea when BR < 50% of baseline for >= 10 consecutive seconds
|
||||
4. Compute AHI (Apnea-Hypopnea Index) = total events / hours monitored
|
||||
|
||||
| AHI | Severity |
|
||||
|-----|----------|
|
||||
| < 5 | Normal |
|
||||
| 5-15 | Mild |
|
||||
| 15-30 | Moderate |
|
||||
| > 30 | Severe |
|
||||
|
||||
### Output
|
||||
- Per-event log: type (apnea/hypopnea), start time, duration, BR during event
|
||||
- Hourly AHI and overall AHI
|
||||
- Severity classification
|
||||
- Alert on severe events (consecutive apneas > 30s)
|
||||
|
||||
### Clinical Relevance
|
||||
Pre-screening tool for obstructive sleep apnea (OSA). Provides motivation for clinical polysomnography referral. Not a diagnostic device; informational pre-screen only.
|
||||
|
||||
---
|
||||
|
||||
## Application 3: Emotional State / Stress Detection
|
||||
|
||||
### Input
|
||||
Heart rate time series from vitals packets at ~1 Hz.
|
||||
|
||||
### Algorithm
|
||||
Heart Rate Variability (HRV) analysis:
|
||||
|
||||
1. **RMSSD** (Root Mean Square of Successive Differences):
|
||||
- Compute successive HR differences within 5-minute windows
|
||||
- RMSSD = sqrt(mean(diff^2))
|
||||
- High RMSSD = high vagal tone = relaxed
|
||||
- Low RMSSD = sympathetic dominance = stressed
|
||||
|
||||
2. **LF/HF Ratio** (via FFT on 5-minute HR windows):
|
||||
- LF band: 0.04-0.15 Hz (sympathetic + parasympathetic)
|
||||
- HF band: 0.15-0.40 Hz (parasympathetic)
|
||||
- High LF/HF (> 2.0) = stressed
|
||||
- Low LF/HF (< 1.0) = relaxed
|
||||
|
||||
3. **Stress Score** (0-100):
|
||||
- `score = 50 * (1 - RMSSD_norm) + 50 * LF_HF_norm`
|
||||
- Where `RMSSD_norm` = RMSSD / max_expected_RMSSD (capped at 1.0)
|
||||
- And `LF_HF_norm` = min(LF_HF / 4.0, 1.0)
|
||||
|
||||
### Output
|
||||
- Real-time stress score (0-100)
|
||||
- RMSSD and LF/HF ratio per window
|
||||
- ASCII trend chart over hours
|
||||
- Activity context correlation (motion level vs. stress)
|
||||
|
||||
### Validation
|
||||
- Periods of activity (walking, working) should correlate with higher stress scores
|
||||
- Quiet rest should show lower scores
|
||||
- Sleeping should show lowest scores (high HRV, low LF/HF)
|
||||
|
||||
---
|
||||
|
||||
## Application 4: Gait Analysis / Movement Disorder Detection
|
||||
|
||||
### Input
|
||||
- Motion energy time series from vitals packets
|
||||
- CSI phase variance from raw CSI frames (0xC5110001)
|
||||
- Cross-node RSSI from vitals packets
|
||||
|
||||
### Algorithm
|
||||
|
||||
1. **Cadence Extraction**: FFT on motion_energy within 5-second sliding windows
|
||||
- Walking cadence: dominant frequency 0.8-2.0 Hz (normal: ~1.0 Hz = 120 steps/min)
|
||||
- Running: > 2.0 Hz
|
||||
- Stationary: no dominant peak
|
||||
|
||||
2. **Stride Regularity**: Autocorrelation of motion_energy
|
||||
- Regular walking: strong autocorrelation peak at step period
|
||||
- Irregularity score = 1 - (peak_height / baseline)
|
||||
|
||||
3. **Asymmetry Detection**: Compare motion energy oscillation between two ESP32 nodes
|
||||
- Symmetric gait: both nodes see similar oscillation period and amplitude
|
||||
- Asymmetry index = |period_node1 - period_node2| / mean_period
|
||||
|
||||
4. **Tremor Detection**: High-frequency phase variance analysis
|
||||
- Compute phase variance per subcarrier in 2-second windows
|
||||
- Tremor band: 3-8 Hz component in phase variance time series
|
||||
- Parkinsonian tremor: 4-6 Hz, resting
|
||||
- Essential tremor: 5-8 Hz, action
|
||||
|
||||
### Output
|
||||
- Cadence (steps/min)
|
||||
- Stride regularity score (0-1)
|
||||
- Asymmetry index (0 = symmetric, 1 = highly asymmetric)
|
||||
- Tremor score and dominant frequency
|
||||
- Walking vs. stationary classification
|
||||
|
||||
### Validation
|
||||
Overnight data should show clear stationary periods with no cadence detected. Any walking segments should show cadence in the 0.8-2.0 Hz range.
|
||||
|
||||
---
|
||||
|
||||
## Application 5: Material/Object Change Detection
|
||||
|
||||
### Input
|
||||
Per-subcarrier amplitude from raw CSI frames (0xC5110001).
|
||||
|
||||
### Algorithm
|
||||
|
||||
1. **Baseline Establishment** (first 10 minutes or configurable):
|
||||
- Record mean amplitude per subcarrier (Welford online mean)
|
||||
- Record null pattern: which subcarriers are below null threshold (amplitude < 2.0)
|
||||
|
||||
2. **Change Detection** (sliding 30-second windows):
|
||||
- Compare current null pattern to baseline
|
||||
- New nulls appearing = new metal object blocking RF path
|
||||
- Existing nulls disappearing = metal object removed
|
||||
- Null position shifted = object moved
|
||||
- Amplitude change without null change = non-metal material (wood, water, glass)
|
||||
|
||||
3. **Material Classification** heuristic:
|
||||
- Metal: sharp null (amplitude drops to near 0 on specific subcarriers)
|
||||
- Water/human: broad amplitude reduction across many subcarriers
|
||||
- Wood/plastic: minimal amplitude change, mostly phase shift
|
||||
- Glass: frequency-selective (affects higher subcarriers more)
|
||||
|
||||
### Output
|
||||
- Change events with timestamp, type (add/remove/move), affected subcarrier range
|
||||
- Estimated material category
|
||||
- Null pattern delta visualization (ASCII)
|
||||
- Event timeline for monitoring
|
||||
|
||||
### Validation
|
||||
Overnight data has 19% null baseline. Changes in null pattern over the recording period indicate environment changes (doors opening/closing, person entering/leaving).
|
||||
|
||||
---
|
||||
|
||||
## Application 6: Room Environment Fingerprinting
|
||||
|
||||
### Input
|
||||
- 8-dimensional feature vectors from feature packets (0xC5110003)
|
||||
- Motion energy and presence score from vitals packets
|
||||
|
||||
### Algorithm
|
||||
|
||||
1. **Online Clustering** using running k-means (k=5, updateable centroids):
|
||||
- Each incoming 8-dim feature vector is assigned to nearest centroid
|
||||
- Centroid updated via exponential moving average (alpha=0.01)
|
||||
- New cluster created if distance to all centroids exceeds threshold
|
||||
|
||||
2. **State Labeling** (heuristic from vitals correlation):
|
||||
- Cluster with lowest motion_energy = "empty/sleeping"
|
||||
- Cluster with highest motion_energy = "active/walking"
|
||||
- Intermediate clusters = "resting", "working", "transitional"
|
||||
|
||||
3. **Transition Tracking**:
|
||||
- Build state transition matrix (from_state -> to_state counts)
|
||||
- Detect anomalous transitions (rare in historical data)
|
||||
|
||||
4. **Daily Profile**:
|
||||
- Aggregate state durations per hour
|
||||
- Compare across days for routine detection
|
||||
|
||||
### Output
|
||||
- Current room state and confidence
|
||||
- State timeline (ASCII)
|
||||
- Transition matrix
|
||||
- Daily pattern profile
|
||||
- Anomaly score (deviation from established daily pattern)
|
||||
|
||||
### Validation
|
||||
Overnight recording should show 2-3 stable clusters corresponding to activity periods at different times. Transitions should be infrequent and correspond to real behavioral changes.
|
||||
|
||||
---
|
||||
|
||||
## Implementation
|
||||
|
||||
All scripts share common infrastructure:
|
||||
- ADR-018 binary packet parsing (same as rf-scan.js, mincut-person-counter.js)
|
||||
- JSONL replay via readline interface
|
||||
- Live UDP via dgram
|
||||
- Pure Node.js, no external dependencies
|
||||
- CLI: `--replay <file>` for offline, `--port <N>` for live, `--json` for programmatic output
|
||||
|
||||
| Script | Primary Packets | Key Algorithm |
|
||||
|--------|----------------|---------------|
|
||||
| `sleep-monitor.js` | vitals (0xC5110002) | BR/HR window classification |
|
||||
| `apnea-detector.js` | vitals (0xC5110002) | BR pause detection, AHI scoring |
|
||||
| `stress-monitor.js` | vitals (0xC5110002) | HRV RMSSD + FFT LF/HF |
|
||||
| `gait-analyzer.js` | vitals + raw CSI | FFT cadence + phase tremor |
|
||||
| `material-detector.js` | raw CSI (0xC5110001) | Null pattern baseline + delta |
|
||||
| `room-fingerprint.js` | feature (0xC5110003) + vitals | Online k-means clustering |
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
- 6 new sensing applications from existing hardware (zero additional cost)
|
||||
- All offline-capable via JSONL replay (no live hardware needed for development)
|
||||
- Pure JS, no native dependencies, runs on any platform with Node.js
|
||||
- Each script is standalone and composable
|
||||
|
||||
### Negative
|
||||
- Vitals accuracy depends on ESP32 CSI quality (RSSI, multipath)
|
||||
- HRV analysis at 1 Hz HR sampling is coarse compared to ECG
|
||||
- Material classification is heuristic, not definitive
|
||||
- Sleep staging without EEG is approximate (consumer-grade accuracy)
|
||||
|
||||
### Risks
|
||||
- Users may misinterpret health-related outputs as clinical diagnoses
|
||||
- Mitigation: all scripts include disclaimers in output headers
|
||||
@@ -1,354 +0,0 @@
|
||||
# ADR-078: Multi-Frequency Mesh Sensing Applications
|
||||
|
||||
| Field | Value |
|
||||
|-------------|--------------------------------------------|
|
||||
| **Status** | Proposed |
|
||||
| **Date** | 2026-04-02 |
|
||||
| **Authors** | ruv |
|
||||
| **Depends** | ADR-018 (binary frame), ADR-029 (channel hopping), ADR-073 (multi-frequency mesh scan) |
|
||||
|
||||
## Context
|
||||
|
||||
ADR-073 established multi-frequency mesh scanning: 2 ESP32-S3 nodes hopping across 6 WiFi channels (1, 3, 5, 6, 9, 11) with 9 neighbor WiFi networks as passive illuminators. This ADR defines 5 sensing applications that are **unique to multi-frequency mesh scanning** and impossible with single-channel WiFi sensing.
|
||||
|
||||
### Why Multi-Frequency is Required
|
||||
|
||||
Single-channel WiFi sensing captures CSI on one frequency (e.g., channel 5 at 2432 MHz). This provides amplitude and phase across ~52-64 OFDM subcarriers within a 20 MHz bandwidth. Multi-frequency mesh scanning extends this to 6 channels spanning 2412-2462 MHz (50 MHz total), with each channel providing independent multipath observations. The applications below exploit the frequency dimension that single-channel sensing cannot access.
|
||||
|
||||
### Available Infrastructure
|
||||
|
||||
| Resource | Detail |
|
||||
|----------|--------|
|
||||
| Node 1 (COM7) | ESP32-S3, channels 1, 6, 11 (non-overlapping), 200ms dwell |
|
||||
| Node 2 | ESP32-S3, channels 3, 5, 9 (interleaved, near neighbor APs), 200ms dwell |
|
||||
| Neighbor APs | 9 networks across channels 3, 5, 6, 9, 11 |
|
||||
| Data transport | UDP port 5006, ADR-018 binary format |
|
||||
| Recorded data | `data/recordings/overnight-*.csi.jsonl` |
|
||||
|
||||
### Neighbor AP Illuminator Table
|
||||
|
||||
| SSID | Channel | Freq (MHz) | Signal (%) | Role |
|
||||
|------|---------|------------|------------|------|
|
||||
| ruv.net | 5 | 2432 | 100 | Primary illuminator |
|
||||
| Cohen-Guest | 5 | 2432 | 100 | Co-channel illuminator |
|
||||
| COGECO-21B20 | 11 | 2462 | 100 | High-freq illuminator |
|
||||
| HP M255 LaserJet | 5 | 2432 | 94 | Device fingerprinting target |
|
||||
| conclusion mesh | 3 | 2422 | 44 | Low-freq illuminator |
|
||||
| NETGEAR72 | 9 | 2452 | 42 | Mid-high illuminator |
|
||||
| NETGEAR72-Guest | 9 | 2452 | 42 | Co-channel illuminator |
|
||||
| COGECO-4321 | 11 | 2462 | 30 | Weak high-freq illuminator |
|
||||
| Innanen | 6 | 2437 | 19 | Weak center-band illuminator |
|
||||
|
||||
## Decision
|
||||
|
||||
Implement 5 multi-frequency-specific sensing applications, each as a standalone Node.js script in `scripts/`.
|
||||
|
||||
---
|
||||
|
||||
## Application 1: RF Tomographic Imaging
|
||||
|
||||
### Principle
|
||||
|
||||
Each WiFi channel "sees" through the room differently because multipath interference patterns are frequency-dependent. A 2 cm path length difference produces a null at 2432 MHz but constructive interference at 2412 MHz. With 6 channels x 2 nodes, we have 12 independent RF path observations through the room.
|
||||
|
||||
RF tomography back-projects attenuation along each transmitter-receiver path. Where paths overlap with high attenuation, there is an absorbing object (person, furniture, wall). Where paths show low attenuation, the space is clear.
|
||||
|
||||
### Algorithm
|
||||
|
||||
```
|
||||
For each CSI frame:
|
||||
1. Compute path attenuation = RSSI_free_space - RSSI_measured
|
||||
2. For each cell in a 10x10 room grid:
|
||||
a. Compute the cell's distance to the TX->RX line (perpendicular distance)
|
||||
b. Weight contribution by 1/distance (cells near the path contribute more)
|
||||
3. Accumulate weighted attenuation across all frames, channels, and node pairs
|
||||
4. Normalize: cells with high accumulated attenuation = absorbers (people/objects)
|
||||
```
|
||||
|
||||
Uses the Algebraic Reconstruction Technique (ART) for iterative refinement, or simple backprojection for real-time display.
|
||||
|
||||
### Resolution
|
||||
|
||||
- Theoretical: ~lambda/2 = 6 cm (at 2.4 GHz)
|
||||
- Practical with 2 nodes: ~20 cm (limited by node geometry)
|
||||
- Frequency diversity gain: sqrt(6) improvement over single-channel = ~2.4x
|
||||
|
||||
### Why Single-Channel Cannot Do This
|
||||
|
||||
Single-channel provides only 1 frequency observation per path. Frequency-selective fading means a single channel may show zero attenuation through a person (if the path happens to be at a constructive interference point). Multiple channels provide independent attenuation measurements through the same spatial path, enabling reliable detection.
|
||||
|
||||
### Script
|
||||
|
||||
`scripts/rf-tomography.js`
|
||||
|
||||
---
|
||||
|
||||
## Application 2: Passive Bistatic Radar
|
||||
|
||||
### Principle
|
||||
|
||||
Neighbor WiFi APs transmit continuously and uncontrollably. The ESP32 nodes capture CSI from these transmissions, which includes phase and amplitude modulated by objects in the room. Each neighbor AP acts as a free "illuminator of opportunity" at a known position and frequency.
|
||||
|
||||
This is the same principle used by military passive radar systems (e.g., the Ukrainian Kolchuga, Czech VERA-NG) that use FM radio and TV transmitters to detect aircraft without emitting any signals themselves. Here we use WiFi APs instead of broadcast towers, and detect people instead of aircraft.
|
||||
|
||||
### Algorithm
|
||||
|
||||
```
|
||||
For each neighbor AP (identified by BSSID/channel):
|
||||
1. Track CSI phase progression across consecutive frames
|
||||
2. Compute Doppler shift: fd = d(phase)/dt / (2*pi)
|
||||
- Positive Doppler = target moving toward the AP
|
||||
- Negative Doppler = target moving away
|
||||
3. Compute range from subcarrier phase slope:
|
||||
- tau = d(phase)/d(subcarrier_freq) / (2*pi)
|
||||
- range = c * tau (where c = speed of light)
|
||||
4. Build range-Doppler map per AP
|
||||
5. Fuse multi-static detections:
|
||||
- Each AP provides a range ellipse (locus of constant TX->target->RX delay)
|
||||
- Intersection of 3+ ellipses = target position
|
||||
```
|
||||
|
||||
### Multi-Static Geometry
|
||||
|
||||
With 3+ neighbor APs as transmitters and 2 ESP32 receivers, we have 6+ bistatic pairs. Each pair constrains the target to an ellipse. The intersection provides 2D position.
|
||||
|
||||
```
|
||||
AP1 (ch5) AP2 (ch11)
|
||||
\ /
|
||||
\ TARGET /
|
||||
\ /|\ /
|
||||
\ / | \ /
|
||||
ESP32_1 ---*--+--*--- ESP32_2
|
||||
/ \ | / \
|
||||
/ \|/ \
|
||||
/ TARGET \
|
||||
/ \
|
||||
AP3 (ch3) AP4 (ch9)
|
||||
```
|
||||
|
||||
### Why Single-Channel Cannot Do This
|
||||
|
||||
Single-channel only captures CSI from APs on that one channel. With channel 5, you see ruv.net and Cohen-Guest, but miss COGECO-21B20 (ch11), conclusion mesh (ch3), NETGEAR72 (ch9). Multi-frequency scanning captures illumination from all 9 APs across 6 channels, providing the geometric diversity needed for position triangulation.
|
||||
|
||||
### Script
|
||||
|
||||
`scripts/passive-radar.js`
|
||||
|
||||
---
|
||||
|
||||
## Application 3: Frequency-Selective Material Classification
|
||||
|
||||
### Principle
|
||||
|
||||
Different materials interact with 2.4 GHz WiFi signals differently, and critically, their absorption/reflection varies with frequency:
|
||||
|
||||
| Material | Attenuation Pattern | Frequency Dependence |
|
||||
|----------|--------------------|--------------------|
|
||||
| Metal | Total reflection, deep null | Frequency-flat (blocks all equally) |
|
||||
| Water/Human body | Strong absorption | Increases with frequency (dielectric loss ~ f^2) |
|
||||
| Wood | Mild attenuation | Increases with frequency (moisture content) |
|
||||
| Glass | Low attenuation | Nearly frequency-flat |
|
||||
| Drywall | Low-moderate attenuation | Slight frequency dependence |
|
||||
| Concrete | Moderate-high attenuation | Increases with frequency |
|
||||
|
||||
### Algorithm
|
||||
|
||||
```
|
||||
For each subcarrier index i across all channels:
|
||||
1. Measure attenuation A(i, ch) on each channel
|
||||
2. Compute frequency selectivity:
|
||||
- Flat ratio = std(A across channels) / mean(A across channels)
|
||||
- Slope = linear regression of A vs frequency
|
||||
3. Classify:
|
||||
- Flat ratio < 0.1 AND high attenuation -> Metal
|
||||
- Flat ratio < 0.1 AND low attenuation -> Glass/Air
|
||||
- Positive slope (A increases with freq) AND high A -> Water/Human
|
||||
- Positive slope AND moderate A -> Wood
|
||||
- High variance across channels -> Complex scatterer
|
||||
```
|
||||
|
||||
### Physics Basis
|
||||
|
||||
At 2.4 GHz, water's complex permittivity is epsilon_r = 77 - j10. The imaginary component (loss) increases with frequency within the WiFi band. Metal is a perfect conductor regardless of frequency. Glass (epsilon_r ~ 6 - j0.1) has negligible loss at all WiFi frequencies.
|
||||
|
||||
The 50 MHz span (2412-2462 MHz) is only ~2% of the carrier frequency, but this is sufficient to detect the frequency-dependent absorption signature of water-bearing materials (human body, wet wood, potted plants) versus frequency-flat materials (metal, glass).
|
||||
|
||||
### Why Single-Channel Cannot Do This
|
||||
|
||||
Material classification requires measuring how attenuation varies with frequency. A single channel provides only one frequency point -- there is no frequency axis to measure against. Multi-frequency scanning provides 6 frequency points spanning 50 MHz, enabling slope and variance computation.
|
||||
|
||||
### Script
|
||||
|
||||
`scripts/material-classifier.js`
|
||||
|
||||
---
|
||||
|
||||
## Application 4: Through-Wall Motion Detection
|
||||
|
||||
### Principle
|
||||
|
||||
Lower WiFi frequencies penetrate walls better than higher frequencies. At 2.4 GHz, wall attenuation for a standard drywall+stud partition is approximately:
|
||||
|
||||
| Channel | Freq (MHz) | Drywall Loss (dB) | Concrete Loss (dB) |
|
||||
|---------|------------|-------------------|-------------------|
|
||||
| 1 | 2412 | 2.5 | 8.0 |
|
||||
| 6 | 2437 | 2.6 | 8.3 |
|
||||
| 11 | 2462 | 2.7 | 8.6 |
|
||||
|
||||
The absolute differences are small (~0.2 dB), but with 6 channels we can:
|
||||
|
||||
1. **Baseline the wall's frequency-dependent attenuation profile** during a calibration period (no one behind the wall)
|
||||
2. **Detect changes above baseline** that indicate motion behind the wall
|
||||
3. **Weight lower channels more heavily** since they have better through-wall SNR
|
||||
4. **Cross-validate** across channels: real through-wall motion appears on all channels (with frequency-dependent amplitude), while interference/noise typically appears on only one channel
|
||||
|
||||
### Algorithm
|
||||
|
||||
```
|
||||
Calibration phase (60 seconds, no motion behind wall):
|
||||
For each channel ch:
|
||||
baseline_mean[ch] = mean(CSI amplitude over calibration)
|
||||
baseline_std[ch] = std(CSI amplitude over calibration)
|
||||
|
||||
Detection phase:
|
||||
For each frame on channel ch:
|
||||
1. Compute deviation = |current_amplitude - baseline_mean[ch]| / baseline_std[ch]
|
||||
2. Channel weight = f(penetration_quality[ch])
|
||||
3. Per-channel score = deviation * weight
|
||||
|
||||
Fused score = weighted sum across channels
|
||||
Alert if fused_score > threshold for N consecutive frames
|
||||
```
|
||||
|
||||
### Why Single-Channel Cannot Do This
|
||||
|
||||
Single-channel through-wall detection suffers from high false-positive rates because it cannot distinguish wall effects from motion. With multi-frequency, we can:
|
||||
|
||||
1. Characterize the wall's frequency response during calibration
|
||||
2. Subtract the wall effect per channel
|
||||
3. Cross-validate detections across channels (real motion is coherent across frequencies; noise is not)
|
||||
|
||||
The frequency diversity provides a ~2.4x improvement in detection SNR (sqrt(6) independent observations).
|
||||
|
||||
### Script
|
||||
|
||||
`scripts/through-wall-detector.js`
|
||||
|
||||
---
|
||||
|
||||
## Application 5: Device Fingerprinting via RF Emissions
|
||||
|
||||
### Principle
|
||||
|
||||
Every electronic device has unique RF characteristics visible in the WiFi spectrum. When a device transmits (or even when its internal oscillators radiate EMI), it modulates nearby WiFi signals in device-specific ways:
|
||||
|
||||
- **WiFi APs**: each AP has unique transmit power, phase noise, and clock drift characteristics
|
||||
- **Printers**: the HP M255 LaserJet creates specific subcarrier patterns when printing (motor EMI)
|
||||
- **Microwave ovens**: 2.45 GHz magnetron radiates across channels 8-11, creating distinctive wideband interference
|
||||
- **Bluetooth devices**: 2.4 GHz frequency-hopping creates transient spikes across channels
|
||||
|
||||
### Algorithm
|
||||
|
||||
```
|
||||
Learning phase:
|
||||
For each known device (from WiFi scan SSID/BSSID correlation):
|
||||
1. Record CSI patterns when device is active vs inactive
|
||||
2. Compute per-channel signature:
|
||||
- Mean amplitude profile across subcarriers
|
||||
- Variance profile (active devices increase variance on specific subcarriers)
|
||||
- Phase noise characteristics
|
||||
3. Store signature as device fingerprint
|
||||
|
||||
Detection phase:
|
||||
For each analysis window:
|
||||
1. Compute current CSI profile per channel
|
||||
2. Correlate against stored fingerprints
|
||||
3. Report device activity: "HP printer active (confidence 0.87)"
|
||||
```
|
||||
|
||||
### Multi-Frequency Advantage
|
||||
|
||||
Different devices affect different channels:
|
||||
|
||||
- HP printer (ch5): affects subcarriers 20-40 on channel 5 during print jobs
|
||||
- NETGEAR72 router (ch9): creates clock-drift correlated phase patterns on channel 9
|
||||
- Microwave: broadband interference strongest on channels 9-11
|
||||
|
||||
Single-channel sensing only sees devices that affect that one channel. Multi-frequency scanning observes the full 2412-2462 MHz band, detecting device activity regardless of which channel the device operates on.
|
||||
|
||||
### Script
|
||||
|
||||
`scripts/device-fingerprint.js`
|
||||
|
||||
---
|
||||
|
||||
## Implementation
|
||||
|
||||
### Shared Infrastructure
|
||||
|
||||
All 5 scripts share common infrastructure:
|
||||
|
||||
| Component | Detail |
|
||||
|-----------|--------|
|
||||
| Packet format | ADR-018 binary (UDP) or .csi.jsonl (replay) |
|
||||
| IQ parsing | `parseIqHex()` for JSONL, `parseCSIFrame()` for binary UDP |
|
||||
| Channel assignment | From binary freq field, or simulated round-robin for legacy JSONL |
|
||||
| Node positions | Configurable, default: Node 1 at (0,0), Node 2 at (3,0) meters |
|
||||
| Visualization | ASCII Unicode block characters and box drawing |
|
||||
|
||||
### Scripts
|
||||
|
||||
| Script | Application | Lines | Key Algorithm |
|
||||
|--------|------------|-------|---------------|
|
||||
| `scripts/rf-tomography.js` | RF Tomographic Imaging | ~500 | ART backprojection |
|
||||
| `scripts/passive-radar.js` | Passive Bistatic Radar | ~500 | Range-Doppler + multi-static fusion |
|
||||
| `scripts/material-classifier.js` | Material Classification | ~450 | Frequency-selective attenuation analysis |
|
||||
| `scripts/through-wall-detector.js` | Through-Wall Detection | ~400 | Baselined multi-channel anomaly detection |
|
||||
| `scripts/device-fingerprint.js` | Device Fingerprinting | ~450 | Per-channel signature correlation |
|
||||
|
||||
### Data Requirements
|
||||
|
||||
- **Live mode**: UDP port 5006, 2 ESP32 nodes channel-hopping per ADR-073
|
||||
- **Replay mode**: `--replay <file.csi.jsonl>` with overnight recordings
|
||||
- **Calibration**: through-wall detector requires 60s calibration with `--calibrate`
|
||||
|
||||
## Performance Targets
|
||||
|
||||
| Application | Latency | Update Rate | Accuracy Target |
|
||||
|-------------|---------|-------------|-----------------|
|
||||
| RF Tomography | <100ms per frame | 1 Hz image update | 20 cm spatial resolution |
|
||||
| Passive Radar | <200ms per frame | 2 Hz range-Doppler | 1 m range, 0.1 m/s velocity |
|
||||
| Material Classification | <500ms per window | 0.5 Hz classification | 70% correct material ID |
|
||||
| Through-Wall Detection | <100ms per frame | 2 Hz detection | 90% true positive, <10% false positive |
|
||||
| Device Fingerprinting | <1s per window | 0.2 Hz activity update | 80% correct device ID |
|
||||
|
||||
## Risks
|
||||
|
||||
### Limited Frequency Span
|
||||
|
||||
The 50 MHz span (2412-2462 MHz) is only 2% of the carrier frequency. Material classification accuracy depends on the attenuation slope being measurable within this narrow range. Mitigation: use long averaging windows (5-10 seconds) to improve SNR of frequency-dependent measurements.
|
||||
|
||||
### Node Geometry
|
||||
|
||||
2 nodes provide limited spatial diversity for tomographic imaging. The backprojection is essentially 1D along the node-to-node axis, with poor resolution perpendicular to it. Mitigation: neighbor APs provide additional geometric diversity for passive radar mode.
|
||||
|
||||
### Legacy Data Compatibility
|
||||
|
||||
Overnight recordings (`data/recordings/overnight-*.csi.jsonl`) were captured before multi-frequency scanning was deployed and lack channel/frequency fields. Scripts simulate channel assignment for replay. Full multi-frequency data requires re-recording with channel hopping enabled.
|
||||
|
||||
### Phase Calibration
|
||||
|
||||
Passive radar requires accurate phase tracking across consecutive frames. ESP32 CSI phase includes a random offset per channel hop that must be removed. Mitigation: use phase-difference between consecutive frames rather than absolute phase.
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
1. **5 GHz multi-frequency**: rejected -- no 5 GHz APs visible in environment, no free illuminators.
|
||||
2. **UWB (ultra-wideband)**: rejected -- ESP32-S3 does not support UWB. Would require additional hardware (DW1000/DW3000 modules).
|
||||
3. **Dedicated radar hardware**: rejected -- multi-frequency WiFi sensing achieves similar capabilities using existing infrastructure at zero additional cost.
|
||||
|
||||
## References
|
||||
|
||||
- Wilson, J. & Patwari, N. (2010). "Radio Tomographic Imaging with Wireless Networks." IEEE Trans. Mobile Computing.
|
||||
- Colone, F. et al. (2012). "WiFi-Based Passive Bistatic Radar: Data Processing Schemes and Experimental Results." IEEE Trans. Aerospace and Electronic Systems.
|
||||
- Adib, F. & Katabi, D. (2013). "See Through Walls with WiFi!" ACM SIGCOMM.
|
||||
- Banerjee, A. et al. (2014). "RF-based material identification using WiFi signals." ACM MobiCom.
|
||||
@@ -1,512 +0,0 @@
|
||||
# ADR-079: Camera Ground-Truth Training Pipeline
|
||||
|
||||
- **Status**: Accepted
|
||||
- **Date**: 2026-04-06
|
||||
- **Deciders**: ruv
|
||||
- **Relates to**: ADR-072 (WiFlow Architecture), ADR-070 (Self-Supervised Pretraining), ADR-071 (ruvllm Training Pipeline), ADR-024 (AETHER Contrastive), ADR-064 (Multimodal Ambient Intelligence), ADR-075 (MinCut Person Separation)
|
||||
|
||||
## Context
|
||||
|
||||
WiFlow (ADR-072) currently trains without ground-truth pose labels, using proxy poses
|
||||
generated from presence/motion heuristics. This produces a PCK@20 of only 2.5% — far
|
||||
below the 30-50% achievable with supervised training. The fundamental bottleneck is the
|
||||
absence of spatial keypoint labels.
|
||||
|
||||
Academic WiFi pose estimation systems (Wi-Pose, Person-in-WiFi 3D, MetaFi++) all train
|
||||
with synchronized camera ground truth and achieve PCK@20 of 40-85%. They discard the
|
||||
camera at deployment — the camera is a training-time teacher, not a runtime dependency.
|
||||
|
||||
ADR-064 already identified this: *"Record CSI + mmWave while performing signs with a
|
||||
camera as ground truth, then deploy camera-free."* This ADR specifies the implementation.
|
||||
|
||||
### Current Training Pipeline Gap
|
||||
|
||||
```
|
||||
Current: CSI amplitude → WiFlow → 17 keypoints (proxy-supervised, PCK@20 = 2.5%)
|
||||
↑
|
||||
Heuristic proxies:
|
||||
- Standing skeleton when presence > 0.3
|
||||
- Limb perturbation from motion energy
|
||||
- No spatial accuracy
|
||||
```
|
||||
|
||||
### Target Pipeline
|
||||
|
||||
```
|
||||
Training: CSI amplitude ──→ WiFlow ──→ 17 keypoints (camera-supervised, PCK@20 target: 35%+)
|
||||
↑
|
||||
Laptop camera ──→ MediaPipe ──→ 17 COCO keypoints (ground truth)
|
||||
(time-synchronized, 30 fps)
|
||||
|
||||
Deploy: CSI amplitude ──→ WiFlow ──→ 17 keypoints (camera-free, trained model only)
|
||||
```
|
||||
|
||||
## Decision
|
||||
|
||||
Build a camera ground-truth collection and training pipeline using the laptop webcam
|
||||
as a teacher signal. The camera is used **only during training data collection** and is
|
||||
not required at deployment.
|
||||
|
||||
### Architecture Overview
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Data Collection Phase │
|
||||
│ │
|
||||
│ ESP32-S3 nodes ──UDP──→ Sensing Server ──→ CSI frames (.jsonl) │
|
||||
│ ↑ time sync │
|
||||
│ Laptop Camera ──→ MediaPipe Pose ──→ Keypoints (.jsonl) │
|
||||
│ ↑ │
|
||||
│ collect-ground-truth.py │
|
||||
│ (single orchestrator) │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Training Phase │
|
||||
│ │
|
||||
│ Paired dataset: { csi_window[128,20], keypoints[17,2], conf } │
|
||||
│ ↓ │
|
||||
│ train-wiflow-supervised.js │
|
||||
│ Phase 1: Contrastive pretrain (ADR-072, reuse) │
|
||||
│ Phase 2: Supervised keypoint regression (NEW) │
|
||||
│ Phase 3: Fine-tune with bone constraints + confidence │
|
||||
│ ↓ │
|
||||
│ WiFlow model (1.8M params) → SafeTensors export │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Deployment (camera-free) │
|
||||
│ │
|
||||
│ ESP32-S3 CSI → Sensing Server → WiFlow inference → 17 keypoints│
|
||||
│ (No camera. Trained model runs on CSI input only.) │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Component 1: `scripts/collect-ground-truth.py`
|
||||
|
||||
Single Python script that orchestrates synchronized capture from the laptop camera
|
||||
and the ESP32 CSI stream.
|
||||
|
||||
**Dependencies:** `mediapipe`, `opencv-python`, `requests` (all pip-installable, no GPU)
|
||||
|
||||
**Capture flow:**
|
||||
|
||||
```python
|
||||
# Pseudocode
|
||||
camera = cv2.VideoCapture(0) # Laptop webcam
|
||||
sensing_api = "http://localhost:3000" # Sensing server
|
||||
|
||||
# Start CSI recording via existing API
|
||||
requests.post(f"{sensing_api}/api/v1/recording/start")
|
||||
|
||||
while recording:
|
||||
frame = camera.read()
|
||||
t = time.time_ns() # Nanosecond timestamp
|
||||
|
||||
# MediaPipe Pose: 33 landmarks → map to 17 COCO keypoints
|
||||
result = mp_pose.process(frame)
|
||||
keypoints_17 = map_mediapipe_to_coco(result.pose_landmarks)
|
||||
confidence = mean(landmark.visibility for relevant landmarks)
|
||||
|
||||
# Write to ground-truth JSONL (one line per frame)
|
||||
write_jsonl({
|
||||
"ts_ns": t,
|
||||
"keypoints": keypoints_17, # [[x,y], ...] normalized [0,1]
|
||||
"confidence": confidence, # 0-1, used for loss weighting
|
||||
"n_visible": count(visibility > 0.5),
|
||||
})
|
||||
|
||||
# Optional: show live preview with skeleton overlay
|
||||
if preview:
|
||||
draw_skeleton(frame, keypoints_17)
|
||||
cv2.imshow("Ground Truth", frame)
|
||||
|
||||
# Stop CSI recording
|
||||
requests.post(f"{sensing_api}/api/v1/recording/stop")
|
||||
```
|
||||
|
||||
**MediaPipe → COCO keypoint mapping:**
|
||||
|
||||
| COCO Index | Joint | MediaPipe Index |
|
||||
|------------|-------|-----------------|
|
||||
| 0 | Nose | 0 |
|
||||
| 1 | Left Eye | 2 |
|
||||
| 2 | Right Eye | 5 |
|
||||
| 3 | Left Ear | 7 |
|
||||
| 4 | Right Ear | 8 |
|
||||
| 5 | Left Shoulder | 11 |
|
||||
| 6 | Right Shoulder | 12 |
|
||||
| 7 | Left Elbow | 13 |
|
||||
| 8 | Right Elbow | 14 |
|
||||
| 9 | Left Wrist | 15 |
|
||||
| 10 | Right Wrist | 16 |
|
||||
| 11 | Left Hip | 23 |
|
||||
| 12 | Right Hip | 24 |
|
||||
| 13 | Left Knee | 25 |
|
||||
| 14 | Right Knee | 26 |
|
||||
| 15 | Left Ankle | 27 |
|
||||
| 16 | Right Ankle | 28 |
|
||||
|
||||
### Component 2: Time Alignment (`scripts/align-ground-truth.js`)
|
||||
|
||||
CSI frames arrive at ~100 Hz with server-side timestamps. Camera keypoints arrive at
|
||||
~30 fps with client-side timestamps. Alignment is needed because:
|
||||
|
||||
1. Camera and sensing server clocks differ (typically < 50ms on LAN)
|
||||
2. CSI is aggregated into 20-frame windows for WiFlow input
|
||||
3. Ground-truth keypoints must be averaged over the same window
|
||||
|
||||
**Alignment algorithm:**
|
||||
|
||||
```
|
||||
For each CSI window W_i (20 frames, ~200ms at 100Hz):
|
||||
t_start = W_i.first_frame.timestamp
|
||||
t_end = W_i.last_frame.timestamp
|
||||
|
||||
# Find all camera keypoints within this time window
|
||||
matching_keypoints = [k for k in camera_data if t_start <= k.ts <= t_end]
|
||||
|
||||
if len(matching_keypoints) >= 3: # At least 3 camera frames per window
|
||||
# Average keypoints, weighted by confidence
|
||||
avg_keypoints = weighted_mean(matching_keypoints, weights=confidences)
|
||||
avg_confidence = mean(confidences)
|
||||
|
||||
paired_dataset.append({
|
||||
csi_window: W_i.amplitudes, # [128, 20] float32
|
||||
keypoints: avg_keypoints, # [17, 2] float32
|
||||
confidence: avg_confidence, # scalar
|
||||
n_camera_frames: len(matching_keypoints),
|
||||
})
|
||||
```
|
||||
|
||||
**Clock sync strategy:**
|
||||
|
||||
- NTP is sufficient (< 20ms error on LAN)
|
||||
- The 200ms CSI window is 10x larger than typical clock drift
|
||||
- For tighter sync: use a handclap/jump as a sync marker — visible spike in both
|
||||
CSI motion energy and camera skeleton velocity. Auto-detect and align.
|
||||
|
||||
**Output:** `data/recordings/paired-{timestamp}.jsonl` — one line per paired sample:
|
||||
```json
|
||||
{"csi": [128x20 flat], "kp": [[0.45,0.12], ...], "conf": 0.92, "ts": 1775300000000}
|
||||
```
|
||||
|
||||
### Component 3: Supervised Training (`scripts/train-wiflow-supervised.js`)
|
||||
|
||||
Extends the existing `train-ruvllm.js` pipeline with a supervised phase.
|
||||
|
||||
**Phase 1: Contrastive Pretrain (reuse ADR-072)**
|
||||
- Same as existing: temporal + cross-node triplets
|
||||
- Learns CSI representation without labels
|
||||
- 50 epochs, ~5 min on laptop
|
||||
|
||||
**Phase 2: Supervised Keypoint Regression (NEW)**
|
||||
- Load paired dataset from Component 2
|
||||
- Loss: confidence-weighted SmoothL1 on keypoints
|
||||
|
||||
```
|
||||
L_supervised = (1/N) * sum_i [ conf_i * SmoothL1(pred_i, gt_i, beta=0.05) ]
|
||||
```
|
||||
|
||||
- Only train on samples where `conf > 0.5` (discard frames where MediaPipe lost tracking)
|
||||
- Learning rate: 1e-4 with cosine decay
|
||||
- 200 epochs, ~15 min on laptop CPU (1.8M params, no GPU needed)
|
||||
|
||||
**Phase 3: Refinement with Bone Constraints**
|
||||
- Fine-tune with combined loss:
|
||||
|
||||
```
|
||||
L = L_supervised + 0.3 * L_bone + 0.1 * L_temporal
|
||||
|
||||
L_bone = (1/14) * sum_b (bone_len_b - prior_b)^2 # ADR-072 bone priors
|
||||
L_temporal = SmoothL1(kp_t, kp_{t-1}) # Temporal smoothness
|
||||
```
|
||||
|
||||
- 50 epochs at lower LR (1e-5)
|
||||
- Tighten bone constraint weight from 0.3 → 0.5 over epochs
|
||||
|
||||
**Phase 4: Quantization + Export**
|
||||
- Reuse ruvllm TurboQuant: float32 → int8 (4x smaller, ~881 KB)
|
||||
- Export via SafeTensors for cross-platform deployment
|
||||
- Validate quantized model PCK@20 within 2% of full-precision
|
||||
|
||||
### Component 4: Evaluation Script (`scripts/eval-wiflow.js`)
|
||||
|
||||
Measure actual PCK@20 using held-out paired data (20% split).
|
||||
|
||||
```
|
||||
PCK@k = (1/N) * sum_i [ (||pred_i - gt_i|| < k * torso_length) ? 1 : 0 ]
|
||||
```
|
||||
|
||||
**Metrics reported:**
|
||||
|
||||
| Metric | Description | Target |
|
||||
|--------|-------------|--------|
|
||||
| PCK@20 | % of keypoints within 20% torso length | > 35% |
|
||||
| PCK@50 | % within 50% torso length | > 60% |
|
||||
| MPJPE | Mean per-joint position error (pixels) | < 40px |
|
||||
| Per-joint PCK | Breakdown by joint (wrists are hardest) | Report all 17 |
|
||||
| Inference latency | Single window prediction time | < 50ms |
|
||||
|
||||
### Optimization Strategy
|
||||
|
||||
#### O1: Curriculum Learning
|
||||
|
||||
Train easy poses first, hard poses later:
|
||||
|
||||
| Stage | Epochs | Data Filter | Rationale |
|
||||
|-------|--------|-------------|-----------|
|
||||
| 1 | 50 | `conf > 0.9`, standing only | Establish stable skeleton baseline |
|
||||
| 2 | 50 | `conf > 0.7`, low motion | Add sitting, subtle movements |
|
||||
| 3 | 50 | `conf > 0.5`, all poses | Full dataset including occlusions |
|
||||
| 4 | 50 | All data, with augmentation | Robustness via noise injection |
|
||||
|
||||
#### O2: Data Augmentation (CSI domain)
|
||||
|
||||
Augment CSI windows to increase effective dataset size without collecting more data:
|
||||
|
||||
| Augmentation | Implementation | Expected Gain |
|
||||
|-------------|----------------|---------------|
|
||||
| Time shift | Roll CSI window by ±2 frames | +30% data |
|
||||
| Amplitude noise | Gaussian noise, sigma=0.02 | Robustness |
|
||||
| Subcarrier dropout | Zero 10% of subcarriers randomly | Robustness |
|
||||
| Temporal flip | Reverse window + reverse keypoint velocity | +100% data |
|
||||
| Multi-node mix | Swap node CSI, keep same-time keypoints | Cross-node generalization |
|
||||
|
||||
#### O3: Knowledge Distillation from MediaPipe
|
||||
|
||||
Instead of raw keypoint regression, distill MediaPipe's confidence and heatmap
|
||||
information:
|
||||
|
||||
```
|
||||
L_distill = KL_div(softmax(wifi_heatmap / T), softmax(camera_heatmap / T))
|
||||
```
|
||||
|
||||
- Temperature T=4 for soft targets (transfers inter-joint relationships)
|
||||
- WiFlow predicts a 17-channel heatmap [17, H, W] instead of direct [17, 2]
|
||||
- Argmax for final keypoint extraction
|
||||
- **Trade-off:** Adds ~200K params for heatmap decoder, but improves spatial precision
|
||||
|
||||
#### O4: Active Learning Loop
|
||||
|
||||
Identify which poses the model is worst at and collect more data for those:
|
||||
|
||||
```
|
||||
1. Train initial model on first collection session
|
||||
2. Run inference on new CSI data, compute prediction entropy
|
||||
3. Flag high-entropy windows (model is uncertain)
|
||||
4. During next collection, the preview overlay highlights these moments:
|
||||
"Hold this pose — model needs more examples"
|
||||
5. Re-train with augmented dataset
|
||||
```
|
||||
|
||||
Expected: 2-3 active learning iterations reach saturation.
|
||||
|
||||
#### O6: Subcarrier Selection (ruvector-solver)
|
||||
|
||||
Variance-based top-K subcarrier selection, equivalent to ruvector-solver's sparse
|
||||
interpolation (114→56). Removes noise/static subcarriers before training:
|
||||
|
||||
```
|
||||
For each subcarrier d in [0, dim):
|
||||
variance[d] = mean over samples of temporal_variance(csi[d, :])
|
||||
Select top-K by variance (K = dim * 0.5)
|
||||
```
|
||||
|
||||
**Validated:** 128 → 56 subcarriers (56% input reduction), proportional model size reduction.
|
||||
|
||||
#### O7: Attention-Weighted Subcarriers (ruvector-attention)
|
||||
|
||||
Compute per-subcarrier attention weights based on temporal energy correlation with
|
||||
ground-truth keypoint motion. High-energy subcarriers that covary with skeleton
|
||||
movement get amplified:
|
||||
|
||||
```
|
||||
For each subcarrier d:
|
||||
energy[d] = sum of squared first-differences over time
|
||||
weight[d] = softmax(energy, temperature=0.1)
|
||||
Apply: csi[d, :] *= weight[d] * dim (mean weight = 1)
|
||||
```
|
||||
|
||||
**Validated:** Top-5 attention subcarriers identified automatically per dataset.
|
||||
|
||||
#### O8: Stoer-Wagner MinCut Person Separation (ruvector-mincut / ADR-075)
|
||||
|
||||
JS implementation of the Stoer-Wagner algorithm for person separation in CSI, equivalent
|
||||
to `DynamicPersonMatcher` in `wifi-densepose-train/src/metrics.rs`. Builds a subcarrier
|
||||
correlation graph and finds the minimum cut to identify person-specific subcarrier clusters:
|
||||
|
||||
```
|
||||
1. Build dim×dim Pearson correlation matrix across subcarriers
|
||||
2. Run Stoer-Wagner min-cut on correlation graph
|
||||
3. Partition subcarriers into person-specific groups
|
||||
4. Train per-partition models for multi-person scenarios
|
||||
```
|
||||
|
||||
**Validated:** Stoer-Wagner executes on 56-dim graph, identifies partition boundaries.
|
||||
|
||||
#### O9: Multi-SPSA Gradient Estimation
|
||||
|
||||
Average over K=3 random perturbation directions per gradient step. Reduces variance
|
||||
by sqrt(K) = 1.73x compared to single SPSA, at 3x forward pass cost (net win for
|
||||
convergence quality):
|
||||
|
||||
```
|
||||
For k in 1..K:
|
||||
delta_k = random ±1 per parameter
|
||||
grad_k = (loss(w + eps*delta_k) - loss(w - eps*delta_k)) / (2*eps*delta_k)
|
||||
grad = mean(grad_1, ..., grad_K)
|
||||
```
|
||||
|
||||
#### O10: Mac M4 Pro Training via Tailscale
|
||||
|
||||
Training runs on Mac Mini M4 Pro (16-core GPU, ARM NEON SIMD) via Tailscale SSH,
|
||||
using ruvllm's native Node.js SIMD ops:
|
||||
|
||||
| | Windows (CPU) | Mac M4 Pro |
|
||||
|---|---|---|
|
||||
| Node.js | v24.12.0 (x86) | v25.9.0 (ARM) |
|
||||
| SIMD | SSE4/AVX2 | NEON |
|
||||
| Cores | Consumer laptop | 12P + 4E cores |
|
||||
| Training | Slow (minutes/epoch) | Fast (seconds/epoch) |
|
||||
|
||||
#### O5: Cross-Environment Transfer
|
||||
|
||||
Train on one room, deploy in another:
|
||||
|
||||
| Strategy | Implementation |
|
||||
|----------|---------------|
|
||||
| Room-invariant features | Normalize CSI by running mean/variance |
|
||||
| LoRA adapters | Train a 4-rank LoRA per room (ADR-071) — 7.3 KB each |
|
||||
| Few-shot calibration | 2 min of camera data in new room → fine-tune LoRA only |
|
||||
| AETHER embeddings | Use contrastive room-independent features (ADR-024) as input |
|
||||
|
||||
The LoRA approach is most practical: ship a base model + collect 2 min of calibration
|
||||
data per new room using the laptop camera.
|
||||
|
||||
### Data Collection Protocol
|
||||
|
||||
Recommended collection sessions per room:
|
||||
|
||||
| Session | Duration | Activity | People | Total CSI Frames |
|
||||
|---------|----------|----------|--------|-----------------|
|
||||
| 1. Baseline | 5 min | Empty + 1 person entry/exit | 0-1 | 30,000 |
|
||||
| 2. Standing poses | 5 min | Stand, arms up/down/sides, turn | 1 | 30,000 |
|
||||
| 3. Sitting | 5 min | Sit, type, lean, stand up/sit down | 1 | 30,000 |
|
||||
| 4. Walking | 5 min | Walk paths across room | 1 | 30,000 |
|
||||
| 5. Mixed | 5 min | Varied activities, transitions | 1 | 30,000 |
|
||||
| 6. Multi-person | 5 min | 2 people, varied activities | 2 | 30,000 |
|
||||
| **Total** | **30 min** | | | **180,000** |
|
||||
|
||||
At 20-frame windows: **9,000 paired training samples** per 30-min session.
|
||||
With augmentation (O2): **~27,000 effective samples**.
|
||||
|
||||
Camera placement: position laptop so the camera has a clear view of the sensing area.
|
||||
The camera FOV should cover the same space the ESP32 nodes cover.
|
||||
|
||||
### File Structure
|
||||
|
||||
```
|
||||
scripts/
|
||||
collect-ground-truth.py # Camera capture + MediaPipe + CSI sync
|
||||
align-ground-truth.js # Time-align CSI windows with camera keypoints
|
||||
train-wiflow-supervised.js # Supervised training pipeline
|
||||
eval-wiflow.js # PCK evaluation on held-out data
|
||||
|
||||
data/
|
||||
ground-truth/ # Raw camera keypoint captures
|
||||
gt-{timestamp}.jsonl
|
||||
paired/ # Aligned CSI + keypoint pairs
|
||||
paired-{timestamp}.jsonl
|
||||
|
||||
models/
|
||||
wiflow-supervised/ # Trained model outputs
|
||||
wiflow-v1.safetensors
|
||||
wiflow-v1-int8.safetensors
|
||||
training-log.json
|
||||
eval-report.json
|
||||
```
|
||||
|
||||
### Privacy Considerations
|
||||
|
||||
- Camera frames are processed **locally** by MediaPipe — no cloud upload
|
||||
- Raw video is **never saved** — only extracted keypoint coordinates are stored
|
||||
- The `.jsonl` ground-truth files contain only `[x,y]` joint coordinates, not images
|
||||
- The trained model runs on CSI only — no camera data leaves the laptop
|
||||
- Users can delete `data/ground-truth/` after training; the model is self-contained
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- **10-20x accuracy improvement**: PCK@20 from 2.5% → 35%+ with real supervision
|
||||
- **Reuses existing infrastructure**: sensing server recording API, ruvllm training, SafeTensors
|
||||
- **No new hardware**: laptop webcam + existing ESP32 nodes
|
||||
- **Privacy preserved at deployment**: camera only needed during 30-min training session
|
||||
- **Incremental**: can improve with more collection sessions + active learning
|
||||
- **Distributable**: trained model weights can be shared on HuggingFace (ADR-070)
|
||||
|
||||
### Negative
|
||||
|
||||
- **Camera placement matters**: must see the same area ESP32 nodes sense
|
||||
- **Single-room models**: need LoRA calibration per room (2 min + camera)
|
||||
- **MediaPipe limitations**: occlusion, side views, multiple people reduce keypoint quality
|
||||
- **Time sync**: NTP drift can misalign frames (mitigated by 200ms windows)
|
||||
|
||||
### Risks
|
||||
|
||||
| Risk | Probability | Impact | Mitigation |
|
||||
|------|-------------|--------|------------|
|
||||
| MediaPipe keypoints too noisy | Low | Medium | Filter by confidence; MediaPipe is robust indoors |
|
||||
| Clock drift > 100ms | Low | High | Add handclap sync marker detection |
|
||||
| Single camera can't see all poses | Medium | Medium | Position camera centrally; collect from 2 angles |
|
||||
| Model overfits to one room | High | Medium | LoRA adapters + AETHER normalization (O5) |
|
||||
| Insufficient data (< 5K pairs) | Low | High | Augmentation (O2) + active learning (O4) |
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
| Phase | Task | Effort | Status |
|
||||
|-------|------|--------|--------|
|
||||
| P1 | `collect-ground-truth.py` — camera + MediaPipe capture | 2 hrs | **Done** |
|
||||
| P2 | `align-ground-truth.js` — time alignment + pairing | 1 hr | **Done** |
|
||||
| P3 | `train-wiflow-supervised.js` — supervised training | 3 hrs | **Done** |
|
||||
| P4 | `eval-wiflow.js` — PCK evaluation | 1 hr | **Done** |
|
||||
| P5 | ruvector optimizations (O6-O9) | 2 hrs | **Done** |
|
||||
| P6 | Mac M4 Pro training via Tailscale (O10) | 1 hr | **Done** |
|
||||
| P7 | Data collection session (30 min recording) | 1 hr | Pending |
|
||||
| P8 | Training + evaluation on real paired data | 30 min | Pending |
|
||||
| P9 | LoRA cross-room calibration (O5) | 2 hrs | Pending |
|
||||
|
||||
## Validated Hardware
|
||||
|
||||
| Component | Spec | Validated |
|
||||
|-----------|------|-----------|
|
||||
| Mac Mini camera | 1920x1080, 30fps | Yes — 14/17 keypoints, conf 0.94-1.0 |
|
||||
| MediaPipe PoseLandmarker | v0.10.33 Tasks API, lite model | Yes — via Tailscale SSH |
|
||||
| Mac M4 Pro GPU | 16-core, Metal 4, NEON SIMD | Yes — Node.js v25.9.0 |
|
||||
| Tailscale SSH | LAN-accessible Mac, passwordless | Yes |
|
||||
| ESP32-S3 CSI | 128 subcarriers, 100Hz | Yes — existing recordings |
|
||||
| Sensing server recording API | `/api/v1/recording/start\|stop` | Yes — existing |
|
||||
|
||||
## Baseline Benchmark
|
||||
|
||||
Proxy-pose baseline (no camera supervision, standing skeleton heuristic):
|
||||
|
||||
```
|
||||
PCK@10: 11.8%
|
||||
PCK@20: 35.3%
|
||||
PCK@50: 94.1%
|
||||
MPJPE: 0.067
|
||||
Latency: 0.03ms/sample
|
||||
```
|
||||
|
||||
Per-joint PCK@20: upper body (nose, shoulders, wrists) at 0% — proxy has no spatial
|
||||
accuracy for these. Camera supervision targets these joints specifically.
|
||||
|
||||
## References
|
||||
|
||||
- WiFlow: arXiv:2602.08661 — WiFi-based pose estimation with TCN + axial attention
|
||||
- Wi-Pose (CVPR 2021) — 3D CNN WiFi pose with camera supervision
|
||||
- Person-in-WiFi 3D (CVPR 2024) — Deformable attention with camera labels
|
||||
- MediaPipe Pose — Google's real-time 33-landmark body pose estimator
|
||||
- MetaFi++ (NeurIPS 2023) — Meta-learning cross-modal WiFi sensing
|
||||
@@ -1,99 +0,0 @@
|
||||
# ADR-080: QE Analysis Remediation Plan
|
||||
|
||||
- **Status:** Proposed
|
||||
- **Date:** 2026-04-06
|
||||
- **Source:** [QE Analysis Gist (2026-04-05)](https://gist.github.com/proffesor-for-testing/a6b84d7a4e26b7bbef0cf12f932925b7)
|
||||
- **Full Reports:** [proffesor-for-testing/RuView `qe-reports` branch](https://github.com/proffesor-for-testing/RuView/tree/qe-reports/docs/qe-reports)
|
||||
|
||||
## Context
|
||||
|
||||
An 8-agent QE swarm analyzed ~305K lines across Rust, Python, C firmware, and TypeScript on 2026-04-05. The overall score was **55/100 (C+) — Quality Gate FAILED**. This ADR captures the findings and establishes a remediation plan.
|
||||
|
||||
## Decision
|
||||
|
||||
Address the 15 prioritized issues from the QE analysis in three waves: P0 (immediate), P1 (this sprint), P2 (this quarter).
|
||||
|
||||
## P0 — Fix Immediately
|
||||
|
||||
### 1. Rate Limiter Bypass (Security HIGH)
|
||||
|
||||
- **Location:** `v1/src/middleware/rate_limit.py:200-206`
|
||||
- **Problem:** Trusts `X-Forwarded-For` without validation. Any client bypasses rate limits via header spoofing.
|
||||
- **Fix:** Validate forwarded headers against trusted proxy list, or use connection IP directly.
|
||||
|
||||
### 2. Exception Details Leaked in Responses (Security HIGH)
|
||||
|
||||
- **Location:** `v1/src/api/routers/pose.py:140`, `stream.py:297`, +5 endpoints
|
||||
- **Problem:** Stack traces visible regardless of environment.
|
||||
- **Fix:** Wrap with generic error responses in production; log details server-side only.
|
||||
|
||||
### 3. WebSocket JWT in URL (Security HIGH, CWE-598)
|
||||
|
||||
- **Location:** `v1/src/api/routers/stream.py:74`, `v1/src/middleware/auth.py:243`
|
||||
- **Problem:** Tokens in query strings visible in logs/proxies/browser history.
|
||||
- **Fix:** Use WebSocket subprotocol or first-message auth pattern.
|
||||
|
||||
### 4. Rust Tests Not in CI
|
||||
|
||||
- **Problem:** 2,618 tests across 153K lines of Rust — zero run in any GitHub Actions workflow. Regressions ship undetected.
|
||||
- **Fix:** Add `cargo test --workspace --no-default-features` to CI. 1-2 hour task.
|
||||
|
||||
### 5. WebSocket Path Mismatch (Bug)
|
||||
|
||||
- **Location:** `ui/mobile/src/services/ws.service.ts:104` constructs `/ws/sensing`, but `constants/websocket.ts:1` defines `WS_PATH = '/api/v1/stream/pose'`.
|
||||
- **Problem:** Mobile WebSocket silently fails.
|
||||
- **Fix:** Align paths. Verify which endpoint the server actually serves.
|
||||
|
||||
## P1 — Fix This Sprint
|
||||
|
||||
| # | Issue | Location | Impact |
|
||||
|---|-------|----------|--------|
|
||||
| 6 | God file: 4,846 lines, CC=121 | `sensing-server/src/main.rs` | Untestable monolith |
|
||||
| 7 | O(L×V) voxel scan per frame | `ruvsense/tomography.rs:345-383` | ~10ms wasted; use DDA ray march |
|
||||
| 8 | Sequential neural inference | `wifi-densepose-nn inference.rs:334-336` | 2-4× GPU latency penalty |
|
||||
| 9 | 720 `.unwrap()` in Rust | Workspace-wide | Each = potential panic in RT paths |
|
||||
| 10 | 112KB alloc/frame in Python | `csi_processor.py:412-414` | Deque→list→numpy every frame |
|
||||
|
||||
## P2 — Fix This Quarter
|
||||
|
||||
| # | Issue | Impact |
|
||||
|---|-------|--------|
|
||||
| 11 | 11/12 Python modules have zero unit tests (12,280 LOC) | Services, middleware, DB untested |
|
||||
| 12 | Firmware at 19% coverage (WASM runtime, OTA, swarm) | Security-critical code untested |
|
||||
| 13 | MAT screen auto-falls back to simulated data | Disaster responders could monitor fake data |
|
||||
| 14 | Token blacklist never consulted during auth | Revoked tokens remain valid |
|
||||
| 15 | 50ms frame budget never benchmarked | Real-time requirement unverified |
|
||||
|
||||
## Bright Spots
|
||||
|
||||
- 79 ADRs (exceptional governance)
|
||||
- Witness bundle system (ADR-028) with SHA-256 proof
|
||||
- 2,618 Rust tests with mathematical rigor
|
||||
- Daily security scanning (Bandit, Semgrep, Safety)
|
||||
- Ed25519 WASM signature verification on firmware
|
||||
- Clean mobile state management with good test coverage
|
||||
|
||||
## Full QE Reports (9 files, 4,914 lines)
|
||||
|
||||
| Report | What it covers |
|
||||
|--------|---------------|
|
||||
| `EXECUTIVE-SUMMARY.md` | Top-level synthesis with all scores and priority matrix |
|
||||
| `00-qe-queen-summary.md` | Master coordination, quality posture, test pyramid |
|
||||
| `01-code-quality-complexity.md` | Cyclomatic complexity, code smells, top 20 hotspots |
|
||||
| `02-security-review.md` | 15 security findings (3 HIGH, 7 MEDIUM), OWASP coverage |
|
||||
| `03-performance-analysis.md` | 23 perf findings (4 CRITICAL), frame budget analysis |
|
||||
| `04-test-analysis.md` | 3,353 tests inventoried, duplication, quality grading |
|
||||
| `05-quality-experience.md` | API/CLI/Mobile/DX UX assessment |
|
||||
| `06-product-assessment-sfdipot.md` | SFDIPOT analysis, 57 test ideas, 14 session charters |
|
||||
| `07-coverage-gaps.md` | Coverage matrix, top 20 risk gaps, 8-week roadmap |
|
||||
|
||||
## Consequences
|
||||
|
||||
- **P0 fixes** eliminate 3 security vulnerabilities and 2 functional bugs
|
||||
- **P1 fixes** improve performance, reliability, and maintainability
|
||||
- **P2 fixes** close coverage gaps and harden the system for production
|
||||
- Target score improvement: 55 → 75+ after P0+P1 completion
|
||||
|
||||
---
|
||||
|
||||
*Generated from QE swarm analysis (fleet-02558e91) on 2026-04-05*
|
||||
@@ -1,627 +0,0 @@
|
||||
# ADR-081: Gesture-Controlled Data Visualization
|
||||
|
||||
- **Status**: Proposed
|
||||
- **Date**: 2026-04-07
|
||||
- **Deciders**: ruv
|
||||
- **Relates to**: ADR-079 (Camera Ground-Truth Training), ADR-029 (RuvSense Gesture Recognition), ADR-072 (WiFlow Architecture), ADR-076 (CNN Spectrogram Embeddings)
|
||||
|
||||
## Context
|
||||
|
||||
RuView can now track 17 COCO keypoints at 92.9% PCK@20 (ADR-079) and detect gestures
|
||||
via DTW template matching (ADR-029). These capabilities exist independently — pose
|
||||
estimation produces skeleton coordinates, and the UI displays static charts. There is no
|
||||
system that connects hand/arm movements to interactive data exploration.
|
||||
|
||||
Gesture-controlled visualization would let users manipulate charts and graphs by waving
|
||||
their hands in front of the ESP32 sensing zone — no mouse, no touchscreen, no wearable.
|
||||
This is particularly valuable for:
|
||||
|
||||
- **Lab/cleanroom** — gloved hands can't use touchscreens
|
||||
- **Kitchen/workshop** — dirty or wet hands
|
||||
- **Presentations** — stand back and gesture at projected dashboards
|
||||
- **Accessibility** — motor impairments that make mouse use difficult
|
||||
- **Digital signage** — public displays without touch hardware
|
||||
|
||||
### Why Camera + CSI Fusion
|
||||
|
||||
Camera alone can do gesture control (e.g., Leap Motion, MediaPipe Hands). CSI alone can
|
||||
detect coarse gestures (ADR-029). The fusion provides:
|
||||
|
||||
| Modality | Strengths | Weaknesses |
|
||||
|----------|-----------|-----------|
|
||||
| Camera (MediaPipe Hands) | 21 hand landmarks, finger-level precision, 30fps | Requires line of sight, lighting dependent, privacy concern |
|
||||
| CSI (ESP32) | Through-wall, works in dark, privacy-preserving, $9 | Coarse spatial resolution, no finger tracking |
|
||||
| **Fusion** | **Finger precision near camera + coarse tracking everywhere** | Requires both sensors during training |
|
||||
|
||||
The fusion model trains on camera + CSI pairs (like ADR-079), then deploys in two modes:
|
||||
1. **Camera-assisted** — full precision when camera is available
|
||||
2. **CSI-only** — reduced but functional gesture control without camera
|
||||
|
||||
## Decision
|
||||
|
||||
Build a gesture-to-visualization control system that maps hand/arm movements to chart
|
||||
interactions using fused camera + CSI input.
|
||||
|
||||
### Gesture Vocabulary
|
||||
|
||||
#### Navigation Gestures (arm-level, CSI-detectable)
|
||||
|
||||
| Gesture | Motion | Chart Action | CSI Feasibility |
|
||||
|---------|--------|-------------|-----------------|
|
||||
| **Swipe left** | Open hand sweeps left | Pan chart left / previous dataset | High — clear directional motion |
|
||||
| **Swipe right** | Open hand sweeps right | Pan chart right / next dataset | High |
|
||||
| **Swipe up** | Open hand sweeps up | Scroll up / zoom out | High |
|
||||
| **Swipe down** | Open hand sweeps down | Scroll down / zoom in | High |
|
||||
| **Push forward** | Palm pushes toward screen | Select / drill into data point | Medium — depth motion harder |
|
||||
| **Pull back** | Hand pulls away from screen | Back / zoom out | Medium |
|
||||
| **Circular CW** | Hand circles clockwise | Increase value / rotate view | Medium — temporal pattern |
|
||||
| **Circular CCW** | Hand circles counter-clockwise | Decrease value / rotate back | Medium |
|
||||
| **Hold still** | Hand stationary 2+ seconds | Hover / show tooltip | High — absence of motion |
|
||||
| **Both hands apart** | Arms spread outward | Expand / zoom into selection | High — bilateral motion |
|
||||
| **Both hands together** | Arms move inward | Collapse / zoom out | High |
|
||||
|
||||
#### Precision Gestures (finger-level, camera-required)
|
||||
|
||||
| Gesture | Motion | Chart Action | Sensor |
|
||||
|---------|--------|-------------|--------|
|
||||
| **Pinch zoom** | Thumb + index spread/close | Continuous zoom | Camera only |
|
||||
| **Point** | Index finger extended | Cursor position on chart | Camera only |
|
||||
| **Grab** | Close fist | Grab and drag data point | Camera only |
|
||||
| **Thumb up** | Thumbs up | Confirm / approve | Camera only |
|
||||
| **Thumb down** | Thumbs down | Reject / undo | Camera only |
|
||||
| **Two-finger rotate** | Two fingers twist | Rotate 3D visualization | Camera only |
|
||||
| **Finger slider** | Index finger moves along axis | Adjust parameter value | Camera only |
|
||||
|
||||
### Architecture
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────────┐
|
||||
│ Input Layer │
|
||||
│ │
|
||||
│ ESP32 CSI (UDP 5005) ──→ CSI Gesture Detector (DTW + WiFlow) │
|
||||
│ ↓ │
|
||||
│ Webcam (MediaPipe Hands) ──→ Hand Landmark Tracker (21 joints) │
|
||||
│ ↓ │
|
||||
│ Gesture Fusion Engine │
|
||||
│ ├── CSI coarse: swipe/circle/hold │
|
||||
│ ├── Camera fine: pinch/point/grab │
|
||||
│ └── Confidence weighting by modality │
|
||||
└──────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌──────────────────────────────────────────────────────────────────┐
|
||||
│ Gesture Interpreter │
|
||||
│ │
|
||||
│ Raw gestures ──→ State Machine ──→ Chart Commands │
|
||||
│ │
|
||||
│ States: │
|
||||
│ IDLE ──(motion detected)──→ TRACKING │
|
||||
│ TRACKING ──(gesture matched)──→ ACTING │
|
||||
│ ACTING ──(gesture complete)──→ COOLDOWN │
|
||||
│ COOLDOWN ──(500ms)──→ IDLE │
|
||||
│ │
|
||||
│ Debounce: 200ms minimum gesture duration │
|
||||
│ Cooldown: 500ms between consecutive gestures │
|
||||
│ Confidence threshold: 0.7 for CSI, 0.9 for camera │
|
||||
└──────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌──────────────────────────────────────────────────────────────────┐
|
||||
│ Visualization Controller │
|
||||
│ │
|
||||
│ Chart Commands ──→ WebSocket ──→ UI │
|
||||
│ │
|
||||
│ Commands: │
|
||||
│ { type: "pan", dx: -0.1, dy: 0 } │
|
||||
│ { type: "zoom", factor: 1.2, center: [0.5, 0.5] } │
|
||||
│ { type: "select", x: 0.45, y: 0.62 } │
|
||||
│ { type: "rotate", angle: 15 } │
|
||||
│ { type: "slider", axis: "x", value: 0.73 } │
|
||||
│ { type: "hover", x: 0.45, y: 0.62 } │
|
||||
│ { type: "back" } │
|
||||
│ { type: "confirm" } │
|
||||
│ { type: "reject" } │
|
||||
└──────────────────────────────────────────────────────────────────┘
|
||||
↓
|
||||
┌──────────────────────────────────────────────────────────────────┐
|
||||
│ Visualization UI │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
|
||||
│ │ Line Chart │ │ Bar Chart │ │ 3D Scatter │ │
|
||||
│ │ (time │ │ (category │ │ (spatial │ │
|
||||
│ │ series) │ │ compare) │ │ data) │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────┘ │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
|
||||
│ │ Heatmap │ │ Gauge │ │ Spectrogram │ │
|
||||
│ │ (CSI grid) │ │ (vitals) │ │ (frequency) │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────┘ │
|
||||
│ │
|
||||
│ Visual feedback: gesture cursor overlay + action indicator │
|
||||
│ Framework: D3.js / Observable Plot in existing UI │
|
||||
└──────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Gesture Detection Pipeline
|
||||
|
||||
#### CSI Gesture Detection (arm-level)
|
||||
|
||||
Extends the existing DTW gesture classifier (ADR-029) with WiFlow pose input:
|
||||
|
||||
```
|
||||
CSI [35, 20] ──→ WiFlow lite ──→ 17 keypoints ──→ Extract arm features:
|
||||
- Wrist velocity (dx/dt, dy/dt)
|
||||
- Elbow angle (shoulder-elbow-wrist)
|
||||
- Bilateral symmetry (left vs right)
|
||||
- Motion energy (frame differencing)
|
||||
↓
|
||||
DTW template matching:
|
||||
- 11 gesture templates
|
||||
- Sliding window (1s)
|
||||
- Top match + confidence
|
||||
```
|
||||
|
||||
#### Camera Gesture Detection (finger-level)
|
||||
|
||||
Uses MediaPipe Hands (21 landmarks per hand, 30fps):
|
||||
|
||||
```
|
||||
Webcam ──→ MediaPipe Hands ──→ 21 landmarks × 2 hands ──→ Extract:
|
||||
- Finger states (extended/curled)
|
||||
- Pinch distance (thumb-index)
|
||||
- Grab state (all fingers curled)
|
||||
- Point direction (index ray)
|
||||
- Hand center velocity
|
||||
↓
|
||||
Rule-based classifier:
|
||||
- Pinch: thumb-index < 0.05
|
||||
- Point: only index extended
|
||||
- Grab: all fingers curled
|
||||
- Thumbs up/down: thumb angle
|
||||
```
|
||||
|
||||
#### Fusion Strategy
|
||||
|
||||
```
|
||||
CSI confidence ──┐
|
||||
├──→ Weighted fusion ──→ Final gesture + confidence
|
||||
Camera conf ──┘
|
||||
|
||||
Rules:
|
||||
- If both agree: confidence = max(csi_conf, cam_conf) + 0.1 * min(csi_conf, cam_conf)
|
||||
- If only CSI: use CSI gesture, confidence *= 0.8
|
||||
- If only camera: use camera gesture, confidence *= 0.95
|
||||
- If conflict: prefer camera for fine gestures, CSI for coarse gestures
|
||||
- Minimum confidence for action: 0.6
|
||||
```
|
||||
|
||||
### Chart Interaction Mapping
|
||||
|
||||
#### Line Chart (Time Series)
|
||||
|
||||
| Gesture | Action | Parameters |
|
||||
|---------|--------|-----------|
|
||||
| Swipe left/right | Pan time axis | dx proportional to swipe speed |
|
||||
| Pinch zoom | Zoom time axis | Continuous, centered on hand position |
|
||||
| Both hands apart/together | Zoom (CSI-only alternative) | Binary zoom in/out |
|
||||
| Point | Show tooltip at nearest data point | x from index finger position |
|
||||
| Hold still | Sticky tooltip | Duration-based activation |
|
||||
| Swipe up/down | Switch dataset / Y-axis scale | Discrete steps |
|
||||
|
||||
#### Bar Chart (Category Comparison)
|
||||
|
||||
| Gesture | Action | Parameters |
|
||||
|---------|--------|-----------|
|
||||
| Swipe left/right | Navigate categories | One category per swipe |
|
||||
| Point | Highlight bar | Nearest bar to finger X position |
|
||||
| Push forward | Select bar for drill-down | Depth gesture |
|
||||
| Grab + drag | Reorder bars | Camera-only |
|
||||
| Circular | Sort ascending/descending | Direction determines order |
|
||||
|
||||
#### 3D Scatter Plot
|
||||
|
||||
| Gesture | Action | Parameters |
|
||||
|---------|--------|-----------|
|
||||
| Swipe left/right | Rotate Y axis | Angle proportional to speed |
|
||||
| Swipe up/down | Rotate X axis | Angle proportional to speed |
|
||||
| Two-finger rotate | Rotate Z axis | Camera-only |
|
||||
| Pinch zoom | Zoom | Camera-only |
|
||||
| Both hands apart | Zoom in (CSI alternative) | Binary |
|
||||
| Point | Highlight nearest point | Ray-cast from finger direction |
|
||||
|
||||
#### Heatmap (CSI Grid)
|
||||
|
||||
| Gesture | Action | Parameters |
|
||||
|---------|--------|-----------|
|
||||
| Swipe | Pan view | dx, dy |
|
||||
| Pinch | Zoom region | Center + scale |
|
||||
| Hold | Show cell value | Position-based |
|
||||
| Circular | Adjust color scale range | CW = expand, CCW = contract |
|
||||
|
||||
#### Gauge (Vital Signs)
|
||||
|
||||
| Gesture | Action | Parameters |
|
||||
|---------|--------|-----------|
|
||||
| Swipe left/right | Switch vital (HR → BR → SpO2) | Discrete |
|
||||
| Circular CW | Set high alert threshold | Continuous |
|
||||
| Circular CCW | Set low alert threshold | Continuous |
|
||||
| Thumb up | Acknowledge alert | Binary |
|
||||
|
||||
### Visual Feedback: AR Camera Overlay
|
||||
|
||||
The primary view is the **live camera feed with AR overlays** — the person is visible
|
||||
with charts, skeleton, and data rendered on top. This creates a "Minority Report" style
|
||||
interface where you see yourself manipulating data in real-time.
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ │
|
||||
│ ╔══════════════════════════════════════════════════════════╗ │
|
||||
│ ║ ║ │
|
||||
│ ║ [Live Camera Feed — person visible] ║ │
|
||||
│ ║ ║ │
|
||||
│ ║ ╭─────╮ ║ │
|
||||
│ ║ │ │ ← skeleton overlay (17 keypoints) ║ │
|
||||
│ ║ ╰──┬──╯ ║ │
|
||||
│ ║ ╱ ╲ ║ │
|
||||
│ ║ ╱ ╲ ┌──────────────────────┐ ║ │
|
||||
│ ║ │ │ │ CSI Amplitude Chart │ ║ │
|
||||
│ ║ │ 🖐→ │ │ ┌─╮ ╭─╮ ╭──╮ │ ║ │
|
||||
│ ║ │ │ │ │ ╰─╯ ╰───╯ │ │ ║ │
|
||||
│ ║ ╲ ╱ │ │ │ │ ║ │
|
||||
│ ║ ╲ ╱ └──────────────────────┘ ║ │
|
||||
│ ║ │ │ ↑ chart follows hand position ║ │
|
||||
│ ║ ╱ ╲ ║ │
|
||||
│ ║ ╱ ╲ ║ │
|
||||
│ ║ ║ │
|
||||
│ ╚══════════════════════════════════════════════════════════╝ │
|
||||
│ │
|
||||
│ ┌──────────────────────────────────────────────────────────┐ │
|
||||
│ │ LOWER THIRD │ │
|
||||
│ │ ┌────┐ │ │
|
||||
│ │ │ pi │ RuView Sensing HR: 72 BPM BR: 16 BPM │ │
|
||||
│ │ │ │ v0.7.0 Presence: 1 Motion: 0.23 │ │
|
||||
│ │ └────┘ │ │
|
||||
│ │ [logo] [gesture: Swipe Right] [CSI ●] [CAM ●] [28fps]│ │
|
||||
│ └──────────────────────────────────────────────────────────┘ │
|
||||
└──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
#### AR Overlay Layers (bottom to top)
|
||||
|
||||
| Layer | Content | Opacity | Update Rate |
|
||||
|-------|---------|---------|-------------|
|
||||
| 0 | Live camera feed (full frame) | 100% | 30fps |
|
||||
| 1 | Skeleton overlay (17 keypoints + bones) | 70% | 30fps |
|
||||
| 2 | Gesture cursor (hand position + state) | 90% | 30fps |
|
||||
| 3 | Floating chart (anchored to hand/body region) | 85% | 30fps |
|
||||
| 4 | Data labels + tooltips | 95% | On gesture |
|
||||
| 5 | Lower third (RuView branding + vitals + status) | 95% | 1fps |
|
||||
|
||||
#### Floating Chart Placement
|
||||
|
||||
Charts are **anchored to the person's body** and follow movement:
|
||||
|
||||
```
|
||||
Placement rules:
|
||||
- Default: chart floats to the right of the person's dominant hand
|
||||
- If hand moves left: chart slides to left side
|
||||
- Chart stays within frame bounds (never clips off-screen)
|
||||
- Multiple charts: stack vertically with 10% gap
|
||||
- Inactive charts: shrink to thumbnail and anchor near shoulder
|
||||
|
||||
Chart anchor point = wrist_position + offset(0.15, -0.1) // right and slightly above hand
|
||||
Chart size: 30% of frame width × 20% of frame height
|
||||
```
|
||||
|
||||
#### Lower Third Design
|
||||
|
||||
The lower third bar provides persistent status in broadcast-style framing:
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ ┌──────┐ │
|
||||
│ │ pi │ RuView Sensing v0.7.0 │
|
||||
│ │ │ ────────────────────────────────────────────── │
|
||||
│ │ logo │ HR: 72 BPM | BR: 16 BPM | Persons: 1 │
|
||||
│ └──────┘ Motion: Low | Gesture: Swipe Right | 28fps │
|
||||
│ [CSI ●] [CAM ●] [FUSE] PCK@20: 92.9% │
|
||||
└──────────────────────────────────────────────────────────────┘
|
||||
|
||||
Design:
|
||||
- Background: semi-transparent dark (#1a1a2e, 80% opacity)
|
||||
- Logo: RuView "pi" icon (32x32px), left-aligned
|
||||
- Text: white (#ffffff) primary, gray (#a0a0a0) secondary
|
||||
- Accent: teal (#00d4aa) for active indicators
|
||||
- Height: 15% of frame
|
||||
- Font: system monospace for data, sans-serif for labels
|
||||
- Divider: thin teal line separating logo from data
|
||||
```
|
||||
|
||||
#### RuView Logo Placement
|
||||
|
||||
```
|
||||
The "pi" logo appears in two contexts:
|
||||
|
||||
1. Lower third (persistent):
|
||||
- Position: bottom-left corner, 12px padding
|
||||
- Size: 32x32px
|
||||
- Style: white outline on dark background
|
||||
- Always visible during gesture mode
|
||||
|
||||
2. Watermark (optional):
|
||||
- Position: top-right corner, 8px padding
|
||||
- Size: 24x24px, 30% opacity
|
||||
- Style: subtle, doesn't interfere with data
|
||||
```
|
||||
|
||||
#### Skeleton Rendering Style
|
||||
|
||||
```
|
||||
Keypoint rendering:
|
||||
- Detected joints: teal circles (#00d4aa), radius 6px
|
||||
- Low-confidence joints: gray circles (#666), radius 4px
|
||||
- Active hand (gesturing): yellow highlight (#ffcc00), radius 8px, glow effect
|
||||
|
||||
Bone rendering:
|
||||
- Normal bones: teal lines (#00d4aa), 2px stroke
|
||||
- Active arm (gesturing): yellow lines (#ffcc00), 3px stroke, glow
|
||||
- Torso: slightly thicker (3px) to anchor the skeleton visually
|
||||
|
||||
Style: dark-theme friendly, high contrast against camera feed
|
||||
```
|
||||
|
||||
**Cursor types:**
|
||||
- **Open hand** — teal ring around wrist, rays extending from fingers
|
||||
- **Pointing** — teal ray from index finger toward chart
|
||||
- **Grabbing** — yellow fist icon, chart border highlights
|
||||
- **Pinching** — two teal dots (thumb + index) with distance line
|
||||
- **Ghost cursor** — CSI-only mode: larger, more diffuse circle (no finger detail)
|
||||
|
||||
### Data Flow Protocol
|
||||
|
||||
WebSocket messages from gesture engine to UI:
|
||||
|
||||
```typescript
|
||||
interface GestureEvent {
|
||||
type: 'gesture';
|
||||
gesture: 'swipe_left' | 'swipe_right' | 'swipe_up' | 'swipe_down'
|
||||
| 'pinch_zoom' | 'point' | 'grab' | 'hold' | 'circle_cw'
|
||||
| 'circle_ccw' | 'push' | 'pull' | 'spread' | 'contract'
|
||||
| 'thumb_up' | 'thumb_down';
|
||||
confidence: number; // 0-1
|
||||
source: 'csi' | 'camera' | 'fusion';
|
||||
position?: [number, number]; // Normalized [0,1] hand position
|
||||
velocity?: [number, number]; // Hand velocity for proportional control
|
||||
param?: number; // Gesture-specific parameter (pinch distance, rotation angle)
|
||||
}
|
||||
|
||||
interface CursorEvent {
|
||||
type: 'cursor';
|
||||
x: number; // 0-1 normalized
|
||||
y: number; // 0-1 normalized
|
||||
state: 'tracking' | 'pointing' | 'grabbing' | 'pinching' | 'idle';
|
||||
hands: number; // 0, 1, or 2
|
||||
}
|
||||
|
||||
interface StatusEvent {
|
||||
type: 'status';
|
||||
csi_active: boolean;
|
||||
camera_active: boolean;
|
||||
mode: 'fusion' | 'csi_only' | 'camera_only';
|
||||
fps: number;
|
||||
gesture_count: number; // Total gestures detected this session
|
||||
}
|
||||
```
|
||||
|
||||
### Training the CSI Gesture Model
|
||||
|
||||
Extends ADR-079's camera ground-truth pipeline:
|
||||
|
||||
```bash
|
||||
# 1. Collect gesture training data (camera + CSI, 10 min)
|
||||
# Perform each gesture 20+ times with natural variation
|
||||
python scripts/collect-gesture-gt.py --duration 600 --gestures all --preview
|
||||
|
||||
# 2. Label gesture segments (auto-detected from camera)
|
||||
node scripts/label-gestures.js \
|
||||
--gt data/ground-truth/gestures-*.jsonl \
|
||||
--csi data/recordings/csi-*.jsonl
|
||||
|
||||
# 3. Train gesture classifier
|
||||
node scripts/train-gesture-model.js \
|
||||
--data data/gestures/labeled-*.jsonl \
|
||||
--scale lite
|
||||
|
||||
# 4. Deploy
|
||||
# CSI-only mode: gestures detected from WiFlow keypoint motion
|
||||
# Fusion mode: camera adds finger-level precision
|
||||
```
|
||||
|
||||
**Training data per gesture:** ~20 examples × 11 gestures = 220 labeled samples.
|
||||
With augmentation (time warp, amplitude noise): ~1,000 effective samples.
|
||||
|
||||
### Optimization: ruvector-cnn Spectrogram Gesture Classification
|
||||
|
||||
Replace DTW template matching with a CNN operating on CSI spectrograms via the
|
||||
`ruvector-cnn` WASM package (ADR-076). This treats each gesture as an image
|
||||
classification problem on the CSI time-frequency representation.
|
||||
|
||||
#### Why CNN Over DTW
|
||||
|
||||
| | DTW (current, ADR-029) | CNN Spectrogram (proposed) |
|
||||
|---|---|---|
|
||||
| Input | 1D keypoint trajectories | 2D CSI spectrogram image |
|
||||
| Features | Hand-crafted (wrist velocity, elbow angle) | Learned end-to-end |
|
||||
| Robustness | Sensitive to speed variation | Warp-invariant (pooling layers) |
|
||||
| Multi-scale | Single scale | Hierarchical (dilated convolutions) |
|
||||
| Training | Template recording + DTW distance | Supervised from camera labels |
|
||||
| New gestures | Record new template | Retrain (or few-shot with embedding) |
|
||||
| Accuracy | ~85% (DTW literature) | ~95%+ (CNN on spectrograms, literature) |
|
||||
|
||||
#### Pipeline
|
||||
|
||||
```
|
||||
CSI [N_subcarriers, T=30] (1-second window)
|
||||
↓
|
||||
Spectrogram transform: STFT per subcarrier
|
||||
→ [N_sub, F_bins, T_bins] ≈ [35, 16, 15]
|
||||
↓
|
||||
Reshape to grayscale image: [35×16, 15] = [560, 15]
|
||||
→ Resize to [64, 64] (bilinear)
|
||||
↓
|
||||
ruvector-cnn CnnEmbedder (WASM-accelerated)
|
||||
→ 128-dim gesture embedding
|
||||
↓
|
||||
Classifier head: Linear(128 → 18 gestures) + softmax
|
||||
→ gesture_id + confidence
|
||||
```
|
||||
|
||||
#### ruvector-cnn Integration
|
||||
|
||||
The `@ruvector/cnn` WASM package provides:
|
||||
|
||||
```javascript
|
||||
const { init, CnnEmbedder, InfoNCELoss } = require('@ruvector/cnn');
|
||||
await init();
|
||||
|
||||
// Create embedder for 64x64 CSI spectrogram "images"
|
||||
const embedder = new CnnEmbedder({
|
||||
inputSize: 64,
|
||||
embeddingDim: 128,
|
||||
normalize: true,
|
||||
});
|
||||
|
||||
// Extract embedding from CSI spectrogram
|
||||
const spectrogram = csiToSpectrogram(csiWindow); // [64, 64] Uint8Array
|
||||
const embedding = embedder.extract(spectrogram, 64, 64);
|
||||
|
||||
// Classify gesture via nearest-neighbor to trained templates
|
||||
const gesture = classifyGesture(embedding, gestureTemplates);
|
||||
```
|
||||
|
||||
#### Training with Contrastive + Classification
|
||||
|
||||
Two-phase training using ruvector-cnn's built-in losses:
|
||||
|
||||
**Phase 1: Contrastive embedding (unsupervised)**
|
||||
```javascript
|
||||
const loss = new InfoNCELoss(0.07);
|
||||
// Same gesture performed at different speeds → positive pairs
|
||||
// Different gestures → negative pairs
|
||||
// Train CnnEmbedder to cluster same-gesture spectrograms
|
||||
```
|
||||
|
||||
**Phase 2: Gesture classification (supervised)**
|
||||
```javascript
|
||||
// Linear classifier on frozen embeddings
|
||||
// 18 gestures × 20 examples each = 360 labeled samples
|
||||
// Camera auto-labels: MediaPipe Hands detects gesture type
|
||||
```
|
||||
|
||||
#### Dual-Path Architecture
|
||||
|
||||
Run both CNN and DTW in parallel for maximum robustness:
|
||||
|
||||
```
|
||||
CSI input ──┬──→ WiFlow → keypoints → DTW templates → gesture_A (conf_A)
|
||||
│
|
||||
└──→ Spectrogram → ruvector-cnn → embedding → classifier → gesture_B (conf_B)
|
||||
|
||||
Fusion: if gesture_A == gesture_B → conf = max(conf_A, conf_B) + 0.15
|
||||
if conflict → pick higher confidence
|
||||
if only one detects → use it at 0.8× confidence
|
||||
```
|
||||
|
||||
This dual-path approach provides:
|
||||
- **DTW** catches gestures the CNN might miss (novel variations)
|
||||
- **CNN** provides higher accuracy for trained gesture types
|
||||
- **Fusion** reduces false positives (both must agree for high-confidence)
|
||||
|
||||
### Optimization: Temporal Gesture Encoding
|
||||
|
||||
Alternative lightweight path for when ruvector-cnn WASM overhead matters
|
||||
(e.g., ESP32 edge deployment):
|
||||
|
||||
```
|
||||
Keypoint sequence [T=30 frames, 1 second]:
|
||||
wrist_x[0..29], wrist_y[0..29],
|
||||
elbow_angle[0..29],
|
||||
hand_velocity[0..29]
|
||||
↓
|
||||
1D CNN (k=5, d=[1,2,4]) → 64-dim gesture embedding
|
||||
↓
|
||||
Nearest-neighbor to gesture templates (cosine distance)
|
||||
↓
|
||||
Top gesture + confidence
|
||||
```
|
||||
|
||||
This is lighter than DTW for real-time use and can be trained end-to-end with
|
||||
the WiFlow backbone (shared TCN features).
|
||||
|
||||
## File Structure
|
||||
|
||||
```
|
||||
scripts/
|
||||
collect-gesture-gt.py # Camera + CSI gesture data collection
|
||||
label-gestures.js # Auto-label gesture segments from camera
|
||||
train-gesture-model.js # Train CSI gesture classifier
|
||||
gesture-server.js # WebSocket gesture detection server
|
||||
|
||||
ui/
|
||||
components/
|
||||
GestureOverlay.js # Cursor + feedback overlay
|
||||
GestureChart.js # Gesture-controlled chart wrapper
|
||||
GestureStatus.js # Sensor health bar
|
||||
services/
|
||||
gesture.service.js # WebSocket client for gesture events
|
||||
```
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- **Hands-free data exploration** — manipulate charts without touching anything
|
||||
- **Works in dark/dirty/gloved conditions** — CSI-only mode needs no camera
|
||||
- **Natural interaction** — swipe, pinch, point are intuitive
|
||||
- **Builds on existing infrastructure** — WiFlow + DTW + MediaPipe all exist
|
||||
- **Dual-mode deployment** — degrade gracefully from fusion to CSI-only
|
||||
- **Low latency** — WiFlow inference is 0.79ms, gesture detection adds ~5ms
|
||||
|
||||
### Negative
|
||||
|
||||
- **Learning curve** — users must learn gesture vocabulary
|
||||
- **False positives** — normal movement may trigger gestures (mitigated by state machine + cooldown)
|
||||
- **CSI-only precision** — coarse gestures only without camera
|
||||
- **Single-user** — multi-user gesture disambiguation is hard
|
||||
|
||||
### Risks
|
||||
|
||||
| Risk | Probability | Impact | Mitigation |
|
||||
|------|-------------|--------|------------|
|
||||
| Gesture false positives from normal movement | Medium | High | State machine with IDLE→TRACKING threshold, 200ms debounce, 0.7 confidence gate |
|
||||
| CSI gestures too coarse for chart control | Medium | Medium | Camera fallback for precision; CSI handles navigation-level gestures only |
|
||||
| Latency > 100ms feels unresponsive | Low | High | WiFlow 0.79ms + gesture 5ms + WebSocket <10ms = ~16ms total |
|
||||
| User fatigue ("gorilla arm") | Medium | Medium | Support seated gestures; small wrist movements, not full arm sweeps |
|
||||
| MediaPipe Hands not detecting in low light | Medium | Low | CSI-only fallback; works in complete darkness |
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
| Phase | Task | Effort | Dependencies |
|
||||
|-------|------|--------|-------------|
|
||||
| P1 | `gesture-server.js` — WebSocket server with camera hand tracking | 3 hrs | MediaPipe Hands model |
|
||||
| P2 | Camera gesture classifier (rule-based from hand landmarks) | 2 hrs | P1 |
|
||||
| P3 | CSI gesture classifier (WiFlow keypoints → DTW templates) | 3 hrs | WiFlow model (ADR-079) |
|
||||
| P4 | Fusion engine (confidence-weighted merge) | 2 hrs | P2 + P3 |
|
||||
| P5 | `GestureOverlay.js` — cursor + feedback UI component | 2 hrs | P1 |
|
||||
| P6 | `GestureChart.js` — gesture-controlled D3 chart wrapper | 4 hrs | P4 + P5 |
|
||||
| P7 | Gesture training data collection + model training | 2 hrs | P3 |
|
||||
| P8 | Integration with existing sensing UI | 2 hrs | P6 |
|
||||
| **Total** | | **~20 hrs** | |
|
||||
|
||||
## References
|
||||
|
||||
- MediaPipe Hands — Google's 21-landmark hand tracking (30fps, CPU)
|
||||
- ADR-029 — RuvSense DTW gesture recognition
|
||||
- ADR-079 — Camera ground-truth training pipeline (92.9% PCK@20)
|
||||
- Leap Motion — commercial gesture controller (comparison point)
|
||||
- SolidJS/D3 gesture interaction patterns
|
||||
- "GestureWiFi" (IEEE 2023) — WiFi gesture recognition survey
|
||||
@@ -31,7 +31,7 @@ All firmware paths are relative to the repository root. Rust crate paths are rel
|
||||
| **Core 0 / Core 1** | The two Xtensa LX7 cores on ESP32-S3; Core 0 runs WiFi + CSI callback, Core 1 runs the DSP pipeline |
|
||||
| **SPSC Ring Buffer** | Single-producer single-consumer lock-free queue between Core 0 (CSI callback) and Core 1 (DSP task) |
|
||||
| **Vitals Packet** | 32-byte UDP packet (magic `0xC5110002`) containing presence, breathing BPM, heart rate BPM, fall flag |
|
||||
| **Compressed Frame** | Delta-compressed CSI frame (magic `0xC5110005`, reassigned from `0xC5110003` by ADR-069) using XOR + RLE for 30-50% bandwidth reduction |
|
||||
| **Compressed Frame** | Delta-compressed CSI frame (magic `0xC5110003`) using XOR + RLE for 30-50% bandwidth reduction |
|
||||
| **WASM Module** | A `no_std` Rust program compiled to `wasm32-unknown-unknown`, executed on-device via WASM3 interpreter |
|
||||
| **Module Slot** | One of 4 pre-allocated PSRAM arenas (160 KB each) that host a WASM module instance |
|
||||
| **Host API** | 12 functions in the `csi` namespace that WASM modules call to read sensor data and emit events |
|
||||
@@ -158,7 +158,7 @@ All firmware paths are relative to the repository root. Rust crate paths are rel
|
||||
| +------------------+--------+ |
|
||||
| | Multi-Person Clustering | |
|
||||
| | (subcarrier groups, <=4) |----> VitalsPacket (0xC5110002) |
|
||||
| +---------------------------+----> CompressedFrame (0xC5110005)|
|
||||
| +---------------------------+----> CompressedFrame (0xC5110003)|
|
||||
| |
|
||||
+--------------------------------------------------------------+
|
||||
```
|
||||
@@ -1197,7 +1197,7 @@ pub trait ProvisioningService {
|
||||
| Sensor Node | Edge Processing | **Partnership** | Tightly coupled via SPSC ring buffer on the same chip |
|
||||
| Edge Processing | WASM Runtime | **Customer/Supplier** | Edge pipeline feeds CSI data to WASM modules via Host API |
|
||||
| Sensor Node | Aggregation | **Published Language** | ADR-018 binary wire format (magic bytes, fixed offsets) |
|
||||
| Edge Processing | Aggregation | **Published Language** | Vitals (0xC5110002), compressed (0xC5110005), and feature vectors (0xC5110003) wire formats |
|
||||
| Edge Processing | Aggregation | **Published Language** | Vitals (0xC5110002) and compressed (0xC5110003) wire formats |
|
||||
| WASM Runtime | Aggregation | **Published Language** | WASM events (0xC5110004) wire format |
|
||||
| Aggregation | Downstream crates | **Customer/Supplier** | Aggregator produces `FusedFrame` consumed by signal/nn/mat |
|
||||
|
||||
@@ -1223,8 +1223,7 @@ impl Esp32ToPipelineAdapter {
|
||||
/// Handles magic byte demuxing:
|
||||
/// 0xC5110001 -> raw CSI frame
|
||||
/// 0xC5110002 -> vitals packet
|
||||
/// 0xC5110003 -> feature vector (ADR-069, 48-byte 8-dim)
|
||||
/// 0xC5110005 -> compressed frame (decompress first)
|
||||
/// 0xC5110003 -> compressed frame (decompress first)
|
||||
/// 0xC5110004 -> WASM event packet
|
||||
pub fn parse_datagram(
|
||||
&self,
|
||||
@@ -1307,9 +1306,8 @@ All ESP32 UDP packets share a 4-byte magic prefix for demuxing at the aggregator
|
||||
|-------|------|--------|------|------|-------------|
|
||||
| `0xC5110001` | Raw CSI | Tier 0+ | ~128-404 B | 20-28.5 Hz | Full I/Q per subcarrier |
|
||||
| `0xC5110002` | Vitals | Tier 2+ | 32 B | 1 Hz (configurable) | Presence, BPM, fall flag |
|
||||
| `0xC5110003` | Feature Vector | Tier 2+ | 48 B | 1 Hz | ADR-069 8-dim normalized features for Cognitum Seed RVF ingest |
|
||||
| `0xC5110003` | Compressed | Tier 1+ | variable | 20-28.5 Hz | XOR+RLE delta-compressed CSI |
|
||||
| `0xC5110004` | WASM Events | Tier 3 | variable | event-driven | Module event_type + value tuples |
|
||||
| `0xC5110005` | Compressed | Tier 1+ | variable | 20-28.5 Hz | XOR+RLE delta-compressed CSI (reassigned from 0xC5110003) |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,336 +0,0 @@
|
||||
---
|
||||
license: mit
|
||||
tags:
|
||||
- wifi-sensing
|
||||
- pose-estimation
|
||||
- vital-signs
|
||||
- edge-ai
|
||||
- esp32
|
||||
- onnx
|
||||
- self-supervised
|
||||
- cognitum
|
||||
- csi
|
||||
- through-wall
|
||||
- privacy-preserving
|
||||
language:
|
||||
- en
|
||||
library_name: onnxruntime
|
||||
pipeline_tag: other
|
||||
---
|
||||
|
||||
# WiFi-DensePose: See Through Walls with WiFi + AI
|
||||
|
||||
**Detect people, track movement, and measure breathing -- through walls, without cameras, using a $27 sensor kit.**
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **License** | MIT |
|
||||
| **Framework** | ONNX Runtime |
|
||||
| **Hardware** | ESP32-S3 ($9) + optional Cognitum Seed ($15) |
|
||||
| **Training** | Self-supervised contrastive learning (no labels needed) |
|
||||
| **Privacy** | No cameras, no images, no personally identifiable data |
|
||||
|
||||
---
|
||||
|
||||
## What is this?
|
||||
|
||||
This model turns ordinary WiFi signals into a human sensing system. It can detect whether someone is in a room, count how many people are present, classify what they are doing, and even measure their breathing rate -- all without any cameras.
|
||||
|
||||
**How does it work?** Every WiFi router constantly sends signals that bounce off walls, furniture, and people. When a person moves -- or even just breathes -- those bouncing signals change in tiny but measurable ways. WiFi chips can capture these changes as numbers called *Channel State Information* (CSI). Think of it like ripples in a pond: drop a stone and the ripples tell you something happened, even if you cannot see the stone.
|
||||
|
||||
This model learned to read those "WiFi ripples" and figure out what is happening in the room. It was trained using a technique called *contrastive learning*, which means it taught itself by comparing thousands of WiFi signal snapshots -- no human had to manually label anything.
|
||||
|
||||
The result is a small, fast model that runs on a $9 microcontroller and preserves complete privacy because it never captures images or audio.
|
||||
|
||||
---
|
||||
|
||||
## What can it do?
|
||||
|
||||
| Capability | Accuracy | What you need | Notes |
|
||||
|---|---|---|---|
|
||||
| **Presence detection** | >95% | 1x ESP32-S3 ($9) | Is anyone in the room? |
|
||||
| **Motion classification** | >90% | 1x ESP32-S3 ($9) | Still, walking, exercising, fallen |
|
||||
| **Breathing rate** | +/- 2 BPM | 1x ESP32-S3 ($9) | Best when person is sitting or lying still |
|
||||
| **Heart rate estimate** | +/- 5 BPM | 1x ESP32-S3 ($9) | Experimental -- less accurate during movement |
|
||||
| **Person counting** | 1-4 people | 2x ESP32-S3 ($18) | Uses cross-node signal fusion |
|
||||
| **Pose estimation** | 17 COCO keypoints | 2x ESP32-S3 + Seed ($27) | Full skeleton: head, shoulders, elbows, etc. |
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
### Install
|
||||
|
||||
```bash
|
||||
pip install onnxruntime numpy
|
||||
```
|
||||
|
||||
### Run inference
|
||||
|
||||
```python
|
||||
import onnxruntime as ort
|
||||
import numpy as np
|
||||
|
||||
# Load the encoder model
|
||||
session = ort.InferenceSession("pretrained-encoder.onnx")
|
||||
|
||||
# Simulated 8-dim CSI feature vector from ESP32-S3
|
||||
# Dimensions: [amplitude_mean, amplitude_std, phase_slope, doppler_energy,
|
||||
# subcarrier_variance, temporal_stability, csi_ratio, spectral_entropy]
|
||||
features = np.array(
|
||||
[[0.45, 0.30, 0.69, 0.75, 0.50, 0.25, 0.00, 0.54]],
|
||||
dtype=np.float32,
|
||||
)
|
||||
|
||||
# Encode into 128-dim embedding
|
||||
result = session.run(None, {"input": features})
|
||||
embedding = result[0] # shape: (1, 128)
|
||||
print(f"Embedding shape: {embedding.shape}")
|
||||
print(f"First 8 values: {embedding[0][:8]}")
|
||||
```
|
||||
|
||||
### Run task heads
|
||||
|
||||
```python
|
||||
# Load the task heads model
|
||||
heads = ort.InferenceSession("pretrained-heads.onnx")
|
||||
|
||||
# Feed the embedding from the encoder
|
||||
predictions = heads.run(None, {"embedding": embedding})
|
||||
|
||||
presence_score = predictions[0] # 0.0 = empty, 1.0 = occupied
|
||||
person_count = predictions[1] # estimated count (float, round to int)
|
||||
activity_class = predictions[2] # [still, walking, exercise, fallen]
|
||||
vitals = predictions[3] # [breathing_bpm, heart_bpm]
|
||||
|
||||
print(f"Presence: {presence_score[0]:.2f}")
|
||||
print(f"People: {int(round(person_count[0]))}")
|
||||
print(f"Activity: {['still', 'walking', 'exercise', 'fallen'][activity_class.argmax()]}")
|
||||
print(f"Breathing: {vitals[0][0]:.1f} BPM")
|
||||
print(f"Heart: {vitals[0][1]:.1f} BPM")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Model Architecture
|
||||
|
||||
```
|
||||
+-- Presence (binary)
|
||||
|
|
||||
WiFi signals --> ESP32-S3 --> 8-dim features --> Encoder (TCN) --> 128-dim embedding --> Task Heads --+-- Person Count
|
||||
(CSI) (on-device) (~2.5M params) (~100K) |
|
||||
+-- Activity (4 classes)
|
||||
|
|
||||
+-- Vitals (BR + HR)
|
||||
```
|
||||
|
||||
### Encoder
|
||||
|
||||
- **Type:** Temporal Convolutional Network (TCN)
|
||||
- **Input:** 8-dimensional feature vector extracted from raw CSI
|
||||
- **Output:** 128-dimensional embedding
|
||||
- **Parameters:** ~2.5M
|
||||
- **Format:** ONNX (runs on any platform with ONNX Runtime)
|
||||
|
||||
### Task Heads
|
||||
|
||||
- **Type:** Small MLPs (multi-layer perceptrons), one per task
|
||||
- **Input:** 128-dim embedding from the encoder
|
||||
- **Output:** Task-specific predictions (presence, count, activity, vitals)
|
||||
- **Parameters:** ~100K total across all heads
|
||||
- **Format:** ONNX
|
||||
|
||||
### Feature extraction (runs on ESP32-S3)
|
||||
|
||||
The ESP32-S3 captures raw CSI frames at ~100 Hz and computes 8 summary features per window:
|
||||
|
||||
| Feature | Description |
|
||||
|---|---|
|
||||
| `amplitude_mean` | Average signal strength across subcarriers |
|
||||
| `amplitude_std` | Variation in signal strength (movement indicator) |
|
||||
| `phase_slope` | Rate of phase change across subcarriers |
|
||||
| `doppler_energy` | Energy in the Doppler spectrum (velocity indicator) |
|
||||
| `subcarrier_variance` | How much individual subcarriers differ |
|
||||
| `temporal_stability` | Consistency of signal over time (stillness indicator) |
|
||||
| `csi_ratio` | Ratio between antenna pairs (direction indicator) |
|
||||
| `spectral_entropy` | Randomness of the frequency spectrum |
|
||||
|
||||
---
|
||||
|
||||
## Training Data
|
||||
|
||||
### How it was trained
|
||||
|
||||
This model was trained using **self-supervised contrastive learning**, which means it learned entirely from unlabeled WiFi signals. No cameras, no manual annotations, and no privacy-invasive data collection were needed.
|
||||
|
||||
The training process works like this:
|
||||
|
||||
1. **Collect** raw CSI frames from ESP32-S3 nodes placed in a room
|
||||
2. **Extract** 8-dimensional feature vectors from sliding windows of CSI data
|
||||
3. **Contrast** -- the model learns that features from nearby time windows should produce similar embeddings, while features from different scenarios should produce different embeddings
|
||||
4. **Fine-tune** task heads using weak labels from environmental sensors (PIR motion, temperature, pressure) on the Cognitum Seed companion device
|
||||
|
||||
### Data provenance
|
||||
|
||||
- **Source:** Live CSI from 2x ESP32-S3 nodes (802.11n, HT40, 114 subcarriers)
|
||||
- **Volume:** ~360,000 CSI frames (~3,600 feature vectors) per collection run
|
||||
- **Environment:** Residential room, ~4x5 meters
|
||||
- **Ground truth:** Environmental sensors on Cognitum Seed (PIR, BME280, light)
|
||||
- **Attestation:** Every collection run produces a cryptographic witness chain (`collection-witness.json`) that proves data provenance and integrity
|
||||
|
||||
### Witness chain
|
||||
|
||||
The `collection-witness.json` file contains a chain of SHA-256 hashes linking every step from raw CSI capture through feature extraction to model training. This allows anyone to verify that the published model was trained on data collected by specific hardware at a specific time.
|
||||
|
||||
---
|
||||
|
||||
## Hardware Requirements
|
||||
|
||||
### Minimum: single-node sensing ($9)
|
||||
|
||||
| Component | What it does | Cost | Where to get it |
|
||||
|---|---|---|---|
|
||||
| ESP32-S3 (8MB flash) | Captures WiFi CSI + runs feature extraction | ~$9 | Amazon, AliExpress, Adafruit |
|
||||
| USB-C cable | Power + data | ~$3 | Any electronics store |
|
||||
|
||||
This gets you: presence detection, motion classification, breathing rate.
|
||||
|
||||
### Recommended: dual-node sensing ($18)
|
||||
|
||||
Add a second ESP32-S3 to enable cross-node signal fusion for better accuracy and person counting.
|
||||
|
||||
### Full setup: sensing + ground truth ($27)
|
||||
|
||||
| Component | What it does | Cost |
|
||||
|---|---|---|
|
||||
| 2x ESP32-S3 (8MB) | WiFi CSI sensing nodes | ~$18 |
|
||||
| Cognitum Seed (Pi Zero 2W) | Runs inference + collects ground truth | ~$15 |
|
||||
| USB-C cables (x3) | Power + data | ~$9 |
|
||||
| **Total** | | **~$27** |
|
||||
|
||||
The Cognitum Seed runs the ONNX models on-device, orchestrates the ESP32 nodes over USB serial, and provides environmental ground truth via its onboard PIR and BME280 sensors.
|
||||
|
||||
---
|
||||
|
||||
## Files in this repo
|
||||
|
||||
| File | Size | Description |
|
||||
|---|---|---|
|
||||
| `pretrained-encoder.onnx` | ~2 MB | Contrastive encoder (TCN backbone, 8-dim input, 128-dim output) |
|
||||
| `pretrained-heads.onnx` | ~100 KB | Task heads (presence, count, activity, vitals) |
|
||||
| `pretrained.rvf` | ~500 KB | RuVector format embeddings for advanced fusion pipelines |
|
||||
| `room-profiles.json` | ~10 KB | Environment calibration profiles (room geometry, baseline noise) |
|
||||
| `collection-witness.json` | ~5 KB | Cryptographic witness chain proving data provenance |
|
||||
| `config.json` | ~2 KB | Training configuration (hyperparameters, feature schema, versions) |
|
||||
| `README.md` | -- | This file |
|
||||
|
||||
### RuVector format (.rvf)
|
||||
|
||||
The `.rvf` file contains pre-computed embeddings in RuVector format, used by the RuView application for advanced multi-node fusion and cross-viewpoint pose estimation. You only need this if you are using the full RuView pipeline. For basic inference, the ONNX files are sufficient.
|
||||
|
||||
---
|
||||
|
||||
## How to use with RuView
|
||||
|
||||
[RuView](https://github.com/ruvnet/RuView) is the open-source application that ties everything together: firmware flashing, real-time sensing, and a browser-based dashboard.
|
||||
|
||||
### 1. Flash firmware to ESP32-S3
|
||||
|
||||
```bash
|
||||
git clone https://github.com/ruvnet/RuView.git
|
||||
cd RuView
|
||||
|
||||
# Flash firmware (requires ESP-IDF v5.4 or use pre-built binaries from Releases)
|
||||
# See the repo README for platform-specific instructions
|
||||
```
|
||||
|
||||
### 2. Download models
|
||||
|
||||
```bash
|
||||
pip install huggingface_hub
|
||||
huggingface-cli download ruvnet/wifi-densepose-pretrained --local-dir models/
|
||||
```
|
||||
|
||||
### 3. Run inference
|
||||
|
||||
```bash
|
||||
# Start the CSI bridge (connects ESP32 serial output to the inference pipeline)
|
||||
python scripts/seed_csi_bridge.py --port COM7 --model models/pretrained-encoder.onnx
|
||||
|
||||
# Or run the full sensing server with web dashboard
|
||||
cargo run -p wifi-densepose-sensing-server
|
||||
```
|
||||
|
||||
### 4. Adapt to your room
|
||||
|
||||
The model works best after a brief calibration period (~60 seconds of no movement) to learn the baseline signal characteristics of your specific room. The `room-profiles.json` file contains example profiles; the system will create one for your environment automatically.
|
||||
|
||||
---
|
||||
|
||||
## Limitations
|
||||
|
||||
Be honest about what this technology can and cannot do:
|
||||
|
||||
- **Room-specific.** The model needs a short calibration period in each new environment. A model calibrated in a living room will not work as well in a warehouse without re-adaptation.
|
||||
- **Single room only.** There is no cross-room tracking. Each room needs its own sensing node(s).
|
||||
- **Person count accuracy degrades above 4.** Counting works well for 1-3 people, becomes unreliable above 4 in a single room.
|
||||
- **Vitals require stillness.** Breathing and heart rate estimation work best when the person is sitting or lying down. Accuracy drops significantly during walking or exercise.
|
||||
- **Heart rate is experimental.** The +/- 5 BPM accuracy is a best-case figure. In practice, cardiac sensing via WiFi is still a research-stage capability.
|
||||
- **Wall materials matter.** Metal walls, concrete reinforced with rebar, or foil-backed insulation will significantly attenuate the signal and reduce range.
|
||||
- **WiFi interference.** Heavy WiFi traffic from other devices can add noise. The system works best on a dedicated or lightly-used WiFi channel.
|
||||
- **Not a medical device.** Vital sign estimates are for informational and research purposes only. Do not use them for medical decisions.
|
||||
|
||||
---
|
||||
|
||||
## Use Cases
|
||||
|
||||
- **Elder care:** Non-invasive fall detection and activity monitoring without cameras
|
||||
- **Smart home:** Presence-based lighting and HVAC control
|
||||
- **Security:** Occupancy detection through walls
|
||||
- **Sleep monitoring:** Breathing rate tracking overnight
|
||||
- **Research:** Low-cost human sensing for academic experiments
|
||||
- **Disaster response:** The MAT (Mass Casualty Assessment Tool) uses this model to detect survivors through rubble via WiFi signal reflections
|
||||
|
||||
---
|
||||
|
||||
## Ethical Considerations
|
||||
|
||||
WiFi sensing is a privacy-preserving alternative to cameras, but it still detects human presence and activity. Consider these points:
|
||||
|
||||
- **Consent:** Always inform people that WiFi sensing is active in a space.
|
||||
- **No biometric identification:** This model cannot identify *who* someone is -- only that someone is present and what they are doing.
|
||||
- **Data minimization:** Raw CSI data is processed on-device and only summary features or embeddings leave the sensor. No images, audio, or video are ever captured.
|
||||
- **Dual use:** Like any sensing technology, this can be misused for surveillance. We encourage transparent deployment and clear signage.
|
||||
|
||||
---
|
||||
|
||||
## Citation
|
||||
|
||||
If you use this model in your research, please cite:
|
||||
|
||||
```bibtex
|
||||
@software{wifi_densepose_2026,
|
||||
title = {WiFi-DensePose: Human Pose Estimation from WiFi Channel State Information},
|
||||
author = {ruvnet},
|
||||
year = {2026},
|
||||
url = {https://github.com/ruvnet/RuView},
|
||||
license = {MIT},
|
||||
note = {Self-supervised contrastive learning on ESP32-S3 CSI data}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## License
|
||||
|
||||
MIT License. See [LICENSE](https://github.com/ruvnet/RuView/blob/main/LICENSE) for details.
|
||||
|
||||
You are free to use, modify, and distribute this model for any purpose, including commercial applications.
|
||||
|
||||
---
|
||||
|
||||
## Links
|
||||
|
||||
- **GitHub:** [github.com/ruvnet/RuView](https://github.com/ruvnet/RuView)
|
||||
- **Hardware:** [ESP32-S3 DevKit](https://www.espressif.com/en/products/devkits) | [Cognitum Seed](https://cognitum.one)
|
||||
- **ONNX Runtime:** [onnxruntime.ai](https://onnxruntime.ai)
|
||||
@@ -1,315 +0,0 @@
|
||||
# QE Queen Summary Report -- wifi-densepose
|
||||
|
||||
**Date:** 2026-04-05
|
||||
**Fleet ID:** fleet-02558e91
|
||||
**Orchestrator:** QE Queen Coordinator (ADR-001)
|
||||
**Domains Activated:** test-generation, coverage-analysis, quality-assessment, security-compliance, defect-intelligence
|
||||
|
||||
---
|
||||
|
||||
## 1. Project Scope and Quality Posture Overview
|
||||
|
||||
### 1.1 Codebase Dimensions
|
||||
|
||||
| Language / Layer | Files | Lines of Code | Purpose |
|
||||
|------------------|-------|---------------|---------|
|
||||
| Rust (.rs) | 379 | 153,139 | Core workspace -- 19 crates (16 in workspace, 3 excluded/auxiliary) |
|
||||
| Python (.py) | 105 | 38,656 | v1 implementation -- API, services, sensing, hardware, middleware |
|
||||
| C/H (firmware) | 48 | 9,445 | ESP32 CSI node firmware -- collectors, OTA, WASM runtime |
|
||||
| TypeScript/TSX (mobile) | 48 | 7,571 | React Native mobile app -- screens, stores, services |
|
||||
| JavaScript (UI) | ~117 | 25,798 | Web observatory UI, components, utilities |
|
||||
| Markdown (docs) | ~79+ | 70,539 | 79 ADRs, user guides, research, witness logs |
|
||||
| **Total** | **~776** | **~305,148** | |
|
||||
|
||||
### 1.2 Architecture Summary
|
||||
|
||||
The project implements WiFi-based human pose estimation using Channel State Information (CSI). It is structured as a multi-language, multi-platform system:
|
||||
|
||||
- **Rust workspace** (v0.3.0): 16 crates in workspace plus `wifi-densepose-wasm-edge` (excluded for `wasm32` target) and `ruv-neural` (auxiliary). Covers signal processing (RuvSense with 14 modules), neural inference (ONNX/PyTorch/Candle), mass casualty assessment (MAT), cross-viewpoint fusion (RuVector v2.0.4), hardware TDM protocol, and web APIs.
|
||||
- **Python v1**: Original implementation with 12 source modules covering API endpoints, CSI extraction, pose services, sensing, database, and middleware.
|
||||
- **ESP32 firmware**: C code for real WiFi CSI collection, edge processing, OTA updates, mmWave sensor integration, WASM runtime, and swarm bridging.
|
||||
- **Mobile UI**: React Native app with pose visualization, MAT screens, vitals monitoring, and RSSI scanning.
|
||||
- **Web observatory**: Three.js-based visualization for RF sensing, phase constellations, and subcarrier manifolds.
|
||||
|
||||
### 1.3 Governance and Process Maturity
|
||||
|
||||
| Indicator | Status | Details |
|
||||
|-----------|--------|---------|
|
||||
| Architecture Decision Records | Strong | 79 ADRs documented in `docs/adr/` |
|
||||
| CI/CD pipelines | Strong | 8 GitHub Actions workflows (CI, CD, security scan, firmware CI, QEMU, desktop release, verify pipeline, submodules) |
|
||||
| Security scanning | Strong | Dedicated `security-scan.yml` with Bandit, Semgrep, Safety; runs daily on schedule |
|
||||
| Deterministic verification | Strong | SHA-256 proof pipeline (`v1/data/proof/verify.py`) with witness bundles (ADR-028) |
|
||||
| Code formatting | Moderate | Black/Flake8 enforced for Python in CI; no `rustfmt.toml` found for Rust |
|
||||
| Type checking | Moderate | MyPy configured in CI for Python; Rust has native type safety |
|
||||
| Dependency management | Strong | Workspace-level Cargo.toml with pinned versions; `requirements.txt` for Python |
|
||||
|
||||
---
|
||||
|
||||
## 2. Test Pyramid Health
|
||||
|
||||
### 2.1 Overall Test Inventory
|
||||
|
||||
| Test Layer | Rust | Python | Mobile (TS) | Firmware (C) | Total |
|
||||
|------------|------|--------|-------------|--------------|-------|
|
||||
| Unit tests | 2,618 `#[test]` | 322 functions / 15 files | 202 test cases / 25 files | 0 | **3,142** |
|
||||
| Integration tests | 16 files / 7 crates | 132 functions / 11 files | 0 | 0 | **148+ functions** |
|
||||
| E2E tests | 0 | 8 functions / 1 file | 0 | 0 | **8 functions** |
|
||||
| Performance tests | 0 | 26 functions / 2 files | 0 | 0 | **26 functions** |
|
||||
| Fuzz tests | 0 | 0 | 0 | 3 files (harnesses) | **3 harnesses** |
|
||||
| **Subtotal** | **~2,634** | **~488** | **~202** | **3** | **~3,327** |
|
||||
|
||||
### 2.2 Test Pyramid Shape Analysis
|
||||
|
||||
```
|
||||
Ideal Pyramid Actual Shape Assessment
|
||||
|
||||
/\ /\
|
||||
/E2E\ / 8 \ E2E: CRITICALLY THIN
|
||||
/------\ /----\
|
||||
/ Integ. \ / 148 \ Integration: THIN
|
||||
/----------\ /--------\
|
||||
/ Unit \ / 3,142 \ Unit: HEALTHY base
|
||||
-------------- --------------
|
||||
```
|
||||
|
||||
**Pyramid Ratio (unit : integration : e2e):**
|
||||
- Actual: **394 : 19 : 1**
|
||||
- Healthy target: **70 : 20 : 10** (percentage)
|
||||
- Actual percentage: **95.3% : 4.5% : 0.2%**
|
||||
|
||||
**Verdict:** The pyramid is severely bottom-heavy. Unit tests are plentiful (good), but integration and E2E layers are dangerously thin relative to the project's complexity. For a multi-crate, multi-service system with hardware integration, the integration layer should be 3-4x larger, and E2E should be 10-20x larger.
|
||||
|
||||
### 2.3 Rust Test Distribution by Crate
|
||||
|
||||
| Crate | Source Lines | Test Count | Tests per 1K LOC | Integration Tests | Assessment |
|
||||
|-------|-------------|------------|-------------------|-------------------|------------|
|
||||
| wifi-densepose-wasm-edge | 28,888 | 643 | 22.3 | 3 files | Good |
|
||||
| wifi-densepose-signal | 16,194 | 370 | 22.8 | 1 file | Good |
|
||||
| ruv-neural | ~558 (test-only) | 364 | N/A | 1 file | Test-only crate |
|
||||
| wifi-densepose-train | 10,562 | 299 | 28.3 | 6 files | Strong |
|
||||
| wifi-densepose-sensing-server | 17,825 | 274 | 15.4 | 3 files | Moderate |
|
||||
| wifi-densepose-mat | 19,572 | 159 | 8.1 | 1 file | Needs improvement |
|
||||
| wifi-densepose-wifiscan | 5,779 | 150 | 26.0 | 0 | Unit only |
|
||||
| wifi-densepose-hardware | 4,005 | 106 | 26.5 | 0 | Unit only |
|
||||
| wifi-densepose-ruvector | 4,629 | 106 | 22.9 | 0 | Unit only |
|
||||
| wifi-densepose-vitals | 1,863 | 52 | 27.9 | 0 | Unit only |
|
||||
| wifi-densepose-desktop | 3,309 | 39 | 11.8 | 1 file | Thin |
|
||||
| wifi-densepose-core | 2,596 | 28 | 10.8 | 0 | Thin for core crate |
|
||||
| wifi-densepose-nn | 2,959 | 23 | 7.8 | 0 | Needs improvement |
|
||||
| wifi-densepose-cli | 1,317 | 5 | 3.8 | 0 | Critically thin |
|
||||
| wifi-densepose-wasm | 1,805 | 0 | 0.0 | 0 | **ZERO tests** |
|
||||
| wifi-densepose-api | 1 (stub) | 0 | N/A | 0 | Stub only |
|
||||
| wifi-densepose-config | 1 (stub) | 0 | N/A | 0 | Stub only |
|
||||
| wifi-densepose-db | 1 (stub) | 0 | N/A | 0 | Stub only |
|
||||
|
||||
### 2.4 Python Test Coverage by Module
|
||||
|
||||
| Source Module | Source Lines | Has Unit Tests | Has Integration Tests | Assessment |
|
||||
|---------------|-------------|----------------|----------------------|------------|
|
||||
| api (13 files) | 3,694 | No | Yes (test_api_endpoints, test_rate_limiting) | Partial |
|
||||
| services (7 files) | 3,038 | No | Yes (test_inference_pipeline) | Partial |
|
||||
| sensing (6 files) | 2,117 | Yes (test_sensing) | Yes (test_streaming_pipeline) | Moderate |
|
||||
| tasks (3 files) | 1,977 | No | No | **ZERO coverage** |
|
||||
| middleware (4 files) | 1,798 | No | No | **ZERO coverage** |
|
||||
| database (5 files) | 1,715 | No | No | **ZERO coverage** |
|
||||
| commands (3 files) | 1,161 | No | No | **ZERO coverage** |
|
||||
| core (4 files) | 1,117 | No (tests focus on CSI extractor from hardware/) | No | **ZERO coverage** |
|
||||
| config (3 files) | 923 | No | No | **ZERO coverage** |
|
||||
| hardware (3 files) | 755 | Yes (test_csi_extractor, test_esp32_binary_parser) | Yes (test_hardware_integration) | Good |
|
||||
| models (3 files) | 578 | No | No | **ZERO coverage** |
|
||||
| testing (3 files) | 500 | No | No | **ZERO coverage** |
|
||||
|
||||
**Key finding:** Python unit tests concentrate heavily on CSI extraction and processing (the hardware layer). 11 of 12 source modules have zero dedicated unit test files. The 322 unit test functions map almost entirely to `hardware/csi_extractor.py` and related signal processing code.
|
||||
|
||||
### 2.5 Mobile UI Test Coverage
|
||||
|
||||
The mobile UI has 25 test files with 202 test cases, covering:
|
||||
- **Stores:** poseStore (21), matStore (18), settingsStore (13) -- good state management coverage
|
||||
- **Components:** SignalBar, GaugeArc, ConnectionBanner, SparklineChart, OccupancyGrid, StatusDot, HudOverlay -- 7 components tested
|
||||
- **Hooks:** useServerReachability, useRssiScanner, usePoseStream -- 3 hooks tested
|
||||
- **Services:** api (14), ws (7), simulation (10), rssi (6) -- good service layer coverage
|
||||
- **Screens:** MAT (4), Live (4), Vitals (5), Zones (6), Settings (6) -- all main screens tested
|
||||
- **Utils:** ringBuffer (20), urlValidator (13), colorMap (9) -- thorough utility testing
|
||||
|
||||
**Assessment:** Mobile testing is the strongest layer relative to its codebase size. Good breadth across stores, components, services, and screens.
|
||||
|
||||
### 2.6 Firmware Test Coverage
|
||||
|
||||
| Test Type | Count | Coverage |
|
||||
|-----------|-------|----------|
|
||||
| Fuzz harnesses | 3 | `fuzz_csi_serialize.c`, `fuzz_edge_enqueue.c`, `fuzz_nvs_config.c` |
|
||||
| Unit tests | 0 | No structured unit testing framework |
|
||||
| Integration tests | 0 | No automated hardware-in-the-loop tests |
|
||||
|
||||
**Assessment:** The firmware has fuzz testing (a positive for security-critical embedded code), but lacks structured unit tests. The 9,445 lines of C code for a safety-relevant embedded system (disaster survivor detection via MAT) warrant stronger test coverage.
|
||||
|
||||
---
|
||||
|
||||
## 3. Cross-Cutting Quality Concerns
|
||||
|
||||
### 3.1 Code Complexity and Maintainability
|
||||
|
||||
| Metric | Value | Threshold | Status |
|
||||
|--------|-------|-----------|--------|
|
||||
| AQE quality score | 37/100 | >70 | FAIL |
|
||||
| Cyclomatic complexity (avg) | 24.09 | <15 | FAIL |
|
||||
| Maintainability index | 24.35 | >50 | FAIL |
|
||||
| Security score | 85/100 | >80 | PASS |
|
||||
|
||||
**Large file risk (>500 lines in Rust src/):**
|
||||
|
||||
| File | Lines | Risk |
|
||||
|------|-------|------|
|
||||
| `sensing-server/src/main.rs` | 4,846 | Monolith risk -- nearly 10x the 500-line guideline |
|
||||
| `sensing-server/src/training_api.rs` | 1,946 | High complexity |
|
||||
| `wasm/src/mat.rs` | 1,673 | Hard to test, 0 tests in crate |
|
||||
| `train/src/metrics.rs` | 1,664 | Complex math, needs exhaustive testing |
|
||||
| `signal/src/ruvsense/pose_tracker.rs` | 1,523 | Critical path, well-tested |
|
||||
| `mat/src/integration/csi_receiver.rs` | 1,401 | Integration boundary |
|
||||
| `mat/src/integration/hardware_adapter.rs` | 1,360 | Hardware boundary, audit needed |
|
||||
|
||||
24 Rust source files exceed 500 lines, violating the project's own `CLAUDE.md` guideline.
|
||||
|
||||
### 3.2 Error Handling Quality (Rust)
|
||||
|
||||
| Pattern | Count | Assessment |
|
||||
|---------|-------|------------|
|
||||
| `Result<>` returns | 450 | Good -- idiomatic error handling in use |
|
||||
| `.unwrap()` calls | 720 | HIGH RISK -- 720 potential panic points in production code |
|
||||
| `.expect()` calls | 35 | Acceptable -- provides context on failure |
|
||||
| `panic!()` calls | 1 | Good -- minimal explicit panics |
|
||||
| `unsafe` blocks | 340 | NEEDS AUDIT -- high count for an application-level project |
|
||||
|
||||
**Critical concern:** The 720 `.unwrap()` calls represent potential runtime panics. In a system processing real-time WiFi CSI data for pose estimation (and mass casualty assessment), an unwrap failure could crash the entire pipeline. Each call should be reviewed and converted to proper error propagation with `?` operator or explicit error handling.
|
||||
|
||||
The 340 `unsafe` blocks are high for a project that is not a systems-level library. These need a focused audit to verify memory safety invariants are upheld, especially in signal processing and hardware interaction code.
|
||||
|
||||
### 3.3 Security Posture
|
||||
|
||||
| Check | Result | Details |
|
||||
|-------|--------|---------|
|
||||
| Hardcoded secrets in Python | 0 found | Clean |
|
||||
| SQL injection risk (f-string SQL) | 0 found | Clean -- likely using parameterized queries |
|
||||
| Python `eval()` usage | 2 calls | Safe -- both are PyTorch `model.eval()` (inference mode), not Python eval |
|
||||
| Firmware buffer overflow risk | 0 `strcpy`/`sprintf` | Clean -- uses safe string functions |
|
||||
| CI security scanning | Active | Bandit, Semgrep, Safety in dedicated workflow, runs daily |
|
||||
| Dependency scanning | Active | Safety checks in CI |
|
||||
|
||||
**Security assessment: GOOD.** The project follows secure coding practices. The dedicated security-scan workflow with daily scheduling is a strong indicator of security maturity. No critical vulnerabilities detected in static analysis patterns.
|
||||
|
||||
### 3.4 Documentation Quality
|
||||
|
||||
| Metric | Value | Assessment |
|
||||
|--------|-------|------------|
|
||||
| Rust `///` doc comments | 11,965 | Strong |
|
||||
| Rust `//!` module docs | 3,512 | Strong |
|
||||
| Rust `pub fn` with docs | 1,781 / 3,912 (45.5%) | Moderate -- 54.5% of public functions lack doc comments |
|
||||
| Python functions with docstrings | ~543 / ~801 (67.8%) | Good |
|
||||
| Python classes with docstrings | ~121 / ~150 (80.7%) | Strong |
|
||||
| ADRs | 79 | Excellent governance |
|
||||
| TODO/FIXME markers | 1 (Python), 0 (Rust) | Clean -- no deferred technical debt markers |
|
||||
|
||||
### 3.5 CI/CD Pipeline Coverage
|
||||
|
||||
| Workflow | Trigger | Scope |
|
||||
|----------|---------|-------|
|
||||
| `ci.yml` | Push/PR to main, develop, feature/* | Python quality (Black, Flake8, MyPy), security (Bandit, Safety) |
|
||||
| `cd.yml` | (deployment) | Production deployment |
|
||||
| `security-scan.yml` | Push/PR + daily cron | SAST with Bandit, Semgrep; dependency scanning with Safety |
|
||||
| `firmware-ci.yml` | Push/PR | ESP32 firmware build verification |
|
||||
| `firmware-qemu.yml` | Push/PR | ESP32 QEMU emulation tests |
|
||||
| `desktop-release.yml` | Release | Desktop application packaging |
|
||||
| `verify-pipeline.yml` | Push/PR | Deterministic proof verification |
|
||||
| `update-submodules.yml` | Manual/scheduled | Git submodule sync |
|
||||
|
||||
**Gap:** No CI workflow runs `cargo test --workspace` for the Rust codebase. The 2,618+ Rust tests appear to run only locally. This is a significant gap -- the largest and most critical codebase has no automated CI test execution.
|
||||
|
||||
---
|
||||
|
||||
## 4. Recommendations Matrix
|
||||
|
||||
| # | Recommendation | Priority | Effort | Impact | Domain |
|
||||
|---|---------------|----------|--------|--------|--------|
|
||||
| R1 | **Add Rust workspace tests to CI** -- Create a GitHub Actions workflow that runs `cargo test --workspace --no-default-features`. The 2,618 Rust tests are the project's primary safety net but run only locally. | CRITICAL | Low (1-2 days) | Very High | CI/CD |
|
||||
| R2 | **Reduce `.unwrap()` calls** -- Audit and convert the 720 `.unwrap()` calls in Rust production code to proper `?` error propagation. Prioritize crates in the real-time pipeline: `signal`, `mat`, `hardware`, `sensing-server`. | CRITICAL | High (2-3 weeks) | Very High | Reliability |
|
||||
| R3 | **Audit `unsafe` blocks** -- Review all 340 `unsafe` blocks. Document safety invariants for each. Consider using `unsafe_code` lint to flag new additions. | CRITICAL | Medium (1-2 weeks) | High | Security |
|
||||
| R4 | **Add Python unit tests for untested modules** -- 11 of 12 Python source modules have zero unit tests. Priority targets: `api/` (3,694 LOC), `services/` (3,038 LOC), `database/` (1,715 LOC), `middleware/` (1,798 LOC). | HIGH | Medium (2-3 weeks) | High | Coverage |
|
||||
| R5 | **Add integration tests for 7 Rust crates** -- `wifi-densepose-core`, `wifi-densepose-hardware`, `wifi-densepose-nn`, `wifi-densepose-ruvector`, `wifi-densepose-vitals`, `wifi-densepose-wifiscan`, `wifi-densepose-cli` have unit tests but no integration test directory. | HIGH | Medium (2 weeks) | High | Coverage |
|
||||
| R6 | **Break up `sensing-server/src/main.rs`** (4,846 lines) -- Extract route handlers, middleware, and configuration into separate modules. This single file is nearly 10x the project's 500-line guideline. | HIGH | Medium (1 week) | Medium | Maintainability |
|
||||
| R7 | **Add E2E tests** -- Only 1 E2E test file exists (`test_healthcare_scenario.py` with 8 tests). For a system with REST API, WebSocket streaming, hardware integration, and mobile clients, E2E coverage is critically insufficient. | HIGH | High (3-4 weeks) | Very High | Coverage |
|
||||
| R8 | **Add tests to `wifi-densepose-wasm`** (1,805 LOC, 0 tests) -- This crate contains MAT WebAssembly bindings used in browser deployment. Zero test coverage for a user-facing interface is unacceptable. | HIGH | Low (3-5 days) | Medium | Coverage |
|
||||
| R9 | **Add firmware unit tests** -- Adopt a C unit test framework (Unity, CMock, or CTest) for the 9,445 lines of ESP32 firmware. The fuzz harnesses are a good start but do not substitute for structured unit tests. | MEDIUM | Medium (2 weeks) | Medium | Coverage |
|
||||
| R10 | **Improve Rust public API documentation** -- 54.5% of `pub fn` declarations lack doc comments. Add `#![warn(missing_docs)]` to crate lib.rs files to enforce documentation. | MEDIUM | Medium (1-2 weeks) | Medium | Documentation |
|
||||
| R11 | **Add `rustfmt.toml`** -- No Rust formatting configuration found. Add workspace-level `rustfmt.toml` and enforce in CI with `cargo fmt --check`. | LOW | Low (1 day) | Low | Consistency |
|
||||
| R12 | **Reduce cyclomatic complexity** -- Average complexity of 24.09 is well above the 15 threshold. Target the 24 files over 500 lines for refactoring. | MEDIUM | High (3-4 weeks) | High | Maintainability |
|
||||
|
||||
---
|
||||
|
||||
## 5. Overall Quality Score
|
||||
|
||||
### 5.1 Scoring Methodology
|
||||
|
||||
Weighted scoring across 8 dimensions, each rated 0-100:
|
||||
|
||||
| Dimension | Weight | Score | Weighted | Rationale |
|
||||
|-----------|--------|-------|----------|-----------|
|
||||
| Unit test coverage | 20% | 68 | 13.6 | 3,142 unit tests is strong for Rust/mobile, but Python modules severely undertested |
|
||||
| Integration test coverage | 15% | 32 | 4.8 | Only 7 of 19 Rust crates have integration tests; Python integration tests exist but skip core modules |
|
||||
| E2E test coverage | 10% | 8 | 0.8 | 1 E2E file with 8 tests for a multi-platform system is critically insufficient |
|
||||
| Security posture | 15% | 82 | 12.3 | Strong CI security scanning, clean code patterns, daily Bandit/Semgrep/Safety; offset by 340 unsafe blocks needing audit |
|
||||
| Code quality / complexity | 15% | 35 | 5.3 | AQE score 37/100, 720 unwraps, 24 oversized files, high cyclomatic complexity |
|
||||
| CI/CD maturity | 10% | 55 | 5.5 | 8 workflows is good breadth, but missing Rust test execution in CI is a major gap |
|
||||
| Documentation | 10% | 78 | 7.8 | 79 ADRs, strong docstrings in Python, moderate Rust doc coverage, witness bundles |
|
||||
| Architecture governance | 5% | 90 | 4.5 | Exemplary ADR practice, DDD bounded contexts, deterministic verification pipeline |
|
||||
| **Total** | **100%** | | **54.6** | |
|
||||
|
||||
### 5.2 Final Verdict
|
||||
|
||||
```
|
||||
+---------------------------------------------------------------+
|
||||
| QE QUEEN ORCHESTRATION COMPLETE |
|
||||
+---------------------------------------------------------------+
|
||||
| Project: wifi-densepose (WiFi CSI Pose Estimation) |
|
||||
| Total Codebase: ~305K lines across 5 languages |
|
||||
| Total Tests: 3,327 (2,618 Rust + 488 Python + 202 Mobile |
|
||||
| + 3 firmware fuzz + 16 Rust integration files) |
|
||||
| Fleet ID: fleet-02558e91 |
|
||||
| Domains Analyzed: 5 |
|
||||
| Duration: ~120s |
|
||||
| Status: COMPLETED |
|
||||
| |
|
||||
| OVERALL QUALITY SCORE: 55 / 100 |
|
||||
| GRADE: C+ |
|
||||
| RELEASE READINESS: NOT READY (quality gate FAILED) |
|
||||
+---------------------------------------------------------------+
|
||||
```
|
||||
|
||||
### 5.3 Summary Assessment
|
||||
|
||||
**Strengths:**
|
||||
- Exceptional architecture governance with 79 ADRs and deterministic verification (witness bundles)
|
||||
- Strong Rust unit test count (2,618) with good distribution across signal processing and training crates
|
||||
- Mature security CI pipeline with daily scheduled scanning (Bandit, Semgrep, Safety)
|
||||
- Mobile UI has the best test-to-code ratio in the entire project
|
||||
- No hardcoded secrets, no unsafe string operations in firmware, clean security patterns
|
||||
|
||||
**Critical Gaps:**
|
||||
- Rust tests do not run in CI -- the 2,618 tests are only a local safety net
|
||||
- 720 `.unwrap()` calls create panic risk in production signal processing pipelines
|
||||
- 340 `unsafe` blocks need formal audit with documented safety invariants
|
||||
- 11 of 12 Python source modules have zero unit tests
|
||||
- Only 8 E2E test functions for a multi-platform, multi-service system
|
||||
- `sensing-server/main.rs` at 4,846 lines is a monolith risk
|
||||
|
||||
**Path to Release Readiness (target: 75/100):**
|
||||
1. Add Rust CI workflow (+10 points to CI maturity)
|
||||
2. Add Python unit tests for top 4 untested modules (+8 points to unit coverage)
|
||||
3. Audit and reduce `.unwrap()` count by 50% (+5 points to code quality)
|
||||
4. Add 5+ E2E test scenarios (+4 points to E2E coverage)
|
||||
5. Add integration tests to `core`, `hardware`, `nn` crates (+5 points to integration coverage)
|
||||
|
||||
---
|
||||
|
||||
*Report generated by QE Queen Coordinator (fleet-02558e91)*
|
||||
*Learnings stored: `queen-orchestration-full-qe-2026-04-05` in namespace `learning`*
|
||||
*AQE v3 quality assessment saved to: `.agentic-qe/results/quality/2026-04-05T11-02-19_assessment.json`*
|
||||
@@ -1,591 +0,0 @@
|
||||
# Code Quality and Complexity Analysis Report
|
||||
|
||||
**Project:** wifi-densepose (ruview)
|
||||
**Date:** 2026-04-05
|
||||
**Analyzer:** QE Code Complexity Analyzer v3
|
||||
**Scope:** Full codebase -- Rust, Python, C firmware, TypeScript/React Native
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
This report analyzes code complexity across the entire wifi-densepose project --
|
||||
153,139 lines of Rust, 21,399 lines of Python, 7,987 lines of C firmware, and
|
||||
7,457 lines of TypeScript/React Native. The analysis identified **231 Rust
|
||||
functions with cyclomatic complexity > 10**, a single 4,846-line Rust file that
|
||||
constitutes the most critical hotspot in the entire codebase, and systematic
|
||||
code duplication patterns that inflate maintenance cost.
|
||||
|
||||
### Key Findings
|
||||
|
||||
| Metric | Rust | Python | C Firmware | TypeScript |
|
||||
|--------|------|--------|------------|------------|
|
||||
| Source files | 379 | 63 | 32 | 71 |
|
||||
| Total lines | 153,139 | 21,399 | 7,987 | 7,457 |
|
||||
| Functions analyzed | 6,641 | 888 | 145 | 97 |
|
||||
| CC > 10 | 231 (3.5%) | 16 (1.8%) | 22 (15.2%) | 3 (3.1%) |
|
||||
| CC > 20 | 74 (1.1%) | 0 | 5 (3.4%) | 1 (1.0%) |
|
||||
| Functions > 50 lines | 282 (4.2%) | 49 (5.5%) | 26 (17.9%) | 3 (3.1%) |
|
||||
| Functions > 100 lines | 81 (1.2%) | 6 (0.7%) | 6 (4.1%) | 1 (1.0%) |
|
||||
| Files > 500 lines | 92 (24%) | 11 (17%) | 4 (25%) | 1 (1.4%) |
|
||||
| Files > 1000 lines | 24 (6%) | 0 | 1 (6%) | 0 |
|
||||
| Max nesting > 4 | 215 (3.2%) | 7 (0.8%) | 4 (2.8%) | 2 (2.1%) |
|
||||
|
||||
### Overall Quality Score: 62/100 (MODERATE)
|
||||
|
||||
The Python and TypeScript codebases are well-structured. The Rust codebase has
|
||||
pockets of extreme complexity concentrated in the sensing server, and the C
|
||||
firmware has proportionally the highest rate of complex functions.
|
||||
|
||||
---
|
||||
|
||||
## 1. Rust Codebase (153,139 lines, 17 crates)
|
||||
|
||||
### 1.1 Crate Size Breakdown
|
||||
|
||||
| Crate | Files | Lines | Assessment |
|
||||
|-------|-------|-------|------------|
|
||||
| wifi-densepose-wasm-edge | 68 | 28,888 | Largest; 68 vendor modules with repetitive `process_frame` |
|
||||
| wifi-densepose-mat | 43 | 19,572 | Mass casualty assessment; moderate complexity |
|
||||
| wifi-densepose-sensing-server | 18 | 17,825 | **CRITICAL** -- contains the worst hotspot |
|
||||
| wifi-densepose-signal | 28 | 16,194 | RuvSense multistatic modules; well-decomposed |
|
||||
| wifi-densepose-train | 18 | 10,562 | Training pipeline; moderate complexity |
|
||||
| wifi-densepose-wifiscan | 23 | 5,779 | Multi-BSSID pipeline; clean architecture |
|
||||
| wifi-densepose-ruvector | 16 | 4,629 | Cross-viewpoint fusion |
|
||||
| wifi-densepose-hardware | 11 | 4,005 | ESP32 TDM protocol |
|
||||
| wifi-densepose-desktop | 15 | 3,309 | Tauri desktop app |
|
||||
| wifi-densepose-nn | 7 | 2,959 | Neural network inference |
|
||||
| wifi-densepose-core | 5 | 2,596 | Core types and traits |
|
||||
| Other (6 crates) | 14 | 4,987 | Small, well-sized |
|
||||
| **Total** | **267** | **121,306** (src only) | |
|
||||
|
||||
### 1.2 Top 20 Most Complex Rust Functions
|
||||
|
||||
| Rank | CC | Lines | Depth | Function | File | Line |
|
||||
|------|-----|-------|-------|----------|------|------|
|
||||
| 1 | 121 | 776 | 8 | `main` | sensing-server/src/main.rs | 4070 |
|
||||
| 2 | 66 | 422 | 8 | `udp_receiver_task` | sensing-server/src/main.rs | 3504 |
|
||||
| 3 | 55 | 278 | 5 | `update` | mat/src/tracking/tracker.rs | 171 |
|
||||
| 4 | 50 | 184 | 8 | `process_frame` | wasm-edge/src/med_seizure_detect.rs | 157 |
|
||||
| 5 | 47 | 232 | 6 | `train_from_recordings` | sensing-server/src/adaptive_classifier.rs | 284 |
|
||||
| 6 | 42 | 381 | 5 | `detect_format` | mat/src/integration/csi_receiver.rs | 815 |
|
||||
| 7 | 41 | 78 | 4 | `deserialize_nvs_config` | desktop/src/commands/provision.rs | 345 |
|
||||
| 8 | 41 | 169 | 4 | `process_frame` | wasm-edge/src/sec_perimeter_breach.rs | 140 |
|
||||
| 9 | 40 | 472 | 6 | `real_training_loop` | sensing-server/src/training_api.rs | 825 |
|
||||
| 10 | 37 | 153 | 6 | `process_frame` | wasm-edge/src/bld_lighting_zones.rs | 118 |
|
||||
| 11 | 37 | 178 | 7 | `process_frame` | wasm-edge/src/ret_table_turnover.rs | 134 |
|
||||
| 12 | 36 | 154 | 7 | `process_frame` | wasm-edge/src/lrn_dtw_gesture_learn.rs | 145 |
|
||||
| 13 | 34 | 167 | 4 | `process_frame` | wasm-edge/src/exo_breathing_sync.rs | 197 |
|
||||
| 14 | 34 | 170 | 4 | `process_frame` | wasm-edge/src/exo_ghost_hunter.rs | 198 |
|
||||
| 15 | 33 | 134 | 5 | `process_frame` | wasm-edge/src/ind_structural_vibration.rs | 137 |
|
||||
| 16 | 33 | 90 | 4 | `process_frame` | wasm-edge/src/ais_prompt_shield.rs | 65 |
|
||||
| 17 | 32 | 144 | 5 | `process_frame` | wasm-edge/src/ret_shelf_engagement.rs | 163 |
|
||||
| 18 | 32 | 174 | 5 | `process_frame` | wasm-edge/src/exo_plant_growth.rs | 170 |
|
||||
| 19 | 31 | 129 | 6 | `process_frame` | wasm-edge/src/bld_meeting_room.rs | 98 |
|
||||
| 20 | 31 | 125 | 5 | `process_frame` | wasm-edge/src/ret_dwell_heatmap.rs | 116 |
|
||||
|
||||
### 1.3 Critical Hotspot: `sensing-server/src/main.rs` (4,846 lines)
|
||||
|
||||
This is the single worst file in the entire codebase. At 4,846 lines, it is
|
||||
**9.7x the project's 500-line guideline** and contains:
|
||||
|
||||
**God Object: `AppStateInner`** (lines 424-525)
|
||||
- 40+ fields spanning unrelated concerns: vital signs, recording state, training
|
||||
state, adaptive model, per-node state, field model calibration, model management
|
||||
- Violates Single Responsibility Principle -- mixes signal processing state,
|
||||
application lifecycle, network I/O, and persistence concerns
|
||||
|
||||
**Monolithic `main()` function** (lines 4070-4846)
|
||||
- CC=121, 776 lines, nesting depth 8
|
||||
- Handles CLI dispatch (benchmark, export, pretrain, embed, build-index, train,
|
||||
server startup) all in one function
|
||||
- Should be decomposed into at least 8 separate command handlers
|
||||
|
||||
**`udp_receiver_task()` function** (lines 3504-3926)
|
||||
- CC=66, 422 lines, nesting depth 8
|
||||
- Handles three different packet types (vitals 0xC511_0002, WASM 0xC511_0004,
|
||||
CSI 0xC511_0001) in a single monolithic match chain
|
||||
- Each branch duplicates the full sensing update construction and broadcast logic
|
||||
|
||||
**Systematic Code Duplication (6 instances):**
|
||||
- `smooth_and_classify` / `smooth_and_classify_node` -- identical logic, differs
|
||||
only in operating on `AppStateInner` vs `NodeState` (could use a trait)
|
||||
- `smooth_vitals` / `smooth_vitals_node` -- same pattern, identical algorithm
|
||||
duplicated for `AppStateInner` vs `NodeState`
|
||||
- `SensingUpdate` construction -- built identically in 6 different places
|
||||
(WiFi task, WiFi fallback, simulate task, ESP32 CSI handler, ESP32 vitals
|
||||
handler, broadcast tick)
|
||||
- Person count estimation -- repeated in WiFi, ESP32, and simulate paths
|
||||
|
||||
### 1.4 Code Smell: `wasm-edge` Vendor Modules
|
||||
|
||||
The `wifi-densepose-wasm-edge` crate contains 68 files (28,888 lines), with
|
||||
nearly every module implementing a `process_frame` function following the same
|
||||
pattern. At least 20 of these have CC > 25. This is a textbook case for:
|
||||
- Extracting a common `process_frame` trait with shared scaffolding
|
||||
- Using a generic signal pipeline builder
|
||||
|
||||
### 1.5 Oversized Rust Files (> 500 lines, violating project guideline)
|
||||
|
||||
92 Rust files exceed the 500-line guideline. The worst offenders:
|
||||
|
||||
| Lines | File |
|
||||
|-------|------|
|
||||
| 4,846 | sensing-server/src/main.rs |
|
||||
| 1,946 | sensing-server/src/training_api.rs |
|
||||
| 1,673 | wasm/src/mat.rs |
|
||||
| 1,664 | train/src/metrics.rs |
|
||||
| 1,523 | signal/src/ruvsense/pose_tracker.rs |
|
||||
| 1,498 | sensing-server/src/embedding.rs |
|
||||
| 1,430 | ruvector/src/crv/mod.rs |
|
||||
| 1,401 | mat/src/integration/csi_receiver.rs |
|
||||
| 1,360 | mat/src/integration/hardware_adapter.rs |
|
||||
| 1,346 | signal/src/ruvsense/field_model.rs |
|
||||
|
||||
### 1.6 Dependency Analysis
|
||||
|
||||
No circular dependencies detected. The dependency graph is clean and follows
|
||||
the documented crate publishing order. Maximum depth is 3 (CLI -> MAT -> core/signal/nn).
|
||||
|
||||
---
|
||||
|
||||
## 2. Python Codebase (21,399 lines, 63 files)
|
||||
|
||||
### 2.1 Overall Assessment: GOOD
|
||||
|
||||
The Python codebase is significantly better structured than the Rust codebase.
|
||||
Only 16 functions (1.8%) exceed CC=10, and no function exceeds CC=20. The code
|
||||
follows clean separation of concerns with distinct layers (api, services, core,
|
||||
hardware, middleware, sensing).
|
||||
|
||||
### 2.2 Top 10 Most Complex Python Functions
|
||||
|
||||
| Rank | CC | Lines | Depth | Function | File | Line |
|
||||
|------|-----|-------|-------|----------|------|------|
|
||||
| 1 | 19 | 90 | 4 | `estimate_poses` | services/pose_service.py | 491 |
|
||||
| 2 | 18 | 126 | 6 | `_print_text_status` | commands/status.py | 350 |
|
||||
| 3 | 15 | 72 | 4 | `websocket_events_stream` | api/routers/stream.py | 156 |
|
||||
| 4 | 14 | 100 | 3 | `health_check` | database/connection.py | 349 |
|
||||
| 5 | 14 | 47 | 3 | `get_overall_health` | services/health_check.py | 384 |
|
||||
| 6 | 13 | 52 | 3 | `_authenticate_request` | middleware/auth.py | 236 |
|
||||
| 7 | 13 | 64 | 4 | `_handle_preflight` | middleware/cors.py | 89 |
|
||||
| 8 | 13 | 84 | 4 | `websocket_pose_stream` | api/routers/stream.py | 69 |
|
||||
| 9 | 13 | 65 | 4 | `generate_signal_field` | sensing/ws_server.py | 236 |
|
||||
| 10 | 13 | 74 | 6 | `create_collector` | sensing/rssi_collector.py | 770 |
|
||||
|
||||
### 2.3 Files Exceeding 500 Lines
|
||||
|
||||
| Lines | File | Concern |
|
||||
|-------|------|---------|
|
||||
| 856 | services/pose_service.py | Pose estimation service -- acceptable for a service class |
|
||||
| 843 | sensing/rssi_collector.py | RSSI collection with 3 collector implementations |
|
||||
| 772 | tasks/monitoring.py | Background monitoring tasks |
|
||||
| 640 | database/connection.py | Database connection management |
|
||||
| 620 | cli.py | CLI command handler |
|
||||
| 610 | tasks/backup.py | Backup task logic |
|
||||
| 598 | tasks/cleanup.py | Cleanup task logic |
|
||||
| 519 | sensing/ws_server.py | WebSocket server |
|
||||
| 515 | hardware/csi_extractor.py | CSI data extraction |
|
||||
| 510 | commands/status.py | Status reporting |
|
||||
| 504 | middleware/error_handler.py | Error handling middleware |
|
||||
|
||||
### 2.4 Observations
|
||||
|
||||
- **Well-typed**: Uses type hints consistently throughout
|
||||
- **Clean separation**: API routers, services, core, and middleware are distinct
|
||||
- **Moderate nesting**: Only 7 functions (0.8%) exceed nesting depth 4
|
||||
- **Minor concern**: `_print_text_status` (CC=18, 126 lines) in `commands/status.py`
|
||||
is essentially a large formatting function that could be split into per-component
|
||||
formatters
|
||||
|
||||
---
|
||||
|
||||
## 3. C Firmware (7,987 lines, 32 files)
|
||||
|
||||
### 3.1 Overall Assessment: MODERATE
|
||||
|
||||
The C firmware has the highest proportion of complex functions (15.2% with CC>10).
|
||||
This is partly expected for embedded C, but several functions warrant attention.
|
||||
|
||||
### 3.2 Top 10 Most Complex C Functions
|
||||
|
||||
| Rank | CC | Lines | Depth | Function | File | Line |
|
||||
|------|-----|-------|-------|----------|------|------|
|
||||
| 1 | 59 | 314 | 3 | `nvs_config_load` | nvs_config.c | 19 |
|
||||
| 2 | 40 | 185 | 3 | `process_frame` | edge_processing.c | 708 |
|
||||
| 3 | 25 | 125 | 5 | `display_ui_update` | display_ui.c | 259 |
|
||||
| 4 | 22 | 94 | 3 | `mock_timer_cb` | mock_csi.c | 518 |
|
||||
| 5 | 22 | 174 | 3 | `app_main` | main.c | 127 |
|
||||
| 6 | 21 | 136 | 3 | `rvf_parse` | rvf_parser.c | 33 |
|
||||
| 7 | 19 | 119 | 3 | `wasm_runtime_load` | wasm_runtime.c | 442 |
|
||||
| 8 | 18 | 84 | 3 | `send_vitals_packet` | edge_processing.c | 554 |
|
||||
| 9 | 17 | 74 | 4 | `update_multi_person_vitals` | edge_processing.c | 474 |
|
||||
| 10 | 17 | 34 | 3 | `ld2410_feed_byte` | mmwave_sensor.c | 274 |
|
||||
|
||||
### 3.3 Critical Hotspot: `nvs_config_load` (CC=59, 314 lines)
|
||||
|
||||
This function in `nvs_config.c` has the highest complexity of any C function.
|
||||
It loads 30+ configuration parameters from NVS flash storage, each with its own
|
||||
error handling and default-value fallback. This is a classic case for:
|
||||
- Table-driven configuration loading with a descriptor array
|
||||
- Macro-based parameter definition to eliminate repetition
|
||||
|
||||
### 3.4 `edge_processing.c` (1,067 lines)
|
||||
|
||||
This is the only C file exceeding 1,000 lines. It implements the full dual-core
|
||||
CSI processing pipeline (11 processing stages). The `process_frame` function
|
||||
(CC=40, 185 lines) combines phase extraction, variance tracking, subcarrier
|
||||
selection, bandpass filtering, BPM estimation, presence detection, and fall
|
||||
detection in a single function.
|
||||
|
||||
### 3.5 Stack Safety Concern
|
||||
|
||||
The code documents that `process_frame` + `update_multi_person_vitals` combined
|
||||
used 6.5-7.5 KB of the 8 KB task stack, necessitating static scratch buffers.
|
||||
This indicates the functions are pushing resource limits and should be
|
||||
decomposed for safety margin.
|
||||
|
||||
---
|
||||
|
||||
## 4. TypeScript/React Native (7,457 lines, 71 files)
|
||||
|
||||
### 4.1 Overall Assessment: GOOD
|
||||
|
||||
The UI codebase is the cleanest in the project. Only 3 functions exceed CC=10,
|
||||
no file exceeds 1,000 lines, and the component architecture follows React
|
||||
best practices with proper separation of screens, components, stores, and services.
|
||||
|
||||
### 4.2 Critical Hotspot: `GaussianSplatWebView.web.tsx` (CC=70, 747 lines)
|
||||
|
||||
This is the only significant complexity hotspot in the TypeScript codebase.
|
||||
The `GaussianSplatWebViewWeb` component (CC=70, 467 lines) manages:
|
||||
- Three.js scene initialization and teardown
|
||||
- Multi-person skeleton rendering with DensePose-style body parts
|
||||
- Signal field visualization
|
||||
- Animation loop management
|
||||
- Frame data parsing and keypoint mapping
|
||||
|
||||
This component should be decomposed into:
|
||||
- A Three.js scene manager (initialization, camera, lighting, animation)
|
||||
- A skeleton renderer (body parts, keypoints, bones)
|
||||
- A signal field renderer (grid, heatmap)
|
||||
- A data adapter (frame parsing, person mapping)
|
||||
|
||||
### 4.3 Well-Structured Patterns
|
||||
|
||||
- **Zustand stores** (`poseStore.ts`, `matStore.ts`, `settingsStore.ts`): Clean
|
||||
state management with proper typing
|
||||
- **Custom hooks** (`useMatBridge`, `useOccupancyGrid`, `useGaussianBridge`):
|
||||
Good separation of WebSocket logic from UI components
|
||||
- **Component decomposition**: Screens are split into sub-components
|
||||
(AlertCard, SurvivorCounter, MetricCard, etc.)
|
||||
|
||||
---
|
||||
|
||||
## 5. Top 20 Hotspots (Cross-Codebase, Risk-Ranked)
|
||||
|
||||
Hotspots are ranked by a composite score combining complexity, file size,
|
||||
nesting depth, and duplication density.
|
||||
|
||||
| Rank | Risk | CC | Lines | File | Function | Primary Issue |
|
||||
|------|------|----|-------|------|----------|---------------|
|
||||
| 1 | 0.98 | 121 | 776 | sensing-server/main.rs:4070 | `main` | God function; CLI dispatch |
|
||||
| 2 | 0.96 | -- | 4,846 | sensing-server/main.rs | (file) | God file; 9.7x guideline |
|
||||
| 3 | 0.94 | 66 | 422 | sensing-server/main.rs:3504 | `udp_receiver_task` | 3 packet types monolithic |
|
||||
| 4 | 0.90 | -- | 40+ fields | sensing-server/main.rs:424 | `AppStateInner` | God object |
|
||||
| 5 | 0.87 | 59 | 314 | nvs_config.c:19 | `nvs_config_load` | Needs table-driven approach |
|
||||
| 6 | 0.85 | 55 | 278 | mat/tracking/tracker.rs:171 | `update` | Complex tracking logic |
|
||||
| 7 | 0.82 | 50 | 184 | wasm-edge/med_seizure_detect.rs:157 | `process_frame` | Deep nesting (8) |
|
||||
| 8 | 0.80 | 70 | 467 | GaussianSplatWebView.web.tsx:277 | `GaussianSplatWebViewWeb` | Three.js god component |
|
||||
| 9 | 0.78 | 47 | 232 | sensing-server/adaptive_classifier.rs:284 | `train_from_recordings` | Complex training logic |
|
||||
| 10 | 0.76 | 42 | 381 | mat/csi_receiver.rs:815 | `detect_format` | Format detection chain |
|
||||
| 11 | 0.75 | 40 | 472 | sensing-server/training_api.rs:825 | `real_training_loop` | Long training loop |
|
||||
| 12 | 0.73 | 40 | 185 | edge_processing.c:708 | `process_frame` | 11-stage DSP in one func |
|
||||
| 13 | 0.70 | -- | 6x | sensing-server/main.rs | `SensingUpdate` builds | Duplicated 6 times |
|
||||
| 14 | 0.68 | 19 | 90 | services/pose_service.py:491 | `estimate_poses` | Highest Python CC |
|
||||
| 15 | 0.65 | -- | 1,946 | sensing-server/training_api.rs | (file) | 3.9x guideline |
|
||||
| 16 | 0.63 | -- | 1,673 | wasm/mat.rs | (file) | 3.3x guideline |
|
||||
| 17 | 0.61 | -- | 1,664 | train/metrics.rs | (file) | 3.3x guideline |
|
||||
| 18 | 0.59 | -- | 1,523 | signal/ruvsense/pose_tracker.rs | (file) | 3.0x guideline |
|
||||
| 19 | 0.57 | 25 | 125 | display_ui.c:259 | `display_ui_update` | Deep nesting (5) |
|
||||
| 20 | 0.55 | 28 | 106 | sensing-server/main.rs:2161 | `estimate_persons_from_correlation` | Complex graph algorithm |
|
||||
|
||||
---
|
||||
|
||||
## 6. Code Smell Catalog
|
||||
|
||||
### 6.1 God Class / God File
|
||||
|
||||
| Smell | Location | Severity |
|
||||
|-------|----------|----------|
|
||||
| God File | sensing-server/main.rs (4,846 lines) | CRITICAL |
|
||||
| God Object | `AppStateInner` (40+ fields) | CRITICAL |
|
||||
| God Function | `main()` (776 lines, CC=121) | CRITICAL |
|
||||
| God Function | `udp_receiver_task()` (422 lines, CC=66) | HIGH |
|
||||
|
||||
### 6.2 Duplicated Code
|
||||
|
||||
| Pattern | Instances | Lines Duplicated | Severity |
|
||||
|---------|-----------|-----------------|----------|
|
||||
| `smooth_and_classify` / `smooth_and_classify_node` | 2 | ~50 per copy | HIGH |
|
||||
| `smooth_vitals` / `smooth_vitals_node` | 2 | ~50 per copy | HIGH |
|
||||
| `SensingUpdate {}` construction | 6 | ~40 per instance | HIGH |
|
||||
| Person count estimation pattern | 3+ | ~15 per instance | MEDIUM |
|
||||
| `frame_history` capacity check | 6+ | ~3 per instance | LOW |
|
||||
| `tracker_bridge::tracker_update` call pattern | 5 | ~5 per instance | MEDIUM |
|
||||
|
||||
Estimated duplicated code in `main.rs` alone: **~450 lines** (9.3% of file).
|
||||
|
||||
### 6.3 Deep Nesting (> 4 levels)
|
||||
|
||||
215 Rust functions exceed 4 levels of nesting. The worst cases:
|
||||
- `main()`: 8 levels (lines 4070-4846)
|
||||
- `udp_receiver_task()`: 8 levels (lines 3504-3926)
|
||||
- Multiple `process_frame` in wasm-edge: 7-8 levels
|
||||
|
||||
### 6.4 Long Parameter Lists (> 5 parameters)
|
||||
|
||||
43 Rust functions have more than 5 parameters. Notable:
|
||||
- `process_frame` variants in wasm-edge: 5-7 parameters each
|
||||
- `extract_features_from_frame`: 3 parameters but returns a 5-tuple
|
||||
|
||||
### 6.5 Repetitive Vendor Modules (wasm-edge)
|
||||
|
||||
The `wifi-densepose-wasm-edge` crate has 68 files following a near-identical
|
||||
pattern. At least 35 have a `process_frame` function with CC > 20. A trait-based
|
||||
or macro-based approach would reduce this to a fraction of the code.
|
||||
|
||||
---
|
||||
|
||||
## 7. Testability Assessment
|
||||
|
||||
| Component | Score | Rating | Key Blockers |
|
||||
|-----------|-------|--------|-------------|
|
||||
| wifi-densepose-core | 85/100 | EASY | Pure types, no side effects |
|
||||
| wifi-densepose-signal | 78/100 | EASY | Mostly pure computation |
|
||||
| wifi-densepose-train | 72/100 | MODERATE | External dataset dependencies |
|
||||
| wifi-densepose-mat | 68/100 | MODERATE | Integration with core+signal+nn |
|
||||
| wifi-densepose-wifiscan | 75/100 | EASY | Platform-specific but well-abstracted |
|
||||
| wifi-densepose-sensing-server | 32/100 | VERY DIFFICULT | God object, coupled state, async |
|
||||
| wifi-densepose-wasm-edge | 55/100 | MODERATE | Repetitive but self-contained |
|
||||
| v1/src (Python) | 70/100 | MODERATE | Good DI, some tight coupling |
|
||||
| firmware (C) | 40/100 | DIFFICULT | Hardware deps, global state |
|
||||
| ui/mobile (TypeScript) | 72/100 | MODERATE | Component isolation is good |
|
||||
|
||||
---
|
||||
|
||||
## 8. Refactoring Recommendations
|
||||
|
||||
### Priority 1: CRITICAL -- sensing-server/main.rs Decomposition
|
||||
|
||||
**Estimated effort:** 3-5 days
|
||||
**Impact:** Reduces maintenance cost for the most-changed file in the project
|
||||
|
||||
1. **Extract `AppStateInner` into bounded contexts:**
|
||||
- `SensingState` -- frame history, features, classification
|
||||
- `VitalSignState` -- HR/BR smoothing, detector, buffers
|
||||
- `RecordingState` -- recording lifecycle, file handles
|
||||
- `TrainingState` -- training status, config
|
||||
- `ModelState` -- loaded model, progressive loader, SONA profiles
|
||||
- `NodeRegistry` -- per-node states, pose tracker, multistatic fuser
|
||||
|
||||
2. **Extract command handlers from `main()`:**
|
||||
- `run_benchmark()` (lines 4082-4089)
|
||||
- `run_export_rvf()` (lines 4092-4142)
|
||||
- `run_pretrain()` (lines 4145-4247)
|
||||
- `run_embed()` (lines 4250-4312)
|
||||
- `run_build_index()` (lines 4315-4357)
|
||||
- `run_train()` (lines 4360-end)
|
||||
- `run_server()` -- the remaining server startup
|
||||
|
||||
3. **Extract `SensingUpdate` builder:**
|
||||
Create a `SensingUpdateBuilder` that encapsulates the repeated 6-instance
|
||||
construction pattern.
|
||||
|
||||
4. **Unify node vs global variants via trait:**
|
||||
```rust
|
||||
trait SmoothingState {
|
||||
fn smoothed_motion(&self) -> f64;
|
||||
fn set_smoothed_motion(&mut self, v: f64);
|
||||
// ... etc
|
||||
}
|
||||
impl SmoothingState for AppStateInner { ... }
|
||||
impl SmoothingState for NodeState { ... }
|
||||
```
|
||||
Then a single `smooth_and_classify<S: SmoothingState>()` replaces both copies.
|
||||
|
||||
5. **Extract `udp_receiver_task` into packet-type handlers:**
|
||||
- `handle_vitals_packet()`
|
||||
- `handle_wasm_packet()`
|
||||
- `handle_csi_frame()`
|
||||
|
||||
### Priority 2: HIGH -- C Firmware `nvs_config_load` Table-Driven Refactor
|
||||
|
||||
**Estimated effort:** 1 day
|
||||
**Impact:** Reduces CC from 59 to approximately 5
|
||||
|
||||
Replace the 314-line sequential NVS load with a descriptor table:
|
||||
```c
|
||||
typedef struct {
|
||||
const char *key;
|
||||
nvs_type_t type;
|
||||
void *dest;
|
||||
size_t size;
|
||||
const void *default_val;
|
||||
} nvs_param_desc_t;
|
||||
|
||||
static const nvs_param_desc_t params[] = {
|
||||
{"node_id", NVS_U8, &cfg->node_id, 1, &(uint8_t){1}},
|
||||
// ... 30+ entries
|
||||
};
|
||||
```
|
||||
|
||||
### Priority 3: HIGH -- wasm-edge `process_frame` Trait Extraction
|
||||
|
||||
**Estimated effort:** 2-3 days
|
||||
**Impact:** Reduces 28,888 lines by an estimated 30-40%
|
||||
|
||||
Define a common trait:
|
||||
```rust
|
||||
trait WasmEdgeModule {
|
||||
fn name(&self) -> &str;
|
||||
fn init(&mut self, config: &ModuleConfig);
|
||||
fn process_frame(&mut self, ctx: &mut FrameContext) -> Vec<WasmEvent>;
|
||||
}
|
||||
```
|
||||
Extract shared signal processing (phase extraction, variance tracking, BPM
|
||||
estimation) into reusable pipeline stages.
|
||||
|
||||
### Priority 4: MEDIUM -- GaussianSplatWebView.web.tsx Decomposition
|
||||
|
||||
**Estimated effort:** 1 day
|
||||
**Impact:** Reduces CC from 70 to approximately 10-15 per component
|
||||
|
||||
Split into:
|
||||
- `SceneManager` -- Three.js initialization, camera, lighting
|
||||
- `SkeletonRenderer` -- body parts, keypoints, bones
|
||||
- `SignalFieldRenderer` -- grid, heatmap visualization
|
||||
- `useFrameAdapter` -- data parsing hook
|
||||
|
||||
### Priority 5: MEDIUM -- `edge_processing.c` Pipeline Decomposition
|
||||
|
||||
**Estimated effort:** 1-2 days
|
||||
**Impact:** Reduces `process_frame` CC from 40 to ~10; improves stack safety
|
||||
|
||||
Split into stage functions:
|
||||
```c
|
||||
static void stage_phase_extract(frame_ctx_t *ctx);
|
||||
static void stage_variance_update(frame_ctx_t *ctx);
|
||||
static void stage_subcarrier_select(frame_ctx_t *ctx);
|
||||
static void stage_bandpass_filter(frame_ctx_t *ctx);
|
||||
static void stage_bpm_estimate(frame_ctx_t *ctx);
|
||||
static void stage_presence_detect(frame_ctx_t *ctx);
|
||||
static void stage_fall_detect(frame_ctx_t *ctx);
|
||||
```
|
||||
|
||||
### Priority 6: LOW -- Python Status Formatter Decomposition
|
||||
|
||||
**Estimated effort:** 0.5 days
|
||||
**Impact:** Reduces `_print_text_status` CC from 18 to ~5 per formatter
|
||||
|
||||
Split `_print_text_status` (126 lines) into per-component formatters:
|
||||
`_format_api_status`, `_format_hardware_status`, `_format_streaming_status`, etc.
|
||||
|
||||
---
|
||||
|
||||
## 9. Quality Gate Recommendations
|
||||
|
||||
### Proposed Complexity Thresholds for CI/CD
|
||||
|
||||
| Metric | Warn | Fail | Current Violations |
|
||||
|--------|------|------|--------------------|
|
||||
| File size | > 500 lines | > 1,000 lines | 92 warn, 25 fail |
|
||||
| Function CC | > 15 | > 25 | ~150 warn, ~74 fail |
|
||||
| Function lines | > 50 | > 100 | ~360 warn, ~94 fail |
|
||||
| Nesting depth | > 4 | > 6 | ~215 warn, ~30 fail |
|
||||
| Parameter count | > 5 | > 7 | ~43 warn, ~10 fail |
|
||||
|
||||
### Recommended Immediate Actions
|
||||
|
||||
1. **Block new functions with CC > 25** in CI (addresses future growth)
|
||||
2. **Block new files exceeding 500 lines** (enforces project guideline)
|
||||
3. **Add complexity linting** via `cargo clippy` with custom lints or `complexity-rs`
|
||||
4. **Prioritize the sensing-server decomposition** -- it is the single largest
|
||||
contributor to technical debt in the project
|
||||
|
||||
---
|
||||
|
||||
## 10. Complexity Distribution Charts (Text)
|
||||
|
||||
### Rust Cyclomatic Complexity Distribution
|
||||
|
||||
```
|
||||
CC Range | Functions | Percentage | Bar
|
||||
------------|-----------|------------|----------------------------------
|
||||
1-5 | 5,728 | 86.2% | ####################################
|
||||
6-10 | 682 | 10.3% | ####
|
||||
11-15 | 107 | 1.6% | #
|
||||
16-20 | 50 | 0.8% |
|
||||
21-30 | 41 | 0.6% |
|
||||
31-50 | 24 | 0.4% |
|
||||
>50 | 9 | 0.1% |
|
||||
```
|
||||
|
||||
### Python Cyclomatic Complexity Distribution
|
||||
|
||||
```
|
||||
CC Range | Functions | Percentage | Bar
|
||||
------------|-----------|------------|----------------------------------
|
||||
1-5 | 740 | 83.3% | ####################################
|
||||
6-10 | 132 | 14.9% | ######
|
||||
11-15 | 13 | 1.5% | #
|
||||
16-20 | 3 | 0.3% |
|
||||
```
|
||||
|
||||
### C Firmware Cyclomatic Complexity Distribution
|
||||
|
||||
```
|
||||
CC Range | Functions | Percentage | Bar
|
||||
------------|-----------|------------|----------------------------------
|
||||
1-5 | 73 | 50.3% | ####################################
|
||||
6-10 | 50 | 34.5% | #########################
|
||||
11-15 | 6 | 4.1% | ###
|
||||
16-20 | 8 | 5.5% | ####
|
||||
21-30 | 3 | 2.1% | ##
|
||||
>30 | 5 | 3.4% | ##
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Appendix A: Methodology
|
||||
|
||||
### Metrics Calculated
|
||||
|
||||
- **Cyclomatic Complexity (CC):** McCabe's cyclomatic complexity counting
|
||||
decision points (if, else if, match, for, while, boolean operators, match arms)
|
||||
- **Cognitive Complexity:** Approximated via nesting depth and CC combination
|
||||
- **Function Length:** Raw line count from function signature to closing brace
|
||||
- **Nesting Depth:** Maximum brace/indent depth within function body
|
||||
- **Parameter Count:** Number of non-self parameters
|
||||
- **File Size:** Total lines including comments and blank lines
|
||||
|
||||
### Tools Used
|
||||
|
||||
- Custom Python AST analysis for Python files
|
||||
- Custom regex-based analysis for Rust, C, and TypeScript files
|
||||
- AST parsing provides higher accuracy for Python; regex-based analysis may
|
||||
slightly overcount CC for Rust (e.g., match arms in comments) but provides
|
||||
consistent cross-language comparison
|
||||
|
||||
### Limitations
|
||||
|
||||
- CC for Rust match arms counted via `=>` may include non-decision match arms
|
||||
- TypeScript analysis captures top-level and exported functions but may miss
|
||||
deeply nested callbacks
|
||||
- C analysis requires function signatures to start at column 0
|
||||
- Dead code detection is heuristic-only (unused imports not checked at scale)
|
||||
|
||||
---
|
||||
|
||||
*Report generated by QE Code Complexity Analyzer v3*
|
||||
*Codebase snapshot: commit 85434229 on branch qe-reports*
|
||||
@@ -1,600 +0,0 @@
|
||||
# Security Review Report -- wifi-densepose
|
||||
|
||||
**Date:** 2026-04-05
|
||||
**Reviewer:** QE Security Reviewer (V3)
|
||||
**Scope:** Full codebase -- Python API, Rust crates, ESP32 C firmware
|
||||
**Severity Weights:** CRITICAL=3, HIGH=2, MEDIUM=1, LOW=0.5, INFORMATIONAL=0.25
|
||||
**Weighted Finding Score:** 19.25 (minimum required: 3.0)
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
This security review examined all security-sensitive code across the wifi-densepose project: the Python FastAPI backend (authentication, rate limiting, CORS, WebSocket, API endpoints), Rust workspace crates (API, DB, config, WASM), and ESP32-S3 C firmware (NVS credentials, OTA update, WASM upload, swarm bridge, UDP streaming).
|
||||
|
||||
**Recommendation: CONDITIONAL PASS** -- No critical data-exfiltration or remote code execution vulnerabilities were found in the production code paths. However, 3 HIGH severity findings and several MEDIUM issues require remediation before any production deployment. The codebase demonstrates solid security awareness in many areas (constant-time OTA PSK comparison, Ed25519 WASM signature verification, parameterized queries via SQLAlchemy/sqlx, bcrypt password hashing), but gaps remain in WebSocket security, rate limiting bypass vectors, and firmware transport encryption.
|
||||
|
||||
---
|
||||
|
||||
## Vulnerability Summary
|
||||
|
||||
| Severity | Count | Categories |
|
||||
|----------|-------|------------|
|
||||
| CRITICAL | 0 | -- |
|
||||
| HIGH | 3 | Auth bypass, information disclosure, IP spoofing |
|
||||
| MEDIUM | 7 | CORS, token lifecycle, transport security, memory growth |
|
||||
| LOW | 5 | Deprecated APIs, logging, configuration hardening |
|
||||
| INFORMATIONAL | 3 | Best practice improvements |
|
||||
|
||||
---
|
||||
|
||||
## Detailed Findings
|
||||
|
||||
### HIGH-001: WebSocket Authentication Token Passed in URL Query String (CWE-598)
|
||||
|
||||
**Severity:** HIGH
|
||||
**OWASP:** A07:2021 -- Identification and Authentication Failures
|
||||
**Files:**
|
||||
- `v1/src/api/routers/stream.py:74` (WebSocket `token` query parameter)
|
||||
- `v1/src/middleware/auth.py:243` (fallback to `request.query_params.get("token")`)
|
||||
- `v1/src/api/middleware/auth.py:173` (`request.query_params.get("token")`)
|
||||
|
||||
**Description:**
|
||||
JWT tokens are accepted via URL query parameters for WebSocket connections. URL parameters are logged in web server access logs, browser history, proxy logs, and HTTP Referer headers. This creates multiple credential leakage vectors.
|
||||
|
||||
```python
|
||||
# v1/src/api/routers/stream.py:74
|
||||
token: Optional[str] = Query(None, description="Authentication token")
|
||||
```
|
||||
|
||||
```python
|
||||
# v1/src/middleware/auth.py:243
|
||||
if request.url.path.startswith("/ws"):
|
||||
token = request.query_params.get("token")
|
||||
```
|
||||
|
||||
**Impact:** JWT tokens may be captured from server logs, proxy caches, or browser history, enabling session hijacking.
|
||||
|
||||
**Remediation:**
|
||||
1. Use the WebSocket `Sec-WebSocket-Protocol` header to pass tokens during the upgrade handshake.
|
||||
2. Alternatively, require clients to send the token as the first WebSocket message after connection, then authenticate before processing further messages.
|
||||
3. If query parameter tokens must be supported during a transition, ensure all web server and reverse proxy log configurations redact the `token` parameter.
|
||||
|
||||
---
|
||||
|
||||
### HIGH-002: Rate Limiter Trusts X-Forwarded-For Header Without Validation (CWE-348)
|
||||
|
||||
**Severity:** HIGH
|
||||
**OWASP:** A05:2021 -- Security Misconfiguration
|
||||
**File:** `v1/src/middleware/rate_limit.py:200-206`
|
||||
|
||||
**Description:**
|
||||
The `_get_client_ip` method trusts the `X-Forwarded-For` header without any validation. An attacker can spoof this header to bypass IP-based rate limiting entirely by rotating forged IP addresses on each request.
|
||||
|
||||
```python
|
||||
# v1/src/middleware/rate_limit.py:200-206
|
||||
def _get_client_ip(self, request: Request) -> str:
|
||||
forwarded_for = request.headers.get("X-Forwarded-For")
|
||||
if forwarded_for:
|
||||
return forwarded_for.split(",")[0].strip()
|
||||
|
||||
real_ip = request.headers.get("X-Real-IP")
|
||||
if real_ip:
|
||||
return real_ip
|
||||
|
||||
return request.client.host if request.client else "unknown"
|
||||
```
|
||||
|
||||
**Impact:** Complete rate limiting bypass for unauthenticated requests. An attacker can send unlimited requests by setting arbitrary `X-Forwarded-For` values.
|
||||
|
||||
**Remediation:**
|
||||
1. Only trust `X-Forwarded-For` when the application is deployed behind a known reverse proxy. Configure a trusted proxy allowlist.
|
||||
2. Use the uvicorn/Starlette `--proxy-headers` flag only when behind a trusted proxy, and strip these headers at the edge.
|
||||
3. Consider using a middleware like `starlette.middleware.trustedhost.TrustedHostMiddleware` and validating the number of proxy hops.
|
||||
|
||||
---
|
||||
|
||||
### HIGH-003: Error Responses Leak Internal Exception Details in Non-Production (CWE-209)
|
||||
|
||||
**Severity:** HIGH
|
||||
**OWASP:** A09:2021 -- Security Logging and Monitoring Failures
|
||||
**Files:**
|
||||
- `v1/src/api/routers/pose.py:140-141` -- `detail=f"Pose estimation failed: {str(e)}"`
|
||||
- `v1/src/api/routers/pose.py:176-177` -- `detail=f"Pose analysis failed: {str(e)}"`
|
||||
- `v1/src/api/routers/stream.py:297` -- `detail=f"Failed to get stream status: {str(e)}"`
|
||||
- All exception handlers in `v1/src/api/routers/stream.py` (lines 326, 351, 404, 442, 463)
|
||||
- `v1/src/middleware/error_handler.py:101-104` -- traceback in development mode
|
||||
|
||||
**Description:**
|
||||
Multiple API endpoints directly interpolate Python exception messages into HTTP error responses. While the global error handler in `error_handler.py` correctly suppresses details in production, the per-endpoint `HTTPException` handlers bypass this and always expose `str(e)` regardless of environment.
|
||||
|
||||
```python
|
||||
# v1/src/api/routers/pose.py:140-141
|
||||
raise HTTPException(
|
||||
status_code=500,
|
||||
detail=f"Pose estimation failed: {str(e)}"
|
||||
)
|
||||
```
|
||||
|
||||
**Impact:** Internal error messages (including database connection strings, file paths, stack traces, and library-specific error codes) are exposed to unauthenticated callers. This aids reconnaissance for targeted attacks.
|
||||
|
||||
**Remediation:**
|
||||
1. Replace all endpoint-level `detail=f"...{str(e)}"` patterns with a generic message: `detail="Internal server error"`.
|
||||
2. Log the full exception server-side with `logger.exception()`.
|
||||
3. Rely on the centralized `ErrorHandler` class for all error formatting, which already has production-safe behavior.
|
||||
|
||||
---
|
||||
|
||||
### MEDIUM-001: CORS Allows Wildcard Origins with Credentials in Development (CWE-942)
|
||||
|
||||
**Severity:** MEDIUM
|
||||
**OWASP:** A05:2021 -- Security Misconfiguration
|
||||
**Files:**
|
||||
- `v1/src/config/settings.py:33-34` -- defaults: `cors_origins=["*"]`, `cors_allow_credentials=True`
|
||||
- `v1/src/middleware/cors.py:255-256` -- development config combines `allow_origins=["*"]` + `allow_credentials=True`
|
||||
|
||||
**Description:**
|
||||
The default settings allow CORS from all origins (`*`) with credentials (`allow_credentials=True`). Per the CORS specification, `Access-Control-Allow-Origin: *` cannot be used with `Access-Control-Allow-Credentials: true`. However, the `CORSMiddleware` implementation echoes the requesting origin header verbatim, effectively granting credentialed access from any origin.
|
||||
|
||||
```python
|
||||
# v1/src/middleware/cors.py:255-256 (development_config)
|
||||
"allow_origins": ["*"],
|
||||
"allow_credentials": True,
|
||||
```
|
||||
|
||||
The `validate_cors_config` function at line 354 correctly flags this combination but is only advisory -- it does not prevent the configuration from being applied.
|
||||
|
||||
**Impact:** Any website can make authenticated cross-origin requests to the API when running in development mode. If development defaults leak to production, this becomes a credential theft vector via CSRF-like attacks.
|
||||
|
||||
**Remediation:**
|
||||
1. Change the default `cors_origins` to `[]` (empty list) and require explicit configuration.
|
||||
2. Make `validate_cors_config` enforce the rule by raising an exception rather than returning warnings.
|
||||
3. In the `CORSMiddleware.__init__`, reject the combination of `allow_credentials=True` with wildcard origins at construction time.
|
||||
|
||||
---
|
||||
|
||||
### MEDIUM-002: WebSocket Connections Lack Message Size Limits (CWE-400)
|
||||
|
||||
**Severity:** MEDIUM
|
||||
**OWASP:** A04:2021 -- Insecure Design
|
||||
**Files:**
|
||||
- `v1/src/api/routers/stream.py:127-128` -- `message = await websocket.receive_text()` with no size limit
|
||||
- `v1/src/api/websocket/connection_manager.py` -- no `max_size` configuration
|
||||
|
||||
**Description:**
|
||||
WebSocket endpoints accept incoming messages of arbitrary size. The `receive_text()` call at `stream.py:127` has no size limit, allowing a client to send extremely large messages that consume server memory.
|
||||
|
||||
Additionally, the `ConnectionManager` does not enforce a maximum number of connections. An attacker could open thousands of WebSocket connections to exhaust server resources.
|
||||
|
||||
**Impact:** Denial of service through memory exhaustion or connection pool exhaustion.
|
||||
|
||||
**Remediation:**
|
||||
1. Configure `websocket.accept(max_size=...)` or use Starlette's `WebSocket` `max_size` parameter (default is 16 MB -- reduce to 64 KB or less for control messages).
|
||||
2. Add a maximum connection limit in `ConnectionManager.connect()` and reject new connections when the limit is reached.
|
||||
3. Implement per-client message rate limiting in the WebSocket handler.
|
||||
|
||||
---
|
||||
|
||||
### MEDIUM-003: Token Blacklist Uses Periodic Full Clear Instead of Per-Token Expiry (CWE-613)
|
||||
|
||||
**Severity:** MEDIUM
|
||||
**OWASP:** A07:2021 -- Identification and Authentication Failures
|
||||
**File:** `v1/src/api/middleware/auth.py:246-252`
|
||||
|
||||
**Description:**
|
||||
The `TokenBlacklist` class clears all blacklisted tokens every hour, regardless of their actual expiry time. This means:
|
||||
1. A revoked token could be re-usable after the next hourly clear.
|
||||
2. Tokens revoked just before a clear cycle have nearly zero effective blacklist time.
|
||||
|
||||
```python
|
||||
# v1/src/api/middleware/auth.py:246-252
|
||||
def _cleanup_if_needed(self):
|
||||
now = datetime.utcnow()
|
||||
if (now - self._last_cleanup).total_seconds() > self._cleanup_interval:
|
||||
self._blacklisted_tokens.clear() # Clears ALL tokens
|
||||
self._last_cleanup = now
|
||||
```
|
||||
|
||||
Furthermore, the `TokenBlacklist` is not consulted in the `AuthMiddleware.dispatch()` or `AuthenticationMiddleware._authenticate_request()` flows -- the `token_blacklist` global instance exists but is never checked during token validation.
|
||||
|
||||
**Impact:** Token revocation (logout) is not enforceable. A stolen JWT remains valid until its natural expiry.
|
||||
|
||||
**Remediation:**
|
||||
1. Store each blacklisted token with its `exp` claim timestamp. Only remove entries whose `exp` has passed.
|
||||
2. Integrate the blacklist check into `_verify_token()` / `verify_token()` so that blacklisted tokens are rejected.
|
||||
3. For production, replace the in-memory set with a Redis-backed store for cross-process consistency.
|
||||
|
||||
---
|
||||
|
||||
### MEDIUM-004: OTA Update Endpoint Has No Authentication by Default (CWE-306)
|
||||
|
||||
**Severity:** MEDIUM
|
||||
**OWASP:** A07:2021 -- Identification and Authentication Failures
|
||||
**File:** `firmware/esp32-csi-node/main/ota_update.c:44-49`
|
||||
|
||||
**Description:**
|
||||
The OTA firmware update endpoint (`POST /ota` on port 8032) has authentication disabled unless an OTA pre-shared key (PSK) is manually provisioned into NVS. The `ota_check_auth` function returns `true` when no PSK is configured, allowing unauthenticated firmware uploads.
|
||||
|
||||
```c
|
||||
// firmware/esp32-csi-node/main/ota_update.c:44-49
|
||||
static bool ota_check_auth(httpd_req_t *req)
|
||||
{
|
||||
if (s_ota_psk[0] == '\0') {
|
||||
/* No PSK provisioned -- auth disabled (permissive for dev). */
|
||||
return true;
|
||||
}
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
The firmware logs a warning about this (`ESP_LOGW(..., "OTA authentication DISABLED")`), but it is the default state for all new devices.
|
||||
|
||||
**Impact:** Any device on the same network can flash arbitrary firmware to the ESP32 without authentication, enabling persistent compromise of the sensing node.
|
||||
|
||||
**Remediation:**
|
||||
1. Require PSK provisioning as part of the mandatory device setup flow. Reject OTA uploads if no PSK is provisioned (fail-closed).
|
||||
2. Alternatively, require physical button press confirmation for OTA updates when no PSK is set.
|
||||
3. Document the PSK provisioning step prominently in the deployment guide.
|
||||
|
||||
---
|
||||
|
||||
### MEDIUM-005: ESP32 UDP CSI Stream Has No Encryption or Authentication (CWE-319)
|
||||
|
||||
**Severity:** MEDIUM
|
||||
**OWASP:** A02:2021 -- Cryptographic Failures
|
||||
**File:** `firmware/esp32-csi-node/main/stream_sender.c:66-106`
|
||||
|
||||
**Description:**
|
||||
CSI data frames are transmitted via plain UDP (`SOCK_DGRAM, IPPROTO_UDP`) with no encryption, authentication, or integrity protection. An attacker on the same network segment can:
|
||||
1. Eavesdrop on CSI data (potentially revealing occupancy/activity information).
|
||||
2. Inject forged CSI frames to manipulate pose estimation.
|
||||
3. Replay captured frames.
|
||||
|
||||
```c
|
||||
// firmware/esp32-csi-node/main/stream_sender.c:92-93
|
||||
int sent = sendto(s_sock, data, len, 0,
|
||||
(struct sockaddr *)&s_dest_addr, sizeof(s_dest_addr));
|
||||
```
|
||||
|
||||
**Impact:** CSI data exposure and injection on the local network. The severity is moderated by the fact that CSI data requires specialized knowledge to interpret, but the UDP transport provides zero confidentiality for the sensor data.
|
||||
|
||||
**Remediation:**
|
||||
1. Implement DTLS (Datagram TLS) for the UDP stream, using mbedTLS which is already available in ESP-IDF.
|
||||
2. At minimum, add HMAC authentication to each frame using a pre-shared key to prevent injection.
|
||||
3. Consider adding a sequence number and replay window to detect replayed frames.
|
||||
|
||||
---
|
||||
|
||||
### MEDIUM-006: Swarm Bridge Seed Token Transmitted in Cleartext HTTP (CWE-319)
|
||||
|
||||
**Severity:** MEDIUM
|
||||
**OWASP:** A02:2021 -- Cryptographic Failures
|
||||
**File:** `firmware/esp32-csi-node/main/swarm_bridge.c:211-229`
|
||||
|
||||
**Description:**
|
||||
The swarm bridge HTTP client configuration does not enforce TLS. The `esp_http_client_config_t` struct at line 211 specifies only `.url` and `.timeout_ms` without setting `.transport_type = HTTP_TRANSPORT_OVER_SSL` or `.cert_pem`. If the `seed_url` uses `http://` rather than `https://`, the Bearer token is transmitted in cleartext.
|
||||
|
||||
```c
|
||||
// firmware/esp32-csi-node/main/swarm_bridge.c:211-216
|
||||
esp_http_client_config_t http_cfg = {
|
||||
.url = url,
|
||||
.method = HTTP_METHOD_POST,
|
||||
.timeout_ms = SWARM_HTTP_TIMEOUT,
|
||||
};
|
||||
```
|
||||
|
||||
```c
|
||||
// firmware/esp32-csi-node/main/swarm_bridge.c:226-229
|
||||
if (s_cfg.seed_token[0] != '\0') {
|
||||
char auth_hdr[80];
|
||||
snprintf(auth_hdr, sizeof(auth_hdr), "Bearer %s", s_cfg.seed_token);
|
||||
esp_http_client_set_header(client, "Authorization", auth_hdr);
|
||||
}
|
||||
```
|
||||
|
||||
**Impact:** Bearer token can be sniffed on the local network, enabling unauthorized access to the Cognitum Seed ingest API.
|
||||
|
||||
**Remediation:**
|
||||
1. Validate that `seed_url` starts with `https://` in `swarm_bridge_init()` and reject `http://` URLs.
|
||||
2. Configure TLS certificate verification in the HTTP client config.
|
||||
3. Consider certificate pinning for the Seed server.
|
||||
|
||||
---
|
||||
|
||||
### MEDIUM-007: In-Memory Rate Limiter Does Not Bound Memory Growth (CWE-400)
|
||||
|
||||
**Severity:** MEDIUM
|
||||
**OWASP:** A04:2021 -- Insecure Design
|
||||
**Files:**
|
||||
- `v1/src/api/middleware/rate_limit.py:28-29` -- `self.request_counts = defaultdict(lambda: deque())`
|
||||
- `v1/src/middleware/rate_limit.py:132` -- `self._sliding_windows: Dict[str, SlidingWindowCounter] = {}`
|
||||
|
||||
**Description:**
|
||||
Both rate limiter implementations store per-client sliding window data in unbounded in-memory dictionaries. An attacker sending requests from many spoofed IPs (see HIGH-002) can create millions of entries, each containing a `deque` of timestamps. The cleanup tasks run only periodically (every 5 minutes or on-demand) and cannot keep pace with a high-rate attack.
|
||||
|
||||
**Impact:** Memory exhaustion denial of service through rate limiter state amplification.
|
||||
|
||||
**Remediation:**
|
||||
1. Cap the total number of tracked clients (e.g., 100,000 entries). Use an LRU eviction policy.
|
||||
2. Use a fixed-size data structure (e.g., a counter array with hash bucketing) instead of per-client deques.
|
||||
3. For production, use Redis-backed rate limiting with automatic key expiry.
|
||||
|
||||
---
|
||||
|
||||
### LOW-001: Test Script Contains Hardcoded Placeholder Secret (CWE-798)
|
||||
|
||||
**Severity:** LOW
|
||||
**OWASP:** A07:2021 -- Identification and Authentication Failures
|
||||
**File:** `v1/test_auth_rate_limit.py:26`
|
||||
|
||||
**Description:**
|
||||
A test script in the repository contains a hardcoded JWT secret key placeholder:
|
||||
|
||||
```python
|
||||
SECRET_KEY = "your-secret-key-here" # This should match your settings
|
||||
```
|
||||
|
||||
While marked with a comment indicating it should be changed, this file is checked into the repository and could be mistaken for a real configuration.
|
||||
|
||||
**Impact:** Low -- this is a test file, not production configuration. However, if a developer copies this value into production settings, JWT tokens become trivially forgeable.
|
||||
|
||||
**Remediation:**
|
||||
1. Replace with an environment variable reference: `SECRET_KEY = os.environ.get("SECRET_KEY", "")`.
|
||||
2. Add a validation check that fails if the secret is the placeholder value.
|
||||
|
||||
---
|
||||
|
||||
### LOW-002: User Information Exposed in Response Headers (CWE-200)
|
||||
|
||||
**Severity:** LOW
|
||||
**OWASP:** A01:2021 -- Broken Access Control
|
||||
**Files:**
|
||||
- `v1/src/middleware/auth.py:298-299` -- `response.headers["X-User"] = user_info["username"]` and `response.headers["X-User-Roles"] = ",".join(user_info["roles"])`
|
||||
- `v1/src/api/middleware/auth.py:111` -- `response.headers["X-User-ID"] = request.state.user.get("id", "")`
|
||||
|
||||
**Description:**
|
||||
Authenticated user information (username, roles, user ID) is included in HTTP response headers. These headers are visible to any intermediary (CDN, reverse proxy, browser extensions) and in browser developer tools.
|
||||
|
||||
**Impact:** Information disclosure of user identity and authorization roles to intermediaries and client-side code.
|
||||
|
||||
**Remediation:**
|
||||
1. Remove `X-User`, `X-User-Roles`, and `X-User-ID` response headers, or restrict them to internal/debug environments only.
|
||||
2. If needed for debugging, use a configuration flag to enable these headers.
|
||||
|
||||
---
|
||||
|
||||
### LOW-003: Deprecated `datetime.utcnow()` Usage (CWE-1235)
|
||||
|
||||
**Severity:** LOW
|
||||
**Files:** Throughout the Python codebase (auth.py, rate_limit.py, connection_manager.py, pose_stream.py, error_handler.py, stream.py)
|
||||
|
||||
**Description:**
|
||||
`datetime.utcnow()` is deprecated in Python 3.12+ in favor of `datetime.now(datetime.timezone.utc)`. While not a security vulnerability per se, timezone-naive datetimes can cause token expiry comparison bugs in environments where the system clock timezone differs from UTC.
|
||||
|
||||
**Remediation:**
|
||||
Replace all instances of `datetime.utcnow()` with `datetime.now(datetime.timezone.utc)`.
|
||||
|
||||
---
|
||||
|
||||
### LOW-004: JWT Algorithm Not Restricted to Asymmetric in Production (CWE-327)
|
||||
|
||||
**Severity:** LOW
|
||||
**OWASP:** A02:2021 -- Cryptographic Failures
|
||||
**File:** `v1/src/config/settings.py:30` -- `jwt_algorithm: str = Field(default="HS256")`
|
||||
|
||||
**Description:**
|
||||
The default JWT algorithm is HS256 (HMAC-SHA256), a symmetric algorithm. This means the same secret is used for both signing and verification, requiring the secret to be distributed to every service that needs to verify tokens. For multi-service architectures, asymmetric algorithms (RS256, ES256) are preferred.
|
||||
|
||||
Additionally, the `jwt_algorithm` setting is not validated against a safe algorithm allowlist, leaving open the possibility of configuration to `none` (no signature).
|
||||
|
||||
**Remediation:**
|
||||
1. Validate `jwt_algorithm` against an allowlist of safe algorithms: `["HS256", "HS384", "HS512", "RS256", "RS384", "RS512", "ES256", "ES384", "ES512"]`.
|
||||
2. Explicitly reject the `none` algorithm.
|
||||
3. For production deployments with multiple services, recommend RS256 or ES256.
|
||||
|
||||
---
|
||||
|
||||
### LOW-005: No Password Complexity Validation (CWE-521)
|
||||
|
||||
**Severity:** LOW
|
||||
**OWASP:** A07:2021 -- Identification and Authentication Failures
|
||||
**File:** `v1/src/middleware/auth.py:115` -- `create_user()` method
|
||||
|
||||
**Description:**
|
||||
The `create_user()` method accepts any password without minimum length, complexity, or entropy requirements. Test credentials in `v1/test_auth_rate_limit.py:21-23` demonstrate weak passwords ("admin123", "user123").
|
||||
|
||||
**Remediation:**
|
||||
1. Enforce minimum password length (12+ characters).
|
||||
2. Check passwords against a common-password blocklist.
|
||||
3. Require mixed character classes or calculate entropy.
|
||||
|
||||
---
|
||||
|
||||
### INFORMATIONAL-001: Rust API, DB, and Config Crates Are Stubs
|
||||
|
||||
**Files:**
|
||||
- `rust-port/wifi-densepose-rs/crates/wifi-densepose-api/src/lib.rs` -- `//! WiFi-DensePose REST API (stub)`
|
||||
- `rust-port/wifi-densepose-rs/crates/wifi-densepose-db/src/lib.rs` -- `//! WiFi-DensePose database layer (stub)`
|
||||
- `rust-port/wifi-densepose-rs/crates/wifi-densepose-config/src/lib.rs` -- `//! WiFi-DensePose configuration (stub)`
|
||||
|
||||
**Description:**
|
||||
The Rust API, database, and configuration crates contain only single-line stub comments. No security review of Rust API endpoints, database queries, or configuration handling was possible because no implementation exists. The `wifi-densepose-sensing-server` crate contains the actual Rust server implementation.
|
||||
|
||||
**Note:** The sensing server (`crates/wifi-densepose-sensing-server/src/main.rs`) was checked for SQL injection patterns, CORS issues, and authentication concerns. No SQL injection risks were found (no string-formatted queries). The server appears to use in-memory data structures rather than a database.
|
||||
|
||||
---
|
||||
|
||||
### INFORMATIONAL-002: Rust `unsafe` Blocks in WASM Edge Crate
|
||||
|
||||
**Files:** `rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/*.rs` (multiple files)
|
||||
|
||||
**Description:**
|
||||
The `wifi-densepose-wasm-edge` crate contains approximately 40 `unsafe` blocks, primarily for:
|
||||
1. Writing to static mutable event arrays (`static mut EVENTS: [...]`)
|
||||
2. Raw pointer casts for `repr(C)` struct serialization in `rvf.rs`
|
||||
|
||||
These patterns are common in `no_std` WASM edge environments where heap allocation is unavailable. The static event arrays use a fixed-size pattern (`EVENTS[..n]`) that prevents out-of-bounds writes as long as `n` is bounded correctly. Visual inspection of the bounds checks suggests they are correct, but formal verification or fuzzing of the bounds logic is recommended.
|
||||
|
||||
The main workspace crate (`wifi-densepose-train`) explicitly notes it avoids `unsafe` blocks.
|
||||
|
||||
---
|
||||
|
||||
### INFORMATIONAL-003: ESP32 Firmware C Code Uses Safe String Handling
|
||||
|
||||
**Files:** `firmware/esp32-csi-node/main/*.c`
|
||||
|
||||
**Description:**
|
||||
The firmware codebase consistently uses `strncpy` with explicit null termination, `snprintf` (not `sprintf`), and proper bounds checking throughout. No instances of `strcpy`, `strcat`, `sprintf`, or `gets` were found. Buffer sizes are defined via `#define` constants. The `rvf_parser.c` performs thorough size validation before any pointer arithmetic.
|
||||
|
||||
This is a positive finding reflecting good security practices.
|
||||
|
||||
---
|
||||
|
||||
## Dependency Analysis
|
||||
|
||||
### Python Dependencies (`requirements.txt`)
|
||||
|
||||
| Package | Version Spec | Risk |
|
||||
|---------|-------------|------|
|
||||
| `python-jose[cryptography]>=3.3.0` | MEDIUM -- python-jose has had JWT confusion vulnerabilities. Consider migrating to `PyJWT` or `authlib`. |
|
||||
| `paramiko>=3.0.0` | LOW -- SSH library. Ensure latest minor version for CVE patches. |
|
||||
| `fastapi>=0.95.0` | LOW -- Version floor is old. Pin to latest stable for security patches. |
|
||||
|
||||
**Recommendation:** Run `pip audit` or `safety check` against the locked dependency file (`v1/requirements-lock.txt`) to identify known CVEs.
|
||||
|
||||
### Rust Dependencies (`Cargo.toml`)
|
||||
|
||||
| Crate | Version | Notes |
|
||||
|-------|---------|-------|
|
||||
| `sqlx 0.7` | OK -- uses parameterized queries by design. |
|
||||
| `axum 0.7` | OK -- current major version. |
|
||||
| `wasm-bindgen 0.2` | OK -- standard WASM interface. |
|
||||
|
||||
**Recommendation:** Run `cargo audit` against `Cargo.lock` to check for known advisories.
|
||||
|
||||
---
|
||||
|
||||
## Positive Security Practices Observed
|
||||
|
||||
The following areas demonstrate security-conscious design:
|
||||
|
||||
1. **OTA PSK constant-time comparison** (`firmware/esp32-csi-node/main/ota_update.c:66-72`): Uses XOR-accumulator pattern to prevent timing attacks on authentication.
|
||||
|
||||
2. **WASM signature verification** (`firmware/esp32-csi-node/main/wasm_upload.c:112-137`): Ed25519 signature verification is enabled by default (`wasm_verify=1`). Unsigned uploads are rejected unless explicitly disabled via Kconfig.
|
||||
|
||||
3. **RVF build hash validation** (`firmware/esp32-csi-node/main/rvf_parser.c:126-137`): SHA-256 hash of the WASM payload is verified against the manifest before loading, preventing tampered module execution.
|
||||
|
||||
4. **Password hashing with bcrypt** (`v1/src/middleware/auth.py:21`): Proper use of `passlib` with `bcrypt` scheme.
|
||||
|
||||
5. **Protected user fields** (`v1/src/middleware/auth.py:139`): `update_user()` prevents modification of `username`, `created_at`, and `hashed_password`.
|
||||
|
||||
6. **Production error suppression** (`v1/src/middleware/error_handler.py:214-218`): The centralized error handler correctly suppresses internal details in production mode.
|
||||
|
||||
7. **No hardcoded secrets in source** (verified via entropy-based search across entire repository): No API keys, passwords, or tokens found in source files (the test script placeholder at `test_auth_rate_limit.py:26` is marked as requiring replacement).
|
||||
|
||||
8. **`.env` file excluded via `.gitignore`** (`.gitignore:171`): Environment files are properly excluded from version control.
|
||||
|
||||
9. **C string safety** (all `firmware/esp32-csi-node/main/*.c`): Consistent use of `strncpy`, `snprintf`, and null-termination guards. No unsafe C string functions.
|
||||
|
||||
10. **NVS input validation** (`firmware/esp32-csi-node/main/nvs_config.c`): Bounds checking on all NVS-loaded values (channel range, dwell time minimums, array index clamping).
|
||||
|
||||
---
|
||||
|
||||
## Files Examined
|
||||
|
||||
### Python (v1/src/)
|
||||
- `v1/src/middleware/auth.py` (457 lines) -- JWT auth, user management, middleware
|
||||
- `v1/src/middleware/rate_limit.py` (465 lines) -- Rate limiting with sliding window
|
||||
- `v1/src/middleware/cors.py` (375 lines) -- CORS middleware and validation
|
||||
- `v1/src/middleware/error_handler.py` (505 lines) -- Error handling middleware
|
||||
- `v1/src/api/middleware/auth.py` (303 lines) -- API-layer JWT auth
|
||||
- `v1/src/api/middleware/rate_limit.py` (326 lines) -- API-layer rate limiting
|
||||
- `v1/src/api/websocket/connection_manager.py` (461 lines) -- WebSocket manager
|
||||
- `v1/src/api/websocket/pose_stream.py` (384 lines) -- Pose streaming handler
|
||||
- `v1/src/api/routers/pose.py` (420 lines) -- Pose API endpoints
|
||||
- `v1/src/api/routers/stream.py` (465 lines) -- Streaming API endpoints
|
||||
- `v1/src/config/settings.py` (436 lines) -- Application settings
|
||||
- `v1/src/sensing/rssi_collector.py` (partial) -- Subprocess usage review
|
||||
- `v1/src/tasks/backup.py` (partial) -- Subprocess command construction
|
||||
- `v1/test_auth_rate_limit.py` (partial) -- Test credentials review
|
||||
|
||||
### Rust (rust-port/wifi-densepose-rs/)
|
||||
- `crates/wifi-densepose-api/src/lib.rs` (1 line -- stub)
|
||||
- `crates/wifi-densepose-db/src/lib.rs` (1 line -- stub)
|
||||
- `crates/wifi-densepose-config/src/lib.rs` (1 line -- stub)
|
||||
- `crates/wifi-densepose-wasm/src/lib.rs` (133 lines) -- WASM bindings
|
||||
- `crates/wifi-densepose-wasm/src/mat.rs` (partial) -- MAT dashboard
|
||||
- `crates/wifi-densepose-wasm-edge/src/*.rs` (unsafe block audit)
|
||||
- `crates/wifi-densepose-sensing-server/src/main.rs` (SQL injection pattern search)
|
||||
- `Cargo.toml` (workspace dependencies)
|
||||
|
||||
### C Firmware (firmware/esp32-csi-node/main/)
|
||||
- `main.c` (302 lines) -- Application entry point
|
||||
- `nvs_config.c` (333 lines) -- NVS configuration loading
|
||||
- `nvs_config.h` (77 lines) -- Configuration struct definitions
|
||||
- `stream_sender.c` (117 lines) -- UDP stream sender
|
||||
- `ota_update.c` (267 lines) -- OTA firmware update
|
||||
- `wasm_upload.c` (433 lines) -- WASM module management
|
||||
- `rvf_parser.c` (169+ lines) -- RVF container parser
|
||||
- `swarm_bridge.c` (328 lines) -- Cognitum Seed bridge
|
||||
|
||||
### Configuration & Dependencies
|
||||
- `requirements.txt` (47 lines)
|
||||
- `.gitignore` (verified .env exclusion)
|
||||
|
||||
---
|
||||
|
||||
## Patterns Checked
|
||||
|
||||
| Check Category | Patterns Searched | Result |
|
||||
|---------------|-------------------|--------|
|
||||
| Hardcoded secrets | `password=`, `secret_key=`, `api_key=`, high-entropy strings | Clean (1 test placeholder found) |
|
||||
| SQL injection | String-formatted SQL queries (`format!` + SQL keywords, f-string + SQL) | Clean |
|
||||
| Command injection | `subprocess` with user input, `os.system`, `eval` | Safe (fixed command arrays only) |
|
||||
| Path traversal | User-controlled file paths without sanitization | Not applicable (no file serving endpoints) |
|
||||
| Insecure deserialization | `pickle.loads`, `yaml.unsafe_load`, `eval` on user input | Clean |
|
||||
| Weak cryptography | `md5`, `sha1` for security, `DES`, `RC4` | Clean (uses bcrypt, SHA-256, Ed25519) |
|
||||
| Unsafe C functions | `strcpy`, `strcat`, `sprintf`, `gets` | Clean (uses safe alternatives throughout) |
|
||||
| Unsafe Rust blocks | `unsafe { ... }` in workspace crates | ~40 in wasm-edge (acceptable for no_std) |
|
||||
| `.env` files committed | `.env`, `.env.local`, `.env.production` | Clean (properly gitignored) |
|
||||
| CORS misconfiguration | Wildcard + credentials | Found (MEDIUM-001) |
|
||||
|
||||
---
|
||||
|
||||
## Remediation Priority
|
||||
|
||||
| Priority | Finding | Effort | Impact |
|
||||
|----------|---------|--------|--------|
|
||||
| 1 | HIGH-002: Rate limiter IP spoofing | Low | Eliminates rate limiting bypass |
|
||||
| 2 | HIGH-001: WebSocket token in URL | Medium | Prevents credential leakage |
|
||||
| 3 | HIGH-003: Error detail exposure | Low | Prevents information disclosure |
|
||||
| 4 | MEDIUM-003: Token blacklist not enforced | Medium | Enables logout functionality |
|
||||
| 5 | MEDIUM-004: OTA default no-auth | Low | Prevents unauthorized firmware flash |
|
||||
| 6 | MEDIUM-002: WebSocket message limits | Low | Prevents DoS via large messages |
|
||||
| 7 | MEDIUM-001: CORS wildcard + credentials | Low | Prevents CSRF-like attacks |
|
||||
| 8 | MEDIUM-005: UDP stream no encryption | High | Adds transport security |
|
||||
| 9 | MEDIUM-006: Swarm bridge cleartext | Medium | Protects Seed authentication |
|
||||
| 10 | MEDIUM-007: Rate limiter memory growth | Medium | Prevents state amplification DoS |
|
||||
|
||||
---
|
||||
|
||||
## Security Score
|
||||
|
||||
| Category | Score | Max | Notes |
|
||||
|----------|-------|-----|-------|
|
||||
| Authentication | 6/10 | 10 | Good JWT implementation; token blacklist non-functional |
|
||||
| Authorization | 8/10 | 10 | Role-based access control present; missing RBAC on some endpoints |
|
||||
| Input Validation | 8/10 | 10 | Pydantic models, NVS bounds checks; WebSocket lacks size limits |
|
||||
| Cryptography | 7/10 | 10 | bcrypt, Ed25519, SHA-256; UDP transport unencrypted |
|
||||
| Configuration | 6/10 | 10 | Good validation functions; unsafe defaults for development |
|
||||
| Error Handling | 7/10 | 10 | Centralized handler good; per-endpoint leaks |
|
||||
| Transport Security | 5/10 | 10 | No TLS enforcement for firmware; no DTLS for UDP |
|
||||
| Dependency Security | 7/10 | 10 | Reasonable version floors; no pinned versions |
|
||||
| Firmware Security | 7/10 | 10 | OTA auth optional; WASM verification strong |
|
||||
| Logging/Monitoring | 7/10 | 10 | Comprehensive logging; token blacklist not wired |
|
||||
|
||||
**Overall Security Score: 68/100**
|
||||
|
||||
---
|
||||
|
||||
*Generated by QE Security Reviewer (V3) -- Domain: security-compliance (ADR-008)*
|
||||
@@ -1,795 +0,0 @@
|
||||
# Performance Analysis Report -- WiFi-DensePose
|
||||
|
||||
**Report ID**: QE-PERF-003
|
||||
**Date**: 2026-04-05
|
||||
**Analyst**: QE Performance Reviewer (V3, chaos-resilience domain)
|
||||
**Scope**: Rust signal processing, NN inference, Python pipeline, ESP32 firmware
|
||||
**Files Examined**: 32 source files across 4 codebases
|
||||
**Weighted Finding Score**: 14.25 (minimum threshold: 2.0)
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
The WiFi-DensePose codebase is a real-time sensing system targeting 20 Hz output (50 ms budget per frame). The analysis identified **4 CRITICAL**, **6 HIGH**, **8 MEDIUM**, and **5 LOW** performance findings across Rust signal processing, neural network inference, Python pipeline, and ESP32 firmware. The most impactful issues are: (1) an O(n*K*S) top-K selection in the ESP32 firmware hot path, (2) O(L * V) tomographic weight computation on every frame, (3) serial batch inference in the NN crate, and (4) excessive heap allocation in the Python CSI pipeline's Doppler extraction. Estimated combined latency savings from addressing CRITICAL and HIGH findings: 15-40 ms per frame (30-80% of the 50 ms budget).
|
||||
|
||||
---
|
||||
|
||||
## 1. Rust Signal Processing -- RuvSense Modules
|
||||
|
||||
### Files Analyzed
|
||||
|
||||
| File | Lines | Hot Path | Complexity |
|
||||
|------|-------|----------|------------|
|
||||
| `ruvsense/tomography.rs` | 689 | Moderate (periodic) | O(I * L * V) |
|
||||
| `ruvsense/multistatic.rs` | 562 | Critical (every frame) | O(N * S) |
|
||||
| `ruvsense/pose_tracker.rs` | 600+ | Critical (every frame) | O(T * D * K) |
|
||||
| `ruvsense/field_model.rs` | 400+ | Calibration + runtime | O(S^2) calibration, O(K * S) runtime |
|
||||
| `ruvsense/gesture.rs` | 579 | On-demand | O(T * N * M * F) |
|
||||
| `ruvsense/coherence.rs` | 464 | Critical (every frame) | O(S) |
|
||||
| `ruvsense/phase_align.rs` | 150+ | Critical (every frame) | O(C * S) |
|
||||
| `ruvsense/multiband.rs` | 150+ | Critical (every frame) | O(C * S) |
|
||||
| `ruvsense/adversarial.rs` | 150+ | Every frame | O(L^2) |
|
||||
| `ruvsense/intention.rs` | 100+ | Every frame | O(W * D) |
|
||||
| `ruvsense/longitudinal.rs` | 100+ | Daily | O(1) per update |
|
||||
| `ruvsense/cross_room.rs` | 100+ | On transition | O(E * P) |
|
||||
| `ruvsense/coherence_gate.rs` | 100+ | Every frame | O(1) |
|
||||
| `ruvsense/mod.rs` | 328 | Orchestrator | N/A |
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-R01: Tomography Weight Matrix -- O(L * nx * ny * nz) per Link [CRITICAL]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/tomography.rs`
|
||||
**Lines**: 345-383 (`compute_link_weights`)
|
||||
|
||||
The `compute_link_weights` function iterates over every voxel in the grid for every link to compute Fresnel-zone intersection weights:
|
||||
|
||||
```rust
|
||||
for iz in 0..config.nz {
|
||||
for iy in 0..config.ny {
|
||||
for ix in 0..config.nx {
|
||||
// point_to_segment_distance per voxel
|
||||
let dist = point_to_segment_distance(...);
|
||||
if dist < fresnel_radius {
|
||||
weights.push((idx, w));
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Impact**: With default grid 8x8x4 = 256 voxels and 12 links, this is 3,072 distance calculations at construction time. However, if the grid is scaled to 16x16x8 = 2,048 voxels with 24 links, this becomes 49,152 calculations. Each involves a sqrt() and 6 multiplications.
|
||||
|
||||
**Impact on ISTA Solver (lines 264-307)**: The reconstruct() method runs up to 100 iterations, each computing O(L * average_weights_per_link) for forward pass and the same for gradient accumulation. With dense weight matrices, this dominates the frame budget.
|
||||
|
||||
**Severity**: CRITICAL -- Blocks real-time operation at higher grid resolutions.
|
||||
|
||||
**Recommendation**:
|
||||
1. Use Bresenham-style ray marching (3D DDA) instead of brute-force voxel scan -- reduces from O(V) to O(max(nx,ny,nz)) per link.
|
||||
2. Precompute weight matrix once, store as CSR sparse format for cache-friendly iteration.
|
||||
3. Use FISTA (Fast ISTA) with Nesterov momentum for 2-3x faster convergence.
|
||||
|
||||
**Estimated Savings**: 5-10x for weight computation, 2-3x for solver convergence.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-R02: Multistatic Fusion -- sin()/cos() per Subcarrier per Node [HIGH]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs`
|
||||
**Lines**: 287-298 (`attention_weighted_fusion`)
|
||||
|
||||
```rust
|
||||
for (n, (&, &ph)) in amplitudes.iter().zip(phases.iter()).enumerate() {
|
||||
let w = weights[n];
|
||||
for i in 0..n_sub {
|
||||
fused_amp[i] += w * amp[i];
|
||||
fused_ph_sin[i] += w * ph[i].sin(); // transcendental per element
|
||||
fused_ph_cos[i] += w * ph[i].cos(); // transcendental per element
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Impact**: With N=4 nodes and S=56 subcarriers, this is 448 sin() + 448 cos() = 896 transcendental function calls per frame at 20 Hz = 17,920/sec. On typical hardware, each sin/cos takes ~20ns, totaling ~18 us/frame. Not blocking by itself, but avoidable.
|
||||
|
||||
**Severity**: HIGH -- Unnecessary CPU in hot path.
|
||||
|
||||
**Recommendation**:
|
||||
1. Use `sincos()` or `(ph.sin(), ph.cos())` as a single call where the compiler can fuse.
|
||||
2. Pre-compute sin/cos of phase vectors before the fusion loop using SIMD (via `packed_simd` or `std::simd`).
|
||||
3. Alternative: Store phase as phasor (sin, cos) pairs throughout the pipeline, avoiding conversion entirely.
|
||||
|
||||
**Estimated Savings**: 2-3x for phase fusion, eliminates transcendental calls.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-R03: Pose Tracker find_track -- Linear Search [MEDIUM]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/pose_tracker.rs`
|
||||
**Lines**: 546-553
|
||||
|
||||
```rust
|
||||
pub fn find_track(&self, id: TrackId) -> Option<&PoseTrack> {
|
||||
self.tracks.iter().find(|t| t.id == id)
|
||||
}
|
||||
```
|
||||
|
||||
**Impact**: Linear O(T) search for each track lookup. With T <= 10 tracks in typical usage, this is negligible. However, `active_tracks()` and `active_count()` also do full scans with `filter()`.
|
||||
|
||||
**Severity**: MEDIUM -- Low impact at current scale, but would degrade with many tracks.
|
||||
|
||||
**Recommendation**: Use a `HashMap<TrackId, usize>` index for O(1) lookup if track count grows beyond 20.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-R04: Multistatic FusedSensingFrame -- Deep Clone of node_frames [HIGH]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs`
|
||||
**Line**: 222
|
||||
|
||||
```rust
|
||||
Ok(FusedSensingFrame {
|
||||
...
|
||||
node_frames: node_frames.to_vec(), // deep clone of all MultiBandCsiFrame structs
|
||||
...
|
||||
})
|
||||
```
|
||||
|
||||
**Impact**: Each `MultiBandCsiFrame` contains `Vec<CanonicalCsiFrame>` with amplitude and phase vectors. With N=4 nodes, each containing 3 channels of 56 subcarriers, this clones 4 * 3 * 56 * 2 * 4 bytes = 5,376 bytes of float data plus Vec heap allocations. At 20 Hz = 107 KB/s of unnecessary heap churn.
|
||||
|
||||
**Severity**: HIGH -- Unnecessary allocation in the hottest path.
|
||||
|
||||
**Recommendation**:
|
||||
1. Accept `Vec<MultiBandCsiFrame>` by move instead of borrowing then cloning.
|
||||
2. Alternatively, use `Arc<[MultiBandCsiFrame]>` for zero-copy sharing.
|
||||
3. Use a pre-allocated buffer pool with frame recycling.
|
||||
|
||||
**Estimated Savings**: Eliminates ~5 KB allocation + copy per frame.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-R05: Coherence Score -- Efficient but exp() in Hot Loop [LOW]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/coherence.rs`
|
||||
**Lines**: 224-252 (`coherence_score`)
|
||||
|
||||
```rust
|
||||
for i in 0..n {
|
||||
let var = variance[i].max(epsilon);
|
||||
let z = (current[i] - reference[i]).abs() / var.sqrt();
|
||||
let weight = 1.0 / (var + epsilon);
|
||||
let likelihood = (-0.5 * z * z).exp(); // exp() per subcarrier
|
||||
weighted_sum += likelihood * weight;
|
||||
weight_sum += weight;
|
||||
}
|
||||
```
|
||||
|
||||
**Impact**: 56 exp() calls per frame at 20 Hz = 1,120/sec. Each exp() ~10ns = ~11 us total. Additionally, sqrt() per iteration.
|
||||
|
||||
**Severity**: LOW -- Under 15 us total, within budget.
|
||||
|
||||
**Recommendation**: Use fast_exp approximation or lookup table for the Gaussian kernel if profiling shows this as a bottleneck. Could also batch with SIMD.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-R06: Gesture DTW -- O(N * M) per Template [MEDIUM]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/gesture.rs`
|
||||
**Lines**: 288-328 (`dtw_distance`)
|
||||
|
||||
The DTW implementation uses the Sakoe-Chiba band constraint (good), but allocates two full Vec<f64> per call:
|
||||
|
||||
```rust
|
||||
let mut prev = vec![f64::INFINITY; m + 1]; // heap allocation
|
||||
let mut curr = vec![f64::INFINITY; m + 1]; // heap allocation
|
||||
```
|
||||
|
||||
With T templates and band_width=5, complexity is O(T * N * band_width * feature_dim). The feature_dim inner loop (euclidean_distance) is also not vectorized.
|
||||
|
||||
**Impact**: For 5 templates, 20 frames, 8 features, band_width=5: 5 * 20 * 5 * 8 = 4,000 operations per classification. Acceptable for on-demand use but costly if called every frame.
|
||||
|
||||
**Severity**: MEDIUM -- Acceptable for on-demand, but allocation should be eliminated.
|
||||
|
||||
**Recommendation**:
|
||||
1. Pre-allocate DTW scratch buffers in the GestureClassifier struct.
|
||||
2. Use SmallVec or stack arrays for typical sequence lengths.
|
||||
3. Consider early termination: if partial DTW cost exceeds current best, abort.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-R07: Field Model Covariance -- O(S^2) Memory [MEDIUM]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/field_model.rs`
|
||||
**Line**: 330 (`covariance_sum: Option<Array2<f64>>`)
|
||||
|
||||
The full covariance matrix for SVD is S x S where S = number of subcarriers. With S=56, this is 56 * 56 * 8 = 25 KB -- reasonable. But the diagonal_fallback (lines 338-383) creates unnecessary intermediate allocations.
|
||||
|
||||
**Severity**: MEDIUM -- Calibration-phase only, but the fallback path allocates on every call.
|
||||
|
||||
**Recommendation**: Pre-allocate the indices vector in the struct to avoid repeated allocation during fallback.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-R08: Multiband Duplicate Frequency Check -- O(N^2) [LOW]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multiband.rs`
|
||||
**Lines**: 126-135
|
||||
|
||||
```rust
|
||||
for i in 0..self.frequencies.len() {
|
||||
for j in (i + 1)..self.frequencies.len() {
|
||||
if self.frequencies[i] == self.frequencies[j] {
|
||||
return Err(...);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Impact**: With N=3 channels, this is 3 comparisons. Negligible.
|
||||
|
||||
**Severity**: LOW -- N is tiny (3-6 channels max).
|
||||
|
||||
**Recommendation**: No action needed at current scale. If N grows, use a HashSet.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-R09: Adversarial Detector -- Potential O(L^2) Consistency Check [MEDIUM]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/adversarial.rs`
|
||||
**Lines**: 147+
|
||||
|
||||
The multi-link consistency check compares energy ratios across all links. With L=12 links, the pairwise comparison (if implemented) would be O(L^2) = 144. Combined with the four independent checks (consistency, field model, temporal, energy), this runs on every frame.
|
||||
|
||||
**Severity**: MEDIUM -- O(L^2) with L=12 is acceptable, but should be monitored if link count grows.
|
||||
|
||||
**Recommendation**: Document maximum supported link count. Consider using pre-sorted energy lists for O(L log L) consistency checking.
|
||||
|
||||
---
|
||||
|
||||
## 2. Rust Neural Network Inference
|
||||
|
||||
### Files Analyzed
|
||||
|
||||
| File | Lines | Role |
|
||||
|------|-------|------|
|
||||
| `wifi-densepose-nn/src/inference.rs` | 569 | Inference engine |
|
||||
| `wifi-densepose-nn/src/tensor.rs` | 100+ | Tensor abstraction |
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-NN01: Serial Batch Inference [CRITICAL]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`
|
||||
**Lines**: 334-336
|
||||
|
||||
```rust
|
||||
pub fn infer_batch(&self, inputs: &[Tensor]) -> NnResult<Vec<Tensor>> {
|
||||
inputs.iter().map(|input| self.infer(input)).collect()
|
||||
}
|
||||
```
|
||||
|
||||
**Impact**: Batch inference is implemented as sequential single-input calls. This completely negates GPU batching benefits and prevents ONNX Runtime from parallelizing across batch dimensions. For batch_size=4, this is 4x the latency of a properly batched inference.
|
||||
|
||||
**Severity**: CRITICAL -- Defeats the purpose of batch inference.
|
||||
|
||||
**Recommendation**:
|
||||
1. Concatenate inputs along batch dimension into a single tensor.
|
||||
2. Run a single backend.run() call with the batched tensor.
|
||||
3. Split output tensor back into individual results.
|
||||
|
||||
**Estimated Savings**: 2-4x latency reduction for batched inference.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-NN02: Async Stats Update Spawns Tokio Task per Inference [HIGH]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`
|
||||
**Lines**: 311-315
|
||||
|
||||
```rust
|
||||
let stats = self.stats.clone();
|
||||
tokio::spawn(async move {
|
||||
let mut stats = stats.write().await;
|
||||
stats.record(elapsed_ms);
|
||||
});
|
||||
```
|
||||
|
||||
**Impact**: Every single inference call spawns a new Tokio task just to record timing statistics. At 20 Hz inference rate, this creates 20 tasks/second, each acquiring an RwLock write guard. The task creation overhead (~1-5 us) and lock contention are unnecessary.
|
||||
|
||||
**Severity**: HIGH -- Unnecessary async overhead in synchronous hot path.
|
||||
|
||||
**Recommendation**:
|
||||
1. Use `AtomicU64` for total count and `AtomicF64` (or a lock-free accumulator) for timing.
|
||||
2. Alternatively, use `try_write()` and skip stats update if lock is contended.
|
||||
3. Best: Use a thread-local accumulator with periodic flush.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-NN03: Tensor Clone in run_single [MEDIUM]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`
|
||||
**Lines**: 122
|
||||
|
||||
```rust
|
||||
fn run_single(&self, input: &Tensor) -> NnResult<Tensor> {
|
||||
let mut inputs = HashMap::new();
|
||||
inputs.insert(input_names[0].clone(), input.clone()); // full tensor clone
|
||||
```
|
||||
|
||||
**Impact**: The default `run_single` implementation clones the entire input tensor to put it into a HashMap. For a [1, 256, 64, 64] tensor of f32, that is 4 MB of data copied unnecessarily.
|
||||
|
||||
**Severity**: MEDIUM -- 4 MB copy at 20 Hz = 80 MB/s of unnecessary bandwidth.
|
||||
|
||||
**Recommendation**: Accept input by value (move semantics) or use a reference-counted tensor.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-NN04: WiFiDensePosePipeline -- Two Sequential Inferences [MEDIUM]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`
|
||||
**Lines**: 389-413
|
||||
|
||||
```rust
|
||||
pub fn run(&self, csi_input: &Tensor) -> NnResult<DensePoseOutput> {
|
||||
let visual_features = self.translator_backend.run_single(csi_input)?;
|
||||
let outputs = self.densepose_backend.run(inputs)?;
|
||||
```
|
||||
|
||||
**Impact**: The pipeline runs two separate inference calls sequentially: CSI-to-visual translator, then DensePose head. If each takes 10-15 ms, total is 20-30 ms -- consuming 40-60% of the 50 ms frame budget on inference alone.
|
||||
|
||||
**Severity**: MEDIUM -- Architectural constraint, but pipelining is possible.
|
||||
|
||||
**Recommendation**:
|
||||
1. Implement pipeline parallelism: while frame N's DensePose runs, start frame N+1's translator.
|
||||
2. Consider fusing the two models into a single ONNX graph for optimized execution.
|
||||
3. Profile to determine actual bottleneck -- translator or DensePose head.
|
||||
|
||||
---
|
||||
|
||||
## 3. Python Real-Time Pipeline
|
||||
|
||||
### Files Analyzed
|
||||
|
||||
| File | Lines | Role |
|
||||
|------|-------|------|
|
||||
| `v1/src/core/csi_processor.py` | 467 | CSI processing pipeline |
|
||||
| `v1/src/services/pose_service.py` | 200+ | Pose estimation service |
|
||||
| `v1/src/api/websocket/connection_manager.py` | 461 | WebSocket management |
|
||||
| `v1/src/sensing/feature_extractor.py` | 150+ | RSSI feature extraction |
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-PY01: Doppler Feature Extraction -- list() Conversion of deque [CRITICAL]
|
||||
|
||||
**File**: `v1/src/core/csi_processor.py`
|
||||
**Lines**: 412-414
|
||||
|
||||
```python
|
||||
cache_list = list(self._phase_cache) # O(n) copy of entire deque
|
||||
phase_matrix = np.array(cache_list[-window:]) # another copy
|
||||
```
|
||||
|
||||
**Impact**: Every frame converts the entire phase_cache deque (up to 500 entries) to a list, then slices and converts to numpy. With 500 entries of 56-element arrays, this copies ~112 KB per frame. At 20 Hz, that is 2.2 MB/s of unnecessary Python object creation and GC pressure.
|
||||
|
||||
**Severity**: CRITICAL -- Major allocation in the hot path.
|
||||
|
||||
**Recommendation**:
|
||||
1. Use a pre-allocated numpy circular buffer instead of a deque of arrays.
|
||||
2. Maintain a write pointer and wrap around, avoiding all list/deque conversions.
|
||||
3. Implementation sketch:
|
||||
```python
|
||||
class CircularBuffer:
|
||||
def __init__(self, max_len, feature_dim):
|
||||
self.buf = np.zeros((max_len, feature_dim), dtype=np.float32)
|
||||
self.idx = 0
|
||||
self.count = 0
|
||||
```
|
||||
|
||||
**Estimated Savings**: Eliminates ~112 KB allocation per frame, reduces GC pressure by >90%.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-PY02: CSI Preprocessing Creates 3 New CSIData Objects per Frame [HIGH]
|
||||
|
||||
**File**: `v1/src/core/csi_processor.py`
|
||||
**Lines**: 118-377
|
||||
|
||||
The preprocessing pipeline creates a new CSIData object at each step:
|
||||
|
||||
```python
|
||||
cleaned_data = self._remove_noise(csi_data) # new CSIData + dict merge
|
||||
windowed_data = self._apply_windowing(cleaned_data) # new CSIData + dict merge
|
||||
normalized_data = self._normalize_amplitude(windowed_data) # new CSIData + dict merge
|
||||
```
|
||||
|
||||
Each CSIData construction copies metadata via `{**csi_data.metadata, 'key': True}`, creating a new dict each time.
|
||||
|
||||
**Impact**: 3 CSIData allocations + 3 dict merges + 3 numpy array operations per frame. The dict merges create O(n) copies of the metadata dictionary each time.
|
||||
|
||||
**Severity**: HIGH -- Unnecessary object churn in hot path.
|
||||
|
||||
**Recommendation**:
|
||||
1. Mutate arrays in-place instead of creating new CSIData objects.
|
||||
2. Use a mutable processing context that carries arrays through the pipeline.
|
||||
3. Accumulate metadata flags in a separate lightweight structure.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-PY03: Correlation Matrix -- Full np.corrcoef on Every Frame [MEDIUM]
|
||||
|
||||
**File**: `v1/src/core/csi_processor.py`
|
||||
**Lines**: 391-395
|
||||
|
||||
```python
|
||||
def _extract_correlation_features(self, csi_data: CSIData) -> np.ndarray:
|
||||
correlation_matrix = np.corrcoef(csi_data.amplitude)
|
||||
return correlation_matrix
|
||||
```
|
||||
|
||||
**Impact**: `np.corrcoef` computes the full NxN correlation matrix where N = number of antennas (typically 3). For 3x3, this is fast. However, if amplitude has shape (num_antennas, num_subcarriers) = (3, 56), corrcoef computes 3x3 matrix -- acceptable. But if amplitude is (56, 3) or another shape, this could produce a 56x56 matrix, which involves O(56^2 * 3) = 9,408 operations per frame.
|
||||
|
||||
**Severity**: MEDIUM -- Depends on actual amplitude shape; could be 100x more expensive than expected.
|
||||
|
||||
**Recommendation**: Validate and document the expected shape. If only antenna-pair correlations are needed, compute them directly without the full matrix.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-PY04: WebSocket Broadcast -- Sequential Send to All Clients [MEDIUM]
|
||||
|
||||
**File**: `v1/src/api/websocket/connection_manager.py`
|
||||
**Lines**: 230-264
|
||||
|
||||
```python
|
||||
async def broadcast(self, data, stream_type=None, zone_ids=None, **filters):
|
||||
for client_id in matching_clients:
|
||||
success = await self.send_to_client(client_id, data) # sequential await
|
||||
```
|
||||
|
||||
**Impact**: Each WebSocket send is awaited sequentially. With 10 connected clients and ~1 ms per send, broadcast takes ~10 ms per frame -- 20% of the frame budget spent on I/O serialization.
|
||||
|
||||
**Severity**: MEDIUM -- Scales linearly with client count.
|
||||
|
||||
**Recommendation**: Use `asyncio.gather()` to send to all clients concurrently:
|
||||
```python
|
||||
tasks = [self.send_to_client(cid, data) for cid in matching_clients]
|
||||
results = await asyncio.gather(*tasks, return_exceptions=True)
|
||||
```
|
||||
|
||||
**Estimated Savings**: Reduces broadcast from O(N * latency) to O(latency).
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-PY05: get_recent_history -- Copies Entire History [LOW]
|
||||
|
||||
**File**: `v1/src/core/csi_processor.py`
|
||||
**Lines**: 284-297
|
||||
|
||||
```python
|
||||
def get_recent_history(self, count: int) -> List[CSIData]:
|
||||
if count >= len(self.csi_history):
|
||||
return list(self.csi_history) # full copy
|
||||
else:
|
||||
return list(self.csi_history)[-count:] # full copy then slice
|
||||
```
|
||||
|
||||
**Impact**: Both branches create a full list copy of the deque before potentially slicing. With 500 entries, this creates a list of 500 references unnecessarily.
|
||||
|
||||
**Severity**: LOW -- Only called on-demand, not in hot path.
|
||||
|
||||
**Recommendation**: Use `itertools.islice` for the windowed case, or index directly into the deque.
|
||||
|
||||
---
|
||||
|
||||
## 4. ESP32 Firmware
|
||||
|
||||
### Files Analyzed
|
||||
|
||||
| File | Lines | Role |
|
||||
|------|-------|------|
|
||||
| `firmware/esp32-csi-node/main/csi_collector.c` | 421 | CSI callback + channel hopping |
|
||||
| `firmware/esp32-csi-node/main/edge_processing.c` | 1000+ | On-device DSP pipeline |
|
||||
| `firmware/esp32-csi-node/main/edge_processing.h` | 219 | Constants and structures |
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-FW01: Top-K Subcarrier Selection -- O(K * S) with K=8, S=128 [HIGH]
|
||||
|
||||
**File**: `firmware/esp32-csi-node/main/edge_processing.c`
|
||||
**Lines**: 301-330 (`update_top_k`)
|
||||
|
||||
```c
|
||||
for (uint8_t ki = 0; ki < k; ki++) {
|
||||
double best_var = -1.0;
|
||||
uint8_t best_idx = 0;
|
||||
for (uint16_t sc = 0; sc < n_subcarriers; sc++) {
|
||||
if (!used[sc]) {
|
||||
double v = welford_variance(&s_subcarrier_var[sc]);
|
||||
if (v > best_var) {
|
||||
best_var = v;
|
||||
best_idx = (uint8_t)sc;
|
||||
}
|
||||
}
|
||||
}
|
||||
s_top_k[ki] = best_idx;
|
||||
used[best_idx] = true;
|
||||
}
|
||||
```
|
||||
|
||||
**Impact**: Runs K=8 passes over S=128 subcarriers = 1,024 iterations with `welford_variance()` call each (2 divisions). On ESP32-S3 at 240 MHz with no FPU for doubles, each division takes ~50 cycles, totaling ~102,400 cycles = ~427 us per call. This runs on every frame at 20 Hz.
|
||||
|
||||
**Severity**: HIGH -- 427 us is nearly 1% of the 50 ms frame budget, and double-precision division on ESP32 is expensive.
|
||||
|
||||
**Recommendation**:
|
||||
1. Use `float` instead of `double` for variance -- ESP32-S3 has single-precision FPU.
|
||||
2. Pre-compute variances into a float array, then find top-K with a single partial sort.
|
||||
3. Use `nth_element`-style partial sort (O(S + K log K) instead of O(K * S)).
|
||||
4. Cache variance values and only recompute when Welford count changes.
|
||||
|
||||
**Estimated Savings**: 5-10x by switching to float + partial sort.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-FW02: Static Memory Layout -- Large BSS Usage [MEDIUM]
|
||||
|
||||
**File**: `firmware/esp32-csi-node/main/edge_processing.c`
|
||||
**Lines**: 224-287
|
||||
|
||||
The module declares substantial static arrays:
|
||||
|
||||
| Variable | Size | Notes |
|
||||
|----------|------|-------|
|
||||
| `s_subcarrier_var[128]` | 128 * 24 = 3,072 bytes | Welford structs (mean, m2, count) |
|
||||
| `s_prev_phase[128]` | 512 bytes | float array |
|
||||
| `s_phase_history[256]` | 1,024 bytes | float array |
|
||||
| `s_breathing_filtered[256]` | 1,024 bytes | float array |
|
||||
| `s_heartrate_filtered[256]` | 1,024 bytes | float array |
|
||||
| `s_scratch_br[256]` | 1,024 bytes | float array |
|
||||
| `s_scratch_hr[256]` | 1,024 bytes | float array |
|
||||
| `s_prev_iq[1024]` | 1,024 bytes | delta compression |
|
||||
| `s_person_br_filt[4][256]` | 4,096 bytes | per-person BR filter |
|
||||
| `s_person_hr_filt[4][256]` | 4,096 bytes | per-person HR filter |
|
||||
| Ring buffer (16 slots * 1024+) | ~17 KB | SPSC ring |
|
||||
| **Total BSS** | **~34 KB** | |
|
||||
|
||||
**Impact**: ESP32-S3 has 512 KB SRAM. This module alone uses ~34 KB (6.6%). Combined with WiFi stack (~50 KB), FreeRTOS (~20 KB), and other modules, total RAM usage may approach limits on 4MB flash variants.
|
||||
|
||||
**Severity**: MEDIUM -- Acceptable on 8MB variant, may be tight on 4MB SuperMini.
|
||||
|
||||
**Recommendation**:
|
||||
1. Reduce `EDGE_PHASE_HISTORY_LEN` from 256 to 128 on 4MB builds (saves ~6 KB).
|
||||
2. Consider using `EDGE_MAX_PERSONS=2` on constrained builds (saves ~4 KB).
|
||||
3. Add build-time assertion for total BSS usage.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-FW03: CSI Callback Rate Limiting -- Correct but Coarse [LOW]
|
||||
|
||||
**File**: `firmware/esp32-csi-node/main/csi_collector.c`
|
||||
**Lines**: 177-195
|
||||
|
||||
```c
|
||||
int64_t now = esp_timer_get_time();
|
||||
if ((now - s_last_send_us) >= CSI_MIN_SEND_INTERVAL_US) {
|
||||
int ret = stream_sender_send(frame_buf, frame_len);
|
||||
```
|
||||
|
||||
**Impact**: Rate limiting at 50 Hz (20 ms interval) is correct. The `memcpy` at line 175 (`csi_serialize_frame`) runs on every callback even if the frame will be rate-skipped. With callbacks firing at 100-500 Hz in promiscuous mode, this wastes 80-90% of serialization effort.
|
||||
|
||||
**Severity**: LOW -- memcpy of ~300 bytes is ~1 us, acceptable.
|
||||
|
||||
**Recommendation**: Move rate limit check before serialization to skip unnecessary work:
|
||||
```c
|
||||
int64_t now = esp_timer_get_time();
|
||||
if ((now - s_last_send_us) < CSI_MIN_SEND_INTERVAL_US) {
|
||||
s_rate_skip++;
|
||||
return; // skip serialization entirely
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-FW04: atan2f() per Subcarrier in Phase Extraction [LOW]
|
||||
|
||||
**File**: `firmware/esp32-csi-node/main/edge_processing.c`
|
||||
**Lines**: 134-139
|
||||
|
||||
```c
|
||||
static inline float extract_phase(const uint8_t *iq, uint16_t idx)
|
||||
{
|
||||
int8_t i_val = (int8_t)iq[idx * 2];
|
||||
int8_t q_val = (int8_t)iq[idx * 2 + 1];
|
||||
return atan2f((float)q_val, (float)i_val);
|
||||
}
|
||||
```
|
||||
|
||||
**Impact**: Called for each subcarrier (up to 128) per frame. atan2f on ESP32-S3 takes ~100 cycles with FPU = ~0.4 us per call. 128 calls = ~51 us per frame. Acceptable.
|
||||
|
||||
**Severity**: LOW -- Within budget.
|
||||
|
||||
**Recommendation**: If profiling reveals this as a bottleneck, use a CORDIC-based atan2 approximation (10-20 cycles instead of 100).
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-FW05: Lock-Free Ring Buffer -- Correct but Not Power-of-2 [LOW]
|
||||
|
||||
**File**: `firmware/esp32-csi-node/main/edge_processing.c`
|
||||
**Lines**: 55-56
|
||||
|
||||
```c
|
||||
uint32_t next = (s_ring.head + 1) % EDGE_RING_SLOTS;
|
||||
```
|
||||
|
||||
`EDGE_RING_SLOTS = 16` which IS a power of 2 (good), but the code uses `%` instead of `& (EDGE_RING_SLOTS - 1)`. The compiler should optimize this for power-of-2 constants, but it is not guaranteed on all optimization levels.
|
||||
|
||||
**Severity**: LOW -- Compiler likely optimizes this.
|
||||
|
||||
**Recommendation**: Use explicit bitmask for clarity and guaranteed optimization:
|
||||
```c
|
||||
uint32_t next = (s_ring.head + 1) & (EDGE_RING_SLOTS - 1);
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Cross-Cutting Concerns
|
||||
|
||||
### FINDING PERF-XC01: Missing Parallelism in Multistatic Pipeline [HIGH]
|
||||
|
||||
**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/mod.rs`
|
||||
**Lines**: 183-232
|
||||
|
||||
The `RuvSensePipeline` orchestrator processes stages sequentially. The multiband fusion and phase alignment stages for each node are independent and could run in parallel using Rayon:
|
||||
|
||||
```
|
||||
Node 0: multiband -> phase_align \
|
||||
Node 1: multiband -> phase_align }-> multistatic fusion -> coherence -> gate
|
||||
Node 2: multiband -> phase_align /
|
||||
Node 3: multiband -> phase_align /
|
||||
```
|
||||
|
||||
**Impact**: With 4 nodes, sequential processing takes 4x the single-node latency. Parallelization could reduce this to 1x (assuming available cores).
|
||||
|
||||
**Severity**: HIGH -- Linear scaling with node count in time-critical path.
|
||||
|
||||
**Recommendation**: Use `rayon::par_iter` for per-node multiband + phase_align stages. Only the multistatic fusion (which requires all nodes) remains sequential.
|
||||
|
||||
---
|
||||
|
||||
### FINDING PERF-XC02: No Pre-allocated Buffer Pool [MEDIUM]
|
||||
|
||||
Across the Rust codebase, many functions allocate fresh Vec<> for intermediate results that are immediately consumed and dropped. Examples:
|
||||
|
||||
- `multistatic.rs` line 249: `let mut mean_amp = vec![0.0_f32; n_sub];`
|
||||
- `multistatic.rs` line 287-289: 3 Vecs for fusion output
|
||||
- `tomography.rs` line 246: `let mut x = vec![0.0_f64; self.n_voxels];`
|
||||
- `tomography.rs` line 266: `let mut gradient = vec![0.0_f64; self.n_voxels];` (per iteration!)
|
||||
- `gesture.rs` line 297-298: 2 Vecs per DTW call
|
||||
|
||||
**Impact**: Repeated allocation/deallocation causes allocator pressure and potential cache pollution. The gradient vector in tomography is allocated 100 times (once per ISTA iteration).
|
||||
|
||||
**Severity**: MEDIUM -- Cumulative impact on latency and GC pressure.
|
||||
|
||||
**Recommendation**:
|
||||
1. Pre-allocate scratch buffers in the parent struct.
|
||||
2. Use `Vec::clear()` + `Vec::resize()` instead of `vec![]` to reuse capacity.
|
||||
3. For the ISTA gradient, allocate once outside the loop.
|
||||
|
||||
---
|
||||
|
||||
## 6. Performance Budget Analysis
|
||||
|
||||
### 50 ms Frame Budget Breakdown (20 Hz target)
|
||||
|
||||
| Stage | Current Est. | Optimized Est. | Finding |
|
||||
|-------|-------------|----------------|---------|
|
||||
| CSI Callback + Serialize | 1 ms | 0.5 ms | FW03 |
|
||||
| Multiband Fusion (4 nodes) | 2 ms | 0.5 ms | XC01 |
|
||||
| Phase Alignment | 1 ms | 1 ms | OK |
|
||||
| Multistatic Fusion | 3 ms | 1 ms | R02, R04 |
|
||||
| Coherence Scoring | 0.5 ms | 0.5 ms | R05 (OK) |
|
||||
| Coherence Gating | <0.1 ms | <0.1 ms | OK |
|
||||
| NN Translator Inference | 10-15 ms | 10-15 ms | NN04 |
|
||||
| NN DensePose Inference | 10-15 ms | 10-15 ms | NN04 |
|
||||
| Pose Tracking Update | 1 ms | 1 ms | R03 (OK) |
|
||||
| Adversarial Check | 0.5 ms | 0.5 ms | R09 (OK) |
|
||||
| WebSocket Broadcast | 5-10 ms | 1 ms | PY04 |
|
||||
| Python Doppler Extraction | 3-5 ms | 0.5 ms | PY01 |
|
||||
| **Total** | **37.5-54 ms** | **26.5-41 ms** | |
|
||||
|
||||
### Verdict
|
||||
|
||||
Current total is **borderline** -- the system may exceed the 50 ms budget under load with 4+ nodes and 10+ WebSocket clients. After applying the CRITICAL and HIGH recommendations, the budget drops to **26.5-41 ms**, providing 9-23 ms of headroom.
|
||||
|
||||
---
|
||||
|
||||
## 7. Findings Summary
|
||||
|
||||
### By Severity
|
||||
|
||||
| Severity | Count | Weight | Total |
|
||||
|----------|-------|--------|-------|
|
||||
| CRITICAL | 4 | 3.0 | 12.0 |
|
||||
| HIGH | 6 | 2.0 | 12.0 |
|
||||
| MEDIUM | 8 | 1.0 | 8.0 |
|
||||
| LOW | 5 | 0.5 | 2.5 |
|
||||
| **Total** | **23** | | **34.5** |
|
||||
|
||||
### By Domain
|
||||
|
||||
| Domain | CRIT | HIGH | MED | LOW | Top Issue |
|
||||
|--------|------|------|-----|-----|-----------|
|
||||
| Rust Signal Processing | 1 | 2 | 4 | 2 | Tomography O(L*V) |
|
||||
| Rust Neural Network | 1 | 1 | 2 | 0 | Serial batch inference |
|
||||
| Python Pipeline | 1 | 1 | 2 | 1 | Deque-to-list copy |
|
||||
| ESP32 Firmware | 0 | 1 | 1 | 3 | Top-K double precision |
|
||||
| Cross-Cutting | 0 | 1 | 1 | 0 | Missing parallelism |
|
||||
|
||||
### Priority Action Items
|
||||
|
||||
1. **PERF-NN01** (CRITICAL): Fix serial batch inference -- single code change, 2-4x improvement
|
||||
2. **PERF-PY01** (CRITICAL): Replace deque with circular numpy buffer -- eliminates 112 KB/frame allocation
|
||||
3. **PERF-R01** (CRITICAL): Replace brute-force voxel scan with DDA ray marching -- 5-10x for tomography
|
||||
4. **PERF-R04** (HIGH): Move node_frames by value instead of cloning -- eliminates 5 KB copy/frame
|
||||
5. **PERF-XC01** (HIGH): Add Rayon parallelism for per-node stages -- reduces 4x to 1x node latency
|
||||
6. **PERF-FW01** (HIGH): Switch top-K to float + partial sort -- 5-10x improvement on ESP32
|
||||
|
||||
---
|
||||
|
||||
## 8. Patterns Checked (Clean Justification)
|
||||
|
||||
The following patterns were checked and found to be well-implemented:
|
||||
|
||||
| Pattern | Files Checked | Status |
|
||||
|---------|--------------|--------|
|
||||
| Unbounded buffers | csi_processor.py, edge_processing.c | CLEAN -- deque maxlen, ring buffer bounded |
|
||||
| Lock contention | connection_manager.py, inference.rs | MINOR -- RwLock in NN stats (noted in NN02) |
|
||||
| Blocking in async | pose_service.py, connection_manager.py | CLEAN -- all I/O properly awaited |
|
||||
| Data structure choice | pose_tracker.rs, coherence.rs | CLEAN -- appropriate for current scale |
|
||||
| Memory safety (ESP32) | edge_processing.c | CLEAN -- bounds checks, copy_len clamped |
|
||||
| CSI rate limiting | csi_collector.c | CLEAN -- 20ms interval, well-documented |
|
||||
| Phase unwrapping | edge_processing.c, phase_align.rs | CLEAN -- correct 2*pi wrap handling |
|
||||
| Welford stability | field_model.rs, edge_processing.c | CLEAN -- numerically stable f64 accumulation |
|
||||
| SPSC ring correctness | edge_processing.c | CLEAN -- memory barriers, single-producer |
|
||||
| Kalman covariance | pose_tracker.rs | CLEAN -- diagonal approximation appropriate |
|
||||
|
||||
---
|
||||
|
||||
## Appendix A: File Paths Analyzed
|
||||
|
||||
### Rust Signal Processing
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/mod.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/tomography.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/pose_tracker.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/field_model.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/gesture.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/coherence.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/coherence_gate.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multiband.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/phase_align.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/adversarial.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/intention.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/longitudinal.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/cross_room.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/temporal_gesture.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/attractor_drift.rs`
|
||||
|
||||
### Rust Neural Network
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`
|
||||
- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/tensor.rs`
|
||||
|
||||
### Python Pipeline
|
||||
- `/workspaces/ruview/v1/src/core/csi_processor.py`
|
||||
- `/workspaces/ruview/v1/src/services/pose_service.py`
|
||||
- `/workspaces/ruview/v1/src/api/websocket/connection_manager.py`
|
||||
- `/workspaces/ruview/v1/src/api/websocket/pose_stream.py`
|
||||
- `/workspaces/ruview/v1/src/sensing/feature_extractor.py`
|
||||
|
||||
### ESP32 Firmware
|
||||
- `/workspaces/ruview/firmware/esp32-csi-node/main/csi_collector.c`
|
||||
- `/workspaces/ruview/firmware/esp32-csi-node/main/edge_processing.c`
|
||||
- `/workspaces/ruview/firmware/esp32-csi-node/main/edge_processing.h`
|
||||
|
||||
---
|
||||
|
||||
*Generated by QE Performance Reviewer V3 (chaos-resilience domain)*
|
||||
*Confidence: 0.92 | Reward: 0.9 (comprehensive analysis, specific line references, measured impact estimates)*
|
||||
@@ -1,544 +0,0 @@
|
||||
# Test Suite Analysis Report
|
||||
|
||||
**Project:** wifi-densepose (ruview)
|
||||
**Date:** 2026-04-05
|
||||
**Analyst:** QE Test Architect (V3)
|
||||
**Scope:** All test suites across Python (v1), Rust (rust-port), and Mobile (ui/mobile)
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
The wifi-densepose project contains **3,353 total test functions** across three technology stacks:
|
||||
|
||||
| Stack | Test Functions | Files | Frameworks |
|
||||
|-------|---------------|-------|------------|
|
||||
| Rust (inline + integration) | 2,658 | 292 source files + 16 integration test files | `#[test]`, Rust built-in |
|
||||
| Python (v1/tests/) | 491 | 30 test files | pytest, pytest-asyncio |
|
||||
| Mobile (ui/mobile) | 204 | 25 test files | Jest, React Testing Library |
|
||||
| **Total** | **3,353** | **363** | |
|
||||
|
||||
### Overall Quality Score: 6.5/10
|
||||
|
||||
**Strengths:** Comprehensive Rust coverage, strong domain-specific signal processing validation, well-structured Python TDD suites.
|
||||
|
||||
**Critical Weaknesses:** Massive test duplication in Python CSI extractor tests, over-reliance on mocks in integration tests, several E2E/performance tests use mock objects that defeat the testing purpose, and mobile tests are predominantly smoke tests with shallow assertions.
|
||||
|
||||
---
|
||||
|
||||
## 1. Python Test Suite Analysis (v1/tests/)
|
||||
|
||||
### 1.1 Test Distribution
|
||||
|
||||
| Category | Files | Test Functions | % of Total |
|
||||
|----------|-------|---------------|------------|
|
||||
| Unit | 14 | 325 | 66.2% |
|
||||
| Integration | 11 | 109 | 22.2% |
|
||||
| Performance | 2 | 26 | 5.3% |
|
||||
| E2E | 1 | 8 | 1.6% |
|
||||
| Fixtures/Mocks | 3 | 23 (helpers) | 4.7% |
|
||||
| **Total** | **31** | **491** | **100%** |
|
||||
|
||||
**Pyramid Assessment:** 66:22:7 (unit:integration:e2e+perf) -- Slightly integration-light but within acceptable bounds.
|
||||
|
||||
### 1.2 Critical Finding: Massive Test Duplication
|
||||
|
||||
The CSI extractor module has **five** test files testing nearly identical functionality:
|
||||
|
||||
1. `test_csi_extractor.py` -- 16 tests (original, older API)
|
||||
2. `test_csi_extractor_tdd.py` -- 18 tests (TDD rewrite)
|
||||
3. `test_csi_extractor_tdd_complete.py` -- 20 tests (expanded TDD)
|
||||
4. `test_csi_extractor_direct.py` -- 38 tests (direct imports)
|
||||
5. `test_csi_standalone.py` -- 40 tests (standalone with importlib)
|
||||
|
||||
**Total: 132 tests across 5 files for a single module.**
|
||||
|
||||
These files test the same validation logic repeatedly. For example, the "empty amplitude" validation test appears in 4 of the 5 files with nearly identical code:
|
||||
|
||||
- `test_csi_extractor_tdd_complete.py:171-188` -- `test_validation_empty_amplitude`
|
||||
- `test_csi_extractor_direct.py:293-310` -- `test_validation_empty_amplitude`
|
||||
- `test_csi_standalone.py:305-322` -- `test_validate_empty_amplitude`
|
||||
- `test_csi_extractor_tdd.py:166-181` -- `test_should_reject_invalid_csi_data`
|
||||
|
||||
The same pattern repeats for empty phase, invalid frequency, invalid bandwidth, invalid subcarriers, invalid antennas, SNR too low, and SNR too high -- each duplicated 3-4 times.
|
||||
|
||||
**Impact:** ~90 redundant tests. This inflates the test count by approximately 18% and creates a maintenance burden where changes to the CSI extractor require updating 4-5 test files.
|
||||
|
||||
**Recommendation:** Consolidate to a single test file (`test_csi_extractor.py`) using the `test_csi_standalone.py` approach (importlib-based, most comprehensive). Delete the other four files.
|
||||
|
||||
Similarly, there are duplicate suites for:
|
||||
- Phase sanitizer: `test_phase_sanitizer.py` (7 tests) + `test_phase_sanitizer_tdd.py` (31 tests)
|
||||
- Router interface: `test_router_interface.py` (13 tests) + `test_router_interface_tdd.py` (23 tests)
|
||||
- CSI processor: `test_csi_processor.py` (6 tests) + `test_csi_processor_tdd.py` (25 tests)
|
||||
|
||||
### 1.3 Test Naming Conventions
|
||||
|
||||
Two competing conventions are used:
|
||||
|
||||
**Convention A (older tests):** `test_<action>_<condition>` (imperative)
|
||||
```python
|
||||
# test_csi_extractor.py:46
|
||||
def test_extractor_initialization_creates_correct_configuration(self, ...):
|
||||
```
|
||||
|
||||
**Convention B (TDD tests):** `test_should_<behavior>` (BDD-style)
|
||||
```python
|
||||
# test_csi_extractor_tdd.py:64
|
||||
def test_should_initialize_with_valid_config(self, ...):
|
||||
```
|
||||
|
||||
**Assessment:** Convention B is more descriptive and follows London School TDD naming. The project should standardize on one convention. Convention A is used in 6 files; Convention B in 8 files.
|
||||
|
||||
### 1.4 AAA Pattern Adherence
|
||||
|
||||
**Good examples:**
|
||||
|
||||
`test_csi_extractor.py:62-74` follows AAA with explicit comments:
|
||||
```python
|
||||
def test_start_extraction_configures_monitor_mode(self, ...):
|
||||
# Arrange
|
||||
mock_router_interface.enable_monitor_mode.return_value = True
|
||||
# Act
|
||||
result = csi_extractor.start_extraction()
|
||||
# Assert
|
||||
assert result is True
|
||||
```
|
||||
|
||||
`test_sensing.py` follows AAA implicitly without comments but with clean structure throughout all 45 tests. This file is the best-written test file in the Python suite.
|
||||
|
||||
**Poor examples:**
|
||||
|
||||
`test_csi_processor_tdd.py:168-182` mixes arrangement with assertion:
|
||||
```python
|
||||
def test_should_preprocess_csi_data_successfully(self, csi_processor, sample_csi_data):
|
||||
with patch.object(csi_processor, '_remove_noise') as mock_noise:
|
||||
with patch.object(csi_processor, '_apply_windowing') as mock_window:
|
||||
with patch.object(csi_processor, '_normalize_amplitude') as mock_normalize:
|
||||
mock_noise.return_value = sample_csi_data
|
||||
mock_window.return_value = sample_csi_data
|
||||
mock_normalize.return_value = sample_csi_data
|
||||
result = csi_processor.preprocess_csi_data(sample_csi_data)
|
||||
assert result == sample_csi_data
|
||||
```
|
||||
This is a 5-level deep `with` block that obscures the test's intent.
|
||||
|
||||
### 1.5 Mock Usage Analysis
|
||||
|
||||
**Over-mocking (Critical):**
|
||||
|
||||
The TDD test files suffer from severe over-mocking. In `test_csi_processor_tdd.py:168-182`, the preprocessing test mocks out `_remove_noise`, `_apply_windowing`, and `_normalize_amplitude` -- the very functions being tested. The test only verifies that the mocks were called, not that the pipeline works correctly. Compare with `test_csi_processor.py:56-61`:
|
||||
|
||||
```python
|
||||
def test_preprocess_returns_csi_data(self, csi_processor, sample_csi):
|
||||
result = csi_processor.preprocess_csi_data(sample_csi)
|
||||
assert isinstance(result, CSIData)
|
||||
```
|
||||
|
||||
This test actually exercises the real code and validates the output type.
|
||||
|
||||
**Over-mocking count:** 14 of 25 tests in `test_csi_processor_tdd.py` mock internal methods rather than collaborators. This violates the London School TDD principle -- London School mocks *collaborators*, not the system under test's own private methods.
|
||||
|
||||
Similarly in `test_phase_sanitizer_tdd.py`, 12 of 31 tests mock internal methods (`_detect_outliers`, `_interpolate_outliers`, `_apply_moving_average`, `_apply_low_pass_filter`).
|
||||
|
||||
**Appropriate mock usage:**
|
||||
|
||||
`test_router_interface.py` correctly uses `@patch('paramiko.SSHClient')` to mock the SSH external dependency. This is textbook London School TDD -- mocking the collaborator (SSH client) to test the router interface's behavior.
|
||||
|
||||
`test_esp32_binary_parser.py:129-177` uses a real UDP socket with `threading.Thread` for the mock server -- excellent integration test design that avoids over-mocking.
|
||||
|
||||
### 1.6 Edge Case Coverage
|
||||
|
||||
**Excellent edge case coverage:**
|
||||
|
||||
`test_sensing.py` (45 tests) provides outstanding edge case coverage:
|
||||
- Constant signals (`test_constant_signal_features`, line 327)
|
||||
- Too few samples (`test_too_few_samples`, line 339)
|
||||
- Cross-receiver agreement (`test_cross_receiver_agreement_boosts_confidence`, line 513)
|
||||
- Confidence bounds checking (`test_confidence_bounded_0_to_1`, line 501)
|
||||
- Multi-frequency band isolation (`test_band_isolation_multi_frequency`, line 308)
|
||||
- Empty band power (`test_band_power_zero_for_empty_band`, line 697)
|
||||
- Platform availability detection with mocked proc filesystem (lines 716-807)
|
||||
|
||||
`test_esp32_binary_parser.py` covers:
|
||||
- Valid frame parsing (line 72)
|
||||
- Frame too short (line 98)
|
||||
- Invalid magic number (line 103)
|
||||
- Multi-antenna frames (line 111)
|
||||
- UDP timeout (line 179)
|
||||
|
||||
**Poor edge case coverage:**
|
||||
|
||||
`test_densepose_head.py` lacks tests for:
|
||||
- Batch size of 0
|
||||
- Non-square input sizes
|
||||
- Very large batch sizes (memory limits)
|
||||
- NaN/Inf in input tensors
|
||||
- Half-precision (float16) inputs
|
||||
|
||||
`test_modality_translation.py` lacks tests for:
|
||||
- Gradient clipping behavior
|
||||
- Learning rate sensitivity
|
||||
- Numerical stability with extreme values
|
||||
|
||||
### 1.7 Test Isolation
|
||||
|
||||
**Shared state issues:**
|
||||
|
||||
`test_sensing.py` -- The `SimulatedCollector` tests are well-isolated using seeds, but `TestCommodityBackend.test_full_pipeline` (line 592) directly accesses `collector._buffer` (private attribute). If the internal buffer implementation changes, this test breaks.
|
||||
|
||||
`test_csi_processor_tdd.py:326-354` -- Tests manipulate `csi_processor._total_processed`, `_processing_errors`, and `_human_detections` directly. These are private attributes and the tests are coupled to implementation details.
|
||||
|
||||
**No test order dependencies found.** All test files use proper fixture setup via `@pytest.fixture` or `setup_method`.
|
||||
|
||||
### 1.8 Flakiness Indicators
|
||||
|
||||
**Timing-dependent tests:**
|
||||
|
||||
- `test_phase_sanitizer.py:89-95` -- Asserts processing time `< 0.005` (5ms). This is fragile on CI with variable load.
|
||||
- `test_csi_processor.py:93-98` -- Asserts preprocessing time `< 0.010` (10ms). Same concern.
|
||||
- `test_csi_pipeline.py:202-222` -- Asserts pipeline processing `< 0.1s`. Better but still fragile.
|
||||
|
||||
**Non-deterministic tests:**
|
||||
|
||||
- `test_densepose_head.py:256-267` -- Training mode dropout test asserts outputs are different. With very small dropout rates or specific random seeds, outputs could occasionally match. The `atol=1e-6` tolerance is tight.
|
||||
- `test_modality_translation.py:145-155` -- Same dropout randomness concern.
|
||||
|
||||
**Network-dependent tests:**
|
||||
|
||||
- `test_esp32_binary_parser.py:129-177` -- Uses real UDP sockets with `time.sleep(0.2)`. Could fail under network congestion or slow CI.
|
||||
- `test_esp32_binary_parser.py:179-206` -- UDP timeout test with `timeout=0.5`. Race condition possible.
|
||||
|
||||
### 1.9 E2E and Performance Test Quality
|
||||
|
||||
**E2E tests (`test_healthcare_scenario.py`):**
|
||||
|
||||
This 735-line file defines its own mock classes (`MockPatientMonitor`, `MockHealthcareNotificationSystem`) rather than using the actual system. This makes it a **component integration test**, not a true E2E test. The test names include "should_fail_initially" comments suggesting TDD red-phase artifacts that were never cleaned up:
|
||||
|
||||
```python
|
||||
# Line 348
|
||||
async def test_fall_detection_workflow_should_fail_initially(self, ...):
|
||||
```
|
||||
|
||||
Despite the names, these tests actually pass (they test the mock objects successfully). The naming is misleading.
|
||||
|
||||
**Performance tests (`test_inference_speed.py`):**
|
||||
|
||||
All 14 tests use `MockPoseModel` with `asyncio.sleep()` simulating inference time. These tests measure sleep accuracy, not actual inference performance. They are **simulation tests**, not performance tests. Every assertion like `assert inference_time < 100` is testing asyncio scheduling, not model performance.
|
||||
|
||||
**Recommendation:** Either rename these to "simulation tests" or replace `MockPoseModel` with actual model inference.
|
||||
|
||||
### 1.10 Test Infrastructure Quality
|
||||
|
||||
**Fixtures (`v1/tests/fixtures/csi_data.py`):**
|
||||
|
||||
Well-designed `CSIDataGenerator` class (487 lines) with:
|
||||
- Multiple scenario generators (empty room, single person, multi-person)
|
||||
- Noise injection (`add_noise`)
|
||||
- Hardware artifact simulation (`simulate_hardware_artifacts`)
|
||||
- Time series generation
|
||||
- Validation utilities (`validate_csi_sample`)
|
||||
|
||||
**Mocks (`v1/tests/mocks/hardware_mocks.py`):**
|
||||
|
||||
Comprehensive mock infrastructure (716 lines) including:
|
||||
- `MockWiFiRouter` with realistic CSI streaming
|
||||
- `MockRouterNetwork` for multi-router scenarios
|
||||
- `MockSensorArray` for environmental monitoring
|
||||
- Factory functions (`create_test_router_network`, `setup_test_hardware_environment`)
|
||||
|
||||
These are well-engineered but used in only 1-2 test files. The E2E test defines its own mocks instead of using these.
|
||||
|
||||
---
|
||||
|
||||
## 2. Rust Test Suite Analysis
|
||||
|
||||
### 2.1 Test Distribution
|
||||
|
||||
| Category | Test Count | Source |
|
||||
|----------|-----------|--------|
|
||||
| Inline unit tests (`#[cfg(test)]`) | ~2,600 | 292 source files |
|
||||
| Integration tests (`crates/*/tests/`) | ~58 | 16 integration test files |
|
||||
| **Total** | **~2,658** | |
|
||||
|
||||
The Rust suite is the largest by far, with 1,031+ tests confirmed passing per the project's pre-merge checklist.
|
||||
|
||||
### 2.2 Integration Test Quality
|
||||
|
||||
**`wifi-densepose-train/tests/test_losses.rs` (18 tests):**
|
||||
|
||||
Excellent test quality. Key observations:
|
||||
|
||||
- All tests use deterministic data (no `rand` crate, no OS entropy) -- explicitly documented in the module docstring (line 9).
|
||||
- Feature-gated behind `#[cfg(feature = "tch-backend")]` with a fallback test (line 447) that ensures compilation when the feature is disabled.
|
||||
- Tests validate mathematical properties, not just "it doesn't crash":
|
||||
- `gaussian_heatmap_peak_at_keypoint_location` (line 55) -- Verifies the peak value and location
|
||||
- `gaussian_heatmap_zero_outside_3sigma_radius` (line 84) -- Validates every pixel in the heatmap
|
||||
- `keypoint_heatmap_loss_invisible_joints_contribute_nothing` (line 229) -- Tests visibility masking
|
||||
- Clear naming convention: `<function_name>_<expected_behavior>`
|
||||
|
||||
**`wifi-densepose-signal/tests/validation_test.rs` (10 tests):**
|
||||
|
||||
Outstanding validation tests that prove algorithm correctness against known mathematical results:
|
||||
|
||||
- `validate_phase_unwrapping_correctness` (line 17) -- Creates a linearly increasing phase from 0 to 4pi, wraps it, then validates unwrapping reconstructs the original.
|
||||
- `validate_amplitude_rms` (line 58) -- Uses constant-amplitude data where RMS equals the constant.
|
||||
- `validate_doppler_calculation` (line 89) -- Computes expected Doppler shift from physics (2 * v * f / c) and validates the implementation matches.
|
||||
- `validate_complex_conversion` (line 171) -- Round-trip test: amplitude/phase to complex and back.
|
||||
- `validate_correlation_features` (line 250) -- Uses perfectly correlated antenna data to validate correlation > 0.9.
|
||||
|
||||
These tests demonstrate mathematical rigor rarely seen in signal processing codebases.
|
||||
|
||||
**`wifi-densepose-mat/tests/integration_adr001.rs` (6 tests):**
|
||||
|
||||
Clean integration tests for the disaster response pipeline:
|
||||
- Deterministic breathing signal generator (16 BPM sinusoid at 0.267 Hz)
|
||||
- Triage logic verification with explicit expected outcomes per breathing pattern
|
||||
- Input validation (mismatched lengths, empty data)
|
||||
- Determinism verification test (line 190) -- runs generator twice and asserts bitwise equality
|
||||
|
||||
### 2.3 Inline Test Patterns
|
||||
|
||||
The 292 source files with `#[cfg(test)]` modules show consistent patterns:
|
||||
|
||||
**Builder pattern testing** is common across crates:
|
||||
```rust
|
||||
CsiData::builder()
|
||||
.amplitude(amplitude)
|
||||
.phase(phase)
|
||||
.build()
|
||||
.unwrap()
|
||||
```
|
||||
|
||||
**Feature-gated tests** prevent compilation failures when optional dependencies are unavailable. The `tch-backend` feature gate pattern is well-applied.
|
||||
|
||||
### 2.4 Missing Rust Test Coverage
|
||||
|
||||
Based on the crate list and test file analysis:
|
||||
|
||||
- `wifi-densepose-api` -- No integration tests for API routes found
|
||||
- `wifi-densepose-db` -- No database integration tests found
|
||||
- `wifi-densepose-config` -- No configuration edge case tests found
|
||||
- `wifi-densepose-wasm` -- No WASM-specific tests beyond budget compliance
|
||||
- `wifi-densepose-cli` -- No CLI integration tests found
|
||||
|
||||
These gaps are less concerning for crates that are primarily thin wrappers, but the API and DB crates warrant integration testing.
|
||||
|
||||
---
|
||||
|
||||
## 3. Mobile Test Suite Analysis (ui/mobile)
|
||||
|
||||
### 3.1 Test Distribution
|
||||
|
||||
| Category | Files | Tests | % |
|
||||
|----------|-------|-------|---|
|
||||
| Components | 7 | 33 | 16.2% |
|
||||
| Screens | 5 | 25 | 12.3% |
|
||||
| Hooks | 3 | 13 | 6.4% |
|
||||
| Services | 4 | 37 | 18.1% |
|
||||
| Stores | 3 | 52 | 25.5% |
|
||||
| Utils | 3 | 42 | 20.6% |
|
||||
| Test Utils/Mocks | 2 | 2 | 1.0% |
|
||||
| **Total** | **27** | **204** | **100%** |
|
||||
|
||||
### 3.2 Component Test Quality
|
||||
|
||||
**Shallow smoke tests dominate.** Most component tests only verify rendering without crashing:
|
||||
|
||||
`GaugeArc.test.tsx:28-63` -- All 4 tests follow the same pattern:
|
||||
```typescript
|
||||
it('renders without crashing', () => {
|
||||
const { toJSON } = renderWithTheme(<GaugeArc ... />);
|
||||
expect(toJSON()).not.toBeNull();
|
||||
});
|
||||
```
|
||||
|
||||
This verifies the component doesn't throw, but doesn't test:
|
||||
- Visual output correctness (arc calculation, text rendering)
|
||||
- Prop-driven behavior changes
|
||||
- Accessibility attributes
|
||||
- Edge cases (value > max, negative values, value = 0)
|
||||
|
||||
**Better examples:**
|
||||
|
||||
`ringBuffer.test.ts` (20 tests) -- Comprehensive boundary testing:
|
||||
- Zero capacity (line 21)
|
||||
- Negative capacity (line 25)
|
||||
- NaN capacity (line 29)
|
||||
- Infinity capacity (line 33)
|
||||
- Overflow behavior (line 46)
|
||||
- Copy semantics (line 67)
|
||||
- Min/max without comparator (line 98, 129)
|
||||
|
||||
`matStore.test.ts` (18 tests) -- Good state management tests:
|
||||
- Initial state verification (lines 69-87)
|
||||
- Upsert idempotency (lines 97-107)
|
||||
- Multiple distinct entities (lines 109-113)
|
||||
- Selection and deselection (lines 187-197)
|
||||
|
||||
### 3.3 Service Test Quality
|
||||
|
||||
`api.service.test.ts` (14 tests) -- Well-structured service tests:
|
||||
- URL building edge cases (trailing slash, absolute URLs, empty base)
|
||||
- Error normalization (Axios errors, generic errors, unknown errors)
|
||||
- Retry logic verification (3 total calls, recovery on second attempt)
|
||||
|
||||
This is the best-tested service in the mobile suite.
|
||||
|
||||
### 3.4 Hook Test Quality
|
||||
|
||||
`usePoseStream.test.ts` (4 tests) -- Minimal hook tests:
|
||||
- Only verifies module exports and store shape
|
||||
- Cannot test actual hook behavior without rendering context
|
||||
- Line 20-38: Tests the store, not the hook
|
||||
|
||||
**Missing:** No `renderHook()` usage from `@testing-library/react-hooks`. Hooks should be tested with the `renderHook` utility.
|
||||
|
||||
### 3.5 Missing Mobile Test Coverage
|
||||
|
||||
- No gesture interaction tests
|
||||
- No navigation flow tests
|
||||
- No dark/light theme switching tests
|
||||
- No offline/error state rendering tests
|
||||
- No accessibility (a11y) tests
|
||||
- No snapshot tests for UI regression
|
||||
- No WebSocket reconnection logic tests
|
||||
|
||||
---
|
||||
|
||||
## 4. Cross-Cutting Analysis
|
||||
|
||||
### 4.1 Test Pyramid Balance
|
||||
|
||||
| Layer | Python | Rust | Mobile | Project Total | Ideal |
|
||||
|-------|--------|------|--------|---------------|-------|
|
||||
| Unit | 66% | ~98% | 62% | ~92% | 70% |
|
||||
| Integration | 22% | ~2% | 20% | ~5% | 20% |
|
||||
| E2E/Perf | 7% | ~0% | 0% | ~1% | 10% |
|
||||
| System/Acceptance | 5% (mocked) | 0% | 18% (screens) | ~2% | -- |
|
||||
|
||||
**Assessment:** The pyramid is top-heavy on unit tests due to the massive Rust inline test suite. Integration and E2E layers are weak across the board.
|
||||
|
||||
### 4.2 Duplicate Coverage Map
|
||||
|
||||
| Module | Files Testing It | Redundant Tests |
|
||||
|--------|-----------------|-----------------|
|
||||
| CSI Extractor | 5 Python files | ~90 |
|
||||
| Phase Sanitizer | 2 Python files | ~7 |
|
||||
| Router Interface | 2 Python files | ~13 |
|
||||
| CSI Processor | 2 Python files | ~6 |
|
||||
| **Total redundant** | | **~116** |
|
||||
|
||||
### 4.3 Test Gap Analysis
|
||||
|
||||
**Untested or under-tested areas:**
|
||||
|
||||
| Component | Gap Description | Risk |
|
||||
|-----------|----------------|------|
|
||||
| REST API (Python) | `test_api_endpoints.py` exists but uses mocks for all HTTP | High |
|
||||
| WebSocket streaming | `test_websocket_streaming.py` exists but no real connection | High |
|
||||
| ESP32 firmware | C code has no automated tests | Critical |
|
||||
| Database layer (Rust) | No integration tests for `wifi-densepose-db` | Medium |
|
||||
| Cross-crate integration | No tests validating crate dependency chains | Medium |
|
||||
| Configuration validation | `wifi-densepose-config` has minimal test coverage | Low |
|
||||
| WASM edge deployment | Only budget compliance tests | Medium |
|
||||
| Mobile navigation | No screen transition tests | Medium |
|
||||
| Mobile WebSocket | `ws.service.test.ts` exists but limited coverage | High |
|
||||
|
||||
### 4.4 Test Maintenance Burden
|
||||
|
||||
**High maintenance cost files:**
|
||||
|
||||
1. `v1/tests/mocks/hardware_mocks.py` (716 lines) -- Complex mock infrastructure that must evolve with the production code. Any hardware interface change requires updating this file.
|
||||
|
||||
2. `v1/tests/fixtures/csi_data.py` (487 lines) -- Rich data generation but duplicates some logic from the production `SimulatedCollector`.
|
||||
|
||||
3. The 5 CSI extractor test files collectively contain ~3,000 lines of test code for a single module. Merging to one file would reduce this to ~600 lines.
|
||||
|
||||
**Brittle test indicators:**
|
||||
|
||||
- Tests that access private attributes (`_buffer`, `_total_processed`, etc.): 8 occurrences
|
||||
- Tests with magic number assertions (`< 0.005`, `< 0.010`): 5 occurrences
|
||||
- Tests with `asyncio.sleep()` for synchronization: 12 occurrences
|
||||
|
||||
---
|
||||
|
||||
## 5. Specific File-Level Findings
|
||||
|
||||
### 5.1 Best Test Files (Exemplary Quality)
|
||||
|
||||
| File | Why It's Good |
|
||||
|------|---------------|
|
||||
| `v1/tests/unit/test_sensing.py` | 45 tests with mathematical rigor, known-signal validation, domain-specific edge cases, cross-receiver agreement, band isolation. No mocks for core logic. |
|
||||
| `v1/tests/unit/test_esp32_binary_parser.py` | Real UDP socket testing, struct-level binary validation, ADR-018 compliance. Tests actual I/Q to amplitude/phase math. |
|
||||
| `rust-port/.../tests/validation_test.rs` | Physics-based validation (Doppler, phase unwrapping, spectral analysis). Tests prove algorithm correctness, not just non-failure. |
|
||||
| `rust-port/.../tests/test_losses.rs` | Deterministic data, feature-gated, tests mathematical properties (zero loss for identical inputs, non-zero for mismatched). |
|
||||
| `ui/mobile/.../utils/ringBuffer.test.ts` | Comprehensive boundary testing (NaN, Infinity, 0, negative, overflow). Tests copy semantics. |
|
||||
|
||||
### 5.2 Worst Test Files (Needs Improvement)
|
||||
|
||||
| File | Issues |
|
||||
|------|--------|
|
||||
| `v1/tests/performance/test_inference_speed.py` | Tests `asyncio.sleep()` accuracy, not model performance. `MockPoseModel` simulates inference with sleep. |
|
||||
| `v1/tests/e2e/test_healthcare_scenario.py` | Not a real E2E test -- defines its own mock classes. Test names contain stale "should_fail_initially" text. |
|
||||
| `v1/tests/unit/test_csi_processor_tdd.py` | 14/25 tests mock the SUT's own private methods. Tests verify mock calls, not behavior. |
|
||||
| `v1/tests/unit/test_phase_sanitizer_tdd.py` | 12/31 tests mock internal methods. Same anti-pattern as csi_processor_tdd. |
|
||||
| `ui/mobile/.../components/GaugeArc.test.tsx` | All 4 tests are `expect(toJSON()).not.toBeNull()` -- smoke tests with no behavioral verification. |
|
||||
|
||||
---
|
||||
|
||||
## 6. Recommendations
|
||||
|
||||
### Priority 1: Eliminate Duplication (Effort: Low, Impact: High)
|
||||
|
||||
1. **Consolidate CSI extractor tests** into a single file. Retain `test_csi_standalone.py` (most comprehensive), delete the other four. This removes ~90 redundant tests and ~2,400 lines of duplicate code.
|
||||
|
||||
2. **Consolidate TDD pairs** -- Merge `test_phase_sanitizer.py` into `test_phase_sanitizer_tdd.py`, `test_router_interface.py` into `test_router_interface_tdd.py`, `test_csi_processor.py` into `test_csi_processor_tdd.py`.
|
||||
|
||||
### Priority 2: Fix Mock Anti-Patterns (Effort: Medium, Impact: High)
|
||||
|
||||
3. **Replace internal-method mocking** in `test_csi_processor_tdd.py` and `test_phase_sanitizer_tdd.py` with real execution tests. Mock only external collaborators (SSH, hardware, network).
|
||||
|
||||
4. **Replace `MockPoseModel`** in performance tests with actual model inference or clearly label these as "simulation tests."
|
||||
|
||||
### Priority 3: Add Missing Test Coverage (Effort: High, Impact: High)
|
||||
|
||||
5. **Add real integration tests** for the REST API and WebSocket endpoints using `httpx.AsyncClient` or similar.
|
||||
|
||||
6. **Add Rust integration tests** for `wifi-densepose-api`, `wifi-densepose-db`, and `wifi-densepose-cli` crates.
|
||||
|
||||
7. **Upgrade mobile component tests** from smoke tests to behavioral tests with prop variation, user interaction, and accessibility checks.
|
||||
|
||||
### Priority 4: Reduce Flakiness Risk (Effort: Low, Impact: Medium)
|
||||
|
||||
8. **Remove or widen timing assertions** in `test_phase_sanitizer.py:89` and `test_csi_processor.py:93`. Use `pytest-benchmark` for performance measurement, not inline time assertions.
|
||||
|
||||
9. **Add retry logic to UDP socket tests** in `test_esp32_binary_parser.py` or use mock sockets for unit-level testing.
|
||||
|
||||
### Priority 5: Standardize Conventions (Effort: Low, Impact: Low)
|
||||
|
||||
10. **Standardize test naming** to `test_should_<behavior>` (BDD-style) across all Python tests.
|
||||
|
||||
11. **Add pytest markers** consistently: `@pytest.mark.unit`, `@pytest.mark.integration`, `@pytest.mark.slow` for performance tests.
|
||||
|
||||
---
|
||||
|
||||
## 7. Metrics Summary
|
||||
|
||||
| Metric | Value | Assessment |
|
||||
|--------|-------|------------|
|
||||
| Total test functions | 3,353 | Good volume |
|
||||
| Unique test functions (estimated) | ~3,237 | ~116 duplicates |
|
||||
| Test-to-source ratio (Python) | 1.8:1 | High (inflated by duplication) |
|
||||
| Test-to-source ratio (Rust) | 2.0:1 | Good |
|
||||
| Files with over-mocking | 4 | Needs remediation |
|
||||
| Timing-dependent tests | 5 | Flakiness risk |
|
||||
| Tests with private attribute access | 8 | Fragility risk |
|
||||
| E2E tests using real services | 0 | Critical gap |
|
||||
| Redundant test files | 6 | Consolidation needed |
|
||||
| Test files following AAA pattern | ~80% | Good |
|
||||
| Tests with meaningful assertions | ~75% | Could improve |
|
||||
|
||||
---
|
||||
|
||||
*Report generated by QE Test Architect V3*
|
||||
*Analysis based on full source code review of 363 test files*
|
||||
@@ -1,746 +0,0 @@
|
||||
# Quality Experience (QX) Analysis: WiFi-DensePose
|
||||
|
||||
**Report ID**: QX-2026-005
|
||||
**Date**: 2026-04-05
|
||||
**Scope**: Full-stack quality experience across API, CLI, Mobile, DX, and Hardware
|
||||
**QX Score**: 71/100 (C+)
|
||||
|
||||
---
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Executive Summary](#1-executive-summary)
|
||||
2. [Overall QX Scores](#2-overall-qx-scores)
|
||||
3. [User Journey Analysis by Persona](#3-user-journey-analysis-by-persona)
|
||||
4. [API Experience Analysis](#4-api-experience-analysis)
|
||||
5. [CLI Experience Analysis](#5-cli-experience-analysis)
|
||||
6. [Mobile App UX Analysis](#6-mobile-app-ux-analysis)
|
||||
7. [Developer Experience (DX) Analysis](#7-developer-experience-dx-analysis)
|
||||
8. [Hardware Integration UX Analysis](#8-hardware-integration-ux-analysis)
|
||||
9. [Cross-Cutting Quality Concerns](#9-cross-cutting-quality-concerns)
|
||||
10. [Oracle Problems Detected](#10-oracle-problems-detected)
|
||||
11. [Prioritized Recommendations](#11-prioritized-recommendations)
|
||||
12. [Heuristic Scoring Summary](#12-heuristic-scoring-summary)
|
||||
|
||||
---
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
The WiFi-DensePose system demonstrates strong architectural foundations with a well-structured FastAPI backend, a mature React Native mobile app, and a comprehensive CLI. However, the quality experience is uneven across touchpoints, with several gaps that impact different user personas in distinct ways.
|
||||
|
||||
### Key Findings
|
||||
|
||||
**Strengths:**
|
||||
- Comprehensive error handling middleware with structured error responses, request IDs, and environment-aware detail levels (`v1/src/middleware/error_handler.py`)
|
||||
- Robust WebSocket reconnection with exponential backoff and automatic simulation fallback in the mobile app (`ui/mobile/src/services/ws.service.ts`)
|
||||
- Well-designed health check architecture with component-level status, readiness probes, and liveness endpoints (`v1/src/api/routers/health.py`)
|
||||
- Strong input validation on API models with Pydantic, including range constraints and clear field descriptions (`v1/src/api/routers/pose.py`)
|
||||
- Persistent settings with AsyncStorage in the mobile app, surviving app restarts (`ui/mobile/src/stores/settingsStore.ts`)
|
||||
- Server URL validation with test-before-save workflow in mobile settings (`ui/mobile/src/screens/SettingsScreen/ServerUrlInput.tsx`)
|
||||
|
||||
**Critical Issues:**
|
||||
- API documentation is disabled in production (`docs_url=None`, `redoc_url=None` when `is_production=True`), leaving production API consumers without discoverability (in `v1/src/api/main.py` line 146-148)
|
||||
- No user-facing progress indicator during calibration -- the calibration endpoint returns an estimated duration but there is no polling endpoint progress beyond percentage (`v1/src/api/routers/pose.py` lines 320-361)
|
||||
- Rate limit responses lack a human-readable `Retry-After` message body; the client receives a bare `"Rate limit exceeded"` string with retry information only in HTTP headers (`v1/src/middleware/rate_limit.py` line 323)
|
||||
- CLI `status` command uses emoji/Unicode characters that break in terminals without UTF-8 support (`v1/src/commands/status.py` lines 360-474)
|
||||
- Mobile app `MainTabs.tsx` passes an inline arrow function as the `component` prop to `Tab.Screen` (line 130), causing unnecessary re-renders on every parent render cycle
|
||||
|
||||
**Top 3 Recommendations:**
|
||||
1. Add a separate production API documentation URL (e.g., `/api-docs`) with authentication, rather than removing docs entirely
|
||||
2. Implement a WebSocket-based calibration progress stream or add a polling endpoint that returns step-by-step progress
|
||||
3. Add a `--no-emoji` CLI flag or auto-detect terminal capabilities to avoid broken status output
|
||||
|
||||
---
|
||||
|
||||
## 2. Overall QX Scores
|
||||
|
||||
| Dimension | Score | Grade | Assessment |
|
||||
|-----------|-------|-------|------------|
|
||||
| **Overall QX** | 71/100 | C+ | Functional but inconsistent across touchpoints |
|
||||
| **API Experience** | 78/100 | B- | Well-structured endpoints, good error model, weak discoverability |
|
||||
| **CLI Experience** | 65/100 | D+ | Adequate commands, poor terminal compatibility, limited help |
|
||||
| **Mobile UX** | 80/100 | B | Strong connection handling, good fallbacks, minor render issues |
|
||||
| **Developer Experience** | 68/100 | D+ | Steep learning curve, complex build, limited onboarding docs |
|
||||
| **Hardware UX** | 62/100 | D | Complex provisioning, limited error recovery guidance |
|
||||
| **Accessibility** | 45/100 | F | No ARIA consideration in mobile, no high-contrast support |
|
||||
| **Trust & Reliability** | 76/100 | B- | Good health checks, rate limiting, auth framework in place |
|
||||
| **Cross-Codebase Consistency** | 70/100 | C | Different error formats between API/CLI, naming inconsistencies |
|
||||
|
||||
---
|
||||
|
||||
## 3. User Journey Analysis by Persona
|
||||
|
||||
### 3.1 Developer Persona
|
||||
|
||||
**Journey**: Clone repo -> Set up environment -> Build -> Run tests -> Develop -> Submit PR
|
||||
|
||||
| Step | Success Rate | Pain Level | Bottleneck |
|
||||
|------|-------------|------------|------------|
|
||||
| Clone & orient | Moderate | MEDIUM | Multiple codebases (Python v1, Rust, firmware, mobile) with no single entry point guide |
|
||||
| Environment setup | Low | HIGH | Requires Python + Rust toolchain + Node.js + ESP-IDF for full development |
|
||||
| Build Python API | Moderate | MEDIUM | Dependency management not containerized for easy onboarding |
|
||||
| Run Rust tests | High | LOW | `cargo test --workspace --no-default-features` works reliably (1,031+ tests) |
|
||||
| Run Python tests | Moderate | MEDIUM | Requires database setup, Redis optional but affects behavior |
|
||||
| Contribute to mobile | Moderate | MEDIUM | Expo/React Native setup is standard but undocumented within this repo |
|
||||
|
||||
**Key Findings:**
|
||||
- `CLAUDE.md` is comprehensive for AI agents but not optimized for human developers; it mixes agent configuration with build instructions
|
||||
- No `CONTRIBUTING.md` file exists
|
||||
- Build commands are scattered: Python uses `pip`, Rust uses `cargo`, mobile uses `npm`, firmware uses ESP-IDF
|
||||
- Test commands differ between `npm test`, `cargo test`, and `python -m pytest` with no unified runner
|
||||
- The pre-merge checklist in `CLAUDE.md` has 12 items, which is thorough but creates friction for external contributors
|
||||
|
||||
### 3.2 Operator Persona
|
||||
|
||||
**Journey**: Install -> Configure -> Start server -> Monitor -> Troubleshoot
|
||||
|
||||
| Step | Success Rate | Pain Level | Bottleneck |
|
||||
|------|-------------|------------|------------|
|
||||
| Install | Low | HIGH | No single installation script or Docker Compose for the full stack |
|
||||
| Configure | Moderate | MEDIUM | Config file path must be specified; no `--init` to generate default config |
|
||||
| Start server | Moderate | MEDIUM | `wifi-densepose start` works but database must be initialized first |
|
||||
| Monitor status | High | LOW | `wifi-densepose status --detailed` provides comprehensive output |
|
||||
| Stop server | High | LOW | Both graceful and force-stop options available |
|
||||
| Troubleshoot | Low | HIGH | Error messages reference internal exceptions; no runbook or FAQ |
|
||||
|
||||
**Key Findings:**
|
||||
- The CLI offers `start`, `stop`, `status`, `db init/migrate/rollback`, `config show/validate/failsafe`, `tasks run/status`, and `version` -- a reasonable command set
|
||||
- However, there is no `wifi-densepose init` command to scaffold a working configuration from scratch
|
||||
- The `config validate` command checks database, Redis, and directory availability -- good for operators
|
||||
- The `config failsafe` command showing SQLite fallback status is a strong resilience feature
|
||||
- Missing: log rotation configuration, log level adjustment at runtime, and a `wifi-densepose doctor` self-diagnosis command
|
||||
|
||||
### 3.3 End-User Persona (Mobile App User)
|
||||
|
||||
**Journey**: Open app -> Connect to server -> View live data -> Check vitals -> Manage zones -> Configure settings
|
||||
|
||||
| Step | Success Rate | Pain Level | Bottleneck |
|
||||
|------|-------------|------------|------------|
|
||||
| Open app | High | LOW | Clean initial load with loading spinners |
|
||||
| Connect to server | Moderate | MEDIUM | Default URL is `localhost:3000` which will not work on physical devices |
|
||||
| View live data | High | LOW | Simulation fallback ensures something is always displayed |
|
||||
| Check vitals | High | LOW | Gauges, sparklines, and classification render smoothly |
|
||||
| Manage zones | Moderate | LOW | Heatmap visualization is functional |
|
||||
| Configure settings | High | LOW | Server URL validation, test connection, save workflow is solid |
|
||||
|
||||
**Key Findings:**
|
||||
- The default `serverUrl` in `settingsStore.ts` is `http://localhost:3000`, which will fail on a physical device where the server runs on a different machine; a first-run setup wizard would improve this
|
||||
- Connection state management is well-implemented with three visible states: `LIVE STREAM`, `SIMULATED DATA`, and `DISCONNECTED` via `ConnectionBanner.tsx`
|
||||
- The simulation fallback (`generateSimulatedData()`) activates automatically when WebSocket connection fails, ensuring the app never shows a blank screen
|
||||
- The MAT (Mass Casualty Assessment Tool) screen seeds a training scenario on first load, which may confuse users who expect a clean state
|
||||
- `ErrorBoundary` provides crash recovery with a "Retry" button, but the error message is the raw JavaScript error (`error.message`) without user-friendly context
|
||||
|
||||
---
|
||||
|
||||
## 4. API Experience Analysis
|
||||
|
||||
### 4.1 Endpoint Structure (Score: 82/100)
|
||||
|
||||
The API follows RESTful conventions with clear resource paths:
|
||||
|
||||
```
|
||||
GET /health/health - System health
|
||||
GET /health/ready - Readiness probe
|
||||
GET /health/live - Liveness probe
|
||||
GET /health/metrics - System metrics (auth required for detailed)
|
||||
GET /health/version - Version info
|
||||
|
||||
GET /api/v1/pose/current - Current pose estimation
|
||||
POST /api/v1/pose/analyze - Custom analysis (auth required)
|
||||
GET /api/v1/pose/zones/{zone_id}/occupancy - Zone occupancy
|
||||
GET /api/v1/pose/zones/summary - All zones summary
|
||||
POST /api/v1/pose/historical - Historical data (auth required)
|
||||
GET /api/v1/pose/activities - Recent activities
|
||||
POST /api/v1/pose/calibrate - Start calibration (auth required)
|
||||
GET /api/v1/pose/calibration/status - Calibration status
|
||||
GET /api/v1/pose/stats - Statistics
|
||||
|
||||
WS /api/v1/stream/pose - Real-time pose stream
|
||||
WS /api/v1/stream/events - Event stream
|
||||
```
|
||||
|
||||
**Issues Found:**
|
||||
- `GET /health/health` is redundant path nesting; the health router is mounted at `/health` prefix, making the full path `/health/health`. This should be `/health` (root of the health router) or the prefix should be `/` for the health router
|
||||
- `POST /api/v1/pose/historical` uses POST for a read operation. While this is common for complex queries, it violates REST conventions. A `GET` with query parameters or a `POST /api/v1/pose/query` would be clearer
|
||||
- The root endpoint (`GET /`) exposes feature flags (`authentication`, `rate_limiting`) which could leak security posture information
|
||||
|
||||
### 4.2 Error Handling (Score: 85/100)
|
||||
|
||||
The `ErrorHandler` class in `v1/src/middleware/error_handler.py` is well-designed:
|
||||
|
||||
**Strengths:**
|
||||
- Structured error responses with consistent format: `{ "error": { "code": "...", "message": "...", "timestamp": "...", "request_id": "..." } }`
|
||||
- Request ID tracking via `X-Request-ID` header for debugging
|
||||
- Environment-aware: tracebacks included in development, hidden in production
|
||||
- Specialized handlers for HTTP, validation, Pydantic, database, and external service errors
|
||||
- Custom exception classes (`BusinessLogicError`, `ResourceNotFoundError`, `ConflictError`, `ServiceUnavailableError`) with domain context
|
||||
|
||||
**Issues Found:**
|
||||
- The `ErrorHandlingMiddleware` class exists but is commented out (line 432-434 in `error_handler.py`), meaning errors are handled by `setup_error_handling()` exception handlers instead. The middleware class and the exception handlers use different `ErrorHandler` instances, creating potential inconsistency if one is changed without the other
|
||||
- The `_is_database_error()` check uses string matching on module names (line 355-373), which is fragile. `"ConnectionError"` will match `aiohttp.ConnectionError` (an external service error), not just database connection errors
|
||||
- Error responses do not include a `documentation_url` field that could guide users to relevant docs
|
||||
|
||||
### 4.3 Rate Limiting UX (Score: 72/100)
|
||||
|
||||
**Strengths:**
|
||||
- Dual algorithm support: sliding window counter and token bucket
|
||||
- Per-endpoint rate limiting with per-user differentiation
|
||||
- Standard `X-RateLimit-*` headers on all responses
|
||||
- `Retry-After` header on 429 responses
|
||||
- Health/docs/metrics paths exempted from rate limiting
|
||||
- Configurable presets for development, production, API, and strict modes
|
||||
|
||||
**Issues Found:**
|
||||
- The 429 response body is `"Rate limit exceeded"` (a plain string). No structured error response with the `ErrorResponse` format is used. The rate limit middleware raises `HTTPException` directly rather than using `CustomHTTPException` or `ErrorResponse`
|
||||
- No information about which rate limit bucket was exhausted (per-IP vs per-user vs per-endpoint)
|
||||
- No rate limit dashboard or endpoint to check current rate limit status without making a request
|
||||
- The `RateLimitConfig` presets (development, production, api, strict) are defined but there is no CLI command or API endpoint to switch between them
|
||||
|
||||
### 4.4 WebSocket Experience (Score: 80/100)
|
||||
|
||||
**Strengths:**
|
||||
- Connection confirmation message with client ID and configuration on connect
|
||||
- Structured message protocol with `type` field (`ping`, `update_config`, `get_status`)
|
||||
- Invalid JSON is handled gracefully with an error message back to client
|
||||
- Stale connection cleanup every 60 seconds with 5-minute timeout
|
||||
- Zone-based and stream-type-based filtering for broadcasts
|
||||
- Client-side config updates without reconnection via `update_config` message
|
||||
|
||||
**Issues Found:**
|
||||
- Authentication is checked _after_ `websocket.accept()` (line 80-93 in `stream.py`), meaning unauthenticated clients briefly hold a connection before being closed. This wastes resources and leaks the existence of the endpoint
|
||||
- The `handle_websocket_message` function handles unknown message types with an error, but does not suggest valid message types: `"Unknown message type: foo"` should list valid options
|
||||
- No heartbeat/keepalive mechanism initiated from the server. The client must send ping messages. If the client does not ping, the connection will be considered stale after 5 minutes even if data is flowing
|
||||
- Close codes are not documented for clients to handle reconnection logic
|
||||
|
||||
### 4.5 API Documentation & Discoverability (Score: 58/100)
|
||||
|
||||
**Issues Found:**
|
||||
- Swagger UI (`/docs`) and ReDoc (`/redoc`) are **disabled in production** (line 146-148 of `main.py`): `docs_url=settings.docs_url if not settings.is_production else None`
|
||||
- No alternative documentation hosting for production environments
|
||||
- The `GET /` root endpoint and `GET /api/v1/info` endpoint provide feature information but no link to documentation
|
||||
- Pydantic models have good `Field(description=...)` annotations, which would generate useful OpenAPI docs -- but only visible in development
|
||||
- No API changelog or versioning documentation beyond the `version` field
|
||||
|
||||
---
|
||||
|
||||
## 5. CLI Experience Analysis
|
||||
|
||||
### 5.1 Command Structure (Score: 70/100)
|
||||
|
||||
The CLI uses Click with a nested group structure:
|
||||
|
||||
```
|
||||
wifi-densepose [--config FILE] [--verbose] [--debug]
|
||||
start [--host] [--port] [--workers] [--reload] [--daemon]
|
||||
stop [--force] [--timeout]
|
||||
status [--format text|json] [--detailed]
|
||||
db
|
||||
init [--url]
|
||||
migrate [--revision]
|
||||
rollback [--steps]
|
||||
tasks
|
||||
run [--task cleanup|monitoring|backup]
|
||||
status
|
||||
config
|
||||
show
|
||||
validate
|
||||
failsafe [--format text|json]
|
||||
version
|
||||
```
|
||||
|
||||
**Strengths:**
|
||||
- Logical grouping of commands (server, db, tasks, config)
|
||||
- Global options `--config`, `--verbose`, `--debug` available on all commands
|
||||
- `--daemon` mode with PID file management and stale PID detection
|
||||
- JSON output format option on `status` and `failsafe` for scripting
|
||||
|
||||
**Issues Found:**
|
||||
- No shell completion support (Click supports it but it is not configured)
|
||||
- No `init` or `setup` command to generate a default configuration file
|
||||
- No `logs` command to tail or search server logs
|
||||
- The `tasks status` subcommand shadows the parent `status` command in Click's namespace (line 347-348 in `cli.py` defines `def status(ctx):` under the `tasks` group), which works but creates confusion
|
||||
- No `--quiet` option for scripting (opposite of `--verbose`)
|
||||
- Error output goes through `logger.error()` which depends on logging configuration; if logging is misconfigured, errors are silently lost
|
||||
|
||||
### 5.2 Error Messages (Score: 60/100)
|
||||
|
||||
**Issues Found:**
|
||||
- Errors from `start` command show the raw exception: `"Failed to start server: {e}"` where `{e}` is the Python exception string
|
||||
- No suggestion for common failure scenarios. For example, if the database connection fails during `start`, the error is `"Database connection failed: [psycopg2 error]"` with no guidance like "Check your DATABASE_URL setting" or "Run 'wifi-densepose db init' first"
|
||||
- The `config validate` command outputs check-style messages (`"X Database connection: FAILED - {e}"`) which is helpful, but the X and checkmark characters use Unicode that may not render in all terminals
|
||||
- The `stop` command handles "Server is not running" gracefully, which is good
|
||||
- Missing: error codes that users could search for in documentation
|
||||
|
||||
### 5.3 Help Text (Score: 65/100)
|
||||
|
||||
**Strengths:**
|
||||
- Each command has a one-line description
|
||||
- Options have help text and defaults documented
|
||||
|
||||
**Issues Found:**
|
||||
- No examples in help text. The argparse `epilog` pattern used in `provision.py` is good practice but is not used in the Click CLI
|
||||
- No `--help` examples showing common workflows like "Start a development server", "Deploy to production", or "Initialize a fresh installation"
|
||||
- Command descriptions are terse: `"Start the WiFi-DensePose API server"` does not mention prerequisites
|
||||
|
||||
### 5.4 Configuration Workflow (Score: 68/100)
|
||||
|
||||
**Strengths:**
|
||||
- `config show` displays the full configuration without secrets
|
||||
- `config validate` checks database, Redis, and directory access
|
||||
- `config failsafe` shows SQLite fallback and Redis degradation status
|
||||
- Settings can be loaded from a file via `--config` flag
|
||||
|
||||
**Issues Found:**
|
||||
- No `config init` to generate a template configuration file
|
||||
- No `config set KEY VALUE` to modify individual settings
|
||||
- No environment variable listing showing which variables affect configuration
|
||||
- The `config show` output dumps JSON but does not annotate which values are defaults vs user-configured
|
||||
|
||||
---
|
||||
|
||||
## 6. Mobile App UX Analysis
|
||||
|
||||
### 6.1 Screen Flow Architecture (Score: 82/100)
|
||||
|
||||
The app uses a bottom tab navigator with five screens:
|
||||
|
||||
```
|
||||
Live (wifi icon) -> Vitals (heart) -> Zones (grid) -> MAT (shield) -> Settings (gear)
|
||||
```
|
||||
|
||||
**Strengths:**
|
||||
- Lazy loading of all screens with `React.lazy` and suspense fallbacks showing loading indicator with screen name
|
||||
- Fallback placeholder screens for any screen that fails to load: `"{label} screen not implemented yet"` with a "Placeholder shell" subtitle
|
||||
- MAT screen badge showing alert count in the tab bar
|
||||
- Icon mapping is clear and semantically appropriate
|
||||
|
||||
**Issues Found:**
|
||||
- `MainTabs.tsx` line 130: `component={() => <Suspended component={component} />}` creates a new function reference on every render. This should be refactored to a stable component reference to prevent unnecessary tab re-renders
|
||||
- No deep linking support for navigating directly to a screen from a notification or external URL
|
||||
- No screen transition animations configured; the default tab switch is abrupt
|
||||
- Tab labels use `fontFamily: 'Courier New'` which may not be available on all devices, with no fallback font specified
|
||||
|
||||
### 6.2 Connection Handling (Score: 88/100)
|
||||
|
||||
The WebSocket connection strategy in `ws.service.ts` is well-designed:
|
||||
|
||||
**Strengths:**
|
||||
- Exponential backoff reconnection: delays of 1s, 2s, 4s, 8s, 16s
|
||||
- Maximum 10 reconnection attempts before falling back to simulation
|
||||
- Simulation mode provides continuous data display even when disconnected
|
||||
- Connection status propagated to all screens via Zustand store
|
||||
- Clean disconnect with close code 1000
|
||||
- Auto-connect on app mount via `usePoseStream` hook
|
||||
- URL validation before attempting connection
|
||||
|
||||
**Issues Found:**
|
||||
- When reconnecting, the simulation timer starts immediately during the backoff delay, which means the user briefly sees "SIMULATED DATA" then "LIVE STREAM" then potentially "SIMULATED DATA" again if the reconnect fails. This creates a flickering experience
|
||||
- No user notification when switching between live and simulated modes beyond the banner color change
|
||||
- The WebSocket URL construction in `buildWsUrl()` hardcodes the path `/ws/sensing`, but the API server expects `/api/v1/stream/pose`. This path mismatch (`WS_PATH = '/api/v1/stream/pose'` in `constants/websocket.ts` vs `/ws/sensing` in `ws.service.ts`) is a potential connection failure point
|
||||
- No explicit ping/pong keepalive from the client; relies on the WebSocket protocol's built-in mechanism
|
||||
|
||||
### 6.3 Loading & Error States (Score: 78/100)
|
||||
|
||||
**Strengths:**
|
||||
- `LoadingSpinner` component with smooth rotation animation using `react-native-reanimated`
|
||||
- `ErrorBoundary` wraps the LiveScreen with crash recovery
|
||||
- LiveScreen shows a dedicated error state with "Live visualization failed", the error message, and a "Retry" button
|
||||
- Retry increments a `viewerKey` to force component remount
|
||||
- `ConnectionBanner` provides three distinct visual states with semantic colors (green/amber/red)
|
||||
|
||||
**Issues Found:**
|
||||
- The `ErrorBoundary` shows `error.message` directly, which may be a technical JavaScript error string like `"Cannot read property 'x' of undefined"`. A user-friendly message mapping would improve the experience
|
||||
- No timeout handling on loading states. If the GaussianSplat WebView never fires `onReady`, the loading spinner displays indefinitely
|
||||
- The VitalsScreen shows `N/A` for features when no data is available, but the gauges (`BreathingGauge`, `HeartRateGauge`) behavior at zero/null values is not guarded in the screen code
|
||||
- No skeleton loading states; screens jump from blank to fully rendered
|
||||
|
||||
### 6.4 State Management (Score: 85/100)
|
||||
|
||||
**Strengths:**
|
||||
- Zustand stores are well-structured with clear separation: `poseStore` (real-time data), `settingsStore` (configuration), `matStore` (MAT data)
|
||||
- `settingsStore` uses `persist` middleware with AsyncStorage for cross-session persistence
|
||||
- `poseStore` uses a `RingBuffer` for RSSI history, capping at 60 entries to prevent memory growth
|
||||
- Clean `reset()` method on `poseStore` to clear all state
|
||||
|
||||
**Issues Found:**
|
||||
- `poseStore` is not persisted, so all historical data is lost on app restart. For a monitoring application, this is a significant gap
|
||||
- The `handleFrame` method updates 6 state properties atomically in one `set()` call, which is correct, but the `rssiHistory` is computed from a module-level `RingBuffer` that exists outside the store, creating a potential synchronization issue during hot reload
|
||||
- No state migration strategy for `settingsStore` -- if the schema changes between app versions, persisted state may cause errors
|
||||
|
||||
### 6.5 Server Configuration UX (Score: 82/100)
|
||||
|
||||
The `ServerUrlInput` component in the Settings screen provides:
|
||||
|
||||
**Strengths:**
|
||||
- Real-time URL validation with `validateServerUrl()` showing error messages inline
|
||||
- "Test Connection" button that measures and displays response latency
|
||||
- Visual feedback: border turns red on invalid URL, test result shows checkmark/X with timing
|
||||
- "Save" button separated from "Test" to allow testing before committing
|
||||
|
||||
**Issues Found:**
|
||||
- Default server URL `http://localhost:3000` will never work on a physical device. The first-run experience should prompt for the server address or attempt auto-discovery via mDNS/Bonjour
|
||||
- No QR code scanner to configure server URL (common in IoT companion apps)
|
||||
- Test result is ephemeral -- it disappears when navigating away and returning
|
||||
- No validation of port range or IP address format beyond URL syntax
|
||||
- Save does not confirm success to the user; the connection simply restarts silently
|
||||
|
||||
---
|
||||
|
||||
## 7. Developer Experience (DX) Analysis
|
||||
|
||||
### 7.1 Build Process (Score: 65/100)
|
||||
|
||||
**Issues Found:**
|
||||
- Four separate build systems: Python (`pip`/`poetry`), Rust (`cargo`), Node.js (`npm`), and ESP-IDF for firmware
|
||||
- No unified `Makefile`, `Taskfile`, or `just` file to abstract build commands
|
||||
- `CLAUDE.md` lists build commands but they are mixed with AI agent configuration
|
||||
- Docker support is mentioned in the pre-merge checklist but no `docker-compose.yml` for local development was found
|
||||
- The Rust workspace has 15 crates with a specific publishing order -- this dependency chain is documented but not automated
|
||||
|
||||
### 7.2 Testing Experience (Score: 72/100)
|
||||
|
||||
**Strengths:**
|
||||
- Rust workspace has 1,031+ tests with a single command: `cargo test --workspace --no-default-features`
|
||||
- Deterministic proof verification via `python v1/data/proof/verify.py` with SHA-256 hash checking
|
||||
- Mobile app has comprehensive test coverage with tests for components, hooks, screens, services, stores, and utilities
|
||||
- Witness bundle verification with `VERIFY.sh` providing 7/7 pass/fail attestation
|
||||
|
||||
**Issues Found:**
|
||||
- No unified test runner across codebases
|
||||
- Python test command (`python -m pytest tests/ -x -q`) requires proper environment setup first
|
||||
- Mobile tests require additional setup (`jest`, React Native testing libraries)
|
||||
- No integration test suite that tests the full stack (API + WebSocket + Mobile)
|
||||
- No test coverage reporting configured for the Python codebase
|
||||
|
||||
### 7.3 Documentation Quality (Score: 62/100)
|
||||
|
||||
**Strengths:**
|
||||
- 43 Architecture Decision Records (ADRs) in `docs/adr/`
|
||||
- Domain-Driven Design documentation in `docs/ddd/`
|
||||
- Comprehensive hardware audit in ADR-028 with witness bundle
|
||||
- User guide at `docs/user-guide.md`
|
||||
|
||||
**Issues Found:**
|
||||
- No quickstart guide for first-time contributors
|
||||
- `CLAUDE.md` is 500+ lines but is primarily an AI agent configuration file, not a developer guide
|
||||
- No API reference documentation beyond the auto-generated Swagger (which is disabled in production)
|
||||
- No architecture diagram showing how the Python API, Rust core, mobile app, and ESP32 firmware interact
|
||||
- Missing: changelog is referenced in the pre-merge checklist but its location is not specified
|
||||
|
||||
### 7.4 Error Messages for Developers (Score: 70/100)
|
||||
|
||||
**Strengths:**
|
||||
- FastAPI validation errors return field-level details with type, message, and location
|
||||
- Rust crate errors use typed error types (`wifi-densepose-core`)
|
||||
- Middleware error handler includes traceback in development mode
|
||||
|
||||
**Issues Found:**
|
||||
- Python API errors in handlers use f-string formatting with raw exception messages: `f"Pose estimation failed: {str(e)}"`. These are user-facing but contain internal details
|
||||
- No error code catalog or error reference documentation
|
||||
- Startup validation errors print checkmarks but do not provide remediation steps
|
||||
|
||||
### 7.5 Configuration Management (Score: 68/100)
|
||||
|
||||
**Strengths:**
|
||||
- Pydantic `Settings` class with environment variable support
|
||||
- Configuration file loading via `--config` CLI flag
|
||||
- Database failsafe with SQLite fallback
|
||||
- Redis optional with graceful degradation
|
||||
|
||||
**Issues Found:**
|
||||
- No `.env.example` or `.env.template` file to guide environment variable setup
|
||||
- No configuration schema documentation beyond code inspection
|
||||
- Sensitive settings (database URL, JWT secret) are validated but error messages do not specify which environment variables to set
|
||||
- The `config show` command redacts secrets but does not explain where secrets should be configured
|
||||
|
||||
---
|
||||
|
||||
## 8. Hardware Integration UX Analysis
|
||||
|
||||
### 8.1 ESP32 Provisioning Flow (Score: 65/100)
|
||||
|
||||
The `provision.py` script in `firmware/esp32-csi-node/` handles WiFi credential and mesh configuration:
|
||||
|
||||
**Strengths:**
|
||||
- Clear `--help` text with usage examples in the argparse epilog
|
||||
- Parameter validation: TDM slot/total must be specified together, channel ranges validated, MAC format validated
|
||||
- `--dry-run` option to generate binary without flashing
|
||||
- Fallback CSV generation when NVS binary generation fails, with manual flash instructions
|
||||
- Password masked in output: `"WiFi Password: ****"`
|
||||
- Multiple NVS generator discovery methods (Python module, ESP-IDF bundled script)
|
||||
|
||||
**Issues Found:**
|
||||
- No auto-detection of serial port. The `--port` is required, but users may not know which port their ESP32 is on. A `--port auto` option using `serial.tools.list_ports` would help
|
||||
- No verification step after flashing to confirm the provisioned values were written correctly
|
||||
- Error when `esptool` or `nvs_partition_gen` is not installed is a raw Python exception. A friendlier message like `"Required tool 'esptool' not found. Install with: pip install esptool"` would be better
|
||||
- The script name is `provision.py` but it is invoked as `python firmware/esp32-csi-node/provision.py`, which is a long path. A CLI subcommand like `wifi-densepose hw provision` would integrate better
|
||||
- 22 command-line arguments is overwhelming; grouped parameter presets (e.g., `--profile basic`, `--profile mesh`, `--profile edge`) would simplify common use cases
|
||||
- No interactive mode for guided provisioning
|
||||
|
||||
### 8.2 Serial Monitoring (Score: 55/100)
|
||||
|
||||
**Issues Found:**
|
||||
- Serial monitoring is done via `python -m serial.tools.miniterm COM7 115200`, which is a raw tool with no structured log parsing
|
||||
- No custom monitoring tool that parses ESP32 output, highlights errors, or shows CSI data visualization
|
||||
- No documentation on what serial output to expect during normal operation vs error conditions
|
||||
- Baud rate (115200) must be known; no auto-baud detection
|
||||
|
||||
### 8.3 Firmware Update Process (Score: 60/100)
|
||||
|
||||
**Issues Found:**
|
||||
- Firmware flashing uses `idf.py flash` which requires the full ESP-IDF toolchain
|
||||
- No OTA (Over-The-Air) update workflow documented for field deployments
|
||||
- The `ota_data_initial.bin` is listed in the release process but OTA update instructions are not provided
|
||||
- No firmware version reporting from the device to verify the update was successful
|
||||
- 8MB and 4MB builds require different `sdkconfig.defaults` files with manual copying
|
||||
|
||||
---
|
||||
|
||||
## 9. Cross-Cutting Quality Concerns
|
||||
|
||||
### 9.1 Error Handling Quality Across Touchpoints (Score: 73/100)
|
||||
|
||||
| Touchpoint | Error Format | User Guidance | Recovery Path |
|
||||
|------------|-------------|---------------|---------------|
|
||||
| API REST | Structured JSON with code, message, request_id | No documentation links | Retry logic needed by client |
|
||||
| API WebSocket | JSON `{ type: "error", message: "..." }` | Lists valid message types: No | Reconnect |
|
||||
| CLI | Logger output to stderr | No remediation suggestions | Exit code 1 |
|
||||
| Mobile | `ErrorBoundary` with retry, `ConnectionBanner` | Raw error messages | Retry button, reconnect |
|
||||
| Provisioning | Python exceptions | Fallback CSV on failure | Manual flash instructions |
|
||||
|
||||
**Key Gap**: Error message styles differ between API (structured JSON) and CLI (logger strings). A unified error taxonomy would improve consistency.
|
||||
|
||||
### 9.2 Feedback Loops (Score: 72/100)
|
||||
|
||||
| Action | Feedback Mechanism | Timeliness | Quality |
|
||||
|--------|-------------------|------------|---------|
|
||||
| API request | HTTP status + response body | Immediate | Good |
|
||||
| WebSocket connect | `connection_established` message | Immediate | Good |
|
||||
| CLI start | Log messages to stdout | Real-time | Adequate |
|
||||
| CLI stop | "Server stopped gracefully" | After completion | Good |
|
||||
| Calibration start | Returns `calibration_id` and `estimated_duration_minutes` | Immediate | Incomplete (no progress stream) |
|
||||
| Mobile connect | Banner color change | ~1s delay | Good |
|
||||
| Firmware flash | `print()` statements | Real-time | Adequate |
|
||||
| Settings save | No confirmation | Silent | Poor |
|
||||
|
||||
### 9.3 Recovery Paths (Score: 68/100)
|
||||
|
||||
| Failure Scenario | Recovery Path | Automated? | Documentation |
|
||||
|-----------------|---------------|------------|---------------|
|
||||
| Database connection fails | SQLite failsafe fallback | Yes | `config failsafe` command |
|
||||
| Redis unavailable | Continues without Redis, logs warning | Yes | Mentioned in startup output |
|
||||
| WebSocket disconnects | Exponential backoff reconnection, simulation fallback | Yes | Not documented |
|
||||
| Stale PID file | Detected and cleaned up on `start`/`stop` | Yes | Not documented |
|
||||
| API server crash | No automatic restart | No | No systemd/supervisor config |
|
||||
| Mobile app crash | `ErrorBoundary` with retry | Partial | Not documented |
|
||||
| Firmware flash fails | Fallback CSV with manual instructions | Partial | Inline help |
|
||||
| Calibration fails | No documented recovery | No | Not documented |
|
||||
|
||||
### 9.4 Accessibility (Score: 45/100)
|
||||
|
||||
**Issues Found:**
|
||||
- Mobile app uses hardcoded hex colors throughout (e.g., `'#0F141E'`, `'#0F6B2A'`, `'#8A1E2A'`) with no high-contrast mode support
|
||||
- No `accessibilityLabel` or `accessibilityRole` props on interactive components in the mobile app
|
||||
- `ConnectionBanner` relies on color alone to distinguish states (green/amber/red). The text labels (`LIVE STREAM`, `SIMULATED DATA`, `DISCONNECTED`) help, but there is no screen reader announcement on state change
|
||||
- CLI status output uses emoji (checkmarks, X marks, weather symbols) as semantic indicators with no text-only fallback
|
||||
- API documentation (when available) has no known accessibility testing
|
||||
- No ARIA landmarks or roles in the sensing server web UI (if any)
|
||||
- Font sizes are fixed in the mobile theme with no dynamic type/accessibility sizing support
|
||||
|
||||
---
|
||||
|
||||
## 10. Oracle Problems Detected
|
||||
|
||||
### Oracle Problem 1 (HIGH): Production API Documentation vs Security
|
||||
|
||||
**Type**: User Need vs Business Need Conflict
|
||||
|
||||
- **User Need**: API consumers need documentation to discover and integrate with endpoints
|
||||
- **Business Need**: Hiding Swagger/ReDoc in production reduces attack surface
|
||||
- **Conflict**: Disabling docs entirely (`docs_url=None` when `is_production=True`) leaves production API consumers without any discoverability mechanism
|
||||
|
||||
**Failure Modes:**
|
||||
1. Developers working against production endpoints cannot discover available APIs
|
||||
2. Third-party integrators have no self-service documentation
|
||||
3. Internal teams must maintain separate documentation that can drift from the actual API
|
||||
|
||||
**Resolution Options:**
|
||||
| Option | User Score | Security Score | Recommendation |
|
||||
|--------|-----------|---------------|----------------|
|
||||
| Keep docs disabled | 20 | 95 | Current state |
|
||||
| Auth-gated docs endpoint | 85 | 80 | Recommended |
|
||||
| Separate docs site from OpenAPI spec export | 90 | 90 | Best but more effort |
|
||||
| Rate-limited docs with no auth | 70 | 60 | Compromise |
|
||||
|
||||
### Oracle Problem 2 (MEDIUM): Simulation Fallback vs Data Integrity
|
||||
|
||||
**Type**: User Experience vs Data Accuracy Conflict
|
||||
|
||||
- **User Need**: The app should always show something; blank screens feel broken
|
||||
- **Business Need**: Users should know when they are seeing real vs simulated data
|
||||
- **Conflict**: Automatic simulation fallback means users may not realize they lost their real data feed
|
||||
|
||||
**Failure Modes:**
|
||||
1. Operator monitors "activity" that is actually simulated, missing real events
|
||||
2. MAT (Mass Casualty Assessment) screen shows simulated survivor data during a real incident
|
||||
3. Vitals screen displays simulated breathing/heart rate data, creating false confidence
|
||||
|
||||
**Resolution Options:**
|
||||
| Option | UX Score | Safety Score | Recommendation |
|
||||
|--------|---------|-------------|----------------|
|
||||
| Current: auto-simulate with banner | 80 | 50 | Risky for safety-critical screens |
|
||||
| Disable simulation on MAT/Vitals screens | 60 | 85 | Recommended |
|
||||
| Prominent modal overlay for simulated mode | 70 | 80 | Good compromise |
|
||||
| Require user confirmation to enter simulation | 55 | 90 | Safest |
|
||||
|
||||
### Oracle Problem 3 (MEDIUM): WebSocket Path Mismatch
|
||||
|
||||
**Type**: Missing Information / Implementation Inconsistency
|
||||
|
||||
- **Evidence**: The mobile app's `ws.service.ts` constructs the WebSocket URL as `/ws/sensing` (line 104), while `constants/websocket.ts` defines `WS_PATH = '/api/v1/stream/pose'`. The API server serves WebSocket on `/api/v1/stream/pose` (stream router). These paths do not match.
|
||||
- **Impact**: The actual connection behavior depends on which path the sensing server uses (the lightweight Axum server may use `/ws/sensing`), but the inconsistency creates confusion and potential silent connection failures
|
||||
- **Resolution**: Align the WebSocket paths across the mobile app and server, or make the path configurable
|
||||
|
||||
---
|
||||
|
||||
## 11. Prioritized Recommendations
|
||||
|
||||
### Priority 1 -- Critical (address before next release)
|
||||
|
||||
| # | Recommendation | Effort | Impact | Persona |
|
||||
|---|---------------|--------|--------|---------|
|
||||
| 1.1 | Add auth-gated API documentation endpoint for production | Low | High | Developer, Operator |
|
||||
| 1.2 | Resolve WebSocket path mismatch between `ws.service.ts` and `constants/websocket.ts` | Low | High | End-User |
|
||||
| 1.3 | Disable automatic simulation fallback on MAT screen (safety-critical) | Low | High | End-User, Operator |
|
||||
| 1.4 | Fix `MainTabs.tsx` inline arrow function causing unnecessary re-renders (line 130) | Low | Medium | End-User |
|
||||
| 1.5 | Include structured error body in 429 rate limit responses using `ErrorResponse` format | Low | Medium | Developer |
|
||||
|
||||
### Priority 2 -- High (next sprint)
|
||||
|
||||
| # | Recommendation | Effort | Impact | Persona |
|
||||
|---|---------------|--------|--------|---------|
|
||||
| 2.1 | Add `wifi-densepose init` command to scaffold default configuration | Medium | High | Operator |
|
||||
| 2.2 | Change default mobile `serverUrl` from `localhost:3000` to empty string with first-run setup prompt | Medium | High | End-User |
|
||||
| 2.3 | Add terminal capability detection to CLI for emoji/unicode fallback | Medium | Medium | Operator |
|
||||
| 2.4 | Add calibration progress WebSocket stream or polling endpoint with step-by-step updates | Medium | Medium | Operator, Developer |
|
||||
| 2.5 | Create a `CONTRIBUTING.md` with quickstart for each codebase | Medium | High | Developer |
|
||||
| 2.6 | Map `ErrorBoundary` error messages to user-friendly strings | Low | Medium | End-User |
|
||||
| 2.7 | Add loading timeout to LiveScreen WebView initialization | Low | Medium | End-User |
|
||||
|
||||
### Priority 3 -- Medium (next quarter)
|
||||
|
||||
| # | Recommendation | Effort | Impact | Persona |
|
||||
|---|---------------|--------|--------|---------|
|
||||
| 3.1 | Create unified `Makefile` or `Taskfile` for cross-codebase builds and tests | High | High | Developer |
|
||||
| 3.2 | Add `--port auto` to provisioning script with serial port auto-detection | Medium | Medium | Operator |
|
||||
| 3.3 | Add accessibility labels to mobile app interactive components | Medium | Medium | End-User |
|
||||
| 3.4 | Create architecture diagram showing component interactions | Medium | High | Developer |
|
||||
| 3.5 | Add `.env.example` file documenting all environment variables | Low | Medium | Developer, Operator |
|
||||
| 3.6 | Implement `wifi-densepose doctor` for self-diagnosis | High | Medium | Operator |
|
||||
| 3.7 | Add `wifi-densepose logs` command with filtering and formatting | Medium | Medium | Operator |
|
||||
| 3.8 | Persist `poseStore` RSSI history for post-restart analysis | Medium | Low | End-User |
|
||||
| 3.9 | Add provisioning parameter presets (`--profile basic/mesh/edge`) | Medium | Medium | Operator |
|
||||
| 3.10 | Authenticate WebSocket before `websocket.accept()` | Low | Low | Developer |
|
||||
|
||||
---
|
||||
|
||||
## 12. Heuristic Scoring Summary
|
||||
|
||||
### Problem Analysis (H1)
|
||||
|
||||
| Heuristic | Score | Finding |
|
||||
|-----------|-------|---------|
|
||||
| H1.1: Understand the Problem | 75/100 | The system addresses WiFi-based pose estimation well but the quality experience varies significantly across touchpoints. The core problem (sensing and display) is well-solved; the surrounding experience (setup, configuration, debugging) needs work. |
|
||||
| H1.2: Identify Stakeholders | 70/100 | Three personas (developer, operator, end-user) are implicitly served but not explicitly designed for. The mobile app targets end-users well; the CLI targets operators adequately; developer experience is the weakest. |
|
||||
| H1.3: Define Quality Criteria | 65/100 | Health checks define "healthy/degraded/unhealthy" but no SLA or quality thresholds are documented. Rate limits are configurable but default values are not justified. |
|
||||
| H1.4: Map Failure Modes | 72/100 | Database failsafe, Redis degradation, and WebSocket reconnection cover major failure modes. Missing: calibration failure recovery, firmware flash failure recovery, mobile app state corruption. |
|
||||
|
||||
### User Needs (H2)
|
||||
|
||||
| Heuristic | Score | Finding |
|
||||
|-----------|-------|---------|
|
||||
| H2.1: Task Completion | 78/100 | Core tasks (view live data, check vitals, manage zones) are completable. Setup tasks (install, configure, provision) have friction. |
|
||||
| H2.2: Error Recovery | 68/100 | Some automated recovery (database failsafe, WebSocket reconnect). Missing recovery paths for calibration failure and firmware issues. |
|
||||
| H2.3: Learning Curve | 60/100 | Steep onboarding across four codebases. No quickstart guide. Mobile app is the most intuitive touchpoint. |
|
||||
| H2.4: Feedback Clarity | 72/100 | API provides structured feedback. CLI provides log-style feedback. Mobile provides visual feedback. Calibration progress is the biggest gap. |
|
||||
| H2.5: Consistency | 70/100 | Error formats differ between API (JSON) and CLI (logger). Mobile is internally consistent. Naming conventions mostly aligned. |
|
||||
|
||||
### Business Needs (H3)
|
||||
|
||||
| Heuristic | Score | Finding |
|
||||
|-----------|-------|---------|
|
||||
| H3.1: Reliability | 76/100 | Health checks, failsafes, and reconnection strategies demonstrate reliability focus. No documented SLAs or uptime targets. |
|
||||
| H3.2: Security Posture | 72/100 | Authentication framework exists but JWT validation is not implemented. Rate limiting is configurable. Production docs are hidden. Secrets redacted in config output. |
|
||||
| H3.3: Scalability | 68/100 | Multi-worker support, WebSocket connection management, per-endpoint rate limiting. No load testing results or capacity planning documented. |
|
||||
| H3.4: Maintainability | 74/100 | Well-separated crates, clear module boundaries, typed interfaces. Pre-merge checklist ensures documentation updates. ADR process is mature. |
|
||||
|
||||
### Balance (H4)
|
||||
|
||||
| Heuristic | Score | Finding |
|
||||
|-----------|-------|---------|
|
||||
| H4.1: UX vs Security | 65/100 | Production API docs disabled for security, but no alternative provided. Authentication errors are informative without leaking implementation details. |
|
||||
| H4.2: Simplicity vs Capability | 68/100 | Provisioning script has 22 parameters. CLI has good grouping but missing convenience features. API has comprehensive endpoints. |
|
||||
| H4.3: Consistency vs Flexibility | 72/100 | Error handling is structured but not uniform across touchpoints. Settings are flexible (env vars + config file + CLI flags). |
|
||||
|
||||
### Impact (H5)
|
||||
|
||||
| Heuristic | Score | Finding |
|
||||
|-----------|-------|---------|
|
||||
| H5.1: Visible Impact (GUI/UX) | 76/100 | Mobile app provides clear visual states. CLI status output is detailed. API responses are informative. |
|
||||
| H5.2: Invisible Impact (Performance) | 70/100 | `cpu_percent(interval=1)` in health check blocks for 1 second per request. Rate limiting uses async locks correctly. RingBuffer prevents memory growth. |
|
||||
| H5.3: Safety Impact | 62/100 | MAT screen auto-simulation is a safety concern. Simulated vitals data could mislead operators. No data provenance indicator beyond the connection banner. |
|
||||
| H5.4: Data Integrity | 72/100 | Pydantic validation on all inputs. Zone ID existence checks. Time range validation on historical queries. Deterministic proof verification for core pipeline. |
|
||||
|
||||
### Creativity (H6)
|
||||
|
||||
| Heuristic | Score | Finding |
|
||||
|-----------|-------|---------|
|
||||
| H6.1: Novel Testing Approaches | 68/100 | Witness bundle verification is creative. Deterministic proof with SHA-256 is strong. No mutation testing or property-based testing. |
|
||||
| H6.2: Alternative Perspectives | 65/100 | The simulation fallback is creative but creates oracle problems. Database failsafe is a pragmatic solution. |
|
||||
| H6.3: Cross-Domain Insights | 70/100 | WiFi CSI for pose estimation is inherently cross-domain (RF + computer vision + IoT). The mobile app's GaussianSplat visualization is innovative. |
|
||||
|
||||
---
|
||||
|
||||
## Methodology
|
||||
|
||||
This Quality Experience analysis was performed by examining source code across all touchpoints of the WiFi-DensePose system. Files analyzed include:
|
||||
|
||||
**API Layer (9 files):**
|
||||
- `v1/src/api/main.py` -- FastAPI application setup, middleware configuration, exception handlers
|
||||
- `v1/src/api/routers/health.py` -- Health check endpoints
|
||||
- `v1/src/api/routers/pose.py` -- Pose estimation endpoints
|
||||
- `v1/src/api/routers/stream.py` -- WebSocket streaming endpoints
|
||||
- `v1/src/api/websocket/connection_manager.py` -- WebSocket connection lifecycle
|
||||
- `v1/src/api/dependencies.py` -- Dependency injection, authentication, authorization
|
||||
- `v1/src/middleware/error_handler.py` -- Error handling middleware
|
||||
- `v1/src/middleware/rate_limit.py` -- Rate limiting middleware
|
||||
|
||||
**CLI Layer (4 files):**
|
||||
- `v1/src/cli.py` -- Click CLI entry point
|
||||
- `v1/src/commands/start.py` -- Server start command
|
||||
- `v1/src/commands/stop.py` -- Server stop command
|
||||
- `v1/src/commands/status.py` -- Server status command
|
||||
|
||||
**Mobile Layer (15 files):**
|
||||
- `ui/mobile/src/screens/LiveScreen/index.tsx` -- Live visualization screen
|
||||
- `ui/mobile/src/screens/VitalsScreen/index.tsx` -- Vitals monitoring screen
|
||||
- `ui/mobile/src/screens/ZonesScreen/index.tsx` -- Zone occupancy screen
|
||||
- `ui/mobile/src/screens/MATScreen/index.tsx` -- Mass casualty assessment screen
|
||||
- `ui/mobile/src/screens/SettingsScreen/index.tsx` -- Settings screen
|
||||
- `ui/mobile/src/screens/SettingsScreen/ServerUrlInput.tsx` -- Server URL configuration
|
||||
- `ui/mobile/src/navigation/MainTabs.tsx` -- Tab navigation
|
||||
- `ui/mobile/src/components/ErrorBoundary.tsx` -- Error boundary
|
||||
- `ui/mobile/src/components/ConnectionBanner.tsx` -- Connection status banner
|
||||
- `ui/mobile/src/components/LoadingSpinner.tsx` -- Loading indicator
|
||||
- `ui/mobile/src/services/ws.service.ts` -- WebSocket service
|
||||
- `ui/mobile/src/services/api.service.ts` -- HTTP API service
|
||||
- `ui/mobile/src/stores/poseStore.ts` -- Real-time data store
|
||||
- `ui/mobile/src/stores/settingsStore.ts` -- Persisted settings store
|
||||
- `ui/mobile/src/utils/urlValidator.ts` -- URL validation
|
||||
- `ui/mobile/src/hooks/usePoseStream.ts` -- Pose data stream hook
|
||||
- `ui/mobile/src/constants/websocket.ts` -- WebSocket constants
|
||||
|
||||
**Hardware Layer (1 file):**
|
||||
- `firmware/esp32-csi-node/provision.py` -- ESP32 provisioning script
|
||||
|
||||
The analysis applied 23 QX heuristics across 6 categories (Problem Analysis, User Needs, Business Needs, Balance, Impact, Creativity) and identified 3 oracle problems where quality criteria conflict across stakeholders.
|
||||
@@ -1,711 +0,0 @@
|
||||
# SFDIPOT Product Factors Assessment: wifi-densepose
|
||||
|
||||
**Assessment Date:** 2026-04-05
|
||||
**Assessor:** QE Product Factors Assessor (HTSM v6.3)
|
||||
**Framework:** James Bach's Heuristic Test Strategy Model -- Product Factors (SFDIPOT)
|
||||
**Scope:** Full wifi-densepose system -- Rust workspace (18 crates, 153k LoC), Python v1 (105 files, 39k LoC), ESP32 firmware (48 files, 1.6k LoC), CI/CD pipelines (8 workflows)
|
||||
**Test Count:** 2,618 Rust `#[test]` functions + 33 Python test files
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
The wifi-densepose project is an ambitious WiFi-based human pose estimation system spanning five deployment targets (server, desktop, WASM/browser, ESP32 embedded, mobile). This SFDIPOT assessment identifies **47 risk areas** across all seven product factors. The highest concentration of risk lies in **Time** (real-time processing constraints with no latency testing), **Platform** (6 target architectures with limited cross-platform validation), and **Interfaces** (multiple protocol boundaries with incomplete contract testing).
|
||||
|
||||
**Overall Risk Rating: HIGH** -- The system's safety-critical use case (Mass Casualty Assessment Tool) combined with multi-platform deployment and real-time signal processing demands rigorous testing that is currently only partially in place.
|
||||
|
||||
### Risk Heat Map
|
||||
|
||||
| Factor | Risk | Confidence | Test Coverage | Key Concern |
|
||||
|--------|------|------------|---------------|-------------|
|
||||
| **Structure** | MEDIUM | High | Good | 18 crates well-organized; MAT lib.rs at 626 lines pushes limit |
|
||||
| **Function** | HIGH | High | Moderate | Vital signs extraction, pose estimation accuracy unvalidated in production conditions |
|
||||
| **Data** | MEDIUM | High | Moderate | Proof-of-reality system strong; CSI data integrity across protocols untested |
|
||||
| **Interfaces** | HIGH | Medium | Low | REST API stub in Rust; Python/Rust boundary undefined; ESP32 serial protocol loosely coupled |
|
||||
| **Platform** | HIGH | Medium | Low | 6 deployment targets; ESP32 original/C3 excluded but not enforced at build level |
|
||||
| **Operations** | MEDIUM | Medium | Low | No Dockerfile; firmware OTA path defined but unvalidated end-to-end |
|
||||
| **Time** | CRITICAL | High | Very Low | 20 Hz target; no latency benchmarks; concurrent multi-node processing untested |
|
||||
|
||||
---
|
||||
|
||||
## S -- Structure
|
||||
|
||||
### What the product IS
|
||||
|
||||
#### S1: Code Integrity
|
||||
|
||||
**Finding:** The Rust workspace is well-structured with 18 crates following Domain-Driven Design bounded contexts. The `wifi-densepose-core` crate uses `#![forbid(unsafe_code)]` and provides clean trait abstractions (`SignalProcessor`, `NeuralInference`, `DataStore`). The crate dependency graph has a clear publish order documented in CLAUDE.md.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The `wifi-densepose-mat` lib.rs is 626 lines, exceeding the project's own 500-line limit specified in CLAUDE.md. The `DisasterResponse` struct owns 8 fields including an `Arc<dyn EventStore>`, making it a coordination bottleneck.
|
||||
- The `wifi-densepose-wasm-edge` crate is excluded from the workspace (`exclude = ["crates/wifi-densepose-wasm-edge"]`), meaning `cargo test --workspace` does not exercise it. This creates a coverage gap for edge deployment code (662 lines).
|
||||
- The `wifi-densepose-api` Rust crate is a 1-line stub (`//! WiFi-DensePose REST API (stub)`), while the Python v1 has a full FastAPI implementation. This implies the Rust port's API surface is incomplete.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| S-01 | P1 | Build `wifi-densepose-wasm-edge` separately (`cargo build -p wifi-densepose-wasm-edge --target wasm32-unknown-unknown`) and run any embedded tests to confirm they pass outside the workspace test run | Integration |
|
||||
| S-02 | P2 | Measure cyclomatic complexity of `DisasterResponse::scan_cycle` which spans 80+ lines with nested borrows and conditional event emission -- flag if complexity exceeds 15 | Unit |
|
||||
| S-03 | P2 | Run `cargo check --workspace --all-features` to surface feature-flag interaction issues across all 18 crates that are hidden by `--no-default-features` in CI | Integration |
|
||||
| S-04 | P3 | Count lines per file across all crates; flag any `.rs` file exceeding the 500-line project policy | Lint/CI |
|
||||
|
||||
#### S2: Dependencies
|
||||
|
||||
**Finding:** The workspace has 30+ external crate dependencies including heavy ones: `tch` (PyTorch FFI), `ort` (ONNX Runtime), `ndarray-linalg` with `openblas-static`, and 7 `ruvector-*` crates from crates.io. The `ruvector` dependency comment notes "Vendored at v2.1.0 in vendor/ruvector; using crates.io versions until published" -- suggesting a version mismatch risk between vendored and published code.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- `ort = "2.0.0-rc.11"` is a release candidate. RC dependencies in production code carry API stability risk.
|
||||
- `ndarray-linalg` with `openblas-static` forces a specific BLAS implementation that may conflict on certain platforms (ARM, WASM).
|
||||
- The `tch-backend` feature flag gates the entire training pipeline. If a developer enables it without libtorch installed, the build fails without a clear error path.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| S-05 | P1 | Run `cargo audit` to detect known vulnerabilities in the 30+ dependencies, particularly `ort` RC and `tch` FFI bindings | CI/Unit |
|
||||
| S-06 | P2 | Build the workspace on ARM64 (aarch64-unknown-linux-gnu) to confirm `openblas-static` compiles; the current CI only runs x86_64 | Integration |
|
||||
| S-07 | P2 | Toggle `tch-backend` feature on `wifi-densepose-train` without libtorch installed; confirm error message is actionable, not a cryptic linker failure | Human Exploration |
|
||||
|
||||
#### S3: Non-Executable Files
|
||||
|
||||
**Finding:** 43+ ADR documents, proof data files (`sample_csi_data.json`, `expected_features.sha256`), NVS configuration files for ESP32. The proof-of-reality system uses a published SHA-256 hash of pipeline output as a trust anchor.
|
||||
|
||||
**Risk: LOW**
|
||||
- The `expected_features.sha256` file is the single point of truth for pipeline integrity. If it is regenerated incorrectly (e.g., with a different numpy version), the proof becomes meaningless.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| S-08 | P0 | Run `python v1/data/proof/verify.py` in CI on every PR that touches `v1/src/core/` or `v1/src/hardware/` to catch proof-breaking changes | CI |
|
||||
| S-09 | P2 | Pin numpy/scipy versions in requirements.txt and confirm `verify.py --generate-hash` produces the same hash across Python 3.10, 3.11, and 3.12 | Integration |
|
||||
|
||||
---
|
||||
|
||||
## F -- Function
|
||||
|
||||
### What the product DOES
|
||||
|
||||
#### F1: Application -- Core Capabilities
|
||||
|
||||
**Finding:** The system advertises five core capabilities:
|
||||
1. CSI extraction from ESP32 hardware
|
||||
2. Signal processing (noise removal, phase sanitization, feature extraction, Doppler)
|
||||
3. Human presence detection and pose estimation (17-keypoint COCO format)
|
||||
4. Vital signs extraction (breathing rate, heart rate)
|
||||
5. Mass casualty assessment (survivor detection through debris)
|
||||
|
||||
The Python v1 CSI processor (`csi_processor.py`) implements a complete pipeline from raw CSI frames through feature extraction to human detection. The Rust port replicates and extends this with 14 RuvSense modules for multistatic sensing.
|
||||
|
||||
**Risk: HIGH**
|
||||
- The human detection confidence calculation in `_calculate_detection_confidence` uses hardcoded binary thresholds (`> 0.1`, `> 0.05`, `> 0.3`) with fixed weights (`0.4`, `0.3`, `0.3`). These are not calibrated against ground truth data.
|
||||
- The temporal smoothing factor (`smoothing_factor = 0.9`) means the system takes ~10 frames to respond to a presence change. For a 20 Hz system, that is 500ms of latency injected by design -- acceptable for presence but too slow for pose tracking.
|
||||
- The `EnsembleClassifier` in the MAT crate combines breathing, heartbeat, and movement classifiers but there are no integration tests validating that the ensemble confidence actually correlates with real survivor detection.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| F-01 | P0 | Feed 100 known-good CSI frames (from `sample_csi_data.json`) through the full Python pipeline and assert detection confidence is within expected range (0.7-0.95 for human-present frames) | Unit |
|
||||
| F-02 | P0 | Feed 100 CSI frames of background noise (no human present) and confirm detection confidence stays below threshold (< 0.3); false positive rate must be < 5% | Unit |
|
||||
| F-03 | P1 | Measure temporal smoothing convergence: inject a step change from no-human to human-present and count frames until confidence exceeds threshold; assert < 15 frames at 20 Hz | Unit |
|
||||
| F-04 | P1 | Run the MAT `EnsembleClassifier` with synthetic vital signs at confidence boundary (0.49, 0.50, 0.51) and confirm correct accept/reject behavior at the `confidence_threshold` boundary | Unit |
|
||||
| F-05 | P2 | Inject CSI data with `amplitudes.len() != phases.len()` into `DisasterResponse::push_csi_data` and confirm the error path returns `MatError::Detection` with descriptive message | Unit |
|
||||
|
||||
#### F2: Calculation Accuracy
|
||||
|
||||
**Finding:** The signal processing pipeline involves FFT (via `rustfft` and `scipy.fft`), correlation matrices, bandpass filtering, zero-crossing analysis, autocorrelation, and SVD decomposition. These are numerically sensitive operations.
|
||||
|
||||
**Risk: HIGH**
|
||||
- The Doppler extraction in Python uses `scipy.fft.fft` with `n=64` bins on a sliding window of cached phase values. The normalization divides by `max_val` which can amplify noise when the max is near zero.
|
||||
- The vital signs extractor (`BreathingExtractor`, `HeartRateExtractor`) uses bandpass filtering in specific Hz ranges (0.1-0.5 Hz for breathing, 0.8-2.0 Hz for heart rate). These filter boundaries are physiologically reasonable but have no tolerance handling for edge cases (e.g., athlete with 40 bpm resting heart rate = 0.67 Hz, below the 0.8 Hz lower bound).
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| F-06 | P0 | Generate a synthetic CSI signal with known Doppler shift (e.g., 2 Hz sinusoidal phase modulation) and confirm the Doppler extraction peak is within +/- 0.5 Hz of the injected frequency | Unit |
|
||||
| F-07 | P1 | Feed the `HeartRateExtractor` a signal at 0.67 Hz (40 bpm, athletic resting rate) and confirm it is either detected correctly or reported as `VitalEstimate::unavailable` -- not misclassified as breathing | Unit |
|
||||
| F-08 | P1 | Test Doppler normalization edge case: when `max_val` approaches zero (< 1e-12), confirm division does not produce NaN or Inf values | Unit |
|
||||
| F-09 | P2 | Compare Python `scipy.fft.fft` output against Rust `rustfft` output for the same 64-element input vector; assert difference < 1e-6 per bin | Integration |
|
||||
|
||||
#### F3: Error Handling
|
||||
|
||||
**Finding:** The Rust crates use `thiserror` with per-crate error enums (`MatError`, `SignalError`, `RuvSenseError`) that chain properly. The Python code uses custom exception classes (`CSIProcessingError`, `DatabaseConnectionError`). Both handle errors with descriptive messages.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The Python `CSIProcessor.process_csi_data` catches all exceptions with a blanket `except Exception as e` and wraps them in `CSIProcessingError`. This loses the original exception type and stack trace from the caller's perspective.
|
||||
- The Rust `scan_cycle` method silently discards event store errors with `let _ = self.event_store.append(...)`. In a disaster response context, losing domain events could mean missing survivor detections.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| F-10 | P1 | Make the `InMemoryEventStore` return an error on `append()` and confirm `scan_cycle` either propagates the error or logs it at WARN+ level -- not silently discard it | Unit |
|
||||
| F-11 | P2 | Inject a `numpy.linalg.LinAlgError` in the correlation matrix computation and confirm the error chain preserves the original exception type through `CSIProcessingError` | Unit |
|
||||
|
||||
#### F4: Security
|
||||
|
||||
**Finding:** The Python API implements authentication middleware (`AuthMiddleware`), rate limiting (`RateLimitMiddleware`), CORS configuration, and trusted host middleware for production. Settings require a `secret_key` field. The dev config endpoint redacts sensitive fields containing "secret", "password", "token", "key", "credential", "auth".
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The `secret_key` field uses `Field(...)` (required) but there is no validation on minimum key length or entropy.
|
||||
- CORS defaults to `["*"]` which is permissive. While overridable, the default is risky if deployed without configuration.
|
||||
- The readiness check at `/health/ready` hardcodes `ready = True` with a comment "Basic readiness - API is responding" and `checks["hardware_ready"] = True` regardless of actual hardware state. This defeats the purpose of a readiness probe.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| F-12 | P0 | Set `secret_key` to a 3-character string and confirm the application either rejects it at startup or logs a security warning | Unit |
|
||||
| F-13 | P1 | Submit a request to `/health/ready` when `pose_service` is `None` and confirm `ready` is reported as `False`, not hardcoded `True` | Integration |
|
||||
| F-14 | P1 | Set `environment=production` and confirm `/docs`, `/redoc`, and `/openapi.json` endpoints return 404, not the Swagger UI | E2E |
|
||||
| F-15 | P2 | Send 101 requests within the rate limit window and confirm the 101st is rejected with HTTP 429 | Integration |
|
||||
|
||||
#### F5: State Transitions
|
||||
|
||||
**Finding:** The system has multiple state machines:
|
||||
- `DeviceStatus`: ACTIVE -> INACTIVE -> MAINTENANCE -> ERROR
|
||||
- `SessionStatus`: ACTIVE -> COMPLETED / FAILED / CANCELLED
|
||||
- `ProcessingStatus`: PENDING -> PROCESSING -> COMPLETED / FAILED
|
||||
- ESP32 firmware: WiFi connecting -> connected -> CSI streaming
|
||||
- RuvSense `TrackLifecycleState`: lifecycle for pose tracks
|
||||
- MAT `ZoneStatus`: Active scan zones
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The database models define valid states via `CheckConstraint` but do not enforce transition rules (e.g., can a device go from ERROR directly to ACTIVE without going through MAINTENANCE?).
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| F-16 | P1 | Attempt to transition `DeviceStatus` from ERROR to ACTIVE directly and confirm the system either prevents it or logs the anomaly | Unit |
|
||||
| F-17 | P2 | Simulate a `Session` that is in COMPLETED status and attempt to add new CSI data to it; confirm it is rejected | Unit |
|
||||
|
||||
---
|
||||
|
||||
## D -- Data
|
||||
|
||||
### What the product PROCESSES
|
||||
|
||||
#### D1: Input Data
|
||||
|
||||
**Finding:** The system ingests CSI frames from multiple sources:
|
||||
- ESP32 ADR-018 binary protocol (UDP)
|
||||
- Serial port data via `serialport` crate
|
||||
- Sample JSON data (`sample_csi_data.json` with 1,000 synthetic frames)
|
||||
- `CsiData` Python dataclass: amplitude (ndarray), phase (ndarray), frequency, bandwidth, num_subcarriers, num_antennas, snr, metadata
|
||||
|
||||
The Rust `Esp32CsiParser::parse_frame` takes raw bytes and returns structured `CsiFrame` with amplitude/phase arrays.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The Python `CSIData` dataclass accepts arbitrary-shaped numpy arrays for amplitude and phase. There is no validation that `amplitude.shape == (num_antennas, num_subcarriers)`.
|
||||
- The ESP32 parser returns `ParseError::InsufficientData { needed, got }` but there is no handling for malformed data that has the right length but corrupt content (e.g., all-zero subcarrier data).
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| D-01 | P1 | Create a `CSIData` with `amplitude.shape = (3, 64)` but `num_antennas = 2` and confirm the processor rejects or reshapes it | Unit |
|
||||
| D-02 | P1 | Feed the ESP32 parser a correctly-sized but all-zero byte buffer and confirm it either rejects the frame (quality check) or marks `quality_score` as degraded | Unit |
|
||||
| D-03 | P2 | Feed the ESP32 parser a buffer with valid header but truncated subcarrier data; confirm `ParseError::InsufficientData` | Unit |
|
||||
| D-04 | P2 | Test boundary: exactly 256 subcarriers (MAX_SUBCARRIERS constant) and 257 subcarriers -- confirm correct handling | Unit |
|
||||
|
||||
#### D2: Data Persistence
|
||||
|
||||
**Finding:** The Python v1 uses SQLAlchemy with PostgreSQL (primary) and SQLite (failsafe fallback). The database schema includes 6 tables: `devices`, `sessions`, `csi_data`, `pose_detections`, `system_metrics`, `audit_logs`. The `csi_data` table stores amplitude and phase as `FloatArray` columns with a unique constraint on `(device_id, sequence_number, timestamp_ns)`.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- Storing raw CSI amplitude/phase arrays as database columns (FloatArray) is expensive. At 20 Hz with 56 subcarriers, that is 2,240 floats/second per device stored to PostgreSQL. No data retention policy or archival strategy is documented.
|
||||
- The SQLite fallback uses `NullPool` which means no connection reuse. Under load, this could exhaust file handles.
|
||||
- The `audit_logs` table tracks changes but there is no mention of log rotation or size limits.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| D-05 | P1 | Insert 100,000 CSI frames (simulating ~83 minutes of data at 20 Hz) into the database and measure query performance for time-range retrievals | Integration |
|
||||
| D-06 | P1 | Trigger PostgreSQL failover to SQLite and confirm: (a) no data loss during transition, (b) API continues responding, (c) health endpoint reports "degraded" not "healthy" | Integration |
|
||||
| D-07 | P2 | Insert CSI data with duplicate `(device_id, sequence_number, timestamp_ns)` and confirm the unique constraint fires with an appropriate error message | Unit |
|
||||
| D-08 | P3 | Run 1,000 concurrent SQLite connections via the NullPool fallback and monitor for "database is locked" errors | Integration |
|
||||
|
||||
#### D3: Proof Data Integrity
|
||||
|
||||
**Finding:** The proof-of-reality system (`v1/data/proof/verify.py`) is a deterministic pipeline verification tool. It feeds 1,000 synthetic CSI frames through the production CSI processor, hashes the output with SHA-256, and compares against a published hash. This is a strong engineering practice.
|
||||
|
||||
**Risk: LOW**
|
||||
- The proof only exercises the Python v1 pipeline. The Rust port has no equivalent proof-of-reality check.
|
||||
- The proof uses `seed=42` for synthetic data generation. If `numpy.random` changes its RNG implementation across versions, the proof breaks without any pipeline code change.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| D-09 | P0 | Run `verify.py` with `--audit` flag to scan for mock/random patterns in the codebase that could compromise pipeline integrity | CI |
|
||||
| D-10 | P1 | Create an equivalent proof-of-reality test for the Rust `wifi-densepose-signal` crate: feed the same 1,000 frames through `CsiProcessor::new(config)` and assert deterministic output | Unit |
|
||||
|
||||
---
|
||||
|
||||
## I -- Interfaces
|
||||
|
||||
### How the product CONNECTS
|
||||
|
||||
#### I1: REST API
|
||||
|
||||
**Finding:** The Python v1 exposes a FastAPI application with three router groups:
|
||||
- `/health/*` -- Health, readiness, liveness, metrics, version (5 endpoints)
|
||||
- `/api/v1/pose/*` -- Pose estimation endpoints
|
||||
- `/api/v1/stream/*` -- Streaming endpoints
|
||||
|
||||
The Rust `wifi-densepose-api` crate is a 1-line stub. The `wifi-densepose-mat` crate has its own `api` module with an Axum router (`create_router, AppState`).
|
||||
|
||||
**Risk: HIGH**
|
||||
- Two separate API implementations (Python FastAPI for v1, Rust Axum for MAT) with no shared contract or OpenAPI schema. A consumer cannot rely on interface consistency.
|
||||
- The Python API's general exception handler returns a generic "Internal server error" for all unhandled exceptions in production, but logs the full traceback. If logs are not monitored, 500 errors go unnoticed.
|
||||
- No API versioning enforcement: the prefix is configurable via `settings.api_prefix` but defaults to `/api/v1`. There is no v2 migration path documented.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| I-01 | P0 | Export OpenAPI spec from the Python FastAPI app and validate it against the actual endpoint behavior using Schemathesis or Dredd | E2E |
|
||||
| I-02 | P1 | Send malformed JSON to every POST endpoint and confirm each returns HTTP 422 with validation error details, not 500 | Integration |
|
||||
| I-03 | P1 | Hit the MAT Axum API and the Python FastAPI health endpoints in parallel and confirm they use compatible response schemas | Integration |
|
||||
| I-04 | P2 | Send a request with `Content-Type: text/xml` to a JSON endpoint and confirm HTTP 415 Unsupported Media Type, not a 500 crash | Integration |
|
||||
|
||||
#### I2: WebSocket Protocol
|
||||
|
||||
**Finding:** The Python v1 has a WebSocket subsystem (`connection_manager.py`, `pose_stream.py`) for real-time pose data streaming. The connection manager tracks active connections and provides stats.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- No WebSocket protocol specification (message format, heartbeat interval, reconnection policy).
|
||||
- The `connection_manager.shutdown()` is called during cleanup but there is no graceful disconnect message sent to connected clients.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| I-05 | P1 | Connect 100 WebSocket clients simultaneously and confirm: (a) all receive pose data, (b) connection stats are accurate, (c) no memory leak over 60 seconds | Integration |
|
||||
| I-06 | P1 | Disconnect a WebSocket client abruptly (TCP reset) and confirm the server cleans up the connection without leaking resources | Integration |
|
||||
| I-07 | P2 | Send a malformed message over WebSocket and confirm the server rejects it without disconnecting the client | Integration |
|
||||
|
||||
#### I3: ESP32 Serial/UDP Protocol
|
||||
|
||||
**Finding:** The ESP32 firmware uses ADR-018 binary format for CSI frames sent over UDP. The firmware includes WiFi reconnection logic with exponential retry (up to MAX_RETRY=10), NVS configuration persistence, OTA update capability, and WASM runtime support.
|
||||
|
||||
The Rust `Esp32CsiParser` parses the binary frames from UDP bytes.
|
||||
|
||||
**Risk: HIGH**
|
||||
- The ADR-018 binary protocol has no version field visible in the main.c header. If the protocol format changes, there is no way for the receiver to detect version mismatch.
|
||||
- The UDP transport is fire-and-forget. There is no acknowledgment, no sequence gap detection documented in the receiver, and no backpressure mechanism.
|
||||
- The `stream_sender.c` sends to a hardcoded or NVS-configured target IP. If the aggregator moves, the sensor is stranded until re-provisioned.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| I-08 | P0 | Inject a CSI frame with a future/unknown protocol version byte and confirm the parser returns `ParseError` with a version mismatch message, not a crash | Unit |
|
||||
| I-09 | P1 | Send 1,000 UDP CSI frames at 20 Hz from a simulated ESP32 and measure packet loss rate at the aggregator; assert < 1% loss on loopback | Integration |
|
||||
| I-10 | P1 | Simulate network partition: stop sending UDP frames for 5 seconds, then resume. Confirm the aggregator recovers without manual intervention | Integration |
|
||||
| I-11 | P2 | Send a UDP frame from a spoofed MAC address and confirm the aggregator either rejects or flags it (ADR-032 security hardening) | Integration |
|
||||
|
||||
#### I4: Inter-Crate Boundaries (Rust)
|
||||
|
||||
**Finding:** The Rust workspace has clear crate boundaries with `pub use` re-exports. The core traits (`SignalProcessor`, `NeuralInference`, `DataStore`) define contracts. However, some inter-crate communication uses concrete types rather than trait objects.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- `wifi-densepose-mat` depends on `wifi-densepose-signal::SignalError` directly via `#[from]`. This couples the MAT error hierarchy to Signal internals.
|
||||
- The `wifi-densepose-train` crate conditionally compiles 5 modules (`losses`, `metrics`, `model`, `proof`, `trainer`) behind the `tch-backend` feature. This means the training crate's public API surface changes dramatically based on feature flags.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| I-12 | P1 | Build `wifi-densepose-mat` with `wifi-densepose-signal` at a different version (e.g., mock a breaking change in `SignalError`) and confirm the type error is caught at compile time | Unit |
|
||||
| I-13 | P2 | Compile `wifi-densepose-train` with and without `tch-backend` and diff the public API symbols; document the feature-gated surface area | Integration |
|
||||
|
||||
#### I5: CLI Interface
|
||||
|
||||
**Finding:** The Rust CLI (`wifi-densepose-cli`) provides subcommands for MAT operations: `mat scan`, `mat status`, `mat survivors`, `mat alerts`. Built with `clap` derive macros.
|
||||
|
||||
**Risk: LOW**
|
||||
- CLI is narrowly scoped to MAT operations. No CLI for CSI data capture, signal processing, or model training.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| I-14 | P2 | Run `wifi-densepose --help`, `wifi-densepose mat --help`, and confirm all documented subcommands are present and help text is accurate | E2E |
|
||||
| I-15 | P3 | Run `wifi-densepose mat scan --zone ""` (empty zone name) and confirm a user-friendly error, not a panic | Unit |
|
||||
|
||||
---
|
||||
|
||||
## P -- Platform
|
||||
|
||||
### What the product DEPENDS ON
|
||||
|
||||
#### P1: Multi-Platform Build Targets
|
||||
|
||||
**Finding:** The project targets 6 platforms:
|
||||
1. **Linux x86_64** -- Primary development/server platform (CI runs here)
|
||||
2. **Windows** -- ESP32 firmware build requires special MSYSTEM env var stripping
|
||||
3. **macOS** -- CoreWLAN WiFi sensing (ADR-025), `mac_wifi.swift` in sensing module
|
||||
4. **ESP32-S3** -- Xtensa dual-core, 8MB/4MB flash variants
|
||||
5. **WASM (wasm32-unknown-unknown)** -- Browser deployment via wasm-pack
|
||||
6. **Desktop** -- `wifi-densepose-desktop` crate (52 lines in lib.rs, minimal)
|
||||
|
||||
Explicitly unsupported: ESP32 (original) and ESP32-C3 (single-core, cannot run DSP pipeline).
|
||||
|
||||
**Risk: HIGH**
|
||||
- The CI workflow (`ci.yml`) only runs on `ubuntu-latest`. No Windows, macOS, or ARM64 CI jobs for the Rust crates.
|
||||
- The macOS CoreWLAN integration (`mac_wifi.swift`) exists in the Python sensing module but there are no tests or build validation for it.
|
||||
- The `openblas-static` dependency in `ndarray-linalg` does not compile on `wasm32-unknown-unknown`, yet `wifi-densepose-signal` depends on it. This means any crate depending on `signal` cannot target WASM without feature gating.
|
||||
- The firmware CI (`firmware-ci.yml`, `firmware-qemu.yml`) exists but the `verify-pipeline.yml` suggests a separate verification path.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| P-01 | P0 | Add macOS and Windows CI runners for `cargo test --workspace --no-default-features` to catch platform-specific compilation failures | CI |
|
||||
| P-02 | P1 | Build `wifi-densepose-wasm` with `wasm-pack build --target web` in CI and confirm it produces a valid `.wasm` binary under 5 MB | CI |
|
||||
| P-03 | P1 | Flash the 4MB firmware variant to an ESP32-S3 and confirm it boots, connects to WiFi, and streams CSI frames within 30 seconds | Hardware/Human |
|
||||
| P-04 | P2 | Attempt to build the firmware for ESP32 (original, non-S3) and confirm the build fails with a clear error message about single-core incompatibility | Integration |
|
||||
|
||||
#### P2: External Software Dependencies
|
||||
|
||||
**Finding:** The system depends on:
|
||||
- PostgreSQL (primary database)
|
||||
- Redis (caching, rate limiting -- optional)
|
||||
- libtorch (PyTorch C++ backend -- optional via `tch-backend` feature)
|
||||
- ONNX Runtime (`ort` crate)
|
||||
- OpenBLAS (via `ndarray-linalg`)
|
||||
- ESP-IDF v5.4 (firmware toolchain)
|
||||
- wasm-pack (WASM build tool)
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The PostgreSQL-to-SQLite failsafe is a good design but the SQLite fallback does not support all PostgreSQL features (e.g., `UUID` columns, array types via `StringArray`/`FloatArray`). The `model_types.py` file likely provides compatibility shims but this is an untested assumption.
|
||||
- Redis is marked optional but the `RateLimitMiddleware` likely depends on it for distributed rate limiting. If Redis is down and rate limiting is enabled, what happens?
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| P-05 | P1 | Start the API with `redis_enabled=True` but Redis unavailable, and `redis_required=False`. Confirm the API starts, rate limiting degrades gracefully, and health reports "degraded" | Integration |
|
||||
| P-06 | P1 | Insert a `Device` record via SQLite fallback with a UUID primary key and StringArray capabilities column; confirm round-trip read matches the write | Integration |
|
||||
| P-07 | P2 | Run the full Python test suite on Python 3.12 (the CI uses 3.11) to catch forward-compatibility issues | CI |
|
||||
|
||||
#### P3: Hardware Compatibility
|
||||
|
||||
**Finding:** Supported hardware:
|
||||
- ESP32-S3 (8MB flash) at ~$9
|
||||
- ESP32-S3 SuperMini (4MB flash) at ~$6
|
||||
- ESP32-C6 + Seeed MR60BHA2 (60 GHz FMCW mmWave) at ~$15
|
||||
- HLK-LD2410 (24 GHz FMCW presence sensor) at ~$3
|
||||
|
||||
The ESP32-S3 is the primary sensing node. The mmWave sensors are auxiliary.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The 4MB flash variant (`sdkconfig.defaults.4mb`) may not have room for OTA + WASM runtime + display driver. Partition table conflicts are plausible but not tested in CI.
|
||||
- The mmWave sensor integration (`mmwave_sensor.c`) exists in firmware but there are no tests validating the serial protocol parsing for the MR60BHA2 radar.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| P-08 | P1 | Build 4MB firmware with OTA + WASM + display all enabled and confirm the binary fits within the 4MB flash partition | CI |
|
||||
| P-09 | P2 | Send synthetic MR60BHA2 serial output to the `mmwave_sensor.c` parser and confirm correct heart rate / breathing rate extraction | Unit |
|
||||
|
||||
---
|
||||
|
||||
## O -- Operations
|
||||
|
||||
### How the product is USED
|
||||
|
||||
#### O1: Deployment Model
|
||||
|
||||
**Finding:** No Dockerfile exists (only `.dockerignore`). CI includes `cd.yml` (continuous deployment) but deployment target is unknown. The firmware has a documented flash process using `idf.py` and a provisioning script (`provision.py`).
|
||||
|
||||
**Risk: HIGH**
|
||||
- Without a Dockerfile, the Python v1 API has no standardized deployment. Server setup is manual and environment-specific.
|
||||
- The firmware OTA update mechanism (`ota_update.c`) exists but the end-to-end update path (build -> sign -> distribute -> apply -> verify) is undocumented.
|
||||
- No Kubernetes manifests, systemd service files, or other deployment automation.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| O-01 | P1 | Create a Docker image for the Python v1 API and confirm it starts, responds to `/health/live`, and connects to a PostgreSQL container | Integration |
|
||||
| O-02 | P1 | Test the firmware OTA path: build a new firmware image, host it on HTTP, trigger OTA from the device, and confirm the device reboots with the new version | Hardware/Human |
|
||||
| O-03 | P2 | Run `wifi-densepose mat scan` on a freshly provisioned ESP32-S3 and confirm end-to-end data flow from sensor to CLI output | E2E/Human |
|
||||
|
||||
#### O2: Monitoring and Observability
|
||||
|
||||
**Finding:** The Python API provides comprehensive health checks (`/health/health`, `/health/ready`, `/health/live`), system metrics (CPU, memory, disk, network via `psutil`), and per-component health status. The Rust crates use `tracing` for structured logging.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The health check calls `psutil.cpu_percent(interval=1)` which blocks for 1 second. This makes the health endpoint slow and potentially a bottleneck under load.
|
||||
- The system metrics endpoint is available to unauthenticated users at `/health/metrics`. Only "detailed metrics" require authentication.
|
||||
- There is no distributed tracing (e.g., OpenTelemetry) for correlating requests across the Python API, ESP32 firmware, and potential Rust services.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| O-04 | P1 | Call `/health/health` 10 times concurrently and confirm total response time is < 15 seconds (not 10x the 1-second cpu_percent block) | Integration |
|
||||
| O-05 | P2 | Confirm `/health/metrics` does not expose PII, database credentials, or internal IP addresses in the response body | Security/E2E |
|
||||
|
||||
#### O3: User Workflows
|
||||
|
||||
**Finding:** Primary user workflows:
|
||||
1. Researcher: Configure sensors -> Collect CSI data -> Train model -> Evaluate
|
||||
2. Disaster responder: Deploy sensors -> Start MAT scan -> Monitor survivors -> Triage
|
||||
3. Developer: Clone repo -> Build -> Run tests -> Submit PR
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The disaster responder workflow is safety-critical. A false negative (missing a survivor) has life-or-death consequences. The system should have explicit false negative rate metrics but none are defined.
|
||||
- The developer workflow requires installing OpenBLAS, potentially libtorch, and ESP-IDF v5.4. No `devcontainer.json` or `nix-shell` to standardize the development environment.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| O-06 | P0 | Run the complete developer setup workflow from a clean Ubuntu 22.04 VM: clone, install deps, `cargo test --workspace --no-default-features`, `python v1/data/proof/verify.py` -- measure total setup time and document any manual steps | Human Exploration |
|
||||
| O-07 | P1 | Simulate a MAT scan with 5 survivors at varying signal strengths (strong, weak, borderline) and confirm the triage classification matches expected START protocol categories | Integration |
|
||||
|
||||
#### O4: Extreme Use
|
||||
|
||||
**Finding:** No load testing, stress testing, or chaos engineering infrastructure exists.
|
||||
|
||||
**Risk: HIGH**
|
||||
- The system targets disaster response scenarios where multiple ESP32 nodes stream simultaneously. The aggregator's behavior under 10+ concurrent node streams is unknown.
|
||||
- The database writes CSI data at 20 Hz per device. With 10 devices, that is 200 inserts/second of array data into PostgreSQL.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| O-08 | P1 | Simulate 10 ESP32 nodes streaming at 20 Hz to the aggregator and measure: packet loss, processing latency per frame, memory growth over 5 minutes | Performance |
|
||||
| O-09 | P2 | Fill the CSI history deque to `max_history_size=500` and confirm the oldest entry is evicted, not causing an OOM | Unit |
|
||||
|
||||
---
|
||||
|
||||
## T -- Time
|
||||
|
||||
### WHEN things happen
|
||||
|
||||
#### T1: Real-Time Processing
|
||||
|
||||
**Finding:** The RuvSense pipeline targets 20 Hz output (50ms per TDMA cycle). The vital signs extraction uses sample rates of 100 Hz with 30-second windows. The CSI processor uses configurable `sampling_rate`, `window_size`, and `overlap`.
|
||||
|
||||
**Risk: CRITICAL**
|
||||
- No latency benchmarks exist anywhere in the codebase. The 20 Hz target implies each frame must be processed in < 50ms including multi-band fusion, phase alignment, multistatic fusion, coherence gating, and pose tracking. This budget has never been measured.
|
||||
- The Python `process_csi_data` method is `async` but all the numpy operations inside are synchronous and CPU-bound. The `await` is cosmetic -- it does not yield to the event loop during computation.
|
||||
- The Doppler extraction iterates over the phase cache on every call. With `max_history_size=500`, this means constructing a 500-element numpy array from a deque on each frame.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| T-01 | P0 | Benchmark the Rust `RuvSensePipeline` end-to-end latency for a single frame with 4 nodes and 56 subcarriers; assert total processing time < 50ms on x86_64 | Benchmark |
|
||||
| T-02 | P0 | Benchmark the Python `CSIProcessor.process_csi_data` method for a single frame and assert it completes in < 25ms (leaving budget for I/O and networking) | Benchmark |
|
||||
| T-03 | P1 | Profile the Doppler extraction path with `max_history_size=500`: measure time spent in `list(self._phase_cache)` and `np.array(cache_list[-window:])` | Benchmark |
|
||||
| T-04 | P1 | Run the Python CSI processor with `asyncio.run()` and confirm it does not block the event loop for > 10ms per frame; use `asyncio.get_event_loop().slow_callback_duration` | Integration |
|
||||
|
||||
#### T2: Concurrency
|
||||
|
||||
**Finding:** The Rust system uses `tokio` for async runtime with `features = ["full"]`. The Python API uses FastAPI (async) with uvicorn workers. The ESP32 firmware uses FreeRTOS tasks. The `DisasterResponse::running` flag uses `AtomicBool` for thread-safe scanning control.
|
||||
|
||||
**Risk: HIGH**
|
||||
- The `DisasterResponse` struct is not `Send + Sync` safe by default (it contains `dyn EventStore` behind an `Arc`, but the struct itself is not wrapped in a `Mutex`). If `start_scanning` is called from multiple threads, the mutable self-reference causes a data race.
|
||||
- The Python `get_database_manager` uses a module-level global `_db_manager` with no thread-safety protection. With multiple uvicorn workers, each worker gets its own instance (process isolation), but within a single worker, concurrent requests could race on initialization.
|
||||
- The ESP32 firmware uses FreeRTOS event groups for WiFi state but the CSI callback runs in the WiFi driver context. If the callback takes too long (e.g., edge processing), it blocks WiFi reception.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| T-05 | P0 | Run `cargo test` under Miri (or ThreadSanitizer) for the `wifi-densepose-mat` crate to detect data races in `DisasterResponse` | CI |
|
||||
| T-06 | P1 | Call `DatabaseManager.initialize()` concurrently from 10 async tasks and confirm only one initialization occurs (no double-init race) | Integration |
|
||||
| T-07 | P1 | Measure the CSI callback execution time on ESP32 and confirm it completes in < 1ms to avoid blocking the WiFi driver | Hardware/Benchmark |
|
||||
| T-08 | P2 | Start and stop `DisasterResponse::start_scanning` from two different tokio tasks simultaneously and confirm no panic or deadlock | Unit |
|
||||
|
||||
#### T3: Scheduling and Timeouts
|
||||
|
||||
**Finding:** The MAT scan interval is configurable (`scan_interval_ms`, default 500ms, minimum 100ms). The database connection pool has `pool_timeout=30s` and `pool_recycle=3600s`. Redis has `socket_timeout=5s` and `connect_timeout=5s`.
|
||||
|
||||
**Risk: MEDIUM**
|
||||
- The ESP32 WiFi reconnection has `MAX_RETRY=10` but no backoff strategy. Ten rapid reconnection attempts could flood the AP.
|
||||
- No timeout on the `scan_cycle` method itself. If detection takes longer than `scan_interval_ms`, cycles overlap without back-pressure.
|
||||
- The `pool_recycle=3600` means database connections are recycled every hour. In a long-running deployment, this causes periodic connection churn.
|
||||
|
||||
**Test Ideas:**
|
||||
| # | Priority | Test Idea | Automation |
|
||||
|---|----------|-----------|------------|
|
||||
| T-09 | P1 | Set `scan_interval_ms=100` (minimum) and run a scan cycle that takes 200ms to complete; confirm the system does not accumulate a backlog of overlapping cycles | Unit |
|
||||
| T-10 | P2 | Simulate 10 WiFi disconnects in rapid succession on ESP32 and confirm the retry counter increments correctly and stops at MAX_RETRY=10 | Integration/Hardware |
|
||||
| T-11 | P2 | Keep the API running for 2 hours and confirm database pool recycling does not cause request failures during connection rotation | Integration |
|
||||
|
||||
---
|
||||
|
||||
## Product Coverage Outline (PCO)
|
||||
|
||||
| # | Testable Element | Reference | Product Factor(s) |
|
||||
|---|------------------|-----------|-------------------|
|
||||
| 1 | Cargo workspace build integrity | Cargo.toml, 18 crates | Structure |
|
||||
| 2 | WASM-edge crate exclusion gap | Cargo.toml `exclude` | Structure |
|
||||
| 3 | Dependency vulnerability surface | 30+ external crates | Structure |
|
||||
| 4 | CSI processing pipeline determinism | csi_processor.py, verify.py | Function, Data |
|
||||
| 5 | Human detection accuracy | _calculate_detection_confidence | Function |
|
||||
| 6 | Vital signs extraction boundaries | BreathingExtractor, HeartRateExtractor | Function, Data |
|
||||
| 7 | MAT ensemble classification | EnsembleClassifier | Function |
|
||||
| 8 | Error chain preservation | CSIProcessingError, MatError | Function |
|
||||
| 9 | Event store silent error discard | scan_cycle let _ = | Function |
|
||||
| 10 | Authentication and secrets management | Settings.secret_key, AuthMiddleware | Function |
|
||||
| 11 | Readiness probe accuracy | /health/ready hardcoded True | Function, Interfaces |
|
||||
| 12 | State machine transition enforcement | DeviceStatus, SessionStatus | Function |
|
||||
| 13 | CSI data shape validation | CSIData ndarray shapes | Data |
|
||||
| 14 | ESP32 binary protocol parsing | Esp32CsiParser | Data, Interfaces |
|
||||
| 15 | Database failover correctness | PostgreSQL -> SQLite | Data, Platform |
|
||||
| 16 | Proof-of-reality cross-platform | verify.py, Rust equivalent | Data |
|
||||
| 17 | REST API contract consistency | FastAPI, Axum MAT API | Interfaces |
|
||||
| 18 | WebSocket connection management | connection_manager.py | Interfaces |
|
||||
| 19 | UDP CSI transport reliability | stream_sender.c, aggregator | Interfaces |
|
||||
| 20 | Cross-platform compilation | Linux, macOS, Windows, WASM, ESP32 | Platform |
|
||||
| 21 | Hardware compatibility matrix | ESP32-S3 4MB/8MB, mmWave | Platform |
|
||||
| 22 | External service dependencies | PostgreSQL, Redis, libtorch | Platform |
|
||||
| 23 | Deployment automation | Missing Dockerfile | Operations |
|
||||
| 24 | OTA firmware update path | ota_update.c | Operations |
|
||||
| 25 | Health endpoint performance | psutil.cpu_percent blocking | Operations |
|
||||
| 26 | Multi-node stress testing | 10+ concurrent ESP32 streams | Operations, Time |
|
||||
| 27 | Real-time latency budget | 50ms target at 20 Hz | Time |
|
||||
| 28 | Async processing correctness | CPU-bound in async context | Time |
|
||||
| 29 | Thread safety and data races | DisasterResponse, DatabaseManager | Time |
|
||||
| 30 | Scan cycle timing overlap | scan_interval_ms vs processing time | Time |
|
||||
|
||||
---
|
||||
|
||||
## Test Data Suggestions
|
||||
|
||||
### Test Data for Structure-Based Tests
|
||||
- Cargo.toml with intentionally broken dependency versions to test build failure modes
|
||||
- `.rs` files at exactly 500 lines and 501 lines to test line-count policy enforcement
|
||||
- A workspace member list with a typo in the path to test error reporting
|
||||
|
||||
### Test Data for Function-Based Tests
|
||||
- 1,000 CSI frames from `sample_csi_data.json` as baseline input
|
||||
- Synthetic CSI frames with known Doppler shifts (1 Hz, 2 Hz, 5 Hz, 10 Hz)
|
||||
- Vital signs signals at physiological extremes: 8 bpm breathing (sleep apnea boundary), 200 bpm heart rate (tachycardia)
|
||||
- Empty CSI frames (all zeros), single-subcarrier frames, maximum-subcarrier frames (256)
|
||||
- EnsembleClassifier inputs at confidence boundary: 0.499, 0.500, 0.501
|
||||
|
||||
### Test Data for Data-Based Tests
|
||||
- 100,000 CSI frames for database stress testing (~83 minutes at 20 Hz)
|
||||
- Duplicate `(device_id, sequence_number, timestamp_ns)` tuples for constraint testing
|
||||
- CSIData with mismatched array shapes (`amplitude.shape != (num_antennas, num_subcarriers)`)
|
||||
- SQLite database files at 100 MB, 1 GB, and 10 GB for scaling tests
|
||||
|
||||
### Test Data for Interface-Based Tests
|
||||
- Valid and malformed ADR-018 binary frames (truncated, corrupted, oversized)
|
||||
- Spoofed MAC addresses in UDP frames for security testing
|
||||
- 100 concurrent WebSocket connections with varying message rates
|
||||
- OpenAPI specification exported from FastAPI for contract validation
|
||||
|
||||
### Test Data for Platform-Based Tests
|
||||
- Cross-compiled binaries for aarch64, x86_64, wasm32
|
||||
- ESP32-S3 4MB partition tables with all features enabled (should overflow)
|
||||
- MR60BHA2 radar serial output samples (synthetic)
|
||||
|
||||
### Test Data for Operations-Based Tests
|
||||
- Docker compose configuration with PostgreSQL + Redis + API
|
||||
- Firmware OTA images (valid, corrupted, oversized)
|
||||
- 10-node ESP32 mesh simulation traffic capture
|
||||
|
||||
### Test Data for Time-Based Tests
|
||||
- CSI frames with monotonically increasing timestamps at exactly 50ms intervals
|
||||
- CSI frames with jittered timestamps (+/- 10ms, +/- 25ms, +/- 50ms)
|
||||
- Phase cache at sizes: 0, 1, 2, 63, 64, 65, 499, 500 (boundary values for Doppler window)
|
||||
|
||||
---
|
||||
|
||||
## Suggestions for Exploratory Test Sessions
|
||||
|
||||
### Exploratory Test Sessions: Structure
|
||||
1. **Session: Crate Dependency Graph Walk** -- Starting from `wifi-densepose-cli`, trace every transitive dependency and look for diamond dependencies, version conflicts, or unnecessary coupling between crates that should be independent.
|
||||
2. **Session: Feature Flag Combinatorics** -- Systematically toggle feature flags on `wifi-densepose-train` (tch-backend on/off) and `wifi-densepose-core` (std/serde/async) and build each combination. Look for compilation failures, missing exports, or confusing error messages.
|
||||
|
||||
### Exploratory Test Sessions: Function
|
||||
3. **Session: Detection Confidence Calibration** -- Feed the CSI processor a sequence of frames that transitions from empty room to one person to two people. Observe how the confidence score evolves. Look for oscillation, slow convergence, or failure to distinguish scenarios.
|
||||
4. **Session: MAT Disaster Scenario Walkthrough** -- Set up a full MAT scan with 3 zones, inject synthetic CSI data representing 5 survivors at varying depths (0.5m, 2m, 5m). Observe triage classification, alert generation, and event store entries. Look for missing events or incorrect triage.
|
||||
|
||||
### Exploratory Test Sessions: Data
|
||||
5. **Session: Database Failover Chaos** -- Start the API with PostgreSQL, insert data, kill PostgreSQL, observe failover to SQLite, insert more data, restart PostgreSQL, and examine whether the system recovers. Look for data loss, schema incompatibilities, or stuck states.
|
||||
6. **Session: Proof of Reality Deep Dive** -- Run `verify.py --verbose` and `verify.py --audit` on a fresh checkout. Modify one line of `csi_processor.py` (e.g., change a threshold) and re-run verify. Look for how quickly the hash changes and whether the error message identifies what changed.
|
||||
|
||||
### Exploratory Test Sessions: Interfaces
|
||||
7. **Session: API Fuzzing Marathon** -- Use `schemathesis` or `restler` against the running FastAPI application for 30 minutes. Focus on edge cases: empty bodies, huge payloads (10 MB JSON), unicode in string fields, negative numbers in integer fields. Track every 500 response.
|
||||
8. **Session: ESP32 Protocol Mismatch Hunt** -- Capture real UDP traffic from an ESP32-S3, modify bytes at various offsets, and feed them to the `Esp32CsiParser`. Look for panics, undefined behavior, or incorrect but accepted frames.
|
||||
|
||||
### Exploratory Test Sessions: Platform
|
||||
9. **Session: macOS CoreWLAN Availability** -- On a macOS machine, attempt to use the `mac_wifi.swift` sensing module. Look for compilation issues, missing entitlements, or WiFi permission dialogs that block unattended operation.
|
||||
10. **Session: WASM in Browser** -- Build `wifi-densepose-wasm` and load it in Chrome, Firefox, and Safari. Call `MatDashboard` methods from the JavaScript console. Look for WASM memory limits, missing `web-sys` features, or browser-specific failures.
|
||||
|
||||
### Exploratory Test Sessions: Operations
|
||||
11. **Session: First-Time Setup Experience** -- Follow the README as a new developer on a clean Ubuntu 22.04 VM. Document every step that fails, every missing dependency, and every confusing error. Measure total time from `git clone` to first passing test.
|
||||
12. **Session: Firmware Provisioning End-to-End** -- Use the `provision.py` script to configure a real ESP32-S3 with WiFi credentials. Monitor serial output. Disconnect and reconnect. Look for edge cases in NVS persistence, WiFi credential storage, and recovery from bad configuration.
|
||||
|
||||
### Exploratory Test Sessions: Time
|
||||
13. **Session: Latency Budget Profiling** -- Instrument the Rust `RuvSensePipeline` with `tracing` spans on each stage (multiband, phase_align, multistatic, coherence, pose_tracker). Run 1,000 frames and produce a flame graph. Identify which stage consumes the most of the 50ms budget.
|
||||
14. **Session: Concurrent Scanning Stress** -- Start `DisasterResponse::start_scanning` with `continuous_monitoring=true` and `scan_interval_ms=100`. While scanning, call `push_csi_data` from a separate thread at 200 Hz. Look for data races, queue overflow, or missed scans.
|
||||
|
||||
---
|
||||
|
||||
## Clarifying Questions
|
||||
|
||||
Suggestions based on general risk patterns and analysis of the existing codebase:
|
||||
|
||||
### Structure
|
||||
1. What is the intended relationship between the Python v1 API and the Rust `wifi-densepose-api` stub? Is the Rust API planned to replace Python, or will they coexist?
|
||||
2. Why is `wifi-densepose-wasm-edge` excluded from the workspace? Are its tests run in a separate CI job, or are they not run at all?
|
||||
|
||||
### Function
|
||||
3. What is the acceptable false positive rate for human detection? What is the acceptable false negative rate for MAT survivor detection? These are not documented anywhere.
|
||||
4. The `HeartRateExtractor` bandpass filter starts at 0.8 Hz (48 bpm). Is this intentional, given that athletic resting heart rates can be 40 bpm (0.67 Hz)?
|
||||
5. The `smoothing_factor` of 0.9 introduces ~500ms lag at 20 Hz. Is this acceptable for the pose tracking use case, or should it be configurable per-mode?
|
||||
|
||||
### Data
|
||||
6. What is the data retention policy for CSI frames in PostgreSQL? At 20 Hz per device, storage grows at ~2.7 GB/day per device (estimated). Who is responsible for archival?
|
||||
7. Is there a plan to create a Rust-equivalent proof-of-reality test to ensure the Rust signal processing pipeline matches the Python pipeline output?
|
||||
|
||||
### Interfaces
|
||||
8. Does the ADR-018 binary protocol include a version byte? If the firmware and server are at different protocol versions, how is this detected?
|
||||
9. What is the WebSocket message format for pose data streaming? Is it documented in an ADR or schema file?
|
||||
10. Is there authentication on the UDP CSI data stream, or can any device on the network inject frames into the aggregator?
|
||||
|
||||
### Platform
|
||||
11. Is ARM64 (e.g., Raspberry Pi 4/5) a supported deployment target for the server? If so, has `openblas-static` been validated on ARM64?
|
||||
12. Are there plans for an Android or iOS mobile app, or is the `wifi-densepose-desktop` crate the only non-server deployment target?
|
||||
|
||||
### Operations
|
||||
13. Is there a Docker image on Docker Hub as mentioned in the pre-merge checklist? If so, what is the image name and how is it built?
|
||||
14. What is the firmware signing process for OTA updates? Is there a code-signing key, and how is it managed?
|
||||
15. Who monitors the `/health/health` endpoint in production? Is there an alerting integration (PagerDuty, Opsgenie, etc.)?
|
||||
|
||||
### Time
|
||||
16. Has the 20 Hz (50ms per frame) latency budget ever been measured on actual hardware with real CSI data? What is the measured P99 latency?
|
||||
17. What happens when `scan_cycle` takes longer than `scan_interval_ms`? Does the next cycle start immediately, or is there a backlog mechanism?
|
||||
18. The ESP32 CSI callback runs in the WiFi driver context. What is the maximum allowed execution time before WiFi reception is impacted?
|
||||
|
||||
---
|
||||
|
||||
## Assessment Quality Metrics
|
||||
|
||||
| Metric | Value | Target | Status |
|
||||
|--------|-------|--------|--------|
|
||||
| SFDIPOT categories covered | 7/7 | 7/7 | PASS |
|
||||
| Test ideas generated | 57 | 50+ | PASS |
|
||||
| P0 (Critical) | 10 (17.5%) | 8-12% | PASS (slightly above due to safety-critical MAT domain) |
|
||||
| P1 (High) | 20 (35.1%) | 20-30% | PASS |
|
||||
| P2 (Medium) | 20 (35.1%) | 35-45% | PASS |
|
||||
| P3 (Low) | 7 (12.3%) | 20-30% | BELOW (complex system with fewer trivial tests) |
|
||||
| Automation: Unit | 22 (38.6%) | 30-40% | PASS |
|
||||
| Automation: Integration | 19 (33.3%) | -- | PASS |
|
||||
| Automation: E2E | 5 (8.8%) | <=50% | PASS |
|
||||
| Automation: Benchmark | 5 (8.8%) | -- | N/A |
|
||||
| Automation: Human Exploration | 6 (10.5%) | >=10% | PASS |
|
||||
| Clarifying questions | 18 | 10+ | PASS |
|
||||
| Exploratory sessions | 14 | 7+ (one per factor) | PASS |
|
||||
|
||||
---
|
||||
|
||||
## Priority Summary: Top 10 Actions
|
||||
|
||||
1. **T-01/T-02 (P0):** Benchmark real-time processing latency against the 50ms budget. The entire system's viability depends on this.
|
||||
2. **F-01/F-02 (P0):** Establish baseline false positive/negative rates for human detection with known test data.
|
||||
3. **T-05 (P0):** Run ThreadSanitizer on the MAT crate to detect data races in the multi-threaded scanning path.
|
||||
4. **P-01 (P0):** Add macOS and Windows CI runners. A 6-platform project tested on 1 platform is a risk multiplier.
|
||||
5. **I-08 (P0):** Add protocol version detection to the ESP32 parser to prevent silent data corruption from version mismatches.
|
||||
6. **S-08/D-09 (P0):** Ensure proof-of-reality runs on every PR touching the signal processing pipeline.
|
||||
7. **F-12 (P0):** Validate that weak secrets are rejected at startup, not silently accepted.
|
||||
8. **O-06 (P0):** Document and automate the developer setup experience. A system this complex needs reproducible environments.
|
||||
9. **F-04 (P1):** Test MAT ensemble classifier at confidence boundaries. In disaster response, boundary behavior determines life-or-death decisions.
|
||||
10. **I-01 (P0):** Generate and validate OpenAPI contract. Two API implementations (Python + Rust) without a shared contract will inevitably diverge.
|
||||
|
||||
---
|
||||
|
||||
*Assessment generated using James Bach's HTSM Product Factors framework (SFDIPOT). All findings are based on static analysis of the codebase at commit 85434229 on the qe-reports branch. Risk ratings reflect both probability and impact, with the MAT safety-critical use case amplifying severity for all Function and Time findings.*
|
||||
@@ -1,514 +0,0 @@
|
||||
# QE Coverage Gap Analysis Report
|
||||
|
||||
**Project:** wifi-densepose (ruview)
|
||||
**Date:** 2026-04-05
|
||||
**Analyst:** QE Coverage Specialist (V3)
|
||||
**Scope:** Python v1, Rust workspace (17 crates + ruv-neural), Mobile (React Native), Firmware (ESP32 C)
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
| Codebase | Source Files | Files With Tests | Coverage Level | Risk |
|
||||
|----------|-------------|-----------------|----------------|------|
|
||||
| Python v1 | 59 | 18 | ~30% file coverage | **High** |
|
||||
| Rust workspace | 293 | 283 (inline `#[cfg(test)]`) | ~97% file coverage | Low |
|
||||
| Rust integration tests | -- | 16 test files | Moderate | Medium |
|
||||
| Mobile (React Native) | 71 | 25 | ~35% file coverage | Medium |
|
||||
| Firmware (ESP32 C) | 16 .c files | 3 fuzz targets | ~19% file coverage | **Critical** |
|
||||
|
||||
**Total source files across all codebases:** ~439
|
||||
**Files with some form of test coverage:** ~339
|
||||
**Estimated overall file-level coverage:** ~77%
|
||||
|
||||
**Key finding:** The Rust codebase has excellent inline test coverage (97% of source files contain `#[cfg(test)]` modules). The critical gaps are concentrated in Python services/infrastructure (0% coverage on 41 source files), firmware C code (13 of 16 source files untested), and mobile utility/navigation layers.
|
||||
|
||||
---
|
||||
|
||||
## 1. Python v1 Coverage Matrix
|
||||
|
||||
### 1.1 Covered Files (18 source files with dedicated tests)
|
||||
|
||||
| Source File | Test File(s) | Coverage Level | Notes |
|
||||
|------------|-------------|----------------|-------|
|
||||
| `core/csi_processor.py` (466 LOC) | `test_csi_processor.py`, `test_csi_processor_tdd.py` | High | Core DSP pipeline, dual test files |
|
||||
| `core/phase_sanitizer.py` (346 LOC) | `test_phase_sanitizer.py`, `test_phase_sanitizer_tdd.py` | High | Phase unwrapping, dual test files |
|
||||
| `core/router_interface.py` (293 LOC) | `test_router_interface.py`, `test_router_interface_tdd.py` | High | Router communication |
|
||||
| `hardware/csi_extractor.py` (515 LOC) | `test_csi_extractor.py`, `_direct.py`, `_tdd.py`, `_tdd_complete.py` | High | 4 test files, well covered |
|
||||
| `hardware/router_interface.py` (240 LOC) | `test_router_interface.py` | Medium | Shared with core test |
|
||||
| `models/densepose_head.py` (278 LOC) | `test_densepose_head.py` | Medium | Neural network head |
|
||||
| `models/modality_translation.py` (300 LOC) | `test_modality_translation.py` | Medium | WiFi-to-vision translation |
|
||||
| `sensing/*` (5 files, ~2,058 LOC) | `test_sensing.py` | Low | Single test file covers 5 source files |
|
||||
|
||||
**Integration test coverage:**
|
||||
|
||||
| Area | Test File | Covers |
|
||||
|------|----------|--------|
|
||||
| API endpoints | `test_api_endpoints.py` | Partial API router coverage |
|
||||
| Authentication | `test_authentication.py` | Partial middleware/auth |
|
||||
| CSI pipeline | `test_csi_pipeline.py` | End-to-end CSI flow |
|
||||
| Full system | `test_full_system_integration.py` | System-level orchestration |
|
||||
| Hardware | `test_hardware_integration.py` | Hardware service layer |
|
||||
| Inference | `test_inference_pipeline.py` | Model inference path |
|
||||
| Pose pipeline | `test_pose_pipeline.py` | Pose estimation flow |
|
||||
| Rate limiting | `test_rate_limiting.py` | Rate limit middleware |
|
||||
| Streaming | `test_streaming_pipeline.py` | Stream service |
|
||||
| WebSocket | `test_websocket_streaming.py` | WebSocket connections |
|
||||
|
||||
### 1.2 Uncovered Files (41 source files -- NO dedicated tests)
|
||||
|
||||
| Source File | LOC | Risk | Rationale |
|
||||
|------------|-----|------|-----------|
|
||||
| **`services/pose_service.py`** | **855** | **Critical** | Core pose estimation orchestration -- highest complexity, production path |
|
||||
| **`tasks/monitoring.py`** | **771** | **Critical** | System monitoring with DB queries, psutil, async tasks |
|
||||
| **`database/connection.py`** | **639** | **Critical** | SQLAlchemy + Redis connection management, pooling, error handling |
|
||||
| **`cli.py`** | **619** | **High** | CLI entry point, command routing |
|
||||
| **`tasks/backup.py`** | **609** | **High** | Database backup operations, file management |
|
||||
| **`tasks/cleanup.py`** | **597** | **High** | Data cleanup, retention policies |
|
||||
| **`commands/status.py`** | **510** | **High** | System status aggregation |
|
||||
| **`middleware/error_handler.py`** | **504** | **High** | Global error handling, affects all requests |
|
||||
| **`database/models.py`** | **497** | **High** | ORM models, schema definitions |
|
||||
| **`services/hardware_service.py`** | **481** | **High** | Hardware abstraction layer |
|
||||
| **`config/domains.py`** | **480** | **Medium** | Domain configuration |
|
||||
| **`services/health_check.py`** | **464** | **High** | Health check logic, dependency monitoring |
|
||||
| **`middleware/rate_limit.py`** | **464** | **High** | Rate limiting implementation |
|
||||
| **`api/routers/stream.py`** | **464** | **High** | Streaming API endpoints |
|
||||
| **`api/websocket/connection_manager.py`** | **460** | **Critical** | WebSocket connection lifecycle management |
|
||||
| **`middleware/auth.py`** | **456** | **Critical** | Authentication middleware -- security-critical |
|
||||
| **`config/settings.py`** | **436** | **Medium** | Settings management |
|
||||
| **`services/metrics.py`** | **430** | **Medium** | Metrics collection |
|
||||
| **`api/routers/health.py`** | **420** | **Medium** | Health check endpoints |
|
||||
| **`api/routers/pose.py`** | **419** | **High** | Pose estimation API endpoints |
|
||||
| **`services/stream_service.py`** | **396** | **High** | Real-time streaming logic |
|
||||
| **`services/orchestrator.py`** | **394** | **Critical** | Service lifecycle orchestration |
|
||||
| **`api/websocket/pose_stream.py`** | **383** | **High** | WebSocket pose streaming |
|
||||
| **`middleware/cors.py`** | **374** | **Medium** | CORS configuration |
|
||||
| **`commands/start.py`** | **358** | **Medium** | Server startup logic |
|
||||
| **`app.py`** | **336** | **Medium** | FastAPI app factory |
|
||||
| **`api/middleware/rate_limit.py`** | **325** | **Medium** | API-level rate limiting |
|
||||
| **`api/middleware/auth.py`** | **302** | **High** | API-level authentication |
|
||||
| **`commands/stop.py`** | **293** | **Medium** | Server shutdown logic |
|
||||
| **`main.py`** | **116** | **Low** | Entry point |
|
||||
| **`database/model_types.py`** | **59** | **Low** | Type definitions |
|
||||
| **`database/migrations/001_initial.py`** | -- | **Low** | Migration script |
|
||||
| **`database/migrations/env.py`** | -- | **Low** | Alembic config |
|
||||
| **`testing/mock_csi_generator.py`** | -- | **Low** | Test utility |
|
||||
| **`testing/mock_pose_generator.py`** | -- | **Low** | Test utility |
|
||||
| **`logger.py`** | -- | **Low** | Logging config |
|
||||
|
||||
**Total uncovered Python LOC: ~12,280** (out of ~18,523 total = **66% of code lacks unit tests**)
|
||||
|
||||
---
|
||||
|
||||
## 2. Rust Workspace Coverage Matrix
|
||||
|
||||
### 2.1 Crate-Level Summary
|
||||
|
||||
| Crate | Source Files | LOC | Files w/ `#[cfg(test)]` | Integration Tests | Coverage |
|
||||
|-------|-------------|-----|------------------------|-------------------|----------|
|
||||
| `wifi-densepose-core` | 5 | 2,596 | 5/5 (100%) | 0 | Excellent |
|
||||
| `wifi-densepose-signal` | 28 | 16,194 | 28/28 (100%) | 1 (`validation_test.rs`) | Excellent |
|
||||
| `wifi-densepose-nn` | 7 | 2,959 | 5/5 non-meta (100%) | 0 | Excellent |
|
||||
| `wifi-densepose-mat` | 43 | 19,572 | 36/37 (97%) | 1 (`integration_adr001.rs`) | Very Good |
|
||||
| `wifi-densepose-hardware` | 11 | 4,005 | 7/8 (88%) | 0 | Good |
|
||||
| `wifi-densepose-train` | 18 | 10,562 | 14/15 (93%) | 6 test files | Excellent |
|
||||
| `wifi-densepose-ruvector` | 16 | 4,629 | 12/12 non-meta (100%) | 0 | Excellent |
|
||||
| `wifi-densepose-vitals` | 7 | 1,863 | 6/6 non-meta (100%) | 0 | Excellent |
|
||||
| `wifi-densepose-wifiscan` | 23 | 5,779 | 16/17 (94%) | 0 | Very Good |
|
||||
| `wifi-densepose-sensing-server` | 18 | 17,825 | 15/16 (94%) | 3 test files | Very Good |
|
||||
| `wifi-densepose-wasm` | 2 | 1,805 | 1/1 (100%) | 0 | Good |
|
||||
| `wifi-densepose-wasm-edge` | 68 | 28,888 | 66/66 non-meta (100%) | 3 test files | Excellent |
|
||||
| `wifi-densepose-desktop` | 15 | 3,309 | 8/11 (73%) | 1 (`api_integration.rs`) | Moderate |
|
||||
| `wifi-densepose-cli` | 3 | 1,317 | 1/1 (100%) | 0 | Good |
|
||||
| `wifi-densepose-api` | 1 | 1 | 0 (stub) | 0 | N/A (stub) |
|
||||
| `wifi-densepose-db` | 1 | 1 | 0 (stub) | 0 | N/A (stub) |
|
||||
| `wifi-densepose-config` | 1 | 1 | 0 (stub) | 0 | N/A (stub) |
|
||||
|
||||
### 2.2 ruv-neural Sub-Crates
|
||||
|
||||
| Sub-Crate | LOC | Files | Files w/ Tests | Coverage |
|
||||
|-----------|-----|-------|---------------|----------|
|
||||
| `ruv-neural-core` | 2,325 | 11 | 2/11 (18%) | **Low** |
|
||||
| `ruv-neural-signal` | 2,157 | 7 | 6/7 (86%) | Good |
|
||||
| `ruv-neural-sensor` | 1,855 | 7 | 2/7 (29%) | **Low** |
|
||||
| `ruv-neural-mincut` | 2,394 | 8 | 7/8 (88%) | Good |
|
||||
| `ruv-neural-memory` | 1,547 | 6 | 5/6 (83%) | Good |
|
||||
| `ruv-neural-graph` | 1,887 | 7 | 6/7 (86%) | Good |
|
||||
| `ruv-neural-esp32` | 1,501 | 7 | 6/7 (86%) | Good |
|
||||
| `ruv-neural-embed` | 2,120 | 8 | 8/8 (100%) | Excellent |
|
||||
| `ruv-neural-decoder` | 1,509 | 6 | 5/6 (83%) | Good |
|
||||
| `ruv-neural-cli` | 1,701 | 9 | 7/9 (78%) | Good |
|
||||
| `ruv-neural-viz` | 1,314 | 6 | 5/6 (83%) | Good |
|
||||
| `ruv-neural-wasm` | 1,507 | 4 | 4/4 (100%) | Excellent |
|
||||
|
||||
### 2.3 Rust Files Without Inline Tests (Specific Gaps)
|
||||
|
||||
| File | Crate | LOC (est.) | Risk |
|
||||
|------|-------|-----------|------|
|
||||
| `api/handlers.rs` | wifi-densepose-mat | ~400 | High -- HTTP request handlers for MAT |
|
||||
| `adaptive_classifier.rs` | wifi-densepose-sensing-server | ~300 | High -- ML classifier |
|
||||
| `port/scan_port.rs` | wifi-densepose-wifiscan | ~200 | Medium -- WiFi scan port |
|
||||
| `domain/config.rs` | wifi-densepose-desktop | ~150 | Medium -- Desktop config |
|
||||
| `domain/firmware.rs` | wifi-densepose-desktop | ~200 | Medium -- Firmware domain model |
|
||||
| `domain/node.rs` | wifi-densepose-desktop | ~150 | Medium -- Node domain model |
|
||||
| `core/brain.rs` | ruv-neural-core | ~300 | High -- Neural brain logic |
|
||||
| `core/graph.rs` | ruv-neural-core | ~200 | Medium -- Graph construction |
|
||||
| `core/topology.rs` | ruv-neural-core | ~200 | Medium -- Topology management |
|
||||
| `core/sensor.rs` | ruv-neural-core | ~150 | Medium -- Sensor abstraction |
|
||||
| `core/signal.rs` | ruv-neural-core | ~150 | Medium -- Signal types |
|
||||
| `core/embedding.rs` | ruv-neural-core | ~150 | Medium -- Embedding logic |
|
||||
| `core/rvf.rs` | ruv-neural-core | ~100 | Medium -- RVF format |
|
||||
| `core/traits.rs` | ruv-neural-core | ~100 | Low -- Trait definitions |
|
||||
| `sensor/calibration.rs` | ruv-neural-sensor | ~200 | High -- Sensor calibration |
|
||||
| `sensor/eeg.rs` | ruv-neural-sensor | ~200 | Medium -- EEG processing |
|
||||
| `sensor/nv_diamond.rs` | ruv-neural-sensor | ~200 | Medium -- NV diamond sensor |
|
||||
| `sensor/quality.rs` | ruv-neural-sensor | ~150 | Medium -- Quality metrics |
|
||||
| `sensor/simulator.rs` | ruv-neural-sensor | ~150 | Low -- Simulator |
|
||||
|
||||
---
|
||||
|
||||
## 3. Mobile (React Native) Coverage Matrix
|
||||
|
||||
### 3.1 Covered Components (25 test files)
|
||||
|
||||
| Source | Test File | Coverage |
|
||||
|--------|----------|----------|
|
||||
| `components/ConnectionBanner.tsx` | `__tests__/components/ConnectionBanner.test.tsx` | Good |
|
||||
| `components/GaugeArc.tsx` | `__tests__/components/GaugeArc.test.tsx` | Good |
|
||||
| `components/HudOverlay.tsx` | `__tests__/components/HudOverlay.test.tsx` | Good |
|
||||
| `components/OccupancyGrid.tsx` | `__tests__/components/OccupancyGrid.test.tsx` | Good |
|
||||
| `components/SignalBar.tsx` | `__tests__/components/SignalBar.test.tsx` | Good |
|
||||
| `components/SparklineChart.tsx` | `__tests__/components/SparklineChart.test.tsx` | Good |
|
||||
| `components/StatusDot.tsx` | `__tests__/components/StatusDot.test.tsx` | Good |
|
||||
| `hooks/usePoseStream.ts` | `__tests__/hooks/usePoseStream.test.ts` | Good |
|
||||
| `hooks/useRssiScanner.ts` | `__tests__/hooks/useRssiScanner.test.ts` | Good |
|
||||
| `hooks/useServerReachability.ts` | `__tests__/hooks/useServerReachability.test.ts` | Good |
|
||||
| `screens/LiveScreen/` | `__tests__/screens/LiveScreen.test.tsx` | Medium |
|
||||
| `screens/MATScreen/` | `__tests__/screens/MATScreen.test.tsx` | Medium |
|
||||
| `screens/SettingsScreen/` | `__tests__/screens/SettingsScreen.test.tsx` | Medium |
|
||||
| `screens/VitalsScreen/` | `__tests__/screens/VitalsScreen.test.tsx` | Medium |
|
||||
| `screens/ZonesScreen/` | `__tests__/screens/ZonesScreen.test.tsx` | Medium |
|
||||
| `services/api.service.ts` | `__tests__/services/api.service.test.ts` | Good |
|
||||
| `services/rssi.service.ts` | `__tests__/services/rssi.service.test.ts` | Good |
|
||||
| `services/simulation.service.ts` | `__tests__/services/simulation.service.test.ts` | Good |
|
||||
| `services/ws.service.ts` | `__tests__/services/ws.service.test.ts` | Good |
|
||||
| `stores/matStore.ts` | `__tests__/stores/matStore.test.ts` | Good |
|
||||
| `stores/poseStore.ts` | `__tests__/stores/poseStore.test.ts` | Good |
|
||||
| `stores/settingsStore.ts` | `__tests__/stores/settingsStore.test.ts` | Good |
|
||||
| `utils/colorMap.ts` | `__tests__/utils/colorMap.test.ts` | Good |
|
||||
| `utils/ringBuffer.ts` | `__tests__/utils/ringBuffer.test.ts` | Good |
|
||||
| `utils/urlValidator.ts` | `__tests__/utils/urlValidator.test.ts` | Good |
|
||||
|
||||
### 3.2 Uncovered Files (46 source files -- NO tests)
|
||||
|
||||
| Source File | LOC (approx.) | Risk | Rationale |
|
||||
|------------|---------------|------|-----------|
|
||||
| **`components/ErrorBoundary.tsx`** | 40 | **High** | Error boundary -- critical for crash resilience |
|
||||
| `components/LoadingSpinner.tsx` | 30 | Low | Simple presentational |
|
||||
| `components/ModeBadge.tsx` | 25 | Low | Simple presentational |
|
||||
| `components/ThemedText.tsx` | 30 | Low | Theme wrapper |
|
||||
| `components/ThemedView.tsx` | 25 | Low | Theme wrapper |
|
||||
| **`hooks/useTheme.ts`** | 20 | Medium | Theme context hook |
|
||||
| **`hooks/useWebViewBridge.ts`** | 30 | **High** | Bridge to native WebView -- complex IPC |
|
||||
| **`navigation/MainTabs.tsx`** | 60 | Medium | Tab navigation config |
|
||||
| **`navigation/RootNavigator.tsx`** | 50 | Medium | Root navigation tree |
|
||||
| `navigation/types.ts` | 20 | Low | Type definitions |
|
||||
| **`screens/LiveScreen/GaussianSplatWebView.tsx`** | 80 | **High** | 3D Gaussian splat renderer |
|
||||
| **`screens/LiveScreen/GaussianSplatWebView.web.tsx`** | 60 | Medium | Web variant |
|
||||
| **`screens/LiveScreen/LiveHUD.tsx`** | 70 | Medium | HUD overlay sub-component |
|
||||
| **`screens/LiveScreen/useGaussianBridge.ts`** | 50 | **High** | Bridge hook for 3D rendering |
|
||||
| **`screens/MATScreen/AlertCard.tsx`** | 50 | Medium | Alert display card |
|
||||
| **`screens/MATScreen/AlertList.tsx`** | 40 | Low | Alert list container |
|
||||
| **`screens/MATScreen/MatWebView.tsx`** | 60 | Medium | MAT WebView integration |
|
||||
| **`screens/MATScreen/SurvivorCounter.tsx`** | 30 | Low | Counter display |
|
||||
| **`screens/MATScreen/useMatBridge.ts`** | 50 | Medium | Bridge hook |
|
||||
| **`screens/SettingsScreen/RssiToggle.tsx`** | 30 | Low | Toggle component |
|
||||
| **`screens/SettingsScreen/ServerUrlInput.tsx`** | 40 | Medium | URL input with validation |
|
||||
| **`screens/SettingsScreen/ThemePicker.tsx`** | 35 | Low | Theme selection |
|
||||
| **`screens/VitalsScreen/BreathingGauge.tsx`** | 50 | Medium | Breathing rate gauge |
|
||||
| **`screens/VitalsScreen/HeartRateGauge.tsx`** | 50 | Medium | Heart rate gauge |
|
||||
| **`screens/VitalsScreen/MetricCard.tsx`** | 35 | Low | Metric display card |
|
||||
| **`screens/ZonesScreen/FloorPlanSvg.tsx`** | 80 | Medium | SVG floor plan rendering |
|
||||
| **`screens/ZonesScreen/ZoneLegend.tsx`** | 30 | Low | Legend component |
|
||||
| **`screens/ZonesScreen/useOccupancyGrid.ts`** | 50 | Medium | Occupancy calculation hook |
|
||||
| `services/rssi.service.android.ts` | 40 | Medium | Platform-specific RSSI |
|
||||
| `services/rssi.service.ios.ts` | 40 | Medium | Platform-specific RSSI |
|
||||
| `services/rssi.service.web.ts` | 30 | Low | Web fallback |
|
||||
| `theme/ThemeContext.tsx` | 40 | Medium | Theme provider |
|
||||
| `theme/colors.ts` | 20 | Low | Color constants |
|
||||
| `theme/spacing.ts` | 15 | Low | Spacing constants |
|
||||
| `theme/typography.ts` | 20 | Low | Typography config |
|
||||
| `theme/index.ts` | 10 | Low | Re-exports |
|
||||
| `constants/api.ts` | 15 | Low | API constants |
|
||||
| `constants/simulation.ts` | 10 | Low | Simulation constants |
|
||||
| `constants/websocket.ts` | 12 | Low | WebSocket constants |
|
||||
| `types/api.ts` | 40 | Low | Type definitions |
|
||||
| `types/mat.ts` | 30 | Low | Type definitions |
|
||||
| `types/navigation.ts` | 15 | Low | Type definitions |
|
||||
| `types/sensing.ts` | 25 | Low | Type definitions |
|
||||
| `utils/formatters.ts` | 30 | Medium | Data formatting utilities |
|
||||
|
||||
---
|
||||
|
||||
## 4. Firmware (ESP32 C) Coverage Matrix
|
||||
|
||||
### 4.1 Source Files
|
||||
|
||||
| Source File | LOC | Test Coverage | Risk |
|
||||
|------------|-----|--------------|------|
|
||||
| **`edge_processing.c`** | **1,067** | **Fuzz: `fuzz_edge_enqueue.c`** | **High** -- partial fuzz only |
|
||||
| **`wasm_runtime.c`** | **867** | **None** | **Critical** -- WASM execution on embedded |
|
||||
| **`mock_csi.c`** | **696** | **None** | Low -- test utility |
|
||||
| **`mmwave_sensor.c`** | **571** | **None** | **Critical** -- 60GHz FMCW sensor driver |
|
||||
| **`wasm_upload.c`** | **432** | **None** | **High** -- OTA WASM upload, security boundary |
|
||||
| **`csi_collector.c`** | **420** | **Fuzz: `fuzz_csi_serialize.c`** | Medium -- partial fuzz |
|
||||
| **`display_ui.c`** | **386** | **None** | Low -- UI rendering |
|
||||
| **`display_hal.c`** | **382** | **None** | Low -- Display HAL |
|
||||
| **`nvs_config.c`** | **333** | **Fuzz: `fuzz_nvs_config.c`** | Medium -- config storage |
|
||||
| **`swarm_bridge.c`** | **327** | **None** | **Critical** -- Multi-node mesh networking |
|
||||
| **`main.c`** | **301** | **None** | Medium -- Startup/init |
|
||||
| **`ota_update.c`** | **266** | **None** | **Critical** -- OTA firmware updates, security |
|
||||
| **`rvf_parser.c`** | **239** | **None** | **High** -- Binary format parsing |
|
||||
| **`display_task.c`** | **175** | **None** | Low -- Display task |
|
||||
| **`stream_sender.c`** | **116** | **None** | Medium -- Network data sender |
|
||||
| **`power_mgmt.c`** | **81** | **None** | Medium -- Power management |
|
||||
|
||||
**Firmware coverage summary:**
|
||||
- 3 fuzz test files cover portions of 3 source files (`csi_collector`, `edge_processing`, `nvs_config`)
|
||||
- 13 of 16 source files (81%) have zero test coverage
|
||||
- **4,435 LOC in security/network-critical firmware is completely untested** (`wasm_runtime`, `mmwave_sensor`, `swarm_bridge`, `ota_update`, `wasm_upload`)
|
||||
|
||||
---
|
||||
|
||||
## 5. Top 20 Highest-Risk Uncovered Areas
|
||||
|
||||
| Rank | File | Codebase | LOC | Risk | Risk Score | Reason |
|
||||
|------|------|----------|-----|------|-----------|--------|
|
||||
| 1 | `firmware/main/wasm_runtime.c` | Firmware | 867 | **Critical** | 0.98 | WASM execution on embedded device, untested attack surface |
|
||||
| 2 | `firmware/main/ota_update.c` | Firmware | 266 | **Critical** | 0.97 | OTA firmware update -- integrity/authentication critical |
|
||||
| 3 | `firmware/main/swarm_bridge.c` | Firmware | 327 | **Critical** | 0.96 | Multi-node mesh networking, untested protocol |
|
||||
| 4 | `v1/src/services/pose_service.py` | Python | 855 | **Critical** | 0.95 | Core production path, highest complexity, no unit tests |
|
||||
| 5 | `v1/src/middleware/auth.py` | Python | 456 | **Critical** | 0.94 | Authentication -- security-critical, no unit tests |
|
||||
| 6 | `v1/src/api/websocket/connection_manager.py` | Python | 460 | **Critical** | 0.93 | WebSocket lifecycle, connection state, no tests |
|
||||
| 7 | `firmware/main/mmwave_sensor.c` | Firmware | 571 | **Critical** | 0.92 | 60GHz FMCW sensor driver, hardware-critical |
|
||||
| 8 | `firmware/main/wasm_upload.c` | Firmware | 432 | **Critical** | 0.91 | OTA WASM upload, code injection risk |
|
||||
| 9 | `v1/src/services/orchestrator.py` | Python | 394 | **Critical** | 0.90 | Service lifecycle management, no tests |
|
||||
| 10 | `v1/src/database/connection.py` | Python | 639 | **Critical** | 0.89 | DB + Redis connection management, pooling |
|
||||
| 11 | `v1/src/middleware/error_handler.py` | Python | 504 | **High** | 0.87 | Global error handler, affects all requests |
|
||||
| 12 | `v1/src/tasks/monitoring.py` | Python | 771 | **High** | 0.86 | System monitoring, DB queries, async tasks |
|
||||
| 13 | `v1/src/services/hardware_service.py` | Python | 481 | **High** | 0.85 | Hardware abstraction, device management |
|
||||
| 14 | `v1/src/middleware/rate_limit.py` | Python | 464 | **High** | 0.84 | Rate limiting -- DoS protection |
|
||||
| 15 | `v1/src/services/health_check.py` | Python | 464 | **High** | 0.83 | Health monitoring, dependency checks |
|
||||
| 16 | `v1/src/tasks/backup.py` | Python | 609 | **High** | 0.82 | Data backup operations |
|
||||
| 17 | `v1/src/tasks/cleanup.py` | Python | 597 | **High** | 0.81 | Data retention, cleanup logic |
|
||||
| 18 | `firmware/main/rvf_parser.c` | Firmware | 239 | **High** | 0.80 | Binary format parsing -- buffer overflow risk |
|
||||
| 19 | `v1/src/api/routers/pose.py` | Python | 419 | **High** | 0.79 | Pose API endpoint handlers |
|
||||
| 20 | `mobile/hooks/useWebViewBridge.ts` | Mobile | 30 | **High** | 0.78 | Native-WebView IPC bridge |
|
||||
|
||||
---
|
||||
|
||||
## 6. Test Generation Recommendations
|
||||
|
||||
### 6.1 Priority 1: Critical -- Immediate Action Required
|
||||
|
||||
#### P1-1: Firmware Security Tests
|
||||
**Target:** `wasm_runtime.c`, `ota_update.c`, `swarm_bridge.c`, `wasm_upload.c`
|
||||
**Test Type:** Unit tests + fuzz tests
|
||||
**Recommended Scenarios:**
|
||||
- Fuzz test for `wasm_runtime.c`: malformed WASM bytecode, oversized modules, stack overflow
|
||||
- Fuzz test for `ota_update.c`: corrupted firmware images, invalid signatures, partial downloads
|
||||
- Fuzz test for `swarm_bridge.c`: malformed mesh packets, replay attacks, node spoofing
|
||||
- Fuzz test for `wasm_upload.c`: oversized payloads, interrupted transfers, malicious modules
|
||||
- Unit tests for all boundary conditions in binary parsing paths
|
||||
|
||||
#### P1-2: Python Authentication and Security Middleware
|
||||
**Target:** `middleware/auth.py`, `api/middleware/auth.py`
|
||||
**Test Type:** Unit tests + integration tests
|
||||
**Recommended Scenarios:**
|
||||
- Valid/invalid JWT token handling
|
||||
- Token expiration and refresh flows
|
||||
- Missing authorization headers
|
||||
- Role-based access control enforcement
|
||||
- SQL injection in authentication queries
|
||||
- Timing attack resistance on token comparison
|
||||
- Session fixation prevention
|
||||
|
||||
#### P1-3: Python Core Services
|
||||
**Target:** `services/pose_service.py`, `services/orchestrator.py`
|
||||
**Test Type:** Unit tests (mock-first TDD)
|
||||
**Recommended Scenarios:**
|
||||
- `PoseService`: CSI data processing pipeline, model inference fallback, mock mode vs production mode isolation, concurrent pose estimation, error propagation
|
||||
- `ServiceOrchestrator`: Service startup ordering, graceful shutdown, background task management, health aggregation, error recovery
|
||||
|
||||
#### P1-4: Database Connection Management
|
||||
**Target:** `database/connection.py`
|
||||
**Test Type:** Unit tests + integration tests
|
||||
**Recommended Scenarios:**
|
||||
- Connection pool exhaustion handling
|
||||
- Redis connection failure and reconnection
|
||||
- Async session lifecycle management
|
||||
- Connection string validation
|
||||
- Transaction isolation verification
|
||||
- Graceful degradation when database is unreachable
|
||||
|
||||
### 6.2 Priority 2: High -- Next Sprint
|
||||
|
||||
#### P2-1: Python WebSocket Layer
|
||||
**Target:** `api/websocket/connection_manager.py`, `api/websocket/pose_stream.py`
|
||||
**Test Type:** Unit tests + integration tests
|
||||
**Recommended Scenarios:**
|
||||
- Connection lifecycle (open, message, close, error)
|
||||
- Concurrent connection handling
|
||||
- Message serialization/deserialization
|
||||
- Backpressure handling on slow consumers
|
||||
- Reconnection logic
|
||||
- Broadcast to multiple subscribers
|
||||
|
||||
#### P2-2: Python Infrastructure Tasks
|
||||
**Target:** `tasks/monitoring.py`, `tasks/backup.py`, `tasks/cleanup.py`
|
||||
**Test Type:** Unit tests
|
||||
**Recommended Scenarios:**
|
||||
- Monitoring: metric collection, threshold alerting, database query mocking
|
||||
- Backup: file creation, rotation policy, error handling on disk full
|
||||
- Cleanup: retention policy enforcement, safe deletion, dry-run mode
|
||||
|
||||
#### P2-3: Python Error Handling
|
||||
**Target:** `middleware/error_handler.py`, `middleware/rate_limit.py`
|
||||
**Test Type:** Unit tests
|
||||
**Recommended Scenarios:**
|
||||
- Error handler: exception type mapping, response format, stack trace sanitization, logging
|
||||
- Rate limiter: request counting, window sliding, IP-based limiting, exemption rules
|
||||
|
||||
#### P2-4: Firmware Sensor Drivers
|
||||
**Target:** `mmwave_sensor.c`, `rvf_parser.c`
|
||||
**Test Type:** Fuzz tests + unit tests
|
||||
**Recommended Scenarios:**
|
||||
- mmWave: invalid sensor data, communication timeout, calibration failure
|
||||
- RVF parser: malformed headers, truncated data, integer overflow in length fields
|
||||
|
||||
### 6.3 Priority 3: Medium -- Scheduled Improvement
|
||||
|
||||
#### P3-1: Mobile Sub-Components
|
||||
**Target:** Screen sub-components (`GaussianSplatWebView`, `AlertCard`, `FloorPlanSvg`, etc.)
|
||||
**Test Type:** Component tests (React Native Testing Library)
|
||||
**Recommended Scenarios:**
|
||||
- Render with various prop combinations
|
||||
- Error state rendering
|
||||
- Loading state transitions
|
||||
- Accessibility compliance (labels, roles)
|
||||
- Snapshot tests for visual regression
|
||||
|
||||
#### P3-2: Mobile Hooks and Navigation
|
||||
**Target:** `useWebViewBridge.ts`, `useTheme.ts`, `MainTabs.tsx`, `RootNavigator.tsx`
|
||||
**Test Type:** Hook tests + navigation tests
|
||||
**Recommended Scenarios:**
|
||||
- WebView bridge: message passing, error handling, reconnection
|
||||
- Theme hook: theme switching, default values
|
||||
- Navigation: screen transitions, deep linking, back button behavior
|
||||
|
||||
#### P3-3: Rust Desktop Domain Models
|
||||
**Target:** `desktop/src/domain/config.rs`, `firmware.rs`, `node.rs`
|
||||
**Test Type:** Unit tests (inline `#[cfg(test)]`)
|
||||
**Recommended Scenarios:**
|
||||
- Config: serialization roundtrip, default values, validation
|
||||
- Firmware: version comparison, compatibility checks
|
||||
- Node: state transitions, connection lifecycle
|
||||
|
||||
#### P3-4: Rust MAT API Handlers
|
||||
**Target:** `mat/src/api/handlers.rs`
|
||||
**Test Type:** Integration tests
|
||||
**Recommended Scenarios:**
|
||||
- Request validation for all endpoints
|
||||
- Error response formatting
|
||||
- Concurrent request handling
|
||||
- Authorization enforcement
|
||||
|
||||
#### P3-5: Mobile Utility Functions
|
||||
**Target:** `utils/formatters.ts`
|
||||
**Test Type:** Unit tests
|
||||
**Recommended Scenarios:**
|
||||
- Number formatting edge cases
|
||||
- Date/time formatting across locales
|
||||
- Null/undefined input handling
|
||||
|
||||
### 6.4 Priority 4: Low -- Backlog
|
||||
|
||||
#### P4-1: Python CLI and Commands
|
||||
**Target:** `cli.py`, `commands/start.py`, `commands/stop.py`, `commands/status.py`
|
||||
**Test Type:** Integration tests
|
||||
**Recommended Scenarios:**
|
||||
- Command parsing, help text, invalid arguments
|
||||
- Startup/shutdown sequence verification
|
||||
|
||||
#### P4-2: Mobile Theme and Constants
|
||||
**Target:** `theme/`, `constants/`, `types/`
|
||||
**Test Type:** Unit tests (snapshot/value verification)
|
||||
|
||||
#### P4-3: ruv-neural Core Types
|
||||
**Target:** `ruv-neural-core/src/{brain,graph,topology,sensor,signal,embedding,rvf,traits}.rs`
|
||||
**Test Type:** Unit tests (inline `#[cfg(test)]`)
|
||||
|
||||
#### P4-4: ruv-neural Sensor Crate
|
||||
**Target:** `ruv-neural-sensor/src/{calibration,eeg,nv_diamond,quality,simulator}.rs`
|
||||
**Test Type:** Unit tests (inline `#[cfg(test)]`)
|
||||
|
||||
---
|
||||
|
||||
## 7. Coverage Improvement Roadmap
|
||||
|
||||
### Phase 1: Security-Critical (Weeks 1-2)
|
||||
- Add 4 firmware fuzz tests (wasm_runtime, ota_update, swarm_bridge, wasm_upload)
|
||||
- Add Python auth middleware unit tests (30+ test cases)
|
||||
- Add Python WebSocket connection manager tests (20+ test cases)
|
||||
- **Expected improvement:** Firmware 19% -> 44%, Python 30% -> 38%
|
||||
|
||||
### Phase 2: Core Business Logic (Weeks 3-4)
|
||||
- Add pose_service, orchestrator, hardware_service unit tests (60+ test cases)
|
||||
- Add database/connection integration tests (15+ test cases)
|
||||
- Add monitoring/backup/cleanup task tests (30+ test cases)
|
||||
- **Expected improvement:** Python 38% -> 55%
|
||||
|
||||
### Phase 3: API and Infrastructure (Weeks 5-6)
|
||||
- Add error_handler, rate_limit middleware tests (25+ test cases)
|
||||
- Add API router tests for stream, health, pose endpoints (30+ test cases)
|
||||
- Add mobile sub-component tests (25+ test cases)
|
||||
- **Expected improvement:** Python 55% -> 70%, Mobile 35% -> 55%
|
||||
|
||||
### Phase 4: Polish and Edge Cases (Weeks 7-8)
|
||||
- Add Rust desktop domain model tests
|
||||
- Add mobile navigation and hook tests
|
||||
- Add firmware rvf_parser and edge_processing unit tests
|
||||
- Add remaining Python CLI/command tests
|
||||
- **Expected improvement:** All codebases at 70%+ file coverage
|
||||
|
||||
### Target State
|
||||
|
||||
| Codebase | Current | Target | Gap to Close |
|
||||
|----------|---------|--------|-------------|
|
||||
| Python v1 | ~30% | 75% | +45% (185+ new tests) |
|
||||
| Rust workspace | ~97% | 99% | +2% (15+ new tests) |
|
||||
| Mobile | ~35% | 65% | +30% (50+ new tests) |
|
||||
| Firmware | ~19% | 50% | +31% (8 new fuzz + 20 unit tests) |
|
||||
|
||||
---
|
||||
|
||||
## 8. Risk Assessment Methodology
|
||||
|
||||
Risk scores (0.0 - 1.0) were calculated using:
|
||||
|
||||
| Factor | Weight | Description |
|
||||
|--------|--------|-------------|
|
||||
| Code complexity | 30% | LOC, cyclomatic complexity, dependency count |
|
||||
| Security criticality | 25% | Authentication, authorization, network boundary, input parsing |
|
||||
| Change frequency | 15% | Git commit frequency on the file |
|
||||
| Blast radius | 15% | How many other components depend on this code |
|
||||
| Data sensitivity | 10% | Handles PII, credentials, or firmware integrity |
|
||||
| Testability | 5% | How difficult the code is to test (hardware deps, async, etc.) |
|
||||
|
||||
Files scoring above 0.85 are flagged as Critical, 0.70-0.85 as High, 0.50-0.70 as Medium, below 0.50 as Low.
|
||||
|
||||
---
|
||||
|
||||
*Report generated by QE Coverage Specialist (V3) -- Agentic QE v3*
|
||||
*Analysis scope: 439 source files across 4 codebases*
|
||||
*292 Rust files with inline test modules, 16 integration test files, 32 Python test files, 25 mobile test files, 3 firmware fuzz targets*
|
||||
@@ -1,98 +0,0 @@
|
||||
# RuView / WiFi-DensePose -- QE Executive Summary
|
||||
|
||||
**Date:** 2026-04-05
|
||||
**Analysis:** Full-spectrum Quality Engineering assessment (8 specialized agents)
|
||||
**Codebase:** ~305K lines across Rust (153K), Python (39K), C firmware (9K), TypeScript/JS (33K), Docs (71K)
|
||||
**Fleet ID:** fleet-02558e91
|
||||
|
||||
---
|
||||
|
||||
## Overall Quality Score: 55/100 (C+) -- QUALITY GATE FAILED
|
||||
|
||||
| Domain | Score | Verdict |
|
||||
|--------|-------|---------|
|
||||
| Code Quality & Complexity | 55-82/100 | CONDITIONAL PASS |
|
||||
| Security | 68/100 | CONDITIONAL PASS |
|
||||
| Performance | Borderline | AT RISK (37-54ms vs 50ms budget) |
|
||||
| Test Suite Quality | Mixed | 3,353 tests but heavy duplication |
|
||||
| Coverage | 77% file-level | FAIL (Python 30%, Firmware 19%) |
|
||||
| Quality Experience (QX) | 71/100 | CONDITIONAL PASS |
|
||||
| Product Factors (SFDIPOT) | TIME = CRITICAL | FAIL on time factor |
|
||||
|
||||
---
|
||||
|
||||
## P0 -- Fix Immediately (Security + CI)
|
||||
|
||||
| # | Issue | File(s) | Impact |
|
||||
|---|-------|---------|--------|
|
||||
| 1 | **Rate limiter bypass** -- trusts `X-Forwarded-For` without validation | `v1/src/middleware/rate_limit.py:200-206` | Any client can bypass rate limits via header spoofing |
|
||||
| 2 | **Exception details leaked** in HTTP responses regardless of environment | `v1/src/api/routers/pose.py:140`, `stream.py:297`, +5 others | Stack traces visible to attackers |
|
||||
| 3 | **WebSocket JWT in URL** -- tokens visible in logs, browser history, proxies | `v1/src/api/routers/stream.py:74`, `v1/src/middleware/auth.py:243` | Token exposure (CWE-598) |
|
||||
| 4 | **Rust tests not in CI** -- 2,618 tests in largest codebase never run in pipeline | No `cargo test` in any GitHub Actions workflow | Regressions ship undetected |
|
||||
| 5 | **WebSocket path mismatch** -- mobile app sends to wrong endpoint | `ui/mobile/src/services/ws.service.ts:104` vs `constants/websocket.ts:1` | Mobile WebSocket connections fail silently |
|
||||
|
||||
## P1 -- Fix This Sprint (Performance + Code Health)
|
||||
|
||||
| # | Issue | File(s) | Impact |
|
||||
|---|-------|---------|--------|
|
||||
| 6 | **God file: 4,846 lines, CC=121** -- sensing-server main.rs | `crates/wifi-densepose-sensing-server/src/main.rs` | Untestable, unmaintainable monolith |
|
||||
| 7 | **O(L*V) tomography voxel scan** per frame | `ruvsense/tomography.rs:345-383` | ~10ms wasted per frame; use DDA ray march for 5-10x speedup |
|
||||
| 8 | **Sequential neural inference** -- defeats GPU batching | `wifi-densepose-nn inference.rs:334-336` | 2-4x latency penalty |
|
||||
| 9 | **720 `.unwrap()` calls** in Rust production code | Across entire Rust workspace | Each is a potential panic in real-time/safety-critical paths |
|
||||
| 10 | **Python Doppler: 112KB alloc per frame** at 20Hz | `v1/src/core/csi_processor.py:412-414` | Converts deque -> list -> numpy every frame |
|
||||
|
||||
## P2 -- Fix This Quarter (Coverage + Safety)
|
||||
|
||||
| # | Issue | File(s) | Impact |
|
||||
|---|-------|---------|--------|
|
||||
| 11 | **11/12 Python modules untested** -- only CSI extraction has unit tests | `v1/src/services/`, `middleware/`, `database/`, `tasks/` | 12,280 LOC with zero unit tests |
|
||||
| 12 | **Firmware at 19% coverage** -- WASM runtime, OTA, swarm bridge untested | `firmware/esp32-csi-node/main/wasm_runtime.c` (867 LOC) | Security-critical code with no tests |
|
||||
| 13 | **MAT simulation fallback** -- disaster tool auto-falls back to simulated data | `ui/mobile/src/screens/MATScreen/index.tsx` | Risk of operators monitoring fake data during real incidents |
|
||||
| 14 | **Token blacklist never consulted** during auth | `v1/src/api/middleware/auth.py:246-252` | Revoked tokens remain valid |
|
||||
| 15 | **50ms frame budget never benchmarked** -- no latency CI gate | No benchmark harness exists | Real-time requirement is aspirational, not verified |
|
||||
|
||||
## P3 -- Technical Debt
|
||||
|
||||
| # | Issue | Impact |
|
||||
|---|-------|--------|
|
||||
| 16 | 340 `unsafe` blocks need formal safety audit | Potential UB in production |
|
||||
| 17 | 5 duplicate CSI extractor test files (~90 redundant tests) | Maintenance burden |
|
||||
| 18 | Performance tests mock inference with `asyncio.sleep()` | Tests measure scheduling, not performance |
|
||||
| 19 | CORS wildcard + credentials default | Browser security weakened |
|
||||
| 20 | ESP32 UDP CSI stream unencrypted | CSI data interceptable on LAN |
|
||||
|
||||
---
|
||||
|
||||
## Bright Spots
|
||||
|
||||
- **79 ADRs** -- exceptional architectural governance
|
||||
- **Witness bundle system** (ADR-028) -- deterministic SHA-256 proof verification
|
||||
- **Rust test depth** -- 2,618 tests with mathematical rigor (Doppler, phase, losses)
|
||||
- **Daily security scanning** in CI (Bandit, Semgrep, Safety)
|
||||
- **Mobile state management** -- clean Zustand stores with good test coverage
|
||||
- **Ed25519 WASM signature verification** on firmware
|
||||
- **Constant-time OTA PSK comparison** -- proper timing-safe crypto
|
||||
|
||||
---
|
||||
|
||||
## Reports Index
|
||||
|
||||
All detailed reports are in the [`docs/qe-reports/`](docs/qe-reports/) directory:
|
||||
|
||||
| Report | Lines | Description |
|
||||
|--------|-------|-------------|
|
||||
| [00-qe-queen-summary.md](00-qe-queen-summary.md) | 315 | Master synthesis, quality score, cross-cutting analysis |
|
||||
| [01-code-quality-complexity.md](01-code-quality-complexity.md) | 591 | Cyclomatic/cognitive complexity, code smells, top 20 hotspots |
|
||||
| [02-security-review.md](02-security-review.md) | 600 | 15 findings (0 CRITICAL, 3 HIGH, 7 MEDIUM), OWASP coverage |
|
||||
| [03-performance-analysis.md](03-performance-analysis.md) | 795 | 23 findings (4 CRITICAL), frame budget analysis, optimization roadmap |
|
||||
| [04-test-analysis.md](04-test-analysis.md) | 544 | 3,353 tests inventoried, duplication analysis, quality assessment |
|
||||
| [05-quality-experience.md](05-quality-experience.md) | 746 | API/CLI/Mobile/DX/Hardware UX assessment, 3 oracle problems |
|
||||
| [06-product-assessment-sfdipot.md](06-product-assessment-sfdipot.md) | 711 | SFDIPOT analysis, 57 test ideas, 14 exploratory session charters |
|
||||
| [07-coverage-gaps.md](07-coverage-gaps.md) | 514 | Coverage matrix, top 20 risk gaps, 8-week improvement roadmap |
|
||||
|
||||
**Total analysis:** 4,816 lines across 8 reports (265 KB)
|
||||
|
||||
---
|
||||
|
||||
*Generated by QE Swarm (8 agents, fleet-02558e91) on 2026-04-05*
|
||||
*Orchestrated by QE Queen Coordinator with shared learning/memory*
|
||||
@@ -1,996 +0,0 @@
|
||||
# GOAP Implementation Plan: ESP32-S3 + Pi Zero 2 W WiFi Pose Estimation
|
||||
|
||||
**Date:** 2026-04-02
|
||||
**Version:** 1.0
|
||||
**Status:** Proposed
|
||||
**Depends on:** ADR-029, ADR-068, SOTA survey (sota-wifi-sensing-2025.md)
|
||||
|
||||
---
|
||||
|
||||
## 1. Goal State Definition
|
||||
|
||||
### 1.1 Terminal Goal
|
||||
|
||||
A production-ready WiFi-based human pose estimation system where:
|
||||
- **ESP32-S3** nodes capture WiFi CSI at 100 Hz, perform temporal feature extraction, and transmit compressed features via UDP
|
||||
- **Raspberry Pi Zero 2 W** receives features from 1-4 ESP32 nodes, runs neural inference, and outputs 17-keypoint COCO poses at >= 10 Hz
|
||||
- **Single-person MPJPE** < 100mm in trained environments
|
||||
- **End-to-end latency** < 150ms (CSI capture to pose output)
|
||||
- **Total BOM cost** < $30 per sensing zone (1x Pi Zero + 2x ESP32)
|
||||
|
||||
### 1.2 World State Variables
|
||||
|
||||
```
|
||||
current_state:
|
||||
esp32_csi_capture: true # Already implemented
|
||||
multi_node_aggregation: true # ADR-018 UDP aggregator
|
||||
phase_alignment: true # ruvsense/phase_align.rs
|
||||
coherence_gating: true # ruvsense/coherence_gate.rs
|
||||
multistatic_fusion: true # ruvsense/multistatic.rs
|
||||
kalman_pose_tracking: true # ruvsense/pose_tracker.rs
|
||||
onnx_inference_engine: true # wifi-densepose-nn
|
||||
modality_translator: true # wifi-densepose-nn/translator.rs
|
||||
training_pipeline: true # wifi-densepose-train
|
||||
pi_zero_deployment: false # No Pi Zero target
|
||||
lightweight_model: false # No edge-optimized model
|
||||
temporal_conv_module: false # No TCN in inference path
|
||||
csi_compression: false # No ESP32-side compression
|
||||
int8_quantization: false # No quantization pipeline
|
||||
bone_constraint_loss: false # No skeleton physics in loss
|
||||
esp32_pi_protocol: false # No lightweight protocol
|
||||
edge_inference_engine: false # No ARM-optimized inference
|
||||
cross_env_adaptation: false # No domain adaptation
|
||||
multi_person_paf: false # No PAF-based multi-person
|
||||
3d_pose_lifting: false # No Z-axis estimation
|
||||
|
||||
goal_state:
|
||||
esp32_csi_capture: true
|
||||
multi_node_aggregation: true
|
||||
phase_alignment: true
|
||||
coherence_gating: true
|
||||
multistatic_fusion: true
|
||||
kalman_pose_tracking: true
|
||||
onnx_inference_engine: true
|
||||
modality_translator: true
|
||||
training_pipeline: true
|
||||
pi_zero_deployment: true # TARGET
|
||||
lightweight_model: true # TARGET
|
||||
temporal_conv_module: true # TARGET
|
||||
csi_compression: true # TARGET
|
||||
int8_quantization: true # TARGET
|
||||
bone_constraint_loss: true # TARGET
|
||||
esp32_pi_protocol: true # TARGET
|
||||
edge_inference_engine: true # TARGET
|
||||
cross_env_adaptation: true # TARGET (Phase 2)
|
||||
multi_person_paf: true # TARGET (Phase 2)
|
||||
3d_pose_lifting: true # TARGET (Phase 3)
|
||||
```
|
||||
|
||||
## 2. Action Definitions
|
||||
|
||||
Each action has preconditions, effects, estimated cost (developer-days), and priority.
|
||||
|
||||
### Action 1: Define ESP32-Pi Communication Protocol (ADR-069)
|
||||
|
||||
```
|
||||
name: define_esp32_pi_protocol
|
||||
cost: 3 days
|
||||
priority: CRITICAL (blocks all Pi Zero work)
|
||||
preconditions: [esp32_csi_capture]
|
||||
effects: [esp32_pi_protocol := true]
|
||||
```
|
||||
|
||||
**Description:** Design a lightweight binary protocol for ESP32 -> Pi Zero communication over UDP (WiFi) or UART (wired fallback).
|
||||
|
||||
**Protocol specification:**
|
||||
|
||||
```
|
||||
Frame Header (8 bytes):
|
||||
[0:1] magic: 0xCF01 (CSI Frame v1)
|
||||
[2] node_id: u8 (0-255, identifies ESP32 node)
|
||||
[3] frame_type: u8 (0=raw_csi, 1=compressed_features, 2=heartbeat)
|
||||
[4:5] sequence: u16 (monotonic frame counter, wraps at 65535)
|
||||
[6:7] payload_len: u16 (bytes following header)
|
||||
|
||||
Raw CSI Payload (frame_type=0):
|
||||
[0:3] timestamp_us: u32 (microseconds since boot, wraps at ~71 minutes)
|
||||
[4] channel: u8 (WiFi channel 1-13)
|
||||
[5] bandwidth: u8 (0=20MHz, 1=40MHz)
|
||||
[6] rssi: i8 (dBm)
|
||||
[7] noise_floor: i8 (dBm)
|
||||
[8:9] num_sc: u16 (number of subcarriers, typically 52 or 114)
|
||||
[10..] csi_data: [i16; num_sc * 2] (interleaved I/Q, little-endian)
|
||||
|
||||
Compressed Feature Payload (frame_type=1):
|
||||
[0:3] timestamp_us: u32
|
||||
[4] compression: u8 (0=none, 1=pca_16, 2=pca_32, 3=autoencoder)
|
||||
[5] num_features: u8 (number of feature dimensions)
|
||||
[6..] features: [f16; num_features] (half-precision floats)
|
||||
|
||||
Heartbeat Payload (frame_type=2):
|
||||
[0:3] uptime_s: u32
|
||||
[4:7] frames_sent: u32
|
||||
[8:9] free_heap: u16 (KB)
|
||||
[10] wifi_rssi: i8 (connection to AP)
|
||||
[11] battery_pct: u8 (0-100, 0xFF if wired)
|
||||
```
|
||||
|
||||
**Implementation locations:**
|
||||
- ESP32 firmware: `firmware/esp32-csi-node/main/protocol_v2.h`
|
||||
- Rust parser: `wifi-densepose-hardware/src/protocol_v2.rs`
|
||||
|
||||
**Design rationale:**
|
||||
- Fixed 8-byte header with magic number for frame synchronization
|
||||
- Half-precision (f16) for compressed features saves 50% bandwidth vs f32
|
||||
- Heartbeat enables Pi Zero to detect node failures and rebalance
|
||||
- Raw CSI mode for debugging; compressed mode for production
|
||||
|
||||
### Action 2: Implement Lightweight Model Architecture
|
||||
|
||||
```
|
||||
name: implement_lightweight_model
|
||||
cost: 10 days
|
||||
priority: CRITICAL (core inference capability)
|
||||
preconditions: [training_pipeline, onnx_inference_engine]
|
||||
effects: [lightweight_model := true, temporal_conv_module := true]
|
||||
```
|
||||
|
||||
**Architecture: WiFlowPose (hybrid WiFlow + MultiFormer)**
|
||||
|
||||
Based on SOTA analysis, we define a custom architecture combining the best elements:
|
||||
|
||||
```
|
||||
Input: CSI amplitude tensor [B, T, S]
|
||||
B = batch size
|
||||
T = temporal window (20 frames at 20 Hz = 1 second context)
|
||||
S = subcarriers (52 for ESP32-S3 20MHz, 114 for 40MHz)
|
||||
|
||||
Stage 1: Temporal Encoder (runs on ESP32 optionally, or Pi Zero)
|
||||
TCN with 4 layers, dilation [1, 2, 4, 8]
|
||||
Input: [B, T, S] = [B, 20, 52]
|
||||
Output: [B, T', C_t] = [B, 20, 64] (temporal features)
|
||||
|
||||
Stage 2: Spatial Encoder (runs on Pi Zero)
|
||||
Asymmetric convolution blocks (1xk kernels on subcarrier dimension)
|
||||
4 residual blocks: 64 -> 128 -> 128 -> 64 channels
|
||||
Subcarrier compression: 52 -> 26 -> 13 -> 7
|
||||
Output: [B, 64, 7]
|
||||
|
||||
Stage 3: Keypoint Decoder (runs on Pi Zero)
|
||||
Axial self-attention (2-stage, 4 heads)
|
||||
Reshape to [B, 17, 64] (17 keypoints x 64 features)
|
||||
Linear projection: 64 -> 2 (x, y coordinates)
|
||||
Output: [B, 17, 2] (17 COCO keypoints, normalized 0-1)
|
||||
|
||||
Optional Stage 4: Multi-person (Phase 2)
|
||||
PAF branch: predict 19 limb affinity fields
|
||||
Hungarian assignment for person grouping
|
||||
```
|
||||
|
||||
**Estimated model size:**
|
||||
- Temporal encoder: ~0.5M params
|
||||
- Spatial encoder: ~1.2M params
|
||||
- Keypoint decoder: ~0.8M params
|
||||
- Total: ~2.5M params
|
||||
- INT8 size: ~2.5 MB
|
||||
- FP16 size: ~5 MB
|
||||
- Estimated Pi Zero 2 W inference: 30-60ms per frame
|
||||
|
||||
**Rust implementation location:** New module in `wifi-densepose-nn/src/wiflow_pose.rs`
|
||||
|
||||
```rust
|
||||
/// WiFlowPose: Lightweight WiFi CSI to pose estimation model
|
||||
///
|
||||
/// Hybrid architecture combining WiFlow's TCN temporal encoder
|
||||
/// with MultiFormer's dual-token spatial processing and
|
||||
/// axial self-attention for keypoint decoding.
|
||||
pub struct WiFlowPoseConfig {
|
||||
/// Number of input subcarriers (52 for ESP32 20MHz, 114 for 40MHz)
|
||||
pub num_subcarriers: usize,
|
||||
/// Temporal window size in frames (default: 20)
|
||||
pub temporal_window: usize,
|
||||
/// TCN dilation factors (default: [1, 2, 4, 8])
|
||||
pub tcn_dilations: Vec<usize>,
|
||||
/// Number of output keypoints (default: 17, COCO format)
|
||||
pub num_keypoints: usize,
|
||||
/// Hidden dimension for spatial encoder (default: 64)
|
||||
pub hidden_dim: usize,
|
||||
/// Number of attention heads in axial attention (default: 4)
|
||||
pub num_attention_heads: usize,
|
||||
/// Enable multi-person PAF branch (default: false)
|
||||
pub multi_person: bool,
|
||||
}
|
||||
|
||||
impl Default for WiFlowPoseConfig {
|
||||
fn default() -> Self {
|
||||
Self {
|
||||
num_subcarriers: 52,
|
||||
temporal_window: 20,
|
||||
tcn_dilations: vec![1, 2, 4, 8],
|
||||
num_keypoints: 17,
|
||||
hidden_dim: 64,
|
||||
num_attention_heads: 4,
|
||||
multi_person: false,
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Action 3: Implement Bone Constraint Loss
|
||||
|
||||
```
|
||||
name: implement_bone_constraint_loss
|
||||
cost: 2 days
|
||||
priority: HIGH
|
||||
preconditions: [training_pipeline, lightweight_model]
|
||||
effects: [bone_constraint_loss := true]
|
||||
```
|
||||
|
||||
**Loss function following WiFlow:**
|
||||
|
||||
```
|
||||
L_total = L_keypoint + lambda_bone * L_bone + lambda_physics * L_physics
|
||||
|
||||
L_keypoint = SmoothL1(pred, gt, beta=0.1)
|
||||
|
||||
L_bone = (1/|B|) * sum_{(i,j) in bones} | ||pred_i - pred_j|| - bone_length_{ij} |
|
||||
|
||||
L_physics = (1/N) * sum_t max(0, ||pred_t - pred_{t-1}|| - v_max * dt)
|
||||
```
|
||||
|
||||
Where:
|
||||
- `bones` = 14 COCO bone connections (e.g., left_shoulder-left_elbow)
|
||||
- `bone_length_{ij}` = average human bone length ratios (normalized to torso length)
|
||||
- `v_max` = maximum physiologically plausible keypoint velocity (2 m/s for walking, 10 m/s for fast gestures)
|
||||
- `lambda_bone = 0.2`, `lambda_physics = 0.1`
|
||||
|
||||
**Bone length ratios (normalized to torso = shoulder_center to hip_center = 1.0):**
|
||||
|
||||
| Bone | Ratio |
|
||||
|------|-------|
|
||||
| shoulder-elbow | 0.55 |
|
||||
| elbow-wrist | 0.50 |
|
||||
| hip-knee | 0.85 |
|
||||
| knee-ankle | 0.80 |
|
||||
| shoulder-hip | 1.00 |
|
||||
| neck-nose | 0.30 |
|
||||
| nose-eye | 0.08 |
|
||||
| eye-ear | 0.12 |
|
||||
|
||||
**Implementation location:** `wifi-densepose-train/src/losses.rs` (add `BoneConstraintLoss`)
|
||||
|
||||
### Action 4: Implement INT8 Quantization Pipeline
|
||||
|
||||
```
|
||||
name: implement_int8_quantization
|
||||
cost: 5 days
|
||||
priority: HIGH
|
||||
preconditions: [lightweight_model, training_pipeline]
|
||||
effects: [int8_quantization := true]
|
||||
```
|
||||
|
||||
**Approach: Post-Training Quantization (PTQ) with calibration**
|
||||
|
||||
1. Train model in FP32 using standard pipeline
|
||||
2. Export to ONNX format
|
||||
3. Run ONNX Runtime quantization tool with calibration dataset:
|
||||
- Collect 1000 representative CSI frames across multiple environments
|
||||
- Run calibration to determine per-layer quantization ranges
|
||||
- Apply symmetric INT8 quantization for weights, asymmetric for activations
|
||||
4. Validate quantized model accuracy (target: <2% PCK@20 degradation)
|
||||
|
||||
**Quantization-aware considerations:**
|
||||
- TCN layers: quantize per-channel (dilated convolutions are sensitive to quantization)
|
||||
- Attention layers: keep attention logits in FP16 (softmax is numerically sensitive)
|
||||
- Output layer: keep in FP32 (final coordinate regression needs precision)
|
||||
|
||||
**Rust implementation:**
|
||||
```rust
|
||||
// In wifi-densepose-nn/src/quantize.rs
|
||||
pub struct QuantizationConfig {
|
||||
/// Quantization method
|
||||
pub method: QuantMethod, // PTQ, QAT, Dynamic
|
||||
/// Per-layer precision overrides
|
||||
pub layer_overrides: HashMap<String, Precision>,
|
||||
/// Calibration dataset path
|
||||
pub calibration_data: PathBuf,
|
||||
/// Number of calibration samples
|
||||
pub num_calibration_samples: usize,
|
||||
/// Target accuracy degradation threshold
|
||||
pub max_accuracy_loss: f32,
|
||||
}
|
||||
|
||||
pub enum Precision {
|
||||
INT8,
|
||||
FP16,
|
||||
FP32,
|
||||
}
|
||||
```
|
||||
|
||||
**ONNX quantization command (for build pipeline):**
|
||||
```bash
|
||||
python -m onnxruntime.quantization.quantize \
|
||||
--input model_fp32.onnx \
|
||||
--output model_int8.onnx \
|
||||
--calibrate \
|
||||
--calibration_data_reader CsiCalibrationReader \
|
||||
--quant_format QDQ \
|
||||
--activation_type QUInt8 \
|
||||
--weight_type QInt8
|
||||
```
|
||||
|
||||
### Action 5: Build Edge Inference Engine for Pi Zero
|
||||
|
||||
```
|
||||
name: build_edge_inference_engine
|
||||
cost: 8 days
|
||||
priority: CRITICAL
|
||||
preconditions: [lightweight_model, int8_quantization, esp32_pi_protocol]
|
||||
effects: [edge_inference_engine := true, pi_zero_deployment := true]
|
||||
```
|
||||
|
||||
**Architecture: Streaming inference with ring buffer**
|
||||
|
||||
```
|
||||
UDP/UART
|
||||
ESP32-S3 ---------> Pi Zero 2 W
|
||||
|
|
||||
v
|
||||
+-- RingBuffer<CsiFrame> --+
|
||||
| (capacity: 64 frames) |
|
||||
+------ | | -------------+
|
||||
v v
|
||||
+-- TemporalWindow --------+
|
||||
| (20 frames, sliding) |
|
||||
+------ | ----------------+
|
||||
v
|
||||
+-- WiFlowPose ONNX ------+
|
||||
| (INT8, XNNPACK accel) |
|
||||
+------ | ----------------+
|
||||
v
|
||||
+-- PoseTracker -----------+
|
||||
| (Kalman + skeleton) |
|
||||
+------ | ----------------+
|
||||
v
|
||||
PoseEstimate output
|
||||
(17 keypoints + confidence)
|
||||
```
|
||||
|
||||
**New Rust binary:** `wifi-densepose-cli/src/bin/edge_infer.rs`
|
||||
|
||||
```rust
|
||||
/// Edge inference daemon for Raspberry Pi Zero 2 W
|
||||
///
|
||||
/// Receives CSI frames from ESP32 nodes via UDP, maintains a temporal
|
||||
/// sliding window, runs INT8 ONNX inference, and outputs pose estimates.
|
||||
///
|
||||
/// Usage:
|
||||
/// wifi-densepose edge-infer \
|
||||
/// --model model_int8.onnx \
|
||||
/// --listen 0.0.0.0:5555 \
|
||||
/// --output-port 5556 \
|
||||
/// --window-size 20 \
|
||||
/// --max-nodes 4
|
||||
|
||||
struct EdgeInferConfig {
|
||||
/// Path to INT8 ONNX model
|
||||
model_path: PathBuf,
|
||||
/// UDP listen address for CSI frames
|
||||
listen_addr: SocketAddr,
|
||||
/// UDP output address for pose results
|
||||
output_addr: Option<SocketAddr>,
|
||||
/// Temporal window size
|
||||
window_size: usize,
|
||||
/// Maximum ESP32 nodes to accept
|
||||
max_nodes: usize,
|
||||
/// Inference thread count (1-4 on Pi Zero 2 W)
|
||||
num_threads: usize,
|
||||
/// Enable XNNPACK acceleration
|
||||
use_xnnpack: bool,
|
||||
}
|
||||
```
|
||||
|
||||
**Cross-compilation for Pi Zero 2 W:**
|
||||
|
||||
```bash
|
||||
# Install cross-compilation toolchain
|
||||
rustup target add aarch64-unknown-linux-gnu
|
||||
sudo apt install gcc-aarch64-linux-gnu
|
||||
|
||||
# Build for Pi Zero 2 W (64-bit Raspberry Pi OS)
|
||||
cross build --target aarch64-unknown-linux-gnu \
|
||||
--release \
|
||||
-p wifi-densepose-cli \
|
||||
--features edge-inference \
|
||||
--no-default-features
|
||||
|
||||
# Or for 32-bit Raspberry Pi OS:
|
||||
# rustup target add armv7-unknown-linux-gnueabihf
|
||||
# cross build --target armv7-unknown-linux-gnueabihf ...
|
||||
```
|
||||
|
||||
**ONNX Runtime linking for ARM:**
|
||||
- Use `ort` crate with `download-binaries` feature for automatic aarch64 binary download
|
||||
- Alternative: build OnnxStream from source for minimal binary size (~2 MB vs ~30 MB for full ONNX Runtime)
|
||||
|
||||
### Action 6: Implement CSI Compression on ESP32
|
||||
|
||||
```
|
||||
name: implement_csi_compression
|
||||
cost: 5 days
|
||||
priority: MEDIUM
|
||||
preconditions: [esp32_csi_capture, esp32_pi_protocol]
|
||||
effects: [csi_compression := true]
|
||||
```
|
||||
|
||||
**Three compression tiers:**
|
||||
|
||||
**Tier 0: No compression (raw CSI)**
|
||||
- Payload: 52 subcarriers x 2 (I/Q) x 2 bytes = 208 bytes per frame
|
||||
- Use case: debugging, maximum fidelity
|
||||
|
||||
**Tier 1: PCA-16 (run on ESP32)**
|
||||
- Pre-computed PCA projection matrix (52 -> 16 dimensions)
|
||||
- Stored in NVS flash during provisioning
|
||||
- Payload: 16 features x 2 bytes (f16) = 32 bytes per frame
|
||||
- Compression: 6.5x
|
||||
- Compute: ~0.1ms on ESP32-S3 (matrix-vector multiply, SIMD)
|
||||
|
||||
**Tier 2: PCA-32 (higher fidelity)**
|
||||
- 52 -> 32 dimensions
|
||||
- Payload: 32 x 2 = 64 bytes
|
||||
- Compression: 3.25x
|
||||
|
||||
**Tier 3: Learned autoencoder (future)**
|
||||
- ESP32-S3 has enough compute for a small encoder (~10K params)
|
||||
- Requires quantized encoder weights in flash
|
||||
- Most bandwidth-efficient but requires training
|
||||
|
||||
**PCA computation (offline, during provisioning):**
|
||||
|
||||
```rust
|
||||
// wifi-densepose-train/src/compression.rs
|
||||
|
||||
/// Compute PCA projection matrix from calibration CSI data
|
||||
pub fn compute_pca_projection(
|
||||
calibration_data: &[CsiFrame],
|
||||
target_dims: usize,
|
||||
) -> PcaProjection {
|
||||
// 1. Stack all CSI amplitude vectors into matrix [N, S]
|
||||
// 2. Center (subtract mean)
|
||||
// 3. Compute covariance matrix [S, S]
|
||||
// 4. Eigendecomposition, take top `target_dims` eigenvectors
|
||||
// 5. Return projection matrix [S, target_dims] and mean vector [S]
|
||||
// ...
|
||||
}
|
||||
|
||||
pub struct PcaProjection {
|
||||
/// Projection matrix [num_subcarriers, target_dims]
|
||||
pub matrix: Vec<f32>,
|
||||
/// Mean vector for centering [num_subcarriers]
|
||||
pub mean: Vec<f32>,
|
||||
/// Number of input subcarriers
|
||||
pub input_dims: usize,
|
||||
/// Number of output features
|
||||
pub output_dims: usize,
|
||||
}
|
||||
```
|
||||
|
||||
**ESP32 firmware integration:**
|
||||
- Store PCA matrix in NVS partition (32x52x4 = 6.5 KB for PCA-32)
|
||||
- Apply projection in CSI callback before UDP transmission
|
||||
- Selectable via provisioning command
|
||||
|
||||
### Action 7: Implement Cross-Environment Adaptation
|
||||
|
||||
```
|
||||
name: implement_cross_env_adaptation
|
||||
cost: 8 days
|
||||
priority: MEDIUM (Phase 2)
|
||||
preconditions: [lightweight_model, training_pipeline, pi_zero_deployment]
|
||||
effects: [cross_env_adaptation := true]
|
||||
```
|
||||
|
||||
**Approach: Rapid environment calibration with few-shot adaptation**
|
||||
|
||||
Inspired by Arena Physica's template-based design space and MERIDIAN (ADR-027):
|
||||
|
||||
1. **Environment fingerprinting (on Pi Zero, at deployment time):**
|
||||
- Collect 60 seconds of "empty room" CSI
|
||||
- Compute room signature: mean amplitude profile, delay spread, K-factor
|
||||
- Match to nearest room template (corridor, office, bedroom, etc.)
|
||||
- Load template-specific model weights
|
||||
|
||||
2. **Few-shot fine-tuning (optional, on workstation):**
|
||||
- Collect 5 minutes of calibration data with known poses
|
||||
- Fine-tune last 2 layers of the model (~50K params)
|
||||
- Transfer updated model back to Pi Zero
|
||||
|
||||
3. **Online adaptation (continuous, on Pi Zero):**
|
||||
- Track CSI statistics over time (sliding window mean/variance)
|
||||
- Detect distribution shift (KL divergence exceeds threshold)
|
||||
- Apply batch normalization statistics update (no gradient computation needed)
|
||||
|
||||
**Implementation location:** `wifi-densepose-train/src/rapid_adapt.rs` (extend existing module)
|
||||
|
||||
### Action 8: Implement Multi-Person PAF Decoding
|
||||
|
||||
```
|
||||
name: implement_multi_person_paf
|
||||
cost: 6 days
|
||||
priority: LOW (Phase 2)
|
||||
preconditions: [lightweight_model, bone_constraint_loss]
|
||||
effects: [multi_person_paf := true]
|
||||
```
|
||||
|
||||
**Architecture (following MultiFormer):**
|
||||
|
||||
Add a PAF branch to the WiFlowPose model:
|
||||
|
||||
```
|
||||
Stage 3 features [B, 64, 7]
|
||||
|
|
||||
+--> Keypoint head: [B, 17, 2] (single-person keypoints)
|
||||
|
|
||||
+--> PAF head: [B, 38, H, W] (19 limb affinity fields)
|
||||
|
|
||||
+--> Confidence head: [B, 19, H, W] (part confidence maps)
|
||||
```
|
||||
|
||||
**Multi-person assignment on Pi Zero:**
|
||||
1. Extract candidate keypoints from confidence maps via NMS
|
||||
2. Compute PAF integral scores between candidate pairs
|
||||
3. Solve bipartite matching with Hungarian algorithm
|
||||
4. Group keypoints into person instances
|
||||
|
||||
**Estimated additional cost:** ~1M parameters, ~10ms additional inference time
|
||||
|
||||
### Action 9: Implement 3D Pose Lifting
|
||||
|
||||
```
|
||||
name: implement_3d_pose_lifting
|
||||
cost: 5 days
|
||||
priority: LOW (Phase 3)
|
||||
preconditions: [lightweight_model, multi_person_paf, multistatic_fusion]
|
||||
effects: [3d_pose_lifting := true]
|
||||
```
|
||||
|
||||
**Approach: Multi-view triangulation + learned depth prior**
|
||||
|
||||
With 2+ ESP32 nodes at known positions, compute 3D pose via:
|
||||
|
||||
1. Each node pair provides a different viewing angle of the WiFi field
|
||||
2. 2D pose from each viewpoint is estimated independently
|
||||
3. Epipolar geometry constrains 3D position from 2D observations
|
||||
4. Learned depth prior resolves ambiguities (front/back confusion)
|
||||
|
||||
This leverages the existing `viewpoint/geometry.rs` module in wifi-densepose-ruvector which already computes GeometricDiversityIndex and Fisher Information for multi-node configurations.
|
||||
|
||||
## 3. Hardware Architecture
|
||||
|
||||
### 3.1 System Topology
|
||||
|
||||
```
|
||||
WiFi AP (existing home router)
|
||||
/ | \
|
||||
/ | \
|
||||
ESP32-S3 #1 ESP32-S3 #2 ESP32-S3 #3
|
||||
(CSI node) (CSI node) (CSI node, optional)
|
||||
| | |
|
||||
+------+------+------+-------+
|
||||
| UDP (WiFi) |
|
||||
v v
|
||||
Raspberry Pi Zero 2 W
|
||||
(edge inference node)
|
||||
|
|
||||
v
|
||||
Pose output (UDP/MQTT/WebSocket)
|
||||
to display / home automation / API
|
||||
```
|
||||
|
||||
### 3.2 Data Flow Timing
|
||||
|
||||
```
|
||||
T=0ms ESP32 #1 captures CSI frame (channel 1)
|
||||
T=2ms ESP32 #1 applies PCA compression (0.1ms compute)
|
||||
T=3ms ESP32 #1 sends UDP packet to Pi Zero (64 bytes)
|
||||
T=5ms ESP32 #2 captures CSI frame (channel 6, TDM slot)
|
||||
T=7ms ESP32 #2 sends UDP packet to Pi Zero
|
||||
T=10ms Pi Zero receives both frames, adds to ring buffer
|
||||
T=10ms Pi Zero checks temporal window (20 frames accumulated?)
|
||||
If yes: run inference
|
||||
T=15ms Temporal encoder processes 20-frame window (5ms)
|
||||
T=35ms Spatial encoder + attention (20ms)
|
||||
T=45ms Keypoint decoder (10ms)
|
||||
T=48ms Kalman filter update + skeleton constraints (3ms)
|
||||
T=50ms Pose estimate emitted (17 keypoints + confidence)
|
||||
```
|
||||
|
||||
**Total latency: ~50ms** (well under 150ms target)
|
||||
**Throughput: 20 Hz** (matching TDMA cycle)
|
||||
|
||||
### 3.3 Hardware Bill of Materials
|
||||
|
||||
| Component | Unit Cost | Quantity | Total |
|
||||
|-----------|----------|----------|-------|
|
||||
| ESP32-S3 DevKit (8MB) | $9 | 2 | $18 |
|
||||
| Raspberry Pi Zero 2 W | $15 | 1 | $15 |
|
||||
| MicroSD card (16GB) | $5 | 1 | $5 |
|
||||
| USB-C power supply | $5 | 1 | $5 |
|
||||
| **Total** | | | **$43** |
|
||||
|
||||
With ESP32-S3 SuperMini ($6 each), total drops to **$37**.
|
||||
|
||||
For minimum viable setup (1 ESP32 + 1 Pi Zero): **$24**.
|
||||
|
||||
### 3.4 Pi Zero 2 W Specifications
|
||||
|
||||
| Parameter | Value |
|
||||
|-----------|-------|
|
||||
| SoC | BCM2710A1 (quad-core Cortex-A53 @ 1 GHz) |
|
||||
| RAM | 512 MB LPDDR2 |
|
||||
| WiFi | 802.11b/g/n (2.4 GHz only) |
|
||||
| Bluetooth | BLE 4.2 |
|
||||
| GPIO | 40-pin header (UART, SPI, I2C) |
|
||||
| Power | 5V/2A USB micro-B |
|
||||
| OS | Raspberry Pi OS Lite (64-bit, headless) |
|
||||
|
||||
**Memory budget for inference:**
|
||||
|
||||
| Component | Memory |
|
||||
|-----------|--------|
|
||||
| OS + services | ~100 MB |
|
||||
| WiFlowPose INT8 model | ~3 MB |
|
||||
| ONNX Runtime / OnnxStream | ~10-30 MB |
|
||||
| Ring buffer (64 frames x 4 nodes) | ~1 MB |
|
||||
| Inference workspace | ~20 MB |
|
||||
| **Total** | ~134-164 MB |
|
||||
| **Available** | ~348-378 MB headroom |
|
||||
|
||||
Comfortable fit within 512 MB RAM.
|
||||
|
||||
## 4. Rust Crate Modifications
|
||||
|
||||
### 4.1 Modified Crates
|
||||
|
||||
#### wifi-densepose-hardware
|
||||
|
||||
**New files:**
|
||||
- `src/protocol_v2.rs` -- Lightweight ESP32-Pi binary protocol parser/serializer
|
||||
- `src/pi_zero.rs` -- Pi Zero UDP receiver with ring buffer management
|
||||
|
||||
**Modified files:**
|
||||
- `src/lib.rs` -- Add `pub mod protocol_v2; pub mod pi_zero;`
|
||||
- `src/aggregator/mod.rs` -- Add support for protocol_v2 frame format
|
||||
|
||||
#### wifi-densepose-nn
|
||||
|
||||
**New files:**
|
||||
- `src/wiflow_pose.rs` -- WiFlowPose model definition (TCN + asymmetric conv + axial attention)
|
||||
- `src/edge_engine.rs` -- Edge-optimized inference engine (streaming, ARM NEON)
|
||||
- `src/quantize.rs` -- INT8 quantization configuration and validation
|
||||
|
||||
**Modified files:**
|
||||
- `src/lib.rs` -- Add new module exports
|
||||
- `src/onnx.rs` -- Add XNNPACK execution provider option, INT8 model loading
|
||||
- `src/translator.rs` -- Add WiFlowPose-compatible input format
|
||||
|
||||
#### wifi-densepose-train
|
||||
|
||||
**New files:**
|
||||
- `src/wiflow_pose_trainer.rs` -- Training loop for WiFlowPose architecture
|
||||
- `src/compression.rs` -- PCA computation for ESP32 CSI compression
|
||||
- `src/bone_loss.rs` -- Bone constraint and physics consistency losses
|
||||
|
||||
**Modified files:**
|
||||
- `src/losses.rs` -- Add `BoneConstraintLoss`, `PhysicsConsistencyLoss`
|
||||
- `src/config.rs` -- Add WiFlowPose training configuration options
|
||||
- `src/dataset.rs` -- Add ESP32-S3 CSI format support (52/114 subcarriers)
|
||||
- `src/rapid_adapt.rs` -- Add few-shot environment calibration
|
||||
|
||||
#### wifi-densepose-signal
|
||||
|
||||
**New files:**
|
||||
- `src/ruvsense/temporal_encoder.rs` -- TCN temporal feature extraction (shared code for ESP32 and Pi)
|
||||
|
||||
**Modified files:**
|
||||
- `src/ruvsense/mod.rs` -- Add `pub mod temporal_encoder;`
|
||||
|
||||
#### wifi-densepose-cli
|
||||
|
||||
**New files:**
|
||||
- `src/bin/edge_infer.rs` -- Pi Zero edge inference daemon
|
||||
- `src/bin/calibrate.rs` -- Environment calibration tool (PCA computation, room fingerprinting)
|
||||
|
||||
#### wifi-densepose-core
|
||||
|
||||
**Modified files:**
|
||||
- `src/types.rs` -- Add `CompressedCsiFrame`, `EdgePoseEstimate` types
|
||||
|
||||
### 4.2 New Feature Flags
|
||||
|
||||
```toml
|
||||
# wifi-densepose-nn/Cargo.toml
|
||||
[features]
|
||||
default = ["onnx"]
|
||||
onnx = ["ort"]
|
||||
edge-inference = ["onnx", "xnnpack"] # NEW: ARM NEON + XNNPACK
|
||||
candle = ["candle-core", "candle-nn"]
|
||||
tch-backend = ["tch"]
|
||||
|
||||
# wifi-densepose-cli/Cargo.toml
|
||||
[features]
|
||||
default = ["full"]
|
||||
full = ["wifi-densepose-nn/onnx", "wifi-densepose-train/tch-backend"]
|
||||
edge-inference = ["wifi-densepose-nn/edge-inference"] # NEW: minimal binary for Pi
|
||||
```
|
||||
|
||||
### 4.3 Cross-Compilation Configuration
|
||||
|
||||
```toml
|
||||
# .cargo/config.toml (add section)
|
||||
[target.aarch64-unknown-linux-gnu]
|
||||
linker = "aarch64-linux-gnu-gcc"
|
||||
rustflags = ["-C", "target-cpu=cortex-a53", "-C", "target-feature=+neon"]
|
||||
```
|
||||
|
||||
## 5. ESP32 Firmware Modifications
|
||||
|
||||
### 5.1 New Files
|
||||
|
||||
- `firmware/esp32-csi-node/main/protocol_v2.h` -- Protocol v2 frame packing
|
||||
- `firmware/esp32-csi-node/main/pca_compress.h` -- PCA compression for CSI
|
||||
- `firmware/esp32-csi-node/main/pca_compress.c` -- PCA implementation with ESP32 SIMD
|
||||
- `firmware/esp32-csi-node/main/pi_zero_mode.c` -- Pi Zero communication mode (lighter than full server mode)
|
||||
|
||||
### 5.2 Modified Files
|
||||
|
||||
- `firmware/esp32-csi-node/main/csi_handler.c` -- Add compression step in CSI callback
|
||||
- `firmware/esp32-csi-node/main/nvs_config.c` -- Store PCA matrix in NVS
|
||||
- `firmware/esp32-csi-node/main/Kconfig.projbuild` -- Add CONFIG_PI_ZERO_MODE, CONFIG_CSI_COMPRESSION options
|
||||
|
||||
### 5.3 Provisioning Updates
|
||||
|
||||
```bash
|
||||
# Provision for Pi Zero mode with PCA-16 compression
|
||||
python firmware/esp32-csi-node/provision.py \
|
||||
--port COM7 \
|
||||
--ssid "MyWiFi" \
|
||||
--password "secret" \
|
||||
--target-ip 192.168.1.50 \ # Pi Zero IP
|
||||
--target-port 5555 \
|
||||
--compression pca-16 \
|
||||
--pca-matrix pca_matrix_16.bin
|
||||
```
|
||||
|
||||
## 6. Training Pipeline
|
||||
|
||||
### 6.1 Training Workflow
|
||||
|
||||
```
|
||||
Phase 1: Pre-train on public datasets (GPU workstation)
|
||||
Dataset: MM-Fi + Wi-Pose (Intel 5300 format, 30 subcarriers)
|
||||
Model: WiFlowPose with 30 subcarriers
|
||||
Loss: L_keypoint + 0.2 * L_bone + 0.1 * L_physics
|
||||
Duration: ~20 hours on single A100
|
||||
|
||||
Phase 2: Domain adaptation for ESP32 CSI (GPU workstation)
|
||||
Dataset: Self-collected ESP32-S3 data (52 subcarriers)
|
||||
Method: Fine-tune all layers with lower learning rate (1e-4)
|
||||
Subcarrier interpolation: 30 -> 52 using existing interpolate_subcarriers()
|
||||
Duration: ~4 hours
|
||||
|
||||
Phase 3: Quantization (CPU workstation)
|
||||
Method: Post-training quantization with 1000 calibration samples
|
||||
Format: ONNX INT8 (QDQ format)
|
||||
Validation: PCK@20 degradation < 2%
|
||||
|
||||
Phase 4: Environment calibration (on Pi Zero)
|
||||
Method: 60-second empty-room CSI collection
|
||||
Output: Room fingerprint + PCA matrix
|
||||
Duration: ~2 minutes total
|
||||
```
|
||||
|
||||
### 6.2 Dataset Collection Protocol
|
||||
|
||||
For self-collected ESP32 training data:
|
||||
|
||||
1. **Setup:** 2 ESP32-S3 nodes at opposite corners of 4x4m room, Pi Zero receiving
|
||||
2. **Ground truth:** Smartphone camera running MediaPipe Pose (30 FPS), synchronized via NTP
|
||||
3. **Activities:** Standing, walking, sitting, waving, falling, idle (2 minutes each)
|
||||
4. **Subjects:** 5+ volunteers with varying body types
|
||||
5. **Environments:** 3+ rooms (bedroom, office, corridor) for generalization
|
||||
6. **Total target:** ~100K synchronized CSI-pose frame pairs
|
||||
|
||||
**Synchronization approach:**
|
||||
- ESP32 and Pi Zero synchronized via NTP (< 10ms accuracy on LAN)
|
||||
- Camera frames timestamped with system clock
|
||||
- Offline alignment via cross-correlation of movement signals
|
||||
|
||||
### 6.3 Transfer Learning Strategy
|
||||
|
||||
Following DensePose-WiFi's proven approach:
|
||||
|
||||
```
|
||||
L_total = lambda_pose * L_pose
|
||||
+ lambda_bone * L_bone
|
||||
+ lambda_transfer * L_transfer
|
||||
+ lambda_physics * L_physics
|
||||
|
||||
L_transfer = MSE(features_student, features_teacher)
|
||||
```
|
||||
|
||||
Where `features_teacher` come from a pre-trained image-based pose model (HRNet or ViTPose) and `features_student` come from the WiFi CSI model at corresponding intermediate layers.
|
||||
|
||||
**Lambda schedule:**
|
||||
- Epochs 1-20: lambda_transfer = 0.5 (heavy transfer guidance)
|
||||
- Epochs 20-50: lambda_transfer = 0.2 (moderate guidance)
|
||||
- Epochs 50-100: lambda_transfer = 0.05 (fine-tuning freedom)
|
||||
|
||||
## 7. Timeline and Milestones
|
||||
|
||||
### Phase 1: Foundation (Weeks 1-4)
|
||||
|
||||
| Week | Actions | Deliverable |
|
||||
|------|---------|-------------|
|
||||
| 1 | Action 1 (protocol), ADR-069 draft | Protocol spec + parser tests |
|
||||
| 2 | Action 2 (model architecture, begin) | WiFlowPose model definition in Rust |
|
||||
| 2 | Action 3 (bone loss) | Loss functions implemented and tested |
|
||||
| 3 | Action 2 (model architecture, complete) | Full model with ONNX export |
|
||||
| 4 | Action 4 (quantization) | INT8 model, accuracy validated |
|
||||
|
||||
**Milestone M1:** WiFlowPose model trained on MM-Fi, exported to INT8 ONNX, PCK@20 > 85% on validation set.
|
||||
|
||||
### Phase 2: Edge Deployment (Weeks 5-8)
|
||||
|
||||
| Week | Actions | Deliverable |
|
||||
|------|---------|-------------|
|
||||
| 5 | Action 5 (edge engine, begin) | Cross-compilation working, model loads on Pi |
|
||||
| 6 | Action 5 (edge engine, complete) | Streaming inference at >= 10 Hz on Pi Zero |
|
||||
| 6 | Action 6 (CSI compression) | PCA compression on ESP32, verified bandwidth reduction |
|
||||
| 7 | Integration testing | ESP32 -> Pi Zero full pipeline working |
|
||||
| 8 | Performance optimization | Latency < 100ms, memory < 200 MB |
|
||||
|
||||
**Milestone M2:** End-to-end demo: ESP32 captures CSI, Pi Zero outputs pose at 10+ Hz.
|
||||
|
||||
### Phase 3: Accuracy and Adaptation (Weeks 9-12)
|
||||
|
||||
| Week | Actions | Deliverable |
|
||||
|------|---------|-------------|
|
||||
| 9 | Data collection (ESP32-S3 training data) | 50K+ synchronized CSI-pose frames |
|
||||
| 10 | Domain adaptation training | ESP32-specific model, MPJPE < 120mm |
|
||||
| 11 | Action 7 (cross-env adaptation) | Room calibration working |
|
||||
| 12 | Validation and documentation | ADR-069 finalized, witness bundle |
|
||||
|
||||
**Milestone M3:** Single-person MPJPE < 100mm in calibrated environment, cross-environment deployment working with 60-second calibration.
|
||||
|
||||
### Phase 4: Multi-Person and 3D (Weeks 13-20)
|
||||
|
||||
| Week | Actions | Deliverable |
|
||||
|------|---------|-------------|
|
||||
| 13-14 | Action 8 (multi-person PAF) | 2-person pose separation working |
|
||||
| 15-16 | Action 9 (3D lifting) | Z-axis estimation from multi-node |
|
||||
| 17-18 | Advanced optimization | Model distillation, QAT |
|
||||
| 19-20 | Production hardening | OTA updates, monitoring, alerting |
|
||||
|
||||
**Milestone M4:** Multi-person 3D pose at 10 Hz on Pi Zero 2 W.
|
||||
|
||||
## 8. Risk Analysis
|
||||
|
||||
### 8.1 Technical Risks
|
||||
|
||||
| Risk | Probability | Impact | Mitigation |
|
||||
|------|------------|--------|------------|
|
||||
| Pi Zero 2 W inference too slow (> 100ms) | Medium | High | Fall back to activity recognition (smaller model); use Pi 4 instead |
|
||||
| ESP32-S3 CSI quality insufficient for pose | Low | Critical | Already validated in ADR-028; add directional antennas if needed |
|
||||
| INT8 quantization degrades accuracy > 5% | Medium | Medium | Use FP16 instead (2x size, ~1.5x slower); apply QAT |
|
||||
| Cross-environment generalization poor | High | High | Room calibration (Action 7); template-based models; continuous adaptation |
|
||||
| WiFi interference degrades CSI | Medium | Medium | Coherence gating (already implemented); channel hopping; 5 GHz fallback |
|
||||
| ONNX Runtime binary too large for Pi Zero | Low | Medium | Use OnnxStream (2 MB) instead of full ONNX Runtime (30 MB) |
|
||||
| Multi-person association errors | High | Medium | Limit to 2 persons initially; use PAF + Hungarian; AETHER re-ID |
|
||||
|
||||
### 8.2 Hardware Risks
|
||||
|
||||
| Risk | Probability | Impact | Mitigation |
|
||||
|------|------------|--------|------------|
|
||||
| Pi Zero 2 W supply shortage | Medium | Medium | Design also works with Pi 3A+ or Pi 4 |
|
||||
| ESP32-S3 firmware instability | Low | Medium | Existing firmware battle-tested; OTA rollback |
|
||||
| WiFi AP interference with CSI | Low | Low | Dedicated 2.4 GHz channel; ESP32 channel hopping |
|
||||
| Power supply issues (brownout) | Low | Medium | Proper power supply; ESP32 brownout detection |
|
||||
|
||||
### 8.3 Research Risks
|
||||
|
||||
| Risk | Probability | Impact | Mitigation |
|
||||
|------|------------|--------|------------|
|
||||
| WiFlow results don't reproduce | Medium | High | Fall back to CSI-Former or MultiFormer architecture |
|
||||
| ESP32 CSI fundamentally different from Intel 5300 | Medium | High | Collect ESP32-specific training data; subcarrier interpolation |
|
||||
| Bone constraint loss doesn't improve edge accuracy | Low | Low | Remove if no benefit; constraint is simple and cheap |
|
||||
| PCA compression loses critical CSI information | Low | Medium | Validate with ablation study; fall back to raw CSI if needed |
|
||||
|
||||
## 9. Dependency Graph (Action Ordering)
|
||||
|
||||
```
|
||||
[esp32_csi_capture] (DONE)
|
||||
/ \
|
||||
v v
|
||||
[Action 1: Protocol] [training_pipeline] (DONE)
|
||||
| / | \
|
||||
v v v v
|
||||
[Action 6: Compression] [Action 2: Model] [Action 3: Bone Loss]
|
||||
| | |
|
||||
| +------+-------+
|
||||
| v
|
||||
| [Action 4: Quantization]
|
||||
| |
|
||||
+---------------+------------+
|
||||
v
|
||||
[Action 5: Edge Engine]
|
||||
|
|
||||
v
|
||||
[Action 7: Cross-Env] (Phase 2)
|
||||
|
|
||||
v
|
||||
[Action 8: Multi-Person] (Phase 2)
|
||||
|
|
||||
v
|
||||
[Action 9: 3D Lifting] (Phase 3)
|
||||
```
|
||||
|
||||
**Critical path:** Action 1 -> Action 2 -> Action 4 -> Action 5
|
||||
**Parallel path:** Action 3 can proceed concurrently with Action 2
|
||||
**Parallel path:** Action 6 can proceed concurrently with Actions 2-4
|
||||
|
||||
## 10. Success Criteria
|
||||
|
||||
### Phase 1 Exit Criteria
|
||||
|
||||
- [ ] WiFlowPose model trains to convergence on MM-Fi dataset
|
||||
- [ ] PCK@20 >= 85% on MM-Fi validation set
|
||||
- [ ] INT8 ONNX model size < 5 MB
|
||||
- [ ] Bone constraint loss reduces physically implausible predictions by > 50%
|
||||
|
||||
### Phase 2 Exit Criteria
|
||||
|
||||
- [ ] edge_infer binary cross-compiles for aarch64 and runs on Pi Zero 2 W
|
||||
- [ ] End-to-end latency < 150ms (CSI capture to pose output)
|
||||
- [ ] Inference rate >= 10 Hz sustained
|
||||
- [ ] PCA compression reduces bandwidth by >= 3x without > 5% accuracy loss
|
||||
- [ ] Multi-node support (2 ESP32 nodes + 1 Pi Zero) working
|
||||
|
||||
### Phase 3 Exit Criteria
|
||||
|
||||
- [ ] Single-person MPJPE < 100mm in calibrated environment
|
||||
- [ ] Cross-environment deployment works with 60-second calibration
|
||||
- [ ] System runs continuously for 24 hours without crashes
|
||||
- [ ] ESP32 OTA firmware update working for CSI compression parameters
|
||||
|
||||
### Phase 4 Exit Criteria
|
||||
|
||||
- [ ] 2-person pose separation working (MPJPE < 150mm per person)
|
||||
- [ ] 3D pose estimation from 2+ nodes (Z-axis error < 200mm)
|
||||
- [ ] Production monitoring and alerting operational
|
||||
|
||||
## 11. Relationship to Existing ADRs
|
||||
|
||||
| ADR | Relationship |
|
||||
|-----|-------------|
|
||||
| ADR-018 | Protocol v2 (Action 1) extends ADR-018 binary frame format |
|
||||
| ADR-024 | AETHER re-ID embeddings used in multi-person tracking (Action 8) |
|
||||
| ADR-027 | MERIDIAN cross-env generalization informs Action 7 |
|
||||
| ADR-028 | ESP32 capability audit validates CSI quality assumptions |
|
||||
| ADR-029 | RuvSense pipeline stages feed into edge inference (Action 5) |
|
||||
| ADR-068 | Per-node state pipeline directly used by multi-node inference |
|
||||
|
||||
## 12. New ADR Required
|
||||
|
||||
**ADR-069: Edge Inference on Raspberry Pi Zero 2 W**
|
||||
|
||||
This implementation plan should be formalized as ADR-069 covering:
|
||||
- Protocol v2 specification
|
||||
- WiFlowPose architecture selection rationale
|
||||
- Pi Zero deployment constraints and optimizations
|
||||
- INT8 quantization strategy
|
||||
- Cross-compilation approach
|
||||
- Environment calibration protocol
|
||||
|
||||
Status: Proposed, pending this plan's approval.
|
||||
@@ -1,142 +0,0 @@
|
||||
# Analysis: Arena Physica and Atlas RF Studio
|
||||
|
||||
## Company Overview
|
||||
|
||||
Arena Physica positions itself as building "Electromagnetic Superintelligence" -- a foundation model trained directly on electromagnetic fields, one of the four fundamental forces of physics.
|
||||
|
||||
**Website:** https://www.arenaphysica.com/
|
||||
**Key Product:** Atlas RF Studio (Beta)
|
||||
**Core Models:** Heaviside-0 (forward prediction), Marconi-0 (inverse design)
|
||||
|
||||
## Technical Architecture
|
||||
|
||||
### Heaviside-0: Forward Electromagnetic Model
|
||||
|
||||
A transformer-based neural network that predicts S-parameters (scattering parameters) from circuit geometry.
|
||||
|
||||
**Performance claims:**
|
||||
- Weighted MAE: < 1 dB
|
||||
- Speed: 13ms per design vs 4 minutes for traditional EM solvers
|
||||
- Speedup: 18,000x to 800,000x over commercial solvers (HFSS, CST)
|
||||
|
||||
**Architecture insights:**
|
||||
- Transformer backbone (specific architecture undisclosed)
|
||||
- Trained on electromagnetic field data, not just input-output mappings
|
||||
- Field augmentation acts as a regularizer -- even 0.3% field coverage during training reduced OOD loss
|
||||
|
||||
### Marconi-0: Inverse Design Model
|
||||
|
||||
A diffusion-based generative model that produces physical RF geometries matching target S-parameter specifications.
|
||||
|
||||
**Approach:**
|
||||
- Iterative refinement (diffusion process)
|
||||
- Generates "alien structures" -- non-intuitive geometries that meet specs
|
||||
- Trades compute time for quality (more diffusion steps = better designs)
|
||||
|
||||
### Training Data
|
||||
|
||||
**Simulated data:** 3 million designs across 25 expert templates with procedural variations, plus random organic structures to force learning in unexplored design space regions.
|
||||
|
||||
**Measured data:** Fabricated designs tested with vector network analyzers to capture manufacturing tolerances, material variations, connector parasitics.
|
||||
|
||||
**Total claimed:** 20M+ simulated designs in the broader training set.
|
||||
|
||||
### Current Design Space
|
||||
|
||||
- 2-layer PCB designs (8mm x 8mm)
|
||||
- 3 dielectric material choices
|
||||
- Ground vias
|
||||
- Filters and antennas
|
||||
|
||||
## Key Technical Insight: Fields as Fundamental Quantities
|
||||
|
||||
Arena Physica's central thesis is that Maxwell's equations govern electromagnetic fields, and models trained on field distributions learn the underlying physics rather than surface-level correlations between geometry and S-parameters.
|
||||
|
||||
This is directly relevant to WiFi sensing because:
|
||||
|
||||
1. **CSI IS an electromagnetic field measurement.** WiFi Channel State Information captures the complex transfer function H(f) between transmitter and receiver antennas across frequency subcarriers. This is a discrete sampling of the electromagnetic field in the propagation environment.
|
||||
|
||||
2. **Human bodies perturb the electromagnetic field.** Pose estimation from WiFi works because the human body (70% water, high permittivity) creates measurable perturbations in the ambient electromagnetic field.
|
||||
|
||||
3. **Foundation model approach could apply to sensing.** A model trained on electromagnetic field distributions in rooms with human bodies could potentially generalize across environments better than models trained on CSI-to-pose mappings directly.
|
||||
|
||||
## Relevance to WiFi-DensePose Project
|
||||
|
||||
### Direct Applicability: Moderate
|
||||
|
||||
Arena Physica's current focus is RF component design (filters, antennas), not sensing. However, several concepts transfer directly:
|
||||
|
||||
### 1. Physics-Informed Neural Architecture
|
||||
|
||||
Arena Physica trains on the electromagnetic field itself, not just input-output pairs. We should adopt this principle:
|
||||
|
||||
**Current approach in wifi-densepose:**
|
||||
```
|
||||
CSI amplitude/phase -> CNN/Transformer -> Keypoint coordinates
|
||||
```
|
||||
|
||||
**Physics-informed approach inspired by Arena Physica:**
|
||||
```
|
||||
CSI amplitude/phase -> Field reconstruction -> Body perturbation extraction -> Pose estimation
|
||||
```
|
||||
|
||||
Concretely, this means adding an intermediate field reconstruction stage that produces a spatial electromagnetic field map (similar to our existing `tomography.rs` module in RuvSense) and then extracting body perturbation from the field rather than going directly from CSI to pose.
|
||||
|
||||
### 2. Forward Model for Data Augmentation
|
||||
|
||||
Heaviside-0 predicts S-parameters from geometry. An analogous forward model for WiFi sensing would predict CSI from (room geometry + human pose). This enables:
|
||||
|
||||
- **Synthetic training data generation:** Generate CSI samples for arbitrary room layouts and poses
|
||||
- **Domain adaptation:** Bridge the sim-to-real gap by training the forward model on measured data
|
||||
- **Physics-based data augmentation:** Perturb room geometry parameters to generate diverse training environments
|
||||
|
||||
This directly addresses our MERIDIAN cross-environment generalization challenge (ADR-027).
|
||||
|
||||
### 3. Diffusion-Based Inverse Models
|
||||
|
||||
Marconi-0 uses diffusion to solve the inverse problem (S-parameters -> geometry). The analogous inverse problem for WiFi sensing is (CSI -> pose). Recent work on diffusion-based pose estimation could be adapted:
|
||||
|
||||
- Generate multiple pose hypotheses from a single CSI observation
|
||||
- Score hypotheses by physical plausibility (bone length constraints, joint angle limits)
|
||||
- Select the highest-scoring hypothesis
|
||||
|
||||
This is more robust than single-shot regression for ambiguous CSI measurements.
|
||||
|
||||
### 4. Multi-Resolution Field Representation
|
||||
|
||||
Arena Physica operates on 2-layer PCB designs at the mm scale. WiFi sensing operates at the wavelength scale (12.5 cm at 2.4 GHz). However, the principle of multi-resolution field representation applies:
|
||||
|
||||
- **Coarse grid:** Room-level field structure (presence detection, zone occupancy)
|
||||
- **Medium grid:** Body-level perturbation (bounding box, silhouette)
|
||||
- **Fine grid:** Limb-level detail (keypoint localization)
|
||||
|
||||
This maps to our existing RuvSense tomography module which implements RF tomography on a voxel grid, but suggests a multi-resolution approach would be more efficient.
|
||||
|
||||
## Adaptation Strategy for ESP32 + Pi Zero Deployment
|
||||
|
||||
### What to borrow from Arena Physica:
|
||||
|
||||
1. **Field-augmented training:** During training (on GPU workstation), include an auxiliary loss that encourages the model to predict the electromagnetic field distribution, not just keypoints. This regularizes the model and improves OOD generalization. At inference time on Pi Zero, the field prediction head is pruned.
|
||||
|
||||
2. **Lightweight forward model:** Train a small forward model (CSI predictor given room parameters) on the ESP32 side. This enables on-device anomaly detection: if observed CSI deviates significantly from the forward model prediction, flag the observation as potentially adversarial or corrupted.
|
||||
|
||||
3. **Template-based design space:** Arena Physica uses 25 expert templates with procedural variations. We should define "room templates" (corridor, open office, bedroom, living room) and train specialized lightweight models per template, selected at deployment time.
|
||||
|
||||
### What does NOT transfer:
|
||||
|
||||
1. **Scale of training data:** 20M+ designs is infeasible for WiFi sensing. Real CSI data collection is expensive. Synthetic data (ray tracing simulation) partially addresses this but lacks the fidelity of Arena Physica's EM simulations.
|
||||
|
||||
2. **Diffusion models on edge:** Marconi-0's diffusion approach is too computationally expensive for Pi Zero inference. We need single-shot architectures for real-time operation.
|
||||
|
||||
3. **2D geometry inputs:** Arena Physica processes 2D PCB layouts. WiFi sensing requires processing time-series data with complex spatial structure. The input representations are fundamentally different.
|
||||
|
||||
## Conclusions
|
||||
|
||||
Arena Physica demonstrates that foundation models trained on electromagnetic field data achieve superior generalization compared to models trained on input-output mappings alone. The key transferable insights for WiFi-DensePose are:
|
||||
|
||||
1. **Train on fields, not just observations** -- include field reconstruction as an auxiliary task
|
||||
2. **Use forward models for augmentation** -- predict CSI from room+pose for synthetic data
|
||||
3. **Multi-resolution representations** -- coarse-to-fine field reconstruction improves efficiency
|
||||
4. **Template-based specialization** -- room-type-specific models improve accuracy with lower compute
|
||||
|
||||
These insights inform the implementation plan, particularly the training pipeline design and the novel "field-augmented" training approach proposed in the implementation plan.
|
||||
@@ -1,444 +0,0 @@
|
||||
# Arena Physica Studio Analysis
|
||||
|
||||
Research document for wifi-densepose project.
|
||||
Date: 2026-04-02
|
||||
|
||||
---
|
||||
|
||||
## 1. What is Arena Physica?
|
||||
|
||||
Arena Physica (trading as Arena, arena-ai.com / arenaphysica.com) is a startup pursuing "Electromagnetic Superintelligence" -- building AI foundation models that develop superhuman intuition for how geometry shapes electromagnetic fields.
|
||||
|
||||
- **Founded**: 2019
|
||||
- **Founders**: Pratap Ranade (CEO), Arya Hezarkhani, Claire Pan, Michael Frei, Harish Krishnaswamy
|
||||
- **Funding**: $30M Series B (April 2025)
|
||||
- **Offices**: NYC (HQ), SF, LA
|
||||
- **Customers**: AMD, Anduril Industries, Sivers Semiconductors, Bausch & Lomb
|
||||
- **Impact claimed**: 35% reduction in engineering man-hours, multi-month acceleration in time-to-market, >3% improvement in product quality
|
||||
|
||||
Arena does NOT do WiFi sensing. They build AI-driven tools for RF/electromagnetic hardware design -- antennas, PCBs, filters, RF components. Their relevance to our project is methodological: they demonstrate how to build neural surrogates for Maxwell's equations that run 18,000x to 800,000x faster than traditional solvers.
|
||||
|
||||
|
||||
## 2. Atlas Platform and RF Studio
|
||||
|
||||
### 2.1 Atlas (Main Platform)
|
||||
|
||||
Atlas is Arena's "agentic platform" for hardware design workflows. It is deployed in production with Fortune 500 companies. Atlas encompasses:
|
||||
|
||||
- AI-driven electromagnetic simulation
|
||||
- Design generation and optimization
|
||||
- Hardware verification workflows
|
||||
- Integration with existing engineering tools
|
||||
|
||||
### 2.2 Atlas RF Studio (Public Beta)
|
||||
|
||||
Atlas RF Studio (https://studio.arenaphysica.com/) is a lightweight public instance of the Atlas platform, released as an "interactive sandbox for AI-driven inverse RF design." It serves as a research preview of their electromagnetic foundation model.
|
||||
|
||||
**Current capabilities (Beta):**
|
||||
- Two-layer RF structures
|
||||
- 8mm x 8mm maximum dimensions
|
||||
- Ground vias support
|
||||
- 3 dielectric material choices
|
||||
- AI-driven design generation from specifications
|
||||
- Real-time S-parameter prediction
|
||||
|
||||
**Workflow:**
|
||||
1. User inputs electromagnetic specifications (target S-parameters)
|
||||
2. Marconi-0 (inverse model) generates candidate geometries via conditional diffusion
|
||||
3. Heaviside-0 (forward model) evaluates each candidate in 13ms
|
||||
4. System iterates: generate -> simulate -> refine
|
||||
5. User receives optimized RF component design
|
||||
|
||||
### 2.3 Foundation Models
|
||||
|
||||
**Heaviside-0 (Forward Model)**:
|
||||
- Named after Oliver Heaviside (reformulated Maxwell's equations into modern vector form)
|
||||
- Predicts: S-parameters (magnitude + phase) and electromagnetic field distributions
|
||||
- Speed: 13ms single design, 0.3ms batched
|
||||
- Traditional solver comparison: ~4 minutes (HFSS/FDTD)
|
||||
- Speedup: 18,000x - 800,000x
|
||||
- Trained on 3 million designs across 25 expert templates + random structures
|
||||
- Training data represents 20+ years of combined simulation time
|
||||
- Accuracy: < 1 dB magnitude-weighted MAE
|
||||
|
||||
**Marconi-0 (Inverse Model)**:
|
||||
- Named after Guglielmo Marconi (radio pioneer)
|
||||
- Generates physical geometries from target S-parameter specifications
|
||||
- Uses conditional diffusion process (similar to Stable Diffusion / DALL-E architecture)
|
||||
- Can produce unconventional geometries that outperform human-designed solutions
|
||||
|
||||
### 2.4 Roadmap
|
||||
|
||||
Planned extensions include:
|
||||
- Multi-layer structures
|
||||
- Silicon integration (tapeout planned by end 2026)
|
||||
- Multiphysics integration (thermal, mechanical beyond EM)
|
||||
- Broader frequency ranges and design spaces
|
||||
|
||||
|
||||
## 3. Studio Technical Architecture
|
||||
|
||||
### 3.1 Frontend Stack
|
||||
|
||||
Based on runtime analysis of https://studio.arenaphysica.com/:
|
||||
|
||||
| Component | Technology | Evidence |
|
||||
|---|---|---|
|
||||
| Framework | Next.js (App Router, server-side streaming) | `__next_f`, `__next_s` arrays, static chunk loading |
|
||||
| UI Library | Mantine | Responsive breakpoint utilities (xs, sm, md, lg, xl) |
|
||||
| Rendering | React (server components + client hydration) | React streaming, component loading |
|
||||
| Fonts | Custom: Rules (Regular/Medium/Bold), EditionNumericalXXIX, Geist Mono (Google Fonts) | Font declarations in page source |
|
||||
| Theme | Dark mode default for "rf" domain | `ATLAS_DOMAIN: "rf"` config triggers dark theme |
|
||||
|
||||
### 3.2 Backend / API Infrastructure
|
||||
|
||||
| Service | Detail |
|
||||
|---|---|
|
||||
| API Domain | `https://api.emfm.atlas.arena-ai.com` (Auth0 audience) |
|
||||
| Organization | `emfmprod` |
|
||||
| Authentication | Auth0 with custom organization ID |
|
||||
| Feature Flags | DevCycle SDK (A/B testing) |
|
||||
| Monitoring | Datadog RUM (Real User Monitoring) |
|
||||
| 3D Rendering | Unreal Engine server at `https://52.61.97.121` (AWS IP) |
|
||||
| Terms of Service | Required (`ATLAS_REQUIRE_TOS: true`) |
|
||||
|
||||
### 3.3 Configuration Flags (from runtime config)
|
||||
|
||||
```json
|
||||
{
|
||||
"AUTH0_AUDIENCE": "https://api.emfm.atlas.arena-ai.com",
|
||||
"ATLAS_DOMAIN": "rf",
|
||||
"ATLAS_REQUIRE_TOS": true,
|
||||
"POLL_FOR_MESSAGES": false,
|
||||
"ENABLE_HOTJAR": false,
|
||||
"SHOW_DEBUG_LOGS": false
|
||||
}
|
||||
```
|
||||
|
||||
Key observations:
|
||||
- `POLL_FOR_MESSAGES: false` -- Messages likely use WebSocket/SSE push rather than polling
|
||||
- `ENABLE_HOTJAR: false` -- Session replay disabled in production
|
||||
- `SHOW_DEBUG_LOGS: false` -- Debug mode off
|
||||
- The `emfm` in the API domain likely stands for "ElectroMagnetic Field Model"
|
||||
|
||||
### 3.4 3D Visualization via Unreal Engine
|
||||
|
||||
The most technically interesting finding: Studio connects to an Unreal Engine server (IP: 52.61.97.121, AWS us-west region) for 3D electromagnetic field visualization.
|
||||
|
||||
**Likely architecture:**
|
||||
1. User submits design geometry in the Next.js frontend
|
||||
2. Backend runs Heaviside-0/Marconi-0 inference
|
||||
3. S-parameter results and field distribution data sent to Unreal Engine instance
|
||||
4. Unreal Engine renders 3D field visualization (E-field, H-field, current distributions)
|
||||
5. Pixel streaming sends rendered frames back to browser via WebRTC/WebSocket
|
||||
6. Interactive controls (rotate, zoom, slice planes) forwarded to Unreal Engine
|
||||
|
||||
This is consistent with Unreal Engine's Pixel Streaming technology, which renders on a remote GPU and streams video to a web browser. The `52.61.97.121` IP being hardcoded suggests a dedicated rendering server or fleet.
|
||||
|
||||
**Unreal Engine WebSocket Protocol** (standard):
|
||||
- Signaling server negotiates WebRTC connection
|
||||
- Control messages: `{ type: "input", data: { ... } }` for mouse/keyboard
|
||||
- Video stream: H.264/VP8 encoded, streamed via WebRTC data channel
|
||||
- Bidirectional: user input -> Unreal, rendered frames -> browser
|
||||
|
||||
### 3.5 Data Formats (Inferred)
|
||||
|
||||
Based on the S-parameter focus:
|
||||
|
||||
**Input (Design Specification):**
|
||||
- Target S-parameters: S11, S21, S12, S22 (magnitude + phase vs frequency)
|
||||
- Frequency range (likely GHz, given RF focus)
|
||||
- Material properties (dielectric constant, loss tangent)
|
||||
- Geometric constraints (layer count, max dimensions)
|
||||
|
||||
**Output (Design Result):**
|
||||
- Geometry: likely a discretized grid (64x64 binary material map based on Not Boring article)
|
||||
- S-parameters: complex-valued frequency response curves
|
||||
- Field distributions: 2D/3D electromagnetic field maps
|
||||
- Performance metrics: return loss, insertion loss, bandwidth
|
||||
|
||||
**Probable API format** (speculative, based on EM conventions):
|
||||
```json
|
||||
{
|
||||
"design": {
|
||||
"layers": [
|
||||
{
|
||||
"geometry": [[0,1,1,0,...], ...], // Binary material grid
|
||||
"material": "FR4",
|
||||
"thickness_mm": 0.2
|
||||
}
|
||||
],
|
||||
"vias": [{"x": 3, "y": 5, "radius_mm": 0.15}],
|
||||
"dielectric": "rogers_4003c"
|
||||
},
|
||||
"simulation": {
|
||||
"s_parameters": {
|
||||
"frequencies_ghz": [1.0, 1.1, ..., 40.0],
|
||||
"s11_mag_db": [-5.2, -5.4, ...],
|
||||
"s11_phase_deg": [45.2, 44.8, ...],
|
||||
"s21_mag_db": [-0.3, -0.3, ...]
|
||||
},
|
||||
"field_data": {
|
||||
"type": "near_field",
|
||||
"grid_size": [64, 64],
|
||||
"e_field_magnitude": [[...], ...]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## 4. UI Components and Features
|
||||
|
||||
### 4.1 Observed UI Elements
|
||||
|
||||
Based on page source analysis:
|
||||
|
||||
- **Dark theme** with custom fonts (Rules family -- geometric sans-serif)
|
||||
- **Icon system** ("IconMark" component -- likely a custom RF/EM icon set)
|
||||
- **Responsive design** via Mantine breakpoints
|
||||
- **ToS gate** requiring acceptance before use
|
||||
- **Organization-scoped access** (Auth0 org-based multi-tenancy)
|
||||
|
||||
### 4.2 Likely Feature Set (inferred from product description and tech stack)
|
||||
|
||||
| Feature | Description | UI Component |
|
||||
|---|---|---|
|
||||
| Specification Input | Enter target S-parameters, frequency range, constraints | Form with frequency sweep chart |
|
||||
| Design Canvas | View/edit 2D geometry layers | Interactive grid editor |
|
||||
| S-parameter Viewer | Plot S11/S21/S12/S22 vs frequency | Interactive chart (likely Recharts or D3) |
|
||||
| 3D Field Viewer | Visualize E/H field distributions | Unreal Engine pixel-streamed viewport |
|
||||
| Design History | Browse previous designs and iterations | List/card view with thumbnails |
|
||||
| Compare View | Side-by-side design comparison | Split-pane layout |
|
||||
| Export | Download design files (Gerber, GDSII, S-parameter Touchstone) | Download buttons |
|
||||
|
||||
### 4.3 Agentic Workflow UI
|
||||
|
||||
Atlas RF Studio describes "agentic workflows" that:
|
||||
1. Accept natural-language or parametric specifications
|
||||
2. Generate multiple candidate designs
|
||||
3. Simulate each candidate
|
||||
4. Present ranked results
|
||||
5. Allow iterative refinement
|
||||
|
||||
This suggests an LLM chat interface (translating intent to specs) alongside the technical EM visualization. The pairing of LLM + LFM (Large Field Model) is explicitly described in their architecture.
|
||||
|
||||
|
||||
## 5. Lessons for Our Sensing Server UI
|
||||
|
||||
### 5.1 Architecture Patterns to Adopt
|
||||
|
||||
| Arena Physica Pattern | Application to wifi-densepose sensing-server |
|
||||
|---|---|
|
||||
| Dark theme default | Already appropriate for a sensing/monitoring dashboard |
|
||||
| Next.js + Mantine | Consider for our sensing-server UI (currently Axum + vanilla) |
|
||||
| Auth0 multi-tenancy | Overkill for local deployment; useful for cloud/multi-site |
|
||||
| Unreal Engine 3D | Too heavy; use Three.js/WebGL for 3D pose visualization |
|
||||
| WebSocket push (not polling) | Match our real-time CSI streaming needs |
|
||||
| Feature flags (DevCycle) | Useful for gradual feature rollout |
|
||||
| Datadog RUM | Consider lightweight alternative (e.g., self-hosted analytics) |
|
||||
|
||||
### 5.2 Visualization Approaches
|
||||
|
||||
**What Arena visualizes:**
|
||||
- S-parameters (frequency-domain complex response) -- charts
|
||||
- Electromagnetic field distributions -- 3D heatmaps
|
||||
- Design geometry -- 2D grid with material layers
|
||||
|
||||
**What we need to visualize:**
|
||||
- CSI amplitude/phase across subcarriers -- frequency-domain charts (similar to S-parameters)
|
||||
- Person occupancy heatmap -- 2D/3D voxel grid (similar to field visualization)
|
||||
- Pose skeleton overlay -- 2D/3D joint rendering
|
||||
- Vital signs (HR, BR) -- time-series charts
|
||||
- Node mesh topology -- graph visualization
|
||||
- Signal quality metrics -- dashboard gauges
|
||||
|
||||
**Shared patterns:**
|
||||
- Both need real-time frequency-domain data visualization
|
||||
- Both show spatial field/occupancy distributions
|
||||
- Both benefit from interactive 3D (but at different scales)
|
||||
- Both require low-latency streaming from computation backend
|
||||
|
||||
### 5.3 Data Flow Architecture Comparison
|
||||
|
||||
**Arena Physica:**
|
||||
```
|
||||
Browser (Next.js) -> API (inference) -> Heaviside-0/Marconi-0 -> Unreal Engine -> Pixel Stream -> Browser
|
||||
```
|
||||
|
||||
**wifi-densepose (recommended):**
|
||||
```
|
||||
ESP32 nodes -> sensing-server (Axum) -> WebSocket -> Browser (React/Mantine)
|
||||
|
|
||||
v
|
||||
RuvSense pipeline -> pose/vitals -> WebSocket -> Browser
|
||||
```
|
||||
|
||||
Key difference: Arena renders 3D on the server (Unreal Engine) and streams pixels. We should render 3D on the client (Three.js/WebGL) and stream data, because:
|
||||
- Our 3D scenes are simpler (skeleton + voxels vs. full EM field)
|
||||
- Client-side rendering avoids GPU server costs
|
||||
- Lower latency for real-time sensing feedback
|
||||
- Works offline / on local network
|
||||
|
||||
### 5.4 API Design Lessons
|
||||
|
||||
**Arena's API pattern** (REST + WebSocket):
|
||||
- REST for design submission and retrieval
|
||||
- WebSocket/SSE for live simulation progress and results
|
||||
- Auth0 JWT for authentication
|
||||
- Organization-scoped resources
|
||||
|
||||
**Recommended for sensing-server:**
|
||||
- REST endpoints for configuration, history, calibration
|
||||
- WebSocket for real-time CSI, pose, and vitals streaming
|
||||
- Optional: SSE as fallback for environments where WebSocket is blocked
|
||||
- API key or local-only access (no OAuth needed for embedded deployment)
|
||||
|
||||
**Proposed WebSocket protocol for sensing-server:**
|
||||
```json
|
||||
// Server -> Client: CSI frame
|
||||
{
|
||||
"type": "csi_frame",
|
||||
"timestamp_us": 1712000000000,
|
||||
"node_id": "esp32-node-1",
|
||||
"subcarriers": 56,
|
||||
"amplitude": [0.45, 0.52, ...],
|
||||
"phase": [-1.23, 0.87, ...]
|
||||
}
|
||||
|
||||
// Server -> Client: Pose update
|
||||
{
|
||||
"type": "pose",
|
||||
"timestamp_us": 1712000000000,
|
||||
"persons": [
|
||||
{
|
||||
"id": 0,
|
||||
"keypoints": [
|
||||
{"name": "nose", "x": 2.3, "y": 1.5, "z": 1.7, "confidence": 0.92},
|
||||
...
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
// Server -> Client: Vitals update
|
||||
{
|
||||
"type": "vitals",
|
||||
"timestamp_us": 1712000000000,
|
||||
"person_id": 0,
|
||||
"heart_rate_bpm": 72.5,
|
||||
"breathing_rate_rpm": 16.2,
|
||||
"presence_score": 0.98
|
||||
}
|
||||
|
||||
// Server -> Client: Occupancy grid
|
||||
{
|
||||
"type": "occupancy",
|
||||
"timestamp_us": 1712000000000,
|
||||
"nx": 8, "ny": 8, "nz": 4,
|
||||
"bounds": [0.0, 0.0, 0.0, 6.0, 6.0, 3.0],
|
||||
"densities": [0.0, 0.0, 0.12, ...]
|
||||
}
|
||||
|
||||
// Client -> Server: Configuration
|
||||
{
|
||||
"type": "config",
|
||||
"action": "set",
|
||||
"key": "tomography.lambda",
|
||||
"value": 0.15
|
||||
}
|
||||
```
|
||||
|
||||
### 5.5 Specific UI Components to Build
|
||||
|
||||
Based on Arena Physica's approach and our sensing needs:
|
||||
|
||||
**Priority 1 (Core Dashboard):**
|
||||
1. **Real-time CSI waterfall** -- Subcarrier amplitude over time, color-mapped (similar to spectrogram)
|
||||
2. **Pose skeleton view** -- 2D/3D rendering of detected keypoints with skeleton connections
|
||||
3. **Node topology map** -- Show ESP32 mesh with RSSI-colored edges
|
||||
4. **Vitals panel** -- Heart rate and breathing rate with time-series charts
|
||||
|
||||
**Priority 2 (Advanced Visualization):**
|
||||
5. **Occupancy heatmap** -- 2D top-down view of tomographic voxel grid
|
||||
6. **Phase coherence indicator** -- Per-link coherence scores (green/yellow/red)
|
||||
7. **Fresnel zone overlay** -- Show first Fresnel zone on room floor plan per link
|
||||
|
||||
**Priority 3 (Configuration/Debug):**
|
||||
8. **Calibration wizard** -- Guide through empty-room calibration for field_model
|
||||
9. **Link quality matrix** -- NxN grid showing per-link signal metrics
|
||||
10. **Raw CSI inspector** -- Select individual link, view amplitude + phase per subcarrier
|
||||
|
||||
|
||||
## 6. Public API Endpoints and Protocols
|
||||
|
||||
### 6.1 Confirmed Endpoints
|
||||
|
||||
| Endpoint | Protocol | Purpose |
|
||||
|---|---|---|
|
||||
| `https://studio.arenaphysica.com` | HTTPS | Main web application (Next.js SSR) |
|
||||
| `https://api.emfm.atlas.arena-ai.com` | HTTPS | Backend API (Auth0 audience) |
|
||||
| `https://52.61.97.121` | HTTPS/WSS | Unreal Engine rendering server |
|
||||
|
||||
### 6.2 Authentication
|
||||
|
||||
- Auth0-based with organization scoping
|
||||
- Custom audience: `https://api.emfm.atlas.arena-ai.com`
|
||||
- Organization: `emfmprod`
|
||||
- Terms of Service required before access
|
||||
|
||||
### 6.3 Feature Flags
|
||||
|
||||
DevCycle SDK integrated for A/B testing and feature gating. This suggests gradual rollout of new capabilities.
|
||||
|
||||
### 6.4 Monitoring
|
||||
|
||||
Datadog RUM (Real User Monitoring) for performance tracking. Session replay (Hotjar) is available but disabled in production.
|
||||
|
||||
### 6.5 What is NOT Publicly Documented
|
||||
|
||||
- REST API endpoints (no public API docs found)
|
||||
- WebSocket message schemas
|
||||
- S-parameter data format
|
||||
- Geometry encoding format
|
||||
- Rate limits or usage quotas
|
||||
- Pricing model
|
||||
|
||||
Arena Physica appears to operate as a closed platform without public API access. The Studio beta is a controlled preview, not an open API.
|
||||
|
||||
|
||||
## 7. Summary of Findings
|
||||
|
||||
### What Arena Physica Is
|
||||
A $30M-funded startup building neural surrogates for electromagnetic simulation. Their AI predicts S-parameters and field distributions 18,000-800,000x faster than traditional solvers. They serve Fortune 500 hardware companies (AMD, Anduril) for RF component design.
|
||||
|
||||
### What Arena Physica Is NOT
|
||||
They are not a WiFi sensing company. They do not do human pose estimation, CSI analysis, or IoT sensing. The relevance to our project is purely methodological.
|
||||
|
||||
### Key Technical Takeaways for wifi-densepose
|
||||
|
||||
1. **Neural surrogates for Maxwell's equations work** -- Arena proves that training on millions of simulation examples produces models accurate to < 1 dB MAE running in milliseconds. We could apply the same approach to CSI prediction.
|
||||
|
||||
2. **Inverse design via conditional diffusion** -- Marconi-0's approach (generating geometry from target specs) parallels our inverse problem (generating pose from CSI). Conditional diffusion is a viable architecture.
|
||||
|
||||
3. **Bidirectional search** -- The generate-evaluate-refine loop is more effective than direct inversion. For real-time sensing, the evaluator (forward model) must be fast.
|
||||
|
||||
4. **Domain-specific models beat general LLMs** -- For electromagnetic tasks, specialized architectures substantially outperform GPT-4 / Claude. This validates our approach of building specialized CSI processing rather than relying on general-purpose models.
|
||||
|
||||
5. **Studio UI is Next.js + Mantine + Unreal Engine** -- A modern stack, but the Unreal Engine component is overkill for our visualization needs. Three.js/WebGL on the client is more appropriate for our real-time sensing dashboard.
|
||||
|
||||
6. **WebSocket push over polling** -- Confirmed by their `POLL_FOR_MESSAGES: false` configuration. Our sensing-server should use WebSocket push for real-time data streaming.
|
||||
|
||||
|
||||
## References
|
||||
|
||||
- Arena Physica Homepage: https://www.arenaphysica.com/
|
||||
- Atlas RF Studio Beta: https://studio.arenaphysica.com/
|
||||
- Introducing Atlas RF Studio (publication): https://www.arenaphysica.com/publications/rf-studio
|
||||
- Electromagnetism Secretly Runs the World (Not Boring essay): https://www.notboring.co/p/electromagnetism-secretly-runs-the
|
||||
- Arena Launches Atlas (press release): https://www.prnewswire.com/news-releases/arena-launches-atlas-to-accelerate-humanitys-rate-of-hardware-innovation-302423412.html
|
||||
- Arena AI raises $30M (SiliconANGLE): https://siliconangle.com/2025/04/08/arena-ai-raises-30m-accelerate-innovation-hardware-testing-atlas/
|
||||
- Artificial Intuition (CDFAM presentation): https://www.designforam.com/p/artificial-intuition-building-an
|
||||
- Pratap Ranade LinkedIn announcement: https://www.linkedin.com/posts/pratap-ranade-7272829_today-im-excited-to-introduce-arena-physica-activity-7442204772725723137-RRtE
|
||||
- Mantine UI: https://mantine.dev/
|
||||
- Unreal Engine Pixel Streaming: https://dev.epicgames.com/documentation/en-us/unreal-engine/remote-control-api-websocket-reference-for-unreal-engine
|
||||
@@ -1,141 +0,0 @@
|
||||
# Deep Analysis: arXiv 2505.15472 -- PhysicsArena
|
||||
|
||||
**Date:** 2026-04-02
|
||||
**Analyst:** GOAP Planning Agent
|
||||
**Relevance to wifi-densepose:** Indirect (physics reasoning benchmark, not WiFi sensing)
|
||||
|
||||
---
|
||||
|
||||
## 1. Paper Identity
|
||||
|
||||
- **Title:** PhysicsArena: The First Multimodal Physics Reasoning Benchmark Exploring Variable, Process, and Solution Dimensions
|
||||
- **Authors:** Song Dai, Yibo Yan, Jiamin Su, Dongfang Zihao, Yubo Gao, Yonghua Hei, Jungang Li, Junyan Zhang, Sicheng Tao, Zhuoran Gao, Xuming Hu
|
||||
- **Submitted:** 2025-05-21, revised 2025-05-22
|
||||
- **Category:** cs.CL (Computation and Language)
|
||||
- **arXiv ID:** 2505.15472v2
|
||||
|
||||
## 2. Core Contribution
|
||||
|
||||
PhysicsArena introduces a multimodal benchmark for evaluating how Large Language Models (MLLMs) reason about physics problems. The benchmark assesses three dimensions:
|
||||
|
||||
1. **Variable Identification** -- Can the model correctly identify physical variables from multimodal inputs (diagrams, text, equations)?
|
||||
2. **Physical Process Formulation** -- Can the model select and chain the correct physical laws and processes?
|
||||
3. **Solution Derivation** -- Can the model produce correct numerical/symbolic solutions?
|
||||
|
||||
This is the first benchmark to decompose physics reasoning into these three granular dimensions rather than only evaluating final answers.
|
||||
|
||||
## 3. Technical Approach
|
||||
|
||||
### 3.1 Benchmark Structure
|
||||
|
||||
The benchmark presents physics problems with multimodal inputs (text descriptions accompanied by diagrams, graphs, and physical setups). Problems span classical mechanics, electromagnetism, thermodynamics, optics, and modern physics.
|
||||
|
||||
### 3.2 Evaluation Protocol
|
||||
|
||||
Unlike prior benchmarks that score only final answers, PhysicsArena evaluates intermediate reasoning:
|
||||
|
||||
- **Variable extraction accuracy:** Does the model identify all relevant physical quantities (mass, velocity, charge, field strength, etc.)?
|
||||
- **Process correctness:** Does the model apply the right sequence of physical laws (Newton's laws, Maxwell's equations, conservation laws)?
|
||||
- **Solution accuracy:** Does the final numerical answer match the ground truth within tolerance?
|
||||
|
||||
### 3.3 Key Finding
|
||||
|
||||
Current MLLMs (GPT-4V, Claude, Gemini) perform significantly worse on variable identification and process formulation than on final solution derivation when provided with correct intermediate steps. This reveals that models often arrive at correct answers through pattern matching rather than genuine physics reasoning.
|
||||
|
||||
## 4. Relevance to WiFi-DensePose
|
||||
|
||||
### 4.1 Direct Relevance: Low
|
||||
|
||||
This paper is not about WiFi sensing, CSI processing, pose estimation, or edge deployment. It benchmarks LLM reasoning about physics problems.
|
||||
|
||||
### 4.2 Indirect Relevance: Moderate
|
||||
|
||||
Several concepts transfer to our domain:
|
||||
|
||||
#### 4.2.1 Physics-Informed Reasoning for Signal Processing
|
||||
|
||||
The paper's decomposition of physics reasoning into (variables, process, solution) maps onto WiFi sensing:
|
||||
|
||||
| PhysicsArena Dimension | WiFi-DensePose Analog |
|
||||
|------------------------|----------------------|
|
||||
| Variable identification | CSI feature extraction (amplitude, phase, subcarrier indices, antenna config) |
|
||||
| Process formulation | Signal processing pipeline selection (phase alignment, coherence gating, multiband fusion) |
|
||||
| Solution derivation | Pose/activity estimation output |
|
||||
|
||||
This suggests a potential architecture where intermediate representations are explicitly supervised -- not just end-to-end loss on final pose, but also losses on intermediate physical quantities (estimated path lengths, Doppler shifts, angle-of-arrival).
|
||||
|
||||
#### 4.2.2 Multimodal Grounding
|
||||
|
||||
PhysicsArena's core challenge is grounding abstract reasoning in physical reality from multimodal inputs. WiFi-DensePose faces the same challenge: grounding neural network predictions in the actual physics of electromagnetic wave propagation through space containing human bodies.
|
||||
|
||||
#### 4.2.3 Decomposed Evaluation
|
||||
|
||||
The three-dimension evaluation framework suggests we should evaluate our pipeline at multiple stages:
|
||||
|
||||
1. **CSI quality metrics** (SNR, coherence, phase stability) -- analogous to variable identification
|
||||
2. **Feature extraction quality** (does the modality translator preserve physically meaningful information?) -- analogous to process formulation
|
||||
3. **Pose accuracy** (PCK@50, MPJPE) -- analogous to solution derivation
|
||||
|
||||
This would help diagnose whether failures in pose estimation originate from poor CSI capture, lossy feature translation, or incorrect pose regression.
|
||||
|
||||
### 4.3 Transferable Insight: Intermediate Supervision
|
||||
|
||||
The paper's key insight -- that evaluating only final outputs masks fundamental reasoning failures -- argues for adding intermediate supervision signals to the wifi-densepose training pipeline:
|
||||
|
||||
```
|
||||
L_total = lambda_pose * L_pose
|
||||
+ lambda_physics * L_physics_consistency
|
||||
+ lambda_intermediate * L_intermediate_features
|
||||
```
|
||||
|
||||
Where `L_physics_consistency` penalizes predictions that violate known electromagnetic propagation physics (e.g., predicted person positions that are inconsistent with observed CSI phase relationships).
|
||||
|
||||
## 5. Applicable Techniques for Implementation Plan
|
||||
|
||||
### 5.1 Physics-Constrained Loss Functions
|
||||
|
||||
Add a physics consistency loss that enforces:
|
||||
|
||||
- **Fresnel zone consistency:** Predicted body positions must be consistent with the Fresnel zones that would produce the observed CSI perturbations
|
||||
- **Multipath geometry:** The number of strong multipath components should be consistent with the predicted scene geometry
|
||||
- **Doppler-velocity consistency:** If temporal CSI changes indicate Doppler shift, the predicted keypoint velocities must match
|
||||
|
||||
### 5.2 Hierarchical Evaluation Pipeline
|
||||
|
||||
Implement three-stage evaluation matching PhysicsArena's decomposition:
|
||||
|
||||
```rust
|
||||
pub struct HierarchicalEvaluation {
|
||||
/// Stage 1: CSI quality assessment
|
||||
pub csi_quality: CsiQualityMetrics,
|
||||
/// Stage 2: Feature translation fidelity
|
||||
pub translation_fidelity: TranslationMetrics,
|
||||
/// Stage 3: Pose estimation accuracy
|
||||
pub pose_accuracy: PoseMetrics,
|
||||
}
|
||||
```
|
||||
|
||||
### 5.3 Structured Intermediate Representations
|
||||
|
||||
Rather than a single encoder-decoder, structure the network to produce interpretable intermediate outputs:
|
||||
|
||||
```
|
||||
CSI input -> [Physics Encoder] -> physical_features (AoA, ToF, Doppler)
|
||||
-> [Geometry Decoder] -> spatial_occupancy_map
|
||||
-> [Pose Regressor] -> keypoint_coordinates
|
||||
```
|
||||
|
||||
Each intermediate output can be supervised independently where ground truth is available.
|
||||
|
||||
## 6. Conclusion
|
||||
|
||||
While arXiv 2505.15472 is not directly about WiFi sensing, its framework for decomposing physics reasoning into interpretable stages provides a valuable architectural pattern. The key takeaway for wifi-densepose is: **do not rely solely on end-to-end training; add intermediate physics-grounded supervision signals to improve robustness and interpretability.**
|
||||
|
||||
This aligns with the existing RuvSense architecture which already has explicit stages (multiband fusion, phase alignment, coherence scoring, coherence gating, pose tracking) -- the paper's framework validates this design choice and argues for adding supervision at each stage boundary.
|
||||
|
||||
## 7. Cross-References
|
||||
|
||||
- **Arena Physica (arena-physica-analysis.md):** Their thesis that "fields are the fundamental quantities" reinforces the physics-first approach recommended here. Training on electromagnetic field distributions rather than end-to-end CSI-to-pose would constitute the WiFi sensing analog of PhysicsArena's decomposed evaluation.
|
||||
- **WiFlow (sota-wifi-sensing-2025.md, Section 1.1):** WiFlow's bone constraint loss is a concrete implementation of physics-informed intermediate supervision -- the skeleton must obey anatomical constraints at every prediction step.
|
||||
- **MultiFormer (sota-wifi-sensing-2025.md, Section 1.2):** MultiFormer's dual-token (time + frequency) tokenization is analogous to PhysicsArena's variable identification -- it explicitly separates the physical dimensions of the CSI measurement before reasoning about them.
|
||||
- **Implementation plan (implementation-plan.md):** The hierarchical evaluation pipeline in Section 5.2 directly implements the three-stage evaluation framework recommended here.
|
||||
@@ -1,615 +0,0 @@
|
||||
# Maxwell's Equations in WiFi/RF Sensing
|
||||
|
||||
Research document for wifi-densepose project.
|
||||
Date: 2026-04-02
|
||||
|
||||
---
|
||||
|
||||
## 1. Maxwell's Equations and CSI Extraction
|
||||
|
||||
### 1.1 Foundational Electromagnetic Theory
|
||||
|
||||
All WiFi-based sensing ultimately derives from Maxwell's four partial differential equations governing electromagnetic field behavior:
|
||||
|
||||
```
|
||||
(1) Gauss's Law (Electric): nabla . E = rho / epsilon_0
|
||||
(2) Gauss's Law (Magnetic): nabla . B = 0
|
||||
(3) Faraday's Law: nabla x E = -dB/dt
|
||||
(4) Ampere-Maxwell Law: nabla x B = mu_0 * J + mu_0 * epsilon_0 * dE/dt
|
||||
```
|
||||
|
||||
In free space with no charges or currents (the indoor propagation case), these simplify to the wave equation:
|
||||
|
||||
```
|
||||
nabla^2 E - mu_0 * epsilon_0 * d^2 E / dt^2 = 0
|
||||
```
|
||||
|
||||
yielding plane wave solutions `E(r, t) = E_0 * exp(j(k . r - omega * t))` where `k = 2*pi / lambda` is the wavenumber. At 2.4 GHz WiFi, `lambda ~ 12.5 cm`; at 5 GHz, `lambda ~ 6 cm`.
|
||||
|
||||
### 1.2 From Maxwell to Channel State Information
|
||||
|
||||
Channel State Information (CSI) is the frequency-domain representation of the wireless channel's impulse response. The derivation from Maxwell's equations proceeds through several simplification layers:
|
||||
|
||||
**Layer 1: Full Maxwell's equations** -- Exact but computationally intractable for room-scale environments at GHz frequencies.
|
||||
|
||||
**Layer 2: High-frequency ray optics (Geometrical Optics / Uniform Theory of Diffraction)** -- When object dimensions >> lambda (walls, furniture), Maxwell's equations reduce to ray tracing. Each ray follows Snell's law at interfaces, with Fresnel reflection/transmission coefficients computed from the dielectric contrast.
|
||||
|
||||
**Layer 3: Multipath channel model** -- The channel impulse response aggregates all propagation paths:
|
||||
|
||||
```
|
||||
h(t) = sum_{n=1}^{N} alpha_n * exp(-j * phi_n) * delta(t - tau_n)
|
||||
```
|
||||
|
||||
where for each path n:
|
||||
- `alpha_n` = complex attenuation (from free-space path loss, reflection, diffraction)
|
||||
- `phi_n = 2*pi*f*tau_n` = phase shift
|
||||
- `tau_n = d_n / c` = propagation delay (distance / speed of light)
|
||||
|
||||
**Layer 4: Channel Frequency Response (CFR) = CSI** -- The Fourier transform of h(t):
|
||||
|
||||
```
|
||||
H(f_k) = sum_{n=1}^{N} alpha_n * exp(-j * 2*pi * f_k * tau_n)
|
||||
```
|
||||
|
||||
Each OFDM subcarrier k at frequency f_k provides one complex CSI measurement:
|
||||
|
||||
```
|
||||
H(f_k) = |H(f_k)| * exp(j * angle(H(f_k)))
|
||||
```
|
||||
|
||||
With 802.11n/ac providing 56-256 subcarriers and 802.11ax up to 512 subcarriers across 160 MHz bandwidth, CSI captures a frequency-sampled version of the channel's multipath structure.
|
||||
|
||||
**Key insight for sensing**: When a human moves in the environment, paths reflecting off the body change their `alpha_n`, `tau_n`, and `phi_n`, modulating the CSI. The sensing problem is to invert this relationship -- recover body state from CSI changes.
|
||||
|
||||
### 1.3 The Two CSI Models
|
||||
|
||||
The Tsinghua WiFi Sensing Tutorial (tns.thss.tsinghua.edu.cn) identifies two mainstream models:
|
||||
|
||||
**Ray-Tracing Model**: Establishes explicit geometric relationships between signal paths and CSI. The received signal is:
|
||||
|
||||
```
|
||||
V = sum_{n=1}^{N} |V_n| * exp(-j * phi_n)
|
||||
```
|
||||
|
||||
This model enables extraction of geometric parameters (distances, reflection points, angles of arrival) from CSI data. It underpins localization and tracking applications.
|
||||
|
||||
**Scattering Model**: Decomposes CSI into static and dynamic contributions:
|
||||
|
||||
```
|
||||
H(f,t) = sum_{o in Omega_s} H_o(f,t) + sum_{p in Omega_d} H_p(f,t)
|
||||
```
|
||||
|
||||
Dynamic scatterers (moving bodies) contribute through angular integration:
|
||||
|
||||
```
|
||||
H_p(f,t) = integral_0^{2pi} integral_0^{pi} h_p(alpha, beta, f, t) * exp(-j*k*v_p*cos(alpha)*t) d_alpha d_beta
|
||||
```
|
||||
|
||||
The scattering model yields the CSI autocorrelation:
|
||||
|
||||
```
|
||||
rho_H(f, tau) ~ sinc(k * v * tau)
|
||||
```
|
||||
|
||||
enabling speed extraction from autocorrelation peak analysis:
|
||||
|
||||
```
|
||||
v = x_0 * lambda / (2 * pi * tau_0)
|
||||
```
|
||||
|
||||
where `x_0` is the first sinc extremum location and `tau_0` is the corresponding time lag.
|
||||
|
||||
### 1.4 Practical Simplifications Used in WiFi Sensing
|
||||
|
||||
| Approximation | Physical Basis | Used When | Accuracy |
|
||||
|---|---|---|---|
|
||||
| Ray tracing (GO/UTD) | High-frequency limit of Maxwell | Objects >> lambda | Good for LOS + major reflections |
|
||||
| Fresnel zone model | Wave diffraction | Target near TX-RX line | Excellent for presence/respiration |
|
||||
| Born approximation | Weak scattering (small perturbation) | Low-contrast objects | Breaks down for human body |
|
||||
| Rytov approximation | Phase perturbation expansion | Moderate scattering | Better for lossy media |
|
||||
| Free-space path loss | 1/r^2 power decay | Coarse attenuation models | Adequate for RSSI-based sensing |
|
||||
|
||||
**Relevance to wifi-densepose**: Our `field_model.rs` implements the eigenstructure approach (Layer 2.5 -- between full ray tracing and statistical models), decomposing the channel covariance via SVD to separate environmental modes from body perturbation. Our `tomography.rs` implements the voxel-based inverse at Layer 3 using L1-regularized least squares.
|
||||
|
||||
|
||||
## 2. Physics-Informed Neural Networks (PINNs) for RF Sensing
|
||||
|
||||
### 2.1 PINN Architecture for Wireless Channels
|
||||
|
||||
Physics-Informed Neural Networks embed physical laws as constraints in the loss function or network architecture. For RF sensing, PINNs encode electromagnetic propagation principles:
|
||||
|
||||
**Standard PINN loss for RF propagation:**
|
||||
|
||||
```
|
||||
L_total = L_data + lambda_physics * L_physics + lambda_boundary * L_boundary
|
||||
|
||||
where:
|
||||
L_data = (1/N) * sum |H_pred(f_k) - H_meas(f_k)|^2 (CSI measurement fit)
|
||||
L_physics = (1/M) * sum |nabla^2 E + k^2 * E|^2 (Helmholtz equation residual)
|
||||
L_boundary = (1/B) * sum |E_pred - E_bc|^2 (boundary conditions)
|
||||
```
|
||||
|
||||
The Helmholtz equation `nabla^2 E + k^2 * n^2(r) * E = 0` (time-harmonic Maxwell) constrains the solution space, where `n(r)` is the spatially varying refractive index.
|
||||
|
||||
### 2.2 Key Papers and Approaches
|
||||
|
||||
**PINN + GNN for RF Map Construction** (arXiv 2507.22513):
|
||||
- Combines Physics-Informed Neural Networks with Graph Neural Networks
|
||||
- Physical constraints from EM propagation laws guide learning
|
||||
- Parameterizes multipath signals into received power, delay, and angle of arrival
|
||||
- Integrates spatial dependencies for accurate prediction
|
||||
|
||||
**PINN for Wireless Channel Estimation** (NeurIPS 2025, OpenReview r3plaU6DvW):
|
||||
- Synergistically combines model-based channel estimation with deep network
|
||||
- Exploits prior information about environmental propagation
|
||||
- Critical for next-gen wireless systems: precoding, interference reduction, sensing
|
||||
|
||||
**ReVeal: High-Fidelity Radio Propagation** (DySPAN 2025):
|
||||
- Physics-informed approach for radio environment mapping
|
||||
- Achieves high fidelity with limited measurement data
|
||||
|
||||
**Physics-Informed Generative Model for Passive RF Sensing** (arXiv 2310.04173, Savazzi et al.):
|
||||
- Variational Auto-Encoder integrating EM body diffraction
|
||||
- Forward model: predicts CSI perturbation from body position/pose
|
||||
- Validated against classical diffraction-based EM tools AND real RF measurements
|
||||
- Enables real-time processing where traditional EM is too slow
|
||||
|
||||
**Multi-Modal Foundational Model** (arXiv 2602.04016, February 2026):
|
||||
- Foundation model for AI-driven physical-layer wireless systems
|
||||
- Physics-guided pretraining grounded in EM propagation principles
|
||||
- Treats wireless as inherently multimodal physical system
|
||||
|
||||
**Generative AI for Wireless Sensing** (arXiv 2509.15258, September 2025):
|
||||
- Physics-informed diffusion models for data augmentation
|
||||
- Channel prediction and environment modeling
|
||||
- Conditional mechanisms constrained by EM laws
|
||||
|
||||
### 2.3 PINN Architecture for CSI-Based Sensing
|
||||
|
||||
```
|
||||
Algorithm: Physics-Informed CSI Sensing Network
|
||||
|
||||
Input: CSI tensor H[time, subcarrier, antenna] of shape (T, K, M)
|
||||
Output: Body state estimate (pose, position, or occupancy)
|
||||
|
||||
1. PREPROCESSING (physics-guided):
|
||||
a. Remove carrier frequency offset (CFO): H_clean = H * exp(-j*2*pi*delta_f*t)
|
||||
b. Conjugate multiply across antenna pairs to cancel common phase noise
|
||||
c. Compute CSI-ratio: H_ratio(f,t) = H_dynamic(f,t) / H_static(f,t)
|
||||
|
||||
2. PHYSICS ENCODER:
|
||||
a. Embed Fresnel zone geometry as positional encoding
|
||||
b. Apply multi-head attention with frequency-aware kernels
|
||||
c. Enforce causality: attention mask respects propagation delay ordering
|
||||
|
||||
3. PHYSICS-CONSTRAINED DECODER:
|
||||
a. Predict body state x_hat
|
||||
b. Forward-simulate expected CSI from x_hat using ray-tracing differentiable renderer
|
||||
c. Compute physics loss: L_phys = ||H_simulated(x_hat) - H_measured||^2
|
||||
|
||||
4. TRAINING LOSS:
|
||||
L = L_pose_supervision + alpha * L_phys + beta * L_temporal_smoothness
|
||||
```
|
||||
|
||||
### 2.4 Relevance to wifi-densepose
|
||||
|
||||
Our RuvSense pipeline already implements physics-guided preprocessing (phase alignment, coherence gating, Fresnel zone awareness). The next step would be to:
|
||||
|
||||
1. Add a differentiable ray-tracing forward model as a physics constraint during NN training
|
||||
2. Use the field model eigenstructure (from `field_model.rs`) as an informed prior
|
||||
3. Embed Fresnel zone geometry from link topology as architectural bias
|
||||
|
||||
|
||||
## 3. Inverse Electromagnetic Scattering for Body Reconstruction
|
||||
|
||||
### 3.1 The Inverse Problem
|
||||
|
||||
The forward problem: given a known body position/shape and room geometry, predict the CSI.
|
||||
|
||||
```
|
||||
Forward: body_state -> Maxwell/ray-tracing -> H(f,t) [well-posed]
|
||||
Inverse: H(f,t) -> ??? -> body_state [ill-posed]
|
||||
```
|
||||
|
||||
WiFi sensing is fundamentally an inverse scattering problem. A WiFi antenna receives signal as 1D amplitude/phase -- the spatial information of the 3D scene is collapsed to a single CSI complex number per subcarrier per antenna pair. Reconstructing fine-grained spatial information from this compressed observation is severely ill-posed.
|
||||
|
||||
### 3.2 Linearized Inverse Scattering: Born and Rytov Approximations
|
||||
|
||||
**Helmholtz equation with scatterer:**
|
||||
|
||||
```
|
||||
nabla^2 E(r) + k^2 * (1 + O(r)) * E(r) = 0
|
||||
```
|
||||
|
||||
where `O(r) = epsilon_r(r) - 1` is the object function (dielectric contrast of the body relative to free space).
|
||||
|
||||
**Born approximation** (first-order): Assumes the field inside the scatterer equals the incident field:
|
||||
|
||||
```
|
||||
E_scattered(r) ~ k^2 * integral O(r') * E_incident(r') * G(r, r') dr'
|
||||
```
|
||||
|
||||
where `G(r, r')` is the free-space Green's function. This is valid when `O(r)` is small and the object is electrically small. For the human body at 2.4 GHz (`epsilon_r ~ 40-60` for muscle tissue), the Born approximation is grossly violated.
|
||||
|
||||
**Rytov approximation**: Expands the complex phase rather than the field:
|
||||
|
||||
```
|
||||
E_total(r) = E_incident(r) * exp(psi(r))
|
||||
|
||||
psi(r) ~ (k^2 / E_incident(r)) * integral O(r') * E_incident(r') * G(r, r') dr'
|
||||
```
|
||||
|
||||
The Rytov approximation handles larger phase accumulation than Born but still assumes weak scattering. It works better for lossy media where absorption limits multiple scattering.
|
||||
|
||||
**Extended Phaseless Rytov Approximation (xPRA-LM)** (Dubey et al., arXiv 2110.03211):
|
||||
- First linear phaseless inverse scattering approximation with large validity range
|
||||
- Demonstrated with 2.4 GHz WiFi nodes for indoor imaging
|
||||
- Handles objects with `epsilon_r` up to 15+j1.5 (20x wavelength size)
|
||||
- At `epsilon_r = 77+j7` (water/tissue), shape reconstruction still accurate
|
||||
|
||||
### 3.3 Iterative Nonlinear Methods
|
||||
|
||||
For high-contrast scatterers like the human body, iterative methods are required:
|
||||
|
||||
**Distorted Born Iterative Method (DBIM):**
|
||||
|
||||
```
|
||||
Algorithm: DBIM for WiFi Body Imaging
|
||||
|
||||
Input: Measured scattered field E_s at receiver locations
|
||||
Output: Object function O(r) (dielectric map of scene)
|
||||
|
||||
1. Initialize: O_0(r) = 0 (empty room)
|
||||
2. For iteration i = 0, 1, 2, ...:
|
||||
a. Solve forward problem: compute total field E_i(r) in medium with O_i(r)
|
||||
b. Compute Green's function G_i(r, r') for medium O_i(r)
|
||||
c. Linearize: delta_E_s = K_i * delta_O (Frechet derivative)
|
||||
d. Solve: delta_O = K_i^+ * (E_s_measured - E_s_computed(O_i))
|
||||
e. Update: O_{i+1} = O_i + delta_O
|
||||
f. Check convergence: ||E_s_measured - E_s_computed(O_{i+1})|| < epsilon
|
||||
```
|
||||
|
||||
**Challenges for WiFi sensing:**
|
||||
- WiFi provides sparse spatial sampling (few antenna pairs vs. full aperture)
|
||||
- Phase is often unavailable (RSSI-only) or corrupted by hardware imperfections
|
||||
- Real-time requirement conflicts with iterative forward solves
|
||||
- Human body is a strong, moving scatterer
|
||||
|
||||
### 3.4 Radio Tomographic Imaging (RTI)
|
||||
|
||||
RTI (Wilson & Patwari, 2010) simplifies the inverse scattering problem by:
|
||||
1. Using only RSS (received signal strength) -- phaseless
|
||||
2. Assuming a voxelized scene with additive attenuation model
|
||||
3. Linearizing: measured attenuation = sum of voxel attenuations along path
|
||||
|
||||
**Forward model:**
|
||||
|
||||
```
|
||||
y = W * x + n
|
||||
|
||||
where:
|
||||
y = [y_1, ..., y_L]^T attenuation measurements (L links)
|
||||
x = [x_1, ..., x_V]^T voxel occupancy values (V voxels)
|
||||
W = [w_{l,v}] weight matrix (link-voxel intersection)
|
||||
n = measurement noise
|
||||
```
|
||||
|
||||
**Weight model (elliptical):**
|
||||
|
||||
```
|
||||
w_{l,v} = { 1 / sqrt(d_l) if d_{l,v}^tx + d_{l,v}^rx < d_l + lambda_w
|
||||
{ 0 otherwise
|
||||
|
||||
where:
|
||||
d_l = distance between TX_l and RX_l
|
||||
d_{l,v}^tx = distance from TX_l to voxel v center
|
||||
d_{l,v}^rx = distance from RX_l to voxel v center
|
||||
lambda_w = excess path length parameter (typically ~lambda/4)
|
||||
```
|
||||
|
||||
**Inverse solution (Tikhonov-regularized):**
|
||||
|
||||
```
|
||||
x_hat = (W^T W + alpha * C^{-1})^{-1} * W^T * y
|
||||
```
|
||||
|
||||
where `C` is the spatial covariance matrix and `alpha` controls regularization.
|
||||
|
||||
**Our implementation** (`tomography.rs`) uses ISTA (Iterative Shrinkage-Thresholding Algorithm) with L1 regularization for sparsity:
|
||||
|
||||
```
|
||||
Algorithm: ISTA for RF Tomography (as in tomography.rs)
|
||||
|
||||
Input: Weight matrix W, observations y, lambda (L1 weight)
|
||||
Output: Sparse voxel densities x
|
||||
|
||||
1. Initialize x = 0
|
||||
2. step_size = 1 / ||W^T * W||_spectral
|
||||
3. For iter = 1 to max_iterations:
|
||||
a. gradient = W^T * (W * x - y)
|
||||
b. x_candidate = x - step_size * gradient
|
||||
c. x = soft_threshold(x_candidate, lambda * step_size)
|
||||
where soft_threshold(z, t) = sign(z) * max(|z| - t, 0)
|
||||
d. residual = ||W * x - y||
|
||||
e. if residual < tolerance: break
|
||||
```
|
||||
|
||||
### 3.5 Reconciling RTI with Inverse Scattering
|
||||
|
||||
Dubey, Li & Murch (arXiv 2311.09633) reconciled empirical RTI with formal inverse scattering theory:
|
||||
- RTI's additive attenuation model corresponds to a first-order Born approximation of the scattered field amplitude
|
||||
- Their enhanced method reconstructs both shape AND material properties
|
||||
- Validated at 2.4 GHz with WiFi transceivers indoors
|
||||
|
||||
### 3.6 State-of-the-Art: Deep Learning Approaches
|
||||
|
||||
**DensePose From WiFi** (Geng, Huang, De la Torre, arXiv 2301.00250, CMU):
|
||||
- Maps WiFi CSI amplitude+phase to UV coordinates across 24 body regions
|
||||
- Uses 3 TX + 3 RX antennas, 56 subcarriers per link
|
||||
- Teacher-student training: camera-based DensePose provides labels
|
||||
- Performance comparable to image-based approaches
|
||||
- Works through walls and in darkness
|
||||
|
||||
**RF-Pose** (Zhao et al., CVPR 2018, MIT CSAIL):
|
||||
- Through-wall human pose estimation using radio signals
|
||||
- Cross-modal supervision: vision model trains RF model
|
||||
- Generalizes to through-wall scenarios with no through-wall training data
|
||||
|
||||
**Person-in-WiFi** (Wang et al., ICCV 2019, CMU):
|
||||
- End-to-end body segmentation and pose from WiFi
|
||||
- Standard 802.11n signals, off-the-shelf hardware
|
||||
|
||||
**3D WiFi Pose Estimation** (arXiv 2204.07878):
|
||||
- Free-form and moving activities
|
||||
- 3D joint position estimation from CSI
|
||||
|
||||
**HoloCSI** (2025-2026):
|
||||
- Holographic tomography pipeline coupling physics-guided projection with adaptive top-k sparse transformer
|
||||
- Preprocesses: CFO rectification, Doppler compensation, antenna-pair normalization
|
||||
- Sparse multi-head attention prunes low-magnitude query-key pairs (quadratic -> near-linear complexity)
|
||||
- Results: +2.9 dB PSNR, +3.6% SSIM, +12.4% mesh IoU vs baselines
|
||||
- 25 fps on RTX-4070-mobile at 5% sparsity; 7 fps on Raspberry Pi 5 with attention-GRU variant
|
||||
|
||||
|
||||
## 4. Computational Electromagnetics for WiFi Sensing
|
||||
|
||||
### 4.1 FDTD (Finite-Difference Time-Domain)
|
||||
|
||||
FDTD discretizes Maxwell's curl equations on a Yee grid and marches forward in time:
|
||||
|
||||
```
|
||||
Algorithm: FDTD Update (2D TM mode, simplified)
|
||||
|
||||
Grid: dx = dy = lambda/20 (minimum 10 cells per wavelength)
|
||||
Time step: dt = dx / (c * sqrt(2)) [Courant condition]
|
||||
|
||||
For each time step n:
|
||||
1. Update H fields:
|
||||
H_z^{n+1/2}(i,j) = H_z^{n-1/2}(i,j) + (dt/mu_0) * [
|
||||
(E_x^n(i,j+1) - E_x^n(i,j)) / dy -
|
||||
(E_y^n(i+1,j) - E_y^n(i,j)) / dx
|
||||
]
|
||||
|
||||
2. Update E fields:
|
||||
E_x^{n+1}(i,j) = E_x^n(i,j) + (dt / epsilon(i,j)) * [
|
||||
(H_z^{n+1/2}(i,j) - H_z^{n+1/2}(i,j-1)) / dy
|
||||
]
|
||||
```
|
||||
|
||||
**For WiFi at 2.4 GHz:**
|
||||
- Wavelength: 12.5 cm
|
||||
- Grid cell: ~6 mm (20 cells/lambda)
|
||||
- Room 6m x 6m x 3m: 1000 x 1000 x 500 = 500M cells
|
||||
- Memory: ~24 GB (6 field components * 4 bytes * 500M)
|
||||
- Time steps: ~10,000 for steady state
|
||||
|
||||
**Key references for WiFi FDTD:**
|
||||
- Lauer & Ertel (2003), "Using Large-Scale FDTD for Indoor WLAN" -- Full FDTD at 2.45 GHz in office environments
|
||||
- Lui et al. (2018), "Human Body Shadowing" -- FDTD human body model for ray-tracing calibration (Hindawi IJAP 9084830)
|
||||
- Martinez-Gonzalez et al. (2008), "FDTD Assessment Human Exposure WiFi/Bluetooth" -- SAR computation with anatomical body models
|
||||
|
||||
**Practical limitations**: FDTD is too slow for real-time sensing but valuable for:
|
||||
- Generating training data for neural networks
|
||||
- Validating approximate models
|
||||
- Understanding near-field body-wave interaction
|
||||
|
||||
### 4.2 Method of Moments (MoM)
|
||||
|
||||
MoM converts Maxwell's integral equations into matrix equations by expanding fields in basis functions:
|
||||
|
||||
```
|
||||
[Z] * [I] = [V]
|
||||
|
||||
where:
|
||||
Z_{mn} = integral integral G(r_m, r_n) * f_m(r) * f_n(r') dS dS'
|
||||
I_n = unknown current coefficients
|
||||
V_m = incident field excitation
|
||||
```
|
||||
|
||||
**Application**: MoM excels for antenna analysis and is used to model WiFi antenna patterns. Less practical for full room simulation due to O(N^2) memory and O(N^3) solve time.
|
||||
|
||||
### 4.3 FEM (Finite Element Method)
|
||||
|
||||
FEM handles complex geometries and material interfaces more naturally than FDTD:
|
||||
|
||||
```
|
||||
Weak form of Helmholtz equation:
|
||||
integral nabla x E_test . (1/mu_r * nabla x E) dV - k_0^2 * integral E_test . epsilon_r * E dV
|
||||
= -j * omega * integral E_test . J_s dV
|
||||
```
|
||||
|
||||
**Application**: HFSS (Ansys) and COMSOL use FEM for electromagnetic simulation. Arena Physica's Heaviside-0 model was trained against such commercial FEM solvers.
|
||||
|
||||
### 4.4 Comparison for WiFi Sensing Applications
|
||||
|
||||
| Method | Speed | Accuracy | Body Modeling | Room Scale | Real-Time |
|
||||
|---|---|---|---|---|---|
|
||||
| FDTD | Hours | Full-wave exact | Excellent | Feasible (GPU) | No |
|
||||
| MoM | Hours | Exact for surfaces | Good (surface) | Impractical | No |
|
||||
| FEM | Hours | Exact | Excellent | Feasible | No |
|
||||
| Ray tracing | Seconds | GO/UTD approximation | Coarse | Easy | Near real-time |
|
||||
| RTI (ISTA) | Milliseconds | Linear approximation | Voxelized | Easy | Yes |
|
||||
| Neural surrogate | Milliseconds | Trained accuracy | Implicit | Trained domain | Yes |
|
||||
|
||||
### 4.5 Hybrid Approaches: Neural Surrogates Trained on CEM
|
||||
|
||||
The most promising direction combines full-wave accuracy with real-time speed:
|
||||
|
||||
1. **Offline**: Run thousands of FDTD/FEM simulations with different body positions
|
||||
2. **Train**: Neural network learns the mapping from body state to CSI
|
||||
3. **Deploy**: Neural surrogate runs in milliseconds for real-time inference
|
||||
|
||||
This is exactly Arena Physica's approach (Section 5), applied to RF component design rather than sensing. The same methodology applies to WiFi sensing: train a neural forward model on FDTD data, then use it as a differentiable physics constraint during inverse model training.
|
||||
|
||||
|
||||
## 5. Arena Physica's Approach
|
||||
|
||||
### 5.1 Company Overview
|
||||
|
||||
Arena Physica (arena-ai.com / arenaphysica.com) pursues "Electromagnetic Superintelligence" -- building foundation models that develop superhuman intuition for how geometry shapes electromagnetic fields. Founded by Pratap Ranade (CEO), Arya Hezarkhani, Claire Pan, Michael Frei, and Harish Krishnaswamy. Offices in NYC (HQ), SF, LA.
|
||||
|
||||
Raised $30M Series B (April 2025). Deployed with AMD, Anduril Industries, Sivers Semiconductors, Bausch & Lomb. Claims 35% reduction in engineering man-hours and multi-month acceleration in time-to-market.
|
||||
|
||||
### 5.2 Technical Architecture
|
||||
|
||||
Arena's Atlas platform uses two foundation models:
|
||||
|
||||
**Heaviside-0 (Forward Model)**:
|
||||
- Input: PCB/RF geometry (discretized as grid)
|
||||
- Output: S-parameters (magnitude + phase) and field distributions
|
||||
- Speed: 13ms per design (single), 0.3ms batched
|
||||
- Comparison: Traditional solver (HFSS/FDTD) takes ~4 minutes
|
||||
- Speedup: 18,000x to 800,000x
|
||||
|
||||
**Marconi-0 (Inverse Model)**:
|
||||
- Input: Target S-parameter specification
|
||||
- Output: Physical geometry that achieves the specification
|
||||
- Method: Conditional diffusion process (similar to image generation)
|
||||
- Generates unconventional geometries no human designer would conceive
|
||||
|
||||
**Training data**: 3 million simulated designs across 25 expert templates + random structures, totaling 20+ years of combined simulation time. Incorporates both S-parameter data and electromagnetic field distributions.
|
||||
|
||||
**Validation**: Predictions validated against commercial numerical field solvers (likely HFSS). Internal testing shows < 1 dB magnitude-weighted MAE (RF engineers operate in 20-30 dB ranges).
|
||||
|
||||
### 5.3 Relationship to Maxwell's Equations
|
||||
|
||||
Arena does NOT solve Maxwell's equations directly. Instead:
|
||||
|
||||
1. **Training phase**: Maxwell's equations are solved by conventional solvers (FDTD/FEM/MoM) millions of times to generate training data
|
||||
2. **Inference phase**: Neural surrogate approximates Maxwell's solutions in milliseconds
|
||||
3. **Design loop**: Generator proposes geometry -> Evaluator predicts EM behavior -> Iterate
|
||||
|
||||
As Pratap Ranade states: the model "learns the syntax of physics" inductively from examples, rather than deductively from equations. This trades precision for speed -- acceptable when searching design space where "speed and direction matter more than precision."
|
||||
|
||||
### 5.4 The "Large Field Model" (LFM) Concept
|
||||
|
||||
Arena's LFM is distinct from Large Language Models:
|
||||
- LLMs learn linguistic patterns from text
|
||||
- LFMs learn electromagnetic field patterns from simulation data
|
||||
- The input is geometry (not text); the output is field distributions (not tokens)
|
||||
- Domain-specific architecture substantially outperforms general LLMs on EM tasks
|
||||
|
||||
### 5.5 Relevance to WiFi Sensing
|
||||
|
||||
Arena Physica focuses on RF component design (antennas, PCBs, filters), not WiFi sensing. However, their approach is directly transferable:
|
||||
|
||||
| Arena Physica (Design) | WiFi Sensing (Our Case) |
|
||||
|---|---|
|
||||
| Forward: geometry -> S-parameters | Forward: body pose -> CSI |
|
||||
| Inverse: S-parameters -> geometry | Inverse: CSI -> body pose |
|
||||
| Train on FDTD/FEM simulations | Train on ray-tracing / FDTD simulations |
|
||||
| 13ms inference | Real-time CSI inference |
|
||||
| Conditional diffusion for generation | Conditional generation for pose prediction |
|
||||
|
||||
**Key lesson for wifi-densepose**: Building a neural forward model (body_pose -> expected_CSI) trained on electromagnetic simulation data, then using it as a differentiable physics constraint during inverse model training, could significantly improve our pose estimation accuracy and generalization. This is the "physics-informed" approach with the computational burden shifted to offline training.
|
||||
|
||||
|
||||
## 6. Connections to wifi-densepose Codebase
|
||||
|
||||
### 6.1 Existing Physics-Based Modules
|
||||
|
||||
| Module | Physical Model | Maxwell Connection |
|
||||
|---|---|---|
|
||||
| `field_model.rs` | SVD eigenstructure decomposition | Eigenmode basis of room's EM field |
|
||||
| `tomography.rs` | L1-regularized RTI (ISTA solver) | Linearized inverse scattering |
|
||||
| `multistatic.rs` | Attention-weighted cross-node fusion | Exploits geometric diversity of multiple TX/RX |
|
||||
| `phase_align.rs` | LO phase offset estimation | Corrects hardware-induced phase corruption |
|
||||
| `coherence.rs` | Z-score coherence scoring | Statistical test on EM field stability |
|
||||
| `coherence_gate.rs` | Accept/Reject decisions | Quality control on EM measurements |
|
||||
| `adversarial.rs` | Physical impossibility detection | Enforces EM consistency constraints |
|
||||
|
||||
### 6.2 Potential Enhancements Based on This Research
|
||||
|
||||
1. **Differentiable ray-tracing forward model**: Train a neural surrogate on ray-tracing simulations of CSI for various body poses in the deployment room. Use as physics constraint in pose estimation.
|
||||
|
||||
2. **Fresnel zone integration**: Augment the attention mechanism in `multistatic.rs` with Fresnel zone geometry -- links where the body falls within the first Fresnel zone should receive higher attention weight.
|
||||
|
||||
3. **xPRA-LM inverse scattering**: For higher-resolution body imaging than RTI, implement the Extended Phaseless Rytov Approximation. Our tomography module currently uses the simpler additive attenuation model.
|
||||
|
||||
4. **HoloCSI-style sparse transformer**: Replace the dense attention in cross-viewpoint fusion with top-k sparse attention for efficiency on ESP32-constrained deployments.
|
||||
|
||||
5. **Physics-informed training loss**: When training the DensePose model, add a loss term penalizing physically impossible CSI patterns (e.g., signals that would require faster-than-light propagation or negative attenuation).
|
||||
|
||||
|
||||
## 7. References
|
||||
|
||||
### Core WiFi Sensing Surveys
|
||||
- WiFi Sensing with Channel State Information: A Survey. ACM Computing Surveys, 2019. https://dl.acm.org/doi/fullHtml/10.1145/3310194
|
||||
- Cross-Domain WiFi Sensing with Channel State Information: A Survey. ACM Computing Surveys, 2022. https://dl.acm.org/doi/10.1145/3570325
|
||||
- Wireless sensing applications with Wi-Fi CSI, preprocessing techniques, and detection algorithms: A survey. Computer Communications, 2024. https://www.sciencedirect.com/science/article/abs/pii/S0140366424002214
|
||||
- Understanding CSI (Tsinghua Tutorial). https://tns.thss.tsinghua.edu.cn/wst/docs/pre/
|
||||
|
||||
### Physics-Informed Neural Networks for RF
|
||||
- PINN and GNN-based RF Map Construction. arXiv 2507.22513
|
||||
- Physics-Informed Neural Networks for Wireless Channel Estimation. NeurIPS 2025, OpenReview r3plaU6DvW
|
||||
- ReVeal: High-Fidelity Radio Propagation. DySPAN 2025. https://wici.iastate.edu/wp-content/uploads/2025/03/ReVeal-DySPAN25.pdf
|
||||
- Physics-informed generative model for passive RF sensing. Savazzi et al., arXiv 2310.04173
|
||||
- Multi-Modal Foundational Model for Wireless Communication and Sensing. arXiv 2602.04016
|
||||
- Generative AI Meets Wireless Sensing: Towards Wireless Foundation Model. arXiv 2509.15258
|
||||
- Physics-Informed Neural Networks for Sensing Radio Spectrum. IJRTE v14i3, 2025
|
||||
|
||||
### Inverse Scattering and Body Reconstruction
|
||||
- DensePose From WiFi. Geng, Huang, De la Torre. arXiv 2301.00250
|
||||
- Through-Wall Human Pose Estimation Using Radio Signals. Zhao et al., CVPR 2018. https://rfpose.csail.mit.edu/
|
||||
- Person-in-WiFi: Fine-grained Person Perception. Wang et al., ICCV 2019
|
||||
- 3D Human Pose Estimation for Free-from Activities Using WiFi. arXiv 2204.07878
|
||||
- EM-POSE: 3D Human Pose from Sparse Electromagnetic Trackers. ICCV 2021
|
||||
- Reconciling Radio Tomographic Imaging with Phaseless Inverse Scattering. Dubey, Li, Murch. arXiv 2311.09633
|
||||
- Accurate Indoor RF Imaging using Extended Rytov Approximation. Dubey et al., arXiv 2110.03211
|
||||
- Phaseless Extended Rytov Approximation for Strongly Scattering Low-Loss Media. IEEE, 2022. https://ieeexplore.ieee.org/document/9766313/
|
||||
- Distorted Wave Extended Phaseless Rytov Iterative Method. arXiv 2205.12578
|
||||
- 3D Full Convolution Electromagnetic Reconstruction Neural Network (3D-FCERNN). PMC 9689780
|
||||
|
||||
### Radio Tomographic Imaging
|
||||
- Radio Tomographic Imaging with Wireless Networks. Wilson & Patwari, 2010. https://span.ece.utah.edu/uploads/RTI_version_3.pdf
|
||||
- Compressive Sensing Based Radio Tomographic Imaging with Spatial Diversity. PMC 6386865
|
||||
- Passive Localization Based on Radio Tomography Images with CNN. Nature Scientific Reports, 2025
|
||||
- Enhancing Accuracy of WiFi Tomographic Imaging Using Human-Interference Model. 2018
|
||||
|
||||
### Fresnel Zone Models
|
||||
- WiFi CSI-based device-free sensing: from Fresnel zone model to CSI-ratio model. CCF Trans. Pervasive Computing, 2021. https://link.springer.com/article/10.1007/s42486-021-00077-z
|
||||
- Towards a Dynamic Fresnel Zone Model for WiFi-based Human Activity Recognition. ACM IMWUT, 2023. https://dl.acm.org/doi/10.1145/3596270
|
||||
- CSI-based human sensing using model-based approaches: a survey. JCDE, 2021. https://academic.oup.com/jcde/article/8/2/510/6137731
|
||||
|
||||
### Computational Electromagnetics
|
||||
- Using Large-Scale FDTD for Indoor WLAN. ResearchGate. https://www.researchgate.net/publication/42637096
|
||||
- Human Body Shadowing -- FDTD and UTD. Hindawi IJAP, 2018. https://www.hindawi.com/journals/ijap/2018/9084830/
|
||||
- FDTD Assessment Human Exposure WiFi/Bluetooth. ResearchGate. https://www.researchgate.net/publication/23400115
|
||||
- Simulation of Wireless LAN Indoor Propagation Using FDTD. IEEE, 2007. https://ieeexplore.ieee.org/document/4396450
|
||||
- Waveguide Models of Indoor Channels: FDTD Insights. ResearchGate. https://www.researchgate.net/publication/4368711
|
||||
- XFdtd 3D EM Simulation Software. Remcom. https://www.remcom.com/xfdtd-3d-em-simulation-software
|
||||
- Wireless InSite Ray Tracing. Remcom. https://www.remcom.com/wireless-insite-em-propagation-software/
|
||||
|
||||
### Arena Physica
|
||||
- Introducing Atlas RF Studio. https://www.arenaphysica.com/publications/rf-studio
|
||||
- Electromagnetism Secretly Runs the World. Not Boring (Packy McCormick). https://www.notboring.co/p/electromagnetism-secretly-runs-the
|
||||
- Arena Launches Atlas (Press Release). https://www.prnewswire.com/news-releases/arena-launches-atlas-to-accelerate-humanitys-rate-of-hardware-innovation-302423412.html
|
||||
- Arena AI raises $30M. SiliconANGLE. https://siliconangle.com/2025/04/08/arena-ai-raises-30m-accelerate-innovation-hardware-testing-atlas/
|
||||
- Artificial Intuition: Building an AI Mind for EM Design. CDFAM NYC 2025. https://www.designforam.com/p/artificial-intuition-building-an
|
||||
|
||||
### Holographic / Advanced
|
||||
- HoloCSI: Holographic tomography pipeline with physics-guided projection and sparse transformer. 2025-2026
|
||||
- CSI-Bench: Large-Scale In-the-Wild Dataset for Multi-task WiFi Sensing. arXiv 2505.21866
|
||||
- RFBoost: Understanding and Boosting Deep WiFi Sensing via Physical Data Augmentation. arXiv 2410.07230
|
||||
- Vision Reimagined: AI-Powered Breakthroughs in WiFi Indoor Imaging. arXiv 2401.04317
|
||||
- Electromagnetic Information Theory for 6G. arXiv 2401.08921
|
||||
@@ -1,341 +0,0 @@
|
||||
# SOTA WiFi Sensing for Edge Pose Estimation (2024-2026 Update)
|
||||
|
||||
**Date:** 2026-04-02
|
||||
**Focus:** New architectures, lightweight models, edge deployment, ESP32+Pi Zero inference
|
||||
**Complements:** `wifi-sensing-ruvector-sota-2026.md` (February 2026 survey)
|
||||
|
||||
---
|
||||
|
||||
## 1. New Architectures Since Last Survey
|
||||
|
||||
### 1.1 WiFlow: Lightweight Continuous Pose Estimation (February 2026)
|
||||
|
||||
**Paper:** WiFlow: A Lightweight WiFi-based Continuous Human Pose Estimation Network with Spatio-Temporal Feature Decoupling ([arXiv:2602.08661](https://arxiv.org/html/2602.08661))
|
||||
|
||||
WiFlow is the most directly relevant architecture for our ESP32 + Pi Zero deployment target.
|
||||
|
||||
#### Architecture
|
||||
|
||||
Three-stage encoder-decoder with spatio-temporal decoupling:
|
||||
|
||||
**Stage 1: Temporal Encoder (TCN)**
|
||||
- Dilated causal convolution with exponentially growing dilation factors (1, 2, 4, 8)
|
||||
- Input: 540x20 tensor (18 antenna links x 30 subcarriers = 540 features, 20 time steps)
|
||||
- Progressive channel compression: 540 -> 440 -> 340 -> 240
|
||||
- Preserves temporal causality while achieving full receptive field coverage
|
||||
|
||||
**Stage 2: Spatial Encoder (Asymmetric Convolution)**
|
||||
- 1xk kernels operating only in the subcarrier dimension
|
||||
- 4 residual blocks: 8 -> 16 -> 32 -> 64 channels
|
||||
- Subcarrier compression: 240 -> 120 -> 60 -> 30 -> 15
|
||||
- Stride (1,2) downsampling -- no pooling layers
|
||||
|
||||
**Stage 3: Axial Self-Attention**
|
||||
- Two-stage axial attention reduces complexity from O(H^2 W^2) to O(H^2 W + HW^2)
|
||||
- Stage one: width direction (temporal axis), 8 groups
|
||||
- Stage two: height direction (keypoint axis)
|
||||
- Input reshaped to (B x K) x C x T for first stage
|
||||
|
||||
**Decoder:**
|
||||
- Adaptive average pooling instead of fully connected layers
|
||||
- Direct coordinate regression to 2D keypoint positions
|
||||
|
||||
#### Key Metrics
|
||||
|
||||
| Metric | WiFlow | WPformer | WiSPPN |
|
||||
|--------|--------|----------|--------|
|
||||
| Parameters | **4.82M** | 10.04M | 121.5M |
|
||||
| FLOPs | **0.47B** | 35.00B | 338.45B |
|
||||
| PCK@20 (random split) | **97.00%** | 70.02% | 85.87% |
|
||||
| MPJPE (random split) | **0.008m** | 0.028m | 0.016m |
|
||||
| PCK@20 (cross-subject) | **86.89%** | -- | -- |
|
||||
| Training time (5-fold) | **18.17h** | 137.5h | -- |
|
||||
|
||||
**Critical observations for our project:**
|
||||
- 4.82M parameters at INT8 quantization = ~4.8 MB model size -- fits in Pi Zero 2 W RAM (512 MB)
|
||||
- 0.47B FLOPs suggests ~50ms inference on Cortex-A53 with NEON SIMD (estimated)
|
||||
- Only uses amplitude, discards phase (phase is "heavily corrupted by CFO and SFO in commercial WiFi devices")
|
||||
- ESP32-S3 CSI has similar CFO/SFO issues, so amplitude-only approach is pragmatic
|
||||
|
||||
**Loss function:**
|
||||
```
|
||||
L = L_H + lambda * L_B
|
||||
L_H = SmoothL1(predicted_keypoints, ground_truth, beta=0.1)
|
||||
L_B = sum of bone length constraint violations across 14 bone connections
|
||||
lambda = 0.2
|
||||
```
|
||||
|
||||
The bone constraint loss is particularly important for edge deployment where noisy predictions need physical plausibility enforcement.
|
||||
|
||||
#### Adaptation for ESP32 + Pi Zero
|
||||
|
||||
WiFlow's architecture maps well to our hardware:
|
||||
- TCN runs on ESP32 (temporal feature extraction from raw CSI stream)
|
||||
- Asymmetric conv + axial attention runs on Pi Zero (spatial encoding + pose regression)
|
||||
- The 540-dimensional input assumes Intel 5300 NIC (18 links x 30 subcarriers); for ESP32-S3 with 1 TX x 1 RX and 52 subcarriers, input dimension is 52x20 = 1040 -- even smaller
|
||||
|
||||
### 1.2 MultiFormer: Multi-Person WiFi Pose (May 2025)
|
||||
|
||||
**Paper:** MultiFormer: A Multi-Person Pose Estimation System Based on CSI and Attention Mechanism ([arXiv:2505.22555](https://arxiv.org/html/2505.22555v1))
|
||||
|
||||
#### Architecture
|
||||
|
||||
Teacher-student framework with OpenPose teacher providing ground truth labels.
|
||||
|
||||
**Time-Frequency Dual-Dimensional Tokenization (TFDDT):**
|
||||
- Input: CSI matrix from 1 TX, 3 RX, 30 subcarriers
|
||||
- Upsampled via zero-insertion + low-pass filtering to 64x3x64
|
||||
- Two parallel token streams:
|
||||
- Frequency tokens F_j: N_S tokens of length M x N_R (subcarrier-centric view)
|
||||
- Temporal tokens T_i: M tokens of length N_S x N_R (time-centric view)
|
||||
|
||||
**Dual Transformer Encoder:**
|
||||
- 8 layers per branch (frequency and temporal)
|
||||
- Multi-head self-attention: MSA(X) = (1/H) * sum(Softmax(QK^T / sqrt(d_k)) V)
|
||||
- Each branch followed by FFN with ReLU, dropout, residual connections
|
||||
|
||||
**Multi-Stage Pose Estimation:**
|
||||
- Part Confidence Maps (PCM): 19x36x36 heatmaps (18 keypoints + average)
|
||||
- Part Affinity Fields (PAF): 38x36x36 directional fields for 19 limb connections
|
||||
- Pose-Attentive Perception Module (PAPM): channel + spatial attention on PCM/PAF
|
||||
- Multi-person assignment via Hungarian algorithm on PAF integrals
|
||||
|
||||
#### Model Variants
|
||||
|
||||
| Variant | Encoder Layers | Input | Parameters |
|
||||
|---------|---------------|-------|------------|
|
||||
| MultiFormer | 8 | 64x1296 | 11.93M |
|
||||
| MultiFormer-24 | 8 | 64x576 | 4.05M |
|
||||
| MultiFormer-18 | 6 | 64x324 | **2.80M** |
|
||||
|
||||
**Key result on MM-Fi dataset:** MultiFormer achieves PCK@20 of 0.7225, outperforming CSI2Pose (0.6841). The compact MultiFormer-18 at 2.80M parameters is edge-deployable.
|
||||
|
||||
#### Relevance to Our Project
|
||||
|
||||
MultiFormer's dual-token approach is valuable because:
|
||||
1. It explicitly separates temporal and frequency information (like WiFlow's decoupling)
|
||||
2. The PAF-based multi-person assignment using Hungarian algorithm can run on Pi Zero
|
||||
3. The 2.80M parameter variant (MultiFormer-18) at INT8 = ~2.8 MB, well within Pi Zero constraints
|
||||
|
||||
### 1.3 Person-in-WiFi 3D (CVPR 2024)
|
||||
|
||||
**Paper:** Person-in-WiFi 3D: End-to-End Multi-Person 3D Pose Estimation with Wi-Fi (CVPR 2024)
|
||||
|
||||
First multi-person 3D WiFi pose estimation.
|
||||
|
||||
**Key results:**
|
||||
- Single person MPJPE: 91.7mm
|
||||
- Two persons: 108.1mm
|
||||
- Three persons: 125.3mm
|
||||
- Dataset: 97K frames, 4m x 3.5m area, 7 volunteers
|
||||
- Transformer-based end-to-end architecture
|
||||
|
||||
**Relevance:** Establishes the accuracy ceiling for WiFi 3D pose. Our ESP32+Pi system should target comparable single-person performance (sub-100mm MPJPE) as a milestone.
|
||||
|
||||
### 1.4 Spatio-Temporal 3D Point Clouds from WiFi-CSI (October 2024)
|
||||
|
||||
**Paper:** [arXiv:2410.16303](https://arxiv.org/html/2410.16303v1)
|
||||
|
||||
Novel approach: generates 3D point clouds from WiFi CSI data using transformer networks.
|
||||
|
||||
**Key innovation:** Positional encoding with learned embeddings for antennas and subcarriers, followed by multi-head attention over antenna-subcarrier pairs. This captures both spatial (antenna geometry) and spectral (subcarrier frequency response) dependencies.
|
||||
|
||||
**Relevance:** Point cloud output is a richer representation than keypoints alone, enabling:
|
||||
- Silhouette estimation for activity recognition
|
||||
- Body volume estimation for person identification
|
||||
- Occlusion reasoning when fused with multiple viewpoints
|
||||
|
||||
### 1.5 Graph-Based 3D Human Pose from WiFi (November 2025)
|
||||
|
||||
**Paper:** Graph-based 3D Human Pose Estimation using WiFi Signals ([arXiv:2511.19105](https://arxiv.org/html/2511.19105))
|
||||
|
||||
Uses graph neural networks where nodes represent keypoints and edges represent skeletal connections. CSI features are injected as node/edge attributes.
|
||||
|
||||
**Relevance:** Graph structure naturally maps to our RuvSense pose_tracker which already maintains a 17-keypoint skeleton with Kalman filtering. Adding graph-based message passing between keypoints could improve joint prediction coherence.
|
||||
|
||||
## 2. Edge Deployment Landscape
|
||||
|
||||
### 2.1 CSI-Sense-Zero: ESP32 + Pi Zero Reference Implementation
|
||||
|
||||
**Repository:** [github.com/winwinashwin/CSI-Sense-Zero](https://github.com/winwinashwin/CSI-Sense-Zero)
|
||||
|
||||
The most directly relevant prior art for our hardware target.
|
||||
|
||||
**Architecture:**
|
||||
- Two ESP32-WROOM-32: one TX, one RX (captures CSI)
|
||||
- Pi Zero: inference node
|
||||
- Communication: USB serial at 921,600 baud
|
||||
- Buffer: 235KB FIFO at `/tmp/csififo` (~256 CSI records)
|
||||
- Inference rate: 2 Hz (configurable)
|
||||
- WebSocket output for real-time visualization
|
||||
|
||||
**Data flow:**
|
||||
```
|
||||
ESP32 TX -> WiFi signal -> ESP32 RX -> Serial (921.6 kbaud) -> Pi Zero FIFO -> Model -> WebSocket
|
||||
```
|
||||
|
||||
**Limitations:**
|
||||
- Original Pi Zero (single-core ARM11) -- very slow inference
|
||||
- Activity recognition only (not pose estimation)
|
||||
- Python inference (not optimized for ARM)
|
||||
|
||||
**What we improve:**
|
||||
- Pi Zero 2 W has quad-core Cortex-A53 -- roughly 5-10x faster than Pi Zero
|
||||
- Rust inference (ONNX/Candle) vs Python -- 3-10x faster
|
||||
- ESP32-S3 vs ESP32-WROOM-32 -- better CSI quality, more subcarriers
|
||||
- Pose estimation instead of just activity classification
|
||||
- UDP transport instead of USB serial -- supports multi-node mesh
|
||||
|
||||
### 2.2 OnnxStream: Lightweight ONNX on Pi Zero 2 W
|
||||
|
||||
**Repository:** [github.com/vitoplantamura/OnnxStream](https://github.com/vitoplantamura/OnnxStream)
|
||||
|
||||
Runs Stable Diffusion XL on Pi Zero 2 W in 298 MB RAM. Key features:
|
||||
- C++ implementation, XNNPACK acceleration
|
||||
- ARM NEON SIMD optimization
|
||||
- Memory-efficient streaming execution (processes one operator at a time)
|
||||
- Supports INT8 quantization
|
||||
|
||||
**Benchmark estimates for our model sizes:**
|
||||
|
||||
| Model | Parameters | INT8 Size | Est. Pi Zero 2 Latency |
|
||||
|-------|-----------|-----------|----------------------|
|
||||
| MultiFormer-18 | 2.80M | ~2.8 MB | ~30-50ms |
|
||||
| WiFlow | 4.82M | ~4.8 MB | ~50-80ms |
|
||||
| MultiFormer | 11.93M | ~11.9 MB | ~120-200ms |
|
||||
| DensePose-WiFi | ~25M (est.) | ~25 MB | ~300-500ms |
|
||||
|
||||
These estimates assume XNNPACK-accelerated INT8 inference on Cortex-A53 @ 1 GHz. The WiFlow and MultiFormer-18 models can achieve 12-20 Hz inference, matching our 20 Hz TDMA cycle target.
|
||||
|
||||
### 2.3 ONNX Runtime on ARM
|
||||
|
||||
ONNX Runtime officially supports Raspberry Pi deployment with:
|
||||
- ARM NEON execution provider
|
||||
- INT8 quantization support
|
||||
- Python and C++ APIs
|
||||
- Model optimization tools (graph optimization, operator fusion)
|
||||
|
||||
For Rust integration, the `ort` crate (ONNX Runtime Rust bindings) supports cross-compilation to aarch64-linux-gnu.
|
||||
|
||||
### 2.4 EfficientFi: CSI Compression for Edge
|
||||
|
||||
**Paper:** EfficientFi: Towards Large-Scale Lightweight WiFi Sensing via CSI Compression ([arXiv:2204.04138](https://arxiv.org/pdf/2204.04138))
|
||||
|
||||
Proposes compressing CSI data on the sensing device before transmission to the inference node. Key idea: train a CSI autoencoder where the encoder runs on the constrained device and the decoder runs on the more powerful inference node.
|
||||
|
||||
**Relevance:** For our ESP32 -> Pi Zero pipeline, CSI compression on ESP32 reduces:
|
||||
- UDP packet size (lower bandwidth, less packet loss)
|
||||
- Pi Zero preprocessing time (compressed features are more compact)
|
||||
- Effective latency (less data to transmit per frame)
|
||||
|
||||
## 3. Comparative Analysis: Architecture Selection for ESP32 + Pi Zero
|
||||
|
||||
### 3.1 Decision Matrix
|
||||
|
||||
| Criterion | WiFlow | MultiFormer-18 | DensePose-WiFi | Graph-3D |
|
||||
|-----------|--------|----------------|----------------|----------|
|
||||
| Parameters | 4.82M | 2.80M | ~25M | ~8M (est.) |
|
||||
| FLOPs | 0.47B | ~0.3B (est.) | ~5B (est.) | ~1B (est.) |
|
||||
| Multi-person | No | Yes (PAF+Hungarian) | Yes (RCNN-based) | No |
|
||||
| 3D output | No (2D) | No (2D) | No (UV map) | Yes (3D) |
|
||||
| Amplitude-only | Yes | Yes | No (amp+phase) | Unknown |
|
||||
| Edge-viable | Yes | Yes | No | Marginal |
|
||||
| Open source | Not yet | Not yet | Limited | Not yet |
|
||||
|
||||
### 3.2 Recommended Architecture: Hybrid WiFlow + MultiFormer
|
||||
|
||||
For the ESP32 + Pi Zero deployment, we recommend a hybrid architecture:
|
||||
|
||||
1. **WiFlow's TCN temporal encoder** on ESP32 -- extract temporal features from raw CSI
|
||||
2. **MultiFormer's dual-token approach** on Pi Zero -- process both frequency and temporal views
|
||||
3. **WiFlow's bone constraint loss** during training -- enforce physical skeleton plausibility
|
||||
4. **RuvSense coherence gating** before inference -- reject low-quality CSI frames
|
||||
|
||||
This hybrid achieves:
|
||||
- ~3-5M parameters (between WiFlow and MultiFormer-18)
|
||||
- Amplitude-only input (robust to ESP32 CFO/SFO)
|
||||
- Sub-100ms inference on Pi Zero 2 W
|
||||
- Optional multi-person support via PAF module
|
||||
|
||||
### 3.3 Training Data Strategy
|
||||
|
||||
Based on the surveyed papers:
|
||||
|
||||
| Dataset | Subjects | Frames | Hardware | Availability |
|
||||
|---------|----------|--------|----------|--------------|
|
||||
| CMU DensePose-WiFi | 8 | ~250K | Intel 5300 | Limited |
|
||||
| Person-in-WiFi 3D | 7 | 97K | Custom WiFi | GitHub |
|
||||
| MM-Fi | Multiple | Large | WiFi + mmWave | Public |
|
||||
| Wi-Pose | Multiple | Large | Intel 5300 | Public |
|
||||
|
||||
**Our approach:**
|
||||
1. Pre-train on MM-Fi/Wi-Pose public datasets (Intel 5300 CSI format)
|
||||
2. Apply domain adaptation for ESP32-S3 CSI format (different subcarrier count, CFO characteristics)
|
||||
3. Fine-tune on self-collected ESP32-S3 data in target environments
|
||||
4. Augment with synthetic CSI from ray-tracing forward model (Arena Physica insight)
|
||||
|
||||
## 4. Gap Analysis: Current wifi-densepose vs SOTA
|
||||
|
||||
### 4.1 What We Have
|
||||
|
||||
| Capability | Status | Module |
|
||||
|-----------|--------|--------|
|
||||
| ESP32 CSI capture | Production | `wifi-densepose-hardware` |
|
||||
| Multi-node fusion | Production | `ruvsense/multistatic.rs` |
|
||||
| Phase alignment | Production | `ruvsense/phase_align.rs` |
|
||||
| Coherence gating | Production | `ruvsense/coherence_gate.rs` |
|
||||
| 17-keypoint tracking | Production | `ruvsense/pose_tracker.rs` |
|
||||
| ONNX inference engine | Production | `wifi-densepose-nn` |
|
||||
| Modality translator | Production | `wifi-densepose-nn/translator.rs` |
|
||||
| Training pipeline | Production | `wifi-densepose-train` |
|
||||
| Subcarrier interpolation | Production | `wifi-densepose-train/subcarrier.rs` |
|
||||
|
||||
### 4.2 What We Are Missing
|
||||
|
||||
| Gap | Required For | Priority |
|
||||
|-----|-------------|----------|
|
||||
| **Pi Zero deployment target** | Edge inference node | Critical |
|
||||
| **Lightweight model architecture** | Sub-100ms inference on Cortex-A53 | Critical |
|
||||
| **Temporal causal convolution** | Real-time streaming inference | High |
|
||||
| **Axial attention module** | Efficient spatial encoding | High |
|
||||
| **Bone constraint loss** | Physical plausibility | High |
|
||||
| **CSI compression on ESP32** | Bandwidth reduction | Medium |
|
||||
| **INT8 quantization pipeline** | Model size reduction | Medium |
|
||||
| **Cross-environment adaptation** | Deployment generalization | Medium |
|
||||
| **Multi-person PAF decoding** | Multiple subject support | Low (Phase 2) |
|
||||
| **3D pose lifting** | Z-axis estimation | Low (Phase 3) |
|
||||
| **Diffusion-based pose refinement** | Uncertainty quantification | Research |
|
||||
|
||||
### 4.3 Architecture Gaps in Detail
|
||||
|
||||
**1. No lightweight inference path.** The current `wifi-densepose-nn` crate assumes GPU or high-end CPU inference. We need an `EdgeInferenceEngine` optimized for:
|
||||
- INT8 ONNX models
|
||||
- ARM NEON SIMD via XNNPACK
|
||||
- Streaming inference (process CSI frames as they arrive, not in batches)
|
||||
- Memory-mapped model loading (avoid loading entire model into RAM)
|
||||
|
||||
**2. No ESP32 -> Pi Zero communication protocol.** The `wifi-densepose-hardware` crate handles ESP32 CSI capture and UDP aggregation to a server, but has no lightweight protocol for ESP32 -> Pi Zero direct communication. We need:
|
||||
- Compact binary frame format (not the full ADR-018 format)
|
||||
- Optional CSI compression (autoencoder on ESP32 or simple PCA)
|
||||
- Heartbeat and synchronization for multi-ESP32 setups
|
||||
|
||||
**3. No temporal convolution module.** The existing signal processing pipeline uses frame-by-frame processing. WiFlow and MultiFormer both show that temporal context (20 frames for WiFlow, 64 frames for MultiFormer) significantly improves accuracy. We need a ring buffer + TCN module in the inference path.
|
||||
|
||||
**4. No bone/skeleton constraint enforcement at inference time.** The `pose_tracker.rs` has Kalman filtering and skeleton constraints, but these are post-hoc corrections. WiFlow shows that baking bone constraints into the loss function during training produces better models that need less post-processing.
|
||||
|
||||
## 5. References
|
||||
|
||||
1. DensePose From WiFi, Geng et al., arXiv:2301.00250, 2023
|
||||
2. Person-in-WiFi 3D, Yan et al., CVPR 2024
|
||||
3. WiFlow, arXiv:2602.08661, 2026
|
||||
4. MultiFormer, arXiv:2505.22555, 2025
|
||||
5. CSI-Channel Spatial Decomposition, MDPI Electronics 14(4), 2025
|
||||
6. CSI-Former, MDPI Entropy 25(1), 2023
|
||||
7. Spatio-Temporal 3D Point Clouds from WiFi-CSI, arXiv:2410.16303, 2024
|
||||
8. Graph-based 3D Human Pose from WiFi, arXiv:2511.19105, 2025
|
||||
9. EfficientFi, arXiv:2204.04138, 2022
|
||||
10. CSI-Sense-Zero, github.com/winwinashwin/CSI-Sense-Zero
|
||||
11. OnnxStream, github.com/vitoplantamura/OnnxStream
|
||||
12. Arena Physica, arenaphysica.com (Atlas RF Studio, Heaviside-0/Marconi-0)
|
||||
13. Tools and Methods for WiFi Sensing in Embedded Devices, MDPI Sensors 25(19), 2025
|
||||
14. Real-Time HAR using WiFi CSI and LSTM on Edge Devices, SASI-ITE 2025
|
||||
@@ -1,917 +0,0 @@
|
||||
# ESP32 CSI to Cognitum Seed Pretraining Pipeline
|
||||
|
||||
A beginner-friendly tutorial for collecting WiFi CSI data with ESP32 nodes
|
||||
and building a pre-trained model using the Cognitum Seed edge intelligence appliance.
|
||||
|
||||
**Estimated time:** 1 hour (setup 20 min, data collection 30 min, verification 10 min)
|
||||
|
||||
**What you will build:** A self-supervised pretraining dataset stored on a
|
||||
Cognitum Seed, containing 8-dimensional feature vectors extracted from live
|
||||
WiFi Channel State Information. The Seed's RVF vector store, kNN search, and
|
||||
witness chain turn raw radio signals into a searchable, cryptographically
|
||||
attested knowledge base -- no cameras or manual labeling required.
|
||||
|
||||
**Who this is for:** Makers, embedded engineers, and ML practitioners who want
|
||||
to experiment with WiFi-based human sensing. No Rust knowledge is needed; the
|
||||
entire workflow uses Python and pre-built firmware binaries.
|
||||
|
||||
---
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Prerequisites](#1-prerequisites)
|
||||
2. [Hardware Setup](#2-hardware-setup)
|
||||
3. [Running the Bridge](#3-running-the-bridge)
|
||||
4. [Data Collection Protocol](#4-data-collection-protocol)
|
||||
5. [Monitoring Progress](#5-monitoring-progress)
|
||||
6. [Understanding the Feature Vectors](#6-understanding-the-feature-vectors)
|
||||
7. [Using the Pre-trained Data](#7-using-the-pre-trained-data)
|
||||
8. [Troubleshooting](#8-troubleshooting)
|
||||
9. [Next Steps](#9-next-steps)
|
||||
|
||||
---
|
||||
|
||||
## 1. Prerequisites
|
||||
|
||||
### Hardware
|
||||
|
||||
| Item | Quantity | Approx. Cost | Notes |
|
||||
|------|----------|-------------|-------|
|
||||
| ESP32-S3 (8MB flash) | 2 | ~$9 each | Must be S3 variant -- original ESP32 and C3 are not supported (single-core, cannot run CSI DSP) |
|
||||
| Cognitum Seed (Pi Zero 2 W) | 1 | ~$15 | Available at [cognitum.one](https://cognitum.one) |
|
||||
| USB-C data cables | 3 | ~$3 each | Must be **data** cables, not charge-only |
|
||||
|
||||
**Total cost: ~$36**
|
||||
|
||||
### Software
|
||||
|
||||
Install these on your host laptop/desktop (Windows, macOS, or Linux):
|
||||
|
||||
```bash
|
||||
# Python 3.10 or later
|
||||
python --version
|
||||
# Expected: Python 3.10.x or later
|
||||
|
||||
# esptool for flashing firmware
|
||||
pip install esptool
|
||||
|
||||
# pyserial for serial monitoring (optional but useful)
|
||||
pip install pyserial
|
||||
```
|
||||
|
||||
> **Tip:** You do not need the Rust toolchain for this tutorial. The ESP32
|
||||
> firmware is distributed as pre-built binaries, and the bridge script is
|
||||
> pure Python.
|
||||
|
||||
### Firmware
|
||||
|
||||
Download the v0.5.4 firmware binaries from the GitHub releases page:
|
||||
|
||||
```
|
||||
esp32-csi-node.bin -- Main firmware (8MB flash)
|
||||
bootloader.bin -- Bootloader
|
||||
partition-table.bin -- Partition table
|
||||
ota_data_initial.bin -- OTA data
|
||||
```
|
||||
|
||||
### Network
|
||||
|
||||
All devices must be on the same WiFi network. You will need:
|
||||
|
||||
- Your WiFi SSID and password
|
||||
- Your host laptop's local IP address (e.g., `192.168.1.20`)
|
||||
|
||||
Find your host IP:
|
||||
|
||||
```bash
|
||||
# Windows
|
||||
ipconfig | findstr "IPv4"
|
||||
|
||||
# macOS / Linux
|
||||
ip addr show | grep "inet " | grep -v 127.0.0.1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Hardware Setup
|
||||
|
||||
### Physical Layout
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Room │
|
||||
│ │
|
||||
│ [ESP32 #1] [ESP32 #2] │
|
||||
│ node_id=1 node_id=2 │
|
||||
│ on shelf on desk │
|
||||
│ ~1.5m high ~0.8m high │
|
||||
│ │
|
||||
│ 3-5 meters apart │
|
||||
│ │
|
||||
│ [Cognitum Seed] │
|
||||
│ on table, USB to laptop │
|
||||
│ │
|
||||
│ [Host Laptop] │
|
||||
│ running bridge script │
|
||||
└─────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
> **Tip:** Place the two ESP32 nodes 3-5 meters apart at different heights.
|
||||
> This gives the multi-node pipeline spatial diversity, which improves the
|
||||
> quality of cross-viewpoint features.
|
||||
|
||||
### Step 2.1: Connect and Verify the Cognitum Seed
|
||||
|
||||
Plug the Cognitum Seed into your laptop using a USB **data** cable.
|
||||
|
||||
Wait 30-60 seconds for it to boot. Then verify connectivity:
|
||||
|
||||
```bash
|
||||
curl -sk https://169.254.42.1:8443/api/v1/status
|
||||
```
|
||||
|
||||
Expected output (abbreviated):
|
||||
|
||||
```json
|
||||
{
|
||||
"device_id": "ecaf97dd-fc90-4b0e-b0e7-e9f896b9fbb6",
|
||||
"total_vectors": 0,
|
||||
"epoch": 1,
|
||||
"dimension": 8,
|
||||
"uptime_secs": 45
|
||||
}
|
||||
```
|
||||
|
||||
> **Note:** The `-sk` flags tell curl to use HTTPS (`-s` silent, `-k` skip
|
||||
> TLS certificate verification). The Seed uses a self-signed certificate.
|
||||
|
||||
You can also open `https://169.254.42.1:8443/guide` in a browser (accept
|
||||
the self-signed certificate warning) to see the Seed's setup guide.
|
||||
|
||||
### Step 2.2: Pair the Seed
|
||||
|
||||
Pairing generates a bearer token that authorizes write access. Pairing can
|
||||
only be initiated from the USB interface (169.254.42.1), not from WiFi -- this
|
||||
is a security feature.
|
||||
|
||||
```bash
|
||||
curl -sk -X POST https://169.254.42.1:8443/api/v1/pair \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"client_name": "wifi-densepose-tutorial"}'
|
||||
```
|
||||
|
||||
Expected output:
|
||||
|
||||
```json
|
||||
{
|
||||
"token": "seed_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
|
||||
"expires": null,
|
||||
"permissions": ["read", "write", "admin"]
|
||||
}
|
||||
```
|
||||
|
||||
Save this token -- you will need it for every bridge command:
|
||||
|
||||
```bash
|
||||
export SEED_TOKEN="seed_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
|
||||
```
|
||||
|
||||
> **Warning:** Treat the token like a password. Do not commit it to git or
|
||||
> share it publicly.
|
||||
|
||||
### Step 2.3: Flash ESP32 #1
|
||||
|
||||
Connect the first ESP32-S3 to your laptop via USB. Identify its serial port:
|
||||
|
||||
```bash
|
||||
# Windows -- look for "Silicon Labs" or "CP210x" in Device Manager
|
||||
# or run:
|
||||
python -m serial.tools.list_ports
|
||||
|
||||
# macOS
|
||||
ls /dev/tty.usb*
|
||||
|
||||
# Linux
|
||||
ls /dev/ttyUSB* /dev/ttyACM*
|
||||
```
|
||||
|
||||
Flash the firmware (replace `COM9` with your port):
|
||||
|
||||
```bash
|
||||
esptool.py --chip esp32s3 --port COM9 --baud 460800 \
|
||||
write_flash \
|
||||
0x0 bootloader.bin \
|
||||
0x8000 partition-table.bin \
|
||||
0xd000 ota_data_initial.bin \
|
||||
0x10000 esp32-csi-node.bin
|
||||
```
|
||||
|
||||
Expected output (last lines):
|
||||
|
||||
```
|
||||
Writing at 0x000f4000... (100 %)
|
||||
Wrote 978432 bytes (...)
|
||||
Hash of data verified.
|
||||
Leaving...
|
||||
Hard resetting via RTS pin...
|
||||
```
|
||||
|
||||
### Step 2.4: Provision ESP32 #1
|
||||
|
||||
Tell the ESP32 which WiFi network to join and where to send data:
|
||||
|
||||
```bash
|
||||
python firmware/esp32-csi-node/provision.py \
|
||||
--port COM9 \
|
||||
--ssid "YourWiFi" \
|
||||
--password "YourPassword" \
|
||||
--target-ip 192.168.1.20 \
|
||||
--target-port 5006 \
|
||||
--node-id 1
|
||||
```
|
||||
|
||||
Replace:
|
||||
- `COM9` with your actual serial port
|
||||
- `YourWiFi` / `YourPassword` with your WiFi credentials
|
||||
- `192.168.1.20` with your host laptop's IP address
|
||||
|
||||
Expected output:
|
||||
|
||||
```
|
||||
Writing NVS partition (24576 bytes) at offset 0x9000...
|
||||
Provisioning complete. Reset the device to apply.
|
||||
```
|
||||
|
||||
> **Important:** The `--target-ip` is your **host laptop**, not the Seed.
|
||||
> The bridge script runs on your laptop and forwards vectors to the Seed
|
||||
> via HTTPS.
|
||||
|
||||
### Step 2.5: Verify ESP32 #1 Is Streaming
|
||||
|
||||
After provisioning, the ESP32 resets and begins streaming. Verify with a
|
||||
quick UDP listener:
|
||||
|
||||
```bash
|
||||
python -c "
|
||||
import socket, struct
|
||||
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
|
||||
sock.bind(('0.0.0.0', 5006))
|
||||
sock.settimeout(10)
|
||||
print('Listening on UDP 5006 for 10 seconds...')
|
||||
count = 0
|
||||
try:
|
||||
while True:
|
||||
data, addr = sock.recvfrom(2048)
|
||||
magic = struct.unpack_from('<I', data)[0]
|
||||
names = {0xC5110001: 'CSI_RAW', 0xC5110002: 'VITALS', 0xC5110003: 'FEATURES'}
|
||||
name = names.get(magic, f'UNKNOWN(0x{magic:08X})')
|
||||
count += 1
|
||||
if count <= 5:
|
||||
print(f' Packet {count}: {name} from {addr[0]} ({len(data)} bytes)')
|
||||
except socket.timeout:
|
||||
pass
|
||||
sock.close()
|
||||
print(f'Received {count} packets total')
|
||||
"
|
||||
```
|
||||
|
||||
Expected output:
|
||||
|
||||
```
|
||||
Listening on UDP 5006 for 10 seconds...
|
||||
Packet 1: VITALS from 192.168.1.105 (32 bytes)
|
||||
Packet 2: FEATURES from 192.168.1.105 (48 bytes)
|
||||
Packet 3: VITALS from 192.168.1.105 (32 bytes)
|
||||
Packet 4: FEATURES from 192.168.1.105 (48 bytes)
|
||||
Packet 5: VITALS from 192.168.1.105 (32 bytes)
|
||||
Received 20 packets total
|
||||
```
|
||||
|
||||
If you see 0 packets, check the [Troubleshooting](#8-troubleshooting) section.
|
||||
|
||||
### Step 2.6: Flash and Provision ESP32 #2
|
||||
|
||||
Repeat steps 2.3-2.5 for the second ESP32, using `--node-id 2`:
|
||||
|
||||
```bash
|
||||
# Flash (replace COM8 with your port)
|
||||
esptool.py --chip esp32s3 --port COM8 --baud 460800 \
|
||||
write_flash \
|
||||
0x0 bootloader.bin \
|
||||
0x8000 partition-table.bin \
|
||||
0xd000 ota_data_initial.bin \
|
||||
0x10000 esp32-csi-node.bin
|
||||
|
||||
# Provision
|
||||
python firmware/esp32-csi-node/provision.py \
|
||||
--port COM8 \
|
||||
--ssid "YourWiFi" \
|
||||
--password "YourPassword" \
|
||||
--target-ip 192.168.1.20 \
|
||||
--target-port 5006 \
|
||||
--node-id 2
|
||||
```
|
||||
|
||||
### Step 2.7: Verify Both Nodes
|
||||
|
||||
Run the UDP listener again. You should see packets from two different IPs:
|
||||
|
||||
```
|
||||
Packet 1: FEATURES from 192.168.1.105 (48 bytes) <-- node 1
|
||||
Packet 2: FEATURES from 192.168.1.104 (48 bytes) <-- node 2
|
||||
Packet 3: VITALS from 192.168.1.105 (32 bytes)
|
||||
Packet 4: VITALS from 192.168.1.104 (32 bytes)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Running the Bridge
|
||||
|
||||
The bridge script (`scripts/seed_csi_bridge.py`) listens for UDP packets
|
||||
from the ESP32 nodes, batches them, and ingests them into the Seed's RVF
|
||||
vector store via HTTPS.
|
||||
|
||||
### Basic Start
|
||||
|
||||
```bash
|
||||
python scripts/seed_csi_bridge.py \
|
||||
--seed-url https://169.254.42.1:8443 \
|
||||
--token "$SEED_TOKEN" \
|
||||
--udp-port 5006 \
|
||||
--batch-size 10
|
||||
```
|
||||
|
||||
Expected output:
|
||||
|
||||
```
|
||||
12:00:01 [INFO] Connected to Seed ecaf97dd — 0 vectors, epoch 1, dim 8
|
||||
12:00:01 [INFO] Listening on UDP port 5006 (batch size: 10, flush interval: 10s)
|
||||
12:00:11 [INFO] Ingested 10 vectors (epoch=2, witness=a3b7c9d2e4f6...)
|
||||
12:00:21 [INFO] Ingested 10 vectors (epoch=3, witness=f1e2d3c4b5a6...)
|
||||
```
|
||||
|
||||
### Bridge Flags Explained
|
||||
|
||||
| Flag | Default | Description |
|
||||
|------|---------|-------------|
|
||||
| `--seed-url` | `https://169.254.42.1:8443` | Seed HTTPS endpoint (USB link-local) |
|
||||
| `--token` | `$SEED_TOKEN` env var | Bearer token from pairing step |
|
||||
| `--udp-port` | `5006` | UDP port to listen for ESP32 packets |
|
||||
| `--batch-size` | `10` | Number of vectors per ingest call |
|
||||
| `--flush-interval` | `10` | Maximum seconds between flushes (time-based batching) |
|
||||
| `--validate` | off | After each batch, run kNN query + PIR comparison |
|
||||
| `--stats` | off | Print Seed stats and exit (no bridge loop) |
|
||||
| `--compact` | off | Trigger store compaction and exit |
|
||||
| `--allowed-sources` | none | Comma-separated IPs to accept (anti-spoofing) |
|
||||
| `-v` / `--verbose` | off | Log every received packet |
|
||||
|
||||
### Recommended: Validation Mode
|
||||
|
||||
For your first data collection, enable `--validate` so the bridge verifies
|
||||
each batch against the Seed's kNN index:
|
||||
|
||||
```bash
|
||||
python scripts/seed_csi_bridge.py \
|
||||
--seed-url https://169.254.42.1:8443 \
|
||||
--token "$SEED_TOKEN" \
|
||||
--udp-port 5006 \
|
||||
--batch-size 10 \
|
||||
--validate
|
||||
```
|
||||
|
||||
With validation enabled, you will see additional output after each batch:
|
||||
|
||||
```
|
||||
12:00:11 [INFO] Ingested 10 vectors (epoch=2, witness=a3b7c9d2...)
|
||||
12:00:11 [INFO] Validation: kNN distance=0.000000 (exact match)
|
||||
12:00:11 [INFO] PIR=LOW CSI_presence=0.14 (absent) -- agreement 100.0% (1/1)
|
||||
```
|
||||
|
||||
### Recommended: Source IP Filtering
|
||||
|
||||
If you are on a shared network, restrict the bridge to only accept packets
|
||||
from your ESP32 nodes:
|
||||
|
||||
```bash
|
||||
python scripts/seed_csi_bridge.py \
|
||||
--token "$SEED_TOKEN" \
|
||||
--udp-port 5006 \
|
||||
--batch-size 10 \
|
||||
--allowed-sources "192.168.1.104,192.168.1.105"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Data Collection Protocol
|
||||
|
||||
Collect 6 scenarios, 5 minutes each, for a total of 30 minutes of data.
|
||||
With 2 nodes at 1 Hz each, each scenario produces ~600 feature vectors.
|
||||
|
||||
> **Before you begin:** Make sure the bridge is running (Section 3). Leave
|
||||
> the terminal open and start a new terminal for the commands below.
|
||||
|
||||
### Scenario 1: Empty Room (5 min)
|
||||
|
||||
This establishes the baseline -- what the room looks like with no one in it.
|
||||
|
||||
```bash
|
||||
echo "=== SCENARIO 1: EMPTY ROOM ==="
|
||||
echo "Leave the room now. Data collection starts in 10 seconds."
|
||||
sleep 10
|
||||
echo "Recording for 5 minutes... ($(date))"
|
||||
sleep 300
|
||||
echo "Done. You may re-enter the room."
|
||||
```
|
||||
|
||||
**What to do:** Leave the room. Close the door if possible. Stay out for
|
||||
the full 5 minutes.
|
||||
|
||||
### Scenario 2: One Person Stationary (5 min)
|
||||
|
||||
```bash
|
||||
echo "=== SCENARIO 2: 1 PERSON STATIONARY ==="
|
||||
echo "Sit at a desk or chair. Stay still. Breathe normally."
|
||||
sleep 300
|
||||
echo "Done."
|
||||
```
|
||||
|
||||
**What to do:** Sit at a desk roughly between the two ESP32 nodes. Stay
|
||||
still. Breathe normally. Do not use your phone (arm movement adds noise).
|
||||
|
||||
### Scenario 3: One Person Walking (5 min)
|
||||
|
||||
```bash
|
||||
echo "=== SCENARIO 3: 1 PERSON WALKING ==="
|
||||
echo "Walk around the room at a normal pace."
|
||||
sleep 300
|
||||
echo "Done."
|
||||
```
|
||||
|
||||
**What to do:** Walk around the room in varied paths. Go near each ESP32
|
||||
node at least once. Walk at a normal pace -- not too fast, not too slow.
|
||||
|
||||
### Scenario 4: One Person Varied Activity (5 min)
|
||||
|
||||
```bash
|
||||
echo "=== SCENARIO 4: 1 PERSON VARIED ==="
|
||||
echo "Move around: stand, sit, wave arms, turn in place."
|
||||
sleep 300
|
||||
echo "Done."
|
||||
```
|
||||
|
||||
**What to do:** Mix activities. Stand up, sit down, wave your arms, turn
|
||||
around, reach for a shelf, crouch down. The goal is to capture a variety of
|
||||
body positions and motions.
|
||||
|
||||
### Scenario 5: Two People (5 min)
|
||||
|
||||
```bash
|
||||
echo "=== SCENARIO 5: TWO PEOPLE ==="
|
||||
echo "Two people in the room, both moving around."
|
||||
sleep 300
|
||||
echo "Done."
|
||||
```
|
||||
|
||||
**What to do:** Have a second person enter the room. Both people should
|
||||
move around naturally -- walking, sitting, standing at different positions.
|
||||
|
||||
### Scenario 6: Transitions (5 min)
|
||||
|
||||
```bash
|
||||
echo "=== SCENARIO 6: TRANSITIONS ==="
|
||||
echo "Enter and exit the room repeatedly."
|
||||
sleep 300
|
||||
echo "Done."
|
||||
```
|
||||
|
||||
**What to do:** Walk in and out of the room several times. Pause for
|
||||
30-60 seconds inside, then leave for 30-60 seconds. This teaches the model
|
||||
what state transitions look like.
|
||||
|
||||
### Expected Data Volume
|
||||
|
||||
After all 6 scenarios:
|
||||
|
||||
| Metric | Expected |
|
||||
|--------|----------|
|
||||
| Total time | 30 minutes |
|
||||
| Vectors per node | ~1,800 |
|
||||
| Total vectors (2 nodes) | ~3,600 |
|
||||
| RVF store size | ~150 KB |
|
||||
| Witness chain entries | ~360+ |
|
||||
|
||||
---
|
||||
|
||||
## 5. Monitoring Progress
|
||||
|
||||
### Check Seed Stats
|
||||
|
||||
At any time, open a new terminal and run:
|
||||
|
||||
```bash
|
||||
python scripts/seed_csi_bridge.py --token "$SEED_TOKEN" --stats
|
||||
```
|
||||
|
||||
Expected output (after completing all 6 scenarios):
|
||||
|
||||
```
|
||||
=== Seed Status ===
|
||||
Device ID: ecaf97dd-fc90-4b0e-b0e7-e9f896b9fbb6
|
||||
Total vectors: 3612
|
||||
Epoch: 362
|
||||
Dimension: 8
|
||||
Uptime: 3845s
|
||||
|
||||
=== Witness Chain ===
|
||||
Valid: True
|
||||
Chain length: 1747
|
||||
Head: a3b7c9d2e4f6g8h1i2j3k4l5m6n7...
|
||||
|
||||
=== Boundary Analysis ===
|
||||
Fragility score: 0.42
|
||||
Boundary count: 6
|
||||
|
||||
=== Coherence Profile ===
|
||||
phase_count: 6
|
||||
current_phase: 5
|
||||
coherence: 0.87
|
||||
|
||||
=== kNN Graph Stats ===
|
||||
nodes: 3612
|
||||
edges: 18060
|
||||
avg_degree: 5.0
|
||||
```
|
||||
|
||||
> **What to look for:**
|
||||
> - `Total vectors` should grow by ~2 per second (1 per node per second)
|
||||
> - `Valid: True` on the witness chain means no data tampering
|
||||
> - `Fragility score` rises during transitions and drops during stable
|
||||
> scenarios -- this is normal and expected
|
||||
> - `phase_count` should roughly correspond to the number of distinct
|
||||
> scenarios the Seed has observed
|
||||
|
||||
### Verify kNN Quality
|
||||
|
||||
Query the Seed for the 5 nearest neighbors to a "someone present" vector:
|
||||
|
||||
```bash
|
||||
curl -sk -X POST https://169.254.42.1:8443/api/v1/store/query \
|
||||
-H "Authorization: Bearer $SEED_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"vector": [0.8, 0.5, 0.5, 0.6, 0.5, 0.25, 0.0, 0.6], "k": 5}'
|
||||
```
|
||||
|
||||
Expected output:
|
||||
|
||||
```json
|
||||
{
|
||||
"results": [
|
||||
{"id": 2847193655, "distance": 0.023},
|
||||
{"id": 1038476291, "distance": 0.031},
|
||||
{"id": 3719284651, "distance": 0.045},
|
||||
{"id": 928374651, "distance": 0.052},
|
||||
{"id": 1847293746, "distance": 0.068}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Low distances (< 0.1) indicate the query vector is similar to stored
|
||||
vectors -- the store contains meaningful data.
|
||||
|
||||
### Verify Witness Chain
|
||||
|
||||
The witness chain is a SHA-256 hash chain that proves no vectors were
|
||||
tampered with after ingestion:
|
||||
|
||||
```bash
|
||||
curl -sk -X POST https://169.254.42.1:8443/api/v1/witness/verify \
|
||||
-H "Authorization: Bearer $SEED_TOKEN"
|
||||
```
|
||||
|
||||
Expected output:
|
||||
|
||||
```json
|
||||
{
|
||||
"valid": true,
|
||||
"chain_length": 1747,
|
||||
"head": "a3b7c9d2e4f6..."
|
||||
}
|
||||
```
|
||||
|
||||
> **Warning:** If `valid` is `false`, the witness chain has been broken.
|
||||
> This means data was modified outside the normal ingest path. Discard
|
||||
> the dataset and re-collect.
|
||||
|
||||
---
|
||||
|
||||
## 6. Understanding the Feature Vectors
|
||||
|
||||
Each ESP32 node extracts an 8-dimensional feature vector once per second
|
||||
from the 100 Hz CSI processing pipeline. Every dimension is normalized to
|
||||
the range 0.0 to 1.0.
|
||||
|
||||
### Feature Dimension Table
|
||||
|
||||
| Dim | Name | Raw Source | Normalization | Range | Example Values |
|
||||
|-----|------|-----------|---------------|-------|----------------|
|
||||
| 0 | Presence score | `presence_score` | `/ 15.0`, clamped | 0.0 -- 1.0 | Empty: 0.01-0.05, Occupied: 0.19-1.0 |
|
||||
| 1 | Motion energy | `motion_energy` | `/ 10.0`, clamped | 0.0 -- 1.0 | Still: 0.05-0.15, Walking: 0.3-0.8 |
|
||||
| 2 | Breathing rate | `breathing_bpm` | `/ 30.0`, clamped | 0.0 -- 1.0 | Normal: 0.5-0.8 (15-24 BPM), At rest: 0.67-1.0 (20-34 BPM observed) |
|
||||
| 3 | Heart rate | `heartrate_bpm` | `/ 120.0`, clamped | 0.0 -- 1.0 | Resting: 0.50-0.67 (60-80 BPM), Active: 0.63-0.83 (75-99 BPM observed) |
|
||||
| 4 | Phase variance | Welford variance | Mean of top-K subcarriers | 0.0 -- 1.0 | Stable: 0.1-0.3, Disturbed: 0.5-0.9 |
|
||||
| 5 | Person count | `n_persons / 4.0` | Clamped to [0, 1] | 0.0 -- 1.0 | 0 people: 0.0, 1 person: 0.25, 2 people: 0.5 |
|
||||
| 6 | Fall detected | Binary flag | 1.0 if fall, else 0.0 | 0.0 or 1.0 | Normal: 0.0, Fall event: 1.0 |
|
||||
| 7 | RSSI | `(rssi + 100) / 100` | Clamped to [0, 1] | 0.0 -- 1.0 | Close: 0.57-0.66 (-43 to -34 dBm), Far: 0.28-0.40 (-72 to -60 dBm) |
|
||||
|
||||
### How to Read a Feature Vector
|
||||
|
||||
Example vector from live validation:
|
||||
|
||||
```
|
||||
[0.99, 0.47, 0.67, 0.63, 0.50, 0.25, 0.00, 0.57]
|
||||
```
|
||||
|
||||
Reading this:
|
||||
|
||||
- **0.99** (dim 0, presence) -- Strong presence detected
|
||||
- **0.47** (dim 1, motion) -- Moderate motion (slow walking or fidgeting)
|
||||
- **0.67** (dim 2, breathing) -- 20.1 BPM (0.67 x 30), normal at-rest breathing
|
||||
- **0.63** (dim 3, heart rate) -- 75.6 BPM (0.63 x 120), normal resting heart rate
|
||||
- **0.50** (dim 4, phase variance) -- Placeholder (future use)
|
||||
- **0.25** (dim 5, person count) -- 1 person (0.25 x 4 = 1)
|
||||
- **0.00** (dim 6, fall) -- No fall detected
|
||||
- **0.57** (dim 7, RSSI) -- RSSI of -43 dBm ((0.57 x 100) - 100), strong signal
|
||||
|
||||
### Packet Format
|
||||
|
||||
The feature vector is transmitted as a 48-byte binary packet with magic
|
||||
number `0xC5110003`:
|
||||
|
||||
```
|
||||
Offset Size Type Field
|
||||
------ ---- ------- ----------------
|
||||
0 4 uint32 magic (0xC5110003)
|
||||
4 1 uint8 node_id
|
||||
5 1 uint8 reserved
|
||||
6 2 uint16 sequence number
|
||||
8 8 int64 timestamp (microseconds since boot)
|
||||
16 32 float[8] feature vector (8 x 4 bytes)
|
||||
------ ----
|
||||
Total: 48 bytes
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Using the Pre-trained Data
|
||||
|
||||
After collecting 30 minutes of data, the Seed holds ~3,600 feature vectors
|
||||
organized as a kNN graph with witness chain attestation.
|
||||
|
||||
### Query for Similar States
|
||||
|
||||
Find vectors similar to "one person sitting quietly":
|
||||
|
||||
```bash
|
||||
curl -sk -X POST https://169.254.42.1:8443/api/v1/store/query \
|
||||
-H "Authorization: Bearer $SEED_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"vector": [0.8, 0.1, 0.6, 0.6, 0.5, 0.25, 0.0, 0.5], "k": 10}'
|
||||
```
|
||||
|
||||
Find vectors similar to "empty room":
|
||||
|
||||
```bash
|
||||
curl -sk -X POST https://169.254.42.1:8443/api/v1/store/query \
|
||||
-H "Authorization: Bearer $SEED_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"vector": [0.05, 0.02, 0.0, 0.0, 0.3, 0.0, 0.0, 0.5], "k": 10}'
|
||||
```
|
||||
|
||||
### Environment Fingerprinting
|
||||
|
||||
The Seed's boundary analysis detects regime changes in the vector space.
|
||||
When someone enters or leaves the room, the fragility score spikes:
|
||||
|
||||
```bash
|
||||
curl -sk https://169.254.42.1:8443/api/v1/boundary
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"fragility_score": 0.42,
|
||||
"boundary_count": 6
|
||||
}
|
||||
```
|
||||
|
||||
A `fragility_score` above 0.3 indicates the environment is in or near a
|
||||
transition state. The `boundary_count` roughly corresponds to the number
|
||||
of distinct "states" (scenarios) the Seed has observed.
|
||||
|
||||
### Export Vectors
|
||||
|
||||
To export all vectors for offline analysis or training:
|
||||
|
||||
```bash
|
||||
curl -sk https://169.254.42.1:8443/api/v1/store/export \
|
||||
-H "Authorization: Bearer $SEED_TOKEN" \
|
||||
-o pretrain-vectors.rvf
|
||||
```
|
||||
|
||||
The exported `.rvf` file contains the raw vector data and can be loaded
|
||||
by the Rust training pipeline (`wifi-densepose-train` crate) or converted
|
||||
to NumPy arrays for Python-based training.
|
||||
|
||||
### Compact the Store
|
||||
|
||||
For long-running deployments, run compaction daily to keep the store
|
||||
within the Seed's memory budget:
|
||||
|
||||
```bash
|
||||
python scripts/seed_csi_bridge.py --token "$SEED_TOKEN" --compact
|
||||
```
|
||||
|
||||
```
|
||||
Triggering store compaction...
|
||||
Compaction result: {
|
||||
"vectors_before": 3612,
|
||||
"vectors_after": 3200,
|
||||
"bytes_freed": 16544
|
||||
}
|
||||
```
|
||||
|
||||
### Use with the Sensing Server
|
||||
|
||||
Start a recording session to capture the raw CSI frames alongside the
|
||||
feature vectors (the sensing-server provides the recording API):
|
||||
|
||||
```bash
|
||||
# Start the recording (5 minutes)
|
||||
curl -X POST http://localhost:3000/api/v1/recording/start \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"session_name":"pretrain-1p-still","label":"1p-still","duration_secs":300}'
|
||||
```
|
||||
|
||||
The recording saves `.csi.jsonl` files that the `wifi-densepose-train`
|
||||
crate can load for full contrastive pretraining (see ADR-070).
|
||||
|
||||
---
|
||||
|
||||
## 8. Troubleshooting
|
||||
|
||||
### ESP32 Won't Connect to WiFi
|
||||
|
||||
**Symptoms:** No packets received, ESP32 serial output shows repeated
|
||||
"WiFi: Connecting..." messages.
|
||||
|
||||
**Fixes:**
|
||||
1. Verify SSID and password are correct (re-provision if needed)
|
||||
2. Make sure you are on a 2.4 GHz network (ESP32 does not support 5 GHz)
|
||||
3. Move the ESP32 closer to the access point
|
||||
4. Check the serial output for the exact error:
|
||||
|
||||
```bash
|
||||
python -m serial.tools.miniterm COM9 115200
|
||||
```
|
||||
|
||||
Look for lines like `wifi:connected` or `wifi:reason 201` (wrong password).
|
||||
|
||||
### Bridge Shows 0 Packets
|
||||
|
||||
**Symptoms:** Bridge starts but never logs "Ingested" messages.
|
||||
|
||||
**Fixes:**
|
||||
1. Make sure the ESP32's `--target-ip` matches your laptop's IP
|
||||
2. Check that `--target-port` matches `--udp-port` on the bridge (default: 5006)
|
||||
3. Check your firewall -- UDP port 5006 must be open for inbound traffic
|
||||
4. Run the UDP listener test from Section 2.5 to confirm raw packets arrive
|
||||
5. If using `--allowed-sources`, make sure the ESP32 IP addresses are listed
|
||||
|
||||
### Seed Returns 401 Unauthorized
|
||||
|
||||
**Symptoms:** Bridge logs `HTTP Error 401` on ingest.
|
||||
|
||||
**Fixes:**
|
||||
1. Make sure `$SEED_TOKEN` is set correctly: `echo $SEED_TOKEN`
|
||||
2. Re-pair the Seed if the token was lost (Section 2.2)
|
||||
3. Verify the token works with a status query:
|
||||
|
||||
```bash
|
||||
curl -sk -H "Authorization: Bearer $SEED_TOKEN" \
|
||||
https://169.254.42.1:8443/api/v1/store/graph/stats
|
||||
```
|
||||
|
||||
### NaN Values in Features
|
||||
|
||||
**Symptoms:** Bridge logs `Dropping feature packet: features[X]=nan (NaN/inf)`.
|
||||
|
||||
**Fixes:**
|
||||
- This is expected during the first few seconds after ESP32 boot while the
|
||||
DSP pipeline initializes. The bridge automatically drops NaN/inf packets.
|
||||
- If NaN persists beyond 10 seconds, reflash the firmware -- the DSP state
|
||||
may be corrupted.
|
||||
|
||||
### ENOMEM on ESP32 Boot
|
||||
|
||||
**Symptoms:** Serial output shows `E (xxx) heap: alloc failed` or
|
||||
`ENOMEM` errors.
|
||||
|
||||
**Fixes:**
|
||||
1. If using a 4MB flash ESP32-S3, use the 4MB partition table and
|
||||
sdkconfig (see `sdkconfig.defaults.4mb`)
|
||||
2. Reduce buffer sizes by setting edge tier to 1 during provisioning:
|
||||
|
||||
```bash
|
||||
python firmware/esp32-csi-node/provision.py \
|
||||
--port COM9 --edge-tier 1 \
|
||||
--ssid "YourWiFi" --password "YourPassword" \
|
||||
--target-ip 192.168.1.20 --node-id 1
|
||||
```
|
||||
|
||||
### Seed Not Reachable at 169.254.42.1
|
||||
|
||||
**Symptoms:** `curl` to `169.254.42.1:8443` times out.
|
||||
|
||||
**Fixes:**
|
||||
1. Ensure you are using a **data** USB cable (charge-only cables lack data pins)
|
||||
2. Wait 60 seconds after plugging in for the Seed to fully boot
|
||||
3. Check the USB network interface appeared on your host:
|
||||
|
||||
```bash
|
||||
# Windows
|
||||
ipconfig | findstr "169.254"
|
||||
|
||||
# macOS / Linux
|
||||
ip addr show | grep "169.254"
|
||||
```
|
||||
|
||||
4. If the Seed is on WiFi instead, use its WiFi IP (e.g., `192.168.1.109`):
|
||||
|
||||
```bash
|
||||
python scripts/seed_csi_bridge.py \
|
||||
--seed-url https://192.168.1.109:8443 \
|
||||
--token "$SEED_TOKEN"
|
||||
```
|
||||
|
||||
### Bridge Ingest Failures (Connection Reset)
|
||||
|
||||
**Symptoms:** Periodic `Ingest failed` messages, then recovery.
|
||||
|
||||
**Fixes:**
|
||||
- The bridge retries once automatically (2-second delay). Occasional failures
|
||||
are normal when the Seed is rebuilding its kNN graph.
|
||||
- If failures are frequent (>10% of batches), increase `--batch-size` to
|
||||
reduce the number of HTTPS calls:
|
||||
|
||||
```bash
|
||||
python scripts/seed_csi_bridge.py --token "$SEED_TOKEN" --batch-size 20
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. Next Steps
|
||||
|
||||
### Full Contrastive Pretraining (ADR-070)
|
||||
|
||||
This tutorial covers Phase 1 (data collection) of the pretraining pipeline
|
||||
defined in [ADR-070](../adr/ADR-070-self-supervised-pretraining.md). The
|
||||
remaining phases are:
|
||||
|
||||
- **Phase 2: Contrastive pretraining** -- Train a TCN encoder using temporal
|
||||
coherence and multi-node consistency as self-supervised signals
|
||||
- **Phase 3: Downstream heads** -- Attach task-specific heads (presence,
|
||||
person count, activity, vital signs) using weak labels from the Seed's
|
||||
PIR sensor and scenario boundaries
|
||||
- **Phase 4: Package and distribute** -- Export as ONNX model weights for
|
||||
distribution in GitHub releases
|
||||
|
||||
### Architecture Documentation
|
||||
|
||||
- [ADR-069: ESP32 CSI to Cognitum Seed Pipeline](../adr/ADR-069-cognitum-seed-csi-pipeline.md) --
|
||||
Full architecture of the bridge pipeline
|
||||
- [ADR-070: Self-Supervised Pretraining](../adr/ADR-070-self-supervised-pretraining.md) --
|
||||
Complete pretraining pipeline design
|
||||
|
||||
### Multi-Node Mesh
|
||||
|
||||
Scale to 3-4 ESP32 nodes for better spatial coverage. Each node gets a
|
||||
unique `--node-id` and all target the same host laptop. The Seed's kNN
|
||||
graph naturally clusters vectors by node and sensing state.
|
||||
|
||||
### Cognitum Seed Resources
|
||||
|
||||
- [cognitum.one](https://cognitum.one) -- Hardware and firmware information
|
||||
- Seed API: 98 HTTPS endpoints with bearer token authentication
|
||||
- MCP proxy: 114 tools accessible via JSON-RPC 2.0 for AI assistant integration
|
||||
|
||||
### Rust Training Pipeline
|
||||
|
||||
For users with the Rust toolchain, the `wifi-densepose-train` crate
|
||||
provides the full training pipeline with RuVector integration:
|
||||
|
||||
```bash
|
||||
cd rust-port/wifi-densepose-rs
|
||||
cargo run -p wifi-densepose-train -- \
|
||||
--data pretrain-vectors.rvf \
|
||||
--epochs 50 \
|
||||
--output pretrained-encoder.onnx
|
||||
```
|
||||
+1
-291
@@ -21,7 +21,6 @@ WiFi DensePose turns commodity WiFi signals into real-time human pose estimation
|
||||
- [Windows WiFi (RSSI Only)](#windows-wifi-rssi-only)
|
||||
- [ESP32-S3 (Full CSI)](#esp32-s3-full-csi)
|
||||
- [ESP32 Multistatic Mesh (Advanced)](#esp32-multistatic-mesh-advanced)
|
||||
- [Cognitum Seed Integration (ADR-069)](#cognitum-seed-integration-adr-069)
|
||||
5. [REST API Reference](#rest-api-reference)
|
||||
6. [WebSocket Streaming](#websocket-streaming)
|
||||
7. [Web UI](#web-ui)
|
||||
@@ -38,9 +37,7 @@ WiFi DensePose turns commodity WiFi signals into real-time human pose estimation
|
||||
14. [Hardware Setup](#hardware-setup)
|
||||
- [ESP32-S3 Mesh](#esp32-s3-mesh)
|
||||
- [Intel 5300 / Atheros NIC](#intel-5300--atheros-nic)
|
||||
15. [Camera-Free Pose Training](#camera-free-pose-training)
|
||||
16. [ruvllm Training Pipeline](#ruvllm-training-pipeline)
|
||||
17. [Docker Compose (Multi-Service)](#docker-compose-multi-service)
|
||||
15. [Docker Compose (Multi-Service)](#docker-compose-multi-service)
|
||||
16. [Testing Firmware Without Hardware (QEMU)](#testing-firmware-without-hardware-qemu)
|
||||
- [What You Need](#what-you-need)
|
||||
- [Your First Test Run](#your-first-test-run)
|
||||
@@ -317,72 +314,6 @@ The mesh uses a **Time-Division Multiplexing (TDM)** protocol so nodes take turn
|
||||
|
||||
See [ADR-029](adr/ADR-029-ruvsense-multistatic-sensing-mode.md) and [ADR-032](adr/ADR-032-multistatic-mesh-security-hardening.md) for the full design.
|
||||
|
||||
### Cognitum Seed Integration (ADR-069)
|
||||
|
||||
Connect an ESP32-S3 to a [Cognitum Seed](https://cognitum.one) (Pi Zero 2 W, ~$15) for persistent vector storage, kNN similarity search, cryptographic witness chain, and AI-accessible sensing via MCP proxy.
|
||||
|
||||
**What the Seed adds:**
|
||||
- **RVF vector store** — Persistent 8-dim feature vectors with content-addressed IDs and kNN search (cosine, L2, dot product)
|
||||
- **Witness chain** — SHA-256 tamper-evident audit trail for every ingest operation
|
||||
- **Ed25519 custody** — Device-bound keypair for cryptographic attestation of sensing data
|
||||
- **Sensor fusion** — BME280 (temp/humidity/pressure), PIR motion, reed switch, 4-ch ADC provide environmental ground truth
|
||||
- **MCP proxy** — 114 tools via JSON-RPC 2.0 so AI assistants (Claude, GPT) can query sensing state directly
|
||||
- **Reflex rules** — Automatic alarm triggers based on fragility, drift, and anomaly thresholds
|
||||
|
||||
**Setup:**
|
||||
|
||||
```bash
|
||||
# 1. Plug in the Cognitum Seed via USB — appears as a network adapter at 169.254.42.1
|
||||
|
||||
# 2. Pair your client (opens a 30-second window, USB-only for security)
|
||||
curl -sk -X POST https://169.254.42.1:8443/api/v1/pair/window
|
||||
curl -sk -X POST https://169.254.42.1:8443/api/v1/pair \
|
||||
-H 'Content-Type: application/json' -d '{"client_name":"my-laptop"}'
|
||||
# Save the returned token — it is shown only once
|
||||
|
||||
# 3. Provision ESP32 to send features to your laptop (where the bridge runs)
|
||||
python firmware/esp32-csi-node/provision.py --port COM9 \
|
||||
--ssid "YourWiFi" --password "secret" \
|
||||
--target-ip 192.168.1.20 --target-port 5006 --node-id 1
|
||||
|
||||
# 4. Run the bridge (receives ESP32 UDP, ingests into Seed via HTTPS)
|
||||
export SEED_TOKEN="your-pairing-token"
|
||||
python scripts/seed_csi_bridge.py \
|
||||
--seed-url https://169.254.42.1:8443 --token "$SEED_TOKEN" \
|
||||
--udp-port 5006 --batch-size 10 --validate
|
||||
|
||||
# 5. Check Seed status
|
||||
python scripts/seed_csi_bridge.py --token "$SEED_TOKEN" --stats
|
||||
|
||||
# 6. Trigger compaction (reclaim disk space from deleted vectors)
|
||||
python scripts/seed_csi_bridge.py --token "$SEED_TOKEN" --compact
|
||||
```
|
||||
|
||||
**Feature vector dimensions (magic `0xC5110003`, 48 bytes, 1 Hz):**
|
||||
|
||||
| Dim | Feature | Range | Source |
|
||||
|-----|---------|-------|--------|
|
||||
| 0 | Presence score | 0.0–1.0 | `s_presence_score / 10.0` |
|
||||
| 1 | Motion energy | 0.0–1.0 | `s_motion_energy / 10.0` |
|
||||
| 2 | Breathing rate | 0.0–1.0 | `s_breathing_bpm / 30.0` |
|
||||
| 3 | Heart rate | 0.0–1.0 | `s_heartrate_bpm / 120.0` |
|
||||
| 4 | Phase variance | 0.0–1.0 | Mean Welford variance of top-K subcarriers |
|
||||
| 5 | Person count | 0.0–1.0 | Active persons / 4 |
|
||||
| 6 | Fall detected | 0.0 or 1.0 | Binary fall flag |
|
||||
| 7 | RSSI | 0.0–1.0 | `(rssi + 100) / 100` |
|
||||
|
||||
**Architecture:**
|
||||
|
||||
```
|
||||
ESP32-S3 ($9) ──UDP:5006──> Host (bridge) ──HTTPS──> Cognitum Seed ($15)
|
||||
CSI @ 100 Hz seed_csi_bridge.py RVF vector store
|
||||
Features @ 1 Hz Batches, validates kNN graph + boundary
|
||||
Vitals @ 1 Hz NaN rejection Witness chain
|
||||
Source IP filtering 114-tool MCP proxy
|
||||
```
|
||||
|
||||
See [ADR-069](adr/ADR-069-cognitum-seed-csi-pipeline.md) for the complete design, validation results, and security analysis.
|
||||
|
||||
---
|
||||
|
||||
## REST API Reference
|
||||
@@ -1010,227 +941,6 @@ These are advanced setups. See the respective driver documentation for installat
|
||||
|
||||
---
|
||||
|
||||
## Camera-Free Pose Training
|
||||
|
||||
RuView can train a 17-keypoint COCO pose model **without any camera** by fusing 10 sensor signals from the ESP32 nodes and Cognitum Seed:
|
||||
|
||||
| Signal | Source | What it provides |
|
||||
|--------|--------|-----------------|
|
||||
| PIR sensor | Seed GPIO 6 | Binary presence ground truth |
|
||||
| BME280 temperature | Seed I2C | Occupancy proxy (temp rises with people) |
|
||||
| BME280 humidity | Seed I2C | Breathing confirmation |
|
||||
| Cross-node RSSI | 2x ESP32 | Rough XY position (triangulation) |
|
||||
| Vitals stability | ESP32 DSP | Activity level (stable HR = stationary) |
|
||||
| Temporal CSI patterns | ESP32 DSP | Walk (periodic), sit (stable), empty (flat) |
|
||||
| kNN clusters | Seed vector store | Natural state groupings |
|
||||
| Boundary fragility | Seed graph analysis | Regime changes (enter/exit) |
|
||||
| Reed switch | Seed GPIO 5 | Door open/close events |
|
||||
| Vibration sensor | Seed GPIO 13 | Footstep detection |
|
||||
|
||||
### How It Works
|
||||
|
||||
The pipeline generates weak labels from sensor fusion, then trains in 5 phases:
|
||||
|
||||
1. **Multi-modal collection** — Syncs CSI frames with Seed sensor events
|
||||
2. **Weak label generation** — RSSI triangulation for head position, subcarrier asymmetry for hands, vibration for feet
|
||||
3. **5-keypoint pose proxy** — Trains head/hands/feet positions from fused signals
|
||||
4. **17-keypoint interpolation** — Derives full COCO skeleton using bone length constraints
|
||||
5. **Self-refinement** — Bootstraps from confident predictions (3 rounds)
|
||||
|
||||
```bash
|
||||
# With Cognitum Seed connected (all 10 signals):
|
||||
node scripts/train-camera-free.js \
|
||||
--data data/recordings/pretrain-*.csi.jsonl \
|
||||
--seed-url https://169.254.42.1:8443 \
|
||||
--seed-token "$SEED_TOKEN"
|
||||
|
||||
# Without Seed (CSI-only, 3 signals — still works):
|
||||
node scripts/train-camera-free.js \
|
||||
--data data/recordings/pretrain-*.csi.jsonl --no-seed
|
||||
```
|
||||
|
||||
**Output:** 82.8 KB model (8 KB at 4-bit) with 17-keypoint predictions, 0 skeleton violations, LoRA per-node adapters, and EWC protection against forgetting.
|
||||
|
||||
See [ADR-071](adr/ADR-071-ruvllm-training-pipeline.md) and the [pretraining tutorial](tutorials/cognitum-seed-pretraining.md) for the full walkthrough.
|
||||
|
||||
---
|
||||
|
||||
## Camera-Supervised Pose Training (v0.7.0)
|
||||
|
||||
For significantly higher accuracy, use a webcam as a **temporary teacher** during training. The camera captures real 17-keypoint poses via MediaPipe, paired with simultaneous ESP32 CSI data. After training, the camera is no longer needed — the model runs on CSI only.
|
||||
|
||||
**Result: 92.9% PCK@20** from a 5-minute collection session.
|
||||
|
||||
### Requirements
|
||||
|
||||
- Python 3.9+ with `mediapipe` and `opencv-python` (`pip install mediapipe opencv-python`)
|
||||
- ESP32-S3 node streaming CSI over UDP (port 5005)
|
||||
- A webcam (laptop, USB, or Mac camera via Tailscale)
|
||||
|
||||
### Step 1: Capture Camera + CSI Simultaneously
|
||||
|
||||
Run both scripts at the same time (in separate terminals):
|
||||
|
||||
```bash
|
||||
# Terminal 1: Record ESP32 CSI
|
||||
python scripts/record-csi-udp.py --duration 300
|
||||
|
||||
# Terminal 2: Capture camera keypoints
|
||||
python scripts/collect-ground-truth.py --duration 300 --preview
|
||||
```
|
||||
|
||||
Move around naturally in front of the camera for 5 minutes. The `--preview` flag shows a live skeleton overlay.
|
||||
|
||||
### Step 2: Align and Train
|
||||
|
||||
```bash
|
||||
# Align camera keypoints with CSI windows
|
||||
node scripts/align-ground-truth.js \
|
||||
--gt data/ground-truth/*.jsonl \
|
||||
--csi data/recordings/csi-*.csi.jsonl
|
||||
|
||||
# Train (start with lite, scale up as you collect more data)
|
||||
node scripts/train-wiflow-supervised.js \
|
||||
--data data/paired/*.jsonl \
|
||||
--scale lite \
|
||||
--epochs 50
|
||||
|
||||
# Evaluate
|
||||
node scripts/eval-wiflow.js \
|
||||
--model models/wiflow-supervised/wiflow-v1.json \
|
||||
--data data/paired/*.jsonl
|
||||
```
|
||||
|
||||
### Scale Presets
|
||||
|
||||
| Preset | Params | Training Time | Best For |
|
||||
|--------|--------|---------------|----------|
|
||||
| `--scale lite` | 189K | ~19 min | < 1,000 samples (5 min capture) |
|
||||
| `--scale small` | 474K | ~1 hr | 1K-10K samples |
|
||||
| `--scale medium` | 800K | ~2 hrs | 10K-50K samples |
|
||||
| `--scale full` | 7.7M | ~8 hrs | 50K+ samples (GPU recommended) |
|
||||
|
||||
See [ADR-079](adr/ADR-079-camera-ground-truth-training.md) for the full design and optimization details.
|
||||
|
||||
---
|
||||
|
||||
## Pre-Trained Models (No Training Required)
|
||||
|
||||
Pre-trained models are available on HuggingFace: **https://huggingface.co/ruvnet/wifi-densepose-pretrained**
|
||||
|
||||
Download and start sensing immediately — no datasets, no GPU, no training needed.
|
||||
|
||||
### Quick Start with Pre-Trained Models
|
||||
|
||||
```bash
|
||||
# Install huggingface CLI
|
||||
pip install huggingface_hub
|
||||
|
||||
# Download all models
|
||||
huggingface-cli download ruvnet/wifi-densepose-pretrained --local-dir models/pretrained
|
||||
|
||||
# The models include:
|
||||
# model.safetensors — 48 KB contrastive encoder
|
||||
# model-q4.bin — 8 KB quantized (recommended)
|
||||
# model-q2.bin — 4 KB ultra-compact (ESP32 edge)
|
||||
# presence-head.json — presence detection head (100% accuracy)
|
||||
# node-1.json — LoRA adapter for room 1
|
||||
# node-2.json — LoRA adapter for room 2
|
||||
```
|
||||
|
||||
### What the Models Do
|
||||
|
||||
The pre-trained encoder converts 8-dim CSI feature vectors into 128-dim embeddings. These embeddings power all 17 sensing applications:
|
||||
|
||||
- **Presence detection** — 100% accuracy, never misses, never false alarms
|
||||
- **Environment fingerprinting** — kNN search finds "states like this one"
|
||||
- **Anomaly detection** — embeddings that don't match known clusters = anomaly
|
||||
- **Activity classification** — different activities cluster in embedding space
|
||||
- **Room adaptation** — swap LoRA adapters for different rooms without retraining
|
||||
|
||||
### Retraining on Your Own Data
|
||||
|
||||
If you want to improve accuracy for your specific environment:
|
||||
|
||||
```bash
|
||||
# Collect 2+ minutes of CSI from your ESP32
|
||||
python scripts/collect-training-data.py --port 5006 --duration 120
|
||||
|
||||
# Retrain (uses ruvllm, no PyTorch needed)
|
||||
node scripts/train-ruvllm.js --data data/recordings/*.csi.jsonl
|
||||
|
||||
# Benchmark your retrained model
|
||||
node scripts/benchmark-ruvllm.js --model models/csi-ruvllm
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Health & Wellness Applications
|
||||
|
||||
WiFi sensing can monitor health metrics without any wearable or camera:
|
||||
|
||||
```bash
|
||||
# Sleep quality monitoring (run overnight)
|
||||
node scripts/sleep-monitor.js --port 5006 --bind 192.168.1.20
|
||||
|
||||
# Breathing disorder pre-screening
|
||||
node scripts/apnea-detector.js --port 5006 --bind 192.168.1.20
|
||||
|
||||
# Stress detection via heart rate variability
|
||||
node scripts/stress-monitor.js --port 5006 --bind 192.168.1.20
|
||||
|
||||
# Walking analysis + tremor detection
|
||||
node scripts/gait-analyzer.js --port 5006 --bind 192.168.1.20
|
||||
|
||||
# Replay on recorded data (no live hardware needed)
|
||||
node scripts/sleep-monitor.js --replay data/recordings/*.csi.jsonl
|
||||
```
|
||||
|
||||
> **Note:** These are pre-screening tools, not medical devices. Consult a healthcare professional for diagnosis.
|
||||
|
||||
---
|
||||
|
||||
## ruvllm Training Pipeline
|
||||
|
||||
All training uses **ruvllm** — a Rust-native ML runtime. No Python, no PyTorch, no GPU drivers required. Runs on any machine with Node.js.
|
||||
|
||||
### 5-Phase Training
|
||||
|
||||
| Phase | What | Duration (M4 Pro) |
|
||||
|-------|------|--------------------|
|
||||
| Contrastive pretraining | Triplet + InfoNCE loss on CSI embeddings | ~5s |
|
||||
| Task head training | Presence, activity, vitals classifiers | ~10s |
|
||||
| LoRA refinement | Per-node room adaptation (rank-4) | ~4s |
|
||||
| TurboQuant quantization | 2/4/8-bit with <0.5% quality loss | <1s |
|
||||
| EWC consolidation | Prevent catastrophic forgetting | <1s |
|
||||
|
||||
```bash
|
||||
# Basic training
|
||||
node scripts/train-ruvllm.js --data data/recordings/pretrain-*.csi.jsonl
|
||||
|
||||
# Benchmark
|
||||
node scripts/benchmark-ruvllm.js --model models/csi-ruvllm
|
||||
```
|
||||
|
||||
### Quantization Options
|
||||
|
||||
| Bits | Size | Compression | Quality Loss | Use Case |
|
||||
|------|------|-------------|-------------|----------|
|
||||
| fp32 | 48 KB | 1x | 0% | Development |
|
||||
| 8-bit | 16 KB | 4x | <0.01% | Cognitum Seed inference |
|
||||
| 4-bit | 8 KB | 8x | <0.1% | Recommended for deployment |
|
||||
| 2-bit | 4 KB | 16x | <1% | ESP32-S3 SRAM (edge inference) |
|
||||
|
||||
### Key Features
|
||||
|
||||
- **SONA adaptation** — Adapts to new rooms in <1ms without retraining
|
||||
- **LoRA adapters** — 2,048 parameters per room, hot-swappable
|
||||
- **EWC protection** — Learns new rooms without forgetting previous ones
|
||||
- **Deterministic** — Same seed always produces same model (reproducible)
|
||||
- **10x data augmentation** — Temporal interpolation, noise injection, cross-node blending
|
||||
|
||||
---
|
||||
|
||||
## Docker Compose (Multi-Service)
|
||||
|
||||
For production deployments with both Rust and Python services:
|
||||
|
||||
@@ -15,10 +15,10 @@
|
||||
set -euo pipefail
|
||||
|
||||
# ---- Configuration ----
|
||||
SSID="${SWARM_WIFI_SSID:?Set SWARM_WIFI_SSID env var}"
|
||||
PASSWORD="${SWARM_WIFI_PASSWORD:?Set SWARM_WIFI_PASSWORD env var}"
|
||||
SEED_URL="${SWARM_SEED_URL:?Set SWARM_SEED_URL env var}"
|
||||
SEED_TOKEN="${SWARM_SEED_TOKEN:?Set SWARM_SEED_TOKEN env var}"
|
||||
SSID="RedCloverWifi"
|
||||
PASSWORD="redclover2.4"
|
||||
SEED_URL="http://10.1.10.236"
|
||||
SEED_TOKEN="hyHVY4Ux6uBAh8FaQzF_9OwWCWMFB-YuM2OJ3Dcwdm8" # Replace with your token
|
||||
|
||||
PROVISION="../../firmware/esp32-csi-node/provision.py"
|
||||
|
||||
|
||||
@@ -4,10 +4,5 @@ cmake_minimum_required(VERSION 3.16)
|
||||
|
||||
set(EXTRA_COMPONENT_DIRS "")
|
||||
|
||||
# Read firmware version from version.txt so esp_app_get_description()->version
|
||||
# matches the release tag. Fixes issue #354 (version mismatch after flashing).
|
||||
file(STRINGS "${CMAKE_CURRENT_LIST_DIR}/version.txt" PROJECT_VER LIMIT_COUNT 1)
|
||||
string(STRIP "${PROJECT_VER}" PROJECT_VER)
|
||||
|
||||
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
|
||||
project(esp32-csi-node VERSION ${PROJECT_VER})
|
||||
project(esp32-csi-node)
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
@echo off
|
||||
echo STARTING > C:\Users\ruv\idf_test.txt
|
||||
set IDF_PATH=C:\Users\ruv\esp\v5.4\esp-idf
|
||||
set PATH=C:\Espressif\tools\python\v5.4\venv\Scripts;C:\Espressif\tools\xtensa-esp-elf\esp-14.2.0_20241119\xtensa-esp-elf\bin;C:\Espressif\tools\cmake\3.30.2\bin;C:\Espressif\tools\ninja\1.12.1;C:\Espressif\tools\idf-exe\1.0.3;%PATH%
|
||||
echo PATH_SET >> C:\Users\ruv\idf_test.txt
|
||||
cd /d C:\Users\ruv\Projects\wifi-densepose\firmware\esp32-csi-node
|
||||
echo CD_DONE >> C:\Users\ruv\idf_test.txt
|
||||
python %IDF_PATH%\tools\idf.py build >> C:\Users\ruv\idf_test.txt 2>&1
|
||||
echo RC=%ERRORLEVEL% >> C:\Users\ruv\idf_test.txt
|
||||
@@ -76,6 +76,7 @@ menu "Edge Intelligence (ADR-039)"
|
||||
Raise to reduce false positives in high-traffic environments.
|
||||
Normal walking produces accelerations of 2-5 rad/s².
|
||||
Stored as integer; divided by 1000 at runtime.
|
||||
Default 2000 = 2.0 rad/s^2.
|
||||
|
||||
config EDGE_POWER_DUTY
|
||||
int "Power duty cycle percentage"
|
||||
|
||||
@@ -118,14 +118,8 @@ esp_err_t display_task_start(void)
|
||||
if (!buf1 || !buf2) {
|
||||
ESP_LOGE(TAG, "Failed to allocate LVGL buffers (%u bytes, caps=0x%lx)",
|
||||
(unsigned)buf_size, (unsigned long)alloc_caps);
|
||||
if (buf1) {
|
||||
free(buf1);
|
||||
buf1 = NULL;
|
||||
}
|
||||
if (buf2) {
|
||||
free(buf2);
|
||||
buf2 = NULL;
|
||||
}
|
||||
if (buf1) free(buf1);
|
||||
if (buf2) free(buf2);
|
||||
return ESP_OK;
|
||||
}
|
||||
ESP_LOGI(TAG, "LVGL buffers: 2x %u bytes (%u lines, %s)",
|
||||
|
||||
@@ -43,12 +43,6 @@ static const char *TAG = "edge_proc";
|
||||
static edge_ring_buf_t s_ring;
|
||||
static uint32_t s_ring_drops; /* Frames dropped due to full ring buffer. */
|
||||
|
||||
/* Scratch buffers for BPM estimation — moved from stack to static to avoid
|
||||
* stack overflow. process_frame + update_multi_person_vitals combined used
|
||||
* ~6.5-7.5 KB of the 8 KB task stack. These save ~4 KB of stack. */
|
||||
static float s_scratch_br[EDGE_PHASE_HISTORY_LEN];
|
||||
static float s_scratch_hr[EDGE_PHASE_HISTORY_LEN];
|
||||
|
||||
static inline bool ring_push(const uint8_t *iq, uint16_t len,
|
||||
int8_t rssi, uint8_t channel)
|
||||
{
|
||||
@@ -276,9 +270,6 @@ static uint8_t s_prev_iq[EDGE_MAX_IQ_BYTES];
|
||||
static uint16_t s_prev_iq_len;
|
||||
static bool s_has_prev_iq;
|
||||
|
||||
/** ADR-069: Feature vector sequence counter. */
|
||||
static uint16_t s_feature_seq;
|
||||
|
||||
/** Multi-person vitals state. */
|
||||
static edge_person_vitals_t s_persons[EDGE_MAX_PERSONS];
|
||||
static edge_biquad_t s_person_bq_br[EDGE_MAX_PERSONS];
|
||||
@@ -413,10 +404,10 @@ static uint16_t delta_compress(const uint8_t *curr, uint16_t len,
|
||||
}
|
||||
|
||||
/**
|
||||
* Send a compressed CSI frame (magic 0xC5110005, reassigned from 0xC5110003 for ADR-069).
|
||||
* Send a compressed CSI frame (magic 0xC5110003).
|
||||
*
|
||||
* Header:
|
||||
* [0..3] Magic 0xC5110005 (LE)
|
||||
* [0..3] Magic 0xC5110003 (LE)
|
||||
* [4] Node ID
|
||||
* [5] Channel
|
||||
* [6..7] Original I/Q length (LE u16)
|
||||
@@ -522,18 +513,20 @@ static void update_multi_person_vitals(const uint8_t *iq_data, uint16_t n_sc,
|
||||
|
||||
/* Estimate BPM when we have enough history. */
|
||||
if (pv->history_len >= 64) {
|
||||
/* Build contiguous buffer (reuse static scratch to save ~2 KB stack). */
|
||||
/* Build contiguous buffer for zero-crossing. */
|
||||
float br_buf[EDGE_PHASE_HISTORY_LEN];
|
||||
float hr_buf[EDGE_PHASE_HISTORY_LEN];
|
||||
uint16_t buf_len = pv->history_len;
|
||||
|
||||
for (uint16_t i = 0; i < buf_len; i++) {
|
||||
uint16_t ri = (pv->history_idx + EDGE_PHASE_HISTORY_LEN
|
||||
- buf_len + i) % EDGE_PHASE_HISTORY_LEN;
|
||||
s_scratch_br[i] = s_person_br_filt[p][ri];
|
||||
s_scratch_hr[i] = s_person_hr_filt[p][ri];
|
||||
br_buf[i] = s_person_br_filt[p][ri];
|
||||
hr_buf[i] = s_person_hr_filt[p][ri];
|
||||
}
|
||||
|
||||
float br = estimate_bpm_zero_crossing(s_scratch_br, buf_len, sample_rate);
|
||||
float hr = estimate_bpm_zero_crossing(s_scratch_hr, buf_len, sample_rate);
|
||||
float br = estimate_bpm_zero_crossing(br_buf, buf_len, sample_rate);
|
||||
float hr = estimate_bpm_zero_crossing(hr_buf, buf_len, sample_rate);
|
||||
|
||||
/* Sanity clamp. */
|
||||
if (br >= 6.0f && br <= 40.0f) pv->breathing_bpm = br;
|
||||
@@ -637,70 +630,6 @@ static void send_vitals_packet(void)
|
||||
}
|
||||
}
|
||||
|
||||
/* ======================================================================
|
||||
* ADR-069: Feature Vector Packet (48 bytes, sent at 1 Hz alongside vitals)
|
||||
* ====================================================================== */
|
||||
|
||||
static void send_feature_vector(void)
|
||||
{
|
||||
edge_feature_pkt_t pkt;
|
||||
memset(&pkt, 0, sizeof(pkt));
|
||||
|
||||
pkt.magic = EDGE_FEATURE_MAGIC;
|
||||
pkt.node_id = g_nvs_config.node_id;
|
||||
pkt.reserved = 0;
|
||||
pkt.seq = s_feature_seq++;
|
||||
pkt.timestamp_us = esp_timer_get_time();
|
||||
|
||||
/* Dim 0: Presence score (0.0-1.0, normalized from raw score) */
|
||||
float p = s_presence_score;
|
||||
pkt.features[0] = p > 10.0f ? 1.0f : (p < 0.0f ? 0.0f : p / 10.0f);
|
||||
|
||||
/* Dim 1: Motion energy (normalized, 0-1 range) */
|
||||
float m = s_motion_energy;
|
||||
pkt.features[1] = m > 10.0f ? 1.0f : (m < 0.0f ? 0.0f : m / 10.0f);
|
||||
|
||||
/* Dim 2: Breathing rate (BPM / 30, 0-1 range) */
|
||||
pkt.features[2] = s_breathing_bpm > 0.0f
|
||||
? (s_breathing_bpm / 30.0f > 1.0f ? 1.0f : s_breathing_bpm / 30.0f)
|
||||
: 0.0f;
|
||||
|
||||
/* Dim 3: Heart rate (BPM / 120, 0-1 range) */
|
||||
pkt.features[3] = s_heartrate_bpm > 0.0f
|
||||
? (s_heartrate_bpm / 120.0f > 1.0f ? 1.0f : s_heartrate_bpm / 120.0f)
|
||||
: 0.0f;
|
||||
|
||||
/* Dim 4: Phase variance mean (top-K subcarriers) */
|
||||
float var_mean = 0.0f;
|
||||
if (s_top_k_count > 0) {
|
||||
float var_sum = 0.0f;
|
||||
uint8_t k = s_top_k_count < EDGE_TOP_K ? s_top_k_count : EDGE_TOP_K;
|
||||
for (uint8_t i = 0; i < k; i++) {
|
||||
var_sum += (float)welford_variance(&s_subcarrier_var[s_top_k[i]]);
|
||||
}
|
||||
var_mean = var_sum / (float)k;
|
||||
}
|
||||
pkt.features[4] = var_mean > 1.0f ? 1.0f : (var_mean < 0.0f ? 0.0f : var_mean);
|
||||
|
||||
/* Dim 5: Person count (n_persons / 4, 0-1 range) */
|
||||
uint8_t n_active = 0;
|
||||
for (uint8_t i = 0; i < EDGE_MAX_PERSONS; i++) {
|
||||
if (s_persons[i].active) n_active++;
|
||||
}
|
||||
pkt.features[5] = (float)n_active / 4.0f;
|
||||
if (pkt.features[5] > 1.0f) pkt.features[5] = 1.0f;
|
||||
|
||||
/* Dim 6: Fall risk (0.0 or 1.0 based on recent detection) */
|
||||
pkt.features[6] = s_fall_detected ? 1.0f : 0.0f;
|
||||
|
||||
/* Dim 7: RSSI normalized ((rssi + 100) / 100, 0-1 range) */
|
||||
pkt.features[7] = ((float)s_latest_rssi + 100.0f) / 100.0f;
|
||||
if (pkt.features[7] > 1.0f) pkt.features[7] = 1.0f;
|
||||
if (pkt.features[7] < 0.0f) pkt.features[7] = 0.0f;
|
||||
|
||||
stream_sender_send((const uint8_t *)&pkt, sizeof(pkt));
|
||||
}
|
||||
|
||||
/* ======================================================================
|
||||
* Main DSP Pipeline (runs on Core 1)
|
||||
* ====================================================================== */
|
||||
@@ -761,18 +690,20 @@ static void process_frame(const edge_ring_slot_t *slot)
|
||||
|
||||
/* --- Step 7: BPM estimation (zero-crossing) --- */
|
||||
if (s_history_len >= 64) {
|
||||
/* Build contiguous buffers from ring (using static scratch to save stack). */
|
||||
/* Build contiguous buffers from ring. */
|
||||
float br_buf[EDGE_PHASE_HISTORY_LEN];
|
||||
float hr_buf[EDGE_PHASE_HISTORY_LEN];
|
||||
uint16_t buf_len = s_history_len;
|
||||
|
||||
for (uint16_t i = 0; i < buf_len; i++) {
|
||||
uint16_t ri = (s_history_idx + EDGE_PHASE_HISTORY_LEN
|
||||
- buf_len + i) % EDGE_PHASE_HISTORY_LEN;
|
||||
s_scratch_br[i] = s_breathing_filtered[ri];
|
||||
s_scratch_hr[i] = s_heartrate_filtered[ri];
|
||||
br_buf[i] = s_breathing_filtered[ri];
|
||||
hr_buf[i] = s_heartrate_filtered[ri];
|
||||
}
|
||||
|
||||
float br_bpm = estimate_bpm_zero_crossing(s_scratch_br, buf_len, sample_rate);
|
||||
float hr_bpm = estimate_bpm_zero_crossing(s_scratch_hr, buf_len, sample_rate);
|
||||
float br_bpm = estimate_bpm_zero_crossing(br_buf, buf_len, sample_rate);
|
||||
float hr_bpm = estimate_bpm_zero_crossing(hr_buf, buf_len, sample_rate);
|
||||
|
||||
/* Sanity clamp: breathing 6-40 BPM, heart rate 40-180 BPM. */
|
||||
if (br_bpm >= 6.0f && br_bpm <= 40.0f) s_breathing_bpm = br_bpm;
|
||||
@@ -855,7 +786,6 @@ static void process_frame(const edge_ring_slot_t *slot)
|
||||
int64_t interval_us = (int64_t)s_cfg.vital_interval_ms * 1000;
|
||||
if ((now_us - s_last_vitals_send_us) >= interval_us) {
|
||||
send_vitals_packet();
|
||||
send_feature_vector(); /* ADR-069: 48-byte feature vector at same 1 Hz cadence. */
|
||||
s_last_vitals_send_us = now_us;
|
||||
|
||||
if ((s_frame_count % 200) == 0) {
|
||||
@@ -909,11 +839,12 @@ static void edge_task(void *arg)
|
||||
* Without a batch limit the task processes frames back-to-back with
|
||||
* only 1-tick yields, which on high frame rates can still starve
|
||||
* IDLE1 enough to trip the 5-second task watchdog. See #266, #321. */
|
||||
const uint8_t BATCH_LIMIT = 4;
|
||||
|
||||
while (1) {
|
||||
uint8_t processed = 0;
|
||||
|
||||
while (processed < EDGE_BATCH_LIMIT && ring_pop(&slot)) {
|
||||
while (processed < BATCH_LIMIT && ring_pop(&slot)) {
|
||||
process_frame(&slot);
|
||||
processed++;
|
||||
/* 1-tick yield between frames within a batch. */
|
||||
@@ -921,10 +852,10 @@ static void edge_task(void *arg)
|
||||
}
|
||||
|
||||
if (processed > 0) {
|
||||
/* Post-batch yield: ~20 ms so IDLE1 can run and feed the
|
||||
* Core 1 watchdog even under sustained load. Uses pdMS_TO_TICKS
|
||||
* for tick-rate independence (minimum 1 tick). */
|
||||
{ TickType_t d = pdMS_TO_TICKS(20); vTaskDelay(d > 0 ? d : 1); }
|
||||
/* Post-batch yield: 2 ticks (~20 ms at 100 Hz) so IDLE1 can
|
||||
* run and feed the Core 1 watchdog even under sustained load.
|
||||
* This is intentionally longer than the 1-tick inter-frame yield. */
|
||||
vTaskDelay(2);
|
||||
} else {
|
||||
/* No frames available — sleep one full tick.
|
||||
* NOTE: pdMS_TO_TICKS(5) == 0 at 100 Hz, which would busy-spin. */
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
|
||||
/* ---- Magic numbers ---- */
|
||||
#define EDGE_VITALS_MAGIC 0xC5110002 /**< Vitals packet magic. */
|
||||
#define EDGE_COMPRESSED_MAGIC 0xC5110005 /**< Compressed frame magic (was 0xC5110003, reassigned for ADR-069). */
|
||||
#define EDGE_COMPRESSED_MAGIC 0xC5110003 /**< Compressed frame magic. */
|
||||
|
||||
/* ---- Buffer sizes ---- */
|
||||
#define EDGE_RING_SLOTS 16 /**< SPSC ring buffer slots (power of 2). */
|
||||
@@ -46,9 +46,6 @@
|
||||
#define EDGE_FALL_COOLDOWN_MS 5000 /**< Minimum ms between fall alerts (debounce). */
|
||||
#define EDGE_FALL_CONSEC_MIN 3 /**< Consecutive frames above threshold to trigger. */
|
||||
|
||||
/* ---- DSP task tuning ---- */
|
||||
#define EDGE_BATCH_LIMIT 4 /**< Max frames per batch before longer yield. */
|
||||
|
||||
/* ---- SPSC ring buffer slot ---- */
|
||||
typedef struct {
|
||||
uint8_t iq_data[EDGE_MAX_IQ_BYTES]; /**< Raw I/Q bytes from CSI callback. */
|
||||
@@ -109,20 +106,6 @@ typedef struct __attribute__((packed)) {
|
||||
|
||||
_Static_assert(sizeof(edge_vitals_pkt_t) == 32, "vitals packet must be 32 bytes");
|
||||
|
||||
/* ---- ADR-069: CSI Feature Vector packet (48 bytes, wire format) ---- */
|
||||
#define EDGE_FEATURE_MAGIC 0xC5110003 /**< Feature vector packet magic. */
|
||||
|
||||
typedef struct __attribute__((packed)) {
|
||||
uint32_t magic; /**< EDGE_FEATURE_MAGIC = 0xC5110003. */
|
||||
uint8_t node_id; /**< ESP32 node identifier. */
|
||||
uint8_t reserved; /**< Alignment padding. */
|
||||
uint16_t seq; /**< Sequence number. */
|
||||
int64_t timestamp_us; /**< Microseconds since boot. */
|
||||
float features[8]; /**< 8-dim normalized feature vector. */
|
||||
} edge_feature_pkt_t;
|
||||
|
||||
_Static_assert(sizeof(edge_feature_pkt_t) == 48, "feature packet must be 48 bytes");
|
||||
|
||||
/* ---- ADR-063: Fused vitals packet (48 bytes, wire format) ---- */
|
||||
#define EDGE_FUSED_MAGIC 0xC5110004 /**< Fused vitals packet magic. */
|
||||
|
||||
|
||||
@@ -16,7 +16,6 @@
|
||||
#include "esp_event.h"
|
||||
#include "esp_log.h"
|
||||
#include "nvs_flash.h"
|
||||
#include "esp_app_desc.h"
|
||||
#include "sdkconfig.h"
|
||||
|
||||
#include "csi_collector.h"
|
||||
@@ -138,9 +137,7 @@ void app_main(void)
|
||||
/* Load runtime config (NVS overrides Kconfig defaults) */
|
||||
nvs_config_load(&g_nvs_config);
|
||||
|
||||
const esp_app_desc_t *app_desc = esp_app_get_description();
|
||||
ESP_LOGI(TAG, "ESP32-S3 CSI Node (ADR-018) — v%s — Node ID: %d",
|
||||
app_desc->version, g_nvs_config.node_id);
|
||||
ESP_LOGI(TAG, "ESP32-S3 CSI Node (ADR-018) — Node ID: %d", g_nvs_config.node_id);
|
||||
|
||||
/* Initialize WiFi STA (skip entirely under QEMU mock — no RF hardware) */
|
||||
#ifndef CONFIG_CSI_MOCK_SKIP_WIFI_CONNECT
|
||||
@@ -170,17 +167,6 @@ void app_main(void)
|
||||
}
|
||||
#else
|
||||
csi_collector_init();
|
||||
|
||||
/* ADR-073: Start multi-frequency channel hopping if configured in NVS. */
|
||||
if (g_nvs_config.channel_hop_count > 1) {
|
||||
ESP_LOGI(TAG, "Starting channel hopping: %u channels, dwell=%lu ms",
|
||||
(unsigned)g_nvs_config.channel_hop_count,
|
||||
(unsigned long)g_nvs_config.dwell_ms);
|
||||
csi_collector_set_hop_table(
|
||||
g_nvs_config.channel_list,
|
||||
g_nvs_config.channel_hop_count,
|
||||
g_nvs_config.dwell_ms);
|
||||
}
|
||||
#endif
|
||||
|
||||
/* ADR-039: Initialize edge processing pipeline. */
|
||||
|
||||
File diff suppressed because one or more lines are too long
Binary file not shown.
@@ -71,14 +71,6 @@ def build_nvs_csv(args):
|
||||
mac_bytes = bytes(int(b, 16) for b in args.filter_mac.split(":"))
|
||||
# NVS blob: write as hex-encoded string for CSV compatibility
|
||||
writer.writerow(["filter_mac", "data", "hex2bin", mac_bytes.hex()])
|
||||
# ADR-073: Multi-frequency channel hopping
|
||||
if args.hop_channels is not None:
|
||||
channels = [int(c.strip()) for c in args.hop_channels.split(",")]
|
||||
writer.writerow(["hop_count", "data", "u8", str(len(channels))])
|
||||
# Store as NVS blob (firmware reads "chan_list" as uint8 blob)
|
||||
chan_bytes = bytes(channels)
|
||||
writer.writerow(["chan_list", "data", "hex2bin", chan_bytes.hex()])
|
||||
writer.writerow(["dwell_ms", "data", "u32", str(args.hop_dwell)])
|
||||
# ADR-066: Swarm bridge configuration
|
||||
if args.seed_url is not None:
|
||||
writer.writerow(["seed_url", "data", "string", args.seed_url])
|
||||
@@ -189,9 +181,6 @@ def main():
|
||||
parser.add_argument("--channel", type=int, help="CSI channel (1-14 for 2.4GHz, 36-177 for 5GHz). "
|
||||
"Overrides auto-detection from connected AP.")
|
||||
parser.add_argument("--filter-mac", type=str, help="MAC address to filter CSI frames (AA:BB:CC:DD:EE:FF)")
|
||||
# ADR-073: Multi-frequency channel hopping
|
||||
parser.add_argument("--hop-channels", type=str, help="Comma-separated channel list for hopping (e.g. '1,6,11')")
|
||||
parser.add_argument("--hop-dwell", type=int, default=200, help="Dwell time per channel in ms (default: 200)")
|
||||
# ADR-066: Swarm bridge
|
||||
parser.add_argument("--seed-url", type=str, help="Cognitum Seed base URL (e.g. http://10.1.10.236)")
|
||||
parser.add_argument("--seed-token", type=str, help="Seed Bearer token (from pairing)")
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
File diff suppressed because one or more lines are too long
Binary file not shown.
Binary file not shown.
@@ -1,33 +0,0 @@
|
||||
# ESP32-S3 CSI Node — Default SDK Configuration
|
||||
# This file is applied automatically by idf.py when no sdkconfig exists.
|
||||
|
||||
# Target: ESP32-S3
|
||||
CONFIG_IDF_TARGET="esp32s3"
|
||||
|
||||
# Use custom partition table (8MB flash with OTA — ADR-045)
|
||||
CONFIG_PARTITION_TABLE_CUSTOM=y
|
||||
CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions_display.csv"
|
||||
|
||||
# Flash configuration: 8MB (Quad SPI)
|
||||
CONFIG_ESPTOOLPY_FLASHSIZE_8MB=y
|
||||
CONFIG_ESPTOOLPY_FLASHSIZE="8MB"
|
||||
|
||||
# Compiler optimization: optimize for size to reduce binary
|
||||
CONFIG_COMPILER_OPTIMIZATION_SIZE=y
|
||||
|
||||
# Enable CSI (Channel State Information) in WiFi driver
|
||||
CONFIG_ESP_WIFI_CSI_ENABLED=y
|
||||
|
||||
# NVS encryption disabled by default (requires eFuse provisioning).
|
||||
# Enable only after burning HMAC key to eFuse block.
|
||||
# CONFIG_NVS_ENCRYPTION is not set
|
||||
|
||||
# Disable unused features to reduce binary size
|
||||
CONFIG_BOOTLOADER_LOG_LEVEL_WARN=y
|
||||
CONFIG_LOG_DEFAULT_LEVEL_INFO=y
|
||||
|
||||
# LWIP: enable extended socket options for UDP multicast
|
||||
CONFIG_LWIP_SO_RCVBUF=y
|
||||
|
||||
# FreeRTOS: increase task stack for CSI processing
|
||||
CONFIG_ESP_MAIN_TASK_STACK_SIZE=8192
|
||||
@@ -1 +0,0 @@
|
||||
0.6.0
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1 +0,0 @@
|
||||
{"intelligence":35,"timestamp":1774903706609}
|
||||
Generated
-1
@@ -7769,7 +7769,6 @@ dependencies = [
|
||||
"chrono",
|
||||
"clap",
|
||||
"futures-util",
|
||||
"ruvector-mincut",
|
||||
"serde",
|
||||
"serde_json",
|
||||
"tempfile",
|
||||
|
||||
@@ -117,7 +117,6 @@ midstreamer-temporal-compare = "0.1.0"
|
||||
midstreamer-attractor = "0.1.0"
|
||||
|
||||
# ruvector integration (published on crates.io)
|
||||
# Vendored at v2.1.0 in vendor/ruvector; using crates.io versions until published.
|
||||
ruvector-mincut = "2.0.4"
|
||||
ruvector-attn-mincut = "2.0.4"
|
||||
ruvector-temporal-tensor = "2.0.4"
|
||||
|
||||
@@ -330,36 +330,9 @@ impl<B: Backend> InferenceEngine<B> {
|
||||
Ok(result)
|
||||
}
|
||||
|
||||
/// Run batched inference.
|
||||
///
|
||||
/// Stacks all inputs along a new batch dimension, runs a single
|
||||
/// backend call, then splits the output back into individual tensors.
|
||||
/// Falls back to sequential inference if stack/split fails.
|
||||
/// Run batched inference
|
||||
pub fn infer_batch(&self, inputs: &[Tensor]) -> NnResult<Vec<Tensor>> {
|
||||
if inputs.is_empty() {
|
||||
return Ok(Vec::new());
|
||||
}
|
||||
if inputs.len() == 1 {
|
||||
return Ok(vec![self.infer(&inputs[0])?]);
|
||||
}
|
||||
// Try batched path: stack -> single call -> split
|
||||
match Tensor::stack(inputs) {
|
||||
Ok(batched_input) => {
|
||||
let n = inputs.len();
|
||||
let batched_output = self.backend.run_single(&batched_input)?;
|
||||
match batched_output.split(n) {
|
||||
Ok(outputs) => Ok(outputs),
|
||||
Err(_) => {
|
||||
// Fallback: sequential
|
||||
inputs.iter().map(|input| self.infer(input)).collect()
|
||||
}
|
||||
}
|
||||
}
|
||||
Err(_) => {
|
||||
// Fallback: sequential if shapes are incompatible
|
||||
inputs.iter().map(|input| self.infer(input)).collect()
|
||||
}
|
||||
}
|
||||
inputs.iter().map(|input| self.infer(input)).collect()
|
||||
}
|
||||
|
||||
/// Get inference statistics
|
||||
|
||||
@@ -304,74 +304,6 @@ impl Tensor {
|
||||
}
|
||||
}
|
||||
|
||||
/// Stack multiple tensors along a new batch dimension (dim 0).
|
||||
///
|
||||
/// All tensors must have the same shape. The result has one extra
|
||||
/// leading dimension equal to `tensors.len()`.
|
||||
pub fn stack(tensors: &[Tensor]) -> NnResult<Tensor> {
|
||||
if tensors.is_empty() {
|
||||
return Err(NnError::tensor_op("Cannot stack zero tensors"));
|
||||
}
|
||||
let first_shape = tensors[0].shape();
|
||||
for (i, t) in tensors.iter().enumerate().skip(1) {
|
||||
if t.shape() != first_shape {
|
||||
return Err(NnError::tensor_op(&format!(
|
||||
"Shape mismatch at index {i}: expected {first_shape}, got {}",
|
||||
t.shape()
|
||||
)));
|
||||
}
|
||||
}
|
||||
let mut all_data: Vec<f32> = Vec::with_capacity(tensors.len() * first_shape.numel());
|
||||
for t in tensors {
|
||||
let data = t.to_vec()?;
|
||||
all_data.extend_from_slice(&data);
|
||||
}
|
||||
let mut new_dims = vec![tensors.len()];
|
||||
new_dims.extend_from_slice(first_shape.dims());
|
||||
let arr = ndarray::ArrayD::from_shape_vec(
|
||||
ndarray::IxDyn(&new_dims),
|
||||
all_data,
|
||||
)
|
||||
.map_err(|e| NnError::tensor_op(&format!("Stack reshape failed: {e}")))?;
|
||||
Ok(Tensor::FloatND(arr))
|
||||
}
|
||||
|
||||
/// Split a tensor along dim 0 into `n` sub-tensors.
|
||||
///
|
||||
/// The first dimension must be evenly divisible by `n`.
|
||||
pub fn split(self, n: usize) -> NnResult<Vec<Tensor>> {
|
||||
if n == 0 {
|
||||
return Err(NnError::tensor_op("Cannot split into 0 pieces"));
|
||||
}
|
||||
let shape = self.shape();
|
||||
let batch = shape.dim(0).ok_or_else(|| NnError::tensor_op("Tensor has no dimensions"))?;
|
||||
if batch % n != 0 {
|
||||
return Err(NnError::tensor_op(&format!(
|
||||
"Batch dim {batch} not divisible by {n}"
|
||||
)));
|
||||
}
|
||||
let chunk_size = batch / n;
|
||||
let data = self.to_vec()?;
|
||||
let elem_per_sample = shape.numel() / batch;
|
||||
let sub_dims: Vec<usize> = {
|
||||
let mut d = shape.dims().to_vec();
|
||||
d[0] = chunk_size;
|
||||
d
|
||||
};
|
||||
let mut result = Vec::with_capacity(n);
|
||||
for i in 0..n {
|
||||
let start = i * chunk_size * elem_per_sample;
|
||||
let end = start + chunk_size * elem_per_sample;
|
||||
let arr = ndarray::ArrayD::from_shape_vec(
|
||||
ndarray::IxDyn(&sub_dims),
|
||||
data[start..end].to_vec(),
|
||||
)
|
||||
.map_err(|e| NnError::tensor_op(&format!("Split reshape failed: {e}")))?;
|
||||
result.push(Tensor::FloatND(arr));
|
||||
}
|
||||
Ok(result)
|
||||
}
|
||||
|
||||
/// Compute standard deviation
|
||||
pub fn std(&self) -> NnResult<f32> {
|
||||
match self {
|
||||
|
||||
@@ -21,4 +21,3 @@ pub use bvp::attention_weighted_bvp;
|
||||
pub use fresnel::solve_fresnel_geometry;
|
||||
pub use spectrogram::gate_spectrogram;
|
||||
pub use subcarrier::mincut_subcarrier_partition;
|
||||
pub use subcarrier::subcarrier_importance_weights;
|
||||
|
||||
@@ -142,29 +142,6 @@ pub fn mincut_subcarrier_partition(sensitivity: &[f32]) -> (Vec<usize>, Vec<usiz
|
||||
}
|
||||
}
|
||||
|
||||
/// Convert a mincut partition into per-subcarrier importance weights.
|
||||
///
|
||||
/// Sensitive subcarriers (high body-motion correlation) get weight > 1.0,
|
||||
/// insensitive ones get weight 0.5. This allows downstream feature extraction
|
||||
/// to emphasise the most informative subcarriers.
|
||||
pub fn subcarrier_importance_weights(sensitivity: &[f32]) -> Vec<f32> {
|
||||
if sensitivity.is_empty() {
|
||||
return vec![];
|
||||
}
|
||||
let (sensitive, _insensitive) = mincut_subcarrier_partition(sensitivity);
|
||||
let max_sens = sensitivity
|
||||
.iter()
|
||||
.cloned()
|
||||
.fold(f32::NEG_INFINITY, f32::max)
|
||||
.max(1e-9);
|
||||
|
||||
let mut weights = vec![0.5f32; sensitivity.len()];
|
||||
for &idx in &sensitive {
|
||||
weights[idx] = 1.0 + (sensitivity[idx] / max_sens).min(1.0);
|
||||
}
|
||||
weights
|
||||
}
|
||||
|
||||
#[cfg(test)]
|
||||
mod tests {
|
||||
use super::*;
|
||||
@@ -198,38 +175,4 @@ mod tests {
|
||||
assert_eq!(s, vec![0]);
|
||||
assert!(i.is_empty());
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_importance_weights_empty() {
|
||||
let w = subcarrier_importance_weights(&[]);
|
||||
assert!(w.is_empty());
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_importance_weights_all_equal() {
|
||||
let sensitivity = vec![1.0f32; 8];
|
||||
let w = subcarrier_importance_weights(&sensitivity);
|
||||
assert_eq!(w.len(), 8);
|
||||
// All subcarriers have identical sensitivity so all should be classified
|
||||
// the same way (either all sensitive or all insensitive after mincut).
|
||||
// At minimum, no weight should exceed 2.0 or be negative.
|
||||
for &wt in &w {
|
||||
assert!(wt >= 0.5 && wt <= 2.0, "weight {wt} out of range");
|
||||
}
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_importance_weights_sensitive_higher() {
|
||||
// First 5 subcarriers have high sensitivity, last 5 low.
|
||||
let sensitivity: Vec<f32> = (0..10).map(|i| if i < 5 { 0.9 } else { 0.1 }).collect();
|
||||
let w = subcarrier_importance_weights(&sensitivity);
|
||||
assert_eq!(w.len(), 10);
|
||||
|
||||
let mean_high: f32 = w[..5].iter().sum::<f32>() / 5.0;
|
||||
let mean_low: f32 = w[5..].iter().sum::<f32>() / 5.0;
|
||||
assert!(
|
||||
mean_high > mean_low,
|
||||
"sensitive subcarriers should have higher mean weight ({mean_high}) than insensitive ({mean_low})"
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -43,8 +43,5 @@ clap = { workspace = true }
|
||||
# Multi-BSSID WiFi scanning pipeline (ADR-022 Phase 3)
|
||||
wifi-densepose-wifiscan = { version = "0.3.0", path = "../wifi-densepose-wifiscan" }
|
||||
|
||||
# Signal processing with RuvSense pose tracker (accuracy sprint)
|
||||
wifi-densepose-signal = { version = "0.3.0", path = "../wifi-densepose-signal" }
|
||||
|
||||
[dev-dependencies]
|
||||
tempfile = "3.10"
|
||||
|
||||
+60
-120
@@ -10,10 +10,6 @@
|
||||
//!
|
||||
//! The trained model is serialised as JSON and hot-loaded at runtime so that
|
||||
//! the classification thresholds adapt to the specific room and ESP32 placement.
|
||||
//!
|
||||
//! Classes are discovered dynamically from training data filenames instead of
|
||||
//! being hardcoded, so new activity classes can be added just by recording data
|
||||
//! with the appropriate filename convention.
|
||||
|
||||
use serde::{Deserialize, Serialize};
|
||||
use std::collections::HashMap;
|
||||
@@ -24,8 +20,9 @@ use std::path::{Path, PathBuf};
|
||||
/// Extended feature vector: 7 server features + 8 subcarrier-derived features = 15.
|
||||
const N_FEATURES: usize = 15;
|
||||
|
||||
/// Default class names for backward compatibility with old saved models.
|
||||
const DEFAULT_CLASSES: &[&str] = &["absent", "present_still", "present_moving", "active"];
|
||||
/// Activity classes we recognise.
|
||||
pub const CLASSES: &[&str] = &["absent", "present_still", "present_moving", "active"];
|
||||
const N_CLASSES: usize = 4;
|
||||
|
||||
/// Extract extended feature vector from a JSONL frame (features + raw amplitudes).
|
||||
pub fn features_from_frame(frame: &serde_json::Value) -> [f64; N_FEATURES] {
|
||||
@@ -127,9 +124,8 @@ pub struct ClassStats {
|
||||
pub struct AdaptiveModel {
|
||||
/// Per-class feature statistics (centroid + spread).
|
||||
pub class_stats: Vec<ClassStats>,
|
||||
/// Logistic regression weights: [n_classes x (N_FEATURES + 1)] (last = bias).
|
||||
/// Dynamic: the outer Vec length equals the number of discovered classes.
|
||||
pub weights: Vec<Vec<f64>>,
|
||||
/// Logistic regression weights: [N_CLASSES x (N_FEATURES + 1)] (last = bias).
|
||||
pub weights: Vec<[f64; N_FEATURES + 1]>,
|
||||
/// Global feature normalisation: mean and stddev across all training data.
|
||||
pub global_mean: [f64; N_FEATURES],
|
||||
pub global_std: [f64; N_FEATURES],
|
||||
@@ -137,38 +133,27 @@ pub struct AdaptiveModel {
|
||||
pub trained_frames: usize,
|
||||
pub training_accuracy: f64,
|
||||
pub version: u32,
|
||||
/// Dynamically discovered class names (in index order).
|
||||
#[serde(default = "default_class_names")]
|
||||
pub class_names: Vec<String>,
|
||||
}
|
||||
|
||||
/// Backward-compatible fallback for models saved without class_names.
|
||||
fn default_class_names() -> Vec<String> {
|
||||
DEFAULT_CLASSES.iter().map(|s| s.to_string()).collect()
|
||||
}
|
||||
|
||||
impl Default for AdaptiveModel {
|
||||
fn default() -> Self {
|
||||
let n_classes = DEFAULT_CLASSES.len();
|
||||
Self {
|
||||
class_stats: Vec::new(),
|
||||
weights: vec![vec![0.0; N_FEATURES + 1]; n_classes],
|
||||
weights: vec![[0.0; N_FEATURES + 1]; N_CLASSES],
|
||||
global_mean: [0.0; N_FEATURES],
|
||||
global_std: [1.0; N_FEATURES],
|
||||
trained_frames: 0,
|
||||
training_accuracy: 0.0,
|
||||
version: 1,
|
||||
class_names: default_class_names(),
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
impl AdaptiveModel {
|
||||
/// Classify a raw feature vector. Returns (class_label, confidence).
|
||||
pub fn classify(&self, raw_features: &[f64; N_FEATURES]) -> (String, f64) {
|
||||
let n_classes = self.weights.len();
|
||||
if n_classes == 0 || self.class_stats.is_empty() {
|
||||
return ("present_still".to_string(), 0.5);
|
||||
pub fn classify(&self, raw_features: &[f64; N_FEATURES]) -> (&'static str, f64) {
|
||||
if self.weights.is_empty() || self.class_stats.is_empty() {
|
||||
return ("present_still", 0.5);
|
||||
}
|
||||
|
||||
// Normalise features.
|
||||
@@ -178,8 +163,8 @@ impl AdaptiveModel {
|
||||
}
|
||||
|
||||
// Compute logits: w·x + b for each class.
|
||||
let mut logits: Vec<f64> = vec![0.0; n_classes];
|
||||
for c in 0..n_classes {
|
||||
let mut logits = [0.0f64; N_CLASSES];
|
||||
for c in 0..N_CLASSES.min(self.weights.len()) {
|
||||
let w = &self.weights[c];
|
||||
let mut z = w[N_FEATURES]; // bias
|
||||
for i in 0..N_FEATURES {
|
||||
@@ -191,8 +176,8 @@ impl AdaptiveModel {
|
||||
// Softmax.
|
||||
let max_logit = logits.iter().cloned().fold(f64::NEG_INFINITY, f64::max);
|
||||
let exp_sum: f64 = logits.iter().map(|z| (z - max_logit).exp()).sum();
|
||||
let mut probs: Vec<f64> = vec![0.0; n_classes];
|
||||
for c in 0..n_classes {
|
||||
let mut probs = [0.0f64; N_CLASSES];
|
||||
for c in 0..N_CLASSES {
|
||||
probs[c] = ((logits[c] - max_logit).exp()) / exp_sum;
|
||||
}
|
||||
|
||||
@@ -200,11 +185,7 @@ impl AdaptiveModel {
|
||||
let (best_c, best_p) = probs.iter().enumerate()
|
||||
.max_by(|a, b| a.1.partial_cmp(b.1).unwrap())
|
||||
.unwrap();
|
||||
let label = if best_c < self.class_names.len() {
|
||||
self.class_names[best_c].clone()
|
||||
} else {
|
||||
"present_still".to_string()
|
||||
};
|
||||
let label = if best_c < CLASSES.len() { CLASSES[best_c] } else { "present_still" };
|
||||
(label, *best_p)
|
||||
}
|
||||
|
||||
@@ -247,88 +228,48 @@ fn load_recording(path: &Path, class_idx: usize) -> Vec<Sample> {
|
||||
}).collect()
|
||||
}
|
||||
|
||||
/// Map a recording filename to a class name (String).
|
||||
/// Returns the discovered class name for the file, or None if it cannot be determined.
|
||||
fn classify_recording_name(name: &str) -> Option<String> {
|
||||
/// Map a recording filename to a class index.
|
||||
fn classify_recording_name(name: &str) -> Option<usize> {
|
||||
let lower = name.to_lowercase();
|
||||
// Strip "train_" prefix and ".jsonl" suffix, then extract the class label.
|
||||
// Convention: train_<class>_<description>.jsonl
|
||||
// The class is the first segment after "train_" that matches a known pattern,
|
||||
// or the entire middle portion if no pattern matches.
|
||||
|
||||
// Check common patterns first for backward compat
|
||||
if lower.contains("empty") || lower.contains("absent") { return Some("absent".into()); }
|
||||
if lower.contains("still") || lower.contains("sitting") || lower.contains("standing") { return Some("present_still".into()); }
|
||||
if lower.contains("walking") || lower.contains("moving") { return Some("present_moving".into()); }
|
||||
if lower.contains("active") || lower.contains("exercise") || lower.contains("running") { return Some("active".into()); }
|
||||
|
||||
// Fallback: extract class from filename structure train_<class>_*.jsonl
|
||||
let stem = lower.trim_start_matches("train_").trim_end_matches(".jsonl");
|
||||
let class_name = stem.split('_').next().unwrap_or(stem);
|
||||
if !class_name.is_empty() {
|
||||
Some(class_name.to_string())
|
||||
} else {
|
||||
None
|
||||
}
|
||||
if lower.contains("empty") || lower.contains("absent") { Some(0) }
|
||||
else if lower.contains("still") || lower.contains("sitting") || lower.contains("standing") { Some(1) }
|
||||
else if lower.contains("walking") || lower.contains("moving") { Some(2) }
|
||||
else if lower.contains("active") || lower.contains("exercise") || lower.contains("running") { Some(3) }
|
||||
else { None }
|
||||
}
|
||||
|
||||
/// Train a model from labeled JSONL recordings in a directory.
|
||||
///
|
||||
/// Recordings are matched to classes by filename pattern. Classes are discovered
|
||||
/// dynamically from the training data filenames:
|
||||
/// - `*empty*` / `*absent*` → absent
|
||||
/// - `*still*` / `*sitting*` → present_still
|
||||
/// - `*walking*` / `*moving*` → present_moving
|
||||
/// - `*active*` / `*exercise*`→ active
|
||||
/// - Any other `train_<class>_*.jsonl` → <class>
|
||||
/// Recordings are matched to classes by filename pattern:
|
||||
/// - `*empty*` / `*absent*` → absent (0)
|
||||
/// - `*still*` / `*sitting*` → present_still (1)
|
||||
/// - `*walking*` / `*moving*` → present_moving (2)
|
||||
/// - `*active*` / `*exercise*`→ active (3)
|
||||
pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, String> {
|
||||
// First pass: scan filenames to discover all unique class names.
|
||||
let entries: Vec<_> = std::fs::read_dir(recordings_dir)
|
||||
.map_err(|e| format!("Cannot read {}: {}", recordings_dir.display(), e))?
|
||||
.flatten()
|
||||
.collect();
|
||||
// Scan for train_* files.
|
||||
let mut samples: Vec<Sample> = Vec::new();
|
||||
let entries = std::fs::read_dir(recordings_dir)
|
||||
.map_err(|e| format!("Cannot read {}: {}", recordings_dir.display(), e))?;
|
||||
|
||||
let mut class_map: HashMap<String, usize> = HashMap::new();
|
||||
let mut class_names: Vec<String> = Vec::new();
|
||||
|
||||
// Collect (entry, class_name) pairs for files that match.
|
||||
let mut file_classes: Vec<(PathBuf, String, String)> = Vec::new(); // (path, fname, class_name)
|
||||
for entry in &entries {
|
||||
for entry in entries.flatten() {
|
||||
let fname = entry.file_name().to_string_lossy().to_string();
|
||||
if !fname.starts_with("train_") || !fname.ends_with(".jsonl") {
|
||||
continue;
|
||||
}
|
||||
if let Some(class_name) = classify_recording_name(&fname) {
|
||||
if !class_map.contains_key(&class_name) {
|
||||
let idx = class_names.len();
|
||||
class_map.insert(class_name.clone(), idx);
|
||||
class_names.push(class_name.clone());
|
||||
}
|
||||
file_classes.push((entry.path(), fname, class_name));
|
||||
if let Some(class_idx) = classify_recording_name(&fname) {
|
||||
let loaded = load_recording(&entry.path(), class_idx);
|
||||
eprintln!(" Loaded {}: {} frames → class '{}'",
|
||||
fname, loaded.len(), CLASSES[class_idx]);
|
||||
samples.extend(loaded);
|
||||
}
|
||||
}
|
||||
|
||||
let n_classes = class_names.len();
|
||||
if n_classes == 0 {
|
||||
return Err("No training samples found. Record data with train_* prefix.".into());
|
||||
}
|
||||
|
||||
// Second pass: load recordings with the discovered class indices.
|
||||
let mut samples: Vec<Sample> = Vec::new();
|
||||
for (path, fname, class_name) in &file_classes {
|
||||
let class_idx = class_map[class_name];
|
||||
let loaded = load_recording(path, class_idx);
|
||||
eprintln!(" Loaded {}: {} frames → class '{}'",
|
||||
fname, loaded.len(), class_name);
|
||||
samples.extend(loaded);
|
||||
}
|
||||
|
||||
if samples.is_empty() {
|
||||
return Err("No training samples found. Record data with train_* prefix.".into());
|
||||
}
|
||||
|
||||
let n = samples.len();
|
||||
eprintln!("Total training samples: {n} across {n_classes} classes: {:?}", class_names);
|
||||
eprintln!("Total training samples: {n}");
|
||||
|
||||
// ── Compute global normalisation stats ──
|
||||
let mut global_mean = [0.0f64; N_FEATURES];
|
||||
@@ -348,9 +289,9 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
}
|
||||
|
||||
// ── Compute per-class statistics ──
|
||||
let mut class_sums = vec![[0.0f64; N_FEATURES]; n_classes];
|
||||
let mut class_sq = vec![[0.0f64; N_FEATURES]; n_classes];
|
||||
let mut class_counts = vec![0usize; n_classes];
|
||||
let mut class_sums = vec![[0.0f64; N_FEATURES]; N_CLASSES];
|
||||
let mut class_sq = vec![[0.0f64; N_FEATURES]; N_CLASSES];
|
||||
let mut class_counts = vec![0usize; N_CLASSES];
|
||||
for s in &samples {
|
||||
let c = s.class_idx;
|
||||
class_counts[c] += 1;
|
||||
@@ -361,7 +302,7 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
}
|
||||
|
||||
let mut class_stats = Vec::new();
|
||||
for c in 0..n_classes {
|
||||
for c in 0..N_CLASSES {
|
||||
let cnt = class_counts[c].max(1) as f64;
|
||||
let mut mean = [0.0; N_FEATURES];
|
||||
let mut stddev = [0.0; N_FEATURES];
|
||||
@@ -370,7 +311,7 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
stddev[i] = ((class_sq[c][i] / cnt) - mean[i] * mean[i]).max(0.0).sqrt();
|
||||
}
|
||||
class_stats.push(ClassStats {
|
||||
label: class_names[c].clone(),
|
||||
label: CLASSES[c].to_string(),
|
||||
count: class_counts[c],
|
||||
mean,
|
||||
stddev,
|
||||
@@ -387,7 +328,7 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
}).collect();
|
||||
|
||||
// ── Train logistic regression via mini-batch SGD ──
|
||||
let mut weights: Vec<Vec<f64>> = vec![vec![0.0f64; N_FEATURES + 1]; n_classes];
|
||||
let mut weights = vec![[0.0f64; N_FEATURES + 1]; N_CLASSES];
|
||||
let lr = 0.1;
|
||||
let epochs = 200;
|
||||
let batch_size = 32;
|
||||
@@ -407,19 +348,19 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
}
|
||||
|
||||
let mut epoch_loss = 0.0f64;
|
||||
let mut _batch_count = 0;
|
||||
let mut batch_count = 0;
|
||||
|
||||
for batch_start in (0..norm_samples.len()).step_by(batch_size) {
|
||||
let batch_end = (batch_start + batch_size).min(norm_samples.len());
|
||||
let batch = &norm_samples[batch_start..batch_end];
|
||||
|
||||
// Accumulate gradients.
|
||||
let mut grad: Vec<Vec<f64>> = vec![vec![0.0f64; N_FEATURES + 1]; n_classes];
|
||||
let mut grad = vec![[0.0f64; N_FEATURES + 1]; N_CLASSES];
|
||||
|
||||
for (x, target) in batch {
|
||||
// Forward: softmax.
|
||||
let mut logits: Vec<f64> = vec![0.0; n_classes];
|
||||
for c in 0..n_classes {
|
||||
let mut logits = [0.0f64; N_CLASSES];
|
||||
for c in 0..N_CLASSES {
|
||||
logits[c] = weights[c][N_FEATURES]; // bias
|
||||
for i in 0..N_FEATURES {
|
||||
logits[c] += weights[c][i] * x[i];
|
||||
@@ -427,8 +368,8 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
}
|
||||
let max_l = logits.iter().cloned().fold(f64::NEG_INFINITY, f64::max);
|
||||
let exp_sum: f64 = logits.iter().map(|z| (z - max_l).exp()).sum();
|
||||
let mut probs: Vec<f64> = vec![0.0; n_classes];
|
||||
for c in 0..n_classes {
|
||||
let mut probs = [0.0f64; N_CLASSES];
|
||||
for c in 0..N_CLASSES {
|
||||
probs[c] = ((logits[c] - max_l).exp()) / exp_sum;
|
||||
}
|
||||
|
||||
@@ -436,7 +377,7 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
epoch_loss += -(probs[*target].max(1e-15)).ln();
|
||||
|
||||
// Gradient: prob - one_hot(target).
|
||||
for c in 0..n_classes {
|
||||
for c in 0..N_CLASSES {
|
||||
let delta = probs[c] - if c == *target { 1.0 } else { 0.0 };
|
||||
for i in 0..N_FEATURES {
|
||||
grad[c][i] += delta * x[i];
|
||||
@@ -448,12 +389,12 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
// Update weights.
|
||||
let bs = batch.len() as f64;
|
||||
let current_lr = lr * (1.0 - epoch as f64 / epochs as f64); // linear decay
|
||||
for c in 0..n_classes {
|
||||
for c in 0..N_CLASSES {
|
||||
for i in 0..=N_FEATURES {
|
||||
weights[c][i] -= current_lr * grad[c][i] / bs;
|
||||
}
|
||||
}
|
||||
_batch_count += 1;
|
||||
batch_count += 1;
|
||||
}
|
||||
|
||||
if epoch % 50 == 0 || epoch == epochs - 1 {
|
||||
@@ -465,8 +406,8 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
// ── Evaluate accuracy ──
|
||||
let mut correct = 0;
|
||||
for (x, target) in &norm_samples {
|
||||
let mut logits: Vec<f64> = vec![0.0; n_classes];
|
||||
for c in 0..n_classes {
|
||||
let mut logits = [0.0f64; N_CLASSES];
|
||||
for c in 0..N_CLASSES {
|
||||
logits[c] = weights[c][N_FEATURES];
|
||||
for i in 0..N_FEATURES {
|
||||
logits[c] += weights[c][i] * x[i];
|
||||
@@ -481,12 +422,12 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
eprintln!("Training accuracy: {correct}/{n} = {accuracy:.1}%");
|
||||
|
||||
// ── Per-class accuracy ──
|
||||
let mut class_correct = vec![0usize; n_classes];
|
||||
let mut class_total = vec![0usize; n_classes];
|
||||
let mut class_correct = vec![0usize; N_CLASSES];
|
||||
let mut class_total = vec![0usize; N_CLASSES];
|
||||
for (x, target) in &norm_samples {
|
||||
class_total[*target] += 1;
|
||||
let mut logits: Vec<f64> = vec![0.0; n_classes];
|
||||
for c in 0..n_classes {
|
||||
let mut logits = [0.0f64; N_CLASSES];
|
||||
for c in 0..N_CLASSES {
|
||||
logits[c] = weights[c][N_FEATURES];
|
||||
for i in 0..N_FEATURES {
|
||||
logits[c] += weights[c][i] * x[i];
|
||||
@@ -497,9 +438,9 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
.unwrap().0;
|
||||
if pred == *target { class_correct[*target] += 1; }
|
||||
}
|
||||
for c in 0..n_classes {
|
||||
for c in 0..N_CLASSES {
|
||||
let tot = class_total[c].max(1);
|
||||
eprintln!(" {}: {}/{} ({:.0}%)", class_names[c], class_correct[c], tot,
|
||||
eprintln!(" {}: {}/{} ({:.0}%)", CLASSES[c], class_correct[c], tot,
|
||||
class_correct[c] as f64 / tot as f64 * 100.0);
|
||||
}
|
||||
|
||||
@@ -511,7 +452,6 @@ pub fn train_from_recordings(recordings_dir: &Path) -> Result<AdaptiveModel, Str
|
||||
trained_frames: n,
|
||||
training_accuracy: accuracy,
|
||||
version: 1,
|
||||
class_names,
|
||||
})
|
||||
}
|
||||
|
||||
|
||||
@@ -1,105 +0,0 @@
|
||||
//! CLI argument definitions and early-exit mode handlers.
|
||||
|
||||
use std::path::PathBuf;
|
||||
use clap::Parser;
|
||||
|
||||
/// CLI arguments for the sensing server.
|
||||
#[derive(Parser, Debug)]
|
||||
#[command(name = "sensing-server", about = "WiFi-DensePose sensing server")]
|
||||
pub struct Args {
|
||||
/// HTTP port for UI and REST API
|
||||
#[arg(long, default_value = "8080")]
|
||||
pub http_port: u16,
|
||||
|
||||
/// WebSocket port for sensing stream
|
||||
#[arg(long, default_value = "8765")]
|
||||
pub ws_port: u16,
|
||||
|
||||
/// UDP port for ESP32 CSI frames
|
||||
#[arg(long, default_value = "5005")]
|
||||
pub udp_port: u16,
|
||||
|
||||
/// Path to UI static files
|
||||
#[arg(long, default_value = "../../ui")]
|
||||
pub ui_path: PathBuf,
|
||||
|
||||
/// Tick interval in milliseconds (default 100 ms = 10 fps for smooth pose animation)
|
||||
#[arg(long, default_value = "100")]
|
||||
pub tick_ms: u64,
|
||||
|
||||
/// Bind address (default 127.0.0.1; set to 0.0.0.0 for network access)
|
||||
#[arg(long, default_value = "127.0.0.1", env = "SENSING_BIND_ADDR")]
|
||||
pub bind_addr: String,
|
||||
|
||||
/// Data source: auto, wifi, esp32, simulate
|
||||
#[arg(long, default_value = "auto")]
|
||||
pub source: String,
|
||||
|
||||
/// Run vital sign detection benchmark (1000 frames) and exit
|
||||
#[arg(long)]
|
||||
pub benchmark: bool,
|
||||
|
||||
/// Load model config from an RVF container at startup
|
||||
#[arg(long, value_name = "PATH")]
|
||||
pub load_rvf: Option<PathBuf>,
|
||||
|
||||
/// Save current model state as an RVF container on shutdown
|
||||
#[arg(long, value_name = "PATH")]
|
||||
pub save_rvf: Option<PathBuf>,
|
||||
|
||||
/// Load a trained .rvf model for inference
|
||||
#[arg(long, value_name = "PATH")]
|
||||
pub model: Option<PathBuf>,
|
||||
|
||||
/// Enable progressive loading (Layer A instant start)
|
||||
#[arg(long)]
|
||||
pub progressive: bool,
|
||||
|
||||
/// Export an RVF container package and exit (no server)
|
||||
#[arg(long, value_name = "PATH")]
|
||||
pub export_rvf: Option<PathBuf>,
|
||||
|
||||
/// Run training mode (train a model and exit)
|
||||
#[arg(long)]
|
||||
pub train: bool,
|
||||
|
||||
/// Path to dataset directory (MM-Fi or Wi-Pose)
|
||||
#[arg(long, value_name = "PATH")]
|
||||
pub dataset: Option<PathBuf>,
|
||||
|
||||
/// Dataset type: "mmfi" or "wipose"
|
||||
#[arg(long, value_name = "TYPE", default_value = "mmfi")]
|
||||
pub dataset_type: String,
|
||||
|
||||
/// Number of training epochs
|
||||
#[arg(long, default_value = "100")]
|
||||
pub epochs: usize,
|
||||
|
||||
/// Directory for training checkpoints
|
||||
#[arg(long, value_name = "DIR")]
|
||||
pub checkpoint_dir: Option<PathBuf>,
|
||||
|
||||
/// Run self-supervised contrastive pretraining (ADR-024)
|
||||
#[arg(long)]
|
||||
pub pretrain: bool,
|
||||
|
||||
/// Number of pretraining epochs (default 50)
|
||||
#[arg(long, default_value = "50")]
|
||||
pub pretrain_epochs: usize,
|
||||
|
||||
/// Extract embeddings mode: load model and extract CSI embeddings
|
||||
#[arg(long)]
|
||||
pub embed: bool,
|
||||
|
||||
/// Build fingerprint index from embeddings (env|activity|temporal|person)
|
||||
#[arg(long, value_name = "TYPE")]
|
||||
pub build_index: Option<String>,
|
||||
|
||||
/// Node positions for multistatic fusion (format: "x,y,z;x,y,z;...")
|
||||
#[arg(long, env = "SENSING_NODE_POSITIONS")]
|
||||
pub node_positions: Option<String>,
|
||||
|
||||
/// Start field model calibration on boot (empty room required)
|
||||
#[arg(long)]
|
||||
pub calibrate: bool,
|
||||
}
|
||||
@@ -1,675 +0,0 @@
|
||||
//! CSI frame parsing, signal field generation, feature extraction,
|
||||
//! classification, vital signs smoothing, and multi-person estimation.
|
||||
|
||||
use std::collections::{HashMap, VecDeque};
|
||||
use ruvector_mincut::{DynamicMinCut, MinCutBuilder};
|
||||
|
||||
use crate::adaptive_classifier;
|
||||
use crate::types::*;
|
||||
use crate::vital_signs::VitalSigns;
|
||||
|
||||
// ── ESP32 UDP frame parsers ─────────────────────────────────────────────────
|
||||
|
||||
/// Parse a 32-byte edge vitals packet (magic 0xC511_0002).
|
||||
pub fn parse_esp32_vitals(buf: &[u8]) -> Option<Esp32VitalsPacket> {
|
||||
if buf.len() < 32 { return None; }
|
||||
let magic = u32::from_le_bytes([buf[0], buf[1], buf[2], buf[3]]);
|
||||
if magic != 0xC511_0002 { return None; }
|
||||
|
||||
let node_id = buf[4];
|
||||
let flags = buf[5];
|
||||
let breathing_raw = u16::from_le_bytes([buf[6], buf[7]]);
|
||||
let heartrate_raw = u32::from_le_bytes([buf[8], buf[9], buf[10], buf[11]]);
|
||||
let rssi = buf[12] as i8;
|
||||
let n_persons = buf[13];
|
||||
let motion_energy = f32::from_le_bytes([buf[16], buf[17], buf[18], buf[19]]);
|
||||
let presence_score = f32::from_le_bytes([buf[20], buf[21], buf[22], buf[23]]);
|
||||
let timestamp_ms = u32::from_le_bytes([buf[24], buf[25], buf[26], buf[27]]);
|
||||
|
||||
Some(Esp32VitalsPacket {
|
||||
node_id,
|
||||
presence: (flags & 0x01) != 0,
|
||||
fall_detected: (flags & 0x02) != 0,
|
||||
motion: (flags & 0x04) != 0,
|
||||
breathing_rate_bpm: breathing_raw as f64 / 100.0,
|
||||
heartrate_bpm: heartrate_raw as f64 / 10000.0,
|
||||
rssi, n_persons, motion_energy, presence_score, timestamp_ms,
|
||||
})
|
||||
}
|
||||
|
||||
/// Parse a WASM output packet (magic 0xC511_0004).
|
||||
pub fn parse_wasm_output(buf: &[u8]) -> Option<WasmOutputPacket> {
|
||||
if buf.len() < 8 { return None; }
|
||||
let magic = u32::from_le_bytes([buf[0], buf[1], buf[2], buf[3]]);
|
||||
if magic != 0xC511_0004 { return None; }
|
||||
|
||||
let node_id = buf[4];
|
||||
let module_id = buf[5];
|
||||
let event_count = u16::from_le_bytes([buf[6], buf[7]]) as usize;
|
||||
|
||||
let mut events = Vec::with_capacity(event_count);
|
||||
let mut offset = 8;
|
||||
for _ in 0..event_count {
|
||||
if offset + 5 > buf.len() { break; }
|
||||
let event_type = buf[offset];
|
||||
let value = f32::from_le_bytes([
|
||||
buf[offset + 1], buf[offset + 2], buf[offset + 3], buf[offset + 4],
|
||||
]);
|
||||
events.push(WasmEvent { event_type, value });
|
||||
offset += 5;
|
||||
}
|
||||
|
||||
Some(WasmOutputPacket { node_id, module_id, events })
|
||||
}
|
||||
|
||||
pub fn parse_esp32_frame(buf: &[u8]) -> Option<Esp32Frame> {
|
||||
if buf.len() < 20 { return None; }
|
||||
let magic = u32::from_le_bytes([buf[0], buf[1], buf[2], buf[3]]);
|
||||
if magic != 0xC511_0001 { return None; }
|
||||
|
||||
let node_id = buf[4];
|
||||
let n_antennas = buf[5];
|
||||
let n_subcarriers = buf[6];
|
||||
let freq_mhz = u16::from_le_bytes([buf[8], buf[9]]);
|
||||
let sequence = u32::from_le_bytes([buf[10], buf[11], buf[12], buf[13]]);
|
||||
let rssi_raw = buf[14] as i8;
|
||||
let rssi = if rssi_raw > 0 { rssi_raw.saturating_neg() } else { rssi_raw };
|
||||
let noise_floor = buf[15] as i8;
|
||||
|
||||
let iq_start = 20;
|
||||
let n_pairs = n_antennas as usize * n_subcarriers as usize;
|
||||
let expected_len = iq_start + n_pairs * 2;
|
||||
if buf.len() < expected_len { return None; }
|
||||
|
||||
let mut amplitudes = Vec::with_capacity(n_pairs);
|
||||
let mut phases = Vec::with_capacity(n_pairs);
|
||||
for k in 0..n_pairs {
|
||||
let i_val = buf[iq_start + k * 2] as i8 as f64;
|
||||
let q_val = buf[iq_start + k * 2 + 1] as i8 as f64;
|
||||
amplitudes.push((i_val * i_val + q_val * q_val).sqrt());
|
||||
phases.push(q_val.atan2(i_val));
|
||||
}
|
||||
|
||||
Some(Esp32Frame {
|
||||
magic, node_id, n_antennas, n_subcarriers, freq_mhz, sequence,
|
||||
rssi, noise_floor, amplitudes, phases,
|
||||
})
|
||||
}
|
||||
|
||||
// ── Signal field generation ─────────────────────────────────────────────────
|
||||
|
||||
pub fn generate_signal_field(
|
||||
_mean_rssi: f64, motion_score: f64, breathing_rate_hz: f64,
|
||||
signal_quality: f64, subcarrier_variances: &[f64],
|
||||
) -> SignalField {
|
||||
let grid = 20usize;
|
||||
let mut values = vec![0.0f64; grid * grid];
|
||||
let center = (grid as f64 - 1.0) / 2.0;
|
||||
|
||||
let max_var = subcarrier_variances.iter().cloned().fold(0.0f64, f64::max);
|
||||
let norm_factor = if max_var > 1e-9 { max_var } else { 1.0 };
|
||||
let n_sub = subcarrier_variances.len().max(1);
|
||||
|
||||
for (k, &var) in subcarrier_variances.iter().enumerate() {
|
||||
let weight = (var / norm_factor) * motion_score;
|
||||
if weight < 1e-6 { continue; }
|
||||
let angle = (k as f64 / n_sub as f64) * 2.0 * std::f64::consts::PI;
|
||||
let radius = center * 0.8 * weight.sqrt();
|
||||
let hx = center + radius * angle.cos();
|
||||
let hz = center + radius * angle.sin();
|
||||
for z in 0..grid {
|
||||
for x in 0..grid {
|
||||
let dx = x as f64 - hx;
|
||||
let dz = z as f64 - hz;
|
||||
let dist2 = dx * dx + dz * dz;
|
||||
let spread = (0.5 + weight * 2.0).max(0.5);
|
||||
values[z * grid + x] += weight * (-dist2 / (2.0 * spread * spread)).exp();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
for z in 0..grid {
|
||||
for x in 0..grid {
|
||||
let dx = x as f64 - center;
|
||||
let dz = z as f64 - center;
|
||||
let dist = (dx * dx + dz * dz).sqrt();
|
||||
let base = signal_quality * (-dist * 0.12).exp();
|
||||
values[z * grid + x] += base * 0.3;
|
||||
}
|
||||
}
|
||||
|
||||
if breathing_rate_hz > 0.05 {
|
||||
let ring_r = center * 0.55;
|
||||
let ring_width = 1.8f64;
|
||||
for z in 0..grid {
|
||||
for x in 0..grid {
|
||||
let dx = x as f64 - center;
|
||||
let dz = z as f64 - center;
|
||||
let dist = (dx * dx + dz * dz).sqrt();
|
||||
let ring_val = 0.08 * (-(dist - ring_r).powi(2) / (2.0 * ring_width * ring_width)).exp();
|
||||
values[z * grid + x] += ring_val;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
let field_max = values.iter().cloned().fold(0.0f64, f64::max);
|
||||
let scale = if field_max > 1e-9 { 1.0 / field_max } else { 1.0 };
|
||||
for v in &mut values { *v = (*v * scale).clamp(0.0, 1.0); }
|
||||
|
||||
SignalField { grid_size: [grid, 1, grid], values }
|
||||
}
|
||||
|
||||
// ── Feature extraction ──────────────────────────────────────────────────────
|
||||
|
||||
pub fn estimate_breathing_rate_hz(frame_history: &VecDeque<Vec<f64>>, sample_rate_hz: f64) -> f64 {
|
||||
let n = frame_history.len();
|
||||
if n < 6 { return 0.0; }
|
||||
|
||||
let series: Vec<f64> = frame_history.iter()
|
||||
.map(|amps| if amps.is_empty() { 0.0 } else { amps.iter().sum::<f64>() / amps.len() as f64 })
|
||||
.collect();
|
||||
let mean_s = series.iter().sum::<f64>() / n as f64;
|
||||
let detrended: Vec<f64> = series.iter().map(|x| x - mean_s).collect();
|
||||
|
||||
let n_candidates = 9usize;
|
||||
let f_low = 0.1f64;
|
||||
let f_high = 0.5f64;
|
||||
let mut best_freq = 0.0f64;
|
||||
let mut best_power = 0.0f64;
|
||||
|
||||
for i in 0..n_candidates {
|
||||
let freq = f_low + (f_high - f_low) * i as f64 / (n_candidates - 1).max(1) as f64;
|
||||
let omega = 2.0 * std::f64::consts::PI * freq / sample_rate_hz;
|
||||
let coeff = 2.0 * omega.cos();
|
||||
let (mut s_prev2, mut s_prev1) = (0.0f64, 0.0f64);
|
||||
for &x in &detrended {
|
||||
let s = x + coeff * s_prev1 - s_prev2;
|
||||
s_prev2 = s_prev1;
|
||||
s_prev1 = s;
|
||||
}
|
||||
let power = s_prev2 * s_prev2 + s_prev1 * s_prev1 - coeff * s_prev1 * s_prev2;
|
||||
if power > best_power { best_power = power; best_freq = freq; }
|
||||
}
|
||||
|
||||
let avg_power = {
|
||||
let mut total = 0.0f64;
|
||||
for i in 0..n_candidates {
|
||||
let freq = f_low + (f_high - f_low) * i as f64 / (n_candidates - 1).max(1) as f64;
|
||||
let omega = 2.0 * std::f64::consts::PI * freq / sample_rate_hz;
|
||||
let coeff = 2.0 * omega.cos();
|
||||
let (mut s_prev2, mut s_prev1) = (0.0f64, 0.0f64);
|
||||
for &x in &detrended {
|
||||
let s = x + coeff * s_prev1 - s_prev2;
|
||||
s_prev2 = s_prev1;
|
||||
s_prev1 = s;
|
||||
}
|
||||
total += s_prev2 * s_prev2 + s_prev1 * s_prev1 - coeff * s_prev1 * s_prev2;
|
||||
}
|
||||
total / n_candidates as f64
|
||||
};
|
||||
|
||||
if best_power > avg_power * 3.0 { best_freq.clamp(f_low, f_high) } else { 0.0 }
|
||||
}
|
||||
|
||||
pub fn compute_subcarrier_importance_weights(sensitivity: &[f64]) -> Vec<f64> {
|
||||
let n = sensitivity.len();
|
||||
if n == 0 { return vec![]; }
|
||||
let max_sens = sensitivity.iter().cloned().fold(f64::NEG_INFINITY, f64::max).max(1e-9);
|
||||
let mut sorted = sensitivity.to_vec();
|
||||
sorted.sort_by(|a, b| a.partial_cmp(b).unwrap_or(std::cmp::Ordering::Equal));
|
||||
let median = if n % 2 == 0 { (sorted[n / 2 - 1] + sorted[n / 2]) / 2.0 } else { sorted[n / 2] };
|
||||
sensitivity.iter()
|
||||
.map(|&s| if s >= median { 1.0 + (s / max_sens).min(1.0) } else { 0.5 })
|
||||
.collect()
|
||||
}
|
||||
|
||||
pub fn compute_subcarrier_variances(frame_history: &VecDeque<Vec<f64>>, n_sub: usize) -> Vec<f64> {
|
||||
if frame_history.is_empty() || n_sub == 0 { return vec![0.0; n_sub]; }
|
||||
let n_frames = frame_history.len() as f64;
|
||||
let mut means = vec![0.0f64; n_sub];
|
||||
let mut sq_means = vec![0.0f64; n_sub];
|
||||
for frame in frame_history.iter() {
|
||||
for k in 0..n_sub {
|
||||
let a = if k < frame.len() { frame[k] } else { 0.0 };
|
||||
means[k] += a;
|
||||
sq_means[k] += a * a;
|
||||
}
|
||||
}
|
||||
(0..n_sub).map(|k| {
|
||||
let mean = means[k] / n_frames;
|
||||
let sq_mean = sq_means[k] / n_frames;
|
||||
(sq_mean - mean * mean).max(0.0)
|
||||
}).collect()
|
||||
}
|
||||
|
||||
pub fn extract_features_from_frame(
|
||||
frame: &Esp32Frame, frame_history: &VecDeque<Vec<f64>>, sample_rate_hz: f64,
|
||||
) -> (FeatureInfo, ClassificationInfo, f64, Vec<f64>, f64) {
|
||||
let n_sub = frame.amplitudes.len().max(1);
|
||||
let n = n_sub as f64;
|
||||
let mean_rssi = frame.rssi as f64;
|
||||
|
||||
let sub_sensitivity: Vec<f64> = frame.amplitudes.iter().map(|a| a.abs()).collect();
|
||||
let importance_weights = compute_subcarrier_importance_weights(&sub_sensitivity);
|
||||
let weight_sum: f64 = importance_weights.iter().sum::<f64>();
|
||||
|
||||
let mean_amp: f64 = if weight_sum > 0.0 {
|
||||
frame.amplitudes.iter().zip(importance_weights.iter())
|
||||
.map(|(a, w)| a * w).sum::<f64>() / weight_sum
|
||||
} else {
|
||||
frame.amplitudes.iter().sum::<f64>() / n
|
||||
};
|
||||
|
||||
let intra_variance: f64 = if weight_sum > 0.0 {
|
||||
frame.amplitudes.iter().zip(importance_weights.iter())
|
||||
.map(|(a, w)| w * (a - mean_amp).powi(2)).sum::<f64>() / weight_sum
|
||||
} else {
|
||||
frame.amplitudes.iter().map(|a| (a - mean_amp).powi(2)).sum::<f64>() / n
|
||||
};
|
||||
|
||||
let sub_variances = compute_subcarrier_variances(frame_history, n_sub);
|
||||
let temporal_variance: f64 = if sub_variances.is_empty() {
|
||||
intra_variance
|
||||
} else {
|
||||
sub_variances.iter().sum::<f64>() / sub_variances.len() as f64
|
||||
};
|
||||
let variance = intra_variance.max(temporal_variance);
|
||||
|
||||
let spectral_power: f64 = frame.amplitudes.iter().map(|a| a * a).sum::<f64>() / n;
|
||||
let half = frame.amplitudes.len() / 2;
|
||||
let motion_band_power = if half > 0 {
|
||||
frame.amplitudes[half..].iter().map(|a| (a - mean_amp).powi(2)).sum::<f64>()
|
||||
/ (frame.amplitudes.len() - half) as f64
|
||||
} else { 0.0 };
|
||||
let breathing_band_power = if half > 0 {
|
||||
frame.amplitudes[..half].iter().map(|a| (a - mean_amp).powi(2)).sum::<f64>() / half as f64
|
||||
} else { 0.0 };
|
||||
|
||||
let peak_idx = frame.amplitudes.iter().enumerate()
|
||||
.max_by(|a, b| a.1.partial_cmp(b.1).unwrap_or(std::cmp::Ordering::Equal))
|
||||
.map(|(i, _)| i).unwrap_or(0);
|
||||
let dominant_freq_hz = peak_idx as f64 * 0.05;
|
||||
|
||||
let threshold = mean_amp * 1.2;
|
||||
let change_points = frame.amplitudes.windows(2)
|
||||
.filter(|w| (w[0] < threshold) != (w[1] < threshold)).count();
|
||||
|
||||
let temporal_motion_score = if let Some(prev_frame) = frame_history.back() {
|
||||
let n_cmp = n_sub.min(prev_frame.len());
|
||||
if n_cmp > 0 {
|
||||
let diff_energy: f64 = (0..n_cmp)
|
||||
.map(|k| (frame.amplitudes[k] - prev_frame[k]).powi(2)).sum::<f64>() / n_cmp as f64;
|
||||
let ref_energy = mean_amp * mean_amp + 1e-9;
|
||||
(diff_energy / ref_energy).sqrt().clamp(0.0, 1.0)
|
||||
} else { 0.0 }
|
||||
} else {
|
||||
(intra_variance / (mean_amp * mean_amp + 1e-9)).sqrt().clamp(0.0, 1.0)
|
||||
};
|
||||
|
||||
let variance_motion = (temporal_variance / 10.0).clamp(0.0, 1.0);
|
||||
let mbp_motion = (motion_band_power / 25.0).clamp(0.0, 1.0);
|
||||
let cp_motion = (change_points as f64 / 15.0).clamp(0.0, 1.0);
|
||||
let motion_score = (temporal_motion_score * 0.4 + variance_motion * 0.2
|
||||
+ mbp_motion * 0.25 + cp_motion * 0.15).clamp(0.0, 1.0);
|
||||
|
||||
let snr_db = (frame.rssi as f64 - frame.noise_floor as f64).max(0.0);
|
||||
let snr_quality = (snr_db / 40.0).clamp(0.0, 1.0);
|
||||
let stability = (1.0 - (temporal_variance / (mean_amp * mean_amp + 1e-9)).clamp(0.0, 1.0)).max(0.0);
|
||||
let signal_quality = (snr_quality * 0.6 + stability * 0.4).clamp(0.0, 1.0);
|
||||
|
||||
let breathing_rate_hz = estimate_breathing_rate_hz(frame_history, sample_rate_hz);
|
||||
|
||||
let features = FeatureInfo {
|
||||
mean_rssi, variance, motion_band_power, breathing_band_power,
|
||||
dominant_freq_hz, change_points, spectral_power,
|
||||
};
|
||||
|
||||
let raw_classification = ClassificationInfo {
|
||||
motion_level: raw_classify(motion_score),
|
||||
presence: motion_score > 0.04,
|
||||
confidence: (0.4 + signal_quality * 0.3 + motion_score * 0.3).clamp(0.0, 1.0),
|
||||
};
|
||||
|
||||
(features, raw_classification, breathing_rate_hz, sub_variances, motion_score)
|
||||
}
|
||||
|
||||
// ── Classification ──────────────────────────────────────────────────────────
|
||||
|
||||
pub fn raw_classify(score: f64) -> String {
|
||||
if score > 0.25 { "active".into() }
|
||||
else if score > 0.12 { "present_moving".into() }
|
||||
else if score > 0.04 { "present_still".into() }
|
||||
else { "absent".into() }
|
||||
}
|
||||
|
||||
pub fn smooth_and_classify(state: &mut AppStateInner, raw: &mut ClassificationInfo, raw_motion: f64) {
|
||||
state.baseline_frames += 1;
|
||||
if state.baseline_frames < BASELINE_WARMUP {
|
||||
state.baseline_motion = state.baseline_motion * 0.9 + raw_motion * 0.1;
|
||||
} else if raw_motion < state.smoothed_motion + 0.05 {
|
||||
state.baseline_motion = state.baseline_motion * (1.0 - BASELINE_EMA_ALPHA)
|
||||
+ raw_motion * BASELINE_EMA_ALPHA;
|
||||
}
|
||||
let adjusted = (raw_motion - state.baseline_motion * 0.7).max(0.0);
|
||||
state.smoothed_motion = state.smoothed_motion * (1.0 - MOTION_EMA_ALPHA) + adjusted * MOTION_EMA_ALPHA;
|
||||
let sm = state.smoothed_motion;
|
||||
let candidate = raw_classify(sm);
|
||||
if candidate == state.current_motion_level {
|
||||
state.debounce_counter = 0;
|
||||
state.debounce_candidate = candidate;
|
||||
} else if candidate == state.debounce_candidate {
|
||||
state.debounce_counter += 1;
|
||||
if state.debounce_counter >= DEBOUNCE_FRAMES {
|
||||
state.current_motion_level = candidate;
|
||||
state.debounce_counter = 0;
|
||||
}
|
||||
} else {
|
||||
state.debounce_candidate = candidate;
|
||||
state.debounce_counter = 1;
|
||||
}
|
||||
raw.motion_level = state.current_motion_level.clone();
|
||||
raw.presence = sm > 0.03;
|
||||
raw.confidence = (0.4 + sm * 0.6).clamp(0.0, 1.0);
|
||||
}
|
||||
|
||||
pub fn smooth_and_classify_node(ns: &mut NodeState, raw: &mut ClassificationInfo, raw_motion: f64) {
|
||||
ns.baseline_frames += 1;
|
||||
if ns.baseline_frames < BASELINE_WARMUP {
|
||||
ns.baseline_motion = ns.baseline_motion * 0.9 + raw_motion * 0.1;
|
||||
} else if raw_motion < ns.smoothed_motion + 0.05 {
|
||||
ns.baseline_motion = ns.baseline_motion * (1.0 - BASELINE_EMA_ALPHA) + raw_motion * BASELINE_EMA_ALPHA;
|
||||
}
|
||||
let adjusted = (raw_motion - ns.baseline_motion * 0.7).max(0.0);
|
||||
ns.smoothed_motion = ns.smoothed_motion * (1.0 - MOTION_EMA_ALPHA) + adjusted * MOTION_EMA_ALPHA;
|
||||
let sm = ns.smoothed_motion;
|
||||
let candidate = raw_classify(sm);
|
||||
if candidate == ns.current_motion_level {
|
||||
ns.debounce_counter = 0;
|
||||
ns.debounce_candidate = candidate;
|
||||
} else if candidate == ns.debounce_candidate {
|
||||
ns.debounce_counter += 1;
|
||||
if ns.debounce_counter >= DEBOUNCE_FRAMES {
|
||||
ns.current_motion_level = candidate;
|
||||
ns.debounce_counter = 0;
|
||||
}
|
||||
} else {
|
||||
ns.debounce_candidate = candidate;
|
||||
ns.debounce_counter = 1;
|
||||
}
|
||||
raw.motion_level = ns.current_motion_level.clone();
|
||||
raw.presence = sm > 0.03;
|
||||
raw.confidence = (0.4 + sm * 0.6).clamp(0.0, 1.0);
|
||||
}
|
||||
|
||||
pub fn adaptive_override(state: &AppStateInner, features: &FeatureInfo, classification: &mut ClassificationInfo) {
|
||||
if let Some(ref model) = state.adaptive_model {
|
||||
let amps = state.frame_history.back().map(|v| v.as_slice()).unwrap_or(&[]);
|
||||
let feat_arr = adaptive_classifier::features_from_runtime(
|
||||
&serde_json::json!({
|
||||
"variance": features.variance,
|
||||
"motion_band_power": features.motion_band_power,
|
||||
"breathing_band_power": features.breathing_band_power,
|
||||
"spectral_power": features.spectral_power,
|
||||
"dominant_freq_hz": features.dominant_freq_hz,
|
||||
"change_points": features.change_points,
|
||||
"mean_rssi": features.mean_rssi,
|
||||
}),
|
||||
amps,
|
||||
);
|
||||
let (label, conf) = model.classify(&feat_arr);
|
||||
classification.motion_level = label.to_string();
|
||||
classification.presence = label != "absent";
|
||||
classification.confidence = (conf * 0.7 + classification.confidence * 0.3).clamp(0.0, 1.0);
|
||||
}
|
||||
}
|
||||
|
||||
// ── Vital signs smoothing ───────────────────────────────────────────────────
|
||||
|
||||
fn trimmed_mean(buf: &VecDeque<f64>) -> f64 {
|
||||
if buf.is_empty() { return 0.0; }
|
||||
let mut sorted: Vec<f64> = buf.iter().copied().collect();
|
||||
sorted.sort_by(|a, b| a.partial_cmp(b).unwrap_or(std::cmp::Ordering::Equal));
|
||||
let n = sorted.len();
|
||||
let trim = n / 4;
|
||||
let middle = &sorted[trim..n - trim.max(0)];
|
||||
if middle.is_empty() { sorted[n / 2] } else { middle.iter().sum::<f64>() / middle.len() as f64 }
|
||||
}
|
||||
|
||||
pub fn smooth_vitals(state: &mut AppStateInner, raw: &VitalSigns) -> VitalSigns {
|
||||
let raw_hr = raw.heart_rate_bpm.unwrap_or(0.0);
|
||||
let raw_br = raw.breathing_rate_bpm.unwrap_or(0.0);
|
||||
let hr_ok = state.smoothed_hr < 1.0 || (raw_hr - state.smoothed_hr).abs() < HR_MAX_JUMP;
|
||||
let br_ok = state.smoothed_br < 1.0 || (raw_br - state.smoothed_br).abs() < BR_MAX_JUMP;
|
||||
if hr_ok && raw_hr > 0.0 {
|
||||
state.hr_buffer.push_back(raw_hr);
|
||||
if state.hr_buffer.len() > VITAL_MEDIAN_WINDOW { state.hr_buffer.pop_front(); }
|
||||
}
|
||||
if br_ok && raw_br > 0.0 {
|
||||
state.br_buffer.push_back(raw_br);
|
||||
if state.br_buffer.len() > VITAL_MEDIAN_WINDOW { state.br_buffer.pop_front(); }
|
||||
}
|
||||
let trimmed_hr = trimmed_mean(&state.hr_buffer);
|
||||
let trimmed_br = trimmed_mean(&state.br_buffer);
|
||||
if trimmed_hr > 0.0 {
|
||||
if state.smoothed_hr < 1.0 { state.smoothed_hr = trimmed_hr; }
|
||||
else if (trimmed_hr - state.smoothed_hr).abs() > HR_DEAD_BAND {
|
||||
state.smoothed_hr = state.smoothed_hr * (1.0 - VITAL_EMA_ALPHA) + trimmed_hr * VITAL_EMA_ALPHA;
|
||||
}
|
||||
}
|
||||
if trimmed_br > 0.0 {
|
||||
if state.smoothed_br < 1.0 { state.smoothed_br = trimmed_br; }
|
||||
else if (trimmed_br - state.smoothed_br).abs() > BR_DEAD_BAND {
|
||||
state.smoothed_br = state.smoothed_br * (1.0 - VITAL_EMA_ALPHA) + trimmed_br * VITAL_EMA_ALPHA;
|
||||
}
|
||||
}
|
||||
state.smoothed_hr_conf = state.smoothed_hr_conf * 0.92 + raw.heartbeat_confidence * 0.08;
|
||||
state.smoothed_br_conf = state.smoothed_br_conf * 0.92 + raw.breathing_confidence * 0.08;
|
||||
VitalSigns {
|
||||
breathing_rate_bpm: if state.smoothed_br > 1.0 { Some(state.smoothed_br) } else { None },
|
||||
heart_rate_bpm: if state.smoothed_hr > 1.0 { Some(state.smoothed_hr) } else { None },
|
||||
breathing_confidence: state.smoothed_br_conf,
|
||||
heartbeat_confidence: state.smoothed_hr_conf,
|
||||
signal_quality: raw.signal_quality,
|
||||
}
|
||||
}
|
||||
|
||||
pub fn smooth_vitals_node(ns: &mut NodeState, raw: &VitalSigns) -> VitalSigns {
|
||||
let raw_hr = raw.heart_rate_bpm.unwrap_or(0.0);
|
||||
let raw_br = raw.breathing_rate_bpm.unwrap_or(0.0);
|
||||
let hr_ok = ns.smoothed_hr < 1.0 || (raw_hr - ns.smoothed_hr).abs() < HR_MAX_JUMP;
|
||||
let br_ok = ns.smoothed_br < 1.0 || (raw_br - ns.smoothed_br).abs() < BR_MAX_JUMP;
|
||||
if hr_ok && raw_hr > 0.0 {
|
||||
ns.hr_buffer.push_back(raw_hr);
|
||||
if ns.hr_buffer.len() > VITAL_MEDIAN_WINDOW { ns.hr_buffer.pop_front(); }
|
||||
}
|
||||
if br_ok && raw_br > 0.0 {
|
||||
ns.br_buffer.push_back(raw_br);
|
||||
if ns.br_buffer.len() > VITAL_MEDIAN_WINDOW { ns.br_buffer.pop_front(); }
|
||||
}
|
||||
let trimmed_hr = trimmed_mean(&ns.hr_buffer);
|
||||
let trimmed_br = trimmed_mean(&ns.br_buffer);
|
||||
if trimmed_hr > 0.0 {
|
||||
if ns.smoothed_hr < 1.0 { ns.smoothed_hr = trimmed_hr; }
|
||||
else if (trimmed_hr - ns.smoothed_hr).abs() > HR_DEAD_BAND {
|
||||
ns.smoothed_hr = ns.smoothed_hr * (1.0 - VITAL_EMA_ALPHA) + trimmed_hr * VITAL_EMA_ALPHA;
|
||||
}
|
||||
}
|
||||
if trimmed_br > 0.0 {
|
||||
if ns.smoothed_br < 1.0 { ns.smoothed_br = trimmed_br; }
|
||||
else if (trimmed_br - ns.smoothed_br).abs() > BR_DEAD_BAND {
|
||||
ns.smoothed_br = ns.smoothed_br * (1.0 - VITAL_EMA_ALPHA) + trimmed_br * VITAL_EMA_ALPHA;
|
||||
}
|
||||
}
|
||||
ns.smoothed_hr_conf = ns.smoothed_hr_conf * 0.92 + raw.heartbeat_confidence * 0.08;
|
||||
ns.smoothed_br_conf = ns.smoothed_br_conf * 0.92 + raw.breathing_confidence * 0.08;
|
||||
VitalSigns {
|
||||
breathing_rate_bpm: if ns.smoothed_br > 1.0 { Some(ns.smoothed_br) } else { None },
|
||||
heart_rate_bpm: if ns.smoothed_hr > 1.0 { Some(ns.smoothed_hr) } else { None },
|
||||
breathing_confidence: ns.smoothed_br_conf,
|
||||
heartbeat_confidence: ns.smoothed_hr_conf,
|
||||
signal_quality: raw.signal_quality,
|
||||
}
|
||||
}
|
||||
|
||||
// ── Multi-person estimation ─────────────────────────────────────────────────
|
||||
|
||||
pub fn fuse_multi_node_features(
|
||||
current_features: &FeatureInfo, node_states: &HashMap<u8, NodeState>,
|
||||
) -> FeatureInfo {
|
||||
let now = std::time::Instant::now();
|
||||
let active: Vec<(&FeatureInfo, f64)> = node_states.values()
|
||||
.filter(|ns| ns.last_frame_time.map_or(false, |t| now.duration_since(t).as_secs() < 10))
|
||||
.filter_map(|ns| {
|
||||
let feat = ns.latest_features.as_ref()?;
|
||||
let rssi = ns.rssi_history.back().copied().unwrap_or(-80.0);
|
||||
Some((feat, rssi))
|
||||
})
|
||||
.collect();
|
||||
|
||||
if active.len() <= 1 { return current_features.clone(); }
|
||||
|
||||
let max_rssi = active.iter().map(|(_, r)| *r).fold(f64::NEG_INFINITY, f64::max);
|
||||
let weights: Vec<f64> = active.iter()
|
||||
.map(|(_, r)| (1.0 + (r - max_rssi + 20.0) / 20.0).clamp(0.1, 1.0)).collect();
|
||||
let w_sum: f64 = weights.iter().sum::<f64>().max(1e-9);
|
||||
|
||||
FeatureInfo {
|
||||
variance: active.iter().zip(&weights).map(|((f, _), w)| f.variance * w).sum::<f64>() / w_sum,
|
||||
motion_band_power: active.iter().zip(&weights).map(|((f, _), w)| f.motion_band_power * w).sum::<f64>() / w_sum,
|
||||
breathing_band_power: active.iter().zip(&weights).map(|((f, _), w)| f.breathing_band_power * w).sum::<f64>() / w_sum,
|
||||
spectral_power: active.iter().zip(&weights).map(|((f, _), w)| f.spectral_power * w).sum::<f64>() / w_sum,
|
||||
dominant_freq_hz: active.iter().zip(&weights).map(|((f, _), w)| f.dominant_freq_hz * w).sum::<f64>() / w_sum,
|
||||
change_points: current_features.change_points,
|
||||
mean_rssi: active.iter().map(|(f, _)| f.mean_rssi).fold(f64::NEG_INFINITY, f64::max),
|
||||
}
|
||||
}
|
||||
|
||||
pub fn compute_person_score(feat: &FeatureInfo) -> f64 {
|
||||
let var_norm = (feat.variance / 300.0).clamp(0.0, 1.0);
|
||||
let cp_norm = (feat.change_points as f64 / 30.0).clamp(0.0, 1.0);
|
||||
let motion_norm = (feat.motion_band_power / 250.0).clamp(0.0, 1.0);
|
||||
let sp_norm = (feat.spectral_power / 500.0).clamp(0.0, 1.0);
|
||||
var_norm * 0.40 + cp_norm * 0.20 + motion_norm * 0.25 + sp_norm * 0.15
|
||||
}
|
||||
|
||||
pub fn estimate_persons_from_correlation(frame_history: &VecDeque<Vec<f64>>) -> usize {
|
||||
let n_frames = frame_history.len();
|
||||
if n_frames < 10 { return 1; }
|
||||
|
||||
let window: Vec<&Vec<f64>> = frame_history.iter().rev().take(20).collect();
|
||||
let n_sub = window[0].len().min(56);
|
||||
if n_sub < 4 { return 1; }
|
||||
let k = window.len() as f64;
|
||||
|
||||
let mut means = vec![0.0f64; n_sub];
|
||||
let mut variances = vec![0.0f64; n_sub];
|
||||
for frame in &window {
|
||||
for sc in 0..n_sub.min(frame.len()) { means[sc] += frame[sc] / k; }
|
||||
}
|
||||
for frame in &window {
|
||||
for sc in 0..n_sub.min(frame.len()) { variances[sc] += (frame[sc] - means[sc]).powi(2) / k; }
|
||||
}
|
||||
|
||||
let noise_floor = 1.0;
|
||||
let active: Vec<usize> = (0..n_sub).filter(|&sc| variances[sc] > noise_floor).collect();
|
||||
let m = active.len();
|
||||
if m < 3 { return if m == 0 { 0 } else { 1 }; }
|
||||
|
||||
let mut edges: Vec<(u64, u64, f64)> = Vec::new();
|
||||
let source = m as u64;
|
||||
let sink = (m + 1) as u64;
|
||||
let stds: Vec<f64> = active.iter().map(|&sc| variances[sc].sqrt().max(1e-9)).collect();
|
||||
|
||||
for i in 0..m {
|
||||
for j in (i + 1)..m {
|
||||
let mut cov = 0.0f64;
|
||||
for frame in &window {
|
||||
let (si, sj) = (active[i], active[j]);
|
||||
if si < frame.len() && sj < frame.len() {
|
||||
cov += (frame[si] - means[si]) * (frame[sj] - means[sj]) / k;
|
||||
}
|
||||
}
|
||||
let corr = (cov / (stds[i] * stds[j])).abs();
|
||||
if corr > 0.1 {
|
||||
let weight = corr * 10.0;
|
||||
edges.push((i as u64, j as u64, weight));
|
||||
edges.push((j as u64, i as u64, weight));
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
let (max_var_idx, _) = active.iter().enumerate()
|
||||
.max_by(|(_, &a), (_, &b)| variances[a].partial_cmp(&variances[b]).unwrap())
|
||||
.unwrap_or((0, &0));
|
||||
let (min_var_idx, _) = active.iter().enumerate()
|
||||
.min_by(|(_, &a), (_, &b)| variances[a].partial_cmp(&variances[b]).unwrap())
|
||||
.unwrap_or((0, &0));
|
||||
if max_var_idx == min_var_idx { return 1; }
|
||||
|
||||
edges.push((source, max_var_idx as u64, 100.0));
|
||||
edges.push((min_var_idx as u64, sink, 100.0));
|
||||
|
||||
let mc: DynamicMinCut = match MinCutBuilder::new().exact().with_edges(edges.clone()).build() {
|
||||
Ok(mc) => mc,
|
||||
Err(_) => return 1,
|
||||
};
|
||||
|
||||
let cut_value = mc.min_cut_value();
|
||||
let total_edge_weight: f64 = edges.iter()
|
||||
.filter(|(s, t, _)| *s != source && *s != sink && *t != source && *t != sink)
|
||||
.map(|(_, _, w)| w).sum::<f64>() / 2.0;
|
||||
if total_edge_weight < 1e-9 { return 1; }
|
||||
|
||||
let cut_ratio = cut_value / total_edge_weight;
|
||||
if cut_ratio > 0.4 { 1 }
|
||||
else if cut_ratio > 0.15 { 2 }
|
||||
else { 3 }
|
||||
}
|
||||
|
||||
pub fn score_to_person_count(smoothed_score: f64, prev_count: usize) -> usize {
|
||||
match prev_count {
|
||||
0 | 1 => {
|
||||
if smoothed_score > 0.85 { 3 }
|
||||
else if smoothed_score > 0.70 { 2 }
|
||||
else { 1 }
|
||||
}
|
||||
2 => {
|
||||
if smoothed_score > 0.92 { 3 }
|
||||
else if smoothed_score < 0.55 { 1 }
|
||||
else { 2 }
|
||||
}
|
||||
_ => {
|
||||
if smoothed_score < 0.55 { 1 }
|
||||
else if smoothed_score < 0.78 { 2 }
|
||||
else { 3 }
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/// Generate a simulated ESP32 frame for testing/demo mode.
|
||||
pub fn generate_simulated_frame(tick: u64) -> Esp32Frame {
|
||||
let t = tick as f64 * 0.1;
|
||||
let n_sub = 56usize;
|
||||
let mut amplitudes = Vec::with_capacity(n_sub);
|
||||
let mut phases = Vec::with_capacity(n_sub);
|
||||
for i in 0..n_sub {
|
||||
let base = 15.0 + 5.0 * (i as f64 * 0.1 + t * 0.3).sin();
|
||||
let noise = (i as f64 * 7.3 + t * 13.7).sin() * 2.0;
|
||||
amplitudes.push((base + noise).max(0.1));
|
||||
phases.push((i as f64 * 0.2 + t * 0.5).sin() * std::f64::consts::PI);
|
||||
}
|
||||
Esp32Frame {
|
||||
magic: 0xC511_0001, node_id: 1, n_antennas: 1, n_subcarriers: n_sub as u8,
|
||||
freq_mhz: 2437, sequence: tick as u32,
|
||||
rssi: (-40.0 + 5.0 * (t * 0.2).sin()) as i8, noise_floor: -90,
|
||||
amplitudes, phases,
|
||||
}
|
||||
}
|
||||
|
||||
/// Generate a simple timestamp (epoch seconds) for recording IDs.
|
||||
pub fn chrono_timestamp() -> u64 {
|
||||
std::time::SystemTime::now()
|
||||
.duration_since(std::time::UNIX_EPOCH)
|
||||
.map(|d| d.as_secs())
|
||||
.unwrap_or(0)
|
||||
}
|
||||
@@ -1,161 +0,0 @@
|
||||
//! Bridge between sensing-server frame data and signal crate FieldModel
|
||||
//! for eigenvalue-based person counting.
|
||||
//!
|
||||
//! The FieldModel decomposes CSI observations into environmental drift and
|
||||
//! body perturbation via SVD eigenmodes. When calibrated, perturbation energy
|
||||
//! provides a physics-grounded occupancy estimate that supplements the
|
||||
//! score-based heuristic in `score_to_person_count`.
|
||||
|
||||
use std::collections::VecDeque;
|
||||
use wifi_densepose_signal::ruvsense::field_model::{CalibrationStatus, FieldModel, FieldModelConfig};
|
||||
|
||||
use super::score_to_person_count;
|
||||
|
||||
/// Number of recent frames to feed into perturbation extraction.
|
||||
const OCCUPANCY_WINDOW: usize = 50;
|
||||
|
||||
/// Perturbation energy threshold for detecting a second person.
|
||||
const ENERGY_THRESH_2: f64 = 12.0;
|
||||
/// Perturbation energy threshold for detecting a third person.
|
||||
const ENERGY_THRESH_3: f64 = 25.0;
|
||||
|
||||
/// Create a FieldModelConfig for single-link mode (one ESP32 node = one link).
|
||||
/// This avoids the DimensionMismatch error when feeding single-frame observations.
|
||||
pub fn single_link_config() -> FieldModelConfig {
|
||||
FieldModelConfig {
|
||||
n_links: 1,
|
||||
..FieldModelConfig::default()
|
||||
}
|
||||
}
|
||||
|
||||
/// Estimate occupancy using the FieldModel when calibrated, falling back
|
||||
/// to the score-based heuristic otherwise.
|
||||
///
|
||||
/// Prefers `estimate_occupancy()` (eigenvalue-based) when the model is
|
||||
/// calibrated and enough frames are available. Falls back to perturbation
|
||||
/// energy thresholds, then to the score heuristic.
|
||||
pub fn occupancy_or_fallback(
|
||||
field: &FieldModel,
|
||||
frame_history: &VecDeque<Vec<f64>>,
|
||||
smoothed_score: f64,
|
||||
prev_count: usize,
|
||||
) -> usize {
|
||||
match field.status() {
|
||||
CalibrationStatus::Fresh | CalibrationStatus::Stale => {
|
||||
let frames: Vec<Vec<f64>> = frame_history
|
||||
.iter()
|
||||
.rev()
|
||||
.take(OCCUPANCY_WINDOW)
|
||||
.cloned()
|
||||
.collect();
|
||||
|
||||
if frames.is_empty() {
|
||||
return score_to_person_count(smoothed_score, prev_count);
|
||||
}
|
||||
|
||||
// Try eigenvalue-based occupancy first (best accuracy).
|
||||
match field.estimate_occupancy(&frames) {
|
||||
Ok(count) => return count,
|
||||
Err(_) => {} // fall through to perturbation energy
|
||||
}
|
||||
|
||||
// Fallback: perturbation energy thresholds.
|
||||
// FieldModel expects [n_links][n_subcarriers] — we use n_links=1.
|
||||
let observation = vec![frames[0].clone()];
|
||||
match field.extract_perturbation(&observation) {
|
||||
Ok(perturbation) => {
|
||||
if perturbation.total_energy > ENERGY_THRESH_3 {
|
||||
3
|
||||
} else if perturbation.total_energy > ENERGY_THRESH_2 {
|
||||
2
|
||||
} else if perturbation.total_energy > 1.0 {
|
||||
1
|
||||
} else {
|
||||
0
|
||||
}
|
||||
}
|
||||
Err(_) => score_to_person_count(smoothed_score, prev_count),
|
||||
}
|
||||
}
|
||||
_ => score_to_person_count(smoothed_score, prev_count),
|
||||
}
|
||||
}
|
||||
|
||||
/// Feed the latest frame to the FieldModel during calibration collection.
|
||||
///
|
||||
/// Only acts when the model status is `Collecting`. Wraps the latest frame
|
||||
/// as a single-link observation (n_links=1) and feeds it.
|
||||
pub fn maybe_feed_calibration(field: &mut FieldModel, frame_history: &VecDeque<Vec<f64>>) {
|
||||
if field.status() != CalibrationStatus::Collecting {
|
||||
return;
|
||||
}
|
||||
if let Some(latest) = frame_history.back() {
|
||||
// Single-link observation: [1][n_subcarriers]
|
||||
let observations = vec![latest.clone()];
|
||||
if let Err(e) = field.feed_calibration(&observations) {
|
||||
tracing::debug!("FieldModel calibration feed: {e}");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/// Parse node positions from a semicolon-delimited string.
|
||||
///
|
||||
/// Format: `"x,y,z;x,y,z;..."` where each coordinate is an `f32`.
|
||||
/// Malformed entries are skipped with a warning log.
|
||||
pub fn parse_node_positions(input: &str) -> Vec<[f32; 3]> {
|
||||
if input.is_empty() {
|
||||
return Vec::new();
|
||||
}
|
||||
input
|
||||
.split(';')
|
||||
.enumerate()
|
||||
.filter_map(|(idx, triplet)| {
|
||||
let parts: Vec<&str> = triplet.split(',').collect();
|
||||
if parts.len() != 3 {
|
||||
tracing::warn!("Skipping malformed node position entry {idx}: '{triplet}' (expected x,y,z)");
|
||||
return None;
|
||||
}
|
||||
match (parts[0].parse::<f32>(), parts[1].parse::<f32>(), parts[2].parse::<f32>()) {
|
||||
(Ok(x), Ok(y), Ok(z)) => Some([x, y, z]),
|
||||
_ => {
|
||||
tracing::warn!("Skipping unparseable node position entry {idx}: '{triplet}'");
|
||||
None
|
||||
}
|
||||
}
|
||||
})
|
||||
.collect()
|
||||
}
|
||||
|
||||
#[cfg(test)]
|
||||
mod tests {
|
||||
use super::*;
|
||||
|
||||
#[test]
|
||||
fn test_parse_node_positions() {
|
||||
let positions = parse_node_positions("0,0,1.5;3,0,1.5;1.5,3,1.5");
|
||||
assert_eq!(positions.len(), 3);
|
||||
assert_eq!(positions[0], [0.0, 0.0, 1.5]);
|
||||
assert_eq!(positions[1], [3.0, 0.0, 1.5]);
|
||||
assert_eq!(positions[2], [1.5, 3.0, 1.5]);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_parse_node_positions_empty() {
|
||||
let positions = parse_node_positions("");
|
||||
assert!(positions.is_empty());
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_parse_node_positions_invalid() {
|
||||
let positions = parse_node_positions("abc;1,2,3");
|
||||
assert_eq!(positions.len(), 1);
|
||||
assert_eq!(positions[0], [1.0, 2.0, 3.0]);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_parse_node_positions_partial_triplet() {
|
||||
let positions = parse_node_positions("1,2;3,4,5");
|
||||
assert_eq!(positions.len(), 1);
|
||||
assert_eq!(positions[0], [3.0, 4.0, 5.0]);
|
||||
}
|
||||
}
|
||||
File diff suppressed because it is too large
Load Diff
-264
@@ -1,264 +0,0 @@
|
||||
//! Bridge between sensing-server per-node state and the signal crate's
|
||||
//! `MultistaticFuser` for attention-weighted CSI fusion across ESP32 nodes.
|
||||
//!
|
||||
//! This module converts the server's `NodeState` (f64 amplitude history) into
|
||||
//! `MultiBandCsiFrame`s that the multistatic fusion pipeline expects, then
|
||||
//! drives `MultistaticFuser::fuse` with a graceful fallback when fusion fails
|
||||
//! (e.g. insufficient nodes or timestamp spread).
|
||||
|
||||
use std::collections::HashMap;
|
||||
use std::sync::LazyLock;
|
||||
use std::time::{Duration, Instant};
|
||||
|
||||
use wifi_densepose_signal::hardware_norm::{CanonicalCsiFrame, HardwareType};
|
||||
use wifi_densepose_signal::ruvsense::multiband::MultiBandCsiFrame;
|
||||
use wifi_densepose_signal::ruvsense::multistatic::{FusedSensingFrame, MultistaticFuser};
|
||||
|
||||
use super::NodeState;
|
||||
|
||||
/// Maximum age for a node frame to be considered active (10 seconds).
|
||||
const STALE_THRESHOLD: Duration = Duration::from_secs(10);
|
||||
|
||||
/// Default WiFi channel frequency (MHz) used for single-channel frames.
|
||||
const DEFAULT_FREQ_MHZ: u32 = 2437; // Channel 6
|
||||
|
||||
/// Monotonic reference point for timestamp generation. All node timestamps
|
||||
/// are relative to this instant, avoiding wall-clock/monotonic mixing issues.
|
||||
static EPOCH: LazyLock<Instant> = LazyLock::new(Instant::now);
|
||||
|
||||
/// Convert a single `NodeState` into a `MultiBandCsiFrame` suitable for
|
||||
/// multistatic fusion.
|
||||
///
|
||||
/// Returns `None` when the node has no frame history or no recorded
|
||||
/// `last_frame_time`.
|
||||
pub fn node_frame_from_state(node_id: u8, ns: &NodeState) -> Option<MultiBandCsiFrame> {
|
||||
let last_time = ns.last_frame_time.as_ref()?;
|
||||
let latest = ns.frame_history.back()?;
|
||||
if latest.is_empty() {
|
||||
return None;
|
||||
}
|
||||
|
||||
let amplitude: Vec<f32> = latest.iter().map(|&v| v as f32).collect();
|
||||
let n_sub = amplitude.len();
|
||||
let phase = vec![0.0_f32; n_sub];
|
||||
|
||||
// Monotonic timestamp: microseconds since a shared process-local epoch.
|
||||
// All nodes use the same reference so the fuser's guard_interval_us check
|
||||
// compares apples to apples. No wall-clock mixing (immune to NTP jumps).
|
||||
let timestamp_us = last_time.duration_since(*EPOCH).as_micros() as u64;
|
||||
|
||||
let canonical = CanonicalCsiFrame {
|
||||
amplitude,
|
||||
phase,
|
||||
hardware_type: HardwareType::Esp32S3,
|
||||
};
|
||||
|
||||
Some(MultiBandCsiFrame {
|
||||
node_id,
|
||||
timestamp_us,
|
||||
channel_frames: vec![canonical],
|
||||
frequencies_mhz: vec![DEFAULT_FREQ_MHZ],
|
||||
coherence: 1.0, // single-channel, perfect self-coherence
|
||||
})
|
||||
}
|
||||
|
||||
/// Collect `MultiBandCsiFrame`s from all active nodes.
|
||||
///
|
||||
/// A node is considered active if its `last_frame_time` is within
|
||||
/// [`STALE_THRESHOLD`] of `now`.
|
||||
pub fn node_frames_from_states(node_states: &HashMap<u8, NodeState>) -> Vec<MultiBandCsiFrame> {
|
||||
let now = Instant::now();
|
||||
let mut frames = Vec::with_capacity(node_states.len());
|
||||
|
||||
for (&node_id, ns) in node_states {
|
||||
// Skip stale nodes
|
||||
if let Some(ref t) = ns.last_frame_time {
|
||||
if now.duration_since(*t) > STALE_THRESHOLD {
|
||||
continue;
|
||||
}
|
||||
} else {
|
||||
continue;
|
||||
}
|
||||
|
||||
if let Some(frame) = node_frame_from_state(node_id, ns) {
|
||||
frames.push(frame);
|
||||
}
|
||||
}
|
||||
|
||||
frames
|
||||
}
|
||||
|
||||
/// Attempt multistatic fusion; fall back to max per-node person count on failure.
|
||||
///
|
||||
/// Returns `(fused_frame, fallback_person_count)`. When fusion succeeds,
|
||||
/// `fallback_person_count` is `None` — the caller must compute count from
|
||||
/// the fused amplitudes. On failure, returns the maximum per-node count
|
||||
/// (not the sum, to avoid double-counting overlapping coverage).
|
||||
pub fn fuse_or_fallback(
|
||||
fuser: &MultistaticFuser,
|
||||
node_states: &HashMap<u8, NodeState>,
|
||||
) -> (Option<FusedSensingFrame>, Option<usize>) {
|
||||
let frames = node_frames_from_states(node_states);
|
||||
if frames.is_empty() {
|
||||
return (None, Some(0));
|
||||
}
|
||||
|
||||
match fuser.fuse(&frames) {
|
||||
Ok(fused) => {
|
||||
// Caller must compute person count from fused amplitudes.
|
||||
(Some(fused), None)
|
||||
}
|
||||
Err(e) => {
|
||||
tracing::debug!("Multistatic fusion failed ({e}), using per-node max fallback");
|
||||
// Use max (not sum) to avoid double-counting when nodes have overlapping coverage.
|
||||
let max_count: usize = node_states
|
||||
.values()
|
||||
.filter(|ns| {
|
||||
ns.last_frame_time
|
||||
.map(|t| t.elapsed() <= STALE_THRESHOLD)
|
||||
.unwrap_or(false)
|
||||
})
|
||||
.map(|ns| ns.prev_person_count)
|
||||
.max()
|
||||
.unwrap_or(0);
|
||||
(None, Some(max_count))
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/// Compute a person-presence score from fused amplitude data.
|
||||
///
|
||||
/// Uses the squared coefficient of variation (variance / mean^2) as a
|
||||
/// lightweight proxy for body-induced CSI perturbation. A flat amplitude
|
||||
/// vector (no person) yields a score near zero; a vector with high variance
|
||||
/// relative to its mean (person moving) yields a score approaching 1.0.
|
||||
pub fn compute_person_score_from_amplitudes(amplitudes: &[f32]) -> f64 {
|
||||
if amplitudes.is_empty() {
|
||||
return 0.0;
|
||||
}
|
||||
|
||||
let n = amplitudes.len() as f64;
|
||||
let sum: f64 = amplitudes.iter().map(|&a| a as f64).sum();
|
||||
let mean = sum / n;
|
||||
|
||||
let variance: f64 = amplitudes.iter().map(|&a| {
|
||||
let diff = (a as f64) - mean;
|
||||
diff * diff
|
||||
}).sum::<f64>() / n;
|
||||
|
||||
let score = variance / (mean * mean + 1e-10);
|
||||
score.clamp(0.0, 1.0)
|
||||
}
|
||||
|
||||
#[cfg(test)]
|
||||
mod tests {
|
||||
use super::*;
|
||||
use std::collections::VecDeque;
|
||||
|
||||
/// Helper: build a minimal NodeState for testing. Uses `NodeState::new()`
|
||||
/// then mutates the `pub(crate)` fields the bridge needs.
|
||||
fn make_node_state(
|
||||
frame_history: VecDeque<Vec<f64>>,
|
||||
last_frame_time: Option<Instant>,
|
||||
prev_person_count: usize,
|
||||
) -> NodeState {
|
||||
let mut ns = NodeState::new();
|
||||
ns.frame_history = frame_history;
|
||||
ns.last_frame_time = last_frame_time;
|
||||
ns.prev_person_count = prev_person_count;
|
||||
ns
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_node_frame_from_empty_state() {
|
||||
let ns = make_node_state(VecDeque::new(), Some(Instant::now()), 0);
|
||||
assert!(node_frame_from_state(1, &ns).is_none());
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_node_frame_from_state_no_time() {
|
||||
let mut history = VecDeque::new();
|
||||
history.push_back(vec![1.0, 2.0, 3.0]);
|
||||
let ns = make_node_state(history, None, 0);
|
||||
assert!(node_frame_from_state(1, &ns).is_none());
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_node_frame_conversion() {
|
||||
let mut history = VecDeque::new();
|
||||
history.push_back(vec![10.0, 20.0, 30.5]);
|
||||
let ns = make_node_state(history, Some(Instant::now()), 0);
|
||||
|
||||
let frame = node_frame_from_state(42, &ns).expect("should produce a frame");
|
||||
assert_eq!(frame.node_id, 42);
|
||||
assert_eq!(frame.channel_frames.len(), 1);
|
||||
|
||||
let ch = &frame.channel_frames[0];
|
||||
assert_eq!(ch.amplitude.len(), 3);
|
||||
assert!((ch.amplitude[0] - 10.0_f32).abs() < f32::EPSILON);
|
||||
assert!((ch.amplitude[1] - 20.0_f32).abs() < f32::EPSILON);
|
||||
assert!((ch.amplitude[2] - 30.5_f32).abs() < f32::EPSILON);
|
||||
// Phase should be all zeros
|
||||
assert!(ch.phase.iter().all(|&p| p == 0.0));
|
||||
assert_eq!(ch.hardware_type, HardwareType::Esp32S3);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_stale_node_excluded() {
|
||||
let mut states: HashMap<u8, NodeState> = HashMap::new();
|
||||
|
||||
// Active node: frame just received
|
||||
let mut active_history = VecDeque::new();
|
||||
active_history.push_back(vec![1.0, 2.0]);
|
||||
states.insert(1, make_node_state(active_history, Some(Instant::now()), 1));
|
||||
|
||||
// Stale node: frame 20 seconds ago
|
||||
let mut stale_history = VecDeque::new();
|
||||
stale_history.push_back(vec![3.0, 4.0]);
|
||||
let stale_time = Instant::now() - Duration::from_secs(20);
|
||||
states.insert(2, make_node_state(stale_history, Some(stale_time), 1));
|
||||
|
||||
let frames = node_frames_from_states(&states);
|
||||
assert_eq!(frames.len(), 1, "stale node should be excluded");
|
||||
assert_eq!(frames[0].node_id, 1);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_compute_person_score_empty() {
|
||||
assert!((compute_person_score_from_amplitudes(&[]) - 0.0).abs() < f64::EPSILON);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_compute_person_score_flat() {
|
||||
// Constant amplitude => variance = 0 => score ~ 0
|
||||
let flat = vec![5.0_f32; 64];
|
||||
let score = compute_person_score_from_amplitudes(&flat);
|
||||
assert!(score < 0.001, "flat signal should have near-zero score, got {score}");
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_compute_person_score_varied() {
|
||||
// High variance relative to mean should produce a positive score
|
||||
let varied: Vec<f32> = (0..64).map(|i| if i % 2 == 0 { 1.0 } else { 10.0 }).collect();
|
||||
let score = compute_person_score_from_amplitudes(&varied);
|
||||
assert!(score > 0.1, "varied signal should have positive score, got {score}");
|
||||
assert!(score <= 1.0, "score should be clamped to 1.0, got {score}");
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_compute_person_score_clamped() {
|
||||
// Near-zero mean with non-zero variance => would blow up without clamp
|
||||
let vals = vec![0.0_f32, 0.0, 0.0, 0.001];
|
||||
let score = compute_person_score_from_amplitudes(&vals);
|
||||
assert!(score <= 1.0, "score must be clamped to 1.0");
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn test_fuse_or_fallback_empty() {
|
||||
let fuser = MultistaticFuser::new();
|
||||
let states: HashMap<u8, NodeState> = HashMap::new();
|
||||
let (fused, count) = fuse_or_fallback(&fuser, &states);
|
||||
assert!(fused.is_none());
|
||||
assert_eq!(count, Some(0));
|
||||
}
|
||||
}
|
||||
@@ -1,194 +0,0 @@
|
||||
//! Skeleton derivation, pose estimation, and temporal smoothing.
|
||||
|
||||
use crate::types::*;
|
||||
|
||||
/// Expected bone lengths in pixel-space for the COCO-17 skeleton.
|
||||
pub const POSE_BONE_PAIRS: &[(usize, usize)] = &[
|
||||
(5, 7), (7, 9), (6, 8), (8, 10),
|
||||
(5, 11), (6, 12),
|
||||
(11, 13), (13, 15), (12, 14), (14, 16),
|
||||
(5, 6), (11, 12),
|
||||
];
|
||||
|
||||
const TORSO_KP: [usize; 4] = [5, 6, 11, 12];
|
||||
const EXTREMITY_KP: [usize; 4] = [9, 10, 15, 16];
|
||||
|
||||
pub fn derive_single_person_pose(
|
||||
update: &SensingUpdate, person_idx: usize, total_persons: usize,
|
||||
) -> PersonDetection {
|
||||
let cls = &update.classification;
|
||||
let feat = &update.features;
|
||||
|
||||
let phase_offset = person_idx as f64 * 2.094;
|
||||
let half = (total_persons as f64 - 1.0) / 2.0;
|
||||
let person_x_offset = (person_idx as f64 - half) * 120.0;
|
||||
let conf_decay = 1.0 - person_idx as f64 * 0.15;
|
||||
|
||||
let motion_score = (feat.motion_band_power / 15.0).clamp(0.0, 1.0);
|
||||
let is_walking = motion_score > 0.55;
|
||||
let breath_amp = (feat.breathing_band_power * 4.0).clamp(0.0, 12.0);
|
||||
|
||||
let breath_phase = if let Some(ref vs) = update.vital_signs {
|
||||
let bpm = vs.breathing_rate_bpm.unwrap_or(15.0);
|
||||
let freq = (bpm / 60.0).clamp(0.1, 0.5);
|
||||
(update.tick as f64 * freq * 0.02 * std::f64::consts::TAU + phase_offset).sin()
|
||||
} else {
|
||||
(update.tick as f64 * 0.02 + phase_offset).sin()
|
||||
};
|
||||
|
||||
let lean_x = (feat.dominant_freq_hz / 5.0 - 1.0).clamp(-1.0, 1.0) * 18.0;
|
||||
let stride_x = if is_walking {
|
||||
let stride_phase = (feat.motion_band_power * 0.7 + update.tick as f64 * 0.06 + phase_offset).sin();
|
||||
stride_phase * 20.0 * motion_score
|
||||
} else { 0.0 };
|
||||
|
||||
let burst = (feat.change_points as f64 / 20.0).clamp(0.0, 0.3);
|
||||
let noise_seed = person_idx as f64 * 97.1;
|
||||
let noise_val = (noise_seed.sin() * 43758.545).fract();
|
||||
let snr_factor = ((feat.variance - 0.5) / 10.0).clamp(0.0, 1.0);
|
||||
let base_confidence = cls.confidence * (0.6 + 0.4 * snr_factor) * conf_decay;
|
||||
|
||||
let base_x = 320.0 + stride_x + lean_x * 0.5 + person_x_offset;
|
||||
let base_y = 240.0 - motion_score * 8.0;
|
||||
|
||||
let kp_names = [
|
||||
"nose", "left_eye", "right_eye", "left_ear", "right_ear",
|
||||
"left_shoulder", "right_shoulder", "left_elbow", "right_elbow",
|
||||
"left_wrist", "right_wrist", "left_hip", "right_hip",
|
||||
"left_knee", "right_knee", "left_ankle", "right_ankle",
|
||||
];
|
||||
|
||||
let kp_offsets: [(f64, f64); 17] = [
|
||||
(0.0, -80.0), (-8.0, -88.0), (8.0, -88.0), (-16.0, -82.0), (16.0, -82.0),
|
||||
(-30.0, -50.0), (30.0, -50.0), (-45.0, -15.0), (45.0, -15.0),
|
||||
(-50.0, 20.0), (50.0, 20.0), (-20.0, 20.0), (20.0, 20.0),
|
||||
(-22.0, 70.0), (22.0, 70.0), (-24.0, 120.0), (24.0, 120.0),
|
||||
];
|
||||
|
||||
let keypoints: Vec<PoseKeypoint> = kp_names.iter().zip(kp_offsets.iter())
|
||||
.enumerate()
|
||||
.map(|(i, (name, (dx, dy)))| {
|
||||
let breath_dx = if TORSO_KP.contains(&i) {
|
||||
let sign = if *dx < 0.0 { -1.0 } else { 1.0 };
|
||||
sign * breath_amp * breath_phase * 0.5
|
||||
} else { 0.0 };
|
||||
let breath_dy = if TORSO_KP.contains(&i) {
|
||||
let sign = if *dy < 0.0 { -1.0 } else { 1.0 };
|
||||
sign * breath_amp * breath_phase * 0.3
|
||||
} else { 0.0 };
|
||||
|
||||
let extremity_jitter = if EXTREMITY_KP.contains(&i) {
|
||||
let phase = noise_seed + i as f64 * 2.399;
|
||||
(phase.sin() * burst * motion_score * 4.0, (phase * 1.31).cos() * burst * motion_score * 3.0)
|
||||
} else { (0.0, 0.0) };
|
||||
|
||||
let kp_noise_x = ((noise_seed + i as f64 * 1.618).sin() * 43758.545).fract()
|
||||
* feat.variance.sqrt().clamp(0.0, 3.0) * motion_score;
|
||||
let kp_noise_y = ((noise_seed + i as f64 * 2.718).cos() * 31415.926).fract()
|
||||
* feat.variance.sqrt().clamp(0.0, 3.0) * motion_score * 0.6;
|
||||
|
||||
let swing_dy = if is_walking {
|
||||
let stride_phase = (feat.motion_band_power * 0.7 + update.tick as f64 * 0.12 + phase_offset).sin();
|
||||
match i {
|
||||
7 | 9 => -stride_phase * 20.0 * motion_score,
|
||||
8 | 10 => stride_phase * 20.0 * motion_score,
|
||||
13 | 15 => stride_phase * 25.0 * motion_score,
|
||||
14 | 16 => -stride_phase * 25.0 * motion_score,
|
||||
_ => 0.0,
|
||||
}
|
||||
} else { 0.0 };
|
||||
|
||||
let final_x = base_x + dx + breath_dx + extremity_jitter.0 + kp_noise_x;
|
||||
let final_y = base_y + dy + breath_dy + extremity_jitter.1 + kp_noise_y + swing_dy;
|
||||
|
||||
let kp_conf = if EXTREMITY_KP.contains(&i) {
|
||||
base_confidence * (0.7 + 0.3 * snr_factor) * (0.85 + 0.15 * noise_val)
|
||||
} else {
|
||||
base_confidence * (0.88 + 0.12 * ((i as f64 * 0.7 + noise_seed).cos()))
|
||||
};
|
||||
|
||||
PoseKeypoint { name: name.to_string(), x: final_x, y: final_y, z: lean_x * 0.02, confidence: kp_conf.clamp(0.1, 1.0) }
|
||||
})
|
||||
.collect();
|
||||
|
||||
let xs: Vec<f64> = keypoints.iter().map(|k| k.x).collect();
|
||||
let ys: Vec<f64> = keypoints.iter().map(|k| k.y).collect();
|
||||
let min_x = xs.iter().cloned().fold(f64::MAX, f64::min) - 10.0;
|
||||
let min_y = ys.iter().cloned().fold(f64::MAX, f64::min) - 10.0;
|
||||
let max_x = xs.iter().cloned().fold(f64::MIN, f64::max) + 10.0;
|
||||
let max_y = ys.iter().cloned().fold(f64::MIN, f64::max) + 10.0;
|
||||
|
||||
PersonDetection {
|
||||
id: (person_idx + 1) as u32,
|
||||
confidence: cls.confidence * conf_decay,
|
||||
keypoints,
|
||||
bbox: BoundingBox { x: min_x, y: min_y, width: (max_x - min_x).max(80.0), height: (max_y - min_y).max(160.0) },
|
||||
zone: format!("zone_{}", person_idx + 1),
|
||||
}
|
||||
}
|
||||
|
||||
pub fn derive_pose_from_sensing(update: &SensingUpdate) -> Vec<PersonDetection> {
|
||||
let cls = &update.classification;
|
||||
if !cls.presence { return vec![]; }
|
||||
let person_count = update.estimated_persons.unwrap_or(1).max(1);
|
||||
(0..person_count).map(|idx| derive_single_person_pose(update, idx, person_count)).collect()
|
||||
}
|
||||
|
||||
/// Apply temporal EMA smoothing and bone-length clamping to person detections.
|
||||
pub fn apply_temporal_smoothing(persons: &mut [PersonDetection], ns: &mut NodeState) {
|
||||
if persons.is_empty() { return; }
|
||||
|
||||
let alpha = ns.ema_alpha();
|
||||
let person = &mut persons[0];
|
||||
|
||||
let current_kps: Vec<[f64; 3]> = person.keypoints.iter()
|
||||
.map(|kp| [kp.x, kp.y, kp.z]).collect();
|
||||
|
||||
let smoothed = if let Some(ref prev) = ns.prev_keypoints {
|
||||
let mut out = Vec::with_capacity(current_kps.len());
|
||||
for (cur, prv) in current_kps.iter().zip(prev.iter()) {
|
||||
out.push([
|
||||
alpha * cur[0] + (1.0 - alpha) * prv[0],
|
||||
alpha * cur[1] + (1.0 - alpha) * prv[1],
|
||||
alpha * cur[2] + (1.0 - alpha) * prv[2],
|
||||
]);
|
||||
}
|
||||
clamp_bone_lengths_f64(&mut out, prev);
|
||||
out
|
||||
} else {
|
||||
current_kps.clone()
|
||||
};
|
||||
|
||||
for (kp, s) in person.keypoints.iter_mut().zip(smoothed.iter()) {
|
||||
kp.x = s[0]; kp.y = s[1]; kp.z = s[2];
|
||||
}
|
||||
ns.prev_keypoints = Some(smoothed);
|
||||
}
|
||||
|
||||
fn clamp_bone_lengths_f64(pose: &mut Vec<[f64; 3]>, prev: &[[f64; 3]]) {
|
||||
for &(p, c) in POSE_BONE_PAIRS {
|
||||
if p >= pose.len() || c >= pose.len() { continue; }
|
||||
let prev_len = dist_f64(&prev[p], &prev[c]);
|
||||
if prev_len < 1e-6 { continue; }
|
||||
let cur_len = dist_f64(&pose[p], &pose[c]);
|
||||
if cur_len < 1e-6 { continue; }
|
||||
let ratio = cur_len / prev_len;
|
||||
let lo = 1.0 - MAX_BONE_CHANGE_RATIO;
|
||||
let hi = 1.0 + MAX_BONE_CHANGE_RATIO;
|
||||
if ratio < lo || ratio > hi {
|
||||
let target = prev_len * ratio.clamp(lo, hi);
|
||||
let scale = target / cur_len;
|
||||
for dim in 0..3 {
|
||||
let diff = pose[c][dim] - pose[p][dim];
|
||||
pose[c][dim] = pose[p][dim] + diff * scale;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
fn dist_f64(a: &[f64; 3], b: &[f64; 3]) -> f64 {
|
||||
let dx = b[0] - a[0];
|
||||
let dy = b[1] - a[1];
|
||||
let dz = b[2] - a[2];
|
||||
(dx * dx + dy * dy + dz * dz).sqrt()
|
||||
}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user