@@ -15,7 +15,7 @@ Das Bild der Kinect ist perspektivisch und wird beim Errechnen der Punktwolke do
\label{img:KinectSides}
\subfigure[Aufnahme aus Sicht der Kinect ]{\includegraphics[width=0.49\textwidth]{Bilder/1FrameKamera.png}}
\subfigure[Aufnahme von der Seite]{\includegraphics[width=0.49\textwidth]{Bilder/1FrameSeite.png}}
\caption{Aufnahme der Kinect aus verscheidenen Perspectiven. In Bild b) sind falsche Punkte zu sehen, die durch die Rekonstruktion aus einem 2D Bild entstehen.}
\caption{Aufnahme der Kinect aus verschiedenen Perspektiven. In Bild (b) sind falsche Punkte zu sehen, die durch die Rekonstruktion aus einem 2D Bild entstehen.}
\end{figure}
...
...
@@ -28,34 +28,34 @@ Die Trackingdaten aus SteamVR, bzw OpenVR geben uns eine globale Position aller
\section{Frames aufnehmen und bereinigen}
Als ersten Schritt wird ein Frame mit der Kinect aufgenommen und das Tiefeinbild geglättet.
Im ersten Schritt wird ein Frame mit der Kinect aufgenommen und das Tiefenbild geglättet.
Anschließend wird das Tiefen- und Farbbild in 3D Punkte umgewandelt und unerwünschte Punkte verworfen.
\subsection{Aufnahme und Glättung}
Das Aufnehmen einer kleinen Punktwolke wird das Kinect SDK verwendet.
Sowohl Tiefeinbild auch als auch Farbbild kann man aus der API erhalten.
Anschließen wird das Tiefenbild geglättet.
Zum Aufnehmen einer kleinen Punktwolke wird das Kinect SDK verwendet.
Sowohl das Tiefeinbild auch als auch das Farbbild kann man aus der API erhalten.
Anschließend wird das Tiefenbild geglättet.
Die Rohdaten sind teilweise sehr verrauscht und so erhält man eine Punktwolke mit glatteren Flächen.
Hierfür braucht man einen Filter der zwar die Flächen glättet, aber gleichzeitig Objektkanten erhält.
Ein Bilateral Filter erzielt den gewünschten Effekt ist aber relativ Rechenaufwändig.
Verwendet wurde der Filter der in dem Paper \cite{Martin:2014:RTH} vorgestellt wird.
Hierbei wird zunächst das Bild mit einem Gausfilter geglättet.
Dieser ist nicht Kanten erhaltend, deshalb wird das geglättet Bild anschließend mit dem Original verglichen.
Bei zu starker Abweichung vom Original wird der Wert des Pixels au das Original zurückgesetzt.
Hierfür braucht man einen Filter, der zwar die Flächen glättet, aber gleichzeitig die Objektkanten erhält.
Ein Bilateral Filter erzielt den gewünschten Effekt ist aber relativ rechenaufwändig.
Verwendet wurde der Filter, der in dem Paper \cite{Martin:2014:RTH} vorgestellt wird.
Hierbei wird zunächst das Bild mit einem Gauß-Filter geglättet.
Dieser ist nicht kantenerhaltend. Deshalb wird das geglättet Bild anschließend mit dem Original verglichen.
Bei zu starker Abweichung vom Original wird der Wert des Pixels auf das Original zurückgesetzt.
Nach der Glättung des Tiefenbildes wird dieses in eine Punktwolke umgewandelt.
Hierfür wurde ebenfalls das Microsoft Kinect SDK verwendet das alle benötigten Methoden bereitstellt.
Hierfür wurde ebenfalls das Microsoft Kinect SDK verwendet, das alle benötigten Methoden bereitstellt.
Nach der Umwandlung werden noch weiter Punkte verworfen.
Nach der Umwandlung werden noch weitere Punkte verworfen.
Zunächst werden alle Punkte ohne zuordnungsfähige Farbe verworfen.
Auch alle Punkte die zu nah oder zu weit vom Sensor entfernt sind, werden nicht weiter betrachtet.
Je weiter das Objekt entfernt, desto ungenauer werden die Aufnahmen.
Auch alle Punkte, die zu nah oder zu weit vom Sensor entfernt sind, werden nicht weiter betrachtet.
Je weiter das Objekt entfernt ist, desto ungenauer werden die Aufnahmen.
Im folgenden wurde ein Mindestabstand von 30cm und ein Maximalabstand von 90cm verwendet.
Als letztes filtern wir alle Flächen deren Oberflächennormale zu weit von dem Kameravektor abweicht(siehe Abb \ref{img:KinectSides} b)
Diese Flächen entstehen durch die Umwandlung des 2D Tiefenbilds in einer 3D Punktwolke.
Als letztes filtern wir alle Flächen deren Oberflächennormale zu weit von dem Kameravektor abweicht(siehe Abb \ref{img:KinectSides} b)
Diese Flächen entstehen durch die Umwandlung des 2D Tiefenbildes in einer 3D Punktwolke. % in eine / einer Punktwolke ??
Die benötigten Informationen fehlen an dieser Stelle und Punkte werden auf die Fläche zwischen Oberflächenobjekt und Hintergrund gesetzt.
Diese Ebene stimmt nicht mit der wirklichen Oberfläche überein und müssen entfernt werden.
Diese Ebene stimmt nicht mit der wirklichen Oberfläche überein und @@@ müssen entfernt werden. %was muss entfernt werden? @@@
Hierfür wird die Oberflächennormale verwendet.
Die Normale wird aus dem Tiefenbild geschätzt.
\begin{equation}
...
...
@@ -64,19 +64,19 @@ Die Normale wird aus dem Tiefenbild geschätzt.
dzYAxis = depthAt[x,y+1] -depthAt[x,y-1] \\
Normale = Normalize(-dzXAxis,-dzYAxis,1.0)\\
\end{split}
\end{equation}
\end{equation}% @@@ depthAT wie Variablen setzen oder wie eine Funktion?
Mit dem Skalarprodukt lässt sich der Winkel zwischen dem Kameravektor $(0,0,1)$ und Normale ausrechnen.
Ein maximaler Winkel von 65\degreehat in den Tests ein gutes Ergebnis geliefert.
Mit dem Skalarprodukt lässt sich der Winkel zwischen dem Kameravektor $(0,0,1)$ und der Normalen ausrechnen.
Ein maximaler Winkel von 65\degree hat in den Tests ein gutes Ergebnis geliefert. % @@@ Leertaste hinter \degree fehlt
\todo{Quellen auf Kinect und Lighthose}
\section{Zusammenfügen von Frames}
Ein wichtiger Teil beim dem Aufnehmen der Punktwolke ist das zusammenführen von mehreren Frames.
Ein wichtiger Teil bei dem Aufnehmen der Punktwolke ist das Zusammenfügen von mehreren Frames.
Hierfür wurde die Kinect mit dem Lighthouse Tracking System verbunden und verzichtet damit auf aufwändige Berechnungen.
\todo{Foto Halterung}
Im lokalen Koordinatensystem der Kinect, also jedes Frames liegt der Ursprung in dem Tiefensensor.
die Transformation $transformControllerToKinect$ zwischen denm Koordinatensystem des Controllers und der Kinect wurde bestimmt
die Transformation $transformControllerToKinect$ zwischen dem Koordinatensystem des Controllers und der Kinect wurde bestimmt
und die globale Transformation des Controllers $transformController$ ist in der OpenVR API abfragbar
Die Transformation der lokalen Punktwolke in ein globale ist mit diesen beiden Transformationen möglich.
Eine wichtige Transformation ist die zwischen dem Koordinatensystem der Kinect und dem des Vive Controllers.
Ist zum Beispiel die Transformation entlang der X Achse der Kinect verschoben so verstärkt sich der Fehler wenn man das Objekt von der Anderen Seite,also um 180\degree dreht aufnimmt (siehe Abb, \ref{img:KinecOffset}). Der Fehler im Lokalen Koordinatensystem wird in das Globale transformiert und ist in dem Fall dann in genau entgegengesetzte Richtungen
Ist zum Beispiel die Transformation entlang der X Achse der Kinect verschoben, so verstärkt sich der Fehler, wenn man das Objekt von der anderen Seite, also um 180\degree gedreht aufnimmt (siehe Abb, \ref{img:KinecOffset}). % @@@ Leertaste hinter \degree fehlt
Der Fehler im lokalen Koordinatensystem wird in das globale transformiert und ist in dem Fall dann in genau entgegengesetzter Richtung.
\begin{figure}
\begin{center}
...
...
@@ -100,15 +101,15 @@ Ist zum Beispiel die Transformation entlang der X Achse der Kinect verschoben so
\end{center}
\end{figure}
Bei der Kinect ist der offiziellen Doku entnehmbar das der Ursprung von Punktwolken in dem Tiefensensor liegt (siehe \cite{KinectDoku})
Aber es gibt keine offizielle Dokumentation wo dieser exakt liegt.
In der offiziellen Dokumentation der Kinect ist beschrieben, dass der Ursprung von Punktwolken in dem Tiefensensor liegt (siehe \cite{KinectDoku}).
Leider fehlt die exakte Positionsangabe dennoch.
Im Bild \ref{img:KinectOrigin} aus dem chinesischen Microsoft Forum ist eine von Benutzern vermessene schematische Darstellung der Kinect abgebildet.
Der Tiefensensor liegt hinter der kleineren runden Öffnung, aber Fertigungsungenauigkeiten lassen keine exakten Daten finden.
Für die Implementation wurde mittig hinter der Öffnung angenommen.
Eine digitale Kalibrierung gestaltet sich schwierig, da das Lighhouse Tracking für den Controler zusätlich einige Ungenauigkeiten mit sich bringt.
Für die Implementation wurde angenommen, dass er sich mittig hinter der Öffnung befindet.
Eine digitale Kalibrierung gestaltet sich schwierig, da das Lighhouse Tracking für den Controller zusätzlich einige Ungenauigkeiten mit sich bringt.
Der Ursprung des Controllers lässt sich aus den Modellen von SteamVR auslesen.
Dieser liegt geschickt für VR Anwendungen ist aber für das Tracking von Objekten ungeschickt.
bei der Implementation stand noch keine Vive Tracker zur Verfügung.
Dieser liegt geschickt für VR Anwendungen, ist aber für das Tracking von Objekten ungeschickt.
Bei der Implementation stand noch kein Vive Tracker zur Verfügung.
Für die Arbeit wurde der Controller so nah wie möglich an dem Teifensensor, also direkt darüber angebracht (siehe Abb.\ref{img:KinecttoVive}).
\todo{Bilder}
...
...
@@ -118,7 +119,7 @@ Für die Arbeit wurde der Controller so nah wie möglich an dem Teifensensor, al
\caption{Abmessungen der Kienct. Der Tiefensensor liegt in der kleinen runden Öffnung. Quelle:\cite{KinectChina}}
\caption{Abmessungen der Kinect. Der Tiefensensor liegt in der kleinen runden Öffnung. Quelle:\cite{KinectChina}}
\end{center}
\end{figure}
...
...
@@ -134,14 +135,14 @@ Für die Arbeit wurde der Controller so nah wie möglich an dem Teifensensor, al
\section{Ergebnisse}
Mit dem vorgestellten Verfahren lässt sich einfach und schnell eine Punktwolke erstellen.
Jedoch gibt es Ungenauigkeiten in dem Vive Tracking und der Kalibrierung die die Punktwolke unbrauchbar aussehen lassen. \todo{Bild}
Jedoch gibt es Ungenauigkeiten in dem Vive Tracking und der Kalibrierung, die die Punktwolke unbrauchbar aussehen lassen. \todo{Bild}
Zwischen 2 Aufnahmen und den daraus resultierenden Punktwolken ist ein Versatz bis zu 2-3 cm sichtbar.
In einer 3D Umgebung insbesondere in VR ist das eine zu große Ungenauigkeit.
Der Versatz zwischen den Punktwolken ist leider nicht konstant und ändert sich teilweise zwischen Durchläufen.
Das Vive Tracking ist hierfür ein Grund.
Vergleicht man mit einem 2m Zollstock die reale Distanz zu der in VR gemessenen dann wird daraus 1,98-2m virtuelle Distanz.
Die Distanz ist hierbei abhängig von der Orientierung zu den Basistationen und der aktuellen Kalibrierung des Lighthous Tracking Systems.
Dieses Problem erschwert es die Kalibrierung zwischen Vive und Kinect zu überprüfen die zusätzlich für einen Versatz der Punktwolke verstärken kann.
Die Distanz ist hierbei abhängig von der Orientierung zu den Basisstationen und der aktuellen Kalibrierung des Lighthous Tracking Systems.
Dieses Problem erschwert es, die Kalibrierung zwischen Vive und Kinect zu überprüfen, die zusätzlich für einen Versatz der Punktwolke verstärken kann. %@@@ der letzte Relativsatz ist unverständlich
Die Rotation der einzelnen Aufnahmen war kein Problem und hat keine sichtbaren Probleme produziert.
