Design e implementação de uma estrutura de detecção de pedestres baseada em matriz de portões programáveis em campo para aplicação de direção autônoma

Summary

Este artigo de pesquisa demonstra a implementação de um algoritmo de detecção de pedestres em tempo real em hardware de gate array programável em campo, principalmente para aplicações de condução autônoma. O algoritmo combina o histograma dos gradientes orientados (HoG) com um classificador de máquina de vetores de suporte (SVM), e os resultados mostram eficiência em termos de velocidade, consumo de energia e utilização de recursos.

Abstract

A direção autônoma oferece uma forma promissora de enfrentar o aumento do número de mortes em acidentes de trânsito. Um veículo autônomo inclui muitos recursos, mas a capacidade de detectar pedestres é crucial, desafiadora e relevante para diversas situações em tempo real, como vigilância, rastreamento de pessoas e monitoramento. Identificar pedestres com precisão é difícil porque eles podem aparecer em diferentes formas, posições e posturas. Eles podem usar vários tipos de roupas e, às vezes, ficar parcialmente escondidos ou se misturar a objetos próximos. Este artigo foca na detecção em tempo real de pedestres para carros autônomos usando uma plataforma de hardware popular: o field programmable gate array (FPGA), Ultra 96 v2. O estudo implementa um método para detecção de pedestres baseado em um histograma de gradientes orientados (HOG) combinado com um classificador de máquina de vetores de suporte (SVM) para reconhecer indivíduos na placa FPGA, aproveitando ferramentas de síntese de alto nível (HLS). A eficácia do sistema foi testada tanto em imagens estáticas quanto em vídeo ao vivo. Os resultados mostram que placas FPGA avançadas, como a Ultra 96 v2, melhoram significativamente as métricas de desempenho. O sistema opera em uma frequência de clock de 150 MHz, consumindo menos da metade dos recursos disponíveis e consumindo cerca de 2,5 W de energia. Além disso, o sistema reporta a precisão da detecção de pedestres próxima a 95% e outras métricas eficientes para avaliação de detecção, como precisão (78,6%), recordação (88,3%) e Pontuação F1 (83,1%). Em resumo, o sistema desenvolvido pode detectar pedestres em tempo real e tem potencial para melhorar significativamente o desenvolvimento de um ambiente de transporte inteligente e seguro.

Introduction

O desenvolvimento urbano e o surgimento das cidades inteligentes são temas de interesse mundial. Todas as nações estão trabalhando para o desenvolvimento de suas cidades, que possam ser construídas de forma que sejam seguras e confortáveis para as pessoas que vivem^{nelas 1,2}. Mas, na situação atual, observou-se que, à medida que a população cresce e o congestionamento nas estradas aumenta, a taxa de fatalidades resultantes de acidentes de trânsito devido a negligência ao volante e problemas de baixa visibilidade está aumentando alarmantemente. Uma solução promissora para esses problemas é o surgimento de veículos autônomos em todo o mundo, que impulsionou a inovação 1,2,3,4, e pesquisadores estão fazendo esforços para desenvolver veículos totalmente autônomos que permitam aos passageiros relaxar sem preocupações. A necessidade do desenvolvimento de veículos autônomos decorre do fato de que até motoristas experientes podem enfrentar estresse, dilemas, fadiga ou dificuldades para perceber o ambiente devido ao mau tempo, e todos esses problemas levam a acidentes de trânsito. Um veículo autônomo é projetado para evitar acidentes durante a viagem, otimizar o uso dos recursos do motor e cumprir as leis de trânsito, o que, sem dúvida, melhorará o transporte ^2,4. Um veículo autônomo é equipado com múltiplos recursos, sensores e funcionalidades que lhe permitem perceber o ambiente com muita precisão, evitando colisões e acidentes, e por isso eles agora se tornaram uma solução promissora para tornar o transporte seguro^{e protegido} 1,2,3,4.

Entre todos os recursos incorporados a um veículo autônomo, um dos mais importantes é a detecção de pedestres. Um sistema robusto de detecção de pedestres pode ajudar significativamente a reduzir fatalidades em acidentes^{de trânsito} 5,6,7,8, já que a maioria das vítimas desses acidentes são pedestres. A detecção de pedestres envolve identificar indivíduos na estrada e evitar colisões com eles. Esse recurso é benéfico não apenas para carros autônomos, mas também para várias outras áreas de aplicação, como monitoramento de multidões, identificação de pessoas e rastreamento^{9, 10 e 11}. O aspecto chave desse processo de detecção é a rapidez e a precisão da detecção. É fundamental detectar pedestres com precisão e rapidez para que o tempo de resposta seja mínimo. A detecção de pedestres representa um enorme desafio. Pedestres na rua podem estar com qualquer roupa, aparência ou postura, e podem ser invisíveis devido ao mau tempo ou à oclusão 10,11,12,13,14. Além disso, é bem possível que os pedestres não sigam as regras por si mesmos, e não se pode controlar a natureza humana, então a melhor abordagem possível é equipar o veículo com a inteligência para lidar com qualquer ação errada e evitar fatalidades. O desenvolvimento completo do trabalho nesta pesquisa e a motivação por trás da implementação por hardware da detecção de pedestres podem ser facilmente compreendidos a partir da Figura 1 abaixo, que explica a necessidade da detecção de pedestres, suas diversas áreas de aplicação, os desafios envolvidos e a implementação em um FPGA para aproveitar os benefícios oferecidos.

Figura 1: Detecção de pedestres. A necessidade de detecção de pedestres, as principais áreas de aplicação da detecção de pedestres, os desafios envolvidos na detecção de pedestres e a implementação do fluxo da detecção de pedestres em uma placa FPGA. Por favor, clique aqui para ver uma versão ampliada desta figura.

Para identificar pedestres na via, existem diversos algoritmos. Essa tarefa geral pode ser dividida principalmente em duas subtarefas principais: a etapa inicial extrai características de uma imagem de entrada, mantendo apenas aquelas que são significativas e transmitem informações relevantes, enquanto ignora as redundantes. Para o reconhecimento eficaz de humanos ou pedestres em uma imagem, é crucial que essas características indiquem a presença de uma figura humana dentro da^{cena 13,14}. Após essa extração, as características precisam ser enviadas para um classificador que possa determinar se as características identificadas correspondem a um humano. Portanto, o algoritmo requer uma fase de extração e descrição de características, seguida de uma etapa de classificação para determinar a presença de pedestres na cena de entrada. Existem vários algoritmos disponíveis para esse propósito. No entanto, o método mais amplamente aceito para detecção de pedestres até hoje permanece a combinação do histograma de gradientes orientados (HoG) com o classificador da máquina de vetores de suporte (SVM⁾ 12,13,14,15. Existem inúmeros exemplos de avanços de software, mas, em última análise, o objetivo é portar a implementação para uma plataforma de hardware compatível, que possa então ser integrada ao sistema de aplicações para uso em tempo real. Portanto, a ênfase atual está na realização de hardware. Pode-se, portanto, afirmar que é necessário desenvolver uma implementação adequada de hardware para sistemas de detecção de pedestres, onde câmeras equipadas com hardware apropriado possam ser instaladas em veículos e identificar pedestres na via. Ao considerar qual hardware é apropriado para tais implementações, uma das opções mais comumente utilizadas é o field programmable gate array (FPGA), devido às suas inúmeras vantagens, incluindo redução do tempo de projeto, escalabilidade, facilidade de modificações, reconfigurabilidade e menor consumo de energia e^{energia 15,16,17,18,19,20,21.22}.

Placas FPGA evoluíram consistentemente e agora são amplamente usadas em aplicações complexas e avançadas de visão computacional que vão desde processamento básico de imagens até detecção de objetos, realidade aumentada e deep learning 20,21,22^. Atualmente, várias placas FPGA de alto desempenho oferecem capacidades arquitetônicas excepcionais para acomodar o processamento extenso necessário para essas aplicações complexas. Se as características avançadas dos veículos autônomos, como a detecção de pedestres, forem implementadas nessas plataformas de hardware, essas plataformas podem ser muito úteis para o desenvolvimento rápido de protótipos para analisar o desempenho e, após a otimização, o algoritmo implementado pode ser transferido para circuitos integrados reais para integração no sistema.

Por mais de uma década, houve publicações significativas baseadas na implementação da detecção de pedestres usando os métodos HoG e SVM em diferentes plataformas FPGA. A Tabela 1 resume os artigos nessa área durante o período de 2015 a 2025 15,16,17,18,19,20,21,22,23,24, focando nos fatores-chave como a resolução da imagem, a taxa de transferência ou os quadros por segundo (FPS), o tipo de classificador e os principais destaques ou contribuições feitas pelo Papel.

Referência	Plataforma FPGA	Resolução de Imagem	Classificador	Destaques / Contribuições
15	Xilinx Zynq	640×480	AdaBoost	Implementação de FPGA em tempo real; eficiente em termos de recursos; usa binarização para otimização; Boa precisão de detecção.
16	Placa DE1-SOC da Terasic	640×480	SVM	Extrator de HOG de alto desempenho; integra SVM; detecção em escala única; pipeline de baixa latência.
17	Altera DE2-115	640×480	AdaBoost	Avalia o desempenho sob múltiplos pontos de vista; implementação FPGA do HOG+AdaBoost; Detecção de pedestres em tempo real.
18	Intel Stratix V	640×480	SVM	Detecção de pedestres em múltiplas escalas; pipeline HOG+SVM amigável a FPGA; destaca os trade-offs entre precisão e eficiência de hardware.
19	Zynq UltraScale+ MPSoC	3840×2160	SVM	Processamento UHD em tempo real; HOG+SVM pipelineado; Implementação de SoC FPGA; otimização de ponto fixo; Arquitetura escalável.
20	Não especificado	Não especificado	SVM	Alcança >95% de precisão de detecção; implementação de FPGA em tempo real; aproveita o paralelismo; projeto detalhado de FPGA HOG+SVM para detecção de pedestres.
21	Zync 7000 FPGA	1920×1080	SVM	Arquitetura de fluxo de alta taxa para HOG+SVM; suporta resolução HD; pipeline eficiente para aceleração FPGA.
22	Ultra96 (rev1)	240×320	SVM	Implementação de FPGA usando HLS; detecta sinais vermelhos; calcula probabilidades em 891 regiões; a latência varia de 153.838 a 19 ciclos.
23	Xilinx Zynq-7000 FPGA	640 × 480	HOG + SVM	Implementou detecção de pedestres usando HOG-SVM em FPGA, alcançando desempenho em tempo real com menor consumo de energia em comparação ao processamento de CPU. Demonstrou pipeline otimizado de extração de recursos adequado para aplicações de visão embarcada.
24	Xilinx Virtex-6 FPGA	640 × 480	Detector de objetos de ponto fixo (características semelhantes a Haar)	Propôs aceleração FPGA de alta taxa de detecção de objetos usando aritmética de ponto fixo, reduzindo o custo computacional enquanto mantém a precisão. Mostrou 15× de aceleração em relação a implementações de CPU com utilização eficiente de recursos de hardware.

Tabela 1: Revisão da literatura de pesquisas baseadas na detecção de pedestres em FPGA (2015–2025).

A Tabela 1 resume que existe uma extensa literatura no domínio da detecção de pedestres, e a implementação de hardware é a área de interesse dos pesquisadores. Também é evidente que existem técnicas avançadas de aprendizado profundo e aprendizado de máquina, como detectores baseados em redes neurais convolucionais (CNNs), como YOLO, arquiteturas baseadas em transformadores, etc., para a tarefa de detecção de pedestres. Eles até superam o algoritmo tradicional HoG em termos de precisão, mas quando se considera a implementação por hardware, os algoritmos avançados levam a uma enorme utilização de recursos^23,24 devido às complexidades do algoritmo, que também podem afetar outros parâmetros de desempenho, e também foi observado que, devido às complexidades adicionais, a velocidade é um pouco melhor no caso do algoritmo HoG^{tradicional 24, 25}. Também foi observado que as técnicas avançadas consomem mais energia quando implementadas em hardware^24,26. Assim, o objetivo do trabalho implementado neste artigo é realizar a detecção de pedestres usando a tradicional estrutura HoG e SVM em hardware FPGA e alcançar um compromisso favorável entre precisão-velocidade-recursos e energia para a incorporação em tempo real. A partir da Tabela 1, fica bastante claro que, ao analisar o trabalho baseado em HoG e SVM, observa-se que há publicações limitadas que utilizaram a recém-introduzida placa de desenvolvimento FPGA baseada em Zynq UltraScale+ (Multi-Processor System On Chip) baseada em^{FPGA 27} para explorar a capacidade dessas placas, já que, do ponto de vista da arquitetura, elas evoluíram, e oferecem grande potencial em termos de implementação de aplicações de visão computacional em tempo real de alto ponto. Existem publicações limitadas que realizaram todo o sistema de detecção de pedestres em tempo real nas placas FPGA. No entanto, eles têm se concentrado na implementação eficiente ou melhoria das tarefas intermediárias. Além disso, a maioria dessas implementações baseia-se na realização de todo o sistema em uma placa FPGA por meio do uso de linguagens de descrição de hardware. Poucos utilizaram os benefícios das ferramentas de Síntese de Alto Nível (HLS) para acelerar o ciclo de projeto. Este artigo demonstra o design e a implementação da detecção de pedestres em tempo real em uma placa FPGA dedicada a uma aplicação de direção autônoma. O artigo utiliza a estrutura HoG e SVM para detectar pedestres em imagens estáticas, vídeo ou entrada real de câmeras. O hardware utilizado é uma placa FPGA de ponta e recentemente lançada, a Ultra96 v2, que é uma arquitetura FPGA avançada que é uma plataforma poderosa para visão computacional, processamento de imagens, aprendizado de máquina, computação de borda, ^etc.24. O Ultra96 v2 é uma placa de desenvolvimento que conta com um AMD Xilinx Zynq UltraScale+^{MPSoC 27} baseado em Arm. Esta placa inclui o segmento de sistema de processamento (PS), que consiste em núcleos de CPU baseados em ARM que gerenciam os aspectos de software do projeto, e o segmento de Lógica Programável (PL), que permite aceleração de hardware^{personalizável} 20,21,22. Juntos, esses componentes aprimoram a funcionalidade de um sistema híbrido, onde a parte PS gerencia o controle e a interação com elementos externos, enquanto a parte PL cuida da lógica real de processamento.

Protocol

O procedimento de implementação utilizado nesta pesquisa, baseado na detecção de pedestres com HoG + SVM em uma placa FPGA, aproveitando os benefícios da síntese de alto nível, está ilustrado na Figura 2 abaixo.

Figura 2: Procedimento de projeto para implementação da detecção de pedestres em placa FPGA. Fase 1: Algoritmo de detecção de pedestres usando HoG+SVM na ferramenta HLS e geração de bloco IP. Fase 2: Algoritmo de detecção de pedestres usando HoG+SVM para implementação real do FPGA e geração do arquivo de bits. Fase 3: Programar a placa com o arquivo de bits gerado. Por favor, clique aqui para ver uma versão ampliada desta figura.

1. Detecção de pedestres usando HoG e SVM na ferramenta HLS

1. Baixe o Ambiente Integrado de Desenvolvimento (IDE) em Python dependendo das propriedades do sistema em que o download é feito.
   NOTA: Neste trabalho, é usada a versão Python 3.10.
2. Execute um script em Python para rodar um modelo de treinamento usando o algoritmo HoG e o classificador SVM. Comece o script carregando as amostras positivas e negativas do conjunto de dados.
   NOTA: Use o conjunto de dados¹¹ do INRIA.
3. Extraia as características HoG para um tamanho de janela de 64 x 128.
4. Divida os dados de treinamento e testes do conjunto de dados do INRIA em uma proporção de 80/20, com embaralhamento aleatório para reprodutibilidade.
   NOTA: O conjunto de dados é embaralhado aleatoriamente usando a função python antes de dividir os dados. Para garantir a reprodutibilidade para que a mesma divisão seja feita toda vez que um valor seed é fixado no código.
5. Treine usando a SVM de classificação vetorial de suporte C (SVC) com um núcleo linear.
6. Extraia os vetores de peso e o viés.
7. Salve os pesos SVM e o viés no formato Q8.8 de ponto fixo para a implementação FPGA.
   NOTA: A conversão é feita escalando cada valor de ponto flutuante originalmente gerado por um fator de 256 (2⁸) e convertendo o resultado em um inteiro.
8. Teste o modelo treinado por meio de outro script em Python e ajuste o parâmetro de regularização C, até que a precisão seja calculada como superior a 95%.
   NOTA: Parâmetro de regularização otimizado obtido: C = 0,05.
9. Abra a ferramenta HLS e crie um novo projeto com o número da peça selecionado como xczu3eg-sbva484-1-e.
10. Escreva um código de detecção de pedestres na ferramenta de síntese de alto nível usando linguagens de alto nível como C++.
11. No código, escreva três scripts diferentes em C++: um para o descritor de características HoG e o classificador SVM, outro para a bancada de testes fornecer entrada às imagens de teste e salvar as imagens de saída, e o terceiro para um arquivo de cabeçalho que declara os parâmetros usados no código.
12. No código para cálculo de características HoG, redimensione a imagem para 640 x 480 e aplique uma arquitetura de janela deslizante com tamanho de janela de 64 x 128. Para cada janela, calcule a magnitude e orientação do gradiente para cada bloco sobreposto de 8 x 8.
    NOTA: É importante escanear toda a imagem através do conceito de janela deslizante para que cada área da imagem seja coberta e pedestres de todos os tamanhos possíveis sejam identificados.
13. Na outra parte do mesmo código para o descritor de características HoG, passe os gradientes calculados para o classificador SVM. Escreva o código para corresponder as características aos pesos do classificador e compare com o limiar para classificar a característica detectada como humana ou não.
14. Clique em Executar Simulação C na ferramenta HLS para simular o código com a ajuda de uma bancada de testes para verificar a correção funcional.
15. Forneça diferentes imagens de entrada para o código e verifique as imagens de saída com os pedestres detectados.
16. Clique em Executar Síntese C para sintetizar o código, mapear o código para linguagens de hardware pela ferramenta e gerar os relatórios de tempo e utilização.
    NOTA: A ferramenta abre automaticamente os relatórios de síntese HLS. Este relatório mostra a estimativa da frequência de clock necessária para implementar a tarefa codificada em uma plataforma FPGA selecionada, e também fornece uma estimativa dos recursos utilizados. Esses valores reportados são apenas estimativas e os parâmetros reais são calculados somente após a implementação na placa FPGA.
17. Clique em Exportar RTL para exportar o bloco de Propriedade Intelectual (IP) do algoritmo HoG de detecção de pedestres.
    NOTA: Este IP deve ser usado nas etapas finais da implementação.

2. Programação da placa FPGA

1. Abra a ferramenta para programação FPGA e crie um novo projeto. Selecione o número da peça como xczu3eg-sbva484-1-e e crie um novo design de bloco.
   NOTA: Este diagrama de blocos foi criado para estabelecer a integração entre a parte PS e a PL da placa FPGA. O protocolo de comunicação utilizado é o protocolo Advanced eXtensible Interface (AXI).
2. Procure pelo Catálogo de IPs na ferramenta e, uma vez encontrado, abra-o.
3. Crie um repositório de usuário adicionando o caminho do IP RTL exportado na etapa 1.17.
4. Na nova janela de design de blocos , agora clique com o botão direito e selecione adicionar IP. Todos os IPs estarão visíveis, incluindo aqueles fornecidos pela ferramenta, bem como repositórios adicionados pelo usuário.
5. Adicione o bloco PS do Zync Ultrascale do repositório.
   NOTA: Este bloco reflete a parte PS do sistema, responsável por gerar os clocks necessários, e também possui as portas master e slave para conexão ao IP HoG importado via o bloco de interconexão AXI, que roda nos fundamentos do protocolo AXI.
6. Adicione 8 IPs HoG porque o sistema processará 8 janelas simultaneamente para aproveitar o benefício do paralelismo oferecido pela placa FPGA.
7. Adicione um bloco de reset do sistema do processador , que também controle o clock e resetem os suprimentos de cada bloco do diagrama.
8. Adicione dois blocos axi_smart conectar para conectar os IPs HoG com o bloco PS do Zync. O diagrama de blocos completo com as conexões completas é mostrado na Figura 3.
   NOTA: Como mostrado na Figura 3, todos os blocos que precisam ser adicionados ao projeto foram mostrados claramente. A Figura 3 é capturada pela ferramenta e mostra as portas internas de cada bloco, bem como as interconexões entre as portas dos diferentes blocos. Esse bloco é o projeto principal, pois é responsável por estabelecer a interface entre a parte PS e PL da placa FPGA.
9. Após concluir as conexões conforme a Figura 3, clique em validar projeto.
   NOTA: A validação basicamente verifica as conexões faltantes ou falhas, o que pode causar problemas em estágios posteriores.
10. Clique em síntese e então Implemente design no tool após a validação do diagrama de blocos ser bem-sucedida.
    NOTA: A síntese mapeia o diagrama de blocos projetado e o mapeia na placa FPGA. Esta etapa reportará quaisquer violações que possam indicar que o projeto não pode ser implementado em hardware.
11. A ferramenta também gerará relatórios relacionados a timing, utilização de recursos e consumo de energia. Examine cuidadosamente os relatórios para verificar possíveis violações de tempo e analise o desempenho do sistema projetado.
12. Clique em Gerar o arquivo de fluxo de bits , que gerará o arquivo .bit necessário para programar a placa FPGA.

Figura 3: Diagrama em blocos para detecção de pedestres usando HoG + SVM importado IP. Por favor, clique aqui para ver uma versão ampliada desta figura.

3. Implementação final na placa FPGA

1. Pegue a placa FPGA e insira o cartão SD com o arquivo de imagem correto no slot da placa.
2. Conecte a placa ao computador também.
3. Inicialize a placa FPGA no modo cartão SD para habilitar a programação em Python^{nela 21,22}.
4. Acesse a plataforma Jupyter na placa depois de conectá-la ao wifi.
5. Conecte uma câmera web à placa.
6. Escreva um código Python para importar o arquivo de bits gerado e realize a tarefa de acessar as imagens da câmera.
7. No código, escreva o script para que a imagem seja escrita na memória da placa FPGA através da parte PS e passada para a parte PL para processamento.
   NOTA: A parte PL da placa que corresponde aos IPs HoG acessa os pixels da imagem por meio dessas localizações de memória, processa-os e fornece as pontuações como saída.
8. Escreva código apropriado no mesmo script Python para ler as imagens processadas e exibi-las na tela do computador.
   NOTA: Isso completa todo o projeto e o sistema está agora pronto para implantação em aplicações do mundo real. Todos os códigos usados neste estudo são carregados como arquivos suplementares de codificação (Arquivo Suplementar 1 [Script_1_train_test.py], Arquivo Suplementar 2 [Script_2_HLS_hog.cpp], Arquivo Suplementar 3 [Script_3_HLS_test_bench.cpp], Arquivo Suplementar 4 [Script_4_HLS_consts.h], Arquivo Suplementar 5 [Script_5_jupyter_code.txt]).

Results

Implementação de detecção de pedestres no HLS
A Figura 4 mostra os resultados da simulação na ferramenta HLS para a detecção de pedestres usando HoG + SVM. Uma imagem de entrada com um pedestre é fornecida como entrada de teste ao código, e a saída com os pedestres detectados é exibida. A imagem tem duas seções. A primeira detecção apresenta muitas caixas delimitadoras ao redor do mesmo pedestre repetidas vezes, e na segunda imagem, as caixas sobrepostas são removidas e suprimidas, restando apenas as caixas principais de detecção.

Figura 4: Resultado da simulação da ferramenta HLS. (A,B) Duas imagens de entrada diferentes e as imagens resultantes com os pedestres detectados. Por favor, clique aqui para ver uma versão ampliada desta figura.

A ferramenta HLS também fornece relatórios de síntese para o momento e a utilização de recursos. O resumo de tempo destaca o período de tempo exigido pelo projeto e fornece os valores máximos e mínimos de latência em termos do número de ciclos. Essas informações são úteis para estimar quanto tempo o projeto leva para ser executado e qual deve ser a frequência do clock ao passar para a implementação de hardware propriamente dita. A Tabela 2 abaixo mostra o relatório de tempo após a síntese HLS, que mostra claramente que o período de clock alvo foi de 6 ns e o projeto levou 5,25 ns, que é menor que o alvo, e portanto o período pode ser 6ns ou mais, mas não abaixo de 5 ns.

Resumo do Tempo
Relógio	Alvo	Estimado
	6,00 ns	5.250 ns
Resumo de Utilização
	Total / Disponível	Percentual de Utilização
BRAM18K	22 / 432	5%
DSP48E	13 / 360	3%
FF	5611/ 141120	3%
LUT	9904/ 70560	14%
URAM	0	0

Tabela 2: Estimado de tempo e relatório de utilização de recursos da ferramenta HLS para detecção de pedestres usando HoG-SVM.

A Tabela 2 também mostra o relatório de utilização. Ele mostra a porcentagem de utilização de recursos importantes de FPGA a bordo, conforme a placa alvo selecionada. Para esse projeto de detecção de pedestres, o relatório de utilização mostra que o projeto consome 14% das tabelas de consulta (LUTs), 3% dos Flip Flops (FFs), 3% do processamento digital de sinal (DSP) e 5% da memória de acesso aleatório em bloco (BRAM). Essas estimativas não são os relatórios exatos de utilização, mas os relatórios reais são próximos dessas estimativas. Essas são apenas as estimativas que podem ser calculadas pelas ferramentas HLS. A implementação real geralmente é muito diferente dessas estimativas.

A implementação real resulta da programação por hardware
Após o código ser mapeado em um IP, que é importado na ferramenta de programação FPGA, e o design ser implementado no hardware real do FPGA, vários relatórios também são gerados. A primeira é o resumo de tempo, que mostra se a frequência de clock fornecida ao projeto é suficiente ou não. Se todas as restrições de tempo forem cumpridas e não houver violações, então o projeto pode prosseguir. A Tabela 3 abaixo mostra o resumo de tempos gerado pela ferramenta. Como mostrado na tabela, o resumo de tempo indica a pior folga negativa, que é 4,073 ns. Como esse valor é positivo, indica que esse tempo ainda está disponível. Valores negativos indicam que o FPGA está demorando mais para concluir a tarefa, e o relógio está correndo rápido. Já que nesse caso não há valores negativos, o que significa que as restrições de tempo foram cumpridas.

Resumo do Tempo de Projeto
Configuração	Segura	Largura do Pulso
Pior Folga Negativa 4.073 ns	Pior Folga de Seguração 0,010 ns	Pior largura de pulso: folga 3.500 ns

Tabela 3: Resumo real do tempo para detecção de pedestres na placa FPGA.

Além disso, a ferramenta mostra os relatórios de utilização de recursos, que são a utilização real dos recursos a bordo conforme a placa FPGA selecionada. Neste caso, a placa selecionada é a placa de desenvolvimento FPGA²⁷ baseada em Zynq UltraScale+ MPSoC (Multi-Processor System On Chip). A Tabela 4 abaixo mostra a utilização de recursos e a Figura 5 mostra a representação diagramática da utilização dos recursos.

O resumo de utilização indica o consumo real dos recursos a bordo, dado que existem 8 IPS HoG usados em paralelo, e as estimativas reportadas pela síntese HLS foram para um único IP HoG. Mas mesmo após um uso tão extenso, a utilização de cada recurso é inferior a 50%. A Tabela 4 indica claramente a utilização em relação aos diversos recursos e sua porcentagem de utilização, representada pictorialmente na Figura 5.

Recurso	Utilização	Disponível	Percentual de utilização
LUT	40536	70560	57.45%
LUTRAM	7304	28800	25.36%
FF	33342	141120	23.63%
BRAM	68	216	31.48%
DSP	128	360	35.56%
BUFG	2	196	1.02%

Tabela 4: Relatório de utilização real para detecção de pedestres no quadro FPGA.

Figura 5: Utilização de recursos para detecção de pedestres na placa FPGA após a implementação real. Consulte tabelas (LUT): 57%, LUTRAM: 25%, Flip flops (FF): 24%, RAM em bloco (BRAM): 31%, Processadores digitais de sinal (DSP): 36%, Buffers: 1%. Por favor, clique aqui para ver uma versão ampliada desta figura.

O terceiro relatório trata das estimativas de potência da placa para a quantidade de consumo de energia pelo projeto. A Figura 6 abaixo mostra o relatório de consumo de energia, que mostra que a potência total no chip é de 2,435 W. A temperatura da junção e a energia consumida por cada rede e componente importantes também são mostrados. As medições de energia não destacam nenhum consumo alarmante de energia, e portanto o projeto pode ser considerado eficiente em energia.

Figura 6: Estimativa de potência para detecção de pedestres na placa FPGA após a implementação real. O relatório de energia gerado pelas ferramentas mostra a potência total consumida como 2,435 W e também mostra a distribuição da potência entre os diversos recursos na placa FPGA. Por favor, clique aqui para ver uma versão ampliada desta figura.

Outra análise é feita para entender a vantagem de usar 8 IPs HoG em vez de um único IP HoG ou mais de 8 no diagrama de blocos criado, como mostrado na Figura 3. As métricas de desempenho relacionadas ao hardware foram calculadas tanto para um único IP HoG quanto para 8 IPs HoG em paralelo. A Tabela 5 abaixo mostra a comparação.

Métrica de Desempenho	1 IP	8 IPs
Temporização (ns)	5.312	~5,25
Frequência (MHz)	188	150
Potência (W)	1.9	2.43
LUTs	4998	40536
FF / Registradores	4,031	33,342
DSP	16	128
BRAM	8.5	68
FPS	~10–11	83

Tabela 5: Comparação de métricas de desempenho usando IPs HoG únicos versus múltiplos.

A Tabela 5 indica claramente que, quando os recursos são considerados como os LUTs, FFs, DSPs e BRAM, então, com um único IP HoG e 8 IPs HoG, a escalabilidade é linear com quase 8 vezes aumento nos recursos utilizados. Isso é claramente esperado, já que mais IPs levarão a mais recursos sendo consumidos. Além disso, se a frequência for observada, então a frequência máxima também degrada ligeiramente em 20% de 188 MHz para 150 MHz. Isso também é esperado, pois mais blocos levam a mais conexões e, portanto, a caminhos mais longos, causando aumento de caminhos críticos. Mas os fatores vantajosos como quadros por segundo (FPS) melhoram de 10 para 83, demonstrando escalonamento não linear no caso de FPS devido ao conceito introduzido de paralelismo, devido a 8 IPs HoG. Além disso, a potência varia de 1,9 W para 2,4 W, indicando melhor eficiência energética por meio do pipeline. Assim, essa análise indica claramente que a introdução de IPs HoG 8 é benéfica para o projeto, e escalar além de 8 pode causar consumo excessivo de recursos; assim, o número de blocos além de 8 não é considerado favorável.

Resultados da detecção de pedestres após a implementação do FPGA
Por fim, todo o sistema é integrado à placa FPGA, e o arquivo de fluxo de bits é gerado, que é então programado na placa através do cartão SD iniciado com capacidade de programação em Python. Uma vez que a placa é inicializada com o cartão SD, a interface jupyter pode ser acessada e o código Python pode ser escrito e executado na plataforma. O código Python é executado e testado para detecção de pedestres em diferentes imagens de entrada. O resultado de algumas imagens é mostrado na Figura 7 abaixo. Essas imagens são utilizadas do conjunto de dados INRIA, bem como imagens aleatórias de pedestres obtidas de fontes online^{de código aberto 26,27}.

Figura 7: Resultados da detecção de pedestres em imagens estáticas via FPGA Board. As imagens testadas incluem imagens do conjunto de dados INRIA, imagens de código aberto disponíveis no Google para testar a precisão da detecção em ruas lotadas da Índia. Por favor, clique aqui para ver uma versão ampliada desta figura.

O sistema também é testado em captura de quadros em tempo real por meio de uma câmera web e na detecção dos pedestres no quadro, assim como é testado em entradas de vídeo já gravadas de pedestres. Os resultados para isso estão representados nas Figuras 8 e 9. A Figura 8 mostra um conjunto de exemplos capturados pela câmera web e os resultados da detecção de pedestres em cada quadro, enquanto a Figura 9 mostra os resultados da detecção de pedestres implementados em um vídeo de entrada fornecido ao sistema.

Figura 8: Resultados da detecção de pedestres em um quadro capturado por uma câmera em tempo real através da placa FPGA. Captura em tempo real de vídeo através da câmera web 720 P e demonstração da detecção em tempo real de pedestres. As imagens borradas são causadas à medida que são tiradas fotos do vídeo ao vivo em andamento. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 9: Resultados da detecção de pedestres em vídeos fornecidos como entrada para a placa FPGA. Os vídeos foram retirados de links open source. Por favor, clique aqui para ver uma versão ampliada desta figura.

Estimativa de métricas de desempenho
Para calcular a eficiência e analisar o desempenho do projeto implementado acima, é essencial calcular métricas de desempenho que sejam úteis para avaliar o desempenho. As métricas de desempenho para detectar a eficiência de um algoritmo de detecção dependem basicamente dos valores de verdadeiros positivos (TP), verdadeiros negativos (TN), falsos positivos (FP) e falsos negativos (FN). A partir desses valores, métricas de desempenho como precisão, recordação, pontuação F1, falsos positivos por imagem e precisão podem ser calculadas conforme as equações abaixo. Foi observado que a maioria dos artigos de pesquisa relata seu desempenho de detecção através do parâmetro de precisão. Mas foi observado que o cálculo de precisão que envolve o uso de TN pode ser um parâmetro enganoso, pois o valor de TN não pode ser calculado corretamente no sentido verdadeiro, pois envolve encontrar a contagem de todas as janelas de detecção em uma imagem que na verdade não tem um pedestre, e o algoritmo implementado também reporta que não há detecções. Esse número geralmente é muito grande, pois o número total de janelas de detecção em uma imagem é grande, e as áreas de fundo em cada imagem geralmente correspondem a regiões sem pedestres. Ao observar de perto a fórmula de precisão mostrada nas equações [1] – [5], pode-se perceber que, como o valor de TN será bastante alto em comparação com TP+FP+FN, o parâmetro de precisão geralmente tem um valor alto. Para avaliar verdadeiramente o desempenho, é muito melhor reportar métricas como precisão, recordação e pontuação F1 que não dependem do TN e, portanto, são muito mais precisas.

[1]

[2]

[3]

[4]

[5]

Para encontrar os valores de TP, TN e FN para este artigo, o experimento nas imagens estáticas foi repetido em um enorme número de imagens. A partir dos resultados de cada imagem, foi calculado o valor dos verdadeiros positivos, que é o número de pedestres detectados corretamente, falsos positivos, o número de pedestres detectados incorretamente e falsos negativos, que são os pedestres reais que não foram detectados. Os seguintes valores foram reportados após os experimentos realizados e estão mostrados na Tabela 6 abaixo.

Métrica de Desempenho	Valor
TP	143
FP	39
FN	19
Precison	0.786 (78.6%)
Recall	0.883 (88.3%)
Placar da F1	0.831 (83.1%)
FPPI	0.867

Tabela 6: Métricas de desempenho para o algoritmo de detecção de pedestres baseado em FPGA implementado.

A Tabela 6 acima descreve assim a precisão do algoritmo de detecção de pedestres por meio das várias métricas de desempenho, precisão, recordação, pontuação F1 e FPPI, quando o algoritmo é implementado na plataforma de hardware.

Comparação de desempenho com implementações HoG baseadas em FPGA existentes
Por fim, o trabalho executado pode ser comparado com a literatura anterior para indicar contribuições significativas dessa pesquisa. Essa comparação está representada na Tabela 7^{15, 16, 17, 21, 24}abaixo. Os artigos com os quais a comparação é feita são todos baseados em aplicações de detecção de pedestres implementadas em plataformas FPGA, e os algoritmos usados para essas detecções também são os mesmos para todos, que é HoG combinado com um classificador, que é um classificador Adaboost ou SVM. O tamanho da imagem também é o mesmo para cada um (640 × 480). A comparação é feita com base em parâmetros como a frequência do clock, que afeta a velocidade, os quadros por segundo, o consumo de energia e a utilização de recursos em termos de LUTs, DSPs, Memória, Fatias e Registradores. Para induzir uma comparação justa, os artigos de pesquisa considerados para comparação têm resolução de imagem semelhante e, para normalizar a comparação de recursos, toda utilização de recurso é normalizada dividindo o número de recursos consumidos pelo total de recursos disponíveis de acordo com a placa FPGA utilizada.

Referência	Tamanho da Imagem	Placa FPGA	Frequência de Clock	Quadros por segundo (FPS)	Energia	Pixels /clock	LUTs (%)	DSP48s (%)	BRAMs /Bits de memória (%)	Caixas/FF (%)
15	640×480	Xilinx Zynq	82,2 MHz	40	-	1	40	2	0	-
24	640×480	Virtex 6	150 MHz	10	19 W		39	53	22	-
16	640×480	Ciclone V	162 MHz	526	9 W	0.99	21	86	100	21
17	640×480	Altera DE2-115	50 MHz	129	3,6 W	-	73	-	72	60
21	640×480	Zync 7000	100 MHz	240	1,6 W	-	13	3	1	10
ESSA OBRA	640 x 480	Ultra 96 v2	150 MHz	83	2,435W	0.0632	57	35	31	24

Tabela 7: Comparação de parâmetros e desempenho para implementações de detecção de pedestres em FPGA

Como visível na Tabela 7 acima, pode-se notar que, quando a implementação nesta pesquisa é comparada com os trabalhos anteriores, as comparações apresentam melhorias significativas em termos de velocidade. A placa FPGA é capaz de operar em uma frequência de clock de 150 MHz, o que indica que o período de tempo para completar toda a tarefa é inferior a 6 ns. Embora alguns trabalhos anteriores relatem significativamente mais FPS, por meio de uma análise cuidadosa, pode-se analisar que essa vantagem tem um custo maior de consumo de energia, bem como a utilização quase completa de certos recursos. Se o consumo de energia for considerado, então neste trabalho a potência reportada também é menor e as utilizações de recursos sugerem que o consumo de cada recurso é ligeiramente maior do que certas implementações, mas igual ou inferior a 50% (57% LUTs, 35% DSPs e 31% BRAM), o que mostra espaço significativo para mais tarefas a serem implementadas neste projeto. No geral, pode-se afirmar que o trabalho implementado neste artigo alcança um equilíbrio entre desempenho, energia e utilização de recursos. Além disso, o trabalho apresentado demonstrou paralelismo escalável através de múltiplos blocos de IP sem afetar drasticamente os parâmetros de desempenho.

Arquivo Suplementar 1: Script_1_train_test.py.Por favor, clique aqui para baixar este arquivo.

Arquivo Suplementar 2: Script_2_HLS_hog.cpp. Por favor, clique aqui para baixar este arquivo.

Arquivo Suplementar 3: Script_3_HLS_test_bench.cpp. Por favor, clique aqui para baixar este arquivo.

Arquivo Suplementar 4: Script_4_HLS_consts.h.Por favor, clique aqui para baixar este arquivo.

Arquivo Suplementar 5: Script_5_jupyter_code.txt.Por favor, clique aqui para baixar este arquivo.

Discussion

Este estudo implementa efetivamente um sistema de detecção de pedestres em tempo real utilizando o algoritmo HoG + SVM em hardware avançado de FPGA baseado na placa de desenvolvimento Zynq UltraScale+^{MPSoC 24}. Os resultados indicam que o algoritmo tradicional HoG de detecção humana¹¹ atinge precisão próxima a 95% e utiliza apenas metade dos recursos FPGA embarcados (LUTs, FFs, BRAM, DSPs), deixando uma enorme capacidade de incluir muito mais processamento para realizar diferentes tarefas. Quando toda a abordagem de implementação é analisada, observa-se que há várias etapas críticas envolvidas. Um passo importante é treinar o modelo^SVM 18,19,24 com um conjunto de dados apropriado para detecção eficaz de pedestres, de modo que os pesos sejam extraídos e utilizados na programação do FPGA. O código de treinamento indicará a precisão do desempenho, e o limiar de detecção precisa ser ajustado cuidadosamente através do parâmetro de regularização para alcançar uma precisão próxima a 95%. Os parâmetros selecionados no treinamento são os descritores personalizados de HoG com tamanho de janela de 64 x 128, tamanho de bloco de 16 x 16, tamanho de célula de 8 x 8, e um número de bins selecionado como 9. Atualmente, o treinamento foi realizado no conjunto de dados¹¹ do INRIA, com 2416 imagens positivas e 1218 imagens negativas. O aumento inclui a rotação das imagens para fornecer a versão espelhada horizontal. Outras inclusões importantes, como a avaliação do modelo sob condições de baixa visibilidade ou variações de escala, serão abordadas em trabalhos futuros para garantir reprodutibilidade e robustez. O conjunto de dados considerado para o treinamento deve incluir imagens de pedestres em várias poses, e também deve conter imagens que não tenham^{pedestres 18,19}.

Outro passo crítico é criar o diagrama de blocos para todo o sistema, de modo que a parte PS da placa FPGA possa se comunicar com a parte PL. Nessa etapa, é necessário garantir que cada bloco esteja parametrizado com as portas corretas e que esteja conectado corretamente aos outros blocos. A ferramenta também oferece roteamento automático com sugestões para auxiliar o projetista. Uma etapa muito crucial é a atribuição de endereços após completar o diagrama de blocos. Os IPs HoG importados precisam receber endereços atribuídos conforme sua profundidade, e esses endereços não devem ser iguais para quaisquer dois IPs. Esses endereços são necessários no código Python do cartão SD, o que ajudará a parte PS da placa FPGA a entender a localização de endereços no PL que ela precisa acessar para ler/escrever os dados. Assim, o passo desafiador é o desenvolvimento da interface na plataforma Python, que permite ao usuário enviar as imagens de entrada/vídeos/transmissão ao vivo da câmera para o FPGA, e exibir a imagem de saída com os pedestres detectados após receber as imagens processadas pelo FPGA. O código Python precisa ser escrito com várias mensagens de depuração para que os resultados intermediários possam ser visualizados pelo projetista e, em caso de falhas, os erros possam ser diagnosticados e corrigidos. Uma enorme quantidade de tempo foi dedicada a essa pesquisa para estabelecer uma interface adequada entre a parte PS e a PL. O script Python dessa interface conseguia acessar os dados dos IPs HoG após várias iterações, e a inclusão de várias instruções para exibir os resultados intermediários era muito útil na resolução de problemas e correção dos erros.

Uma limitação observada do método é a utilização da parte em python para estabelecer a interface entre a parte PS e a parte PL do FPGA. Embora a plataforma Python tenha reduzido drasticamente o tempo de design, isso introduz custos adicionais que impactam o desempenho em tempo real. O sistema acelerado por hardware de detecção de pedestres reportou uma taxa de transferência de 83 FPS, mas o desempenho geral do sistema foi afetado devido à latência ou ficou sem resposta durante os testes de câmera ao vivo devido a atrasos causados pela transferência de dados entre o PS e a parte PL. A perspectiva futura oferece a possibilidade de desenvolver um sistema completo acelerado por hardware, sem dependência de software.

Embora existam limitações descritas acima, a pesquisa contribui significativamente, pois o sistema desenvolvido pode ser adaptado perfeitamente para detecção de pedestres em imagens estáticas, transmissões ao vivo ou entradas de vídeo. Todos os três métodos requerem apenas pequenas modificações no código Python na plataforma Jupyter, demonstrando a rápida adaptabilidade do sistema a vários cenários. Os resultados indicam que a implementação nas arquiteturas avançadas de FPGA gera resultados encorajadores, pois os parâmetros de desempenho são altamente otimizados, resultando em valores bons e aceitáveis. A frequência de clock alcançada é comparável à literatura^anterior 14,15,16,20,23, indicando que a velocidade não é comprometida, enquanto o consumo mínimo de energia sugere que não há problemas de aquecimento. Além disso, a utilização de recursos mostra que todos os recursos são utilizados em menos de 50 %, indicando potencial significativo para melhorias adicionais no projeto.

O sistema desenvolvido pode ser utilizado em qualquer aplicação que exija a tarefa de detectar humanos e pode ser adaptado para aplicações em tempo real. Além disso, esforços futuros podem se concentrar em remover as limitações mencionadas, desenvolvendo todo o sistema, seja completamente na parte PL, fazendo com que a lógica do FPGA leia as imagens de entrada e exiba as imagens processadas de saída, já que quase 50% dos recursos internos ainda estão disponíveis. Além disso, se a integração PS e PL for utilizada, o desenvolvimento de interface por meio de ferramentas de Software Development Kit (SDK) pode ser realizado. Outras possíveis extensões podem ser identificar pedestres em condições climáticas significativamente mais rigorosas ou durante baixa visibilidade, ou identificar pedestres ocluídos que estão escondidos atrás de outros objetos, exigindo modificações no algoritmo. A única modificação necessária nesses casos seria substituir os pesos treinados pelo SVM após o treinamento adequado de acordo com o desafio selecionado, e o restante do sistema não requer outras modificações. Assim, o sistema implementado é bem adequado para se adaptar facilmente a outros cenários desafiadores. Outra perspectiva futura pode ser focar em incorporar recursos adicionais ao sistema para criar um veículo totalmente autônomo usando a avançada placa FPGA.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
Python	Python	Versão 3.10
Placa FPGA Ultra 96 V2	Xilinx	Introduzido em 2018	Plataforma de Implementação de Hardware usada para implementar o algoritmo de detecção de pedestres
Vivado	AMD	2019.2	Ferramenta de programação FPGA usada para programar a placa FPGA Ultra 96 v2 com o algoritmo de detecção de pedestres
Vivado HLS	AMD	2019.2	Ferramenta de Síntese de Alto Nível usada para programação de alto nível do código de detecção de pedestres no artigo para exportar a Propriedade Intelectual (PI)