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.
“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 happens to be of type
bool and contain the value
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:
BTW, Wouldnt that kind of topic deserve its own Category in Discourse ?