Archive | November, 2012

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.

 

IKNOW-ANALYSE

23 Nov

In diesem Beitrag stelle ich kurz das Thema der Masterarbeit vor und gehe auf den Abschnitt der Datenbereinigung ein.

  • Was ist das Thema der Masterarbeit?

Analyse des IKNOW Forschungsnetzwerkes und Visualisierung von Forschungstrends – Datenbereinigung, Analyse mit Trenderkennung und Visualisierung

In meiner Masterarbeit beschäftige ich mich mit der Analyse der eingereichten Paper der Konferenz IKNOW.
Weiterhin sollen die Ergebnisse grafisch dargestellt werden.

Datenbereinigung

  • Warum ist das nötig?

Um aussagekräftige Analysen mit korrekten Daten zu erhalten, müssen die Quelldaten eine möglichst hohe Qualität aufweisen.
Durch die automatische Erkennung des KnowAAN-Tools ist diese Qualität nicht gewährleistet.
Eine manuelle Datenbereinigung erhöht die Qualität der Daten und ermöglicht erst Auswertungen zum Inhalt der vorhandenen Konferenzpaper.

  • Welche Daten sind vorhanden?

Die IKNOW-Konferenz hat bisher jährlich von 2001-2012 stattgefunden.
Die vorhandenen, eingereichten Paper wurden in das KnowAAN-Tool, das durch die PG KnowAAN erstellt wurde, geladen.
Bisher sind insgesamt 622 Paper im System.
Diese können mit dem KnowAAN-Documentbrowser exploriert, und mit einer Editionsmaske bearbeitet werden.
Weitere Paper sind auf den Konferenzseiten aufgeführt, konnten aber noch nicht in das System geladen werden.
Die Konferenzseite zählt zusammen 663 Paper auf.

  • Aufwandsschätzung im Vorfeld:

Um den Aufwand für die manuelle Datenbereinigung abzuschätzen, wurde die folgende Rechnung erstellt.
Bei einem Paper werden die Kopfdaten und die Referenzen bearbeitet.
Als Schätzung wurden 10 Minuten für die Kopfdaten und 20 Minuten für die Referenzen pro Paper angenommen.
Dabei werden 20 Referenzen pro Paper vermutet und jeweils 1 Minute pro Referenz gerechnet.
Bearbeitung gesamt: 30 Min. / Paper

Bei einer maximal geplanten Bearbeitungszeit zur Datenbereinigung von 2-2.5 Monaten steht folgende Zeit zur Verfügung.
Arbeitszeit: 6 Stunden / Tag ; 5 Tage / Woche (Mehr Zeit kann hier für diese Aufgabe nicht eingesetzt werden, da die Konzentration nachlässt und Fehler entstehen.)
12 Paper / Tag
60 Paper / Woche
in 10 Wochen sind somit 600 Paper bearbeitbar

Vorgehen:
Aufteilen der Korrekturen in 2 Phasen / Durchläufe.
Phase 1: Kopfdaten bereinigen
Phase 2: Referenzen bereinigen

Nachteil: Jedes Paper wird doppelt bearbeitet.
Vorteil: Man erhält schneller einen Überblick über alle Paper, da die kürzere Aufgabe zunächst für alle Paper durchgeführt wird.
Als Folge können mögliche Probleme eher erkannt werden und der weitere Aufwand kann besser abgeschätzt werden.

 

  • PHASE 1: Kopfdaten bereinigen umfasst: Titel, Name Autor(en), Arbeitsstelle Autor(en), Ort der Arbeitsstelle, Schlüsselwörter, Jahr der Konferenz.

Die Arbeit mit 2 Bildschirmen (Editiermaske, Paper als PDF) ist sinnvoll.
Die Paper sollten der Reihenfolge nach bearbeitet werden.
Die Sortierung nach Jahr und eine alphabetische Sortierung innerhalb eines Jahres hat sich als sinnvoll erwiesen.
Man sollte hierbei mit den früheren Jahren beginnen, da man bei Papern aus späteren Jahren auf bereits korrigierte Paper aus früheren Jahren zurückgreifen kann.
Die bearbeiteten Paper sollte man sich merken/notieren.

Bei den Kopfdaten soll der Ort der Arbeitsstelle für jeden Autor erfasst werden.
Die Ortsangaben werden für Kartenansichten benötigt, die die Herkunft der Autoren darstellen.
Als Genauigkeitsmaßstab werden im Allgemeinen die Stadt und das Land angegeben.
In einigen Papern ist die Stadt jedoch nicht angegeben.
Hier ist eine zusätzliche Recherche erforderlich (mit Autor und Firma).
Die Angaben zu Abkürzungen von Kategorien werden als Schlüsselwörter mit aufgenommen.

Die Korrektureingabemaske ermöglicht die Speicherung erst dann, wenn alle Pflichtfelder gefüllt sind.
Durch fehlerhafte Erkennung in der automatischen Vorverarbeitung der Paper ist es möglich, dass die Referenzen nicht in einem „korrekten“ Zustand sind.
Daher werden die vorhandenen, erkannten Referenzen soweit korrigiert, dass diese Änderungen gespeichert werden können.

 

 

SuTeCo – People Tagging

23 Nov

Ein weiteres Konzept, das im Rahmen meiner Masterarbeit implementiert werden soll, ist das „People Tagging“.

Jeder Benutzer der Web-Applikation SuTeCo soll die Möglichkeit haben, einen anderen Benutzer dieser Applikation mit Schlagwörtern zu versehen bzw. zu taggen.  Außerdem soll es möglich sein, sowohl eigene als auch Follow-Gruppen zu taggen.

Die entstandene Datenbank mit Tags wird später für die Suche nach Ansprechpartnern bzw. deren Kompetenzen eingesetzt. Weiterlesen

SuTeCo – Gruppenverwaltung

8 Nov

Im nächsten Schritt wird die Implementierung der Schnittstelle für das Gruppenmanagement umgesetzt. Diese Seite ermöglicht dem Benutzer die Verwaltung von eigenen Gruppen sowie von Gruppen, denen er folgt. Es werden folgende Grundfunktionen realisiert:

  • Anzeige von eigenen Gruppen und Followed-Gruppen sowie deren Beschreibungen
  • Erstellen / Löschen eigener Gruppen
  • Folgen / Entfolgen von Gruppen
  • Einfügen / Löschen neuer Benutzer
  • Taggen von Gruppen

Wie in Abbildung 1 zu sehen, soll die Seite des Gruppenmanagements alle eigenen und Follow-Gruppen in Kreisform darstellen. Im rechten Seitenbereich werden detaillierte Informationen über die jeweils ausgewählte Gruppe dargestellt. Das Steuerungspanel mit den Buttons „Gruppe anlegen“ oder „Gruppe löschen“ wird nach vielen Überlegungen nicht hier platziert, da es aus Usability-Gründen nicht hierher passt. Die anderen Elemente der Benutzeroberfläche bleiben an der Stelle, wo sie geplant war. Weiterlesen

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