Tuner X Swerve Generator - Invert Pigeon2 Yaw

[jonathandao0]

My team recently tried using the Tuner X Swerve Generator with good results. However, once we tried integrating it with PathPlanner, we noticed our robot had issues following a simple drive straight auto. On further investigation, we realized that the yaw from the Pigeon2 we used was changing opposite of the robot's actual movement. In looking at the Phoenix 6 API, there is no option to invert the rotation of the Yaw using the Pigeon2Configuration() or using the SwerveDrivetrainConstants to invert the Yaw. We attempted to change the MountPose in the Pigeon2Configuration(), as well as use Tuner X to change the MountPose on the Pigeon2 by changing the pitch/roll orientation to +/- 180 to see if this would work as an inversion, but it did not. Is there no way to do this in software with Phoenix 6?

[CoryNessCTR]

On further investigation, we realized that the yaw from the Pigeon2 we used was changing opposite of the robot's actual movement

The Pigeon 2 should report positive rotation with counterclockwise rotation, which is expected in WPILib and PathPlanner, is that not the case?

If it's not the case, can you take a self-test snapshot of the Pigeon 2 while rotating counter-clockwise and send it to us? If you could also send the .hoot file of when you're driving the robot around, that would also be very helpful. You can find documentation on how to retrieve the hoot files here: https://v6.docs.ctr-electronics.com/en/stable/docs/tuner/tools/log-extractor.html

Note we only need the raw hoot files, not the converted files.

looking at the Phoenix 6 API, there is no option to invert the rotation of the Yaw using the Pigeon2Configuration() or using the SwerveDrivetrainConstants ... Is there no way to do this in software with Phoenix 6?

There is no way to change the inversion of yaw, as it's tied to the coordinate system that Pigeon 2 uses. If you need a clockwise-positive yaw, I'd recommend either negating the reported yaw, or extending the class for it, however this is very atypical and shouldn't be necessary, especially for PathPlanner integration.

[jonathandao0]

My team was able to meet up today to look into this further. In looking at the logs, we noticed that the reported yaw was correct. Upon further investigation, we found that we were using getAngle() when looking at the Pigeon2's yaw instead of using getYaw(). After that, were then able to trace down the actual issue with our robot not being able to follow a drive straight: The bevel gear on one of our modules had lost all of its screws, leaving the drive wheel free spinning. So the code was reporting the correct values, but when we drove on the floor, the missing drive output from one of the modules was causing the robot to correct itself, causing it to spin in place which made it look like the gyro output was inverted.