Edge AI w mobilności: liczenie pieszych i rowerzystów

W tym miesiącu kończymy naszą część współfinansowanego ze środków publicznych projektu badawczego o kamerach AI, które zbierają dane o mobilności aktywnej: ile osób przechodzi i przejeżdża rowerem obok danego punktu i w którym kierunku. Projekt prowadził nasz partner, start-up budujący sprzęt IoT dla infrastruktury drogowej. My odpowiadaliśmy za część embedded AI: nagrywanie i streaming w systemach kamer, wybór i wdrożenie modeli detekcji oraz ich testy w terenie.

Nie był to nasz pierwszy kontakt z kamerami AI: pierwszy demonstrator kamery AI dla infrastruktury drogowej zbudowaliśmy już w 2021 roku, a przez cały 2023 rok sprawdzaliśmy, czy kamera stereo z własnym procesorem wizyjnym może stać się podstawą pilotażu liczenia. Poniżej wnioski, które z tego wynieśliśmy.

Dlaczego liczyć na kamerze

Celem nigdy nie było wideo. Planista ruchu potrzebuje liczby obiektów według klasy, kierunku i kwadransa. Jeśli kamera sama je policzy, żaden obraz ludzi nie musi opuszczać urządzenia. Dobry projekt trzyma obrazy na urządzeniu, ściśle ogranicza zdalny dostęp i wysyła tylko anonimowe statystyki. To bardzo upraszcza rozmowę o RODO, a jest jeszcze ważniejsze teraz, gdy Parlament Europejski w tym miesiącu przyjął AI Act, ze szczególną uwagą dla systemów identyfikujących ludzi. Policzenie, że przejechał rowerzysta, to coś zupełnie innego niż rozpoznanie, kto to był.

Urządzenia przy drodze mają też mało energii i często słaby zasięg sieci komórkowej, więc wysyłanie kilku liczb zamiast strumienia wideo to nie tylko kwestia prywatności.

To kamera decyduje, jakich modeli możesz użyć

Wnioskowanie na urządzeniu oznacza, że model działa na procesorze wizyjnym kamery, więc najpierw trzeba go przekonwertować do formatu, który ten procesor rozumie. W praktyce zawęziło to wybór dużo bardziej, niż sugerowałaby jakakolwiek tabela benchmarków:

• Lekkie detektory typu SSD działały płynnie na urządzeniu i obejmowały zarówno ludzi, jak i pojazdy.
• Kompaktowe warianty YOLO rozpoznawały więcej klas, ale przy wyraźnie niższej liczbie klatek na sekundę.
• Modele wyspecjalizowane, na przykład tylko do pojazdów, mogą być świetne dla jednej klasy i mało przydatne, gdy zmienią się wymagania.
• Najnowsze architektury nie zawsze są dostępne w formacie obsługiwanym przez procesor wizyjny; ich konwersja może wymagać więcej pracy niż cała reszta potoku.

Było też drugie, mniej oczywiste ograniczenie. Detekcja działa wewnątrz kamery, a urządzenie nie jest zaprojektowane do przyjmowania nagranego wideo jako wejścia – a tak zwykle porównuje się modele na komputerze. Zbudowaliśmy więc funkcje nagrywania i streamingu dla kamer oraz sposób uruchamiania każdego modelu na tym samym nagraniu, żeby wszystkie modele dało się porównać na identycznym wideo referencyjnym.

Testy w terenie: każdy wynik porównany z liczeniem ręcznym

Wyniki z laboratorium niewiele mówią o ulicy. Testowaliśmy więc w terenie, na chodniku wspólnym dla pieszych i rowerzystów, nagrywaliśmy każdą sesję i porównywaliśmy wyniki kamery z ręcznym liczeniem na tym samym nagraniu.

• Przy małym ruchu lekki detektor w połączeniu z informacją o głębi i prostym filtrem ruchu zbliżał się do ręcznego wyniku referencyjnego.
• W godzinach szczytu, gdy grupy przechodziły jednocześnie, każdy model miał problemy: ludzie byli łączeni lub pomijani, a rowery liczone za dużo razy.
• Cięższe modele nie były automatycznie lepsze, gdy musiały działać na urządzeniu.

Wnioski w większości nie dotyczyły modelu:

• Progi to kompromis, a nie rozwiązanie. Obniżenie progu detekcji sprawiało, że model widział więcej, ale liczba fałszywych detekcji rosła drastycznie. Filtrowanie po ruchu i głębi pomagało bardziej niż strojenie progu.
• Montaż znaczy tyle samo co model. Najlepsze wyniki były tam, gdzie ścieżki się nie krzyżowały, a ludzie nie zatrzymywali się na skraju pola widzenia. Wysokość montażu też zmienia wyniki, zwłaszcza w tłumie.
• Zasilanie wpływa na wszystko. Wymóg niskiego poboru mocy zawęża wybór sprzętu i podnosi koszt każdego dnia testów na miejscu, więc trzeba go planować od początku.

Co powiedzielibyśmy każdemu, kto planuje liczenie kamerami

• Określ klasy, kierunki i akceptowalny błąd, zanim wybierzesz sprzęt. Dzienna statystyka i wyzwalacz bezpieczeństwa potrzebują zupełnie innej dokładności.
• Wybieraj sprzęt brzegowy ze świadomością, że ogranicza on modele, które da się uruchomić, i sprawdź ścieżkę konwersji dla wybranych modeli przed zakupem.
• Od pierwszego dnia planuj dane referencyjne: nagranie wideo i ręczne liczenie dla każdego testu, zarówno przy małym, jak i dużym ruchu.
• Testuj w tłumie i w docelowym miejscu montażu. Na spokojnym chodniku każdy model wygląda dobrze.
• Trzymaj obrazy na urządzeniu i wysyłaj tylko te liczby, których potrzebuje dane zastosowanie.

Następne pytanie dotyczy zwykle trenowania. Modele wytrenowane na publicznych zbiorach danych zaprowadzą Cię daleko; żeby nadrobić braki w zatłoczonych scenach, potrzeba danych z rzeczywistych miejsc montażu, a obrazy syntetyczne to jeden ze sposobów na obniżenie kosztu ich etykietowania.

Detekcja obiektów na brzegu sieci to nie pomniejszona wersja AI w chmurze. To inny projekt, w którym sprzęt, montaż i zasilanie znaczą tyle samo co model, a prywatność można wbudować od początku, zamiast dokładać ją później. Jeśli pracujesz nad urządzeniem albo projektem smart city, który ma widzieć i liczyć, zajrzyj do naszych usług IoT albo napisz do nas.