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*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Thu, 26 Nov 2009 15:00:10 -0500*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 :content-transfer-encoding; bh=LIJ2XzP6POLvXNMueFx/GglJRKCJWi+f1dbQTn+5VuQ=; b=NpCZpLkALXH3+4vDh2/J1H5URO7mQmLANGTf3/IUvJganBe+8QBJaHoitgVmPdXDTS cHYGtZdvV2SpdZfxmcbJ3MYWnEf7W3BEUhZbRHcdWk/1BImJlerxAHxej6V2LcFHx6Tg 6YyhDMtixrv7yvJK2TqGbioothYqbII68YuFQ=*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:content-transfer-encoding; b=iYQZOm3J9RuB8cn3OtUEQwDgLkGEwuPw0d3f8EJr3a7MGHuQxBBXPFRbzDhiVj0Cug xh/ZCzg4mI9un/jOlm0kdG1RcqN3TYhJeeCsYiRKVuEDhf8SSVWhoWo4hxicz/9R7obe F6hwlPH+pmnMFI4QhxpdTD1W5EDlOtgbuYeQ0=

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

**Follow-Ups**:**Re: [eigen] Eigen and rigid body simulation***From:*Rohit Garg

**Re: [eigen] Eigen and rigid body simulation***From:*Adolfo Rodríguez Tsouroukdissian

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] combine matrix blocks** - Next by Date:
**[eigen] renaming 'precision' to 'dummy_precision'** - 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/ |