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, 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 hace 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 sitio y el backend solo almacena números. En un flujo RTSP en vivo, la serie reComputer R2000 (Hailo-8) midió 14,3 FPS (fuente de 15 FPS), y las series reComputer RK3588 / RK3576 midieron 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 el mismo formato de mensaje. Varias tiendas pueden mezclar hardware y seguir informando 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 señal de cámara en vivo 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ó más a menudo. 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 ponen la cámara y el 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 se necesita 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 encuadrarse
	serie reComputer RK3588 el mismo preset también es compatible con la serie reComputer RK3576	Host de detección	Ya utilizas placas Rockchip; la decodificación de vídeo se ejecuta en hardware
	serie reComputer R2000 (R2035-12, Hailo-8)	Host de detección	Una caja industrial sin ventilador para un armario o cuarto de instalaciones
	reComputer Super J4012 y serie reComputer J50	Host de detección	Varias cámaras en un solo host
	serie reComputer R1100 (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 el descubrimiento de cámaras ONVIF funcione.

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 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 solo 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 deberían 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 — 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 la pasarela de vídeo 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 con reCamera, instala la app de analítica retail en la cámara; en las rutas con 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 bien 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, la pasarela de vídeo 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 se reutiliza después.

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 historial.
• 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 de la pasarela de vídeo local en el puerto 1984.

Referencia completa de topics y cargas útiles

Topic / puerto	Contenido	Retenido
<site>/retail-vision/results/<camera-id>	Un JSON por segundo en lote: conteos por zona (ocupación, explorando, comprometido, 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	—
Pasarela de vídeo 1984	Descubrimiento de cámaras y vista previa en vivo	—

<site> y <camera-id> se establecen 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. Otras métricas no se ven afectadas.

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 transmisión en las rutas RK y Hailo.

Qué dispositivos se midieron

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

Detalle de rendimiento

Frecuencia de fotogramas de extremo a extremo en una transmisión en vivo

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

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

• Las dos placas RK: la decodificación por hardware MPP estaba activa y la tasa de mensajes fue de 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 el promedio en una ventana de 30.7 s.
• Reproducción: los benchmarks de inferencia de extremo a extremo y autónomos 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 Serie	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.

Multitransmisión

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.

Runtimes 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 Serie	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 Serie (R2135-12, Hailo-8)	YOLOv8n (yolov8n.hef)	INT8	HailoRT 4.21 + GStreamer	Obtenido del Hailo Model Zoo v2.15.0, directorio hailo8, fijado por sha256
reComputer J40 / J50 Serie	YOLO11n (yolo11n.engine)	FP16	TensorRT	El motor se construye en el dispositivo (export de ultralytics, 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 ocupa 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 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, de modo 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

• Ubicació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 se encuadren las personas, 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 valor 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 hace 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 salvo licencia comercial, así que confirma las licencias de los modelos, o sustituye por 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.