Fix inverse rotation in FTCCoordinates and InvertedFTCCoordinates

[MightyHelper]

ℹ️ I may be misunderstanding the intended semantics here, but I found what looks like a round-trip inconsistency in the FTC coordinate transforms. This PR assumes convertFromPedro() and convertToPedro() are meant to be inverses; if that assumption is wrong, feel free to disregard.

Summary

This fixes the convertToPedro() implementations in FTCCoordinates and InvertedFTCCoordinates so they are the actual inverse of convertFromPedro().

Problem

convertFromPedro() and convertToPedro() appear intended to be inverse transforms between Pedro coordinates and the FTC field coordinate systems.

This also matches the published coordinate conventions:

• Pedro docs define +x to the right, +y upward on the field image, with positive heading counterclockwise.
• FTC docs define the standard field frame from the Red Wall reference frame, with positive rotation also counterclockwise.
• For the normal FTC field, that mapping corresponds to a -pi/2 rotation from Pedro to FTC, so the reverse transform should use +pi/2.
• For the inverted FTC field, the mapping corresponds to a +pi/2 rotation from Pedro to FTC, so the reverse transform should use -pi/2.

In the current implementation, both directions use the same rotation sign, so round-tripping an arbitrary pose does not return the original pose.

For example, with FTCCoordinates:

• convertFromPedro() translates by (-72, -72) and rotates by -pi/2
• the inverse should therefore rotate by +pi/2 and then translate by (+72, +72)

Instead, convertToPedro() also rotates by -pi/2, which breaks round-trip identity.

The same issue exists in InvertedFTCCoordinates with the opposite sign.

Changes

• FTCCoordinates.convertToPedro(): change rotation from -pi/2 to +pi/2
• InvertedFTCCoordinates.convertToPedro(): change rotation from +pi/2 to -pi/2

Impact

This restores the expected identity properties:

• convertFromPedro(convertToPedro(pose)) == pose
• convertToPedro(convertFromPedro(pose)) == pose

for arbitrary poses in these coordinate systems.

References

• Pedro coordinate conventions: https://pedropathing.com/docs/pathing/reference/coordinates
• FTC field coordinate system: https://ftc-docs.firstinspires.org/en/latest/game_specific_resources/field_coordinate_system/field-coordinate-system.html

[Copilot]

Pull request overview

This PR fixes the FTC ↔ Pedro pose conversion round-trip behavior by updating the rotation direction in convertToPedro() so it is the mathematical inverse of convertFromPedro() for both standard and inverted FTC coordinate systems.

Changes:

• Update FTCCoordinates.convertToPedro() to rotate by +π/2 (inverse of -π/2 in convertFromPedro()).
• Update InvertedFTCCoordinates.convertToPedro() to rotate by -π/2 (inverse of +π/2 in convertFromPedro()).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
ftc/src/main/java/com/pedropathing/ftc/FTCCoordinates.java	Fixes convertToPedro() rotation sign to correctly invert convertFromPedro()
ftc/src/main/java/com/pedropathing/ftc/InvertedFTCCoordinates.java	Fixes convertToPedro() rotation sign to correctly invert convertFromPedro()

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

There’s an extra space between the constructor name and parentheses (new Pose (...)), which is inconsistent with the rest of the codebase’s new Pose(...) usage. Consider removing the space for consistent formatting.

[Copilot]

There’s an extra space between the constructor name and parentheses (new Pose (...)), which is inconsistent with the rest of the codebase’s new Pose(...) usage. Consider removing the space for consistent formatting.