| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
When we are going to tweak NavSatStatus, why not tweak NavSatFix as well with additional fields?
Also I would rather have a separate message for velocities.
0: Tweaked NavSatFix with tweaked NavSatStatus. (including datum)
1: Heading
2: Velocities
3: Fix details (AR ratio, satellites visible/used, etc).
(4: raw observations)
@danthony in the UBLOX DGNSS driver I publish UBX messages with the data as ROS2 messages - I wouldnt rely on the old messages which I believe were originally based on NMEA and GPSD - have a look at https://github.com/aussierobots/ublox_dgnss and the ublox_ubx_msgs. For my projects I presently use UbxNavSat and UbxNavOrb - to work out the satellite vehicle need to refer to the ublox documentation. They all have constellation ids and satellite vehicle ids within the constellations
@Conpleks I am not saying that all GNSS operates in WGS84 - I am saying that for a message type for robots that could operate anywhere in the world, we should choose a default reference frame.
In practice all GNSS operates in a 3 dimensional reference frame so in principle it is possible to transform a fix from one 3-D reference frame to another, and of course, multi-constellation receivers do this all the time. We should probably pick the reference frame that is most commonly used by most receivers then it becomes easy to publish that fix as a message.
Of course if for some reason you have a receiver that only spits out in say a PZ-90 reference frame and doesnât do the transformation for you, then you can still transform from one 3-D reference frame to another before publishing the message.
As far as possible the person writing the node that publishes the message should worry about the coordinate transform probably not the person writing the node that subscribes to the message.
It shouldnât be difficult to write a message filter that does these transformations, utilizing geographiclib or something similar. But that requires the datum to be a part of the measage.
One of the principles in ROS sensor drivers is to output as raw data as possible, only converting them to SI units. Iâd like to keep that.
Yes you can convert the reference frames but it very complicated and also processor intensive. When we ship robots with world wide RTK then I would much rather not have to do that, and simply have the datum be reported as it is from the GNSS receiver.
I work for Trimble and maintain (when I have time) a ROS driver for reading data from our GNSS products such as high performance inertial navigation systems or multi-use receivers for surveying and machine control.
Happy to help any way I can 
Please tag me in any PR or RFC that comes out of this discussion.
Great - thanks for the offer of help.