Best gyro for frc.

[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.

[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

[seg9585]

Originally Posted by scottandme

This guy if you don't want to use SPI:

EVAL-ADXRS642Z - about $75 from mouser, digikey, etc

http://www.analog.com/en/mems-sensor...s/product.html

How reliable is this gyro as an analog voltage output? The gyro on the ADXL345 (FIRST Choice, etc) simply didn't work for us, it had way too much drift to be useful. A typical 2-minute match resulted in >45 degrees of drift! Because of this, I've become skeptical of analog sensors requiring integration for attitude/position calculation (too much noise on the A2D probably led to these problems)

[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

[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?

[AustinSchuh]

Originally Posted by seg9585

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

That's what I get for assuming that I knew what chip was on the eval board... Sorry...

Originally Posted by seg9585

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?

We do perform a similar activity. We average 5 seconds worth of data to figure out the offset at startup. This happens currently on our co-processor.

Since the calibration will happen on the roboRIO next year for us, I'd like to improve this process by saving the last 5 seconds of gyro values, and doing the averaging the first time the robot is enabled. I learned this trick from Kiet from the Holy Cows. This lets you not worry about keeping the robot still while booting.

Last time I benchmarked the Gyro class in 2011, I found a horrible lag between angle changes as measured by the encoders, and and angle changes measured by the Gyro class. I was seeing ~0.1 seconds of lag. This was destroying my phase margin and making it very hard to tune the loops. I banged my head against this for about a month before figuring out what was wrong. I've since become very cautious about gyros and how we use them. This was with the KOP gyro and WPILib Gyro class. That lead to us to use ADXRS453, and we have been very pleased since with it's performance.

[Breakaway3937]

I am very new with working with SPI and had a question. How does the startup sequence work for the ADXRS543. We are currently using Labview as our programming language, but i would assume it is the same for all languages. I have been looking at the register and memory values in the datasheet and was trying to get a bead on how to setup the gyro at open and draw the correct values during operation. I have looked over the SPI example in Labview, and have gained a lot of insight on how SPI functions even though the accelerometer has different registry and memory call values.

I would assume I need to set the rate and data format that I read from the gyro.

Thanks for any help you can give.

[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.

[AustinSchuh]

Originally Posted by Breakaway3937

Thanks for any help you can give.

I've been swamped recently with work and team activities, so I don't have time to give you a well-processed answer. I can give you some pointers though. Hopefully they are more useful, not more confusing.

You can download 971's microcontroller code which reads the gyro.

http://frc971.org/content/2014-software

The file you care about is bbb_cape/src/cape/gyro.c. The functions should be reasonably well named, and together with the datasheet, you should be able to figure it out.

[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