Podejmowanie pionów za pomocą robota manipulacyjnego IRp-6 ...

Rok akademicki 2013/2014

POLITECHNIKA WARSZAWSKA

WYDZIAŁ ELEKTRONIKI I TECHNIK INFORMACYJNYCH

INSTYTUT AUTOMATYKI I INFORMATYKI STOSOWANEJ

PRACA DYPLOMOWA INŻYNIERSKA

Mikołaj Kojdecki

Podejmowanie pionów za pomocą robota

manipulacyjnego IRp-6 korzystającego z chwytaka

podciśnieniowego

Opiekun pracy:dr inż. Tomasz Winiarski

Ocena pracy: . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Data i podpis Przewodniczącego

Komisji Egzaminu Dyplomowego

Streszczenie

Praca miała na celu modyfikację robota i stworzenie oprogramowania umożli-wiającego podejmowanie kamieni do japońskiej gry go za pomocą chwytaka podciś-nieniowego do elementów elektronicznych. W ramach pracy powstały programy dlasystemu ROS sterującego robotem i zadanie wizyjne stworzone przy użyciu progra-mowej struktury ramowej DisCODe.Słowa kluczowe: manipulator IRp-6, go, ROS, DisCODe, OpenCV

Spis treści

1 Wstęp 5

1.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Motywacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Układ pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Wykorzystane przyrządy i technologie 7

2.1 Gra go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Chwytak podciśnieniowy . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 Oprogramowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.1 ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.2 Orocos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5.3 IRPOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.4 DisCODe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.5 OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.6 FlyCap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Opis rozwiązania 23

3.1 Modyfikacja chwytaka . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.2 Model końcowy . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Moduł DisCODe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Sterownik kamery . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2 Zastosowane algorytmy . . . . . . . . . . . . . . . . . . . . . . 29

3.2.3 Integracja z ROS . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.4 Zadanie wizyjne . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 Moduł ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3

4 SPIS TREŚCI

3.3.1 Modyfikacje systemu IRPOS . . . . . . . . . . . . . . . . . . . 323.3.2 Klasa pomocnicza . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.3 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4 Stanowisko robocze . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.5 Schemat działania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Wyniki i wnioski 41

4.1 Strojenie systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.1.1 Eksperymenty wizyjne . . . . . . . . . . . . . . . . . . . . . . 414.1.2 Testowanie systemu . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Wyniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Literatura 46

Rozdział 1

Wstęp

Ten rozdział stanowi wstęp do pracy. Znajduje się w nim wprowadzenie do te-matyki (sekcja 1.1), moja motywacja do jej wykonania (sekcja 1.2), jej cele (sekcja1.3) oraz opis jej układu (sekcja 1.4).

1.1 Wprowadzenie

Od kiedy powstała idea robota, ludzie chcieli, by maszyny wykonywały pewneczynności za nich lub dla nich. Jako pierwsze powstały roboty przemysłowe(rysunek 1.1), które odtwarzały zaprogramowany przez eksperta ruch z powtarzalnądokładnością przekraczającą możliwości szeregowego pracownika.

Rysunek 1.1: Robot przemysłowy (źródło: [1])

Wraz z rozwojem dziedziny spektrum zastosowań dla robotów rosło. Zaczętoich używać również do rozrywki, jak na przykład robot grający w ping ponga lubrysujący portrety czy powstały na wydziale Elektroniki i Technik InformacyjnychPolitechniki Warszawskiej robot grający w kości [10]. Takie maszyny, które zaczęto

5

6 ROZDZIAŁ 1. WSTĘP

nazywać robotami usługowymi w odróżnieniu od przemysłowych, mogą w przyszło-ści znaleźć zastosowanie w codziennym życiu. Z całą pewnością mogą one ułatwićżycie ludziom z pewnymi rodzajami niepełnosprawności lub pozwolić wykonywaćpewne czynności razem, pomimo odległości, np. zdalna partia tenisa stołowego z wy-korzystaniem wideokonferencji.

1.2 Motywacja

Pierwszy raz z praktycznym podejściem do robotów spotkałem się na przedmio-cie o nazwie Wstęp do Robotyki będącym w ofercie dydaktycznej naszego wydziałui bardzo mnie ono zainteresowało. Moją motywacją do stworzenia tej pracy jest chęćzgłębienia tej ciekawej tematyki i możliwość nabrania doświadczenia przed global-nym otwarciem się rynku.

1.3 Cel pracy

Celem pracy było stworzenie systemu robotycznego, który realizowałby jednoz zadań stawianych przed graczem w go, tj. podjęcie kamienia z pojemnika w spo-sób możliwie jak najdokładniejszy. Dzięki temu w przyszłości mogłaby być możliwagra manipulatora przemysłowego IRp-6 z człowiekiem bez dodatkowego wyposażeniaułatwiającego pewne czynności robotowi (przykładowo podajnika kamieni lub do-datkowego chwytaka do umieszczania kamieni bez rozsuwania tych już znajdującychsię na planszy).

1.4 Układ pracy

Praca została podzielona na cztery rozdziały, łącznie z niniejszym. Kolejne trzyopisują: wykorzystane przy realizacji projektu narzędzia, przedmioty i oprogramo-wanie (rozdział 2), opracowane rozwiązanie (rozdział 3), wyniki pracy i płynącez nich wnioski (rozdział 4). Ponadto w rozdziale 2 znajduje się opis gry go wraz z jejskróconymi zasadami.

Rozdział 2

Wykorzystane przyrządy

i technologie

Do stworzenia systemu robotycznego realizującego postawione zadanie potrzebo-wałem przede wszystkim robota (sekcja 2.3) i obiektów (sekcja 2.1), które robot mógłpodnosić oraz narzędzia (sekcja 2.2), którym mógł tego dokonać i oprogramowaniaułatwiającego zaprogramowanie robota (sekcja 2.5). W tym rozdziale wszystkie teelementy opiszę.

2.1 Gra go

Legenda mówi, że go powstało za czasów panowania chińskiego cesarza Yao(2337-2258 p.n.e.) na jego polecenie, w celu pozytywnego wpłynięcia na jego nie-sfornego syna, Danzhu, i zostało stworzone przez jednego z cesarskich doradcówimieniem Shun. Pierwsze pisane źródła, które wspominają o grze, pochodzą z okołoIV w. p.n.e. z Chin. Go przeniknęło do Korei i Japonii około VII w. n.e.Mimo prostych zasad (wytłumaczonych skrótowo dalej) gra ma bardzo duży stopieńskomplikowania i opanowanie jej w stopniu zaawansowanym jest trudne. Doświad-czenie gracza jest określane poprzez nadaną mu rangę. Najniższą z uczniowskich jest49. kyu, najwyższą z uczniowskich 1. kyu, zaś nad nimi znajduje się siedem stopnimistrzowskich amatorskich (od 1. do 7. dana) oraz dziewięć stopni mistrzowskichprofesjonalnych (od 1. do 9. dana). Najlepsze programy komputerowe są w staniegrać na poziomie amatorskiego dana.Do gry stosowane są:

• goban (plansza),

• gosu (pojemniki na kamienie),

7

8 ROZDZIAŁ 2. WYKORZYSTANE PRZYRZĄDY I TECHNOLOGIE

Rysunek 2.1: Goishi w gosu

• goishi (kamienie).

Projekt obejmuje podejmowanie goishi z pojemnika pełniącego rolę gosu (rysunek2.1).

Zasady

Plansza składa się z pionowych i poziomych linii, które przecinają się tworząckwadrat o wymiarach 19x19 skrzyżowań (w mniejszych planszach: 13x13 lub 9x9).To właśnie przecięcia stanowią pola planszy, na których gracze na przemian układająswoje kamienie. Grę zawsze rozpoczyna gracz z czarnymi. Jeśli gracze mają podobnypoziom, to kolory są wybierane losowo, a grający białymi otrzymuje dodatkowe 6,5punktu jako rekompensatę za przewagę pierwszego ruchu czarnych. W przeciwnymwypadku gracz słabszy dostaje czarne kamienie, a dodatkowo, jeśli różnica w umie-jętnościach jest znacząca, może położyć dodatkowe od 1 do 9 kamieni w zależnościod jej wielkości. Dokładna ilość zależy od opinii silniejszego gracza.Każdy kamień ma swoje oddechy, czyli wolne przecięcia obok swojej pozycji (nieliczą się skosy). Jeśli utracił trzy z czterech swoich oddechów, znajduje się w atari(rysunek 2.2) i najpewniej zostanie zaraz zbity. W chwili kiedy zostaje otoczony, jestzabierany przez przeciwnika.

W grze są dwie zasady określające gdzie można położyć kamień:

• ko - plansza nie może wrócić do stanu sprzed poprzedniego ruchu (rysunek2.3),

2.1. GRA GO 9

Rysunek 2.2: Goishi w atari

Rysunek 2.3: Czarny zbił kamień białego. Biały nie może w tym ruchu zbić czarnego,ponieważ zabrania tego zasada ko.

• zabraniająca samobójstw - nie można wykonać ruchu w miejscu, w którymnasz kamień od razu straciłby wszystkie oddechy, chyba że powoduje to zbiciegrupy przeciwnika (i stworzenie oddechu dla naszego goishi).

Kamienie jednego koloru tworzą grupy, jeśli są obok siebie lub grupy luźne, jeślipo przekątnej (rysunek 2.4). Grupa ma tyle oddechów co kamienie ją tworzące. Ża-den z kamieni tworzących grupę nie może zostać zbity oddzielnie.Grupy mogą być żywe, martwe lub nierozstrzygnięte. Grupa jest żywa, jeśli posiadaco najmniej dwoje oczu, czyli przecięć otoczonych przez kamienie tworzące grupę.Dzieje się tak, ponieważ nie można w jednym ruchu zabrać wszystkich oddechów ta-kiej grupy, a zasada zabraniająca samobójstw nie pozwala na robienie tego w wieluruchach. Grupa martwa, czyli otoczona i niemająca co najmniej dwojga oczu, nakoniec gry liczy się jako kamienie zbite - więźniowie. Gdy po zakończeniu rozgrywkigracze nie potrafią określić czy grupa jest żywa, czy martwa (czyli jest nierozstrzy-gnięta) wznawiają grę do czasu ustalenia tego. Po określeniu statusu grupy stanplanszy jest przywracany do tego z chwili zakończenia partii.


Rysunek 2.4: Grupa (po lewej) i grupa luźna (po prawej)

Celem gry jest zdobycie jak największej ilości punktów, które mogą być naliczanena jeden z dwóch sposobów:

• chiński - gracz otrzymuje punkty za własne pozostałe na planszy kamienie i zazbite kamienie przeciwnika,

• japoński - gracz otrzymuje punkty za terytorium, które jest otoczone przezjego piony i za zbite piony przeciwnika.

Gra kończy się w chwili gdy obaj zawodnicy oddadzą ruch, co oznacza, że niewidzą dla siebie żadnych korzystnych zagrań.

2.2 Chwytak podciśnieniowy

W zadaniu ważne było, by podejmować kamienie z możliwie największą pre-cyzją. W związku z tym podnoszenie za pomocą dwóch zaciskających się palcównie było dobrym sposobem, ponieważ przesuwałoby to obiekty w pojemniku. Za-miast tego robot zaciska końcówki swojego efektora na ręcznym chwytaku podci-śnieniowym (rysunek 2.5) przeznaczonym do elementów elektronicznych. Ponieważpodejmowane obiekty są gładkie i lekkie, zastosowanie takiego narzędzia jest jednymz efektywniejszych podejść.

2.3 Robot

Głównym elementem systemu robotycznego jest robot, w tym wypadku manipu-lator przemysłowy IRp-6 (rysunek 2.6), i jego czujniki. Wszystkie programy działajądla dowolnego z dwóch egzemplarzy tego robota znajdujących się w laboratorium,choć pewne różnice w ich konstrukcji wymuszają różne parametry akwizycji ob-razu i pozycje robota w momencie podejmowania decyzji o wyborze kamienia do

2.3. ROBOT 11

(a) (b)

Rysunek 2.5: Chwytak podciśnieniowy do elementów elektronicznych

podniesienia. Zespół Programowania Robotów i Systemów Rozpoznających [6] zmo-dyfikował bazowe konstrukcje obu robotów, dokładając dodatkowy stopień swobody(tj. skręt nadgarstka).Roboty posiadają czujniki siły ATI-IA Gamma, dzięki którym jest możliwe wyczu-cie oporu i przerwanie ruchu w przypadku kontaktu z obiektem. Najważniejszymz sensorów manipulatora jest kamera opisana w sekcji 2.4.

Rysunek 2.6: Jeden z dwóch manipulatorów Irp-6


2.4 Kamera

W trakcie prac nad realizacją zadania ustaliłem, że dotychczas używana kameraanalogowa nie zapewniała jakości obrazu pozwalającej na prawidłowe rozpoznanieobiektów. Nie umożliwiała również ustawienia parametrów akwizycji potrzebnychdo ustabilizowania warunków pozyskiwania informacji wizualnych. Z tych powodówkonieczna była jej wymiana. Zastąpiła ją kamera cyfrowa Blackfly o rozdzielczo-ści 1,4 Mpix w wariancie BFLY-PGE-14S2C-CS wyprodukowana przez firmę PointGrey. Do kamery został dobrany obiektyw firmy LC Security o nazwie kodowejLC-M13VM2812IRD o aperturze F1.4 i ogniskowej zmiennej w zakresie 2,8-12mm.Regulacja szerokości otwarcia przysłony, długości ogniskowej i ostrości jest dokony-wana manualnie za pomocą pierścieni, które można zablokować śrubami.W ramach projektu inżynierskiego stworzyłem mocowanie dla kamery z aluminio-wego kątownika. Umożliwiło to pewny montaż bezpośrednio na kiści robota (ry-sunek 2.7). Dodatkowo pełni ono funkcję radiatora ciepła dla kamery. Zrealizowa-łem również sterownik do kamery przeznaczony dla platformy DisCODe, umożliwia-jący regulację parametrów akwizycji, między innymi wzmocnienia, jasności, długościotwarcia migawki oraz liczby rejestrowanych na sekundę klatek, zarówno przed uru-chomieniem komponentu, jak i w trakcie wykonania programu.

2.5 Oprogramowanie

Do stworzenia systemu wykorzystałem:

• zestaw bibliotek i narzędzi ROS do oprogramowania ruchu robota (sekcja2.5.1),

• ściśle współpracującą z ROS-em programową strukturę ramową (ang. frame-work) Orocos, która steruje ruchami robota w czasie rzeczywistym (sekcja2.5.2),

• stworzony przez Zespół Programowania Robotów i Systemów Rozpoznającychsystem o nazwie IRPOS do sterowania robotami IRp-6 (sekcja 2.5.3),

• programową strukturę ramową DisCODe do przetwarzania i przekazywaniainformacji z kamery (sekcja 2.5.4),

• bibliotekę OpenCV do przetwarzania obrazu (sekcja 2.5.5),

• bibliotekę FlyCap firmy Point Grey do stworzenia sterownika kamery (sekcja2.5.6).

2.5. OPROGRAMOWANIE 13

(a) Widok z boku (b) Widok z dołu

Rysunek 2.7: Kamera wraz z montowaniem


2.5.1 ROS

ROS [5], czyli Robot Operating System, jest programową strukturą ramową(ang. framework). Stanowi kolekcję narzędzi, bibliotek i konwencji mających na celuułatwienie tworzenia skomplikowanych, odpornych i uniwersalnych programów dlarobotów.Najważniejszą ideą stojącą za ROS-em jest rozproszenie, zarówno na etapie tworze-nia oprogramowania, jak i na etapie jego działania. Podstawową jednostką repre-zentowaną w systemie plików jest pakiet. W pakiecie mogą się znajdować programyczy skrypty, wykorzystywane w komunikacji typy danych nazywane wiadomościamioraz deklaracje usług. Każdy pakiet musi zawierać manifest, czyli plik w formacieXML, który zawiera informacje o danym pakiecie, tj. nazwę, wersję, opis, rodzaj li-cencji oraz zależności od innych pakietów i typów danych potrzebne do poprawnegoskompilowania pakietu. Poza pakietami istnieją struktury nadrzędne: metapakietybędące kolekcjami pakietów oraz repozytoria, czyli kolekcje pakietów współdzielącejeden system kontroli wersji.Na etapie działania architektura ROS-a wyróżnia:

• węzły (ang. nodes),

• tematy (ang. topics),

• wiadomości (ang. messages),

• usługi (ang. services),

• zarządcę (ang. master),

• serwer parametrów (ang. parameter server),

• worki (ang. bags).

Węzły są samodzielnymi aplikacjami współtworzącymi system. Dla robota mo-bilnego podział na procesy mógłby wyglądać następująco:

• węzeł odpowiadający za budowanie mapy środowiska,

• węzeł odpowiadający za lokalizowanie na mapie,

• węzeł odpowiadający za przetwarzanie obrazu odebranego,

• dwa węzły odpowiadające za odbieranie obrazu z kamery stereowizyjnej,

• węzeł odpowiadający za wybór ścieżki i ruch.


Publisher Subscriber

Topic

Publisher

Publisher

Subscriber

Rysunek 2.8: Jeden temat może posiadać dowolną liczbę wydawców lub subskryben-tów, w szczególności zero. Każdy subskrybent otrzymuje wiadomości od wszystkichwydawców.

Podział systemu na węzły pozwala na lepszą kontrolę nad kodem źródłowym,testowanie poszczególnych modułów osobno i oderwanie współpracujących ze sobąkomponentów od implementacji partnerów (o ile interfejsy modułów są zgodne), copozwala na łatwą zmianę metod działania. Przykładowo przy wymianie czujnikanie ma konieczności przebudowy całego systemu, trzeba jedynie podmienić modułodpowiedzialny za obsługę poprzedniego, a system będzie działać bez koniecznościdalszych ingerencji.Węzły komunikują się ze sobą za pomocą mechanizmu tematów (rysunek 2.8). Każdyproces może chcieć odbierać lub nadawać wiadomości na dany temat, np. opisująceaktualne położenie końcówki efektora manipulatora. Węzeł może zostać wydawcą(ang. publisher) i wydawać wiadomości na dany temat lub subskrybentem (ang.subscriber) i je odbierać. Dowolną z ról węzeł przyjmuje poprzez rejestrację z poda-niem nazwy tematu u zarządcy. Wydawca nigdy nie wie o istnieniu subskrybentów,a w przypadku wielu wydawców subskrybent nie wie, od którego otrzymał wia-domość, dlatego ważne jest zadbanie o odpowiednie nazwy tematów. Jeśli węzełzarejestrował się jako odbiorca wiadomości tematu, który nie posiada żadnych pro-ducentów informacji, system wyświetla ostrzeżenie, że kanał jest pusty.By stworzyć temat, węzeł musi podać format przekazywanych w nim informacji,który jest zawarty w wiadomości. Wiadomość jest definiowana poprzez stworzeniepliku nazwanego zgodnie ze schematem <nazwa_wiadomości>.msg w odpowiednimpodkatalogu pakietu. Wewnątrz pliku znajduje się dowolna liczba par typ-nazwa,przy czym każda musi być w osobnym wierszu. Właściwe pliki wykorzystywaneprzez oprogramowanie są generowane w trakcie kompilacji pakietu.W przypadku gdy wymagane jest potwierdzenie otrzymania danej wiadomości lub


Publisher SubscriberMaster

Topic

Rysunek 2.9: Schemat zapisu do tematu. Najpierw wydawca lub subskrybent zgła-sza chęć podłączenia się do tematu u zarządcy (linia przerywana). Następnie za-rządca przekazuje węzłowi informację o temacie, tworząc go w razie potrzeby (liniakropkowana). Po tej wymianie wydawca może zacząć publikować do tematu, zaśsubskrybent otrzymywać z niego wiadomości (linie ciągłe).

pewność wykonania pewnej akcji w związku z odbiorem informacji przed przej-ściem do dalszego wykonania programu, wykorzystywany jest mechanizm usług.Usługa jest definiowana przez stworzenie pliku nazwanego zgodnie ze schematem<nazwa_usługi>.srv zawierającego w sposób podobny do opisanego powyżej dwiewiadomości - jedną podającą argumenty i drugą zwracającą wyniki. W trakcie wyko-nywania programu użycie usługi jest podobne do zdalnego wywołania metody (RMI- ang. Remote Method Invoking), tj. blokuje wykonanie dalszej części programu ażdo chwili zakończenia obsługi żądania.Zarządca jest najważniejszym z procesów platformy. Jego istnienie jest niezbędnedo działania systemu. To on zarządza przestrzeniami nazw, rejestruje węzły, usługi,tematy i ich wydawców i subskrybentów (rysunek 2.9). Gdy jeden węzeł wykorzy-stuje usługę udostępnianą przez drugi, wyszukuje go poprzez zarządcę.Węzły mogą posiadać parametry, czyli pary danych typu klucz-wartość, które sąprzechowywane centralnie. Ich gromadzeniem zajmuje się serwer parametrów. W ak-tualnej wersji systemu jest on połączony z zarządcą, niemniej jednak twórcy planujągo w przyszłości usamodzielnić.Worki są kontenerami do masowego rejestrowania komunikacji w systemie. Pozwa-lają na zapisanie wiadomości pojawiających się w pewnym temacie w celu późniejszejanalizy. Dzięki workom jest możliwe dokładne odtwarzanie sytuacji wywołującychbłędy, ponieważ raz zapisane wiadomości można ponownie opublikować w temacie.W takim przypadku worek staje się chwilowym wydawcą dla podanego przez użyt-kownika tematu.


Wszystkie aktywne procesy tworzą w przestrzeni nazw drzewo nazywane w doku-mentacji przez twórców grafem obliczeniowym (ang. Computation Graph).

Narzędzia

ROS zapewnia użytkownikowi szereg narzędzi ułatwiających poruszanie się po sys-temie plików, orientowanie się w istniejącym grafie obliczeniowym, śledzenie wyko-nania czy debugowanie. Są to między innymi:

• roscd, rosls służące do poruszania się po pakietach na poziomie systemuplików,

• rospack wyświetlający informacje o istniejących pakietach,

• rosgraph, rosnode, rosmsg wyświetlające aktualnie działające procesy, zależ-ności pomiędzy nimi i typy wiadomości oraz informacje na ich temat,

• rostopic pozwalający wypisać aktywne tematy oraz wiadomości w nich pu-blikowane,

• rosbag umożliwiający zapisanie wiadomości publikowanych do tematu i póź-niejsze ich odtworzenie,

• roswtf analizujący istniejącą instancję systemu pod kątem potencjalnych błę-dów i nieprawidłowości.

2.5.2 Orocos

Orocos (ang. Open RObot Control Software) [4] jest otwartą programową struk-turą ramową o architekturze komponentowej. Stanowi niejako uzupełnienie ROS-a,ponieważ jego głównym celem jest sterowanie robotami i maszynami w czasie rzeczy-wistym. Posiada podobne założenia co wspomniany system, tj. wielokrotne wyko-rzystanie raz napisanego kodu (komponenty), możliwość dokładania komponentóww trakcie wykonania i co za tym idzie zmiany zachowania systemu i ułatwieniewspółpracy między różnymi ośrodkami badawczymi poprzez możliwie jak najwięk-sze oderwanie implementacji od sprzętu.Orocos znajduje zastosowanie przede wszystkim w kontroli ruchu robota, ponieważROS, nieposiadający twardych ograniczeń czasowych, mógłby pozwolić na uszko-dzenie konstrukcji lub otoczenia.


Port wyjściowyPort wejściowyStrumień danych

Funkcja p

Komponent Funkcja przejściaPriorytet funkcji

Strumień danych

Argument funkcjiKomponentk

Kolejność

Wartość funkcji

Rysunek 2.10: Struktura komponentu w programowej strukturze ramowej DisCODe(źródło: [9])

2.5.3 IRPOS

Zespół Programowania Robotów i Systemów Rozpoznających opracował systemo nazwie IRPOS przeznaczony do sterowania robotami IRp-6. Rdzeniem stworzo-nego oprogramowania jest ROS, który zajmuje się komunikacją w obrębie systemui obsługą użytkownika. Zaimplementowane są w nim generatory trajektorii, dziękiktórym jest możliwe podanie jedynie punktów kluczowych ruchu i warunków końco-wych, m.in. prędkości, przyspieszenia. Do sterowania ruchem w czasie rzeczywistymzostały zastosowane komponenty Orocosowe. W skład pakietu wchodzi symulatorrviz, dzięki któremu możliwe jest testowanie oprogramowania bez fizycznego nara-żenia maszyny na uszkodzenia.Zastosowane rozwiązania powodują, że system jest przejrzysty, czytelny i łatwo gow razie potrzeby zmodyfikować.

2.5.4 DisCODe

DisCODe [8] (ang. Distributed Component Oriented Data Processing) jest pro-gramową strukturą ramową o architekturze komponentowej stworzoną w językuC++ przez członków Zespołu Programowania Robotów i Systemów Rozpoznają-cych dr. inż. Tomasza Kornutę i mgr. inż. Macieja Stefańczyka. Służy do przetwa-rzania danych sensorycznych (głównie wizualnych). Zadanie definiowane w plikuXML jest rozbijane na atomowe czynności, z których każda zajmuje się innym eta-pem przetwarzania. Przykładowo wykrycie obiektu w polu widzenia kamery składasię z: akwizycji obrazu, konwersji do skali szarości, wykrycia krawędzi, progowania iwyliczenia cech. Każda z tych czynności jest realizowana przez osobny komponent.W celu zwiększenia użyteczności raz napisanego kodu każdy z komponentów posiadawłasności (ang. Property), które można ustawić w pliku konfiguracyjnym zadania.Dzięki temu raz napisany komponent może być dostosowany do skrajnie różnychzadań wizyjnych.


Port wyjściowyPort wejściowy

Strumień danych

Nazwa

KomponentEgzekutorPodzadanie

Strumień danych

Nazwaegzekutorak

Kolejność Nazwapodzadania

Typ komponentu

Rysunek 2.11: Struktura zadania w programowej strukturze ramowej DisCODe (źró-dło: [9])

Oprócz własności każdy komponent posiada wejściowe i wyjściowe strumienie da-nych. W pliku konfiguracyjnym zadania użytkownik musi zdefiniować zależności po-między poszczególnymi elementami. Nawiązując do przykładu: obraz z kamery pozy-skiwany przez komponent związany z jej obsługą jest przekazywany do komponentuzajmującego się zmianą przestrzeni barw obrazu. Uogólnioną strukturę komponentuprzedstawia rysunek 2.10.Każdy komponent można przypisać do jednej z czterech kategorii w zależności odfunkcji, jaką pełni. Kategorie te to:

• źródła (ang. sources) zajmujące się pozyskaniem danych (z kamery, mikrofonulub dysku), przeważnie posiadające tylko jeden port wyjściowy,

• procesory (ang. processors) zajmujące się przetwarzaniem otrzymanych danychi posiadające przynajmniej po jednym porcie wejściowym i wyjściowym,

• odpływy (ang. sinks) wyświetlające lub zapisujące wyniki przetwarzania, prze-ważnie mające tylko porty wejściowe,

• pośredniki (ang. proxies) przesyłające dane do innych systemów, np. do ROS-a.

Plik definiujący zadanie musi zawierać:

• podzadania, w których znajdują się elementy wymienione w kolejnych dwóchpodpunktach,

• egzekutory będące oddzielnymi wątkami wykonującymi przypisane im kompo-nenty w sposób ciągły, okresowy lub aktywowany zdarzeniami,

• komponenty opisujące sposób wykonania podzadania,


Rysunek 2.12: Panel konfiguracyjny aplikacji FlyCap

• zależności pomiędzy strumieniami danych.

Definicja zadania została przedstawiona na rysunkach 2.11 oraz 2.13.

2.5.5 OpenCV

OpenCV [2] to otwarta (ang. open source) biblioteka przeznaczona do wizji kom-puterowej. Zawiera typy i struktury danych potrzebne do przechowywania informacjiwizualnych oraz implementuje wiele algorytmów przetwarzania obrazów o różnymstopniu skomplikowania. Jest podstawą większości komponentów zawartych w pro-gramowej strukturze ramowej DisCODe (sekcja 2.5.4).

2.5.6 FlyCap

Firma Point Grey udostępnia na swojej stronie [3] oprogramowanie dedykowanedla kamer, tj. sterownik systemowy, aplikację umożliwiającą przechwytywanie ob-razu i zmianę parametrów kamery (rysunek 2.12) oraz bibliotekę umożliwiającą pisa-nie własnego oprogramowania. Tę ostatnią wykorzystałem do napisania sterownikaprzeznaczonego dla platformy DisCODe, który opisałem w sekcji 2.4.


1 <Task>2 <Subtasks >3 <Subtask name="Processing">4 <Executor name="Exec1" period="0.1">5 <Component name="Source" type="CameraPGR:CameraPGR"

priority="1" bump="0">6 <param name="camera_serial">13481977 </param>7 <param name="frame_rate_mode">manual </param >8 <param name="frame_rate_value">10</param>9 </Component >

10 </Executor >11 </Subtask >12

13 <Subtask name="Visualisation">14 <Executor name="Exec2" period="0.05">15 <Component name="Window" type="CvBasic:CvWindow"

priority="1" bump="0">16 <param name="count">1</param >17 <param name="title">Obraz </param>18 </Component >19 </Executor >20 </Subtask >21 </Subtasks >22

23 <Events >24 </Events >25

26 <DataStreams >27 <Source name="Source.out_img">28 <sink>Window.in_img </sink>29 </Source >30 </DataStreams >31 </Task>

Rysunek 2.13: Przykładowa struktura zadania w DisCODe

Rozdział 3

Opis rozwiązania

W tym rozdziale zostały opisane poszczególne moduły tworzące system, zarównofizyczne (sekcja 3.1), jak i programistyczne (sekcje 3.2 i 3.3). Znalazły się w nim rów-nież opisy ścieżki przetwarzania obrazu (sekcja 3.2.4) i algorytmu podjęcia kamienia(sekcja 3.5).

3.1 Modyfikacja chwytaka

W celu umożliwienia podniesienia kamienia do gry konieczne było narzędzie opi-sane w sekcji 2.2, zaś by móc nim operować, potrzebna była modyfikacja chwytaka.Przy opracowywaniu modyfikacji było ważne, by zapewniała ona:

• przeniesienie siły z końcówki narzędzia na robota, co umożliwiłoby skorzysta-nie z czujnika i zatrzymanie ruchu po napotkaniu oporu,

• łatwość montażu,

• pewność chwytu,

• wyśrodkowanie narzędzia w osi x obrazu.

Najpierw stworzyłem drewniany prototyp (sekcja 3.1.1), by lepiej poznać specyfikęzadania i wykryć ewentualne dalsze wymagania. Jako druga powstała aluminiowamodyfikacja palców chwytaka przykręcana bezpośrednio do robota (sekcja 3.1.2).

3.1.1 Prototyp

Prototyp powstał z jednego kawałka drewna o grubości w przybliżeniu równejgrubości palców robota. Pierwsza wersja była zgrubnie opiłowana tak, by dopaso-wać ją do kształtu wnęki o trójkątnym przekroju. W części, do której miał przy-legać chwytak podciśnieniowy, było wyfrezowane gniazdo i otwór do wypuszczenia

23

24 ROZDZIAŁ 3. OPIS ROZWIĄZANIA

(a) Czoło części trzymającej(b) Czoło części trzymającej z włożonymw gniazdo chwytakiem podciśnieniowym

(c) Czoło części dociskającej (d) Chwytak podciśnieniowy w gnieździe

Rysunek 3.1: Części prototypu

końcówki. Całość miała trzymać się w palcach robota bez dodatkowych mocowań(rysunek 3.2).Szybko się okazało, że konstrukcji brakuje sztywności, więc zostały dołożone dwaprostokątne kawałki blachy aluminiowej dociśnięte do drewna za pomocą nakrętekosadzonych na nagwintowanym pręcie znajdującym się w nawierconym gnieździe.Całość została umiejscowiona w taki sposób, by nie stanowić przeszkody przy zaci-skaniu szczęk.W trakcie pierwszych testów wyniknął problem z wykrywaniem siły - chwytak pod-ciśnieniowy, zamiast przekazywać działającą na niego siłę do dalszych elementówkonstrukcji, wysuwał się ze swojego gniazda. Jako ograniczniki zostały powbijanemałe gwoździe zapobiegające ruchom na boki i do góry, na takiej wysokości, by nieprzeszkadzały w zaciskaniu się prototypu.Kolejne dwa problemy można było dostrzec po ściśnięciu gruszki narzędzia. Po pierw-sze ścięcie w dolnej części naciskacza było za niskie i powodowało ściśnięcie plasti-kowego elementu stanowiącego łącznik między przyssawką a gruszką, co skutkowałobrakiem nacisku na właściwą część chwytaka podciśnieniowego. Po drugie wysokieboki gniazda nie pozwalały na poprawne spłaszczenie gruszki, a co za tym idziewypuszczenie powietrza. Oba problemy zostały rozwiązane spiłowaniem naddatków(rysunek 3.1d).W czasie kolejnych testów okazało się, że robot nie jest w stanie ścisnąć narzędziawystarczająco mocno. Ten problem został rozwiązany poprzez zmniejszenie obszarunacisku za pomocą dwóch gwoździ, które wystawały z części naciskającej na około

3.1. MODYFIKACJA CHWYTAKA 25

0,3 cm (rysunek 3.1c). To rozwiązanie stworzyło kolejny problem: po ściśnięciu rurkawychodząca z narzędzia opierała się o krawędź otworu. Defekt ten powodował wy-krzywienie się konstrukcji, czego skutkiem było odchylenie przyssawki z pionowej osii w efekcie uniemożliwienie wykonania zadania. To również zostało rozwiązane zapomocą gwoździa wbitego w odpowiednie miejsce (rysunek 3.1b). Niestety gwoździez obu stron nie mogły znajdować się na tej samej wysokości z powodu nagwintowa-nego pręta do stabilizacji, który przechodził w przybliżeniu na tej samej wysokości,przez co wychylenie nie zostało do końca wyeliminowane.Ostatnią usterką prototypu był brak stabilnego mocowania elementu naciskającegow palcu chwytaka, czemu próbowałem zaradzić dodatkowym opiłowaniem trzyma-nej przez robota końcówki i obłożeniem jej taśmą izolacyjną. Niestety, efekt byłniewspółmierny do włożonego wysiłku. Wzbogacony o praktyczną wiedzę porzuci-łem prototyp i stworzyłem konstrukcję finalną opisaną w sekcji 3.1.2.

(a) Tył (wyżej) i przód (niżej)prototypu (b) Modyfikacja w szczękach manipulatora

Rysunek 3.2: Prototyp modyfikacji chwytaka

3.1.2 Model końcowy

Modyfikacja użyta w zadaniu powstała z aluminiowej listwy o grubości 2 mm,która została wygięta w odpowiednich miejscach. Nowy model składa się z dwóchoddzielnych elementów poprzykręcanych do gniazd na palcach chwytaka robota (ry-sunek 3.5). Narzędzie w pozycji otwartej chwytaka jest utrzymywane wyłącznie przezgumkę przechodzącą przez gniazda wypiłowane w bokach listwy, której końce nieposiadają już dodatkowego profilowania. Jej naciągnięciem można sterować poprzez


(a) Zdjęcie poglądowe konstruk-cji zmodyfikowanego chwytaka (b) Ogranicznik ruchu narzędzia

Rysunek 3.3: Model końcowy chwytaka

obracanie śruby przechodzącej przez jej pętle. Takie rozwiązanie ma i wadę, i zaletę:z jednej strony nawet stosunkowo niewielka siła wywarta na rurkę może spowodo-wać odchylenie narzędzia od prawidłowej osi, zaś z drugiej narzędzie jest w tensposób chronione przed uszkodzeniem w przypadku nieprawidłowości w wykonaniuprogramu lub odcięcia zasilania (robot IRp-6 Track wykazuje niską samohamownośćw pozycjach innych niż synchronizacji).Strefa nacisku, dzięki swojej relatywnie małej wysokości i dość dużej odległości odplastikowego elementu chwytaka podciśnieniowego, charakteryzuje się dużą spraw-nością. Przy zaciśniętych szczękach odchylenie końcówki narzędzia w osiach x i ykiści jest znikome.Przeniesienie siły w pozycji otwartej jest zapewnione przez ogranicznik ruchu do-kręcony do części utrzymującej chwytak podciśnieniowy (rysunki 3.3 i 3.4), z koleiw pozycji zamkniętej tarcie jest wystarczające duże, by uniemożliwić narzędziu prze-sunięcie się w chwycie.

(a) Dzięki śrubce znajdującej się w pętlimożna regulować naprężenie gumki

(b) Otwory na śruby mają większą śred-nicę od użytych śrub, dzięki czemu ułatwiająmontaż

Rysunek 3.4: Końcowy model modyfikacji montowanej na chwytaku

3.2. MODUŁ DISCODE 27

Rysunek 3.5: Końcowy model chwytaka zamontowany na robocie

3.2 Moduł DisCODe

W ramowej strukturze programowej DisCODe stworzyłem sterownik kamery Po-int Grey Blackfly i komponenty do przetwarzania danych i do komunikacji z syste-mem ROS. Napisałem również zadanie wizyjne, definiujące które komponenty majązostać włączone oraz sposób w jaki mają być połączone między sobą.

3.2.1 Sterownik kamery

W stworzonym sterowniku jedynym wymaganym do działania parametrem jestnumer seryjny kamery (camera_serial), bez którego oprogramowanie nie jest w sta-nie sparować się z urządzeniem. Pozostałe własności komponentu można podzielić nadwie grupy, z których jedna opisuje format obrazu, a druga nastawy kamery. Ponie-waż oprogramowanie producenta nie jest dedykowane dla jednego modelu, tylko dlacałej rodziny kamer ethernetowych, możliwe jest zastosowanie sterownika na innychmodelach. W takim przypadku jednak trzeba zadbać o poprawność parametrów,gdyż jego domyślne nastawy są dopasowane do konkretnego modelu.Do pierwszej grupy parametrów należą:

• pixel_format o możliwych wartościach RAW lub RGB, który mówi, jak mająbyć kodowane piksele tworzące obraz,


• width i height opisujące wymiary pozyskiwanego obrazu (dla zastosowanejkamery maksymalnie 1296 x 1032),

• offsetX i offsetY określające przesunięcie punktu początkowego obrazuw przypadku zażądania obrazu o wymiarach mniejszych niż maksymalne; mu-szą być podzielne przez 4.

W drugiej grupie znajdują się pary parametrów o nazwach zgodnych ze schematami<nazwa>_mode i <nazwa>_value, które wpływają na wygląd pozyskiwanego obrazu.Są to:

• brightness - zwiększenie czułości sensora skutkujące rozjaśnieniem całegoobrazu,

• exposure - korekcja ekspozycji,

• sharpness - parametr sterujący wysokoprzepustowym filtrowaniem obrazu naetapie wstępnego przetwarzania w celu wyostrzenia krawędzi,

• white_balance - balans bieli,

• hue - zmiana przestrzeni barw,

• saturation - sterowanie nasyceniem barw,

• gamma,

• frame_rate - ilość klatek na sekundę,

• shutter - długość czasu otwarcia migawki,

• gain - wzmocnienie (wysokie wartości zwiększają ilość szumów).

Dla parametrów o nazwach <nazwa>_mode poprawne są wartości manual orazprevious, dla niektórych również auto i/lub one_push. Pierwsza z nich jest ko-nieczna, jeśli ma być przekazana kamerze wartość liczbowa z <nazwa>_value,a ostatnia oznacza pojedyncze automatyczne dostosowanie nastawy. Oprogramo-wanie nie sprawdza poprawności podanych wartości, ponieważ niektóre z nich sąze sobą skorelowane i nie istnieje ryzyko uszkodzenia urządzenia. Użytkownikowizaleca się sprawdzenie ich poprawności w programie FlyCap (opisanym w rozdziale2) przed wprowadzeniem do zadania DisCODe’a. W przypadku podania niepopraw-nych wartości parametrów zostaną one odrzucone przez bibliotekę producenta lubnie zostanie rozpoczęte rejestrowanie obrazu przez kamerę.


3.2.2 Zastosowane algorytmy

Poniżej zostały pokrótce opisane najważniejsze algorytmy przetwarzania obra-zów zastosowane w pracy. Ponieważ dla opisu algorytmów działających na obraziebinarnym ma znaczenie, który z dwóch stanów niesie ze sobą informację, przyjmujesię, że obiekty mają barwę białą, zaś krawędzie czarną.

Progowanie adaptacyjne

Podstawowe progowanie (zwane również binaryzacją) przyjmuje próg, a następ-nie dla każdego piksela obrazu sprawdza, czy jego wartość jest większa lub równaczy mniejsza od progu. W pierwszej sytuacji rozpatrywany punkt przyjmuje wartośćmaksymalną, w drugiej minimalną, zatem obraz wynikowy staje się dwubarwny (bi-narny).Progowanie adaptacyjne jest rozwinięciem tej idei w stronę odporności na nie-równomierne oświetlenie sceny. Polega na podziale obrazu na regiony, z którychkażdy posiada własny próg. Użytkownik zamiast podać wartość progową podajerozmiar bloku (regionu) i metodę obliczania progu - w przypadku funkcji z biblio-teki OpenCV można wybrać średnią arytmetyczną lub średnią ważoną o wagachz okna gaussowskiego.

Filtracja rankingowa

Do realizacji trzech podzadań został stworzony komponent RankFiltering prze-prowadzający filtrację rankingową. Polega ona na stworzeniu okna analizy o wymia-rach 3x3 piksele, które jest przesuwane po całym obrazie. Po każdorazowym usta-wieniu okna w jakimś punkcie jest tworzona i sortowana lista wartości wszystkichpikseli z okna. Następnie aktualny piksel środkowy przyjmuje wartość znajdującąsię pod indeksem podanym przez użytkownika w pliku konfiguracyjnym. Kompo-nent jest przystosowany do pracy na obrazach o trzech (RGB) lub jednym (skalaszarości) kanałach.Filtracja rankingowa musi działać na dwóch obrazach jednocześnie: jednym do ana-lizy oraz jednym do zapisu wyniku operacji.

Dylacja

Operacja dylacji, czyli rozrostu, jest wykonywana na obrazach w skali szarości. Jestodpowiednikiem filtru typu maksimum, czyli przepuszczającego najwyższą wartośćz pasma. Ponieważ dylacja jest zwykle stosowana na obrazach binarnych (po spro-gowaniu), oznacza to, że jeśli którykolwiek z pikseli zawartych w oknie jest biały, to


aktualny element środkowy również taki będzie.Dylacja jest stosowana m.in. do redukcji szumów i ścieniania (ang. skeletonization).Może powodować przerwanie krawędzi obiektów na obrazie.

Erozja

Operacja erozji, podobnie do dylacji, jest wykonywana na obrazach w skali szarości,zwykle binarnych. Odpowiada filtrowi typu minimum. Jeśli którykolwiek z pikseliokna analizy jest czarny, to aktualny element środkowy na wynikowym obrazie rów-nież będzie czarny.Erozja może być stosowana do łączenia krawędzi. Może powodować rozrost szumówi utratę informacji.

Rozmycie

Rozmycie, będące filtracją dolnoprzepustową, ma na celu zmniejszenie szumóww przetwarzanym obrazie. Ponieważ zaciera wyraźne krawędzie, może prowadzićdo utraty informacji.

Wykrywanie okręgów

W programie został wykorzystany komponent CvHoughCircle z DCL (ang. Di-sCODe Component Library) CvBasic. Korzysta on z funkcji HoughCircles biblio-teki OpenCV, która ma dwa ważne kroki wykonania. W pierwszym z nich wy-krywa krawędzie w obrazie za pomocą algorytmu Canny’ego. Następnie korzystającz gradientowej transformacji Hougha, będącej uogólnieniem oryginalnej transfor-macji Hougha i działającej w zbliżony sposób, wykrywa trójki opisujące okręgi, tj.współrzędne x i y środka okręgu i jego promień.

3.2.3 Integracja z ROS

Ponieważ moduł DisCODe nie jest częścią systemu ROS, należało umożliwićprzepływ danych z zadania wizyjnego do głównego programu sterującego robotem.W tym celu powstały dwa komponenty opisane poniżej.

Rozłożenie obiektu

Ponieważ mogą wystąpić opóźnienia zarówno przy przesyłaniu wiadomościi w jednym, i w drugim module, konieczne było zapewnienie, że obie współrzędnenależą do środka tego samego okręgu. W tym celu powstał komponent Demux, który


przyjmuje i analizuje obiekt Types:Circles, następnie wybiera okrąg o najwięk-szym promieniu i rozdziela informacje o jego środku pomiędzy dwa komponentynależące do DCL-a ROSProxy.

ROSProxy

W bibliotece komponentów ROSProxy autorstwa mgr. inż. Macieja Stefańczykaznajduje się komponent IntProxy, który będąc częścią DisCODe’a, rejestruje sięrównocześnie jako węzeł systemu ROS i publikuje lub subskrybuje na podanyw konfiguracji temat. Ponieważ CvHoughCircles zwraca wektor okręgów zapisa-nych jako trzy wartości zmiennoprzecinkowe, konieczne było napisanie własnegopośrednika przekazującego wartości takiego typu. Nowy komponent został nazwanyFloatProxy. Ze względu na konieczność przekazania dwóch współrzędnych w zada-niu zawarte są dwa takie komponenty.

KameraCameraPGR

Konwersja do skaliszarosci

CvColorConv

RozmyciemedianoweRankFiltering

Progowanieadaptacyjne

CvAdaptiveThreshold

DylacjaRankFiltering

ErozjaRankFiltering

WykrywanieokręgówCvHoughCircles

Rozdzieleniewspółrzędnych

Demux

Współrzędna xFloatProxy

Współrzędna yFloatProxy

OknoCvWindow

Rysowanieokręgów

DrawDetectedCircles

Rysunek 3.6: Przepływ danych w zadaniu wizyjnym

3.2.4 Zadanie wizyjne

Struktura zadania wizyjnego została przedstawiona na rysunku 3.6. Prostokątyoznaczają wątki, owale komponenty, zaś zapisany małą czcionką tekst w owalu opi-suje użyty do danej czynności typ komponentu. Pierwszy komponent każdego eg-zekutora posiada bufor wejściowy typu tylko najnowszy, dzięki czemu działanie nanieaktualnych klatkach zostało niemal wyeliminowane.Obraz z kamery jest ograniczony do prostokąta o wymiarach 400x500 pikseli, byprzyśpieszyć jego przetwarzanie. Pierwszą operacją dokonywaną na obrazie jest jegokonwersja do skali szarości, ponieważ pojedynczy kanał obrazu wymaga mniej ob-liczeń niż trzy, a ponadto taki format jest wymagany przez komponent dokonującyprogowania adaptacyjnego.


W zadaniu zostało wykorzystane rozmycie medianowe mające na celu usunięcie szu-mów w obrazie, które mogłyby tworzyć fałszywe krawędzie. Ta operacja obejmujetrzy iteracje, dzięki czemu obraz przechodzący do kolejnego komponentu jest w dużejmierze pozbawiony zakłóceń. Ponieważ pozyskany obraz jest bardzo dobrej jakości,a sama operacja filtracji medianowej nie uszkadza w znaczący sposób krawędzi obiek-tów, jej wynikiem jest znaczące poprawienie parametrów analizowanej klatki.Jedynym kryterium wyboru kamienia jest długość promienia wykrytego okręgu. Po-nieważ w wybranej metodzie detekcji są narzucone ograniczenia na minimalny i mak-symalny promień znalezionego obiektu, możliwe jest uniknięcie fałszywych wykryć.Wyborem kamienia i przygotowaniem do wysłania współrzędnych jego środka zaj-muje się komponent opisany na rysunku 3.6 jako Rozdzielenie współrzędnych.

3.3 Moduł ROS

Główny program sterujący robotem został zrealizowany w języku Python jakowęzeł systemu ROS. Wykorzystuje on system IRPOS opisany w rozdziale 2. W mo-dule ROS można wyróżnić trzy elementy:

• modyfikacje istniejącego sterownika,

• klasę pomocniczą zarządzającą ruchem,

• główny program sterujący.

Układ współrzędnych kartezjańskich robota jest prawoskrętny, wyskalowanyw jednostkach SI. Jego początek wypada w środku podstawy kolumny, na którejznajduje się robot, oś x jest skierowana do taśmociągu będącego blatem roboczym,zaś oś z pionowo w górę. Orientację obiektu w układzie wyznacza się za pomocąznormalizowanego (o normie Euklidesowej równej 1) kwaternionu [7].

3.3.1 Modyfikacje systemu IRPOS

By umożliwić wykonanie zadania konieczne były następujące zmiany:

• w pakiecie irp6_robot:

– pliki konfiguracyjne irp6.ops oraz irp6-conv.ops - wyjścia odpowied-nich modułów ForceTransformation zostały podłączone do wejść odpo-wiednich modułów CartesianTrajectoryAction,

3.3. MODUŁ ROS 33

– pliki uruchamiające grupy procesów irp6.launch orazirp6-conv.launch - dla silnika sterującego zaciskaniem bądź otwiera-niem chwytaka zostały podniesione ograniczenia prądowe z 200 mA do250 mA,

– plik ForceSensor.cpp - ilość uśrednianych odczytów została zwiększonado pięciu,

• w pakiecie common_controlers - klasa CartesianTrajectoryAction zostałaprzekształcona w taki sposób, by pojedyncza wartość pobrana z czujnika siłynie przerywała zadanego ruchu, lecz dopiero trzy kolejne odczyty przekracza-jące próg.

3.3.2 Klasa pomocnicza

By poprawić przejrzystość kodu i przyspieszyć prace, do zarządzania ruchemrobota powstała klasa pomocnicza o nazwie ROSPyIrpMoveManager. Ponieważ po-wstała z myślą o tym konkretnym projekcie, nie przyjmuje kwaternionu opisującegoorientację efektora w metodzie odpowiedzialnej za ruch w układzie kartezjańskim.Zamiast tego korzysta z tego zdefiniowanego dla odpowiedniego robota. Zdefinio-wana orientacja odpowiada efektorowi skierowanemu pionowo w dół z kamerą odstrony blatu roboczego.Oprócz konstruktora klasa zawiera pięć metod przeznaczonych dla użytkownika. Sąto:

• jointMove(point, duration), gdzie point jest tablicą sześciu lub siedmiuw zależności od robota liczb zmiennoprzecinkowych, które wyrażają stany ko-lejnych stawów w radianach, a duration liczbą określającą czas w jakim ruchma się wykonać,

• xyzMove(point, duration, stopOnForceDetected, zForce, sleepDur),gdzie point jest obiektem klasy Point budowanym z trzech liczb zmiennoprze-cinkowych wyrażających przesunięcie końcówki narzędzia względem początkubazowego układu współrzędnych, duration - liczbą określającą czas, w jakimruch ma się wykonać, stopOnForceDetected - zmienną logiczną mówiąca czyruch ma się skończyć w przypadku wykrycia siły progowej w osi z efektora,zaś kolejne dwa argumenty są opcjonalne i wyrażają odpowiednio wartość siłyprogowej oraz długość okresu uśpienia przeznaczonego na kalibrację czujnikasiły przed wykonaniem ruchu,


• toolMove(point, duration), gdzie point jest tablicą zawierającą jednąliczbę zmiennoprzecinkową będącą współrzędną silnika zaciskającego szczękichwytaka, a duration liczbą określającą czas w jakim ruch ma się wykonać,

• toolConfig(point), gdzie point jest obiektem klasy Point, budowanymz trzech liczb zmiennoprzecinkowych określających aktualne przesunięcie koń-cówki narzędzia od początku układu współrzędnych nadgarstka; funkcja in-formuje sterowniki o położeniu końca efektora względem robota, by ruch wewspółrzędnych kartezjańskich mógł się wykonać w prawidłowy sposób.

• finish() - kończy działanie programu, wyłączając ostatni włączony generator.

Klasa dba o to, by wyłączać nieużywane sterowniki tak, by nigdy nie zdarzyłosię, że dwa są uruchomione w tym samym czasie.

3.3.3 Program

Program jest podzielony na funkcje, z których każda odpowiada pewnemupodzadaniu. Są zatem funkcje odpowiedzialne za złapanie lub wypuszczeniekamienia, mocząca przyssawkę chwytaka podciśnieniowego, przenoszące do punktuobserwacyjnego, nad wybrany kamień lub ponad miejsce odłożenia. Nietrywialnąfunkcją w programie głównym jest wyliczenie pozycji wybranego kamienia w ukła-dzie współrzędnych robota na podstawie współrzędnych obrazu.Dzięki temu, że położenie kamery i poszczególnych elementów stanowiska jestznane a priori, w programie można wpisać zależną od robota skalę, czyli ilośćpikseli przypadających na jeden centymetr na poziomie wierzchu pojemnika. Przywyliczaniu przesunięcia należało uwzględnić fakt, że środek narzędzia wypada naśrodku dolnej krawędzi pojemnika.

Obliczenia są dokonywane w następujący sposób:

xr =−(x) + szer

2.0

skala· 0.01 (3.1)

yr =wys− (y)

skala· 0.01 (3.2)

gdzie x i y to współrzędne środka okręgu na obrazie, wys i szer to wymiary obrazu,skala to ilość pikseli przypadających na jeden centymetr, zaś xr i yr to rzeczywisteprzesunięcie robota w metrach w układzie współrzędnych kamery, tj. xr odpowiadaprzesunięciu na osi y robota, a yr na osi x robota.

3.4. STANOWISKO ROBOCZE 35

(a) Wymiary pojemnika są w przybliżeniurówne 110x90x20mm

(b) Pojemnik wypełniony kamieniami przy-gotowany do ustawienia na stanowisku

Rysunek 3.7: Wykorzystany pojemnik

Program pomocniczy

Istnieje program pomocniczy o nazwie initialize.py, który należy uruchomićprzed rozpoczęciem zadania, w przypadku gdy stanowisko lub robot nie są jeszczeprzygotowane. Ustawia on robota w pozycji obserwacji, która umożliwia dokręceniemodyfikacji chwytaka i ustawienie elementów stanowiska w prawidłowy sposób. Po-nieważ system nie lokalizuje pojemnika, konieczne jest, by w całości znajdował sięw prawidłowym położeniu w polu widzenia kamery.

3.4 Stanowisko robocze

Ze względu na bezpieczeństwo wszystkich przedmiotów wykorzystanych w zada-niu oraz ujednolicenie oświetlenia podejmowanych obiektów został wybrany płytkipojemnik o jednolitej, różnej od podejmowanych obiektów barwie (rysunek 3.7).Jako podejmowane obiekty zostały wykorzystane plastikowe kamienie w styluchińskim, tj. o płaskiej podstawie i wypukłej górze (rysunek 3.8). Są lżejsze odszklanych, więc pewniej się trzymają chwytaka podciśnieniowego, zaś ich kształtpowoduje, że łatwiej robotowi złapać jeden bez rozsuwania pozostałych.


(a) Podwyższenie stanowi jedynie wizualnewyróżnienie przestrzeni operacyjnej

(b) Na podwyższeniu koło pojemnika jestpuste miejsce na odkładane kamienie

Rysunek 3.9: Stanowisko robocze systemu

Rysunek 3.8: Plastikowe kamienie do go

W trakcie testów okazało się, że choć robot jest w stanie chwycić kamienie, toz powodu ich chropowatej powierzchni nie jest w stanie poruszyć się wystarczającoszybko i bezpiecznie, by je odłożyć zanim same odpadną od przyssawki. By temuzapobiec, końcówka narzędzia jest maczana w wodzie. Dzięki takiemu rozwiązaniukamienie trzymają się pewnie i się nie brudzą, jak by się działo w przypadku gdybymedium uszczelniającym był olej.Stanowisko pracy składa się z małego postumentu, do którego prawej (z punktu wi-dzenia robota) krawędzi przylega pojemnik z kamieniami. Pojemnik jest ustawionytak, by w pozycji, z której robot dokonuje wyboru podejmowanego kamienia, koń-cówka narzędzia znajdowała się w miarę możliwości najdokładniej nad środkiem jegodolnej krawędzi. Tuż obok postumentu, również z prawej strony z perspektywy ro-bota, znajduje się podwyższenie, na którym jest naczynie z wodą. Obok pojemnikaz kamieniami na postumencie znajduje się wolne miejsce, w które robot odkładapodjęte kamienie. Całość jest dokładnie zaprezentowana na rysunku 3.9.

3.5. SCHEMAT DZIAŁANIA 37

Inicjalizacja

Zamocz narzędzie

Przyjmij pozycjęobserwacyjną

Zaczekaj naaktualny odczyt Oblicz pozycję

Podejmij kamień Ustaw się nadkamieniem

DisCODe

Współrzędna x Współrzędna y

Podjęcie jednego kamienia

Odłóż kamień

Rysunek 3.10: Schemat działania programu

3.5 Schemat działania

Ogólny schemat działania systemu został przedstawiony na rysunku 3.10. Liniaprzerywana oznacza transmisję asynchroniczną, tj. kamienie są wyszukiwane nie-przerwanie, a dane o środku największego ze znalezionych okręgów są wysyłaneza każdym razem, kiedy zostają wyliczone. Ponieważ moduł DisCODe jest wykony-wany na innej maszynie niż moduł ROS-a, nie ma to znaczącego wpływu na szybkośćdziałania modułu sterującego ruchem robota. Początkowa inicjalizacja systemu jestruchem we współrzędnych stawowych manipulatora i ma na celu upewnienie się, żerobot nie znajdzie się w osobliwości powodującej jego nieprzewidywalne zachowanie.Trzy z wyszczególnionych etapów korzystają z tego samego schematu ruchu, tj.ustawienia się nad lokalizacją docelową i powolnego opuszczenia efektora w wybranypunkt. Są to: zamoczenie narzędzia, podjęcie i odłożenia kamienia. Taki ruch ma tra-jektorię rozłożoną na 20 sekund, co ma na celu uniknięcie przeciążeń wpływającychna odczyty siły. W ciągu tego okresu czasu przyssawka chwytaka podciśnieniowegopowinna pokonać około 8 centymetrów i napotkać opór, który powoduje zatrzymanieruchu. W przypadku niewystąpienia siły hamującej wykona się pełna trajektoria, tj.ruch o 10 cm pionowo w dół.W systemie zostało zastosowane podejście pojedynczego spojrzenia (ang. look andgo), tj. nie są dokonywane jakiekolwiek korekty pozycji po pierwszym wyliczeniutrajektorii dla wybranego kamienia.


Kod głównej funkcji programu realizującej wybrany schemat działania wraz z opisemznaczenia poszczególnych linii został zamieszczony poniżej.

155 if __name__ == ’__main__ ’:

156 rospy.init_node(’grip_stone ’)

157 moveMan = ROSPyIrpMoveManager(ROBOT)

158

159 rospy.Subscriber(’/center_x ’, Float32 , xCallback)

160 rospy.Subscriber(’/center_y ’, Float32 , yCallback)

161 rospy.sleep (1.)

162

163 initialize ()

164 moveMan.toolConfig(Point (0.0, 0.0, 0.375))

165 wetGripper ()

166

167 for i in range(1, 6):

168 print "%d. proba" %(i)

169 moveToLook ()

170 waitForReading ()

171 countPosition ()

172 prepareForPickUp ()

173 moveToPickUp ()

174 pickUp ()

175 testGrip(i)

176

177 moveMan.finish ()

155 - jeśli plik został uruchomiony jako program, należy wykonać kolejne linie,

156 - rejestracja węzła ROS-owego,

157 - stworzenie obiektu klasy pomocniczej dla konkretnego robota,

159-160 - zasubskrybowanie się do tematów przekazujących współrzędne środkanajwiększego znalezionego okręgu,

163 - ruch we współrzędnych stawowych, który zapewnia ominięcie osobliwościkinematycznej,

164 - ustawienie w generatorach pozycji narzędzia,

165 - zamoczenie narzędzia,

167-175 - pętla wykonująca 5 prób podjęcia kamienia,

169 - ustawienie robota w pozycji obserwacyjnej,

3.5. SCHEMAT DZIAŁANIA 39

170 - odczekanie 5 sekund w celu upewnienia się, że odczyt jest aktualny,

171 - wyliczenie współrzędnych obiektu w bazowym układzie współrzędnych,

172 - ustawienie się nad obiektem,

173 - opuszczenie narzędzia w kierunku obiektu do momentu wykrycia kontaktu,

174 - schwytanie kamienia chwytakiem podciśnieniowym i podniesienie narzędziado góry,

175 - odłożenie podjętego kamienia na bok,

179 - wyłączenie ostatniego generatora.

Rozdział 4

Wyniki i wnioski

W tym rozdziale znajduje się opis kalibracji systemu (sekcja 4.1), wyniki jegotestów (sekcja 4.2) oraz wnioski końcowe z projektu (sekcja 4.3).

4.1 Strojenie systemu

Stworzony w ramach niniejszej pracy system należało dostosować do istniejącychwarunków. Konieczne było prawidłowe ustalenie parametrów akwizycji obrazu, de-tekcji obiektów oraz wprowadzenie korekt do wyliczenia rzeczywistych współrzęd-nych podejmowanego kamienia. W sekcji 4.1.1 przedstawiam sposób ich dobrania wzadaniu wizyjnym, a w sekcji 4.1.2 w głównym programie sterującym.

4.1.1 Eksperymenty wizyjne

Najlepsze parametry akwizycji i przetwarzania obrazu zostały wybrane w spo-sób eksperymentalny. Konkretne wartości parametrów zadania wizyjnego są silniezależne od warunków oświetleniowych. W związku z tym istnieją dwa zadania,po jednym dla każdego z robotów, ponieważ pozycja stanowiska wypada inaczejwzględem lamp je oświetlających. Porównanie długości otwarcia migawek znajdujesię na rysunku 4.1. Dla białych pionów zbyt długo naświetlany obraz skutkujezanikiem krawędzi i niewykryciem kamieni. W przypadku czarnych różnica jestkosmetyczna, choć najwygodniejszymi dla operatora parametrami zdają się być 120ms otwarcia migawki i wzmocnienie sygnału o 2 dB.

Porównanie różnych wartości parametrów komponentu wykrywającego okręgiznajduje się na rysunku 4.2. Niektóre z nich dają efekt nienadający się do wyko-rzystania w sposób praktyczny, np. wielokrotne wykrycie tego samego okręgu lub

41

42 ROZDZIAŁ 4. WYNIKI I WNIOSKI

(a) 80 ms (b) 100 ms

(c) 120 ms (d) 100 ms

(e) 120 ms (f) 120 ms i 2 dB wzmocnienia sygnału

Rysunek 4.1: Różne nastawy długości otwarcia migawki

wykrycie nieistniejących. Na podstawie dokonanych eksperymentów wybrałem na-stępujące wartości:

• minDist=50,

• cannyHigherThreshold=250,

• accumulatorThreshold=24,

• minCircleRadius=30,

• maxCircleRadius=65.

4.1.2 Testowanie systemu

Stworzony system był testowany na obu manipulatorach IRp-6 będących własno-ścią Zespołu Programowania Robotów i Systemów Rozpoznających. Do końcowegozastosowania zalecany jest robot nazwany Postument z powodu dokładniejszegoczujnika siły. Szumy występujące na odczytach z drugiego manipulatora, Tracka,skutkowały koniecznością zwiększenia progu siły potrzebnej do zatrzymania robota.Powodowało to zwiększony nacisk na kamienie i, nawet przy dobrym podejściu dopodjęcia, mogło skończyć się nieudaną próbą z powodu ześlizgnięcia się narzędzia nadno pojemnika. Dokładniejsze odczyty siły Postumenta pozwoliły na niemal dwu-krotne zmniejszenie siły progowej, której wartość została ustalona na 1,5 N.W trakcie pierwszych testów systemu okazało się, że konieczne jest wprowadzenie

4.1. STROJENIE SYSTEMU 43

(a) Wybrane nastawy detek-tora

(b) accumulatorThreshold15,

(c) accumulatorThreshold20,

(d) maxCircleRadius 165 (e) minDist 10 (f) minCircleRadius 10

Rysunek 4.2: Porównanie różnych wartości parametrów detektora

do wyliczania współrzędnych rzeczywistych środka obiektu korekty kompensującejniedoskonałość montażu kamery oraz nieznaczne, nieskorygowane na etapie rejestra-cji obrazu dystorsje, tzw. efekt rybiego oka. Spowodowało to zmianę formy obliczeńprzytoczonych w rozdziale 3 do następującej:

xkor =x

szer· 85 (4.1)

ykor = (1− y

wys) · (−50) +

|x− szer2|

szer2

· (−50) (4.2)

xr =−(x+ xkor) +

szer2

skala· 0.01 (4.3)

yr =wys− (y + ykor)

skala· 0.01 (4.4)

gdzie xkor i ykor oznaczają korekty, wys i szer rozmiary obrazu, a xr i yr przesu-nięcie w jednostkach SI, jakie musi wykonać narzędzie. Ostatnie dwie są w układziewspółrzędnych obrazu, co znaczy, że robotowi należy przekazać je na odwrót, tj. yrjest przesunięciem na osi x robota, a xr na osi y.


(a) Moczenie narzędzia (b) Podjęcie kamienia (c) Odłożenie kamienia

Rysunek 4.3: Poprawnie wykonane najważniejsze ruchy

(a) Narzędzie nie naciska idealnie na środekkamienia

(b) Próba jest udana mimo częściowego we-pchnięcia kamienia głębiej

Rysunek 4.4: Podjęcie ze środka pojemnika

4.2 Wyniki

Stworzona sekwencja ruchów: zamocz, popatrz, podnieś, odłóż jest prawidłowozaprojektowana (rysunek 4.3). Zamoczenie końcówki narzędzia znacząco poprawiapewność, z jaką narzędzie chwyta kamień. Z obserwacji wynika, że namoczenie po-winno być powtarzane po około 10 próbach podjęcia.System charakteryzuje się wysoką skutecznością, gdy podejmowane kamienie znaj-dują się w pozycji poziomej i są od spodu podparte (rysunek 4.4). Manipulatorowirzadko udawało się podjąć kamień mający jedynie częściowe podparcie (np. z po-wodu opierania się z jednej strony o krawędź pojemnika) - rysunki 4.5 oraz 4.6.Zamiast tego zsuwał go niżej, co samo w sobie nie jest złym zjawiskiem - w ten spo-sób sam tworzył nowe możliwości podjęcia. System osiągałby lepsze wyniki, gdybymógł posiadać jeszcze niższą wartość siły progowej, lecz testy wykazały, że jest onanieosiągalna. Dla wartości niższych od 1,5 N robot zatrzymywał ruch natychmiastpo jego rozpoczęciu, co z punktu widzenia obserwatora wyglądało, jakby ruch nigdynie nastąpił. Ponadto możliwa jest modyfikacja algorytmu dokonującego wyboru ka-mienia tak, by faworyzował on te znajdujące się najbliżej środka obrazu (a zatemrównież najbliżej środka pojemnika).

4.3. WNIOSKI 45

(a) Wybrano kamień przybrzegu

(b) Kamień nie jest podpartyod strony ścianki

(c) Próba podjęcia kończy sięwepchnięciem go głębiej

Rysunek 4.5: Nieudane podjęcie skrajnego kamienia

(a) Wybrano kamień przybrzegu

(b) Kamień jest podparty odstrony ścianki

(c) Próba zakończona powo-dzeniem

Rysunek 4.6: Udane podjęcie skrajnego kamienia

W aktualnym stadium rozwoju system nie dokonuje sprawdzenia, czy podjęta próbazakończyła się sukcesem, lecz w przyszłości można go rozwinąć, dodając tę funkcjo-nalność poprzez zwiększenie obszaru rejestrowanego przez kamerę tak, by obejmowałon również końcówkę efektora i sprawdzając jego stan w dwóch punktach pokonywa-nej trajektorii po próbie podjęcia. Powiększony obraz można by w pierwszym etapieprzetwarzania dzielić na dwa obszary, które byłyby analizowane oddzielnie, dziękiczemu nakład obliczeniowy nie uległby znacznemu zwiększeniu.Wielokrotne wykonywanie programu skutkuje przeniesieniem do pojemnika ilościwody wystarczającej do spowodowania przywierania kamieni do dna. W przypadkurozwijania projektu zaleca się zastosowanie pojemnika porowatego lub z otworemodprowadzającym.

4.3 Wnioski

Realizacja projektu zakończyła się sukcesem, choć stworzony system nie jestdoskonały. Można go ulepszyć wprowadzając poprawki opisane w sekcji 4.2, a na-stępnie użyć do rozegrania gry z prawdziwym graczem lub jako część zupełnie innegosystemu wykorzystującego podobną sekwencję ruchów. Uważam, że projekt był do-skonałym wprowadzeniem do tematyki robotów usługowych.

Bibliografia

[1] http://automatykaonline.pl/w-fabryce-volvo-beda-pracowac-roboty-abb.

[2] Dokumentacja OpenCV. http://docs.opencv.org.

[3] Oficjalna strona firmy Point Grey. http://ptgrey.com.

[4] Oficjalna strona Orocosa. http://www.orocos.org/.

[5] Oficjalna strona ROS-a. http://www.ros.org/.

[6] Oficjalna strona Zespołu Programowania Robotów i Systemów Rozpoznają-cych. http://robotyka.ia.pw.edu.pl.

[7] John J. Craig. Wprowadzenie do robotyki: mechanika i sterowanie. Wydawnic-twa Naukowo-Techniczne, wydanie 2, 1995.

[8] Tomasz Kornuta, Maciej Stefańczyk. DisCODe: komponentowa struktura ra-mowa do przetwarzania danych sensorycznych. Pomiary Automatyka Robotyka,16(7-8):76–85, 2012.

[9] Tomasz Kornuta, Maciej Stefańczyk, Michał Laszkowski, Maksym Figat, JanFigat, Cezary Zieliński. Obsługa asynchronicznego przepływu danych w kom-ponentowych podsystemach percepcji robotów. Pomiary – Automatyka – Ro-botyka PAR, 18(3), 2014.

[10] Tomasz Pokorski. Robot IRp-6 grający w kości. Praca inżynierska, PolitechnikaWarszawska, Wydział Elektroniki i Technik Informacyjnych, 2012.

47

http://automatykaonline.pl/w-fabryce-volvo-beda-pracowac-roboty-abb

http://docs.opencv.org

http://ptgrey.com

http://www.orocos.org/

http://www.ros.org/

http://robotyka.ia.pw.edu.pl

Podejmowanie pionów za pomocą robota manipulacyjnego IRp-6 ...

Documents

Transcript of Podejmowanie pionów za pomocą robota manipulacyjnego IRp-6 ...