PRACADYPLOMOWAINŻYNIERSKA - … · rok akademicki 2015/2016 politechnika warszawska wydziaŁ elektroniki i technik informacyjnych instytut automatyki i informatyki stosowanej pracadyplomowainŻynierska

Rok akademicki 2015/2016

POLITECHNIKA WARSZAWSKA

WYDZIAŁ ELEKTRONIKI I TECHNIK INFORMACYJNYCH

INSTYTUT AUTOMATYKI I INFORMATYKI STOSOWANEJ

PRACA DYPLOMOWA INŻYNIERSKA

Maciej Safarzyński

Przegląd środowisk programistycznych dla LEGO

Mindstorms EV3, z weryfikacją robotem

układającym Kostkę Rubika

Opiekun pracy:dr inż. Tomasz Winiarski

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

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

Data i podpis Przewodniczącego

Komisji Egzaminu Dyplomowego

2

Streszczenie

Celem pracy był przegląd różnych środowisk programistycznych dla LEGO Mind-storms EV3. Przegląd miał charakter praktyczny, bowiem opierał się na stworzeniuprogramu robota zbudowanego z LEGO Mindstorms. Robot miał za zadanie układaćkostkę Rubika. Zadanie to zostało zrealizowane, poprzez napisanie trzech programóww środowiskach, ROBOTC, ev3dev oraz Matlab. Wszystkie trzy programy pomimorealizacji w różnych językach programistycznych łączy ta sama funkcjonalność.

Słowa kluczowe: Mindstorms EV3, ROBOTC, Matlab, ev3dev, Kostka Rubika.

Abstract

Title: Overview of programming environments for LEGO Mindstorms EV3, verifiedby Rubik’s Cube solving robot.

The aim of this thesis was an overview of different programming environmentsfor LEGO Mindstorms EV3. The overview had a practical nature, because it wasbased on the creation of a program for the robot built with LEGO Mindstorms. Robotbuilt with LEGO had the task of solving Rubik’s cube. This task was accomplishedby writing three programs in environments, ROBOTC, ev3dev and Matlab. All threeprograms despite the implementation in different programming languages share thesame functionality.

Keywords: Mindstorms EV3, ROBOTC, Matlab, ev3dev, Rubik’s cube.

4

Spis treści

1 Wstęp 7

1.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Motywacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Struktura pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Wykorzystane technologie 13

2.1 Wykorzystany sprzęt . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 LEGO Mindstorms EV3 Education Core Set . . . . . . . . . . 13

2.1.2 Kostka Rubika . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Wykorzystane algorytmy . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Wykorzystane oprogramowanie . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 ROBOTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.2 Matlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.3 ev3dev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Projekt systemu 23

3.1 Przebieg zadania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Założenia projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Realizacja 31

4.1 Implementacja w środowisku ROBOTC . . . . . . . . . . . . . . . . . 31

4.1.1 Główna pętla programu - plik “main“ . . . . . . . . . . . . . . 31

4.1.2 Moduł zmiennych globalnych - plik “globals“ . . . . . . . . . . 32

4.1.3 Moduł manipulacji - plik “manipulate“ . . . . . . . . . . . . . 32

4.1.4 Moduł kalibracji - plik “calibrate“ . . . . . . . . . . . . . . . . 33

4.1.5 Moduł wyświetlania - plik “display“ . . . . . . . . . . . . . . . 33

4.1.6 Moduł skanowania - plik “scan_cube“ . . . . . . . . . . . . . . 33

4.1.7 Moduł rozwiązywania - plik “solve“ . . . . . . . . . . . . . . . 33

4.1.8 Moduł skanuj i rozwiąż - plik “scan_and_solve“ . . . . . . . . 34

5

6 SPIS TREŚCI

4.2 Próba implementacji w środowisku Matlab . . . . . . . . . . . . . . . 344.3 Implementacja w systemie ev3dev . . . . . . . . . . . . . . . . . . . . 35

4.3.1 Moduł zmiennych globalnych - plik “globals“ . . . . . . . . . . 354.3.2 Moduł manipulacji - klasa “manipulate“ . . . . . . . . . . . . 364.3.3 Moduł kalibracji - klasa “calibrate“ . . . . . . . . . . . . . . . 364.3.4 Moduł wyświetlania - klasa “display“ . . . . . . . . . . . . . . 364.3.5 Moduł skanowania - klasa “scan_cube“ . . . . . . . . . . . . . 374.3.6 Moduł rozwiązywania - klasa “solver“ . . . . . . . . . . . . . . 374.3.7 Moduł skanuj i rozwiąż - klasa “scan_and_solve“ . . . . . . . 37

5 Podsumowanie 39

5.1 Wyniki analizy porównawczej . . . . . . . . . . . . . . . . . . . . . . 395.2 Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2.1 Charakterystyka projektów dla środowiska ROBOTC . . . . . 415.2.2 Charakterystyka projektów dla środowiska ev3dev . . . . . . . 415.2.3 Charakterystyka projektów dla środowiska Matlab . . . . . . . 425.2.4 Wniosek ogólny . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Bibliografia 45

Rozdział 1

Wstęp

Rozdział ten zawiera wprowadzenie do tematyki pracy (sekcja 1.1), motywacjęautora do napisania pracy (sekcja 1.2), cel pracy (sekcja 1.3) oraz opisuje jej struk-turę (sekcja 1.4).

1.1 Wprowadzenie

Praca ta jest ściśle związana z zagadnieniem robotyki. W celu właściwego odbiorupracy warto na wstępie wyjaśnić znaczenie terminu “robotyka“, a najłatwiej to zrobićzaczynając od definicji słowa “robot“. Według definicji wprowadzonej w 1979 rokuprzez Robotics Industries Association, “robot“ to: “Programowalny, wielofunkcyjnymanipulator zaprojektowany do przenoszenia materiałów, części, narzędzi lub specja-lizowanych urządzeń poprzez różne programowalne ruchy, w celu realizacji różnorod-nych zadań“. [3] Natomiast szersze pojęcie “robotyki“ dr inż. Wojciech Szynkiewicztłumaczy: “Robotyka zajmuje się projektowaniem, budową, badaniem i wykorzysta-niem robotów“. [11]

Robotyka jest jedną z najszybciej rozwijających się technologii dzisiejszych cza-sów. Zakres jej zastosowań jest coraz większy, a ilość dziedzin, w których wyspecjali-zowane roboty zastępują człowieka stale się rozszerza. Niemniej jednak robotyka jestniezwykle złożoną dziedziną nauki. Przede wszystkim ze względu na to, że zawartyjest w niej szereg bazowych, acz skomplikowanych dyscyplin takich jak: mechanika,elektronika, matematyka, automatyka, informatyka, czy nawet biologia. Biorąc poduwagę tak wielopłaszczyznowy zakres tematów, ilość ekspertów w tej dziedzinie jestbardzo ograniczona. Jednocześnie w obecnych czasach znacząco rośnie zapotrzebo-wanie na specjalistów właśnie z zakresu robotyki.

Aby poradzić sobie z tym problemem, a zarazem wzbudzić zainteresowanie te-matem w jak najszerszym gronie, na rynku pojawia się coraz więcej uproszczonych

7

8 ROZDZIAŁ 1. WSTĘP

platform robotycznych. Uproszczenie oznacza przede wszystkim, że producenci two-rzą gotowe lub nieskomplikowane w złożeniu roboty, dostępne dla szerokiej rzeszyodbiorców w tym amatorów.

Roboty dają swoim twórcom ogromne perspektywy rozwoju. Ich uniwersalnośćpolega głownie na dostarczeniu użytkownikom narzędzi, które ułatwiają procesprogramowania robotów, równocześnie nie ograniczając mnogości ich przeznaczeń.Dzięki temu tak złożony temat jakim jest robotyka staje się po części dostępny na-wet dla laików, rozbudza zainteresowanie, chęć zgłębiania zagadnienia, a co za tymidzie zwiększa szanse i możliwości dla profesjonalnego rozwoju tej dyscypliny.

Rysunek 1.1: Zestaw LEGO Mindstorms EV3 Education Core Set.

Jedną z takich przystępnych platform jest LEGO Mindstorms. Rozwijana od1998 roku seria zestawów, łączący klocki LEGO z czujnikami elektronicznymi, ser-womechanizmami i komputerową jednostką centralną. Technologia pozwala międzyinnymi na konstruowanie robotów i układów automatyki oraz na ich odpowiednieoprogramowywanie. Najnowszym produktem z serii jest LEGO Mindstorms EV3wprowadzonym na rynek w 2013 roku. Użycie klocków LEGO jako głównego bu-dulca robotów, oraz dostarczenie użytkownikowi intuicyjnych narzędzi do tworzeniaoprogramowania, spowodowało, że technologia ta znajduje odbiorców nawet wśróddzieci. To wspaniały sposób na wprowadzanie młodych ludzi w świat robotyki. Jed-nocześnie platforma Mindstorms ma na tyle nieograniczone zastosowania, że po-zwala na budowę całego spektrum dużo bardziej skomplikowanych i wielofunkcyj-nych robotów dla bardziej zaawansowanych użytkowników. Właśnie dla nich rozwi-jany jest szereg profesjonalnych środowisk programistycznych, przez niezależne odgrupy LEGO, firmy, koła projektowe, czy osoby prywatne. Organizacje te nie mają

1.2. MOTYWACJA 9

żadnego komercyjnego związku z firmą produkującą Mindstorms, jednak ich pracajest przez grupę LEGO wspierana i leży w interesie twórców platformy Mindstorms.Jeden z produktów linii Mindstorms przedstawiony jest na rysunku 1.1.

1.2 Motywacja

W dzisiejszych czasach zastosowanie robotów wiąże się coraz ściślej z niemalkażdą dziedziną nauki i życia. Roboty obecne są w życiu codziennym, podczas pro-stych czynności i zabaw, ale również w najbardziej skomplikowanych działaniachtakich jak operacje chirurgiczne [1], badanie dna oceanów [2], czy eksploracja ko-smosu [9]. Proces tworzenia i konstrukcji robotów, uzależniony od funkcji jaką mająspełniać, poza projektem technicznym, opiera się na środowisku programistycznym,w którym dany robot jest programowany. To właśnie środowisko decyduje o skalimożliwości i przeznaczeniu danego robota. Uściślając “środowisko programistyczneto aplikacja lub zespół aplikacji służących do tworzenia, modyfikowania, testowa-nia i konserwacji oprogramowania“ [12], jest to zatem miejsce, w którym tworzonyjest swoisty “umysł“ przypisany do konkretnego urządzenia, “umysł“ który wydajerozkazy, wyznacza zadania i steruje precyzją ich wykonania.

Środowisko programistyczne i związany z nim ściśle język programowania wpływazatem bezpośrednio na łatwość samego procesu programowania. Środowisko wrazz językiem dostarczają programiście narzędzi, od których zależy czy proces opro-gramowania robota będzie przebiegał sprawnie, wygodnie i szybko, oraz czy ogólnezałożenia programowe da się w technologiach dostarczanych przez środowisko zre-alizować.

Co ważne środowiska różnią się od siebie dostarczając programistom bardziej lubmniej zaawansowanych bibliotek języków programowania. W związku z tym zreali-zowanie pewnej funkcji robota może wymagać mniej lub więcej czasu oraz linii koduźródłowego. W skrajnych przypadkach może stać się wręcz niemożliwe wykonaniepewnych programów, które w innych środowiskach byłyby wykonalne. Oprócz tegośrodowisko może dostarczać szeregu narzędzi służących do kompilacji programu, de-bugowania, testowania, przesyłania programu na urządzenie, komunikacji z robotem,wykonywania poleceń zdalnych, czy eksplorowania plików robota. Narzędzia te mogąbyć bardziej lub mniej wygodne w zależności od jakości środowiska. Zbiór narzędzidostępnych w danym środowisku oraz ich jakość ma decydujący wpływ na to do ja-kich projektów dane środowisko się nadaje oraz decyduje o wygodzie pracy. Dlategotak istotny jest dobór odpowiedniego środowiska programistycznego do konkretnegoprojektu.


1.3 Cel pracy

Celem pracy jest przegląd trzech różnych środowisk programistycznych przezna-czonych dla technologii LEGO Mindstorms EV3. Robot LEGO Mindstorms zostałsamodzielnie złożony, a następnie został dla niego napisany program po kolei w każ-dym z trzech środowisk.

Rysunek 1.2: Rubik solver - robot układający Kostkę rubika.

Przedmiotem testowania środowisk programistycznych jest robot “Rubik Solver“,który samodzielnie układa Kostkę Rubika. Robot otrzymuje Kostkę w stanie pomie-szanym, następnie skanuje kolejne kolory pól Kostki, oblicza optymalną najmniejsząilość ruchów rozwiązujących Kostkę i na koniec manipuluje Kostką tak aby każdaze ścian Kostki składała się z elementów w tym samym kolorze. Konstrukcja robotaoparta jest na istniejącym projekcie “Mindcub3r“ [8]. Na podstwie tego schematuzostał skonstruowany robot nazwany dla potrzeb pracy “Rubik Solver“, widoczny narysunku 1.2.

Zadanie realizowane było, poprzez napisanie trzech programów w środowiskach,ROBOTC, ev3dev oraz Matlab. Wszystkie trzy programy pomimo realizacji w róż-nych językach programistycznych łączy ta sama funkcjonalność. Robot układającyKostkę Rubika wymaga skomplikowanego oprogramowania, wykorzystującego więk-szość funkcji biblioteki języka dostępnych w środowiskach, oraz narzędzi środowi-skowych. Ze względu na złożoność programu, każdorazowa implementacja w danymśrodowisku skutkowała dogłębnym poznaniem systemu i wykorzystaniem jego wielumożliwości.

W poniższej pracy sformułowane zostały wnioski podsumowujące właściwościkażdego ze środowisk, jego cechy pozytywne, jak również aspekty utrudniające pracę.

1.4. STRUKTURA PRACY 11

Na podstawie analizowanych danych zostały również zdefiniowane typy projektów,które najbardziej pasują do danego środowiska.

1.4 Struktura pracy

Niniejsza praca składa się z pięciu rozdziałów licząc razem z niniejszym wstę-pem 1. W rozdziale 2 zostały zaprezentowane narzędzia jakich użyto do zbudowaniai oprogramowania robota. Rozdział 3 przedstawia przebieg zadania inżynierskiegooraz formułuje założenia projektowe. Rozdział 4 poświęcony jest realizacji implemen-tacji programów w środowiskach programistycznych. Ostatni rozdział 5 to podsu-mowanie wyników pracy w formie analizy porównawczej oraz sformułowane wnioski.


Rozdział 2

Wykorzystane technologie

W pracy wykorzystywany był sprzęt (sekcja 2.1), algorytmy (sekcja 2.2) orazprogramy (sekcja 2.3).

2.1 Wykorzystany sprzęt

Sprzętem potrzebnym do wykonania pracy był zestaw LEGO Mindstorms EV3Education Core Set (podsekcja 2.1.1) oraz Kostka Rubika (podsekcja 2.1.2).

2.1.1 LEGO Mindstorms EV3 Education Core Set

Podstawowym sprzętem wykorzystywanym w pracy jest zestaw umożliwiającybudowanie robotów LEGO Mindstorms EV3 Education Core Set. Jest to wersjaedukacyjna produktu EV3 skierowana głownie do studentów i uczniów, ale takżebardziej profesjonalnych użytkowników. W skład zestawu wchodzą elementy mecha-niczne - klocki LEGO Technic, oraz aktywne - serwomotory, sensory i kostka EV3.

Elementy mechaniczne wykorzystuje się do budowy nieruchomych części robotai nie mają większego znaczenia w poniższej pracy. Warto jednak poświęcić niecouwagi elementom aktywnym, ponieważ to one stanowią o możliwościach i potencjalerobota. Elementy aktywne przedstawione są na rysunku 2.1.

13

14 ROZDZIAŁ 2. WYKORZYSTANE TECHNOLOGIE

Rysunek 2.1: Serwomechanizmy, czujniki oraz kostka EV3 - elementy aktywne ze-stawu Mindstorms EV3 Education Core Set

Elementy aktywne:

• Programowalna kostka EV3 - komputer z systemem Linux oparty na proceso-rze ARM taktowanym częstotliwością 300MHz. Na pamięć komputera składasię 16- sto megabajtowa pamięć stała Flash rozszerzalna dzięki portowi kartmicroSDHC, oraz 64 MB pamięci operacyjnej RAM. W kostce znajdują sięcztery porty wejściowe do łączenia z czujnikami, oraz 4 wyjściowe przezna-czone dla reaktorów, wszystkie oparte na standardzie RJ-12. Do komunikacjiz komputerem zewnętrznym służą porty USB i Mini-USB, a w standardziebezprzewodowym technologia Bluetooth oraz opcjonalnie Wi-Fi poprzez do-datkowy adapter, do kupienia oddzielnie. Wszystko to wieńczy panel interakcjiz użytkownikiem, na którym znajduje się 6 programowalnych przycisków, ko-lorowe diody LED, głośnik oraz monochromatyczny wyświetlacze LCD o roz-dzielczości 178x128 pikseli.

• Dwa duże serwomechanizmy - napędy dużej mocy, o momencie siły za prze-kładnią wynoszącym 0.2 Niutonometra. Maksymalna prędkość kątowa wynosi160-170 obrotów na minutę. Mechanizmy wyposażone są w enkodery przy-rostowe, czyli czujniki obrotu o rozdzielczości 360 impulsów na obrót. Osieobrotu dużych serw ułożone są prostopadle względem korpusu podzespołu.

• Średni serwomechanizm - napęd o mniejszym gabarycie i mniejszym momen-cie siły za przekładnią, 0.08 Niutonometra. Kosztem zmniejszenia momentumożliwe było zwiększenie prędkości maksymalnej, która w przypadku napędu

2.1. WYKORZYSTANY SPRZĘT 15

średniego wynosi 240-250 obrotów na minutę. Serwo to również zostało wy-posażone w czujnik obrotu o rozdzielczości 360 impulsów/obrót. Oś obrotunapędu znajduje się wzdłuż najdłuższego wymiaru mechanizmu.

• Ultradźwiękowy czujnik odległości - sonar, który informuje o dystansie ro-bota do najbliższej przeszkody, działa na zasadzie emitowania i wyłapywaniaodbitych od przeszkód fal ultradźwiękowych. Dzięki użyciu tej zaawansowa-nej technologii stosowanej m.in. w radarach lotniczych, czujnik charakteryzujesię wysoką rozdzielczością ok. 1 cm. Sonar poprawnie działa gdy przeszkodaznajduje się w odległości od 3 do 250 cm. Dodatkowo oprócz funkcji pomiaruodległości, sensor można przełączyć w stan bierny, w którym pełni on funkcjęczujnika wyłapującego fale ze źródeł zewnętrznych.

• Czujnik koloru - jest to ściślej ujmując czujnik natężenia światła. Wyposażonyjest w ledowy emiter światła o kolorach bazowych: czerwieni, zieleni i koloruniebieskiego oraz wiązki światła białego. Emitowane z sensora fale świetlne poodbiciu od przedmiotu trafiają do soczewki, zbierającej je ponownie. Następnieczujnik bada natężenie odbitej fali. W zależności od tego jakie światło emitujesam czujnik, może on działać w trzech trybach: tryb rozpoznawania kolorów,tryb natężenia światła odbitego, tryb natężenia światła otoczenia. Czujnikkoloru działa z częstotliwością próbkowania wynoszącą 1kHz. Aby zapewnićpoprawny odczyt koloru, obiekt powinien znajdować się w odległości 15-55mmod czujnika.

• Dwa czujniki dotykowe - analogowe czujniki dotykowe wykrywają przyciśnięciebądź zwolnienie przycisku umiejscowionego z przodu czujnika. Przycisk skon-struowany jest specjalnie w taki sposób aby możliwe było dołączanie do niegostandardowych klocków Lego Technic. Głębokość na jaką przycisk może byćmaksymalnie wciśnięty wynosi 4mm. Czujnik ten można wykorzystać na dwasposoby: wykrywanie przeszkód przez robota, oraz jako dodatkowy przyciskudla użytkownika.

• Czujnik żyroskopowy - cyfrowy czujnik żyroskopowy mierzy ruchy obrotowerobota, oraz zmiany w jego orientacji. Z jego pomocą można zwiększyć do-kładność manewrów robota, odczytywać kąt nachylenia robota względem pod-łoża, co pozwala na budową robotów balansujących. Żyroskop może pracowaćw dwóch trybach: tryb kątowy z dokładnością ok. 3 stopni mierzy kąt ob-rotu czujnika; tryb żyroskopowy mierzy prędkość kątową, gdzie maksymalna


mierzalna prędkość wynosi 440 stopni na sekundę. Częstotliwość próbkowaniażyroskopu to 1kHz.

2.1.2 Kostka Rubika

W 1974 roku węgierski rzeźbiarz i architekt Ernő Rubik skonstruował łamigłówkęlogiczną, która szybko stała się jedną z najbardziej rozpoznawalnych zabawek naświecie. Na cześć twórcy została nazwana “Kostką Rubika“. Rozwiązywanie kostkipolega na takim układaniu kolorowych kwadratów, aby każda ze ścian miała wszyst-kie kwadraty w jednym kolorze.

Rysunek 2.2: Kostka Rubika

Budowa kostki: Kostka zbudowana jest z 26 sześcianów oraz przegubu, któryumożliwia zewnętrznym warstwom kostki obrót wokół osi środka kostki, będącejprostopadłą do płaszczyzny danej warstwy. Powierzchnie sześcianów widoczne z ze-wnątrz pomalowane są na sześć kolorów: czerwony, zielony, niebieski, żółty, poma-rańczowy i biały. Na poniższym rysunku przedstawiona jest Kostka Rubika firmyRubik’s 2.2.

Rysunek 2.3: Ściana i ścianka kostki Rubika

Aby ułatwić opis kostki, warto wprowadzić specyficzną dla niej terminologię,a więc pojęcia ścian i ścianek widocznych na rysunku2.3.

• Ściana kostki - odnosi się do ściany całej kostki Rubika, która po rozwiązaniujest jednokolorowa.

• Ścianka kostki - ściana jednego z 26 małych sześcianów widocznych na ze-wnątrz, posiadająca jeden z sześciu kolorów.

2.2. WYKORZYSTANE ALGORYTMY 17

2.2 Wykorzystane algorytmy

W pracy użyty został algorytm układania Kostki Rubika. Istnieje bardzo dużotechnik układania Kostki. Zagadnienie znajdywania optymalnych algorytmów, jesttrudne ze względu na olbrzymią liczbę kombinacji różnych ułożeń kostki, która wy-nosi ponad 43 tryliardy (43 252 003 274 489 856 000). W 2010 roku grupa matema-tyków dzięki mocy obliczeniowej serwerów komputerowych udowodniła, że dowolniepomieszaną kostkę da się ułożyć wykonując maksymalnie 20 “ruchów“.

Projektowanie nowego algorytmu układania Kostki Rubika, to niezwykleskomplikowany i wymagający proces. Ponieważ, nie jest on związany z tematempracy, wykorzystany został już istniejący algorytm. Jest on częścią projektuMindcub3r, rozwijanego przez Davida Gilday’a, pasjonatę tworzenia robotówz LEGO, rozpoznawalną postać w internetowym świecie LEGO. [8] O samymalgorytmie niewiele wiadomo, jako że jest on dostępny tylko w formie kodubinarnego i uruchamiany jest z poziomu odrębnego programu. Nie jest znany kodźródłowy tego programu, nazywanego w dalszej części pracy “solverem“. Wiadomojednak, że zaimplementowany został tu algorytm, który potrafi układać KostkęRubika w średnio 24 ruchach. Komunikacja programu robota z solverem odbywasię za pomocą zapisu i odczytu współdzielonych plików.

2.3 Wykorzystane oprogramowanie

Do oprogramowania wykorzystanego w pracy inżynierskiej należą programy, RO-BOTC (podsekcja 2.3.1), ev3dev (podsekcja 2.3.3) i Matlab (podsekcja 2.3.2).

2.3.1 ROBOTC

ROBOTC to wieloplatformowe środowisko programistyczne dla popularnych sys-temów robotycznych, takich jak: VEX IQ, VEX EDR, VEX PIC, TETRIX, ArduinoUNO, Arduino MEGA, oraz produkty Lego, RCX, NXT, a także najnowszy EV3.ROBOTC, to również nazwa języka programowania, którego się w tym systemieużywa. Język ROBOTC opiera swoją składnie na powszechnie znanym języku Ci przez to jest do niego bliźniaczo podobny. Systemem operacyjnym wymaganymprzez ROBOTC jest Windows, ale możliwe jest uruchamianie programu poprzezmaszynę wirtualną. Poniżej na rysunku 2.4 okno programu ROBOTC.


Rysunek 2.4: Okno programu ROBOTC

Program jest kompleksowym środowiskiem, tak zwanym zintegrowanym środowi-skiem programistycznym (ang. Integrated Development Environment, IDE ). Ozna-cza to, że dostarcza on narzędzi do pisania i edytowania kodu, a także umożliwiakompilację kodu i wysyłanie pliku binarnego na urządzenie, a wszystko to w jednymprogramie.

Oprócz powyższych, w programie dostępne są narzędzia takie jak:

• Debugger

• Przeglądarka funkcji bibliotecznych

• Konfigurator komunikacji z robotem

• Eksplorator plików robota

• Konfigurator napędów i czujników

• Narzędzie aktualizacji jądra systemu robota

• Automatyczne formatowanie i uzupełnianie kodu

Dodatkowo ze środowiskiem związany jest wirtualny symulator robota i jegoprzestrzeni roboczej: Robot Virtual Worlds. Jest to odrębny, dodatkowo płatny pro-gram, który pozwala na symulację zachowania robota w graficznym świecie wir-tualnym. Robot Virtual Worlds świetnie nadaje się do nauki robotyki, nawet bez

2.3. WYKORZYSTANE OPROGRAMOWANIE 19

Rysunek 2.5: Okno programu Robot Virtual Worlds

konieczności posiadania fizycznego robota. Znajduje się w nim przystępny samo-uczek oraz szereg zajmujących wyzwań programistycznych. Okno programu RobotVirtual Worlds widoczne jest na rysunku 2.5. Na platformie tej organizowane sąliczne konkursy robotyczne, mające odnajdywać młode talenty z zakresu robotyki,jednym z przykładów takich konkursów jest “Mini Urban Challenge“. [6]

2.3.2 Matlab

Rysunek 2.6: Okno programu Matlab z dodatkiem LEGO Mindstorms EV3 SupportPackage


Matlab to rozbudowany program komputerowy stworzonym do wykonywania ob-liczeń naukowych oraz tworzenia symulacji komputerowych. Płatny program tworzyfirma MathWorks. Dostępny jest na systemach operacyjnych Windows, OS X, orazLinux i Unix. Program jest dobrze znany przez uczniów studiów inżynierskich, jeston szeroko stosowany na uczelniach. Operuje się tu w języku Matlab opartym najęzyku C. Okno programu Matlab przedstawia rysunek 2.6.

Dla programu dostępne są liczne biblioteki dodatkowe (ang. toolbox ), które po-większają zdolności programu Matlab o dodatkowe funkcje. Jednym z takich do-datków jest “LEGO Mindstorms EV3 Support Package“. [5] Dodatek ten umożliwiapisanie programów na roboty w technologii Mindstorms EV3.

Działanie środowiska Matlab różni się od innych środowisk programistycznychdla robotów. Różnica polega na tym, że Matlab pełni rolę zdalnego kontrolera dlarobota. Program nie jest tu przesyłany na urządzenie, wykonuje się na komputerze,jedynie w przypadku gdy robot wykonywać ma jakieś instrukcje wysyłane są doniego rozkazy.

2.3.3 ev3dev

Rysunek 2.7: Okno sesji SSH z robotem uruchomionym w systemie ev3dev

Jednym ze sposobów programowania robotów serii EV3 jest środowisko ev3dev.W odróżnieniu od poprzednio opisywanych programów ev3dev nie jest zintegrowa-nym środowiskiem programistycznym. Ev3dev to rozwijany przez Ralph’a Hempela

2.3. WYKORZYSTANE OPROGRAMOWANIE 21

oraz David’a Lechner’a system operacyjny oparty na Debianie, dystrybucji systemuLinux. Ponieważ kostka EV3 działa na systemie Linux, wystarczy wgrać obraz dyskuinnej dystrybucji Linux’a na kartę pamięci umieszczaną w kieszeni robota. Wówczasrobot po włączeniu uruchamia system z karty pamięci zamiast z pamięci trwałej.Tym sposobem możliwa jest podmiana systemu robota. System ev3dev posiada ni-skopoziomowe sterowniki umożliwiające używanie czujników, motorów i samej kostkiEV3. Na rysunku 2.7 znajduje się okno klienta SSH połączonego z robotem, którypracuje z uruchomionym systemem ev3dev.

Podstawowym założeniem systemu jest otwartość i dostępność. Dzięki temu pro-gramiści z całego świata pomagają w rozwoju projektu. Efektem globalnej współ-pracy jest istnienie bibliotek współpracujących z robotem LEGO, napisanych w bar-dzo szerokiej gamie języków programistycznych. Użytkownik chcący pracować nadrobotem w systemie ev3dev może wybierać wedle upodobań jeden z dostępnychjęzyków: C++, Node.js, Python, Google Go, C, Clojure, lua, Perl.

Proces rozwijania oprogramowania robotycznego poprzez system ev3dev wyglądanastępująco:

1. Pisanie kodu źródłowego programu w dowolnym edytorze tekstowym

2. Kompilacja kodu na komputerze (z użyciem kompilatora dla procesora ARM)

3. Przesłanie skompilowanego pliku binarnego na robota poprzez łącze SSH(ang.Secure Shell [4])

4. Uruchomienie programu zdalnie poprzez SSH lub bezpośrednio na robocie

Powyżej przedstawione kroki, są tylko ramowym przedstawieniem procesu, moż-liwe są jego modyfikacje. Dla przykładu kompilację można przeprowadzać na urzą-dzeniu, oszczędza to przesyłania pliku wykonalnego z komputera, jednak ze względuna ograniczone możliwości procesora robota kompilacja taka zajmuje dużo czasu. Do-stępne są też dodatkowe narzędzia umożliwiające np. debugowanie programu w sesjiSSH.


Rozdział 3

Projekt systemu

W rozdziale tym opisano kolejne etapy przebiegu zadania (sekcja 3.1) i scharak-teryzowano założenia projektowe (sekcja 3.2).

3.1 Przebieg zadania

W poniższej pracy wyodrębnione zostały poszczególne etapy pracy nad robotemLEGO. Głównym zadaniem był przegląd kilku środowisk programistycznych orazich przetestowanie i porównanie z perspektywy programowania robota.

Etap 1: Stworzenie fizycznego modelu robota

Pierwszy etap polegał na wybraniu odpowiedniego robota. Odpowiedniość pole-gała na możliwości rzetelnego i sprawnego testowania środowisk programistycznych.Założenia te spełnił robot układający Kostkę Rubika.

Zalety testowania środowisk na robocie rozwiązującym Kostkę Rubika:

• Złożoność - jest to skomplikowany projekt, który wykorzystuje dużą liczbęczujników i napędów. Projekt wymaga implementacji dużej ilości kodu źró-dłowego, wykorzystującego szeroką gamę funkcji bibliotecznych danego językaprogramowania. Dzięki temu środowiska mogą być gruntownie przetestowane,za pomocą użycia zaledwie jednego urządzenia.

• Powtarzalność - robot będzie zachowywał się powtarzalnie przy otrzymaniutych samych danych wejściowych. Oznacza to, że za każdym razem, gdy robotdostaje identycznie pomieszaną kostkę, układa ją za pomocą tej samej se-kwencji ruchów. Jest to cecha, która bardzo ułatwia proces testowania robota,w przeciwieństwie do robotów niepowtarzalnych, gdzie ciężko jest obiektywnieporównać zachowania robota przy kolejnych uruchomieniach.

23

24 ROZDZIAŁ 3. PROJEKT SYSTEMU

• Niezależność od środowiska - robot rozwiązujący Kostkę Rubika jest małozależny od czynników zewnętrznych. Jedynie oświetlenie może wpływać nadziałanie czujnika światła, jednak da się umniejszyć ten wpływ stosującodpowiednią kalibrację wstępną. Dzięki niewielkiemu wpływowi czynni-ków zewnętrznych robot staje się zależny jedynie od danych wejściowych.Przekłada się to na powtarzalność robota oraz umożliwia pominięcie stanuśrodowiska otaczającego robota, przy każdym jego uruchomieniu. Jest toczynnik wpływający na łatwość testowania robota oraz środowisk.

Gdy koncepcja robota była określona, kolejnym zadaniem było znalezieniei wybór odpowiedniego, gotowego projektu robota. Najlepszym projektem okazałsię Mindcub3r [8], stworzony przez David’a Gilday’a. Kryterium wyboru podlegały,solidność konstrukcji oraz możliwość zbudowania robota przy użyciu elementówaktywnych jedynie z zestawu EV3 Education Core Set. Konstrukcja robota “Rubiksolver“ różni się od projektu Mincub3r’a, ponieważ drugi wykorzystuje równieżklocki LEGO z zestawu “EV3 Education Expansion Set“, które zostały zastąpioneinnymi elementami z innych zestawów LEGO. [10] Oprócz tego nie było potrzebywykorzystywać czujnika odległości do wykrywania kostki, tak jak w projekcieMindcub3r. Na rysunku 3.1 widoczne są oba roboty.

Rysunek 3.1: Projekt robota “Mindcub3r“(po lewej) i robot “Rubik solver“ (po pra-wej)

Robot “Rubik solver“ potrafi skanować oraz manipulować kostką dzięki rucho-mym układom zbudowanym z siłowników, czujnika koloru oraz klockom LEGO Tech-nic.

3.1. PRZEBIEG ZADANIA 25

Ruchome układy zostały nazwane:

Rysunek 3.2: Spinner

• “Spinner“ - obracająca się platforma przytrzymująca kostkę. “Spinner“, wi-doczny na rysunku 3.2, pełni dwie funkcje, obraca kostkę wokół osi pionowej,oraz obraca dolną warstwę kostki gdy jest ona przytrzymywana od góry “Flip-perem“. Za obracanie platformą odpowiada duży serwonapęd umiejscowionypod nią. Serwonapęd porusza platformą poprzez dwa koła zębate: mniejsze- 12 zębów, większe - 36 zębów, co daje w efekcie przełożenie geometrycznerówne 3.

Rysunek 3.3: Camera

• “Camera“ - ruchomy wysięgnik na którego końcu umieszczony jest czujnikkoloru. “Camera“, widoczna na rysunku 3.3, umożliwia skanowanie kolejnychścianek kostki. Skanowanie odbywa się poprzez zgranie w jednym czasie dwóchruchów: obrotowego ruchu platformy i przesuwnego ruchu wysięgnika. W tensposób rozpoznawane są kolory ścianek krawędziowych jednej ze ścian kostki.Kolor ścianki środkowej rozpoznawany jest przy nieobracającej się platformie.Pomiędzy średnim serwonapędem zlokalizowanym pionowo pod wysięgnikiem,a samym wysięgnikiem znajdują się 3 koła zębate, pierwsze umieszczone z osią


obrotu zwróconą pionowo o 12 zębach, drugie z poziomą osią obrotu równieżo 12 zębach, ostatnie największe koło z osią poziomą o 36 zębach. Takie usta-wienie kół zębatych zmienia oś obrotu z wejściowej pionowej, na poziomą orazzwiększa precyzję ruchów.

Rysunek 3.4: Flipper

• “Flipper“ - ruchome ramie robota pełniące dwie funkcje. Pierwszą funkcją jestobracanie kostki na platformie w osi poziomej, poprzez “naciągnięcie“ kostkina barierkę platformy. “Flipper”, widoczny na rysunku 3.4, skonstruowany jestw ten sposób, że wykonując ruch w kierunku przeciwnym do ruchu obraca-jącego kostkę, ramię nie obraca kostki w przeciwnym kierunku, dzięki temumożliwy jest powrót ramienia do pozycji wyjściowej po wykonaniu manewruobracającego. Drugą funkcją ramienia jest przytrzymywanie kostki w chwiligdy platforma wykonuje obrót, w celu obrócenia dolnej warstwy kostki. Wy-konywaniem ruchów ramienia zajmuje się duży serwomotor umieszczony przyosi obrotu ramienia. Motor połączony jest z ramieniem za pomocą przegubuw kształcie krzywej łamanej. Dzięki takiemu kształtowi przegubu ramie wy-konuje ruch posuwisty, przypominający ruch korbowodu lokomotywy parowej.Korbowód lokomotywy, dla zobrazowania widoczny jest na rysunku 3.5.

Rysunek 3.5: Schemat układu jezdnego lokomotywy parowej, widoczny jest na nimkorbowód, którego ruch przypomina poruszanie się “Flippera“

3.2. ZAŁOŻENIA PROJEKTU 27

Etap 2: Napisanie oprogramowania robota w środowisku ROBOTC

Gdy robot był już solidnie skonstruowany kolejnym etapem było stworzenieoprogramowania w pierwszym ze środowisk. Jako pierwsze wybrane zostało śro-dowisko ROBOTC, jako że autor pracy miał w nim największe doświadczenie.Napisanie pierwszego programu jest najbardziej czasochłonnym zadaniem, dlategowybranie środowiska, które zna się najlepiej wydaje się właściwym rozwiązaniem,ponieważ przyspiesza proces, co wpływa pozytywnie na rozwój pracy.

Etap 3: Przepisanie programu w środowisku Matlab

W momencie gdy program działał poprawnie i zadowalająco, przyszła pora naprzepisanie go do kolejnego środowiska, którym był Matlab. Tutaj nastąpiły pewnekomplikacje, na temat których więcej dowiedzieć się można w rozdziale 4.

Etap 4: Przepisanie programu dla systemu ev3dev

Ostatnim testowanym środowiskiem było ev3dev. Tak samo jak w przypadkupoprzednich środowisk na tym etapie pracy nastąpiło napisanie programu w tymśrodowisku.

Etap 5: Porównanie wygody implementacji kodu w powyższych śro-

dowiskach

Po sfinalizowaniu wszystkich etapów związanych z implementacją nadszedł czasna wyciągnięcie wniosków, na temat pracy w każdym ze środowisk. Porównanie ichze sobą, zestawienie najważniejszych atrybutów tych programów w tabeli porów-nawczej. Określenie jakie typy projektów najlepiej pasują do każdego ze środowisk.

3.2 Założenia projektu

Ważną fazą, która miała miejsce jeszcze przed rozpoczęciem prac projektowychbyło sformułowanie założeń jakie robot, programy i praca muszą spełniać. Dziękizałożeniom droga do celu jest prostsza. Założenia zapobiegają wykonywaniazbędnych czynności, które opóźniają sfinalizowanie projektu.

Założeniami projektu są:

• Solidna konstrukcja robota - robot musi być umieszczony na stabilnej plat-formie. Konstrukcja nie powinna zmieniać się w trakcie eksploatacji, powinna


być w stanie wytrzymać minimum 10 kolejnych uruchomień programu, bez po-trzeby wykonywania napraw. Robot powinien być niepodatny na uszkodzeniaprzy przenoszeniu i transporcie.

• Robot zbudowany z wykorzystaniem możliwym minimum części - “Im prościejtym lepiej.“ “Im mniej tym więcej.“ Te motta towarzyszyły projektowaniu ro-bota. W dodatku ograniczona liczba dostępnych części wymuszała minimalizmkonstrukcji.

• Wykorzystanie przynajmniej dwóch środowisk programistycznych - zakłada-nym minimum było przetestowanie dwóch potencjalnie najlepszych dostępnychśrodowisk do programowania robota.

• Programy robota potrafiące rozwiązać Kostkę Rubika w czasie poniżej 2 mi-nut - odgórne ograniczenie czasu potrzebnego robotowi do wykonania zadania,zmuszało do uzyskania sprawnie działającego robota. Czas liczy się od rozpo-częcia skanowania, do chwili gdy Kostka jest w pełni ułożona. W efekcie średniczas jest znacznie krótszy niż zakładane ograniczenie, dzięki temu testowanierobota przechodzi bardzo sprawnie.

• Programy nieobarczone błędami krytycznymi - nie istnieje jeden, idealnyprogram spełniający daną funkcjonalność, często programiści niezadowoleniz efektów, poddają program ciągłym udoskonaleniom. Rozwijanie oprogra-mowania potrafi przez to trwać dużo dłużej niż zadowalające minimum, a wwielu przypadkach, programy wręcz nigdy nie zostają ukończone. Wymaganie,że program uznaje się za ukończony w sytuacji gdy działa, a jego działanie,sprawdzone poprzez testy nie jest przerywane przez błędy programistyczne ja-sno stwierdza, kiedy można zakończyć proces ulepszania kodu. Dzięki temuogólny proces tworzenia pracy inżynierskiej ulega skróceniu, a zaoszczędzonyczas można przeznaczyć na bardziej istotne elementy projektu.

• Programy z różnych środowisk mające możliwe podobne działanie - oprogra-mowanie robota z różnych środowisk powinno być napisane w możliwie po-dobny sposób, tak aby zachowanie robota było nie do rozróżnienia.

• Uruchomione programy nie mogą niszczyć konstrukcji robota oraz jego elemen-tów - programy muszą mieć tak dobrane wartości mocy i prędkości elementówruchomych, aby nie mogły zniszczyć konstrukcji robota.

3.2. ZAŁOŻENIA PROJEKTU 29

• Zachowanie podziału na moduły programów po między środowiskami - opro-gramowanie robota składa się z modułów odpowiadających za konkretne funk-cje. Wymaganiem jest aby w różnych środowiskach programy podzielone byłyna takie same moduły.

• Robot ma trzy podejścia do właściwego zeskanowania Kostki - w sytuacji gdyrobot napotyka na problem w trakcie skanowania Kostki zliczane są nieudanepróby. Po trzeciej próbie robot przerywa wykonywanie programu. Dzięki temuunika się sytuacji, w której robot bez końca podejmuje nieudane próby zeska-nowania kostki.

• Manipulacja Kostką przez robota musi przechodzić bezbłędnie - współczynnikiruchu manipulatorów powinny być w taki sposób dobrane, aby nie popełnianebyły błędy w poruszaniu Kostką. Dla przykładu niedopuszczalna jest sytuacja,w której robot miał obrócić Kostkę, a w wyniku przyblokowania Kostka niezmieniła swojej orientacji.

• Robot po ułożeniu Kostki musi być gotowy do kolejnego układania - stanrobota po zakończeniu udanego układania Kostki musi być dokładnie taki samjak stan robota przed ułożeniem Kostki. Gwarantuje to płynność działaniarobota w kolejnych uruchomieniach. Przyspiesza i ułatwia testowanie robota.


Rozdział 4

Realizacja

Rozdział ten opisuje implementację programu robota w środowiskach: ROBOTC(sekcja 4.1), ev3dev (sekcja 4.3) oraz Matlab (sekcja 4.2).

4.1 Implementacja w środowisku ROBOTC

Środowisko ROBOTC umożliwia pisanie programów w języku ROBOTC, którywykorzystuje składnię języka C. W tym właśnie języku napisany jest program ro-bota. Program podzielony jest na moduły. Moduły odzwierciedlają konkretną funk-cję, za którą kod jest odpowiedzialny. Na diagramie UML 4.1 widoczny jest podziałna pliki odpowiadające oddzielnym modułom programu. W kolejnych podsekcjachopisane są wszystkie moduły programu.

4.1.1 Główna pętla programu - plik “main“

Główna pętla ma bardzo prostą budowę. Wywoływane są w niej kolejno trzyfunkcje. Wraz z uruchomieniem programu wywoływana jest funkcja “calibrate()“z modułu kalibracji, która ustawia właściwą pozycję serwonapędów robota. Po za-kończeniu kalibracji wołana jest funkcja “displayPatternSelection()“ z modułu wy-świetlania, która wyświetla stosowny komunikat i oczekuje na wciśnięcie przyciskurozpoczynającego skanowanie. Gdy przycisk zostaje naciśnięty, wówczas wywoły-wana jest funkcja “scanAndSolve()“ z modułu skanuj i rozwiąż, która zajmuje sięskanowaniem, rozwiązywaniem oraz układaniem Kostki Rubika.

31

32 ROZDZIAŁ 4. REALIZACJA

Rysunek 4.1: Schemat UML struktury programu napisanego w ROBOTC

4.1.2 Moduł zmiennych globalnych - plik “globals“

W module tym zdefiniowane są zmienne współdzielone przez inne moduły. Zde-finiowane są tutaj tablice ułożeń kostki, flagi programu, współczynniki sterowaniasilnikami itp.

4.1.3 Moduł manipulacji - plik “manipulate“

Moduł manipulacji jest najważniejszą częścią programu. Zdefiniowane są tu funk-cje, które z dużą dokładnością zmieniają pozycje oraz ułożenie ścianek na Kostce.Wykorzystywane są tu funkcje dostępne w bogatej bibliotece dostarczonej przezśrodowisko ROBOTC. Funkcje biblioteczne dają możliwość między innymi: ruchusilnika o określony kąt z zadaną mocą, ruchu silnika o określony kąt z zadaną prędko-ścią, z wykorzystaniem algorytmu PID, wstrzymanie wątku programu do momentuzakończenia ruchu. Dostarczenie tak wysokopoziomowych funkcji operowania moto-rami pozwala na sprawne pisanie programu i nie wymaga konstruowania własnychfunkcji. Z modułu manipulacji korzystają wszystkie inne moduły oprócz modułurozwiązywania.

4.1. IMPLEMENTACJA W ŚRODOWISKU ROBOTC 33

4.1.4 Moduł kalibracji - plik “calibrate“

Moduł kalibracji dostarcza metod potrzebnych do ustawienia ruchomych częścirobota w odpowiednich pozycjach wyjściowych. Zawiera też funkcję, która sprawdzaczy uruchomiony jest zewnętrzny program odpowiedzialny za znajdywanie optymal-nej sekwencji rozwiązywania Kostki. Moduł ten wywoływany jest głównie przy uru-chomieniu programu, oraz po zakończeniu działania w celu powrotu robota do stanuwyjściowego.

4.1.5 Moduł wyświetlania - plik “display“

Moduł ten odpowiada za wyświetlanie komunikatów na ekranie robota, orazobsługę przycisków znajdujących się na panelu przednim kostki EV3. Do wyświetla-nych komunikatów zaliczamy: nazwa obecnie wykonywanej operacji (kalibracja, ska-nowanie, kalkulacja, rozwiązywanie), wyświetlanie błędów, ewentualny wybór wzoruukładanego na Kostce, czy ilość pozostałych ruchów potrzebnych do rozwiązaniaKostki.

4.1.6 Moduł skanowania - plik “scan_cube“

Plik “scan_cube.c“ odpowiada za wszelkie operacje związane ze skanowaniem ko-lorów kolejnych ścianek Kostki. Znajdują się tu funkcje takie jak: skanuj środkowąściankę Kostki, skanuj ściankę krawędziową, skanuj ściankę narożną, skanuj całąścianę Kostki, oraz łączącą wszystkie poprzednie, funkcję skanującą całą Kostkę.Moduł ten wykorzystuje możliwości wielowątkowości programu, tworząc oddzielnewątki, które niezależnie od wykonywania głównego programu powodują ruch układuĆamera". Dzięki temu można zsynchronizować ruch obrotowy Kostki z ruchem czuj-nika koloru, tak aby sprawnie i poprawnie pobrać kolejne kolory ścianek Kostki.

4.1.7 Moduł rozwiązywania - plik “solve“

Moduł rozwiązywania zajmuje się komunikacją z zewnętrznym programem ob-liczającym optymalne rozwiązanie Kostki. Komunikacja pomiędzy dwoma progra-mami odbywa się za pomocą dwóch plików tekstowych znajdujących się w pamięcirobota. Pierwszy plik nazywa się mc3cmd.rtf i służy do przekazywania kolejnychkomend. W pliku mc3dat.rtf umieszczane są przez program odczytane wartości ko-lorów ścianek robota. W tym samym pliku jako odpowiedź zapisywane są przezsolver informacje: liczba kroków rozwiązywania, oraz szereg cyfr reprezentującychsekwencję układania Kostki.


Proces komunikacji przebiega w kolejności:

1. Moduł rozwiązywania najpierw zapisuje w pliku mc3cmd.rtf komunikat roz-poczęcia pracy.

2. Program “solver“ odpowiada, że zrozumiał komendę zapisując odpowiedźw pliku mc3cmd.rtf

3. Po zeskanowaniu Kostki program zapisuje w pliku mc3dat.rtf wartości kolorówkolejnych ścianek Kostki.

4. Po obliczeniu optymalnego rozwiązania “solver“ zapisuje w pliku mc3dat.rtfilość kroków rozwiązania oraz sekwencje ruchów układania kostki

5. Na koniec “solver“ w pliku mc3out.rtf umieszcza raport pracy programu “so-lver“

4.1.8 Moduł skanuj i rozwiąż - plik “scan_and_solve“

Moduł ten zawiera tylko jedną funkcję. Funkcja ta służy do uruchamiania kolejnowszystkich metod potrzebnych do tego aby właściwie zeskanować, obliczyć ruchyi ułożyć Kostkę Rubika. W przypadku trzech nieudanych prób ułożenia Kostki mo-duł ten zaprzestaje wykonywać dalsze próby, wyświetla stosowny komunikat błędui ustawia robota w pozycji wyjściowej.

4.2 Próba implementacji w środowisku Matlab

Przed rozpoczęciem implementacji w programie Matlab miał miejsce przeglądtego środowiska. Celem tego przeglądu było poznanie możliwości jaki ten programoferuje. W trakcie przeglądu wyszło na jaw jak ograniczoną funkcjonalność repre-zentuje sobą środowisko Matlab w tym zastosowaniu. W szczególności najbardziejistotnymi ograniczeniami były:

• Brak możliwości przesłania programu na urządzenie - program Matlab pozwalajedynie na pracę w formie zdalnej kontroli robota. Program wykonywany jestna komputerze, który tylko i wyłącznie drogą komunikacji z robotem wysyłamu na bieżąco kolejne instrukcje do wykonania. Oznacza to, że niemożliwe jestsamodzielne funkcjonowanie robota.

• Ograniczona liczba funkcji bibliotecznych - charakter zdalnego kontrolera pro-gramu Matlab powoduje mocno ograniczony zbiór gotowych funkcji bibliotecz-nych. Programista otrzymuje jedynie najbardziej podstawowy zestaw funkcji

4.3. IMPLEMENTACJA W SYSTEMIE EV3DEV 35

takich jak przekazanie mocy na dany silnik, czy odczyt surowej wartości ja-sności światła czujnika koloru. Brak bardziej skomplikowanych funkcji, np.obrotu serwonapędu z utrzymywaniem zadanej prędkości, dzięki algorytmowiPID, utrudnia i spowalnia pisanie skomplikowanych programów.

• Brak operacji odczytu i zapisu plików na urządzeniu - W programie Matlabniemożliwe jest wykonywanie operacji na plikach znajdujących się w pamięcirobota. Przez to nie jest możliwa komunikacja z zewnętrznym programem “so-lver“, który komunikuje się z oprogramowaniem robota właśnie poprzez wy-mienianie danych w plikach urządzenia.

• Brak programowania wielowątkowego - program Matlab nie daje możliwościprogramowania współbieżnego robotów Mindstorms. Stanowi to silne ograni-czenie. W wielu przypadkach da się przerobić oprogramowanie współbieżnena jednowątkowe, jednak może się to okazać czasochłonne oraz zmieniającezachowanie robota. W pozostałych dwóch środowiskach wielowątkowość byławykorzystywana.

Te wszystkie czynniki wpłynęły na decyzję, że środowisko Matlab nie nadajesię do implementacji programu na robota “Rubik solver“. Tak więc po wstęp-nym zapoznaniu ze środowiskiem postanowione zostało, że robot oprogramo-wany zostanie w środowiskach ROBOTC i ev3dev, natomiast Matlab zostaniewykluczony ponieważ nie nadaje się on do projektów tego typu.

4.3 Implementacja w systemie ev3dev

Do implementacji kolejnej kopii programu wykorzystany został system ev3dev.Program napisany był w języku C++. C++ jest językiem obiektowym, dlatego pro-gram podzielony został na klasy odpowiadające modułom programu. W funkcji maintworzone są kolejno wszystkie obiekty głównych klas modułów. Obiekty potrzebnemetodom klas przekazywane są do nich poprzez argumenty wywołania metody. Dotego celu zdefiniowane zostały szablony metod. Na rysunku 4.2 przedstawiony zo-stał diagram klas programu napisanego w systemie ev3dev. W kolejnych podsekcjachopisane są wszystkie moduły programu.

4.3.1 Moduł zmiennych globalnych - plik “globals“

Tak jak w przypadku programu z ROBOTC wykorzystywany jest szereg zmien-nych globalnych. Jest to prawie identyczny zestaw zmiennych, stałych i tablic jakw przypadku pliku “globals“ z programu napisanego w ROBOTC.


Rysunek 4.2: Diagram klas programu napisanego w środowisku ev3dev

4.3.2 Moduł manipulacji - klasa “manipulate“

W klasie manipulate znajdują się funkcje odpowiedzialne za manipulacje KostkąRubika. Biblioteka ev3dev dostarcza trochę uboższy zestaw funkcji związanych z se-rvonapędami. Nie przeszkadza to jednak w tworzeniu własnych wysokopoziomowychfunkcji. W klasie manipulate zaimplementowane zostały funkcje stworzone na wzórtych ze środowiska ROBOTC, ułatwiło to przepisywanie programu z pierwszego śro-dowiska. W dodatku dzięki temu programy zachowują spójną konstrukcją, co byłojednym z założeń projektowych.

4.3.3 Moduł kalibracji - klasa “calibrate“

Dokładnie jak w przypadku pliku “calibrate“ z ROBOTC w klasie tej znajdująsię metody ustawiające robota w pozycji gotowej do rozwiązywania Kostki.

4.3.4 Moduł wyświetlania - klasa “display“

Klasa odpowiada za dostarczenie interfejsu do komunikacji z użytkownikiem.Wyświetlane są komunikaty informujące o stanie robota, kolejnych fazach działania

4.3. IMPLEMENTACJA W SYSTEMIE EV3DEV 37

programu, czy ewentualnych błędach. Dla uproszczenia komunikaty nie są forma-towane, a są po prostu kolejnymi wypisanymi na ekranie liniami tekstu, tak jakw przypadku linii poleceń komputera PC.

4.3.5 Moduł skanowania - klasa “scan_cube“

Moduł “scan_cube“ to klasa ze zdefiniowanymi metodami, które zajmują siędokładnym zeskanowaniem wszystkich kolorowych ścianek Kostki. Funkcje te wyko-rzystują czujnik koloru działający w trybie RGB - podającym składowe czerownego,zielonego i niebieskiego koloru ścianki. Informacje te zebrane w tablicach scan_red,scan_green, scan_blue wysyłane są potem do zewnętrznego programu.

4.3.6 Moduł rozwiązywania - klasa “solver“

Klasa ta dostarcza metod których zadaniem jest komunikacja z zewnętrznymprogramem “solver“. Komunikacja przebiega w dokładnie ten sam sposób co w śro-dowisku ROBOTC ponieważ wykorzystuje dokładnie ten sam zewnętrzny programrozwiązujący.

4.3.7 Moduł skanuj i rozwiąż - klasa “scan_and_solve“

Klasa ta zajmuje się uruchamianiem kolejnych metod ze wszystkich klas, takaby w efekcie z pomieszanej Kostki po wywołaniu metody scanAndSolve otrzymaćKostkę rozwiązaną. Tak jak w przypadku programu z ROBOTC wykonywane sątrzy próby ułożenia Kostki, a w przypadku porażki komunikowany jest błąd, a robotustawiany w pozycji wyjściowej.


Rozdział 5

Podsumowanie

W ostatnim rozdziale zawarte są wyniki analizy środowisk programistycznych(sekcja 5.1) oraz wnioski wyciągnięte w trakcie wykonywania analizy (sekcja 5.2).

5.1 Wyniki analizy porównawczej

Rysunek 5.1: Porównanie środowisk programistycznych. * zależne od wybranegoedytora, ** możliwość doinstalowania modułu

39

40 ROZDZIAŁ 5. PODSUMOWANIE

Analiza porównawcza przebiegła sprawnie, dzięki temu, że środowiska zostałypoznane od strony implementacyjnej. Udało się uzyskać wyniki charakteryzującekażde ze środowisk. Wyniki porównania przedstawione są w tabeli z rysunku 5.1.

Najważniejsze różnice pomiędzy środowiskami:

• Środowisk ROBOTC i Matlab nie trzeba konfigurować przed rozpoczęciempierwszych projektów. Natomiast jedynie środowisko ev3dev umożliwia dołą-czanie modułów rozszerzających funkcjonalność programu.

• ROBOTC i Matlab posiadają zintegrowane edytory, w których dostępne sąznane ze standardowych zintegrowanych środowisk programistycznych funk-cje, jak: kolorowanie składni kodu, czy automatyczne uzupełnianie wyra-żeń. Dodatkowo bardzo przydatnym udogodnieniem jest przeglądarka wszyst-kich funkcji bibliotecznych, która dostępna jest tylko w programie ROBOTC.Ev3dev nie posiada dedykowanego edytora. Natomiast można użyć dowolnegoedytora, który wspiera języki używane przez ev3dev. Dobranie własnego edy-tora wymaga samodzielnej konfiguracji, instalowania kompilatorów skrośnychi doinstalowywania potrzebnych rozszerzeń. Mimo wymaganego wysiłku przykonfiguracji, efekt może dorównywać edytorom środowisk ROBOTC i Matlab.Dodatkowym atutem wyróżniającym ev3dev jest otwartość kodu źródłowegotego projektu.

• W przypadku testowania i wykrywania błędów środowiska ROBOTC i Matlaboferują wbudowane, wszystkie standardowe narzędzia potrzebne do tych pro-cesów. Natomiast ev3dev standardowo nie posiada takich narzędzi, możliwejest jednak doinstalowanie narzędzi, które można znaleźć w sieci.

• Kompilatorem zintegrowanym mogą się pochwalić ROBOTC i Matlab jednakw przypadku tego drugiego kod binarny nigdy nie jest w całości wysyłanyna robota, co wynika z faktu pracy środowiska w formie zdalnego kontrolera.ROBOTC i ev3dev umożliwiają również pracę w trybie zdalnej kontroli jed-nak standardowo, cały skompilowany program przesyłany jest na urządzenie.Dodatkowym atutem środowiska ev3dev jest możliwość kompilacji programubezpośrednio na robocie. Umożliwia to przeprowadzenie całego procesu imple-mentacji programu, za pomocą urządzenia umożliwiającego zdalny dostęp dorobota bez konieczności używania komputera. Taki tryb pracy wygodny jestjedynie w przypadku bardzo małych programów.

5.2. WNIOSKI 41

• Wszystkie środowiska umożliwiają stabilną komunikacje za pomocą kabla USB,oraz bezprzewodowo z użyciem standardów Bluetooth oraz Wi-Fi. Natomiastw środowisku ev3dev wymagana jest ręczna konfiguracja takiego połączenia,podczas gdy pozostałe programy posiadają wygodne zintegrowane moduły ko-munikacji.

• Cechami wyróżniającymi poszczególne środowiska są: Możliwości analizy i pre-zentacji danych w programie Matlab. Możliwe jest również stworzenie wirtu-alnego modelu robota oraz testowanie z użyciem współpracującego programuSimulink [7]. ROBOTC oraz ev3dev wspierają podłączanie do robota nieofi-cjalnych podzespołów. W ev3dev możliwe jest pisanie własnych sterowników,co otwiera drogę do podłączania autorskich podzespołów. Atutem wyróżnia-jącym system ev3dev jest możliwość wyboru spośród wachlarza języków pro-gramowania.

5.2 Wnioski

Wnioski mają formę charakterystyki projektów najbardziej odpowiednich dlakonkretnych środowisk. W kolejnych podsekcjach znajdują się wnioski dla środowiskROBOTC (podsekcja 5.2.1), ev3dev (podsekcja 5.2.2) oraz Matlab (podsekcja 5.2.3).Na końcu znajduje się wniosek ogólny (podsekcja 5.2.4).

5.2.1 Charakterystyka projektów dla środowiska ROBOTC

Środowisko ROBOTC jest najbardziej wszechstronnym spośród analizowanychprogramów. Cechy takie jak: automatyczna konfiguracja, zebranie wszystkich po-trzebnych narzędzi w jednym programie, zintegrowany kompilator, debugger i modułkomunikacji, dołączona przeglądarka funkcji bibliotecznych i dokumentacja, świad-czą o tym, że środowisko to świetnie nadaje się do zarówno małych jak i bardzodużych projektów. Wadami środowiska są zamknięte źródła kodu, oraz brak wy-boru języków programowania. Najbardziej polecany dla młodzieży, w szczególnościna zajęcia szkolne oraz uniwersyteckie.

5.2.2 Charakterystyka projektów dla środowiska ev3dev

Ev3dev to system, którego największymi zaletami są szerokie spektrum dostęp-nych języków programowania, oraz nieograniczone możliwości rozwijania programu.


Otwarty kod źródłowy pozwala na dołączanie własnych rozszerzeń systemu, używa-nie dowolnych nieoficjalnych podzespołów, oraz dostosowywanie projektu dokład-nie do potrzeb użytkownika. Bardzo dużą zaletą jest możliwość pisania programówz praktycznie każdej platformy, łącznie z mobilnymi systemami operacyjnymi. Naj-większa wada systemu - brak zintegrowanego edytora, jest jednocześnie wielką zaletą.Wadą braku edytora jest potrzeba samodzielnej i skomplikowanej konfiguracji sys-temu, co w przypadku wielu użytkowników platformy Lego Ev3, zwłaszcza tych naj-młodszym może okazać się barierą nie do pokonania. Natomiast dla wymagającychprogramistów spodziewających się braku nałożonych ograniczeń jest to olbrzymiazaleta. Dlatego właśnie to doświadczonym programistom system ten jest najbardziejpolecany, do projektów małych i dużych.

5.2.3 Charakterystyka projektów dla środowiska Matlab

Środowisko Matlab pod względem samego tworzenia oprogramowania robotówjest najbardziej ograniczonym. Największymi atutami programu jest przedstawianiedanych i wyników w postaci wykresów, tworzenie modeli matematycznych, używanieskomplikowanych działań matematycznych, oraz symulowanie robota w programieSimulink. Program Matlab polecany jest do projektów, których część robotycznaograniczona jest do minimum, natomiast główny nacisk położony jest na zbiera-nie danych i analizowanie zachowania robota. W prostszych słowach najlepszymiprojektami są roboty o bardzo prostej funkcji, z użyciem niewielu elementów aktyw-nych, gdzie badana jest problematyka precyzji robota, optymalności algorytmów,czy zgodności zachowania robota z jego modelem wirtualnym. Doskonałe środowi-sko dla studentów robotyki i automatyki w projektach poświęconych analizie robotaopartego na modelach matematycznych i fizycznych.

5.2.4 Wniosek ogólny

W ramach pracy został zbudowany robot o solidnej konstrukcji, którego zada-niem jest układanie Kostki Rubika. Na robota tego napisane zostały dwa programynapisane w dwóch różnych środowiskach programistycznych. Została również pod-jęta próba napisania programu w środowisku Matlab, jednak ograniczone możliwościrozszerzenia programu dla technologii Lego Mindstorms zadecydowały o wyklucze-niu środowiska Matlab z fazy implementacyjnej. Oba programy napisane w środowi-skach ROBOTC i ev3dev spełniają wszystkie założenia sformułowane w sekcji 3.2.Robot w większości przypadków testowych po uruchomieniu dowolnego z dwóch

5.2. WNIOSKI 43

programów poprawnie układa pomieszaną Kostkę. Nieudane próby wynikają jedy-nie z wpływu oświetlenia zewnętrznego, które powoduje pomyłkę przy skanowaniukolorów czerwonego i żółtego. Przy żadnej innej fazie pracy robota poza fazą skano-wania nie występowały problemy. Stworzenie robota było jednak tylko częścią po-niższej pracy. Ważnym zagadnieniem była ocena testowanych środowisk. Analiza taprzebiegła pomyślnie, zostały sformułowane cechy pozytywne i negatywne każdegoze środowisk. Zostały one zestawione ze sobą w tabeli porównawczej, a na konieczostały przedstawione profile projektów, które najbardziej pasują do poszczególnychśrodowisk. W związku z powyższym można stwierdzić, że praca przebiegła zgodniez planem, a wyniki są satysfakcjonujące.


Bibliografia

[1] Robot chirurgiczny da Vinci - artykuł. http://www.asimo.pl/modele/

davinci.php.

[2] Robotyka podwodna - artykuł. http://yadda.icm.edu.pl/yadda/element/

bwmeta1.element.baztech-article-BSW1-0109-0006/c/Gieldzinski.pdf.

[3] Robotyka.com: Teoria robotyki. http://www.robotyka.com/teoria.php/

teoria.4.

[4] Secure Shell - wikipedia angielska.

[5] Strona główna dodatku LEGO Mindstorms EV3 Support Package. http:

//www.mathworks.com/hardware-support/lego-mindstorms-ev3-matlab.

html.

[6] Strona główna konkursu Mini Urban Challenge. http://www.

robotvirtualworlds.com/mini-urban-challenge/?_ga=1.160675512.

469940421.1427281178.

[7] Strona główna produktu Simulink. http://www.mathworks.com/products/

simulink/.

[8] Strona główna projektu Mindcub3r. http://mindcuber.com/index.html.

[9] Strona główna projektu NASA Curiosity Rover. https://www.nasa.gov/

mission_pages/msl/index.html.

[10] Strona internetowa produktu LEGO Mindstorms EV3 EducationExpansion Set. https://education.lego.com/en-us/products/

lego-mindstorms-education-ev3-expansion-set/45560.

[11] Wstęp do Robotyki - Wykład 1. http://elka.pw/obieralne/wr/wyk/WR_cz1.pdf.

45

http://www.asimo.pl/modele/davinci.php

http://www.asimo.pl/modele/davinci.php

http://yadda.icm.edu.pl/yadda/element/bwmeta1.element.baztech-article-BSW1-0109-0006/c/Gieldzinski.pdf

http://yadda.icm.edu.pl/yadda/element/bwmeta1.element.baztech-article-BSW1-0109-0006/c/Gieldzinski.pdf

http://www.robotyka.com/teoria.php/teoria.4

http://www.robotyka.com/teoria.php/teoria.4

http://www.mathworks.com/hardware-support/lego-mindstorms-ev3-matlab.html



http://www.robotvirtualworlds.com/mini-urban-challenge/?_ga=1.160675512.469940421.1427281178



http://www.mathworks.com/products/simulink/

http://www.mathworks.com/products/simulink/

http://mindcuber.com/index.html

https://www.nasa.gov/mission_pages/msl/index.html

https://www.nasa.gov/mission_pages/msl/index.html

https://education.lego.com/en-us/products/lego-mindstorms-education-ev3-expansion-set/45560

https://education.lego.com/en-us/products/lego-mindstorms-education-ev3-expansion-set/45560

http://elka.pw/obieralne/wr/wyk/WR_cz1.pdf

http://elka.pw/obieralne/wr/wyk/WR_cz1.pdf

46 BIBLIOGRAFIA

[12] Zintegrowane środowisko programistyczne - wikipedia definicja. https://pl.

wikipedia.org/wiki/Zintegrowane_środowisko_programistyczne.

https://pl.wikipedia.org/wiki/Zintegrowane_�rodowisko_programistyczne

https://pl.wikipedia.org/wiki/Zintegrowane_�rodowisko_programistyczne

Documents

PRACADYPLOMOWAINŻYNIERSKA - … · rok akademicki 2015/2016 politechnika warszawska wydziaŁ elektroniki i technik informacyjnych instytut automatyki i informatyki stosowanej pracadyplomowainŻynierska