AIwiki

1. Radosław Chmielarz
2. Łukasz Masłowski
3. Krzysztof Rączka

Celem algorytmu było takie pokierowanie robotem aby cały czas jeździł wewnątrz obszaru zaznaczonego czarną linią. Dodaliśmy do tego także warunek aby po klaśnięciu robot całkowicie się zatrzymał.

• Algorytm:

:- consult('plnxt.pl').
 
start :-
    nxt_open,
    nxt_light_LED(activate),
    trigger_create(_,clap,[nxt_light_LED(passivate),nxt_stop,nxt_close]),
    go.   
 
 
go :-
    nxt_go(200),
    trigger_create(_,check_for_line,turn_a_bit).
 
% Sprawdzenie, czy natężenie dźwięku przekracza progową wartość.
clap :-
    nxt_sound(Value,force),
    Value > 50.
 
turn_a_bit :-
    nxt_stop,
    Angle is 120 + random(120),
    nxt_rotate(200,Angle),
    go.
 
check_for_line :-
    nxt_light(Value,force),
    Value < 50.

• Problemy:
  • Środowisko SWI rzucało wyjątkiem przy próbie obsługi przerwania zatrzymującego robota:

Warning: [Thread 2] Thread running "trigger_start(check_distance, [nxt_stop, nxt_close], 1)" died on exception: source_sink `nxt_close' does not exist

Podejrzewamy że problem znajduje się w API które w jakiś sposób nie udostępnia reguły nxt_close.

• Robot nie zatrzymywał się nawet po „usłyszeniu” klaśnięcia jeśli nie obsłużył chociaż raz przerwania związanego z rozpoznaniem czarnej linii. Innymi słowy robot zatrzymywał się dopiero po ustaleniu wszystkich wartości. Wydaje nam się że ma to jakiś związek z mechanizmem rejestrowania obsługi przerwań. Wygląda na to że oba przerwania pracują na osobnych wątkach, co tłumaczyłoby dlaczego robot jechał dalej mimo wydania mu wyraźnej komendy stop po tym jak usłyszał klaśnięcie (drugi wątek był nadal zarejestrowany i program odpytywał go co jakiś czas, wydając mu tym samym polecenie nxt_go). Zagadką jest natomiast to dlaczego robot zatrzymywał się po tym jak zostało już raz obsłużone przerwanie związane z czarną linią. Podejrzewamy że wpłynęło na to jakoś użycie nxt_close, ale pewności nie ma.

• Algorytm:

:- consult('plnxt.pl').
 
start :-
    nxt_open,
    go.
 
go :-
    nxt_go(400),
    trigger_create(_,check_distance,turn_a_bit).
 
turn_a_bit :-
    nxt_stop,
    nxt_go_cm(-400,10,force),
    nxt_rotate(400,90),
    go.
 
check_distance :-
    nxt_ultrasonic(Distance,force),
    Distance < 15.

• Problemy:
  • Tak jak w poprzednim przykładzie środowiska rzuca wyjątkiem związanym z nxt_close:

Warning: [Thread 2] Thread running "trigger_start(check_distance, [nxt_stop, nxt_close], 1)" died on exception: source_sink `nxt_close' does not exist

• Precyzja w ustaleniu kąta obrotu zależy od prędkości z jaką porusza się robot. To samo tyczy się przejechanego dystansu. Winą obarczamy albo małą precyzję czujników robota przy ustalaniu ilości obrotów silników albo ustawionym „na sztywno” algorytmie obrotu, który jednak powinien być zależny od prędkości.
• Oprócz tego robot przy ustaleniu mu zbyt niskiej prędkości (np. 200) wykonuje parę podrygów po czym całkowicie się zatrzymuje. Podczas gdy powinien co jakiś czas powoli poruszać się do przodu. Prawdopodobnie ma to związek z użyciem bezpośredniej metody dostarczonej wraz z API LEGO Mindstorms, która nie radzi sobie z tak małymi prędkościami. Może dobrym pomysłem byłoby zaimplementowanie własnego algorytmu poruszania się, który wykorzystywałby cyklicznie komendę ruchu dostarczoną przez LEGO z prędkością uznaną przez nich jako „optymalną”, zaś samą prędkość poruszania ustalałoby się poprzez wykorzystanie stosownych interwałów pomiędzy wywołaniami komend. Robot poruszałby się wówczas skokowo, ale przynajmniej jechałby do przodu.