Re: [eigen] Eigen and rigid body simulation |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Eigen and rigid body simulation*From*: Adolfo Rodríguez Tsouroukdissian <dofo79@xxxxxxxxx>*Date*: Fri, 27 Nov 2009 10:10:12 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ifq2oCRd3aV6mxx9lm7LpowELsLTjaiqJ0yf21Whac0=; b=I6Rz1na2MuQs+9FpxuA/Pwjt7HYXpPLmJKJoYPdM76dS9Fwl7Wt7/wkjcg0GyBZE02 kPQpdjdwH34y2ml4PsZTzYiTyk4sW8q8CJsYPJe8RkSYa0+ukaCEjGyg+vnJupTdRyRK Z0JKERJdM5papapYLjakFN3FoRs9K6jf/882Q=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=R5Aeo0HMUSnhBNmbwx/6ctmL6wD26vV4IaD8nrvBwwLZ04UhNQM2Qdn1RNUrUqYkOH Ovg7w3rP4Jace1e6T3IWeCDSVV7EhBzH1LGLc1u6XSglK91JPT+VxipTZ8BZNB459ixG IsA3xhOGnouvlo7jJghuWHKSNPK01Yyhce/cA=

On Thu, Nov 26, 2009 at 9:00 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

If I understand correctly, Displacement is a specialization of the existing Transform class for the isometry in 3D case (just like Rohit's dual quaternion implementation), so maybe Transform3D or similar would be easier to relate with the more general implementation.

Twist is the derivative of the displacement. The other two are not derivatives or either displacement or a rotation(quaternion). In the naming convention I am used to, a wrench in 3D is a generalized force consisting of a 3D force and a 3D torque.

I don't know if you're familiar with the Kinematics and Dynamics Library, a.k.a. KDL [1], that implements many of these concepts, and as its name implies, many kinematics/dynamics algorithms that you might find useful. KDL is used by quite a few groups in the robotics community, and is to my knowledge the most mature open source alternative out there (in its domain). Not so long ago its internals were migrated from boost::numeric::ublas to Eigen, which should make all of us happy ;). One observation is that in KDL, Eigen data structures are not exposed in the public API as much as the above proposal suggests, but then again it's OK to have a pretty much Eigen-agnostic interface, the main thing being able to properly expose data structures/concepts (not in the C++0x sense) and algorithms rather than internal design choices.

If you are indeed familiar with KDL, and you found out that it does not adapt well to your needs, I'd be very interested in knowing what shortcomings you found for your application domain, and how would you address them otherwise.

Finally, I apologize if the topic of this thread drifted a bit from an Eigen-specific subject. Anyway, it's been an interesting thread :D.

Cheers,

Adolfo

[1] http://orocos.org/kdl/

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.

If I understand correctly, Displacement is a specialization of the existing Transform class for the isometry in 3D case (just like Rohit's dual quaternion implementation), so maybe Transform3D or similar would be easier to relate with the more general implementation.

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?

Twist is the derivative of the displacement. The other two are not derivatives or either displacement or a rotation(quaternion). In the naming convention I am used to, a wrench in 3D is a generalized force consisting of a 3D force and a 3D torque.

I don't know if you're familiar with the Kinematics and Dynamics Library, a.k.a. KDL [1], that implements many of these concepts, and as its name implies, many kinematics/dynamics algorithms that you might find useful. KDL is used by quite a few groups in the robotics community, and is to my knowledge the most mature open source alternative out there (in its domain). Not so long ago its internals were migrated from boost::numeric::ublas to Eigen, which should make all of us happy ;). One observation is that in KDL, Eigen data structures are not exposed in the public API as much as the above proposal suggests, but then again it's OK to have a pretty much Eigen-agnostic interface, the main thing being able to properly expose data structures/concepts (not in the C++0x sense) and algorithms rather than internal design choices.

If you are indeed familiar with KDL, and you found out that it does not adapt well to your needs, I'd be very interested in knowing what shortcomings you found for your application domain, and how would you address them otherwise.

Finally, I apologize if the topic of this thread drifted a bit from an Eigen-specific subject. Anyway, it's been an interesting thread :D.

Cheers,

Adolfo

[1] http://orocos.org/kdl/

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:

here I would say: if it's only needed for strong typing, then refrain

> NB: This class is optional, and is only needed for strong typing.

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

>> 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

>

>

>

--

Adolfo Rodríguez Tsouroukdissian, Ph. D.

Robotics engineer

PAL ROBOTICS S.L

http://www.pal-robotics.com

Tel. +34.93.414.53.47

Fax.+34.93.209.11.09

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.

**Follow-Ups**:**Re: [eigen] Eigen and rigid body simulation***From:*Mathieu Gautier

**References**:**[eigen] Eigen and rigid body simulation***From:*Mathieu Gautier

**Re: [eigen] Eigen and rigid body simulation***From:*Christian Mayer

**Re: [eigen] Eigen and rigid body simulation***From:*Mathieu Gautier

**Re: [eigen] Eigen and rigid body simulation***From:*Thomas Capricelli

**Re: [eigen] Eigen and rigid body simulation***From:*Mathieu Gautier

**Re: [eigen] Eigen and rigid body simulation***From:*Benoit Jacob

**Re: [eigen] Eigen and rigid body simulation***From:*Benoit Jacob

**Re: [eigen] Eigen and rigid body simulation***From:*Mathieu Gautier

**Re: [eigen] Eigen and rigid body simulation***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Eigen and rigid body simulation** - Next by Date:
**Re: [eigen] Eigen and rigid body simulation** - Previous by thread:
**Re: [eigen] Eigen and rigid body simulation** - Next by thread:
**Re: [eigen] Eigen and rigid body simulation**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |