Re: [eigen] Eigen and rigid body simulation

On Thu, Nov 26, 2009 at 9:00 PM, 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.

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:

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