Skocz do zawartości

OpenMV - przetwarzanie obrazu na STM32


Komentator

Pomocna odpowiedź

html_mig_img
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.

UWAGA, to tylko wstęp! Dalsza część artykułu dostępna jest na blogu.

Przeczytaj całość »

Poniżej znajdują się komentarze powiązane z tym wpisem.

Link do komentarza
Share on other sites

> 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 https://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.

Link do komentarza
Share on other sites

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.

Link do komentarza
Share on other sites

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

Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

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.

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.

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.

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.

Link do komentarza
Share on other sites

[ 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.

Link do komentarza
Share on other sites

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.

Link do komentarza
Share on other sites

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.

Link do komentarza
Share on other sites

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.

Link do komentarza
Share on other sites

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ś 😐

Link do komentarza
Share on other sites

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.

Link do komentarza
Share on other sites

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ę.

Link do komentarza
Share on other sites

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?

Link do komentarza
Share on other sites

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.

Link do komentarza
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Anonim
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.

×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.