@msmcconnell, After looking into it a bit closer, the gpsins_localizer will have to keep the dependence on the novatel msgs in the short term. The novatel_span_driver doesn’t use gps_common. The novatel_gps_driver does publish it but it’s missing almost all useful data. This could/should be improved in the driver, but at the moment it’s not useful.
In terms of covariance info, I agree with you, but currently autoware’s architecture is setup to use geometry_msgs/PoseStamped for estimated localizer pose and geometry_msgs/TwistStamped for localizer velocity. So adding covariance would need to be done with message type changes to all existing localizers and subscribers to localizers. Something I feel should be discussed and done later in a larger localization architecture MR (we were sort of working towards that in this thread before it stalled).
I think this is why I didn’t upstream this package in the first place, because I wasn’t sure how best to fit it into autoware’s existing localization architecture.
That being said, I think the gpsins_localizer package still has value as the only localizer in autoware that conforms to REP-105, allows people to use GPS data outside of Japan, and allows people to localize without the need of a lidar.
I’m hoping I’ll have time to do a more formal review of the localization situation in autoware and we can move it towards REP-105, but I can’t guarantee anything unfortunately.