0
$\begingroup$

Rosanswers logo

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.


Originally posted by rohan_k on ROS Answers with karma: 33 on 2012-02-10

Post score: 1


Original comments

Comment by rohan_k on 2012-02-10:
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?

Comment by rohan_k on 2012-02-10:
No, the obstacle is being detected about a metre away in the x direction

Comment by DimitriProsser on 2012-02-10:
Is the obstacle being detected at a height that's greater than 1 meter?

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by DimitriProsser with karma: 11163 on 2012-02-10

This answer was ACCEPTED on the original site

Post score: 4


Original comments

Comment by DimitriProsser on 2012-02-10:
It should register an obstacle in at x=1 y=0 z=-0.4 in the frame of the costmap, yes.

Comment by rohan_k on 2012-02-10:
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?

Comment by DimitriProsser on 2012-02-10:
The costmap map type is 2D only. That could be a problem for your application. I'm not sure; only you would know that.

Comment by rohan_k on 2012-02-10:
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)?

Comment by DimitriProsser on 2012-02-10:
Perhaps voxel maps require more than a single point in order to register an obstacle?

Comment by rohan_k on 2012-02-10:
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?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.