Will positional head tracking be activated in the dev kit?

"DieKatzchen" wrote:
In that case I have never seen a mod interfere, although I'm sure they would have. I remember looking at that circuit and going "why is he using 9volts and downvolting it? Why not use AAs?"

His schematic had multiple 9-volt batteries IN SERIES, which could have supplied up to 36-volts to the Rift DK (possibly more than its internal voltage regulator can safely handle). Many step-down voltage regulator components have a maximum input voltage of 24-volts. It has been reported that the Rift DK does indeed contain an internal voltage regulator, so it should be able to handle 12-volts just fine though (even from an automobile accessory jack), without external voltage regulation.

A mod did post a comment in that thread though, which should apply to all threads in all forums:

"cybereality" wrote:
I will leave this thread here, because I think it's an interesting topic and an interesting problem. However I would suggest that people get their facts straight before posting possibly misleading information (especially when it could damage people's hardware).

Regarding potentially-offensive "swear word" editing, that is probably handled automatically by the forum software. However, posts containing personal attacks may be editted or deleted by moderators from time to time, to keep this a "family-friendly" place.

How about using a set of AR tags (or IR LEDs) attached to the headset and a web cam to correct the error from integrating accelerometer readings?

Camera based tracking tends to have a lot of lag. And I can't see them slapping a fiducial on the front and telling everyone to get a webcam. It's not commercially viable for them.

On the other hand, don't let that stop you from trying. It might work better than we think. And until they come out with Rift Mark II we're going to have to hack and experiment ourselves.

Well, you should look at the thread were we are slapping LEAP Motion controllers on our heads/Rifts. You don't expect everybody to buy a LEAP right?

Also, the idea is to use the camera for correcting error, not as the only source of input. I was hoping to hear from somebody who might have tried this kind of approach. The idea is to use an accelerometer to integrate position, and fix any error using another source of input.

People have demonstrated head tracking projects using the Wii's IR camera...

That's a purpose-built tracking camera though. I have no idea what the latency on it is like (I'm not sure how you'd test for it), but it seems quite responsive in it's normal intended role.

The problem with webcams is they have abysmal framerates. (they're designed for 30 fps, but many can't even maintain that).

On top of that, the image processing for optical marker tracking is complex enough to potentially be slow for that reason alone.

The PS eye solves the framerate issue, but the Wii's IR tracker has the benefit of both fast tracking (100 fps), and dedicated built-in tracking hardware that is potentially a lot faster - Although it would require extra calculations to track in 3d space.

The downside to anything involving wii hardware or similar though is that it is difficult to set up, and thus even less likely to get used than a system requiring a webcam.

I'm intending to try some technical comparisons of various head tracking schemes though...
(Specifically, Coloured LED tracking using a regular webcam, and PS eye camera - to see what effects the differences in framerate have, and tracking using a wii remote and IR marker - with controller stationary, and the marker on the headset.)

It'd be good to know what works well as a temporary hack, even if it would prove unwieldy as a permanent solution...

Is TrackIR rotational or does it do positional as well?

I wish people would pay attention and actually respond to my idea as it was proposed.

First of all, I'm not even sure that using a camera for pure positional head tracking would be a horrible idea because a low framerate (interpolated) and latency might be a much smaller problem for position than it is for rotation. So speculating about slow framerate or latency may be misplaced.

Second, the idea isn't to use the camera as a primary means of getting position (but as stated before, nobody has provided any evidence it would present a problem), but only as a correction to the input provided by accelerometers. Could we discuss that, which is what I actually posted about?

That's all well and good, but unless you actually test it, you'll never know.

As for accelerometer based position tracking...

I tried that out once a long time ago, and while I'm sure there is possibility for improvement, let me tell you, those test results were not encouraging.

The result of trying to track position with an accelerometer were such that after about 3-4 seconds, the error was on the order of the reported position being several meters away from the actual position.

Left to run at that rate, after about a minute the reported position could easily be several hundred meters off.

Now, I'm sure you could code something better thought out than what I was doing back then, but the drift is huge.

Using an accelerometer as a PRIMARY data source for position tracking is a really bad idea.
At best it can give you a bit of supplementary data, but if you're thinking it can be the primary source, and you use the camera (or whatever else there is) to correct it, you're being way too optimistic about just how huge the error is for acceleration data.

Remember:
You are trying do determine a position in space;

Starting from accelerometer data,
You first have the error in reported acceleration.

You then need to find the integral of the acceleration to get the velocity,
Then you need to integrate again to find the position.

Each integration step, roughly speaking creates an exponential increase in the amount of error.

Not only that, but the error is cumulative. So, if the original error in reported acceleration is +-0.1 m/s^2, then the potential error in reported velocity is at least +-0.2 m/s, but will gradually increase. For a velocity calculated from 3 values, it's +-0.3 m/s, for 10 values it's +-1 m/s - And at this point you don't even have a position value yet...)


Trying to use acceleration data as your core positional input, in short, is a horrible idea.
If you're going to do this at all, it would be far safer to do the reverse;

Start from known positional data. (provided by a camera of some sort, or whatever other means), then use acceleration data to predict the motion between position updates.
However, how much you'd gain from doing this is questionable, and closely related to the camera's framerate and other issues. - The framerate of the camera determines how much time you'd have to spend performing acceleration based tracking; Which in turn figures in to how much uncertainty you will have to work with.

The uncertainty for anything beyond trivial amounts of time becomes a major issue though; - if it didn't there would be a lot of position tracking applications around already, because accelerometers are all over the place these days.

"KuraIthys" wrote:
As for accelerometer based position tracking... I tried that out once a long time ago, and while I'm sure there is possibility for improvement, let me tell you, those test results were not encouraging.

Ditto. I tried to get position that way once in an iPhone app years back. The results were completely unusable.

"320x200" wrote:

"KuraIthys" wrote:
As for accelerometer based position tracking... I tried that out once a long time ago, and while I'm sure there is possibility for improvement, let me tell you, those test results were not encouraging.

Ditto. I tried to get position that way once in an iPhone app years back. The results were completely unusable.

I posted details about how this is possible and practical (within defined constraints) at MTBS3D:

"http wrote:
Re: Rift Head Tracking; Readily Available?

I read a recent research paper about velocity error compensation in IMUs for positional tracking. It claimed that a new technique was designed after studying human gait analysis, and how various phases of walking could be determined from IMU data. The simple thing I got from it was that the key to accurately determining position from IMU data is to find a stable point of reference that you can assume is periodically at zero velocity, and use that to calibrate velocity. In the case of walking, an IMU was attached to the foot, and every time the foot was on the ground during walking, it could be assumed to be at zero velocity. Zeroing the velocity allowed the positional errors to drop from the typical uncompensated 33% all the way down to about 0.3% positional error.

In that research paper, they gave an example of an early experiment they performed, in which they picked up an object from a table and set it back down one meter away. The IMU mounted on it gave a position that was accurate to within one centimeter (1% error) when using their velocity compensation method, which assumed a zero velocity resting position when the object was set down. This compared favorably to a 33% error when measuring the position using "traditional" double integration methods on the IMU data.

The following information is my own personal extrapolation of this idea, as it can apply to Oculus Rift head tracking.

Although not a subject of that study, I believe that we can assume that the posterior of a seated subject is at zero velocity while leaning forward and back, and from side to side, and "normal" movements typically terminate in a static (zero velocity) position, between "gestures". Just try some normal motions, and you will notice at least a fraction of a second of little or no motion in between typical aperiodic motions. At those points, velocities could be calibrated back to zero so that positonal accuracy is greatly enhanced.

While seated (or standing) we may be able to detect various static positions such as standing upright, seated with upright torso and head looking forward, or laying prone looking through a rifle scope. If we can detect these postures, we can calibrate our positions to them (and our velocities to zero). Even without posture detection, every time we stop and hesitate for a fraction of a second before changing direction, we can calibrate our velocity back to zero.

The result of all using all of these continuous hesitation and posture detections (and recalibrating to them) can be a very accurate estimation of position, with no absolute position tracking needed (which also means no external references needed, such as GPS or magnetic base units or cameras), making this a self-contained "free roaming" solution with no external dependencies. I suspect that adding skeletal model constraints to these calculations (especially for seated postures) could make positional calculations even more accurate.

The reason I posted this here is that perhaps the Rift head tracking can benefit greatly from this velocity and posture recalibration method, to almost completely compensate for velocity and positional drift. Google is not helping me find that research paper on this computer. I will have to check my browser history on my tablet PC, where I was reading that PDF file...

With my extensive background in motion control and analysis, these are the kinds of things that I love to work with and dream about. I am planning to bring a lot of the things I learned in industrial robotics and motion control into my VR creations. They can only add to the realism...
:D

"At

Re: Positional Tracker Requirements?

"MSat" wrote:
@geekmaster

Your best bet at removing the gravity vector from your position calculations is to compare it with gyro data. So say that your accelerometer reports 1G in the Z axis (vertical) and .2G in the X axis (side to side) while your gyro doesn't report any rotation along the X axis (roll) you can deduce that the 1G in the Z axis is the gravity vector, and the .2G in the X axis is a translational acceleration. Of course, you'll always have the issue with random noise which will make it practically useless.

Thanks, I will try that out too.

To use IMUs for free walking position, you need an IMU mounted on your foot, so that it can be completely stopped during a portion of every stride while walking. During that rest period, the calculated velocity is forced to zero so that there is no accumulated drift. The only positional drift is the small amount accumulated while the foot is in motion. Experimental studies showed that positional drift for constrained static state gate analysis as described is only about 0.3-percent. To compensate for that slow position drift, you add GPS to the fusion algorithm to maintain accurate average position. Another source of outdoor positioning information is triangulation of relative signal strength for various Wifi SSIDs in the neighborhood, similar to what google uses. With mobile wifi, perhaps you can use the WiGLE wardriving database:
http://www.irongeek.com/i.php?page=security/igigle-wigle-wifi-to-google-earth-client-for-wardrive-mapping

I want to try using a similar method without a foot IMU, by making simple assumptions about being seated in a chair or standing in one position, which limits how far you can move the Rift (not much beyond your hips, to maintain balance). And I plan to assume you spend most of your time in a fully upright centered position. That should allow us to look around objects naturally, and may help reduce motion sickness.

And the Rift SDK does set the range to +/- 2G, which is clearly visible in the output data from my modified version of the "Minimal Oculus" demo from the OculusVR wiki. And the SDK headers set the default range to 4G, so that matches.

What is not clear is the SDK headers say the acceleration data should be 1000 times larger than what is being returned, which is why I had to set the standard gravity so small to compensate. Perhaps that will be fixed in the next SDK version.

Here are the documents I referenced in various posts:
http://www.cl.cam.ac.uk/research/dtg/www/files/publications/public/abr28/ojw28_thesis.pdf
http://www.xsens.com/images/stories/PDF/Inertial%20and%20Magnetic%20Sensing%20of%20Human%20Motion.pdf

I hope this information is useful to this discussion. If not, please disregard... :mrgreen: