ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

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

asked 2021-03-02 03:37:58 -0500

MoritzEmanuel gravatar image

updated 2021-03-05 01:58:06 -0500

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
robot_base_frame: base_link
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
    subscribe_to_updates: 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 ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-03-02 08:43:40 -0500

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

edit flag offensive delete link more

Comments

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

MoritzEmanuel gravatar image MoritzEmanuel  ( 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

MoritzEmanuel gravatar image MoritzEmanuel  ( 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
Tristan9497 gravatar image Tristan9497  ( 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.

Tristan9497 gravatar image Tristan9497  ( 2021-03-05 08:32:12 -0500 )edit
1

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

MoritzEmanuel gravatar image MoritzEmanuel  ( 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.

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

Question Tools

1 follower

Stats

Asked: 2021-03-02 03:37:58 -0500

Seen: 529 times

Last updated: Mar 05 '21