Ask Your Question
0

why local costmap rotates with robot [closed]

asked 2011-09-29 13:32:12 -0500

VN gravatar image

updated 2011-10-09 21:10:34 -0500

Hi: I got a strange problem. I am simulating a robot in gazebo and visualizing in rviz. My local costmap rotates as robot traverses along its planned path. I tried all options, double check with frames naming. Please refer to an image below.image description

costmap configuration files are as follow:

costmap_common_params_sim.yaml

footprint: [[-0.18,-0.20],[-0.28,-0.10],[-0.28,0.10],[-0.18,0.20],[0.070,0.20],[0.180,0.10],[0.180,-0.10],[0.07,-0.20]]    
inflation_radius: 0.75
cost_scaling_factor: 10.0
transform_tolerance: 2.0

observation_sources: laser_scan_sensor sonar_scan_sensor point_cloud_sensor

laser_scan_sensor: {sensor_frame: base_scan_link, data_type: LaserScan, topic: /scan,marking: true, clearing: true, obstacle_range: 10, raytrace_range: 10}

sonar_scan_sensor: {sensor_frame: base_link, data_type: LaserScan, topic: /myscan, marking: false, clearing: true, obstacle_range: 5.2, raytrace_range: 5.7, observation_persistence: 0}

point_cloud_sensor: {sensor_frame: base_scan_link, data_type: PointCloud2, topic: /marking, max_obstacle_height: 7, min_obstacle_height: 2, marking: true, clearing: false, obstacle_range: 4.9, raytrace_range: 4.9, observation_persistance: 0}

global_costmap_params.yaml

global_costmap:
  global_frame: map
  robot_base_frame: base_footprint
  map_type: costmap
  unknown_cost_value: 1
  track_unknown_space: true
  obstacle_range: 10.0
  raytrace_range: 10.0
  update_frequency: 0.5
  publish_frequency: 0.2
  static_map: true

local_costmap_params.yaml

local_costmap:
  global_frame: odom
  map_type: costmap
  robot_base_frame: base_footprint
  obstacle_range: 2.0
  raytrace_range: 2.0
  update_frequency: 5.0
  publish_frequency: 1.0
  inflation_radius: 0.35
  static_map: false
  rolling_window: true
  width: 6.0
  height: 6.0
  origin_x: 0.0
  origin_y: 0.0
  resolution: 0.025

I am just using laser sensor to get the data in simulation. So "sonar_scan_sensor" and "point_cloud_sensor" in costmap_common_params_sim.yaml are not in use.

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Procópio
close date 2016-04-28 03:51:36.362688

Comments

Could you include your costmap configuration files?
Eric Perko gravatar imageEric Perko ( 2011-10-01 08:07:19 -0500 )edit
Have you looked at TF information in rviz? Specifically, you'd want to look at whether the odometric frame moves as expected relative to the map frame. If you see it rotate strangely, something is wrong in your odometry.
eitan gravatar imageeitan ( 2011-10-05 11:13:47 -0500 )edit

3 Answers

Sort by » oldest newest most voted
2

answered 2011-10-07 07:25:53 -0500

eitan gravatar image

If the odometric frame is rotating with respect to the map frame in rviz, it implies that something is wrong with the raw odometry information. You'll probably want to check that the odometry source you're using is operating correctly. Are you using a custom odometry source? Or are you exposing ground truth data from gazebo over tf somehow?

edit flag offensive delete link more

Comments

So another words about the root cause is the map -> odom tf relation is polluted by the terrible robot odometer output?

SHI.ZP gravatar imageSHI.ZP ( 2016-03-19 01:33:26 -0500 )edit
0

answered 2011-09-29 17:40:04 -0500

Alexandr Buyval gravatar image

I'm not sure, maybe it arises from the accumulation of odometry errors.

edit flag offensive delete link more
0

answered 2011-10-05 07:46:14 -0500

tfoote gravatar image

Are you using electric? There's a possibly releated question gazebo model wheels slip after upgrade to electric

edit flag offensive delete link more

Question Tools

Stats

Asked: 2011-09-29 13:32:12 -0500

Seen: 780 times

Last updated: Oct 09 '11