Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Jak OpenCV działa na STM32 - benchmark

ghost666 24 Sep 2021 14:48 1857 8
Computer Controls
  • OpenCV uruchamiany jest głównie na wysokowydajnych platformach obliczeniowych czy mocnych mikroprocesorach, ale pakiet ten może wykonywać kilka rodzajów aplikacji do przetwarzania obrazu na prostych mikrokontrolerach.

    Przetwarzanie obrazu stało się częścią naszego życia. Nikogo nie dziwi rozpoznawanie twarzy w smartfonie czy wykrywanie pasa ruchu przez samochód. Obecnie najpowszechniejszą biblioteką wykorzystywaną do tych celów jest OpenCV. Obecnie OpenCV koncentruje się głównie na platformach i mikroprocesorach o wysokiej wydajności (HPC). Chociaż mikrokontrolery wyższej klasy mają zasoby porównywalne z procesorem Pentium II, nadal bardzo rzadko uruchamia się na nich programy wykorzystujące OpenCV.

    Jakiś czas temu pokazano już, że istnieje możliwość wykorzystania OpenCV na układach z rodziny STM32 (i innych mikrokontrolerach podobnej klasy). Celem tego artykułu jest zademonstrowanie użycia tej biblioteki na podobnych platformach sprzętowych. Mimo że uzyskano w testach bardzo niską wydajność, to jeszcze do niedawna nie wiedziano, jaka jest przyczyna tego stanu rzeczy. W tym artykule poprawiono oczywiste niedociągnięcia pierwszych testów. Pozwala to osiągnąć wyższą wydajność. Dodatkowo, w poniższym artykule przedstawiono wyniki pomiarów wydajności dla różnych przykładów wykorzystania OpenCV na platformie STM32F7.

    Wszystkie przykłady w artykule są oparte na systemie Ebox RTOS i można je odtworzyć, postępując zgodnie z instrukcjami w repozytorium z przykładami. W przykładach używana jest flaga optymalizacji -Os. Wszystkie przykłady używają włączonej pamięci podręcznej procesora. Pliki danych mogą znajdować się na karcie SD. Obrazy przechowywane są w pamięci Flash QSPI, który znajduje się na płytce deweloperskiej, aby uprościć podstawowe instrukcje podczas odtwarzania wyników.

    Wykorzystano płytkę demonstracyjną STM32F769i-Discovery. Na płytce znajdują się dwa rodzaje pamięci ROM: 2 MB wbudowanej pamięci Flash i 64 MB zewnętrznej pamięci Flash QSPI. Ponadto dostępne są dwa typy pamięci RAM: 512+16+4 KB na chipie i 16 MB zewnętrznej pamięci SDRAM.

    Wykrywanie krawędzi

    Zacznijmy przykładu, który był już wcześniej testowany, a mianowicie wykrywania krawędzi. W przykładzie zastosowano algorytm Canny'ego. W artykule prezentowane jest kompletne wyjście z programu dla tego procesu. Dla pozostałych przykładów zawarte są tylko tabelki z porównaniem wyników.

    Próbka analizowanego obrazu:

    Jak OpenCV działa na STM32 - benchmark


    ObrazCzas przetwarzania przy wykorzystaniu wewnętrznej pamięci Flash (ms)Czas przetwarzania przy wykorzystaniu zewnętrznej pamięci QSPI Flash (ms)
    fruits.png 512×269116120
    fruits.png 512×480254260


    Jak OpenCV działa na STM32 - benchmark


    K-means

    Ten przykład z OpenCV określa klastry punktów i kreśli koło dookoła nich, opierając się na miarze, którą OpenCV opisuje jako kompaktowość ("compactness") - sumę kwadratów odległości każdego puntu od środka tego okręgu. Zasadniczo jest to metoda, która pozwala na określenie "środka masy" dla punktów.

    Skrypt kmeans.cpp generuje obraz o rozdzielczości 480 x 480 z kilkoma klastrami punktów o różnym kolorze. Środek każdego z klastrów jest wybierany losowo, a punkty dodawane są w odległości opisywanej rozkładem normalnym.

    KompaktowośćCzas przetwarzania z pamięci ROM (ms)Czas przetwarzania z pamięci QSPI (ms)
    7335893498
    160406618
    3314471438
    7062801336
    399182825


    Jak OpenCV działa na STM32 - benchmark


    Kwadraty

    Rozpoznawanie kształtów geometrycznych, w szczególności prostokątów, to jeden ze standardowych przykładów z biblioteki OpenCV. Przykład analizowanego obrazka (pic6.png w tabelce) pokazano poniżej.

    Jak OpenCV działa na STM32 - benchmark


    Wyniki dla analizy obrazków o rozdzielczości 400×300 umieszczono w poniższej tabelce:

    ObrazCzas przetwarzania z pamięci ROM (ms)Czas przetwarzania z pamięci QSPI (ms)
    pic1.png13121668
    pic2.png48937268
    pic3.png12631571
    pic4.png23513590
    pic5.png12351515
    pic6.png15752202


    Jak OpenCV działa na STM32 - benchmark


    Wykrywanie twarzy

    Rozpoznawanie twarzy było pierwotnie przedstawionym celem badań. Chciano oszacować, jak dobrze podobne algorytmy działają na płytkach z mikrokontrolerami. Skorzystano ze standardowego przykładu „wykrywania twarzy” z zestawem pięciu obrazów. Przykłady wykorzystują wykrywanie kaskadowe Haara. Poniżej pokazano przykładowy analizowany obraz:

    Jak OpenCV działa na STM32 - benchmark


    Rezultaty dla obrazów o rozdzielczości 256×256:

    ObrazCzas przetwarzania z pamięci ROM (ms)Czas przetwarzania z pamięci QSPI (ms)
    seq_256x256/img_000.png33893801
    seq_256x256/img_001.png40154454
    seq_256x256/img_002.png40164464
    seq_256x256/img_003.png33153717
    seq_256x256/img_004.png35263952


    Rezultaty dla obrazów o rozdzielczości 480×480:

    ObrazCzas przetwarzania z pamięci ROM (ms)Czas przetwarzania z pamięci QSPI (ms)
    seq_480x480/img_000.png1440616149
    seq_480x480/img_001.png1478416578
    seq_480x480/img_002.png1510616904
    seq_480x480/img_003.png1269514352
    seq_480x480/img_004.png1465516446


    Jak OpenCV działa na STM32 - benchmark


    Wykrywanie osób

    Autorzy testów chcieli także uruchomić bardziej złożone algorytmy, takie jak wykrywanie ludzi. W tym celu uruchomili przykładowy skrypt "peopledetect’ z OpenCV, który oparty jest na analizie histogramów zorientowanych gradientów (HOG). Poniżej pokazano przykładowy obraz:

    Jak OpenCV działa na STM32 - benchmark


    Wyniki testów:

    ObrazCzas przetwarzania z pamięci ROM (ms)Czas przetwarzania z pamięci QSPI (ms)
    basketball2.png 640×4804034752587


    Jak OpenCV działa na STM32 - benchmark


    Kody QR

    Kody QR są szeroko wykorzystywane do zapisy informacji, które można łatwo odczytywać. Do analizy kodu QR wykorzystuje się algorytmy rozpoznawania kształtów. W tym przykładzie wykorzystano QR w formie kwadratu, otoczonego ramką. System tyko wykrywa lokalizację kodu, ale w tym przykładzie nie analizuje jego zawartości. Przykładowe zdjęcie zostało pobrane z Internetu.

    Jak OpenCV działa na STM32 - benchmark


    Wynik:

    ObrazCzas przetwarzania z pamięci ROM (ms)Czas przetwarzania z pamięci QSPI (ms)
    qrcode_600x442.png3092


    W tym przykładzie użyto różnych wywołań funkcji, więc do końcowego obrazu wstawiany jest inny kod. Dlatego, gdy próbowano zbudować ten skrypt, nie mógł on korzystać z wewnętrznej pamięci Flash i z tego powodu wyniki pochodzą tylko z analizy z wykorzystaniem danych z QSPI.

    Jak OpenCV działa na STM32 - benchmark


    Specyfika pracy na mikrokontrolerach

    Jest kilka godnych uwagi aspektów, które autorzy porównania wykryli, podczas pracy z OpenCV na mikrokontrolerach. Po pierwsze, kod z pamięci wewnętrznej działa szybciej niż z zewnętrznej pamięci Flash QSPI, nawet przy włączonej pamięci podręcznej.

    Drugim, ich zdaniem, również powiązanym z pamięcią podręczną, jest zależność wydajności od lokalizacji kodu. Okazuje się, że drobne zmiany w kodzie, takie jak wstawienie polecenia, które nie jest wywoływane, może zwiększyć lub zmniejszyć wydajność nawet o 5% lub więcej.

    Trzeci to ograniczony rozmiar pamięci wewnętrznej. Nie było możliwe szybkie uruchomienie przykładu z wykrywaniem kodów QR z wewnętrznej pamięci Flash.

    Kolejna ważna cecha dotyczy samych rdzeni ARM Cortex-M. Wykorzystywano rdzenie procesora obsługujące instrukcje SIMD. Technologia ta pomaga zwiększyć wydajność, wykonując tę ​​samą operację na wielu punktach danych w jednym rejestrze jednocześnie. Aby oszacować, czy ma to wpływ na wydajność w podobnych zadaniach, przeprowadzono pomiary w systemie operacyjnym Linux z obsługą instrukcji SIMD i bez niej i stwierdzono, że w niektórych przykładach, takich jak wykrywanie kwadratów, użycie SIMD zwiększa wydajność nawet o 80%, jednak przyspieszenie zależne jest od zastosowanego algorytmu.

    W przypadku wykorzystanych rdzeni procesora istnieje tylko wsparcie w postaci funkcji wewnętrznych. Innymi słowy, konieczne jest ręczne wstawienie tych poleceń. OpenCV wspiera to podejście - można zaimplementować obsługę SIMD dla niestandardowej architektury. Ale w tej chwili obsługa OpenCV w SIMD jest zaprojektowana do pracy tylko z długimi typami danych (128 bitów i więcej), podczas gdy rdzeń Cortex-M7 obsługuje tylko rejestry 32-bitowe. W związku z tym praca ta nie wykorzystuje poprawy wydajności podczas korzystania z SIMD na STM32. Autorzy porównania mają jednak nadzieję, że będzie to kierunek ich przyszłych badań.

    Podsumowanie

    Wyniki te wskazują, że bardzo złożone oprogramowanie, takie jak OpenCV, może być używane na małych mikrokontrolerach. Kilka przykładów zostało uruchomionych i wszystkie działały pomyślnie. Jednak wydajność jest zauważalnie niższa niż w przypadku większych platform.

    Wykorzystanie OpenCV na mikrokontrolerach jest silnie uzależnione od celów. Większość podstawowych algorytmów działa niezauważalnie dla oka. Wykrywanie krawędzi realizuje się w ułamku sekundy; ta wydajność może wystarczyć autonomicznemu robotowi. Można również zastosować złożone algorytmy, takie jak przetwarzanie kodów QR, ale konieczna jest każdorazowa ocena zalet i wad takiego rozwiązania. Z jednej strony 3 sekundy wymagane do zakończenia wykrywania twarzy mogą być dla niektórych aplikacji długim czasem, ale z drugiej strony dla niektórych celów może być to wystarczająco szybkie.

    Dlatego okazuje się, że takie platformy nie są jeszcze wystarczająco wydajne, aby rozpoznawać złożone obiekty, na przykład identyfikować osobę. Opóźnienie jest bardzo zauważalne w porównaniu z rozpoznawaniem tego samego obrazu na większym systemie. Musimy jednak również zrozumieć, że w tym badaniu porównano mikrokontrolery z 64-bitowym procesorem Intel-i7 z 8 rdzeniami i zasadniczo inną częstotliwością taktowania - zużycie energii i koszt tych platform są oczywiście zupełnie inne. Poza tym porównanie nie dotyczyło najpotężniejszego mikrokontrolera - STM32 ma serię H7, która ma ponad dwukrotnie większą wydajność niż testowane tutaj elementy.

    Na poniższym filmie przedstawiono część testów wykonanych w ramach opisywanego badania:



    Powielanie wyników

    Możesz odtworzyć wyniki uzyskane w artykule. Potrzebujesz do tego dwóch repozytoriów. Główne repozytorium Ebox (Link) oraz repozytorium z przykładowymi obrazami i gotowymi konfiguracjami dla płyty STM32F769i-discovery (Link). Aby odtworzyć wyniki, postępuj zgodnie z instrukcjami w pliku README z repozytorium próbek.

    Można również użyć innych płyt, jednak konieczne może być przygotowanie konkretnej konfiguracji Emboxa dla tych modułów. Można również eksperymentować z innymi obrazami lub przechowywać obrazy na karcie SD, ale wymaga to również zmiany konfiguracji Emboxa.

    Źródło: https://www.embedded.com/benchmarking-opencv-on-stm32-mcus/

    Cool! Ranking DIY
    Can you write similar article? Send message to me and you will get SD card 64GB.
    About Author
    ghost666
    Translator, editor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    ghost666 wrote 10586 posts with rating 8937, helped 157 times. Live in city Warszawa. Been with us since 2003 year.
  • Computer Controls
  • #2
    victoriii
    Level 18  
    Mam wrazenie ze w tabelce z fruits.png 512×480 zabraklo jeszcze jednej cyferki dla przetwarzania z QSPI.
  • #3
    ghost666
    Translator, editor
    victoriii wrote:
    Mam wrazenie ze w tabelce z fruits.png 512×480 zabraklo jeszcze jednej cyferki dla przetwarzania z QSPI.


    Racja, skorygowałem. Dziękuję za uwagę i czujność.
  • Computer Controls
  • #4
    _johnny_
    Level 6  
    A esp32 mówi potrzymaj mi piwo. St strzeliło sobie w kolano przez swoje zatory produkcyjne. Układy są cholernie drogie i niedostępne. Na szczęście espressif to dobrze wykorzystał, trzyma normalne stany magazynowe i mają bardzo dobre wsparcie dla ESP-IDF.
  • #5
    ghost666
    Translator, editor
    _johnny_ wrote:
    A esp32 mówi potrzymaj mi piwo. St strzeliło sobie w kolano przez swoje zatory produkcyjne. Układy są cholernie drogie i niedostępne. Na szczęście espressif to dobrze wykorzystał, trzyma normalne stany magazynowe i mają bardzo dobre wsparcie dla ESP-IDF.


    Ciekaw jestem, jak ESP32 radzi sobie w komercyjnych aplikacjach np. w przemyśle. Ja znam głównie od strony Arduino, a ciekawe by było wykorzystać to w czymś "poważniejszym".
  • #6
    krisRaba
    Level 31  
    Hmm, a w jakim sensie miałoby sobie nie poradzić?
    Wydaje mi się, że jeśli w jakimś zastosowaniu radzi sobie na biurku, nie sypie się w nieokreślony sposób i ma dla danego celu wystarczające peryferia, to możliwość zastosowania w trudnych warunkach najczęściej sprowadza się do odpowiedniego projektu PCB oraz stosowania rozwiązań zmniejszających podatność na różne zakłócenia.

    Bo prawda jest taka, że można skaszanić projekt na niby przemysłowych układach i nie będzie to poprawnie działać, a można też jakieś wrażliwe układy tak dobezpieczyć i filtrować, że "nie zauważą", że pracują w trudnych warunkach ;)

    Dodano po 4 [minuty]:

    Chyba że masz na myśli stricte komunikację radiową, a nie działanie samego scalaka.. to różnie może być, bo na dobrą komunikację też będzie wpływać sporo czynników, jak choćby moc nadajnika, sposób zabudowy itp.
  • #7
    ghost666
    Translator, editor
    krisRaba wrote:
    Hmm, a w jakim sensie miałoby sobie nie poradzić?
    Wydaje mi się, że jeśli w jakimś zastosowaniu radzi sobie na biurku, nie sypie się w nieokreślony sposób i ma dla danego celu wystarczające peryferia, to możliwość zastosowania w trudnych warunkach najczęściej sprowadza się do odpowiedniego projektu PCB oraz stosowania rozwiązań zmniejszających podatność na różne zakłócenia.

    Bo prawda jest taka, że można skaszanić projekt na niby przemysłowych układach i nie będzie to poprawnie działać, a można też jakieś wrażliwe układy tak dobezpieczyć i filtrować, że "nie zauważą", że pracują w trudnych warunkach ;)

    Dodano po 4 [minuty]:

    Chyba że masz na myśli stricte komunikację radiową, a nie działanie samego scalaka.. to różnie może być, bo na dobrą komunikację też będzie wpływać sporo czynników, jak choćby moc nadajnika, sposób zabudowy itp.



    Głównie to mam na myśli oprogramowanie - STM32 ma cały swój ekosystem, HALa, CubeMX i ogromną ilość informacji w sieci. ESP32 - nie wiem. Może to dobry moment, żeby się dowiedzieć...
  • #8
    krisRaba
    Level 31  
    Hmm, to może za jakiś czas Ci powiem, bo ostatnio kupiłem devkita z ESP32, żeby wybadać z czym to się je. Czeka tylko na zamknięcie wcześniejszych tematów.
    Dotąd pracowałem sporo właśnie z STM32. O ile ekosystem spoko, to wg mnie HAL jakością nie powala(ł) i bardzo dużo rzeczy i tak pisałem swoich.
    Wiele przykładów, co to niby uruchamia się gotowe rozwiązanie w 10 czy 30 minut (według marketingu) to też zwykle tylko w obrębie konkretnego przykładu demo, a jak chce się coś konkretnie, co nieco odstaje w jakiś sposób od przykładu, to już dłuższa rzeźba... Stąd nie jest to tak, że w ramach ekosystemu wszystko jest gotowe i podane na tacy ;)
    Zwykle rzeczy uniwersalne i "nakładki" wprowadzają swoje ograniczenia. Bezpośrednio na sprzęcie da się często zrobić więcej.
  • #9
    ghost666
    Translator, editor
    krisRaba wrote:
    Hmm, to może za jakiś czas Ci powiem, bo ostatnio kupiłem devkita z ESP32, żeby wybadać z czym to się je. Czeka tylko na zamknięcie wcześniejszych tematów.
    Dotąd pracowałem sporo właśnie z STM32. O ile ekosystem spoko, to wg mnie HAL jakością nie powala(ł) i bardzo dużo rzeczy i tak pisałem swoich.
    Wiele przykładów, co to niby uruchamia się gotowe rozwiązanie w 10 czy 30 minut (według marketingu) to też zwykle tylko w obrębie konkretnego przykładu demo, a jak chce się coś konkretnie, co nieco odstaje w jakiś sposób od przykładu, to już dłuższa rzeźba... Stąd nie jest to tak, że w ramach ekosystemu wszystko jest gotowe i podane na tacy ;)
    Zwykle rzeczy uniwersalne i "nakładki" wprowadzają swoje ograniczenia. Bezpośrednio na sprzęcie da się często zrobić więcej.



    Absolutnie się z Tobą zgadzam, jednakże z mojego doświadczenia, to większość rzeczy, jakie się robi, nie potrzebują dużo więcej, niż to co jest w HALu...

    Daj znać jak z ESP32, koniecznie :). Tutaj albo w innym wątku lub napisz PW.