FusionCore vs fuse: honest technical comparison

[manankharwar]

fuse is a ROS sensor fusion framework from the Clearpath/Locus robotics ecosystem. It takes a different architectural approach than robot_localization or FusionCore. Here is an honest comparison.

---

What fuse is

fuse uses a factor graph formulation. Instead of a Kalman filter running a fixed state vector forward in time, fuse adds sensor measurements as factors to a graph and optimizes over a sliding window. It uses Google Ceres as the nonlinear least-squares solver.

The conceptual advantage: you can add or remove sensor types without modifying core filter code. Each sensor is a plugin that adds factors. The graph can optimize over past states when delayed measurements arrive.

---

Architecture comparison

	FusionCore	fuse	robot_localization
Filter type	UKF (sigma point)	Factor graph (Ceres optimizer)	EKF / UKF
State representation	Fixed 23-state vector	Variable, graph nodes	Fixed state vector
Sensor extensibility	Measurement functions	Factor plugins	Sensor flags
Delayed measurements	IMU ring buffer + retrodiction (up to 500 ms)	Natural (graph re-solves)	Timestamp at arrival
GPS handling	ECEF direct	Plugin-dependent	navsat_transform
CPU profile	Under 0.2 ms/cycle (i7, measured)	Higher (graph solve)	Low
Numerical guarantees	Chi2 gate + covariance bounding	Ceres convergence	None explicit

---

Where fuse wins

Sensor extensibility. Adding a new sensor type in fuse means writing a factor plugin. The core solver does not change. If you have an unusual sensor (visual odometry with full pose covariance, LiDAR scan matching, barometer) and want it integrated properly, fuse's plugin architecture handles this more cleanly than FusionCore's current measurement function approach.

Delayed measurement handling. fuse can marginalize over past states naturally. When a sensor arrives late, the graph re-optimizes with the new factor in the right place. FusionCore's IMU ring buffer retrodiction is an approximation to the same idea (and it works well in practice for GPS latency up to 500 ms), but fuse handles it more generally across arbitrary sensor types and delays.

Academic trajectory. The factor graph formulation is closer to how modern SLAM systems work. If you are integrating FusionCore into a larger SLAM pipeline, fuse's architecture aligns better with the broader graph-SLAM ecosystem.

---

Where FusionCore wins

Real-time determinism. A Kalman filter update is O(n^3) in state dimension but constant-time per cycle. A Ceres solve over a sliding window has variable cost depending on window size and factor count. For hard real-time at 100 Hz on embedded hardware, a UKF is more predictable.

GPS-specific hardening. FusionCore's chi2 gate, gnss.base_noise_xy noise floor, ECEF GPS fusion, and coast mode are built for the specific failure patterns GPS produces in outdoor robotics. fuse's GPS support is plugin-dependent and less opinionated. You would need to implement equivalent hardening yourself.

Zero-configuration bias estimation. Gyro bias, accel bias, and encoder WZ bias are filter states. They are estimated continuously from the incoming sensor stream. fuse does not have an equivalent built-in.

Benchmark validation. FusionCore has published ATE numbers on twelve full-length NCLT sequences (~940 min total) against RTK ground truth: 10 of 12 wins over robot_localization EKF, with improvements from 1.2x to 22.2x. The RL UKF diverges numerically on all twelve sequences. fuse does not have an equivalent public outdoor benchmark. Full results: benchmarks/README.md.

Simpler deployment for the common case. If you have IMU + wheel encoders + GPS, FusionCore's config is a single YAML with two numbers from your IMU datasheet. fuse configuration requires understanding the plugin system and assembling the factor graph manually.

---

When to choose each

Choose FusionCore if: IMU + encoders + GPS, outdoor robot, you want it working with minimal tuning, you need GPS robustness against covariance miscalibration and blackouts.

Choose fuse if: unusual sensor suite, you need natural late-sensor integration across many sensor types, you are building on top of an existing SLAM graph.

Choose robot_localization if: you are already deployed on it and it is working.

---

Questions about specific tradeoffs welcome.