Clamps wrote:

I have a marker that was imported at a "size" of 2000, because I didn't know if that had anything to do with tracking.
The object attached to this marker is a very large building.
In the real world, the marker would be 2m x 2m. And the building is about 3 stories tall. So about 10 meters. This makes the object about 5 times larger than the marker.
We are seeing a *lot* of wobble and scaling problems when running this on an iPad2. It's basically unusable, due to the drift, wobble and scaling.

Is this a known issue, or is there some setting (like the size setting on the trackable import function) that we've gotten wrong?

thanks

FYI - we're not ignoring you Clamps - we've been looking into this but are waiting for feedback from the core development team on our own findings.

I have the same problem. But I doubt that this has anything to do with the IOS version specifically. The Android version has the same problem.

The object stability only works well for objects which are not too high in relation to the marker. If have an object is placed far away from the marker (or big in size), it will wobble massively. This is the case for both the frame markers and the image targets.

It is a deficiency of the tracking algorithm used. The tracking will always contain a certain amount of error. A small error in translation isn't so bad because it is hard to detect. But an error in rotation gets amplified as you get further away from the marker. This is what you are seeing.

String AR has this problem as well but it has far less wobble with large objects then QCAR. If you want to eliminate this problem, you have to use multiple markers spaced far apart (not on the same plane), bring them into a single coordinate system, and average the tracking matrix. That's just a theory though. I haven't tested it yet, but I am working on it.

Edit:
Try the new version 1.0.6 for Android. The jitter is reduced. Not sure if this incorporated in the IOS version though...

Edit 2:
You can find the Unified Coordinate project here:
http://ar.qualcomm.at/node/2001030

elecman wrote:

If you want to eliminate this problem, you have to use multiple markers spaced far apart (not on the same plane), bring them into a single coordinate system, and average the tracking matrix. That's just a theory though. I haven't tested it yet, but I am working on it.

That's a neat idea for stabilising the augmentation, elecman. I've tried a solution that averages just the trackable's pose which works well, although as it averages over time it does introduce some latency in the responsiveness. I expect your solution will provide a better responsiveness.

I'll post my example once we've got some feedback from the core team, unless you beat me to it. :-)

MoSR wrote:

That's a neat idea for stabilising the augmentation, elecman. I've tried a solution that averages just the trackable's pose which works well, although as it averages over time it does introduce some latency in the responsiveness. I expect your solution will provide a better responsiveness.

I'll post my example once we've got some feedback from the core team, unless you beat me to it. :-)

My colleagues and I have found that running the resulting rotations through a median filter can help significantly reduce the rotational jitter. But of course, there's that issue of latency. In our tests, 7 to 11 samples was more than sufficient, but of course at the perceived cost to the end user of tracking speed. Mind you, if you can pull it off with fewer samples, latency isn't really that much of a problem; even String has a small amount of latency when repositioning objects relative to the marker.

@MoSR: Did you just average the modelViewMatrix or the individual rotation components?

stridefrodo wrote:

@MoSR: Did you just average the modelViewMatrix or the individual rotation components?

In the test case I just did the simple thing of creating a rolling average of the returned pose matrix. This isn't strictly correct, but provides a basic solution - if you do the more complex solution of transforming into individual components you can use different strategies to dampen each component.

I did transform the pose matrix in Quaternion and then dampened it by median filter. I got decent result but more improvements can be done.

@MoSR: What other strategies would you suggest?

is jitter reduction in latest iOS version?

stridefrodo wrote:

is jitter reduction in latest iOS version?

The iOS version now has the same jitter reduction as the Android 1.0.6 version.

Sorry I didn't get back to you on 'strategies' but I think that's a research project. :-)

Try if a Unified Coordinate system makes a difference:
http://ar.qualcomm.at/node/2001030