-
Notifications
You must be signed in to change notification settings - Fork 23
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
6DPose vs Pose #152
Comments
A minor terminological issue: 6D poses are also those where a translation and quaternion are used. Yes, it's "seven" values, but the quaternion is not arbitrary. The one constraint for it to be unit length means the 4 degrees of freedom are reduced by 1. In any case, the format of the pose components is an issue that popped up elsewhere already, and it may be time to discuss it again. Daniel wants to move away from the xsd:string as a type for the translation/orientation components, and towards array_double instead, so this proposal will definitely get a hearing soon. If not next week, the week after. |
You are right, it stays a 6D pose, I was confusing naming and representation here, thanks for clearing that up! |
Is this still relevant? Has the proposal about pose representation been discussed, and are any changes planned? |
In my application I have "7D" poses, i.e. poses defined as a 3D position and a 4D quaternion orientation.
Currently I use hasPositionData and serialize pose data into a comma-separated string where possible, since I am the only consumer it's okay that I have 7 values.
However, maybe it might be useful to rethink the pose concept. I heard that @mpomarlan is considering some 2D-applications, for which a pose is also well defined as a position and an orientation.
For example, something such as:
Might make it more flexible to define positions, orientations, and poses more freely and still more precise.
While changing that, there is a datatype array_double (which is just an xsd:string) which could make it slightly more precise, for example one could define:
Or, another datatype such as array_numeric might be useful for this case.
One could go a step into another direction and define PositionData and OrientationData, that could make it more precise (how many dimensions do we have? etc.) and remove the "array as xsd:string"-model:
And even a step further:
Another thing to note is that in that case we could define the Pose further again:
Either way, I am currently fine with using xsd:string for the poses, just wanted to leave this here as a food for thought.
The text was updated successfully, but these errors were encountered: