In 2 more sentences: I’m worried about breaking apart a standard into many message types that makes it harder / impossible to support all base types in common dependencies like filtering, simulation, and control. Also, there are several frequently-used packages that are indeed suitable for multiple base-types (differential, omni, ackermann) and without a single message type to describe, capabilities will either be lost or require abusing the rotation adaptors, as Igno puts it, everywhere.
The requirement I would like to add is for a single message NewMsgType is still able to communicate the information required for the big classes of robots like ackermann, different, and omnidirectional. sensor_msgs/PointCloud2 and sensor_msgs/Image do this by having an encoding or other metadata in the message about the format of the information being communicated. We could potentially have something like (notional, not literal):
Header header
uint8[] data
VelocityCommandEncoding encoding
Where the encoding is some set of constants for choosing encoding method: differential with linear and angular velocities, omnidirectional with linear XY and angular velocities, and ackermann with linear velocity and steering angle (or whatever people feel is appropriate). We can then provide a set of headers like PointCloud2 has for working with that encoded data:
OurNewMsgType msg = ...;
float lin_vel = sensor_msgs::GetLinearVel(msg);
float ang_vel = sensor_msgs::GetAngularVel(msg);
float steering_angle = sensor_msgs::GetSteeringAngle(msg);
float GetSteeringAngle(const OurNewMsgType & msg)
{
if (msg.encoding != VelocityCommandEncoding::ACKERMANN) {
throw std::runtime_error("Hey man, this isn't right.");
}
return ...;
}
Clearly that toy example has some holes, but the idea being some headers to support extracting useful information from that message. At this point, then its up to the application to not try to get invalid information from the wrongly encoded type, but if they were, it’ll throw exceptions.
While I find this less clean, I think it would address your concerns and there’s precedence for it. Then applications such as Gazebo etc can fill in this message and send it around, or when it gets a message from something like this, it can extract the useful information (or provide a sensor_msgs::ConvertToTwist(msg) method…).
For other users not following, this is the ticket discussing the TwistStamped topic: Switch from Twist to TwistStamped for cmd_vel · Issue #1594 · ros-planning/navigation2 · GitHub
