Frontier blacklist

[hiddewie]

Use case

Exploration of an unknown area. There are many different locations with frontiers. After a while a frontier is chosen but it is momentarily blocked by an obstacle. move_base cannot find a valid path. frontier_exploration is notified of the movement failure and aborts all exploration.

Problem

In case of movement failure all exploration is aborted, even though other explorable frontiers might still be available.

Solution

I have solved this problem by implementing a blacklist of points, and a blacklist radius. The points describe the center of circles with the defined radius, together forming a blocked area where no frontiers may be chosen for exploration.

The blacklist is cleared once a frontier has been reached successfully. This allows returning to previously obstructed frontier points.

The exploration now finishes if either all points are explored, or the frontier list only contains blacklisted points.

---

Implementation details / comments

• This introduces 2 new parameters for the bounded explore layer: the global frame (global_frame, default "map") and the blacklist radius (blacklist_radius, default 1.0).
• Two new services are introduced for the bounded explore layer: blacklist_point (frontier_exploration::BlacklistPoint) and clear_blacklist (std_srvs::Empty)
• The Frontier message now only contains a single travel point, depending on the chosen value for frontier_travel_point.
• The value frontier_travel_point is now used in FrontierSearch::buildNewFrontier rather than the explore layer.
• The blacklist is visualized in rviz by using visualization_msgs::Marker cilinders with small height. Screenshot of blacklisted exploration points:

[dagarzonr]

Hello! I used the blaclist-frontier-pr in my own platform. It solved the issue of continuous aborting, many thanks!

I added a couple of lines for returning the robot to the starting point, nevertheless I did it in a non-elegant way and with the risk of aborting if none path is found or if the robot is stuck.

@hiddewie, could you please consider adding this functionality inside the explore_server? The approach used in the blacklist would allow taking some action if the robot has a problem while it's trying to achieve the starting point.

I apologize if it is not the right place for writing my request.

Best regards,

David

[hiddewie]

Hello @dagarzonr,

Thank you for the positive comment. It is great that the submitted code is useful for other users.

Although I think your functionality has merit (I've also implemented a similar thing on the platform I am using), this package is not the correct place to implement that feature.

Personally I have created an extra ROS node, the initializer. I let the initializer call the actionlib service of frontier_exploration to start exploring the environment until no new frontiers can be found. Furthermore, once the service returns with either a success or a failure, I call the actionlib service of move_base to return the platform to its initial position.

I think the idea of ROS is to create nodes that perform a single task, and perform it well. Returning to the initial position is not a part of an exploration task and my opinion is that it should not be implemented in this package for that reason.

Kind regards, Hidde

[paulbovbel]

@hiddewie thanks for this interesting contribution (and the min_frontier_size). I haven't looked at frontier_exploration in a while (though I've come back to it to try a rewrite several times).

In general this looks good to me, although sometime in the near future I'd like to update this package to be a little more architecturally sane. It makes sense to include a supervisory component that gets frontier locations, issues move base goals, and deals with error conditions (such as keeping track of a frontier blacklist of failed move_base goals).

Anyways, please rebase your changes against the lunar-devel branch, and I think this should be safe to merge.

[hiddewie]

Thank you for the positive comment. I have rebased it against the lunar-devel branch.

Feel free to edit the code for your major refactor of the package.