Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using Elevation Mapping instead of OctoMap in ROS-noetic #1175

Closed
FlorianMehnert opened this issue Dec 6, 2023 · 4 comments
Closed

Using Elevation Mapping instead of OctoMap in ROS-noetic #1175

FlorianMehnert opened this issue Dec 6, 2023 · 4 comments

Comments

@FlorianMehnert
Copy link

Hi,

for larger areas it appears that the 3d octomap might become too large to handle. I would like to only use a 2.5d map which should be more efficient in storing the environment data.
Is it possible to substitute the OctoMap used in the rtabmap-slam with the Gridmap used in Elevation Mapping?

Thanks :)

@matlabbe
Copy link
Member

You could probably launch elevation_mapping node along side of rtabmap node that would provide the TF map->base_link, connect for odometry pose to elevation_mapping then the robot centric elevation map would be available. If you need the global map as an elevation map and that map is updated on loop closures, we would indeed need to integrate GridMap/ElevationMap inside rtabmap like we did with OctoMap. However, the GridMap library seems more focused on local elevation map around the robot (like inside 2-3 meters radius) like a local costmap with rolling window, not a 100 m x 100 m elevation map for example. I don't know if there is maximum map size supported.

I don't have experience with GridMap, so not sure how hard it would be to integrate as an external library. I guess we could assemble the local 3D occupancy grid maps saved in nodes and integrate them as PointCloud2 into a GridMap layer of size equal to our global map. That would be similar than this function:

cv::Mat create2DMapFromOccupancyLocalMaps(

but we would not lose the elevation of the resulting 2D map. And like the we did for OctoMap to avoid re-assembling the whole OctoMap when the graph didn't change a lot, the full global map won't need to be regenerated unless bounds are reached or graph optimization makes the nodes move more than X cm.

In term of usage, the GridMap approach could be selected by adding an updateGridMap option here and updating our GridMap wrapper class. I'll take a look in the code tomorrow.

@matlabbe
Copy link
Member

GridMap has been integrated in PR above for ROS noetic. A new elevation map topic is published. See #1180 for example.

TODO: update ros2 branch with elevation map topic.

@FlorianMehnert
Copy link
Author

Thank you for your effort ❤️
The integration is working great. I guess I close this issue now

@matlabbe
Copy link
Member

matlabbe commented Feb 7, 2024

Oh yeah the todo for ros2 is indeed done from that merge introlab/rtabmap_ros@80ae448

Small note, the current implementation will re-update a cell in the elevation map with latest value added to map (there is no average to account the noise or ray tracing like in an OctoMap, just using latest observed value over a cell). For example, if in one frame there was someone, you may get sudden high elevation, then as soon as the person moves, the values will be reset to floor if in the frame we can see the floor for that particular cell.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants