Skocz do zawartości

Jaka kamera do atmegi?


Pomocna odpowiedź

Napisano

Witam

Chciałbym zbudować robota typu LineFollower podczas pierwszego przejazdu korzystający z kamery w celu odczytu trasy i zapisania jej przebiegu, a podczas drugiego korzystałby z zapisanych danych w celu optymalizacji trasy jazdy.

Niestety w żadnym sklepie z częściami nie znalazłem kamery współpracującej z ATMegą albo innym mikroprocesorem.

Również wyszukiwanie na forum i w google nic nie dało.

Czytałem ten temat , ale wymaga on użycia komputera klasy PC, a wzrost wagi o te co najmniej 0,5kg spowodowałby zbytnie spowolnienie pojazdu.

Jeżeli ktokolwiek z was ma jakież doświadczenie z rejestrowaniem i przetwarzaniem obrazu z użyciem mikroprocesora, proszę o pomoc.

Powiem krótko nie da się.Nie zrozum mię źle ale potrzebował byś atmegi z funkcję hostu USB + program rozpoznający linie.Poza tym kamera musi mieć dużo fps żeby robot się nie zgubił.Jedyne co ci pozostaje to wykorzystać do tego celu jakiegoś ARMa np.wykorzystać do tego celu raspbery PI.sam ten zestaw posiada kamerę i wyjścia I/0 więc wystarczyło by tylko wpiąć mostki i gotowe.

koval_blazej, koledze zuba1 chodziło chyba o obsługę kamery - a ta jest uzależniona tylko i wyłącznie od zainstalowanego linuksa na PI. Problem jest inny: 30fps*3B*640*480 = 27.6MB/s (przy 800*600 ~2x tyle), czyli 9s i kończy się pamięć RAM. Inna opcja to bardzo wolny przejazd i analizowanie trasy na bieżąco i potem jazda wg tego, ale LF ma poślizg, więc te dane będą często nieaktualne - jedyny plus jest taki, że będzie można poznać kształt trasy i do tego dorobić algorytm dla enkoderów, ale to jest dość "masakryczna" robota. Zdecydowanie nie w dziale " Robotyka - Początkujący"

OldSkull

9s i kończy się pamięć RAM.

Ale jak pokazuje wolfram alpha na karcie SDHC (Raspberry takie obsługuje?) 16GB - 2GB na system zmieści się aż 8,5 minuty.

Poza tym do rozpoznania linii wystarczy obraz czarno-biały (nawet nie odcienie szarości), nie wiem czy uwzględniłeś to w obliczeniach.

zuba1, niestety nie masz racji. Raz, że Pi to sam 'komputer'. Dwa, kto mówił, że kamera potrzebuje połączenia przez USB?

Tak jak mówi koval_blazej, Freescale'owa kamerka jest bardzo spoko. Jest to w zasadzie pojedynczy rząd pikseli (128), obsługiwany w sposób dość banalny, poprzez taktowanie jednego pinu i odczyty ADC na drugim. Fakt, że trzeba mieć szybkie ADC do tego, ale sprawdza się bardzo dobrze.

Jest to w zasadzie pojedynczy rząd pikseli (128),

Czyli ma rozdzielczość 128x1?

jeśli tak, to czy brak pokrywających się pikseli w kolejnych klatkach nie uniemożliwi łączenia ich oraz wykrywania przesunięcia?

Myślałem o użyciu hugino-podobnego algorytmu aby połączyć wszystkie nagrane klatki w jeden obraz, następnie wyznaczeniem z niego przebiegu trasy, a ostatecznie obliczeniu najkrótszej linii po której może poruszać się robot, dla której trasa cały czas jest wewnątrz jego obrysu.

W jakim celu chcesz użyć w takim razie kamerę? Mógłbyś patrzeć do przodu i wprowadzać korektę do jazdy, ale jeśli chcesz kamerą tylko zmapować trasę to jest to niepotrzebne. Przecież identycznie możesz ją sobie zmapować zwykłymi czujnikami. Jaką widzisz zaletę przy takiej kamerze? Pomijam już fakt koszmarnej ilości danych jaką należałoby obrobić.

Może czegoś nie rozumiem, ale wychodzi mi ok. 0.1Mb/s przy obrazie 100*100px czarno-białym 10fps.

Przy czasie przejazdu na poziomie max. 50s daje to 5Mb = 0,626 MB.

Nie wydaje mi się to bardzo dużą ilością...

Ja bym policzył tak:

Np. co 1mm trasy odczytujemy czarno-biały "pasek" o szerokości 128 pikseli. Do tego dodajemy log z manewrów robota bo trzeba wiedzieć jakie były parametry ruchu w czasie skanu. Na 12 metrowej trasie mamy 12000 odczytów czyli 1.5Mbita plus pewnie z 50kbajtów na dane z enkoderów. Wychodzi dobrze ponad 200kbajtów. Dużo? Zależy dla kogo. Dla małej ATmegi to dużo. I nie chodzi o to, że RAM mały, można podłączyć dowolnie duży ale to są dopiero czyste dane wejściowe. Teraz trzeba to obrobić, wykryć trasę, połączyć skany w jeden ciąg, skorelować z zapamiętanymi manewrami robota, przesunąć całość do jakiejś bezwzględnej płaszczyzny odniesienia, wyznaczyć optymalną trasę i przełożyć to na plan przejazdu wyrażony komendami silników. Potem zostaje już tylko realizacja planu w czasie rzeczywistym z nadążnymi poprawkami od poślizgów i uchybów aktualnego położenia (pobieranymi z kamerki?). Zadanie fajne, ciekawe kto pierwszy takiego LFa zrobi 🙂 I chyba wcale nie ilość danych jest tu krytyczna..

Czyli chyba prościej wyjdzie dużo czujników odbiciowych + sensor z myszy do przesunięcia.

Chociaż kamera dałaby większą rozdzielczość odwzorowania toru, ale nie wiem, czy jest ona tu potrzebna...

Sensor z myszki może być bardzo dobrym rozwiązaniem.

Nie wiem ile kosztują takie kamerki jak pokazana przeze mnie (tak, to jest 1x128px), ale chyba warto zainwestować do takiego projektu - 128 czujników linii raczej nie zainstalujesz 😉. Jest jeszcze jedna możliwość jej zastosowania, nad którą dyskutowaliśmy z kolegami - można mieć jednocześnie kamerę i tradycyjne czujniki - czujniki widzą to, co jest tuż przed robotem, a kamera patrzy w przód i umożliwia reagowanie z wyprzedzeniem.

W każdym razie pomysł z zapamiętaniem trasy raczej nie nowy, jakoś nadal nikt tego nie zrealizował, ale warto spróbować, wyniki mogą być bardzo ciekawe!

Co ważne, do 'speed run'a' enkodery z pewnością już nie wystarczą i będzie potrzebny jakiś optyczny czujnik przemieszczenia, IMU czy jeszcze inna szarlatańska sztuczka.

znalazłem cos ciekawego w kryteri LF koles wykorzystuje kamere 124x1 + IR do wykrywania lini Link . a swoja droga Baton to taka kamerka idealna by była do skanera laserowego takiego jak w XV-11

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
×
×
  • Utwórz nowe...