Podczas laboratorium mieliśmy zaprojektować i przetestować po „załadowaniu do robota” program lub programy realizujące co najmniej jedno z wyznaczonych zadań: Magazynier 1, Magazynier 2, Złodziej 1, Złodziej 2.
Zaproponowane zadania cechowały się bardzo dużym podobieństwem:
Każde z zadań rozpoczynało się szeregiem instrukcji pozwalających robotowi podjechać do piłeczki, chwycić ją, wykonać zwrot o 180 stopni, by rozpocząć ruch w kierunku pewnego celu.
Powyższy fakt skusił nas do zrealizowania jednego programu głównego Robo3.rbt, którego treść czerpała z każdego z powyższych algorytmów. Zapragnęliśmy, by Czesław został złodziejem mającym za zadanie dostarczenie skradzionej piłeczki do jednego z wyznaczonych miejsc ( biały obszar, ściana ). Robot po wykonaniu zwrotu jednocześnie sprawdza stan czujników dźwięku, światła i odległości by w przypadku spełnienia jednego z wymaganych warunków, wykonać przypisane do niego instrukcje.
Jednoczesne sprawdzanie wartości na poszczególnych czujnikach uzyskaliśmy poprzez widoczne na zdjęciu „rozgałęzienie” w algorytmie po wykonaniu instrukcji zwrotu o 180 stopni [ zwrot taki jest najbliższy pożądanemu w przypadku zażądania przeciwnego względem siebie obrotu kół robota, każde o dokładnie 90% jednego swojego pełnego obrotu ( efekt nie będzie widoczny na filmach, gdyż zaimportowany program obraca koła o 100% jednego obrotu ) ].
Po „usłyszeniu” odpowiednio głośnego dźwięku ( np. wypowiedzianego „Stać! Policja” ) robot zatrzymuje się i upuszcza piłeczkę. Warto zwrócić uwagę na fakt, że robot zatrzymując się, nie ma już szansy dotrzeć do „białego obszaru” lub „ściany”, przez co pozostałe rozgałęzienia w algorytmie nie wprowadzają niepożądanych udziwnień w zachowaniu Czesława. Eleganckim rozwiązaniem byłoby jednak na końcu każdego rozgałęzienia umieścić instrukcje w sposób twardy kończącą działanie programu. Przy aktualnym stanie rzeczy, po wykonaniu instrukcji np. związanych z dotarciem do „białego obszaru”, robot mógłby wykonać np. instrukcje związane z czujnikiem dźwięku, jeśli wartość na nim byłaby odpowiednio wysoka.
Film: http://www.youtube.com/watch?v=O1nObbJO720
W początkowym etapie realizacji programu, robot nie może poradzić sobie z przechwyceniem piłeczki. Jest to efekt ślizgania się stojaka po posadzce. Dopiero po napotkaniu obszaru o większym współczynniku tarcia z gumą, robot może przejść do dalszej pracy z algorytmem.
Po „wykryciu” przez czujnik światła obszaru o odpowiednio jasnej powierzchni, robot zatrzymuje się, wypuszcza piłeczkę, wycofuje się i zwiera szczęki.
Po „wykryciu” przez czujnik przeszkody ( ściany ) w odległości 15 cm, robot wykonuje podobne instrukcje jak w przypadku: Cel: Biały obszar.
Każdy z powyższych filmów jest efektem działania jednego, tego samego programu.
Program: robo3.rbt
Algorytm Magazynier realizował instrukcje związane z przenoszeniem piłeczki na konkretną odległość w nieskończonej pętli, tak aby po przeniesieniu jednej „paczki”, magazynier wracał po kolejną. Swoją drogą ciekawym rozwinięciem tego pomysłu mogłyby być dwa roboty podkradające sobie na zmianę piłeczki ze swoich „baz”.
Program: magazynier.rbt
Po zakończeniu pracy nad algorytmem Robo3 i chwilą wytchnienia w formie Magazyniera, zajęliśmy się pracą nad zestawem instrukcji realizujących tzw kluczenie. Z braku czasu, stworzyliśmy prosty program, który w momencie „usłyszenia” przez robota odpowiednio donośnego dźwięku, realizował nieskończony ruch po okręgu aż do usłyszenia po raz kolejny podobnie donośnego dźwięku. Następnie następowało wypuszczenie piłeczki ze szczypiec.
Program: kluczenie.rbt
Podczas wykonywania zadań związanych z trzecim laboratorium Lego MindStorms przetestowaliśmy -naszym zdaniem- jedną z bardzo ważnych możliwości środowiska NXT, jaką jest programowanie zadań mających wykonywać się równolegle od dowolnego punktu programu sekwencyjnego. Mając na uwadze udogodnienia komunikacyjne w postaci operacji na zmiennych, łatwo zdać sobie sprawę z potencjału takiego stanu rzeczy. Pod koniec laboratorium, z pomocą prowadzącego, odkryliśmy także możliwość sprawdzenia wartości na poszczególnych czujnikach na konsoli zamontowanej w robocie, bardzo ułatwiającej projektowania oprogramowania.
Po trzecim laboratorium jeszcze bardziej kuszące stało się zaprojektowanie i przetestowanie programów przeznaczonych do współpracy kilku robotów, bądź po prostu kilku konsol w jednym bardziej skomplikowanym robocie. Ciekawi jesteśmy jak mogłaby przebiegać komunikacja poprzez czujniki ( czy w ogóle byłaby w praktyce skuteczna ) i połączone porty kilku konsol.
