Progettazione e implementazione di un framework di rilevamento pedoni basato su gate array programmabile sul campo per applicazioni di guida autonoma

Summary

Questo articolo di ricerca dimostra l'implementazione di un algoritmo di rilevamento pedoni in tempo reale su hardware di gate array programmabile sul campo, principalmente per applicazioni di guida autonoma. L'algoritmo combina l'istogramma dei gradienti orientati (HoG) con un classificatore di macchina a vettori di supporto (SVM), e i risultati mostrano efficienza in termini di velocità, consumo energetico e utilizzo delle risorse.

Abstract

La guida autonoma offre un modo promettente per affrontare il crescente numero di decessi causati da incidenti stradali. Un veicolo autonomo include molte funzionalità, ma la capacità di rilevare i pedoni è cruciale, impegnativa e rilevante per varie situazioni in tempo reale come la sorveglianza, il tracciamento delle persone e il monitoraggio. Identificare accuratamente i pedoni è difficile perché possono apparire in diverse forme, posizioni e posturizzazioni. Possono indossare vari tipi di abbigliamento e a volte essere parzialmente nascosti o mimetizzarsi con oggetti vicini. Questo articolo si concentra sul rilevamento in tempo reale dei pedoni per auto a guida autonoma utilizzando una piattaforma hardware molto popolare: il field programmable gate array (FPGA), Ultra 96 v2. Lo studio implementa un metodo per il rilevamento dei pedoni basato su un istogramma di gradienti orientati (HOG) combinato con un classificatore di macchina a vettori di supporto (SVM) per riconoscere gli individui sulla scheda FPGA, sfruttando strumenti di sintesi ad alto livello (HLS). L'efficacia del sistema è stata testata sia su immagini fisse che su video in diretta. I risultati mostrano che schede FPGA avanzate come l'Ultra 96 v2 migliorano significativamente le metriche di prestazione. Il sistema opera a una frequenza di clock di 150 MHz utilizzando meno della metà delle risorse disponibili e consumando circa 2,5 W di energia. Inoltre, il sistema riporta la precisione della rilevazione dei pedoni vicina al 95% e altre metriche efficienti per la valutazione del rilevamento, come la precisione (78,6%), il richiamo (88,3%) e il punteggio F1 (83,1%). In sintesi, il sistema sviluppato può rilevare i pedoni in tempo reale e ha il potenziale di migliorare significativamente lo sviluppo di un ambiente di trasporto intelligente e sicuro.

Introduction

Lo sviluppo urbano e l'emergere delle smart city sono argomenti di interesse in tutto il mondo. Tutte le nazioni stanno lavorando per lo sviluppo delle loro città che possano essere costruite in modo da essere sicure e confortevoli per le persone che vi^{vivono 1,2}. Ma nella situazione attuale è stato osservato che, con la crescita della popolazione e l'aumento della congestione stradale, il tasso di decessi dovuti a incidenti stradali dovuti a negligenza alla guida e problemi di scarsa visibilità sta aumentando in modo allarmante. Una soluzione promettente a questi problemi è l'emergere di veicoli autonomi in tutto il mondo, che ha dato origine all'innovazione 1,2,3,4 e i ricercatori stanno facendo sforzi per sviluppare veicoli completamente autonomi che permettano ai passeggeri di rilassarsi senza preoccupazioni. La necessità di sviluppare veicoli autonomi deriva dal fatto che anche i conducenti esperti possono affrontare stress, dilemmi, fatica o difficoltà a percepire l'ambiente a causa del maltempo, e tutti questi problemi portano a incidenti stradali. Un veicolo a guida autonoma è progettato per evitare incidenti durante il viaggio, ottimizzare l'uso delle risorse del motore e rispettare le leggi sul traffico, il che senza dubbio migliorerà i^{trasporti 2,4}. Un veicolo autonomo è dotato di molteplici caratteristiche, sensori e funzionalità che gli permettono di percepire l'ambiente circostante con grande precisione, evitando collisioni e incidenti, e perciò si sono ora rivelati una soluzione promettente per rendere il trasporto sicuro ^{e protetto} 1,2,3,4.

Tra tutte le funzionalità incorporate in un veicolo autonomo, una delle più importanti è il rilevamento dei pedoni. Un sistema robusto di rilevamento pedoni può aiutare significativamente a ridurre le fatalità in incidenti^stradali 5,6,7,8, poiché la maggior parte delle victime di questi incidenti sono pedoni. Il rilevamento dei pedoni consiste nell'identificare le persone sulla strada ed evitare collisioni con loro. Questa funzione è vantaggiosa non solo per le auto a guida autonoma, ma anche per varie altre aree applicative come il monitoraggio delle folle, l'identificazione delle persone e il tracciamento^{9, 10, 11}. L'aspetto chiave di questo processo di rilevamento è la velocità e la precisione del rilevamento. È fondamentale rilevare i pedoni con precisione e rapidità affinché i tempi di risposta siano minimi. La rilevazione dei pedoni rappresenta una sfida enorme. I pedoni sulla strada possono indossare qualsiasi abbigliamento, aspetto o postura, e possono essere invisibili a causa del maltempo o dell'occlusione 10,11,12,13,14. Inoltre, è del tutto possibile che i pedoni non seguano le regole da sé e non si possa controllare la natura umana, quindi il miglior approccio possibile è dotare il veicolo dell'intelligenza necessaria per gestire qualsiasi azione sbagliata ed evitare le vittime. Il flusso completo del lavoro in questa ricerca e la motivazione dietro l'implementazione hardware del rilevamento pedonale possono essere facilmente compresi dalla Figura 1 qui sotto, che spiega la necessità del rilevamento pedonale, le sue varie aree di applicazione, le sfide coinvolte e l'implementazione su un FPGA per sfruttare i benefici offerti.

Figura 1: Rilevamento dei pedoni. La necessità di rilevamento pedonale, le principali aree di applicazione del rilevamento pedonale, le sfide coinvolte nel rilevamento pedonale e il flusso di implementazione del rilevamento pedonale su una scheda FPGA. Clicca qui per visualizzare una versione più grande di questa figura.

Per identificare i pedoni sulla strada esistono numerosi algoritmi. Questo compito complessivo può essere principalmente suddiviso in due sottocompiti principali: il primo passaggio estrae caratteristiche da un'immagine di input, mantenendo solo quelle significative e che trasmettono informazioni rilevanti, ignorando quelle ridondanti. Per un riconoscimento efficace di umani o pedoni in un'immagine, è fondamentale che queste caratteristiche indichino la presenza di una figura umana all'interno della scena^13,14. Dopo questa estrazione, le caratteristiche devono essere inviate a un classificatore che possa determinare se le caratteristiche identificate corrispondono a un essere umano. Pertanto, l'algoritmo richiede una fase di estrazione e descrizione delle caratteristiche, seguita da un passaggio di classificazione per determinare la presenza dei pedoni nella scena di input. Esistono vari algoritmi disponibili a questo scopo. Tuttavia, il metodo più accettato per il rilevamento dei pedoni ad oggi rimane la combinazione dell'istogramma dei gradienti orientati (HoG) con il classificatore della macchina a vettori di supporto (^{SVM) 12,13,14,15}. Esistono numerosi esempi di progressi software, ma in definitiva l'obiettivo è portare l'implementazione su una piattaforma hardware compatibile, che possa poi essere integrata nel sistema applicativo per l'uso in tempo reale. Pertanto, l'attuale enfasi è sulla realizzazione hardware. Si può quindi affermare che è necessario sviluppare un'implementazione hardware adeguata dei sistemi di rilevamento pedonale, in cui telecamere dotate di hardware appropriato possano essere installate sui veicoli e identificare i pedoni sulla strada. Quando si valuta quale hardware sia appropriato per tali implementazioni, una delle opzioni più comunemente utilizzate è l'array di gate programmabile sul campo (FPGA) grazie ai suoi numerosi vantaggi, tra cui riduzione dei tempi di progettazione, scalabilità, facilità di modifiche, riconfigurabilità e minore consumo energetico^{e energetico 15,16,17,18,19,20,21.22}.

Le schede FPGA si sono evolute costantemente e sono ora ampiamente utilizzate per applicazioni complesse e avanzate di visione artificiale che spaziano dall'elaborazione di immagini di base al rilevamento di oggetti, alla realtà aumentata e al deep^{learning 20, 21, 22.} Attualmente, diverse schede FPGA ad alte prestazioni offrono capacità architettoniche eccezionali per gestire l'ampia elaborazione richiesta per queste applicazioni complesse. Se le funzionalità avanzate dei veicoli autonomi, come il rilevamento pedonale, sono implementate su tali piattaforme hardware, queste piattaforme possono essere molto utili per lo sviluppo rapido di prototipi per analizzare le prestazioni e, dopo l'ottimizzazione, l'algoritmo implementato può essere trasferito ai circuiti integrati veri e propri per l'integrazione nel sistema.

Da oltre un decennio sono state pubblicate importanti basate sull'implementazione del rilevamento pedonale tramite i metodi HoG e SVM su diverse piattaforme FPGA. La Tabella 1 riassume gli articoli in questo campo nel periodo 2015–2025 15,16,17,18,19,20,21,22,23,24, concentrandosi sui fattori chiave come la risoluzione dell'immagine, la velocità di rendimento o i fotogrammi al secondo (FPS), il tipo di classificatore e i principali punti salienti o i contributi apportati dal carta.

Riferimento	Piattaforma FPGA	Risoluzione dell'immagine	Classificatore	Punti salienti / Contributi
15	Xilinx Zynq	640×480	AdaBoost	Implementazione FPGA in tempo reale; efficiente in termini di risorse; usa la binarizzazione per l'ottimizzazione; Buona accuratezza nella rilevazione.
16	Scheda DE1-SOC di Terasic	640×480	SVM	Estrattore HOG ad alte prestazioni; integra SVM; rilevamento a scala singola; Pipeline a bassa latenza.
17	Altera DE2-115	640×480	AdaBoost	Valuta le prestazioni da più punti di vista; Implementazione FPGA di HOG+AdaBoost; Rilevamento pedonale in tempo reale.
18	Intel Stratix V	640×480	SVM	Rilevamento pedonale su scala multipla; pipeline HOG+SVM compatibile con FPGA; evidenzia i compromessi tra accuratezza ed efficienza hardware.
19	Zynq UltraScale+ MPSoC	3840×2160	SVM	Elaborazione UHD in tempo reale; HOG+SVM pipelined; Implementazione SoC FPGA; ottimizzazione del punto fisso; architettura scalabile.
20	Non specificato	Non specificato	SVM	Raggiunge una precisione di rilevamento del >95%; implementazione FPGA in tempo reale; sfrutta il parallelismo; progettazione dettagliata di FPGA HOG+SVM per il rilevamento dei pedoni.
21	Zync 7000 FPGA	1920×1080	SVM	Architettura a flusso ad alta produttività per HOG+SVM; supporta la risoluzione HD; efficiente pipeline per l'accelerazione FPGA.
22	Ultra96 (rev1)	240×320	SVM	implementazione FPGA tramite HLS; rileva semafori rossi; calcola probabilità in 891 regioni; La latenza varia da 153.838 a 19 cicli.
23	Xilinx Zynq-7000 FPGA	640 × 480	HOG + SVM	Ha implementato il rilevamento dei pedoni usando HOG-SVM su FPGA, ottenendo prestazioni in tempo reale con un consumo energetico ridotto rispetto all'elaborazione CPU. Ha dimostrato una pipeline ottimizzata di estrazione delle funzionalità adatta ad applicazioni di visione embedded.
24	Xilinx Virtex-6 FPGA	640 × 480	Rivelatore di oggetti a punto fisso (caratteristiche simili a Haar)	Proposta un'accelerazione FPGA ad alto rendimento del rilevamento degli oggetti tramite aritmetica a punto fisso, riducendo i costi computazionali mantenendo l'accuratezza. Ha mostrato un aumento di velocità del 15× rispetto alle implementazioni CPU con un utilizzo efficiente delle risorse hardware.

Tabella 1: Revisione della letteratura della ricerca basata sul rilevamento dei pedoni su FPGA (2015–2025).

La Tabella 1 riassume che esiste una vasta letteratura nel campo della rilevazione dei pedoni, e l'implementazione hardware è l'area di interesse per i ricercatori. È anche evidente che esistono tecniche avanzate di deep learning e machine learning, come rivelatori basati su reti neurali convoluzionali (CNN) come YOLO, architetture basate su trasformatori, ecc., per il compito di rilevamento dei pedoni. Sono persino superiori rispetto all'algoritmo HoG tradizionale in termini di accuratezza, ma considerando l'implementazione hardware, gli algoritmi avanzati portano a un enorme utilizzo delle risorse^23,24 a causa delle complessità dell'algoritmo che possono influenzare anche altri parametri di prestazione; è stato anche osservato che, a causa delle complessità aggiunte, la velocità è leggermente migliore nel caso dell'algoritmo HoG^{tradizionale 24, 25}. È stato inoltre osservato che le tecniche avanzate consumano più energia quando implementate su hardware^24,26. Pertanto, l'obiettivo del lavoro implementato in questo articolo è eseguire il rilevamento dei pedoni utilizzando il tradizionale framework HoG e SVM su hardware FPGA e ottenere un compromesso favorevole tra precisione-velocità-risorse e potenza per l'embedding in tempo reale. Dalla Tabella 1 è abbastanza chiaro che, analizzando il lavoro basato su HoG e SVM, si osserva che ci sono pubblicazioni limitate che hanno utilizzato la recentemente introdotta scheda di sviluppo FPGA basata su Zynq UltraScale+ (Multi-Processor System On Chip) basata su^{FPGA board 27} per esplorare le capacità di queste schede, poiché dal punto di vista dell'architettura queste schede si sono evolute, e offrono un grande potenziale in termini di implementazione di applicazioni di computer vision in tempo reale di alto livello. Ci sono poche pubblicazioni che hanno realizzato l'intero sistema di rilevamento pedoni in tempo reale sulle schede FPGA. Tuttavia, si sono concentrati sull'implementazione efficiente o sul miglioramento dei compiti intermedi. Inoltre, la maggior parte di queste implementazioni si basa sulla realizzazione dell'intero sistema su una scheda FPGA tramite l'uso di linguaggi di descrizione hardware. Pochi hanno sfruttato i vantaggi degli strumenti di sintesi ad alto livello (HLS) per accelerare il ciclo di progettazione. Questo articolo dimostra la progettazione e l'implementazione del rilevamento pedonale in tempo reale su una scheda FPGA dedicata a un'applicazione di guida autonoma. L'articolo utilizza il framework HoG e SVM allo scopo della rilevazione pedonale su immagini statiche, video o input reali della telecamera. L'hardware utilizzato è una scheda FPGA all'avanguardia e recentemente rilasciata, l'Ultra96 v2, che è un'architettura FPGA avanzata che rappresenta una potente piattaforma per la visione artificiale, l'elaborazione delle immagini, il machine learning, l'edge computing, ^ecc.24. L'Ultra96 v2 è una scheda di sviluppo dotata di un AMD Xilinx Zynq UltraScale+^{MPSoC 27} basato su Arm. Questa scheda include il segmento di sistema di elaborazione (PS), che consiste in core CPU basati su ARM che gestiscono gli aspetti software del progetto, e il segmento Programmable Logic (PL) che consente accelerazioni hardware^{personalizzabili} 20,21,22. Insieme, questi componenti migliorano la funzionalità di un sistema ibrido, dove la parte PS gestisce il controllo e l'interazione con elementi esterni, mentre la parte PL gestisce la logica di elaborazione effettiva.

Protocol

La procedura di implementazione utilizzata in questa ricerca, basata sul rilevamento pedonale con HoG + SVM su una scheda FPGA, sfruttando i vantaggi della sintesi ad alto livello, è illustrata nella Figura 2 qui sotto.

Figura 2: Procedura di progettazione per l'implementazione del rilevamento pedoni sulla scheda FPGA. Fase 1: Algoritmo di rilevamento pedoni usando HoG+SVM sullo strumento HLS e generazione del blocco IP. Fase 2: Algoritmo di rilevamento pedoni usando HoG+SVM per l'implementazione effettiva dell'FPGA e la generazione del file bit. Fase 3: Programmazione della scheda con il file di bit generato. Clicca qui per visualizzare una versione più grande di questa figura.

1. Rilevamento pedoni usando HoG e SVM sullo strumento HLS

1. Scarica l'Ambiente di Sviluppo Integrato Python (IDE) a seconda delle proprietà del sistema su cui viene effettuato il download.
   NOTA: In questo lavoro viene utilizzata la versione Python 3.10.
2. Esegui uno script Python per eseguire un modello di addestramento utilizzando l'algoritmo HoG e il classificatore SVM. Inizia lo script caricando i campioni positivi e negativi dal dataset.
   NOTA: Usa il dataset^{INRIA 11}.
3. Estrai le caratteristiche HoG per una finestra di 64 x 128.
4. Dividere i dati di addestramento e di test dal dataset INRIA in un rapporto 80/20 con un mescolare casuale per la riproducibilità.
   NOTA: Il dataset viene mescolato casualmente usando la funzione python prima di suddividere i dati. Per garantire la riproducibilità in modo che la stessa divisione venga fatta ogni volta che un valore seed viene fissato nel codice.
5. Addestrare utilizzando la SVM di classificazione vettoriale a supporto C (SVC) con un kernel lineare.
6. Estrai i vettori di peso e il bias.
7. Salva i pesi SVM e il bias nel formato Q8.8 a punto fisso per l'implementazione FPGA.
   NOTA: La conversione avviene scalando ogni valore in virgola mobile con l'originalità generata da un fattore 256 (2⁸) e convertendo il risultato in un intero.
8. Testare il modello addestrato tramite un altro script Python e regolare il parametro di regolarizzazione C, finché l'accuratezza non sarà calcolata superiore al 95%.
   NOTA: Parametro di regolarizzazione ottimizzato ottenuto: C = 0,05.
9. Apri lo strumento HLS e crea un nuovo progetto con il numero di parte selezionato come xczu3eg-sbva484-1-e.
10. Scrivi un codice di rilevamento pedoni sullo strumento di sintesi di alto livello usando linguaggi di alto livello come C++.
11. Nel codice, scrivi tre script C++ diversi: uno per il descrittore di caratteristiche HoG e il classificatore SVM, un altro per il testbench per fornire input alle immagini di test e salvare le immagini di output, e il terzo per un file header che dichiara i parametri usati nel codice.
12. Nel codice per il calcolo delle caratteristiche HoG, ridimensionare l'immagine a 640 x 480 e applicare un'architettura a finestra scorrevole con una dimensione di 64 x 128. Per ogni finestra, calcola la magnitudine e l'orientamento del gradiente per ogni blocco 8 x 8 sovrapposto.
    NOTA: È importante scansionare l'intera immagine attraverso il concetto di finestra scorrevole, così che ogni area dell'immagine sia coperta e che i pedoni di ogni dimensione possibili vengano identificati.
13. Nell'altra parte dello stesso codice per il descrittore di caratteristiche HoG, passa i gradienti calcolati al classificatore SVM. Scrivi il codice per abbinare le caratteristiche ai pesi del classificatore e confronta con la soglia per classificare la caratteristica rilevata come quella di un essere umano o meno.
14. Clicca su Esegui Simulazione C nello strumento HLS per simulare il codice con l'aiuto di un banco di prova per verificare la correttezza funzionale del codice.
15. Fornisci immagini di input diverse al codice e controlla le immagini di output con i pedoni rilevati.
16. Clicca su Esegui Sintesi C per sintetizzare il codice e mappare il codice ai linguaggi hardware tramite lo strumento e generare i report di tempistica e utilizzo.
    NOTA: Lo strumento apre automaticamente i report di sintesi HLS. Questo rapporto mostra la stima della frequenza di clock richiesta per implementare il compito codificato su una piattaforma FPGA selezionata, e fornisce anche una stima delle risorse utilizzate. Questi valori riportati sono solo stime e i parametri effettivi vengono calcolati solo dopo l'implementazione sulla scheda FPGA.
17. Clicca su Esporta RTL per esportare il blocco di Proprietà Intellettuale (IP) per l'algoritmo HoG di rilevamento pedonale.
    NOTA: Questa IP deve essere utilizzata nelle fasi successive dell'implementazione.

2. Programmazione della scheda FPGA

1. Apri lo strumento per la programmazione FPGA e crea un nuovo progetto. Seleziona il numero di parte come xczu3eg-sbva484-1-e e crea un nuovo design a blocchi.
   NOTA: Questo diagramma a blocchi è stato creato per stabilire l'integrazione tra la parte PS e la parte PL della scheda FPGA. Il protocollo di comunicazione utilizzato è il protocollo Advanced eXtensible Interface (AXI).
2. Cerca il Catalogo IP nello strumento e, una volta trovato, aprilo.
3. Crea un repository utente aggiungendo il percorso dell'IP RTL esportato nello step 1.17.
4. Nella nuova finestra di design dei blocchi , ora clicca con il tasto destro e seleziona aggiungi IP. Tutti gli IP saranno visibili, inclusi quelli forniti dallo strumento e i repository aggiunti dall'utente.
5. Aggiungi il blocco PS Zync Ultrascale dal repository.
   NOTA: Questo blocco riflette la parte PS del sistema, responsabile della generazione dei clock richiesti, e ha anche le porte master e slave per la connessione all'IP importato HoG tramite il blocco interconnessione AXI, che funziona sui fondamenti del protocollo AXI.
6. Aggiungi 8 IP HoG perché il sistema elaborerà 8 finestre simultaneamente per sfruttare il vantaggio del parallelismo offerto dalla scheda FPGA.
7. Aggiungi un blocco di reset del sistema del processore , che controlla anche il clock e il reset degli alimentatori a ogni singolo blocco nel diagramma.
8. Aggiungi due blocchi axi_smart connect per collegare gli IP HoG con il blocco Zync PS. L'intero schema a blocchi con le connessioni complete è mostrato nella Figura 3.
   NOTA: Come mostrato nella Figura 3, tutti i blocchi che devono essere aggiunti al progetto sono stati mostrati chiaramente. La Figura 3 è catturata dallo strumento e mostra le porte interne di ogni blocco così come le interconnessioni tra le porte dei diversi blocchi. Questo blocco è il progetto principale poiché è responsabile dell'interfaccia tra la PS e la parte PL della scheda FPGA.
9. Dopo aver completato le connessioni come in Figura 3, clicca su valida design.
   NOTA: La validazione controlla fondamentalmente le connessioni mancanti o rotte, che possono portare a problemi nelle fasi successive.
10. Clicca su sintesi e poi Implementa progettazione nel tool dopo che la validazione del diagramma a blocchi è stata riuscita a verificare.
    NOTA: Synthesis mappa il diagramma a blocchi progettato e lo mappa sulla scheda FPGA. Questo passaggio segnala eventuali violazioni che possano indicare che il design non può essere implementato sull'hardware.
11. Lo strumento genererà anche report relativi a tempistiche, utilizzo delle risorse e consumo energetico. Esamina attentamente i report per verificare eventuali violazioni dei tempi e analizza le prestazioni del sistema progettato.
12. Clicca su Genera il file bitstream che genererà il file .bit necessario per programmare la scheda FPGA.

Figura 3: Diagramma a blocchi per il rilevamento pedonale usando IP importati HoG + SVM. Clicca qui per visualizzare una versione più grande di questa figura.

3. Implementazione finale sulla scheda FPGA

1. Prendi la scheda FPGA e inserisci la scheda SD con il file immagine corretto nello slot della scheda.
2. Collega anche la scheda al computer.
3. Avvia la scheda FPGA in modalità scheda SD per abilitare la programmazione in Python^21,22.
4. Accedi alla piattaforma Jupyter sulla scheda dopo averla collegata al wifi.
5. Collega una webcamera alla scheda.
6. Scrivi un codice Python per importare il bit file generato e svolgi il compito di accedere alle immagini della telecamera.
7. Nel codice, scrivi lo script in modo che l'immagine venga scritta nella memoria della scheda FPGA tramite la parte PS e passata alla parte PL per l'elaborazione.
   NOTA: La parte PL della scheda che corrisponde agli IP HoG accede ai pixel immagine attraverso queste posizioni di memoria, li elabora e fornisce i punteggi come output.
8. Scrivi codice appropriato nello stesso script Python per leggere le immagini elaborate e mostrarle sullo schermo del computer.
   NOTA: Questo completa l'intero progetto e il sistema è ora pronto per il dispiegamento in applicazioni reali. Tutti i codici utilizzati in questo studio sono caricati come file di codifica supplementare (File Supplementare 1 [Script_1_train_test.py], File Supplementare 2 [Script_2_HLS_hog.cpp], File Supplementare 3 [Script_3_HLS_test_bench.cpp], File Supplementare 4 [Script_4_HLS_consts.h], File Supplementare 5 [Script_5_jupyter_code.txt]).

Results

Implementazione del rilevamento pedonale su HLS
La Figura 4 mostra i risultati della simulazione sullo strumento HLS per il rilevamento pedonale usando HoG + SVM. Un'immagine di input con un pedone viene fornita come input di prova al codice e viene visualizzata l'uscita con i pedoni rilevati. Ci sono due sezioni nell'immagine. La prima rilevazione mostra molte caselle di delimitazione attorno allo stesso pedone più e più volte, e nella seconda immagine le caselle sovrapposte vengono rimosse e soppresse, lasciando solo le caselle principali di rilevamento.

Figura 4: Risultato della simulazione dallo strumento HLS. (A,B) Due immagini di input diverse e le immagini risultanti con i pedoni rilevati. Clicca qui per visualizzare una versione più grande di questa figura.

Lo strumento HLS fornisce anche rapporti di sintesi per la tempistica e l'utilizzo delle risorse. Il riassunto temporale evidenzia il periodo di tempo richiesto dal progetto e fornisce i valori di latenza massimo e minimo in termini di numero di cicli. Queste informazioni sono utili per stimare quanto tempo richiede il progetto per essere eseguito e quale dovrebbe essere la frequenza di clock quando si passa all'implementazione hardware effettiva. La Tabella 2 sottostante mostra il rapporto temporale dopo la sintesi HLS, che mostra chiaramente che il periodo di clock target era di 6 ns e il progetto richiedeva 5,25 ns, che è meno del target, e quindi il periodo di tempo può essere di 6ns o superiore ma non inferiore a 5 ns.

Riepilogo dei tempi
Orologio	Bersaglio	Sttime
	6,00 ns	5.250 ns
Riepilogo dell'utilizzo
	Totale / Disponibile	Percentuale di utilizzo
BRAM18K	22 / 432	5%
DSP48E	13 / 360	3%
FF	5611/ 141120	3%
LUT	9904/ 70560	14%
URAM	0	0

Tabella 2: Stima del rapporto di tempistica e utilizzo delle risorse dallo strumento HLS per il rilevamento pedonale tramite HoG-SVM.

La Tabella 2 mostra anche il rapporto di utilizzo. Mostra la percentuale di utilizzo delle importanti risorse FPGA a bordo in base alla scheda target selezionata. Per questo progetto di rilevamento pedonale, il rapporto di utilizzo mostra che il progetto consuma il 14% delle tabelle di ricerca (LUT), il 3% dei Flip Flop (FF), il 3% dell'elaborazione digitale del segnale (DSP) e il 5% della memoria a blocchi di accesso casuale (BRAM). Queste stime non sono i rapporti di utilizzo esatti, ma i rapporti effettivi sono vicini a queste stime. Queste sono solo le stime che possono essere calcolate dagli strumenti HLS. L'implementazione effettiva è solitamente molto diversa da queste stime.

L'implementazione effettiva risulta dalla programmazione hardware
Dopo che il codice è stato mappato in un IP, che viene importato dallo strumento di programmazione FPGA, e il design implementato sull'hardware FPGA vero e proprio, vengono generati anche diversi report. Il primo è il riassunto del tempo, che mostra se la frequenza di clock fornita al progetto è sufficiente o meno. Se tutti i vincoli temporali sono soddisfatti e non ci sono violazioni, allora il progetto può procedere. La Tabella 3 qui sotto mostra il riepilogo dei tempi generato dallo strumento. Come mostrato nella tabella, il riepilogo temporale indica il peggior margine negativo, ovvero 4,073 ns. Poiché questo valore è positivo, indica che questo tempo è ancora disponibile. I valori negativi indicano che l'FPGA impiega più tempo per completare il compito e il clock scorre velocemente. Poiché in questo caso non ci sono valori negativi, il che significa che i vincoli temporali sono soddisfatti.

Riepilogo dei tempi del progetto
Configurazione	Fermati	Larghezza dell'impulso
Peggiore Negative Slack 4.073 ns	Peggior Mantenimento Scarico 0,010 ns	Peggiore larghezza d'impulso: Slack 3.500 ns

Tabella 3: Riepilogo effettivo dei tempi per il rilevamento pedoni sulla scheda FPGA.

Inoltre, lo strumento mostra i report di utilizzo delle risorse, che rappresentano l'effettivo utilizzo delle risorse a bordo secondo la scheda FPGA selezionata. In questo caso, la scheda selezionata è la scheda di sviluppo FPGA²⁷ basata su Zynq UltraScale+ MPSoC (Multi-Processor System On Chip). La Tabella 4 qui sotto mostra l'utilizzo delle risorse e la Figura 5 mostra la rappresentazione diagrammatica dell'utilizzo delle risorse.

Il riepilogo dell'utilizzo indica il consumo effettivo delle risorse a bordo, dato che vengono utilizzati in parallelo 8 IP HoG, e le stime riportate dalla sintesi HLS erano per un singolo IP HoG. Ma anche dopo un uso così esteso, l'utilizzo delle risorse per ogni risorsa è inferiore al 50%. La Tabella 4 indica chiaramente l'utilizzo rispetto alle varie risorse e la loro percentuale di utilizzo, rappresentata in modo illustrato nella Figura 5.

Risorsa	Utilizzo	Disponibile	Percentuale di utilizzo
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%

Tabella 4: Rapporto effettivo di utilizzo per il rilevamento dei pedoni sulla scheda FPGA.

Figura 5: Utilizzo delle risorse per il rilevamento pedoni sulla scheda FPGA dopo l'effettiva implementazione. Consulta le tabelle (LUT): 57%, LUTRAM: 25%, Flip flop (FF): 24%, RAM a blocchi (BRAM): 31%, Digital signal processors (DSP): 36%, Buffer: 1%. Clicca qui per visualizzare una versione più grande di questa figura.

Il terzo rapporto riguarda le stime di potenza della scheda per la quantità di consumo energetico del progetto. La Figura 6 qui sotto mostra il rapporto sui consumi energetici, che mostra che la potenza totale sul chip è di 2,435 W. Sono inoltre mostrate la temperatura della giunzione e l'energia consumata da ogni rete e componente importante. Le misurazioni di potenza non evidenziano alcun consumo allarmante e quindi il progetto può essere considerato efficiente dal punto di vista energetico.

Figura 6: stima della potenza per il rilevamento pedoni sulla scheda FPGA dopo l'implementazione effettiva. Il rapporto di potenza generato dagli strumenti mostra la potenza totale consumata come 2,435 W e mostra anche la distribuzione della potenza tra le varie risorse sulla scheda FPGA. Clicca qui per visualizzare una versione più grande di questa figura.

Un'altra analisi viene effettuata per comprendere il vantaggio di utilizzare 8 IP HoG invece di un singolo IP HoG o più di 8 nel diagramma a blocchi creato, come mostrato nella Figura 3. Le metriche di prestazione hardware sono state calcolate sia per un singolo IP HoG sia per 8 IP HoG in parallelo. La Tabella 5 qui sotto mostra il confronto.

Metrica di Performanze	1 IP	8 IP
Tempismo (ns)	5.312	~5.25
Frequenza (MHz)	188	150
Potenza (W)	1.9	2.43
LUT	4998	40536
FF / Registri	4,031	33,342
DSP	16	128
BRAM	8.5	68
FPS	~10–11	83

Tabella 5: Confronto delle metriche di performance usando IP HoG singoli e multipli.

La Tabella 5 indica chiaramente che, considerando le risorse come LUT, FF, DSP e BRAM, con un singolo IP HoG e 8 IP HoG, la scalabilità è lineare con un aumento di quasi 8 volte delle risorse utilizzate. Questo è chiaramente prevedibile, poiché più IP porteranno a un consumo maggiore di risorse. Inoltre, se la frequenza viene osservata, allora la frequenza massima si degrada leggermente del 20% da 188 MHz a 150 MHz. Questo è prevedibile, poiché più blocchi portano a più connessioni e quindi a percorsi più lunghi, causando un aumento dei percorsi critici. Ma i fattori vantaggiosi come i frame per secondo (FPS) migliorano da 10 a 83, dimostrando una scalatura non lineare nel caso degli FPS grazie al concetto introdotto di parallelismo, dovuto a 8 IP HoG. Inoltre, la potenza varia da 1,9 W a 2,4 W, indicando un miglioramento dell'efficienza energetica grazie alla tubazione. Pertanto, questa analisi indica chiaramente che l'introduzione di 8 IP HoG è vantaggiosa per il design, e la scalabilità oltre 8 può causare un sovraconsumo di risorse; quindi, il numero di blocchi oltre 8 non è considerato favorevole.

Risultati del rilevamento pedoni dopo l'implementazione dell'FPGA
Infine, l'intero sistema è integrato sulla scheda FPGA e viene generato il file bitstream, che viene poi programmato sulla scheda tramite la scheda SD avviata con la capacità di programmabilità Python. Una volta avviata la scheda con la scheda SD, l'interfaccia jupyter può essere accessibile e il codice Python può essere scritto ed eseguito sulla piattaforma. Il codice Python viene eseguito e testato per il rilevamento dei pedoni su diverse immagini di input. Il risultato di alcune immagini è mostrato nella Figura 7 qui sotto. Queste immagini sono utilizzate dal dataset INRIA così come da immagini casuali di pedoni ottenute da fonti online^{open source 26,27}.

Figura 7: Risultati del rilevamento pedoni su immagini statiche tramite FPGA Board. Le immagini testate includono immagini dal dataset INRIA, immagini open source disponibili su Google per verificare l'accuratezza della rilevazione nelle strade affollate dell'India. Clicca qui per visualizzare una versione più grande di questa figura.

Il sistema viene inoltre testato sulla cattura in tempo reale tramite una webcam e sulla rilevazione dei pedoni presenti nell'inquadratura, oltre a essere testato su input video già registrati dei pedoni. I risultati sono raffigurati nella Figura 8 e nella Figura 9. La Figura 8 mostra un insieme di frame di esempio catturati dalla webcamera e i risultati del rilevamento dei pedoni in ciascun fotogramma, mentre la Figura 9 mostra i risultati del rilevamento dei pedoni implementati su un video in ingresso fornito al sistema.

Figura 8: Risultati di rilevamento pedoni su un fotogramma catturato in tempo reale da una telecamera tramite la scheda FPGA. Cattura in tempo reale del video tramite webcam 720 P e dimostrazione della rilevazione in tempo reale dei pedoni. Le immagini sfocate sono causate da istantanee scattate dal video in diretta in corso. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 9: Risultati di rilevamento pedoni nei video forniti come input al Board FPGA. I video sono stati scattati da link open source. Clicca qui per visualizzare una versione più grande di questa figura.

Stima delle metriche di performance
Per calcolare l'efficienza e analizzare le prestazioni del progetto implementato sopra, è essenziale calcolare metriche di performance utili per valutare le prestazioni. Le metriche di performance per rilevare l'efficienza di un algoritmo di rilevamento dipendono fondamentalmente dai valori dei veri positivi (TP), dei veri negativi (TN), dei falsi positivi (FP) e dei falsi negativi (FN). Da questi valori, le metriche di performance come precisione, richiamo, punteggio F1, falsi positivi per immagine e accuratezza possono essere calcolate secondo le equazioni riportate di seguito. È stato osservato che la maggior parte degli articoli di ricerca riporta le loro prestazioni di rilevamento tramite il parametro di precisione. Tuttavia, è stato osservato che il calcolo di precisione che coinvolge l'uso di TN può essere un parametro fuorviante, poiché il valore di TN non può essere calcolato correttamente in senso reale, poiché implica trovare il conteggio di tutte le finestre di rilevamento in un'immagine che in realtà non ha un pedone, e l'algoritmo implementato lo segnala anche come nessuna rilevazione. Questo numero è generalmente molto elevato, poiché il numero totale di finestre di rilevamento in un'immagine è ampio e le aree di sfondo in ogni immagine corrispondono solitamente a regioni senza pedoni. Osservando attentamente la formula di accuratezza mostrata nelle equazioni [1] – [5], si può capire che, poiché il valore di TN sarà piuttosto alto rispetto a TP+FP+FN, il parametro di precisione di solito ha un valore elevato. Per valutare davvero le prestazioni, è molto meglio riportare metriche come precisione, richiamata e punteggio F1 che non dipendono dal TN e quindi sono molto più accurate.

[1]

[2]

[3]

[4]

[5]

Per trovare i valori di TP, TN e FN per questo articolo, l'esperimento sulle immagini fisse è stato ripetuto su un enorme numero di immagini. Dai risultati di ogni immagine, è stato calcolato il valore dei veri positivi, cioè il numero di pedoni rilevati correttamente, i falsi positivi, il numero di pedoni rilevati erroneamente, e i falsi negativi, cioè i pedoni effettivamente non rilevati. I seguenti valori sono stati riportati dopo gli esperimenti eseguiti e sono mostrati nella Tabella 6 qui sotto.

Metrica di Prestazioni	Valore
TP	143
FP	39
FN	19
Precison	0.786 (78.6%)
Richiamo	0.883 (88.3%)
Punteggio F1	0.831 (83.1%)
FPPI	0.867

Tabella 6: Metriche di prestazione per l'algoritmo di rilevamento pedoni implementato basato su FPGA.

La Tabella 6 sopra descrive quindi l'accuratezza dell'algoritmo di rilevamento pedoni attraverso le varie metriche di prestazione, precisione, richiamo, punteggio F1 e FPPI, quando l'algoritmo è implementato sulla piattaforma hardware.

Confronto delle prestazioni con implementazioni HoG basate su FPGA esistenti
Infine, il lavoro eseguito può essere confrontato con la letteratura precedente per indicare eventuali contributi significativi di questa ricerca. Questo confronto è illustrato nella Tabella 7^{15, 16, 17, 21, 24}qui sotto. Gli articoli con cui viene effettuato il confronto si basano tutti su applicazioni di rilevamento pedoni implementate su piattaforme FPGA, e gli algoritmi utilizzati per queste rilevazioni sono anch'essi gli stessi per tutti, ovvero HoG combinato con un classificatore, che è o un classificatore Adaboost o SVM. La dimensione dell'immagine è anch'essa la stessa per ciascuno (640 × 480). Il confronto viene effettuato in base a parametri come la frequenza di clock che influenza la velocità, i frame al secondo, il consumo energetico e l'utilizzo delle risorse in termini di LUT, DSP, Memory, Slices e Registers. Per indurre un confronto equo, gli articoli di ricerca considerati per il confronto hanno una risoluzione dell'immagine simile e, per normalizzare il confronto delle risorse, ogni utilizzo delle risorse viene normalizzato dividendo il numero di risorse consumate per il numero totale di risorse disponibili secondo la scheda FPGA utilizzata.

Riferimento	Dimensione dell'immagine	Scheda FPGA	Frequenza di clock	Fotogrammi al secondo (FPS)	Potenza	Pixel /clock	LUT (%)	DSP48 (%)	BRAMs /memoria Bit (%)	Registri/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
QUESTO LAVORO	640 x 480	Ultra 96 v2	150 MHz	83	2.435W	0.0632	57	35	31	24

Tabella 7: Confronto di parametri e prestazioni per le implementazioni del rilevamento pedoni su FPGA

Come possibile nella Tabella 7 sopra, si può notare che quando l'implementazione in questa ricerca viene confrontata con i lavori precedenti, i confronti mostrano miglioramenti significativi in termini di velocità. La scheda FPGA è in grado di funzionare a una frequenza di clock di 150 MHz, il che indica che il periodo di tempo per completare l'intero compito è inferiore a 6 ns. Sebbene alcuni studi precedenti riportino un aumento significativo degli FPS, attraverso un'attenta analisi si può analizzare che questo vantaggio avviene a costo di un maggiore consumo energetico e di un utilizzo quasi completo di determinate risorse. Se si considera il consumo energetico, in questo lavoro anche la potenza dichiarata è inferiore e l'utilizzo delle risorse suggerisce che il consumo di ogni risorsa è leggermente superiore rispetto a certe implementazioni, ma uguale o inferiore al 50% (57% LUT, 35% DSP e 31% BRAM), il che mostra un margine significativo per ulteriori compiti da implementare in questo design. Nel complesso, si può affermare che il lavoro implementato in questo documento raggiunge un compromesso equilibrato tra prestazioni, energia e utilizzo delle risorse. Inoltre, il lavoro presentato ha mostrato un parallelismo scalabile attraverso più blocchi IP senza influire drasticamente sui parametri di prestazione.

Fascicolo supplementare 1: Script_1_train_test.py.Clicca qui per scaricare questo file.

File supplementare 2: Script_2_HLS_hog.cpp. Clicca qui per scaricare questo file.

Fascicolo supplementare 3: Script_3_HLS_test_bench.cpp. Clicca qui per scaricare questo file.

File supplementare 4: Script_4_HLS_consts.h.Clicca qui per scaricare questo file.

Fascicolo supplementare 5: Script_5_jupyter_code.txt.Clicca qui per scaricare questo file.

Discussion

Questo studio implementa efficacemente un sistema di rilevamento pedoni in tempo reale che utilizza l'algoritmo HoG + SVM su hardware FPGA avanzato basato sulla scheda di sviluppo Zynq UltraScale+^{MPSoC 24}. I risultati indicano che l'algoritmo tradizionale HoG del rilevamento^{umano 11} raggiunge una precisione vicina al 95% e utilizza solo metà delle risorse FPGA a bordo (LUT, FF, BRAM, DSP), lasciando una grande capacità di includere molta più elaborazione per svolgere compiti diversi. Quando si analizza l'intero approccio di implementazione, si osserva che sono coinvolti diversi passaggi critici. Un passo importante è addestrare il modello^SVM 18,19,24 con un dataset appropriato per una rilevazione efficace dei pedoni, in modo che i pesi vengano estratti e utilizzati nella programmazione FPGA. Il codice di addestramento indicherà l'accuratezza delle prestazioni, e la soglia di rilevamento deve essere regolata attentamente attraverso il parametro di regolarizzazione per raggiungere un'accuratezza vicina al 95%. I parametri selezionati nell'addestramento sono i descrittori HoG personalizzati con una finestra di 64 x 128, una dimensione di blocco di 16 x 16, una cella di 8 x 8 e un numero di bin selezionato come 9. Attualmente, la formazione è stata effettuata sul dataset^{INRIA 11} con 2416 immagini positive e 1218 immagini negative. L'aumento include la rotazione delle immagini per fornire la versione orizzontale a specchio. Altre importanti inclusioni, come la valutazione del modello in condizioni di scarsa visibilità o variazioni di scala, saranno affrontate in lavori futuri per garantire riproducibilità e robustezza. Il dataset considerato per l'addestramento deve includere immagini di pedoni in varie pose e deve includere anche immagini che non contengono^{pedoni 18,19}.

L'altro passaggio critico è creare il diagramma a blocchi per l'intero sistema in modo che la parte PS della scheda FPGA possa comunicare con la parte PL. In questo passaggio, è necessario assicurarsi che ogni blocco sia parametrizzato con le porte corrette e che sia collegato correttamente agli altri blocchi. Lo strumento offre anche l'instradamento automatico con suggerimenti per assistere il progettista. Un passaggio molto cruciale è l'assegnazione dell'indirizzo dopo aver completato il diagramma a blocchi. Gli IP HoG importati devono ricevere indirizzi in base alla loro profondità, e questi indirizzi non devono essere gli stessi per due IP qualsiasi. Questi indirizzi sono richiesti nel codice python sulla scheda SD che aiuterà la parte PS della scheda FPGA a comprendere la posizione degli indirizzi in PL a cui deve accedere per leggere/scrivere i dati. Il passo quindi impegnativo è lo sviluppo dell'interfaccia sulla piattaforma Python, che permette all'utente di inviare le immagini in ingresso/video/feed live della telecamera all'FPGA e di visualizzare l'immagine in uscita con i pedoni rilevati dopo aver ricevuto le immagini elaborate dall'FPGA. Il codice Python deve essere scritto con vari messaggi di debug affinché i risultati intermedi possano essere visualizzati dal progettista e, in caso di fallimenti, gli errori possano essere diagnosticati e corretti. Una grande quantità di tempo è stata dedicata a questa ricerca per stabilire un'interfaccia adeguata tra la parte PS e quella PL. Lo script Python di questa interfaccia era in grado di accedere ai dati degli IP HoG dopo diverse iterazioni, e l'inclusione di diverse istruzioni per visualizzare i risultati intermedi era molto utile per la risoluzione dei problemi e la correzione degli errori.

Una limitazione osservata del metodo è l'utilizzo della parte python per stabilire l'interfaccia tra la parte PS e quella PL dell'FPGA. Sebbene la piattaforma python abbia ridotto drasticamente il tempo di progettazione, introduce ulteriori overhead che influiscono sulle prestazioni in tempo reale. Il sistema accelerato hardware di rilevamento pedoni ha riportato una velocità di 83 FPS, ma le prestazioni complessive del sistema sono state influenzate dalla latenza o sono diventate non reattive durante i test della telecamera in diretta a causa dei ritardi causati dal trasferimento dati tra la parte PS e la parte PL. La prospettiva futura prevede la possibilità di sviluppare un sistema hardware accelerato completo senza alcuna dipendenza dal software.

Sebbene vi siano limitazioni come descritto sopra, la ricerca contribuisce in modo significativo poiché il sistema sviluppato può essere adattato senza soluzione di continuità per la rilevazione dei pedoni in immagini statiche, feed live o ingressi video. Tutti e tre i metodi richiedono solo modifiche minori al codice Python sulla piattaforma Jupyter, dimostrando la rapida adattabilità del sistema a vari scenari. I risultati indicano che l'implementazione sulle architetture FPGA avanzate produce risultati incoraggianti, poiché i parametri di prestazione sono altamente ottimizzati, ottenendo valori buoni e accettabili. La frequenza di clock raggiunta è paragonabile alla letteratura^precedente 14,15,16,20,23, indicando che la velocità non è compromessi, mentre il consumo energetico minimo suggerisce che non ci siano problemi di riscaldamento. Inoltre, l'utilizzo delle risorse mostra che tutte le risorse sono utilizzate a meno del 50 %, indicando un potenziale significativo per ulteriori miglioramenti progettuali.

Il sistema sviluppato può essere utilizzato in qualsiasi applicazione che richieda il compito di rilevare gli esseri umani e può essere adattato ad applicazioni in tempo reale. Inoltre, gli sforzi futuri potrebbero concentrarsi sulla rimozione delle limitazioni menzionate sviluppando l'intero sistema, sia completamente sulla parte PL, facendo sì che la logica FPGA legga da sola legga le immagini di ingresso e visualizzi le immagini di output elaborate, poiché quasi il 50% delle risorse a bordo è ancora disponibile. Inoltre, se si vuole utilizzare l'integrazione PS e PL, si può effettuare lo sviluppo di interfacce tramite strumenti Software Development Kit (SDK). Altre possibili estensioni potrebbero essere l'identificazione dei pedoni in condizioni meteorologiche significativamente più rigide o durante la bassa visibilità, oppure l'identificazione dei pedoni occlusi nascosti dietro altri oggetti, richiedendo modifiche all'algoritmo. L'unica modifica richiesta in questi casi sarebbe la sostituzione dei pesi addestrati SVM dopo un addestramento adeguato secondo la sfida selezionata e il resto del sistema non richiede altre modifiche. Pertanto, il sistema implementato è ben adatto ad adattarsi facilmente ad altri scenari difficili. Un'altra prospettiva futura potrebbe essere concentrarsi sull'incorporazione di funzionalità aggiuntive nel sistema per creare un veicolo completamente autonomo utilizzando la scheda FPGA avanzata.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
Python	Python	Versione 3.10
Scheda FPGA Ultra 96 V2	Xilinx	Introdotto nel 2018	Piattaforma di implementazione hardware utilizzata per implementare l'algoritmo di rilevamento pedoni
Vivado	AMD	2019.2	Strumento di programmazione FPGA utilizzato per programmare la scheda FPGA Ultra 96 v2 con l'algoritmo di rilevamento pedoni
Vivado HLS	AMD	2019.2	Strumento di sintesi di alto livello utilizzato per la programmazione ad alto livello del codice di rilevamento pedoni nel documento per esportare la proprietà intellettuale (IP)