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

Local costmap does not update obstacles on one side of the robot [closed]

asked 2021-04-23 13:30:05 -0600

s_niket gravatar image

updated 2021-04-26 14:42:24 -0600

Hi, I have been facing this weird issue and would appreciate any help possible.

My robot has a 2D LiDAR sensor and I have been trying to generate a global and a local costmap using the ROS Navigation's costmap_2d. The package does generate correct global costmap but the local costmap does not update any obstacles on the right half of the robot.

I tried to play around with the "expected_update_rate" param and other ObstacleLayer params but I couldn't get the desired output. I also tried rotating the robot, but it's independent of it, it's always the right half of the robot that is ignored.

Here's the output on the rviz: https://drive.google.com/file/d/1lzLy...

The following are the params for move_base and the launch file:

DWAPlannerROS: {acc_lim_theta: 2.0, acc_lim_trans: 0.1, acc_lim_x: 1.0, acc_lim_y: 0.0,   angular_sim_granularity: 0.1, forward_point_distance: 0.325, global_frame_id: odom,   goal_distance_bias: 24.0, max_scaling_factor: 0.2, max_vel_theta: 1.0, max_vel_trans:
0.5,   max_vel_x: 0.5, max_vel_y: 0.5, min_vel_theta: 0.4, min_vel_trans:
0.1, min_vel_x: 0.0,   min_vel_y: 0.0, occdist_scale: 0.5, oscillation_reset_angle: 0.2, oscillation_reset_dist: 0.05,   path_distance_bias: 64.0, prune_plan: false, publish_cost_grid_pc: true, publish_traj_pc: true,   restore_defaults: false, scaling_speed: 0.25, sim_granularity:
0.025, sim_time: 1.0,   stop_time_buffer: 0.2, theta_stopped_vel: 0.4, trans_stopped_vel: 0.0, twirling_scale: 0.0,   use_dwa: true, vth_samples: 20, vtheta_samples: 20, vx_samples: 6, vy_samples: 1,   xy_goal_tolerance: 0.15, yaw_goal_tolerance: 0.3} GlobalPlanner: {allow_unknown: true, cost_factor: 3.0, default_tolerance:
0.0, lethal_cost: 253,   neutral_cost: 50, old_navfn_behavior: false, planner_costmap_publish_frequency:
0.0,   planner_window_x: 0.0, planner_window_y: 0.0, publish_potential: true, publish_scale: 100,   use_dijkstra: true, use_grid_path: false, use_quadratic: true} NavfnROS: {allow_unknown: false, default_tolerance: 0.0, planner_window_x: 0.0, planner_window_y: 0.0,   visualize_potential: false} aggressive_reset: {reset_distance:
1.84} base_global_planner: navfn/NavfnROS base_local_planner: dwa_local_planner/DWAPlannerROS clearing_rotation_allowed: true conservative_reset: {reset_distance:
3.0} conservative_reset_dist: 3.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:
5.0, enabled: true, inflate_unknown: false,
    inflation_radius: 0.3}   obstacle_layer:
    combination_method: 1
    enabled: true
    footprint_clearing_enabled: true
    max_obstacle_height: 2.0
    observation_sources: scan
    obstacle_range: 5.0
    raytrace_range: 10.0
    scan: {clearing: true, data_type: LaserScan, marking: true, sensor_frame: base_link,
      topic: /scan}   obstacle_range: 5.0   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.5   raytrace_range: 10.0   resolution:
0.05   robot_base_frame: base_link   robot_radius: 0.2   rolling_window: false   static_layer: {enabled: true, map_topic: map, subscribe_to_updates: true}   static_map: true   transform_tolerance: 0.5   update_frequency: 1.0   width: 10 local_costmap:   combination_method: 0 footprint: '[]'   footprint_padding:
0.01   global_frame: odom   height: 10   inflation_layer: {cost_scaling_factor:
5.0, enabled: true, inflate_unknown: false,
    inflation_radius: 0.3}   obstacle_layer:
    combination_method: 1
    enabled: true
    footprint_clearing_enabled: true
    max_obstacle_height: 2.0
    observation_sources: scan
    obstacle_range: 5.0
    raytrace_range: 10.0
    scan: {clearing: true, data_type: LaserScan, expected_update_rate: 0.4, marking: true,
      sensor_frame: base_link, topic: /scan}   obstacle_range: 5.0   origin_x: 0.0   origin_y: 0.0   plugins:
  - {name: obstacle_layer, type: 'costmap_2d::ObstacleLayer'}
  - {name: inflation_layer, type: 'costmap_2d::InflationLayer'}   publish_frequency: 5.0   raytrace_range: 10 ...
(more)
edit retag flag offensive reopen merge delete

Closed for the following reason too subjective or argumentative by s_niket
close date 2021-04-28 14:34:08.131684

Comments

  • /move_base/local_costmap/obstacle_layer/scan/topic: /cat_dog/correcte...

The LaserScan topic name you are using is /cat_dog/correcte... Is that correct? When you view the topic in rviz, does the right half of the topic show up?

miura gravatar image miura  ( 2021-04-24 02:25:54 -0600 )edit

Yes, my bad, I had edited the description here to change the /scan topic name. Yes, the lidar scan topic is correct and the right half does show up. If you look at the image I have linked, it shows that the right half has inflated obstacles from the global_costmap, but nothing in the local even though the obstacles are within the range of the local_costmap.

s_niket gravatar image s_niket  ( 2021-04-24 09:21:26 -0600 )edit

I honestly can't predict it anymore. (I'm a little concerned that the frame_id is different between global_costmap and local_costmap, but I don't think this leads to the event in question. )

I have a suggestion for an approach to research. Why don't you try setting global_costmap and local_costmap to the exact same settings? You should get the same cost map. From there, change the values back one by one to the current values. If it is the same as the current state, then something is lurking there.

miura gravatar image miura  ( 2021-04-27 10:43:14 -0600 )edit

Hey, thanks for all the support. I was able to identify the bug yesterday, and currently working on solving it. So I published the pointcloud from ObservationBuffer object's latest observation and the pointcloud was only half of the actual pointcloud. The bufferCloud method in the ObservationBuffer class does a transformation of the original cloud to a global_frame_cloud and that transformation right now is causing a loss in data. If I passed the un-transformed pointcloud to the ObstacleLayer class, I could see the entire pointcloud.

s_niket gravatar image s_niket  ( 2021-04-27 11:18:04 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-04-24 20:28:01 -0600

miura gravatar image

updated 2021-04-26 11:07:04 -0600

  • /move_base/local_costmap/obstacle_layer/raytrace_range: 4.0

I think the obstacle is erased because raytrace_range is smaller than obstacle_range.

Update

  • /move_base/local_costmap/combination_method: 0

Have you tried setting 1?

edit flag offensive delete link more

Comments

Yeah, I tried different combinations and it failed even then. The combinations being scan_range > raytrace_range, scan_range >>> raytrace_range, scan_range < raytrace_range and scan_range <<< raytrace_range

s_niket gravatar image s_niket  ( 2021-04-26 10:33:13 -0600 )edit

Yes I've tried with combination_method as 0 and 1

s_niket gravatar image s_niket  ( 2021-04-26 11:07:59 -0600 )edit

Question Tools

1 follower

Stats

Asked: 2021-04-23 13:22:59 -0600

Seen: 691 times

Last updated: Apr 26 '21