[math] Pose2d.minus has unexpected behavior; seems to rotate the translation

[binex-dsk]

[math] Pose2d.minus has unexpected behavior; seems to rotate the translation

[calcmogul]

b.minus(a) creates a Transform2d c such that a.transformBy(c) should equal b. Is that not happening?

new Pose2d(translation - otherTranslation, rotation - otherTranslation);

That's not how Transform2d works. Read https://github.com/wpilibsuite/allwpilib/blob/main/wpimath/src/main/java/edu/wpi/first/math/geometry/Transform2d.java#L29-L37 for an explanation of what it does instead.

[binex-dsk]

b.minus(a) creates a Transform2d c such that a.transformBy(c) should equal b. Is that not happening?

new Pose2d(translation - otherTranslation, rotation - otherTranslation);

That's not how Transform2d works.

Understood, and that's where the confusion comes from. It makes more sense to me that you should be able to subtract the translational and rotational components and have that as a separate method. Having minus be unrelated to that concept and instead into the realm of transformations is rather unintuitive (plus, relativeTo already exists, which minus calls anyway).

[calcmogul]

It's not unrelated though. It's exactly what should happen to make other operations, like linear interpolation, work correctly. We're defining scale(), plus(), and minus() to act like a vector space. What you're proposing would break these invariants.

You can think of the return value of b.minus(a) like the pose b relative to the pose a. Subtracting element-wise doesn't produce the correct result there, and doesn't seem like it would be useful for anything.

[binex-dsk]

Okay, that makes much more sense now, since that's how vector subtraction/addition works. We were thinking about it differently...

However it caused a minor headache for us, since the naming of minus made us assume it was individual subtracting the vector components. Thinking about it now though, we never actually needed the rotational difference so we should've used Translation2d.minus() which gives us what we're looking for. Makes sense now that I understand we were operating on [x, y, t], not [x, y] and [t]. There may be room for improved documentation in case students aren't as familiar with vector concepts.

With all that said, you are correct that it's not actually useful for anything now that I've thought about it, since separate operation on translation & rotation gives you the desired results.

[calcmogul]

There may be room for improved documentation in case students aren't as familiar with vector concepts.

We already document the current behavior to be what I described rather than element-wise subtraction: https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/geometry/Pose2d.html#minus(edu.wpi.first.math.geometry.Pose2d)

[binex-dsk]

Yep that's what made me skeptical, however some of our students understood "relative to" as in translation1 + translation2 and rotation1 + rotation2. There is room for improvement on our end but I do wonder if there is room for more easily accessible documentation on vectors (I think there exists something in frc-docs already) that is directly referenced in Transform2d

[calcmogul]

Vector documentation doesn't seem relevant here though, because Transform2d doesn't use them.