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
The following elements in the link_state specification all use the pose data type, even though the rotational components should not be represented by a quaternion.
//state/link/velocity
//state/link/acceleration
//state/link/wrench
I'm guessing this is because there is no vector6 type to handle the spatial vectors. Since it can be confusing to remember whether the translational or rotational components should go first (SDFormat and URDF pose put translation first, while DART and many spatial algebra formulations put rotation first), an alternative is to split them into two vector3 types.
Alternatives considered
We could add a gz::math::Vector6 to support a vector6 type, but I think it may be less confusing to use two vector3s.
Implementation suggestion
Additional context
The text was updated successfully, but these errors were encountered:
Desired behavior
The following elements in the link_state specification all use the
pose
data type, even though the rotational components should not be represented by a quaternion.//state/link/velocity
//state/link/acceleration
//state/link/wrench
I'm guessing this is because there is no
vector6
type to handle the spatial vectors. Since it can be confusing to remember whether the translational or rotational components should go first (SDFormat and URDF pose put translation first, while DART and many spatial algebra formulations put rotation first), an alternative is to split them into twovector3
types.Alternatives considered
We could add a
gz::math::Vector6
to support avector6
type, but I think it may be less confusing to use twovector3
s.Implementation suggestion
Additional context
The text was updated successfully, but these errors were encountered: