Suggestions for std_srvs

21

I have a cautionary tale from the world of RT-Middleware, which has provided something similar to that requested since the dawn of time. I can see why it was done initially: Defining new types in RT-Middleware is quite difficult for most users. I’m sure the thinking was that providing these defaults based on common data types would make things easier for everyone. However, the result has been overwhelmingly negative. Nearly all users are using those generic data types, and instead of semantically structured data, we see things like people putting poses into arrays of floats. The result is that RT-Middleware components are nearly universally not reusable because none of them have compatible interfaces, the components are hard to understand, and debugging is a nightmare.

Do not underestimate the value of semantically typed topics and services, and type safety. You and I may use varying different names for our topics and services, but we know that if the type is the same, then we can make our nodes talk with a simple remapping. If we use generic topic and service types, then we have to read the documentation and understand how the type is being applied to be sure. The argument has been made that someone could fill in an image incorrectly, but that’s not a good argument: Such a node should be considered broken and fixed.

I think that not providing default topic and service for common data types encourages developers to think more about the interface of their node and encourages a higher level of reusability.

3 Likes
22

I liken the arguments here to the C versus C++ debate. I advise to check the Cpp2016 talk by Dan Saks on that topic, very enlightening.

TL;DR :
“I am used to C and it is simple to get things done. C++ is harder.”
=> C++ gives you better type checking which makes it harder to write incorrect code.

In short, yes default common message types are easy to use, but you lose the long term guarantee that a type system is supposed to give you. You surely don’t want to sending strings around even if it is easier.

So, taking the perspective of defining message types as the types we manipulate in our large distributed ROS computing systems, I would also vote for removing default common data types.

I would even go further, and remove (or do our best to avoid) implicit conversion, which initially caused lot of confusion for me :
std_msgs.Bool(true) is not a bool with value true.
It actually is a message that contain a field data.
That field data happens to be of type bool and contain the value true.
But one should not forget the field is not the message, and therefore their type are also very different.

In that same perspective I would encourage the community to find ways to improve the ROS message type definition system, so that people can rely on it because it guarantees that we write correct code, and not just merely “use” it, to “get things to work”.

Until we can get a sound type theory of messages implemented in ROS, with direct verifiable benefits for the user, and in a way that fit into the developer workflow without feeling like a hassle, there will be the temptation of “bypassing it”.

The list of potential application for a sound message typing system is long :

  • We could feasibly write test tools just based on message types, to ensure a node (or set of) is behaving as specified.
  • We could probably write provable specifications to ensure your overall system will work as we think it will, all based on message types.
  • We could write run time checker to shut down a node (and maybe restart it) as soon as it doesn’t behave as expected.
  • And much more I cant even think about right now…

We cannot do many things in ROS1. But without breaking backward compatibility, we still can :

  • emphasize the user should define his own message types, and not the std ones.
  • write test tools that verify if a node actually behave as expected when sending random data of the described type. If not it means either your node is buggy, our your message type is not defined properly. These should probably even be included in the same package as the message itself, and easy to use in some kind of basic testing…
  • actively look for ways to improve our message type system. We still have a long way to go:
>>> std_msgs.msg.Int8(2562342342342)
data: 2562342342342

BTW, Wouldnt that kind of topic deserve its own Category in Discourse ?

23

I agree with nearly all (maybe all?) of what @asmodehn said. The more well-defined a node’s interface is, the easier it is to do the useful things mentioned.

But, there are two potential problems. The first is that I think that there is a risk of going so far that we duplicate existing solutions (such as OMG’s IDL). Even if we fix the problems with a system such as IDL, the chance of introducing new ones of our own is high. The second is that such features would possibly be quite heavy.