politechnika warszawska wydziaŁ elektrycznyczajewsw/studenckie/inne/modzelewski/modzelewski.pdf ·...
TRANSCRIPT
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/