Positional tracking calibration

"edzieba" wrote:
The problem is that accelerometer drift is massive and rapid (see the previously mosted Google Tech Talk. Over 8 metres of drift within seconds!). You can't wait until you can make a reasonable guess that the users head is in a certain position, you need to re-set to a rigidly known location rapidly and regularly.
...
A seated user is not constrained. The range of movement you can perform even without minor lifting out the the chair is enormous. Movements are not regular or rigidly pathed, are not repeating, and while there is a natural zero position, it has no distinctive characteristics to allow it to be distinguished from IMU data alone (unlike in the foot-mounted case, where all gyros would read zero, and the accelerometers would only read a stationary g-vector in a known direction), as you cannot keep your head perfectly stationary and do not naturally return your head to centre between movements. You need an additional external input to provide the reset data, and this means either manual re-setting or an absolute tracking system (making the inertial system largely redundant).
...
Yes, free-moving inertial navigation can be done, and has been done for as long as viable ICBMs have been deployed. It is possible. What is not possible is doing so with commercially available MEMS devices at a price affordable to someone outside a government research lab or large university.

I think we are talking about different things, to some extent here.

I am using positional "gesture detection" that closely mimics normal positional head tracking, so that it will be easy to "learn" and to use. I am using predefined "attractor points" on a grid one IPD apart, and I am moving to the next grid point at a speed determined by actual head motion. I plan to fine-tune this later, but locking your possible head positions to nearby points is vastly superior to ignoring head motions. I believe it will be a useful tool for games. My method does not drift because the "gravity" of the attractor point exceeds the drift rate.

I plan to add calibrated magnetic anomaly detection to supplement my head tracking, using such magnetic "distortions" as fiduciary markers. Nearby ferrous objects and emitted magnetic fields can not only be used for tracking, but I plan to visualize them by changing the pixel colors when viewing their locations. I think that viewing magnetic fields will be a cool use for the Rift DK, but even better if I can walk around my building recalibrating my position to mapped magnetic anomalies.

Regarding that huge drift you mentioned, I am not seeing that, but I may be using a "non-traditional" approach (i.e. constrained jerk-vector with gesture-based target attractors). And yes, the end user DOES need to learn to use it within its design constraints, but that will be very intuitive. I think it will be a very welcome addition, compared to the current method of IGNORING head movement.

Remember, we are talking about GAMES here, not real-world navigation (yet). Even a non-accurate method of head tracking can be useful. ... or ARE you planning to use your Rift in an ICBM guidance system?
:o

"geekmaster" wrote:
I am using predefined "attractor points" on a grid one IPD apart, and I am moving to the next grid point at a speed determined by actual head motion. I plan to fine-tune this later, but locking your possible head positions to nearby points is vastly superior to ignoring head motions. I believe it will be a useful tool for games. My method does not drift because the "gravity" of the attractor point exceeds the drift rate.

So if I'm understanding correctly, the user can 'jump' their viewpoint between preset locations in space, as long as they move their head rapidly enough between them to overcome the correction factor (i.e. all measurable accelerations must be higher than the integrated noise)? I can see that working if you can characterise the sensor noise well, but I think that sort of jerking disconnected motion will be very nauseating.

I plan to add calibrated magnetic anomaly detection to supplement my head tracking, using such magnetic "distortions" as fiduciary markers. Nearby ferrous objects and emitted magnetic fields can not only be used for tracking, but I plan to visualize them by changing the pixel colors when viewing their locations. I think that viewing magnetic fields will be a cool use for the Rift DK, but even better if I can walk around my building recalibrating my position to mapped magnetic anomalies.

I'm not sure the magnetometers in the IMU are sensitive enough to perform anomaly mapping from natural field peturbation, unless you seed your area with powerful coded fields (i.e. some sort of pulse modulation). You'd lose geomagnetic yaw correction, but if the magnetometers are responsive enough for you to code your field pulses rapidly, you could build a multi-transmitter triangulation tracking system. I don't think 3-axis chip magnetometers are that responsive, though; most average over time in order to get a stable output (but that may just be because they are designed to detect the weak geomagnetic field).

Remember, we are talking about GAMES here, not real-world navigation (yet). Even a non-accurate method of head tracking can be useful.

The latency and accuracy constraints on orientation head tracking apply to positional head tracking too. Position is slightly more forgiving (see Hydra-based position tracking combined with IMU orientation being acceptable), but it's still a case where you either do it well or not at all; not having good enough tracking is worse than no tracking, due to nausea effects.

"edzieba" wrote:
So if I'm understanding correctly, the user can 'jump' their viewpoint between preset locations in space, as long as they move their head rapidly enough between them to overcome the correction factor (i.e. all measurable accelerations must be higher than the integrated noise)? I can see that working if you can characterise the sensor noise well, but I think that sort of jerking disconnected motion will be very nauseating.

No "jump". It takes very little motion to move away from an attactor point, while still preventing drift. Also, the motion will track head motion until you get near an attractor, which will recalibrate velocity to zero when reached. I think the user will learn to match his head movements to these attractor points, just like cymatic bruce recommends wobbling your head during head bobbing in a video game, to prevent motion sickness. And a user can always turn off positional head tracking if it bothers him. My experience so far seems quite encouraging.

"edzieba" wrote:
I'm not sure the magnetometers in the IMU are sensitive enough to perform anomaly mapping from natural field peturbation, unless you seed your area with powerful coded fields (i.e. some sort of pulse modulation). You'd lose geomagnetic yaw correction, but if the magnetometers are responsive enough for you to code your field pulses rapidly, you could build a multi-transmitter triangulation tracking system. I don't think 3-axis chip magnetometers are that responsive, though; most average over time in order to get a stable output (but that may just be because they are designed to detect the weak geomagnetic field).

You may be right, but it seems like it should be able to detect permanent magnets too (not just pulsed fields), and I have not problem planting magnetic seeds in my area if that aids positional tracking. It may be slow, but we also have inertial navigation to fuse with it.

"edzieba" wrote:
The latency and accuracy constraints on orientation head tracking apply to positional head tracking too. Position is slightly more forgiving (see Hydra-based position tracking combined with IMU orientation being acceptable), but it's still a case where you either do it well or not at all; not having good enough tracking is worse than no tracking, due to nausea effects.

I think we can use gesture-based head tracking to known target points, and (mostly) avoid nausea. In any case, I will continue my experimental tuning of my code and try to optimize it for minimum nausea. And users will be able to disable it if they do not like it. How can it be worse than the current method of ignoring head translation?

"geekmaster" wrote:

"edzieba" wrote:
The problem is that accelerometer drift is massive and rapid (see the previously mosted Google Tech Talk. Over 8 metres of drift within seconds!). You can't wait until you can make a reasonable guess that the users head is in a certain position, you need to re-set to a rigidly known location rapidly and regularly.
...
A seated user is not constrained. The range of movement you can perform even without minor lifting out the the chair is enormous. Movements are not regular or rigidly pathed, are not repeating, and while there is a natural zero position, it has no distinctive characteristics to allow it to be distinguished from IMU data alone (unlike in the foot-mounted case, where all gyros would read zero, and the accelerometers would only read a stationary g-vector in a known direction), as you cannot keep your head perfectly stationary and do not naturally return your head to centre between movements. You need an additional external input to provide the reset data, and this means either manual re-setting or an absolute tracking system (making the inertial system largely redundant).
...
Yes, free-moving inertial navigation can be done, and has been done for as long as viable ICBMs have been deployed. It is possible. What is not possible is doing so with commercially available MEMS devices at a price affordable to someone outside a government research lab or large university.

I think we are talking about different things, to some extent here.

I am using positional "gesture detection" that closely mimics normal positional head tracking, so that it will be easy to "learn" and to use. I am using predefined "attractor points" on a grid one IPD apart, and I am moving to the next grid point at a speed determined by actual head motion. I plan to fine-tune this later, but locking your possible head positions to nearby points is vastly superior to ignoring head motions. I believe it will be a useful tool for games. My method does not drift because the "gravity" of the attractor point exceeds the drift rate.

I plan to add calibrated magnetic anomaly detection to supplement my head tracking, using such magnetic "distortions" as fiduciary markers. Nearby ferrous objects and emitted magnetic fields can not only be used for tracking, but I plan to visualize them by changing the pixel colors when viewing their locations. I think that viewing magnetic fields will be a cool use for the Rift DK, but even better if I can walk around my building recalibrating my position to mapped magnetic anomalies.

Regarding that huge drift you mentioned, I am not seeing that, but I may be using a "non-traditional" approach (i.e. constrained jerk-vector with gesture-based target attractors). And yes, the end user DOES need to learn to use it within its design constraints, but that will be very intuitive. I think it will be a very welcome addition, compared to the current method of IGNORING head movement.

Remember, we are talking about GAMES here, not real-world navigation (yet). Even a non-accurate method of head tracking can be useful. ... or ARE you planning to use your Rift in an ICBM guidance system?
:o

I think that if your calibration is (even a little) false, the player will be subject of motion sickness.
Cuz your brain can detect what is a total natural movement, and an approximative one.

"Tgaud" wrote:
... I think that if your calibration is (even a little) false, the player will be subject of motion sickness.
Cuz your brain can detect what is a total natural movement, and an approximative one.

In which case it needs to be a user-selectable option. I think it is preferable over ignoring head translation like the SDK and apps.

My code currently uses jerk vectors (differential acceleration) to remove gravity, but that causes translation when you roll. So I am trying to get gravity vector subtraction working correctly now. I tried adding this to the OculusWorldDemo app, but I did not get it to work correctly yet:
http://www.varesano.net/blog/fabio/simple-gravity-compensation-9-dom-imus
Perhaps some axes need swapping or something, or perhaps I should just subtract a Euler angle vector instead of the quaternion orientation.

As it is, the Rift ALREADY causes queasiness for some people, and perhaps my method will give them a better experience in some cases. In any case, I like it and I plan to continue to improve it. My first test was in the SensorBox app, and other than the roll problem it seems to work pretty good. I want it in an FPV app now (with better gravity compensation), so I can see whether it makes motion sickness better or worse. I think it will be an improvement over ignoring motion althogether...

I think if you approximate the head movement you will suffer less motion sickness than if you ignore it altogether.

The approach with a few standard head positions is probably a good one. There are some scenarios where the application may be able to make an educated guess about theh most favorable/likely head movements, i.e. you are standing in front of a wall near a corner? You probably want to peek around the corner.

You are standing in front of a low hanging tree branch that is blocking your view? The user will be inclined to duck. Etc.

If the accelerometer readings roughly indicate such a movement, it's likely that it matches what the player actually did.

"sven" wrote:
I think if you approximate the head movement you will suffer less motion sickness than if you ignore it altogether.

The approach with a few standard head positions is probably a good one. There are some scenarios where the application may be able to make an educated guess about theh most favorable/likely head movements, i.e. you are standing in front of a wall near a corner? You probably want to peek around the corner.

You are standing in front of a low hanging tree branch that is blocking your view? The user will be inclined to duck. Etc.

If the accelerometer readings roughly indicate such a movement, it's likely that it matches what the player actually did.

Exactly! And in some cases, a game may even provide recommended target viewpoints for the positional head tracking gestures to move to. But for other games, we can provide some default "3D detent" positions (attractor points).

The way I envision this (inside my head) is sort of a 3D version of how QAM decoding works (Quadrature Amplitude Modulation, as used in cable TV). You have a bunch of "buckets", and you select the closest bucket to where your "decoding" ends up:
http://vlsi-india.org/vsi/download/publications/archive/Euclidean-Distance.pdf

In a game, you could even highlight such recommended positions that a user SHOULD move to (to reveal hidden secrets from a new vantage point).

Positional gesture recognition should be quite easy for users to adapt to, I think. Certainly better than ignoring head movements, as we do now. And we can keep both Hydra controllers in our hands where they give us more control.

Why do you bother...
Just made PROPER position tracking, with PROPER technology like RF.

"Tgaud" wrote:
Why do you bother...
Just made PROPER position tracking, with PROPER technology like RF.

Do you have a financial interest in RF position tracking equipment sales? If not, then what is your problem here?

I will answer your question anyway, even though you will probably ignore my answer:

Because SOFTWARE can be downloaded, but hardware must be purchased, and shipped, and waited for...

And RF requires FCC (and other) certification, which is incredibly expensive for a small production run, and will add a LOT to the manufacturing cost. And each design change requires recertification. Even a DIY RF kit will be way beyond the means (money and skill) of most Rift owners...

That is why!

Why are you so argumentative and discouraging about a software solution?




http://knowyourmeme.com/memes/subcultures/trolling

why are you telling BS ?

There is not need of FCC certification for the RF used here.
they are very short range RF so no certification needed.

And we are talking of taking the RF thing Inside The rift.

I dont see why we should bother with "simlation" when you can make "real" thing.
that's not the spirit of the rift.

It must be a complete all in one solution of Head tracking (including position tracking) .