POLITECHNIKA WROCŁAWSKA WYDZIAŁ ELEKTRONIKI PRACA DYPLOMOWA MAGISTERSKA

Transkrypt

1 POLITECHNIKA WROCŁAWSKA WYDZIAŁ ELEKTRONIKI KIERUNEK: SPECJALNOŚĆ: Automatyka i Robotyka (AiR) Robotyka (ARR) PRACA DYPLOMOWA MAGISTERSKA Stanowisko laboratoryjne wielosensorycznej miniplatformy mobilnej Laboratory stand of a small multi-sensor mobile platform AUTOR: Robert Konieczny PROWADZACY PRACE: dr inż. Bogdan Kreczmer, I-6 OPIEKUN: dr inż. Bogdan Kreczmer, I-6 OCENA PRACY: WROCŁAW 2009

2

3 Pracę dedykuję rodzicom.

4

5 Składam serdeczne podziekowania Panu dr inż. Bogdanowi Kreczmerowi za rady, wyrozumiałość i cierpliwość.

6

7 Spis treści 1 Wstęp 1 2 Założenia i cel pracy 3 3 Przeglad rozwiazań Jednostka centralna Wstęp Minimoduł z mikrokontrolerem z rodziny M68K Minimoduł z mikrokontrolerem z rdzeniem ARM7-TDMI Platforma embedded z mikrokontrolerem Samsung S3C Platforma PC Gunstix Verdex Pro Gumstix Overo Earth BeagleBoard Podsumowanie System stereowizyjny Wstęp Aparat MCA Kamery internetowe Podsumowanie Komunikacja bezprzewodowa Czytnik RFID Rozbudowa mechaniki minirobota Wstęp Modyfikacje konstrukcji wewnętrznej Konstrukcja głowicy stereowizyjnej Instalacja czytnika RFID Wyprowadzenie przewodów połączeniowych Rozbudowa sterowników minirobota Płytka translacji napięć Sterownik PWM/LCD Sterownik enkodera Koncentrator USB

8 vi SPIS TREŚCI 6 Stanowisko pracy nad oprogramowaniem Wstęp Niezbędne narzędzia Pobieranie i kompilowanie źródeł projektu Instalowanie systemu Budowa paczki Modyfikowanie paczek Instalowanie paczek Tworzenie oprogramowania na platformie docelowej Oprogramowanie minirobota Oprogramowanie jednostki centralnej Oprogramowanie sterowników platformy Demonstracja działania Sterownik dalmierzy Sterownik sensorów Sterownik enkodera Sterowniki taktylny i PWM/LCD Czytnik RFID System stereowizyjny Badania Układ pomiarowy Oprogramowanie Kalibracja kamery Pomiary i ich analiza Wnioski Podsumowanie 59 A Dodatkowe opisy, schematy 61 A.1 Zawarto nośnika CD A.2 Rysunki techniczne

9 Rozdział 1 Wstęp Postęp w technologiach robotycznych posuwa się bardzo szybko. W dziedzinie mechaniki i sterowania pojawiają się coraz to nowsze pomysły na usprawnienia czyniące roboty bardziej zaradnymi w naszym świecie. W tym celu między innymi powstał LARS. Ma On pomóc w rozwiązywaniu zagadnień, które w wirtualnym świecie liczb cierpią zazwyczaj tylko z powodu dokładności obliczeń, podczas gdy losowość i nieprzewidywalność świata rzeczywistego potrafią zniszczyć całkowicie ich koncepcje. Ninejsza praca dokumentuje rozbudowę platformy LARS pod względem mechanicznym, elektronicznym i programowym. Pierwszy z napotkanych rozdziałów dostarcza informacji o doborze jednych z głównych elementów platformy - mózgu, oczu i aparatu komunikacji robota. Kolejne rozdziały opisują modyfikacje w mechanice i sterownikach zrealizowane dla integracji obecnego już wyposażenie LARSa z nowymi elementami. Po nich przychodzi czas na zagadnienia związane z oprogramowanieml, czyli opis przygotowania środowiska pracy nad kodem oraz objaśnienie idei oprogramowania stworzonego dla platformy. Ostatni rozdział zawiera opis badań dodanych urządzeń pomiarowych. W dodatkach, znajdującym się na końcu, znaleźć można rysunki techniczne elementów mechaniki, kod źródłowy oprogramowani i inne pliki potrzebne do pracy z robotem.

10

11 Rozdział 2 Założenia i cel pracy Oczekiwanym efektem końcowym pracy jest stanowisko minirobota mobilnego. Wspomniany robot powinien dysponować możliwie bogatym zestawem sensorów. Powinny one umożliwiać mu autonomiczną nawigację, jak też łączność radiową ze stanowiskiem operatora. Architektura systemu sensorycznego i systemu sterowania powinna być możliwie otwarta. W tym celu należy rozważyć możliwość zaadoptowania jednego z istniejących interfejsów i protokołów dających możliwość podłączenia dodatkowych sensorów. Zakłada się, że wspomniane stanowisko będzie tworzone w oparciu o istniejącą konstrukcję miniplatformy LARS. Istniejący zestaw sensorów powinien być uzupełniony o czytnik znaczników RFID oraz system stereowizyjny. Dodane sensory powinny zostać przebadane pod kątem wiarygodności otrzymywanych danych pomiarowych. Wskazane jest zaproponowanie odpowiednich procedur filtrujących i zwiększających wiarygodność otrzymywanych informacji. W oparciu o skonstruowaną platformę, zakłada się, że zostanie utworzone stanowisko laboratoryjne. Powinno ono umożliwiać tworzenie oprogramowania, kroskompilację i przesyłanie go do platformy. Komunikacja z platformą ma być realizowana drogą radiową z wykorzystaniem możliwie uniwersalnego standardu transmisji. Kanał transmisyjny powinien być na tyle wydajny, by umożliwić kooperację platformy z oprogramowaniem stanowiska operatorskiego. Oprogramowanie jednostki centralnej powinno dostarczać polecenia lub funkcje sterujące ruchem platformy. Możliwe powinno być również pobranie informacji o aktualnym stanie platformy. W opracowanym zestawie komend powinny znaleźć się również takie, które umożliwią odczytanie pomiarów z sensorów platformy. Sterowanie platformą powinno być możliwe do realizacji z poziomu aplikacji wykonywanej na jednostce centralnej. Jako test stworzonego stanowiska powinny powstać przykładowe program obrazujące sposób wykorzystania funkcji sterujących platformą i odczytujących dane pomiarowe.

12

13 Rozdział 3 Przeglad rozwiazań 3.1 Jednostka centralna Wstęp Do potrzeb niniejszego projektu dopasować można kilka rozwiązań bazujących na różnych procesorach. Podstawowe wymogi to zapewnienie komunikacji z zainstalowanymi już sensorami robota, oraz możliwość kontrolowania napędów. Niezbędny zatem jest port SPI (najlepiej mogący obsłużyć co najmniej 5 uradzeń podrzędnych) oraz 2 porty PWM. Robot zasilany jest z akumulatora żelowego o pojemności 3,5 Ah, zatem jednostka centralna powinna pobierać niewielkie ilości prądu. Z racji, że platforma wyposażona ma być w układ stereowizyjny, cechować ją musi duża moc obliczeniowa. Wymieniono podstawowe zagadnienia na jakie należy zwrócić uwagę. Spośród dostępnych produktów wybrano kilka i opisano poniżej Minimoduł z mikrokontrolerem z rodziny M68K Jednym z mikroprocesorów z rodziny M68K jest MC68332[35]. To 32-bitowy mikroprocesor pracujący z taktowaniem do 25 MHz, bogato wyposażony w układy peryferyjne. Szczególnie Rysunek 3.1: Minimoduł z mikrokontrolerem MC68332

14 6 Przeglad rozwiazań przydatne w projekcie mogłyby być moduły TPU oraz QSM. Moduł QSM (Queued Serial Module) składa się z QSPI oraz SCI. QSPI (Queued Serial Peripheral Interface) to rozbudowany układ SPI pozwalający na automatyzację komunikacji. Pobranie wartości z sensorów sprowadza się do odczytania rejestrów procesora, które są cyklicznie odświeżane bez absorbowania do tego jednostki centralnej. Port SPI posiada linie kontrolne dla 4 urządzeń podrzędnych. Ich niedobór (potrzebnych jest 5) można zlikwidować stosując układ multipleksera. Port SCI posłużyć może do realizacji komunikacji bezprzewodowej poprzez moduły bluetooth i podobne. Kolejny moduł to TPU (Time Processor Unit). To programowalny koprocesor przeznaczony do cyklicznej realizacji funkcji w oparciu o układy czasowo-licznikowe. Wykorzystany mógłby być do generowania sygnałów PWM dla silnika napędowego oraz serwomechanizmu kierującego. MC68332 wyposażony jest w 19-bitową zewnętrzną magistrale adresową oraz 16-bitową magistralę danych, zatem pamięć SRAM i FLASH/ROM można podłączyć jako układy zewnętrzne. Ze względu na układy peryferyjne mikroprocesor MC68332, z powodzeniem mógłby znaleźć zastosowanie w jednostce LARS. Jego architektura zachęca do stosowania systemów operacyjnych. Wymiary, złożoność kompletnego układu, dostępność elementów oraz koszty przemawiają za tym rozwiązaniem. Moc obliczeniowa może być jednak niewystarczająca dla realizacji przetwarzania obrazu stereowizyjnego w czasie rzeczywistym. Brakuje także możliwości podłączenia prostych kamer VGA oraz czytnika RFID (wliczając moduł Bluetooth potrzebne byłyby 4 interfejsy RS232) Minimoduł z mikrokontrolerem z rdzeniem ARM7-TDMI Na rynku dostępnych jest wiele mikrokontrolerów z tym rdzeniem. Produkty firmy NXP[13] są autorowi pracy znane najlepiej, zatem na nich skoncentrowany zostanie przegląd. Taktowanie Rysunek 3.2: Minimoduł z mikrokontrolerem LPC2148 rdzenia nie przekracza 72 MHz. Wśród nich (rodzina LPC2xxx) znaleźć można małe mikrokontrolery wyposażone w kilka kilobajtów RAM i FLASH, ale także takie, które posiadają kontroler pamięci zewnętrznej. Kontroler taki obsługiwać może zazwyczaj pamięć SRAM, SDRAM i FLASH poprzez 23-bitową magistrale adresową i 32-bajtową magistralę danych. Wszystkie procesory wyposażone są w co najmniej jeden port SPI i SSP (Serial Synchronous

15 3.1 Jednostka centralna 7 Port, port mogący pracować między innymi jako SPI z dodatkowym buforowaniem). Posiadanie pojedynczych linii wyboru urządzenia podrzędnego można skompensować wspomagając się portami wejść/wyjść. Mikrokontrolery LPC2xxx posiadają co najmniej dwa buforowane port UART zgodne ze standardem 16c550, z czego jeden wyposażony w komplet linii modemowych z uzgadnianiem. Na pokładzie znajdują się oczywiście kanały PWM, oraz kilka przydanych portów takich jak np. CAN (Controller Area Network), stanowiących dobrą podstawę dla dalszej rozbudowy platformy. Wyższe modele posiadają port USB Host/OTG co umożliwiłoby podłączenie kamer internetowych. Nasuwa się jednak pytanie, czy dostępne jest gotowe oprogramowanie do ich wykorzystania. LPC2xxx, jak i inne procesory z rdzeniem ARM7-TDMI, są bardzo dobrą platformą dla systemów operacyjnych czasu rzeczywistego. Posiada system zwektoryzowanych przerwań i rozbudowaną kontrolę uprawnień. Środowiska programistyczne i wdrożeniowe dla nich są równie dobrze rozwinięte jak w przypadku procesora Motorola. Moc obliczeniowa jest niemal 3-krotnie wyższa niż w MC68332, nadal jednak wydaje się być niewystarczająca do przetwarzania dwóch strumieni video w czasie rzeczywistym Platforma embedded z mikrokontrolerem Samsung S3C2440 S3C2440[17] - mikrokontroler oparty na rdzeniu ARM920T, to 16/32-bitowa jednostka taktowana zegarem 400 MHz (maksymalnie 533 MHz). Wyposażona jest w MMU 1 pozwalającą Rysunek 3.3: Platforma z procesorem S3C2440 uruchomić pełnoprawny system operacyjny typu Linux czy Windows CE. Zasoby mikroprocesora to dwa porty SPI, 9 portów UART, 4 kanały PWM, kontroler zewnętrznej pamięci SDRAM oraz FLASH i wiele innych. Należy pamiętać, że S3C2440 to zaawansowany układ w obudowie typu BGA. Wykonanie własnej płyty rozwojowej jest niemożliwe. Użytkownik skazany 1 Memory Management Unit - jednostka zarządzania pamięcią, zapewnia dostęp do pamięci żądanej przez procesor, realizuje funkcje jej ochrony, wirtualizacji itp..

16 8 Przeglad rozwiazań jest na konfigurację sprzętową płyt rozwojowych dostępnych na rynku. Płyty takie najczęściej wyposażone są w 64 MB pamięci SDRAM i FLASH, 3 porty szeregowe, 1 kanał PWM, złącze kamery, port USB Host 1.1, port LAN oraz około 30 portów wejść wyjść binarnych. Problemem jest brak portów SPI. Rozwiązaniem może być mostek udostępniający szynę SPI poprzez wyprowadzoną szynę I2C. Od wcześniej opisanych rozwiązań S3C2440 odróżnia się znacznie większa wydajnością oraz wykorzystaniem systemu Linux. Przeciwko tym zaletom staje fakt, iż płyta ewaluacyjna ogranicza funkcjonalność mikrokontrolera. Na rynku dostępne są minimoduły do zastosowań na własnych płytach. Ich nabycie jest jednak utrudnione ( zamówienia realizowane dla większej ilości sztuk). Poza tym cena płyt uruchomieniowych nie jest korzystna Platforma PC104 PC104 oraz PC104+[16] to standardy będące odpowiedzią na zapotrzebowanie rynku na jednopłytowe modułowe komputery przemysłowe. Wyposażane są one w różne procesory, począw- Rysunek 3.4: Platforma w standardzie PC104 szy od AMD Geode, poprzez procesory VIA Eden po produkty Intel Celeron M czy Pentium M. To co łączy te procesory to architektura (x86), zatem dostępność i przenośność oprogramowania jest ogromna. To co je różni to wydajność. Płyty PC104 z energooszczędnymi procesorami VIA potrzebują nie mniej niż 10W do prawidłowej pracy. Ich wymiary są w pełni akceptowalne w automatyce, lecz na platformie LARS nie uda się wygospodarować wystarczającej ilości przestrzeni. W opisie celowo pominięto układy peryferyjne ponieważ można je wybrać spośród ogromnej gamy modułów rozszerzeniowych. Niestety trzeba przyznać, że atuty w postaci wystarczającej mocy obliczeniowej i dużej różnorodności rozwiązań, przegrywają ze zbyt dużym poborem energii, rozmiarami i nieatrakcyjną ceną.

17 3.1 Jednostka centralna Gunstix Verdex Pro Gumstix Verdex Pro[9] to kompletny komputer jednopłytowy wyposażony w procesor PXA270 z rodzina XScale (rdzeń ARM11). Opis skoncentrowano na modelu Verdex Pro XM4-bt, ponieważ posiada on zintegrowany moduł komunikacji Bluetooth. Taktowanie procesora w tym a) b) Rysunek 3.5: a) Platforma Gumstix Verdex Pro XM4-bt, b) Moduł Robostix modelu to 400 MHz, pamięć to 64 MB RAM i 16 MB FLASH. Gdyby nie posiadanie złącz ewaluacyjnych, na tym kończyłyby się użyteczne zasoby jednostki. Poprzez 3 różne złącza Gumstix może być doposażony w wyprowadzenia portu USB Host 1.1, 3 porty szeregowe, jeden lub dwa porty LAN 10/100 MBps, moduł Wi-Fi, port I2C, kilkanaście portów GPIO i kilka innych. Dostępny jest także moduł Robostix. Posiada on mikrokontroler ATmega128, z którym Gumstix komunikuje się poprzez I2C. Robostix może dostarczyć dla Gumstix pełnej funkcjonalności jaką sam posiada - porty szeregowe, PWM, GPIO. Zestaw złożony z Gumstix Verdex Pro MX4-bt i Robostix posiada odpowiednie porty do połączenia prostych kamer VGA, czytnika RFID i sterowania napędów. Niestety by uzyskać port SPI należy sprzętowo zmodyfikować Robostix - brak jest wyprowadzeń sygnałów na złącza. Inne moduły w ogóle nie posiadają portu SPI. Zestaw Gumstix Verdex Pro XM4-bt i Robostix pobiera ok 2W mocy, jest mały, ma wydajny procesor XScale, rozwinięte środowisko programistyczne i dużą ilością gotowego już oprogramowania[10][14]. Niemniej jednak ma także wady. Platforma posiada niewielką i nierozszerzalna ilość pamięci operacyjnej. Może jej zabraknąć do przetwarzania obrazów o większej rozdzielczości. Robostix rozszerza funkcjonalność, ale jest dodatkową platformą do oprogramowania i przystosowania do pracy z Gumstix. Przez praktyków jest odradzany ze względu na częste problemy z nim. Pewna przeszkodę stanowi także brak dystrybutorów w Europie i nieco wysoka cena takiego rozwiązania Gumstix Overo Earth Idea serii Overo[9] jest taka sama jak Verdex Pro - bardzo mały, jednopłytowy, modułowy, energooszczędny komputer z pełnoprawnym systemem operacyjnym. Zasadniczą różnicę stanowi procesor główny. Overo wyposażone jest w procesor OMAP3503. Jest to układ typu SoC (System on Chip) posiadający rdzeń ARM Cortex-A8 z zegarem 600 MHz, 256 MB pamięci RAM i FLASH. Rdzeń ten jest znacznie wydajniejszy od ARM11. Overo również wymaga modułów rozszerzających by można było skorzystać z portów procesora. Z racji że Overo jest stosunkowo młodą konstrukcją, posiada na razie tylko jeden moduł rozszerzeniowy - Summit. Moduł ten udostępnia I2C, 6 linii PWM, 2 porty szeregowe, 1 port konsoli USB, SPI dla 2 urządzeń podrzędnych, USB Host, USB OTG i kilka portów GPIO. Wyprowadzone porty pozwolą zatem podłączyć sensory, napędy oraz czytnik RFID. Komunikację bezprzewodowa zapewnić może karta WiFi na USB. Są one domyślnie obsługiwane przez większość dystrybucji Linux. Jako kamery można wykorzystać kamery internetowe także podłączane do portu USB. OMAP3503

18 10 Przeglad rozwiazań a) b) Rysunek 3.6: a) Platforma Overo Earth, b) Moduł Summit powinien podołać przetwarzaniu strumienia obrazu w rozdzielczości VGA. Producent zapowiada kolejne wersje Overo z innymi modelami procesorów z rodziny OMAP (między innymi posiadającymi procesor DSP) Przyjąć można, że do nielicznych, ale znaczących wad należą cena i brak dostawców w Europie BeagleBoard BeagleBoard[4] to bliźniacze rozwiązanie względem Overo. Posiada procesor OMAP3[1] wyposażony w procesor DSP C64+. Taktowanie procesora głównego (GPP - General Purpose Rysunek 3.7: Platforma Beagleboard, rev.b7 Processor) to 533 MHz, jednostka DSP natomiast pracuje z zegarem 433 MHz. W układzie zintegrowano 128 MB RAM i 256 MB FLASH. Beagleboard posiada gniazdo rozszerzeń z 22 liniami sygnałowymi. Wbudowane w procesorze OMAP multipleksowanie pozwala uzyskać na nich sygnały 2 portów SPI, I2C, I2S, UART, MMC oraz kilkanaście portów GPIO. Oczywiście wyprowadzenia niektórych portów nakładają się na siebie. W odpowiedniej konfiguracji (każdy pin konfigurowany jest osobno) uzyskać można np. kilka portów GPIO, 2 porty SPI obsługujące 3 urządzenia podrzędne, UART z liniami RTS i CTS oraz port I2C. Dodatkowo do dyspozycji użytkownika jest port szeregowy domyślnie adaptowany na potrzeby konsoli systemowej (możliwy do przekonfigurowania) oraz port USB OTG.

19 3.2 System stereowizyjny 11 Zasoby oprogramowania są równie bogate jak dla platform Gumstix Verdex, czy Overo Earth. Praca z oprogramowaniem dla GPP realizowana jest głównie z wykorzystaniem projektu Open Embedded oraz kompilatorów skrośnych dla platformy ARM. Natomiast do tworzenia oprogramowania dla DSP wykorzystywane są narzędzia dostarczone przez Texas Instruments[1]. Zaletami tego rozwiązania są niewątpliwie wydajność, energooszczędność i małe wymiary. Do wad zaliczyć można cenę oraz brak dystrybutorów w Europie Podsumowanie W zasięgu rozważań znalazły się układy mikroprocesorowe własnej konstrukcji oraz gotowe rozwiązania. Te pierwsze wymagają większego nakładu pracy nad sprzętem a dostępne na rynku mikrokontrolery posiadają niewielką moc obliczeniową. Poza tym ograniczeniem, elastyczność takiego rozwiązania jest duża (choć obarczona coraz większą komplikacją systemu). Gotowe rozwiązania zwalniają niemal zupełnie z pracy nad sprzętową stroną zagadnienia. Dostarczają znacznie większej mocy obliczeniowej, ale i cena jest odpowiednio wyższa. Większość opisanych platform pozwoli (z większym lub mniejszym trudem) na obsługę zainstalowanych na LARS sensorów oraz napędów. Wyboru dokonano zatem w oparciu o funkcjonalność przydatną dla sensorów dodawanych do platformy. Chodzi głównie o system wizyjny. Do przetwarzania obrazu najbardziej nadają się kolejno platformy PC104, Beagleboard oraz Overo Earth. Platformę PC104 dyskwalifikują rozmiary i ilość pobieranej energii. Beagleboard natomiast nabiera sporej przewagi nad Overo ze względu na posiadanie procesora DSP i wyższą opłacalność. Zatem to ta platforma, Beagleboard, została wybrana. 3.2 System stereowizyjny Wstęp W założeniach LARS to autonomicznym robot mobilny. Potrzebuje więc dużej wiedzy o otoczeniu by móc się w nim bezkolizyjnie poruszać. Zainstalowane na platformie sensory PSD oraz sonary ultradźwiękowe dostarczają takich informacji. Zdarza się jednak, że są one niejednoznaczne, lub nawet mylące. Dla przykładu: sensory PSD są wrażliwe na kolor powierzchni i kąt pod jakim pada na nią wiązka miernicza. Sonary natomiast wprowadzają szereg znanych i dobrze opisanych problemów związanych z zafałszowaniem pomiaru w pobliżu naroży, czy cienkich kolumn. System stereowizyjny ma na celu uzupełnienie i zweryfikowanie wiedzy przez nie dostarczonej Aparat MCA-25 MCA-25 to moduł aparatu przeznaczony dla telefonów komórkowych. Dysponuje on matrycą o rozdzielczości VGA. Komunikacja z nim oparta jest o komendy AT[23]. Aparat obsługuje dwa tryby pracy: zdjęć (rozdzielczość 640x480, format JPEG, ok. 1 klatka na sekundę) i podglądu (rozdzielczość 60x80, format RGB332, ok. 6 klatka na sekundę). MCA-25 posiada prostą konstrukcję optyki - soczewka zespolona jest z obudową matrycy co uniemożliwia korekcję ostrości. W trybie zdjęć, przy dobrym oświetleniu, obraz potrafi być zaszumiony (rysunek 3.9) i może posiadać artefakty w postaci poziomych lub pionowych linii. Gorsza ekspozycja powoduje wzrost zaszumienia (rysunek 3.10). Dla trybu podglądu ilość użytecznych informacji zawartych w obrazie zmniejsza się drastycznie (rysunek 3.11). Rozważano zastosowanie MCA-25 dla platform opartych o mikrokontrolery MC68332 lub LPC2xxx. Standardowo obraz pobierany byłby w trybie podglądu. Kilka klatek na sekundę,

20 12 Przeglad rozwiazań Rysunek 3.8: Aparat MCA-25 Rysunek 3.9: Zdjęcie wykonane aparatem MCA-25 w trybie zdjęć przy dobrej ekspozycji

21 3.2 System stereowizyjny 13 Rysunek 3.10: Zdjęcie wykonane aparatem MCA-25 w trybie zdjęć przy słabym oświetleniu a) b) Rysunek 3.11: Zdjęcie wykonane aparatem MCA-25 w trybie podglądu przy oświetleniu a) dobrym, b) złym

22 14 Przeglad rozwiazań brak kompresji obrazu i mniejsza rozdzielczość przypuszczalnie pozwoliłyby na przetwarzanie obrazu w czasie rzeczywistym. W razie potrzeb, jednorazowo aparat przełączany byłby w tryb zdjęć w celu pobrania ramki w lepszej jakości. Zaletami tego rozwiązania są prostota, energooszczędność, obszerność dokumentacji, dostępność sterowników i cena. Wady to niska jakość obrazu Kamery internetowe Większość kamer internetowych wyposażona jest w interfejs USB 1.1 lub 2.0. Dla potrzeb projektu przegląd skoncentrowano na kamerach współpracujących ze sterownikiem UVC[12]. Sterownik ten jest jednym z lepiej ustandaryzowanych i wspieranych technicznie. Dostępny jest w dystrybucji Linux Angstrom[2] dla platformy BeagleBoard. Dla platform niższego poziomu (MC68332 czy LPC2xxx) nie istnieje sterownik UVC. Z resztą ich zasoby (pamięć, moc obliczeniowa) i tak są za małe. Listę kamer obsługiwanych przez sterownik UVC znaleźć można na stronie projektu[12]. Spośród nich wybrano Logitech QuickCam E3500. W odniesieniu do ogółu dostępnych na rynku Rysunek 3.12: Kamera internetowa Logitech QuickCam E3500 kamer internetowych, ta plasuje się w segmencie średnim. Wśród kamer UVC jest jednak prostszą konstrukcją. Posiada matryce o rozdzielczości VGA, soczewkę pozwalającą na regulację głębi ostrości oraz wbudowany mikrofon. Kamera ta dobrze spisuje się w warunkach złego oświetlenia (rysunki 3.13 i 3.14). Zawdzięcza to wbudowanemu algorytmowi poprawiania jakość obrazu przy złej ekspozycji. W skrajnych przypadkach algorytm ten potrafi jednak znacząco obniżyć ilość klatek na sekundę. Nie będzie to jednak istotny problem w projekcie. Dla porównania dołączono zdjęcia (rysunki 3.15 i 3.16) wykonane kamerą 1.3MPix instalowaną w komputerach przenośnych. Zdjęcia 3.15, 3.16 wyraźnie odbiegają jakością od zdjęć 3.13, Zaszumienie jest większe, gama kolorów bardziej uboga a do tego niezbędna jest dobra ekspozycja. Plusem tej kamery jest natomiast duża (i niezależna od zmian oświetlenia) ilość klatek dostarczanych w sekundę.

23 3.2 System stereowizyjny 15 Rysunek 3.13: Zdjęcie wykonane kamerą QuickCam E3500 przy dobrej ekspozycji Rysunek 3.14: Zdjęcie wykonane kamerą QuickCam E3500 przy słabym oświetleniu Rysunek 3.15: Zdjęcie wykonane kamerą wbudowaną przy dobrej ekspozycji

24 16 Przeglad rozwiazań Rysunek 3.16: Zdjęcie wykonane kamerą wbudowaną przy słabym oświetleniu Podsumowanie Wyboru jednostki centralnej dokonano z myślą o systemie wizyjnym. Wpływa to także na dobór kamer. Preferowane są rozwiązania mogące wykorzystać zaplecze sprzętowe i programowe jednostki centralnej. System Linux dysponuje sterownikami dla kamer internetowych oraz pakietami takimi jak Open CV, ARToolKit[3] czy GStreamer[8]. Składają się one na wygodne, efektywne i bogate w funkcje środowisko komputerowego przetwarzania obrazu. Dlatego też zdecydowano się ostatecznie na kamery Logitech QuickCam E3500. Przedstawione zalety okupione zostały niską energooszczędnością. Według producenta pojedyncza kamera pobiera do 500 ma. 3.3 Komunikacja bezprzewodowa Dzięki komunikacji bezprzewodowej platforma LARS może współpracować z otaczającym ją światem. Możliwa staje się wizualizacja zachowania i sterowanie platformą oraz kooperacja w obliczeniach. Aby funkcje te działały sprawnie niezbędny jest kanał transmisyjny o wystarczającej przepustowości. Obok uniwersalności będzie to jeden z głównych argumentów rządzących wyborem technologii transmisji. LARS wyposażony jest już w moduł komunikacji WT12 Bluetooth [34]. Działa on w technologii Bluetooth EDR i dostarcza przepustowości 2-3 MBps w trybie asynchronicznym. Przewidziany był do współpracy z jednostką centralną bazującą na mikrokontrolerze MC Komunikacja z nim realizowana miała być poprzez port szeregowy. Nieskomplikowany zestaw komend czynił to rozwiązanie idealnym do ówczesnych zastosowań. Ze względu na aspekty opisane na wstępie, oraz fakt, że jednostka centralna korzysta z Linux, konieczne okazały się zmiany. Technologia Bluetooth 2.0 nie daje wystarczającej przepustowości. Prostota pracy z modułem WT12 okazują się tracić na nadzwyczajności w porównaniu z możliwością wykorzystania kart bezprzewodowych Wi-Fi - dobrze wspieranych przez Linux. Standard IEEE g[11] dostarcza realnych przepustowości asynchronicznych do 20 MBps. Wykorzystanie gotowych modułów sterowników oraz ogólnodostępnych i otwartych bibliotek komunikacji przenosi zagadnienie komunikacji bezpośrednio do warstwy aplikacji końcowej. Nawiązaniem połączenia, jego szyfrowanie czy korekcja błędów transmisji spoczywa na jądrze systemu i biblioteki towarzyszących. W systemie Linux, jednym z lepiej wspieranych układów komunikacji Wi-Fi są układy firmy

25 3.4 Czytnik RFID 17 RaLink, dlatego wybrano kartę Linksys WUSB54GC[22]. Karta ta posiada port USB 2.0, obsługuje technologie b/g oraz szyfrowania WEP, WPA i WPA2. W odniesieniu do modułu WT12 przegrywa tylko na polu energooszczędności. Według producenta konsumować może do 500 ma gdy moduł WT12 ogranicza się do 60 ma. Rysunek 3.17: Karta bezprzewodowa Linksys WUSB54GC 3.4 Czytnik RFID Przed czytnikiem RFID stawiane będą zadania identyfikacji elementów odnalezionych w otoczeniu robota oraz rozpoznawania miejsc (bram, korytarzy itp.). Zbędne jest tutaj stosowanie wysublimowanych urządzeń i technologii. Przy doborze czytnika RFID ograniczono się zatem do konstrukcji prostych i energooszczędnych. Podczas poszukiwań natrafiono na czytnik RFID Unique[29]. Pracuje on w częstotliwości a) b) Rysunek 3.18: Zestaw RFID: a) Czytnik RFID Unique, b) Identyfikatory RFID 125kHz. Posiada antenę w postaci cewki o średnicy 55mm. Sam moduł czytnika ma wymiary 18 mm x 20,5 mm x 7 mm. Zużywa 20 ma w trakcie normalnej pracy i 1,2 ma w trybie uśpienia. Do komunikacji z układem nadrzędnym czytnik korzysta z portu szeregowego w standardzie TTL 5V. Obsługuje transmisję danych tylko w kierunku wychodzącym. Linia Tx zakończona jest tranzystorem w układzie otwartego kolektora (przewidziano współpracę kilku czytników na jednej linii transmisyjnej). Do czytnika dobrano identyfikatory w postaci kart z tworzywa PVC o wymiarach 86 mm x 54 mm x 1 mm. Każdy z nich posiada 5-bajtowy unikalny niemodyfikowalny klucz. Dla poprawnej pracy czytnika odległość anteny od identyfikatora-karty nie powinna przekraczać 8 cm (absolutna granica to 12 cm). Dystans dla breloków/pastylek jest mniejszy.

26

27 Rozdział 4 Rozbudowa mechaniki minirobota 4.1 Wstęp Punktem wyjściowym niniejszej pracy był robot LARS z gotową i sprawną mechaniką, czekający na oprogramowanie jednostki centralnej. W czasie realizacji postanowiono jednak istotnie rozszerzyć funkcjonalność platformy. Zastosowano BeagleBoard jako jednostkę centralną i zdecydowano się na wyposażenie robota w system stereowizyjny. Nieunikniona stała się zatem rozbudowa konstrukcji. 4.2 Modyfikacje konstrukcji wewnętrznej Poprzednia jednostka centralna - moduł em332[35], ulokowana była w lewej przedniej części robota. Była ona ściśle związana z płytkami P_332v1 oraz P_332v2. Znajdowały się one pod nią i stanowiły płytę główną udostępniającą wyprowadzenia jednostki centralnej. Wszystkie trzy wymienione tu elementy zostały wymontowane. Ich zadanie przejęła nowa jednostka centralna - BeagleBoard, wyposażona w płytkę translacji napięć P_T RANS (opisano w rozdziale 5.1). Miejsce instalacji, z powodu większych rozmiarów, uległo zmianie. Jednostka centralna ulokowana została w tylnej części robota, w miejsce (również wymontowanej) płytki P_WY S. Płytka P_WY S stanowiła prosty układ pośredni pomiędzy poprzednią jednostką centralną, a wyświetlaczem i przyciskami umieszczonymi w górnej pokrywie robota. Zdemontowana została także płytka P_W T 12 wraz z osadzonym na niej modułem Bluetooth. Platformę wyposażono w dwa dodatkowe sterowniki: sterownik PWM/LCD (opisano w rozdziale 5.2) oraz sterownik enkodera (opisano w rozdziale 5.3). Pierwszy z nich ulokowano nad płytkami P_TACT i P_SON. Drugi natomiast z racji prostoty układu i zaleceń na temat krótkiego przewodu, wbudowano bezpośrednio w przewód. Funkcjonalność złącza BDM została zmieniona, obecnie jest ono portem szeregowym pracującym w standardzie napięciowym RS232. Przy tylnej ścianie obudowy umieszczono koncentrator USB z wpiętą do niego kartą bezprzewodową. 4.3 Konstrukcja głowicy stereowizyjnej Głowica umożliwia ruch obrotowy w osi pionowej i poziomej. Jej model kinematyki prezentuje rysunek Model rozszerzony jest o translacje i rotacje związane z rozstawieniem kamer na poprzeczce oraz z konstrukcją samej kamery (położenie ogniskowej względem punktu zamocowania kamery). Opis kinematyki w notacji Denavita-Hartenberga przedstawia poniższy wzór.

28 20 Rozbudowa mechaniki minirobota Parametr s określa koniec łańcucha kinematycznego (objaśnienie na rysunku 4.2). gdzie długości członów wynoszą: A 2 0 = RotZ(q 1) TrZ(l 1 ) RotX( π 2 ) RotZ(q 2 ) T x(l 2 + l 3 ) RotZ( π 2 ) T z(s l 3) T x(l 4 ) RotX( π 2 ) (4.1) l1 = 56mm l2 = 23mm l3 = 15mm l4 = 3mm l5 = 45mm Stopa, kolumna, klamra obrotowa i poprzeczka wykonane są z aluminium, wałki osi obroto- Rysunek 4.1: Głowica stereowizyjna wych i drążki serwomechanizmów wykonano ze stali. Połączenia obrotowe są łożyskowane co zapewnia precyzję ruchów oraz umożliwia intensywniejszą pracę i przenoszenie większych obciążeń. Osie obrotu przecinają się. Zakres obrotu osi poziomej, z powodu ograniczeń konstrukcyjnych, wynosi ±45 względem płaszczyzny stopy. Jej napędem jest serwomechanizm Hitec HS-81[25]. Zakres obrotu osi poziomej ograniczany jest tylko prze układ napędowy osi i wynosi ±70. Napęd stanowi serwomechanizm TowerPro MG995 [18]. Głowica posiada stosunkowo uniwersalną przestrzeń montażową. Serwomechanizm osi poziomej przytwierdzono do korpusu za pomocą aluminiowego koszyczka. Koszyczek ten stanowi punkt zaczepu drążka sterującego osi pionowej. Połączenia drążków sterujących wykonano tak, by przenosiły kąt i moment obrotowy z przełożeniem 1:1 (rysunek 4.3). Nastawy osi są dzięki temu jednoznaczne z nastawami serwomechanizmów. Jednorazowej kalibracji podlegają tylko punkty neutralne napędów (czyli kamery patrzą w poziomie, przed robota). Kamery przytwierdzone są do poprzeczki spoczywającej na głowicy. Obecna konstrukcja nie

29 4.3 Konstrukcja głowicy stereowizyjnej 21 Rysunek 4.2: Model kinematyczny głowicy stereowizyjnej a) b) Rysunek 4.3: Szkic modelu przełożenia sterowania w głowicy: a) oś pozioma, b) oś pionowa

30 22 Rozbudowa mechaniki minirobota przewiduje zmiany bazy układu stereowizyjnego. Modyfikacji takiej łatwo jest jednak dokonać wymieniając poprzeczkę. Rozstaw kamer wynosi 90 mm, kąt widzenia kamery wynosi 48. Na dystansie do ok. 100 mm otrzymujemy obrazy w pełni rozdzielne - brak stereowizji. Głowicę stereowizyjną zamontowano na stelażu ewaluacyjnym. Miejsce wybrano tak, by przy dowolnych nastawach w przegubach głowicy, poprzeczka z kamerami nie wyłaniała się poza obrys obudowy robota, a zwłaszcza poza zderzak aktywny. Kształt obudowy kamer utrudniał precyzyjny i solidny montaż. Zdecydowano się na wymontowanie płytek kamer z obudów. Wklejono je następnie żywicą epoksydową na ceowniki z PVC o wysokości 9 mm. W ten sposób uzyskano płaską precyzyjną powierzchnię ułatwiającą przykręcenie kamer do poprzeczki. Ceowniki nie wychodząc poza obrys płytek kamer, dzięki temu przy ustawianiu bazy układu stereowizyjnego można wspomóc się precyzją wykonania samych kamer. Mocowanie takie zapewnia jednakową wysokość montażu kamer, równoległość osi patrzenia kamer oraz brak skręceń względem tych osi. Otwory montażowe w poprzeczce pod śruby kamer są o około 2 mm większej średnicy niż średnica śrub. Zwalnia to z obowiązku wykonania ich z dużą precyzją rozstawu i zapewnia wystarczający luz dla ustawienia kamer. Do ustawienia bazy wystarczy suwmiarka: 1. Od środka poprzeczki do boku pierwszej kamery odmierzamy połowę wymiaru bazy pomniejszoną o połowę szerokości kamery. Kamera powinna przylegać równo dolną krawędzią do dolnej ściany poprzeczni. Błąd pomiaru odległości na tym etapie będzie się przekładał 1 do 1 na błąd przesunięcia w prawo lub lewo punktu zidentyfikowanego na obrazie stereowizyjnym. 2. Od bocznej ścianki pierwszej kamery odmierzamy dystans do bocznej ścianki drugiej kamery równy wymiarowi bazy pomniejszonemu o szerokość kamery. Błąd pomiaru na tym etapie będzie pomniejszał dokładność układu stereowizyjnego ponadproporcjonalnie względem odległości przedmiotu od układu. 4.4 Instalacja czytnika RFID Antenę czytnika postanowiono przymocować na jednym z boków robota. Pozwala to uniknąć skomplikowanych manewrów dojazdowych w celu odczytania znaczników. Zainstalowano ją na bocznej poprzeczce ewaluacyjnej. Mocowanie bezpośrednio na bocznej ścianie robota jest niemożliwe - bliskość anteny względem metalowej powierzchni zmniejsza zasięg poprawnego działania układu do ok 4 cm. Z wnętrza obudowy robota wyprowadzono dwa przewody dla czytników RFID, by w przyszłości można było doinstalować kolejny czytnik z drugiej strony. Rysunek 4.4: Mocowanie czytnika RFID.

31 4.5 Wyprowadzenie przewodów połaczeniowych Wyprowadzenie przewodów połaczeniowych Korpus robota stanowi niemal w pełni zamkniętą bryłę wykonaną z metalu. Jest zatem klatką Faraday a 1. Z tego powodu antena karty bezprzewodowej wyprowadzona została poza obudowę. W tym celu, w karcie, w miejsce wbudowanej anteny wlutowano przewód RG178 zakończony gniazdem RP-SMA. Gniazdo przykręcono w porywie górnej a do niego antenę o zysku 2 db. Przewodów kamer układu stereowizyjnego nie wprowadzano do wnętrza. Podłączono je a) b) Rysunek 4.5: Wyprowadzenie przewodu karty WiFi: a) modyfikacje karty, b) gniazdo antenowe do przedłużaczy wyprowadzonych na zewnątrz. Dzięki temu kalibrację układu przeprowadzać można na komputerze zewnętrznym bez udziału jednostki centralnej. Pod stelażem ewaluacyjnym wykonano otwór do przeprowadzenia przewodów dla kamer, serwomechanizmów oraz czytników RFID. Port debagowy BDM umieszczony na górnej pokrywie robota (czarne żeńskie złącze DB-9) zmienił swoją funkcję - obecnie jest portem szeregowym w standardzie napięciowym RS-232. Udostępnia on konsolę systemową Beagleboard. Parametry transmisji to n8. 1 Do i z wnętrza bryły wykonanej z metalu nie przenikają fale elektromagnetyczne o długości większej niż wymiary otworów w ściankach bryły

32

33 Rozdział 5 Rozbudowa sterowników minirobota Zmiana jednostki centralnej spowodowała szereg zmian w strukturze sterowania platformą. Port QSPI zapewniał mikroprocesorowi MC68332 komunikację z enkoderem oraz sterownikami sensorów, dalmierzy i taktylnym. Komunikację bezprzewodową zapewniał moduł bluetooth obsługiwany przez port szeregowy SCI. Standardowe linie GPIO służyły do obsługi wyświetlacza i przycisków. Sterowanie napędem i serwomechanizmem kierującym realizowane było natomiast poprzez moduł TPU. Złącze rozszerzające BeagleBoard rev.b7[21] w optymalnej dla projektu konfiguracji posiada dwa porty SPI, port szeregowy, port I2C oraz kilka portów GPIO. Zupełnie brak jest linii PWM. Porty SPI posiadają tylko 3 linie ChipSelect. Dodatkowo obsługa wyświetlacza LCD poprzez porty GPIO mogłaby okazać się mało praktyczna ze względu na sposób sterowania tymi liniami w systemie Linux. Główną barierę stanowi niekompatybilność elektryczna platformy Beagle- Board działającej w standardzie TTL 1V8 i elektroniki robota działającej w standardzie TTL 5V. 5.1 Płytka translacji napięć Rysunek 5.1: Płytka translacji napięć Problem różnych standardów napięć rozwiązano stosując układ TXS0108E[27]. To dwukierunkowy konwerter napięć z automatycznym wykrywaniem kierunku transmisji. Linie układu mogą pracować w konfiguracji push pull (z prędkością do 60 Mbps) oraz z wyjściami typu

34 26 Rozbudowa sterowników minirobota otwarty dren (z prędkością do 2 Mbps). Dzięki temu, w niezmienionej konfiguracji sprzętowej, układ jest w stanie przekazać poprawnie wszystkie sygnały jakie wyprowadzić lub odebrać chce BeagleBoard. W oparciu o TXS0108E zaprojektowano płytkę translacji napięć P_T RANS. Schemat przedstawiają rysunki 5.2 i 5.3. Zadaniem płytki jest konwersja napięć pomiędzy Rysunek 5.2: Schemat segmentów zasilania oraz układów translacji napięć płytki P_T RANS.

35 5.1 Płytka translacji napięć 27 Rysunek 5.3: Schemat segmentu gniazd płytki P_T RANS.

36 28 Rozbudowa sterowników minirobota standardami TTL 5V i 1V8, oraz wyprowadzenie sygnałów na złącza portów komunikacyjnych. Płytka posiada wyprowadzone porty SPI3 i SPI4, każdy dla 4 urządzeń podrzędnych. Należy zwrócić w tym miejscu uwagę na przypisanie linii GPIO do ChipSelect. Port SPI3 posiada tylko 2 sprzętowe linie CS, SPI4 natomiast tylko jedną [21][28]. Brakujące linie zostały uzupełnione portami GPIO (schemat 5.2). Pozostałe porty komunikacji to port szeregowy UART2 1, oraz port I2C2 2. Na etapie projektowania płytki nieznane było jej pełne zastosowanie, dlatego wyposażono ją w trzy źródła zasilania napięciem 1V8. Załącza się je zworkami. Jedno pochodzi z Beagleboard, drugie ze stabilizatora LDO NCP1117DT18G[32] a trzecie z przetwornicy opartej o układ MCP1603[30] o stałym napięciu odniesienia. Ostatecznie wykorzystywane będzie tylko zasilanie z Beagleboard. 5.2 Sterownik PWM/LCD LARS potrzebuje co najmniej 3 sygnałów PWM dla sterowania serwomechanizmami, oraz przynajmniej jednego sygnału PWM dla sterowania silnikiem napędowym. Platforma Beagle- Board rev.b7[21] nie posiada jednak żadnej linii PWM. Zdecydowano się więc na budowę sterownika, który dodatkowo obsłuży również wyświetlacz LCD. Płytka P_PW MLCD bazuje Rysunek 5.4: Płytka sterownika PWM/LCD na mikrokontrolerze LPC2103[31] firmy NXP (schemat na rysunku 5.5). Posiada on 4 układy licznikowe, w oparciu o które zrealizować można do 14 sprzętowych linii PWM. Ostatecznie uzyskano: 6 linii SERVO_xy (f = 50Hz, rozdzielczość 20000), 6 linii PWM_xy (f = 10 KHz, rozdzielczość 1000), komplet linii sterujących wyświetlaczem LCD (zgodnym z HD44780[24]) w trybie 4-bitowym, bez odczytu i bez sprawdzania flagi zajętości. Dostępne są również 4 wyjścia binarne BINx. Sygnały SERVO_xy są w standardzie TTL 3V3. By zmodyfikować je do TTL 5V wystarczy zastosować rezystor pull-up (przykładem jest SERVO_A0). Linie sterujące wyświetlaczem LCD również pracują w standardzie TTL 3V3. Dla uzyskania TTL 5V, sygnały PW M_xy oraz wyjścia BINx przeprowadzono przez bufory odwracające 74HCT240[26]. Po odwróceniu stanów logicznych, na wyjściu otrzymujemy sygnał PWM który rozpoczyna się stanem wysokim. Odwrócenie sygnałów SERVO_xy odbywa się programowo, przy czym ich stan wysoki ulokowany jest pod koniec przebiegu. 1 Uwaga, numeracja portów realizowana przez jądro Linux może odbiegać od numerów widniejących w notach katalogowych dla BeagleBoard[21] i OMAP3530[28] 2 Uwaga, numeracja portów może być rozbieżna.

37 5.2 Sterownik PWM/LCD 29 Rysunek 5.5: Schemat płytki P_PWMLCD

38 30 Rozbudowa sterowników minirobota Komunikacja z układem zrealizowana została przez port szeregowy z wykorzystaniem tylko linii Rx mikrokontrolera. Dodatkowego wyjaśnienia wymaga linia INT. Łącząc ją z linią INT wychodzącą ze sterownika taktylnego zapewnimy, w momencie wykrycia kolizji, natychmiastowe zatrzymanie silnika napędowego. Algorytm działania sterownika rozpoczyna się od inicjalizacji systemu: SERVO_xy w pozycji neutralnej (1500), PW M_xy o zerowym wypełnieniu, BINx w stanie niskim, zainicjalizowany wyświetlacz. Port szeregowy obsługiwany w przerwaniach czeka na nadejście danych. Pierwszy odebrany bajt jest adresem rejestru sterownika. Jeśli nie jest to rejestr wyświetlacza, to odbierane i wpisywane do zadanego rejestru są dwa kolejne bajty 3. Jeśli to rejestr wyświetlacza, to każdy kolejny znak do momentu napotkania \0 przenoszony jest do bufora wyświetlacza. 45. Gdy transmisja dla wyświetlacza się zakończy, program przechodzi do wyświetlenia napisu. Wartości z rejestru sterownika przepisywane są do odpowiednich rejestrów procesora z częstotliwością 50Hz Sterownik enkodera Enkoder silnika napędowego skonstruowany jest w oparciu o układ AS5040[20]. Posiada on port komunikacji w standardzie SSI (Synchronous Serial Interface). Standard ten zbliżony jest do standardu SPI. Jest jednak spora różnica pomiędzy nimi. SSI wymaga próbkowania danych na koniec pełnego okresu linii zegarowej (rysunek 5.6), czego port SPI nie jest w stanie zrobić. Z tego powodu zdecydowano się na programową realizację szyny SSI. Skonstruowano prosty Rysunek 5.6: Przebiegi czasowe na porcie SSI enkodera AS5040 sterownik w oparciu o mikrokontroler ATmega8[19] (rysunek 5.7). Pierwszym z jego zadań jest odczyt (w pętli programowej) danych z enkodera. Drugim zadaniem jest obsługa przerwań od portu SPI, poprzez który udostępniane są pomiary. 5.4 Koncentrator USB Koncentrator USB powinien być wyposażony we własne źródło zasilania. Port USB OTG w Beagleboard dostarcza tylko 100 ma[21]. Znakomita większość koncentratorów posiada wewnętrznie zwarte linie zasilania z portu USB hosta oraz z gniazda zasilacza zewnętrznego. Urządzenia podłączone do koncentratora według producentów pobierać mogą sumarycznie nawet 1,5 A. Przy zasilaczu zewnętrznym o małej wydajności prądowej, spory spadek napięcia 3 Kolejność bajtów: MSB, LSB 4 Pojemność bufora to 83 = 2 * (40 znaków w linii + \n ) + \0 gdzie \n = 10 (jest jednobajtowe) 5 Przepełnienie bufora spowoduje jego zawinięcie się do początku i nadpisanie danych 6 Z częstotliwością 50Hz sterowane są serwomechanizmy, więc większa częstotliwość aktualizacji sterowania jest zbędna

39 5.4 Koncentrator USB 31 Rysunek 5.7: Schemat sterownika enkodera odbija się na układzie TWL4030 zasilającym Beagleboard. Intensywne przegrzewanie się może naturalnie spowodować jego uszkodzenie. Problem zwarcia linii zasilania rozwiązać można zazwyczaj wstawiając w linię GND lub VCC portu USB rezystor rzędu kilku kω 7 lub stosując tranzystor polowy kluczujący zasilanie zewnętrzne sterowany zasilaniem z portu USB. Aby uruchomić port USB OTG w trybie Host należy zewrzeć pin 4 gniazda z pinem 5 (GND). Niezbędne jest to gdy wtyczka koncentratora to USB Mini-B. Gdy stosujemy USB Mini-A, piny te zwarte są już w obudowie wtyku. W projekcie zwarto piny zworką umieszczoną wewnątrz portu. W systemie Linux Angstrom, od wersji jądra (włącznie) pojawiły się problemy z detekcją większości niskiej jakości koncentratorów. System nie wykrywa ich na starcie. Pomaga, czasami kilkukrotne, odłączenie i podłączenie koncentratora do portu USB. 7 Zupełne oddzielenie linii GND lub VCC z gniazda USB spowoduje niewykrywanie koncentratora.

40

41 Rozdział 6 Stanowisko pracy nad oprogramowaniem 6.1 Wstęp Procesor główny Beagleboard skonstruowany jest w architekturze ARM Cortex-A8[28]. Programy przygotowywane na na zewnętrznych maszynach (przeważnie o arch. x86) podlegać muszą kompilacji skrośnej. Proces ten, np. dla mikrokontrolerów, z powodzeniem może być zrealizowana przy użyciu Makefile. Rozwiązanie to jest jednak zupełnie nieaplikowalne dla projektu złożonego z tysięcy oddzielnie rozwijanych pakietów. Z pomocą przychodzi tutaj środowisko OpenEmbedded[14]. OpenEmbedded to zbiór metadanych. W ich skład wchodzą pliki konfiguracyjne opisujące własności maszyn, przepisy parkietów oraz poprawki do podstawowych wersji pakietów. Przepisy mówią jak pobrać i przystosować niezbędne źródła, kontrolują zależności, organizują kompilację skrośną i określają postać wynikową zbudowanego programu. OE przechowuje zatem informacje, które użyteczne są dopiero w połączeniu z dodatkowymi narzędziami. 6.2 Niezbędne narzędzia OpenEmbadded łączy w sobie tysiące projektów, począwszy od jądra Linux, przez biblioteki po programy użytkowe mające działać w systemie. Główna linia rozwojowa OE modyfikowana jest przez wąskie grono osób, ale rozwija i wykorzystuje ją ogromna ilość ludzi. Z tego powodu całość OE przechowywana i udostępniana jest jako repozytorium GIT[7]. GIT to szybki i wydajny system wersjonowania działający obecnie w projektach takich jak Linux Kernel, Qt, Fedora i wiele innych. Zalecana jest instalacja GIT z repozytoriów systemu (sudo apt-get install git). Każdy z pakietów OE rozwijany jest indywidualnie przez grono programistów z nim związanych. Starają się oni tworzyć kod przenośny. Nie uzależniają go od konkretnej platformy i nie przystosowują dla potrzeb projektów takich jak OE. Projekty najczęściej udostępniane są jako archiwum ze źródłami lub odnośnik do repozytorium np. CVS lub SVN. Metody i parametry ich kompilacji są ściśle określone. Linkowanie statyczne i dynamiczne narzuca zależności względem innych pakietów. O spełnienie tych zależności użytkownik musi zadbać sam. Gdy kompilacja odbywa się skrośnie, sprawa budowy nawet prostego pakietu może stać się bardzo skomplikowana. Począwszy od skompletowania i właściwego użycia łańcucha narzędzi, przez dobranie odpowiednich parametrów kompilacji oraz dostarczenie linkerowi bibliotek statycznych, po zapewnienie bibliotek dynamicznych do późniejszego uruchomienia aplikacji. Prawdopodobnie przed tym wszystkim użytkownik zechce jeszcze zmodyfikować kod źródłowy by program lepiej sprawował się na platformie docelowej. Dla stworzenia podstawowego obrazu skompilować musielibyśmy w taki sposób kilkaset paczek/projektów. Całą tą pracę w OE wy-

42 34 Stanowisko pracy nad oprogramowaniem konuje BitBake[5]. Jak wspomniano, OE to tylko zbiór metadanych. BitBake natomiast jest programem, który je przetwarza i na ich podstawie rozwiązuje problemy opisane powyżej. Zalecane jest pobrać BitBake w wersji Najlepiej wykonać 1 : cd $OE_HOME wget tar -xvzf bitbake tar.gz mv bitbake bitbake 6.3 Pobieranie i kompilowanie źródeł projektu Niniejszy opisa bazuje na informacjach pochodzących z domowej strony projektu OpenEmbedded[14], z instrukcji[33] oraz ze strony projektu Beagleboard[4], tam też znaleźć można bardziej szczegółowe informacje. Pracę należy rozpocząć od stworzenia katalogu głównego dla projektu: mkdir /oe W pliku /.bashrc zlecamy eksport zmiennej OE_HOME dodając na końcu: export OE_HOME=$HOME/oe export PATH=$PATH:$OE_HOME/bitbake/bin Dołączono do ścieżek przeszukiwania katalog binarii bitbake. Po zrestartowaniu konsoli kontrolujemy, czy uruchamiane jest właściwe bitbake: which bitbake odpowiedź powinna być zgodna z: $OE_HOME/bitbake/bin/bitbake Przystępujemy do pobrania repozytorium OpenEmbedded: cd $OE_HOME git clone git://git.openembedded.net/openembedded Dla tak pobranego projektu, utworzona została automatycznie lokalna gałąź org.openembedded.dev bazująca na origin/org.openembedded.dev - wersja rozwojowa projektu. Tworzymy lokalną gałąź stable/2009 bazując na wersji zdalnej origin/stable/2009: cd openembedded git checkout origin/stable/2009 -b stable/2009 Następnie definiujemy konfiguracji projektu. Zrobi to skrypt: mkdir -p $OE_HOME/beagleboard/beagleboard/conf cat > $OE_HOME/beagleboard/beagleboard/conf/local.conf <<_EOF DISTRO = angstrom BBFILES = $OE_HOME/openembedded/recipes/*/*.bb TMPDIR = $OE_HOME/tmp MACHINE = beagleboard ENABLE_BINARY_LOCALE_GENERATION = 0 _EOF W pliku $OE_HOME/beagleboard/beagleboard/conf/local.conf zapisana została podstawowa konfiguracja: dystrybucja (DISTRO), ścieżka do przepisów (BBFILES), ścieżka robo- 1 $OE_HOME zdefiniowano w kolejnym rozdziale

43 6.3 Pobieranie i kompilowanie źródeł projektu 35 cza bitbake (TMPDIR), urządzenie docelowe (MACHINE) oraz wyłączono zupełnie generowanie locale (ENABLE_BINARY_LOCALE_GENERATION= 0 ). Zalecane jest, również na komputerach z procesorem jednordzeniowym, dołączenie parametrów: BB_NUMBER_THREADS = 2 PARALLEL_MAKE = -j 2 Parametr BB_NUMBER_THREADS określa ilość wątków w jakich uruchomione jest bitbake. Gdy jeden wątek kompiluje źródła projektu X, drugi może już pobierać źródła projektu Y. Parametr PARALLEL_MAKE określa natomiast ilość wątków w jakich uruchamiane jest make (w projektach kompilowanych z użyciem Makefile). Znane są problemy z błędami kompilacji spowodowanymi wielowątkowością make, zatem opcji tej należy używać ostrożnie. Dodatkowo, dla wygody programisty, tworzony jest plik profile.sh. cd $OE_HOME cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF export OE_HOME=\$HOME/oe export MY_OE_CONF= beagleboard export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF: \$OE_HOME/openembedded export BBFILES= \$OE_HOME/openembedded/recipes/*/*.bb export BB_ENV_EXTRAWHITE= MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME export PATH=\$OE_HOME/openembedded/bitbake/bin:\$PATH if [ \$PS1 ]; then if [ \$BASH ]; then export PS1= \[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \$PS1 fi fi _EOF chmod +x $OE_HOME/beagleboard/beagleboard/profile.sh Wyjaśnień wymaga BB_ENV_EXTRAWHITE. Zmienne środowiskowe dostępne w powłoce, a nie wymienione w BB_ENV_EXTRAWHITE, będą ignorowane przez bitbake. Posiadamy już gotowe środowisko pracy. Aby zbudować obraz wystarczy zadbać o zmienne środowiskowe: source $OE_HOME/beagleboard/beagleboard/profile.sh i wywołać: cd $OE_HOME bitbake console-image Console-image to prosty obraz systemu bez bibliotek graficznych. Podczas pracy bitbake wykorzystuje informacje zawarte w pliku local.conf oraz w przepisie console-image.bb. Na ich podstawie dociera do pliku $OE_HOME/openembedded/conf/machine/beagleboard.conf (zmienna MACHINE), skąd czerpie informacje o architekture procesora, preferowanym formacie obrazu systemu itp.. Z pliku $OE_HOME/openembedded/conf/distro/angstrom conf (zmienna DISTRO) pochodzą informacje takie jak wersja jądra, preferowane wersje kompilatora i glibc, pakiety włączane w dystrybucję itp.. Proces rozpoczyna się od analizy wszystkich przepisów znalezionych w ścieżkach BBFILES. Uzyskane informacje lądują w katalogu $TMPDIR/cache. Do katalogu $TMPDIR/download trafią pobrane źródła pakietów. Stworzony łańcuch skrośny umieszczony będzie w $TMPDIR/cross. Kompilacja przeprowadzona zostanie w katalogu $TMPDIR/work. To tam źródła każdego pakietu zostaną skopiowane, zmodyfikowane(jeśli dostarczono poprawki), skonfigurowane, skompilowane, posegregowane i przygotowane do stworzenia paczek insta-