====== 1. Wstęp ======

Celem tego ćwiczenia jest sprawdzenie możliwości interfejsu programistycznego PLNXT przy prostych algorytmach. Do dyspozycji mieliśmy komputer, moduł komunikacji Bluetooth oraz już złożonego robota "Agatkę". Niestety, muszę w tym miejscu nadmienić, iż ćwiczenie nie zostało wykonane w normalny, podany w instrukcji sposób, z uwagi na patologiczne zachowanie robota, które zostanie omówione w szczegółach w dalszej części tego sprawozdania.

====== 2. Opis problemów z połączeniem ======

Pierwszym problemem napotkanym podczas wykonywania ćwiczenia było nawiązanie poprawnej łączności z robotem. Co ciekawe, na początku nie mieliśmy do dyspozycji modułu BT na USB, zwanego potocznie "dzyndzlem", co rodzi wątpliwości, czy ktoś na wcześniejszych zajęciach w ogóle bawił się tym robotem. Po otrzymaniu modułu i podłączeniu go do komputera, robot jest teoretycznie wykrywany, jednak nie reaguje na polecenia z konsoli Prologa, tak samo nie pojawiają się odpowiedzi typu "Yes"/"No". Wielokrotne próby parowania robota oraz wykonanie plnxt_stty daje taki sam rezultat, ewentualnie próba wydania jakiegokolwiek polecenia daje komunikat o braku połączenia. Nie pomagało też usuwanie kontaktów z bricka ani jego restartowanie. Dopiero reset całego systemu operacyjnego na komputerze przyniósł oczekiwany efekt. Na tym jednak problemy się nie skończyły.

====== 3. Problemy po uzyskaniu połączenia ======

Tak naprawdę ciekawe rzeczy zaczęły się dziać po nawiązaniu połączenia. Przekonaliśmy się o tym, gdy chcieliśmy przetestować jeden z podanych na wiki przykładów:

<code prolog>:- consult('plnxt.pl').
 
start :-
	nxt_open,
	rectangle_loop.
 
rectangle_loop :-
	nxt_go_cm(350,40),
	nxt_rotate(350,90),
	rectangle_loop.</code>

Przykład ten, jak widać, realizuje ruch po kwadracie o boku 40cm, z szybkościami ruchu i obrotu równymi 350 cm/s i stopni/s, czyli dość szybki. Po skompilowaniu i wywołaniu polecenia start robot zareagował. Reakcja jednak należała do niespodziewanych, albowiem robot zaczął poruszać się do przodu i nie zatrzymywał, dopóki silniki nie zostaną zatrzymane przez jeden z poniższych warunków/stanów:

  * Wydanie polecenia nxt_stop,
  * Wyłączenie bricka,
  * Rozładowanie akumulatorów robota.

Zadziwieni rezultatem postanowiliśmy przetestować przykład z wykorzystaniem wątków:

<code prolog>:- consult('plnxt.pl').
 
start :-
	nxt_open,
	thread_create(rectangle_loop,_,[detached(true)]).
 
rectangle_loop :-
	nxt_go_cm(350,40),
	nxt_rotate(350,90),
	rectangle_loop.
 
stop :-
	trigger_killall,
	nxt_stop,
	nxt_close.
</code>

Działanie tego algorytmu okazało się jeszcze bardziej zastanawiające. Mianowicie po wpisaniu start, robot, podobnie, jak wcześniej, poruszał się na nieokreślony dystans do przodu. Co jednak ciekawe, wpisanie teraz nxt_stop nie zatrzymało robota, ale spowodowało przejście do następnej akcji w rectangle_loop! Czyli robot, jeżeli przed wpisaniem poruszał się do przodu, po wpisaniu zaczął się obracać wkoło bez końca i vice versa. Zabicie wątków poleceniem stop natomiast działało normalnie.

Zdziwieni takim stanem rzeczy i nakłonieni przez prowadzącego, postanowiliśmy przeanalizować odpowiedzi robota na podstawowe polecenia. Zauważyliśmy, iż część z nich wykonuje się z dość dużym opóźnieniem, od 5 do 10 sekund. Ogółem jednak polecenia związane z odczytem wartości czujników działały poprawnie, tak, jak np. włączenie podświetlenia sensoru światła. Do problematycznych należały nxt_go_cm oraz nxt_rotate. Jak napisano wcześniej, ich wykonanie kończyło się niekończącym się ruchem bądź obrotem robota. Zachowanie nie zależało od parametru określającego odległość czy kąt - przetestowano zarówno bardzo małe, jak i większe wartości i za każdym razem ruch robota musiał być sztucznie przerywany. Reakcja na parametr określający szybkość ruchu była poprawna - przy mniejszych wartościach robot istotnie jechał i obracał się wyraźnie wolniej, jednak tak czy inaczej w sposób nieprzerwany.

W ten sposób wykonanie zadań stało się efektywnie znacznie utrudnione - było w zasadzie konieczne ręczne sterowanie. Postanowiliśmy też sprawdzić wyposażenie robota. Wykorzystaliśmy więc programy Try Me zawarte w Bricku. Tu w zasadzie nie napotkaliśmy się na większe problemy z jednym wyjątkiem. Czujnik dźwięku zdawał się być źle wykalibrowany i reagował wyraźnym ruchem już na ciche rozmowy kolegów siedzących ok. 3 metry obok. Przy skierowaniu polecenia wprost do robota następował gwałtowny zryw kończący się na przebyciu przez robota ok. 0,5 metra. Dość zastanawiające zachowanie zostało uwiecznione na filmiku nagranym przez jednego z członków grupy.

====== 4. Wnioski ======

Jak wspomniano wcześniej, laboratorium nie mogło zostać ukończone w normalny sposób. Jest to tym bardziej zastanawiające, że inne grupy pracujące z tym robotem wykonały zadania w sposób normalny. Ciężko wskazać potencjalne przyczyny takiego zachowania robota, jakie zauważyliśmy. Wygląda na to jednak, że później wszystko wróciło do normy.

====== 5. Materiały ======

[[http://example.com|Film przedstawiający reakcję robota na dźwięki z sali [Do przesłania przez M. Besta] ]]

[[http://example.com|Zdjęcia z lab [Do przesłania przez M. Besta] ]]

Brak materiałów.  --- //[[wojnicki@agh.edu.pl|Igor Wojnicki]] 2009/05/20 12:42//