Re: Gyroscope Code
 

So, speaking as the only person here who has read the spec sheet, this second pwm output gives absolute temperature. There are nice little graphs relating the reading to the temperature of the chip. In that regard it could be useful. I, however, have not tinkered with that particular output.
EDIT: I set up a calibration algorithm that gives an average of the first ten values it pulls from the gyro, and sets that as neutral (after 20 program loops to give it a chance to spinup) So I feel okay ignoring the temperature output.

Re: Gyroscope Code
 

i download the Gyro code and i think the result are not correct because when i move the gyro 90 degrees and back to 0 degrees then i not get the same values

what is the problem ??

-Naor

Re: Gyroscope Code
 

I have a few questions again..

In adc.c, I notice that you divide the accumulated readings, to once again have a value that's between 0 and 1024: But in gyro.c I notice you are factoring in ADC_RANGE in your calculations: I guess I'm just a bit confused as to what is happening here. Is there a bit of math that I didn't think about?

I have it set right now to sample four channels at 3200Hz, and to collect 16 samples before an update. This sets ADC_RANGE to 4096 and ADC_UPDATE_RATE to 3200/(16 * 4), which is 50Hz. So the ADC_RANGE seems out of place. Is the down shift of the accumulator in adc.c not supposed to be there, or is it doing something other than what I think it is?

Re: Gyroscope Code
 

Ugh, I'll have to work through it. The gyro expression looks convoluted because it's hand-tuned to minimize integer division rounding error while not overflowing the numerator. While I'm looking at it, you might consider working through it yourself using dimensional analysis. Keep in mind that gyro_angle is not in angular units <grin>.

-Kevin

Re: Gyroscope Code
 

nvm. I'll just wait for your response.

Re: Gyroscope Code
 

See the attached document for a dimensional analysis of the expression in Get_Gyro_Angle().

-Kevin

Re: Gyroscope Code
 

We had a similar issue today messing around with both the DAA and another <classified> sensor that give a 0-5 volt signal. We're already using the gyro, so we can't use Get_Analog_Value anymore, so instead we've move the code to use Get_ADC_Result(), and I was surprised to get 11-bit outputs (0-2047) on that instead of 10-bit values I was expecting.

Re: Gyroscope Code
 

Yes, this is documented in adc.h and probably adc_readme.txt. The code can oversample and decimate to give you higher resolution data.

-Kevin

Re: Gyroscope Code
 

It's documented in both. We just missed it the first time around since we thought we had adjusted the oversampling rate down to 2 (we hadn't, editted the header in another project directory), so we thought we had an extra bit of precision.

Thanks for all the help. The team's programming team has been very "feature aggressive" this year, so there is a lot of code I'm helping them test and keep track off, and we'd be in a much bigger mess without your help.

Re: Gyroscope Code
 

Thanks for that breakdown! Now I understand.

You actually DO get more resolution from oversampling!

So, at 16 samples per update, I have a 12-bit ADC value, that is completely valid, and does not have to be divided any further. I looked at the code again, and you take 16 samples, then divide by 4, leaving 4*[0, 1023]. This is awesome. 12-bits is exactly the resolution that's required to be as accurate as I need to be in my application.

Previously I had thought that oversampling gave more "resolution" due to the fact that when the samples were completely averaged together, they would just eliminate more noise.

Now I think I understand better.

Thanks again.

Re: Gyroscope Code
 

I wrote a quick whitepaper on this a few years ago. The paper gives a basic reasoning as to why it works along with a few plots to show it in action.

Re: Gyroscope Code
 

Yes, it is completely valid and doesn't need to be divided down further. If you look in adc.h you'll find code like this:
The line "#define ADC_RESULT_DIVISOR 4-2" is where I calculate the number of bits I need to shift right to perform the equivalent division. the 4 is the number of bits I need to shift right to get back to the 10 bit native resolution of the ADC. I subtract 2 from the 4 because I've gained 2 bits worth of resolution, for an effective 12-bits.

-Kevin

Re: Gyroscope Code
 

Hey, this is a great paper. Any chance of expanding it to include a bit more on oversampling and decimation? If you're cool with it, I'll include a link to it in my own documentation.

-Kevin

Re: Gyroscope Code
 

I have a question about the code, how much would the accuracy suffer if I modified how long the gyroscope spends calculating the bias? Is there a graph somewhere which would explain this?

Re: Gyroscope Code
 

Hi Kevin,
I've got the full sized RC running now and I'm trying to merge last year's pid.c/h and robot.c/h with this year's gyro.c/h, encoder.c/h and adc.c/h code. I've got the encoders working fine and adc appears to be working fine (I've hooked up a pot to analog port 2 and called Get_ADC_Result(2) and got good data). I've even called Get_ADC_Result(1) with the gyro hooked up to input 1 and got readings that varied as I moved the gyro around. But I am not getting anything out of gyro.c. The routine I created to start and stop the gyro bias calculation worked fine on the EDU controller with last year's adc and gyro codes. On this year's full size controller all I ever get is a bias of -1 and a heading of 0.

When I run the gyro only code it works fine. It does not like robot.c for some reason. Any ideas?

I should add that I actually started with the 2006 frc_gyro project and added the other files to it so I would not miss anything. I've also disabled the serial ports options related to rx1, tx2, & rx2.

Thanks again for all your efforts!