rviz: Large transforms lead to unstable visualizations (ros-pkg ticket #5394)

[hershwg]

I'm trying to visualize some georeferenced (UTM) !PointCloud2 data using rviz and running into what appears to be some unstable math. See the attached video for an example as I rotate from side to side while in orbit mode.

When using the following static_transform_publisher command and attached vcg file, rotating the camera in in either !Orbit or !TopDownOrtho view with the fixed frame set to /utm and the target frame set to /front_camera, the axes will not line up and, while rotating, will jitter a lot. Everything else being visualized also undergoes similar jitter/disappearing, which makes rviz pretty unusable.

static_transform_publisher command:
{{{
rosrun tf static_transform_publisher 5900018.039 4468280.167 330.249 -0.009 0.027 0.898 0.440 front_camera utm 100
}}}

I've tested this in Ubuntu 11.10 and 10.04 with the same results on two different Dell laptops, so I doubt it's a GPU or driver issue (GPU on the 11.10 machine was a Quadro FX 3800M for reference).

Is this issue due to some unstable math or precision loss in rviz? If so, can it be patched or are there any workarounds possible (besides transforming all of my data into some relative frame so that the tf values aren't nearly so large)?

trac data:

• Owner: hersh
• Reporter: ericperko
• Reported at: Mon Mar 12 21:48:20 2012
• URL: http://code.ros.org/trac/ros-pkg/ticket/5394

[hershwg]

[ericperko] I should also note that this issue goes away if I make the x,y,z of the transform closer to 0,0,0 and that I checked this on both the rviz in Electric and in Fuerte, with both having the same issue.

[hershwg]

[hersh] Single-precision floats are just not big enough to express differences in centimeters nicely when the absolute numbers are thousands of kilometers.

RViz uses Ogre for rendering which uses single-precision floats by default. You could recompile Ogre with OGRE_DOUBLE_PRECISION set to 1 in OgreConfig.h as described here: [http://www.ogre3d.org/forums/viewtopic.php?f=10&t=9354]

But that sounds like a hassle.

TF does all its math with double-precision floats, which are big enough, so you just need to let TF do the relative frame thing before your numbers get to Ogre.

All you have to do is set the "Fixed Frame" in rviz to a TF frame which is within, say, a kilometer of your target frame. I re-tried your example with "Fixed Frame" set to "/nearby" with the following 2 static transform publishers:

{{{
rosrun tf static_transform_publisher 5900000 4400000 0 -0.009 0.027 0.898 0.440 utm nearby 100 &
rosrun tf static_transform_publisher 5900018.039 4468280.167 330.249 -0.009 0.027 0.898 0.440 utm front_camera 100
}}}

Note that I swapped the frame order (utm and then front_camera) compared to your example so that both "front_camera" and "nearby" are children of "utm" instead of both being parents, which doesn't work.

So with that setup, the ends of the axes intersect again and the view rotates smoothly. AND you still get to use giant values in your TF positions. :)

We are trying to move to using standard installs of dependencies, rather than maintaining patched versions, so I don't think we'll ever switch to a double-precision version of Ogre for rviz.

However with this trick of publishing a nearby frame to use as a local anchor, I think you won't really need it.

[hershwg]

[joq] I can accept this resolution due to limitations of the tools involved.

But, the behavior of rviz when this occurs is quite unpleasant and confusing to the user.

Could rviz perhaps detect when 32-bit floats lack the necessary resolution for the numbers involved and log a warning?

[hershwg]

[hersh] I do see a place in frame_manager.cpp where we could add a check for that.

The only check I see how to do though, is to check if the magnitudes of the X, Y, and Z components of the position are greater than some fixed threshold. If someone is viewing stuff on a much different scale, like if they use millimeters instead of meters, this could end up giving incorrect warning messages. I don't know how to make the alert threshold be relative to the scale at which a person is working.

That said, I think RViz is mostly used with meters, so maybe it is fine to just pick something like 1,000,000 and warn on anything larger.

[hershwg]

[ericperko] Wouldn't working with millimeters on the order of say, 1 million mm still have a similar issue, since the problem with floating point in this case is the number of digits in the mantissa, not the exponent? In either case, we still need more significant digits than floating point can hold in order to get the precision we might want.

[hershwg]

[hersh] Yes, absolutely a million of any unit would be a problem.

My point was that I don't know how to detect the scale that people are working in, therefore I don't know where to set my warning message threshold. If all the objects are 1,000 meters long, showing them 1,000,000 meters apart will work just fine. If all the objects are .001 meters long, showing them even 1000 meters apart will be bad.

[hershwg]

[joq] Theoretically, I suppose it's a question of whether the positions of objects being displayed differ in the first 7 digits.

However, your idea of logging a warning if some position exceeds 1,000,000 should work fine in practice, especially if the logging is throttled and rviz continues to do the best it can with what it has.