Our Nav2 WG has been using a ROS2 ported fork of cartographer_ros for doing SLAM.
@clalancette has been kindly keeping this updated but it is forked from the upstream cartographer_ros project, which doesn’t have a ros2 branch. My previous attempt to broach the subject there was this issue which basically boomeranged back to me to create an RFC and take it to the google cartographer Open House, which hasn’t met in 7 months, in order to get it approved and a ROS2 branch created. This is obviously a hassle, but I’d be potentially willing to do it, except it doesn’t look like that meeting is happening anymore and I’m not even sure that repo is being maintained anymore, based on the last commit having been back in May.
If anyone knows what is going on with cartographer and whether it is still being supported / maintained, I’d love to hear that.
BUT, based on what I’m seeing, I believe we need a well-supported, maintained SLAM for ROS2, and I’m opening the discussion here for suggestions as to who and what that should be going forward.
Is this meant to be just 2D SLAM or also 3D? Also does it make sense to simply fork Cartographer and maintain it separately until (if) we see any more activity from the original project (though like, it’s a Google project so there’s every reason to believe that it’s just dead now). What about Karto?
I’d also like to shamelessly plug one of my projects as a possible contender. I’ve been working on what is essentially a rewrite of open_karto but built to be “python first” and more flexible (e.g. supply scan matching for a new kind of sensor and the SLAM would come for free). It’s also faster than Karto based on what I’ve seen and the ultimate goal is to unlock life long mapping. It’s almost ready for primetime (just finished the ROS 1 node). I’m committed to working on it and maintaining for at least a few more years and I’ve deliberately kept the code as simple as possible. I believe I can explain the code fully to another engineer in a single afternoon (in fact I did that for a colleague just a few days ago). This should help with maintainability. If there’s interest I can accelerate work on a ROS 2 wrapper.
From the weekly, I finally (one armed, no less motorcycles are dangerous, don’t get one) ported slam toolbox to ROS2. You’ll get mapping, localization, and lifelong mapping capabilities in complete if I did everything right. The only non-ported items are related to the rviz plugin and interactive markers which I have tickets open in the appropriate repos.
Building in build farm as we speak and should be installable in the next dashing sync. I’m not sure if anyone at Intel has the cycles to play with it, but expect a similar level of support for this project as I give navigation2.
I think that’s both incredibly reasonable and unrealistic for the moment. Different options meet different bullets. I’d say my work meets the bullets of that that are most important: efficient, documented, debians, and open (sure, not apache, but I make no terms against commercial use, just to give back, which I find very rational given the time organizations I’ve been in have dumped into it). Gmapping if ported would be 4 of those. Karto 3.
Karto nor gmapping provided PR testing or have really been maintained at all in the last 5 years. Gmapping for the majority of its life was non-commercial and Karto is GPL. The only example I could give that had all that is cartographer@ros1. I would like very much so to have gmapping die in ROS1, its really past its prime by really any other available option.
Do you see another non-cartographer example in ROS1 that provided those that we could look to port? These are important points but tempering with past projects is useful.
@smac - I’m not excluding your slam toolbox as the potential right solution, just trying to clarify what I think requirements are. I’m sure others have their opinions as to what is needed, I’m trying to get some of those as input too.
I don’t know of any other non-cartographer example in ROS1 that meets all the criteria I listed, which is partly why I started this thread. I’d really like to see someone in the community or TSC step up and volunteer to take ownership. It seems like there are quite a few SLAM implementations out there but they’re generally released as part of a conference or academic paper, maintained for a little while, then abandoned. This is the problem I see that I’d like to see solved for ROS2.
@ruffsl - thanks for the info on the point cloud repo. I still have my concerns however, until I hear some commitment from the maintainers themselves.
When @clalancette I discussed this earlier, I think we came to the conclusion:
cartographer itself is completely independant from ROS/ROS 2, so the upstream source should be valid for both.
cartographer_ros needs (and currently has) a port for ROS 2, but the ideal scenario would be to get it upstream into a ros2 branch or as part of a unified repo (a single repo that could build for ROS/ROS2).
I believe that we left off with wanting to propose this to the cartographer developers, but as you said, there hasn’t been much traction there.
You are correct, and it could be. I think ideally it would be maintained in the same place that the ros wrapper is maintained, so that improvements can be ported across the versions. That saves a bit of effort in shuttling things back and forth across forks.
Another thread mentioned that the OSRF ros2 port doesn’t contain recent changes which the cartographer folks say make substantial improvements. I think Matt’s goal is to have it committed to and maintained by Google so OR isn’t constantly chasing changes in Cartographer/ros1 wrapper that they (probably?) don’t have time or long term resources to do if we can get Google to do it.
@mkhansen my goal with that comment wasn’t to push ST as much as point out that our options with that check list are very limited and we might want to temper expectations from looking at history unless there’s someone standing up saying they’ll do the work & maintain under a ROS org long term. With that list of requirements, I see 2 most reasonable options: we reapproach Google folks again on ROS2 and re-explain the importance or we port Gmapping and write the testing infrastructure ourselves. With that said, the last substantive change to gmapping was years ago so I’m not entirely sure the automated testing pipeline is totally necessary with the small cadence of changes.
I’d prefer option 1 since I really hoped to leave gmapping behind. Then there are 3rd party options like what Jari and I have presented amongst others, I can create an overview of the other ones I know about that are more or less equivalent (REP105 frames + lidar) but I wouldn’t place much hope there will be a long term support plan as many are as you mentioned for a paper and widely untouched afterwards. Something used by companies in production is more attractive to me since there’s a group that has invested interest in it working, which at minimum Jari and I’s would have.
To add to this: having used gmapping, and then Karto and Slam Toolbox in production I’m 100% with @smac on letting gmapping die with ROS 1. Karto and Slam Toolbox work infinitely better and are more lightweight*.
*And the more I look into Cartographer the more I’m convinced the original framework presented by Karto is much more straight forward (trying to follow code paths in Cartographer make my head spin) and seemingly just as flexible as the one present in Cartographer. I feel like this matters for maintainability even if the original maintainers drop off.
Couldn’t agree more. I’ve found reading the standard template library to be easier than that. SLAM Toolbox has 50% less code in entirety than Cartographers ROS wrapper. Reading their paper I’m in love with their ideas but I can’t match that up to the actual code that exists. Not to say our stuff is trivial to understand, but its at least readable and well commented.
Edit: sorry this is here nor there. I think Cartographer is a reasonable option regardless. I’d just like to narrow down to finite options and discuss what’s the best direction amongst them to move forward with. I think there will be some compromises any way we go- but step 1 is what are the options. So far I’m hearing: cartographer, karto, gmapping, slam toolbox, and yag
I’m surprised that nobody suggested the idea of starting a ROS2 SLAM effort from scratch. Therefore let me do so.
My SLAM experience is mostly ROS1 based and over the years I got to ‘play’ with many - if not most - of the SLAM frameworks out there. During that time I always had a feeling of frustration because (choose any, non exhaustive) the framework …
… feels outdated, be it the code and/or the actual algorithm
… has no flexibility, extending it essentially means re-writing a substantial portion of it
… has little to no modularity. SLAM is a set of algorithms put together, but often there are no easy way to only change a chunk of it
… does not have a somewhat standardized API that would make comparison easier
… is too task specific, 2D-only/vision-only etc.
… is a pain to set up (I’m not pointing a finger at cartographer)
I believe all these cons already somewhat make the case for developing a ROS2 SLAM framework.
Notice that I am not suggesting to re-implement karto, or cartographer, or ORB-SLAM but a framework organizing the data-flow much like navigation2 with defined API, base classes and tooling. Such framework would be fully ROS2 based and emphasize modularity and flexibility. As for the initial demo, a simple 2D pose-graph (karto-like) could be implemented.
I do realize this is a substantial effort, likely one for a dedicated WG, thus I’m only mentioning the idea to see the interest and feedback it gathers.
Post post edit: I fear we may be leaving the domain of the original discussion.
I can’t comment on if it would be beneficial to set up SLAM similar to the nav stack but all the reasons you mention are the reasons I wrote my own SLAM package (or rather, rewrote most of Karto, second shameless plug). Most SLAM/VIO/VSLAM/LOAM implementations seem to ultimately come down to
Do some form of odom correction or odom calculation, compute uncertainty
Build graph that encodes uncertainty
Look for loops
Optimize graph given some condition
So, yeah. If those 4 pieces are sufficiently abstracted the choice of hardware should be meaningless as long as folks can supply 1 and 3, I think (I’m not very good at this stuff so maybe there’s nuance I’m missing).
Agreed, I think in concept its totally possible. I’ve spent some time thinking about that for about a year but never had really the motivation or resources to “do it right” so I haven’t even started.
Would that be awesome? Yes, absolutely, and I’d love to be part of it as its happening, but for the more immediate need of a ROS2 reliable SLAM solution that’s going to be looked after, we should steer back towards that. A modular-SLAM metapackage would be at least a 6-12 month undertaking.
Post post edit: I fear we may be leaving the domain of the original discussion.
As per the fairly open title of this thread, I don’t think we are. But I’d be happy to start a new thread if people prefer to.
@safijari has essentially summarized the 4 ‘modules’ of any regular SLAM out there (others include graph-sparsification, planning and whatnot). This would be one of the layer of abstraction. Others can be devised, especially from the implementation perspective.
@smac, glad to see that you would like to be part of such project! I have been thinking about it for a while too and I think that ROS2 now offers pretty much all the basic pieces to build an awesome framework on top, action/srv, components etc.
I agree this would be more of a mid to long-term project and does not respond to the immediate need for a mapping solution in ROS2. But you know, the earlier we talk about it …
This also assumes graph slam remains the flavor of the day, which I think will be true for awhile, but has to be extendable beyond it as well if we want it to be useful into the general future. Probably have a PF unit and plugins for deep learning units while making sure that its super performant with all that generalization.
Mapping is one of the robot tasks I think new flavors of deep learning could eventually outshine our meaty human brains in, especially since its a non-safety critical task there’s alot of leeway it can be given
My current assumption is indeed that such framework would rely on graph-based SLAM as it is currently the de-facto standard formulation. However since the framework would essentially organise data and its production, the solving aspect is therefore just another module, possibly one that allows for different formulation. But this aspect of the modularity is not quite clear to me yet.
I do agree with you that machine learning is growing in SLAM. My view is that it ‘only’ going to be a particular implementation of a particular task (e.g. feature detection/extraction, place-recognition, odometry etc…) rather than a larger (partially) end-to-end thing. In this context I’m not worried about fitting those algorithms.
IG, I agree with you when it comes to general perception tasks as it relates to industrial resource constrained non-cloud server robotics. IG, I agree that most slam implementations that use deep learning use it as a feature extractor or for one of the specific tasks. IG, I think its hard for even something like an RNN or similar to have the memory to accurately accumulate data as to remove structure emposed by a graph or tree.
But I’m seeing work that is slowly changing that. I think there’s going to be some structural elements to aid a DL approach, but I think we’ll be seeing effective methods that aren’t structured so rigidly as graphs in the near term future.
motorcycles are dangerous, don’t get one) ported slam toolbox to ROS2. You’ll get mapping, localization, and lifelong mapping capabilities in complete if I did everything right. The only non-ported items are related to the rviz plugin and interactive markers which I have tickets open in the appropriate repos.