I'd also like to see this happen before the deadline and would be willing to participate in the review process.
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