| Re: [eigen] Eigen and rigid body simulation |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
I'm slowly, very slowly understanding what this is about: I know zero
about mechanics.
It's more about Lie group and lie algebra than about mechanism, but it's
far from easy.
***
Quick Summary:
The 3 first classes Quaternion, Displacement, AngularVelocity are
potentially interfering with geometric concepts that we have to that
we may want to have in Eigen. As such, we must be very careful of
integrating them with Eigen, ideally stripping them from any physical
content and making them purely geometric. The 3 last classes Twist,
Torque, Wrench are not a problem, being 100% specific to mechanics it
doesn't hurt to have them in an unsupported module, they don't
interfere with the rest of Eigen.
Mechanics it's just a field of application.
* 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.
* 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.
* 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.
* an AngularVelocity is an element of so(3) which is also a lie algebra.
It can be view as infinitesimal rotation.
* 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).
We could pick the names SO3element, SE3element, etc.. which would be
distinct from their mecanical application.
***
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.
Quaternion should really be unified with the existing Quaternion. I
don't think that restricting it to unit quatenions is a good enough
reason to make it a separate class
I also agree, I add a seperate class to discuss the specific point of
having quaternions in one hand and quaternion which are used to
manipulate 3D rotation in other hand.
So it would help a lot if you could rename AngularVelocity to
something that doesn't involve the physical notion of time. What you
really mean is "an element of the Lie algebra so(3)", right? I don't
know much about that but perhaps there is a name for these elements.
Or perhaps just call them LieAlgSo3.
Exactly, it's the little list I put at the beginning of this mail.
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.
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.
Am I correct in understanding that they are just derivatives (with
respect to time) of existing classes Quaternion and Displacement?
Not exaclty, the definition is a little more complex. you have to take
into account the frame in which you are derivating. But they indeed
reflect the notion of velocity.
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.
--
Mathieu