Wyciąg z API leJOS oraz iCommand - Funkcjonalności

kwiecień 2008 autor: Paweł Gutowski

iCommand - v.0.7 leJOS NXJ - beta version 0.5.0

iCommand - dokumentacja składa się z JavaDoc API oraz z kilku przykładowych klas w Java, wykorzystujących iCommand. Schemat prezentuje hierarchię warstw w iCommand:

|---------------------|  |-----------------|
| icommand.navigation |  | icommand.vision |
|---------------------|  |-----------------|
|    icommand.nxt     | 
|---------------------|
| icommand.nxt.comm   |
|---------------------|

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:

  • 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.
  2. Z wykorzystaniem kompasu (dodatkowy czujnik). Odpowiadają za to klasy: CompassPilot, CompassNavigator).

Funkcjonalność klas dla opcji 1 oraz 2 pokrywa się, jednak z oczywistych przyczyn użycie kompasu będzie bardziej precyzyjne…

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:

  1. kontrola jazdy do przodu i do tyłu, funckje:
    1. forward
    2. backward
    3. travel
    4. isMoving
    5. stop
  2. ustawianie (obracanie) oraz odczytywanie kierunku (kąta robota), funkcje:
    1. angleTo (ustawia robota w kierunku podanym wg współrzędnych x,y)
    2. getAngle
    3. rotate (obrót o zadany kąt)
    4. rotateTo (obrót do zadanego kąta)
    5. rotateLeft, rotateRight
  3. kontrola położenia robota na płaszczyźnie, funkcje:
    1. getX, getY (odczyt współrzędnych)
    2. goTo(x,y) (robot obraca się w stornę punktu x,y i dojeżdża do niego)
    3. setPosition (robot dojeżdża do punktu x,y i ustawia się w podanym kierunku)
  4. kontrola ruchu po okręgu (łuku), funkcje:
    1. 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.

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.

Większość funkcjonalności została pokryta JPL'em i udokumentowana.

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)
  • 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.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:

  1. 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ę:
    1. kod realizujący dane zachowanie (np sekwencja ruchów silnikczami)
    2. opis okoliczności w jakich dane zachowanie robota ma zostać wykonane (ciało metody zwracającej booleana - np. true wtedy gdy wciśnięty czujnik nacisku)
    3. kod, który ma zostać zrealizowany w chiwli, gdy klasa-Arbitrator przerwie realizowanie danego zachowania.
  2. Interfejs Behavior2 + Klasa Arbitrator2: Rozszerzenie wersji powyższej. Rozszerzenie polega na dodaniu możliwości w której to obiekt pod interfejsem Behavior2 sam zgłasza się do Arbitratora2, że chce się wykonać
  3. 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ą:

  1. Timer + interfejs TimerListener służące do uruchamiania zdarzeń z opóźnieniem
  2. Interfejs Recyclable + kilka klas kontenerowych. Można do nich wrzucać i wyrzucać obiekty. Taki śmieszny garbage collector, tyle, że collectorem jest sam programista…
  3. Datalogger - prosty logger umożliwiający logowanie liczb (bez tekstu) i wysłanie ich później do PC poprzez bluetooth lub USB.
pl/miw/miw08_mindstormscontrolj/apibrief.txt · ostatnio zmienione: 2017/07/17 08:08 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0