docPrzegląd środowisk programistycznych dla LEGO Mindstorms EV3
download 
Reklamacja Transkrypt
Przegląd środowisk programistycznych dla LEGO Mindstorms EV3
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 Mindstorms EV3. Przegląd miał charakter praktyczny, bowiem opierał się na stworzeniu programu robota zbudowanego z LEGO Mindstorms. Robot miał za zadanie układać kostkę Rubika. Zadanie to zostało zrealizowane, 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ść. Słowa kluczowe: Mindstorms EV3, ROBOTC, Matlab, ev3dev, Kostka Rubika. Abstract Title: Overview of programming environments for LEGO Mindstorms EV3, verified by Rubik’s Cube solving robot. The aim of this thesis was an overview of different programming environments for LEGO Mindstorms EV3. The overview had a practical nature, because it was based on the creation of a program for the robot built with LEGO Mindstorms. Robot built with LEGO had the task of solving Rubik’s cube. This task was accomplished by writing three programs in environments, ROBOTC, ev3dev and Matlab. All three programs despite the implementation in different programming languages share the same 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 2.1 13 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 4.1 31 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 . . . . . . . . . . . . . . . 34 4.3 Implementacja w systemie ev3dev . . . . . . . . . . . . . . . . . . . . 35 4.3.1 Moduł zmiennych globalnych - plik “globals“ . . . . . . . . . . 35 4.3.2 Moduł manipulacji - klasa “manipulate“ 4.3.3 Moduł kalibracji - klasa “calibrate“ . . . . . . . . . . . . . . . 36 4.3.4 Moduł wyświetlania - klasa “display“ . . . . . . . . . . . . . . 36 4.3.5 Moduł skanowania - klasa “scan_cube“ . . . . . . . . . . . . . 37 4.3.6 Moduł rozwiązywania - klasa “solver“ . . . . . . . . . . . . . . 37 4.3.7 Moduł skanuj i rozwiąż - klasa “scan_and_solve“ . . . . . . . 37 5 Podsumowanie . . . . . . . . . . . . 36 39 5.1 Wyniki analizy porównawczej . . . . . . . . . . . . . . . . . . . . . . 39 5.2 Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.1 Charakterystyka projektów dla środowiska ROBOTC . . . . . 41 5.2.2 Charakterystyka projektów dla środowiska ev3dev . . . . . . . 41 5.2.3 Charakterystyka projektów dla środowiska Matlab . . . . . . . 42 5.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 strukturę (sekcja 1.4). 1.1 Wprowadzenie Praca ta jest ściśle związana z zagadnieniem robotyki. W celu właściwego odbioru pracy 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 roku przez Robotics Industries Association, “robot“ to: “Programowalny, wielofunkcyjny manipulator zaprojektowany do przenoszenia materiałów, części, narzędzi lub specjalizowanych urządzeń poprzez różne programowalne ruchy, w celu realizacji różnorodnych zadań“. [3] Natomiast szersze pojęcie “robotyki“ dr inż. Wojciech Szynkiewicz tłumaczy: “Robotyka zajmuje się projektowaniem, budową, badaniem i wykorzystaniem robotów“. [11] Robotyka jest jedną z najszybciej rozwijających się technologii dzisiejszych czasów. Zakres jej zastosowań jest coraz większy, a ilość dziedzin, w których wyspecjalizowane roboty zastępują człowieka stale się rozszerza. Niemniej jednak robotyka jest niezwykle złożoną dziedziną nauki. Przede wszystkim ze względu na to, że zawarty jest w niej szereg bazowych, acz skomplikowanych dyscyplin takich jak: mechanika, elektronika, matematyka, automatyka, informatyka, czy nawet biologia. Biorąc pod uwagę tak wielopłaszczyznowy zakres tematów, ilość ekspertów w tej dziedzinie jest bardzo ograniczona. Jednocześnie w obecnych czasach znacząco rośnie zapotrzebowanie na specjalistów właśnie z zakresu robotyki. Aby poradzić sobie z tym problemem, a zarazem wzbudzić zainteresowanie tematem 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 tworzą gotowe lub nieskomplikowane w złożeniu roboty, dostępne dla szerokiej rzeszy odbiorcó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ą proces programowania 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 nawet dla laików, rozbudza zainteresowanie, chęć zgłębiania zagadnienia, a co za tym idzie 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 od 1998 roku seria zestawów, łączący klocki LEGO z czujnikami elektronicznymi, serwomechanizmami i komputerową jednostką centralną. Technologia pozwala między innymi na konstruowanie robotów i układów automatyki oraz na ich odpowiednie oprogramowywanie. Najnowszym produktem z serii jest LEGO Mindstorms EV3 wprowadzonym na rynek w 2013 roku. Użycie klocków LEGO jako głównego budulca robotów, oraz dostarczenie użytkownikowi intuicyjnych narzędzi do tworzenia oprogramowania, spowodowało, że technologia ta znajduje odbiorców nawet wśród dzieci. To wspaniały sposób na wprowadzanie młodych ludzi w świat robotyki. Jednocześnie platforma Mindstorms ma na tyle nieograniczone zastosowania, że pozwala na budowę całego spektrum dużo bardziej skomplikowanych i wielofunkcyjnych robotów dla bardziej zaawansowanych użytkowników. Właśnie dla nich rozwijany jest szereg profesjonalnych środowisk programistycznych, przez niezależne od grupy 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 praca jest 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 niemal każdą dziedziną nauki i życia. Roboty obecne są w życiu codziennym, podczas prostych czynności i zabaw, ale również w najbardziej skomplikowanych działaniach takich jak operacje chirurgiczne [1], badanie dna oceanów [2], czy eksploracja kosmosu [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 skali możliwości i przeznaczeniu danego robota. Uściślając “środowisko programistyczne to aplikacja lub zespół aplikacji służących do tworzenia, modyfikowania, testowania i konserwacji oprogramowania“ [12], jest to zatem miejsce, w którym tworzony jest swoisty “umysł“ przypisany do konkretnego urządzenia, “umysł“ który wydaje rozkazy, wyznacza zadania i steruje precyzją ich wykonania. Środowisko programistyczne i związany z nim ściśle język programowania wpływa zatem bezpośrednio na łatwość samego procesu programowania. Środowisko wraz z językiem dostarczają programiście narzędzi, od których zależy czy proces oprogramowania robota będzie przebiegał sprawnie, wygodnie i szybko, oraz czy ogólne założenia programowe da się w technologiach dostarczanych przez środowisko zrealizować. Co ważne środowiska różnią się od siebie dostarczając programistom bardziej lub mniej zaawansowanych bibliotek języków programowania. W związku z tym zrealizowanie 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 wykonanie pewnych 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, debugowania, 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ędzi dostępnych w danym środowisku oraz ich jakość ma decydujący wpływ na to do jakich projektów dane środowisko się nadaje oraz decyduje o wygodzie pracy. Dlatego tak istotny jest dobór odpowiedniego środowiska programistycznego do konkretnego projektu. 10 ROZDZIAŁ 1. WSTĘP 1.3 Cel pracy Celem pracy jest przegląd trzech różnych środowisk programistycznych przeznaczonych 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 pomieszanym, 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żda ze ścian Kostki składała się z elementów w tym samym kolorze. Konstrukcja robota oparta jest na istniejącym projekcie “Mindcub3r“ [8]. Na podstwie tego schematu został skonstruowany robot nazwany dla potrzeb pracy “Rubik Solver“, widoczny na rysunku 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ący Kostkę Rubika wymaga skomplikowanego oprogramowania, wykorzystującego większość funkcji biblioteki języka dostępnych w środowiskach, oraz narzędzi środowiskowych. Ze względu na złożoność programu, każdorazowa implementacja w danym środowisku skutkowała dogłębnym poznaniem systemu i wykorzystaniem jego wielu możliwości. W poniższej pracy sformułowane zostały wnioski podsumowujące właściwości każ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 zbudowania i oprogramowania robota. Rozdział 3 przedstawia przebieg zadania inżynierskiego oraz formułuje założenia projektowe. Rozdział 4 poświęcony jest realizacji implementacji programów w środowiskach programistycznych. Ostatni rozdział 5 to podsumowanie wyników pracy w formie analizy porównawczej oraz sformułowane wnioski. 12 ROZDZIAŁ 1. WSTĘP Rozdział 2 Wykorzystane technologie W pracy wykorzystywany był sprzęt (sekcja 2.1), algorytmy (sekcja 2.2) oraz programy (sekcja 2.3). 2.1 Wykorzystany sprzęt Sprzętem potrzebnym do wykonania pracy był zestaw LEGO Mindstorms EV3 Education 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ący budowanie robotów LEGO Mindstorms EV3 Education Core Set. Jest to wersja edukacyjna produktu EV3 skierowana głownie do studentów i uczniów, ale także bardziej profesjonalnych użytkowników. W skład zestawu wchodzą elementy mechaniczne - klocki LEGO Technic, oraz aktywne - serwomotory, sensory i kostka EV3. Elementy mechaniczne wykorzystuje się do budowy nieruchomych części robota i nie mają większego znaczenia w poniższej pracy. Warto jednak poświęcić nieco uwagi elementom aktywnym, ponieważ to one stanowią o możliwościach i potencjale robota. Elementy aktywne przedstawione są na rysunku 2.1. 13 14 ROZDZIAŁ 2. WYKORZYSTANE TECHNOLOGIE Rysunek 2.1: Serwomechanizmy, czujniki oraz kostka EV3 - elementy aktywne zestawu Mindstorms EV3 Education Core Set Elementy aktywne: • Programowalna kostka EV3 - komputer z systemem Linux oparty na procesorze ARM taktowanym częstotliwością 300MHz. Na pamięć komputera składa się 16- sto megabajtowa pamięć stała Flash rozszerzalna dzięki portowi kart microSDHC, oraz 64 MB pamięci operacyjnej RAM. W kostce znajdują się cztery porty wejściowe do łączenia z czujnikami, oraz 4 wyjściowe przeznaczone dla reaktorów, wszystkie oparte na standardzie RJ-12. Do komunikacji z komputerem zewnętrznym służą porty USB i Mini-USB, a w standardzie bezprzewodowym technologia Bluetooth oraz opcjonalnie Wi-Fi poprzez dodatkowy adapter, do kupienia oddzielnie. Wszystko to wieńczy panel interakcji z użytkownikiem, na którym znajduje się 6 programowalnych przycisków, kolorowe diody LED, głośnik oraz monochromatyczny wyświetlacze LCD o rozdzielczości 178x128 pikseli. • Dwa duże serwomechanizmy - napędy dużej mocy, o momencie siły za przekładnią wynoszącym 0.2 Niutonometra. Maksymalna prędkość kątowa wynosi 160-170 obrotów na minutę. Mechanizmy wyposażone są w enkodery przyrostowe, czyli czujniki obrotu o rozdzielczości 360 impulsów na obrót. Osie obrotu dużych serw ułożone są prostopadle względem korpusu podzespołu. • Średni serwomechanizm - napęd o mniejszym gabarycie i mniejszym momencie siły za przekładnią, 0.08 Niutonometra. Kosztem zmniejszenia momentu moż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 wyposażone w czujnik obrotu o rozdzielczości 360 impulsów/obrót. Oś obrotu napędu znajduje się wzdłuż najdłuższego wymiaru mechanizmu. • Ultradźwiękowy czujnik odległości - sonar, który informuje o dystansie robota do najbliższej przeszkody, działa na zasadzie emitowania i wyłapywania odbitych od przeszkód fal ultradźwiękowych. Dzięki użyciu tej zaawansowanej technologii stosowanej m.in. w radarach lotniczych, czujnik charakteryzuje się wysoką rozdzielczością ok. 1 cm. Sonar poprawnie działa gdy przeszkoda znajduje się w odległości od 3 do 250 cm. Dodatkowo oprócz funkcji pomiaru odległ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żony jest w ledowy emiter światła o kolorach bazowych: czerwieni, zieleni i koloru niebieskiego oraz wiązki światła białego. Emitowane z sensora fale świetlne po odbiciu od przedmiotu trafiają do soczewki, zbierającej je ponownie. Następnie czujnik bada natężenie odbitej fali. W zależności od tego jakie światło emituje sam 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. Czujnik koloru 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-55mm od czujnika. • Dwa czujniki dotykowe - analogowe czujniki dotykowe wykrywają przyciśnięcie bądź zwolnienie przycisku umiejscowionego z przodu czujnika. Przycisk skonstruowany jest specjalnie w taki sposób aby możliwe było dołączanie do niego standardowych klocków Lego Technic. Głębokość na jaką przycisk może być maksymalnie wciśnięty wynosi 4mm. Czujnik ten można wykorzystać na dwa sposoby: wykrywanie przeszkód przez robota, oraz jako dodatkowy przycisku dla użytkownika. • Czujnik żyroskopowy - cyfrowy czujnik żyroskopowy mierzy ruchy obrotowe robota, oraz zmiany w jego orientacji. Z jego pomocą można zwiększyć dokł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 obrotu czujnika; tryb żyroskopowy mierzy prędkość kątową, gdzie maksymalna 16 ROZDZIAŁ 2. WYKORZYSTANE TECHNOLOGIE 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 kostki polega na takim układaniu kolorowych kwadratów, aby każda ze ścian miała wszystkie kwadraty w jednym kolorze. Rysunek 2.2: Kostka Rubika Budowa kostki: Kostka zbudowana jest z 26 sześcianów oraz przegubu, który umożliwia zewnętrznym warstwom kostki obrót wokół osi środka kostki, będącej prostopadłą do płaszczyzny danej warstwy. Powierzchnie sześcianów widoczne z zewnątrz pomalowane są na sześć kolorów: czerwony, zielony, niebieski, żółty, pomarańczowy i biały. Na poniższym rysunku przedstawiona jest Kostka Rubika firmy Rubik’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ązaniu jest jednokolorowa. • Ścianka kostki - ściana jednego z 26 małych sześcianów widocznych na zewnątrz, posiadająca jeden z sześciu kolorów. 2.2. WYKORZYSTANE ALGORYTMY 2.2 17 Wykorzystane algorytmy W pracy użyty został algorytm układania Kostki Rubika. Istnieje bardzo dużo technik układania Kostki. Zagadnienie znajdywania optymalnych algorytmów, jest trudne ze względu na olbrzymią liczbę kombinacji różnych ułożeń kostki, która wynosi ponad 43 tryliardy (43 252 003 274 489 856 000). W 2010 roku grupa matematyków dzięki mocy obliczeniowej serwerów komputerowych udowodniła, że dowolnie pomieszaną kostkę da się ułożyć wykonując maksymalnie 20 “ruchów“. Projektowanie nowego algorytmu układania Kostki Rubika, to niezwykle skomplikowany i wymagający proces. Ponieważ, nie jest on związany z tematem pracy, wykorzystany został już istniejący algorytm. Jest on częścią projektu Mindcub3r, rozwijanego przez Davida Gilday’a, pasjonatę tworzenia robotów z LEGO, rozpoznawalną postać w internetowym świecie LEGO. [8] O samym algorytmie niewiele wiadomo, jako że jest on dostępny tylko w formie kodu binarnego i uruchamiany jest z poziomu odrębnego programu. Nie jest znany kod źródłowy tego programu, nazywanego w dalszej części pracy “solverem“. Wiadomo jednak, że zaimplementowany został tu algorytm, który potrafi układać Kostkę Rubika w średnio 24 ruchach. Komunikacja programu robota z solverem odbywa się za pomocą zapisu i odczytu współdzielonych plików. 2.3 Wykorzystane oprogramowanie Do oprogramowania wykorzystanego w pracy inżynierskiej należą programy, ROBOTC (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 systemów robotycznych, takich jak: VEX IQ, VEX EDR, VEX PIC, TETRIX, Arduino UNO, 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 systemie używa. Język ROBOTC opiera swoją składnie na powszechnie znanym języku C i przez to jest do niego bliźniaczo podobny. Systemem operacyjnym wymaganym przez ROBOTC jest Windows, ale możliwe jest uruchamianie programu poprzez maszynę wirtualną. Poniżej na rysunku 2.4 okno programu ROBOTC. 18 ROZDZIAŁ 2. WYKORZYSTANE TECHNOLOGIE Rysunek 2.4: Okno programu ROBOTC Program jest kompleksowym środowiskiem, tak zwanym zintegrowanym środowiskiem programistycznym (ang. Integrated Development Environment, IDE ). Oznacza to, że dostarcza on narzędzi do pisania i edytowania kodu, a także umożliwia kompilację kodu i wysyłanie pliku binarnego na urządzenie, a wszystko to w jednym programie. 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 jego przestrzeni roboczej: Robot Virtual Worlds. Jest to odrębny, dodatkowo płatny program, który pozwala na symulację zachowania robota w graficznym świecie wirtualnym. 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 samouczek oraz szereg zajmujących wyzwań programistycznych. Okno programu Robot Virtual 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 Support Package 20 ROZDZIAŁ 2. WYKORZYSTANE TECHNOLOGIE Matlab to rozbudowany program komputerowy stworzonym do wykonywania ob- liczeń naukowych oraz tworzenia symulacji komputerowych. Płatny program tworzy firma MathWorks. Dostępny jest na systemach operacyjnych Windows, OS X, oraz Linux i Unix. Program jest dobrze znany przez uczniów studiów inżynierskich, jest on szeroko stosowany na uczelniach. Operuje się tu w języku Matlab opartym na języku C. Okno programu Matlab przedstawia rysunek 2.6. Dla programu dostępne są liczne biblioteki dodatkowe (ang. toolbox ), które powiększają zdolności programu Matlab o dodatkowe funkcje. Jednym z takich dodatków jest “LEGO Mindstorms EV3 Support Package“. [5] Dodatek ten umożliwia pisanie programów na roboty w technologii Mindstorms EV3. Działanie środowiska Matlab różni się od innych środowisk programistycznych dla robotów. Różnica polega na tym, że Matlab pełni rolę zdalnego kontrolera dla robota. 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ą do niego 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 zintegrowanym ś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 systemu Linux. Ponieważ kostka EV3 działa na systemie Linux, wystarczy wgrać obraz dysku innej dystrybucji Linux’a na kartę pamięci umieszczaną w kieszeni robota. Wówczas robot 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 niskopoziomowe sterowniki umożliwiające używanie czujników, motorów i samej kostki EV3. Na rysunku 2.7 znajduje się okno klienta SSH połączonego z robotem, który pracuje z uruchomionym systemem ev3dev. Podstawowym założeniem systemu jest otwartość i dostępność. Dzięki temu programiści z całego świata pomagają w rozwoju projektu. Efektem globalnej współpracy jest istnienie bibliotek współpracujących z robotem LEGO, napisanych w bardzo szerokiej gamie języków programistycznych. Użytkownik chcący pracować nad robotem w systemie ev3dev może wybierać wedle upodobań jeden z dostępnych języków: C++, Node.js, Python, Google Go, C, Clojure, lua, Perl. Proces rozwijania oprogramowania robotycznego poprzez system ev3dev wygląda nastę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ędu na ograniczone możliwości procesora robota kompilacja taka zajmuje dużo czasu. Dostępne są też dodatkowe narzędzia umożliwiające np. debugowanie programu w sesji SSH. 22 ROZDZIAŁ 2. WYKORZYSTANE TECHNOLOGIE Rozdział 3 Projekt systemu W rozdziale tym opisano kolejne etapy przebiegu zadania (sekcja 3.1) i scharakteryzowano założenia projektowe (sekcja 3.2). 3.1 Przebieg zadania W poniższej pracy wyodrębnione zostały poszczególne etapy pracy nad robotem LEGO. Głównym zadaniem był przegląd kilku środowisk programistycznych oraz ich przetestowanie i porównanie z perspektywy programowania robota. Etap 1: Stworzenie fizycznego modelu robota Pierwszy etap polegał na wybraniu odpowiedniego robota. Odpowiedniość polegał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ęzyka programowania. Dzięki temu środowiska mogą być gruntownie przetestowane, za pomocą użycia zaledwie jednego urządzenia. • Powtarzalność - robot będzie zachowywał się powtarzalnie przy otrzymaniu tych samych danych wejściowych. Oznacza to, że za każdym razem, gdy robot dostaje identycznie pomieszaną kostkę, układa ją za pomocą tej samej sekwencji ruchów. Jest to cecha, która bardzo ułatwia proces testowania robota, w przeciwieństwie do robotów niepowtarzalnych, gdzie ciężko jest obiektywnie porównać zachowania robota przy kolejnych uruchomieniach. 23 24 ROZDZIAŁ 3. PROJEKT SYSTEMU • Niezależność od środowiska - robot rozwiązujący Kostkę Rubika jest mało zależny od czynników zewnętrznych. Jedynie oświetlenie może wpływać na działanie czujnika światła, jednak da się umniejszyć ten wpływ stosując odpowiednią kalibrację wstępną. Dzięki niewielkiemu wpływowi czynnikó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 to czynnik wpływający na łatwość testowania robota oraz środowisk. Gdy koncepcja robota była określona, kolejnym zadaniem było znalezienie i 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ów aktywnych jedynie z zestawu EV3 Education Core Set. Konstrukcja robota “Rubik solver“ 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ąpione innymi elementami z innych zestawów LEGO. [10] Oprócz tego nie było potrzeby wykorzystywać czujnika odległości do wykrywania kostki, tak jak w projekcie Mindcub3r. Na rysunku 3.1 widoczne są oba roboty. Rysunek 3.1: Projekt robota “Mindcub3r“(po lewej) i robot “Rubik solver“ (po prawej) Robot “Rubik solver“ potrafi skanować oraz manipulować kostką dzięki ruchomym układom zbudowanym z siłowników, czujnika koloru oraz klockom LEGO Technic. 25 3.1. PRZEBIEG ZADANIA Ruchome układy zostały nazwane: Rysunek 3.2: Spinner • “Spinner“ - obracająca się platforma przytrzymująca kostkę. “Spinner“, widoczny 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 “Flipperem“. Za obracanie platformą odpowiada duży serwonapęd umiejscowiony pod 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 geometryczne równe 3. Rysunek 3.3: Camera • “Camera“ - ruchomy wysięgnik na którego końcu umieszczony jest czujnik koloru. “Camera“, widoczna na rysunku 3.3, umożliwia skanowanie kolejnych ścianek kostki. Skanowanie odbywa się poprzez zgranie w jednym czasie dwóch ruchów: obrotowego ruchu platformy i przesuwnego ruchu wysięgnika. W ten sposó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ą 26 ROZDZIAŁ 3. PROJEKT SYSTEMU 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 ustawienie kół zębatych zmienia oś obrotu z wejściowej pionowej, na poziomą oraz zwiększa precyzję ruchów. Rysunek 3.4: Flipper • “Flipper“ - ruchome ramie robota pełniące dwie funkcje. Pierwszą funkcją jest obracanie kostki na platformie w osi poziomej, poprzez “naciągnięcie“ kostki na barierkę platformy. “Flipper”, widoczny na rysunku 3.4, skonstruowany jest w ten sposób, że wykonując ruch w kierunku przeciwnym do ruchu obracającego kostkę, ramię nie obraca kostki w przeciwnym kierunku, dzięki temu możliwy jest powrót ramienia do pozycji wyjściowej po wykonaniu manewru obracającego. Drugą funkcją ramienia jest przytrzymywanie kostki w chwili gdy platforma wykonuje obrót, w celu obrócenia dolnej warstwy kostki. Wykonywaniem ruchów ramienia zajmuje się duży serwomotor umieszczony przy osi obrotu ramienia. Motor połączony jest z ramieniem za pomocą przegubu w kształcie krzywej łamanej. Dzięki takiemu kształtowi przegubu ramie wykonuje 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 nim korbowó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 stworzenie oprogramowania w pierwszym ze środowisk. Jako pierwsze wybrane zostało środowisko ROBOTC, jako że autor pracy miał w nim największe doświadczenie. Napisanie pierwszego programu jest najbardziej czasochłonnym zadaniem, dlatego wybranie ś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 na przepisanie go do kolejnego środowiska, którym był Matlab. Tutaj nastąpiły pewne komplikacje, 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 przypadku poprzednich środowisk na tym etapie pracy nastąpiło napisanie programu w tym środowisku. Etap 5: Porównanie wygody implementacji kodu w powyższych środowiskach Po sfinalizowaniu wszystkich etapów związanych z implementacją nadszedł czas na wyciągnięcie wniosków, na temat pracy w każdym ze środowisk. Porównanie ich ze sobą, zestawienie najważniejszych atrybutów tych programów w tabeli porównawczej. 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 projektowych było sformułowanie założeń jakie robot, programy i praca muszą spełniać. Dzięki założeniom droga do celu jest prostsza. Założenia zapobiegają wykonywania zbędnych czynności, które opóźniają sfinalizowanie projektu. Założeniami projektu są: • Solidna konstrukcja robota - robot musi być umieszczony na stabilnej platformie. Konstrukcja nie powinna zmieniać się w trakcie eksploatacji, powinna 28 ROZDZIAŁ 3. PROJEKT SYSTEMU być w stanie wytrzymać minimum 10 kolejnych uruchomień programu, bez potrzeby wykonywania napraw. Robot powinien być niepodatny na uszkodzenia przy przenoszeniu i transporcie. • Robot zbudowany z wykorzystaniem możliwym minimum części - “Im prościej tym lepiej.“ “Im mniej tym więcej.“ Te motta towarzyszyły projektowaniu robota. W dodatku ograniczona liczba dostępnych części wymuszała minimalizm konstrukcji. • Wykorzystanie przynajmniej dwóch środowisk programistycznych - zakładanym 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 minut - odgórne ograniczenie czasu potrzebnego robotowi do wykonania zadania, zmuszało do uzyskania sprawnie działającego robota. Czas liczy się od rozpoczęcia skanowania, do chwili gdy Kostka jest w pełni ułożona. W efekcie średni czas jest znacznie krótszy niż zakładane ograniczenie, dzięki temu testowanie robota przechodzi bardzo sprawnie. • Programy nieobarczone błędami krytycznymi - nie istnieje jeden, idealny program spełniający daną funkcjonalność, często programiści niezadowoleni z efektów, poddają program ciągłym udoskonaleniom. Rozwijanie oprogramowania potrafi przez to trwać dużo dłużej niż zadowalające minimum, a w wielu 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 jasno stwierdza, kiedy można zakończyć proces ulepszania kodu. Dzięki temu ogólny proces tworzenia pracy inżynierskiej ulega skróceniu, a zaoszczędzony czas można przeznaczyć na bardziej istotne elementy projektu. • Programy z różnych środowisk mające możliwe podobne działanie - oprogramowanie robota z różnych środowisk powinno być napisane w możliwie podobny sposób, tak aby zachowanie robota było nie do rozróżnienia. • Uruchomione programy nie mogą niszczyć konstrukcji robota oraz jego elementów - programy muszą mieć tak dobrane wartości mocy i prędkości elementów ruchomych, 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 - oprogramowanie robota składa się z modułów odpowiadających za konkretne funkcje. Wymaganiem jest aby w różnych środowiskach programy podzielone były na takie same moduły. • Robot ma trzy podejścia do właściwego zeskanowania Kostki - w sytuacji gdy robot napotyka na problem w trakcie skanowania Kostki zliczane są nieudane próby. Po trzeciej próbie robot przerywa wykonywanie programu. Dzięki temu unika się sytuacji, w której robot bez końca podejmuje nieudane próby zeskanowania kostki. • Manipulacja Kostką przez robota musi przechodzić bezbłędnie - współczynniki ruchu manipulatorów powinny być w taki sposób dobrane, aby nie popełniane był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 nie zmieniła swojej orientacji. • Robot po ułożeniu Kostki musi być gotowy do kolejnego układania - stan robota po zakończeniu udanego układania Kostki musi być dokładnie taki sam jak stan robota przed ułożeniem Kostki. Gwarantuje to płynność działania robota w kolejnych uruchomieniach. Przyspiesza i ułatwia testowanie robota. 30 ROZDZIAŁ 3. PROJEKT SYSTEMU 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óry wykorzystuje składnię języka C. W tym właśnie języku napisany jest program robota. Program podzielony jest na moduły. Moduły odzwierciedlają konkretną funkcję, za którą kod jest odpowiedzialny. Na diagramie UML 4.1 widoczny jest podział na pliki odpowiadające oddzielnym modułom programu. W kolejnych podsekcjach opisane 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 trzy funkcje. 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 zakończeniu kalibracji wołana jest funkcja “displayPatternSelection()“ z modułu wyświetlania, która wyświetla stosowny komunikat i oczekuje na wciśnięcie przycisku rozpoczynającego skanowanie. Gdy przycisk zostaje naciśnięty, wówczas wywoływana 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. Zdefiniowane są tutaj tablice ułożeń kostki, flagi programu, współczynniki sterowania silnikami itp. 4.1.3 Moduł manipulacji - plik “manipulate“ Moduł manipulacji jest najważniejszą częścią programu. Zdefiniowane są tu funkcje, 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: ruchu silnika 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 momentu zakończenia ruchu. Dostarczenie tak wysokopoziomowych funkcji operowania motorami pozwala na sprawne pisanie programu i nie wymaga konstruowania własnych funkcji. Z modułu manipulacji korzystają wszystkie inne moduły oprócz modułu rozwiązywania. 4.1. IMPLEMENTACJA W ŚRODOWISKU ROBOTC 4.1.4 33 Moduł kalibracji - plik “calibrate“ Moduł kalibracji dostarcza metod potrzebnych do ustawienia ruchomych części robota w odpowiednich pozycjach wyjściowych. Zawiera też funkcję, która sprawdza czy uruchomiony jest zewnętrzny program odpowiedzialny za znajdywanie optymalnej sekwencji rozwiązywania Kostki. Moduł ten wywoływany jest głównie przy uruchomieniu programu, oraz po zakończeniu działania w celu powrotu robota do stanu wyjściowego. 4.1.5 Moduł wyświetlania - plik “display“ Moduł ten odpowiada za wyświetlanie komunikatów na ekranie robota, oraz obsługę przycisków znajdujących się na panelu przednim kostki EV3. Do wyświetlanych komunikatów zaliczamy: nazwa obecnie wykonywanej operacji (kalibracja, skanowanie, kalkulacja, rozwiązywanie), wyświetlanie błędów, ewentualny wybór wzoru układanego na Kostce, czy ilość pozostałych ruchów potrzebnych do rozwiązania Kostki. 4.1.6 Moduł skanowania - plik “scan_cube“ Plik “scan_cube.c“ odpowiada za wszelkie operacje związane ze skanowaniem koloró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 oddzielne wą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 czujnika 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 obliczającym optymalne rozwiązanie Kostki. Komunikacja pomiędzy dwoma programami odbywa się za pomocą dwóch plików tekstowych znajdujących się w pamięci robota. Pierwszy plik nazywa się mc3cmd.rtf i służy do przekazywania kolejnych komend. W pliku mc3dat.rtf umieszczane są przez program odczytane wartości kolorów ścianek robota. W tym samym pliku jako odpowiedź zapisywane są przez solver informacje: liczba kroków rozwiązywania, oraz szereg cyfr reprezentujących sekwencję układania Kostki. 34 ROZDZIAŁ 4. REALIZACJA Proces komunikacji przebiega w kolejności: 1. Moduł rozwiązywania najpierw zapisuje w pliku mc3cmd.rtf komunikat rozpoczę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ów kolejnych ścianek Kostki. 4. Po obliczeniu optymalnego rozwiązania “solver“ zapisuje w pliku mc3dat.rtf ilość kroków rozwiązania oraz sekwencje ruchów układania kostki 5. Na koniec “solver“ w pliku mc3out.rtf umieszcza raport pracy programu “solver“ 4.1.8 Moduł skanuj i rozwiąż - plik “scan_and_solve“ Moduł ten zawiera tylko jedną funkcję. Funkcja ta służy do uruchamiania kolejno wszystkich metod potrzebnych do tego aby właściwie zeskanować, obliczyć ruchy i ułożyć Kostkę Rubika. W przypadku trzech nieudanych prób ułożenia Kostki moduł ten zaprzestaje wykonywać dalsze próby, wyświetla stosowny komunikat błędu i ustawia robota w pozycji wyjściowej. 4.2 Próba implementacji w środowisku Matlab Przed rozpoczęciem implementacji w programie Matlab miał miejsce przegląd tego środowiska. Celem tego przeglądu było poznanie możliwości jaki ten program oferuje. W trakcie przeglądu wyszło na jaw jak ograniczoną funkcjonalność reprezentuje sobą środowisko Matlab w tym zastosowaniu. W szczególności najbardziej istotnymi ograniczeniami były: • Brak możliwości przesłania programu na urządzenie - program Matlab pozwala jedynie na pracę w formie zdalnej kontroli robota. Program wykonywany jest na komputerze, który tylko i wyłącznie drogą komunikacji z robotem wysyła mu na bieżąco kolejne instrukcje do wykonania. Oznacza to, że niemożliwe jest samodzielne funkcjonowanie robota. • Ograniczona liczba funkcji bibliotecznych - charakter zdalnego kontrolera programu Matlab powoduje mocno ograniczony zbiór gotowych funkcji bibliotecznych. 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 jasności światła czujnika koloru. Brak bardziej skomplikowanych funkcji, np. obrotu serwonapędu z utrzymywaniem zadanej prędkości, dzięki algorytmowi PID, utrudnia i spowalnia pisanie skomplikowanych programów. • Brak operacji odczytu i zapisu plików na urządzeniu - W programie Matlab niemożliwe jest wykonywanie operacji na plikach znajdujących się w pamięci robota. Przez to nie jest możliwa komunikacja z zewnętrznym programem “solver“, który komunikuje się z oprogramowaniem robota właśnie poprzez wymienianie danych w plikach urządzenia. • Brak programowania wielowątkowego - program Matlab nie daje możliwości programowania współbieżnego robotów Mindstorms. Stanowi to silne ograniczenie. W wielu przypadkach da się przerobić oprogramowanie współbieżne na jednowątkowe, jednak może się to okazać czasochłonne oraz zmieniające zachowanie robota. W pozostałych dwóch środowiskach wielowątkowość była wykorzystywana. Te wszystkie czynniki wpłynęły na decyzję, że środowisko Matlab nie nadaje się do implementacji programu na robota “Rubik solver“. Tak więc po wstępnym zapoznaniu ze środowiskiem postanowione zostało, że robot oprogramowany zostanie w środowiskach ROBOTC i ev3dev, natomiast Matlab zostanie wykluczony 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 program podzielony został na klasy odpowiadające modułom programu. W funkcji main tworzone są kolejno wszystkie obiekty głównych klas modułów. Obiekty potrzebne metodom klas przekazywane są do nich poprzez argumenty wywołania metody. Do tego celu zdefiniowane zostały szablony metod. Na rysunku 4.2 przedstawiony został diagram klas programu napisanego w systemie ev3dev. W kolejnych podsekcjach opisane są wszystkie moduły programu. 4.3.1 Moduł zmiennych globalnych - plik “globals“ Tak jak w przypadku programu z ROBOTC wykorzystywany jest szereg zmiennych globalnych. Jest to prawie identyczny zestaw zmiennych, stałych i tablic jak w przypadku pliku “globals“ z programu napisanego w ROBOTC. 36 ROZDZIAŁ 4. REALIZACJA 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 servonapędami. Nie przeszkadza to jednak w tworzeniu własnych wysokopoziomowych funkcji. W klasie manipulate zaimplementowane zostały funkcje stworzone na wzór tych ze środowiska ROBOTC, ułatwiło to przepisywanie programu z pierwszego środowiska. W dodatku dzięki temu programy zachowują spójną konstrukcją, co było jednym 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ą formatowane, a są po prostu kolejnymi wypisanymi na ekranie liniami tekstu, tak jak w 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 wykorzystują 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ętrznym programem “solver“. Komunikacja przebiega w dokładnie ten sam sposób co w środowisku ROBOTC ponieważ wykorzystuje dokładnie ten sam zewnętrzny program rozwiązujący. 4.3.7 Moduł skanuj i rozwiąż - klasa “scan_and_solve“ Klasa ta zajmuje się uruchamianiem kolejnych metod ze wszystkich klas, tak aby 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 robot ustawiany w pozycji wyjściowej. 38 ROZDZIAŁ 4. REALIZACJA 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 wybranego edytora, ** możliwość doinstalowania modułu 39 40 ROZDZIAŁ 5. PODSUMOWANIE Analiza porównawcza przebiegła sprawnie, dzięki temu, że środowiska zostały poznane od strony implementacyjnej. Udało się uzyskać wyniki charakteryzujące każ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ęciem pierwszych 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 funkcje, jak: kolorowanie składni kodu, czy automatyczne uzupełnianie wyrażeń. Dodatkowo bardzo przydatnym udogodnieniem jest przeglądarka wszystkich funkcji bibliotecznych, która dostępna jest tylko w programie ROBOTC. Ev3dev nie posiada dedykowanego edytora. Natomiast można użyć dowolnego edytora, który wspiera języki używane przez ev3dev. Dobranie własnego edytora wymaga samodzielnej konfiguracji, instalowania kompilatorów skrośnych i doinstalowywania potrzebnych rozszerzeń. Mimo wymaganego wysiłku przy konfiguracji, efekt może dorównywać edytorom środowisk ROBOTC i Matlab. Dodatkowym atutem wyróżniającym ev3dev jest otwartość kodu źródłowego tego projektu. • W przypadku testowania i wykrywania błędów środowiska ROBOTC i Matlab oferują wbudowane, wszystkie standardowe narzędzia potrzebne do tych procesów. Natomiast ev3dev standardowo nie posiada takich narzędzi, możliwe jest jednak doinstalowanie narzędzi, które można znaleźć w sieci. • Kompilatorem zintegrowanym mogą się pochwalić ROBOTC i Matlab jednak w przypadku tego drugiego kod binarny nigdy nie jest w całości wysyłany na robota, co wynika z faktu pracy środowiska w formie zdalnego kontrolera. ROBOTC i ev3dev umożliwiają również pracę w trybie zdalnej kontroli jednak standardowo, cały skompilowany program przesyłany jest na urządzenie. Dodatkowym atutem środowiska ev3dev jest możliwość kompilacji programu bezpośrednio na robocie. Umożliwia to przeprowadzenie całego procesu implementacji programu, za pomocą urządzenia umożliwiającego zdalny dostęp do robota bez konieczności używania komputera. Taki tryb pracy wygodny jest jedynie 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. Natomiast w środowisku ev3dev wymagana jest ręczna konfiguracja takiego połączenia, podczas gdy pozostałe programy posiadają wygodne zintegrowane moduły komunikacji. • Cechami wyróżniającymi poszczególne środowiska są: Możliwości analizy i prezentacji danych w programie Matlab. Możliwe jest również stworzenie wirtualnego modelu robota oraz testowanie z użyciem współpracującego programu Simulink [7]. ROBOTC oraz ev3dev wspierają podłączanie do robota nieoficjalnych podzespołów. W ev3dev możliwe jest pisanie własnych sterowników, co otwiera drogę do podłączania autorskich podzespołów. Atutem wyróżniającym system ev3dev jest możliwość wyboru spośród wachlarza języków programowania. 5.2 Wnioski Wnioski mają formę charakterystyki projektów najbardziej odpowiednich dla konkretnych środowisk. W kolejnych podsekcjach znajdują się wnioski dla środowisk ROBOTC (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 analizowanych programów. Cechy takie jak: automatyczna konfiguracja, zebranie wszystkich potrzebnych narzędzi w jednym programie, zintegrowany kompilator, debugger i moduł komunikacji, dołączona przeglądarka funkcji bibliotecznych i dokumentacja, świadczą o tym, że środowisko to świetnie nadaje się do zarówno małych jak i bardzo dużych projektów. Wadami środowiska są zamknięte źródła kodu, oraz brak wyboru języków programowania. Najbardziej polecany dla młodzieży, w szczególności na 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ępnych języków programowania, oraz nieograniczone możliwości rozwijania programu. 42 ROZDZIAŁ 5. PODSUMOWANIE Otwarty kod źródłowy pozwala na dołączanie własnych rozszerzeń systemu, używanie dowolnych nieoficjalnych podzespołów, oraz dostosowywanie projektu dokładnie do potrzeb użytkownika. Bardzo dużą zaletą jest możliwość pisania programów z praktycznie każdej platformy, łącznie z mobilnymi systemami operacyjnymi. Największa wada systemu - brak zintegrowanego edytora, jest jednocześnie wielką zaletą. Wadą braku edytora jest potrzeba samodzielnej i skomplikowanej konfiguracji systemu, co w przypadku wielu użytkowników platformy Lego Ev3, zwłaszcza tych najmłodszym może okazać się barierą nie do pokonania. Natomiast dla wymagających programistów spodziewających się braku nałożonych ograniczeń jest to olbrzymia zaleta. Dlatego właśnie to doświadczonym programistom system ten jest najbardziej polecany, 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ów jest najbardziej ograniczonym. Największymi atutami programu jest przedstawianie danych i wyników w postaci wykresów, tworzenie modeli matematycznych, używanie skomplikowanych działań matematycznych, oraz symulowanie robota w programie Simulink. Program Matlab polecany jest do projektów, których część robotyczna ograniczona jest do minimum, natomiast główny nacisk położony jest na zbieranie danych i analizowanie zachowania robota. W prostszych słowach najlepszymi projektami są roboty o bardzo prostej funkcji, z użyciem niewielu elementów aktywnych, gdzie badana jest problematyka precyzji robota, optymalności algorytmów, czy zgodności zachowania robota z jego modelem wirtualnym. Doskonałe środowisko dla studentów robotyki i automatyki w projektach poświęconych analizie robota opartego na modelach matematycznych i fizycznych. 5.2.4 Wniosek ogólny W ramach pracy został zbudowany robot o solidnej konstrukcji, którego zadaniem jest układanie Kostki Rubika. Na robota tego napisane zostały dwa programy napisane w dwóch różnych środowiskach programistycznych. Została również podjęta próba napisania programu w środowisku Matlab, jednak ograniczone możliwości rozszerzenia programu dla technologii Lego Mindstorms zadecydowały o wykluczeniu środowiska Matlab z fazy implementacyjnej. Oba programy napisane w środowiskach 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ą jedynie z wpływu oświetlenia zewnętrznego, które powoduje pomyłkę przy skanowaniu kolorów czerwonego i żółtego. Przy żadnej innej fazie pracy robota poza fazą skanowania nie występowały problemy. Stworzenie robota było jednak tylko częścią poniższej pracy. Ważnym zagadnieniem była ocena testowanych środowisk. Analiza ta przebiegła pomyślnie, zostały sformułowane cechy pozytywne i negatywne każdego ze środowisk. Zostały one zestawione ze sobą w tabeli porównawczej, a na koniec został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 zgodnie z planem, a wyniki są satysfakcjonujące. 44 ROZDZIAŁ 5. PODSUMOWANIE 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 Expansion Set. produktu LEGO Mindstorms EV3 Education 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 46 BIBLIOGRAFIA [12] Zintegrowane środowisko programistyczne - wikipedia definicja. https://pl. wikipedia.org/wiki/Zintegrowane_środowisko_programistyczne.
