gps_common/GPSFix has wrong time data

[icolwell-as]

The gps/gps topic publishing gps_common/GPSFix messages is using the utc field from the novatel messages to fill the time field in the ROS message instead of GPS time.

[pjreed]

Ah, that's a good catch. That's definitely not correct, although something to note is that the GPGGA log does not actually report GPS time, so in order to fill that field in properly, the driver would need to get the GPS time from a log that it synchronizes together with GPGGA such as BESTPOS. We could try to estimate it if we fail to synchronize logs for some reason, but I feel like that might be misleading and it'd be better to just leave it blank...

Although the more I look at it, the more I feel like the current approach to generating GPSFix messages -- which is to combine data from GPGGA and GPRMC logs and augment them with BESTPOS logs when possible -- might be better if it were inverted and it used BESTPOS logs as the basis for it and augmented that with GPGGA/GPRMC data when possible. I might test that out and see how it works...

[pjreed]

All right, if you'd like to take a look at it, I think the branch in #74 should put the correct timestamps in GPSFix messages. It will also use BESTVEL logs to fill in the speed/track and PSRDOP2 logs to fill in the DoP values if it is configured to publish those.

This is actually a pretty significant rewrite of how GPSFix messages are generated, so I'd like to get some more testing for it before I merge it into master.

[icolwell-as]

Does it make sense to use INSPVA as the basis for GPSFix? I didn't compare the fields in detail, but they seem to have some overlapping data. INSPVA has gps week and seconds.

[pjreed]

I think BESTPOS is preferable over INSPVA; BESTPOS is supposed to be the best position calculated by the receiver, which can incorporate INS data, but also INS logs are only available on receivers with SPAN support.