Weird behavior when instantiating SimpleActionClient right after initializing node in rospy

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

Chris Bersch
21 ●1 ●1 ●3

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 flag offensive close merge delete

Comments

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

add a comment

1

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

mmwise

8372 ●45 ●74 ●99 http://www.meloneewise.com/

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

add a comment

0

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

Daniel Pinyol
41 ●7 ●9 ●10

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

add a comment

0

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

stfn
287 ●10 ●19 ●24

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.

edit flag offensive delete link

Comments

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.

gvdhoorn ( 2019-03-30 02:27:50 -0600 )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 ( 2019-03-30 06:42:27 -0600 )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 ( 2019-03-31 02:20:29 -0600 )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... .

stfn ( 2019-05-20 07:58:27 -0600 )edit

add a comment