My teammate didn’t even spin the gyro all the way around, but the numbers just kept going up, even when she stopped.
help?
And we made sure the pwm cables were attached correctly.
There are two outputs on the gyro, one for temperature. and one for turn rate. if you use the wrong outputs, you will get the behavior you described. Check your wiring.
the wiring on it is right, though. we’ve checked it already. Which is why we’re at a loss.
The gyro has to be completely still during calibration (done during open I believe) or you will get the kind of response that you are seeing.
Check it against the manual. A few mislabled ones escaped into the wild. Your result is typical of wiring into the temperature output.
Rate should be on the outside, temp on the inside.
This continuous accumulation also occurred to our gyro, however, mislabeling was not the cause. We desoldered the wires and then resoldered them, and magically the gyro worked. Try that.
Keeping the wires short will also help the drift(lower capacitance).
I do not believe you, yet. Can you please explain your reasoning?
The gyro produces a voltage that will charge the capacitance in the wire. The longer the wire, the larger the capacitance, longer discharge time, longer change in voltage after gyro stops accelerating. It will also catch more noise if the wires are longer.
What you are describing is phase delay. Drift is where the null value (zero turn) drifts away from nominal, which is interpreted as a constant steady spin.
Your comment on phase delay is technically true, but not on a scale that is detectable. A cable that long will contribute a couple dozen picofarads. With a sampling frequency of 62,500Hz and an output impedence of 100 Ohms, you would need to add a couple hundred thousand picofarads to start to change things.
Since the gyro signal is only in the 0-200Hz(ish) range, I’d wager that phase delay will continue to be imperceptible.
However, the noise comment is very valid.
(If you’re using C++, not sure about LabView) Are you trying to read the values using printf or cout? If you output too much it all builts up in the cRIO’s memory and slowly comes out the console, so you might just be seeing old data in your terminal.
~DtD
OK, I am trying to implement an ADXRS300 gyro on our 2009 bot using WindRiver.
I’m starting with a known-good unit from 2008. Using our bench setup, upon outputting printf’s, with the gyro completely stationary, I’m getting a steady increase in gyro angle values that (from memory) is around a degree every five seconds or so. The gyro was stationary throughout the cRIO power-up process, and it is connected to Analog Input #1 on the first input module.
Last year, I used Kevin Watson’s code, with much success. Kevin’s code implemented a rejection deadband (ours was set to the default of 8) to help filter out junk and eliminate drift. Other than SetSensitivity (which I currently have set to 0.005 but will adjust to .00393 now that I’ve found the specific tuning values we used in last year’s code), what other gyro setup/tuning adjustments are possible with WPILib’s C++ gyro code, and how would we implement this tuning?
Thanks in advance,
We had the same problem. We found it to be our code by running the sample gyro code. Also check that the wires are not reversed, I know that this has been said before, but it plagued us early in the 6 weeks.
If the gyro is constantly returning the exact same high angular velocity, then the problem is your wiring. Take a multimeter and check the voltage between one of the red/black wires and the signal wire. It should be about 2.5 volts in correct operation. To confirm if this is the case, set up your gyro class so it uses an incorrect PWM input that nothing is plugged into, and see if the behavior changes.
Also, double check that your using both the correct SLOT and correct channel. If you only specify the channel, it might be attempting to read the gyro off of the incorrect cRio slot.
If the gyro is constantly returning a varying low angular velocity (1 degree every 5 seconds as posted above is about right), then everything is fine and that is expected.
1 degree every 5 seconds doesn’t sound too bad (IE, inline with what I’ve seen with the new control system). You can play with AnalogChannel::SetAccumulatorDeadband if you want to (I think it is a relatively new addition). There was a big thread a few years ago debating whether it was better to have the dead band or not, as having the deadband may throw off the results once you start moving.
You may want to confirm the legality of the ADXRS300 gyro, as Analog devices has stopped making it, and it looks like most suppliers have stopped carrying it.
We observed significant standing-still error with the new control system as well, somewhere around this order of magnitude.
By modifying the Deadband, as suggested, we got much more stable results and still observed good accuracy when moving.
Also, check which analog channel you’re using/try changing the channel. I’m not sure if this is true for everyone, but our module didn’t like using the last analog in when we had the jumper for battery voltage on (Well…I guess we never tested whether it worked without it, since changing the channel worked).
Since it hasn’t been mentioned, could the OP post about how fast the gyro measurement is drifting?
The battery voltage jumper controls what is fed to the last ADC channel on the analog module. You either get to measure battery voltage on that last channel, or you get to hook something up to the last channel header on the bumper and measure that.
So, your experience would hold for everyone on the first cRIO slot since the battery voltage measurement is required by the rules this year.
After using the Reset VI for the gyro in Labview we noticed that the angle toggled between 359 360 and 0. Does anyone else have this issue? We’ve never seen this before with the previous controller and kevin’s code.
I know 359, 360, and 0 are about the same but why would it not be -1 or -2 deg rather than 359 360.