Will positional head tracking be activated in the dev kit?

Re: social phobia

Don't freak out dude. I'm often in the same boat (but I probably over compensate by being overly assertive in forums, :lol:). Your comments have been really helpful even if we don't quite see eye to eye. I'm actually trying to figure out what the state of the art is so I can stand on the shoulders of those who've tried this kind of stuff before and your responses have been rather helpful.

Wow guys this is pretty intense! It would seem as the thread I started with an innocent little question could be the start of some real headway into getting positional headtracking working (to some extent anyway). This is a fascinating stuff here people. Keep it up! :)

Check out:

http://www.roadtovr.com/2013/02/15/posittron-diy-oculus-rift-positional-tracking-virtual-reality-3158

and

http://www.roadtovr.com/2013/04/26/immersight-positional-tracking-hmd-translation-5322

or go straight to the source

http://www.mtbs3d.com/phpBB/viewtopic.php?f=138&t=16072

I had considered the possibility of using an IMU for dead reckoning in conjunction with an optical system for positional verification/correction before. The problem is ensuring that the errors can remain low enough between optical corrections, otherwise it's pointless.

It's not really accurate to say that an IMU with a fast refresh will accumulate errors faster than a slower device. Sure, you'll have more samples, each which will have slight errors, but at the same time you gain some accuracy by having higher spatial resolution. With a slower device, there's a greater chance of missing accelerations/rotations.

It is possible to lower the noise floor of a particular sensor by using several of each type on a single IMU, then perform a weighted average or some other algorithm of their values. Also, for sensors that allow external control of their sampling points (such as the accelerometer/gyro in the Rift), spatial resolution can be increased by using multiple sensors and have them sample out of phase from one another. Whether such a configuration would give good enough results for VR positional tracking has yet to be demonstrated, but there are research papers on these "virtual IMUs", one of them here: http://www.mdpi.com/1424-8220/12/2/1720

Another possible option that I have suggested before is adding an additional IMU on the upper torso. Similar to how the Rift's head tracker is used to implement a head+neck model, the torso IMU would be used with a hip-to-neck model. This only provides quasi-positional tracking, but it might be a decent and simple solution for seated use - or standing as long as you don't shift your body forwards/back/side-to-side. However, with such an IMU arrangement, and something like a Wii Balance Board to detect center of balance, you can have a nearly complete motion tracking system (except for vertical movement) given that your feet stay planted.

Those linked videos definitely prove that my suggestion is viable. There is a lot of obvious lag in the video based tracking solutions, but I think accelerometer data could be used to remove that lag. Maybe that is how I should have talked about the idea to begin with. Add in some constraints based on how we expect heads to move and I think video + accelerometers would be compelling.

I really want my Rift because I hate not being able to put up or shut up :)

Hmm, maybe I don't need it. If I was willing to strap a LEAP motion to my head then I shouldn't feel stupid slapping an AR tag on it either...

"jwilkins" wrote:
Ack, I figured out the cubic error thing after I posted and was hoping you wouldn't notice ;-)

I'll try to digest all of the rest what you posted later.

Lol. It's very easy to miss things. I believe I made several mistakes with what I wrote as is. Not to mention the way I phrased the original statement wasn't exactly correct either... XD

"mihalski" wrote:

"KuraIthys" wrote:
Egh. I don't know sometimes why I bother really. ... ...

Now if you'll excuse me I'm going to have to get back to being too scared to talk to people for a bit. Funny how the internet can make it almost seem like I have actual social skills... XD

No! Please bother!

I wish there were more threads like this instead of ones discussing perceived delivery delays and communication inadequacies. Also, your communication skills are more than fine.

Oh. OK. I guess it's nice to know someone appreciates it, even if what I write feels like a pointless mess a lot of the time...

"jwilkins" wrote:
Re: social phobia

Don't freak out dude. I'm often in the same boat (but I probably over compensate by being overly assertive in forums, :lol:). Your comments have been really helpful even if we don't quite see eye to eye. I'm actually trying to figure out what the state of the art is so I can stand on the shoulders of those who've tried this kind of stuff before and your responses have been rather helpful.

Um. Thanks. I'm glad it's helpful in any way, even if it does sometimes just look like a huge argument... XD

I've really been struggling in the last few weeks though. - I've had problems for a long time, but recently I've been getting nervous just being around people, and after several panic attacks it can seem as though you really can't cope with anything.
... Really don't wanna end up being that weird girl that freaks out if anyone so much as looks in her direction...
It may be a bit late to salvage the 'weird' part, but it'd be nice to be able to maintain at least some resemblance of sanity... XD

Ahem... Probably shouldn't have said any of that... :lol:

... Moving on...

"msat" wrote:

It's not really accurate to say that an IMU with a fast refresh will accumulate errors faster than a slower device. Sure, you'll have more samples, each which will have slight errors, but at the same time you gain some accuracy by having higher spatial resolution. With a slower device, there's a greater chance of missing accelerations/rotations.

... Sometimes I do say things without fully thinking them through. - I spent a lot of time last night just thinking through the logic of a system like this, and concluded I'd made a rather critical oversight.

As you mention, if you miss a rotation/acceleration that would throw off the accuracy a lot. Although, that's assuming the slower sensor misses it entirely. - But that's a secondary issue related to trying to track motions which happen over shorter intervals than the sensor in use can identify.
A critical point I missed however, and only realised when I thought through the situation more carefully, is that for a given amount of force, the shorter the time interval, the smaller the calculated position change would be.
If you assume a smooth 1g acceleration taking 1 second, then with 10 samples, you'd have 10 readings all reading 1 g.
But... Stated in m/s^2, this is roughly 10 m/s^2... The velocity increase for each sample takes place over 1/10th of a second, meaning the velocity increases by just 1 m/s in that period. And equally, the position increases by 1/10th of a meter. (I'm being very lax with the effects of acceleration here, obviously.). The error for one reading therefore is some proportion of 1/10th of a meter.

If you increase the sample rate to 100 samples a second in the same scenario, the acceleration remains 1g / 10m/s^2, but the velocity increment is now for 1/100th of a second rather than 1/10th, and thus increases by about 0.1 m/s.
The position meanwhile only increases by 1/100th of 0.1 m or 0.001 - Thus the error for one sample is over a much smaller distance. - After the end of 1 second, obviously, the actual distance would be larger and so would the error, but the conclusion here is that the overall error isn't necessarily larger because of the use of more samples, even if the minimum raw error is the same for each sample regardless of sampling rate, the proportion of error after integration may not increase at the same rate, since the distance covered per sample is probably smaller.


Just as an aside though, the original point of this thread seems to have been to ask whether the current prototype rift headset could do positional tracking.
The answer clearly, is 'not really'... - Because most of the things being discussed here require extra hardware. (Be they cameras, more sensors, or whatever.)
Combining a camera + accelerometer may work... But it still requires a camera. :lol: - which the rift headset does not have as part of it's current design.

Which brings us to home brew setups to do positional, until maybe Dev Kit Rev 2 later this year?

I started looking around trying to figure out what sensor setup the Hydra uses with magnetic fields, wasn't able to find much of use. Which means I'm not looking in the proper places.

Being a closed system I'm assuming the Hydra isn't going to want to track more fields, but you never know what one might get away with. Soooo, anybody know anything about the types of sensors it uses as they appear to be pretty accurate.

"KuraIthys" wrote:
...
Just as an aside though, the original point of this thread seems to have been to ask whether the current prototype rift headset could do positional tracking.
The answer clearly, is 'not really'... - Because most of the things being discussed here require extra hardware. (Be they cameras, more sensors, or whatever.)
Combining a camera + accelerometer may work... But it still requires a camera. :lol: - which the rift headset does not have as part of it's current design.

I believe that postional tracking based on double integration can work for special cases, such as seated, standing or prone positions only. You can only comfortablly shift your balance side-to-side until your head is over your hips, both seated and standing, unless you extend a limb for balance (or lean against something). Forward you can bend a lot, but not backwards (both seated and standing).

I think it is safe to ASSUME (for gaming purposes), that the most common (home) position is standing or sitting upright with head at highest available position. Whenever we detect the home position, we can zero out the velocity, which stops drift and recenters the viewpoint at the home position. We could also detect changing from a sitting to a standing position, and perhaps even add a prone position for sniper action (another known "home" position with head a short distance above the floor).

You can read more in the PDF links I provided in previous posts in this thread (incorrectly attributed in a recent jwilkins post as from a 320x200 post). Just look at the bottom of my (really long) previous post in this thread for the link...

"geekmaster" wrote:

"KuraIthys" wrote:
...
Just as an aside though, the original point of this thread seems to have been to ask whether the current prototype rift headset could do positional tracking.
The answer clearly, is 'not really'... - Because most of the things being discussed here require extra hardware. (Be they cameras, more sensors, or whatever.)
Combining a camera + accelerometer may work... But it still requires a camera. :lol: - which the rift headset does not have as part of it's current design.

I believe that postional tracking based on double integration can work for special cases, such as seated, standing or prone positions only. You can only comfortablly shift your balance side-to-side until your head is over your hips, both seated and standing, unless you extend a limb for balance (or lean against something). Forward you can bend a lot, but not backwards (both seated and standing).

I think it is safe to ASSUME (for gaming purposes), that the most common (home) position is standing or sitting upright with head at highest available position. Whenever we detect the home position, we can zero out the velocity, which stops drift and recenters the viewpoint at the home position. We could also detect changing from a sitting to a standing position, and perhaps even add a prone position for sniper action (another known "home" position with head a short distance above the floor).

You can read more in the PDF links I provided in previous posts in this thread (incorrectly attributed in a recent jwilkins post as from a 320x200 post). Just look at the bottom of my (really long) previous post in this thread for the link...

I'm not entirely sure that's a safe assumption for the home position. I mean, I know I tend to slouch a lot. XD

That aside, how do you detect the 'home' position exactly? I'm far from reading through that entire paper, but much of the initial stuff they mentioned depended on a IMU being attached to a person's foot, and being able to determine reasonably accurately what the signal output was for the short pause when a person's foot is touching the ground.

I'm not so confident the 'home' position you are describing is that easy to measure. - You can't reset the assumed position unless you are confident you are currently in a known position, otherwise you'll just create huge discrepancies instead of improving accuracy.

"Felix12g" wrote:
Which brings us to home brew setups to do positional, until maybe Dev Kit Rev 2 later this year?

I started looking around trying to figure out what sensor setup the Hydra uses with magnetic fields, wasn't able to find much of use. Which means I'm not looking in the proper places.

Being a closed system I'm assuming the Hydra isn't going to want to track more fields, but you never know what one might get away with. Soooo, anybody know anything about the types of sensors it uses as they appear to be pretty accurate.

The best resource I've found for the hydra so far is this:
http://janoc.rd-h.com/archives/212

Basically, a hydra base station is 3 perpendicular coils of wire. (have a close look at it - the base is transparent, and you can see the coils.)

The 'tracker' inside the controller consists of 3 perpendicular 20 millihenry inductors. (which, again is basically just a coil of wire).

To determine position, the base station turns each of it's coils on in sequence, and then pauses. (each pulse is 2 ms - so you get an 8 ms set of pulses consisting of something like 'x coil', 'y coil', 'z coil', 'pause')

In the controllers, the inductors feed into a set of amplifiers. - The signal strength of any given coil relates to the angle between it and the currently active magnetic field, and the distance from the base station.

The short pause would presumably allow determination of the magnetic background. - distance from the base station can be determined from the strength of all 3 coils, and angle can be determined because the signal strength for any one coil in the controller relates directly to the angle between it and the currently active coil in the base station.
So, each active pulse of one of the coils in the base station essentially gives the relative angle between that coil and the 3 perpendicular coils in the controller.
Repeat this for each of the 3 perpendicular coils, and you get 9 readings (plus 3 with just the background magnetic fields)

These readings combined then essentially give you the distance to the base station, heading to the base station, and the orientation of the controller relative to the base station. (Calculating XYZ positions from this clearly requires converting from polar coordinates though.)