Projektowanie i implementacja programowalnego ramy wykrywania pieszych opartego na polowych tablicach bram dla zastosowań autonomicznej jazdy

Summary

Niniejszy artykuł naukowy demonstruje wdrożenie algorytmu wykrywania pieszych w czasie rzeczywistym na sprzęcie programowalnych w terenie, głównie do zastosowań autonomicznej jazdy. Algorytm łączy histogram gradientów zorientowanych (HoG) z klasyfikatorem maszyny wektorowej wsparcia (SVM), a wyniki pokazują efektywność pod względem szybkości, zużycia energii i wykorzystania zasobów.

Abstract

Autonomiczna jazda to obiecujący sposób na radzenie sobie ze wzrostem liczby ofiar śmiertelnych w wypadkach drogowych. Pojazd autonomiczny oferuje wiele funkcji, ale możliwość wykrywania pieszych jest kluczowa, wymagająca i istotna dla różnych sytuacji w czasie rzeczywistym, takich jak nadzór, śledzenie ludzi czy monitoring. Dokładne rozpoznanie pieszych jest trudne, ponieważ mogą pojawiać się w różnych kształtach, pozycjach i pozach. Mogą nosić różne rodzaje ubrań, czasem częściowo ukryte lub wtapiać się w pobliskie przedmioty. Niniejszy artykuł koncentruje się na wykrywaniu pieszych w czasie rzeczywistym dla samochodów autonomicznych przy użyciu popularnej platformy sprzętowej: programowalnej bramki w polu (FPGA), Ultra 96 v2. Badanie wykorzystuje metodę wykrywania pieszych opartą na histogramie zorientowanych gradientów (HOG) połączoną z klasyfikatorem maszyny wektorowej wspierającej (SVM) do rozpoznawania osób na tablicy FPGA, wykorzystując narzędzia do syntezy wysokiego poziomu (HLS). Skuteczność systemu została przetestowana zarówno na zdjęciach statycznych, jak i na transmisji na żywo. Wyniki pokazują, że zaawansowane płyty FPGA, takie jak Ultra 96 v2, znacząco poprawiają parametry wydajności. System działa z częstotliwością zegara 150 MHz, zużywając mniej niż połowę dostępnych zasobów i zużywając około 2,5 W mocy. Ponadto system raportuje dokładność wykrywania pieszych na poziomie bliskiej 95% oraz inne efektywne wskaźniki oceny wykrywalności, takie jak precyzja (78,6%), przywołanie (88,3%) oraz F1 Score (83,1%). Podsumowując, opracowany system potrafi wykrywać pieszych w czasie rzeczywistym i ma potencjał do znaczącego usprawnienia rozwoju inteligentnego i bezpiecznego środowiska transportowego.

Introduction

Rozwój urbanistyczny i powstawanie inteligentnych miast to tematy zainteresowania na całym świecie. Wszystkie narody pracują nad rozwojem swoich miast, które można budować w taki sposób, by były bezpieczne i komfortowe dla mieszkańców ^1,2. Jednak w obecnej sytuacji zaobserwowano, że wraz ze wzrostem liczby ludności i wzrostem korków na drogach, wskaźnik ofiar śmiertelnych w wypadkach drogowych spowodowanych zaniedbaniami i problemami z widocznością rośnie alarmująco. Obiecującym rozwiązaniem tych problemów jest pojawienie się pojazdów autonomicznych na całym świecie, co zapoczątkowało innowacje 1,2,3,4, a naukowcy podejmują wysiłki, aby opracować w pełni autonomiczne pojazdy, które pozwolą pasażerom odpoczywać bez obaw. Potrzeba rozwoju pojazdów autonomicznych wynika z faktu, że nawet doświadczeni kierowcy mogą doświadczać stresu, dylematów, zmęczenia lub trudności z wyczuwaniem otoczenia z powodu złej pogody, a wszystkie te problemy prowadzą do wypadków drogowych. Pojazd autonomiczny został zaprojektowany tak, aby unikać wypadków podczas podróży, optymalizować wykorzystanie zasobów silnika i przestrzegać przepisów ruchu drogowego, co z pewnością poprawi transport ^2,4. Pojazd autonomiczny wyposażony jest w wiele funkcji, czujników i funkcji, które pozwalają mu bardzo precyzyjnie wykrywać otoczenie, unikając kolizji i wypadków, dlatego stały się obiecującym rozwiązaniem zapewniającym bezpieczeństwo transportu 1,2,3,4.

Spośród wszystkich funkcji wbudowanych w pojazd autonomiczny, jedną z najważniejszych jest wykrywanie pieszych. Solidny system wykrywania pieszych może znacząco pomóc zmniejszyć liczbę ofiar śmiertelnych w wypadkach drogowych 5,6,7,8, ponieważ większość ofiar to piesi. Wykrywanie pieszych polega na identyfikacji osób na drodze i unikaniu kolizji z nimi. Ta funkcja jest korzystna nie tylko dla samochodów autonomicznych, ale także dla różnych innych obszarów zastosowań, takich jak monitorowanie tłumu, identyfikacja osób czy śledzenie ^9,10,11. Kluczowym aspektem tego procesu wykrywania jest szybkość i dokładność wykrywania. Kluczowe jest dokładne i szybkie wykrywanie pieszych, aby czas reakcji był minimalny. Wykrywanie pieszych stanowi ogromne wyzwanie. Piesi na drodze mogą być w dowolnym ubraniu, wyglądzie lub postawie i mogą być niewidoczni z powodu złej pogody lub zasłony^{10, 11, 12, 13, 14}. Co więcej, całkiem możliwe, że piesi sami nie przestrzegają zasad, a nie da się kontrolować ludzkiej natury, więc najlepszym możliwym podejściem jest wyposażenie pojazdu w inteligencję, by radzić sobie z każdym niewłaściwym działaniem i unikać śmiertelnych wypadków. Pełny przebieg prac w tym badaniu oraz motywacje stojące za sprzętową implementacją wykrywania pieszych można łatwo zrozumieć na Rysunku 1 poniżej, który wyjaśnia potrzebę wykrywania pieszych, jego różne obszary zastosowań, wyzwania oraz wdrożenie FPGA w celu wykorzystania oferowanych korzyści.

Rysunek 1: Wykrywanie pieszych. Potrzeba wykrywania pieszych, kluczowe obszary zastosowań wykrywania pieszych, wyzwania związane z wykrywaniem pieszych oraz proces wdrażania detekcji pieszych na tablicy FPGA. Proszę kliknąć tutaj, aby zobaczyć większą wersję tej figurki.

Aby identyfikować pieszych na drodze, istnieje wiele algorytmów. To ogólne zadanie można zasadniczo podzielić na dwa główne podzadania: początkowy etap wyodrębnia cechy z obrazu wejściowego, zachowując tylko te istotne i przekazujące istotne informacje, ignorując te zbędne. Aby skutecznie rozpoznać ludzi lub pieszych na obrazie, kluczowe jest, aby te cechy wskazywały na obecność postaci ludzkiej w scenie^13,14. Po tym wyodrębnieniu cechy muszą zostać przesłane do klasyfikatora, który może określić, czy zidentyfikowane cechy odpowiadają człowiekowi. Dlatego algorytm wymaga fazy ekstrakcji i opisu cech, po której następuje etap klasyfikacji w celu określenia obecności pieszych w scenie wejściowej. Dostępnych jest wiele algorytmów do tego celu. Jednak najbardziej akceptowaną metodą wykrywania pieszych pozostaje połączenie histogramu zorientowanych gradientów (HoG) z klasyfikatorem maszyny wektorowej wspierającej (SVM) 12,13,14,15. Istnieje wiele przykładów postępu programowego, ale ostatecznie celem jest przeniesienie implementacji na kompatybilną platformę sprzętową, która następnie może być zintegrowana z systemem aplikacji do użytku w czasie rzeczywistym. Dlatego obecnie nacisk kładzie się na realizację sprzętową. Można więc stwierdzić, że konieczne jest opracowanie odpowiedniej sprzętowej implementacji systemów wykrywania pieszych, w której kamery wyposażone w odpowiedni sprzęt mogą być instalowane na pojazdach i identyfikować pieszych na drodze. Przy rozważaniu, który sprzęt jest odpowiedni dla takich implementacji, jedną z najczęściej stosowanych opcji jest programowalna macierz bramkowa (FPGA) ze względu na liczne zalety, w tym skrócony czas projektowania, skalowalność, łatwość modyfikacji, możliwość rekonfiguracji oraz niższe zużycie energii i energii^. 15,16,17,18,19,20,21,²².

Płyty FPGA nieustannie ewoluowały i są obecnie szeroko wykorzystywane w złożonych, zaawansowanych aplikacjach widzenia komputerowego, obejmujących zarówno podstawowe przetwarzanie obrazu, wykrywanie obiektów, rzeczywistość rozszerzoną, jak i głębokie uczenie 20,21,22. Obecnie kilka wysokowydajnych płyt FPGA oferuje wyjątkowe możliwości architektoniczne, aby sprostać rozległemu przetwarzaniu wymaganym w tych skomplikowanych zastosowaniach. Jeśli zaawansowane funkcje pojazdów autonomicznych, takie jak wykrywanie pieszych, zostaną zaimplementowane na takich platformach sprzętowych, platformy te mogą być bardzo przydatne do szybkiego tworzenia prototypów analizujących wydajność, a po optymalizacji zaimplementowany algorytm może zostać przeniesiony do rzeczywistych układów scalonych w celu integracji z systemem.

Od ponad dekady ukazują się znaczące publikacje dotyczące implementacji wykrywania pieszych z wykorzystaniem metod HoG i SVM na różnych platformach FPGA. Tabela 1 podsumowuje artykuły z tej dziedziny w latach 2015–2025 15,16,17,18,19,20,21,22,23,24, koncentrując się na kluczowych czynnikach takich jak rozdzielczość obrazu, przepustowość lub liczba klatek na sekundę (FPS), typ klasyfikatora oraz najważniejsze cechy lub wkład wniesiony przez gazetę.

Bibliografia	Platforma FPGA	Rozdzielczość obrazu	Klasyfikator	Kluczowe osiągnięcia / Wkład
15	Xilinx Zynq	640×480	AdaBoost	Implementacja FPGA w czasie rzeczywistym; efektywność zasobów; wykorzystuje binarizację do optymalizacji; Dobra dokładność wykrywania.
16	Płyta DE1-SOC firmy Terasic	640×480	SVM	Wysokowydajny ekstraktor HOG; integruje SVM; detekcja w pojedynczej skali; Pipeline o niskiej latencji.
17	Altera DE2-115	640×480	AdaBoost	Ocenia wyniki z różnych perspektyw; implementacja HOG+AdaBoost przez FPGA; wykrywanie pieszych w czasie rzeczywistym.
18	Intel Stratix V	640×480	SVM	Wieloskalowe wykrywanie pieszych; przyjazny dla FPGA pipeline HOG+SVM; Podkreśla kompromisy między dokładnością a efektywnością sprzętową.
19	Zynq UltraScale+ MPSoC	3840×2160	SVM	przetwarzanie UHD w czasie rzeczywistym; potokowany HOG+SVM; Implementacja FPGA SoC; optymalizacja punktów stałych; Architektura skalowalna.
20	Nieokreślona	Nieokreślona	SVM	Osiąga >95% dokładności wykrywania; implementacja FPGA w czasie rzeczywistym; wykorzystuje paralelizm; szczegółowy projekt FPGA HOG+SVM do wykrywania pieszych.
21	Zync 7000 FPGA	1920×1080	SVM	Architektura strumienia o wysokiej przepustowości dla HOG+SVM; obsługuje rozdzielczość HD; efektywny pipeline do przyspieszania FPGA.
22	Ultra96 (rev1)	240×320	SVM	implementacja FPGA z wykorzystaniem HLS; wykrywa czerwone sygnalizatory świetlne; oblicza prawdopodobieństwa w 891 regionach; Opóźnienia wahają się od 153 838 do 19 cykli.
23	Xilinx Zynq-7000 FPGA	640 × 480	HOG + SVM	Implementowano wykrywanie pieszych za pomocą HOG-SVM na FPGA, osiągając wydajność w czasie rzeczywistym przy mniejszym zużyciu energii w porównaniu z przetwarzaniem CPU. Demonstrowano zoptymalizowany proces ekstrakcji cech odpowiedni do zastosowań z wbudowanym obrazem.
24	Xilinx Virtex-6 FPGA	640 × 480	Detektor obiektów o stałym punkcie (cechy podobne do Haara)	Proponowane przyspieszenie wykrywania obiektów o wysokiej przepustowości FPGA z wykorzystaniem arytmetyki stałych punktów, co zmniejsza koszty obliczeniowe przy zachowaniu dokładności. Pokazano 15× przyspieszenia w porównaniu z implementacjami CPU przy efektywnym wykorzystaniu zasobów sprzętowych.

Tabela 1: Przegląd literatury badań opartych na wykrywaniu pieszych na FPGA (2015–2025).

Tabela 1 podsumowuje, że istnieje obszerna literatura w dziedzinie wykrywania pieszych, a wdrożenie sprzętowe jest obszarem zainteresowania badaczy. Widać również, że istnieją zaawansowane techniki uczenia głębokiego i uczenia maszynowego, takie jak detektory oparte na splotowych sieciach neuronowych (CNN), takie jak YOLO, architektury oparte na transformerach itp., do wykrywania pieszych. Osiągają nawet lepsze wyniki niż tradycyjny algorytm HoG pod względem dokładności, ale przy zastosowaniu sprzętu zaawansowane algorytmy prowadzą do ogromnego wykorzystania zasobów^23,24 ze względu na złożoność algorytmu, która może wpływać także na inne parametry wydajności, a także zaobserwowano, że ze względu na dodatkowe złożoności prędkość jest nieco lepsza w przypadku tradycyjnego algorytmu HoG^24,25. Zaobserwowano również, że zaawansowane techniki zużywają więcej energii przy implementacji na sprzęcie ^24,26. Celem pracy zrealizowanej w tym artykule jest zatem przeprowadzenie wykrywania pieszych przy użyciu tradycyjnych ram HoG i SVM na sprzęcie FPGA oraz osiągnięcie korzystnego kompromisu dokładności, prędkości, zasobów i energii dla osadzania w czasie rzeczywistym. Z Tabeli 1 jasno wynika, że analizując prace oparte na HoG i SVM, można zauważyć, że istnieje niewielka liczba publikacji wykorzystujących niedawno wprowadzoną płytkę rozwojową Zynq UltraScale+ MPSoC (Multi-Processor System On Chip) opartą na FPGA²⁷ do badania możliwości tych płyt, ponieważ z punktu widzenia architektury te płytki się rozwinęły, oraz oferują duży potencjał w zakresie wdrażania zaawansowanych aplikacji do widzenia komputerowego w czasie rzeczywistym. Istnieje niewiele publikacji, które zrealizowały cały system wykrywania pieszych w czasie rzeczywistym na tablicach FPGA. Jednak skupiają się na efektywnej realizacji lub ulepszaniu zadań pośrednich. Co więcej, większość tych implementacji opiera się na realizacji całego systemu na płycie FPGA za pomocą języków opisu sprzętowego. Niewielu z nich wykorzystało zalety narzędzi High Level Synthesis (HLS), aby przyspieszyć cykl projektowy. Niniejszy artykuł demonstruje projektowanie i wdrożenie wykrywania pieszych w czasie rzeczywistym na tablicy FPGA dedykowanej zastosowaniu autonomicznej jazdy. Artykuł wykorzystuje ramy HoG i SVM do wykrywania pieszych na zdjęciach statycznych, wideo lub rzeczywistym wejściu z kamery. Używany sprzęt to nowoczesna i niedawno wydana płyta FPGA, Ultra96 v2, która jest zaawansowaną architekturą FPGA, stanowiącą potężną platformę do widzenia komputerowego, przetwarzania obrazów, uczenia maszynowego, edge computingu ^itd.24. Ultra96 v2 to płyta deweloperska wyposażona w procesor AMD Xilinx Zynq UltraScale+ MPSoC²⁷ oparty na Arm. Ta płyta obejmuje segment systemu przetwarzania (PS), który składa się z rdzeni CPU opartych na ARM zarządzających aspektami programowymi projektu, oraz segment Programmable Logic (PL) umożliwiający konfigurowalną akcelerację sprzętową 20,21,22. Razem te komponenty zwiększają funkcjonalność systemu hybrydowego, gdzie część PS zarządza kontrolą i interakcją z elementami zewnętrznymi, a część PL odpowiada za faktyczną logikę przetwarzania.

Protocol

Procedura implementacyjna zastosowana w tym badaniu, oparta na wykrywaniu pieszych za pomocą HoG + SVM na tablicy FPGA, wykorzystująca korzyści z syntezy wysokiego poziomu, została zilustrowana na Rysunku 2 poniżej.

Rysunek 2: Procedura projektowania implementacji wykrywania pieszych na tablicy FPGA. Faza 1: Algorytm wykrywania pieszych z wykorzystaniem narzędzia HoG+SVM on HLS oraz generowanie bloku IP. Faza 2: Algorytm wykrywania pieszych z wykorzystaniem HoG+SVM do faktycznej implementacji FPGA i generowania pliku bitowego. Faza 3: Programowanie płytki za pomocą wygenerowanego pliku bitowego. Proszę kliknąć tutaj, aby zobaczyć większą wersję tej figurki.

1. Wykrywanie pieszych za pomocą HoG i SVM w narzędziu HLS

1. Pobierz Python Integrated Development Environment (IDE) w zależności od właściwości systemu, na których pobieranie jest wykonywane.
   UWAGA: W tej pracy używa się wersji Python 3.10.
2. Wykonaj skrypt Pythona do uruchomienia modelu treningowego z wykorzystaniem algorytmu HoG i klasyfikatora SVM. Rozpocznij skrypt od załadowania próbek pozytywnych i negatywnych ze zbioru danych.
   UWAGA: Użyj zbioru danych INRIA¹¹.
3. Wyodrębniaj cechy HoG, aby uzyskać wymiar okna 64 x 128.
4. Podziel dane treningowe i testowe z zestawu danych INRIA na stosunek 80/20 z losowym tasowaniem dla powtarzalności.
   UWAGA: Zbiór danych jest losowo tasowany za pomocą funkcji python przed podziałem danych. Aby zapewnić powtarzalność tak, aby za każdym razem, gdy wartość zalążkowa jest ustalana w kodzie, wykonywane jest to samo podział.
5. Trenuj za pomocą SVM klasyfikacji wektorów wsparcia C-support (SVC) z jądrem liniowym.
6. Wyodrębniaj wektory wagowe i błędy.
7. Zachowaj wagi SVM i bias w formacie Q8.8 o stałym punkcie dla implementacji FPGA.
   UWAGA: Konwersja odbywa się poprzez skalowanie wartości zmiennoprzecinkowych oryginalności wygenerowanej o czynnik 256 (2⁸) i odrzucenie wyniku do liczby całkowitej.
8. Przetestuj wytrenowany model za pomocą innego skryptu Pythona i dostosuj parametr regularizacyjny C, aż dokładność zostanie obliczona na ponad 95%.
   UWAGA: Uzyskano zoptymalizowany parametr regularizacji: C = 0,05.
9. Otwórz narzędzie HLS i stwórz nowy projekt z numerem części wybranym jako xczu3eg-sbva484-1-e.
10. Napisz kod wykrywający pieszych w narzędziu do syntezy wysokiego poziomu, korzystając z języków wysokiego poziomu, takich jak C++.
11. W kodzie zapisz trzy różne skrypty C++: jeden dla deskryptora cech HoG i klasyfikatora SVM, drugi dla testbench, aby dostarczać dane do obrazów testowych i zapisywać obrazy wyjściowe, oraz trzeci dla pliku nagłówkowego deklarującego parametry użyte w kodzie.
12. W kodzie do obliczania cech HoG zmieniaj rozmiar obrazu do 640 x 480 i zastosuj architekturę okien przesuwanych o wymiarze okna 64 x 128. Dla każdego okna oblicz gradientową wartość i orientację dla każdego nakładającego się bloku 8 x 8.
    UWAGA: Ważne jest, aby skanować cały obraz przez koncepcję przesuwanego okna, tak aby każdy obszar obrazu był pokryty i zidentyfikowano pieszych o możliwych rozmiarach.
13. W drugiej części tego samego kodu dla deskryptora cech HoG przekaż obliczone gradienty do klasyfikatora SVM. Napisz kod do dopasowania cech do wag klasyfikatora i porównaj z progiem, aby zaklasyfikować wykrytą cechę jako ludzką lub nie.
14. Kliknij na Uruchom symulację C w narzędziu HLS, aby zasymulować kod za pomocą testowego stołu i sprawdzić poprawność funkcjonalności kodu.
15. Dostarcz różne obrazy wejściowe do kodu i sprawdź obrazy wyjściowe z wykrytymi pieszymi.
16. Kliknij na Uruchom syntezę C, aby zsyntetyzować kod i odwzorować go na języki sprzętowe przez narzędzie oraz generować raporty o czasie i wykorzystaniu.
    UWAGA: Narzędzie automatycznie otwiera raporty syntezy HLS. Raport ten przedstawia szacunkowy zakres wymaganej częstotliwości zegara do implementacji zadania kodowanego na wybranej platformie FPGA, a także przedstawia szacunkowy zakres wykorzystanych zasobów. Te raportowane wartości są jedynie szacunkami, a rzeczywiste parametry są obliczane dopiero po wdrożeniu na płycie FPGA.
17. Kliknij Eksport RTL , aby wyeksportować blok własności intelektualnej (IP) dla algorytmu HoG wykrywającego pieszych.
    UWAGA: To IP powinno być używane na późniejszych etapach wdrożenia.

2. Programowanie płyty FPGA

1. Otwórz narzędzie do programowania FPGA i stwórz nowy projekt. Wybierz numer części jako xczu3eg-sbva484-1-e i stwórz nowy projekt bloku.
   UWAGA: Ten diagram blokowy został stworzony, aby ustalić integrację między częścią PS a PL płyty FPGA. Używany protokół komunikacyjny to Advanced eXtensible Interface (AXI).
2. Wyszukaj w narzędziu katalog IP i po znalezieniu go otwórz.
3. Stwórz repozytorium użytkownika, dodając ścieżkę eksportowanego adresu IP RTL w kroku 1.17.
4. W nowym oknie projektowania bloków kliknij prawym przyciskiem myszy i wybierz dodaj IP. Wszystkie adresy IP będą widoczne, w tym te dostarczone przez narzędzie oraz repozytoria dodane przez użytkownika.
5. Dodaj blok PS Zync Ultrascale z repozytorium.
   UWAGA: Ten blok odzwierciedla część PS systemu, odpowiedzialną za generowanie wymaganych zegarów, a także posiada porty master i slave do połączenia z importowanym IP HoG przez blok interconnect AXI, który działa na podstawach protokołu AXI.
6. Dodaj 8 IP HoG , ponieważ system będzie przetwarzał 8 okien jednocześnie, aby wykorzystać zaletę równoległości oferowanej przez płytę FPGA.
7. Dodaj blok resetowania systemu procesorowego , który również steruje zegarem i zasila zasilanie resetowe do każdego bloku na diagramie.
8. Dodaj dwa bloki axi_smart connect do łączenia adresów IP HoG z blokiem PS Zync. Cały diagram blokowy z pełnymi połączeniami przedstawiono na Rysunku 3.
   UWAGA: Jak pokazano na Rysunku 3, wszystkie bloki wymagane do dodania do projektu zostały wyraźnie pokazane. Rysunek 3 został uchwycony z narzędzia i pokazuje wewnętrzne porty każdego bloku oraz połączenia między portami różnych bloków. Ten blok jest głównym projektem, ponieważ odpowiada za ustanowienie interfejsu między PS a częścią PL na płycie FPGA.
9. Po zakończeniu połączeń zgodnie ze Rysunkiem 3 kliknij na "Zweryfikowaj projekt".
   UWAGA: Walidacja zasadniczo sprawdza brakujące lub zerwane połączenia, co może prowadzić do problemów na późniejszych etapach.
10. Kliknij na syntezę , a następnie Implementuj projekt w tool po pomyślnym zatwierdzenie diagramu blokowego.
    UWAGA: Synteza mapuje zaprojektowany schemat blokowy i mapuje go na płycie FPGA. Ten krok zgłosi wszelkie naruszenia, które mogą wskazywać, że projekt nie może być zaimplementowany na sprzęcie.
11. Narzędzie będzie również generować raporty dotyczące czasu, wykorzystania zasobów i zużycia energii. Dokładnie przeanalizuj raporty, aby sprawdzić ewentualne naruszenia czasowe i przeanalizować wydajność zaprojektowanego systemu.
12. Kliknij na Generate the bitstream file , który wygeneruje plik .bit potrzebny do programowania płyty FPGA.

Rysunek 3: Schemat blokowy wykrywania pieszych z użyciem HoG + SVM importowanego IP. Proszę kliknąć tutaj, aby zobaczyć większą wersję tego rysunku.

3. Ostateczna implementacja na płycie FPGA

1. Weź płytę FPGA i włóż kartę SD z odpowiednim plikiem obrazu do slotu na płycie.
2. Podłącz płytę do komputera.
3. Uruchom płytę FPGA w trybie karty SD, aby włączyć programowanie w Pythonie^21,22.
4. Dostęp do platformy jupyter na płytce po podłączeniu do Wi-Fi.
5. Podłącz kamerę internetową do płyty.
6. Napisz kod pythona, aby zaimportować wygenerowany plik bitowy i wykonać zadanie dostępu do obrazów z kamery.
7. W kodzie zapisz skrypt tak, aby obraz był zapisywany w pamięci płyty FPGA przez część PS i przekazywany do części PL do przetwarzania.
   UWAGA: Część PL na płytce odpowiadająca adresom IP HoG uzyskuje dostęp do pikseli obrazu przez te miejsca pamięci, przetwarza je i dostarcza wyniki jako wyjście.
8. Napisz odpowiedni kod w tym samym skrypcie Python, aby odczytać przetworzone obrazy i wyświetlić je na ekranie komputera.
   UWAGA: To kończy cały projekt i system jest gotowy do wdrożenia w rzeczywistych zastosowaniach. Wszystkie kody użyte w tym badaniu są przesyłane jako pliki kodowania uzupełniające (Plik Uzupełniający 1 [Script_1_train_test.py], Plik Uzupełniający 2 [Script_2_HLS_hog.cpp], Plik Uzupełniający 3 [Script_3_HLS_test_bench.cpp], Plik Uzupełniający 4 [Script_4_HLS_consts.h], Plik uzupełniający 5 [Script_5_jupyter_code.txt]).

Results

Implementacja wykrywania pieszych w HLS
Rysunek 4 przedstawia wyniki symulacji w narzędziu HLS do wykrywania pieszych z użyciem HoG + SVM. Obraz wejściowy z pieszym jest podawany jako testowe wejście do kodu, a wyjście z wykrytymi pieszymi jest wyświetlane. Na obrazie są dwie części. Pierwsze wykrywanie ma wiele ramek ograniczających wokół tego samego pieszego wielokrotnie, a na drugim obrazie nakładające się ramki są usuwane i tłumione, pozostawiając jedynie główne pola wykrywania.

Rysunek 4: Wyniki symulacji za pomocą narzędzia HLS. (A,B) Dwa różne obrazy wejściowe oraz powstałe obrazy z wykrytymi pieszymi. Proszę kliknąć tutaj, aby zobaczyć większą wersję tej figurki.

Narzędzie HLS dostarcza również raporty syntetyczne dotyczące czasu i wykorzystania zasobów. Podsumowanie czasowe podkreśla wymagany przez projekt okres czasowy oraz podaje maksymalne i minimalne wartości opóźnień w liczbie cykli. Te informacje są przydatne do oszacowania, ile czasu projekt wymaga na wykonanie oraz jaka powinna być częstotliwość zegara przy przejściu do rzeczywistej implementacji sprzętowej. Tabela 2 poniżej pokazuje raport czasowy po syntezie HLS, który wyraźnie pokazuje, że docelowy okres zegara wynosił 6 ns, a projekt trwał 5,25 ns, co jest mniej niż docelowy, dlatego okres może wynosić 6ns lub więcej, ale nie poniżej 5 ns.

Podsumowanie czasowe
Zegar	Cel	Szacunkowo
	6,00 ns	5,250 ns
Podsumowanie wykorzystania
	Całość / Dostępne	Procent wykorzystania
BRAM18K	22 / 432	5%
DSP48E	13 / 360	3%
FF	5611/ 141120	3%
LUT	9904/ 70560	14%
URAM	0	0

Tabela 2: Szacowany raport o czasie i wykorzystaniu zasobów z narzędzia HLS do wykrywania pieszych z użyciem HoG-SVM.

Tabela 2 również przedstawia raport o wykorzystaniu. Pokazuje procentowe wykorzystanie ważnych zasobów FPGA na pokładzie zgodnie z wybranym planszem docelowym. W przypadku tego projektu wykrywania pieszych raport wykorzystania pokazuje, że projekt zużywa 14% tabel wyszukiwania (LUT), 3% flipflopów (FF), 3% cyfrowego przetwarzania sygnałów (DSP) oraz 5% pamięci o dostępie o losowym dostępie blokowym (BRAM). Te szacunki nie są dokładnymi raportami o wykorzystaniu, ale rzeczywiste raporty są do nich zbliżone. To są tylko szacunki, które mogą być obliczone przez narzędzia HLS. Rzeczywista realizacja zwykle bardzo różni się od tych szacunków.

Rzeczywiste wyniki implementacji wynikające z programowania sprzętowego
Po mapowaniu kodu na adres IP, który jest importowany do narzędzia programistycznego FPGA, a projekt jest zaimplementowany na rzeczywistym sprzęcie FPGA, generowane są również liczne raporty. Pierwszym jest podsumowanie czasowe, które pokazuje, czy częstotliwość zegara podany do projektu jest wystarczający, czy nie. Jeśli wszystkie ograniczenia czasowe są spełnione i nie ma naruszeń, projekt może być kontynuowany. Tabela 3 poniżej przedstawia podsumowanie czasowe wygenerowane przez to narzędzie. Jak pokazano w tabeli, podsumowanie czasowe wskazuje na najgorszy ujemny slack, który wynosi 4,073 ns. Ponieważ ta wartość jest dodatnia, oznacza to, że tyle czasu jest jeszcze dostępne. Wartości ujemne wskazują, że FPGA potrzebuje więcej czasu na wykonanie zadania, a zegar pędzi. Ponieważ w tym przypadku nie ma wartości ujemnych, oznacza to, że ograniczenia czasowe są spełnione.

Podsumowanie czasowania projektu
Przygotowanie	Zatrzymaj	Szerokość impulsu
Najgorszy ujemny luz 4,073 ns	Najgorszy luz trzymania 0,010 ns	Najgorsza szerokość impulsu – luz 3,500 ns

Tabela 3: Rzeczywiste podsumowanie czasowe wykrywania pieszych na tablicy FPGA.

Narzędzie pokazuje również raporty wykorzystania zasobów, czyli rzeczywiste wykorzystanie zasobów pokładowych zgodnie z wybranym planszem FPGA. W tym przypadku wybrana płytka to Zynq UltraScale+ MPSoC (Multi-Processor System On Chip) oparty na FPGA board²⁷. Tabela 4 poniżej przedstawia wykorzystanie zasobów, a Rysunek 5 przedstawia diagramatyczne przedstawienie wykorzystania zasobów.

Podsumowanie wykorzystania wskazuje rzeczywiste zużycie zasobów pokładowych, biorąc pod uwagę, że równolegle używanych jest 8 IPS HoG, a szacunki podane przez syntezę HLS dotyczyły jednego IP HoG. Ale nawet po tak intensywnym wykorzystaniu zasoby dla każdego zasobu jest poniżej 50%. Tabela 4 wyraźnie pokazuje wykorzystanie w odniesieniu do poszczególnych zasobów oraz ich procentowy wskaźnik, co jest przedstawione obrazkowo na Rysunku 5.

Zasoby	Wykorzystanie	Dostępne	Procent wykorzystania
LUT	40536	70560	57.45%
LUTRAM	7304	28800	25.36%
FF	33342	141120	23.63%
BRAM	68	216	31.48%
DSP	128	360	35.56%
BUFG	2	196	1.02%

Tabela 4: Raport rzeczywistego wykorzystania wykrywania pieszych na tablicy FPGA.

Rysunek 5: Wykorzystanie zasobów do wykrywania pieszych na tablicy FPGA po rzeczywistej implementacji. Tabele wyszukiwania (LUT): 57%, LUTRAM: 25%, flip-flopy (FF): 24%, RAM blokowy (BRAM): 31%, cyfrowe procesory sygnału (DSP): 36%, bufory: 1%. Proszę kliknąć tutaj, aby zobaczyć większą wersję tej figurki.

Trzeci raport dotyczy szacunków mocy płyty dla ilości zużycia energii przez projekt. Rysunek 6 poniżej przedstawia raport o zużyciu energii, który pokazuje, że całkowita moc na chipie wynosi 2,435 W. Pokazane są również temperatury złącza oraz zużycie energii przez każdą ważną sieć i element. Pomiary mocy nie wykazują alarmującego zużycia energii, dlatego konstrukcja może być uznana za energooszczędną.

Rysunek 6: Estymacja energii wykrywania pieszych na płycie FPGA po rzeczywistej implementacji. Raport o poborze energii generowany przez narzędzia przedstawia całkowite zużycie energii jako 2,435 W oraz rozkład mocy pomiędzy różne zasoby na tablicy FPGA. Proszę kliknąć tutaj, aby zobaczyć większą wersję tej figurki.

Kolejna analiza ma na celu zrozumienie korzyści płynących z użycia 8 IP HoG zamiast jednego IP HoG lub więcej niż 8 w utworzonym schemacie blokowym, jak pokazano na Rysunku 3. Wskaźniki wydajności sprzętowej były obliczane zarówno dla jednego IP HoG, jak i 8 IP HoG równolegle. Tabela 5 poniżej przedstawia porównanie.

Metryka perfromancji	1 IP	8 IP
Timing (ns)	5.312	~5.25
Częstotliwość (MHz)	188	150
Moc (W)	1.9	2.43
LUT-y	4998	40536
FF / Rejestry	4,031	33,342
DSP	16	128
BRAM	8.5	68
FPS	~10–11	83

Tabela 5: Porównanie wskaźników wydajności przy użyciu pojedynczych i wielu adresów IP HoG.

Tabela 5 wyraźnie wskazuje, że gdy rozpatrujemy zasoby takie jak LUT, FF, DSP i BRAM, to przy jednym IP HoG i 8 IP HoG, skalowanie jest liniowe, z prawie 8-krotnym wzrostem wykorzystania zasobów. Jest to oczywiście oczekiwane, ponieważ więcej IP oznacza większe zużycie zasobów. Ponadto, jeśli zaobserwujemy tę częstotliwość, maksymalna częstotliwość również nieznacznie spada o 20% z 188 MHz do 150 MHz. Jest to również oczekiwane, ponieważ więcej bloków prowadzi do większej liczby połączeń, a co za tym idzie do dłuższych ścieżek, co powoduje wzrost liczby ścieżek krytycznych. Jednak korzystne czynniki, takie jak liczba klatek na sekundę (FPS), poprawiają się z 10 do 83, co pokazuje nieliniowe skalowanie w przypadku FPS dzięki wprowadzonej koncepcji równoległości, wynikającej z 8 IP HoG. Ponadto moc waha się od 1,9 W do 2,4 W, co wskazuje na poprawę efektywności energetycznej dzięki rurolinizacji. Analiza ta wyraźnie wskazuje, że wprowadzenie 8 IP HoG jest korzystne dla projektu, a skalowanie powyżej 8 może powodować nadmierne zużycie zasobów; dlatego liczba bloków powyżej 8 nie jest uznawana za korzystną.

Wyniki wykrywania pieszych po wdrożeniu FPGA
Na koniec cały system jest integrowany na płycie FPGA, a plik bitstream jest generowany, który jest następnie programowany na płycie za pomocą karty SD uruchamianej z programowalnością Pythona. Po uruchomieniu płyty za pomocą karty SD można uzyskać dostęp do interfejsu jupytera oraz napisać i uruchomić kod w Pythonie na platformie. Kod Pythona jest uruchamiany i testowany pod kątem wykrywania pieszych na różnych obrazach wejściowych. Wynik kilku zdjęć przedstawiono na Rysunku 7 poniżej. Obrazy te są wykorzystywane z zestawu danych INRIA oraz losowych zdjęć pieszych uzyskanych z otwartych źródeł online^26,27.

Rysunek 7: Wyniki wykrywania pieszych na statycznych obrazach za pomocą FPGA Board. Testowane obrazy obejmują obrazy z zestawu danych INRIA, otwarte obrazy dostępne w Google do testowania dokładności wykrywania na zatłoczonych ulicach Indii. Proszę kliknąć tutaj, aby zobaczyć większą wersję tej figurki.

System jest również testowany na podstawie rejestrowania klatek w czasie rzeczywistym przez kamerę internetową i wykrywania pieszych w kadrze, a także na już nagranych sygnałach wideo pieszych. Wyniki tego pokazano na Rysunku 8 i 9. Rysunek 8 przedstawia zestaw przykładowych klatek zarejestrowanych przez kamerę internetową oraz wyniki wykrywania pieszych w każdej klatce, natomiast Rysunek 9 pokazuje wyniki wykrywania pieszych zaimplementowane na wideo wejściowym dostarczonym do systemu.

Rysunek 8: Wyniki wykrywania pieszych na klatce zarejestrowanej przez kamerę w czasie rzeczywistym przez płytę FPGA. Rejestrowanie wideo w czasie rzeczywistym kamerą internetową 720 P i demonstracja wykrywania pieszych w czasie rzeczywistym. Rozmyte obrazy powstają podczas robienia migawek z trwającego nagrania na żywo. Proszę kliknąć tutaj, aby zobaczyć większą wersję tej figurki.

Rysunek 9: Wyniki wykrywania pieszych na nagraniach wideo dostarczanych jako dane wejściowe do tablicy FPGA. Filmy pochodzą z linków open source. Proszę kliknąć tutaj, aby zobaczyć większą wersję tej figurki.

Szacowanie metryk wydajności
Aby obliczyć efektywność i przeanalizować wydajność powyższego wdrożonego projektu, niezbędne jest obliczenie wskaźników efektywności, które są przydatne do oceny efektywności. Metryki wydajności wykrywającej efektywność algorytmu detekcji zasadniczo zależą od wartości prawdziwych pozytywnych wyników (TP), prawdziwych negatywów (TN), fałszywych pozytywów (FP) oraz fałszywych negatywów (FN). Z tych wartości można obliczyć wskaźniki wydajności, takie jak precyzja, przypomnienie, wynik F1, fałszywie pozytywne wyniki na obraz oraz dokładność zgodnie z poniższymi równaniami. Zaobserwowano, że większość artykułów naukowych raportuje ich skuteczność wykrywania za pomocą parametru dokładności. Zaobserwowano jednak, że obliczenia dokładności wymagające TN mogą być mylącym parametrem, ponieważ wartości TN nie da się prawidłowo obliczyć, gdyż polega na znalezieniu liczby wszystkich okien detekcji na obrazie, który faktycznie nie ma pieszego, a zaimplementowany algorytm również raportuje to jako brak wykryć. Ta liczba jest zazwyczaj bardzo duża, ponieważ łączna liczba okien detekcji na obrazie jest duża, a obszary tła na każdym zdjęciu zazwyczaj odpowiadają regionom bez pieszych. Dokładnie analizując wzór na dokładność przedstawiony w równaniach [1] – [5], można zauważyć, że ponieważ wartość TN będzie dość wysoka w porównaniu do TP+FP+FN, parametr dokładności zwykle ma wysoką wartość. Aby naprawdę ocenić wyniki, znacznie lepiej jest podać wskaźniki takie jak precyzja, przypomnienie i wynik F1, które nie zależą od TN i są znacznie dokładniejsze.

[1]

[2]

[3]

[4]

[5]

Aby znaleźć wartości TP, TN i FN dla tego artykułu, eksperyment na nieruchomych obrazach powtórzono na ogromnej liczbie obrazów. Na podstawie wyników każdego obrazu obliczano wartość prawdziwych pozytywnych wyników, czyli liczby prawidłowo wykrytych pieszych, fałszywie pozytywnych, liczby błędnie wykrytych pieszych oraz fałszywych negatywów, czyli faktycznych pieszych, którzy pozostali niewykryti. Następujące wartości zostały przedstawione po przeprowadzonych eksperymentach i przedstawione są w Tabeli 6 poniżej.

Metryka wydajności	Wartość
TP	143
FP	39
FN	19
Precison	0.786 (78.6%)
Przypomnienie	0.883 (88.3%)
Wynik F1	0.831 (83.1%)
FPPI	0.867

Tabela 6: Metryki wydajności dla algorytmu wykrywania pieszych opartego na FPGA.

Tabela 6 powyżej opisuje zatem dokładność algorytmu wykrywania pieszych poprzez różne wskaźniki wydajności, precyzję, przywołanie, wynik F1 oraz FPPI, gdy algorytm jest implementowany na platformie sprzętowej.

Porównanie wydajności z istniejącymi implementacjami HoG opartymi na FPGA
Wreszcie, wykonaną pracę można porównać z wcześniejszą literaturą, aby wskazać istotny wkład tych badań. To porównanie przedstawiono w tabeli 7 15,16,17,21,24 poniżej. Artykuły, z którymi przeprowadza się porównanie, opierają się na aplikacjach wykrywania pieszych zaimplementowanych na platformach FPGA, a algorytmy stosowane do tych detekcji są również takie same dla wszystkich, czyli HoG połączony z klasyfikatorem, którym jest albo Adaboost, albo SVM. Rozmiar obrazu jest również taki sam dla każdego (640 × 480). Porównanie opiera się na parametrach takich jak częstotliwość zegara wpływająca na prędkość, liczba klatek na sekundę, zużycie energii oraz wykorzystanie zasobów w kategoriach LUT, DSP, pamięci, wycinków i rejestrów. Aby wywołać uczciwe porównanie, rozważane artykuły badawcze mają podobną rozdzielczość obrazu, a aby znormalizować porównanie zasobów, każde wykorzystanie zasobów jest normalizowane przez podzielenie liczby zużytych zasobów przez całkowitą liczbę dostępnych zasobów według użytej tablicy FPGA.

Bibliografia	Rozmiar obrazu	Tablica FPGA	Częstotliwość zegara	Liczba klatek na sekundę (FPS)	Zasilanie	Piksele /zegar	LUTs (%)	DSP48s (%)	BRAMs / memory Bits (%)	Rejestry/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	Cyklon 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
TO DZIEŁO	640 x 480	Ultra 96 v2	150 MHz	83	2,435W	0.0632	57	35	31	24

Tabela 7: Porównanie parametrów i wydajności dla implementacji wykrywania pieszych w FPGA

Jak widać w Tabeli 7 powyżej, można zauważyć, że porównanie implementacji w tym badaniu z poprzednimi pracami pokazuje znaczącą poprawę pod względem szybkości. Płyta FPGA może pracować z częstotliwością zegara 150 MHz, co oznacza, że czas wykonania całego zadania jest krótszy niż 6 ns. Chociaż niektóre wcześniejsze prace zgłaszały znacznie wyższe FPS, poprzez dokładną analizę można przeanalizować, że ta przewaga wiąże się z wyższym zużyciem energii oraz niemal całkowitym wykorzystaniem niektórych zasobów. Jeśli uwzględnić zużycie energii, to w tej pracy raportowana energia jest również niższa, a wykorzystanie zasobów sugeruje, że zużycie każdego zasobu jest nieco wyższe niż w niektórych implementacjach, ale równe lub mniejsze niż 50% (57% LUT, 35% DSP i 31% BRAM), co wskazuje na znaczne pole do realizacji kolejnych zadań w tym projektowaniu. Ogólnie można stwierdzić, że prace realizowane w tym artykule osiągają zrównoważony kompromis między wydajnością, energią a wykorzystaniem zasobów. Dodatkowo prezentowane prace wykazały skalowalny równoległość poprzez wiele bloków IP bez drastycznego wpływu na parametry wydajności.

Plik uzupełniający 1: Script_1_train_test.py.Kliknij tutaj, aby pobrać ten plik.

Plik uzupełniający 2: Script_2_HLS_hog.cpp. Kliknij tutaj, aby pobrać ten plik.

Plik uzupełniający 3: Script_3_HLS_test_bench.cpp. Kliknij tutaj, aby pobrać ten plik.

Plik uzupełniający 4: Script_4_HLS_consts.h.Kliknij tutaj, aby pobrać ten plik.

Plik uzupełniający 5: Script_5_jupyter_code.txt.Kliknij tutaj, aby pobrać ten plik.

Discussion

To badanie skutecznie implementuje system wykrywania pieszych w czasie rzeczywistym, wykorzystujący algorytm HoG + SVM na zaawansowanym sprzęcie FPGA opartym na tablicy rozwojowej Zynq UltraScale+ MPSoC²⁴. Wyniki wskazują, że tradycyjny algorytm HoG wykrywania ludzkiego¹¹ osiąga dokładność bliską 95% i wykorzystuje tylko połowę zasobów FPGA na pokładzie (LUT-y, FF, BRAM, DSP), pozostawiając ogromne możliwości włączenia znacznie większej ilości przetwarzania do wykonywania różnych zadań. Podczas analizy całego podejścia wdrożeniowego zauważa się, że zaangażowane są różne kluczowe kroki. Jednym z głównych kroków jest wytrenowanie modeli SVM^{18, 19, 24} z odpowiednim zbiorem danych do skutecznego wykrywania pieszych, tak aby wagi były wyodrębniane i wykorzystywane w programowaniu FPGA. Kod treningowy wskaże dokładność wydajności, a próg wykrywania musi być starannie dostrojony przez parametr regularizacji, aby osiągnąć dokładność bliską 95%. Wybrane parametry w treningu to niestandardowe deskryptory HoG o rozmiarze okna 64 x 128, bloku 16 x 16, komórce 8 x 8 oraz liczbie pojemników wybranych jako 9. Obecnie trening przeprowadzono na zbiorze danych INRIA¹¹, obejmując 2416 obrazów pozytywnych i 1218 obrazów negatywnych. Augmentacja obejmuje obrót obrazów, aby uzyskać poziomą wersję lustrzaną. Inne istotne elementy, takie jak ocena modelu w warunkach słabej widoczności lub zmienności skali, zostaną uwzględnione w przyszłych badaniach, aby zapewnić powtarzalność i odporność. Zbiór danych rozpatrywany do szkolenia musi zawierać obrazy pieszych w różnych pozach, a także obrazy, na których nie ma pieszych^18,19.

Drugim kluczowym krokiem jest stworzenie schematu blokowego dla całego systemu, tak aby część PS na płycie FPGA mogła komunikować się z częścią PL. W tym etapie należy upewnić się, że każdy blok jest parametryzowany z odpowiednimi portami i prawidłowo połączony z pozostałymi blokami. Narzędzie oferuje także automatyczne trasowanie z sugestiami wspierającymi projektanta. Bardzo ważnym krokiem jest przypisanie adresu po ukończeniu diagramu blokowego. Importowane adresy IP HoG muszą być przypisane do ich głębokości, a te adresy nie mogą być takie same dla dwóch adresów. Te adresy są wymagane w kodzie pythona na karcie SD, co pomoże części PS na płycie FPGA zrozumieć lokalizację adresu w PL, do której ma dostęp do odczytu/zapisu danych. Dlatego najtrudniejszym etapem jest rozwój interfejsu na platformie Python, który pozwala użytkownikowi przesyłać obrazy/filmy/transmisję z kamery na żywo do FPGA oraz wyświetlać obraz wyjściowy wykrytym pieszym po otrzymaniu przetworzonych obrazów z FPGA. Kod Pythona musi być napisany z różnymi komunikatami debugującymi, aby projektant mógł zobaczyć wyniki pośrednie, a w przypadku awarii błędy mogły zostać zdiagnozowane i poprawione. Poświęcono ogromną ilość czasu na te badania nad ustanowieniem właściwego interfejsu między częścią PS a PL. Skrypt Python dla tego interfejsu potrafił uzyskać dostęp do danych IP HoG po kilku iteracjach, a dodanie kilku instrukcji wyświetlających wyniki pośrednie było bardzo pomocne w rozwiązywaniu problemów i korygowaniu błędów.

Jednym z zaobserwowanych ograniczeń metody jest wykorzystanie części python do ustanawiania interfejsu między PS a częścią PL FPGA. Platforma Python znacznie skróciła czas projektowania, ale wprowadza dodatkowe narzuty, które wpływają na wydajność w czasie rzeczywistym. System wykrywania pieszych, przyspieszany sprzętowo, raportował przepustowość 83 FPS, jednak ogólna wydajność systemu była pogorszona przez opóźnienia lub stała się nieresponsywna podczas testów kamer na żywo z powodu opóźnień spowodowanych transferem danych między PS a częścią PL. Perspektywa przyszłości daje możliwość opracowania kompletnego systemu przyspieszanego sprzętowo, bez uzależnienia od oprogramowania.

Chociaż istnieją ograniczenia, jak opisano powyżej, badania znacząco przyczyniają się do tego, ponieważ opracowany system można bezproblemowo dostosować do wykrywania pieszych na zdjęciach nieruchomych, transmisjach na żywo lub wejściach wideo. Wszystkie trzy metody wymagają jedynie drobnych modyfikacji kodu Pythona na platformie Jupyter, co pokazuje szybką adaptację systemu do różnych scenariuszy. Wyniki wskazują, że implementacja na zaawansowanych architekturach FPGA przynosi zachęcające rezultaty, ponieważ parametry wydajności są wysoko optymalizowane, co skutkuje dobrymi i akceptowalnymi wartościami. Osiągnięta częstotliwość zegara jest porównywalna z wcześniejszymi materiałami 14,15,16,20,23, co wskazuje, że prędkość nie jest obniżona, a minimalne zużycie energii sugeruje brak problemów z nagrzewaniem. Dodatkowo, wykorzystanie zasobów pokazuje, że wszystkie zasoby są wykorzystywane poniżej 50%, co wskazuje na znaczący potencjał do dalszych ulepszeń projektowych.

Opracowany system może być wykorzystywany w każdej aplikacji wymagającej wykrywania ludzi i może być dostosowany do zastosowań w czasie rzeczywistym. Ponadto przyszłe wysiłki mogą skoncentrować się na usuwaniu wspomnianych ograniczeń poprzez rozwój całego systemu całkowicie na stronie PL, poprzez umożliwienie logice FPGA samodzielnie odczytywania obrazów wejściowych i wyświetlania przetworzonych obrazów wyjściowych, ponieważ prawie 50% zasobów na pokładzie jest nadal dostępnych. Jeśli integracja PS i PL ma być wykorzystana, można rozpocząć rozwój interfejsu za pomocą narzędzi Software Development Kit (SDK). Inne możliwe rozszerzenia mogą obejmować identyfikację pieszych w znacznie trudniejszych warunkach pogodowych lub w słabej widoczności, albo identyfikację zasłoniętych pieszych ukrytych za innymi obiektami, co wymaga modyfikacji algorytmu. Jedyną modyfikacją wymaganą w takich przypadkach jest wymiana ciężarów trenowanych SVM po odpowiednim treningu zgodnie z wybranym wyzwaniem, a reszta systemu nie wymaga żadnych dodatkowych modyfikacji. Dzięki temu zaimplementowany system doskonale nadaje się do łatwego dostosowania się do innych wymagających scenariuszy. Inną perspektywą na przyszłość może być skupienie się na wdrożeniu dodatkowych funkcji do systemu, aby stworzyć w pełni autonomiczny pojazd z wykorzystaniem zaawansowanej płyty FPGA.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
Python	Python	Wersja 3.10
Ultra 96 V2 płyta FPGA	Xilinx	Wprowadzony w 2018 roku	Platforma implementacyjna sprzętowa używana do implementacji algorytmu wykrywania pieszych
Vivado	AMD	2019.2	Narzędzie programistyczne FPGA używane do programowania płyty FPGA Ultra 96 v2 z algorytmem wykrywania pieszych
Vivado HLS	AMD	2019.2	Narzędzie do syntezy wysokiego poziomu używane do programowania wysokopoziomowego kodu wykrywania pieszych w artykule w celu eksportu własności intelektualnej (IP)