You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When converting between PTransformd the rotation component must be inverted:
before you convert from Eigen/V-REP formatted data to PTransformd
ex: Affine3d or vector+quaternion array to a PTransformd
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?
The text was updated successfully, but these errors were encountered:
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.
When converting between PTransformd the rotation component must be inverted:
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?
The text was updated successfully, but these errors were encountered: