Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fill out interface of pose representation #32

Open
furgalep opened this issue Jun 22, 2014 · 4 comments
Open

Fill out interface of pose representation #32

furgalep opened this issue Jun 22, 2014 · 4 comments

Comments

@furgalep
Copy link
Contributor

Here we need the following:

  1. Match the rotation implementation by implementing inverted() and invert()
  2. Transformation by multiplication (see Support rotation by multiplication of native types #28)
  3. Transformation of 4x1 vectors
  4. Support for setRandom() (see Rotations and poses should have "setRandom()" #31)
  5. Initialize from a 4x4 matrix (maybe this already exists?)
  6. Fill out the documentation for this (see Develop documentation for poses #22)
@furgalep
Copy link
Contributor Author

Also: transformation of native types (Eigen::Vector3d, Eigen::Vector4d).

@furgalep
Copy link
Contributor Author

@HannesSommer, @remod, @gehrinch, this is a show stopper for me. I want to push to use Kindr in the rewrite of aslam_cv but it isn't possible without:

  1. Match the rotation implementation by implementing inverted() and invert()
  2. Transformation of 4x1 vectors
  3. Initialize from a 4x4 matrix (maybe this already exists?)
  4. Fill out the documentation for this (see Develop documentation for poses #22)

and I realized that the Pose/transformation is missing composition!

I honestly tried to implement it myself but it isn't possible without getting some design document that explains how to put something like that together (and why it is put together like this).

Any chance someone has some cycles to help?

@HannesSommer
Copy link
Contributor

I can certainly write something about the design goals and rational about some decisions (see #21). But can that wait till tomorrow? Btw. I don't think the design has completely stabilized yet - it is not even consistent over all classes.
This library is young and has quite difficult goals. The most important thing at the moment is the exterior interface. So people can start to use - at least the part that is implemented.
From that usage the exterior interface will stabilize. The interior structure can and will still change a bit. But I don't think there is a much simpler then existing in it with various fashions without scarifying important goals.

@furgalep
Copy link
Contributor Author

Yes, of course it can wait until tomorrow. Thanks for helping me understand the design. As I said, the external interface is very nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants