[ros-users] Standard GPS Message

[Rene Wagner]

Hi all,

On Fri, 2010-10-08 at 16:14 -0400, Eric Perko wrote:
> What additions to a GPS message would make it easier to interface to
> googlemaps?

I think we should treat Google Maps and the like as what they are, part
of the user interface/presentation layer that clearly shouldn't
influence how core layers represent GPS/GNSS data. Any sound internal
representation will enable conversion to whatever format the UI expects.

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

Agreed. I guess we could flag each data point as, say,
"original" (calculated by the receiver), "derived" (in software) or
"unavailable".

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

Dilution of precision is a fairly theoretical value: It is computed
solely from the geometrical configuration (as seen by the receiver) of
the satellites used in the positioning solution. So, it's merely a lower
bound on the expected error but doesn't necessarily reflect the
magnitude of the actual error.

The err* fields should ideally be derived from the covariance matrix of
the receiver-internal Kalman filter, thus representing what the receiver
thinks the actual error currently is.

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

Agreed. In my experience an optional status isn't useful in practice.

> Is there a datum and/or ellipsoid that many others can be converted
> to?

Offhand I can't think of any reason why you couldn't convert arbitrarily
between different representations as far as individual points are
concerned. Preserving distance information would be a different story.

Which relevant representations are there in practice though? On the user
visible and interface layers GPS is pretty "hard wired" to WGS84 (due in
part to the ubiquitous use of NMEA). ECEF (Earth-centered, Euclidean) is
popular as the state representation used by the receiver-internal Kalman
filter.

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

I agree in general. I would add the following requirement though: The
ROS driver should retrieve data in the format used by the receiver
internally (if possible by any means) and use a well
documented/understood software routine to do the conversion. I have seen
receivers where the conversion from the internal ECEF datum to WGS84
apparently lost precision.

Cheers,

Rene

-- 
------------------------------------------------------------
Dipl.-Inf. René Wagner                     Junior Researcher
DFKI Bremen                           Enrique-Schmidt-Str. 5
Safe and Secure Cognitive Systems             D-28359 Bremen

Phone: (+49) 421-218-64224       Fax: (+49) 421-218-98-64224
Email: Rene.Wagner at dfki.de       Web: http://www.dfki.de/sks
--- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Deutsches Forschungszentrum für Künstliche Intelligenz  GmbH
Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern

Geschäftsführung:
   Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
                                          Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
                                Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern                          HRB 2313
------------------------------------------------------------