How to view map regions with large coordinate values using rviz?

asked 2012-05-09 07:11:14 -0500

joq
25443 ●181 ●256 ●408

I am experimenting with Open Street Map, and want to visualize my data using rviz.

The problem is that the natural coordinate system to use is UTM, which tends to generate rather large offsets, like (622191, 3362020), from the /map origin.

There must be some way to shift the rviz view from (0, 0) to (622191, 3362020), but I have not discovered a reasonable solution. On Fuerte, I was able to save a view, then edit the .vcg file to fill in the desired coordinates. Messy, but it worked. On Electric, I can't even get that to work.

Surely there is a better approach?

edit retag flag offensive close merge delete

Comments

1

The coordinate frame for saving view pose changed between Electric and Fuerte. Fuerte uses a frame consistent with the rest of rviz, where X and Y are on the ground plane and +Z is up. I think Electric used the typical Ogre frame, where +Y is up, but there were bugs which lead to inconsistencies.

hersh ( 2012-05-10 08:30:22 -0500 )edit

add a comment

5

answered 2012-05-09 10:11:56 -0500

Eric Perko

8406 ●73 ●90 ●144 http://ericperko.com/

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.

edit flag offensive delete link

Comments

Thanks, Eric. I was considering a similar approach, based on the hint from @alfa_80. Good to know this works for you.

joq ( 2012-05-09 10:39:06 -0500 )edit

We do something similar at times as well

Ryan ( 2012-05-09 13:11:33 -0500 )edit

add a comment

1

answered 2012-05-09 07:21:29 -0500

alfa_80
1051 ●123 ●137 ●150

updated 2012-05-09 07:22:03 -0500

What I normally did in solving such a problem is that, I set a fixed known offset value as the origin of /map coordinate frame, instead of using (0,0). I know this might not be an optimal or agile solution, though, but it works in my case.

edit flag offensive delete link

Comments

Thanks for the suggestion, but that would not work well for this application. The goal is to visualize maps set anywhere in the world.

joq ( 2012-05-09 07:47:39 -0500 )edit

Yes, for your application if wouldn't suffice. Sorry, I've overlooked it.

alfa_80 ( 2012-05-09 08:04:13 -0500 )edit

I don't quite understand why this won't work? When you get a map from OpenStreetMap, there's the bounds minlat/minlon value. If you use this as offset to all your GPS (converted to UTM) readings, it should work, right?

weiin ( 2012-05-09 15:10:49 -0500 )edit

That's OK for display purposes (see other answer). But, I don't want to recode all the UTM points in some local map frame. Ultimately, we want to travel long distances. That requires a map hierarchy, and the ability to stitch maps together.

joq ( 2012-05-09 16:09:42 -0500 )edit

add a comment

1

answered 2012-05-10 08:43:32 -0500

hersh
1351 ●16 ●21 ●28

To automate the "snapping" from one coordinate frame to another, consider writing either a new program which links against "librviz" or writing a Display plugin for rviz.

In either case, your code will have access to rviz::VisualizationManager and its function setFixedFrame(). If you leave the target frame set to "<fixed frame="">" then changes to the fixed frame will be reflected in the target frame automatically. If you don't want that, you can call setTargetFrame().

The whole-new-program approach is described in the librviz tutorial, and the display plugin approach is described in the imu display tutorial.

With the plugin version, your new Display class could listen to a topic which publishes the currently-desired map frame name, and just call setFixedFrame() with the result each time.

With the librviz version, you could really do anything you want, integrate an rviz 3d view window into an existing Qt application, listen for messages, whatever.

These comments are relevant to the Fuerte version of RViz.

edit flag offensive delete link

add a comment

How to view map regions with large coordinate values using rviz?

Comments

3 Answers

Comments

Comments

Question Tools

Stats

Related questions

How to view map regions with large coordinate values using rviz? edit

Comments

3 Answers

Comments

Comments

Question Tools

Stats

Related questions

How to view map regions with large coordinate values using rviz?