Skocz do zawartości
rafiko93

Robot Janusz tworzący mapę otoczenia w ROS

Pomocna odpowiedź

Cześć!

Chciałbym zaprezentować wam mojego robota o imieniu Janusz. Był to temat mojej pracy inżynierskiej. Robotem sterujemy zdalnie za pomocą innego komputera bądź laptopa z dostępem do internetu. Robot jest o tyle ciekawy, bo jest to chyba pierwsza konstrukcja na forbocie korzystająca z platformy Robot Operating System (ROS). Dzięki niej robot tworzy mapę otoczenia.

Budowa:

Złożenie robota wykonano w programie Autodesk Inventor. Zastosowanie systemu CAD umożliwiło wprowadzanie licznych zmian i poprawek bez potrzeby tworzenia rzeczywistych prototypów. Rama została wykonana z profili aluminiowych 20x20x15 [mm], a także płyt z pleksiglas. Rysunek poniżej przedstawia widok złożenia zaprojektowanej konstrukcji.

Specyfikacja:

-Wymiary: 530x440x580 [mm]

-Waga: 8,5 [kg]

-Ładowność: 3 [kg]

-Prędkość: 0,5 [m/s]

Napęd:

Robot posiada napęd na cztery koła tzw. napęd burtowy (na podobnej zasadzie jeżdżą czołgi). W robocie zastosowano silniki Pololu 70:1 Metal Gearmotor 37Dx54L wraz z enkoderami magnetycznymi. Silniki zasilane napięciem 12 [V] charakteryzują się wysokim momentem obrotowym 1,37 [Nm], a także zadowalającą prędkością obrotową na poziomie 150 [obr/min]. Silniki przenoszą napęd na koła, za pomocą półosi wykonanych w technologi druku 3D z nylonu. Koła robota zostały zdemontowane z samochodu zabawki.

Silnik wraz z kołami:

Półoś:

Część elektroniczna:

Robot zasilany jest z akumulatora żelowego o pojemności 7,2 [Ah], wystarcza na ponad dwugodzinną pracę. Kinect zasilany jest poprzez stabilizator napięcia LM2940. Arduino Mega 2560 zasilane jest poprzez przewód USB i za pomocą dwóch motor shieldów MC33926 steruje pracą silników. Zastosowane enkodery inkrementalne umożliwiają pomiar z rozdzielczością 48 impulsów na obrót. Po przeliczeniu jeden impuls enkodera występuje co 0,08 [mm] przejechanej trasy. Schemat elektryczny wykonano w programie Eagle i pokazano poniżej.

Oprogramowanie:

W celu umożliwienia sterowania ruchem robota i budowy mapy otoczenia wykorzystano platformę programistyczną ROS. Jest ona zbiorem bibliotek i narzędzi pozwalających nie tylko na sterowanie, ale także symulację oraz wizualizację ruchu pojazdu. Jedną z głównych zalet Robot Operating System jest fakt, iż jest to platforma całkowicie darmowa, zarówno do celów naukowych, jak i komercyjnych. Oparta jest na systemie operacyjnym Linux, a możliwe języki programowanie to C++ lub Python.

Sterowanie robotem odbywa się za pomocą klawiatury. Poniżej przedstawiono widok operatora (istnieje możliwość powiększenia okna z widokiem z kamery, co ukazano na filmie).

Robot tworzy mapę za pomocą metody odometrycznej, niestety obarczona jest narastającym błędem wraz ze wzrostem przebytej trasy.Spowodowane miedzy innymi poślizgiem kół czy błędnym odczytem z czujników. Poniżej przedstawiam uzyskaną mapę korytarza akademika (w przyszłości postaram się skalibrować czujniki, tak aby uzyskać lepszą dokładność).

Perspektywy rozwoju:

W przyszłości zamierzam zamiast notebooka zastosować Raspberry Pi 2 z wgranym systemem operacyjnym linux. Napisać dodatkowe oprogramowanie zwiększające funkcjonalność robota. Dodanie pakietu navigation zapewni autonomiczność platformy, czyli możliwość poruszania się bez udziału operatora. Innym kierunkiem rozwoju może być napisanie oprogramowania do sensora Kinect, umożliwiającego wydawanie poleceń za pomocą gestów lub rozpoznawanie przedmiotów.

Jest to mój pierwszy zbudowany robot. Z racji tego że wykonywałem go w akademiku bez profesjonalnego sprzętu część mechaniczna ma wiele wad i niedociągnięć. Sporo czasu zajęło zrozumienie i poznanie platformy programistycznej ROS. Dla zainteresowanych mogę udostępnić program na arduino. Proszę o opinie.

Poniżej przedstawiam film z działania robota:

__________

Komentarz dodany przez: Treker

Poprawiłem filmik, teraz wszystko się zgadza 🙂

z2.thumb.jpg.63c2e5a30dc6afb33d1ab01def0e3c28.jpg

  • Lubię! 2

Udostępnij ten post


Link to post
Share on other sites

Podoba Ci się ten projekt? Zostaw pozytywny komentarz i daj znać autorowi, że zbudował coś fajnego!

Masz uwagi? Napisz kulturalnie co warto zmienić. Doceń pracę autora nad konstrukcją oraz opisem.

Dlaczego zdecydowałeś się na taki układ napędu? Odometria przy poślizgu kól jaki tu masz już na wstępie jest utrudniona. Czy przy tworzeniu mapy korzystasz z jakiś metod dopasowywania skanów?

Udostępnij ten post


Link to post
Share on other sites

Nie chciałem iść na łatwiznę i zbudować robota klasy (2,0) tzw. unicykle, gdzie poślizg kół by nie występował. Ciekawiło mnie własnie uzyskanie dokładnej odometrii przy poślizgu kół. Poprzez odpowiednio dobrany algorytm, błąd wynikający z poślizgu kół udało się zniwelować. Niestety zabrakło czasu, żeby skalibrować całość na ideał. W przyszłości dopracuje ten algorytm. Dane z sensora głebi czujnika Kinect zamieniane są na skan laserowy (coś podobnego do danych z profesjonalnych skanerów laserowych 3D), a następnie za pomocą pakiety "gmapping" sklejane w całość. Uwzględniając aktualną odometrię.

Udostępnij ten post


Link to post
Share on other sites

Mam kilka wątpliwości odnośnie samego opisu:

Robot tworzy mapę za pomocą metody odometrycznej, niestety obarczona jest narastającym błędem wraz ze wzrostem przebytej trasy.Spowodowane miedzy innymi poślizgiem kół czy błędnym odczytem z czujników.

Co jest spowodowane błędnym odczytem z czujników? Nie do końca rozumiem, jaki podmiot ma to drugie zdanie.

Poprzez odpowiednio dobrany algorytm, błąd wynikający z poślizgu kół udało się zniwelować.
W przyszłości postaram się skalibrować czujniki, tak aby uzyskać lepszą dokładność.

Co rozumiesz poprzez odpowiednio dobrany algorytm? Chodzi Ci o zwykłą kalibrację jeżeli dobrze rozumiem? To w końcu co jest skalibrowane, a co nie?

Udostępnij ten post


Link to post
Share on other sites
Nie chciałem iść na łatwiznę i zbudować robota klasy (2,0) tzw. unicykle, gdzie poślizg kół by nie występował. Ciekawiło mnie własnie uzyskanie dokładnej odometrii przy poślizgu kół. Poprzez odpowiednio dobrany algorytm, błąd wynikający z poślizgu kół udało się zniwelować. Niestety zabrakło czasu, żeby skalibrować całość na ideał. W przyszłości dopracuje ten algorytm. Dane z sensora głebi czujnika Kinect zamieniane są na skan laserowy (coś podobnego do danych z profesjonalnych skanerów laserowych 3D), a następnie za pomocą pakiety "gmapping" sklejane w całość. Uwzględniając aktualną odometrię.

Kinect jest zupełnie wystarczający, jedyne czego mu brakuje to laser, najlepiej taki aby nakładał coś na pierwowzór poligonów (siatki).

Udostępnij ten post


Link to post
Share on other sites
Nie chciałem iść na łatwiznę i zbudować robota klasy (2,0) tzw. unicykle, gdzie poślizg kół by nie występował. Ciekawiło mnie własnie uzyskanie dokładnej odometrii przy poślizgu kół. Poprzez odpowiednio dobrany algorytm, błąd wynikający z poślizgu kół udało się zniwelować. Niestety zabrakło czasu, żeby skalibrować całość na ideał. W przyszłości dopracuje ten algorytm. Dane z sensora głebi czujnika Kinect zamieniane są na skan laserowy (coś podobnego do danych z profesjonalnych skanerów laserowych 3D), a następnie za pomocą pakiety "gmapping" sklejane w całość. Uwzględniając aktualną odometrię.

Kinect jest zupełnie wystarczający, jedyne czego mu brakuje to laser, najlepiej taki aby nakładał coś na pierwowzór poligonów (siatki).

Wystarczający do czego? Dlaczego uważasz, że mu brakuje lasera, skoro laser jest emulowany właśnie przez kinecta? Zupełnie nie zrozumiałem Twojej wypowiedzi...

Udostępnij ten post


Link to post
Share on other sites
Nie chciałem iść na łatwiznę i zbudować robota klasy (2,0) tzw. unicykle, gdzie poślizg kół by nie występował. Ciekawiło mnie własnie uzyskanie dokładnej odometrii przy poślizgu kół. Poprzez odpowiednio dobrany algorytm, błąd wynikający z poślizgu kół udało się zniwelować. Niestety zabrakło czasu, żeby skalibrować całość na ideał. W przyszłości dopracuje ten algorytm. Dane z sensora głebi czujnika Kinect zamieniane są na skan laserowy (coś podobnego do danych z profesjonalnych skanerów laserowych 3D), a następnie za pomocą pakiety "gmapping" sklejane w całość. Uwzględniając aktualną odometrię.

Kinect jest zupełnie wystarczający, jedyne czego mu brakuje to laser, najlepiej taki aby nakładał coś na pierwowzór poligonów (siatki).

Wystarczający do czego? Dlaczego uważasz, że mu brakuje lasera, skoro laser jest emulowany właśnie przez kinecta? Zupełnie nie zrozumiałem Twojej wypowiedzi...

Ponieważ normalny laser jest dożo dokładniejszy, dobrze byłoby aby obiekty widział i zapamiętywał co do śrubki 😃

Udostępnij ten post


Link to post
Share on other sites
Nie chciałem iść na łatwiznę i zbudować robota klasy (2,0) tzw. unicykle, gdzie poślizg kół by nie występował. Ciekawiło mnie własnie uzyskanie dokładnej odometrii przy poślizgu kół. Poprzez odpowiednio dobrany algorytm, błąd wynikający z poślizgu kół udało się zniwelować. Niestety zabrakło czasu, żeby skalibrować całość na ideał. W przyszłości dopracuje ten algorytm. Dane z sensora głebi czujnika Kinect zamieniane są na skan laserowy (coś podobnego do danych z profesjonalnych skanerów laserowych 3D), a następnie za pomocą pakiety "gmapping" sklejane w całość. Uwzględniając aktualną odometrię.

Kinect jest zupełnie wystarczający, jedyne czego mu brakuje to laser, najlepiej taki aby nakładał coś na pierwowzór poligonów (siatki).

Wystarczający do czego? Dlaczego uważasz, że mu brakuje lasera, skoro laser jest emulowany właśnie przez kinecta? Zupełnie nie zrozumiałem Twojej wypowiedzi...

Ponieważ normalny laser jest dożo dokładniejszy, dobrze byłoby aby obiekty widział i zapamiętywał co do śrubki 😃

No nie do końca. Kinect (w wersji 1.0) ma rozdzielczość kątową równą około 0.1 stopnia (horyzontalnie), gdzie na przykład rozdzielczość URG-04LX-UG01 to 0.35 stopnia. Skanery laserowe mają za to zazwyczaj lepszą rozdzielczość i dokładność głębi. Z resztą, to jest jak dyskusja na wyższością jednych Świąt nad drugimi, ponieważ oba urządzenia aplikują się do innych zastosowań (i innych kieszeni).

Jeśli zaś chodzi o rozpoznawanie obiektów skaner jest zdecydowanie mniej przydatny niż kamera RGB-D - chyba, że chcesz rozpoznawać nogi stołu/krzesła, ale na pewno nie "główki śrubek".

Udostępnij ten post


Link to post
Share on other sites
Nie chciałem iść na łatwiznę i zbudować robota klasy (2,0) tzw. unicykle, gdzie poślizg kół by nie występował. Ciekawiło mnie własnie uzyskanie dokładnej odometrii przy poślizgu kół. Poprzez odpowiednio dobrany algorytm, błąd wynikający z poślizgu kół udało się zniwelować. Niestety zabrakło czasu, żeby skalibrować całość na ideał. W przyszłości dopracuje ten algorytm. Dane z sensora głebi czujnika Kinect zamieniane są na skan laserowy (coś podobnego do danych z profesjonalnych skanerów laserowych 3D), a następnie za pomocą pakiety "gmapping" sklejane w całość. Uwzględniając aktualną odometrię.

Kinect jest zupełnie wystarczający, jedyne czego mu brakuje to laser, najlepiej taki aby nakładał coś na pierwowzór poligonów (siatki).

Wystarczający do czego? Dlaczego uważasz, że mu brakuje lasera, skoro laser jest emulowany właśnie przez kinecta? Zupełnie nie zrozumiałem Twojej wypowiedzi...

Ponieważ normalny laser jest dożo dokładniejszy, dobrze byłoby aby obiekty widział i zapamiętywał co do śrubki 😃

No nie do końca. Kinect (w wersji 1.0) ma rozdzielczość kątową równą około 0.1 stopnia (horyzontalnie), gdzie na przykład rozdzielczość URG-04LX-UG01 to 0.35 stopnia. Skanery laserowe mają za to zazwyczaj lepszą rozdzielczość i dokładność głębi. Z resztą, to jest jak dyskusja na wyższością jednych Świąt nad drugimi, ponieważ oba urządzenia aplikują się do innych zastosowań (i innych kieszeni).

Jeśli zaś chodzi o rozpoznawanie obiektów skaner jest zdecydowanie mniej przydatny niż kamera RGB-D - chyba, że chcesz rozpoznawać nogi stołu/krzesła, ale na pewno nie "główki śrubek".

Masz rację, kluczem nie jest super laser, ale algorytm 😃

Udostępnij ten post


Link to post
Share on other sites

Szacunek za fajny projekt! Ja też kiedyś myślałem o czymś takim, ale niestety ambicje przerosły umiejętności 🙁

Nie jestem wielkim ekspertem od robotyki, ale co sądzisz o takim pomyśle na uwzględnienie poślizgu kół?:

Wydaje mi się, że każde mierzalne (0,08 mm) przesunięcie pojazdu wpływałoby na wskazania akcelerometru i/lub kompasu, przy czym każda taka zmiana jest przewidywalna. Gdy koło się ślizga, przewidziana zmiana nie następuje, lub nie jest wystarczająca i daną różnicę da się uwzględnić przy określaniu położenia pojazdu.

Udostępnij ten post


Link to post
Share on other sites

Przyznam, że bardzo fajny pomysł na pracę inżynierską. Szacunek przede wszystkim za to, że nie poszedłeś na łatwiznę a zadałeś sobie jakiś problem, który na swój sposób rozwiązałeś, a takie rzeczy się ceni. Fajnie jeżeli po obronie nie zaprzestaniesz prac i jeszcze usprawnisz działanie Janusza.

Udostępnij ten post


Link to post
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Gość
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.


×
×
  • Utwórz nowe...