staszek

Ja kupiłem na Allegro. Jeśli nie możesz znaleźć, polecam znaleźć stronę producenta, skontaktować się z nim i poprosić o wystawienie. pozdrawiam Stachu

Syntezator mowy w Twoim robocie Streszczenie Artykuł prezentuje sposób wykorzystania syntezatora mowy w amatorskim robocie społecznym. Omawia instalację darmowego syntezatora o nazwie Festival. Przedstawiony zostanie skrypt, który pozwoli na pobranie z sieci najświeższych wiadomości, repertuaru kin, prognozy pogody lub kursów walut (z RSS), i odczytanie ich przez Twojego robota. 1. Wstęp Szybki rozwój syntezatorów mowy zaowocował ich obecnością w życiu codziennym. Zdziwił byś się, w jak wielu miejscach są wykorzystywane. Proponuję Ci następujący eksperyment: jeśli posiadasz telefon w sieci Dialog, wyślij na numer stacjonarny wiadomość SMS. Jeśli twój aparat nie odbiera SMS'ów, za parę sekund zadzwoni automat, który odczyta treść wiadomości i numer nadawcy. Miejsce Polski jest szczególne w tej dziedzinie. Obecnie syntezator Ivona ( http://www.ivona.com/ ) uważany jest za najlepszy na świecie. Jeśli jesteś zafascynowany syntezą mowy i chciałbyś wykorzystać ją w swoim robocie, ten artykuł może Cię zainteresować. 2. Sprzęt Niniejszy artykuł prezentuje sposób implementacji syntezatora Festival w robocie wykorzystującym system Linux. Wykonany przeze mnie robot wyposażony jest w thinclient HP Evo T20, który posiada kartę dźwiękową. Sposób modyfikacji tego urządzenia pod względem wykorzystania w robotyce omówiłem w innym artykule: https://www.forbot.pl/forum/topics20/driver-do-player-stage-na-mini-komputerze-vt2192.htm?sid=36ab17551b888d0c4a9defdb0b818bb7 . Również tam znajdziesz linki, jak zainstalować Linux'a na Evo T20. Rysunek 1. Robot wykorzustujący HP Evo T20. Ponadto w swoim robocie używam głośniczków Nokia MD-8, zasilanych przez 3 baterie AAA. Wymiary ok. 120x45. Rysunek 2. Nokia MD-8 3. Konfiguracja dźwięku na Evo T20 Jeśli zdecydujesz się na wykorzystanie Evo T20, być może napotkasz na problem z obsługą karty dźwiękowej. Każdy system jaki instalowałem na tym urządzeniu (DSL, Debian, Ubuntu) uruchamia driver „kahula”, który nie działa. Rozwiązanie problemu znajduje się na stronie http://www.mowson.org/karl/articles/DEvoSL-sound/ . Sugeruję dodać do ~/.bashrc kod proponowany przez Bartka Szurgota: modprobe sb io=0x220 irq=7 mpu_io=0x300 4. Festival Festival jest darmowym syntezatorem mowy, również do zastosowań komercyjnych. Próbki dźwięku możesz wykonać na stronie: http://www.cstr.ed.ac.uk/projects/festival/onlinedemo.html . Próbki języka polskiego znajdują się w załączniku (na końcu postu). Niestety jakość polskiego głosu jest zdecydowanie niższa, niż tych na stronie, ponieważ wykorzystuje on starszą metodę syntezy. Powód dla którego korzystam z festival'a to przede wszystkim jego licencja i łatwa obsługa. Jeśli chcesz możesz skorzystać z innego syntezatora. Listę niektórych znajdziesz tutaj: http://pl.wikipedia.org/wiki/Synteza_mowy . 5. Instalacja festival'a i polskiego głosu Jeśli korzystasz z DEvoSL, Festival możesz zainstalować za pomocą aplikacji MyDSL. Jeśli korzystasz z Ubuntu lub Debiana, również możesz skorzystać z systemowych paczek: sudo apt-get install festival Niestety języka polskiego nie można zainstalować z repozytoriów. W załączniku umieściłem potrzebne pliki. Autorami paczki są D. Oliver, A. W. Black oraz M. Truszel. Rozpakuj ją do folderu /usr/share/festival/voices/polish/ . sudo mkdir /usr/share/festival/voices/polish tar -zxf cstr_pl_em_diphone.tar.gz sudo mv cstr_pl_em_diphone /usr/share/festival/voices/polish/ Następnie w pliku /usr/share/festival/languages.scm dodaj linijki z definicją języka i polskiego głosu... (define (language_polish) "(language_polish) Set up language parameters for Polish." (set! male1 voice_cstr_pl_em_diphone) (male1) (Parameter.set 'Language 'polish) ) następnie w tym samym pliku, w sekcji select_language dodaj: ((equal? language 'polish) (language_polish)) Nie zapomnij o zmianie uprawnień: sudo chmod -R 755 /usr/share/festival/voices/polish/ Aby sprawdzić czy wszystko zostało zainstalowane poprawnie wykonaj następujący test: echo "test" | festival --tts --language polish 6. Uwagi odnośnie użytkowania Z polskich znaków możesz korzystać za pomocą transkrypcji... ą = o~ ć = c~ ę = e~ ł = l/ ń = n~ ó = u ś = s~ ź = z~ ż = z* …lub z kodowania ISO-8859-2. Jeśli Twój terminal pracuje w UTF-8, możesz wykorzystać program iconv: echo "działa" | iconv -f UTF-8 -t ISO_8859-2 | festival --tts --language polish 7. Program czytający RSS dla robota społecznego Prosty skrypt BASH'a pozwala na pobranie wiadomośći z wybranego kanału RSS. Twój robot może więc sprawdzić dla Ciebie prognoznę pogody, przeczytać wiadomości ze świata itp... W sieci znalazłem pewien skrypt pobierający kilka najświeższych wiadomości: http://snippets.dzone.com/posts/show/1900 . Poniżej prezentuję wersję zmienioną. Rozszerzyłem go o usuwanie znaczników HTML (w RSS dopuszczalne są linki i grafika) oraz pewnych znaków, by festival lepiej radził sobie z czytaniem. Skrypt korzysta z programów curl i sed. #!/bin/sh # Copyright (c) 2005 Davor Babic <davorb@gmail.com> # All rights reserved. # Usage of the works is permitted provided that this # instrument is retained with the works, so that any # entity that uses the works is notified of this # instrument. # DISCLAIMER: THE WORKS ARE WITHOUT WARRANTY. url="http://wiadomosci.wp.pl/ver,rss,rss.xml" echo "Parsing RSS..." curl --silent "$url" | grep -E '(title>|description>)' | \ sed -n '4,$p' | \ sed -e 's/<title>//' -e 's/<\/title>//' -e 's/<description>/ /' \ -e 's/<\/description>//' | head -5 > digg echo "Reading..." sed -e 's/ &lt.*>//g' digg > digg2 sed -e 's/[\(\)&:;\_-]/ /g' digg2 > digg sed -e 's/[,\.]/\ /g' digg > digg2 sed -e 's/quot/ /g' digg2 > digg cat digg | festival --tts --language polish rm -rf ./digg rm -rf ./digg2 echo "Done." Uwaga: Wirtualna Polska koduje polskie znaki w ISO-8859-2. W innych przypadkach być może będziesz musiał skorzystać jeszcze z programu iconv. W załączniku umieściłem przykładowe wiadomości pobrane i odczytane przez skrypt. proba.mp3 test.mp3 cstr_pl_em_diphone.tar.gz

Zdalne sterowanie z komputera Streszczenie Artykuł prezentuje prosty sposób na zdalne sterowanie zabawkowego auta z komputera (za pośrednictwem klawiatury, lub przez internet). Ów sposób nie wymaga wiedzy z zakresu elektroniki. Przydatne mogą być podstawowe wiadomości na temat programowania w Delphi (Pascal). Zabawka zdalnie sterowana z komputera to prosty sposób na zabawę z dzieckiem lub zaimponowanie kolegom. 1. Wstęp Jeśli myślałeś kiedyś o zrobieniu zdalnego sterowania do platformy mobilnej Twojego robota, być może zainteresuje Cię ten zaskakująco prosty sposób, polegający na wykorzystaniu zabawkowego auta. Oto spis rzeczy jakie potrzebowałem do realizacji zadania: ➡️ zdalnie sterowany samochód, ➡️ lutownica, ➡️ moduł wyjścia/wejścia cyfrowego sterowany przez USB firmy ARCO, ➡️ Borland Delphi IDE (darmowa wersja). Oczywiście w prezentowany sposób możesz sterować inną zabawką, a zamiast kupować wspomniany moduł wejścia/wyjścia sam możesz wykonać płytkę z przekaźnikami lub transoptorami. Cel projektu przedstawiają poniższe filmy... Kiedy będziesz już w stanie sterować swoim robotem z komputera, będziesz mógł pisać skrypty do automatycznego kierowania albo sterować nim przez internet (!). 2. Zobacz jak działa nadajnik Jeśli rozbierałeś kiedyś nadajnik radiowy do sterowania zabawki, na pewno zauważyłeś w jaki sposób on działa. Dźwignie które znajdują się się na panelu sterowania działają jak przyciski, które zwierają jakieś ścieżki na płytce z elektroniką. Kiedy ścieżki te są zwarte, układ generuje określone fale radiowe, które otrzymuje odbiornik w zabawce. Zauważ, że ścieżki zawsze zwierane są do tzw. masy układu. Rysunek 1. Nadajnik. Na powyższym zdjęciu widać przykładowy nadajnik. Sprawdź które przyciski odpowiadają za jaką akcję Twojej zabawki. Teraz kiedy już wiesz jak to działa, pomyśl jak wykorzystać tę wiedzę do sterowania z komputera. Otóż potrzebujesz jakiegoś narzędzia, które pozwoli Ci zwierać przyciski nadajnika, za pośrednictwem komputera. Możesz sam wykonać takie urządzenie za dosłownie parę złotych. Ja opiszę jednak jak można wykorzystać dostępny na Allegro moduł wyjścia/wejścia cyfrowego sterowany przez USB. 3. Moduł wyjścia/wejścia cyfrowego Poniższe zdjęcia przedstawiają wspomniany moduł. Rysunek 2. Moduł: front. Rysunek 3. Moduł: back. Koszt takiego urządzenia to kilkadziesiąt złotych. Powody dla których warto skorzystać z tego rozwiązania, to: ➡️ solidne wykonanie, ➡️ urządzenie proste w programowaniu, ➡️ gotowy program w załączniku, ➡️ oszczędność czasu. Moduł komunikuje się z komputerem za pośrednictwem USB. Znajdują się na nim cztery wejścia i cztery wyjścia. Nas obecnie interesować będą wyłącznie wyjścia. Jeśli będziesz chciał rozbudować swoją platformę mobilną o jakieś czujniki, być może te wejścia będą dla Ciebie w przyszłości użyteczne. Czarne „bloczki” na płytce to tzw. przekaźniki. Ich działanie jest bardzo proste, możesz o nim przeczytać np. tutaj http://pl.wikipedia.org/wiki/Przeka%C5%BAnik . Nas interesuje tylko to, że będą one zwierać przyciski nadajnika. W związku z powyższym musisz wyprowadzić przewody z nadajnika. Przylutuj je na płytce w miejscu gdzie działają przyciski. Rysunek 4. Nadajnik. Rysunek 5. Nadajnik. Rysunek 6. Nadajnik. Pamiętaj, że przyciski te zwierają zawsze do masy. Ponieważ „masa jest jedna” wystarczy wyprowadzić tylko jeden jej kabelek, a moduł połączyć tak, by zwierał zawsze do tego jednego kabelka. Rysunek 7. Masa. 4. Programowanie Programowanie modułu w Delphi jest bardzo łatwe. Otwórz załączony na płycie CD przykładowy program, a zobaczysz jak należy używać wyjść tego urządzenia. W załączniku umieściłem również przykładowy program do sterowania autkiem. Rysunek 8. Program do zdalnego sterowania. Pozwala on na sterowanie myszką, klawiaturą (przyciski w, s, a, d) oraz za pomocą skryptu. Jak korzystać z takich skryptów wyjaśnia kod źródłowy programu. procedure TForm1.wykonywanie; var pomin: string; begin while eof(plik)<>True do begin opcja:='/'; while opcja='/' do begin read(plik,opcja); if opcja='/' then readln(plik,pomin); end; readln(plik,parametr); case ord(opcja) of 110: begin if parametr=1 then wla_n else wyl_n; end; 119: begin if parametr=1 then wla_w else wyl_w; end; 101: begin if parametr=1 then wla_e else wyl_e; end; 115: begin if parametr=1 then wla_s else wyl_s; end; 111: begin opoznienie; end; end; if stop.Enabled=False then Break; end; end; W załączniku umieściłem również sterowniki pod Linux'a, oraz przykładowe kody w języku C. 5. Zdalne sterowanie przez internet Jeśli Twój robot jest już sterowany z komputera możesz spróbować sterować nim przez internet. Możesz użyć do tego programu RealVNC, który udostępnia zdalny pulpit w sieci. Na komputerze, do którego podłączony jest nadajnik zainstalowano serwer VNC. Obsługiwać własny pulpit możesz z dowolnego miejsca na Ziemi, za pomocą klienta VNC lub przez przeglądarkę (program RealVNC udostępnia klienta w JAVIE przez http). Więcej na temat tego oprogramowania znajdziesz tutaj: http://www.realvnc.com/ . Jeśli Twoja sieć domowa wykorzystuje router być może zainteresuje Cię ten artykuł http://www.realvnc.com/support/portforward.html . Powodzenia! autko.rar libftdi-0.10.tar.gz

Pierwsze kroki w Player/Stage Streszczenie Artykuł omawia instalację i działanie popularnego systemu wielorobotowego Player i spokrewnionego z nim symulatora Stage. 1. Wstęp Po opublikowaniu na stronach Diody raportu dotyczącego robota wykorzystującego serwer Player poproszono mnie dokładniejsze wyjaśnienie w jaki sposób działa to narzędzie. Ponieważ oprogramowanie to jest wciąż w początkowej fazie rozwoju, jego instalacja i użytkowanie może przysporzyć licznych kłopotów i wręcz odstraszać. Wierzę jednak iż po przeczytaniu artykułu Czytelnik dostrzeże ogromne możliwość, które stwarza korzystanie z pakietu. 2. Player Player jest serwerem sprzętu robotycznego. Po co w robocie serwer? Odpowiedź jest prosta: do komunikacji czujników i elementów wykonawczych w prosty i jednolity sposób, z oprogramowaniem. Zauważ, że wśród czujników, z których korzystają Twoje roboty, można dokonać podziału według informacji, którą dostarczają. Tak np. enkodery, optyczny czujnik przemieszczenia (z myszki), akcelerometry, GPS, to urządzenia, które służą do określenia pozycji robota. Podobnie dalmierz IR, oraz sonar ultradźwiękowy służą do określenia odległości od przeszkody. Twórcy Player'a zauważyli, że po dokonaniu takiego podziału można oddzielić warstwę obsługi sprzętowej od warstwy zadaniowej. Np. jeśli chcesz aby twój robot zatrzymał się w odległości 0,1 m od przeszkody, to pisząc program skorzystasz ze standardowego interfejsu IR, nie martwiąc się o to jaki w robocie zastosowano dalmierz. Interfejs IR zwróci odległość od przeszkody, a nie napięcie na przetworniku czy czas trwania impulsu... Takie rozwiązanie pozwala na pisanie przenośnych programów. Jeśli ktoś napisał program do robota tworzącego mapy otoczenia wykorzystującego (reuquires) interfejs IR oraz interfejs position2d, możesz z powodzeniem wykorzystać go w swoim robocie, jeśli tylko udostępnisz te interfejsy. Nie musisz zastosować dokładnie tych samych czujników. Wystarczy, że będziesz przestrzegał standardów Player'a. Aby dokonać komunikacji pomiędzy Player'em a czujnikiem (lub urządzeniem), musisz skorzystać z driver'a. Jest to biblioteka, która odpowiada za obsługę sprzętową, np. odczyta z przetwornika napięcie i obliczy odpowiadającą mu odległość. Każdy driver udostępnia (provides) określone interfejsy. Player udostępnia je w postaci gniazdek TCP, z których korzystają Twoje programy klienckie (np. program do tworzenia mapy otoczenia). Ogromną zaletą Player'a jest duża liczba darmowych driver'ów. Ich kompletną listę znajdziesz tutaj: http://playerstage.sourceforge.net/doc/Player-2.1.0/player/group__drivers.html . Zauważ, że wśród driverów są nie tylko takie, które realizują komunikację z urządzeniem, ale i takie które pozwalają na wykorzystanie gotowych algorytmów sterowania (np. VFH), albo komunikację z zewnętrznymi programami (np. program do rozpoznawania mowy). 3. Stage i Gazebo Teraz wyobraź sobie, że masz robota i driver który udostępnia określone interfejsy. Zauważ, że Player komunikuje się urządzeniami za pomocą driver'a. Taki driver można więc zastąpić symulatorem rzeczywistości. Przykładem takiego symulatora jest Stage. Istnieje jeszcze jeden symulator do Playera, Gazebo, który pozwala na symulację trójwymiarowego świata, w odróżnieniu od Stage'a, który działa w dwóch wymiarach. Stage pozwala na symulację wielu robotów. Masz możliwość edycji map otoczenia i wyboru czujników, które Cię interesują. 4. Instalacja Poniżej zamieszczam sposób instalacji Player'a i Stage'a na Xubuntu 9.04. Metoda instalacji pod Windows znajduje się tutaj: http://sourceforge.net/mailarchive/message.php?msg_name=497E8426.6070202%40killbots.net . Uruchom Menedżer Pakietów Synaptic i odnajdź następujące pakiety: ➡️ robot-player ➡️ stage oraz zezwól Synaptic'owi, aby uzupełnił zależności. Pobierz i zainstaluj pakiety. Wykonaj polecenie w terminalu: robot-player /usr/share/stage/worlds/simple.cfg Jeśli występuje następujący problem... * Part of the Player/Stage/Gazebo Project [http://playerstage.sourceforge.net]. * Copyright (C) 2000 - 2006 Brian Gerkey, Richard Vaughan, Andrew Howard, * Nate Koenig, and contributors. Released under the GNU General Public License. * Player comes with ABSOLUTELY NO WARRANTY. This is free software, and you * are welcome to redistribute it under certain conditions; see COPYING * for details. trying to load /usr/share/stage/worlds/libstageplugin... trying to load /usr/lib/libstageplugin... success invoking player_driver_init()... Stage driver plugin init ** Stage plugin v2.0.3 ** * Part of the Player/Stage Project [http://playerstage.sourceforge.net] * Copyright 2000-2006 Richard Vaughan, Andrew Howard, Brian Gerkey * and contributors. Released under the GNU General Public License v2. success Stage driver creating 1 device 6665.31.0 is a Stage world [Loading /usr/share/stage/worlds/simple.world][Include pioneer.inc][Include map.inc][Include sick.inc] err: unable to open color database /usr/X11R6/lib/X11/rgb.txt : No such file or directory (stage.c stg_lookup_color) Segmentation fault … utwórz następujące katalogi... sudo mkdir /usr/X11R6/lib sudo mkdir /usr/X11R6/lib/X11 i wgraj tam plik RGB. Ja korzystam z pliku od Scilab'a... sudo cp /usr/share/scilab/modules/tclsci/demos/tk/rgb.txt /usr/X11R6/lib/X11/rgb.txt ...ale jeśli nie korzystasz z Scilaba'a możesz spróbować użyć innego pliku. Znajdziesz je wpisując po prostu: find / -name rgb.txt Jeśli Player nie uruchamia okna symulacji, spróbuj użyć innego pliku RGB. Ostatecznie możesz utworzyć pusty, plik, ale będziesz miał wtedy problemy z kolorami. Pamiętaj jeszcze o uprawnieniach... sudo chmod 755 /usr/X11R6/lib/X11/rgb.txt 5. Pierwsze uruchomienie Wpisz w terminalu... robot-player /usr/share/stage/worlds/simple.cfg …a da to następujący rezultat: * Part of the Player/Stage/Gazebo Project [http://playerstage.sourceforge.net]. * Copyright (C) 2000 - 2006 Brian Gerkey, Richard Vaughan, Andrew Howard, * Nate Koenig, and contributors. Released under the GNU General Public License. * Player comes with ABSOLUTELY NO WARRANTY. This is free software, and you * are welcome to redistribute it under certain conditions; see COPYING * for details. trying to load /usr/share/stage/worlds/libstageplugin... trying to load /usr/lib/libstageplugin... success invoking player_driver_init()... Stage driver plugin init ** Stage plugin v2.0.3 ** * Part of the Player/Stage Project [http://playerstage.sourceforge.net] * Copyright 2000-2006 Richard Vaughan, Andrew Howard, Brian Gerkey * and contributors. Released under the GNU General Public License v2. success Stage driver creating 1 device 6665.31.0 is a Stage world [Loading /usr/share/stage/worlds/simple.world][Include pioneer.inc][Include map.inc][Include sick.inc] Stage driver creating 1 device 6665.42.0 is "cave" Stage driver creating 2 devices 6665.4.0 is "robot1" 6665.6.0 is "robot1.laser:0" Listening on ports: 6665 Zauważ, co spowodowało wykonanie tego polecenia. Wpierw wystartował serwer Playera. Następnie rozpoczyna się inicjalizacja plugin'u Stage. Powinno również pokazać się okno, widoczne na poniższym screen'ie. Jest to twój symulowany świat; pamiętaj, że zamiast niego możesz korzystać z prawdziwego robota. Rysunek 1. Stage. Zwróć jeszcze uwagę, na ostatnią linię: Listening on ports: 6665 Oznacza ona, że serwer oczekuje na podłączenie się programów klienckich; port 6665 (localhost). Wypróbuj załączony do pakietu program laserobstacleavoid. Spowoduje on przypadkowe poruszanie się robota po mapie, bez uderzania w przeszkody. Wpisz: /usr/share/player/examples/libplayerc++/laserobstacleavoid Wynik: Rysunek 2. laserobstaclevoid. Kolejnym przykładem programu klienckiego jest np. robot-playerv. Wpisz po prostu: robot-playerv Ten program pozwoli Ci np. na „ręczne” sterowanie robotem, korzystanie z algorytmu VFH czy odczyt prędkości. Rysunek 3. robot-playerv. 6. Pliki konfiguracyjne Zwróć uwagę w jaki sposób uruchamiałeś serwer: robot-player /usr/share/stage/worlds/simple.cfg /usr/share/stage/worlds/simple.cfg jest tzw. plikiem konfiguracyjnym serwera. Poniższy listing przedstawia jego zawartość. # Desc: Player sample configuration file for controlling Stage devices # Author: Richard Vaughan # Date: 1 December 2004 # CVS: $Id: simple.cfg,v 1.30.2.1 2006/07/13 17:59:10 gerkey Exp $ # load the Stage plugin simulation driver driver ( name "stage" provides ["simulation:0" ] plugin "libstageplugin" # load the named file into the simulator worldfile "simple.world" ) driver ( name "stage" provides ["map:0"] model "cave" ) # Create a Stage driver and attach position2d and laser interfaces # to the model "robot1" driver ( name "stage" provides ["position2d:0" "laser:0" ] model "robot1" ) # Demonstrates use of a Player "abstract driver": one that doesn't # interface directly with hardware, but only with other Player devices. # The VFH driver attempts to drive to commanded positions without # bumping into obstacles. driver ( name "vfh" provides ["position2d:1"] requires ["position2d:0" "laser:0" ] ) Jak widzisz plik ten definiuje, jakie driver'y ma załadować serwer. Ponadto każdy driver jest konfigurowany. Określasz jakie protokoły ma udostępniać (provides) i/lub jakie protokoły ma wykorzystać (requires). Liczba po dwukropku oznacza liczbę porządkową; dzięki temu możesz używać wielu czujników w różnych celach i używać wielu robotów. Więcej na temat pisania plików konfiguracyjnych znajdziesz na stronie http://playerstage.sourceforge.net/doc/Player-2.1.0/player/group__tutorial__config.html . 7. Własne programy klienckie Pisanie własnych programów klienckich jest bez wątpienia najciekawszym zadaniem. Dzięki symulacjom możesz szybko i łatwo prototypować własne algorytmy i sterowniki. Wybór języka jest dość szeroki, dzięki darmowym bibliotekom: ➡️ libplayerc © ➡️ playerclient (C++) ➡️ guileplayer (Scheme) ➡️ playerc_py lub pyro (Python) ➡️ Player Client For Common Lisp (Common Lisp) ➡️ Ruby Player (Ruby) ➡️ Javaclient (Java) ➡️ octplayer (Octave) przy czym z biblioteki libplayerc możesz korzystać pisząc programy w C++. Obiła mi się o uszy możliwość pisania programów klienckich w języku ADA (!), czyli tym, z którego powszechnie korzysta się w statkach kosmicznych. Jak korzystać z bibliotek i pisać własne programy kliencki dowiesz się z poniższych linków. ➡️C http://playerstage.sourceforge.net/doc/Player-1.6.5/player-html/group__player__clientlib__libplayerc.php ➡️C++ http://psurobotics.org/wiki/index.php?title=Player/Stage_Overview http://playerstage.sourceforge.net/doc/Player-1.6.5/player-html/group__player__clientlib__cplusplus.php ➡️Java http://java-player.sourceforge.net/docs/howto.pdf ➡️Python http://playerstage.sourceforge.net/doc/Player-1.6.5/player-html/group__player__clientlib__libplayerc__py.php 8. Własny driver Jeśli chcesz wykorzystać serwer Player'a na własnym robocie, musisz napisać driver. Nie jest to trudne, zwłaszcza, że w sieci znaleźć można wiele przykładowych driver'ów. Na temat struktury driver'ów i ich pisania znajdziesz informacje pod poniższymi adresami. ➡️http://psurobotics.org/wiki/index.php?title=Player/Stage_Drivers ➡️http://psurobotics.org/wiki/index.php?title=Writing_a_Player_Plugin ➡️http://image.diku.dk/mediawiki/images/e/e2/Driverhowtodoc_HandedIn.pdf Przykładowe driver'y znajdziesz tutaj: ➡️http://svn.psurobotics.org/view/bin/cgi/viewvc.cgi/ ➡️http://segomo.elka.pw.edu.pl/websvn/listing.php?repname=Player+repository&path=%2Fprotonekdriver%2Fdriver-2.1.1%2F&rev=65 ➡️http://playerstage.sourceforge.net/doc/Player-2.1.0/player/classKhepera.html ➡️https://www.forbot.pl/forum/topics20/driver-do-player-stage-na-mini-komputerze-vt2192.htm?sid=1854aa68909f2062b53c8a7b627e4436 powodzenia! rgb.txt

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

Koło Naukowe Robotyków KoNaR projekt "Yokozuna" Prezentacja kompletnego kodu programu prostego robota minisumo Streszczenie Artykuł prezentuje przykład prostego programu działającego robota. Proponuje gotowe rozwiązania dla początkujących konstruktorów, kładąc nacisk na realizację strategii i celowo pomijając sferę szczegółów technicznych, związanych programowaniem mikrokontrolerów. Czytając tekst zaleca się wgląd do załączonych plików z kodem źródłowym. 1. Wstęp Prezentowany program dedykowano robotowi wyposażonemu w mikrokontroler ATmega16 firmy Atmel. Bez wprowadzania większych zmian łatwo przenieść go na inny, podobny układ firmy Atmel (ATmega32, ATmega8 etc.). O wiele większym problemem stojącym przed Czytelnikiem jest implementacja zaprogramowanego, w prezentowany sposób mikrokontrolera, w układzie elektronicznym, sterującym robotem. Realizacja takiego układu może wymagać, gruntownych zmian kodu źródłowego, jeśli peryferia są dla Czytelnika niedostępne, bądź zdecydowano zbudować robota z innych elementów. Omawiany program napisany został dla robota wykorzystującego następujące urządzenia: dwa dalmierze Sharp GP2Y0A21, cztery czujniki koloru firmy ARE, silniki sterowane przez układ L298. Szczegóły w znaleźć można w [1]. 2. Struktura programu Kod omawianego programu podzielony został na następujące pliki: ➡️ yokozuna_adc.c ➡️ yokozuna_fight.c ➡️ yokozuna_main.c ➡️ yokozuna_motors.c ➡️ yokozuna_other.c ➡️ yokozuna_uart.c Zostaną one omówione w kolejnych rozdziałach artykułu. Wszystkim wyżej wymienionym plikom, odpowiadają pliki nagłówkowe, które w celu zachowania komplementarności rozważań załączono na końcu dokumentu. Na szczególną uwagę zasługuje jednak niewspomniany dotąd plik yokozuna_defs.h, który powinien wyjaśnić jak mikrokontroler został zaimplementowany w układzie. Ponadto, jego modyfikacja w łatwy sposób dostosuje program do potrzeb Czytelnika. Znaczenie zmiennych globalnych i definicji omówione zostanie w dalszej części dokumentu. 3. yokozuna_main.c Ten plik prezentuje całą strategię prowadzonej przez robota walki. W pozostałych plikach znajdują się tylko funkcje realizujące konkretne zadania. Zadania te można podzielić na takie, które dotyczą sfery sprzętowej (np. konfiguracja liczników, przetwornika ADC, etc.), oraz takie które dotyczą technik obrony, ataku i lokalizacji przeciwnika. Program główny przedstawia poniższy diagram. Rysunek 1. int main(void). Można zauważyć iż w programie głównym nie występuje interakcja robota z otoczeniem (pomijając oczekiwanie na sygnał startu). W nieskończonej pętli program ustawia silniki na jazdę do przodu. W istocie, odczytywanie danych z czujników, ich analiza, lokalizowanie przeciwnika i ucieczka w przypadku zagrożenia, zrealizowane zostały w przerwaniu od przepełnienia licznika T1 (Rysunek 2). Rysunek 2. Przerwanie od przepełnienia licznika T1. Dzięki takiemu rozwiązaniu, kiedy robot nie jest w niebezpieczeństwie (tzn. nie najechał na białą linię) i widzi przed sobą przeciwnika, przerwanie kończy się bardzo szybko, a w programie głównym silniki zostają ustawione na jazdę do przodu i trwa to do następnego przerwania. Sytuacja zmienia się gdy robot najedzie na białą linię lub traci kontakt z przeciwnikiem. Wówczas w przerwaniu uruchomiona zostaje funkcja odpowiedzialna za obronę (ucieczkę) i/lub odnalezienie przeciwnika. Zadanie wspomniane w poprzednim akapicie zrealizowano za pomocą zmiennych globalnych: danger i contact, które ustawione zostają w efekcie działania funkcji check_white_line() i check_contact(), poprzedzonych przez odczytanie wartości z przetwornika, w wyniku działania funkcji check_adc(). 4. yokozuna_adc.c Plik yokozuna_adc.c zawiera funkcje obsługujące przetwornik ADC. Funkcja init_adc() służy konfiguracji przetwornika. Funkcja check_adc() zmienia wartości zmiennych globalnych oznaczonych w pliku yokozuna_defs.h dopiskiem w komentarzu "from ADC". Ponadto funkcja umożliwia wysłanie wartości tych zmiennych przez port szeregowy do komputera połączonego z robotem, w celu weryfikacji poprawności działania czujników. Procedury komunikacji (w prezentowanym kodzie) objęto jednak komentarzem, gdyż podczas normalnej pracy robota nie ma potrzeby wysyłania tych informacji. Funkcje realizujące komunikację z komputerem znajdują się w pliku yokozuna_uart.c. Szczególnego komentarza wymagać może działanie odejmowania, przy odczytywaniu napięć z czujnika koloru. Jest to realizacja tzw. pomiaru różnicowego, którego opis znaleźć można w dokumentacji czujnika [5]. 5. yokozuna_fight.c Po odczytaniu wartości z przetwornika ADC następuje ich analiza i ewentualne podjęcie koniecznych działań, o czym była mowa w punkcie 3. Analiza danych i wspomniane działania realizuje kod zawarty w pliku yokozuna_fight.c. Funkcja check_white_line() na podstawie zmienny globalnych kol_fl, kol_fr, kol_bl, kol_br (wartości z przetwornika odpowiadające napięciom na wyjściu czujników koloru) wpływa na zmienną globalną danger (danger wynosi 1 wtedy i tylko wtedy gdy robot najechał na białą linię). Analogicznie działa funkcja check_contact(), która na podstawie wartości sharp_l, sharp_r wpływa na zmienną globalną contact (contact wynosi 1 wtedy i tylko wtedy, gdy przeciwnik znajduje się naprzeciwko robota w bliskiej odległości). Kiedy w przerwaniu od przepełnienia licznika T1 (patrz punkt 3) po analizie wartości z przetwornika, rozpoznano niebezpieczeństwo (biała linia) bądź stracono kontakt z przeciwnikiem, uruchomione zostają odpowiednie procedury, escape() lub hunt(). Szczególnego komentarza wymagać może zastosowanie stałych WL_CONST oraz SHARP_CONST w funkcjach analizujących dane z przetwornika. Są to wartości liczbowe, zdefiniowane w pliku yokozuna_defs.h, oraz dobrane eksperymentalnie. Ich wykorzystanie jest proste, np. gdy wartość zmiennej globalnej odpowiadającej tylnemu lewemu czujnikowi koloru przekroczy dopuszczalną wartość (kol_br > WL_CONST), oznacza to, że czujnik ten znajduje się nad białą linią. 6. yokozuna_motors.c W pliku yokozuna_motors.c zawarto funkcje do obsługi silników. Szczegóły znaleźć można w [6]. 7. yokozuna_uart.c Plik zawiera funkcje do obsługi komunikacji robota z komputerem, przydatne podczas testowania programu. Szczegóły znaleźć można w [2] i [3]. 8. yokozuna_other.c W pliku umieszczono funkcje odpowiedzialne głównie za konfigurację mikrokontrolera (wyodrębnienie pliku zwiększa czytelności kodu). 9. Pozostałe pliki nagłówkowe Do kompilacji niezbędnę są poniższe pliki nagłówkowe (w załączniku): ➡️ yokozuna_adc.h ➡️ yokozuna_fight.h ➡️ yokozuna_motors.h ➡️ yokozuna_other.h ➡️ yokozuna_uart.h 10. Kompilacja (Linux) Przykład kompilacji: #!/bin/bash avr-gcc -mmcu=atmega16 -Os -c yokozuna_adc.c -o adc.o avr-gcc -mmcu=atmega16 -Os -c yokozuna_fight.c -o fight.o avr-gcc -mmcu=atmega16 -Os -c yokozuna_uart.c -o uart.o avr-gcc -mmcu=atmega16 -Os -c yokozuna_other.c -o other.o avr-gcc -mmcu=atmega16 -Os -c yokozuna_motors.c -o motors.o avr-gcc -mmcu=atmega16 -Os -c yokozuna_main.c -o main.o avr-gcc adc.o fight.o uart.o other.o motors.o main.o -mmcu=atmega16 -o prog.out avr-objcopy -R .eeprom -O ihex prog.out prog.hex Bibliografia [1] Szymon Gospodarek, Robot klasy Mini-Sumo "Yokozuna", KoNaR, Wrocław 2009. [2] Wydział Eletroniki, Telekomunikacji i Informatyki Politechniki Gdańskiej, Dokumentacja mikrokontrolera ATmega16 firmy Atmel, Gdańsk 2006. [3] ATmega16 (dokumentacja), ATMEL, 2006. [4] GP2Y0A21 (dokumentacja), SHARP Corporation, 2006. [5] Czujnik koloru ARE0015 (dokumentacja), ARE. [6] L298 Dual full-bridge driver (dokumentacja), ST, 2000. yokozuna.rar