Concerns regarding robot_localization deprecation

In a recent post, while soliciting community feedback for GPS in Fuse, @smac announced

It is the expressed interest of myself and @automatom to start the process of sunsetting Robot Localization in favor of Fuse as the standard state estimation and fusion package in the ROS ecosystem.

I wanted to create a thread where we could discuss this transition in general, without derailing the previous GPS-focused discussion.

I’ll start: So, I’ve admittedly never used Fuse before, but in looking at the source code to investigate such a transition, I notice (as have others) that all the models have the prefix “_2d”. Should we expect full 3D support by the time such a transition takes place, since ROS is not strictly an ecosystem for 2D robots? It looks like there has already been some 3rd party work along these lines, but no PR yet.

3 Likes

Thanks for the new thread.

Yes, the plan is to depreciate R_L. In many ways, it already is since neither Tom (@automatom) nor I want to continue to maintain it. It was and continues to be a fantastic package, but the state of the art has moved forward and R_L’s age is really starting to show. Alot of things that we “could” do to improve it likely never will because Tom’s organization now uses Fuse as a replacement and I frankly have no interest in putting more time into something that there’s momentum in the community to move away from.

There’s a real question to be asked “Why Fuse?” over others, but I can answer it from my perspective:

One of the core requirements I want to see before I inject a new dependency on the ROS 2 mobile robotics community or Nav2 userbase is maturity and product-readiness. We’re only as good as our weakest link. Fuse is being used by Locus Robotics for some time now on their fleet of thousands of robots worldwide. As far as any technology can achieve the “its ready” mark, its long since passed that.

Another is that its built on a framework for expansion for new applications, which Fuse has in spades with that intention in mind. I’ll admit just the basics of Fuse I questioned for some time why not just use Ceres directly since I had some experience with it from building SLAM Toolbox. However, I’ve come more towards the useful abstractions line of thinking. Its awesome that you can set this all up in config files with no-coding (as long as you’re using standard nav_msgs/sensor_msgs/etc).

To your comment on 2D applications → I believe you’re correct. It really is right now mainly focused on 2D constraints in planar environments. But all the types that are taken in use 3D pose and orientation representations, so its not a massive effort to add that third dimension in. The fact that this is a framework that can add new constraints like this relatively easily is a big selling point to me. This is work that would likely need to be done by someone with the interests in 3D, but we’ve already started running into those folks when we’ve been talking about GPS! I can’t promise for Polymath Robotics that they’re going to implement every single 3D model you could want, but they’ll end up doing some of the basics (e.g. Pose, Orientation) which are the basis of the remaining that should be not terribly difficult.

As to whom will do that work, that’s not well defined at this moment, but there’s far more interest and value in adding the 3D constraints to Fuse than fixing half the tickets in R_L. I’m not personally committing to doing it, but it might be a result that I do it as part of the migration.

The last big thing I look for is support: does the organization that built it actually use it and plan to continue to use it long term. I can’t put words in Locus’ mouth, but it seems that’s a Yes. Tom, Stephen, and Co. are the only ones that can answer that definitely. That’s not the same thing as corporate support (e.g. you can pay CompanyA to fix a bug or help configure your system) which Locus won’t support – but hey nor will GTSAM. I also just started this thing called Open Navigation, ya hear? Maybe that’s a role we can help fill since its definitely in the ROS 2 mobile robotics orbit and won’t be the first time I’ve played with Ceres :smile:

So, we hit all three categories in my mind satisfactorily: Maturity, Expansion, and Support.


A separate topic might be “What about the alternatives” to which my answer would be, honestly, Stephen Williams is in a much better position to be making that argument, so I’ll defer to him and the links (that I can’t find at the moment) where he explains his thinking. I know Stephen and the team at Locus well; they’re smart folks; if he chose to rebuild something from scratch instead of using software he was deeply familiar with, I think that’s illustrative in it of itself.

I’m not taking a side as much as looking to build consensus so we can all move forward together with a solution that is maintainable, mature, and sustainable. Those elements are more important to me than having the absolute bleeding edge of research – if that bleeding-edge solution means that it can’t be easily expanded upon, used by the majority of non-expert PhD-level roboticists, and is only of marginal practical additional benefit. Plus, if its integrated as the “default” for Nav2, I’ll probably have to take some minor role in it, so those attributes are pretty important from my perspective as an open-source maintainer :wink:

Edit: This last remark aren’t accusations about GTSAM, just general points. I care about the tech as much as the next guy, but its one axis on a multi-axis analysis that we should make sure to consider.

1 Like

Just throwing the idea out there that a fuse to robot_localization equivalent of this migration doc would be really nice:
http://docs.ros.org/en/kinetic/api/robot_localization/html/migrating_from_robot_pose_ekf.html

I didn’t find one yet but if one already exists, someone please lmk. :smile:

I am sure I’m not the only person interested in trying fuse but hesitant to do so because of the time involved in translating my working robot localization config into a fuse equivalent, especially with no prior knowledge of fuse. The library looks promising though so I’m excited to try it when I have the time

Also a bit uncertain if the “unicycle2d” motion model supports holonomic 2d robots. And I couldn’t find info on this.

1 Like

Yes, the plan is to depreciate R_L. In many ways, it already is since neither Tom (@automatom) nor I want to continue to maintain it. It was and continues to be a fantastic package, but the state of the art has moved forward and R_L’s age is really starting to show.

There is also nothing really preventing an up-start community member from taking over maintainership or forking robot_localization to continue to provide that avenue. I would take a look at the past and existing issues and think pretty deeply before committing to that, though.

I know this isn’t the full nature of the ask @jjdang, but this tutorial for setting up Fuse with Odom and IMU is a good example analog to the ekf.yaml and ukf.yaml in robot_localization for basic mobile robotics odometry sensor fusion.

As previously mentioned, there will be growing pains to get all of the features required – it looks like an Omni model is one of those. I took a ~5 minute walking tour through the Unicycle model and nothing in there looks terribly complex beyond understanding precisely how the pipeline works. Creating an Omni should be straight forward. Less than a day even coming in cold I suspect.

No matter what technology we choose, there’s going to be a list of action items, so please keep them coming! So far I’m hearing (1) 3D eq. of all models (2) Omni motion model, (3) I’ll throw in ackermann model just to round it off, (4) accepts GPS messages in some format for fusion

Any others? :slight_smile:

1 Like

Instead of Ackermann I’d use the more generic bicycle model. Just like the unicycle model represents a diff-drive.

I don’t have much to add here, but I will note that we have fuse documented (for ROS 1, at least) here. I’d specifically draw your attention to this “getting started” tutorial. Most of the parameters are pretty similar to those in r_l, or should be pretty straightforward to understand.

As far as r_l goes, I no longer work for Charles River Analytics, so I’m not sure how it will play if I add more external collaborators to the repo so as to hand if off. While forking is definitely an option, I think as a community, our time and effort would be better spent getting behind fuse and adding the features we want to see. Adding new sensor and motion models is really not complicated. If I can get some cycles, I’ll try to make a point to help get the base set of 3D models in place.

Also, I should note that while I am not going to be actively developing r_l or even fixing bugs at this point, the package is stable and isn’t going anywhere. It builds and functions in ROS 2, and I don’t think we should remove it from rosdistro. So from my perspective, I don’t know that there’s any urgency to move to fuse for users who don’t have the time to do so.

1 Like

Also, I should note that while I am not going to be actively developing r_l or even fixing bugs at this point, the package is stable and isn’t going anywhere. It builds and functions in ROS 2, and I don’t think we should remove it from rosdistro. So from my perspective, I don’t know that there’s any urgency to move to fuse for users who don’t have the time to do so.

Thanks @automatom . The reason for my original question is that I’m at the point of starting a new project that requires 3D localization (underwater), and didn’t want to start with something already being deprecated.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.