So we had hoped to cross this bridge at ROSCon, but luck wasn’t with us on the Lightning Talk random selection.
Here’s the state of…state estimation on ROS2, at least from my (and Locus Robotics’) view.
r_l is a decent generic EKF implementation, but it has some serious drawbacks, namely
- It doesn’t handle bias estimation for IMU data
- It uses a generic 3D omnidirectional kinematic model that isn’t appropriate for all robots
- It’s hard to extend
- It needs some serious refactoring
So my colleague at Locus, Stephen Williams, decided to write a new state estimation package for ROS1 and ROS2, which we are calling
fuse. Fuse addresses literally all of the shortcomings of
r_l (or will). The core
fuse package is available now, but the core package lacks the ability to actually take in ROS sensor data. To that end, I am working on a
fuse_rl package that will replicate all of the behavior of
r_l, but in the
fuse framework. I may even put together a configuration file converter.
fuse_rl will contain, among other things, an explicit 2D kinematic model that is appropriate for differential drive robots, as that appears to be the most common use case for the current package. All of the other functionality will remain intact.
But this post is about ROS2. We don’t yet support ROS2 on
fuse, but we are actively working on the problem, as time permits.
r_l, I did put some time in to get it to build on ROS2, but I had some trouble with the ROS1 bridge and
r_l's custom service definitions. We’re not actively using ROS2 yet, and my free time these days is extremely limited, so I was forced to shelve my efforts for now (I admittedly didn’t put a lot of time into this).
Anyway, this is a very long-winded way of saying that I welcome community involvement in a ROS2 port of
r_l, but I expect support to be limited, especially once
fuse is released for ROS2. It’s a much more flexible and far better written package, and I think it’ll serve the community well. Having said that, I don’t have a firm timeline on when it will be available, so getting
r_l properly working in ROS2 is a worthwhile exercise.
In any case, the answers to your questions are
The ROS2 source for
r_l lives in the
ros2 branch of the
r_l test suite comprises bagged data from real and simulated robots. It should be sufficient to verify functionality.
Finally, if you look at the ROS2 migration ticket for
r_l, you’ll see that @mkhansen has created a ticket to verify the ROS2 functionality of
r_l. I only point this out to ensure that we don’t duplicate efforts unnecessarily.