Rigid body orientation randomly flips in tracking tools

[blooop]

I have been having a lot of trouble with the orientation values for my rigid bodies. I have now been able to isolate what is causing the problems and can reproduce it using a standard optitrack marker holder.

If you turn an object 180 degrees about the vertical axis the orientation becomes unstable. If you return the object to its original orientation, stability is no longer a problem.

This video demonstrated the problem. http://www.youtube.com/watch?v=ke9-LDgGPF4

I don't think it is a case of not all the marker getting tracked correctly as this screenshot shows all markers in clear view. The history of orientations shows the jitter.



I have tried setting the flexibility and acceptable marker deflection to their minimum values but this does not solve the problem.

This problem doesn't occur if I only use 3 markers, but I would like to avoid that in case one of those markers gets occluded while I'm tracking.

[Seth Steiling]

Hi blooop,

This appears to be a bug in the rigid body solver. Could you please take a recording of this behavior and send us the timeline, calibration, and rigid body definition files? We'll take a look at the data and see what's up. You can send the files to me at seth[at]naturalpoint[dot]com

[vgrabe]

I can confirm this problem. In our case, we observe this gimbal lock whenever the y-axis is pointing down. We made sure to not have all markers in a plane (or otherwise symetric configuration) to exclude this error. Consequently, this problem arrises with all our objects.

The fastest way to reproduce this problem is to create a trackable and than have the frame of this object rotated bei 180 deg right away in the orientation settings such that y points down.

The requested files are 40 even after compression. For that reason, I will upload the files and send you a link later on.

[Seth Steiling]

Hi blooop,

We've taken a look at your data. The main issue is how the markers are arranged. Since the reconstructed point cloud is not ideal, it has a certain amount of error on each marker. In order to track the rigid body, it has to allow for some tolerance in their locations. Because they are very symmetrical--nearly square--the rigid body solver is finding multiple solutions. It tries to choose the best one, but sometimes it will chose the unwanted one. The two solutions are shown here:





Another problem is that the point cloud accuracy is reduced when you have cameras that aren't getting a good look at the markers. During the problematic portion of this recording, Camera #1 is getting a poor look at the markers, shown here:



When combined with the symmetrical marker arrangement, the loss of a camera due to poor perspective of the markers can make rigid body orientation flipping even more common.

Our recommendation to prevent this problem would be that you either modify the arrangement of the markers to make them less symmetrical and less co-planar, add an additional marker (again, aiming for asymmetry), or both. By rearranging or supplementing your marker cluster, you'll give the rigid body solver fewer solutions to the point cloud each frame. If there is only one possible solution to the points, you won't run the risk of it flipping its orientation when you lose a camera for a few frames.

[Seth Steiling]

[quote=bratmaxe]I can confirm this problem. In our case, we observe this gimbal lock whenever the y-axis is pointing down. We made sure to not have all markers in a plane (or otherwise symetric configuration) to exclude this error. Consequently, this problem arrises with all our objects.

The fastest way to reproduce this problem is to create a trackable and than have the frame of this object rotated bei 180 deg right away in the orientation settings such that y points down.

The requested files are 40 even after compression. For that reason, I will upload the files and send you a link later on.[/quote]
We're still doing some investigating on your issue, bratmaxe.

[blooop]

Thanks for the reply. I am already aware of the the issues with marker placement but thought I had showed sufficiently that this was not the cause of the problem.

I have now recorded another sequence to show that the marker positioning is not related to the issue. In this sequence there are 6 markers each of which is a unique distance to all the other markers. They are coplanar in this example, but that does not matter as I will only rotate the markers in 180 degrees in that plane anyway. When the orientation tracking problems occur all 6 markers are not occluded in any way. I hope this is helpful.

The orientation only has problems when the object is turned 180 degrees from the original position (in any axis). This really looks like a software problem as it is reproducible for a number of marker configurations that do not have tracking problems for any other orientation.

The files are on my public dropbox folder:
https://dl.dropbox.com/u/12467721/6%20M ... acking.zip

[Seth Steiling]

Hi blooop,

Thanks for sending over that additional data. It gave us a better understanding of the issue you're encountering. Our devs are confident that it is indeed a bug, and they're continuing to investigate. Stay tuned.

[vgrabe]

Are there any news on this? Did this problem also exist in earlier versions of TrackingTools? In this case we might consider to downgrade until fixed.

[blooop]

Has there been any progress on this bug?

[blooop]

It's now been 5 months since I first posted. Are there any developments?