Praca dyplomowa magisterska

Transkrypt

1 Politechnika Warszawska W Y D Z I A Ł E L E K T R O N I K I I T E C H N I K I N F O R M A C Y J N Y C H Instytut Automatyki i Informatyki Stosowanej Praca dyplomowa magisterska na kierunku Automatyka i Robotyka Agentowa specyfikacja systemu sterujacego robota manipulacyjnego IRp-6 Maciej Piotr Węgierek Numer albumu promotor dr inż. Tomasz Winiarski WARSZAWA 2018

2

3 Streszczenie Tytuł: Agentowa specyfikacja systemu sterującego robota manipulacyjnego IRp-6 Praca traktuje o opisie struktury sterownika robota manipulacyjnego IRp-6, bazującym na podejściu do specyfikacji systemów opartym na istnieniu agenta upostaciowionego. W pracy podjęto się próby zdefiniowania podziału całego systemu na komunikujące się ze sobą agenty. Praca koncentruje się na opisie agenta odpowiedzialnego za oprogramowanie robota. Szczególną wagę przyłożono do definicji zachowań systemu z uwzględnieniem częściowych funkcji przejść składających się na właściwe funkcje przejść danego zachowania. W pracy uwzględniono nie tylko zasadniczy tryb pracy sterownia, ale również jego inicjalizację, synchronizację napędów oraz awaryjne zatrzymanie. Słowa kluczowe: agent upostaciowiony, manipulator, robot IRp-6, specyfikacja, sterownik, SysML, synchronizacja napędów Abstract Title: Embodied Agent based IRp-6 manipulating robot control system specification The aim of the thesis was to present a specification of IRp-6 manipulating robot control system. The specification is based on Embodied Agent theory. Definition of a system division into a set of communicating agents was the first goal of the work. The thesis concentrates on the robot software agent description. The particular importance was given to the system behaviors definition. Transition functions of the behaviors were decomposed into partial functions. Not only a main operating mode of a system, but also its initialization, performance of a robot synchronization and emergency stop was considered. A system modeling language SysML was used as a graphical form of specification. Keywords: Embodied Agent, manipulator, IRp-6 robot, specification, control system, SysML, drives synchronization

4 D

5

6 F

7 Spis treści 1. Wstęp Motywacja Cel pracy Układ pracy Metodyka specyfikacji i formy jej opisu Agent upostaciowiony Metamodel agenta upostaciowionego Struktura wewnętrzna agenta Hierarchia elementów definiujących działanie agenta Automat skończony opisujący zachowanie Funkcja przejścia i jej dekompozycja Język modelowania systemów SysML Przegląd istniejących specyfikacji sterownika robota IRp Założenia Ograniczenia sprzętowe robot Ograniczenia sprzętowe interfejs użytkownika Ograniczenia funkcjonalności Metodyka specyfikacji i forma jej opisu Metodyka badania działania sterownika Powiązanie specyfikacji z implementacją systemu Specyfikacja systemu Struktura agentowa systemu Agent ui Agent robot Specyfikacja podsystemu sterowania c robot Automat skończony Zachowania Funkcje przejścia dekompozycja Funkcje przejścia kompozycja i dowód ortogonalności Funkcje przejścia opis działania bloków Specyfikacja wirtualnego efektora e robot Automat skończony Powiązanie specyfikacji z implementacją Relacja między blokami a komponentami Komponenty służące do komunikacji agentów a robot i a ui Komponent służący do komunikacji podsystemów c robot i e robot Komponenty realizujące główne algorytmy podsystemu c robot

8 6.2. Przykładowa implementacja komponentu podsystemu c robot Przykładowa implementacja fragmentu podsystemu c ui Sekwencja uruchomień bloków Inicjalizacja sterownika Synchronizacja napędów Synchronizacja pojedynczego napędu Regulacja pozycji Podsumowanie Realizacja wyznaczonych celów Nowe aspekty podejścia do modelowania podsystemu sterowania Krytyczna ocenia rozwiązania Perspektywy kontynuacji prac Bibliografia 47 Spis rysunków 51 Spis tablic 53 2

9 Rozdział 1 Wstęp 1.1. Motywacja Współczesna robotyka ma coraz szersze zastosowania nie tylko w przemyśle, ale również w ratownictwie [5] czy branży medycznej [2]. Rozwój technologii umożliwia konstruowanie systemów autonomicznych, będących w stanie działać w dynamicznie zmiennym środowisku lub we współpracy z człowiekiem [23]. Oprogramowanie takich urządzeń często przybiera formę skomplikowanych i zaawansowanych systemów informatycznych [7]. Aby efektywnie projektować, wytwarzać i dokumentować sterowniki robotów konieczna jest ich specyfikacja bazująca na pewnej ogólnie przyjętej metodyce i standardzie opisu. Owa metodyka jest jednak tylko pewnym narzędziem, które nie stanowi jednoznacznego przepisu na opis dowolnego sterownika, a w szczególności wszystkich aspektów jego działania. Duża różnorodność systemów robotycznych oraz fakt dynamicznego rozwoju ich możliwości i sposobów wykorzystania sprawiają, że zadanie specyfikacji staje się dużym wyzwaniem dla projektantów i analityków [42, 7, 41] Cel pracy Celem pracy jest specyfikacja części sterownika robota manipulacyjnego IRp-6, z uwzględnieniem mechanizmów inicjalizacji, synchronizacji napędów oraz awaryjnego zatrzymania. Jako metodę opisu przyjęto teorię agenta upostaciowionego [39], zaś jako formę standard SysML [11]. Szczególną wagę przyłożono do wyodrębnienia stanów systemu, w taki sposób by odpowiadały one jego przypadkom użycia. Konsekwencją takiego założenia, w obliczu chęci uniknięcia redundancji opisu, była konieczność odpowiedniej dekompozycji funkcji przejść opisujących kolejne zachowania. Ponadto w pracy podjęto się opisu kolejnych funkcji przejść, wykorzystując do tego celu szereg różnych diagramów SysML, opisujących takie aspekty ich działania jak przepływ danych czy szczegóły działania algorytmu. Praca prezentuje również sposób interpretacji kolejnych elementów specyfikacji, który umożliwia wskazanie relacji specyfikacji z implementacją. 3

10 W celu łatwej weryfikacji osiągniętych rezultatów pracy, wymieniono kolejne cele w postaci listy. Praca podejmuje zadania podzielone na 4 cele, którymi są: cel 1 Specyfikacja mechanizmów: cel 1.1 inicjalizacji sterownika, cel 1.2 synchronizacji napędów robota, cel 1.3 awaryjnego zatrzymania pracy sterownika i napędów robota. cel 2 Unikanie redundancji opisu w rozumieniu pewnych powtarzających się elementów specyfikacji. cel 3 Uwzględnienie takich aspektów działania systemu jak: cel 3.1 przepływ danych pomiędzy częściami składowymi obiektów specyfikacji, cel 3.2 szczegóły działania wybranych algorytmów związanych z procesem synchronizacji napędów robota. cel 4 Tworzenie specyfikacji w taki sposób, by można było wskazać jednoznaczną zależność między głównymi elementami specyfikacji i implementacji Układ pracy Rozdział 2 opisuje metodykę specyfikacji opartą o teorię agenta upostaciowionego. Rozdział 3 stanowi przegląd literatury pod kątem istniejących specyfikacji robota IRp-6. Kolejny rozdział 4 prezentuje założenia pracy, przypadki użycia systemu oraz ograniczenia sprzętowe. Specyfikacja sterownika została opisana w rozdziale 5. Rozdział 6 traktuje o powiązaniu specyfikacji z implementacją sterownika. Ostatni rozdział 7 stanowi podsumowanie pracy. 4

11 Rozdział 2 Metodyka specyfikacji i formy jej opisu W tym rozdziale zostanie omówiona wykorzystana w pracy metodyka specyfikacji systemu robotycznego. Sekcja 2.1 traktuje o teorii agenta upostaciowionego, zaś sekcja 2.2 o graficznym języku opisu systemów SysML Agent upostaciowiony Jedną z metodyk specyfikacji sterowników robotów jest teoria agenta upostaciowionego, zakładająca podział systemu na grupę komunikujących się ze sobą agentów [36]. Podejście to było wielokrotnie wykorzystywane m.in. do specyfikowania sterowników robotów mobilnych [27, 26, 8] oraz manipulacyjnych [35, 37, 32] Metamodel agenta upostaciowionego Rysunek 2.1 prezentuje metamodel agenta upostaciowionego opisujący części składowe agenta. Agent upostaciowiony posiada dokładnie jeden podsystem sterowania i może posiadać szereg wirtualnych receptorów i efektorów oraz rzeczywistych receptorów i efektorów. W szczególności może istnieć agent składający się jedynie z podsystemu sterowania. Sam system może składać się z wielu agentów. system 1..* agent 0..* wirtualny efektor 1 podsystem sterowania 0..* wirtualny receptor 0..* rzeczywisty rzeczywisty 0..* efektor receptor Rysunek 2.1: Metamodel agenta upostaciowionego 5

12 Rysunek 2.2 prezentuje rodzaje podsystemów i ich liczebność. Każdy z wymienionych obiektów oznaczonych kolorem szarym jest typem podsystemu, który oznaczono kolorem białym. Podsystem sterowania może być skojarzony z wieloma wirtualnymi tworami, zaś w obrębie danego agenta wirtualne podsystemu skojarzone są tylko z jednym podsystemem sterowania. Każdy z wirtualnych tworów skojarzony jest z przynajmniej jednym obiektem rzeczywistym. Agent nie może posiadać rzeczywistego efektora lub receptora, który nie byłby skojarzony odpowiednio z pewnym wirtualnym efektorem lub receptorem. podsystem podsystem sterowania 1 1 rzeczywisty efektor 1..* 1..* wirtualny 0..* 0..* wirtualny 1..* 1..* efektor receptor rzeczywisty receptor Rysunek 2.2: Rodzaje podsystemów i ich liczebność Podsystem sterowania agenta odpowiedzialny jest za zarządzanie pracą agenta, komunikację z innymi agentami jak również odbieranie danych od wirtualnych podsystemów oraz wysyłanie do nich poleceń. Rzeczywiste efektory utożsamiane są z fizycznymi urządzeniami oddziałującymi na środowisko, zaś rzeczywiste receptory z sensorami zbierającymi informacje o środowisku pracy systemu [39]. Wirtualne podsystemy odpowiedzialne są za pośredniczenie w wymianie danych między podsystemem sterowania a rzeczywistymi efektorami i receptorami, przetwarzanie danych czy realizację algorytmów sterowania Struktura wewnętrzna agenta podsystem sterowania wirtualny efektor wirtualny receptor rzeczywisty efektor rzeczywisty receptor Rysunek 2.3: Wewnętrzna struktura agenta upostaciowionego Na rysunku 2.3 zaprezentowano model definiujący nazewnictwo podsystemów, ich pamięci wewnętrznych oraz portów komunikacyjnych agenta a j. Symbolem c j oznaczono podsystem sterowania, zaś c c j jego pamięć wewnętrzną. Podsystem ten może wysyłać dane do agenta a j poprzez port T y c j,j oraz odbierać poprzez port T x c j,j. Podsystem sterowania komunikuje się z N wirtualnymi efektorami e j,n, gdzie n {1,...,N}. Do wysyłania danych do e j,n służy port e yc j,n zaś do odbierania port e xc j,n. Wirtualny efektor e j,n posiada pamięć wewnętrzną e e j,n i komunikuje 6

13 się z M rzeczywistymi efektorami E j,m, gdzie m {1,...,M}. Dane wysyłane są przez port E y e j,n,m zaś odbierane przez port E x e j,n,m. Rzeczywisty efektor odbiera dane poprzez port x E j,m oraz wysyła przez port y E j,m. Analogiczna komunikacja realizowana jest pomiędzy podsystemem sterowania, wirtualnym receptorem i rzeczywistym receptorem. Podsystem sterowania komunikuje się z K wirtualnymi receptorami r j,k, gdzie k {1,...,K}. Do wysyłania danych do r j,k służy port r yc j,k zaś do odbierania port r xc j,k. Wirtualny receptor r j,k posiada pamięć wewnętrzną r r j,k i komunikuje się z L rzeczywistymi receptorami R j,l, gdzie l {1,...,L}. Dane wysyłane są przez port R y r j,k,l zaś odbierane przez port R x r j,k,l. Rzeczywisty receptor odbiera dane poprzez port xr j,l oraz wysyła przez port y R j,l Hierarchia elementów definiujących działanie agenta Rysunek 2.4 prezentuje hierarchię elementów składowych agenta służących do opisu jego działania. System może składać się z wielu agentów, które mogą posiadać wiele podsystemów. Każdy podsystem posiada porty komunikacyjne, pamięć wewnętrzną oraz automat skończony stanowiący model działania podsystemu. Automat składa się ze stanów. Każdy stan posiada warunek początkowy, po którego spełnieniu automat przechodzi do danego stanu oraz zachowanie tj. opis działania podsystemu będącego w danym stanie. Zachowanie opisane jest poprzez funkcję przejścia, warunek końcowy oraz warunek błędu. Dane zachowanie może być częścią więcej niż jednego stanu, zaś stan może posiadać tylko jedno zachowanie. Funkcja przejścia może być zdekomponowana na szereg częściowych funkcji przejścia, które mogą rekurencyjnie zagnieżdżać w sobie kolejne częściowe funkcje przejścia. system 1..* agent port komunikacyjny 1..* 1..* podsystem pamięć wewnętrzna 1 1 automat skończony warunek początkowy warunek końcowy warunek błędu * stan 1 zachowanie 1 funkcja przejścia 1..* częściowa funkcja przejścia * Rysunek 2.4: Elementy opisu agenta upostaciowionego Automat skończony opisujący zachowanie Działanie zachowania może być opisane w postaci odrębnego automatu skończonego [9]. Na diagramie 2.5 przedstawiono automat skończony opisujący pewne zachowanie. Symbolami S 1,...,S 4 oznaczono kolejne stany automatu, zaś symbolami f ɛ i f τ odpowiednio warunek błędu i warunek końcowy zachowania. Pojedyncze wykonanie zachowania rozpoczyna się od obliczenia funkcji przejścia (stan S 1 ), której wynikiem działania są pewne dane wyjściowe. W następnym kroku automat przechodzi do stanu S 2, w którym następuje wysłanie danych do skojarzonych 7

14 podsystemów i/lub agentów. W stanie S 3 następuje zwiększenie licznika czasowego oraz w stanie S 4 odebranie danych od skojarzonych podsystemów i/lub agentów. Ze stanu S 4 można wrócić do stanu S 1 jeśli nie jest spełniony warunek błędu oraz warunek końcowy f ɛ f τ, zaś w przeciwnym przypadku zakończyć działanie zachowania. obliczenie wysłanie danych funkcji przejścia odebranie danych zwiększenie licznika czasu Rysunek 2.5: Automat skończony opisujący zachowanie Funkcja przejścia i jej dekompozycja Funkcja przejścia skojarzona z zachowaniem może mieć formę pojedynczej, niepodzielnej całości bądź stanowić kompozycję wielu częściowych funkcji przejścia. Dekompozycji dokonuje się by zwiększyć czytelność opisu, bądź uniknąć jego redundancji w przypadku, gdy funkcje przejścia posiadają pewne części wspólne. Rozróżnia się dwa typy dekompozycji: ze względu na produkowane dane wyjściowe oraz ze względu na cel prowadzonych obliczeń. W tej sekcji zostały opisane obydwa podejścia. Dla ustalenia uwagi zasada została opisana na przykładzie podsystemu sterowania c j pewnego agenta a j. Dla innych podsystemów sposób dekompozycji jest analogiczny. Na wstępnie zostaną wprowadzone pewne wspólne oznaczenia. Symbolem x c i j oznaczono argument funkcji, którego pełną zawartość zobrazowano w (2.1). Indeksem i oznaczono numer iteracji obliczeń funkcji przejścia podsystemu. Argument składa się z zawartości: pamięci wewnętrznej c i j podsystemu, buforów wejściowych przechowujących dane odebrane od wirtualnych efektorów e xc i j,1,..., e xc i j,n, buforów wejściowych przechowujących dane odebrane od wirtualnych receptorów r xc i j,1,..., r xc i j,m oraz buforów wejściowych komunikacji międzyagentowej T x c i j,j,..., T 1 x c i j,j J xc i j = c i j, e xc i j,1,..., e xc i j,n, r xc i j,1,..., r xc i j,m, T x c i j,j 1,..., T x c i j,j (2.1) J Skomponowana funkcja przejścia produkuje wyjście będące kompozycją wyjść kolejnych częściowych funkcji. Ma ono postać (2.2). yc i+1 j = c i+1 j, e yc i+1 j,1,..., e yc i+1 j,n, r yc i j,1,..., r yc i+1 j,m, T y c i+1 j,j,..., T 1 y c i+1 j,j J Dodatkowo symbolem F oznacza się zbiór częściowych funkcji przejścia, zaś symbolem f comp skomponowaną funkcję przejścia. (2.2) Dekompozycja ze względu na produkowane dane wyjściowe Zasada dekompozycji funkcji ze względu na produkowane wyjścia została przedstawiona w pracy [38]. Funkcja przejścia f comp tworzona jest jako kompozycja czterech częściowych funkcji przejść (2.3). Każda z nich produkuje dane do innego bufora wyjściowego lub do pamięci wewnętrznej. 8

15 F = c j c i+1 j = f ccj ( x c i j ) e j y c i+1 j = f cej ( x c i j ) r j y c i+1 j = f crj ( x c i j ) T j y c i+1 j = f ctj ( x c i j ) (2.3) Wszystkie częściowe funkcje przejścia posiadają ten sam argument x c i j (2.1). Funkcja f comp produkuje wyjście y c i+1 j obliczane wedle wzoru (2.4). Zawartość produkowanego wyjścia prezentuje wzór (2.2). yc i+1 j = f comp ( x c i j) (2.4) Wynikowa wartość y c i+1 j stanowi zawartość wszystkich buforów wyjściowych podsystemu oraz jego pamięci wewnętrznej. Jej zawartość prezentuje wzór (2.2). Prezentowane podejście do dekompozycji funkcji przejścia znalazło zastosowanie między innymi w pracach [28, 31] traktujących o specyfikacji robota mobilnego i manipulacyjnego Dekompozycja ze względu na cel prowadzonych obliczeń W ramach prac badawczych prowadzonych przez autora pracy oraz promotora w trakcie realizacji pracy magisterskiej powstała propozycja nowego sposobu dekompozycji funkcji przejścia. Zaproponowana metoda opisuje dekompozycję funkcji przejścia ze względu na cel prowadzonych obliczeń. Symbolem F (2.5) nazwano zbiór wszystkich częściowych funkcji przejścia należących do zachowań podsystemu c j agenta a j. Zbiór ten liczy N f częściowych funkcji przejścia. Oznaczone są one symbolami f 1 c,...,f N f c. F = yc i+1 1 j... yc i+1 j = f 1 c ( x c i j ) N f = f N f c ( x c i j ) Funkcje posiadają argument x c i j, którego pełną zawartość zobrazowano w (2.1). Częściowe funkcje przejścia produkują wyjścia oznaczone symbolami y c i+1 1 j,...,y c i+1 N f j. Każda częściowa funkcja może produkować dane jednocześnie do wszystkich buforów wyjściowych podsystemu. Zawartość produkowanego wyjścia prezentuje wzór (2.6). yc i+1 j = c i+1 j, e yc i+1 j,1,..., e yc i+1 j,n, r yc i j,1,..., r yc i+1 j,m, T y c i+1 j,j,..., T 1 y c i+1 j,j J Aby dokonać kompozycji funkcji przejścia należy wybrać pewien podzbiór F zbioru F i potraktować zawarte w nim częściowe funkcje jako jedną całość. Warunkiem prawidłowej kompozycji funkcji przejścia jest to, by w ramach jednej skomponowanej funkcji przejścia nie istniały dwie częściowe funkcje przejścia, które produkowałyby dane wyjściowe do tych samych części buforów wyjściowych podsystemu. Warunek ten został formalnie zapisany w postaci wzoru (2.7). Dla dowolnej pary funkcji f c, f c ze zbioru F, produkowane przez nie wyjścia dla argumentu x c i j muszą posiadać pustą część wspólną. ( f c, f c F ) ( ) f c ( x c i j) f c ( x c i j) = Skomponowana funkcja przejścia produkuje wyjście będące kompozycją wyjść kolejnych częściowych funkcji, które ma postać (2.2). (2.5) (2.6) (2.7) 9

16 2.2. Język modelowania systemów SysML Jedną z metod opisu specyfikacji oraz implementacji systemów jest graficzny język modelowania SysML (ang. System Modeling Language) [11]. Powstał on jako modyfikacja i rozbudowa standardu UML (ang. Unified Modeling Language) [10]. W niniejszej pracy bazowano na standardzie SysML w wersji 1.1. Opisuje on 9 typów diagramów [25] podzielonych na 3 klasy: diagramy zachowań (ang. Behaviour Diagram), diagramy wymagań systemowych (ang. Requirements Diagram) oraz diagramy struktury (ang. Structure Diagram). W pracy wykorzystano diagram przypadków użycia (ang. Use Case Diagram), diagram maszyny stanowej (ang. State Machine Diagram), diagram bloków wewnętrznych (ang. Internal Block Diagram), rozszerzony diagram czynności (ang. Activity Diagram) oraz diagram sekwencji (ang. Sequence Diagram). 10

17 Rozdział 3 Przegląd istniejących specyfikacji sterownika robota IRp-6 Specyfikacja agentowa sterownika robota manipulacyjnego IRp-6 była wielokrotnie przedmiotem badań Zespołu Programowania Robotów i Systemów Rozpoznających IAiIS i została szeroko omówiona w szeregu prac. Dla celów prac badawczych prowadzonych w ramach niniejszej pracy magisterskiej dokonano przeglądu istniejących specyfikacji. Wstępny przegląd miał na celu zbadanie obecnego stanu wiedzy dotyczącej specyfikacji takich aspektów sterownika robota IRp-6 jak: a1 sposób inicjalizacji sterownika, a2 zasada synchronizacji napędów robota, a3 obsługa awaryjnego zatrzymania pracy sterownika i robota, a4 opis działania sterowników sprzętowych napędów robota. Podczas przeglądu nie znaleziono prac traktujących o specyfikacji agentowej wymienionych aspektów działania sterownika. Poniżej zostaną pokrótce omówione przeanalizowane prace, ze wskazaniem omawianych w nich elementów specyfikacji. Autorzy publikacji [34] zaproponowali wyodrębnienie czterech częściowych funkcji przejścia. Pierwsza została zaprojektowana tak, by była aktywna przez cały czas działania systemu. Odpowiada ona obliczaniu stanu robota między innymi rozwiązywaniu prostego zadania kinematyki. Pozostałe trzy funkcje odpowiadają za realizację ruchu robota w przestrzeni konfiguracyjnej, operacyjnej, a także w sposób pozycyjno-prędkościowy. Z trzech wymienionych częściowych funkcji w danej chwili może być aktywna tylko jedna i działać równolegle z częściowa funkcją obliczającą stan robota. Praca prezentuje też komponentową strukturę systemu oraz metodę przełączania zachowań. Praca [33] traktuje o specyfikacji zachowań wirtualnego efektora, takich jak sterowanie pozycyjne oraz impedancyjne w przestrzeni konfiguracyjnej i operacyjnej. Opisano również propozycję komponentowej realizacji opisanych zachowań. Podczas przeglądu literatury wyodrębniono publikacje, w których specyfikowano wybrane aspekty sterownika robota IRp-6 na potrzeby opisu konkretnych aplikacji. W jednej z nich [35] określono ogólną strukturę systemu i skoncentrowano się na specyfikacji wirtualnego receptora. Celem działania systemu było rozpoznawanie kształtów i rysowanie ich na kartce papieru. Publikacja [31] koncentruje się na opisie struktury sterownika systemu wielorobotowego realizującego zadanie sprzężenia haptycznego. Praca bazuje na teorii agenta upostaciowionego w wersji nie zakładającej istnienia wirtualnego efektora. Stanowi jednak przykład wykorzystania idei dekompozycji funkcji przejścia ze względu na produkowane dane wyjściowe. Praca [20] definiuje ogólną strukturę sterownika robota, specyfikuje system percepcji wirtualny efektor, którego celem jest rozpoznawanie i lokalizacja obiektów oraz opisuje podsystem sterowania jako koordynatora 11

18 wykonywania zadania chwytania obiektów. Analizowano również pracę [22] opisującą działanie wirtualnego receptora rozpoznającego i lokalizującego obiekty oraz działanie podsystemu sterowania wykonującego zadanie poruszania manipulatorem w kierunku ustalonych obiektów. Praca nie definiuje wirtualnego efektora jako oddzielnego bytu. Wyodrębniono również artykuły traktujące o rozwoju i sposobach wykorzystania specyfikacji agentowej, gdzie specyfikacja sterownika robota IRp-6 odgrywa rolę ilustracji omawianej metodyki. Praca [21] prezentuje metodę specyfikacji zadań robota opisanych w abstrakcyjny z punktu widzenia sterownika, ale zrozumiały dla człowieka sposób. Autorzy przedstawili proponowaną metodykę na przykładzie działania robota IRp-6 w zadaniu chwytania obiektów. Pozostałe dwie prace [19, 40] wykorzystują robota IRp-6 jako przykład do opisu proponowanych ogólnych, uniwersalnych zasad specyfikowania sterowników. W ramach prac koncepcyjnych nad specyfikacją czterech wymienionych wyżej aspektów (a1,...,a4) działania sterownika analizowano różne możliwości definiowania funkcjonalności podsystemu sterowania oraz wirtualnego efektora. Z tego powodu w dalszej części opracowania uzupełniono przegląd istniejących rozwiązań o opis: roli podsystemu sterowania c j, zawartości buforów komunikacyjnych pomiędzy: podsystemem sterowania a wirtualnym efektorem c j e j wirtualnym efektorem a podsystemem sterowania e j c j wirtualnym efektorem a rzeczywistym efektorem e j E j rzeczywistym efektorem a wirtualnym efektorem E j e j źródło [20] [33] [34] [35] [21] [19] rola c j zarządzanie zadaniem c j e j zadana zadany zadana zadana zadana zadana pozycja, przyrost pozycja pozycja pozycja pozycja polecenie pozycji ruchu e j c j aktualna pozycja status zadania, aktualna pozycja e j E j PWM prąd E j e j odczyty enkodera pozycja wału silnika status zadania, aktualna pozycja pozycja wału silnika pozycja wału silnika aktualna pozycja bd. bd. Tabela 3.1: Przegląd istniejących specyfikacji aktualna pozycja prąd odczyty enkodera aktualna pozycja pozycja wału silnika pozycja wału silnika Przegląd został jednak ograniczony do opisów specyfikacji spełniających ograniczenia niniejszej pracy, które zostały opisane w rozdziale 4. Konsekwentnie: przeanalizowano opisy bazujące na teorii agenta upostaciowionego w ujęciu zakładającym istnienie wirtualnego efektora pośredniczącego w komunikacji między podsystemem sterowania a rzeczywistym efektorem, koncentrowano się na specyfikacji podsystemu sterowania, wirtualnych oraz rzeczywistych efektorów, z pominięciem wirtualnych i rzeczywistych receptorów, 12

19 uwzględniano części specyfikacji opisującej ruch pozycyjny robota. Nie zostały brane pod uwagę inne warianty ruchu jak na przykład pozycyjno-siłowy, prędkościowy czy impedancyjny. Wyniki przeglądu prezentuje tabela 3.1. Kolumny tabeli zawierają opis rozwiązań uwzględnionych w wymienionych publikacjach, zaś rzędy opisują specyfikację wedle przedstawionych kryteriów. Cechą wspólną wszystkich opisów jest wyodrębnienie podsystemu sterowania c j jako podsystemu zarządzającego wykonywaniem zadania. Komunikuje się on z wirtualnym efektorem przesyłając mu zadaną pozycję, polecenie ruchu czy przyrost pozycji. Otrzymuje zaś od wirtualnego efektora informację o aktualnej pozycji czy statusie wykonywania zadania. Rolą wirtualnego efektora jest między innymi generowanie trajektorii oraz obliczanie prostego i odwrotnego zadania kinematyki. Pewne rozbieżności w analizowanych opisach można znaleźć na poziomie interfejsu pomiędzy wirtualnym a rzeczywistym efektorem. W jednej z prac [20] wirtualny efektor przesyła do rzeczywistego efektora sygnał PWM, w dwóch pracach [33, 21] wielkość sterowania prądowego, zaś w pozostałych pracach [34, 19] pozycję wału silnika. W dwóch pracach [20, 21] rzeczywisty efektor przesyła do wirtualnego efektora odczyty enkodera, zaś w trzech pracach [33, 34, 19] przesyłana jest pozycja wału silnika. 13

20 14

21 Rozdział 4 Założenia W tym rozdziale zostały omówione założenia pracy. Dotyczą ona ograniczeń sprzętowych (sekcja 4.1), przyjętego zakresu interakcji operatora z robotem (sekcja 4.2) oraz założonych ograniczeń funkcjonalności systemu (sekcja 4.3). Opisano również założenia dotyczące sposobu tworzenia specyfikacji tj. form opisu (sekcja 4.4), metodyki badania działania sterownika (sekcja 4.5) oraz analizy powiązania specyfikacji z implementacją (sekcja 4.6) Ograniczenia sprzętowe robot Praca podejmuje temat specyfikacji robota IRp-6. Jest to przemysłowy robot manipulacyjny o sześciu stopniach swobody, wyposażony w chwytak dwupalczasty. Efektorami robota są silniki prądu stałego. Napędy wyposażone są w inkrementalne enkodery służące do pomiaru względnych położeń wałów silników. Z uwagi na zastosowane rozwiązania konstrukcyjne, napędy robota muszą być synchronizowane przy każdym uruchomieniu sterowników sprzętowych robota. Synchronizacja odbywa się z wykorzystaniem enkoderów oraz czujników pola synchronizacji (opis w sekcji ). Robot wyposażony jest też w wyłączniki krańcowe. Napędy wraz z ich proprioceptorami obsługiwane są przez dedykowane sterowniki sprzętowe [29]. Robot wyposażony jest również w szereg sensorów, do których można zaliczyć nadgarstkowy czujnik siły, optyczne czujniki siły zamontowane na chwytaku [1] czy kamerę. Praca ogranicza się do opisu części sterownika obsługującej działanie sześciu kolejnych napędów osi z pominięciem napędu chwytaka. W ramach kolejnych napędów uwzględniono sterowanie silnikami, obsługę enkoderów, czujników pola synchronizacji i wyłączników krańcowych. Praca nie obejmuje opisu działania czujników siły oraz kamery Ograniczenia sprzętowe interfejs użytkownika Użytkownik robota jego operator wchodzi w interakcję z robotem poprzez jego sprzętowy i programowy interfejs. Interfejs sprzętowy sterowany jest bezpośrednio przez użytkownika, zaś interfejs programowy może pośredniczyć w komunikacji między pewną częścią interfejsu sprzętowego a sterownikiem robota. Do sprzętowego interfejsu zalicza się: przycisk włączający zasilanie napędów i sterowników robota, przycisk włączający zasilane układów logicznych sterowników robota, przyciski służące do realizacji bezpośredniej interakcji użytkownika ze sterownikami sprzętowymi oraz przycisk awaryjnego zatrzymania robota. Do interfejsu sprzętowego zalicza się również monitor, klawiatura i mysz. Są to peryferia komputera PC na którym uruchomiony jest programowy interfejs użytkownika. Praca ogranicza się do opisu części sterownika wymagającej wykorzystania takich części interfejsu sprzętowego jak: przycisk awaryjnego zatrzymania, mysz, klawiatura i monitor. 15

22 4.3. Ograniczenia funkcjonalności Specyfikacja sterownika robota, której tematem jest niniejsza praca magisterska, ogranicza się do pewnych wybranych funkcji robota: Uwzględniono tylko tryb pozycyjny pracy robota. Założono dwa warianty ruchu: w przestrzeni konfiguracyjnej, gdzie zadawaną pozycją jest pozycja kolejnych stawów manipulatora, oraz w przestrzeni operacyjnej, gdzie zadawana jest kartezjańska pozycja punktu znajdującego się na końcu łańcucha kinematycznego. Nie wzięto pod uwagę innych trybów takich jak: pozycyjno-siłowy, prędkościowy czy impedancyjny. W opracowaniu uwzględniono mechanizmy inicjalizacji oraz awaryjnego zatrzymania systemu. Jednak nie podjęto się opisu mechanizmów systemu operacyjnego biorących udział w samym uruchamianiu oraz wyłączaniu oprogramowania rozumianego jako zbiór procesów i wątków systemu operacyjnego. sterownik programowy PU(0): uruchomienie sterownika <<require>> <<require>> użytkownik <<require>> PU1: inicjalizacja <<require>> PU2: synchronizacja <<require>> PU3: ruch w przestrzeni konfiguracyjnej PU4: ruch w przestrzeni operacyjnej PU5: awaryjne zatrzymanie PU(6): zakończenie pracy sterownika Rysunek 4.1: Przypadki użycia sterownika robota Ograniczenie dotyczące możliwych interakcji użytkownika z systemem przedstawiono na diagramie 4.1 prezentującym przypadki użycia sterownika robota. Użytkownik ma do dyspozycji siedem przypadków użycia systemu. Symbolami PU(0) i PU(6) oznaczono przypadki odpowiednio zaczynające i kończące pracę systemu. Związane są one bezpośrednio z obsługą mechanizmów systemu operacyjnego służących do włączania i wyłączania oprogramowania sterownika. Zgodnie z przyjętymi założeniami, wymienione przypadki nie będą opisane w dalszej części pracy. Pierwszym przypadkiem użycia, który może być wykonany po uruchomieniu sterownika, jest PU1: inicjalizacja. Odpowiada on za konfigurację wszystkich programów wchodzących w skład sterownika. Dotyczy to między innymi wczytania parametrów konfiguracyjnych związanych z modelem robota i adresami portów komunikacyjnych. Po zakończeniu inicjalizacji, istnieje możliwość synchronizacji napędów robota PU2. Zadanie to wykonywane jest jednokrotnie i realizuje synchronizację każdego napędu robota sekwencyjnie po zakończeniu synchronizacji napędu n-tego, następuje synchronizacja napędu n + 1-wszego. Jeśli napędy robota zostały prawidłowo zsynchronizowane, użytkownik może uruchamiać zadania PU3 i PU4 związane z wykonaniem ruchu robota odpowiednio w przestrzeni konfiguracyjnej i operacyjnej. W każdym 16

23 momencie działania systemu, niezależnie od stanu wykonania innych przypadków użycia, możliwe jest wykonanie przypadku użycia PU5: awaryjne zatrzymanie. Uruchamia on programowe mechanizmy zatrzymania pracy sterownika oraz wyłączenia zasilania napędów robota Metodyka specyfikacji i forma jej opisu Jako metodę specyfikacji systemu przyjęto model agenta upostaciowionego, w formie uwzględniającej istnienie wirtualnych tworów pośredniczących między rzeczywistymi efektorami oraz podsystemem sterowania. Specyfikacja została opisana poprzez język SysML Metodyka badania działania sterownika Sterownik robota, którego specyfikacja jest tematem niniejszej pracy, jest zaimplementowanym i działającym systemem. Część odpowiadająca sterownikowi programowemu oraz interfejsowi użytkownika ma formę komponentową działającą w ramach struktur ROS [24] i OROCOS [3, 4]. Kod źródłowy tej części jest dostępny w repozytoriach [18, 13]. Specyfikacja bazuje na analizie kodów źródłowych. Sterownik sprzętowy został analizowany na zasadzie czarnej skrzynki. Obserwowano stan wejść i wyjść sterownika podczas pracy systemu. Wspierano się również dokumentacją zawartą w pracy magisterskiej [30] Powiązanie specyfikacji z implementacją systemu Założono, że cel 4 pracy będzie spełniony poprzez wskazanie zależności pomiędzy komponentami sterownika programowego a pewnymi obiektami składowymi specyfikacji. Dodatkowo założono, że w owej analizie zależności nie będą brały udziału komponenty uznane za pomocnicze tzn. takie, które nie realizują konkretnego algorytmu, a jedynie pełnią rolę konwerterów danych, elementów grupujących dane w obrębie pewnych struktur czy realizujące zadanie komunikacji między pewnymi elementami systemu. W ramach opisywanej struktury, z uwagi na czytelność specyfikacji, nie uwzględniono faktu przesyłania danych o wybranych informacjach diagnostycznych. Dodatkowo w specyfikacji nie uwzględniono modelowania obsługi sytuacji wyjątkowych i błędów, rozumianych nie w kontekście algorytmów sterowania, a programowych mechanizmów związanych z implementacją systemu. Z tego powodu specyfikacja nie opisuje warunków błędów przypisanych do zachowań. 17

24 18

25 Rozdział 5 Specyfikacja systemu 5.1. Struktura agentowa systemu Podział systemu na agenty jest aspektem specyfikacji, który należy omówić w pierwszej kolejności, gdyż agent jest najbardziej ogólnym, po samym systemie, elementem w hierarchii elementów składowych systemu agentowego. Niemniej same przyczyny prezentowanego podziału zostaną omówione w kolejnych sekcjach tego rozdziału, gdyż wynikły one podczas próby specyfikacji części systemu bezpośrednio związanej z oprogramowaniem sterującym robota. System podzielono na dwa agenty a ui oraz a robot, których relację obrazuje rysunek 5.1. Agent a ui obejmuje funkcjonalność interfejsu użytkownika i jest odpowiedzialny za wysyłanie poleceń ruchu dla robota. Zaproponowano również by pełnił on funkcję nadzorcy nad wykonywanymi poleceniami, tak by był odpowiednikiem podsystemu sterowania agenta obsługującego robota, w rozumieniu w jakim opisano to w przeglądzie istniejących specyfikacji (rozdział 3). Drugi agent a robot obejmuje programowy i sprzętowy sterownik robota jak również jego fizyczną realizację. Rysunek 5.1: Struktura agentów systemu Port Opis Typ a ui a robot d_s rozpoczęcie synchronizacji bool d_pc / d_po parametry ruchu w przestrzeni konfiguracyjnej / operacyjnej struktura s_c / s_o rozpoczęcie ruchu w przestrzeni konfiguracyjnej / operacyjnej bool es_c_ui polecenie awaryjnego zatrzymania bool a robot a ui c_d / o_d koniec ruchu w przestrzeni konfiguracyjnej / operacyjnej bool c_p / o_p aktualna pozycja w przestrzeni konfiguracyjnej / operacyjnej struktura r_s informacja o stanie synchronizacji robota bool s_e informacja o zakończonej synchronizacji bool es_i informacja o awaryjnym zatrzymaniu bool Tabela 5.1: Zawartość buforów komunikacyjnych komunikacji międzyagentowej 19

26 Tabela 5.1 opisuje zawartość buforów komunikacyjnych służących do komunikacji agentów a ui oraz a robot. Użytkownik poprzez interfejs użytkownika może wydać polecenie rozpoczęcia synchronizacji oraz ruchu w przestrzeni konfiguracyjnej lub operacyjnej jak również polecenie awaryjnego zatrzymania sterownika. Komunikacja w stronę przeciwną zakłada przesyłanie informacji o zakończeniu zadanego ruchu, aktualnej pozycji robota, stanie synchronizacji, informacji o zakończonej synchronizacji oraz awaryjnym zatrzymaniu. Ostatnia kolumna tabeli zawiera informacje o typie przesyłanych danych. Może być to wartość logiczna (bool) lub złożona struktura danych Agent ui Struktura agenta a ui została zaprezentowana na diagramie 5.2. Agent posiada podsystem sterowania c ui oraz skojarzone z nim dwa wirtualne receptory r ui,1, r ui,2 oraz wirtualny efektor e ui,1. Do wirtualnych receptorów przyporządkowane są odpowiednio rzeczywiste receptory odpowiadające myszy (R ui,1 ) oraz klawiaturze (R ui,2 ). Z wirtualnym efektorem e ui,1 skojarzony jest rzeczywisty efektor E ui,1, będący monitorem komputera PC. Poszczególne podsystemy przesyłają między sobą dane poprzez porty komunikacyjne. Kierunki przepływu danych oraz nazwy poszczególnych portów obrazuje diagram. Agent odpowiedzialny jest za odbieranie poleceń od użytkownika, wysyłanie odpowiednio przygotowanych zadań i poleceń do sterownika robota, odbieranie informacji od sterownika robota o jego stanie, przekazywanie użytkownikowi wybranych informacji oraz zarządzanie wykonywanymi przez robota zadaniami. podsystem sterowania wirtualny efektor wirtualny receptor wirtualny receptor rzeczywisty efektor - monitor rzeczywisty receptor - mysz rzeczywisty receptor - klawiatura Rysunek 5.2: Struktura agenta a ui Agent robot Agent a robot (rys. 5.3) utożsamiany jest z programowym i sprzętowym sterownikiem robota oraz fizycznymi urządzeniami, z których zbudowany jest robot. Składa się on z podsystemu sterowania c robot, sześciu wirtualnych efektorów e robot,n, dla n {1,...,6} oraz sześciu rzeczywistych efektorów E robot,m, dla m {1,...,6}. Podsystem sterowania utożsamiany jest z całym programowy sterownikiem robota, który uruchamiany jest na komputerze PC. Wirtualne efektory pełnią funkcję programu obsługującego sprzętowe sterowniki napędów. Programy te uruchamiane są bezpośrednio w owych sterownikach. Rysunek prezentuje również możliwe kierunki komunikacji oraz nazwy buforów. W odróżnieniu od dotychczasowego podejścia do specyfikacji sterownika robota IRp-6, które zostało szerzej opisane w rozdziale 3, wszystkie algorytmy związane z główną pętlą sterowania 20

27 robota zostały zawarte w podsystemie sterowania. Nie zostały w nim ujęte algorytmy odpowiedzialne za zarządzanie zadaniami robota, które przeniesione zostały do agenta a ui. Podsystem sterowania poszerzył swoją funkcjonalność o tą opisywaną do tej pory w ramach działania wirtualnego efektora. Sam wirtualny efektor zyskał zaś nową, nieuwzględnianą dotychczas funkcję opisującą działanie sterowników sprzętowych. W opisywanym podejściu zaproponowano specyfikowanie oddzielnego wirtualnego efektora do każdego ze sterowników sprzętowych, gdyż robot IRp-6 dysponuje sześcioma sterownikami obsługującymi kolejne sześć napędów. Przyczyną wyodrębnienia wirtualnego efektora jako bytu związanego tylko z oprogramowaniem sterownika sprzętowego, była chęć uwzględnienia faktu fizycznego podziału między komputerem PC, na którym uruchomiony jest sterownik programowy, od układów elektronicznych pełniących rolę sterowników sprzętowych. Ponadto zaproponowany podział umożliwia łatwe uwidocznienie liczebności sterowników sprzętowych. podsystem sterowania wirtualny efektor wirtualny efektor rzeczywisty efektor rzeczywisty efektor Rysunek 5.3: Struktura agenta a robot Port Opis Typ c robot e robot,1,...,6 c_r wartość sterowania prądowego liczba r_p polecenie zerowania pozycji enkodera bool s_s rozpoczęcie sychronizacji bool f_s polecenie zakończenia sychronizacji bool es_c_n polecenie awaryjnego zatrzymania bool e robot,1,...,6 c robot m_p aktualna pozycja wału silnika liczba s_a napęd jest w polu synchronizacji bool m_s napęd został pomyślnie zsynchronizowany bool i_s wszystkie napędy są zsynchronizowane bool es_c_ve polecenie awaryjnego zatrzymania bool Tabela 5.2: Zawartość buforów komunikacyjnych między podsystemami c robot i e robot Tabela 5.2 prezentuje zawartość buforów komunikacyjnych służących do wymiany informacji między podsystemami agenta. Podstawowymi informacjami przekazywanymi między podsystemami jest wartość sterowania prądowego oraz aktualna pozycja wału silnika. Ten podstawowy interfejs jest zgodny z zaproponowanym w pracy [33] opisanej w przeglądzie rozwiązań (rozdział 3). Różnicą jest jednak to, że w proponowanym rozwiązaniu jest to interfejs pomiędzy 21

28 podsystemem sterowania a wirtualnym efektorem, zaś we wspomnianej pracy [33] był to interfejs pomiędzy wirtualnym a rzeczywistym efektorem. Zaproponowany podstawowy interfejs został wzbogacony o porty służące do wymiany informacji potrzebnych do realizacji synchronizacji robota oraz obsługi awaryjnego zatrzymania. Ostatnia kolumna tabeli zawiera informacje o typie przesyłanych danych. Może być to wartość logiczna (bool) lub pojedyncza wartość liczbowa Specyfikacja podsystemu sterowania c robot Automat skończony W podsystemie sterowania zostało wyodrębnionych siedem stanów, które zostały przedstawione na diagramie 5.4. W dalszej części opisu zostaną omówione warunki początkowe kolejnych stanów. Każdy warunek jest zależny od wartości polecenia awaryjnego zatrzymania e_s. Symbolem e_s oznaczono wystąpienie owego sygnału zaś e_s, brak wystawienia. Ze względu na czytelność opisu nie omówiono znaczenia sygnału e_s w poszczególnych warunkach początkowych. W każdym przypadku źródłem sygnału e_s może być interfejs użytkownika (sygnał es_c_ui), blok regulatora zdefiniowany w dalszej części pracy (sygnał es_c_r) oraz wirtualny efektor (sygnał es_c_ve), a zatem e_s = es_c_ui es_c_r es_c_ve. System zaczyna swoją pracę od stanu init, z którego może przejść do stanu idle_synchonized, jeśli został spełniony warunek r_s e_s napędy robota już na etapie inicjalizacji sterownika są zsynchronizowane. Taka sytuacja może wystąpić, podczas gdy robot został zsynchronizowany, informacja o synchronizacji została zapisana w wirtualnym efektorze, po czym sterownik programowy robota (podsystem sterowania) został wyłączony i ponownie włączony. Jeśli został jednak spełniony warunek r_s e_s, podsystem sterowania przechodzi do stanu idle_not_synchonized. W obydwu stanach sterownik robota realizuje bierną pętlę regulacji. Utrzymywana jest stała pozycja wszystkich stawów robota. Ze stanu idle_not_synchonized podsystem sterowania może przejść do stanu synchronization, po spełnieniu warunku d_s e_s. W tym stanie następuje synchronizacja napędów robota. Po zakończeniu synchronizacji sterownik s_c r_s d_pc e_s e_s init idle_not_synchronized synchronization idle_synchronized e_s d_s r_s e_s e_s s_o e_s d_po e_s e_s e_s e_s e_s e_s configurational_move e_s operational_move e_s emergency_stop Rysunek 5.4: Automat skończony podsystemu sterowania e_s = es_c_ui es_c_r es_c_ve przechodzi do stanu idle_synchonized. W tym stanie sterownik oczekuje na polecenia od interfejsu użytkownika. Jeśli użytkownik wyda polecenie ruchu w przestrzeni konfiguracyjnej s_c oraz wyśle niepustą informację o punkcie docelowym d_pc, to sterownik przechodzi do stanu 22

29 configurational_move i realizuje zadanie ruchu. Po zakończeniu zadania sterownik wraca do stanu bezczynności idle_synchronized. Jeśli zaś użytkownik wyśle żądanie ruchu w przestrzeni operacyjnej s_o oraz wyśle niepustą wiadomość o pozycji zadanej d_po, sterownik przechodzi do stanu operational_move i realizuje ruch w przestrzeni operacyjnej. Po zakończeniu zadania sterownik wraca do stanu bezczynności idle_synchronized. Z każdego z opisanych stanów sterownik może pod wpływem warunku e_s przejść do stanu emergency_stop, odpowiedzialnego za obsługę awaryjnego zatrzymania robota Zachowania W tabeli 5.3 zaprezentowano przyporządkowanie zachowań c B robot, do poszczególnych stanów c S robot,. Każde zachowanie przyporządkowane jest do dokładnie jednego stanu o tej samej nazwie. Symbolem c oznaczono podsystem sterowania, robot to nazwa agenta, zaś * odpowiada nazwie stanu lub zachowania. stan c S robot, init idle_not_synchronized synchronization idle_synchronized configurational_move operational_move emergency_stop zachowanie c B robot, init idle_not_synchronized synchronization idle_synchronized configurational operational_move emergency_stop Tabela 5.3: Przyporządkowanie zachowań do kolejnych stanów podsystemu sterowania c robot Warunki końcowe zachowań Tabela 5.4 zawiera warunki końcowe kolejnych zachowań. Powstały one poprzez zapisanie alternatywy negacji warunków początkowych stanów, do których istnieje możliwość przejścia ze stanu analizowanego. Wyjątkiem są stany w których realizowany jest konkretny ruch robota: synchronization, configurational_move, operational_move, których warunki końcowe wynikają z warunku ukończeni zadania odpowiednio s_e, d_c i d_o. Stan emergency_stop nie posiada warunku końcowego, gdyż jak zostało opisane to w dalszej części specyfikacji, odpowiada on procesowi zombie, który może być zakończony poprzez mechanizmy systemu operacyjnego. Warto przypomnieć, że tak jak w sekcji e_s = es_c_ui es_c_r es_c_ve. zachowanie c B robot, warunek końcowy init r_s e_s idle_not_synchronized d_s e_s synchronization s_e e_s idle_synchronized (s_c d_pc ) (s_o d_po ) e_s configurational_move d_c e_s operational_move d_o e_s emergency_stop Tabela 5.4: Warunki końcowe funkcji przejścia kolejnych zachowań podsystemu sterowania c robot Funkcje przejścia dekompozycja Podczas definiowania funkcji przejścia podsystemu sterowania, zdecydowano się dokonać ich dekompozycji ze względu na prowadzone obliczenia. Przyczyną decyzji była chęć uproszczenia 23

30 opisu poprzez uniknięcie powtarzania się dużych części opisu w ramach kilku funkcji przejść. W tej sekcji zaprezentowano działanie poszczególnych częściowych funkcji w formie diagramów bloków wewnętrznych SysML. Można wyróżnić trzy zasadnicze elementy diagramów. Są nimi: bufory komunikacyjne służące do komunikacji z wirtualnymi efektorami oraz do realizacji komunikacji międzyagentowej, bloki elementy odpowiedzialne za wykonywanie obliczeń, jak również porty komunikacji między blokami. Wprowadzono także oznaczenie CFP jako ogólną nazwę częściowej funkcji przejścia CFP synchro_check Funkcja c f robot,synchro_check (rys 5.5a) jest odpowiedzialna za sprawdzanie stanu synchronizacji robota, tj. wszystkich jego napędów. Blok nadzorcy komunikuje się z wirtualnymi efektorami robota poprzez port i_s, aby uzyskać informację o tym czy wszystkie napędy robota są zsynchronizowane. Informację o stanie synchronizacji całego robota przekazuje poprzez port r_s do bufora komunikacji międzyagentowej. Komunikacja Międzyagantowa r_s nadzorca i_s Wirtualne Efektory (a) CFP synchro_check Komunikacja Międzyagantowa es_i es_c_ui nadzorca es_c_n es_c_ve Wirtualne Efektory (b) CFP stop_handling es_c_r regulator Rysunek 5.5: Sprawdzanie stanu synchronizacji napędów oraz obsługa polecenia awaryjnego zatrzymania CFP stop_handling Funkcja c f robot,stop_handling (rys 5.5b) jest odpowiedzialna za obsługę awaryjnego zatrzymania robota. Polecenie awaryjnego zatrzymania może przyjść z trzech źródeł: od użytkownika poprzez bufor komunikacji międzyagentowej, od bloku regulatora oraz od wirtualnego efektora. Użytkownik może podjąć decyzję o awaryjnym zatrzymaniu wykorzystując interfejs użytkownika. Informacja ta przekazywana jest poprzez port es_c_ui do bloku nadzorcy, który wysyła do wszystkich wirtualnych efektorów poprzez port es_c_n polecenie przejścia w stan awaryjnego zatrzymania. W taki sam sposób, żądanie awaryjnego zatrzymania może wysłać blok regulatora poprzez port es_c_r. Na diagramie widać również trzecie źródło sygnału wejściowego do bloku nadzorcy (es_c_ve). Są nimi wirtualne efektory, które mogą autonomiczne podjąć decyzję o przejściu w stan awaryjnego zatrzymania. W takim przypadku wysyłają do bloku nadzorcy informację o podjętym działaniu. W każdej z opisanych sytuacji blok nadzorcy wysyła poprzez port es_i informację do interfejsu użytkownika o podjętym działaniu awaryjnego zatrzymania CFP passive_regulation Funkcja c f robot,passive_regulation (rys 5.6) realizuje bierną pętlę regulacji napędów robota. Jeśli na port d_p nie jest wysyłana nowa pozycja zadana dla regulatora, to jego zadaniem jest utrzymanie ostatniej zadanej pozycji nazwanej old-constant. Regulator pobiera aktualną pozycję silnika z portu m_p oraz wysyła obliczone sterowanie prądowe poprzez port c_r CFP state_calculate Funkcja c f robot,state_calculate (rys 5.7a) przekazuje do interfejsu użytkownika informację o położeniu robota w przestrzeni operacyjnej i konfiguracyjnej. Pozycja wałów silników m_p pobierana jest z wirtualnych efektorów i przekazywana do bloku odpowiedzialnego za transformację pozycji 24

31 regulator c_r m_p d_p <<datastore>> old-costant Wirtualne Efektory Rysunek 5.6: Bierna pętla regulacji CFP pasive_regulation do przestrzeni konfiguracyjnej (stawów). Obliczona wielkość przechowywana jest w porcie c_p i przekazywana to bufora komunikacji międzyagentowej oraz bloku odpowiedzialnego za obliczanie prostej kinematyki robota. Wyniki obliczeń przekazywane są poprzez port o_p do bufora komunikacji międzyagentowej CFP synchronization Funkcja c f robot,synchronization odpowiedzialna jest za realizację synchronizacji napędów robota. Polecenie wykonania synchronizacji wysyłane jest przez interfejs użytkownika i przechowywane w buforze d_s bloku nadzorcy, który przekazuje żądanie do bloku synchronizacji. Po wykonaniu synchronizacji, tj. w momencie otrzymania informacji na porcie s_e o jej zakończeniu, blok nadzorcy wysyła ją poprzez port s_ei do interfejsu użytkownika. Blok synchronizacji realizuje synchronizację kolejnych napędów robota sekwencyjnie wedle algorytmu przedstawionego w sekcji Blok synchronizacji komunikuje się z buforem komunikacji z wirtualnymi efektorami poprzez porty: m_p informacja o aktualnym położeniu wału silnika, s_s polecenie przejścia sterownika sprzętowego w tryb synchronizacji, f_s polecenie wyjścia sterownika sprzętowego z trybu synchronizacji, r_p polecenie wyzerowania pozycji enkoderów, s_a informacja o tym czy napęd znajduje się w polu synchronizacji, m_s informacja o przejściu sterownika sprzętowego w stan, w którym obsługiwany napęd jest zsynchronizowany. Poprzez port d_p wysyłana jest informacja od bloku synchronizacji do regulatora o zadanej pozycji, zaś przez port r_r polecenie resetowania zmiennych regulatora. Regulator wysyła do bufora komunikacji z wirtualnym efektorem poprzez port c_r wielkość sterowania prądowego, zaś otrzymuje informację o aktualnym położeniu wału silnika poprzez port m_p. Komunikacja Międzyagentowa Komunikacja Międzyagentowa o_p prosta kinematyka c_p transformacja z przestrzeni silników do przestrzeni stawów m_p d_p r_r regulator c_r m_p d_s s_e nadzorca d_sw s_ei synchronizacja m_p s_s, f_s, r_p s_a, m_s Wirtualne Efektory Wirtualne Efektory (a) CFP state_calculate (b) CFP synchronization Rysunek 5.7: Bierna pętla regulacji oraz synchronizacja CFP configurational_move i CFP operational_move Funkcje c f robot,configurational_move i c f robot,operational_move odpowiedzialne są odpowiednio za realizację ruchu robota w przestrzeni konfiguracyjnej i operacyjnej. Ich struktura jest podobna to tych przedstawionych w dwóch analizowanych wcześniej pracach [34, 33]. Podejście przedstawione 25