Skaner laserowy 360 stopni RPLidar

[aw]

Na botlandzie pojawił się nowy produkt:

http://botland.com.pl/skanery-laserowe/2730-skaner-laserowy-360-stopni-rplidar.html

Opis:

Precyzyjny skaner laserowy 2D działający w obszarze 360 stopni o zasięgu 6 m. Częstotliwość odświeżania wynosi do 5,5 Hz czyli 2000 próbek na sekundę, do komunikacji służy interfejs szeregowy - wyprowadzenia RX i TX.

Ponoć ma biblioteke do Arduino.

Produkt bardzo drogi bo 1 870,00 zł ale wydaje się marzeniem robotyka 🙂 Co o tym myślicie?

[Elvis]

Za ta cene to ja bym poczekal. Tylko 2D...

Polecam popatrzec co szykuje google:

https://www.google.com/atap/projecttango/#project

[marek1707]

No nie, jednak Google robi coś innego - nie porównywałbym tego.

Szybki, dookólny czujnik o sensownym zasięgu i rozdzielczości to rzeczywiście marzenie każdego robotyka. Do tej pory takie głowice laserowe kosztowały po kilka tysięcy (5+) i choćby z tego powodu były ograniczone do zastosowań profesjonalnych lub mocno sponsorowanych zespołów studenckich. Ta w porównaniu z nimi jest.. hm, tania 😐

Tak, wiem, dla większości może to być kontrowersyjne stwierdzenie, bo kieszonkowe nie wystarcza czasem na mostek do silnika, ale dla osób które już zdecydowały o swojej przyszłości i chcą ją wiązać z elektroniką/robotyką oraz zaczęły pracę i coś tam zarabiają, może to być inwestycją w siebie. Można uczyć się angielskiego a można po nocach pisać kod mapowania zeskanowanej przestrzeni 2D w grafy i poszukiwania drogi przejazdu w diagramach Voronoi'a (swoją drogą polecam temat).

Właśnie, i tu dochodzimy do kolejnego problemu: spożytkowanie danych z takiego czujnika to sztuka sama w sobie. Algorytmy SLAM (choćby po to by uratować misia) to już wyższa szkoła jazdy i wcale nie jest oczywiste jaką elektronikę powinien mieć na pokładzie taki robot. Na pewno żaden 8-bitowy procesor nie poradzi sobie ani z wykonaniem mapowania w sensownym czasie ani nawet z samą ilością danych do przetworzenia, bo to trochę jakby zmuszać biednego AVR do rozpoznawania twarzy znajomych na obrazie z kamery. Moim zdaniem płytka klasy Maliny to absolutne minimum a pewnie i tak zwykle kończy się na jeżdżącym, wielordzeniowym PC lub mocnym DSP 🙁 W każdym razie może czasem warto wejść w taki temat na rok czy dwa, wykonać jakiś fajny (i płatny) projekt a za uzbierane pieniądze kupić skaner. Zabawa na pewno jest przednia i już samo czytanie tego co ludzie z tym zrobili (a jest tego trochę), jak wyglądają już opracowane algorytmy i ile jeszcze można tutaj zdziałać jest fascynujące.

[Elvis]

To co robi google nie jest az tak rozne od prezentowanego skanera. Tango tez ma wbudowany laserowy pomiar odleglosci, ma natomiast nieco wiecej czujnikow i niezly procesorek (NVidia K1). Skaner dziala podobnie do kinect-a, wiec pozwala na skanowanie wiecej niz jednego punktu. Jedyny minus to brak obrotowej platformy. To mozna na szczescie byloby zrobic we wlasnym zakresie - wymontowac kamerke IR wraz z laserem i zamocowac np. na serwie. Aktualna cena to 1024$, ale jak projekt wejdzie w faze produkcyjna, cena pownna byc porownywalna ze zwyklymi telefonami / tabletami. A wtedy moze to byc ciekawe rozwiazanie.

[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

[aw]

Moim zdaniem pod względem możliwości projekt google tym się różni że daje od razu 3d, nie trzeba tego przetwarzać z drugiej strony jego czujnik ma skromniejsze możliwości.

Zgadzam się że to jest potęga i naprawdę może być krokiem milowym w robotyce. Jeżeli ktoś jest prawdziwym hobbysta to ta cena go nie powinna przerazić. Fotografowie kupują droższy sprzęt 🙂.

Z punktu jednak widzenia robotów sumo/line follower a nawet mouse nie widzę zastosowania. Te projekty nie wykorzystają tych możliwości.

Jeżeli chodzi o moc obliczeniową to sądze że np. pic32 spokojnie wystarczy (jedyny mikrokontroler 32bit na nóżkach THT). To zalezy od rozdzielczości ale do poruszania po pokoju nie potrzeba dużej a można ją uzupełnić o inny rodzaj czujnika. Zresztą pytanie czy nie wystarczy utrzymanie w pamięci umiejscowania punktów w przestrzeni czy od razu potrzeba grafów? To zależy co chcemy osiągnąć. Pamiętajmy że pierwsze gry 3d oparte o wektorową grafikę pojawiły się na słabych 16bitowcach. Ja pamiętam że takie gry potrafiły chodzić bez przyspieszenia sprzętowego.

Dla mnie najtrudniejszą kwestią wbrew pozorom będzie zapewnienie odpowiedniej pamięci. Mikrokontrolery nie mają jej za dużo, a jednak pamięć liczona w kB niestety nie będzie wystarczała, zwłaszcza jak dodamy do tego poruszanie się robota i przyrost danych.

[Wikkan]

Pracuje na codzień z takimi skanerami, głównie bezpieczeństwa ale też z skanerami pomiarowymi. Świetna rzecz, 50 m zasiegu. Ta głowica nie jest droga, w porównaniu do profesjonalnego sprzetu, a jak ktoś ktos na poważnie zajmuje się robotyka to sprzęt jest naprawdę super. A na upartego to nawet Atmega dala by rade. Zamiast mapowac wszystko szuka się tylko zadanych punktów. Tak się to wykonuje w przemyśle gdy nie trzeba skanować wszystkiego ale jak ktoś kupuje taki sprzęt to raczej projekt jest troche bardziej skomplikowany.

[marek1707]

No tak, ATmega, ale Ty mówisz o sytuacji w której skaner zamontowany jest na stałe w jednym położeniu i ma sprawdzać, czy ktoś nie wszedł do chronionej strefy. Wtedy OK, z całego pola widzenia wybieramy pewien wektor np. kilkudziesięciu odległości i sprawdzamy, czy któraś nie jest mniejsza od zadanego progu. To łatwe i rzeczywiście każdy sobie z tym poradzi. Ale odwracamy sytuację i wstawiamy skaner na robota. Tu już nie chodzi o detekcję odległości od ściany z przodu czy z boku, bo to trywialne i do tego wystarczy czujnik odległości typu SHARP tylko o rozumienie sytuacji w otoczeniu. Wstawienie takiego skanera do pojazdu, który ma się nie obijać o ściany w pokoju jest proste, tylko po co to? Jeżeli ma bezkolizyjnie poruszać się po nieznanych pomieszczeniach i jeszcze realizować jakiś cel (np. dostarczyć coś gdzieś) to musi nie tylko zrozumieć co widzi, ale także umieć odróżnić wąskie przejście od szerokiego i znaleźć drogę w takim labiryncie kształtów. Mamy zatem ciąg kilkuset liczb określających odległość od wszystkiego dookoła. Robot się porusza i obraca, więc kilka(naście) razy na sekundę dostajemy inny zestaw kilkuset liczb. Musimy to przerzucić na bitmapę otoczenia zawsze zorientowaną tak samo więc budujemy ją iteracyjnie (bo przecież są błędy pomiarów) wielokrotnie nakładając na siebie kolejne skany i za każdym razem robiąc obrót do żądanej, stałej orientacji plus oczywiście przesunięcie wynikające z jazdy i nowego punktu odniesienia. Czujnik widzi tylko pierwszy plan, a przecież poruszając się robot wciąż "odkrywa" nowe obszary dotychczas zasłonięte rogami mebli czy słupami w hali i wszystko wciąż się zmienia. Nawet jeśli uzyskamy tymczasową mapę przeszkód to przecież dopiero początek drogi, bo taka wielka macierz jest bezużyteczna. Trzeba z niej wyciągnąć położenie rzeczywistych przeszkód więc algorytmy rozpoznawania elementów obrazu zamieniają bitmapę na najbardziej prawdopodobne (bo nic nie jest pewne na 100%) położenie ścian złożonych np. z prostych lub aproksymowanych odcinkami i dopiero wtedy można zacząć bawić się w wyznaczanie trasy tak, by niezerowej wielkości robot zmieścił się między sprzętami. Tutaj budowanie grafów i znajdowanie w nich drogi to standard.

Gry robiły (i robią) to dokładnie odwrotnie i dlatego to zły przykład. Tam cały świat zaprojektowany jest wcześniej i mnóstwo developmentu pochłania takie przygotowanie danych, by algorytmy nie musiały męczyć się z rozpoznawaniem kształtów czy położenia obiektów. Grafy, węzły i ich połączenia są rozpisane wcześniej i wbrew pozorom NPCe nie chodzą tam gdzie im się "podoba" choć programiści stają na głowie, byś tak pomyślał. Wszystko jest tam bardzo uproszczone tylko po to, by zachować płynność i zostawić jeszcze trochę mocy na AI przeciwników.

Lepszym przykładem byłyby np. samochody jeżdżące samodzielnie. Co? Nie ma takich na ulicach? A to, znaczy, że to widocznie trudne.

[Wikkan]

Autonomicznych pojazdów w tym aut pojawia się coraz więcej, może nie są to jednostki dopuszczone do ruchu (poza drobnymi wyjątkami) ale jednak coś się dzieje w temacie.

Co do dynamicznego skanowania i mapowania otoczenia, wszystko zależne jest od zapotrzebowania i np. wózek jezdny (paletowy) nie musi robić dokładnej mapy otoczenia, np. gdy skaner pomiarowy który wysyła pomiary już maksymalnie uproszczone do interpretacji nie jest jedynym czujnikiem a jednym z wielu współpracujących ze sobą, w takim wypadku wykorzystywane są enkodery, znaczniki (foto, magnetyczne, radiowe), GPS (ale to przy dużych odległościach), i inne sposoby detekcji położenia w przestrzeni. Poglądowa wersja mapy może być już wgrana do pamięci a odczyty ze skanera będą ją aktualizować, jeżeli na obiekcie poruszają się tylko takie pojazdy to również w "miarę" prosty sposób można rozwiązać problem zmieniającego się otoczenia i fałszowania mapy (np. gdy obok wózka przejedzie inny wózek).

PS: Gdy by po ulicach jeździły tylko autonomiczne pojazdy, komunikujące się i zarządzane lub wspomagane przez główną jednostkę (Wielki Brat 🙂 ), a drogi były idealne to wdrożenie autonomicznych pojazdów nie nastręczało by wielkich problemów. Problemem jest to że człowiek jak i sytuacja na drodze jest nieprzewidywalna i dynamiczna, komputer nie potrafi reagować "kreatywnie" i słusznie na każdą ewentualność.

To takie moje luźne przemyślenia.

[marek1707]

Oczywiście masz rację. Bardzo dużo zależy od zastosowania i celów jakie chcemy osiągnąć. Po prostu chciałem powiedzieć, że temat nie jest prosty a kupowanie takiego czujnika i próba jego opanowania będzie pracą na długie miesiące. Tym bardziej, że jego relatywnie (do innych podobnych) niska cena wcale mała nie jest w porównaniu choćby z czujnikami ultradźwiękowymi czy optycznymi-triangulacyjnymi i nie ma sensu używać go w prostych aplikacjach. Za to w tych bardziej wyrafinowanych bardzo szybko okaże się jak dobrze słuchaliśmy wykładów z matematyki i jak umiemy tę wiedzę stosować.

Tak więc dla profesjonalisty: super, można zbudować za ten sam budżet dwa lub trzy pojazdy zamiast jednego lub przeznaczyć więcej pieniędzy na badania czy testowanie.

Dla ambitnego amatora: będzie się musiał pogodzić z pewnymi wyrzeczeniami (-Mamo, czy jest coś do jedzenia? -Nie.), ale gdy już do tego usiądzie, odkryje świat zupełnie nowych wyzwań i możliwości a po kilku początkowych sukcesach (-Mamo patrz jaka ładna mapa biurka! -Ale tu masz bałagan synku..) trzeba będzie dokupić mobilny komputer embedded, zasilanie no i zacząć czytać książki.

Dla początkującego: absolutnie odradzam - bariera cenowa i głównie aplikacyjna nie do przejścia mimo wsparcia w materiały firmowe.

Fajnie, że takie rzeczy tanieją. Szkoda, że wciąż mają elementy ruchome (wirująca głowica) no i to jednak ciągle delikatna optyka i mikromechanika. Dzięki taniejącej mocy obliczeniowej być może nadzieja na SLAM w wizji 3D (w końcu my tak to robimy) albo może kamerach Time-of-Flight?

[aw]

Aż znajdzie ktoś taki który nie wie że czegoś się nie da zrobić i to robi... 😉

Ale serio pisząc to nie wiem jak możecie dojść do jakiegokolwiek konsensusu skoro jeden z Was mówi o prostym poruszaniu się wzdłuż labiryntu a drugi o czymś bardziej skomplikowanym np. rozpoznaniu piłki i jej podniesieniu. W pierwszym wypadku rzeczywiście nie potrzeba wiele - wystarczą skrajne punkty.

Teraz jednak przeczytałem specyfikacje i wydaje się mi że można spróbować to samo zrobić za pomocą sharpa ale na mniejszą odległość. Zależy jak szybko działa czujnik sharpa. Bawiłem się tylko czujnikami ultradźwiękowymi więc nie wiem.

http://www.robotshop.com/en/rplidar-360-laser-scanner.html

Podsumowując ak naprawdę nie daje on obrazu 2d w taki sposób jak myślałem tylko po prostu kręci się w kółko daje odległości ale względem tylko linii w której znajduje się laser.

[marek1707]

Ej, zaraz, chyba żaden z nas nie mówił o piłce. Obaj wiemy jak taki czujnik działa i obaj wiemy, że jest wiele możliwości wykorzystania otrzymywanych danych, ale trudno w nich będzie odróżnić piłkę od słupa. Ja nie mam wrażenia, że mówimy o dwóch zupełnie różnych rzeczach. W jednych aplikacjach będzie łatwiej, bo możemy a priori wbudować mapy i próbować dopasowywać je do tego co widzi czujnik posiłkując się danymi z systemów bezwładnościowych czy GPS, a w innych, nieznanych otoczeniach będzie trudniej. I jedno i drugie wymaga dużo pracy i mniej lub (raczej) bardziej skomplikowanych algorytmów. O ile zabawka może potrącić kota i nic się nie stanie, o tyle wózek widłowy raczej rozkwasić na ścianie kogoś nie powinien więc w zastosowaniach profesjonalnych dochodzą czynniki planowania, wdrażania i testowania. Nie widzę tu dwóch istotnie różnych punktów widzenia i konieczności dochodzenia do kompromisu.

Czujnik SHARPa potrzebuje chyba ok. 10ms na pomiar. Chcesz go obracać? Ktoś już takie coś tu pokazywał. OK, to pójdźmy dalej: załóżmy, że masz już wyniki takiego dookólnego skanu w postaci np. tablicy 64 liczb. Jakie jest zadanie robota i co robisz dalej?