Gyro direction : is it part of the interface contract?

[ozrien]

[1] Does the Gyro interface assume a particular direction for increasing heading? [2] If [1] is yes, is it documented? I could have missed it, should it be in the comments? If [1] is no, should the interface include a function so caller can confirm what direction is interpreted as positive?

I think the ADI gyro is positive => right. PigeonIMU is positive =>left.

We (CTRE) might want to make a WPI_PigeonIMU that implements the WPI interface. If [1] is yes and it is positive=>right, we could flip the signage in WPI_PigeonIMU to match, but that might be a source of confusion. Or we could pass it up as is, but then this disagrees with ADI Gyro.

[calcmogul]

We don't have a standard direction for gyros themselves as far as I know. However, MecanumDrive has the following comment for one of its member functions:

   * @param gyroAngle The current angle reading from the gyro in degrees around
   *                  the Z axis. Use this to implement field-oriented controls.

Since the drive classes use the NED axes convention, they expect a gyro angle that becomes more positive with clockwise rotation.

[ThadHouse]

Both the NavX and the Analog Gryo provided in the KOP are right positive for the getAngle() function. I'm pretty sure the ADXIS is as well. So we should make the interface documented on what should be provided.

To add another thing. on both of those sensors they do not roll over at 360 degrees. They are absolute without bounds. (at least with getAngle(), navx has other functions that do wrap at different intervals.

So I agree we should document the interface to make that a part of the contract.

[ThadHouse]

I feel like most gyros are right positive as well. I know the ones we use at work for VexIQ and VexEDR are right positive, however the Lego EV3 one is left positive and it gets really confusing.

[PeterJohnson]

Documented in #1151.