politechnika wrocławska wydział elektroniki praca dyplomowa ...

POLITECHNIKA WROCŁAWSKAWYDZIAŁ ELEKTRONIKIKIERUNEK:SPECJALNOŚĆ:Automatyka i Robotyka (AiR)Robotyka (ARR)PRACA DYPLOMOWAMAGISTERSKASymulator graficzny robotów Pioneer iPeopleBotGraphics simulator of Pioneer andPeopleBot robotsAUTOR:Adam NowakowskiPROWADZACY ˛ PRACE:˛dr inż. Bogdan Kreczmer, I-6OPIEKUN:dr inż. Bogdan Kreczmer, I-6OCENA PRACY:

Spis treści1 Wstęp 12 Założenia i cel pracy 33 Przeglad ˛ istniejacych ˛ rozwiazań ˛53.1 Webots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 ROBOOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Przeglad ˛ wykorzystywanych narzędzi 114.1 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 VTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 ODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4 X3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Roboty Pioneer i PeopleBot – ogólna charakterystyka 155.1 Pioneer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 PeopleBot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Sterowanie i systemy sensoryczne robotów Pioneer i PeopleBot 176.1 Sterowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.1.1 Komunikacja z robotem . . . . . . . . . . . . . . . . . . . . . . . . . 176.1.2 Pakiety informacyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.2 Systemy sensoryczne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.2.1 Sonary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.2.2 Enkodery inkrementalne . . . . . . . . . . . . . . . . . . . . . . . . . 197 Symulator robotów Pioneer i PeopleBot – architektura i struktury danych 217.1 Symulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217.2 Sensory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.3 Procesory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Realizacja interfejsu użytkownika – opis funkcjonalności 298.1 Simbo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298.1.1 Plik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308.1.2 Symulacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318.1.3 Opcje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.2 SimboEd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.2.1 Plik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.2.2 Dodaj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.2.3 Edytuj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

iiSPIS TREŚCI8.2.4 Ustawienia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Pakiety oprogramowania przeznaczone do sterowania robotami 419.1 Aria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419.2 UNIFRACX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4210 Integracja symulatora z innymi pakietami oprogramownia 4510.1 Integracja z Arią . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4510.2 Integracja z UNIFRACXem . . . . . . . . . . . . . . . . . . . . . . . . . . . 4511 Implementacja algorytmów nawigacji z wykorzystaniem pakietu Aria 4911.1 Losowy ruch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4911.2 Metoda sił wirtualnych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5011.3 Algorytm histogramu pola wektorów . . . . . . . . . . . . . . . . . . . . . . . 5112 Wyniki eksperymentów 5512.1 Losowy ruch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5512.2 Metoda sił wirtualnych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5512.3 Histogram pola wektorów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5813 Podsumowanie 63A Przykład użycia edytora SimboEd 65B Przykład implementacji dalmierza laserowego 69

Rozdział 1WstępSymulatory robotów mają na celu odwzorowanie w możliwie dokładny sposób w wirtualnymśrodowisku zachowania rzeczywistej maszyny. Ich zastosowanie niesie za sobą szereg korzyści.Są one znacznie tańsze, zarówno pod względem zakupu jak i eksploatacji, a przez to stają sięłatwiej dostępne dla ogółu. Ponadto osoby korzystające z nich nie muszą obawiać się efektówniepoprawnej obsługi robota lub uruchomienia programu sterującego obarczonego błędami, cow przypadku rzeczywistej maszyny może doprowadzić do uszkodzenia jej samej lub otoczenia,w którym się ona porusza. Również nie bez znaczenia jest możliwość łatwej modyfikacji scenyoraz robota lub robotów na niej obecnych, by w ten sposób sprawdzić poprawność zachowaniamaszyny w różnorodnych sytuacjach, zanim program nią sterujący zostanie zastosowany wrzeczywistym modelu. Podobnie symulatory są też wygodną metodą zapoznania się z możliwościamidanego robota, przed dokonaniem decyzji o jego zakupie. Pomimo tych zalet pamiętaćjednak należy, iż dokładność odwzorowania rzeczywistości przez symulatory zawsze będzie wpewnym stopniu ograniczona, a ostateczny test poprawności funkcjonowania robota dokonaćsię musi na prawdziwym urządzeniu.W chwili obecnej istnieje szereg symulatorów robotów. Różnią się one opcjami i możliwościamirozbudowy oraz dostępnością. Wiele z nich to produkty komercyjne o zamkniętymkodzie, co ogranicza możliwości modyfikacji aplikacji i dostosowywania jej do własnych potrzeb.Niektóre posiadają odgórnie narzucony zestaw robotów lub sensorów, a brak przejrzystegoi intuicyjnego interfejsu znacznie utrudnia użytkownikowi dodawanie własnych modelido takich aplikacji. Istnieją również symulatory dedykowane konkretnym modelom robotów,co znacznie ogranicza zakres ich wykorzystania. Niniejsza praca stara się rozwiązać powyższeograniczenia, udostępniając aplikację o otwartym kodzie, której prosty interfejs umożliwiałatwe dostosowanie jej do konkretnego zastosowania.

Rozdział 2Założenia i cel pracyOczekiwanym efektem końcowym pracy jest aplikacja graficzna wizualizująca pracę robotaPioneer i PeopleBot. Aplikacja ta powinna umożliwiać obrazowanie pracy w pomieszczeniachbudynku. Sam kształt pomieszczenia lub połączonych ze sobą pomieszczeń powinien być możliwydo zadawania przez użytkownika. Modelowanie pomieszczeń może się odbywać w tej samejaplikacji lub aplikacji zewnętrznej, której opis sceny będzie importowany przez właściwysymulator. Powinno być możliwe również dodanie innego typu robotów.Stworzony symulator powinien pozwalać na umieszczanie dodatkowych elementów na korpusierobota. Ponadto powinien dopuszczać możliwość pracy kilku robotów jednocześnie. Testempoprawności realizacji symulator ma być połączenie symulatora z pakietem oprogramowaniaAria, który przeznaczony jest do sterowania rzeczywistym robotem. Wykorzystując tenpakiet należy oprogramować prosty system nawigacji dla robotów Pioneer i PeopleBot. Uzyskanewyniki należy porównać z efektami sterowania rzeczywistym robotem.

Rozdział 3Przeglad ˛ istniejacych ˛ rozwiazań˛Niniejszy rozdział przedstawia najpopularniejsze symulatory wraz z krótkim opisem dostępnychrobotów oraz sensorów. Poniżej prezentowane są zarówno gotowe aplikacje, jak i bibliotekiudostępniające funkcjonalność symulatora, jednakże bez interfejsu użytkownika.3.1 WebotsWebots jest popularnym symulatorem robotów dostępnym w wersji profesjonalnej oraz edukacyjnej.Projekt ten został rozpoczęty w 1996 roku przez dr Oliviera Michela na PolitechniceFederalnej w Lozannie, a od 1998 roku jest dalej rozwijany przez Cyberbotics [9]. Jest on dostępnyw wersjach przeznaczonych dla systemów MS Windows, Linuks oraz Mac OS X. Wykorzystujeon bibliotekę fizyczną ODE (Open Dynamics Engine), co pozwala na realistyczneodwzorowanie zachowania robotów i innych obiektów na scenie. Natomiast wizualizacja przeprowadzanajest przy pomocy biblioteki OpenGL.Webots udostępniany jest wraz z gotowym zestawem robotów oraz przykładowymi symulacjamiprezentującymi możliwości symulatora. W wersji 6.2.2 programu dostępne są następująceprzykłady:• Bioloid Dog – robot kroczący kształtem przypominający psa o 16 stopniach swobody,model oparty na rzeczywistym robocie firmy Tribotix,• Kondo KHR–2HV – humanoidalny robot oparty na rzeczywistym robocie firmy Kondo,• platforma Stewarta – prezentacja silnika fizycznego symulatora oraz działania serwomechanizmów,• Salamandra Robotica – robot pływający o kształcie salamandry, model oparty na rzeczywistymrobocie z Biorobotics Laboratory,• Shrimp III – sześciokołowy robot pasywnie dostosowujący się do jazdy po nierównymterenie, model bazuje na konstrukcji robota firmy BlueBotics,• Ghostdog – robot kroczący kształtem przypominający psa, z aktywnymi i pasywnymikończynami oraz sensorami dotyku,• Surveyor SRV-1 – robot na gąsienicach, posiadający kamerę do obserwacji otoczenia,model oparty na robocie firmy Surveyor,• IPR (Katana) – linia produkcyjna z robotem HD6M180 o 6 stopniach swobody wyposażonymw chwytak, czujniki podczerwieni oraz dotyku, model oparty na robocie firmyNeuronics,

6 Przeglad ˛ istniejacych ˛ rozwiazań˛• Gantry Robot – robot transportowy układający wieże Hanoi,• Fujitsu HOAP-2 – humanoidalny robot kroczący oparty na rzeczywistym robocie firmyFujitsu,• Hexapod – sześcionożny robot kroczący wykorzystujący napędy liniowe i obrotowe,• E-Puck – Robot kołowy klasy (2,0) śledzący czarną linię oraz omijający przeszkody,• QRIO Robot – humanoidalny robot luźno oparty na rzeczywistym robocie firmy Sony,• Sojourner Rover – sześciokołowy robot przeznaczony do eksploracji powierzchni Marsa,• Autonomiczny samochód – samochód korzystający z kamery oraz dalmierzy, aby poruszaćsię po drodze i unikać przeszkód,• robot modułowy – wężopodobny model robota YAMOR z Biorobotics Laboratory,• Fujitsu HOAP-2 sumo – model rzeczywistego robota firmy Fujitsu, wykonujący rytuałShiko zapaśników Sumo,• LIS-EPFL Blimp – balon powietrzny prezentujący alternatywny sposób lokomocji,• Gra w piłkę nożną – symulacja prezentuje dwie drużyny robotów grające w piłkę nożną.Ponadto Webots umożliwia również tworzenie własnych modeli robotów (kształt, tekstura,masa, tarcie, napędy oraz sensory) oraz otoczenia. Roboty kontrolowane są za pomocą programównapisanych w C, C++, Javie, Pythonie lub MATLABie.Webots udostępnia również szereg sensorów oraz napędów, które można wykorzystywać wrobotach; są to m.in.:• akcelerometry,• kamery,• dalmierze,• system GPS,• detektory światła,• detektory dotyku,• mikrofony,• radioodbiorniki,• serwomechanizmy,• diody LED,• napędy różnicowe,• głośniki.Niestety Webots nie oferuje możliwości implementacji własnych czujników, więc wszelkieich modyfikacje mogą być wprowadzane jedynie przez producenta w kolejnych wersjachprogramu.

3.2 ROBOOP 7Rysunek 3.1: Główne okno symulatora Webots.3.2 ROBOOPROBOOP jest darmową biblioteką C++ udostępnianą na licencji GNU GPL wspomagającąprzeprowadzanie symulacji łańcuchów kinematycznych [7]. Projekt ten został zapoczątkowanyw 1996 roku przez Richarda Gourdeau na Politechnice Montrealskiej. Biblioteka ta zawieramiędzy innymi funkcje wyliczające kinematykę prostą i odwrotną, jakobian, moment obrotowyi przyspieszenie. Istotną wadą tej biblioteki jest jej niska wydajność — wyliczenie kinematykilub dynamiki robota dla przykładowych modeli dostarczanych wraz z bilbioteką zajmuje kilkanaściemilisekund, co wyklucza zastosowanie jej w bardziej złożonym symulatorze działającymw czasie rzeczywistym. Problemem jest również ograniczona funkcjonalność umożliwiająca jedyniemodelowanie stosunkowo prostych łańcuchów kinematycznych pojedynczego robota, atakże brak mechanizmów detekcji i rozwiązywania kolizji z innymi obiektami na scenie.ROBOOP wymaga zainstalowania biblioteki Boost oraz gnuplota (w przypadku wykorzystywaniafunkcji rysowania wykresów). Razem z biblioteką dostarczone są pliki makefileumożliwiające łatwe skompilowanie przy użyciu kompilatorów Borland C++ 4.5 i 5.x, VisualC++ 6.0, Visual C++ 7.0 (.NET) oraz GNU G++.Głównymi klasami ROBOOP są Robot oraz mRobot. Zawierają one informacje o ilościstopni swobody robota, wektorze grawitacji oraz tablicę przegubów opisujących łańcuch kinematycznyrobota. Ponadto udostępniają one metody wyliczające dynamikę oraz kinematykęprostą i odwrotną robota.Dodatkowo biblioteka ROBOOP ułatwia wykonywanie transformacji obiektów. Służą dotego funkcje wyliczające macierz rotacji na podstawie kątów Eulera, wektora i kąta lub wektorai punktów (oraz odwrotne do tych transformacji), a także funkcja translacji o określony wektor.

8 Przeglad ˛ istniejacych ˛ rozwiazań˛Rysunek 3.2: Zastosowanie biblioteki ROBOOP z wizualizacją realizowaną przez GLroboop.W wykonywaniu rotacji pomocna jest również klasa kwaternionów.Ponadto zestaw funkcji graficznych umożliwia tworzenie charakterystyk różnych parametrówsymulacji w oparciu o plik ze wspołrzędnymi punktów. Tego typu wykresy można dalejmodyfikować dodając własne krzywe oraz informacje o charakterystyce (nazwy osi, tytuł).3.3 PlayerProjekt Player jest darmowym programem udostępnianym na licencji GNU GPL służącym dosymulacji i badań robotów oraz ich sensorów [5]. Został on rozpoczęty w 2000 roku przezBriana Gerkeya, Richarda Vaughana, Andrew Howarda oraz Nathana Koeniga na UniwersyteciePołudniowokalifornijskim. W roku 2001 ukazała się wersja 1.0 programu. Składa się on ztrzech modułów: Player, Stage oraz Gazebo.Player pozwala kontrolować różnorodne roboty i sensory poprzez interfejs TCP. Taka struktura,typu klient-serwer umożliwia tworzenie oprogramowania sterującego robotami w dowolnychjęzykach.Stage jest symulatorem mobilnych robotów w środowisku dwuwymiarowym. Udostępniaon szereg sensorów, które można wykorzystać w robotach, np. sonar, dalmierz laserowy lubkamerę.Gazebo, podobnie jak Stage, jest również symulatorem, ale przeznaczonym do środowiskatrójwymiarowego. Zawiera on także moduł symulacji fizyki brył sztywnych, co pozwala narealistyczne odwzorowanie zachowań obiektów na scenie.

3.3 Player 9Wszystkie trzy moduły dostępne są w wersji pracującej pod Linuksem, ponadto Player orazStage są również dostępne w wersji przeznaczonej systemów Solaris, BSD oraz Mac OS X.Dodatkowo Gazebo wymaga również zainstalowania bibliotek Mesa3D oraz GLUT, a takżesilnika fizycznego ODE oraz biblioteki graficznej OGRE.Player umożliwia symulowanie następujących modeli robotów:• robot Garcia firmy Acroname,• robot Obot d100 firmy Botrics,• roboty ER1 oraz ERSDK produkowane przez Evolution Robotics,• robot odkurzający Roomba firmy iRobot,• robot Khephera produkowana przez K-Team,• seria robotów z MobileRobots, m.in. Pioneer oraz PeopleBot,• platforma NOMAD200 firmy Nomadics,• robot Clodbuster produkowany przez UPenn GRASP,• platforma ERRATIC firmy Videre Design,• robot 914 PC-BOT produkowany przez White Box Robotics.Ponadto Player zawiera również zestaw sensorów i dodatkowego sprzętu, który można montowaćw modelach robotów. Są to m.in. kamery, dalmierze laserowe, odbiorniki GPS, czytnikiRFID, akcelerometry, głośniki, bezprzewodowe karty sieciowe oraz joysticki.

Rozdział 4Przeglad ˛ wykorzystywanych narzędziStworzenie aplikacji kompletnego symulatora jest zadaniem niezwykle złożonym, wymagającymrozwiązania zarówno problemów samej symulacji, jak i kwestii wizualizacji, reprezentacjidanych, przepływu informacji oraz interfejsu użytkownika. Aby sprawnie rozwiązać niektórez tych kwestii, w symulatorze Simbo wykorzystano szereg istniejących bibliotek i formatówdanych. Poniżej przedstawiono opis tych narzędzi.4.1 QtQt jest zestawem bibliotek i narzędzi wspomagających tworzenie interfejsu użytkownika w językuC++. Projekt został rozpoczęty w roku 1991 przez Haavarda Norda i Eirika Chambe-Engaz Trolltechu, a pierwsza jego wersja ukazała się w roku 1995 [3]. Od 2008 roku Qt jest dalejrozwijane przez Nokię. W późniejszych wersjach dodano szereg klas niezwiązanych bezpośrednioz programowaniem interfejsu, natomiast przydatnych w innych aspektach tworzeniaaplikacji. Jest on dostępny w wersjach przeznaczonych dla trzech głównych systemów, tzn.MS Windows, Linuks oraz Mac OS X, a także dla niektórych mniej popularnych platform.Taka wieloplatformowość umożliwia stosunkowo łatwe przenoszenie kodu aplikacji na innesystemy operacyjne.Na potrzeby symulatora Simbo, biblioteka Qt została wykorzystana głównie do utworzeniainterfejsu użytkownika — okienek programu oraz interakcji pomiędzy nimi (przy użyciu sygnałówQt). Również interfejsy bibliotek sensorów oraz procesorów robotów są oparte o pluginyQt, ze względu na wykorzystywanie przez nich sygnałów. Ponadto taktowanie symulatora kontrolowanejest przez obiekt Qt klasy QTimer.4.2 VTKVTK (Visualisation Toolkit) jest darmową biblioteką C++ o otwartym kodzie wspomagającątworzenie grafiki dwu- i trójwymiarowej [13]. Pierwsza jej wersja została napisana w 1993roku przez Willa Schroedera, Kena Martina i Billa Lorensena jako dodatek do książki "TheVisualization Toolkit: An Object-Oriented Approach to 3D Graphics". W 1998 roku w celusprostania rosnącej popularności VTK Will i Ken założyli firmę Kitware, która od tego czasuzajmuje się dalszym rozwojem tej biblioteki. VTK jest dostępne dla systemu MS Windows,Linuks oraz Mac OS X. Możliwe jest również pisanie programów w Pythonie, Javie lub Tcl iautomatyczna konwersja kodu na C++.W Simbo VTK jest wykorzystywany jako warstwa pośrednicząca pomiędzy reprezentacjąsceny w symulatorze oraz funkcjami OpenGL. Takie rozwiązanie znacznie usprawnia wizualizacjęsceny, gdyż biblioteka VTK, w przeciwieństwie do samego OpenGL, zawiera szereg

12 Przeglad ˛ wykorzystywanych narzędziklas reprezentujących podstawowe bryły geometryczne (np. vtkCube, vtkCylinder) oraz klasysłużące do tworzenia (vtkRenderer) i wizualizacji sceny (vtkRenderWindow). Ponieważ analogiczneobiekty geometryczne są definiowane również w bibliotece ODE jak i w formacie X3D,pozwala to na bezpośrednie przeniesienie wyników symulacji na wizualizowaną scenę. Równieżistotny jest fakt istnienia klasy QVTKWidget, która pozwala w prosty sposób wyświetlićwizualizację VTK w interfejsie Qt.4.3 ODEODE (Open Dynamics Engine) jest darmowym silnikiem fizycznym o otwartym kodzie napisanymw język C++ [14]. Został on stworzony w 2001 roku przez Russella Smitha i od tego czasubył wykorzystywany w wielu symulatorach oraz grach. Zapewnia on obiekty i funkcje do symulacjifizyki brył sztywnych oraz funkcje do detekcji kolizji, aczkolwiek możliwe jest równieżwykorzystanie własnych bibliotek. Natomiast ODE nie zawiera żadnych mechanizmów wizualizacji.Dzięki temu jest on niezależny od platformy na której jest uruchamiany, wymagającjedynie utworzenia sceny i obiektów na niej przy pomocy dostępnych funkcji.Mimo braku wewnętrznych funkcji wizualizacyjnych ODE umożliwia ustawienie do nichwskaźników dla każdego obiektu na scenie, dzięki czemu gdy zmieni on położenie, wizualizacjatego obiektu zostanie automatycznie uaktualniona. Mimo to mechanizm ten nie zostałwykorzystany w Simbo, ze względu na wykonywanie wielu iteracji symulacji fizyki podczaspojedynczego wywołania wizualizacji (domyślnie po 10 krokach ODE następuje pojedynczewywołanie wizualizacji).ODE opisuje scenę za pomocą trzech głównych grup obiektów. Pierwsza z nich, geomy,służy do opisu geometrii obiektów. Geomy obsługiwane przez Simbo to Box (prostopadłościan),Sphere (kula) oraz Cylinder — z nich można budować modele obiektów na scenie. Wprzypadku sensorów możliwe jest również wykorzystanie dowolnych innych geomów, przykładowodalmierz laserowy wykorzystywać może Ray (promień), a sonar TriMesh (siatkę trójkątów)w celu wykrycia pobliskich przeszkód.Druga grupa obiektów ODE to ciała (body); zawierają one informacje o fizycznych właściwościachobiektu (np. masa, prędkość) oraz o przypisanych im geomach. Pojedyncze ciałomoże być powiązane z wieloma geomami, dzięki czemu możliwe jest tworzenie bardziej złożonychstruktur z podstawowych brył geometrycznych.Ostatnia grupa obiektów to przeguby (joint). Łączą one ciała ze sobą, ograniczając ich wzajemnepołożenie do pewnych dozwolonych konfiguracji. Simbo pozwala definiować dwa typyprzegubów — obrotowe (Single Axis Hinge Joint) i translacyjne (Slider Joint), z których możnastworzyć dowolne połączenie pomiędzy obiektami. Dodatkowo Simbo wykorzystuje równieżtymczasowe przeguby kolizyjne (Collision Joint; tworzone jedynie na czas pojedynczego krokusymulacji, aby umożliwić interakcję poszczególnych ciał między sobą) oraz napędowe (MotorJoint; tworzone w celu przemieszczenia obiektu lub przegubu w zadane położenie).4.4 X3DX3D jest XMLowym standardem ISO (ISO/IEC 19775/19776/19777) stworzonym jako następcaVRML przez konsorcjum Web3D [6]. Pierwsza jego specyfikacja została zaakceptowanaprzez Międzynarodową Organizację Normalizacyjną w 2004 roku. X3D pozwala przechowywaćróżnorodne informacje graficzne i geometryczne. Oznacza to możliwość opisu złożonychobiektów geometrycznych oraz ich atrybutów fizycznych (masa, tarcie) i graficznych (tekstura),jak również informacji o środowisku (oświetlenie, mgła, grawitacja, itp). Od wersji 3.2 format

4.4 X3D 13ten pozwala również definiować przeguby łączące poszczególne obiekty, a tym samym tworzyćłańcuchy kinematyczne.Istnieje szereg edytorów przeznaczonych do edycji plików X3D (np. X3D-Edit, SwirlX3D,Flux Studio); również niektóre edytory graficzne umożliwiają eksport do formatu X3D (np.Blender, aczkolwiek nie zapisuje on ogólnych danych o geometrii obiektów, takich jak promieńkuli lub wysokość/szerokość sześcianu, a jedynie współrzędne wszystkich wierzchołków danejbryły).Na potrzeby symulatora robotów Simbo stworzono profil X3D zawierający jedynie elementyniezbędne do opisu modeli obiektów. Grupy węzłów wchodzące w skład tego profiluprzedstawione zostały poniżej.• Podstawowe bryły geometryczne:– Box,– Cone,– Cylinder,– Sphere,– Shape.• Bryły sztywne (wymaga X3D w wersji 3.2):– RigidBodyCollection,– RigidBody,– CollidableShape.• Przeguby (wymaga X3D w wersji 3.2):– BallJoint,– DoubleAxisHingeJoint,– MotorJoint,– SingleAxisHingeJoint,– SliderJoint.• Tekstury:– Appearance,– ImageTexture,– TextureTransform.Przykładowy fragment kodu X3D opisujący tylną oś i kółko Pioneera widocznego na rysunku4.1 ma następującą postać:

14 Przeglad ˛ wykorzystywanych narzędziRysunek 4.1: Wizualizacja modelu Pioneera w Simbo.

Rozdział 5Roboty Pioneer i PeopleBot – ogólnacharakterystykaNiniejszy rozdział zawiera krótką historię Pioneera oraz PeopleBota, a także przedstawia ichwygląd oraz możliwości.5.1 PioneerPrototyp Pioneera powstał w 1995 roku w ramach współpracy pomiędzy RWI i ActivMediaRobotics jako tania platforma badawcza umożliwiająca odbiorcom skoncentrowanie się na sterowaniui interakcji, a nie samej jego budowie [2]. Robot dostępny jest w dwóch wersjach;Pioneer 2-AT jest czterokołowym robotem dostosowanym do przemieszczania się po różnorodnychpowierzchniach. Natomiast Pioneer 2-DX jest trójkołowym robotem klasy (2,0) przeznaczonymgłównie do badań w pomieszczeniach zamkniętych. W niniejszej pracy uwagępoświęcono modelowi P2DX.Pioneer 2-DX jest robotem o wymiarach: 21,5cm wysokości, 42,5cm szerokości oraz 51cmdługości. Może osiągać maksymalną prędkość 1,6m/s i transportować ciężary do 23kg. Posiadaon pierścień ośmiu sonarów umożliwiających wykrywanie przeszkód przed robotem orazenkodery inkrementalne pozwalające mierzyć kąt obrotu kół, dzięki czemu na niewielkich dystansachmożna określać przemieszczenie robota (na większych odległościach pomiar przestajebyć dokładny). Ponadto robot może zostać wyposażony w dodatkowe sensory i efektory, takiejak:• zestaw 8 sonarów umożliwiających detekcję przeszkód za robotem,• dalmierze laserowe,• zderzaki (pozwalające wykrywać kolizję robota z przeszkodami),• chwytak (umożliwiający podnoszenie ciężarów do 2kg),• kamerę (zarówno zwykłą jak i stereoskopową),• kompas.Tego typu wyposażenie znacznie rozszerza możliwości rozpoznawania otoczenia i nawigacji.Komunikacja z robotem może odbywać się w sposób bezprzewodowy lub poprzez bezpośredniepołączenie z komputerem.

16 Roboty Pioneer i PeopleBot – ogólna charakterystyka5.2 PeopleBotPeopleBot jest robotem zbudowanym na bazie Pioneera i posiada podobne parametry. Jest jednakod niego wyższy, mierząc 112cm. Robot ten powstał w 2000 roku z myślą o bardziejbezpośredniej interakcji z ludźmi oraz typowym otoczeniem w pomieszczeniach zamkniętych(meble) [2]. W tym celu oprócz przedniego pierścienia ośmiu sonarów, w podstawowej wersjiwyposażony jest on również tylny pierścień sonarów oraz przedni umieszczony na górnejplatformie. Ponadto robot posiada czujnik podczerwieni umożliwiający wykrywanie przeszkódznajdujących się pomiędzy górną a dolną platformą (np. stół). Zamontowanie ekranu dotykowegona górnej platformie umożliwia wyświetlanie informacji, a przez to bardziej bezpośredniąinterakcję robota z człowiekiem.Robot dostępny jest w dwóch wersjach. Performance PeopleBot przeznaczony jest do interakcjiz otoczeniem; w tym celu wyposażony został w chwytak o dwóch stopniach swobody,dodatkowe czujniki podczerwieni umożliwiające prostopadłą orientację względem brzegu stołuoraz kamerę umożliwiającą obserwację twarzy ludzi lub obiektów, które podnosi chwytakiem.Natomiast Talking PeopleBot dodatkowo posiada oprogramowanie służące do rozpoznawaniamowy oraz syntezatory mowy, dzięki czemu może odbierać werbalne polecenia od ludzi orazprowadzić z nimi konwersacje.

Rozdział 6Sterowanie i systemy sensoryczne robotówPioneer i PeopleBotW niniejszym rozdziale przedstawiono protokół komunikacji z Pioneerem i PeopleBotem (zarównoprzesyłanie komend do robotów jak i dobieranie pakietów informacyjnych przez nie wysyłanych).Ponadto również opisano szczegółowo sensory, w które oba roboty są wyposażonew podstawowej wersji.6.1 Sterowanie6.1.1 Komunikacja z robotemTypowe sterowanie Pioneerem (i PeopleBotem, gdyż zbudowany jest on na podstawie Pioneera)odbywa się przy pomocy aplikacji klienta uruchomionej na komputerze, która komunikujesię z robotami poprzez port szeregowy. Po nawiązaniu połączenia klient wysyła do robota trzypakiety synchronizujące (SYNC0, SYNC1, SYNC2) oraz komendę uruchomienia sterownika(OPEN) — po tych czynnościach robot jest gotowy do odbierania dalszych poleceń. Ponadtoaby połączenie nie zostało zerwane, klient musi okresowo odświeżać watchdoga robota wysyłającco najmniej jeden rozkaz co 2 sekundy (istnieje możliwość zmiany tego przedziału czasu).W przypadku braku rozkazów do wysłania, klient może wysłać komendę PULSE, której jedynąfunkcją jest właśnie utrzymanie połączenia.Przemieszczenie Pioneera można kontrolować za pomocą komend sterowania pośredniegoi bezpośredniego ruchem. Robot przełącza się w odpowiedni tryb sterowania po otrzymaniuktórejś z komend należących do danego trybu. W przypadku bezpośredniego sterowania istniejejedna komenda funkcjonująca w nim — VEL2. Umożliwia ona zadanie oddzielnych prędkościobrotowych dla każdego z kół robota. Natomiast w przypadku sterowania pośredniego Pioneeramożna kontrolować za pomocą następujących poleceń:• HEAD – obrót robota do podanego kąta,• DHEAD – obrót robota o podany kąt,• ROTATE – obrót robota z podaną prędkością kątową,• VEL – ruch robota z podaną prędkością liniową,• MOVE – ruch robota o podany dystans.

18 Sterowanie i systemy sensoryczne robotów Pioneer i PeopleBotPioneer posiada górne limity maksymalnych prędkości i przyspieszeń, które nie mogą byćprzekroczone. Informację o tych limitach klient może uzyskać z pakietu konfiguracyjnego przysyłanegoprzez robota po wydaniu polecenia CONFIG. Dla Pioneera 2-DX ograniczenia te sąnastępujące:• limit prędkości kątowej (całego robota): 360 ◦ s• limit prędkości liniowej: 2,2 m s• limit przyspieszenia kątowego (całego robota): 600 ◦ s 2• limit przyspieszenia liniowego: 4 m s 2Dodatkowo klient może zdefiniować własne ograniczenia prędkości i przyspieszenia liniowegoi kątowego, jednak nie mogą one być większe niż powyższe. Te ograniczenia robot stosuje,gdy wydane zostaną polecenia pośredniego sterowania ruchem.6.1.2 Pakiety informacyjneInformacja zwrotna od robota przesyłana jest poprzez pakiety informacyjne (SIP, server informationpacket). Każdy taki pakiet posiada typ, który określa jaki rozdzaj informacji jest w nimzawarty. Wysłanie pakietu danego typu odbywa się tylko na żądanie klienta, aczkolwiek możliwejest również zażądanie wysyłania ciągłego. Protokół Pioneera definiuje szereg pakietówróżnego typu. W symulatorze Simbo zaimplementowane zostały następujące:• pakiet konfiguracyjnyZawiera parametry konfiguracyjne robota, takie jak wspomniane powyżej ograniczeniaprędkości i przyspieszeń, a także informacje o zainstalowanych czujnikach i efektorach,szybkości połączenia i inne. W tym pakiecie również zawarta jest informacja o typie imodelu robota oraz jego nazwie.• pakiet standardowyPakiet zawiera większość informacji potrzebnych do skutecznej nawigacji robota w otoczeniu.Do najważniejszych należy pozycja i orientacja robota (uzyskana na podstawieodczytów z enkoderów kół), prędkości kół oraz odczyty z sonarów, zderzaków i kompasu.• pakiet chwytakaPakiet pozwala stwierdzić czy chwytak został zamontowany oraz sprawdzić stan jegoramion i podnosnika (zamknięte/w ruchu/otwarte). Ponadto pakiet pozwala odczytać czasuchwytu — wartość ta liczona jest od momentu, gdy ramiona zetknęły się z obiektem, domomentu gdy osiągnięty zostanie zadany czas. Dzięki temu możliwe jest sterowanie siłąnacisku ramion.• pakiet enkoderówPakiet tego typu zawiera bezpośrednie wartości enkoderów obu kół i może być wykorzystanydo niezależnego określenia pozycji i orientacji robota.Poza powyższymi istnieją również takie jak: pakiet listy utworów, pakiet portów I/O oraz pakietyspecyficzne dla danego typu urządzeń peryferyjnych zamontowanych na robocie.Na potrzeby symulatora Simbo zdefiniowano również dwa dodatkowe typy pakietów: PAUSE(0xFC) oraz RESUME (0xFD), które robot wysyła do klienta, gdy symulacja zostanie wstrzymanalub wznowiona. Dzięki temu klient przystosowany do tego symulatora jest w stanie

6.2 Systemy sensoryczne 19Rysunek 6.1: Układ pierścienia sonarów na Pioneerze.wstrzymać własne działania i odczekać na wznowienie symulacji. Przysłanie tego typu pakietówdo standardowych klientów Pioneera nie zaburza ich funkcjonowania w żaden sposób,gdyż pakiety o nierozpoznanych typach są ignorowane.6.2 Systemy sensoryczne6.2.1 SonaryPioneer standardowo wyposażony jest w zestaw 8 sonarów umieszczonych z przodu robota takjak przedstawiono to na rysunku 6.1. Sonary te dokonują pomiaru odległości z częstotliwością25Hz oraz posiadają zasięg od 10cm do około 5m. W przypadku zamontowania również tylnegozestawu sonarów możliwe jest detekcja przeszkód w obrębie 360 stopni, czyli wokół całegorobota.Przy modelowaniu sonarów w symulatorze uwzględniony został efekt odbicia sygnału odpłaskiej powierzchni, co przy niewielkim kącie padania może spowodować niewykrycie przeszkody.Z powodu złożoności problemu detekcji najbliższej przeszkody przez sonar z uwzględnieniemtego efektu, w symulatorze Simbo moduł odpowiedzialny za funkcjonowanie sonarapracuje jedynie z częstotliwością około 2Hz, aby nadmiernie nie spowalniać symulacji przywiększej ilości sonarów obecnych na scenie.6.2.2 Enkodery inkrementalneRobot Pioneer posiada dwa enkodery inkrementalne pozwalające określić położenie i prędkośćobrotową każdego z kół robota. Dzięki temu przy założeniu braku poślizgu oraz stałym kontakciez podłożem możliwe jest śledzenie zarówno pozycji jak i orientacji robota. Te informacjePioneer wylicza automatycznie przyjmując układ współrzędnych taki jak przedstawiony na rysunku6.2 i przesyła do klienta w pakiecie informacyjnym.Zaznaczyć należy, że powyższe założenia odnośnie braku poślizgu i stałego kontaktu z podłożemw rzeczywistości nie są spełnione, przez co pomiar pozycji i orientacji robota staje sięmniej dokładny wraz z przebytą drogą, dlatego też powinien on być wykorzystywany jedyniena niewielkich dystansach. Wyzerowanie wartości pozycji i orientacji możliwe jest poprzezwysłanie do robota komendy SET0.

20 Sterowanie i systemy sensoryczne robotów Pioneer i PeopleBotRysunek 6.2: Wewnętrzny układ współrzędnych Pioneera.

Rozdział 7Symulator robotów Pioneer i PeopleBot –architektura i struktury danychNiniejszy rozdział przedstawia ogólną strukturę poszczególnych części wchodzących w składsymulatora Simbo. Jak widać na rysunku 7.1, struktura ta jest modułowa. Główna jego częśćzawiera interfejs użytkownika oraz obsługuje proces symulacji i wizualizację sceny. Moduływ postaci pluginów Qt zawierać mogą implementacje różnych typów sensorów lub procesorówrobotów. Procesorem w tym kontekście nazywany jest program sterujący zachowaniem robota,przy czym może to być program pasywny przyjmujący polecenia z zewnętrznego sterownika(rys. 7.2) poprzez określony protokół komunikacji i przetwarzający je na konkretne zachowanierobota. Tego typu rozwiązanie zastosowano w procesorze Pioneera, do którego poprzez portTCP może się podłączyć program sterownika, a komunikacja odbywa się poprzez standardowyprotokół Pioneera. Dzięki temu ten sam sterownik może kontrolować zarówno rzeczywistegorobota jak i model w symulatorze. Taka struktura umożliwia łatwą modyfikację i rozbudowędostępnych sensorów i robotów oraz pozwala odseparować niskopoziomowe sterowanie poszczególnymiprzegubami robota od poleceń zawartych w protokole komunikacji.7.1 SymulatorSimbo składa się z dwóch podstawowych grup klas — pierwsza dotyczy interfejsu użytkownikai zawiera klasy opisujące poszczególne okienka programu (w tym wizualizację sceny);druga dotyczy symulacji i zawiera klasy opisujące obiekty na scenie. Przepływ danych pomiędzyposzczególnymi klasami symulatora (realizowany głównie przy pomocy sygnałów Qt)oraz najważniejsze właściwości i metody poszczególnych klas przedstawiono na rysunku 7.3.Wyróżnić można następujące klasy:• MainWindow, JointsWindow, SensorsWindow, SettingsWindowTe klasy opisują poszczególne okna aplikacji oraz definiują funkcjonalność opcji dostępnychw tych oknach. W przypadku MainWindow, klasa odpowiada również za wizualizacjęsceny oraz funkcje z tym związane (np. zaznaczenie obiektu na scenie).• SimulatorClassKlasa obsługująca cały proces symulacji. Zawiera szereg metod pozwalających zmieniaćparametry symulacji, wykrywać kolizje (w tym kolizje przeprowadzane na żądaniesensorów) oraz w sposób natychmiastowy modyfikować pozycję i orientację obiektów, atakże położenie przegubów.

22 Symulator robotów Pioneer i PeopleBot – architektura i struktury danychRysunek 7.1: Podstawowa architektura symulatora Simbo.Rysunek 7.2: Architektura symulatora Simbo z rozdzieleniem procesora i sterownika.

7.1 Symulator 23Rysunek 7.3: Diagram klas symulatora.

24 Symulator robotów Pioneer i PeopleBot – architektura i struktury danych• ObjectPodstawowa klasa opisująca pojedynczy obiekt na scenie. Obiektem nazywany jest zestawbrył sztywnych (elementów) połączonych przegubami, którego zachowanie jakocałości może być kontrolowane przez oddzielny program ("procesor robota"); ponadtoobiekt może zawierać szereg sensorów, z których dane mogą być odczytywane przez procesor.Należy pamiętać, iż elementy należące do tego samego obiektu nie mogą ze sobąkolidować. Dzięki temu detekcja kolizji jest szybsza, a modelowanie obiektów łatwiejsze(łącząc elementy obiektu nie trzeba uważać na kolizje pomiędzy nimi).• ElementKlasa opisuje pojedynczą bryłę sztywną; zawiera informacje o wszystkich bryłach geometrycznych,które definiują kształt całego elementu.• SensorKlasa ta jest jedynie interfejsem dla zewnętrznych pluginów Qt implementujących właściwąfunkcjonalność poszczególnych sensorów.• ProcessorPodobnie jak powyższa, również ta klasa jest jedynie interfejsem dla zewnętrznych pluginówQt, ale dotyczy ona implementacji procesorów robotów.• X3DParserKlasa pomocnicza wykorzystywana przy wczytywaniu modelu obiektu. Wczytuje i przetwarzaplik X3D, tworząc na jego podstawie obiekt gotowy do wykorzystania przez symulator.7.2 SensorySensory umożliwiają robotowi uzyskiwanie informacji o otoczeniu. Są one wirtualnymi obiektamii nie posiadają konkretnej reprezentacji graficznej. Zamiast tego sensor może być przypisanydo dowolnej bryły geometrycznej będącej częścią elementu obiektu, co spowoduje, żejego pozycja i orientacja zawsze będzie taka jak fragment elementu do którego został on przyłączony.W Simbo sensory zostały zrealizowane w postaci zewnętrznych pluginów Qt, które sąwczytywane w momencie, gdy model je wykorzystujący zostanie wczytany. Ogólny interfejssensorów zawiera w sobie następujące metody:• virtual Sensor *Sensor::createInstance() = 0Wczytanie biblioteki może nastąpić jedynie raz i tworzona jest pojedyncza instancja tejbiblioteki. Ponieważ sensorów danego typu może istnieć wiele jednocześnie, koniecznajest ta metoda, która pozwoli stworzyć kolejne instancje plugina. Typowa implementacjatej metody to:Sensor *PrzykladowySensor::createInstance() {return new PrzykladowySensor;}• virtual void Sensor::InitSensor() = 0Metoda ta wywoływana jest po utworzeniu sensora i podłączeniu sygnałów sensora zeslotami symulatora. Pozwala ona zainicjować zmienne sensora.

7.2 Sensory 25• virtual QByteArray Sensor::GetOutput() = 0Ta metoda wywoływana jest, gdy sensor powinien przesłać swój odczyt do procesora.Informacja jest ciągiem bajtów, a jej interpretacja jest w pełni zależna od sensora.• virtual void Sensor::TimeTick() = 0Metoda wywoływana jest co 40ms i odmierza upływ czasu symulacji. Pozwala okresowowykonywać dowolne czynności. Metoda nie jest wywoływana, jeśli symulacja jestwstrzymana.• virtual void Sensor::NewTimeInterval(float interval) = 0Metoda wywoływana jest, gdy zmianie ulegnie interwał czasu symulowany podczas jednejiteracji symulacji. Wartość interwału równa jest iloczynowi szybkości i precyzji symulacjiustawionych w opcjach symulatora.• virtual void Sensor::SensorMoved() = 0Metoda wywoływana jest za każdym razem, gdy zmieni się pozycja lub orientacja sensora.Jest ona wywoływana za każdym razem zaraz przed wywołaniem TimeTick(), aledodatkowo wywoływana jest również, gdy obiekt zostanie przesunięty poprzez edycjęjego pozycji.• virtual void Sensor::CollisionCheckResult(QVector hits) = 0Sensor może zażądać od symulatora przeprowadzenia detekcji kolizji wirtualnej bryły odowolnym kształcie z obiektami na scenie. Detekcja kolizji pomija obiekt, do któregonależy sensor. Żądanie zgłaszane jest poprzez wysłanie następującego sygnału:void Sensor::RequestCollisionCheck(Sensor *sensor, dGeomID geom,unsigned int hitpoints)Po przeprowadzeniu kolizji, symulator wywołuje w sensorze metodę CollisionCheckResult()zawierającą dane o wszystkich znalezionych punktach.• virtual void Sensor::ReceivedCommand(QByteArray command) = 0Ta metoda wywoływana jest przez procesor i umożliwa ona wysłanie dowolnego ciągubajtów do sensora. Może ona posłużyć np. do włączenia lub wyłączenia sensora lubzmiany jego parametrów pracy.• virtual void Sensor::ActorAdded(void *actor) = 0,virtual void Sensor::ActorRemoved(void *actor) = 0Te metody wywoływane są przez symulator, gdy aktor zostanie dodany do sceny/usuniętyze sceny. Umożliwia to sensorom takim jak kamery uaktualnienie własnej kopii reprezentacjisceny.Wszystkie powyższe metody są wirtualne i muszą zostać zaimplementowane w pluginie.Ponadto każdy sensor posiada kilka zmiennych zawierających podstawowe dane. Są to:• NameZmienna zawiera nazwę sensora, ustawiana jest ona automatycznie przez symulator napodstawie nazwy podanej w pliku modelu robota.

26 Symulator robotów Pioneer i PeopleBot – architektura i struktury danych• TypeZmienna zawiera typ sensora, jest to nazwa pliku plugina niezawierająca rozszerzenia.Jest ona ustawiana automatycznie przez symulator.• ParentGeomZmienna zawiera wskaźnik na geom (podstawową bryłę geometryczną) do którego sensorzostał przypisany. Jest ona ustawiana automatycznie przez symulator.• RendererZmienna zawiera wskaźnik do głównego renderera sceny, umożliwiający sensorom tworzeniedodatkowych efektów wizualizacyjnych (np. promienia dalmierza laserowego).Zmienna jest ustawiana automatycznie przez symulator.• InfoBoxJedyna zmienna, która nie jest modyfikowana przez symulator. Plugin sensora może doniej przypisać widgeta Qt zawierającego dowolne opcje oraz odczyty sensora. Ten widgetumieszczany jest w oknie odczytu sensorów.Szczegółowy opis implementacji sensora został przedstawiony w dodatku B na przykładziedalmierza laserowego.7.3 ProcesoryProcesor w Simbo jest wirtualnym odpowiednikiem oprogramowania funkcjonującego w robocie,a więc sprawuje on bezpośrednią kontrolę nad zachowaniem robota. Jest on pluginem Qt,który poprzez określony interfejs może wpływać na przeguby robota oraz odczytywać dane zsensorów. Procesor może aktywnie kontrolować zachowanie robota, lub jedynie przyjmowaćpolecenia od innej aplikacji (sterownika) i przetwarzać je na odpowiednie zachowanie robota.Drugi sposób umożliwia wykorzystanie sterowników dostosowanych do rzeczywistych robotówi połączenie ich z wirtualnym procesorem, a tym samym sterowanie robotem w symulatorze.Ogólny interfejs procesora zawiera w sobie następujące metody:• virtual Processor *Processor::createInstance() = 0Wczytanie biblioteki może nastąpić jedynie raz i tworzona jest pojedyncza instancja tejbiblioteki. Ponieważ procesorów danego typu może istnieć wiele jednocześnie, koniecznajest ta metoda, która pozwoli stworzyć kolejne instancje plugina. Typowa implementacjatej metody to:Processor *ProcesorRobota::createInstance() {return new ProcesorRobota;}• virtual void Processor::Init() = 0Metoda wywoływana po utworzeniu procesora i podłączeniu jego sygnałów i slotów.Umożliwia inicjalizację zmiennych procesora.• virtual void Processor::CPUtick() = 0Metoda wywoływana po każdej iteracji symulacji, odmierzająca upływ czasu symulacji.Metoda nie jest wywoływana, jeśli symulacja jest wstrzymana.

7.3 Procesory 27• virtual void Processor::NewTimeInterval(float interval) = 0Metoda wywoływana jest po wczytaniu modelu obiektu oraz za każdym razem, gdy zmianieulegnie interwał czasu symulowany podczas jednej iteracji symulacji (interwał tenrówny jest iloczynowi szybkości i precyzji symulacji ustawionych w opcjach symulatora).• virtual void Processor::ReceivedSensorData(QString sensorname,QString sensortype,QByteArray data) = 0Metoda wywoływana jest podczas każdej iteracji symulacji dla każdego sensora. Umożliwiaona procesorowi przetworzenie danych przysłanych przez sensory, dla każdego podającjego nazwę, typ oraz ciąg bajtów uzyskany metodą GetOutput().• virtual void Processor::PauseRobot(bool state) = 0Metoda wywoływana jest w procesorze, gdy symulacja zostanie wstrzymana lub wznowiona,z odpowiednią wartością określającą nowy stan symulacji.Wszystkie powyższe metody są wirtualne i muszą zostać zaimplementowane w pluginie.Ponadto procesor może wysyłać trzy sygnału, które pozwalają na kontrolę zachowania robotaoraz sensorów. Są to:• void Processor::SetJointForce(QString jointname, float force)Wysłanie tego sygnału spowoduje ustawienie nowej wartości maksymalnej siły jaką przegubmoże wygenerować, aby osiągnąć zadaną prędkość. Nazwa przegubu jest równoznacznaz nazwą zdefiniowaną w pliku modelu.• void Processor::SetJointVelocity(QString jointname, float velocity)Wysłanie tego sygnału spowoduje zadanie nowej wartości prędkości dla przegubu. Nazwaprzegubu jest równoznaczna z nazwą zdefiniowaną w pliku modelu.• void Processor::SendCommandToSensor(QString sensorname,QByteArray command)Wysłanie tego sygnału umożliwia przekazanie dowolnego ciągu bajtów do sensora o podanejnazwie. Umożliwia to bezpośrednie kontrolowanie zachowania sensorów przezprocesor.

Rozdział 8Realizacja interfejsu użytkownika – opisfunkcjonalnościNiniejszy rozdział zawiera kompletny opis opcji udostępnianych przez symulator Simbo orazedytor modeli SimboEd.8.1 SimboPo uruchomieniu programu pojawia się główne okno aplikacji (patrz rys. 8.1). Korzystającz opcji menu użytkownik może wczytywać modele oraz sprawdzać i modyfikować ustawieniasymulacji. Niektóre z tych opcji wymagają zaznaczenia elementu obiektu na scenie —odbywa się to poprzez dwukrotne kliknięcie myszą na wybranym elemencie. Domyślnie aktualniewybrany element jest oznaczany kolorem czerwonym. Odznaczenie elementu dokonujesię poprzez dwukrotne kliknięcie na pustym obszarze w oknie wizualizacji sceny.Nawigacja w oknie wizualizacji sceny odbywa się przy wykorzystaniu myszy; przytrzymująclewy klawisz oraz przesuwając myszą można obracać widok wokół ogniska kamery.Analogiczna akcja z prawym klawiszem myszy pozwala przybliżać lub oddalać kamerę od jejogniska. Natomiast ruch myszy z jednoczesnym przytrzymaniem obu klawiszy myszy umożliwiaprzesuwanie kamery w płaszczyźnie ekranu. Ponadto nawigację ułatwia kilka skrótówklawiszowych:• klawisz W – przełącza wizualizację na wyświetlanie jedynie konturów obiektów,• klawisz S – przełącza wizualizację na wyświetlanie pełnych obiektów (domyślny stan),• klawisz 3 – włącza/wyłącza stereograficzną wizualizację (złożenie koloru czerwonego iniebieskiego),• klawisz F – ustawia ognisko kamery na punkcie sceny wskazanym przez kursor myszy,• klawisz P – wyświetla prostopadłościan opisany na bryle wskazanej przez kursor myszy,• klawisz R – ustawia kamerę, tak by widoczne były wszystkie obiekty na scenie,• Spacja – wstrzymuje/wznawia symulację (analogicznie jak kliknięcie na opcji stanu symulacjiponiżej obszaru wizualizacji).Poniżej opisano zastosowanie poszczególnych opcji.

30 Realizacja interfejsu użytkownika – opis funkcjonalnościRysunek 8.1: Główne okno symulatora Simbo.8.1.1 PlikWczytaj modelOpcja pozwala na wczytanie wybranego modelu X3D do symulatora. Model rozumiany jest tujako zestaw brył sztywnych, które połączone są ze sobą przegubami. Po wybraniu pliku modelupojawia się kolejne okienko wyboru procesora dla tego obiektu. Jeśli obiekt nie wymagaprocesora (nie ma być sterowany), to można anulować ten wybór. Tę opcję można wywołaćkorzystając ze skrótu klawiszowego Ctrl+M.Wczytaj scenęOpcja pozwala na wczytanie zapisanej wcześniej sceny (plik *.sce) do symulatora. Scena jestzestawem modeli w określonej konfiguracji (pozycja oraz orientacja). Ta opcja nie usuwawcześniej wczytanych modeli. Tę opcję można wywołać korzystając ze skrótu klawiszowegoCtrl+L.Zapisz scenęOpcja pozwala na zapisanie modeli aktualnie istniejących na scenie do pliku *.sce. Dla każdegomodelu zapisywana jest nazwa jego pliku X3D (a więc do poprawnego odczytu sceny koniecznejest istnienie tego pliku) oraz pozycja i orientacja. Tę opcję można wywołać korzystając zeskrótu klawiszowego Ctrl+S.Wyczyść środowiskoOpcja usuwa wszystkie modele ze sceny. Tę opcję można wywołać korzystając ze skrótu klawiszowegoCtrl+N.WyjścieOpcja kończy działanie aplikacji.

8.1 Simbo 31Rysunek 8.2: Okno opcji obiektu.Rysunek 8.3: Okno odczytów sensorów.8.1.2 SymulacjaOpcje obiektuWybranie tej opcji otwiera okno modyfikacji obiektu (patrz rys. 8.2). Jeśli użytkownik wybrałobiekt na scenie, to w tym oknie wyświetlona zostanie pozycja oraz orientacja zaznaczonegoobiektu, a także wszelkie przeguby, które łączą wybrany element z sąsiednimi elementami zaznaczonegoobiektu, wraz z opisem ich nazwy, typu oraz aktualnej pozycji. Ponadto przycisk"Uczyń obiekt statycznym"pozwala zmienić stan zaznaczonego elementu na statyczny; tegotypu element zawsze posiada zerową prędkość (nie porusza się), ale może wciąż kolidowaćz innymi niestatycznymi obiektami. Zmiany wprowadzone w tym oknie są natychmiastowoprzekazywane do symulatora.Odczyty sensorówWybranie tej opcji otwiera okno odczytów sensorów (patrz rys. 8.3). Jeśli użytkownik wybrałobiekt na scenie, to w rozwijanym menu zawarta będzie lista wszystkich sensorów należącychdo tego obiektu. Wybranie któregokolwiek z tych sensorów spowoduje wyświetlenie jegookienka informacyjnego poniżej.

32 Realizacja interfejsu użytkownika – opis funkcjonalnościRysunek 8.4: Okno opcji wizualizacji.8.1.3 OpcjeWizualizacjaZakładka opcji wizualizacji (patrz rys. 8.4) pozwala określić kolory jakimi mają być oznaczone:tło sceny, obiekty niezaznaczone, zaznaczone oraz statyczne. Ponadto umożliwia onawłączenie lub wyłączenie dodatkowych opcji wizualizacji (natychmiastowe renderowanie orazużycie 32-bitowych tekstur), które mogą mieć wpływ na szybkość symulacji. Przycisk "Domyślne"przywracadomyślne wartości tych opcji.SymulatorZakładka opcji symulatora (patrz rys. 8.5) pozwala określić parametry symulacji. Parametry,które można zmodyfikować, zostały opisane poniżej.• Wektor grawitacji – Wektor (x,y,z) określający kierunek siły grawitacji.• Miękkość powierzchni – Parametr określający dopuszczalną głębokość penetracji przykolizji. Ustawienie niewielkiej dodatniej wartości zapobiega drganiu obiektów na skutekciągłego tworzenia i zrywania kontaktu.• CFM (Constraint Force Mixing) – Parametr oznaczający elastyczność przegubów. Zwiększanietej wartości zmniejsza siłę ograniczeń wprowadzanych przez przeguby i może zredukowaćbłędy numeryczne symulacji.• ERP (Error Reduction Parameter) – W każdym kroku symulacji przeprowadzana jest korekcjaprzegubów, które osiągnęły niedozwoloną pozycję. ERP oznacza maksymalną siłęjaka może być wygenerowana w celu przeprowadzenia korekcji. Sugerowane wartościpowinny być w przedziale 0,1 – 0,8.

8.2 SimboEd 33• Szybkość symulacji – Wartość oznacza ilość kroków ODE wykonywanych w każdym cyklusymulatora (1 cykl symulatora trwa 40ms). Zwiększenie tej wartości pozwala przyspieszyćsymulację, kosztem obciążenia procesora.• Krok symulacji – Wartość podawana w sekundach, oznacza ile czasu w symulatorzeupływa podczas jednego kroku ODE. Mniejsze wartości zwiększają dokładność obliczeń.Aby uzyskać czas rzeczywisty, krok symulacji musi być równy25∗τ 1 , gdzie τ – szybkośćsymulacji. Zalecana wartość powinna być dużo mniejsza od jedności.• Włącz blokowanie – Opcja blokowania obiektów. Jeśli zostanie włączona, to podczaskażdego kroku symulacji obiekty, które spełniają poniższe warunki zostaną zablokowanei nie będą analizowane przez symulator, przyspieszając obliczenia. Obiekty są automatycznieodblokowywane, jeśli zderzą się z innymi obiektami.• Ilość kroków – Minimalna ilość kroków symulacji przez jaką poniższe progi muszą byćspełnione, aby obiekt został zablokowany.• Czas – Minimalny czas symulacji przez jaki poniższe progi muszą być spełnione, abyobiekt został zablokowany.• Próg prędkości liniowej – Jeśli przez ustaloną ilość kroków prędkość liniowa obiektubędzie mniejsza niż podana wartość, to obiekt zostanie zablokowany.• Próg prędkości kątowej – Jeśli przez ustaloną ilość kroków prędkość kątowa obiektu będziemniejsza niż podana wartość, to obiekt zostanie zablokowany.• Nieskończone tarcie – Zaznaczenie tego pola powoduje ustawienie nieskończonego tarcia.• Tarcie – Pole pozwala na wprowadzenie wartości współczynnika tarcia powierzchni.• Sprężystość – Pole pozwala na wprowadzenie współczynnika sprężystości powierzchni wzakresie 0,0 – 1,0. Wartość 0 oznacza brak odbicia, wartość 1 oznacza odbicie doskonalesprężyste.• Prędkość odbicia – Minimalna prędkość przy jakiej zachodzi odbicie. Zderzenia poniżejtej prędkości będą miały parametr sprężystości równy 0.SystemZakładka opcji systemowych (patrz rys. 8.6) pozwala określić ścieżki do katalogów zawierającychsensory oraz tekstury.8.2 SimboEdSimboEd jest programem umożliwiającym graficzną edycję i zapis modeli X3D. Jest on przystosowanydo symulatora Simbo i obsługuje jedynie zestawy węzłów X3D kompatybilnych znim.Po uruchomieniu programu pojawia się główne okno aplikacji (patrz rys. 8.7). Nawigacjapo scenie odbywa się w analogiczny sposób jak w przypadku symulatora Simbo. Natomiastinna jest kolorystyka elementów na scenie. Bryły (zwane w ODE geomami) należące do tego

34 Realizacja interfejsu użytkownika – opis funkcjonalnościRysunek 8.5: Okno opcji symulacji.Rysunek 8.6: Okno opcji systemowych.

8.2 SimboEd 35Rysunek 8.7: Główne okno edytora.samego elementu (zwanego w ODE ciałem) będą wizualizowane tym samym kolorem, co pozwalaje w łatwy sposób rozróżnić. Zaznaczone bryły podobnie jak w symulatorze oznaczanesą kolorem czerwonym, ale, w przeciwieństwie do symulatora, zaznaczenie ogranicza się dosamej bryły, a nie elementu, którego jest ona częścią. Również przeguby można zaznaczać wtakim sam sposób jak bryły.Zastosowanie poszczególnych opcji programu opisano poniżej.8.2.1 PlikNowyWybranie tej opcji usuwa ze sceny edytora dotychczas utworzone obiekty.WczytajWybranie tej opcji pozwala na wczytanie wcześniej utworzonego modelu X3D.ZapiszWybranie tej opcji pozwala na zapisanie aktualnego obiektu do formatu modelu X3D.WyjścieWybranie tej opcji kończy działanie edytora.8.2.2 DodajProstopadłościan, Cylinder, KulaWybranie którejkolwiek z tych opcji wyświetla nowe okienko (patrz rys. 8.8), w którym możnawpisać nazwę tworzonej bryły oraz określić jej wymiary. Pozostawienie pustych pól wymiarówpowoduje przypisanie bryle domyślnych wartości. Jeśli przy zatwierdzaniu opcji tworzenia

36 Realizacja interfejsu użytkownika – opis funkcjonalnościRysunek 8.8: a) Okno tworzenia nowego geomu. b) Okno tworzenia nowego przegubu.nie jest zaznaczona żadna bryła, to utworzona bryła stanie się jednocześnie częścią nowego elementu,w przeciwnym razie zostanie ona przypisana do elementu, do którego należy zaznaczonabryła.Przegub obrotowy, Przegub przesuwnyWybraniej tych opcji wyświetla nowe okienko (patrz rys. 8.8), w którym można określić parametryprzegubu.Kotwica ma zastosowanie jedynie w przypadku przegubu obrotowego i określa punkt wprzestrzeni wokół którego przegub będzie się obracał. Zaznaczenie opcji automatycznego określeniakotwicy powoduje ustawienie tego punktu w połowie odległości pomiędzy środkami elementów,które przegub łączy.Oś obrotu oznacza wektor (x,y,z) wzdłuż lub wokół którego przegub będzie się poruszał.Puste pola są równoznaczne z wpisaniem wartości 0.Dolny i górny limit definiują ograniczenia pozycji jakie przegub może osiągać. W przypadkuprzegubu obrotowego wartość podawana jest w stopniach i powinna zawierać się w przedzialeod -180 do 180. Pozostawienie pustego pola limitu oznacza brak limitu.Aby poprawnie połączyć dwa elementy należy zaznaczyć dowolną bryłę pierwszego z nich,następnie kliknąć przycisk "Ustaw ciało 1", potem zaznaczyć dowolną bryłę drugiego z nichi kliknąć przycisk "Ustaw ciało 2". Po wykonaniu tej czynności oraz ustawieniu żądanychparametrów przegubu można zatwierdzić tworzenie przegubu przyciskiem "OK".Aby przegub został poprawnie zapisany, każdy z elementów, które on łączy, musi miećokreśloną unikalną nazwę definiowaną w opcji edycji ciała.8.2.3 EdytujCiałoWybraniej opcji edycji ciała otwiera nowe okienko (patrz rys. 8.9), które pozwala użytkownikowiokreślić nazwę, masę oraz środek masy elementu do którego należy aktualnie zaznaczonabryła. Przypisanie unikatowej nazwy do elementu jest niezbędne, jeśli jest on połączony przegubamiz innymi elementami.Dodatkowo przy pomocy przycisku "Połącz"można połączyć dwa niezależne elementy wjeden. Aby tego dokonać należy zaznaczyć element, który ma zostać przyłączony, następniekliknąć ten przycisk, a potem wybrać element do którego zostanie on przyłączony i ponowniekliknąć przycisk połączenia. Wszelkie przeguby istniejące pomiędzy łączonymi ciałami sąautomatycznie usuwane.

8.2 SimboEd 37Rysunek 8.9: a) Okno edycji ciała. b) Okno edycji geomu.GeomWybranie opcji edycji geomu otwiera nowe okienko (patrz rys. 8.9) umożliwiające modyfikacjęparametrów aktualnie zaznaczonej bryły. Są to:• Nazwa – Dowolny ciąg znaków identyfikujący bryłę (jeśli do bryły zostanie przypisanysensor, to jego nazwa będzie równoznaczna z nazwą tej bryły),• Wymiary/Promień/Wysokość – W zależności od typu zaznaczonej bryły te opcje pozwalajązmieniać jej rozmiar,• Pozycja – Pozycja (x,y,z) zaznaczonej bryły,• Orientacja – Orientacja zaznaczonej bryły podawana w kolejności (ox, oy, oz), ale wykonywanaw kolejności (oz, oy, ox),• Sensor – Nazwa pliku biblioteki sensora przypisanego do zaznaczonej bryły (przycisk"..."pozwala wybrać bibliotekę z listy plików; pozostawienie pustego pola oznacza brakprzypisanego sensora).PrzegubWybranie opcji edycji przegubu otwiera nowe okienko (patrz rys. 8.10) umożliwiające modyfikacjęparametrów aktualnie zaznaczonego przegubu. Parametry możliwe do edycji są takiesame jak parametry podawane przy tworzeniu przegubu.TeksturaOpcja edycji tekstury wyświetla okienko (patrz rys. 8.10) umożliwiające przypisanie do bryłypliku tekstury (akceptowane formaty to JPG lub PNG) oraz określenie translacji i skali tej tekstury.GrupaWybranie tej opcji włącza tryb edycji grup oraz wyświetla okienko opcji grupy (patrz rys. 8.11).W tym trybie wszystkie bryły przedstawione są w kolorze białym. Dwukrotnie kliknięcie naktórejkolwiek bryle powoduje zaznaczenie całej grupy elementów do której należy elementzawierający wybraną bryłę (zaznaczona grupa zmieni kolor na czerwony, a zaznaczona bryła

38 Realizacja interfejsu użytkownika – opis funkcjonalnościRysunek 8.10: a) Okno edycji przegubu. b) Okno edycji tekstury.Rysunek 8.11: a) Okno edycji grupy. b) Okno edycji nagłówka.na ciemnoczerwony). Jeśli element nie należy do żadnej grupy, to jedynie wybrana bryła zmienikolor na ciemnoczerwony.Gdy wczytywany jest model, automatycznie tworzona jest nowa grupa oraz wszelkie elementywchodzące w jego skład są dodawane do niej. Ponadto przycisk "Usuń"pozwala usunąćz grupy element, do którego należy aktualnie zaznaczona bryła. Natomiast po kliknięciu przycisku"Dodaj", zaznaczeniu grupy oraz ponownym jego kliknięciu, pierwotnie zaznaczony elementzostanie przypisany do wybranej grupy. Jeśli element należał do innej grupy, to zostanienajpierw z niej usunięty. Jeśli element przypisywany jest do elementu nienależącego do grupy,to tworzona jest nowa grupa zawierająca oba elementy.Opcja pozycji pozwala przesuwać wszystkie elementy należące do aktualnie zaznaczonejgrupy jednocześnie.NagłówekWybranie tej opcji wyświetla okienko edycji nagłówka (patrz rys. 8.11), gdzie wprowadzićmożna informacje o autorze i nazwie modelu oraz krótki jego opis.Usuń zaznaczonyWybranie tej opcji spowoduje usunięcie zaznaczonej bryły. Tę opcję można wywołać korzystającze skrótu klawiszowego Delete.

8.2 SimboEd 398.2.4 UstawieniaSystemWybranie tej opcji otwiera okienko (patrz rys. 8.12) umożliwiające określenie ścieżek do katalogówsensorów, modeli i tekstur.Rysunek 8.12: Okno opcji systemowych.Użycie edytora SimboEd na przykładzie budowania modelu kamery stereowizyjnej zostałozaprezentowane w dodatku A.

Rozdział 9Pakiety oprogramowania przeznaczone dosterowania robotamiZagadnienie komunikacji z robotem jest problemem niskopoziomowym, który powinien w jaknajmniejszym stopniu dotyczyć użytkownika zamierzającego maszyną sterować. W tym celutworzone są pakiety oprogramowania ułatwiające komunikację z robotami. MobileRobots, producentPioneera udostępnia pakiet Aria (Advanced Robot Interface for Applications), który jestbiblioteką C++ pośredniczącą w komunikacji pomiędzy sterownikiem a robotem. Innym pakietemo bardziej ogólnym przeznaczeniu jest UNIFRACX (UNIfied FRame for ACtions eXecution),pozwalający na tworzenie uniwersalnych scenariuszy zachowań, które następnie tłumaczonesą na polecenia dla konkretnych robotów. W niniejszym rozdziale opisano możliwościsterowania oraz ułatwienia komunikacji wynikające ze stosowania tych pakietów.9.1 AriaAria [11] jest uniwersalną biblioteką dla wszystkich robotów MobileRobots. Posiada ona szeregplików konfiguracyjnych opisujących parametry poszczególnych typów robotów takie jakfizyczne wymiary, a po nawiązaniu połączenia z robotem i uzyskaniu od niego pakietu konfiguracyjnego(zawierającego m.in. typ i model robota) automatycznie wyszukuje odpowiedniplik zawierający dane robota. Na podstawie pakietu konfiguracyjnego robota Aria weryfikujerównież obecność różnych typów sensorów zamontowanych na robocie. Dzięki takiemu odseparowaniuwarstwy komunikacji od warstwy sterowania możliwe jest pisanie sterownikówkompatybilnych z różnymi robotami.Przykładem takiej separacji może być metoda ArRobot::getClosestSonarRange() — wymagaona podania dwóch kątów, określających przedział, w którym sprawdzony zostanie dystansdo najbliższej przeszkody. Oczywiście, aby ją użyć, konieczna jest obecność sonarówna robocie, ale ich ilość i rozmieszczenie są nieistotne z poziomu wywołania tej funkcji. Ariaautomatycznie wybierze sonary, których zasięg pokrywa się z podanym przedziałem kątów izwróci odczyt wskazujący na najbliższą przeszkodę.Ponadto Aria zawiera gotowe akcje wspomagające nawigację. Są to klasy C++ takie jakArActionStallRecover, ArActionBumpers, ArActionAvoidFront lub ArActionConstantVelocity.Każda z nich posiada szereg parametrów, którymi można modyfikować sposób jej działania;przykładowo akcja unikania kolizji pozwala okreslić dystans na jaki robot może zbliżyć się doprzeszkody, zanim rozpocznie manewr jej omijania. Akcje można przypisywać robotowi metodąArRobot::addAction(), która pozwala również zdefiniować priorytet, więc możliwe jesttworzenie w prosty sposób złożonych zachowań robota.Pakiet Arii zawiera zestaw około 40 przykładowych programów prezentujących różnorodne

42 Pakiety oprogramowania przeznaczone do sterowania robotamifunkcje robotów — od prostych rozkazów ruchu lub okresowego wypisywania odczytów z sensorów,do przykładów zawierających pełne sterowanie robotem z wykorzystaniem dostępnychsensorów do unikania przeszkód. Dzięki temu możliwe jest łatwe przetestowanie funkcjonowaniabiblioteki z robotem oraz dalsze rozwijanie istniejących przykładów, by dostosować jedo własnych potrzeb.Aria domyślnie próbuje nawiązać połączenie przez port szeregowy komputera, jednakżeistnieje możliwość wskazania portu TCP z którym sterownik powinien się połączyć. Jest toszczególnie przydatne w przypadku symulatorów, gdyż pozwala symulować wiele robotów wjednym wirtualnym środowisku, a każdy z nich może być kontrolowany przez oddzielny sterownikkomunikujący się na innym porcie TCP.Pomimo iż Aria jest napisana w języku C++, to oprogramowanie z niej korzystające możnapisać również w Pythonie oraz Javie. W takiej sytuacji wykorzystać należy odpowiednie warstwyinterpretujące kod tych języków na wywołania metod Arii.9.2 UNIFRACXUNIFRACX [8] jest projektem definiującym jednolitą metodę opisu akcji dowolnego robota.Zestawy takich akcji można następnie dowolnie zestawiać budując tzw. scenariusze zachowania.Implementacja poszczególnych akcji odbywa się na poziomie bibliotek C++. Pojedynczabiblioteka musi już uwzględniać protokół komunikacji z robotem, a więc jej zastosowanie ograniczasię do danego modelu maszyny (lub innych podobnych). Tym niemniej dzięki XMLowymplikom określającym przypisania poszczególnych akcji do funkcji bibliotek je obsługującychmożna w łatwy sposób zmieniać sposób sterowania, a więc i docelowego robota.Oprócz zapewnienia spójnego zestawu akcji, UNIFRACX również posiada określone typyoraz jednostki danych wykorzystywane przy definiowaniu argumentów dla poszczególnych akcji.Wyróżnić można takie jednostki jak:• jednostka dystansu (mm, cm, m),• jednostka czasu (µs, ms, s, m, h),• jednostka prędkości ( mm s , cm s , m s ),• jednostka przyspieszenia ( mms 2 , cms 2 , m s 2 ).Dzięki temu jednostki, w jakich podawane są argumenty akcji w scenariuszach, mogą byćróżne, a w momencie wywołania funkcji biblioteki odpowiadającej danej akcji, zostaną oneprzekonwertowane na wymiar zdefiniowany dla tej funkcji.Z punktu widzenia sterowania robotem poprzez UNIFRACXa, poza samą biblioteką koniecznejest również utworzenie zestawu plików XMLowych, opisujących powiązania funkcjitej biblioteki z odpowiednimi akcjami. Służą do tego takie pliki jak:• plik bibliotekZawiera definicje funkcji należących do poszczególnych, wraz z typami parametrów wymaganymiprzez nie.• plik przypisań akcji do funkcjiDefiniuje przypisania różnorodnych akcji do konkretnych funkcji poszczególnych bibliotekoraz poszczególnych wcieleń.

9.2 UNIFRACX 43• plik wcieleńDefiniuje nazwy spójnych grup łączących w sobie pewną funkcjonalność (np. akcje dotyczącedanego modelu robota)• plik scenariuszaZawiera zestawy akcji, określające zachowanie robota.Procesowi uruchomienia UNIFRACXa towarzyszy podanie jako argumentów ścieżek do każdegoz powyższych plików.

Rozdział 10Integracja symulatora z innymi pakietamioprogramowniaW rozdziale 9 opisano Arię — pakiet producenta Pioneera i PeopleBota, który pozwala odseparowaćpolecenia od bezpośredniego sterowania oraz umożliwia wykorzystanie tego samegoprogramu do kontroli różnych robotów MobileRobots. Przedstawiony został również pakietUNIFRACX udostępniający ogólny zestaw poleceń dla agentów (np. robotów), które następniesą interpretowane na komendy odpowiednie dla konkretnych obiektów będących przedmiotemsterowania. W niniejszym rozdziale opisano proces interacji symulatora z tymi pakietami orazsposób wykorzystania do sterowania robotem w środowisku Simbo.10.1 Integracja z Aria˛Aria przeznaczona jest do komunikacji z robotami poprzez port szeregowy, jednakże możliwejest również nawiązanie połączenia z symulatorem przez port TCP. W tym celu programsterownika (wykorzystujący bibliotekę Arii) należy uruchomić z dodatkowym parametrem-remoteRobotTcpPort (lub w skrócie -rrtp) i numerem portu na którym symulatoroczekuje na połączenie.Symulator Simbo zawiera implementację procesora Pioneera w postaci dynamicznie łączonejbiblioteki. Komunikacja z nią oparta została o oficjalną specyfikację protokołu Pioneera [2],więc z poziomu klienta łączącego się z takim procesorem, nie ma różnicy pomiędzy sterowaniemrobotem rzeczywistym, a robotem w symulatorze — w zakresie komend jakie procesoroferuje. Jest to istotne zastrzeżenie, ponieważ niektóre z komend Pioneera nie mają zastosowaniaw przypadku symulatora (np. GETAUX, gdyż symulator nie obsługuje dźwięków)lub ich funkcjonalność miałaby zastosowanie dopiero po zamontowaniu dodatkowego sprzętu,który nie został zaimplementowany w wersji robota dostępnej w symulatorze (np. zestaw poleceńobsługujących chwytak o pięciu stopniach swobody, tzw. ARM [10]). Tym niemniejprocesor zapewnia obsługę podstawowych poleceń ruchu, odczytywania danych z sensorów,obsługę chwytaka (wersja o dwóch stopniach swobody, tzw. GRIPPER [1]) oraz ogólne poleceniaumożliwiające nawiązanie i utrzymanie połączenia.10.2 Integracja z UNIFRACXemAby umożliwić wykonywanie scenariuszy w symulatorze utworzona została biblioteka C++korzystająca z interfejsu UNIFRACXa. Zawiera ona szereg funkcji implementujących podstawowyzakres poleceń Pioneera i komunikuje się z robotem (rzeczywistym lub symulowanym)

46 Integracja symulatora z innymi pakietami oprogramowniaRysunek 10.1: Struktura symulatora z Arią i UNIFRACXem.przy wykorzystaniu pakietu Arii. Koncepcyjna struktura powiązań pomiędzy poszczególnymielementami została przedstawiona na rysunku 10.1.Utworzona biblioteka UNIFRACXa zawiera następujące funkcje:• int SetSpeed()Funkcja pozwala określić stałą prędkość liniową ruchu robota. Jest odpowiednikiem komendyVEL Pioneera.• int SetRotSpeed()Funkcja pozwala określić stałą prędkość kątową ruchu robota. Jest odpowiednikiem komendyRVEL Pioneera.• int SetHeading()Funkcja pozwala obrócić robota o podany kąt. Jest odpowiednikiem komendy HEADPioneera.• int SetAbsoluteHeading()Funkcja pozwala obrócić robota, tak by jego orientacja osiągnęła podany kąt. Jest odpowiednikiemkomendy DHEAD Pioneera.• int Move()Funkcja spowoduje ruch robota do przodu o podany dystans. Jest odpowiednikiem komendyMOVE Pioneera.• int SetWheelSpeed()Funkcja pozwala niezależnie określić prędkości obrotowe poszczególnych kół robota.Jest odpowiednikiem komendy VEL2 Pioneera.• int Stop()Funkcja pozwala zatrzymać robota (ustawia prędkość liniową i kątową na zero).

10.2 Integracja z UNIFRACXem 47• int Wander()Funkcja inicjuje losowe przemieszczanie robota z unikaniem przeszkód.• int HistogramMoveTo()Funkcja inicjuje ruch robota do celu (współrzędne określone relatywnie do aktualnej pozycji)z unikaniem przeszkód przy wykorzystaniu algorytmu histogramu pola wektorów.• int ForceMoveTo()Funkcja inicjuje ruch robota do celu (współrzędne określone relatywnie do aktualnej pozycji)z unikaniem przeszkód przy wykorzystaniu algorytmu sił wirtualnych.

Rozdział 11Implementacja algorytmów nawigacji zwykorzystaniem pakietu AriaW celu kompleksowego sprawdzenia funkcjonowania symulatora oraz powiązanych z nim zewnętrznychpakietów, utworzono trzy algorytmy sterowania Pioneerem. Niniejszy rozdziałszczegółowo opisuje założenia i sposoby realizacji każdego z nich.11.1 Losowy ruchNajprostszy z prezentowanych algorytmów ma na celu jedynie zastosowanie informacji zwrotnejz sonarów do unikania przeszkód przed robotem. Jeśli w pobliżu Pioneera nie ma przeszkód,to porusza się on ruchem prostoliniowym. Algorytm ten definiuje trzy kierunki — przed robotem,po lewej stronie, po prawej stronie, a dla każdego określa dwa progi odległości — bliskii daleki. Koncepcja detekcji przeszkód tą metodą została przedstawiona na rysunku 11.1. Jakmożna zauważyć robot wykorzystuje jedynie 4 sonary, z których dwa odpowiadają za pomiarodległości od przeszkody po obu stronach Pioneera, a wynik z pozostałych dwóch jest uśrednianyi traktowany jako dystans do przeszkody przed robotem.Progi odległości ustalone zostały odpowiednio na 50cm dla bliskiego dystansu i na 100cmdla dalekiego. Zachowanie robota rozpatrywać można oddzielnie dla prędkości liniowej i oddzielniedla prędkości obrotowej. W pierwszym przypadku w zależności od odległości jest ononastępujące:• Jeśli odległość przed robotem jest większa od dalekiego progu oraz odległości boczne sąwiększe od bliskiego progu, to prędkość liniowa ustalana jest na 20 cm s• W przeciwnym razie jeśli odległość przed robotem jest większa od bliskiego progu, toprędkość liniowa ustalana jest na 10 cm s• W przeciwnym razie prędkość liniowa ustalana jest na 0 cm sNatomiast dla prędkości obrotowej obowiązują poniższe reguły:• Jeśli odległość po lewej stronie jest mniejsza od bliskiego progu, to prędkość obrotowaustalana jest na 30 ◦ s• W przeciwnym wypadku jeśli odległość po prawej stronie jest mniejsza od bliskiegoprogu, to prędkość obrotowa ustalana jest na −30 ◦ s• W przeciwym wypadku jeśli odległość po lewej stronie jest mniejsza, a odległość poprawej stronie jest większa od dalekiego progu, to prędkość obrotowa jest ustalana na 5 ◦ s

50 Implementacja algorytmów nawigacji z wykorzystaniem pakietu AriaRysunek 11.1: Strefy nawigacji robota w algorytmie losowego ruchu.• W przeciwym wypadku jeśli odległość po prawej stronie jest mniejsza, a odległość polewej stronie jest większa od dalekiego progu, to prędkość obrotowa jest ustalana na −5 ◦ s• W przeciwnym wypadku jeśli odległość przed robotem jest mniejsza od bliskiego progu,to prędkość obrotowa jest ustalana na 15 ◦ s(jeśli lewy dystans jest mniejszy od prawego)lub −15 ◦ s(w przeciwnym wypadku)• W przeciwnym wypadku prędkość obrotowa ma wartość 0 ◦ sWartości dodatnie prędkości obrotowych oznaczają kierunek zgodny z ruchem wskazówek zegara,wartości ujemne, oznaczają kierunek przeciwny.11.2 Metoda sił wirtualnychMetoda sił wirtualnych opisana w [12] jest przykładem algorytmu sterującego ruchem robota docelu. Końcowy punkt definiowany jest tu względem aktualnej pozycji robota. Aby umożliwićokreślenie tej pozycji Pioneer wykorzystuje enkodery do zliczania obrotów obu kół i na tejpodstawie wylicza swoje przemieszczenie.Koncepcja działania tego algorytmu została przedstawiona na rysunku 11.2. Wyliczany jestwektor C skierowany do celu, a następnie dla każdej przeszkody w otoczeniu robota wyznaczanyjest wektor P o zwrocie przeciwnym do kierunku, w którym jest ta przeszkoda. Długośćtego wektora jest stała, natomiast długość wektora P jest tym większa, im mniejszy dystansdzieli robota od przeszkody. Następnie wszystkie wektory są sumowane i otrzymuje się wynikowywektor W, który wyznacza kierunek w jakim robot powinien się przemieścić.Uzyskany wektor wypadkowy jest podstawą do wyznaczenia żądanej prędkości obrotoweji liniowej robota. Pierwsza z nich zależy bezpośrednio od kąta jaki Pioneer musi mieć, byjechać w kierunku wyliczonego wektora; robot wykonuje obrót wolniej, gdy kąt, o jaki musisię obrócić, jest niewielki — co pozwala na precyzyjniejsze sterowanie, gdy kierunek ruchujest właściwy. Natomiast prędkość liniowa jest zerowa, gdy kąt, o jaki robot musi się obrócić,jest większy od pewnego progu, a w przeciwnym wypadku jest tym większa, im bliższy jestaktualny kierunek robota kątowi wyznaczonemu przez wektor wypadkowy.

11.3 Algorytm histogramu pola wektorów 51Rysunek 11.2: Koncepcja unikania przeszkód metodą sił wirtualnych.Ponieważ Pioneer wyposażony jest w 16 sonarów, nie można w prosty sposób uzyskać dokładniejszejinformacji o otoczeniu niż dystans do przeszkód w 16 różnych kierunkach. Dlategoteż kąt pełny podzielono na równe sektory mierzące 22.5 ◦ i każdy z nich przypisano do konkretnegosonara. Tego typu rozwiązanie daje stosunkowo niewielką rozdzielczość, więc, abyzminimalizować nagłe zahamowania i zmiany kierunku ruchu robota, w kolejnych implementacjachtego algorytmu zastosowano ograniczenia zmian prędkości robota.11.3 Algorytm histogramu pola wektorówAlgorytm histogramu pola wektorów został zaproponowany przez Johanna Borensteina i YoramaKorena [4]. Podobnie jak w przypadku metody sił wirtualnych, umożliwia on bezkolizyjne sterowanierobotem do celu. Algorytm ten dzieli obszar wokół robota na równomierną siatkę pól,z których każde zawiera liczbę określającą prawdopodobieństwo wystąpienia przeszkody w danymmiejscu. Następnie generowany jest histogram biegunowy składający się z sektorów ookreślonej szerokości kątowej. Przykładowy histogram dla sceny 11.3 przedstawiony został narysunku 11.4. Wartości poszczególnych sektorów wyliczane są na podstawie wartości prawdopodobieństwwystąpienia przeszkód w poszczególnych sektorach w danym kierunku od robotaoraz odległości od nich. Sektory, których wartości przekraczają ustalony próg, oznaczane sąjako sektory zabronione, pozostałe to obszary w kierunku których robot może jechać.Z tak utworzonego histogramu wybierany jest najbliższy dostępny sektor k n (rys. 11.5) wkierunku docelowego punktu (wektor C). Następnie wybierany jest sektor k f oddzielony od k no określoną ilość dostępnych sektorów. Jeśli k n nie sąsiaduje z odpowiednią ilością wolnychsektorów, to k f jest najdalszym z nich, a przejście tego typu określane jest jako wąskie. Napodstawie kierunków definiowanych przez oba sektory wyznaczany jest wektor θ, który określatrajektorię jaką robot powinien przyjąć.Główną zaletą tego algorytmu w porównaniu do metody sił wirtualnych jest możliwośćnawigacji w wąskich przejściach (np. drzwi). Taką sytuację przedstawiono na rysunku 11.6.Mimo niewielkiej odległości pomiędzy przeszkodami, znalezienie dostepnych sektorów po-

52 Implementacja algorytmów nawigacji z wykorzystaniem pakietu AriaRysunek 11.3: Robot w otoczeniu przeszkód.Rysunek 11.4: Histogram dla sceny na rysunku 11.3.

11.3 Algorytm histogramu pola wektorów 53Rysunek 11.5: Wybór kierunku ruchu na podstawie histogramu.zwala na przejazd między nimi. Natomiast w przypadku metody sił wirtualnych, suma siłpochodzących od pobliskich przeszkód może przekroczyć siłę przyciągającą do celu, co w rezultacieuniemożliwi przejazd takim korytarzem.

54 Implementacja algorytmów nawigacji z wykorzystaniem pakietu AriaRysunek 11.6: Porównanie zachowania algorytmów w przypadku wąskiego korytarza pomiędzyprzeszkodami: a) Histogram pola wektorów — dostępne sektory pomiędzy przeszkodamiumożliwiają przejazd b) Metoda sił wirtualnych — suma sił odpychających uniemożliwia robotowiprzejazd do celu.

Rozdział 12Wyniki eksperymentówAlgorytmy opisane w poprzednim rozdziale zostały zaimplementowane w postaci bibliotekUNIFRACXa z wykorzystaniem pakietu Arii. Przy pomocy symulatora Simbo sprawdzonozachowanie robota sterowanego poszczególnymi metodami. Poniżej przedstawiono rezultatytych badań.12.1 Losowy ruchPierwsze badanie losowego ruchu robota wykonano w pustym pomieszczeniu o wymiarach9,5m × 4,6m. Trakejtorię robota przedstawiono na rysunku 12.1. Początkową pozycją Pioneerabył punkt (0 0). Droga, którą przebył robot, jest stosunkowo gładka, wyjątkiem jest jedyniemoment nawracania przy lewej ścianie pomieszczenia, gdy niewielka odległość od przeszkodydoprowadziła do zatrzymania robota i dokończenia obrotu, przed dalszą kontynuacją jazdy.Kolejny przykład losowego ruchu przedstawia zachowanie Pioneera na scenie z czteremaprzeszkodami o wymiarach 80cm × 40cm. Na rysunku 12.2 zaprezentowano robota poruszającegosię tą metodą w środowisku z przeszkodami, natomiast jego trajektorię na tej scenieprzedstawiono na rysunku 12.3. Ruch ponownie został rozpoczęty w punkcie (0 0). Zauważyćmożna większe nierówności trajektorii; przy tak gęstym rozmieszczeniu przeszkód robotwielokrotnie zatrzymywał się, aby zmienić swoją orientację. Ostatecznie wjechał nieznaczniepomiędzy dwie przeszkody, lecz każda dalsza próba ruchu kończyła się wycofaniem, gdyż zakażdym razem dystans do jednej z przeszkód przekraczał minimalny próg bezpieczeństwa.12.2 Metoda sił wirtualnychBadanie zachowania Pioneera sterowanego metodą sił wirtualnych rozpoczęto w pomieszczeniuo wymiarach 9,5m × 4,6m. Robot umieszczony został w punkcie (0 0) i otrzymał zadanie dojechaniado punktu o współrzędnych (−1 1). Trajektorię realizacji tego zadania przedstawionona rysunku 12.4. Po rozpoczęciu ruchu robot skierowany był w przeciwną stronę niż punktdocelowy, więc zawrócił. Następnie skierował się do celu. Zaznaczyć należy również, że punktw którym robot się zatrzymał nie odpowiada dokładnie żądanym współrzędnym celu z dwóchprzyczyn. Pierwsza z nich wynika z faktu, że wyznaczanie pozycji na podstawie enkoderówjest obarczone pewnymi błędami, więc na dłuższych dystansach rzeczywista pozycja Pioneeramoże znacznie różnić się od pozycji, która została obliczona. Druga przyczyna niedokładnościleży w założeniu, że robot osiągnął cel, jeśli znajdzie się w odległości nie większej niż 5cm odniego.Drugi eksperyment przeprowadzono na scenie z kilkoma przeszkodami o wymiarach 80cm× 40cm. Robot ponownie ustawiony został w punkcie (0 0) i otrzymał rozkaz jazdy do punktu

56 Wyniki eksperymentówRysunek 12.1: Trajektoria robota poruszającego się po pustej scenie.Rysunek 12.2: Robot poruszający się po scenie metodą losowego ruchu.

12.2 Metoda sił wirtualnych 57Rysunek 12.3: Trajektoria robota poruszającego się po scenie z dodatkowymi przeszkodami.Rysunek 12.4: Trajektoria robota jadącego do celu przy użyciu metody sił wirtualnych.

58 Wyniki eksperymentówRysunek 12.5: Robot poruszający się po scenie metodą sił wirtualnych.o współrzędnych (−3,5 3). Na rysunku 12.5 zaprezentowano robota wykonującego powyższezadanie, natomiast przebytą drogę przedstawiono na rysunku 12.6. W początkowej fazie ruchuwidoczny jest zwrot robota w kierunku celu. Trajektoria jest gładka, stopniowa zmiana siły przyzbliżaniu się do przeszkód pozwoliła uzyskać łagodną zmianę orientacji robota. Jedynym wyjątkiemjest tu zbliżenie się do przeszkody o współrzędnych (−2 2), gdy Pioneer zatrzymał się,by wykonać obrót i ruch zwiększający jego dystans do celu. Zachowanie to spowodowane byłodużą prędkością liniową oraz kątem pod jakim robot zbliżał się do przeszkody. W rezultacie wkrótkim odcinku czasu wektor odpychający robota od przeszkody znacząco zwiększył swą długość,a konieczność tak znacznej zmiany orientacji robota spowodowała gwałtowną redukcjęprędkości liniowej.Aby zapobiec powyższemu problemowi wprowadzono ograniczenie przyspieszenia liniowegojakiemu może być poddany robot. Test przeprowadzono dla limitu przyspieszenia 5 mm .s 2Wynikowa trajektoria przy takiej samej scenie i zadaniu została przedstawione na rysunku 12.7.Widoczny jest wzrost gładkości drogi przy użyciu bardziej restrykcyjnych ograniczeń zmianyprędkości. Jednakże użyta metoda uniemożliwia robotowi natychmiastowe zatrzymanie się,więc konieczne jest ustalenie odpowiednich limitów odległości od przeszkód, przy których zaczynająone generować siły odpychające, a także określenie wystarczającego przyrostu tych siłwraz ze spadkiem odległości. Zapewni to odpowiednio wczesną modyfikację ruchu robota, takby miał on czas na ewentualną stopniową redukcję swej prędkości.12.3 Histogram pola wektorówPierwszy test zachowania Pioneera przy wykorzystaniu nawigacji metodą histogramu pola wektorówwykonano w pomieszczeniu o wymiarach 9.5m × 4.6m. Robot został umieszczony wpunkcie (0 0) i otrzymał rozkaz jazdy do punktu o współrzędnych (−0,5 1). Na rysunku 12.8zaprezentowano robota realizującego powyższe zadanie, natomiast całą przebytą drogę przedstawionona rysunku 12.9. Zauważyć można, iż robot początkowo skierowany był w przeciwnąstronę niż punkt docelowy i po rozpoczęciu ruchu zawrócił. Następnie skierował się ku celowi.Podobnie jak w przypadku metody sił wirtualnych, również i w przypadku histogramupola wektorów występuje niewielka niezgodność pozycji końcowej z zadanym położeniem —

12.3 Histogram pola wektorów 59Rysunek 12.6: Trajektoria robota jadącego do celu przy użyciu metody sił wirtualnych nascenie z przeszkodami.Rysunek 12.7: Trajektoria robota jadącego do celu przy użyciu metody sił wirtualnych nascenie z przeszkodami z ograniczeniem przyspieszenia liniowego do 5 mm .s 2

60 Wyniki eksperymentówRysunek 12.8: Robot poruszający się po scenie metodą histogramu pola wektorów.przyczyny tej rozbieżności są takie same jak w poprzednim algorytmie.Drugi przykład przeprowadzono na scenie z przeszkodą o wymiarach 80cm × 40cm ustawionąna drodze do celu. Robot ustawiony został w punkcie (0 0) i otrzymał rozkaz jazdy dopunktu o współrzędnych (−2 2). Wygenerowaną trajektorię przedstawiono na rysunku 12.10.Ponownie w początkowym okresie ruchu widoczny jest nawrót wykonany przez robota, zewzględu na niewłaściwą orientację względem punktu końcowego. Następnie robot skierowałsię do celu, ale po napotkaniu przeszkody skręcił i podążał wzdłuż niej. W momencie, gdykierunek ku końcowej pozycji przestał być blokowany przez przeszkodę, robot podjął kolejnepróby zmiany orientacji. Ten fragment trajektorii charakteryzuje się kilkoma nagłymi zmianamiorientacji, wynikającymi z faktu, że po wykonaniu nieznacznego obrotu ku celowi przeszkodaznajdywała się ponownie w sektorze przed robotem, co wymuszało ponowny obrót do poprzedniejorientacji. Efekt ten powodowany jest głównie niewielką ilością sektorów na jakie zostałpodzielony obszar wokół robota (co wymuszone było ilością dostępnych sonarów). Pojedynczysektor miał 22,5 ◦ szerokości kątowej, a przy takiej rozdzielczości nagła zmiana stanu sektora zdozwolonego na zabroniony powodowała wyraźne skoki wektora kierunku ruchu.

12.3 Histogram pola wektorów 61Rysunek 12.9:wektorów.Trajektoria robota jadącego do celu przy użyciu algorytmu histogramu polaRysunek 12.10: Trajektoria robota jadącego do celu przy użyciu algorytmu histogramu polawektorów na scenie z przeszkodą.

Rozdział 13PodsumowanieW ramach niniejszej pracy dyplomowej utworzony został symulator Simbo, umożliwiający badaniezachowania robotów w wirtualnym środowisku, bez narażania na uszkodzenie rzeczywistychmaszyn lub otoczenia oraz pozwalający na łatwe modyfikowanie sceny i symulowanychrobotów. Aplikacja posiada opcję wczytywania dowolnych obiektów (robotów, elementów otoczenialub statycznych elementów) oraz zapisywania całego zestawu wczytanych obiektów wpostaci plików scen. Dodatkowo możliwe jest sprawdzenie odczytów sensorów bezpośredniow programie oraz natychmiastowa zmiana pozycji całych obiektów oraz przegubów łączącychposzczególne ich części. Cały przebieg symulacji wizualizowany jest przy pomocy bibliotekiVTK. W przeciwieństwie do wielu komercyjnych symulatorów, Simbo jest aplikacją o otwartymkodzie, co umożliwia dostosowanie go do indywidualych potrzeb użytkownika.W celu ułatwienia rozbudowy zestawu dostępnych modeli utworzony został również edytorSimboEd. Jego prosty i przejrzysty interfejs użytkownika umożliwa szybkie tworzenie nowychmodeli robotów oraz innych obiektów sceny w oparciu o podstawowe bryły geometryczne.Ponadto, ponieważ modele zapisywane są w XMLowym standardzie X3D, możliwe jest równieżwprowadzanie zmian przy pomocy innych edytorów obsługujących ten format danych (lubnawet przy wykorzystaniu zwykłych edytorów tekstowych) — przy czym w takiej sytuacji koniecznajest pewna wiedza o węzłach obsługiwanych przez symulator i ich atrybutach. W swejpodstawowej wersji symulator oferuje modele robotów Pioneera oraz PeopleBota, a także szeregobiektów pomocnych w budowaniu sceny (szafy, stoły, krzesła, itp.). Ponadto dostępne sąrównież modele kamery stereowizyjnej oraz chwytaka Pioneera, które przy pomocy edytoramogą być zamontowane na robocie.Symulator standardowo oferuje jeden procesor obsługujący oba podstawowe modele robotóworaz zestaw sensorów możliwych do zamontowania na robotach: dalmierz laserowy, sonar,enkoder inkrementalny oraz prędkościomierz. Dzięki implementacji tych urządzeń w postacipluginów Qt możliwa jest również rozbudowa i dodawanie nowych procesorów oraz sensorów.Prosty interfejs umożliwia łatwą komunikację oraz sterowanie robotem. Ponadto sposóbrealizacji procesora Pioneera wymaga połączenia z nim aplikacji klienta przez port TCP; ponieważwykorzystywany protokół jest zgodny ze standardem biblioteki ARIA, umożliwia towykorzystanie programów przeznaczonych do kontroli rzeczywistego robota i sterowanie nimiwirtualnymi robotami w symulatorze.Ostatecznym testem poprawności funkcjonowania symulatora było utworzenie prostych algorytmównawigacji przy wykorzystaniu biblioteki ARIA i sprawdzenie zachowania robotasterowanego nimi. W szczególności dotyczy to funkcji odczytujących z sonarów informacjeo odległości od przeszkód oraz wyliczania pozycji na podstawie wskazań enkoderów robota,a także funkcji odpowiedzialnych za wydawanie poleceń ruchu robotowi. Opis algorytmów irezultaty przeprowadzonych eksperymentów zawarte zostały w rozdziałach 11 i 12. Na podstawietrajektorii robota można stwierdzić, że komunikacja z wirtualnym Pioneerem w symula-

64 Podsumowanietorze Simbo przy wykorzystaniu biblioteki ARIA przebiegała zgodnie z oczekiwaniami. Przypomocy sonarów robot poprawnie unikał przeszkód, a dane z enkoderów pozwalały mu określićwłasną pozycję względem punktu początkowego, a tym samym wyznaczać kierunek do punktudocelowego w przypadku korzystania z algorytmów kierujących robota do wyznaczonego celu.Utworzona aplikacja wymagała zapoznania się z szerokim zakresem zagadnień; począwszyod samego środowiska Qt, a w szczególności optymalnego wykorzystania sygnałów oraz sposobupisania zewnętrznych pluginów, poprzez prawidłowe użycie biblioteki silnika fizycznegoODE oraz powiązanie go z wizualizacją realizowaną przez VTK, a także problemami związanychz reprezentacją obiektów w formacie X3D, aż do zagadnień funkcjonowania różnorodnychsensorów robotów i odwzorowywania ich w symulatorze oraz implementacji konkretnychalgorytmów nawigacji. Mimo to wciąż istnieje szereg modyfikacji, które można wprowadzićdo symulatora w celu usprawnienia jego działania. Poza dodawaniem nowych modeli, procesorówi sensorów oraz doskonaleniem tych istniejących wartościowym dodatkiem mogłabybyć obsługa szerszego zakresu przegubów, gdyż aktualnie symulator obsługuje jedynie przegubprzesuwny i obrotowy o jednym stopniu swobody, a zarówno X3D jak i ODE definiująwiele innych. Również dostępne bryły geometryczne mogłyby zostać rozszerzone o obsługęsiatek trójkątów, co pozwoliłoby modelować obiekty o dowolnych kształtach. Ponadto w celuzoptymalizowania wykorzystania wieloprocesorowej struktury współczesnych komputerów dobrymrozwiązaniem byłaby modyfikacja procesorów i sensorów, tak by uruchamiane były woddzielnych wątkach lub procesach. Natomiast w przypadku zaimplementowanych algorytmówsterowania warto byłoby dodać syntezę odczytów sensorów z kilku chwil czasowych zuwzględnieniem pozycji robota, by w ten sposób móc uzyskać rozdzielczość otoczenia lepsząniż to, na co pozwala zestaw 16 sonarów Pioneera.

Dodatek APrzykład użycia edytora SimboEdW niniejszym dodatku opisany został proces budowy modelu kamery stereowizyjnej przy pomocyedytora SimboEd. Model gotowej kamery przedstawiony został na rysunku A.1. Czarnepierścienie oznaczają przeguby obrotowe kamery.Rysunek A.1: Model kamery stereowizyjnej w edytorze SimboEd.PodstawaPodstawa, na której umieszczona jest kamera, składa się z trzech prostopadłościanów oraztrzech cylindrów (patrz rys. A.2). Wymiary oraz pozycje prostopadłościanów przedstawiono wtablicy A.1, natomiast wymiary i pozycje cylindrów zostały przedstawione w tablicy A.2.Nazwa Szerokość Wysokość Długość X Y ZP1 1 0,8 0,7 0 0 0P2 1 0,6 1 0 0,7 0,15P3 0,6 0,6 1,2 0 0,7 0,25Tablica A.1: Wymiary i pozycje prostopadłościanów wchodzących w skład podstawy kamery.Aby utworzyć podstawę kamery należy wykonać następujące czynności:• z menu Dodaj wybrać opcję Prostopadłościan lub Cylinder,

66 Przykład użycia edytora SimboEdRysunek A.2: Podstawa kamery — model oraz jego siatka.Nazwa Promień Wysokość X Y Z OX OY OZC1 0,5 0,8 0 0 0,35 90 0 0C2 0,2 0,6 0,3 0,7 0,65 90 0 0C3 0,2 0,6 -0,3 0,7 0,65 90 0 0Tablica A.2: Wymiary i pozycje cylindrów wchodzących w skład podstawy kamery.• zatwierdzić dodanie nowej bryły klikając przycisk OK,• z menu Edytuj wybrać opcję Geom i wprowadzić odpowiednie wymiary i pozycję z tablicyA.1 lub A.2 (należy zwrócić uwagę na to, by edytowana bryła była zaznaczona –powinna być koloru czerwonego),• zatwierdzić edycję bryły klikając przycisk Ustaw,Powyższe czynności powinny być wykonane dla wszystkich sześciu brył. Ponadto dodająckolejną bryłę należy zwrócić uwagę na to, by zaznaczona była jedna z już istniejących brył —spowoduje to połączenie nowego elementu z poprzednimi, tworząc w ten sposób jedno ciałosztywne (w edytorze bryły należące do tego samego ciała oznaczane są tym samym kolorem).StatywStatyw składa się z jednego cylindra, umożliwiającego kamerze wykonywanie horyzontalnegoobrotu. Aby dodać go do modelu należy najpierw odznaczyć aktualnie zaznaczony elementpoprzez dwukrotne kliknięcie myszą na pustym obszarze okna edycyjnego. Poprawne dodaniebryły spowoduje, że stanie się ona jednocześnie nowym ciałem sztywnym — powinna onazostać oznaczona innym kolorem niż wcześniej utworzona podstawa kamery. Następnie, postępującwedług kroków opisanych powyżej, należy dodać cylinder o parametrach opisanych wtablicy A.3.Nazwa Promień Wysokość X Y Z OX OY OZC4 0,05 0,4 0 1,2 0,5 90 0 0Tablica A.3: Wymiary i pozycja cylindra stanowiącego statyw kamery.

67Kolejną czynnością, którą należy wykonać, jest połączenie podstawy ze statywem przy pomocyprzegubu obrotowego. Aby to uczynić należy z menu Dodaj wybrać opcję Przegubobrotowy. Kotwica tego przegubu powinna zostać ustawiona w takiej samej pozycji jak bryłąreprezentująca statyw, tzn. (0 1,2 0,5); obrót statywu powinien odbywać się wokół osi Y, awięc należy w polach oznaczających wektor obrotu należy wpisać wartość (0 1 0). Następnie,aby połączyć dwa ciała sztywne (podstawę i statyw) przy pomocy tworzonego przegubu, należyzaznaczyć jedno z nich (dwukrotnym kliknięciem na jednym z jego elementów), kliknąćprzycisk Ustaw ciało 1, zaznaczyć drugie z nich i kliknąć przycisk Ustaw ciało 2. Po tychczynnościach można zakończyć proces tworzenia przegubu klikając przycisk OK. Jeśli przegubzostał poprawnie dodany, wokół statywu powinien pojawić się czarny pierścień (patrz rys. A.3).Rysunek A.3: Podstawa kamery i statyw połączone przegubem obrotowym.ObiektywyOstatnim elementem kamery są jej obiektywy (dwa cylindry) oraz element je łączący (prostopadłościan).Wymiary i pozycje tych brył przedstawione zostały w tablicy A.5 oraz A.4. Należyje dodać do modelu postępując według kroków opisanych powyżej.Nazwa Szerokość Wysokość Długość X Y ZP4 0,6 0,15 0,15 0 1,45 0,5Tablica A.4: Wymiary i pozycja prostopadłościanu na którym umieszczone są obiektywy kamery.Nazwa Promień Wysokość X Y Z OX OY OZC5 0,05 0,02 0,2 1,45 0,585 0 0 0C6 0,05 0,02 -0,2 1,45 0,585 0 0 0Tablica A.5: Wymiary i pozycje cylindrów reprezentujących obiektywy kamery.Następnie należy połączyć obiektywy ze statywem, tworząc kolejny przegub obrotowy wedługwskazówek opisanych wcześniej; pozycja kotwicy przegubu powinna być taka sama jakpozycja prostopadłościanu łączącego obiektywy, natomiast wektor obrotu przegubu powinien

68 Przykład użycia edytora SimboEdmieć postać (1 0 0). Poprawne dodanie przegubu powinno zostać zobrazowane pojawieniem siędrugiego czarnego pierścienia, a ostateczny model powinien mieć wygląd taki, jak to przedstawionona rysunku A.1.Dodanie sensorówAby model mógł wykonywać swe działanie, konieczne jest przypisanie sensorów kamery dogeomów reprezentujących obiektywy. W tym celu należy zaznaczyć jeden z tych geomów, anastępnie w menu Edytuj wybrać opcję Geom. W okienku edycji w polu Sensor można wpisaćnazwę odpowiedniego sensora (w tym przypadku libCamera) lub korzystając z przycisku obokotworzyć okienko umożliwiające wybór pliku biblioteki sensora (libCamera.so).Ponadto w polu Nazwa można również wpisać unikanlną nazwę geoma, co umożliwi procesorowirobota identyfikację sensora, który przysłał swoje odczyty.Po dokonaniu koniecznych modyfikacji, zmiany należy zaakceptować klikając przyciskUstaw, a powyższe czynności należy powtórzyć dla drugiego obiektywu.Identyfikacja przegubówAby procesor robota mógł sterować przegubami kamery, konieczne jest przypisanie im unikalnychnazw, umożliwiających ich identyfikację. W tym celu należy dwukrotnym kliknięciemna przegubie zaznaczyć go, a następnie z menu Edytuj należy wybrać opcję Edycjaprzegubu. Pole Nazwa umożliwia podanie ciągu znaków identyfikującego zaznaczony przegub.W ten sposób utworzony model można zapisać w formacie X3D wybierając z menu Plikopcję Zapisz.

Dodatek BPrzykład implementacji dalmierzalaserowegoW niniejszym dodatku opisany został kod źródłowy biblioteki implementującej funkcjonalnośćdalmierza laserowego w symulatorze Simbo.Idea działania tego czujnika zakłada utworzenie promienia o orientacji takiej jak bryła, doktórej sensor został przypisany, a następnie przeprowadzenie jego kolizji z innymi obiektami nascenie. Odczytem dalmierza jest liczba określająca dystans od pozycji dalmierza do najbliższejprzeszkody. Dodatkowo wizualizacja promienia dalmierza przeprowadzana powinna być przypomocy czerwonej linii.Poniżej przedstawiono definicję klasy laserrangefinder, implementującej funkcjonalnośćdalmierza.class laserrangefinder : public Sensor{Q_OBJECTvtkLineSource *LineSource;Geometry TrackingRay;dReal Distance;private:inline void CreateTracker();inline void ChangeTrackerDistance();public:~laserrangefinder();Sensor* createInstance();void InitSensor();QByteArray GetOutput();void TimeTick();void NewTimeInterval(float interval);void SensorMoved();void CollisionCheckResult(QVector hits);void ReceivedCommand(QByteArray command);void ActorAdded(void *actor);void ActorRemoved(void *actor);};

70 Przykład implementacji dalmierza laserowegoKlasa ta zawiera trzy właściwości. LineSource jest źródłem VTK czerwonej linii reprezentującejpromień dalmierza (bezpośredni dostęp do tego obiektu jest konieczny, by zmienićdługość promienia, gdy napotka on na przeszkodę). TrackingRay jest strukturą przechowywującąm.in. wskaźniki do aktora VTK oraz obiektu ODE reprezentujących promień dalmierza.Natomiast Distance zawiera odległość od najbliższej przeszkody uzyskaną z ostatniego pomiaru.Ponadto klasa zawiera dwie metody prywatne oraz publiczny destruktor – pozostałe są implementacjąogólnego interfejsu sensorów. Kod poszczególnych metod wraz z opisem ich funkcjonalnościprzedstawiony został poniżej.void laserrangefinder::CreateTracker(){vtkPolyDataMapper *mapper;vtkActor *actor;LineSource = vtkLineSource::New();mapper = vtkPolyDataMapper::New();actor = vtkActor::New();LineSource->SetPoint1(0,0,0);LineSource->SetPoint2(0,0,100);mapper->SetInput(LineSource->GetOutput());actor->SetMapper(mapper);}actor->GetProperty()->SetColor(1,0,0);TrackingRay.Actor = actor;((vtkRenderer*)Renderer)->AddActor(actor);Prywatna metoda CreateTracker wywoływana jest podczas inicjalizacji sensora i ma nacelu utworzenie elementów odpowiedzialnych za wizualizację promienia dalmierza. Są to kolejnoobiekty klas: vtkLineSource (odpowiedzialna za określenie geometrii linii), vtkPolyDataMapper(odpowiedzialna za wizualizację geometrii) oraz vtkActor (odpowiedzialna m.in. za pozycję iorientację linii).Metoda ustawia początkowy punkt linii w pozycji (0 0 0) oraz końcowy w pozycji (0 0 100)– przy czym zaznaczyć należy, iż te punkty dotyczą lokalnego układu współrzędnych linii,więc nie będą one modyfikowane podczas ruchu sensora (z wyjątkiem zmiany współrzędnej Zdrugiego punktu, gdy konieczna będzie zmiana długości promienia); Zmiana orientacji i pozycjicałej linii odbywać się będzie poprzez wywołania odpowiednich metod aktora.Następnie trzy obiekty łączone są ze sobą w potok renderujący oraz zmieniany jest kolorlinii na czerwony, a aktor zostaje dodany do sceny (zmienna Renderer jest właściwością klasySensor, a więc dostępna jest również w klasach potomnych).void laserrangefinder::ChangeTrackerDistance(){dReal distance;if(Distance==dInfinity) distance=100;else distance = Distance;LineSource->SetPoint2(0,0,distance);

71}LineSource->Update();vtkPolyDataMapper *mapper =(vtkPolyDataMapper*)(TrackingRay.Actor->GetMapper());mapper->Update();Metoda ChangeTrackerDistance wywoływana jest za każdym razem, gdy zmieni się dystansdo przeszkody wykryty przez dalmierz. Na podstawie aktualnej wartości dystans zmieniaona współrzędne drugiego punktu linii, tak by jej długość odpowiadała aktualnej odległości. Wprzypadku gdy przeszkoda nie zostanie wykryta, długość promienia ograniczona jest do 100.Po wprowadzeniu modyfikacji konieczne jest uaktualnienie potoku renderującego poprzez wywołaniemetody Update kolejno w obiektach klas vtkLineSource oraz vtkPolyDataMapper.laserrangefinder::~laserrangefinder(){delete InfoBox;((vtkRenderer*)Renderer)->RemoveActor(TrackingRay.Actor);TrackingRay.Actor->Delete();dGeomDestroy(TrackingRay.Geom);}Destruktor dalmierza usuwa obiekty utworzone podczas inicjalizacji sensora, tzn. aktoraVTK, promień ODE oraz okno informacyjne sensora. W przypadku aktora konieczne jest teżusunięcie go ze sceny. Zaznaczyć należy, iż zmienna InfoBox jest właściwością należącą doklasy Sonar, a więc dostępna jest w klasach potomnych, aczkolwiek w przypadku dalmierzajej modyfikacja ma miejsce dopiero w metodzie inicjalizującej sensor.Sensor* laserrangefinder::createInstance(){return new laserrangefinder();}Metoda createInstance należy do interfejsu sensorów. Zgodnie z omówioną w rozdziale7 sugestią, implementacja tej metody tworzy jedynie kopię obiektu klasy dalmierza.void laserrangefinder::InitSensor(){QLabel *label;Distance = dInfinity;TrackingRay.Geom = dCreateRay(0,100);const dReal *pos = dGeomGetOffsetPosition(ParentGeom);const dReal *rot = dGeomGetOffsetRotation(ParentGeom);dGeomSetPosition(TrackingRay.Geom,pos[0],pos[1],pos[2]);dGeomSetRotation(TrackingRay.Geom,rot);CreateTracker();InfoBox = new QWidget();InfoBox->setWindowTitle(Name);InfoBox->setGeometry(0,0,200,100);

72 Przykład implementacji dalmierza laserowego}InfoBox->setAttribute(Qt::WA_QuitOnClose,false);label = new QLabel(InfoBox);label->setText("Laser Rangefinder");label->setGeometry(0,0,200,20);label = new QLabel(InfoBox);label->setText("Collision Distance: N/A");label->setGeometry(0,20,200,20);Metoda InitSensor jest częścią interfejsu sensorów, wywoływana jest ona zaraz po utworzeniuczujnika oraz połączeniu jego sygnałów i slotów. W przypadku dalmierza metoda tawykonuje trzy zasadnicze czynności – tworzy promień ODE oraz ustawia jego pozycję i orientacjęna taką, jaką ma bryła, do której sensor został przypisany; następnie tworzy wizualizacjępromienia wywołując metodę CreateTracker opisaną wcześniej; ostatecznie tworzy okno informacyjnesensora jako obiekt klasy QWidget i przypisuje go do zmiennej InfoBox, z którejsymulator automatycznie skorzysta, gdy konieczne będzie wyświetlenie tego okna użytkownikowi.Okno informacyjne dalmierza zawiera nazwę sensora oraz zmierzony dystans do przeszkody.void laserrangefinder::SensorMoved(){const dReal *pos = dGeomGetPosition(ParentGeom);const dReal *rot = dGeomGetRotation(ParentGeom);vtkMatrix4x4 *matrix = vtkMatrix4x4::New();matrix->SetElement(0,0,rot[0]);matrix->SetElement(0,1,rot[1]);matrix->SetElement(0,2,rot[2]);matrix->SetElement(0,3,pos[0]);matrix->SetElement(1,0,rot[4]);matrix->SetElement(1,1,rot[5]);matrix->SetElement(1,2,rot[6]);matrix->SetElement(1,3,pos[1]);matrix->SetElement(2,0,rot[8]);matrix->SetElement(2,1,rot[9]);matrix->SetElement(2,2,rot[10]);matrix->SetElement(2,3,pos[2]);dGeomSetPosition(TrackingRay.Geom,pos[0],pos[1],pos[2]);dGeomSetRotation(TrackingRay.Geom,rot);TrackingRay.Actor->SetUserMatrix(matrix);matrix->Delete();}Metoda SensorMoved również należy do interfejsu sensorów i wywoływana jest w każdymkroku symulacji, oraz, w przeciwieństwie do metody TimeTick, również gdy symulacja jestwstrzymana, a użytkownik zmieni położenie obiektu. Zadaniem tej metody jest skopiowaniepozycji i orientacji bryły, do której sensor jest przypisany, i przypisanie ich do aktora VTK orazpromienia ODE.void laserrangefinder::TimeTick(){emit RequestCollisionCheck(this,TrackingRay.Geom,1);}

73Metoda TimeTick jest elementem interfejsu sensorów i wywoływana jest w każdym krokusymulacji. W przypadku dalmierza metoda ta wykorzystywana jest do zgłoszenia symulatorowiżądania przeprowadzenia detekcji kolizji promienia ODE (parametr TrackingRay.Geom) zobiektami na scenie. Po wykonaniu tego zadania symulator wywoła metodę CollisionCheckResultz informacją o znalezionych punktach kolizyjnych.void laserrangefinder::CollisionCheckResult(QVector hits){Distance = dInfinity;if(hits.size()!=0){for(int i=0;isetText(text);}ChangeTrackerDistance();Metoda CollisionCheckResult należy do interfejsu sensorów i wywoływana jest po wyemitowaniusygnału RequestCollisionCheck, gdy symulator skończy przeprowadzanie zażądanejdetekcji kolizji. Zmienna hits zawiera punkty, w których wysłany promień przeciął inneobiekty na scenie, przy czym dla każdego obiektu wygenerowany zostaje maksymalnie jedenpunkt (domyślnie jest to punkt najbliższy). Ilość generowanych punktów dla każdego obiektuokreśla trzeci parametr wywołania sygnału żądania detekcji kolizji.Po wywołaniu tej metody dalmierz sprawdza wszystkie znalezione punkty i jako dystansdo przeszkody wybiera najbliższy z nich. Następnie modyfikowany jest opis w oknie informacyjnymoraz wywoływana jest metoda ChangeTrackerDistance modyfikująca wizualizacjępromienia.QByteArray laserrangefinder::GetOutput(){QByteArray ret;QDataStream stream(&ret,QIODevice::WriteOnly);stream

74 Przykład implementacji dalmierza laserowegovoid laserrangefinder::NewTimeInterval(float) {}void laserrangefinder::ReceivedCommand(QByteArray) {}void laserrangefinder::ActorAdded(void *) {}void laserrangefinder::ActorRemoved(void *) {}Powyższe cztery metody są częścią interfejsu sensorów, jednakże nie mają zastosowania wprzypadku dalmierza, więc nie wykonują one żadnych czynności. Tym niemniej ich implementacjemuszą się pojawić w bibliotece.Q_EXPORT_PLUGIN2(LaserRangeFinder, laserrangefinder)Ostatnim elementem tworzenia plugina w Qt jest wywołanie powyższego makra w celuwyeksportowania klasy implementowanej w bibliotece.

Bibliografia[1] ActivMedia Robotics. Pioneer 2 Gripper Manual, May 1999.[2] ActivMedia Robotics. Pioneer 2 / PeopleBot Operations Manual for P2OS-based ActivMediaRobots, Jul 2002.[3] Jasmin Blanchette and Mark Summerfield. C++ GUI Programming with Qt 4. PrenticeHall PTR, Upper Saddle River, NJ, USA, 2006.[4] J. Borenstein and Y. Koren. The vector field histogram - fast obstacle avoidance for mobilerobots. IEEE Journal of Robotics and Automation, 7(3):278 – 288, June 1991.[5] Richard T. Vaughan Brian P. Gerkey and Andrew Howard. Player User Manual, Jun 2004.[6] Don Brutzman. Mobile x3d graphics. Edinburgh, Scotland, May 2006. Web3D Consortium.[7] R. Gourdeau. ROBOOP - A Robotics Object Oriented Package in C++, Oct 2007.[8] B. Kreczmer. Unifracx - unified frame for actions execution. http://lirec.iiar.pwr.wroc.pl/~bk/unifracx/.[9] O. Michel. Webots: Professional mobile robot simulation. International Journal of AdvancedRobotic Systems, 1(1):39 – 42, 2004.[10] MobileRobots. Pioneer Arm Manual, 2006.[11] MobileRobots. MobileRobots Advanced Robotics Interface for Applications (ARIA) Developer’sReference Manual, 2009.[12] V.O.S. Olunloyo and M.K.O. Ayomoh. Autonomous mobile robot navigation using hybridvirtual force field concept. European Journal of Scientific Research, 31(2):204 – 228,2009.[13] William J. Schroeder, Kenneth M. Martin, and William E. Lorensen. The design andimplementation of an object-oriented toolkit for 3d graphics and visualization. In VIS ’96:Proceedings of the 7th conference on Visualization ’96, Los Alamitos, CA, USA, 1996.IEEE Computer Society Press.[14] R. Smith. Open Dynamics Engine User Guide, Feb 2006.

Spis rysunków3.1 Główne okno symulatora Webots. . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Zastosowanie biblioteki ROBOOP z wizualizacją realizowaną przez GLroboop. 84.1 Wizualizacja modelu Pioneera w Simbo. . . . . . . . . . . . . . . . . . . . . . 146.1 Układ pierścienia sonarów na Pioneerze. . . . . . . . . . . . . . . . . . . . . . 196.2 Wewnętrzny układ współrzędnych Pioneera. . . . . . . . . . . . . . . . . . . . 207.1 Podstawowa architektura symulatora Simbo. . . . . . . . . . . . . . . . . . . . 227.2 Architektura symulatora Simbo z rozdzieleniem procesora i sterownika. . . . . 227.3 Diagram klas symulatora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238.1 Główne okno symulatora Simbo. . . . . . . . . . . . . . . . . . . . . . . . . . 308.2 Okno opcji obiektu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318.3 Okno odczytów sensorów. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318.4 Okno opcji wizualizacji. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.5 Okno opcji symulacji. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348.6 Okno opcji systemowych. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348.7 Główne okno edytora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358.8 a) Okno tworzenia nowego geomu. b) Okno tworzenia nowego przegubu. . . . 368.9 a) Okno edycji ciała. b) Okno edycji geomu. . . . . . . . . . . . . . . . . . . . 378.10 a) Okno edycji przegubu. b) Okno edycji tekstury. . . . . . . . . . . . . . . . . 388.11 a) Okno edycji grupy. b) Okno edycji nagłówka. . . . . . . . . . . . . . . . . . 388.12 Okno opcji systemowych. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3910.1 Struktura symulatora z Arią i UNIFRACXem. . . . . . . . . . . . . . . . . . . 4611.1 Strefy nawigacji robota w algorytmie losowego ruchu. . . . . . . . . . . . . . 5011.2 Koncepcja unikania przeszkód metodą sił wirtualnych. . . . . . . . . . . . . . 5111.3 Robot w otoczeniu przeszkód. . . . . . . . . . . . . . . . . . . . . . . . . . . 5211.4 Histogram dla sceny na rysunku 11.3. . . . . . . . . . . . . . . . . . . . . . . 5211.5 Wybór kierunku ruchu na podstawie histogramu. . . . . . . . . . . . . . . . . 5311.6 Porównanie zachowania algorytmów w przypadku wąskiego korytarza pomiędzyprzeszkodami: a) Histogram pola wektorów — dostępne sektory pomiędzyprzeszkodami umożliwiają przejazd b) Metoda sił wirtualnych — suma sił odpychającychuniemożliwia robotowi przejazd do celu. . . . . . . . . . . . . . . 5412.1 Trajektoria robota poruszającego się po pustej scenie. . . . . . . . . . . . . . . 5612.2 Robot poruszający się po scenie metodą losowego ruchu. . . . . . . . . . . . . 5612.3 Trajektoria robota poruszającego się po scenie z dodatkowymi przeszkodami. . 5712.4 Trajektoria robota jadącego do celu przy użyciu metody sił wirtualnych. . . . . 5712.5 Robot poruszający się po scenie metodą sił wirtualnych. . . . . . . . . . . . . 58

78 SPIS RYSUNKÓW12.6 Trajektoria robota jadącego do celu przy użyciu metody sił wirtualnych na sceniez przeszkodami. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5912.7 Trajektoria robota jadącego do celu przy użyciu metody sił wirtualnych na sceniez przeszkodami z ograniczeniem przyspieszenia liniowego do 5 mm . . . . . . 59s 212.8 Robot poruszający się po scenie metodą histogramu pola wektorów. . . . . . . 6012.9 Trajektoria robota jadącego do celu przy użyciu algorytmu histogramu polawektorów. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6112.10Trajektoria robota jadącego do celu przy użyciu algorytmu histogramu polawektorów na scenie z przeszkodą. . . . . . . . . . . . . . . . . . . . . . . . . 61A.1 Model kamery stereowizyjnej w edytorze SimboEd. . . . . . . . . . . . . . . . 65A.2 Podstawa kamery — model oraz jego siatka. . . . . . . . . . . . . . . . . . . . 66A.3 Podstawa kamery i statyw połączone przegubem obrotowym. . . . . . . . . . . 67

Spis tablicA.1 Wymiary i pozycje prostopadłościanów wchodzących w skład podstawy kamery. 65A.2 Wymiary i pozycje cylindrów wchodzących w skład podstawy kamery. . . . . . 66A.3 Wymiary i pozycja cylindra stanowiącego statyw kamery. . . . . . . . . . . . . 66A.4 Wymiary i pozycja prostopadłościanu na którym umieszczone są obiektywykamery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.5 Wymiary i pozycje cylindrów reprezentujących obiektywy kamery. . . . . . . . 67