ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
I had a similar problem looking at PointClouds where the x,y,z was UTM northing, easting, altitude. I ran into a number of issues with the numerical stability of things, as rviz (Ogre) internally uses float32's, which don't have enough precision to work with UTM-magnitude transforms (where we often need many digits to represent the northing to good precision). See https://code.ros.org/trac/ros-pkg/ticket/5394 for some explanation by @hersh . (sidenote: PointCloud2's are also made of floats so those also can't hold UTM coordinates very reliably.)
The good news is that TF can handle coordinates that big to enough precision, so if you transform your inputs into some "nearby" reference frame, it will work. Basically something like utm->base_link
and a utm->nearby
and then set your fixed_frame in rviz to nearby
will force TF to transform all of the data.
As far as automatically setting this, perhaps it could be the center of the current UTM zone (perhaps including the latitude band would be best so that the northing is smaller than relative to the equator)?
That doesn't really solve the issue of getting rviz to "snap" to some location (like the center of the currently displayed map tiles), but that could be solved with another transform from say, utm->centered_view
so that you could set your target_frame accordingly. Note that none of this changes the actual coordinate system that the map or things like the vehicle's location are in (that can still be UTM), just sets up some extra TF's to make things easier to visualize.