-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
Bug report
Required Info:
- Operating System:
- Ubuntu 20.04
- ROS2 Version:
- Foxy binaries
- Version or commit hash:
- DDS implementation:
- Fast-RTPS
Steps to reproduce issue
Running slam toolbox on the commit at this PR SteveMacenski/slam_toolbox#223 and attempting to save the map through the cli by calling the /save_map service. To verify /map was being published to correctly I ran a ros2 topic hz which settled out with around the following output.
average rate: 0.145
min: 4.970s max: 30.000s std dev: 4.28447s window: 48
Given a call to the /save_map service I found that saving the map only succeeds about 1/3rd of the time, the rest of the time it outputs:
[async_slam_toolbox_node-1] [INFO] [1594529940.286451570] [map_saver]:
[async_slam_toolbox_node-1] map_saver lifecycle node launched.
[async_slam_toolbox_node-1] Waiting on external lifecycle transitions to activate
[async_slam_toolbox_node-1] See https://design.ros2.org/articles/node_lifecycle.html for more information.
[async_slam_toolbox_node-1] [INFO] [1594529940.286567916] [map_saver]: Creating
[async_slam_toolbox_node-1] [INFO] [1594529940.286682543] [map_saver]: Saving map from 'map' topic to '' file
[async_slam_toolbox_node-1] [WARN] [1594529940.286694799] [map_saver]: Free threshold unspecified. Setting it to default value: 0.250000
[async_slam_toolbox_node-1] [WARN] [1594529940.286705367] [map_saver]: Occupied threshold unspecified. Setting it to default value: 0.650000
[async_slam_toolbox_node-1] [ERROR] [1594529942.288657252] [map_saver]: Failed to save the map: timeout
[async_slam_toolbox_node-1] [INFO] [1594529942.288713783] [map_saver]: Destroying
Expected behavior
The timeout is easily configurable / longer when using slam_toolbox than the current 2 seconds or proper QoS configuration sets up the communications to be transient local (so they act like latching in ROS1) so that the last message is immediately sent over given that is hasn't expired past its deadline.
Additional Notes
I am not yet completely familiar with how different QoS combinations for the pub/subs behave but I would guess the best solution is to get the QoS configured so that it receives the last published map within a given time period. I know the slam_toolbox /map has the configuration of reliable and transient local but the map_saver /map subscription looks to be reliable and volatile (system defaults). Does that mean the map saver will not get the transient local behavior when subscribed to the /map topic? Potentially related to this, I noticed that after restarting slam_toolbox while keeping the same Rviz instance open it would not receive any new maps while it had the QoS profile of reliable and transient local. In order to get RViz to subscribe to the new slam_toolbox instance's /map topic correctly, I had to change the QoS on it to best effort and transient local.