Gyro reset() troubles

[otherguy]

We were testing out some autonomous code over the weekend which utilized the gyro for turning. We were noticing that about 50% of the time our code didn't seem to be working. After placing in some debug print statements (see below) we confirmed the source of the problem.
The value printed before and after the reset are quite often the same non-zero number. About 50% of the time. This is quite repeatable on our hardware. I've tried multiple gyro sensors with similar results.

public void resetGyro() {
    double before = getGyroAngle();
    gyro.reset();
    System.out.println("Gyro Before: " + before + " After: " + getGyroAngle());
}

Other than it not resetting reliably, the gyro appears to be working as expected.

I was wondering if any one else was experiencing this behavior. It looks like the gyro.reset() call ultimately just boils down to the following:

NiFpga.writeU32(m_DeviceHandle, kReset_Addresses[m_SystemIndex], 1, status);

I know there were changes made in the FPGA, was a bug introduced?


We have a workaround, but knowing others are seeing this problem would at least restore sanity to my world.

[pblankenbaker]

My understanding of the gyro is that a reset is not instantaneous. It takes a bit of time for the gryo to zero itself and during this time it is best not to move. If you changed your code to the following, you might be more likely to see a value closer to zero:

public void resetGyro() {
    double before = getGyroAngle();
    gyro.reset();
    Timer.delay(2.0);
    System.out.println("Gyro Before: " + before + " After: " + getGyroAngle());
}

Adding delays to wait for the gyro to initialize is undesirable. Our general approach has been:

• Avoid resetting the gyro (maybe reset it once during initialization, but avoid it during the autonomous and teleop periods).
  
• Make autonomous turns based off the current gyro setting. For example, if the want to rotate 90 degrees, use (90.0 + getGryoAngle()) as your destination instead of resetting and using 90.0.
  
• Add a smart dashboard button to reset the gyro while testing.
  
• Determine a gain correction for the gyro and apply this to each reading. For example, if you rotate the robot 10 times and the gryo reports 3500 degrees, the gain correction would be (3600.0 / 3500.0) and you would then multiply the raw values reported by the gyro using this gain correction factor.

Hope that helps,
Paul

[Joe Ross]

Originally Posted by pblankenbaker

My understanding of the gyro is that a reset is not instantaneous. It takes a bit of time for the gryo to zero itself and during this time it is best not to move. If you changed your code to the following, you might be more likely to see a value closer to zero:

The gyro open performs a gyro calibration which takes several seconds, but is blocking. Gyro reset does not calibrate and should be quick. It's just zeroing the accumulators. I wonder if there is a synchronization issue and a tiny delay would make it work reliably.

We also never reset the gyro except at the beginning of autonomous, and track everything relative to the starting angle. It ends up being much more accurate if you ever want to come back to the starting angle.

[otherguy]

Yea I was wondering if the gyro zeroed after the reset() was called myself, our command code was running after the code I listed above. This code was also printing out the current gyro angle. In the innumerable times I executed code, I never witnessed the current angle to suddenly jump to zero (what you would expect to happen if it were time related).

We are latching in our current heading at the beginning of commands as a workaround. There still seems to be a bug though.

Would anyone mind instrumenting their code and seeing if the problem is present on your hardware as well? All of my crios are tied up at the moment.

[Jared]

The reset() method is a bit goofy. It does some type of calibration with the cRIO when you call it, which can take up to a second to complete, or sometimes happens instantly.

The reset method not only sets the current angle to zero, but recalibrates and adjusts some unknown thing in the FPGA by writing some random value to it's memory.

To avoid this, I don't ever call their reset method, but instead add my own that will subtract the angle that was measured at the time of the reset from the current angle. This just zeros the angle rather than doing some weird calibration sequence.

[BradAMiller]

As Joe pointed out, the reset() method only zeros the accumulator as you can see in this code from the Gyro class:

    public void reset() {
        if (m_analog != null) {
            m_analog.resetAccumulator();
        }
    }

I'm not sure why it isn't resetting immediately unless, as was suggested, there is some delay in the hardware. I'd also suggest to try adding a delay after doing the reset to see if it makes a difference.

Let us know if that helps.

[otherguy]

Originally Posted by BradAMiller

I'm not sure why it isn't resetting immediately unless, as was suggested, there is some delay in the hardware. I'd also suggest to try adding a delay after doing the reset to see if it makes a difference

As I stated in my last post, we had a command executing after the reset method was being called. The command was printing out the current gyro angle. If the gyro didn't zero after the reset call, it never was zeroed.

I don't think this is time related.

And I've never had to wait for the reset method to zero the gyro in the past. We've used this method extensively in the past and have never had a problem with it previously.