POLITECHNIKA WARSZAWSKA WYDZIAŁ ELEKTRYCZNY

Transkrypt

1 POLITECHNIKA WARSZAWSKA WYDZIAŁ ELEKTRYCZNY INSTYTUT STEROWANIA I ELEKTRONIKI PRZEMYSŁOWEJ PRACA DYPLOMOWA INŻYNIERSKA na kierunku INFORMATYKA specjalność: IFORMATYKA W ELEKTROENERGETYCE Michał MODZELEWSKI Nr albumu: Rok akad.: 2007/08 Warszawa, 30.XI.2007 TESTOWANIE ALGORYTMÓW STEROWANIA RUCHEM ROBOTÓW Z WYKORZYSTANIEM MICROSOFT ROBOTICS STUDIO 1.5 Zakres pracy: 1. Wprowadzenie do Microsoft Robotics Studio 2. Zbadanie możliwości Microsoft Robotics Studio 3. Sterowanie robotów mobilnych 4. Symulacja algorytmów sterowania w Microsoft Robotics Studio Kierujący pracą: dr inż. Konrad MARKOWSKI (Podpis pracownika naukowo dydaktycznego, dydaktycznego) dr hab. inż. Bartłomiej BELICZYŃSKI, prof. PW (Podpis i pieczątka Kierownika Zakładu Dydaktycznego/Katedry) Termin złożenia pracy: Praca wykonana i obroniona pozostaje własnością Instytutu, Katedry i nie będzie zwrócona wykonawcy.

2 Wstęp Wprowadzenie do Microsoft Robotics Studio Co to jest Microsoft Robotics Studio i jakie są jego możliwości? Narzędzia i architektura środowiska Microsoft Robotics Studio Język programowania VPL Decentralized Software Services (DSS) koncepcja serwisów Concurrency and Coordination Runtime (CCR) programowanie rozproszone Representational state transfer (REST) Wprowadzenie do symulacji w Microsoft Robotics Studio Po co stosować symulację Drogi i trudny w zdobyciu sprzęt do konstrukcji robotów Złożone i trudne rozwiązywanie problemów sprzętowych Trudności przy pracy grupowej Symulacja w Microsoft Robotics Studio, jej wady i zalety Zalety Wady i ograniczenia symulacji Architektura aplikacji symulacyjnej w Microsoft Robotics Studio i przykładowa aplikacja Metody sterowania robotów Opis metod i podstawy teoretyczne Sterowanie odporne Sterowanie adaptacyjne Sterowanie neuronowe Sterowanie rozmyte Sterowanie grupą robotów Każdy sobie Robot matka Sterowanie na podstawie zgromadzonych danych Opis pracy Założenia projektu Co zostało zrobione. Opis aplikacji i instrukcja obsługi Tworzenie wirtualnego świata

3 4.3. Przeprowadzone symulacje i ich wyniki Symulacja robotów ze zderzakami Symulacja robotów z dalmierzem laserowym Symulacja z robotem matką Symulacja z robotem matką i dalmierzem laserowym Wnioski Spis Skrótów Spis Rysunków Bibliografia

4 Wstęp Informatyka jest dziedziną stosunkowo nową i szybko rozwijającą się. Pojawia się ona w coraz to nowych dziedzinach życia. Coraz bardziej zaawansowane narzędzia informatyczne stają się ważnym narzędziem pracy dla wielu ludzi. Na dzień dzisiejszy trudno wyobrazić sobie pracę na zagadnieniami inżynierskimi bez pomocy komputera. Niezawodny i szybki komputer nie ma jednak zastosowania bez odpowiedniego oprogramowania. Tworzenie oprogramowanie bez odpowiednich narzędzi nie jest rzeczą łatwą. Na szczęści istnieje coraz więcej narzędzi programistycznych dostępnych za niską cenę lub wręcz bezpłatnie. Jednym z wiodących producentów oprogramowania na komputery osobiste jest firma Microsoft. Jej najbardziej znanym produktem jest system operacyjny Windows. Poza tworzeniem systemów operacyjnych oraz oprogramowania biurowego, firma Microsoft zaczęła tworzyć narzędzie programistyczne Microsoft Visual Studio, przeznaczone do tworzenia oprogramowania pod ich system operacyjny. Ze względu na łatwość obsługi, coraz większe możliwości oraz powszechność systemu operacyjnego Windows, zyskało ono szerokie grono zwolenników. Było to z kolei bodźcem dla firmy Microsoft aby znajdować dla Visual Studio coraz to nowsze zastosowania. W dniu dzisiejszym Microsoft Visual Studio jest używane do tworzenia aplikacji okienkowych, aplikacji internetowych, warstw dostępu do danych, serwisów webowych oraz aplikacji na urządzenia mobilne. Istnieje możliwość doinstalowania dodatkowych modułów, integrujących się ze środowiskiem. Przykładem takiego modułu są XNA Game Studio oraz Microsoft Robotics Studio. Oba te dodatki są darmowe i można je zintegrować z darmową dystrybucją Microsoft Visual Studio Express Edition. XNA Game Studio jest to zbiór narzędzi ułatwiających tworzenie gier komputerowych, przeznaczonych dla systemu Windows oraz konsoli XBox. Umożliwia nam dostęp do wszystkich zaawansowanych funkcji graficznych biblioteki Direct3D oraz pozostałych komponentów DirectX. Microsoft Robotics Studio zostało stworzone z myślą o twórcach aplikacji obsługujących hardware robotów. Umożliwia nam w łatwy sposób stworzenie oprogramowania sterującego naszym robotem. Umożliwia nam również przetestowanie naszego oprogramowania na symulowanym robocie. Do stworzenia wirtualnego świata, oraz fizycznego modelu symulowanego robota, Microsoft Robotics Studio wykorzystuje narzędzie z XNA Studio. Celem pracy jest przybliżenie możliwości środowiska symulacyjnego Microsoft Robotics Studio. W rozdziale pierwszym znajduje się opis środowiska Microsoft Robotics Studio. Omówione są w nim najważniejsze cechy środowiska. Rozdział drugi jest wprowadzeniem do 3

5 symulacji w Microsoft Robotics Studio. Opisane są w nim przypadki w których możemy zastosować symulację. Przedstawia również opis architektury aplikacji symulacyjnej. Rozdział trzeci zawiera opis metod sterowania robotami. Pierwsza część rozdziału przedstawia podstawy teoretyczne sterowania robotów kołowych a drugiej części znajduje się opis algorytmów które możemy zaimplementować w Microsoft Robotics Studio. Rozdział czwarty jest poświęcony części praktycznej pracy. Zawiera opis wykonanych symulacji oraz podsumowuje osiągnięte wyniki. 4

6 1. Wprowadzenie do Microsoft Robotics Studio Co to jest Microsoft Robotics Studio i jakie są jego możliwości? Microsoft Robotics Studio jest platformą programistyczną przeznaczoną dla systemów Windows, umożliwiającą tworzenie oprogramowania dla robotów [6]. Stworzone oprogramowanie może być wykorzystane na różnym sprzęcie. Środowisko jest kompatybilne z rozwiązaniami sprzętowymi takimi jak Fischertechnik, Roomba i Lego Mindstorms NXT. Robotics Studio zawiera również narzędzie do symulowania robotów i środowiska. Dzięki temu stworzoną aplikację możemy testować w realistycznym, trójwymiarowym świecie. Silnik fizyki bazuje na silniku PhysX firmy AGEIA Technologies. Najważniejszymi cechami środowiska są: Możliwość tworzenia zorientowanych na usługi (service oriented) aplikacji, współpracujących z szeroką gamą sprzętu używanego w robotyce. Wizualny język programowania (Visual Programming Language) ) umożliwiający tworzenie oprogramowania osobą, które nie są programistami. Tworzenie aplikacji w tym języku przypomina tworzenie aplikacji w środowisku Simulink, znanego z pakietu Matlab. Dzięki temu przy małym nakładzie pracy na naukę możemy zacząć tworzyć pierwsze aplikacje. Możliwość symulowania działania naszej aplikacji korzystając z realistycznych modeli w wirtualnym świecie symulacji. Środowisko symulacyjne w Microsoft Robotics Studio zawiera silnik fizyki AGEIA PhysX Technology firmy AGEIA Technologies Inc.. Dzięki temu symulacje nabierają cech rzeczywistego świata. Realistyczne symulowanie praw fizyki odbywa się kosztem mocy obliczeniowej komputera na którym pracujemy. Żeby wesprzeć procesor możemy wyposażyć nasz komputer w sprzętowy akcelerator fizyki firmy AGEIA Technologies. Wykorzystanie architektury Representational State Transfer (REST ). Modne ostatnimi czasy podejście do projektowania aplikacji rozproszonych. Przykładem takiego rozwiązania jest wprowadzony niedawno przez Microsoft Windows Comunnication Foundation (WCF ). 5

7 Mechanizm Concurrency and Coordination Runtime (CCR) ułatwiający programistom tworzenie aplikacji korzystających z asynchronicznej wymiany danych. Jest to wygodny sposób do obsługi komunikatów pomiędzy sensorami, procesorem i aktorami będącymi częściami składowymi robota. jest Technologią Decentralized Software Services (DSS), która jest konsekwencją stosowania w najniższej warstwie środowiska architektury REST. Daje nam ona łatwy dostęp do poszczególnych części składowych aplikacji (serwisów). Dzięki temu jesteśmy w stanie monitorować i zmieniać stan poszczególnych serwisów poprzez aplikacje desktop jak i web. Możliwość budowania aplikacji niezależnych sprzętowo. Dzięki temu nasza aplikacja lub jej elementy mogą być testowane na różnym sprzęcie. Aplikacje napisane w środowisku Microsoft Robotics Studio możemy uruchamiać na procesorach 8, 16 i 32 bitowych, zarówno jedno jak i wielordzeniowych. Otwartość platformy. Dzięki temu zewnętrzne firmy mogą rozszerzać jej funkcjonalność poprzez dodawanie nowych bibliotek oraz serwisów. Producenci sprzętu i oprogramowania mogą w łatwy sposób sprawić aby ich produkt był w pełni kompatybilny z MSRS. Komunikacja pomiędzy robotem a PC poprzez port szeregowy, Bluetooth, , lub RF. Aplikacja może być również uruchamiana na komputerze pokładowym robota. Możliwość rozwijania aplikacje na roboty za pomocą języków programowania wspieranych przez Microsoft Visual Studio (C#, VB.NET) jak i języków skryptowych takich jak Microsoft Iron Python. Istnieje również możliwość tworzenia aplikacji w językach opracowanych przez firmy trzecie, które wspierają architekturę zorientowaną na serwisy Narzędzia i architektura środowiska Microsoft Robotics Studio Poniżej znajduje się opis najważniejszych narzędzi dostępnych z platformą Microsoft Robotics Studio. Bardziej szczegółowy opis możemy znaleźć w następujących pozycjach literatury [6], [7], [8]. 6

8 Język programowania VPL Microsoft Visual Programming Language (Rysunek 1) (VPL) to środowisko do tworzenia aplikacji, które w odróżnieniu od tradycyjnego modelu programowania opisującego przepływ sterowania, opisuje w sposób graficzny przepływ danych. Odpowiednie bloki (serwisy) zaczynają przetwarzać dane w chwili ich otrzymania. Nie ma określonej sekwencji wykonywania operacji. Takie podejście jest bardzo pomocne przy tworzeniu aplikacji rozproszonych i równoległych. VPL został stworzony z myślą o początkujących programistach, którzy posiadają jedynie podstawową wiedzę programowaniu. Mimo swojej prostoty VPL umożliwia tworzenie w pełni profesjonalnych aplikacji. Dzięki swojej modularnej strukturze, znacznie przyśpiesza proces wytwarzania zarówno prototypów jak i końcowych aplikacji. Robotyka nie jest jednym zagadnieniem gdzie VPL może znaleźć zastosowanie. Może on być z powodzeniem stosowany przez programistów tworzących aplikacji desktop i Web dla innych dziedzin nauki takich jak Chemia czy Fizyka. Rys. 1 Microsoft Visual Programming Language Przepływ danych (Rysunek 2) w Microsoft VPL składa się z połączonej grupy bloków czynności (z ang. activities). Reprezentowane są one przez bloki posiadające wejścia i wyjścia. Przez nie łączymy blokami czynności między sobą. 7

9 Rys. 2 Przepływ danych w Microsoft Visual Programming Language Bloki czynności reprezentują serwisy, kontrole przepływu danych, funkcje i inne moduły. Wynikowa aplikacja jest sekwencja odrębnych procesów. Nowo tworzone bloki czynności mogą być również budowane z innych bloków czynności. Pozwala to na składnie własnych bloków i wielokrotne ich używanie. Dzięki takiemu podejściu, cała aplikacja stworzona w VPL może być traktowana jako osobny blok czynności. Blok czynności (Rysunek 3) zawiera: nazwę czynności oraz obramowanie, na którym zaznaczone są jego punkty podłączania. Blok czynności może również zawierać grafikę, która symbolizuje zastosowanie bloku. Każdy blok posiada interfejs użytkownika umożliwiający ustawianie właściwości bloku oraz przypisywanie wartości zmiennym. Podobnie wygląda ustawianie właściwości kontrolek przy programowaniu WinForms w Visual Studio. Rys. 3. Elementy bloku czynności Bloki czynności łączone są za pomocą pinów. Piny po lewej stronie bloku reprezentują porty wejściowe dla nadchodzących wiadomości, a piny po prawej stronie reprezentują pory wyjściowe dla wiadomości wychodzących z bloku. Piny wejściowe są połączone ze zdefiniowanymi wewnątrz bloku funkcjami (z ang. handlers). 8

10 Blok czynności zaczyna przetwarzać przychodzącą wiadomość tak szybko jak tylko ją otrzyma i stwierdzi, że zawiera ona poprawne dane. Wszystkie dane wysłane do bloku czynności są przez ten blok przetwarzane. Dane, które mają być przesłane przez blok czynności do kolejnego bloku są odbierane, przepisywane i wysyłane jako inny komunikat przez pin wyjściowy bloku. Każdy blok czynności może posiadać wiele pinów wejściowych (Rysunek 4), z których każdy może posiadać własny zestaw pinów wyjściowych. Piny wyjściowe mogą należeć do jednego z dwóch typów; pin wynikowy i pin powiadamiający. Wynikowy pin jest reprezentowany jako prostokątny punk podłączenia a pin powiadamiający jest reprezentowany jako okrągły punkt podłączenia. Rys. 4. Piny w bloku czynności Wynikowy pin wyjściowy jest używany w sytuacjach, gdy wysyłany komunikat jest wynikiem określonego komunikatu wejściowego opisującego pewną czynność. Pin powiadamiający też może wysłać komunikat będący wynikiem odebrania takiego komunikatu, jednak zazwyczaj jest on używany do wysłania komunikatu opisującego zmianę jego wewnętrznego stanu. Piny powiadamiające mogą również generować komunikaty wielokrotnie, podczas gdy piny wynikowe wysyłają komunikat tylko raz, jako odpowiedz na komunikat, który przybył. Tak więc piny powiadamiające są używane do wysyłania komunikatów, które nie są rezultatem (odpowiedzią) na któryś z komunikatów przychodzących. 9

11 Decentralized Software Services (DSS) koncepcja serwisów Decentralized Software Services (DSS) oferuje zorientowany na usługi model, który łączy w sobie kluczowe aspekty z tradycyjnej architektury sieciowej (znanej jako REST) z elementami architektury usług sieciowych (web services). Model aplikacji zdefiniowany przez DSS bazuje na modelu REST. Definiuje on serwis poprzez ściśle określony zestaw operacji, jakie można wykonać na stanie serwisu. Rozszerza funkcjonalność oferowaną przez HTTP o manipulowanie strukturalnymi danymi i powiadamianie o zdarzeniach. Więcej informacji na ten temat można znaleźć w pracy [10]. Podstawowym celem stosowania DSS jest tworzenie prostych, niezależnych od platformy i luźno sparowanych komponentów. Dzięki temu możliwe jest tworzenie aplikacji będących zestawem serwisów znajdujących się na tym samym hoście jak i serwisów rozproszonych w środowisku sieciowym. Owocuje to dużą elastycznością i prostotą przy tworzeniu aplikacji. DSS korzysta z protokołów HTTP oraz DSSP (Decentralized Software Services Protocol) do komunikacji pomiędzy serwisami. DSSP jest to odmiana protokołu SOAP (Simple Object Access Protocol). Jest on używany do obsługi subskrypcji i manipulowania serwisami. Dzięki temu możliwy jest sprawny i niezawodny przepływ komunikatów w modelu, sterowanym zmianą stanu serwisów. Model DSS nie jest zależne od żadnego komponentu wchodzącego w skład Microsoft Robotics Studio poza CCR (Concurrency and Coordination Runtime). DSS zapewnia środowisko do hostowania i zarządzania serwisami oraz dostarcza zestawu serwisów, które mogą być używane do tworzenia, debugowania, testowania, monitorowania i zabezpieczania nowych serwisów. Jak już wiemy ze wstępu, serwis jest podstawowym elementem składowym aplikacji tworzonej w Microsoft Robotics Studio. Jest kluczową koncepcją modelu DSS. Serwisy mogą reprezentować praktycznie wszystko, przykładami mogą być: o elementy sprzętowe takie jak sensory i aktory, o elementy aplikacji takie jak interfejs użytkownika, kontenery, o agregacje (zestaw sensorów itp.). Serwisy są uruchamiane w kontekście zwanym DSS Node. DSS Node jest to środowisko hostujące, które umożliwia tworzenie i zarządzanie instancją serwisu dopóki nie zostanie on usunięty, lub DSS Node zostanie zatrzymana. Serwisy są z założenia przystosowane do działania w środowisku sieciowym więc mogą komunikować się ze sobą nawzajem niezależnie od tego czy komunikacja odbywa się w ramach tego samego DSS Node 10

12 czy poprzez sieć. Każdy z serwisów posiada zestaw składników (Rysunek 5) wspólny dla wszystkich serwisów. Poniżej omówimy składowe elementy serwisu. Rys. 5. Składniki serwisów Identyfikator Serwisu (Service Identifier) W Momocie, w którym w DSS Node jest tworzona instancja serwisu, Constuctor Sernice dynamicznie przypisuje jej URI (Uniform Resource Identifier). Ten identyfikator odpowiada konkretnej instancji serwisu działającej w konkretnym DSS Node. Identyfikator ten umożliwia innym serwisom na komunikowanie się z tą konkretną instancją serwisu jak i obejrzenie tej instancji w przeglądarce internetowej. Jedynym zadaniem identyfikatora jest identyfikacja instancji serwisu. Nie zawiera on żadnych informacji na temat stanu, zachowania lub kontekstu serwisu. Identyfikator kontraktu (Contract Identifier) Kontrakt jest opisem implementacji serwisu oraz jego zachowania. Dzięki temu inne serwisy wiedzą jak współpracować z danym serwisem. Kontrakt serwisu może obejrzeć za pomocą DSS Contrach Information Tool (DssInfo.exe). Kontrakty są używane w celu stworzenia DSS Proxy, które służy za punkt komunikacyjny z innym serwisem. Identyfikator Kontraktu (z ang. Contrach Identifier) jest URI, które jednoznaczne identyfikuje kontrakt serwisu. Identyfikator kontraktu jest generowany automatycznie podczas tworzenia serwisu. Identyfikator kontraktu może być zmieniony. 11

13 Stan serwisu (Service State) Stan serwisu reprezentuje serwis w danej chwili czasowej. San serwisu opisuje aktualną wartość jego zmiennych. Jako przykłady stanu można podać: o stan serwisu reprezentującego silnik może zawierać dane na temat obrotów na minutę, temperatury, ciśnienia oleju, zużycia paliwa; o stan serwisu reprezentującego kolejkę zadań może zawierać dane o liczbie aktualnych zadań, oraz ich aktualnym statusie. Zadania same są zazwyczaj serwisami tak więc można je łatwo rozróżniać poprzez Service Identiefier. Posiadają również własny stan; o stan serwisu reprezentującego klawiaturę może zawierać informacje o tym, który klawisz został przyciśnięty. Każda informacja, która może być otrzymana, zmodyfikowana lub monitorowana jako część Serwisu DSS musi być częścią stanu tego serwisu. Serwisy współpracujące (Service Partners) Ważną częścią modelu DSS jest umożliwianie serwisom łączenia się z innymi serwisami w celu udostępnienia funkcjonalności wyższego poziomu. Oznacza to, że zanim współpracujące serwisy zaczną czerpać korzyści z tej współpracy, muszą najpierw być w stanie nawiązać ze sobą połączenie. Przez to że serwisy są luźno sparowane, serwis nie wie czy serwis, z którym chce współpracować jest dostępny ani nawet nie wie gdzie ten serwis się znajduje. Aby rozwiązać ten problem w modelu DSS każdy serwis zawiera informacje na temat serwisów partnerujących. Serwisy partnerzy, to serwisy, z którymi dany serwis współpracuje aby zapewnić pewną funkcjonalność. Poprzez deklaracje zestawu serwisów jako partnerów, serwis wymusza na środowisku aby połączenie z tymi serwisami następowało w procesie tworzenia tego serwisu (a nie dopiero po stworzeniu). Partnera definiujemy poprzez użycie atrybutu Partner posiadający zestaw opcji. Dzięki nim możemy opisać zasady współpracy obydwu serwisów. Można zażądać, żeby serwis współpracujący był niezbędny. Jeżeli taki partner nie zostanie odnaleziony, wtedy serwis nie zostanie uruchomiony. Partnerzy mogą być również zdefiniowani jako opcjonalni. W tym przypadku pomimo braku połączenia z serwisem współpracującym serwis może zostać uruchomiony. Port główny (Main Port) Port główny to port CCR gdzie przychodzą komunikaty (wiadomości) z innych serwisów. Ponieważ serwisy nie są ze sobą połączone bezpośrednie, mogą ze sobą rozmawiać 12

14 tylko poprzez wysyłanie komunikatów na porty główne. Port główny jest prywatnym członkiem klasy serwisu i jest oznaczony przez atrybut ServicePoort. Komunikaty (wiadomości) akceptowane przez port główny są zdefiniowane poprzez typ portu. Wszystkie operacje zdefiniowane dla portu głównego muszą bazować na operacjach zdefiniowanych przez protokoły DSSP lub HTTP. Uchwyty (Service Handlers) Dla każdej operacji DSSP zdefiniowanej na porcie głównym potrzeba zarejestrować uchwyty (z ang. service handlers) aby obsłużyć wiadomość przychodzącą na port. Jedynymi wyjątkami są operacje DsspDefaultLookup oraz DsspDefaultDrop, dla których środowisko DSS rejestruje domyślne uchwyty. Z kontekstu definiującego Service Handler, serwis może wysłać komunikat do innego serwisu. Wiadomość może być wysyłana na dwa sposoby: Nie wymaga informacji w formie zapytania, wysłana do innego serwisu. Wymagana informacja w formie powiadomienia o zdarzeniu, wysłana do abonenta w wyniku zmiany stanu w serwisie generującym to powiadomienie o zmianie stanu. W obydwu przypadkach komunikaty (wiadomości) są wysyłane poprzez service forwarder (Rysunek 6), który jest lokalnym portem CCR, który reprezentuje port główny zdalnego serwisu. Kiedy wiadomość jest wysyłana przez service forwarder, jest ona przekazywane przez coraz niższe warstwy środowiska aż do warstwy transportowej, która prześle wiadomość do warstwy transportowej docelowego serwisu. Gdy tak się stanie, wiadomość jest transportowana przez coraz wyższe warstwy środowiska aż dojdzie do portu głównego serwisu docelowego. 13

15 Rys. 6 Przesyłanie komunikatów Powiadamianie o zdarzeniu (Event Notifications) Powszechnie stosowanym zabiegiem używanym w serwisach DSS jest subskrypcja. Serwis generuje zdarzenie powiadamiające jako wynik zmiany swojego stanu. Dla każdej subskrypcji jaką serwis ma ustawioną z innymi serwisami, serwis otrzyma zdarzenie powiadamiające na osobne porty CCR. Poprzez użycie różnych portów dla każdej subskrypcji możliwe jest rozróżnienie zdarzeń powiadamiających i określenie, z której subskrypcji pochodzi. Dzięki temu, że zdarzenia powiadamiające są odbierane na portach, można nimi sprawnie zarządzać Concurrency and Coordination Runtime (CCR) programowanie rozproszone Concurrency and Coordination Runtime (CCR) [9] udostępnia konkurencyjny, bazujący na wymianie komunikatów, model zapewniający koordynację przepływu komunikatów bez konieczności ręcznego kodowania wątków, zamków, semaforów itp.. CCR ułatwia tworzenie aplikacji zorientowanych na usługi poprzez udostępnienie modelu który, zapewnia funkcjonalności do zarządzania operacjami asynchronicznymi, zapewnia konkurencyjność, wykorzystuje zrównoleglenie sprzętowe oraz obsługuje błędy występujące podczas przetwarzania równoległego. Umożliwia to tworzenie aplikacji, w których moduły kodu lub komponenty są luźno połączone. Dzięki temu mogą być one rozwijane osobno i pracować niezależnie od rodzaju środowiska oraz innych komponentów. Przykładowe zastosowania CCR: 14

16 Wysyłanie asynchronicznych sygnałów sterujących - Podczas komunikacji pomiędzy luźno sparowanymi komponentami (na przykład program w środowisku sieciowym). Operacje asynchroniczne sprawiają, że kod programu szybciej reaguje na komunikaty, bardziej nadaje się do sterowania precyzyjnego oraz lepiej obsługuje błędy. Programowanie asynchroniczne znacznie pogarsza czytelność kodu ponieważ logika jest często rozdzielona pomiędzy wywołania operacji a kod, który te wywołania zapoczątkował. Również obsługa błędów dotyczących wielu niedokończonych operacje jest prawie niemożliwa do zrealizowania (transakcje rozproszone). Przetwarzanie współbieżne to przetwarzanie oparte na współistnieniu wielu wątków lub procesów operujących na współdzielonych danych. Wątki uruchomione na tym samym procesorze są przełączane, w krótkich przedziałach czasu, co sprawia wrażenie, że wykonują się równolegle. Aby możliwe było takie współistnienie wielu wątków i praca na współdzielonych danych, konieczne jest stosowanie różnych mechanizmów synchronizacyjnych, np. semaforów i monitorów. W przeciwnym wypadku może to doprowadzić do utraty spójności danych. Koordynacja i obsługa błędów Najbardziej złożonym komponentem większości dużych programów jest komponent odpowiedzialny za współpracę pozostałych komponentów. Rozbieżności pomiędzy sposobami interakcji poszczególnych komponentów, prowadzą do powstania nieczytelnego kodu w miejscach gdzie zachowanie środowiska zmienia się dla różnych sposobów koordynacji Representational state transfer (REST) W tym podrozdziale zostanie przedstawiony model aplikacji w Microsoft Robotics Studio.Więcej informacji na ten temat można znaleźć w pracy [10]. Podstawowym zadaniem aplikacji dla robotów jest pobieranie danych z sensorów robota oraz reagowanie na te dane poprzez zarządzanie zestawem aktorów, w taki sposób, aby osiągnąć założenia stawiane aplikacji. Na poniższym diagramie (Rysunek 7) widać prosty przepływ danych, w którym wysłany przez zderzak komunikat powoduje wyświetlenie komunikatu. Pomiędzy zderzakiem (sensorem) a kodem wyświetlającym komunikat jest zarządca/koordynator, który umożliwia połączenie obydwu elementów. 15

17 Rys. 7 Prosty przepływ danych Zarządca/koordynator jest w tym wypadku prosty, ale w miarę wzrostu złożoności aplikacji (coraz większa liczba sensorów i aktorów) jego zadanie staje się coraz bardziej złożone (Rysunek 8). Rys. 8 Złożony przepływ danych W sytuacji, gdy każdy z sensorów i aktorów jest bardziej skomplikowany, zarządca/koordynator musi zarządzać większą liczbą komponentów. Oprócz większej liczby komponentów i większej złożoności zarządcy, aplikacja obsługująca bardziej złożony przepływ danych powinna cechować się: Pobieranie danych wejściowych i kontrolowanie aktorów musi odbywać się konkurencyjnie, inaczej aktor może nie zostać uruchomiony a dane z sensora mogą zostać zignorowane. 16

18 Zarządzanie oraz scalanie komponentów są najbardziej newralgicznymi elementami aplikacji zwłaszcza gdy liczba sensorów i aktorów rośnie, przez co zarządzanie staje się bardziej skomplikowane. Autonomiczne i rozproszone zarządzanie wymaga, aby komponenty mogły być rozproszone i dostępne w środowisku sieciowym. Głównym założeniem architektury sieciowej jest prosta struktura, możliwość współpracy rozwiązań różnych producentów oraz luźnie parowanie. Aplikacje sieciowe bazujące na protokole HTTP pokazały, że spełniają te założenia. Pomimo to są pewne aspekty, w których model oparty na HTTP nie jest dobrym rozwiązaniem. Brak wsparcia dla operacji na danych strukturalnych. Ogranicza to znacznie możliwości aktualizacji stanu serwisu oraz ograniczy sposoby na które serwis może współpracować. Brak wsparcie dla powiadomieniach o zdarzeniach. HTTP jest protokołem typu request/response i nie wspiera modelu powiadamiania bazującego na przesyłaniu komunikatów o zdarzeniu do abonentów. Brak wsparcia dla zakładania relacji pomiędzy serwisami/komponentami. Nie da się określić i przypisać ról poszczególnym serwisom działającym w ramach jakiegoś przepływu. Przez to nie da się określić, które serwisy mają współpracować z określonym zarządcą. Microsoft Robotics Studio Runtime dostarcza model bazujący na architekturze REST, ale dodaje do niego pewne elementy z technologii Web services. Poprzez taki zabieg aplikacja może korzystać z powiadomień o zdarzeniach oraz manipulacji danymi strukturalnymi bez tracenia elastyczności komponentów współpracujących w środowisku rozproszonym. Protokół HTTP został zaprojektowany długo przed XML (Extensible Markup Language) przez co dostarcza funkcjonalności umożliwiających jedynie operowanie na całych zasobach (GET, PUT) przez co zmieniają cały stan zasobu. Dla porównania Web Service są reprezentowane całkowicie jako XML. Dzięki reprezentacji zasobów jako structured entity, możliwe jest zdefiniowanie operacji, które operują na części stanu serwisu. 17

19 Microsoft Robotics Studio Runtime pozwala na reprezentacje zasobu w sposób strukturalny oraz definiuje zestaw funkcjonalności umożliwiającychh operacjee ADD, DELATE, UPDATE oraz QUERY na stanie serwisu. Takie połączenie Web Services i REST daje możliwość bardziej elastycznego sposobu współdziałania serwisów. Kolejnym ważnym elementem jaki Microsoft Robotics Studio Runtime zaadoptowało z Web Services jest powiadamianie o zdarzeniu (Rysunek 9). W zmienionym modelu REST, zdarzenia są modelowane jako zmiany stanu serwisu. Dla przykładu jako operacje UPDATE stanu serwisu rozumiemy jako zmianie stanu serwisu spowodowaną działaniem operacji UPDATE. Ponadtoo operacja UPDATE sama reprezentuje zmianie stanu tak więc naturalne wydaje się traktowanie powiadomienia o zdarzeniu jako operacji UPDATE. Poprzez określenie powiadomienia o zdarzeniu jako zmiany stanu serwisu, serwisy subskrybujące mają wspólną metodę do monitorowania stanu serwisu publikującego niezależnie od sposobu implementacji, a serwisy publikujące mająą wspólną metodę reprezentacji powiadomienia o zdarzeniu. Rys. 9 Powiadamianie o zdarzeniu W Microsoft Robotics Studio Runtime aplikacja jest zbiorem serwisów, które bazują na rozszerzonej architekturze REST. Dzięki temu można budować rozproszone aplikacje o różnym stopniu złożoności, które z kolei można łączyć w jeszcze bardziej złożone i użyteczne aplikacje. Ze względu na związek z HTTP stan każdego serwisu może być monitorowany i zmieniany poprzezz ten protokół korzystając z przeglądarki internetowej lub poprzez bazujący na SOAP protokole DSSP (z ang. Decentralized Software Services Protocol) 18

20 HTTP umożliwia wykonywanie operacji GET, PUT, POST i DELETE. DSSP umożliwia wykonywanie operacji UPDATE, INSERT i QUERY a poza tym zapewnia event notification oraz structured data manipulation 19

21 2. Wprowadzenie do symulacji w Microsoft Robotics Studio 1.5 Microsoft Robotics Studio jest produktem, którego głównym celem jest przyśpieszenie testowania i wytwarzania aplikacji dla robotów. Jednym z jego najważniejszych składników jest środowisko symulacyjne. Technologie, takie jak realistyczne wizualizacje czy realistyczny silnik fizyki, na bazie których powstało środowisko symulacyjne MSRS, były przez lata rozwijane i stosowane do tworzenia gier na komputery PC oraz konsole. Źródłem informacji na temat symulacji w Microsoft Robotocs Studio są [8], [3], [4] 2.1. Po co stosować symulację Drogi i trudny w zdobyciu sprzęt do konstrukcji robotów Modularne platformy do tworzenia robotów takie jak LEGO MINDSTORMS lub Fischertechnik sprawiły, że robotyka stała się bardziej dostępna dla szerszego grona odbiorców. Jest ot bardzo dobre rozwiązanie do celów edukacyjnych i dla hobbistów. Jednak gdy chcemy zwiększyć poziom złożoności robota lub zwiększyć znacznie liczbę robotów, to koszt takiego przedsięwzięcia może być znaczny Złożone i trudne rozwiązywanie problemów sprzętowych Naprawa i obsługa sprzętu technicznego jest zazwyczaj trudna. Diagnozowanie problemów nawet dla sprzętu ogólno dostępnego i powszechnego tak jak odtwarzacze DVD czy telewizory jest zadaniem czasochłonnym, oraz wymagającym odpowiedniej wiedzy i umiejętności. Budowanie robota wymaga bardziej zaawansowanych umiejętności i wiedzy a czas potrzebny na wykonanie tego zadania jest nieporównywalnie większy Trudności przy pracy grupowej Konstruowanie zaawansowanych robotów w grupie wieloosobowej jest dużym problemem. Po pierwsze zaawansowany technologicznie robot jest drogi a po drugie jest tylko jeden robot. Te dwa problemy uniemożliwiają wykorzystanie, projektowanie i testowanie robota przez kilka zespołów jednocześnie. Z tego powodu roboty bywają 20

22 wykonywane w częściach, przez kilka różnych zespołów. Powoduje to niestety duże problemy przy składaniu wykonanych komponentów w jedną działającą całość Symulacja w Microsoft Robotics Studio, jej wady i zalety Zalety Niski koszt symulacji pozwala ludziom wyposażonym w zwyczajne komputery osobiste projektować roboty i grupy robotów, których złożoność i zastosowane jest ograniczona jedynie przez wyobraźnię użytkownika i czas. Do tego, dzięki w miarę realistycznemu i zbliżonemu do fizycznych warunków środowisku, koncepcje opracowane w świecie wirtualnym mogą zostać przeniesione do świata rzeczywistego w prawie niezmienionej formie. Microsoft Robotic Studio, umożliwia projektowanie, symulowanie i testowanie części koncepcji, bez konieczności ukończenia całego rozwiązania. Oznacza to, że można zacząć testowanie swojego pomysłu na bardzo wczesnym etapie wytwarzania przy pomocy prostych modeli. W łatwy i szybki sposób można stworzyć środowisko, w którym będziemy mogli testować podstawowe funkcjonalności naszego robota i wychwycić ewentualne błędy we wczesnej fazie projektu. Symulacja może być bardzo przydatnym narzędziem przy kształceniu studentów. Za jej pomocą można z łatwością przeanalizować wiele scenariuszy i powtarzać je wielokrotnie z dobrym skutkiem. Można również przedstawiać koncepcje czysto hipotetyczne, które byłyby trudne do zrealizowania lecz są przydatne dla celów edukacyjnych lub naukowych. Kolejnym ciekawym zastosowaniem symulacji jest to, że może być ona uruchomiona w czasie działa prawdziwego robota. Możemy testować pomysły w wirtualnym świecie, bazując na danych pochodzących z sensorów prawdziwego robota. Dzięki temu, z pewnym prawdopodobieństwem możemy określić, które z zachowań robota mogłoby być lepsze w danej sytuacji. 21

23 Wady i ograniczenia symulacji Problemy i ograniczenia symulacji wynikają z dwóch przyczyn. Po pierwsze trudno jest przenieść ograniczenia i wady sprzętu, z którego budowane są roboty do świata symulacji. Po drugie tworzenie oprogramowania i modelu fizycznego prowadzi do powstania kolejnych ograniczeń. Przez to można przy wytwarzaniu i testowaniu aplikacji wyróżnić miejsca, w których symulacja sprawdza się dobrze jak i miejsca w których wykorzystanie sprzętowych podzespołów robota daje lepsze rezultaty i jest łatwiejsze. Gama zagadnień, w których środowisko symulacyjne jest lepszym rozwiązaniem jest większa i dzięki ciągłemu rozwojowi środowiska stale się powiększa. Przetestowanie robota nawet w bardzo dobrym środowisku symulacyjnym nie jest gwarancją na jego poprawne działanie w rzeczywistym świecie. Dzieje się tak dlatego że świat rzeczywisty jest bardzo złożony, pełen zaszumionych sygnałów oraz dodatkowych bodźców, których nie da się przewidzieć w symulacji. Wiele bodźców i zjawisk występujących w świecie rzeczywistym dzieje się w sposób nieoczekiwany, nieregularny lub jest bardzo trudna do zamodelowania. Oznacza to, że zamodelowanie pewnych czynników jest trudne lub niemożliwe do wykonania dla symulacji w czasie rzeczywistym. Środowisko symulacyjne umożliwia łatwe i szybkie umiejscowienie robota w wirtualnym świecie i wymuszenie na nim interakcji z obiektami. Mimo to potrzeba sporo czasu na testy w celu dostrojenia symulowanych sensorów tak aby zachowywały się porównywalnie z tymi rzeczywistymi. Technologia AGEIA PhysX Technology ułatwia to zadanie. Ale przez to trzeba więcej czasu poświęcić na obsługę narzędzi służących do nastawiania parametrów symulacji oraz naukę ich obsługi. 22

24 2.3. Architektura aplikacji symulacyjnej w Microsoft Robotics Studio i przykładowa aplikacja W Microsoft Robotics Studio, środowisko symulacyjne składa się z następujących komponentów: Simulation Engine Service odpowiada za renderowanie elementów oraz odmierzanie czasu na potrzeby silnika fizyki. Śledzi stan całego świata symulacji oraz udostępnia dostęp do symulacji. Managed Physics Engine Wrapper uwalnia użytkownika od korzystania z niskopoziomowego API silnika fizyki, przez co zapewnia bardziej zwięzły interfejs do zarządzania fizyką w świecie symulacji. Native Physics Engine Library umożliwia sprzętowe przyśpieszanie obliczeń fizycznych silnika AGEIA PhysX Technology, który współpracuje z procesorem fizyki AGEIA PhysX Technology znajdującym się na kartach rozszerzeń PhysX Accelerator montowanych w komputerach PC Entities/Encje/Obiekty reprezentują sprzętowe oraz fizyczne obiekty w świecie symulacji. Microsoft Robotics Studio zawiera predefiniowane encje/jednostki, które umożliwiają użytkownikowi na szybkie stworzenie dość złożonego robota i umieszczenie go w zróżnicowanym środowisku symulacyjnym. Aby lepiej zrozumieć istotę symulacji i rolę poszczególnych elementów składowych, zostanie przedstawiona prosta przykładowa aplikacja. Aplika ta będzie tworzyć środowisko symulacyjne z kilkoma robotami. Każdy z robotów będzie wyposażony w podstawowy sprzęt. W celu przetestowania stworzonych przez nas robotów skorzystamy z dostępnej razem z Microsoft Robotic Studio aplikacji Dashboard. Więcej ciekawych przykładów można znaleźć w [12], [13]. 23

25 1. Tworzenie projektu DSS Otwieramy Visual Studio. Tworzymy nowy projekt typu Simple Dss Service (Rysunek 10) Rys. 10 Tworzenie nowego projektu 2. Dodajemy referencje Abyśmy mogli korzystać z MSRS w naszym projekcie, musimy dodać referencje do następujących bibliotek. RoboticsCommon.DLL PhysicsEngine.DLL SimulationCommon.DLL SimulationEngine.DLL SimulationEngine.Proxy.DLL SimulatedBumper.Y2006.M05.Proxy SimulatedDifferentialDrive.2006.M06.Proxy SimulatedLRF.Y2006.M05.Proxy 24

26 SimulatedWebcam.Y2006.M09.Proxy 3. Dodanie using Na górze pliku DssService1.cs dodajemy usingi using Microsoft.Robotics.Simulation; using Microsoft.Robotics.Simulation.Engine; using engineproxy = Microsoft.Robotics.Simulation.Engine.Proxy; using Microsoft.Robotics.Simulation.Physics; using drive = Microsoft.Robotics.Services.Simulation.Drive.Proxy; using lrf = Microsoft.Robotics.Services.Simulation.Sensors.LaserRangeFinder.Proxy; using bumper = Microsoft.Robotics.Services.Simulation.Sensors.Bumper.Proxy; using simwebcam = Microsoft.Robotics.Services.Simulation.Sensors.SimulatedWebcam.Proxy; using Microsoft.Robotics.PhysicalModel; using System.ComponentModel; using Microsoft.Dss.Core.DsspHttp; using System.Net; 4. Dodanie partnera Pod definicją stanu i portu głównego dodajemy definicję partnera [Partner("Engine", Contract = engineproxy.contract.identifier, CreationPolicy = PartnerCreationPolicy.UseExistingOrCreate)] private engineproxy.simulationengineport _engineserviceport = new engineproxy.simulationengineport(); 5. Metoda Start Metoda start to główna metoda każdego serwisu. Zmieniamy jej ciało w następujący sposób. Uruchamiamy w niej bazowy serwis oraz odpalamy metody odpowiedzialne za stworzenie i konfigurację świata symulacji. protected override void Start() { base.start(); SetupCamera(); PopulateWorld(); } 25

27 6. Dodanie pozostałych metod Metody tworzące świat symulacji private void PopulateWorld() { AddSky(); AddGround(); AddCameras(); //AddTable(new Vector3(1, 0.5f, -2)); AddPioneer3DXRobot(new Vector3(1, 0.1f, 0)); AddLegoNxtRobot(new Vector3(2, 0.1f, 0)); } Ustawiamy kamerę główną świata 2.0f)); private void AddCameras() { CameraEntity cam1 = new CameraEntity(640, 480); cam1.state.name = "newcam1"; cam1.state.pose.position = new Vector3(20f, 1f, -10f); cam1.state.pose.orientation = Quaternion.FromAxisAngle(0, 1, 0, (float)(-math.pi / cam1.isrealtimecamera = false; } SimulationEngine.GlobalInstancePort.Insert(cam1); Dodajemy niebo do świata symulacji. Jest to w rzeczywistości protokąt z przypisaną odpowiednią teksturą. Oprócz nieba dodajemy również źródło światła które będzie imitować światło słoneczne. void AddSky() { SkyEntity sky = new SkyEntity("sky.dds", "sky_diff.dds"); SimulationEngine.GlobalInstancePort.Insert(sky); } LightSourceEntity sun = new LightSourceEntity(); sun.state.name = "Sun"; sun.type = LightSourceEntityType.Directional; sun.color = new Vector4(0.8f, 0.8f, 0.8f, 1); sun.direction = new Vector3(-1.0f, -1.0f, 0.5f); SimulationEngine.GlobalInstancePort.Insert(sun); 26

28 Metoda odpowiedzialna za utworzenie ziemi. Tak jak i w przypadku nieba, jest to prostokąt z przypisaną teksturą. W świecie symulacji jest on zdefiniowany jako obiekt specjalny aby silnik symulacji wiedział, że reprezentuje on ziemię. Obiekt ten możne też utworzyć z mapy szarości w celu uzyskania zróżnicowanego terenu. void AddGround() { HeightFieldShapeProperties hf = new HeightFieldShapeProperties("height field", 64, // liczba wierszy 100, // distance in meters, between rows 64, // number of columns 100, // distance in meters, between columns 1, // scale factor to multiple height values -1000); // vertical extent of the height field. Should be set to large negative values hf.heightsamples = new HeightFieldSample[hf.RowCount * hf.columncount]; for (int i = 0; i < hf.rowcount * hf.columncount; i++) { hf.heightsamples[i] = new HeightFieldSample(); hf.heightsamples[i].height = (short)(math.sin(i * 0.01)); } hf.material = new MaterialProperties("ground", 0.8f, 0.5f, 0.8f); SimulationEngine.GlobalInstancePort.Insert(new "03RamieSc.dds")); } HeightFieldEntity(hf, Kolejna metoda tworzy robota z jego serwisami. Podstawą jest tu serwis Pioneer3DX. Do niego dodawane są kolejne serwisy będące serwisami podległymi serwisu reprezentujęcego napęd robota. Na końcu dodajemy całego robota do głównego serwisu symulacji. void AddPioneer3DXRobot(Vector3 position) { Pioneer3DX robotbaseentity = CreateMotorBase(ref position); LaserRangeFinderEntity laser = CreateLaserRangeFinder(); robotbaseentity.insertentity(laser); BumperArrayEntity bumperarray = CreateBumperArray(); robotbaseentity.insertentity(bumperarray); CameraEntity camera = CreateCamera(); robotbaseentity.insertentity(camera); 27

29 } SimulationEngine.GlobalInstancePort.Insert(robotBaseEntity); Metoda tworząca napęd robota Pioneer. Jest to serwis główny symulowanego robota. private Pioneer3DX CreateMotorBase(ref Vector3 position) { Pioneer3DX robotbaseentity = new Pioneer3DX(position); robotbaseentity.state.assets.mesh = "Pioneer3dx.bos"; 1.0f); robotbaseentity.chassisshape.state.diffusecolor = new Vector4(0.8f, 0.25f, 0.25f, robotbaseentity.state.name = "P3DXMotorBase"; drive.contract.createservice(constructorport, Microsoft.Robotics.Simulation.Partners.CreateEntityPartner( " + robotbaseentity.state.name) ); } return robotbaseentity; Metoda tworzy serwis reprezentujący laser. private LaserRangeFinderEntity CreateLaserRangeFinder() { LaserRangeFinderEntity laser = new LaserRangeFinderEntity( new Pose(new Vector3(0, 0.30f, 0))); laser.state.name = "P3DXLaserRangeFinder"; laser.laserbox.state.diffusecolor = new Vector4(0.25f, 0.25f, 0.8f, 1.0f); } lrf.contract.createservice( ConstructorPort, Microsoft.Robotics.Simulation.Partners.CreateEntityPartner( " + laser.state.name)); return laser; Metoda tworząca serwis zderzaka. private BumperArrayEntity CreateBumperArray() { BoxShape frontbumper = new BoxShape( new BoxShapeProperties("front", 0.001f, 28

30 new Pose(new Vector3(0, 0.05f, -0.25f)), new Vector3(0.40f, 0.03f, 0.03f) ) ); frontbumper.state.diffusecolor = new Vector4(0.1f, 0.1f, 0.1f, 1.0f); BoxShape rearbumper = new BoxShape( new BoxShapeProperties("rear", 0.001f, new Pose(new Vector3(0, 0.05f, 0.25f)), new Vector3(0.40f, 0.03f, 0.03f) ) ); rearbumper.state.diffusecolor = new Vector4(0.1f, 0.1f, 0.1f, 1.0f); frontbumper.state.enablecontactnotifications = true; rearbumper.state.enablecontactnotifications = true; BumperArrayEntity bumperarray = new BumperArrayEntity(frontBumper, rearbumper); bumperarray.state.name = "P3DXBumpers"; } bumper.contract.createservice( ConstructorPort, Microsoft.Robotics.Simulation.Partners.CreateEntityPartner( " + bumperarray.state.name)); return bumperarray; Metoda tworząca serwis kamery. private CameraEntity CreateCamera() { CameraEntity cam = new CameraEntity(320, 240); cam.state.name = "robocam"; cam.state.pose.position = new Vector3(0.0f, 0.5f, 0.0f); cam.isrealtimecamera = true; simwebcam.contract.createservice( ConstructorPort, Microsoft.Robotics.Simulation.Partners.CreateEntityPartner( " + cam.state.name) ); } return cam; 29

31 Metoda towżąca symulowanego robota LEGO. Inicjalizacja poszczególnych serwisów odbywa się analogicznie jak przy tworzeniu robota Pioneer. Robot ten różni się od Pionnera tym, że posiada jedynie jeden zderzak (z przodu) i nieposiada kamery. void AddLegoNxtRobot(Vector3 position) { LegoNXTTribot robotbaseentity = CreateLegoNxtMotorBase(ref position); BumperArrayEntity bumperarray = CreateLegoNxtBumper(); robotbaseentity.insertentity(bumperarray); } SimulationEngine.GlobalInstancePort.Insert(robotBaseEntity); private LegoNXTTribot CreateLegoNxtMotorBase(ref Vector3 position) { LegoNXTTribot robotbaseentity = new LegoNXTTribot(position); robotbaseentity.state.assets.mesh = "LegoNXTTribot.bos"; robotbaseentity.state.name = "LegoNXTMotorBase"; } CreateService( drive.contract.identifier, Microsoft.Robotics.Simulation.Partners.CreateEntityPartner( " + robotbaseentity.state.name) ); return robotbaseentity; private BumperArrayEntity CreateLegoNxtBumper() { BoxShape frontbumper = new BoxShape( new BoxShapeProperties( "front", 0.001f, //mass new Pose(new Vector3(0, 0.063f, -0.09f)), //position new Vector3(0.023f, 0.023f, 0.045f))); frontbumper.state.enablecontactnotifications = true; BumperArrayEntity bumperarray = new BumperArrayEntity(frontBumper); bumperarray.state.name = "LegoNXTBumpers"; CreateService( bumper.contract.identifier, 30

32 } Microsoft.Robotics.Simulation.Partners.CreateEntityPartner( " + bumperarray.state.name)); return bumperarray; W tym miejscu zaczynamy tworzyć kolejnego robota dostępnęgo standardowo w Microsoft Robotics Studio. Posiada również jedynie zderzak. Posiada on również miejsze rozmiary. Jego napęd rónież jest prosty (małe koła) przez co nie sprawdza się w trudnym terenie. void AddIRobotCreateRobot(Vector3 position) { IRobotCreate robotbaseentity = CreateIRobotCreateMotorBase(ref position); BumperArrayEntity bumperarray = CreateIRobotCreateBumper(true); robotbaseentity.insertentity(bumperarray); bumperarray = CreateIRobotCreateBumper(false); robotbaseentity.insertentity(bumperarray); } SimulationEngine.GlobalInstancePort.Insert(robotBaseEntity); private IRobotCreate CreateIRobotCreateMotorBase(ref Vector3 position) { IRobotCreate robotbaseentity = new IRobotCreate(position); robotbaseentity.state.assets.mesh = "IRobot-Create.bos"; robotbaseentity.state.name = "IRobotCreateMotorBase"; } CreateService( drive.contract.identifier, Microsoft.Robotics.Simulation.Partners.CreateEntityPartner( " + robotbaseentity.state.name) ); return robotbaseentity; private BumperArrayEntity CreateIRobotCreateBumper(bool isleft) { string Name; Vector3 Offset; float Rotation; if (isleft) { Name = "Left"; Offset = new Vector3(-0.07f, 0.055f, -0.14f); 31

33 Rotation = 1.75f; } else { Name = "Right"; Offset = new Vector3(0.07f, 0.055f, -0.14f); Rotation = -1.75f; } BoxShape Bumper = new BoxShape( new BoxShapeProperties( Name, 0.001f, //mass new Pose(Offset, // position Quaternion.FromAxisAngle(0, 1, 0, (float)(rotation * Math.PI / 2.0f))), // rotation new Vector3(0.15f, 0.06f, 0.01f))); // dimensions Bumper.State.EnableContactNotifications = true; BumperArrayEntity bumperarray = new BumperArrayEntity(Bumper); bumperarray.state.name = "IRobotCreateBumper" + Name; CreateService( bumper.contract.identifier, Microsoft.Robotics.Simulation.Partners.CreateEntityPartner( " + bumperarray.state.name)); } return bumperarray; [ServiceHandler(ServiceHandlerBehavior.Concurrent)] Metody poniżej reprezentują odpowiedzialne z obsługą standardowych operacji. public IEnumerator<ITask> HttpGetHandler(HttpGet get) { get.responseport.post(new HttpResponseType(HttpStatusCode.OK, _state)); } Replace replace = new Replace(); replace.body = _state; replace.body.tablecount++; _mainport.post(replace); yield break; [ServiceHandler(ServiceHandlerBehavior.Exclusive)] public IEnumerator<ITask> ReplaceHandler(Replace replace) { _state = replace.body; replace.responseport.post(new DefaultReplaceResponseType()); 32

34 } yield break; 7. Plik DssService1Types.cs W tym pliku opisujemy głównie stan serwisu. Obywa się poprzez zdefiniowane obiektu opatrzonego atrybutem DataContract, zawierającym pola z atrybutami DataMember. public static class Contract { public const string Identifier =" } [DataContract] public class DssService1State { [DataMember] public string Message; public DssService1State(string message) { Message = message; } [DataMember] public int TableCount; public DssService1State() { } } public class Replace : Replace<DssService1State, DsspResponsePort<DefaultReplaceResponseType>> { } [ServicePort] public class DssService1Operations : PortSet<DsspDefaultLookup, DsspDefaultDrop, HttpGet, Replace> { } 8. Plik DssService1.manifest.xml W pliku manifest definiujemy jakie serwisy chcemy uruchomić. Plik ten podajemy jako parametr programu DssNode. W naszym przykładzie startujemy serwis, który tworzymy czyli 33

35 dssservice1 oraz standardowy serwis dostarczony razem z MSRS simpledashbord. Udostępnia on funkcjonalność przeglądania i sterowania serwisami robotów. <?xml version="1.0"?> <Manifest xmlns=" xmlns:dssp=" <CreateServiceList> <ServiceRecordType> <dssp:contract> </ServiceRecordType> <ServiceRecordType> <dssp:contract> ct> </ServiceRecordType> </CreateServiceList> </Manifest> 9. Uruchomienie programu i efekty działania. Jak widzimy na Rysunku 11, Microsoft Robotic Studio dodało do ustawień projektu odpowiednie opcje, pozwalające uruchomić nasz projekt. Należy pamiętać o tym, że nasz projekt nie jest samo wykonywalnym programem lecz serwisem. Tak jak każdy serwis musi on mieć swój program hostujący. Do uruchamiania serwisów Robotic Studio udostępnia program dsshost. Przyjmuje on jako parametr lokalizację do pliku manifest określającego, które serwisy mają być uruchomione oraz numery portów dla każdego z wystartowanych serwisów. Serwisy mogą pracować na dowolnych portach (poza portami dobrze znanymi). 34

36 Rys. 11 Okno projektu Aby przetestować nasz projekt postępujemy dokładnie tak samo jak z innymi projektami stworzonymi za pomocą Visual Studio. Klikamy prawym klawiszem myszki na projekcie (Rysunek 12). Z menu kontekstowego wybieramy Debug a następnie Start New Instance. Możemy również po prostu nacisnąć na klawiaturze klawisz F5. Rys. 12 Uruchomienie projektu 35

37 Gdy nasz serwis zostanie zbudowany, uruchomiony zostanie program dssnode.exe.w pierwszej kolejności wyświetli się konsola systemu Windows. Możemy na niej śledzić postępy w uruchamianiu poszczególnych serwisów i przeczytać ewentualne komunikaty o błędach jakie mogły zaistnieć w czasie uruchamiania aplikacji. Jeżeli wszystko poprawnie ustawiliśmy po krótkim czasie powinniśmy zobaczyć okno świata symulacji oraz okno programu Dashboard (Rysunek 13). Rys. 13 Uruchomiony projekt Przy pomocy programu Dashboard (Rysunek 14) możemy podejrzeć uruchomione serwisy, sterować serwisami reprezentującymi napęd robotów oraz przechwytywać dane z czujnika laserowego. Wystarczy w prawym górnym okienku wpisać adres serwera (w naszym przypadku wystarczy wpisać localhost ) i przycisnąć klawisz connect. Na liście pod spodem wyświetlą się serwisy kamer i napędów. Po dwukrotnym kliknięciu na któryś z napędów możemy zacząć sterować robotem. W lewym górnym rogu klikamy przycisk driver i za pomocą okrągłego pola sterujemy wybranym wcześniej robotem. 36

38 Rys. 14 Program Dashboard Na samym dole okienka aplikacji Dashboard widzimy okienko reprezentujące dane z czujnika laserowego. Gdybyśmy dodali jakieś obiekty, które dostałyby się w wiązkę lasera czujnika robota Pionier otrzymalibyśmy na tym ekranie przybliżony obraz tego obiektu. Rysunek 15 przedstawia przykład naszej aplikacji z dwom robotami Pionier i stołem. Pionier najbliżej nas ma włączony dalmierz laserowy. Pionier stojący naprzeciwko naszego robota jest reprezentowany na ekranie jako graniastosłup. Nogi od stołu widzimy jako dwa równoległe graniastosłupy. Robot LEGO jest zbyt niski. Nie przecina on wiązki laserowej naszego robota i przez to nie jest on widoczny na obrazie powstałym na podstawie danych zebranych przez dalmierz. 37

39 Rys. 15 Przykład aplikacji z robotami Pionier, robotem LEGO i stołem Istnieje również możliwość sprawdzenia naszej aplikacji bez korzystania z aplikacji Dashboard. Możemy do tego celu użyć przeglądarki internetowej (Rysunek 16). Uruchamiamy naszą aplikację. Gdy wszystko już działa włączmy przeglądarkę Internet Explorer (podgląd dla przeglądarki Firefox nie jest możliwy) i podajemy adres Rys. 16 Sprawdzenie aplikacji za pomocą przeglądarki internetowej 38

40 Po lewej stronie mamy dostępne menu. Aby zaspokoić naszą ciekawość wystarczy wybrać opcję Sernice Direktory (Rysunek 17). Pozwoli nam to obejrzeć listę uruchomionych serwisów. Po dokładniejszym przyjrzeniu się tej liście na pewno odnajdziemy serwisy napędów, zderzaków oraz dalmierza laserowego. Rys. 17 Lista uruchomionych serwisów Po kliknięciu na któryś z serwisów, możemy obejrzeć jego aktualny stan. Oto przykładowy stan serwisu reprezentującego napęd dyferencyjny: <?xml version="1.0" encoding="utf-8"?> <DriveDifferentialTwoWheelState xmlns:s=" xmlns:wsa=" xmlns:d=" xmlns=" <TimeStamp> T21:14: :00</TimeStamp> <LeftWheel> <WheelSpeed xmlns=" <MotorState xmlns=" <HardwareIdentifier>0</HardwareIdentifier> <CurrentPower>0</CurrentPower> <PowerScalingFactor>30</PowerScalingFactor> <ReversePolarity>false</ReversePolarity> <Pose> <Position xmlns=" ml"> <X>0</X> <Y>0</Y> 39

41 40 <Z>0</Z> </Position> <Orientation xmlns=" ml"> <X>0</X> <Y>0</Y> <Z>0</Z> <W>0</W> </Orientation> </Pose> </MotorState> <Radius xmlns=" <GearRatio xmlns=" </LeftWheel> <RightWheel> <WheelSpeed xmlns=" <MotorState xmlns=" <HardwareIdentifier>0</HardwareIdentifier> <CurrentPower>0</CurrentPower> <PowerScalingFactor>30</PowerScalingFactor> <ReversePolarity>false</ReversePolarity> <Pose> <Position xmlns=" <X>0</X> <Y>0</Y> <Z>0</Z> </Position> <Orientation xmlns=" ml"> <X>0</X> <Y>0</Y> <Z>0</Z> <W>0</W> </Orientation> </Pose> </MotorState> <Radius xmlns=" <GearRatio xmlns=" </RightWheel> <DistanceBetweenWheels> </DistanceBetweenWheels> <IsEnabled>false</IsEnabled> <DriveState>NotSpecified</DriveState> </DriveDifferentialTwoWheelState>

42 3. Metody sterowania robotów 3.1. Opis metod i podstawy teoretyczne Rozdział ten ma na celu przedstawienie w ogólny sposób rozważań teoretycznych na temat sterowania ruchem robotów. W tym rozdziale przedstawię krótką i ogólną analizę poszczególnych algorytmów. Analiz jest pobieżna i przedstawia tylko najważniejsze jej fragmenty. Bardziej szczegółową analizę można znaleźć w pracach [1], [2], [3], na podstawie których ten rozdział powstał. Metody sterowania robotów (Rysunek 18) opierają się w głównej mierze o model matematyczny obiektu oraz jego parametry. Czasami dokładne wyznaczenie modelu interesującego nas obiektu jest trudne lub niemożliwe ze względu na znaczną liczbę równań nieliniowych i zmiennych. Dlatego właśnie często przy projektowaniu układów sterowania stosuje się metody sterowania odpornego oraz adaptacyjnego, które nie wymagają dokładnego opisu układu sterowanego. Sterowanie odporne opiera się o wyznaczenie dokładności modelu, czyli określeniu maksymalnego zakresu zmian parametrów obiektu regulowanego. Na tej podstawie projektuje się regulator zwany regulatorem odpornym, którego zadaniem jest kompensacja nieliniowości obiektu oraz stabilizacja pracy obiektu. Tak powstały model (obiekt + regulator) pracujący w układzie sterowania zamkniętym będzie pracował poprawnie w założonym zakresie zmian parametrów obiektu. Przy metodzie sterowania adaptacyjnego sytuacja ma się nieco inaczej. Mianowicie algorytm sterowania projektowany jest w taki sposób, aby mógł samodzielnie modyfikować swoje własności podczas zmieniających się warunków pracy układu. W porównaniu do sterowania odpornego metoda ta posiada jedną istotną cechę szczególną, mianowicie musi zachodzić zbieżność szacowania wartości parametrów do rzeczywistych parametrów obiektu. W przypadku tej metody sterowania praca układu jest stabilna oraz zapewnia nadążanie (minimalizacja czasu opóźnienia) sygnału wyjściowego obiektu w porównaniu do sygnału wymuszenia. Poza wymienionymi wyżej metodami projektowania układów sterowania w ostatnich latach pojawiła się jeszcze jedna, która zaczyna odgrywać coraz większą rolę. Jest to metoda oparta o sieci neuronów i logikę rozmytą. Sieci neuronowe stosowane są do projektowania układów sterowania w warunkach niepewności, gdy posiadamy zbyt mały zasób wiedzy na temat obiektu jak i jego otoczenia. Dlatego też ze względu na zdolność uczenia się oraz 41

43 adaptacji sieci stały się doskonałym narzędziem do aproksymacji dowolnych odwzorowań nieliniowych, jak i analizy tych układów. W przypadku połączenia sieci neuronowych z układami opartymi o logikę rozmytą otrzymujemy doskonałe narzędzie do analizy układów dynamicznych. Układy te oparte są informacje lingwistyczne, które to operują pojęciami opisowymi (sieci neuronowe oparte są w głównej mierze o informacje numeryczne) przez co mogą odzwierciedlać funkcje nieliniowe w sposób bardziej dokładny. W praktyce zadaniem bardzo trudnym jest opracowanie modelu, który dokładnie by opisywał obiekt. Dzieje się tak dlatego, że większość parametrów obiektu zmienia się w czasie jego pracy. Dlatego właśnie modele, które stosowane są do opisu obiektów tylko w przybliżeniu opisują badany obiekt. Rys. 18 Schemat układu sterowania robotów Sterowanie odporne Układ sterowania nazywamy układem odpornym, wtedy gdy pomimo oddziaływania na niego zakłóceń parametrycznych i nieparametrycznych pozostaje on stabilny i zapewnia założoną dokładność sterowania (Rysunek 19). Oznacza to tolerancję dla błędów, takich jak niewłaściwa struktura modelu lub zmiana parametrów obiektu (współczynnik wzmocnienia, stałe czasowe, opóźnienia) Odporność regulatora może tu oznaczać jego poprawną (stabilną) pracę dla szerokiego pasma przenoszenia a optymalną pracę dla wąskiego. 42

44 Z matematycznego punktu widzenia układy sterowania odpornego mają strukturę składającą się ze sprzężenia kompensującego i sprzężenia zwrotnego. W syntezie odpornego algorytmu sterowania ruchem nadążnym mobilnych robotów kołowych można wykorzystać metodę linearyzacji układu typu wejście-wyjście oraz teorię ruchu ślizgowego układu o zmiennej strukturze. Linearyzację typu wejście-wyjście wykorzystuje się do wyznaczenia liniowej zależności pomiędzy sygnałem wyjściowym a sygnałem sterującym. Dzięki temu uzyskujemy kompensację nieliniowej części układu sterowania. Ruch ślizgowy jest rozumiany jako ruch po pewnej powierzchni w przestrzeni stanu wymuszony przez sygnały sterujące, będące nieciągłymi funkcjami punktów przestrzeni. Zgodnie z założeniami teorii o ruchu ślizgowym, trzeba wyznaczyć takie sterowania, które sprowadzą trajektorię układu z dowolnego punktu przestrzeni stanu do zadanej powierzchni oraz utrzymują trajektorię jej małym otoczeniu. Dzięki temu ruch ślizgowy jest niewrażliwy na zakłócenia. Rys. 19 Schemat układu sterowania odpornego Sterowanie adaptacyjne Wadą sterowania odpornego jest możliwość wystąpienia poślizgów. Możliwość ich wystąpienia bierze się z faktu, że dla niedokładności parametrycznych, zakładamy wartości ograniczeń. Niskie wartości ograniczeń parametrycznych nie są dostępne i stosuje się ich zawyżone estymacje. To z kolei może prowadzić do powstawania zawyżonych amplitud sygnałów serujących. 43

45 Alternatywą dla sterowania odpornego, pozbawioną powyższych niedogodności, jest sterowanie uwzględniające adaptację parametrów dynamicznych równań ruchu (Rysunek 20). Polega to na automatycznym dopasowywaniu się parametrów regulatora (np. współczynnik wzmocnienia, czas całkowania, czas różniczkowania) do zmieniających się właściwości obiektu regulacji. Istnieje wiele metod syntezy adaptacyjnych algorytmów sterowania. Jedną z podstawowych metod jest metoda wyliczanego momentu. Zastosowanie tej metody w syntezie adaptacyjnego algorytmu sterowania jest związane z koniecznością pomiaru przyśpieszeń uogólnionych oraz z założeniem, że estymowana macierz bezwładności jest nieosobliwa, co w warunkach rzeczywistych może być trudne do realizacji. Lepszym rozwiązaniem jest zastosowanie do syntezy adaptacyjnego algorytmu sterowania metody uwzględniającej pasywność układów mechanicznych. Strukturę układu sterowania adaptacyjnego przyjęto taką jak dla sterowania odpornego. Różnica pomiędzy tymi układami polega na tym, że w sterowaniu adaptacyjnym wartość parametrów modelu matematycznego mobilnego robota są uaktualniane na bieżąco, według przyjętego prawa estymacji. Rys. 20 Odporny układ sterowania z adaptacją parametrów Sterowanie neuronowe W matematycznych algorytmach sterowania ruchem nadążnym robotów mobilnych stosuje się również metody oparte na sztucznych sieciach neuronowych oraz logice rozmytej. Główną cechą tych podejść, pomocną przy rozwiązywaniu tego typu zagadnień, jest zdolność 44

46 do aproksymacji odwzorowań nieliniowych. Przy syntezie algorytmów sterowania tymi metodami przyjmujemy te same równania ruchu co przy sterowaniu odpornym i adaptacyjnym. W opisanych wyżej metodach, rozwiązanie sterowania otrzymywaliśmy poprzez aproksymację nieliniowych funkcji z członu kompensującego. Przy tym podejściu zakładaliśmy że nieliniowa funkcja jest kombinacją znanych funkcji podstawowych (linowych lub nie). Do aproksymacji tej nieliniowej funkcji możemy zastosować siec neuronową (Rysunek 21). Rys. 181 Schemat układu sterowania neuronowego Sterowanie rozmyte Układy z logiką rozmytą możemy stosować do sterowania układami dynamicznymi, których modele jedynie w przybliżeniu opisują własności sterowanego obiektu (Rysunek 22). W zadaniu syntezy adaptacyjnych układów sterowania zakłada sie ze funkcja nieliniowa jest kombinacją znanych funkcji podstawowych. Sieci neuronowe wykorzystują informacje numeryczne wiążące jednoznacznie sygnały wejściowe i wyjściowe. Układy z logiką rozmytą wykorzystują informacje w postaci pojęć opisowych. Pojęciom opisowym 45

47 przypisane są zmienne numeryczne. Funkcje opisujące z zależności tych zmiennych tworzą reguły opisujące system. Rys. 22 Układ sterowania logiką rozmytą 3.2. Sterowanie grupą robotów Każdy sobie Jest to prosty algorytm sterowania grupą robotów. W tej metodzie każdy z robotów sterowany jest oddzielnie. Nie występuje tu żadna wymiana komunikatów. W przedstawionej tu implementacji roboty będą korzystać ze zderzaka. Każdy z robotów porusza się samodzielnie aż do napotkania przeszkody. Po uderzeniu w przeszkodę serwis reprezentujący zderzak robota wysyła odpowiedni komunikat (zmian stanu serwisu) do serwisu nasłuchującego. Serwis nasłuchujący otrzymuje komunikat i wysyła inny komunikat do 46

48 serwisu reprezentującego napęd. Informacje z komunikatów przychodzących z serwisu reprezentującego zderzak nie są nigdzie zapamiętywane. Serwisy napędu i zderzaka są zadeklarowane jako serwisy partnerujące serwisu będącego naszą aplikacją Robot matka W tym algorytmie roboty mają przypisaną jedną z dwóch ról. Robota matki lub robota podległego. Robot matka to robot, który podejmuje decyzję. To on porusza się jako pierwszy, gromadzi potrzebne dane i wydaje komunikaty sterujące do robota podległego. Robot podległy ma za zadanie jedynie podążać za robotem matką. Algorytm ten nie gwarantuje bezpieczeństwa robota podległego. Robot matka nie ma zazwyczaj informacji o tym co dzieje się z robotem podległym. Roboto matka może z sukcesem pokonać przeszkodę terenową podczas gdy robot podległy może na niej utknąć. Wynika to z faktu że robot podległy nie porusza się idealnie po tej samej trajektorii co robot matka. Wpływ na to może mieć również inna budowa obydwu robotów Sterowanie na podstawie zgromadzonych danych W tej metodzie robot sterujący posiada pamięć. Może to być robot sterujący samym sobą jak również robot matka. W przedstawionej implementacji pamięć robota przedstawiona jest jako mapa. Mapę tą robot generuje dynamicznie podczas poznawania świata. Do poznawania świata robot używa dalmierza laserowego. Wszystkie dane przychodzące od serwisu dalmierza do aplikacji sterującą są używane do modyfikacji mapy. Gdy na podstawie przesłanych danych, serwis sterujący stwierdzi, że robot zbliża się do przeszkody, serwis napędu robota otrzyma komunikat każący mu zatrzymać ruch robota. Następnie na podstawie zebranych wcześniej jak i aktualnych danych, serwis sterujący podejmie decyzję, w którą stronę robot powinien kontynuować swój ruch. 47

49 4. Opis pracy 4.1. Założenia projektu Tematem pracy jest poznanie środowiska Microsoft Robotic Studio (MSRS), zbadanie jego możliwości i przetestowanie go pod kątem symulacji robotów. Tematem pracy jest również przetestowanie różnych algorytmów sterowania robotami jak i przebadania sposobów ich implementacji i możliwości. Część praktyczna powstała na podstawie prac [14], [15], [16], [17], [4], [5] Co zostało zrobione. Opis aplikacji i instrukcja obsługi Część praktyczna pracy składa się z pięciu projektów. Cztery projekty opisują implementację zachowania robotów. Jeden projekt jest odpowiedzialny za tworzenie świata symulacji i robotów. Wszystkie projekty zostały wykonane na bazie materiałów dostępnych razem ze środowiskiem MSRS. Praca autorska polegała na przystosowaniu przykładów do obsługi dwóch robotów oraz zmiany środowiska symulacyjnego pod kątem testowanych algorytmów. Głównym zagadnieniem jakiemu trzeba było sprostać podczas tworzenia projektów była obsługa i koordynacja pracy rozproszonej aplikacji Tworzenie wirtualnego świata Projekt w katalogu Teren odpowiada za tworzenie terenu symulacji dla trzech z czterech symulacji. Jego zadaniem jest wygenerowanie terenu z bitmapy oraz stworzenie serwisu świata symulacji oraz serwisów dla dwóch robotów Pionier. Każdy robot składa się z napędu, zderzaka, lasera i kamery. Dla każdej symulacji wykorzystuje inny teren. Aby każdą symulacji oglądać w innym otoczeniu należy przed uruchomieniem każdej z symulacji przebudować projekt odpowiedzialny za generowanie świata symulacji. Do tworzenia świata symulacji możemy również użyć wbudowanego w MSRS narzędzia Visual Simulation Environment (Rysunek 23). Dzięki niemu możemy naszą symulację stworzyć w sposób niewymagający kodowania. Wystarczy dodawać interesujące nas elementy z odpowiedniego menu. 48

50 Rys. 23 Przykładowe uruchomienie środowiska Visual Simulation Environment Po zakończeniu pracy, naszą symulację zapisujemy do pliku xml. Microsoft Visual Studio Environment utworzy we wskazanej przez nas lokalizacji dwa pliki: naszasymulacja.config.xml oraz naszasymulacja.config.manifest.xml. Pierwszy z nich zawiera opis stworzonej przez nas symulacji. Znajdują się tam dokładne definicje obiektów, ich położenie, wygląd oraz funkcja. Drugi plik jest odpowiednikiem normalnego pliku manifest dla serwisu. Definiujemy w nim jakie serwisy są udostępniane przez stworzony przez nas świat symulacji. Obydwa sposoby generowania świata symulacji dają te same efekty. Wersja z generowaniem opisu świata wydaje się być bardziej mobilna. Korzystając z wizualnego edytora mamy możliwość oglądania wirtualnego świata w trakcie jego tworzenia. Ten wariant wydaje się być bardziej przyjazny użytkownikowi. Z kolei przy wczytywaniu terenu z bitmapy jesteśmy w stanie w znacznie krótszym czasie wygenerować różne przeszkody. Roboty musimy w tym wariancie zakodować ręcznie. 49

51 4.3. Przeprowadzone symulacje i ich wyniki Do uruchamiania aplikacji służą pliki bat. Do każdego projektu są również skrypty przebudowujące dany projekt. Niektóre aplikacje przed uruchomieniem należy przebudować ponieważ mają one czasem tą samą nazwę serwisów. Jeżeli ich nie przebudujemy nie uzyskamy oczekiwanej funkcjonalności. Trzy z czterech aplikacji korzystają ze wspólnego serwisu symulacji. Wymusza to każdorazowe przebudowanie świata symulacji pod konkretną symulację. Trzeba to zrobić ręcznie. Uruchamiamy projekt symulacji. Od linii 128 do 136 mamy następujący fragment kodu: // ZMIANA MAPY: //Mapa dla symulacji ze zderzakami //_state.maze Robotics Studio (1.5)\PracaInzynierska\Teren\ModelLarge.bmp"; //Mapa dla symulacji z laserami //_state.maze Robotics Studio (1.5)\PracaInzynierska\Teren\ModelLargeLaser.bmp"; //Mapa dla symulacji z laserami i robotem matka _state.maze Robotics Studio (1.5)\PracaInzynierska\Teren\ModelLargeTunel.bmp"; Dla każdej symulacji naluży odkomętować jeden z trzech fragmętów kodu i zakomętowaćdwa pozostałe. Dla symulacji pierwszej musimy mieć odkomętowany kod w lini 130. Dla symulacji drugiej potrzebujemy kodu w lini 133. Dla symuolacji trzeciej potrzebujemy kodu z lini 136. Kolejnym krokiem jest ustalenie pozycji robotów w symulowanym świecie. Odbywa się to w liniach od 900 do 916. //Pozycja robotow do symulacji jeden za drugim Vector3 position = new Vector3(_state.RobotStartCellCol * -_state.gridspacing, 0.05f, -(_state.robotstartcellrow * _state.gridspacing)); Vector3 position2 = new Vector3(_state.RobotStartCellCol * -_state.gridspacing, 0.05f, -(_state.robotstartcellrow * _state.gridspacing) - 1); //pozycja robotow do symulacji zderzaki i lasery //Vector3 position = new Vector3(_state.RobotStartCellCol * -_state.gridspacing, // 0.05f, // -(_state.robotstartcellrow * _state.gridspacing)); 1, //Vector3 position2 = new Vector3(_state.RobotStartCellCol * -_state.gridspacing + // 0.05f, // -(_state.robotstartcellrow * _state.gridspacing) + 1); 50

52 Dla symulacji pierwszej i drugiej kożystamy z wektórw zdefiniowanych w liniach 910 i 914 a dla symulacji czwartej kożystamy z wektorów z lini 900 i 904. Po modyfikacji kodu należy przebudować projekt. Aby zakończyć uruchomioną symulację, należy z menu File wybrać opcję Exit Simulatior (Rysunek 24). Rys. 24 Zamykanie okna symulacji 51

53 Symulacja robotów ze zderzakami W pierwszej symulacji oba roboty poruszają się po symulowanym świecie. Sensorem, z którego korzystają jest zderzak (Rysunek 25). Algorytm sterowania polega na tym, że po uderzeniu w przeszkodę, jest wysyłany komunikat informujący o takim zdarzeniu. Po odebraniu tego komunikatu, robot cofa sie, obraca w losowym kierunku i jedzie dalej dopóki nie napotka kolejnej przeszkody. Roboty nie znają swojego wzajemnego położenia i w razie kolizji każdy z nich traktuje to jako uderzenie w statyczną przeszkodę. Rys. 25 Zrzut ekranu z symulacji robotów ze zderzakami Każdy z robotów korzysta z serwisu napęd i zderzak. Pełne roboty (z serwisami odpowiedzialnymi za zderzak, laser, kamerę napęd) są zaimplementowane w projekcie reprezentującym środowisko symulacji. Aby uruchomić aplikację należy ją najpierw przebudować. Aby to uczynić, należy uruchomić skrypt przebuduj_symulacja_1.bat. Po przebudowaniu należy uruchomić skrypt symulacja_1.bat. Po uruchomieniu aplikacji powinniśmy zobaczyć okno symulacji i okno programu Dashboard (Rysunek 26). 52

54 Rys. 26 Okno programu Dashboard dla pierwszej symulacji Aby zainicjować algorytm na zderzak robota musi zostać uderzony. Aby tego dokonać należy w prawym górnym rogu aplikacji Dashboard (Rysunek 26) kliknąć przycisk Connect, potem na liście wybrać serwis /simulateddifferentialdrive/ a następnie w lewym górnym rogu nacisnąć przycisk Driver. Gdy to zrobimy za pomocą szarego koła w lewym górnym rogu możemy sterować wybranym robotem. Po uderzeniu w przeszkodę i po przyjściu pierwszego komunikatu na port serwisu robot powinien zacząć samodzielnie się poruszać. To samo należy wykonać dla drugiego robota, poprzez wybranie na liście kolejnej pozycji /simulateddifferentialdrive/. Algorytm jest prosty i spełnia swoje założenia. Jego pierwowzór był wykorzystywany w symulacji z jednym robotem. Liczba robotów nie ma wpływu na działanie algorytmu. Algorytm przestaje sprawnie funkcjonować w trudnym terenie (wzniesienia). Ze względu na brak terenowego podwozia u robotów, zderzak zawadza w czasie poruszania się o podłoże. Powoduje to zawracanie robota z miejsc, do których byłby w stanie dojechać. 53