[best practice][.srv] Mandatory return type?

Quality Assurance
1

I keep having to suggest adding a string field in ROS Service definition .srv so that Service server can communicate with the Service client about any undefined condition on Server side. I’ve come up with situations where developers noticed later that there’s no way to send error state to the client with the custom .srv.

I haven’t found discussion/sources about such a practice online yet.

  • Is it a good idea?
  • Is there any downside in doing so?

(Thought there’s a tag for best practice but I can’t find it.)

2

In ROS1, I usually recommend adding a uint return_code and string message to the response, while always return true from any service server - I’m pretty sure there’s no way to tell a communication failure from return false client-side.

ROS2 thankfully has no return false semantics from a service server, however that does make ros1_bridge a little… weird.

1 Like
3

I would definitely not recommend string as a return type. That would require you to be doing string comparisons and be highly fragile.

A return code with an error description or message that’s filled if there’s an error might make sense. However again the description shouldn’t have anything happen to it but display it.

The response should be designed to encode whatever information is necessary for the client to respond appropriately. I don’t think that it would be valuable to try to necessarily enforce a uniform response recommendation. If you discover those sorts of shortcomings my recommendation is to extend the message. This process of learning while using is why we want non-trivial implementations and usage for messages before standardizing them so that we can catch these sorts of oversights.

1 Like
4

One option I’ve seen used is to have an enum in the message defining the possible error returns. It’s semantically more expressive than just a number and it’s not strings.

Ultimately though you have to accept that a ROS service is not as expressive as something like a local function call, where you can have a much more complex interface going as far as exceptions if necessary. OMG IDL defines similar capabilities for interfaces and it’s debatable whether it’s a good thing to try and get that level of capability over a remote interface.

5

For cross referencing: https://github.com/ros2/ros2/issues/921

6

Aren’t exceptions in ROS1 transferred to the service clients?

7

Yes, but not in ROS 2. And that is what the referenced issue is about.

1 Like
8

Thanks for discussion!

I verified this to happen, in ROS1.

To me, that’s the cleanest way to capture errors that happen on ROS Service server side. I just can’t find this behavior documented. To the minimum, I added a link to an old BestPractice page.

9

UPDATE:

  • Yes I verified for both server and client are rospy.
  • No, when server is rospy but client is roscpp, the client doesn’t seem to receive exception from the server.
1 Like