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.
Studentenblogs DDI@UPB 