 Okay, ich würde dann mal anfangen. Herzlichen Dank, dass ihr so früh am Morgen schon gekommen seid. Das Thema ist heute Virtual Reality mit freier Software bzw. das, was es mal werden wird. Denn es geht darum, was ich bis jetzt schon weiß, was wir schon können und auch was wir noch nicht können bis jetzt. Ich bin tagsüber eigentlich Linux Kernelentwickler und ansonsten interessiere ich mich viel dafür, wie Sachen funktionieren und habe relativ früh schon bei der Oculus DK2 mir die 3D-Brille gekauft, um zu sehen, wie die so funktioniert und seitdem ist das zu so einem Hobby geworden. Ja, ich bin auf FreeNode unter dem Handel PH5 unterwegs. Wenn sich also irgendjemand für das Thema interessiert, mich einfach irgendwann ansprechen, freue ich mich drüber. Und worum geht es heute? Ich habe versprochen, über drei Themen zu reden. Einmal, wie funktioniert das Tracking von den 3D-Billen, die es im Moment so gibt überhaupt. Dann, was gibt es für Open Source Software-Projekte, die sich dem angenommen haben oder versuchen das nachzubauen, was da die proprietäre Software im Moment macht. Und als drittes Kapitel so ein bisschen Reverse-Engineering, das sind im Moment alles USB-Devices. Also wird das Binden halten, mal drauf zu gucken, wenn man das Ding ansteckt, was passiert und was kann man damit machen sofort. So, Hardware. Die momentane Marktübersicht wäre Vive, CV1 und PSVR. Das sind so die Massenprodukte, die im Moment weit verbreitet sind. Wenn man da reinguckt, die Daten habe ich alle von iFixit.com, die haben die Dinger für uns auseinandergenommen. Dann bestehen die aus einem Mikrocontroller, der die ganze Organisation übernimmt. Mit dem redet man über USB und kann Dinger einschalten und ausschalten und bekommt die Sensordaten, von dem überliefert. Dann bestehen die aus einem IMU, einem Inertion Motion Unit, wo ein Accelerometer drin ist und ein Gyro. Das ist ein Inven-Sense bei Vive und bei Rift und PSVR. Das ist ein Bosch-Sensor, aber so oder so auch ähnlich. Und dann gibt es wesentlich noch so einen HDMI-Konverter auf, was auch immer das Display dahinter macht. Da ist auch überall fast der gleiche Chip drin, der ist von Toshiba. Und bei Vive und Rift gibt es dann noch Funkchips, die sind von Nordic Radio. Bei der Vive gleich zweimal, die hängen hinter dem USB-Hub und sehen einfach aus wie USB-Dongles. Und bei der Rift hängt es hinter SPI, also man redet über das Ding über den Mikroprozessor mit dem Ding. Und da hängen dann jeweils die Handcontroller dran. Das Prinzip von dem Tracking ist im Prinzip genau das gleiche wie bei jedem Android-Handy mittlerweile. Man bekommt aus dem IMU die Gyrodaten und die Accelerometer-Daten. Dann werden die Radendaten integriert und man bekommt aus der Drehgeschwindigkeit und aus der Beschleunigung sowas wie eine Geschwindigkeit und ein Winkel. Und dann werden wir gleich sehen, wie das wegtrifftet und man muss es korrigieren. Und dann gibt es irgendwelche externen Referenzpunkte, die fest im Raum angebracht sind, wo man dann die wegtrifftenden Daten wieder zurück an den richtigen Ort organisiert. So, da ist einerseits das Accelerometer. Die Accelerometer-Achse zeigt immer die Beschleudigungsrichtung an der Gravitation entgegen. Plus die Beschleunigung, die es durch die Bewegung erfährt. Also hier haben wir die X-Achse, die Y-Achse und die Z-Achse. Und bei dem Gyro ist es die Drehwinkelgeschwindigkeit um genau diese Achse. Also die X-Achse-Drehung, die Z-Achse und die Y-Achse ist diese. Und dann kann man diese Sachen hernehmen und integrieren. Das heißt, man nimmt immer einen Drehwinkelwert, multipliziert den mit dem Zeitintervall seit den letzten Mal und zählt das auf die vorige Rotation drauf. In dem Fall ist das jetzt eine Quadrenion-Darstellung. Da sind im Prinzip die ersten drei Komponenten die Drehachse multipliziert mit dem Cosinus von dem halben Winkel und die vierte Komponente ist der Sinus von dem halben Winkel. Und das, was dabei rauskommt, und man sieht hier schon, dass die Position noch nicht richtig stimmt, ist die Rotation von dem Gerät. So, das habe ich noch nicht auspinitiert, fällt mir jetzt gerade auf. Was man dann machen möchte, ist die Rotation wieder in die richtige Richtung drehen. Dazu nimmt man den Beschleunigungsvektor, den man mitteln kann, weil wenn man eine lange Beschleunigung in eine Richtung hat, dann würde ja der Controller weg verschwinden in eine bestimmte Richtung. Und üblicherweise benutzt man den ja in begrenzten Räumen, sprich im Mittel ist die Beschleunigung, die man durch die Bewegung erfährt, null. Und das, was übrig bleibt, ist dann tatsächlich die Gravitation. Das heißt, man kann den über eine Weile gemittelten Beschleunigungsektor nehmen, um die Gravitationsrichtung anzunähern und dann den Drehwinkel wieder in die richtige Richtung zu bekommen. Wie man das macht, ist, dass man die Ungenauigkeit der Sensoren mit berücksichtigt. Das heißt, wenn man sich jetzt vorstellt, dass die rote Kurve der erste Messwert ist, wo man noch eine absolute Messung hatte, und dann bekommt man durch die Integration einen zweiten Messwert, das wäre jetzt die grüne Kurve, der ein wenig weiter gedriftet ist, und dann berücksichtigt man, dass man durch das Modell die Ungenauigkeit erhöht hat und dann verbreitert sich halt die Kurve und damit die Unsicherheit des Winkelwertes wieder. Und die blaue Kurve wäre dann der dritte Wert nach zwei Schritten. Und wenn man jetzt einen neuen Messwert hat, der wieder den absoluten Winkel misst später, an der Stelle der roten Kurve, dann kann man die beiden Gaussfunktionen multiplizieren und bekommt einen Mittelwert, der entsprechend der Ungenauigkeit gewichtet ist. Das heißt, der ist sehr viel näher an der sehr genauen Kurve und sehr viel weiter weg von der sehr ungenauen Kurve und die Genauigkeit von dem Wert hat dann wieder erhöht. Das ist bis jetzt noch nicht implementiert, und weil ich es noch nicht implementiert habe, habe ich es auch noch nicht hinreichend gut verstanden, dass ich es jetzt ausführlich erkläre. Sprich, das bleibt im Moment auf dem Level. Da sitze ich aber gerade dran. So, und die externe Referenz, die man jetzt braucht, um die Winkelwerte wieder zurückzubekommen, nein, die externe Referenz, die man jetzt braucht, um die Positionswerte wieder zurückzubekommen, ist an der Stelle eine Kamera bei der PSVR. Die sieht einfach die Leuchtflächen, das sieht dann so aus. Und ich habe hier eben geschrieben, das ist eine Stereo-Kamera und hier ist ein einzelnes Bild, das ist einfach nur ein Bild von meiner Webcam. Und es liegt daran, dass die PSVR-Kamera dummerweise nicht Standardstecker hat. Das ist der erste Schritt, da kann man sich einen kleinen Adapter bauen und das PSB-Dreit dann anschließend damit. Und dann stellt man fest, dass da keine Firmware drin ist. Das heißt, man bekommt erstmal so einen OmniVision-Bootloader angesteckt und dann kann man Projekte im Internet finden, wo Leute schon angefangen, das zu reverse-engineeren und da kann man den Bootloader reinladen und mit einem speziellen Programm die Daten runter... Also es ist alles noch sehr kompliziert und unfertig und ich sehe nicht, dass das jemand gerne nachmacht. Ja, wenn es Fragen gibt, immer gerne rein. Ich arbeite daran. Und einige andere arbeiten auch daran. Also der Tenor von diesem Vortrag ist noch nichts fertig. Wer jetzt mit Virtual Reality spielen möchte, der ist wahrscheinlich am besten beraten, sich eine Vive zu kaufen unter Linux und die SteamVR-Better zu installieren. Aber hier geht es um Spielereien mit den Dingern und versuchen rauszufinden, wie sie funktionieren. Wir werden da ankommen, die Frage ist wie schnell. Je mehr mitmachen, desto schneller wird es. Ach so, an der Stelle interessiert mich, wer von euch hat eine 3D-Brille, vielleicht mal die Hände hoch? Das sind ja doch ein ganz paar. Wer von euch hat eine Rift? Wer eine Vive? Und wer eine PSVR? Und wer hat eine PSVR und keine PlayStation? Okay, das ist ja doch dann ein bisschen überlappt. Ja, also das zählt auch, habe ich auch. Richtig, wie heißt das, Jan? Wie heißt das andere? Genau, Daydream vielleicht? Ja. Okay, also an der Stelle kann ich eigentlich, das Ding mal anschließen, das dauert eine Weile, bis es hochgebotet hat, weil da ist es ein ganzer Sock drin, der das Betriebssystem starten muss. Also ich kann mit dem Ding schon reden, ich kann die Lampen anmachen, ich nehme das mal kurz vorne weg. Und ich dachte, ich kann mit der Kamera auch schon die Position bestimmen. Nope, Vorführ-Effekt. Also wir können damit später nur rumspielen, ich bin das ganze Wochenende da, wenn sich irgendjemand dafür interessiert, was da in der Tat schon funktioniert, immer vorbeikommen und dann können wir damit ein bisschen rumspielen. Ich dachte, ich kann das jetzt hier einfach zeigen. Ich probiere nochmal neu zu starten. Die PSVA Bilder reinzumachen ist ganz einfach, man schließt die über HDMI an. Ja, tut mir leid, dass das jetzt ein bisschen stock gerade, aber vielleicht funktioniert es wegen dem Licht gerade nicht. Es ist eine extrem simple Erkennung im Moment. Das werde ich auch noch verbessern. Okay, dann mache ich den erstmal wieder aus. Bei der Rift ist die externe Referenz auch eine Kamera. Die ist jetzt einfach nicht stereo, sondern einzeln, aber dafür kriegt man zwei davon, wenn man die Handcontroller benutzt und stellt die an unterschiedliche Stellen. Das hat einen gleichen Effekt. Und die sieht Infrarot-LEDs. Das sieht dann idealerweise so aus. Und da kann man dann auch wieder einfach in Software die Punkte erkennen. Und was dann passiert ist, dass man anhand der Punktposition ja den Winkel kennt von der Kamera aus, die der Punkt hat. Wenn man genügend Punkte hat, kann man aus den Winkeln der unterschiedlichen Punkte und der Orientierung der Punkte, die man kennt, weil man hat ja das Hardware-Modell von der Punktorientierung wieder zurückrechnen auf die Position relativ zu der Kamera. Wenn man das mit beiden Kameras macht, dann kann man die Werte vergleichen, kann man das als Quelle für diese Korrekturdaten, für die Filter benutzen und dann die Werte, die aus dem Gyros, aus dem Imo und aus dem Axelometer rauskommen, wieder korrigieren damit. Da ist der aktuelle Stand, dass wir zwar mit der Kamera reden können, die ist, wenn man es richtig macht, einfach nur eine UVC-Kamera. Das heißt, man kann die ansteppseln und das Bild rausbekommen. Es hat allerdings ein Problem. Und zwar habe ich jetzt hier von der alten Rift die Kamera mitgebracht. Ach, die steckt auch schon dran. Das ist eine Infrarotkamera einfach. Und eigentlich, sollten Sie mir was anzeigen? Wir haben ja Zeit. Ja, jetzt haben wir es. Okay, also es gibt ein paar Infrarotquellen hier in dem Raum. Das merke ich auch. Und hier, ich halte immer den Schatten rein. Die leuchtet einfach nicht. Ich habe im Moment das Programm gestoppt, was die offen hält. Bei Oculus ist das so, dass die so einen Keep Alive-Timeout haben. Ein Keep Alive-Timeout haben, da muss man also alle zehn Sekunden oder so immer ein Paket hinschicken, sonst geht die einfach aus. So, und jetzt sieht man hier was blinken. Ich reflektiere natürlich Infrarot, das liegt sehr schön, aber da sind halt die Leuchten an der Kamera dran. Ich mach das mal groß. So, jetzt fällt euch wahrscheinlich auf, das blinkt. Und das ist ja zum Tracking eher blöd, wenn immer das Bild wieder verschwindet. Und das liegt halt einfach daran, dass die Dinger wenig Energie verbrauchen sollen. Und deswegen sind sie nicht die ganze Zeit an, sondern immer nur kurz. Und die Kamera ist eigentlich so eingestellt, dass sie zum gleichen Zeitpunkt, wo die Brille, die LEDs alle anmacht, wo der Handkontroller die LEDs alle anmacht, das Bild macht, die Belichtung, und dann wieder aufhört. Und bei der DK2, das ist das Vorserienmodell gewesen, ist dieser Synchronisationspuls zwischen der Beleuchtung von der Brille, wo die LEDs anmacht, und dem Trigger der Kamera im Prinzip über den Kabel gegangen. Und jetzt bei den neuen Dingern geht es halt über diese Funktipps. Da sind auch in den USB-Kameras zu der Rift-Empfänger drin, die irgendein Funksignal, was ich noch nicht kenne, aufnehmen und daran ihre Belichtung orientieren, bitte. Das ist aber... Also erst mal ist es einstellbar. Ich glaube, standardmäßig stellen sie das auf so was wie 54 Hertz ein oder so. Und die blinken immer nur so ein paar Mikrosekunden lang. Der Grund dafür ist, dass das Ding über USB versorgt werden kann. Es gibt nicht viel Energie, wenn es nur in diesem Bereich, wo genau die Kamera aufnimmt, blinkt. Und das Kamera-Beleuchtungsintervall möchte man natürlich kurz haben, damit man selbst in schneller Bewegung ein möglichst scharfen Punkt bekommt und nicht irgendwie so einen breiten Streifen. Die Blinkfrequenz hier ergibt sich aus der Schwebung zwischen der Wiederholfrequenz von der Kamera, die im Moment vollkommen frei läuft, halt mit irgendwie 60 Hertz oder so, und der Blinkfrequenz von der Brille. Und richtig. Da müsste man jetzt... Gibt es eine Frage? Nein, da telefoniert jemand. Da müsste man jetzt herausfinden, wie genau man die Kameras von der Rift dazu bringt, auf dieses Radiosignal zu hören und eben ihr Kamerabild genau zu synchronisieren auf das Blinken. Und dann könnte man da auch die Daten benutzen, um die Position zu erkennen. Richtig. Wenn da jemand mit Erfahrung hat und mir dabei helfen will, auch immer gerne... Wir werden da schon noch zu was kommen. Bei der Rift ist es ähnlich, aber völlig anders. Da gibt es keine Kamera, die leuchtende Punkte filmt, sondern da gibt es diese Basisstationen, die Licht über den Raum schwirnt. Und zwar blitzt die immer einmal hell, omnidirektional in alle Richtungen und dann sweept sie mit seinem Laser über den Raum und zwar einmal in horizontaler Richtung, mit so einem in die Richtung aufgefächerten Laser und der Abstand von dem Blinkpuls und dem Zeitpunkt, wo dieser Lasers wie den Sensor trifft, ist genau der Winkel, unter dem sich der Sensor befindet zu der Basisstation. Man hat also wieder wie bei den Kameras für jeden Sensorpunkt an der Vive, das sind die ER-Photo-Dioden, ein Winkel, unter dem er relativ zu der externen Referenz zu finden ist, nur in dem Fall ist das Licht genau in die andere Richtung gegangen. Das klingt jetzt alles erstmal so, als ob das ungefähr das Gleiche ist, bloß andersrum und relativ einfach. Der Teufel steckt da natürlich total im Detail und wer sich für die Hardware interessiert, da gibt es einen super Vortrag von Alan Yates, von Welf, der das maßgeblich mitentwickelt hat. Ich glaube auf Hackaday. Ich werde die Sachen alle in dem Vortrag, in dem Vortrags-Wiki verlinken. Da kann man sich mal genau darüber informieren, was sie alles für Hürden umschiffen müssten. Im Prinzip hat man also einen Rotationssensor, an einem Rotator. Da sind zwei im Prinzip festnatten Motoren in die Richtung und in die Richtung im Moment eingebaut. Dann gibt es einen Laser pro Rotor, der auf so einen um 45 Grad verdrehten Spiegel auf der Drehachse feuert. Das wird dann reflektiert nach außen hin. Dann gibt es eine Linse, die das aufweitet, in eine Richtung und dann gibt es so einen Lasersheet, der einmal über den Raum spiegt, also in diese Richtung. Auf diesem Rotor gibt es irgendwo so ein Retroreflektor und einen optischen Sensor, der dann halt dieses Rotationssensor-Signal, also den Nullpunkt quasi, den Null-Grad-Winkel bestimmt. Und zu dem Zeitpunkt, wo der signalisiert, wird ein ganzes Array von LEDs angemacht. Das heißt, es gibt einen so hellen Lichtpuls, das ist dieses O-Tix da oben. Das heißt irgendwie Omnidirectional, Optical Transmitter. Und die Länge dieses Pulses, die modulieren die. Und zwar gibt es da, ich glaube, da sind drei Bits Daten drauf moduliert, die beinhalten einmal, und nun ist es der Vertikale oder der horizontale Sweep, der als Nächstes folgt. Die Information ist, dass als Nächstes ein Sweep oder setzt die Basisstation eine Runde aus. Das hat den Zweck, dass man zwei Basisstationen gleichzeitig benutzen kann. Dann blitzt immer die eine Basisstation, sweept einmal in beide Richtungen und dann blitzt die andere Basisstation und sweept einmal in beide Richtungen. Die Blitze sehen die Basisstationen aber gegenseitig, sodass sie sich aneinander synchronisieren können, sodass es halt immer eine einmal aus ist. Sodass man immer abwechseln von beiden Positionen die Daten bekommen kann, für den Fall, dass man halt nicht beide Stationen sieht und Verdeckung hat, man immer noch tracken kann. So, und ein festes Zeitintervall hinter diesem Synchronisationspuls beginnt dann, dass es hier mit Laser Axe 1 und Axe 0 markiert ist, das Sweepfenster. Also diese dauert tatsächlich die Dauer, die der Laser an ist über den Raumscan. Und irgendwo in diesem Intervall misst man dann, wenn man das Ausgangssignal von der Fotodiode anguckt, einfach nur einen sehr kurzen Puls. Und der Abstand von diesem Synchronisationspuls, den man zuerst misst, und dem darauf folgenden Sweepuls, ist im Prinzip ein Maß für den Winkel. Und dann hat man wieder die gleichen Daten, wie bei den anderen Systemen, wo man eigentlich ein komplettes Kamerabild hat und Blobs finden muss. Ja, da fallen wesentlich weniger Daten an. Im Detail ist es alles ein bisschen komplizierter, weil aus Produktionsgründen diese Linsen nicht immer unter dem exakt dem gleichen Winkel eingebaut werden können. Das heißt, der Sweep ist nicht unbedingt immer exakt 90 Grad, sondern vielleicht ein bisschen schräg. Was bedeuten würde, dass wenn man weiter oben ist, man eher getroffen wird und unten später, was also wieder irgendwie auf den Winkel zurückfällt, unter dem man sich befindet, wenn man die Zeit misst. Es kann sein, dass der Laser nicht exakt in der Mitte der Achse angebracht ist, also nicht komplett in der Achse auf den Spiegel trifft, sondern ein bisschen versetzt, was dazu führen kann, dass wenn sich der Spiegel dreht, dann der Punkt, unter dem der Laser den Spiegel trifft, immer hin und her wandert. Also der Laser an der Linsen ein bisschen hin und her wandert, was auch noch einen optischen Effekt hat, von dem ich nicht weiß, was es genau ist. Wir wissen schon, dass diese Synchronisationspulsen Daten übertragen werden. Und zwar sind das, ich glaube, 40 bytes oder so an Daten. Das sind Kalibrierinformationen drin. Das sind so fünf Floatwerte, die sagen, wie der Tilt ist von der Achse und wie das gebogen ist irgendwie. Wir wissen aber leider noch nicht, was da genau der mathematische Zusammenhang ist. Sprich, da ist die Suche ongoing, nachdem, wie man es dann exakt kalibriert. Also so ungefähr die Position zu finden geht schon, aber das so exakt zu machen, wie die proprietäre Software das im Moment kann, ist noch nicht möglich, weil wir einfach nicht genug wissen. Das habe ich eben schon mal ausprobiert. Das hat leider nicht funktioniert. Ich lasse das jetzt einfach mal, das können wir vielleicht danach noch ausprobieren, wenn es irgendwie weitergeht. Und dann bin ich mit dem, was ich im Moment über das Tracking weiß und schon implementiert habe, auch schon am Ende. Also wie gesagt, was jetzt als nächstes ansteht, ist diese Positionserkennung robust zu machen und bei der Rift erstmal rauszufinden, wie man überhaupt die Kamerabilder synchronisiert bekommt, damit man die Positionsdaten vernünftig auswerten kann. Und bei der Vive im Wesentlichen, wie die Kalibrierung funktioniert, bitte. Ich bin Idealist. Also die Frage war, warum beschäftige ich mich überhaupt mit Rift? Dankeschön übrigens. Beschäftige ich mich überhaupt mit Rift und Vive? Da gibt es doch Software für. Erstens, Rift funktioniert nicht unter Linux und wird auf absehbare Zeiten nicht unter Linux funktionieren. Das ist eine Bewegung auf Seiten von Facebook oder Oculus, dass sie das irgendwie unterstützen wollen. Glaube ich nicht dran. Ich will keinem sagen, dass er irgendwas kaufen soll oder nicht kaufen soll. Das ist im Moment alles sowieso noch nicht so ideal. Die werden in zwei, drei Generationen so viel besser. Wer sich dafür interessiert und damit rum basteln will, gerne. Ich freue mich über jeden, der irgendwie mithilft, zu basteln. Ich glaube, dass sie im Moment zum Spielen sowieso noch für neugierige sind. Sie haben alle noch Einschränkungen. Also ich beschäftige mich mit Rift und mit Vive, weil ich wissen will, wie es funktioniert und ich will es nachmachen. Für mich stellt sie die Frage nach dem, warum eigentlich nicht. Die Dinger sind da und ich jetzt will ich das selber machen. Das ist der Grund. Für die PlayStation natürlich was zu tun, was andere benutzen können, damit die PlayStation auch einen Sinn hat. Die PlayStation wie auch einen Sinn hat für die Leute, die nicht nur zum Spielen benutzen möchten, vielleicht. Der Software Teil möchte ich kurz drei Projekte vorstellen. Da gibt es im Wesentlichen OpenHMD. Die sind unter FreeNode auch auf dem OpenHMD Channel aktiv. Ein Projekt auch auf GitHub. Die haben im Moment implementiert Rotation und ein Filter mit diesem Beschleunigungs-Sensor-Korrektur. Man hat eine Drift-Korrektur in der ebenden Richtung, sodass die Ebene immer wieder richtig rumgemacht wird. Man hat aber noch keine Positionserkennung. Man kann das benutzen und schon Programme damit starten, die davon abhängen. Zum Beispiel gibt es Blender-Unterstützung auf einem Branche und kann damit schon ein Blender-View auf die Brille setzen, wenn man nebenher modelliert. Aber eben noch nicht mit Positionserkennung. Solange man seinen Kopf stillhält, ist alles gut. In dem Moment, wenn man den Kopf bewegt, kommt die Welt mit. Es fehlt im Moment wesentlichen wieder Expertise-Filter und genau die drei Punkte, die ich eben schon genannt habe, zu der Positionsbestimmung, dass man die Daten richtig auswerten kann. Ansonsten sind die immer sehr schnell darin, die Protokolle von USB-Geräten von irgendwelchen neuen Brillen auszuklamüsern. Es gibt da Support für verschiedene chinesische Modelle, die teilweise auch sehr billig sind. Die können zum Beispiel mit dem OpenHDK umgeben, was von Censics oder Razer oder von beiden irgendwie zusammen ist. Da gibt es so eine Open-Source-Brille, die mit OSVR zusammenarbeitet. Und eben auch mit Rift DK1, DK2, jetzt der kommerziellen Brille, die CV1 heißt Playstation und die Vive unterstützen sie auch. Work in Progress. Das nächste Projekt, was ich kurz vorstellen möchte, ist Lib Survive. Das ist aus dem Grund ganz interessant, weil da so ein YouTuber ist, der fast daran arbeitet. Der hat sich irgendwann mal angefangen, das OSVR-Projekt runterzuladen, was für dieses OpenHDK, nein, für dieses HDK da war und zu versuchen, da Support für die Vive reinzubauen, wollte er eigentlich. Und dann hat er festgestellt, dass das so dermaßen viele Daten sind, und das Mobile-Plan voll war irgendwie. Das sind hunderte von Megabytes, die man dafür das Framework-Rundladen muss und hat sich gedacht, das kann er vielleicht besser und kleiner machen. Und dann hat er live gestreamt. Angefangen hat die Teile, die er da brauchte, für die Vive zu reverseingenieren und eine kleine Bibliothek gemacht, die eben genau dieses Aufnehmen der Laser-Daten implementiert und dann nachher Positionserkennung daraus macht. Und ich glaube, er hatte irgendwie vor, das so in 2, 3 Live-Streams zu machen und mittlerweile sind das irgendwie 7, 8 oder 9 oder so und 20 Stunden mindestens Video kann man Leuten dabei zugucken, wie sie rum rudern und wie halt so reverse-Engineering wirklich funktioniert, wenn man abends mal zusammen ist und versucht, Dinge rauszufinden. Das ist aus dem Grund auch noch ganz interessant, weil da die Valve-Engineere irgendwie drauf angesprungen sind und dann in den Chess, in denen die da unterwegs waren, geholfen haben, immer noch so kleine Hinweise geliefert haben, und die sind maßgeblich dafür verantwortlich, dass wir jetzt mit den Vive-Hand-Kontrollern über Radio auch die Laser-Daten auslesen können. Also die haben irgendwie so ein komprimiertes Protokoll um diese Laser-Pulse-Informationen, die die Fotodioden aufnehmen, über Funk an die Vive-Brille zu schicken, die sieht man dann über USB aus diesen Dongles. Aber da wussten wir lange Zeit nicht, wie das komprimiert ist und das haben die rausgefunden. Und ansonsten sind die eben gerade dabei zu versuchen, Kaliberier-Daten aufzunehmen, damit wir irgendwie Informationen darüber bekommen können, was denn genau diese Kaliberier-Informationen, die Vive-Basis-Stationen, die Laser-Stationen senden, machen. So und das letzte ist Overt, das ist das, was ich gerade eben vorgeführt habe, was teilweise funktioniert und teilweise auch gerade nicht. Das ist im Prinzip so mein persönlicher Spielbahnhof für die Präsentation und alles, was dahinter liegt. Also im Wesentlichen habe ich da Protokoller-Entwicklung gemacht und rausgefunden, wie man zum Beispiel die Rift-Touch-Controller an die Brille perrt und so Zeugs. Und für PlayStation gibt es im Moment schon ein paar Projekte nicht fertige Software. Da sind so Sachen wie PSVR-Framework, wo die Software für mich uninteressant ist, weil das ist C-Sharp-Windows-Programm irgendwie, aber die haben sehr viel Informationen zusammengetragen. Das Protokoll, was man mit der Brille spricht, schon komplett dokumentiert. Es fehlt noch so Spezialfunktionalität, aber alles, was man braucht, um irgendwie die Letz anzumachen und die Sensor-Daten auszulesen und die 3D-Position zu berechnen, wenn man möchte, ist alles schon da. Das war eine große Hilfe. Die PlayStation hat auch Hand-Controller, das sind so Sterbe mit Leuchtbombeln am Ende irgendwie. Dafür gibt es auch schon eine komplette Impinierung, das ist leider Windows Only und die haben sich auf den Plan geschrieben, Linux zu unterstützen, ist aber noch nicht so ganz so weit, aber da gibt es halt schon viel Code und Implementierung in diesem PS Move Service. Und dann wie gesagt, um die PlayStation Stereo Kamera in Betrieb zu nehmen, ist auch noch Arbeit nötig. Da gibt es ein Projekt auf GitHub, PS4 ICAM, was zumindest schon mal eine Firmware hat, die man da irgendwie reinladen kann und dann kann man da Daten rausholen. Aber es ist noch nicht Anstecken und Out-of-the-Box und PSVR-Kamera wird nie anstecken Out-of-the-Box, weil man immer erst mal diesen Adapter zusammen löten muss, und dann kann man einen anderen Stecker zu nehmen als USB 3. Dann gibt es ein paar Projekte auch wieder auf GitHub, die Hilfreiche Dokumentation enthalten. Das ist für die ganzen Rift-Geschichten Rift-DK1, das ist von Oculus damals selbst noch. Die haben für ihre erste Brille komplett die Gerber-Daten, also die PCB- Informationen, ich glaube auch die mechanischen Drawings da reingetan und eine komplette Firmware-Dokumentation und die Firmware-Quellen. Das ist eine Hilfe, weil die Firmware der DK2 und auch der CV1 der offiziellen Oculus-Brille auf der alten Firmware aufbauen, sprich das Protokoll ist erweitert worden, aber die Grundfunktioniziert ist immer noch die gleiche. Das heißt, das war ein super Ausgangspunkt an der Stelle. Lighthouse Redox ist ein Repositorich von einem, der schon zu Playstation, Wifepree also bevor diese Prototypen-Modellen rausgefunden hat, dass das Teil der Protokolle funktionieren und das da dokumentiert und wer irgendwas rausfindet, an der Stelle ist angehalten oder will kommen, da Informationen zuzuliefern. Das wäre mein Software-Teil, sprich es gibt jede Menge Projekte zu all diesen Brillen schon irgendwelche Leute, die daran arbeiten aber überall immer noch viele Lücken, die noch gefüllt werden müssen und viel zu wenig Freizeit für sowas. Die Geräte in der Generation sind alle USB basiert. Die werden bestimmt dennächst funkbasiert, aber ich denke mal da wird dann USB über ein Funkkanal getunnelt oder sie werden weiterhin human interface devices sein, sprich das ist nichts, was verschenkt ist, wenn man sich damit beschäftigt. Das macht es einfach zu gucken, was passiert. Mit USB human interface devices redet man wie mit einer Tastatur oder einer Maus, sprich man hat Interrupt Transfers, das sind Pakete, die das Gerät von sich ausschickt sowas wie ein Tastendruck oder eine Mausbewegung, in dem Fall schicken die halt ihren kompletten Datensatz immer mit der Wiederholfrequenz, das sind irgendwie so 500.000 oder 2.000 Hertz. Da sind dann die Axiometer-Daten drin, die Gyrodaten, Temperatur, Informationen darüber, welche Knöpfe gedrückt sind bei den Kontrollern. Dann haben sie noch so ein Infrared-Proximity-Sensor, damit man sieht, ob die Stirn nahe dem Sensor ist, damit sie ihr Display dann an und ausschalten können. Alles, was man braucht, kommt da halt automatisch raus. Bei manchen muss man vorher irgendetwas tun, um sie einzuschalten. Da gibt es Hit-Protokoll sogenannte Reports, Feature Reports sind so nummerierte Datenfelder im Prinzip, wo man irgendwelche Sachen hinsenden oder irgendwelche Sachen wieder rausholen kann. Im Prinzip so erweiterte Konfigurationsblöcke und Tastaturen benutzen, um LEDs an- und auszumachen oder sowas. Dann gibt es Wenderextensions, wo man die Reports benutzen kann, um Firmware zu flaschen, Epiroms auszulesen und so. In dem Fall der 3D-Brillen passiert halt genau das auch und man kann die benutzen, um den Bildschirm an- und auszuschalten, das Radio zu bedienen, das Pairing auszulösen, im Fall von den Handkontrollern, die Haptics, also diesen Motor an- und auszuschalten und also Spiele. Wie findet man raus, wie die Dinger funktionieren? Also, wenn man sie ansteckt, kommen da entweder schon Daten rausgesprudelt oder das passiert erstmal nichts. Was ich als erstes mache, ist LSU-SB und schauen, was so viele Interfaces drauf sind und wenn man dann Daten rausbekommt, kann man die schon analysieren und irgendwas sinnvolles mitmachen, wenn da erstmal nichts passiert oder man wissen möchte, wie man das Ding einschaltet erstmal oder eben im Fall von dieser Rift, wie man das Ding be- live senden muss, damit es angeht und anbleibt. Erst mal rausfinden, wie das überhaupt funktioniert. In dem Fall von der Rift war das jetzt nun gerade schon dokumentiert, wie gesagt. Aber es gibt genügend Details, die man halt nicht weiß. Ist es total hilfreich, wenn man ein Gerät hat, wo das Ding funktioniert schon und man mit lauschen kann, was passiert. Und da gibt es Wireshark und unter Windows USB-P-Cab, was dazu total super funktioniert. Also, ich habe einen Windows-Rechner mit Steam-WR auf Steam installiert und dann startet man Wireshark und klickt bei USB-P-Cab an, steckt die Geräte an, damit man die USB-Verhandlung, die Descriptoren alle bekommt. Dann ist in dem Protokoll auch mit drin, was das Gerät behauptet hat, wer es ist und solche Sachen. Startet das Programm und macht ein Ding, was einen interessiert. Entweder man spielt einmal das Pairing durch oder man drückt irgendwo drauf, dass der Controller besit macht und den Dampf rausholen möchte, stoppt den Dampf und schaut sich den Wireshark an. Und das sieht dann ungefähr so aus und man startet da stundenlang drauf oder halt auch nicht stundenlang, je nachdem, wie viel man vorher schon weiß. In dem Fall, glaube ich, war das gerade für das Pairing. Da sieht man oben das USB-Device, mit dem es redet und man sieht, dass da irgendwie ein Gerät 2.3.0, 2.3.1 ist. Das sind zwei Interfaces und dieses schwarz markierte Paket ist ein Set Report Request. Das ist eines von diesen Konfigurationsblockdingern, wo man was reinschreiben kann. Und bei dem USB-Protokoll sind immer diese Transfers in ein Request und in eine Response unterzahlt. Und in dem Request steht drin, welchen Report man einwerfen möchte und in dem Response steht dann in dem Dampf drin, was für Daten da drin waren. In dem Fall sieht man, da kommt ein Request, das war nämlich ein Request, das Ding neu zu booten im Pairing-Modus. Sprich, an der Stelle musste ich einfach ein bisschen ausprobieren, was man da genau reinschreibt. Ich wusste halt, dass es ein Report mit der Nummer 6 ist und dann hatte dieses Ding irgendwie zwei Beid-Nutztaten und dann war es halt ein bisschen schätzen, was man da reinschreiben muss und kurze Zeit später taucht das Gerät dann halt unter einer neuen Nummer auf und der Get-Report, der hier aufgemacht ist dazu, enthält hier die Nutzdaten, die da wieder rauskommen und da hatte ich diese Request, die ich hingeschickt habe und da steht jetzt hier die Nummer drin, die ich da reingeschrieben hatte und das sagt mir, dass es wieder hochgekommen ist in dem Modus, den ich Requestet habe, in dem Fall. Also, um das Pairing auszulösen, was dahinter kommt und dann auch ein bisschen komplizierter ist und mit mehreren Schritten, wo man irgendwelche Adressen in irgendwelche Fälle reinschreiben muss, war der erste Schritt, dieses Ding in dem speziellen Modus neu zu booten und für so was hilft halt Viashack. Total selbst, wenn nicht alle Informationen da sind. Da die USB-Kameras mit angesteckt hat, dann werden das teilweise sehr viele Daten, also muss man sich da ein bisschen reinfuchsen, um die Sachen gut rauszufiltern, damit man auch das findet, was man sucht. Aber das ist elementar für Reverse-Engineering von Windows-USB-Geräten. Das ist einfach der Schritt, den ich bis jetzt gefunden habe. Für die PlayStation einerseits hatte ich Glück und es hat schon jemand für mich gemacht, andererseits ist es da nicht so einfach, weil man nicht ein Windows-Gerät hat, wo man einfach Viashack installieren kann. Das ist irgendwie ein USB-Sniffer dazwischem Schalten, der teilweise ein bisschen teurer ist. Oder ja, wenn auf der noch die original Software für das PSVR laufen könnte, würde das total helfen. Also habe ich keinelei Informationen zu, wie gesagt, ich habe keine PlayStation. Ich habe schon überlegt, ob ich mir für das Projekt eine PlayStation kaufe, aber ich würde sie halt sonst nicht benutzen. Dafür ist es doch wieder ein bisschen teuer. Ja, vielleicht um Linus drauflaufen zu lassen dann. Das letzte, was ich da unten hatte, war Live Capture. Gerade für diese ganzen Sensoren, die da so drin sind, finde ich das immer sehr mühselig, in dem Viashack Dumps durch die Dinger durchzuklicken und dann die unterschiedlichen Felder zu vergleichen, die man nicht gleichzeitig sieht. Da schreibe ich mir meistens kleine Programme, die einfach die USB-Devices aufmachen und hoschen. Das wäre meine letzte Kurze Live-Demo an der Stelle, glaube ich. Und zwar, vielleicht kann ich das mal zeigen, ich weiß gar nicht, ob man das hier ... Nein, gut. Ihr wollt auch keines Hauses kurz sehen an der Stelle. Wer ihn sehen möchte, kommt nachher bei mir vorbei. Das sind die kompletten Daten, die von dem Ding über das Radio von der Rift im Moment eingehen. Wenn man jetzt den zweiten Controller dazu hätte oder noch die Fernbedienung, dann würden sie sich überschneiden und dann wäre da noch ein bisschen mehr unterwegs. Aber im Prinzip, das ist alles, was von den Dingern kommt. Da sieht man jetzt erst mal nicht so viel, außer dass der komplette Bereich nullen sind. Was ich jetzt schon darüber weiß, ist, dass dafür den Fall, dass man in der Brille irgendwie noch mehr gemacht hat und nicht schnell genug die Daten abholen konnte, einfach ein zweites Paket da reingelegt werden kann, dann kann man halt mit einem Transfer das verpasste Paket und das aktuelle Paket bekommen. Als nächstes kann man jetzt also diesen interessanten Teil, wo die Daten drin sind, nehmen und das schon mal farblich markieren. Der erste Grau-Teil ist immer der gleiche, da ist das erste Beid diese Report-ID 0x0c steht halt für den Sensor-Report von diesem Handkontroller. Der weiße Teil des 1c und 00, habe ich keine Ahnung, was das ist. 02 ist die Device-Nummer, das ist 1 für die Fernbedienung, 2 und 3 für die beiden Handkontroller. Das magenterfarbene ist relativ offensichtlich irgendein Little-Indian-Counter. Da stellt sich raus, das zählt einfach Mikrosekunden in Device-Time. Das ist wichtig, um das Intervall zwischen zwei Sensor-Daten Punkte rauszufinden, damit man auch richtig aufintegrieren kann, damit die Rotation stimmt. Jetzt ist er wieder eingeschlafen. Ich muss ihn also bewegt halten, damit er was tut. Dann gibt es zweimal rot-grün-blau und die ändern sich irgendwie, wenn man das Ding bewegt. Das ist X, Y, Z Beschleunigungs-Sensor und Gyro. Man sieht es auch besser, wenn man das jetzt nicht mehr Hexadizimal und Little-Indian darstellt. Das werde ich auch gleich noch machen. Dahinter kommt was Blaues, was türkisfarben ist. Was die oberen Bits sind, weiß ich nicht. Die unteren Bits sind die Knöpfe und wo ist der 4. Das unteren Nibbel von dem türkisfarbenen sind die Knopfdaten. Die weißen übergehe ich mal, das ist ein bisschen komplizierter, weil sie nicht beidweise orientiert sind, sondern die sind irgendwie 10-Bittig oder so zusammen gemixt. Das sind die für diesen Joystick, der da drauf ist und für die Analogentaster. Das gelbe ganz am Schluss stellt sich dann raus, sind die kapazitiven Sensoren. Wenn man das mal anhält, dann sieht man schon, dass in der ersten gelben Zeile sich immer die gleichen Zahlen wiederholen. Das steht immer irgendwie. Das sind also 16-Bit-Werte, die man demultiplexen muss und da vorne sind die Kanalen uman. Das werde ich als nächstes tun. Nee, stimmt nicht. Als nächstes werde ich noch, das habe ich vergessen, das Little-Indian wegmachen. Dann sieht es ein bisschen ordentlicher aus und die Accelerometer und Bürodaten schon mal als Dezimal darstellen. Also das Accelerometer hat offensichtlich ein Auschlag, wenn man es einfach still in eine Richtung hält, je nachdem wie die Orientierung ist. Die Bürodaten in den zweiten Rotglut bauen, die schlagen immer aus, wenn man es gerade dreht. Das ist genau diese Kurve, die man Anfang gesehen hat. Und an den gelben Daten sieht man nicht viel Neues. Der Beschleunigungssensor. Also das, was der Beschleunigungssensor misst, ist ja die Auslenkung durch Summe aus Gravitation und lokaler Besteinigung. Wenn ich es still hinlege, dann ist das die Gravitation. Das ist die Y und Z-Komponente an der Stelle und die X-Komponente sind die 2000er da. Und deswegen ist auch, weil ich gerade bei drei, ja, ne? Wenn ich es still hinlege, sind die Werte in den Gyrospalten hier relativ klein. Die sind um Null rum irgendwie. Man sieht aber, dass die hier einen Offset haben. Man kann aus dem E-Prom lesen von diesem Controller-Gerät. Da ist irgendwie so ein JSON-Pfeil drin. Und da sind jede Menge Floating-Point-Zahlen und unter anderem auch die Offsets und Skalierungsfaktoren für diese Gyros und die Beschleunigungssensoren. Sprich, die sind vorkalibriert und den Drift, den man durch die Integration hat, zu minimieren. Aber ganz unterdrücken kann man hier nicht. Deswegen die Korrektur mit den externen Sensoren. So, und wenn man jetzt hier hinten, jetzt muss ich wieder ein bisschen kleiner machen, die Informationen aus den unterschiedlichen Kanälen, was also das erste Byte von diesen drei gelben war, dem Multiplex und immer alle aufschreibt, die man sich gerade gemerkt hat. Dann sieht man, dass man zum Beispiel an dem hier immer mich den Zeigefinger hochnehme, da irgendwie einen anderen Wert kriegt und was der andere. Das ist der hier. Wenn ich den Daumen hochnehme, kriegt man da irgendwie einen anderen Wert und dann benutzt man das sofort total sinnvoll und macht genau das, was Oculus auch kann, nämlich tolle Gestenerkennung. Okay. Vielen Dank für eure Aufmerksamkeit. Hat jemand Fragen, dann würde ich die gerne entgegennehmen. Der Grund liegt also, im Prinzip ist es, die Frage war, ob man mehr als zwei von den Weißsensoren benutzen könnte. Von den Basisstationen. Im Prinzip gibt es eigentlich keine Limitierung, physikalisch. Im Moment schicken die alle Licht auf der gleichen Frequenz und moduliert mit der gleichen Modulation das irgendwie so eine 2, ich glaube 1,8 oder 2 MHz Modulation drauf, die die Sensoren, die Infrarotioden verstärker benutzen, um das Signal zu erkennen. Sprich, wenn zwei Weiß gleichzeitig, zwei Laserbasistationen gleichzeitig sweepen würden, dann bekommt man Mülldaten, also im Moment zeitlich voneinander getrennt in wohl definierten Fenstern ihre Laser sweepen. Die Firmware, die da im Moment drauf ist, ist ausgelegt für zwei Stationen. Das heißt, in diesen OOTX Synchronisationspulsen gibt es genau drei Bits und ein Bit ist für an oder aus da und im Moment macht eine Basistation halt immer zwei Answeeps und dann macht es wieder zwei Answeeps und dann ist wieder zwei weg und die, die drauf hört, macht es genau andersrum. Sprich, dadurch, dass die Firmware im Moment so ist wie sie ist, kann man nicht einfach eine Dritte kaufen und die da zustellen. Weil selbst, die die Firmware im Griff haben, könnten das theoretisch ohne Problem machen. Ich weiß nicht, ob sich das im Moment schon irgendwie lohnt für die. Vielleicht ist es demnächst mit der nächsten Generation dann irgendwie anders oder so. Also Sie haben es offensichtlich irgendwie vor, ob das einfach mit der Technik gemacht wird, das weiß ich aber nicht. Der Grund, dass es im Moment nicht geht, ist, dass wir die Firmware nicht ändern können. Noch nicht. Also die Geräte im Prinzip sind total offen. Die haben alle irgendwie Mikrocontroller drin und man kann die im Bootloader-Modus starten, kann dann über USB die Firmware reinkopieren. Wer möchte, kann also die Firmware auseinandernehmen und ändern und wieder reinflaschen und wenn es nicht funktioniert, kann dann das Ding wieder in Bootloader starten und eine andere Firmware reinflaschen. Die sind abgesehen davon, dass da halt die Firmware nicht zerflasht war eigentlich. Die Basisstation sollte eigentlich nicht brickbar sein. Die Frage ist, was passiert, wenn man zum Beispiel die Kalibriertaten überschreibt, dann ist sie effektiv geprickt. Wenn du mir jetzt sagen würdest, dass die unbrickbar sind, erwehren oder so, dann würde ich das natürlich mal machen, riskieren. Aber du bist dir nicht sicher, also Kalibrierungsdaten. Also bei einem normalen Firmware-Update-Vorgang. Genau. Werden die Kalibriertaten nicht überschrieben, sprich, wenn man einfach nur den Programmkodeil überschreibt und die Firmware-Update und das geht schief, weil man in der Mitte abbrecht oder so, müsste man sie wieder in den Bootloader-Reset mit dem Bootloader-Reset in den Bootloader-Modus zurückversetzen und das nochmal versuchen. Ja, wir können nachher nochmal darüber... Ich kann es natürlich nicht garantieren, dass es sicher ist, aber nachdem was ich darüber weiß, würde ich davon ausgehen, dass man sie damit nicht kaputt machen kann. Damit, ja, egal. Wir reden später mal darüber. Noch wer ein Wunsch, eine Frage. Nicht gut. Wenn sich jemand für das Thema interessiert, ich bin hier irgendwo unterwegs, ansonsten im ERC auf Renaut unter pH 5 zu erreichen und... Vielen Dank.