Gyro's angle value going up

[[HT]3KEZ]

Our team has recently run into a snag in our code where our gyro's angle value goes up by 0.001 extremely quickly. We don't know what it is in our code that causes this, but we would like to remove it if possible. We're using command based Java coding, and can post excerpts of our code if need be. Thanks in advance for any help!

[tStano]

A definition of "Extremely Quickly" is needed. 'Gyro Drift' is a real thing. Its part of the physics of gyros that they slowly get off (roughly a degree every second or three). This is (simply put) because you are taking a discrete integral of a noisy signal. You can compensate by resetting your gyro when you're at a known angle, or with some really fancy code, but slowly counting up is a thing gyros do.

If you are seeing huge jumps, then you may have real problems.

[GeeTwo]

At the beginning of last year's build, we had four working gyros. One went out last year, unrecognized, which ruined our field coordinates mode (We had a mecanum drive train). The symptoms of that dying gyro sound a bit like yours. During the build this year, we've lost two more. We now have one working KoP gyroscope, and it's in the bag. We could not find a "drop-in" replacement online, so instead we've ordered some 3-axis I²C gyroscopes from Pololu. It's on a closeout discount, but being replaced with a compatible upgrade. They had 189 until we ordered 20. We'll figure out how to use them on our practice 'bot next week.

[[HT]3KEZ]

"Extremely quickly" meant that the Gyro's angle value went up by approx. 0.2 degrees per second, so it does sound like it could be gyro drift. If it's just a part of the gyro, can we leave it be without the gyro getting confused? Because that's what the team is worried about so far.

[tStano]

If you're only using it for autonomous, you should be fine, as it will go off by about 3 degrees over the whole period(.2*15).

However, if you're planning to use it throughout the match(a field-centric drivescheme or on an arm or something) you should look into resetting the sensor when its in a known orientation

Alternately, if you know its a constantish .2 degrees per second, you can account for that when you read the gyro. Start a timer and subtract .2*timerReading whenever you read the gyro. This might be a poor solution because its not a constant .2 degrees per second, but it might get you something better than what you have.

Another solution we're considering is noise reduction. Wrapping the sensor in a few layers of electrical tape(to insulate it so you don't short it) and then in aluminum foil should help block some of the magnetic and electric fields present on your robot. It won't eliminate gyro drift, but it might help to minimize the problem.

[[HT]3KEZ]

Alright, thanks so much for the help! We'll definitely look into using one of those solutions.

[faust1706]

A "cheat" we have used in the past is a gyro reset button. That is, when we know we are at 0 degrees, we make the gyro equal zero.

Another more ambitious route is using vision to check the gyro. This was possible in 2011,12,13, and 14 due to static vision targets. All that was needed was a pose calculation.

[GeeTwo]

Originally Posted by faust1706

A "cheat" we have used in the past is a gyro reset button. That is, when we know we are at 0 degrees, we make the gyro equal zero. .

While we have done this manually in the past, thanks for the reminder! We have "curb feelers" that help us square up with the scoring platforms. (See this link for photos. Maybe we can program an automatic reset to either 0 or 180 (whichever is closer to our current value) when both of them have found the ramp.

[Mike Bortfeldt]

Originally Posted by GeeTwo

We could not find a "drop-in" replacement online, so instead we've ordered some 3-axis I²C gyroscopes from Pololu. It's on a closeout discount, but being replaced with a compatible upgrade. They had 189 until we ordered 20. We'll figure out how to use them on our practice 'bot next week.

Gus,

I've used similar gyros in the past and was not happy with their performance. In my experience, the Analog Devices gyros seem to give much better results. It's certainly possible that the newer models from Pololu have improved, and I would be interested hearing your opinion of them.

Mike

[GeeTwo]

Originally Posted by Mike Bortfeldt

I've used similar gyros in the past and was not happy with their performance. In my experience, the Analog Devices gyros seem to give much better results. It's certainly possible that the newer models from Pololu have improved, and I would be interested hearing your opinion of them.

Having learned what I have in the past few days (see this thread on usfirst), I'm not surprised; the gyro class uses hardware acceleration unavailable to an I²C gyroscope. While we will look at the suggestions there, there's the possibility of using an arduino to turn the I²C gyro into a rotation encoder, or just buying an integrated solution. The NavX would also be under consideration if it were actually available.

[FlyOldPlanes]

If you want to null out a small rate like that, you can use the setDeadband method in the Gyro class. we were a little confused since it shows up in the c++ version of the code, but not the java version. Look at the gyro.java code posted here:

https://usfirst.collab.net/gerrit/gitweb?p=allwpilib.git;a=blob;f=wpilibj/wpilibJavaDevices/src/main/java/edu/wpi/first/wpilibj/Gyro.java;h=ea1e1cc301c71243e091206312fa281fb2f5e5 87;hb=HEAD

The setDeadband is not made public, I don't know why. we just copied the code as a newGyro.java class in our project and made it public. It seems to work fine so far. You will lose a little accuracy with a larger deadband, but if it is small, it most likely won't be a problem.

Hope this helps,

Lennie

[Mike Bortfeldt]

Originally Posted by GeeTwo

... While we will look at the suggestions there, there's the possibility of using an arduino to turn the I²C gyro into a rotation encoder, or just buying an integrated solution. The NavX would also be under consideration if it were actually available.

Gus,

If you are looking for a replacement for the old KOP gyro, either the EVAL-ADXRS642Z or the EVAL-ADXRS652Z should work. Both are 0-5v analog gyros and should be a fairly easy replacement for what you are used to. In the past, I've also used an Arduino to do the integration of the gyro rate signal for both analog and SPI gyros - so that is a valid option as well.

Mike

[GeeTwo]

Originally Posted by Mike Bortfeldt

Gus,

If you are looking for a replacement for the old KOP gyro, either the EVAL-ADXRS642Z or the EVAL-ADXRS652Z should work. Both are 0-5v analog gyros and should be a fairly easy replacement for what you are used to. In the past, I've also used an Arduino to do the integration of the gyro rate signal for both analog and SPI gyros - so that is a valid option as well.

Mike

Five thousand dollars for a minimum order of 100? Or is there someone who has them for retail? Actually, even if there is, I'd rather go with the integrated all-axes solution with built-in integration and Kalman filtering at $130 than a single axis analog gyro at $50.

[Mike Bortfeldt]

Gus,

The EVAL parts can be ordered singularly at $50 or $70 depending on the model. Look near the bottom of the web page.

Mike