Różnice między wybraną wersją a wersją aktualną.
| Nowa wersja | Poprzednia wersja | ||
|
pl:miw:miw08_mindstormscontrolj:apibrief [2008/05/20 04:31] miw utworzono |
pl:miw:miw08_mindstormscontrolj:apibrief [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 1: | Linia 1: | ||
| - | Wyciąg z API leJOS oraz iCommand - Funkcjonalności. | + | ====== Wyciąg z API leJOS oraz iCommand - Funkcjonalności ====== |
| kwiecień 2008 | kwiecień 2008 | ||
| autor: Paweł Gutowski | autor: Paweł Gutowski | ||
| Linia 20: | Linia 20: | ||
| Opis poszczególnych pakietów: | Opis poszczególnych pakietów: | ||
| - | icommand.navigation - Sterowanie robotem poruszającym się na dwóch kołach (warunek konieczny). Obiekty klas z tego pakietu kontrolują informacje takie jak: | + | ==== icommand.navigation ==== |
| - | - położenie (x,y) robota na płaszczyźnie (stole, podłodze itp.) | + | Sterowanie robotem poruszającym się na dwóch kołach (warunek konieczny). Obiekty klas z tego pakietu kontrolują informacje takie jak: |
| - | - kierunek zwrotu robota - kąt wokół pionowej osi, względem pozycji startowej | + | * położenie (x,y) robota na płaszczyźnie (stole, podłodze itp.) |
| - | + | * kierunek zwrotu robota - kąt wokół pionowej osi, względem pozycji startowej | |
| - | Jest to realizowane na dwa sposoby: | + | |
| - | 1. Program zapamiętuje dokładnie wszystkie zmiany położenia silników. Znając średnicę kół oraz ich rozstaw wyliczane jest aktualne położenie (x,y) oraz kąt inofmujący w którą stronę zwrócony jest robot. Odpowiadają za to klasy Pilot oraz TachoNavigator. | + | Jest to realizowane na dwa sposoby: |
| - | 2. Z wykorzystaniem kompasu (dodatkowy czujnik). Odpowiadają za to klasy: CompassPilot, CompassNavigator). | + | - Program zapamiętuje dokładnie wszystkie zmiany położenia silników. Znając średnicę kół oraz ich rozstaw wyliczane jest aktualne położenie (x,y) oraz kąt inofmujący w którą stronę zwrócony jest robot. Odpowiadają za to klasy Pilot oraz TachoNavigator. |
| - | Funkcjonalność klas dla opcji 1 oraz 2 pokrywa się, jednak z oczywistych przyczyn użycie kompasu będzie bardziej precyzyjne... | + | - Z wykorzystaniem kompasu (dodatkowy czujnik). Odpowiadają za to klasy: CompassPilot, CompassNavigator). |
| - | + | ||
| - | Przed rozpoczęciem sterowania należy podać parametry fizyczne robota (rozstaw oraz średnica kół, układ silników, ew. port czujnika z kompasem) - Tych zmiennych metody klas z pakietu icommand.navigation będą używać do wyliczania pozycji robota. | + | Funkcjonalność klas dla opcji 1 oraz 2 pokrywa się, jednak z oczywistych przyczyn użycie kompasu będzie bardziej precyzyjne... |
| - | Do dyspozycji będziemy mieli następujące funkcje: | + | |
| + | Przed rozpoczęciem sterowania należy podać parametry fizyczne robota (rozstaw oraz średnica kół, układ silników, ew. port czujnika z kompasem) - Tych zmiennych metody klas z pakietu icommand.navigation będą używać do wyliczania pozycji robota. | ||
| + | |||
| + | Do dyspozycji będziemy mieli następujące funkcje: | ||
| -kontrola jazdy do przodu i do tyłu, funckje: | -kontrola jazdy do przodu i do tyłu, funckje: | ||
| -forward | -forward | ||
| Linia 50: | Linia 53: | ||
| -steer, turn - różne wersje (jazda po łuku o zadanym promieniu - przejechanie zadanego kąta do przodu lub do tyłu po łuku). | -steer, turn - różne wersje (jazda po łuku o zadanym promieniu - przejechanie zadanego kąta do przodu lub do tyłu po łuku). | ||
| - | -Dodatkowo, opcja z kompasem umożliwia kontrolę robota względem kierunków Świata. | + | Dodatkowo, opcja z kompasem umożliwia kontrolę robota względem kierunków Świata. |
| - | + | ||
| - | icommand.nxt - obsługa robota na poziomie poszczególnych komponentów (czujnik - odczyt danych z czujnika, silnik - ustawienie prędkości, pozycji docelowej, odczyt prędkości, odczyt pozycji). Z poziomu tej warstwy komunikowaliśmy się z klockami przy użyciu Prologu i JPL'a. | + | ==== icommand.nxt ==== |
| - | Większość funkcjonalności została pokryta JPL'em i udokumentowana. | + | Obsługa robota na poziomie poszczególnych komponentów (czujnik - odczyt danych z czujnika, silnik - ustawienie prędkości, pozycji docelowej, odczyt prędkości, odczyt pozycji). Z poziomu tej warstwy komunikowaliśmy się z klockami przy użyciu Prologu i JPL'a. |
| - | W przyszłości jednak na uwagę mogą zasługiwać klasy: | + | |
| - | -FileSystem (upload/download/usuwanie plików w bricku. Uruchamianie/zatrzymywanie programów umieszczonych w bricku) | + | Większość funkcjonalności została pokryta JPL'em i udokumentowana. |
| - | -NXT - informacje o bricku (wersja, nazwa itp.) | + | |
| - | icommand.nxt.comm - pakiet klas stanowiących warstwę komunikacji iCommand przez blueatooth- w kontekście tego opracowania jej opis jest nieistotny. | + | W przyszłości jednak na uwagę mogą zasługiwać klasy: |
| - | icommand.vision - pakiet klas, których funkcjonalność może być przydatna przy akwizycji obrazu z kamery internetowej (min: interfejsy do implementacji triggerów - przy wykryciu konkretnego koloru, światła, ruchu...) Do uruchomienia konieczna jest kamera internetowa (podłączona do komputera). UWAGA: Pakiet ten w zasadzie nie ma nic wspólnego z LEGO. | + | * FileSystem (upload/download/usuwanie plików w bricku. Uruchamianie/zatrzymywanie programów umieszczonych w bricku) |
| + | * NXT - informacje o bricku (wersja, nazwa itp.) | ||
| + | ==== icommand.nxt.comm ==== | ||
| + | Pakiet klas stanowiących warstwę komunikacji iCommand przez blueatooth- w kontekście tego opracowania jej opis jest nieistotny. | ||
| + | |||
| + | ==== icommand.vision ==== | ||
| + | Pakiet klas, których funkcjonalność może być przydatna przy akwizycji obrazu z kamery internetowej (min: interfejsy do implementacji triggerów - przy wykryciu konkretnego koloru, światła, ruchu...) Do uruchomienia konieczna jest kamera internetowa (podłączona do komputera). UWAGA: Pakiet ten w zasadzie nie ma nic wspólnego z LEGO. | ||
| + | |||
| + | |||
| + | ===== leJOS ===== | ||
| + | |||
| + | ==== java.awt, java.io, java.lang, java.util ==== | ||
| + | Okrojone wersje podstawowoych bibiliotek dla JVM uruchamianej bricku. | ||
| + | |||
| + | ==== javax.microedition.io, javax.microedition.lcdui ==== | ||
| + | Również okrojone wersje podstawowych bibliotek, tyle, że dla urządzeń mobilnych J2ME | ||
| + | |||
| + | ==== lejos.navigation ==== | ||
| + | Kopia pakietu icommand.navigation. Występują jedynie drobne różnice w nazewnictwie, typach zmiennych (foat, double) lub umiejscowieniu metod (niektóre "poprzechodziły" z klas Pilot, CompassPilot do klas TachoNavigator, CompassNavigator i odwrotnie). | ||
| + | ==== lejos.nxt ==== | ||
| + | Funkcjonalność z grubsza pokrywa się z pakietem icommand.nxt. Występujące różnice: | ||
| + | * jest dostępna obsługa większej ilości dodatkowych czujników (przyspieszenia, koloru, kamery dla NXT >>a nie dla PC<<, kompasu...) | ||
| + | * jest dostępna obsługa wyświetlacza LCD | ||
| + | * jest dostępnych więcej poziomów abstrackji (klasy dziedziczą po sobie) - jednak "na samej górze" funkcjonalność pozostaje praktycznie niezmieniona względem icommand | ||
| + | * udostępniona większa ilość poziomów abstrakcji umożliwia np dobranie się do czujników na poziomie szyny I2C. | ||
| + | * jest dostępna obsługa komunikacji ze starszą wersją klocków: RCX - przy użyciu dodatkowego "czujnika" - służącego do komunikacji IR. (klasy których nazwa rozpoczyna się od RCX) | ||
| + | ==== lejos.nxt.comm ==== | ||
| + | Zestaw klas umożliwiających kontrolowanie komunikacji, zarówno przy użyciu Lego Communication Protocol, jak i "gołych" metod: | ||
| + | * Bluetooth | ||
| + | * USB | ||
| - | leJOS - funkcjonalność udostępniana przez tę VM wykracza poza zakres modułu MOVEMENTS pisanego przez kolegę Piota Hołownię (np pakiet lejos.nxt.remote). | + | ==== lejos.nxt.remote ==== |
| + | Pakiet umożliwiający kontrolę zdalną nad innym robotem. Innymi słowy - jeden robot może sterować innym robotem (ma dostęp do jego portów, silników itd.). Kontrola odbywa się poprzez klasy z pakietu lejos.nxt (dla silników) oraz klasę lejos.nxt.remote.RemoteSensorPort (dla wszystkich czujników). | ||
| - | java.awt, java.io, java.lang, java.util - okrojone wersje podstawowoych bibiliotek dla JVM uruchamianej bricku. | + | ==== lejos.rcxcomm ==== |
| - | javax.microedition.io, javax.microedition.lcdui - również okrojone wersje podstawowych bibliotek, tyle, że dla urządzeń mobilnych J2ME | + | Pakiet z klasami emulującymi funkcjonalność komunikacyjną starej wersji klocków - RCX |
| - | lejos.navigation - Kopia pakietu icommand.navigation. Występują jedynie drobne różnice w nazewnictwie, typach zmiennych (foat, double) lub umiejscowieniu metod (niektóre "poprzechodziły" z klas Pilot, CompassPilot do klas TachoNavigator, CompassNavigator i odwrotnie). | + | |
| - | lejos.nxt - funkcjonalność z grubsza pokrywa się z pakietem icommand.nxt. Występujące różnice: | + | ==== lejos.subsumption ==== |
| - | -jest dostępna obsługa większej ilości dodatkowych czujników (przyspieszenia, koloru, kamery dla NXT >>a nie dla PC<<, kompasu...) | + | Pakiet z mini-frameworkami do pisania programów pod NXT. Składają się na niego 2 systemy kolejkowania zachowań - uruchamianych wtedy gdy zajdą odpowiednie okoliczności oraz jeden system pseudo-wielowątkowy: |
| - | -jest dostępna obsługa wyświetlacza LCD | + | |
| - | -jest dostępnych więcej poziomów abstrackji (klasy dziedziczą po sobie) - jednak "na samej górze" funkcjonalność pozostaje praktycznie niezmieniona względem icommand | + | |
| - | -udostępniona większa ilość poziomów abstrakcji umożliwia np dobranie się do czujników na poziomie szyny I2C. | + | |
| - | -jest dostępna obsługa komunikacji ze starszą wersją klocków: RCX - przy użyciu dodatkowego "czujnika" - służącego do komunikacji IR. (klasy których nazwa rozpoczyna się od RCX) | + | |
| - | lejos.nxt.comm - zestaw klas umożliwiających kontrolowanie komunikacji, zarówno przy użyciu Lego Communication Protocol, jak i "gołych" metod: | + | |
| - | -Bluetooth | + | |
| - | -USB | + | |
| - | lejos.nxt.remote - pakiet umożliwiający kontrolę zdalną nad innym robotem. Innymi słowy - jeden robot może sterować innym robotem (ma dostęp do jego portów, silników itd.). Kontrola odbywa się poprzez klasy z pakietu lejos.nxt (dla silników) oraz klasę lejos.nxt.remote.RemoteSensorPort (dla wszystkich czujników). | + | |
| - | lejos.rcxcomm - pakiet z klasami emulującymi funkcjonalność komunikacyjną starej wersji klocków - RCX | + | |
| - | lejos.subsumption - pakiet z mini-frameworkami do pisania programów pod NXT. Składają się na niego 2 systemy kolejkowania zachowań - uruchamianych wtedy gdy zajdą odpowiednie okoliczności oraz jeden system pseudo-wielowątkowy: | + | |
| -Interfejs Behavior + Klasa Arbitrator: Programista definiuje listę zachowań robota (Behavior) - kolejność w liście oznacza priorytet. Następnie należy uruchomić dla nich "Arbitrator'a" - klasę, która iteruje po wszystkich "zachowaniach" i jeżeli któreś zgłosi, że zapadły okoliczności w których powinno się wykonać to zostaje wykonane. Na jedno zachowanie składają się: | -Interfejs Behavior + Klasa Arbitrator: Programista definiuje listę zachowań robota (Behavior) - kolejność w liście oznacza priorytet. Następnie należy uruchomić dla nich "Arbitrator'a" - klasę, która iteruje po wszystkich "zachowaniach" i jeżeli któreś zgłosi, że zapadły okoliczności w których powinno się wykonać to zostaje wykonane. Na jedno zachowanie składają się: | ||
| -kod realizujący dane zachowanie (np sekwencja ruchów silnikczami) | -kod realizujący dane zachowanie (np sekwencja ruchów silnikczami) | ||
| Linia 87: | Linia 109: | ||
| -Klasy Activity + ActivityBase: Stanowią niejako "nakładkę" na Thread. Programista definiuje zestaw zachowań (Activity), które będą uruchamiane wtedy gdy któraś z innych "zachowań" ją wywoła (lub ona sama w przypadku callbacka, jako, że może implementować PortListener}. Krótko mówiąc, jest to uproszczona wersja obsługi wielowątkowości (pozornie). | -Klasy Activity + ActivityBase: Stanowią niejako "nakładkę" na Thread. Programista definiuje zestaw zachowań (Activity), które będą uruchamiane wtedy gdy któraś z innych "zachowań" ją wywoła (lub ona sama w przypadku callbacka, jako, że może implementować PortListener}. Krótko mówiąc, jest to uproszczona wersja obsługi wielowątkowości (pozornie). | ||
| - | lejos.util - pakiet z dodatkami, które wg twórców leJOSa mogą się przydać programistom klocków (bezpośrednio nie mają wiele wspólnego z samymi klockami). Udostępnianymi narzędziami są: | + | ==== lejos.util ==== |
| + | Pakiet z dodatkami, które wg twórców leJOSa mogą się przydać programistom klocków (bezpośrednio nie mają wiele wspólnego z samymi klockami). Udostępnianymi narzędziami są: | ||
| -Timer + interfejs TimerListener służące do uruchamiania zdarzeń z opóźnieniem | -Timer + interfejs TimerListener służące do uruchamiania zdarzeń z opóźnieniem | ||
| -Interfejs Recyclable + kilka klas kontenerowych. Można do nich wrzucać i wyrzucać obiekty. Taki śmieszny garbage collector, tyle, że collectorem jest sam programista... | -Interfejs Recyclable + kilka klas kontenerowych. Można do nich wrzucać i wyrzucać obiekty. Taki śmieszny garbage collector, tyle, że collectorem jest sam programista... | ||
| -Datalogger - prosty logger umożliwiający logowanie liczb (bez tekstu) i wysłanie ich później do PC poprzez bluetooth lub USB. | -Datalogger - prosty logger umożliwiający logowanie liczb (bez tekstu) i wysłanie ich później do PC poprzez bluetooth lub USB. | ||
