[ros-users] Standard GPS Message

[Eric Perko]

Bill,

I'd also like to see this happen before the deadline and would be willing to
participate in the review process.

On Fri, Oct 8, 2010 at 2:58 PM, Bill Morris <morris at ee.ccny.cuny.edu> wrote:

> On Thu, 2010-09-16 at 11:16 -0500, Jack O'Quin wrote:
> > I think it's about time to resurrect this discussion about adding GPS
> > messages to sensor_msgs for the Diamondback release. Getting the
> > messages defined early and committed to unstable will provide people a
> > chance to experiment with them before interfaces get frozen for the
> > release.
> >
> > I am interested in participating. Let's discuss options some more here
> > on the mailing list. If there is a consensus on a fairly concrete
> > approach, we could probably start a package proposal and API review on
> > it soon after.
>
> I'm interested in making this happen, and now we have a deadline.
> I would like something similar to the GPSd message but with additions to
> make it easier to interface to googlemaps and navigation systems.
>
> Perhaps one approach is to break the GPS messages down into several
> primitives; a point, a volume and a vector.
>

What additions to a GPS message would make it easier to interface to
googlemaps? Don't we just need a lat/long in order to draw a marker in
googlemaps? I think it is very important to split the message into basic
chunks and build composite messages of that with indicators of whether or
not to use the data. This is especially important for non-GPSd devices - I
have a GPS unit that currently only outputs lat/long/altitude, standard
deviations on each of those in meters, a fix type and number of satellites
used. This would leave some of the fields empty in the current GPSd message
with no way to say whether or not they should be used. Do we really need
both dilution of precision information and the err* fields or can one be
derived from the other?


> I think it would be best to separate the geometry from the satellite
> information. this way status information can be optional.
>

I think it would be best to actually have a GPS position message that
includes both the fix itself and status information. Anytime I've used GPS,
we've always needed the status information to tell us whether or not to even
believe the fix information at all, so I'm not sure how useful an optional
status is.


>
> The next question is it worth supporting multiple datums and ellipsoids?
>

Is there a datum and/or ellipsoid that many others can be converted to? I
think it would be best to specify one for this message so that any tools
such as the gpsd_viewer only have to worry about one datum and ellipsoid. A
gps_tools package could then provide conversion facilities (perhaps similar
to the laser_filters used by the laser_pipeline). Mainly, I don't want to
have to write code over and over to handle which  GPS reference system is
being used in order to support arbitrary GPS receivers.


>
> In addition to the messages I would like to see a gps tools package with
> functions for calculation of distance, time of arrival, time to
> intercept, direction to waypoint and etc.
>

I'd also love to see a reusable set of functions for this. However, I think
it's separate from the message definition process besides anytime during the
message definition process where we can say that a gps_tools package could
handle a conversion instead of having to make the message itself handle it.


>
> My use case is a quadrotor helicopter that needs to fly from point A to
> near point B to point C. It would also be nice for the aircraft to track
> moving objects as we are looking towards implementation of swarm
> control.
>
> Eventually we are looking toward building 3D map infrastructure so that
> we can have the aircraft flying in a global map, switch to a local map
> as it approaches a building and switch to a floor map as it enters the
> building.
>
> Related Info
>
> http://earth-info.nga.mil/GandG/publications/tm8358.1/toc.html
> http://code.google.com/apis/kml/documentation/kml_tut.html
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101008/51c94141/attachment-0004.html>