Robot mobilny z systemem autonomicznej nawigacji w środowisku ROS

Maj 7, 2016
Wysłane przez Michał Drwięga

 

Przedstawiony robot mobilny został wyposażony w system autonomicznej nawigacji działający w środowisku ROS i wykorzystujący sensor Microsoft Kinect. 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. Robot został zaprezentowany na poniższych zdjęciach i wizualizacji.

robot_img1m

robot_vis2_min

robot3_v2min
Pierwszą wersję robota, czyli platformę mobilną bez dodatkowego komputera i sensora Kinect przedstawiono już wcześniej, w niniejszym 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.

robot_interior

 

Dla potrzeb systemu autonomicznej nawigacji platforma została rozbudowana o dodatkowy (tymczasowy) komputer (notebook z procesorem Intel Core i3 i pamięcią RAM równą 4GB), a~także sensor Microsoft 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.

tacbot_hardware_architecture

 

Architektura systemu sterowania wysokiego poziomu

 

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, co oznacza że działania systemu muszą być zdeterminowane w czasie. Spełnienie takich wymagań zrealizowano przez implementację algorytmów na mikrokontrolerze Kinetis. Konkretne rozwiązania dotyczące sterowania niskiego poziomu zostały opisane w poprzednim wpisie. 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.

tacbot_architecture_control

 

Warstwa sterowania wysokiego poziomu zrealizowana została w środowisku ROS w wersji Hydro. Zaletą tego środowiska jest zapewnienie mechanizmów komunikacji dla tworzonego oprogramowania umożliwiających uruchamianie komponentów na wielu maszynach jednocześnie, praktycznie bez żadnych 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 12.04 x64 LTS. Poszczególne komponenty systemu sterowania wysokiego poziomu zrealizowane zostały w postaci węzłów (ang. node) uruchamianych w środowisku ROS. Węzły komunikują się ze sobą za pomocą mechanizmu zwanego tematami (ang. topics). Można wyróżnić następujące komponenty, wchodzące w skład systemu:

  • PS3 Pad teleoperation
  • Keyboard teleoperation
  • Velocities filter
  • Velocities multiplexer
  • User application with rviz
  • Localization filter
  • Hardware driver
  • Kinect Openni
  • Navigation
  • Laser scan from Kinect

 

W dalszej części umieszczono opisy poszczególnych elementów systemu.

 

PS3 Pad teleoperation

Komponent pozwala manualnie kontrolować ruch platformy mobilnej za pomocą kontrolera Sony DualShock 3. W zależności od wciśniętego przycisku zabezpieczającego typu deadman, aktywuje się jeden z trzech trybów sterowania.

 

Keyboard teleoperation

Komponent umożliwia kontrolowanie ruchu platformy za pomocą klawiatury. W zależności od wciśniętych przycisków generuje on sygnały sterujące dla kolejnych komponentów.

Moduł ten został zrealizowany w postaci skryptu napisanego w języku Python. Definiowanie przycisków odpowiedzialnych za konkretny ruch wykonuje się z poziomu skryptu.

 

Velocities multiplexer

Zastosowany multiplekser prędkości jest odpowiednio skonfigurowanym, standardowym komponentem systemu ROS. Umożliwia on zmianę źródła sterowania robota, przez wybór odpowiedniego tematu wejściowego jako tematu wyjściowego. Zmiana sterowania realizowana jest za pomocą mechanizmu usług (ang. services), będącego częścią środowiska ROS. W celu przełączenia źródła z poziomu linii komend, można wykorzystać poniższe polecenie, którego ostatnia część jest nazwą tematu, który zostanie podłączony do wyjścia.

rosservice call mux_cmd_vel/select pad_cmd_vel

 

Velocities filter

Komponent zapewnia filtrację prędkości podawanych na niskopoziomowy sterownik silników robota. Docelowe wartości sterowań modyfikowane są w taki sposób, aby ograniczone były przyspieszenia oraz maksymalne wartości prędkości robota.

 

Hardware driver

Komponent w postaci dedykowanego sterownika podzespołów robota, został zaimplementowany przez autora na potrzeby niniejszej pracy. Jego zadaniem jest pobieranie danych ze sprzętowego modułu sensorów i modułu silników, a także publikowanie ich w postaci odpowiedniej dla środowiska ROS. 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 w języku C, służąca do obsługi niektórych funkcji procesora Broadcom BCM 2835, w który wyposażony został komputer Raspberry Pi.

 

User application with rviz

Oprogramowanie pozwalające użytkownikowi obsługiwać robota. Komponent wykorzystuje narzędzie ROS’a do wizualizacji — rviz. Umożliwia to między innymi wyświetlanie map, zadawanie celów dla autonomicznej nawigacji, czy wizualizowanie odczytów z sensorów robota. Dodatkowo z poziomu programu można wyświetlić obraz z kamery.

 

Localization filter

W celu poprawy wyników lokalizacji względnej uzyskiwanych na podstawie pomiarów obrotów kół, zrealizowano fuzję danych z odometrii i inercyjnej jednostki pomiarowej (IMU). Komponent należy do pakietu robot_localization dostępnego w standardowym repozytorium ROS’a. Wykorzystuje on algorytm UKF (Unscented Kalman Filter).

 

Kinect Openni

Sterownik OpenNI  w postaci standardowego pakietu, pobierający z sensora Kinect dane takie, jak: obraz z kamery RGB lub kamery IR (podczerwieni), czy mapa głębi. Pobrane dane publikowane są w postaci tematów ROS’a.

 

Laser scan from Kinect

Oprogramowanie konwertuje mapę głębi otrzymywaną z sensora Kinect do postaci wiadomości sensor_msgs/LaserScanDodatkowo, umożliwia usuwanie podłoża z wynikowych danych oraz kompensację kąta pochylenia sensora. Komponent 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 przedstawiono wycinki interfejsu graficznego wizualizującego robota i tworzoną mapę, a także utworzoną mapę pomieszczenia.

4wd_map_p14wd_map_p2209_kinect

 

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.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

  • Polski
  • English