Problems with costmap and the inflation layer [closed]

asked 2015-06-15 05:08:12 -0600

Gork gravatar image

updated 2015-06-22 05:48:51 -0600

Hello,

since english isn't my first language, I hope I can explain my problem well enough and I am thanking you in advance for slogging through this mess of a text.

I'm kind of new to ROS and was setting up the navigation stack as a part of my bachelor thesis. I followed this tutorial. I'm using v-rep to simulate and rviz to visualize. I properly configured all necessary publishers (odom, tf, etc.).

In my understanding, the inflation layer exists for keeping the robot out of range of obstacles. I adjusted the inflation_radius and the cost_scaling_factor parameters to my liking, but here lies the problem. My robot seems to ignore the gobal path (green line), and tries to make a very sharp turn around the inscribed area, causing the center of the robot to enter the inscribed area as soon as the costmap moves itself a little bit (for accuracity reasons I believe) and stopping the navigation. What am I doing wrong? Why is the robot ignoring the global plan that acknowledges the costmap values and doing something different?

Thanks in advance for your answers.

Best Regards, Georg Schuppe

EDIT: Solved. I learned about the parameters pdist_scale and occdist_scale. With proper configuration, I could solve my problem.

image description

Ubuntu 14.04 ROS indigo newest versions of rviz and vrep (updated 15.06.2015)

costmap_common_params.yaml

obstacle_range: 4.5
raytrace_range: 5.0

footprint: [[0.52, 0.32],
            [0.52, 0.028],
            [0.62, 0.028],
            [0.62, -0.028],
            [0.52, -0.028],
            [0.52, -0.32],
            [-0.54, -0.32],
            [-0.54, 0.32]]

inflation_radius: 1.0
cost_scaling_factor: 0.5

observation_sources: base_scan

base_scan: {sensor_frame: base_front_link,
            data_type: LaserScan,
            topic: /vrep/front_scan,
            expected_update_rate: 0.2,
            observation_persistence: 0.0,
            marking: true,
            clearing: true,
            min_obstacle_height: -0.10,
            max_obstacle_height: 2.0}

base_local_planner_params.yaml

TrajectoryPlannerROS:
  max_vel_x: 0.45
  min_vel_x: 0.1
  max_rotational_vel: 1.0
  min_in_place_rotational_vel: 0.4

  acc_lim_th: 3.2
  acc_lim_x: 2.5
  acc_lim_y: 2.5

  holonomic_robot: true

  xy_goal_tolerance: 0.3
  yaw_goal_tolerance: 0.3

local_costmap_params.yaml

local_costmap:
  global_frame: odom
  robot_base_frame: base_link
  update_frequency: 5.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 20.0
  height: 20.0
  resolution: 0.05

global_costmap_params.yaml

global_costmap:
  global_frame: /map
  robot_base_frame: base_link
  update_frequency: 5.0
  static_map: true
  width: 40.0
  height: 40.0
edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Gork
close date 2015-06-22 05:47:36.805772

Comments

What does the local costmap look like?

David Lu gravatar imageDavid Lu ( 2015-06-15 08:56:53 -0600 )edit

Sorry for answering so late, I solved the problem by myself. The local planner was simply not impressed enough about the local costmap, there is a parameter in base_local_planner_params.yaml that solves exactly that: occdist_scale. In summary: global plan, was good, local plan messed it up.

Gork gravatar imageGork ( 2015-06-22 05:45:47 -0600 )edit