I agree, that missusing messages and services is a tempting thing when prototyping software and it often doesn’t get replaced later on.
However, I like to see those very simple services kind of the same as c++ functions. If you take the setBool service for example. You would create a service called e.g. set_detection_enabled of type SetBool
In c++ you would create a function called set_detection_enabled which takes a bool as an argument.
Now you could create a custom service type, let’s name it SetDetectionEnabledStatus which has a boolean field called is_enabled. This is how I understand the counter-general-services position above.
Taken back to c++ terms I understand this as a typdef from bool to detection_enabled_status which doesn’t feel quite right to me.
As soon as I would pack something into a struct or class or enum in c++ I agree, that it does make sense to also define it’s own message type. This also fits together with Tully’s example that you could in theory use an image for a pointcloud, but you wouldn’t.
Another point is that everybody knows how to use these standard types. If we go back to my example and let’s say, we created a service called SetDetectionEnabledStatus, it’s not clear from the type which states are actually allowed. It could also contain an enum field with 20 different states. If it’s just of type SetBool, then everybody knows the two possible values just by looking at the type.
I am very well aware that the SetBool service does exist in std_srvs and I’v been cloning the repo to my workspaces a couple of times before it was released as package, however I think that the same argumentation goes for something like setFloat, setInt and so on. To quote a colleague: A float is a float, is a float. If you decide to call a service called set_distance with a measurement received from a humidity sensor or from a random number generator, that’s ok. I think it is quite obvious, that this probably won’t produce the desired behavior, however.
TLDR: I would prefer to have predefined set and trigger services with basic datatypes, however I see the risk of tempting people to kind of missuse datastructures out of pure lazyness and that this should be prevented as good as reasonable (reasonable as in the bool typedef example).