Make explicit that body fixed frame is the sourceFrame

[joaobrittoneto]

As the frames are formally described as sourceFrame and targetFrame,
make it clear that the angular velocity is represented in sourceFrame.
Let an indication that it is the "body" frame, as in the RigidBodyState documentation

[doudou]

This goes against my understanding of #99

If RBS is the state of 'source' in 'target', the velocities should be the velocities of 'source' in 'target'. Or am I still missing something ?

[saarnold]

I agree that both velocities should be represented in the same frame. In most parts of the code I know it is sadly not the case, probably because of the ambiguous documentation.
Changing body fixed frame to world fixed frame would be one solution.
I would also be more than happy to have both velocities represented in the source frame, but the effort of changing this might be even higher I guess.

[joaobrittoneto]

According my understanding of RBS documentation #99:

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?

But I agree with Sascha:

I would also be more than happy to have both velocities represented in the source frame,

[doudou]

I agree that both velocities should be represented in the same frame. In most parts of the code I know it is sadly not the case, probably because of the ambiguous documentation.

One relevant question is whether the current code is consistent with the current RBS documentation, or if we anyways have widely different interpretations in the wild already.

In the former case, changing it is difficult. In the latter case, it's a no-brainer.

[saarnold]

At least the code I know, where both pose and velocity is set, is consistent with the current documentation. But it wouldn't be to hard to change those parts.

[joaobrittoneto]

I have a doubt about the velocities in case the sourceFrame==targetFrame.
The velocities are not the velocities of the sourceFrame related to the targetFrame, expressed in the respectives frames? In this case the velocity of sourceFrame==targetFrame should not be zero??

[doudou]

In this case the velocity of sourceFrame==targetFrame should not be zero??

For me, the only thing that would make sens with the current definition is to express the velocity of sourceFrame in the targetFrame considered fixed at time (t). Otherwise, there is no way to express a velocity of a vehicle in the body frame.

[joaobrittoneto]

to express the velocity of sourceFrame in the targetFrame considered fixed at time (t)

It's not a trivial assumption. One can think that the frames, if having the same name, should share the same properties, including velocities.

Why not represent the velocities direct in sourceFrame (the body frame)? Like the velocity of the sourceFrame related to the targetFrame expressed in sourceFrame?
Like that the information of orientation between sourceFrame and targetFrame doesn't really matter at that level.
For example, the velocities of sourceFrame related to two frames, targetFrame1 and targetFrame2, both expressed in sourceFrame, are the same if the transformation between targetFrame1 and targetFrame2 is constant.

A body frame velocity is usually what a sensor measures, independent of the targetFrame (inertial frame) used. If anyone wants the representation of the velocity in a specific targetFrame, then the orientation is required.
And I have the impression that most of a system requires the velocities expressed in body frame. Having the velocity expressed in targetFrame requires the orientation being available or making the hack of sourceFrame==targetFrame.

[doudou]

I'm picking up on this since the confusion came back (rock-gazebo/simulation-orogen-rock_gazebo#15), in this case because I didn't re-read the RBS documentation in the first place (so, not confusion of reading the documentation, but simply not the intuitive answer).

Anyways,

I think the best right now is to stick to the common interpretation of the code (even if it ends up being horribly incosistent, IMO), that is - from what I believe @saarnold said:

• velocity is the linear velocity of the sourceFrame relative to targetFrame, expressed in targetFrame
• angular_velocity is the angular velocity of the sourceFrame relative to targetFrame, expressed in sourceFrame

If there's agreement, could you update this PR, @joaobrittoneto ? If you don't have the time, I will create a new one.

[doudou]

Thanks