# Weird behavior when instantiating SimpleActionClient right after initializing node in rospy

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__':
rospy.init_node('test_manipulation')
#rospy.sleep(1.0)

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 " )
exit(1)


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.

Chris

edit retag 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.
( 2011-06-17 12:10:54 -0500 )edit

Sort by » oldest newest most voted

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.

more

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:
rospy.sleep(0.01)


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.

more

1

+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.

( 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.

( 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.

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

Turns out there already was a ticket for that: https://github.com/ros/actionlib/issu... . I re-opened this issue in https://github.com/ros/actionlib/issu... .

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

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.

more