Re: [eigen] Eigen and rigid body simulation

[Maxime Tournier <maxime.tournier@xxxxxxxxxxxx>]

On Thursday 21 January 2010 17:54:00 Mathieu Gautier wrote:
> >> I can then write something like  :
> >> 
> >> double data[4] = {1,3,4,5};
> >> 
> >> Rotd d, dr;
> >> RotMapd dm(data);
> >> dr = d *dm;
> > 
> > Yes it's definitely easier to write when using it, but in the end there's
> > still a lot of machinery to simply avoid using free functions. In your
> > case, the wrapper also involves performance issues since values are
> > copied all around.
> 
> In fact they are not copied, at least for the objects I tried. Since I
> was focused on tiny elements like Quaternion or Matrix<Scalar, 1, 7>,
> the copy are elided by the compiler and I didn't see this issue. I
> haven't checked with more complex objects. But it may indeed involve
> unecessary copy.
> 
> > and then:
> > 
> > 
> > Foo a, b, c;
> > c = a.lie() * b.lie().inverse();
> > 
> > or ( with a helper lie_wrap template function ) :
> > c = lie_wrap(a) * lie_wrap(b).inverse()
> > 
> > (which is only a matter of taste)
> > 
> > 
> > If i'm bothered with all those pesky "lie" calls, i can always do:
> > lie::wrap<Foo>  aa(a), bb(b);
> > 
> > c = aa * bb.inverse();
> 
> I still have my same concerns with this implementation. I think it's too
> complicated for rigid body simulations where we only want to use so3,
> se3, SO3 and SE3 elements (with nice names :) ). But for a more complex
> use (group product, etc.), your suggestion may be more appropriated and
> the more complex syntax would be then unavoidable.
> 

I think there is a slight misunderstanding from my part. Allow me to clarify.

If you want to use SO3 or SE3 elements, you can do it directly using Eigen 
classes. This is for when you know, *in advance*, that you're going to use 
rotations/rigid transforms in your algorithm. In this case there is no point 
in using all this complicated Lie group stuff, just use the plain types 
instead.

And if this is just about having nice names for existing stuff, then typedefs 
are fine :-)

However, if you want to design an algorithm that works for any Lie group (like 
interpolation, blending, averaging, and what not), then it might be convenient 
to abstract out the specifics of each class, which is what the wrapper/concept 
map stuff does. It will give you a coherent, convenient, and non-intrusive 
view over existing data types for implemening *generic* algorithms.

If you implement the Lie group structure for Eigen types (which is mostly 
already done), then you will automatically  benefit from these algorithms if 
you feed them Eigen types directly. So really, if you just want to interpolate 
quaternions, all you'll need to do is:

Eigen::Quaterniond q1, q2;
interpolate(q1, q2, 0.5); 


Good news is that even in the improbable event of you wanting to use another 
linear algebra library (what a weird idea) for doing your stuff, all you'll 
have to do is to implement Lie group structure for your new library (a concept 
map) and it *will* work without touching anything else.

So this will still work as long as you provided a concept map:

EvilLibrary::Quatd q1, q2;
interpolate( q1, q2, 0.5 );


So to me, all this Lie group stuff is really aimed at implementing *generic*  
algorithms, (as opposed to specific) that can be reused fairly easily no 
matter what the underlying types are. I believe the benefits are huge, but 
*only* if you need to write generic stuff. Otherwise it's a complete loss of 
time :-)


But say for example i'd like to interpolate rigid transforms or homographies 
or data in a high-dimensional torus, or maybe just good ol' vectors in a 
spline way. If i implement the algorithm using only Lie-group structure of the 
data ( for example by extending http://portal.acm.org/citation.cfm?id=218486 
as i did :-), then it will work for everything that has a Lie group structure. 

Same goes for a time integrator, post-step stabilization in a constrained 
physical system, statistical analysis ( see 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.2692&rep=rep1&type=pdf 
) and quite a bunch of other things.

It saves huge amounts of development, copypasta, headaches, and so on. 

But the user is not supposed to, well, use all this stuff. All (s)he will 
see/use will be Eigen types as they are now and a bunch of new algorithms.

> I'll check again my implementation with more complex cases (if you have
> any example, it would help).


Best regards,


-- 
Maxime Tournier

PhD Student - EVASION Team
Grenoble Universities / LJK / INRIA Rhône-Alpes
FRANCE
Tel: +33 4 76 61 54 45