Costmap2D: Observation layer's laser scan callback is never called with a low publication rate

edit

Hi, I'm facing an issue (that seems to be) related to the navigation stack's costmap.

Summary of the problem: The obstacle layer's laser scanner callback is never called with a low publication frequency of the laser scanner. Everything runs fine with a higher publication frequency, although Gazebo publishes at the correct rate.

I'm running ROS Melodic on Ubuntu 18.04 with a simulated Turtlebot 3 Burger in Gazebo. Localization is based on AMCL and for navigation I use move_base. I use to the following resources to spawn the robot: https://github.com/ROBOTIS-GIT/turtle... .

If I run the laser scanner with the normal frequency at 5 Hz (<update_rate>5</update_rate>) the observation buffer of the costmap is not updated at all. If I increase the update rate to 25 Hz everything runs fine - just as expected.

UPDATE: I still did't figure out why the callback is not working. However, it seems to be related to the transforms. When I reduce the transform frequency of the differential drive plugin from 30 Hz to only 5 Hz the laser scanner callback sometimes updates the scans. After some time the timeouts don't occur anymore at all or just rarely and the laser callback is called. From this, I assume that this is somehow related to the tf2_ros::MessageFilter where the callback is registered . I guess that the future stamped transforms from the robot_pose_publisher and AMCL play a role as well.

UPDATE 2: After fiddling around with a lot of parameters, I think that the reason for the observed behavior comes somewhere from the tf2_ros::MessageFilter and costmap_2d::ObservationBuffer . I noticed that when I run the differential drive plugin at 5 Hz and the laser scanner at 6 Hz, then the callback updates the values. I am still just guessing, but there is some relation between the publication frequencies of the differential drive plugin (that also boradcasts the transforms for the odom frame), the publication frequency of the laser scanner and the tf2 message filter. Unfortunately, I'm not too familiar with these libraries - but perhaps all this information helps someone running into the same problem.

My first guess was that the laser scanner messages are not published at the right rate or Gazebo can't keep up with the speed. However, rostopic hz /scan and gz topic --hz /scan tell me that the publication frequency is 5 Hz. Additionally, I compared the timestamps of the scan messages with the values of the /clock topic (/use_sim_time is true) - there aren't any large deviations. So it looks like like the problem isn't related to Gazebo.

Even with a rather generous expected_update_rate: 0.50 and a transforms_tolerance: 0.50 the observation buffer is not updated at all. AMCL runs fine and all the transforms in the transform tree look good. The scan messages are fine as well and correctly displayed in rviz.

So I went ahead, uninstalled the move_base package and reinstalled it from source to check what ... (more)