Ask Your Question
1

"Obstacles" not being added to costmap in Navigation Stack

asked 2012-02-10 03:58:48 -0500

rohan_k gravatar image

updated 2012-02-10 05:53:28 -0500

Hi,

I'm running the Navigation Stack on my robot with no map, and publishing Point cloud messages to represent data coming in from Sonar sensors. Though I can plot the locations of the obstacles in Rviz using markers, they won't add to the costmap properly, such that even when an obstacle has been in range for a while, typing rostopic echo /move_base/local_costmap/obstacles results in:

header: 
  seq: 153
  stamp: 
    secs: 1328893241
    nsecs: 331444433
  frame_id: /odom
cell_width: 0.0500000007451
cell_height: 0.0500000007451
cells: []

I imagine when an obstacle is seen within range (which it is, as can be seen in Rviz), the cells: [] array becomes populated?

But it isn't - does anyone have an idea as to why not or what the problem might be? I've tried to post what I think might be useful below.

Thanks in advance,

Rohan

My yaml files and launch files look like this:

move_base.launch:

<launch>
  <master auto="start"/>

<node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
<rosparam file="$(find quadcopter_2dnav)/yaml/PC_params_costmap2d.yaml" command="load" ns="global_costmap" />
<rosparam file="$(find quadcopter_2dnav)/yaml/PC_params_costmap2d.yaml" command="load" ns="local_costmap" />
<rosparam file="$(find quadcopter_2dnav)/yaml/local_costmap_params.yaml" command="load" />
<rosparam file="$(find quadcopter_2dnav)/yaml/global_costmap_params.yaml" command="load" />
<rosparam file="$(find quadcopter_2dnav)/yaml/local_costmap_params.yaml" command="load" />
</node>

</launch>

global_costmap_params.yaml:

global_costmap:
  global_frame: odom
  robot_base_frame: base_link
  update_frequency: 5.0
  static_map: false

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: 6.0
  height: 6.0
  resolution: 0.05

PC_params_costmap2d.yaml:

global_frame: odom
robot_base_frame: base_link
update_frequency: 20.0
publish_frequency: 20.0
publish_voxel_map: true
static_map: false
rolling_window: true
width: 6.0
height: 6.0
resolution: 0.025

map_type: voxel
origin_z: -0.1
z_resolution: 1
z_voxels: 32
unknown_threshold: 10
mark_threshold: 0

transform_tolerance: 0.3
obstacle_range: 2.5
max_obstacle_height: 1.0
min_obstacle_height: 0.10
raytrace_range: 3.0
footprint: [[-0.4, -0.4], [-0.4, 0.4], [0.4,0.4], [0.4, -0.4]]
footprint_padding: 0.01
inflation_radius: 0.55
cost_scaling_factor: 10.0

observation_sources: point_cloud_sensorA

point_cloud_sensorA: {sensor_frame: 'base_sonarA', data_type: PointCloud, topic: '/sonar_data_to_pointcloud/point_cloud_sonar_dataA', marking: true, clearing: true}

EDIT 1:

After changing min_obstacle_height to -1, the obstacle message remains the same as above. The point cloud message being published looks like this:

header: 
  seq: 380
  stamp: 
    secs: 1328903308
    nsecs: 169542053
  frame_id: base_link
points: 
  - 
    x: 1.16724598408
    y: 0.0
    z: -0.035000000149
channels: 
  - 
    name: intensities
    values: [100.0]

Hence the point being registered is within range, yet it still doesn't appear on the obstacle list in the local costmap.

edit retag flag offensive close merge delete

Comments

Is the obstacle being detected at a height that's greater than 1 meter?
DimitriProsser gravatar imageDimitriProsser ( 2012-02-10 04:20:41 -0500 )edit
No, the obstacle is being detected about a metre away in the x direction
rohan_k gravatar imagerohan_k ( 2012-02-10 04:54:33 -0500 )edit
Oh, actually, the sensor position is at z = -0.4 relative to the base link, and is aimed horizontally, so technically it is being detected at x=1m, z=-0.4m - could that be the issue? does the "min_obstacle height" parameter nullify that reading?
rohan_k gravatar imagerohan_k ( 2012-02-10 04:56:10 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
3

answered 2012-02-10 05:36:29 -0500

DimitriProsser gravatar image

If your sensor is reading the obstacle at z=-0.4m with respect to base_link, it will not register as an obstacle due to the min_obstacle_height parameter. The options are to either lower this setting (it can be negative), or move your sensor.

edit flag offensive delete link more

Comments

Thanks for pointing that out - obviously it was an issue. However it is still the same problem when echoing the local_costmap/obstacles message. I have written an edit above. Any ideas?
rohan_k gravatar imagerohan_k ( 2012-02-10 05:54:50 -0500 )edit
Perhaps voxel maps require more than a single point in order to register an obstacle?
DimitriProsser gravatar imageDimitriProsser ( 2012-02-10 06:21:44 -0500 )edit
If i make it a non-voxel map and register a point at x=1m, z=-0.4m, will that be added to a non voxel based map? or can it only register points in the plane of the robot or something? i.e. can i just turn map-type to costmap (and make other necessary adjustments of course)?
rohan_k gravatar imagerohan_k ( 2012-02-10 06:30:52 -0500 )edit
The costmap map type is 2D only. That could be a problem for your application. I'm not sure; only you would know that.
DimitriProsser gravatar imageDimitriProsser ( 2012-02-10 06:50:58 -0500 )edit
yes I'm aware, but for now I'm just trying to get it to work in 2D! The question is if it registers an obstacle at x=1, y=0, z=-0.4, should it add an obstacle to the 2D costmap at x=1, y=0? And if so, why is my implementation not doing that?
rohan_k gravatar imagerohan_k ( 2012-02-10 06:56:26 -0500 )edit
It should register an obstacle in at x=1 y=0 z=-0.4 in the frame of the costmap, yes.
DimitriProsser gravatar imageDimitriProsser ( 2012-02-10 07:42:26 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2012-02-10 03:58:48 -0500

Seen: 3,539 times

Last updated: Feb 10 '12