6DPose vs Pose

[shoeffner]

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:

Pose: hasPosition exactly 1 Position and hasOrientation exactly 1 Orientation
Position: hasPositionData exactly 1 xsd:string
Orientation: hasOrientationData exactly 1 xsd:string

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:

Pose: hasPosition exactly 1 Position and hasOrientation exactly 1 Orientation
Position: hasPositionData exactly 1 array_double or hasPositionData exactly 1 array_float or ...
Orientation: equivalently

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:

PositionData: hasDimension1Value exactly 1 xsd:double and hasDimension2Value max 1 xsd:double and hasDimension3Value max 1 xsd:double
OrientationData: hasDimension1Value exactly 1 xsd:double and hasDimension2Value max 1 xsd:double and hasDimension3Value max 1 xsd:double and hasDimension4Value max 1 xsd:double

And even a step further:

PositionData
    Position1DData: hasDimension1Value exactly 1 xsd:double
    Position2DData: hasDimension1Value exactly 1 xsd:double and hasDimension2Value exactly 1 xsd:double
    Position3DData: hasDimension1Value exactly 1 xsd:double and hasDimension2Value exactly 1 xsd:double and hasDimension3Value exactly 1 xsd:double
OrientationData
    Orientation2DData: hasDimension1Value exactly 1 xsd:double
    QuaternionOrientationData: hasDimension1Value exactly 1 xsd:double and hasDimension2Value exactly 1 xsd:double and hasDimension3Value exactly 1 xsd:double and hasDimension4Value exactly 1 xsd:double
    EulerAngleOrientationData: hasDimension1Value exactly 1 xsd:double and hasDimension2Value exactly 1 xsd:double and hasDimension3Value exactly 1 xsd:double

Another thing to note is that in that case we could define the Pose further again:

Pose: hasPosition exactly 1 Position and hasOrientation exactly 1 Orientation
    Pose2D: hasPosition exactly 1 Position2D and hasOrientation exactly 1 Orientation2D
    Pose3D: hasPosition exactly 1 Position3D and hasOrientation exactly 1 Orientation3D
Position: hasPositionData exactly 1 PositionData
    Position1D: hasPositionData exactly 1 Position1DData
    Position2D: hasPositionData exactly 1 Position2DData
    Position3D: hasPositionData exactly 1 Position3DData
Orientation: hasOrientationData exactly 1 OrientationData
    Orientation2D: hasOrientationData exactly 1 Orientation2DData
    Orientation3D: hasOrientationData exactly 1 QuaternionOrientationData or hasOrientationData exactly 1 EulerAngleOrientationData

Either way, I am currently fine with using xsd:string for the poses, just wanted to leave this here as a food for thought.

[mpomarlan]

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.

[shoeffner]

You are right, it stays a 6D pose, I was confusing naming and representation here, thanks for clearing that up!

[ayden175]

Is this still relevant? Has the proposal about pose representation been discussed, and are any changes planned?