Autonomiczny robot z układem wizyjnym

[Elvis]

Wszyscy przyzwyczaili się do światłolubów, ale jak zrobić robota który rozróżnia kolory, a może nawet kształty. Ostatnio na forum pojawił się bardzo aktywny wątek o bibliotece OpenCV. Pozwala ona na przetwarzanie obrazów, pozostaje jednak pytanie, jak zbudować robota sterowanego obrazem.

Pierwsza myśl to kamerka WiFi. Jest to rozwiązanie proste, ale nie autonomiczne. Obraz przesyłany jest do komputera PC, sam robot nie jest w stanie odczytać obrazu. Można oczywiście wmontować PC do robota. Istnieje też nieco inna możliwość - wykorzystanie modułu z linux-em na pokładzie. MMnet1001 wydaje się wręcz idealny. Postaram się więc opisać jak z modułu MMnet1001 oraz kamerki internetowej zbudować robota. Na początek podłączamy moduł MMnet1001 i kamerkę Logitech do płytki ewaluacyjnej (EVBmm).

Fizyczne podłączenie jest łatwe - na płytce jest gniazdo USB, wystarczy podłączyć kamerkę. Wśród dostarczonych z modułem pakietów znajduje się uvc_streamer - program pozwalający na umieszczenie obrazu z kamery w internecie. Co ciekawe program nazywa się MJPG-streamer, projekt dostępny jest tutaj: http://sourceforge.net/projects/mjpg-streamer/develop Na początek sprawdzimy, czy kamera działa. Szukamy urządzenia /dev/video i okazuje się, że system kamerki nie widzi.

Konieczne jest ręczne wczytanie odpowiednich modułów (w odpowiedniej kolejności). Wykonujemy następujące komendy:

insmod v4l1-compat
insmod videodev
insmod gspca_main
insmod gspca_zc3xx

Jeśli okaże się, że opisywanych modułów nie ma w naszym systemie, konieczna jest rekompilacja jądra. Po przeczytaniu dokumentacji modułu, nie powinno to stanowić problemu. Zajmuje ok. godzinki i lepiej nie używać wersji IDE z maszyny wirtualnej. Gdy moduły zostaną załadowane, po podłączeniu kamerki pojawi się urządzenie /dev/video0.

Teraz możemy uruchomić uvc_streamer:

Aby zobaczyć obraz z kamery, łączymy się za pomocą przeglądarki z portem 8080 naszego modułu:

Jak widać obraz jest całkiem niezłej jakości, mamy już to co oferuje nam kamerka po WiFi - podgląd obrazu. Czas na odczytanie obrazu z kamerki. Pod Linux-em do komunikacji z kamerką wykorzystamy moduł Video4Linux. W internecie znajdziemy sporo informacji, dokumentacji i przykładowych programów. Warto na początek uruchomić program na PC, a dopiero później próbować sił na robocie.

Ja wykorzystałem źródła programu MJPG-streamer. Dostępny jest on na licencji GNU, więc i mój program obejmuje ta licencja. Wykorzystując gotowe moduły odczyt danych z kamery jest bardzo łatwy. Właściwie 2 linijki kodu wystarczą do odczytu obrazu z kamery. Inicjalizacja kamery i ustawienie parametrów:

video_dev = init_videoIn(&videoIn, device, 320, 240, 1, V4L2_PIX_FMT_MJPEG, 1);

Oraz sam odczyt obrazu:

uvcGrab(&videoIn)

Obraz pobieramy w formacie JPEG, możemy zapisać go do pliku, aby sprawdzić, czy wszystko działa. Poniżej obrazek pobrany z kamerki:

W programie możemy wybrać rozdzielczość oraz liczbę klatek na sekundę. Oczywiście w granicach tego, co oferuje sprzęt. Dalej pojawiają się niestety problemy. Moja kamerka za nic nie chce przyjąć innej konfiguracji niż wysyłanie obrazów w formacie JPEG. Pozornie nie ma z tym problemu, jednak odkodowywanie obrazów będzie zajmowało dużo czasu. Widać już, że zwykła kamerka internetowa nie najlepiej się do budowy robota nadaje.

Należałoby poszukać kamery, która jest w stanie przesłać nieskompresowany obraz. Z braku lepszej kamery pozostaje odkodowanie obrazu zapisanego w pliku JPEG. Żeby nie pisać samemu dekodera jpeg-ów, pobieramy gotową bibliotekę. Ja poprałem ją stąd: http://heanet.dl.sourceforge.net/project/libjpeg/libjpeg/6b/jpegsr6.zip

Plik trzeba rozpakować, można najpierw skompilować na PC i zobaczyć jak działa, następnie przygotowujemy wersję dla ARM. Wykonujemy polecenia:

./configure CC='arm-linux-uclibc-gcc'
make

 

i mamy gotową wersję na nasz mikrokontroler. Żeby jeszcze bardziej ułatwić sobie życie, wykorzystamy gotowy program o nazwie 'djpeg'. Pozwala on na zmianę formatu pliku z jpeg, na łatwiejszy od dalszej obróbki. Do wyboru są różne formaty plików, np. bmp, gif. Najłatwiej będzie odczytać domyślny format, czyli pnm. Jeśli chcemy poznać szczegóły tego formatu plików, jego opis znajdziemy tutaj: http://netpbm.sourceforge.net/doc/pnm.html

Jest to bardzo prosty format, na początku 3 linijki nagłówka, później dane obrazu zapisane jako RGB:

Potrafimy już pobrać obraz z kamery, przekodować go do prostego formatu. Teraz czas na analizę obrazu. Najlepszym rozwiązaniem byłoby wykorzystanie biblioteki OpenCV. Na początek (albo raczej z braku czasu) przygotujemy program, który będzie jedynie oceniał jasność obrazu. Celem będzie przygotowanie światłoluba. Dzielimy więc obraz na 3 części i liczymy jasność każdej z nich. Na początek przygotowujemy zdjęcia testowe. Odpowiednio dla jazdy w lewo, prosto i w prawo.

Następnie przygotowujemy prosty program. Na podstawie zdjęcia będzie on wydawał polecenie odpowiedzialne za kierunek jazdy. Możliwe polecenia to:

• LEFT
• CENTER
• RIGHT

Testujemy program na mikrokontrolerze i przykładowych obrazkach:

Po przetestowaniu programu na przykładowych zdjęciach czas uruchomić wszystkie programy na mikrokontrolerze. Za pomocą skryptu cyklicznie będziemy uruchamiać:

1. program od odczytu obrazu z kamery
2. dekoder JPEG do PNM
3. program decydujący o kierunku jazdy

Niestety czas działania jest bardzo słaby. Poleceniem time możemy sprawdzić, który program zajmuje nam tak dużo czasu.

v4l - program do odczytu danych z kamery. Wykonanie go to aż 2.64s.

djpeg - dekoder jpeg do pnm. Działa nawet szybko, 310ms

pictest - program decydujący o kierunku jazdy. 290ms.

Wniosek jest prosty: nie można uruchamiać programów kolejno, trzeba przygotować jeden, który będzie na bierząco pobierał dane z kamerki i poddawał obróbce. Drugi wniosek jest mniej przyjemny - nawet gdyby pobieranie obrazu trwało zero sekund, to i tak pozostaje 600ms na klatkę. To baaardzo mało. Na pewno używając kamerki z JPEG nie uzyskamy pełnego realtime-u. Ale może dla światłoluba wystarczy.

Optymalizacja

Uruchamianie programów przez skrypt dało bardzo kiepskie rezultaty. Najwięcej zajmuje inicjalizacja kamery (ponad 2 sekundy). Aby przyspieszyć działanie konieczne jest połączenie programów do odczytu danych, dekodowania oraz podejmowania decyzji w jeden. Poniżej widać rezultat działania poprawionego programu:

Tym razem odczyt z kamery prawie nie zajmuje czasu (<= 1ms), najwięcej zajmuje dekodowanie JPEG-ów. Co prawda kod nie jest optymalny - za każdym razem tworzony jest nowy proces i uruchamiany program djpeg, jednak nawet po zmianie kodu ten fragment zabierałby cenny czas. Całe przetwarzanie zajmuje ok. 280 ms. Kolejnym krokiem będzie wykorzystanie kamery do sterowania robotem.

Robot sterowany jest przez dwa procesory. Na płytce ewaluacyjnej znajduje się opisywany wcześniej ARM9 z Linux-em na pokładzie. Procesor dokonuje analizy obrazu z kamerki (bardzo prostym algorytmem) i przekazuje dane o kierunku jazdy do drugiego procesora. ATMega16 odpowiedzialna jest za sterowanie silnikami. Do wymiany informacji między procesorami wykorzystałem UART (buforowany, aby zapewnić konwersję napięć z 5V na 3.3V).

Wnioski

Wykorzystana kamerka zupełnie nie spełniła oczekiwań. Dekodowanie JPEG-ów zajmuje bardzo dużo czasu, znacznie więcej niż algorytm analizy obrazu. W rezultacie robot reaguje dość wolno na zmianę kierunku oświetlania, zwykły światłolub bez mikrokontrolera działa o wiele sprawniej. Kolejnym problemem okazał się algorytm analizy obrazu. Wybrany jako prosty przykład, działał dla obrazów testowych, jednak w prawdziwym robocie zupełnie się nie sprawdził. Tylko dla dobrze ustawionego źródła światła potrafił za nim podążać.

Robot bazuje na dwóch płytkach ewaluacyjnych. Budując "prawdziwego" robota należałoby oczywiście wykorzystać mniejszą płytkę specjalnie zaprojektowaną. Testowy robot praktycznie nie korzystał z możliwości podrzędnego mikrokontrolera. AVR jedynie wykonywał polecenia układu ARM9. Do zadań krytycznych czasowo należałoby wykorzystać możliwości mniejszego układu. Robot powinien posiadać dodatkowe czujniki, np. odległości lub linii i za ich pomocą dokonywać natychmiastowej oceny otoczenia. Analiza obrazu może służyć jedynie jako pewna "podpowiedź" gdzie robot powinien się kierować, albo jakim algorytmem posługiwać.

Przykładowo robot typu LF mógłby na podstawie analizy obrazu dobierać prędkość jazdy, jednak samo wykrywanie linii musiałoby odbywać się tradycyjnymi metodami. Wykorzystanie gotowego systemu operacyjnego znacznie ułatwia obsługę urządzeń opartych na łączu USB. Podłączenie kamerki nie było oczywiste, jednak znając metodę zajmuje 15 minut. Otwarty kod (Open Source )pozwala na łatwe opracowywanie własnych programów.

Programując można najpierw przetestować działanie na komputerze PC z zainstalowanym Linux-em, a gdy program zacznie działać wystarczy przekompilować na ARM9. Niestety budowa robota rozpoznającego obraz nie jest łatwa. Wymaga dobrej znajomości linux-a, komunikacji oraz przygotowania algorytmów rozpoznawania obrazu. Opisywana platforma to jedynie wstęp do budowy prawdziwego robota. Jest to bardzo ciekawy temat, ale ze względu na poziom trudności polecam jako pracę magisterską, jeśli nie temat doktoratu.

Zmiana kamerki

Po pierwszych testach okazało się, że kamerka Logitech C200 zupełnie nie spełniła oczekiwań. Dekodowanie JPEG do mapy bitowej zajmowało o wiele za dużo czasu. Kupiłem inną kamerkę. Tym razem wybrałem kamerkę firmy Modecom - model chyba "Yoyo Web Cam". Na pudełku była informacja, że kamera obsługuje format pikseli RGB24. Parametry jej są przeciętne, ale nie o to chodziło. Więcej informacji na stronie: http://www.modecom.pl/product.php?category=18&id=685&lang=pl&arch=0

Kamerka obsługuje standard UVC, więc podłączenie do linuxa było bardzo proste. Na stacjonarnym komputerze obraz w 640x480 pikseli jest dość dobrej jakości. Kolejnym krokiem było napisanie programu, który pobierze dane z kamery. Tutaj pojawiła się pierwsza niespodzianka. Kamerka wcale nie pracuje w trybie RGB24! Zamiast tego używa YUYV. Nie jest to idealne kodowanie, ale zawsze lepiej niż JPEG.

Po szybkim przeczytaniu kilku artykułów o kodowaniach YUV, przygotowałem program v4lyuv - kod w załączniku. Linki do stron z których korzystałem:

• http://www.fourcc.org/fccyvrgb.php
• http://en.wikipedia.org/wiki/YUV

Program pobiera 5 obrazów w rozdzielczości 320x240 i dekoduje je trzema sposobami. Pierwsze dekodowanie zamienia obraz na RGB, działa na liczbach zmiennopozycyjnych. Drugi sposób dekodowania działa na liczbach całkowitych. Trzecie kodowanie wykorzystuje tylko składową Y, czyli jasność koloru. Poniżej czasy przetwarzania na komputerze PC:

Kolejnym krokiem było przekompilowanie kodu na ARM. Co ciekawe musiałem zmienić sposób kodowania pikseli. Ustawienie YUYV działa na PC, ale na ARM zgłasza błąd. Po zmianie na MJPEG działa pięknie i co najciekawsze nadal zwraca obraz w formacie YUYV. W załączniku kod programu dla ARM - v4lyuvarm.

Poniżej czas działania:

Czas przetwarzania, szczególnie trzecim algorytmem jest o wiele krótszy niż z poprzednią kamerką. Wynosi ok. 90ms i można go jeszcze skrócić analizując tylko fragment obrazu. Kod nie jest zoptymalizowany, można byłoby pewnie sporo przyspieszyć działania. W ostatecznej wersji przydałoby się zakodować to w asemblerze. Poniżej przykładowe obrazki:

Wynik działania trzeciego algorytmu - tylko składowa jasności:

Nieoczekiwany koniec artykułu

Planowałem zastosowanie nowej kamery do sterowania robotem testowanym poprzednio. Szybsze przetwarzanie obrazu oraz gotowa informacja o jasności dawała nadzieję na lepsze rezultaty. Niestety nastąpił mały wypadek. Akumulator Li-Pol z nieznanych mi zupełnie przyczyn uległ samozapłonowi. Na szczęście płyta z linux-em na pokładzie przetrwała, ale płytka z atmegą oraz cały napęd robota uległ zniszczeniu. Poniżej zdjęcia ku przestrodze.

OSTROŻNIE A AKUMULATORAMI LITOWYMI

CamRobot.zip

v4larm2.zip

v4lyuvarm.zip

v4lyuv.zip

[Treker (Damian Szymański)]

Artykuł został ukończony, więc podbijam, aby inni widzieli dodaną część.

Elvis, dobra robota 😉

Może teraz, więcej początkujących zrozumie na co się porywa.

[olimek]

Wielkie brawa za chęci i za samo wykonanie 😉

[wsowa]

probowales z innymi formatami wideo niz mjpg?

[Polecacz 101]

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

[Chechli]

Fajna konstrukcja, jakby udało sie zrobić algorytm poprawnie wykrywający plamę światła, co jest jednak trudniejsze imo niż wykrycie linii. W ogóle to jak to obecnie sprawdzasz, liczysz jasność kawałka jako sumę wartości pikseli w RGB? Czy wykrywasz plamę analizując krawędzie?

[Elvis]

Próbowałem zmusić kamerkę do generowania strumienia we wszystkich możliwych formatach - RGB, YUV, GRAY itd. Niestety zawsze wysyłany jest JPEG. Wydaje mi się, że to efekt wykorzystania pierwszej lepszej (najtańszej) kamerki jaką mieli w sklepie. Na przyszłość trzeba wybrać kamerkę, która:

1) obsługuje nieskompresowane dane

2) są do niej moduły v4l

Co do wykrywania to liczę jasność 3 obszarów - po lewej, środek i po prawej. Następnie robot stara się skierować w tę stronę, gdzie jest najjaśniej.

W teorii i na testowych obrazach wszystko działało pięknie, natomiast sam robot zachowywał się bardzo kiepsko.

Zamiast jechać do światła wolał np. telewizor w sąsiednim pokoju.

Lepiej byłoby wykrywać coś bardziej charakterystycznego - np. plamkę lasera. Niestety nie mam takiego, ale pewnie dałoby dużo lepsze efekty. Najpierw filtr na kolor czerwony, później wyszukiwanie.

Ogólnie temat jest dość trudny, najlepiej byłoby przekompilować OpenCV na ARM i zacząć zabawę z algorytmem.

[Chechli]

Czyli rozumiem, że robot ma w polu widzenia nie tylko podłogę. W takim wypadku liczenie jasności raczej musi być zawodne, bo tło może być jaśniejsze w różnych miejscach, nawet bez dodatkowego oświetlenia. A może gdyby napisać algorytm, który wykrywa równy wzrost jasności w R, G i B, i obszar ograniczony w ten sposób traktuje jako plamę światła? Zapobiegło by to wykryciu jako obszaru jaśniejszego obiektu RGB(255, 255, 0) od RGB(0, 0, 255), mimo iż te obszary nie są od siebie jaśniejsze, tylko w innych kolorach.

[Elvis]

Na razie największym problemem jest dekodowanie jpeg-ów. Powoduje bardzo duże opóźnienia.

Dzisiaj kupiłem inną kamerkę. Na pudełku ma napisane, że obsługuje RGB24. Co ciekawe wcale nie obsługuje...

Zamiast tego przesyła YUYV. Rozpoznawanie jasności powinno być więc łatwiejsze niż w RGB.

A co najważniejsze obraz nie jest skompresowany.

Tylko te ilości danych do przetworzenia... Bufor obrazu dla 640x480 to 600kB. Obraz pobieram w 320x240, ale to nadal 150kB na ramkę.

[wsowa]

Elvis, Jaka to kamerka? Mógłbyś wrzucić przykładowy filmik nagrany tą kamerką. Dokładniej chodzi mi o to jak wyjdą poruszające się obiekty z różną prędością w różnym świetke. Machanie ręką przed kamerą z różną prędkością w różnym świetle wystarczy.

Pytam, bo za miesiąc z hakiem zaczynam budowę robota z dwiema kamerami jako jednymi sensorami (PC na pokładzie bo obliczeń bedzie sporo), a nadal nie mam wybranej kamery. Rozważałem Logitech C200.

[Elvis]

Logitech-a nie polecam. Mam chyba właśnie C200 - na obudowie nie ma symbolu, ale kupowałem najtańszą.

Główna wada to przesyłanie tylko i wyłącznie w formacie JPEG. Dekodowanie tego zajmuje wieki.

Zaraz dopiszę do artykułu rezultat testu innej kamerki - jest dużo lepiej.

[Treker (Damian Szymański)]

Kolejna aktualizacja w pierwszym poście.

[Radbles]

szkoda tych silniczków i płytki:(

[Bobby]

Hmm, przejrzałem sobie na wiki opis tego YUV, jeśli dobrze rozumiem, to chcąc mieć obraz czarno-biały (światłolub/linefollower) wystarczy tylko sobie wyciągnąć Y? I jesteśmy wtedy pozbawieni obliczania jasności na podstawie RGB. Ale rozumiem, że art miał być jak najbardziej uniwersalny, dlatego postanowiłeś przekonwertować to na bitmapę. No a platformy rzeczywiście szkoda, bo takie jeździdełko zawsze się przydaje, serwa nie są całe? bo wyglądają na zdjęciach jak by tylko plastik przytopiło.

[Chechli]

Wydaje mi się, że wyciągnięcie samego Y nie wystarczy. Niektóre przedmioty są przecież bez oświetlenia jaśniejsze niż inne, a robot ma podążać za światłem, a nie jasnymi przedmiotami. Trzeba jeszcze jakoś z innych składowych wyciągnąć informacje, czy to jasna plama na podłodze, czy inny obiekt.

[wsowa]

No szkoda platformy. Dobrze, że większego pożaru nie było. Tak to jest z LiPo - lekkie, wydajne ale niebezpieczne.

Moim zdaniem z YUV można zrobić więcej niż z RGB, więc nawet lepiej ze kamerka daje YUV a nie RGB.