Reverse Engineering the Oculus Rift DK2's Positional Tracking Tech

An anonymous reader writes The Oculus Rift DK2 VR headset hides under its IR-transparent shell an array of IR LEDs which are picked up by the positional tracker. The data is used to understand where the user's head is in 3D space so that the game engine can update the view accordingly, a critical function for reducing sim sickness and increasing immersion. Unsurprisingly, some endeavoring folks wanted to uncover the magic behind Oculus' tech and began reverse engineering the system. Along the way, they discovered some curious info including a firmware bug which, when fixed, revealed the true view of the positional tracker.

40 years later, Twinkle Box makes a comeback.

[Animats]

The Oculus Rift tracking method, with various lights blinking at different rates, was first used in Twinkle Box [researchgate.net], in 1974. It was really clunky then. They had to use rotating-disk cameras because vidicons had too much lag, and the wearer had to wear a big electronics box. Same idea, though.

Re:

[ledow]

Yes, it's not new and I imagine it still suffers from the same problems it always has (multiple frames required in order to identify which LED it actually is, sync issues requiring extra cabling, etc.).

Article barely mentions me...

[Jherico]

I think that the article kind of unfairly glosses over my contribution. I posted the original reddit thread, and I'm the one who discovered the codes required to actually enable the LEDs on the device. I appreciate that Oliver is an actual VR researcher, but I did this in part to get some visibility for the book I'm writing on Oculus Rift development [manning.com].

Re:Article barely mentions me...

[Jherico]

Anyone with the SDK can get these codes. Oh, and you made a thread on Reddit.

Really? Oliver explicitly said he'd had no luck in getting the codes. The SDK doesn't contain them, btw. Only the Oculus runtime, which is closed source, now communicates with the hardware. So, anyone who had the SDK and could also figure out how to write a DLL to intercept the HID calls made by the runtime (not the SDK, which doesn't contain the codes anywhere) could get the codes.

Re:

[Jherico]

It's not hard to monitor HID, lol. None of this is hidden, buried, or secret. It's just not published. Anyone who has the SDK can easily do what you did.

Thank Captain Hindsight. Sure, technically anybody could have done it. But no one else actually did it, despite the numerous Linux developers complaining about the total lack of positional support for them. It's pretty easy to look at someone else's work and say "Oh, yeah, that's obvious" once they've actually done it. I don't really see why you've bothered commenting since you seem to be of the opinion that the entire exercise was pointless. If you don't buy into the entire premise of the article how

Re:

[Anonymous Coward]

A few things:

There is no SDK on Linux, so they couldn't just use the binary that comes with the SDK to control the LEDs. The first thing they had to do was figure out how to turn on the LEDs without the SDK. Everything else hinges on that. Even if you think that's not difficult, Jherico was the first to do it and share his findings, thereby saving everybody else some time and putting the initial lines onto the blank sheet of paper: Finding a starting point is a major stumbling block for many people, so that

Re:Article barely mentions me...

[blueshift_1]

Welcome to the internet where the facts are made up and citations don't matter...

Re:Article barely mentions me...

[ArcadeMan]

Welcome to the internet where the facts are made up and citations don't matter. - ArcadeMan

Article mentions me!

[Jherico]

Never mind. They've corrected the article.

Re:

[schweini]

Sorry to highjack this thread for an OT question, but: Do you know if there is a way to emulate OR DK2's tracking data? I would like to homebrew a very poor man's Oculus Rift. The screen should be no problem, and there are many IMUs available - but how would i get an Oculus-enabled game to read the IMUs data?

Re:

[Jherico]

The Oculus SDK license specifically forbids using it to connect to non-Oculus hardware. On the other hand, they've recently released the full specs of the DK1 as open source, so it's now possible to legally build a piece of hardware that the SDK itself can't distinguish from the real thing. Hypothetically speaking, since the most recent version of the SDK relies on a runtime to communicate with the hardware, if you could spoof the runtime communication (which happens over a socket) then you could use any

Linux

[Anonymous Coward]

Unsurprisingly, some endeavoring folks wanted to uncover the magic behind Oculus' tech and began reverse engineering the system.

No, what they actually wanted was to use the SDK under Linux. Oculus says they support Linux on their dk2 website: http://www.oculus.com/dk2/

The Oculus Rift and the Oculus SDK currently support Windows, Mac OS X, and Linux.

They neglect to mention that now 2.5 month after the dk2 (windows) release, they still do in fact *not* support linux and they still don't know whether Linux will be supported in their next release: https://developer.oculusvr.com/forums/viewtopic.php?f=20&t=15318&status=1#p201687

Oculus has shown that there is probably nothing of lower priority than actually sup

Re:Linux

[Jherico]

I understand this point of view, but on the other hand, I think that the VR killer app hasn't been found yet. The 'mainstream' equation works both ways. Sure there's a bigger potential customer base for VR apps running on Windows and OSX, but I think there's a bigger 'idea base' for new VR apps with hackers running Linux.