Team2168 / 2015_Main_Robot

Source code for the 2015 season
2 stars 0 forks source link

SPI Gyro Calibration #56

Closed NotInControl closed 9 years ago

NotInControl commented 9 years ago

The SPI gyro calibration method needs some love, and a logic check. There may be a problem with it, when dealing with negative numbers.

In short, ensure that it cals as expected in all use cases. Also need to add a loop which senses drift and recalls automatically

jcorcoran commented 9 years ago

I modified the calibration sequence. I don't think you would have been able to calibrate more than once with the old code. This code in particular

angle += (currentRate * deltaTime) - accumulatedOffset * deltaTime;

The first time through accumulatedOffset is zero, so it's not really affecting calculations of the angle term at all. But on subsequent calls to calibrate, the accumulatedOffset will likely be non-zero, which means that the old (bad) accumulatedOffset value would be used to calculate a the new one:

accumulatedOffset = (angle - accum) / calibration_timer.get();

It makes more sense to me to just accumulate your drift rate for the duration of the calibration time period. Then once the calibration period is done, normalize the drift rate over that duration of time. The calibrated offset value shouldn't care about angles. All you're trying to figure out is what the rate is for 0.0 deg/sec.

The way I wrote it, you should be able to monitor the gyro angle while calibration is active, which should be cool as you should be able to see the live data slowly stop drifting.

Doing it this way also has the side effect of allowing you to stop the calibration sequence at any time. Hence the reason for me adding some methods which would allow you to do just that.

Your last bit about recalibrating automatically shouldn't be done within the Gyro class in my opinion, as the gyro can't tell if its reporting higher than normal drift rates because the calibration is bad, or if it's because the sensor is actually moving. I think something similar to what we did last year (conditionally recalibrate the sensor from within Robot.java disabled) would work best.

If you're dead set on letting the sensor re-calibrate itself. It might be worth looking at having the calibration sequence run until the %change of the drift rate is below some pre-defined value. The only problem with this is the cal. sequence wouldn't be deterministic, it could run forever.