Filtern
Erscheinungsjahr
- 2008 (26) (entfernen)
Dokumenttyp
- Studienarbeit (26) (entfernen)
Schlagworte
- E-IMS (2)
- Programmierung (2)
- Robotik (2)
- VNUML (2)
- 3D-Modell (1)
- ATMega 16 (1)
- ATmega644 (1)
- ATtiny2313 (1)
- Abfragesprache (1)
- Anwendungssoftware (1)
Im Rahmen dieser Studienarbeit wurde ein Faktenextraktor für Java-Quelltexte entwickelt. Der Javaextraktor generiert eine TGraph-Repräsentation der Quelltexte eines in Java implementierten Softwareprojekts. Dieser TGraph ist dann durch dieWerkzeuge des Gupro-Projekts weiter verarbeitbar. Der Javaextraktor kann Javaquelltexte bis einschließlich Javaversion 6 verarbeiten. Dazu wurde ein Werkzeug gefunden, welches den Parsingvorgang übernimmt, so dass diese Funktion nicht selbst implementiert werden musste. Zusätzlich wurde ein Javametamodell und entsprechendes Schema für den TGraph entwickelt. Die Knoten- und Kantentypen des Metamodells konnten automatisiert mit JGraLab aus dem Schema erzeugt werden.
IPv6 Autokonfiguration
(2008)
Diese Studienarbeit stellt verschiedene Möglichkeiten der automatischen Konfiguration von Netzwerkknoten unter IPv6, dem designierten Nachfolger des Internetprotokolls, vor. Dabei wird recht ausführlich in IPv6-Netzwerke eingeführt, wobei aber vorausgesetzt wird, dass der Leser Kenntnisse über das IP-Protokoll der Version 4 hat. Es werden sowohl die zustandslose als auch DHCPv6 ausführlich in der Theorie als auch im praktischen Einsatz gezeigt. Dafür wird das VNUML-System eingesetzt, das an der Technischen Universität Madrid entwickelt wurde und das es ermöglicht, mehrere Linuxsysteme auf einem Wirtsrechner zu simulieren.
Große Gebiete lassen sich auf Grund von Schattenbildung und begrenzter Scanreichweite nicht mit einem einzigen 3D-Scan aufnehmen. Um konsistente dreidimensionale Karten dieses Gebietes zu erzeugen müssen also mehrere Scans zusammengefügt werden. Soll dieses Matchen der Scans automatisch geschehen, so kann es wegen fehlerhaften Translations- und Rotationsdaten, die die unterschiedlichen Positionen der Scans beschreiben,zu inkonsistenten Karten kommen. Um dies zu vermeiden wird in dieser Arbeit ein schneller Iterativ Closest Points Algorithmus implementiert, der versucht, Fehler in diesen sechs Freiheitsgraden zu korrigieren. Das Verfahren soll im Rahmen dieser Arbeit in die schon vorhandene Software unseres Roboters eingebunden werden.
In dieser Studienarbeit wurde ein Algorithmus vorgestellt, um sich mit einem Roboter in unbekanntem Gebiet zu lokalisieren und gleichzeitig eine Karte von der Umgebung zu erstellen. Die Lokalisation des Roboters geschieht auf 2D Ebene und errechnet die (x, y, θ)T Position des Roboters zu jedem Zeitpunt t inkrementell. Der Algorithmus baut auf dem FastSLAM 2.0 Algorithmus auf und wurde abgeändert, um eine möglichst genaue Lokalisation in Gebäuden zu ermöglichen. Hierfür wurden mehrere verschieden Arten von möglichen Landmarken untersucht, verglichen und kombiniert. Schwerpunkt dieser Studienarbeit war das Einarbeiten in das Extended Kalman-Filter und die Selektion von Landmarken, die für den Einsatz in Gebäuden geeignet sind.
GreQL-Script
(2008)
Im Rahmen dieser Arbeit wird eine Scriptsprache entworfen und ein Interpreter für diese implementiert. Sie ist der Nachfolger der von Bernt Kullbach entwickelten Scriptsprache Command Line GreQL (CLG) und soll die Arbeit mit TGraphen und mit der von Katrin Marchewka in ihrer Diplomarbeit beschriebenen Graphanfragesprache Graph Repository Query Language 2 (GReQL 2) vereinfachen.
Die Siedlungsgeschichte im Rhein-Mosel-Dreieck reicht zurück bis in die römische Zeit. Entlang der beiden großen Flüsse finden sich zahlreiche Beispiele historischer Architektur. In diese Kategorie lässt sich auch die ehemalige Burganlage im Kondertal einordnen, die sich auf dem Nordwest-Ausläufer des Hinterberges befindet. Um eine genauere Vorstellung der Burganlage zu erhalten, sollte ein Computermodell erstellt werden. Die praktische Umsetzung dieses Modells ist Thema der vorliegenden Studienarbeit. Von der Erstellung eines "einfachen 3D-Modells" mittels einer dazu mächtigen Software kam man schnell ab. Stattdessen sollte das Ziel der Arbeit ein Programm sein, dass es dem Benutzer ermöglicht die Burganlage interaktiv aufzubauen und in beliebiger Form zu verändern.
Das Forschungsprojekt Bildanalyse zur Ornamentklassifikation hat es sich zur Aufgabe gemacht, ornamentale Strukturen in Bildern computergestützt zu lokalisieren, analysieren und klassifizieren. Grundlage des Projekts bildet eine umfangreiche Bilddatenbank, deren Abbildungen manuell vorsortiert sind. Durch Kombinationen mit Methoden der Bildverabeitung und der Verwendung von Wissensdatenbanken (Knowledge Databases) soll diese Kategorisierung weiter verfeinert werden. Sämtliche Bilder durchlaufen bis zum Prozess der Ornamentklassifikation mehrere Vorverarbeitungsschritte. Beginnend mit einem Normalisierungsprozess, bei dem das Bild u. a. entzerrt und entrauscht wird, werden im Anschluss Interessensregionen selektiert. Diese Regionen bilden die Grundlage für das spätere Lokalisieren der Ornamente. Aus ihnen werden mit unterschiedlichen Verfahren Merkmale extrahiert, die wiederum in der Datenbank gespeichert werden. In dieser Arbeit wurde ein weiteres solches Verfahren implementiert und auf seine mögliche Verwendung in dem Projekt untersucht.
Im Rahmen dieser Studienarbeit wurden acht verschiedene Algorithmen unterschiedlichen Umfangs und Komplexität zur Pupillenmittelpunktssuche implementiert und im Vergleich mit dem Originalalgorithmus ausgewertet. Die Berechnung des Hornhautreflektionsmittelpunkts wurde modifiziert, so dass die Helligkeitswerte der Hornhautreflektion bei der Berechnung des Schwerpunkts gewichtet werden. Bei der Auswertung wurde festgestellt, dass drei der acht Algorithmen, der Starburst-Algorithmus für hochauflösende Bilder, Daugmans Algorithmus für Aufnahmen bei sichtbarem Licht und der Average Coordinate Algorithmus von Daunys und Ramanauskas, Mängel in Zusammenhang mit dem gegebenen System aufweisen, so dass diese momentan nicht für die Mittelpunktssuche im Gazetracker geeignet sind. Die restlichen Algorithmen zeigten im grafischen Vergleich ähnlich gute Ergebnisse und wurden im Test verglichen, wobei der Algorithmus von Perez, Garcia, Mendez, Munoz, Pedraza und Sanches und der Algorithmus von Poursaberi und Araabi die besten Ergebnisse aufwiesen in Bezug auf Dichte der Punkte, Fehlerpunkte und Outlier.
Ziel dieser Studienarbeit war es, Erfahrungen in der Grafik- und Spieleprogrammierung zu sammeln. Als Grundidee kam dabei die Erstellung eines 3-dimensionalen Terrains auf. Solche Terrains werden heutzutage nicht nur in der Spielebranche eingesetzt, wo sie in beinahe jedem Genre vertreten sind, sondern auch z.B. in der Geologie zur Erstellung von Simulationen von Plattentektonik. Die simple Erstellung eines 3-dimensionalen Terrains wäre für eine Studienarbeit jedoch zu trivial, daher sollte das Terrain spezielle Anforderungen erfüllen. Zum einen sollte das Terrain dynamisch erzeugt werden, d.h. der Benutzer des Programms hat Einfluss darauf, wie sich das Terrain entwickelt. Dies sollte vorzugsweise spielerisch eingebracht werden. Zum anderen sollte das Terrain zufällig generiert werden. Dies bedeutet, dass keine vormodellierte Landschaft genutzt, sondern jede Erhebung/- Vertiefung des Terrains mittels Zufallsfaktoren erzeugt werden sollte. Zusätzlich sollte das Terrain endlos erzeugt werden. Bei einer Bewegung über das Terrain sollte also niemals ein Ende erreicht werden. Also auch keine Kreistrecke, sondern ein wirklich endloses und stets anders aussehendes Terrain. Desweiteren sollte es dem Benutzer møglich sein, ein Fluggerät über das Terrain zu steuern. Dies gab dann auch die Chance, aus der oben genannten dynamischen Anforderung ein spielerisches Element zu machen, indem der Benutzer das Terrain durch Einsammeln von sogenannten TerraformItems beeinflussen kann. Die Steuerung eines Fluggerätes spielt auch für die geforderte Endlosigkeit des Terrains eine wichtige Rolle, da diese ohne eine Möglichkeit der Fortbewegung gar nicht nachprüfbar wäre. Das Problem mit der Endlosigkeit ist dabei, dass kein System endlosen Speicher zur Verfügung hat um das Terrain komplett zu speichern und dem Benutzer somit die Option zu bieten, die gleiche Strecke zurückzufliegen. Eine Lösung für diese Problematik wäre bei einer Kehrtwende das Terrain auch rückwärts wieder neu zu generieren. Der Einfachheit halber sollte stattdessen ein komplette Kehrtwende einfach nicht zugelassen werden. Eine Kollisionserkennung musste dann natürlich auch implementiert werden. Zum einen weil das Fluggerät ja nicht einfach wie ein Geist durch das Terrain hindurchgleiten sollte, zum anderen muss das Programm ja irgendwie das Einsammeln der oben angesprochenen TerraformItem-Objekte registrieren können. Weitere Objekte wie Bäume oder Felsen sollten das Terrain optisch aufwerten. Zu guter Letzt sollte noch eine simple Benutzeroberfläche erstellt werden, um dem Benutzer diverse Bedienelemente und Rückmeldungen zu bieten. Damit sollte es z.B. auch möglich sein dass Terrain direkt zu verändern.