UTM Message

[Chad Rockey]

Do we have a ROS message already for UTM converted NavSatFix?

I'm working on Unscented Kalman Filter functionality for ROS, and I'd like to test absolute position filtering with GPS.

https://github.com/chadrockey/graft

Do we have a specific UTM message or should we convert into something more generic like http://www.ros.org/doc/api/geometry_msgs/html/msg/PoseWithCovarianceStamped.html and leave the orientation with -1 in the covariance diagonal?

- Chad

[Eric Perko]

There's a number of different types available in geodesy (no UTM message however): http://ros.org/doc/hydro/api/geodesy/html/c++/namespacegeodesy.html 

It looks like there's support there for going from a NavSatFix to a UTMPoint (via a GeoPoint), but not the other way around (which makes sense since it drops some information).

Is there any particular reason you want to add a UTM interface for graft as opposed to only supporting Lat/Lon based absolute position inputs? During the original geographic_info review, we decided to drop UTM-based messages in favor of a single Lat/Lon interface ( http://ros.org/wiki/geographic_info/Reviews/2011-06-18_Proposal ).

- Eric

--
You received this message because you are subscribed to the Google Groups "ros-sig-geographic-info" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-geographi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Chad Rockey]

Thanks for the help, it's been a long while since I've used GPS for anything.  My use case is just converting lat/long/altitude into Cartesian x/y/z coordinates.  I'll use geodesy directly then; I was hoping to not force it as a dependency.

What technique should I use for changing zones?  I was hoping I could set the converting library to 'lock' to a zone.  Otherwise, I'll have to add more output options and automatically adjust filter state.  :)  Either way I feel very sorry for whoever tries to run this near a boundary first.  Maybe I'll take a vacation to somewhere near LA/San Diego.  :P

---

On the other hand, should I use UTM?  Is there an alternative that will output the simple case of "offset from startup location"?

[Eric Perko]

On Wed, Aug 7, 2013 at 9:21 PM, Chad Rockey <chadr...@gmail.com> wrote:

Thanks for the help, it's been a long while since I've used GPS for anything.  My use case is just converting lat/long/altitude into Cartesian x/y/z coordinates.  I'll use geodesy directly then; I was hoping to not force it as a dependency.

What technique should I use for changing zones?  I was hoping I could set the converting library to 'lock' to a zone.  Otherwise, I'll have to add more output options and automatically adjust filter state.  :)  Either way I feel very sorry for whoever tries to run this near a boundary first.  Maybe I'll take a vacation to somewhere near LA/San Diego.  :P

I've not really found any good information about changing zones (e.g. how far can you extend a zone and what does that do to the projection error) besides that you can do it via reprojection. The closest I've heard is along the lines of "they are designed to overlap a bit and you can extend a given zone for X without suffering too badly" (where X was... 500m?? if I'm recalling correctly). 

If you are outputting a geographic absolute position, you should probably output a GeoPose (or GeoPoint, whichever you have enough data to fill) with covariance info to allow the user to project it into whatever system they'd like. Not everyone uses UTM/UPS depending on needs. If you want to output UTM, you'd also have to determine if you were outputting zones (specifically latitude bands) compatible with MGRS or just standard UTM zones (which don't cover the poles).

 

---

On the other hand, should I use UTM?  Is there an alternative that will output the simple case of "offset from startup location"?

What size areas are you expecting to filter? 100s of meters? 10s of km? 100s of km? Trans-oceanic voyages? I'm not sure that geodesy has support for it (yet), or how to do it with PROJ.4, but I've used GeographicLib [1] to project Lat/Lon points into a "local cartesian" frame [2]. That let's you simply pick a reference Lat/Lon and project/unproject into some basically "offset from reference" coordinate system. It's working fairly well over reasonable distances, but we did recently notice some significant error when trying to project points that are far from the reference (where far is closer to ~500-1000km so probably a bit more than you care about for graft :-) (note UTM zones are ~660km wide at the equator) ).

GeographicLib also has support for creating your own arbitrary reference for a Transverse Mercator transform [3], which would allow you to move the reference meridians (UTM is just a TM transform with a fixed set of reference meridians). 

If you don't expect the GPS positions to be far apart, you could simply use the offset from the previous position, calculated by assuming the Earth is flat between them (which for distances in the 10s of meters is definitely a solid approximation). I've done that on a few different projects and it worked out fairly well for ground vehicles with standard GPS update rates. No fancy projections required if you don't need to keep a lot of data in the same reference frame (say for a grid map or something).

- Eric

[1]: http://geographiclib.sourceforge.net/

[2]: http://geographiclib.sourceforge.net/html/classGeographicLib_1_1LocalCartesian.html

[3]: http://geographiclib.sourceforge.net/html/classGeographicLib_1_1TransverseMercator.html

[Nick Armstrong-Crews]

I know I'm out of the loop on this one, but as a passing comment: be wary of covariance on manifolds (i.e., using any flavor of Kalman filter on lat/long coords or UTM). Differential geometry and information geometry are hard, and figuring out how converting coord paramaterizations affects covariance (i.e., how the distribution that used to be Gaussian in the original space is warped into a hideous abomination in the new space) is black magic. I strongly advise doing all back-end calculations in Euclidean space (e.g., ECEF), and only allowing client interfaces to use UTM/lat-long/whatever. You'll need to use 64-bit data types for ECEF, but at least your calculations will be theoretically sound. You could also center your local coord system around some point in ECEF, allowing 32-bit math to suffice, and you're still no worse off than the local coord systems used in UTM.

[Jack O'Quin]

Sorry for the very late response...

On Wed, Aug 7, 2013 at 8:21 PM, Chad Rockey <chadr...@gmail.com> wrote:

Thanks for the help, it's been a long while since I've used GPS for anything.  My use case is just converting lat/long/altitude into Cartesian x/y/z coordinates.  I'll use geodesy directly then; I was hoping to not force it as a dependency.

It's not intended to be a very heavy dependency. Mostly it wraps python-pyproj.

But, the C++ implementation does not (yet) use PROJ.4. We should probably update that so you'll have a more stable dependency.

 https://github.com/ros-geographic-info/geographic_info/issues/2

What technique should I use for changing zones?  I was hoping I could set the converting library to 'lock' to a zone.  Otherwise, I'll have to add more output options and automatically adjust filter state.  :)  Either way I feel very sorry for whoever tries to run this near a boundary first.  Maybe I'll take a vacation to somewhere near LA/San Diego.  :P

I like the idea of locking to a zone. That should work fine for local navigation. Geodesy does not currently have that, but it should be easy to add. I'll add it, if you've a need.

I don't recall the exact numbers, but I'm fairly sure that even 10's of kilometers outside the zone the projection errors are small enough for practical purposes.

On the other hand, should I use UTM?  Is there an alternative that will output the simple case of "offset from startup location"?

I like UTM. As Eric and Nick mentioned, there are other reasonable options. Each has advantages and disadvantages.

When working on our driverless car, I found it best *not* to use startup-relative coordinates. The reasons were many, some subtle. They included restarting a run that started elsewhere, and analyzing data collected from multiple runs. 

It was really helpful to have a one-to-one mapping from lat/lon to UTM. Locking onto a specific zone would affect that, I suppose. But, even if it's not one-to-one, I suspect we can reliably convert UTM coordinates back and forth between adjacent MGRS zones. It's also possible to use smaller grid cells, as the military does with MGRS. 

Even though I am not working on the car any longer, I continue to believe that long-distance planetary surface navigation should be done using lat/lon for high-level path planning and UTM (or something similar) for local or regional navigation and obstacle avoidance. 

That does require some ability of the navigation to shift zones from time to time. As you say, it'll be hard to test, but could probably be tested in simulation with an appropriate starting coordinate choice. 

--
 joq