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
------------------------------------------------------------
(text/plain)