move_base does not update local_costmap

asked 2020-01-02 08:23:54 -0500

Yehor
166 ●39 ●49 ●49

updated 2020-01-03 04:22:57 -0500

Hello,

I have problem with navigation stack, move_base node in particular. I have launched everything and the robot is going to the goal, which I specified on rviz. AMCL localization is working and everything is good except 1 thing, the move_base node doesn't publish any data to local_costmap topic and the robot can't avoid new obstacles.

this is the output from

rosparam get /move_base

NavfnROS: {allow_unknown: true, default_tolerance: 0.1, planner_costmap_publish_frequency: 0.5,
  planner_window_x: 0.0, planner_window_y: 0.0, visualize_potential: true}
TrajectoryPlannerROS: {acc_lim_th: 3.5, acc_lim_theta: 1.0, acc_lim_x: 1.0, acc_lim_y: 1.0,
  angular_sim_granularity: 0.05, controller_frequency: 5, dwa: true, escape_reset_dist: 0.1,
  escape_reset_theta: 1.57079632679, escape_vel: -0.1064, gdist_scale: 0.8, global_frame_id: odom,
  goal_distance_bias: 2.5, heading_lookahead: 0.325, heading_scoring: true, heading_scoring_timestep: 0.8,
  holonomic_robot: false, latch_xy_goal_tolerance: true, max_rotational_vel: 1.0,
  max_vel_theta: 1.0, max_vel_x: 1.0, meter_scoring: true, min_in_place_rotational_vel: 0.05,
  min_in_place_vel_theta: 0.55, min_vel_theta: -1.0, min_vel_x: 0.2, occdist_scale: 0.1,
  oscillation_reset_dist: 0.1, path_distance_bias: 0.5, pdist_scale: 0.6, planner_frequency: 0,
  prune_plan: true, publish_cost_grid_pc: false, restore_defaults: false, sim_granularity: 0.25,

sim_time: 4.0, simple_attractor: false, vtheta_samples: 40, vx_samples: 20, xy_goal_tolerance: 0.2,
y_vels: '-0.3,-0.1,0.1,-0.3', yaw_goal_tolerance: 0.2}
aggressive_reset: {reset_distance: 1.84}
base_global_planner: navfn/NavfnROS
base_local_planner: base_local_planner/TrajectoryPlannerROS
clearing_rotation_allowed: true
conservative_reset: {reset_distance: 3.0}
conservative_reset_dist: 2.0
controller_frequency: 5.0
controller_patience: 3.0
global_costmap:
  footprint: '[]'
  footprint_padding: 0.01
  global_frame: map
  height: 10
  inflation_layer: {cost_scaling_factor: 10.0, enabled: true, inflate_unknown: false,
    inflation_radius: 0.4}
  inflation_radius: 0.4
  laser_scan_sensor: {clearing: true, data_type: LaserScan, marking: true, max_obstacle_height: 0.4,
    min_obstacle_height: 0.1, sensor_frame: laser_frame, topic: scan}
  observation_sources: laser_scan_sensor
  obstacle_layer:
combination_method: 1
enabled: true
footprint_clearing_enabled: true
    laser_scan_sensor: {clearing: true, data_type: LaserScan, marking: true, max_obstacle_height: 0.4,
      min_obstacle_height: 0.1, sensor_frame: laser_frame, topic: /scan}
    max_obstacle_height: 2.0
    observation_sources: laser_scan_sensor
    obstacle_range: 2.5
    raytrace_range: 3.0
  obstacle_range: 2.5
  origin_x: 0.0
  origin_y: 0.0
  plugins:
    - {name: static_layer, type: 'costmap_2d::StaticLayer'}
    - {name: obstacle_layer, type: 'costmap_2d::ObstacleLayer'}
    - {name: inflation_layer, type: 'costmap_2d::InflationLayer'}
  publish_frequency: 0.0
  raytrace_range: 3.0
  resolution: 0.05
  robot_base_frame: base_footprint
  robot_radius: 0.2
  static_layer: {enabled: true}
  static_map: true
  transform_tolerance: 1.0
  update_frequency: 3.0
  width: 10
local_costmap:
  footprint: '[]'
  footprint_padding: 0.01
  global_frame: odom
  height: 3
  inflation_layer: {cost_scaling_factor: 10.0, enabled: true, inflate_unknown: false,
    inflation_radius: 0.4}
  inflation_radius: 0.4
  laser_scan_sensor: {clearing: true, data_type: LaserScan, marking: true, max_obstacle_height: 0.4,
    min_obstacle_height: 0.1, sensor_frame: laser_frame, topic: scan}
  map_topic: map
  map_type: costmap
  observation_sources: laser_scan_sensor
  obstacle_layer: {combination_method: 1, enabled: true, footprint_clearing_enabled: true,
    mark_threshold: 0, max_obstacle_height: 2.0, origin_z: 0.0, unknown_threshold: 15,
    z_resolution: 0.2, z_voxels: 10}
  obstacle_range: 2.5
  origin_x: 0.0
  origin_y: 0.0
  plugins:
  - {name: obstacle_layer, type: 'costmap_2d::VoxelLayer'}
  - {name: inflation_layer, type: 'costmap_2d::InflationLayer'}
  publish_frequency: 2.0
  raytrace_range: 3.0
  resolution: 0.05
  robot_base_frame: base_footprint
  robot_radius: 0.2
  rolling_window: true
  static_map: false
  transform_tolerance: 1.0
  update_frequency: 5.0
  width: 3
max_planning_retries: -1
oscillation_distance: 0.5
oscillation_timeout: 0.0
planner_frequency: 3.0
planner_patience: 5.0
recovery_behavior_enabled: true
recovery_behaviors:
- {name: conservative_reset, type: clear_costmap_recovery/ClearCostmapRecovery}
- {name: rotate_recovery1, type: rotate_recovery/RotateRecovery}
- {name: aggressive_reset, type ...

(more)

edit retag flag offensive close merge delete

Comments

Check whether transform is available from laser_frame to robot's base_link frame

prince ( 2020-01-02 21:57:49 -0500 )edit

@prince I have checked everything seems to be okay, I'll post the screenshot of tf tree soon

Yehor ( 2020-01-03 04:10:29 -0500 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2020-02-12 01:17:56 -0500

Yehor
166 ●39 ●49 ●49

It seems that the problem was in: min_obstacle_height: 0.1 max_obstacle_height: 0.4

As @Namal Senarathne mentioned.

Now it is working))

edit flag offensive delete link

add a comment

answered 2020-01-02 09:51:47 -0500

cat_in_box
51 ●4 ●4

updated 2020-01-02 09:53:42 -0500

Two things to try in your costmap configs:

footprint: '[]' -> you haven't specified the robot footprint parameter in both the global and local costmaps. A simpler way is to list it in the common_costmap only (with the appropriate footprint dimensions added). You can add the footprint as discussed in section 2.3.1 from the navigation setup docs.
laser_scan_sensor is defined three times: twice in the global costmap and once in the local costmap. In the two global costmap definitions it's given different parameters: the first time sensor_frame subscribes to topic scan, while the second time sensor_frame subscribes to topic \scan. As above, I would remove all three definitions from the global and local costmaps and instead include a single definition in the common_costmap, where the topic subscribed to is \scan.

edit flag offensive delete link

Comments

Thank you for your answer. I want to ask, instead of using footprint, I am using:

robot_radius: 0.2

Is is okay? Or I have to use footprint

And another question, do I need to write topic name with slash, or without.

/map or map

Yehor ( 2020-01-02 11:50:38 -0500 )edit

here I add my yaml files separately:

costmap_common_para.yaml:

obstacle_range: 2.0
raytrace_range: 3.0
#footprint: [[x0, y0], [x1, y1], ... [xn, yn]]
robot_radius: 0.2
#ir_of_robot
inflation_radius: 0.40
transform_tolerance: 1.0

observation_sources: laser_scan_sensor 
#point_cloud_sensor

#laser_scan_sensor: {sensor_frame: laser_frame, data_type: LaserScan, topic: scan, marking: true, clearing: true}

laser_scan_sensor:
  sensor_frame: laser_frame
  data_type: LaserScan
  topic: /scan
  marking: true
  clearing: true
  marking: true
  min_obstacle_height: 0.1
  max_obstacle_height: 0.4

#point_cloud_sensor: {sensor_frame: frame_name, data_type: PointCloud, topic: topic_name, marking: true, clearing: true}

global_costmap.yaml:

global_costmap:
  global_frame: map
  robot_base_frame: base_footprint
  update_frequency: 5.0
  static_map: true

Yehor ( 2020-01-02 11:51:46 -0500 )edit

local_costmap.yaml:

local_costmap:
  global_frame: map
  robot_base_frame: base_footprint
  update_frequency: 1
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 3.0
  height: 3.0
  resolution: 0.1
  plugins:
   - {name: obstacle_layer,      type: "costmap_2d::VoxelLayer"}
   - {name: inflation_layer,     type: "costmap_2d::InflationLayer"}

base_local_param.yaml:

TrajectoryPlannerROS:
  max_vel_x: 1.0
  min_vel_x: 0.3
  max_vel_theta: 1.0
  min_in_place_vel_theta: 0.7

  acc_lim_theta: 3.2
  acc_lim_x: 2.5
  acc_lim_y: 2.5

# Goal Tolerance Parameters
  xy_goal_tolerance: 0.5
  yaw_goal_tolerance: 0.5

  holonomic_robot: false

Yehor ( 2020-01-02 11:54:22 -0500 )edit

@cat_in_box do you have any other idea?

Yehor ( 2020-01-03 04:12:20 -0500 )edit

I would also check the following parameters in the laser_scan_sensor observation source

min_obstacle_height: 0.1
max_obstacle_height: 0.4

It could be that your laser is mounted outside of this height window (with respect to the map frame's z-axis origin)

Namal Senarathne ( 2020-01-21 21:05:22 -0500 )edit

@Namal Senarathne Hi! Thank you for your comment, could you explain please what does it mean: could be mounted outside of this height window??

My Laser scan frame is not on the same height with respect to the map. But it is mentioned in the tf tree.

Yehor ( 2020-01-23 03:24:48 -0500 )edit

What I meant was if your laser is mounted say 0.5m from the ground (where z = 0), then the laser points would be filtered out and not included in the costmap.

Namal Senarathne ( 2020-01-23 08:51:22 -0500 )edit

@Namal Senarathne Yes, it is mounted 0.4m from ground, but I mentioned it in static conversion in TF. So, I can't understand how it can be filtered out.

Could you explain?

Yehor ( 2020-01-24 04:18:53 -0500 )edit

see more comments

move_base does not update local_costmap

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

move_base does not update local_costmap edit

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

move_base does not update local_costmap