Re: [eigen] Eigen and rigid body simulation

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2009/11/27 Mathieu Gautier <mathieu.gautier@xxxxxx>:
> It's more about Lie group and lie algebra than about mechanism
> [...]
> Mechanics it's just a field of application.

ah great, now we're talking. Then let's go as far as possible in the
direction of abstracting it as pure mathematical concepts, that will
make it optimally useful in Eigen (perhaps even useful to KDL!)

>
> * a rotation 3d is an element of the special orthogonal group SO(3) which is
> a Lie group. We choose to represent it with a quaternion.

That I understood. Do you think that there is a fundamental reason why
you specialize on quaternions? Just a question, I guess it depends on
technical details. Because otherwise you could leverage our
RotationBase infrastructure, which is quite nice, it exactly means "3D
rotation" but allows different kinds of storage, at no cost (in pure
Eigen style, everything is done at compile time).

>
> * a displacement is an element of the special euclidian group SE(3) = SO(3)
> * R^3 (rotations and translations = direct isometries) which is also a Lie
> Group.

Ok, that too I understood. In Eigen terms, that would be a pair
(Translation, RotationBase). However so far you specialized on the
case where the rotation is reprensented by a quaternion. So that would
be a pair (Translation, Quaternion).

>
> * a twist is a member of se(3) which is a Lie algebra associated to SE(3)..
> It can be view as infinitesimal rigid transform.

OK, i see.

>
> * an AngularVelocity is an element of so(3) which is also a lie algebra. It
> can be view as infinitesimal rotation.

OK, that I understood.

> * a Wrench is a member to the dual Lie aglebra se*(3) of se(3).
>
> * a Torque is a member of so*(3) dual of so(3).

oh wow, so even that is purely mathematical, i see.

Is there a canonical duality? Or does e.g. the natural dot product on
R^3 give you at least a "usual" duality?

If there is a reasonable "usual" duality then there's no need to
implement a separate class for the dual, just implementing the
bilinear form is enough. (Think of how we don't have a class for
linear forms on R^n, the dual of R^n; instead we have the dot product
function; so a linear form can just be represented by the vector that
is dual to it in the usual dot product, and the dot product gives you
the pairing between the vector space and its dual).

But if there is a reason to add specify methods or operators there,
then I understand that you want to keep them as separate classes

>
> We could pick the names SO3element, SE3element, etc.. which would be
> distinct from their mecanical application.

Hm, we have a problem here: SO3Element, meaning "3D rotation", is
exactly what we are already calling RotationBase. If you specialize to
use quaternions, then we already have the Quaternion class for that.

Or did you mean lowercase so3 and se3? Then  yes I very much agree
with your idea, except that "Element" is a bit clumsy, and we must
find a way of putting "so" and "se" in lowercase. Not easy! Perhaps:

Lie_so3 and Lie_se3 ?

>
> ***
>>
>> I am unclear on the respective merits of such a Displacement class vs.
>> DualQuaternion and I don't have the expertise to fully understand your
>> reply to Rohit's mail. I can see how indeed such a Displacement class
>> allows for smooth interpolation. In any case, we could have both
>> Displacement and DualQuaternion; perhaps renaming Displacement to
>> QuatAndTranslation would help disambiguate with other representations
>> such as DualQuaternion.
>
> I agree that the name is not ideal. It's a gallicism refering to 3D direct
> isometries.

OK, that's what I understood, but indeed i believe that's what caused
confusion above.

Again, in order to find the right name for it, we need to decide: is
there a good reason to force the usage of Quaternion or can this be
generalized to RotationBase. Of course I much prefer to go
RotationBase unless there's a big reason not to.

>> Assuming that Quaternion, Displacement, AngularVelocity are absorbed
>> into Eigen itself in the way described above, there remain the
>> following classes in your proposed new module:
>>
>> Twist, Torque, Wrench
>
> I think that's Twist may have to be in Eigen, just like angularvelocity.

Understood.

> Wrench and Torque could be put in a separate module, since they are more
> specifics. The notion of wrench can be defined from twist through the notion
> of mecanical power.

Again see above what I write about duality. If there's a usual/natural
choice of a duality here, then these dual classes may not be needed?

But if it is nice to put some mechanics-oriented methods in these
classes, then it makes sense to create a new module for them.

>> I can't decide for you whether to have them as separate classes. About
>> what you write above:
>>
>>> NB: This class is optional, and is only needed for strong typing.
>>
>> here I would say: if it's only needed for strong typing, then refrain
>> from introducing such a class. We rejected a Point class (same as
>> Vector, just for strong typing) for that exact reason. However in your
>> case there may be stronger reasons to introduce these classes:
>>  - they represent physical quantities of distinct dimensions/units
>>  - you might have distinct code in each of them, i didn't check.
>
> I only introduce two methods through these classes. So, I am not sure if
> it's worth to add two additionnal class with the mapping mechanism. It's
> still an open question for me. I'd prefer minimizing the code. Torque and
> AngularVelocity can be replace by a vector (Matrix<Scalar, 1, 3>) with a
> method to return a skew symmetric matrix 3x3 from it.

It depends a lot on how it's going to be used. As I said, we rejected
creating a Point class because it was going to be used exactly like a
Vector. On the other hand we created a Translation class because for
example it allows to do:
  Translation * SomeOtherVector
or
  SomeOtherMatrix * Translation
which is completely different semantics than a vector had. So you need
to think about use cases.

Benoit