Sparked by the message format review for foxy, we got into discussing whether
geometry_msgs/Twist is a good interface for commanding robot bases. William suggested to take this elsewhere, which is why I’m posting a new thread here.
I have argued that the interface is error-prone, because you can send y and z velocities and rotations to a robot base that doesn’t support those and there is no direct way for the recipient to report this. Also, we are seeing some people with Ackermann kinematics abusing the rotation to send a steering angle. My initial, probably somewhat naive, suggestion has been to create message types that reflect the capabilities of the underlying base (e.g., a differential drive base would have a message that contains only translational and rotational velocities).
@smac has made several big comments, which I suggest you read directly, but I think the gist is that he is very much opposed to splitting this up into multiple message types, because he is worried about interoperability and the potential resulting complexity across the eco-system.
For the record, I do share those concerns in general and I think it is very important to have standardized, message types that are well supported across the whole eco-system. I just don’t think that creating a small number of new command messages types would be the utter disaster that @smac considers it to be
I’m also already seeing that people are extending navigation systems in many incompatible ways (e.g., ackermann_msgs has never been properly standardized), and I’m also seeing people generally having issues with messages that are ambiguous.
Therefore, I’m wondering what other people think and whether looking at the standard robot command interfaces would be considered useful.
btw, I think adding a timestamp (e.g., going to TwistStamped) is generally considered useful, so we’re most likely looking at a small change anyway.