Re: [eigen] geometry module

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/9/7 Daniel Stonier <d.stonier@xxxxxxxxx>:
> Thanks for the great summary Benoit. Again, I'll do some more tests
> tomorrow and decide on where we need to head, need to work out just
> where we will be doing most of our calculations and how slow trig
> lookups are compared to matrix products on our embedded boards. At
> some point in the future, I might look at the quaternion case too -
> has anyone else started or considered moving on that one?

I think Rohit started work on dual quaternions, but don't know the
status of that.

>
>> as said above:
>>  - for 3d isometries, quat+vector or quat+quat have been discussed
>> previously, would be a welcome addition
>>  - for 2d isometries, angle is inefficient, combining
>> Rotation2D+vector is the right approach.
>
> Isn't Rotation2D just a wrapper around an angle though? In which case
> I think you mean the transform classes or simply a 2x2 matrix + 2x1
> vector.

You're right, I didn't realize it, but Rotation2D is indeed a wrapper
around an angle.

So that makes me think that I'm not sure how much I like the name
Rotation2D for that. How about Angle2D instead? Would be consistent
with AngleAxis.

Benoit

>
> On 7 September 2010 19:57, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 2010/9/7 Daniel Stonier <d.stonier@xxxxxxxxx>:
>>> As I mentioned in the previous email, I've been having a gander at the
>>> new geometry module. Not sure who's putting it together, but wondering
>>> if they'd mind me picking their brain a bit.
>>>
>>
>>
>> First of all, the Transform class is for transformations represented
>> by matrices i.e. homographies. It's not a statement that no other
>> representation is interesting, it's just what this class is doing.
>> Other representations may be added as separate classes.
>>
>>> We're using transforms for robotics, so strictly rotations and
>>> translations. A 2D setup might only need 3 variables, angle + x-trans
>>> + y-trans.
>>
>> The problem with representing a transformation using an angle, is that
>> subsequent computations are relatively slow as one needs to compute
>> cosines and sines. If however you're OK with representing the angle as
>> a (cosine, sine) pair, then Rotation2D is doing that. If you want a
>> class that combines a Rotation2D with a translation vector, which
>> could be called Isometry2D, indeed we don't currently have that.
>>
>>> A 3D setup could most efficiently run with quaternion + 3
>>> element vector for translation.
>>
>> Here, "most efficiently" depends on what you're doing. If you want to
>> apply this transformation to a vector, it's going to be faster if you
>> have a matrix representation of your transform, as the Transform class
>> does. This is one of the most performance-critical use cases...
>>
>> That said, either what you propose (quaternion+vector) or a "dual
>> quaternion" class as has been discussed previously on this list, would
>> be interesting. We just happen not to have that yet.
>>
>> I think that given sufficiently explicit names, different classes can
>> coexist. The name Transform may not be very explicit though, but the
>> matrix approach is the only one to be generally applicable (any size,
>> no assumption on the transformation...) so that warrants a relatively
>> generic name.
>>
>>> I see that some optimisations are
>>> being made to the transform class - e.g. CompactAffine. There is also
>>> Isometry - how exactly does this differ from the Affine types,
>>
>> Isometry means Affine from the point of view of storage. The only
>> difference is that if you use Isometry, then you guarantee that the
>> transformation is actually an isometry, i.e. an orthogonal
>> transformation + translation vector. This allows Eigen to generate
>> faster code for certain operations like inverse().
>>
>> By the way --- others: shouldn't Isometry be CompactAffine instead of
>> Affine? Or should there be a CompactIsometry, etc.
>>
>>> and
>>> was/is there any design thoughts behind more optimised
>>> storage/calculation processes (i.e. quaternion instead of 3d rotation
>>> matrix, angle value instead of 2d rotation matrix)?
>>
>> as said above:
>>  - for 3d isometries, quat+vector or quat+quat have been discussed
>> previously, would be a welcome addition
>>  - for 2d isometries, angle is inefficient, combining
>> Rotation2D+vector is the right approach.
>>
>> Benoit
>>
>>>
>>> Many thanks,
>>> Daniel Stonier.
>>>
>>> --
>>> Phone : +82-10-5400-3296 (010-5400-3296)
>>> Home: http://snorriheim.dnsdojo.com/
>>> Yujin Robot: http://www.yujinrobot.com/
>>> Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> Phone : +82-10-5400-3296 (010-5400-3296)
> Home: http://snorriheim.dnsdojo.com/
> Yujin Robot: http://www.yujinrobot.com/
> Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>
>
>