FusionCore
ROS 2 UKF sensor fusion: GPS+IMU+wheels, zero manual tuning
9 followers
ROS 2 UKF sensor fusion: GPS+IMU+wheels, zero manual tuning
9 followers
FusionCore is a production-grade ROS 2 sensor fusion library. It runs a 22-state UKF fusing GPS, IMU, and wheel odometry with adaptive noise estimation (no manual Q tuning), Mahalanobis outlier rejection for GPS spikes and IMU glitches, and ECEF-native GPS handling that works at any scale. Benchmarked against robot_localization on the NCLT outdoor driving dataset: FusionCore wins on 5 of 6 sequences, up to 4 × lower ATE. Apache 2.0.
This is the 2nd launch from FusionCore. View more
FusionCore 0.3.2
Launched this week
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.
Free
Launch Team / Built With
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.
@kamile1142718 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?