Teoretyzowanie przed praktyką #2 - lokalizowanie obiektu w pomieszczeniu

[Treker (Damian Szymański)]

Witam wszystkich,
z uporem starałem się przekonać Was do comiesięcznych dyskusji na różne tematy. Dlatego we wrześniu założyłem temat o czujnikach IR. Jak widać, jest on ciągle żywy i niesie za sobą mnóstwo przydatnych informacji. W tym miesiącu chciałbym zaproponować Wam nowy temat - oczywiście stary nadal pozostaje otwarty i aktualny.

Czym zajmiemy się w tym miesiącu? Wystarczy przejrzeć tematy, aby zauważyć, że bardzo często pojawia się temat lokalizowania robota lub obiektu w pomieszczeniu. Przeważnie odpowiedzi ograniczają się do podawania tych samych, niekoniecznie sprawdzonych rozwiązań. Pora coś z tym zrobić!

Cel teoretyzowania: Znalezienie najlepszych rozwiązań pozwalających na zlokalizowanie obiektu/robota w pomieszczeniu. Możemy rozważać sytuację ze znacznikami aktywnymi i pasywnymi. Załóżmy tylko, że topologia pomieszczenia nie ulega zmianie. Nie pojawiają się również nowe przeszkody, jednak nie zawsze dysponujemy gotowym planem otoczenia.

Jak do tej pory w pokrewnych tematach pojawiały się rady: stosowania "latarni" ultradźwiękowych lub IR, stosowania kamer i znaczników lub używania wielu czujników pozwalających na symulację przemieszczenia robota w pomieszczeniu. Pora powiedzieć coś więcej na każdy z tych tematów. Pomóżmy wspólnie osobom, które w przyszłości będą zmagać się z tym problemem.

Kto z Was spotkał się z takim zagadnieniem w praktyce? Jak sobie z nim poradziliście lub jakbyście to zrobili?

Propozycje następnych tematów możecie przysyłać do mnie na PW.

[OldSkull]

Ja się spotkałem z podstawą w takich tematach - z odometrią. Nie pamiętam czy już kiedyś o tym nei pisałem, ale w skrócie: robot ma dokładne czujniki przesunięć na obu kołach (dla napędu różnicowego) i na podstawie ich sygnałów obliczamy co chwila zmianę położenia. Mogę powiedzieć, że można osiągnąć bardzo dokładne wyniki, ale niestety metoda ma parę wad:

- błąd wraz z przebytą drogą, narasta

- dla dokładności obliczenia obrotu bardzo ważna jest szerokość rozstawu kół (czym większa tym lepsza)

- rozdzielczość enkoderów nie może być zbyt mała

- szerokość powierzchni styku kół z podłożem powinna być jak najmniejsza

- poślizgi generują błędy

- pozycję określamy w stosunku do pozycji początkowej lub wybranej pozycji uzyskanej od rozpoczęcia algorytmu

Powyższe wady powodują, że nie jest to metoda idealna, ale gdy stosowana np. z jakąś latarnią (lub dowolną inną metodą) daje spore możliwości. Spotkałem się np. z czymś takim:

- ustalamy naszą pozycję, robimy zdjęcie

- przesuwamy się o kawałek

- ustalamy pozycję, robimy zdjęcie

- mając 2 położenia i 2 zdjęcia tworzymy mapę punktów 3D 😃 Nie jest to łatwe (drgania kamery podczas ruchu, opóźnienia w czasie których robot może wykonać jakiś ruch, itd.) ale pewne efekty idzie osiągnąć. Jeden z kolegów bawił się tym do magisterki, ale nie wiem jakie miał efekty. Zaletą jest tani sprzęt: potrzebujemy robota z enkoderami (był moment, kiedy z używanymi silnikami to był koszt rzędu 200zł), moduł BT (40-90zł), kamerkę internetową bezprzewodową (niestety jakość takich kamer lekko przeraża :/, 90-150zł) oraz komputer PC. Alternatywnie użyć zwykłej kamerki (40-90zł) i laptopa postawić na robocie, ale wtedy robot musi być większy i droższy.

[Treker (Damian Szymański)]

Mogę powiedzieć, że można osiągnąć bardzo dokładne wyniki, ale niestety metoda ma parę wad:

- błąd wraz z przebytą drogą, narasta

- dla dokładności obliczenia obrotu bardzo ważna jest szerokość rozstawu kół (czym większa tym lepsza)

- rozdzielczość enkoderów nie może być zbyt mała

- szerokość powierzchni styku kół z podłożem powinna być jak najmniejsza

- poślizgi generują błędy

- pozycję określamy w stosunku do pozycji początkowej lub wybranej pozycji uzyskanej od rozpoczęcia algorytmu

Jedną z bardziej odpowiednich metod rozwiązania problemu lokalizacji wydaje mi się połączenie metody jaką opisujesz wraz z aktywnymi latarniami. Mogłyby one być punktami orientacyjnymi, które zerowałyby błędy powstałe podczas jazdy robota. Myślisz, że to pozwoliłoby uniknąć problemów o jakich piszesz?

Ważna też jest kwestia o jakiej dokładności lokalizowania nam zależy?

[OldSkull]

Tylko pozostaje jeden problem: jak dokładnie jesteśmy w stanie określić pozycję danej latarni względem robota? Taka metoda pozwoli nam ograniczyć błąd do pewnego poziomu, ale dobrze zrobiona odometria taki błąd wygeneruje tylko w przypadku jakiejś kolizji bądź po dość długim czasie. Przynajmniej ja tak sądzę. Ale to zależy też od powierzchni po jakiej się poruszamy.

Teraz tak pomyślałem o innej opcji, ale nakładałaby spore ograniczenia: gdybyśmy mieli płaski, jednobarwny sufit (albo z odpowiednim wzorem, np. pocięty na kwadraty liniami) widoczny w całości z każdego miejsca na dole to robot mógłby np. świecić w górę wiązką lasera i z kamery odczytywać aktualną pozycję. Ale taka metoda miałaby wiele ograniczeń.

[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

[mactro]

Podoba mi się temat 🙂

A zatem przyjrzyjmy się najpierw odometrii. Tak jak Oldskull napisał podstawową wadą odometrii jest to, że choćbyśmy nie wiem jak się starali, to po pewnym czasie błąd położenia zacznie narastać i nie ma jakiejkolwiek możliwości aby go zredukować. Błędy mogą wynikać z:

- różnej średnicy kół

- nieznajomości dokładnej średnicy/rozstawu kół

- niedoskonałości konstrukcyjnych, luzów, nierównoległości kół itd.

Ogólnie błędy wynikające z konstrukcji robota można całkiem ładnie skompensować wykonując odpowiednią kalibrację, np. metodą UMBmark. Prawdziwym problemem są zakłócenia zewnętrzne - wystarczy, że robot przejedzie np. przez próg, czy kabel i najprawdopodobniej o jakiejkolwiek sensownej lokalizacji możemy zapomnieć.

Aby poradzić sobie z takimi zewnętrznymi zakłóceniami (też nie w 100%) stosuje się scan matching - dopasowywanie skanów. Najczęściej wykorzystywane są skanery laserowe, ale z tego co widzę Oldskull spotkał się z kamerami, a mi się zdaje, że widziałem wykorzystane do tego dalmierze ultradźwiękowe/IR. Jeśli nie mamy możliwości ingerowania w pomieszczenie (np. ustawiając latarnie), to być może warto się przyjrzeć tego typu metodom.

Co do latarni ultradźwiękowych, czy jakichkolwiek innych: tak, jeśli tylko faktycznie uda się je uruchomić, to pozwolą na lokalizację robota niezależnie od tego jak długo będzie on działał. Problemy do przeanalizowania:

- widoczność latarni - co jeśli któraś będzie zasłonięta? Być może należałoby stosować więcej niż 3 (minimum do jednoznacznego określenia położenia)

- identyfikacja sygnału z poszczególnych latarni

- eliminacja echa

- jak określić kierunek z jakiego przyszedł sygnał z latarni (jeśli chcielibyśmy ustalić także orientację robota)

Jeśli chodzi o patrzenie się w sufit, zerknijcie na system Stargazer: http://eng.hagisonic.kr/cnt/prod/prod010102?uid=10&cateID=2&fieldName=&orderBy=

[Nawyk]

Temat-rzeka... Spotkałem się z nim w praktyce na studiach, podrzucę trochę materiałów dla zainteresowanych (załączniki) 🙂

InTech-Design_of_test_tracks_for_odometry_calibration_of_wheeled_mobile_robots.pdf oraz paper60.pdf dotyczą przydatnych zagadnień związanych z odometrią. Materiały są w języku angielskim, ale nieogarnięci mogą spróbować wywnioskować coś z obrazków 🙂

Dorzucam też materiały związane z konkretnymi ćwiczeniami, podczas których mieliśmy z kolegą zaprogramować robota w taki sposób, aby poruszał się po pomieszczeniu w oparciu o mapę. Do nawigacji robot wykorzystywał oczywiście enkodery, oprócz tego posiadał zestaw dalmierzy. Sztuka polegała na tym, że robot jeżdżąc wcześniej po pomieszczeniu (tryb mapowania) zapisywał odczyty z dalmierzy w odniesieniu do przejechanego dystansu, każdy punkt na stworzonej mapie miał w miarę unikalny zestaw danych z tych dalmierzy, odometria działała tylko wspomagająco. Czasami pomagało się też robotowi po prostu ręcznie wskazując mu jego aktualną pozycję na mapie pomieszczenia. Po skończonym mapowaniu, robot jeżdżąc po sali, porównywał odczyty z dalmierzy z tymi zapisanym wcześniej w pamięci. Jeśli wynik nie był jednoznaczny - jechał kawałek dalej i porównywał kolejny punkt. W ten sposób, po kilku ruchach, robot był w stanie jednoznacznie określić swoje położenie na mapie, co później można było wykorzystać np. do wydawania mu poleceń w stylu "jedź do operatora, potem jedź pod tablicę" itd.

Ogromną zaletą takiego rozwiązania jest orientacja robota w swoim aktualnym położeniu niezależnie od położenia pierwotnego. Innymi słowy - można było wyłączonego robota przenieść na drugi koniec sali, a on i tak po uruchomieniu dosyć szybko dochodził do tego, gdzie się aktualnie znajduje.

W ćwiczeniu musieliśmy na koniec jeszcze dodać opcję omijania przeszkód znajdujących się po drodze - czyli otoczenie mogło się w niewielkim stopniu zmieniać, a robot mimo wszystko musiał umieć nawigować. Brzmi skomplikowanie, ale rozwiązanie bazowało na prawie gotowym oprogramowaniu - szczegóły można znaleźć w instrukcji/sprawozdaniu do laborek.

paper60.pdf

InTech-Design_of_test_tracks_for_odometry_calibration_of_wheeled_mobile_robots.pdf

Sprawozdanie LIMIS-Pioneer 3DX-AiR-grupa 6.pdf

Instrukcja_Pioneer.pdf

[mactro]

W jaki sposób powstała mapa laboratorium? Była przygotowana ręcznie, czy przez SLAM, a później podana jakiejś dodatkowej obróbce? Fajne laborki w każdym razie 🙂

Żeby jakoś rozruszać temat, przedstawię może koncepcję latarni ultradźwiękowych. Otóż, aby rozwiązać problem identyfikacji, z której latarni nadszedł sygnał i czy to co odbiera robot jest impulsem z dalekiego nadajnika, czy odbitym echem z bliskiego (co mogłoby być problemem przy wielu nadajnikach), myślę, że warto nadajnik zamontować na robocie, a odbiorniki na nieruchomych "stacjach nasłuchowych".

Kiedy robot chciałby się zlokalizować, wysyłałby impuls US i jednocześnie komunikował ten fakt przez radio. Dzięki temu stacje wiedziałyby kiedy został wysłany impuls i mogłyby odpowiedzieć, również radiowo, odległością w jakiej są od robota. Dalej zostaje tylko wyliczenie pozycji na podstawie odległości od trzech znanych punktów, czyli łatwizna 😉

[BlackJack]

Hm..sygnał to sygnał, nie można w latarniach wbudować koderów podobnych do RC5, każda latarnia ma swój adres, no to wiesz od której dostałeś sygnał. Nie wiem czy by się nie zakłócały, ale gdyby, mogą mieć nadajnik i odbiornik, i działać w systemie Tocken Ring, czyli takiego pierścienia w którym nadaje jeden za drugim w zamknietym łańcuchu.

[l153k]

To może tak:

kamerka na suficie, z filtrem przepuszczającym tylko IR

dioda na robocie, mogłaby nadawać coś z prędkością kamery (np. 24 klatki/s -> 3B/s)-wtedy kilka robotów dałoby się od siebie odróżnić. Wiadomo, że z tą prędkością robot się przemieści zauważalnie nawet w czasie przesyłania jednego bajta-ale rozpoznać która kropka to która na kolejnych zdjęciach to nie jest raczej coś bardzo trudnego (a jak znamy bezwładność robota i jego przyspieszenie, to możemy prawie na 100% rozróżnić kropki)

[ Dodano: 04-11-2013, 13:57 ]

Albo jeszcze inaczej-kod kreskowy na listwie przypodłogowej, zapisany w jakimś systemie tak, żeby patrząc na dowolny kawałek (o jakiejś długości) można było rozpoznać na który kawałek się patrzy. Powiedzmy że w pokoju od drzwi w prawo leci 1,2,3...100 (a dalej 1-czyli zamknięta pętla).

Robot patrzy przed siebie i widzi 5, zerknie o np. 45st. w prawo, widzi 20, zerknie w lewo, widzi 90. Jeśli wszystkie te liczby są na jednej ścianie (robot musi mieć kształt pokoju w pamięci i jakąś informację o rozmieszczeniu liczb), to wie że jest na wprost liczby 5 (bo od 5 do 20 i do 90 ma tyle samo), i wie w jakiej odległości (jak zobaczy 5, 35 i 75 to będzie dwa razy dalej od 5 na ścianie-tw. Talesa chyba)

[maciejuszek]

My w Sarmaticku - robotcie klasy "Puck Collect" wykonaliśmy system pozycjonowania przy pomocy myszy komputerowej oraz żyroskopu. Obydwa elementy są zamocowane w środku geometrycznym robota, dodatkowo myszka ma możliwość ruchu względem konstrukcji tylko w pionie - tak aby zawsze dotykała podłoża.

Zalety:

- poślizg kół nie wpływa na pomiar

- nie potrzeba żadnej komunikacji z zewnętrznymi latarniami

Wady:

- robot musi cały czas przylegać do podłoża

- podłoże, po którym jeździ powinno być płaskie i jednolite

- lekkie nierówności w podłożu potrafią nieźle namieszać w pomiarze

- błąd pomiaru narasta z czasem

Metoda ta okazała się wystarczająca do użycia w konkurencji Puck Collect. Informację o położeniu wykorzystujemy do najszybszego powrotu do bazy. W przypadku jeśli pomiar zawodzi (Sarmatic wyznacza, że jest daleko poza planszą, co się zdarza lecz bardzo rzadko) to robot posługuje się czujnikami odległości.

[Treker (Damian Szymański)]

maciejuszek, jaką uzyskujecie dokładność w takim rozwiązaniu? Tak przykładowo po kilku minutach/ruchach? Rozważaliście inne rozwiązania?

[maciejuszek]

Błąd pomiaru wynosi max 2%. Raz przeprowadziliśmy testy na sali o długości 30m. Gdy robot przejechał tam i z powrotem to wartość początkową wskazywał pół metra od faktycznego miejsca startu, co odpowiada szerokości samego robota.

Cały system był tworzony tylko do Puck Collect, gdzie czas rozgrywki wynosi 3 min, a plansza jest kwadratem o boku 2,8m. W takich warunkach robot po zakończonym przejeździe myli się średnio o 5cm, co w tej konkurencji jest znikomą wartością.

Niestety na tym zakończyła się nasza inwencja twórcza. Żadne lepsze czy gorsze rozwiązanie nie urodziło się w naszych głowach...

[Treker (Damian Szymański)]

maciejuszek, o to szczerze mówiąc zaskoczyłeś mnie jak dokładne jest to rozwiązanie. Niestety, w przypadku większej ilości przeszkód lub nie równości terenu metoda będzie generowała spore błędy. Jednak jeśli, ktoś będzie chciał lokalizować robota w "idealnym środowisku" to metoda ta będzie wystarczająca.

[Treker (Damian Szymański)]

Widzę, że temat powoli ucichł. Odnalazłem jednak pewne gotowe rozwiązanie oraz dwa ciekawe pdf'y.

Można zakupić gotowy czujniki:

http://www.robotshop.com/en/hagisonic-stargazer-localization-system.html

za okazyjne 980$ 😉

Jednak warto zwrócić uwagę na pdf'y z załącznika.

hagisonic-stargazer-v-manual-stargazer.pdf

stargazer_user_manual_ver_04_080417(english).pdf

[havoc]

a ja proponuję po prostu stary telefon z Androidem na pokładzie i dobrze napisaną aplikację 😉

andAR

Bardzo stary projekt, tak stary, że telefony na których to działa kosztują na dziś dzień ~200zł 😉

I uwaga! nie wykorzystuje OpenCV 😉

Pozdrawiam

PS. pierwszy post 😉