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

Eliminating the rotation invert step when converting to/from PTransformd #19

Closed
ahundt opened this issue Oct 23, 2017 · 2 comments
Closed

Comments

@ahundt
Copy link

ahundt commented Oct 23, 2017

When converting between PTransformd the rotation component must be inverted:

  1. before you convert from Eigen/V-REP formatted data to PTransformd
    • ex: Affine3d or vector+quaternion array to a PTransformd
  2. After you extract data from PTransformd to quaternion or Affine3d
    • ex: PTransformd to Affine3d or vector+quaternion array

Overall this set of APIs is beautiful, easy to use, and easy to understand when compared to anything else I've used in the past. That said, I'm writing some new code using the libraries and this extra Rotation invert step has been a continuous and ongoing pain point as I try to debug my code and add new utilities.

As far as I can assess, this difference between these representation seems to cause people a lot of trouble, my own example is in jrl-umi3218/Tasks#10. Typically keeping track of the frames themselves and making everything consistent can be fairly tricky on its own. In this case there is also an additional component of keeping track of which inverted state the rotation component is in which doubles the number of places your math can contain a bug.

Eliminating this manual step directly in the API could make this problem completely disappear. However, I'm aware there is tons of code that would become legacy if such a change were to be made, and there may also be a small amount of processing overhead depending on how it is implemented. That said, with a careful transition process it is conceivable that these problems could be mitigated, and the data conversion + user friendliness of the APIs would be simplified and improved forever.

That said, there may be very good reasons to keep things as they are beyond what I mention above, how do you feel about this possibility?

@gergondet
Copy link
Member

I am not sure what you mean here and especially which API you want to modify.

Do you mean to keep track of the left-handedness/right-handedness nature of the rotation within a PTransform<T> object? That would be quite impractical as everything assumes left-handedness.

Maybe you missed it but #15 introduced a set of conversion utility which defaults to assuming your non-PTransform object are right-handed and you want to convert to/from PTransform (always left-handed) objects accordingly.

@ahundt
Copy link
Author

ahundt commented Oct 24, 2017

Yes I meant the handedness. Oh well, I guess I'll make due.
I had missed #15, thanks.

@ahundt ahundt closed this as completed Oct 24, 2017
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