Mapa de Calor de Fluxo de Pessoas no Varejo: Construção, Implantação e Resultados Medidos

Aviso de uso

O mapa de calor registra apenas onde as pessoas estão. Ele não identifica ninguém e não faz correspondência de rostos. A precisão da detecção não foi avaliada; consulte Desempenho e dados medidos.

O que esta solução faz

Uma câmera olha para o chão, localiza cada pessoa no quadro e continua rastreando-as, depois grava onde as pessoas param, quanto tempo ficam e quantas entram e saem em um banco de dados local, mostrado em um dashboard Grafana e em um mapa de calor. Feito para lojas de varejo, pilotos de redes de lojas, pavilhões de exposição e qualquer espaço interno onde decisões de layout dependam de onde as pessoas caminham.

Locais que já têm câmeras IP as mantêm e adicionam um host de IA que faz a detecção. Locais sem câmeras usam uma reCamera, onde a detecção roda dentro da câmera. O vídeo é processado no local e o backend armazena apenas números. Em um stream RTSP ao vivo, reComputer série R2000 (Hailo-8) mediu 14,3 FPS (fonte de 15 FPS), e reComputer séries RK3588 / RK3576 mediram 13,2 / 13,3 FPS.

• Implementação open source (rota reCamera): github.com/xr686/reCamera-with-Heatmap
• Implementação open source (rota câmera IP + Jetson): github.com/bleaaach/yolo11-grafana-influxdb
• Escolhendo uma configuração e implantando: página de reference design

• Processado no local, backend armazena números

  A detecção roda na câmera ou no host de IA. O que chega ao backend são posições em porcentagens, contagens e tempos de permanência. A visualização ao vivo passa pelo gateway de vídeo local e permanece na sua rede.

• Use as câmeras que você já tem

  Qualquer câmera IP com stream RTSP funciona, seja qual for a marca; nada na parede precisa ser substituído. Sem câmeras, uma reCamera com o app de analytics para varejo instalado começa a produzir dados.

• Cinco caminhos de hardware, um dashboard

  reCamera 2002, reCamera Pro, Rockchip, Hailo-8 e Jetson publicam todos o mesmo formato de mensagem. Várias lojas podem misturar hardware e ainda assim reportar para um único backend.

• Sem necessidade de internet após a implantação

  Broker, banco de dados e dashboard rodam todos no backend local. A internet é usada apenas durante a implantação para baixar imagens e modelos.

O que os dispositivos realmente geram

Resultados de cada detector chegam a um dashboard Grafana: o feed de câmera ao vivo à esquerda, e painéis agregando ocupação, estados de permanência e contagens de entrada/saída ao longo do tempo.

Os mesmos dados de posição também desenham um mapa de calor. Áreas mais escuras são onde as pessoas ficaram mais tempo ou passaram com mais frequência. Por padrão ele sobrepõe a visão da câmera; após calibração pode sobrepor a planta do seu estabelecimento.

De que hardware você precisa

Três coisas: uma câmera que veja o chão, algo que detecte pessoas e um backend que armazene os dados e os desenhe. O backend é compartilhado por todas as rotas.

① Câmera — se você já tem câmeras IP com stream RTSP, mantenha-as; qualquer marca funciona e nada na parede muda. Se você não tiver nenhuma, reCamera 2002 / reCamera Pro colocam a câmera e o processamento em uma unidade, executando detecção, rastreamento, estados de permanência e contagem de entradas/saídas dentro da câmera.

② Host de detecção — necessário apenas nas rotas com câmera IP. Cada host executa a mesma lógica de rastreamento e permanência; a diferença é o acelerador.

③ Backend do dashboard — executa o broker MQTT, InfluxDB, Grafana e o gateway de vídeo. Pode ser um computador sempre ligado ou um reComputer R1100; nas rotas com câmera IP ele pode compartilhar o gabinete com o detector.

	Dispositivo	O que faz	Quando escolhê-lo
	reCamera 2002 câmera e processamento em um só, 1080P	Detecção + rastreamento + contagem	Perto da área contada, cobertura pequena, forma mais rápida de colocar um stream em funcionamento
	reCamera Pro câmera e processamento em um só, 4K	Detecção + rastreamento + contagem	Mais distante, cobertura grande, quando pessoas distantes ainda precisam de pixels suficientes para serem enquadradas
	reComputer série RK3588 o mesmo preset também suporta a série reComputer RK3576	Host de detecção	Você já utiliza placas Rockchip; a decodificação de vídeo roda em hardware
	reComputer série R2000 (R2035-12, Hailo-8)	Host de detecção	Um box industrial fanless para um rack ou armário técnico
	reComputer série J40 (J4012) e série reComputer J50	Host de detecção	Várias câmeras em um único host
	reComputer série R1100 (R1124-10)	Backend do dashboard	Nenhum computador sempre ligado no local para executar o dashboard

Outros pré-requisitos: Docker na máquina de backend, pelo menos 2 GB de disco livre, portas 1883, 3000, 8080 e 8086 livres, e câmeras e backend no mesmo segmento de rede para que a descoberta de câmeras ONVIF funcione.

Layout dos dispositivos: câmeras IP entregam vídeo RTSP ao host de IA, enquanto uma reCamera executa a detecção dentro da câmera; detectores geram apenas porcentagens de posição e contagens, sem imagens; cada detector reporta para um backend (broker MQTT, InfluxDB, Grafana, gateway de vídeo go2rtc), então um dashboard cobre todas as câmeras. A visualização ao vivo é o navegador puxando da câmera através do gateway de vídeo local, não pelo banco de dados do backend.

Limites de Seleção Negativa

• Altura de montagem e campo de visão: reCamera 2002 é adequada para tetos de 3–4 m; para alturas acima de 5 m ou grandes átrios, não escolha a 2002, escolha reCamera Pro com resolução 4K.
• Rastreamento de identidade: Esta solução gera apenas mapas de calor de densidade anônimos, não reconhecimento facial ou reidentificação de pessoas.

Instalação no local

Duas partes: montar a câmera corretamente e depois instalar o software.

1. Montando a câmera

Requisitos de posicionamento

Monte a câmera em um ponto alto, olhando para baixo para a área a ser contada, a 3–5 m do alvo. As pessoas devem ocupar pelo menos cerca de 30 × 30 pixels no quadro, caso contrário não poderão ser enquadradas. Vistas ao nível dos olhos, ângulos com forte oclusão mútua e tomadas distantes em que as pessoas ficam muito pequenas causam detecções perdidas.

2. Instalando o software — três a quatro etapas

As instruções por dispositivo estão na página do reference design, onde você responde a algumas perguntas sobre o local e faz o download do pacote de aplicativo correspondente.

Configure e baixe o pacote do app 🖱️

1. Coloque o backend em funcionamento — inicie o broker, o InfluxDB, o Grafana e o video gateway na máquina sempre ligada. Esta etapa descobre câmeras ONVIF no mesmo segmento; para câmeras em outro segmento, insira as URLs RTSP no formulário de implantação.
2. Faça o detector publicar — nas rotas com reCamera, instale o app de análise de varejo na câmera; nas rotas com câmera IP, faça o deploy do detector no host de IA. Ambos pedem três coisas: o endereço do broker MQTT (a máquina da etapa 1), um nome de instalação e um ID de câmera. Use um nome de instalação por loja e um ID por câmera; é assim que o dashboard diferencia os dispositivos.
3. Calibre a planta baixa (opcional) — abra o heatmap na porta 8080, envie uma captura da câmera e a planta da loja e clique em quatro pontos correspondentes em cada uma. Escolha pontos de referência bem espaçados, como pilares, portas e cantos de parede. A calibração é salva no servidor, e várias câmeras podem compartilhar uma planta. Pule esta etapa se a visão da câmera for tudo de que você precisa.
4. Abra o dashboard — Grafana na porta 3000, o heatmap ao vivo em 8080, o video gateway em 1984.

A documentação upstream indica 15 minutos de ponta a ponta. A rota Jetson é a exceção: a primeira implantação gera um mecanismo TensorRT no dispositivo, o que leva de 2 a 5 minutos e é reutilizado depois.

Quais interfaces ele expõe

Todo detector publica o mesmo formato de mensagem no broker backend. Três formas de entrada, dependendo do que você já executa:

• O dashboard integrado é suficiente — nada a integrar. Os painéis Grafana já cobrem tendências de fluxo de pessoas por hora, dia e semana, além de permanência e contagens de entrada/saída, e os dados dos painéis podem ser exportados diretamente.
• Um sistema de BI ou analytics existente — assine o tópico de resultados MQTT para dados em tempo real ou consulte o InfluxDB no backend para histórico.
• Seu próprio sistema ou API — assine como acima; o payload traz contagens por zona mais a posição e o tempo de permanência de cada pessoa rastreada, o suficiente para você desenhar seus próprios painéis. Quadros ao vivo vêm do video gateway local na porta 1984.

Referência completa de tópicos e payload

Tópico / porta	Conteúdo	Retido
<site>/retail-vision/results/<camera-id>	Um JSON em lote por segundo: contagens por zona (ocupação, navegando, engajado, precisa de assistência, entradas, saídas, permanência média) mais o track_id, posição e tempo de permanência de cada pessoa rastreada	Não
<site>/retail-vision/status	online / offline	Sim
Broker MQTT 1883	Resultados de cada detector	—
Grafana 3000	Tendências de fluxo de pessoas por hora, dia e semana; contagens de permanência e entrada/saída	—
Heatmap ao vivo 8080	Sobreposição de calor na visão da câmera ou na sua planta; o ícone de engrenagem abre a calibração	—
Video gateway 1984	Descoberta de câmeras e visualização ao vivo	—

<site> e <camera-id> são definidos no formulário de implantação e aceitam apenas letras, dígitos, hifens e sublinhados.

As posições são publicadas como porcentagens do quadro. Cada detector converte o centro da caixa rastreada em uma porcentagem antes de publicar, de modo que uma calibração de planta valha para qualquer resolução de câmera; substituir por uma câmera de resolução mais alta não exige recalibração.

As mensagens são agrupadas uma vez por segundo. Na reCamera isso é --mqtt-interval-ms 1000; sem isso o app publica por quadro (cerca de 10 mensagens por segundo por câmera). Nas rotas com host de IA é publish_hz: 1.0 na configuração do detector. Com várias câmeras em um mesmo local, se o broker acompanha ou não depende desse parâmetro.

A reCamera Pro não gera tempo médio de permanência, portanto o painel Avg Dwell permanece vazio nessa rota. Outras métricas não são afetadas.

Desempenho e dados medidos

Todas as quatro rotas com host de IA executam a mesma lógica de rastreamento e permanência; o modelo de detecção e o runtime variam por acelerador.

reCamera-with-Heatmap

O que segue são dados medidos de dispositivo para throughput e taxa de mensagens, a partir de fontes ao vivo de fluxo único nas rotas RK e Hailo.

Quais dispositivos foram medidos

Dispositivo	Acelerador	Modelo entregue	Status de verificação
reComputer série RK3588	NPU RK3588	YOLO11n rawhead FP16	✅ Fluxo ao vivo no hardware
reComputer série RK3576	NPU RK3576	YOLO11n rawhead FP16	✅ Fluxo ao vivo no hardware
reComputer série R2000 (R2135-12, Hailo-8)	Hailo-8	YOLOv8n INT8	✅ Fluxo ao vivo no hardware
reCamera 2002	NPU SG2002	YOLO11n INT8	Implantação verificada

Detalhes de desempenho

Taxa de quadros de ponta a ponta em um fluxo ao vivo

A entrada é filmagem RTSP real. A medição cobre todo o caminho desde o quadro da câmera até os resultados chegarem ao backend: decodificação + detecção + rastreamento + lógica de permanência + publicação MQTT, um fluxo por host.

Host de detecção	Modelo	Taxa de rastreamento	Taxa de mensagens MQTT	Fonte
reComputer série R2000 (R2135-12, Hailo-8)	YOLOv8n INT8	14,3 FPS	0,94 msg/s	Medido (440 quadros / 30,7 s)
reComputer série RK3588	YOLO11n FP16	13,2 FPS	1,00 msg/s	Medido
reComputer série RK3576	YOLO11n FP16	13,3 FPS	1,00 msg/s	Medido

• As duas placas RK: a decodificação por hardware MPP estava ativa e a taxa de mensagens foi de 1,00 msg/s.
• Os 14,3 FPS do Hailo são limitados pela taxa de quadros da fonte. Sem limitação, o mesmo pipeline atingiu 234 FPS, cerca de 15× a fonte de 15 FPS.
• A diferença entre 0,94 e 1,00 msg/s vem de como foi feita a média: ambas visam uma mensagem por segundo, e 0,94 é a média em uma janela de 30,7 s.
• Reprodução: benchmarks de inferência de ponta a ponta e autônoma estão no repositório benchmarks/run_heatmap_bench.sh; execute ./run_heatmap_bench.sh --profile rk3588.

Velocidade de inferência autônoma

Host de detecção	Modelo	Por inferência	Fonte
reComputer série J40 / J50	YOLO11n FP16 (TensorRT)	9,7 ms	Valor de inferência autônoma fornecido upstream
reCamera 2002	YOLO11n INT8	cerca de 10 FPS	Taxa na câmera indicada nas notas do app upstream

Essas duas linhas não se comparam diretamente com a tabela de ponta a ponta acima: 9,7 ms excluem decodificação, rastreamento e publicação, e cerca de 10 FPS é a taxa de processamento na câmera, não a taxa em que os resultados chegam ao backend.

Múltiplos fluxos

Cada número acima veio de um host observando uma câmera. "Várias câmeras em um host" é a divisão de trabalho entre presets (a rota Jetson assume esse papel). Um backend pode aceitar qualquer número de detectores no nível de protocolo, separados por nome de instalação e ID de câmera; o limite está no lado do host de IA.

Tempos de execução e parâmetros principais

Host de detecção	Modelo de detecção	Precisão	Runtime	Como o modelo é entregue
reCamera 2002	YOLO11n (yolo11n_detection_cv181x_int8.cvimodel)	INT8	NPU da câmera SG2002	Enviado com retail-vision_1.5.1_riscv64.deb, verificado por sha256
reCamera Pro	Empacotado com o app retail-vision do App Center	Definida pelo app	NPU da câmera	Não incluído no pacote; instale-o primeiro a partir do App Center do dispositivo
reComputer série RK3576 / RK3588	yolo11n_pose_rawhead_fp16.<board>.rknn	FP16	RKNN	Entregue por placa e verificado por sha256; o modelo da placa errada não será carregado
reComputer série R2000 (R2135-12, Hailo-8)	YOLOv8n (yolov8n.hef)	INT8	HailoRT 4.21 + GStreamer	Obtido do Hailo Model Zoo v2.15.0 diretório hailo8, fixado por sha256
reComputer série J40 / J50	YOLO11n (yolo11n.engine)	FP16	TensorRT	O engine é gerado no dispositivo (export ultralytics, half=True, imgsz=640): 2–5 minutos na primeira vez, reutilizado depois

• Hailo está travado na HailoRT 4.21. A implantação verifica as bibliotecas na placa e interrompe, imprimindo a versão instalada, se não corresponderem. Um Hailo-8 executa um aplicativo por vez; se outro app Hailo estiver usando o acelerador, o detector não iniciará.
• As placas RK precisam do driver NPU presente (/usr/lib/librknnrt.so).
• Na reCamera, o aplicativo de analytics assume o controle exclusivo da câmera: ao instalá-lo, o autostart do Node-RED é desativado, e os dois não podem ser executados ao mesmo tempo.

Parâmetros que alteram o comportamento da implantação (valores fornecidos nas rotas RK e Jetson):

• dwell_min_duration (1,5 s) — uma pessoa só é considerada em permanência depois de se mover mais devagar que dwell_speed_threshold (10.0) por esse tempo, de modo que virar de costas em frente a uma prateleira não conta.
• dwell_assistance_threshold (20,0 s) — o tempo de permanência além disso entra no estado de necessidade de assistência.
• avg_person_height_m (1,7) — converte o limite de velocidade de pixels para distância real. Quando a altura média das pessoas na câmera difere substancialmente de 1,7 m, a detecção de permanência se torna mais frouxa ou mais rígida em todo o sistema.

Degradações conhecidas

• Posicionamento. A câmera deve ser montada em altura, de 3 a 5 m do alvo, com pessoas ocupando pelo menos cerca de 30 × 30 pixels no quadro. Vistas ao nível dos olhos, tomadas muito distantes e forte oclusão impedem que as pessoas sejam enquadradas, e uma pessoa que não é detectada deixa o mapa de calor em branco sem gerar erro.
• A calibração da planta baixa é feita com quatro pontos clicados manualmente. Pontos de referência muito próximos entre si ou colineares amplificam o erro de posição. Mover ou redirecionar a câmera invalida a calibração e ela precisa ser refeita — uma calibração incorreta não gera erro, ela apenas desenha o calor em outro lugar.
• O Avg Dwell da reCamera Pro fica sempre vazio, porque o aplicativo não gera esse campo.
• Em RK, a decodificação por hardware volta para decodificação por software quando não está ativa. Uma taxa de quadros claramente baixa junto com uma CPU saturada é o sintoma; a rota Jetson não faz fallback (fallback: none).

Fontes e licenças

• Modelos de detecção — a rota Hailo usa yolov8n.hef do Hailo Model Zoo diretório hailo8 da versão v2.15.0, fixado por digest em vez de ser re-hospedado. A rota RK reutiliza yolo11n_pose_rawhead_fp16.<board>.rknn já publicado por fall_detection. A rota Jetson exporta yolo11n.engine no dispositivo com ultralytics.
• Licenciamento de modelos — os detectores usam modelos da família YOLO (YOLO11n, YOLOv8n). Os modelos Ultralytics YOLO são AGPL-3.0, a menos que licenciados comercialmente, portanto confirme as licenças dos modelos, ou substitua por um modelo com licença compatível, antes de enviar um produto.
• Componentes de backend — o broker MQTT, o InfluxDB, o Grafana e o gateway de vídeo go2rtc são implantados a partir de suas imagens oficiais. As credenciais padrão do Grafana são admin / admin; altere-as logo após a colocação em serviço.
• Imagens — o dashboard do Grafana e as capturas de tela do mapa de calor vêm da biblioteca de ativos da solução upstream; o diagrama de arquitetura é desenhado internamente. Nenhuma pessoa identificável aparece nas imagens de demonstração.