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: 189931

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 dr hab. inż. Bartłomiej BELICZYŃSKI, prof. PW (Podpis i pieczątka (Podpis pracownika naukowo – dydaktycznego, dydaktycznego) Kierownika Zakładu Dydaktycznego/Katedry) Termin złożenia pracy: 2008.12.15 Praca wykonana i obroniona pozostaje własnością Instytutu, Katedry i nie będzie zwrócona wykonawcy.

1

 

Wstęp .......................................................................................................................................... 3 

1.  Wprowadzenie do Microsoft Robotics Studio 1.5 ............................................................. 5 

1.1.  Co to jest Microsoft Robotics Studio i jakie są jego możliwości? .............................. 5 

1.2.  Narzędzia i architektura środowiska Microsoft Robotics Studio ................................ 6 

1.2.1.  Język programowania VPL .................................................................................. 7 

1.2.2.  Decentralized Software Services (DSS) koncepcja serwisów ........................... 10 

1.2.3.  Concurrency and Coordination Runtime (CCR) programowanie rozproszone . 14 

1.2.4.  Representational state transfer (REST) .............................................................. 15 

2.  Wprowadzenie do symulacji w Microsoft Robotics Studio 1.5 ....................................... 20 

2.1.  Po co stosować symulację ......................................................................................... 20 

2.1.1.  Drogi i trudny w zdobyciu sprzęt do konstrukcji robotów ................................. 20 

2.1.2.  Złożone i trudne rozwiązywanie problemów sprzętowych ................................ 20 

2.1.3.  Trudności przy pracy grupowej .......................................................................... 20 

2.2.  Symulacja w Microsoft Robotics Studio, jej wady i zalety ....................................... 21 

2.2.1.  Zalety .................................................................................................................. 21 

2.2.2.  Wady i ograniczenia symulacji .......................................................................... 22 

2.3.  Architektura aplikacji symulacyjnej w Microsoft Robotics Studio i przykładowa

aplikacja ............................................................................................................................... 23 

3.  Metody sterowania robotów ............................................................................................. 41 

3.1.  Opis metod i podstawy teoretyczne ........................................................................... 41 

3.1.1.  Sterowanie odporne ............................................................................................ 42 

3.1.2.  Sterowanie adaptacyjne ...................................................................................... 43 

3.1.3.  Sterowanie neuronowe ....................................................................................... 44 

3.1.4.  Sterowanie rozmyte ............................................................................................ 45 

3.2.  Sterowanie grupą robotów ......................................................................................... 46 

3.2.1.  Każdy sobie ........................................................................................................ 46 

3.2.2.  Robot matka ....................................................................................................... 47 

3.2.3.  Sterowanie na podstawie zgromadzonych danych ............................................. 47 

4.  Opis pracy ........................................................................................................................ 48 

4.1.  Założenia projektu ..................................................................................................... 48 

4.2.  Co zostało zrobione. Opis aplikacji i instrukcja obsługi ........................................... 48 

4.2.1.  Tworzenie wirtualnego świata ........................................................................... 48 

2

4.3.  Przeprowadzone symulacje i ich wyniki ................................................................... 50 

4.3.1.  Symulacja robotów ze zderzakami ..................................................................... 52 

4.3.2.  Symulacja robotów z dalmierzem laserowym ................................................... 54 

4.3.3.  Symulacja z robotem matką ............................................................................... 55 

4.3.4.  Symulacja z robotem matką i dalmierzem laserowym ....................................... 57 

4.3.5.  Wnioski .............................................................................................................. 58 

Spis Skrótów ............................................................................................................................ 61 

Spis Rysunków ......................................................................................................................... 62 

Bibliografia ............................................................................................................................... 63 

3

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

4

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.

5

1. Wprowadzenie do Microsoft Robotics Studio 1.5

1.1. 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 ).

6

••• 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®,

802.11, 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.

1.2. 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] .

7

1.2.1. 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ą.

8

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).

9

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.

10

1.2.2. 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

11

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.

12

••• 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ć

13

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.

14

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ć.

1.2.3. 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:

15

• 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.

1.2.4. 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.

Z

aplikacj

złożone

W

zarządc

kompon

przepływ

•••

Zarządca/ko

ji (coraz w

e (Rysunek 8

W sytuacji

a/koordyna

nentów i w

w danych p

••• Pobieran

konkure

zostać z

oordynator

większa licz

8).

i, gdy ka

ator musi z

większej zł

powinna cec

nie danych

encyjnie, ina

zignorowane

Rys. 7 Pr

jest w tym

zba sensoró

Rys. 8 Zło

żdy z sen

arządzać w

łożoności

chować się:

h wejściow

aczej aktor

e.

rosty przepły

m wypadku

ów i aktoró

ożony przepły

nsorów i

większą liczb

zarządcy,

wych i kon

może nie zo

yw danych

prosty, ale

ów) jego za

yw danych

aktorów je

bą kompone

aplikacja o

ntrolowanie

ostać uruch

e w miarę w

adanie staje

est bardzie

entów. Opró

obsługująca

aktorów m

homiony a d

wzrostu zło

e się coraz

ej skomplik

ócz większe

a bardziej

musi odby

dane z senso

16

ożoności

bardziej

kowany,

ej liczby

złożony

ywać się

ora mogą

17

••• 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.

M

struktur

DELAT

daje mo

K

z Web S

zdarzen

stanu s

UPDAT

wydaje

P

subskry

niezależ

reprezen

W

na rozsz

różnym

aplikacj

zmienia

na SOA

Microsoft R

ralny oraz

TE, UPDAT

ożliwość bar

Kolejnym w

Services jes

nia są mode

erwisu rozu

TE. Ponadto

się traktow

Poprzez ok

ybujące ma

żnie od sp

ntacji powia

W Microso

zerzonej ar

m stopniu zło

je. Ze wzgl

any poprzez

AP protokole

Robotics S

definiuje

TE oraz QU

rdziej elasty

ważnym ele

st powiadam

lowane jako

umiemy ja

o operacja

wanie powiad

kreślenie po

ają wspóln

posobu im

adomienia o

oft Robotics

rchitekturze

ożoności, kt

lędu na zwi

z ten protokó

e DSSP (z a

Studio Run

zestaw f

UERY na sta

ycznego spo

ementem jak

mianie o zd

o zmiany st

ko zmianie

UPDATE s

domienia o

owiadomien

ną metodę

mplementacji

o zdarzeniu

Rys. 9 Pow

s Studio Ru

REST. Dz

tóre z kolei

iązek z HTT

ół korzystaj

ang. Decent

ntime pozw

funkcjonaln

anie serwisu

osobu wspó

ki Microsof

arzeniu (Ry

tanu serwis

e stanu ser

sama reprez

zdarzeniu j

nia o zdarze

do monit

i, a serwi

.

wiadamianie o

untime aplik

zięki temu m

można łącz

TP stan każ

jąc z przeg

tralized Soft

wala na rep

ności umoż

u. Takie poł

ółdziałania s

ft Robotics

ysunek 9). W

u. Dla przy

rwisu spow

zentuje zmi

ako operacj

eniu jako z

torowania

isy publiku

o zdarzeniu

kacja jest zb

można bud

zyć w jeszcz

żdego serw

lądarki inte

ftware Servic

prezentacje

żliwiających

łączenie We

serwisów.

Studio Run

W zmienion

ykładu jako

wodowaną d

ianie stanu

ji UPDATE

zmiany stan

stanu serw

ujące mają

biorem serw

dować rozpr

ze bardziej z

wisu może b

ernetowej lu

ces Protoco

zasobu w

h operacje

eb Services

ntime zaado

nym modelu

operacje U

działaniem

tak więc n

E.

nu serwisu,

wisu publik

ą wspólną

wisów, któr

roszone apl

złożone i uż

być monitor

ub poprzez b

ol)

18

sposób

e ADD,

s i REST

optowało

u REST,

UPDATE

operacji

naturalne

serwisy

kującego

metodę

re bazują

likacje o

żyteczne

rowany i

bazujący

19

••• 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

20

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ę

2.1.1. 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.

2.1.2. 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.

2.1.3. 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ą

21

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ść.

2.2. Symulacja w Microsoft Robotics Studio, jej wady i zalety

2.2.1. 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.

22

2.2.2. 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.

23

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].

24

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

25

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();

}

26

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

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 /

2.0f));

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);

}

27

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 HeightFieldEntity(hf,

"03RamieSc.dds"));

}

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);

28

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";

robotBaseEntity.ChassisShape.State.DiffuseColor = new Vector4(0.8f, 0.25f, 0.25f,

1.0f);

robotBaseEntity.State.Name = "P3DXMotorBase";

drive.Contract.CreateService(ConstructorPort,

Microsoft.Robotics.Simulation.Partners.CreateEntityPartner(

"http://localhost/" + 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(

"http://localhost/" + laser.State.Name));

return laser;

}

Metoda tworząca serwis zderzaka.

private BumperArrayEntity CreateBumperArray()

{

BoxShape frontBumper = new BoxShape(

new BoxShapeProperties("front",

0.001f,

29

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(

"http://localhost/" + 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(

"http://localhost/" + cam.State.Name)

);

return cam;

}

30

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(

"http://localhost/" + 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,

31

Microsoft.Robotics.Simulation.Partners.CreateEntityPartner(

"http://localhost/" + 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(

"http://localhost/" + 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);

32

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(

"http://localhost/" + 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());

33

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 ="http://schemas.tempuri.org/2008/08/dssservice1.html";

}

[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

34

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="http://schemas.microsoft.com/xw/2004/10/manifest.html"

xmlns:dssp="http://schemas.microsoft.com/xw/2004/10/dssp.html">

<CreateServiceList>

<ServiceRecordType>

<dssp:Contract>http://schemas.tempuri.org/2008/08/dssservice1.html</dssp:Contract>

</ServiceRecordType>

<ServiceRecordType>

<dssp:Contract>http://schemas.microsoft.com/robotics/2006/01/simpledashboard.html</dssp:Contra

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).

35

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

36

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.

37

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.

38

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

http://localhost:50000/ .

Rys. 16 Sprawdzenie aplikacji za pomocą przeglądarki internetowej

39

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="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:d="http://schemas.microsoft.com/xw/2004/10/dssp.html" xmlns="http://schemas.microsoft.com/robotics/2006/05/drive.html">

<TimeStamp>2008-09-08T21:14:39.125+02:00</TimeStamp> <LeftWheel>

<WheelSpeed xmlns="http://schemas.microsoft.com/robotics/2006/05/motor.html">0</WheelSpeed>

<MotorState xmlns="http://schemas.microsoft.com/robotics/2006/05/motor.html"> <HardwareIdentifier>0</HardwareIdentifier> <CurrentPower>0</CurrentPower> <PowerScalingFactor>30</PowerScalingFactor> <ReversePolarity>false</ReversePolarity>

<Pose> <Position

xmlns="http://schemas.microsoft.com/robotics/2006/07/physicalmodel.html">

<X>0</X> <Y>0</Y>

40

<Z>0</Z> </Position>

<Orientation xmlns="http://schemas.microsoft.com/robotics/2006/07/physicalmodel.html">

<X>0</X> <Y>0</Y> <Z>0</Z> <W>0</W>

</Orientation> </Pose> </MotorState>

<Radius xmlns="http://schemas.microsoft.com/robotics/2006/05/motor.html">0</Radius>

<GearRatio xmlns="http://schemas.microsoft.com/robotics/2006/05/motor.html">0</GearRatio>

</LeftWheel> <RightWheel>

<WheelSpeed xmlns="http://schemas.microsoft.com/robotics/2006/05/motor.html">0</WheelSpeed>

<MotorState xmlns="http://schemas.microsoft.com/robotics/2006/05/motor.html"> <HardwareIdentifier>0</HardwareIdentifier> <CurrentPower>0</CurrentPower> <PowerScalingFactor>30</PowerScalingFactor> <ReversePolarity>false</ReversePolarity>

<Pose> <Position

xmlns="http://schemas.microsoft.com/robotics/2006/07/physicalmodel.html"> <X>0</X> <Y>0</Y> <Z>0</Z>

</Position> <Orientation

xmlns="http://schemas.microsoft.com/robotics/2006/07/physicalmodel.html">

<X>0</X> <Y>0</Y> <Z>0</Z> <W>0</W>

</Orientation> </Pose> </MotorState>

<Radius xmlns="http://schemas.microsoft.com/robotics/2006/05/motor.html">0</Radius>

<GearRatio xmlns="http://schemas.microsoft.com/robotics/2006/05/motor.html">0</GearRatio>

</RightWheel> <DistanceBetweenWheels>0.10499999672174454</DistanceBetweenWheels> <IsEnabled>false</IsEnabled> <DriveState>NotSpecified</DriveState>

</DriveDifferentialTwoWheelState>

41

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

42

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

3.1.1. 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.

43

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

3.1.2. 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.

44

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

3.1.3. 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ść

45

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

3.1.4. 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

46

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

3.2.1. 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

47

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ą.

3.2.2. 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.

3.2.3. 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.

48

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] .

4.2. 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.

4.2.1. 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.

49

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.

50

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 = @"C:\Microsoft Robotics Studio (1.5)\PracaInzynierska\Teren\ModelLarge.bmp"; //Mapa dla symulacji z laserami //_state.Maze = @"C:\Microsoft Robotics Studio (1.5)\PracaInzynierska\Teren\ModelLargeLaser.bmp"; //Mapa dla symulacji z laserami i robotem matka

_state.Maze = @"C:\Microsoft 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)); //Vector3 position2 = new Vector3(_state.RobotStartCellCol * -_state.GridSpacing + 1, // 0.05f, // -(_state.RobotStartCellRow * _state.GridSpacing) + 1);

51

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

52

4.3.1. 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).

53

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ć.

54

4.3.2. Symulacja robotów z dalmierzem laserowym

W symulacji numer dwa roboty korzystają z czujnika laserowego (Rysunek 27).

Badają przy jego pomocy otoczenie i tworzą w pamięci (stanie) serwisu (zewnętrzny ośrodek

decyzyjny) mapę otoczenia. Gdy algorytm na podstawie mapy uzna, że robot zbliża sie do

przeszkody, następuje poszukiwanie pustej przestrzeni. Po odnalezieniu wolnej przestrzeni

robot zaczyna poruszać się w jej kierunku dopóki nie stwierdzi, że zbyt blisko zbliżył się do

przeszkody.

Rys. 27 Zrzut ekranu z symulacji robotów z dalmierzem laserowym

Aby uruchomić aplikację należy ją najpierw przebudować. Aby to uczynić, należy

uruchomić skrypt przebuduj_symulacja_2.bat . Po przebudowaniu należy uruchomić skrypt

symulacja_2.bat . Po uruchomieniu aplikacji powinniśmy zobaczyć okno symulacji, okno

programu Washboard oraz dwa okna z mapami. Algorytm jest inicjalizowany przez

komunikaty z dalmierzy laserowych, więc roboty zaczną się poruszać samodzielnie. Należy

pamiętać o odpowiednim przebudowaniu aplikacji odpowiedzialnej za tworzenie świata

symulacji.

55

Algorytm działa i jest lepszy od poprzedniego. Roboty nie obijają się o przeszkody

stacjonarne ani o mobilne (drugi robot). Mapa powstała na bazie danych z lasera jest

aktualizowana na tyle często, ze nie tworzą sie błędy powstałe w wyniku ruchu przeszkód.

Testowane również była wersja algorytmu ze wspólną mapą dla obydwu robotów. Jednak

poprzez nakładanie się danych obraz mapy nie był czytelny. Powodowało to nieprawidłowe

działanie obydwu robotów. Algorytm ma też trudności z pokonywaniem nierównego trenu.

Na przykład podczas zjazdu ze wzgórza, robot myśli że zbliża się do ściany. Przez to nigdy

nie zdoła zjechać z tego wzgórza. Problemem jest też tu umiejscowienie lasera na pewnej

wysokości. Przez to tylko przeszkody od pewnej granicznej wysokości są zauważane przez

robota.

4.3.3. Symulacja z robotem matką

Algorytm został zaadaptowany z przykładu dostarczonego z MSRS (Rysunek 28 i 29).

W testowanej wersji algorytm został użyty dla większych i bardziej złożonych robotów oraz

w zróżnicowanym terenie. Dla sprawdzenia dodatkowych funkcji przeprowadzone zostały

również symulacje dla inne niż ziemska grawitacji (Rysunek 28).

Rys. 28 Zrzut ekranu symulacji trzeciej dla innej grawitacji niż ziemska

56

Rys. 29 Zrzut ekranu symulacji trzeciej

Aby uruchomić aplikację należy uruchomić skrypt symulacja_3.bat . Po uruchomieniu

aplikacji powinniśmy zobaczyć okno programu symulacji. W tym przykładzie świat symulacji

jest wczytywany z pliku xml. Algorytm ruszy samodzielnie. Roboty powinni same podjechać

do siebie i w sposób losowy określić, który będzie prowadził.

Algorytm w prostym terenie (bez wzniesień) sprawował się dobrze. Problemy

zaczynają sie w trudnym terenie gdy jego struktura ma wpływ na ruch robotów. Przez to ze

robot matka nie ma danych na temat robota, który podąża za nim nie może skorygować jego

ruchu. Błąd ten potęguje sie przy niskich wartościach grawitacji, gdy małe nierówności terenu

powodują znaczne zmiany w torze ruchu robotów. Wynika to głównie z nieprzystosowania

symulowanych robotów od poruszania się w trudnym terenie a tym bardziej przy niskiej

wartości grawitacji.

57

4.3.4. Symulacja z robotem matką i dalmierzem laserowym

W tej symulacji połączone zostały właściwości z symulacji numer 2 i 3 (Rysunek 30).

Robot matka tworzy mapę terenu przy pomocy czujnika laserowego. Na tej podstawie określa

swój tor ruchu i narzuca go podwładnemu robotowi.

Rys. 30 Zrzut ekranu symulacji z robotem matką i dalmierzem laserowym

Aby uruchomić aplikację należy ją najpierw przebudować. Aby to uczynić, należy

uruchomić skrypt przebuduj_symulacja_4.bat . Po przebudowaniu należy uruchomić skrypt

symulacja_4.bat. Po uruchomieniu aplikacji powinniśmy zobaczyć okno symulacji, okno

programu Washboard oraz jedno okno z mapą. Algorytm ruszy samodzielnie. Należy

pamiętać o odpowiednim przebudowaniu aplikacji odpowiedzialnej za tworzenie świata

symulacji.

Algorytm dobrze się sprawdza dla zadań gdzie robot matka musi przeprowadzić robota

podwładnego przez korytarz. W środowisku z dużą ilością małych przeszkód algorytm spisuje

się gorzej. Wynika to z faktu że robot podążający za robotem matką nie myśli. Przez to że

podąża w pewnej odległości za matką ma szansę zablokować się na małej przeszkodzie.

Algorytm źle sobie radzi z pokonywaniem przez roboty ostrych i ciasnych zakrętów, oraz

podczas wymijania gęsto rozmieszczonych przeszkód (slalom).

58

4.3.5. Wnioski

Symulacja pierwsza, w której roboty korzystają ze zderzaków była najprostszą z

przeprowadzonych. Zadaniem robotów było poruszanie się i omijanie uderzonych przeszkód.

W warunkach symulacyjnych algorytm wypadł dobrze dal robotów poruszających się po

płaskim terenie z przeszkodami. W symulacji drugiej algorytm miał nieco trudniejsze zadanie.

Roboty korzystające z dalmierzy laserowych miały omijać przeszkody i nie mogły ich

uderzyć. Tak jak i w symulacji pierwszej algorytm sprawuje się dobrze dla przeszkód

umieszczonych na płaskim terenie. W środowisku w którym występują naturalne

zniekształcenia terenu roboty omijają nawet łagodne wzniesienia ponieważ rejestrowane są

one jako przeszkoda pionowa. Z kolei przeszkody które są niższe niż wysokość na której

znajduje się wiązka lasera są dla robota niewidoczne przez co robot może uderzyć w taką

przeszkodę. Możemy również wyobrazić sytuację w której robot uderzy „głową” w

przeszkodę wystającą z sufitu korytarza, która jest ponad wiązką lasera. W symulacji trzeciej

algorytm miał za zadanie skoordynowanie ruchu dwóch robotów. Tak jak i w poprzednich

symulacjach algorytm spisuje się dobrze na płaskiej powierzchni. W czasie poruszania się w

trudniejszym terenie widać niedoskonałości tego algorytmu polegające głównie na

„bezmyślnym” podążaniu jednego robota za drugim. Można by rozwinąć ten algorytm o

możliwość korekcji położenia robotów względem siebie. Robot matka przekazuje robotowi

podwładnemu jedynie dane dotyczące sygnałów sterujących napędem podwozia. Położenie

robota matki determinują również inne czynniki, takie jak zróżnicowanie terenu (zsuwanie się

robota jadącego po zboczu), przez co robot podążający za nim nie ma informacji o dokładniej

zmianie jego położenia. Z tego właśnie powodu w zróżnicowanym terenie droga po której

powinien podążać robot prowadzony szybko przestaje się pokrywać z drogą robota matki. W

czwartej symulacji mamy podobną sytuację. Tu robot matka używa dalmierza laserowego do

wyznaczania własnej trasy (algorytm z symulacji drugiej) i przesyła sygnały sterujące

robotowi który za nim podąża. Robot matka jest wstanie przeprowadzić robota podległego

przez korytarz z niewielkim łukiem. Problemy zaczynają się przy ostrych zakrętach. Dzieje

się tak dlatego że robot podległy podąża w pewnej odległości od robota matki i może utknąć

na rogu takiego zakrętu. Z tego samego powodu zdarza się że robot podległy utyka na

przeszkodach ominiętych przez robota matkę.

Środowisko symulacyjne z Microsoft Robotics Studio jest ciekawym produktem.

Pozwala w dość prosty i szybki sposób na stworzenie i przetestowanie aplikacji, którą później

możemy wykorzystać do sterowania prostymi robotami. Sprawa komplikuje się niestety gdy

59

chcemy stworzyć symulację dla bardziej złożonego robota wyposażonego w zaawansowane

czujniki. W takim wypadku nie możemy liczyć na zaimplementowane standardowo serwisy.

Nakład pracy potrzebny na stworzenie własnego robota z własnym zestawem czujników jest

duży. Byłoby to zajęcie na długie tygodnie dla kilku programistów, z których każdy musiałby

mieć spore doświadczenie w tworzeniu aplikacji tego typu (opanowanie i zrozumienie REST

oraz CCR).

Z mojej perspektywy praca z Microsoft Robotics Studio jest dość przyjemna. Tutoriale

i przykładowe programy (zarówno te dołączone do MSRS oraz dostępne w sieci) umożliwiają

szybkie stworzenie prostej aplikacji i opanowanie prostych wzorców postępowania. Gorzej

jest niestety z materiałami umożliwiającymi wyjście poza te przykłady. Przykładem może tu

być sterowanie kilkom robotami. Znalazłem tylko jedną przykładową aplikację, w której

sterowane są dwa roboty jednocześnie. Tak samo istnieje tylko jeden przykład z robotem

niebędącym standardowym robotem dostępnym w MSRS.

MSRS okazało się przydatnym narzędziem do testowania algorytmów sterowania

robotami. Dzięki niemu byłem w stanie szybko sprawdzić poszczególne algorytmy w różnych

warunkach terenowych. Takie testy na prawdziwych robotach zajęłyby dużo więcej czasu.

Dzięki symulacji możemy przetestować scenariusze, których w nie moglibyśmy przetestować

w laboratorium. Przykładem może tu być testowanie robotów w bardzo zróżnicowanym

terenie przy różnych wartościach grawitacji.

Rzeczą, o której warto byłoby wspomnieć są wymagania sprzętowe symulacji w

MSRS. Rozproszona architektura aplikacji sprawia nieco problemów. Przez to, że serwisy

współpracujące są luźno sparowane, zdarza się, że nie wszystkie uruchomią się w czasie

kiedy będziemy ich potrzebować. Zdarza się, że aplikacja zaczyna wyszukiwać

symulowanych serwisów (napędy, dalmierze laserowe) i ich nie znajduje. Jeżeli chcemy

stworzyć większą symulację dla więcej niż jednego robota, będziemy potrzebować

dwurdzeniowego procesora. Dla większej liczby złożonych robotów nawet dobry PC może

nie wystarczyć. Silnik grafiki MSRS korzysta z DirectX 9c i jest to ten sam silnik, który jest

używany do tworzenia gier na konsole Xbox. Jeżeli nie posiadamy w systemie

zainstalowanych najnowszych bibliotek DirectX oraz karty graficznej z obsługą sprzętową tej

biblioteki, nasza symulacje nie będzie chciała się uruchomić. W dzisiejszych czasach nie są to

może zbyt wygórowane wymagania, ale warto mieć świadomość, że jeżeli chcemy korzystać

w pełni z tej technologii, musimy dysponować sprzętem nie gorszym niż ten, który był

wysokim standardem dwa - trzy lata temu.

60

Myślę, że za parę lat MSRS będzie znacznie lepiej udokumentowane i będzie znacznie

więcej osób wyspecjalizowanych w jego używaniu. Gdyby istniała większa ilość przykładów

i działających projektów dla MSRS można by łatwiej znaleźć punkt odniesienia dla własnych

rozwiązań. Umożliwiłoby to również sprawdzenie czy to co zrobiliśmy dział w sposób

optymalny.

61

Spis Skrótów MSRS Microsoft Robotics Studio

VPL Visual Programming Language

REST Representational State Transfer

WCF Windows Communication Foundation

CCR Concurrency and Coordination Runtime

DDS Decentralized Software Services

DDSP Decentralized Software Services Protocol

SOAP Simple Object Access Protocol

URI Uniform Resource Identifier

62

Spis Rysunków Rys. 1 Microsoft Visual Programming Language ...................................................................... 7 

Rys. 2 Przepływ danych w Microsoft Visual Programming Language ..................................... 8 

Rys. 3. Elementy bloku czynności ............................................................................................. 8 

Rys. 4. Piny w bloku czynności ................................................................................................. 9 

Rys. 5. Składniki serwisów ...................................................................................................... 11 

Rys. 6 Przesyłanie komunikatów ............................................................................................. 14 

Rys. 7 Prosty przepływ danych ................................................................................................ 16 

Rys. 8 Złożony przepływ danych ............................................................................................. 16 

Rys. 9 Powiadamianie o zdarzeniu .......................................................................................... 18 

Rys. 10 Tworzenie nowego projektu ........................................................................................ 24 

Rys. 11 Okno projektu ............................................................................................................. 35 

Rys. 12 Uruchomienie projektu ............................................................................................... 35 

Rys. 13 Uruchomiony projekt .................................................................................................. 36 

Rys. 14 Program Dashboard ..................................................................................................... 37 

Rys. 15 Przykład aplikacji z robotami Pionier, robotem LEGO i stołem ................................ 38 

Rys. 16 Sprawdzenie aplikacji za pomocą przeglądarki internetowej ..................................... 38 

Rys. 17 Lista uruchomionych serwisów .................................................................................. 39

Rys. 18 Schemat układu sterowania robotów .......................................................................... 42

Rys. 19 Schemat układu sterowania odpornego ....................................................................... 43

Rys. 20 Odporny układ sterowania z adaptacją parametrów ................................................... 44

Rys. 21 Schemat układu sterowania neuronowego .................................................................. 45

Rys. 22 Układ sterowania logiką rozmytą ............................................................................... 46 

Rys. 23 Przykładowe uruchomienie środowiska Visual Simulation Environment .................. 49 

Rys. 24 Zamykanie okna symulacji ......................................................................................... 51 

Rys. 25 Zrzut ekranu z symulacji robotów ze zderzakami ...................................................... 52 

Rys. 26 Okno programu Dashboard dla pierwszej symulacji .................................................. 45 

Rys. 27 Zrzut ekranu z symulacji robotów z dalmierzem laserowym ..................................... 54 

Rys. 28 Zrzut ekranu symulacji trzeciej dla innej grawitacji niż ziemska ............................... 55 

Rys. 29 Zrzut ekranu symulacji trzeciej ................................................................................... 56 

Rys. 30 Zrzut ekranu symulacji z robotem matką i dalmierzem laserowym ........................... 57 

63

Bibliografia [1]. A. Burghardt, Z. Hendzel Sterowanie behawioralne mobilnymi robotami kołowymi,

OWPRz, Reszów 2007

[2]. M. J. Giergiel, Z. Hendzel, W. Żylski Modelowanie i sterowanie mobilnych robotów

kołowych, PWN, Warszawa 2002

[3]. W. Hejmo Sterowanie robotami i manipulatorami przemysłowymi. Modele i metody

matematyczne, Politechnika Krakowska, Kraków 1997

[4]. K. Johns, T. Taylor, Professional Microsoft Robotics Developer Studio, Wrox, 2008

[5]. S. Morgan, Programing Micsosoft Robotics Studio, Microsoft Press, 2008

[6]. Microsoft Robotics Developer Center

http://msdn.microsoft.com/en-us/robotics/default.aspx

[7]. Microsoft Robotics Studio Overview

http://msdn.microsoft.com/pl-pl/library/bb483024(en-us).aspx

[8]. Visual Programming Language

http://msdn.microsoft.com/pl-pl/library/bb905470%28en-us%29.aspx

[9]. CCR User Guide http://msdn.microsoft.com/pl-pl/library/bb905447(en-us).aspx

[10]. DSS User Guide http://msdn.microsoft.com/pl-pl/library/bb905448(en-us).aspx

[11]. DSS Application Model Introduction

http://msdn.microsoft.com/plpl/library/bb466255(en-us).aspx

[12]. Visual Simulation Environment

http://msdn.microsoft.com/plpl/library/bb905471%28en-us%29.aspx

[13]. VPL Tutorials http://msdn.microsoft.com/pl-pl/library/bb964567(en-us).aspx

[14]. MSRS Maze Simulator Trewor Taylor

http://sky.fit.qut.edu.au/~taylort2/MSRS/MazeSimulator/MazeSimulator.htm

[15]. Professional Microsoft Robotics Developer Studio http://www.promrds.com/

[16]. Microsoft Robotics Studio Forum

http://forums.microsoft.com/forums/ShowPost.aspx?PostID=3696744&SiteID=1

[17]. Microsoft Robotics Studio Forum

http://forums.microsoft.com/Forums/default.aspx?ForumGroupID=383&SiteID=1

[18]. LEGO Mindstorms http://mindstorms.lego.com/eng/Black_Destination/Default.aspx

[19]. Nieoficjalna strona LEGO Mindstorms http://www.mindstorms.pl/