Evaluate Fuse as a RL replacement & consider other alternatives

[SteveMacenski]

There's not necessarily a reason to remove RL as our defacto-standard sensor fusion system for odometry / GPS, but it is worth considering a change with ROS 2 and the fact that the maintainers (@ayrton04 and I) no longer directly use it ourselves.

There have been a few ROS-based options proposed, including Fuse. If this doesn't make sense, consider others that may or building/adopting a new one within Nav2 (potentially based on another project).

CC @DLu

[ayrton04]

I think fuse would be an excellent candidate for the standard sensor fusion system going forward. We'll need to add a GPS sensor to it, but once the community understands how to add sensors (this will be covered in the ROS World talk), that might not be too challenging.

[soldierofhell]

Nothing against fuse, but I'd vote for gtsam. There're many great localization framework build with gtsam, in particular VIO and LIO. But you can also build simple imu + gps in python (https://github.com/PaulKemppi/gtsam_fusion).

Regards,

[ayrton04]

I know very little about gtsam, but I will only note that the author of fuse, Stephen Williams, was also involved in the development of gtsam. But in the end, we should do whatever provides the most value for the community.

[Timple]

From the readme of gtsam_fusion:

The pose estimation is done in IMU frame and IMU messages are always required as one of the input.

That seems rather restrictive? And not in line with REP-105 which indicates base_link is the robot position.

[soldierofhell]

I've pointed gtsam_fusion code as an example of simple localization with python api. There're other projects like https://github.com/ilnehc/gtsam_ros, as well as tons of visual/lidar odometry/slam, just to mention rtabmap, kimera, lio-sam and others and of course gtsam own examples. There's no one implementation that handles all sensors and use-cases, but a lot of examples (including code) how to use it (with ROS/ROS2). I think if the goal is just to handle standard "turtlebot" setup like imu, odometry and gps then maybe it's not worth to use gtsam, but if we want framework that can handle visual/lidar odometry (internally), april tags, landmarks and other fancy stuff with map generation, smooth gps/non-gps transition, gtsam is great choice.

[soldierofhell]

This was mentioned on nav2 slack, so I'm adding it to list: WOLF: A modular estimation framework for robotics based on factor graphs . Surprisingly, factor graphs not in gtsam :)

[jeremysalwen]

How does WOLF compare to Fuse? I asked the WOLF developers but as they are not familiar with Fuse, I wasn't able to get a straightfoward answer. The main thing seems to be that WOLF keeps an explicit representation of the different modules that are active which you can introspect, called the WOLF tree. From a technical perspective about what sorts of functionality it supports I couldn't tell much.