Gra czna konsola sterownicza systemu MRROC++ stworzona w
Transkrypt
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