Skip to main content
jherico
Inspiring
October 3, 2014

Linux 'putting your money where your mouth is' thread...

So, the Linux 'nagging thread' has kind of dragged on for a while. Oculus has pledged Linux support, but given no ETA on when we'll see positional tracking supported for DK2. It could be this week. It could be months.

However, I think that sitting around and waiting for Oculus to solve the issue kind of goes against the spirit of Linux anyway. If you want something done, you should be willing to do it yourself. To that end, I'm working on porting the current 0.4.2 SDK to Linux. I've managed to reverse engineer some of the code required to interact with the LEDs so that they can be turned on. The camera is natively supported. Right now the primary missing component to getting this done is the software for calculating a head pose based on an image from the camera.

Unfortunately this kind of math is outside my field of expertise. So I'm putting a call out to the community to see if interested parties might be able to assist with this.

If you want a Linux SDK and don't want to wait for Oculus to get around to it, and you've got the skills, here's a video of them captured from the webcam on Linux:




You can download original file from here: https://s3.amazonaws.com/Oculus/oculus_rift_leds.webm

If you can write C or C++ code that will take that video, or an image from that video, and turn it into a head pose, let me know and I'll work with it to produce a viable Linux SDK with positional tracking.

    44 replies

    Show previous replies
    matus
    Up and Coming
    October 4, 2014
    An open sdk for rift is a great idea. I think it's necessary if you wish to experiment with stand-up experience, eye-tracking or other stuff that oculus refuses to tolerate with their sdk.

    As already mentioned, it would be helpful to see the output of the camera when the leds are controled with the oculus sdk and then reproduce the modulation. 3D model of the relative led location is also necessary. Finally, you need an external sensor to test and validate the algorithm.

    Personally, I plan to ditch the cheap camera solution (that's what oculus calls it in the talk linked above) altogether and use the priovr head sensor instead. Unfortunately, the delivery of priovr is also late - looks like no one in VR indurstry is able get things done on time :roll:
    swsmith
    Participant
    October 4, 2014
    I also think an Open VR SDK would be a great idea given Oculus move towards closed source. The first thing we would need to implement the camera position tracking is:

    1) An LED numbering scheme and careful measurements of the XYZ LED positions on the headset relative to some fixed point on the headset. If Oculus was feeling nice the could provide us with this data.

    2) Some video with a mask for each frame indicating which LED's are on for that frame. If we could get a capture of what Oculus is doing we could use a similar scheme for modulating the LED's state to identify them.
    http://www.angryoctopus.co.nz
    nuclear
    Up and Coming
    October 4, 2014
    While indeed a LibOVR-quality full pose estimation might be a big and involved project (but not without merit due to the possibility of obtaining a full free software SDK out of it), I think that, as a more immediate goal, it would be quite easy to calculate a rough 3 DoF head position, by treating the LED image as a blob and using its 2D center position and projected screen size (to derive Z distance).
    We already have rotational data from the other sensors, so apart for correcting yaw drift, rotational information from the pose estimation is not strictly necessary.
    John Tsiombikas webpage - blog - youtube channel
    vrcoder3d
    Participant
    October 4, 2014
    How would one go about estimating an actual scope of work to achieve a robust, open-source positional-tracking solution?

    Because maybe if we could scope it out with more precision than faith-based beliefs... there could be a way to partition the problem more incrementally (and have it solved sooner).

    Also I question whether positional tracking is in fact just a matter of maths... the same way I question whether virtual reality is just a matter of binary numbers and photons. :)
    blackguest
    Participant
    October 6, 2014
    Dear Oculus developers, please read this, and chime in with hints http://doc-ok.org/?p=1095. Thanks.
    pH5
    New Participant
    October 6, 2014
    "blackguest" wrote:
    Dear Oculus developers, please read this, and chime in with hints http://doc-ok.org/?p=1095. Thanks.

    Thank you, that is a great write-up!

    I have done some USB tracing on a Windows machine and have figured out how to read the Camera's EEPROM and how to enable the exposure synchronization. There is a block of data at 0x2000 in the EEPROM that I hope encodes the lens distortion parameters:

    00002000  00 89 97 e2 7a 00 01 00  09 00 fe 57 c1 af 00 00
    00002010  0c 00 63 1a dc 83 e7 ca  85 40 01 00 0c 00 f4 3c
    00002020  f4 46 b8 cb 85 40 02 00  0c 00 42 d2 37 0a 31 bf
    00002030  77 40 03 00 0c 00 4c 32  ee 7a fe ac 6c 40 04 00
    00002040  0c 00 f8 1a 08 80 b9 3d  e0 bf 05 00 0c 00 f4 1b
    00002050  eb e1 e0 f7 d4 3f 06 00  0c 00 fe a7 2f 24 67 4b
    00002060  3b 3f 07 00 0c 00 c1 6f  08 a3 8f 14 53 3f 08 00
    00002070  0c 00 8b e6 c0 de 56 2d  c0 bf ff ff ff ff ff ff

    I have uploaded my code here: https://github.com/pH5/ouvrt
    creepytennis
    Participant
    October 6, 2014
    This all looks fantastic, and completely fascinating. I'll try hard to find time to participate in the hacking! Thanks so much for your work so far.

    An open driver stack will be a huge benefit for the community, and actually for Oculus themselves too.
    vrcoder3d
    Participant
    October 6, 2014
    While others work on the maths I've been looking across communities for ways to strengthen our own.

    One of greatest community shortcuts I've rediscovered is how a Blender developer offers a VirtualBox .vha image http://wiki.blender.org/index.php/User:Ideasman42/ArchLinuxVirtualBox -- literally, you download, launch with VirtualBox tools and are sitting at a productive Blender dev prompt -- replete with all necessary tools including an IDE.

    Perhaps such an instant-on "VR dev image" is something we could work on as a community, in parallel to (and in support of) ongoing lower-level efforts?

    In theory such a tool would immediately foster an influx of new hands to help in general, with even those on Windows and OS X able to boot within a VM and test Linux-side features like distortion.

    I'm thinking a remastered Ubuntu LiveCD .iso would be sufficient if it had a pre-installed IDE and relevant github SDK pointers. The README then might only need three bullets:
    Step 1: Download a bootable .iso
    Step 2: Boot it into any x86_64 machine (or VM container)
    Step 3: ~90 seconds later, hit F5 to debug some example C++ code (etc)

    Do we think this is a good idea? If so, does anyone have experience remastering LiveCDs yet? And what open source IDE might offer newcomers to VR (and potentially Linux) the most pleasant first-time experience?
    blackguest
    Participant
    October 6, 2014
    "vrcoder3d" wrote:

    One of greatest community shortcuts I've rediscovered is how a Blender developer offers a VirtualBox .vha image...


    I really like this idea
    okreylos
    New Participant
    October 6, 2014
    "vrcoder3d" wrote:
    Do we think this is a good idea? If so, does anyone have experience remastering LiveCDs yet? And what open source IDE might offer newcomers to VR (and potentially Linux) the most pleasant first-time experience?


    I've made a (very) experimental live respin of Fedora 20, including Nvidia's vendor-supplied binary GPU driver and our entire VR software stack. It boots directly from USB stick, but it obviously can't run inside a VM due to lack of GPU access. The idea was to make it easier to test-drive our software, but it could serve as a starting point.
    Show more replies
    Terms & ConditionsAccessibility statement