Use of atan2 in SwerveController.getTargetSpeeds taking headingX and headingY arguments

[chauser]

The use of atan2 in SwerveController.getTargetSpeeds flips the X and Y arguments from normal use which is atan2(y,x). This means that, for example, the look* methods in AbsoluteDriveAdv set values for the headingX and headingY variables that don't make sense in the standard coordinate system of the field. I'm not sure what other code has been affected (perhaps direct control of the heading with a joystick?) or if there is some reason for the swap. But it certainly seems strange.
I'm looking at this in the dev branch.

[thenetworkgrinch]

WPILib coordinate system defines Y as towards or away the field wall not alliance wall. Which many teams do not want to think about. Which is why i flip it in atan for them.

[chauser]

OK. If it is working for most teams I can understand. And I certainly don't think it should be changed at this late date in 2025.

For us, we really emphasize using the standard coordinate system everywhere, because having different conventions in different parts of the code leads us to confusion. Shortcuts to avoid thinking about it in one place lead to questions down the road about why it was done that way. In the current instance, we are wanting to create buttons for 60 degree orientations and it's taking a lot of thought to figure out the right combinations of sin's and cos's and signs to match up with the flipped atan2, compared to the thought process for turning to a particular angle in the standard coordinate system.