Skip to main content
Inspiring
May 17, 2013

Positional tracking calibration

I'm still hopeful regarding the idea of approximating positional tracking for scenarios with limited mobility (e.g. the users sitting on a chair) with the accelerometers inside the rift tracker.

I think it may be worthwhile to capture real positional data recorded by a different system (Razer Hydra, MS Kinect or PS Move) and correlate it with the readings from the sensor.

Do you think this is worthwhile? Has anyone tried it?

    74 replies

    Up and Coming
    June 19, 2013
    I only have a few courses at a polytechnic to account for experience of control theory, but I have not let that stop me before.

    http://en.wikipedia.org/wiki/List_of_bones_of_the_human_skeleton

    This, for example, is an inverted pendulum. Standing on one's hind-legs isn't easy, and when we reach out with our arms our head has to move to keep the balance. Toddlers fall over a lot.

    But I think there are reason for why there should be a skeleton which is transferable between the player and the avatar. Some of those reasons may be tied to the 'virtual human' research... and I think Computer Vision projects such as OpenCV have robust skeletal models which we could ninja. Stuff like, you give its head a value and then it tells you if that value is OK to go with or Not OK.
    Up and Coming
    June 19, 2013
    I just downloaded the latest version of OpenCV two days ago. ;)
    This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
    svenAuthor
    Inspiring
    June 19, 2013
    So, geekmaster, almost a month ago you wrote
    "geekmaster" wrote:
    I already have some rudimentary constrained positional tracking working.

    Now, with more than half of all posts in this thread being yours... it's time to "man up", "put your money where you mouth is", how about a little "sneak peek"? :mrgreen:
    Up and Coming
    June 19, 2013
    "sven" wrote:
    So, geekmaster, almost a month ago you wrote
    "geekmaster" wrote:
    I already have some rudimentary constrained positional tracking working.

    Now, with more than half of all posts in this thread being yours... it's time to "man up", "put your money where you mouth is", how about a little "sneak peek"? :mrgreen:

    Yeah, too much of my available free time in the forums and not enough in the code. That is why I downloaded OpenCV. I really need some Inverse Kinematics to put some bones between the Rift and the chair. But I suppose I could release something without that. I have a mix of C code using raw hidapi, and patches to OculusRoomTiny, and SensorBox, and OculusWorldDemo. I have been migrating code snippets into OculusWorldDemo, but I am thinking that OculusRoomTiny may be a better framework, just to keep things simple.

    The key concept is to calibrate the code to the Rift tracker, and although it works with mine just fine, I need a simpler calibration procedure to adapt to other Rifts. I also had to set my "not moving" calibration thresholds just above the noise level from my sensors, and those may need to be calibrated for different Rifts as well. I would really like to implement some sort of automatic calibration. Currently, I need support my Rift on my desk, with each orientation of each axis down, to measure per-axis accelerometer range and offset adjustments. In my Rift, they are significantly off, even in the demos, even though those demos seem to work well enough. My code needs them calibrated more accurately so that it can be more sensitive to subtle motions (smaller noise threshold values).

    Even after I release some "alpha" code, it will still require making it more portable for other Rifts. I was thinking the auto-calibrate function could use sensor fusion with a Razer Hydra mounted on the Rift, and then could function later without the Hydra... Just ideas...

    I have SO MANY different projects I am working on. Most recently, I was working in my stereoscopic panorama code, and before that my combined GMsphere+mplayer code. And code snippets for many other projects too. I need to get back to this project, because I think more people can benefit from it. Sadly, sometimes after I have implemented something just far enough to prove to myself that I can do it, I move onto other projects and never do get it ready for release. Although this will only have limited use (consumer Rifts will have hardware positional tracking), there are plenty of Rift DK users who could use this software-only version. Soon (within the next four weeks)...
    :D

    I really do not like posting unfinished code, because my coding style is rather unique (attuned to my "coding trance" requirements) and some people who are addicted to white space in source code complain about my condensed coding style as "obfuscated". It really benefits ME that way though... But it does hurt my feelings to publish something people say is awesome (capability and features) but then complain about my source code. I say to run it through AStyle and reformat it to your preferred method, instead of complaining... So I am torn between publishing what I have now, and waiting to publish what may make more people happy (later).
    :?:

    And I have robotics and FPV projects I am working on too, you know... ;)
    This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.