Feature: GPS velocity fusion via generic gnss.velocity_topic

[manankharwar]

Background

This came out of a conversation with the ublox_dgnss maintainer (@hortovanyi): aussierobots/ublox_dgnss#63

The ublox UBX-NAV-COV message carries a full 3x3 velocity covariance in NED that NavSatFix does not have. Fusing GPS velocity as an independent measurement alongside wheel odometry would be useful for slip detection: if GPS velocity and wheel odometry disagree, the wheels are slipping.

Why not native UBX messages

@amock correctly pointed out that adding a direct dependency on ublox_ubx_msgs would force every FusionCore user to install ublox packages at compile time, even those running Septentrio, ZED, Piksi, or any other receiver. That breaks hardware-agnostic packaging for a single vendor benefit.

Revised design

FusionCore adds a generic gnss.velocity_topic that accepts geometry_msgs/TwistWithCovariance. Any receiver that outputs GPS velocity in that format plugs straight in.

fusioncore:
  ros__parameters:
    gnss.velocity_topic: "/gnss/velocity"   # leave empty to disable

For ublox users specifically, a small separate bridge node subscribes to UBX-NAV-PVT and UBX-NAV-COV and republishes as TwistWithCovariance. That bridge lives in its own package with no impact on non-ublox users.

What this enables

• GPS velocity fusion as an independent measurement update (separate from wheel odometry)
• Slip detection: innovation between GPS velocity and wheel odometry reveals wheel slip
• Velocity stays valid during brief GPS position degradation, bridging dead-reckoning gaps
• Works with any receiver that publishes velocity, not just ublox

What stays the same

FusionCore core has zero new vendor dependencies. The ublox bridge is a separate optional package.

cc @hortovanyi @amock

[amock]

Hi @manankharwar,

I just read this issue and wanted to share a thought. Even though I like u-blox a lot, this change introduces a manufacturer dependency. That means people using other GNSS hardware providers would still need u-blox as a dependency. Have you considered this? Could it become a problem?

What about using more generic message types like a partially filled nav_msgs/Odometry or gps_msgs/GPSFix? Or do they also miss some important parts you need? From a quick check, it seems that gps_msgs/GPSFix at least lacks the 3x3 velocity covariance.

Greetings,
Alex

[manankharwar]

Hey @amock, really glad you raised this before any code was written.

You're completely right. If FusionCore added a direct dependency on ublox_ubx_msgs, every single user would need to install ublox packages at compile time, even if they're running a Septentrio, a ZED camera, a Piksi, or anything else that has nothing to do with u-blox. That would be a bad trade: one vendor's extra covariance data in exchange for breaking the hardware-agnostic packaging that makes FusionCore useful in the first place.

I think a better approach is to keep FusionCore's GPS input layer hardware-agnostic and solve this a different way. Instead of subscribing to UBX messages directly, FusionCore would add a generic gnss.velocity_topic that accepts geometry_msgs/TwistWithCovariance. Any receiver that publishes GPS velocity and covariance in that format can plug straight in. For ublox users specifically, a small separate bridge node would subscribe to UBX-NAV-PVT and UBX-NAV-COV and republish as TwistWithCovariance. That bridge can live in its own package and has zero impact on anyone not using ublox hardware.

This way:

• FusionCore core stays clean with no vendor dependencies
• ublox users still get GPS velocity fusion and the receiver covariance
• Any other receiver that outputs velocity (Septentrio, Swift Navigation, etc.) works through the same generic topic without any bridge needed

Going to update the issue description to reflect this design. Thanks for catching it early, this is exactly the kind of feedback that keeps the architecture clean.

[samuk]

Do you have any estimate of when this might land? I'm hoping to use fusioncore with F9P, just working out what topics to use

[manankharwar]

Hey @samuk, I started working on this last week and it’s almost done. I’m planning to finish it up tomorrow. Since it uses the generic gnss.velocity_topic path, it should work nicely with F9P setups too.