Mapa de Calor de Flujo de Personas en Retail: Construcción, Despliegue y Resultados Medidos

Aviso de uso

El mapa de calor solo registra dónde están las personas. No identifica a nadie ni realiza emparejamiento de rostros. La precisión de la detección no se ha evaluado; consulta Rendimiento y datos medidos.

Qué hace esta solución

Una cámara mira hacia el suelo, localiza a cada persona en el encuadre y las sigue, luego escribe dónde se detienen las personas, cuánto tiempo se quedan y cuántas entran y salen en una base de datos local, que se muestra en un panel de Grafana y en un mapa de calor. Diseñado para tiendas minoristas, pilotos de cadenas de tiendas, salas de exposiciones y cualquier espacio interior donde las decisiones de distribución dependan de por dónde camina la gente.

Los sitios que ya tienen cámaras IP las conservan y añaden un host de IA que realiza la detección. Los sitios sin cámaras usan una reCamera, donde la detección se ejecuta dentro de la cámara. El vídeo se procesa en el lugar y el backend solo almacena números. En un flujo RTSP en vivo, reComputer R2000 Serie (Hailo-8) midió 14,3 FPS (fuente de 15 FPS), y reComputer RK3588 / RK3576 Serie midió 13,2 / 13,3 FPS.

• Implementación de código abierto (ruta reCamera): github.com/xr686/reCamera-with-Heatmap
• Implementación de código abierto (ruta cámara IP + Jetson): github.com/bleaaach/yolo11-grafana-influxdb
• Elegir una configuración y desplegar: página de diseño de referencia

• Procesado en el sitio, el backend almacena números

  La detección se ejecuta en la cámara o en el host de IA. Lo que llega al backend son posiciones en porcentajes, conteos y tiempos de permanencia. La vista previa en vivo pasa por la pasarela de vídeo local y permanece en tu red.

• Usa las cámaras que ya tienes

  Cualquier cámara IP con un flujo RTSP funciona, sea cual sea la marca; nada en la pared necesita ser reemplazado. Sin cámaras, una reCamera con la app de analítica para retail instalada empieza a producir datos.

• Cinco rutas de hardware, un panel

  reCamera 2002, reCamera Pro, Rockchip, Hailo-8 y Jetson publican todos el mismo formato de mensaje. Varias tiendas pueden mezclar hardware y aun así informar a un solo backend.

• No se necesita internet una vez desplegado

  El broker, la base de datos y el panel se ejecutan todos en el backend local. Internet solo se usa durante el despliegue para descargar imágenes y modelos.

Qué generan realmente los dispositivos

Los resultados de cada detector llegan a un único panel de Grafana: la transmisión en vivo de la cámara a la izquierda y paneles que agregan ocupación, estados de permanencia y conteos de entrada/salida a lo largo del tiempo.

Los mismos datos de posición también dibujan un mapa de calor. Las zonas más oscuras son donde la gente se quedó más tiempo o pasó con más frecuencia. De forma predeterminada se superpone a la vista de la cámara; tras la calibración puede superponerse al plano de tu tienda.

Qué hardware necesitas

Tres cosas: una cámara que vea el suelo, algo que detecte personas y un backend que almacene los datos y los represente. El backend es compartido por todas las rutas.

① Cámara: si ya tienes cámaras IP con un flujo RTSP, consérvalas; cualquier marca funciona y nada en la pared cambia. Si no tienes ninguna, reCamera 2002 / reCamera Pro combinan cámara y cómputo en una sola unidad, ejecutando detección, seguimiento, estados de permanencia y conteo de entradas/salidas dentro de la cámara.

② Host de detección: solo es necesario en las rutas con cámara IP. Cada host ejecuta la misma lógica de seguimiento y permanencia; la diferencia es el acelerador.

③ Backend del panel: ejecuta el broker MQTT, InfluxDB, Grafana y la pasarela de vídeo. Puede ser un ordenador siempre encendido o un reComputer R1100; en las rutas con cámara IP puede compartir la caja con el detector.

	Dispositivo	Qué hace	Cuándo elegirlo
	reCamera 2002 cámara y cómputo en uno, 1080P	Detección + seguimiento + conteo	Cerca de la zona contada, cobertura pequeña, la forma más rápida de poner un flujo en marcha
	reCamera Pro cámara y cómputo en uno, 4K	Detección + seguimiento + conteo	Más lejos, gran cobertura, donde las personas distantes aún necesitan suficientes píxeles para encuadrarlas
	reComputer RK3588 Serie el mismo preset también es compatible con reComputer RK3576 Serie	Host de detección	Ya utilizas placas Rockchip; la decodificación de vídeo se ejecuta por hardware
	reComputer R2000 Serie (R2035-12, Hailo-8)	Host de detección	Una caja industrial sin ventilador para un armario o cuarto de instalaciones
	reComputer J40 Serie (J4012) y reComputer J50 Serie	Host de detección	Varias cámaras en un solo host
	reComputer R1100 Serie (R1124-10)	Backend del panel	No hay un ordenador siempre encendido en el sitio para ejecutar el panel

Otros requisitos previos: Docker en la máquina backend, al menos 2 GB de disco libre, los puertos 1883, 3000, 8080 y 8086 libres, y cámaras y backend en el mismo segmento de red para que funcione el descubrimiento de cámaras ONVIF.

Distribución de dispositivos: las cámaras IP entregan vídeo RTSP al host de IA, mientras que una reCamera ejecuta la detección dentro de la cámara; los detectores solo generan porcentajes de posición y conteos, sin imágenes; cada detector informa a un backend (broker MQTT, InfluxDB, Grafana, pasarela de vídeo go2rtc), de modo que un solo panel cubre todas las cámaras. La vista previa en vivo es el navegador tirando de la cámara a través de la pasarela de vídeo local, no a través de la base de datos del backend.

Límites de selección negativa

• Altura de montaje y campo de visión: reCamera 2002 es adecuada para techos de 3–4 m; para alturas superiores a 5 m o grandes atrios, no elijas 2002, elige reCamera Pro con resolución 4K.
• Seguimiento de identidad: Esta solución genera únicamente mapas de calor de densidad anónimos, no reconocimiento facial ni reidentificación de personas.

Instalación in situ

Dos partes: montar la cámara correctamente e instalar el software.

1. Montaje de la cámara

Requisitos de colocación

Monta la cámara en alto, mirando hacia abajo al área que se va a contar, a 3–5 m del objetivo. Las personas deben ocupar al menos unos 30 × 30 píxeles en el encuadre; de lo contrario, no se pueden encuadrar. Vistas a la altura de los ojos, ángulos con mucha oclusión mutua y tomas lejanas donde las personas son demasiado pequeñas provocan detecciones perdidas.

2. Instalación del software: de tres a cuatro pasos

Las instrucciones por dispositivo se encuentran en la página del diseño de referencia, donde respondes algunas preguntas sobre el sitio y descargas el paquete de aplicación correspondiente.

Configura y descarga el paquete de la aplicación 🖱️

1. Levanta el backend: inicia el broker, InfluxDB, Grafana y el video gateway en la máquina siempre encendida. Este paso descubre cámaras ONVIF en el mismo segmento; para cámaras en otro segmento, introduce las URL RTSP en el formulario de despliegue.
2. Haz que el detector publique: en las rutas reCamera, instala la app de analítica retail en la cámara; en las rutas de cámara IP, despliega el detector en el host de IA. Ambos piden tres cosas: la dirección del broker MQTT (la máquina del paso 1), un nombre de instalación y un ID de cámara. Usa un nombre de instalación por tienda y un ID por cámara; así es como el panel diferencia los dispositivos.
3. Calibra el plano de planta (opcional): abre el mapa de calor en el puerto 8080, sube una captura de la cámara y el plano de la tienda, y haz clic en cuatro puntos coincidentes en cada uno. Elige puntos de referencia muy separados, como pilares, puertas y esquinas de paredes. La calibración se guarda en el servidor y varias cámaras pueden compartir un mismo plano. Omite esto si la vista de la cámara es todo lo que necesitas.
4. Abre el panel: Grafana en el puerto 3000, el mapa de calor en vivo en 8080, el video gateway en 1984.

La documentación upstream indica 15 minutos de extremo a extremo. La ruta Jetson es la excepción: el primer despliegue construye un motor TensorRT en el dispositivo, lo que lleva de 2 a 5 minutos y luego se reutiliza.

Interfaces que expone

Cada detector publica el mismo formato de mensaje en el broker backend. Tres formas de entrada, según lo que ya tengas en marcha:

• El panel integrado es suficiente: no hay nada que integrar. Los paneles de Grafana ya cubren las tendencias de flujo de personas por hora, día y semana, además del tiempo de permanencia y los conteos de entrada/salida, y los datos de los paneles se pueden exportar directamente.
• Un sistema BI o de analítica existente: suscríbete al topic de resultados MQTT para datos en vivo, o consulta InfluxDB en el backend para el histórico.
• Tu propio sistema o API: suscríbete como arriba; la carga útil incluye conteos por zona más la posición y el tiempo de permanencia de cada persona seguida, suficiente para dibujar tus propios paneles. Los fotogramas en vivo provienen del video gateway local en el puerto 1984.

Referencia completa de topics y payload

Topic / puerto	Contenido	Retenido
<site>/retail-vision/results/<camera-id>	Un JSON por segundo en lote: conteos por zona (ocupación, curioseando, implicado, necesita ayuda, entradas, salidas, tiempo medio de permanencia) más el track_id, la posición y el tiempo de permanencia de cada persona seguida	No
<site>/retail-vision/status	online / offline	Sí
Broker MQTT 1883	Resultados de cada detector	—
Grafana 3000	Tendencias de flujo de personas por hora, día y semana; tiempo de permanencia y conteos de entrada/salida	—
Mapa de calor en vivo 8080	Superposición de calor sobre la vista de la cámara o sobre tu plano de planta; el icono de engranaje abre la calibración	—
Video gateway 1984	Descubrimiento de cámaras y vista previa en vivo	—

<site> y <camera-id> se configuran en el formulario de despliegue y solo aceptan letras, dígitos, guiones y guiones bajos.

Las posiciones se publican como porcentajes del encuadre. Cada detector convierte el centro del recuadro seguido en un porcentaje antes de publicar, de modo que una sola calibración del plano de planta sirve para cualquier resolución de cámara; sustituir una cámara por otra de mayor resolución no requiere recalibrar.

Los mensajes se agrupan una vez por segundo. En reCamera esto es --mqtt-interval-ms 1000; sin ello, la app publica por fotograma (unos 10 mensajes por segundo por cámara). En las rutas con host de IA es publish_hz: 1.0 en la configuración del detector. Con varias cámaras en un mismo sitio, que el broker mantenga el ritmo depende de este parámetro.

reCamera Pro no emite el tiempo medio de permanencia, por lo que el panel Avg Dwell permanece vacío en esa ruta. El resto de métricas no se ve afectado.

Rendimiento y datos medidos

Las cuatro rutas con host de IA ejecutan la misma lógica de seguimiento y permanencia; el modelo de detección y el runtime difieren según el acelerador.

reCamera-with-Heatmap

Lo que sigue son datos medidos de dispositivos sobre rendimiento y tasa de mensajes, a partir de fuentes en vivo de una sola secuencia en las rutas RK y Hailo.

Qué dispositivos se midieron

Dispositivo	Acelerador	Modelo entregado	Estado de verificación
reComputer RK3588 series	NPU RK3588	YOLO11n rawhead FP16	✅ Flujo en vivo en hardware
reComputer RK3576 series	NPU RK3576	YOLO11n rawhead FP16	✅ Flujo en vivo en hardware
reComputer R2000 series (R2135-12, Hailo-8)	Hailo-8	YOLOv8n INT8	✅ Flujo en vivo en hardware
reCamera 2002	NPU SG2002	YOLO11n INT8	Despliegue verificado

Detalle de rendimiento

Frecuencia de fotogramas de extremo a extremo en un flujo en vivo

La entrada es metraje RTSP real. La medición cubre toda la ruta desde el fotograma de la cámara hasta la llegada de los resultados al backend: decodificación + detección + seguimiento + lógica de permanencia + publicación MQTT, una secuencia por host.

Host de detección	Modelo	Frecuencia de seguimiento	Frecuencia de mensajes MQTT	Fuente
reComputer R2000 series (R2135-12, Hailo-8)	YOLOv8n INT8	14.3 FPS	0.94 msg/s	Medido (440 fotogramas / 30.7 s)
reComputer RK3588 series	YOLO11n FP16	13.2 FPS	1.00 msg/s	Medido
reComputer RK3576 series	YOLO11n FP16	13.3 FPS	1.00 msg/s	Medido

• Las dos placas RK: la decodificación hardware MPP estaba activa y la frecuencia de mensajes era 1.00 msg/s.
• Los 14.3 FPS de Hailo están limitados por la frecuencia de fotogramas de la fuente. Sin limitación, la misma canalización alcanzó 234 FPS, aproximadamente 15× los 15 FPS de la fuente.
• La diferencia entre 0.94 y 1.00 msg/s proviene de cómo se promedió: ambas apuntan a un mensaje por segundo, y 0.94 es la media en una ventana de 30.7 s.
• Reproducción: los benchmarks de inferencia de extremo a extremo y autónoma se encuentran en el repositorio benchmarks/run_heatmap_bench.sh; ejecuta ./run_heatmap_bench.sh --profile rk3588.

Velocidad de inferencia autónoma

Host de detección	Modelo	Por inferencia	Fuente
reComputer J40 / J50 series	YOLO11n FP16 (TensorRT)	9.7 ms	Cifra de inferencia autónoma proporcionada upstream
reCamera 2002	YOLO11n INT8	alrededor de 10 FPS	Frecuencia en cámara indicada en las notas de la app upstream

Estas dos filas no se comparan directamente con la tabla de extremo a extremo anterior: 9.7 ms excluye decodificación, seguimiento y publicación, y alrededor de 10 FPS es la frecuencia de procesamiento en cámara, no la frecuencia a la que los resultados llegan al backend.

Multisecuencia

Cada cifra anterior proviene de un host viendo una cámara. "Varias cámaras en un host" es la división del trabajo entre presets (la ruta Jetson cumple ese papel). Un backend puede aceptar cualquier número de detectores a nivel de protocolo, separados por nombre de instalación e ID de cámara; el límite está en el lado del host de IA.

Tiempos de ejecución y parámetros clave

Host de detección	Modelo de detección	Precisión	Runtime	Cómo se entrega el modelo
reCamera 2002	YOLO11n (yolo11n_detection_cv181x_int8.cvimodel)	INT8	NPU de la cámara SG2002	Incluido con retail-vision_1.5.1_riscv64.deb, verificado por sha256
reCamera Pro	Incluido con la app retail-vision del App Center	Definida por la app	NPU de la cámara	No incluido en el paquete; instálalo primero desde el App Center del dispositivo
reComputer RK3576 / RK3588 series	yolo11n_pose_rawhead_fp16.<board>.rknn	FP16	RKNN	Entregado por placa y verificado por sha256; el modelo de placa incorrecto no se cargará
reComputer R2000 series (R2135-12, Hailo-8)	YOLOv8n (yolov8n.hef)	INT8	HailoRT 4.21 + GStreamer	Obtenido del directorio hailo8 del Hailo Model Zoo v2.15.0, fijado por sha256
reComputer J40 / J50 series	YOLO11n (yolo11n.engine)	FP16	TensorRT	El motor se construye en el dispositivo (ultralytics export, half=True, imgsz=640): de 2 a 5 minutos la primera vez, reutilizado después

• Hailo está bloqueado a HailoRT 4.21. El despliegue comprueba las bibliotecas en la placa y se detiene, imprimiendo la versión instalada, si no coinciden. Un Hailo-8 ejecuta una aplicación a la vez; si otra app de Hailo está usando el acelerador, el detector no se iniciará.
• Las placas RK necesitan que el controlador NPU esté presente (/usr/lib/librknnrt.so).
• En reCamera la aplicación de analítica toma la cámara en exclusiva: al instalarla desactiva el inicio automático de Node-RED, y ambas no pueden ejecutarse a la vez.

Parámetros que cambian el comportamiento del despliegue (valores enviados en las rutas RK y Jetson):

• dwell_min_duration (1.5 s): una persona cuenta como en permanencia solo después de moverse más despacio que dwell_speed_threshold (10.0) durante este tiempo, por lo que darse la vuelta frente a un estante no cuenta.
• dwell_assistance_threshold (20.0 s): el tiempo de permanencia más allá de este valor entra en el estado de necesita asistencia.
• avg_person_height_m (1.7): convierte el umbral de velocidad de píxeles a distancia real. Cuando la altura media de las personas en cámara difiere sustancialmente de 1.7 m, la detección de permanencia se vuelve más laxa o más estricta en general.

Degradación conocida

• Colocación. La cámara debe montarse en alto, a 3–5 m del objetivo, con personas de al menos unos 30 × 30 píxeles en el encuadre. Las vistas a la altura de los ojos, las tomas lejanas y la oclusión intensa impiden que las personas sean encuadradas, y una persona que no se detecta deja el mapa de calor en blanco sin que se genere ningún error.
• La calibración del plano de planta son cuatro puntos clicados manualmente. Los puntos de referencia que están muy juntos o son colineales amplifican el error de posición. Mover o reorientar la cámara invalida la calibración y hay que rehacerla: una calibración incorrecta no genera ningún error, simplemente dibuja el calor en otro lugar.
• El Avg Dwell de reCamera Pro siempre está vacío, porque la aplicación no emite ese campo.
• En RK, la decodificación por hardware vuelve a la decodificación por software cuando no está activa. Una tasa de fotogramas claramente baja junto con una CPU saturada es el síntoma; la ruta Jetson no tiene retroceso (fallback: none).

Fuentes y licencias

• Modelos de detección: la ruta Hailo usa yolov8n.hef del Hailo Model Zoo directorio hailo8 de la versión v2.15.0, fijado por digest en lugar de volver a alojarlo. La ruta RK reutiliza yolo11n_pose_rawhead_fp16.<board>.rknn ya publicado por fall_detection. La ruta Jetson exporta yolo11n.engine en el dispositivo con ultralytics.
• Licenciamiento de modelos: los detectores usan modelos de la familia YOLO (YOLO11n, YOLOv8n). Los modelos Ultralytics YOLO son AGPL-3.0 a menos que se licencien comercialmente, así que confirma las licencias de los modelos, o sustituye un modelo con licencia compatible, antes de enviar un producto.
• Componentes de backend: el broker MQTT, InfluxDB, Grafana y la pasarela de vídeo go2rtc se despliegan desde sus imágenes oficiales. Las credenciales predeterminadas de Grafana son admin / admin; cámbialas justo después de la puesta en marcha.
• Imágenes: el panel de Grafana y las capturas de pantalla del mapa de calor provienen de la biblioteca de recursos de la solución upstream; el diagrama de arquitectura está dibujado internamente. Ninguna persona identificable aparece en las imágenes de demostración.