wifi-densepose: WiFi sensing turned into a pose estimation API

The pipeline starts at the access point, not at a camera

The repository describes itself as a production ready implementation of InvisPose, a WiFi based dense human pose estimation system that enables real time full body tracking through walls using commodity mesh routers, and the README restates the idea as a system that leverages channel state information and machine learning to provide real time, privacy preserving pose detection without cameras. The claim to look at carefully is the commodity mesh routers part, because it sets the whole difficulty budget. A channel state information stream is a fine grained description of how a radio channel looks over time, and it is not a thing most consumer routers will give you without modification. So the first and hardest engineering step is upstream of the model, and the README is organised around that. The architecture diagram in the README shows three WiFi routers as CSI sources feeding a CSI Data Collector described as a hardware interface, which then feeds a Signal Processor, then a Neural Network Model with a DensePose head, then a Person Tracker, and finally three outputs, a REST API for CRUD operations, a WebSocket API for real time streaming, and an analytics engine for fall detection. Everything downstream of the collector is software you can inspect.

Phase sanitisation is the step that makes CSI usable

The core components list in the README names the pieces, and one of them explains the rest. The CSI Processor extracts and processes channel state information from the WiFi signals, and the Phase Sanitizer removes hardware specific phase offsets and noise. That second component is the interesting one, because the phase of a channel state information sample carries a constant offset that depends on the particular radio chain it came from, so a receiver that is swapped for another model of router produces a different phase reading for the same physical situation. Left alone, those offsets are indistinguishable from a person moving, and a model trained on one radio chain collapses on another. Removing the hardware specific offset is what makes the data portable across devices, and it is the part of the pipeline where the project is doing real signal processing rather than calling a neural network. The DensePose Neural Network then converts the processed CSI data into human pose keypoints, and the README is explicit that the output is keypoints, not a body mesh, even though the head is borrowed from DensePose. The privacy framing follows from the sensing modality rather than from policy, because no image is ever formed.

Tracking people, and the analytics built on top

The Person Tracker maintains consistent person identities across frames, and the README lists multi-person tracking of up to ten individuals as a feature. This is the component that turns a stream of keypoints into something an application can use, because a fall detection system or a gym dashboard needs to know that the figure in frame forty is the same person as the figure in frame thirty-nine, and it needs a per-person trajectory rather than a bag of poses. On top of that sits the analytics engine, described as covering advanced analytics including fall detection and activity recognition, and the feature list adds occupancy monitoring to that. The stated application domains are healthcare, fitness, smart home and security, and they are not arbitrary, because each maps to a different combination of the same primitives. Healthcare uses fall detection on a per-person basis, fitness needs activity recognition with identity so that two athletes on a mat do not get merged, smart home wants occupancy counts per room, and security wants a trajectory. The WebSocket API exists so that an application can subscribe to the pose stream as it is produced, rather than polling for it.

The service surface: authentication, rate limiting and the REST API

The feature list calls the API enterprise ready, with authentication, rate limiting and monitoring, and the repository layout backs that up with a large operational surface. There is a tests directory, plus two top level test files with revealing names, test_application.py and test_auth_rate_limit.py, so the authentication and rate limiting paths are tested separately from the application itself. The infrastructure is not a demo either, with a docker-compose.yml and a docker-compose.prod.yml, a Dockerfile, a deploy.sh, and directories for kubernetes manifests, terraform, ansible playbooks, monitoring and logging. The development dependencies are equally serious, with prometheus-client for metrics, python-jose for tokens, passlib with bcrypt for password hashing and python-multipart for form handling. The project also ships infrastructure as code, since the documentation table of contents has a section for it, alongside monitoring and logging, load testing and performance optimisation sections. The README claims a hundred percent test coverage badge, and a coverage badge in the readme header, though that badge links to a different repository namespace, which is worth noticing if you are deciding how much the coverage claim applies to this copy.

Installing from PyPI, and what the extras actually pull in

The README marks the pip route as recommended, and the package is published under the name wifi-densepose on PyPI.

# Install the latest stable version
pip install wifi-densepose

# Install with specific version
pip install wifi-densepose==1.0.0

# Install with optional dependencies
pip install wifi-densepose[gpu]  # For GPU acceleration
pip install wifi-densepose[dev]  # For development
pip install wifi-densepose[all]  # All optional dependencies

The packaging metadata gives the version as 1.2.0, and the extras map onto the heavier parts of the stack, with gpu for acceleration and dev for the test and lint tooling. The base dependency list is where the cost is, and it is not a light one. The web layer is FastAPI with uvicorn and pydantic with pydantic-settings, the storage layer is SQLAlchemy with Alembic for migrations and asyncpg plus psycopg2-binary for PostgreSQL, with Redis and aioredis marked optional in the packaging, and the machine learning layer is torch and torchvision with numpy, opencv-python, pillow and scikit-learn. A separate requirements.txt exists for the hardware interface, with asyncio-mqtt, aiohttp and paramiko, and the signal processing stack of numpy, scipy, torch and torchvision. The setup.py file is explicitly kept for backward compatibility, with the note that the main configuration is in pyproject.toml, and the version string is read out of the package init file. That is a sensible arrangement, since the requirements file and the packaging metadata have drifted apart in their pins, which is a situation worth keeping in mind when pins disagree between the two files.

Docker Compose, PostgreSQL, Redis and the environment switches

The development compose file is worth reading as a configuration reference, because it names every switch the service understands and shows the dependencies the system expects. The application service builds from the Dockerfile with a development target, publishes port 8000, mounts the source tree and three named volumes for logs, data and models, and depends on both postgres and redis.

    environment:
      - ENVIRONMENT=development
      - DEBUG=true
      - LOG_LEVEL=debug
      - RELOAD=true
      - ENABLE_TEST_ENDPOINTS=true
      - ENABLE_AUTHENTICATION=false
      - ENABLE_RATE_LIMITING=false
      - DATABASE_URL=postgresql://wifi_user:wifi_pass@postgres:5432/wifi_densepose
      - REDIS_URL=redis://redis:6379/0

The database service is postgres 15 alpine with a health check using pg_isready, and the cache is redis 7 alpine started with appendonly enabled and a password required. The health check on the application service hits the health endpoint with curl. Two things follow for a real deployment. The first is that the development profile disables authentication and rate limiting explicitly, so a production compose file has to turn them back on, and the existence of docker-compose.prod.yml is a promise rather than a recipe, so you should read it before trusting it. The second is that the data model lives in PostgreSQL with Alembic migrations, while the compose file also exposes aiosqlite in the requirements, so a single node trial run does not need the database container. The health check also implies a health endpoint on the service, which is the piece a load balancer or a Kubernetes probe would use.

What the repository does not contain, and what to check first

The honest gaps are worth naming, because the README is written in the register of a finished system. The repository has no GitHub releases, so there is no tagged version to install, and the last push was on 2026-09-06. The licence story is muddled. The readme carries an MIT badge, the packaging metadata declares the license as MIT, and yet GitHub classifies the repository licence as a custom one it cannot categorise, with the terms in a LICENSE file, so read that file rather than trusting the badge. The model weights are the other question. The pipeline ends in a DensePose head that converts CSI into keypoints, and a data directory and a models volume exist in the compose setup, which implies the weights are an input you supply or download rather than something the package carries, and the README does not document where to get them. The documentation table of contents does list sections for hardware setup, supported hardware, physical setup, network configuration and environment calibration, and those are the sections to read before you believe the word commodity. Finally, the performance numbers in the feature list, the sub 50 millisecond latency and 30 frames per second, are the project's own claims about its own system, and the benchmark section exists precisely so that you can check them, so treat them as a starting point for your own measurement rather than a specification.

Editorial conclusion

Adopt wifi-densepose if you are building a sensing application where a camera is unacceptable, such as a care home or a gym, and you already have routers that can expose channel state information. It does not fit a project that needs accurate body geometry from commodity hardware, because the accuracy depends on the CSI extraction path you can get from your access points and on the weights the project expects, and it does not fit anyone who cannot supply those. Before you build on it, confirm that your hardware can deliver CSI data at a usable rate, read the licensing terms in the LICENSE file since GitHub cannot classify it even though the packaging metadata says MIT, and check the hardware setup and environment calibration sections of the documentation rather than assuming the routers will just work.

Frequently asked questions

Official sources

1. davidakpele/wifi-densepose on GitHub
2. Issues
3. README