Droculus

Aus toolbox_interaktion
Wechseln zu: Navigation, Suche

Einleitung

Das Thema virtuelle Realität spielt in naher Zukunft immer eine größer werdende Rolle. Maschinen ohne direkten Kontakt steuern zu können, wird gerade im gefährlichem Umfeld immer wichtiger. Um diese Fähigkeiten der Ansteuerung zu schulen, haben wir es uns zur Aufgabe gemacht, eine ARDrone mit einer Oculus Rift Brille zu steuern.


Umsetzung

Um die ARDrone mit der Oculus Rift zu steuern, müssen die Sensorausgangsdaten der Oculus Rift in die Dronen Entwicklungsumgebung (SDK) eingelesen und dort verarbeitet werden. Zusätzlich muss der Videostream, den die Dronenkamera erzeugt auf die Oculus Rift übertragen werden. Allerdings ist das Oculus Bild verzerrt, sodass auch unser Videostream vorher verzerrt werden muss.

Konzept 1

Bild Konzept 2-2.JPG

Um bei beiden Komponenten eine Kommunikation herzustellen, kam die Idee auf dies über das OSC-Protokoll laufen zu lassen. Das Konzept schien zunächst sinnvoll, da es so möglich war, beide originalen SDK's (ArDrone und Oculus Rift), die jeweils in einer anderen Programmiersprache geschrieben wurden, ohne Probleme miteinander zu verbinden. Dazu musste in der SDK der Oculus Rift ein Sender mit den Steuerungsdaten programmiert werden und in der SDK der ArDrone ein Empfänger für die Daten programmiert werden. Jedoch gab es dabei ein grundlegendes Problem: Das OSC-Protokoll ist zwar sinnvoll, um zwei verschiedene Welten auf einem Standard kommunizieren zu lassen, da das ganze Projekt somit unabhängiger wird, jedoch unterstütz das OSC-Protokoll lediglich kleine Datenraten. Die Oculus Rift sollte jedoch den Video-Stream in HD-Auflösung der ArDrone erhalten und diesen auf seinem Bildschirm ausgeben. Die Datenraten eines HD-Video-Streams sind deutlich über dem, was über das OSC-Protokoll geschickt werden kann. Somit konnte diese Konzept nicht länger genutzt werden.

Konzept 2

Bild Konzept 1-2.JPG

Das nächste Konzept ist in diesem Hinblick unabhängiger von Datenraten über ein Protkoll, da beide SDK's miteinander verbunden werden sollten. Zunächst gab es eine intensive Suche nach zwei SDK's, die in der gleichen Sprache geschrieben waren. Die originalen SDK's waren einmal in C++(Oculus Rift) und C(ArDrone) geschrieben. Somit konnten die originalen SDK's nicht verwendet werden. Außerdem gab es bei der originalen SDK der ArDrone ein Problem: Die Dokumentation war mangelhaft, bzw. garnicht vorhanden vom Hersteller. Eine sinnvolle SDK der ArDrone in C++ wurde nach einer Recherche im Internet auch nicht gefunden. Deshalb ging die Suche weiter und fand dann schließlich bei der Programmiersprache Java eine Ende. Diese erschien sinnvoll, da Java den Ruf hat, Plattformunabhängig agieren zu können. Zunächst gab es beim kompilieren ein Problem, da beide SDK's beim kompilieren Bibliotheksfehler aufgewiesen haben. Nach entfernen von sämtlichen Bibliotheks- und Kompilerfehler ist es gelungen, die SDK'S zu starten. Sie funktionierten auch wie erwartet. Danach ging die Suche nach den Ausgangsvariablen der Oculus Rift in Java los. Da auch diese Dokumentation nicht sehr ausführlich, bzw. nicht vorhandne war, blieb nicht genug Zeit dieses Problem weiter zu verfolgen. In Zwischenzeit wurden die Eingangsvariablen in der ArDrone gefunden und hätten beschrieben weden können. Da das zweite Konzept erst zum Ende des Semesters angefangen wurde, blieb nicht genug Zeit das Projekt erfolgreich zu beenden.

Status quo

Die richtigen SDK's in der Programmiersprache Java wurden gefunden und konnten einzeln kompiliert werden, jedoch blieb für die Zusammenführung in ein großes Projekt keine Zeit mehr. Auch wurden die Eingangsvariablen in der ArDronen SDK gefunden und können somit auch verändert werden. Die Übertragung des Videostreams als auch die Verzerrung dieses Bildes war von der Zeit her nicht mehr machbar und konnte noch nicht realisiert werden.

Zusammenfassung

Da die richtigen SDK's gefunden wurden und auch kompiliert werden konnten, ist es nur noch eine Frage der Zeit die richtigen Variablen in den SDK's zu finden. Als Empfehlung für die mögliche Nachfolger, die auch die gleiche Idee verfolgen wollen: Die originalen SDK's sind für diese Anwendung nicht empfehlenswert und daher sollte die Idee mit den SDK's in gleicher Programmiersprache (Java) weiter verfolgt werden. Leider wurde mit der Realisierung des ersten Konzepts zu viel Zeit verschenkt und somit blieb nicht genügend Zeit für das zweite (sinnvollere) Konzept.