Extend or clarify TwistStamped semantics to be able to transform

[tfoote]

There was an initial implementation for transforming Twists based on the stamped frame_id however it was identified that the representation was insufficient to fully describe the semantics of a Twist.

from: https://wiki.ros.org/tf/Reviews/2010-03-12_API_Review copying here for visibility

API review
Proposer: Tully

Present at review:

List reviewers
Question / concerns / comments
Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.

Meeting agenda
To be filled out by proposer based on comments gathered during API review period

Review new lookupVelocity and transformVelocity transformTwist
Codify interpretation of Twist message.
there is a reference transformTwist method here using the semantics defined below as transformVelocity There is a transformTwist method documentation here http://www.ros.org/doc/api/tf/html/c++/classtf_1_1TransformListener.html#5560fed20fc0ab7a9dd330aca7f3a7dc

Twist message discussion summary
The problem with twist messages is that there are 4 potential different coordinate frames associated with any twist. There are:

reference point
reference frame
observational frame
body frame
The problem with this is that the [TwistStamped](https://wiki.ros.org/TwistStamped) messages only has one coordinate frame.

With this message the body frame cannot be expressed.
There is a consensus to collapse the reference point and reference frame into a single coordinate frame.
Whether to consider the observational frame the same as the reference frame is a question.
This is particularly an issue when considering transforming velocities. Are they absolute measurements of velocity, or are the relative ones which should be only rereferenced but not transformed.
For example: two robots are driving forward. They each see each other as moving 1 m/s in the world. I could ask for robot1's velocity in robot2's frame. The results of this could either be a transformation of 1m/s linear to the combo of angular and linear which is offset by the distance between the robots. But still the magnitude is
Proposal
make transformVelocity which assumes observational frame is coincident with reference frame, and corrects for moving frames.
make rereferenceTwist which only changes the representation of the twist to a new coordinate frame
Other options
possibly make a new Velocity Message?
Extend the twist message
Stu
Here's my use case:

I am controlling the gripper in the frame of the forearm camera. My joystick defines a twist of the gripper in the frame of the forearm camera. I want to transform that twist to the frame of the torso, and then apply it to the gripper.
Conclusion
Stack status change mark change manifest)

/!\ Action items that need to be taken.

{X} Major issues that need to be resolved

tf provide lookupTwist methods
lookupTwist(string tracking frame, string obs frame, string reference_frame, pointStamped ref_point, Time time)
simple version where:(ref_point is origin of target_frame, ref_frame =obs frame)
move transformTwist into tf_kdl_conversions as helper functions

The result of this review was to remove the transformTwist method due to incomplete semantic information: ros/geometry@de17182 And the follow up needed was to either clearly define the twist semantics in the message or extend the Twist message to capture all the frame information.

I'm opening this as an enhancement ticket to motivate the evolution/extension of TwistStamped.

In particular we need to make sure that we capture or document where these all are so that everyone makes the same assumptions:

• reference point
• reference frame
• observational frame
• body frame

[Ryanf55]

Is this something you want to do by J-turtle?

[tfoote]

This is something I would have liked to do for more than a decade. It is entirely feasible to do this for J turtle. It will take a good amount of work to first do the due diligence to make sure that we can get coverage of the many different use cases. And secondly to identify and clearly define the migration paths for existing users with a deprecation process etc.

[destogl]

@tfoote didn't we resolve this issue in #240

[tfoote]

Indeed we can close this!