POLITECHNIKA WARSZAWSKA Wydział Elektroniki i Technik Informacyjnych Instytut Systemów Elektronicznych
Maciej Gąbka
Kamil Muszyński
nr albumu: 198404
nr albumu: 198429
Praca dyplomowa inżynierska
Środowisko symulacyjne i algorytm unikania kolizji robota mobilnego grającego w piłkę nożną
Praca wykonana pod kierunkiem dr. hab. Jarosława Arabasa
Warszawa 2008
Tytuł: Środowisko symulacyjne i algorytm unikania kolizji robota mobilnego grającego w piłkę nożną Celem pracy było opracowanie środowiska do symulacji Ligi RoboCup umożliwiającego testowanie algorytmów sterujących drużyną robotów. Drugim zadaniem była implementacja oraz przetestowanie pod kątem użyteczności w rozgrywkach wybranego algorytmu unikania kolizji. Do realizacji środowiska wybrano symulator Gazebo, pokazano jego podstawowe cechy oraz możliwości. Zaprezentowano i opisano wykonane modele. W kolejnych rozdziałach skupiono się na algorytmach unikania kolizji, ze szczególnym uwzględnieniem tych, które są wykorzystywane w dynamicznym środowisku. Dokonano przeglądu dostępnych metod. Do zastosowania wybrano metodę krzywizn i prędkości (Curvature Velocity Method, CVM ), opisano jej sposób implementacji. Nastepnie wykonano szereg eksperymentów i modyfikacji tak, aby przystosować metodę do działań w dynamicznym środowisku Ligi RoboCup.
Title: Simulation environment and collision avoidance algorithm for football playing mobile robot The aim of this thesis was to develop simulation environment capable of modelling RoboCup League. Second goal was to implement a collision avoidance algorithm and to use the simulation environment to test it in the RoboCup match. The Gazebo simulator, with it’s basic features described, was chosen to design RoboCup environment. After that, the created models (ball, field and robots) were presented. Furthermore, the survey of collision avoidance methods was made. For this thesis purposes, Curvature Velocity Method (CVM) was selected as the solution to be implemented. Afther that, a set of tests and modifications were made to increase method’s performance in the dynamic RoboCup League environment.
1
Spis treści 1 Wstęp (Maciej Gąbka, Kamil Muszyński ) 1.1
Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Liga RoboCup (Maciej Gąbka)
5 6 7
2.1
Geneza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Podział na ligi robotów . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3
Specyfika ligi Small-size (F180) . . . . . . . . . . . . . . . . . . . . . 12 2.3.1
Zasady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2
Schemat komunikacji . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3
Budowa robota . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Założenia projektowe (Maciej Gąbka)
17
3.1
Projekt Robcup na WEiTI . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2
Uzasadnienie sposobu realizacji . . . . . . . . . . . . . . . . . . . . . 18
3.3
Założenia dotyczące aplikacji sterującej
. . . . . . . . . . . . . . . . 19
4 Player/Stage/Gazebo (Kamil Muszyński )
21
4.1
Koncepcja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2
Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3
4.2.1
Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.2
Gazebo
4.2.3
Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.4
Wybrane rozwiązanie . . . . . . . . . . . . . . . . . . . . . . . 26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Modelowanie obiektów w Gazebo . . . . . . . . . . . . . . . . . . . . 27 4.3.1
Przykładowy model (Gazebo do v.0.7) . . . . . . . . . . . . . 27
4.3.2
Zasady modelowania w Gazebo 0.8 . . . . . . . . . . . . . . . 30
2
Spis treści
4.3.3
Realizacja środowiska Ligi RoboCup . . . . . . . . . . . . . . 34
5 Koncepcja aplikacji sterującej drużyną robotów (Kamil Muszyński )
36
5.1
Zawodnik jako agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2
Sterowanie agentami . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3
Opis rozwiązania docelowego . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.1
Unikanie kolizji przez robota . . . . . . . . . . . . . . . . . . . 40
5.3.2
Planowanie gry drużyny robotów . . . . . . . . . . . . . . . . 40
6 Aplikacja sterująca robotem (Kamil Muszyński )
43
6.1
Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2
Podstawowa funkcjonalność . . . . . . . . . . . . . . . . . . . . . . . 44
6.3
Przykład zastosowania . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4
Aplikacja testowa CVM . . . . . . . . . . . . . . . . . . . . . . . . . 46
7 Algorytmy unikania kolizji (Maciej Gąbka) 7.1
48
Przegląd algorytmów unikania kolizji . . . . . . . . . . . . . . . . . . 49 7.1.1
Algorytm Bug . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1.2
Algorytm VFH . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1.3
Technika dynamicznego okna . . . . . . . . . . . . . . . . . . 54
7.1.4
Metoda ewolucyjna . . . . . . . . . . . . . . . . . . . . . . . . 55
7.1.5
Metoda CVM . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2
Uzasadnienie wyboru metody CVM . . . . . . . . . . . . . . . . . . . 58
7.3
Zasada działania CVM
. . . . . . . . . . . . . . . . . . . . . . . . . 59
8 Implementacja oraz testy algorytmu CVM (Maciej Gąbka)
66
8.1
Szczegóły implementacji . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.2
Testowanie podstawowej wersji algorytmu
. . . . . . . . . . . . . . . 68
8.2.1
Plan eksperymentów . . . . . . . . . . . . . . . . . . . . . . . 70
8.2.2
Wyniki eksperymentów . . . . . . . . . . . . . . . . . . . . . . 71
9 Modyfikacje algorytmu CVM (Kamil Muszyński )
77
9.1
Omówienie zmodyfikowanej wersji algorytmu (1) . . . . . . . . . . . . 77
9.2
Omówienie zmodyfikowanej wersji algorytmu (2) . . . . . . . . . . . . 81
3
Spis treści
10 Eksperyment w środowisku dynamicznym (Maciej Gąbka)
89
11 Podsumowanie (Maciej Gąbka, Kamil Muszyński )
93
A Zawartość płyty CD (Maciej Gąbka)
95
B Instrukcja instalacji Gazebo (Kamil Muszyński )
96
C Wyznaczenie promieni okręgów stycznych w CVM (Maciej Gąbka)
97
D Szczegóły eksperymentów (Kamil Muszyński )
4
100
Rozdział 1 Wstęp Maciej Gąbka, Kamil Muszyński ˘ Termin robot został po raz pierwszy użyty w sztuce czeskiego pisarza Karela Capka. Słowo to określało maszynę-niewolnika zastępującą człowieka w najbardziej uciążliwych zajęciach. Semantyka tego wyrazu doskonale wyraża motywację, którą kieruje się człowiek tworząc roboty. Dlatego w drugiej połowie XX wieku, kiedy technologia elektroniczna oferowała coraz większe możliwości, robotyka jako dziedzina nauki i techniki zaczęła się gwałtownie rozwijać. Początkowo konstruowano roboty do zastosowań przemysłowych. Były to manipulatory, czyli mechaniczne ramiona o kilku stopniach swobody, na których zamontowane były odpowiednie narzędzia. Pierwszy manipulator został wykorzystany w przemyśle samochodowym w 1961 roku przez firmę General Motors. Wraz z rozwojem techniki zaczęto myśleć o wprowadzeniu robotów do codziennego życia przeciętnego człowieka. Koncepcja robotów usługowych zakłada, że będą one wyręczać ludzi z konieczności wykonywania żmudnych czynności, takich jak sprzątanie czy też koszenie trawników. Współczesne roboty usługowe mogą nawet pełnić funkcje przewodników po muzeach. Nie wyczerpuje to oczywiście wszystkich zastosowań robotów, które coraz częściej wykorzystywane są w medycynie, wojskowości oraz ratownictwie. Innowacyjne rozwiązania stwarzają jednak potrzebę opracowania wymagającego środowiska testowego. W przypadku robotów mobilnych gra w piłkę nożną może za takie posłużyć. Podobnie jak w przypadku ludzi zawodnik w takiej grze powinien charakteryzować się dużą zwrotnością i szybkością. Ponadto powinien sprawnie reagować na zmiany sytuacji na boisku, szybko podejmować decyzje oraz (ponieważ 5
Rozdział 1. Wstęp
jest to gra zespołowa) współpracować z pozostałymi zawodnikami. Z takiego założenia wyszli twórcy RoboCup, czyli rozgrywek robotów w piłkę nożną. Liga jest traktowana jako pole testowe dla konstrukcji mechanicznych oraz algorytmów sterowania. W ostatnich latach stworzono także osobne przedsięwzięcie o nazwie RoboCup Rescue, mające na celu testowanie robotów pod kątem użyteczności w ratownictwie podczas sytuacji kryzysowych. Liga RoboCup budzi zainteresowanie wielu ludzi na całym świecie, także liczne środowiska akademickie prowadzą prace z nią związane. Pomimo że na Politechnice Warszawskiej nie istnieje jeszcze w pełni funkcjonalna drużyna robotów, testowane są już algorytmy sterowania pojedynczym zawodnikiem. Jednym z podstawowych problemów, na który napotyka się przy sterowaniu robotem mobilnym, jest bezkolizyjna nawigacja w dynamicznie zmieniającym się środowisku. To właśnie ten problem należy rozwiązać przed przystąpieniem do kolejnych, bardziej zaawansowanych prac.
1.1
Cel pracy
Celem niniejszej pracy było stworzenie kompletnego środowiska symulacyjnego, pozwalającego na modelowanie robotów grających w piłkę nożną i dającego w przyszłości możliwość testowania różnorodnych rozwiązań sterowania drużyną. Ponadto za zadanie przyjęto zaimplementowanie algorytmu unikania kolizji, który pozwalałby zawodnikowi sprawnie poruszać się w dynamicznym środowisku, jakim jest rozgrywka RoboCup. Tworząc modele robotów postawiono sobie za cel ich kompatybilność z robotami HMT rozwijanymi aktualnie przez studenckie Koło Naukowe Robotyki Bionik1 (funkcjonujące przy Zespole Programowania Robotów i Systemów Rozpoznających na Wydziale Elektroniki i Technik Informacyjnych). Autorzy mają nadzieję, ze ich praca w przyszłości przyczyni się do rozwoju działań związanych z rozgrywkami robotów w piłkę nożną na naszym Wydziale, a także okaże się przydatna innym osobom zajmującym się zagadnieniami związanymi z robotyką.
1
http://bionik.ia.pw.edu.pl
6
Rozdział 2 Liga RoboCup Maciej Gąbka
Współzawodnictwo od zarania dziejów pociągało ludzi. Z jednej strony było źródłem interesujących widowisk, z drugiej zaś motywowało ludzi do postępu. Postępu rozumianego jako praca nad sobą samym ale także w wymiarze technologicznym. Liga RoboCup połączyła oba te aspekty rywalizacji, sprawiła, że piłka nożna, sport, którym pasjonują się miliony ludzi na całym świecie, stała się polem do testowania najnowszych osiągnięć technologicznych. Wybranie tak popularnego sportu miało na celu wypromowanie robotyki jako dziedziny wiedzy, umożliwiając także promocję wszystkich nauk, bez których robotyka nie jest w stanie funkcjonować. Głównym celem przedsięwzięcia jest stworzenie do 2050 roku drużyny w pełni autonomicznych robotów humanoidalnych zdolnych wygrać rozgrywkę z aktualnymi mistrzami świata. Aby osiągnąć zamierzony cel należy połączyć osiągnięcia z różnych dziedzin nauki. Przede wszystkim ważna jest konstrukcja zarówno mechaniczna jak i elektroniczna robota. Zawodnik powinien być wyposażony w odpowiedni zestaw czujników umożliwiających osiągnięcie pełnej autonomiczności. Z drugiej strony natomiast należy dysponować funkcjonalnym oprogramowaniem umożliwiającym współpracę wielu robotów. Szczegółowy opis przedsięwzięcia można znaleźć w [1].
2.1
Geneza
Pierwsze eksperymenty z udziałem robotów mobilnych koordynowanych za pomocą globalnego systemu wizyjnego miały miejsce na początku lat 90-tych XX wieku. 7
Rozdział 2. Liga RoboCup
W swoim artykule [2] Alan K. Mackworth z University of British Columbia opisał projekt Dynamo (Dynamics and Mobile Robots), którego celem było stworzenie dwóch drużyn robotów współpracujących, ale także i rywalizujących miedzy sobą. Początkowo informacja o położeniu robotów pochodziła z kamery umieszczonej nad planszą, w trakcie rozwoju prac planowano wyposażyć poszczególne roboty w czujniki wizyjne. Takie środowisko miało za zadanie umożliwić testowanie nowych algorytmów sterowania robotami. Jednoczenie na jednej z konferencji poświęconych sztucznej inteligencji zorganizowanej przez japońskich naukowców dyskutowano nad sposobem wykorzystania gry w piłkę nożną do promocji nowych technologii. Dyskusja przyniosła efekt w postaci spisanych podstawowych zasad, jakimi miałby być regulowany taki projekt oraz prototypu robotów-zawodników, a także i symulatora. W 1993 roku powstała inicjatywa pod nazwą J-League, w której uczestniczyli jedynie Japończycy. W krótkim czasie zainteresowanie przedsięwzięciem wykazały ośrodki naukowe z całego świata i zadecydowano o zmianie jego charakteru, decyzja ta zaowocowała zmianą nazwy na Robot World Cup Initiative, w skrócie RoboCup. We wrześniu 1993 roku sformułowano oficjalne zasady i ustalono podział na ligi. W tym samym czasie niezależnie od siebie realizowane były projekty z dziedziny robotyki, w których jako pole testowe wybrano grę w piłkę nożną. Takim przykładem mogą być badania prowadzone w japońskich ETL (ElectroTechnical Laboratory). Rozpoczęto tam prace nad symulatorem przeznaczonym do gry piłkę nożną. Z czasem został on uznany jako oficjalny symulator RoboCup. W roku 1996 w Osace na konferencji poświęconej inteligentnym systemom robotycznym zorganizowano pierwszy oficjalny pokaz. Zademonstrowano możliwości robotów mobilnych z ligi Middle-size oraz zorganizowano rozgrywki w lidze symulacyjnej. Pierwsze oficjalne zawody miały miejsce w 1997 roku w Nagoji. Do udziału zgłoszono ponad 40 drużyn z różnych krajów. Wydarzenie cieszyło się znacznym zainteresowaniem, liczbę widzów oszacowano na 5 tysięcy. Tegoroczne rozgrywki odbyły się w Chinach, wzięły w nich udział 373 drużyny z 35 krajów.
2.2
Podział na ligi robotów
W poprzedniej części wspomniano, iż RoboCup składa się z kilku lig, w zależności od konstrukcji oraz możliwości robotów. Aktualnie wyróżnione zostały nastepujące 8
Rozdział 2. Liga RoboCup
ligi: • liga symulacyjna • Small-size League • Middle-size League • Standard Platform League • Humanoid League Liga symulacyjna jest najstarszą z lig, towarzyszy ona przedsięwzięciu od samego początku jego istnienia. Zachowanie robotów jest symulowane za pomocą programu zwanego Robocup Soccer Simulator. Składa się on z dwóch osobnych aplikacji Robocup Soccer Server – symulującej zachowanie robotów oraz Robocup Soccer Monitor – odpowiedzialnej za wizualizację rozgrywek. Początkowo symulator umożliwiał modelowanie zachowań piłki oraz robotów w dwóch wymiarach, chociaż rozgrywka mogła być wyświetlana w dwóch trybach, zarówno w 2D jak i 3D. Obecnie dostępne są dwie wersje symulatora: podstawowa (dwuwymiarowa) oraz trójwymiarowa. Wymagane jest, aby każdy zawodnik sterowany był poprzez osobną aplikację kliencką. Robocup Soccer Server posiada także zaimplementowany moduł sędziego, który decyduje o klasyfikowaniu prostych sytuacji podczas rozgrywki (między innymi zdobyta bramka, aut). Jednakże konieczne jest także, aby funkcję sędziego pełnił człowiek, ponieważ w pewnych sytuacjach interpretacja zachowania zawodników zależy od ich intencji. Przykładem takiej sytuacji może być zasłonięcie własnej bramki przez wiele robotów, czy oddanie piłki drużynie przeciwnej w myśl zasad fair play. Symulowana rozgrywka ma miejsce na typowym boisku piłkarskim według standardów FIFA, czyli długość boiska zawiera się pomiędzy 100 [m] a 110 [m], natomiast szerokość pomiędzy 64 [m] a 75 [m]. Symulator może obsłużyć maksymalnie po jedenastu graczy dla każdej drużyny. Serwer udostępnia aplikacji sterującej agentem-zawodnikiem tylko część informacji, zależy ona od wskazań sensorów robota. Dostępne są trzy typy sensorów: • wizyjny – umożliwiający dostęp do informacji o położeniu zawodników oraz piłki, • słuchowy – umożliwiający komunikację z pozostałymi zawodnikami, 9
Rozdział 2. Liga RoboCup
• body receptor – określający stan wewnętrzny samego zawodnika. Ponadto dostępne są dwa osobne typy aplikacji klienckich: coach oraz online trainer. Trainer może być używany jedynie podczas treningów (funkcja ta może być z powodzeniem stosowana w przypadku algorytmów wykorzystujących maszynowe uczenie się), podczas rozgrywki nie można podłączyć takiej aplikacji do serwera. Natomiast coach jest wykorzystywany podczas meczu do obserwacji poczynań drużyny i udzielania wskazówek lub korekt. Jednak istnieją zabezpieczenia, aby aplikacja o charakterze coach nie mogła całkowicie sterować wszystkimi agentami. Kolejną z lig jest Small-Size League. W rozgrywkach tej ligi drużyna składa się maksymalnie z pięciu niewielkich robotów, takich jak widoczne na fotografii 2.1. Roboty nie są jednak w pełni autonomiczne, ponieważ nie posiadają własnych sensorów. Algorytm sterujący czerpie informację o położeniu piłki oraz robotów z kamery umieszczonej centralnie nad boiskiem. Lidze tej został poświęcony w całości paragraf 2.3.
Rysunek 2.1: Roboty biorące udział w Small-Size League (źródło: www.robocup.org) Middle-size League to liga już w pełni autonomicznych robotów. W odróżnieniu od wcześniej omawianej ligi małych robotów, globalny system wizyjny jest całkowicie zakazany. Każdy robot jest wyposażony w osobny zestaw czujników wizyjnych. Dozwolone są wszystkie rodzaje czujników, które nie łamią dwóch poniższych zasad: 1. wszystkie części systemu wizyjnego muszą być zamontowane na robocie, 2. system nie powinien ingerować w środowisko rozgrywki (np. umieszczać znaczniki). W celu umożliwienia rozróżniania robotów między sobą zostały one wyposażone w znaczniki określone w regulaminie. Regulamin ligi nie zawiera także szczegółowych 10
Rozdział 2. Liga RoboCup
Rysunek 2.2: Rozgrywki Middle-size League (źródło: www.robocup.org) wytycznych dotyczących konstrukcji mechanicznej robota, określone są jedynie dopuszczalne minimalne i maksymalne wymiary: • rzut robota na powierzchnię boiska powinien zmieścić się w kwadracie o boku 50 [cm] oraz powinien być większy od kwadratu o boku 30 [cm] • wysokość powinna zawierać się między 40 [cm] a 80 [cm] Jest to liga, w której drużyny są najbardziej liczne – każda może zawierać do 11 graczy. Od 2007 roku istnieje nowa liga Standard Platform League, która powstała z istniejącej we wcześniejszych latach ligi piesków Aibo (fotografia 2.3a). Założeniem ligi jest koncentrowanie się jedynie na opracowywaniu nowych rozwiązań algorytmicznych, stąd wszystkie drużyny korzystają z tych samych konstrukcji mechanicznych Jakiekolwiek dodatkowe modyfikacje oryginalnych robotów są (a) Sony Aibo
zabronione. W tym roku wiodącym modelem robota wykorzystywanym w tej
(b) Nao
Rysunek 2.3: Roboty wykorzystywane
lidze stał się Nao (fotografia 2.3b) fir-
w Standard Platform League
my Aldebaran Robotics. Drużyna może
(źródło: www.robocup.org)
składać się maksymalnie z trzech zawodników (wliczając bramkarza). Ostatnią z lig, o której należy wspomnieć, jest liga robotów humanoidalnych. Roboty biorące udział w rozgrywkach tej ligi swoim kształtem z założenia powinny 11
Rozdział 2. Liga RoboCup
Rysunek 2.4: Roboty humanoidalne (źródło: www.robocup.org) przypominać ludzi, czyli posiadać korpus, nogi, ręce oraz głowę. Przykładowy zawodnik został zaprezentowany na fotografii 2.4. Nie ma sprecyzowanych wymagań dotyczących konstrukcji robotów, w lidze mogą uczestniczyć różne modele. Jedynym ograniczeniem są ich wymiary oraz rozmieszczenie sensorów (musi być analogiczne jak u człowieka, np. sensor wizyjny nie może być umieszczony w nodze lub ręce). Ponadto, ze względu na wysokość robota, wyróżniony został podział na dwie klasy: • KidSize – wysokość zawodnika należy do przedziału od 30 [cm] do 60 [cm], • TeenSize – wysokość zawodnika należy do przedziału od 60 [cm] do 130 [cm]. W rozgrywce biorą udział dwa roboty, przy czym jeden z nich może zostać oddelegowany do pełnienia funkcji bramkarza.
2.3
Specyfika ligi Small-size (F180)
Spośród omówionych w poprzednim rozdziale lig wykorzystujących rzeczywiste roboty najprostszą w realizacji jest liga małych robotów. Dlatego też próbę jej stworzenia podjęto w Instytucie Automatyki i Informatyki Stosowanej (szerszy opis zamieszczono w rozdziale 3). Zadecydowały o tym następujące względy: • dość prosta konstrukcja mechaniczna oraz elektroniczna robota; wynika to z faktu, iż robot nie musi być w pełni autonomiczny, • możliwość zastosowania scentralizowanego algorytmu sterowania drużyną dzięki posiadaniu informacji o położeniu wszystkich zawodników oraz piłki, 12
Rozdział 2. Liga RoboCup
• małe wymiary boiska.
2.3.1
Zasady
Zbiór zasad obowiązujący w lidze podlega co roku aktualizacji przez komitet techniczny ligi. Zazwyczaj około rok przed kolejnymi mistrzostwami znane są zasady na nich obowiązujące. Początkowo w rozgrywkach wszystkie roboty korzystały z globalnego systemu wizyjnego, jednak w trakcie kolejnych zmian w przepisach dopuszczono do rozgrywek roboty z własnym systemem wizyjnym, dzięki czemu zaczęto wykorzystywać także rozproszone algorytmy sterowania. W rozgrywce na boisku o wymiarach 6.1 [m] na 4.2 [m] wyłożonej zielonym dywanem lub wykładziną biorą udział dwie drużyny składające się z maksymalnie pięciu robotów. Jeden z robotów może zostać oddelegowany do pełnienia funkcji bramkarza, jednak powinno to zostać zgłoszone przed rozpoczęciem meczu. Konstrukcja robota powinna zmieścić się w walcu o średnicy 18 [cm] oraz wysokości 15 [cm]. W przypadku robotów z własnymi sensorami wizyjnymi dopuszcza się wysokość do 22.5 [cm]. Robot może być wyposażony w urządzenie do prowadzenia piłki, jednak istnieją pewne ograniczenia dotyczące jego budowy oraz stosowania w czasie gry. Mianowicie robot może prowadzić piłkę maksymalnie przez dystans 50 [cm], po przejechaniu którego powinien albo podać ją innemu zawodnikowi, albo kopnąć przed siebie i dalej ją prowadzić. W przeciwnym wypadku sygnalizowane jest przewinienie. Natomiast konstrukcja urządzenia do dryblowania nie może uniemożliwiać kontaktu z piłką zawodnikowi z przeciwnej drużyny. Rozgrywka jest całkowicie kontrolowana przez arbitra, który czuwa nad tym, aby regulamin był przestrzegany. Do jego zadań należy sygnalizowanie przewinień, zdobytych bramek oraz innych typowych sytuacji na boisku. Sędzia ma prawo zmienić swoją decyzje po konsultacjach z asystentem. Postanowienia arbitra są tłumaczone na sygnały elektryczne przez asystenta i wysyłane do wszystkich zawodników.
2.3.2
Schemat komunikacji
Jedną z najistotniejszych spraw podczas rozgrywki jest dostęp do informacji o położeniu piłki i pozostałych robotów. Aby rozwiązać ten problem drużyny uczestniczące w rozgrywce mogą korzystać z systemu wizyjnego widocznego na rysunku 2.5. Składa się on z kamery ustawionej centralnie nad boiskiem oraz specjalnej aplikacji 13
Rozdział 2. Liga RoboCup RoboCup VideoServer 1 . Obraz zarejestrowany przez kamerę jest przesyłany do komputera, na którym uruchomiony jest RoboCup VideoServer. Program przetwarza na bieżąco obraz z kamery i w wyniku swojego działania dostarcza informację o położeniu oraz prędkościach robotów i piłki. Dane te następnie są wykorzystywane przez rywalizujące ze sobą drużyny na potrzeby ich algorytmów sterujących zawodnikami. Algorytm sterujący jako wynik swojego działania powinien zwracać kierunek i prędkość zawodników. Ta ostateczna informacja jest wysyłana droga radiową do zawodnika. Sam program RoboCup VideoServer oferuje bardzo dużą funkcjonalność. Pozwala przykładowo dokonać dokładnej kalibracji nawet w przypadku, gdy boisko widziane przez kamerę ma kształt owalny (z powodu zniekształceń obrazu). Przed rozpoczęciem pracy z aplikacją należy zdefiniować początek układu współrzędnych oraz rozpoznawane przez serwer kolory.
Rysunek 2.5: Schemat komunikacji w Small Size League (źródło: www.robocup.org) RoboCup VideoServer może rozpoznawać nie tylko położenie poszczególnych robotów, ale także ich orientację na płaszczyźnie. Jednak do tego celu niezbędne jest zastosowanie specjalnych znaczników. Każdej z drużyn przed rozpoczęciem rozgrywki zostaje przypisana para kolorów, jakie zawiera znacznik. Dzięki zastosowaniu dwóch kolorów możliwe jest nie tylko rozróżniania robotów z różnych drużyn, ale także właśnie ich orientacji. 1
Do pobrania z http://sourceforge.net/projects/robocup-video
14
Rozdział 2. Liga RoboCup
(a)
(b)
(c)
Rysunek 2.6: Popularny model robota wykorzystywany w lidze F180 (źródło: www.robocup.org)
2.3.3
Budowa robota
W oficjalnym regulaminie ligi nie zostały narzucone konkretne modele robotów, które mogą brać udział w rozgrywkach, jednak, obserwując kolejne mistrzostwa, łatwo zauważyć, że wśród zgłaszanych drużyn dominuje jedna konstrukcja mechaniczna. Została ona zaprezentowana na rysunkach 2.6. Podczas gry w piłkę nożną często wynika potrzeba zmiany orientacji w miejscu. W prezentowanym rozwiązaniu zdecydowano się na omnikierunkową bazę jezdną. Składa się ona z trzech kół szwedzkich, w tym dwóch niezależnie napędzanych. Koło szwedzkie posiada taką zaletę, iż dodatkowo poza obrotem wokół własnej osi umożliwia obrót wokół punktu styczności koła z podłożem oraz wokół osi rolek umieszczonych na kole. Dzięki zastosowaniu takiego rozwiązania uzyskano w pełni holonomiczną budową robota. Robot biorący udział w rozgrywkach musi być zdolny do prowadzenia piłki. Zastosowana konstrukcja jest wyposażona w urządzenie do dryblowania widoczne na rysunkach 2.6a oraz 2.6c. Zbudowane jest ono z walca nadającego piłce wsteczną rotację, przez co nie odbija się ona od robota, a także nie traci on nad nią kontroli w momencie hamowania lub obracania się. W
Rysunek 2.7: Znacznik
regulaminie rozgrywek dopuszczono do stoso-
umożliwiający systemowi
wania jedynie urządzenia do dryblowania dzia-
wizyjnemu identyfikację robotów
łające na piłkę siłą prostopadłą do podłoża
15
Rozdział 2. Liga RoboCup
rys. 2.6a (we wcześniejszych latach w użyciu były urządzenia, w których obracany walec był umieszczony pionowo). Ostatnim ważnym elementem, w który musi być wyposażony robot, jest znacznik (rys. 2.7). Znajduje się on w takim miejscu, aby kamera umieszczona centralnie nad boiskiem mogła go zarejestrować (przykrywa robota od góry). Znaczniki umożliwiają systemowi wizyjnemu określenie, do której drużyny należy dany robot, a także poprawne rozpoznanie jego pozycji, orientacji oraz prędkości na boisku.
16
Rozdział 3 Założenia projektowe Maciej Gąbka
Idea rozgrywek robotów jest zagadnieniem skupiającym uwagę wielu ludzi. Także w Polsce istnieją ośrodki gromadzące ludzi zainteresowanych tą dziedziną. Na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej powstało kilka opracowań dotyczących tej tematyki, aczkolwiek nadal nie udało się stworzyć w pełni działającej drużyny robotów. Mimo to nie należy odrzucać dotychczasowego dorobku, dlatego niniejsza praca inżynierska miała jako jeden z celów dopasowanie się do istniejących rozwiązań i ich dalsze rozwijanie.
3.1
Projekt Robcup na WEiTI
W Instytucie Automatyki i Informatyki Stosowanej powstało lub jest nadal prowadzonych kilka prac dyplomowych związanych z tematyką rozgrywek robotów w piłkę nożną. Początkowo konstrukcje mechaniczne robotów były tworzone z klocków Lego Mindstorms. W ramach przeprowadzonych prac opisanych w [3] powstał algorytm planowania ruchu dla pojedynczego robota, którego docelowym zastosowaniem były rozgrywki RoboCup. W ostatnich latach powstała także pierwsza wersja bazy jezdnej o nazwie HMT1 oraz dedykowany dla niej układ sterownika [4]. W efekcie powstał robot mobilny o napędzie różnicowym komunikujący się z komputerem PC za pomocą technologii bluetooth. Przy odpowiedniej konfiguracji sterownika możliwa była także komunikacja między poszczególnymi robotami. W ramach pracy magisterskiej [5] sterownik robota został udoskonalony. Powsta17
Rozdział 3. Założenia projektowe
ła nowa konstrukcja elektroniczna, robot został dodatkowo wyposażony w enkodery optyczne, dzięki którym możliwy jest pomiar zmiany położenia kół. Docelowo planowana jest budowa nowej, lżejszej konstrukcji mechanicznej. Oprogramowanie sterujące umożliwia bezprzewodową komunikację między robotem a komputerem klasy PC. Do robota HMT2 wysyłana jest informacja o zadanych prędkościach lewego oraz prawego silnika. Robot może utrzymywać zadaną prędkość dzięki zaimplementowanemu dyskretnemu regulatorowi PID prędkości obrotowej silników. Nadal brakuje jednak gotowej bazy jezdnej, aczkolwiek istnieją już jej prototypy. Działające na WEiTI Koło Naukowe Robotyki Bionik także zaangażowało się w próbę stworzenia rozgrywek robotów. Jako ligę docelową wybrano Small-size League, ponieważ wymagania stawiane uczestniczącym w niej zawodnikom nie są wygórowane, ponadto plansza, na której odbywają się rozgrywki, jest najmniejsza spośród lig RoboCup. W ramach działalności koła powstało boisko, które jest przeskalowaną wersją realnej wersji z ligi Small-size. Tak jak w rzeczywistych rozgrywkach, nad polem gry została umieszczona kamera przekazująca obraz do serwera video.
3.2
Uzasadnienie sposobu realizacji
Jak już wspomniano we wstępie do tego rozdziału, kroki podjęte przez autorów niniejszej pracy miały na celu dopasowanie się do istniejących rozwiązań. Z faktu, iż nie dysponowano w pełni funkcjonalnym robotem, wyniknęła konieczność symulowania działania zachowania zawodnika ligi Small-size. Oficjalny symulator Ligi RoboCup opisywany w rozdziale 2 nie mógł zostać wykorzystany do modelowania rozgrywek Small-size League, ponieważ nie wspiera on centralnego sterowania drużyną. Dostęp do informacji o położeniu wszystkich robotów jest ograniczony, dlatego nawet przy symulowaniu ruchu pojedynczego zawodnika napotkano by na duże trudności. Zaimplementowany algorytm unikania kolizji nie mógłby np. niezależnie sterować zasięgiem swojego działania. Istnieją co prawda dwa typy aplikacji klienckich, które mają dostęp do globalnej informacji o położeniu robotów, jednak ich funkcjonalność jest ograniczona1 . Jako środowisko symulacyjne wybrano projekt Player/Stage/Gazebo szerzej opisany w kolejnym rozdziale. Początkowo pracę rozpoczęto z Gazebo w wersji 0.7. O jego wyborze zadecydował fakt, iż dostepne były zaimplementowa1
Mowa tutaj o aplikacjach typu coach oraz trainer przytaczanych w rozdziale 2.
18
Rozdział 3. Założenia projektowe
ne w tym środowisku modele robotów HMT1. W ramach naszej pracy inżynierskiej powstał także model boiska, odwzorowujący wymiary rzeczywistego boiska, którym dysponuje Koło Robotyki Bionik.
3.3
Założenia dotyczące aplikacji sterującej
Podczas tworzenia oprogramowania sterującego robotem położono nacisk na odwzorowanie takiego przepływu informacji, jaki pojawia się w aplikacjach sterujących drużyną ligi Small-size. Drugim założeniem była taka konstrukcja oprogramowania, aby w razie potrzeby umożliwiła ona szybkie przeniesienie symulowanego rozwiązania na rzeczywisty sprzęt (co oznacza nawiązanie współpracy z kamerą oraz robotami). Aby zrealizować przyjęte cele, stworzono przedstawioną na rys. 3.1 strukturę klas w języku C++. Źródło informacji o rozgrywce stanowi klasa Videoserver, która odbiera dane o pozycjach i prędkościach robotów oraz piłki z symulatora Gazebo. Następnie pakiet danych jest przekazywany do aplikacji kontrolującej drużynę, która podejmuje decyzje o nowych sterowaniach, jakie należy wyznaczyć podległym jej robotom. Sterowania te są zadawane poprzez wywołanie metod obiektów klasy Robot, obiekty te zaś odwołują się bezpośrednio do symulatora, ustawiając odpowiednie prędkości “silnikom” modeli robotów. W ten sposób zachowany jest schemat przepływu informacji, który został przedstawiony na rys. 2.5 (strona 14). Ponadto ewentualne przystosowanie zaimplementowanej aplikacji do rozgrywki rozgrywanej
Rysunek 3.1: Przepływ informacji w aplikacji sterującej
19
Rozdział 3. Założenia projektowe
w rzeczywistym środowisku wymaga jedynie modyfikacji części klas Robot oraz Videoserver odpowiedzialnej za komunikację ze sprzętem (klasa Videoserver powinna być w stanie odbierać dane o współrzędnych obiektów na boisku rozpoznane przez oficjalny VideoServer Ligi RoboCup, klasa Robot – przesyłać drogą radiową komendy wydawane rzeczywistym robotom) – sam algorytm sterowania może pozostać niezmieniony.
20
Rozdział 4 Player/Stage/Gazebo Kamil Muszyński
4.1
Koncepcja
Początki oprogramowania nazwanego Project Player (oznaczającego zestaw trzech aplikacji: Player, Stage oraz Gazebo) sięgają 1998 roku, kiedy to na Uniwersytecie Południowej Kaliforni w Los Angeles rozpoczęto prace nad stworzeniem oprogramowania pozwalającego na sterowanie grupą robotów mobilnych Pioneer 2 firmy ActivMedia, będących na wyposażeniu tamtejszego laboratorium robotyki. Twórcami projektu byli Brian Gerkey i Richard Vaughan, później dołaczyli do nich Kasper Støy oraz Andrew Howard. Do tego czasu w skład stworzonego oprogramowania wchodziły: Golem (pozwalający na sterowanie robotem Pioneer ) oraz Arena (symulator). W toku prac narodziła się idea opracowania uniwersalnego zestawu aplikacji, umożliwiającego kontrolę nad robotami niezależnie od zastosowanych rozwiązań sprzętowych, dobrze współpracującego z symulatorem oraz dostępnego za darmo (zgodnie z GNU GPL). Tak powstały aplikacje Player oraz Stage. Player miał za zadanie dostarczać narzędzi do sterowania podzespołami robota, a Stage stanowił prosty dwuwymiarowy symulator. Oprogramowanie to znalazło szeroko stosowane zarówno w uczelnianych laboratoriach, jak i wśród indywidualnych użytkowników. W 2002 roku rozpoczęto prace nad nowym symulatorem Gazebo, który został stworzony do modelowania zachowań robotów w trójwymiarowym świecie z uwzględnieniem oddziaływań fizycznych między obiektami. Całość projektu jest w dalszym ciągu intensywnie rozwijana przez deweloperów oraz aktywną społeczność użytkowników. Oprogramowanie działa na systemach Linux, Solaris, *BSD oraz Mac 21
Rozdział 4. Player/Stage/Gazebo
OSX. Szczegółowe informacje, dokumentacja oraz kody źródłowe dostępne są pod adresem http://playerstage.sourceforge.net/.
4.2
Architektura
Schemat zależności pomiędzy komponentami Player/Stage/Gazebo został przedstawiony na rysunku 4.1. Dobrze obrazuje on rolę programu Player, pełniącego funkcję pośrednika pomiędzy aplikacją klienta (odpowiadającą za algorytm sterowania robotem), a rzeczywistym robotem lub symulatorami modelującymi jego zachowanie (Stage oraz Gazebo). Do komunikacji pomiędzy komponentami wykorzystywany jest protokół TCP/IP. Aplikacja kliencka łączy się z “serwerem”, którego rolę pełni Player. Z punktu widzenia klienta nie ma znaczenia, czy interfejsy dostarczane przez Playera sterują robotem rzeczywistym, czy tylko jego wirtualnym odpowiednikiem (modelem) w jednym z symulatorów. Ponadto, przeniesienie kontroli pomiędzy symulowanym a rzeczywistym robotem nie wymaga (lub wymaga tylko nieznacznych) modyfikacji kodu. Istnieje jeszcze druga opcja – do każdego z symulatorów (Stage lub Gazebo) można odwoływać się bezpośrednio w przypadku, gdy korzystanie z Playera nie jest uzasadnione, lub gdy chce się dokonać pewnych modyfikacji w sposobie działania symulatora. Do tego tego celu zostały stworzone biblioteki (libstage oraz libgaze-
Rysunek 4.1: Schemat komunikacji w środowisku Player/Stage/Gazebo
22
Rozdział 4. Player/Stage/Gazebo
bo), które dostarczają funkcji służących do komunikacji między aplikacją kliencką, a symulatorami. Podsumowując, struktura pakietu oprogramowania Player/Stage/Gazebo umożliwia pisanie aplikacji sterujących robotami w sposób, który zapewnia przenośność stworzonych programów i ich działanie zarówno na symulatorach robotów, jaki i na rzeczywistych obiektach.
4.2.1
Stage
Stage został stworzony jako prosty dwuwymiarowy symulator nastawiony na modelowanie dużych skupisk robotów mobilnych. Zrezygnowano w nim ze szczegółowości modeli na rzecz ich wydajności pod względem obliczeniowym. Symulowane obiekty są reprezentowane jako prostokąty pokryte zadaną bitmapą, posiadane przez nie cechy fizyczne to tylko rozmiar, masa i prędkość – nie uwzględnia się np. tarcia, inercji, itp. Jest to jednak wystarczające przybliżenie do obserwacji reakcji robotów na zadane sterowania. Dzięki temu Stage pozwala na symulację setek robotów mobilnych na pojedynczym komputerze PC. Samo środowisko jest wysoce konfigurowalne, umożliwia szybkie tworzenie i testowane nowych aplikacji sterujących, symulację w przypadku braku dostępu do sprzętu, a nawet testy rozwiązań (np. czujników), które dopiero mają zostać wprowadzone do produkcji.
Rysunek 4.2: Stage – ilustracja działania (zrzut ekranu)
23
Rozdział 4. Player/Stage/Gazebo
4.2.2
Gazebo
Program Gazebo, podobnie jak Stage, umożliwia symulację grup robotów mobilnych. Różnica polega na tym, że symulowane środowisko jest trójwymiarowe, uwzględnia dynamikę, cechy fizyczne oraz oddziaływania między modelami. Wiąże się to oczywiście ze wzrostem potrzebnej mocy obliczeniowej, dlatego też symulowane grupy robotów nie mogą być tak liczne, jak w przypadku Stage. Gazebo zostało oparte na nastepujących komponentach: • ODE1 , bibliotece odpowiadającej za symulację cech fizycznych brył oraz detekcję kolizji, • OGRE2 , silniku graficznym umożliwiającym tworzenie wspomaganej sprzętowo grafiki 3D, • FLTK3 , bibliotece dostarczającej przenośny interfejs użytkownika dla Gazebo, • libXML24 , parserze XML (stworzonym oryginalnie dla środowiska graficznego GNOME), umożliwiającym Gazebo proste wczytywanie plików konfiguracyjnych. Gazebo pozwala na symulację standardowych sensorów (m.in. czujniki odległości, kamery, GPS). Dostarcza gotowe modele popularnych robotów (jak np. Pioneer2DX, Pioneer 2AT oraz SegwayRMP ). Pozwala ponadto na tworzenie własnych modeli i definiowanie ich własności fizycznych (takich jak np. masa, współczynnik tarcia, sztywność), co zapewnia odpowiedni realizm symulacji i pozwala na interakcję z innymi obiektami (podnoszenie, przesuwanie brył itp.). Co więcej, dla każdego z modeli dostępne są kontrolery pozwalające na ich sterowanie, ale nic nie stoi na przeszkodzie, żeby zdefiniować własne według potrzeb i dodać je do Gazebo.
4.2.3
Player
Player jest serwerem sieciowym dostarczającym interfejs do kontroli nad sensorami i efektorami, w które wyposażony jest robot, za pośrednictwem protokołu TCP/IP. 1
Open Dynamics Engine, http://www.ode.org Object-Oriented Graphics Rendering Engine, http://www.ogre3d.org/ 3 Fast Light Toolkit, http://www.fltk.org/ 4 http://xmlsoft.org/ 2
24
Rozdział 4. Player/Stage/Gazebo
Rysunek 4.3: Gazebo – okno główne (wersja 0.8) Jak już wspomniano, został zaprojektowany do obsługi robotów z rodziny Pioneer 2 firmy ActivMedia, jednak z czasem rozbudowano go dodając obsługę wielu innych urządzeń i algorytmów5 . Najważniejsze cechy decydujące o atrakcyjności i funkcjonalności Playera to: • niezależność od platformy i stosowanego języka programowania – program klienta łączący się z aplikacją Playera może zostać uruchomiony na dowolnym systemie operacyjnym; wymagane jest tylko istnienie połączenia sieciowego z robotem oraz to, żeby język programowania, w którym napisano progam kliencki, potrafił obsługiwać komunikację za pośrednictwem socketów TCP; Player dostarcza obecnie narzędzia ułatwiające komunikację z nim w językach C, C++, Tcl, Java, Python i Common LISP, • brak ograniczeń na strukturę programu klienta przeznaczonego do sterowania robotem – może ona być wielowątkowa, napisana w prosty sposób reaktywny (pobierz dane - reaguj) lub bardziej skomplikowany – z perspektywy Playera 5
Aktualną listę można znaleźć pod adresem http://playerstage.sourceforge.net/doc/
Player-cvs/player/supported_hardware.html
25
Rozdział 4. Player/Stage/Gazebo
nie ma to żadnego znaczenia, • możliwość reprezentacji wielu urządzeń przez ten sam interfejs – dzięki temu można np. sterować dwoma zupełnie różnymi robotami za pomocą tego samego programu klienta (ich efektory odpowiadające za przemieszczanie robota będą w obu przypadkach reprezentowane przez interfejs position), • wspieranie dowolnej liczby klientów; przykładowo, można stworzyć wiele połączeń do dowolnych instancji aplikacji Playera na dowolnym robocie i za pomocą jednej aplikacji sterować robotami, podczas gdy druga będzie odpowiedzialna za generowanie wykresów obrazujących odczyty z sensorów, • możliwość zdalnej konfiguracji serwera czasie jego pracy, • łatwość testowania rozwiązań w symulatorach – Player jest kompatybilny ze Stage oraz Gazebo, a kod napisany w celu sterowania robotami może działać bez poprawek zarówno z symulatorem, jak i z rzeczywistym robotem.
4.2.4
Wybrane rozwiązanie
Jak już wspomniano w paragrafie 3.2, do modelowania środowiska Ligi RoboCup wybrano symulator Gazebo. Pozwolił on na uwzględnienie cech fizycznych rozgrywki, co było niezbędne np. przy modelowaniu interakcji robota z piłką. Uznano także, że ten sposób symulacji ułatwi ewentualne późniejsze dostosowanie pracy aplikacji do sterowania rzeczywistymi robotami. Z tego tez względu zrezygnowano z użycia Playera – co prawda dostarcza on wiele użytecznych interfejsów do sterowania modelami, jednak w przypadku robotów HMT stworzono już aplikację sterującą, z której w przyszłości będzie można skorzystać. Ponadto podczas testów współpracy Gazebo (0.7) i Playera okazało się, że ówczesna wersja Gazebo nie miała ukończonej implementacji SimulationProxy (czyli narzędzia dającego dostęp do rzeczywistych pozycji robotów w symulatorze, które było niezbędne do zamodelowania pracy serwera video Ligi Robocup). Dlatego zdecydowano się na komunikację z Gazebo za pośrednictwem funkcji bibliotecznych dostarczonych przez libgazebo (poprzez pamięć dzieloną), co przy okazji przyspieszyło pracę i testy.
26
Rozdział 4. Player/Stage/Gazebo
4.3
Modelowanie obiektów w Gazebo
Filozofia modelowania w Gazebo opiera się na tworzeniu opisu świata (o parametrach określonych w pliku .world za pomocą języka XML), w którym umieszczone zostają symulowane obiekty. Sama koncepcja tworzenia tych obiektów zmieniała się wraz z rozwojem Gazebo. Przed wydaniem wersji 0.8 modele dodawane były do światów w formie skompilowanej do dołączanych dynamicznie plików *.so. Podejście to było dość uciążliwe dla projektantów (każda zmiana w modelu wymagała jego ponownej kompilacji), dlatego od wersji 0.8 zdecydowano się na inne rozwiązanie – Gazebo zostało przebudowane w ten sposób, żeby modele obiektów były tworzone dynamicznie na podstawie ich opisu w plikach XML, co w znacznym stopniu poprawiło prostotę użytkowania oraz szybkość tworzenia i testowania nowych modeli. Początkowo podczas tworzenia niniejszej pracy korzystano z Gazebo w wersji 0.7. Jednak wraz z pojawieniem się wydania 0.8 zdecydowano się przepisać posiadane modele robotów do kodu w XML. Decyzja ta została podyktowana problemami z wersją 0.7 (m. in. z jedynie częściową implementacją regulacji współczynnika tarcia dla modeli w starym Gazebo, co wpływało niekorzystnie na realizm symulacji). Nowa wersja symulatora okazała się także działać znacznie szybciej i wydajniej. Aby podkreślić zalety opisywania modeli robotów za pomocą języka XML, poniżej przedstawiono porównanie sposobu konstrukcji obiektów w obu używanych wersjach symulatora Gazebo.
4.3.1
Przykładowy model (Gazebo do v.0.7)
Jak już wspomniano, opis modelowanego środowiska należy zawrzeć w pliku XML z rozszerzeniem .world. Po uruchomieniu symulatora plik ten jest analizowany. Na jego podstawie ustawiane są parametry symulowanego świata (dotyczące zarówno fizyki, jak i sposobu renderowania sceny), jak i interfejsu użytkownika (rozmiary okna, pozycja, ujęcie kamery, itp.). Następnie wczytywane są modele reprezentujące obiekty. Modele te dzielą się na statyczne (dostarczone przez twórców symulatora i wkompilowane w Gazebo) oraz typu plug-in, czyli dołączane dynamicznie w formie modułów stworzonych przez użytkownika. Do modeli statycznych należą np. gotowe modele robotów Pioneer, czujniki, źródła światła oświetlające scenę czy modele podłoża. Przykładowy fragment pliku .world dodający modele wygląda następująco:
27
Rozdział 4. Player/Stage/Gazebo
Listing 4.1: Przykład użycia modeli (Gazebo 0.7) 1
2
< model:LightSource >
3
< id > light0
4
< xyz > 0.0 0.0 10.0
5
6 7
8
< model:GroundPlane >
9 10
< id > ground1
11 12
13
< model:Pioneer2AT >
14
< id > robot1
15
< xyz >0 0.0 0.5
16
< model:SickLMS200 >
17
< id > laser1
18
< xyz > 0.15 0 0.20
19 20
21 22
23
< model:Ball >
24
< plugin > ball . so
25
< id > ball0
26
< xyz > 1.5 1.3 0.02
27
< rpy >0 0 0
28
Chcąc zaprojektować model (typu plug-in), użytkownik musi stworzyć odpowiednią klasę w języku C++, dziedziczącą interfejs po klasie Model. Musi ona implementować następujące metody: • Load(), odpowiedzialną za tworzenie fizycznych i wizualnych elementów modelu; Za cechy fizyczne odpowiada element body (reprezentuje on pozycję, prędkość i siły działające na model), natomiast o wyglądzie decydują obiekty geoms, z jakich body się składa (geoms to inaczej podstawowe figury geometryczne, takie jak kula, walec, prostopadłościan, z których można tworzyć bardziej złożone kształty. Jeżeli tworzony robot składa się z wielu elementów 28
Rozdział 4. Player/Stage/Gazebo
body (np. są to koła robota i jego podwozie), to należy je połączyć za pomocą złączeń, czyli joints; • Init(), metodę pozwalającą na wprowadzenie modelu w stan początkowy i zainicjowane jego elementów; • Fini(), pozwalającą na zwolnienie interfejsów w momencie likwidacji modelu; • Update(), podstawową metodę sterującą zachowaniem modelu. Jest ona wywoływana cyklicznie przez symulator i pozwala na sprawdzenie stanu interfejsów robota, odebranie poleceń od aplikacji kontrolera i wykonanie zadanych sterowań (przez przyłożenie odpowiednich sił do elementów joints). Tak przygotowany model jest gotowy do kompilacji i dołączenia do testowanego świata. Przykładowy kod tworzący model (piłkę do Ligi Robocup) wygląda następująco: Listing 4.2: Przykładowy model piłki(Gazebo 0.7) 1
int Ball :: Load ( WorldFile * file , WorldFileNode * node )
2
{
3
// dodanie ciala do modelu
4
Body ball = new Body ( this - > world ) ;
5
this - > AddBody ( ball , true ) ;
6 7
// wymiary pilki golfowej i masa
8
float r = 0.021;
9
float m = 0.045;
10 11
GzColor c = GzColor (1.0 , 0.4 , 0.0) ;
// pomaranczowy
12 13
// zdefiniowanie wygladu pilki
14
Geom * ballShape ;
15
ballShape = new SphereGeom ( ball , this - > modelSpaceId , r ) ;
16
ballShape - > SetRelati ve P o si t i on ( GzVectorSet (0 , 0 , 0) ) ;
17
ballShape - > SetMass ( m ) ;
18
ballShape - > SetColor ( c ) ;
19
return 0;
20
}
29
Rozdział 4. Player/Stage/Gazebo
Przedstawiony sposób opisu ma jedną zasadniczą wadę: podczas tworzenia modelu użytkownik jest często zmuszony do zmieniania jego parametrów i wprowadzania poprawek po to, żeby projektowany obiekt zachowywał się w sposób odzwierciedlający rzeczywistość, a to wiąże się z koniecznością ciągłego rekompilowania plików źródłowych modelu.
Rysunek 4.4: Dostępne typy geoms – Gazebo 0.8 (źródło: [17])
4.3.2
Zasady modelowania w Gazebo 0.8
W wersji 0.8 symulatora Gazebo modelowanie robotów zostało znacznie ułatwione. Zrezygnowano z tworzenia kodów w C++ na rzecz opisu obiektów w XML, co pozwoliło przyspieszyć implementację i testy. Chcąc stworzyć symulowane środowisko (podobnie jak w przypadku Gazebo 0.7), należy rozpocząć od pisania głównego pliku .world. Plik ten musi zawierać informacje związane z konfiguracją interfejsu użytkownika, sposobem renderowania sceny oraz fizyką symulacji. Przykładowy plik .world składa się z następujących elementów:
30
Rozdział 4. Player/Stage/Gazebo
1
