Gra czna konsola sterownicza systemu MRROC++ stworzona w

J¦drzej Kuryªo
Graczna konsola sterownicza systemu
MRROC++ stworzona w oparciu
o platform¦ Java
Praca dyplomowa in»ynierska pod kierunkiem
mgr in». Tomasza Winiarskiego
Instytut Automatyki i Informatyki Stosowanej
Politechniki Warszawskiej
Warszawa, Wrzesie« 2008
Streszczenie
Celem mojej pracy in»ynierskiej byªo zaprojektowanie i implementacja nowej gracznej konsoli sterowniczej systemu MRROC++ na podstawie istniej¡cego ju» rozwi¡zania. W przeciwie«stwie do pierwowzoru, miaªa ona umo»liwia¢ zdaln¡ prac¦ w
systemie, by¢ przeno±na mi¦dzy ró»nymi platformami sprz¦towymi i programowymi, a
jej dystrybucja i aktualizacja powinna by¢ mo»liwie nieskomplikowana.
Graczna konsola sterownicza zostaªa zrealizowana w architekturze klient-serwer.
Serwer aplikacji napisany zostaª w j¦zyku C++ i dziaªa jako jeden z procesów systemu
MRROC++. Aplikacja kliencka to applet j¦zyka Java. Komunikacja pomi¦dzy klientem
i serwerem odbywa si¦ przy pomocy pary protokoªów TCP/IP.
Powstaªa w ramach pracy konsola speªnia wszystkie stawiane przed ni¡ wymagania,
oferuje równie» mo»liwo±ci niedost¦pne w pierwowzorze. Poprawno±¢ dziaªania aplikacji
zwerykowana zostaªa w warunkach laboratoryjnych podczas sterowania rzeczywistymi
robotami.
Abstract
Title: Java based MRROC++ graphical user Interface
The aim of this thesis was to design and implement a new graphical user interface
for the MRROC++ system, based on the existing console. Unlike its prototype, the
new interface had to provide remote access to the MRROC++ system. Moreover, it
had to be a cross-platform and easy to distribute and update.
The new graphical user interface uses client-server model. The server was written
in C++ and works as one of MRROC++ processes. The graphical user interface is a
Java applet, communicating with server via TCP/IP protocols.
Application meets all the requirements, but it also oers some new functions. It has
proved to work properly in the laboratory experimental setup.
2
Spis tre±ci
1 Wst¦p
4
1.1
Geneza pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Wprowadzenie do systemu MRROC++
6
2.1
Struktura ramowa MRROC++ . . . . . . . . . . . . . . . . . . . . . .
6
2.2
Graczna konsola sterownicza . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.1
Podstawowe elementy . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.2
Realizowane funkcje
. . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.3
Wady dotychczasowego rozwi¡zania . . . . . . . . . . . . . . . .
10
3 Opis wybranych technologii
12
3.1
Platforma Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2
Biblioteka Java Swing
. . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.3
Applet j¦zyka Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.4
Protokóª TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.5
Protokóª Rsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4 Realizacja aplikacji
19
4.1
Identykatory operacji . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2
Klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.1
Struktura aplikacji . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.2
Klasa MrrocppUI . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2.3
Okna dialogowe . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.2.4
Klasy robotów . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.3
Serwer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.4
Komunikacja
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.4.1
Klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.4.2
Serwer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.5
5 Podsumowanie
41
5.1
Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2
Perspektywy rozwoju . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Literatura
43
Dodatek A - Dodanie obsªugi nowego robota
44
3
1 Wst¦p
1.1 Geneza pracy
Cz¦st¡ sytuacj¡ podczas programowania systemów robotowych jest wytwarzanie
podobnych do siebi¦ programów, jednak dziaªaj¡cych na ró»nym sprz¦cie, realizuj¡cych
nieco odmienne zadania. Wtedy w sukurs przychodz¡ programowe struktury ramowe,
wspomagaj¡ce tworzenie sterowników dla systemów robotowych. Zawieraj¡ one moduªy
i wzorce programowe oraz narz¦dzia przydatne przy realizacji programów steruj¡cych.
Jedn¡ z takich programowych struktur ramowych jest MRROC++1 [1] stworzona w
Instytucie Automatyki i Informatyki Stosowanej Politechniki Warszawskiej. Wspomaga
ona tworzenie sterowników dla wspóªbie»nych systemów wielorobotowych. Napisana
w j¦zyku C++ dziaªa pod kontrol¡ systemu operacyjnego czasu rzeczywistego QNX
Neutrino [2]. Jednym z komponentów MRROC++ jest graczna konsola sterownicza,
umo»liwiaj¡ca m.in. uruchamianie procesów steruj¡cych i zada«, r¦czne sterowanie
manipulatorami oraz udost¦pniaj¡c¡ informacje o stanie systemu.
Po latach u»ytkowania istniej¡cej gracznej konsoli sterowniczej okazaªo si¦, i» nie
do ko«ca speªnia ona oczekiwania obecnych u»ytkowników. Rozwój informatyki i pokrewnych jej dziedzin przyniósª rozwój nowych technologii, a wraz z nim wzrost oczekiwa« u»ytkowników stawianych aplikacjom. Cz¦±¢ zastosowanych rozwi¡za« okazaªa si¦
by¢ przestarzaªa, a nowe technologie pozwalaj¡ obecnie na realizacj¦ pewnych aspektów
dziaªania konsoli w efektywniejszy sposób. Dlatego te» pojawiª si¦ pomysª zrealizowania
nowej wersji gracznej konsoli sterowniczej w oparciu o istniej¡ce dotychczas rozwi¡zanie. Nie tylko realizowane funkcje, ale równie» wygl¡d konsoli, mo»liwie zbli»ony do
dotychczas stosowanej, umo»liwi¢ miaªy mo»liwie szybk¡ i bezproblemow¡ migracj¦
u»ytkowników na now¡ wersj¦. Nowa wersja konsoli za± miaªaby stanowi¢ tak»¦ solidn¡
baz¦, rozszerzan¡ pó¹niej o nowe funkcje.
Z mojej strony zainteresowanie projektem i realizacj¡ nowej wersji gracznej konsoli
sterowniczej systemu MRROC++ wynikaªo z umiejscowienia tego tematu na pograniczu kilku ciekawych dziedzin - robotyki i programowania systemu wieloorobotowego z
jednej strony, a ciesz¡cej si¦ ogromn¡ popularno±ci¡ technologi¡ Java z drugiej strony.
Dodatkow¡ motywacj¡ byª równie» fakt rzeczywistego wykorzystania konsoli w pracy
z systemem wielorobotowym.
1.2 Cel pracy
Celem mojej pracy in»ynierskiej byªo zaprojektowanie i realizacja gracznej konsoli sterowniczej systemu MRROC++ o mo»liwo±ciach pierwotnej konsoli. Aby nada¢
jednak sens powielaniu ju» istniej¡cej i z powodzeniem u»ywanej aplikacji, przed re1 Multi-Robot
Research Oriented Controller
4
alizowan¡ konsol¡ postawiony zostaª szereg wymaga«, których pierwotna konsola nie
speªnia, a które uznano za istotne w obliczu rozwoju technologii i metodologii programowania, jak i zmian w systemie MRROC++.
Podstawowym z tych wymaga« jest wieloplatformowo±¢ rozwi¡zania, rozumiana
jako umo»liwienie sterowania systemem wielorobotowym przy u»yciu mo»liwie dowolnej sprz¦towej i programowej konguracji komputera. Dotychczas u»ywana konsola
mo»e by¢ uruchamiana jedynie pod kontrol¡ systemu operacyjnego QNX Neutrino,
jednak sama w sobie nie korzysta ze szczególnych cech tego systemu czasu rzeczywistego. Nie ma wi¦c istotnych przeciwwskaza«, by umo»liwi¢ uruchomienie jej w innych
systemach, zwªaszcza »e w obliczu dzisiejszej ró»norodno±ci u»ywanych systemów operacyjnych taka mo»liwo±¢ jest wskazana. Wymaganie to dodatkowo zyskuje na wa»no±ci
w obliczu trwaj¡cych ju» od dªu»szego czasu prac nad przeniesieniem na platformy inne
ni» QNX niektórych elementów struktury MRROC++ i ±rodowiska programistycznodeveloperskiego.
Równie po»¡dan¡ cech¡, co wieloplatformowo±¢ rozwi¡zania, jest mo»liwo±¢ pracy
zdalnej w systemie MRROC++ przy wykorzystaniu niezale»nych od platformy protokoªów sieciowych. Dotychczasowe rozwi¡zanie, mimo »e dziaªaj¡ce w ±rodowisku rozproszonym, dopuszcza prac¦ jedynie w obr¦bie sieci lokalnej QNET2 , a to ograniczenie
jest nieuzasadnione w obliczu ªatwego obecnie dost¦pu do sieci praktycznie z ka»dego
komputera. Wymagana mo»liwo±¢ pracy zdalnej rozumiana jest wi¦c jako umo»liwienie
pracy w systemie MRROC++ przy u»yciu komputera w dowolnej lokalizacji z mo»liwie dowolnym uruchomionym systemem operacyjnym. Jest ono równie» konsekwencj¡
wymaganej wieloplatformowo±ci rozwi¡zania, gdy» dopuszczenie do dziaªania komputerów z systemem operacyjnym innym ni» QNX wymaga zastosowania innego ni» QNET
protokoªu sieciowego.
Kolejn¡ cech¡, któr¡ speªnia¢ powinna realizowana aplikacja, jest ªatwo±¢ dystrybucji. Instalacja i uruchomienie dotychczasowej konsoli, ze wzgl¦du na ±cisª¡ jej integracj¦
ze struktur¡ MRROC++, wymaga instalacji caªej struktury. Dlatego te» kluczem do
ªatwiejszej dystrybucji i aktualizacji jest wyodr¦bnie gracznej konsoli sterowniczej z
systemu MRROC++ i realizacja jej jako samodzielnej aplikacji. Takie rozwi¡zanie pozwoli te» uczyni¢ uruchomienie konsoli na wybranej maszynie mniej pracochªonnym i
skomplikowanym.
Speªnienie wymienionych wymaga« przez realizowan¡ konsol¦ zaowocuje aplikacj¡
znacznie przewy»szaj¡c¡ dotychczasowe rozwi¡zanie funkcjonalno±ci¡ i wygod¡ u»ytkowania. Nowe mo»liwo±ci wykorzystania gracznej konsoli sterowniczej wydaj¡ si¦ by¢
warte wysiªku wªo»onego w realizacj¦ aplikacji.
2 natywny
protokóª sieciowy systemu QNX Neutrino, który czyni z wchodz¡cych w skªad sieci
komputerów rozproszone ±rodowisko o wspólnych zasobach
5
2 Wprowadzenie do systemu MRROC++
2.1 Struktura ramowa MRROC++
MRROC++ [1] to programowa struktura ramowa wspomagaj¡ca wytwarzanie sterowników dla systemów wielorobotowych. Powstaªa ona w Instytucie Automatyki i Informatyki Stosowanej Politechniki Warszawskiej. Historia struktury si¦ga pocz¡tku lat
dziewi¦¢dziesi¡tych, kiedy to powstaª jej pierwowzór RORC3 [3], wspomagaj¡cy tworzenie sterowników dla pojedynczych robotów. Nast¦pc¡ struktury RORC byª powstaªy
w 1995 roku MRROC [4], umo»liwiaj¡cy wspóªprac¦ z systemami wielorobotowymi,
jednak stworzony z wykorzystaniem paradygmatu proceduralnego, w przeciwie«stwie
do powstaªego kilka lat pó¹niej obiektowego MRROC++. Struktura MRROC++ jest
rozwijana po dzi± dzie«, w du»ej mierze dzi¦ki temu, i» stanowi podstawowe narz¦dzie
wykorzystywane w pracach dyplomowych realizowanych w Laboratorium Robotyki. Od
chwili powstania zostaªa wykorzystana do sterowania wykonaniem ró»norodnych zada«
- m.in. polerowania i frezowania przez robota RNT czy gry w warcaby i ukªadania kostki
Rubika [5] przez zmodykowane manipulatory Irp6 (Rysunek 1).
Rysunek 1: Dwa zmodykowane manipulatory Irp-6 ukªadaj¡ce kostk¦ Rubika
Struktura MRROC++ zawiera bibliotek¦ moduªów oraz wzorców programów, na
bazie których ªatwo mo»na zbudowa¢ dedykowany sterownik dla systemu wielorobotowego. Bibliotek¦ mo»na rozszerzy¢, tworz¡c nowe funkcje w C++, j¦zyku ¹ródªowym
struktury programowej, lub te» modykuj¡c istniej¡ce moduªy. Powstaªy sterownik
dziaªa pod kontrol¡ systemu operacyjnego czasu rzeczywistego QNX.
Dziaªaj¡cy sterownik to w rzeczywisto±ci zbiór procesów o ±ci±le okre±lonych zadaniach, dziaªaj¡cych w w¦zªach sieci kolalnej. Sam sterownik ma budow¦ wielowarstwow¡
3 Research-Oriented
Robot Controller
6
i modularn¡ (Rysunek 2), co upraszcza jego modykacj¦, bowiem wymiana jednego z
elementów nie poci¡ga za sob¡ wymiany czy modykacji pozostaªych moduªów.
Rysunek 2: Struktura sterownika MRROC++
Najni»sz¡ warstw¡ systemu jest warstwa sprz¦towa. W tej warstwie dziaªaj¡ procesy EDP4 , maj¡ce bezpo±redni dost¦p do sprz¦tu i steruj¡ce ruchem pojedynczego
efektora. Ich podstawowym zadaniem jest rozwi¡zywanie prostego i odwrotnego zadania kinematyki oraz realizacja funkcji charakterystycznych dla danego typu robota.
Od strony programistycznej EDP stanowi wirtualny efektor, wykonuj¡cy zadane ruchy.
Obok procesów EDP dziaªaj¡ równie» procesy VSP5 reprezentuj¡ce wirtualny sensor
agreguj¡cy dane otrzymane z rzeczywistych czujników w wirtualny odczyt, stanowi¡cy
ju» informacj¦ u»yteczn¡ dla systemu. Odczyty czujników rzeczywistych wykonywane
s¡ co okre±lony interwaª czasu na »¡danie procesu ECP lub MP.
Warstwa druga odpowiedzialna jest za wykonanie zadania na pojedynczym efekto4 Eector
5 Virtual
Driver Process
Sensor Process
7
rze. W jej skªad wchodz¡ procesy ECP6 . Ich ilo±¢, podobnie jak procesów EDP, jest
równa liczbie efektorów w systemie. Procesy te realizuj¡ algorytm sterowania pojedynczego manipulatora. W celu realizacji programu u»ytkowego komunikuj¡ si¦ z procesem
EDP steruj¡cym odpowiadaj¡cym im robotom oraz procesami MP, VSP czy UI. Jednym z zada« pojedynczego procesu ECP mo»e by¢ generacja trajektorii dla robota pod
jego kontrol¡ w przypadku niezale»nej lub lu¹nej wspóªpracy.
Najwy»sz¡ warstw¦ stanowi pojedynczy proces MP7 , koordynuj¡cy wspóªprac¦ robotów i steruj¡ca wykonaniem zadania. Synchronizuje w czasie dziaªanie efektorów, a w
przypadku ich ±cisªej wspóªpracy generuje trajektorie. Dodatkowo proces ten realizuje
równie» polecenia u»ytkownika otrzymane z procesu UI.
Oprócz wy»ej wymienionych w systemie istnieje równie» warstwa niezale»na od
wykonywanego zadania, odpowiedzialna za komunikacj¦ z u»ytkownikiem. W warstwie
tej pracuje proces UI8 . Proces UI realizuje graczny interfejs u»ytkownika, oparty na
±rodowisku gracznym Photo MicroGUI, wchodz¡cym w skªad systemu operacyjnego
QNX. Jego w¡tek SR9 odpowiedzialny jest za wy±wietlanie stanu systemu steruj¡cego.
Procesy ECP, MP i VSP s¡ zale»ne od wykonywanego zadania, podczas gdy procesy
EDP s¡ ±ci±le zwi¡zane ze sprz¦tem. Oznacza to, i» modykacja zadania sprowadza si¦
do modykacji kodu procesów MP i ECP. Zmiany w sprz¦cie z kolei poci¡gaj¡ za sob¡
konieczno±¢ modykacji kodu procesów EDP w przypadku efektora i VSP w przypadku
czujnika. Taki rozdzial warstwy zadania od warstwy sprz¦towej uªatwia tworzenie sterowników, gdy» umo»liwia oprogramowanie zadania bez konieczno±ci ingerencji w kod
steruj¡cy efektorów i czujników, a kod steruj¡cy zadaniem uniezale»nia od u»ytego
sprz¦tu.
2.2 Graczna konsola sterownicza
Podstawowym zadaniem gracznej konsoli sterowniczej jest umo»liwienie sterowania systemem MRROC++ i poszczególnymi robotami w wygodny i intuicyjny sposób.
Konsola zostaªa zbudowana w oparciu o ±rodowisko graczne Photon MicroGUI [6],
wchodz¡ce w skªad systemu operacyjnego czasu rzeczywistego QNX. ‘rodowisko to
oferuje bogaty zestaw elementów gracznych (tzw. widgetów), obsªug¦ wielu standardów kodowania tekstu i wsparcie dla aplikacji wieloj¦zycznych. W zale»no±ci od wykonywanej akcji konsola komunikuje si¦ z odpowiednimi procesami EDP, ECP lub MP.
6 Eector
Control Process
Process
8 User Interface
9 System Response
7 Master
8
Rysunek 3: Graczna konsola sterownicza systemu MRROC++ wykonana w Photon
MicroGUI
2.2.1 Podstawowe elementy
Okno gracznej konsoli sterowniczej, przedstawione na rysunku 3 mo»na podzieli¢
na cztery gªówne elementy.
• menu górne umo»liwia wydawanie podstawowych komend dla systemu
MRROC++, takich jak uruchomienie procesów EDP steruj¡cych poszczególnymi
robotami, uruchomienie procesu MP steruj¡cego wykonaniem zadania czy wydanie rozkazów dla wszystkich uruchomionych robotów. W menu górnym zawarte
s¡ równie» indywidualne menu wszystkich robotów obsªugiwanych przez system.
• panel gªówny w obszarze tym otwierane s¡ okna ruchów r¦cznych poszczególnych robotów, umo»liwiaj¡ce m.in. podgl¡d poªo»enia manipulatora czy te» ruch
wybranego robota do zadanej pozycji
• konsola na niej wy±wietlane s¡ komunikaty systemowe, zawieraj¡ce informacje
o przebiegu zadania, potwierdzenia wykonania polece« czy informacje o bª¦dach
• pasek statusu obok hasªa gªosz¡cego wy»szo±¢ ramowej struktury programowej
MRROC++ nad innymi podobnymi strukturami, wy±wieta równie» informacj¦
9
o aktualnej zaj¦to±ci systemu, czy to wskutek powoªywania wªa±nie procesów
steruj¡cych, komunikacji z procesami lub wykonywania rozkazu ruchu
2.2.2 Realizowane funkcje
Gdy w systemie MRROC++ nie s¡ uruchomione »adne procesy steruj¡ce, graczna
konsola sterownicza oferuje dost¦p jedynie do podstawowych funkcji systemu. Umo»liwia ona wtedy m.in. wczytanie konguracji z pliku wybranego z listy, wy±wietlaj¡cej
zawarto±¢ katalogu congs/ oraz czyszczenie konsoli tekstowej. Najwa»niejszym jej zadaniem jest jednak uruchamianie procesu MP, steruj¡cego wykonaniem zadania, oraz
wcze±niej procesów EDP poszczególnych robotów - pojedynczo dla ka»dego robota lub
jednocze±nie dla wszystkich robotów wymienionych w pliku konguracyjnym. Uruchomienie tych procesów umo»liwia dost¦p do du»o szerszego zakresu funkcji oferowanych
przez system.
Uruchomienie procesu EDP daje dost¦p do menu wybranego robota. Zawiera ono z
reguªy dost¦p do polecenia synchronizacji oraz ruchu robota do jednej z predeniowanych pozycji. Pas transmisyjny Conveyor udost¦pnia dodatkowo okno dialogowe Move,
sªu»¡ce do zadawania pozycji przy pomocy poªo»enia silników. Zmodykowane manipulatory Irp6 oferuj¡ o wiele wi¦cej sposobów specykowania po»¡danej pozycji. Mo»e
by¢ ona zadana za pomoc¡ poªo»e« silników oraz stawów, jak równie» przy pomocy
wspóªrz¦dnych o±-k¡t oraz wspóªrz¦dnych Eulera. Dodatkowo mo»liwe jest zadawanie
pozycji narz¦dzia w tych ukªadach wspóªrz¦dnych oraz wybór modelu kinematyki i algorytmów serworegulacji poszczególnych stawów. Ka»dy z robotów udost¦pnia równie»
polecenie zako«czenia dziaªania procesu EDP.
Uruchomienie procesu MP daje dost¦p do funkcji wywoªywanych z okna Process
Control, dost¦pnego w menu Task. Okno to umo»liwia wstrzymywanie i ponowne uruchamianie procesu MP, jak równie» uruchamianie i zatrzymywanie w¡tków pomiarowych EDP_READER, przechowuj¡cych i zapisuj¡cych stan procesu EDP.
2.2.3 Wady dotychczasowego rozwi¡zania
Istniej¡ca graczna konsola sterownicza, jako aplikacja nieco wiekowa, nie nad¡»a
niestety za najnowszymi trendami. Dotychczasowa konsola nie korzysta z peªni mo»liwo±ci, które oferuje wielow¡tkowo±¢. Uniemo»liwia ona przede wszystkim wykonywanie
równolegªych operacji na ró»nych robotach. Wskutek tego ju» sama synchronizacja robotów odbywa si¦ sekwencyjnie i zajmuje kilkakrotnie wi¦cej czasu ni» mogªaby, mimo
»e nie ma przeciwwskaza«, by w pewnych przypadkach wykonywa¢ j¡ równolegle na
wszystkich robotach.
Kolejnym problemem jest konieczno±¢ instalacji systemu operacyjnego QNX na maszynie rzeczywistej lub wirtualnej w celu uruchomienia dotychczasowej konsoli sterow10
niczej. Nie jest to wad¡, gdy u»ytkownik planuje uruchamianie na tej samej maszynie
aplikacji stworzonych dla systemu MRROC++, gdy» do ich uruchomienia system QNX
jest i tak wymagany. Jednak w przypadku, gdy na wybranej maszynie uruchamiana
ma by¢ jedynie konsola sterownicza, koszt instalacji, mierzony po±wi¦conym na to czasem, miejscem na dysku twardym komputera, czy te» zªo»ono±ci¡ tej operacji, wydaje
si¦ by¢ nieadekwatny do rzeczywistych wymaga« sprz¦towych i systemowych aplikacji,
jak¡ jest konsola sterownicza.
Kolejn¡ wad¡ dotychczasowego rozwi¡zania jest jego nieprzeno±no±¢ na inne systemy operacyjne ze wzgl¦du na ±cisª¡ integracj¦ ±rodowiska Photon MicroGUI z systemem QNX. Speªnienie wymagania jak najwi¦kszej przeno±no±ci aplikacji mi¦dzy ró»nymi systemami operacyjnymi umo»liwi¢ ma prac¦ z systemem MRROC++ przy u»yciu mo»liwie dowolnej platformy, bez ponoszenia wcze±niej wymienionych kosztów.
Przywi¡zanie aplikacji do systemu operacyjnego QNX ogranicza równie» mo»liwo±¢
pracy zdalnej, bardzo po»¡danej obecnie cechy, gdy» obszar roboczy aplikacji sprowadza
si¦ do obr¦bu sieci lokalnej QNET.
Celem pracy jest stworzenie konsoli wolnej od powy»szych wad i ogranicze«.
11
3 Opis wybranych technologii
Zrealizowana przeze mnie graczna konsola sterownicza systemu MRROC++ napisana zostaªa jako applet j¦zyka Java [7]. Do budowy interfejsu gracznego wykorzystaªem bibliotek¦ Java Swing. U»yte do realizacji zadania technologie postaram si¦
przybli»y¢ w tym rozdziale.
3.1 Platforma Java
Historia powstania i rozwoju j¦zyka Java ma swój pocz¡tek w grudniu 1990 roku,
kiedy to zespóª in»ynierów zatrudnionych w rmie Sun dostaª za zadanie opracowanie
technologii tworzenia przeno±nych aplikacji, zapewniaj¡cych wielow¡tkowo±¢, automatyczne zarz¡dzanie pami¦ci¡ i mo»liwo±¢ programowania rozproszonego. Projekt ten
zostaª nazwany Stealth Project. W 1992 roku zademonstrowany zostaª nowy j¦zyk Oak,
dwa lata pó¹niej przemianowany na Jav¦ z powodu zastrze»enia nazwy Oak przez inn¡
rm¦. Ocjalna premiera platformy Java miaªa miejsce 23 grudnia 1995 roku. Od 2006
roku platforma Java jest udost¦pniana prawie w caªo±ci na licencji GNU, z wyª¡czeniem
kilku bibliotek z zamkni¦tym ¹ródªem.
Platforma Java to zbiór narz¦dzi i bibliotek udost¦pnionych przez rm¦ Sun Microsystems w celu tworzenia aplikacji w j¦zyku Java. Dost¦pna jest ona w czterech
wersjach:
Java Card umo»liwia pisanie maªych aplikacji uruchamianych na kartach elektronicznych (tzw. smart cards)
Java Micro Edition dedykowana dla urz¡dze« przeno±nych z niewielk¡ ilo±ci¡ dost¦pnych zasobów
Java Standard Edition stworzona z my±l¡ o tworzeniu aplikacji dla komputerów
osobistych
Java Enterprise Edition umo»liwia tworzenie wielowarstwych, najcz¦±ciej rozproszonych aplikacji klasy Enterprise
Podstawowym narz¦dziem, na którym oparta jest platforma, jest j¦zyk Java. Jest
to silnie zorientowany obiektowo j¦zyk wysokiego poziomu - kompilator Javy wymaga,
by caªo±¢ kodu aplikacji znajdowaªa si¦ w klasach. Skªadnia j¦zyka wzorowana jest na
j¦zyku C++, jednak posiada uproszczony model obiektowy i uniezale»niona jest od
niskopoziomowych operacji.
Najwa»niejsz¡ cech¡ j¦zyka i platformy jest to, »e zostaªy zaprojektowane jako caªkowicie niezale»ne od platformy sprz¦towej, na której uruchamiane maj¡ by¢ aplikacje.
Jest to mo»liwe, poniewa» aplikacje napisane w Javie nie s¡ uruchamiane bezpo±rednio na maszynie, ale w ustandaryzowanym ±rodowisku nazywanym wirtualn¡ maszyn¡
12
Javy10 , zaimplementowanym pod ró»norodne systemy operacyjne. Stworzone w j¦zyku
Java programy s¡ kompilowane do kodu po±redniego (tzw. bytecode), zawieraj¡cego
instrukcje dla maszyny wirtualnej. Dystrybucja programu w postaci kodu po±redniego,
wykonywanego na maszynie wirtualnej, daje niezale»no±¢ od platformy, gdy» mo»e by¢
wykonany wsz¦dzie tam, gdzie znajduje si¦ wirtualna maszyna Java.
Przeno±no±¢ mi¦dzy systemami operacyjnymi Java zawdzi¦cza mnogo±ci implementacji wirtualnej maszyny Java. Oprócz ocjalnej implementacji rmy Sun Microsystems
dla systemów Windows, Linux i Solaris, stworzone zostaªy równie» implementacje innych dostawców, ale posiadaj¡ce certykaty kompatybilno±ci rmy Sun, co gwarantuje przeno±no±¢ aplikacji mi¦dzy ró»nymi implementacjami. Nieocjalne implementacje maszyny wirtualnej Javy powstaªy dla nast¦puj¡cych platform:
Windows implementacje rm IBM i Microsoft
Linux implementacja rmy IBM, projekt Blackdown i Kae
OS/2 implementacje rm IBM, GoldenCode Development i Innotek
MacOS implementacja rmy Apple
HP-UX implementacja rmy HP
Irix implementacja rmy SGI
AIX,OS/400 implementacja rmy IBM
Na rysunku 4 przedstawiono schemat platformy Java SE, wykorzystanej do realizacji zadania. Na samej górze znajduje sie j¦zyk Java, na dole za± platformy sprz¦towe, na
których wykonuj¡ si¦ aplikacje w j¦zyku Java. Pomi¦dzy nimi umiejscowiono narz¦dzia i
biblioteki, umo»liwiaj¡ce tworzenie tekstowych i gracznych aplikacji. Najwa»niejszymi
elementami platformy s¡:
java interpreter j¦zyka Java, wykonuj¡cy na maszynie wirtualnej rozkazy zawarte
w kodzie po±rednim
javac kompilator j¦zyka Java, tªumacz¡cy kod w j¦zyku Java na kod po±redni
javadoc narz¦dzie do wytwarzania dokumentacji na podstawie znaczników umieszczonych w kodzie programu
jar narz¦dzie do tworzenia archiwów, zawieraj¡cych klasy wykorzystywane przez
aplikacj¦
10 Java
Virtual Machine (JVM)
13
RMI Remote Method Invocation - zbiór narz¦dzi umo»liwiaj¡cych interakcj¦ aplikacji z innymi systemami za po±rednictwem sieci
AWT, Swing, Java2D biblioteki graczne, sªu»¡ce do budowy gracznego interfejsu u»ytkownika
Accessibility, Drag'n'Drop biblioteki zapewniaj¡ce dodatkowe funkcje uªatwiaj¡ce prac¦ z gracznymi aplikacjami
JDBC Java Database Connectivity - warstwa abstrakcji baz danych
IDL umo»liwia tworzenie aplikacji rozproszonych w ±rodowisku CORBA
JNI Java Native Interface - interfejs umo»liwiaj¡cy korzystanie z funkcji natywnych
dla danego systemu operacyjnego z poziomu aplikacji Java
XML JAXP umo»liwia przetwarzanie dokumentów XML
Wymienione elementy stanowi¡ zaledwie uªamek mo»liwo±ci wbudowanych w j¦zyk
Java, spora ich cz¦±¢ przedstawiona zostaªa na rysunku 4, jednak to nie bogactwo bibliotek byªo powodem wyboru tej»e platformy do realizacji zadania. Tworzona konsola
sterownicza systemu MRROC++ wykorzystuje tylko podstawowe biblioteki oferowane
przez Jav¦, w peªni czerpie za to z przeno±no±ci platformy, gdy» wªa±nie przeno±no±¢
byªa jednym z wymaga« stawianych aplikacji.
Rysunek 4: Schemat platformy Java SE w wersji 6
3.2 Biblioteka Java Swing
Biblioteka Swing [8] wchodzi w skªad Java Foundation Classes (JFC), zbioru komponentów do tworzenia gracznego interfejsu u»ytkownika. Podstawowymi elementami
14
tej biblioteki s¡ ró»nego rodzaju kontrolki, od najprostszych przycisków, poprzez pola
tekstowe, na rozwijanych drzewach, listach i tabelach ko«cz¡c. Kontrolki te sªu»¡ do budowy interaktywnego interfejsu gracznego. Oprócz biblioteki Swing wskªad JFC wchodzi równie» pakiet Drag'n'Drop, udost¦pniaj¡cy mechanizmy "przeci¡gnij i upu±¢", pakiet Accessibility, zawieraj¡cy uªatwienia dla osób niedowidz¡cych i niedosªysz¡cych,
oraz pakiet Java2D, umo»liwiaj¡cy tworzenie graki dwuwymiarowej.
Pierwotnie do tworzenia interfejsów gracznych Java korzystaªa z biblioteki AWT11 ,
zawieraj¡cych tzw. komponenty ci¦»kie, które ka»de zdarzenie tªumaczyªy na odpowiednie wywoªanie systemu operacyjnego. Swing jest nast¦pc¡ biblioteki AWT, w przeciwie«stwie jednak do niej stworzony zostaª w caªo±ci w j¦zyku Java, dzi¦ki czemu jest
niezale»ny od platformy sprz¦towej. Dodatkowo do rysowania interfejsu wykorzystywana jest biblioteka Java 2D, a nie funkcje systemu operacyjnego, czego skutkiem jest
prawie identyczny (z dokªadno±ci¡ do kolorystyki i stylu) wygl¡d aplikacji pod ró»nymi
systemami operacyjnymi.
Komunikacja pomi¦dzy interfejsem gracznym a aplikacj¡ polega na obsªudze asynchronicznie wywoªywanych zdarze«. Zdarzenia maj¡ce ¹ródªo w interfejsie u»ytkownika
(np. wci±ni¦cie przycisku) obsªugiwane s¡ po kolei przez pojedynczy w¡tek obsªugi
zdarze« EDT12 , który przekazuje zdarzenie do metody actionPerformed() obiektów
skojarzonych ze zdarzeniem, implementuj¡cych interfejs ActionListener, umo»liwiaj¡cy
obsªug¦ zdarze«. Konsekwencj¡ jednow¡tkowej obsªugi zdarze« jest ich kolejkowanie,
dopóki w¡tek EDT nie zako«czy obsªugi poprzedniego zdarzenia. Rodzi to niebezpiecze«stwo zakleszcze« oraz zawieszenia interfejsu w przypadku realizacji czasochªonnych
operacji w w¡tku EDT podczas obsªugi zdarzenia.
Projekt Java Swing zakªadaª wst¦pnie realizacj¦ biblioteki w architekturze ModelWidok-Kontroler:
Model przechowuje dane deniuj¡ce komponent
Widok tworzy graczn¡ reprezentacje komponentu
Kontroler obsªuguje interakcj¦ z u»ytkownikiem i w razie potrzeby modykuje model
lub widok w odpowiedzi na akcj¦ u»ytkownika
Zale»no±ci pomi¦dzy widokiem i kontrolerem byªy jednak zbyt du»e, gdy» kontroler
w du»ym stopniu korzysta z implementacji widoku, dlatego te» w rzeczywisto±ci model
MVC degenerowaª w model Dokument-Widok.
Oddzielenie widoku od modelu spowodowaªo, »e Java Swing posiada jeszcze jedn¡,
bardzo przydatn¡ cech¦ - umo»liwia zmian¦ wygl¡du interfejsu bez modykacji kodu
nim steruj¡cego. Dlatego te» mo»liwe jest deniowanie wªasnych schematów wygl¡du
11 Abstract
12 Event
Window Toolkit
Dispatch Thread
15
aplikacji (tzw. look and feel). Co wi¦cej, aplikacja uruchomiona pod kontrol¡ ró»nych
systemów operacyjnych mo»e wykorzysta¢ schemat wygl¡du tych wªa±nie systemów,
dzi¦ki czemu jej wygl¡d przypomina¢ b¦dzie natywne aplikacje danego systemu operacyjnego.
3.3 Applet j¦zyka Java
Applet j¦zyka Java to niewielki program osadzany w kodzie strony WWW i uruchamiany w kontek±cie przegl¡darki internetowej. Pobierany jest on z serwera w postaci
kodu po±redniego, a nast¦pnie wykonywany przez maszyn¦ wirtualn¡ Javy. Dystrybucja appletu w postaci kodu po±redniego zapewnia przeno±no±¢ pomi¦dzy platformami
oferowan¡ przez j¦zyk Java.
Applet w kodzie HTML osadzi¢ przy pomocy nast¦puj¡cego prostego kodu:
<applet
code="MrrocppUI"
archive="JavaUISigned.jar">
</applet>
Applety Javy stosowane s¡ w celu dodania dynamiki do statycznej strony HTML, zawieraj¡cej niezmienn¡ tre±¢, identyczn¡ dla ka»dego u»ytkownika. Applety umo»liwiaj¡
zmian¦ zawarto±ci strony w zale»no±ci od akcji podejmowanych przez u»ytkownika, pozwalaj¡c nie tylko na czytanie tre±ci strony, ale równie» na dwukierunkow¡ komunikacj¦
pomi¦dzy serwerem, a u»ytkownikiem. Alternatyw¡ dla appletu s¡ strony wykonane
przy wykorzystaniu DHTML, technologii Flash lub Silverlight, jednak ust¦puj¡ one
appletowi Javy pod wzgl¦dem oferowanych funkcji.
Maszyna wirtualna Javy uruchamia applety z innymi uprawnieniami ni» samodzielne aplikacje. Projektanci JVM zaªo»yli, »e u»ytkownik instaluj¡cy i uruchamiaj¡cy samodzieln¡ aplikacj¦ Javy bierze na siebie odpowiedzialno±¢ za ewentualne konsekwencje. Dlatego te» takie aplikacje maj¡ domy±lnie przyznany dost¦p do wszystkich
zasobów komputera.
W przeciwie«stwie do samodzielnych aplikacji, applety Javy pobierane s¡ z internetu i uruchamiane automatycznie przez przegl¡dark¦. W celu zapewnienia bezpiecze«stwa wykonywania kodu pobranego z internetu, przegl¡darki internetowe uruchamiaj¡
applet w bardzo ograniczonym ±rodowisku (tzw. sandbox), przez co ma on dost¦p tylko
do wybranych zasobów. Pobrany z internetu applet nie ma dost¦pu do plików lokalnej
maszyny czy schowka, nie jest równie» uprawniony do nawi¡zywania poª¡cze« sieciowych z adresem innym ni» strona, z której zostaª pobrany.
Ze wzgl¦du na trudno±¢ pisania bardziej zªo»onych aplikacji przy tak surowych
ograniczeniach, dopuszcza si¦ rozszerzenie uprawnie« appletu poprzez jego cyfrowe
podpisanie. Przed uruchomieniem takiego appletu podpis zostanie zwerykowany, a
16
u»ytkownik zapytany o to, czy dostawca appletu jest dla niego zaufan¡ stron¡. Je»eli
u»ytkownik ufa dostawcy, to applet zyska mo»liwo±¢ dost¦pu do dodatkowych zasobów
komputera, zdeniowanych w pliku java.policy.
Realizacja gracznej konsoli sterowniczej jako appletu ma szereg zalet. Najwa»niejsz¡ jest to, »e applet speªnia stawiane aplikacji wymaganie ªatwej dystrybucji. Dystrybucja jest uªatwiona, gdy» aplikacj¦ wystarczy pobra¢ z serwera korzystaj¡c z przegl¡darki internetowej, w któr¡ wyposa»ony jest praktycznie ka»dy system operacyjny.
Applet nie wymaga instalacji, wi¦c w razie potrzeby u»ytkownik bez wi¦kszego wysiªku
mo»e uruchomi¢ graczn¡ konsol¦ sterownicz¡ systemu MRROC++ na dowolnym komputerze podª¡czonym do internetu.
Taki sposób dystrybucji rodzi równie» pytanie, czy konieczno±¢ pobierania aplikacji
przed uruchomieniem nie powoduje zb¦dnego ruchu sieciowego. W przypadku appletu
jednak nie jest to problemem, gdy» po pobraniu przechowywany jest on w pami¦ci podr¦cznej przegl¡darki, a ponowne pobranie nast¦puje dopiero w przypadku pojawienia
si¦ na serwerze nowszej wersji appletu. Tu równie» objawia si¦ kolejna cecha appletu
- ªatwo±¢ aktualizacji. Dzi¦ki scentralizowanej instalacji aktualizacj¦ konsoli wystarczy przeprowadzi¢ tylko w jednym miejscu, a aktualna wersja zostanie pobrana przez
u»ytkowników w momencie próby uruchomienia w przegl¡darce starszej wersji.
3.4 Protokóª TCP/IP
Aby graczna konsola sterownicza speªniaªa stawiane jej wymaganie mo»liwo±ci
pracy zdalnej w systemie, zdecydowaªem si¦ na realizacj¦ aplikacji w architekturze
klient-serwer, konsekwencj¡ czego byªa realizacja komunikacji za pomoc¡ protokoªów
sieciowych. Do tego celu wybrana zostaªa para protokoªów TCP/IP [9], wykorzystywana typowo do komunikacji w sieci internet. Niew¡tpliw¡ zalet¡ TCP/IP jest fakt, i»
protokóª ten jest dost¦pny w standardowych instalacjach wi¦kszo±ci systemów operacyjnych. Istniej¡ równie» implementacje tego protokoªu dla wi¦kszo±ci j¦zyków programowania, co umo»liwia niemal nieograniczone jego stosowanie.
Protokóª IP13 to protokóª warstwy sieciowej modelu ISO/OSI, odpowiadaj¡cy za
dostarczenie pakietów od nadawcy do odbiorcy bazuj¡c jedynie na ich adresach. Do
adresowania wykorzystywany jest obecnie najcz¦±ciej protokóª IPv4, ale z powodu na
wyczerpuj¡c¡ si¦ pul¦ adresów coraz cz¦±ciej do u»ycia wchodzi protokóª IPv6.
Protokóª IP jest protokoªem zawodnym - nie daje »adnych gwarancji poprawnego
dostarczenia pakietu. W dostarczonych pakietach mog¡ znajdowa¢ si¦ bª¦dy, cz¦±¢ pakietów mo»e si¦ powtarza¢, a cz¦±ci mo»e brakowa¢, a kolejno±¢ ich dostarczania jest
caªkowicie niezale»na od kolejno±ci nadawania. Co wi¦cej, protokóª nie zapewnia »adnej
sygnalizacji wyst¡pienia wy»ej wymienionych bª¦dów, dlatego te» kontrol¡ poprawno±ci
13 Internet
Protocol
17
transmisji musz¡ zajmowa¢ si¦ protokoªy warstwy wy»szej.
Protokóª TCP14 to protokóª warstwy transportowej modelu ISO/OSI i to na nim
spoczywa odpowiedzialno±¢ za poprawno±¢ dostarczenia danych. Do najwa»niejszych
cech tego protokoªu mo»na zaliczy¢:
• dostarczanie datagramów do odbiorcy w takiej samej kolejno±ci, w jakiej zostaªy
nadane, poprzez buforowanie i uªo»enie pakietów w odpowiedniej kolejno±¢i przed
przekazaniem ich do warstwy wy»szej
• gwarancja dostarczenia datagramu bez bª¦dów, realizowane poprzez retransmisj¦
bª¦dnych lub zaginionych pakietów, a w najgorszym wypadku informacji zwrotnej
o niemo»no±ci dostarczenia pakietu
Gwarancja dostarczenia pakietów byªa tym, co zdecydowaªo o wyborze tej pary
protokoªów do realizacji komunikacji pomi¦dzy klientem i serwerem. Specyka komunikacji z systemem MRROC++ wymagaªa bowiem wysyªania przez serwer potwierdze«
wykonania ruchu, a bª¦dy w ich dostarczeniu skutkowaªyby niepoprawnym dziaªaniem
aplikacji.
3.5 Protokóª Rsh
Do sterowania systemem MRROC++, oprócz gracznej konsoli klienckiej, niezb¦dny jest równie» serwer dziaªaj¡cy po stronie systemu QNX. Serwer nie zawsze
jest uruchomiony, dlatego pojawiªa si¦ potrzeba zdalnego powoªania procesu serwera.
Do tego zadania wybrany zostaª protokóª Rsh.
Rsh15 to protokóª wywodz¡cy si¦ z systemów BSD, wchodz¡cy w skªad pakietu rlogin. Sªu»y do wykonywania polece« powªoki systemowej na innej maszynie. Na zdalnej
maszynie musi w tym celu zosta¢ uruchomiony demon rshd, który nasªuchuje na porcie
514, a po nawi¡zaniu poª¡czenia wykonuje otrzymane polecenie.
Implementacj¦ protokoªu Rsh w Javie dostarczaj¡ biblioteki wchodz¡ce w skªad
projektu Apache Commons. Protokóª rsh dostarczany jest w pakiecie Net, który oprócz
rsh, dostarcza on implementacj¦ wi¦kszo±ci podstawowych protokoªów sieciowych, m.in.
FTP, SMTP, POP3 oraz Telnet.
14 Transport
15 Remote
Control Protocol
Shell
18
4 Realizacja aplikacji
Wymagan¡ mo»liwo±¢ pracy zdalnej w systemie MRROC++ oferuje realizacja gracznej konsoli sterowniczej w architekturze klient-serwer (Rysunek 5). Realizowane
przez aplikacj¦ funkcje zostaªy rozdzielone pomi¦dzy graczn¡ konsol¦, uruchamian¡
po stronie klienta, oraz ±ci±le zintegrowany z systemem MRROC++ proces serwera.
Rysunek 5: Ogólna struktura systemu
Graczna konsola, napisana w oparciu o technologi¦ Java, umo»liwia wydawanie
podstawowych polece« dla systemu MRROC++, rozkazów ruchów dla robotów oraz
sterowanie przebiegiem wykonania zadania. Dodatkowo wy±wietla informacje o stanie systemu i otrzymywane z serwera komunikaty. Pod wzgl¦dem oferowanych funkcji
nie ró»ni si¦ ona od pierwotnej konsoli - z zaªo»enia bowiem miaªa ona by¢ mo»liwie
zbli»ona do pierwowzoru.
Serwer, dziaªaj¡cy jako jeden z procesów po stronie systemu MRROC++, napisany
zostaª w j¦zyku C++. Przyjmuje i wykonuje polecenia z aplikacji klienckiej, udost¦pnia
te» informacj¦ o stanie systemu i rozsyªa komunikaty systemowe. Serwer komunikuje si¦
z pojedyncz¡ aplikacj¡ klienck¡, dlatego te» próby nawi¡zania poª¡czenia przez kolejne
aplikacje s¡ odrzucane.
Komunikacja pomi¦dzy klientem a serwerem odbywa si¦ przy pomocy pary protokoªów TCP/IP przy u»yciu dedykowanej do tego struktury danych.
Scenariusz pracy z systemem MRROC++ przy pomocy gracznej konsoli sterowniczej przedstawiono na rysunku 6. Wszystkie przedstawione na nim elementy systemu
zostan¡ szczegóªowo przedstawione w tym rozdziale.
4.1 Identykatory operacji
W rozdziale 4.4 przedstawiony zostanie opracowany na potrzeby aplikacji protokóª
komunikacyjny sªu»¡cy do przesyªania informacji pomi¦dzy klientem i serwerem. Podstaw¡ jego dziaªania s¡ trzy typy wyliczeniowe, zdeniowane i u»ywane przez wi¦kszo±¢
klas aplikacji. Zakres ich u»ycia spowodowaª konieczno±¢ przedstawienia ich ju» teraz.
Cz¦±¢ z tych typów zostaªa zdeniowana kilkukrotnie, bowiem w zale»no±ci od kontekstu zbiór dopuszczalnych warto±ci mo»e by¢ ró»ny. W celu okre±lenia robota b¦d¡cego
nadawc¡ lub odbiorc¡ komunikatu oraz identykacji funkcji, której wykonanie zleciª
19
Rysunek 6: Scenariusz pracy z systemem MRROC++
20
u»ytkownik, przesyªane s¡ warto±ci zmiennych tych trzech typów.
Wspomniane typy wyliczeniowe to:
RobotId identykator robota, zdeniowany tylko w klasie MrrocppUI, okre±la robota, w którego kontek±cie nast¡piªo zdarzenie.
DialogId identykator okna dialogowego, zdeniowany w klasie MrrocppUI obejmuje trzy okna dialogowe sªu»¡ce do sterowania systemem MRROCP++, zdeniowany w klasach reprezentuj¡cych roboty obejmuje wszystkie okna dialogowe
sªu»¡ce do sterowania danym robotem. Sªu»y do identykacji okna dialogowego,
zawieraj¡cego komponent, który wygenerowaª zdarzenie.
ActionId identykator akcji, zdeniowany w ka»dej klasie reprezentuj¡cej okno
dialogowe, jak równie» w klasie MrrocppUI. Sªu»y do okre±lenia przycisku lub
pozycji w menu, którego wci±ni¦cie wygenerowaªo zdarzenie.
4.2 Klient
Klienck¡ cz¦±¢ zrealizowanej aplikacji stanowi napisana w j¦zyku Java graczna
konsola sterownicza. Interfejs graczny konsoli zaprojektowany zostaª tak, by mo»liwie
dokªadnie odwzorowywaª wygl¡d pierwotnej konsoli stworzonej w Photon MicroGUI.
Wykorzystana do budowy interfejsu biblioteka Java Swing zawiera podobny zestaw
kontrolek, jaki znale¹¢ mo»na w Photon MicroGUI, udaªo si¦ wi¦c uzyska¢ wierne
odwzorowanie dotychczasowego interfejsu. Na rysunku 7 przedstawiono now¡ wersj¦
konsoli w stanie identycznym jak prezentowana na rysunku 3 pierwotna konsola. Funkcje oferowane przez zrealizowan¡ przeze mnie konsol¦ w peªni pokrywaj¡ te oferowane
przez jej pierwowzór. Dodatkowo wprowadzone zostaªo kilka usprawnie«. Oprócz eksportu pozycji robota do konsoli tekstowej, nowa wersja umo»liwia eksport wspóªrz¦dnych do schowka systemowego oraz zapami¦tanie pozycji robota w programie, w celu
pó¹niejszego wybrania jej z listy i wczytania.
4.2.1 Struktura aplikacji
Struktur¦ aplikacji klienckiej przedstawiono na diagramie 8. Trzonem aplikacji jest
obiekt klasy MrrocppUI, reprezentuj¡cej gªówne okno gracznej konsoli sterowniczej.
Klasa ta realizuje dwukierunkow¡ komunikacj¦ z systemem MRROC++, umo»liwia
równie» wydawanie podstawowych polece« dla systemu.
Gam¦ funkcji oferowanych przez klas¦ MrrocppUI rozszerza szereg okien dialogowych umo»liwiaj¡cych wczytywanie konguracji czy sterowanie przebiegiem wykonania
zadania. Okna dialogowe wraz z klas¡ MrrocppUI zapewniaj¡ realizacj¦ caªo±ci funkcji gracznej konsoli sterowniczej, za wyj¡tkiem rozkazów zwi¡zanych ze sterowaniem
pojedynczymi robotami.
21
Rysunek 7: Graczna konsola sterownicza systemu MRROC++ wykonana w Java
Swing
Ostatnim elementem aplikacji s¡ klasy reprezentuj¡ce roboty obsªugiwane przez
system MRROC++. Zapewniaj¡ one mo»liwo±¢ r¦cznego sterowania robotem, udost¦pniaj¡ równie» informacj¦ o jego aktualnym stanie.
4.2.2 Klasa MrrocppUI
Graczna konsola sterownicza zostaªa zrealizowana jako applet j¦zyka Java, dlatego
te» klasa MrrocppUI (Rysunek 9) dziedziczy po klasie javax.swing.JApplet. Jednym
z zada« tej klasy jest stworzenie gªównego okna aplikcji, dlatego te» obsªuguje ona
zdarzenia wywoªywane przez komponenty wchodz¡ce wskªad tego okna, co wymusiªo
implementacj¦ przez t¦ klas¦ interfejsu ActionListener.
Graczna konsola sterownicza systemu MRROC++ rozpoczyna swoje dziaªanie od
statycznej funkcji MrrocppUI::main(), która tworzy instancj¦ obiektu klasy MrrocppUI. Konstruktor klasy MrrocppUI w pierwszym kroku tworzy obiekty reprezentuj¡ce
obsªugiwane przez system MRROC++ roboty, a nast¦pnie wywoªywana jest funkcja
createGUI, tworz¡ca i wy±wietlaj¡ca gªówne okno aplikacji (rysunek 7). Dalsze dziaªanie programu obejmuje obsªug¦ zdarze« wygenerowanych przez u»ytkownika, jak i
obsªug¦ komunikatów otrzymanych z systemu.
22
Rysunek 8: Struktura aplikacji klienckiej
W górnej cz¦±ci gªównego okna znajduje si¦ menu. Zawiera ono podstawowe polecenia dla systemu MRROC++, obsªugiwane wªa±nie przez klas¦ MrrocppUI. Na rysunku 10 przedstawiono hierarchi¦ menu górnego. Cz¦±¢ pozycji otwiera okno dialogowe, pozostaªe wysyªaj¡ do serwera odpowiednie »¡danie. W menu górnym znajduje
si¦ równie» podmenu Robot. Zawiera ono menu sªu»¡ce do sterowania poszczególnymi
robotami. Zawarto±¢ tych menu udost¦pniana jest przez klasy reprezentuj¡ce obsªugiwane roboty za pomoc¡ funkcji Robot::getMenu().
W dolnej cz¦±ci okna gªównego znajduje si¦ konsola tekstowa. Sªu»y ona do wy±wietlania zarówno komunikatów otrzymywanych z serwera, jak i generowanych przez
aplikacj¦ klienck¡. Ka»dy komunikat posiada jeden z predeniowanych typów, przypisane jest mu równie» ¹ródªo oraz moment generacji. Wszystkie te informacje wy±wietlane s¡ wªa±nie w konsoli tekstowej. Dost¦p do konsoli realizowany jest przy u»yciu
funkcji MrrocppUI::LogMessage(). Funkcja ta jako argumenty przyjmuje tre±¢ oraz
typ komunikatu. Obsªugiwane typy zdeniowane s¡ w globalnym typie wyliczeniowym
MessageType.
Poni»ej konsoli znajduje si¦ pasek statusu. Wy±wietla on aktualny stan pracy serwera (Rysunek 11), którym mo»e by¢ jeden z poni»szych stanów:
Disconnected aplikacja kliencka nie jest poª¡czona z serwerem
Starting serwer jest w trakcie uruchamiania
Communication komunikacja pomi¦dzy klientem i serwerem
Ready serwer jest gotowy do przyj¦cia polecenia
Busy serwer wykonuje polecenie u»ytkownika
Synchronisation jeden z robotów jest synchronizowany
23
Rysunek 9: Klasa MrrocppUI
Rysunek 10: Hierarchia menu
Process Creation po strone serwera powoªywany jest proces EDP
Exiting zamykanie serwera
Na pasku statusu, podobnie jak w pierwotnej wersji konsoli sterowniczej, znajduje
si¦ równie» napis sªawi¡cy struktur¦ MRROC++ jako najlepsz¡ struktur¦ ramow¡
kiedykolwiek stworzon¡.
Zdarzenia wygenerowane przez komponenty znajduj¡ce si¦ w gªównym oknie aplikacji obsªugiwane s¡ przez klas¦ MrrocppUI w metodzie MrrocppUI::ActionPerformed().
Obsªuga zdarzenia sprowadza si¦ do wysªania odpowiedniego polecenia do serwera po
stronie systemu MRROC++ przy u»yciu funkcji MrrocppUI::SendMessage(). Komunikacja z serwerem opisana jest szerzej w rozdziale 4.4.
Klasa MrrocppUI w realizowaniu podstawowych funkcji systemu posiªkuje si¦
trzema oknami dialogowymi reprezentowanymi przez klasy MrrocppUI::ConnectDialog,
MrrocppUI::CongDialog oraz MrrocppUI::ControlDialog, opisanymi w dalszej cz¦±ci
rozdziaªu. Klasa MrrocppUI wraz z tymi trzema klasami pokrywaj¡ caªo±¢ mo»liwo±ci
24
Rysunek 11: Diagram stanów aplikacji klienckiej
oferowanych przez konsol¦ sterownicz¡ za wyj¡tkiem sterowania pojedynczymi robotami.
MrrocppUI::ConnectDialog Klasa MrrocppUI::ConnectDialog odpowiada za nawi¡zanie poª¡czenia z serwerem po stronie systemu MRROC++. Wy±wietla ona okno
dialogowe, umo»liwiaj¡ce wprowadzenie adresu maszyny, na której dziaªa serwer, oraz
±cie»k¦ do katalogu, w którym znajduje si¦ plik wykonywalny serwera. Po wprowadzeniu parametrów poª¡czenia aplikacja usiªuje nawi¡za¢ poª¡czenie z serwerem przy
pomocy gniazd TCP/IP. Mo»liwych jest kilka scenariuszy (Rysunek 12) nawi¡zywania
poª¡czenia z serwerem:
1. W przypadku poprawnego nawi¡zania poª¡czenia uruchamiane s¡ w osobnych
w¡tkach funkcje odpowiadaj¡ce za odbieranie i nadawanie komunikatów - odpowiednio MrrocppUI::ReadQueue::run() i MrrocppUI::SendQueue::run(). Klasy
MrrocppUI::ReadQueue i MrrocppUI::SendQueue opisane s¡ szerzej w rozdziale 4.4.
2. W przypadku, gdy nie uda si¦ nawi¡za¢ poª¡czenia, aplikacja zakªada, »e nie
zostaª uruchomiony po stronie systemu MRROC++ serwer. Aplikacja spróbuje
w takim wypadku uruchomi¢ serwer, korzystaj¡c w tym celu z protokoªu RExec,
a nast¦pnie spróbuje ponownie nawi¡za¢ poª¡czenie.
3. W przypadku nieudanej próby ponownego nawi¡zania poª¡czenia, po uprzedniej próbie uruchomienia serwera na zdalnej maszynie, kolejna próba poª¡czenia
nie zostanie podj¦ta. Nieudane uruchomienie procesu serwera mo»e by¢ przede
wszystkim spowodowane brakiem plików wykonywalnych.
25
Rysunek 12: Scenariusz nawi¡zywania poª¡czenia z serwerem
Dost¦p do okna dialogowego MrrocppUI::ConnectDialog jest mo»liwy po wybraniu
opcji Conguration z menu Task.
Klasa MrrocppUI::CongDialog Klasa ta umo»liwia wybranie pliku konguracyjnego spo±ród dost¦pnych na serwerze. Konstruktor tej klasy wysyªa do serwera polecenie przesªania zawarto±ci katalogu congs/ w katalogu domowym systemu
MRROC++, a nast¦pnie wy±wietla okno dialogowe, zawieraj¡ce list¦ dost¦pnych plików konguracyjnych. W przypadku wyboru pliku przez u»ytkownika, jego nazwa przesyªana jest do serwera przy u»yciu metody MrrocppUI::SendMessage().
Dost¦p do tego okna dialogowego jest mo»liwy po wybraniu opcji Conguration z
menu Task.
Klasa MrrocppUI::ControlDialog Klasa ta reprezentuje okno sterowania wykonaniem zadania - dost¦pne po wybraniu opcji Process Control z menu Task. Umo»liwia
ona uruchamianie, zatrzymywanie i wznawianie procesu MP odpowiadaj¡cego za sterowanie przebiegiem zadania, oraz uruchamianie i zatrzymywanie procesów odpowiedzialnych za dokonywanie odczytów poªo»e« poszczególnych robotów oraz sterowanie
procesami ECP. Jak w caªej aplikacji równie» i tutaj wysyªanie komunikatów odbywa
si¦ przy u»yciu metody MrrocppUI::SendMessage().
4.2.3 Okna dialogowe
Zdecydowana wi¦kszo±¢ funkcji oferowanych przez graczn¡ konsol¦ sterownicz¡, a
w szczególno±ci ruchy r¦czne pojedynczymi robotami, realizowana jest przy pomocy
okien dialogowych. W celu uªatwienia tworzenia nowych okien stworzone zostaªy dwie
klasy przedstawione na rysunku 13, stanowi¡ce podstaw¦ do budowy okien dialogowych.
26
Rysunek 13: Klasy wykorzystywane do budowy okien dialogowych
Klasa SimpleDialog Klasa ta stanowi abstrakcyjn¡ klas¦ bazow¡, po której dziedzicz¡ wszystkie okna dialogowe u»ywane przez aplikacj¦. Skupia ona funkcje wspóln¡
dla tych okien. Klasa ta dziedziczy po klasie javax.swing.JDialog. Implementuje ona interfejs ActionListener, mo»e wi¦c obsªugiwa¢ zdarzenia generowane przez komponenty
które zawiera. Obiekty klasy SimpleDialog udost¦pniaj¡ nast¦puj¡ee funkcje:
SimpleDialog( MrrocppUI, String) Konstruktor klasy SimpleDialog. Jako argumenty przyjmuje referencje do obiektu klasy MrrocppUI, reprezentuj¡cej gªówne
okno aplikacji, w którego kontek±cie wy±wietla¢ b¦dzie si¦ okno dialogowe, oraz
tytuª, który wy±wietli si¦ w nagªówku okna.
disable() Umo»liwia zablokowanie okna, wskutek czego niemo»liwe b¦dzie wydawanie systemowi polece«. Z funkcji tej korzystaj¡ przede wszystkim okna sªu»¡ce do
sterowania pojedynczymi robotami, ze wzgl¦du na fakt, i» system MRROC++
27
nie dopuszcza równolegªego wykonywania przez robota wi¦cej ni» jednego rozkazu.
enable() Umo»liwia odblokowanie okna, zablokowanego przy u»yciu funkcji disable()
drawDialog() Jest to abstrakcyjna funkcja, odpowiadaj¡ca za zbudowanie okna dialogowego. Implementacj¦ tej funkcji zapewniaj¡ konkretne klasy reprezentuj¡ce
poszczególne okna dialogowe.
showDialog() Powoduje wy±wietlenie na ekranie okna dialogowego.
actionPerformed( ActionEvent) Funkcja abstrakcyjna wchodz¡ca wskªad interfejsu
ActionListener, sªu»¡ca do obsªugi zdarze« generowanych przez komponenty nale»¡ce do okna dialogowego. Jako argument przyjmuje referencj¦ do obiektu klasy
ActionEvent, reprezentuj¡cego zdarzenie i udost¦pniaj¡cego informacj¦ na temat
¹ródªa zdarzenia. Implementacj¦ tej metody zapewniaj¡ konkretne klasy reprezentuj¡ce poszczególne okna dialogowe.
Klasa ReadSetDialog Dziedzicz¡ca po SimpleDialog klasa ReadSetDialog reprezentuje okna ruchów r¦cznych pojedynczych robotów. Przykªadowe okno typu ReadSetDialog przedstawiono na rysunku 14.
Rysunek 14: Przykªadowe okno klasy ReadSetDialog
Okna typu ReadSetDialog umo»liwiaj¡ mi¦dzy innymi:
• wy±wietlanie aktualnej pozycji manipulatora
• wprowadzenie r¦cznie »¡danej pozycji
• krokowa zmiana warto±ci pojedynczych wspóªrz¦dnych
28
• eksport i import pozycji manipulatora do i ze schowka systemowego
• zapami¦tanie nazwanych zestawów wspóªrz¦dnych i ich przywracanie
• wysªanie do serwera »¡dania odczytu pozycji
• zadanie nowej pozycji manipulatora
W skªad klasy ReadSetDialog wchodz¡ nast¦puj¡ce funkcje publiczne:
ReadSetDialog( MrrocppUI, String) konstruktor klasy ReadSetDialog. Jako argumenty przyjmuje referencje do obiektu klasy MrrocppUI, reprezentuj¡cej gªówne
okno aplikacji, w którego kontek±cie wy±wietla¢ b¦dzie si¦ okno dialogowe, oraz
tytuª, który wy±wietli si¦ w nagªówku okna.
showDialog() powoduje wy±wietlenie okna dialogowego. Dodatkowo przesyªa do
serwera zapytanie o aktualn¡ pozycj¦ manipulatora i przepisuje te wspóªrz¦dne
w pola zawieraj¡ce aktualn¡ i »¡dan¡ pozycj¦ robota.
updateDialog( double []) funkcja przyjmuje jako argument tablic¦ zawieraj¡c¡ poszczególne wspóªrz¦dne robota i wpisuje je w odpowiednie pola.
Stworzenie nowego okna dialogowego tego typu sprowadza si¦ do implementacji klasy
dziedzicz¡cej po klasie ReadSetDialog. Konstruktor nowego okna powinien ustawi¢
odpowiednio warto±ci zmiennych wymienionych poni»ej. Zostan¡ one wykorzystane do
budowy okna dialogowego. Obsªuga zdarze« i przesyªanie polece« do serwera zostaªo
ju» zaimplementowane w klasie ReadSetDialog.
DialogId dialogId identykator okna dialogowego. Typ DialogId opisany jest szerzej
w rodziale 4.4.
String variableLabelText etykieta kolumny zawieraj¡cej nazwy wspóªrz¦dnych
int variableNumber liczba wspóªrz¦dnych
String [] variableLabels nazwy wspóªrz¦dnych
boolean enableImportExport wª¡cza/wyª¡cza import i eksport pozycji
boolean enableIncremental wª¡cza/wyª¡cza mo»liwo±¢ krokowej zmiany pojedynczych wspóªrz¦dnych
double stepMin, double stepMax minimalna i maksymalna warto±¢ kroku
double stepDefault domy±lna, pocz¡tkowa warto±¢ kroku
double stepStep warto±¢, o jak¡ zmienia¢ mo»na krok
29
double[][] desiredPositionParams tablica zawieraj¡ca dziedziny poszczególnych
wspóªrz¦dnych, warto±¢ domy±ln¡ oraz warto±¢ kroku. Dla ka»dej wspóªrz¦dnej w
tablicy desiredPositionParams powinna znajdowa¢ si¦ czteroelementowa tablica
liczb typu double, odpowiadaj¡cych odpowiednio domy±lnej pocz¡tkowej warto±ci
wspóªrz¦dnej, minimalnej warto±ci, maksymalnej warto±ci oraz warto±ci kroku, o
jaki mo»na zmienia¢ t¦ wspóªrz¦dn¡.
4.2.4 Klasy robotów
Hierarchia klas reprezentuj¡cych roboty znajduje si¦ na rysunku 15.
Rysunek 15: Hierarchia klas reprezentuj¡cych obsªugiwane przez MRROC++ roboty
Graczna konsola sterownicza systemu MRROC++ stworzona zostaªa z my±l¡ o
przyszªym rozszerzeniu gamy obsªugiwanych robotów. Klasy reprezentuj¡ce obsªugiwane roboty musz¡ dziedziczy¢ po abstrakcyjnej klasie Robot. Interfejs klasy Robot
zawiera nast¦puj¡ce funkcje:
Robot( MrrocppUI, String) konstruktor klasy Robot. Jako argumenty przyjmuje
referencje do obiektu reprezentuj¡cego gªówne okno aplikacji i nazw¦ robota.
30
getMenu() abstrakcyjna metoda, zwracaj¡ca obiekt klasy javax.swing.JMenu, reprezentuj¡cy menu robota. Menu to zostanie dodane do menu Robot.
getName() zwraca nazw¦ robota.
getRobotId() zwraca identykator robota.
hideDialogs() powoduje zamkni¦cie wszystkich okien sªu»¡cych do sterowania danym robotem.
EDPLoad() obsªuguje uruchomienie procesu EDP wybranego robota po stronie
systemu MRROC++. Funkcja ta powinna przede wszystkim odblokowa¢ menu
robota.
EDPUnload() obsªuguje zako«czenie dziaªania procesu EDP wybranego robota po
stronie systemu MRROC++.
disableDialogs() blokuje menu i wszystkie okna sªu»¡ce do sterowania danym robotem. Uniemo»liwia to wydawanie robotowi jakichkolwiek polece«. Najcz¦±ciej
metoda ta stosowana jest po wydaniu robotowi rozkazu, a przed otrzymaniem z
serwera potwierdzenia jego wykonania. Ma to zapobiec próbie wykonania równolegle dwóch lub wi¦cej rozkazów przez pojedynczego robota.
enableDialogs() odblokowuje menu i okna dialogowe danego robota.
handleRequest( DialogId, ActionId, double[]) abstrakcyjna metoda obsªuguj¡ca komunikaty otrzymane z serwera, a skierowane do danego robota. Typy wyliczeniowe DialogId i ActionId opisane s¡ szerzej w rozdziale 4.4.
Najwa»niejsz¡ funkcj¡, której implementacj¦ dostarczy¢ maj¡ konkretne klasy reprezentuj¡ce rzeczywiste roboty, jest funkcja handleRequest(). Jako argumenty przyjmuje
identykatory okna dialogowego i akcji oraz tablic¦ liczb rzeczywistych. Obsªuga komunikatu otrzymanego z serwera realizowana jest w caªo±ci przez funkcj¦ handleRequest(),
a gªówna aplikacja jedynie po±redniczy w przekazaniu komunikatu. Dlatego te» dodanie
obsªugi nowego robota nie wymaga ingerencji w kod aplikacji, a jedynie implementacji
tej»e funkcji.
W czasie pisania pracy system MRROC++ przystosowany byª do sterowania pi¦cioma typami robotów. Trzy z nich to zmodykowane manipulatory Irp-6, dodatkowo
obsªugiwany jest pas transmisyjny (Conveyor) oraz Speaker. W aplikacji roboty te reprezentowane s¡ przez klasy dziedzicz¡ce po klasie Robot, opisane w dalszej cz¦±ci
rozdziaªu.
31
Klasa Irp6 Klasa ta dziedziczy po klasie Robot, sama za± stanowi klas¦ bazow¡ dla
zmodykowanych manipulatorów Irp-6. Klasy reprezentuj¡ce te zmodykowane wersje
robotów ró»ni¡ si¦ przede wszystkim liczb¡ stopni swobody, mog¡ równie» dodawa¢
funkcje specyczne dla danego typu manipulatora. Zmodykowane manipulatory Irp6
reprezentowane s¡ przez klasy Irp6OnTrack, Irp6Postument i Irp6Mechatronika.
Oprócz zapewnienia implementacji abstrakcyjnych metod klasy Robot, klasa Irp6
deniuje dziewi¦¢ okien dialogowych, sªu»¡cych do sterowania pojedynczym robotem.
Siedem z nich to okna typu ReadSetDialog, pozostaªe to proste okna dialogowe dziedzicz¡ce po klasie SimpleDialog. Wszystkie zdeniowane okna zostaªy przedstawione
poni»ej:
PostAngleAxisDialog sterowanie manipulatorem za pomoc¡ wspóªrz¦dnych w ukªadzie o±-k¡t
PostEulerDialog sterowanie manipulatorem za pomoc¡ wspóªrz¦dnych Eulera
PostJointsDialog sterowanie manipulatorem za pomoc¡ bezwzgl¦dnych poªo»e«
stawów po synchronizacji
PostMotorsDialog sterowanie manipulatorem za pomoc¡ bezwzgl¦dnych poªo»e«
silników po synchronizacji
PreMotorsDialog sterowanie manipulatorem za pomoc¡ wzgl¦dnych poªo»e« silników przed synchronizacj¡
ToolAngleDialog zadawanie pozycji narz¦dzia we wspóªrz¦dnych o±-k¡t
ToolEulerDialog zadawanie pozycji narz¦dzia we wspóªrz¦dnych Eulera
KinematicDialog sªu»y do podania numeru modelu kinematyki, który ma by¢ u»ywany
ServoAlgorithmDialog wybór algorytmu serworegulacji
Klasa Conveyor Klasa ta reprezentuje pas transmisyjny. Dostarcza ona implementacje abstrakcyjnych metod klasy Robot. Dodatkowo deniuje dwa okna dialogowe,
dziedzicz¡ce po klasie SimpleDialog:
MoveDialog sªu»y do zadawania pozycji pasa transmisyjnego
ServoAlgorithmDialog wybór algorytmu
32
Klasa Speaker Klasa ta reprezentuje syntezator mowy. Dostarcza ona implementacje abstrakcyjnych metod klasy Robot. Dodatkowo deniuje okno dialogowe PlayDialog, pozwalaj¡ce na wprowadzenie tekstu i przesªanie go do urz¡dzenia.
4.3 Serwer
Napisany w C++ serwer, dziaªaj¡cy po stronie systemu MRROC++, odbiera komunikaty z konsoli gracznej i wykonuje zawarte w nich polecenia. Wysyªa równie»
do konsoli klienckiej potwierdzenia wykonania polecenia oraz komunikaty otrzymane z
serwera, dotycz¡ce zmiany jego stanu i przebiegu wykonania zadania.
Zaimplementowany serwer posiada niebanaln¡ cech¦, która sama w sobie czyni zrealizowan¡ aplikacj¦ lepsz¡ od pierwowzoru. Serwer umo»liwia mianowicie równolegªe
wykonywanie polece« na poszczególnych robotach. Dotychczasowa konsola sterownicza nie przyjmowaªa »adnych rozkazów ruchu, je»eli jaki± rozkaz ju» byª realizowany
przez dowolny manipulator. W nowej wersji konsoli ograniczenie to dotyczy tylko pojedynczych robotów - które faktycznie mog¡ wykonywa¢ w danej chwili tylko jeden
rozkaz. Nie ma natomiast nieuzasadnionego ograniczenia równolegªego dziaªania kilku
robotów.
™ródªa serwera znajduj¡ si¦ w pliku ui_init.cc. Prototypy funkcji oraz wykorzystywane struktury danych zawarte s¡ z kolei w pliku gcc_ntox86/proto.h.
Dost¦p do funkcji systemu MRROC++, z których korzysta serwer, mo»liwy jest
przy u»yciu funkcji zawartych w pliku fun.cc. Zdeniowano tu odpowiedniki funkcji,
z których korzysta pierwotna konsola stworzona w Photon MicroGUI. zdeniowanych
równie» w pliku fun.cc w katalogu tej»e konsoli. Funkcje te nie zawieraj¡ jednak kodu
modykuj¡cego interfejs u»ytkownika, wzbogacone s¡ za to o mo»liwo±¢ przesyªania
potwierdzenia wykonania polecenia.
Funkcje ka»dego z robotów obsªugiwanych przez system zdeniowane s¡ plikach
fun_r_NAZWAROBOTA.cc. S¡ to odpowiedniki plików wykorzystywanych w pierwotnej konsoli, a ró»nice mi¦dzy nimi s¡ podobne, jak dla funkcji zdeniowanych w
pliku fun.cc. Dodatkowo funkcje ruchu oprócz potwierdzenia wykonania rozkazu przesyªaj¡ nowe wspóªrz¦dne manipulatora.
Funkcja init Dziaªanie serwera rozpoczyna si¦ wraz z wywoªaniem funkcji init. Realizuje ona funkcje swojego odpowiednika w pierwotnej konsoli. Inicjalizuje system
MRROC++, wczytuje warto±ci zmiennych globalnych systemu, uruchamia serwer gns
i dodaje obsªug¦ sygnaªów systemowych. Uruchamia równie» w osobnych w¡tkach funkcje server_thread i comm_thread.
Ze wzgl¦du na potrzeb¦ synchronizacji dost¦pu do ag typu int, okre±laj¡cych zdolno±¢ robota do wykonania kolejnego polecenia, funkcja init inicjalizuje sªu»¡ce do tego
33
semafory typu sem_t. Poniewa» wykorzystywane s¡ one w kilku ró»nych funkcjach,
zostaªy zrealizowane jako zmienne globalne. Aktualnie zdeniowane semafory i agi
zebrano w tabeli 1.
Semafor
Flaga
Znaczenie
sem_ui
block_ui
Dost¦p do funkcji przesyªaj¡cych informacj¦ do interfejsu
gracznego
sem_all
block_all
Dost¦p do dowolnego robota
sem_mp
block_mp
Dost¦p do procesu MP
sem_irp6_on_track
block_irp6_on_track
Dost¦p
do
manipulatora
Irp6OnTrack
sem_irp6_mechatronika
block_irp6_mechatronika Dost¦p
do
manipulatora
Irp6Mechatronika
sem_irp6_postument
block_irp6_postument
Dost¦p
do
manipulatora
Irp6Postument
sem_conveyor
block_conveyor
Dost¦p do manipulatora Conveyor
sem_speaker
block_speaker
Dost¦p do robota Speaker
Tablica 1: Semafory i agi u»ywane do synchronizacji dost¦pu do robotów
Podczas projektowania aplikacji rozwa»ane byªo rozwi¡zanie problemu dost¦pu do
pojedynczych robotów poprzez kolejkowanie rozkazów, jednak ostatecznie zwyci¦»yªa
koncepcja ignorowania polece« otrzymanych w trakcie wykonywania wcze±niejszych
rozkazów ruchu. Wykonanie cz¦±ci bowiem polece« zajmuje sporo czasu, dopuszczenie
wi¦c do kolejkowania polece« skutkowaªoby jeszcze wi¦kszym opó¹nieniem pomi¦dzy
nadaniem rozkazu a potwierdzeniem jego wykonania.
Blokada wykonania wi¦cej ni» jednego polecenia przez pojedynczego robota zaimplementowana jest po stronie konsoli klienckiej. Implementacja po stronie serwera
stanowi jedynie dodatkowe zabezpieczenie.
Funkcja server_thread Funkcja ta, dziaªaj¡ca w osobnym w¡tku, stanowi najwa»niejsz¡ cz¦±¢ serwera. Nasªuchuje ona na wybranym porcie na poª¡czenia przychodz¡ce
z gracznej konsoli klienckiej. Po nawi¡zaniu poª¡czenia sterowanie przekazywane jest
do gªównej p¦tli programu, w której funkcja ta czeka na przesªanie polecenia. Po otrzymaniu komunikatu od u»ytkownika, funkcja server_thread uruchamia w nowym w¡tku
funkcj¦ obsªugi zdarze« callfunc, do której przekazuje ten»e komunikat, a nast¦pnie
przechodzi w stan oczekiwania na kolejne polecenia.
34
Funkcja comm_thread Funkcja ta równie» dziaªa w osobnym w¡tku. Podstawowym jej zadaniem jest oczekiwanie na komunikaty przychodz¡ce od systemu
MRROC++. Otrzymane polecenia przesyªane s¡ do aplikacji klienckiej.
Obsªugiwane przez funkcj¦ comm_thread komunikaty to m.in. zapytania wysyªane przez procesy ECP i MP, steruj¡ce realizacj¡ zadania lokalnie przez pojedynczy
manipulator oraz globalnie, przez caªy system. Sªu»¡ one do komunikacji z u»ytkownikiem aplikacji klienckiej, a bardzo cz¦sto uzyskania od niego informacji niezb¦dnej
do wykonania zadania. Obsªugiwane typy polece«, identykowane przez warto±ci typu
wyliczeniowego ECP_TO_UI_COMMAND :
YES_NO pytanie do u»ytkownika, oczekuj¡ce na decyzj¦ typu Tak/Nie
MESSAGE komunikat dla u»ytkownika
DOUBLE_NUMBER pytanie o warto±¢ typu double
INTEGER_NUMBER pytanie o warto±¢ typu int
CHOOSE_OPTION pro±ba o wybór jednej z mo»liwych opcji
LOAD_FILE pytanie o nazw¦ pliku do wczytania
SAVE_FILE pytanie o nazw¦ pliku do zapytania
Pierwsze cztery polecenia zawieraj¡ tre±¢ pytania lub komunikatu, pi¡te zawiera dodatkowo list¦ opcji do wyboru. Dwa pozostaªe wykorzystuj¡ komunikat predeniowany
po stronie klienta.
Funkcja callfunc Funkcja ta odpowiada za obsªug¦ zdarze« przychodz¡cych od
u»ytkownika. Wywoªywana jest w osobnym w¡tku dla ka»dego otrzymanego z konsoli
klienckiej polecenia. Jako argument przyjmuje tre±¢ komunikatu.
Obsªuga zdarzenia realizowana jest w kilku krokach:
1. Sprawdzenie typu komunikatu Je»eli zawiera on informacje liczbowe, to funkcja
przydziela pami¦¢ na tablic¦ typu double, a nast¦pnie wypeªnia j¡ otrzymanymi
liczbami. Je»eli zawiera on jedynie informacj¦ tekstow¡, to jest ona zachowywana
bez zmian.
2. Okre±lenie obiektu docelowego polecenia Jest on identykowany przez
zmienn¡ RobotId. Adresatem polecenia mo»e by¢ pojedynczy robot lub system
MRROC++.
3. Sprawdzenie dost¦pno±ci adresata Ze wzgl¦du na niemo»no±¢ równolegªego wykonywania kilku polece« przez pojedynczego robota, nie s¡ realizowane polecenia
otrzymane przed zako«czeniem realizacji poprzedniego rozkazu ruchu.
35
4. Wykonanie rozkazu w przypadku dost¦pno±ci adresata Funkcja obsªuguj¡ca
rozkaz identykowana jest za pomoc¡ warto±ci zmiennych DialogId i ActionId.
Przed uruchomieniem funkcji ustawiana jest aga blokuj¡ca dost¦p do adresata.
Po wykonaniu rozkazu aga jest kasowana. Przekazywany do funkcji jest otrzymany od konsoli klienckiej komunikat tekstowy lub tablica liczb.
5. Pomini¦cie rozkazu w przypadku zaj¦to±ci adresata Funkcja ko«czy swoje dziaªanie, nie wywoªuj¡c »adnej funkcji.
4.4 Komunikacja
Komunikacja pomi¦dzy aplikacj¡ klienck¡, a serwerem dziaªaj¡cym po stronie systemu MRROC++ odbywa si¦ dwukierunkowo. Informacja przesyªana przez graczn¡
konsol¦ sterownicz¡ do serwera obejmuje:
• polecenia dla systemu MRROC++, np. uruchomienie procesu MP, zabicie procesów steruj¡cych robotami czy wczytanie pliku konguracyjnego
• rozkazy ruchu dla pojedynczych robotów, zawieraj¡ce docelowe wspóªrz¦dne
• polecenia dla poszczególnych robotów, np. »¡danie synchronizacji
• »¡danie przesªania stanu robota, m.in. jego aktualnych wspóªrz¦dnych
Serwer do klienta mo»e przesyªa¢:
• potwierdzenia wykonania operacji
• informacj¦ zwrotn¡ w odpowiedzi na »¡danie przesªania stanu robota
• komunikaty generowane przez dziaªaj¡ce procesy, wy±wietlane pó¹niej w konsoli
tekstowej w dolnej cz¦±ci gªównego okna
• komunikaty o bª¦dach
Wa»nym aspektem komunikacji mi¦dzy klientem a serwerem byªo rozpoznawanie zerwania poª¡czenia lub nieprawidªowego dziaªania jednej ze stron. W przypadku bª¦du
krytycznego po stronie systemu MRROC++ konsola czekaªaby w niesko«czono±¢ na
potwierdzenie wykonania rozkazu. Dlatego te» opisane w dalszej cz¦±ci rodziaªu klasy
i funkcje implementuj¡ zabezpieczenia, pozwalaj¡ce szybko stwierdzi¢ zerwanie poª¡czenia lub nieprawidªowe dziaªanie jednej ze stron.
36
4.4.1 Klient
Po stronie gracznej konsoli sterowniczej wysyªanie i odbieranie komunikatów odbywa si¦ za po±rednictwem dziaªaj¡cych w osobnych w¡tkach funkcji run klas Mrrocp-
pUI::SendQueue i MrrocppUI::ReadQueue. Przesyªane wiadomo±¢i reprezentowane s¡
w programie przez obiekty klasy MrrocppUI::Message
Klasa MrrocppUI::Message Klasa ta (Rysunek 16)reprezentuje komunikaty przesyªane z konsoli sterowniczej do serwera. Obiekty klasy Message posiadaj¡ nast¦puj¡ce
atrybuty:
type rodzaj wiadomo±ci - warto±¢ typu wyliczeniowego MessageType okre±laj¡ca
priorytet wysyªania wiadomo±¢i
message tre±¢ wiadomo±ci
timestamp znacznik czasu, okre±laj¡cy moment wygenerowania wiadomo±ci
Rysunek 16: Klasa MrrocppUI::Message
Klasa Message implementuje interfejs Comparable, umo»liwiaj¡cy porównywanie
i sortowanie obiektów tej klasy wzgl¦dem ich typu i czasu wygenerowania. Cecha ta
pozwala na implementacj¦ kolejek priorytetowych przechowuj¡cych obiekty klasy Mes-
sage. Tego rodzaju kolejka u»ywana jest w programie do nadawania wiadomo±ci w
kolejno±ci uwzgl¦dniaj¡cej ich priorytet. Priorytet ten okre±lany jest przez typ komunikatu - jedn¡ z warto±ci FatalError,NonFatalError,SystemError,Message lub Unknow-
nError - a nast¦pnie przez czas generacji. Takie rozwi¡zanie gwarantuje sekwencyjne
wykonywanie polece«, umo»liwia jednak natychmiastowe dostarczenie komunikatów o
bª¦dach istotnych dla dziaªania systemu.
37
Funkcja MrrocppUI::SendMessage() Do wysyªania komunikatów - reprezentowanych przez obiekty klasy Message - sªu»y przeªadowana funkcja Mrrocp-
pUI::SendMessage(). Przyjmuje ona nast¦puj¡ce argumenty:
RobotId identykator systemu lub robota, który wygenerowaª komunikat
DialogId identykator okna dialogowego, zawieraj¡¢ego komponent, który wygenerowaª zdarzenie b¦d¡ce ¹ródªem komunikatu
ActionId identykator akcji
string | double[] ci¡g znaków w przypadku komunikatu tekstowego lub tablica liczb
rzeczywistych
MessageType typ wiadomo±ci
Funkcja ta tworzy nowy obiekt klasy Message, a nast¦pnie wstawia go do kolejki
komunikatów do wysªania za pomoc¡ funkcji send() klasy MrrocppUI::SendQueue.
Klasa MrrocppUI::SendQueue Klasa ta reprezentuje kolejk¦ priorytetow¡ komunikatów do wysªania. Przechowuje ona komunikaty oraz wysyªa je do serwera w kolejno±ci wynikaj¡cej z priorytetu wiadomo±ci.
Klasa MrrocppUI::SendQueue dziedziczy po klasie java.lang.Thread, dzi¦ki czemu
jej metoda run() mo»e dziaªa¢ w osobnym w¡tku. Takie rozwi¡zanie pozwala na swobodne wysyªanie komunikatów nawet w przypadku wykonywania przez aplikacj¦ czasochªonnych operacji.
Ze wzgl¦du na wspomnian¡ wcze±niej konieczno±¢ kontroli poprawno±ci dziaªania
poª¡czenia pomi¦dzy klientem a serwerem, funkcja run() wysyªa co ustalony interwaª czasu do serwera pusty komunikat, pozwalaj¡cy po stronie serwera stwierdzi¢, »e
konsola pracuje poprawnie.
Klasa MrrocppUI::ReadQueue Klasa ta obsªuguje komunikaty przychodz¡ce z
serwera. Podobnie jak klasa MrrocppUI:SendQueue dziedziczy po java.lang.Thread i
dziaªa w osobnym w¡tku.
Metoda run() czyta komunikaty otrzymane z serwera i na podstawie przesª¡nych
identykatorów - RobotId,DialogId i ActionId - rozpoznaje adresata wiadomo±ci. Je»eli
adresatem jest system - wywoªywana jest odpowiednia metoda klasy MrrocppUI. Je»eli za± adresatem jest który± z obsªugiwanych robotów, wtedy komunikat oraz warto±ci
DialogId i ActionId przekazywane s¡ do funkcji handleRequest() obiektu reprezentuj¡cego danego robota.
Funkcja run() tej klasy stanowi kolejny element systemu rozpoznawania niepoprawnego dziaªania którego± z elementów. Mierzy ona czas pomi¦dzy kolejnymi otrzymanymi
komunikatami. Je»eli przekroczy on okre±lon¡ warto±¢, poª¡czenie zostanie zerwane.
38
4.4.2 Serwer
Komunikacja po stronie serwera zrealizowana zostaªa podobnie, jak w konsoli klienckiej. Komunikaty trzymane s¡ w kolejce i wysyªane na bie»¡co w osobnym w¡tku. Po
stronie serwera równie» zaimplementowane zostaªy mechanizmy sªu»¡ce wykryciu nieprawidªowego dziaªania aplikacji klienckiej.
Klasa Message Klasa ta zdeniowana jest w pliku gcc_ntox86/proto.h. Stanowi
odpowiednik klasy MrrocppUI::Message po stronie klienckiej, zawiera nawet takie same
atrybuty:
RobotId identykator systemu lub robota, który wygenerowaª komunikat
DialogId identykator okna dialogowego, zawieraj¡¢ego komponent, który wygenerowaª zdarzenie b¦d¡ce ¹ródªem komunikatu
ActionId identykator akcji
char[] ci¡g znaków stanowi¡cy komunikat
MessageType typ wiadomo±ci
Reprezentuje ona komunikat przesyªany z serwera do klienta. Zdecydowana wi¦kszo±¢ wysyªanych przez serwer wiadomo±ci to potwierdzenia wykonania rozkazu oraz
komunikaty tekstowe, generowane przez procesy steruj¡ce wykonaniem zadania, wy±wietlane pó¹niej na konsoli tekstowej po stronie klienta.
Funkcja replySend Funkcja ta sªu»y do wstawiania obiektów klasy Message do
kolejki komunikatów. Przyjmuje jeden argument - wska¹nik na obiekt klasy Message.
Synchronizacja dost¦pu Kolejka komunikatów u»ywana jest równolegle przez wiele
w¡tków - w¡tek reply_thread wysyªaj¡cy komunikaty do klienta, w¡tek comm_thread
wstawiaj¡cy komunikaty systemowe oraz w¡tki funkcji callfunc, wysyªaj¡cej potwierdzenia wykonania otrzymanych od u»ytkownika rozkazów. Pojawiªa si¦ wi¦c potrzeba
synchronizacji dost¦pu do kolejki, co zrealizowane zostaªo przy pomocy semaforów binarnych. Wstawianie do kolejki jest czynno±ci¡ bardzo krótk¡, dlatego te» oczekiwanie
na zwolnienie zasobu nie powoduje zauwa»alnego spowolnienia dziaªania aplikacji.
Funkcja reply_thread Funkcja ta, dziaªaj¡ca jako oddzielny w¡tek, odpowiada
za wysyªanie komunikatów do klienta. Pobiera ona z kolejki komunikatów wszystkie
dost¦pne w danej chwili wiadomo±ci, po czym wysyªa je do klienta
39
W¡tek comm_thread Funkja ta odpowiedzialna jest za generowanie wiadomo±ci
zawieraj¡cych komunikaty systemowe, wy±wietlane pó¹niej w konsoli tekstowej po stronie aplikacji klienckiej.
Funkcja pobiera za pomoc¡ wywoªania systemowego MsgReceive wiadomo±ci z systemu, a nast¦pnie tworzy obiekt klasy Message. Wygenerowana wiadomo±¢ wstawiana
jest nast¦pnie do kolejki komunikatów przy pomocy funkcji ReplySend.
4.5 Testy
Graczna konsola sterownicza zostaªa sprawdzona podczas testów na rzeczywistych
robotach, znajduj¡cych si¦ w laboratorium robotyki Instytutu Automatyki i Informatyki Stosowanej Politechniki Warszawskiej. Poprawno±¢ jej dziaªania wykazana zostaªa
podczas wykonywania przez roboty nast¦puj¡cych zada«:
• uczenia robota trajektorii doprowadzanie manipulatora do wybranych poªo»e«
i ich zapami¦tanie, a nast¦pnie odtwarzanie przez robota trajektorii
• ukªadania kostki Rubika wspóªpraca dwóch zmodykowanych manipulatorów
Irp6 wyposa»onych w system wizyjny i chwytak
• sprz¦»enia haptycznego dwóch manipulatorów Irp6
40
5 Podsumowanie
5.1 Wnioski
W ramach pracy powstaªa sprawnie dziaªaj¡ca nowa wersja gracznej konsoli sterowniczej systemu MRROC++. Aplikacja zostaªa zrealizowana w architekturze klientserwer, a jej funkcje rozdzielone zostaªy pomi¦dzy gracz¡ konsol¦ uruchamian¡ po
stronie klienta oraz proces serwera zintegrowany z systemem MRROC++. Komunikacja pomi¦dzy klientem i serwerem odbywa si¦ przy wykorzystaniu pary protokoªów
TCP/IP.
Nowa wersja aplikacji speªnia postawione przed ni¡ we wst¦pie wymagania. Do realizacji aplikacji klienckiej wybrana zostaªa technologia Java rmy Sun Microsystems,
sama za± konsola dziaªa jak applet j¦zyka Java. Pozwala to na uruchomienie konsoli
pod kontrol¡ wi¦kszo±ci wspóªczesnych systemów operacyjnych, a w szczególno±ci Linux, Windows, Unix i MacOS. Obok wieloplatformowo±ci takie rozwi¡zanie zapewnia
równie» ªatwo±¢ dystrybucji i aktualizacji oprogramowania.
Powstaªa graczna konsola ma wygl¡d, zgodnie z zaªo»eniami, bardzo podobny do
dotychczas u»ywanej, stworzonej w oparciu o Photon MicroGUI. Nowa konsola realizuje
równie» w caªo±ci funkcje pierwowzoru, pojawiªo si¦ jednak kilka istotnych usprawnie«.
Zbli»ony wygl¡d i identyczny sposób pracy z konsol¡ umo»liwia ªatw¡ i bezproblemow¡
migracj¦ u»ytkowników na now¡ wersj¦ konsoli sterowniczej.
Proces serwera napisany zostaª w j¦zyku C++, co umo»liwiªo jego ±cisª¡ integracj¦ ze struktur¡ MRROC++. Serwer udost¦pnia na bie»¡co informacj¦ o aktualnym
stanie systemu oraz wykonuje otrzymywane od u»ytkownika polecenia, czy to polecenia dla systemu MRROC++, czy te» rozkazy ruchu dla poszczególnych robotów. Jego
niew¡tpliw¡ zalet¡ jest niezale»no±¢ od stworzonej konsoli klienckiej, co pozwala na
wspóªprac¦ serwera z innymi aplikacjami, niekoniecznie powielaj¡cymi jedynie funkcje
gracznej konsoli sterowniczej.
Poprawno±¢ dziaªania gracznej konsoli sterowniczej zostaªa potwierdzona nie tylko
testami przeprowadzanymi przeze mnie podczas implementacji aplikacji, jak i po jej
zako«czeniu - prawdziw¡ prób¡ dla nowej wersji byªo praktyczne jej zastosowanie do
sterowania systemem wielorobotowym w wydziaªowym labolatorium 012. Próba ta zako«czyªa si¦ sukcesem, a szeroki wachlarz realizowanych w jej trakcie zada« pozwoliªo
dogª¦bnie przetestowa¢ poprawno±¢ dziaªania aplikacji.
5.2 Perspektywy rozwoju
Zrealizowana aplikacja stworzona zostaªa pod k¡tem wspóªpracy ze wszystkimi robotami, które obsªugiwane s¡ przez pierwotn¡ konsol¦ sterownicz¡, tj. trzy wersje robota przemysªowego Irp-6, pas transmisyjny Conveyor oraz efektor do emisji d¹wi¦ku
41
Speaker. Projektowana byªa ona jednak z my±l¡ o jak najªatwiejszym rozszerzaniu
gamy obsªugiwanych robotów, wi¦c dodanie nowego robota jest nieskomplikowane, a
jedyny wymagany nowy kod ¹ródªowy dotyczy dziaªa« specycznych dla tego» robota
(Dodatek A).
Dzi¦ki realizacji aplikacji w architekturze klient-serwer mo»liwe jest równie» stworzenie zdalnych konsoli sterowniczych opartych na innych ni» Java technologiach, jak
chocia»by ±rodowiska QT, GTK czy FLTK.
42
Literatura
[1] T. Winiarski C. Zieli«ski, W. Szynkiewicz and T. Kornuta. MRROC++ based
system description. Technical Report nr 06-9, IAIS, May Warsaw, 2006.
[2] QNX Realtime operating system (RTOS), www.qnx.com.
[3] Kr¦glewska U. Sobczyk J. ‘luzek A. Zieli«ska T. Zieli«ski C., Grodecki A. Sterownik robotów przeznaczony do celów badawczych. Technical report, IAIS, December
Warsaw, 1992.
[4] Kierzenkowski K. Zieli«ska T. Grodecki A. Gosiewski A. Szynkiewicz W., Zieli«ski C. ‘rodowisko programowe do tworzenia sterowników wielorobotowych dla
zªo»onych zastosowa«. Technical report, IAIS, May Warsaw, 1997.
[5] W. Szynkiewicz M.Staniak W. Czajewski C. Zieli«ski, T. Winiarski and T. Kornuta. MRROC++ based controller of a dual arm robot system manipulating a
rubik's cube. Technical Report 06-10, IAIS, April Warsaw, 2006.
[6] QNX Photon microGUI, www.qnx.com/products/middleware/graphics/photon.html.
[7] Java SE at a Glance, java.sun.com.
[8] Creating a GUI with JFC/Swing, java.sun.com.
[9] T. Socolofsky and C. Kale. A TCP/IP Tutorial (Request for comments 1180),
http://tools.ietf.org/html/rfc1180 January 1991
[10] P. Szuadowicz. Wizualizacja pracy robotów w systemie MRROC++. Master's
thesis, WEiTI, Warsaw, 2008.
43
Dodatek A - Dodanie obsªugi nowego robota
Zrealizowana przeze mnie aplikacja pisana byªa z my±l¡ o przyszªym rozszerzeniu
gamy obsªugiwanych przez system MRROC++ robotów. Zarówno serwer, jak i graczna konsola, napisane zostaªy tak, by dodanie nowego robota wymagaªo jak najmniej
zmian w kodzie aplikacji. W poni»szym rozdziale zaprezentuj¦ czynno±ci wystarczaj¡ce
do zapewnienia obsªugi robota kartezja«skiego. Oferowaª on b¦dzie jedynie podstawowe
funkcje w celu mo»liwie czytelnego przedstawienia realizacji tego zadania.
Klient
Pierwszym krokiem po stronie klienckiej jest stworzenie klasy reprezentuj¡cej robota
- nazwijmy j¡ cRobot - dziedzicz¡cej po klasie Robot. Powinna ona zawiera¢ implementacje odziedziczonych z klasy Robot abstrakcyjnych metod, dodatkowo ruchy r¦czne
tym robotem mo»liwe b¦d¡ przy u»yciu okna dialogowego MoveDialog, dziedzicz¡cego
po ReadSetDialog.
Klasa reprezentuj¡ca robota
Kod klasy cRobot przedstawiono poni»ej:
//cRobot.java
class Conveyor extends Robot
{
/**
* Typ wyliczeniowy okre±laj¡cy akcj¦
*/
enum ActionId{Read,Set};
/**
* Typ wyliczeniowy okre±l¡j¡cy okno dialogowe
*/
enum DialogId{EDPLoad,EDPUnload,Move};
/**
* Tworzy obiekt robota
*
* @param MrrocppUI ui referencja do gªównego okna aplikacji
* @param int id identyfikator robota
* @param String name nazwa robota
*/
public cRobot(MrrocppUI ui,int id,String name)
{
super(ui,id,name);
}
/**
* Blokuje okna dialogowe
*/
public void disableDialogs()
{
moveDialog.getGlassPane().setVisible(true);
44
}
/**
* Odblokowuje okna dialogowe
*/
public void enableDialogs()
{
moveDialog.getGlassPane().setVisible(false);
}
/**
* Zwraca menu robota
*/
JMenu getMenu()
{
menu = new JMenu(name);
menu.setEnabled(false);
edpLoadAction = new JMenuItem("EDP Load",'L');
edpLoadAction.addActionListener(this);
menu.add(this.edpLoadAction);
edpUnloadAction = new JMenuItem("EDP Unload",'U');
edpUnloadAction.addActionListener(this);
menu.add(this.edpUnloadAction);
edpUnloadAction.setEnabled(false);
menu.addSeparator();
moveAction = new JMenuItem("Move",'M');
servoAction.setEnabled(false);
servoAction.addActionListener(this);
menu.add(this.servoAction);
return menu;
}
/**
* Ukrywa okna dialogowoe
*/
public void hideDialogs()
{
if(moveDialog != null)
{
moveDialog.setVisible(false);
}
}
/**
* Obsªuguje uruchomienie procesu EDP robota
*/
public void EDPLoad()
{
if(moveDialog == null)
{
moveDialog = new MoveDialog(ui,robotId);
}
moveAction.setEnabled(true);
edpLoadAction.setEnabled(false);
edpUnloadAction.setEnabled(true);
}
/**
45
* Obsªuguje zabicie procesu EDP robota
*/
public void EDPUnload()
{
moveAction.setEnabled(false);
edpLoadAction.setEnabled(true);
edpUnloadAction.setEnabled(false);
hideDialogs();
}
/**
* Obsªuguje zdarzenia wygenerowane przez komponenty zwi¡zane z robotem
*
* @param ActionEvent e obiekt reprezentuj¡cy zdarzenie
*/
public void actionPerformed(ActionEvent e)
{
if(e.getSource() == edpLoadAction)
{
ui.SendMessage(robotId,DialogId.EDPLoad.ordinal(),0,"",
MessageType.FatalError);
}
else if(e.getSource() == edpUnloadAction)
{
ui.SendMessage(robotId,DialogId.EDPUnload.ordinal(),0,"",
MessageType.FatalError);
}
else if(e.getSource() == moveAction)
{
MoveDialog.showDialog();
ui.SendMessage(robotId,DialogId.Move.ordinal(),
ActionId.Read.ordinal(),"",MessageType.FatalError);
}
}
/**
* Obsªuguje komunikaty skierowane do robota
*
* @param int dialogId identyfikator okna dialogowego
* @param int actionId e identyfikator akcji
* @param double[] values przeslane wartosci
*/
public void handleRequest(int dialogId,int actionId,double[] values)
{
switch (dialogId)
{
case DialogId.Move.ordinal():
{
moveDialog.UpdateDialog(values);
break;
}
case DialogId.EDPLoad.ordinal():
{
EDPLoad();
break;
}
case DialogId.EDPUnload.ordinal():
{
EDPUnload();
46
break;
}
}
}
private JMenu menu;
private JMenuItem edpLoadAction,edpUnloadAction,moveAction;
private MoveDialog moveDialog;
}
Okno ruchów r¦cznych
Mo»liwo±ci zdeniowanej klasy cRobot ograniczaj¡ si¦ do uruchomienia i zatrzymania procesu EDP robota. Umo»liwia¢ ma ona jeszcze ruchy r¦czne robotem, dlatego
te» nale»y zdeniowa¢ w klasie cRobot zagnie»d»on¡ klas¦ MoveDialog, dziedzicz¡c¡ po
ReadSetDialog i reprezentuj¡c¡ okno ruchów r¦cznych.
//cRobot.java
class MoveDialog extends ReadSetDialog
{
public MoveDialog(MrrocppUI ui,int id)
{
super(ui,name + " - Move");
robotId = id;
dialogId = DialogId.Move.ordinal();
//Wspóªrz¦dne robota
variableLabelText = "Axis";
variableNumber = 3;
variableLabels = new String[]{"X","Y","Z"};
//Wª¡czenie importowania pozycji i ruchów krokowych
enableImportExport = true;
enableIncremental = true;
//Parametry kroku
stepMin = 0;
stepMax = 10;
stepDefault = 0;
stepStep = 0.01;
//Zakresy ruchu robota
desiredPositionParams =
new double[][]{
{0,-100,100,0.5},
{0,-100,100,0.5},
{0,-100,100,0.5},
};
47
//Rysowanie okna dialogowego - odziedziczone z ReadSetDialog
drawDialog();
}
}
Klasa MrrocppUI
Dodanie okna dialogowego uzupeªnia brakuj¡ce funkcje w klasie cRobot. Jedyne, co
pozostaªo jeszcze do zrobienia po stronie klienckiej to dodanie obsªugu zdeniowanego
wcze±niej robota do gracznej konsoli sterowniczej. Sprowadza si¦ to do dodania jednej
linijki do kostruktora klasy MrrocppUI.
//MrrocppUI.java
/**
* Inicjalizuje wektor obiektów reprezentuj¡cych obsªugiwane roboty
*/
public MrrocppUI()
{
robots = new Vector<Robot>();
addRobot(new Irp6OnTrack(this,1,"Irp6 on Track"));
addRobot(new Irp6Postument(this,2,"Irp6 Postument"));
addRobot(new Conveyor(this,3,"Conveyor"));
addRobot(new Speaker(this,4,"Speaker"));
addRobot(new Irp6Mechatronika(this,5,"Irp6 Mechatronika"));
//Dodanie robota kartezja«skiego
addRobot(new Irp6Mechatronika(this,6,"Kartezjanski"));
createGUI();
}
Skutkiem dodania tej linijki b¦dzie rozszerzenie gracznej konsoli sterowniczej o
obsªug¦ nowego robota klasy cRobot o identykatorze równym 6. Od tej chwili menu
robota pojawia¢ si¦ b¦dzie w menu górnym Robot, co umo»liwi dost¦p do funkcji robota. Przekazywane mu równie» b¦d¡ skierowane do niego komunikaty otrzymane z
serwera. W oknie dialogowym Process Control, sªu»¡cym do sterowania przebiegiem
wykonania zadania, zostanie dodany rónie» nowy wiersz przycisków, odpowiadaj¡cych
za sterowanie wykonaniem zadania na nowym manipulatorze.
Serwer
W porównaniu ze stron¡ klienck¡, po stronie serwera potrzeba zdecydowanie mniej
modykacji, aby umo»liwi¢ obsªug¦ kolejnego robota. Obsªuga ta wymaga oczywi±cie
dodatkowo zaimplementowania w systemie MRROC++ funkcji tego» robota, nie jest
to jednak przedmiotem tej pracy, a dodanie obsªugi robota do serwera odbywa si¦ przy
zaªo»eniu istniej¡cej ju» implementacji robota w systemie.
48
Synchronizacja dost¦pu do manipulatora
W celu zapobie»enia jednoczesnego wykonania wi¦cej ni» jednego rozkazu przez
pojedynczy manipulator, niezb¦dne jest zdeniowanie dwóch zmiennych:
sem_t sem_cRobot semafor
binarny,
synchronizuj¡cy
dost¦p
do
agi
block_cRobot
int block_cRobot aga okre±laj¡ca dost¦pno±¢ robota
Denicje tych dwóch zmiennych nale»y umie±ci¢ w pliku ui_init.cc.
sem_t sem_cRobot;
int block_cRobot = 0;
Dodatkowo w funkcji init() nale»y zainicjalizowa¢ nowy semafor:
//ui_init.cc
int init()
{
if(sem_init(&sem,0,1) == -1
|| sem_init(&sem_conveyor,0,1) == -1
|| sem_init(&sem_irp6_on_track,0,1) == -1
|| sem_init(&sem_irp6_postument,0,1) == -1
|| sem_init(&sem_irp6_mechatronika,0,1) == -1
|| sem_init(&sem_speaker,0,1) == -1
//semafor synchronizuj¡cy dost¦p do nowego robota
|| sem_init(&sem_cRobot,0,1) == -1
|| sem_init(&sem_ui,0,1) == -1
|| sem_init(&sem_mp,0,1) == -1)
{
perror("Unable to initialize semaphore\n");
return NULL;
}
//reszta funkcji init()...
}
Obsªuga rozkazów skierowanych do robota
Do obsªugi rozkazów zdeniowa¢ trzeba funkcj¦, przyjmuj¡c¡ jako parametry dwa
identykator - okna dialogowego i akcji - oraz tablic¦ przesª¡nych od klienta parametrów. Zwyczajowo funkcj¦ t¦ nazywa si¦ NAZWAROBOTA_handle_request() i umieszcza w pliku fun_r_NAZWAROBOTA.cc. Kod tej funkcji zale»ny jest ju» od tego, jakie
rozkazy robot przyjmuje. Powinna ona na podstawie przesªanych identykatorów wywoªa¢ odpowiednie metody, implementuj¡ce dziaªania robota po stronie MRROC++.
Metody te powinny znajdow¡c si¦ w pliku fun_r_NAZWAROBOTA.cc. Dodatkowo
w pliku gcc_ntox86/proto.h nale»y zdeniowa¢ staª¡ NAZWAROBOTA o warto±ci
równej identykatorowi po stronie gracznej konsoli oraz staªe reprezentuj¡ce akcje
równe pozycjom odpowiadaj¡cych im po stronie klienckiej. W tym wypadku w pliku
gcc_ntox86/proto.h powinna znale¹¢ si¦ linijka:
49
#define CROBOT 6
#define EDPLOAD 0
#define EDPUNLOAD 1
#define MOVE 2
Na potrzeby przykªadu zakªadam, »e w pliku fun_r_NAZWAROBOTA.cc zdeniowane zostaªy nast¦puj¡ce funkcje:
EDP_cRobot_create() uruchamia proces EDP robota
EDP_cRobot_slay() zabija proces EDP robota
cRobot_Move() wykonuje ruch do zadanych wspóªrz¦dnych
UWAGA! Bardzo wa»ne jest, by ka»de wywoªanie funkcji NAZWAROBOTA_handle_request() skutkowaªo nadaniem komunikatu zwrotnego do serwera,
zawieraj¡ce identyczne identykator jak te, przekazane do funkcji. Mo»na to uczyni¢
albo w kodzie funkcji NAZWAROBOTA_handle_request(), albo w kodzie funkcji z
niej woªanych.
Przykªadowy kod funkcji NAZWAROBOTA_handle_request() przedstawiono poni»ej:
//fun_r_cRobot.cc
/**
* Obsªuguje komunikaty skierowane do robota cRobot
*/
int cRobot_handle_request(int DialogId,int ActionId,double[] values)
{
switch(DialogId)
{
case EDPLOAD:
EDP_cRobot_create();
break;
case EDPUNLOAD:
EDP_cRobot_slay();
break;
case MOVE:
cRobot_Move(values);
break;
}
//Wysªanie potwierdzenia wykonania polecenia
replySend(new Message(CROBOT,DialogId,ActionId,0,NULL,NULL));
}
Obsªuga polece« otrzymanych z konsoli
Aby doda¢ obsªug¦ rozkazów dla nowego robota otrzymywanych z konsoli klienckiej, nale»y ju» tylko rozszerzy¢ funkcj¦ callfunc. Jednym z jej elementów jest wyra»enie
50
switch, które w zale»no±ci od przesªanego identykatora robota sprawdza jego dost¦pno±¢, a nast¦pnie wywoªuje odpowiedni¡ fukcj¦ obsªugi zdarze«. Kod wyra»enia case,
które nale»y doda¢, przedstawiono poni»ej:
//ui_init.cc
case CROBOT:
{
//Sprawdzenie dost¦pno±ci robota
sem_wait(&sem_cRobot);
if(block_cRobot == 1 || (!ui_robot.cRobot))
{
sem_post(&sem_cRobot);
return (void*)NULL;
}
block_cRobot = 1;
sem_post(&sem_cRobot);
//Obsªuga rozkazu
cRobot_handle_request(DialogId,ActionId,values);
//Zwolnienie robota po wykonaniu polecenia
sem_wait(&sem_cRobot);
block_cRobot = 0;
sem_post(&sem_cRobot);
break;
}
Wª¡czenie obsªugi nowego manipulatora w funkcj¦ callfunc wyczerpuje modykacje
niezb¦dne do tego, by rozszerzy¢ graczn¡ konsol¦ sterownicz¡ o mo»liwo±¢ sterowania
nowym robotem.
51