Robotics StackExchange | Archived questions

Map update loop missed its desired rate

Hi,

I encounter this well known issue with the global costmap:

[ WARN] [1690554476.967147020]: Map update loop missed its desired rate of 5.0000Hz... the loop actually took 12.3751 seconds

I found also many answer in the web, but none of those resolve my issue. Someone suggest to comment "r.sleep()" in this line, someone suggest to reduce global costmap dimension or resolution... None of these solutions resolved the issue.

So, I looked for the source of the problem and I found that the action that causes this large delay is the lock of the mutex at these two lines: LayeredCostmap::updateMap and Costmap2DPublisher::publishCostmap.

How can I solve this problem? Anyone can help me?

Here below my config files:

costampcommonparams.yaml (Here I write only the global costmap params):

robot_base_frame: base_link
transform_tolerance: 0.5
map_type: costmap
origin_x: 0.0
origin_y: 0.0
footprint: [[1.25,0.4],[-0.4,0.4],[-0.4,-0.4],[1.25,-0.4]] 
footprint_padding: 0.3
always_send_full_costmap: True


map_layer_global:
  enabled: True
  unknown_cost_value: 255 
  lethal_cost_threshold: 255 
  map_topic: /mapper/map/move_base 
  first_map_only: True 
  subscribe_to_updates: False 
  track_unknown_space: False 
  use_maximum: False
  trinary_costmap: True 

inflation_layer_global: 
  enabled: True
  cost_scaling_factor: 2.58
  inflation_radius: 1.1
  inflate_unknown: True


obstacles_layer_global:
  enabled: True
  cost_scaling_factor: 2.0
  obstacle_range: 14.0
  raytrace_range: 15.0
  inflation_radius: 0.7
  track_unknown_space: False
  combination_method: 1
  max_obstacle_height: 2.5 
  lethal_cost_threshold: 100
  unknown_cost_value: 255     
  footprint_clearing_enabled: True
  observation_sources: base_laser_scan_sensor_clearing base_laser_scan_sensor_marking top_laser_scan_sensor_clearing top_laser_scan_sensor_marking 
  base_laser_scan_sensor_clearing: {sensor_frame: scan_fl, data_type: LaserScan, topic: sick_fl/scan, marking: False, clearing: True}
  base_laser_scan_sensor_marking: {sensor_frame: scan_fl, data_type: LaserScan, topic: sick_fl/scan, marking: True, clearing: False}
  top_laser_scan_sensor_clearing: {sensor_frame: scan_br, data_type: LaserScan, topic: sick_br/scan, marking: False, clearing: True}
  top_laser_scan_sensor_marking: {sensor_frame: scan_br, data_type: LaserScan, topic: sick_br/scan, marking: True, clearing: False}

globalcostampparams.yaml:

global_costmap:
  global_frame: map
  robot_base_frame: base_link
  update_frequency: 5.0
  publish_frequency: 3.0
  static_map: false
  width: 12.0
  height: 12.0
  resolution: 0.3
  raytrace_range: 13.0
  always_send_full_costmap: False

  plugins: 
        - {name: map_layer_global, type: "costmap_2d::StaticLayer" }
        - {name: obstacles_layer_global,  type: "costmap_2d::ObstacleLayer" }
        - {name: inflation_layer_global,  type: "costmap_2d::InflationLayer" }

I use ROS noetic on Ubuntu 20 with an 11th Gen Intel(R) Core(TM) i5-1145G7E @ 2.60GHz with 8Gb RAM.

PS. htop says that resources are not full (cpus and ram)

Asked by AndreaTimpani on 2023-07-28 09:55:31 UTC

Comments

How big is your map, in pixels? What is the output of the command rospack find costmap_2d ?

Asked by Mike Scheutzow on 2023-07-29 09:02:48 UTC

Hi Mike, and thanks for the answer. My map is 640x1056 with a resolution of 0.05. the output of rospack find costmap_2d is /opt/ros/tamago/share/costmap_2d. I also run the command rosversion costmap_2d and the output is 1.17.3.

Asked by AndreaTimpani on 2023-07-31 02:00:40 UTC

Are you building the costmap_2d from source code? Why does the path say tamago and not noetic?

Asked by Mike Scheutzow on 2023-07-31 08:38:21 UTC

Yes, I built the package from the source code inside my own workspace

Asked by AndreaTimpani on 2023-07-31 08:43:04 UTC

You did not answer the 2nd question. Is there a reason you are not using the ros apt repository?

Asked by Mike Scheutzow on 2023-07-31 09:10:30 UTC

Because we haveto modify AMCL inside the navigation stack. But we never modify costmap_2d package. And we prefere to have the entire package in our workspace

Asked by AndreaTimpani on 2023-07-31 09:15:29 UTC

Answers

To achieve good performance, costmap_2d needs to be a Release build, not a Debug build:

catkin_make -DCMAKE_BUILD_TYPE=Release

I can not predict whether this alone will be enough to reduce your loop time from 12.3 sec to 0.200 sec. You might also consider decreasing the costmap update_frequency if it is safe to do so for your robot's environment.

Asked by Mike Scheutzow on 2023-07-31 10:22:37 UTC

Comments