Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Czterokołowy robot mobilny z systemem autonomicznej nawigacji w środowisku ROS

themin 19 Mar 2017 23:46 4884 9
  • Czterokołowy robot mobilny z systemem autonomicznej nawigacji w środowisku ROS

    Cześć!

    Przedstawiony robot mobilny został wyposażony w system autonomicznej nawigacji działający w środowisku ROS i wykorzystujący sensor Microsoft Kinect oraz kilka innych czujników. Platforma posiada cztery niezależnie napędzane koła i jest stosunkowo niewielkich rozmiarów. Szerokość oraz długość nie przekraczają 35 cm, a wysokość wraz z sensorem Kinect wynosi około 50 cm.

    Czterokołowy robot mobilny z systemem autonomicznej nawigacji w środowisku ROS

    Pierwszą wersję robota, czyli platformę mobilną bez dodatkowego komputera i sensora Kinect przedstawiałem już wcześniej, w tym wpisie. Jest ona wyposażona w komputer Raspberry Pi, a ponadto umieszczono w jej wnętrzu  szereg sensorów i cztery silniki prądu stałego (DC) od firmy Pololu.

    Czterokołowy robot mobilny z systemem autonomicznej nawigacji w środowisku ROS

    Dla potrzeb systemu autonomicznej nawigacji platforma została rozbudowana o dodatkowy (tymczasowy) komputer (notebook, Intel Core i3, RAM 4GB), a także sensor Kinect wraz z odpowiednimi mocowaniami. Poniżej znajduje się diagram przedstawiający architekturę sprzętową robota, natomiast opis poszczególnych elementów można znaleźć w poprzednim wpisie dotyczącym pierwszej wersji robota.

    Czterokołowy robot mobilny z systemem autonomicznej nawigacji w środowisku ROS





    Architektura systemu sterowania

    Układ sterowania robota ma strukturę wielowarstwową i został zrealizowany z wykorzystaniem kilku jednostek obliczeniowych. Jednym z wymagań dla systemu sterowania niskopoziomowego jest realizacja zadań w czasie rzeczywistym. Spełnienie takich wymagań zrealizowano przez implementację algorytmów na mikrokontrolerze Kinetis. W przypadku sterowania wysokiego poziomu, kluczową kwestią nie było zapewnienie działania w czasie rzeczywistym. Zresztą w obecnej konfiguracji robota, warunek ten nie mógłby zostać spełniony, ze względu na zastosowanie niedeterministycznych interfejsów komunikacyjnych, jak: Ethernet, czy USB. Na poniższym diagramie przedstawiono architekturę systemu sterowania robota.

    Czterokołowy robot mobilny z systemem autonomicznej nawigacji w środowisku ROS

    Warstwa sterowania wysokiego poziomu zrealizowana została w środowisku ROS w wersji Indigo. Jego zaletą jest zapewnienie mechanizmów komunikacji dla tworzonego oprogramowania umożliwiających uruchamianie komponentów na wielu maszynach jednocześnie, praktycznie bez dodatkowych nakładów pracy. Z tego powodu część komponentów systemu, głównie związanych z obsługą sterowników niskopoziomowych uruchamiano na komputerze Raspberry Pi. Urządzenie to oparte jest na procesorze ARM i działa pod kontrolą systemu Raspbian. W przypadku drugiego komputera, system sterowania uruchamiano na Ubuntu 14.04 x64 LTS. Poszczególne komponenty systemu sterowania wysokiego poziomu zrealizowane zostały w postaci węzłów (ang. node). Węzły komunikują się ze sobą za pomocą mechanizmu zwanego tematami (ang. topics). 
     
    Opisy wybranych komponentów znajdują się poniżej, a po informacje odnośnie pozostałych odsyłam do źródeł (na końcu), które można znaleźć na mojej stronie.
     
    Hardware driver
    Komponent w postaci dedykowanego sterownika podzespołów robota. Realizowane przez komponent zadania są następujące:
    - przesyłanie komend sterujących z tematu /cmd_vel do sterownika niskiego poziomu, czyli modułu sterowania silnikami,
    - pobieranie danych odometrycznych, zawierających względną pozycję i prędkości robota, ze sterownika niskopoziomowego oraz publikowanie ich w temacie /wheels_odom,
    - pobieranie z modułu sensorów danych uzyskanych z czujników inercyjnych i magnetometru oraz publikowanie ich w tematach: /imu/raw_data/imu_mag.

    Komponent uruchamiany jest na komputerze Raspberry Pi, a komunikacja z modułami niskiego poziomu wykorzystuje magistralę I2C. Został on napisany w języku C++, przy czym do obsługi magistrali I2C wykorzystywana jest biblioteka bcm2835 , służąca do obsługi niektórych funkcji procesora Broadcom BCM 2835, w który wyposażony został Raspberry Pi.

    Laser scan from Kinect
    Oprogramowanie konwertuje mapę głębi otrzymywaną z sensora Kinect do postaci wiadomości sensor_msgs/LaserScan. Dodatkowo, umożliwia usuwanie podłoża z wynikowych danych oraz kompensację kąta pochylenia sensora. Komponent był rozwijany przeze mnie w ramach projektu ReMeDi i został udostępniony jako część pakietu depth_nav_tools na stronie ROS'a.

    Navigation
    Odpowiednio skonfigurowany, standardowy pakiet środowiska ROS, realizujący zadania nawigacji.

    Testy systemu autonomicznej nawigacji

    Poniżej znajdują się wycinki interfejsu graficznego wizualizującego robota i tworzoną mapę, a także utworzoną mapę pomieszczenia.

    Czterokołowy robot mobilny z systemem autonomicznej nawigacji w środowisku ROS
    Czterokołowy robot mobilny z systemem autonomicznej nawigacji w środowisku ROS

    Przeprowadzone testy pokazały, że możliwe jest zarówno tworzenie map z wykorzystaniem sensora Kinect jak i autonomiczne poruszanie się robota po otoczeniu. Niestety, problemy sprawiają ograniczenia sensora Kinect takie jak: niewielkie kąty widzenia oraz niewielki zasięg. Powoduje to, że czasami robot ma problemy z odnalezieniem się na mapie.

    Oprogramowanie:
    Część wykorzystywanego oprogramowania (wysokiego poziomu) oraz konfiguracji standardowych komponentów ROS'a można
    znaleźć na GitHubie:
    - https://github.com/mdrwiega/tacbot
    - https://github.com/mdrwiega/depth_nav_tools

    Źródła:
    - Michał Drwięga. Bezkolizyjna nawigacja w pomieszczeniu robotem mobilnym wyposażonym w czujnik Kinect. Praca magisterska, Politechnika Wrocławska, Wrocław, 2015
    - Michał Drwięga. Fuzja sygnałów sensorycznych dla potrzeb lokalizacji kołowego robota mobilnego. Praca inżynierska , Politechnika Wrocławska, Wrocław, 2013

    Więcej informacji można znaleźć na mojej stronie www.mdrwiega.com.


    Fajne!
  • #2 20 Mar 2017 00:07
    szymon122
    Poziom 36  

    Gratuluję świetnego projektu!
    Ciekawi mnie fakt zastosowania dwóch komputerów. Co nie umożliwiło zrealizowanie tego na samym RPi?
    Chcąc zabrać się za podobny temat ale jako sensora użyć kamerki internetowej mam szansę "udźwignąć" to na raspberry pi zero? Nie mam pojęcia ile zasobów potrzebują algorytmy orientacji w przestrzeni, przetwarzanie danych z kamery itp.
    Czy twój robót oprócz zamieszczonych map potrafi tworzyć mapy 3D?

  • #3 21 Mar 2017 09:44
    themin
    Poziom 10  

    Dzięki. Jeżeli chodzi o RPi, to przy wersji 2B mocy obliczeniowej wystarcza na to, aby pobrać dane z Kinecta i ewentualnie zrobić jakieś proste przetwarzanie. Niestety, na uruchomienie algorytmu SLAM (np. gmapping), czy samej lokalizacji (AMCL) jest to znacznie za mało. Być może odpowiednia optymalizacja algorytmów trochę by pomogła, ale nie zagłębiałem się w to.

    Odnośnie kamery na RPi zero (który jest niewiele mocniejszy od RPi 1A), obawiam się, że będzie ciężko (chyba, że piszesz wszystko od zera i odpowiednio zoptymalizujesz). Oczywiście dużo zależy od tego, jakim algorytmem chcesz wykrywać cechy otoczenia i czy potrzebujesz, aby całość działała w czasie rzeczywistym (a może pozbierasz dane i uruchomisz algorytm offline?).

    Do tworzenia map 3d próbowałem używać algorytmu RGB-DSLAM, aczkolwiek przy większym otoczeniu nie działa za szybko.

  • #4 31 Mar 2017 22:22
    pako8420
    Poziom 11  

    Witaj.

    Czy zastanawiałeś się nad użyciem gimbala do stabilizacji kamery? Nawet najprostszy gimbal złożony na serwie i żyroskopie powinien już w dużej mierze poprawić jakość odczytu Kinnecta.

    Świetny projekt, pozdrawiam.

  • #5 01 Kwi 2017 01:40
    ucy74
    Poziom 20  

    Napisz pls co z zasilaniem pojazdu - akumulatory czy zasilanie z zewnątrz?
    Co z sensorami o których piszesz - oddzielna płytka - analizuje to PI czy ROS, jakie dane wyciąga, co interpretuje?
    Jeżeli stosujesz oddzielne napędy na wszystkie cztery koła to przy trajektorii "po łuku" część kół "ciągnie" a część jest "wleczona" - czy poruszacz kołami symetrycznie tak jak gąsienicami w czołgu?

  • #6 01 Kwi 2017 12:09
    themin
    Poziom 10  

    pako8420 napisał:
    Czy zastanawiałeś się nad użyciem gimbala do stabilizacji kamery? Nawet najprostszy gimbal złożony na serwie i żyroskopie powinien już w dużej mierze poprawić jakość odczytu Kinnecta.


    Nie myślałem nad tym, ponieważ robot do tej pory poruszał się raczej po równym terenie. Sama stabilizacja mechaniczna wymagałaby też mocnych napędów, ponieważ Kinect waży prawie 0,5 kg.
    Stabilizacja programowa jest znacznie łatwiejsza, gdy bazuje się na orientacji robota z IMU. Stworzyłem też narzędzie depth_sensor_pose (detekcja podłoża algorytmem RANSAC), które umożliwia wyznaczenie kąta pochylenia Kinecta względem płaszczyzny podłoża.
    Program można znaleźć tutaj: http://wiki.ros.org/depth_sensor_pose.

    ucy74 napisał:
    Napisz pls co z zasilaniem pojazdu - akumulatory czy zasilanie z zewnątrz?
    Co z sensorami o których piszesz - oddzielna płytka - analizuje to PI czy ROS, jakie dane wyciąga, co interpretuje?
    Jeżeli stosujesz oddzielne napędy na wszystkie cztery koła to przy trajektorii "po łuku" część kół "ciągnie" a część jest "wleczona" - czy poruszacz kołami symetrycznie tak jak gąsienicami w czołgu?


    Jeżeli chodzi o zasilanie, w podstawie robota znajdują się dwa akumulatory litowo-polimerowe, 3 ogniwowe, każdy o pojemności 2,2 Ah. Dochodzi oczywiście akumulator z laptopa. Aczkolwiek w nowszej wersji robota zamierzam zrezygnować z laptopa i zastosować mocniejszy, wewnętrzny komputer (np. Intel NUC).

    Odnośnie czujników, część z nich, m. in. IMU, enkodery, czujniki prądu, czy odległości przesyłają dane do dedykowanych modułów sprzętowych, później zbierane jest to przez Raspberry Pi, przetwarzane i wysyłane do drugiego komputera (ale już z wykorzystaniem protokołów ROSa). Natomiast Kinect jest podłączony bezpośrednio do laptopa (wersja RPi, którą stosuję nie poradziłaby sobie z przetwarzaniem danych).

    Napędy wszystkich kół są niezależne. Aktualnie jednak, koła są elektronicznie synchronizowane stronami, czyli w efekcie działa to tak jak w przypadku czołgu.

  • #7 01 Kwi 2017 14:57
    ucy74
    Poziom 20  

    Drążę jeszcze temat czujników - pytanie co z czego korzysta i jakie dane obrabia?

    Jak rozumiem:
    Mając na pokładzie enkodery i znając średnicę kół jest się w stanie (zgrubnie) określić odległości (trasę?) pokonywane przez robota.
    Magnetometr daje nam orientację wobec "północy" - wobec bezwzględnego parametru.
    Akcelerometr mierzy przechyły wobec osi pionowej i przyśpieszenia w trakcie jazdy.
    Żyroskop to znowu przechyły kadłuba pojazdu (chyba, że kinecta).
    Czujniki IR to pomiar odległości (obecności) wobec ew. przeszkody.

    Które z tych danych wykorzystujesz tylko do napędu, które trafiają do ROS'a, czy używasz ich do wspomagania (korekcji) danych 3D z kinect'a?
    Jak dużo tych informacji wciąga/wspiera/przygotowuje/zwraca sam ROS jako platforma?

    Co do gubienia się robota w mapie:
    Czy słyszałeś o odometrii - używaniu dwu kamer wideo, która zamieniła się ostatnio w Project Tango?
    Jej pomysłodawca zaczynał od używania kamery IR z WiiMote.
    Jest jeszcze system North Star używany w robotach mopujących Mint i Braava.

  • #8 01 Kwi 2017 23:01
    themin
    Poziom 10  

    Jeżeli chodzi o czujniki i o to, gdzie, jakie dane są przetwarzane, najłatwiej można to prześledzić na schemacie:
    Czterokołowy robot mobilny z systemem autonomicznej nawigacji w środowisku ROS

    W skrócie, dane z enkoderów pozwalają wyznaczyć zgrubnie położenie i orientację robota. Tylko tutaj dokładność jest znacznie mniejsza niż w większości dwukołowych robotów. Przy konstrukcji czterokołowej, każde skręcanie robota powoduje poślizgi i przy prostym algorytmie odometrii pojawiają się znaczne błędy położenia jak i orientacji. Ponieważ odometria jest metodą przyrostową, pojawiające się błędy stale rosną i nie można jej używać w dłuższym przedziale czasu. Tak, czy inaczej uzyskane dane (przeliczone w sterowniku napędów) trafiają do ROS'a.

    Akcelerometr, żyroskop oraz magnetometr wykorzystywane są do wyznaczenia orientacji robota. W zasadzie można wykorzystać sam akcelerometr i żyroskop, ale magnetometr pozwala uzyskać jakiś zewnętrzny punkt odniesienia. Dzięki temu, błędy orientacji nie rosną w nieskończoność. Ale trzeba uważać na zakłócenia magnetometru, czy to przez wewnętrzne elementy robota, czy metalowe elementy znajdujące się w otoczeniu. Dane z tych czujników przetwarzane są wstępnie w module sensorów (tak na prawdę powinno być IMU) i trafiają do ROS'a.

    Później wykorzystuję filtr Kalmana do fuzji danych z odometrii oraz IMU i otrzymuję w miarę dokładną informację o względnym przemieszczeniu robota. Jednak błędy tej informacji nadal narastają, więc jest ona przydatna tylko chwilowo. Dlatego też tak ważne jest korygowanie co jakiś czas położenia i orientacji robota względem jakiegoś zewnętrznego układu odniesienia. Problem ten rozwiązałem przez wcześniejsze utworzenie mapy otoczenia. Robot, gdy się porusza dopasowuje swój odczyt z czujnika głębi (z Kinecta) do mapy i w ten sposób określa swoje położenie w otoczeniu.

    Pytałeś jeszcze o wsparcie dla różnych informacji przez platformę ROS, więc to wsparcie jest całkiem dobre. Mowa tutaj o standardowych typach wiadomości służących do przesyłania danych z czujników.
    Pełna lista wiadomości do czujników i nawigacji jest na stronie ROSa. Można tam też znaleźć wiele gotowych algorytmów do przetwarzania danych.

    Jeżeli chodzi o projekt Tango, to tak naprawdę używają tam nie tylko kamery wizyjnej (szerokokątnej), ale też kamery głębi (promiennik i odbiornik IR), czyli w efekcie uzyskiwane są niemal takie same informacje jak w przypadku Kinecta. Wydaje mi się natomiast, że najciekawsze w tym projekcie to miniaturyzacja kamery głębi i być może efektywny algorytm lokalizacji i mapowania (SLAM).

    Ogólnie, informację o przemieszczeniu można wyciągnąć nawet z jednej kamery wizyjnej. Wykrywa się wtedy cechy obrazu i oblicza przesunięcie tych cech w kolejnych klatkach obrazu. Konkretne metody można wyszukać np. pod pojęciami: Visual Odometry, MonoSLAM, VisualSLAM. Zresztą podobna idea wykorzystywana jest w myszach optycznych.

  • #9 09 Kwi 2017 23:40
    ucy74
    Poziom 20  

    themin napisał:
    [Napędy wszystkich kół są niezależne. Aktualnie jednak, koła są elektronicznie synchronizowane stronami, czyli w efekcie działa to tak jak w przypadku czołgu.
    Przy takiej konstrukcji napędu - nie myślałeś o kołach omniwheel, czy mecanum?

  • #10 12 Kwi 2017 11:09
    themin
    Poziom 10  

    Myślałem o tym, jednak takie koła nie są najlepszym wyborem do jazdy po nierównym terenie. Druga kwestia to spory koszt w przypadku dobrej jakości elementów. Oczywiście nic nie stoi na przeszkodzie, aby podmienić koła w przyszłości.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME