Angular velocity frame representation

[joaobrittoneto]

The RigidBodyState's documentation says the RBS represents the state of the sourceFrame expressed in the targetFrame.
But the angular velocity is expressed in body fixed frame (I'd assume it's the sourceFrame).
Why it's not represented in targetFrame, like the velocity?

[doudou]

@jhidalgocarrio : any idea ? How are the velocities represented currently w.r.t the source and target frames ?

[jhidalgocarrio]

But the angular velocity is expressed in body fixed frame (I'd assume it's the sourceFrame).

This is a wrong assumption (but it is not your fault). Rock naming convention is "IMO" a mess and I have been saying that since the last 3 years.
In Rock you have to think that the sourceFrame is not the fixed frame, it is the moving frame. "source" as the source of a sensor frame, which is normally the moving frame. (never interpret "source" as the source of the RBS transformation, as 90% of people do).

In RBS documentation is written (line26):
"For instance, if sourceFrame is "body" and targetFrame is "world", then
the RigidBodyState object is the state of body in the world frame"

Then, I assume angular velocity is expressed in sourceFrame which is the moving frame.

Why it's not represented in targetFrame, like the velocity?

It is actually expressed in "target frame". Rock calls it sourceFrame.

[doudou]

Rock naming convention is "IMO" a mess and I have been saying that since the last 3 years.

I wholeheartedly agree on that part ... I'm trying to get people to at least document the thing properly so that one can make sense of it.

The source/target naming convention being based on the 'frame change' convention (i.e. X/source_RBS(source->target)=X/target), it means that RBS(source->target) is the pose of the source expressed in the target frame, right ? (given that Identity/source_RBS(source->target) = Pose_source/target.

If that's right, I get your moving frame / reference frame argument. Basically, if a RBS represents the state of body X in reference Y, sourceFrame = X, targetFrame = Y.

[joaobrittoneto]

Thanks for the explanation.

(never interpret "source" as the source of the RBS transformation, as 90% of people do)

I have to admit it was my case for a while.

So, If i got this right regarding the velocities:
The angular velocity is expressed in sourceFrame ( the angular velocity of the moving frame expressed on it own frame).
And the linear velocity is expressed in targetFrame (the linear velocity of the moving frame expressed on the fixed frame). Is that right?

I just ask myself if there was a reference that was used to define which frame the velocities would be expressed in, or if it is a RBS convention.

[jhidalgocarrio]

The source/target naming convention being based on the 'frame change' convention (i.e. X/sourceRBS(source->target)=X/target), it means that RBS(source->target) is the pose of the source expressed in the target frame, right ?

Yes, this is right.

If that's right, I get your moving frame / reference frame argument. Basically, if a RBS represents the state of body X in reference Y, sourceFrame = X, targetFrame = Y.

Also true.

I'm trying to get people to at least document the thing properly so that one can make sense of it.

This is really good but I don't agree this is the best solution. I think a change (even when it's late) is better than documentation.
Mainly for three reasons: 1. the manner @joaobrittoneto interpreted the RBS transformation is becoming a de facto standard in robotics [http://ieeexplore.ieee.org/document/7300355 , ISO 9787:2013 and Handbook of Robotics, Chapter 1.2 ]. 2. most of the existing libraries (kdl, urdf, ros, gtsam, osg ...) use the de facto way of interpreting a transformation. 3. using the de factor standard concatenation becomes intuitively easier: RBS(a->b) RBS(b->c) = RBS(a->c). Currently in rock has to be something like RBS(b->a) RBS(c->b)=RBS(c->a). Meaning the pose of c expressed in a.

There are several attempts to improve the issue: #35 #85
A complete change in rock would affect the transformer and vizkit3d. Actually the first versions of vizkit3d used the de factor manner (because of osg) but it was changed to be coherent with RBS and the transformer.

[doudou]

But the angular velocity is expressed in body fixed frame (I'd assume it's the sourceFrame).

This is a wrong assumption (but it is not your fault). Rock naming convention is "IMO" a mess and I have been saying that since the last 3 years.

Actually, it is the right assumption. If source is the moving frame and target the reference frame, body-fixed frame is source (as in RBS represents the pose of "body" in "world")

[jhidalgocarrio]

Actually, it is the right assumption. If source is the moving frame and target the reference frame, body-fixed frame is source (as in RBS represents the pose of "body" in "world")

Yeap...of course the body frame is a frame fixed to the body (this is the reason why it is called body frame) and body frame is moving w.r.t. the world frame. What I understood from "body fixed frame" is a fixed reference frame or inertial frame of reference. I also got this understanding from the second question ">Why it's not represented in targetFrame, like the velocity?"

What I wanted to say is that in rock the sourceFrame is not a fixed reference frame, which is the de factor in many text/books/libraries. Nevertheless, I imagine everything is subject to interpretation.

[doudou]

Just to be clear: I'm all for picking a convention that matches what looks like the most widely used convention (the way we picked X-forward because it was the standard frame orientation in ROS). Just pointing out that I finally realized that Joao's interpretation of source/target was correct[1]

[1] note how long it took me to realize that ...

[jhidalgocarrio]

Just to be clear: I'm all for picking a convention that matches what looks like the most widely used >convention (the way we picked X-forward because it was the standard frame orientation in ROS).

+1