Commit dde58329 by wester

Merge branch 'master' of ssh://git.breab.org:2223/kai/MasterArbeit

# Conflicts: # Ausarbeitung/07Evaluation.tex
parents 0ea18d81 e1c9be1f
Pipeline #339 passed with stage
in 1 minute 36 seconds
......@@ -29,42 +29,43 @@ Diese werden anschließend in der Hololens relativ zum Welt Anker visualisiert.
\section{Kalibrierung}
Die Kalibrierung erfolgt anhand des Weltankers und eines Vive Trackers.
Der Weltanker orientiert sich an dem erkannten Boden, sodass die y Achse senkrecht nach oben zeigt.
Um die beiden Welten zu synchronisieren wird ein Vive Tracker so platziert, das die beiden Koordinatensysteme übereinstimmen (Siehe Abb. \ref{img:holokalib})
Hierfür wurde an dem Tracker ein 3D gedruckte Hilfe angebraucht um die aktuelle Rotation besser erkennen zu können.
Durch einen Tastenduck auf einen Controller wird d ie aktuelle Rotation und Position des Trackers in der Unreal Engine gespeichert.
Um die beiden Welten zu synchronisieren, wird ein Vive Tracker so platziert, dass die beiden Koordinatensysteme übereinstimmen (siehe Abb. \ref{img:holokalib})
Hierfür wurde an dem Tracker eine 3D gedruckte Hilfe angebracht, um die aktuelle Rotation besser erkennen zu können.
Durch einen Tastendruck auf einen Controller wird die aktuelle Rotation und Position des Trackers in der Unreal Engine gespeichert.
Mit dieser Transformation kann der Strahl der VR Umgebung in das lokale Koordinatensystem des Weltankers transformiert werden.
\begin{figure}
\begin{center}
\label{img:holokalib}
\includegraphics[width=\textwidth]{Bilder/HoloLens/Kalib.jpg}
\caption{Mixed Reality Capture der Hololens. Zu sehen ist das Koordinatenkruz und der Vive Tracker. Am Tracker ist das 3D gedruckte Hilfe zu sehen. }
\caption{Mixed Reality Capture der Hololens. Zu sehen ist das Koordinatenkreuz und der Vive Tracker. Am Tracker ist die 3D gedruckte Hilfe zu sehen. }
\end{center}
\end{figure}
\subsection{Kalibrierungsfehler}
Diese Art der Klibrierung ist einfach, aber an mehrerehn stellen Fehelranfällig mit der aktuellen Hardware.
Diese Art der Kalibrierung ist einfach, aber mit der aktuellen Hardware an mehreren Stellen fehleranfällig.
Das erste Problem ist die menschliche Ungenauigkeit.
Den Tracker muss exakt an die richtige Postion mit der richtigen Rotation gelegt werden.
Dabei ist das Hologram direkt über dem Tracker, verdeckt diesen und erschwert damit das exakte Positionieren
Insbesondere die Rotation ist bei der Rotation ein Problem.
Eine kleiner Rotationsfehler wirkt sich weiter entfernt vom Ursprung stark auf die Kallibrierung aus.
Der Tracker muss exakt an die richtige Postion mit der richtigen Rotation gelegt werden.
Dabei ist das Hologramm direkt über dem Tracker, verdeckt diesen und erschwert damit das exakte Positionieren.
Insbesondere die Rotation ist bei der Kalibrierung ein Problem.
Eine kleiner Rotationsfehler wirkt sich weiter entfernt vom Ursprung stark auf die Kalibrierung aus.
Zum Beispiel bringt ein Fehler von 1\degree bei 2m Distanz eine Verschiebung von 3,4cm $(distance (rotate(1^{\circ}, (2,10)) (2,0))$.
\todo{check distance}
Zu den Menschlichen Fehlern kommen Ungenauigkeiten vom Vive Tracking und dem Hololens Tracking.
Zum einen verschiebt sich der Hololens Ursprung manchmal leicht wenn er nicht direkt angeschaut wird.
Durch erneutes Ansehen der Ursprungsumgebung fängt sich dieser meistens wieder und wird zurück auf die Ursprüngliche Position gesetzt.
Aber es konnten sehr vereinzelnd Dauerhafte Verschiebungen beobachtet werden.
Im Extrafall waren ca.10cm nach unten zu beobachten.
Ein Weiterer Faktor sind die Ungenauigkeiten im Vive Tracking.
Insbesondere sind hierbei die Längen unterscheide zwischen Echtwelt und Virtueller Welt gewesen.
Zu den menschlichen Fehlern kommen Ungenauigkeiten vom Vive Tracking und dem HoloLens Tracking.
Zum einen verschiebt sich der HoloLens Ursprung manchmal leicht, wenn er nicht direkt angeschaut wird.
Dies ist bedingt durch das Inside-out Tracking der Hololens.
Durch erneutes Ansehen der Ursprungsumgebung wird dieser dieser meistens wiedererkannt und wird zurück auf die ursprüngliche Position gesetzt.
Aber es konnten sehr vereinzelt dauerhafte Verschiebungen beobachtet werden.
Im Extremfall waren ca. 10cm nach unten zu beobachten.
Ein weiterer Faktor sind die Ungenauigkeiten im Vive Tracking.
Problematisch sind hierbei insbesonders die Längenunterschiede zwischen Echtwelt und Virtueller Welt gewesen.
In dem verwendeten Setup wurde ein 2m Zollstock mit einem Vive Controller vermessen.
Dabei war die in VR gemessene Distanz 1,98m.
Dieser Fehler wirkt sich direkt auf das Zusammenspiel der Vive und Hololens aus.
Wird der Controller 2m vom Ursprung weg bewegt, dann bewegt sich der Beam nur um 1,98 in VR udn damit AR und entfernt sich damit von seiner eigentlichen Position.
In der Implementierung wurde das versucht auszugleichen indem alle Werte die per UDP versendet werden mit dem Faktor 1,025 skaliert wurden.
Dieser Fehler wirkt sich direkt auf das Zusammenspiel der Vive und HoloLens aus.
Wird der Controller 2m vom Ursprung weg bewegt, dann bewegt sich der Beam nur um 1,98 in VR und damit entfernt sich auch der Beam in der AR Visualisierung von seiner eigentlichen Position.
In der Implementierung wurde versucht das auszugleichen, indem alle Werte, die per UDP versendet werden, mit dem Faktor 1,025 skaliert wurden.
Der Wert wurde experimentell bestimmt.
\todo{Bidler}
......@@ -72,26 +73,10 @@ Der Wert wurde experimentell bestimmt.
\section{Ergebnisse}
Die Kalibrierung funktioniert, ist aber nicht schnell und fehlerfrei umsetzbar.
Bis die Kalibrierung vollständig stimmt muss der Prozess teilweise ein paar mal wiederholt und getestet werden.
Nahe an dem Weltanker erreicht das umgesetzte Tool den gewünschten Effekt den Laser an den Vive Controller zu hängen.
Bis die Kalibrierung vollständig stimmt, muss der Prozess teilweise ein paar Mal wiederholt und getestet werden.
Nahe an dem Weltanker erreicht das umgesetzte Tool den gewünschten Effekt, den Laser an den Vive Controller zu hängen.
Entfernt man sich von diesem Punkt, wird das Tracking immer schlechter und die Fehler werden sichtbarer.
Für die Evaluation wurde die VR Umgebung verschoben um getrennte Ort zu simulieren.
Für die Evaluation wurde die VR Umgebung verschoben, um getrennte Ort zu simulieren.
Damit der Fehler möglichst klein bleibt und keinen großen Einfluss auf die Evaluation hat wurde die Verschiebung so klein wie möglich gehalten (1.5m).
\chapter{Evaluation}
\label{chapter:07Evaluation}
Das grundlegende Szenario das Evaluiert wird spielt zwischen einem Lokalen Nutzer (häufig auch Techniker) und einem Experten der remote zugeschaltet werden soll.
Der lokale Nutzer hat ein Hardware Problem und der Experte das Fachwissen um das Problem zu lösen.
Der allgemeine Ablauf bei so einem Szenario ist das der Lokale Nutzer zunächst Daten aufnimmt und dem Experten zur Vorberitung sendet.
Anschließend lösen die beiden in gemeinsam das Porblem.
Das grundlegende Szenario das evaluiert wird, spielt zwischen einem lokalen Nutzer (häufig auch Techniker) und einem Experten der remote zugeschaltet werden soll.
Der lokale Nutzer hat ein Hardwareproblem und der Experte das Fachwissen, um das Problem zu lösen.
Der allgemeine Ablauf bei so einem Szenario ist, dass der lokale Nutzer zunächst Daten aufnimmt und dem Experten zur Vorbereitung sendet.
Anschließend lösen die beiden gemeinsam das Problem.
Als Vorbereitung kann der lokale Nutzer eine Punktwolke aufnehmen und diese dem Experten senden.
Dieser kann sich die Punktwolke in einer VR Umgebung anschauen und mit seinem Controller und dem daran befestigten Laser auf die Punktwolke zeigen.
Der lokale Nutzer bekommt in seiner AR Brille den Laser an der zugehörigen realen Position visualisiert.
So kann der Experte auf die Punktwolkenrepräsentation des Objekts zeigen und der lokale Nutzer die in echt auch mit.
So kann der Experte auf die Punktwolkenrepräsentation des Objekts zeigen und der lokale Nutzer sieht diese Zeigegeste am echten Objekt.
Als Referenz Szenario wurde ein Videostream gewählt. Als Vorbereitung sendet der lokale Nutzer Bilder an den Experten und bei der Zusammenarbeit stand ein.
Als Referenzszenario wurde ein Videostream gewählt. Als Vorbereitung sendet der lokale Nutzer Bilder an den Experten und bei der Zusammenarbeit stand ein Videostream zur Verfügung.
\section{Versuchsaufbau}
Das Hardwareporblem wurde idn der Evaluation durch Duplopsteine simuliert.
Das Hardwareproblem wurde in der Evaluation durch Duplosteine simuliert.
Aus den Steinen wurde insgesamt 2 Turmpaare aus 2 relativ ähnlichen Türmen gebaut.
\todo{Todo Bilder von beiden Turmpaaren auf dem Tisch}
In den Türmen wurden die Farben durch gewechselt, sodass jeder Turm insgesamt 13 farbige Ebenen hat.
Jeder Farbe wurde mit einer eindeutigen kleinen Beschriftung versehen bestehend aus einem Buchstaben und einer Zahl.
Diese Beschriftung kann dazu verwendet werden ob bei einem Versuch der Richtige Stein erkannt.
Des weiterem wurde darauf geachtet das in jedem Turmpaar eine Farbsequenz von 4 aneinandergrenzenden Farben eindeutig ist.
In den Türmen wurden verschiedene Farben benutzt, sodass jeder Turm insgesamt 13 farbige Ebenen hat.
Jede Farbe wurde mit einer eindeutigen kleinen Beschriftung versehen, bestehend aus einem Buchstaben und einer Zahl.
Diese Beschriftung kann dazu verwendet werden um die Korrektheit bei einem Experimentdurchlauf zu überprüfen.
Des weiterem wurde darauf geachtet, dass in jedem Turmpaar eine Farbsequenz von 4 aneinander grenzenden Farben eindeutig ist.
Hierbei sollten sich die Türme aber möglichst ähnlich sein um die Aufgabe zu erschweren.
Auf einem fahrbaren Tisch wurden für beide Turmpaare Maskierungen angebracht, damit diese immer an der gleichen Position auf dem Tisch stehen.
Für das VR Scenario wurde zusätzlich ein Vive Tracker auf dem Tisch platziert.
Damit ist es möglich das Objekt auch in der virtuellen Welt zu tracken und richtig zu positionieren.
Hierfür wurde zunächst beim aufnehmen der Punktwolke diese in das Lokale Koordinatensystem des Trackers transformiert, und beim visualisieren die aktuelle Transformation des Trackers hinzugefügt.
Damit bei der Durchführung die echte Welt nicht komplett mit der virtuellen synchronisiert ist, wird die Virtuelle Welt um einen konstanten Vektor verschoben.
Diese Verschiebung wird vor dem senden der Daten an die Hololens wieder raus gerechnet.
In der Evalution wurde dafür eine Verschiebung entlang der negativen X-Achse des Trackers um 1,5m gewählt.
Die Distanz wurde versucht möglichst klein zu halten um Trackingungenauigkeiten nicht zu verstärken.
Für das VR Szenario wurde zusätzlich ein Vive Tracker auf dem Tisch platziert.
Damit ist es möglich, das Objekt auch in der virtuellen Welt zu tracken und richtig zu positionieren.
Hierfür wurde zunächst beim Aufnehmen der Punktwolke diese in das lokale Koordinatensystem des Trackers transformiert, und beim Visualisieren die aktuelle Transformation des Trackers hinzugefügt.
Damit bei der Durchführung die echte Welt nicht komplett mit der virtuellen synchronisiert ist, wird die virtuelle Welt um einen konstanten Vektor verschoben.
Stehen Lokaler Nutzer und Experte am selbem Objekt, könnte der Lokale Nutzer zum Beispiel aus der Handbewegung Rückschlüsse ziehen die das Ergebniss verfälschen.
Diese Verschiebung wird vor dem Senden der Daten an die HoloLens wieder heraus gerechnet.
In der Evaluation wurde dafür eine Verschiebung um 1,5m entlang der negativen X-Achse des Trackers gewählt.
Diese Distanz wurde möglichst klein gehalten, um Trackingungenauigkeiten nicht zu verstärken.
Für das Video Szenario wurde die App IP Webcam genutzt. Diese stellt den Videostrem einer Handykamera als Webstream zur Verfügung.
Für das Videoszenario wurde die Handy-App IP Webcam genutzt. Diese stellt den Videostream einer Handykamera als Webstream zur Verfügung.
Der Experte kann diesen dann am PC anschauen.
\subsection{Punktwolken}
Für die Evaluation wurde auf das Aufnehmen von Punktwolken durch die Probanden verzichtet.
Die Methode die Kinect mit dem Lighthose Tracking zu verbinden liefert zu ungenaue Wolken.
Deshalb wurden im nur statische Punktwolken verwendet die vorher aufgenommen wurden und per Hand nachbearbeitet wurden.
Diese Limitierung führt dazu das die Türme nicht umgebaut werden könne und nur statisch betrachtet wurden.
Die Methode die Kinect mit dem Lighthouse Tracking zu verbinden, liefert zu ungenaue Wolken.
Deshalb wurden nur statische Punktwolken verwendet, die vorher aufgenommen wurden und per Hand nachbearbeitet wurden.
Diese Limitierung führt dazu, dass die Türme nicht umgebaut werden können und nur statisch betrachtet wurden.
Für das Videoszenario wurden im voraus Bilder aufgenommen, die dem Experten bei der Vorbereitung zur Verfügung stehen.
\section{Versuchsablauf}
......@@ -47,7 +48,7 @@ In einem echten Szenario hat der Experte bereits alles benötigte Wissen im Vorf
Bei der Evaluation müssen aber alle Probanden in beiden Szenarien das gleiche Wissen erhalten.
Das Vorwissen wurde durch die eindeutigen Farbsequenzen simuliert.
Ein Test in beiden Szenarien besteht aus 15 Durchläufen der gleichen Aufgabenbescheibung.
Ein Test in beiden Szenarien besteht aus 15 Durchläufen der gleichen Aufgabenbeschreibung.
Bei einem Durchlauf erhält der Experte eine Aufgabe.
Diese Aufgabe ist eine eine Farbsequenz von oben nach unten von 4 aufeinanderfolgenden Farben.
Am Anfang oder Ende der Farbsequenz ist ein zusätzlicher gesuchter Stein markiert.
......@@ -92,7 +93,7 @@ Meißt Ordinale Daten ->median QUard
Zeitdaten metrisch Mittelwert udn Standartabweichung
Signifikanztest
Abhängig paaren aaka vr udn ar
Abhängig paaren aka vr udn ar
unabhängig VR mit Video
pwert kleienr als 0.05 -> nullhpothesse verwerfen
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment