(Jezyk opisu i realizacja zadan przez automat skonczony w systemie

Transkrypt

Marek Kisiel
J¦zyk opisu i realizacja zada« przez automat
sko«czony w systemie MRROC++
Praca dyplomowa in»ynierska pod kierunkiem
mgr in». Tomasza Winiarskiego
Instytut Automatyki i Informatyki Stosowanej
Politechniki Warszawskiej
Warszawa, Listopad 2008
Podzi¦kowania
Specjalne podzi¦kowania kieruj¦ do osób, bez których pomocy i wsparcia powstanie tej
pracy nie byªoby mo»liwe. Nale»¡ do nich przede wszystkim moja »ona Ola oraz rodzice.
Chciaªbym tak»e ogromnie podzi¦kowa¢ mojemu promotorowi Tomkowi Winiarskiemu za
ogromn¡ cierpliwo±¢, któr¡ wykazaª w czasie naszej wspóªpracy i caª¡ pomoc jak¡ okazaª przy
realizacji tej pracy. Dzi¦kuj¦ równie» Piotrkowi Trojankowi za wszystkie rady i celne uwagi,
które bardzo mi pomogªy i miaªy wpªyw na ksztaªt niniejszej pracy.
Streszczenie
Celem pracy in»ynierskiej byªo zdeniowanie j¦zyka opisu zada« wielorobotowych w notacji XML, zgodnego z denicj¡ automatu sko«czonego oraz implementacja mechanizmu, który
pozwala na interpretacj¦ zdeniowanego zadania i jego wykonanie w rzeczywistym systemie
wielorobotowym.
W ramach pracy powstaª j¦zyk znaczników sªu»¡cy do zapisu automatu sko«czonego, bazuj¡cy na formacie XML, zawieraj¡cy denicj¦ elementów wykorzystywanych do opisu zadania
oraz zbiór reguª okre±laj¡cy sposób jego konstruowania.
Do interpretacji i realizacji zadania zapisanego zgodnie z przyj¦ta denicj¡ sªu»y mechanizm zaimplementowany w systemie
MRROC++.
Jego integraln¡ cz¦±ci¡ jest biblioteka
libxml,
która sªu»y do obsªugi dokumentów XML przy u»yciu j¦zyka C/C++.
Rozwi¡zanie b¦d¡ce przedmiotem tej pracy umo»liwia zapisanie zada« u»ytkowych zaimplementowanych obecnie w kodzie struktury
MRROC++
w postaci automatu sko«czonego,
w notacji XML. Poprawno±¢ jego dziaªania zostaªa zwerykowana poprzez zapisanie zada«
nalewania i ukªadania kostki Rubika zgodnie z przyj¦ta denicj¡ j¦zyka i ich uruchomienie
w systemie
MRROC++.
Abstract
Title: Description language and task execution by nite state automaton in the MRROC++
system.
The aim of this thesis was to create denition of multi-robot task description language
in XML notation which should be compliant with the Finite State Automaton denition. In
addition, the goal of this work was the implementation of mechanism to interpret and enforce
the dened task in real multi-robot system.
The markup language used to write nite state automaton, which is based on the XML
format, was a part of this thesis. It contains denition of the elements used to describe the
task and a set of rules determining the manner of its construction.
A special mechanism was implemented in the
MRROC++ system to interpret and execute the
tasks described in accordance with the language denition. An integral part of that mechanism
is an open source library
libxml,
which is used to handle XML documents using C/C++
language.
Thesis results enables the user to describe the task currently implemented in the C/C++
code as the nite state automaton, in XML notation. The pouring task and Rubik's cube
solving task were reimplemented in this way to verify proposed approach.
3
Spis tre±ci
1 Wst¦p
6
1.1
Geneza pracy
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2
Cel pracy
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3
Ukªad pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2 Wprowadzenie do systemu MRROC++
MRROC++
9
2.1
Struktura systemu
2.2
Proces
MP
2.2.1
Powªoka - cz¦±¢ staªa procesu
2.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.2
MP .
J¡dro - cz¦±¢ wymienna procesu MP
. . . . . . . . . . . . . . . . . . .
12
2.2.3
Generator trajektorii . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Procesy
2.3.1
2.3.2
ECP
. . . . . . . . . . . . . . . . . . .
12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ECP
J¡dro procesu ECP
.
Powªoka procesu
13
. . . . . . . . . . . . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3 Automat sko«czony
15
3.1
Automat typu Moore'a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2
Automat typu Mealy'ego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3
Wnioski
18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 XML
19
4.1
SGML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2
XML Rozszerzalny J¦zyk Znaczników . . . . . . . . . . . . . . . . . . . . . . .
20
4.2.1
Mechanizm XInclude . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.3
DTD Denicja Typu Dokumentu . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.4
Biblioteka libxml
23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Denicja j¦zyka opisu zada« w dokumencie XML
26
5.1
DTD denicji j¦zyka
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.2
Element <State> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.2.1
Szczegóªy atrybutów . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.2.2
Potomkowie elementu <State> . . . . . . . . . . . . . . . . . . . . . .
33
5.3
Element <SubTask> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.4
Element <ROBOT> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.5
Element <SetOfRobots>
35
5.6
Element <ECPGeneratorType>
5.7
Element <GeneratorFilePath>
5.8
Element <taskInit>
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
36
. . . . . . . . . . . . . . . . . . . . . . . . . .
36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.8.1
Element <ecp> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.8.2
Element <mp> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4
5.9
Element <Speech> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.10 Element <AddArg>
41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.11 Element <Sensor> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.12 Element <TimeSpan> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.13 Element <GeneratorParameters> . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.14 Element <Parameters>
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.16 Element <Trajectory> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.15 Element <transition>
5.15.1 Atrybut
target
5.17 Deniowanie zadania dla systemu
MRROC++
. . . . . . . . . . . . . . . . . . .
48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.17.2 Ukªadanie kostki Rubika . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.17.1 Zadanie nalewania
6 Realizacja mechanizmu interpretuj¡cego i wykonuj¡cego zdeniowane zadanie
54
6.1
6.2
Obiektowa reprezentacja elementów zadania . . . . . . . . . . . . . . . . . . .
54
6.1.1
Klasa State
55
6.1.2
Klasa Transition
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
6.1.3
Klasa Condition
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.1.4
Klasa StateHeap
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.1.5
Klasa Trajectory
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
Implementacja mechanizmu realizuj¡cego zadania . . . . . . . . . . . . . . . .
64
6.2.2
MP mechanizmu realizuj¡cego zadanie . . . . . . . .
Przykªadowe ECP mechanizmu realizuj¡cego zadanie
6.2.3
Metody dodane do klasy
ecp_task
6.2.4
Metody dodane do klasy
ecp_smooth_generator
6.2.1
6.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Plik konguracyjny
fsautomat.ini
. . . . . . . . . .
65
. . . . . . . . . .
68
. . . . . . . . . . . . . . . . . . . .
70
. . . . . . . . . . . .
70
. . . . . . . . . . . . . . . . . . . . . . . .
71
7 Podsumowanie
73
7.1
Wnioski
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
7.2
Perspektywy rozwoju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Literatura
75
Dodatek A
76
5
1 Wst¦p
1.1 Geneza pracy
W ogólnym przypadku programowanie systemów robotowych opiera si¦ na tworzeniu podobnych do siebie programów. Najcz¦±ciej uruchamiane s¡ one na ró»nym sprz¦cie oraz realizuj¡ nieco ró»ni¡ce si¦ mi¦dzy sob¡ zadania. W takim przypadku efektywnym narz¦dziem
wspomagaj¡cym tworzenie sterowników dla systemów robotowych s¡ programowe struktury
ramowe.
System
MRROC++1
[1] jest jedn¡ z takich programowych struktur ramowych. Powstaª w In-
stytucie Automatyki i Informatyki Stosowanej Politechniki Warszawskiej i przeznaczony jest
do tworzenia sterowników dla wspóªbie»nych systemów wielorobotowych. Napisany zostaª
w j¦zyku C++ i dziaªa pod kontrol¡ systemu operacyjnego czasu rzeczywistego QNX [2]
Neutrino.
MRROC++
w swoim obecnym ksztaªcie pozwala na budowanie nowych sterowników dla sys-
temów wielorobotowych przy wykorzystaniu ju» istniej¡cych rozwi¡za«, moduªów. Generatory
s¡ elementami, które w gªównej mierze s¡ wykorzystywane przy deniowaniu zada«. Prowadzi
to do wniosku, »e umiej¦tna dekompozycja zada« dla ukªadu wielorobotowego, na etapie ich
projektowania skutkuje zdeniowaniem sterowników wykorzystuj¡cych te same elementy.
Z kolei denicja automatu sko«czonego sprawia, »e jest on pot¦»nym narz¦dziem opisu
i implementacji logiki steruj¡cej. Maszyna stanowa posiada zwart¡ form¦ reprezentacji oraz
podlega prostym reguªom i jest ªatwa do werykacji.
Przedstawione wcze±niej wªa±ciwo±ci systemu
MRROC++,
charakterystyka zada« wielorobo-
towych oraz mo»liwo±ci maszyny stanowej prowadz¡ do konkluzji, »e wygodnym i naturalnym
sposobem konstruowania i zarazem opisu zadania jest wykorzystanie notacji zgodnej z logik¡
maszyny stanowej. Bardzo wygodnym j¦zykiem do reprezentowania ró»nych danych w ustruk-
2 i to on zostaª wykorzystany do zapisu denicji zadania zgodnie
turalizowany sposób jest XML
z reguªami maszyny stanowej.
Zainteresowanie tematem pracy wynikaªo z mo»liwo±ci realizacji rozwi¡zania, które mo»e
w znacznej mierze uªatwi¢ i przy±pieszy¢ tworzenie nowych sterowników. Mechanizm zaimplementowany w niniejszej pracy jest nowatorski z punktu widzenia programowania systemów
robotowych, a zarazem daje okazj¦ do dalszego jego rozwoju.
1.2 Cel pracy
Celem niniejszej pracy in»ynierskiej byªo zdeniowanie j¦zyka opisu zada« wielorobotowych w notacji XML, wykorzystuj¡cego reprezentacj¦ automatu sko«czonego oraz implementacja mechanizmu, który pozwala na interpretacj¦ zdeniowanego zadania i jego wykonanie
w systemie
MRROC++
(rysunek 1.2)
Jednym z wymaga« stawianych tej pracy byªa implementacja narz¦dzia, które by w znacz-
1
2
Multi-Robot Research Oriented Controler
Extensible Markup Language
6
Rysunek 1: Ogólna struktura dziaªania systemu
nym stopniu zmniejszaªo wysiªek konieczny do zdeniowania i uruchomienia zadania. Sam
fakt, i» opisywane rozwi¡zanie nie wymaga przekompilowania caªego lub te» cz¦±ci ±rodowiska, które obecnie jest konieczne przy budowaniu nowych i modykacji istniej¡cych zada«,
owocuje tym, »e czas potrzebny do napisania nowego sterownika zostaje znacznie skrócony.
Równie po»¡dan¡ cech¡, co zmniejszenie czasochªonno±ci tworzenia nowego sterownika
w systemie
MRROC++,
jest umo»liwienie osobom nieznaj¡cym j¦zyka programowania C++,
w którym napisany jest kod ¹ródªowy systemu robotycznego
MRROC++,
a tak»e którego zna-
jomo±¢ potrzebna jest do sprawnego pisania zada« wielorobotowych, pracy nad tworzeniem
nowych sterowników. Speªnienie tego wymagania mo»e zaowocowa¢ faktem, »e programowalna
struktura ramowa jak¡ jest
MRROC++, b¦dzie bardziej otwarta
i wzbudzi zainteresowanie szer-
szego grona osób zainteresowanych jej rozwojem.
W wi¦kszo±ci prac rozwojowych nad systemem
MRROC++
du»y nacisk jest kªadziony na
wieloplatformowo±¢ tworzonego rozwi¡zania, co równie» dotyczy omawianej tutaj pracy. Zaimplementowany mechanizm ma wykonywa¢ zadanie u»ytkowe na podstawie jego denicji
opisanej w dokumencie XML. Tworzenie wspomnianego pliku jest niezale»ne od platformy.
W zaªo»eniu plik w formacie XML ma umo»liwia¢ ªatw¡ wymian¦ dokumentów pomi¦dzy
ró»nymi systemami, co jest po»¡dan¡ w tej pracy cech¡ formatu XML.
1.3 Ukªad pracy
W rezultacie niniejszej pracy powstaª j¦zyk opisu zada« wielorobotowych oraz mechanizm
po stronie systemu
MRROC++,
który jest odpowiedzialny za interpretacj¦ zadania oraz za jego
wykonanie w systemie robotycznym. Aby przedstawi¢ przyj¦te rozwi¡zanie, pierwsze rozdziaªy
tego dokumentu skupiaj¡ si¦ na przybli»eniu elementów oraz technologii, które zostaªy u»yte
przy realizacji projektu. W rozdziale 2 znajduje si¦ krótki opis struktury
MRROC++. Uwag¦ sku-
piono na elementach, na poziomie których byª implementowany wspomniany wcze±niej mechanizm. Zostaªy równie» wymienione i opisane wykorzystane technologie (libxml)(Sekcja 4.4),
oraz standardy(XML)(Rozdziaª 4). Umieszczone s¡ równie» w tym rozdziale podstawy teoretyczne, na kanwie których zbudowany zostaª j¦zyk opisu. Jest to denicja automatu sko«czonego (Rozdziaª 3) oraz reguªy odnosz¡ce si¦ do sposobu budowy i implementacji tego typu
7
konstrukcji. W nast¦pnych rozdziaªach zostaj¡ opisane elementy powstaªe w wyniku przeprowadzonych prac. Skªadaj¡ si¦ na nie: denicja j¦zyka opisu zada« (Rozdziaª 5) oraz mechanizm
interpretacji i realizacji zadania po stronie struktury systemu
MRROC++ (Rozdziaª 6). Nast¦pnie
w ostatnim rozdziale znajduj¡ si¦ podsumowanie i wnioski z przeprowadzonych prac (Rozdziaª 7).
8
2 Wprowadzenie do systemu MRROC++
MRROC++
[1] to programowa struktura ramowa. Jej zadaniem jest wspomaganie wytwa-
rzania sterowników dla systemów wielorobotowych. Powstaªa w Instytucie Automatyki i Informatyki Stosowanej Politechniki Warszawskiej, a jej historia si¦ga pocz¡tku lat dziewi¦¢dziesi¡tych. Wówczas pojawiª si¦ pierwowzór systemu
MRROC++ o nazwie RORC3
[3] wspoma-
gaj¡cy tworzenie sterowników dla pojedynczych robotów. W roku 1995 pojawiª si¦ nast¦pca
RORC'a o nazwie MRROC [4], który umo»liwiaª wspóªprac¦ z systemami wielorobotowymi,
ale w przeciwie«stwie do powstaªego kilka lat pó¹niej obiektowego
MRROC++,
z wykorzystaniem paradygmatu programowania proceduralnego. Struktura
tworzony byª
MRROC++ jest caªy
czas rozwijana i jest podstawowym narz¦dziem sªu»¡cym do tworzenia coraz bardziej zªo»onych i zaawansowanych sterowników, jakim na przykªad jest realizacja zadania ukªadania
kostki Rubika [5]
System
MRROC++
jest bibliotek¡ moduªów, z których jest konstruowany sterownik i zara-
zem j¦zykiem programowania w którym to zadanie jest wyra»ane. Zawiera wzorce programów
(sterowników) na bazie których, w poª¡czeniu z moduªami, na które skªadaj¡ si¦ funkcje,
obiekty i procesy napisane w j¦zyku C++, mo»na w ªatwy sposób zbudowa¢ nowy sterownik dedykowany okre±lonemu zadaniu dla systemu wielorobotowego. Istotn¡ cech¡ struktury
MRROC++
jest jej otwarto±¢, umo»liwiaj¡ca doª¡czenie do systemu dowolnej liczby efektorów
i czujników.
2.1 Struktura systemu MRROC++
Ka»dy system robotyczny
• efektory e
s
mo»na zdekomponowa¢ na trzy cz¦±ci:
elementy systemu oddziaªywuj¡ce na otoczenie,
• receptory r
czujniki rzeczywiste (dostarczaj¡ informacji o otoczeniu),
• podsystem sterowania c
system odpowiedzialny za zarz¡dzanie efektorami oraz
receptorami; skªada si¦ na niego sprz¦t obliczeniowy wraz z oprogramowaniem na nim
dziaªaj¡cym.
Na podstawie przyj¦tych oznacze« poszczególnych cz¦±ci systemu oraz ich stanów mo»na
zapisa¢ nast¦puj¡cy wzór:
s =< e, r, c >,
s ∈ S,
e ∈ E,
r ∈ R,
c ∈ C,
gdzie:
s
jest stanem systemu robotycznego,
S
jest przestrzeni¡ stanów systemu
e
jest stanem efektorów,
E
jest przestrzeni¡ stanów efektorów
r
jest stanem receptorów,
R
jest przestrzeni¡ receptorów
c
jest stanem podsystemu sterowania,
C
jest przestrzeni¡ stanów podsystemu
sterowania
3
Research-Oriented Robot Controller
9
(1)
Dane pochodz¡ce z czujników rzeczywistych musz¡ zosta¢ przeksztaªcone (zagregowane)
do postaci u»ytecznej w sterowaniu, gdzie s¡ nazywane odczytem czujnika wirtualnego:
v = fv (r, c, e),
gdzie
V
v∈V
(2)
jest przestrzeni¡ odczytów czujników wirtualnych, a funkcja
fv
nosi nazw¦ funkcji
agreguj¡cej. Funkcja ta zazwyczaj zale»y od stanu receptorów. Odczyt czujnika wirtualnego
mo»e te» zale»e¢ od stanu podsystemu sterowania, jak i stanu efektorów.
Rysunek 2: Struktura sterownika
Sterownik
MRROC++
MRROC++ skªada si¦ z moduªów b¦d¡cych odr¦bnymi procesami, co jest efektem
jego hierarchicznej struktury funkcjonalnej. Procesy uruchamiane s¡ w w¦zªach sieci lokalnej dziaªaj¡cej pod kontrol¡ systemu operacyjnego czasu rzeczywistego QNX. Modularna
struktura systemu upraszcza jego modykacj¦. Wymiana jednego z elementów nie wi¡»e si¦
z konieczno±ci¡ wymiany czy modykacji pozostaªych moduªów. Obecn¡ struktur¦ systemu
MRROC++
pokazano na rysunku 2.
W ukªadzie sterowania mo»na wyró»ni¢ kilka warstw. Najni»sza z warstw odwoªuje si¦
bezpo±rednio do sprz¦tu, a w jej skªad wchodz¡ procesy obsªugi urz¡dze« (efektorów, czujników). Procesy
EDP
(ang.
Eector Driver Process )
dla danego typu efektora. z kolei procesy
s¡ sterownikami charakterystycznymi
VSP (ang. Virtual Sensor Processes ) s¡ odpowie-
dzialne za odczyt i przetwarzanie danych z czujników rzeczywistych. W kolejnej warstwie
mamy procesy:
ECP
(ang.
Eector Control Process ),
10
które realizuj¡ algorytmy sterowania
poszczególnymi efektorami, w zale»no±ci od wykonywanego aktualnie przez system zadania.
Warstw¦ nadrz¦dn¡ tworzy proces
MP (ang. Master Prosess ). Jest on odpowiedzialny za ko-
ordynacj¦ procesów steruj¡cych robotami. Dodatkowa warstwa, która nie jest bezpo±rednio
zwi¡zana z realizacj¡ zadania, to proces UI (ang.
User Interface ). Zapewnia on komunikacj¦
sterownika z operatorem.
MP oraz ECP s¡ zale»ne od zadania, które ma wykona¢ system
procesy zale»ne od sprz¦tu, czyli EDP, oraz VSP s¡ niezale»ne od
Wspomniane wy»ej procesy
robotyczny. Natomiast
zadania. Jedynie w sytuacji kiedy do systemu doª¡czany jest nowy efektor b¡d¹ czujnik,
wymagana jest modykacja tych procesów.
Rysunek 3: Ogólna struktura procesów
Procesy
MP i ECP.
MP i ECP mo»na podzieli¢ na dwie podstawowe cz¦±ci, co zostaªo pokazane na
rysunku 3
•
powªok¦
•
j¡dro
niezmienna cz¦±¢ procesu, niezale»na od wykonywanego zadania,
wymienna cz¦±¢ procesu, zale»na od zadania realizowanego przez system robo-
tyczny.
Powªoka ka»dego z tych procesów odpowiada za rejestracj¦ procesu w systemie operacyjnym, komunikacj¦ z innymi procesami w systemie, a tak»e za obsªug¦ bª¦dów. Zadania j¡dra
s¡ ró»ne dla ka»dego procesu.
2.2 Proces MP
Proces
•
Master Process
ma za zadanie:
koordynowa¢ prac¦ wszystkich obecnych w systemie efektorów,
11
•
generowa¢ trajektorie dla ±ci±le wspóªpracuj¡cych robotów,
•
nasªuchiwa¢ polece« od operatora w momencie wykonywania zadania,
•
informowa¢ poprzez
UI o ewentualnych bª¦dach i awariach.
2.2.1 Powªoka - cz¦±¢ staªa procesu
Zadaniem powªoki procesu
MP
MP jest:
•
utworzenie ª¡czy komunikacyjnych z innymi procesami,
•
nasªuchiwanie polece« od operatora systemu,
•
powoªywanie i likwidacja procesów
•
obsªuga bª¦dów,
•
informowanie o bª¦dach i awariach pojawiaj¡cych si¦ w czasie pracy systemu,
•
realizacja programu u»ytkownika zawartego w j¡drze procesu
ECP i VSP,
MP.
MP po fazie inicjalizacji tworzy ª¡cze komunikacyjne z interfejsem u»ytkownika UI.
W kolejnym kroku powoªywane s¡ wszystkie ECP oraz tworzone s¡ kanaªy odpowiedzialne
za komunikacj¦ pomi¦dzy MP, a procesami ECP. Nast¦pnie MP przechodzi w stan oczekiwania na polecenie START od UI. Po otrzymaniu tego polecenia MP rozpoczyna wykonywanie
Proces
zawartego w j¡drze procesu programu u»ytkowego.
Polecenia od operatora systemu s¡ nasªuchiwane i przyjmowane za pomoc¡ sygnaªów
(SIGTERM) i za pomoc¡ pulsów (ang.
cenia
pulses ). MP
START, STOP, RESUME, PAUSE.
2.2.2 J¡dro - cz¦±¢ wymienna procesu
J¡dro procesu
•
przyjmuje i adekwatnie reaguje na pole-
Master Process
MP
zawiera:
obiekty klas pochodnych, wywiedzionych z klas bazowych takich jak:
mp_robot,
ecp_mp_sensor i transmiter,
•
program u»ytkowy.
Program u»ytkowy (zadanie) jest implementowany w j¦zyku C++ w
w gªównej mierze zbudowane s¡ z instrukcji
MRROC++,
i stanowi¡ j¡dra tych procesów.
Move
MP i ECP,
które
i z innych funkcji bibliotecznych systemu
MP i ECP
dziaªaj¡ jedynie na obrazach robotów,
dlatego u»ywaj¡ tylko abstrakcyjnej notacji, w zwi¡zku z tym poªo»enie ko«cówki manipulatora mo»e by¢ okre±lone np. we wspóªrz¦dnych kartezja«skich i k¡tach Eulera. Na poziomie
MP
obraz robota jest uaktualniany na podstawie informacji docieraj¡cej a poziomu
Programista pisz¡cy nowy sterownik tworzy
MP
ECP.
poprzez okre±lenie listy wªa±ciwych robo-
tów, czujników i transmiterów (a wªa±ciwie obrazów robotów, czujników oraz transmitterów)
12
oraz odpowiednich generatorów trajektorii. Aby wykona¢ ruch programista wskazuje, które
roboty, czujniki i transmitery b¦d¡ u»yte. Odpowiadaj¡ce im obiekty, czyli
i
robot, sensor
transmitter zapewniaj¡ interakcj¦ z wªasnymi procesami ECP oraz VSP. Rozpocz¦cie dzia-
ªania programu u»ytkowego polega na wysªaniu zlecenia wszcz¦cia wykonania do wszystkich
podlegªych mu procesów
ECP (start_all)
Wszystkie wcze±niej wspomniane klasy robotów pojawiaj¡ce si¦ na poziomie procesu
musz¡ by¢ wywiedzione z klasy bazowej
nej z
mp_robot
MP
mp_robot. Ka»dy obiekt klasy konkretnej wywiedzio-
zawiera struktur¦ zwan¡
obrazem robota,
która przechowuje aktualny stan
robota oraz stan nast¦pny (pozycj¦ zadan¡). Dane przechowywane przez t¡ struktur¦ s¡ wykorzystywane w obliczeniach dokonywanych przez generator trajektorii. Klasa
metody
robot
posiada
create_command i get_reply, które s¡ odpowiedzialne za komunikacj¦ pomi¦dzy ob-
razem robota, a procesem.
2.2.3 Generator trajektorii
Obiekt konkretnego generatora trajektorii, wywiedziony z klasy bazowej
jest jedynym argumentem instrukcji
Move.
ecp_generator,
Gªównym zadaniem generatora jest sprawdzenie
warunku ko«cowego instrukcji ruchowej na podstawie informacji zawartej w li±cie czujników
i robotów. Je»eli warunek ten nie jest speªniony, zadaniem generatora jest wygenerowanie
nowych warto±ci zadanych dla robota.
Generator musi by¢ wskazany dla ka»dego ruchu. Ogromn¡ zalet¡ klas konkretnych generatorów trajektorii jest fakt, »e obiekty z nich wywiedzione mog¡ zosta¢ na poziomie ró»nych
procesów
ECP.
2.3 Procesy ECP
Procesy
ECP s¡ odpowiedzialne za:
•
uruchomienie zadania u»ytkowego pojedynczego efektora,
•
przesyªanie informacji do
•
generacj¦ trajektorii w przypadku dziaªania niezale»nego lub lu¹nej wspóªpracy z innymi
MP i EDP w celu realizacji zadania,
robotami,
MP i wysyªanie odpowiedzi,
•
odbieranie informacji od
•
przekazywanie komunikatów oraz informacji o ewentualnych bª¦dach do
Ogólna struktura procesu
2.3.1 Powªoka procesu
Powªoka procesu
•
ECP jest analogiczna do struktury MP.
ECP
ECP jest cz¦±ci¡ niezmienn¡, a do jej zada« nale»y:
nasªuchiwanie polece« z
MP,
13
UI.
VSP,
•
powoªywanie i likwidacja
•
komunikacja z innymi procesami,
•
obsªuga ewentualnych wyj¡tków,
•
sygnalizacja sytuacji awaryjnych procesom
•
realizacja programu u»ytkowego zapisanego w j¡drze procesu.
MP,
ECP rozpoczyna prac¦ od rejestracji swojej nazwy w w systemie oraz lokalizaprocesów MP, EDP_MASTER i UI. W kolejnym kroku tworzy ª¡cza komunikacyjne ze
Proces
cji
wspomnianymi procesami, a nast¦pnie przechodzi do wykonania zadania zapisanego przez
programist¦.
2.3.2 J¡dro procesu
ECP
ECP stanowi cz¦±¢ wymienn¡ tego procesu i jest zbudowane w gªównej mierze z analogicznych elementów jak proces MP. Zawiera:
J¡dro
•
obiekty
klas
wywiedzionych
z
transmitter, ecp_generator),
•
klas
bazowych
(np.
ecp_robot, ecp_mp_sensor,
które b¦d¡ u»ywane w realizacji zadania,
program u»ytkowy.
W ramach realizacji mechanizmu wykonuj¡cego zadanie u»ytkowe zapisane w dokumencie
XML zostaªy stworzone odpowiednie procesy
MP oraz ECP. Ich j¡dra zostaªy zaimplemento-
wane w sposób umo»liwiaj¡cy interpretacj¦ wspomnianego zadania, stworzenie obiektowego
modelu automatu po stronie systemu
MRROC++ i uruchomienie zadania jako maszyny stanowej.
W wyniku implementacji powstaªy procesy:
• mp_fsautomat
• ecp_irp6ot_fsautomat
• ecp_irp6p_fsautomat
14
3 Automat sko«czony
Finite State Machine ) lub Automatem Sko«czonym FSA (ang. Finite State Automaton ), czy te» Maszyn¡ Stanow¡ SM (ang. State Machine )
Sko«czon¡ Maszyn¡ Stanow¡ FSM (ang.
nazywamy model zachowania skªadaj¡cy si¦ ze sko«czonej liczby stanów, przej±¢ mi¦dzy tymi
stanami i akcji. Maszyna stanowa jest abstrakcyjnym modelem maszyny z prymitywn¡ pami¦ci¡ wewn¦trzn¡.
Automat sko«czony mo»na traktowa¢ jako element, który w odpowiedzi na zdarzenia wej±ciowe generuje odpowied¹ wyj±cia. W sytuacji, kiedy odpowied¹ zale»aªaby tylko od wej±cia
(stan wyj±cia dla takiej samej warto±ci na wej±ciu byªby taki sam) automat sko«czony nie
miaªby sensu. Zachowanie automatu na wyj±ciu jest nie tylko bezpo±redni¡ konsekwencj¡
aktualnego stanu wej±¢, ale tak»e poprzednich stanów systemu (przeszªo±ci). Automat jest
opisany przez zestaw stanów wewn¦trznych reprezentuj¡cych histori¦ dziaªania od momentu
startu systemu do tera¹niejszo±ci. Przej±cie wskazuje na kolejny stan automatu i jest opisane
przez warunek, który musi zosta¢ speªniony, aby przej±cie do nast¦pnego stanu byªo mo»liwe.
Akcja, czy te» dziaªanie, jest opisem czynno±ci, która ma by¢ wykonana w danym momencie.
Istnieje kilka rodzajów akcji:
• entry
• exit
• do
akcja wykonywana przy wej±ciu do stanu,
akcja wykonywana przy wyj±ciu ze stanu,
akcja wykonywana w sposób ci¡gªy, gdy system znajduje si¦ w danym stanie.
Automat sko«czony mo»emy modelowa¢ na ró»ne sposoby, przy czym najbardziej znane s¡
modele Moore'a i Mealy'ego. Wspomniane typy automatów klasykuje si¦ jako
przetworniki.
Automat sko«czony, w którym wyj±cia zale»¡ jedynie od stanów wewn¦trznych, to automat
Moore'a.
Automat sko«czony, w którym wyj±cia zale»¡ od aktualnego stanu wej±¢ oraz od stanów
wewn¦trznych nazywamy automatem Mealy'ego.
W obu przedstawionych przypadkach stan nast¦pny jest funkcj¡ stanu bie»¡cego oraz wej±cia.
Z przedstawionych wªasno±ci wspomnianych automatów wynika, i» ka»dy automat Moore'a
jest jednocze±nie automatem Mealy'ego. Okazuje si¦ te», »e z ka»dego automatu Mealy'ego
mo»na przej±¢ na automat Moore'a, co wi¡»e si¦ ze zwi¦kszeniem liczby stanów.
Sko«czona maszyna stanowa jest typem automatu zdeniowanym przez krotk¦ 6 elementow¡
(S, Σ, Λ, T, G, s)
zªo»on¡ ze:
S,
•
sko«czonego zbioru stanów
•
sko«czonego zbioru sygnaªów wej±ciowych (tzw. alfabet wej±ciowy)
•
sko«czonego zbioru sygnaªów wyj±ciowych (tzw. alfabet wyj±ciowy)
•
funkcji przej±cia
•
funkcji wyj±ciowej
T : S × Σ S,
G : S × Σ Λ,
15
Σ,
Λ,
•
stanu pocz¡tkowego
s ∈ S.
Przy opisie automatu sko«czonego b¦dziemy korzysta¢ z takich poj¦¢ jak:
• Stan
za jego pomoc¡ okre±lamy aktualny stan systemu, mo»e by¢ zwi¡zany z akcj¡,
• Tranzycja wskazuje zmian¦ stanu i jest opisana warunkiem, który musi zosta¢ speªniony
w celu uaktywnienia tranzycji,
• Akcja
jest opisem aktywno±ci wykonywanej w danej chwili.
Automat sko«czony mo»e by¢ przykªadowo przedstawiony za pomoc¡ diagramu stanów
(Rysunek 4).
Rysunek 4: Przykªad automatu sko«czonego
Mo»liwa jest równie» prezentacja automatu sko«czonego w postaci ró»nego rodzaju tabel.
Najbardziej powszechna reprezentacja pokazana jest w przykªadowej tabeli 1.
Stan aktualny
Warunek
Stan A
Stan B
Stan C
Warunek X
Stan B
...
...
Warunek Y
...
Stan C
...
Warunek Z
...
...
Stan A
Tablica 1: Tabela przej±¢ stanów
W tabeli jest przedstawiony przykªad, w którym kombinacja aktualnego stanu (
B ) i wa-
Y ) pokazuje nowy stan (C ).
runku (
3.1 Automat typu Moore'a
W modelu Moore'a gªównym elementem s¡ stany, a sam automat dziaªa zgodnie z konwencj¡ zakªadaj¡c¡, »e je±li zmieniaj¡ si¦ warunki wej±ciowe, to maszyna stanowa zmienia swój
16
stan, a przy wej±ciu w nowy stan automat wykonuje akcj¦ zwi¡zan¡ z tym stanem. W tym
modelu z tranzycj¡ nie jest zwi¡zana »adna akcja, a wyj±cie zale»y jedynie od stanu w jakim
maszyna si¦ znajduje. Przej±cie do innego stanu nast¦puje jedynie w sytuacji kiedy warunek
tranzycji jest speªniony. Akcja wyj±ciowa zale»y tylko od stanu aktualnego.
Rysunek 5: Maszyna stanowa Moore'a
(Rysunek 5) przedstawia diagram opisuj¡cy dziaªanie urz¡dzenia otwieraj¡cego i zamykaj¡cego
drzwi.
czujnik_otwarte
Sygnaªami
oraz
wej±ciowymi
czujnik_zamkni¦te,
dla
tego
urz¡dzenia
s¡
zamknij, otwórz,
przy czym dwa pierwsze pochodz¡ od u»ytkow-
nika, a pozostaªe od czujników umieszczonych w systemie. Wyj±ciem jest praca elementu
wykonawczego, w tym przypadku siªownika. Otwiera on drzwi przez caªy czas, gdy maszyna
znajduje si¦ w stanie
Otwieranie.
mencie wyst¡pienia zdarzenia
Otwarte.
Przej±cie do nast¦pnego stanu nast¦puje dopiero w mo-
czujnik_otwarte.
Stanem docelowym tego przej±cia jest stan
Nast¦pny krok dziaªania urz¡dzenia wyst¦puje w momencie wydania polecenia za-
mknij przez u»ytkownika i wi¡»e si¦ z przej±ciem do stanu
wyst¡pienia zdarzenia
Zamykanie, który trwa do momentu
czujnik_zamkni¦te.
3.2 Automat typu Mealy'ego
W omawianym tutaj modelu Mealy'ego akcje zwi¡zane s¡ z tranzycj¡ i s¡ wykonywane
przy przej±ciu ze stanu ¹ródªowego do stanu docelowego. Przyjmuje si¦, »e automat sko«czony
zawsze jest w jakim± stanie, a tranzycje s¡ atomowe. W praktyce wygl¡da to w sposób nast¦puj¡cy: stan zawiera zbiór akcji wyj±ciowych, z których ka»da jest przypisana do jednej
z tranzycji wyj±ciowych z tego stanu, wiec w przypadku kiedy s¡ speªnione warunki odpalenia tranzycji akcje z ni¡ zwi¡zane s¡ wykonywane przed opuszczeniem stanu ¹ródªowego
i dopiero po ich wykonaniu automat znajduje si¦ w stanie docelowym, czyli nie zachodzi sy-
17
tuacja, w której automat nie znajduje si¦ w »adnym stanie, a akcje s¡ wykonywane pomi¦dzy
stanami.
Rysunek 6: Maszyna stanowa Mealy'ego
Na rysunku 6 przedstawione jest urz¡dzenie analogiczne do tego z rysunku 5. Diagram
jest zapisany zgodnie z modelem Mealy'ego i jak wida¢ zawiera o jeden stan mniej ni» poprzedni diagram. Nie wyst¦puj¡ tutaj stany
si¦ stan
Praca siªownika,
Zamykanie oraz Otwieranie, a w zamian pojawia
w którym ponadto wyst¦puje wi¦cej ni» jedna akcja wyj±ciowa.
Automat b¦d¡c w tym stanie, w zale»no±ci od tego jaka komenda pojawiªa si¦ na wej±ciu, wystawia sterowanie
siªownik_otwieraj
b¡d¹
siªownik_zamykaj.
Stan aktualny nie w peªni
charakteryzuje odpowied¹ maszyny, gdy» wyj±cie zale»y równie» od wej±cia.
3.3 Wnioski
Ró»nic¦ pomi¦dzy przedstawionymi modelami mo»na zauwa»y¢ porównuj¡c rysunki 5
oraz 6. Na obu diagramach zostaª przedstawiony automat stanowy steruj¡cy drzwiami,
reaguj¡cy na generowane przez u»ytkownika zdarzenia
zamknij
i
otwórz
rzenia wysªane przez czujnik otwarcia i zamkni¦cia drzwi, mianowicie
i
czujnik_zamkni¦te.
oraz na zda-
czujnik_otwarte
Jak ju» wspomniano wcze±niej, w modelu Moore'a dla tego samego
zadania jest wi¦cej stanów, jednak nie ma akcji zwi¡zanych z tranzycjami. z kolei w modelu Mealy'ego z tranzycjami powi¡zane s¡ akcje co wi¡»e si¦ z faktem, »e liczba stanów jest
mniejsza.
Z przedstawionych powy»ej porównania mo»na wnioskowa¢, »e model Moore'a jest prostszy w implementacji. Skªada si¦ z mniejszych i mniej skomplikowanych elementów wyst¦puj¡cych w wi¦kszej liczbie. z kolei automat Mealy'ego wydaje si¦ by¢ bardziej czytelny i ªatwiejszy
do przedstawienia w postaci diagramu. Przydatno±¢ ka»dego z modeli zale»y w du»ej mierze
od konkretnego zastosowania i trudno jednoznacznie okre±li¢, który z tych modeli jest lepszy.
W kontek±cie denicji zadania u»ytkowego, niniejsza praca skupia si¦ na omówionym tutaj
modelu Moore'a.
18
4 XML
Extensible Markup Language ),
XML [6] (ang.
J¦zyk Znaczników,
czyli w wolnym tªumaczeniu
Rozszerzalny
jest uniwersalnym j¦zykiem formalnym przeznaczonym do reprezentowa-
nia ró»nych danych w ustrukturalizowany sposób. J¦zyk XML jest niezale»ny od platformy,
dzi¦ki czemu umo»liwia ªatwa wymian¦ dokumentów pomi¦dzy ró»nymi systemami. Fakt ten
znacz¡co przyczyniª si¦ do popularyzacji tego j¦zyka w dobie internetu. XML jest podzbiorem
j¦zyka SGML (ang.
Standard Generalized Markup Language ), zwi¡zku z tym ka»dy dokument
XML jest równie» dokumentem SGML. XML jest rekomendowany i specykowany przez organizacj¦
W3C
(ang.
World Wide Web Consortium ).
4.1 SGML
SGML jest to standardowy uogólniony j¦zyk znaczników. Sªu»y do ujednolicenia struktury
i formatu ró»nego rodzaju informacji (danych) i pozwala je zapisa¢ w postaci dokumentu
tekstowego, dzi¦ki czemu jest niezale»ny od sytemu operacyjnego.
SGML w odró»nieniu od j¦zyków znaczników dedykowanych do konkretnych zastosowa«,
jakim dla przykªadu jest HTML (ang.
HyperText Markup Language ),
nie jest zbiorem okre-
±lonych znaczników i reguª ich u»ytkowania. Jest ogólnym, nadrz¦dnym j¦zykiem sªu»¡cym
do deniowania dowolnych znaczników i ustalania zasad ich poprawnego u»ytkowania.
J¦zyka SGML u»ywa si¦ w praktyce do dwóch celów:
•
precyzyjnego deniowania zbiorów znaczników przeznaczonych do konkretnych zastosowa« (np. HTML),
•
ujednolicania zasad pisania i przekazywania dokumentów tekstowych w obr¦bie du»ych
rm i instytucji.
W powy»szych przypadkach dokument w j¦zyku SGML skªada si¦ z trzech cz¦±ci:
•
deklaracji dokumentu deniuje ogólne reguªy stosowane w zapisie dokumentu (np.
maksymalna dªugo±¢ nazwy elementu, znak u»ywany jako pocz¡tek znacznika domy±lnie jest to znak
•
DTD (ang.
< ),
Document Type Denition )
denicji typu dokumentu (szerzej opisana
w 4.3),
•
wªa±ciwego dokumentu tekst wraz ze znacznikami.
Z powodu zªo»ono±ci standardu SGML, bardzo niewielka liczba narz¦dzi implementuje
peªen standard. W efekcie trudno±ci implementacyjnych powstaª j¦zyk i standard XML, który
na pocz¡tku swego istnienia (pierwsza wersja powstaªa w 2000 roku), byª jedynie podzbiorem
reguª SGML.
19
4.2 XML Rozszerzalny J¦zyk Znaczników
Rozszerzalny j¦zyk znaczników XML jest prostym i bardzo elastycznym formatem dokumentów. Zostaª zaczerpni¦ty z wspomnianego w poprzednim podrozdziale SGML'a. XML
zostaª pocz¡tkowo zaprojektowany, aby stawi¢ czoªo wyzwaniom elektronicznej dziaªalno±ci
wydawniczej prowadzonej na szerok¡ skal¦. W chwili obecnej XML odgrywa wa»na rol¦ w wymianie ró»nego rodzaju danych zarówno w sieci internetowej jak i poza ni¡. XML jest otwartym
standardem, na który skªada si¦ format danych, jak i j¦zyk modelowania danych. W zwi¡zku
z tym mo»na powiedzie¢, »e XML stanowi metaj¦zyk, który umo»liwia tworzenie j¦zyków
znaczników.
Integraln¡ cz¦±ci¡ dokumentu w formacie XML s¡ znaczniki. Znacznikiem nazywamy ci¡g
znaków otoczony przez ostre nawiasy. W poni»szym przykªadzie mo»emy zobaczy¢ znaczniki
u»ywane w dokumencie XML:
•
znacznik otwieraj¡cy pole danych,
•
znacznik zamykaj¡cy pole danych.
Rysunek 7: Przykªad znaczników j¦zyka XML
Mo»liwe jest sprawdzenie poprawno±ci gotowego dokumentu XML, przy czym rozró»nione
s¡ dwa typy takiej poprawno±ci.
Dokument jest poprawny skªadniowo (ang.
well-formed ), je»eli jest zgodny z reguªami skªadni
XML. Reguªy te obejmuj¡ m.in. konieczno±¢ domykania wszystkich znaczników. Dokument
niepoprawny skªadniowo nie mo»e by¢ przetworzony przez parser XML.
Dokument jest poprawny strukturalnie (ang.
valid ) je»eli jest zgodny z denicj¡ dokumentu,
tzn. dodatkowymi reguªami okre±lonymi przez u»ytkownika. Do precyzowania tych reguª sªu»¡
specjalne j¦zyki takie jak DTD, XML Schema oraz
RELAX NG
[7]
Wydruk 1 przedstawia przykªadowy dokument XML. Pierwsza linia tego dokumentu zaczyna si¦ instrukcj¡ steruj¡c¡. Zawiera ona informacje o wersji standardu XML, z jakim dokument jest zgodny, oraz informacj¦ o sposobie kodowania znaków. Zgodnie ze standardem
wszystkie te informacje s¡ opcjonalne, mo»na pomija¢ dowolne z nich, a nawet caª¡ instrukcj¦
steruj¡c¡. W sytuacji, kiedy brakuje której± z danych, przyjmuje si¦ warto±¢ domy±ln¡, czyli
wersja
1.0
oraz standard kodowania
UTF-8.
W chwili obecnej mamy do czynienia z dwoma standardami dokumentów XML. S¡ to:
•
wersja
1.0,
20
•
wersja
1.1.
Nale»y zaznaczy¢, »e wersja
1.1
nie jest traktowana jako nast¦pca dla
1.0.
Jest to ra-
czej odmiana standardu przeznaczona do bardzo specycznych zastosowa«. Wprowadza ona
zmiany w zestawie dopuszczalnych znaków, co ma zwi¡zek z modykacjami standardu
code
zaistniaªymi w ostatnich latach. Wci¡» zalecane jest korzystanie z wersji
1.0
Uni-
wsz¦dzie,
gdzie jest to mo»liwe.
1
<?
xml version=" 1 . 0 "
e n c o d i n g="UTF−8" ?>
<k s i a z k a _ t e l e f o n i c z n a k a t e g o r i a=" b o h a t e r o w i e s e r i a l i ">
< !−−
komentarz
−−>
<osoba c h a r a k t e r=" dobry ">
<i m i e>P o r u c z n i k</ i m i e>
5
<nazwisko>Borewicz</ nazwisko>
< t e l e f o n>123 − 456 − 789</ t e l e f o n>
</ osoba>
<osoba c h a r a k t e r=" z ª y ">
<i m i e>A l o j z y</ i m i e>
10
<nazwisko>B¡bel</ nazwisko>
< t e l e f o n />
</ osoba>
</ k s i a z k a _ t e l e f o n i c z n a>
Wydruk 1: Przykªadowy kod XML
Na
powy»szym
wydruku
wida¢,
»e
korzeniem
dokumentu
jest
element
o
nazwie
ksi¡»ka_telefoniczna. Element ten ma atrybut o nazwie kategoria i warto±ci bohaterowie
seriali.
Korze« jest rodzicem dwóch innych elementów. Oba maj¡ t¡ sam¡ nazw¦
i przypisany atrybut o nazwie
charakter.
dla trzech innych elementów o nazwach
osoba
Ka»dy z elementów o nazwie osoba jest rodzicem
imi¦, nazwisko i telefon, które zawieraj¡ konkretne
dane w postaci w¦zªów tekstowych, czyli tekst zawarty pomi¦dzy odpowiednimi znacznikami
otwieraj¡cymi i zamykaj¡cymi. Element o nazwie
telefon w dwunastym wierszu dokumentu
jest pusty - nie ma »adnych potomków - a znacznik otwieraj¡cy jest jednocze±nie znacznikiem
zamykaj¡cym. Zapis
<telefon/> jest równoznaczny z zapisem <telefon></telefon>. z kolei
w trzecim wierszu zostaª przedstawiony przykªadowy komentarz.
4.2.1 Mechanizm XInclude
XInclude 4 [8] to mechanizm scalania dokumentów XML. Jest to mechanizm analogiczny do
mechanizmu zawierania (np.
Przykªad
zastosowania
include) wykorzystywanego przez wiele j¦zyków programowania.
mechanizmu
dokument XML zawiera element
XInclude
xi:include,
wida¢
na
wydruku
<?
xml version=" 1 . 0 " ?>
4
XML Inclusion
21
Przedstawiony
który wskazuje na zewn¦trzny dokument
(klauzula.xml)
1
2.
5
< t e l e f o n>123 − 456 − 789</ t e l e f o n>
< x i : i n c l u d e h r e f=k l a u z u l a .
</ osoba>
xml>
Wydruk 2: Przykªad zastosowania XInclude
Wydruk 3 przedstawia zawarto±¢ dokumentu klauzula.xml
1
<?
<k l a u z u l a>P r z e d s t a w i o n e dane n i e mog¡ by¢ wykorzystywane
w c e l a c h handlowych . Peªny t e k s t uregulowa« z a w i e r a ustawa
z d n i a 2 9 . 0 8 . 1 9 9 7 o~ o c h r o n i e danych osobowych
5
( Dz . U. nr 1 3 3 , poz . 8 3 3 )</ k l a u z u l a>
Wydruk 3: Zawarto±¢ dokumentu
klauzula.xml
Dokumentowi powstaªemu w wyniku rozwi¡zania zawierania opisanego w wydruku 2 odpowiada zawarto±¢ pliku XML przedstawiona na wydruku 4.
1
<?
5
< t e l e f o n>123 − 456 − 789</ t e l e f o n>
<k l a u z u l a>P r z e d s t a w i o n e dane n i e mog¡ by¢ wykorzystywane
w c e l a c h handlowych . Peªny t e k s t uregulowa« z a w i e r a ustawa
z d n i a 2 9 . 0 8 . 1 9 9 7 o~ o c h r o n i e danych osobowych
10
( Dz . U. nr 1 3 3 , poz . 8 3 3 )</ k l a u z u l a>
</ osoba>
Wydruk 4: Wynik zawierania
Na przytoczonym przykªadzie wida¢, »e mechanizm XInclude mo»e by¢ skutecznym narz¦-
dziem do organizacji i zarz¡dzania tre±ci¡ dokumentu XML. W niniejszej pracy zastosowanie
tego mechanizmu w znacznym stopniu wpªyn¦ªo na czytelno±¢ dokumentu zawieraj¡cego opis
zadania u»ytkowego. XInclude daje równie» mo»liwo±¢ wygodnego korzystania z istniej¡cych
ju» elementów przy tworzeniu nowych sterowników wedªug specykacji przyj¦tej w tej pracy
(szerzej jest to opisane w rozdziale 5)
4.3 DTD Denicja Typu Dokumentu
DTD (ang.
Document Type Denition ), czyli denicja typu dokumentu, jest to rodzaj do-
kumentu deniuj¡cy formaln¡ struktur¦ plików z rodziny SGML (np. HTML, XML, XHTML).
Denicje DTD mog¡ by¢ zawarte w pliku dokumentu, którego struktur¦ deniuj¡, zazwyczaj
22
jednak zapisane s¡ w osobnym pliku tekstowym, co pozwala na zastosowanie tego samego
DTD dla wielu dokumentów.
Za pomoc¡ DTD okre±lamy skªadni¦ konkretnej aplikacji XML lub SGML zdeniowanej
dla potrzeb u»ytkownika. DTD deniuje ka»dy dopuszczalny element dokumentu, jego zbiór
atrybutów i dopuszczalne warto±ci, okre±la tak»e zagnie»d»anie i wymagan¡ liczno±¢ poszczególnych elementów w dokumencie. W praktyce DTD przewa»nie skªada si¦ z denicji
i
ATTLIST,
ELEMENT
gdzie:
• ELEMENT
oznacza denicj¦ elementu,
• ATTLIST
oznacza denicj¦ atrybutu danego elementu.
Wydruk 5 przedstawia cz¦±¢ pliku denicji
fsautomat.dtd.
Plik ten zawiera zbiór reguª
i denicji, które dotycz¡ ka»dego zadania u»ytkowego zapisanego w postaci dokumentu XML
i obsªugiwanego przez mechanizm opisany w tej pracy. Na przedstawionym przykªadzie
mo»na zobaczy¢ sposób tworzenia pliku denicji DTD
ELEMENT T a s k D e s c r i p t i o n ( S t a t e +,SubTask ∗ )>
ELEMENT SubTask ( S t a t e +)>
<!
1
<!
ELEMENT
<!
S t a t e ( (ROBOT| SetOfRobots ) ? , ECPGeneratorType ? ,
T r a j e c t o r y F i l e P a t h ? , T r a j e c t o r y ? , t a s k I n i t ? , Speech ? , AddArg ? ,
5
S e n s o r ? , TimeSpan ? , G e n e r a t o r P a r a m e t e r s ? , Parameters ? , t r a n s i t i o n +)>
ATTLIST
< ! ATTLIST
<!
CDATA #REQUIRED>
type CDATA #REQUIRED>
State id
State
ELEMENT SetOfRobots
<!
10
( F i r s t S e t ? , S e c S e t ? )>
ELEMENT F i r s t S e t (ROBOT+)>
ELEMENT S e c S e t (ROBOT+)>
<!
<!
...
>
15
Wydruk 5: Zawarto±¢ pliku fsautomat.dtd
4.4 Biblioteka libxml
Libxml
jest darmow¡ bibliotek¡ do obsªugi dokumentów XML przy u»yciu j¦zyka C/C++.
Zostaªa napisana przez Daniela Vellard'a. Pierwotnie zostaªa stworzona dla ±rodowiska
GNOME, jednak aktualnie biblioteka jest dost¦pna dla wielu ±rodowisk programistycznych
i systemów operacyjnych (Linux, Unix, Windows, CygWin, MacOS, MacOS X, RISC Os,
OS/2, VMS, QNX, i wieleu innych).
Libxml
implementuje szereg istniej¡cych standardów powi¡zanych z j¦zykami znaczników:
•
the XML standard: http://www.w3.org/TR/REC-xml,
•
Namespaces in XML: http://www.w3.org/TR/REC-xml-names/,
23
•
XML Base: http://www.w3.org/TR/xmlbase/,
•
RFC 2396 : Uniform Resource Identiers http://www.ietf.org/rfc/rfc2396.txt,
•
XML Path Language (XPath) 1.0: http://www.w3.org/TR/xpath,
•
HTML4 parser: http://www.w3.org/TR/html401/,
•
XML Pointer Language (XPointer) Version 1.0: http://www.w3.org/TR/xptr,
•
XML Inclusions (XInclude) Version 1.0: http://www.w3.org/TR/xinclude/,
•
ISO-8859-x encodings, as well as rfc2044 [UTF-8] and rfc2781 [UTF-16] Unicode encodings, and more if using iconv support,
•
part of SGML Open Technical Resolution TR9401:1997,
•
XML
Catalogs
Working
Draft
06
August
2001:
http://www.oasis-
open.org/committees/entity/spec-2001-08-06.html,
•
Canonical XML Version 1.0: http://www.w3.org/TR/xml-c14n and the Exclusive XML
Canonicalization CR draft http://www.w3.org/TR/xml-exc-c14n,
•
Relax
NG,
ISO/IEC
19757-2:2003,
http://www.oasis-open.org/committees/relax-
ng/spec-20011203.html,
•
W3C XML Schemas Part 2: Datatypes REC 02 May 2001,
•
W3C xml:id Working Draft 7 April 2004.
Dodatkowym atutem stosowania
libxml 'a
jest mo»liwo±¢ korzystania nie tylko z parsera
XML, ale te» szeregu narz¦dzi wspomagaj¡cy prac¦ nad dokumentami w formacie XML.
Jednym z nich jest
xmllint,
który jest programem przeznaczonym do parsowania plików
XML. Jedn¡ z jego zalet, z punktu widzenia tej pracy, jest mo»liwo±¢ sprawdzania poprawno±ci
skªadniowej i strukturalnej (czyli zgodno±ci z denicj¡ dokumentu zawart¡ z pliku DTD)
dokumentu XML z zapisem zadania u»ytkowego. W efekcie ju» na etapie tworzenia nowego
sterownika mo»emy unikn¡¢ szeregu bª¦dów, które w tradycyjnym podej±ciu do tworzenia
zada« robotycznych, byªyby wychwytywane dopiero na etapie kompilacji ±rodowiska
MRROC++,
a nawet uruchamiania systemu steruj¡cego.
W przypadku sprawdzenia poprawno±ci dokumentu XML z denicj¡ zadania, stosuje si¦
zazwyczaj dwa ró»ne wywoªania programu
xmllint,
np.:
• xmllint -valid -noout data/pouring.xml
Jest to przykªadowe wywoªanie na rzecz dokumentu XML z zapisanym zadaniem nalewania -
pouring.xml.
-valid
Parametry wywoªania programu oznaczaj¡:
opcja walidacji dokumentu pod k¡tem sprawdzenia poprawno±ci skªa-
dniowej i strukturalnej,
24
-noout oznacza wybór trybu, w którym drzewo wynikowe dokumentu nie jest wy±wietlane na wyj±ciu programu. Dzi¦ki temu program wy±wietla jedynie informacje
o ewentualnych bª¦dach.
• xmllint -xinclude -postvalid -noout data/rcsc.xml
Jest to przykªadowe wywoªanie odnosz¡ce si¦ do dokumentu, w którym zastosowano
mechanizm
XInclude. W tym przypadku sprawdzeniu zostaje poddany dokument z za-
daniem ukªadania kostki Rubika -
rcsc.xml.
Parametry wywoªania oznaczaj¡:
-xinclude oznacza, »e przed walidacj¡ dokumentu zostanie wykonane wª¡czanie
elementów z plików, które maj¡ zosta¢ doª¡czone za pomoc¡ mechanizmu XInclude. W przypadku braku tej opcji sprawdzenie b¦dzie dotyczy¢ jedynie dokumentu
wskazanego w wywoªaniu programu, czyli bez wª¡czania elementów z plików zewn¦trznych.
-postvalid w przypadku wyboru tej opcji, walidacja odbywa si¦ po etapie parsowania dokumentu XML. Parametr ten jest wymagany w przypadku sprawdzania
poprawno±ci dokumentów wykorzystuj¡cych mechanizm XInclude.
25
5 Denicja j¦zyka opisu zada« w dokumencie XML
Jednym z celów niniejszej pracy byªo stworzenie j¦zyka opisu zada« wielorobotowych w notacji XML, zgodnego z denicj¡ automatu sko«czonego. W wyniku przeprowadzonych rozwa»a« powstaª j¦zyk znaczników sªu»¡cy do zapisu automatu sko«czonego, bazuj¡cy na formacie
XML. Efektem prac jest równie» zbiór denicji reguluj¡cych konstruowanie zadania w omawianej notacji.
Nale»y tutaj przypomnie¢, »e zdeniowany j¦zyk skupia si¦ na opisie automatu sko«czonego zgodnego z modelem Moore'a. Korzy±ci¡ wynikaj¡c¡ z przyj¦cia takiego zaªo»enia jest
fakt, »e akcje s¡ zwi¡zane jedynie ze stanami (a nie, jak jest to mo»liwe w automacie typu
Mealy'ego, z tranzycjami), co ma upraszcza¢ konstruowanie zadania u»ytkowego i zapis jego
denicji.
Wydruki 6 i 7 przedstawiaj¡ przykªadow¡ instrukcj¦ wykorzystywan¡ przy konstruowaniu
zadania u»ytkowego. Jest to zlecenie wykonania ruchu przez generator
wykorzystaniu robotów
ROBOT_IRP6_ON_TRACK
oraz
ECP_GEN_SMOOTH
ROBOT_IRP6_POSTUMENT.
przy
Na wydruku 6
przedstawiona jest posta¢ instrukcji stosowana w tradycyjnym podej±ciu do tworzenia sterownika i zawarta jest ona w kodzie programu. Natomiast wydruk 7 zawiera t¡ sam¡ instrukcj¦
zapisan¡ jako cz¦±¢ automatu sko«czonego w notacji XML.
1
if
( set_next_ecps_state ( (
int )
ECP_GEN_SMOOTH, 0 ,
int )
ECP_GEN_SMOOTH, 0 ,
" t r j / p o u r i n g / irp6_ot_ap . t r j " , 1 , ROBOT_IRP6_ON_TRACK) )
{
5
if
return true ;
}
" t r j / p o u r i n g / irp6_p_ap . t r j " , 1 , ROBOT_IRP6_POSTUMENT) )
{
return true ;
}
i f ( run_extended_empty_generator_for_set_of_robots_and_
10
wait_for_task_termination_message_of_another_set_of_robots
( 2 , 2 , ROBOT_IRP6_ON_TRACK, ROBOT_IRP6_POSTUMENT,
ROBOT_IRP6_ON_TRACK, ROBOT_IRP6_POSTUMENT) )
{
return true ;
}
Wydruk 6: Przykªadowa instrukcja ruchu zapisana w j¦zyku C++
1
<S t a t e i d=" approach_1 " type=" ru nG en er at or ">
<ROBOT>ROBOT_IRP6_ON_TRACK</ROBOT>
<ECPGeneratorType>ECP_GEN_SMOOTH</ ECPGeneratorType>
<T r a j e c t o r y F i l e P a t h> t r j / p o u r i n g / irp6_ot_ap . t r j</ T r a j e c t o r y F i l e P a t h>
5
<T r a j e c t o r y c o o r d i n a t e T y p e="JOINT" numOfPoses="1 ">
<Pose>
<S t a r t V e l o c i t y>0
<En dV el oc it y>0
0 0 0 0 0 0 0</ S t a r t V e l o c i t y>
0 0 0 0 0 0 0</ E nd Ve lo ci ty>
<V e l o c i t y>0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 0 5</ V e l o c i t y>
10
<A c c e l e r a t i o n s>0 . 1
<C o o r d i n a t e s>0
0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1</ A c c e l e r a t i o n s>
0 . 1 − 1.1
0 . 1 1 . 3 2 . 9 1 . 3 0 . 0</ C o o r d i n a t e s>
</ Pose>
26
</ T r a j e c t o r y>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" approach_2 " />
15
</ S t a t e>
<ROBOT>ROBOT_IRP6_POSTUMENT</ROBOT>
<T r a j e c t o r y F i l e P a t h> t r j / p o u r i n g / irp6_p_ap . t r j</ T r a j e c t o r y F i l e P a t h>
20
<Pose>
<En dV el oc it y>0
0 0 0 0 0 0 0</ S t a r t V e l o c i t y>
0 0 0 0 0 0 0</ E nd Ve lo ci ty>
<V e l o c i t y>0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 0 4
25
1</ V e l o c i t y>
0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1</ A c c e l e r a t i o n s>
<C o o r d i n a t e s> − 0.0 − 1.5
0 . 1 1 . 4 2 . 3 − 1.6
0 . 0 0</ C o o r d i n a t e s>
</ Pose>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" approach_end " />
30
</ S t a t e>
<S t a t e i d=" approach_end " type=" emptyGenForSet ">
<SetOfRobots>
<F i r s t S e t>
35
</ F i r s t S e t>
<S e c S e t>
40
</ S e c S e t>
</ SetOfRobots>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" grab_1 " />
</ S t a t e>
Wydruk 7: Przykªadowa instrukcja ruchu zapisana w XML'u
Na wydruku 7 mo»emy odnale¹¢ wszystkie konieczne elementy wykorzystywane do kon-
strukcji automatu sko«czonego. Znajdujemy tutaj stan opisany znacznikiem
równie» tranzycj¦, której odpowiednikiem jest znacznik
zamieszczon¡ pomi¦dzy znacznikami
<State>,
jak
<transition>, z kolei caªa zawarto±¢
<State></State>
jest zwi¡zana z wykonywan¡ akcj¡.
Na przedstawionym przykªadzie, w dwóch pierwszych stanach, deniowane s¡ pozycje dla poszczególnych robotów. Tak zapisana pozycja mo»e by¢ wczytana z pliku z trajektori¡
którego ±cie»ka jest zawarta w elemencie
z pliku XML, jako zawarto±¢ elementu
<TrajectoryFilePath>
.trj, do
lub wczytana bezpo±rednio
<Trajectory>.
W kolejnych podrozdziaªach zamieszczone s¡ opisy i specykacje elementów, które wykorzystywane s¡ przy konstruowaniu zadania u»ytkowego zgodnie z przyj¦t¡ denicj¡.
27
5.1 DTD denicji j¦zyka
Zadanie, któremu nale»aªo sprosta¢ przy tworzeniu j¦zyka opisu zada« u»ytkowych w dokumencie XML, byªo stworzenie denicji tego j¦zyka zgodnej z logik¡ automatu sko«czonego.
W tego typu denicji powinny si¦ znale¹¢ reguªy okre±laj¡ce elementy sªu»¡ce do budowania
maszyny stanowej, reguluj¡ce wymagan¡ liczno±¢ poszczególnych elementów oraz opisuj¡ce
relacje zachodz¡ce mi¦dzy elementami. Specykacja j¦zyka XML (a wªa±ciwie j¦zyka SGML,
z którego wywodzi si¦ XML) udost¦pnia wygodne narz¦dzie do konstruowania i opisywania
wy»ej wspomnianych reguª. Jest to Denicja Typu Dokumentu (DTD).
DTD
z
denicj¡
fsautomat.dtd,
gów systemu
j¦zyka
opisu
zada«
u»ytkowych
który znajduje si¦ w katalogu
MRROC++.
data
jest
przechowywana
w
pliku
mieszcz¡cego si¦ w strukturze katalo-
Mo»liwie jest równie» bezpo±rednie zawieranie denicji DTD w pliku
dokumentu XML, lecz jest to rozwi¡zanie zmniejszaj¡ce czytelno±¢ opisanego zadania. Podej±cie, w którym DTD jest przechowywane w jednym, wspólnym pliku tekstowym pozwala na
zastosowanie tego samego pliku denicji dla wielu dokumentów i wpªywa pozytywnie na spójno±¢ denicji j¦zyka. Dlatego te» wskazane jest zawierania DTD, tak jak jest to przedstawione
na wydruku 8.
1
<?
xml version=" 1 . 0 "
e n c o d i n g="UTF−8" ?>
DOCTYPE T a s k D e s c r i p t i o n SYSTEM " f s a u t o m a t . dtd "
<!
>
Wydruk 8: Przykªadowy nagªówek dokumentu z zapisem zadania
Wpis pojawiaj¡cy si¦ w linii trzeciej oznacza równie», »e korzeniem dokumentu XML
z zadaniem u»ytkowym jest element
<TaskDescription>.
5.2 Element <State>
Element
<State>
przechowuje reprezentacj¦ stanu. Jest podstawowym elementem sªu»¡-
cym do konstruowania automatu sko«czonego z zapisem zadania.
Poni»ej na wydruku 9 zamieszczony zostaª wpis z pliku
elementu
1
fsautomat.dtd
odnosz¡cy si¦ do
<State>.
ELEMENT T a s k D e s c r i p t i o n ( S t a t e +,SubTask ∗ )>
ELEMENT SubTask ( S t a t e +)>
<!
<!
ELEMENT
<!
S t a t e ( (ROBOT| SetOfRobots ) ? , ECPGeneratorType ? , T r a j e c t o r y F i l e P a t h ? ,
T r a j e c t o r y ? , t a s k I n i t ? , Speech ? , AddArg ? , S e n s o r ? , TimeSpan ? ,
5
ATTLIST
< ! ATTLIST
<!
G e n e r a t o r P a r a m e t e r s ? , Parameters ? , t r a n s i t i o n +)>
CDATA #REQUIRED>
type CDATA #REQUIRED>
State id
State
<State>
w pliku DTD
korzeniem
dokumentu
Wydruk 9: Element
Jak
ju»
wcze±niej
<TaskDescription>.
nadmieniono,
Potomkami
tego
elementu
28
s¡
w¦zªy
XML
<State>
oraz
jest
element
<SubTask>
co
jest opisane w pierwszej linii wydruku 9. Symbole
*
i
+
(co najmniej jeden),
?
(jeden lub »aden)
(zero lub wiele) wyznaczaj¡ wymagan¡ liczno±¢ elementów. Brak okre±lonego symbolu
oznacza, »e element musi pojawi¢ si¦ dokªadnie jeden raz. Kolejne linie wydruku oznaczaj¡:
•
<TaskDescription>
linia nr 1 oznacza, »e w¦zeª
mo»e zawiera¢ dwa typy elementów:
co najmniej jeden element<State> oraz zero lub wiele elementów
•
linia nr 2 oznacza, »e w¦zeª
<SubTask>
<SubTask>,
jest rodzicem jednego lub wielu elementów
<State>,
•
linie od 4 do 6 okre±laj¡ wszystkie elementy, które s¡ dzie¢mi elementu
•
linie 7 i 8 oznaczaj¡, »e element
id
oraz
type
<State>,
<State> posiada dwa obowi¡zkowe atrybuty o nazwach
(szerzej opisane w kolejnym podrozdziale 5.2.1).
5.2.1 Szczegóªy atrybutów
W tabeli 2 przedstawione zostaªy atrybuty elementu
Nazwa Wymagany
id
Typ
TAK
<State>.
Warto±¢
domy±lna
ID
brak
Opis
Identykator
aktualnego
stanu.
Musi by¢ unikalny w obr¦bie caªego dokumentu
type
TAK
NMTOKEN
brak
Nazwa
okre±laj¡ca
typ
stanu.
Musi mie¢ warto±¢ zgodn¡ z jednym z przyj¦tych typów stanów
Tablica 2: Szczegóªy atrybutów elementu
Atrybut
id
elementu
<State>,
<State>
jest unikalnym w obr¦bie caªego dokumentu identyka-
torem konkretnego stanu. Deniuj¡c j¦zyk przyj¦to, »e stanem pocz¡tkowym automatu jest
stan, którego
1
id
ma warto±¢
INIT,
np.:
<S t a t e i d="INIT" type=" s y s t e m I n i t i a l i z a t i o n ">
W ogólnym przypadku jest to stan zwi¡zany z inicjalizacj¡ systemu
MRROC++,
aby mo»liwe
byªo wykonanie zadania zawartego w dokumencie XML. Przy takich zaªo»eniach stanem pocz¡tkowym automatu jest zawsze stan o
id=INIT
Nale»y te» tutaj nadmieni¢, »e atrybut
• _STOP_
id
i typie
type=systemInitialization.
stanu nie mo»e przyjmowa¢ warto±ci:
jest to warto±¢ przypisana jako cel (target) tranzycji (transition) w mo-
mencie, kiedy automat sko«czony wychodzi z cyklu pracy (przechodzi w stan
• _END_
_STOP_),
jest to warto±¢ przypisana jako cel tranzycji i oznacza zako«czenie wykony-
wania podzadania (SubTask). W praktyce oznacza zlecenie zdj¦cia ze stosu
docelowego.
29
id
stanu
Z kolei atrybut
ksztaªt elementu
type
mo»e przyjmowa¢ jedn¡ z warto±ci, która ma decyduj¡cy wpªyw na
<State>:
• systemInitialization
MRROC++.
1
oznacza, »e akcja stanu jest zwi¡zana z inicjalizacj¡ systemu
Tylko typ stanu
INIT
ma przypisan¡ tak¡ warto±¢. Przykªad stanu:
<t a s k I n i t>
<ecp name="ROBOT_IRP6_ON_TRACK">
<ecp_tool_change_gen>1</ ecp_tool_change_gen>
5
<ecp_smooth_gen>1</ecp_smooth_gen>
<ecp_sub_task_gripper_opening></ ecp_sub_task_gripper_opening>
</ ecp>
<ecp name="ROBOT_IRP6_POSTUMENT">
10
</ ecp>
</ t a s k I n i t>
</ S t a t e>
• runGenerator
oznacza, »e akcja stanu wi¡»e si¦ z uruchomieniem konkretnego gene-
ratora trajektorii. Typowy przykªad stanu:
1
5
<Pose>
<En dV el oc it y>0
0 0 0 0 0 0 0</ S t a r t V e l o c i t y>
0 0 0 0 0 0 0</ E nd Ve lo ci ty>
10
0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1</ A c c e l e r a t i o n s>
0 − 1.16 0 1 . 3 6
2.93
1.37
0 . 0 8</ C o o r d i n a t e s>
</ Pose>
15
</ S t a t e>
• emptyGenForSet
oznacza, »e akcja stanu jest zwi¡zana z uruchomieniem pustego ge-
neratora dla jednego zestawu robotów i oczekiwaniem na zako«czenie zadania wykonywanego przez inny zestaw robotów. Przykªad stanu:
1
<SetOfRobots>
<F i r s t S e t>
5
30
</ F i r s t S e t>
<S e c S e t>
</ S e c S e t>
10
</ SetOfRobots>
</ S t a t e>
• emptyGen
oznacza, »e akcja stanu jest zwi¡zana z uruchomieniem pustego generatora.
Przykªad stanu:
1
<S t a t e i d=" approach_7 " type="emptyGen">
<AddArg>1</AddArg>
5
</ S t a t e>
• wait
oznacza, »e akcja stanu jest zwi¡zana z uruchomieniem generatora zatrzymuj¡-
cego wykonywanie zadania na dany kwant czasu. Przykªad stanu:
1
<S t a t e i d=" approach_27 " type=" w a i t ">
<TimeSpan>500</TimeSpan>
</ S t a t e>
• stopGen
oznacza, »e akcja stanu polega na zatrzymaniu wykonywania ruchu danego
robota lub zestawu robotów. Przykªad stanu:
1
<S t a t e i d=" approach_8 " type=" stopGen ">
<SetOfRobots>
<F i r s t S e t>
5
</ F i r s t S e t>
</ SetOfRobots>
</ S t a t e>
• cubeStateInit
oznacza, »e akcja stanu polega na inicjalizacji programowego odpo-
wiednika kostki rubika. Przykªad stanu:
1
<S t a t e i d=" i d e n t i f y _ c o l o r s _ 1 " type=" c u b e S t a t e I n i t ">
<Parameters>BLUE
GREEN RED ORANGE WHITE YELLOW</ Parameters>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" ica_1>>i d e n t i f y _ c o l o r s _ 2 " />
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t="_STOP_" />
5
</ S t a t e>
31
• initiateSensorReading
oznacza, »e akcja stanu polega na inicjowaniu odczytów
z konkretnego sensora. Przykªad stanu:
1
<S t a t e i d=" ica_5 " type=" i n i t i a t e S e n s o r R e a d i n g ">
<S e n s o r>SENSOR_CAMERA_ON_TRACK</ S e n s o r>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" ica_6 " />
</ S t a t e>
• getSensorReading
oznacza, »e akcja stanu polega na pobraniu odczytów z konkret-
nego sensora. Przykªad stanu:
1
<S t a t e i d=" ica_7 " type=" g e t S e n s o r R e a d i n g ">
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t="_END_" />
</ S t a t e>
• cubeStateWriting
oznacza, »e akcja stanu polega na zapisaniu aktualnego stanu
kostki Rubika. Przykªad stanu:
1
<S t a t e i d=" i d e n t i f y _ c o l o r s _ 1 4 " type=" c u b e S t a t e W r i t i n g ">
<AddArg>4</AddArg>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" i d e n t i f y _ c o l o r s _ 1 5 "/>
5
</ S t a t e>
• cubeStateChange
oznacza, »e akcja stanu polega na zmianie aktualnego stanu kostki
Rubika, a wªa±ciwie obiektu reprezentuj¡cego kostk¦. Przykªad stanu:
1
<S t a t e i d="fco_CL_180_26" type=" cubeStateChange ">
<AddArg>180</AddArg>
</ S t a t e>
• communicateWithSolver
oznacza, »e akcja stanu polega na komunikacji z solwerem
odpowiedzialnym za wyznaczenie sekwencji ruchów ukªadaj¡cych kostk¦ Rubika. Przykªad stanu:
1
<S t a t e i d="communicate_wws_3" type=" communicateWithSolver ">
< t r a n s i t i o n c o n d i t i o n=" s t a t e O p e r a t i o n R e s u l t " t a r g e t="communicate_wws_4" />
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t="depop_1" />
</ S t a t e>
• manipulationSeqTranslation
oznacza, »e akcja stanu polega na przetworzeniu se-
kwencji ruchów otrzymanych z solwera, do postaci zrozumiaªej przez interpreter automatu sko«czonego. Przykªad stanu:
32
1
<S t a t e i d="man_4" type=" m a n i p u l a t i o n S e q T r a n s l a t i o n ">
</ S t a t e>
• intermediateState
oznacza, »e stan aktualny jest stanem po±rednim, w którym nie
jest wykonywana »adna akcja. Zazwyczaj taka konstrukcja jest wykorzystywana w przypadku delegowania wykonania podzada«. Przykªad stanu:
1
<S t a t e i d="man_1" type=" i n t e r m e d i a t e S t a t e ">
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t="fto_CL_0_1>>man_2" />
</ S t a t e>
5.2.2 Potomkowie elementu <State>
Element
<State>
jest rodzicem nast¦puj¡cych elementów:
• <ROBOT> opcjonalny element przechowuj¡cy nazw¦ robota z którym zwi¡zana jest akcja
zawarta w aktualnym stanie. Pojawia si¦ najwy»ej jeden raz, zamiennie z elementem
<SetOfRobots>.
• <SetOfRobots>
Zobacz 5.4
opcjonalny element zawieraj¡cy dwa zbiory nazw robotów, z którymi
zwi¡zana jest akcja. Pojawia si¦ najwy»ej jeden raz, zamiennie z elementem
<ROBOT>.
Zobacz 5.5
• <ECPGeneratorType>
- opcjonalny element zawieraj¡cy nazw¦ generatora, który jest
wykorzystany do wyznaczenia trajektorii je»eli taka akcja jest zwi¡zana z danym stanem.
Pojawia si¦ najwy»ej jeden raz. Zobacz 5.6
• <GeneratorFilePath>
opcjonalny element zawieraj¡cy ±cie»k¦ do pliku
.trj
z tra-
jektori¡. Pojawia si¦ najwy»ej jeden raz. Zobacz 5.7
• <Trajectory> opcjonalny element przechowuj¡cy informacje o trajektorii. Pojawia si¦
najwy»ej jeden raz. Zobacz 5.16
• <taskInit> opcjonalny element zawieraj¡cy sekcj¦ inicjalizuj¡c¡. Pojawia si¦ najwy»ej
jeden raz. Zobacz 5.8
• <Speech>
opcjonalny element przechowuj¡cy tekst b¦d¡cy argumentem dla robota
ROBOT_FESTIVAL.
• <AddArg>
Pojawia si¦ najwy»ej jeden raz. Zobacz 5.9
opcjonalny element przechowuj¡cy warto±¢ b¦d¡c¡ dodatkowym argumen-
tem zwi¡zanym z akcj¡, która zawarta jest w stanie. Pojawia si¦ najwy»ej jeden raz.
Zobacz 5.10
• <Sensor>
opcjonalny element przechowuj¡cy nazw¦ sensora. Pojawia si¦ najwy»ej
jeden raz. Zobacz 5.11
33
• <TimeSpan>
typu
opcjonalny element przechowuj¡cy warto±¢ b¦d¡c¡ argumentem dla akcji
wait. Pojawia si¦ najwy»ej jeden raz. Zobacz 5.12
• <GeneratorParameters>
opcjonalny element przechowuj¡cy argumenty wywoªania
konkretnego generatora. Pojawia si¦ najwy»ej jeden raz. Zobacz 5.13
• <Parameters>
opcjonalny element przechowuj¡cy dodatkowe parametry nie uwzgl¦d-
nione w innych elementach. Pojawia si¦ najwy»ej jeden raz. Zobacz 5.14
• <transition>
deniuje wychodz¡c¡ z aktualnego stanu tranzycj¦. Pojawia si¦ co
najmniej jeden raz. Zobacz 5.15
5.3 Element <SubTask>
Element
(np. plik
<SubTask>
jest korzeniem dokumentu XML zawieraj¡cego denicj¦ podzadania
faceChangeOperations.xml).
W nast¦pstwie scalenia dokumentu XML zawieraj¡-
cego denicj¦ zadania u»ytkowego przy wykorzystaniu mechanizmu
tem potomkiem korzenia dokumentu
elementy
XInclude, staje si¦ elemen-
<TaskDescrition>. Potomkami elementu <SubTask> s¡
<State>.
Wpisy w denicji typu dokumentu DTD dotycz¡ce elementu
<SubTask>
umieszczone s¡
na wydruku 9 w liniach 1 i 2.
Charakterystyczn¡ cech¡ podzadania
zawiera tranzycj¦
transition
SubTask
której atrybut
jest fakt, »e stan wyj±ciowy z podzadania
target
przyjmuje warto±¢
_END_.
Oznacza to
zako«czenie wykonywania podzadania i wymusza zdj¦cie nazwy stanu docelowego ze stosu
automatu sko«czonego.
5.4 Element <ROBOT>
<ROBOT>
jest elementem przechowuj¡cym nazw¦ robota z którym zwi¡zana jest akcja za-
warta z aktualnym stanie. Mo»e przyjmowa¢ warto±ci odpowiadaj¡ce nazwom robotów, które
s¡ zdeniowane w systemie
MRROC++.
Na t¡ chwil¦ s¡ to:
• ROBOT_UNDEFINED
• ROBOT_IRP6_ON_TRACK
• ROBOT_IRP6_POSTUMENT
• ROBOT_FESTIVAL
• ROBOT_CONVEYOR
• ROBOT_SPEAKER
• ROBOT_IRP6_MECHATRONIKA
• ROBOT_ELECTRON
34
• ROBOT_HAND
• ROBOT_SPEECHRECOGNITION
Nale»y tutaj nadmieni¢, »e w obecnym ksztaªcie mechanizmu realizuj¡cego zadanie u»ytkowe, poprawnie obsªu»one zostan¡ pierwsze cztery roboty wymienione na powy»szej li±cie.
W momencie tworzenia przyj¦tego rozwi¡zania nie byªo konieczno±ci tworzenia procesów
ECP
pozostaªych robotów. Jednak implementacja brakuj¡cych procesów nie powinna przysparza¢
problemów, gdy» ich tworzenie b¦dzie analogiczne do istniej¡cych
maganej funkcjonalno±ci jest zawarta w klasie bazowej
ecp_task.
Poni»ej na wydruku 10 zamieszczony zostaª wpis z pliku
elementu
9
10
<ROBOT>.
ECP. Dodatkowo cz¦±¢ wy-
fsautomat.dtd odnosz¡cy si¦ do
Znajduje si¦ w linii 14.
ELEMENT SetOfRobots
<!
( F i r s t S e t ? , S e c S e t ? )>
ELEMENT F i r s t S e t (ROBOT+)>
ELEMENT S e c S e t (ROBOT+)>
<!
<!
ELEMENT ROBOT (#PCDATA)>
<!
Wydruk 10: Elementy
Przykªadowy zapis elementu
<State>
<ROBOT>
oraz
<SetOfRobots>
w pliku DTD
odpowiadaj¡cy manipulatorowi
IR6 on track
wy-
gl¡da nast¦puj¡co:
1
5.5 Element <SetOfRobots>
Element
<SetOfRobots>
wieraj¡cych elementy typu
fsautomat.dtd
jest rodzicem dwóch zbiorów
<ROBOT>.
<FirstSet>
Wpis dotycz¡cy elementu
<FirstSet> i <SecSet>
wy»ej jeden raz. Ich potomkami s¡ elementy
<SetOfRobots>
pojawia si¦ w elemencie
<ROBOT>
Przykªadowe u»ycie elementu
<SetOfRobots>
<SetOfRobots>
<F i r s t S e t>
<ROBOT>ROBOT_FESTIVAL</ROBOT>
</ F i r s t S e t>
<S e c S e t>
10
za-
w pliku
</ S e c S e t>
</ SetOfRobots>
35
<SetOfRobots>
naj-
i pojawiaj¡ si¦ co najmniej jeden raz
w aktualnym zbiorze.
5
<SecSet>
znajduje si¦ w liniach 9-12 wydruku 10.
Ka»dy z elementów
1
oraz
wygl¡da nast¦puj¡co:
5.6 Element <ECPGeneratorType>
Element
<ECPGeneratorType>
zawiera nazw¦ generatora wykorzystywanego do wyzna-
czenia trajektorii. Mo»e przyjmowa¢ jedn¡ z warto±ci, która zdeniowana jest w strukturze
MRROC++
i odnosi si¦ do konkretnego generatora trajektorii:
• ECP_GEN_TRANSPARENT
oznacza u»ycie generatora transparentnego
• ECP_GEN_TFF_NOSE_RUN
• ECP_GEN_TEACH_IN
• ECP_GEN_SMOOTH
oznacza generator
oznacza generator
oznacza generator
• ECP_GEN_TFF_RUBIK_GRAB
ecp_generator_t
ecp_tff_nose_run_generator
ecp_teach_in_generator
oznacza generator
ecp_tff_rubik_grab_generator,
• ECP_GEN_TFF_RUBIK_FACE_ROTATE oznacza gen. ecp_tff_rubik_face_rotate_generator
• ECP_GEN_TFF_GRIPPER_APPROACH oznacza gen. ecp_tff_gripper_approach_generator
• RCSC_GRIPPER_OPENING
• ECP_GEN_FESTIVAL
oznacza generator
oznacza generator
• ECP_GEN_BIAS_EDP_FORCE
• ECP_TOOL_CHANGE_GENERATOR
przedstawiony
jest
festival_generator
oznacza generator
• ECP_WEIGHT_MEASURE_GENERATOR
Poni»ej
ecp_sub_task_gripper_opening
wpis
bias_edp_force_generator
oznacza generator
oznacza generator
w
weight_meassure_generator
ecp_tool_change_generator
fsautomat.dtd
pliku
odnosz¡cy
si¦
do
elementu
<ECPGeneratorType>
1
ELEMENT ECPGeneratorType (#PCDATA)>
<!
Nast¦pny wydruk ilustruje przykªad u»ycia omawianego elementu w kodzie dokumentu XML:
1
5.7 Element <GeneratorFilePath>
Element
<GeneratorFilePath> zawiera ±cie»k¦ do pliku z trajektori¡ (plik z rozszerzeniem
.trj)wykorzystywan¡
przez generator
ecp_smooth_generator.
korzystywana jest w zale»no±ci konguracji zawartej w pliku
Wpis w pliku
1
fsautomat.dtd
ELEMENT
<!
odnosz¡cy si¦ do elementu
Zawarto±¢ elementu jest wy-
fsautomat.ini
6.3
<GeneratorFilePath>:
PCDATA)>
T r a j e c t o r y F i l e P a t h (#
Wydruk ilustruj¡cy przykªad u»ycia omawianego elementu w kodzie dokumentu XML:
1
<T r a j e c t o r y F i l e P a t h> t r j / r c s c /irp6ot_sm_ap_2 . t r j</ T r a j e c t o r y F i l e P a t h>
36
5.8 Element <taskInit>
Element
<taskInit>
zawiera informacj¦ dotycz¡c¡ inicjalizacji ±rodowiska, która jest ko-
nieczna do wykonania zadania u»ytkowego. Element ten wyst¦puje jedynie w stanie pocz¡tkowym maszyny stanowej, gdzie
id="INIT"
i
type=systemInitialization
stanem odpowiedzialnym za inicjalizacj¦ wskazanych elementów struktury
Poni»szy wydruk 11 przedstawia cz¦±¢ zawarto±ci pliku
elementu
1
i który jest
MRROC++.
fsautomat.dtd
odnosz¡c¡ si¦ do
<taskInit>
ELEMENT t a s k I n i t ( ecp +,mp? )>
< !ELEMENT \ECP\ ( ecp_gen_t ? , ecp_tool_change_gen ? , ecp_tff_nose_run_gen ? ,
<!
ecp_tff_rubik_grab_gen ? , ecp_tff_gripper_approach_gen ? ,
ecp_tff_rubik_face_rotate_gen ? , ecp_teach_in_gen ? , bias_edp_force_gen ? ,
ecp_smooth_gen ? , weight_meassure_gen ? , ecp_sub_task_gripper_opening ? )>
5
ATTLIST \ECP\ name CDATA #REQUIRED>
ELEMENT ecp_gen_t (#PCDATA)>
< !ELEMENT ecp_tool_change_gen (#PCDATA)>
< !ELEMENT ecp_tff_nose_run_gen (#PCDATA)>
< !ELEMENT ecp_tff_rubik_grab_gen (#PCDATA)>
< !ELEMENT ecp_tff_gripper_approach_gen (#PCDATA)>
< !ELEMENT ecp_tff_rubik_face_rotate_gen (#PCDATA)>
< !ELEMENT ecp_teach_in_gen (#PCDATA)>
< !ELEMENT bias_edp_force_gen (#PCDATA)>
< !ELEMENT ecp_smooth_gen (#PCDATA)>
< !ELEMENT weight_meassure_gen (#PCDATA)>
< !ELEMENT ecp_sub_task_gripper_opening (#PCDATA)>
<!
<!
10
15
ELEMENT \MP\ ( c u b e _ s t a t e ? , S e n s o r ∗ , T r a n s m i t t e r ? )>
< !ELEMENT c u b e _ s t a t e (#PCDATA)>
< !ELEMENT T r a n s m i t t e r (#PCDATA)>
< !ELEMENT S e n s o r (#PCDATA)>
<!
20
Wydruk 11: Element
<taskInit>
w pliku DTD
Element
<taskInit>
• <ecp>
obowi¡zkowy element zawieraj¡cy elementy b¦d¡ce odpowiednikami obiektów,
jest rodzicem nast¦puj¡cych elementów:
które maj¡ by¢ powoªane po stronie konkretnego
ECP.
Pojawia si¦ co najmniej jeden
raz. Zobacz 5.8.1
• <mp>
opcjonalny element przechowuj¡cy informacj¦ o obiektach, które maj¡ by¢ po-
woªane na poziomie
MP. Pojawia si¦ najwy»ej jeden raz. Zobacz 5.8.2
Na wydruku 12 przedstawiono przykªadowy stan zawieraj¡cy element
1
<t a s k I n i t>
<ecp_gen_t></ ecp_gen_t>
5
<ecp_tff_nose_run_gen>8</ ecp_tff_nose_run_gen>
37
<taskInit>.
<ecp_tff_rubik_grab_gen>8</ ecp_tff_rubik_grab_gen>
<ecp_tff_gripper_approach_gen>8</ ecp_tff_gripper_approach_gen>
<ecp_tff_rubik_face_rotate_gen>8</ ecp_tff_rubik_face_rotate_gen>
<ecp_teach_in_gen></ ecp_teach_in_gen>
<bias_edp_force_gen></ bias_edp_force_gen>
10
<weight_meassure_gen>1</ weight_meassure_gen>
</ ecp>
15
20
25
</ ecp>
<mp>
<c u b e _ s t a t e></ c u b e _ s t a t e>
<S e n s o r>SENSOR_CAMERA_SA</ S e n s o r>
<T r a n s m i t t e r>TRANSMITTER_RC_WINDOWS</ T r a n s m i t t e r>
30
</mp>
</ t a s k I n i t>
</ S t a t e>
Wydruk 12: Przykªadowy stan zawierajacy element
<taskInit>
5.8.1 Element <ecp>
<ecp>
jest elementem przechowuj¡cym elementy odpowiadaj¡ce obiektom powoªanym po
stronie konkretnego procesu
ECP, okre±lanego na podstawie atrybutu name. Szczegóªy atry-
butu zostaªy opisane w tabeli 3
Atrybut
name mo»e przyjmowa¢ warto±ci odpowiadaj¡ce nazwom robotów zdeniowanych
w strukturze
MRROC++:
• ROBOT_UNDEFINED
• ROBOT_IRP6_ON_TRACK
• ROBOT_IRP6_POSTUMENT
• ROBOT_FESTIVAL
• ROBOT_CONVEYOR
38
Nazwa Wymagany
name
Typ
TAK
Warto±¢
domy±lna
NMTOKEN
brak
Opis
Warto±¢
odpowiadaj¡c¡
nazwie
robota. Jest stosowana, aby okre±li¢ na poziomie
ECP którego ro-
bota maj¡ by¢ powoªane obiekty
odpowiadaj¡ce elementom zawartym w
<ecp>
<ecp>
• ROBOT_SPEAKER
• ROBOT_IRP6_MECHATRONIKA
• ROBOT_ELECTRON
• ROBOT_HAND
• ROBOT_SPEECHRECOGNITION
Ograniczenia odnosz¡ce si¦ do tego atrybutu, s¡ analogiczne do ogranicze« zwi¡zanych
z zawarto±ci¡ elementu
<ecp>
<ROBOT>
(rozdziaª 5.4).
jest rodzicem elementów przedstawionych w poni»szym zestawieniu. S¡ one odpo-
wiednikami obiektów o nazwach analogicznych do nazw tych elementów, które powoªywane
s¡ na poziomie
ECP.
• <ecp_gen_t>
pojawia si¦ najwy»ej jeden raz,
• <ecp_tool_change_gen>
• <ecp_tff_nose_run_gen>
• <ecp_tff_rubik_grab_gen>
• <ecp_tff_gripper_approach_gen>
• <ecp_tff_rubik_face_rotate_gen>
• <ecp_teach_in_gen>
• <bias_edp_force_gen>
• <ecp_smooth_gen>
• <weight_meassure_gen>
• <ecp_sub_task_gripper_opening>
pojawia si¦ najwy»ej jeden raz.
39
Pojawienie si¦ w sekcji
»e na poziomie
<ecp>
jakiegokolwiek z wy»ej wymienionych elementów oznacza,
ECP robota wymienionego w atrybucie name ma by¢ powoªany do »ycia obiekt
odpowiadaj¡cy danemu elementowi. Je»eli taki element dodatkowo zawiera warto±¢, oznacza
to, »e warto±¢ ta ma by¢ przekazana do konstruktora danego elementu.
1
5
</ ecp>
W
powy»szym
wsta¢
maj¡
przykªadzie
obiekty
na
poziomie
ecp_irp6ot_fsautomat
procesu
ecp_tool_change_generator,
ecp_sub_task_gripper_opening,
przy
czym
do
konstruktorów
dwóch
neratorów przekazana zostanie warto±¢ 1 (rzutowana na warto±¢ logiczn¡
Przykªadowe u»ycie elementu
<ecp>
pooraz
pierwszych
ge-
true).
zawiera wydruk 12.
5.8.2 Element <mp>
Element
<mp>
jest dzieckiem elementu
<taskInit>
i zawiera informacje, które s¡ wyko-
rzystywane do inicjalizacji obiektów na poziomie procesu
MP. Pojawia si¦ najwy»ej jeden raz,
w zale»no±ci, czy powoªanie konkretnych obiektów jest wymagane w danym typie zadania
u»ytkowego.
<mp> jest rodzicem poni»szych elementów. S¡ one odpowiednikiem obiektów powoªywanych
na poziomie MP
• <cube_state>
element odpowiadaj¡cy obiektowi
CubeState.
Pojawia si¦ najwy»ej
sensor_m.
Pojawia si¦ wiele razy
jeden raz,
• <Sensor>
element zawieraj¡cy konguracj¦ obiektu
lub wcale,
• <Transmitter> element zawieraj¡cy konguracj¦ obiektu transmitter_m. Pojawia si¦
najwy»ej jeden raz.
Wpis w pliku
fsautomat.dtd
odpowiadaj¡cy elementowi
<mp>
jest przedstawiony na wy-
druku 11 w liniach 19-22. Poni»ej jest zamieszczony przykªad ilustruj¡cy u»ycie elementu
<mp>
w dokumencie XML:
1
<mp>
5
</mp>
Przedstawiony
ªany
zostaje
wydruk
obiekt
oznacza,
CubeState
»e
oraz
na
etapie
inicjalizacji
inicjalizowane
40
s¡
w
obiekty
procesie
sensor_m,
MP
powo-
takie
jak
SENSOR_CAMERA_ON_TRACK
i
SENSOR_CAMERA_SA
oraz
obiekt
transmitter_m
o
nazwie
TRANSMITTER_RC_WINDOWS
5.9 Element <Speech>
<Speech>
przechowuje tekst, który jest wypowiadany przez robota
czyli przechowuje argument wywoªania generatora
w tych stanach
<State>,
ECP_GEN_FESTIVAL.
ROBOT_FESTIVAL,
Pojawia si¦ jedynie
gdzie ma by¢ u»yty wymieniony robot i generator.
Poni»ej przedstawiony jest przykªadowy stan, w którym jest zawarty element
1
<Speech>
<S t a t e i d=" approach_15 " type=" r un Ge ne ra to r ">
<ECPGeneratorType>ECP_GEN_FESTIVAL</ ECPGeneratorType>
<Speech>j e s t e m robotem u s l /ugowym</ Speech>
5
</ S t a t e>
5.10 Element <AddArg>
Element
<AddArg> przechowuje dodatkowe dane numeryczne konieczne do wykonania akcji
zwi¡zanej ze stanem, który zawiera ten element. W zale»no±ci od typu stanu, w którym zostaª
zapisany mo»e oznacza¢:
•
stan,
gdzie
chowywana
type=runGenerator
przez
<AddArg>
set_next_ecps_state(),
jest
oznacza,
»e
przekazywana
warto±¢
jako
drugi
numeryczna
argument
prze-
metody
którego warto±¢ domy±lna w przyj¦tej implementacji wynosi
0. Poni»ej przykªad u»ycia w omawianym kontek±cie:
1
<ECPGeneratorType>ECP_GEN_TRANSPARENT</ ECPGeneratorType>
<Speech>j e s t e m podatny</ Speech>
5
<AddArg>1</AddArg>
</ S t a t e>
•
stan gdzie
type=emptyGen
<AddArg>,
jest przekazywana jako pierwszy argument metody
oznacza, »e warto±¢ numeryczna przechowywana przez
run_ext_empty_gen(),
którego warto±¢ domy±lna, podobnie jak wcze±niej, wynosi 0. Poni»ej przykªad u»ycia
w omawianym kontek±cie:
1
<S t a t e i d=" approach_7 " type="emptyGen">
<AddArg>1</AddArg>
5
</ S t a t e>
41
•
stan gdzie
type=cubeStateWriting
sªu»y do identykacji ±cianki kostki Rubika,
która jest aktualnie zapisywana. Poni»ej przykªad u»ycia w omawianym kontek±cie:
1
<S t a t e i d=" i d e n t i f y _ c o l o r s _ 2 " type=" c u b e S t a t e W r i t i n g ">
<AddArg>0</AddArg>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" i d e n t i f y _ c o l o r s _ 3 " />
5
</ S t a t e>
5.11 Element <Sensor>
Element
<Sensor> przechowuj¦ nazw¦ czujnika, którego nazwa jest wykorzystywana w ak-
cji zwi¡zanej ze stanem, w którym dany element jest zawarty. Poni»ej przykªad ilustruj¡cy
u»ycie el.
1
<Sensor>:
</ S t a t e>
5.12 Element <TimeSpan>
Element
<TimeSpan>
zawiera warto±¢ numeryczn¡, która wyra»a liczb¦ milisekund. War-
to±¢ ta jest przekazywana jako argument wywoªania generatora zatrzymuj¡cego dziaªanie
systemu
MRROC++
o wskazany kwant czasu. Poni»ej zamieszczony jest przykªad ilustruj¡cy
wykorzystanie elementu
1
<TimeSpan>:
<S t a t e i d=" ica_6 " type=" w a i t ">
</ S t a t e>
5.13 Element <GeneratorParameters>
GeneratorParameters
jest elementem przechowuj¡cym dodatkowe dane, które s¡ wyko-
rzystywane jako parametr przy wykonywaniu ruchu przez wskazany generator na poziomie
procesu
ECP. Mo»e zawiera¢ kilka argumentów, które oddzielone s¡ mi¦dzy sob¡ separatorem.
Przyj¦to, »e separatorem tym jest znak tabulacji. Poni»ej zamieszczono wydruk ilustruj¡cy
u»ycie tego elementu:
1
<S t a t e i d=" approach_28 " type=" r un Ge ne ra to r ">
<ECPGeneratorType>ECP_GEN_TFF_RUBIK_GRAB</ ECPGeneratorType>
<G e n e r a t o r P a r a m e t e r s>0 . 0 5 7
5
0 . 0 0 0 0 5 0</ G e n e r a t o r P a r a m e t e r s>
</ S t a t e>
42
Powy»szy stan skutkuje wykonaniem nast¦puj¡cego kodu na poziomie procesu ECP:
rgg −>c o n f i g u r e ( 0 . 0 5 7 , 0 . 0 0 0 0 5 , 0 ) ;
1
rgg −>Move ( ) ;
, gdzie
rgg
oznacza generator
ecp_tff_rubik_grab_generator
5.14 Element <Parameters>
Element
<Parameters>
zawiera dodatkowe parametry wykorzystywane w wykonywaniu
akcji zwi¡zanej z aktualnym stanem. Mo»e przechowywa¢ kilka argumentów, które oddzielone s¡ mi¦dzy sob¡ separatorem, którym jest znak tabulacji. Poni»y wydruk ilustruje u»ycie
opisywanego elementu
1
<Parameters>:
<S t a t e i d=" i d e n t i f y _ c o l o r s _ 1 " type=" c u b e S t a t e I n i t ">
<Parameters>BLUE
GREEN RED ORANGE WHITE YELLOW</ Parameters>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" ica_1>>i d e n t i f y _ c o l o r s _ 2 " />
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t="_STOP_" />
5
</ S t a t e>
Jak
wida¢
na
<Parameters>,
przedstawionym
przykªadzie,
parametry
przechowywane
przez
element
u»ywane s¡ do inicjalizacji stanu kostki Rubika.
5.15 Element <transition>
Element
<transition> przechowuje reprezentacj¦ tranzycji. Tranzycja jest jednym z pod-
stawowych elementów sªu»¡cych do budowy automatu sko«czonego opisuj¡cego zadanie u»ytkowe. Atrybutami
transition
s¡:
condition i target,
ich szczegóªy przedstawione zostaªy
w tabeli 4
Nazwa
Wymagany
Typ
condition
TAK
NMTOKEN
Warto±¢
domy±lna
brak
Opis
Warto±¢
false).
Umieszcza
równie»
j¡ca
logiczna
(true
si¦
konstrukcj¦
warunek
logiczny,
lub
tutaj
opisunp.
iniFile.irp6p_compliant==true
target
TAK
ID
brak
ID stanu docelowego. Musi mie¢
warto±¢ odpowiadaj¡c¡ jednemu
ze stanów zawartych w dokumencie.
Zgodnie z denicj¡ j¦zyka zawart¡ w pliku
<transition>
fsautomat.dtd,
cej tranzycji.
43
ka»dy stan zawiera 1 lub wi¦-
Najcz¦±ciej zapis elementu
<transition>
stosowany w opisach zada« u»ytkowych, które po-
wstaªy na potrzeby niniejszej pracy, ma posta¢:
1
Na przykªadzie wida¢, »e warunkiem przej±cia
logiczna
true.
condition
zawartym w tranzycji, jest warto±¢
Oznacza to, »e po wykonaniu akcji stanu aktualnego, automat przejdzie bez-
po±rednio do stanu opisanego w polu
target. Takie stosowanie elementu <transition> sªu»y
jedynie do opisu sekwencji przej±¢.
Wariantowo±¢ wykonania przej±cia do nast¦pnego stanu, opisana zgodnie z przyj¦t¡ denicj¡ j¦zyka, przedstawiona jest na kolejnym przykªadzie:
1
...
< t r a n s i t i o n c o n d i t i o n=" s t a t e O p e r a t i o n R e s u l t " t a r g e t="communicate_wws_4" />
< t r a n s i t i o n c o n d i t i o n=" i n i F i l e . i r p 6 p _ c o m p l i a n t " t a r g e t=" approach_6 "/>
5
...
Zapis ten oznacza: je»eli rezultat wykonywania akcji zwi¡zanej ze stanem ko«czy si¦ poprawnie
(zwracana jest warto±¢ logiczna
nie, sprawdzane jest pole
true), nast¦puje przej±cie do stanu communicate_wws_4, je»eli
irp6p_compliant
pole te ma warto±¢ logiczn¡
true,
w pliku konguracyjnym
nast¦puje przej±cie do stanu o id
przypadku nast¦puje przej±cie do stanu
fsautomat.ini.
approach_6.
Je»eli
W innym
approach_9.
Powy»szy zapis mo»na przedstawi¢ jako nast¦puj¡c¡ instrukcj¦ steruj¡ca, zapisan¡ w j¦zyku
C:
1
...
i f ( stateOperationResult
== t r u e )
goToState ( communicate_wws_4 ) ;
else i f ( i n i F i l e . i r p 6 p _ c o m p l i a n t )
5
goToState ( approach_6 ) ;
else
goToState { approach_9 } ;
...
Nale»y
tutaj
<transition>,
nadmieni¢,
»e
którego atrybut
ka»dy
stan
condition
powinien
zawsze
ma wpisan¡ warto±¢
zawiera¢
true.
jeden
element
Ma to sªu»y¢ unik-
ni¦ciu sytuacji, kiedy »aden z wymienionych wcze±niej warunków tranzycji nie jest speªniony
i automat zawiesza si¦ na aktualnym stanie.
Istnieje równie» dodatkowe zabezpieczenie, które ma przeciwdziaªa¢ bª¦dom zawartym
w dokumencie XML. Mianowicie, w sytuacji kiedy
id
nast¦pnego stanu jest bª¦dnie wpi-
sane i nie ma stanu docelowego tranzycji, automat ko«czy dziaªanie przechodz¡c do stanu
ko«cowego. Szerzej jest to opisane w 6.1.
5.15.1 Atrybut target
Atrybut
target
elementu
<transition>
mo»e by¢ zapisywany na dwa sposoby, np:
44
• target=approach_1 - jest to typowa konstrukcja, w której warto±ci¡ atrybutu jest id
stanu docelowego danej tranzycji,
• target=ica_1identify_colors_2
zawiera
id
- jest to konstrukcja, w której warto±¢ atrybutu
dwóch stanów przedzielonych separatorem . Takim zapisem opisana jest
instrukcja wykonania podzadania.
Przedstawiony wy»ej zapis
target=ica_1identify_colors_2 czytamy w nast¦puj¡cy
Id¹ do stanu identify_colors_2, ale wcze±niej wykonaj podzadanie, którego stanem
pocz¡tkowym jest stan ica_1.
Wymagane jest, aby po lewej stronie separatora (nazwijmy go operatorem skoku do
podzadania ) znajdowaªo si¦ id stanu pocz¡tkowego poprawnie zdeniowanego podzadania,
sposób:
a po jego prawej stronie
id
kolejnego stanu zawartego w opisie zadania u»ytkowego.
Samo podzadanie reprezentuje sekwencj¦ pewnych akcji, która jest wykonywana identycznie w kilku miejscach opisywanego zadania u»ytkowego. Podzadanie mo»e by¢ konstruowane
w sposób opisany w podrozdziale 5.3. W najprostszym przypadku mo»e ono oznacza¢ przej±cie
przez pewien zbiór stanów automatu, gdzie
w atrybucie
target
elementu
id
<transition>,
stanu docelowego ostatniego z nich, zawarte
ma przypisan¡ warto±¢
_END_,
tak jak jest to
przedstawione na przykªadzie 13.
1
<S t a t e i d=" i d e n t i f y _ c o l o r s _ 1 6 " type=" i n t e r m e d i a t e S t a t e ">
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" ica_1>>i d e n t i f y _ c o l o r s _ 1 7 " />
</ S t a t e>
<S t a t e i d=" i d e n t i f y _ c o l o r s _ 1 7 " type=" c u b e S t a t e W r i t i n g ">
5
<AddArg>5</AddArg>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" i d e n t i f y _ c o l o r s _ 1 8 "/>
</ S t a t e>
< !−−
10
############################################################### −−>
<S t a t e i d=" ica_1 " type=" i n t e r m e d i a t e S t a t e ">
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t="fto_CL_0_1>>ica_2 " />
</ S t a t e>
<S t a t e i d=" ica_2 " type=" r un G en er at or ">
15
<Speech>o g l o ~dam k o l o r y na s~ c i a n c e</ Speech>
</ S t a t e>
<S t a t e i d=" ica_3 " type=" emptyGenForSet ">
20
<SetOfRobots>
<F i r s t S e t>
</ F i r s t S e t>
<S e c S e t>
25
</ S e c S e t>
</ SetOfRobots>
45
</ S t a t e>
30
</ S t a t e>
35
</ S t a t e>
40
</ S t a t e>
<S t a t e i d=" ica_7 " type=" g e t S e n s o r R e a d i n g ">
45
</ S t a t e>
Wydruk 13: Przykªadowe podzadanie
Dzi¦ki przyj¦ciu takiej denicji nie jest konieczne powielanie analogicznych fragmentów
opisu zadania.
5.16 Element <Trajectory>
Element
j¦ta
<Trajectory>
denicj¡
j¦zyka.
zawiera i przechowuje reprezentacj¦ trajektorii zgodn¡ z przy-
Odpowiada
ona
trajektorii
wykorzystywanej
przez
generator
ecp_smooth_generator i zapisywanej w plikach z rozszerzeniem .trj. Przykªadowo zapisowi
trajektorii w pliku
1
.trj:
JOINT
2
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
5
0.5 0.5 0.5 0.5 0.5 0.5 0.5 1.0
0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.01
0 . 0 − 0.08 − 1.54 0 . 0 2
1.21
2.57
− 2.66 0 . 0 5
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
10
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.5 0.5 0.5 0.5 0.5 0.5 0.5 1.0
0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.01
0 . 0 − 0.08 − 1.54 0 . 0 2
1.21
2.57
− 2.66 0 . 0 6 5
odpowiada zapis po stronie dokumentu XML:
1
<Pose>
<En dV el oc it y>0
0 0 0 0 0 0 0</ S t a r t V e l o c i t y>
0 0 0 0 0 0 0</ E nd Ve lo ci ty>
46
<V e l o c i t y>0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 1</ V e l o c i t y>
5
0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 0 1</ A c c e l e r a t i o n s>
− 0.08 − 1.54 0 . 0 2
1.21
2.57
− 2.66 0 . 0 5</ C o o r d i n a t e s>
</ Pose>
<Pose>
10
<En dV el oc it y>0
0 0 0 0 0 0 0</ S t a r t V e l o c i t y>
0 0 0 0 0 0 0</ E nd Ve lo ci ty>
<V e l o c i t y>0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 1</ V e l o c i t y>
0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 0 1</ A c c e l e r a t i o n s>
− 0.08 − 1.54 0 . 0 2
1.21
2.57
− 2.66 0 . 0 6</ C o o r d i n a t e s>
</ Pose>
15
Wydruk 14: Przykªad zapisu trajektorii w dokumencie XML
Reguªy dotycz¡ce elementu
<Trajectory>
zostaªy opisane w pliku
fsautomat.dtd
w na-
st¦puj¡cy sposób:
ELEMENT T r a j e c t o r y ( Pose+)>
< ! ATTLIST T r a j e c t o r y c o o r d i n a t e T y p e CDATA #REQUIRED>
< ! ATTLIST T r a j e c t o r y numOfPoses CDATA #REQUIRED>
1
<!
5
<!
ELEMENT Pose
( S t a r t V e l o c i t y , EndVelocity , V e l o c i t y , A c c e l e r a t i o n s ,
C o o r d i n a t e s )>
ELEMENT S t a r t V e l o c i t y (#PCDATA)>
ELEMENT En d Ve lo ci ty (#PCDATA)>
< !ELEMENT V e l o c i t y (#PCDATA)>
< !ELEMENT A c c e l e r a t i o n s (#PCDATA)>
< !ELEMENT C o o r d i n a t e s (#PCDATA)>
<!
<!
10
Wydruk 15: Denicja elementu
Jak wida¢ na wydruku 15
mentów
<Pose>,
<Trajectory>
<Trajectory>
w DTD
jest rodzicem jednego lub wi¦kszej liczby ele-
którego potomkami s¡ kolejno:
• <StartVelocity>
przechowuje warto±ci pr¦dko±ci pocz¡tkowych separowane znakiem
tabulacji. Pojawia si¦ dokªadnie jeden raz,
• <EndVelocity>
przechowuje warto±ci pr¦dko±ci ko«cowych separowane znakiem ta-
bulacji. Pojawia si¦ dokªadnie jeden raz,
• <Velocity>
przechowuje warto±ci pr¦dko±ci separowane znakiem tabulacji. Pojawia
si¦ dokªadnie jeden raz,
• <Accelerations>
przechowuje warto±ci przy±piesze« separowane znakiem tabulacji.
Pojawia si¦ dokªadnie jeden raz,
• <Coordinates> przechowuje warto±ci koordynatów separowane znakiem tabulacji. Pojawia si¦ dokªadnie jeden raz.
Szczegóªy atrybutów elementu
<Trajectory>
47
zostaªy opisane w tabeli 5.
Nazwa
Wymagany
Typ
Warto±¢
domy±lna
coordinateType
TAK
NMTOKEN
brak
Opis
Warto±¢ okre±laj¡ca w jakiej
s¡
postaci
dane
przez
by¢
wyra»one
przechowywane
element.
zgodna
z
Musi
jedn¡
ze
zdeniowanych warto±ci
numOfPoses
TAK
decimal
brak
Warto±¢ liczbowa okre±laj¡ca liczb¦ pozycji, które
zawiera trajektoria.
Tablica 5: Atrybuty elementu
<Trajectory>
5.17 Deniowanie zadania dla systemu MRROC++
Proces deniowania dokumentu XML z zapisem zadania u»ytkowego mo»na podzieli¢ na
kilka etapów. W pierwszym kroku nale»y zdeniowa¢ zadanie oraz elementy, których u»ycie
b¦dzie konieczne do jego wykonania. Nast¦pnie nale»y dokona¢ dekompozycji, która pozwoli
na okre±lenie czynno±ci elementarnych skªadaj¡cych si¦ na caªe zadanie. Czynno±ci te wst¦pnie
okre±laj¡ stany nale»¡ce do deniowanej maszyny stanowej. W kolejnym kroku nale»y okre±li¢
sekwencj¦, w jakiej b¦d¡ wykonywane kolejne czynno±ci, czy przej±cia do ich wykonywania s¡
uzale»nione od speªnienia pewnych warunków. Przeprowadzone rozwa»ania powinny w pewnym stopniu przybli»y¢ ksztaªt budowanej maszyny stanowej. W efekcie dekompozycji mo»na
okre±li¢ stany automatu i czynno±ci z nimi zwi¡zane, przej±cia i ich warunki, oraz przepªyw
sterowania, czyli wszystkie potrzebne elementy, z których zbudowany jest automat sko«czony.
Warto po±wi¦ci¢ szczególn¡ uwag¦ na okre±lenie ksztaªtu stanu pocz¡tkowego opisywanego
zadania. Przy deniowaniu tego stanu (którego
id=INIT i type=systemInitialization),
nale»y zaznaczy¢, jakie obiekty b¦d¡ wykorzystywane przy realizacji zadania u»ytkowego i na
ECP czy MP) b¦d¡ one powoªywane do »ycia. Na tym etapie
nale»y te» zaznaczy¢ z jakich generatorów b¦d¡ korzysta¢ procesy ECP robotów uczestnicz¡-
poziomie którego z procesów (
cych w wykonaniu zadania i jakie dodatkowe elementy nale»y doda¢ czy te» zainicjalizowa¢
na poziomie procesu
MP.
Nale»y te» pami¦ta¢, »e ka»dy stan, z którego automat mo»e wyj±¢ do stanu ko«ca pracy,
powinien jako ostatni element
1
<transition>
zawiera¢ wpis:
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t="_STOP_"></ t r a n s i t i o n>
W ramach sprawdzenia mo»liwo±ci, czy te» siªy wyrazu powstaªego j¦zyka opisu, pewne
istniej¡ce w systemie
MRROC++
zadania zapisane w kodzie j¦zyka C++, zostaªy opisane w po-
staci dokumentów XML. S¡ to:
•
Zadanie nalewania (ang.
pouring task ),
48
•
Zadanie ukªadania kostki Rubika (ang.
Rubik cube solver task ).
pouring.xml oraz rcsc.xml, których
W wyniku przeprowadzonych prac powstaªy dokumenty
zawarto±¢ zostaªa opisana w kolejnych podrozdziaªach.
5.17.1 Zadanie nalewania
Zadanie nalewania, w swojej orginalnej formie, skªada si¦ z kodu procesu
nego w pliku
i
mp_t_pouring.cc
oraz kodów procesów
ECP
robotów
MP
zapisa-
ROBOT_IRP6_ON_TRACK
ROBOT_IRP6_POSTUMENT zapisanych odpowiednio w plikach ecp_t_pouring_irp6ot.cc oraz
ecp_t_pouring_irp6p.cc.
niowanych w plikach
.trj
Implementacja ta skupia si¦ w gªównej mierze na wykonaniu zdetrajektorii przez generator
ECP_GEN_SMOOTH.
Denicja zadania u»ytkowego, w formie opisywanej w tej pracy, zostaªa zapisana w dokumencie XML o nazwie
pouring.xml
ni¡ stan pocz¡tkowy automatu o
/data
struktury
MRROC++.
Skªada si¦ na
id=INIT przedstawiony na wydruku 16, na którym wida¢
jakie generatory i na poziomie którego
1
w katalogu
ECP, s¡ powoªywane.
<t a s k I n i t>
5
</ ecp>
10
</ ecp>
</ t a s k I n i t>
</ S t a t e>
Wydruk 16: Stan pocz¡tkowy automatu opisuj¡cego zadanie nalewania
Nast¦pne stany opisywanego automatu sko«czonego zawieraj¡ instrukcje ruchowe wykonywane przy pomocy wymienionych wcze±niej generatorów. Przykªadowo, kod realizuj¡cy wykonanie ruchu i zapisany w kodzie C++ pokazany na wydruku 17,
1
if
{
if
5
{
if
int )
ECP_GEN_SMOOTH, 0 ,
int )
ECP_GEN_SMOOTH, 0 ,
" t r j / p o u r i n g / irp6_ot_ap . t r j " , 1 , ROBOT_IRP6_ON_TRACK) )
return true ;
}
" t r j / p o u r i n g / irp6_p_ap . t r j " , 1 , ROBOT_IRP6_POSTUMENT) )
return true ;
}
( run_extended_empty_generator_for_set_of_robots
_and_wait_for_task_termination_message_of_another_set_of_robots ( 2 , 2 ,
10
ROBOT_IRP6_ON_TRACK, ROBOT_IRP6_POSTUMENT,
ROBOT_IRP6_ON_TRACK, ROBOT_IRP6_POSTUMENT) )
49
{
return true ;
}
Wydruk 17: Fragment kodu C++ zadania nalewania
w dokumencie XML z denicj¡ zadania przyjmuje posta¢ jak na wydruku 18.
1
5
<Pose>
<En dV el oc it y>0
0 0 0 0 0 0 0</ S t a r t V e l o c i t y>
0 0 0 0 0 0 0</ E nd Ve lo ci ty>
10
0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1</ A c c e l e r a t i o n s>
0 . 1 − 1.162 0 . 1 7 2 1 . 3 6 7 2 . 9 3 6 1 . 3 7 1 0 . 0 8 8</ C o o r d i n a t e s>
</ Pose>
15
</ S t a t e>
<T r a j e c t o r y F i l e P a t h> t r j / p o u r i n g / irp6_p_ap . t r j</ T r a j e c t o r y F i l e P a t h>
20
<Pose>
<En dV el oc it y>0
0 0 0 0 0 0 0</ S t a r t V e l o c i t y>
0 0 0 0 0 0 0</ E nd Ve lo ci ty>
<V e l o c i t y>0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 5 0 . 0 4
25
1</ V e l o c i t y>
0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1 0 . 1</ A c c e l e r a t i o n s>
<C o o r d i n a t e s> − 0.072 − 1.5 0 . 1 6 2 1 . 4 9 2 2 . 3 3 2 − 1.622 0 . 0 8 0</ C o o r d i n a t e s>
</ Pose>
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t=" approach_end " />
30
</ S t a t e>
<SetOfRobots>
<F i r s t S e t>
35
</ F i r s t S e t>
<S e c S e t>
40
</ S e c S e t>
</ SetOfRobots>
</ S t a t e>
Wydruk 18: Fragment dokumentu XML z zadaniem nalewania
50
5.17.2 Ukªadanie kostki Rubika
Zadanie ukªadania kostki Rubika, podobnie jak zadanie nalewania, pocz¡tkowo zostaªo
zapisane w j¦zyku C++ w pliku z kodem procesu
procesów
MP mp_t_rcsc.cc oraz plikach z kodem
ECP ecp_t_rcsc_irp6ot.cc i ecp_t_rcsc_irp6p.cc.
Z kolei opis zadania ukªadania kostki Rubika, zgodny z denicj¡ j¦zyka b¦d¡cego przedmiotem tej pracy, zostaª umieszczony w plikach
podzadania, a mianowicie
rcsc.xml
faceChangeOperations.xml
i
oraz dokumentach zawieraj¡cych
faceTurnOperations.xml.
Zapisa-
nie zadania w kilku dokumentach XML miaªo wpªyn¡¢ na czytelno±¢ opisu zadania. W wyniku
tego podziaªu, konieczne byªo zastosowanie mechanizmu
XInclude.
Stan pocz¡tkowy automatu opisuj¡cego zadanie ukªadania kostki Rubika jest przedstawiony
na poni»szym wydruku 19.
1
<t a s k I n i t>
5
10
<weight_meassure_gen>1</ weight_meassure_gen>
</ ecp>
15
20
25
</ ecp>
<mp>
30
</mp>
</ t a s k I n i t>
</ S t a t e>
Wydruk 19: Stan pocz¡tkowy automatu opisuj¡cego zadanie rozwi¡zywania kostki Rubika
51
Jak wynika z konstrukcji stanu pocz¡tkowego, realizacja omawianego zadania wymaga
u»ycia niemal caªego zestawu generatorów trajektorii zawartych w strukturze
MRROC++. Dzi¦ki
temu zadanie te stanowi dobre narz¦dzie do sprawdzenia przydatno±ci j¦zyka opisanego w tej
pracy.
W zwi¡zku z faktem, »e opis zadania ukªadania kostki Rubika zawarty z dokumencie XML
jest do±¢ obszerny i wielu miejscach zawiera instrukcje ruchowe analogiczne do instrukcji
zawartych w zadaniu nalewania, zostan¡ opisane tutaj jedynie fragmenty, które mog¡ si¦
wydawa¢ najbardziej interesuj¡ce.
Opis automatu realizuj¡cego zadanie nalewania, w wyniku natury tego zadania, nie posiadaª przej±¢ do kolejnych stanów, które by wymagaªy speªnienia warunku. Przedstawiaª
wªa±ciwie sekwencj¦ pewnych akcji zwi¡zanych ze stanami. Wariantowo±¢ przej±¢ wyst¦puje
w opisie zadania ukªadania kostki Rubika, co jest pokazane na wydruku 20.
1
<Speech>j e s t e m podatny</ Speech>
5
<AddArg>1</AddArg>
</ S t a t e>
<S t a t e i d=" approach_5 " type=" emptyGenForSet ">
<SetOfRobots>
10
<F i r s t S e t>
</ F i r s t S e t>
<S e c S e t>
15
</ S e c S e t>
</ SetOfRobots>
< t r a n s i t i o n c o n d i t i o n=" i n i F i l e . i r p 6 p _ c o m p l i a n t " t a r g e t=" approach_6 "/>
</ S t a t e>
Wydruk 20: Przykªad wariantowo±ci zadania ukªadania kostki Rubika
Na przykªadzie zostaª pokazany przypadek, gdzie przej±cie do stanu
gdy w pliku konguracyjnym
warto±¢ logiczna
true.
approach_6
nast¡pi,
.ini b¦dzie znajdowaª si¦ wpis irp6p_compliant i b¦dzie miaª
W przypadku niespeªnienia tego warunku nast¡pi przej±cie do stanu
approach_9.
Jednak najbardziej interesuj¡cym fragmentem opisu omawianego zadania, jest miejsce,
w którym wyznaczona sekwencja ruchów koniecznych do uªo»enia kostki Rubika, jest tªumaczona na sekwencje przej±¢ pomi¦dzy stanami i wykonania akcji z nimi zwi¡zanych. Na
wydruku 21 pokazano fragment dokumentu XML z opisem tego zadania.
1
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t="man_3>>depop_1" />
</ S t a t e>
52
5
< t r a n s i t i o n c o n d i t i o n=" t r u e " t a r g e t="man_4>>fco_CL_0_1" />
</ S t a t e>
<S t a t e i d="man_4" type=" m a n i p u l a t i o n S e q T r a n s l a t i o n ">
10
</ S t a t e>
Wydruk 21: Wyznaczanie sekwencji ukªadania w zadaniu ukªadania kostki Rubika
Watro omówi¢ wszystkie stany pojawiaj¡ce si¦ na powy»szym wydruku, aby w peªni
przedstawi¢ sposób realizacji zadania ukªadania kostki Rubika. Dwa pierwsze stany maj¡ typ
type=intermediateState
id
i nie wykonuj¡ »adnej akcji, a jedynie sªu»¡ do odªo»enia nazw
stanów pocz¡tkowych pewnych podzada«, które b¦d¡ wykonane, gdy nast¡pi ich zdj¦cie
ze stosu. Nast¦pnym stanem, do którego po przej±ciu dwóch pierwszych wejdzie automat,
jest stan
man_4
o typie
manipulationSeqTranslation.
Akcja zawarta w tym stanie polega na przetªumaczeniu sekwencji ruchów, otrzymanych z solwera rozwi¡zuj¡cego kostk¦ Rubika, na reprezentacj¦ zrozumiaª¡ przez automat i odªo»eniu
wszystkich nazw
id
stanów pocz¡tkowych podzada« zwi¡zanych z wykonaniem okre±lonych
ruchów, na stosie automatu. Celem tranzycji tego stanu jest
_END_
i automat interpretuje to
jako instrukcj¦ zdj¦cia nazwy kolejnego stanu ze stosu automatu. W tym momencie rozpoczyna si¦ realizowanie podzada« wcze±niej odªo»onych na stosie. Jako, »e ka»de podzadanie
ko«czy si¦ instrukcj¡ zdj¦cia
id
kolejnego stanu ze stosu, zadanie b¦dzie si¦ wykonywa¢ do
momentu, a» zrealizowana zostanie wcze±niej wyznaczona sekwencja.
Nast¦pnie automat przejdzie do podzada«, których nawy odªo»one zostaªy na stosie w dwóch
wcze±niejszych stanach po±rednich. Mo»na zauwa»y¢, »e je»eli wyznaczenie sekwencji ruchów
odbywaj¡ce si¦ w stanie
man_4
nie odb¦dzie si¦ poprawnie (tzn. nie zostanie wyznaczona se-
kwencja ruchów ukªadaj¡ca kostk¦) automat przejdzie do stanów, których nazwy wcze±niej
odªo»ono na stosie.
53
6 Realizacja mechanizmu interpretuj¡cego i wykonuj¡cego zdeniowane zadanie
Aby zdeniowany j¦zyk opisu zada« wielorobotowych w dokumencie XML miaª racj¦ bytu,
nale»aªo zaimplementowa¢ mechanizm, który by potraª interpretowa¢ tak zapisane zadanie,
a nast¦pnie je wykona¢ na rzeczywistym ukªadzie robotycznym. W ramach realizacji tego zaªo»enia powstaªy procesy
mp_fsautomat oraz ecp_irp6ot_fsautomat i ecp_irp6p_fsautomat,
które wraz z obiektami reprezentuj¡cymi automat sko«czony po stronie struktury
MRROC++
tworz¡ mechanizm umo»liwiaj¡cy uruchamianie zada« zapisanych zgodnie z reguªami opisywanego wcze±niej i b¦d¡cego przedmiotem tej pracy, j¦zyka opisu zada« u»ytkowych.
6.1 Obiektowa reprezentacja elementów zadania
Diagram pokazany na rysunku 6.1 opisuje struktur¦ mechanizmu realizuj¡cego zadanie.
Rysunek 8: Ogólna struktura mechanizmu
Przedstawiony powy»ej obiekt klasy
mp_task_fsautomat
jest j¡drem procesu
MP
reali-
zuj¡cego zadanie u»ytkowe. Obiekty pozostaªych klas sªu»¡ do reprezentowania elementów
istniej¡cych w dokumencie XML z zadaniem:
• State
obiekt tej klasy reprezentuje element
54
<State>
w systemie
MRROC++,
• Transition obiekt tej klasy reprezentuje element <Transition> w systemie MRROC++,
• Condition
obiekt tej klasy reprezentuje element
<Condition>
• StateHeap
obiekt tej klasy odpowiada za realizacj¦ stosu automatu (stosu stanów
w systemie
MRROC++,
docelowych),
• Trajectory obiekt tej klasy reprezentuje element <Trajectory> w systemie MRROC++,
• ecp_smooth_taught_in_pose
w systemie
MRROC++
obiekt klasy reprezentuj¡cy nauczon¡ pozycj¦ zawarty
i wykorzystywany w implementowaniu tego rozwi¡zania.
6.1.1 Klasa State
State
Obiekty klasy
reprezentuj¡ elementy
dania w dokumencie XML, w systemie
<State>
MRROC++.
wykorzystywane do tworzenia za-
Interfejs klasy
State
pokazany zostaª na
wydruku 22
1
class
{
State
public :
State ( ) ;
5
State (
const
S t a t e &s t a t e ) ;
~State ( ) ;
typedef struct
RobotSets {
RobotSets ( ) ;
RobotSets (
10
const
RobotSets & r o b o t S e t s ) ;
~RobotSets ( ) ;
int
int
15
firstSetCount ;
secondSetCount ;
ROBOT_ENUM ∗ f i r s t S e t ;
ROBOT_ENUM ∗ s e c o n d S e t ;
};
20
25
static ROBOT_ENUM r e t u r n P r o p e r R o b o t ( char
void s e t S t a t e I D ( char ∗ s t a t e I D ) ;
char ∗ g e t S t a t e I D ( ) const ;
void setNumArgument ( char ∗ time ) ;
int getNumArgument ( ) const ;
void setType ( char ∗ type ) ;
char ∗ getType ( ) const ;
void setRobot ( char ∗ r o b o t ) ;
ROBOT_ENUM getRobot ( ) const ;
void s e t G e n e r a t o r T y p e ( char ∗ genType ) ;
∗ robotName ) ;
STATE_MACHINE_ECP_GENERATOR getGeneratorType ( )
30
void
char
void
void
setStringArgument (
char
∗ trajFilePath );
const ;
char
s e t P r o p e r T r a n s i t i o n R e s u l t ( bool
∗
const ;
getStringArgument ( )
setTransition (
char
∗ cond ,
55
∗ t a r g e t , c o n f i g u r a t o r &_ c o n f i g ) ;
result );
const char
∗ r e t u r n N e x t S t a t e I D ( StateHeap &sh ) ;
const ;
s t d : : l i s t <T r a n s i t i o n > ∗ g e t T r a n s i t i o n s ( )
void
35
showStateContent ( )
const ;
RobotSets ∗ r o b o t S e t ;
private :
char ∗ i d ;
char ∗ type ;
int numArgument ;
char ∗ stringArgument ;
40
ROBOT_ENUM r o b o t ;
STATE_MACHINE_ECP_GENERATOR g e n e r a t o r T y p e ;
45
s t d : : l i s t <T r a n s i t i o n > ∗ s t a t e T r a n s i t i o n s ;
};
Wydruk 22: Interfejs klasy
State
Jak wida¢ na zamieszczonym wydruku, obiekt klasy
State
zawiera nast¦puj¡ce atrybuty
odpowiedzialne za przechowywanie danych zawartych w dzieciach elementu
• id
<State>:
atrybut przechowuj¡cy unikalny identykator stanu,
• type
atrybut przechowuj¡cy typ stanu,
• numArgument
atrybut przechowuj¡cy argumenty numeryczne zawarte w elementach-
potomkach takich jak:
• stringArgument
potomkach
<AddArg> i <TimeSpan>,
atrybut przechowuj¡cy argumenty tekstowe zawarte w elementach-
takich
jak:
<TrajectoryFilePath>,
<Parameters>, <Sensor>
oraz
<Speech>.
pojawienie si¦ w elemencie
<State>
<GeneratorParameters>,
Wykorzystana jest tutaj wªa±ciwo±¢, »e
jednego z tych potomków, wyklucza pojawienie si¦
pozostaªych. Dlatego mo»liwe jest wykorzystanie jednego atrybutu odpowiadaj¡cego
kilku elementom,
• robot
atrybut przechowuj¡cy typ robota - warto±¢ typu wyliczeniowego
ustawiany na podstawie warto±ci elementu
ROBOT_ENUM,
<ROBOT>,
• robotSet atrybut przechowuj¡cy wska¹nik do struktury RobotSets, która przechowuje
nazwy robotów w postaci dwóch zbiorów (deklaracja tej struktury znajduje si¦ w liniach
8-17 wydruku 22), jest odpowiednikiem elementu
• generatorType
<SetOfRobots>,
atrybut przechowuj¡cy typ generatora - warto±¢ typu wyliczeniowego
STATE_MACHINE_ECP_GENERATOR,
• stateTransitions atrybut przechowuj¡cy wska¹nik do listy zawieraj¡cej obiekty klasy
Transition
odpowiadaj¡ce elementom
<transition>.
56
Poni»sza lista przedstawia metody, których deklaracje zostaªy zawarte w interfejsie klasy
State
oraz ich opisy:
• returnProperRobot(char *)
liczeniowego
ROBOT_ENUM
• setStateID(char *)
• getStateID()
na podstawie argumentu tekstowego,
metoda ustawiaj¡ca identykator stanu,
metoda zwracaj¡ca identykator stanu,
• setNumArgument(char* )
• getNumArgument()
• setType(char *)
• getType()
jest to statyczna metoda zwracaj¡ca warto±¢ typu wy-
metoda ustawiaj¡ca warto±¢ atrybutu
metoda zwracaj¡ca warto±¢ atrybutu
numArgument,
numArgument,
metoda ustawiaj¡ca typ stanu,
metoda zwracaj¡ca typ stanu,
• setRobot(char *)
• getRobot()
• setGeneratorType(char *)
• getGeneratorType()
robot,
robot,
generatorType,
generatorType,
• setStringArgument(char *) metoda ustawiaj¡ca warto±¢ atrybutu stringArgument,
• getStringArgument()
• setTransition(char *, char *, configurator &)
stworzenie
nowego
obiektu
klasy
Transition
i
stringArgument,
metoda
dodanie
go
odpowiedzialna
do
listy
za
tranzycji
stateTransitions,
• setProperTransitionResult(bool) metoda umo»liwiaj¡ca ustawienie rezultatu akcji
zwi¡zanej ze stanem zgodnie z, przekazan¡ jako argument, warto±ci¡ logiczn¡,
• returnNextStateID(StateHeap &) metoda zwracaj¡ca identykator kolejnego stanu,
do którego ma przej±¢ maszyna stanowa. Jako argument tej funkcji przekazywana jest
referencja do obiektu klasy
(tzn. warunek
o warto±ci
condition
_END_,
StateHeap.
W momencie kiedy celem speªnionej tranzycji
tranzycji jest speªniony) aktualnego stanu jest identykator
identykator kolejnego stanu jest zdejmowany ze stosu i zwracany
przez omawian¡ metod¦,
• getTransitions()
metoda zwracaj¡ca wska¹nik do listy przechowuj¡cej tranzycje
zwi¡zane z aktualnym obiektem klasy
State,
na rzecz którego ta metoda jest wywoªy-
wana,
• showStateContent() metoda wypisuj¡ca na standardowym wyj±ciu zawarto±¢ obiektu
klasy
State.
Stosowana jest gªównie w celach testowych.
57
6.1.2 Klasa Transition
Obiekty klasy
Transition
reprezentuj¡ w strukturze
MRROC++
elementy
<transition>
znajduj¡ce si¦ w denicji zadania zawartego w dokumencie XML. Obiekty te s¡ agregowane
w obiektach klasy
Interfejs klasy
1
class
{
State,
Transition
Transition.
zostaª przedstawiony na wydruku 23
Transition
public :
Transition (
Transition (
5
które mog¡ zawiera¢ jeden lub wi¦cej obiektów typu
char ∗ cond , char
const T r a n s i t i o n
∗ t a r g e t I D , c o n f i g u r a t o r &_ c o n f i g ) ;
&t r a n s i t i o n ) ;
~Transition ( ) ;
bool
bool
char
char
void
10
getConditionResult ( ) ;
setConditionResult (
bool
result );
∗ get Tar get ID ( StateHeap &sh )
∗ getConditionDescription ()
showContent ( ) ;
const ;
const ;
private :
char ∗ t a r g e t I D ;
15
Condition ∗ condition ;
};
Atrybutami obiektu klasy
• targetID
Transition
Transition
s¡:
jest to atrybut przechowuj¡cy identykator stanu docelowego tranzycji.
Reprezentuje warto±¢ atrybutu
• condition
target
elementu
<transition>,
jest to atrybut przechowuj¡cy wska¹nik na obiekt typu
zentuj¡cy warunek zwi¡zany z tranzycj¡, czyli warto±¢ atrybutu
Condition
condition
repre-
elementu
<transition>.
Poni»ej zostaªy przedstawione metody, których denicje zostaªy zawarte w interfejsie klasy
Transition:
• getConditionResult()
jest to metoda zwracaj¡ca warto±¢ wyra»enia logicznego re-
prezentowanego przez obiekt klasy
• setConditionResult(bool)
Condition,
jest to metoda pozwalaj¡ca na odgórne ustawienie war-
to±ci wyra»enia logicznego reprezentowanego przez obiekt klasy
Condition,
• getTargetID(StateHeap &) metoda zwracaj¡ca identykator kolejnego stanu, do którego ma przej±¢ maszyna stanowa i który jest zapisany jako atrybut
gument tej funkcji przekazywana jest referencja do obiektu klasy
mencie kiedy warto±¢ pola
targetID
jest równa
kolejnego stanu ze stosu,
58
_END_
targetID. Jako ar-
StateHeap, aby w mo-
nast¡piªo zdj¦cie identykatora
• getConditionDescription()
metoda zwracaj¡ca tekstow¡ reprezentacj¦ wyra»enia
logicznego zawartego w obiekcie klasy
Condition,
• showContent() metoda wypisuj¡ca na standardowym wyj±ciu zawarto±¢ obiektu klasy
Transition
stosowana gªównie w celach testowych.
6.1.3 Klasa Condition
Obiekt klasy
Condition
reprezentuje w systemie
MRROC++
atrybut
condition
elementu
<transition>, który przechowuje wyra»enie logiczne zwi¡zane z dan¡ tranzycj¡. Obiekt typu
Condition
jest zawierany przez obiekt klasy
Transition.
Na poni»szym wydruku 24 zostaª
pokazany interfejs omawianej klasy
1
class
{
5
Condition
public :
enum RELATIONAL_OPERATOR
public :
{EQUAL_TO = 0 , NOT_EQUAL, LESS_EQUAL,
GREATER_EQUAL, LESS_THAN, GREATER_THAN, WITHOUT_OP} ;
Condition ( ) ;
Condition (
Condition (
char ∗ condDesc , c o n f i g u r a t o r
const C o n d i t i o n &cond ) ;
&_ c o n f i g ) ;
~Condition ( ) ;
10
bool
bool
bool
checkCompareResult ( ) ;
setResult (
char
std : : l i s t <
15
char
char ∗ toCheck ) ;
bool r e s u l t ) ;
checkContext (
∗> ∗ r e t u r n S p l i t e d S t r (
∗ getCondDesc ( )
const ;
char
∗ toSplit );
RELATIONAL_OPERATOR s p l i t C o n d E x p r ( ) ;
private :
char ∗ c o n d i t i o n ;
char ∗ l h V a l u e ;
char ∗ rhValue ;
bool r e s u l t ;
20
RELATIONAL_OPERATOR o p e r a t i o n T y p e ;
25
c o n f i g u r a t o r &c o n f i g ;
};
Condition
Z przedstawionej deklaracji klasy wynika, »e obiekt typu
Condition
posiada nast¦puj¡ce
atrybuty:
• condition
jest to pole tekstowe przechowuj¡ce wyra»enie logiczne reprezentuj¡ce wa-
runek przej±cia,
59
• lhValue
je»eli wyra»enie logiczne zapisane w
condition
jest zapisane przy u»yciu
operatora relacji, to ten atrybut przyjmuje warto±¢ odpowiadaj¡c¡ wyra»eniu stoj¡cemu
po lewej stronie operatora,
• rhValue
analogicznie jak atrybut opisany wy»ej, tyle »e atrybut zawiera wyra»enie
stoj¡ce po prawej stronie operatora relacji,
• result
atrybut przechowuj¡cy rezultat wyra»enia logicznego zapisanego w atrybucie
condition,
• operationType
atrybut
RELATIONAL_OPERATOR,
w polu
ustawiany
przyjmuj¡cy
jest
na
warto±¢
podstawie
typu
operatora
wyliczeniowego
relacji
zawartego
condition.
Poni»sza lista przedstawia metody, których deklaracje zostaªy przedstawione w interfejsie
klasy
Condition:
• checkCompareResult() jest to metoda zwracaj¡ca warto±¢ warunku logicznego, przechowywanego w atrybucie
• checkContext(char *)
condition
obiektu,
metoda ta zwraca warto±¢ logiczn¡ zapisan¡ w pliku pod
odpowiedni¡ nazw¡. Jest wywoªywana gdy w tek±cie wyra»enia logicznego zawarty jest
znak zakresu ., charakterystyczny dla odwoªania si¦ do pliku konguracyjnego,
• setResult(bool) metoda ustawiaj¡ca atrybut result zgodnie z przekazan¡ do funkcji
warto±ci¡ logiczn¡,
• returnSplitedStr(char)
pomocnicza metoda zwracaj¡ca list¦ stringów, które sta-
nowiªy pojedynczy string, a zarazem argument wej±ciowy metody i byªy przedzielone
separatorem .,
• getCondDesc()
metoda zwracaj¡ca zawarto±¢ pola
• splitCondExpr()
condition,
metoda zwracaj¡ca typ u»ytego operatora relacji.
6.1.4 Klasa StateHeap
Obiekt klasy
StateHeap
reprezentuje stos automatu sko«czonego. Na stos odkªadane s¡
i przez niego przechowywane identykatory stanów, do których ma przej±¢ automat po wykonaniu podzadania. Poni»szy wydruk 25 przedstawia interfejs klasy
1
class
{
StateHeap
public :
StateHeap ( ) ;
5
~StateHeap ( ) ;
void
pushTargetName (
const char
∗ stateName ) ;
60
StateHeap:
const char
void
10
∗ popTargetName ( ) ;
showHeapContent ( ) ;
private :
const char
std : : l i s t <
};
∗> ∗ t a r g e t s H e a p ;
Obiekt klasy
StateHeap
StateHeap, co wida¢ na powy»szym wydruku, posiada jeden atrybut, którym
jest lista przechowuj¡ca ci¡gi znakowe odpowiadaj¡ce identykatorom stanów.
Posiada równie» metody, których deklaracje zostaªy zawarte w interfejsie klasy
StateHeap.
S¡ to przede wszystkim funkcje sªu»¡ce do odªo»enia i zdj¦cia kolejnego identykatora stanu
ze stosu. Ich opis znajduje si¦ poni»ej:
• pushTargetName(const char * )
jest to metoda, której wywoªanie na rzecz obiektu
powoduje odªo»enie identykatora stanu, przekazanego jako argument wywoªania, na
stos reprezentowany przez list¦
targetHeap,
• popTargetName() jest to metoda, której wywoªanie na rzecz obiektu powoduje zdj¦cie
identykatora stanu ze stosu i zwrócenie go przez funkcj¦. Kiedy metoda jest wywoªana gdy stos jest pusty, zwracany jest identykator
_STOP_
oznaczaj¡cy koniec pracy
automatu sko«czonego,
• showHeapContent()
klasy
StateHeap
metoda wypisuj¡ca na standardowym wyj±ciu zawarto±¢ stosu
stosowana gªównie w celach testowych.
6.1.5 Klasa Trajectory
Obiekt klasy
Trajectory
reprezentuje w systemie
MRROC++
element
<Trajectory>,
który
jest wykorzystywany do deniowania zada« u»ytkowych w dokumencie XML. Obiekty te s¡
zawarte w obiektach klasy
State.
Obiekt typu
Trajectory
ma przechowywa¢ i przedstawia¢
w ustrukturalizowany sposób dane zapisywane w plikach trajektorii z rozszerzeniem
Interfejs omawianej klasy przedstawiony zostaª na wydruku 26
1
class
{
Trajectory
public :
Trajectory ( ) ;
5
Trajectory (
char
char
∗ numOfPoses ,
∗ poseSpecification );
Trajectory (
const
char
∗ trajecto ryName ,
T r a j e c t o r y &t r a j e c t o r y ) ;
~Trajectory ( ) ;
10
static int s e t V a l u e s I n A r r a y ( double a r r a y T o F i l l [ ] , char ∗ d a t a S t r i n g ) ;
static POSE_SPECIFICATION returnProperPS ( char ∗ p o s e S p e c i f i c a t i o n ) ;
static const char ∗ t o S t r i n g ( double v a l A r r [ ] , int l e n g t h ) ;
61
.trj.
static const char
static const char
static const char
15
static bool
∗ toString (
int
numberOfPoses ) ;
∗ t o S t r i n g (POSE_SPECIFICATION ps ) ;
∗ returnRobotName (ROBOT_ENUM r o b o t ) ;
writeTrajectoryToXmlFile (
char
∗ fileName ,
POSE_SPECIFICATION ps , s t d : : l i s t <ecp_smooth_taught_in_pose> &p o s e s ) ;
void
void
void
char
void
20
createNewPose ( ) ;
addPoseToTrajectory ( ) ;
setTrjID (
char
∗ getTrjID ( )
∗ trjID ) ;
const ;
setNumOfPoses ( uint64_t numOfPoses ) ;
const ;
void s e t P o s e S p e c i f i c a t i o n ( char ∗ p o s e S p e c i f i c a t i o n ) ;
POSE_SPECIFICATION g e t P o s e S p e c i f i c a t i o n ( ) const ;
void s e t S t a r t V e l o c i t i e s ( char ∗ s t a r t V e l o c i t i e s ) ;
double ∗ g e t S t a r t V e l o c i t i e s ( ) const ;
void s e t E n d V e l o c i t i e s ( char ∗ e n d V e l o c i t i e s ) ;
double ∗ g e t E n d V e l o c i t i e s ( ) const ;
void s e t V e l o c i t i e s ( char ∗ V e l o c i t i e s ) ;
double ∗ g e t V e l o c i t i e s ( ) const ;
void s e t A c c e l e r a t i o n s ( char ∗ a c c e l e r a t i o n s ) ;
double ∗ g e t A c c e l e r a t i o n s ( ) const ;
void s e t C o o r d i n a t e s ( char ∗ c C o o r d i n a t e s ) ;
double ∗ g e t C o o r d i n a t e s ( ) const ;
void showTime ( ) ;
uint64_t getNumberOfPoses ( )
25
30
35
s t d : : l i s t <ecp_smooth_taught_in_pose> ∗ g e t P o s e s ( ) ;
40
private :
char ∗
trjID ;
uint64_t numOfPoses ;
POSE_SPECIFICATION p o s e S p e c ;
45
ecp_smooth_taught_in_pose ∗ a c t P o s e ;
s t d : : l i s t <ecp_smooth_taught_in_pose> ∗ t r j P o s e s ;
};
Obiekt klasy
.trj.
Trajectory
Trajectory
posiada atrybuty oddaj¡ce natur¦ struktury zawarto±ci plików
Przedstawione s¡ one w poni»szym zestawieniu:
• trjID
jest to ci¡g znakowy b¦d¡cy identykatorem trajektorii, jego warto±¢ jest usta-
lana na podstawie identykatora stanu do jakiego nale»y trajektoria,
• numOfPoses
pole numeryczne przechowuj¡ce liczb¦ pozycji skªadaj¡cych si¦ na tra-
jektori¦,
• poseSpec pole przyjmuj¡ce warto±¢ typu wyliczeniowego POSE_SPECIFICATION. Oznacza w jaki sposób interpretowane s¡ przechowywane dane,
62
• actPose pole przechowuj¡ce wska¹nik do obiektu typu ecp_smooth_taught_in_pose,
• trjPoses
wska¹nik na list¦ przechowuj¡c¡ pozycje zawarte w danej trajektorii.
W li±cie poni»ej przedstawione i omówione s¡ metody, których denicje znalazªy si¦ w interfejsie klasy
Trajectory:
• setValuesInArray(double arrayToFill[], char * dataString)
metoda klasy. Jej zadanie polega na umieszczeniu warto±ci typu
jest to statyczna
double do tablicy prze-
kazanej jako pierwszy argument wywoªania na podstawie warto±ci zapisanych jako ci¡g
znaków i przedzielonych znakiem tabulacji, przekazanych w drugim argumencie wywoªania,
• returnProperPS(char *poseSpecification) jest to statyczna metoda, która na podstawie ci¡gu znaków przekazanych jako argument wywoªania ustala do której warto±ci
typu wyliczeniowego
POSE_SPECIFICATION
si¦ odnosi i zwraca warto±¢ tego typu,
• toString(double vallArr[], int length)
typu
double,
statyczna metoda zamieniaj¡ca tablic¦
przekazan¡ jako pierwszy argument wywoªania, o rozmiarze równym dru-
giemu argumentowi wywoªania, na zmienn¡ tekstow¡, któr¡ nast¦pnie zwraca,
• toString(int number)
statyczna metoda zmieniaj¡ca warto±¢ numeryczn¡ przeka-
zan¡ jako argument wywoªania, na string'a i zwracaj¡ca go,
• toString(POSE_SPECIFICATION ps)
to±¢ typu wyliczeniowego
statyczna metoda zmieniaj¡ca przekazan¡ war-
POSE_SPECIFICATION na odpowiadaj¡c¡ mu warto±¢ tekstow¡,
• returnRobotName(ROBOT_ENUM robot)
statyczna metoda zwracaj¡ca ci¡g znaków
odpowiadaj¡cy warto±ci typu wyliczeniowego, przekazanego jako argument wywoªania
funkcji,
• writeTrajectoryToXmlFile(char *fileName, POSE_SPECIFICATION ps,
std::list<ecp_smooth_taught_in_pose> &poses)
jest
to
statyczna
metoda
zapisuj¡ca do dokumentu XML trajektori¦ opisan¡ przez argumenty wywoªania tej
metody,
• createNewPose()
metoda
odpowiedzialna
za
utworzenie
nowego
obiektu
klasy
obiekt
typu
ecp_smooth_taught_in_pose,
• addPoseToTrajectory()
ecp_smooth_taught_in_pose
metoda
dodaj¡ca
do listy
trjPoses,
uprzednio
stworzony
• setTrjID(char *trjId) metoda ustawiaj¡ca identykator obiektu klasy Trajectory,
• getTrjID()
metoda zwracaj¡ca identykator obiektu klasy
• setNumOfPoses(uint64_t numOfPoses)
numOfPoses,
63
metoda
Trajectory,
ustawiaj¡ca
warto±¢
pola
• getNumberOfPoses()
metoda zwracaj¡ca warto±¢ pola
• setPoseSpecification(char *poseSpecification)
pola
poseSpec
metoda ustawiaj¡ca warto±¢
na podstawie argumentu wywoªania,
• getPoseSpecification()
• getPoses()
numOfPoses,
metoda zwracaj¡ca warto±¢ pola
metoda zwracaj¡ca wska¹nik do listy
poseSpec,
trjPoses.
Pozostaªe metody stanowi¡ zbiór akcesorów sªu»¡cych do ustawiania i zwracania warto±ci atrybutów obiektów klasy
zawartych w obiekcie typu
Trajectory.
S¡ to mianowicie:
• setStartVelocities(char *startVelocities)
• getStartVelocities()
• setEndVelocities(char *endVelocities)
• getEndVelocities()
• setVelocities(char *Velocities)
• getVelocities()
• setAccelerations(char *accelerations)
• getAccelerations()
• setCoordinates(char *cCoordinates)
• getCoordinates()
6.2 Implementacja mechanizmu realizuj¡cego zadania
W poprzednim podrozdziale zostaªy opisane klasy, które powstaªy by reprezentowa¢ elementy skªadaj¡ce si¦ na automat sko«czony po stronie struktury
MRROC++. W tej sekcji przed-
stawione zostanie ich u»ycie oraz opis mechanizmu realizuj¡cego zadania.
Na opisywany mechanizm skªada si¦ kod zapisany w plikach:
• mp_t_fsautomat.cc
• ecp_t_fsautomat_irp6ot.cc
• ecp_t_fsautomat_irp6p.cc
Oraz metody zaimplementowane w ju» istniej¡cych klasach skªadaj¡cych si¦ na struktur¦
MRROC++:
• ecp_task.cc
• ecp_g_smooth.cc
64
6.2.1
MP mechanizmu realizuj¡cego zadanie
Na proces
MP opisywanego mechanizmu, skªada si¦ klasa mp_task_fsautomat, kórej in-
tefejs przedstawiony jest na wydruku 27.
1
class
{
mp_task_fsautomat :
public
mp_task
protected :
bool b r e a k _ s t a t e ;
CubeState ∗ c u b e _ s t a t e ;
5
public :
mp_task_fsautomat ( c o n f i g u r a t o r &_ c o n f i g ) ;
~mp_task_fsautomat ( ) ;
10
void
void
task_initialization (
main_task_algorithm (
void ) ;
void ) ;
S t a t e ∗ c r e a t e S t a t e ( xmlNode ∗ s t a t e N o d e ) ;
char
s t d : : map<
15
bool
bool
bool
bool
bool
bool
bool
bool
bool
bool
bool
bool
bool
bool
20
25
30
void
void
∗ , S t a t e , ecp_task : : str_cmp> ∗ takeStatesMap ( ) ;
e x e c u t e M o t i o n ( S t a t e &s t a t e ) ;
runEmptyGenForSet ( S t a t e &s t a t e ) ;
runEmptyGen ( S t a t e &s t a t e ) ;
runWaitFunction ( S t a t e &s t a t e ) ;
stopProperGen ( S t a t e &s t a t e ) ;
sensorInitialization ();
i n i t i a l i z e C u b e S t a t e ( S t a t e &s t a t e ) ;
i n i t i a t e S e n s o r R e a d i n g ( S t a t e &s t a t e ) ;
g e t S e n s o r R e a d i n g ( S t a t e &s t a t e ) ;
w r i t e C u b e S t a t e ( S t a t e &s t a t e ) ;
changeCubeState ( S t a t e &s t a t e ) ;
changeCubeState (
int
turn_angle ) ;
communicate_with_windows_solver ( S t a t e &s t a t e ) ;
t r a n s l a t e M a n i p u l a t i o n S e q u e n c e ( StateHeap &sh ) ;
configureProperSensor (
char
∗ propSensor ) ;
configureProperTransmitter (
char
∗ propTrans ) ;
s t d : : l i s t <S i n g l e M a n i p u l a t i o n > m a n i p u l a t i o n _ l i s t ;
35
};
Obiekt klasy
mp_task_fsautomat
• cube_state
mp_task_fsautomat
zawiera nast¦puj¡ce atrybuty:
atrybut przechowuj¡cy wska¹nik na obiekt typu
rzystywany jest po stronie struktury
MRROC++
CubeState,
który wyko-
do reprezentowania stanu kostki Rubika
w zadaniu ukªadania tej kostki. Obiekt jest powoªywany do »ycia na podstawie wpisu
dotycz¡cego inicjalizacji
• break_state
MP w dokumencie XML,
atrybut przechowuj¡cy zmienn¡ logiczn¡ reprezentuj¡ca stan procesu
65
MP,
• manipulation_list
atrybut przechowuj¡cy list¦ manipulacji, czyli list¦ ruchów, któ-
rych wykonanie prowadzi do uªo»enia kostki Rubika. Aby omawiany mechanizm byª
w stanie uªo»y¢ kostk¦, lista ta musi by¢ przetªumaczona na inn¡ reprezentacj¦.
Pozostaª¡
zawarto±¢
interfejsu
klasy
mp_task_fsautomat
tworz¡
deklaracje
metod.
W wi¦kszo±ci, s¡ to metody zwi¡zane z typem stanu i wywoªywane przy wej±ciu automatu
w
okre±lony
stan.
Poni»ej
przedstawiono
i
opisano
zestawienie
metod
klasy
mp_task_fsautomat:
• task_initialization()
metoda wymagana w implementacji klasy procesu
MP
-
odpowiada za inicjalizacj¦. W przyj¦tej implementacji mechanizmu funkcja ta, na podstawie informacji zawartej w stanie o identykatorze
INIT, dokonuje wskazanych inicja-
lizacji,
• main_task_algorithm()
mentacji procesu
podobnie jak powy»sza metoda, jest wymagana do imple-
MP. W ciele tej metody znajduje si¦ kod realizuj¡cy mechanizm auto-
matu sko«czonego,
• createState(xmlNode *stateNode)
argument w¦zªa elementu
metoda, która na podstawie przekazanego jako
<State> dokumentu XML, tworzy obiekt klasy State i zwraca
wska¹nik do tego obiektu,
• takeStatesMap()
metoda, która wczytuje dokument XML. Opis dziaªania automatu
zawarty w elementach
<State>
umieszcza w mapie w postaci obiektów typu
State,
których indeksami s¡ identykatory stanów, a nast¦pnie zwraca utworzon¡ map¦,
• executeMotion(State &) metoda odpowiedzialna za wykonanie akcji zawartej w stanie typu
runGenerator,
• runEmptyGenForSet(State &)
w stanie typu
metoda odpowiedzialna za wykonanie akcji zawartej
emptyGenForSet,
• runEmptyGen(State &) metoda odpowiedzialna za wykonanie akcji zawartej w stanie
typu
emptyGen,
• runWaitFunction(State &)
w stanie typu
wait,
• stopProperGen(State &) metoda odpowiedzialna za wykonanie akcji zawartej w stanie typu
stopGen,
• sensorInitialization() metoda odpowiedzialna za wykonanie akcji zawartej w stanie typu
systemInitialization,
• initializeCubeState(State &) metoda odpowiedzialna za wykonanie akcji zawartej
w stanie typu
cubeStateInit,
66
• initiateSensorReading(State &)
wartej w stanie typu
initiateSensorReading,
• getSensorReading(State &)
w stanie typu
metoda odpowiedzialna za wykonanie akcji za-
getSensorReading,
• writeCubeState(State &) metoda odpowiedzialna za wykonanie akcji zawartej w stanie typu
cubeStateWriting,
• changeCubeState(State &)
w stanie typu
cubeStateChange,
• changeCubeState(int)
wartej w stanie typu
przeci¡»ona metoda odpowiedzialna za wykonanie akcji za-
cubeStateChange,
• communicate_with_windows_solver(State &) metoda odpowiedzialna za wykonanie
akcji zawartej w stanie typu
communicateWithSolver,
• translateManipulationSequence(StateHeap &)
nanie akcji zawartej w stanie typu
metoda odpowiedzialna za wyko-
manipulationSeqTranslation,
• configureProperSensor(char *)
metoda odpowiedzialna za wykonanie akcji zwi¡-
zanej z konguracj¡ sensora, którego nazwa jest przekazana jako argument wywoªania,
• configureProperTransmitter(char *)
metoda odpowiedzialna za wykonanie akcji
zwi¡zanej z konguracj¡ transmitera, którego nazwa jest przekazana jako argument
wywoªania.
Funkcja mp_task_fsautomat::main_task_algorithm()
Funkcja
mp_task_fsautomat::main_task_algorithm() realizuje gªówny algorytm wyko-
nywany przez proces
MP. Ciaªo tej metody jest pokazane na wydruku 31.
W pierwszych liniach tej funkcji nast¦puje deklaracja zmiennych i obiektów klas, które s¡
w niej wykorzystywane, czyli m.in. obiekt klasy
StateHeap,
czy ci¡g znaków przechowuj¡cy
identykator stanu. W linii nr 6 znajduje si¦ deklaracja i inicjalizacja wska¹nika do mapy
stateMap.
Przypisanie adresu do wspomnianego wska¹nika odbywa si¦ za pomoc¡ wcze±niej
wspomnianej metody
takeStatesMap().
Funkcja ta jest odpowiedzialna za wczytanie doku-
mentu XML z denicj¡ zadania, utworzeniu odpowiednich obiektów klasy
elementów
<State>
State na podstawie
zawartych w dokumencie i umieszczeniu tych stanów w mapie, gdzie in-
deksami s¡ identykatory stanów, do której adres funkcja zwraca. Tak utworzona mapa stanów
stanowi reprezentacj¦ tre±ci zapisanej w dokumencie XML po stronie struktury
MRROC++.
Aby mo»liwe byªo rozpocz¦cie pracy automatu sko«czonego, konieczne jest okre±lenie stanu
pocz¡tkowego automatu. Zgodnie z konwencj¡ przyj¦t¡ wcze±niej, stanem pocz¡tkowym automatu, jest stan o identykatorze
si¦ przypisanie warto±ci
INIT
INIT.
Tak te» w linii nr 15 omawianego wydruku pojawia
do zmiennej przechowuj¡cej nazw¦ stanu, do którego wchodzi
67
automat. W kolejnych liniach (17-18) znajduje si¦ p¦tla
for, która zapewnia realizowanie za-
pisanego w mapie zadania zgodnie z logik¡ maszyny stanowej. Cze±¢ instrukcji odpowiedzialna
za inicjalizacj¦, jest pusta gdy» zostaªa ona przeprowadzona wcze±niej (linia 15). W cz¦±ci odpowiedzialnej za sprawdzenie warunku ko«ca p¦tli
nicj¡, mówi¡ca, »e pojawienie si¦ identykatora
for
zapisana jest instrukcja, zgodna z de-
_STOP_
powoduje koniec pracy automatu,
czyli w tym przypadku, wyj±cie z p¦tli. W kolejnej cz¦±ci nast¦puje wyznaczenie kolejnego
stanu automatu. Jest to zapisane jako nast¦puj¡ca instrukcja:
1
s t r c p y ( n e x t S t a t e , ( ∗ stateMap ) [ n e x t S t a t e ] . r e t u r n N e x t S t a t e I D ( sh ) )
Oznacza ona, »e na rzecz obecnego stanu wywoªywana jest metoda
returnNextStateID(),
a warto±¢ przez ni¡ zwrócona przypisywana jest do identykatora stanu, po czym wykonywane
jest ciaªo p¦tli. Mo»liwe jest ró»ne zachowanie si¦ metody
od warto±ci
•
gdy
targetID
•
gdy
tranzycji stanu, której warunek zostaª speªniony. Mianowicie:
tagetID = id_stanu
warto±¢
jest to sytuacja typowa, przez funkcj¦ zostanie zwrócona
id_stanu,
targetID = id_podzadaniaid_stanu
targetID
stowa
returnNextStateID() w zale»no±ci
zawiera
id_stanu
jest to sytuacja, gdzie warto±¢ pola
operator skoku do podzadania.
W
takiej
sytuacji
warto±¢
tek-
zostaje odªo»ona na stosie, a przez funkcj¦ zostaje zwrócona warto±¢
id_podzadania,
•
gdy
targetID = _END_ jest to identykator ko«ca podzadania, w takiej sytuacji funk-
cja zwraca identykator stanu, który jako ostatni zostaª odªo»ony na stos.
W ciele omawianej p¦tli znajduj¡ si¦ instrukcje warunkowe, które maj¡ za zadanie sprawdzi¢
typ stanu, w jakim znalazª si¦ automat i w zale»no±ci od niego, wykona¢ akcj¦ zwi¡zan¡ ze
stanem (linie 20-103). Po wykonaniu danej akcji, konieczne jest wyznaczenie identykatora
kolejnego stanu, do którego przejdzie maszyna. Operacja ta jest wykonywana za pomoc¡
opisanej wy»ej instrukcji.
6.2.2 Przykªadowe
Na procesy
ECP opisywanego mechanizmu realizacji zadania skªada si¦ proces ECP robota
IRP6_ON_TRACK
interfejs klasy
1
class
{
ECP mechanizmu realizuj¡cego zadanie
oraz
IRP6_POSTUMENT.
Na wydruku 28 jako przykªad, zostaª przedstawiony
ecp_task_fsautomat_irp6ot
ecp_task_fsautomat_irp6ot :
public
ecp_task
protected :
ecp_smooth_generator ∗ s g ;
5
ecp_tool_change_generator ∗ t c g ;
ecp_generator_t ∗ g t ;
ecp_tff_nose_run_generator ∗ nrg ;
ecp_tff_rubik_grab_generator ∗ r g g ;
e c p _ t f f _ g r i p p e r _ a p p r o a c h _ g e n e r a t o r ∗ gag ;
68
ecp_tff_rubik_face_rotate_generator ∗ r f r g ;
10
ecp_teach_in_generator ∗ t i g ;
bias_edp_force_generator ∗ befg ;
weight_meassure_generator ∗ wmg;
ecp_sub_task_gripper_opening ∗ go_st ;
15
char ∗ ,
s t d : : map<
T r a j e c t o r y , str_cmp>∗ trjMap ;
public :
ecp_task_fsautomat_irp6ot ( c o n f i g u r a t o r &_ c o n f i g ) ;
~ecp_task_fsautomat_irp6ot ( ) ;
20
void
void
};
void ) ;
main_task_algorithm ( void ) ;
task_initialization (
Jak
wida¢
na
powy»szym
wydruku,
je±li
chodzi
o
deklaracje
metod,
jest zgodna z konwencj¡ stosowan¡ w strukturze
tycz¡c¡ tworzenia klas wywodz¡cych si¦ z klasy
ecp_task.
klasa
MRROC++,
do-
Zaimplementowe zostaªy tutaj
dwie funkcje:
• task_initialization()
- jest to metoda odpowiedzialna za inicjalizacj¦ obiektów,
które b¦d¡ wykorzystywane przez proces
ECP. Inicjalizacja ta jest dokonywana na pod-
stawie informacji zawartych w obiekcie klasy
• main_task_algorithm()
procesu
State
o identykatorze
INIT,
- jest to metoda, która na podstawie zlece« pochodz¡cych od
MP, uruchamia wskazany generator z przekazanymi argumentami wywoªania.
Atrybuty tej klasy stanowi¡ wska¹niki do generatorów:
• sg
wska¹nik na obiekt klasy
• tcg
• gt
ecp_smooth_generator,
ecp_tool_change_generator,
ecp_generator_t,
• nrg
ecp_tff_nose_run_generator,
• rgg
ecp_tff_rubik_grab_generator,
• gag
ecp_tff_gripper_approach_generator,
• rfrg
• tig
• befg
• wmg
ecp_teach_in_generator,
ecp_tff_rubik_face_rotate_generator,
bias_edp_force_generator,
weight_meassure_generator,
69
• go_st
ecp_sub_task_gripper_opening.
W zale»no±ci od potrzeby u»ycia danego generatora przy wykonaniu konkretnego zadania
u»ytkowego, s¡ one inicjalizowane w metodzie
task_initialization().
Dodatkowym atrybutem obiektu omawianej klasy jest wska¹nik przechowuj¡cy adres mapy
trjMap,
która zawiera obiekty klasy
Trajectory.
Indeksy mapy stanowi¡ identykatory tych
obiektów. Przypisanie adresu do wspomnianego wska¹nika odbywa si¦ przy pomocy metody
ecp_task,
klasy bazowej
a mianowicie
loadTrajectories(char * , ROBOT_ENUM ).
To czy
nast¡pi inicjalizacja tego obiektu uzale»nione jest od wpisu w pliku konguracyjnym tego
zadania
1
fsautomat.ini.
Na wydruku 29 znajduje si¦ przykªad takiego wpisu:
[ xml_settings ]
x m l _ f i l e=data / r c s c . xml
trajectory_from_xml=1
t r a j e c t o r y _ o n _ e c p _ l e v e l=1
Wydruk 29: Fragment pliku konguracyjnego
fsautomat.ini
6.2.3 Metody dodane do klasy ecp_task
Poni»sze zestawienie zawiera metody, które zostaªy dodane na potrzeby omawianej pracy
do istniej¡cej ju» w systemie
MRROC++,
denicji klasy bazowej
ecp_task,
mianowicie:
• Trajectory * createTrajectory(xmlNode *actNode, xmlChar *stateID)
metoda zwracaj¡ca obiekt klasy
Trajectory
na podstawie w¦zªa XML
jest to
<Trajectory>
przekazanego w argumencie wywoªania i o identykatorze analogicznym do identykatora stanu, przekazanym jako drugi argument wywoªania,
• std::map<char*, Trajectory, str_cmp>* loadTrajectories(char * fileName,
ROBOT_ENUM propRobot)
obiekty typu
jest to metoda zwracaj¡ca adres do mapy przechowuj¡cej
Trajectory.
Wywoªywana jest w momencie, kiedy wpis w sekcji
XML
pliku konguracyjnego jest analogiczny do wpisu przedstawionego na przykªadzie 29.
W takim przypadku, w trakcie dziaªania programu, trajektoria nie jest wczytywana
.trj
z pliku (
czy te» dokumentu XML z zadaniem) tylko jest pobierana i wykonywana
na podstawie obiektu przechowywanego w pami¦ci programu.
6.2.4 Metody dodane do klasy ecp_smooth_generator
W
poni»szym
zestawieniu
zostaªy
przedstawione
metody
dodane
do
denicji
klasy
w ramach implementacji mechanizmu realizacji zada« zapisanych
zgodnie z denicj¡ j¦zyka, która jest przedmiotem tej pracy:
• set_pose_from_xml(xmlNode *stateNode, bool &first_time)
daj¡ca do przechowywanej przez omawian¡ klas¦ listy
jest to metoda do-
pose_list,
wyznaczanego na podstawie w¦zªa
XML, przekazanego jako argument wywoªania funkcji,
70
obiektu klasy
<Pose>
dokumentu
• load_trajectory_from_xml(char* fileName, char* nodeName)
której dziaªanie jest analogiczne do istniej¡cej w klasie
cji
load_file_with_path (const char* file_name).
jest to metoda,
funk-
W tej wersji metoda wczytuje
trajektori¦ ze stanu o podanym w argumencie wywoªania identykatorze z pliku XML,
którego nazwa równie» stanowi argument wywoªania funkcji,
• load_trajectory_from_xml(Trajectory &trajectory)
jest to przeci¡»ona wersja
metody omówionej poni»ej. Jej zadaniem jest wczytanie trajektorii na podstawie referencji do obiektu klasy
Jak
wida¢
na
Trajectory
powy»szym
przekazanej jako argument wywoªania funkcji.
zestawieniu,
mo»emy
tworzy¢
trajektori¦,
wykorzystuj¡c
czyli
do
list¦
tego
trzy
obiektów
ró»ne
me-
tody. Aby okre±li¢, w jaki sposób ma si¦ to odbywa¢, konieczna jest odpowiednia konguracja
mechanizmu, która jest zawarta w pliku
fsautomat.ini
i opisana poni»ej 6.3.
6.3 Plik konguracyjny fsautomat.ini
Plik
fsautomat.ini,
przechowuj¡cy konguracj¦ moduªu realizacji zadania u»ytkowego
zapisanego w dokumencie XML ma struktur¦ analogiczn¡ do plików konguracyjnych innych
zada« u»ytkowych zdeniowanych i uruchamianych w systemie
niaj¡cym omawian¡ konguracj¦ jest sekcja
[xml_settings],
MRROC++.
Elementem wyró»-
która zawiera trzy konguro-
walne parametry, tak jak jest to pokazane na poni»szym wydruku 30
1
[ xml_settings ]
x m l _ f i l e=data / p o u r i n g . xml
trajectory_from_xml=0
t r a j e c t o r y _ o n _ e c p _ l e v e l=0
Wydruk 30: Fragment pliku konguracyjnego
fsautomat.ini
Kolejne parametry omawianej sekcji pliku konguracyjnego oznaczaj¡:
• xml_file=data/pouring.xml
pole okre±laj¡cy ±cie»k¦ do pliku z denicj¡ zadania
u»ytkowego zapisan¡ w dokumencie XML,
• trajectory_from_xml
jest to pole przyjmuj¡ce warto±¢ 0 lub 1. Okre±la, czy trajek-
toria pobierana przez obiekt generatora
z plików trajektorii z rozszerzeniem
.trj
wczytywana jest
(gdy 0), czy z dokumentu XML z denicja
zadania (gdy 1),
• trajectory_on_ecp_level
pole, które w przypadku zaznaczenia opcji wczytywania
trajektorii z dokumentu XML (pole
trajectory_from_xml
ma przypisan¡ warto±¢ 1),
okre±la sposób w jaki jest ona czytana:
gdy ustawione jest na 0 wczytywanie trajektorii odbywa si¦ analogicznie jak
za pomoc¡ metody
load_file_with_path (const char* file_name)
z t¡ ró»-
nic¡, »e wczytywana jest trajektoria z dokumentu XML, która wyszukana jest
71
na podstawie identykatora stanu, który ja przechowuje. U»yta zostaje metoda
load_trajectory_from_xml(char* fileName, char* nodeName),
gdy
w
s¡
równa
momencie
w
si¦
1
w
powstania
pami¦ci
tym
procesu
programu
obiektu generatora
przypadku
w
ECP.
postaci
wczytanie
Wczytane
mapy,
a
trajektorii
trajektorie
przekazanie
si¦
przechowywane
trajektorii
do
odbywa si¦ za pomoc¡ metody
load_trajectory_from_xml(Trajectory &trajectory).
72
odbywa
7 Podsumowanie
7.1 Wnioski
W ramach pracy powstaª j¦zyk opisu zada« wielorobotowych, umo»liwiaj¡cy zapisywanie zada« u»ytkowych, implementowanych na bazie struktury ramowej
MRROC++,
w postaci
automatu sko«czonego, zapisywanego jako dokument XML. Stworzono równie» mechanizm
realizacji tak zdeniowanych zada« po stronie systemu
MRROC++.
Zaproponowany j¦zyk za-
wiera denicje elementów wykorzystywanych do opisu zada« w omawianej notacji oraz zbiór
reguª okre±laj¡cych sposób jego konstruowania. Reguªy te przechowywane s¡ w pliku denicji
typu danych DTD (fsautomat.dtd).
Zastosowany tutaj uniwersalny j¦zyk formalny XML przeznaczony jest do ujednolicenia
struktury i formatu ró»nego rodzaju danych. Pozwala prezentowa¢ je w ustrukturalizowany
sposób i zapisywa¢ w postaci dokumentu tekstowego, dzi¦ki czemu jest niezale»ny od systemu
operacyjnego. Tym samym, zadanie u»ytkowe zapisane w j¦zyku omawianym w tej pracy,
mo»e by¢ deniowane na dowolnej platformie sprz¦towej, bez konieczno±ci anga»owania w tym
procesie elementów systemu
Struktura ramowa
MRROC++.
MRROC++
jest wykorzystywana dopiero na etapie uruchamiania zadania
u»ytkowego zapisanego w dokumencie XML. Jednym z podstawowych elementów skªadaj¡cych si¦ na implementacj¦ opisywanego mechanizmu jest biblioteka
libxml.
Jest to darmowa
biblioteka do obsªugi dokumentów XML przy u»yciu j¦zyka C/C++, która oprócz parsera
XML'a, dostarcza szereg narz¦dzi wspomagaj¡cych prac¦ nad dokumentami XML.
Istotnym elementem zaimplementowanego moduªu systemu
MRROC++
jest równie» mecha-
nizm realizuj¡cy wykonywanie podzada«. Skªada si¦ na niego stos automatu sko«czonego oraz
XInclude, który jest mechanizmem scalania dokumentów XML. Zastosowanie tych dwóch rozwi¡za« pozwala na skrócenie opisu zadania u»ytkowego zawartego w dokumencie XML oraz
pozytywnie wpªywa na jego czytelno±¢ i logiczn¡ organizacj¦.
Stworzone rozwi¡zanie, umo»liwia zapisanie zada« u»ytkowych implementowanych na bazie struktury ramowej
MRROC++
w postaci automatu sko«czonego. Zostaªo ono zwerykowane
na zadaniach nalewania oraz zadania ukªadania kostki Rubika. Wspomniane zadania zostaªy
zapisane w dokumentach XML zgodnie z denicj¡ j¦zyka przyj¦t¡ w niniejszej pracy i uruchomione w systemie
MRROC++
przy wykorzystaniu mechanizmu interpretuj¡cego i wykonuj¡cego
zdeniowane zadanie.
7.2 Perspektywy rozwoju
W wyniku przeprowadzonych prac zostaªa stworzona denicja j¦zyka zapisu zada« wielorobotowych w dokumencie XML. Na chwil¦ obecn¡ dokument XML zawieraj¡cy tre±¢ zadania
u»ytkowego tworzony jest przez operatora, który opisuje zadanie wykorzystuj¡c zdeniowane
przez j¦zyk elementy.
Aby uªatwi¢ i w znacznym stopniu przyspieszy¢ ten proces planowane jest stworzenie gracznego narz¦dzia uªatwiaj¡cego przeprowadzenie procesu projektowania zadania. Deniowa-
73
nie tego zadania miaªo by przypomina¢ tworzenie diagramu stanów obrazuj¡cego dziaªania
automatu sko«czonego. Od projektanta zadania wymagane ma by¢ okre±lenie akcji zwi¡zanych ze stanami, tranzycji do innych stanów i ich warunków. Efektem dziaªania takiej aplikacji
b¦dzie dokument XML z opisem zadania, który na t¦ chwil¦ jest zapisywany r¦cznie.
74
Literatura
[1] C. Zieli«ski, W. Szynkiewicz, T. Winiarski, and T. Kornuta. MRROC++ Based System
Description. Technical Report 06-9, IAIS, Warsaw, 2006.
[2] QNX Realtime operating system (RTOS), www.qnx.com.
[3] Zieli«ski C., Grodecki A., Kr¦glewska U., Sobczyk J., ±luzek A., and Zieli«ska T. Sterownik
robotów przeznaczony do celów badawczych opracowanie dla KBN, grudzie« 1992.
[4] Szynkiewicz W., Zieli«ski C., Kierzenkowski K., and Zieli«ska T. ±rodowisko programowe
do tworzenia sterowników wielorobotowych dla zªo»onych zastosowa«.
Automation'97,
1:127134, marzec 1997.
[5] C. Zieli«ski, T. Winiarski, W. Szynkiewicz, M. Staniak, W. Czajewski, and T. Kornuta.
MRROC++ Based Controller of a Dual Arm Robot System Manipulating a Rubik's Cube.
Technical Report 06-10, IAIS, Warsaw, 2006.
[6] Extensible markup language (xml) 1.0 (fourth edition), http://www.w3.org/tr/rec-xml/.
[7] Relax ng - schema language for xml, http://www.relaxng.org/.
[8] Xml inclusions (xinclude) version 1.0 (second edition), http://www.w3.org/tr/xinclude/.
75
Dodatek A
Funkcja
1
void
mp_task_fsautomat::main_task_algorithm():
mp_task_fsautomat : : main_task_algorithm (
{
void )
StateHeap sh ;
b r e a k _ s t a t e=
5
char
false ;
∗ nextState =
char
s t d : : map<
new char [ 6 4 ] ;
∗ , S t a t e , ecp_task : : str_cmp> ∗ stateMap = takeStatesMap ( ) ;
sr_ecp_msg−>message ( "MP d l a Automatu Skonczonego − w c i s n i j s t a r t " ) ;
wait_for_start ( ) ;
10
// Wyslanie START do wszystkich \ECP\
s t a r t _ a l l ( robot_m ) ;
for
(;;)
{
15
s p r i n t f ( n e x t S t a t e , "INIT" ) ;
for ( ; strcmp ( n e x t S t a t e , ( const char
∗ ) "_STOP_" ) ; s t r c p y ( n e x t S t a t e ,
( ∗ stateMap ) [ n e x t S t a t e ] . r e t u r n N e x t S t a t e I D ( sh ) ) )
{
20
i f ( ! strcmp ( n e x t S t a t e , ( const char
∗ ) "_END_" ) )
s t r c p y ( n e x t S t a t e , sh . popTargetName ( ) ) ;
// protection from wrong targetID specyfication
25
i f ( stateMap −>count ( n e x t S t a t e )==0)
break ;
i f ( strcmp ( ( ∗ stateMap ) [ n e x t S t a t e ] . getType ( ) ,
( const char ∗ ) " ru nG en er at or " ) == 0 )
{
i f ( ! e x e c u t e M o t i o n ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
s t d : : cout<<n e x t S t a t e <<" −> zakonczony "<<s t d : : e n d l ;
30
}
( const char ∗ ) " emptyGenForSet " ) == 0 )
{
i f ( ! runEmptyGenForSet ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
35
}
( const char ∗ ) "emptyGen" ) == 0 )
{
40
i f ( ! runEmptyGen ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
}
( const char ∗ ) " w a i t " ) == 0 )
45
{
i f ( ! runWaitFunction ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
76
}
50
( const char ∗ ) " stopGen " ) == 0 )
{
i f ( ! stopProperGen ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
}
55
( const char ∗ ) " s y s t e m I n i t i a l i z a t i o n " ) == 0 )
{
s t d : : cout<<" In s e n s o r i n i t i a l i z a t i o n . . "<<s t d : : e n d l ;
if (! sensorInitialization ())
60
}
( const char ∗ ) " c u b e S t a t e I n i t " ) == 0 )
{
65
i f ( ! i n i t i a l i z e C u b e S t a t e ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
}
( const char ∗ ) " i n i t i a t e S e n s o r R e a d i n g " ) ==
70
{
0)
i f ( ! i n i t i a t e S e n s o r R e a d i n g ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
}
75
( const char ∗ ) " g e t S e n s o r R e a d i n g " ) == 0 )
{
i f ( ! g e t S e n s o r R e a d i n g ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
}
80
( const char ∗ ) " c u b e S t a t e W r i t i n g " ) == 0 )
{
i f ( ! w r i t e C u b e S t a t e ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
85
}
( const char ∗ ) " cubeStateChange " ) == 0 )
{
i f ( ! changeCubeState ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
90
}
( const char ∗ ) " communicateWithSolver " ) ==
{
95
0)
i f ( ! communicate_with_windows_solver ( ( ∗ stateMap ) [ n e x t S t a t e ] ) )
77
}
( const char ∗ ) " m a n i p u l a t i o n S e q T r a n s l a t i o n " )
{
100
== 0 )
i f ( ! t r a n s l a t e M a n i p u l a t i o n S e q u e n c e ( sh ) )
}
}
// Oczekiwanie na STOP od UI
105
wait_for_stop (MP_THROW) ;
// Wyslanie STOP do wszystkich \ECP\ po zakonczeniu programu uzytkownika
t e r m i n a t e _ a l l ( robot_m ) ;
}
110
break ;
// koniec : for ( ; ; )
−
wewnetrzna petla
}
Wydruk 31: Ciaªo metody
mp_task_fsautomat::main_task_algorithm()
78

(Jezyk opisu i realizacja zadan przez automat skonczony w systemie

Transkrypt

Podobne dokumenty

Robot antyterrorystyczny otrzymał znak „Teraz Polska”!

Pobierz plik

Przeczytaj relację.

Załącznik