Global Costmap Detects Obstacle When None is there

asked 2020-01-16 20:47:01 -0600

Orl gravatar image

updated 2020-01-20 01:13:51 -0600

I'm running Cartographer on ROS Kinetic on Ubuntu 16.04 using an rplidar as my sensor source. When SLAM is started, everything look normal and clean as shown in the image below. image1

However as the robot moves throughout the environment, I can see small spots, some of which I have highlighted with a red circle , of the Global Costmap that has not been cleared out. This is quite a big issue as it will affect navigation. The path planner will try to avoid these small remnants of the global costmap and also if a navigation goal is set on top of one of these remnants, it will fail. image2

Here's my global costmap config file:

global_costmap:
  ## Plugins ##
  plugins:
    - {name: "static_layer",    type: "costmap_2d::StaticLayer"}
    - {name: "obstacle_layer",  type: "costmap_2d::ObstacleLayer"}
    - {name: "inflation_layer", type: "costmap_2d::InflationLayer"}
  ## Coordinate frame and tf parameters ##
  global_frame:         "map"
  robot_base_frame:     "base_footprint"
  transform_tolerance:  0.5
  ## Rate parameters ##
  update_frequency:     1.0
  publish_frequency:    0.5
  ## Map management parameters ##
  static_map:           true
  rolling_window:       false
  origin_x:             0.0
  origin_y:             0.0
  width:                10.0
  height:               10.0
  ## Map type parameters ##
  map_type:             "costmap"
  ### ObstacleCostmapPlugin parameters ###
  track_unknown_space:  true
  footprint_clearing_enabled: true
### Obstacle Layer ###
# ref. http://wiki.ros.org/costmap_2d/hydro/obstacles
  obstacle_layer:
    ## Sensor management parameters ##
    observation_sources:  "lidar"
    lidar:
     topic:              "/scan_filtered" #scan
      sensor_frame:       "base_scan" #lidar_frame
      observation_persistence: 0.0
      expected_update_rate: 0.3   # 0.15 == 6.66 Hz for RPLiDAR
      data_type:          "LaserScan"
      clearing:           true
      marking:            true
      max_obstacle_height: 0.4    # RPLiDAR height is 0.35
      min_obstacle_height: 0.2
      obstacle_range:     5.5     # RPLiDAR effective range is 5.5
      raytrace_range:     8.0     # RPLiDAR max range is 8.0
      inf_is_valid:       true
    ## Global Filtering Parameters ##
    max_obstacle_height:  1.0     # Orbbec-Astra height is 1.3
    obstacle_range:       5.5     # maximum range to insert obstacles into the costmap using sensor data
    raytrace_range:       8.0     # maximum range to raytrace out obstacles from the map using sensor data
    ## Misc ##
    enabled:              true
    combination_method:   1       # 1 - maximun
### Static Layer ###
# ref. http://wiki.ros.org/costmap_2d/hydro/staticmap
  static_layer:
    unknown_cost_value:         255
    lethal_cost_threshold:      100
    map_topic:                  "map"
    first_map_only:             false
    subscribe_to_updates:       false
    track_unknown_space:        true
    use_maximum:                false
    trinary_costmap:            false
    ## Misc ##
    enabled:                    true

Any ideas on how to resolve such an issue?

edit retag flag offensive close merge delete

Comments

Is that from a map or a costmap? That color scheme implies its a from the costmap, not your cartographer map, unless you're using the costmap coloring for your map-map.

stevemacenski gravatar imagestevemacenski ( 2020-01-16 22:16:00 -0600 )edit

@stevemacenski That's right, it's coming from the global costmap. However it should not be there because there are no obstacles in that area.

Orl gravatar imageOrl ( 2020-01-16 23:18:47 -0600 )edit

@Orl what sensor do you use? Given how frequently costmap_2d is used in such a use case I doubt that it is a bug. Please share your costmap configuration and, if possible, a bagfile with the sensor data where your issue appears.

mgruhler gravatar imagemgruhler ( 2020-01-17 00:50:48 -0600 )edit

@mgruhler I'm using an rplidar as my data source. I've updated the issue by including the global costmap config file. A bagfile is currently unavailable. I'm hoping you can find something in the config file. Thanks.

Orl gravatar imageOrl ( 2020-01-17 01:35:11 -0600 )edit

Please don't add a link to a Google Drive or something. This file will go away at some point and one cannot refer to it anymore. Also, it is not searchable. Please edit your question again and paste the relevant content (i.e. get rid of any unnecessary comments) and format the pasted file with the preformatted text button (the on with 1010101 on it)... Thanks

mgruhler gravatar imagemgruhler ( 2020-01-17 04:58:24 -0600 )edit

@mgruhler Thanks for the suggestion. I edited the question. Appreciate the help.

Orl gravatar imageOrl ( 2020-01-20 01:14:30 -0600 )edit

Alright, more questions (having a bagfile where the issue is shown would really help :-) )

  • Where do the "ghost readings" appear? At max range of the LiDAR? Or anywhere in between?
  • Have you checked if there are actually readings in the scan message at those spots?
  • Do those readings also occur in the local costmap or exclusively in the global one?
  • What is the behavior of the LiDAR "shooting in the air" (I don't have an RPLiDAR at hand to test), 0, max_range, inf?
mgruhler gravatar imagemgruhler ( 2020-01-20 06:32:53 -0600 )edit

@mgruhler (Sorry a bagfile is currently unavailable.)

  • The "ghost readings " appear anywhere in between as shown in the second image highlighted with a few red circles. I do not know why the global costmap puts that there.

  • The scan messages are highlighted as green dots around the borders of the map or obstacles. From rviz I see no laser scan data at those spots.

  • The lidar basically measures the distance to any obstacles it encounters. We ignore any readings within a 23 cm radius of the robot and we accept the rest as far as 8 m. Anything over 8 m will also be ignored.

Orl gravatar imageOrl ( 2020-01-20 23:43:16 -0600 )edit