Popularny post staszek Napisano Sierpień 3, 2009 Popularny post Udostępnij Napisano Sierpień 3, 2009 Koło Naukowe Sztucznej Inteligencji CJANT projekt "Khepera" Koło Naukowe Robotyków KoNaR projekt "CamOn/MapMaker" Sterownik amatorskiego robota mobilnego do serwera Player Streszczenie Artykuł stanowi sprawozdanie dla kół naukowych. Omówiono w nim działanie narzędzia Player/Stage. Opisano również próbę budowy robota, wykorzystującego to oprogramowanie, dzięki wykorzystaniu małego terminala sieciowego Evo T20, który umieszczono na robocie. 1. Wstęp 1.1. Założenia projektowe Celem projektu było napisanie sterownika komunikującego serwer Player z czujnikami i silnikami znajdującymi się na amatorskim robocie mobilnym. Sterownik miał udostępniać (provides) następujące interfejsy: ➡️ position2d, ➡️ ir, ➡️ camera. Sterownik ma pomóc w realizacji projektów kół naukowych CJANT oraz KoNaR. 1.2. Player/Stage/Gazebo Player/Stage/Gazebo [1] (PSG) to zaawansowane środowisko robotyczne (system wielorobotowy), pozwalające na symulację i komunikację z narzędziami robotycznymi. O samym Playerze można powiedzieć, że jest serwerem sieciowym, gdyż komunikacja pomiędzy jego aplikacjami klienckimi a interfejsami do sensorów znajdujących się na robocie odbywa się za pośrednictwem gniazdek TCP. Serwer pozwala na obsługę wielu robotów (istnieją gotowe sterowniki do robotów Pioneer, Khepera etc.), urządzeń wykorzystywanych w robotach (GPS, kamery, dalmierze laserowe etc.), programów (moduł rozpoznawania mowy, syntezy mowy, blobfinder etc.) oraz algorytmów sterowania (np. VFH). Główną zaletą ([3]) korzystania z Player'a, jest pisanie programów przenośnych na inne roboty, ponieważ serwer pozwala na całkowite oddzielenie obsługi sprzętowej od programowanych zadań robota, dzięki standardowym interfejsom (rysunek 1). Środowisko pozwala na szybkie testowanie algorytmów poprzez symulację robotów na płaszczyźnie (symulator Stage) lub w trójwymiarze (symulator Gazebo). Sam serwer nie wie czy driver, który obsługuje, realizuje zadania prawdziwego robota czy symulatora. Aplikacje klienckie można pisać w wielu językach, dzięki dostarczonym z Player'em bibliotekom. Środowisko jest dostępne dla systemów: Linux (PC i embedded), Solaris, Mac OSX, *BSD. PSG jest wolnym oprogramowaniem, z otwartym kodem źródłowym. Rysunek 1. Schemat zadania realizowanego przez serwer Player (źródło: [2]). 1.3. Player Driver Player Driver to biblioteka, realizująca komunikację pomiędzy fizycznym robotem (lub innym urządzeniem) a serwerem. Pozwala on na udostępnienie sygnałów i parametrów (odczyty z dalmierzy, odczyt pozycji i prędkości etc.) w postaci standardowych struktur danych zwanych proxies. Konfigurację robota (bądź symulatora) określa plik *.cfg, wskazywany podczas uruchamiania serwera. W pliku są wypisane wykorzystywane driver'y oraz zmienne konfigurujące driver (np. wybór portu szeregowego, pozycja początkowa robota etc.). Ponadto określone są udostępniane interfejsy (sekcja provides), wraz z ich numeracją, która pozwala na dostęp z poziomu programów klienckich. Niektóre driver'y, wymagają dostępu do wspominanych interfejsów, np. algorytm VFH wymaga dostępu do position2d oraz sonar. Plik konfiguracyjny określa więc również, z jakich interfejsów (numer z sekcji provides) mają korzystać inne driver'y (sekcja requires). Przykładowe pliki konfiguracyjne serwera znajdują się w załączniku. Driver skompilowany jest zazwyczaj do postaci biblioteki współdzielonej *.so i napisany w języku C++. Schemat blokowy zadań realizowanych przez driver przedstawia poniższy rysunek. Rysunek 2. Cykl Player Driver'a (źródło: [2]). W kodach źródłowych Player'a znaleźć wiele gotowych sterowników. Procedurę tworzenia driver'ów opisano np. w [2] oraz w [4]. Poza wspomnianymi kodami źródłowymi, znaleźć można w sieci inne przykłady sterowników, takie jak: ➡️ProtonekDriver - sterownik robota Politechniki Warszawskiej Protonek, ➡️MGDriver - sterownik robota przygotowywanego do zawodów Mini Grand Challange, przez Robotics Club z Pennsylvania State University, ➡️HDAPS - sterownik realizujący sterowanie robotem, poprzez manipulację laptopem IBM, wykorzystującym Linux'owy sterownik HDAPS (Hard Drive Actice Protection System) obsługujący żyroskop zabezpieczający dysk twardy w przypadku gwałtownych wstrząsów. Spektakularne możliwości ostatniego z driver'ów przedstawia poniższy film. 2. Realizacja projektu 2.1. Komputer pokładowy 2.1.1 Evo T20 Realizacja zadania wymagała wykorzystania systemu wbudowanego pozwalającego na uruchomienie serwera Player w systemie Linux. Proces projektowania systemów wbudowanych jest zajęciem trudnym i czasochłonnym, dobrym pomysłem było więc wykorzystanie gotowego urządzenia. Niestety specjalistyczne układy elektroniczne przeznaczone do tego celu są drogie i trudno dostępne w Polsce. W sieci znaleźć można jednak wiele artykułów, dotyczących instalacji Linux'a na urządzeniach takich jak router'y, terminale sieciowe etc. Przykładem takiego urządzenia jest thinclient HP Evo T20. 3a. PCB front (źródło: [6]) 3b. PCB back (źródło: [6]) 3c. z obudową (źródło: Wikimedia) Rysunek 3. HP Evo T20. 2.1.2. Przygotowanie obrazu Spośród wielu artykułów na temat instalacji Linux'a na Evo T20 na szczególną uwagę zasługują [6] i [7]. Procedura polega na zastąpieniu firmowego programu znajdującego się w pamięci układu, obrazem z bootloader'em (w tym przypadku GRUB) i jądrem Linux'a. Pozostałe elementy składowe systemu znajdują się na pendrivie lub dysku USB (istnieje możliwość instalacji całego systemu w pamięci FLASH, choć nie opracowano jeszcze metody bootowania jądra znajdującego się na pendrive'ie). Opis ze strony [6], jest ciekawy ze względu na dogłębne wyjaśnienia wszystkich etapów instalacji. Proponuje jednak instalację systemu Damn Small Linux (DSL), który z pewnych względów byłby niewygodny w omawianym projekcie. Chodzi tu przede wszystkim o utrudniony sposób zapisywania ustawień systemowych, znacznie wydłużający czas bootowania. Ponadto twórcy DSL postanowili nie załączać do dystrybucji jądra nowszego od 2.4.x (ze względu na rozmiar kolejnych wersji). Ponieważ projekt przewiduje wykorzystanie kamery USB zdecydowano, że bardziej korzystne będzie rozwiązanie z nowszą wersją jądra. Postanowiono wykorzystać sposób prezentowany w [7], zwłaszcza, że zwalniał on z konieczności ingerencji w firmowy obraz. Zastosowane rozwiązanie pozwoliło na zachowanie funkcjonalności systemu Ubuntu, oraz wykorzystanie odpowiednio spreparowanego jądra (wg metody z [7]). System Ubuntu Server Edition zainstalowano za pomocą nośnika instalacyjnego na pendrive. Posiada więc też własne jądro i dzięki temu istnieje możliwość uruchomienia systemu na innych komputerach. Rysunek 4. Zastosowane rozwiązanie. 2.1.3. Instalacja obrazu Aktualizacja obrazu firmware polega na udostępnieniu go w sieci w celu pobrania przez urządzenie. Podczas rozruchu Evo T20 istnieje możliwość uruchomienia programu, który automatycznie pobierze obraz i zainstaluje w pamięci FLASH. Producent poleca metodę udostępniania obrazu w sieci za pomocą narzędzia NetXfer Download Utility Program [5]. Jest to aplikacja przeznaczona do uruchomienia w systemie Windows. Wymaga starej wersji środowiska Java, niestety dokumentacja nie podaje, jaka jest to wersja. Postanowiono więc wykorzystać inną metodę udostępniania, wykorzystującą system Linux, zaczerpniętą z [6]. Polega ona na instalacji serwera DHCP i TFTP na komputerze w sieci lokalnej. Można pobrać (również z [6]) gotowe skrypty konfigurujące serwery w celu uzyskania zgodności z NetXfer. Rysunek 5. Procedura instalacji obrazu, opisana w [6]. 2.2. Elektronika sterująca 2.2.1. Modułowa płytka testowa Pobieranie danych z czujników oraz sterowanie silnikami realizuje dodatkowa elektronika. Player komunikuje się z nią za pośrednictwem wirtualnego portu szeregowego. Robot został wyposażony w modułową płytkę testową, w której skład wchodzą: ➡️ mikrokontroler ATmega32, ➡️ układ konwersji napięć (oparty o układ scalony MAX232), ➡️ scalony podwójny mostek H (układ l298), ➡️ diody sygnalizacyjne. Ponadto robota wyposażono w: ➡️ silniki modelarskie z przekładnią, ➡️ impulsatory, do pomiaru kątów obrotu kół, ➡️ dalmierz Sharp, realizujący interfejs ir, ➡️ kamerkę internetową (podłączona do EVO T20 przez USB). Schemat modułów płytki testowej znajduje się w załączniku. 2.2.2. Komunikacja W robocie postanowiono wykorzystać taki sam sposób komunikacji poprzez port szeregowy, jaki wykorzystano w robocie Khepera ([9]). Listę komend łatwo można odczytać z kodów źródłowych programu mikrokontrolera. 2.3. Odometria Udostępnianie interfejsu position2d odbywa się dzięki odometrycznemu pomiarowi położenia. Rysunek 6. Odometria (źródło: [10]). Niech S_i oznacza drogę przebytą przez koło i (i=l lub i=r). Związek pomiędzy S_i a liczbą impulsów zliczonych przez impulsator opisuje poniższe równanie. S_i = (2 * pi * R * N_i) / C_i Gdzie: ➡️R - promień koła, ➡️N_i - liczba zliczonych impulsów, ➡️C_i - rozdzielczość impulsatora (ilość impulsów na obrót). Jeśli O(T) oznacza kąt obrotu (w radianach) robota, to kąt obrotu w chwili T+1 można obliczyć z poniższej zależności. O(T+1) = O(T) + (S_r - S_l) / W W oznacza rozstaw kół robota. Podobnie można obliczyć przesunięcie robota D, od chwili T do T+1. D(T,T+1) = (S_r + S_l) / 2 Proste przekształcenia geometryczne prowadzą do zapisu położenia robota we współrzędnych kartezjańskich. x(T+1) = x(T) + D(T,T+1) cos(O(T+1) y(T+1) = y(T) + D(T,T+1) sin(O(T+1)) 2.4. Implementacja Driver'a Programując driver wykorzystano kod gotowego sterownika robota Khepera, autorstwa Toby'ego Collett'a, który dołączony jest do źródeł Player'a. Kod sterownika znajduje się w załączniku. Ponadto załączono również plik konfiguracyjny serwera, oraz kod programu mikrokontrolera. Kod oryginalnego driver'a robota Khepera można znaleźć np. na stronie projektu ([1]). 3. Podsumowanie 3.1. Osiągnięte cele Projekt pozwolił na napisanie programu sterownika, napisanie programu mikrokontrolera, instalację systemu Linux na robocie oraz budowę tymczasowej konstrukcji robota. 3.2. Nierozwiązane problemy projektu 3.2.1. Problem zliczania impulsów Ten problem zauważono dopiero w ostatniej fazie pracy nad projektem, gdy wykonywano testy. Problem Impulsy zliczane są przez piny przerwań zewnętrznych mikrokontrolera. Przerwanie od INT0 ma priorytet wyższy od przerwania od INT1, więc zawsze lewe koło zlicza więcej impulsów niż prawe (nawet gdy robot jedzie na wprost). Ponadto przerwania generowane przez obsługę UART, również blokują zliczanie impulsów. Powód Błędne założenia projektu, dotyczące impulsatora. Pomysły na rozwiązanie problemu ➡️ Zastosowanie innych czujników do udostępniania interfejsu position2d (np. optyczny czujnik przemieszczenia z myszki), ➡️ wykorzystanie osobnego mikrokontrolera do obsługi impulsatorów. 3.2.2. Problem z obrazem z kamery Testy wykonywano na komputerze PC. Problem Program kliencki playercam pokazuje czarny obraz. Kamerę obsługuje Player'owy driver camera4l. Serwer nie zwraca żadnych ostrzeżeń dotyczących pracy kamery. Działanie innych programów (np. cheese) potwierdza sprawność kamery. Powód Nieznany. Pomysł na rozwiązanie problemu ➡️ Instalacja nowszej wersji Player'a (wraz z programami klienckimi), ➡️ wykonanie prób konfiguracji sterownika camera4l, ➡️ napisanie własnego programu klienckiego do pobieraniu obrazu z kamery, z użyciem biblioteki OpenCV, ➡️ zastosowanie innej kamery. 4. Opis załączników 4.1. Program mikrokontrolera ➡️uc_adc.c - obsługa przetwornika ADC, ➡️uc_defs.h - definicje, konfiguracja robota, ➡️uc_motors.c - obsługa mostka H, ➡️uc_opt.c - obsługa optycznego czujnika przemieszczenia (próba wykorzystania innego czujnika do udostępniania interfejsu position2d), ➡️uc_other.c - inne funkcje, ➡️uc_uart.c - obsługa transmisji szeregowej, ➡️uc_imp.c - obsługa impulsatora, ➡️uc_main.c - program główny, obsługa przerwania od zakończenia odbioru. 4.2. Driver ➡️StachuRobot.cfg - plik konfiguracyjny serwera, ➡️StachuRobot.cc - kod drivera'a, ➡️StachuRobot_serial.cc - kod funkcji do obsługi portu szeregowego. 4.3. Narzędzia do symulacji W załączniku znajdują się również pliki do symulacji robota Khepera w Stage'u, autorstwa Khairulmizam'a Samsudin'a. 4.4. Pozostałe załączniki Do sprawozdania dołączono również schematy elektroniczne, oraz zdjęcia wykonanego robota (poniżej). Rysunek 7. Zdjęcia robota. Bibliografia [1] The Player Project, http://playerstage.sourceforge.net/. [2] RoboWiki, http://www.psurobotics.org/wiki/. [3] Richard T. Vaughan, Brian P. Gerkey, Really Reusable Robot Code and the Player/Stage Project, Springer Tracts on Advanced Robotics, 2006. [4] Bue Peterson, Jonas Fonseca, Writing Player/Stage Drivers, a howto for ERSP Player Driver Source Package, 2006. [5] PXE Operation Flow for Compaq Evo Thin Clients, Compaq Computer Corporation, 2002. [6] DEvoSL - DSL on Evo T20 HowTo, http://www.mowson.org/karl/evo_t20/. [7] Terminal EVO T20 jako serwer, http://www.plociennik.ostrowwlkp.pl/index.php?id=71. [8] open-evot20, http://open-evot20.sourceforge.net/. [9] Wiktor Matysek, Laboratorium Podstaw Robotyki I, Ćwiczenie: Khepera - dwukołowy robot mobilny (instrukcja), 2006. [10] Simulated Reality Systems, http://www.simreal.com/. symulacja.rar prog_uc.rar schematy.rar driver.rar 3 Link do komentarza Share on other sites More sharing options...
Pomocna odpowiedź
Bądź aktywny - zaloguj się lub utwórz konto!
Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony
Utwórz konto w ~20 sekund!
Zarejestruj nowe konto, to proste!
Zarejestruj się »Zaloguj się
Posiadasz własne konto? Użyj go!
Zaloguj się »