Ta strona używa ciasteczek (plików cookies), dzięki którym może działać lepiej. Dowiedz się więcejRozumiem i akceptuję

OpenMV – przetwarzanie obrazu na STM32

Recenzje 11.04.2017 Elvis

Po długim oczekiwaniu dotarła do mnie w końcu płytka OpenMV, więc mogłem zabrać się za testy. W tym artykule postanowiłem podzielić się moimi spostrzeżeniami, które pojawiły się podczas pierwszych testów.

Z założenia, platforma ta miała umożliwić szybki start z przetwarzaniem obrazu na STM32.

OpenMV to kolejny startup, jego twórcy mieli na celu stworzenie platformy do komputerowego przetwarzania obrazu w oparciu o mikrokontroler. W dużym uproszczeniu, można powiedzieć, że OpenMV to kamerka, micro-python oraz biblioteki do rozpoznawania obrazu pracujące na STM32.

Więcej informacji znaleźć można na stronie projektu. Nie ukrywam, że moje pierwsze skojarzenie było: „to nie zadziała”. Jednak po usłyszeniu bardzo pochlebnych opinii o tym projekcie postanowiłem zaryzykować i zamówić płytkę.

Zamówienie zajmuje tylko chwilę, ale pokazuje pierwszy i chyba najpoważniejszy
problem tego projektu – jego cenę.

Sama płytka kosztuje 75$. Jednak to nie koniec kosztów. Dochodzi przesyłka – 26$, a zanim obierzemy paczkę trzeba jeszcze wypełnić deklarację celną… I zapłacić VAT, czyli dodatkowe 23% plus koszty obsługi. Razem wyszło trochę ponad 100 USD plus trochę ponad 100 zł… Czyli jakieś 500 zł patrząc po dzisiejszym kursie dolara.

Cena trochę zaporowa, ale skoro pieniądze już wydane, nie ma co narzekać, czas rozpakować nową zabawkę. Płytka przychodzi w kopercie, wystarczy przykręcić obiektyw do kamerki, podłączyć kabelek USB (nie jest dołączany do zestawu) i można zaczynać zabawę.

Oprogramowanie OpenMV

Niewątpliwym plusem projektu jest przygotowane oprogramowanie. Możemy pobrać bardzo proste w obsłudze (bo wzorowane mocno na arduinowym) środowisko programistyczne.

Programy piszemy w micro-pythonie, co jest faktycznie bajecznie proste. Osoby które kiedyś lubiły Bascom-a, powinny pokochać ten dialekt języka. Zamiast skomplikowanej zabawy z rejestrami mamy banalne, bardzo intuicyjne programowanie wysokopoziomowe.

Do płytki dołączone są biblioteki obsługujące większość modułów peryferyjnych, w tym oczywiście samą kamerkę. Więcej o bibliotekach znajdziemy w udostępnionej dokumentacji.

Bardzo sympatyczna jest opcja podglądu bufora obrazu – w prawej części okna widzimy obraz prosto z mikrokontrolera. Spowalnia to trochę przetwarzanie, ale bardzo ułatwia eksperymenty.

Razem ze środowiskiem programistycznym dostajemy też sporą liczbę przykładów (podobnie jak do Arduino). Nie ukrywam, że pierwsze godziny minęły mi na zabawie tymi właśnie programami. Niestety szybko wyszły pierwsze problemy. Okazuje się, że nie wszystkie programy działają. Część działa tylko na wybranych płytkach, a ich uruchomienie kończy się zawieszeniem układu.

Sprzęt dostępny na OpenMV

Zanim przejdziemy dalej, krótkie podsumowanie sprzętu, który znajdziemy w OpenMV:

  • mikrokontroler STM32F427 (Cortex-M4, 180MHz, 1MB flash, 256KB SRAM),
  • przetwornik obrazu OV7725 (VGA 0.3 Mpx, 640×480),
  • gniazdo kart micro-sd,
  • gniazdo micro-usb do komunikacji i zasilania,
  • dioda RGB oraz IR,
  • 9 pinów I/O.

Szczegóły widoczne są na poniższej grafice:

Ogólne wrażenia

Nie ukrywam, że początki zabawy z płytką były fantastyczne, byłem pod dużym wrażeniem możliwości układu. Jednak pierwsze oczarowanie szybko minęło.

Pierwsze, co mnie zaskoczyło, to rozdzielczość obrazu z kamery. O ile przetwornik obsługuje rozdzielczość VGA (0.3 Mpx), to już sama płytka maksymalnie pracuje w QVGA, czyli 320×240.

Daje to „oszałamiającą” rozdzielczość 0.08 Mpx.

Kolejne rozczarowanie, to liczba klatek na sekundę. Rozdzielczość już znamy, FPS co ciekawe jest bardzo zmienny… Bywa, że możemy osiągnąć 30 FPS, a najczęściej jest to jednak 10-12 klatek, ale jeśli zasłonimy kamerę to wynik spadnie do 8 FPS.

W zależności od obrazu otrzymujemy różną ilość FPS.

Trochę poszukałem na ten temat w dokumentacji i jest to chyba spowodowane kompresją. Co ciekawe efekt występuje zarówno przy włączonym, jak i wyłączonym podglądzie obrazu.

Drugie rozczarowanie to algorytmy przetwarzania obrazu. Niby działają, ale porównywanie ich z OpenCV, to jakby porównywać małego fiata i ferrari. Oba jeżdżą, ale to tyle podobieństw. Kolejną rzecz, która szybko mnie rozdrażniła, to micro-python. Fakt, na mikrokontrolerze nie można oczekiwać cudów, to nie jest jednak pełny Python – trzeba pamiętać o wielu ograniczeniach.

Wcześniej używałem Pythona na Raspberry i innych płytkach
opartych na Linuksie, stąd moje rozczarowanie.

Więcej informacji na temat płytki znaleźć można na stronie zakończonej kampanii (Kickstarter):

Podsumowanie

Pierwsze momenty z OpenMV były zaskakująco pozytywne – projekt daje łatwą i szybką możliwość spróbowania sił z komputerowym przetwarzaniem obrazu.  Niestety euforia szybko zamieniła się w rozczarowanie.

STM32 jest jednak tylko mikrokontrolerem i do przetwarzania obrazu
po prostu brakuje mu mocy i pamięci.

Nie pomaga też oparcie projektu na micro-pythonie, który chociaż miły, łatwy i wygodny, to jednak zabiera cenne zasoby. Natomiast tym co moim zdaniem dyskwalifikuje ten projekt jest jego cena. Za cenę płytki OpenMV można kupić Raspberry 3 z czterema rdzeniami Cortex-A, 1GB pamięci, kamerą 5 Mpx i pełnym Pythonem. Gdybym miał drugi raz kupować taką płytkę, to wybrałbym coś innego. Moim zdaniem to tylko bardzo droga ciekawostka.

Plusy:

  • łatwe w instalacji i obsłudze środowisko,
  • podgląd bufora obrazu,
  • prosty język programowania,
  • „zaskakujące, ale to działa”.

Minusy:

  • cena, cena, cena,
  • za słaby mikrokontroler,
  • za mało pamięci RAM,
  • koszmarnie niska rozdzielczość,
  • bardzo mała liczba klatek na sekundę,
  • ograniczone możliwości bibliotek, szybko dochodzi konieczność pisania w C lub asm,
  • brak możliwości pracy zdalnej,
  • bardzo mało wyprowadzonych pinów.

Powiadomienia o nowych, darmowych artykułach!

Komentarze

deshipu

9:08, 11.04.2017

#1

> Trochę poszukałem na ten temat w dokumentacji i jest to chyba spowodowane kompresją. Co ciekawe efekt występuje zarówno przy włączonym, jak i wyłączonym podglądzie obrazu.

To nie powinno mieć miejsca. Przy wyłączonym podglądzie powinno działać dużo szybciej i tak się dzieje u mnie. Niestety przepychanie obrazu przez kabel zajmuje czas.

> Nie pomaga też oparcie projektu na micro-pythonie, który chociaż miły, łatwy i wygodny, to jednak zabiera cenne zasoby. Natomiast tym co moim zdaniem dyskwalifikuje ten projekt jest jego cena. Za cenę płytki OpenMV można kupić Raspberry 3 z czterema rdzeniami Cortex-A, 1GB pamięci, kamerą 5 Mpx i pełnym Pythonem. Gdybym miał drugi raz kupować taką płytkę, to wybrałbym coś innego. Moim zdaniem to tylko bardzo droga ciekawostka.

Moim zdaniem nie powinieneś porównywać tego do mini-komputerów produkowanych po taniości w Chinach, tylko do innych mikrokontrolerowych kamer, takich jak w http://forbot.pl/blog/artykuly/recenzje/czy-do-arduino-mozna-podlaczyc-kamere-test-arducam-id17843 -- bo to je ma OpenMV zastępować. Stąd też mała liczba nóżek -- założenie jest takie, że podłączasz to do swojego projektu ze swoim mikrokontrolerem.

BlackJack

9:56, 11.04.2017

#2

Znawcą nie jestem, ale z tego co widzę, to wyprowadzone są praktycznie same porty komunikacyjne SPI, CAN, RS232 chyba też. MCU nie zamiata, szczegulnie te 256KB RAM, ale na upartego po napisaniu własnego softu powinno coś tam umieć.320x240 pix to 64KB RAM x2 na bufor ramki daje zaledwie 50% RAMu, czy miejsce na obróbkę danych jest, tylko widocznie algorytm kuleje. Dziwne bo ten STM32 ma chyba FPU, ma na pewno DMA, więc można powiedzieć optymalizacja softu leży i kwiczy, ale podobnie jest z BASCOMem, tam też to leży. Ogólnie wydaje mi się że to ma być zwykła kamerka VGA, z możliwością wstępnego przygotowania danych (kompresja, filtracja itp.) a resztę ma jednak robić zewnętrzne CPU pokroju np. RAPi 0.

Ale przy tej cenie to jakieś nieporozumienie.

Elvis
Autor wpisu

11:01, 11.04.2017

#3

Testowałem przy wyłączonym podglądzie, program tylko pobierał dane z kamery, a wysyłał czasy - wychodziła bardzo widoczna zależność od widzianego obrazu. O ile rozumiem nawet w pamięci przechowywany jest jpeg - i to mogłoby tłumaczyć różne czasy.

Nie rozumiem dlaczego nie można porównywać OpenMV do RPi - szczególnie zero jest dość podobnym rozwiązaniem. Tylko że raspberry wymiata dzięki GPU, a różnica w cenie, rozdzielczości i wydajności jest kolosalna.

Porównując z ArduinoCam - faktycznie jest lepiej. Ale używając taniej płytki z Cortex-A i dodatkową pamięcią może być znacznie lepiej. Wcale nie musi być Rpi. Na kickstarterze jest chociażby projekt snickerdoodle - za 95$ jest 2x Cortex-A9, a do tego FPGA... Do niedawna płytki były po 65$, ale chyba się nie opłacało. https://www.crowdsupply.com/krtkl/snickerdoodle

Gdyby OpenMV kosztowało 50zł polecałbym każdemu jako fajną płytkę. Za 100zł byłaby to ciekawostka, ale trochę za droga. Przy obecnej cenie, to delikatnie mówiąc - niezbyt optymalne rozwiązanie. Za podobne, a nawet mniejsze pieniądze można mieć inne płytki.

[ Dodano: 11-04-2017, 11:57 ]

BlackJack, 320x240 to 76800. Na każdy piksel przypadają 2 bajty, więc bufor obrazu to równo 150kB. Dlatego więcej niż QVGA nie działa, a na resztę kodu niewiele zostaje. Inna sprawa, że np. płytki discovery po prostu mają dołączoną pamięć zewnętrzną. I wtedy chociaż wolniej, ale można więcej danych przetwarzać http://www.st.com/en/evaluation-tools/32f429idiscovery.html

deshipu

11:58, 11.04.2017

#4

Elvis napisał/a:

Testowałem przy wyłączonym podglądzie, program tylko pobierał dane z kamery, a wysyłał czasy - wychodziła bardzo widoczna zależność od widzianego obrazu. O ile rozumiem nawet w pamięci przechowywany jest jpeg - i to mogłoby tłumaczyć różne czasy.

Nie bardzo, bo czarny jpeg powinien być mniejszy od takiego z jakimś obrazem, a u ciebie wyniki sugerują coś odwrotnego.

Elvis napisał/a:

Nie rozumiem dlaczego nie można porównywać OpenMV do RPi - szczególnie zero jest dość podobnym rozwiązaniem. Tylko że raspberry wymiata dzięki GPU, a różnica w cenie, rozdzielczości i wydajności jest kolosalna.

Dlatego, że wtedy porównujesz komputer z systemem operacyjnym rozwijanym przez 50 lat przez setki ludzi, środowiskiem uruchomieniowym rozwijanym przez 20 lat przez dziesiątki ludzi i bibliotekami do grafiki rozwijanymi przez 10 lat przez kilkunastu ludzi, produkowany masowo w większości w Chinach (tylko montowany jest w UK) z części, które i tak by się nie sprzedały do niczego innego, przez producenta samych czipów, który na tym praktycznie nie zarabia, z hobbystycznym projektem zrobionym w trzy lata po godzinach przez dwójkę ludzi, którzy przy tym zaliczyli na kickstarterze wpadkę, która prawie położyła projekt, bez systemu operacyjnego, ze środowiskiem uruchomieniowym, które ma 3 lata (a było całkowitą nowością jak zaczynali), z bibliotekami napisanymi przez nich w większości od zera (wydajniejszymi niż te w OpenCV), produkowanym w porządnej fabryce w ilościach kilkudziesięciu sztuk na raz. Tak, różnice są kolosalne, bo porównujesz jabłka do pomarańczy.

Elvis napisał/a:

Porównując z ArduinoCam - faktycznie jest lepiej. Ale używając taniej płytki z Cortex-A i dodatkową pamięcią może być znacznie lepiej. Wcale nie musi być Rpi. Na kickstarterze jest chociażby projekt snickerdoodle - za 95$ jest 2x Cortex-A9, a do tego FPGA... Do niedawna płytki były po 65$, ale chyba się nie opłacało. https://www.crowdsupply.com/krtkl/snickerdoodle

Jest podstawowa różnica pomiędzy "mogłoby być" a "jest". Wydaje się tobie, że można by coś takiego zrobić i intuicja podpowiada ci, że byłoby to lepsze. Ale problem w tym, że dopóki to nie istnieje, to jest to tylko gdybanie i nie wiesz tak naprawdę czy nie przeoczyłeś jakichś dodatkowych czynników, które spowodowałyby, że jednak lepiej by nie było. OpenMV istnieje w tej chwili, działa da się testować. Jestem całkowicie pewien, że w planach i teorii też miał działać znacznie lepiej i być tańszy.

Elvis napisał/a:

Gdyby OpenMV kosztowało 50zł polecałbym każdemu jako fajną płytkę. Za 100zł byłaby to ciekawostka, ale trochę za droga. Przy obecnej cenie, to delikatnie mówiąc - niezbyt optymalne rozwiązanie. Za podobne, a nawet mniejsze pieniądze można mieć inne płytki.

Gdyby OpenMV kosztowało 50zł, to bym kupował, rozlutowywał i sprzedawał części. 100zł to kosztuje oryginalne Arduino UNO. Tak, oczywiście, można kupić w Chinach płytki za 10zł, które nawet jakoś działają jak się samemu w nich wymieni wadliwy rezystor. Ale zrobienie na nich tego, co na OpenMV masz od kopa zajęłoby ogarniętemu studentowi kilka lat pracy.

BlackJack

23:16, 11.04.2017

#5

Elvis napisał/a:

[ Dodano: 11-04-2017, 11:57 ]

BlackJack, 320x240 to 76800. Na każdy piksel przypadają 2 bajty, więc bufor obrazu to równo 150kB. Dlatego więcej niż QVGA nie działa, a na resztę kodu niewiele zostaje. Inna sprawa, że np. płytki discovery po prostu mają dołączoną pamięć zewnętrzną. I wtedy chociaż wolniej, ale można więcej danych przetwarzać http://www.st.com/en/evaluation-tools/32f429idiscovery.html

Faktycznie mały błąd nie wiem czemu przyjąłem 8-bitową głębie koloru. W takim razie tym bardziej dziwne że nie wzięli MCU z co najmniej 521KB RAM, albo nie dodali zewnetrznego.

deshipu

0:56, 12.04.2017

#6

Jest możliwość zapisywania klatek do flasha i z tego, co pamiętam rzeczywiście wtedy jest dostępna wyższa rozdzielczość. Tylko tak jak piszecie, jest wtedy wolniej. Za to da się na przykład porównywać ze starszą klatką, żeby wykrywać migające rzeczy.

Elvis
Autor wpisu

7:09, 12.04.2017

#7

Zapis do flasha? To nawet nie jest śmieszne... Sprawdzałeś kiedyś jakie są czasy zapisu i ile cykli kasowania wytrzymuje flash? Podpowiem: skasowanie 128kB sektora trwa nawet 2s (sekundy!). Typowy czas to 1s - a na jedną ramkę potrzebujemy trochę więcej. Co do żywotności flasha to znalazłem coś o 100.000 zapisów. Jeśli to prawda, jest to bardzo dobry wynik. Ale przy 30FPS wystarczyłby na niecałą godzinę pracy...

Pamięć flash jest świetna, ale do tego zastosowania się nie nadaje.

deshipu

9:54, 12.04.2017

#8

100000 zapisów to raczej nie jest to, musiałeś gdzieś zjeść jakieś zera.

Szkoda, że Raspberry Pi domyślnie właśnie tak robi, ze swapem na karcie SD :D

Elvis
Autor wpisu

10:07, 12.04.2017

#9

Na karcie SD masz wbudowany mikrokontroler odpowiedzialny za wear-leveling. 100.000 zapisów to całkiem niezły wynik dla pamięci NOR w mikrokontrolerze. Jeszcze nie tak dawno standardem było 10-20k zapisów. W przypadku SD lub SSD odpowiedni nadmiar wolnych sektorów oraz sprytne algorytmy dodają te brakujące zera - i dlatego to może działać. A rpi, jak i cały linux stara się zapisy buforować w DDR więc to też trochę oszczędza czas i żywotność pamięci. Na stm32 po prostu brakuje na to zasobów.

[ Dodano: 12-04-2017, 10:08 ]

BTW skąd pomysł swapa na SD? Takiej konfiguracji nie używa się w embedded - bo i jaki sens miałby swap na flash? Chyba pomyliło Ci się z linuxem na PC.

marek1707

10:31, 12.04.2017

#10

No niestety tu Elvis ma rację. Wśród pamięci nielotnych technologia FLASH ma najgorszą trwałość. Do tego dochodzi fakt, że FLASHe procesorów nie muszą być mega-odporne, bo nie służą do częstych zmian. Hobbysta może bawić się w wielokrotne ładowanie nowego kodu do tej samej płytki. W procesie pisania nowej aplikacji w całkiem profesjonalnym urządzeniu także "flashujemy" proca setki razy, ale docelowo, w produkcji dużo ważniejszy jest czas utrzymywania informacji w czasie i w temperaturze. Wciąż są procesory mające "tylko" 10 tys. gwarantowanych zapisów a standardem dziś jest rzeczywiście 100 tys. Istnieją co prawda programy/biblioteki emulujące np. EEPROM na stronach pamięci FLASH, ale to zawsze jest ryzyko i trzeba mieć świadomość zagrożeń. A Malina rzeczywiście domyślnie używa karty w sposób tragiczny i jest to powodem padania nawet najlepszych egzemplarzy po miesiącu ciągłej pacy jako np. domowy serwer plików. Nie pomagają tu ani "kroczące" systemy plików ani wyrównywanie obciążeń sektorów robione w tle przez kontroler SD. FLASH szybko się degraduje i nie ma na to rady. Trochę pomagają kody korekcyjne ECC, które stały się w tych (większych) pamięciach standardem, ale to właśnie z ich pomocą osiągamy te 100 tys. bezbłędnych zapisów.. A gdy weźmiemy pod uwagę czas i temperaturę, tj. pracę takiej pamięci bez okresowego odświeżania zawartości stron, to jest jeszcze gorzej :(

Wszystko to wynika z technologii: małe komórki umożliwiają dużą gęstość upakowania (stąd pojemności idące w Gb), ale okupione są dużymi prądami upływu i szybkim zapominaniem. Szybkie zapisy z kolei (kilka us /bajt, w porównaniu do EEPRMów np) wymagają dużych prądów wstrzykiwania ładunku i skutkują szybką degradacją izolacji bramek tranzystorów pamiętających. Cóż, coś za coś :-|

BlackJack

11:59, 13.04.2017

#11

Tak wracając do teg RAMu, jakoś nie chce mi się wierzyć że nie da się zaimplementować w takim CPU bezstratnego algorytmu kompresji działającego w locie np wykorzystać zmodernizowany standard GIF, co najmniej kompresja 2x, LZW sądzę da średnio 2,5x albo nawet 3, a są to standardy dosyć dobrze opisane, w C.

Elvis
Autor wpisu

12:13, 13.04.2017

#12

To raczej jest pytanie po co to robić. Teoretycznie OpenMV ma pozwalać na przetwarzanie obrazu - a na skompresowanej wersji będzie to trudniejsze (i wolniejsze). Dla obrazu 320x240 pamięci wystarcza, co prawda tylko na jedną kopię, ale zawsze. Gdybyśmy chcieli przechować obraz VGA, czyli 640x480 to otrzymamy: 640 * 480 * 2B = 614400B = 600kB. Czyli kompresja musiałaby osiągnąć współczynnik 2,34x, a jednocześnie nie używać ani jednego bajtu pamięci (i program też nie miałby już nic).

Moim zdaniem cała ta zabawa nie ma sensu. Taniej i łatwiej jest wykorzystać lepszy sprzęt, o Cortex-A już wspominałem, ale nawet na STM32 jest inna opcja: http://www.st.com/en/evaluation-tools/32f429idiscovery.html a do tego kamerka. Na płytce mamy wtedy 8MB pamięci SRAM i wyświetlacz w gratisie.

Oczywiście szybko zabraknie mocy przerobowych w MCU, ale można chociaż próbować. Jak dla mnie wykorzystywanie STM32 do przetwarzania obrazu to jak rajdy małymi fiatami - trzeba mieć fantazję.

deshipu

13:27, 13.04.2017

#13

Skoro macie tyle pomysłów jak to zrobić lepiej, to na co jeszcze czekacie? :-)

Osobiście jestem pewien, że autorzy OpenMV wszystkie te opcje o których piszecie wypróbowali i odrzucili z takiego czy innego powodu. Ale oczywiście zawsze jest szansa, że się kompletnie nie znają i wasze pomysły są lepsze. Jest tylko jeden sposób na przekonanie się o tym. Oni swój projekt zrobili, gdzie są wasze?

Elvis
Autor wpisu

13:38, 13.04.2017

#14

Ja nie uważam, żeby warto było tworzyć nowy projekt od zera - a jak uzyskać podobny efekt na rpi pewnie niedługo pojawi się na forum.

BlackJack, tylko wspominał o wykorzystaniu pamięci, to chyba nic złego podyskutować o możliwych opcjach. Chociaż wcale nie twierdzę że na STM32 w ogóle da się sensowne przetwarzanie obrazu zrobić.

A w końcu forum jest chyba od wymiany doświadczeń i opinii. Trochę nieładnie podchodzić - nie zrobiłeś projektu w tej dziedzinie, to nie masz prawa się odzywać. Gdybyśmy przyjmowali takie podejście chyba niewiele osób miałoby możliwość zabierać głos.

deshipu

13:52, 13.04.2017

#15

Przepraszam, masz rację. Nadal wydaje mi się, że takie teoretyzowanie "w powietrzu" ma bardzo dużą szansę na przeoczenie bardzo konkretnych i rzeczywistych problemów, no ale w końcu nikt nic tu nie buduje, więc to nic nie szkodzi, bo się z tymi problemami nie spotka. A podróżowanie palcem po mapie też może przyjemność sprawiać.

Zobacz powyższe komentarze na forum

FORBOT Damian Szymański © 2006 - 2017 Zakaz kopiowania treści oraz grafik bez zgody autora. vPRsLH.