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

[Jack O'Quin]

On Mon, Jun 13, 2011 at 9:48 AM, Eric Perko <wisesage5001 at gmail.com> wrote:
> 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>
>> > > 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.

Agreed. It is very useful for certain types of visualization. Chad
proposed export and import for that format.

>> > > 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.

I think the basic way-point message should be fairly small and simple,
because maps will contain a lot of them. We can define higher-level
messages like NamedWayPoint, or WayPointWithCovariance that embed
simpler messages. Similarly, I believe the basic WayPoint message
should have no Header.

One other WayPoint field I think we *should* add: "altitude".
Unfortunately, most of the mapping databases don't include much
elevation information, but I'd hate to define a bunch of interfaces
that were only 2D. We need a "missing" value for altitude (NaN
perhaps?). Unfortunately, messages constructors will default to 0.0,
which is a perfectly valid elevation.

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

I think a WayPointTarget could contain a WayPoint and some of these other data.

>> 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.

I prefer to define a new messages package (see below).

>> > 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.

I like that approach. We don't have to release the new stack with
Electric, we can develop on Electric and target Fuerte for an initial
release.

I recommend avoiding the GPS acronym. This stack is really about
mapping, topography, and geographic navigation. The fact that the
lat/long values of the way-points come from one of several navigation
satellite services is a lower-level detail.

I nominate "topography" as the stack name (other suggestions welcome).

 http://en.wikipedia.org/wiki/Topography

The messages can go in a topography_msgs package, included in that
stack. We could move that package to common_msgs later, if that ever
makes sense.

For me, the most convenient repository would be ros-pkg. I believe it
should go there eventually, so we might as well work there until the
new stack is ready to release. I doubt anyone at WG would oppose
adding a "topography" stack (or whatever we choose to call it) to
ros-pkg, as long as we commit to maintaining it and provide good
documentation. (I am willing to create or maintain a different repo if
y'all prefer someplace different.)

>> 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.

Good point. We should keep it in mind.
-- 
 joq