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

Occasional service call failure

asked 2011-08-27 06:18:01 -0600

SL Remy gravatar image

updated 2012-03-01 20:49:04 -0600

kwc gravatar image

There are some times that one of my service clients fails to get a response when it calls the service.
Are there any approaches or tools that can help my understanding of why this occasional failure occurs?

Both the server and client were written referring to the tutorials. They are run on the same machine and I was making calls at about 50Hz (a third node drives service calls between the client and the server and that node sends messages at 50Hz)

The error message I get is the "Failed to call the SensorService" until I abort the nodes. The messages always show up from the beginning, if they do show up. (Lending support to a start up issue, although one would think that eventually the service provider would start responding to service calls)

I reduced the loop rate to 10Hz and I haven't noticed a failed call in a while (but remember, it was occasional even at the higher loop rate). I did not use a persistent call. I just restart the launch file (a couple of times).

if (SensorClient_.call(SensorService))
{
    //Let the world know
    ROS_INFO("I called the SensorService!");
}
else
{
    ROS_ERROR("Failed to call the SensorService");
}
edit retag flag offensive close merge delete

Comments

Can you give a little more information? Did you write the server? Is the server running on the same computer as the client?
Lorenz gravatar image Lorenz  ( 2011-08-29 02:23:32 -0600 )edit
Likewise, can you edit your question and list the actual errors you receive from the service when the call fails? Also, how fast are you hitting the service? Like once a second, 50 times per second, once in awhile? You might get better results with a persistent service connection. I use a service to update the speed of my servos 20 times per second. At that rate, I can get connection failures to the service provider even when they are running on the same computer. However, when I make the service persistent, the errors go away. Persistent services using Python are described here (http://www.ros.org/wiki/rospy/Overview/Services#Persistent_connections) and for C++ look here (http://www.ros.org/wiki/roscpp/Overview/Services#Persistent_Connections).
Pi Robot gravatar image Pi Robot  ( 2011-08-29 03:05:37 -0600 )edit
+1 for persistent connections; service calls are fairly expensive, and persistence helps a lot.
Mac gravatar image Mac  ( 2011-09-02 12:18:20 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2011-09-12 04:43:48 -0600

Wim gravatar image

Likewise, can you edit your question and list the actual errors you receive from the service when the call fails? Also, how fast are you hitting the service? Like once a second, 50 times per second, once in awhile? You might get better results with a persistent service connection. I use a service to update the speed of my servos 20 times per second. At that rate, I can get connection failures to the service provider even when they are running on the same computer. However, when I make the service persistent, the errors go away. Persistent services using Python are described here (http://www.ros.org/wiki/rospy/Overview/Services#Persistent_connections) and for C++ look here (http://www.ros.org/wiki/roscpp/Overview/Services#Persistent_Connections). - Pi Robot

edit flag offensive delete link more
2

answered 2012-03-01 06:01:27 -0600

SL Remy gravatar image

The cause of the problem was a missing wait command: ros::service::waitForService("topic");

Because of this omission I caused a race hazard. Mischief managed.

Can this be added to C++ service client tutorial? (It's already in the python one.)

edit flag offensive delete link more

Comments

It's a wiki...

Mac gravatar image Mac  ( 2012-03-02 16:05:30 -0600 )edit

Question Tools

Stats

Asked: 2011-08-27 06:18:01 -0600

Seen: 5,236 times

Last updated: Mar 01 '12