Full documentation

Transkrypt

Full documentation

Program Badań Stosowanych, Numer projektu: PBS1/A3/8/2012
Projekt:
RobREx – Autonomia dla robotów ratowniczo-eksploracyjnych
Raport z wykonanych prac
Ontologia środowiska wspólna dla ludzi
i robotów
Za okres:
styczeń-czerwiec 2015
Zadania:
Ontologia 1, Ontologia 2
Koordynator zadań:
dr hab. Stanisław Ambroszkiewicz
Autonomia dla robotów ratowniczo-eksploracyjnych
wersja 1.0
Spis treści
Informacje o dokumencie ....................................................................................................................... 3
Streszczenie ................................................................................................................................................. 4
1.
Ontologia .......................................................................................................................................... 7
1.1.
Definiowanie pojęć .........................................................................................................................................7
1.2.
Ontologia dla środowiska testowego .....................................................................................................8
1.3.
Mapy obiektowe ........................................................................................................................................... 13
2.
Algorytm uczenia się ................................................................................................................. 14
Zlecanie i wykonanie zadań................................................................................................................................... 31
Sposób integracji Z urządzeniami fizycznymi ............................................................................................... 31
4.
Protokół obsługi transakcji .................................................................................................... 33
5.
Repozytorium .............................................................................................................................. 38
5.1.
Definiowanie typów i zależności między nimi ................................................................................ 38
5.2.
Definiowanie map obiektowych ............................................................................................................ 40
5.3.
Korzystanie z Repozytorium ................................................................................................................... 41
6.
Realizacja zadania ...................................................................................................................... 44
6.2.
Obsługa nieprawidłowych sytuacji ...................................................................................................... 49
7.
Środowisko symulacyjne ......................................................................................................... 53
7.1.
Możliwości środowiska ............................................................................................................................. 53
7.2.
Generowanie środowiska na podstawie map obiektowych...................................................... 53
7.3.
Środowisko testowe.................................................................................................................................... 57
8.
Eksperymenty .............................................................................................................................. 59
8.1.
Scenariusz 1 – transport słoika z szafki na platformę ................................................................. 59
8.2.
Scenariusz 2 – unieszkodliwienie bomby ......................................................................................... 67
8.3.
Scenariusz 3 – Transfer zawartości obiektu .................................................................................... 75
styczeń 2016
2/80
wersja 1.0
Informacje o dokumencie
Numer raportu:
RobREx-O1-O2-RP-01
Koordynator:
S. Ambroszkiewicz
Autorzy:
S. Ambroszkiewicz, W. Bartyna, K. Skarżyński, M. Stępniak,
M. Szymczykowski,
Poziom dostępności:
wewnętrzny
Słowa kluczowe:
system wielorobotowy, roboty mobilne, ontologia, reprezentacja
środowiska, symulacja, SOA, usługi, automatyzacja aranżacja
styczeń 2016
3/80
wersja 1.0
Streszczenie
Reprezentacja środowiska jest abstrakcyjnym, uproszczonym modelem świata. Spośród
wielu pojęć wybierane są tylko te, które są istotne przy realizacji z góry zdefiniowanej klasy
zadań. Dotyczy to atrybutów, obiektów, oraz relacji między nimi. Podejście te nawiązuje do
reprezentacji jaką posługuje się człowiek. Reprezentacja jest wspólna dla ludzi i urządzeń
(robotów), ponieważ ma służyć współdziałaniu. Użytkownik (człowiek), za pomocą
wygodnych interfejsów, definiuje zadania do wykonania przez robota. Robot otrzymuje
wiedzę o środowisku w postaci częściowej mapy, którą może uaktualniać
i uszczegóławiać. Tak rozumiana reprezentacja środowiska została zrealizowana jako
formalna specyfikacja wraz z narzędziem programistycznym (Słownikiem pojęć)
z wygodnym interfejsem graficznym (GUI) dla użytkownika.
Do konstrukcji reprezentacji środowiska (ontologii) zostało użyte pojęcie obiektu, na które
składają się atrybuty (wybrane cechy obiektu), typy obiektów, oraz relacje zachodzące
między obiektami. Każdy obiekt (jako instancja swojego typu) może być traktowany jako
mapa obiektowa na odpowiednim poziomie.
Typ obiektu może agregować atrybuty, jak i inne obiekty (mówimy wtedy, że zawiera
podobiekty), oraz dziedziczyć po innych typach. Dziedziczenie oznacza, że oprócz swoich
własnych atrybutów i podtypów, w jego konstrukcji używane są również te pochodzące z
dziedziczonego typu.
Podczas definiowania typu podawana jest jego nazwa oraz typy, z których ma on
dziedziczyć. Następnie wybierane są atrybuty ze zbioru wcześniej zdefiniowanych
atrybutów, dla których opcjonalnie dodawana jest ilość wystąpień oraz zakres.
Między obiektami
(instancjami typów) mogą występować relacje binarne, które
sprowadzają się do relacji między atrybutami w tych obiektach.
W celu aktualizacji mapy obiektowej wykorzystywany jest algorytm umożliwiający
weryfikację wartości atrybutów obiektów istniejących w mapie obiektowej dla danej
lokalizacji. Natomiast uszczegóławianie mapy polega na dodaniu do niej definicji nowych
obiektów. Akcje te mogą być realizowane jako dedykowane typy usług świadczone przez
urządzenia kognitywne (wyposażone
w sensory). Usługi takich typów mogą być
wywoływane również jako komponenty złożonych zadań, np. w celu ewaluacji sytuacji
w środowisku po wykonaniu zadania przez robota mobilnego.
Kluczowym elementem dla efektywnych algorytmów aktualizacji i uszczegóławiania mapy
jest rozpoznanie kontekstu, w ramach którego będą wykonywane. Kontekstem jest aktualna
lokalizacja robota, a dokładniej element mapy reprezentujący fizyczną lokalizację,
pomieszczenie, w którym dany robot się znajduje. Ustalony kontekst pozwala na
wyznaczenie, podczas rozpoznawania obiektów, zbioru najbardziej prawdopodobnych
typów obiektów i ich instancji.
Tak zaprojektowana i zrealizowana otologia jest wykorzystywana w układach sterujących
robotów oraz w procesie zgłaszania zadań przez człowieka i ich automatycznej realizacji
przez roboty mobilne. Z ontologii korzysta również:

Menedżer Usług odpowiedzialny za integrowanie robotów z systemem,

środowisko symulacyjne służące do wizualizacji map obiektowych za pomocą grafiki
trój-wymiarowej.
Menedżer Usług dostarcza narzędzi umożliwiających wykonanie funkcji (zachowań) robota
w celu osiągnięcia stanu środowiska opisanego przez zadanie. Na podstawie opisu zadania
(opisu sytuacji początkowej i końcowej), oraz danych pobranych z Repozytorium, Menedżer
styczeń 2016
4/80
wersja 1.0
Usług sekwencyjnie zleca zachowania dla jednostek fizycznych w celu osiągnięcia
pożądanego końcowego stanu środowiska opisanego w zadaniu.
Menedżer Usług pełni rolę pośrednika pomiędzy robotem a Menedżerem Zadań. W tym celu
zdefiniowane zostały interfejsy opisujące zachowania robota (jego usługi). Służą one do
konstrukcji planu wykonania usługi w komunikacji pomiędzy robotem a Menedżerem Zadań.
Menedżer Usług powinien znajdować się bezpośrednio na urządzeniu, lub w połączeniu
umożliwiającym komunikację TCP/IP. Dla każdego z urządzeni fizycznych, niezbędna jest
nowa instancja Menedżera Usług.
Żeby zintegrować nowe urządzenie z systemem niezbędne jest zainstalowanie Menedżera
Usług na platformie, która umożliwia komunikację TCP/IP z tym urządzeniem. Następnie
możliwe jest zdefiniowanie zachowań robota za pomocą interfejsu zapewnionego przez
Menedżer Usług oraz wykorzystanie zdefiniowanych zachowań w planie. Wymagane jest, by
urządzenie nasłuchiwało na porcie podanym przez użytkownika, dzięki czemu Menedżer
Usług jest w stanie nawiązać połączenie oraz wysłać parametry zachowania. W trakcie
wykonywania funkcji przez robota, Menedżer Usług będzie oczekiwał na odpowiedź. Po
uzyskaniu odpowiedzi wykonany zostanie kolejny krok planu. W przypadku otrzymania
wiadomości o wystąpieniu błędu, wykonywanie zadania zostanie przerwane oraz
poinformowany zostanie Menedżer Zadań.
W celu ułatwienia implementowania Menedżera Usług dla urządzeń fizycznych zrealizowane
zostały narzędzia programistyczne do:

implementacji mechanizmu nasłuchiwania po stronie urządzenia.

definiowania zadań po stronie Menedżera Usług.

definicji planu usługi, w którym wykorzystane zostaną uprzednio zdefiniowane
zachowania.

zapewnienia możliwości komunikacji między Menedżerem Usług a Menedżerem
Zadań.
Programistyczny interfejs Repozytorium pozwala na pobieranie informacji związanych
z ontologią, mapami obiektowymi i typami usług. Komunikacja z repozytorium odbywa się za
pomocą protokołu HTTP, treść przesyłanych wiadomości zapisywana jest w postaci
dokumentów XML.
Integracja z systemem ROS została zrealizowana poprzez opracowanie interfejsów
i komunikacji, na które składa się (patrz również rysunek niżej):

przesłanie ustalonych parametrów dla funkcji robota.

sterowanie robotem.

przesłanie rezultatu wykonania funkcji robota.
styczeń 2016
5/80
wersja 1.0
Rolą środowiska symulacyjnego jest odwzorowanie mapy z Repozytorium w celu testowania
działania systemu wielorobotowego. Umożliwia dodawanie oraz modyfikację urządzeń
i obiektów. Środowisko zostało zaimplementowane przy użyciu platformy .NET oraz
zintegrowanego środowiska do tworzenia gier trójwymiarowych Unity3D.
Przetestowano 3 scenariusze (uwzględniając również niepowodzenia).

scenariusz 1 – transport słoika z szafki na platformę ,

scenariusz 2 – unieszkodliwienie niebezpiecznego obiektu

scenariusz 3 – transfer zawartości obiektu.
W końcowej fazie realizacji projektu opracowano podstawy ontologii typu outdoor.
Integracja z pozostałymi zadaniami w projekcie zapewniona została poprzez opracowanie
odpowiednich interfejsów programistycznych.
styczeń 2016
6/80
wersja 1.0
1. Ontologia
Klasycznie, ontologia to pojęcia i zachodzące pomiędzy nimi relacje. Są nimi obiekty i ich
atrybuty (czyli cechy), oraz relacje zachodzące pomiędzy obiektami. Każdy obiekt jest
pewnego, z góry zdefiniowanego typu. Typ obiektu jest wyznaczony poprzez atrybuty, które
obiekty tego typu posiadają, oraz poprzez wewnętrzną (hierarchiczną) strukturę takich
obiektów, na którą mogą składać się pod-obiekty oraz relacje zachodzące pomiędzy tymi
pod-obiektami. Typ elementarny nie posiada wewnętrznej struktury, jest wyznaczony
poprzez zbiór atrybutów, zaś typ złożony taką strukturę posiada. Ontologia jest definiowana
jako hierarchiczny zbiór typów obiektów. Pierwotne atrybuty i pierwotne relacje są
podstawowymi elementami, z których konstruowane są typy obiektów. Sam obiekt, jako
instancja swojego typu, jest definiowany poprzez nadanie atrybutom konkretnych wartości i
zachodzenie relacji. Pierwotne atrybuty oraz pierwotne relacje muszą być mierzalne i
rozpoznawalne przez urządzenia sensoryczne znajdujące się w systemie.
1.1. Definiowanie pojęć
Definiowane ontologie będę składać się z następujących pojęć:

Atrybuty – definiują właściwości typu, np., kolor, kształt, pozycja,

Typy – definiują atrybuty, ograniczenia wartości atrybutów specyficzne dla obiektów
danego typu, oraz relację obiektów tego typu z obiektami innych typów,

Ograniczenia – za ich pomocą definiowane są zakresy możliwych wartości atrybutów
dla danego typu obiektu oraz relacji zachodzących między jego atrybutami lub
między nim a innymi typami,

Relacje – umożliwiają zapisywanie zależności między obiektami,

Obiekty – instancje typu z podanymi wartościami atrybutów i zdefiniowanymi
relacjami z innymi obiektami.
Podstawą do konstrukcji ontologii jest ustalony zbiór atrybutów. Pojedynczy atrybut
posiada:

nazwę zrozumiałą dla człowieka,

typ podstawowy, za pomocą którego wyrażana jest wartość atrybutu (np. ciąg
znaków, liczba całkowita, liczba zmiennoprzecinkowa, itp.),

typ jednostki (np. długość, waga, pieniądz, czas),

opis słowny zrozumiały dla człowieka.
W celu dodania nowego obiektu do ontologii niezbędne jest uprzednie zdefiniowanie jego
typu. W ramach definicji typu specyfikujemy:

listę atrybutów,

lista wymaganych pod-obiektów wskazanych typów (w przypadku typów
złożonych),

listę ograniczeń:
o
dopuszczalne wartości atrybutów dla danego typu,
o
wymagane relacje między pod-obiektami danego typu.
styczeń 2016
7/80
wersja 1.0
Definiując obiekt wybieramy jego typ, podajemy konkretne wartości dla wszystkich
wymaganych atrybutów i wskazujemy pod-obiekty. Podane wartości i zależności między
wskazanymi pod-obiektami musza być zgodne z ograniczeniami typu.
Na przykład, zdefiniujmy
następujące atrybuty:
typ noga od stołu (ang. FurnitureLeg). Będzie on posiadał

pozycja X (PositionX),

pozycja Y (PositionY),

pozycja Z (PositionZ),

rotacja X (RotationX),

rotacja Y (RotationY),

rotacja Z (RotationZ),

wysokość (Height),

szerokość (Width),

długość (Length).
Następnie niezbędne jest dodanie ograniczeń, które umożliwią klasyfikację rozpoznawanych
obiektów:

Height < 800 (mm),

Width < 200 (mm) ,

Width < 200 (mm),

this IsFixedTo FurnitureSideBoard .
W ograniczeniach wykorzystana została relacja IsFixedTo oznaczająca przymocowanie
obiektu do obiektu typu FurnitureSideBoard (blatu stołu). Pozwala to na jednoznaczne
odróżnienie nogi od stołu od zwykłego kawałka drewna leżącego swobodnie. Ograniczenia
nałożone na atrybuty Height, Length, i Width pozwalają odróżnić nogę np., od stołu od filaru
podtrzymującego sufit ze względu na skalę obiektu.
1.2. Ontologia dla środowiska testowego
W ontologii dla środowiska testowego utworzony został główny typ Object, z którego
wywodzą się wszystkie pozostałe. W celu rozróżnienia obiektów fizycznych (elementarnych)
od obiektów abstrakcyjnych (złożonych) np.: pokój, utworzone zostały dwa typy wywodzące
się z Object:

PhysicalObject,

AbstractObject.
styczeń 2016
8/80
wersja 1.0
Rysunek 1. Główne typy ontologii
Wszystkie typy dziedziczące bezpośrednio po PhysicalObject zostały przedstawione na
Rysunek 2.
Rysunek 2. Gałąź typów dziedziczących po typie PhysicalObject
styczeń 2016
9/80
wersja 1.0
Rysunek 3. Gałąź typów dziedziczących po typie AbstractObject
Typy wywodzące się od AbstractObject pozwalają na grupowanie obiektów fizycznych w byty
abstrakcyjne takie jak np. stół oraz szafka (Rysunku 4). Jest to możliwe dzięki wykryciu
relacji zachodzących między grupą obiektów, a następnie dopasowaniu ich do
odpowiedniego typu abstrakcyjnego.
styczeń 2016
10/80
wersja 1.0
Rysunek 4. Przykład typu abstrakcyjnego
Wszystkie atrybuty obiektu mogą zostać sprecyzowane za pomocą ograniczeń na poziomie
definicji typu (Rysunek 5). W celu jednoznacznej kategoryzacji rozpoznawanych
obiektów(przypisanie ich do odpowiedniego typu) wymagane jest zdefiniowanie
spodziewanych zakresów wartości dla jak największej liczby atrybutów.
Rysunek 5. Przykład ograniczeń atrybutów prostych
Na rysunku Rysunek 6 przedstawiony został główny typ ontologii kształtów
wykorzystywanych podczas opisu wszystkich obiektów fizycznych. Utworzenie tego typu
pozwala na rozbicie kształtu na cztery główne kategorie, a następnie dalszą ich specjalizację
za pomocą ograniczeń. Bez dodatkowych informacji (np. ograniczeń wartości atrybutów) nie
bylibyśmy w stanie odróżnić obiektu typu Wall od obiektu typu PhysicalObject (Rysunek 7).
Rysunek 6. Fragment hierarchii typów atrybutu Shape
Proces klasyfikacji zachodzi głównie za pośrednictwem atrybutów złożonych Shape oraz
Texture. Jeżeli zaklasyfikowanie obiektu nie jest możliwe na podstawie tych dwóch
atrybutów, należy przejść do sprawdzenia relacji zachodzących między danym obiektem, a
innymi obiektami tworzącymi typy abstrakcyjne.
styczeń 2016
11/80
wersja 1.0
Rysunek 5. Przykład ograniczenia atrybutu złożonego
W celu opisu zależności zachodzących pomiędzy obiektami utworzone zostały relacje
umożliwiające złożone operacje na mapie obiektowej, takie jak np. wyszukiwanie trasy.
Rysunek 6. Typy relacji
Wszystkie relacje posiadają definicję opisującą sposób powiązania dwóch obiektów będących
jej atrybutami. Wyróżniamy trzy typy relacji:

IsAdjacedTo – relacja oznaczająca sąsiedztwo obiektów,

IsIntegralPartOf – dany obiekt jest integralną i nierozłączną częścią innego obiektu,

IsFixedTo – relacja opisująca stałe połączenie dwóch obiektów (np., dwie ściany
połączone krawędziami).
styczeń 2016
12/80
wersja 1.0
1.3. Mapy obiektowe
Po zdefiniowaniu ontologii dla środowiska testowego, można utworzyć jego właściwą już
mapę obiektową wykorzystywaną podczas eksperymentów, poniżej przedstawiony został jej
fragment składający się z mapy pokoi dla 1 piętra.
Rysunek 7 Mapa obiektowa środowiska testowego
styczeń 2016
13/80
wersja 1.0
2. Algorytm uczenia się
Aktualizacja polega na zweryfikowaniu wartości atrybutów obiektów istniejących w mapie
obiektowej (instancja ontologii) dla danej lokalizacji. Natomiast uszczegóławianie mapy
polega na dodaniu do niej definicji nowych obiektów. Akcje te mogą być realizowane jako
dedykowane typy usług świadczone przez urządzenia kognitywne (wyposażone w sensory).
Usługi takich typów mogą być wywoływane również jako komponenty złożonych zadań, np.
w celu ewaluacji sytuacji w środowisku po wykonaniu zadania przez robota mobilnego.
Kluczowym elementem dla efektywnych algorytmów aktualizacji i uszczegóławiania mapy
jest rozpoznanie kontekstu, w ramach którego będą wykonywane. Kontekstem jest aktualna
lokalizacja robota, a dokładniej element mapy reprezentujący fizyczną lokalizację,
pomieszczenie, w którym dany robot się znajduje. Ustalony kontekst pozwala na
wyznaczenie, podczas rozpoznawania obiektów, zbioru najbardziej prawdopodobnych
typów obiektów i ich instancji.
Dla algorytmu wyznaczania kontekstu przyjęto następujące założenia:

Robot znajduje się w określonym budynku. Jego dokładna lokalizacja nie jest znana
(nie jest znane piętro i pomieszczenie, w którym się znajduje).

Znana jest ontologia zawierająca pojęcia opisujące strukturę budynku (typy, typy ich
pod-obiektów i relacji między nimi).

Znana jest (częściowa) mapa obiektowa danego budynku. Mapa obiektowa obejmuje
obiekty:

o
statyczne (będące częścią struktury budynku),
o
dynamiczne, których
w pomieszczeniach).
lokalizacja
może
się
zmienić
(np.
meble
Robot jest w stanie rozpoznać ustalony zbiór cech przedmiotów (atrybutów
obiektów), na podstawie których te obiekty będą rozpoznawane. Jest to powiązane z
Zadaniem 3.
Na sam algorytm wyznaczania kontekstu składają się następujące kroki:
1. Inicjalizacja
a) Wyznaczany jest zbiór ML (możliwe lokalizacje) na podstawie mapy
obiektowej budynku. Do tego zbioru należą obiekty typów dziedziczących po
typie ClosedSpace (reprezentującego zamknięte pomieszczenia: pokoje,
korytarze, hole, itp.).
b) Każdemu z obiektów zbioru ML przypisywane jest prawdopodobieństwo
tego, że robot znajduje się właśnie w tej lokalizacji.
2. Ewaluacja
a) Jeżeli w zbiorze ML istnieją
obiekty z prawdopodobieństwem
przekraczającym ustalony próg, algorytm jest finalizowany, a jego rezultatem
jest zbiór obiektów spełniających to kryterium.
b) Jeżeli zbiór ML jest pusty, (co oznacza, że wszystkie możliwe lokalizacje
zostały wyeliminowane na podstawie przeprowadzonych obserwacji),
ustalenie lokalizacji robota jest niemożliwe dla posiadanej mapy obiektowej i
przeprowadzonych obserwacji.
c) Jeżeli powyższe warunki nie zostały spełnione, algorytm jest kontynuowany.
3. Obserwacja – przeprowadzenie obserwacji przez robota, którego rezultatem jest
zbiór rozpoznanych cech obiektu. Jest to związane z Zadaniem 3.
4. Klasyfikacja – rozpoznanie obiektu na podstawie zaobserwowanych cech.
5. Eliminacja – usunięcie ze zbioru ML lokalizacji nie posiadających rozpoznanych
obiektów.
6. Modyfikacja – modyfikacja prawdopodobieństw w zbiorze ML
7. Powrót do kroku 2.
styczeń 2016
14/80
wersja 1.0
Optymalizacja kroku obserwacji polega na odpowiednim wyznaczeniu obiektu do
wyszukania. Możliwe jest wykorzystanie wielu strategii i dobieranie ich w zależności od
aktualnego stanu zbioru potencjalnych lokalizacji. Strategie te mogą obejmować
wyznaczenie:
 niezaobserwowanego obiektu wskazanego typu,
 niezaobserwowanego obiektu najrzadziej występującego typu w mapie
obiektowej możliwych lokalizacji (pozwala na szybkie wyeliminowanie dużej
liczby potencjalnych lokalizacji),
 niezaobserwowanego obiektu z mapy obiektowej najbardziej prawdopodobnej
lokalizacji (pozwala na potwierdzenie najbardziej prawdopodobnego
rozwiązania).
Komunikacja z modułem percepcji (realizującym obserwację w ramach Zadani 3) odbywa się
poprzez przekazywanie obiektu klasy PhysicalObject, posiadającego takie atrybuty jak:
współrzędne, orientacja, waga, tekstura i kształt.
Proces klasyfikacji przebiega w następujący sposób:
1. pozyskanie zbioru opisujących go cech za pośrednictwem sensorów;
2. wyznaczenie zbioru typów obiektów posiadających atrybuty odpowiadające
pozyskanym cechom obiektu;
3. wyznaczanie podzbioru tych typów na podstawie ograniczeń wartości
atrybutów;
4. wyszukanie w mapie obiektów wyznaczonych typów;
5. wyszukanie obiektów z atrybutami, których wartości odpowiadają pozyskanym
cechom (biorąc pod uwagę przedział możliwego błędu pomiaru).
Znajomość kontekstu znacznie przyśpiesza proces rozpoznawania poprzez ograniczenie
zbioru możliwych typów i obiektów.
W podstawowej wersji algorytmu, wyznaczanie lokalizacji opiera się wyłącznie na
obowiązkowych pod-obiektach (elementach strukturalnych).
W celu wykorzystania
informacji o opcjonalnych obiektach (np. krzesła, biurka, lodówka znajdujące się w danym
pokoju) należy przygotować wcześniej rozkład prawdopodobieństwa ich występowania
w każdej z lokalizacji. Rozkład ten jest również wykorzystywany w klasyfikowaniu
rozpoznawanych obiektów.
W przypadku wykorzystania rozkładów prawdopodobieństw występowania obiektu
danego typu w danej lokalizacji podczas rozpoznawania kontekstu, konieczne jest
wprowadzenie zmian do kroku Modyfikacja. Nowe wartości prawdopodobieństw są zależne
od ilości możliwych lokalizacji, jak również prawdopodobieństwa wystąpienia danego
obiektu w każdym z nich.
Algorytm uczenia jest realizowany jako biblioteka kodu. Korzysta z niego przede
wszystkim Menadżer Usług, wywołując odpowiednie metody, np. do ustalania lokalizacji lub
rozpoznania obiektu. Funkcjonalność ta może zostać udostępniona jako jedna z funkcji
robota, i tym samym może być składową planu wykonania usług.
Jednym z kluczowych aspektów podczas implementacji tych mechanizmów jest sposób
realizacji obserwacji w ramach Zadania 3. Integracja tych mechanizmów z obserwacjami
(tj. z percepcją robota realizowaną w ramach Zadania 3) została zrealizowana poprzez
opracowanie interfejsów w postaci bibliotek programistycznych. Na potrzeby testowania
dane z kolejnych obserwacji były otrzymywane ze środowiska symulacyjnego w kroku nr 3
algorytmu. Wartości te nie muszą odpowiadać idealnie wartościom zdefiniowanym w mapie
obiektowej. W kroku nr 4 i 5 (Klasyfikacja i Eliminacja), podczas porównywania wartości
atrybutów obiektów w mapie z wartościami z obserwacji dla rozpoznanych typów
uwzględnia się przedziały bezpieczeństwa wynikające z możliwych błędów pomiarowych.
styczeń 2016
15/80
wersja 1.0
Częścią korku nr 3 (Obserwacja), lub kroku bezpośrednio go poprzedzającego, może być
algorytm wyznaczania konkretnych cech do wyszukania w otoczeniu robota. W odróżnieniu
od systematycznego sprawdzania całego otoczenia, można wyznaczyć obiekty
charakterystyczne dla pewnych zbiorów lokalizacji lub dla jednej lokalizacji. Może to również
dotyczyć, nie tylko samych obiektów (które mogą występować w kilku lokalizacjach), ale
wartości ich atrybutów, wyróżniające ich w skali całego budynku. Może to dla większości
przypadków znacznie przyśpieszyć algorytm jednoznacznego wyznaczania lokalizacji robota.
W przypadku, gdy algorytm zakończy się zwróceniem kilku możliwych lokalizacji, dalszym
postępowaniem jest:
1. Przyjęcie hipotezy o tym, że znajdujemy się w lokalizacji o największym
prawdopodobieństwie
(lub
pierwszej
z
nich,
jeżeli
mają
równe
prawdopodobieństwa). Lokalizacja ta staje się kontekstem dalszych działań robota.
2. Postępowanie zgodnie z tą hipotezą przy przemieszczaniu się, lub realizowaniu usług.
3. Jeżeli w trakcie ich realizacji dojdziemy do sprzeczności (np. statyczny obiekt
znajduje się w miejscu, w którym nie powinien być w ramach aktualnego kontekstu)
przyjmujemy kolejną hipotezę dla następnego w kolejce obiektu.
Opisany wyżej algorytm został zintegrowany z infrastrukturą programową do
zarządzania systemem wielorobotowym (opartym na paradygmacie SOA) na poziomie
pojedynczego robota mobilnego.
styczeń 2016
16/80
wersja 1.0
3. System Autero
Roboty mobile (i inteligentne urządzenia) mogą ze sobą współpracować w ramach
otwartych, dynamicznych i heterogenicznych środowisk. Aby umożliwić współpracę i
semantyczną zgodność komunikacji w takim środowisku potrzebna jest wspólna
reprezentacja dziedziny, której dotyczy ta komunikacja. Z tego względu reprezentacja
środowiska została zrealizowana w postaci ontologii, która jest wykorzystywana do
definiowania interfejsów usług, a także do formułowania zadań.
Definicja typu usługi składa się z następujących elementów:

typu usługi, czyli rodzaju akcji, którą wykonuje usługa,

wejść i wyjść usługi,

warunków wymaganych do wykonania usługi i efektów wykonania,

atrybutów usługi.
Nie wszystkie elementy są wymagane. Niektóre typy usług mogą w swojej definicji posiadać
tylko typy obiektów wejściowych i wyjściowych, inne zaś definicję wymaganego opisu
sytuacji wejściowej i efektów wykonania usługi. Mogą także wystąpić kombinacje tych
przypadków.
Atrybuty usługi zawierają informacje o niezmiennych cechach danej usługi. Atrybutami mogą
być: zasięg działania (np. dla usługi transportowej), technologia lub parametry wykonania
(dla usługi wytwarzającej zamówione przedmioty), maksymalny czas realizacji usługi itp.
Dzięki temu zbiór usług może zostać przefiltrowany przy pomocy wybranych atrybutów.
Rysunek 8. Schemat typu usługi
W przypadku obszernego zbioru typów usług można wprowadzić ich hierarchię np. poprzez
odpowiednią strukturę kategorii wykonywanych czynności. Taki podział może zostać
wykorzystany do ułatwienia i przyśpieszenia wyszukiwania właściwego typu usługi,
zarówno dla operacji automatycznych, jak i w przypadku ręcznego wyszukiwania
właściwego typu usługi przez klienta.
styczeń 2016
17/80
wersja 1.0
Semantyczny opis usług pozwala także na automatyczną kompozycję usług w złożone
procesy poprzez dopasowywanie typów usług, które mogą być użyte w danym miejscu
sekwencji procesu, aby była możliwa realizacja zadania. Możliwość automatycznej
kompozycji jest ważna w otwartych i dynamicznych środowiskach, gdzie nie możemy
przewidzieć w czasie projektowania, jakie typy usług będą dostępne w środowisku. Nie
zawsze jednak możliwe jest automatyczne skomponowanie planu. W takim przypadku
konieczne jest skorzystanie ze zbioru manualnie przygotowanych planów.
Za wybór odpowiednich usług do realizacji zadania odpowiada procedura zwana aranżacją.
Pozwala ona na wcześniejsze ustalenie parametrów wykonania usługi i jej rezerwację. Dzięki
temu można sprawdzić wykonywalność zadania przed jego faktycznym wykonaniem.
Możliwe jest także zapewnienie odpowiednich parametrów jakościowych wykonania usługi,
ponieważ wynikiem aranżacji jest pewna forma umowy pomiędzy klientem a usługodawcą.
3.1. Architektura systemu
Poniższy rysunek przedstawia architekturę systemy RobREx. Jest ona zgodna z
paradygmatem SOA.
Rysunek
10.
Rysunek 9. Architektura systemu Autero
Repozytorium jest komponentem przechowującym i udostępniającym ontologię dla
pozostałych komponentów systemu. Udostępnia interfejs graficzny umożliwiający w prosty
sposób tworzyć i modyfikować ontologię.
Menedżer Zadań – reprezentuje klienta. Udostępnia dla niego interfejs graficzny
pozwalający na zdefiniowanie zadania i monitorowanie jego przebiegu. Menedżer zadań
udostępnia wszystkie potrzebne do tego celu mechanizmy. Wykorzystuje moduł planowania
przy budowaniu procesów i moduł aranżacji do ich aranżowania. Komunikuje się także z
usługami, wykorzystując do tego odpowiedni protokół.
Moduł planujący (Planer) – jest modułem wewnętrznym Menedżera Zadań, który
odpowiada za kompozycję procesu biznesowego. Planer generuje zbiór planów
abstrakcyjnych na podstawie żądania z Menedżera Zadań. Plany te Menedżer Zadań
przekształca na procesy biznesowe. Obecna implementacja Planera wykorzystuje zbiór z
góry zdefiniowanych planów.
styczeń 2016
18/80
wersja 1.0
Moduł Aranżacyjny – podobnie jak Planer, Moduł Aranżacyjny jest częścią Menedżera
Zadań. Odpowiada za przeprowadzenie procesu aranżacji. Może implementować różne
mechanizmy wyszukiwania najlepszych usług. Możliwe jest także automatyczne wybieranie
najlepszej oferty. Umożliwia przeprowadzenie aranżacji zadania, przesyłając intencje i
zbierając zobowiązania od Menedżerów Usług udostępniających usługi określonego typu.
Rejestr usług – pozwala na odnalezienie aktualnie dostępnych usług. Każda dostępna usługa
musi być wcześniej zarejestrowana przez Menedżera Usług. Rejestr usług może być prostym
komponentem zawierającym tylko listę zarejestrowanych usług i zwracającym podzbiór
usług o typie zgodnym z żądaniem. Może być jednak rozszerzony o dodatkową logikę
wspierającą menedżera zadań i planera. Rejestr usług może filtrować zarejestrowane usługi,
uwzględniając ich atrybuty, a także pełnić funkcje prostej maszyny wnioskującej, filtrując
usługi na podstawie intencji. Jeżeli nie są dostępne usługi wymaganego typu, rejestr usług
może zaproponować usługę złożoną, przesyłając plan takiej usługi złożonej. W taki sposób
rejestr uzupełnia funkcję planera. Dzięki temu, że dysponuje wiedzą o aktualnie dostępnych
usługach, może znaleźć wykonywalny plan efektywniej. Taki sposób działania nazywamy
planowaniem rozproszonym.
Menedżer Usług – udostępnia funkcjonalność robota (lub robotów) w postaci usług. Steruje
wykonaniem zadań przez roboty w ramach świadczonej usługi i odpowiada za obsługę
protokołu transakcji po jej stronie.
3.2. Menedżer Zadań
Interfejs Menedżera Zadań udostępniany jest w postaci stron WWW. Wspólnym elementem
dla każdej z nich jest menu główne widoczne na poniższym rysunku.
Rysunek 10. Menu główne Menedżera Zadań
Menu główne zawiera cztery elementy:
1.
Home – pozwala na przejście do strony głównej.
2.
Create Task – wyświetla formularz pozwalający na zdefiniowanie i zlecenie nowego
zadania.
3.
Task – lista zadań danego użytkownika.
4.
Messages – lista wiadomości z informacjami o przebiegu zadań.
Definiowanie zadania
W obecnej wersji Menedżera Zadań definiowanie zadań odbywa się tekstowo w postaci
odpowiedniej formuły, zawierającej warunki początkowe i końcowe zadania.
styczeń 2016
Rysunek 11. Formularz definiowania nowego zadania
19/80
wersja 1.0
Powyższy rysunek przedstawia formularz pozwalający na zdefiniowanie i zlecenie nowego
zadania, składający się z następujących elementów:

nazwa zadania,

czas do którego zadanie musi zostać ukończone,

definicja zadania.
Zadania użytkownika przedstawione są w postaci tabeli (zob. rysunek poniżej).
Rysunek 12. Widok listy zdefiniowanych zadań
Widok zadań zawiera takie informacje jak:

nazwa zadania,

data utworzenia zadania,

termin przewidziany na realizację zadania,

data zakończenia zadania (prawidłowego lub nieprawidłowego),

status zadania.
Rysunek 13. Szczegółowy widok zadania
Powyższy rysunek przedstawia szczegółowy widok realizowanego zadania. Poza
informacjami widocznymi także na liście zadań, widok ten zawiera dodatkowo listę kroków
procesu. Elementami widocznymi na tej liście są:

unikalny identyfikator usługi,

nazwa typu usługi,
styczeń 2016
20/80
wersja 1.0

stan usługi,

liczba odebranych zobowiązań w fazie aranżacji,

stan fazy aranżacji,

czas rozpoczęcia fazy wykonania usługi,

czas zakończenia usługi
Informacje związane z realizacją zadań użytkownika są przekazywane w postaci wiadomości.
Dzięki temu użytkownik widzi najważniejsze zmiany w procesie realizacji zadania bez
potrzeby analizowania każdego zadania z osobna.
Rysunek 14. Widok listy komunikatów
Wiadomości prezentowane są użytkownikowi w postaci tabeli zawierającej następujące
elementy:

data utworzenia wiadomości,

typ wiadomości – informacja, ostrzeżenie, błąd, błąd fatalny,

treść wiadomości,

identyfikator procesu, którego wiadomość dotyczy,

znacznik przeczytania wiadomości.
Proces realizujący zadanie może być także przedstawiony w postaci diagramu. Węzły
diagramu reprezentują poszczególne usługi w procesie, a krawędzie przedstawiają relacje
między nimi.
styczeń 2016
21/80
wersja 1.0
Rysunek 15. Graficzna reprezentacja procesu
Przykład diagramu procesu widoczny jest na rysunku powyżej. Główną zaletą diagramu jest
możliwość łatwego zorientowania się w relacjach zachodzących pomiędzy węzłami procesu.
3.3. Menedżer Usług
Celem Menedżera Usług jest zapewnienie narzędzi umożliwiających wykonanie zachowań robota
(więcej na temat zachowań w rozdziale 3.3 ) w celu osiągnięcia stanu środowiska opisanego
przez zadanie. Na podstawie opisu zadania (opis sytuacji początkowej i końcowej), oraz danych
pobranych z repozytorium, Menedżer Usług sekwencyjnie zleca zachowania dla jednostek
fizycznych, w celu osiągnięcia pożądanego końcowego stanu środowiska opisanego w zadaniu.
Aplikacja wykonana została na platformie .NET z wykorzystaniem frameworka ASP.NET MVC 5.
Do persystencji oraz modelowania struktur danych wykorzystany został Entity framework oraz
baza danych SQL CE. Interfejs graficzny dostępny jest z poziomu przeglądarki internetowej.
3.3.1. Funkcjonalność MU
Menedżer Usług pełni rolę pośrednika pomiędzy robotem a Menedżerem Zadań. W tym celu
niezbędne jest zdefiniowanie na nim interfejsów zachowań robota, do komunikacji z robotem oraz
planów usług do komunikacji z Menedżerem Zadań. Menedżer Usług powinien znajdować się
bezpośrednio na urządzeniu, lub w połączeniu umożliwiającym komunikację TCP/IP. Dla każdego
z urządzeni fizycznych, niezbędna jest nowa instancja Menedżera Usług.
styczeń 2016
22/80
wersja 1.0
Rysunek 16. Architektura Menedżera Usług
Na funkcjonalność Menedżera Usług składa się:

Interfejs graficzny służący do definicji zachowania robota,

Interfejs graficzny służący do definicji planu dla konkretnego typu usługi,

Interfejs wykonania zadania zleconego przez Menedżer Zadań,

Moduł odpowiedzialny za tłumaczenie planu usługi na zachowania robota.
3.3.2. Definiowanie zachowań robota
W celu wywołania zachowania robota niezbędne jest zdefiniowanie sposobu komunikacji. W
zależności od sposobu komunikacji między MU a robotem, parametry niezbędne do ustanowienia
połączenia mogą być różne. Dodatkowo niezbędne jest również ustalenie parametrów
wejściowych oraz wyjściowych zachowania. W celu ułatwienia dalszej implementacji stworzona
została klasa abstrakcyjna posiadająca niezbędne metody oraz pola w celu integracji jej z planem
usługi (więcej na temat planu w następnym rozdziale). W celu utworzenia nowego sposobu
komunikacji wystarczy zaimplementowanie nowej klasy rozszerzającej RegisteredRobotFuncion
oraz nadpisanie metody Execute która odpowiedzialna jest za wysłanie a następnie odebranie
komunikatu od robota.
styczeń 2016
23/80
wersja 1.0
Rysunek 17 Przykładowa definicja zachowania robota
W celu zdefiniowania zachowania na aktualne potrzeby (ze względu na środowisko symulacyjne)
niezbędne były parametry:

Name – nazwa usługi umożliwiająca wykorzystanie jej podczas definiowania planu,

Function Adress – adres sieciowy serwera symulacji,

Robot Name – nazwa robota który ma wykonać daną usługę (ze względu na
implementacje symulacji),

Port – informacja na którym porcie ma zostać nawiązane połączenie,

Inputs – dane wejściowe w których zdefiniowana jest nazwa oraz typ parametru,

Outputs – dane wyjściowe w których zdefiniowana jest nazwa oraz typ parametru.
Możliwe typu parametrów dla Inputs i Outputs to:

String,

Integer,

Long,

Double,

ObjectInstance – obiekt repozytorium.
styczeń 2016
24/80
wersja 1.0
Format Wiadomości Xml do robota od Menedżera Usług:
Rysunek 18 Format wiadomości wysyłanej do robota
Format wiadomości wysyłanych do robota może zostać zmodyfikowany w zależności od potrzeb.
Proces wysyłania wiadomości oraz jej format następuje w klasie rozszerzającej
RegisteredRobotFunction. Aktualnie wykorzystywana implementacja komunikacji za pomocą
socketów
znajduje
się
w
klasie
SocketRobotFunction
(Models>
RobotRegisteredFunctions>SocketRobotFunction.cs).
Format Wiadomości Xml od robota do Menedżera Usług:
Rysunek 19 Przykładowa wiadomość od robota do Menedżera Usług
z parametrami
Odpowiedź oraz wszystkie parametry konwertowane
„ExecutionResults” w którym przechowywana jest:
są
do
postaci
obiektu
typu

Message – wiadomość podstawowa, w przypadku powodzenia jest to „done”

AdditionalMessage – wiadomość dodatkowa o ewentualnych błędach

ResultType – enum świadczący o powodzeniu lub niepowodzeniu wykonania zachowania

Results – mapa przechowująca wszystkie obiekty zwrócone przez zachowanie robota, w
większości przypadków będzie ona pusta, lecz w przypadku zachowań kognitywnych np.
FindAndReturn będzie znajdował się tam obiekt (lub wiele obiektów) typu
ObjectInstance (format tego typu można zobaczyć w dokumentacji repozytorium)
styczeń 2016
25/80
wersja 1.0
Rysunek 20 Przykładowe zachowania robota
3.3.3. Tworzenie usług i planów ich wykonania
W celu wykonania serii zachowań robota (przykładowe zachowania na Rysunek 4) w
odpowiedniej kolejności niezbędny jest plan ich wykonania. Umożliwia to również
uwarunkowywanie ich w zależności od zmian zaistniałych w środowisku. Plan zawarty będzie w
usługach oferowanych przez Menedżer Usług. W poniższym rozdziale przedstawiony zostanie
przykład tworzenia nowej usługi.
Definicja interfejsu usługi
By stworzyć usługę realizowaną przez MU niezbędne jest uprzednie zdefiniowanie jej typu. Jest
to możliwe dzięki dwóm komponentom systemu, Repozytorium oraz Rejestrowi Usług. Najpierw
definiowany jest typ usługi na Repozytorium.
Rysunek 21 Definicja typu usługi
Operator „?” oznacza zmienną, natomiast jego brak, odwołanie do Repozytorium po nazwie
obiektu. Wewnątrz znaczników „<>” oznaczony jest typ. Ponieważ dodatkowe informacje na temat
obiektu typu „Granules” nie są potrzebne do wykonania zadania, nie jest on pobierany z
Repozytorium. Obiekty typu „Jar” i „Bowl” brak znacznika „?” oznacza że ich nazwy będą
styczeń 2016
26/80
wersja 1.0
niezbędne Menedżerowi Usług i dane na ich temat muszą zostać pobrane z repozytorium w celu
wykonania usługi.
Następnie po zdefiniowaniu typu, możliwe jest utworzenie usługi za pomocą Menedżera Usług,
poprzez wybranie odpowiedniego typu usługi oraz zdefiniowanie planu jej wykonania(więcej na
ten temat w podrozdziale 4.2).Usługa po utworzeniu w MU jest automatyczne rejestrowana w
Rejestrze Usług.
Rysunek 22 Usługi zarejestrowane w Rejestrze Usług
Definicja planu usługi
Podczas tworzenia usługi niezbędne jest wybranie jej typu(z tych zdefiniowanych na
Repozytorium). Po wybraniu automatycznie wypełnione zostają precondition, oraz
postconditions.
Rysunek 23 Kreator usługi
Następnie możliwe jest zdefiniowanie planu wykonania usługi w celu zrealizowania warunków
końcowych. Przykład pustego planu przedstawiony został na Rysunek 8.
styczeń 2016
27/80
wersja 1.0
Rysunek 24 Podstawowa definicja planu o nazwie „Find”
Dzięki automatycznie wypełnionym polom Precondition oraz Postcondition, możliwe jest
wykorzystanie w planie obiektów przekazanych jako parametry wykonania usługi.
Elementy planu
Podczas tworzenia planu możliwe jest wykorzystanie pięciu typów elementów:

robotFunction – umożliwia wywołanie zachowania robota,

if – umożliwia ewaluacje wyrażenia oraz przejście do odpowiedniego kroku w planie,

exception – umożliwia zwrócenie wyjątku do menedżera zadań oraz opisanie stanu
końcowego środowiska.


task – zdalne wywoływanie zadań za pośrednictwem menedżera zadań
route – wyznaczenie ścieżki między obiektami mapy
Każdy z powyżej elementów obsługuje atrybuty takie jak:

stepId – unikalny identyfikator niezbędny do zachowania odpowiedniej kolejności
wykonania kroków, atrybut jest obowiązkowy

nextStepId – atrybut wskazujący na kolejny krok który zostanie wykonany, jeżeli
następny krok nie zostanie wskazany, nastąpi zakończenie planu

delay – opcjolany atrybut wskazujący czas w milisekundach do odczekania przed
rozpoczęciem kroku
Wykorzystanie zachowań robota
W celu wykorzystania zachowań robota które zostały opisane w rozdziale 2 dostępny jest element
planu o nazwie „robotFunction”.
Rysunek 25 Przykładowa implementacja elementu robotFunction
Element „robotFunction” wymaga definicji atrybutu „stepId” oraz „functionName”, wszystkie inne
elementy oraz atrybuty są nieobowiązkowe. Poniżej zostaną opisane wszystkie atrybuty oraz
elementy:

Atrybuty elementu „robotFunction”:
o
stepId – unikalny identyfikator elementu planu,
o
nexStepId – id kolejnego kroku (parametr opcjonalny)
o
functionName – nazwa zachowania robota które zostanie wywołane (w
przypadku braku takiego zachowania wystąpi błąd),
styczeń 2016
28/80
o
wersja 1.0
delay –atrybut opóźniający rozpoczęcie wykonania elementu.

Element „input” określa parametry weściowe

Element „param” pozwala na przekazywanie wartości, możliwe atrybuty to:
o
name – nazwa odpowiadająca parametrowi w definicji zachowania robota
o
value – wyrażenie które zostanie ewaluowane oraz wysłane do robota jako
wartość parametruni
o
results – nazwa zmiennej do której przypisana zostanie wartość parametru (w
przypadku jej braku, zostanie utworzona)
Uzależnienie planu od zmiennych środowiskowych
Instrukcje warunkowe umożliwiają stworzenie bardziej złożonych planów. W tym celu utworzony
został element „if”.
Rysunek 26 Przykładowa implementacja elementu "if"
Atrybuty elementu:


nextStepId – id kolejnego kroku(parametr opcjonalny),

ifTrue – id kolejnego kroku w przypadku uzyskania prawdy podczas ewaluacji,

ifFalse – id kolejnego kroku w przypadku uzyskania fałszu podczas ewaluacji,

expression – wyrażenie ewaluowane, wartości atrybutów dynamicznie podmieniane a
następnie ewaluowane,

maxRetryCount – maksymalna ilość powtórzeń, w przypadku osiągnięcia ich
maksymalnej ilości automatycznie zwracany jest błąd wykonania planu, pozwala to na
uniknięcie nieskończonych pętli.
Sytuacje wyjątkowe
Możliwe jest również nie spełnienie założonej sytuacji końcowej podanej w „postconditions”. W
tym celu dodano element „exception” umożliwiający Planiście zwrócenie do Menedżera Zadań
innej niż oczekiwana sytuacji końcowej.
Rysunek 27 Przykładowa implementacja elementu "exception"
Atrybuty elementu:


postconditions – wyrażenie zawarte w postconditions, wyrażenie „?objectSet1.Name”
zostanie dynamicznie zastąpione wartością atrybutu.
styczeń 2016
29/80
wersja 1.0
Przedstawiony element ten jest częścią planu „TransferContent”. Zakłada on transfer (płynnej lub
sypkiej) zawartości jednego pojemnika do drugiego. W przypadku stwierdzenia za pomocą
czujników braku transferu całej zawartości, zwrócona zostaje specjalna sytuacja końcowa.
Zlecanie innych zadań (task)
W sytuacji gdy do wykonania usługi niezbędna jest wykonanie innej usługi(przez innego robota)
możliwe jest zlecenie zadania za pośrednictwem Menedżera Zadań. Np. robot podczas
przemieszczania obiektu między piętrami wymaga usługi transportowej świadczonej przez windę.
Generowanie ścieżki (route)
By robot mógł poruszać się po środowisku niezbędne jest wyznaczenie jego wstępnej trasy.
Wykorzystywana jest do tego element planu typu „route”. Podczas wykonywania elementu
wyszukiwana jest możliwa ścieżka pomiędzy obiektami oraz zwracana jest lista obiektów przez
które robot musi przejść by dotrzeć do celu. W przypadku gdy takim obiektem są drzwi,
automatycznie zostanie wygenerowany nowy pan (tylko na potrzeby elementu route) w którym
znajdą się niezbędne elementy typu „robotFunction” dzięki którym robot będzie się przemieszczał
oraz typu „task”.
Rysunek 28 Przykładowa implementacja elementu „route”
Atrybuty elementu:


nextStepId – identyfikator następnego kroku
Dane wejściowe elementu:

Start – nazwa obiektu od którego wyznaczana jest ścieżka,

Finish – nazwa obiektu do którego wyznaczana jest ścieżka.
styczeń 2016
30/80
wersja 1.0
3.3.4. Przebieg tworzenia usługi
Zlecanie i wykonanie zadań
W celu wykonania zadania niezbędne jest przekazanie opisu sytuacji dla konkretnych obiektów.
W tym celu powstał komponent Menedżera Zadań który zleca wykonanie konkretnego typu usługi
dla konkretnych obiektów opisujących sytuacje zdefiniowaną w typie usługi.
Po zdefiniowaniu planu dla konkretnego typu usługi jest ona rejestrowana w Rejestrze Usług.
Menedżer Zadań ma możliwość przeszukania Rejestru Usług w celu znalezienia odpowiedniego
typu usługi. Następnie po wypełnieniu sytuacji początkowej i końcowej odpowiednimi obiektami
lub zmiennymi, zlecane jest rozpoczęcie zadania.
Rysunek 29. Tworzenie zadania
Operator „?” oznacza zmienną, natomiast „#” odwołanie do Repozytorium po nazwie obiektu.
Wewnątrz znaczników „<>” oznaczony jest typ. Ponieważ dodatkowe informacje na temat obiektu
typu „Granules” nie są potrzebne do wykonania zadania, nie jest on pobierany z Repozytorium.
Obiekty typu „Jar” i „Bowl” poprzedzone są znakiem „#” w celu przekazania Menedżerowi Usług że
dane na ich temat będą niezbędne do wykonania planu, czyli muszą zostać pobrane z
repozytorium.
Gdy obiekty zostaną pobrane z repozytorium, umieszczane są one w lokalnym słowniku pod
kluczem którego nazwa odpowiada argumentowi w definicji usługi. Na Rysunek 29 obiekt o
nazwie „Jar001” zostanie zapisany do lokalnego słownika pod kluczem „object1” na podstawie
definicji usług widocznej na Błąd! Nie można odnaleźć źródła odwołania.. Po przetworzeniu
arametrów zadania Menedżer usług przystępuje do jego wykonania. Całe zadanie opisane jest za
pomocą planu który wykonywany jest w krokach. W każdym kroku możliwe jest wystąpienie
błędu na poziomie robota, zostaje on raportowany do Menedżera Usług, który z kolei przekazuje
błąd do Menedżera Zadań jeżeli nie jest w stanie sam go obsłużyć. Kod błędu może zostać
przekazany za pomocą atrybutu „resultVarName” który definiowany jest na poziomie planu dla
każdego zachowania.
Sposób integracji Z urządzeniami fizycznymi
W ramach planu wykorzystywana jest klasa „RobotFunction” która posiada wszystkie niezbędne
parametry oraz metody do translacji zachowania robota zdefiniowanego w planie na formę
gotową do wysłania na urządzenie fizyczne. Zaimplementowana została również klasa
„SocketRobotFunction” dziedzicząca po „RobotFunction”. Pozwala to na zdefiniowanie
dodatkowych pól w formularzu niezbędnych do ustanowienia połączenia pomiędzy robotem a
Menedżerem Usług oraz nadpisana została metoda wysłania wiadomości. Zaimplementowana
klasa umożliwia komunikację sieciową przez protokół TCP/IP. Pozwala to na proste dodanie
nowych form komunikacji pomiędzy Menedżerem Usług a innymi urządzeniami fizycznymi.
By zintegrować nowe urządzenie z systemem niezbędne jest zainstalowanie Menedżera Usług na
platformie która umożliwia komunikację TCP/IP z tym urządzeniem. Następnie możliwe jest
styczeń 2016
31/80
wersja 1.0
zdefiniowanie zachowań robota za pomocą interfejsu zapewnionego przez Menedżer Usług oraz
wykorzystanie zdefiniowanych zachowań w planie. Wymagane jest by urządzenie nasłuchiwało
na porcie podanym przez użytkownika dzięki czemu Menedżer Usług jest w stanie nawiązać
połączenie oraz wysłać parametry zachowania. W trakcie wykonywania Menedżer Usług będzie
oczekiwał na odpowiedź (domyślnie komunikat o poprawnym wykonaniu zachowania to „done”).
Po uzyskaniu odpowiedzi wykonany zostanie kolejny krok planu. W przypadku otrzymania
wiadomości o wystąpieniu błędu, wykonywanie zadania zostanie przerwane oraz poinformowany
zostanie Menedżer Zadań.
W celu zintegrowania Menedżera Usług z urządzeniem fizycznym niezbędne jest:

Implementacja mechanizmu nasłuchiwania po stronie urządzenia,

Zdefiniowanie zadań po stronie Menedżera Usług,

Definicja planu usługi w którym wykorzystane zostaną uprzednio zdefiniowane zadania,

Zapewnienie możliwości komunikacji między Menedżerem Usług a Menedżerem Zadań.
styczeń 2016
32/80
wersja 1.0
4. Protokół obsługi transakcji
Komunikacja pomiędzy Menedżerem Zadań a Menedżerami Usług odbywa się za pomocą
protokołu transakcji, który definiuje stany usługi i wiadomości wykorzystywane do ich
zmiany. Protokół taki umożliwia adaptację procesu do aktualnego stanu środowiska, aby
umożliwić prawidłową realizację transakcji biznesowej. Protokół będzie nazywany ABTP
(ang. Adaptive Business Transaction Protocol - adaptacyjny protokół dla transakcji
biznesowych).
Rysunek 30. Diagram stanów usługi i wiadomości protokołu ABTP
Wszystkie fazy realizacji usługi biznesowej są reprezentowane za pomocą zbioru stanów
usługi:

Inactive – stan występujący tylko po stronie menedżera zadań. Oznacza, że dany
węzeł reprezentujący usługę należy do procesu, ale faza aranżacji jeszcze się nie
rozpoczęła.

Arranging – faza aranżacji węzła procesu biznesowego reprezentującego usługę. W
tym stanie nie ma jeszcze konkretnej usługi przypisanej do węzła.

Rearranging – stan występujący po wysłaniu przez menedżera zadań polecenia
przearanżowania warunków wykonania usługi. W tym stanie usługodawca generuje
nowe zobowiązanie dla zmienionej intencji klienta.

Arranged – stan po zaakceptowaniu zobowiązania usługi w fazie aranżacji. Od tego
momentu konkretna usługa jest powiązana z odpowiednim węzłem procesu
biznesowego (nie jest już tylko abstrakcyjnym typem).

Executing – usługa wykonuje swoje zadanie.

Completed – usługa wykonała swoje zadanie prawidłowo.

Ended – w takim stanie wiadomo, że dany proces biznesowy, którego usługa była
częścią, został zakończony i nie będą od niej wymagane żadne dodatkowe akcje.
Usługa w tym stanie może usunąć informacje o kontekście transakcji.
styczeń 2016
33/80
wersja 1.0

Compensating – w tym stanie usługa wykonuje operacje mające na celu kompensację
wykonanych wcześniej operacji.

Compensated – stan po prawidłowym wykonaniu operacji kompensacji.

CompensationFailed – jeżeli proces kompensacji nie powiedzie się, to usługa
przechodzi do tego stanu.

Failed – stan, do którego usługa przechodzi po nieudanym wykonaniu zadania.

Aborting – w tym stanie usługa przerywa wykonywanie zadania. Proces przerywania
może trwać długo ze względu na możliwą konieczność wykonania określonych
czynności, np. zatrzymanie urządzeń realizujących dane zadanie itp.

Aborted – stan po przerwaniu wykonania zadania.

Withdrawn – stan oznaczający, że usługa została anulowana po zakończonej fazie
aranżacji.
Do zmiany powyższych stanów wykorzystywany jest zbiór, zdefiniowanych w ramach
protokołu transakcji, wiadomości. Wiadomości przesyłane z menedżera zadań do usługi
inicjują poszczególne fazy usługi lub dodatkowe operacje. Usługa przesyła wiadomości po
zakończeniu poszczególnych faz, a także w przypadku wystąpienia nieokreślonych zdarzeń.
Rysunek 30 przedstawia diagram stanów usługi i wiadomości powodujące przejścia
pomiędzy stanami.
Wiadomości generowane przez menedżera zadań w poszczególnych stanach:

Inactive – jeżeli usługa jest nieaktywna i można przeprowadzić jej aranżację, to
menedżer zadań wysyła (może to zrobić za pośrednictwem modułu aranżacyjnego) do
zbioru usług danego typu wiadomość Arrange razem z intencją. Rozpoczyna to fazę
aranżacji danego kroku procesu.

Arranging – w fazie aranżacji, po otrzymaniu zbioru zobowiązań, menedżer zadań
akceptuje jedno zobowiązanie, wysyłając wiadomość Accept do wybranej usługi.
Informuje także pozostałe usługi o braku akceptacji ich ofert za pomocą wiadomości
Cancel.

Arranged – normalną operacją po fazie aranżacji jest wywołanie usługi za pomocą
wiadomości Execute, która jest przesyłana razem z danymi wejściowymi dla usługi.
Jeżeli w trakcie wykonywania procesu biznesowego zmieni się stan środowiska
pociągający za sobą konieczność zmiany wcześniej ustalonych warunków wykonania
usługi, to menedżer zadań podejmuje próbę ponownej aranżacji, wysyłając wiadomość
Rearrange. W przypadku konieczności wycofania aranżacji menedżer zadań wysyła
wiadomość Withdraw.

Rearranging – warunki usługodawcy akceptowane są wiadomością Accept. Proces
ponownej aranżacji może być przerwany, np. z powodu przedłużającej się decyzji
usługodawcy. Menedżer zadań przerywa ten proces, wysyłając wiadomość Withdraw.

Executing – w trakcie fazy wykonania usługi może zaistnieć potrzeba jej przerwania.
Operacja ta jest rozpoczynana po wiadomości Abort.

Completed – wykonana usługa może zostać skompensowana po wysłaniu wiadomości
Compensate. Jeżeli proces zostanie zakończony lub wiadomo jest, że usługa nie będzie
kompensowana, menedżer zadań może zakończyć interakcję z nią, wysyłają
wiadomość End.

Aborted – dla przerwanej usługi można podjąć próbę kompensacji, wysyłając do niej
wiadomość Compensate, lub zakończyć transakcję wiadomością End.

Compensating – proces kompensacji może trwać długo. Jeżeli menedżer zadań uzna,
że jest to za długo lub z innego powodu zaistnieje potrzeba przerwania kompensacji,
to do usługi zostaje wysłana wiadomość Abort.
styczeń 2016
34/80
wersja 1.0

Failed – dla usługi zakończonej niepowodzeniem może zostać podjęta próba
kompensacji wywoływana wiadomością Compensate. W tym stanie możliwe jest
również zakończenie transakcji wiadomością End.

Withdrawn, Compensated, CompensationFailed – zakończenie transakcji w tych
stanach wywoływane jest poleceniem End.
Wiadomości wysyłane przez usługę w poszczególnych stanach:

Arranging – w fazie aranżacji usługa wysyła zobowiązanie razem z wiadomością
Terms lub odmawia wykonania usługi wiadomością Refusal.

Arranged – zaaranżowana usługa może odmówić wykonania, wysyłając wiadomość
Refusal.

Rearranging – w trakcie ponownej aranżacji usługa wysyła nowe zobowiązanie
razem z wiadomością Terms lub odmawia wykonania usługi według nowych
wymagań, wysyłając Refusal.

Executing – jeżeli w fazie wykonania usługa nie może wykonać zadania, to musi
wysłać wiadomość Failed. O poprawnym zakończeniu zadania usługa informuje
menedżera zadań za pomocą wiadomości Completed.

Compensating – jeżeli proces kompensacji zakończy się powodzeniem, to usługa
informuje o tym za pomocą wiadomości Compensated, a w przypadku niepowodzenia
wiadomością CompensationFailed.

Aborting – usługa potwierdza przerwanie wykonywania poprzedniej operacji,
wysyłając wiadomość Aborted.
Po otrzymaniu każdej wiadomości odbiorca wysyła wiadomość z potwierdzeniem
poprawnego dostarczenia lub informacje o wystąpieniu błędu razem z jego opisem. Z
niektórymi wiadomościami przesyłane są dodatkowe dane. Zestawienie wiadomości i
odpowiadających im danych przedstawione jest w poniższej tabeli.
Wiadomość
Dane
Arrange
Intencja
Rearrange
Nowa intencja
Terms
Zobowiązanie
Execute
Dane wejściowe usługi
Completed
Dane wyjściowe usługi
Failed
Opis błędu i aktualny stan środowiska
CompensationFailed
Opis błędu i aktualny stan środowiska
Compensated
Aktualny stan środowiska
Aborted
Aktualny stan środowiska
W trakcie realizacji zadania wiadomości przesyłane są według określonych sekwencji. Mogą
one tworzyć różne kombinacje, ale zbiór możliwych wiadomości w danym stanie usługi jest
ściśle określony w protokole transakcji.
W celu zapewnienia spójnego stanu systemu, wiadomości w ramach protokołu muszą być
przesyłane zgodnie z określoną procedurą. Dodatkowo strony muszą zapamiętywać w
odpowiednim momencie czy odbiór wiadomości został potwierdzony przez drugą stronę, a
także datę i godzinę wysłania wiadomości. Te informacje pozwalają określić czy i kiedy
należy ponowić wysłanie danej wiadomości. Na rysunku 31 znajduje się diagram sekwencji
ilustrujący ten proces.
styczeń 2016
35/80
wersja 1.0
Rysunek 31. Diagram sekwencji operacji przy przesyłaniu wiadomości protokołu
Rysunek 32. Diagram sekwencji wiadomości protokołu dla 3 usług tego samego typu
Diagram na rysunku 32 przedstawia kompletną sekwencję przesyłania wiadomości
protokołu dla pojedynczego kroku procesu biznesowego. W Rejestrze usług zarejestrowane
są 3 usługi. Każda z nich zgadza się wykonać usługę według podanych parametrów i przesyła
swoje oferty. Menedżer Zadań wybiera jedna ofertę, a resztę odrzuca wiadomością Cancel.
Następnie wybrana usługa jest wywoływana. Po prawidłowym zakończeniu pracy
powiadamia ona o tym Menedżera Zadań przesyłając wiadomość Completed. Wiadomość
End kończy transakcję. Oznacza to, że usługa nie musi przechowywać dłużej kontekstu
transakcji.
styczeń 2016
36/80
wersja 1.0
styczeń 2016
37/80
wersja 1.0
5. Repozytorium
Rolą Repozytorium jest przechowywanie oraz udostępnianie map obiektowych tworzonych
przez użytkowników i/lub roboty. Dodatkowo Repozytorium przechowuje typy usług
możliwych do świadczenia przez urządzenia w systemie.
Repozytorium zostało zaimplementowane jako aplikacja internetowa, przy użyciu platformy
.NET. Do persystencji danych i modelowania struktur danych wykorzystano Entity
Framework i bazę danych SQL CE (Microsoft SQL Server Compact) oraz ASP.NET MVC 5 do
interakcji z użytkownikiem i innymi systemami.
5.1. Definiowanie typów i zależności między nimi
Na typ składają się atrybuty opisujące cechy obiektów, interfejsy definiujące zachowania
możliwe do wykonania na danym obiekcie oraz innych typów obiektów składających się na
ten typ.
Atrybuty składają się z nazwy, wielkości, typu jednostki, w której będzie przedstawiony (np.
liczba całkowita, zmiennoprzecinkowa, tekst, litera itd.) oraz opcjonalnie opisu. Nazwa
atrybutu musi być unikalna.
Do definicji typu „PlacedMapObject”, reprezentującego wszystkie obiekty posiadające
położenie i obrót, wymagane są 3 atrybuty przedstawiane w formie liczby
zmiennoprzecinkowej, opisujące długość: „PositionX”, „PositionY”, „PositionZ”.
Rysunek 33. Tworzenie atrybutu – warstwa prezentacji
Interfejsy składają się z nazwy, definicji oraz opcjonalnie opisu. Nazwa interfejsu musi być
unikalna.
styczeń 2016
38/80
wersja 1.0
Rysunek 34. Tworzenie interfejsu - warstwa prezentacji
Relacje określane są za pomocą nazwy, dwóch typów będących argumentami relacji oraz
definicji, służącej do jej ewaluowania. Nazwa relacji musi być unikalna. Definicja relacji to
zbiór warunków arytmetycznych połączonych operatorami logicznymi, wykorzystujących
atrybuty obiektów będących argumentami relacji.
Aby wystąpiła relacja „IsIn” (zawierania się) na dwóch obiektach typu „Cuboid”, należy
spełnić następujący warunek:
( ( leftObject.Width * leftObject.Width ) < ( rightObject.Width * rightObject.Width ) ) AND (
leftObject.PositionX < ( rightObject.PositionX + rightObject.Width / 2 ) ) AND (
leftObject.PositionX > ( rightObject.PositionX - rightObject.Width / 2 ) ) AND (
leftObject.PositionZ < ( rightObject.PositionZ + rightObject.Width / 2 ) ) AND (
leftObject.PositionZ > ( rightObject.PositionZ - rightObject.Width / 2 ) ) AND ( (
leftObject.PositionY - leftObject.Height / 2 ) < rightObject.PositionY ) AND (
leftObject.PositionY > ( rightObject.PositionY - rightObject.Height / 2 ) )
Rysunek 35. Tworzenie typu relacji – warstwa prezentacji
styczeń 2016
39/80
wersja 1.0
Typy obiektów definiowane są przez nazwę, opcjonalny opis, typ bazowy, który będzie
rozszerzany, obiekty podrzędne, atrybuty i interfejsy. Nazwa typu musi być unikalna.
Atrybuty są cechami obiektu, np. obiekt typu „Cuboid” będzie musiał posiadać atrybuty
opisujące jego położenie i obrót w układzie odniesienia oraz wielkość.
W typach zostało zaimplementowane dziedziczenie jednokrotne, tj. istnieje możliwość
stworzenia typu pochodnego, rozszerzając jego cechy i zachowania.
Obiekty składowe to grupa typów, które wymagane są do istnienia innego obiektu, np. na stół
składają się cztery nogi i jeden blat, wszystkie te obiekty będą typu „Cuboid”. Dodatkowo
obiekty te posiadają swoją unikalną nazwę, określającą je wewnątrz obiektu stołu, np. blat,
lewa przednia noga, lewa tylna noga, itd. Nazwa ta wymagana jest do ewaluacji relacji
występujących w typie, np. tworząc pokój konkretne ściany muszą się ze sobą stykać oraz
muszą być prostopadłe do podłogi i sufitu, ponadto podłoga musi być na dole pokoju, a sufit
na górze.
Rysunek 36. Tworzenie typu - warstwa prezentacji
5.2. Definiowanie map obiektowych
Mapa obiektowa jest zbiorem obiektów znajdujących się w tym samym pomieszczeniu,
powiązanych ze sobą relacjami. Obiekty mogą być proste (do ich definicji podawane są tylko
atrybuty), lub złożone (na takie obiekty składa się pewna grupa obiektów, która może być
powiązana między sobą relacjami). Przykładem mapy obiektowej może być pokój, składający
się ze ścian, sufitu oraz drzwi, w którym znajduje się szafka, ze słoikiem oraz stół, na którym
stoi miska.
Obiekty należy tworzyć od najbardziej szczegółowych do ogólnych, czyli np. chcąc stworzyć
stół najpierw należy stworzyć jego cztery nogi i blat, a na końcu stół, który łączy wszystkie te
obiekty w całość. Jeśli definiowany obiekt posiada relacje między obiektami podrzędnymi, to
są one automatycznie ewaluowane oraz dodawane podczas zapisywania do słownika.
styczeń 2016
40/80
wersja 1.0
Rysunek 37. Tworzenie obiektu - warstwa prezentacji
Obiekty można połączyć ze sobą przez relację pewnego typu dopasowując obiekty
odpowiednich typów dla tej relacji. Przed zapisaniem relacji ewaluowana jest jej definicja,
która pozwala na sprawdzenie, czy dana relacja na pewno zachodzi między wybranymi
obiektami. Relacja zostanie zapisana tylko w wypadku, gdy jest spełniona.
5.3. Korzystanie z Repozytorium
Repozytorium posiada interfejs pozwalający na pobieranie danych ze słownika. Komunikacja
z repozytorium odbywa się za pomocą protokołu HTTP, do odpowiedzi i wykonania bardziej
złożonych zapytań wykorzystywany jest język XML.
Pobranie listy typów, znajdujących się w Repozytorium, dostępne jest po wysłaniu żądania
metodą GET na adres interfejsu Repozytorium zakończony ścieżką „/GetTypes”. Odpowiedź
na to zapytanie jest dokumentem, który posiada element „ObjectTypes”, zawierający listę
znaczników „ObjectType”, które w posiadają informacje o numerze identyfikacyjnym danego
typu (atrybut „id”), ilości obiektów danego typu w repozytorium (atrybut „instancesCount”)
oraz nazwie typu (wartość znacznika).
Uzyskanie obiektów zadanego typu, znajdujących się w Repozytorium, odbywa się poprzez
wysłanie żądania metodą GET na adres interfejsu Repozytorium zakończony ścieżką
„/GetObjectsByType/1”, gdzie liczba 1 jest numerem identyfikacyjnym typu, którego obiekty
chcemy znaleźć. W odpowiedzi zostanie zwrócony dokument, posiadający element
„ObjectInstances” zawierający listę znaczników „ObjectInstance” przechowujących
informacje o numerze identyfikacyjnym obiektu (atrybut „id”) oraz nazwie tego obiektu
(wartość znacznika).
Otrzymanie szczegółowych informacji o obiekcie możliwe jest poprzez wysłanie żądania
metodą GET na adres interfejsu Repozytorium zakończony ścieżką „/GetObject/1”, gdzie
liczba 1 jest numerem identyfikacyjnym obiektu, którego szczegóły mają zostać pobrane. W
odpowiedzi otrzymywany jest dokument, posiadający element „ObjectInstance” zawierający
szczegóły pożądanego obiektu, tj. numer identyfikacyjny (atrybut „id”), nazwę obiektu
zawartą w elemencie „name”, typ znajdujący się w znaczniku „type”, listę atrybutów,
styczeń 2016
41/80
wersja 1.0
obiektów podrzędnych, relacji oraz interfejsów zawarte w znacznikach kolejno „Attributes”,
„Subobjects”, „Relations”, „Interfaces”.
Lista atrybutów składa się ze znaczników „Attribute” zawierających informacje o nazwie
atrybutu (wartość znacznika „name”), typu jednostki, w której atrybut jest przedstawiany
(wartość znacznika „baseType”) oraz wartości danego atrybutu (wartość znacznika „value).
Lista obiektów podrzędnych zawiera elementy „Subobject” przechowujące informacje o
nazwie obiektu podrzędnego (wartość znacznika) oraz numerze identyfikacyjnym obiektu
będącego obiektem podrzędnym (wartość atrybutu „id”).
Lista relacji składa się ze znaczników „Relation” zawierających informacje o numerze
identyfikacyjnym relacji (atrybut „id”), argumentach relacji i ich numerach identyfikacyjnych
(elementy „leftObject” i „rightObject” oraz ich atrybuty „id”).
Lista interfejsów zawiera elementy „Interface” przechowujące informacje o nazwie interfejsu
(wartość elementu).
Pobranie typów usług, znajdujących się w Repozytorium, dostępne jest po wysłaniu żądania
metodą GET na adres interfejsu Repozytorium zakończony ścieżką „/GetServiceTypes”.
Odpowiedź na to zapytanie będzie posiadała element „ServiceTypes”, zawierający listę
znaczników „ServiceType”, przechowujących informacje o nazwie typu usługi (wartość
elementu „name”), warunkach wstępnych (wartość elementu „precondition”), warunkach
końcowych (wartość elementu „postcondition”), parametrów wejściowych i wyjściowych
(kolejno w elementach „inputEntries” i „outputEntries”).
Lista parametrów wejściowych składa się z elementów „InputEntry” zawierających
informacje o nazwie tego parametru (wartość elementu „name”), typie obiektu (wartość
elementu „objectType”) oraz numerze identyfikacyjnym tego typu (atrybut „id” w elemencie
„objectType”).
Lista parametrów wyjściowych składa się z elementów „OutputEntry” zawierających takie
same informacje jak parametry wejściowe.
Wyszukanie obiektów na podstawie podanych informacji odbywa się poprzez wysłanie
żądania metodą POST na adres interfejsu Repozytorium zakończony ścieżką
„/FindObjectInstance” i załączenia w parametrze „document” kryteriów wyszukiwania w
odpowiednim formacie. W odpowiedzi otrzymywany jest dokument, posiadający element
„ObjectInstances” zawierający listę odpowiadających kryteriom obiektów, które opisane są
tak samo jak w przypadku uzyskiwania szczegółów obiektu. Kryteria wyszukiwania również
muszą mieć taki sam format jak szczegóły obiektu, ale nie muszą być pełne. Elementy
brakujące będą ignorowane przy porównywaniu obiektów.
styczeń 2016
42/80
wersja 1.0
Rysunek 38. Przykładowe zapytanie (po lewej) i odpowiedź (po prawej)
przy wyszukiwaniu obiektu
styczeń 2016
43/80
wersja 1.0
6. Realizacja zadania
6.1.1. Definiowanie zadania
Zadania w systemie Autero definiowane są za pomocą odpowiednich formuł logicznych.
Zadanie określa warunek końcowy, w jakim ma się znaleźć środowisko po jego wykonaniu.
Przy definiowaniu zadań wykorzystywane są obiekty i relacje zdefiniowane w ontologii.
Rysunek 39 zawiera relacje pomiędzy elementami znajdującymi się w Repozytorium a
definicją zadania.
Rysunek 39. Zależności pomiędzy elementami z repozytorium a definicją zadania
Podczas definicji zadania ustalane są także zasoby przeznaczone na jego realizację i czas, do
którego zadanie musi się zakończyć.
6.1.2. Faza planowania
Semantyczny opis usług pozwala na automatyczną kompozycję usług w złożone procesy
biznesowe poprzez dopasowywanie typów usług, które mogą być użyte w danym miejscu
sekwencji procesu, aby była możliwa realizacja zadania. Możliwość automatycznej
kompozycji jest ważna w otwartych i dynamicznych środowiskach, gdzie nie możemy
przewidzieć w czasie projektowania, jakie typy usług będą dostępne w środowisku. Nie
zawsze jednak możliwe jest automatyczne skomponowanie planu dla procesu biznesowego.
W takim przypadku konieczne jest skorzystanie ze zbioru wcześniej przygotowanych
manualnie planów. Algorytmy automatycznie komponujące usługi w procesy mogą bazować
na różnych danych. Mogą to być typy danych wejściowych i wyjściowych usług lub
semantyczne opisy efektów działania usług i ich wymagań początkowych.
Przyjęta reprezentacja usługi, która zakłada istnienie fazy aranżacji, pociąga za sobą
konieczność zdefiniowania odpowiednich relacji w reprezentacji procesu biznesowego.
Dostępne rozwiązanie nie pozwalają na odwzorowanie tych relacji lub wymagałoby
styczeń 2016
44/80
wersja 1.0
zastosowania nieintuicyjnych rozwiązań. Dlatego został opracowany własny format procesu
biznesowego, a także planu, którego proces jest w pewnym sensie rozszerzeniem.
Za kompozycję odpowiada moduł planujący (Planer), który na wejściu otrzymuje aktualne
informacje o stanie środowiska, a także informacje o tym, jaki ma być stan środowiska po
wykonaniu usługi. Opcjonalnym elementem na wejściu jest także informacja o usługach,
które mogą być wykorzystane. W obecnej implementacji Planera wykorzystywany jest zbiór
wcześniej przygotowanych planów. Zadaniem Planera jest więc wybór właściwego planu na
podstawie dostarczonej definicji zadania.
Na wyjściu planer zwraca plan lub zbiór alternatywnych planów w postaci abstrakcyjnego
grafu. W najprostszej wersji będzie to zbiór węzłów (kroków procesu) reprezentujących typy
usług i relacje pomiędzy tymi usługami. Relacja określa kolejność aranżacji i wykonania.
Typy tych relacji zostały omówione przy okazji omawiania fazy aranżacji. Węzły
reprezentujące usługi określonego typu są aranżowane zgodnie z relacjami aranżacji. Usługa,
która zaoferowała wybraną ofertę, jest przypisywana do odpowiedniego węzła w procesie
biznesowym. Wykonując tę czynność dla wszystkich węzłów w procesie, przekształcamy
abstrakcyjny plan procesu z typami usług na wykonywalny proces biznesowy, w którym
poszczególne węzły reprezentują konkretne usługi. Nie zawsze da się jednak zaaranżować
całego procesu przed fazą wykonania. W takiej sytuacji proces biznesowy zawiera węzły z
nieprzypisanymi usługami, dla których aranżacja jest przeprowadzana w dalszym etapie
realizacji procesu.
Plan może także zawierać węzły, które nie reprezentują pojedynczych usług. Mogą to być
grupy węzłów, które są w rzeczywistości zagnieżdżonymi grafami. Plan może przypisywać
także do poszczególnych węzłów procedury obsługi dla operacji kompensacji i obsługi
niepowodzeń. Na rysunku 40 przedstawiono przykładowy plan.
Rysunek 40. Przykładowy plan w postaci graficznej
W systemie Autero relacje między usługami opierają się głównie na warunkach
początkowych i warunkach końcowych usług, opisujących stan części środowiska związanej
styczeń 2016
45/80
wersja 1.0
z realizacją usługi. Te elementy zawarte są w przyjętej reprezentacji usługi. Warunki te są
określane już podczas definiowania typów usług (w sposób ogólny i abstrakcyjny), a w fazie
aranżacji i wykonania są precyzowane. Warunki są także wykorzystywane w fazie
planowania. Mogą być użyte podczas planowania automatycznego.
Rysunek 41. Relacje i warunki pomiędzy trzema usługami
Rysunek 41 przedstawia relacje pomiędzy trzema usługami. Przy każdej usłudze zostały
oznaczone warunki początkowe (WP) i warunki końcowe (WK). Na przykład usługa o typie
T1 wymaga przed rozpoczęciem wykonania spełnienia warunków WP1, a po jej wykonaniu
w środowisku zachodzą warunki określone w WK1. Oznaczenia pozostałych usług są
analogiczne. Usługa typu T3 jest zależna od usług o typach T1 i T2. Warunek początkowy
usługi T3 zawiera się w koniunkcji warunków usług T1 i T2. Oznacza to, że usługi o typach
T1 i T2 zmieniają środowisku w ten sposób, że są spełnione warunki początkowe usługi T3,
ale mogą generować także dodatkowe zmiany środowiska.
Na rysunku 42 zostały przedstawione dwa przykładowe plany realizujące zadanie, które
polega na przetransportowaniu ładunku z punktu A do punktu B. Na trasie znajduje się
przeszkoda wodna. Usługa typu ST1 udostępnia transport lądowy, usługa ST2 transport
wodny, natomiast usługa typu ST3 zapewnia transport drogą powietrzną.
styczeń 2016
46/80
wersja 1.0
Rysunek 42. Plany zadania w postaci graficznej
W przedstawionym przykładzie plan 1 składa się z 3 węzłów reprezentujących usługi, 2 typu
ST1 i jednej typu ST2. Tworzą one sekwencję ST1->ST2->ST1. Oznacza to, że najpierw
zostanie wykorzystana usługa transportu lądowego, której wynikiem będzie
przetransportowanie ładunku z punktu A do punktu C. Punkt C będzie znajdował się gdzieś
na granicy ląd-woda, ponieważ musi być odebrany przez usługodawcę usługi typu ST2 lub do
niego przekazany. Następnie drogą wodną ładunek transportowany jest z punktu C do
punktu D. To zadanie realizuje usługa typu ST2. Końcową trasę (D->B) ładunek pokonuje
drogą lądową z ponownym wykorzystaniem usługi typu ST1. W tym przypadku będzie to
najprawdopodobniej inna usługa (może być ta sama, ale z wykorzystaniem innego robota).
Plan 2 składa się z sekwencji usług typu ST1 i ST3. W tym przypadku ładunek jest
przewożony do punktu pośredniego E przez usługę typu ST1, a resztę drogi transportowany
drogą powietrzną. Taki transport realizuje usługa typu ST3. Alternatywnym planem może
być wykorzystanie tylko usługi transportu drogą powietrzną. W podanym przykładzie należy
jednak przyjąć, że usługa typu ST3 ma ograniczony zasięg i wymaga użycia dodatkowej
usługi.
Dokładna lokalizacja punktów C, D (dla planu 1) i E (dla planu 2) będzie ustalona w fazie
aranżacji. Może także istnieć typ usługi posiadający zdefiniowane takie punkty. Zależy to od
stopnia specjalizacji usługi.
6.1.3. Faza aranżacji
Sposób realizacji usług w realnym świecie bardzo często zależy od wymagań klienta, a także
aktualnego stanu środowiska. Dlatego ważne jest, aby ustalić te warunki przed faktycznym
wykonaniem usługi. Za to odpowiedzialna jest faza aranżacji. W tej fazie do usługi wysyłane
jest zapytanie z wymaganiami klienta zawierające także informacje o dostępnych zasobach
(lub zasobach przeznaczonych na realizację odpytywanej usługi) i żądanym czasie realizacji
usługi, a także aktualny stan środowiska i specyficzne wymagania innych usług z procesu
biznesowego. Usługodawca decyduje czy może wykonać swoje zadanie zgodnie z
przesłanymi parametrami. Jeżeli tak, to przesyła do klienta swoją ofertę zawierającą
dokładne wymagania odnośnie potrzebnych zasobów i czasu realizacji usługi, oraz opis
warunków, które muszą być spełnione, aby umożliwić realizację usługi, w przeciwnym razie
styczeń 2016
47/80
wersja 1.0
wysyła odmowę. Informacje przesyłane do usługodawcy w fazie aranżacji będą nazywane
intencją, a odpowiedź usługodawcy zobowiązaniem. Taki proces odpytywania jest
przeprowadzany także dla innych usług danego typu. Wyboru najlepszego usługodawcy
może dokonywać użytkownik lub może to być wybór automatyczny na podstawie wymagań
użytkownika.
W trakcie przeprowadzania fazy aranżacji intencje dla usług, których aranżacja jest zależna
od innych usług, są zwykle generowane na podstawie zobowiązań tych usług. W ten sposób
tworzy się łańcuch zależności.
Aranżacja usług wykonywanych za pomocą robotów musi uwzględniać nie tylko ich ogólne
właściwości, ale także ich aktualny stan w środowisku i wykonywane przez nie zadania. Za
przykład może posłużyć usługa transportu towaru pomiędzy dwoma punktami. Jeżeli
zleceniodawca chce wykonać usługę jak najszybciej, to kryterium wyboru usługi w fazie
aranżacji będzie przewidywany czas jej realizacji. Przykładowy scenariusz przedstawiony
został na rysunku 43.
Rysunek 43. Przykładowy stan środowiska w fazie aranżacji
W tym przypadku zadanie polega na przetransportowaniu ładunku z punktu A do punktu B, a
dostępne są dwie usługi mogące to zadanie zrealizować. Usługi są tego samego typu i z takimi
samymi atrybutami (reprezentują taki sam typ robota). Są one jednak w różnej odległości od
początkowej pozycji ładunku. Po otrzymaniu intencji zawierającej dokładne położenie
ładunku, Menedżery Usług reprezentujące roboty generują zobowiązanie, określając w nim,
na podstawie swojej aktualnej pozycji, czas w jakim deklarują się wykonać usługę transportu.
Robot 1 znajduje się w odległości 54 od ładunku, natomiast robot 2 w odległości 122, czyli
ponad 2 razy większej. W takim przypadku zobowiązanie wysłane przez Menedżera Usług
reprezentującego robota 1 powinno zawierać krótszy czas realizacji usługi i dlatego ten robot
zostanie wybrany do zrealizowania zadania.
W trakcie aranżacji kontrolowane są zasoby przeznaczone na realizację zadania. W
zobowiązaniach usługi przekazują, oprócz maksymalnego czasu realizacji zadania, także jego
koszt. Te dwa parametry decydują o wyborze najlepszej usługi. Zasoby, których zużycie
deklaruje wybrana usługa, są rezerwowane. Przy analizie możliwości dalszej realizacji
zadania obliczane są dostępne zasoby korzystając z prostego rachunku:
styczeń 2016
48/80
wersja 1.0
zasoby przeznaczone na zadanie – (zasoby skonsumowane przez usługi + zarezerwowane
zasoby)
Jeżeli dostępne środki są równe lub większe od tego, co wymaga usługa, to można
zaakceptować jej zobowiązanie.
6.1.4. Faza wykonania
Przed fazą wykonania usługi Menedżer Zadań przygotowuje odpowiednie dane wejściowe
korzystając z wygenerowanych danych powiązanych usług. Podobnie określane są warunki
początkowe dla usługi, które wynikają z warunków końcowych powiązanych usług i
aktualnego stanu środowiska. Menedżer Zadań przesyła te dane razem z wiadomością
Execute, która nakazuje usłudze rozpocząć zaaranżowaną pracę.
Faza wykonania może być przerwana przez Menedżera Zadań. Taka operacja, zgodnie z
przyjętymi założeniami, nie może powodować niebezpiecznych sytuacji i pozostawiać
nieokreślonego stanu usługi. Jeżeli zadanie wykonuje robot, to wysłanie komunikatu Abort
nie może być równoznaczne z awaryjnym zatrzymaniem robotów lub maszyn realizujących
zadanie. Menedżer Zadań nie kontroluje bezpośrednio sposobu realizacji zadania przez
usługę. Zapewnienie prawidłowego przerwania usługi leży po stronie usługodawcy. Po
przerwaniu pracy usługa powinna powiadomić także Menedżera Zadań o aktualnym stanie
środowiska.
W fazie wykonania Menedżer Zadań kontroluje także czas działania usługi. Jeżeli czas ten
przekroczy czas zadeklarowany przez usługę, to jest ona przerywana i podejmowana jest
próba dokończenia realizacji zadania z wykorzystaniem innych usług.
6.2. Obsługa nieprawidłowych sytuacji
W czasie realizacji usług realizowanych przez roboty może dojść do wielu nieoczekiwanych
zdarzeń, które należy obsłużyć. Robotyka jest dziedziną stale rozwijającą się i na obecnym
etapie niepowodzenia występują stosunkowo często. Oczywiście to stwierdzenie dotyczy
autonomicznych robotów w dynamicznych środowiskach, a nie np. robotów przemysłowych,
które wykonują ściśle zaplanowane i powtarzalne operacje.
Do zilustrowania działania mechanizmów obsługi niepowodzeń zostanie użyte zadanie
polegające na przetransportowaniu ładunku z punktu A do punktu B. Pierwotny plan
zakłada, że zostanie do tego celu wykorzystana jedna usługa, która realizuje to zadanie za
pomocą pojedynczego robota.
Rysunek 44. Wymiana nieprawidłowo zakończonej usługi w zadaniu transportu ładunku
styczeń 2016
49/80
wersja 1.0
Rysunek 44 przedstawia pierwszy etap algorytmu obsługi niepowodzeń, czyli zamianę
nieprawidłowo zakończonej usługi usługą tego samego typu. W fazie aranżacji wybrana
została usługa 1. Usługa ta przetransportowała ładunek tylko do punktu C, po czym zgłosiła
niepowodzenie, przesyłając informację, że obiekt jest w punkcie C. Po otrzymaniu takiej
informacji Menedżer Zadań podejmuje próbę ponownej aranżacji, wyszukując oferty tego
samego typu. W analizowanym przykładzie została wybrana usługa 2, która przetransportuje
ładunek z punktu C do punktu B, realizując w ten sposób zadanie.
Rysunek 45. Wymiana nieprawidłowo zakończonej usługi z użyciem alternatywnego planu
W trakcie realizacji zadania może wystąpić sytuacja uniemożliwiająca robotowi
kontynuowanie pracy, a tym samym brak możliwości zrealizowania świadczonej usługi. Na
przykład robot transportujący ładunek może natrafić na przeszkodę niemożliwą do
ominięcia (dla robota tego typu), która powstała w trakcie wykonania usługi lub była
nieznana w fazie planowania. Jeżeli przyjmiemy, że usługa typu T1 jest specyficzną usługą
transportową wykorzystującą jeden rodzaj robota, to ponowna aranżacja dla tego typu nie
powiedzie się.
W takiej sytuacji należy zaplanować alternatywny sposób realizacji pozostałej części zadania.
Rysunek 45 przedstawia opisaną sytuację i możliwe rozwiązanie. Do dokończenia realizacji
zadania zostały wybrane dwie usługi (typu T2 i T3), które zastąpią usługę 1 na pozostałym
odcinku (z punktu C do punktu B). W fazie aranżacji zostały wybrane usługi 2 i 3. Usługa typu
T2 ma lepsze możliwości pokonywania przeszkód od usługi typu T1, ale posiada także
ograniczony zasięg. Dlatego transportuje ona ładunek tylko do punktu D. Końcowy etap
realizowany jest za pomocą usługi typu T3, która transportuje ładunek drogą powietrzną.
Wszystkie operacje wykonywane są w ramach transakcji, która zawiera dynamiczny zbiór
uczestników. Transakcja nie wymaga, aby wszyscy jej uczestnicy poprawnie zakończyli swoje
zadania. Dzięki temu niepowodzenie pojedynczej usługi lub nawet wielu z nich nie powoduje
konieczności przerwania transakcji. Taka konieczność zachodzi jedynie w momencie, gdy nie
jest możliwa dalsza realizacja zadania. W takim przypadku transakcja kończy się
niepowodzeniem.
Rysunek 46. Procedura kompensacji dla zadania transportu
Przed zakończeniem transakcji możliwe jest także przeprowadzenie kompensacji. Taka
operacja wykonywana jest po anulowaniu realizacji zadania lub po wystąpieniu
niepowodzenia uniemożliwiającego realizację zadania. Kompensacja ma za zadanie
przywrócić stan środowiska sprzed rozpoczęcia wykonywania zadania. Uzyskanie takiej
styczeń 2016
50/80
wersja 1.0
sytuacji jest często niemożliwe, dlatego dąży się do uzyskania sytuacji jak najbardziej
zbliżonej do początkowej. Poszczególne usługi w procesie realizującym zadanie
kompensowane są w kolejności odwrotnej do sekwencji wykonania. Kompensacja
realizowana jest poprzez wywołanie wewnętrznej kompensacji usługi lub procedury
kompensacji przypisanej na poziomie planu do węzła reprezentującego daną usługę (w
przypadku gdy taka procedura została zdefiniowana).
Rysunek 46 przedstawia operację kompensacji dla omawianego zadania. Po wystąpieniu
polecenia anulowania wykonania zadania robot transportujący ładunek, będący aktualnie w
punkcie pomiędzy punktami A i B, przewozi ładunek z powrotem do punktu A. Należy
zauważyć, że w tym przypadku realizowana jest wewnętrzna procedura kompensacji usługi,
czyli operację kompensacji wykonuje ta sama usługa, która wykonywała przerwane
wcześniej zadanie. Nie oznacza to jednak, że do powrotnego transportu ładunku zostanie
wykorzystany ten sam robot. Wynika to z rozdzielenia sterowania wykonaniem usług, za
które odpowiada Menedżer Zadań, od sterowania robotami, które jest zadaniem Menedżera
Usług.
Omówione sposoby postępowania można zapisać w postaci algorytmu. Taki algorytm reakcji
na nieprawidłowe zakończenie usługi został przedstawiony na diagramie na rysunku 47.
Zbiór S zawiera usługi wchodzące w skład podprocesu, który zostanie wymieniony. Zbiór N
zawiera natomiast usługi, które są połączone relacjami sekwencji wykonania z usługami ze
zbioru S.
Rysunek 47. Algorytm obsługi niepowodzeń
styczeń 2016
51/80
wersja 1.0
Po otrzymaniu wiadomości o błędzie następuje próba ponownej aranżacji, która polega na
wyszukaniu innych ofert usług tego samego typu spełniających wymagania zadania. Jeżeli są
dostępne takie usługi, to zostanie wybrana najlepsza oferta i możliwe jest dalsze
realizowanie zadania. W przeciwnym przypadku nieprawidłowo zakończona usługa
dodawana jest do zbioru S. Następnie dla usług ze zbioru S (dokładnie podprocesu złożonego
z tych usług) wyznaczane są warunki początkowe i końcowe. Dla tych warunków
generowany jest nowy plan (zbiór planów, z których zostanie wybrany jeden). Jeżeli operacja
generowania planu zakończy się sukcesem, to jest on zamieniany na podproces, który
następnie jest dołączany do procesu i aranżowany. W przypadku, gdy generowanie nowego
planu dla podanych warunków nie powiedzie się, to tworzony jest zbiór N zawierający usługi
będące bezpośrednimi następnikami usług w zbiorze S (pomijane są usługi, które znajdują
się już w zbiorze S). Po utworzeniu zbioru N jest on dodawany do zbioru S. Tak więc suma
zbiorów S i N staje się nowym zbiorem S. Następnie określane są warunki początkowe i
końcowe dla podprocesu składającego się z usług ze zbioru S. Dalej procedura powtarza się.
Taka pętla kończy się w momencie udanego wygenerowania nowego planu lub gdy zbiór N
będzie zbiorem pustym. Otrzymanie pustego zbioru N oznacza brak możliwości realizacji
zadania. W takim przypadku transakcja kończy się niepowodzeniem.
styczeń 2016
52/80
wersja 1.0
7. Środowisko symulacyjne
Rolą środowiska symulacyjnego jest odwzorowanie mapy z Repozytorium w celu testowania
działania systemu wielorobotowego. Umożliwia dodawanie oraz modyfikację urządzeń i
obiektów.
Środowisko zostało zaimplementowane przy użyciu platformy .NET oraz zintegrowanego
środowiska do tworzenia gier trójwymiarowych Unity3D.
7.1. Możliwości środowiska
Środowisko pozwala na umieszczanie obiektów utworzonych w Repozytorium oraz różnego
typu urządzeń takich jak np. kamery, roboty, automatycznie otwierane drzwi, windy oraz
wiele innych. Ponadto silnik Unity3D posiada bardzo rozbudowaną fizykę, przez co możliwe
jest uzyskanie kolizji między obiektami, działania grawitacji, tworzenia płaszczyzn kolizji
dopasowanych do kształtu obiektu, symulowania oświetlenia powodującego realistyczne
cienie itd. Ponadto środowisko umożliwia Menedżerom Usług komunikację z symulowanymi
urządzeniami przez gniazda sieciowe.
7.2. Generowanie środowiska na podstawie map obiektowych
Środowisko pozwala na odwzorowanie wszystkich obiektów znajdujących się w
Repozytorium. Po dodaniu nowego typu lub relacji do słownika wymagane jest
zaimplementowanie odwzorowania po stronie środowiska.
Wszystkie klasy odpowiadające obiektom w Repozytorium związane są z abstrakcyjną klasą
bazową SimulationObject. Jest ona odpowiedzialna za przetworzenie uzyskanego z
Repozytorium dokumentu XML przedstawiającego obiekt. Klasa służy do pobrania informacji
o nazwie i typie obiektu, jego pozycji oraz rotacji, masie, wymiarach, ewentualnym materiale,
który należy nałożyć na ten obiekt, informację o tym, czy na obiekt będzie wpływała
grawitacja oraz uchwyt do odpowiadającego mu, podczas działania symulacji, obiektowi
klasy GameObject. Ponadto klasa przechowuje listy wszystkich atrybutów, relacji oraz
interfejsów potrzebne do odwzorowania obiektów w środowisku.
styczeń 2016
53/80
wersja 1.0
Rysunek 48. Diagram klas hierarchii obiektów w środowisku symulacyjnym
Najprostszym obiektem, odwzorowywanym w środowisku, jest prostopadłościan, który w
Repozytorium posiada atrybuty informujące o jego położeniu i obrocie, wymiarach, wadze,
oraz teksturze na niego nałożonej. Jest on reprezentowany przez klasę CuboidObject,
rozszerzającą abstrakcyjną klasę bazową SimulationObject. W środowisku prostopadłościan
tworzony jest przy pomocy wbudowanego w Unity3D obiektu sześcianu, któremu
modyfikowane są parametry.
Obiektami, które rozszerzają funkcjonalności prostopadłościanu są drzwi (klasa DoorObject)
oraz winda (klasa ElevatorObject), które są symulowanymi urządzeniami, posiadającymi
własne Menedżery Usług.
Drzwi mają możliwość otwierania oraz zamykania się, muszą być ulokowane wewnątrz
ściany i połączone z nią relacją typu „isPlacedIn”. Relacja ta w środowisku powoduje
„wycięcie” dziury na drzwi w ścianie. Polega to na podzieleniu jednego obiektu ściany na 3
obiekty mniejsze.
Winda posiada możliwość poruszania się między piętrami. Ilość oraz wysokość pięter jest z
góry zdefiniowana w Repozytorium.
styczeń 2016
54/80
wersja 1.0
Rysunek 49. Ściana i drzwi połączone relacją isPlacedIn
Kolejnym obiektem prostym jest sfera, która w Repozytorium posiada informację o jej
położeniu i obrocie, promieniu, wadze oraz teksturze na nią nałożonej. Sfera reprezentowana
jest przez klasę SphereObject, rozszerzającą abstrakcyjną klasę bazową SimulationObject. W
środowisku sfera tworzona jest przy pomocy wbudowanego w Unity3D obiektu sfery,
któremu modyfikowane są parametry.
Obiektem rozszerzającym funkcjonalność sfery granulat (klasa GranulesObject). Granulat w
Repozytorium zapisany jest jako jeden obiekt, natomiast po stronie środowiska
symulacyjnego odwzorowywany jest przez pewną zdefiniowaną ilość sfer, które tworzone są
w punkcie, wskazywanym przez słownik. Tworzenie obiektu w ten sposób umożliwia
uzyskania realistycznego wypełnienia naczynia (np. słoika) przez swobodnie opadający
symulowany granulat.
Kolejnym symulowanym urządzeniem, generowanym w symulacji jest kamera (klasa
CameraObject, rozszerzająca klasę SimulationObject). Kamera w symulacji jest
reprezentowana przez wbudowany w Unity3D obiekt kamery, który pozwala na
wyświetlanie obrazu w oknie gry. Aby uzyskać możliwość wyświetlania wielu kamer w tym
samym czasie został zaimplementowany skrypt skalujący obraz z kamer, pozwalający na
wyświetlenie jednej kamery głównej, zajmującej 2/3 wielkości okna gry, 3 kamer
pobocznych, umieszczonych po prawej stronie kamery głównej oraz siatki wyświetlającej
pozostałe kamery, umieszczonej na dole okna gry.
Najważniejszym symulowanym urządzeniem w środowisku są roboty, reprezentowane przez
obiekty klasy RobotObject, rozszerzającej abstrakcyjną klasę bazową. Istnieje możliwość
symulowania robota z chwytakiem, robota z kontenerem oraz robota sprzątającego.
Robot z chwytakiem posiada podwozie z czterema kołami, które nie posiadają możliwości
skrętu. Aby obrócić robota należy wykonać obrót kół na obu osiach w przeciwnych
kierunkach. Ponadto robot posiada ramie z pięcioma stopniami swobody oraz chwytak z
dwoma stopniami swobody. Przy użyciu wyżej wymienionych elementów możliwe jest
uzyskanie zachowań: przemieszczenie się do zadanego punktu, przemieszczenie się w
okolicę jakiegoś punktu, przesunięcie ramienia do zadanego punktu, zamknięcie (zaciśnięcie)
i otwarcie chwytaka oraz obrót chwytaka, np. w celu przesypania zawartości.
Robot z pojemnikiem posiada podwozie takiego samego typu, jak w przypadku robota z
chwytakiem. Dodatkowo robot posiada pojemnik z podnośnikiem, który pozwala na
otwieranie i zamykanie samego kontenera oraz wysuwanie i opuszczanie podnośnika. W
przypadku, gdy przewożony obiekt jest zbyt dużych rozmiarów, istnieje możliwość
opuszczenia samego podnośnika, bez zamykania kontenera.
styczeń 2016
55/80
wersja 1.0
Robot sprzątający posiada podwozie takiego samego typu, jak w przypadku powyższych
robotów. Robot ma za zadanie sprzątanie granulatu, który spadł na podłogę, posiada on
wysuwaną prowadnicę, pozwalającą na wysypywanie zebranych przez robota elementów.
Rysunek 50. Roboty dostępne w środowisku
Obiekty zawierające elementy (obiekty) podrzędne tworzone są przy pomocy klasy
ComplexObject, rozszerzającej klasę SimulationObject, która pozwala na połączenie ze sobą
wszystkich tych obiektów. Dodatkowo wyliczana jest całkowita masa tworzonego obiektu.
Pozostałe typy, które posiadają kształty trudne do osiągnięcia poprzez łączenie obiektów
prostych tworzone są przy użyciu klasy PremadeObject. Obiektami takimi są np. miska, słoik
lub materiały niebezpieczne. W środowisku Unity3D uzyskiwane są one z utworzonych
wcześniej modeli trójwymiarowych, do których dodawane są odpowiednie collidery,
pozwalające na jak najdokładniejsze odwzorowanie kolizji między obiektami. Środowisko
Unity3D posiada również collidery pobierające swój kształt z modelu, na który są nakładane,
przez co pozwalają na idealne odwzorowanie kształtu fizycznego obiektu, lecz silnik nie
pozwala na wykrywanie między nimi kolizji. Kolizje na elementach takiego typu możliwe są
po uwypukleniu kształtu, lecz wtedy takie obiekty nie pozwalałyby na umieszczanie w nich
innych obiektów, np. nie dało by się wypełnić słoika granulatem.
Rysunek 51. Słoik z widocznymi colliderami
styczeń 2016
56/80
wersja 1.0
7.3. Środowisko testowe
Środowisko testowe składa się z czterech pomieszczeń: dwóch pomieszczeń na parterze,
jednego na piętrze oraz windy. Jedno z pomieszczeń na parterze jest puste, posiada tylko
drzwi wyjściowe na zewnątrz, drzwi do pokoju obok oraz do windy. Drugie pomieszczenie na
parterze zawiera stół, na którym stoi miska, szafkę, na której stoi słoik z granulatem oraz
dwa roboty: robota z ramieniem oraz robota sprzątającego. W windzie znajduje się jedynie
podnośnik, służący do przemieszczania się między piętrami. Pomieszczenie na piętrze
posiada szafkę, na której stoi słoik z granulatem oraz również dwa roboty: robota z
ramieniem oraz robota z pojemnikiem.
Rysunek 52. Środowisko testowe
Ponadto wszystkie pomieszczenia posiadają umieszczone w ich rogu kamery, kamera w
windzie porusza się razem z podnośnikiem. Każdy robot posiada co najmniej jedną kamerę
umiejscowioną za nim, pozwalającą na widok z trzeciej osoby. Niektóre roboty posiadają
dodatkowe kamery, umiejscowione w zależności od typu urządzenia, np. robot z ramieniem
posiada kamerę podłączoną do chwytaka, a robot z pojemnikiem posiada kamerę na kabinie
pozwalającą na podgląd pojemnika.
styczeń 2016
57/80
wersja 1.0
Rysunek 53. Podgląd kamer, widoczny po uruchomieniu środowiska testowego.
styczeń 2016
58/80
wersja 1.0
8. Eksperymenty
Scenariusze zostały wykonane na 3 komputerach. Menedżer Zadań był uruchomiony na
pierwszym komputerze. Na drugim część Menedżerów Usług, a pozostałe komponenty
(Repozytorium, Rejestr Usług, symulacja i Menedżery Usług) na trzecim. Poza symulacją,
komponenty systemu nie wymagają dużej mocy obliczeniowej, więc umieszczenie tylu
komponentów na jednym komputerze nie stanowiło problemu.
8.1. Scenariusz 1 – transport słoika z szafki na platformę
Pierwszy scenariusz testowy będzie polegał na przewiezieniu przedmiotu z otwartej szafki
na platformę.
Rysunek 54 Przebieg zadania transportu
Transportowanym przedmiotem jest w tym przypadku słoik z zawartością (granulkami).
Zadanie jest realizowane przez jedną usługę typu TransferObject reprezentującej jednego
robota wyposażonego w chwytak. Zadanie jest zdefiniowane następująco:

warunki początkowe: Jar002 isOn ?Shelf

warunki końcowe: Jar002 isOn Platform001
Plan zadania transportu słoika:
<?xml version="1.0" encoding="utf-8" ?>
<plans>
<plan>
<step id="1">
<task serviceType="TransferObject">
</task>
</step>
</plan>
</plans>
W fazie aranżacji do usługi typu TransferObject to wysyłane są zarówno warunki
początkowe, jak i końcowe zadania. Usługa w zobowiązaniu nie zmienia warunków
początkowych, które niezmienione pozostają także do fazy wykonania i są wysyłane z
wiadomością rozpoczęcia wykonania (Execute).
Po otrzymaniu wiadomości rozpoczynającej fazę wykonania, Menedżer Usług wysyła robota
w pobliże szafki, tak aby transportowany przedmiot był w zasięgu chwytaka. Następnie
styczeń 2016
59/80
wersja 1.0
przedmiot jest chwytany, ramię ustawia się w odpowiedniej pozycji transportowej i robot
podjeżdża do platformy, na której odkłada słoik.
Przebieg scenariusza w symulacji:
Fazy realizacji scenariusza w symulacji zostały przedstawione na rysunku 55.
Rysunek 55 Przebieg zadania transportu w symulacji
Zrzuty ekranu symulacji przedstawiają następujące etapy:

A – podjeżdżanie do obiektu

B – chwytanie obiektu

C – transport obiektu

D – odkładanie obiektu
Rysunek 56 Środowisko po wykonaniu zadania transportu słoika
styczeń 2016
60/80
wersja 1.0
Powyższy rysunek obrazuje stan środowiska po wykonaniu zadania, co oznacza, że słoik jest
na platformie.
Rysunek 57. Sekwencja wiadomości protokołu transakcji dla zadania transportu obiektu
Scenariusz 1b – niepowodzenie: uszkodzenie napędu robota
W czasie wykonywania zadania transportu może dojść do wielu niepowodzeń. Jednym z nich
jest częściowe uszkodzenie robota, w tym przypadku będzie to uszkodzenie napędu. W takiej
sytuacji robot posiada działającą jednostkę sterującą i może komunikować się z resztą
systemu. Posiada także działający nadal chwytak. Odkłada więc transportowany przedmiot
na ziemię i wysyła do Menedżera Zadań informację o jego położeniu (warunki końcowe:
Jar002.PositionX=12.5 AND Jar002.PositionY=1.3 AND Jar002.PositionZ=7). Dzięki temu
Menedżer Zadań może podjąć akcje pozwalające na dokończenie zadania. W analizowanym
scenariuszu znajduje inną usługę tego samego typu (TransferObject - transport przedmiotu) i
zleca jej wykonanie, wskazując jako sytuację wejściową otrzymaną od robota pozycję słoika.
Realizacja drugiej usługi polega na podjechaniu do miejsca uszkodzenia robota, podniesieniu
słoika z ziemi, przetransportowaniu do pozycji docelowej i odłożeniu słoika na platformę.
Rysunek 58 Przebieg zadania uwzględniający uszkodzenie napędu robota
styczeń 2016
61/80
wersja 1.0
Rysunek 59 Przebieg scenariusza w symulacji - fragment realizowany przez pierwotnie
wybranego robota
Zrzuty ekranu na rysunkach powyżej i poniżej przedstawiają następujące etapy scenariusza:

A – podjechanie i chwycenie słoika przez robota (oznaczmy go numerem 1).

B – transport słoika przez robota 1.

C – uszkodzenie napędu w robocie 1.

D – odłożenie przedmiotu.

E – robot 2, realizujący zastępczą usługę transportu podjeżdża pod słoik.

F – robot 2 chwycił słoik.

G – dalszy transport słoika przez robota 2.

H – robot 2 odkłada słoik na platformie docelowej.

I – słoik znajduje się na platformie, co oznacza, że zadanie zostało poprawnie
wykonane.
styczeń 2016
62/80
wersja 1.0
Rysunek 60 Przebieg scenariusza w symulacji - kończenie zadania przez usługę zastępczą
styczeń 2016
63/80
wersja 1.0
Rysunek 61. Sekwencja wiadomości protokołu transakcji dla zadania transportu z
niepowodzeniem
Rysunek 61 przedstawia kompletną sekwencję wiadomości protokołu ABTP podczas
realizacji zadania według scenariusza 1b. Nieprawidłowo zakończona usługa
TransferObject 1 nie uczestniczy w ponownej aranżacji. Wiadomość Arrange wysyłana jest
tylko do usługi TransferObject 2. Do obu usług na koniec zostaje przesłana wiadomość End,
oznaczająca zakończenie transakcji.
Scenariusz 1c –
komunikacyjnego
niepowodzenie:
uszkodzenie
napędu
robota
i
modułu
Wersja c scenariusza jest rozszerzeniem (bardziej skomplikowanym niepowodzeniem)
scenariusza b. W tym przypadku, poza uszkodzeniem napędu, uszkodzeniu uległ moduł
komunikacyjny. Mogło to nastąpić np. w wyniku fizycznego uszkodzenia anteny razem z
kołem w wyniku zderzenia z innym obiektem. W takiej sytuacji robot odkłada słoik, ale nie
może wysłać informacji o niepowodzeniu i aktualnej sytuacji środowiska (położenia słoika).
styczeń 2016
64/80
wersja 1.0
Rysunek 62. Przebieg zadania transportu słoika z wystąpieniem niepowodzenia usługi w
przypadku braku powiadomienia o tym zdarzeniu
Jeżeli po upłynięciu czasu przeznaczonego na wykonanie usługi Menedżer Zadań nie otrzyma
informacji o poprawnym wykonaniu lub niepowodzeniu, to przyjmuje on, że usługa
zakończyła się niepowodzeniem i podejmuje kroki pozwalające na dalszą realizację zadania.
W opisanej sytuacji Menedżer Zadań wysyła do Planera żądanie wygenerowania planu
realizacji zadania zastępującego nieprawidłowo zakończoną usługę, ale uwzględniając także
nieznaną sytuację wejściową. Usługa transportowa wymaga na wejściu aktualnej pozycji
obiektu do transportu, dlatego do planu zostanie dodana usługa mająca za zadanie znaleźć
aktualną pozycję obiektu, na którego transporcie polegało zadanie klienta.
Plan dokończenia zadania dla nieznanego stanu środowiska po niepowodzeniu:
<plans>
<plan>
<step id="1">
<task serviceType="Find"> </task>
</step>
<step id="2">
<task serviceType="TransferObject"> </task>
</step>
<rules>
<relationship arrangementType="AfterExecution">
<step id="1"/>
<step id="2"/>
</relationship>
</rules>
</plan>
</plans>
Powyższy listing przedstawia plan dokończenia zadania. Poza usługą TransferObject
w planie znajduje się usługa Find, której zadaniem jest znalezienie obiektu do transportu.
Usługi połączone są relacją AfterExecution. Oznacza to, że usługa TransferObject będzie
aranżowana dopiero po wykonaniu usługi Find. Podyktowane to jest tym, że usługa
transportu musi już w fazie aranżacji znać lokalizacje początkowe i końcowe
transportowanego obiektu.
styczeń 2016
65/80
wersja 1.0
Rysunek 63. Przebieg scenariusza 1c w symulacji - transport, niepowodzenie, ustalanie
aktualnej sytuacji
Zrzuty ekranu na rysunkach 63 i 64 przedstawiają następujące etapy scenariusza:

A – podjechanie i chwycenie słoika przez robota 1.

B – transport słoika przez robota 1.

C – uszkodzenie napędu w robocie 1 i odłożenie słoika.

D – przeszukanie otoczenia w poszukiwaniu słoika.

E – chwycenie słoika przez robota 2, realizującego zastępczą usługę transportu.

F – transport słoika przez robota 2.

G – słoik znajduje się na platformie, co oznacza, że zadanie zostało poprawnie
wykonane.
styczeń 2016
66/80
wersja 1.0
Rysunek 64. Przebieg scenariusza 1c w symulacji - kończenie zadania przez usługę zastępczą
8.2. Scenariusz 2 – unieszkodliwienie bomby
Scenariusz 2 jest po części rozwinięciem scenariusza 1. Zamiast słoika transportowany jest
niebezpieczny ładunek wybuchowy (bomba). Docelowym miejscem jest platforma
urządzenia do unieszkodliwienia ładunku.
Rysunek 65 Przebieg zadania unieszkodliwienia bomby
W tym przypadku zadanie realizowane jest za pomocą dwóch usług. Pierwsza jest usługą
transportującą ładunek, natomiast druga unieszkodliwia ładunek, który został wcześniej
umieszczony na odpowiedniej platformie. Zadanie jest zdefiniowane następująco:

warunki początkowe: Bomb001 isIn Cabinet001

warunki końcowe: Bomb001 isIn Platform001
styczeń 2016
67/80
wersja 1.0
Plan zadania dla scenariusza 2:
<plans>
<plan>
<step id="1">
<task serviceType="TransferObject">
</task>
</step>
<step id="2">
<task serviceType="ExplosivesDisposal">
</task>
</step>
<rules>
<relationship arrangementType="Reversed">
<step id="1"/>
<step id="2"/>
</relationship>
</rules>
</plan>
</plans>
Na listingu powyżej został zamieszczony plan zadania dla scenariusza 2. Zawiera on dwie
usługi o typach TransferObject i ExplosivesDisposal, czyli odpowiednio usługa transportowa
i usługa neutralizująca niebezpieczny ładunek (np. ładunek wybuchowy). Usługi w planie są
połączone relacją Reversed, co oznacza, że pomiędzy usługami, których dotyczy ta relacja,
faza aranżacji przebiega w odwrotnej kolejności do fazy wykonania. Aby unieszkodliwić
ładunek, usługa typu ExplosivesDisposal wymaga umieszczenia go w odpowiednim miejscu.
To miejsce jest podawane w fazie aranżacji. Wymagane warunki początkowe określone w
zobowiązaniu to „Bomb001 isOn Platform001”. Dopiero po zaaranżowaniu tej usługi można
więc zaaranżować usługę transportową z warunkami początkowymi „Bomb001 isIn
Cabinet001” i warunkami końcowymi „Bomb001 isOn Platform001”. W czasie wykonania
usługi realizują zadania według zaaranżowanych warunków.
styczeń 2016
68/80
wersja 1.0
Rysunek 66. Przebieg scenariusza 2a w symulacji - chwycenie i transport bomby
Na rysunkach 66 i 67 przedstawiono następujące etapy realizacji zadania:

A – przemieszczanie robota w kierunku bomby.

B – chwytanie bomby.

C – transport bomby do miejsca unieszkodliwienia.

D – umieszczenie bomby na specjalnej platformie urządzenia unieszkodliwiającego.

E – otworzenie platformy.

F – przemieszczenie bomby do wnętrza urządzenia.

G – zamknięcie platformy i unieszkodliwienie bomby
styczeń 2016
69/80
wersja 1.0
Rysunek 67 Unieszkodliwienie bomby
Rysunek 68. Sekwencja wiadomości protokołu transakcji dla zadania unieszkodliwienia
bomby
styczeń 2016
70/80
wersja 1.0
Scenariusz 2b – detonacja bomby transportowanej windą
Alternatywną wersją scenariusza 2 jest przypadek, gdzie bomba i platforma
unieszkodliwiająca znajdują się na innych piętrach budynku. W takiej sytuacji robot musi
skorzystać z windy, aby przemieścić się wraz z ładunkiem na właściwe piętro.
Rysunek 69 Przebieg zadania unieszkodliwienia bomby z uwzględnieniem windy
W ramach tego scenariusza wykorzystywana jest możliwość zlecania zadań w Menedżerze
Zadań przez inne komponenty systemu. Winda jest traktowana jako usługa, której zadanie
polega na dojechaniu na żądane piętro. Robot dojeżdża z bombą do windy i zleca
(komponentem zlecającym jest Menedżer Usług obsługujący danego robota) zadanie
dojechania windy na piętro, na którym aktualnie znajduje się ten robot. Po zaaranżowaniu
odpowiedniej usługi i jej wykonaniu, robot otrzymuje potwierdzenie wykonania zadania.
Oznacza to, że winda dojechała na wskazane piętro i jej drzwi otworzyły się. Następnie robot
wjeżdża do środka i zleca wykonanie zadania przejechania windy na docelowe piętro. Po
wykonaniu zadania windy robot wyjeżdża z niej i kieruje się do platformy urządzenia
neutralizującego, na którą odkłada bombę. Jest ona następnie wciągana do środka urządzenia
i neutralizowana.
styczeń 2016
71/80
wersja 1.0
Rysunek 70. Przebieg scenariusza 2b w symulacji - transport bomby windą
Na rysunkach 70 i 71 przedstawiono następujące etapy realizacji zadania:

A – przemieszczanie robota z bombą w kierunku windy.

B – wjechanie robota do windy.

C – przekrój budynku z widoczną windą na pierwszym piętrze.

D – przekrój budynku z widoczną windą na parterze.

E – wyjechanie z windy.

F – transport bomby do urządzenia unieszkodliwiającego.

G – umieszczenie bomby na platformie urządzenia.

H – zamknięcie platformy i unieszkodliwienie bomby.
styczeń 2016
72/80
wersja 1.0
Rysunek 71. Przebieg scenariusza 2b w symulacji – unieszkodliwienie bomby
styczeń 2016
73/80
wersja 1.0
Rysunek 72. Sekwencja wiadomości protokołu transakcji dla zadania unieszkodliwienia
bomby transportowanej windą
styczeń 2016
74/80
wersja 1.0
8.3. Scenariusz 3 – Transfer zawartości obiektu
Zadanie w scenariuszu 3 polega na przetransportowaniu zawartości słoika znajdującego się
w szafce do miski znajdującej się na stole. Zawartością słoika jest granulat, którego transfer
będzie polegał na operacji przesypania.
Rysunek 73 Przebieg zadania przesypania zawartości obiektu
Zadanie jest zdefiniowane następująco:

warunki początkowe: ?Granules002 isIn Jar001

warunki końcowe: ?Granules002 isIn Bowl001
Plan zadania dla scenariusza 3:
<plans>
<plan>
<step id="1">
<task serviceType="TransferContent">
</task>
</step>
<step id="2">
<task serviceType="CleanArea">
</task>
</step>
<failureHandler id="3" stepId="1">
<step id="2"/>
</failureHandler>
</plan>
</plans>
Powyższy listing przedstawia plan realizacji zadania. Zadanie jest realizowane z
wykorzystaniem jednego typu (TransferContent) usługi, która realizuje transfer zawartości.
Wykorzystana konkretna usługa (reprezentująca robota z chwytakiem) może realizować
zadania transferu zawartości polegające na przesypaniu lub przelaniu. Dodatkowo w planie
znajduje się zdefiniowana procedura obsługi niepowodzenia zawierająca usługę typu
CleanArea. Wywołuje się ona w przypadku niepowodzenia w trakcie transferu zawartości.
Pierwszy etap realizacji zadania transferu jest analogiczny jak w przypadku zadania
przeniesienia obiektu. W tym przypadku robot nie odkłada jednak słoika, a odpowiednio go
przekręca nad miską, powodując przesypanie zawartości. Po tej operacji odstawia pusty słoik
z powrotem do szafki.
styczeń 2016
75/80
wersja 1.0
Rysunek 74. Przebieg scenariusza 3a w symulacji - chwycenie i transport słoika z granulatem
Przebieg scenariusza przedstawiony na zrzutach (Rysunek 74 i Rysunek 75), zawiera
następujące kroki i stany:

A – podjechanie robota do szafki, w której znajduje się słoik z zawartością
(granulatem).

B – chwycenie słoika.

C – transport słoika do miejsca gdzie jego zawartość zostanie przesypana.

D – przygotowanie do operacji przesypania granulatu.

E – przesypywanie granulatu.

F – zawartość słoika została w całości przesypana do miski na stole.

G – odstawienie słoika do szafki.
styczeń 2016
76/80
wersja 1.0
Rysunek 75. Przebieg scenariusza 3a w symulacji - przesypanie granulatu i odstawienie
słoika
Zadanie można traktować jako wykonane już po ukończeniu pełnego przesypywania
granulek do miski. Po tej operacji mamy sytuację środowiska, w której granulat znajduje się
w misce, czyli zgodnie z definicją zadania. Odstawienie słoika jest już dodatkową operacją
usługi, ale wydaje się naturalne dla takiego zadania. Zwykle po skorzystaniu z substancji w
jakimś pojemniku (kawa, herbata, cukier) odstawiamy go w to samo miejsce. W przypadku
całkowitego opróżnienia pojemnika źródłowego można jeszcze rozważyć jego wyrzucenie,
ale w tym przypadku przyjęto, że robot tego nie robi.
styczeń 2016
77/80
wersja 1.0
Rysunek 76. Sekwencja wiadomości protokołu transakcji dla zadania przesypania granulatu
Scenariusz 3b – ubytek części transportowanej zawartości
W trakcie realizacji analizowanego w scenariuszu 3 zadania może dojść do niepowodzenia
polegającego na wydostaniu się transferowanej substancji poza pojemnik docelowy. W takim
przypadku zostanie uruchomiona procedura obsługi niepowodzenia (zdefiniowana
wcześniej w planie), zawierającą usługę (CleanArea) sprzątającą substancję (granulki), która
znalazła się na podłodze. Po sprzątaniu granulki są transferowane do wskazanego miejsca.
Może to być miska, do której miały trafić pierwotnie. W takim przypadku, po zakończeniu
procedury obsługi niepowodzenia, zadanie kończy się sukcesem (wszystkie granulki
znajdują się w obiekcie docelowym). Jeżeli zadanie wymaga przetransferowania wszystkich
granulek, a robot sprzątający nie zdołał ich znaleźć lub nie mogą być one umieszczone w
pojemniku docelowym, to zadanie kończy się niepowodzeniem. W opisywanym scenariuszu
została wybrana pierwsza opcja, dlatego warunki końcowe dla usługi sprzątania to
„?Granules002 isIn Bowl001”. Warunki początkowe są przekazywane z usługi zakończonej
niepowodzeniem, która wysłała opis sytuacji wskazującej, że granulki znajdują się na
podłodze (?Granules002 isOn Floor001).
Rysunek 77 Przebieg zadania przesypania zawartości słoika do miski z zebraniem rozsypanej
zawartości
styczeń 2016
78/80
wersja 1.0
Przebieg scenariusza 3b w symulacji jest do momentu zakończenia przesypywania taki sam
jak w wersji 3a. W scenariuszu 3b po przesypaniu okazuje się, że część granulek jest na
podłodze, jak zostało to zaznaczony kółkiem na zrzucie ekranu A.
Rysunek 78. Pierwszy etap realizacji procedury obsługi niepowodzenia
Procedura obsługi niepowodzenia w symulacji (Rysunek 78 i Rysunek 79) wygląda
następująco:

A – wykrycie nieprawidłowego wykonania zadania.

B – zlecenie wykonania usługi w ramach zdefiniowanej procedury obsługi –
uruchomienie robota sprzątającego.

C – działanie robota sprzątającego.

D – zakończenie zbieranie rozsypanego granulatu.

E – przygotowanie do wysypania sprzątniętego granulatu.

F – wysypywanie granulatu do pojemnika, w którym miał się, według definicji
zadania, znaleźć.

G – wszystkie granulki zostały umieszczone w misce na stole, co oznacza, że zadanie
zostało wykonane poprawnie.
styczeń 2016
79/80
wersja 1.0
Rysunek 79 Drugi etap realizacji procedury obsługi niepowodzenia
Rysunek 80. Sekwencja wiadomości protokołu transakcji dla zadania przesypania granulatu
w przypadku niepowodzenia usługi przesypującej
styczeń 2016
80/80

Full documentation

Transkrypt

Podobne dokumenty

Ogólny plan zajęć teoretycznych i praktycznych z robotyki

Tworzenie animacji postaci z wykorzystaniem klatek - Gimp

INWESTOR Państwowe Muzeum Auschwitz