No to zaczynamy

Wpadła mi w ręce Re:Camera od Seeed. W zasadzie to małe pudełeczko (kostka o krawędzi 4 cm), opasane radiatorem. W środku dwurdzeniowy MPU na bazie RISC-V (aktualizacja: w systemie widoczny jest tylko jeden rdzeń, drugi jest najprawdopodobniej zarezerwowany dla operacji specjalnych), wiekowy mikrokontroler 8051, sensor kamery od OmniVision, diody do podświetlenia, Wi-Fi, BT, no i różne peryferia. Pamięci RAM jest malutko, zaledwie 256 megabajtów, więc postawienie Greengrass będzie problematyczne. Można podłączyć Ethernet przez specjalny kabelek-przejściówkę, który ledwo się trzyma, ale do developmentu nie ma to sensu, bo kamera udostępnia sieć po USB typu C i prościej tak pracować. Jeśli brakuje pamięci (a urządzenie jest dostępne w wariantach z 8 GB i 64 GB wbudowanej pamięci), można wsadzić kartę MicroSD. Pudełko można też przyczepić do czegoś metalowego, bo z jednej strony ma magnesiki.

alt text

Po podłączeniu można otworzyć stronę internetową (domyślnie 192.168.42.1), która sama z siebie nic nie potrafi, oprócz udostępnienia konfiguracji Wi-Fi i aktualizacji. Jest tam też konsola, ale kto normalny używa konsoli w przeglądarce, gdy ma się SSH?

Podejrzewam, że da się z tym coś zrobić i w obecnym stanie, ale instrukcja usilnie sugeruje aktualizację przez OTA, co też uczyniłem (choć to może oczywiste, najpierw trzeba skonfigurować sieć). Po 5 minutach aktywnego migania diodami i podłączania/odłączania się urządzenia od komputera, sprzęt dał mi dostęp do już zaktualizowanej strony i zażądał zmiany domyślnego hasła (recamera/recamera). Zmiana tego hasła zmienia również hasło dostępowe do SSH, więc ostrożnie.

Po aktualizacji pojawia się dostęp do Node-RED, takiego graficznego środowiska programistycznego, w którym przepływy danych opisuje się grafami z nodami-przetwarzaczami. Domyślnie taki graf jest już załadowany i daje dostęp do prostego dashboardu, który pozwala podejrzeć obraz z kamery i wyniki działania modelu AI YOLOv11. Inne grafy można (teoretycznie) pobrać ze strony SenseCraft AI od Seeed, ale wymaga ona rejestracji, więc olałem temat.

alt text

O kamerze

Sensor zamontowany w pudełku jest, szczerze mówiąc, przestarzały. To OmniVision OV5647, 5-megapikselowa kamera z migawką typu rolling shutter. Całkiem niedawno robiłem demko z sensorem BrightSense od STMicro, wyposażonym w global shutter, zbierającym informacje z matrycy jednocześnie, a nie linia po linii, jak tutaj. Przełożyło się to na rozdzielczość (tylko 1,5 megapiksela), ale za to szybko spadające cukierki łapała idealnie. O wszystkich “urokach” rolling shuttera można poczytać na Wikipedii, ale w dwóch słowach: jeśli widzieliście, jak w filmach pięknie pokazują różne rzeczy wciągane do czarnej dziury, no to właśnie to. Seeed obiecuje, że będzie można podłączać inne sensory i że w przyszłości wypuszczą nowe warianty, w tym z kamerą global shutter, ale na razie jest jak jest.

The window should be staight
The window should be straight

Dlaczego ważne są niezniekształcone obiekty? Ano ze względu na model. Do którego teraz przejdziemy.

O modelu

No, nie do końca. Najpierw o tym, na czym to śmiga. W pudełeczku siedzi NPU o wydajności całego jednego TOPS-a. Przy 8-bitowej kwantyzacji, rzecz jasna, w liczbach zmiennoprzecinkowych (float) to on nie potrafi. Jak coś optymalizować pod to NPU, tego jeszcze nie rozgryzłem, więc na razie o wydajności można wnioskować z danych dostępnych na wbudowanym dashboardzie. Model, który tam siedzi, to Ultralytics YOLOv11 w najmniejszym wariancie (n, czyli nano), potrafi wykrywać i zwracać bounding boxy dla 80 różnych klas obiektów, takich jak żyrafy i szczoteczki do zębów, co średnio pasuje do większości zadań produkcyjnych, więc model trzeba trenować na własnym datasecie. Za to wydajność jest całkiem niezła, demko podaje następujące dane:

  • Preprocessing: 0 ms. I to jest super sprawa, widocznie kamera potrafi od razu zwracać wynik w formacie, który model może przyjąć. W demku, o którym wspominałem, nie udało mi się tego uzyskać i musiałem się nieźle nagimnastykować, żeby to zoptymalizować.
  • Sama inferencja: ~50 ms. Nieźle, całkiem nieźle. Postprocessing: 20–25 ms. Tu działa algorytm Non-Maximum Suppression, który jest dość zasobożerny, i wygląda na to, że uruchamia się na CPU, sądząc po obciążeniu w top.
  • W sumie daje nam to jakieś 12–13 inferencji na sekundę, co dla wielu zadań jest całkiem znośne. W UI jednak wizualnie wygląda to na 4–5 klatek na sekundę, co może być spowodowane nieoptymalnym potokiem (pipeline) lub innymi narzutami.

Przy tym wszystkim pudełeczko grzeje się konkretnie.

alt text

Co (na razie) zostało za kulisami

Jeśli mówimy o użyciu tego do czegoś poważniejszego niż zabawa wbudowanymi demkami, trzeba ogarnąć, jak:

  • a) Jak złożyć system. Wątpię, żeby Node-RED nadawał się do zadań produkcyjnych, więc trzeba będzie wziąć się za rzeźbienie (Buildroot, tak na marginesie) i wepchnąć potrzebny nam soft.
  • b) Jak optymalizować model i uruchamiać inferencję z własnych programów.

Jeśli starczy na to czasu, wrócę do tego w przyszłych odcinkach. A na razie, do usłyszenia.