Symulacja robota Polycrank wsystemie MRROC++

Politechnika Warszawska

Wydział Elektroniki i Technik Informacyjnych

Instytut Automatyki i Informatyki Stosowanej

Rok akademicki 2010/2011

Praca dyplomowa magisterska

Mariusz Żbikowski

Symulacja robota Polycrank w systemie

MRROC++

Opiekun pracy:

dr inż. Tomasz Winiarski

Ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Podpis Przewodniczącego

Komisji Egzaminu Dyplomowego

Podziękowania

Za merytoryczną pomoc podczas tworzenia pracy podziękowania z mojej strony należą

się: dr inż. Tomaszowi Winiarskiemu, dr inż. Wojciechowi Szynkiewiczowi, mgr inż. Krzysz-

tofowi Czajkowskiemu, Konradowi Banachowiczowi, Adamowi Skubisowi oraz Krzysztofowi

Łoźnemu. Moja praca dyplomowa nie powstałaby bez współpracy z przedstawicielami Za-

kładu Teorii Maszyn i Robotów Wydziału Mechanicznego Energetyki i Lotnictwa Politechniki

Warszawskiej. Szczególne podziękowania należą się dr inż. Krzysztofowi Mianowskiemu oraz

mgr inż. Jarosławowi Jankowskiemu.

Specjalność : Systemy Informacyjno-Decyzyjne

Data urodzenia : 1985.07.18

Data rozpoczęcia studiów : 2005.02.21

Życiorys

Urodziłem się 18 lipca 1985 roku w Ciechanowie. W roku 2004 ukończyłem I Liceum

Ogólnokształcące im. Zygmunta Krasińskiego w Ciechanowie. Od 21 lutego 2005 studiuje

na wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. W roku 2009

obroniłem pracę inżynierską pt. Graficzne środowisko symulacyjne systemu wielomanipulato-

rowego. Moje zainteresowania zawodowe związane są z grafiką komputerową i przetwarzaniem

obrazów.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

podpis studenta

Egzamin dyplomowy

Złożył egzamin dyplomowy w dn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Z wynikiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ogólny wynik studiów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dodatkowe wnioski i uwagi Komisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Streszczenie

Celem pracy magisterskiej było opracowanie i implementacja metody symulacji robota

Polycrank w systemie sterowania robotów MRROC++. Robot Polycrank ma 6 stopni swobody o

teoretycznie nieograniczonych zakresach obrotów w przegubach. Może być wykorzystany do

bardzo szybkiego podejmowania obiektów np. z linii technologicznej w ruchu.

Główne technologie wykorzystane w pracy to system MRROC++, symulator chwytania Gra-

spIt, programy do tworzenia i konwersji modeli 3D takie jak Unigraphics NX5, 3dsMax oraz

Deep Exploration 5. W systemie MRROC++ został zaimplementowany sterownik dla robota Po-

lycrank oraz proste zadanie wykorzystujące generator trajektorii Smooth. Praca wymagała

dodania do programu GraspIt modelu 3D manipulatora oraz napisania pliku konfiguracyjnego

zawierającego kinematykę prostą tego robota w notacji Denavita-Hartenberga. Najważniejszym

elementem zaimplementowanym w symulatorze GraspIt był interfejs pozwalający na komuni-

kację z systemem MRROC++, zapis i odtwarzanie trajektorii oraz zapis położeń interpolacyjnych.

Umożliwiło to opracowanie metody symulacji i stworzenie środowiska badawczego, w którym

można realizować eksperymenty związane z pracą robota Polycrank.

Wyniki przeprowadzonych eksperymentów pokazują, że symulacja robota nie wymaga im-

plementacji kinematyki prostej i odwrotnej explicite w systemie MRROC++. Jest to możliwe

poprzez umiejętne wykorzystanie zaawansowanych możliwości generatora trajektorii Smooth

i programu GraspIt.

Słowa kluczowe: Polycrank, Graspit, MRROC++ , sterownik EDP, symulacja, Qt.

Abstract

Title: Polycrank robot simulation in the MRROC++ .

The aim of this thesis was to design and implement method of simulation of Polycrank

robot using the robot control system MRROC++. The Polycrank has 6 degree of freedom, without

joint limits. It may be usefull for high-speed cyclic gross motion realization, for example for

a belt conveyor operaton.

The main software used in the work were the MRROC++, a grasp simulator GraspIt, a 3D

modeling and converting programs such as Unigraphics NX5, 3dsMax and Deep Exploration 5.

In the MRROC++ a driver for robot was implemented and simple task using Smooth generator.

I have added 3D model of the Polycrank to GraspIt and I have written the configuration file

contain the Denavit-Hartenberg parameters of robot joints. The most important element of the

implementation in GraspIt was user interface which allows to connect with MRROC++, record

and play robot trajectory and save interpolation positions. The result of implementation were

method of simulation and research environment in which experiments can be performed .

The results of the experiments show that in robot simulation it is not necessary to directly

implement direct and inverse kinematics solvers of robot.

Keywords: Polycrank, Graspit, MRROC++ , EDP driver, simulation, Qt.

Spis treści

Życiorys 3

Streszczenie 4

1 Wstęp 8

1.1 Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Zawartość Rozdziałów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Robot Polycrank 10

2.1 Charakterystyka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Zastosowanie robota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Model 3D 16

3.1 Unigraphics NX5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Deep Exploration 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 3ds Max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Format Open Inventor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Graspit 26

4.1 Opis techniczny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Opis głównych funkcji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Kinematyka prosta robota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.1 Notacja Denavita-Hartenberga DH . . . . . . . . . . . . . . . . . . . . 29

4.3.2 Zmodyfikowana Notacja Denavita-Harteberga ZDH . . . . . . . . . . . 29

4.3.3 Parametry Denavita-Harteberga w Graspit . . . . . . . . . . . . . . . 30

4.4 Plik konfiguracyjny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5 Model 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.6 Kinematyka odwrotna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.7 Sceny 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Qt 43

5.1 Opis technologii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2 Sygnały i sloty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Komunikacja sieciowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6

SPIS TREŚCI

5.4 Graficzny interfejs użytkownika . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 System MRROC++ 49

6.1 Struktura ramowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2 Konsola sterownicza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.3 Generator Smooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7 Specyfikacja wymagań 55

7.1 Główne wymagania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.2 Analiza wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8 Implementacja 58

8.1 Sekwencja operacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8.2 Implementacja w Graspit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.2.1 Zapis położeń interpolacyjnych . . . . . . . . . . . . . . . . . . . . . . 63

8.2.2 Komunikacja z MRROC++ . . . . . . . . . . . . . . . . . . . . . . . . 64

8.2.3 Odtwarzanie trajektorii . . . . . . . . . . . . . . . . . . . . . . . . . . 66

8.3 Implementacja w MRROC++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.3.1 Sterownik EDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8.3.2 UI-PhAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.3.3 UI-Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.3.4 Zadanie MP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

9 Badania 75

9.1 Eksperyment 1 - ruch chwytaka w pionie wzdłuż filaru . . . . . . . . . . . . . 75

9.2 Eksperyment 2 - wykrywanie blatu stołu . . . . . . . . . . . . . . . . . . . . . 76

9.3 Eksperyment 3 - ruch chwytaka z jednego filaru na drugi i z powrotem . . . . 77

9.4 Ocena badań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

10 Podsumowanie 80

10.1 Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

10.2 Perspektywy rozwoju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Bibliografia 82

A Zawartość załączonej płyty CD 85

B Spis symboli i skrótów 86

Spis rysunków 87

Spis tablic 90

Spis wydruków 91

7

Rozdział 1

Wstęp

1.1 Cel pracy

Celem pracy magisterskiej była symulacja robota Polycrank widocznego poniżej na zdję-

ciu 1.1. Aby móc symulować pracę manipulatora w systemie MRROC++ zaistniała potrzeba

przeniesienia go do wirtualnego świata 3D. Umożliwiło to opracowanie metody symulacji i

stworzenie środowiska badawczego, w którym można przeprowadzać eksperymenty związane

z pracą robota Polycrank.

Rysunek 1.1: Robot Polycrank w laboratorium robotyki Instytutu Automatyki i Informatyki

Stosowanej Politechniki Warszawskiej widziany z trzech stron: z boku, z przodu, z tyłu.

8

1.2. ZAWARTOŚĆ ROZDZIAŁÓW

1.2 Zawartość Rozdziałów

Początkowe rozdziały wprowadzają w tematykę pracy, zawierają informację dotyczące

manipulatora Polycrank. Kolejne rozdziały przybliżają główne technologie wykorzystane w

projekcie dyplomowym oraz szczegóły implementacyjne. Na końcu znajdują się główne wnioski

i perspektywy rozwoju pracy.

W rozdziale 2 przedstawiono najważniejsze informacje na temat robota Polycrank. Rozdział

został wzbogacony o odpowiednie rysunki przybliżające budowę manipulatora.

W rozdziale 3 znajduje się opis wykorzystanych w pracy programów do tworzenia modeli

3D. W rozdziale omówiono użyte formaty plików graficznych 3D, w szczególności format Open

Inventor.

W rozdziale 4 umieszczono opis symulatora chwytania GraspIt. W rozdziale opisano główne

funkcje programu oraz sposób dodawania nowych robotów do tego środowiska na przykładzie

robota Polycrank.

W rozdziale 5 przybliżono główne możliwości technologii Qt.

W rozdziale 6 przedstawiono zarys struktury ramowej MRROC++. W głównej mierze rozdział

został poświęcony na opis systemu MRROC++, konsoli sterowniczej oraz generatora trajektorii

Smooth.

W rozdziale 7 można znaleźć specyfikację głównych wymagań stawianych pracy. Rozdział

zawiera szczegółowy opis wymagań oraz analizę najważniejszych problemów związanych z

implementacją.

Szczegóły implementacyjne zawiera rozdział 8. W podrozdziale 8.1 została opisana opraco-

wana metoda symulacji robota Polycrank. Wprowadzone zmiany w programie GraspIt zostały

przedstawione w podrozdziale 8.2. Zaimplementowane elementy w systemie MRROC++ zostały

omówione w podrozdziale 8.3.

Wybrane eksperymenty przeprowadzone w ramach badań zostały opisane w rozdziale 9.

Rozdział 10 zawiera podsumowanie uzyskanych wyników, główne wnioski towarzyszące

wykonanym badaniom i możliwości dalszego rozwoju pracy.

9

Rozdział 2

Robot Polycrank

Główne problemy konstrukcyjne i technologiczne oraz wyniki wstępnych badań prototypu

robota Polycrank zostały przedstawione w pracach [19] oraz [18]. Szczegółowy opis kinematyki

prostej i odwrotnej manipulatora znajduję się w pracy [27]. Lektura tych publikacji pozwo-

liła mi na przedstawienie najważniejszych informacji charakteryzujących robota Polycrank w

poniższym rozdziale.

2.1 Charakterystyka

Robot Polycrank ma szeregową strukturę kinematyczną złożoną z siedmiu par obrotowych.

Kąty obrotu dwóch par są ze sobą sprzężone. Sprzężone człony widoczne są na zdjęciach 2.2.

Dzięki sprzężeniu tych dwóch par robot ma sześć stopni swobody. Stopnie swobody zostały

zaznaczone na rysunku 2.3. Zakresy obrotów w przegubach teoretycznie są nieograniczone.

W praktyce są one jednak ograniczone w dużej mierze przez przewody. Przestrzeń robocza

manipulatora ma kształt pełnego walca i została przedstawiona na rysunku 2.1.

Rysunek 2.1: Przestrzeń robocza robota Polycrank.

Główne elementy konstrukcji robota Polycrank widoczne są na rysunku 2.4. Nowością kon-

cepcji manipulatora o nieograniczonych zakresach ruchów obrotowych w przegubach są człony

w kształcie ukośnych korb o lekkiej konstrukcji powłokowej. Są one połączone ze sobą za po-

10

2.1. CHARAKTERYSTYKA

Rysunek 2.2: Sprzężone ze sobą dwa człony robota Polycrank w wybranych, charakterystycz-

nych położeniach.

Rysunek 2.3: Stopnie swobody robota Polycrank zaznaczone na trzech widokach. A - widok z

boku, B - widok z przodu, C - widok na chwytak.

mocą pojedynczych łożysk krzyżowo-rolkowych. Ulokowane wewnątrz tych korb równoległo-

wody, widoczne na rysunku 2.5 służą do transmisji napędu.

11

2.1. CHARAKTERYSTYKA

Rysunek 2.4: Główne elementy budowy robota Polycrank.

Trzy pierwsze człony tworzą płaski łańcuch kinematyczny o pionowych osiach obrotu,

który jest napędzany przez silniki bezpośredniego napędu DD 1 zamontowane współosiowo w

podstawie. Dwa pierwsze człony są ukośnymi korbami, a trzeci ma kształt kolumny. Napęd

pierwszych trzech stopni swobody przenoszony jest za pomocą układu równoległowodów. War-

tości współrzędnych wewnętrznych qi równe są kątom fi obrotu wałów odpowiednich silników,

co można zapisać następującymi wzorami:

q1 = f1 (2.1)

q2 = f2 (2.2)

q3 = f3 (2.3)

Trzy następne człony tworzą płaski łańcuch kinematyczny o poziomych osiach obrotu,

którego ostatni człon jest pierwszym elementem kiści. Jest on wraz z kiścią napędzany przez

silniki AC z przekładniami związanymi z członem trzecim. Prostowód realizujący ruch pio-

nowy ( sprzężone współrzędne q4 i q5 ) napędzany jest poprzez przekładnie o sumarycznym1ang. Direct Drive

12

2.2. ZASTOSOWANIE ROBOTA

Rysunek 2.5: A-ulokowane wewnątrz korb równoległowody służące do transmisji napędu, B-

same równoległowody połączone za pomocą łożysk.

przełożeniu P4. Zależność między współrzędną q4 a kątem obrotu wału silnika f4 można za-

pisać wzorem:

q4 = P4f4 (2.4)

Silniki napędzające człony 6 i 7 zamocowane są na członie 3. Napęd od silników do me-

chanizmu kiści przenoszony jest poprzez układy równoległowodów umieszczonych w członach

4 i 5 oraz przekładnie. Dobrze ilustruje to rysunek 2.6 pochodzący z publikacji [12]. Analiza

dynamiczna robota nie jest przedmiotem niniejszej pracy. Szczegółową analizę mechanizmu

przeniesienia napędu manipulatora Polycrank można znaleźć w pracy magisterskiej [13]. Do

analizy dynamicznej robota Polycrank wykorzystano oprogramowanie MSC ADAMS 2, a wy-

brane elementy odkształcalne zostały wykonane w środowisku ANSYS.

2.2 Zastosowanie robota

Końcówka robota Polycrank może rozwijać bardzo duże prędkości, maksymalnie do 5ms z

wysoką precyzją rzędu 0.2 mm. Robot może być wykorzystany do wykonywania następujących

prac:

• szybkie podejmowanie obiektów z linii technologicznej w ruchu, ich sortowanie i palety-

zacja,2ang. Advanced Dynamic Analysis of Mechanical Systems from MSC Software

13


Rysunek 2.6: A-zaznaczone główne człony robota Polycrank: 0-baza, 1, 2, 3, 4, 5, 6, 7-chwytak,

B-mechanizm przeniesienia napędu do kiści.

• operowania głowicą plazmową lub laserową,

• natryskiwanie twardych powłok przy regeneracji lub utwardzaniu powierzchni,

• sortowanie i paletyzacja w procesie utylizacji odpadów w sortowniach wielkomiejskich .

W pracy [17] zostały ponadto zaprezentowane możliwości wykorzystania dwóch robotów

Polycrank jednocześnie. Wykorzystując ich nieograniczone zakresy obrotów w stawach można

zastosować je do wielokrotnego obracania bardzo dużych obiektów, co zostało pokazane np.

na rysunku 2.7.

Rysunek 2.7: Wielokrotne obracanie wokół osi X2 bardzo dużym obiektem przy wykorzystaniu

dwóch manipulatorów Polycrank.

Manipulatory te można także wykorzystać do manipulowania bardzo długimi obiektami,

co widać na rysunku 2.8.

14


Rysunek 2.8: Manipulowanie bardzo długim obiektem przy wykorzystaniu dwóch manipula-

torów Polycrank.

15

Rozdział 3

Model 3D

Chcąc symulować pracę robota wskazane jest stworzenie dopracowanego modelu kom-

puterowego 3D wiernie odwzorowującego rzeczywistego manipulatora. Podczas modelowania

należy pamiętać, aby zachować odpowiednie proporcje i kształty.

3.1 Unigraphics NX5

Na początku realizacji projektu otrzymałem model 3D od konstruktora robota Polycrank,

dr inż. Krzysztofa Mianowskiego z Wydziału Mechanicznego Energetyki i Lotnictwa Politech-

niki Warszawskiej (MEiL). Próba samodzielnego wykonania modelu manipulatora w popular-

nym środowisku graficznym mijała się z celem, ponieważ istniał już gotowy model stworzony

przez samego konstruktora. Problemem okazał się za to fakt, że otrzymany model był w for-

macie programu Unigraphics NX5. Jest to zaawansowane środowisko typu CAD1 pozwalające

na projektowanie obiektów bryłowo lub powierzchniowo. Model robota Polycrank składał się w

tym programie, z widocznych po lewej stronie na rysunku 3.1, bardzo wielu grup elementów.

Poszczególne grupy odpowiadały zarówno elementom budowy zewnętrznej oraz wewnętrznej

robota i znajdowały się one w ponad 340 różnych plikach o rozszerzeniu *.prt. Problem nie-

wygodnego do dalszej pracy formatu rozwiązałem wykorzystując możliwości konwersji pro-

gramu Unigraphics NX5. Dzięki uprzejmości Jarosława Jankowskiego, studenta z wydziału

MEiL, przekonwertowałem otrzymany model manipulatora do popularnego formatu *.wrl.

Ten format plików 3D jest silnie wspierany przez praktycznie wszystkie popularne programy

graficzne. Co jest warte podkreślenia, środowisko Unigraphics NX5 nie umożliwia konwersji do

popularnego formatu .3ds programu 3dsMax, wspiera za to wszystkie formaty CAD.

3.2 Deep Exploration 5

Otrzymany model zawierał także wszystkie mechanizmy wewnętrzne, takie jak opisywane

w rozdziale 2 mechanizmy przenoszenia napędu, układy równoległowodów i przekładni. Obec-

ność tych elementów powodowała, że model był redundantny i miał bardzo skomplikowaną1ang. Computer Aided Design

16

3.2. DEEP EXPLORATION 5

Rysunek 3.1: Model robota Polycrank w programie Unigraphics NX5.

siatkę, co jest widoczne na rysunku 3.2 w lewej kolumnie. Nie powinno to jednak dziwić, jeżeli

rozmiar pliku *.wrl z modelem 3D po konwersji opisanej w podrozdziale 3.1 wynosił 7MB.

Przetwarzanie tak dużej liczby wierzchołków siatki modelu tylko niepotrzebnie zwiększałoby

czas renderingu w wizualizacji. Niezbędna była zatem optymalizacja modelu.

W ramach optymalizacji usunąłem:

• wszystkie mechanizmy wewnętrzne,

• redundantne elementy podstawy,

• chwytak dwupalczasty, gdyż w trakcie dalszych prac miałem korzystać z chwytaka trój-

palczastego.

Efekt tych zabiegów optymalizacyjnych widoczny jest na rysunku 3.2. Na rysunku 3.2 do-

skonale widać jak zdecydowanie uprościł się model 3D robota i jego siatka. Co jest warte

podkreślenia, rozmiar pliku z modelem po optymalizacji zmniejszył się do 251 KB.

Nieocenioną rolę przy usuwaniu elementów z modelu odegrał program Deep Exploration 5.

Przypisuje on każdemu elementowi modelu identyfikator. Usunięcie wybranego nadmiarowego

elementu ograniczało się jedynie do odznaczenia obiektu z listy drzewa sceny (ang. Scene

Tree), co widać na rysunku 3.3. Po odznaczenia wszystkich nadmiarowych elementów należy

zapisać plik z uproszczonym modelem, aby zachować wprowadzone zmiany. Program ma za-

implementowane także własne funkcje optymalizacji siatki obiektu i liczby wierzchołków, z

których korzystałem po usunięciu wszystkich nadmiarowych elementów.

17

3.2. DEEP EXPLORATION 5

Rysunek 3.2: Redundantny model i jego skomplikowana siatka w kolumnie po lewej. Zopty-

malizowany model i jego uproszczona siatka w kolumnie po prawej. Zrzuty ekranowe modelu

robota Polycrank pochodzą z programu Deep Exploration 5.

Deep Exploration 5 jest to najnowsza i rozbudowana wersja programu 3D Exploration, z któ-

rego korzystałem w pracy inżynierskiej [5]. Program dostępny jest pod adresem [8], a legalne

użytkowanie wymaga rejestracji na stronie producenta. Po rejestracji na adres mail zostaje

wysłana licencja. Program działa tylko na platformie Windows i wymaga do uruchomienia

karty graficznej obsługującej sprzętowo standard OpenGL. Deep Exploration 5 został napi-

sany w C++ i charakteryzuje się dużą szybkością działania. Posiada on intuicyjny interfejs

przypominający swym wyglądem Windows Explorer. Program umożliwia przeglądanie naj-

popularniejszych formatów plików graficznych 3D: 3DS MAX, LightWave, Caligari, DirectX,

AutoCAD, Open Inventor. Drugą, może nawet ważniejszą funkcją programu jest możliwość

konwertowania między różnymi formatami plików graficznych. Przy pomocy Deep Explora-

tion 5 można dokonywać skalowania, obrotów, translacja czy zmiany kolorów materiałów wy-

18

3.3. 3DS MAX

Rysunek 3.3: Zaznaczanie redundantnego elementu celem usunięcia z modelu robota Polycrank

w programie Deep Exploration 5.

korzystanych w modelu. Okna programu pozwalające na tego typu operacje przedstawione są

na zrzutach ekranowych 3.4.

Przedstawione powyżej możliwości oferuje także darmowy program MeshLab. Szczegółowy

opis tego programu znajduje się pod adresem [2].

3.3 3ds Max

Opisane w poprzednim podrozdziale 3.2 zabiegi pozwoliły uzyskać zoptymalizowany model

robota. Siłą rzeczy pociągnęło to za sobą niewielkie, lecz zauważalne, szczególnie na dużych

powiększeniach deformacje siatki. Podstawy niektórych członów zamiast okrągłego nabrały

elipsoidalnego kształtu, a niektóre elementy zatraciły swoją symetryczność. Wpłynęłoby to

niekorzystnie na jakość wizualizacji robota Polycrank. Także nie udałoby się prawidłowo od-

wzorować kinematyki manipulatora, jeżeli postawy członów nabrały elipsoidalnego kształtu.

Nieunikniona stała się zatem poprawa geometrii modelu, którą skutecznie wykonałem przy

pomocy popularnego programu 3dsMax, widocznego na rysunku 3.5. Jest to bardzo zaawanso-

wany program do tworzenia i edycji trójwymiarowej grafiki, działającym na platformie Win-

19

3.3. 3DS MAX

Rysunek 3.4: Możliwości programu Deep Exploration 5. A-Proste operacje na obiektach: 1-

Skalowanie, 2-Obrót, 3-Translacja. B-Zmiana koloru materiału obiektu.

dows. 3dsMax posiada bardzo intuicyjny i rozbudowany interfejs użytkownika, predefiniowane

widoki na scenę 3D (domyślnie cztery: TOP, FRONT, LEFT i PERSPECTIVE ), których

obecność pozwala na dokładny ogląd geometrii modelu.

Aby móc później w wizualizacji odwzorować kinematykę robota należało podzielić kompu-

terowy model manipulatora na ogniwa. Na rysunku 3.6 znajduje się przykładowe ogniwo kine-

matyczne wydzielone z modelu robota Polycrank, widocznego na rysunku 3.5. Jest to czwarty

człon manipulatora będący pierwszym z dwóch sprzężonych ogniw. W podobny sposób zo-

stały wydzielone z modelu pozostałe ogniwa i zapisane w oddzielnych plikach o rozszerzeniach

*.3DS, co widać na rysunku 3.7. W wyniku czego zostały stworzone pliki zawierające ogniwa

robota, które będzie można wykorzystać w celu wizualizacji pracy manipulatora Polycrank.

Alternatywnym programem do poprawy geometrii modelu, który w ostatnich latach cieszy

się coraz większą popularnością, jest Blender. Ma on zdecydowanie mniejsze wymagania jeżeli

chodzi o zasoby sprzętowe, jest bezpłatny (opłaty były jedynie pobierane za pomoc techniczną)

i dostępny na różne platformy systemowe w odróżnieniu od 3dsMax. Mimo to nie osiągnął,

aż tak dużego sukcesu komercyjnego jak przypuszczano. Obecnie jest jednak coraz częściej

wykorzystywanym narzędziem do produkcji m.in. reklam telewizyjnych.

20

3.3. 3DS MAX

Rysunek 3.5: Model robota Polycrank w programie 3dsMax.

Rysunek 3.6: Przykład wydzielonego ogniwa z modelu robota Polycrank w programie 3dsMax.

21

3.4. FORMAT OPEN INVENTOR

Rysunek 3.7: Ogniwa robota Polycrank w formacie 3dsMax.

3.4 Format Open Inventor

Początkowa nazwa formatu Open Inventor to IRIS Inventor. Format został napisany w

C++ do tworzenia zoptymalizowanych modeli 3D. Główny nacisk położono na efektywność i

wygodę tworzenia obiektów. Aby przybliżyć składnię formatu przedstawiłem poniżej 3 przy-

kładowe bryły (sześcian, kula, walec) i ich pliki konfiguracyjne:

• Sześcian

Rysunek 3.8: Sześcian w formacie Open Inventor.

1 #Inventor V2.1 ascii

Separator {

Transform { translation 0 0 0 }

Cube { width 60 height 60 depth 60}

5 }

Wydruk 3.1: Plik konfiguracyjny sześcianu widocznego na rysunku 3.8 w formacie Open In-

ventor.

• Kula

22


Rysunek 3.9: Kula w formacie Open Inventor.


Separator { # Body

Transform { translation 0 0 0 }

Material{ # A bronze color:

5 ambientColor .33 .22 .27

diffuseColor .78 .57 .11

specularColor .99 .94 .81

shininess .28

transparency .6

10 }

Sphere { radius 8 }

}

}

Wydruk 3.2: Plik konfiguracyjny kuli widocznej na rysunku 3.9 w formacie Open Inventor.

• Walec


Separator { # Body

Material {

ambientColor 0.4 0.4 0.8

5 diffuseColor 0.4 0.4 0.8

}

Cylinder { radius 22 height 180 }

}

Wydruk 3.3: Plik konfiguracyjny walca widocznego na rysunku 3.10 w formacie Open Inventor.

23


Rysunek 3.10: Walec w formacie Open Inventor.

Na podstawie powyższych przykładów widać, że składnia formatu nie jest skomplikowana.

Wykorzystując ten format można w prosty i szybki sposób odwzorować proste obiekty two-

rzące środowisko pracy robota. Open Inventor umożliwia dostęp do podstawowych operacji

na obiektach takich jak przesunięcie, obrót czy skalowanie. Szczegółowy opis formatu Open

Inventor można znaleźć na stronie [20].

Budowa bardziej złożonych obiektów, wymaga jednak wykorzystania rozbudowanych pro-

gramów do edycji grafiki 3D, dających dostęp do zaawansowanych przekształceń. Dlatego,

aby uzyskać modele ogniw manipulatora Polycrank w formacie Open Inventor należało :

1. wykorzystać modele ogniw w formacie *.3DS widoczne na rysunku 3.7 i opisane w

poprzednim podrozdziale 3.3,

2. wykonać niezbędne transformacje (obrót, przesunięcie, skalowanie) przy pomocy pro-

gramu 3dsMax lub Deep Exploration 5,

3. przekonwertować modele ogniw do formatu Open Inventor wykorzystując program Deep

Exploration 5 lub IVCON dostępny pod adresem [1],

4. (opcjonalnie) dodać dodatkowe parametry opisujące ogniwo np. materiał i masę, tak jak

na przykładowym wydruku 3.4.


#material metal

#mass 100

Wydruk 3.4: Dodatkowe parametry umieszczane na początku pliku konfiguracyjnego *.iv

ogniwa.

Program 3dsMax niestety nie oferuje możliwości konwersji do formatu Open Inventor. Naj-

wygodniej konwertować modele ogniw przy pomocy środowiska Deep Exploration 5. Przy okazji

24


konwersji program umożliwia zmianę kolorów materiałów, jak widać na rysunku 3.11 przed-

stawiającym uzyskane ogniwa manipulatora Polycrank w formacie Open Inventor. W celu kon-

wersji do formatu *.iv można także wykorzystać, uruchamiany z wiersza poleceń programu

IVCON. Jednak program ten jest zdecydowanie mniej intuicyjny w obsłudze niż Deep Explo-

ration 5.

Rysunek 3.11: Ogniwa robota Polycrank w formacie Open Inventor.

25

Rozdział 4

Graspit

W swojej pracy inżynierskiej[5] zaprojektowałem i zaimplementowałem aplikację Zbik3D

pełniącą rolę wizualizacji pracy dwóch robotów Irp-6 (Track - manipulator na torze jezd-

nym, Postument - robot wolnostojący). W ramach mojej pracy magisterskiej wzbogaciłem to

graficzne środowisko o wizualizację robota Polycrank. Przykładowy zrzut ekranowy aplikacji

Zbik3D z robotem Polycrank przedstawia rysunek 4.1. Umożliwiło mi to poznanie kinematyki

prostej tego robota i poznanie pierwszych problemów związanych z jego symulacją.

Rysunek 4.1: Aplikacja Zbik3D z wizualizacją robota Polycrank.

W trakcie dalszych prac postanowiłem jednak wykorzystać do wizualizacji robota Poly-

crank symulator planowania i realizacji chwytów GraspIt. Taka decyzja wynikała, z faktu, że

26

4.1. OPIS TECHNICZNY

program był darmowym narzędziem, w którym zostały rozwiązane takie problemy jak:

• planowanie i realizacja chwytów,

• wykrywanie kolizji,

• realizacja kinematyki prostej i odwrotnej,

• uwzględnienie sił grawitacji i tarcia.

Dodatkowo, GraspIt zawiera gotowe chwytaki, przeszkody, obiekty, które można wykorzy-

stać przy tworzeniu środowiska pracy manipulatora. Implementacja tego wszystkiego w apli-

kacji Zbik3D nie miałaby większego sensu, gdy istnieje już odpowiednie narzędzie jakim jest

symulator GraspIt. Dlatego też w myśl zasady, że „nie należy próbować wywarzać otwartych

drzwi” wykorzystałem ten program do symulacji pracy robota Polycrank.

4.1 Opis techniczny

Symulator GraspIt został napisany na Uniwersytecie Columbia w Nowym Jorku. Głów-

nym autorem programu jest Andrew T. Miller, który umieścił szczegółowy opis możliwości

symulatora w pracy [14]. Program jest darmowy i można go uruchomić zarówno na platformie

Windows jak i Linux. Sposób instalacji w zależności od platformy został szczegółowo opisany

na stronie programu, znajdującej się pod adresem [15].

Możliwości instalacji najnowszej wersji programu GraspIt (2.1.0) sprawdzałem na platfor-

mie Windows (Windows XP oraz Windows 7) oraz dystrybucji Debian 5.05 (Lenny) oraz

Ubuntu 10.10 (Lucid Lynx), zarówno w wersjach 32-bitowych jak i 64-bitowych. Sam proces

instalacji przebiegał bez większych problemów. Instalacja jest jednak czasochłonna i wymaga

konfiguracji w systemie operacyjnym najnowszych, stabilnych wersji następujących bibliotek:

• Qt, minimalnie wersja 4.0, a najlepiej 4.7 - zestaw przenośnych bibliotek języka C++,

których podstawą są klasy służące do budowy graficznego interfejsu programów kom-

puterowych. Technologia została szerzej opisana w rozdziale 5,

• Coin3d, wersja 3.1.3 - biblioteka C++ do tworzenia aplikacji graficznych 3D oparta

na standardzie OpenGL 1. Jest ona w pełni kompatybilna z formatem plików grafiki

trójwymiarowej Open Inventor (*.iv), który został opisany w podrozdziale 3.4,

• SoQt, wersja 1.5.0 - biblioteka do integracji bibliotek Coin3d i Qt,

• wybranej implementacji Lapack 2, wersja 3.3.0 - bardzo wydajna biblioteka do obliczeń

numerycznych, szczególnie operacji macierzowych:

– Intel MKL 3, wersja 10.3,

– CLapack, wersja 3.2.1.1ang. Open Graphics Library2ang. Linear Algebra PACKage3ang. Math Kernel Library

27

4.2. OPIS GŁÓWNYCH FUNKCJI

4.2 Opis głównych funkcji

GraspIt jest rozbudowanym symulatorem planowania i realizacji chwytów. Główne funkcje

programu zostały zaznaczone na rysunku 4.2.

Rysunek 4.2: Główne funkcje programu GraspIt.

1. translacja obiektu lub zmiana wartości stopnia swobody,

2. obrót obiektu lub zmiana wartości stopnia swobody,

3. możliwość wyboru wielu obiektów w scenie przy wciśniętym przycisku Shift,

4. włączenie lub wyłączenie wykrywania kolizji dla zaznaczonych obiektów (domyślnie efekt

odnosi się do wszystkich obiektów w scenie),

5. tryb interaktywny pozwalający na manipulowanie obiektami (translacje, obroty, zmiana

położenia i orientacji) wirtualnego świata 3D,

6. tryb pozwalający na manipulowanie kamerą (translacja, obrót, powiększenie),

7. ustawienie kamery w zapamiętanym położeniu,

8. zapamiętanie pozycji kamery,

9. ustawienie kamery tak, aby wszystkie obiekty sceny mieściły się na ekranie,

28

4.3. KINEMATYKA PROSTA ROBOTA

10. tryb pozwalający na wycentrowanie kamery na zaznaczony wcześniej obiekt i zbliżenie

w tym kierunku,

11. przełączanie między widokiem perspektywicznym a równoległym,

12. możliwość zbliżania/oddalania kamery,

13. możliwość obrotu względem osi Y,

14. możliwość obrotu względem osi X.

Program GraspIt pozwala symulować chwyty obiektów przy użyciu dostępnych już modeli

rąk (np. ręka DLR widoczna na rysunku 4.2). Można oczywiście dodawać własne modele rąk

i obiektów. Symulator oferuje pomiar jakości uzyskanych chwytów z uwzględnieniem różnych

kryteriów. Dodawać można także obiekty będące przeszkodami, które ograniczają przestrzeń

roboczą manipulatora. Jest to przydatne np. w eksperymentach z wykorzystaniem stołu.

4.3 Kinematyka prosta robota

Proste zadanie kinematyki polega na określeniu położenia i orientacji końcówki roboczej

(narzędzia) względem bazowego układu odniesienia podstawy dla zadanych zmiennych prze-

gubowych. Zadanie kinematyki prostej nazywane jest także w literaturze kinematyką konfigu-

racji, a zmienne przegubowe nazywane są zmiennymi konfiguracyjnymi. Każdy przegub można

opisać jedną liczbą rzeczywistą. W przypadku członu obrotowego będzie to kąt obrotowy, a

w przypadku członu translacyjnego przemieszczenie.

4.3.1 Notacja Denavita-Hartenberga DH

Aby móc opisać kinematykę manipulatora niezbędna jest jednoznaczna notacja. Sto-

sowanym w robotyce opisem ogniwa (człon, ramię) manipulatora są parametry Denavita-

Hartenberga. Przyporządkowują one każdemu ogniwu cztery parametry:

ai - długość ogniwa,

αi - skręcenie ogniwa,

di - odsunięcie przegubu,

θi - kąt przegubu.

Pierwsze dwie wielkości opisują ogniwo, pozostałe dwie przegub. Dokładny opis notacji znaj-

duje się w pracy [9].

4.3.2 Zmodyfikowana Notacja Denavita-Harteberga ZDH

W literaturze najczęściej stosowana jest Zmodyfikowana notacja Denavita-Hartenberga

ZDH, nazywana czasami notacją Khalila-Kleinfingera. Przyporządkowuje one każdemu

ogniwu cztery parametry [25] :

ai−1 - długość ogniwa,

αi−1 - skręcenie ogniwa,

29

4.4. PLIK KONFIGURACYJNY

di - odsunięcie przegubu,

θi - kąt przegubu.

Pierwsze dwie wielkości opisują ogniwo, pozostałe dwie połączenie z sąsiednim członem.

W notacji DH oś zi położona jest wzdłuż przegubu i+1. W notacji ZDH oś zi położona

jest wzdłuż osi przegubu i. Dlatego do opisu ogniwa i notacja DH wykorzystuje parametry

(związane z przegubem i) : ai, αi, di, θi. Notacja ZDH wykorzystuje natomiast parametry

(związane z przegubem i-1 ): ai−1, αi−1, di, θi, co jest bardziej intuicyjne. Jako pierwsza

została wprowadzana notacja DH, lecz obecnie częściej stosowana jest notacja ZDH. Szerzej

możliwe podejścia w rozwiązaniu problemu kinematyki prostej zostały opisane w pracy [23].

4.3.3 Parametry Denavita-Harteberga w Graspit

Program GraspIt ma zaimplementowaną własną notację bazującą na parametrach Denavita-

Hartenberga. Parametry te pełnią kluczową rolę przy tworzeniu pliku konfiguracyjnego mani-

pulatora w GraspIt i dlatego zostały opisane w następnym podrozdziale 4.4.

4.4 Plik konfiguracyjny

Budowa modelu robota Polycrank w programie GraspIt wymagała stworzenia pliku konfi-

guracyjnego robota *.cfg widocznego na wydruku 4.1. Główne elementy tego pliku to :

1. parametry Denavita-Hartenberga opisujące kinematykę prostą manipulatora,

2. odnośniki (ścieżki) do plików graficznych *.iv poszczególnych ogniw w formacie Open

Inventor. Sposób tworzenia plików *.iv odpowiadających ogniwom robota został opisany

w podrozdziale 3.4.

Znaczenie pozostałych parametrów zostało szczegółowo wyjaśnione poprzez obszerne ko-

mentarze wewnątrz pliku pliku konfiguracyjnego robota widocznego na wydruku 4.1.

1 #Nazwa klasy modelu

#Robot - robot z jednym łańcuchem kinematycznym lub

#Hand - ręka z więcej niż jednym łańcuchem kinematycznym lub

#zaimplementowane własne klasy

5 Robot

#Opis bazy

#nazwa_pliku ostatnie_ogniwo

#jeżeli żadne ogniwo nie wpływa na podstawę ostatnie ogniwo to -1

10 palm.iv -1

#Liczba stopni swobody

6

15 #Dla każdego stopnia swobody podawana jest 1 linia opisu

#Rodzaj stopnia swobody (r-zwykły , c-sprzężony)

30


#Domyślna prędkość (0- pomijanie wartości ,

#1-funkcja automatycznego chwytu będzie uwzględniać wartość)

#Maksymalna siła (nie wykorzystywane w pracy)

20 #Praca (nie wykorzystywane w pracy)

#Przesunięcie (nie wykorzystywane w pracy)

#Promień okręgu umożliwiającego interakcję ze stopniem swobody

r 1.0 1.0e+10 1.0e+12 1.0e+7 140.0

r 1.0 1.0e+10 1.0e+12 1.0e+7 140.0

25 r 1.0 1.0e+10 1.0e+12 1.0e+7 110.0

r 1.0 1.0e+10 1.0e+10 1.0e+7 80.0

r 1.0 1.0e+10 1.0e+10 1.0e+7 80.0

r 1.0 1.0e+10 1.0e+10 1.0e+7 55.0

30 #Liczba łańcuchów kinematycznych

1

#Początek opisu łańcucha kinematycznego numer 0

#Liczba ogniw w łańcuchu kinematycznym

35 7

#Liczba przegubów w łańcuchu kinematycznym

7

40 #Transformacje od układu współrzędnych bazy

#do układu współrzędnych początku łańcucha kinematycznego

#Przykład

#r 90 x (obrót o 90 stopni wokół osi x)

#rr 3.0368729 y (obrót o 3.0368729 radianów wokół osi y)

45 #t 1.92188 134.5 39.0717

#( translacja o 1.92188 134.5 39.0717 w mm)

t 0 0 0

#Opis przegubów (1 przegub w 1 linii)

50 #theta d a alpha DOFminval DOFmaxval

#( przeguby są w kolejności od najbliższego kiści do najdalszego)

#( równania liniowe mają postać q#*k+c [bez spacji !])

d0 220 0 0 -36000 36000

d1 152 180 0 -36000 36000

55 d2 335 0 90 -36000 36000

d3 120 151 0 -36000 36000

d3*-1 116 151 0 -36000 36000

d4 60 0 90 -36000 36000

d5 43 0 0 -36000 36000

60

#Opis ogniw (1 ogniwo w 1 linii)


31


#typy połączeń

#Revolute–ogniwo jest połączone z poprzednim poprzez jeden przegub ,

65 #Universal–ogniwo jest połączone z poprzednim poprzez dwa przeguby ,

#zazwyczaj z o prostopadłych osiach

#Ball–ogniwo jest połączone z poprzednim poprzez trzy przeguby ,


#( ogniwa są w kolejności od najbliższego bazy do najdalszego)

70 #( ostatnie_ogniwo jest to numer ostatniego ogniwa , które może

#mieć wpływ na przegub w tej samej linii)

Revolute

link1.iv 0

Revolute

75 link2.iv 1

Revolute

link3.iv 2

Revolute

link4.iv 3

80 Revolute

link5.iv 4

Revolute

link6.iv 5

Revolute

85 link7.iv 6

#Koniec opisu łańcucha kinematycznego numer 0

Wydruk 4.1: Plik konfiguracyjny robota Polycrank w programie GraspIt zawierający parametry

Denavita-Hartenberga do opis kinematyki prostej.

Jak widać kluczowymi parametrami w budowie modelu manipulatora w GraspIt są para-

metry Denavita-Hartenberga. Podczas symulacji rozwiązanie prostego zadania kinematyki dla

robota jest automatycznie wyliczane przez program GraspIt na podstawie tabeli tych para-

metrów. W tabeli 4.1 przedstawiono parametry Denavita-Hartenberga dla robota Polycrank w

notacji stosowanej w GraspIt, a tabeli 4.2 w najczęściej stosowanej notacji ZDH. Zmienne d0,

d1, d2, d3, d4, d5, d6 oznaczają kolejne zmienne przegubowe licząc od chwytaka. W notacji

stosowanej w GraspIt wpisywane są w kolumnie θ dla stopni swobody. Jak widać w tabeli 4.1

przeguby czwarty i piąty są ze sobą sprzężone. Dlatego odpowiadające im zmienne przegu-

bowe mają wartość d3 oraz d3*-1. W notacji zaimplementowanej w GraspIt d3*-1 oznacza

-d3. Podane w tabeli 4.1 długości wyrażane są mm. θmin i θmax oznaczają minimalne i

maksymalne dopuszczalne wartości kolejnych zmiennych przegubowych. Uwzględniając fakt,

że Polycrank posiada teoretycznie nieograniczone zakresu ruchu w przegubach podałem jako

ograniczenia skrajnie bardzo duże wartości ( -36000 i 36000 ). Te ograniczenia na wartości

zmiennych przegubowych wydają się wystarczające trudne do przekroczenia podczas symu-

lacji. W związku z tym zadane wartości zmiennych przegubowych mogą nie zostać osiągnięte

jedynie jeżeli miałoby to powodować kolizje z innymi obiektami. Trzeba wiedzieć, że w symu-

32


latorze domyślnie włączone jest wykrywanie kolizji.

θ d a α θmin θmax

d0 220 0 0 -36000 36000

d1 152 180 0 -36000 36000

d2 335 0 90 -36000 36000

d3 120 151 0 -36000 36000

d3*-1 116 151 0 -36000 36000

d4 60 0 90 -36000 36000

d5 43 0 0 -36000 36000

Tablica 4.1: Parametry Denavita-Hartenberga manipulatora Polycrank w notacji stosowanej w

programie GraspIt.

αi−1 ai−1 di θi

0 0 220 θ1

0 0 152 θ2

0 180 335 θ3

90 0 120 θ4

0 151 116 −θ40 151 60 θ5

90 0 43 θ6

Tablica 4.2: Kinematyka prosta manipulatora Polycrank w notacji ZDH.

33

4.5. MODEL 3D

4.5 Model 3D

Model robota Polycrank zbudowany na podstawie pliku konfiguracyjnego, opisanego w

podrozdziale 4.4, widoczny jest na rysunku 4.4. Aby wczytać plik konfiguracyjny robota do

programu GraspIt należy z menu File widocznego na rysunku 4.3 wybrać opcję Import Robot,

a następnie wskazać ścieżkę do pliku.

Rysunek 4.3: Menu File programu GraspIt pozwalające na: 1-wczytanie pliku konfiguracyjnego

robota (*.cfg), 2-wczytanie pliku konfiguracyjnego obiektu (*.iv), 3-wczytanie plik konfigura-

cyjnego przeszkody (*.iv).

W GraspIt wokół osi obrotu rysowane są okręgi wykorzystywane do interakcji z symulo-

wanym robotem. Za pomocą myszy można je obracać ustawiając żądaną wartość zmiennej

konfiguracyjnej. Dla ostatnich dwóch przegubów nie są narysowane okręgi, ale za to występują

na członie 5 robota czyli na ogniwie sprzężonym biernym. Przesunięcie to jest konsekwencją

tego, że twórcy nie uwzględnili w implementacji możliwości występowania biernego stopnia

swobody w łańcuchu kinematycznym. Jest to jednak tylko błąd wizualny polegający na tym, że

dwa ostatnie okręgi znajdują się w złym miejscu na modelu. Model robota Polycrank widoczny

na rysunku 4.4 działa w pełni prawidłowo. Podobny problem pojawił się w pracy [10], gdzie

w modelu chwytaka trójpalczastego okrąg O2 widoczny na zdjęciu 4.5 zamiast na ostatnim

występuje na przedostatnim przegubie.

Co ciekawe, inny model robota Polycrank widoczny na rysunku 4.6 wizualnie wygląda

prawidłowo. Okręgi znajdują się na właściwych miejscach. Jest to jednak tylko efekt wizualny

powstały w wyniku nieuwzględniania sprzężenia członów 4 i 5. Model wizualnie wygląda

poprawnie, jednak nie działa prawidłowo.

34

4.5. MODEL 3D

Rysunek 4.4: Model robota Polycrank w programie GraspIt. Człony 4 i 5 są ze sobą sprzężone.

Robot ma 6 stopni swobody.

Rysunek 4.5: Model chwytaka trójpalczastego autorstwa K. Czajkowskiego [10] w programie

GraspIt. Człony 1 i 2 są ze sobą sprzężone. Okrąg O2 zamiast na ostatnim występuje na

przedostatnim przegubie.

35

4.5. MODEL 3D

Rysunek 4.6: Model robota Polycrank bez uwzględniania sprzężenia członów 4 i 5 w programie

GraspIt. Robot ma 7 stopni swobody.

36

4.5. MODEL 3D

Pliku konfiguracyjny robota Polycrank bez uwzględniania sprzężenia członów 4 i 5 znajduje

się na wydruku 4.2.

1 #Nazwa klasy modelu

#Robot - robot z jednym łańcuchem kinematycznym lub

#Hand - ręka z więcej niż jednym łańcuchem kinematycznym lub

#zaimplementowane własne klasy

5 Robot

#Opis bazy


#jeżeli żadne ogniwo nie wpływa na podstawę ostatnie ogniwo to -1

10 palm.iv -1

#Liczba stopni swobody

6

15 #Dla każdego stopnia swobody podawana jest 1 linia opisu

#Rodzaj stopnia swobody (r-zwykły , c-sprzężony)

#Domyślna prędkość (0- pomijanie wartości ,

#1-funkcja automatycznego chwytu będzie uwzględniać wartość)

#Maksymalna siła (nie wykorzystywane w pracy)

20 #Praca (nie wykorzystywane w pracy)

#Przesunięcie (nie wykorzystywane w pracy)

#Promień okręgu umożliwiającego interakcję ze stopniem swobody

r 1.0 1.0e+10 1.0e+12 1.0e+7 140.0

r 1.0 1.0e+10 1.0e+12 1.0e+7 140.0

25 r 1.0 1.0e+10 1.0e+12 1.0e+7 110.0

r 1.0 1.0e+10 1.0e+10 1.0e+7 80.0

r 1.0 1.0e+10 1.0e+10 1.0e+7 80.0

r 1.0 1.0e+10 1.0e+10 1.0e+7 55.0

r 1.0 1.0e+10 1.0e+10 1.0e+7 45.0

30

#Liczba łańcuchów kinematycznych

1

#Początek opisu łańcucha kinematycznego numer 0

35 #Liczba ogniw w łańcuchu kinematycznym

7

#Liczba przegubów w łańcuchu kinematycznym

7

40

#Transformacje od układu współrzędnych bazy

#do układu współrzędnych początku łańcucha kinematycznego

#Przykład

37

4.5. MODEL 3D

#r 90 x (obrót o 90 stopni wokół osi x)

45 #rr 3.0368729 y (obrót o 3.0368729 radianów wokół osi y)

#t 1.92188 134.5 39.0717

#( translacja o 1.92188 134.5 39.0717 w mm)

t 0 0 0

50 #Opis przegubów (1 przegub w 1 linii)

#theta d a alpha DOFminval DOFmaxval

#( przeguby są w kolejności od najbliższego kiści do najdalszego)

#( równania liniowe mają postać q#*k+c [bez spacji !])

d0 220 0 0 -36000 36000

55 d1 152 180 0 -36000 36000

d2 335 0 90 -36000 36000

d3 120 151 0 -36000 36000

d4 116 151 0 -36000 36000

d5 60 0 90 -36000 36000

60 d6 43 0 0 -36000 36000

#Opis ogniw (1 ogniwo w 1 linii)


#typy połączeń

65 #Revolute–ogniwo jest połączone z poprzednim poprzez jeden przegub ,

#Universal–ogniwo jest połączone z poprzednim poprzez dwa przeguby ,


#Ball–ogniwo jest połączone z poprzednim poprzez trzy przeguby ,


70 #( ogniwa są w kolejności od najbliższego bazy do najdalszego)

#( ostatnie_ogniwo jest to numer ostatniego ogniwa , które może

#mieć wpływ na przegub w tej samej linii)

Revolute

link1.iv 0

75 Revolute

link2.iv 1

Revolute

link3.iv 2

Revolute

80 link4.iv 3

Revolute

link5.iv 4

Revolute

link6.iv 5

85 Revolute

link7.iv 6

#Koniec opisu łańcucha kinematycznego numer 0

#dla manipulatora szeregowego

38

4.6. KINEMATYKA ODWROTNA

Wydruk 4.2: Plik konfiguracyjny robota Polycrank (bez uwzględniania sprzężenia członów 4

i 5) w programie GraspIt zawierający parametry Denavita-Hartenberga do opisu kinematyki

prostej.

θ d a α θmin θmax

d0 220 0 0 -36000 36000

d1 152 180 0 -36000 36000

d2 335 0 90 -36000 36000

d3 120 151 0 -36000 36000

d4 116 151 0 -36000 36000

d5 60 0 90 -36000 36000

d6 43 0 0 -36000 36000

Tablica 4.3: Parametry Denavita-Hartenberga manipulatora Polycrank (bez uwzględniania

sprzężenia członów 4 i 5) w notacji stosowanej w programie GraspIt.

αi−1 ai−1 di θi

0 0 220 θ1

0 0 152 θ2

0 180 335 θ3

90 0 120 θ4

0 151 116 θ5

0 151 60 θ6

90 0 43 θ7

Tablica 4.4: Kinematyka prosta manipulatora Polycrank bez uwzględniania sprzężenia członów

4 i 5 w notacji ZDH.

4.6 Kinematyka odwrotna

Odwrotne zadanie kinematyki polega na wyznaczeniu wszystkich możliwych zbiorów war-

tości współrzędnych konfiguracyjnych w połączeniach ruchowych, które umożliwią manipula-

torowi osiągnięcie zadanego położenia lub orientacji końcówki roboczej (narzędzia). Jest to

fundamentalne zadanie w robotyce, gdyż pozwala określić jak poszczególne współrzędne kon-

figuracyjne powinny zmieniać się w celu realizacji pożądanego ruchu końcówki. Innymi słowy

mając dane położenie i orientację należy obliczyć wszystkie możliwe zbiory współrzędnych

konfiguracyjnych tak, aby osiągnąć pożądane położenie i orientację. Jak łatwo zauważyć jest

to zadanie trudniejsze od prostego zadania kinematyki ze względu na wielokrotność rozwią-

zań i ich silną nieliniowość. Może istnieć wiele rozwiązań dla danego położenia i orientacji.

W szczególnych przypadkach (w punktach osobliwych) może być ich nieskończenie wiele.

39

4.7. SCENY 3D

Dla określonej struktury kinematycznej rozwiązanie może w ogóle nie istnieć. Aby istniało

rozwiązanie odwrotnego zadania kinematyki zadany punkt docelowy dla końcówki musi prze-

cież należeć do przestrzeni roboczej. Silnia nieliniowość uniemożliwia najczęściej znalezienie

rozwiązań w postaci rozwikłanej. Trzeba też pamiętać, że nie ma uniwersalnych metod roz-

wiązywania układów równań nieliniowych.

Problem ten został rozwiązany w programie GraspIt numerycznie, dlatego uzyskiwane roz-

wiązania są obliczane wolniej i mniej niezawodnie niż w systemie MRROC++, gdzie dla ro-

bota Irp-6 zostało to rozwiązane w sposób analityczny. Nie mniej jednak metody iteracyjne

z reguły są prostsze w implementacji i stanowią alternatywę dla metod analitycznych. Je-

żeli poszukiwane rozwiązanie wymaga większej niż określona w programie stała maksymalna

ilość iteracji (safeGuardUpperBound) obliczenia są przerywane i pojawia się komunikat

(safeguard hit). Dobrze ilustruje to poniższy fragment kodu 4.3.

1 // m a k s y m a l n a ilość iteracji

safeGuardUpperBound = 200;

// wykonana ilość iteracji

i n t safeguard = 0;

5

whi le (++ safeguard < safeGuardUpperBound)

{

... // o b l i c z e n i a n u m e r y c z n e

++ safeguard;

10 }

i f (safeguard >= safeGuardUpperBound)

{

std::cout << "safeguard␣hit\n";

15 return FAILURE;

}

Wydruk 4.3: Fragment funkcji invKinematics z pliku robot.cpp programu GraspIt ilustrujący

iteracyjną metodę obliczenia kinematyki odwrotnej

Zaimplementowana w symulatorze kinematyka odwrotna uwzględnia ograniczenia nało-

żone na zmienne przegubowe tak, aby rozwiązanie zawierało się w przestrzeni roboczej mani-

pulatora. Zmiana położenia i orientacji końcówki robota Polycrank możliwa jest w symulatorze

GraspIt za pomocą kursora myszy, co widać na rysunku 4.7.

4.7 Sceny 3D

W GraspIt można tworzyć sceny 3D, do których oprócz robotów i chwytaków można do-

dawać obiekty (Import Object) lub przeszkody (Import Obstacle) z Menu File widocznego na

rysunku 4.3. Pozwala to na wierne odwzorowanie środowiska pracy manipulatora i urealnia

przeprowadzane eksperymenty w tym środowisku symulacyjnym.

40

4.7. SCENY 3D

Rysunek 4.7: GraspIt: A - Zmiana położenia końcówki robota Polycrank za pomocą kursora

myszy, B - Zmiana orientacji końcówki robota Polycrank za pomocą kursora myszy.

Rysunek 4.8 przedstawia przykład prostej sceny 3D, w której umieszczony został robot

Polycrank z chwytakiem trójpalczastym autorstwa K. Czajkowskiego [10].

Na rysunku 4.9 widoczny jest robot Polycrank z chwytakiem dwupalczastym autorstwa

K. Czajkowskiego [11]. Manipulator został umieszczony na sześciennej podstawie. Dzięki wy-

korzystaniu podstawy o mniejszych gabarytach blat stołu znalazł się w przestrzeni roboczej

manipulatora. W wyniku czego możliwa stała się symulacja pracy robota podczas wykrywania

blatu stołu. Zastosowanie standardowej bazy robota Polycrank uniemożliwiło przeprowadze-

nie eksperymentu, gdyż stół byłby wtedy poza przestrzenią roboczą. Możliwość dodawania

obiektów, łatwość zmiany ich położenia i orientacji to ogromna zaleta programu GraspIt, która

pozwala na dużą wygodę podczas przeprowadzania eksperymentów.

41

4.7. SCENY 3D

Rysunek 4.8: Prosta scena 3D w GraspIt: robot Polycrank z chwytakiem trójpalczastym umiesz-

czony na podłożu.

Rysunek 4.9: Wirtualny świat w GraspIt: robot Polycrank z chwytakiem dwupalczastym. Pod-

stawą robota jest sześcian. Scena 3D wykorzystana do symulacji wykrywania blatu stołu przez

chwytak manipulatora.

42

Rozdział 5

Qt

5.1 Opis technologii

Qt to zestaw w pełni przenośnych bibliotek języka C++, a także narzędzi programistycz-

nych dedykowanych dla różnych języków programowania i platform systemowych. Obecnie

technologia dostępna jest w językach C++, Java, Ada, Pascal, Perl, PHP, Ruby i Python.

Platforma Qt dostępna jest na wielu systemach operacyjnych, m.in: Windows, Mac OS X

oraz dla urządzeń wbudowanych opartych na Linux (Qt Extended), Windows CE i Symbian

oraz platformy X11 (Solaris, GNU). Producentem Qt jest norweska firma Qt Development

Frameworks, a właścicielem fińska firma Nokia.

Technologia oferuje m.in:

• klasy służące do budowy graficznego interfejsu użytkownika (GUI 1),

• mechanizm sygnałów i slotów,

• automatyczne rozmieszczanie widżetów,

• zhierarchizowany system obsługi zdarzeń.

Qt udostępnia niezależne od platformy systemowej moduły służące do obsługi m.in:

• interfejsu użytkownika,

• baz danych (SQL),

• języka XML,

• procesów,

• wielowątkowości,

• grafiki trójwymiarowej (OpenGL),

• plików,1(ang. Graphical User Interface)

43

5.2. SYGNAŁY I SLOTY

• sieci.

W skład Qt wchodzi wiele specjalistycznych narzędzi programistycznych. Należą do nich

m.in.:

• Qt Designer - aplikacja graficzna do definiowania graficznego interfejsu użytkownika

(okien dialogowych itp.),

• Qt Linguist - aplikacja wspomagająca tłumaczenie programu na różne języki,

• Qt Assistant - aplikacja zawierająca rozbudowany system pomocy dla programistów,

• Qt Creator - zintegrowane środowisko programistyczne,

• moc (ang. Meta Object Compiler) - specjalny preprocesor, który na podstawie plików

nagłówkowych (*.h) generuje dodatkowe pliki źródłowe (*.cpp),

• uic (ang. User Interface Compiler) - kompilator plików *.ui zwykle generowanych za

pośrednictwem programu Qt Designer,

• qmake - program do zarządzania procesem kompilacji, którego głównym zadaniem

jest utworzenie, a później aktualizacja pliku Makefile na podstawie definicji projektu

zawartej w pliku (*.pro),

Qt od wersji 4.0 zaczęło udostępniać także narzędzia do tworzenia programów konsolowych

i serwerów. Technologia ta ma w pełni obiektową architekturę. Posiada ona także własne sza-

blony klas kontenerowych, niezależne od zaimplementowanych w bibliotece STL(ang. Standard

Template Library) języka C++. Qt jest podstawą środowiska graficznego KDE dedykowanego

dla systemów linuxowych, komunikatora Skype, przeglądarek internetowych Opera i Aurora.

Symulator planowania i realizacji chwytów GraspIt, opisany w rozdziale 4, także został na-

pisany w oparciu o tą bibliotekę. Qt rozpowszechniane jest na licencji LGPL (ang. Lesser

General Public License) oraz oddzielnie w wersji komercyjnej. Licencja LGPL pozwala na

tworzenie zarówno otwartego, jak i zamkniętego, komercyjnego oprogramowania.

5.2 Sygnały i sloty

Kluczową rolę w bibliotece Qt odgrywa mechanizm sygnałów i slotów. Umożliwia on komu-

nikację pomiędzy obiektami. Sygnał jest komunikatem informującym, o wystąpieniu pewnego

zdarzenia. Obiekty z biblioteki Qt emitują (emit) sygnał w momencie wystąpienia zdarzenia

np. naciśnięcia przycisku. Slot jest specyficzną metodą obiektu z biblioteki Qt, która może

obsługiwać zdarzenie, np. zakończyć działanie aplikacji. Slot odpowiedzialny jest za wykona-

nie określonej funkcji. Aby połączenie było możliwe slot i sygnał muszą zawierać taką samą

listę parametrów. Inaczej mówiąc sygnały można dowolnie łączyć ze slotami, o ile posiadają

takie same parametry. Prosty przykład wykorzystania mechanizmu sygnałów i slotów dobrze

ilustruje wydruku 5.1, pochodzący z [16].

44

5.3. KOMUNIKACJA SIECIOWA

1 #inc lude <QApplication >

#inc lude <QPushButton >

i n t main( i n t argc , char *argv [])

{

5

QApplication a(argc , argv);

QPushButton button("Quit");

button.show ();

10 QObject :: connect (&button , SIGNAL( clicked () ), &a, SLOT( quit() ));

return a.exec ();

}

Wydruk 5.1: Przykład wykorzystania mechanizmu sygnałów i slotów w Qt.

W linii 10 na wydruku 5.1 widoczny jest przykład połączenia dwóch obiektów. Jeśli obiekt

button (przycisk) wyemituje sygnał o nazwie clicked() (przycisk kliknięty), na obiekcie

a (aplikacja) zostanie wywołany slot o nazwie quit(), co spowoduje zakończenie działania

aplikacji.

5.3 Komunikacja sieciowa

Tworząc interfejs sieciowy staje się przed wyborem protokołu komunikacji. W większości

przypadków wybór dotyczy dwóch protokołów: TCP (ang. Transmission Control Protocol) i

UDP (ang. User Datagram Protocol). Użycie protokołu komunikacji bezpołączeniowej UDP

jak i protokołu komunikacji połączeniowej TCP daje możliwość połączenia się z dowolną

platformą.

TCP to strumieniowy protokół komunikacji, który znajduje się w warstwie transporto-

wej modelu OSI (ang. Open System Interconnection). TCP gwarantuje, w przeciwieństwie

do UDP, wiarygodne połączenie dla wyższych warstw poprzez używanie sum kontrolnych i

numerów sekwencyjnych pakietów. Ma to na celu weryfikację, czy doszło do wysłania bądź

odbioru. Obsługa brakujących pakietów odbywa się poprzez żądania retransmisji. Host odbie-

rający pakiety TCP porządkuje je według numerów sekwencyjnych. W ten sposób przekazuje

wyższym warstwom modelu OSI pełen, prawidłowo złożony segment. Inaczej mówiąc TCP

gwarantuję, że wysłane pakiety dotrą do celu i we właściwej kolejności. Protokół znajduje

zastosowanie tam, gdzie wymagany jest wysoki stopień niezawodności.

UDP to protokół bezpołączeniowy, który znajduje się także w warstwie transportowej

modelu OSI. UDP oferuje jedynie kontrolę integralności pakietu i nie daje gwarancji, że da-

tagramy dotrą do celu. Nie ma nawet gwarancji, że dostanie się zwrotną informację, czy

którykolwiek z pakietów w ogóle dotarł do celu. Korzystanie z protokołu wiąże się za to z

dużo mniejszym narzutem komunikacyjnym niż w przypadku protokołu TCP. Trzeba bowiem

45

5.3. KOMUNIKACJA SIECIOWA

pamiętać, że TCP wymaga nawiązywania połączenia i śledzenia sesji. UDP nie posiada zaś

żadnych mechanizmów kontroli przepływu i retransmisji danych. Dzięki tym uproszczeniom

UDP oferuję większą szybkość transmisji danych niż TCP. Protokół UDP znalazł zastoso-

wanie w wideokonferencjach lub grach sieciowych, gdzie dane muszą być przesyłane szybko.

Poprawą błędów, jeżeli takie zajdą, zajmują się wtedy inne warstwy modelu OSI.

W przypadku interfejsów sieciowych trudno jest znaleźć optymalne rozwiązanie o charak-

terze ogólnym. Jednakże często okazuję się, że lepszym rozwiązaniem będzie wybór protokołu

UDP. Po pierwsze charakteryzuje się on większą szybkością transmisji danych niż TCP. Po

drugie w oparciu o UDP łatwiej zaimplementować komunikację sieciową aplikacji ze względu

na prostszą budowę tego protokołu. Dlatego też zaimplementowana w tej pracy komunikacja

sieciowa z systemem MRROC++ została napisana przy wykorzystaniu standardu UDP. W tym

celu wykorzystano dostępne w Qt gniazda UDP. Gniazdo (ang. socket) to abstrakcyjne pojęcie

określające dwukierunkowy punkt końcowy połączenia. Dwukierunkowość oznacza możliwość

wysyłania i odbierania danych. Gniazda wykorzystywane są przez aplikacje do komunikowa-

nia się ze sobą przez sieć w ramach komunikacji międzyprocesowej IPC (ang. Inter-Process

Communication). Istnieje wiele sposobów komunikacji międzyprocesowej.

Każde gniazdo posiada trzy główne właściwości:

• 1. typ gniazda identyfikujący protokół wymiany danych,

• 2. lokalny adres (np. adres IP),

• 3. lokalny numer portu identyfikujący proces, który wymienia dane przez gniazdo.

Tworząc gniazdo należy wyspecyfikować tryb komunikacji (połączeniowy lub bezpołącze-

niowy), z którego wynika protokół transmisji danych przez to gniazdo (TCP lub UDP). Pro-

tokół jest również elementem wyróżniającym gniazdo. Dwa gniazda o tym samym adresie, ale

różnych protokołach są różnymi gniazdami. Przykład wykorzystania gniazda klasy QUdp-

Socket w komunikacji sieciowej widoczny jest na wydruku 5.2. Jeżeli obiekt klasy QUdpSoc-

ket otrzymał sygnał readyRead() informujący o pojawieniu się pakietu zostaje uruchomiony

slot odpowiedzialny za funkcje odbierającą przychodzące pakiety. Miejsce QUdpSocket w

hierarchii dziedziczenia klas w Qt widoczne jest na rysunku 5.1.

1 void Server :: initSocket ()

{

// tw orz en ie gniazda

udpSocket = new QUdpSocket( t h i s );

5 // p r z y p i s a n i e adresu i portu

udpSocket ->bind(QHostAddress ::LocalHost , 5020);

// w y k o r z y s t a n i e m e c h a n i z m u slotów i sygnałów

connect(udpSocket , SIGNAL(readyRead ()),

10 th i s , SLOT(readPendingDatagrams ()));

}

46

5.4. GRAFICZNY INTERFEJS UŻYTKOWNIKA

// metoda o d b i e r a j ą c a p r z y c h o d z ą c e pakiety

void Server :: readPendingDatagrams ()

15 {

whi le (udpSocket ->hasPendingDatagrams ()) {

QByteArray datagram;

datagram.resize(udpSocket ->pendingDatagramSize ());

QHostAddress sender;

20 quint16 senderPort;

udpSocket ->readDatagram(datagram.data(), datagram.size(),

&sender , &senderPort );

25 processTheDatagram(datagram );

}

}

Wydruk 5.2: Przykład wykorzystania gniazda klasy QUdpSocket w komunikacji sieciowej.

Rysunek 5.1: QUdpSocket w hierarchii dziedziczenia klas w Qt.

5.4 Graficzny interfejs użytkownika

Qt Designer umożliwia interaktywne definiowanie własnego, graficznego interfejsu użyt-

kownika (GUI). Środowisko pozwala na dodawanie do tworzonych interfejsów okien dialogo-

wych, paneli, menu, list rozwijalnych, przycisków, suwaków i innych widżetów widocznych na

rysunku 5.2, w panelu po lewej stronie. W panelu po prawej stronie, na dole, można usta-

wiać parametry dodawanych elementów graficznego interfejsu użytkownika np. szerokość czy

wysokość.

Dodając kolejne elementy metodą drag and drop czyli przeciągnij i upuść, tworzymy w

programie obiekty klas Qt. Najczęściej wykorzystywane przy budowaniu GUI są klasy QPu-

shButton i QLabel pozwalające na tworzenie przycisków i napisów (etykiet). Miejsce tych

dwóch klas w hierarchii dziedziczenia w Qt przedstawia rysunek 5.3.

47

5.4. GRAFICZNY INTERFEJS UŻYTKOWNIKA

Rysunek 5.2: Przykład prostego GUI tworzonego w Qt Designer.

Rysunek 5.3: QPushButton i QLabel w hierarchii dziedziczenia klas w Qt.

48

Rozdział 6

System MRROC++

System MRROC++[28] został stworzony w Instytucie Automatyki i Informatyki Stosowanej

Politechniki Warszawskiej. Już w latach 80-tych XX-tego wieku powstał jego pierwowzór o na-

zwie RORC1 [29] wspomagający tworzenie sterowników dla jednostkowych robotów. Następcą

RORC’a był MRROC. MRROC umożliwiał współpracę z systemami wielorobotowymi i był

tworzony w sposób proceduralny. Następcą MRROC’a był tworzony już w sposób obiektowy

MRROC++, który jest rozwijany po dzień dzisiejszy.

6.1 Struktura ramowa

Obecnie występuje ogromna różnorodność robotów, środowisk pracy robotów, czujników.

Dlatego też istnieje potrzeba stworzenia struktury oprogramowania zdecydowanie ogranicza-

jącej niezbędne, lecz tak kosztowne, modyfikacje przy powstawaniu nowych projektów, ste-

rowników. Odpowiednim rozwiązaniem w takim przypadku wydaje się programowa struktura

ramowa.

Na programową strukturę ramową składają się po pierwsze moduły umożliwiające two-

rzenie programów sterujących robotami, po drugie niezbędne są szablony programów po to,

aby móc wywoływać moduły biblioteczne. W programowej strukturze ramowej nie może też

zabraknąć wzorców modułów.

Przykładem programowej struktury ramowej jest system MRROC++, który skutecznie wspo-

maga wytwarzanie sterowników dla systemów wielorobotowych. MRROC++ jest biblioteką modu-

łów służących do budowania sterowników programowych dedykowanych zadaniom, a zarazem

językiem programowania, w którym to zadanie jest programowane.

Główne cechy charakterystyczne struktury ramowej MRROC++ to:

• otwartość pozwalająca na dołączenie dużej liczby różnych czujników takich jak czujniki

sił i momentów sił, czujniki dotykowe, czujniki na podczerwień, czujniki ultradźwiękowe,

kamery,

• możliwość tworzenia systemów sterujących znaczną liczbą robotów,1ang. Research-Oriented Robot Controller

49

6.1. STRUKTURA RAMOWA

• tworzone sterowniki programowe dedykowane są specyficznej konfiguracji sprzętowej,

specyficznej klasie zadań,

• procesy uruchamiane są w węzłach lokalnej sieci komputerowej działającej pod kontrolą

systemu operacyjnego czasu rzeczywistego QNX 6.5.0 lub systemu linuxowego Ubuntu

10.10 (Lucid Lynx) ,

• modularna struktura systemu, która upraszcza jego modyfikację, ponieważ wymiana

jednego z elementów nie wymaga wymiany czy modyfikacji pozostałych modułów,

• struktura bazująca na języku programowania C++.

Struktura systemu MRROC++ została przedstawiona na rysunku 6.1.

Rysunek 6.1: Struktura systemu MRROC++.

Jak widać sterownik MRROC++ ma hierarchiczną strukturę funkcjonalną. Typowy sterownik

składa się z trzech warstw:

• interfejsu operatora,

• zależnej od zadania,

• zależnej od sprzętu.

Najniższa warstwa odwołuje się bezpośrednio do sprzętu, a w jej skład wchodzą procesy

obsługi urządzeń (efektorów, czujników). Procesy EDP (ang. Effector Driver Process) są ste-

rownikami charakterystycznymi dla danego typu efektora. EDP jest właściwym sterownikiem

50

6.2. KONSOLA STEROWNICZA

konkretnego typu robota. Można powiedzieć, że jest to serwer wykonujący rozkazy klientów

jakimi są procesy ECP oraz UI. Zmiana typu robota odbywa się poprzez zmianę EDP. Dane od-

czytywane z czujników rzeczywistych są przetwarzane przez procesy VSP (ang. Virtual Sensor

Processes).

W kolejnej warstwie można wyróżnić procesy: ECP (ang. Effector Control Process). Re-

alizują one algorytmy sterowania poszczególnymi efektorami, w zależności od zadania, które

jest aktualnie wykonywane przez system.

Warstwę nadrzędną tworzy proces MP (ang. Master Process). Do jego zadań należy koor-

dynacja procesów sterujących robotami. Proces MP jest koordynatorem działania wszystkich

współpracujących efektorów. Jeśli sterownik dedykowany jest tylko jednemu efektorowi czyli

steruje się jednym robotem wówczas MP przesyła jedynie polecenia z UI do niższych warstw.

Proces UI (ang. User Interface) tworzy warstwa, która nie jest bezpośrednio związana z re-

alizacją zadania i zapewnia jedynie komunikację sterownika z operatorem. Proces UI umożliwia

obsługę całego sterownika m.in. ładowanie bądź zabijanie procesów, synchronizację robota,

wybór węzłów do uruchamiania procesów.

Procesy MP oraz ECP są zależne od zadania, które ma wykonać system robotyczny. Pro-

cesy zależne od sprzętu, czyli EDP oraz VSP są niezależne od zadania. Oznacza to, że mody-

fikacja zadania sprowadza się do modyfikacji kodu procesów MP i ECP. Zmiany w sprzęcie

wymagają modyfikacji kodu procesów EDP w przypadku efektora i VSP w przypadku czujnika.

W strukturze procesów: MP, ECP, VSP można wyróżnić 2 podstawowe części:

• jądro, które jest wymienną częścią procesu, zależną od zadania realizowanego przez

system robotyczny,

• powłoka, która jest niezmienną częścią procesu, niezależną od wykonywanego zadania.

Jest ona odpowiedzialna za realizację procesu w systemie operacyjnym, komunikację z

innymi procesami.

MRROC++ od chwili powstania był wykorzystany do sterowania wykonaniem różnorodnych

zadań, tj: układania kostki Rubika [7] [32] [31] [22], polerowania i frezowania przez robota

RNT [30] [32], gry w warcaby [3] [4], a nawet rysowania [32].

6.2 Konsola sterownicza

Graficzna konsola sterownicza widoczna na rysunku 6.2 powstała, aby sterowanie syste-

mem MRROC++ oraz manipulatorami było w jak największym intuicyjne. Konsola wykonana

została w środowisku Photon Application Builder systemu operacyjnego czasu rzeczywistego

QNX Neutrino. Oferuje ona rozbudowany zestaw elementów pozwalających na tworzenie gra-

ficznych interfejsów użytkownika.

Głównym zadaniem graficznej konsoli sterowniczej jest uruchamianie procesów EDP po-

szczególnych robotów (EDP Load) oraz uruchamianie procesu MP. Procesy EDP mogą być

uruchamiane oddzielnie dla każdego robota lub jednocześnie dla wszystkich robotów. Aby uru-

chomić oddzielnie procesy EDP dla każdego robota należy przejść do menu Robot i uruchomić

51

6.2. KONSOLA STEROWNICZA

Rysunek 6.2: Konsola sterwonicza systemu MRROC++ stworzona w PhAB.

proces EDP właściwego robota np. proces EDP jednego z robotów IRp-6 (Irp6-on-Track,

Irp6-Postument) lub pasu transmisyjnego Conveyor. Aby uruchomić procesy EDP wszystkich

robotów należy przejść do menu All robots i uruchomić proces EDP. Uruchomienie procesu

EDP umożliwia dostęp do menu wybranego robota. Dzięki temu mamy zazwyczaj dostęp

do polecenia synchronizacji oraz możemy doprowadzić robota do jednej z predefiniowanych

pozycji. Proces MP steruje wykonaniem całego zadania.

Główne sposoby zadawania pożądanej pozycji manipulatorom to:

• położenia stawów,

• położenia silników,

• współrzędne oś-kąt,

• współrzędne Eulera.

Korzystając z okna ruchów ręcznych widocznego na rysunku 6.2 można zadawać położenia

manipulatorowi w przestrzeni stawów.

Każdy z robotów udostępnia również polecenie zakończenia działania procesu EDP (EDP

Unload). Uruchomienie procesu MP daje dostęp do funkcji wywoływanych z okna Process

52

6.3. GENERATOR SMOOTH

Control dostępnego w menu Task. Wywołując Configuration z menu Task możliwe jest wczy-

tanie konfiguracji robota z wybranego pliku konfiguracyjnego. Pliki konfiguracyjne w systemie

MRROC++ domyślnie znajdują się w katalogu configs. Przydatną funkcją konsoli jest możliwość

wyczyszczenia jej zawartości poprzez wywołanie Clear Console z menu Task.

Na początku 2011 roku została zaimplementowana konsola sterownicza, widoczna na zdję-

ciu 6.3, przy wykorzystaniu technologii Qt. Było to konsekwencją prowadzonej od pewnego

czasu migracji systemu MRROC++ na platformę Linux. Powodem migracji była chęć ujednolice-

nia platformy oraz uproszczenia sposobu kompilacji i uruchamiania systemu MRROC++. Pozwo-

liło to na zwiększenie wygody pracy i otworzyło nowe możliwości w rozwoju systemu MRROC++

jakie oferuje obecnie platforma Linux. Nowa konsola pozwala także na uruchamianie sterow-

ników robotów tj. IRp-6, Smb, Spkm, Shead. Jak widać graficznie i funkcjonalnie jest bardzo

zbliżona do poprzedniej wersji.

Rysunek 6.3: Konsola sterwonicza systemu MRROC++ stworzona w Qt.

6.3 Generator Smooth

Za generowanie trajektorii w strukturze MRROC++ odpowiedzialne są obiekty generato-

rów. Do ich zadań należy zainicjalizowanie ruchu, wyznaczanie współrzędnych kolejnych

punktów trajektorii oraz sprawdzanie spełnienia warunków stopu. Generator trajektorii

Smooth stworzony został w ramach pracy [26]. Jego implementacja znajduje się w klasie

ecp::common::generator::newsmooth.

53

6.3. GENERATOR SMOOTH

Generator Smooth generuje trajektorię dla poniższych reprezentacji:

• wewnętrzne współrzędne

– przestrzeń stawów

– przestrzeń napędów,

• zewnętrzne współrzędne,

– układ współrzędnych os-kąt,

– układ współrzędnych Eulera.

Generator ten porusza końcówką manipulatora po trajektorii zdefiniowanej poprzez skoń-

czony zbiór punktów w przestrzeni roboczej. Umożliwia on zdefiniowanie ograniczeń na przy-

spieszenie i prędkość ruchu niezależnie dla każdej osi. Prędkość początkowa i końcowa ruchu

wynosi zero. Ruch jest płynny, ponieważ przejście przez poszczególne punkty trajektorii od-

bywa się bez zatrzymywania ruchu.

Generator Smooth może poruszać manipulatorem:

• do ostatnio osiągniętej pozycji - void move_to_current(void),

• do następnej pozycji - void move_to_next(void),

• poprzedniej pozycji - void move_to_prev(void),

• bezpośrednio do pierwszego punktu trajektorii - void move_to_first(void),

• bezpośrednio do ostatniego punktu trajektorii - void move_to_last(void).

Najważniejszą w ECP i MP instrukcją jest komenda Move(), której zadaniem jest wywoła-

nie instrukcji ruchowej klasy generatora. Wykorzystuje ona dane udostępnione przez efektory

i sensory. Wywołanie przez proces ECP metody Move() generatora realizuje algorytm genero-

wania ruchu.

MRROC++ zawiera narzędzia przyspieszające implementację generatorów, zawiera również

szereg generatorów, na których można się wzorować lub które można próbować rozszerzać.

Szerzej opisywano to w pracy [28].

54

Rozdział 7

Specyfikacja wymagań

7.1 Główne wymagania

Główne wymagania dotyczące symulacja robota Polycrank to:

• stworzenie modelu 3D robota w celu wizualizacji,

• zapoznanie się z chwytakiem wielopalczastym, pod kątem możliwości jego symulacji,

– z chwytakiem dwupalczastym,

– z chwytakiem trójpalczastym,

• realizacja kinematyki prostej i odwrotnej manipulatora,

• stworzenie interfejsu pozwalającego na:

– komunikację robota Polycrank z systemem MRROC++,

– zapis i odtwarzanie trajektorii ruchu,

– zapis położeń interpolacyjnych,

• napisanie sterownika robota Polycrank w systemie MRROC++,

• uruchomienie ruchów ręcznych dla manipulatora z UI1 systemu MRROC++, w celu stero-

wania pracą robota,

– z UI napisanego w Photon Application Builder uruchamianego na platformie systemu

czasu rzeczywistego QNX,

– z UI napisanego w Qt uruchamianego na platformie Linux,

• napisanie prostego zadania MP wykorzystującego generator trajektorii Smooth.1ang. User Interface

55

7.2. ANALIZA WYMAGAŃ

7.2 Analiza wymagań

Na początku realizacji projektu otrzymałem model 3D od konstruktora robota Polycrank,

dr inż. Krzysztofa Mianowskiego z Wydziału Mechanicznego Energetyki i Lotnictwa Politech-

niki Warszawskiej. Model wymagał edycji w kilku zaawansowanych programach graficznych

3D takich jak: Unigraphics NX5, 3dsMax i Deep Exploration 5. Pozwoliło to na przeniesienie

modelu manipulatora do programu GraspIt w celu symulacji. Do symulacji robota Polycrank

w programie GraspIt został wykorzystany chwytak dwupalczasty i trójpalczasty autorstwa

K. Czajkowskiego. Jak widać początkowe wymagania wiązały się głównie z koniecznością

wykorzystania już istniejących technologii i modeli, co pozwoliło na skuteczne rozwiązanie

napotkanych problemów.

Analiza wcześniej wymienionych wymagań pokazała, że kluczowym problemem w pracy

jest realizacja kinematyki prostej i odwrotnej manipulatora Polycrank. Możliwe okazały się

dwa rozwiązania:

1. Implementacja kinematyki prostej i odwrotnej w systemie MRROC++,

2. Wykorzystanie zaimplementowanej kinematyki prostej i odwrotnej w programie GraspIt.

Typowym rozwiązaniem tego problemu jest implementacja kinematyki prostej i odwrotnej

w sterowniku robota Polycrank w systemie MRROC++. Trzeba jednak wiedzieć, że rozwiązanie

kinematyki odwrotnej w systemie MRROC++ zależy od aktualnej konfiguracji manipulatora.

Dlatego nie daje to gwarancji czy znalezione rozwiązanie nie powoduje np. kolizji z innymi

obiektami. GraspIt posiada większą niż MRROC++ ilość danych np. o położeniu przeszkód, dla-

tego wydaje się, że kinematyka odwrotna powinna być w nim rozwiązywana. Wadą tego

rozwiązania jest jednak fakt, że kinematyka odwrotna w GraspIt obliczana jest numerycznie,

a nie analitycznie, jak w MRROC++. Kinematyka odwrotna obliczana analitycznie jest szybsza i

bardziej niezawodna o tej obliczanej numerycznie. Jednak o wiele ważniejsze w symulacji jest

to, aby uzyskiwane rozwiązania kinematyki odwrotnej nie powodowały kolizji z innymi obiek-

tami, przeszkodami tworzącymi środowisko pracy robota. Wtedy symulacja ma sens i możliwe

jest przeprowadzenie eksperymentów związanych z pracą manipulatora. Dlatego rozwiązania

z symulatora powinny mieć wyższy priorytet niż znalezione analitycznie w systemie MRROC++.

Implementacja interfejsu pozwalającego na komunikację robota Polycrank z systemem

MRROC++, zapis i odtwarzanie trajektorii ruchu, zapis położeń interpolacyjnych będzie wy-

magać wykorzystania technologii Qt. Biblioteka ta ma ogromne możliwości jeżeli chodzi o

budowanie graficznego interfejsu użytkownika oraz pisanie komunikacji sieciowej opartej na

gniazdach protokołów UDP lub TCP. Do komunikacji z systemem MRROC++ zostaną wykorzy-

stane gniazda UDP, co zostało uzasadnione w podrozdziale 5.3.

Napisanie sterownika robota Polycrank wymaga poznania istniejących już rozwiązań w

systemie MRROC++. Wzorując się na rozwiązaniach stworzonych dla innych manipulatorów,

powielając istniejące już szablony, należy napisać sterownik dla robota Polycrank. W takim

też celu powstała struktura ramowa MRROC++, która wspiera tworzenie nowych sterowników.

Manipulator Polycrank powinien być dodany do UI zbudowanego w Photon Application Builder

56

7.2. ANALIZA WYMAGAŃ

lub Qt w podobny sposób, jak miało to miejsce w przypadku innych robotów. Do generacji

trajektorii na podstawie położeń interpolacyjnych zostanie wykorzystany generator trajektorii

Smooth. Będzie to wymagało napisania prostego zadania MP w systemie MRROC++.

Realizacja wymagań stawianych pracy pozwoli stworzyć metodę symulacji robota Poly-

crank przy wykorzystaniu zaawansowanych możliwości systemu sterowania robotów MRROC++

i symulatora GraspIt. Opracowanie metody symulacji jest niezbędne, aby stworzyć środowi-

sko badawcze, w którym będzie można przeprowadzać niezbędne eksperymenty związane z

symulacją robota Polycrank.

57

Rozdział 8

Implementacja

W ramach badań opracowałem i zaimplementowałem własną metodę symulacji pracy ma-

nipulatora Polycrank w systemie MRROC++. Jest to innowacyjna metoda symulacji robota w sto-

sunku do dotychczas zaimplementowanych w systemie MRROC++ manipulatorów. Kinematyka

prosta i odwrotna robota Polycrank nie została zrealizowana w sterowniku manipulatora, lecz

w symulatorze GraspIt. W myśl zasady, że „nie należy próbować wyważać otwartych drzwi”, do

symulacji robota Polycrank wykorzystałem zaawansowane możliwości programu GraspIt, które

zostały opisane w rozdziale 4.

8.1 Sekwencja operacji

Symulacja robota Polycrank wymagała stworzenia w programie GraspIt interfejsu złożo-

nego z trzech okien dialogowych, które zostały szczegółowo opisane w tym rozdziale. Są one

uruchamiane z zaimplementowanego dla robota Polycrank menu, widocznego na rysunku 8.1.

Rysunek 8.1: Stworzone w programie GraspIt menu pozwalające na: 1. Komunikację sieciową

z systemem MRROC++ (Connect with MRROC++), 2. Zapis położeń interpolacyjnych (Save inter-

polation positions), 3. Odtwarzanie trajektorii ruchu (Play trajectory).

W celu symulacji pracy robota Polycrank należy wykonać następującą sekwencję operacji:

• Operacja 1 . Wczytać plik konfiguracyjny robota Polycrank w programie GraspIt. Został

on opisany w podrozdziale 4.5.

• Operacja 2 . Uruchomić okno programu GraspIt widoczne na rysunku 8.2 pozwalające

na zapisywanie do pliku *.trj położeń interpolacyjnych robota Polycrank.

58

8.1. SEKWENCJA OPERACJI

Rysunek 8.2: Zaimplementowane w GraspIt okno pozwalające na zapis położeń interpolacyj-

nych.

• Operacja 3 . Na wejście generatora Smooth w systemie MRROC++ należy umieścić plik z

położeniami interpolacyjnymi robota Polycrank uzyskany w programie GraspIt. O tym

pliku była mowa w Operacja 2. Plik ten w systemie MRROC++ jest plikiem sterującym dla

generatora Smooth, dzięki któremu można wygenerować trajektorię ruchu robota Poly-

crank przesyłaną podczas działania systemu do EDP. Wymaga to uruchomienia prostego

zadania MP dla robota Polycrank, które korzysta z generatora trajektorii Smooth. Zo-

stało to dokładnie omówione w podrozdziale 8.3.4.

• Operacja 4 . Uruchomić okno programu GraspIt, widoczne na rysunku 8.3, służące do

komunikacji sieciowej z procesem EDP robota Polycrank w celu wizualizacji przesyłanej

trajektorii ruchu. Podczas wizualizacji w GraspIt istnieje możliwość zapisu przesyłanej

trajektorii do pliku *.txt.

Rysunek 8.3: Zaimplementowane w GraspIt okno pozwalające na komunikacje sieciową z sys-

temem MRROC++.

• Operacja 5 . Uruchomić okno programu GraspIt, widoczne na rysunku 8.4 pozwalające

na odtwarzanie trajektorii z pliku *.txt. O tym pliku była mowa w Operacja 4.

59

8.1. SEKWENCJA OPERACJI

Rysunek 8.4: Zaimplementowane w GraspIt okno pozwalające na odtwarzanie trajektorii ruchu

robota Polycrank.

Rysunek 8.5: Sekwencja operacji opracowanej metody symulacji robota Polycrank w systemie

MRROC++.

60

8.2. IMPLEMENTACJA W GRASPIT

Oprócz opisu słownego sekwencja operacji została przedstawiona za pomocą diagramu 8.5.

Jak widać stworzona metoda symulacji opiera się na umiejętnym wykorzystaniu możliwości

zaawansowanych narzędzi, takich jak generator Smooth systemu MRROC++ i symulator GraspIt.

Jest ona ciekawą alternatywą w stosunku to standardowej metody symulacji, która wymaga

implementacji kinematyki prostej i odwrotnej w systemie MRROC++ w oparciu o stworzone na

papierze równania. Nierzadko są to bardzo skomplikowane równania, które wymagają dopra-

cowywania i wielu poprawek w trakcie implementacji w systemie MRROC++. Opracowana przeze

mnie metoda pozwala na symulację bez konieczności implementacji tychże równań po stronie

systemu MRROC++. Poza tym, GraspIt posiada większą niż MRROC++ ilość istotnych informacji

np. o położeniu przeszkód, dlatego kinematyka prosta i odwrotna powinny być w nim rozwią-

zywane. Dzięki temu uzyskiwane rozwiązania nie będą powodowały kolizji z innymi obiektami,

przeszkodami.

8.2 Implementacja w Graspit

Opracowana metoda symulacji wymagała implementacji w symulatorze GraspIt graficznego

interfejsu pozwalającego na:

• komunikację robota Polycrank z systemem MRROC++,

• zapis i odtwarzanie trajektorii ruchu,

• zapis położeń interpolacyjnych.

Interfejs ten został zaimplementowany, podobnie jak GraspIt, w oparciu o bibliotekę Qt w

środowisku Qt Designer. Tworząc graficzny interfejs użytkownika stosowałem standardowe,

sprawdzone rozwiązania opisane szczegółowo w książkach [6] oraz [24]. Diagram hierarchii klas

wchodzących w skład stworzonego interfejsu został przedstawiony na rysunku 8.6.

Rysunek 8.6: Diagram hierarchii zaimplementowanych klas w GraspIt przy wykorzystaniu

biblioteki Qt.

Główne metody klasy PolycrankPanel zostały przedstawione w tabeli 8.1.

61


Nazwa funkcji Znaczenie

void edpClicked() nawiązanie komunikacji sieciowej z systemem MRROC++

void sendDatagram() wysyłanie danych (dowolny, niepusty pakiet) do systemu MRROC++

void receiveDatagram() odbieranie danych (trajektorii) z systemu MRROC++

void saveClicked() zapis trajektorii ruchu do pliku *.txt

void XClicked() obsługa zamknięcia okna

Tablica 8.1: Główne metody klasy PolycrankPanel zaimplementowanej w programie GraspIt.


void playerForwardTrajectoryClicked() odtwarzanie trajektorii w przód

void playerBackwardTrajectoryClicked() odtwarzanie trajektorii w tył

void chooseFileClicked() wybór pliku *.txt z trajektorią do odtwarzania


Tablica 8.2: Główne metody klasy PolycrankPlayer zaimplementowanej w programie GraspIt.

Główne metody klasy PolycrankPlayer zostały przedstawione w tabeli 8.2.

Główne metody klasy PolycrankSaver zostały przedstawione w tabeli 8.3.


void saverPositionsClicked() zapis położeń interpolacyjnych do pliku *.trj

void chooseFileClicked() wybór pliku *.trj do zapisu położeń interpolacyjnych


Tablica 8.3: Główne metody klasy PolycrankSaver zaimplementowanej w programie GraspIt.

Główna klasa MainWindow programu GraspIt komunikuje się z tymi trzema klasami

korzystając z mechanizmu slotów i sygnałów, analogicznie jak mam to miejsce w przypadku

innych okien tego symulatora.

W następnych podrozdziałach zostały szczegółowo opisane okna będące instancjami klas

PolycrankPanel, PolycrankPlayer i PolycrankSaver. Oprócz wymienionych już moż-

liwości każde okno wyświetla aktualne wartości 7 zmiennych przegubowych robota Poly-

crank (Q1, Q2, Q3, Q4, Q5, Q6, Q7). Robot Polycrank ma 6 stopni swobody, ale 7 zmien-

nych przegubowych. Wynika to z faktu, że zmienne Q4 i Q5 są ze sobą sprzężone.

Tylko jedno z tych trzech okien może być w danej chili aktywne w GraspIt. Wynika to

z faktu, że np. odtwarzanie trajektorii z pliku nie ma sensu gdy trwa komunikacja robota

Polycrank z systemem MRROC++. Podobnie bezsensowne są pozostałe przypadki gdy, więcej

niż jedno spośród trzech okien jest aktywne. Innymi słowy każde okno określa jeden z trzech

rozłącznych trybów pracy stworzonego symulacyjnego środowiska badawczego, mianowicie:

1. tryb komunikacji z systemem MRROC++,

2. tryb odtwarzania trajektorii z pliku,

62


3. tryb zapisu położeń interpolacyjnych do pliku.

W przypadku próby uruchomienia więcej niż jednego okna spośród trzech tutaj opisanych

pojawi się komunikat widoczny na rysunku 8.7.

Rysunek 8.7: Komunikat pojawiający się w sytuacji próby uruchomienia więcej niż jednego

okna zaimplementowanego w GraspIt dla robota Polycrank.

8.2.1 Zapis położeń interpolacyjnych

Okno widoczne na rysunku 8.8 pozwala na zapis pozycji interpolacyjnych członów robota

uzyskanych poprzez zmianę położenia lub orientacji końcówki.

Rysunek 8.8: Zaimplementowane w GraspIt okno pozwalające na zapis położeń interpolacyj-

nych. Na rysunku zaznaczono główne funkcje okna.

Główne funkcje okna zostały zaznaczone na rysunku 8.8. Oto one:

1. Save interpolation positions - zapis aktualnych położeń interpolacyjnych członów

robota,

2. Choose file to save interpolation positions - uruchomienie okna widocznego na

rysunku 8.13 umożliwiającego stworzenie pliku, w którym będą zapisywane kolejne po-

łożenia interpolacyjne.

Symulator GraspIt ma zaimplementowany solver, który numerycznie rozwiązuje zadanie ki-

nematyki odwrotnej. Dzięki temu poprzez zmianę położenia i orientacji końcówki wyliczane są

położenia odpowiednich członów robota, które można zapisać do pliku. Tak uzyskane położe-

nia interpolacyjne są zapisywane do pliku w formacie zaproponowanym przez Rafała Tulwima

63


Rysunek 8.9: Okno umożliwiające stworzenie pliku, do którego będą zapisywane położenia

interpolacyjne.

w jego pracy inżynierskiej [26]. Przykładowy plik z położeniami interpolacyjnymi widoczny

jest na wydruku 8.10 i pochodzi z raportu [21].

W tym pliku podaje się na kolejno rozdzielając 1 pustą linią:

1. rodzaj współrzędnych np. JOINT,

2. ilość położeń (pozycji) interpolacyjnych,

3. rodzaj ruchu - ABSOLUTE lub RELATIVE,

4. prędkości maksymalne będące liczbami rzeczywistymi z przedziału (0-1),

5. przyspieszenia maksymalne będące liczbami rzeczywistymi z przedziału (0-1),

6. położenia interpolacyjne (współrzędne) w danej reprezentacji.

8.2.2 Komunikacja z MRROC++

Okno pozwalające na komunikację sieciową z systemem MRROC++ widoczne jest na ry-

sunku 8.11. Użytkownik podaje w nim adres IP i port komputera, na którym został urucho-

miony proces EDP robota Polycrank. Pobierana z zadaną częstotliwością z sytemu MRROC++

trajektoria jest wizualizowana w programie GraspIt. Inaczej mówiąc, GraspIt pełni rolę wizuali-

zacji przesyłanej trajektorii ruchu robota Polycrank. Podczas wizualizacji okno oferuję także

możliwość zapisu trajektorii ruchu do pliku. Tak powstały plik z trajektorią można później

odtwarzać wykorzystując okno widoczne na rysunku 8.11 i opisane w podrozdziale 8.2.3.


1. Connect with EDP Polycrank - nawiązanie komunikacji sieciowej z systemem

MRROC++,

64


Rysunek 8.10: Przykładowy plik z położeniami interpolacyjnymi umieszczany na wejście ge-

neratora trajektorii Smooth.

Rysunek 8.11: Zaimplementowane w GraspIt okno pozwalające na komunikacje sieciową z

systemem MRROC++. Na rysunku zaznaczono główne funkcje okna.

2. Port - możliwość wprowadzenia portu, na którym został uruchomiony proces EDP

robota Polycrank,

3. IP - możliwość wprowadzenia adresu IP, na którym został uruchomiony proces EDP

robota Polycrank,

65


4. suwak ustawiający częstotliwość pobierania danych podczas komunikacji sieciowej z

systemem MRROC++, domyślnie pakiety pobierane są z częstotliwością 50 Hz czyli co

20ms,

5. Save Polycrank Trajectory - możliwość zapisu przesyłanych danych (trajektorii

ruchu) z systemu MRROC++ do pliku *.txt

6. dioda określająca status połączenia, dioda pulsuje na zielono tylko jeżeli ma miejsce

komunikacja, w przeciwnym przypadku nie pulsuje wcale,

7. - wyświetlanie i zadawanie częstotliwości pobierania danych z systemu MRROC++.

Komunikacja sieciowa odbywa się w architekturze klient-serwer przy wykorzystaniu gniazd

klasy QUdpSocket. Rozwiązanie to zostało szczegółowo omówione w podrozdziale 5.3. Po-

bieranie danych (trajektorii) w stałych odstępach czasowych zostało zrealizowane przy wy-

korzystaniu obiektów klasy QTimer. Timery tej klasy dokładnie odliczają czas w oparciu o

przerwania zegarowe. Przykład wykorzystania obiektu klasy QTimer widać na wydruku 8.1.

1 // s t w o r z e n i e obiektu klasy QTimer

QTimer timerInterval;

// u r u c h o m i e n i e timer ’a o d l i c z a j ą c e g o czas 20 ms

timerInterval.start (20);

5 // z a t r z y m a n i e timer ’a

timerInterval.stop ();

Wydruk 8.1: Przykład użycia timer’a klasy QTimer do odliczania czasu 20 ms.

8.2.3 Odtwarzanie trajektorii

Okno pozwalające na odtworzenie pliku z trajektorią widoczne jest na zrzucie ekrano-

wym 8.12. Trajektoria może być odtwarzana w przód lub w tył. Okno pozwala ustawić żądaną

częstotliwość odtwarzania trajektorii.


1. Play Forward Trajectory - odtwarzanie trajektorii w przód,

2. Play Backward Trajectory - odtwarzanie trajektorii w tył,

3. suwak informujący o postępie w odtwarzaniu trajektorii z pliku, podobne rozwiązanie

jest często stosowane w popularnych odtwarzaczach multimedialnych,

4. Open Trajectory File - uruchomienie okna widocznego na rysunku 8.13 umożliwia-

jącego wybór pliku z trajektorią, która ma zostać wczytana do odtwarzania,

5. Frequency - ustawianie częstotliwości odtwarzania trajektorii, domyślna wartość to

50 Hz czyli zmienne przegubowe robota Polycrank w GraspIt są aktualizowane kolejnymi

wartościami z pliku co 20 ms.

66

8.3. IMPLEMENTACJA W MRROC++

Rysunek 8.12: Zaimplementowane w GraspIt okno pozwalające na odtwarzanie trajektorii ru-

chu robota Polycrank. Na rysunku zaznaczono główne funkcje okna.

Rysunek 8.13: Okno umożliwiające wybór pliku z trajektorią, która ma zostać wczytana do

odtwarzania.

8.3 Implementacja w MRROC++

Wzorując się na sterownikach napisanych dla innych manipulatorów zaimplementowałem

własny dla robota Polycrank w systemie MRROC++. Dodałem do UI niezbędne elementy, aby

móc sterować pracą robota Polycrank z konsoli sterowniczej. Zostało to zrealizowane, zarówno

dla UI stworzonego w Photon Application Builder, jak i zaimplementowanego w Qt.

Sterownik, powstały w oparciu o strukturę MRROC++ działa pod kontrolą systemu operacyj-

nego czasu rzeczywistego QNX 6.5.0 lub Ubuntu 10.10 (Lucid Lynx). Jest to w rzeczywistości

zbiór procesów, z których każdy ma precyzyjnie określone zadanie.

Struktura ramowa MRROC++ udostępnia obecnie dwie metody programowania trajektorii

67


robota Polycrank:

1. pliki trajektorii,

2. ruchy ręczne za pomocą konsoli sterowniczej.

8.3.1 Sterownik EDP

Tworząc sterownik wzorowałem się na implementacji zastosowanej dla robota Conveyor.

Sterownik dla tego robota miał najprostszą strukturę i nie miał zaimplementowanej kinema-

tyki. Trzeba pamiętać, że w projekcie, z powodów opisanych w podrozdziale 7.2, kinematyka

robota Polycrank nie jest realizowana w systemie MRROC++, a w programie GraspIt. Pisząc

sterownik dla robota Polycrank powieliłem sposób implementacji zastosowany dla robota Co-

nveyor uwzględniając istotne szczegóły takie jak np. liczba stopni swobody. Proces EDP zleca

wykonanie ruchu, jeżeli przysłano rozkaz ruchu SET ARM, odczytu położenia GET ARM

lub synchronizacji SYNCHRO. Ze względu na fakt, że przedmiotem pracy jest symulacja

założyłem w implementacji sterownika EDP, że robot jest zsynchronizowany.

Szczegółową dokumentację Doxygen systemu MRROC++ z zaimplementowanym w tej pracy

sterownikiem robota Polycrank załączyłem na płycie CD.

Przed uruchomieniem sterownika robota Polycrank z UI należy wczytać jego plik konfigu-

racyjny. W tym celu należy wywołać Configuration z menu Task i podać ścieżkę do pliku

konfiguracyjnego. Plik konfiguracyjny robota Polycrank w systemie MRROC++ widoczny jest na

wydruku 8.2.

1 [ui]

is_polycrank_active =1

is_mp_and_ecps_active =1

;additional_spawn_argument=>> /net/grafika/dev/ttyp1

5

[mp]

program_name=mp_polycrank

node_name=reksio

10 [ecp_polycrank]

program_name=ecp_polycrank

node_name=reksio

[edp_polycrank]

15 robot_test_mode =1

force_sensor_test_mode =1

node_name=reksio

Wydruk 8.2: Plik konfiguracyjny robota Polycrank w systemie MRROC++.

68


8.3.2 UI-PhAB

Proces UI obsługuje rozkazy wydawane przez operatora systemu, umożliwia uruchomienie

i zakończenie działania sterownika. Użytkownik może sterować robotami za pomocą okna ru-

chów ręcznych w przestrzeni stawów (JOINTS). Nie można sterować ręcznie robotem w trakcie

działania procesu MP. Zlecenia zakończenia, wstrzymania, wznawiania działania procesu MP

są realizowane poprzez obustronną, programową wymianę informacji pomiędzy procesami UI

i MP.

Dla robota Polycrank podobnie jak dla innych robotów dodanych do systemu MRROC++

zostały zaimplementowane polecenia:

• Load_EDP - uruchomienie procesu EDP,

• Unload_EDP - zabicie procesu EDP,

• Move_Joints - uruchomienie okna ruchów ręcznych widocznego na zdjęciu 8.14.

Rysunek 8.14: Zaimplementowane okno ruchów ręcznych dla robota Polycrank w UI stworzo-

nym w PhAB.

Okno ruchów ręcznych dla robota Polycrank widoczne na zdjęciu stworzyłem w środowisku

Photon Application Builder. Wymagało to :

69


• powielenia elementów graficznych z okna ruchów ręcznych dla robota IRp-6 Postument,

który podobnie jak Polycrank ma 6 stopni swobody,

• wprowadzenia nowych nazw dla tychże elementów,

• stworzenia nowych funkcji (Callback) do obsługi zdarzeń wywoływanych z okna ruchów

ręcznych.

Wprowadzone przeze mnie nazwy dla elementów graficznych, czy też funkcji obsługi zda-

rzeń są analogiczne do tych stworzonych wcześniej dla innych robotów. Inaczej mówiąc w

implementacji trzymałem się wypracowanego w systemie MRROC++ standardu nazywania, co

jest uważane za dobrą praktykę programistyczną. Jak widać stworzenie sterownika dla robota

Polycrank wymagało powielenia istniejących już rozwiązań implementacyjnych i standardów.

Taka jest też rola i znaczenie systemu MRROC++, będącego otwartą i elastyczną strukturą ra-

mową wspomagającą tworzenie nowych sterowników dla robotów.

8.3.3 UI-Qt

Jak widać na rysunku 8.15 robot Polycrank został także dodany do nowej konsoli sterow-

niczej zaimplementowanej w Qt.

Rysunek 8.15: Robot Polycrank dodany do nowego UI napisanego w Qt.

Funkcjonalnie drugi sterownik robota Polycrank działa tak samo jak ten uruchamiany z

konsoli sterowniczej na platformie QNX. Zmienił się tylko proces UI i jego środowisko uru-

chomieniowe. Poprzednia konsola sterownicza była zrealizowana przy wykorzystaniu PhAB

70


i mogła być uruchamiana na platformie QNX. Obecnie wykorzystywana konsola sterowni-

cza została stworzona w Qt i jest uruchamiana na platformie Linux. Podobnie jak wcześniej

proces EDP robota Polycrank w systemie MRROC++ można uruchomić wywołując EDP Load.

Zakończenie działania procesu odbywa się poprzez wywołanie EDP Unload. Okno ruchów

ręcznych w przestrzeni stawów uruchamiane jest poprzez Move Joints. Korzystając z okna

ruchów ręcznych widocznego na rysunku 6.2 można sterować pracą manipulatora Polycrank

zadając położenia w przestrzeni stawów. Przeniesienie konsoli sterowniczej z platformy QNX

na Linux miało na celu poprawę jakości pracy, ujednolicenie platformy, uproszczenie sposobu

kompilacji i uruchamiania systemu MRROC++.

Rysunek 8.16: Zaimplementowane okno ruchów ręcznych dla robota Polycrank w nowym UI

napisanych w Qt.

8.3.4 Zadanie MP

Klasą bazową dla wszystkich globalnych procesów ECP i MP jest klasa

ecp_mp::task::task. Inicjalizuje ona komunikację z procesem UI, udostępnia też sze-

reg metod umożliwiających komunikację z operatorem i wirtualnymi czujnikami. Zapewnia

ona obiektom klas po niej dziedziczących dostęp do innych obiektów istniejących w systemie.

Obiekt reprezentujący odpowiedniego robota tworzony jest przy tworzeniu obiektu klasy

ecp_mp::task::task.

Aby wykorzystać generator trajektorii Smooth należało zaimplementować proste zadanie

MP dla robota Polycrank. W tym celu wykorzystałem aplikację generator_tester, w której

71


trzeba było:

1. stworzyć obiekt generatora newsmooth, co widać na wydruku 8.3,

1 sgenjoint = new generator :: newsmooth(ecp_t , lib::ECP_JOINT ,6)

Wydruk 8.3: Tworzenie obiektu generatora newsmooth.

W konstruktorze generatora newsmooth należy podać kolejno:

(a) ecp_t - obiekt klasy ecp_mp::task::task,

(b) lib::ECP_JOINT - rodzaj współrzędnych, w których odbywa się ruch,

(c) 6 - liczbę osi, w których się odbywa się ruch.

2. załadować dla generatora plik z trajektorią przy pomocy metody

load_trajectory_from_file, której argumentem jest właśnie ścieżka do pliku

z położeniami interpolacyjnymi robota Polycrank,

3. wywołać na obiekcie generatora newsmooth, metodę calculate_interpolate() i dalej

metodę Move().

Najważniejszą w ECP i MP instrukcją jest komendaMove(), której zadaniem jest wywoła-

nie instrukcji ruchowej klasy generatora. Wykorzystuje ona dane udostępnione przez efektory

i sensory. Wywołanie przez proces ECP metody Move() generatora realizuje algorytm gene-

rowania ruchu. Metoda calculate_interpolate() dokonuje interpolacji położeń.

Zadanie MP dla robota Polycrank stworzyłem analogicznie, jak miało to miejsce w przy-

padku robotów IRp-6. Generalnie generator Smooth używa się w podobny sposób dla wszyst-

kich robotów.

Aby uruchomić zadanie MP dla robota Polycrank w systemie MRROC++, trzeba kolejno:

1. załadować plik konfiguracyjny, widoczny na wydruku 8.4, zadania MP dla robota Poly-

crank,

2. uruchomić proces EDP robota Polycrank,

3. uruchomić proces MP,

4. uruchomić zadanie MP klikając na przycisk Start.

Aby zatrzymać wykonanie zadania należy kliknąć przycisk Stop.

Plik konfiguracyjny zadania MP dla robota Polycrank wykorzystujący generator trajektorii

Smooth w systemie MRROC++ widoczny jest na rysunku 8.4.

1 [ui]

is_irp6ot_m_active =0

is_irp6p_m_active =0

is_polycrank_active =1

5 is_conveyor_active =0

72


is_mp_and_ecps_active =1

[mp]

program_name=mp_gen_test

10 node_name=reksio

[ecp_irp6p_m]

program_name=ecp_gen_test

node_name=reksio

15

[edp_irp6p_m]

robot_test_mode =0


node_name=reksio

20

[ecp_polycrank]


node_name=reksio

25 [edp_polycrank]

robot_test_mode =1


node_name=reksio

30 [ecp_conveyor]


node_name=reksio

[edp_conveyor]

35 robot_test_mode =1


node_name=reksio

[ecp_irp6ot_m]

40 program_name=ecp_gen_test

node_name=reksio

[edp_irp6ot_m]

robot_test_mode =1

45 force_sensor_test_mode =1

node_name=reksio

Wydruk 8.4: Plik konfiguracyjny zadania MP dla Polycrank wykorzystującego generator tra-

jektorii Smooth w systemie MRROC++.

Po uruchomieniu zadania MP dla dowolnego robota generator wykrywa możliwość nie-

73


bezpiecznego szarpnięcia w ruchu. Szarpnięcie to rozumiane jest jako przekroczenie przyspie-

szenia (zmiany prędkości) we współrzędnych, w których przeprowadzona jest interpolacja.

Wykrywanie takich zdarzeń wynika z faktu, że mogą one prowadzić do uszkodzenia manipula-

tora. Tworząc zadanie MP dla robota można uwzględniać lub pomijać wykrywanie szarpnięć

stosując odpowiednie warunki logiczne przedstawione na wydruku 8.5. Wykrycie szarpnięcia

powoduje, że trajektoria ruchu nie zostanie wygenerowana.

1 // Jeżeli w y k r y w a n i e s zar pn ię ć ma być u w z g l ę d n i o n e to

// warunek powinien wyglądać n a s t ę p u j ą c o :

i f (sgenjoint ->calculate_interpolate () &&

sgenjoint ->detect_jerks (1) == 0)

5 {

sgenjoint ->Move ();

}

// Jeżeli w y k r y w a n i e s zar pn ię ć ma być po min ię te to

10 // warunek powinien wyglądać n a s t ę p u j ą c o :

i f (sgenjoint ->calculate_interpolate ())

{

sgenjoint ->Move ();

}

Wydruk 8.5: Uwględnienie lub pomijanie wykrywania szarpnięć przez generator Smooth.

74

Rozdział 9

Badania

W ramach badań opracowałem i wykonałem szereg eksperymentów. Miały one na celu

przetestowanie możliwości symulacji robota Polycrank w zaimplementowanym przeze mnie

środowisku badawczym. Przedmiotem zainteresowania była analiza kinetyczna, w szczególno-

ści badanie trajektorii ruchu podczas wykonywania przez robota różnych zadań. Symulacja

pozwoliła stwierdzić, które zadania są realizowalne, a które nie i co trzeba zmienić, aby były

do wykonania. Spośród wykonanych wielu eksperymentów przedstawiam trzy wybrane, które

dobrze ilustrują typowe problemy jakie można analizować i rozwiązywać przy użyciu opraco-

wanej przeze mnie metody symulacji.

9.1 Eksperyment 1 - ruch chwytaka w pionie wzdłuż filaru

Rysunek 9.1: Eksperyment 1: Symulacja ruchu końcówki robota Polycrank w pionie wzdłuż

filaru. A-położenie początkowe chwytaka, B-położenie końcowe chwytaka.

Celem eksperymentu widocznego na rysunku 9.1 było uczenie robota Polycrank ruchu w

pionie wzdłuż filaru. Położenie początkowe chwytaka zostało przedstawione na rysunku A,

75

9.2. EKSPERYMENT 2 - WYKRYWANIE BLATU STOŁU

położenie końcowe na rysunku B. Na potrzeby eksperymentu należało wykorzystać podstawę

sześcienną o mniejszych gabarytach niż standardowa baza robota Polycrank. Pozwoliło to ob-

niżyć przestrzeń roboczą manipulatora i umożliwiło uczenie robota w większym zakresie. W

trakcie symulacji okazało się, że im więcej punktów interpolacyjnych zostało zadanych w Gra-

spIt, tym wygenerowana z systemu MRROC++ trajektoria była bliższa pożądanemu ruchowi w

pionie. Jednak nie należy przesadzać z badaniach z wyznaczaniem punktów interpolacyjnych,

ponieważ generacja trajektorii to przecież zadanie generatora. Zaimplementowane środowisko

badawcze można także wykorzystać do przeprowadzenia eksperymentalnych symulacji pozwa-

lających określić, ile minimalnie należy zadać punktów interpolacyjnych i w których miejscach,

aby nauczyć robota ruchu w pionie. Prowadząc jednak tego typu badania, trzeba precyzyj-

nie określić dokładność ruchu jaką chcemy osiągnąć. Uzyskane w eksperymencie trajektorie

zostały zapisane i można je w przyszłości wykorzystać do analizy lub uczenia rzeczywistego

robota.

9.2 Eksperyment 2 - wykrywanie blatu stołu

Rysunek 9.2: Eksperyment 2: Symulacja wykrywania blatu stołu przez robota Polycrank. A-

położenie początkowe chwytaka, B-położenie końcowe chwytaka.

Na potrzeby eksperymentu, widocznego na rysunku 9.2 należało wykorzystać podstawę

sześcienną o mniejszych gabarytach niż standardowa baza robota Polycrank. Pozwoliło to na

obniżenie przestrzeni roboczej manipulatora. Zastosowanie typowej bazy dla robota uniemoż-

liwiło przeprowadzenie eksperymentu wykrywania blatu stołu, gdyż stół byłby wtedy poza

przestrzenią roboczą manipulatora. Możliwość dodawania obiektów, łatwość zmiany ich poło-

żenia i orientacji to ogromna zaleta programu GraspIt, która pozwala na dużą wygodę podczas

przeprowadzania eksperymentów. Położenie początkowe kiści robota zostało pokazane na ry-

sunku A, a końcowe na rysunku B. Ten eksperyment wymagał wyznaczenia zdecydowanie

większej ilości punktów interpolacyjnych (minimum 20) niż poprzednim razem, kiedy wystar-

czyło zazwyczaj 10. W przypadku małej ich ilości generowana trajektoria nie dość, że była

daleka od zadanej, to dochodziło do kolizji. Trzeba pamiętać, że domyślnie GraspIt wykrywa

76

9.3. EKSPERYMENT 3 - RUCH CHWYTAKA Z JEDNEGO FILARU NA DRUGI I ZPOWROTEM

kolizje. Wynikało to z dłuższego odcinka ruchu i z dużej powierzchni stołu. Wykrywanie blatu

stołu odbywało się na dłuższym niż w poprzednim eksperymencie odcinku, dlatego wymagało

wyznaczenia większej ilości punktów interpolacyjnych. Nieduże odchylenia od zadanej tra-

jektorii w pierwszym eksperymencie powodowały tylko odejście od pionu, a tutaj przy dużej

powierzchni stołu powodują kolizje. Najprostszym rozwiązaniem byłoby wyłączenie wykry-

wania kolizji w GraspIt w sposób pokazany na rysunku 9.3 (przejście ze stanu wykrywania

kolizji Colision ON na wyłączenie wykrywania kolizji Colision OFF ). Jednak najlepszym, nie

tylko w symulacji, ale także w rzeczywistości rozwiązaniem jest zachowania pewnego odstępu

(bezpieczeństwa) od blatu stołu w tego typu eksperymentach. Szczególnie w rzeczywistości

błędne przeprowadzenie takiego eksperymentu może spowodować uszkodzenie chwytaka, a

nawet manipulatora. Dlatego warto jest w takim przypadku przeprowadzić wcześniej odpo-

wiednie symulacje.

Rysunek 9.3: Eksperyment 2: Wyłączenie wykrywania kolizji w GraspIt.

9.3 Eksperyment 3 - ruch chwytaka z jednego filaru na drugi i

z powrotem

Oczywiście nie wszystkie problemy okazały się wykonalne w zaimplementowanym środo-

wisku badawczym. Przykład takiego eksperymentu widoczny jest na rysunku 9.4. Ruch koń-

cówki nie były możliwy pomiędzy dwoma filarami ze względu na sprzężenie członów 4 i 5 w

kinematyce robota. Dopiero jednak po symulacji problemu można było to stwierdzić. Można

dojść także do takiego samego wniosku analizując możliwe położenia sprzężonych członów

widoczne na zdjęciach 2.2. Dlatego w przemyśle, tak często, zanim przystąpi się do pracy z

rzeczywistym robotem symuluje się możliwości jego wykorzystania w określonych sytuacjach.

Pozwala to zaoszczędzić czas i pieniądze. Dzięki symulacji można dokonać gruntownej analizy

i podjąć próbę rozwiązania problemu. Analizując problem w środowisku symulacyjnym za-

uważyłem, że zadanie byłoby realizowalne, jeżeli człon 4 i 5 nie byłyby ze sobą sprzężone, co

widać na rysunku 9.5. Innymi słowy symulacja nie tylko pozwala rozstrzygnąć czy dany pro-

blem da się czy nie rozwiązać przy określonych założeniach. Umożliwia ona także dostrzeżenie

jakie zmiany konstrukcyjne należy wprowadzić, aby zadanie stawiane przed robotem było do

wykonania.

Jak wcześniej wspomniałem ruch końcówki między dwoma filarami byłby możliwy, jeżeli w

kinematyce nie uwzględnialibyśmy sprzężenia członu 4 i 5. Oznaczałoby to, że robot musiałby

77

9.3. EKSPERYMENT 3 - RUCH CHWYTAKA Z JEDNEGO FILARU NA DRUGI I ZPOWROTEM

Rysunek 9.4: Eksperyment 3: Symulacja ruchu końcówki z jednego filaru na drugi. Sprzężone

człony 4 i 5 uniemożliwiają ruch chwytaka z jednego filaru na drugi.

Rysunek 9.5: Eksperyment 3: Symulacja ruchu końcówki z jednego filaru na drugi. Człony 4

i 5 nie są sprzężone. A-położenie początkowe chwytaka, B-położenie końcowe chwytaka.

mieć 7 stopni swobody. W tym celu dokonałem odpowiednich zmian w pliku konfiguracyj-

nym robota Polycrank w programie GraspIt oraz modyfikacji w sterowniku robota w systemie

MRROC++. Jak się okazało po stronie systemu MRROC++ wymagało to właściwie kosmetycznej

zmiany wartości stałej określającej liczbę stopni swobody robota Polycrank oraz dodawania

siódmego stopnia swobody do UI. Po dokonaniu niezbędnych modyfikacji symulacja potwier-

dziła, iż ruch końcówki jest możliwy między 2 filarami, jeżeli nie uwzględniałoby się sprzężenia

między 4 i 5 członem.

Na potrzeby eksperymentu należało wykorzystać standardową bazę robota o większych

gabarytach niż pod podstawa sześcienna, użyta w dwóch poprzednich eksperymentach. Eks-

peryment wykonałem wykorzystując 3 punkty interpolacyjne, gdy chwytak był w położeniu

początkowym, końcowym i znów początkowym.

78

9.4. OCENA BADAŃ

9.4 Ocena badań

Kluczowe znaczenie w opracowanej przeze metodzie symulacji robota Polycrank odgrywają

punkty interpolacyjne. Teoretycznie im więcej tych punktów tym trajektoria ruchu będzie bliż-

sza pożądanej w przestrzeni operacyjnej. Jednak wyznaczanie dużej liczby punktów interpola-

cyjnych nie ma większego sensu, gdyż jest czasochłonne, a przede wszystkim do wyznaczania

kolejnych położeń powinno wykorzystać się generator trajektorii Smooth, bo taka jest prze-

cież jego rola. Zadanie generatora Smooth można nazwać uczeniem manipulatora trajektorii

na pamięć na podstawie zadanych w programie GraspIt położeń interpolacyjnych.

W wielu badaniach interesująca może okazać zaimplementowana możliwość odtwarzania

trajektorii od tyłu. Pozwala to na inne spojrzenie na uzyskaną trajektorię ruchu. Także w

przypadku, gdy plik z trajektorią jest bardzo duży, możliwość odtwarzania trajektorii od tyłu

znacznie przyspiesza odnalezienie interesującego nas fragmentu ruchu.

Opracowana metoda symulacji pozwala na analizę kinematyczną ruchu robota Polycrank.

Stworzone symulacyjne środowisko badawcze pozwala na odwzorowywanie w wirtualnym świe-

cie rzeczywistych problemów. W programie GraspIt możliwe stało się proste uczenie robota

Polycrank, rysowanie trajektorii ruchu, którą można zapisać do pliku. Tak zapisane trajektorie

mogą być przedmiotem analizy w przyszłości, a nawet posłużyć do sterowania rzeczywistym

robotem. Szereg przeprowadzonych eksperymentów potwierdził poprawność implementacji.

Trzeba być jednak świadomym, że nie wszystkie zadania są możliwe do realizacji np. ze

względu na kinematykę robota. Przedstawione w tym rozdziale eksperymenty nie były ra-

czej skomplikowane, a mimo to nasunęło się w trakcie nich wiele wniosków, co też pokazuje

rolę i znaczenie symulacji.

79

Rozdział 10

Podsumowanie

10.1 Wnioski

Stworzenie odpowiedniego modelu komputerowego 3D wiernie odwzorowującego rzeczywi-

stego manipulatora wymaga zachowania odpowiednich proporcji i kształtów. Często niezbędna

jest poprawa geometrii modelu oraz uproszczenie jego siatki. Obecnie dostępnych jest wiele

komercyjnych i darmowych programów o ogromnych możliwościach, które nie tylko wspierają

podczas tworzenia modeli 3D, ale i obsługują najróżniejsze formaty plików graficznych. W celu

osiągnięcia pożądanego efektu najistotniejszy jest wybór odpowiedniego narzędzia i formatu

graficznego.

Symulacja pracy robota Polycrank w wirtualnym świecie 3D pozwala rozwiązać wiele trud-

nych do realizacji w rzeczywistości problemów. Do jednych z nich z pewnością należy problem

nieograniczoności zakresów obrotów w przegubach, który trudno jest uzyskać w rzeczywistości,

choćby ze względu na okablowanie robota. Jak łatwo się domyśleć w stworzonym wirtualnym

środowisku badawczym taki problem praktycznie nie istnieje.

Kinematyka prosta i odwrotna robota Polycrank nie została zaimplementowana w systemie

sterowania MRROC++, a w programie GraspIt. W tym kryje się element innowacyjności pracy,

ponieważ sterownik robota w systemie MRROC++ najczęściej zawiera jednak implementację jego

kinematyki prostej i odwrotnej. Trzeba jednak pamiętać, że rozwiązanie kinematyki odwrotnej

w MRROC++ zależy od aktualnej konfiguracji manipulatora. Dlatego nie daje to gwarancji czy

znalezione rozwiązanie nie powoduje np. kolizji z innymi obiektami tworzącymi środowisko

pracy robota. GraspIt posiada większą niż MRROC++ ilość istotnych informacji np. o położeniu

przeszkód, dlatego kinematyka odwrotna powinna być w nim rozwiązywana. Wadą tego roz-

wiązania jest jednak fakt, że kinematyka odwrotna w GraspIt obliczana jest numerycznie, a

nie analitycznie jak w MRROC++. Trzeba bowiem wiedzieć, że kinematyka odwrotna obliczana

analitycznie jest szybsza i bardziej niezawodna o tej obliczanej numerycznie. Jednak szybkość

obliczeń podczas zadawania pozycji interpolacyjnych w opracowanej metodzie symulacji nie

ma aż tak istotnego znaczenia. Za to ważniejsze w symulacji jest to, aby uzyskiwane rozwią-

zania kinematyki odwrotnej nie powodowały kolizji z innymi obiektami, przeszkodami.

GraspIt w opracowanej metodzie symulacji stał się środowiskiem badawczym pozwalającym

80

10.2. PERSPEKTYWY ROZWOJU

na eksperymenty związane z symulacją robota Polycrank. Było to możliwe dzięki właściwemu

wykorzystaniu możliwości zaawansowanych technologii takich jak GraspIt i generator trajekto-

rii Smooth. Kinematyka prosta i odwrotna robota Polycrank jest rozwiązywana po stronie pro-

gramu GraspIt, a trajektoria ruchu pochodzi z generatora trajektorii Smooth systemu MRROC++.

Uzyskane w trakcie eksperymentalnych symulacji trajektorie ruchu mogą zostać wykorzystane

przez sterownik rzeczywistego robota. Ma to często miejsce w przemysłowych zastosowaniach.

Przed wdrożeniem często wykonuje się symulacje z użyciem dokładnego modelu robota. Umoż-

liwia to przeprowadzenie niezbędnych, wstępnych badań i pozwala wyeliminować wiele błędów

przed wdrożeniem manipulatora na rzeczywiste stanowisko pracy.

Stworzone środowisko badawcze pozwala na analizę kinematyczną pracy robota Polycrank i

rysowanie możliwych trajektorii ruchu w trakcie realizacji różnych zadań. Analiza dynamiczna

nie była tematem tej pracy. Jak pokazuje praca [13] do analizy dynamicznej należałoby wy-

korzystać inne technologie. O stopniu złożoności problemu świadczy choćby fakt, że temat

dynamiki w tej pracy został podjęty w zawężonym zakresie, dotyczącym analizy dynamicznej

samego mechanizmu przeniesienia napędu. Mimo to wymagał wykorzystania wielu specjali-

stycznych środowisk.

Kompleksowa symulacja pracy robota wymaga uwzględnienia jego kinematyki i dynamiki.

Jednak w wielu przypadkach na początkowym etapie badań wystarczająca jest analiza ki-

nematyczna. Dopiero na zaawansowanym etapie prac konieczna jest symulacja dynamiczna

uwzględniająca wszystkie występujące siły i inne czynniki zewnętrzne. Praca ta była jedną

z pierwszych na Politechnice Warszawskiej podejmującą temat symulacji robota Polycrank.

Uwzględnienie całej, złożonej dynamiki manipulatora wydaje się najciekawszą drogą rozwoju

w trakcie dalszych badań.

10.2 Perspektywy rozwoju

Główne możliwości rozwoju badań związanych z symulacją pracy robota Polycrank:

• symulacja całej złożonej dynamiki manipulatora,

• implementacja analitycznej metody obliczania kinematyki odwrotnej w programie Gra-

spIt,

• system planowania i realizacji chwytów dla robota Polycrank z chwytakiem trójpalcza-

stym,

• możliwość tworzenia plików graficznych z wygenerowaną trajektorią ruchu,

• opracowanie i realizacja kolejnych eksperymentów wykorzystujących możliwość symu-

lacji robota Polycrank w systemie MRROC++,

• symulacja równoległej pracy dwóch manipulatorów Polycrank.

81

Bibliografia

[1] IVCON-Graphics File Conversions, http://orion.math.iastate.edu/burkardt/g_src/ivcon/ivcon.html.

[2] Mesh Lab, http://meshlab.sourceforge.net/.

[3] Tomasz Bem. Robot playing checkers. Master’s thesis, WEiTI, Warsaw, 2009.

[4] Tomasz Bem, Tomasz Kornuta, and Tomasz Winiarski. Zastosowanie wizyjnej struktury

ramowej FraDIA w aplikacjach robotycznych. Cz II: Aplikacje. In XI Krajowa Konferen-

cja Robotyki, 2010.

[5] M. Żbikowski. Graficzne środowisko symulacyjne systemu wielomanipulatorowego. Poli-

technika Warszawska, WEiTI, 2009. Praca Inżynierska.

[6] J. Blanchette and M. Summerfield. C++ GUI Programming with Qt 4. Prentice Hall,

February 2008.

[7] Zieliński C., Szynkiewicz W., Winiarski T., Czajewski W., and Staniak M. Układanie

kostki Rubika jako zadanie testujące zdolności robota usługowego. In K. Tcho, editor,

IX Krajowa Konferencja Robotyki – Postępy Robotyki: Systemy i współdziałanie robotów,

volume 2, pages 237–246. Wydawnictwa Komunikacji i Łączności, Warszawa, 2006.

[8] Right Hemisphere Company. Deep Exploration, http://www.righthemisphere.com/products/dexp/.

[9] J. Craig. Wprowadzenie do robotyki - mechanika i sterowanie. WNT, 1995.

[10] K. Czajkowski. Planowanie i symulacja chwytów za pomocą sztucznej, trójpalczastej ręki.

Politechnika Warszawska, WEiTI, 2009. Praca Inżynierska.

[11] K. Czajkowski. System planowania i realizacji chwytów za pomocą robotycznych rąk.

Politechnika Warszawska, WEiTI, 2010. Praca Magisterska.

[12] J. Frączek and M. Wojtyra. Application of General Multibody Methods to Robotics.

Multibody Dynamics. Computational Methods and Applications. Springer, 2011. 131-

152.

[13] J. Jankowski. Analiza dynamiczna mechanizmu przeniesienia napędu robota Polycrank z

uwzględnieniem wpływu sił tarcia. Politechnika Warszawska, MEiL, 2010. Praca Magi-

sterska.

82

BIBLIOGRAFIA

[14] A. T. Miller. GraspIt!: A Versatile Simulator for Robotic Grasping. Columbia University,

2001.

[15] Andrew T. Miller. Graspit! 2.1. http://www.cs.columbia.edu/ cmatei/graspit/html-

manual/graspit-manual.html.

[16] D. Molkentin. The Book of Qt 4: The Art of Building Qt Applications. William Pollock,

2006.

[17] K. Nazarczuk and S. Luszczak. Redundant manipulator polycrank without joint limits -

preliminary design study. Warsaw University of Technology.

[18] K. Nazarczuk and K. Mianowski. Polycrank – fast robot without joint limits. In Pro-

ceedings of the 12-th CISM-IFToMM Symposium on Theory and Practice of Robots and

Manipulators Ro.Man.Sy’12, Vienna, 6–9 June, pages 317–324. Springer-Verlag, 1995.

[19] K. Nazarczuk, K. Mianowski, and S. Łuszczak. Development of the design of polycrank

manipulator without joint limits. In Proceedings of the 13-th CISM-IFToMM Symposium

on Theory and Practice of Robots and Manipulators Ro.Man.Sy 13, Zakopane, Poland,

3–6 July, pages 285–292. Springer-Verlag, 2000.

[20] R. M. Pinchback. Open Inventor, http://web.mit.edu/ivlib/www/iv/files.html.

[21] R.Tulwin and T. Winiarski. Motion generators performing trajectory interpolation in-

between initially defined positions. Warsaw University of Technology, Warsaw, November

2010. Report no 10-16.

[22] J. Sałacka. Fast search strategies using solution tree finding sequence of moves of Ru-

bik’s cube faces. (In Polish). Master’s thesis, WEiTI, Warsaw, 2007. Szybkie algorytmy

przeszukiwania drzew rozwiązań w celu znalezienia sekwencji ruchów ścianami kostki

Rubika.

[23] A. Sibilska. Porównanie metody wykorzystującej proste i odwrotne zadanie kinematyki

oraz jakobian do sterowania manipulatorem. Politechnika Warszawska, WEiTI, 2007.

Praca Magisterka.

[24] M. Summerfield. Advanced Qt programming : Creating Great Software with C++ and Qt

4. Addison-Wesley, July 2010.

[25] W. Szynkiewicz. Wstęp do Robotyki - Wykłady. Politechnika Warszawska, 2009.

[26] R. Tulwin. Trajectory generation in MRROC++ applications. Politechnika Warszawska,

WEiTI, 2010. Praca Inżynierska.

[27] M. Wojtyra. Zadanie proste i odwrotne kinematyki (o położeniu i prędkości) dla robota

szybkiego. Politechnika Warszawska, Luty 1999. Wersja robota zmontowana w 1999r.

83

BIBLIOGRAFIA

[28] C. Zieliliński, W. Szynkiewicz, and T. Zielielińska. System MRROC++. Technical report,

IAiIS, may 1999.

[29] C. Zieliński. Programming and control of multi-robot systems. In 6th International Con-

ference on Control, Automation, Robotics and Vision, ICARCV’2000, Singapore, pages

on CD–ROM, December 5–8 2000.

[30] C. Zieliński, W. Szynkiewicz, and T. Winiarski. Applications of MRROC++ robot pro-

gramming framework. In Proceedings of the 5th International Workshop on Robot Motion

and Control, RoMoCo’05, Dymaczewo, Poland, pages 251–257, June, 23–25 2005.

[31] C. Zieliński, W. Szynkiewicz, T. Winiarski, and M. Staniak. Rubik’s cube puzzle as a

benchmark for service robots. In 12th IEEE International Conference on Methods and

Models in Automation and Robotics, MMAR’2006, pages 579–584, August 28 - 31 2006.

[32] C. Zieliński, T. Winiarski, W. Szynkiewicz, M. Staniak, W. Czajewski, and T. Kornuta.

MRROC++ Based Controller of a Dual Arm Robot System Manipulating a Rubik’s

Cube. Technical Report 06-10, IAIS, Warsaw, 2006.

84

Dodatek A

Zawartość załączonej płyty CD

Płyta CD zawiera:

1. Symulator GraspIt Ver. 2.1 oraz jego rozszerzenia stworzone w tej pracy na potrzeby

symulacji robota Polycrank:

• pliki robota Polycrank,

• pliki stworzonych scen,

• pliki interfejsu pozwalającego na połączenie robota z systemem MRROC++, zapis i

odtwarzanie trajektorii oraz zapis położeń interpolacyjnych.

2. System MRROC++ wraz z modyfikacjami wprowadzonymi na potrzeby symulacji, w szcze-

gólności:

• sterownik EDP robota Polycrank,

• elementy UI w Photon Builder,

• elementy UI w Qt,

• zadanie MP wykorzystujące generator trajektorii Smooth.

3. Dokumentację Doxygen systemu MRROC++ z wprowadzonymi w tej pracy modyfikacjami.

85

Dodatek B

Spis symboli i skrótów

Symbol/Skrót Opis Definicja

MRROC++ Multi Robot Research-Oriented Robot Controller 49

EDP Effector Driver Process 50

ECP Effector Control Process 51

MP Master Process 51

VSP Virtual Sensor Processes 51

UI User Interface Process 51

PhAB Photon Application Builder 51

86

Spis rysunków

1.1 Robot Polycrank w laboratorium robotyki Instytutu Automatyki i Informatyki

Stosowanej Politechniki Warszawskiej widziany z trzech stron: z boku, z przodu,

z tyłu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Przestrzeń robocza robota Polycrank. . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Sprzężone ze sobą dwa człony robota Polycrank w wybranych, charakterystycz-

nych położeniach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Stopnie swobody robota Polycrank zaznaczone na trzech widokach. A - widok

z boku, B - widok z przodu, C - widok na chwytak. . . . . . . . . . . . . . . . 11

2.4 Główne elementy budowy robota Polycrank. . . . . . . . . . . . . . . . . . . . 12

2.5 A-ulokowane wewnątrz korb równoległowody służące do transmisji napędu, B-

same równoległowody połączone za pomocą łożysk. . . . . . . . . . . . . . . . 13

2.6 A-zaznaczone główne człony robota Polycrank: 0-baza, 1, 2, 3, 4, 5, 6, 7-chwytak,

B-mechanizm przeniesienia napędu do kiści. . . . . . . . . . . . . . . . . . . . 14

2.7 Wielokrotne obracanie wokół osi X2 bardzo dużym obiektem przy wykorzysta-

niu dwóch manipulatorów Polycrank. . . . . . . . . . . . . . . . . . . . . . . . 14

2.8 Manipulowanie bardzo długim obiektem przy wykorzystaniu dwóch manipula-

torów Polycrank. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Model robota Polycrank w programie Unigraphics NX5. . . . . . . . . . . . . . 17

3.2 Redundantny model i jego skomplikowana siatka w kolumnie po lewej. Zop-

tymalizowany model i jego uproszczona siatka w kolumnie po prawej. Zrzuty

ekranowe modelu robota Polycrank pochodzą z programu Deep Exploration 5. . 18

3.3 Zaznaczanie redundantnego elementu celem usunięcia z modelu robota Poly-

crank w programie Deep Exploration 5. . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Możliwości programu Deep Exploration 5. A-Proste operacje na obiektach: 1-

Skalowanie, 2-Obrót, 3-Translacja. B-Zmiana koloru materiału obiektu. . . . . 20

3.5 Model robota Polycrank w programie 3dsMax. . . . . . . . . . . . . . . . . . . 21

3.6 Przykład wydzielonego ogniwa z modelu robota Polycrank w programie 3dsMax. 21

3.7 Ogniwa robota Polycrank w formacie 3dsMax. . . . . . . . . . . . . . . . . . . 22

3.8 Sześcian w formacie Open Inventor. . . . . . . . . . . . . . . . . . . . . . . . . 22

3.9 Kula w formacie Open Inventor. . . . . . . . . . . . . . . . . . . . . . . . . . . 23

87

SPIS RYSUNKÓW

3.10 Walec w formacie Open Inventor. . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.11 Ogniwa robota Polycrank w formacie Open Inventor. . . . . . . . . . . . . . . . 25

4.1 Aplikacja Zbik3D z wizualizacją robota Polycrank. . . . . . . . . . . . . . . . . 26

4.2 Główne funkcje programu GraspIt. . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Menu File programu GraspIt pozwalające na: 1-wczytanie pliku konfigura-

cyjnego robota (*.cfg), 2-wczytanie pliku konfiguracyjnego obiektu (*.iv), 3-

wczytanie plik konfiguracyjnego przeszkody (*.iv). . . . . . . . . . . . . . . . 34

4.4 Model robota Polycrank w programie GraspIt. Człony 4 i 5 są ze sobą sprzężone.

Robot ma 6 stopni swobody. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5 Model chwytaka trójpalczastego autorstwa K. Czajkowskiego [10] w programie

GraspIt. Człony 1 i 2 są ze sobą sprzężone. Okrąg O2 zamiast na ostatnim

występuje na przedostatnim przegubie. . . . . . . . . . . . . . . . . . . . . . . 35

4.6 Model robota Polycrank bez uwzględniania sprzężenia członów 4 i 5 w programie

GraspIt. Robot ma 7 stopni swobody. . . . . . . . . . . . . . . . . . . . . . . . 36

4.7 GraspIt: A - Zmiana położenia końcówki robota Polycrank za pomocą kursora

myszy, B - Zmiana orientacji końcówki robota Polycrank za pomocą kursora

myszy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.8 Prosta scena 3D w GraspIt: robot Polycrank z chwytakiem trójpalczastym

umieszczony na podłożu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.9 Wirtualny świat w GraspIt: robot Polycrank z chwytakiem dwupalczastym. Pod-

stawą robota jest sześcian. Scena 3D wykorzystana do symulacji wykrywania

blatu stołu przez chwytak manipulatora. . . . . . . . . . . . . . . . . . . . . . 42

5.1 QUdpSocket w hierarchii dziedziczenia klas w Qt. . . . . . . . . . . . . . . . . 47

5.2 Przykład prostego GUI tworzonego w Qt Designer. . . . . . . . . . . . . . . . 48

5.3 QPushButton i QLabel w hierarchii dziedziczenia klas w Qt. . . . . . . . . . . 48

6.1 Struktura systemu MRROC++. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.2 Konsola sterwonicza systemu MRROC++ stworzona w PhAB. . . . . . . . . . . . 52

6.3 Konsola sterwonicza systemu MRROC++ stworzona w Qt. . . . . . . . . . . . . . 53

8.1 Stworzone w programie GraspIt menu pozwalające na: 1. Komunikację sieciową z

systemem MRROC++ (Connect with MRROC++), 2. Zapis położeń interpolacyjnych

(Save interpolation positions), 3. Odtwarzanie trajektorii ruchu (Play trajectory). 58

8.2 Zaimplementowane w GraspIt okno pozwalające na zapis położeń interpolacyj-

nych. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.3 Zaimplementowane w GraspIt okno pozwalające na komunikacje sieciową z sys-

temem MRROC++. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.4 Zaimplementowane w GraspIt okno pozwalające na odtwarzanie trajektorii ru-

chu robota Polycrank. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

88

SPIS RYSUNKÓW

8.5 Sekwencja operacji opracowanej metody symulacji robota Polycrank w systemie

MRROC++. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

8.6 Diagram hierarchii zaimplementowanych klas w GraspIt przy wykorzystaniu

biblioteki Qt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.7 Komunikat pojawiający się w sytuacji próby uruchomienia więcej niż jednego

okna zaimplementowanego w GraspIt dla robota Polycrank. . . . . . . . . . . . 63

8.8 Zaimplementowane w GraspIt okno pozwalające na zapis położeń interpolacyj-

nych. Na rysunku zaznaczono główne funkcje okna. . . . . . . . . . . . . . . . 63

8.9 Okno umożliwiające stworzenie pliku, do którego będą zapisywane położenia

interpolacyjne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.10 Przykładowy plik z położeniami interpolacyjnymi umieszczany na wejście ge-

neratora trajektorii Smooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.11 Zaimplementowane w GraspIt okno pozwalające na komunikacje sieciową z sys-

temem MRROC++. Na rysunku zaznaczono główne funkcje okna. . . . . . . . . . 65

8.12 Zaimplementowane w GraspIt okno pozwalające na odtwarzanie trajektorii ru-

chu robota Polycrank. Na rysunku zaznaczono główne funkcje okna. . . . . . . 67

8.13 Okno umożliwiające wybór pliku z trajektorią, która ma zostać wczytana do

odtwarzania. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.14 Zaimplementowane okno ruchów ręcznych dla robota Polycrank w UI stworzo-

nym w PhAB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.15 Robot Polycrank dodany do nowego UI napisanego w Qt. . . . . . . . . . . . . 70

8.16 Zaimplementowane okno ruchów ręcznych dla robota Polycrank w nowym UI

napisanych w Qt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

9.1 Eksperyment 1: Symulacja ruchu końcówki robota Polycrank w pionie wzdłuż

filaru. A-położenie początkowe chwytaka, B-położenie końcowe chwytaka. . . 75

9.2 Eksperyment 2: Symulacja wykrywania blatu stołu przez robota Polycrank. A-

położenie początkowe chwytaka, B-położenie końcowe chwytaka. . . . . . . . . 76

9.3 Eksperyment 2: Wyłączenie wykrywania kolizji w GraspIt. . . . . . . . . . . . 77

9.4 Eksperyment 3: Symulacja ruchu końcówki z jednego filaru na drugi. Sprzężone

człony 4 i 5 uniemożliwiają ruch chwytaka z jednego filaru na drugi. . . . . . 78

9.5 Eksperyment 3: Symulacja ruchu końcówki z jednego filaru na drugi. Człony 4

i 5 nie są sprzężone. A-położenie początkowe chwytaka, B-położenie końcowe

chwytaka. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

89

Spis tablic

4.1 Parametry Denavita-Hartenberga manipulatora Polycrank w notacji stosowanej

w programie GraspIt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Kinematyka prosta manipulatora Polycrank w notacji ZDH. . . . . . . . . . . 33

4.3 Parametry Denavita-Hartenberga manipulatora Polycrank (bez uwzględniania

sprzężenia członów 4 i 5) w notacji stosowanej w programie GraspIt. . . . . . . 39

4.4 Kinematyka prosta manipulatora Polycrank bez uwzględniania sprzężenia czło-

nów 4 i 5 w notacji ZDH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8.1 Główne metody klasy PolycrankPanel zaimplementowanej w programie GraspIt. 62

8.2 Główne metody klasy PolycrankPlayer zaimplementowanej w programie GraspIt. 62

8.3 Główne metody klasy PolycrankSaver zaimplementowanej w programie GraspIt. 62

90

Spis wydruków

3.1 Plik konfiguracyjny sześcianu widocznego na rysunku 3.8 w formacie Open In-

ventor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Plik konfiguracyjny kuli widocznej na rysunku 3.9 w formacie Open Inventor. . 23

3.3 Plik konfiguracyjny walca widocznego na rysunku 3.10 w formacie Open Inventor. 23

3.4 Dodatkowe parametry umieszczane na początku pliku konfiguracyjnego *.iv

ogniwa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Plik konfiguracyjny robota Polycrank w programie GraspIt zawierający parame-

try Denavita-Hartenberga do opis kinematyki prostej. . . . . . . . . . . . . . . 30

4.2 Plik konfiguracyjny robota Polycrank (bez uwzględniania sprzężenia członów 4

i 5) w programie GraspIt zawierający parametry Denavita-Hartenberga do opisu

kinematyki prostej. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Fragment funkcji invKinematics z pliku robot.cpp programu GraspIt ilustrujący

iteracyjną metodę obliczenia kinematyki odwrotnej . . . . . . . . . . . . . . . 40

5.1 Przykład wykorzystania mechanizmu sygnałów i slotów w Qt. . . . . . . . . . 45

5.2 Przykład wykorzystania gniazda klasy QUdpSocket w komunikacji sieciowej. . 46

8.1 Przykład użycia timer’a klasy QTimer do odliczania czasu 20 ms. . . . . . . . 66

8.2 Plik konfiguracyjny robota Polycrank w systemie MRROC++. . . . . . . . . . . . 68

8.3 Tworzenie obiektu generatora newsmooth. . . . . . . . . . . . . . . . . . . . . 72

8.4 Plik konfiguracyjny zadania MP dla Polycrank wykorzystującego generator tra-

jektorii Smooth w systemie MRROC++. . . . . . . . . . . . . . . . . . . . . . . . 72

8.5 Uwględnienie lub pomijanie wykrywania szarpnięć przez generator Smooth. . 74

91

Symulacja robota Polycrank wsystemie MRROC++

Documents

Transcript of Symulacja robota Polycrank wsystemie MRROC++