Wiedza i doświadczenie projektowe wizytówką absolwenta kierunku automatyka i robotyka na Wydziale Automatyki, Elektroniki i Informatyki Politechniki Śląskiej POKL.04.01.02-00-020/10 Program Operacyjny Kapitał Ludzki współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Społecznego Gliwice, 21.02.2013 SKN Robotyki Encoder Wydział Automatyki, Elektroniki i Informatyki Politechnika Śląska dr hab. inż. Marek Pawełczyk, prof. nzw. w Politechnice Śląskiej Koordynator Projektu POKL.04.01.02-00-020/10 Sprawozdanie z działalności sekcji pracującej nad projektem Autonomicznej platformy mobilnej z manipulatorem. Projekt przeprowadzany jest w ramach działalności Studenckiego Koła Naukowego Robotyki Encoder, opiekunem naukowym projektu jest mgr inż. Tomasz Grzejszczak. Członkowie projektu: Mateusz Dziewior Piotr Mierzwa Dawid Wylenżek Michał Żuk Liderem projektu jest Dawid Wylenżek. Podpis opiekuna Strona 1 z 24
I. Spis treści I. Spis treści... 2 II. Cele projektu.... 3 III. Przełożenie podstawy jezdnej.... 4 IV. Matematyczny opis promienia krzywizny toru podczas jazdy po łuku w zależności od prędkości obrotowych kół.... 5 V. Instalacja manipulatora oraz bezprzewodowa komunikacja.... 10 VI. Obsługa enkoderów... 11 VII. System sterowania platformą i manipulatorem.... 14 VIII. Wykorzystane czujniki.... 16 IX. System czasu rzeczywistego.... 17 X. Aktualny stan projektu.... 17 XI. Wygląd gotowego projektu.... 18 XII. Publikacja poczynionych postępów.... 20 XIII. Podsumowanie wykorzystana budżetu.... 21 XIV. Zdjęcia zakupionego sprzętu.... 23 Strona 2 z 24
II. Cele projektu. Rozbudowanie istniejącej platformy mobilnej oraz wyposażenie jej w manipulator. Głównym zadaniem była zmiana podstawy jezdnej na większą i mocniejszą oraz zamontowanie na niej manipulatora. 1. Kamienie milowe projektu: Zakup elementów potrzebnych do realizacji projektu; Zmiana podstawy jezdnej; Instalacja i uruchomienie manipulatora; Stworzenie systemu sterowania platformą; Stworzenie systemu sterowania manipulatorem; Stworzenie stanowiska operatora; Scalenie i kalibracja wszystkich systemów; Implementacja komunikacji bezprzewodowej; 2. Harmonogram realizacji zadao Zakup elementów potrzebnych do realizacji projektu 15.12.2012; Zmiana podstawy jezdnej 15.01.2013; Implementacja komunikacji bezprzewodowej 20.01.2013; Instalacja i uruchomienie manipulatora 01.02.2013; Stworzenie systemu sterowania platformą 15.02.2013; Stworzenie systemu sterowania manipulatorem 01.03.2013; Stworzenie stanowiska operatora 05.03.2013; Scalenie i kalibracja wszystkich systemów 10.03.2013; Strona 3 z 24
III. Przełożenie podstawy jezdnej. Kamieniem milowym była zmiana podstawy jezdnej na większą i mocniejszą. Wybrana przez nas platforma posiadała wbudowaną elektronikę, która opierała się o mikrokontroler Atmega128. Na zdjęciu nr 1 pokazany jest wbudowany sterownik podstawy jezdnej. Zdjęcie 1. Oryginalny sterownik nowej podstawy jezdnej. Pierwszym zadaniem przy zmianie platformy było odpowiednie zaprogramowanie mikrokontrolera Atmega128, aby była możliwośd skorzystania ze znajdujących się w pojeździe sterowników silników. Po analizie dokumentacji sterownika pojazdu oraz zaznajomieniu się z biblioteką funkcji przygotowanych przez producenta, mikrokontroler został zaprogramowany tak, by istniała możliwośd podłączenia do niego głównego sterownika, tj. sbrio-9632, który dotychczas sterował platformą. Posiadaliśmy podstawową wiedzę w zakresie programowania mikrokontrolerów z rodziny Atmega, dzięki czemu odpowiednie oprogramowanie sterownika nie zajęło nam dużo czasu. Kolejnym krokiem było zintegrowanie oryginalnego sterownika platformy ze sterownikiem sbrio-9632, musieliśmy zadbad o odpowiednie wartości napięd oraz zabezpieczyd oba sterowniki przed błędnym podłączeniem przewodów. Zastosowaliśmy logikę odwrotną (zero jest prawdziwe), co powoduje, że przy błędnym podłączeniu przewodów pojazd nie ruszy. Dodatkowo, w przypadku uszkodzenia przewodów sterujących pojazd zatrzyma się. Strona 4 z 24
Zdjęcie 2. Zakupiona podstawa jezdna. W czasie gdy oczekiwaliśmy na dostarczenie platformy, sporządziliśmy analityczne wyprowadzenia wzorów, które opisują zmianę promienia krzywizny toru ruchu w zależności od prędkości obrotowej poszczególnych kół. Dzięki temu byliśmy w stanie bardzo szybko napisad odpowiednie oprogramowanie, które pozwala w dogodny sposób sterowad platformą. IV. Matematyczny opis promienia krzywizny toru podczas jazdy po łuku w zależności od prędkości obrotowych kół. Wartością skrętu steruje zmienna x i określa ona stosunek prędkości obrotowych prawych kół do lewych. x = P L, gdzie P prędkośd obrotowa prawych kół, L lewych W przypadku gdy L P oczywistym jest, że pojazd będzie poruszad się po pewnym łuku. Rozpatrzmy dwie możliwości skręt w lewo lub prawo. A. Skręt w lewo. Rysunek 1. Schemat skrętu platformy w lewo. Strona 5 z 24
Poruszając się wokół środka obrotu O po pewnym elementarnym łuku o promieniu krzywizny R prawe koła przebędą drogę: Natomiast lewe: Stosunek tych elementarnych dróg odpowiada założonemu stosunkowi prędkości obrotowych kół: Strona 6 z 24
B. Skręt w prawo. Wykres 1. Zależnośd promienia skrętu od przełożenia x dla skrętu w lewo. Rysunek 2. Schemat skrętu platformy w prawo. Sytuacja wygląda analogicznie. Prawe koła przebędą drogę: Natomiast lewe: Strona 7 z 24
Stosunek tych elementarnych dróg odpowiada założonemu stosunkowi prędkości obrotowych kół: Wykres 2. Zależnośd promienia skrętu od przełożenia x dla skrętu w prawo. Strona 8 z 24
C. Obrót w miejscu W przypadku gdy prawe koła kręcą się przeciwnie niż lewe otrzymujemy: Wówczas robot obraca się wokół własnego środa masy który pokrywa się z jego środkiem geometrycznym. Zdefiniowany do tego punktu promieo krzywizny z matematycznego punktu widzenia można uznad za zerowy. Zgadza się to z powyższym rozważaniami. D. Podsumowanie. Wzór na wartośd R ma następującą postad : Łatwo zauważyd, że wzór sprowadza się do ogólniejszej postaci: -W pobliżu asymptoty pionowej x=1 promieo R, co w praktyce odpowiada jeździe po linii prostej. Pracujemy na, co najwyżej, kilkumetrowych promieniach skrętu. -W pobliżu asymptoty poziomej R a 2. Z kolei przy tak małym promieniu skrętu występuje różny poślizg unieruchomionych kół. Z przeprowadzonych doświadczeo wynika, że promieo skrętu zależy od siły tarcia kół o mniejszej prędkości obrotowej, a zatem zależy od podłoża na którym porusza się robot. Powoduje to rozbieżnośd z wyznaczonymi wzorami teoretycznymi. Jednak nasz robot oferuje nam optymalne rozwiązanie tego problemu. W takich sytuacjach obracamy platformę w miejscu wokół jej środka ciężkości. Strona 9 z 24
Wykres 3. Zależnośd promienia skrętu od przełożenia x w przypadku ogólnym. V. Instalacja manipulatora oraz bezprzewodowa komunikacja. Kolejnym kamieniem milowym było zapewnienie bezprzewodowej komunikacji z platformą. Uprzednia wersja pojazdu posiadała już taki mechanizm zrealizowany przy wykorzystaniu routera WiFi. Mechanizm ten działał całkiem dobrze, a router nie zajmował dużo miejsca tak więc postanowiliśmy pozostad przy tym rozwiązaniu. Najtrudniejszą zadaniem, z którym przyszło nam się zmierzyd, była instalacja na pojeździe manipulatora oraz podłączenie go do sterownika sbrio-9632. Aby zrealizowad ten cel, utworzyliśmy specjalną ramę, która rozciąga się wzdłuż pojazdu. Na szczycie ramy został umieszczony manipulator AX-12A Smart Robotic Arm. Manipulator ten wyposażony jest w cyfrowe serwomechanizmy, z którymi trzeba komunikowad się przez port szeregowy. Sterownik sbrio-9632 posiada port RS232, który chcieliśmy wykorzystad do sterowania manipulatorem. Początkowo napisaliśmy oprogramowanie w środowisku LabVIEW i podłączyliśmy manipulator do komputera. Po przetestowaniu działania programu przystąpiliśmy do przeniesienia go do systemu czasu rzeczywistego sterującego platformą. Napotkaliśmy duże problemy związane z obsługą znajdującego się w sterowniku portu szeregowego. Początkowo system czasu rzeczywistego nie był w stanie połączyd się z portem, czego przyczyną był brak odpowiednich sterowników. Następnie musieliśmy zapewnid kompatybilnośd napięcia w porcie szeregowym i napięcia, które jest odpowiednie dla serwomechanizmów. W tym celu zbudowaliśmy mały układ oparty na układzie scalonym MAX232, który pozwolił na dostosowanie napięcia z portu szeregowego do potrzebnego dla serwomechanizmów. Po rozwiązaniu wszystkich problemów manipulator został na stałe przymocowany do pojazdu i podłączony do wewnętrznego źródła zasilania. Strona 10 z 24
Zdjęcie 3. Zastosowany manipulator AX-12A Smart Robotic Arm. Kształt manipulatora został zmodyfikowany tak, aby spełniał swoje cele będąc przymocowanym do platformy. VI. Obsługa enkoderów Postanowiliśmy, że platforma powinna mied możliwośd pomiaru przebytej drogi. Aby zrealizowad ten cel, potrzebowaliśmy informacji o obrotach kół. Elementem, który pozwala na otrzymanie takich informacji, jest enkoder. Po rozeznaniu w rodzajach enkoderów, ustaliliśmy, że najlepszy dla nas będzie enkoder inkrementalny. Enkoder obrotowy inkrementalny generuje impulsy odpowiadające ruchowi obrotowemu. Na pełny obrót (360 ) przypada stała, określona liczba impulsów. Na wyjściu otrzymujemy dwa sygnały prostokątne przesunięte względem siebie w fazie o 90. W zależności od kierunku obrotu, sygnał A wyprzedza sygnał B (lub odwrotnie), dzięki temu możliwe jest przekazanie informacji, w którą stronę obraca się silnik. Na podstawie liczby impulsów w danym przedziale czasu możemy obliczyd prędkośd obrotową. Strona 11 z 24
Wykres 4. Przebieg czasowy sygnałów wyjściowych enkodera. Ważnymi zaletami oferowanymi przez enkodery inkrementalne jest ich wysoka rozdzielczośd, duża wytrzymałośd oraz prostota instalacji. Spełniają więc założone przez nas wymagania i nadają się idealnie do pracy w zamkniętym układzie regulacji prędkości silnika. Schemat 1. Blokowy układu regulacji prędkości. Strona 12 z 24
Dzięki zastosowanemu sprzężeniu zwrotnemu możliwe jest utrzymanie stałej prędkości niezależnie od warunków zewnętrznych (np. obciążenia pojazdu, kąta nachylenia podłoża). Zastosowanie enkodera inkrementalnego umożliwia pomiar prędkości silnika, przyspieszenia oraz względnej pozycji pojazdu. Dzięki uzyskanym w ten sposób informacjom możemy określid, jaką drogę przebył pojazd, jego przybliżone położenie oraz orientację w terenie. Obsługa enkodera W środowisku LabVIEW istnieje biblioteka do obsługi enkodera na poziomie FPGA (wykorzystanie enkodowanie typu X4). Istnieją trzy podstawowe typy enkodowania: X1 w sytuacji, gdy sygnał A wyprzedza sygnał B licznik jest inkrementowany przez narastające zbocze sygnału A, w przeciwnym razie licznik jest dekrementowany przez opadające zbocze sygnału A. X2 różnicą w stosunku do X1 jest to, że licznik jest inkrementowany (lub dekrementowany) na każdym zboczu sygnału A. Każdy cykl to dwie inkrementacje (lub dekrementacje) licznika. X4 licznik jest inkrementowany (lub dekrementowany) na każdym zboczu sygnału A oraz B. Na każdy cykl przypadają cztery inkrementacje (lub dekrementacje) licznika. Schemat 2. Program zliczający impulsy enkodera. Strona 13 z 24
VII. System sterowania platformą i manipulatorem. Utworzony przez nas pojazd byłby bezużyteczny gdyby nie posiadał odpowiedniego interfejsu użytkownika. Środowisko LabVIEW umożliwia budowanie zawansowanych panelów sterowania, które posłużyły nam za interfejs użytkownika. Napisane przez nas oprogramowanie miało kilka interfejsów o różnym przeznaczeniu. Podstawowym z nich jest interfejs do testowania regulatorów zaimplementowanych na układzie FPGA. Pozwala on na test regulacji prędkości obrotowej silników oraz zmianę stosunku prędkości obrotowej lewych i prawych silników, co umożliwia skręt o dowolnym promieniu. Na panelu widzimy także odległości zwracane z ultradźwiękowych czujników odległości. Tak więc możliwe jest testowanie poprawności ich działania. Zdjęcie 4. Interfejs poziomu FPGA. Sterowanie manipulatorem odbywa się z poziomu systemu czasu rzeczywistego, gdzie również widzimy informacje zwracane przez czujniki odległości, a także mamy możliwośd wyboru trybu sterowania. Dodatkowo widzimy położenie każdego członu manipulatora i możemy nim sterowad. Strona 14 z 24
Zdjęcie 5. Interfejs poziomu czasu rzeczywistego. Sterowanie pojazdem za pomocą myszki jest bardzo niewygodne, dlatego zaimplementowaliśmy możliwośd sterowania platformą i manipulatorem z klawiatury komputera. Wybraliśmy najczęściej używane klawisze tak aby użytkownik nie miał problemów z obsługą robota. Zdjęcie 6. Rozkład klawiszy sterujących. Strona 15 z 24
VIII. Wykorzystane czujniki. Autonomiczna praca platformy wymaga odpowiedniego oczujnikowania. Aby zapewnid pełne bezpieczeostwo platformy, wykorzystaliśmy redundantne połączenie czujników ultradźwiękowych i czujników wykorzystujących podczerwieo. Różne typy czujników zapewniają wykrycie przeszkód wykonanych z różnych materiałów. Przykładowo czujnik wykorzystujący podczerwieo nie wykryje przeźroczystej przeszkody (np. szyby), natomiast czujnik ultradźwiękowy pozwoli na jej detekcję. Nie zawsze użycie ultradźwięków daje żądany rezultat. Częśd materiałów rozprasza fale ultradźwiękowe, a dodatkowo gdy zbliżamy się do przeszkody pod dużym kątem, to fala odbija się od przeszkody i wraca do czujnika inną drogą bądź wcale, co powoduje znaczny błąd w pomiarze odległości. Zastosowane czujniki ultradźwiękowe HC-SR04 zapewniają dokładny pomiar gdy zbliżamy się do przeszkody na wprost lub pod małym kątem. Przeprowadzone przez nas doświadczenia pokazują, że problemy z pomiarem zaczynają się gdy przeszkoda jest nierównomierna lub nachylona pod dużym kątem. Zaimplementowaliśmy funkcję, która częściowo wychwytuje takie sytuacje, jej działanie polega na sprawdzaniu zmian wartośd kolejnych pomiarów. Ponieważ nasz pojazd nie porusza się zbyt szybko zwracana odległośd powinna zmieniad się powoli, gdy następuje nagły i duży skok zmierzonej odległości, sprawdzamy pomiar z czujnika wykorzystującego podczerwieo i podejmujemy odpowiednią akcję. Rysunek 4. Pomiar odległości od przeszkody nachylonej pod dużym kątem. Kolejnym problemem okazało się stosowanie większej ilości czujników ultradźwiękowych w tym samym momencie. Jednoczesny pomiar czujnikami skierowanymi w tę samą stronę powodował nakładanie się fal co powodowało błąd w wyznaczaniu odległości była ona mniejsza niż w rzeczywistości. Strona 16 z 24
IX. System czasu rzeczywistego. Dla każdego z uruchomionych i przetestowanych elementów napisaliśmy prosty program w systemie czasu rzeczywistego tak, aby mied pewnośd, że każda częśd działa poprawnie. Jednym z założeo projektu jest wielozadaniowośd, tak więc przygotowaliśmy podstawowy system czasu rzeczywistego, który steruje platformą. Ma on scentralizowaną architekturę, co umożliwia dodanie kolejnego wątku bez zmian w pozostałych wątkach. Architektura ta ma także wiele innych zalet, między innymi możliwośd dostępu do wszystkich danych w wszystkich wątkach, co znacząco ułatwia komunikację pomiędzy nimi. Schemat 3 przedstawia budowę architektury zastosowanej w projekcie. Schemat 3. Architektura scentralizowana. X. Aktualny stan projektu. Pojazd został przez nas wyposażony we wszystkie dotychczas zakładane peryferia. W najbliższym czasie planujemy dołożyd do projektu elementy związane z nawigacją, takie jak kompas, GPS czy żyroskop. Wszystkie cele tego etapu projektu zostały zrealizowane, platforma jest w pełni mobilna oraz istnieje intuicyjny system sterowania. W najbliższym czasie planujemy rozwinąd system czasu rzeczywistego o dodatkowe funkcje pozwalające użytkownikowi na wybór zadania jakie ma wykonad platforma, a także ulepszyd tryb jazdy autonomicznej. Wiele godzin rozważao, testów i kalibracji pojazdu pozwoliły nam dobrze poznad jego budowę i zachowanie, a co za tym idzie, wszystkie planowane prace powinny byd szybko zrealizowane. Strona 17 z 24
XI. Wygląd gotowego projektu. Zdjęcie 6. Gotowy projekt. Zdjęcie 7. Gotowy projekt. Strona 18 z 24
Zdjęcie 8. Gotowy projekt. Strona 19 z 24
XII. Publikacja poczynionych postępów. Sprawozdanie z realizacji projektu oraz filmy pokazowy dla naszego projektu znajdują się na stronie koła naukowego SKN ENCODER pod adresem http://encoder.polsl.pl/. Na stronie znajdują się informacje dotyczące całego koła natomiast dokumenty dotyczące tylko naszego projektu dostępne są pod adresem http://encoder.polsl.pl/?page_id=12. Strona 20 z 24
XIII. Podsumowanie wykorzystana budżetu. Planowany budżet: Lp. Nazwa elementu Cena elementu Koszt wysyłki Koszt całkowity 1 Podstawa jezdna 900zł 15zł 915zł 2 Akumulatory LiPol 420zł 15zł 435zł 3 Ładowarka akumulatorów LiPol 560zł 0 560zł 4 Router WiFi 350zł 15zł 365zł 5 Zestaw enkoderów 400zł 0 400zł suma 2675zł Zrealizowany budżet Lp. Nazwa elementu Cena elementu 1 Podstawa jezdna 888,06zł 2 Akumulatory LiPol 410,63zł 3 Ładowarka akumulatorów LiPol 459,3zł 4 Aparatura RC 574,86zł suma 2332,85zł Strona 21 z 24
W trakcie prac nad projektem udało się zrealizowad bezprzewodową komunikacją oraz zliczanie przebytej drogi przy wykorzystaniu posiadanego sprzętu. Zaoszczędzone środki przeznaczyliśmy na 6-cio kanałową aparaturę RC którą wykorzystamy do zdalnego sterowania platformą( zamiast komputera PC). Sytuacja ta spowodowało iż z przydzielonego budżetu pozostało nam do wykorzystania 342,15zł. Zwracamy się z uprzejmą prośbą o przeniesienie niewykorzystanych środków tj. 342,15 zł do puli przyznanej SKN Ecoder w ramach czwartego konkursu na finansowanie projektów w ramach działalności Studenckich Kół Naukowych. Jednocześnie wnioskujemy, aby równy dostęp do przeniesionych środków miały wszystkie zespoły realizujące projekty w ramach SKN Encoder. Strona 22 z 24
XIV. Zdjęcia zakupionego sprzętu. Podstawa jezdna : Zdjęcie 9. Zakupiona podstawa jezdna. Akumulator LiPol Zdjęcie 10. Zakupiony akumulator. Strona 23 z 24
Ładowarka : Aparatura RC: Zdjęcie 11. Zakupiona ładowarka. Zdjęcie 12. Zakupiona aparatura RC. Strona 24 z 24