exploration stack issues

asked 2012-07-26 00:13:20 -0500

cemkyg
21 ●1 ●2 ●3

Hello, I'm Cem and fairly new to ROS. I've been trying to get turtlebot to do mapping on gazebo environment. I somehow managed to make things work however there are several major issues which makes the whole process painfully slow.

First one is inconsistencies between the maps generated by gmapping and explore, as demonstrated in these pictures: http://imgur.com/a/lESsv (You should zoom in a little bit to see the path)

First picture is obtained from the map made by explore node. The plan looks valid, but as we take a glance to the second map, the plan is made to an occupied grid cell. Second one is in the same order as the first. This time the endpoint isn't at an occupied grid cell but very close to one. It looks like robot won't execute the plan as long as the plan is made through or to an occupied or unknown grid cell.

In my opinion this behaviour is due to difference between sources used by planner and by the node which executes the plan. The planner makes the plans by using the map (or costmap, I don't know) created by explore node, yet the navigating one verifies and executes them by using the map generated by gmapping.

Second one is, when the robot enters a very large area, planner fails to come up with a new plan(or takes very long time). Check this: http://i.imgur.com/a8N6v.png

How can I solve these problems?

Map generated by explore looks very distorted. How can I make it more appropriate?

Also; If you see something wrong here, please let me know. I've been working with ROS for just 3 weeks without supervision or reference, someone with experience is only thing I need now.

edit retag flag offensive close merge delete

add a comment

2

answered 2012-08-01 22:54:00 -0500

Roy89
131 ●5 ●6 ●13

I have been playing around with this problem for a while and I think I managed to get a solution. You need to delete all observation sources for just the explore cost map. Make a new local_costmap_params.yaml file with no observation sources and include this with just the explore cost map.

I created the new files costmap_explore_params.yaml and explore_costmap.yaml which are different to the settings used for the navigation costmaps.

explore_costmap_params.yaml

map_type: voxel origin_z: 0.0 z_resolution: 0.2 z_voxels: 10 unknown_threshold: 9 mark_threshold: 0 transform_tolerance: 0.3 obstacle_range: 2.5 max_obstacle_height: 2.0 raytrace_range: 3.0 footprint: [[-0.325, -0.325], [-0.325, 0.325], [0.325, 0.325], [0.46, 0.0], [0.325, -0.325]] footprint_padding: 0.01 inflation_radius: 0.55 cost_scaling_factor: 10.0 lethal_cost_threshold: 100

In the explore_costmap.yaml file you need to set static_map to true (so it will subscribe to the map topic created by gmapping), track_unknown_space to true and set unknown_cost_value as 255. explore_costmap.yaml

explore_costmap: publish_voxel_map: true global_frame: /map robot_base_frame: base_link update_frequency: 0.5 publish_frequency: 1.0 raytrace_range: 10.0 obstacle_range: 5.0 static_map: true rolling_window: false width: 100.0 height: 100.0 resolution: 0.1 origin_x: 0.0 origin_y: 0.0 track_unknown_space: true unknown_cost_value: 255 transform_tolerance: 0.5

With these settings explore will only create a costmap from the map created with gmapping. Since now the map used for navigation and the cost map in explore used for setting goals are the same the navigation stack has much more success at reaching the goals set for it.

edit flag offensive delete link

Comments

I know this post is rather old, but could you please clarify what you've done? I find the above quite confusing.

Zayin ( 2013-05-30 09:34:06 -0500 )edit

add a comment

1

answered 2012-07-27 04:23:02 -0500

phil0stine
682 ●15 ●24 ●33

I can't speak to the issue of planning in a large area, but the first issue you raise is a good one. You have hit on the problem with explore using its internal costmap while gmapping is creating and correcting its own.

So, explore generates a goal by looking at what the planner cost would be using its internal map (among other costs), but I think move_base is trying to plan using the gmapping map. If the goal sent using the explore map is unachievable in the gmapping map, then you will have a planner failure.

Ideally, you would want SLAM corrections to propogate back to the explore node so that everything is consistent in goal generation and path planning.

I haven't tested how this would work (yet), but I think if you subscribe to an OccupancyGrid message (/map), you can create/update a Costmap2DROS map, and update the explore costmap on the fly.

edit flag offensive delete link

Comments

As far as I know the explore package is used as de-facto exploration package, I'd expect it to contain few bugs here and there but a major flaw which endured this far doesn't sound logical. I think I am doing something wrong here but nevertheless can you elaborate your solution idea further?

cemkyg ( 2012-07-29 22:43:28 -0500 )edit

you can check for yourself if you step through the code. the explore node is creating its own internal map, separate from the gmapping map,but explore itself is not doing any sort of SLAM, the "loop-closing" portion of the code is for looking for places where a SLAM process might do a correction

phil0stine ( 2012-07-30 04:23:57 -0500 )edit

So, if explore keeps its own map that is based off local sensor data for an estimated pose, and then suddenly that pose (and map itself) changes due to a SLAM correction in gmapping, where does the actual explore map get updated?

phil0stine ( 2012-07-30 04:24:39 -0500 )edit

Just want to emphasize, I am not knocking explore here, in fact weve used it with success, but that doesn't mean it couldn't be improved.

phil0stine ( 2012-07-30 04:25:28 -0500 )edit

add a comment

exploration stack issues

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

exploration stack issues edit

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

exploration stack issues