Archive by Author

Ergebnis Technologievergleich, Simulation von Aktoren und Sensoren in NeXTsim, Benutzerinteraktion in NeXTsim

30 Nov

Wie in meinem letzten Blogeintrag erwähnt hat der durchgeführte Technologievergleich ergeben, dass es eine Reihe von Open Source Engines gibt, welche die Anforderungen für NeXTsim erfüllen und für die Entwicklung eingesetzt werden können. Die entgültige Wahl fiel letztendlich auf die Java MonkeyEngine, da sie neben der eigentlichen Funktionalität auch über eine vergleichsweise große und aktive Community und eine Dokumentation von hoher Qualität verfügt. Antworten auf Fragen und Probleme findet man daher in der Regel schnell, was gerade bei Arbeiten, die innerhalb einem strikten Zeitfenster (wie an der Uni üblich) erledigt werden sollen, äußerst wünschenswert ist.

Im Anschluss daran ist eine Anwendung entwickelt worden, in der Lichtsensoren, Farbsensoren, Berührungssensoren, Ultraschallsensoren und Servomotoren simuliert werden können. Diese können flexibel innerhalb von aus Lego Komponenten gebauten Systemen integriert werden.

 

Motoren:

Bei der Umsetzung Motoren wurde auf Physikdetails (Erzeugung der Drehbewegung, Übertragung mittels Getriebe ect.) verzichtet und die Auswirkung der Motoren auf das Model fokussiert. Dabei wurde zwischen „Modell-Bewegungs-Motoren“ (Bereits implementiertes Feature; Motoren, die eine Bewegung des kompletten Modelles auf der x,z Ebene bewirken) und „Interne-Bewegungs-Motoren“ (Noch nicht implementiert; Motoren die Bewegungen innerhalb des Modelles bewirken – z. B. das Ausfahren des Arms eines Krans – sind dann interessant, wenn die Position von Sensoren durch die Bewegung beeinträchtigt werden).

 

Ultraschallsensoren:

Ultraschallsensoren wurden mithilfe eines einstellbaren (Abstand der einzelnen Rays, Öffnungswinkel des Kegels, Abtastrate ect.) Raycasting-Kegels umgesetzt. Die Evaluation der Rays bzw. die daraus zu erfolgende Bestimmung des Sensorwertes orientiert sich an den Messwerten von: ftp://ftp.tik.ee.ethz.ch/pub/students/2006-So/SA-2006-18.pdf

 

Lichtsensoren/Farbsensoren:

Wirklich brauchbare Evaluationsergebnisse für die Lichtsensoren und Farbsensoren lagen zum Zeitpunkt der Implementierung nicht vor. Als Problem hat sich dabei herausgestellt, dass sich die Farbe/Helligkeit von Polygonen, nicht durch ein einfaches Raycasting bestimmen lässt – die exakten Farb- und Helligkeitswerte liegen, befingt durch die LWJGL & OpenGL-Technologie auf der Grafikkarte und sind für den Entwickler grundsätzlich nicht zugänglich. Daher wurden Licht und Farbsensoren als Off-Screen-Szenenrenderer implementiert, bei dem die gerenderte Projektion mittels Offscreenshot (:-)) in den Hauptspeicher kopiert wird. Dieser zwar sehr exakte und allgemeine Sensor wirkt sich (nach ersten Erfahrungswerten) noch nicht negativ auf die Performance aus. Im Zweifelsfall wird noch ein weiterer Lichtsensor implementiert, der schneller, jedoch auf die Verfolgung von Fahrstraßen spezialisiert ist.

 

Berührungssensor:

Der Berührungssensor wurde als Kollisionslistener und -erkenner umgesetzt. Physikalische Details (Druckkraft, Druckwinkel) wurden dabei ignoriert. Er ist primär passiv bzw. arbeitet nur dann, wenn es eine Kollision im Szenario gegeben hat – unabhängig davon ob der Sensor selbst daran beteiligt ist. Die Arbeit des Sensors besteht darin herauszufinden, ob er selbst an einer der registrierten Kollision beteiligt gewesen ist. Intuitiv ist er daher effizient, wenn es wenige Kollisionen im Szenario gibt. Für Szenarien mit vielen Kollisionen wird eventuell ein weiterer Berührungssensor (basierend auf Raycastingtechnik), implementiert.

Für die simulierbaren Komponenten gibt es außerdem einige Spekrum an Konfigurationsparametern (Fehler, Abtastrate, Auflösung ect.). Außerdem verfügt die Anwendung über eine Ladefunktion, mit der Szenarien im XML-Format geladen werden können. Außerdem ist zu einem gewissen Maß Szenariomanipulation (Objekte hinzufügen/entfernen, Modelle hinzufügen/entfernen) und Simulationskontrolle möglich (manuelles Starten, Pausieren, Fortsetzen, Zurücksetzen, Stoppen und Löschen von primitiven Szeneobjekten und Modellen – sowohl einzeln als auch für alle Modelle/Objekte). Kontinuierliches Rendering, Kollisionserkennung, Kontrolle der Kameraposition werden unterstützt.

 

Advertisements

NeXTsim – Entwurf und Entwicklung einer Simulationssoftware für NXT-basierte LEGO Mindstorms Systeme

6 Nov

Im Rahmen meiner Masterarbeit wird die Entwicklung der Simulationssoftware NeXTsim (für Lego Mindstorms Systeme) begonnen.
Die Software wird voraussichtlich aus vier Komponenten bestehen:

  1. Simulationsumgebung: 3D-Visualisierung der Simulation, Umsetzung von Aktorbefehlen, Lesen von Sensorwerten (aus der Szene), Laden + Speichern von Szenarien, einfache Szenarienmanipulation
  2. Emulation: Umgebung zum Schreiben der Steuerungsprogamme + Ausführung der Steuerungsprogramme (Kommunikation mit 4. erforderlich)
  3. Modelleditor: Editor zum Erstellen von Modellen (z. B. Mindstorms-Roboter)
  4. Szenarieneditor: Editor zur Erstellung komplexer Szenen, die den grafischen Ansprüchen der Schüler gerecht wird

Im Rahmen meiner Arbeit wird die Simulationsumgebung und ein Protokoll für die Kommunikation zwischen Emulation und Simulationsumgebung entwickelt.

Es erfolgte bisher eine Einarbeitung in Grundlagen und verwandte Arbeiten. Da durch die Verwendung einer geeigneten 3D-(Game-)Engine auf lange Sicht viel Zeit bei der Implementierung gespart werden kann, wurde außerdem ein Vergleich von 3D-(Game-)Engines durchgeführt.

Verglichen werden:

  • Ardor3D
  • Aviatrix3D
  • Env3D
  • Espresso3D
  • JMonkeyEngine
  • jPCT
  • Xith3D

Als interessant herausgestellt haben sich die JMonkeyEngine, Xith3D und Env3D.

  • JMonkeyEngine: Ist, allem Anschein nach, die am häufigsten empfohlene und verwendete Java basierte Game Engine. Sie verfügt über eine ausfürliche Dokumentation sowie eine vergleichsweise große und aktive Community und unterstützt viele Features die für NeXTsim relevant sind. (Swing kompatibel, Physik, eingebauter Renderer, Applets erstellbar, ect. …)
  • Xith3D: Benutzt als einzige Game-Engine in dem Vergleich die Physikengine JOODE. Alle anderen Engines benutzen (sofern Physik überhaupt unterstützt wird) JBullet.
  • Env3D: Die Spieleentwicklung soll mit Env3D besonders leicht sein. Sie ist für Didaktiker besonders interessant.  Die Engine wurde entwickelt um Schülern/Studenten Programmiertechnik zu vermitteln: durch die Entwicklung von Spielen.

3D Szene = Virtuelle 3D Welt
Modell = ein virtuelles aus Lego (Mindstorms) Komponenten aufgebautes System, das über in der Regel einen NXT-Baustein verfügt und daran angeschlossene Aktoren und Sensoren
Szenario = 3D Szene + darin platzierte Modelle