Ask Your Question
0

Ghost obstacles on costmap

asked 2019-04-24 02:35:31 -0500

Getchbold NT gravatar image

updated 2019-05-02 21:32:08 -0500

Hi everyone,

Please give me some advices for this problem with ghost obstacles.

My mobile robot is working with ROS (Kinetic, Ubuntu 16.0.4) using Sick sensor. My robot uses 2 Sick sensor, one is in the right-upper corner and another one is in left-bottom corner. I use ira_laser_tools to merge data of these 2 laser scanners.

However, I am stucking at one problem: ghost obstacles appear on the costmap, and this ghost obstacle is relative to my mobile robot. If my robot moves, the ghost obstacle relatively follow. It causes mobile robot try to avoid obstacles even though there is no real obstacles.

I have tried to use some different laser-filter packages, but this problem still happen.

Can you please give me some suggestion ?

Thanks in advances


I took a video about my error (ghost obstacle) as in the link below:

https://www.youtube.com/watch?v=THt7o...

And, the picture within the indication for ghost obstacles here:

C:\fakepath\rplidar.png

And, the costmap configuration:

costmap_common_params:

footprint: [[0.44, 0.34], [0.44, -0.34], [-0.44, -0.34], [-0.44, 0.34] ]

footprint_padding: 0.0

transform_tolerance: 0.2
map_type: costmap

obstacle_layer:
 enabled: true
 obstacle_range: 1.5
 raytrace_range: 3.0
 inflation_radius: 0.2
 track_unknown_space: true
 combination_method: 1
 min_obstacle_height: 0.1
 max_obstacle_height: 0.5

 observation_sources: laser_scan_sensor
 laser_scan_sensor: {data_type: LaserScan, topic: scan, marking: true, clearing: true}


inflation_layer:
  enabled:              true
  cost_scaling_factor:  10.0  # exponential rate at which the obstacle cost drops off (default: 10)
  inflation_radius:     0.6 # max. distance from an obstacle at which costs are incurred for planning paths.

static_layer:
  enabled:              true
  map_topic:            "map"

rgbd_obstacle_layer:

  enabled:               true

  voxel_decay:           0.4     #seconds if linear, e^n if exponential

  decay_model:           0      #0=linear, 1=exponential, -1=persistent

  voxel_size:            0.05   #meters

  track_unknown_space:   true   #default space is unknown

  observation_persistence: 0.0  #seconds

  max_obstacle_height:   2.0    #meters

  unknown_threshold:     15     #voxel height

  mark_threshold:        0      #voxel height

  update_footprint_enabled: true

  combination_method:    1      #1=max, 0=override

  obstacle_range:        2.0    #meters

  origin_z:              0.0    #meters

  publish_voxel_map:     true   # default off

  transform_tolerance:   0.2    # seconds

  mapping_mode:          false  # default off, saves map not for navigation

  map_save_duration:     60     #default 60s, how often to autosave

  observation_sources:   rgbd1_clear rgbd1_mark rgbd2_clear rgbd2_mark

  rgbd1_mark:

    data_type: PointCloud2

    topic: cam_1/depth/color/points

    marking: true

    clearing: false

    min_obstacle_height: 0.15     #default 0, meters

    max_obstacle_height: 2.0     #defaule 3, meters

    expected_update_rate: 0    #default 0, if not updating at this rate at least, remove from buffer

    observation_persistence: 0.0 #default 0, use all measurements taken during now-value, 0=latest 

    inf_is_valid: false          #default false, for laser scans

    clear_after_reading: true    #default false, clear the buffer after the layer gets readings from it

    voxel_filter: true           #default off, apply voxel filter to sensor, recommend on 

  rgbd1_clear:

 data_type: PointCloud2

    topic: cam_1/depth/color/points

    marking: false

    clearing: true

    min_z: 0.1                   #default 0, meters

    max_z: 7.0                   #default 10, meters

    vertical_fov_angle: 0.7      #default 0.7, radians

    horizontal_fov_angle: 1.04   #default 1.04, radians

    decay_acceleration: 1.       #default 0, 1/s^2. If laser scanner MUST be 0

    model_type: 0                #default 0 (depth camera). Use 1 for 3D Lida ...
(more)
edit retag flag offensive close merge delete

Comments

I guess it would help to see an image of your problem, as well as a description of what is there "in the real world". Also, maybe share your costmap configuration. That the obstacle is moving with the robot is suggesting that it is continuously seen by the scanner. Can you verify this?

I've come across this in multiple scenarios:

  • self measurement of the robot
  • "ghost pixels" due to veiling effect (ScanShadowsFilter can help there)
  • bad configuration of obstacle_range and raytrace_range
  • discretization effects in the obstacle_layer

maybe it can be narrowed down to one of those?

mgruhler gravatar imagemgruhler ( 2019-04-24 04:30:21 -0500 )edit

Thank mgruhler so much for your quick help, I will prepare those kinds of data and update soon

Getchbold NT gravatar imageGetchbold NT ( 2019-04-24 05:11:43 -0500 )edit

@Getchbold NT: please attach your screenshot directly to the question. I've given you sufficient karma.

gvdhoorn gravatar imagegvdhoorn ( 2019-04-25 02:22:23 -0500 )edit

Thank you so much @gvdhoorn

Getchbold NT gravatar imageGetchbold NT ( 2019-04-25 02:28:51 -0500 )edit

I updated the video and picture about error and cost_map configuration @mgruhler

Getchbold NT gravatar imageGetchbold NT ( 2019-04-25 02:29:46 -0500 )edit

quite obviously, the laser scanner is actually measuring something there. So the costmap is actually doing what it is supposed to.

So you need to figure out where those readings are coming from.

  1. actual measurement: Remove what the LiDAR is seeing there (I know, obvious :-))
  2. self-measurement of the robot: mount the LiDAR differently or filter the ranges where you are hitting the robot with the laser beam
  3. veiling effect (i.e. hitting "edges" with one beam): judging from the image/video, this could actually be the case
  4. other effects, like strong reflection (mirror, glas?) could also lead to those readings.

If this is a problem that occurs that often, you might probably have to use a laser filter to get rid of those (single point) measurements. The ScanShadowsFilter can really help there.

What sensor are you using exactly?

mgruhler gravatar imagemgruhler ( 2019-04-25 03:00:47 -0500 )edit

@mgruhler thank you so much for your answer

I am using Sick sensor.

Our laboratory does not has mirror and glass.

This problem now always happen, I cannot know how to solve this problem. I am quite new with lidar sensor and laser filter. Can you please tell me clearly how to use ScanShadowsFilter to remove these single points?.

I can see this configuration of ScanShadowsFilter, but I do not actually whether this shadow_filter is called or not ?

scan_filter_chain:

  • name: shadows

    type: ScanShadowsFilter

    params:

    min_angle: 5

    max_angle: 175

    neighbors: 1

    window: 1

  • name: dark_shadows

    type: LaserScanIntensityFilter

    params:

    lower_threshold: 100

    upper_threshold: 50000

    disp_histogram: 0

The costmap configuration is used as default, I did not change anything

Thank you so much

Getchbold NT gravatar imageGetchbold NT ( 2019-04-25 03:13:17 -0500 )edit

Yes, a Sick sensor, but which model? LMSXXX? S300? S3000? MSR? Seeing that the scan is actually 360°, it is non of the former, but maybe an MSR?

There is a tutorial describing the ScanShadowsFilter. Then you obviously need to fix the remappings in the respective nodes. Please update your question (or post a new one) if you have troubles with setting this up...

mgruhler gravatar imagemgruhler ( 2019-04-25 04:50:26 -0500 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2019-05-03 04:22:57 -0500

Getchbold NT gravatar image

updated 2019-05-03 04:24:31 -0500

I have solved the problem. The reason is that the setting of angle_range and position of Sick sensor on the robot cause the laser beam hit the planes of robot. I solved this problem by reduce the angle_range (scan angular range). Since I am using 2 sensor at 2 corners of robot, so the angle_range is from -135 to 135 degree, I just changed to -130 to 130 degree. Or, later, locating the laser sensor a little bit far from current position to avoid collision between laser beam and robot's planes. Because the movement of robot is not smooth, robot fluctuates around the desired path. That's the reason. Thanks so much for all your help

edit flag offensive delete link more

Comments

1

So this would seem to be the first thing @mgruhler suggested in his first comment:

I've come across this in multiple scenarios:

  • self measurement of the robot

Perhaps you missed that?

gvdhoorn gravatar imagegvdhoorn ( 2019-05-03 04:45:29 -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

2 followers

Stats

Asked: 2019-04-24 02:35:31 -0500

Seen: 178 times

Last updated: May 02