I have been looking into this further in order to understand what was going on with the gyro and the segoway demo. I was finding that the the gyro angle would increase from 0 to about -45 in the first 60 seconds of balancing.
Looking at the gyro values in a static situation, although after recalibrateOffset a call to getAngularVelocity returns a velocity of zero once in the main loop getAngularVelocity initially returns a value of about -2. This is consistent over many runs (and for recalibrateOffsetAlt).
Clearly a non-zero value would affect the gyro angle (time integral) adversely. I note that in the segoway code there is a correction to the velocity value with a smoothed offset,
- Code: Select all
gOffset = EMAOFFSET * gyroRaw + (1 - EMAOFFSET) * gOffset;
The value of gOffset starts at -2 and moves to 0. However over this period the gyro angle moves from 0 to -45, even though the gyro doesn't move.
Although this offset correction is useful to correct the initial mismatch of the velocity reading a side-effect is that when the gyro is moved the new angle value is "corrected" back to the stabilisation value of -45, resulting in incorrect values for the angle.
Alternatively if I skip the calibration and set an offset of 587 then I get velocity readings of around 0. And if I avoid the offset smoothing then the gyro angle is reflected correctly.
Where does the offset of -2 come from?
Is there any benefit to using recalibrateOffset?