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.
As for `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
1. The ROS2 source for `r_l` lives in the `ros2` branch of the `r_l` repo:
https://github.com/cra-ros-pkg/robot_localization/tree/ros2
2. 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](
https://github.com/cra-ros-pkg/robot_localization/issues/265) 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.
---
[Visit Topic](
https://discourse.ros.org/t/robot-localization-porting-to-ros2/6379/2) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)