On Fri, 2011-06-03 at 21:24 -0500, Jack O'Quin wrote:
> On Wed, Jun 1, 2011 at 5:33 PM, Chad Rockey <
chadrockey@gmail.com> 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.
I think KML should be useful as a guide and definitely a target for
interoperability. I'm not sure kml is appropriate for everything that
will be needed but it will be nice if we can output kml.
>
> > 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.
I think that we should use ID, latitude and longitude as the initial
definition of a waypoint so we are all on the same page.
If we fix this then it will be easier to share code between the groups.
I'm undecided if a waypoint needs a volume, a human readable name, or
covariance. Should the determination of the requirements for achieving
the waypoint be separated from the position of the waypoint.
Ground tasks are usually something like start at A drive to within 10m
of B then proceed to within 20m but no closer then 2m (the waypoint is a
tree) of C and stop within 1m of D.
Aerial tasks will be something like start at A pass through B with a
heading of 270deg magnetic and proceed to C and circle the waypoint with
a range of 10m-15m at an altitude of 30-40m for 10minutes before landing
at D 3m above sea level
> 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
I think nav_msgs is the right place
http://www.ros.org/wiki/nav_msgs
Is gps_common fully integrated at this point?