FusionCore
ROS 2 UKF sensor fusion: GPS+IMU+wheels, zero manual tuning
Start new thread

FusionCore 0.3.2 - Robust sensor fusion for ROS 2, zero manual tuning

by•
FusionCore is a production-grade ROS 2 sensor fusion library. A 23-state UKF fuses GPS, IMU, and wheel odometry with adaptive noise estimation (no manual Q tuning), chi-squared outlier rejection that catches GPS multipath spikes before they move the estimate, inertial coast through GPS dropouts, and ECEF-native GPS that works anywhere on Earth. Benchmarked against robot_localization on the NCLT outdoor dataset: ahead on 10 of 12 sequences. ROS 2, Apache 2.0.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt 👋 I'm Manan, founder of FusionCore. The same thing kept biting outdoor robots I worked with: robot_localization is the ROS default, but the moment GPS goes bad near buildings, trees, or steel, the filter trusts the bad fix and the robot lurches off course. Getting it to behave is a tuning rabbit hole most teams don't have time for. FusionCore is the answer I wanted: a 23-state UKF that adapts its noise automatically (no manual Q tuning), rejects GPS multipath spikes with a chi-squared gate before they move the estimate, and coasts on IMU plus wheel odometry through full GPS dropouts. On the NCLT outdoor dataset it's ahead of robot_localization on 10 of 12 sequences. Apache 2.0, and it stays that way. Since the last launch, 0.3.2 shipped the fix I'm proudest of: a sustained GPS spike can no longer sneak past the outlier gate, and the filter now survives a clock rewind instead of crashing. If you run anything outdoors on GPS, I'd genuinely love to hear what you're using for localization and where it breaks.
🧐 Good find

The ECEF-native GPS handling is a really thoughtful choice — so many sensor fusion libraries quietly assume small working frames and then break the moment you cross a UTM boundary. Glad to see someone took that seriously from day one.

Maker

 Thanks, you spotted the thing I was most stubborn about. Most fusion stacks pin everything to a local ENU tangent plane or a single UTM zone, which is fine right up until the robot drives far enough that the flat-earth assumption starts to drift, or crosses a zone boundary and the coordinates jump. Keeping the state in ECEF means there's no special-casing and no discontinuity, it just works whether you're on a 10m test patch or a cross-country run. Are you working on something geospatial yourself, or do you just have the scars from a frame bug too?