WiFi DensePose: «Ve» a través de las paredes usando solo el router de casa


Imagina poder saber exactamente dónde está una persona, qué postura tiene, si respira o si se ha caído, sin usar ni una sola cámara. Esto ya es una realidad gracias a WiFi DensePose: la capacidad de «ver» a través de las paredes utilizando únicamente las ondas de radio de los routers WiFi convencionales.

Este proyecto de código abierto (bajo licencia MIT) combina inteligencia artificial, procesamiento de señales y hardware asequible para crear un sistema de monitorización que respeta la privacidad como ninguna cámara podría hacerlo. Basado en el innovador sistema InvisPose, convierte los routers WiFi en potentes sensores de presencia y movimiento, reconstruyendo poses 2D y 3D en tiempo real, incluso a través de obstáculos.

¿Cómo funciona? La magia de la CSI

En esencia, WiFi DensePose utiliza la Información del Estado del Canal (CSI) de tu red WiFi. Cuando una persona se mueve, altera sutilmente la amplitud y fase de las señales de radio. El sistema captura, procesa e interpreta estas alteraciones para:

  • Reconstruir la postura corporal: Genera puntos clave de articulaciones o un mapa denso de la superficie del cuerpo (DensePose).
  • Monitorear signos vitales: Detecta la frecuencia respiratoria y el ritmo cardíaco sin ningún contacto.
  • Funcionar a través de paredes: Las señales WiFi penetran la mayoría de los materiales de construcción.
  • Ofrecer datos en tiempo real: Provee la información a través de una API REST y WebSockets para integrarla con otras aplicaciones.

Principales Características Técnicas

  • Visión por radiofrecuencia: Utiliza redes neuronales para lograr resultados comparables a los sistemas ópticos, pero sin capturar imágenes.
  • Seguimiento multi-persona: Identifica y sigue a múltiples individuos, manteniendo su identidad incluso cuando se cruzan.
  • Hardware estándar y asequible: Funciona con chips WiFi convencionales como el ESP32-S3 (~$8) y routers comerciales. Nada de equipos militares.
  • API completa para integración: Incluye endpoints REST y streaming WebSocket para conectar con cualquier plataforma SaaS, smart home o app de fitness.
  • Despliegue flexible: Compatible con Docker, Kubernetes y Ansible, con documentación exhaustiva para llevarlo a producción.

¿Qué necesitas para probarlo?

El proyecto está pensado para ser «production-ready» y se despliega fácilmente con Docker:

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

Opciones de hardware:

  • Opción Profesional (CSI completa): Necesitas hardware que exponga la CSI. La opción más recomendada y económica es usar una malla de 3 a 6 placas ESP32-S3. También funcionan tarjetas de investigación como la Intel 5300.
  • Opción Básica (Solo presencia): Si solo tienes un portátil con WiFi estándar, el sistema puede funcionar con datos RSSI, limitado a detección de presencia y movimientos gruesos.

La configuración física típica recomienda colocar los routers/ESP32 a 2-3 metros de altura, separados entre 5 y 10 metros.

Casos de Uso Reales

Las aplicaciones son enormes y abarcan múltiples campos:

  • Salud y Teleasistencia: Monitorización no intrusiva de ancianos, detección de caídas y análisis de patrones de sueño, garantizando la privacidad total al no usar cámaras.
  • Hogar Inteligente (Smart Home): Control de presencia para automatizar luces, detección de gestos para comandos y monitorización de la calidad del sueño.
  • Realidad Virtual/Aumentada (VR/AR): Seguimiento corporal para experiencias inmersivas sin necesidad de sensores en el cuerpo.
  • Respuesta a Desastres (WiFi-Mat): El proyecto incluye un módulo específico para equipos de búsqueda y rescate que puede detectar supervivientes atrapados bajo escombros.

Conectando con tu Aplicación desde Python

Acceder a los datos es muy sencillo, ya sea vía REST o WebSocket.

Ejemplo básico con REST (python):

import requests

response = requests.get("http://localhost:3000/api/v1/sensing")
data = response.json()
print(f"Personas detectadas: {len(data.get('persons', []))}")

Ejemplo de Streaming WebSocket en Tiempo Real (python):

import asyncio
import websockets
import json

async def escuchar_poses():
    uri = "ws://localhost:3001/ws/sensing"
    async with websockets.connect(uri) as websocket:
        while True:
            mensaje = await websocket.recv()
            data = json.loads(mensaje)
            print(f"Poses en vivo: {len(data.get('persons', []))}")

asyncio.run(escuchar_poses())

Privacidad: La Ventaja Estratégica

En un mundo donde cada vez más personas desconfían de las cámaras, WiFi DensePose ofrece una alternativa ética y técnicamente superior:

  • No graba imágenes: No hay rostros, ropa ni identificación visual. Solo datos de pose y presencia.
  • Permite despliegues donde las cámaras son inviables: Hospitales psiquiátricos, baños, vestuarios, habitaciones de ancianos.
  • Cumple normativas de privacidad: Al no tratar datos biométricos visuales, el marco regulatorio (GDPR, CCPA) es mucho más sencillo de navegar.

En Resumen

WiFi DensePose no es solo una librería interesante; es una plataforma tecnológica que cambia las reglas del juego en monitorización humana. Representa una oportunidad única para startups que buscan diferenciarse con soluciones técnicamente sólidas y éticamente responsables.

El futuro de la monitorización no se ve, se siente. Y se siente a través del WiFi que ya nos rodea. ¿Te animas a probarlo?

Enlaces de interés:

Documentación oficial

Repositorio en GitHub

El dilema del bus de colector abierto: Por qué unos diodos necesarios pueden bloquear tu Modbus


Si estás leyendo esto, es probable que hayas montado un bus con varios dispositivos, como los populares medidores PZEM, y te hayas encontrado con un comportamiento extraño: todo funciona a medias. Lees datos sin problema, pero en el momento de intentar algo más complejo, como cambiar la dirección de un dispositivo (con el comando setAddress), todo falla.

Lo más frustrante es que, a menudo, el culpable no es un componente defectuoso, sino un pequeño detalle de diseño que, aunque necesario, introduce un efecto secundario inesperado. Este es el caso de los diodos en un bus de colector abierto con múltiples dispositivos.Analicemos por qué ocurre esto y cómo diagnosticar el problema.

pzem004 1712339109

La Necesidad de los Diodos: Protegiendo el Bus

En un bus donde varios dispositivos comparten la misma línea de comunicación y usan salidas de colector abierto (o drenaje abierto), los diodos son esenciales. Su función es evitar que un dispositivo que está en reposo (con su salida en alta impedancia) bloquee la línea de pull-up cuando otro dispositivo intenta comunicarse.

La orientación correcta, y la que seguramente tienes, es con el cátodo hacia el pin TX del PZEM y el ánodo conectado al bus común. Esta es la configuración estándar para que un bus de colector abierto funcione correctamente. Sin estos diodos, el bus quedaría permanentemente bloqueado.

Por lo tanto, el problema no es la presencia de los diodos en sí, sino un efecto secundario de los mismos que interfiere con la comunicación bidireccional completa que exige el protocolo.

El Diagnóstico: Por qué la Lectura es Posible y la Escritura No

Para entenderlo, veamos qué sucede en los dos escenarios típicos con un bus que tiene esta topología.

1. Lectura por Broadcast (Funciona sin problemas)

Imagina que tu ESP32 envía una solicitud de lectura a todos los dispositivos (broadcast).

  1. La orden sale: La señal de tu ESP32 viaja directamente por la línea TX hacia los pines RX de todos los PZEM. No hay ningún obstáculo.
  2. La respuesta llega (a medias): El PZEM que tiene la dirección solicitada procesa el comando y debe responder por su línea TX.
    • Para enviar un ‘0’ lógico (nivel bajo), el pin TX del PZEM se conecta a tierra. El diodo conduce y la señal llega limpiamente al bus y al ESP32. Perfecto.
    • Para enviar un ‘1’ lógico (nivel alto), el pin TX del PZEM se pone en alta impedancia (desconectado). Aquí es donde el diodo de ese PZEM se polariza inversamente, actuando como un interruptor abierto y bloqueando la señal.

En este modo de broadcast, el ESP32 no espera una respuesta directa de un único dispositivo. El sistema puede funcionar porque el flanco de bajada (‘0’) es lo suficientemente claro para que el maestro interprete la comunicación, aunque la señal esté degradada. Por eso no se detecta un fallo inmediato.

2. Escritura con Confirmación (setAddress) (Falla estrepitosamente)

Aquí es donde se revela el verdadero problema. El comando setAddress no es una simple orden que se envía y se olvida. El protocolo Modbus-RTU, que utilizan los PZEM, exige una confirmación.

  1. El ESP32 ordena: Envía el comando para cambiar la dirección al PZEM M3.
  2. El PZEM M3 confirma: Para que el comando sea exitoso, el PZEM M3 debe enviar una trama de confirmación (ACK) de vuelta al ESP32.
    • El ‘0’ sí pasa: Para enviar un ‘0’ lógico, el TX del M3 se pone a tierra, el diodo conduce y la señal llega al ESP32. Perfecto.
    • El ‘1’ es bloqueado (¡problema!): Para enviar un ‘1’ lógico, el TX del M3 se pone en alta impedancia. En ese instante, el diodo del M3 se polariza inversamente y bloquea completamente la señal. La línea de datos se queda «flotando», sin que el pull-up pueda subirla a nivel alto.

El resultado es que el ESP32 nunca recibe los bits en ‘1’ que forman parte de la trama de confirmación. La comunicación se corrompe, el checksum no coincide y el comando setAddress falla.

En Resumen

El diodo actúa como una válvula unidireccional desde la perspectiva del PZEM hacia el bus. Permite que el PZEM tire de la línea a tierra (para enviar un ‘0’), pero le impide soltarla para que la resistencia de pull-up la lleve a estado alto (para enviar un ‘1’). Este comportamiento, que es inherente a la forma en que están colocados los diodos, es letal para un protocolo bidireccional y basado en flancos como Modbus.

Ahora que sabes que los diodos son la causa del bloqueo, el siguiente paso es buscar una solución. ¿La más común? Implementar un puente removible de modo que cuando vayamos a programar la dirección de un modulo PZEM podemos cortocircuitar el diodo de modo que una vez programado podamos liberar ese cortocircuito en su operación normal. Algo mucho mas avanzado es montar un circuito que convierta las señales unidireccionales en verdaderamente bidireccionales, como un adaptador de nivel lógico o un circuito discreto con transistores. Pero esa, como suele decirse, es una historia para otro post.