Just wanted to put my two cents on this discussion:
Regarding ready-to-go SLAM modules for “typical cases”, such as 2D grid-mapping, 2D or 3D EKF-SLAM (yes, really, I know we’re in 2019!), ICP-based graph-SLAM, etc. with 3-BSD License, we’ve been maintaining for years the mrpt_slam packages based on MRPT. If someone else want to join the effort of being maintainer too, they could be ported to ROS2. I’m already too busy maintaining the MRPT upstream project to undertake the port from scratch to ROS2, to be honest MRPT packages are readily available in all Ubuntu distributions.
On a modular solution to SLAM, we proposed exactly that kind of solution in this paper in RSS2019. Source code is here, GNU GPL3, although only a fraction of what can be done is already developed (much work ahead!).
Being realistic and pragmatic, I think that option (1) would be a good choice in terms of ratio “effort investment / results” for the community to have something working in a reasonable time.
That multi robot example is really really cool. open_karto was written with that in mind but I never saw it being used and it wasn’t exposed by any of the ROS wrappers.
I’ve looked at various mrpt packages before but never ventured in, I guess I should change that. Out of curiosity is there any reason why the graph slam uses ICP rather than correlation based matching a.la Karto (and as far as I can tell Cartographer)?
As a matter of fact I know about MOLA and envision something similar for ROS2. One of my main grief against it is that it depends on MRPT (sorry ). I did not always had the smoothest experience with MRPT and using it in conjunction to ROS, it feels like a lot of things are duplicated (well it is a different fully grown robotics framework). I personally don’t think that it would be the best path here.
Nevertheless, congrats guyz on developing and sharing MRPT, that’s truly impressive!
Man, I’m super close to getting that to work. There’s one issue left in how the optimizer is structured (ahhhhhh) and it works on a branch I have. A little bit of cleanup for getting odometry measurements and its out the door. If anyone’s incentivized to get multi-robot mapping online, message me and we can collaborate. It’s 1 hard bug and about 3 small tasks away from working. I’ve shown it working when they don’t interact fine, but once their tracks come together, the optimizer just shuffles things around in a confusing way. Maybe I’m not anchoring the tracks correctly, maybe there’s something missing, maybe 'm indexing wrong.
@jlblancoc part of this too isnt just that it exists under BSD, but also that the primary maintainers are motivated for the long term to support it in ROS2. It doesn’t sound like you’re incentivized to port and maintain it for ROS2 for the long haul. If that changes though, we’d love to add it to our evaluation list Matt and I are gathering for the TSC.
Hi, I hope I can help here. Google won’t be supporting Cartographer again anytime soon, but we, Lyft, are planning to take over maintenance of Cartographer and are currently looking into how to make this happen. If this works out as expected, things will improve soon.
The activity in the point_cloud_viewer repo are my coworkers.
@Wolfgang_Hess - this is definitely interesting news. Did you see my post above about what type of support we’re looking for? Is that in line with your plans? Particularly, we’re looking for ROS2 support, is that in your plans or ROS only?
I haven’t set a call specifically for this, and probably can’t until after ROSCon. If we have interest, we could discuss in person at ROSCon. I know @smac and I will be there, don’t know about the rest.
I think a key question is whether @Wolfgang_Hess and Lyft will be supporting Cartographer in ROS2. If so, that’s great, and we may not have a problem using Cartographer going forward. But we need an answer on that before we know.
Along with @mkhansen’s comment: I’d prefer a quick call with @Wolfgang_Hess and @mkhansen to first understand the scope of their interest and intent before opening it up for a wider conversation.
It may be moot if there isn’t interest in ROS2 or interest in long term support. Unless @Aaron_Blasdel you’re separately suggesting interest in maintaining ROS2 Cartographer?
We’ll probably arrange a call or take over a Navigation WG meeting post-ROSCon. It sounds like there’s some substantial interest in at least knowing what’s going on (if not, also contributing?) so keeping everyone apprised and getting some feedback while we hammer out options is good.
Would also like to be on the call if there is one both from an interest in the problem and cartographer in general as well as from an interest in seeing where this ends up at with regards to ROS 2 (not coming to ROSCon but if there’s a meeting I’d appreciate being able to listen in).
Our lab at UCSD is also in search for a defacto SLAM stack with native ROS2 support, as we migrate. Perhaps it’s worth proposing a time for a birds of a feather session on the subject:
Count me in for a meetup at ROScon to discuss SLAM in ROS2! While the conversation above is a great start, I feel like the use cases and requirements could be better captured by a group discussion. E.g. 2D vs. 3D, lidar/camera, single/multi robot, loosely/tightly coupled, centralised/decentralised etc. etc.
@ruffsl the impression I’m getting is that if we can find someone interested in long-term maintenance of ROS2 Cartographer, that’s the direction folks want to go. With that said, since Google’s (seemingly) abandoned it for the foreseeable future and the codebase is how it is, I think this is a good entry point the way that gmapping was a good entry point in ROS1: it probably isn’t the best solution, but its here and its well documented. And for the “default” SLAM in ROS I think that’s OK, if folks want something different/better/niche, there are other “non-default” options available as we’re talking about above.
With that said, “impressions” aren’t worth much and we really need to look at this more analytically or at least perform a proper trade study that we can publish along side our decision to justify it. If folks really do care about picking something different/better/niche that should be reflected.
Towards less “impressions” arguments: I can say both from my experience and the experiences of plenty of other robotics professionals in industry ranging from Warehousing (4x), Retail (2x), and libraries (yes, libraries 1x) we all have the same qualms with Cartographer. After dumping independently lots of resources into it, it came out as a non-decision of building a product around. But most people aren’t doing that and even in ROS1 GMapping was sufficient for the vast majority of users. I think the second most important question in making a decision (after is there a long-term maintainer) is who we’re targeting this for and why. That very much so changes what the best “default” should be.
@rgreid I think for now if you have thoughts, you should express them here so they’re documented and we can digest & continue a dialog. This isn’t a decision we’re going to be able to make in a 30 minute lunch break even with everyone together . I wouldn’t go too much into the weeds of loose/tight since that’s not really the point, but if you have tangible implementations you can recommend that are “industrial grade” we’re all ears to hear about all the options on the table. At the moment we’re only considering lidar slam, but we’re not opposed to a vision (or a visual component with lidar slam) assuming it is actually robust and comes with an additionally robust localization method over the long haul. If you can provide me an example of one, I’ll throw away all my lidars and happily join the vision camp .
Yes, I read this and I cannot give you a good answer yet. I’m still in the process of figuring out how best to move ahead. Regarding Cartographer itself, yes, this is the plan.
For the existing ROS wrapper and development of a ROS2 wrapper, we could for sure help out with code reviews etc, but would depend on contributions from others, since we’re not using Cartographer with ROS(2) at Lyft. So if others are interested in helping with maintaining a ROS(2) wrapper that would definitely be appreciated.
). I did not always had the smoothest experience with MRPT and using it in conjunction to ROS, it feels like a lot of things are duplicated (well it is a different fully grown robotics framework). I personally don’t think that it would be the best path here.
.