Inspiring

Positional tracking calibration

74 replies
20502 views

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?

Show previous replies

edzieba

Up and Coming

"geekmaster" wrote:
While seated or standing in a fixed position, your anchor position is a dynamic combination of your median range-of-motion position and your long-term mean position.

The point of an anchor position is for it to be absolutely static. If it is not static, it is useless as an anchor (averaging over time just means averaging your noise over time too, which is exactly what you need the anchor position to avoid doing).

I am seeing the gravity vector magnitude vary significantly as I statically support my Rift at different orientations

If you re-watch the previously linked google tech talk on sensor fusion (do it, it's a really excellent overview of how the process works!), you'll note that the major source of noise in trying to estimate position from an IMU is not really double-integration of the noise from the accelerometer, but double-integration of the mis-estimation of the g-vector. You need to very accurately know the g-vector in order to cancel it from the accelerometer date, but the accelerometer is what you're using to estimate your g-vector! Even using a gyro to track the change in orientation and assuming a totally static geogravitational environment (a safe assumption unless you're travelling at high speed over a long distance), MEMS gyros are not accurate enough to keep track of the g-vector. That's why the IMUs used in military Inertial Navigation Systems are ring-laser gyros rather than MEMS gyros (and even then, their spherical error porbability continuously increases every second they are removed from an absolute anchor location).

geekmaster

Up and Coming

"edzieba" wrote:
The point of an anchor position is for it to be absolutely static. If it is not static, it is useless ... If you re-watch the previously linked google tech talk on sensor fusion (do it, it's a really excellent overview of how the process works!), you'll note that the major source of noise in trying to estimate position from an IMU is not really double-integration of the noise from the accelerometer, but double-integration of the mis-estimation of the g-vector. You need to very accurately know the g-vector in order to cancel it from the accelerometer date, but the accelerometer is what you're using to estimate your g-vector! ...

I know all about that stuff. I watched that video long before you posted the URL. I know about military IMUs (even the ones with MEMs gyros along with their built-in atomic clocks).

This is NOT a military application. This is for a GAME! Not navigation. Not even for trying to align to real-world props. Just good enough to let you look around obstacles a little without needing to stick a hydra controller on your head.

I do not intend to ESTIMATE the g-vector. I plan to MEASURE it, over a long-term average for each direction of each axis. I will use that ACCURATE (axis-compensated) g-vector to while estimating my approximate positions within my constrained boundaries. While seated, there is a limit to how far you can lean comfortable without arm support. Those limits establish boundaries, inside which we define our anchor.

I believe that medians and means will work well enough for my intended application AFTER the user calibrates each accelerometer axis (six directions) to measure its contribution to the gravity vector in each direction. This will let me determine the range and offset for each axis AND the actual measured gravity constant at the user's geographic location.

As I said, my code already works well enough even WITHOUT such calibration, to verify (to me) that it will work FOR MY APPLICATION. Users may enable or disable it at will. I think that many will choose to enable it. You may choose to ignore it. But you may not stop my progress. If you wish to argue semantics over my use of words like "anchor", I wish to NOT participate in that debate.

Like my many other contributions to the public domain and open source for the past FORTY years, I am doing this for my OWN personal use, and for my own personal satisfaction. Even *IF* I were to fail at this attempt (which is VERY unlikely at this point), I will still have learned a lot, and that is all that really matters to me. I rarely fail at anything I attempt, and certainly not at things that I believe in. I believe in this. Look at how many times Edison failed at his experiments before he finally succeeded to produce a viable lightbulb. Even a failure this time will not stop me. I will try other methods until I succeed, because I believe that I can do it.

I have found MANY times that others are very happy to use tools that I create for my own personal benefit, but which I choose to share freely with others. If that bothers you, that is no concern of mine. You are free to be bothered by anything you choose...

EDIT: We both believe in our own personal opinions, and we can both find "expert evidence" to support our point of view. What REALLY matters most is NOT your need to feel superior by proving that "somebody is wrong on the internet". What really DOES matter is that one of us is working FOR progress, and the other is working AGAINST progress. It is no concern of yours how I choose to spend my time, as long as I am not harming you or others. I am sure that most of my readers will agree with me. I have no time for bullies and trolls. If you do not like my posts then do not read them, or at least do not respond to them unless you have a useful contribution that will ASSIST my progress. I am not aiming for accuracy. I am only aiming for enhanced immersion and utility. I already know from my GMsphere experiments that accuracy is much less important than believable and predictable continuity, and that is all I aim for here.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

edzieba

Up and Coming

"geekmaster" wrote:
I do not intend to ESTIMATE the g-vector. I plan to MEASURE it, over a long-term average for each direction of each axis.

What are you using to measure the g-vector? The gyros won't work, they drift. The Accelerometer can provide an absolute vector, but noisy. And that's even if you hold it stationary, if you're moving you have no measure of what contribution gravity provides and what is acceleration from movement. That is why the g-vector acquired from filtering the accel and the gyros is an estimate, not a measurement.

What REALLY matters most is NOT your need to feel superior by proving that "somebody is wrong on the internet". What really DOES matter is that one of us is working FOR progress, and the other is working AGAINST progress.

That is not my intention. There is simply a lot of misinformation and 'dark art' around inertial position tracking. There are fundamental limitations with current MEMS sensors that prevent useful positional tracking over even short periods of time.

Basically, if you have managed to get any sort of actually usable free-space positional tracking from MEMS devices, then you can right now walk into any university or research lab and get a job for life for such a revolution in sensor filtering. Think on the level of the Kalman Filter in terms of impact. The theory behind this filtering is vastly more important than any specific implementation.

geekmaster

Up and Coming

"edzieba" wrote:
What are you using to measure the g-vector? The gyros won't work, they drift. The Accelerometer can provide an absolute vector, but noisy. And that's even if you hold it stationary, if you're moving you have no measure of what contribution gravity provides and what is acceleration from movement. That is why the g-vector acquired from filtering the accel and the gyros is an estimate, not a measurement.
...
Basically, if you have managed to get any sort of actually usable free-space positional tracking from MEMS devices, then you can right now walk into any university or research lab and get a job for life for such a revolution in sensor filtering. Think on the level of the Kalman Filter in terms of impact. The theory behind this filtering is vastly more important than any specific implementation.

I continuously define my experimental results as CONSTRAINED positional tracking, not "free-space" postitional tracking. I know that free-space tracking requires an extremely accurate timebase, such as the atomic clocks used by the military for that purpose, and that just slows down drift accumulation but does not stop it altogether.

"Constrained" means keeping your expectations restricted to what the technology CAN deliver. And it can certainly deliver a lot more than how it is currently being used by the Rift. There is no magic in that. Although extending the field even a little may be worth writing a publishable research paper over -- who knows? I just want to make a useful addition to the available tools we can use for Rift gaming. In particular, I want to implement the "Johnny Lee" (floating target) demo.

And regarding "measuring" the gyros and accelerometers, yes, it is possible to MEASURE a noisy (or even a drifting) value, to within the precision not buried in noise. And you can even measure drift by subtracting the fused values. No magic there either. But it does work better if I do my own (more accurate) sensor calibration routine.

Noise and drift do not prevent measurement. They only affect accuracy and precision. Gravity is the force you measure on the sensors while the Rift is stationary. Unless you wish to get into a semantic argument over word definitions, that is...

No magic to be seen here. Nothing all that special. But it is useful just the same. No need to make it more than it is, just to knock it down.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

geekmaster

Up and Coming

"edzieba" wrote:
What are you using to measure the g-vector? The gyros won't work, they drift. The Accelerometer can provide an absolute vector, but noisy. And that's even if you hold it stationary, if you're moving you have no measure of what contribution gravity provides and what is acceleration from movement. That is why the g-vector acquired from filtering the accel and the gyros is an estimate, not a measurement. ...

While reading the Madgwick AHRS code, it just occurred to me that we may be disagreeing over our definitions of the words "measure" and "measurement". While I am referring to the actual values returned by the measuring instrument (the IMU sensors), I suspect that you are referring to real-world physical values and navigational coordinates.

For navigation (such as used in the military during dropout or blackout periods of GPS or other geographical position coordinates) you do need to be very accurate to avoid stepping off a cliff in the dark, so to speak.

But for gaming, when we are constraining ourselves to a seated or standing position (no free roaming), we can rely on our brain adapting to scalar range variations in yaw and horizontal position. Even in free roaming, this perceptual adaptation can be useful for redirected walking, altering both perceived direction and perceived distance traveled.

So in my case, "measurement" merely means using the values returned by my measuring instruments, and not accurately locating myself in real-world geographic space.

And my only reason to (optionally) remove the gravity vector is to make my jerk vector (differential acceleration) a bit less sensitive to roll (simplifying skeletal orientation compensation).

Disagreements often boil down to differing interpretations of word meanings and semantics, rather than technical details of the idea being discussed, and I think that problem applies in this thread too.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

edzieba

Up and Coming

"geekmaster" wrote:
"Constrained" means keeping your expectations restricted to what the technology CAN deliver. And it can certainly deliver a lot more than how it is currently being used by the Rift. There is no magic in that. Although extending the field even a little may be worth writing a publishable research paper over -- who knows?

We're using different definitions of 'constrained' If motion is constrained, that means that you can define the possible motions rigidly. A train on rails has constrained motion, a walking foot has (mostly) constrained motion (assuming you never run, never sidestep, never shuffle, have perfect grip, the floor is flat and stationary, etc). The human head is unconstrained in space; while relative to the torso it is somewhat constrained (but not very, especially when straining and craning), you can orient and position your head in any manner you wish. If you intend to track the head, you need an unconstrained tracking system.

And regarding "measuring" the gyros and accelerometers, yes, it is possible to MEASURE a noisy (or even a drifting) value, to within the precision not buried in noise. And you can even measure drift by subtracting the fused values. No magic there either.

But what you're measuring is not 'down', but the current highest magnitude force-vector. If you're perfectly stationary, this happens to correspond with down. If you are not stationary then the relationship is somewhere between 'loose' and 'nonexistant' (and in the rare case of freefall, your accelerometer will tell you absolutely nothing about your orientation).

Gravity is the force you measure on the sensors while the Rift is stationary.

That 'while the rift is stationary' is key. The Rift, when attached to someone's head, will almost never be stationary. And worse, you have no way to tell if it is stationary apart from with the aid of an external sensor! A naive method would be to assume that any time the magnitude of the acceleration vector was exactly 9.81ms^-2, then the orientation of that vector is straight down. But this is not true; there are many ways to move that will result in the magnitude of the vector being 9.81ms^-2, but in these cases the orientation will not be down! With an IMU, you physically cannot tell when you are stationary.

While reading the Madgwick AHRS code, it just occurred to me that we may be disagreeing over our definitions of the words "measure" and "measurement". While I am referring to the actual values returned by the measuring instrument (the IMU sensors), I suspect that you are referring to real-world physical values and navigational coordinates.

Exactly! What you, measure with an accelerometer is categorically NOT your position or orientation, or even your motion. It is only the force that is currently acting on the MEMS sensor. You can estimate your motion by using this data and combining it with other sensors, but you are absolutely NOT measuring orientation (with respect to the Earth's gravitational field) when you read the value from an accelerometer.

But for gaming, when we are constraining ourselves to a seated or standing position (no free roaming), we can rely on our brain adapting to scalar range variations in yaw and horizontal position

But we can't! As has been very clear with orientation testing with the current Rift sensor, and numerous reports of nausea from slight errors in yaw rate (and even some perceptible yaw drift!), the human brain is really, really sensitive to proprioceptive sensation of head motion (from the semicircular canals in the head) not matching up with the head motion delivered by your eyes. You can't kludge it and rely on the user adapting, it really does need to be dead-on.

The requirement is, if anything, MORE stringent than military-grade INS. An ICBM only needs to avoid drifting out by less than 10 metres over a period of 30 minutes, or 5.5mm/second. That level of drift would be intolerable to someone wearing a HMD! Your view would be continuously wobbling about in a very obvious manner, and you would quickly become nauseated. If you tried to eliminate this by, say, averaging over several samples, then you now add latency issues to the mix.

geekmaster

Up and Coming

"edzieba" wrote:
The human head is unconstrained in space; while relative to the torso it is somewhat constrained (but not very, especially when straining and craning), you can orient and position your head in any manner you wish. If you intend to track the head, you need an unconstrained tracking system.

In my world, my head is constrained to my neck, which is constrained to my spine, which is constrained to my pelvis, which is constrained to my chair (within the flexibility limits of my gluteus maximus musculature, and the flexibility limits of my seat cushion). All of which, when taken together, constrain my head (and my Rift, and its IMU sensors), to a relative area around my chair that has defined maximum limits (without muscle strains or join dislocations). So let's not argue sematics and word definitions. You know what I am talking about. I cannot make myself more clear. Your arguments AGAINST my research are using a different set of word definitions, making them automatically out of context for the IDEAS that I have presented, and therefore inconclusive (or conclusively invalid in this context).

"edzieba" wrote:
But what you're measuring is not 'down', but the current highest magnitude force-vector. If you're perfectly stationary, this happens to correspond with down. If you are not stationary then the relationship is somewhere between 'loose' and 'nonexistant' (and in the rare case of freefall, your accelerometer will tell you absolutely nothing about your orientation).

Why should I care which direction you DEFINE as "down"? I only wish to cause a minimal disturbance to the force, removing WHATEVER axial forces may be acting against each independent axis, while I MEASURE (the sensor VALUES) to compute a RELATIVE APPROXIMATE "KINDA SORTA" jerk vector, that is SUFFICIENTLY close to reality that a human brain can use it to control useful in-game positional head movements. Even WITHOUT removing g-forces, it works pretty good except when tilting the head from side-to-side, and even then could be compensated using gyro values WITHOUT subtracting a gravity vector. So again, I really do not care about WHAT words anybody wants to use to describe my methods. I only care that they work sufficiently well enough to be useful.

"edzieba" wrote:
"geekmaster" wrote:
Gravity is the force you measure on the sensors while the Rift is stationary.
That 'while the rift is stationary' is key. The Rift, when attached to someone's head, will almost never be stationary. And worse, you have no way to tell if it is stationary apart from with the aid of an external sensor! A naive method would be to assume that any time the magnitude of the acceleration vector was exactly 9.81ms^-2, then the orientation of that vector is straight down. But this is not true; there are many ways to move that will result in the magnitude of the vector being 9.81ms^-2, but in these cases the orientation will not be down! With an IMU, you physically cannot tell when you are stationary.

As I said, I will NOT make any false assumption that 9.81 is a correct value for gravity (even though that value is used in the OculusVR SDK). I know that gravity varies at different places on the planet, due to crustal density variations and that it varies from equator to pole, and that it varies due to lunar tidal forces. I do NOT care. I (optionally) calibrate each axis independently AND in both directions, while the Rift is stationary and supported in each axial orientation, and these independent axial (gravity caused) measured values will not change significantly during the course of a game. And anyway, I only MEASURE the VALUES returned by the sensors (whatever you choose to call them) to OPTIONALLY decrease side-effects from tilting your head (which could be forbidden or ignored, just like in some games). That does not decrease the usefulness of this method. And once again, I do not care to argue over word definitions. That does not affect my code, unless my source code comments bother you (if I decide to share my source code, that is)...

"edzieba" wrote:
"geekmaster" wrote:
... I suspect that you are referring to real-world physical values and navigational coordinates.
Exactly! What you, measure with an accelerometer is categorically NOT your position or orientation, or even your motion. It is only the force that is currently acting on the MEMS sensor. You can estimate your motion by using this data and combining it with other sensors, but you are absolutely NOT measuring orientation (with respect to the Earth's gravitational field) when you read the value from an accelerometer.

Yeah, okay, fine, whatever... Again, I just do not care to argue over semantics or word definitions. That is only of concern to the accuracy of my code comments, not its effective performance.

"edzieba" wrote:
"geekmaster" wrote:
But for gaming, when we are constraining ourselves to a seated or standing position (no free roaming), we can rely on our brain adapting to scalar range variations in yaw and horizontal position
But we can't! As has been very clear with orientation testing with the current Rift sensor, and numerous reports of nausea from slight errors in yaw rate (and even some perceptible yaw drift!), the human brain is really, really sensitive to proprioceptive sensation of head motion (from the semicircular canals in the head) not matching up with the head motion delivered by your eyes. You can't kludge it and rely on the user adapting, it really does need to be dead-on.

The requirement is, if anything, MORE stringent than military-grade INS. An ICBM only needs to avoid drifting out by less than 10 metres over a period of 30 minutes, or 5.5mm/second. That level of drift would be intolerable to someone wearing a HMD! Your view would be continuously wobbling about in a very obvious manner, and you would quickly become nauseated. If you tried to eliminate this by, say, averaging over several samples, then you now add latency issues to the mix.

Your claim is unsupported, and beyond (my) belief. Please supply proof for your claim. In fact, please supply supporting evidence for ANY (or all) of your claims.

Actually, according to studies that I have read (and reported elsewhere in MTBS3D forums), the human brain DOES adapt to fixed scalar variations just exactly as I said above, with an adaptation period of 10 minutes when you enter VR, and another 10 minutes when you exit VR (within certain rather broad range limits). This scalar variation is reported to work for both orientation and for speed of locomotion (i.e. head postiion, in this case). And in ANY case, what we have now is a MUCH LARGER deviation from reality, than the SUFFICIENT head position motion I am working with (constrained by skeletal flexure and by seated range of comfortable stable motion). I do not plan to accurately track when you lean too far and fall out of your chair, or when you get up and walk away and jerk the Rift cords out of your computer.

And regarding supporting evidence (of which I have already supplied an abundance in this and other threads), here are some relevant research studies that I have posted repeatedly:
http://www.hitl.washington.edu/publications/r-96-4/p-96-2.pdf
http://www.hitl.washington.edu/publications/r-98-3/index.html
And a relevant "scalar variation" chart extracted from one of those documents:

And there has been plenty of additional information posted that is also relevant to this discussion, regarding "redirected walking", in various threads including this one:
http://www.mtbs3d.com/phpbb/viewtopic.php?f=138&t=14069

Studies have shown that we are not very good at determining direction OR distance travelled, due to differences in our gait, and (perceived) differences in terrain. And in VR, such perceived variations can be used to good effect, both in redirected walking and in MY METHOD of "constrained SUFFIECIENT head position tracking".

And again, what we have now is a FAR GREATER deviation from reality than what I propose, so it will CERTAINLY be an improvement (for many people), despite your unsupported arguments to the contrary. And it will be user-selectable, so if you are one of the unlucky people who prefer the current ZERO position tracking to what I propose, then by all means turn off that feature.

SUMMARY: Your unsupported arguments do not apply to my research. You need to prove your contrary claims with substantial evidence before I will allow it to impede my progress. However, many other things in my life ARE slowing progress, but I will soon be able to spend more time working on this project (within about three weeks or so).

It is okay if you do not want to believe me, even AFTER reading the linked information that I have provided. You can research your OWN projects, and you can IMPLEMENT your own projects, and you can contribute to the advancement of this renaissance of VR too, if you really care to. Or not... If you do not wish to contribute, that is fine too.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

geekmaster

Up and Coming

"

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

ganzuul

Up and Coming

You are also constrained by the strength of your muscles vs. the limbs they actuate. IIRC the muscles of the eyes were the upper bound.

In my thought experiments and research I concluded that the best smoothing algorithm was the median value (read, not average value) of a 5 to 7 entry long FIFO register. This should remove the outliers with the needed accuracy and latency. At 1000 measurements per second there is 10x headroom compared with that I designed for, so maybe one could make the register 11 or more long.

I think that for sensor fusion at this stage one should not, as Steve LaValle says, use the 'sledgehammers'. Those filters have to be calibrated anyway, so it is better to accomplish accuracy 'gain' through thinking about what you're doing and then cutting that in stone.

I think a Kalman or particle filter would make sense in a pluggable system where eg. a webcam and a secondary IC IMU attached to your belt were contributing to a skeletal model. The belt sensor would carry some pre-defined metadata about what it was measuring over to the filter, plugging in the required configuration.

I have some vague recollections about fuzzy logic that I feel is relevant for modelling a skeleton... I'm sure the answer lies somewhere behind http://en.wikipedia.org/wiki/Control_theory

geekmaster

Up and Coming

Regarding control theory, much of my professional experience is in motion control (robotics and factory automation). I am a big fan of "bang-bang adaptive optimal control", but for responsive slow sample-rate data I like to use adaptive-length FIFOs (short when the data is rapidly changing, for responsive updates, but long when data is fairly stable, to allow higher precision averages). PID was much too slow for a lot of things I did, but sometimes we used self-tuning adaptive PID when latency was not an issue. We typically moved heavy mass at high speeds, so both operator safety and maximum factory production rate were primary concerns. I have thought experiments of my own, trying to adapt my experience to head and body tracking, which is why I have potentially-innovative ideas (and beliefs) regarding the topic of this thread. I think there will be some good cross-disciplinary contributions between motion control and position tracking.

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Show more replies

Get Help

Sign up

Login with SSO

Login to the community

Login with SSO