Ask Your Question

frontier_exploration: frontiers inside robot footprint

asked 2014-11-27 09:36:08 -0600

e.mint27 gravatar image

updated 2014-12-01 06:48:03 -0600


we started working with the frontier_exploration ros package using gmapping and the navigation-stack on our robot (Volksbot RT6). Both (gmapping and the navigations stack) work fine as long as we use rviz to publish navigation goals. So we began to include the frontier_exploration package. We use the provided launch-file global_map.launch to run the package and only changed the topics and robot specific variables like the footprint and the baselink topic. The thing we don’t understand though is what the lines 15-29 are related to, are those map specific parameters?

When we used rviz to visualize the frontiers topic and we often have frontiers set inside the robots footprint. Since our robot is non-holonomic this often leads to oscillation of the robot and the move_base starts its recovery behaviours. Additional to that we often get the error message 'Could not find nearby clear cell to start search'.

We do have some screenshots of this but since we don’t have the karma points yet we can’t post them. I hope even without those it’s clear what we mean. We’d be glad for any suggestions how to resolve this problem.

Thank you in advance, Miria and Inga

Here is the launch file we use:


    <!-- Set to your sensor's range -->
    <arg name="sensor_range" default="1.0"/>

    <node pkg="frontier_exploration" type="explore_client" name="explore_client" output="screen"/>

    <node pkg="frontier_exploration" type="explore_server" name="explore_server" output="screen" >

        <param name="frequency" type="double" value="2.0"/>
        <param name="goal_aliasing" type="double" value="$(arg sensor_range)"/>

        #All standard costmap_2d parameters as in move_base, other than BoundedExploreLayer
        <rosparam ns="explore_costmap" subst_value="true">
            footprint: [[0.36, -0.25], [-0.36, -0.25], [-0.36, 0.25],[0.36, 0.25],[0.51,0.09],[0.51,-0.09]]

            #!transform_tolerance: 0.5
            #update_frequency: 0.5
            #publish_frequency: 0.5

            #must match incoming static map
            global_frame: map
            robot_base_frame: base_footprint
            #resolution: 0.05-->

            rolling_window: true
            track_unknown_space: true


                - {name: static,           type: "costmap_2d::StaticLayer"}            
                - {name: explore_boundary, type: "frontier_exploration::BoundedExploreLayer"}
                #Can disable sensor layer if gmapping is fast enough to update scans
                - {name: sensor,           type: "costmap_2d::ObstacleLayer"}
                - {name: inflation,        type: "costmap_2d::InflationLayer"}

                #Can pull data from gmapping, map_server or a non-rolling costmap            
                map_topic: /map
                # map_topic: move_base/global_costmap/costmap   
                subscribe_to_updates: true

                resize_to_boundary: false
                frontier_travel_point: middle
                #set to false for gmapping, true if re-exploring a known area
                explore_clear_space: false

                observation_sources: laser
                laser: {data_type: LaserScan, clearing: true, marking: true, topic: scan_filtered, inf_is_valid: true, raytrace_range: $(arg sensor_range), obstacle_range: $(arg sensor_range)}

                inflation_radius: 0.15



here's a link to some screenshots we took today with tf visualization overlayed.

and here is the gist of our gmapping and move_base configuration

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted

answered 2014-11-28 10:20:45 -0600

paulbovbel gravatar image

updated 2014-12-05 12:27:05 -0600

Bumped your karma, you should be able to post links now, try putting the images up on imgur or similar.

Can you please retake the screenshots with tf visualization overlaid, something really funky is going on with your transforms/navigation setup. Also please post gists of your move_base and gmapping configuration.


Something really weird is going on with your configuration. I'm guessing that's move_base's costmap you're displaying, and not frontier_exploration's. Your frontier points (and thus the goals that are sent to move_base) should be directly on top of any detected frontiers, which are by definition edges between known and unknown space. From the images, it looks like they're being placed in very strange locations.

This might be because your odometry is poor, causing discrepencies between the local (laser data) and global (gmapping) frames. You could try using only gmapping data for exploration, taking out the laser stuff. You'll have to make sure gmapping pumps out map updates quickly enough, and potentially you'd have to lower the rate on frontier exploration.

A development goal for me may be to tie exploration updates to happen only when new data comes in from gmapping, but that's a specific use case.

edit flag offensive delete link more


thanks. we just added the screenshots and the gist. we hope that helps.

e.mint27 gravatar image e.mint27  ( 2014-12-01 06:49:11 -0600 )edit

answered 2018-09-19 11:02:19 -0600

li9i gravatar image

Hey I know it's four years too late but I came across the very same 'Could not find nearby clear cell to start search' error, and I wanted to add that, in my case, it had to do with the 'sensor_range' value in the 'frontier_exploration.launch' file.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2014-11-27 09:36:08 -0600

Seen: 1,035 times

Last updated: Sep 19 '18