Modell-getriebene Softwareentwicklung für Lego Mindstorms NXT

© itemis AG 2008 ◊ Alle Rechte vorbehalten

Modell-getriebene
Softwareentwicklung für
Lego Mindstorms NXT
Jörg Reichert
IT-Berater
30. Mai 2008

Modell-getriebene Softwareentwicklung
für Lego Mindstorms NXT


Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Werkzeug-Integration
Bewertung

Copyright 2008 itemis GmbH & Co. KG

2



Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Bewertung


3


Plattform - Lego Mindstorms NXT


• Der JVM NXT Brick ist das „Gehirn“ des Lego Mindstorm
Roboters, an dessen Ports Sensoren und Motoren
angeschlossen werden können


4


Programmieralternative 1 - NXT-G


• Der Roboter lässt sich über die mitgelieferte Lego Mindstorms
NXT Entwicklungsumgebung programmieren, die dazu die vom
MIT mitentwickelte Programmiersprache NXT-G verwendet


5



Programmieralternative 2 - leJOS
• leJOS ist eine kleine Java Virtual Machine, die neben der NXT
API auch Werkzeuge enthält, mit denen der Code auf den NXT
Brick übertragen werden kann.
• mit leJOS ist es möglich, den NXT mit einer Objekt-orientierten
Sprache (Java) zu programmieren, dabei werden
unterbrechende Threads, (multi-dimensionale) Arrays,
Rekursion, Synchronisation, Rekursion, Exceptions, die
elementaren Java-Typen wie z.B. float, long und String sowie
die meisten Klassen aus den java.lang, java.util und java.io
Paketen unterstützt


6



Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Bewertung


7



leJOS Statemachine Development Toolkit
• Prof. Dr. Frank Zimmermann von der privaten Hochschule
NORDAKADEMIE in Elmshorn hat ein leJOS-Eclipse-Plugin
entwickelt, das die Generierung von leJOS-Code aus
Zustandsautomaten-Modellen unterstützt
• da UML für die Generierung zu komplex war, wurde eine
domänenspezisches EMF Metamodell erstellt
• mit dem GMF-basierten grafischen Editor lassen sich auf Basis
des Metamodells Zustandsautomaten definieren
• mit Hilfe von openArchitectureWare können die Modelle validiert
und aus ihnen Java-Code generiert werden


8



Metamodell NXT Zustandsautomat


9



leJOS Statemachine Editor


10



Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Bewertung


11



Validieren
• da openArchitectureWare verwendet wird, könnte man mit
check Gültigkeitsregeln definieren
• vom leJOS Statemachine Development Toolkit wird allerdings
nur eine voreingestellte Modellvalidierungs-Regeln angeboten,
z.B. das Prüfen, ob eine Transition zwischen Startzustand und
einem anderen Zustand besteht, das Fehlen eines
Zustandsnamens wird nicht bemängelt (wird dann entsprechend
im Modell und im Error-View angezeigt)
• ob das Modell fehlerhaft ist, erkennt man dann höchstens an
einem fehlerhaft generierten Code
• eigene auf die Semantik des Modells bezogene Regeln kann
somit auch nicht definiert werden.


12



Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Bewertung


13



Simulieren
• wird im Prinzip nicht unterstützt
• es besteht allerdings die Option sich Animationscode mit
generieren zu lassen
• dieser Code wird mit auf den Roboter deployt
• durch den Befehl „run and animate“ im Kontextmenü des
Statemachine Editors kann man über Bluetooth das Programm
auf dem Roboter starten und dieser sendet über Bluetooth
seinen aktuellen Zustand und durchlaufene Transitionen, die in
der modellierten Zustandsmaschine durch Hervorhebungen
visualisiert werden
• von Simulieren kann trotzdem nicht gesprochen werden, weil
das Ganze ja schon auf dem Gerät läuft und nicht in einer
eigenen Simulationsumgebung


14



Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Bewertung


15



Generieren und Kompilieren
• Beim Speichern des Modells wird automatisch eine Java-Klasse
generiert
• Es muss dazu also nicht explizit der openArchitectureWareWorkflow angestoßen werden.
• Wenn man für das Eclipse-Projekt den automatischen Build
eingestellt, wird die generierte Java-Datei auch gleich in
Binärcode übersetzt.
• (Syntaktische) Fehler im Java-Code zeigt die Eclipse IDE an.
• Da einem Java-Projekt die leJOS Nature verliehen werden
kann, werden über die Nature die benötigten leJOS und
Nordakademie-Bibliotheken in den Klassenpfad aufgenommen.
• Über die Eclipse-Preferences wird der Pfad zum leJOSInstallationsordner angegeben.


16



Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Bewertung


17


Deployen


• Das leJOS Statemachine Development Toolkit integriert den
Upload-Befehl in das Kontextmenü der generierten JavaKlasse.
• Die Verbindung zum Roboter lässt sich über die EclipsePreferences konfigurieren (USB pder Bluetooth-Verbindung)
• Bisheriges Manko ist, dass die leJOS-Firmware noch nicht mit
dem Plugin auf den Roboter überspielt werden kann.


18



Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Bewertung


19



Debuggen (1)
• Gerätedebugging wird nicht unterstützt
• Die leJOS-Bibliotheken enthalten Klassen für das Debuggen.
Diese müssten dann aber direkt im Code verwendet werden.
• Die Debugausgabe auf dem Display des NXT-Bricks ist meist
wenig geeignet (wenig Platz oder dann eine spezielle
Debugformatausgabe).
• Eine weitere Alternative wäre, Nachrichten vom Roboter via
Bluetooth zu erhalten. Diese Funktion ist aber eine Leistung der
leJOS-Bibliotheken und kann nicht explizit modelliert werden.


20



Debuggen (2)


21



Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Bewertung


22



Werkzeug-Integration (1)
• Es werden Eclipse als Integrations- und Entwicklungsplattform,
leJOS als Java-Betriebssystem und Entwicklungssprache für
den NXT-Roboter sowie eine Abwandlung des leJOS-EclipsePlugins (das um die Unterstützung von Zustandsmaschinen
bzw. der Modellierung an sich erweitert worden ist) verwendet.
• Zudem ist die Kommunikation zum Roboter via USB oder
Bluetooth konfigurierbar.
• Der Pfad zum leJOS Installationsordner lässt sich angeben. Das
Hochladen des Codes ist über das Kontextmenü der JavaKlasse möglich.
• Die entsprechenden Funktionen im Kontextmenü des
Statechart-Editors selbst gehen nur für Bluetooth-Verbindung.


23



Werkzeug-Integration (2)
• Die Verwendung des Generator-Frameworks
openArchitectureWare ist vollkommen transparent.
• Einem Java-Projekt, dass das Toolkit verwenden soll, muss
einfach nur die leJOS-Nature gesetzt werden.
• Dadurch werden die benötigte Ordnerstruktur im Projekt
angelegt, die gebrauchten Bibliotheken werden in den
Klassenpfad aufgenommen und die Tool-spezifischen
Funktionen als Kontextmenüeintrag für die entsprechenden
Dateien aufgenommen.


24



Agenda
•
•
•
•
•
•
•
•
•

Plattform
Modellieren
Validieren
Simulieren
Generieren
Deployen
Debuggen
Bewertung


25



Bewertung (1)
• Durch die Verwendung von grafischen Modellen und speziell
der Notationsform Zustandsautomat können die Abläufe im
Verhalten des Roboters leicht verständlich visuell dargestellt
werden.
• Damit wird die Domäne „Zustandsmaschine“ (geschlossenes
System mit inneren Zuständen, das über eingehende Ereignisse
nach definierten Regeln seinen Zustand wechseln kann)
abgedeckt
• Problem ist die Einbettung von komplizierten Plattform-Code in
das Zustandsdiagramm, dazu muss man die Plattform sehr gut
kennen, die Editierung im Diagramm ist nicht sehr bequem
• durch die Einbettung des Codes in das Zustandsdiagramm ist
das Abstraktionsniveau nicht sehr hoch
• keine Unterstützung von Annotationen


26


Bewertung (2)


• auch wenn es bei Betrachtung des Metamodells möglich
scheint, können keinen eingebetteten Statemachines modelliert
werden
• damit ist keine Modularisierung über mehreren
Zustandsmaschinen oder gar über mehrere Diagramme möglich


27


Beispiele (1)
• Welcome
• Einfache Ausgabe von „Hallo Welt“ auf dem Display

• Bumper


• Nutzung des Tast-Sensors
• Funktion: beim Anstoßen auf ein Hindernis fährt der Roboter
zurück, dreht sich um 90° und fährt weiter bis er auf ein anderes
Hindernis stößt; bei 4 Richtungsänderungen bricht das Programm
ab

• LineFollower
• Nutzung des Licht-Sensors
• Funktion: Roboter folgt einer schwarzen Linie, bei weißem
Untergrund dreht sich der Roboter um die eigene Achse, bis er
wieder schwarzen Untergrund erkennt


28



Beispiele (2) - Demonstration „Drive on line“


29


Beispiele (3)
• CatChaser
• Nutzung des Ultraschall-Sensors
• Funktion: Roboter erkennt über Ultraschall einen Luftballon und
fährt auf diesen zu


• Dog
• Nutzung des Lautsprecher-Sensors
• Funktion: durch Zuruf von „Links“ oder „Rechts“ ändert der Roboter
entsprechend seine Fahrrichtung – der Roboter unterscheidet
dabei von hellen Tönen (liiinks) oder tiefen Tönen (reeechts)


30



Beispiele (4) - Demonstration „Cat chaser“


31



Quellen
• Prof. Dr. Frank Zimmermann: Modellgetriebene
Softwareentwicklung für Lego Mindstorms NXT, URL:
http://www.nordakademie.de/fileadmin/downloads/Arbeitspapier
e/AP_2008_01.pdf
• Prof. Dr. Frank Zimmermann: Benutzerhandbuch leJOS
Statemachine Toolkit, URL:
http://www.nordakademie.de/fileadmin/downloads/Arbeitspapier
e/AP_2008_02.pdf
• Jeff: Line Follower NXT-G Program, URL:
http://home.earthlink.net/
%7Exaos69/NXT/Line_Follower/Line_Follower.html
• leJOS, URL: http://lejos.sourceforge.net/
• Lego Mindstorms NXT, URL: http://mindstorms.lego.com/


32


Vielen Dank für Ihre
Aufmerksamkeit!
Jörg Reichert
IT-Berater
30. Mai 2008

Modell-getriebene Softwareentwicklung für Lego Mindstorms NXT

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (18)

Similaire à Modell-getriebene Softwareentwicklung für Lego Mindstorms NXT

Similaire à Modell-getriebene Softwareentwicklung für Lego Mindstorms NXT (20)

Plus de joergreichert

Plus de joergreichert (15)

Modell-getriebene Softwareentwicklung für Lego Mindstorms NXT