Paul Furgale

It looks like there is a very clever setup for how to write unit tests once and have the same tests run over all possible implementations. This is great! However,...

The documentation says > Base class that defines the interface of a pose of a rigid body. > > This class defines the interface of a pose of a rigid...

I've noticed that, for every eigen type, one has to reimplement `class get_matrix3d`. This seems error prone and tedious. For example, if we want to support transformation of `4x1` types...

Fill out interface of pose representation

4

Here we need the following: 1. Match the rotation implementation by implementing `inverted()` and `invert()` 2. Transformation by multiplication (see #28) 3. Transformation of `4x1` vectors 4. Support for `setRandom()`...

Add support for homogeneous 4x1 vectors

1

We should be able to rotate and transform these. As a minimum, we should support native types (i.e. `Eigen::Vector4d`), but should we also have an abstraction for homogeneous quantities?

The current implementation uses `class get_matrix3` to abstract the types for fixed sized `3xN` matrices. Should we support dynamic sized `3xN` matrices? i.e.: ``` typedef kindr::rotations::eigen_impl::RotationQuaternionAD RotationQuaternion Eigen::MatrixXd A_p(3,100); //...

Add more rotation parameterizations

1

At the minimum we should cover these guys:  

Either this page http://ethz-asl-lr.bitbucket.org/kindr/page_rotations.html or each rotation implementation should have latex that says how to build a rotation matrix from the scalars for every different rotation parameterization.

Something like this: http://eigen.tuxfamily.org/dox-devel/AsciiQuickReference.txt

Kindr needs a developer guide.

3

This guide should justify the complexity of the implementation, walk the reader through an example of how the implementation hooks together (like for the rotate call or the multiplication call).