Best gyro for frc.

[Aren Siekmeier]

Originally Posted by AustinSchuh

This is on my over-booked TODO list...

We had a co-processor reading it last year. We are putting together a board right now to interface one with the roboRIO. We'll be releasing our beta test code closer to the start of the season. I expect that we should be able to interface with it over SPI.

Austin,

Do you expect any differences between integrating on your co-processor and integrating with the accumulator in the FPGA, in particular with integral error and drift? What was the SPI bus clock speed/integral dt on your co-processor? Do you happen to know the SPI frequency on the roboRIO? (I think I saw 4MHz in a myRIO document...)

Thanks,
Aren

[AustinSchuh]

Originally Posted by compwiztobe

Austin,

Do you expect any differences between integrating on your co-processor and integrating with the accumulator in the FPGA, in particular with integral error and drift? What was the SPI bus clock speed/integral dt on your co-processor? Do you happen to know the SPI frequency on the roboRIO? (I think I saw 4MHz in a myRIO document...)

Thanks,
Aren

Aren,

We integrated in software on our co-processor. Since the gyro is SPI, I'd recommend just doing the integration yourself in software on the roboRIO in a RT thread running at high priority. That's what we'll be doing. I like being able to audit the code, especially for something like a gyro where I've seen horrible bugs in the past. We got 2 ish degrees of error over 2 minutes with the ADXRS453.

I checked our uC code, and it looks like we read the gyro at 200 hz, and ran the bus at 7.5 MHz. 200 hz is above the gyro's bandwidth, which is good.

The roboRIO's maximum SPI clock rate is 500 KHz (as reported by WPILib's documentation.) The datasheet for the gyro lists the maximum clock rate to be 8 MHz, but doesn't list a minimum. This should be fine.

seg9585: This is a SPI gyro (digital). The ADC is inside the gyro chip, and seems to be very accurate from what I've seen.

Austin

[Hugh Meyer]

Here is a nice one.

http://www.ebay.com/itm/291208070192...%3AMEBIDX%3AIT

-Hugh

[aldaeron]

Originally Posted by Hugh Meyer

Here is a nice one.

http://www.ebay.com/itm/291208070192...%3AMEBIDX%3AIT

-Hugh

Yeah but that gyro has to be dithered. Better to get a Zero Lock Gyro so you don't have to dither to prevent phase lock. Or a Fiber Gyro.

[Hugh Meyer]

Originally Posted by aldaeron

Yeah but that gyro has to be dithered. Better to get a Zero Lock Gyro so you don't have to dither to prevent phase lock. Or a Fiber Gyro.

The dithering is built into the device so it is transparent to the user. Why do you see this as a problem?

Stiction is stiction it does not matter what type of device. I thought all laser gyros had to have some form of dithering.

I don't know what you mean by the term "Zero Lock Gryo". I found some information indicating Litton had a system using this term, but didn't find anything that really explained how it worked. (just sales mumbo jumbo) Can you please explain that more or post links please?

-Hugh

[seg9585]

Quick update for anyone interested in using a reliable gyroscope this year:

I purchased the EVAL-ADXRS453Z from Mouser and wired it up + tested on an Arduino this weekend.
Overall I got great results! There was a rate bias (0.417 deg/sec) but when I nulled this out, the bias change was minimal.
I programmed 1 kHz sampling with a 50-sample smoothing which fed into my integrator to calculate heading.

Results: I achieved a maximum heading drift of approx 0.35 degrees/minute. This is highly acceptable for FRC given 2-2:30 minute match lengths.

A few notes:
The Gyro SPI clock runs at up to 8Mhz. My Arduino is capable of 16Mhz but the roboRio can only output 4Mhz. Anyway, I verified the drift was still acceptable when running the Gyro at 4Mhz.

The data is 32-bit MSB, zero polarity and requires Chip Select to be pulled low for data collection.
Rate data is 16-bit and is stored in Registers 25 through 10 as two-complement, so a little bitshifting and data conversion is required.

I plan to implement this with the FRC Java SPIDevice class and will let you know if it performs as well as it is with the Arduino.

[Ether]

Originally Posted by seg9585

I programmed 1 kHz sampling with a 50-sample smoothing which fed into my integrator to calculate heading.

Could you please provide a bit more detail?

It sounds like you were sampling the rate at 1KHz, keeping the 50 most recent rate samples in a ring buffer, and using the average of those 50 samples every 20ms to calculate a new heading. Is that correct?

[seg9585]

Originally Posted by Ether

Could you please provide a bit more detail?

It sounds like you were sampling the rate at 1KHz, keeping the 50 most recent rate samples in a ring buffer, and using the average of those 50 samples every 20ms to calculate a new heading. Is that correct?

Correct -- I accumulated the last 50 samples, averaged the value (divide by 50), and calculated the new heading (this means the heading is updated at 20Hz, not every 20ms).

The reason I had to do this is because the most accurate Timer I could find in the Arduino was only accurate to the nearest 1ms and this introduced significant heading error when calculating time delta, particularly at high rates.

Happy to post my code if interested.

[seg9585]

By the way, this is an inertial sensor along the z axis. Therefore I suspect some of the sensor error could be attributed to Earth's rotation.

360 degrees/rotation * 1 rotation/24 hrs * 1 hr/60 mins * sin(latitude of Los Angeles) = 0.25*.53 = 0.1325 deg/min error from Earth rotation, which accounts for 35% of the error

[Andrew Schreiber]

Originally Posted by seg9585

Correct -- I accumulated the last 50 samples, averaged the value (divide by 50), and calculated the new heading (this means the heading is updated at 20Hz, not every 20ms).

The reason I had to do this is because the most accurate Timer I could find in the Arduino was only accurate to the nearest 1ms and this introduced significant heading error when calculating time delta, particularly at high rates.

Happy to post my code if interested.

What do you mean the most accurate timer was 1ms? Unless you meant microsecond instead of the millisecond I'm assuming that means.

[seg9585]

Originally Posted by Andrew Schreiber

What do you mean the most accurate timer was 1ms? Unless you meant microsecond instead of the millisecond I'm assuming that means.

Hmm, I was using the millis() function and did not realize there was a micros() available. Reviewing the Arduino library I now see it is available, so I'll go back and modify my code to use it. This could help to increase heading sample rates.

[Andrew Schreiber]

Originally Posted by seg9585

Hmm, I was using the millis() function and did not realize there was a micros() available. Reviewing the Arduino library I now see it is available, so I'll go back and modify my code to use it. This could help to increase heading sample rates.

That's what I assumed, do note that micros() returns multiples of 4 (or 8 on 8mhz arduinos).

You might also want to look into using interrupt driven timers.

And while on the topic of timing and arduino, for timing dependent tasks write the code yourself. Tests I did a couple years back showed that there's a SIGNIFICANT overhead for the arduino digitalWrite compared to the comparable C code. I'd always assumed they were just macros but they actually include a fair bit of code.

[seg9585]

Originally Posted by Andrew Schreiber

That's what I assumed, do note that micros() returns multiples of 4 (or 8 on 8mhz arduinos).

You might also want to look into using interrupt driven timers.

And while on the topic of timing and arduino, for timing dependent tasks write the code yourself. Tests I did a couple years back showed that there's a SIGNIFICANT overhead for the arduino digitalWrite compared to the comparable C code. I'd always assumed they were just macros but they actually include a fair bit of code.

As in the long variable returned will always be a multiple of 4 (or 8), or a return of "1" actually means 4ms? If the former, no impact since I am just comparing time now to time at last sample collection.

I'm using SPI.transfer(data), not digitalWrite. Is there a more efficient method than this one?

[seg9585]

Originally Posted by Andrew Schreiber

That's what I assumed, do note that micros() returns multiples of 4 (or 8 on 8mhz arduinos).

You might also want to look into using interrupt driven timers.

And while on the topic of timing and arduino, for timing dependent tasks write the code yourself. Tests I did a couple years back showed that there's a SIGNIFICANT overhead for the arduino digitalWrite compared to the comparable C code. I'd always assumed they were just macros but they actually include a fair bit of code.

I added a calibration task that samples 5 seconds of data at 1kHz and calculates the bias from this. And I used micros() instead of ms counts and removed the smoothing, so now the heading is updated at 1kHz as well.

Result: ~1 deg drift in 10 minutes. I think that'll be good enough.

Photo of the setup (3D printed protective case):


Serial Output:

[seg9585]

Originally Posted by AustinSchuh

Aren,

We integrated in software on our co-processor. Since the gyro is SPI, I'd recommend just doing the integration yourself in software on the roboRIO in a RT thread running at high priority. That's what we'll be doing. I like being able to audit the code, especially for something like a gyro where I've seen horrible bugs in the past. We got 2 ish degrees of error over 2 minutes with the ADXRS453.

I checked our uC code, and it looks like we read the gyro at 200 hz, and ran the bus at 7.5 MHz. 200 hz is above the gyro's bandwidth, which is good.

The roboRIO's maximum SPI clock rate is 500 KHz (as reported by WPILib's documentation.) The datasheet for the gyro lists the maximum clock rate to be 8 MHz, but doesn't list a minimum. This should be fine.

seg9585: This is a SPI gyro (digital). The ADC is inside the gyro chip, and seems to be very accurate from what I've seen.

Austin

Austin -- my reply was directed towards the recommendation of using the EVAL-ADXRS642Z, which appears to be an analog output.

I asked my questions earlier related to the ADXRS453 for which you provided at least some of the information I need to help initialize the gyro in the SPIDevice class. So thank you -- but I do have another question: the FRC-provided Gyro class performed a calibration within its Constructor that, to my understanding, calculated the drift bias it needed to apply to its integrator. It performed the calibration by taking a seconds-long sample of "still" data and averaging the values to find an offset. Did you have to perform a similar activity in your Robot Init method?