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

renweiros's profile - activity

2017-08-02 02:42:13 -0500 received badge  Famous Question (source)
2017-05-29 13:32:11 -0500 commented answer The frontier_exploration demo fails quickly because the robot can't move.

Due to the comment length limit, I have to split my response into two comments. To resolve or at least alleviate the iss

2017-05-29 13:29:16 -0500 commented answer The frontier_exploration demo fails quickly because the robot can't move.

Thank you for the pointer. Actually, I have tried the Husky frontier exploration demo given at http://wiki.ros.org/husky

2017-05-28 22:14:54 -0500 received badge  Famous Question (source)
2017-05-25 13:20:18 -0500 received badge  Student (source)
2017-05-25 13:19:53 -0500 received badge  Notable Question (source)
2017-05-03 14:35:39 -0500 received badge  Popular Question (source)
2017-04-28 21:32:20 -0500 commented answer Call a service at startup with a launch file

This also works under kinetic! Thank bhaskara for the answer:)

2017-04-19 13:46:41 -0500 received badge  Supporter (source)
2017-04-14 13:51:18 -0500 received badge  Notable Question (source)
2017-04-14 13:50:57 -0500 answered a question The frontier_exploration demo fails quickly because the robot can't move.

I found one possible cause for this issue. The footprint config in navigation_stage/move_base_config/costmap_common_params.yaml doesn't match the sample config in frontier_exploration/launch/global_map.launch.

The footprint config in costmap_common_params.yaml:

#The footprint of the robot and associated padding
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

The footprint config in global_map.launch:

footprint: [[0.1, 0.0], [0.0, 0.1], [-0.1, 0.0], [0.0, -0.1]]
robot_radius: 0.10

I tried changing the one in global_map.launch to match the one in costmap_common_params.yaml and started getting better results, i.e., the exploration won't fail quickly. But the exploration will often fail because the robot can't move, especially when it tries exploring a relatively large unknown area. Does anyone have any suggestion? Many thanks in advance.

2017-04-11 22:13:51 -0500 commented question Move_base can't find a valid plan,when use frontier_exploration

I am hitting the same issue when I run the frontier_exploration demo given at the wiki page:

http://wiki.ros.org/frontier_explorat...

2017-04-11 14:02:03 -0500 asked a question The frontier_exploration demo fails quickly because the robot can't move.

I followed the instructions given at the frontier_exploration wiki page:

http://wiki.ros.org/frontier_explorat...

roslaunch navigation_stage move_base_gmapping_5cm.launch
roslaunch navigation_stage move_base.xml
roslaunch frontier_exploration global_map.launch

After I specified an exploration region in rviz, the robot will start exploring but soon it will stops.

From the rviz and stage, I observed that the robot most of the times got stuck to some obstacle and failed to recover, but sometimes it was in a open space, not close to any obstacle, and still couldn't move.

In the frontier_exploration terminal, I always saw an error message:

[ERROR] [1491936923.242211778, 124.600000000]: Failed to move

In the move_base terminal, I saw a related error message when the robot got stuck:

[ERROR] [1491936126.596561945, 221.100000000]: Aborting because a valid plan could not be found. Even after executing all recovery behaviors

Has anyone else encounter a similar issue? Do I need to change some configurations/parameters of move_base and exploration_frontier? Any suggestion or help will be highly appreciated.

2017-04-11 13:07:35 -0500 received badge  Popular Question (source)
2017-03-01 01:45:29 -0500 received badge  Enthusiast
2017-02-19 04:45:05 -0500 asked a question Unknown publisher in the tf_monitor output for the turtlebot_gazebo demo.

Run the demo Explore the Gazebo world. Check the tf tree via rqt_tf_tree and obtain the output as below:

rqt_tf_tree output

You can see that the tf of base_footprint -> base_link is published by the node robot_state_publisher.

But "tf_monitor" shows "unknown_publisher" for base_footprint -> base_link.

RESULTS: for base_footprint to base_link
Chain is: base_link -> base_footprint
Net delay     avg = 1114.58: max = 1164.52

Frames:
Frame: base_footprint published by unknown_publisher Average Delay: 0.00476341 Max Delay: 0.02

All Broadcasters:
Node: unknown_publisher 124.051 Hz, Average Delay: 0.00459184 Max Delay: 0.02

Also in the tf tree drawn by "rosrun tf view_frames", there is no tf from base_footprint to base_link.

tf view_frames output

Also notice that compared with the rqt_tf_tree output, there are many other tfs missing in the view_frames output.

Is this a bug in tf_monitor and view_frames? Or some configurations in the demo are incorrect?