Celem laboratorium jest wykorzystanie interfejsu PLNXT do napisania zaawansowanych algorytmów sterowania robotem Lego Mindstorms. Do dyspozycji mieliśmy złożonego już robota, moduł do komunikacji Bluetooth oraz oczywiście stanowisko komputerowe. Zweryfikowaliśmy łączność z komputerem, sprawdziliśmy, czy ustawienia komunikacji, w szczególności nr robota, są odpowiednie, co przebiegło bez większych komplikacji. W związku z tym przystąpiliśmy do pisania ćwiczenia.
Do realizacji wybraliśmy pierwsze z podanych zadań. Oto kod źródłowy owego programu:
:- consult('plnxt.pl'). start :- nxt_open, nxt_light_LED(activate), thread_create(go,_,[detached(true)]). go :- nxt_go(300), trigger_create(t1,check_light,turn_away), trigger_create(t2,check_ball,escape). check_light :- nxt_light(Light), Light < 56. turn_away :- nxt_stop,Angle is 90 + random(90),nxt_rotate(240,Angle),nxt_go(300). check_ball :- nxt_light(Light), Light > 60, Light < 66. nxt_play_tone(5000,1000),trigger_kill(t1),nxt_go_cm(300,500),nxt_play_tone(666,1000),stop. stop :- trigger_killall, nxt_stop, nxt_light_LED(passivate), nxt_close.
Jest to w zasadzie nic więcej niż zmodyfikowany szkielet dostępny przy opisie wcześniejszego ćwiczenia. Wykorzystuje on wątki, co ułatwia sterowanie robotem z poziomu konsoli.
Jak można się spodziewać, niemałym problemem przy tym zadaniu było dobranie empiryczne wartości progowych z czujnika światła. Naiwna metoda polega na ustawieniu robota w taki sposób, że sensor znajduje się bezpośrenio nad powierzchnią i odczytanie wartości poleceniem nxt_light(Value). Ponieważ zmienne oświetlenie pomieszczenia ma wpływ na wartości odczytów, zwłaszcza, że nasze stanowisko znajduje się przy oknie, przydatna jest kompensacja za pomocą diody LED zapalanej poleceniem nxt_light_LED(activate).
Powtarzane odczyty nad czarnym obrzeżem wskazywały na wartości w okolicach 50, +/- 5 w obie strony. Natomiast czerwony obszar, który służy za klucz, dawał wartości mniej więcej stałe i wynoszące około 64. Pomiary przeprowadzaliśmy kilkukrotnie po teście wcześniej obranych wartości. Zdarzało się bowiem, że przyjęte na początku progi nie sprawdzały się. Zbyt niski próg może spowodować, że linia/klucz w ogóle nie zostaną wykryte - i istotnie, tak się zdarzało wcześniej, szczególnie przy bardziej naświetlonej części planszy. Z kolei zbyt wysoki próg oznacza przedwczesną lub w ogóle błędną reakcję na obiekt, którego tak naprawdę nie ma - i taki problem stworzyły dwa czarne kwadraty u dołu planszy. W związku z tym konieczna była korekcja wprowadzonych wartości, tak, by uwzględniły pewien margines w obie strony, ale by nie był on też zbyt duży. Szczególnie, jak już wspomniano, tyczy się to krawędzi planszy, gdyż klucz dawał relatywnie stałe odczyty.
Inny problem to częściowe wyjeżdżanie robota poza planszę np. jednym kołem, gdy czujnik znajdował się nad linią. Przyczyna takiego stanu rzeczy jest raczej jasna i należy do wad konstrukcyjnych robota. By uniknąć takich patologii, sensor musi znajdować się po środku robota i najlepiej odpowiednio wysunięty do przodu, by uwzględniał także obrót robota. Przez 'odpowiednio' rozumiemy tu, że czujnik jest najdalej odsuniętym punktem od osi obrotu robota. W naszym przypadku sensor znajdował się on nieco po lewej stronie maszyny i odrobinę z przodu kół, co przy pewnych kątach oznacza właśnie takie wyjeżdżanie małą częścią robota poza planszę. Po przebudowie wspomniany problem nie ma racji bytu.
Można pomyśleć nad wersją, która nie wykonywałaby pełnego obrotu przy spotkaniu z czarnymi kwadratami na planszy. Podejście, jakie proponujemy, polega na zatrzymaniu się przy czarnym obszarze, podobnie, jak wcześniej. Tym razem jednak robot wykonuje coś a'la śledzenie krawędzi, czyli obraca się o 90 stopni, odjeżdża trochę, obraca się z powrotem o te 90 stopni i podjeżdża pod krawędź. Tym samym wykorzystujemy fakt, że te kwadraty mają stosunkowo krótkie boki. Alternatywnie można by obniżyć próg reakcji na światło, ale rodzi to ryzyko niewykrycia realnej krawędzi, jak już wcześniej wspomniano. Większym problemem byłoby więc całkowite zignorowanie tych kwadratów.
Sam interfejs jest relatywnie prostym w obsłudze narzędziem do programowania robota, o czym przekonaliśmy się już na wcześniejszych laboratoriach. Problemy zaczynają się w implementacji rozwiązań. Mają one dwojaką naturę:
Gdy jednak te problemy udaje się rozwiązać, praca z robotem staje się bardzo satysfakcjonująca.
