Gyro inconsistencies...

[Jake M]

After two days of testing, I'm pretty sure our gyro gives slightly different output, depending on which direction it's turning. For instance...

Counter-Clockwise
-----------------
1771
1777
1773
1771
1775
-----------------
Clockwise
---------
1802
1796
1800
1806
1800
---------

These are outputs given after resetting the angle to zero and slowly turning the gyro exactly 180 degrees. As you can see, the clockwise direction is quite near perfect, but the other direction is always off. You can also see that both directions are very consistent. If I re-calibrate based on the counter-clockwise direction, then the clockwise direction is consistently off.

I'm not really that worried about 3 degrees, but what I've found is that because of this, when the gyro turns far from zero, it doesn't go back to zero at the same position, and I can easily see that error compounding very quickly, particularly since the gyro seems to be less consistent the faster I turn it, and I doubt the robot will want to turn as slowly and carefully as I am.

Is this really all that strange? Should I just reset the heading to zero whenever I actually need to use it? Should we perhaps invest in a better quality gyro?

Settings and such...
-------------------
ADC Sample Rate of 1600Hz
32 ADC Samples per Update
Deadband set to 16 (Deadband and Bias double when resolution goes from 2048 to 4096)
Using ADXRS150

[7-11number1]

Originally Posted by Jake M

After two days of testing, I'm pretty sure our gyro gives slightly different output, depending on which direction it's turning. For instance...

Is this really all that strange? Should I just reset the heading to zero whenever I actually need to use it? Should we perhaps invest in a better quality gyro?

Settings and such...
-------------------
ADC Sample Rate of 1600Hz
32 ADC Samples per Update
Deadband set to 16 (Deadband and Bias double when resolution goes from 2048 to 4096)
Using ADXRS150

Jake,

We are just now getting to the GYRO. I am not sure if you've seen this link from the Killer Bees Team but this is where we are starting for our Gyro primer.

After this weekend I should be able to let you know more once we get the gyro up and running. Also, the GYRO from last years KOP had a faster response in terms of measuring DPS (Degrees Per Second). Could measurement lag be causing your measurement anomaly?

Please let us know how it works out, and if you wouldn't mind sharing your Gyro code we would like to see it.

-Michael

[DonRotolo]

Remember that this is a Yaw Rate Gyro, key word being Rate. This gives an output in degrees per second, so in other words it measures how FAST the sensor is being turned - NOT how much it has turned.

If you multiply the rate times time, then you get amount of turn. But, how you do that multiplication can introduce errors if the rate is not exactly constant. That could be the source of your error, perhaps.

Try to eliminate that source of error by turning at as constant a rate as possible, and not very slowly - about 90 degrees per second is probably a good rate.

EDIT: Make sure you're turning the gyro about it's real axis, which is not the axis of the PC Board!

Don

[Jake M]

Perhaps I should have mentioned that I'm using Kevin Watson's background gyro code (gyro.c and gyro.h) as well as Kevin's ADC code.

And although the gyro is turning slowly and not at a constant rate, that shouldn't make much difference, since I'm the one turning it both times and I've been taking care to be consistent in that respect. Plus, since the individual sets of numbers (clockwise and counter-clockwise) are so consistent, that suggests that the error is internal, not external.

I just thought someone with more experience working with the gyros might have come across this before.

[Russ Beavis]

A couple of things to keep in mind about gyros -

1) you could be experiencing an error due to nonlinearity (although the 1.5% difference between your CW and CCW results is a bit higher than the spec for the gyro)

2) you may still have some residual offset error in the gyro (most likely in my opinion)

3) your gyro may be "leaning" when turning CW instead of CCW (or vice versa) and causing an effective gain change (but again 1.5% is a bit high since the "lean" would have to be about 10 deg of tilt (cos(10) = 0.985))


I'd recommend running the same tests that you've been doing (specifically duration of time) but without any physical rotation. I'm guessing that you'll observe a non-zero heading at the end of the time interval (probably 1.5 degrees).

Russ

[Jake M]

No, the time span is only just a few seconds, and it takes a couple minutes for the heading to change when immobile.

I'll dig out another gyro or two from our sensor box tomorrow and see what kind of results I get.

[Russ Beavis]

I don't know the details of Kevin's code but I wouldn't be surprised if the code "ignores" small non-zero readings. That is a very simple but technically insufficient way to keep from "runaway" due to integration of a small non-zero output.

The proper way to dedrift a gyro is to use an absolute reference (eg compass and inclinometer). Since an absolute reference is typically too expensive for applications like ours, a SW solution with a band clamp is often used (as in Kevin's code?).

I'll bet that there's still a non-zero offset in the readings but it's being masked by a nonlinear bit of SW.

There is another possible culprit - ADC resolution. This could be affecting either the null cancellation or the value that's reported when it's actually spinning. Depending on the rate at which the gyro is rotating and a number of other factors, ADC resolution could come into play. I'd be very surprised, however, since there is almost certainly more "noise" in the gyro output than ADC resolution and the effective resolution is usually fine.

Russ

[Kevin Watson]

Originally Posted by Russ Beavis

I don't know the details of Kevin's code but I wouldn't be surprised if the code "ignores" small non-zero readings. That is a very simple but technically insufficient way to keep from "runaway" due to integration of a small non-zero output.

This is exactly what my code does, although Jake's deadband setting of sixteen DN seems excessive. I strongly suspect there is something wrong with Jake's gyro because the code works really well with the gyros I have on hand (several ADXRS150s, two ADXRS300s, one Systron Donner from the 2005 KOP, and several Silicon Sensing Systems' CRS03s). As I mentioned here, I have a CRS03 that ran for nearly two hours with less than two degrees of drift using the default ADC settings. One of my ADXRS150s will do nearly as well as that CRS03. Jake, if you can, try a different gyro because what you're seeing isn't typical behavior.

-Kevin

[Russ Beavis]

Jake,
What is your rotation rate? How fast are you turning 180 degrees?

Maybe you're getting close to saturation. Aren't the gyros set for 90 deg/sec max rate this year or are they really set for 150 deg/sec?

Russ

[Jake M]

This year's gyro is actually set to 80 deg/sec, but I was using one of the older years, at 150 deg/sec.

The 16 for deadband is actually the defualt of 8 that you provided, since I raised the ADC resolution from 2048 to 4096. The gyro bias doubled in the same way when I raised the resolution.

I'll probably end up putting the ADC back to default, because raising the update rate and resolution doesn't seem to have made any difference.

I know we have some other ADXRS150's from past years somewhere, I just need to go find them tomorrow. We had to call of building for today.

Thanks for the input, everyone. In the end, I think the bulk of what I'll use the gyro for is to back up the basic driving output (our frame tends to pull slightly to the right) for which I'll only need to use the rate. As a programmer, little problems like this just tend to bug me if I can't explain them.

[Jake M]

I plugged in this year's brand new gyro and it's the same story. Clockwise and Counter-clockwise measurements are consistently about 2.5 degrees apart from each other. It must have something to do with how I'm mounting and testing it. I'm just going to calibrate it for counter-clockwise, which will be the main turning direction this year, and leave it at that.

Thanks for all the help, everyone.

[tseres]

keep in mind that those readings are in 10ths of a degree, so you have to knock off the last digit. both directions are pretty near 180 degrees (179,180)

[Jake M]

Which is another reason why I'm not going to worry about it.

[Bongle]

If you get two gyros with the same specs, what if you mounted one with its axis of rotation opposite the other (i.e. upside down)? That way, while one was rotating CCW around its axis, the other would be rotating CW. You could probably implement some software error elimination by averaging the two ouputs or only taking the reading from the one that is currently rotating in the 'correct' direction.

[Jake M]

If I cared that much, I would just implement two GYRO_CAL_FACTOR's, one for each direction.