YOLO przy wózku widłowym: dlaczego nowszy model nie zawsze jest lepszy

Od września pracuję nad urządzeniem, które ma ostrzegać operatorów wózków widłowych i innych maszyn roboczych o obiektach w martwej strefie. Cztery kamery, LiDAR, radar i niewielki komputer z akceleratorem AI.

Od początku przyjęliśmy ważne ograniczenie: budujemy system wspomagania operatora zgodny z założeniami ISO 16001, a nie certyfikowane urządzenie ochronne. System ostrzega, ale nie hamuje maszyny ani nie ogranicza jej prędkości.

Zanim zacząłem testować modele, spodziewałem się, że największym wyzwaniem będzie skuteczność rozpoznawania ludzi. Okazało się, że równie istotne są geometria obrazu, fałszywe alarmy i ograniczenia sprzętu.

Najpierw fizyka, potem AI

Zacząłem od policzenia, z jakiej odległości kamera może w ogóle dostarczyć obraz człowieka wystarczająco duży dla modelu.

Tu pojawił się pierwszy ważny wniosek: liczba megapikseli kamery nie decyduje bezpośrednio o zasięgu detekcji.

YOLO przed analizą zmniejsza obraz do ustalonej rozdzielczości (imgsz). Jeśli sylwetka człowieka zajmuje w tym obrazie kilkanaście pikseli, nawet najlepszy model niewiele zdziała. Zwiększanie rozdzielczości matrycy niczego nie zmieni, jeśli obraz nadal jest skalowany do tego samego rozmiaru.

Duże znaczenie ma też kąt widzenia. Szerokokątna kamera obejmuje większy obszar, ale człowiek znajdujący się daleko zajmuje mniej pikseli. Trzeba więc wybierać między pokryciem przestrzeni a zasięgiem rozpoznawania.

Z obliczeń wyszło, że przy szerokokątnej optyce i uwzględnieniu pogorszenia warunków obrazowania użyteczny zasięg może być znacznie mniejszy od geometrycznego maksimum. To na razie szacunek, nie wynik pomiaru w terenie.

Jest też problem bliskiej odległości. Człowiek stojący tuż przy maszynie może nie mieścić się w kadrze. Dlatego samą kamerą nie da się obsłużyć całego otoczenia.

Uzupełnieniem jest LiDAR, który dostarcza informacji o odległości. Zrezygnowaliśmy też z radaru 24 GHz na rzecz 77 GHz, ponieważ potrzebujemy wykrywania również nieruchomych obiektów. Stojący człowiek nie może znikać tylko dlatego, że się nie porusza.

Nowszy YOLO przegrał ze starszym

Zestaw testowy zbudowałem na Raspberry Pi 5 z akceleratorem Hailo-8. Modele pochodziły z gotowego zbioru producenta i były trenowane na COCO.

Porównałem kilka wariantów segmentacji YOLO. Kryteria ustaliłem wcześniej: model musi obsłużyć wszystkie kamery z odpowiednią szybkością, wykrywać możliwie dużo osób, a dopiero potem liczy się wynik na standardowym benchmarku.

Spodziewałem się, że nowszy YOLO11s-seg będzie przynajmniej porównywalny ze starszym YOLOv8s-seg.

Nie był.

Na niewielkim zestawie zdjęć nowszy model pomijał więcej osób, szczególnie małe sylwetki i ludzi przy krawędziach kadru. Był też wolniejszy na używanym akceleratorze.

Wybrałem YOLOv8s-seg, mimo że YOLO11s-seg ma lepszy publikowany wynik mAP.

Nie oznacza to, że starszy model jest ogólnie lepszy. Test był mały, a punkt odniesienia stanowiły osoby potwierdzone przez co najmniej dwa modele. Wynik wystarczył jednak do wyboru wariantu do dalszych prób.

Po zmianie sposobu przetwarzania klatek i wykorzystaniu inferencji paczkowej osiągnąłem około 98 analiz na sekundę dla czterech kamer. Wcześniejszy wariant, przetwarzający pojedyncze klatki, był znacznie wolniejszy.

Przy okazji poprawiła się częstotliwość aktualizowania odległości z LiDAR-a.

Zdjęcie ślubne jako pieszy

Najciekawsze problemy pojawiły się podczas zwykłych testów w pokoju.

Na regale stało zdjęcie ślubne. Modele konsekwentnie rozpoznawały znajdującą się na nim osobę jako rzeczywistego pieszego. Nie był to przypadkowy błąd jednej klatki. Fałszywa detekcja utrzymywała się praktycznie przez cały pomiar.

Pod światło fotel gamingowy bywał rozpoznawany jako zwierzę. Z kolei kot siedzący w cieniu stanowił duży problem dla mniejszych modeli.

Większy YOLOv8m-seg znacznie lepiej radził sobie z kotem, ale był zbyt wolny, żeby spełnić przyjęte wymagania. W wykrywaniu człowieka pod światło nie dawał natomiast przewagi uzasadniającej zmianę.

Największą poprawę przyniosło coś znacznie prostszego niż wymiana modelu.

Podniosłem próg pewności detekcji z 0,25 do 0,50. W mierzonej serii liczba fałszywych wykryć w tle spadła ze 142 do 7, przy niewielkiej utracie prawdziwych detekcji.

To pokazało, że strojenie progu może mieć większy wpływ na praktyczną użyteczność niż wybór kolejnej generacji sieci.

Sam próg nie rozwiązuje jednak problemu zdjęcia na regale. Do odróżnienia rzeczywistego człowieka od obrazu potrzebna jest dodatkowa informacja geometryczna, na przykład z LiDAR-a.

Do aplikacji dodałem też wygładzanie wyników, histerezę i blokowanie alarmów podczas postoju lub poza kursem jazdy. Osobny mechanizm wybiera najważniejsze zagrożenie, żeby operator nie dostawał kilku ostrzeżeń jednocześnie.

USB potrafi zepsuć cały eksperyment

Podczas integracji okazało się, że modele AI nie są jedynym źródłem problemów.

Początkowo Raspberry Pi uruchamiało tylko dwie z czterech kamer. Problemem nie była rzeczywista ilość przesyłanych danych, lecz rezerwacja pasma przez sterownik UVC. Dopiero zmiana parametru max_payload pozwoliła uruchomić wszystkie kamery.

Później pojawił się trudniejszy problem: przy wyższej rozdzielczości kamer resetowało się całe drzewo USB. Napięcie wyglądało prawidłowo, ale zadziałało ograniczenie prądowe portów. Rozwiązaniem ma być aktywny hub lub odpowiednie zasilanie.

Sprawdziłem również temperatury. Hailo mocno nagrzewał się nawet przy umiarkowanym obciążeniu. Zmniejszenie częstotliwości analiz odciąża procesor, ale niewiele pomaga w chłodzeniu akceleratora. W wysokiej temperaturze otoczenia może to być istotny problem.

Trafiłem też na cichą pułapkę w SDK Hailo. Bez jawnego ustawienia planisty ROUND_ROBIN pierwsze pomiary zwracały same zera. Żadnego wyjątku ani komunikatu błędu. Dopiero poprawienie konfiguracji uruchomiło detekcję.

Co wiem, a czego jeszcze nie

Po tych testach mam wybrany model i działający zestaw deweloperski. Wiem też, że dalsza poprawa systemu nie musi polegać na szukaniu coraz większych sieci neuronowych.

Więcej można zyskać przez odpowiednią optykę, fuzję czujników, właściwy próg detekcji i dopracowanie integracji sprzętowej.

Ale nie mam jeszcze odpowiedzi na najważniejsze pytanie: jak dobrze system będzie działał na rzeczywistym wózku?

Wszystkie dotychczasowe pomiary wykonałem w pokoju, z jedną osobą, jednym kotem i niewielką liczbą scen. Nie przeprowadziłem jeszcze zaplanowanego pomiaru zasięgu w metrach, prób w całkowitej ciemności ani testów na hali i na zewnątrz.

Nie zweryfikowałem też fizycznie słabszej wersji akceleratora. Jej wydajność oszacowałem na podstawie odpowiednio skompilowanego modelu.

Wyniki wskazują sensowny kierunek dalszych prac, ale nie dowodzą jeszcze skuteczności urządzenia w rzeczywistych warunkach. O tym zdecydują dopiero testy przy maszynie.