Will positional head tracking be activated in the dev kit?

That's a big improvement... XD

Yes, I assume something of that nature would be needed to do anything useful with accelerometer data in trying to track position.

The hard part is going to be determining appropriate moments at which to reset the device.

A foot resting on the ground is guaranteed to be stationary at least some of the time. (When physically in contact with the ground the foot doesn't move at all.)

The same can't be said for a person's head; Even when not moving in any real sense, you will get head movements associated with breathing in and out, slight swaying, and adjustments in posture...
And so on.

I'm reading through that paper now...

In any event, you can see that this method requires several assumptions about what's going on. That's not a problem as such, of course, but it does make any code involved inherently less flexible, and requires a careful study of what might be going on at any given moment to determine when you can do something like what the paper describes.

Worth the effort though, I suppose; If it works. XD

As far as the foot being stationary when in contact with the ground, how is that going to be affected by a setup like the Omni?

@Geekmaster... you'll become a VR legend one day

Disclaimer: I'm not a time traveler

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

Of course, but looking for experiences so I know what to expect if I try it.

"KuraIthys" wrote:

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.

How fast was the accelerometer and what kind of integration algorithm did you use (Runge Kutta?)? The one in the Rift is 1000Hz which might help. Also, I was thinking that video might be able to recalibrate the position 10-30 times a second, so that is 40-120 corrections in those 4 seconds.

"KuraIthys" wrote:
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.

Good thing that wasn't the idea. I'm not being "optimistic" at all unless you mean not dropping an idea as soon as somebody poo poos it is "opimistic" :)

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

No way it is exponential. What would the exponential be? The error would be polynomial and since acceleration is the second derivative there is no way the error would be more than quadratic. Maybe you are speaking loosely here. [Edit: The error is actually on the order of a cubic because it is accumulated over time.]

"KuraIthys" wrote:

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;

Thinking about it, I'm not sure if defining one source as "core" or "primary" and the other as "secondary" has a rigorous definition. In my thinking I was seeing acceleration as primary because it was much higher frequency, not because I was somehow letting it wonder off 10 meters and then getting pulled back.

Better to just say I'm thinking of how to fuse them somehow and not load up the terms with meaningless descriptors like "primary" or "core" or say that one input stream is "correcting" the other.

"KuraIthys" wrote:

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.

That is fine if you are talking about position tracking using only accelerometers.

My question has always been, "Can you combine computer vision data with accelerometer data in order to overcome the weaknesses of both." Even if I did not express it clearly.

This looks really promising
https://www.youtube.com/watch?v=MSTge5IDxF4
apparently the sensors are only using a triaxial gyroscope, accelerometer, and compass.
Throw in some optical correction and you got yourself a sandwich. :D

"arepass" wrote:
This looks really promising
https://www.youtube.com/watch?v=MSTge5IDxF4
apparently the sensors are only using a triaxial gyroscope, accelerometer, and compass.
Throw in some optical correction and you got yourself a sandwich. :D

If they are only using accelerometers then this works because of the constraints to the motion you can apply due to it being acceleration of a jointed skeleton and also constraints due to there being multiple accelerometers.

"arepass" wrote:
This looks really promising
https://www.youtube.com/watch?v=MSTge5IDxF4
apparently the sensors are only using a triaxial gyroscope, accelerometer, and compass.
Throw in some optical correction and you got yourself a sandwich. :D

A very expensive sandwich, they are using $3995 worth of tracking hardware to do that video.

"jwilkins" wrote:

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

Of course, but looking for experiences so I know what to expect if I try it.

"KuraIthys" wrote:

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.

How fast was the accelerometer and what kind of integration algorithm did you use (Runge Kutta?)? The one in the Rift is 1000Hz which might help. Also, I was thinking that video might be able to recalibrate the position 10-30 times a second, so that is 40-120 corrections in those 4 seconds.

It was the accelerometer from a Wii remote. That's about 100 hz - The method used was the most naive possible (direct integration of the sensor values).

I don't think a faster accelerometer actually helps the situation here; The error accumulates over time based on the cumulative error of the sensor readings. That would imply a faster sensor actually accumulates error more quickly than a slower one.

Getting a position value from a camera would certainly help, but it starts to become a question of whether the accelerometer improves your accuracy any over just using the camera data by itself.

"KuraIthys" wrote:
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.

Good thing that wasn't the idea. I'm not being "optimistic" at all unless you mean not dropping an idea as soon as somebody poo poos it is "opimistic" :)

Considering there is decades worth of research on the subject which all has similar conclusions, I'm afraid, that yes, you are being optimistic if you think you can do something which a lot of people have basically failed at.

I'm not saying don't try things, but try to have realistic expectations please...

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

No way it is exponential. What would the exponential be? The error would be polynomial and since acceleration is the second derivative there is no way the error would be more than quadratic. Maybe you are speaking loosely here.

... Yes. I'm not the most careful with words sometimes... An unfortunate trait when talking about technical subjects. = in any event, - The error from a single integration is basically the sum of the errors of the values being integrated. The minimum amount of data needed to integrate twice is 3 values, which would give an error of approximately 3 times the original value.

However, if you're trying to determine position in 3 dimensions, then the error on each axis is a separate thing. - What on one axis implies the actual location could be anywhere within a given distance of the calculated location, for 3 dimensions it is somewhere within a volume. I do have a tendency to confuse things here though... So that's probably one reason for the mistake. (The other being the error over time). - Obviously, taking the error as a cubic volume, the maximum possible distance is along the diagonals of the cube.

And, for a device combining data from a gyroscope and accelerometer, These create errors that stack on top of one another as well.


HOWEVER, and this is critical: The paper linked to by geekmaster in a post above( which I mistakenly attributed to 320x200) (http://www.cl.cam.ac.uk/research/dtg/www/files/publications/public/abr28/ojw28_thesis.pdf) summarises the implications of a lot of different tracking schemes.

On page 19 of the paper you'll find an overview of how inertial navigation works.

This part in particular is worth noting:

"Inertial navigation makes no assumptions about the movement of the tracked device, except
that its accelerations and angular velocities remain within the operating range of the individual
sensors. The cost of this generality is that drift in position tends to grow at a rate that is
proportional to t^3, where t is the duration for which the device has been tracked [14]. This
cubic error growth is due to the propagation of gyroscope bias errors"

The growth in error is cubic with regard to time. Meaning attempting to track for twice as long produces 8 times the error.

And that's an assumption based on the methods used to do inertial guidance for aircraft and submarines...
The critical factor, unless you can think of something really clever to do. (such as what the research paper itself notes), is the error of the sensors themselves.

Since the error is entirely cumulative (Which should be obvious from how you would determine position from such sensor data in the first place), and when using multiple sensors, the error is the combined error of the sensors...

Because each new reading is being summed with a previous one, the faster new readings come in, the more quickly you end up getting positional errors. - Amongst other things, the error of a sensor is a fixed proportion of each reading. - So having more readings simply means more error accumulates in the same period of time...

"KuraIthys" wrote:

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;

Thinking about it, I'm not sure if defining one source as "core" or "primary" and the other as "secondary" has a rigorous definition. In my thinking I was seeing acceleration as primary because it was much higher frequency, not because I was somehow letting it wonder off 10 meters and then getting pulled back.

Better to just say I'm thinking of how to fuse them somehow and not load up the terms with meaningless descriptors like "primary" or "core" or say that one input stream is "correcting" the other.

Yes, it can be pretty arbitrary. It depends on what you're doing with the data though - if you're using something like a kalman filter, or similar, then there is no primary source of data, as you simply integrate whatever comes in at a given moment with the existing prediction.

However, other methods do have a concept of what is 'primary' data and what is not. - And this is because they ignore some of the data.

A method involving a kalman filter would use the prior predictions of all the sensor readings combined to calculate the next position, but simpler schemes might just use the camera data when available, then add acceleration data on top of that. - in such a scheme however, your primary data source should be whatever source can provide information without time dependencies.

A positional reading from GPS, or computer vision or the like is not perfect, but it has no dependency on time. The reported position when the sensor reading was taken depends only on that one sensor position, and not on prior readings.

An inertial sensor such as a gyroscope or accelerometer on the other hand, cannot meaningfully determine position at all without at least a starting point. - To even hope to track position with it requires keeping track of the history of movement.

If you combine the two, you could try and integrate all the data, but you might find it isn't worth the effort, and the results might be good enough simply by ignoring the data except when you don't have a direct positional reading.

"KuraIthys" wrote:

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.

That is fine if you are talking about position tracking using only accelerometers.

My question has always been, "Can you combine computer vision data with accelerometer data in order to overcome the weaknesses of both." Even if I did not express it clearly.

And that's a reasonable enough question, except that there are plenty of systems already that can answer that question, and their usage in practice seems to imply it's rarely worth the effort.

Consider:
The Wii - Accelerometer + IR position tracking (+ gyroscope upgrade) - No game made for it to date attempts positional tracking at all, even with the aid of a gyroscope. - Any examples that in any way resemble positional tracking do so by using IR data alone. (The accelerometer is used to help determine roll because the data from the IR tracker with the standard sensor bar is only sufficient for 2 axis position + roll that is mirrored across the x axis)

PS Move - Accelerometer + Magnetic tracking + gyroscope + Optical tracking based on high speed camera - Even though it's more than capable of combining optical tracking with accelerometer data, again, it's use is minimal. - From what I've seen of it, when the controller is visible to the camera, positional tracking is done using entirely optical methods. - The acceleration and gyroscope data is ignored entirely for the purposes of determining position, although it does still find use in keeping track of the controller's orientation. The PS Move does perform dead reckoning when the optical system loses sight of the marker, but only for the space of a few seconds at most. Any longer than that and the system decides that tracking is lost entirely.

Mobile phones/tablets/etc - This is a tough one to describe since it depends largely on the device, and on app developers. - Most phones have cameras, but the data is rarely used for tracking purposes, even though there are technical demonstrations showing it is possible.

------

Anyway, I'm not trying to convince you not to try. I'm just trying to get you to understand that the existing evidence and research on the subject (and believe me, there is a lot of it.) suggests little is gained from trying to compensate optical tracking using accelerometers.

If you have optical tracking anyway, what you gain from adding an accelerometer largely doesn't seem to be worth the effort. - They simply don't complement eachother that well as far as I can tell.

By all means, try it. But just don't expect it to perform miracles or anything.
As I said, if it was that useful, it would have been done by now, because the combination of hardware needed for it exists in several existing devices as is.

Egh. I don't know sometimes why I bother really. Everyone always seems to assume that because I have something negative to say on a subject that I'm trying to dissuade them from doing it. - All I'm trying to do most of the time is to make people aware of the difficulties as much as I'm able to.
Repeating the same mistakes as dozens of people before you isn't going to lead you to doing something they didn't after all.
So by pointing out that it's unlikely to work, I'm merely trying to get you to understand that you'll probably have to do something creative to accomplish anything.

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

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.

"KuraIthys" wrote:
Egh. I don't know sometimes why I bother really. Everyone always seems to assume that because I have something negative to say on a subject that I'm trying to dissuade them from doing it. - All I'm trying to do most of the time is to make people aware of the difficulties as much as I'm able to.
Repeating the same mistakes as dozens of people before you isn't going to lead you to doing something they didn't after all.
So by pointing out that it's unlikely to work, I'm merely trying to get you to understand that you'll probably have to do something creative to accomplish anything.

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.