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

[Ken Conley]

On Mon, Jun 13, 2011 at 9:08 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:
> 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.)

We're (very) slowly moving stack development off the unified 'ros-pkg'
repository mainly due to the fact that we prefer our kforge backend to
the gforge backend, but that's the only (minor) pushback on using the
ros-pkg repository.

 - Ken

>>> 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
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>