artivis
commented
5 years ago I essentially agree with @SteveMacenski and, in the given context, vote for SLAM Toolbox because it is karto ('it just works') with goodies.
My only remark is that I wouldn't 'officially' provide/support 2 SLAM implementations for the reason that it pledges ROS 2 (maintainers, community etc) in to a lot of efforts. We better support one, do it well, and advertise other packages has 'community-provided' options. My concern is to avoid the ROS 1 situation where both karto and gmapping were somewhat the 'official' SLAM solutions but neither was fully working nor (at some point) properly maintained. I also think that it might be confusing for new comers following tutorials and the main recommendations. They are not looking for options to tweak and compare but rather something 'that just maps'.
To summarize, my remark is about duplicate efforts and (mis)communication.
SteveMacenski
mkhansenbot
adamdbrw
JaccovdS
eupedrosa
doisyg
Per some discussions with the TSC, we're moving this discussion into Navigation.
We need to come up with a default option that's well supported for ROS2. From the discourse thread and additional conversations at ROSCon, I propose the following as the 3 major options
Each of these has their pros and cons.
Cartographer: Apache 2, Lots of community traction, though very hard to setup or modify. Google has largely stopped working on it but some companies have really taken ahold of it. I'd argue that it isnt suitable for most (not all, not for everyone) industrial applications based on my experiences and discussions with a number of other companies. Works with 2D and 3D lidars, localization, and limited serialization. Lives in the Cartographer organization, but the temporary ROS2 fork in OSRF's organization, but not interested in maintaining it long term. To my knowledge, there are no excited maintainers for ROS2.
SLAM Toolbox: Currently available under LGPL 2.1, it builds on top of the open karto library with additional optimizations and includes things like full serialization, localization, continue mapping, and works well for large / dynamic spaces. I would be a maintainer and welcome others who would be serious about it to join as well. Lives in my personal github account. There may be some opportunity to relicense to something more permissive but to get that process started it has to be basically already chosen as the primary option so that shouldn't be assumed to happen for your decision making process.
LaMa: BSD3, New SLAM based on distance function "attraction" as the author calls it. No ROS2 branch but we could make one without too much trouble. It runs much lower overhead than the other 2 options above, but I don't believe at this moment that anyone has tested how it would scale or do in large scale environments. There's a question around how well it works in changing environments or with the probabilistic grid generation. These problems don't seem unsolvable but are current things needing to be looked at. Lives in the IRIS LAMA github organization, the author would be willing to maintain and I would also probably take part. On a personal note, I've found it works well for some datasets I have but breaks down for others and I'm trying to figure out how or why.
My proposition: I think we provide/support 2 SLAM implementations. I think those 2 should be SLAM Toolbox & LaMa. There would need to be a few people with interest in testing, fixing if necessary, and porting LaMa to ROS2. Right now its a really new (and interesting) option but we need to know more about how it works in many varying environments. I would argue that if everything works out, this becomes the sole default SLAM option in a couple years' time if we work out the kinks and no massive red flags are raised.
Cartographer seems abandoned and I think it would be a mistake to keep it alive when Google itself doesn't seem interested in using it. Moreover there is no one standing up with incentives to maintain or continue developing on it.
CC @mkhansen-intel @mikeferguson @ablasdel