ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org
Ask Your Question
0

obstacles ignored when drawing costmap

asked 2018-07-17 03:27:44 -0500

arrinay gravatar image

updated 2018-07-17 06:30:56 -0500

Hi all.

I'm having trouble with the costmap in ROS. I'm using the obstacles costmap layer for updating my global costmap. However, some obstacles are ignored by my costmap. Points above the default 2m are never added as an obstacle. However, I did set the max_obstacle_height parameter to 60m. In the documentation it says "Setting this parameter to a value greater than the global max_obstacle_height parameter has no effect". I'm wondering what they mean with the global max_obstacle_height, since I can't find any documentation on a global max_obstacle_height. I did however add a max_obstacle_height parameter under "costmap" (next to the one in my obstacles layer), to no avail. This is not the only problem though, as sometimes even lower points are ignored, but only at very specific places. I added a picture to demonstrate the problem. There, the roof should be added as an obstacle on the costmap, but it doesn't happen (the building is ~10m high). The bottom corner also isn't added as an obstacle, even though it is well below the 2m.

Anyone who knows what could be the problem here?

Note: The point cloud is built up gradually. My UAV starts at the back of the building (left-ish in the picture). Only after a short period it moves beyond one of the corners, and adds the point cloud of the wall that is now visible. The first part is added perfectly, but the last part of the wall isn't. Also when I rotate my building, the same thing happens (the last part of the wall isn't added). I also think that the higher obstacles are even marking the costmap as "clear", instead of "unkown" - the exact opposite of what I need it to do.

Edit: It might be useful to add that I'm not using the full move_base package, but only the global_planner. I added the rqt_graph as well.

image description image description

My costmap parameters (output of "rosparam get /firefly_0/global_planner_node/"):

costmap:
  always_send_full_costmap: true
  footprint:
  - [-0.325, -0.325]
  - [-0.325, 0.325]
  - [0.325, 0.325]
  - [0.46, 0.0]
  - [0.325, -0.325]
  global_frame: /map
  height: 35
  inflation_radius: 1
  max_obstacle_height: 60.0
  obstacles:
    base_scan: {clearing: true, data_type: PointCloud2, inf_is_valid: true, marking: true,
      max_obstacle_height: 60.0, min_obstacle_height: 0.2, obstacle_range: 9.0, raytrace_range: 10.0,
      topic: rtabmap/cloud_map}
    observation_sources: base_scan
    transform_tolerance: 0.3
  origin_x: -17
  origin_y: -17
  plugins:
  - {name: obstacles, type: 'costmap_2d::ObstacleLayer'}
  - {name: inflation, type: 'costmap_2d::InflationLayer'}
  publish_frequency: 1.0
  resolution: 0.3
  robot_base_frame: /firefly_0/base_link
  track_unknown_space: true
  update_frequency: 5.0
  width: 35
edit retag flag offensive close merge delete

Comments

Having raytrace range greater than obstacle_range doesn't make sense, secondly I think it's because of your lidar setting, as obstacle information comes from lidar points, if lidar doesn't see roof as an obstacle, it won't show up on costmap.

Choco93 gravatar imageChoco93 ( 2018-07-17 04:54:21 -0500 )edit

I thought I'd read somewhere that the raytrace_range should be greater than obstacle_range, so that every obstacle which is added can also be cleared afterwards. The default values for these parameters also reflect that.

arrinay gravatar imagearrinay ( 2018-07-17 04:59:20 -0500 )edit

The obstacle information here comes from my point cloud. The map subscribes to rtabmap/cloud_map, which is the same point cloud which is displayed in the image.

arrinay gravatar imagearrinay ( 2018-07-17 05:01:36 -0500 )edit

that's computationally expensive and not very useful in most of the cases. Secondly if it is missing a corner or something, it simply means that lidar didn't see it. What is Orientation of lidar on UAV?

Choco93 gravatar imageChoco93 ( 2018-07-17 06:12:10 -0500 )edit

Is there a better approach to construct a global costmap then? In the end, it will always need the point cloud, no? And the sensor can certainly see it, since it constructed the point cloud in the first place. (It's not a lidar but a vi-sensor - but that shouldn't matter too much I think)

arrinay gravatar imagearrinay ( 2018-07-17 06:22:22 -0500 )edit

Yes, it needs pointcloud, source doesn't really matte. What is your end gaol with this?

Choco93 gravatar imageChoco93 ( 2018-07-17 06:40:16 -0500 )edit

The goal is to autonomously construct a cloud map. All of the logic seems to be working. The only thing lacking now is a well constructed costmap (so my UAV knows it cannot fly through the building).

arrinay gravatar imagearrinay ( 2018-07-17 06:56:25 -0500 )edit

I have tried cartographer and it works pretty well, maybe you can look into this as well or octomap.

Choco93 gravatar imageChoco93 ( 2018-07-17 07:01:48 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-07-17 10:34:22 -0500

David Lu gravatar image

There is a parameter in the obstacle layer's dynamic configuration that controls the max_obstacle_height for all the observation sources...that's the global one. You can also set it for the individual observation sources as documented.

edit flag offensive delete link more

Comments

This is, it should go in the obstacle namespace, not in the costmap one, right?

mgruhler gravatar imagemgruhler ( 2018-07-17 10:40:34 -0500 )edit

I think so.

David Lu gravatar imageDavid Lu ( 2018-07-17 10:59:39 -0500 )edit

I changed my parameters to also include max_obstacle_height in the obstacle namespace. This also didn't work. However, changing the raytrace_range and obstacle_range to a higher value did solve it. Is it possible the distance is calculated from a fixed frame?

arrinay gravatar imagearrinay ( 2018-07-18 02:51:21 -0500 )edit

The origin and points are projected into the global frame and then the XY distance is calculated there, I believe.

David Lu gravatar imageDavid Lu ( 2018-07-18 10:53:46 -0500 )edit

Okay, in that case it makes sense. I thought the obstacle range would be calculated from the base_link frame.

arrinay gravatar imagearrinay ( 2018-07-18 14:14:50 -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: 2018-07-17 03:27:44 -0500

Seen: 226 times

Last updated: Jul 17 '18