Delay after resetting Gyro

[trilogy2826]

Background:
-C++
-KOP Gyro
-4-Slot cRIO
-Gyro plugged into Analog Channel 1:1

Issue:
After calling gyro.Reset(), it takes approximately 50 to 100 ms for the gyro to zero.

Symptoms:
Our Auto control (where the gyro interface lives) is running in a separate task than MyRobot. MyRobot (when running in auto mode) calls a series of actions, in this case turning the robot to a specified angle.

For each spin request, a new task is created and the gyro is reset immediately after the task runs.
The condition to end the task and permit the next to begin is based on the proximity to the angle goal (in this case within 1 degree). When this occurs, the task exits and is deleted.

One such sequence was to spin the robot Counterclockwise 45 degrees, then Clockwise 45 degrees, for a total of 4 cycles. In competition, this is a very impractical function, but this was used to measure spatial accuracy after several consecutive spins.

So the odd part is that once one spin task is completed, MyRobot calls another. Using a console print of the gyro angle right after the gyro.Reset() at the top of the task shows that the gyro has not yet reset. The issue is that if the gyro has not reset, when the task exit condition is reached, it is incorrectly satisfied and the task exits without doing the intended function.

Through experimentation, adding a simple Wait(x) after the gyro.Reset() in the task allows proper "time" for the gyro to complete the reset. we found the time x to be a little flaky at 50ms and pretty stable at 100ms.

In the end...
After doing some digging, after Reset() is called a few other tasks are generated in the AnalogChannel class, so maybe some delay is inherent with this. It's unlikely that this is a practical issue, I would just like to understand the mechanics behind this and create a discussion on the behind the scenes Gyro implementation.

Thanks in advance for any advice

[Chris Hibner]

I don't use C++ for the cRIO, so excuse me if this is a stupid question: why is the gyro being reset after each maneuver?

[trilogy2826]

In our case, we only care about what that maneuver accomplishes. For example, turn 45 deg, drive 5 feet, turn 45 degrees, etc.

We found that by resetting the gyro before each turn clears the drift inherent in the KOP gyro, producing a more accurate result. We keep track of the overall angle difference from the beginning to the end to be able to correct for any deviation actually incurred.

[Joe Ross]

Originally Posted by trilogy2826

We found that by resetting the gyro before each turn clears the drift inherent in the KOP gyro, producing a more accurate result. We keep track of the overall angle difference from the beginning to the end to be able to correct for any deviation actually incurred.

You can also get the current position of the gyro and add/subtract your turn to get the new set point, and not worry about resetting the gyro.

[Chris Hibner]

If the maneuvers are rapid-fire (meaning your robot is not sitting still for any significant period of time), then resetting the gyro between moves does not buy any protection against drift. However, if you're sitting still for a long period of time, then resetting the gyro immediately before the next move will cancel any drift that occurred while sitting still.

We haven't experienced any more than about 0.5 degree of drift throughout the 15 seconds of autonomous, so we don't even bother doing any resets after auton starts.

I personally don't like the gyro zeroing routine being a black box - your original post seems to show that you've experienced why I don't like it. We actually just read the raw analog voltage and we do our own zeroing routine and integration. My day job involves doing a lot of work with gyros and accelerometers so I feel pretty comfortable doing that, and I was able to guarantee that the zeroing and reset works how I want it to (and it gave me a great reason to show the students a little about calculus and sensors).

If you don't feel like writing your own gyro code, then a good workaround might be to create a separate "maneuver" that is just a gyro reset while sitting still. Do all of the rapid-fire maneuvers without the reset. Then immediately after your sit-still-and-shoot maneuver, call the gyro reset maneuver (which incorporates the 100 ms delay), followed by your next maneuver.

(Note: apalard actually re-wrote a lot of the WPI LabVIEW library for his team. I didn't have the patience for that - I could do my own gyro code in about 5 minutes which is a lot less time than it would take me to figure out what's going on in the WPI lib.)