* feat(ADR-262 P3): live RuField surface — RuView sensing speaks RuField on /api/field + /ws/field Wire the P1 `wifi-densepose-rufield` bridge into the live `wifi-densepose-sensing-server` so the governed sensing cycle emits real signed RuField `FieldEvent`s on two additive endpoints. - Cargo: add the `wifi-densepose-rufield` path dep (the single coupling point, ADR-262 §5.4 — no new RuView-internal coupling). - New `src/rufield_surface.rs` (kept out of the 8k-line main.rs): `FieldSurface` holds a dedicated ed25519 `Signer` + a bounded ring of recent events + the `/ws/field` broadcast topic; `GET /api/field` and `GET /ws/field` handlers; a standalone `router()` for isolated testing. - Signer (defers the P2 key decision, ADR-262 §8 Q1): a STANDALONE dev/sensing key from `WDP_RUFIELD_SIGNING_SEED`, else a deterministic dev default with a logged WARN. Reusing the `cog-ha-matter` Ed25519 key is the deferred P2 call — P3 does not pre-empt it. - Tap: at the ESP32 governed-trust cycle (`main.rs` ~5886 observe_cycle / ~5938 SensingUpdate build), `emit_rufield_event` joins the cycle's features/classification/signal_field with the engine's effective_class/demoted trust state into a `SensingSnapshot` and surfaces it via the bridge. Existing endpoints (`/ws/sensing` etc.) are unchanged — purely additive. - Privacy egress: `network_egress_allowed` is fail-closed for an unattended live surface — only P1/P2 leave the box; P0 raw and P3/P4/P5 (identity/biometric/aggregate) are held edge-local. A `Derived` cycle maps to P4/P5 and never surfaces. - No-phantom: `emit` drops no-presence cycles (no fabricated events). Gates (tests/rufield_surface_test.rs, tower::oneshot, 4/0): well-formed signed event (WifiCsi, P2 not P1, is_fusable, real timestamp); empty cycle → no phantom; Derived trust never surfaces; mixed stream surfaces only egress-safe events. Honesty (ADR-262 §0/§6): real plumbing on a live endpoint, NOT accuracy. Single-link CSI with its existing caveats (no validated room-coordinate accuracy); dedicated dev signing key pending the P2 ownership decision; no accuracy claim. Co-Authored-By: claude-flow <ruv@ruv.net> * docs(ADR-262 P3): mark P1+P3 implemented; document /api/field + /ws/field; CHANGELOG - ADR-262 Status → "P1 + P3 implemented"; add a P3 implementation-status block (tap site, endpoints, dedicated dev signer deferring the §8 Q1 key decision, fail-closed egress, gates). Keep the honesty framing: real plumbing on a live endpoint, not accuracy. - CHANGELOG [Unreleased]: add the ADR-262 P3 entry. - user-guide: add `/api/field` to the REST table + a "RuField surface (ADR-262 P3)" section covering `/api/field` + `/ws/field`, the fail-closed P1/P2-only egress, the WDP_RUFIELD_SIGNING_SEED dev key, and the no-accuracy honesty note. Co-Authored-By: claude-flow <ruv@ruv.net> * ci: checkout submodules everywhere + Dockerfile copies vendor/rufield Making wifi-densepose-rufield (ADR-262 bridge) a v2 workspace member means EVERY cargo-on-workspace context must have the vendor/rufield submodule present (cargo loads all member manifests). P1 only fixed the rust-tests job; this adds `submodules: recursive` to all workflow checkouts that run cargo (mqtt-integration was failing on the missing submodule manifest), and makes Dockerfile.rust COPY vendor/rufield/ to /vendor/rufield (matches the bridge's ../../../vendor/rufield path-dep under the collapsed Docker layout). update-submodules.yml left alone (it manages submodules itself). Co-Authored-By: claude-flow <ruv@ruv.net> --------- Co-authored-by: ruv <ruvnet@gmail.com> |
||
|---|---|---|
| .. | ||
| benches | ||
| examples | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| README.md | ||
README.md
wifi-densepose-sensing-server
Lightweight Axum server for real-time WiFi sensing with RuVector signal processing.
Overview
wifi-densepose-sensing-server is the operational backend for WiFi-DensePose. It receives raw CSI
frames from ESP32 hardware over UDP, runs them through the RuVector-powered signal processing
pipeline, and broadcasts processed sensing updates to browser clients via WebSocket. A built-in
static file server hosts the sensing UI on the same port.
The crate ships both a library (wifi_densepose_sensing_server) exposing the training and inference
modules, and a binary (sensing-server) that starts the full server stack.
Integrates wifi-densepose-wifiscan for multi-BSSID WiFi scanning per ADR-022 Phase 3.
Features
- UDP CSI ingestion -- Receives ESP32 CSI frames on port 5005 and parses them into the internal
CsiFramerepresentation. - Vital sign detection -- Pure-Rust FFT-based breathing rate (0.1--0.5 Hz) and heart rate (0.67--2.0 Hz) estimation from CSI amplitude time series (ADR-021).
- RVF container -- Standalone binary container format for packaging model weights, metadata, and
configuration into a single
.rvffile with 64-byte aligned segments. - RVF pipeline -- Progressive model loading with streaming segment decoding.
- Graph Transformer -- Cross-attention bottleneck between antenna-space CSI features and the
COCO 17-keypoint body graph, followed by GCN message passing (ADR-023 Phase 2). Pure
std, no ML dependencies. - SONA adaptation -- LoRA + EWC++ online adaptation for environment drift without catastrophic forgetting (ADR-023 Phase 5).
- Contrastive CSI embeddings -- Self-supervised SimCLR-style pretraining with InfoNCE loss, projection head, fingerprint indexing, and cross-modal pose alignment (ADR-024).
- Sparse inference -- Activation profiling, sparse matrix-vector multiply, INT8/FP16 quantization, and a full sparse inference engine for edge deployment (ADR-023 Phase 6).
- Dataset pipeline -- Training dataset loading and batching.
- Multi-BSSID scanning -- Windows
netshintegration for BSSID discovery viawifi-densepose-wifiscan(ADR-022). - WebSocket broadcast -- Real-time sensing updates pushed to all connected clients at
ws://localhost:8765/ws/sensing. - Static file serving -- Hosts the sensing UI on port 8080 with CORS headers.
Modules
| Module | Description |
|---|---|
vital_signs |
Breathing and heart rate extraction via FFT spectral analysis |
rvf_container |
RVF binary format builder and reader |
rvf_pipeline |
Progressive model loading from RVF containers |
graph_transformer |
Graph Transformer + GCN for CSI-to-pose estimation |
trainer |
Training loop orchestration |
dataset |
Training data loading and batching |
sona |
LoRA adapters and EWC++ continual learning |
sparse_inference |
Neuron profiling, sparse matmul, INT8/FP16 quantization |
embedding |
Contrastive CSI embedding model and fingerprint index |
Quick Start
# Build the server
cargo build -p wifi-densepose-sensing-server
# Run with default settings (HTTP :8080, UDP :5005, WS :8765)
cargo run -p wifi-densepose-sensing-server
# Run with custom ports
cargo run -p wifi-densepose-sensing-server -- \
--http-port 9000 \
--udp-port 5005 \
--static-dir ./ui
Using as a library
use wifi_densepose_sensing_server::vital_signs::VitalSignDetector;
// Create a detector with 20 Hz sample rate
let mut detector = VitalSignDetector::new(20.0);
// Feed CSI amplitude samples
for amplitude in csi_amplitudes.iter() {
detector.push_sample(*amplitude);
}
// Extract vital signs
if let Some(vitals) = detector.detect() {
println!("Breathing: {:.1} BPM", vitals.breathing_rate_bpm);
println!("Heart rate: {:.0} BPM", vitals.heart_rate_bpm);
}
Architecture
ESP32 ──UDP:5005──> [ CSI Receiver ]
|
[ Signal Pipeline ]
(vital_signs, graph_transformer, sona)
|
[ WebSocket Broadcast ]
|
Browser <──WS:8765── [ Axum Server :8080 ] ──> Static UI files
Related Crates
| Crate | Role |
|---|---|
wifi-densepose-wifiscan |
Multi-BSSID WiFi scanning (ADR-022) |
wifi-densepose-core |
Shared types and traits |
wifi-densepose-signal |
CSI signal processing algorithms |
wifi-densepose-hardware |
ESP32 hardware interfaces |
wifi-densepose-wasm |
Browser WASM bindings for the sensing UI |
wifi-densepose-train |
Full training pipeline with ruvector |
wifi-densepose-mat |
Disaster detection module |
License
MIT OR Apache-2.0