[ros-users] defining interfaces for GPS way-points and mapping

[Eric Perko]

On Mon, Jun 13, 2011 at 7:43 AM, Bill Morris <morris at ee.ccny.cuny.edu>wrote:

> 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 at 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 at 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?
>

I thing having a separate GPS tools stack is best, containing gps_msgs
package, gps_visualization, gps_tools, etc. Currently, nav_msgs is described
as messages for interfacing with the navigation stack, which does not deal
directly with GPS (at least not yet). I prefer not putting these into
common_msgs or other released stack. This will allow for much faster
iteration, ignoring backwards compatibility, etc while fleshing out what
will go into the first release. If we put the messages into common_msgs, we
are stuck with the release schedule for common_msgs. I would much prefer
something like what trajectory_msgs did - started out in pr2_controllers,
became useful outside of that stack and was then moved to 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.
>
> Maybe someone at ros.org/wg can setup gps-ros-pkg to hold all of the
>
>> packages related to GPS while we figure things out. My alternate
> preference would be github followed by something similar supporting svn.
>

kforge.ros.org would let us setup a git repo, trac, etc right (or Hg or
svn), correct? If we can't get a repo hosted by WG, I vote for Github.


>
> > We could do both: define a standard WayPoint and WayPointID, but
> > create a separate repo for GPS tools.
>
> I would like a separate repo for GPS tools so we cut down on duplication.
> I think a standard waypoint message would be nice but I'm fine if we can
> put it in the gps tools repo until fuerte.
>

Agreed, see above.

- Eric

P.S. Removed all of the extra CC's, since the message got bounced originally
due to having too many recipients.


>
> Another thing to contemplate is if there is a need for a NavSatPose message
> or if Pose should be used with x and y
>
>> set to lat and lon, or if it is better to use the navsatfix message.
>
>>
> One of the more important library functions that will need to be written is
> a way to request the heading
>
>> to a waypoint given the current position and orientation.
>
>>
>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110613/40fb9a7a/attachment-0002.html>