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

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 ...

edit retag close merge delete

This is really a guess, but if any kind of time synchronisation is used from message_filters and the buffers are too short then a 5 Hz and 25 Hz topic may always just be too far apart for any synchronised callback to be called.

But again: really a guess.

( 2018-11-17 06:42:01 -0600 )edit

Thanks for your guess! I took a look at the used message_filters and noticed the tf2_ros::MessageFilter. Transforms are published at a way higher rate (static: 1000 Hz & the rest ~ 30 Hz) - might that cause some issues? But that shouldn't be a problem as the timestamps don't deviate too much.

( 2018-11-17 12:42:54 -0600 )edit

Well as I wrote, it was really just a guess. I'm not into navigation or costmap2d at all.

( 2018-11-17 13:53:52 -0600 )edit

It may not be any help, but have you tried having the topics as "scan" rather than "/scan"? In your common params you define the topic as "scan" as expected, but in your launch file you use "/scan", I wonder if there is some odd conflict under the hood, resulting in the buffer getting confused?

( 2018-11-20 12:21:49 -0600 )edit

I dont think that would be the case or else it would never work. I'd also make sure your transform tolerance is in the right namespace to be picked up. That configuration file looks suspect... If the default tolerance is used, its not shocking to me this is happening.

( 2018-11-20 12:48:08 -0600 )edit

Thanks for the ideas. The transform_tolerance is interpreted correctly - the param server returns the specified value and if I set it to 0.0 all tf lookups fail as expected. I tried running everything without renaming the topics in the launch file but that didn't affect the problem as well.

( 2018-11-21 03:44:28 -0600 )edit