Hi all,

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.

Is there anything like a current proposal/working draft of a GPS
message? I believe that should allow us to streamline the discussion and
get up to speed with the standardization effort.

Generally speaking, I would suggest the following:

- Focus on representing the raw data first, i.e., avoid lossy coordinate
  system transforms (any projections into planar approximations, etc.).

- Consider which coordinate system is best. Candidates are (at least)
  WGS84 and ECEF. It might also be worth having both and indicating
  which is used by the receiver internally (this may be important when
  post-processing logs).

- Consider whether one could standardize a GNSS (global navigation
  satellite system) message to cover GPS, GLONASS, Galileo, etc.
  (RTK-)Receivers that support both GPS and GLONASS are gaining
  popularity over here (central Europe) since GPS and GLONASS
  geometrically complement each other quite nicely (southern vs.
  northern hemisphere respectively). All GNSS are conceptually quite
  similar. I don't know how feasible a common message format would turn
  out to be in detail and this is certainly not a "must".  In fact it's
  perfectly fine to decide against a common message type but I'd like to
  avoid a situation where GLONASS users end up converting their data
  into GPS messages in some lossy fashion. 

- Avoid replicating GPSD structs - I believe we can do better in ROS.
  E.g. gps_common/GPSStatus stores information on visible satellite in
  multiple separate arrays. I think this should be a single array of
  a custom satellite (sub-)message.

- Decide for a specific naming scheme, particularly for or against the
  use of acronyms early on, e.g., satellite vs. space vehicle vs. SV.
  The "plain English" variant (satellite) is probably easiest for novice
  or casual users to work with.

- Be very specific when defining fields. E.g., gps_common/GPSFix has
  various err_* fields but it isn't obvious to me whether these are
  1-sigma errors or something else.

- I wonder whether a split such as the one between gps_common/GPSFix
  and gps_common/GPSStatus is a good idea. In my own (as yet non-ROS)
  outdoor code I always take both types of information into account (to
  e.g. discard positioning results when not enough satellites are
  visible). To do the same in a ROS node I wouldn't want to look for
  matching messages from different topics first.

That's all for now.

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
Web: http://www.informatik.uni-bremen.de/agebv/en/ReneWagner
--- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
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
------------------------------------------------------------