Suggestions for std_srvs

[tfoote]

Yes indeed it’s always a judgement call on a case by case basis.

But I’d like to highlight that there are two dimensions of semantic meaning encapsulated in the type and topic names. There is the semantic meaning of the type and the semantics of what is represented in the instance of the topic.

What I’ve been discussion above has been about the semantic meaning of the type. Such that anything with the same semantic meaning should be interchangeable. This is Image vs PointCloud (both of which have used std_msgs MultiArray datatypes in the past in ROS), or simpler RelativeHumidity vs Illuminance

These messages have very similar data structure, but have very different meanings. It is an error to feed an illuminance signal into something that is processing the humidity.

The second level mentioned is the semantic meaning of the instance which we recommend be captured by the topic name. /left_camera/image vs /right_camera/image These are both images with the same type and can both be run through any image processing pipeline. And you can still get bad behavior by feeding left camera data to both sides of a stereo module. But the system knows that it’s invalid to feed a PointCloud into the input of a stereo image.

@heppner

This is especially important when thinking about one of the main strong points of ROS (in my opinion): The strong emphasis on interconnecting different parts of an application together without having to couple them specifically. When I use newly defined topics and services for that, I loose some of the flexibility I otherwise have when using just the generic types of std_msgs. Instead of having two packages perfectly on their own ( of course they are not on their own as they referr to std_msgs or std_srvs but as they will be present on every ros system it is basically the same as having no specific dependency), I will need to either have one as the dependency of the other or create a third, just to define the communication type.

I agree that interconnectability is one of the values that ROS provides. But this value is actually provided by not taking the shortcuts you mentioned and “missusing” messages. By having the carefully defined datatypes that are fully self contained and have semantic meaning, a modules interface can be defined basically by the types and you know that if you have a matching typed publisher you can hook it up and it will process the data.

I’ve seen many systems where if you use loosely defined datatypes, or missuse defined datatypes, you get modules that theoretically have the same information but they’ve diverged in their representation and can no longer function correctly due to the diverged use of the message. Which then breaks the whole introspection system as well as the interface definitions.