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

Weird behavior when instantiating SimpleActionClient right after initializing node in rospy

asked 2011-06-17 05:14:21 -0500

Chris Bersch gravatar image

Hi all,

I ran into a problem when I ran python scripts where an actionlib action client is intantiated right after the node a the wait_for_server() function does not seem to work always properly (it just does not wait).

For example:

if __name__ == '__main__':

trajClient = actionlib.SimpleActionClient("r_arm_controller/joint_trajectory_action", pr2_controllers_msgs.msg.JointTrajectoryAction)

if not trajClient.wait_for_server(rospy.Duration(10.0)):
   rospy.logerr("Could not connect to actionserver " )

will return immediately, ie. it goes into the if branch and prints the "Could not connect to actionserver " error statement, even though I would expect it to wait 10s. If I uncomment rospy.sleep(1.0), everything works always as expected. Is there a more elegant solution to this?

It seems like it is not always reproducable, but I have seen it on happen on my machine and the PR2 running Diamondback and Lucid.


edit retag flag offensive close merge delete


file a ticket if you can find a way to reproduce it, I just tested out your code above and things seems to work fine.
mmwise gravatar image mmwise  ( 2011-06-17 12:10:54 -0500 )edit

3 Answers

Sort by ยป oldest newest most voted

answered 2011-09-02 12:06:08 -0500

mmwise gravatar image

file a ticket if you can find a way to reproduce it, I just tested out your code above and things seems to work fine.

edit flag offensive delete link more

answered 2011-10-24 03:14:14 -0500

Daniel Pinyol gravatar image

I have the same problem with c++ SimpleActionClient. A workaround is not specifying a duration to wait_for_server, but then it would get stuck if server is not ready.

I guess the problem is at ConnectionMonitor::waitForActionServerToStart. I also have diamondback and lucid. I'll try add traces to debug it.

edit flag offensive delete link more

answered 2019-03-29 19:20:01 -0500

stfn gravatar image

Well, almost a decade later, I also stumbled upon this. I tracked it down to time itself: wait_for_server () returns false immediately, when time is not yet initialized. I.e. rospy.get_time() returns 0. This fixes it (almost) without magic long sleep times:

while rospy.get_time() <= 0:

Its just a workaround, not a real fix. But I don't dare to file a PR and mess around with time itself. It miht have something todo with simulated time, i.e. /use_sim_time and a clock server.

edit flag offensive delete link more



+1 for finding a potential cause.

It would be greatly appreciated if you could follow @mmwise's suggestion and post an issue to the actionlibissue tracker documenting your findings. That would have much higher visibility than an answer on ROS Answers.

gvdhoorn gravatar image gvdhoorn  ( 2019-03-30 02:27:50 -0500 )edit

It seems that rospy.wait_for_service is robust against this time issue, while SimpleActionClient.wait_for_server is not. However, I'm not sure its really an action-server problem. Time is initialized in the very core. And I think it is reasonable to assume, for any ros-function, that time is initialized after rospy.init_node.

stfn gravatar image stfn  ( 2019-03-30 06:42:27 -0500 )edit

I'm not sure I understand your comment.

If SimpleActionClient.wait_for_server(..) is not robust against time changes or uninitialised time, that would be a problem and shoul be fixed.

Making assumptions in code about whether rospy.init_node(..) has been called is a bad practice.

gvdhoorn gravatar image gvdhoorn  ( 2019-03-31 02:20:29 -0500 )edit

Turns out there already was a ticket for that: . I re-opened this issue in .

stfn gravatar image stfn  ( 2019-05-20 07:58:27 -0500 )edit

Question Tools

1 follower


Asked: 2011-06-17 05:14:21 -0500

Seen: 540 times

Last updated: Mar 29 '19