Autor: Lubosz Sarnecki, Collabora Ltd.<\/p>\n
Obwohl das Feld der Virtuellen und Augmentierten Realit\u00e4t seit den 90er Jahren besteht, erleben wir in den letzten Jahren eine rasante marktgetriebene Entwicklung in diesem interdisziplin\u00e4ren Bereich. Zwar ist es historisch von propriet\u00e4rer Software gepr\u00e4gt, genie\u00dft aber eine enthusiastische Community von Open Source Hackern und Unternehmen, die freie Treiber und Middleware entwickeln. Offene Standardisierungsbem\u00fchungen werden derzeit von der Khronos-Gruppe durchgef\u00fchrt.<\/strong><\/p>\n Siehe Abb. 1 (PDF<\/a>): Das Reality-Virtuality Continuum von Milgram, 1994<\/p>\n Der Begriff XR (Extended Reality) wird gerne verwendet, um die Aspekte von virtueller und augmentierter Realit\u00e4t zu vereinigen. Er ist hierbei als Synonym von Mixed Reality zu sehen, welches den mittleren Teil der Achse des\u00a0Reality-Virtualty Kontinuums<\/em>\u00a0von Milgram einnimmt. Das Kontinuum beginnt bei der vollst\u00e4ndigen echten Realit\u00e4t, geht \u00fcber die augmentierte Realit\u00e4t, bei der virtuelle Gegenst\u00e4nde in die Realit\u00e4t eingef\u00fcgt werden, und endet in der vollst\u00e4ndigen Virtualit\u00e4t.<\/p>\n Neben des Renderings ist das Tracking der Hauptbestandteil von XR-Systemen. Im Folgenden werden einige in Konsumentensystemen g\u00e4ngige Verfahren vorgestellt.<\/p>\n Die IMU (engl. Inertial Measurement Unit) ist eine Kombination mehrerer Tr\u00e4gheitssensoren und wird durch ihre Preisg\u00fcnstigkeit als Fundament der meisten Trackingsysteme genutzt. Die wichtigsten Sensoren hierbei sind das Akzelerometer (Beschleunigungssensor) und das Gyroskop (Drehratensensor). Viele IMUs enthalten auch ein zus\u00e4tzliches Magnetometer (Magnetfeldsensor), welches jedoch aufgrund seiner St\u00f6rungsanf\u00e4lligkeit auf elektromagnetische Strahlung oft in Implementierungen vernachl\u00e4ssigt oder gar nicht erst verbaut wird. Durch den Einsatz von IMUs in den meisten Mobiltelefonen k\u00f6nnen Projekte wie Google Cardboard das Smartphone als VR-Komplettl\u00f6sung nutzen und m\u00fcssen lediglich einen Papierkarton mit Plastiklinsen als Halterung anbieten.<\/p>\n Um aus einer IMU eine vollst\u00e4ndige Orientierung zu erhalten, muss man mehrere Sensoren zusammenf\u00fchren.<\/p>\n Eine Implementierung f\u00fcr das Auslesen der IMU-Signals der meisten g\u00e4ngigen Konsumenten-VR-Headsets ist\u00a0OpenHMD<\/em>[4]. Die USB-Ger\u00e4te werden hierbei mit der Bibliothek\u00a0hidapi<\/em>\u00a0angesprochen. OpenHMD verf\u00fcgt ebenfalls \u00fcber eine Sensor-Fusion und liefert \u00fcber eine C-Schnittstelle eine fertige Pose des Kopfes. OpenHMD ist unter der Boost-Lizenz ver\u00f6ffentlicht und verf\u00fcgt \u00fcber eine aktive Entwicklergemeinde.<\/p>\n Obwohl die IMU prinzipiell f\u00fcr das Bestimmen einer Position im 3D-Raum verwendet werden kann, liefern g\u00e4ngige Sensoren Daten, die zu verrauscht sind und zu sehr driften, um f\u00fcr diesen Zweck zu gen\u00fcgen. \u00dcblicherweise wird mit IMUs deshalb nur eine Rotation bestimmt, w\u00e4hrend die folgenden Trackingsysteme auch die Position liefern.<\/p>\n Eine g\u00e4ngige Methode, um eine 6DOF (6 Degrees Of Freedom) Pose zu bestimmen, also eine Pose mit 6 Freiheitsgraden, ist das externe bildbasierte Tracking. Hierf\u00fcr gibt es zwei Ans\u00e4tze.<\/p>\n Beim ersten Ansatz beinhaltet das Headset die Aktoren und der externe Tracker ist eine Kamera. Beispiele f\u00fcr diesen Ansatz sind Oculus DK2 \/ CV1, PSVR und OSVR HDK. Bei diesen Ger\u00e4ten findet man ein LED-Gitter am HMD und an den Controllern, welches im infraroten Spektrum leuchtet. Durch Blob-Detektion lassen sich die Aktoren, deren 3D-Anordnung auf dem Headset bekannt ist, im 2D-Kamerabild bestimmen. Mit Algorithmen wie PnP (Point-N-Point), was beispielsweise in\u00a0OpenCV<\/em>\u00a0implementiert ist, kann von den 2D-Positionen im Kamerabild und ihrer 3D-Anordnung auf die Pose des Headsets im Raum geschlossen werden. Eine Open Source Implementierung des kamerabasierten externen Trackings findet man in\u00a0OSVR<\/em>[12] und dem GPLv2 lizensierten\u00a0ouvrt<\/em>[1].<\/p>\n Beim anderen Ansatz beinhaltet das Headset die Sensoren und ein externer Tracker die Aktoren. Dies kommt beispielsweise beim Lighthouse Trackingsystem der HTC Vive und anderen Headsets wie StarVR zum Einsatz.<\/p>\n Hierbei emittieren die Tracker durch 2 an Rotoren angebrachten Lasern, \u00e4hnlich wie bei Laser-Scannern, ein Signal, welches durch einfache Lichtsensoren am Headset und den Controllern aufgenommen wird. Durch die fabrikkalibrierte Anordnung der Sensoren, die vom Headset ausgelesen werden kann, sowie der Information, zu welchem exakten Zeitpunkt jeder Sensor von einem Laserstrahl getroffen wurde, l\u00e4sst sich hierbei eine Pose rekonstruieren. Durch Impulse eines LED-Arrays und Fotosensoren k\u00f6nnen sich mehrere Base-Stationen synchronisieren, ohne mit der Tracking-Software zu interagieren.\u00a0Das USB-Protokoll der HTC Vive wurde vom Project\u00a0LighthouseRedox<\/em>[2] dokumentiert.<\/strong>\u00a0Ein Ansatz f\u00fcr eine Open Source Implementierung des Lighthouse Trackings findet man in meinem experimentellen\u00a0vive-libre<\/em>[13] Treiber sowie in dem darauf basierenden MIT lizenzierten\u00a0libsurvive<\/em>[3].<\/p>\n Bei beiden Ans\u00e4tzen ist eine Steigerung in der Robustheit des Systems mit einer Erh\u00f6hung der Trackeranzahl erreichbar.<\/p>\n Siehe Abb. 2 (PDF<\/a>): Lightouse Tracking-System<\/p>\n Durch die fehlende Notwendigkeit von externen Tracker-Ger\u00e4ten wird das Inside-Out-Tracking gerne in modernen Konsumenten-HMDs eingesetzt. Hierbei ben\u00f6tigt das Headset lediglich mindestens eine Kamera, die mit Hilfe von aus der Robotik stammenden Verfahren wie SLAM (Simultaneous Localization and Mapping) anhand von Feature-Detektion und Aufbau einer Karte die Pose der Kamera im Raum bestimmen kann. In modernen propriet\u00e4ren AR-Implementierungen wie ARcore von Google und ARkit von Apple ist es die bevorzugte Tracking-Methode. Das IMU-Signal des Smartphones oder HMDs tr\u00e4gt hier durch seine kleine Latenz und hohe Frequenz ebenfalls zur Vervollst\u00e4ndigung der Ortung bei. SLAM-Verfahren, die Tr\u00e4gheitssensorik integrieren, nennt man Visual-Inertial, auch VIO. Leistungsstarke Open-Source Implementierungen sind\u00a0ORB-SLAM2<\/em>[6] (GPLv3) und\u00a0Maplab<\/em>[5] (Apache 2.0) von der ETH Z\u00fcrich.<\/p>\n F\u00fcr das Tracken der Controller kann das SLAM mit externen Kamera-Trackingverfahren kombiniert werden, wie beispielsweise bei den Microsoft Mixed Reality Headsets. Der Controller verliert hierbei das Positionstracking, sobald er aus dem Sichtfeld (Field Of View) der Sensoren austritt, und f\u00e4llt auf seine Tr\u00e4gheitssensorik zur\u00fcck.<\/p>\n Eine Liste an zahlreichen Open Source SLAM-Implementierungen kann auf OpenSLAM eingesehen werden[18].<\/p>\n Mit einem simplen Ger\u00e4t wie der Leap Motion oder uSens FINGO, welches eine weitwinklige Stereo-Infrarotkamera enth\u00e4lt, kann mit Bildverarbeitung so wie K\u00fcnstlicher Intelligenz ein solides Tracking von H\u00e4nden erreicht werden. Leider blieb es bei Open Source Treibern wie\u00a0OpenLeap<\/em>[7] nur bei minimalen Ans\u00e4tzen f\u00fcr die Implementierung. Tiefenkameras wie der Microsoft Kinect oder Intel Realsense bieten eine weitere Alternative zum K\u00f6rpertracking. Das\u00a0ROS<\/em>\u00a0liefert Implementierungen f\u00fcr Handtracking auf Tiefenkamerabasis[8].<\/p>\n Eine sehr weit verbreitete API fuer VR ist Valve\u2018s\u00a0OpenVR<\/em>[10]. Zwar ist ihre Implementierung SteamVR nicht Open Source, allerdings bietet SteamVR ein Treiber-Interface an, das die Entwicklung oder Einbindung von Open Source Tracking-Treibern erm\u00f6glicht. Zum Beispiel liefert das\u00a0SteamVR-OpenHMD<\/em>[9] Projekt eine Anbindung an alle von OpenHMD unterst\u00fctzten Headsets.<\/p>\n Die von Sensics entwickelte Middleware\u00a0OSVR<\/em>\u00a0implementiert externes kamerabasiertes Tracking f\u00fcr die HDK- und HDK2-Headsets sowie einen Kalman-Filter f\u00fcr die Filterung der Sensordaten und Bestimmung der Pose. Als IPC und Fundament von\u00a0OSVR-Core<\/em>[12] wird hierbei\u00a0vrpn<\/em>[11] verwendet, welches auch weitere Ger\u00e4tetreiber liefert.\u00a0OSVR<\/em>\u00a0verf\u00fcgt zus\u00e4tzlich \u00fcber Anbindungen zu propriet\u00e4ren Treibern wie SteamVR und Oculus VR.<\/p>\n Die Khronos-Gruppe publizierte bekannte Industriestandards f\u00fcr Grafikschnitstellen wie OpenGL und Vulkan. Derzeit wird an der Spezifikation der OpenXR-API gearbeitet, die herstellerunabh\u00e4ngige Applikationen erm\u00f6glichen wird.<\/p>\n Siehe Abb. 3 (PDF<\/a>): API-Fragmentierung vor und nach dem Einsatz von OpenXR<\/p>\n Bei klassischen Input-Systemen wie SDL 1 wird in der Applikation der Zustand von fest definierten Tasten abgefragt. Dabei kann z.B. die Anwendung geschlossen werden, wenn die Escape-Taste des Keyboards gedr\u00fcckt wird, oder eine Sprungaktion in einem Spiel ausgef\u00fchrt werden, wenn die 2. Taste des Spielecontrollers bet\u00e4tigt wurde. Das hat den Nachteil, dass eine Neubelegung der Tasten speziell in der Anwendung oder im Treiber implementiert werden muss. Ebenso muss der Applikation zur Implementierungszeit der Controller bekannt sein. Dieses Problem f\u00fchrt oft dazu, dass Anwendungen nur einen Controller unterst\u00fctzen, wie z.B. den Microsoft Xbox Controller. Userspace-Treiber wie\u00a0xboxdrv<\/em>[16] helfen hier, das Problem zu l\u00f6sen, indem sie f\u00fcr verschiedene Gamepads einen Xbox-Controller emulieren. Die L\u00f6sung auf Seiten der API ist jedoch einerseits nicht, spezielle Tasten abzurufen, sondern Aktionen zu definieren, die dann im Treiber einer Taste zugewiesen werden k\u00f6nnen. Hier werden aus dem oben genannten Beispiel eine Beenden- und Springen-Aktion die in der Anwendung verarbeitet werden. Der Anwender kann hierbei die Belegung \u00e4ndern oder auf vorgefertigte Profile zur\u00fcckgreifen. Da im Bereich der Virtuellen Realit\u00e4t eine hohe Inhomogenit\u00e4t und Innovation im Bereich der Eingabe herrscht, ist eine Actions-API eine notwendige L\u00f6sung. Hierbei k\u00f6nnen auch Posen des Kopfes, der Controller oder sonstigen getrackten Elemente als Aktionen eingebunden und belegt werden.<\/p>\n Eine propriet\u00e4re Implementierung f\u00fcr eine Actions-API existiert bereits in SteamVR, welche in OpenVR spezifiziert ist. OpenXR wird ebenfalls eine Actions-API besitzen, wie im Vortrag „Standardizing All the Realities: A Look at OpenXR“<\/em>\u00a0angek\u00fcndigt wurde[15].<\/p>\n XR-Ger\u00e4te profitieren von einem speziellen Anzeigemodus, der Direct Mode genannt wird. Im klassischen Extended Mode behandelt das Betriebssystem das HMD als normalen Monitor \u2013 der Desktop wird auf das HMD erweitert, allerdings sind 2D-Anwendungen direkt auf dem HMD angezeigt nicht benutzbar. Eine VR-Applikation zeichnet hierbei in ein normales Vollbildfenster, das auf dem HMD angezeigt wird. Dies hat auch den Nachteil, dass das Rendering mit relativ hoher Latenz geschieht, da moderne Fenstermanager zum Beispiel Compositing zur Darstellung von Fenstern verwenden, welche nicht auf geringe Latenz ausgelegt sind.<\/p>\n Der Open Source Desktop bietet durch die junge Einf\u00fchrung des DRM-Lease-Verfahrens von Keith Packard die M\u00f6glichkeit, Bildschirme komplett vom Desktop-Betrieb auszuschlie\u00dfen. Eine Liste mit Bildschirmen, also HMDs, die durch ihre EDID auf „non-desktop“ gesetzt werden, ist im Linux-Kernel zu finden. Es sind zahlreiche aktuelle Komponenten wie Kernel, X Server und Mesa-Grafiktreiber notwendig, um dieses Feature zu nutzen. Eine genaue Liste an Patches wurde von Christoph Haag zusammengef\u00fchrt[14].<\/p>\n Eine M\u00f6glichkeit, DRM-Leases zu nutzen, ist die Vulkan Grafik-API. Durch die Vulkan-Erweiterungen\u00a0<\/strong>VK_EXT_direct_mode_display<\/strong>\u00a0und\u00a0<\/strong>VK_EXT_acquire_xlib_display<\/strong>\u00a0kann \u00fcber Xlib-Strukte die Bildschirmausgabe im Direct Mode initialisiert werden. Ein Beispiel f\u00fcr die Nutzung des Direct Modes mit Vulkan findet man in meiner VR-Grafikdemo\u00a0xrgears<\/em>[17], welche OpenHMD als Tracker verwendet.<\/strong><\/p>\n Abb 1: https:\/\/en.wikipedia.org\/wiki\/Reality\u2013virtuality_continuum<\/p>\n Abb 2: HTC Vive PRE User Guide<\/p>\n Abb 3: OpenXR API Diagram https:\/\/www.khronos.org\/openxr<\/p>\n [1] https:\/\/github.com\/pH5\/ouvrt<\/p>\n [2] https:\/\/github.com\/nairol\/LighthouseRedox<\/p>\n [3] https:\/\/github.com\/cnlohr\/libsurvive<\/p>\n [4] https:\/\/github.com\/OpenHMD\/OpenHMD<\/p>\n [5] https:\/\/github.com\/ethz-asl\/maplab<\/p>\n [6] https:\/\/github.com\/raulmur\/ORB_SLAM2<\/p>\n [7] https:\/\/github.com\/openleap\/OpenLeap<\/p>\n [8] https:\/\/wiki.ros.org\/hand_interaction<\/p>\n [9] https:\/\/github.com\/ChristophHaag\/SteamVR-OpenHMD<\/p>\n [10] https:\/\/github.com\/ValveSoftware\/openvr<\/p>\n [11] https:\/\/github.com\/vrpn\/vrpn<\/p>\n [12] https:\/\/github.com\/OSVR\/OSVR-Core<\/p>\n [13] https:\/\/github.com\/lubosz\/OSVR-Vive-Libre<\/p>\n [14] https:\/\/haagch.frickel.club\/#!drmlease.md<\/p>\n [15] Nick Whiting, \u201eStandardizing All the Realities: A Look at OpenXR<\/em>\u201c, GDC, March 2018<\/p>\n [16] https:\/\/gitlab.com\/xboxdrv\/xboxdrv<\/p>\n [17] https:\/\/gitlab.com\/lubosz\/xrgears<\/p>\n [18] https:\/\/openslam-org.github.io<\/p>\n Lubosz Sarnecki ist Senior Software Engineer bei Collabora und VR-Enthusiast seit den Oculus DK1 Tagen. Er arbeitet seit 2011 an Open-Source-Softwareprojekten wie GStreamer. Nach der Arbeit an den GStreamer OpenGL-Plugins konzentrierte sich Lubosz auf Grafik und VR. Er ist Author der GStreamer VR Plugins, zahlreicher Open Source VR-Demos und arbeitet derzeit an der Verbesserung des Open Source VR-Stacks. Lubosz hat einen B.Sc. in Computervisualistik der Universit\u00e4t Koblenz.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Open-Source \/ Embedded Software Engineering.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Open-Source \/ Embedded Software Engineering steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nBegriffserkl\u00e4rung XR<\/h2>\n
Tracking-Technologien<\/h2>\n
Inertiale Messeinheit<\/h3>\n
Externes bildbasiertes Tracking<\/h3>\n
Inside-Out Tracking<\/h3>\n
Handtracking<\/h3>\n
\u00dcbersicht: Standardisierungsans\u00e4tze und APIs<\/h2>\n
OpenVR<\/h3>\n
OSVR<\/h3>\n
OpenXR<\/h3>\n
Actions API<\/strong><\/h3>\n
Direct Mode auf dem Open Source Grafikstack<\/h3>\n
Abk\u00fcrzungsverzeichnis<\/h2>\n
\n\n
\n VR<\/strong><\/td>\n Virtual Reality<\/td>\n<\/tr>\n \n AR<\/strong><\/td>\n Augmented Reality<\/td>\n<\/tr>\n \n XR<\/strong><\/td>\n Extended Reality<\/td>\n<\/tr>\n \n OpenVR<\/strong><\/td>\n Valve\u2018s Open Virtual Reality API<\/td>\n<\/tr>\n \n OSVR<\/strong><\/td>\n Sensics Open Source Virtual Reality Middleware<\/td>\n<\/tr>\n \n OVR<\/strong><\/td>\n Oculus Virtual Reality API<\/td>\n<\/tr>\n \n OpenXR<\/strong><\/td>\n Open Extended Reality Khronos Standard API<\/td>\n<\/tr>\n \n SLAM<\/strong><\/td>\n Simultaneous Localization And Mapping<\/td>\n<\/tr>\n \n IMU<\/strong><\/td>\n Inertial Measurement Unit<\/td>\n<\/tr>\n \n OpenCV<\/strong><\/td>\n Open Computer Vision<\/td>\n<\/tr>\n \n 6DOF<\/strong><\/td>\n 6 Degrees Of Freedom<\/td>\n<\/tr>\n \n ROS<\/strong><\/td>\n Robotic Operating System<\/td>\n<\/tr>\n \n PnP<\/strong><\/td>\n Point-N-Point<\/td>\n<\/tr>\n \n VIO<\/strong><\/td>\n Visual-Inertial Odomentry<\/td>\n<\/tr>\n \n DRM<\/strong><\/td>\n Direct Rendering Manager<\/td>\n<\/tr>\n \n IPC<\/strong><\/td>\n Inter-process Communication<\/td>\n<\/tr>\n \n HMD<\/strong><\/td>\n Head-Mounted Display<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Abbildungsverzeichnis<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
Autor<\/h2>\n
\nOpen-Source – unsere Trainings & Coachings<\/h2>\n
\nOpen-Source – Fachwissen<\/h2>\n