Conception et mise en œuvre d’un cadre de détection piétonne basé sur un réseau de portes programmable sur le terrain pour une application de conduite autonome

Summary

Cet article de recherche démontre la mise en œuvre d’un algorithme de détection piéton en temps réel sur du matériel de réseau de portes programmable sur le terrain, principalement pour des applications de conduite autonome. L’algorithme combine l’histogramme des gradients orientés (HoG) avec un classificateur de machine à vecteurs de support (SVM), et les résultats montrent une efficacité en termes de vitesse, consommation d’énergie et d’utilisation des ressources.

Abstract

La conduite autonome offre une manière prometteuse de faire face à l’augmentation du nombre de décès dus aux accidents de la route. Un véhicule autonome comprend de nombreuses fonctionnalités, mais la capacité à détecter les piétons est cruciale, stimulante et pertinente pour diverses situations en temps réel telles que la surveillance, le suivi des personnes et la surveillance. Identifier précisément les piétons est difficile car ils peuvent apparaître sous différentes formes, positions et postures. Ils peuvent porter divers types de vêtements et parfois être partiellement cachés ou se fondre dans les objets à proximité. Cet article se concentre sur la détection en temps réel des piétons pour les voitures autonomes à l’aide d’une plateforme matérielle populaire : le field programmable gate array (FPGA), Ultra 96 v2. L’étude met en œuvre une méthode de détection des piétons basée sur un histogramme de gradients orientés (HOG) combiné à un classificateur de machine à vecteurs de support (SVM) pour reconnaître les individus sur la carte FPGA, en tirant parti d’outils de synthèse de haut niveau (HLS). L’efficacité du système a été testée à la fois sur des images fixes et sur la vidéo en direct. Les résultats montrent que les cartes FPGA avancées comme l’Ultra 96 v2 améliorent significativement les indicateurs de performance. Le système fonctionne à une fréquence d’horloge de 150 MHz en utilisant moins de la moitié des ressources disponibles et consommant environ 2,5 W d’énergie. De plus, le système rapporte une précision de détection des piétons proche de 95 % ainsi que d’autres indicateurs efficaces pour l’évaluation de la détection, tels que la précision (78,6 %), le rappel (88,3 %) et le score F1 (83,1 %). En résumé, le système développé peut détecter les piétons en temps réel et a le potentiel d’améliorer significativement la mise en place d’un environnement de transport intelligent et sûr.

Introduction

Le développement urbain et l’émergence des villes intelligentes sont des sujets d’intérêt à travers le monde. Toutes les nations œuvrent au développement de leurs villes qui peuvent être construites de manière à être sûres et confortables pour les^{habitants 1,2}. Mais dans la situation actuelle, il a été observé qu’à mesure que la population augmente et que la congestion routière augmente, le taux de décès dus à des accidents de la route dus à la négligence au volant et à la mauvaise visibilité augmente de manière alarmante. Une solution prometteuse à ces problèmes est l’émergence des véhicules autonomes dans le monde, ce qui a suscité l’innovation 1,2,3,4, et les chercheurs s’efforcent de développer des véhicules entièrement autonomes capables de permettre aux passagers de se détendre sans aucune préoccupation. Le besoin de développer des véhicules autonomes découle du fait que même les conducteurs expérimentés peuvent faire face au stress, aux dilemmes, à la fatigue ou à des difficultés à percevoir leur environnement en raison du mauvais temps, et tous ces problèmes conduisent à des accidents de la route. Un véhicule autonome est conçu pour éviter les accidents en circulation, optimiser l’utilisation des ressources du moteur et respecter le code de la route, ce qui améliorera sans aucun doute les^{transports 2,4}. Un véhicule autonome est équipé de multiples fonctionnalités, capteurs et fonctionnalités qui lui permettent de percevoir son environnement avec une grande précision, évitant ainsi toute collision et accident, et c’est pourquoi ils se sont imposés comme une solution prometteuse pour rendre le transport sûr^{et sécurisé 1,2,3,4}.

Parmi toutes les fonctionnalités intégrées à un véhicule autonome, l’une des plus essentielles est la détection des piétons. Un système robuste de détection des piétons peut contribuer significativement à réduire les décès d’accidents de la route 5,6,7,8, car la majorité des victimes de ces accidents sont des piétons. La détection des piétons consiste à identifier les personnes sur la route et à éviter toute collision avec elles. Cette fonctionnalité est bénéfique non seulement pour les voitures autonomes, mais aussi pour divers autres domaines d’application tels que la surveillance des foules, l’identification des personnes et le suivi^{9, 10, 11}. L’aspect clé de ce processus de détection est la rapidité et la précision de la détection. Il est crucial de détecter les piétons avec précision et rapidité afin que le temps de réponse soit minimal. La détection des piétons pose un énorme défi. Les piétons sur la route peuvent porter n’importe quel vêtement, apparence ou posture, et peuvent être invisibles en raison du mauvais temps ou de l’obstruction 10,11,12,13,14. De plus, il est tout à fait possible que les piétons ne respectent pas eux-mêmes les règles, et on ne peut pas contrôler la nature humaine, donc la meilleure approche possible est d’équiper le véhicule de l’intelligence nécessaire pour gérer toute mauvaise action et éviter des décès. Le déroulement complet des travaux menés dans cette recherche et la motivation derrière la mise en œuvre matérielle de la détection des piétons peuvent être facilement compris à partir de la Figure 1 ci-dessous, qui explique la nécessité de la détection des piétons, ses différents domaines d’application, les défis liés et la mise en œuvre sur un FPGA pour exploiter les avantages offerts.

Figure 1 : Détection des piétons. Le besoin de détection des piétons, les domaines clés d’application de la détection des piétons, les défis liés à la détection des piétons, et la mise en œuvre du flux de détection des piétons sur une carte FPGA. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Pour identifier les piétons sur la route, de nombreux algorithmes existent. Cette tâche globale peut être principalement divisée en deux sous-tâches principales : l’étape initiale extrait des caractéristiques d’une image d’entrée, ne conservant que celles qui sont significatives et transmettent des informations pertinentes, tout en ignorant les données redondantes. Pour une reconnaissance efficace des humains ou des piétons dans une image, il est crucial que ces caractéristiques indiquent la présence d’une figure humaine dans la scène^13,14. Après cette extraction, les caractéristiques doivent être envoyées à un classificateur capable de déterminer si les caractéristiques identifiées correspondent à un humain. Par conséquent, l’algorithme nécessite une phase d’extraction et de description des caractéristiques, suivie d’une étape de classification pour déterminer la présence des piétons dans la scène d’entrée. Il existe divers algorithmes disponibles à cet effet. Cependant, la méthode la plus largement acceptée à ce jour pour la détection des piétons reste la combinaison de l’histogramme des gradients orientés (HoG) avec le classificateur^12,13,14,15 de la machine à vecteurs de support (SVM^). De nombreux exemples d’avancées logicielles existent, mais l’objectif final est de porter l’implémentation vers une plateforme matérielle compatible, qui pourra ensuite être intégrée au système applicatif pour une utilisation en temps réel. Par conséquent, l’accent actuel est mis sur la réalisation matérielle. Il est donc nécessaire de développer une mise en œuvre matérielle adaptée des systèmes de détection des piétons, où des caméras équipées du matériel approprié puissent être déployées sur les véhicules et identifier les piétons sur la route. Lorsqu’on considère quel matériel est approprié pour de telles implémentations, l’une des options les plus couramment utilisées est le réseau de portes programmable sur le terrain (FPGA) en raison de ses nombreux avantages, notamment la réduction du temps de conception, la scalabilité, la facilité de modification, la reconfigurabilité, ainsi que la moindre consommation d’énergie et^d’énergie 15,16,17,18,19,20,21.²².

Les cartes FPGA ont constamment évolué et sont désormais largement utilisées pour des applications complexes et avancées de vision par ordinateur allant du traitement d’image basique à la détection d’objets, la réalité augmentée et l’apprentissage^{profond 20, 21, 22.} Actuellement, plusieurs cartes FPGA haute performance offrent des capacités architecturales exceptionnelles pour accueillir le traitement étendu requis pour ces applications complexes. Si les fonctionnalités avancées des véhicules autonomes, telles que la détection des piétons, sont mises en œuvre sur de telles plateformes matérielles, ces plateformes peuvent être très utiles pour le développement rapide de prototypes afin d’analyser les performances et, après optimisation, l’algorithme implémenté peut être transféré vers de véritables circuits intégrés pour être intégré au système.

Depuis plus d’une décennie, des publications importantes ont été publiées sur la mise en œuvre de la détection des piétons utilisant les méthodes HoG et SVM sur différentes plateformes FPGA. Le tableau 1 résume les articles dans ce domaine durant la période de 2015 à 2025 : ^{15,16,17,18,19,20,21,22,23,24}, en se concentrant sur les facteurs clés tels que la résolution de l’image, le débit, ou les images par seconde (FPS), le type de classificateur, ainsi que les points forts ou les contributions apportées par le papier.

Référence	Plateforme FPGA	Résolution de l’image	Classificateur	Faits forts / contributions
15	Xilinx Zynq	640×480	AdaBoost	Mise en œuvre FPGA en temps réel ; économe en ressources ; utilise la binarisation pour l’optimisation ; Bonne précision de détection.
16	Carte DE1-SOC de Terasic	640×480	SVM	Extracteur HOG haute performance ; intègre la SVM ; détection à échelle unique ; pipeline à faible latence.
17	Altera DE2-115	640×480	AdaBoost	Évalue la performance sous plusieurs angles ; Implémentation FPGA de HOG+AdaBoost ; détection des piétons en temps réel.
18	Intel Stratix V	640×480	SVM	détection des piétons à plusieurs échelles ; pipeline HOG+SVM compatible avec FPGA ; Met en évidence les compromis entre précision et efficacité matérielle.
19	Zynq UltraScale+ MPSoC	3840×2160	SVM	Traitement UHD en temps réel ; HOG+SVM pipeline ; Mise en œuvre du SoC FPGA ; optimisation en virgule fixe ; Architecture évolutive.
20	Non spécifié	Non spécifié	SVM	Atteint une précision de détection de >95 % ; implémentation FPGA en temps réel ; exploite le parallélisme ; conception détaillée de FPGA HOG+SVM pour la détection des piétons.
21	Zync 7000 FPGA	1920×1080	SVM	Architecture de flux à haut débit pour HOG+SVM ; prend en charge la résolution HD ; pipeline efficace pour l’accélération FPGA.
22	Ultra96 (rev1)	240×320	SVM	implémentation FPGA utilisant HLS ; détecte les feux rouges ; calcule les probabilités dans 891 régions ; La latence varie de 153 838 à 19 cycles.
23	Xilinx Zynq-7000 FPGA	640 × 480	HOG + SVM	A implémenté la détection des piétons via HOG-SVM sur FPGA, obtenant des performances en temps réel avec une consommation d’énergie réduite par rapport au traitement CPU. Pipeline d’extraction de caractéristiques optimisé démontré, adapté aux applications de vision embarquée.
24	Xilinx Virtex-6 FPGA	640 × 480	Détecteur d’objets à point fixe (caractéristiques de type Haar)	Proposition d’accélération FPGA à haut débit de la détection d’objets utilisant l’arithmétique à virgule fixe, réduisant le coût de calcul tout en maintenant la précision. A montré une accélération de 15× par rapport aux implémentations CPU avec une utilisation efficace des ressources matérielles.

Tableau 1 : Revue de la littérature des recherches basées sur la détection des piétons sur FPGA (2015–2025).

Le tableau 1 résume qu’il existe une littérature abondante dans le domaine de la détection des piétons, et que la mise en œuvre matérielle est le domaine d’intérêt des chercheurs. Il est également évident qu’il existe des techniques avancées d’apprentissage profond et d’apprentissage automatique, telles que des détecteurs basés sur des réseaux de neurones convolutionnels (CNN) comme YOLO, des architectures basées sur des transformateurs, etc., pour la détection des piétons. Ils surpassent même l’algorithme HoG traditionnel en termes de précision, mais lorsqu’on considère la mise en œuvre matérielle, les algorithmes avancés entraînent une utilisation massive des ressources^23,24 en raison de la complexité de l’algorithme, ce qui peut aussi affecter d’autres paramètres de performance, et il a également été observé qu’en raison de la complexité ajoutée, la vitesse est légèrement supérieure dans le cas de l’algorithme HoG^{traditionnel 24, 25}. Il a également été observé que les techniques avancées consomment plus d’énergie lorsqu’elles sont implémentées sur du matériel^24,26. Ainsi, l’objectif du travail mis en œuvre dans cet article est de réaliser la détection des piétons en utilisant le cadre traditionnel HoG et SVM sur le matériel FPGA et d’obtenir un compromis favorable entre précision, vitesse, ressources et puissance pour l’intégration en temps réel. D’après le tableau 1, il est assez clair que lorsque les travaux basés sur HoG et SVM sont analysés, on observe qu’il existe peu de publications ayant utilisé la carte de développement FPGA²⁷ récemment introduite Zynq UltraScale+ (Multi-Processor System On Chip) basée sur FPGA pour explorer les capacités de ces cartes, car du point de vue de l’architecture, ces cartes ont évolué. et offrent un grand potentiel en termes de mise en œuvre d’applications de vision par ordinateur en temps réel haut de gamme. Il existe peu de publications qui ont réalisé l’intégralité du système de détection des piétons en temps réel sur les cartes FPGA. Cependant, ils se sont concentrés sur la mise en œuvre ou l’amélioration efficace des tâches intermédiaires. De plus, la plupart de ces implémentations reposent sur la réalisation de l’ensemble du système sur une carte FPGA grâce à l’utilisation de langages de description matérielle. Peu ont exploité les avantages des outils de synthèse de haut niveau (HLS) pour accélérer le cycle de conception. Cet article démontre la conception et la mise en œuvre de la détection piétonne en temps réel sur une carte FPGA dédiée à une application de conduite autonome. L’article utilise le cadre HoG et SVM pour la détection des piétons sur des images fixes, des vidéos ou des entrées réelles de caméra. Le matériel utilisé est une carte FPGA de pointe récemment lancée, l’Ultra96 v2, qui est une architecture FPGA avancée offrant une plateforme puissante pour la vision par ordinateur, le traitement d’images, l’apprentissage automatique, l’informatique de bord, ^etc.24. L’Ultra96 v2 est une carte de développement équipée d’un AMD Xilinx Zynq UltraScale+^{MPSoC 27} basé sur Arm. Cette carte comprend le segment système de traitement (PS), qui comprend des cœurs CPU basés sur ARM gérant les aspects logiciels du projet, ainsi que le segment Logique Programmable (PL) qui permet une accélération matérielle^{personnalisable 20, 21, 22}. Ensemble, ces composants améliorent la fonctionnalité d’un système hybride, où la partie PS gère le contrôle et l’interaction avec les éléments externes, tandis que la partie PL gère la logique de traitement réelle.

Protocol

La procédure de mise en œuvre utilisée dans cette recherche, basée sur la détection des piétons avec HoG + SVM sur une carte FPGA, tirant parti des avantages de la synthèse de haut niveau, est illustrée à la Figure 2 ci-dessous.

Figure 2 : Procédure de conception pour la mise en œuvre de la détection des piétons sur la carte FPGA. Phase 1 : Algorithme de détection des piétons utilisant HoG+SVM sur l’outil HLS et génération du bloc IP. Phase 2 : Algorithme de détection des piétons utilisant HoG+SVM pour l’implémentation réelle du FPGA et la génération du fichier bit. Phase 3 : Programmation de la carte avec le fichier bit généré. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

1. Détection des piétons en utilisant HoG et SVM sur l’outil HLS

1. Téléchargez l’Environnement de Développement Intégré (IDE) Python en fonction des propriétés système sur lesquelles le téléchargement est effectué.
   REMARQUE : Dans ce travail, la version Python 3.10 est utilisée.
2. Exécutez un script Python pour exécuter un modèle d’entraînement en utilisant l’algorithme HoG et le classificateur SVM. Commencez le script par le chargement des échantillons positifs et négatifs à partir du jeu de données.
   REMARQUE : Utilisez l’ensemble de données^{INRIA 11}.
3. Extraire les caractéristiques HoG pour une fenêtre de 64 x 128.
4. Séparez les données d’entraînement et de test du jeu de données INRIA en un ratio de 80/20 avec un mélange aléatoire pour la reproductibilité.
   REMARQUE : Le jeu de données est aléatoirement aléatoirement aléatoire à l’aide de la fonction python avant de diviser les données. Assurer la reproductibilité afin que la même division soit effectuée à chaque fois qu’une valeur de départ est fixée dans le code.
5. Entraînez-vous en utilisant la SVM de classification vectorielle de support C (SVC) avec un noyau linéaire.
6. Extraire les vecteurs de poids et le biais.
7. Sauvegardez les poids SVM et le biais au format Q8.8 à virgule fixe pour l’implémentation FPGA.
   REMARQUE : La conversion s’effectue en mettant à l’échelle chaque valeur en virgule flottante l’originalité générée par un facteur de 256 (2⁸) et en convertissant le résultat en entier.
8. Testez le modèle entraîné via un autre script Python et ajustez le paramètre de régularisation C, jusqu’à ce que la précision soit calculée à plus de 95 %.
   REMARQUE : Paramètre de régularisation optimisé obtenu : C = 0,05.
9. Ouvre l’outil HLS et crée un nouveau projet avec le numéro de pièce sélectionné comme xczu3eg-sbva484-1-e.
10. Écrivez un code de détection de piétons sur l’outil de synthèse de haut niveau en utilisant des langages de haut niveau comme C++.
11. Dans le code, écrivez trois scripts C++ différents : un pour le descripteur de caractéristique HoG et le classificateur SVM, un autre pour le banc d’essai afin de fournir une entrée aux images de test et sauvegarder les images de sortie, et le troisième pour un fichier d’en-tête qui déclare les paramètres utilisés dans le code.
12. Dans le code pour le calcul des caractéristiques HoG, redimensionnez l’image à 640 x 480 et appliquez une architecture à fenêtre coulissante avec une taille de fenêtre de 64 x 128. Pour chaque fenêtre, calculez la magnitude et l’orientation du gradient pour chaque bloc de 8 x 8 qui se chevauche.
    REMARQUE : Il est important de parcourir l’image entière à travers le concept de fenêtre coulissante afin que chaque zone de l’image soit couverte et que les piétons de toutes tailles possibles soient identifiés.
13. Dans l’autre partie du même code pour le descripteur de caractéristiques HoG, passez les gradients calculés au classificateur SVM. Écrivez le code pour associer les caractéristiques aux poids du classificateur et comparez avec le seuil pour classer la caractéristique détectée comme étant humaine ou non.
14. Cliquez sur Exécuter la simulation C dans l’outil HLS pour simuler le code à l’aide d’un établi de test afin de vérifier la correction fonctionnelle du code.
15. Fournissez différentes images d’entrée au code et vérifiez les images de sortie avec les piétons détectés.
16. Cliquez sur Exécuter C Synthèse pour synthétiser le code afin de le mapper aux langages matériels via l’outil et générer les rapports de timing et d’utilisation.
    REMARQUE : L’outil ouvre automatiquement les rapports de synthèse HLS. Ce rapport montre l’estimation de la fréquence d’horloge requise pour implémenter la tâche codée sur une plateforme FPGA sélectionnée, et fournit également une estimation des ressources utilisées. Ces valeurs rapportées ne sont que des estimations et les paramètres réels ne sont calculés qu’après leur mise en œuvre sur la carte FPGA.
17. Cliquez sur Exporter RTL pour exporter le bloc de propriété intellectuelle (IP) de l’algorithme HoG de détection des piétons.
    REMARQUE : Cette IP doit être utilisée dans les étapes ultérieures de la mise en œuvre.

2. Programmation de la carte FPGA

1. Ouvre l’outil de programmation FPGA et crée un nouveau projet. Sélectionnez le numéro de pièce comme xczu3eg-sbva484-1-e et créez un nouveau design de bloc.
   REMARQUE : Ce schéma en blocs est créé pour établir l’intégration entre la partie PS et la partie PL de la carte FPGA. Le protocole de communication utilisé est le protocole Advanced eXtensible Interface (AXI).
2. Cherchez le catalogue IP dans l’outil et, une fois trouvé, ouvrez-le.
3. Créez un dépôt utilisateur en ajoutant le chemin de l’IP RTL exportée à l’étape 1.17.
4. Dans la nouvelle fenêtre de conception de blocs , faites maintenant un clic droit et sélectionnez ajouter une adresse IP. Toutes les IP seront visibles, y compris celles fournies par l’outil ainsi que les dépôts ajoutés par l’utilisateur.
5. Ajoutez le bloc PS Zync Ultrascale depuis le dépôt.
   REMARQUE : Ce bloc reflète la partie PS du système, responsable de la génération des fréquences requises, et il possède également les ports maître et esclave pour la connexion à l’IP HoG importée via le bloc d’interconnexion AXI, qui fonctionne sur les fondamentaux du protocole AXI.
6. Ajoutez 8 IP HoG car le système traitera 8 fenêtres simultanément pour tirer parti de l’avantage du parallélisme offert par la carte FPGA.
7. Ajoutez un bloc de réinitialisation du système processeur , qui contrôle également l’horloge et les alimentations de chaque bloc du schéma.
8. Ajoutez deux blocs axi_smart connect pour connecter les IP HoG avec le bloc PS Zync. Le schéma bloc complet avec les connexions complètes est montré à la Figure 3.
   REMARQUE : Comme montré à la Figure 3, tous les blocs à ajouter à la conception ont été clairement illustrés. La figure 3 est capturée à partir de l’outil et elle montre les ports internes de chaque bloc ainsi que les interconnexions entre les ports des différents blocs. Ce bloc est la conception principale car il est responsable de l’établissement de l’interface entre la partie PS et la partie PL de la carte FPGA.
9. Après avoir complété les connexions comme indiqué à la Figure 3, cliquez sur valider la conception.
   REMARQUE : La validation vérifie essentiellement les connexions manquantes ou cassées, ce qui peut entraîner des problèmes à des étapes ultérieures.
10. Cliquez sur synthèse puis implémentez la conception dans le tool après que la validation du diagramme bloc ait été réussie.
    REMARQUE : Synthèse cartographie le schéma en blocs conçu et le mappe sur la carte FPGA. Cette étape signalera toute infraction pouvant indiquer que la conception ne peut pas être implémentée sur le matériel.
11. L’outil générera également des rapports liés au timing, à l’utilisation des ressources et à la consommation d’énergie. Examinez attentivement les rapports pour vérifier toute violation du timing et analysez les performances du système conçu.
12. Cliquez sur Générer le fichier du flux binaire qui générera le fichier .bit nécessaire à la programmation de la carte FPGA.

Figure 3 : Diagramme bloc pour la détection des piétons utilisant HoG + SVM IP importée. Veuillez cliquer ici pour voir une version agrandie de cette figure.

3. Implémentation finale sur la carte FPGA

1. Prends la carte FPGA et insère la carte SD avec le bon fichier image dans le slot de la carte.
2. Connecte aussi la carte à l’ordinateur.
3. Démarrez la carte FPGA en mode carte SD pour activer la programmation Python^{dessus 21,22}.
4. Accédez à la plateforme Jupyter sur la carte après l’avoir connectée au wifi.
5. Connectez une webcam à la carte.
6. Écrivez un code Python pour importer le fichier bit généré et effectuez la tâche d’accès aux images de la caméra.
7. Dans le code, écrivez le script de façon à ce que l’image soit écrite dans la mémoire de la carte FPGA via la partie PS et transmise à la partie PL pour traitement.
   REMARQUE : La partie PL du tableau correspondant aux IP HoG accède aux pixels de l’image via ces emplacements mémoire, les traite et fournit les scores en sortie.
8. Écrivez le code approprié dans le même script Python pour lire les images traitées et les afficher à l’écran de l’ordinateur.
   REMARQUE : Cela complète l’ensemble de la conception et le système est désormais prêt à être déployé dans des applications réelles. Tous les codes utilisés dans cette étude sont téléchargés sous forme de fichiers de codage supplémentaires (Fichier Supplémentaire 1 [Script_1_train_test.py], Fichier Supplémentaire 2 [Script_2_HLS_hog.cpp], Fichier Supplémentaire 3 [Script_3_HLS_test_bench.cpp], Fichier Supplémentaire 4 [Script_4_HLS_consts.h], Fichier Supplémentaire 5 [Script_5_jupyter_code.txt]).

Results

Implémentation de la détection piétonne sur HLS
La figure 4 montre les résultats de simulation sur l’outil HLS pour la détection des piétons en utilisant HoG + SVM. Une image d’entrée avec un piéton est envoyée comme entrée de test au code, et la sortie avec les piétons détectés est affichée. L’image comporte deux sections. La première détection montre de nombreuses boîtes englobantes autour du même piéton, encore et encore, et dans la seconde image, les boîtes qui se chevauchent sont supprimées, et elles sont supprimées, ne laissant que les boîtes principales de détection.

Figure 4 : Résultat de simulation de l’outil HLS. (A,B) Deux images d’entrée différentes et les images résultantes avec les piétons détectés. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

L’outil HLS fournit également des rapports de synthèse sur le moment et l’utilisation des ressources. Le résumé temporel met en évidence la période requise par la conception et fournit les valeurs de latence maximale et minimale en termes de nombre de cycles. Ces informations sont utiles pour estimer le temps nécessaire pour l’exécution de la conception et quelle devrait être la fréquence d’horloge lors du passage à la mise en œuvre matérielle réelle. Le tableau 2 ci-dessous montre le rapport de temporisation après la synthèse HLS, qui montre clairement que la période d’horloge cible était de 6 ns et que la conception a pris 5,25 ns, ce qui est inférieur à la cible, et donc la période peut être de 6 ns ou plus mais pas en dessous de 5 ns.

Résumé des horaires
Horloge	Cible	Estimation
	6,00 ns	5,250 ns
Résumé de l’utilisation
	Total / Disponible	Pourcentage d’utilisation
BRAM18K	22 / 432	5%
DSP48E	13 / 360	3%
FF	5611/ 141120	3%
LUT	9904/ 70560	14%
URAM	0	0

Tableau 2 : Estimation du calendrier et du rapport d’utilisation des ressources à partir de l’outil HLS pour la détection des piétons utilisant HoG-SVM.

Le tableau 2 présente également le rapport d’utilisation. Il montre le pourcentage d’utilisation des ressources FPGA embarquées importantes selon la carte cible sélectionnée. Pour cette conception de détection piétonne, le rapport d’utilisation montre que la conception consomme 14 % des tables de recherche (LUT), 3 % des Flip Flops (FF), 3 % du traitement numérique du signal (DSP) et 5 % de la mémoire d’accès aléatoire par blocs (BRAM). Ces estimations ne sont pas les rapports d’utilisation exacts, mais les rapports réels sont proches de ces estimations. Ce ne sont que les estimations qui peuvent être calculées par les outils HLS. La mise en œuvre réelle est généralement très différente de ces estimations.

L’implémentation réelle résulte de la programmation matérielle
Après que le code a été mappé dans une IP, qui est importée dans l’outil de programmation FPGA, et que la conception est implémentée sur le matériel FPGA réel, plusieurs rapports sont également générés. La première est le résumé du chronométrage, qui montre si la fréquence d’horloge fournie à la conception est suffisante ou non. Si toutes les contraintes de temps sont respectées et qu’il n’y a pas de violations, alors la conception peut avancer. Le tableau 3 ci-dessous présente le résumé des délais généré par l’outil. Comme indiqué dans le tableau, le résumé du timing indique le pire marge de jeu négatif, soit 4,073 ns. Comme cette valeur est positive, elle indique que ce temps reste disponible. Les valeurs négatives indiquent que le FPGA met plus de temps à accomplir la tâche, et que l’horloge file rapidement. Puisque dans ce cas il n’y a pas de valeurs négatives, ce qui signifie que les contraintes temporelles sont respectées.

Résumé du calage de conception
Mise en place	Tiens	Largeur d’impulsion
Pire Negative Slack 4,073 ns	Pire marge de maintien 0,010 ns	Pire largeur d’impulsion : Mou 3,500 ns

Tableau 3 : Résumé réel du timing pour la détection des piétons sur la carte FPGA.

De plus, l’outil affiche les rapports d’utilisation des ressources, qui correspondent à l’utilisation réelle des ressources embarquées selon la carte FPGA sélectionnée. Dans ce cas, la carte de développement sélectionnée est la carte de développement^{FPGA 27} basée sur Zynq UltraScale+ MPSoC (Multi-Processor System On Chip). Le tableau 4 ci-dessous montre l’utilisation des ressources et la figure 5 montre la représentation diagrammatique de l’utilisation des ressources.

Le résumé d’utilisation indique la consommation réelle des ressources embarquées, étant donné qu’il y a 8 IP HoG utilisés en parallèle, et que les estimations rapportées par la synthèse HLS concernaient une seule IP HoG. Mais même après une utilisation aussi étendue, l’utilisation des ressources pour chaque ressource est inférieure à 50 %. Le tableau 4 indique clairement l’utilisation par rapport aux différentes ressources et leur pourcentage d’utilisation, représenté de manière picturale à la Figure 5.

Ressource	Utilisation	Disponible	Pourcentage d’utilisation
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%

Tableau 4 : Rapport d’utilisation réel pour la détection des piétons sur la carte FPGA.

Figure 5 : Utilisation des ressources pour la détection des piétons sur la carte FPGA après la mise en œuvre effective. Consultez les tableaux (LUT) : 57 %, LUTRAM : 25 %, tongs (FF) : 24 %, RAM par bloc (BRAM) : 31 %, processeurs de signal numérique (DSP) : 36 %, tampons : 1 %. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Le troisième rapport concerne les estimations de puissance de la carte pour la consommation d’énergie par la conception. La figure 6 ci-dessous montre le rapport de consommation électrique, qui indique que la puissance totale embarquée sur puce est de 2,435 W. La température de jonction et l’énergie consommée par chaque réseau et composant importants sont également indiqués. Les mesures de puissance ne mettent pas en évidence une consommation d’énergie alarmante, et la conception peut donc être considérée comme économe en énergie.

Figure 6 : Estimation de la puissance pour la détection des piétons sur la carte FPGA après la mise en place effective. Le rapport de puissance généré par les outils indique la puissance totale consommée à 2,435 W et montre également la répartition de la puissance entre les différentes ressources sur la carte FPGA. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Une autre analyse est réalisée pour comprendre l’avantage d’utiliser 8 IP HoG au lieu d’une seule IP HoG ou plus de 8 dans le schéma bloc créé, comme montré à la Figure 3. Les métriques de performance liées au matériel étaient calculées en parallèle pour une seule IP HoG et 8 IP HoG. Le tableau 5 ci-dessous montre la comparaison.

Métrique de performance	1 IP	8 IP
Chronométrage (ns)	5.312	~5,25
Fréquence (MHz)	188	150
Puissance (W)	1.9	2.43
LUTs	4998	40536
FF / Registres	4,031	33,342
DSP	16	128
BRAM	8.5	68
FPS	~10–11	83

Tableau 5 : Comparaison des indicateurs de performance utilisant une seule IP de HoG vs plusieurs IP HoG.

Le tableau 5 indique clairement que lorsque les ressources sont considérées comme les LUT, FF, DSP et BRAM, alors avec une IP HoG unique et 8 IP HoG, la mise à l’échelle est linéaire avec une augmentation de près de 8 fois des ressources utilisées. Cela est clairement attendu, car plus de propriétés intellectuelles entraîneront une consommation accrue de ressources. De plus, si la fréquence est observée, alors la fréquence maximale se dégrade légèrement de 20 % de 188 MHz à 150 MHz. Cela est également attendu, car plus de blocs entraînent plus de connexions et donc des chemins plus longs, ce qui entraîne une augmentation des chemins critiques. Mais les facteurs avantageux comme les images par seconde (FPS) passent de 10 à 83, démontrant une mise à l’échelle non linéaire dans le cas des FPS grâce au concept introduit de parallélisme, grâce à 8 IP HoG. De plus, la puissance passe de 1,9 W à 2,4 W, ce qui indique une amélioration de l’efficacité énergétique grâce au pipeline. Ainsi, cette analyse indique clairement que l’introduction de 8 IP HoG est bénéfique pour la conception, et qu’une mise à l’échelle au-delà de 8 peut entraîner une surconsommation des ressources ; ainsi, le nombre de blocs au-delà de 8 n’est pas considéré comme favorable.

Résultats de détection des piétons après la mise en œuvre du FPGA
Enfin, l’ensemble du système est intégré sur la carte FPGA, et le fichier bitstream est généré, qui est ensuite programmé sur la carte SD via la carte SD démarrée avec la capacité de programmation Python. Une fois la carte connectée au démarrage de la carte SD, l’interface jupyter peut être accessible et du code Python peut être écrit et exécuté sur la plateforme. Le code Python est exécuté et testé pour la détection des piétons sur différentes images d’entrée. Le résultat de quelques images est montré à la Figure 7 ci-dessous. Ces images sont utilisées à partir de l’ensemble de données INRIA ainsi que des images aléatoires de piétons obtenues à partir de sources en ligne open^{source 26,27}.

Figure 7 : Résultats de détection des piétons sur des images fixes via FPGA Board. Les images testées incluent des images issues de l’ensemble de données INRIA, des images open source disponibles sur Google pour tester la précision de la détection dans les rues bondées de l’Inde. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Le système est également testé en capture d’images en temps réel via une caméra web et la détection des piétons dans le cadre ainsi que sur les entrées vidéo déjà enregistrées des piétons. Les résultats de ce processus sont représentés dans les figures 8 et 9. La figure 8 montre un ensemble d’images d’exemple capturées par la caméra web et les résultats de la détection des piétons dans chaque image, tandis que la figure 9 montre les résultats de la détection des piétons mise en œuvre sur une vidéo d’entrée fournie au système.

Figure 8 : Résultats de détection des piétons sur une image capturée en temps réel par une caméra via la carte FPGA. Capture vidéo en temps réel via une caméra web 720 P et démonstration de la détection en temps réel des piétons. Les images floues sont causées par des instantanés pris à partir de la vidéo en direct en cours. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 9 : Résultats de détection de piétons sur les vidéos fournies en entrée au FPGA Board. Les vidéos ont été prises à partir de liens open source. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Estimation des indicateurs de performance
Pour calculer l’efficacité et analyser la performance du design implémenté ci-dessus, il est essentiel de calculer des indicateurs de performance utiles pour évaluer la performance. Les indicateurs de performance pour détecter l’efficacité d’un algorithme de détection dépendent essentiellement des valeurs des vrais positifs (TP), des vrais négatifs (TN), des faux positifs (FP) et des faux négatifs (FN). À partir de ces valeurs, les métriques de performance telles que la précision, le rappel, le score F1, les faux positifs par image et la précision peuvent être calculées selon les équations ci-dessous. Il a été observé que la plupart des articles de recherche rapportent leur performance de détection via le paramètre de précision. Mais il a été observé que le calcul de précision impliquant l’utilisation de TN peut être un paramètre trompeur, car la valeur de TN ne peut pas être calculée correctement au sens réel, car cela implique de trouver le nombre de toutes les fenêtres de détection dans une image qui ne contient pas réellement de piéton, et l’algorithme implémenté le signale également comme aucune détection. Ce nombre est généralement très élevé, car le nombre total de fenêtres de détection dans une image est important, et les zones de fond correspondent généralement à des zones sans piétons. En examinant de près la formule de précision présentée dans les équations [1] – [5], on peut réaliser que, comme la valeur de TN sera assez élevée comparée à TP+FP+FN, le paramètre de précision a généralement une valeur élevée. Pour vraiment évaluer la performance, il est bien préférable de rapporter des métriques comme la précision, la mémoire et le score F1 qui ne dépendent pas du TN et sont donc beaucoup plus précises.

[1]

[2]

[3]

[4]

[5]

Pour trouver les valeurs de TP, TN et FN pour cet article, l’expérience sur les images fixes a été répétée sur un grand nombre d’images. À partir des résultats de chaque image, la valeur des vrais positifs, soit le nombre de piétons détectés correctement, les faux positifs, le nombre de piétons détectés à tort, et les faux négatifs, c’est-à-dire les piétons réels qui n’ont pas été détectés, a été calculée. Les valeurs suivantes ont été rapportées après les expériences réalisées et sont présentées dans le tableau 6 ci-dessous.

Mesure de performance	Valeur
TP	143
FP	39
FN	19
Précison	0.786 (78.6%)
Rappel	0.883 (88.3%)
F1 Score	0.831 (83.1%)
FPPI	0.867

Tableau 6 : Indicateurs de performance pour l’algorithme de détection des piétons basé sur le FPGA implémenté.

Le tableau 6 ci-dessus décrit ainsi la précision de l’algorithme de détection des piétons à travers les différentes métriques de performance, la précision, le rappel, le score F1 et le FPPI, lorsque l’algorithme est implémenté sur la plateforme matérielle.

Comparaison des performances avec les implémentations HoG existantes basées sur FPGA
Enfin, le travail réalisé peut être comparé à la littérature antérieure pour indiquer les contributions significatives de cette recherche. Cette comparaison est illustrée dans le tableau 7^{15, 16, 17, 21, 24}ci-dessous. Les articles avec lesquels la comparaison est réalisée sont tous basés sur des applications de détection de piétons implémentées sur des plateformes FPGA, et les algorithmes utilisés pour ces détections sont également les mêmes pour tous, c’est-à-dire HoG combiné à un classificateur, qui est soit un classificateur Adaboost, soit un SVM. La taille de l’image est également la même pour chaque image (640 × 480). La comparaison se fait sur la base de paramètres tels que la fréquence d’horloge qui influence la vitesse, les images par seconde, la consommation d’énergie et l’utilisation des ressources en termes de LUT, DSP, mémoire, tranches et registres. Pour induire une comparaison équitable, les articles de recherche envisagés pour la comparaison ont une résolution d’image similaire, et pour normaliser la comparaison des ressources, chaque utilisation des ressources est normalisée en divisant le nombre de ressources consommées par le nombre total de ressources disponibles selon la carte FPGA utilisée.

Référence	Taille de l’image	Carte FPGA	Fréquence d’horloge	Images par seconde (FPS)	Puissance	Pixels /clock	LUTs ( %)	DSP48 ( %)	BRAMs /bits mémoire ( %)	Caisses/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	Cyclone 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
CETTE ŒUVRE	640 x 480	Ultra 96 v2	150 MHz	83	2,435W	0.0632	57	35	31	24

Tableau 7 : Comparaison des paramètres et des performances pour les implémentations de la détection des piétons sur FPGA

Comme visible dans le tableau 7 ci-dessus, on peut noter que lorsque la mise en œuvre dans cette recherche est comparée aux travaux précédents, les comparaisons montrent des améliorations significatives en termes de rapidité. La carte FPGA peut fonctionner à une fréquence d’horloge de 150 MHz, ce qui signifie que le délai pour accomplir l’ensemble de la tâche est inférieur à 6 ns. Bien que certains travaux antérieurs rapportent un nombre significativement plus élevé de FPS, il est possible d’examiner attentivement que cet avantage se fait au détriment d’une consommation d’énergie plus élevée ainsi qu’une utilisation quasi complète de certaines ressources. Si l’on considère la consommation d’énergie, alors dans ce travail, la puissance déclarée est également inférieure et les utilisations des ressources suggèrent que la consommation de chaque ressource est légèrement supérieure à celle de certaines implémentations, mais égale ou inférieure à 50 % (57 % LUTs, 35 % DSP et 31 % BRAM), ce qui montre une marge significative pour davantage de tâches à implémenter dans cette conception. Dans l’ensemble, on peut affirmer que le travail mis en œuvre dans cet article permet un compromis équilibré entre performance, énergie et utilisation des ressources. De plus, le travail présenté mettait en avant un parallélisme évolutif à travers plusieurs blocs IP sans affecter drastiquement les paramètres de performance.

Dossier supplémentaire 1 : Script_1_train_test.py.Veuillez cliquer ici pour télécharger ce fichier.

Dossier supplémentaire 2 : Script_2_HLS_hog.cpp. Veuillez cliquer ici pour télécharger ce fichier.

Dossier supplémentaire 3 : Script_3_HLS_test_bench.cpp. Veuillez cliquer ici pour télécharger ce fichier.

Fichier supplémentaire 4 : Script_4_HLS_consts.h.Veuillez cliquer ici pour télécharger ce fichier.

Dossier supplémentaire 5 : Script_5_jupyter_code.txt.Veuillez cliquer ici pour télécharger ce fichier.

Discussion

Cette étude met en œuvre efficacement un système de détection des piétons en temps réel utilisant l’algorithme HoG + SVM sur du matériel FPGA avancé basé sur la carte de développement Zynq UltraScale+^{MPSoC 24}. Les résultats indiquent que l’algorithme HoG traditionnel de détection^{humaine 11} atteint une précision proche de 95 % et n’utilise que la moitié des ressources FPGA embarquées (LUT, FF, BRAM, DSP), laissant une énorme capacité d’inclure beaucoup plus de traitement pour effectuer différentes tâches. Lorsque l’ensemble de l’approche de mise en œuvre est analysé, on observe que plusieurs étapes critiques sont impliquées. Une étape majeure consiste à entraîner le modèle^{SVM 18, 19, 24} avec un ensemble de données approprié pour une détection efficace des piétons afin que les poids soient extraits et utilisés dans la programmation FPGA. Le code d’entraînement indiquera la précision des performances, et le seuil de détection doit être soigneusement ajusté via le paramètre de régularisation pour atteindre une précision proche de 95 %. Les paramètres sélectionnés dans l’entraînement sont les descripteurs HoG personnalisés avec une taille de fenêtre de 64 x 128, une taille de bloc de 16 x 16, une taille de cellule de 8 x 8, et un nombre de bins est sélectionné comme 9. Actuellement, la formation a été réalisée sur le jeu de données^{INRIA 11} avec 2416 images positives et 1218 images négatives. L’augmentation inclut la rotation des images pour fournir la version horizontale miroir. D’autres inclusions majeures, comme l’évaluation du modèle dans des conditions de faible visibilité ou de variations d’échelle, seront abordées dans de futurs travaux afin d’assurer la reproductibilité et la robustesse. L’ensemble de données envisagé pour la formation doit inclure des images de piétons dans diverses poses, et il doit également inclure des images ne comportant aucun^{piéton 18,19}.

L’autre étape critique consiste à créer le schéma bloc pour l’ensemble du système afin que la partie PS de la carte FPGA puisse communiquer avec la partie PL. À cette étape, il faut s’assurer que chaque bloc est paramétré avec les bons ports et qu’il est correctement connecté aux autres blocs. L’outil propose également un routage automatique avec des suggestions pour aider le concepteur. Une étape très cruciale est l’attribution des adresses après avoir complété le schéma en blocs. Les IP HoG importées doivent se voir attribuer des adresses en fonction de leur profondeur, et ces adresses ne doivent pas être identiques pour deux IP éventuelles. Ces adresses sont requises dans le code Python sur la carte SD qui aidera la partie PS de la carte FPGA à comprendre l’emplacement d’adresse dans PL auquel elle doit accéder pour lire/écrire les données. Ainsi, l’étape difficile est le développement de l’interface sur la plateforme Python qui permet à l’utilisateur d’alimenter les images/vidéos/flux en direct de la caméra au FPGA, et d’afficher l’image de sortie avec les piétons détectés après avoir reçu les images traitées du FPGA. Le code Python doit être écrit avec divers messages de débogage afin que les résultats intermédiaires puissent être consultés par le concepteur, et en cas d’échec, les erreurs puissent être diagnostiquées et corrigées. Un énorme temps a été consacré à cette recherche pour établir une interface appropriée entre la partie PS et la partie PL. Le script Python de cette interface pouvait accéder aux données des IP HoG après plusieurs itérations, et l’inclusion de plusieurs instructions pour afficher les résultats intermédiaires était très utile pour le dépannage et la correction des erreurs.

Une limitation observée de la méthode est l’utilisation de la partie python pour établir l’interface entre la partie PS et la partie PL du FPGA. Bien que la plateforme Python ait considérablement réduit le temps de conception, elle introduit des surcharges supplémentaires qui impactent les performances en temps réel. Le système accéléré par le matériel de détection des piétons rapportait un débit de 83 FPS, mais les performances globales du système étaient affectées par la latence ou devenaient non réactives lors des tests en direct de la caméra à cause des délais causés par le transfert de données entre le PS et la partie PL. La perspective future offre la possibilité de développer un système complet accéléré par le matériel sans aucune dépendance au logiciel.

Bien qu’il existe des limites comme décrites ci-dessus, la recherche contribue de manière significative car le système développé peut être adapté sans effort à la détection des piétons dans des images fixes, des flux en direct ou des entrées vidéo. Les trois méthodes ne nécessitent que des modifications mineures du code Python sur la plateforme Jupyter, démontrant la rapidité d’adaptation du système à divers scénarios. Les résultats indiquent que la mise en œuvre sur les architectures FPGA avancées donne des résultats encourageants, car les paramètres de performance sont fortement optimisés, ce qui donne des valeurs bonnes et acceptables. La fréquence d’horloge atteinte est comparable à la littérature^précédente 14,15,16,20,23, indiquant que la vitesse n’est pas compromise, tandis que la consommation d’énergie minimale suggère qu’il n’y a pas de problèmes de chauffage. De plus, l’utilisation des ressources montre que toutes les ressources sont utilisées à moins de 50 %, ce qui indique un potentiel significatif pour d’autres améliorations de conception.

Le système développé peut être utilisé dans toute application nécessitant la détection humaine et peut être adapté à des applications en temps réel. De plus, les efforts futurs pourraient se concentrer sur la suppression des limitations mentionnées en développant l’ensemble du système, soit entièrement sur la partie PL, en faisant en sorte que la logique FPGA lise elle-même les images d’entrée et affiche les images de sortie traitées, car près de 50 % des ressources embarquées sont encore disponibles. De plus, si l’intégration PS et PL doit être utilisée, le développement d’interfaces via les outils Software Development Kit (SDK) peut être entrepris. D’autres extensions possibles pourraient être l’identification des piétons dans des conditions météorologiques nettement plus difficiles ou en faible visibilité, ou l’identification des piétons occultés cachés derrière d’autres objets, nécessitant des modifications de l’algorithme. La seule modification requise dans ces cas serait de remplacer les poids entraînés par le SVM après un entraînement approprié selon le défi sélectionné, et le reste du système ne nécessite aucune autre modification. Ainsi, le système mis en œuvre est bien adapté pour s’adapter facilement à d’autres scénarios complexes. Une autre perspective future pourrait être de se concentrer sur l’intégration de fonctionnalités supplémentaires dans le système pour créer un véhicule entièrement autonome utilisant la carte FPGA avancée.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
Python	Python	Version 3.10
Carte FPGA Ultra 96 V2   ;	Xilinx  ;	Introduit en 2018	Plateforme d’implémentation matérielle utilisée pour la mise en œuvre de l’algorithme de détection des piétons
Vivado  ;	AMD	2019.2	Outil de programmation FPGA utilisé pour programmer la carte FPGA Ultra 96 v2 avec l’algorithme de détection des piétons   ;
Vivado HLS  ;	AMD	2019.2	Outil de synthèse de haut niveau utilisé pour la programmation de haut niveau du code de détection des piétons dans l’article afin d’exporter la propriété intellectuelle (PI)