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

cob_script_server always results in aborted

asked 2012-08-01 12:42:38 -0500

natbur gravatar image

updated 2012-08-01 12:47:12 -0500

I've been trying to interface with the COB_SCRIPT_SERVER but all of my attempts are generally resulting in an aborted state, although in Gazebo it's clear that the robot is completing the action. Even the included scripts are resulting in the same behaviour. For simplicity, I'm going to reference a run of one of the included scripts ros_script.py. I say generally, because about 10% of the time, the individual action will result in a success state. For example, the tray will reach down, but the arm will abort, or vice versa. I've experienced this on both machines I've used for development. I'm not sure if I'm missing a step during the installation, or if there is a bug that's preventing the script server from running properly.

Details below:
Version: Electric
Output:

nathan@Desktop:~$ rosrun cob_script_server ros_script.py
[INFO] [WallTime: 1343860413.922051] [0.000000] Start parsing...
[INFO] [WallTime: 1343860415.098590] [1813.232000] ...parsing finished
[INFO] [WallTime: 1343860416.166140] [1814.234000] Starting <<ros_script>> script...
[INFO] [WallTime: 1343860416.173912] [1814.238000] <<init>> <<tray>>
[INFO] [WallTime: 1343860416.177135] [1814.244000] Wait for <<tray>> to <<init>>...
[INFO] [WallTime: 1343860416.179207] [1814.247000] ...<<tray>> is <<init>>
[INFO] [WallTime: 1343860416.181657] [1814.247000] <<init>> <<torso>>
[INFO] [WallTime: 1343860416.184228] [1814.247000] Wait for <<torso>> to <<init>>...
[INFO] [WallTime: 1343860416.186081] [1814.247000] ...<<torso>> is <<init>>
[INFO] [WallTime: 1343860416.188504] [1814.250000] <<init>> <<arm>>
[INFO] [WallTime: 1343860416.197476] [1814.258000] Wait for <<arm>> to <<init>>...
[INFO] [WallTime: 1343860416.199323] [1814.260000] ...<<arm>> is <<init>>
[INFO] [WallTime: 1343860416.202449] [1814.265000] <<init>> <<sdh>>
[INFO] [WallTime: 1343860416.205368] [1814.270000] Wait for <<sdh>> to <<init>>...
[INFO] [WallTime: 1343860416.207662] [1814.275000] ...<<sdh>> is <<init>>
[INFO] [WallTime: 1343860416.216444] [1814.280000] Set light to <<red>>
[INFO] [WallTime: 1343860416.220778] [1814.284000] Move <<arm>> to <<folded>>
[INFO] [WallTime: 1343860416.493836] [1814.510000] Move <<torso>> to <<home>>
[INFO] [WallTime: 1343860416.732325] [1814.705000] Move <<sdh>> to <<home>>
[INFO] [WallTime: 1343860417.005013] [1814.980000] Move <<tray>> to <<down>>
[INFO] [WallTime: 1343860417.278968] [1815.216000] Wait for <<tray>> reaching <<down>>...
[ERROR] [WallTime: 1343860420.619813] [1818.026000] Got a result when we were already in the DONE state
[ERROR] [WallTime: 1343860420.910384] [1818.226000] Got a result when we were already in the DONE state
[ERROR] [WallTime: 1343860421.142359] [1818.403000] Got a result when we were already in the DONE state
[ERROR] [WallTime: 1343860421.273235] [1818.499000] ...<<tray>> could not reach <<down>>, aborting...
[WARN] [WallTime: 1343860421.273568] [1818.499000] Execution of <<arm>> to <<folded>> was aborted, wait not possible. Continuing...
[INFO] [WallTime: 1343860421.281221] [1818.501000] Move <<base>> to <<home>>
[ERROR] [WallTime: 1343860421.585754] [1818.728000] Got a result when we were already in the DONE state
[ERROR] [WallTime: 1343860427.967003] [1823.516000] /move_base action server not ready within timeout, aborting...
[INFO] [WallTime: 1343860427.975447] [1823.519000] Set light to <<green>>
[INFO] [WallTime: 1343860427.978389] [1823.524000] Wait for script to finish...
[INFO] [WallTime: 1343860427.978713] [1823.524000] ...script finished.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2012-08-01 20:13:21 -0500

weisshardt gravatar image

The problem you describe is not related to the cob_script_server but to the trajectory controller which is moving the components in gazebo. The script_server just forwards the action result which is returned by the actionlib interface to the gazebo controllers. So far I am not aware of a sulution solving this. If you want to investigate furhter you'd probably dive into cob_controller_configuration_gazebo.

edit flag offensive delete link more

Comments

Thanks for the help, at least now I know it's not something that I've done. I'll just work around it until I get a chance to run it on the physical robot

natbur gravatar image natbur  ( 2012-08-08 02:55:37 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2012-08-01 12:42:38 -0500

Seen: 379 times

Last updated: Aug 01 '12