RuView: an open source platform for camera-free spatial sensing with WiFi signals

Sun, 17 May 2026 17:34:08 +0800

RuView is an open source WiFi spatial sensing platform from ruvnet.

Its idea is ambitious: instead of using cameras or wearables, it relies on ordinary WiFi signals and low-cost ESP32-S3 sensing nodes to extract presence, motion, breathing, heart rate, activity patterns, room state, and pose-estimation signals from Channel State Information, or CSI.

Project: https://github.com/ruvnet/RuView

Bottom line

RuView is worth watching, but it needs a cool head.

It is not a regular web app, and it is not a finished monitoring system that can “see through walls” as soon as you start a Docker container. More accurately, it is a research-oriented open source platform around WiFi CSI, ESP32-S3, edge inference, spatial sensing, and multimodal fusion.

It is suitable for:

Learning WiFi CSI sensing and wireless signal processing.
Building ESP32-S3 prototypes for presence detection, activity detection, and vital-sign sensing.
Researching camera-free spatial sensing.
Exploring edge sensing for elder care, healthcare, smart buildings, retail traffic, security, and robot safety.
Testing non-video sensing in privacy-sensitive spaces.

It is not yet suitable for:

Replacing medical devices just by buying a board.
High-precision indoor 3D localization with a single ESP32 node.
Identifying each person accurately in any room without tuning or calibration.
Getting full CSI capability from ordinary RSSI on a laptop.
Direct deployment of a beta project into high-risk production scenarios.

The README also makes the limits clear: RuView is still beta software; APIs and firmware may change; ESP32-C3 and the original ESP32 are not supported; single-ESP32 deployments have limited spatial resolution; and camera-free pose estimation still has obvious accuracy limits.

What RuView is

RuView treats WiFi signals as spatial sensors.

WiFi routers continuously emit radio waves through a room. Human movement, breathing, sitting down, and standing up all cause tiny changes in those signals. Traditional WiFi mainly cares whether the connection works and how strong the signal is. RuView looks at lower-level Channel State Information.

CSI can be understood as fine-grained wireless-link state across subcarriers and time points. Compared with ordinary RSSI, it carries much more information and can help analyze:

Whether a room is occupied.
Roughly where someone is.
Whether someone is walking, sitting, or falling.
Whether breathing frequency looks abnormal.
Whether heart-rate signals can be estimated.
Whether the room’s RF fingerprint has changed.
Whether multiple nodes provide enough spatial relationship for finer localization.

RuView tries to turn raw wireless signals into usable spatial intelligence.

What it can sense

According to the project README, RuView focuses on:

Presence and occupancy: detecting people, occupancy changes, entries, and exits.
Vital signs: contactless breathing-rate and heart-rate estimation.
Activity recognition: walking, sitting, gestures, falls, and similar activities.
Environment mapping: room RF fingerprints, furniture movement, and new-object changes.
Sleep quality: nighttime monitoring, sleep-stage direction, and apnea screening research.
Pose estimation: human keypoint estimation based on WiFi CSI.

The easiest parts to land are presence detection, activity changes, and coarse occupancy judgment. Breathing, heart rate, and pose estimation place much higher demands on hardware placement, environment, signal quality, models, and calibration.

So it is better not to treat every feature as equally mature. Running a research pipeline and operating stably for months in a real home, hospital, hotel, or warehouse are very different engineering problems.

Why ESP32-S3

RuView recommends ESP32-S3 as the low-cost CSI collection node.

The README notes:

ESP32-C3 is not supported.
The original ESP32 is not supported.
The reason is limited single-core compute and insufficient capacity for CSI DSP workloads.
A single ESP32 deployment has limited spatial resolution.
Better results need two or more nodes, or Cognitum Seed.

This matters. “WiFi sensing” can make people assume that any laptop, router, or ESP32 board can do the full job. In practice, full CSI capability depends on hardware, firmware, and how data is collected.

The project describes several hardware paths:

Docker simulated data: no hardware needed, good for evaluating the processing pipeline.
ESP32-S3 nodes: low-cost real-time collection, suitable for prototypes.
ESP32 mesh: multiple nodes improve spatial resolution.
ESP32-S3 + Cognitum Seed: persistent memory, kNN, witness chain, and AI integration.
Research NICs such as Intel 5300 / Atheros AR9580 for fuller CSI research.
Ordinary WiFi laptops: usually limited to RSSI, with very limited sensing ability.

Quick trial

If you only want to see the interface and simulated data, start with Docker:

1
2

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

Then open:

`1`	`http://localhost:3000`

For real ESP32-S3 hardware, you need to flash firmware and configure WiFi:

1
2
3

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

Configure the network and target address:

1
2

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

The project also provides real-time processing scripts, for example:

1
2
3

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

These commands are for developers who can follow the README and validate the pipeline step by step. Users without wireless signal-processing or embedded-development experience will face a real learning curve.

Processing pipeline

The basic RuView pipeline can be understood as:

WiFi signals pass through the room.
Human bodies and objects change the propagation paths.
ESP32-S3 mesh nodes collect CSI.
Multi-band, multi-subcarrier, and multi-node links are fused.
Signals are cleaned and features are extracted.
RuVector / AI Backbone performs representation, compression, retrieval, and modeling.
Neural networks output body keypoints, vital signs, and room models.
Upper-layer applications use the results for alerts, statistics, visualization, or automation.

This involves CSI amplitude and phase, multipath propagation, Fresnel-zone geometry, breathing and heart-rate filtering, Hampel filter, SpotFi, BVP, spectrograms, graph algorithms, attention, spiking neural networks, mesh nodes, and cross-view fusion.

That is why RuView is closer to a research platform than a small IoT utility.

Use cases

The README lists many possible scenarios.

For elder care and healthcare support:

Presence detection in an elder’s room.
Fall detection.
Night activity monitoring.
Breathing-rate observation during sleep.
Auxiliary breathing and heart-rate monitoring for non-critical beds.

These scenarios are attractive because they avoid cameras and do not require people to wear devices. But anything medical must be treated carefully. A research project should not be used as a medical device.

For smart buildings and commercial spaces:

Occupancy of desks and meeting rooms.
HVAC control based on real presence.
Hotel-room vacancy and energy saving.
Restaurant queues and table turnover.
Retail foot traffic, dwell time, and heat maps.

These are closer to occupancy and behavior statistics. They may be easier to deploy first because they require less centimeter-level precision, but they still need privacy controls.

For safety and industrial sites:

Perimeter intrusion detection.
Warehouse safety zones.
Forklift proximity alerts.
Presence in enclosed spaces.
Construction-site fall detection and headcounting.

These need low latency and reliable alerts, but false positives, missed detections, and liability boundaries must be handled.

For robotics and difficult environments:

Human sensing when cameras are limited.
Detecting people behind smoke, fog, occlusions, or shelves.
Searching for breathing signals in disaster rescue.
Underground, mining, ship, or other places where optical sensors struggle.

These are valuable research directions, but the engineering difficulty is higher.

Privacy benefits and new risks

RuView’s important selling point is that it does not need a camera.

In elder care, hospitals, schools, offices, hotels, restaurants, and bathrooms, cameras create obvious privacy pressure. WiFi sensing does not record images and does not require wearables, which reduces many visual privacy issues by design.

But “no camera” does not mean “no privacy risk.”

WiFi sensing can still infer:

Whether someone is in a room.
When people enter and leave.
Sleep, breathing, and activity patterns.
Falls or long periods of stillness.
Behavioral patterns in a space.

These are sensitive data too. Deployments still need clear notice, access control, retention rules, encrypted storage, minimal collection, and audit trails.

Compared with cameras, PIR, and millimeter-wave radar

Cameras provide rich, intuitive, explainable information, but they have the highest privacy pressure and depend on lighting and line of sight.

PIR sensors are cheap and easy to deploy, but they mainly sense heat changes. They can miss stationary people and have limited spatial resolution.

Millimeter-wave radar works well for contactless vital signs and presence detection and can be more stable, but it usually requires extra hardware and costs more than reusing WiFi infrastructure.

WiFi sensing has several advantages:

WiFi infrastructure is already common.
Signals can pass through some walls and occlusions.
It does not collect images.
ESP32-S3 nodes are inexpensive.
It can integrate with existing network environments.

The weaknesses are also clear:

Signals are strongly affected by the environment.
Node placement, node count, and wall materials matter.
Multi-person scenarios are harder.
High-precision pose and vital-sign estimation remain difficult.
Engineering validation is harder than ordinary camera deployments.

Current limits

The README already lists several key limits:

The project is still beta software.
APIs and firmware may change.
ESP32-C3 and the original ESP32 are not supported.
A single ESP32 deployment has limited spatial resolution.
Two or more nodes, or Cognitum Seed, are recommended.
Current camera-free pose-estimation accuracy is limited.
Camera-supervised training pipelines exist, but data collection and evaluation are still in progress.
The Docker example uses simulated data and does not represent real hardware performance.

This type of project is easy to oversell through headlines. WiFi sensing has strong technical potential, but real results depend on hardware, environment, deployment density, models, calibration, and application tolerance.

For prototyping, start with presence detection and simple activity recognition. Do not start by demanding high-precision pose, heart rate, and multi-person 3D tracking.

How to start

A practical learning path is:

Run Docker with simulated data to understand the UI and pipeline.
Read the README and architecture docs.
Prepare ESP32-S3, not ESP32-C3 or the original ESP32.
Start with single-node CSI collection and verify stable data flow.
Add two to four nodes and observe changes in spatial resolution.
Validate basic presence, movement, and breathing first.
Then try pose estimation, edge modules, and multimodal fusion.

For productization, also consider installation location, network security, encryption and retention, alert false-positive rates, user notice and consent, hardware maintenance, behavior during network or power loss, OTA updates, and firmware rollback.

Summary

RuView is an ambitious WiFi CSI spatial sensing project. It combines low-cost ESP32-S3 hardware, wireless signal processing, edge AI, vital-sign estimation, pose recognition, and camera-free spatial monitoring in one platform.

Its most valuable contribution is making the idea that “WiFi can be a spatial sensor, not just a networking tool” into runnable open source engineering. For researchers, hardware developers, smart-building teams, and privacy-sensitive product prototypes, it is worth studying.

But it is still beta. The README’s feature list should not be treated as stable product capability. Single-node results are limited, hardware matters, real environments add noise, and multi-person or high-precision pose estimation remains hard. Treat RuView as a WiFi sensing experimentation platform, start with simulated data and basic presence detection, and validate its usefulness in your actual space step by step.

References:

ESP32 on KnightLi Blog