map update is slow and consumes excessive computational resources

[Zarqu0n]

Required Info:

• Operating System:
  Ubuntu 22.04
• Installation type:
  source
• ROS Version
  ROS2 Humble
• Version or commit hash:
  humble-branch
• Laser unit:
  RP Lidar S2

Steps to reproduce issue

Clone the ROS2 Slam Toolbox repository and set up the workspace.
Launch the Slam Toolbox node using the provided configuration for online mapping.
Begin mapping with a robot or a simulation that provides laser scans or other sensor data.
Observe the behavior of the occupancy grid update during mapping.

Expected behavior

The occupancy grid should update efficiently and in real time, requiring reasonable computational resources during the mapping process.

Actual behavior

The occupancy grid updates take significantly longer than expected, causing delays in mapping. Additionally, the process consumes an excessive amount of computational power, potentially leading to performance issues or lags.

When we comment the following part in the line, the process of connecting posegraphs becomes faster.

slam_toolbox/src/slam_toolbox_common.cpp

Line 293 in a69c0fe

updateMap();

At the same time, when deserializing large maps, for example, 100 mb maps, the map loading process can take more than 10 seconds. When we comment it like this, this process takes much less time.

It is normal for it to take time while loading the map, but as the map size grows during mapping, it limits the mapping process. It seems as if it is recreating the map from scratch with the scans that have been there since the beginning, instead of updating the map with the latest scans. I did not have the opportunity to examine the source code of the Karto very much.

How can we make this process consume less resources and happen faster?

Additional information

Tested on Saha Robotics Speedy Mobile Robot

[SteveMacenski]

and in real time

I think this is not entirely the case, this is usually on a timer to update the map periodically, but not in real time (i.e. every laser scan). The internal map representation used by the SLAM system is not an occupancy grid, its based on sensor measurements and chains of connections between them in a graph. The outputted occupancy grid is used by navigation, but not the actual native implementation of the map representation. Thus, when we updateMap() to publish the map, we're not just publishing the known map, we're actually generating it, live, on the fly.

Its not usual to need / want SLAM to update at 10hz with laser scans (or what have you), both for how scan matchers work and because when moving at < 1m/s with a decent lidar, you don't need that frequent of updates for successful occupancy grid mapping for navigation.

I don't disagree with you that it is a computationally expensive process, but it is iterating through all laser scans, allocating the map size of memory, raytracing them to mark occupancy status, and then finally publishing it. With that in mind, do you think there's still an issue? If so, taking a look at that process and seeing where you could improve performance I'm sure would be a valuable contribution :-)