[ros-users] defining interfaces for GPS way-points and mapping
morris at ee.ccny.cuny.edu
Mon Jun 13 19:26:08 UTC 2011
Here are some more links that look interesting
On Mon, 2011-06-13 at 11:08 -0500, Jack O'Quin 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>
> >> > > 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.
Basic Import and Export to and from KML seems like an important feature
we should target for 1.0
> >> > > Bill Morris morris at ee.ccny.cuny.edu writes:
> >> 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.
I am in agreement, this seems like a reasonable approach that allows the
complexity to scale as actually needed.
> 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.
For my needs I will generally want to specify a waypoint as "Above
Ground Level" (AGL), however "Above Sea Level" (ASL) may be more
appropriate for some cases.
SatNav systems provide altitude as ASL, Barometric pressure is
calibrated to AGL usually but you could use ASL. Sonar/Lidar gives you
AGL. You can integrate the data from a variometer to get the current
altitude relative to whatever you want.
My first instinct on this is to use AGL for the waypoint and if you need
ASL of the waypoint you need to do a map lookup. This seems more
practical for aircraft since usually your primary concern is not
However this means that we can't have a function like getIncline(p1,w2);
for ground robots to estimate the slope from the current pose to a
> 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.
If WG will do it, I say kforge with git or svn.
> >> > 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
> 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).
> 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.
I'll throw out some more ideas gis-ros-pkg, geo_messages, Cartograpy,
> >> 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.
I don't where we are in terms of a package review but it might be worth
cataloging the use cases somewhere.
More information about the ros-users