On Wed, Jun 1, 2011 at 5:33 PM, Chad Rockey wrote: > Hi Jack, > Eric and I are both finishing our theses and starting jobs this month, but > we'd be willing to provide our limited input to this.  We've only worked > with off-road mobile robots with very simple waypoints, nothing like Open > Street Maps or Google Maps; although something like that would be great to > see happen. > I do like the idea of a common UTM conversion tool. UTM conversions are fairly easy and quite useful. We've got some that can be used. They need some cleanup, so better implementations would be welcome. > Another possible tool would be KML import and export to waypoints/paths, > since this makes it easy to visualize and create paths in Google Earth/Maps. >  For our waypoints, we would define them in KML files either by clicking in > Google Earth or manually typing in coordinates.  Then we could feed this to > our robot which would start following them in order or we could look at the > path either as markers or as a polygon in Google Earth.  Even though the > imagery data could be a meter or two off, it was still very useful when > great precision wasn't required or we just wanted to look at the overall > shape/order. > > Here is an example KML path > file: http://code.google.com/apis/kml/documentation/kml_tut.html#paths KML should definitely be considered. Good idea. > Bill Morris morris@ee.ccny.cuny.edu writes: > > One of our projects this summer requires GPS based navigation for aerial > robots so I'll be working on this more later in the summer. I would like > to see GPS waypoints defined in E-Turtle and a gps_tools library for > Fuerte. I could imagine defining a way-point ID as a 128-bit opaque value, able to hold a UUID if desired. The basic WayPoint message would at least contain an ID, latitude and longitude. Maybe that's it. Lat/Long needs to be defined unambiguously, probably using fractional degrees, positive North and East, negative South and West. Getting those messages defined, reviewed and agreed to in time for E-turtle sounds difficult but possible. Should they go in some common_msgs package? If so, which one? http://www.ros.org/wiki/common_msgs If there is still design and development work to do before we know what to standardize on, I suggest picking a repository and working together on a general stack for mapping-related packages. We could use the utexas-art-ros-pkg repo for that, maybe ros.org, or some other. Perhaps it would be best to create a new repo just for this. I'll volunteer to maintain it wherever seems best and most convenient to the participants. We could do both: define a standard WayPoint and WayPointID, but create a separate repo for GPS tools. What do y'all suggest? --  joq