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).
---
[Visit Topic](
https://discourse.ros.org/t/suggestions-for-std-srvs/1079/16) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)