We still need some time to figure that out, so I cannot give you a good answer, sorry. Whatever the outcome, I think it is definitely a good idea to see whether others are interested in contributing to the ROS(2) interface packages. I would be surprised if we could not at least help a bit, but I just do not want to promise you more than we can realistically provide.
I think others are interested in contributing, but what we really need is someone to own maintaining it, including updating it for each ROS2 release and releasing it to the build farm. It’s not glorious work unfortunately.
I should also add, it might be possible to add 3-4 of us like me, @smac, @clalancette and one other as maintainers of the cartographer_ros package. We could potentially keep it updated / released to the ROS distros. However, someone like you / Lyft would need to keep it updated if you change the APIs on the cartographer side.
A co-maintainer option like that might work.
1 Like
I used Cartographer. It is really difficult to set up. I still could not completely solve this problem https://github.com/googlecartographer/cartographer_ros/issues/1368. In some rooms, it throttling NUC and freezes. It seems to me that initially the Cartographer was not designed for robots, so the code is poorly optimized for robots. What do you think of it?
Why are there still no normal visual SLAM wrappers for ROS? I experimented with ORB2, but I would like to have a standard solution for visual SLAM, in which the gridmap is built and for a wheeled robot the map does not go up or down.
I am interested in the topic of SLAM for ROS1 and ROS2. I would like to take part in an informal meeting at ROSCON.
You’d have to define “normal wrapper” for us. There exists wrappers for visual SLAM implementations in ROS, but in concept wrapping into ROS shouldn’t be too hard if you start with an otherwise good solution.
Most visual SLAM implementations focus on feature maps and not dense reconstructions. There exist plenty of visual-stereo that will do reconstruction, that you could project into a grid map, but that’s not always the goal. I’d also challenge you on why you need the grid map- the point of SLAM/localization is positioning. You don’t necessarily require a grid map for anything in particular in navigation.
If you have any suggestions of robust visual slam that meets your requirements and the thing missing is a good ROS(2) wrapper, let us know and add to the trade study.
Unfortunately I’m at my limit of formal time commitments at ROSCon and I can’t commit to moderating a SLAM discussion separately from the ros-perception birds of a feather discussion. But this conversation will primarily focus on the image and pointcloud processing tools in ROS2 & if time left, SLAM.
orb2 gives a curved map, even if you are driving along an long corridor. The robot rises in an arc downward or upward in the odom topic along the z axis, but in reality it was driving directly on a flat floor. Assigning z = 0 will not be correct, since the angle of the normal to the floor has also changed. I hope I clearly explained. The question is how to get a flat odom for the gridmap from this, or to use it, for example, in gmapping as odom.
Are we interested in getting that ROScon meet up to happen we discussed to happen. @smac @Wolfgang_Hess @mkhansen
Maybe during lunch or the 2nd coffee break?
To answer your question smac: We (AWS Robotics) are currently focused on contributing to the ROS2 tooling & security working groups. While we don’t currently have the bandwidth to contribute to nav/slam areas I am considering expanding my team to have that capability/bandwidth.
Sounds good. I’m in a space invaders shirt, hard to miss. Lets do lunch, meet at the AWS booth to walk over?
Is there anything that could be updated in this discourse thread after the meeting at ROScon?
I am currently using cartographer for 3D outdoor SLAM (application: self driving car). I get decent results in offline mode, but in online mode it is computationally too expensive to keep up. In that sense I agree that cartographer appears to be not meant for robotic applications, where latencies should be as low as possible. However, cartographer is one of the few packages that actually support 3D mode combined with the ability to include the GNSS in the pose graph optimization.
Do you think that it would be possible to have a single SLAM package that would work both indoor and outdoor? It seems that the requirements between indoor and outdoor SLAM differ a lot. If I may add a few criteria to the list of @mkhansen, then I would add these:
- Optionally including the GNSS in pose graph optimization
- Optional 3D mode
- Able to perform real time localization in an existing map
Hi,
I’ve taken this discussion as well as discussions had at ROSCon and created this high level summary ofmy thoughts. https://github.com/ros-planning/navigation2/issues/1389
If you have additional thoughts or concerns, lets move the conversation over there. To have consideration, we need the following at minimum to
- SLAM implementation must exist. I’m sure we can all use our collective brain power to create a new slam algorithm or generalized package, but the discussion right now isn’t centered around making something new but taking something and making it default for the immediate future. If a separate effort ends up working out to make a new package, that can be considered to replace this option in the future when it tangibly exists.
- SLAM implementation must have at least 1 person familiar with its code and willing te be an active maintainer into the future. This person does not necessarily have to be the original author.
- SLAM implementation should be sufficiently general to work with many vendors of LIDARs. May use other sensor data but the primary focus should be LIDARs, unless there is sufficient documented experiences to show robustness in varying changes over long periods of time. Points if it works with 3D lidars.
- Lets discuss the practical merits of a package before technical. While I would love to geek out about SLAM methods and ideas, the point here is to find something that can be used for a large number of people and environments, with support and ROS2-enabled. The quality of how well it works is less important at this stage as the technical project management elements. With many SLAM algorithms that pass that first gate, we can then discuss the technical merits of their approaches.
2 Likes