# Global and local costmap are shifted in relation to the map mapped by gmapping

Dear friends,

I have the following problem where I would love to get any hint that leads me to a solution. First of all here are my tech specs:

• ROS melodic with Stage 4.3 simulation
• Ubuntu 5.4.0-65.73~18.04.1-generic 5.4.78
• Environment variables ROS_ETC_DIR=/opt/ros/melodic/etc/ros ROS_ROOT=/opt/ros/melodic/share/ros

ROS_MASTER_URI=http://localhost:11311 ROS_VERSION=1 ROS_PYTHON_VERSION=2 ROS_PACKAGE_PATH=/home/emanuel/rccar_ws/src:/home/emanuel/testnav_ws/src:/home/emanuel/floribot_ws/src/base:/home/emanuel/floribot_ws/src/plc_connection:/opt/ros/melodic/share ROSLISP_PACKAGE_DIRECTORIES=/home/emanuel/rccar_ws/devel/share/common-lisp:/home/emanuel/testnav_ws/devel/share/common-lisp:/home/emanuel/floribot_ws/devel/share/common-lisp ROS_DISTRO=melodic

I am running a ROS Stage simulation with a differential drive robot equipped with a laser scanner and odometry. The robot is to pass through a corn field. It does not know the area at the beginning but is given an empty map that is dynamically builds up as the robot proceeds. The navigation stack is set up as described in http://wiki.ros.org/navigation/Tutori... with some modifications. I am using the following planners:

• global planner: A self written planner that simply returns the goal which yields to a straight line from the current position to the goal not depending on any costmap
• local planner: DWAPlannerROS

Now to my question: When I am sending navigation goals to the robot it can follow and reach them eventually. But I have noticed that almost every time the global and local costmap are shifted and do not match the map mapped by gmapping. Thus, the costs in the costmaps which are indicating an obstacle (here: corn plant) do not sit directly at the mapped obstacles but are shifted as it can be seen in the picture. This leads to a very unstable navigation: Sometimes the robot can reach its given goals but sometimes not. What can I change to have the costmaps lay perfectly onto the mapped map?

Unfortunately I do not have enough points to include a picture - therefore I uploaded it to this page: https://ibb.co/yXGFzqj

I appreciate any hint that could help me fixing this. Kind regards, Eman

P.S. here are my costmap and planner config files

costmap_common_params.yaml

global_frame: map
obstacle_range: 5.0
raytrace_range: 10.0
footprint: [[0.275, 0.125], [-0.275, 0.125], [-0.275, -0.125], [0.275, -0.125]]

plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
publish_frequency: 1.0
static_layer:
unknown_cost_value: -1
lethal_cost_threshold: 250
map_topic: map
first_map_only: false
track_unknown_space: true
use_maximum: false
trinary_costmap: false
obstacle_layer:
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: base_laser_link, data_type: LaserScan, topic: base_scan, marking: true, clearing: true}
track_unknown_space: true
footprint_clearing_enabled: true
combination_method: 0
#    origin_z: 0.0
#    z_resolution: 0.05
#    z_voxels: 10
#    unknown_threshold: 10
#    mark_threshold: 0
#    publish_voxel_map: false
inflation_layer:
inflation_radius: 0.35 # = gap corn row / 2, so that robot runs in the very center of the row
cost_scaling_factor: 15.0 # the higher, the quicker ...
edit retag close merge delete

Sort by » oldest newest most voted

Hi,

can you provide your config for the costmap and the planners? (mostly the frames they operate in are interesting) furthermore please provide a tf tree of your setup.

My guess is, that your odom frame isn't sitting at the same spot as your map frame, which maybe will offset your costmaps if their global_frame is odom. Therefore please check the global_frame of your costmaps.

The misalignment probably comes from the mapping and localization procedure. Thats why your global_frame of the costmap imo should be map. Can you check the position of your global costmap in rviz? For this set fixed frame to map. Does the position move over time?

Hope this helps

more

Hi Tristan,

thank you for your answer. I added the costmap and planner config files in addition to the tf tree and my launch file into the description. - I have set the global_frame for the local and global costmap to map, but the problem still exists - The fixed frame in rviz is set to map. Yes, the position of the global costmap moves when the robot is moving -> this leads to the shift that I have encountered (see another image here https://ibb.co/HXrKPsB)

Do you have an idea where the error may come from?

Kind regards,

Eman

( 2021-03-05 02:04:42 -0500 )edit

I think there is something wrong with odom or gmapping, because

• at the beginning odom tf matches map tf perfectly but later on odom tf moves away from map tf while the robot is moving (map tf is fixed frame in rviz)
• after the robot has moved and the costmap does not overlay with the static map, the laserscan matches the obstacles in the costmap but not the one in the static map

Here is an image that shows what I mean: https://ibb.co/HK4tdfS

Does that help somehow to find the errror causing this behaviour

( 2021-03-05 04:39:27 -0500 )edit

Ok, thanks for the further information. I can't tell you exactly what is causing the behavior but i can point out things that seem weird in your setup.

Check the global_costmap_params.yaml and local_costmap_params.yaml here you define you want the maps to be static meaning not moving relative to the global_frame. Diretly after that you define them as rolling window meaning moving with your base frame.

This certainly is wrong the costmap can either be rolling or static, not both. Take a look at the parameter part in the Documentation

My proposal here is the general setup for the costmaps:

global:
static_map: true
rolling_window: false
global_frame: map

local:
static_map: false
rolling_window: true
global_frame: odom

( 2021-03-05 08:19:09 -0500 )edit

I am actually unsure if i would include the static layer in the local costmap. I would probably feed only live data to it so it can clear obstacles that have been previously in the map but aren't there anymore.

( 2021-03-05 08:32:12 -0500 )edit

Hello Tristan, thank you for your help! together with a friend we have found the solution: Disabling the amcl did the trick! Probably slam_gmapping and amcl were competing against each other and causing jumps in the tf between map-->odom. Further more I set both global_frame to map:

global_costmap:
static_map: true
rolling_window: false
global_frame: map

local_costmap:
static_map: false
rolling_window: true
global_frame: map


It is so cool to have you guys helping out! Thank you, Eman

( 2021-03-10 12:39:02 -0500 )edit

Hey Eman, thanks for the update i am happy that i was able to help you.

What you are saying makes totally sense, since both gmapping and amcl have a localization they both publish tf transforms.

Yea i love this community here as well. I was totally lost, when i started with ros.

( 2021-03-10 12:45:32 -0500 )edit