ROS 2 sensor fusion in 2026: robot_localization vs fuse vs FusionCore

Manan Kharwar — Mon, 27 Apr 2026 23:31:57 +0000

If you're building an outdoor mobile robot in ROS 2 and need to fuse GPS, IMU and wheel encoders into a single position estimate, you have three real options right now. I've used all three and benchmarked two of them on a public dataset. Here's the honest picture.

robot_localization

The default answer for years. Mature, well documented, large community. It ships an EKF and a UKF node and handles GPS through a separate navsat_transform node that converts GPS coordinates into odometry the filter can consume.

The problems in practice:

navsat_transform uses UTM projection internally. UTM zones are 6 degrees of longitude wide. If your robot crosses a zone boundary mid-mission, the coordinate origin shifts and your position estimate jumps. For most indoor or small outdoor missions this never matters. For large area agricultural or survey robots it's a real issue.

There's no IMU bias estimation. Your IMU's gyro and accelerometer biases drift with temperature and time and robot_localization has no mechanism to estimate them. You absorb the bias error directly into your position estimate.

Noise covariances are static YAML parameters. When your environment changes.... moving from open field to urban canyon: the optimal noise model changes too. You retune manually or you accept degraded performance.

That said: it works, it's in every ROS distro, and if your use case is simple it's probably still the right choice.

Bottom line: Proven, well supported, best choice for simple setups. Starts showing cracks on large outdoor missions or when GPS quality is variable.

Fuse

The designated long-term successor to robot_localization. Factor graph architecture instead of a Kalman filter... theoretically more flexible, supports loop closure, handles delayed measurements cleanly by design.

In practice in early 2026: GPS support is still incomplete. No native ECEF handling, no RTK quality gating. The plugin architecture is powerful but it means every sensor needs a custom plugin and the documentation for writing those is thin. For teams with the engineering bandwidth to build on it, fuse is the right long-term bet. For a team that needs GPS fusion working this week, it's not there yet.

Bottom line: The future of ROS sensor fusion, not the present. Watch it, don't bet your project on it yet.

FusionCore

I built this after running into the navsat_transform UTM zone issue on a real project. It's a 22-state UKF that fuses IMU, wheel encoders and GPS in a single node. GPS is handled directly in ECEF... no coordinate projection, no zone boundaries. Gyro and accelerometer biases are estimated online. Noise covariance adapts automatically from the innovation sequence.

I benchmarked it against robot_localization EKF on 6 sequences from the NCLT public dataset.... a real Segway robot on a university campus with RTK GPS ground truth. Same data, both packages, full reproduce instructions in the repo.

FusionCore wins 5 of 6. On the 6th sequence, prolonged GPS degradation under fall foliage meant the outlier gate kept rejecting GPS while drift accumulated. robot_localization has no gate so it accepted the noisy GPS and self-corrected when signal returned. I think that tradeoff is worth understanding rather than hiding... the gate protects you from spikes but costs you during slow degradation.

robot_localization UKF diverged to NaN on all six sequences.

It's Apache 2.0, in the ROS 2 Jazzy apt repo, and has a Zenodo DOI if you need to cite it.

sudo apt install ros-jazzy-fusioncore-ros

GitHub: https://github.com/manankharwar/fusioncore

Bottom line: Best measured accuracy on this dataset, honest about the one loss, single node with no coordinate transform dependency. Good fit if you need GPS fusion working reliably on a real outdoor robot today.

DEV Community: Manan Kharwar

ROS 2 sensor fusion in 2026: robot_localization vs fuse vs FusionCore