Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

actionlib ABORTED status "sticks" between goals

Hello,

I am using the move_base action server and the SimpleActionClient (Python) to send a series of navigation goals to my robot. At the moment I am doing this in simulation, not on the real robot. My setup is Ubuntu 12.04 and ROS Groovy Debian install.

The problem I am having is that when a navigation goal is aborted because the goal cannot be reached, the next goal location in the list is also aborted even though it is perfectly reachable. It's as if the first ABORTED status "sticks" long enough to get attached to the next goal. Is there something I have to do after an aborted goal to clear the status? I've already tried cancel_goal() and cancel_all_goals() after a goal is aborted but it does not change the behavior.

Thanks,
patrick

actionlib ABORTED status "sticks" between goals

Hello,

I am using the move_base action server and the SimpleActionClient (Python) to send a series of navigation goals to my robot. At the moment I am doing this in simulation, not on the real robot. My setup is Ubuntu 12.04 and ROS Groovy Debian install.

The problem I am having is that when a navigation goal is aborted because the goal cannot be reached, the next goal location in the list is also aborted even though it is perfectly reachable. It's as if the first ABORTED status "sticks" long enough to get attached to the next goal. Is there something I have to do after an aborted goal to clear the status? I've already tried cancel_goal() and cancel_all_goals() after a goal is aborted but it does not change the behavior.

Thanks,
patrick

UPDATE:

The following setup reproduces the problem 100% of the time. The nav_abort_test.py script moves the robot continually through 4 waypoints. The third waypoint is set right in the middle of an obstacle on the map so move_base has to abort. However, it then aborts on the next waypoint as well.

To reproduce the setup, follow these steps:

$ cd ~/ros_workspace
$ git clone https://github.com/pirobot/rbx1.git
$ rosmake rbx1
$ roslaunch rbx1_bringup fake_turtlebot.launch
$ roslaunch rbx1_nav fake_move_base_obstacle.launch
$ rosrun rviz rviz -d `rospack find rbx1_nav`/nav.rviz
$ rosrun rbx1_nav nav_abort_test.py

If you don't want to run all the steps above, the script can be found here and the obstacle map can be found here. The navigation params for the fake Turtlebot can be found here.

actionlib ABORTED status "sticks" between goals

Hello,

I am using the move_base action server and the SimpleActionClient (Python) to send a series of navigation goals to my robot. At the moment I am doing this in simulation, not on the real robot. My setup is Ubuntu 12.04 and ROS Groovy Debian install.

The problem I am having is that when a navigation goal is aborted because the goal cannot be reached, the next goal location in the list is also aborted even though it is perfectly reachable. It's as if the first ABORTED status "sticks" long enough to get attached to the next goal. Is there something I have to do after an aborted goal to clear the status? I've already tried cancel_goal() and cancel_all_goals() after a goal is aborted but it does not change the behavior.

Thanks,
patrick

UPDATE:

The following setup reproduces the problem 100% of the time. The nav_abort_test.py script moves the robot continually through 4 waypoints. The third waypoint is set right in the middle of an obstacle on the map so move_base has to abort. However, it then aborts on the next waypoint as well.

To reproduce the setup, follow these steps:

$ cd ~/ros_workspace
$ git clone https://github.com/pirobot/rbx1.git
$ rosmake rbx1
$ roslaunch rbx1_bringup fake_turtlebot.launch
$ roslaunch rbx1_nav fake_move_base_obstacle.launch
$ rosrun rviz rviz -d `rospack find rbx1_nav`/nav.rviz
$ rosrun rbx1_nav nav_abort_test.py

If you don't want to run all the steps above, the script can be found here and the obstacle map can be found here. The navigation params for the fake Turtlebot can be found here.

actionlib ABORTED status "sticks" between goals

Hello,

I am using the move_base action server and the SimpleActionClient (Python) to send a series of navigation goals to my robot. At the moment I am doing this in simulation, not on the real robot. My setup is Ubuntu 12.04 and ROS Groovy Debian install.

The problem I am having is that when a navigation goal is aborted because the goal cannot be reached, the next goal location in the list is also aborted even though it is perfectly reachable. It's as if the first ABORTED status "sticks" long enough to get attached to the next goal. Is there something I have to do after an aborted goal to clear the status? I've already tried cancel_goal() and cancel_all_goals() after a goal is aborted but it does not change the behavior.

Thanks,
patrick

UPDATE:

The following setup reproduces the problem 100% of the time. The nav_abort_test.py script moves the robot continually through 4 waypoints. The third waypoint is set right in the middle of an obstacle on the map so move_base has to abort. However, it then aborts on the next waypoint as well.

To reproduce the setup, follow these steps:

 $ cd ~/ros_workspace
 $ git clone https://github.com/pirobot/rbx1.git
 $ rosmake rbx1
 $ roslaunch rbx1_bringup fake_turtlebot.launch
 $ roslaunch rbx1_nav fake_move_base_obstacle.launch
 $ rosrun rviz rviz -d `rospack find rbx1_nav`/nav.rviz
 $ rosrun rbx1_nav nav_abort_test.py

If you don't want to run all the steps above, the script can be found here and the obstacle map can be found here. The navigation params for the fake Turtlebot can be found here.

actionlib ABORTED status "sticks" between goals

Hello,

I am using the move_base action server and the SimpleActionClient (Python) to send a series of navigation goals to my robot. At the moment I am doing this in simulation, not on the real robot. My setup is Ubuntu 12.04 and ROS Groovy Debian install.

The problem I am having is that when a navigation goal is aborted because the goal cannot be reached, the next goal location in the list is also aborted even though it is perfectly reachable. It's as if the first ABORTED status "sticks" long enough to get attached to the next goal. Is there something I have to do after an aborted goal to clear the status? I've already tried cancel_goal() and cancel_all_goals() after a goal is aborted but it does not change the behavior.

Thanks,
patrick

UPDATE:

The following setup reproduces the problem 100% of the time. The nav_abort_test.py script moves the robot continually through 4 waypoints. The third waypoint is set right in the middle of an obstacle on the map so move_base has to abort. However, it then aborts on the next waypoint as well.well even though that waypoint is perfectly reachable which can be proved by commenting the third waypoint out of the script.

To reproduce the setup, follow these steps:

 $ cd ~/ros_workspace
 $ git clone https://github.com/pirobot/rbx1.git
 $ rosmake rbx1
 $ roslaunch rbx1_bringup fake_turtlebot.launch
 $ roslaunch rbx1_nav fake_move_base_obstacle.launch
 $ rosrun rviz rviz -d `rospack find rbx1_nav`/nav.rviz
 $ rosrun rbx1_nav nav_abort_test.py

If you don't want to run all the steps above, the script can be found here and the obstacle map can be found here. The navigation params for the fake Turtlebot can be found here.

actionlib ABORTED status "sticks" between goals

Hello,

I am using the move_base action server and the SimpleActionClient (Python) to send a series of navigation goals to my robot. At the moment I am doing this in simulation, not on the real robot. My setup is Ubuntu 12.04 and ROS Groovy Debian install.

The problem I am having is that when a navigation goal is aborted because the goal cannot be reached, the next goal location in the list is also aborted even though it is perfectly reachable. It's as if the first ABORTED status "sticks" long enough to get attached to the next goal. Is there something I have to do after an aborted goal to clear the status? I've already tried cancel_goal() and cancel_all_goals() after a goal is aborted but it does not change the behavior.

Thanks,
patrick

UPDATE:

The following setup reproduces the problem 100% of the time. The nav_abort_test.py script moves the robot continually through 4 waypoints. The third waypoint is set right in the middle of an obstacle on the map so move_base has to abort. However, it then aborts on the next waypoint as well even though that waypoint is perfectly reachable which can be proved by commenting the third waypoint out of the script.

To reproduce the setup, follow these steps:

 $ cd ~/ros_workspace
 $ git clone https://github.com/pirobot/rbx1.git
 $ rosmake rbx1
 $ roslaunch rbx1_bringup fake_turtlebot.launch
 $ roslaunch rbx1_nav fake_move_base_obstacle.launch
 $ rosrun rviz rviz -d `rospack find rbx1_nav`/nav.rviz
 $ rosrun rbx1_nav nav_abort_test.py

If you don't want to run all the steps above, the test script can be found here and the obstacle map can be found here. The navigation params for the fake Turtlebot can be found here.