Open hakuturu583 opened 5 years ago
This would be something that could use a standardized message to capture. It would likely be the same datastructure as the Twist but with different semantic meaning. Could you make a proposal and show it in use in practice? Before we promote it into a common message it's preferred to have actual demonstrated use cases. For example the Twist has a challenge that there ambiguity between reference point and frame vs the observational frame and the body frame.
This has caused things like transformTwist implementations to be removed due to ambiguity. These should be considered and resolved in this proposed message and likely an evolution of Twist can take up the same changes.
More info:
I don't have a solution for the problems described with Twist
, but I would like to second the proposal to add a Jerk
message to geometry_msgs
.
This came up in a discussion around a new message (set) for Cartesian trajectories in a ROSIN FTP and it'd be really nice if we could avoid introducing a custom message for this.
As you write @tfoote: it'd essentially be a copy of Twist
but with changed semantics.
Showing usage is difficult, as in our research it doesn't seem many ROS (ros_
) control interfaces consider jerk, which is something we're trying to address.
@fmauch @jonbinney
Uh, that notification slipped through my mails...
As @gavanderhoorn wrote we are currently working on a Cartesian trajectory interface proposal where jerk definitions in waypoints came up in a discussion.
As this is a pure interface definition where controllers could be built upon, this doesn't provide a real world use case, but a "potential" use case which IMHO does make sense to tackle.
I want to describe jerk in geometry_msgs. However, there is an acceleration message, but there are no jerk message. So, I want to add message for jerk.