Open
Conversation
save() acquires global_mapping_mutex and calls optimize() internally. This blocks the ROS2 executor thread for the duration (potentially 30-60s for large maps). Sensor callbacks cannot fire during this window — DDS/RMW subscriber queues have bounded depth and incoming LiDAR/IMU data may be dropped. This is intentional: save_map is an operator action; a brief data gap is acceptable. Do not call from automated controllers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a simple ROS2 save map service (
SaveMap.srv) that allows saving the ROS node's results without shutting down the node. This is something I needed, as I wanted to save intermediate steps between sequential bags during large mobile mapping runs (processing happens offline).To use the service:
ros2 service call /glim_ros/save_map glim_ros/srv/SaveMap "{path: '/example/path'}"The save blocks the ROS2 executor thread while writing. Sensor data queued during a long save may be dropped by DDS. This is expected behaviour and is logged as a warning. This is because I only need to run it at the end of a bag after playing, and making this asynchronous would have been a significantly more complex undertaking.
I have tested this service running this on one of the example bags on my computer using a jazzy build, and the behaviour is as expected.