There is some commented code that seems like it should be usable if a team uses a NavX IMU instead of a Pigeon. However, this code uses the Fused Heading and that introduces a couple issues, one major and the other minor.
1) The fused heading needs to be inverted. Near this code, it should be return Rotation2d.fromDegrees(-m_navx.getFusedHeading());
2) The fused heading is not reset when zeroYaw() is called, so pressing Back to activate this code does not do anything.
I would question the use of the fused heading. It seems good, but even the manufacture recommends FRC teams just reset the offset periodically over using the fused heading.
1) The simplest approach which is supported by the navX-sensor libraries is to periodically “re-zero” navX-sensor by applying an offset to the navX-sensor yaw angle. To use this approach, when the robot is in the correct orientation, a driver can press a button which causes an offset to be added so that the reported angle at that orientation is 0.
2) ...The navX-sensor provides a 9-axis “fused heading” which is combined with the drift in the yaw angles....
In practice, FRC teams find that approach 1) is preferred, and given the enhanced accuracy of “Generation 2” sensors this is definitely the recommended approach.
There is some commented code that seems like it should be usable if a team uses a NavX IMU instead of a Pigeon. However, this code uses the Fused Heading and that introduces a couple issues, one major and the other minor. 1) The fused heading needs to be inverted. Near this code, it should be
return Rotation2d.fromDegrees(-m_navx.getFusedHeading());2) The fused heading is not reset whenzeroYaw()is called, so pressing Back to activate this code does not do anything.I would question the use of the fused heading. It seems good, but even the manufacture recommends FRC teams just reset the offset periodically over using the fused heading.