Re: [eigen] Eigen and rigid body simulation

[Rohit Garg <rpg.314@xxxxxxxxx>]

Also since translation is already in eigen, displacement class (or
whatever it's new features are) should be merged into the existing
class for maximum compatibility.

On Fri, Nov 27, 2009 at 1:30 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> OK thanks.
>
> I'm slowly, very slowly understanding what this is about: I know zero
> about mechanics.
>
> So you are introducing these classes:
>
> Quaternion, Displacement, AngularVelocity, Twist, Torque, Wrench
>
> ***
>
> 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.
>
> ***
>
> Displacement deserves to be in the Geometry module but with a
> different name. At the very least there must be 3D in the name,
> because we aim to support all dimensions. So perhaps Displacement3D.
> Or call it QuatAndTranslation... I don't know.
>
> 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.
>
> 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: for example, if you wanted such a
> UnitQuaternion class to be useful, you would have to make it
> impossible to construct non-unit quaternions with it, so you couldn't
> have a Quaternion(x,y,z,w) constructor, or a Map<...> system, etc.
> That would be too cumbersome. It seems easier to just say that it's
> the responsibility of the user to only use unit quaternions when they
> are to be interpreted as rotations. It's like the reason why we don't
> have an InvertibleMatrix class even though at many places one needs to
> use invertible matrices.
>
> But in order to unify Quaternion with the existing Quaternion, one
> needs to clarify the log() return value. Calling it AngularVelocity
> here means that your Quaternion represents actually a "rotational
> movement" otherwise you wouldn't talk about velocity. I don't think
> that you want to create a new different Quaternion class just for
> that, right? Especially as you then use it for plain rotations, for
> rotational speeds and even for rotational forces.
>
> 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.
>
> 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
>
> Then I'd say why not, these names are specific enough to mechanics so
> it can't hurt to have them used in that way.
>
> Am I correct in understanding that they are just derivatives (with
> respect to time) of existing classes Quaternion and Displacement? Ok,
> up to the identification force == acceleration. Not saying that they
> shouldn't exist as separate classes, just trying to understand. 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.
>
> Cheers,
> Benoit
>
>
> 2009/11/26 Mathieu Gautier <mathieu.gautier@xxxxxx>:
>>> I was confused that you called these functions log() and exp()
>>
>> yes, it's a little bit tricky because there's two different exponential
>> function, and both have a mathematical definition.
>>
>> 1/ the exponential of quaternion generalize the exponential of complex
>> number to quaternion. This exponential is actually useless for rigid body
>> motion.
>>
>> 2/ the exponential of an element of the Lie algebra so(3) (Angular Velocity)
>> return an element of the Lie group SO(3) which are in fact the rotation
>> matrices.
>> This exponential function is defined by the sum of 1/k! A^k with k in [0;
>> infinity[ where A is in SO(3). This exponential links a rotation and  the
>> angular velocity.
>>
>> The main problem is that we choose to represent a rotation with a
>> quaternion. It's very usefull, but have some drawbacks. For example, adding
>> two quaternions have no meanings when these quaternion represents  rotation.
>> That's why I introduce a Rotation3D to reflects this distinction.
>> I don't know if it's better to have a class Quaternion to represents the
>> classical quaternion and another class to represents 3D rotation with a link
>> (inheritance, ownership) to this Quaternion class.
>>
>> --
>> Mathieu
>>
>>
>>
>
>
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay