ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

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

Hello,

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:

<launch>

    <!-- 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

            plugins: 

                - {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"}

            static:
                #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

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

            sensor:
                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:
                inflation_radius: 0.15
      </rosparam>
    </node>

</launch>

edit:

here's a link to some screenshots we took today with tf visualization overlayed. http://imgur.com/gallery/OrgbB

and here is the gist of our gmapping and move_base configuration https://gist.github.com/anonymous/b0e7aed627ef05d9a233

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted
1

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.

---EDIT

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

Comments

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
0

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

Question Tools

2 followers

Stats

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

Seen: 1,498 times

Last updated: Sep 19 '18