FusionCore vs robot_localization: when to use each

[manankharwar]

People ask this regularly, so here is a direct answer.

---

Use FusionCore if

Your GPS covariance is wrong. NCLT reports var_xy = 9 (3m sigma) but the actual noise on three sequences is far worse. robot_localization EKF trusts that covariance directly through navsat_transform. It rejects fixes that exceed the reported sigma as outliers, and loses GPS for long stretches. FusionCore sets a gnss.base_noise_xy floor that matches real sensor behavior. Same chi2 gate, calibrated statistics, fixes accepted.

You are near a UTM zone boundary. robot_localization projects GPS through UTM, which has a hard discontinuity at zone edges. This crashes navsat_transform in production (#951, #904). FusionCore fuses GPS directly in ECEF. No projection, no zone boundary, no crash.

You care about delayed GPS. GPS messages arriving 50-200 ms late are common. robot_localization processes them at arrival time (#911). FusionCore maintains a 1-second IMU ring buffer, reconstructs the state at the GPS timestamp, and replays forward. Same bag, same config, deterministic output.

You need reproducible results. robot_localization output varies across bag replays under use_sim_time:true (#957). FusionCore is driven entirely by message timestamps. Same bag plus same config equals identical output.

You run a wheeled robot. The non-holonomic constraint (lateral velocity = 0, vertical velocity = 0) is a built-in virtual measurement applied on every encoder update. robot_localization has no equivalent (#744).

You need numerical stability with UKF. robot_localization UKF diverges with NaN on GPS-heavy sequences (#780, #777). All nine NCLT sequences ran to completion without NaN with FusionCore.

---

Use robot_localization if

You are already deployed on it and GPS quality is good. If it is working and GPS covariance is accurate, switching has no upside. robot_localization EKF won two of nine NCLT sequences. The two FusionCore losses are specific failure modes: adversarial GPS outliers at blackout boundaries and accumulated heading drift during a 461-second GPS blackout. If your operating environment does not produce those patterns, RL-EKF is fine.

You have an unusual sensor configuration FusionCore does not support yet. robot_localization is more flexible on sensor input geometry. FusionCore is opinionated: IMU + wheel encoders + GPS. If your setup is something else, check the roadmap or open an issue.

You need a large existing community. robot_localization has years of Stack Overflow answers, forum posts, and tutorials. FusionCore is newer. If you hit something unusual, the debugging surface area is larger with RL.

---

Benchmark summary

Nine full-length NCLT sequences, same config, no per-sequence tuning:

Sequence	Season	FC ATE	RL-EKF ATE	Winner
2012-01-08	Winter	18.6 m	41.2 m	FC +55%
2012-02-04	Winter	49.7 m	265.5 m	FC +81%
2012-03-31	Spring	22.0 m	156.5 m	FC +86%
2012-05-11	Spring	9.7 m	11.5 m	FC +16%
2012-06-15	Summer	49.2 m	18.2 m	RL +63%
2012-08-20	Summer	98.3 m	10.6 m	RL +89%
2012-09-28	Fall	10.8 m	55.7 m	FC +81%
2012-10-28	Fall	29.9 m	60.0 m	FC +50%
2012-11-04	Fall	60.1 m	122.0 m	FC +51%

RL-UKF: NaN divergence on all nine sequences.

The two FC losses have documented root causes. See the linked issues for full analysis.

---

Migration

If you are coming from robot_localization, the migration guide covers the config translation line by line: manankharwar.github.io/fusioncore/migration_from_robot_localization

Questions welcome here.