FusionCore, which is a ROS 2 Jazzy sensor fusion package (robot_localization replacement)

ROS ROS General
1

Hey everyone,
I’ve been working on FusionCore for the last few months… it’s a ROS 2 Jazzy sensor fusion package that aims to bridge the gap left by the deprecation of robot_localization.

There wasn’t anything user-friendly available for ROS 2 Jazzy. It merges IMU, wheel encoders, and GPS/GNSS into a single, reliable position estimate at 100Hz. No need for manual covariance matrices…. just one YAML config file.

  • It uses an Unscented Kalman Filter (UKF) with a complete 3D state…. and it’s not just a port of robot_localization.
  • It features native GNSS fusion in ECEF coordinates, so you won’t run into UTM zone issues.
  • It supports dual antenna heading right out of the box….
  • It automatically estimates IMU gyroscope and accelerometer bias.
  • It includes HDOP/VDOP quality-aware noise scaling, which means bad GPS fixes are automatically down-weighted.
  • It’s under the Apache 2.0 license, making it commercially safe.
  • And it’s built natively for ROS 2 Jazzy….. not just a port.

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

image
image892×618 38.7 KB

I respond to issues within 24 hours. If you’re working on a wheeled robot with GPS on ROS 2 Jazzy and hit problems….. open an issue or reply here.

2 Likes
2

Thanks for the package! I really like the simplicity and cleanliness of the design.

However, it seems to be too simple so far in several areas:

  • IMUs rarely come in base_link frame. You should use imu_transformer.
  • GNSS also rarely comes in base_link. This is, however, a much harder problem, because if the antenna is offset from the axis of the robot, its readings are for a point that follows different trajectory than base_link. This problem itself adds a few 100s lines to robot_localization, yet it is a very important one to resolve (and no, please, do not take inspiration from r_l which just saves the very first heading as an offset). Until you’re sure with the heading of the robot, fusing off-center GNSS is not good.
  • Why do you ignore covariances in the messages? Some sensors/algorithms actually put useful values there… Most importantly GNSS has often off-diagonal elements that are quite important (and DOPs are only very lightly related to the quality of localization). Or a wheel-slip estimating odometry.
  • But I agree if a sensor publishes bogus covariance, it is nice to have an easy way to override it.
  • Some IMUs provide very good orientation estimates. Why not use them?
  • What about using multiple sources of each type?

Out of which box? I don’t see anything heading-related in the ROS node (only code in the core, but no ROS interface).

If you’re also missing a message to represent the heading, please consider using compass/compass_msgs/msg/Azimuth.msg at master · ctu-vras/compass · GitHub . One day, I’d like to standardize it. The more users it has, the more feedback I have and the better the standard will be.