Service buffer overrun only when service is persistent
I'm using a rospy service call to a custom c++ gazebo library. Ever time this service is called, gazebo takes a certain number of simulation steps, and responds with the new sensor measurements. I'm running many trials, so I'd like to run this as quickly as possible, so I started using persistent connections.
rospy.wait_for_service('step_service')
self.step_service = rospy.ServiceProxy('step_service', ActionService, True)
action = np.zeros((12,1))
self.state = self.step_service(action)
and my cpp service server is:
step_service = rosnode->advertiseService("/step_service", &GazeboRosStepper::step_srv, this);
bool GazeboRosStepper::step_srv(gazebo_ros_stepper::ActionService::Request &req, gazebo_ros_stepper::ActionService::Response &res)
{
step
fill response with joint angles, velocities (24 doubles)
return true
}
When the step_service in the python code is persistent, I get the errors:
rospy.service.ServiceException: service [/step_service] responded with an error: b'Buffer Overrun'
This is no matter the size of my response (I commented out most of the response, still errors) or the size of my request. It also happens during the first call.
Everything works perfectly when things are not persistent. However, since I'm calling this as fast as possible, I'd like to remove the wasted computation for resetting the TCP connection every time.
How fast are you calling the service? Does the node have time to wait for a Service result and does it actually
spin
? Or are you, like, calling the Service in a single run of your script a hundred times without anyspin
ing?I do not call spin! This makes sense now. I'm surprised it worked without the persistent call.
Also: Doesn't a service call block? So it would always wait for a response (I may have misunderstood you)
Since rospy doesn't have a spinOnce function, how would you recommend I tackle this?
Well, you are right, service calls are blocking. Also, I just found the following on the wiki
So the spin in the calling node is not ...
required. But in the service server, you still need it, IMO, but there
spin
is ok.It is strange though, that it seems to work without the persistent connection. But this could be a side-effect of re-creating the connection, and, in that course, delivering the message. But this is just a guess...