Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:miw:miw08_mindstormsapi [2008/05/27 01:07] miw |
pl:miw:miw08_mindstormsapi [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 1: | Linia 1: | ||
| - | ====== Opis ====== | + | ====== PlNXT ====== |
| + | __**Projekt zakończony**__ | ||
| Piotr Hołownia, <holownia@student.agh.edu.pl> | Piotr Hołownia, <holownia@student.agh.edu.pl> | ||
| - | Build an API prototype in Prolog for NXT-based robots | + | PlNXT to API w Prologu do obsługi [[http://mindstorms.lego.com/eng/Overview/default.aspx|LEGO Mindstorms NXT]] |
| - | * low-level sensomotoric API, cover NXT funcs, provide control for motors, sensors, brick i/o | + | |
| - | * mid-level mimic LEGO env blocks?? does it make sens? | + | |
| - | * component-level: identify common robot parts that need control: wheel, sensor, arm, etc? | + | |
| - | * robot-level: identify robot classes: e.g. im/mobile, rolling vs. walking; provide means to describe common robot designs, like the four provided by LEGO | + | |
| - | * high-level provide services for different classes | + | |
| - | Architecture: | + | |
| - | * MVC, the above is logical model | + | |
| - | * provide a V for every M component to support building of the interface | + | |
| - | Issues: | + | |
| - | * communication | + | |
| - | * control | + | |
| - | * design | + | |
| - | * event handling, device polling | + | |
| - | Ideas: | + | |
| - | * think how to build a Prolog API for NXT | + | |
| - | * investigate the [[http://lejos.sourceforge.net/|LeJOS]] [[http://lejos.sourceforge.net/p_technologies/nxt/nxj/api/index.html|NXJ API]] to remain compatible | + | |
| - | * investigate communication layer: one can use native NXT protocol, iCommand stack, other? | + | |
| - | * middle layer for: integrating logic layer with communication layer | + | |
| - | ====== Spotkania ====== | + | Celem projektu było zaimplementowanie funkcji niskiego poziomu (np. obracanie silnikiem, odczyt sensorów) oraz wyższego (np. jazda do przodu przez zadany czas, wykonanie skrętu w lewo o zadany kąt z zadanym promieniem). |
| - | ===== 08.03.04 ===== | + | Udało się założone cele zrealizować w zadowalającym stopniu. Są rzeczy, które warto poprawić. Zachęcam do zapoznania się z opisem. |
| - | * fenomenologicznie :) mamy klocki, jakby można zrobić API? | + | Dokumentacja: {{:pl:miw:miw08_mindstormsapi:plnxtdocs.zip|plnxtdocs.zip}} |
| - | * inżyniersko, mamy klocki, BT, jak się dogadać z Prologiem | + | |
| + | ====== Opis warstw ====== | ||
| + | Projekt jest podzielony na następujące wartswy: | ||
| + | * najniższa warstwa (nxt_actions), | ||
| + | * średnia warstwa (nxt_sensomoto), | ||
| + | * najwyższa warstwa (nxt_movement). | ||
| - | ===== 080311 ===== | ||
| - | * spec: czego chcemy od niższej warstwy, np.: synchr, etc. | ||
| - | * próbujemy opisywać predykatem w prologu moduły ze środ. lego | ||
| + | ===== Warstwa nxt_actions ===== | ||
| - | ===== 080318 ===== | + | Warstwa odpowiada za komunikację z NXT. Mamy do dyspozycji predykaty poruszające silnikami, odczytującymi dane z sensorów, itp. W tej warstwie można zastosować różne systemy komunikacji. Do tej pory zaimplementowane zostały dwa: |
| - | * pakiety SWI? | + | * {{:pl:miw:miw08_mindstormsapi:080612:nxt_actions_icommand.pl|nxt_actions_icommand}} - komunikacja z użyciem [[http://lejos.sourceforge.net/p_technologies/nxt/icommand/icommand.php|iCommand]], |
| - | * prefixy high-level i mid-level | + | * {{:pl:miw:miw08_mindstormsapi:080612:nxt_actions_sockets.pl|nxt_actions_sockets}} - komunikacja z użyciem socketów (dziełko kolegi [[pl:miw:miw08_mindstormscontrolc|Ziółkowskiego]]). |
| - | * sensory cd | + | |
| + | Dowolną inna implementację komunikacji można stworzyć bazując na pliku {{:pl:miw:miw08_mindstormsapi:080612:nxt_actions_dummy.pl|nxt_actions_dummy.pl}}. | ||
| - | ===== 080401 ===== | + | Ograniczeniem jest to, że nazwy predykatów eksportowanych muszą pozostać takie same. Nie ma także możliwości wprowadzenia niczego nowego bez uwzględnienia tego w warstwie wyższej. Dlaczego? Jest to jedna z warstw projektu, ale wydzielona tylko, aby umożliwić wstawienie w jej miejsce różnych alternatywnych wersji. **Warstwa nxt_actions nie stanowi części API. Nie powinna być używana w projektach bazujących na PlNXT. Nie ma takiej potrzeby.** |
| - | * techn: kom. po ang, użycie [[http://www.swi-prolog.org/packages/pldoc.html|pldoca]] | + | |
| - | * przemyśleć kwestię timerów, trigger, pod kątem [[http://gollem.science.uva.nl/SWI-Prolog/Manual/threads.html|wątków SWI]] | + | |
| + | ===== Warstwa nxt_sensomoto ===== | ||
| - | ===== 080408 ===== | + | Warstwa bazuje na nxt_actions. To, co zostało zaimplementowane w niższej warstwie, w tej jest obudowane w logikę. Zatem mamy tutaj: poruszanie silnikami, odczyt sensorów, odczyt napięcia baterii, odtworzenie pliku dźwiękowego zapisanego w pamięci NXT, odtworzenie dźwięku o podanej częstotliwości. |
| - | * API do obsługi Brick: sound, display, ?? | + | |
| - | * jak się maja wątki, trigery, timery do JPL | + | |
| - | * synchronizacja z [[pl:miw:miw08_mindstormscontrolj|p. Gutowskim]] | + | |
| - | ===== 080415 ===== | + | Dokumentacja: [[http://student.agh.edu.pl/~holownia/plnxt/nxt_sensomoto.html|nxt_sensomoto]] |
| - | * powrót do 3 warstw | + | |
| - | * przygotowanie ''nxt_actions_dummy'' | + | |
| - | * próba zrobienia własnego ''nxt_actions_icmd'' ??? | + | |
| + | ===== Warstwa nxt_movement ===== | ||
| + | Warstwa dostarcza predykaty realizujące złożoną pracę silników: ruch pojazdu do przodu, do tyłu, skręcanie, obracanie, ruch do napotkania przeszkody. | ||
| - | ===== 080422 ===== | + | Dokumentacja: [[http://student.agh.edu.pl/~holownia/plnxt/nxt_movement.html|nxt_movement]] |
| - | * czy mamy pokrytą //całość// funkcjonalności (crosscheck): | + | |
| - | * {{:pl:miw:appendix_2-lego_mindstorms_nxt_direct_commands.pdf|protokołu lego}} | + | |
| - | * icmd | + | |
| - | * [[pl:miw:miw08_mindstormscontrolc|p. Ziólkowski]] | + | |
| - | * synchronizacja z [[pl:miw:miw08_mindstormscontrolc|p. Ziólkowskim]] | + | |
| - | * synchronizacja z [[pl:miw:miw08_mindstormscontrols|p. Siarą]] | + | |
| - | ===== 080520 -> 080527 ===== | ||
| - | * [[pl:mindstorms:lab:lab5]] [[pl:miw:miw08_mindstormsdesign:strona_1]] [[pl:miw:miw08_mindstormsenv]] | ||
| - | ====== Projekt ====== | + | ====== Dodatkowe komponenty ====== |
| + | ===== Threads ===== | ||
| - | ===== 08.03.04 ===== | + | Do implementacji złożonych algorytmów sterowania NXT niezbędne jest wprowadzenie mechanizmów opóźniania akcji w czasie oraz uwarunkowanie akcji od pewnych zdarzeń. Np. chcemy, żeby po 10 sekundach od wciśnięcia sensora dotyku urządzenie odtworzyło plik dźwiękowy. |
| - | {{:pl:miw:miw08_mindstormsapi:akcje.pl|:pl:miw:miw08_mindstormsapi:akcje.pl}} | + | |
| - | {{:pl:miw:miw08_mindstormsapi:ruch.pl|:pl:miw:miw08_mindstormsapi:ruch.pl}} | + | |
| - | <code prolog> | + | W pliku {{:pl:miw:miw08_mindstormsapi:080612:threads.pl|threads.pl}} znajdują się predykaty umożliwiające tworzenie triggerów i timerów z wykorzystaniem wątków w SWIProlog. Trigger uruchamia akcję pod warunkiem zajścia zdarzenia. Timer uruchamia akcję po wyznaczonym czasie. |
| - | nxt_motor(Motor,Speed, Direction) :- | + | |
| - | var(Speed), % odczyt pr | + | |
| - | get_speed(Speed) | + | |
| - | nxt_motor(Motor,Speed, Direction) :- | + | |
| - | var(Dir), % odczyt dir | + | |
| - | nxt_motor(Motor,Speed, Direction) :- | + | |
| - | nonvar(S), | + | |
| - | set_speed(S), | + | |
| - | nxt_motor(Motor,Speed, Direction) :- | + | |
| - | Speed < 0, | + | |
| - | nxt_motor(Motor,reverse, Direction) :- | + | |
| - | nxt_motor(Motor,Speed, _), | + | |
| - | Speedn is - Speed, | + | |
| - | nxt_motor(Motor,Speedn). | + | |
| - | nxt_motor(Motor,Speed, Time) :- | + | Dokumentacja: [[http://student.agh.edu.pl/~holownia/plnxt/threads.html|threads]] |
| - | create_timer(T1), %potrzebuje miec timery | + | |
| - | set_speed(M,S), | + | |
| - | wakeup(T1,Time,nxt_motor(,0,_)). | + | |
| - | </code> | ||
| - | nxt_motor(M,S,_),S \= 0. | + | ====== Przygotowanie środowiska ====== |
| - | <code prolog> | + | ===== Z użyciem iCommand ===== |
| - | nxt_motor(Motor,Speed, Direction) :- | + | |
| - | var(Speed), % odczyt pr | + | |
| - | nxt_get_speed(Speed). | + | |
| - | nxt_get_speed(Speed) :- | + | Krótka instrukcja konfiguracji połączenia BT z wykorzystaniem iCommand dla użytkowników systemu Windows: |
| - | icmnd_get_speed(Speed). | + | |
| - | + | ||
| - | nxt_get_speed(Speed) :- | + | |
| - | ptcp_get_speed(Speed). | + | |
| + | - Ściągnij i rozpakuj (np. do katalogu C:\nxt\) następujące pliki zip: | ||
| + | * iCommand (http://lejos.sourceforge.net/p_technologies/nxt/icommand/downloads.php), | ||
| + | * rxtx (http://www.rxtx.org), | ||
| + | * bluesock (http://bluesock.dev.java.net). | ||
| + | - Dopisz do zmiennej środowiskowej Classpath ścieżki do następujących plików jar: icommand.jar, bluesock.jar, RXTXcomm.jar. Np.: <code> C:\nxt\icommand-0.7\dist\icommand.jar;C:\nxt\bluesockbeta1.0\bluesock.jar;C:\nxt\rxtx-2.1-7-bins-r2\RXTXcomm.jar </code> | ||
| + | - Dopisz do zmiennej środowiskowej Path ścieżki do katalogów z bibliotekami dll pochodzącymi z RXTX i bluesock. Np.: <code> C:\nxt\rxtx-2.1-7-bins-r2\Windows\i368-mingw32\;C:\nxt\bluesockbeta1.0\ </code> | ||
| + | - Sparuj komputer z NXT. Dla tego urządzenia musi być dostępna usługa portu szeregowego "Dev B". Sprawdź jaki port COM został przypisany do tej usługi dla NXT. | ||
| + | - Umieść w katalogu domowym plik icommand.properities (przy próbie skorzystania z iCommand zostanie utworzony automatycznie). Edytuj go, wpisując dwie następujące linie: | ||
| + | <code> | ||
| + | nxtcomm=COM6 | ||
| + | nxtcomm.type=bluesock | ||
| </code> | </code> | ||
| - | ===== 08.03.11 ===== | + | Zamiast COM6 wpisz port, który jest przypisany do Twojego NXT. |
| - | * {{:pl:miw:miw08_mindstormsapi:ruch2.pl|ruch2.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:silnik.pl|silnik.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:akcje2.pl|akcje2.pl}} | + | |
| - | ===== 08.03.18 ===== | + | Chcąc używać API, należy do katalogu projektu skopiować następujące pliki: |
| - | * {{:pl:miw:miw08_mindstormsapi:nxt_actions.pl|nxt_actions.pl}} | + | * {{:pl:miw:miw08_mindstormsapi:080612:nxt_actions_icommand.pl|nxt_actions_icommand.pl}}, |
| - | * {{:pl:miw:miw08_mindstormsapi:nxt_components.pl|nxt_components.pl}} | + | * {{:pl:miw:miw08_mindstormsapi:080612:nxt_sensomoto.pl|nxt_sensomoto.pl}}, |
| - | * {{:pl:miw:miw08_mindstormsapi:nxt_movement.pl|nxt_movement.pl}} | + | * {{:pl:miw:miw08_mindstormsapi:080612:nxt_movement.pl|nxt_movement.pl}}, |
| + | * {{:pl:miw:miw08_mindstormsapi:080612:threads.pl|threads.pl}}. | ||
| - | ===== 08.04.01 ===== | + | W programie należy załadować moduły, których chcemy używać. Np. |
| - | * {{:pl:miw:miw08_mindstormsapi:080401:nxt_movement.pl|nxt_movement.pl}} | + | <code prolog> |
| - | * {{:pl:miw:miw08_mindstormsapi:080401:nxt_components.pl|nxt_components.pl}} | + | :- use_module(nxt_movement). |
| - | * {{:pl:miw:miw08_mindstormsapi:080401:nxt_actions.pl|nxt_actions.pl}} | + | :- use_module(nxt_sensomoto). |
| - | + | :- use_module(nxt_thread). | |
| - | ===== 08.04.08 ===== | + | </code> |
| - | * {{:pl:miw:miw08_mindstormsapi:080408:nxt_movement.pl|nxt_movement.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080408:nxt_java_movement.pl|nxt_java_movement.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080408:nxt_components.pl|nxt_components.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080408:threads.pl|threads.pl}} | + | |
| - | + | ||
| - | ===== 08.04.15 ===== | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080415:nxt_movement.pl|nxt_movement.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080415:nxt_sensomoto.pl|nxt_sensomoto.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080415:nxt_actions_icommand.pl|nxt_actions_icommand.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080415:nxt_actions_dummy.pl|nxt_actions_dummy.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080408:threads.pl|threads.pl}} | + | |
| - | + | ||
| - | + | ||
| - | ===== 08.04.22 ===== | + | |
| - | W stosunku do projektu z 08.04.15 zmieniły się następujące pliki: | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080422:nxt_sensomoto.pl|nxt_sensomoto.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080422:nxt_actions_icommand.pl|nxt_actions_icommand.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080422:nxt_actions_dummy.pl|nxt_actions_dummy.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080422:nxtapi-gpl.txt|gpl}} | + | |
| - | + | ||
| - | ===== iCommand how-to for Windows users ===== | + | |
| - | + | ||
| - | * 1. Unzip the contents of the iCommand zip file (http://lejos.sourceforge.net/p_technologies/nxt/icommand/downloads.php) into a directory. | + | |
| - | * 2. Set your classpath environment variable to include icommand.jar. | + | |
| - | * 3. Download RXTX from http://www.rxtx.org. | + | |
| - | * 4. Set the Java build path to include RXTXcomm.jar. | + | |
| - | * 5. There are some dll's that come with RXTX. Make the dll's accessible by copying them to your Java bin directory. | + | |
| - | * 6. Download Bluesock from http://bluesock.dev.java.net/servlets/ProjectDocumentList | + | |
| - | * 7. Set the Java build path to include bluesock.jar. | + | |
| - | * 8. Make the bluesock.dll accessible by copying it to your Java bin directory. | + | |
| - | * 9. Pair your computer with your NXT brick and check which COM port uses your NXT. Maybe it needs to be set (depends on BT stack). | + | |
| - | * 10. Put the file icommand.properties into your home directory, or your working directory. Set the value of nxtcomm to the value of your COM port. The file has to include these two lines: | + | |
| - | + | ||
| - | nxtcomm=COM6 | + | |
| - | + | ||
| - | nxtcomm.type=bluesock | + | |
| - | + | ||
| - | I'm not sure if that's all. ;) Try it. If there's something missing, don't hesitate | + | |
| - | to fix this how-to. | + | |
| - | + | ||
| - | + | ||
| - | ===== 08.05.27 ===== | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080527:nxt_movement.pl|nxt_movement.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080527:nxt_sensomoto.pl|nxt_sensomoto.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080527:nxt_actions_icommand.pl|nxt_actions_icommand.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080527:nxt_actions_dummy.pl|nxt_actions_dummy.pl}} | + | |
| - | * {{:pl:miw:miw08_mindstormsapi:080527:threads.pl|threads.pl}} | + | |
| - | + | ||
| - | ====== Sprawozdanie ====== | + | |
| - | ===== 08.03.04 ===== | + | |
| - | Podejście inżynierskie zawiesiłem. Spróbowałem tworzyć API wyższego poziomu przy założeniu, że mam dostępne pewne predykaty API niższego poziomu (ustawianie prędkości obrotowej serwomechanizmu, obracanie o zadany kąt). Jest to trudne do realizacji bez gotowych rozwiązań API niższego poziomu. Istotne jest, aby stworzyć mechanizmy działania, które w leJOS są dostępne w klasie Behavior i umożliwiają podejmowanie akcji po zajściu jakiegoś zdarzenia. Myślę, że należy skupić się na podejściu inżynierskim. | + | |
| - | + | ||
| - | ===== 08.03.11 ===== | + | |
| - | W pliku ruch2.pl zamieszczone są predykaty realizujące złożoną pracę silników: ruch pojazdu do przodu, do tyłu, skręcanie, obracanie. | + | |
| - | W pliku silnik.pl znajduje się predykat nxtMotor, pozwalający w wybrany sposób poruszać silnikiem. | + | |
| - | W pliku akcje2.pl są predykaty, które powinny obracać silnik z zadaną prędkością, o zadany kąt, odczytywać prędkość obrotową silnika, a także umożliwiać tworzenie timerów i triggerów. | + | |
| - | Wprowadzenie triggerów pozwala dodać dla każdego z ruchów pojazdu warunek: "do napotkania przeszkody" i wiele innych możliwości. Np. jedź do napotkania przeszkody, skręcaj do napotkania przeszkody, rozpocznij jazdę na komendę dźwiękową. | + | |
| - | W tym momencie predykaty z pliku akcja2.pl wypisują jedynie swój zamierzony cel, aby móc testować działanie. | + | |
| - | ** Wobec tego od realizujących warstwy niższe oczekuję wykonania w tym miejscu działających mechanizmów. Czyli:** | + | |
| - | * możliwość sterowania z Prologu ruchem silnika z zadana prędkością, zadanym kątem lub w nieskończoność, | + | |
| - | * możliwość używania timerów i triggerów. | + | |
| - | + | ||
| - | ===== 08.03.18 ===== | + | |
| - | Utworzyłem moduły: | + | |
| - | * nxt_actions - predykaty, które powinny obracać silnik z zadaną prędkością, o zadany kąt, odczytywać prędkość obrotową silnika, odczytywać pomiary sensorów, a także umożliwiać tworzenie timerów i triggerów, | + | |
| - | * nxt_components - predykaty realizujące operacje na sensorach i silnikach na różne sposoby, | + | |
| - | * nxt_movement - predykaty obsługujące złożoną pracę silników: ruch pojazdu do przodu, do tyłu, skręcanie, obracanie, ruch do napotkania przeszkody. | + | |
| - | + | ||
| - | Aby nie wprowadzać zbyt dużej ilości kodu przed stwierdzeniem słuszności zastosowania triggerów, tylko predykat 'go' z modułu 'nxt_movement' pozwala na ruch do napotkania przeszkody. W każdym razie niezbędny jest jakiś sposób implementacji callbacków. | + | |
| - | + | ||
| - | W module nxt_actions znajdują się predykaty, które powinny być pomostem pomiędzy moim projektem a projektami realizujących niższe warstwy. | + | |
| - | + | ||
| - | ===== 08.04.01 ===== | + | |
| - | Dodane komentarze oraz trigger i timer z wykorzystaniem wątków w SWIProlog. | + | |
| - | + | ||
| - | ===== 08.04.08 ===== | + | |
| - | Zdecydowałem się jednak na wprowadzenie przedrostka nxt dla predykatów. Mimo iż moduł ma swoją przestrzeń nazw, hipotetycznie mogłaby zaistnieć sytuacja, w której ktoś korzystałby jednocześnie z mojego modułu i czyjegoś, który dostarczałby przynajmniej jeden predykat o tej samej nazwie, co w moim module. | + | |
| - | + | ||
| - | iCommand nie umożliwia obsługi wyświetlacza i wydawania dźwięków! | + | |
| - | + | ||
| - | W iCommand metoda Motor.A.rotate(long count,boolean returnNow) obraca silnik o zadany kąt i zwraca sterowanie, jeśli returnNow==true. Nie zwraca go jednak wystarczająco szybko (wywoływana przez jpl), aby uruchomienie dwóch silników bezpośrednio po sobie odbyło się bez opóźnienia. Stąd błędy w poruszaniu się robota przy użyciu tej metody. Np. predykat nxt_go(200,1000) sprawia, że robot nieznacznie skręca przed wykonaniem ruchu prostoliniowego i na koniec także. Praca silników jest lekko przesunięta w czasie. Przy większych prędkościach obrotowych (np. 700 stopni na sekundę) ta różnica staje się niedopuszczalnie duża. Przy mniejszych (np. 150 stopni na sekundę) wydaje się nie przeszkadzać. Dla wyeliminowania tego błędu należałoby zastosować wielowątkowość w Javie. | + | |
| - | + | ||
| - | Dodatkowym poważnym problemem jest brak możliwości odczytu kierunku obracania się silnika przy użyciu iCommand. To także należy rozwiązać. | + | |
| - | + | ||
| - | Poza powyższymi dwoma problemami moduł nxt_movement działa prawidłowo (testowałem na "żywym" robocie). Muszę jeszcze poprawić komentarze, bo nie wszystko jest jasno określone. | + | |
| - | + | ||
| - | Ponadto W iCommand jest dostępna klasa icommand.navigation.Pilot. Umożliwia pewne ruchy robota na średnim poziomie (alternatywa dla modułu nxt_movement). Próbowałem używać jej w Prologu, ale nie zdążyłem przetestować. Efekt w module nxt_java_movement. | + | |
| - | Z mniej ciekawych rzeczy: | + | Aby sprawdzić poprawność przygotowania środowiska, zachęcam do uruchomienia pliku testowego {{:pl:miw:miw08_mindstormsapi:test.pl|test.pl}}. Jest on przygotowany dla robota [[http://mindstorms.lego.com/Overview/MTR_Tribot.aspx|TriBot]]. Można dzięki niemu szybko sprawdzić poprawność odczytów czujników oraz działanie silnika. Dla [[http://mindstorms.lego.com/Overview/MTR_Tribot.aspx|TriBot]] także ruch złożony (jazda do przodu, do tyłu, skręcanie, obracanie). |
| - | Metody iCommand Motor.A.stop() i Motor.A.flt() działają nieprawidłowo. | ||
| - | Funkcja "stop" używa hamulca, a "flt" odcina zasilanie i sprawia, że silnik zatrzymuje się w wyniku oporów ruchu. | ||
| - | Do zatrzymania silnika rozsądnie byłoby użyć funkcji "stop". Robot na równi pochyłej nie będzie się staczał pod swoim cięzarem. Oczywiście powinno się także umożliwić korzystanie z zatrzymania płynnego innym predykatem, ale idea predykatu nxt_motor(Motor,0) jest taka, ze silnik sie nie obraca. W każdej sytuacji! | ||
| - | Po użyciu funkcji "stop" funkcja "isMoving" zwraca "true", chociaż silnik jest nieruchomy. Poważy błąd ze strony iCommand. | ||
| - | Spróbowałem jednocześnie używać funkjci "stop" i "flt" po sobie. Takie zestawienie sprawia, że hamulec wciąz działa, a po zastosowaniu funkcji "flt" funkcja "isMoving" działa poprawnie. | ||
| - | Znowu błąd ze strony iCommand. Po użyciu funkcji "flt" ponowne uruchomienie silnika jest niemożliwe. | ||
| - | Wreszcie prawidłowe zatrzymanie silnika powinno składać się z zastosowania funkjci "stop" i ustawienia prędkości silnika na zero (setSpeed(0)). Wtedy co prawda funkcja "isMoving" zwraca "true", ale funkcja "getSpeed" zwraca zero i w ten sposób można rozpoznać, że silnik się nie obraca. | ||
| - | Predykat obracający silnik o zadany kąt z zadaną prędkością także musi na koniec ustawić prędkość zerową, aby zapewnić poprawny odczyt prędkości. Należy się zastanowić nad rozsądniejszym rozwiązaniem. Jako tymczasowe jest dobre, ale w przyszłości może powodować błędy. Np. przy wielowątkowym sterowaniu robotem. | + | ====== Laboratorium przygotowane w ramach projektu ====== |
| - | **Nazwy modułów, predykatów są robocze. W każdej chwili do zmiany. Proponowana przeze mnie konstrukcja: nxt_components (może warto nazwać nxt_icommand, bo teraz wykorzystuje icommand) jest warstwą niższą. Używa jej warstwa wyższa (nxt_movement i ewentualnie nxt_java_movement, bo nie wiem, co z tym "dobrodziejstwem" zrobić). Do tego dochodzi moduł threads, implementujący prymitywny trigger i timer za pomocą wątków SWIProlog. Pan Ziółkowski powinien zaproponować swoją wersję nxt_components.** | + | [[pl:mindstorms:lab:lab5|Laboratorium]] przewidziane na 1,5 godziny składa się z obserwowania testowego programu oraz implementacji wybranego algorytmu. |
| - | ===== 08.04.15 ===== | ||
| - | Wróciłem do trójwarstowej konstrukcji. | ||
| - | nxt_movement korzysta z nxt_sensomoto, do którego przy użyciu predykatu use_module/1 można podłączyć warstwę komunikacyjną z NXT (np.nxt_actions_icommand). | ||
| - | Dla potrzb testowania bez użycia klocków należy podłączyć nxt_actions_dummy. Ten moduł także może posłużyć jako wzór do konstruowania alternatywnego dla nxt_actions_icommand modułu komunikacyjnego. | ||
| - | ===== 08.04.22 ===== | ||
| - | Aby uzupełnić funkcjonalność dodałem predykaty realizujące w icommand: | ||
| - | * odczyt i zapis brick name, | ||
| - | * odgrywanie dźwięku o podanej częstotliwości i podanym czasie trwania, | ||
| - | * odgrywanie pliku dźwiękowego raz lub w pętli, | ||
| - | * uruchamianie i zatrzymywanie pliku wykonywalnego z programem, | ||
| - | * odczyt poziomu napięcia baterii. | ||
| - | O wilku mowa! Nie przetestowałem wprowadzonych predykatów z powodu rozładowanych baterii. Zrobię to w najbliższym czasie. | ||
| - | Pan Ziółkowski realizuje taką funkcjonalność, więc może znów bazując na nxt_actions_dummy wprowadzić swoje rozwiązania. | ||
| - | Wyglądałoby na to, że mam pokrytą funkcjonalność protokołu Lego, Ziółka i icommand(w stopniu wykluczającym zagłębianie się w niepotrzebne szczegóły). | ||
| - | ===== 08.05.27 ===== | + | ====== Co należy poprawić? ====== |
| - | Przygotowałem laboratorium: [[pl:mindstorms:lab:lab5]]. | + | |
| - | Laboratorium składa się z obserwowania testowego programu oraz implementacji wybranego algorytmu. | + | |
| - | Proponowana nazwa API to PlNXT. Podobnie do PlDoc, PlUnit. Krótko i konkretnie. | + | Moduł komunikacyjny nxt_actions_icommand nie daje możliwości odczytu kierunku obrotu silnika. Nie jest to zaimplementowane w samym iCommand. |
| + | ---- | ||
| + | Odczytu sensorów dokonuje się podając numer portu. Powinna być też możliwość łatwiejszego odczytu bez podawania portu. Port byłby wtedy pobierany z konfiguracji robota. | ||
| + | ---- | ||
| + | Musi istnieć możliwość usuwania wcześniej utworzonych timerów i triggerów. | ||
| + | ---- | ||
| + | W iCommand metoda Motor.A.rotate(long count,boolean returnNow) obraca silnik o zadany kąt i zwraca sterowanie, jeśli returnNow==true. Nie zwraca go jednak wystarczająco szybko (wywoływana przez jpl), aby uruchomienie dwóch silników bezpośrednio po sobie odbyło się bez opóźnienia. | ||
| - | Chyba powinienem jeszcze dokładniejszą dokumentację przygotować. Niektóre rzeczy mogą być niejasne dla kogoś, kto ma pierwszy raz styczność z PlNXT. | + | Stąd błędy w poruszaniu się robota przy użyciu tej metody. Np. predykat nxt_go(200,1000) sprawia, że robot nieznacznie skręca przed wykonaniem ruchu prostoliniowego i na koniec także. |
| - | PlDoc generuje dokumentację w latex, ale nie mogłem tego rozgryźć. Nie działało to prawidłowo. Dokumentacja w html jest generowana przez serwer dokumentacji w Prolog. Ta droga tworzenia dokumentacji działa bez zarzutu. Może przydałoby się taki uruchomić, aby dokumentacja była automatycznie generowana po wprowadzanych zmianach i dostępna na wiki? Tymczasowo wygenerowane pliki html i css po małej przeróbce umieściłem tutaj: | + | Praca silników jest lekko przesunięta w czasie. Przy większych prędkościach obrotowych (np. 700 stopni na sekundę) ta różnica staje się niedopuszczalnie duża. Przy mniejszych (np. 150 stopni na sekundę) wydaje się nie przeszkadzać. Może dla wyeliminowania tego błędu należałoby zastosować wielowątkowość w Javie. |
| - | * [[http://student.agh.edu.pl/~holownia/plnxt/nxt_sensomoto.html|nxt_sensomoto]] | + | ---- |
| - | * [[http://student.agh.edu.pl/~holownia/plnxt/nxt_movement.html|nxt_movement]] | + | |
| - | * [[http://student.agh.edu.pl/~holownia/plnxt/threads.html|threads]] | + | |
| - | ====== Materiały ====== | + | ====== Historia prac nad projektem ====== |
| - | * http://mindstorms.lego.com/Overview/NXTreme.aspx | + | |
| - | * http://mindstorms.lego.com/eng/community/resources/default.asp | + | |
| + | [[pl:miw:miw08_mindstormsapi:historia|Historia]] - spotkania, kolejne wersje projektu, sprawozdania cząstkowe. | ||
