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.
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.
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:
:- consult('plnxt.pl'). start :- nxt_open, rectangle_loop. rectangle_loop :- nxt_go_cm(350,40), nxt_rotate(350,90), rectangle_loop.
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:
Zadziwieni rezultatem postanowiliśmy przetestować przykład z wykorzystaniem wątków:
:- 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.
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.
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.
Film przedstawiający reakcję robota na dźwięki z sali [Do przesłania przez M. Besta]
Zdjęcia z lab [Do przesłania przez M. Besta]
Brak materiałów. — Igor Wojnicki 2009/05/20 12:42
