Missing transform Vector3 operator for Pose3

[stefanbuettner]

Hey there,

is there a reason why there is no Vector3 operator*(Vector3) implemented for Pose3? Wouldn't it be rather handy for transforming points between different link/model/joint frames?

Cheers,
Stefan

[chapulina]

We've had some trouble with Pose3's operator*(Pose3) in the past and had to change its definition, see #60. That's to say that the meaning of these operators can get fuzzy. I'm personally in favor of just using functions that are well-defined rather than operators that can be misinterpreted.

Unless it's for a class that has a well-established meaning in mathematics, like Matrix4:

https://github.com/ignitionrobotics/ign-math/blob/6a3c4a32b18e6bd7956fecfe53ccfe14bfcd2907/include/ignition/math/Matrix4.hh#L673-L685

[chapulina]

@stefanbuettner , after the comment above, do you still think the operator is needed?

[stefanbuettner]

Either the operator or a function which let's me transform a vector from the pose's frame to the pose's parent frame.
I would have expected the operator to be equivalent to

Vector3 Pose3::operator*(Vector3 const& p) {
    return Matrix4(*this) * p;
}

I find the addition and subtraction operators the confusing part. To me the Pose3 represents a transformation from one frame of reference to another frame of reference. Thus I want to concatenate poses (i.e. nesting reference frames) and transform points from one frame of reference to another.

This can also be described by 4x4 matrices. Although I would make it explicit via the Pose3 class.

Pose3d const table; // w.r.t the world
Pose3d const mug; // w.r.t the table
Vector3d const precomputed_grasp_point; // w.r.t. the mug

// I like both
Vector3d grasp_point = table * mug * precomputed_grasp_point;
Vector3d grasp_point = (table * mug).Transform(precomputed_grasp_point);

// Weird
Vector3d grasp_point = table.Concatenate(mug).Transform(precomputed_grasp_point);

Although having a named function for concatenating poses would be weird. But probably just because I'm used to the multiplication operator and see matrices there.

[jrutgeer]

For what it's worth: I want to second this.

Typically you'd name the transformation variables according to their references, e.g.:

Pose3d const T__world__table; // Transforms coordinates from {table} coordinate frame to {world}
Pose3d const T__table__mug; // Transforms coordinates from {mug} to {table}
Vector3d const p_precomputed_grasp_point__mug; // grasp point coordinates expressed in {mug}

Vector3d p_grasp_point__world = T__world__table * T__table__mug * p_precomputed_grasp_point__mug;

Unless it's for a class that has a well-established meaning in mathematics, like Matrix4:

Imo. it is exactly the inverse. There is no mathematical meaning to multiplying a 4x4 matrix with a 3x1 vector. Unless it is implicitly assumed that the 4x4 matrix represents a homogeneous transformation matrix, and that the 3x1 vector represents homogeneous coordinates [px; px; pz; 1].

The way it is implemented does imply this assumption. But this is contradictory with the general constructor which allows you to set all coordinates without restrictions.

But even if the 4x4 matrix represents a homogeneous transformation matrix:
Both a homogeneous transformation matrix as well as a Pose3 represent identical concepts (relative position and orientation of coordinate systems) and hence should have identical semantics.

[stefanbuettner]

Since there is not much of a discussion in the last 3 years and many opinions, let’s just close it. I think it’s not that important.