Best gyro for frc.

[stufflikethat]

I have been looking into different gyros online for an offseason project and am not sure which one to go with. The applications will be at least as demanding as FRC if not a good bit more. This means we would like minimal drift and for it to remain accurate under high acceleration.

Anyways could any teams who use gyros in their robot tell me which gyro they used and if they recommend it. (Shoutout to 1717 and 16, you all probably have good gyros for your swerve, it would be greatly appreciated info)

[connor.worley]

1538 had very good results with Analog Devices gyros.

[RyanCahoon]

I used a ADXRS453 for the NASA Sample Return Challenge this year and was impressed with the performance for the cost.

[Mike Bortfeldt]

I had a opportunity to test several different gyros (from two different manufacturers) on an FRC robot for a personal project and like the others, I would recommend the Analog Devices gyros. The one I am currently using is the ADXRS450 (similar to the ADXRS453 above - except without the internal temperature compensation) and it works well. If price isn't an issue, higher quality gyros are available with some excellent specs, however they typically run more than $1000.

Mike

[AustinSchuh]

I used a ADXRS453 for the NASA Sample Return Challenge this year and was impressed with the performance for the cost.

We've been using that gyro as well, and it works incredibly well. Very low drift, very low acceleration -> yaw coupling.

[AdamHeard]

We've been using that gyro as well, and it works incredibly well. Very low drift, very low acceleration -> yaw coupling.

2 years in on the same gyro for us, I wish we had used it with our swerve in 2012!

[Mk.32]

We've been using that gyro as well, and it works incredibly well. Very low drift, very low acceleration -> yaw coupling.

Is there a place to get an pre-made IMU for this gyro? Quick googling doesn't seem to bring up anything state side.

[Mark Sheridan]

Is there a place to get an pre-made IMU for this gyro? Quick googling doesn't seem to bring up anything state side.

The part # for the evaluation board is : EVAL-ADXRS453Z

Mouser and digikey sell these.

Never actually used this but I had it bookmarked to buy eventually.

[Jduffy]

We tried to use an MPU6050 breakout and arduino last year, but combining everything fairly difficult, so we just bought a nav6 from kauai http://www.kauailabs.com/store/index.php?route=product/product&product_id=50
They're $70, but designed to work with a cRio out of the box, and will probably work with an rRio with a serial cable. It worked over usb to my computer, and the new rio runs linux, so it should be fairly easy to set up.

We used it to make our swerve field-centric, and it only floats by a degree or two throughout the match, which is about as good as you'll get with a cheap chip gyro.

If you want to make your own, arduino and an MPU6050 is a good place to start, there are several good libraries and explanations to get you up and running fairly quickly.

[AustinSchuh]

Is there a place to get an pre-made IMU for this gyro? Quick googling doesn't seem to bring up anything state side.

At some point, I'm going to make a board for it for the roboRIO. Given my schedule, don't hold your breath for it... It will most likely be available through WCP.

[slibert]

We tried to use an MPU6050 breakout and arduino last year, but combining everything fairly difficult, so we just bought a nav6 from kauai http://www.kauailabs.com/store/index.php?route=product/product&product_id=50
They're $70, but designed to work with a cRio out of the box, and will probably work with an rRio with a serial cable. It worked over usb to my computer, and the new rio runs linux, so it should be fairly easy to set up.

We used it to make our swerve field-centric, and it only floats by a degree or two throughout the match, which is about as good as you'll get with a cheap chip gyro.

If you want to make your own, arduino and an MPU6050 is a good place to start, there are several good libraries and explanations to get you up and running fairly quickly.

If you want to use the arduino and the MPU6050 and assemble something yourself, I highly recommend you ensure that the interrupt pin from the MPU-6050 is connected to the Arduino. This will allow interrupt-driven operations which is the way to get good performance. If you go to the nav6 website (https://code.google.com/nav6) you'll see schematics that show how to hook it up. All the nav6 open source code is available there too - and it's Arduino-compatible w/an Arduino UNO.

Do keep in mind that the MPU-6050 is a 3.3V part, and isn't 5V tolerant, so you'll need to take care of that. The nav6 does that, and also allows powering directly off the 12V robot battery.

One of the nice things about using the nav6 firmware, even if you assemble it yourself, is it will work w/all the WPI classes (java, C++) as well as w/the LabView VIs (these are also on the nav6 website). A few people who have the RoboRio beta systems are testing out the nav6 on the RoboRio, and although I haven't got word yet how well it's working for them we expect it should work just fine.

If you have any questions, please contact me at scott@kauailabs.com.

[Breakaway3937]

2 years in on the same gyro for us, I wish we had used it with our swerve in 2012!

Hey Adam,

I noticed that the pin out on these gyros are different from the KOP sensor board. How would you interface these with the control system we have with FIRST. I know you have to set up a SPI connection with SCLK, CS, MOSI, MISO, I just have no background with this.

EDIT: Found it. For anyone who wishes to know how to wire the ADXRS453. It is just like the accelerometer. You will take the SCLK, CS, MOSI, MISO to the DIO pins 1-4, doesn't matter really what order, and can power it from the 5V or Ground located below the DIO pin 1 location. Thanks all and hope this helps someone else out.

[seg9585]

I assume you use the SPIDevice class in Java (for example)? If so, can someone with experience using the ADXRS453Z provide feedback on the correct bit order, clock polarity, clock rate, and frame modes?

Any sample code you code provide would be helpful, which could help avoid hours of troubleshooting.

[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-sensors/mems-gyroscopes/adxrs642/products/product.html

[AdamHeard]

Austin Schuh is really the best to answer those questions here.

Colin Wilson (254>973>254) made ours, and could also answer but he's less active on here.

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

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]

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

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

http://www.analog.com/en/mems-sensors/mems-gyroscopes/adxrs642/products/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]

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?_trksid=p2055119.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

-Hugh

[seg9585]

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]

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


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]

Here is a nice one.

http://www.ebay.com/itm/291208070192?_trksid=p2055119.m1438.l2649&ssPageName=STRK%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]

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]

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]

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]

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]

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]

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]

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]

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?

[Cash4587]

Has anyone thought about making an aftermarket board that plugs straight into the expansion port on the rRIO that includes a gyro built in as well as pwm expansion and dI/O and analog expansion?

[seg9585]

Has anyone thought about making an aftermarket board that plugs straight into the expansion port on the rRIO that includes a gyro built in as well as pwm expansion and dI/O and analog expansion?

Gyros are very sensitive to electromagnetic fields, this may be a problem so close to the roboRio.

Even if it wasn't, the chip I tried in particular is a single-axis gyro and will require more precise mounting on the robot. Many teams like to mount cRios/roboRios vertically or in a way convenient for troubleshooting or maintanence. Maybe an embedded 3-axis gyro would solve that problem, like the rRio's 3-axis accelerometer.

[seg9585]

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):
http://eric.segonline.net/2014/frc/gyroboard.jpg

Serial Output:
http://eric.segonline.net/2014/frc/drift.jpg

[Andrew Schreiber]

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?

Looks like you already figured it out, the returned value will always be a multiple of 4.

I'd be willing to bet doing the SPI write yourself would be more efficient but it's probably not a huge deal. The only reason I did any tests was I needed faster executing digital writes. It was mostly an example of how the wrapper library is pretty inefficient.





Mounting the gyro near the roboRio probably won't be an issue. Every time I've run a gyro has been an analog gyro, the issue was that the signal got messed up by the magnetic fields caused by currents driving motors. Minimizing transmission distance should help you there. But this gyro talks SPI so it's less susceptible to that issue.

[AustinSchuh]

Mounting the gyro near the roboRio probably won't be an issue. Every time I've run a gyro has been an analog gyro, the issue was that the signal got messed up by the magnetic fields caused by currents driving motors. Minimizing transmission distance should help you there. But this gyro talks SPI so it's less susceptible to that issue.

You can also throw a ground plane under the gyro to block most of the magnetic fields that might be there. That's good practice anyways.

[ayeckley]

You can also throw a ground plane under the gyro to block most of the magnetic fields that might be there. That's good practice anyways.

Not to bust your chops, but that's true for electric fields -- not so much for magnetic fields. Effective magnetic shielding requires the use of a material with a high magnetic permeability such as Mu-metal (Carpenter Specialty Alloys). Rolled foil copper such as that found on PCBs has little effect.

[AustinSchuh]

Not to bust your chops, but that's true for electric fields -- not so much for magnetic fields. Effective magnetic shielding requires the use of a material with a high magnetic permeability such as Mu-metal (Carpenter Specialty Alloys). Rolled foil copper such as that found on PCBs has little effect.

I wasn't quite sure that I hadn't mixed the two up when I wrote the post. Thanks for calling me out on it :o

[slibert]

Has anyone thought about making an aftermarket board that plugs straight into the expansion port on the rRIO that includes a gyro built in as well as pwm expansion and dI/O and analog expansion?

Kauailabs will be announcing exactly what you describe on January 3.

[mman1506]

Kauailabs will be announcing exactly what you describe on January 3.


Awesome, any plans to offer official Python support?

[AdamHeard]

Kauailabs will be announcing exactly what you describe on January 3.

What gyro specifically?

Thanks

[slibert]

What gyro specifically?

Thanks

Invensense MPU-9250 (9-axis sensor).

Plus an on-board 32-bit ARM microcontroller, providing motion processing and calibration algorithms for accelerometers, gyros and magnetometers. Minimal yaw drift due to filtering/fusion algorithms. UART, SPI, I2C and USB interfaces. Open source hardware and firmware. C++, Java and Labview libraries for the Roborio will be available, too.

[slibert]

Awesome, any plans to offer official Python support?

We'll be providing Java, C++ and Labview on the Roborio, and we also will provide sources for apps in Java (Processing) and C# on a PC.

If you would like to discuss Python development, please contact me at scott@kauailabs.com. You'll need to decide if you want to interface serially (UART/USB), I2C or SPI.

[AdamHeard]

Invensense MPU-9250 (9-axis sensor).

Plus an on-board 32-bit ARM microcontroller, providing motion processing and calibration algorithms for accelerometers, gyros and magnetometers. Minimal yaw drift due to filtering/fusion algorithms. UART, SPI, I2C and USB interfaces. Open source hardware and firmware. C++, Java and Labview libraries for the Roborio will be available, too.

What are you looking at price wise?

Available kickoff? Through andymark?

[slibert]

What are you looking at price wise?

Available kickoff? Through andymark?

Available soon after kickoff. At Andymark. Pricing details to be announced on Jan. 3.

[mman1506]

We'll be providing Java, C++ and Labview on the Roborio, and we also will provide sources for apps in Java (Processing) and C# on a PC.



If you would like to discuss Python development, please contact me at scott@kauailabs.com. You'll need to decide if you want to interface serially (UART/USB), I2C or SPI.


Cool, thanks. Out of interest what arm platform are you using (Si Labs, ST etc)?

[slibert]

Cool, thanks. Out of interest what arm platform are you using (Si Labs, ST etc)?

STM32F411 @100 MHz; firmware developed in Eclipse C++, debuggable over SWD port with a ST/Link V2 adapter.

[philso]

Not to bust your chops, but that's true for electric fields -- not so much for magnetic fields. Effective magnetic shielding requires the use of a material with a high magnetic permeability such as Mu-metal (Carpenter Specialty Alloys). Rolled foil copper such as that found on PCBs has little effect.

Increasing the distance to the source of magnetic field interference is also very effective. The strength of the coupling is inversely proportional to the cube of the distance.

[Jared]

Not to bust your chops, but that's true for electric fields -- not so much for magnetic fields. Effective magnetic shielding requires the use of a material with a high magnetic permeability such as Mu-metal (Carpenter Specialty Alloys). Rolled foil copper such as that found on PCBs has little effect.

I don't think you'd need mu-metal to shield because it's a higher frequency magnetic field. The new victors switch at 15 kHz, so copper, aluminum or preferably steel may make an effective shield. That said, if your problem is due to the DC magnetic field from something like the battery cable, copper or aluminum won't do much. However, the DC magnetic field is much weaker than the fields from the motors, which are quite noisy. The motors brushes create lots of really high frequency em fields that can be blocked by copper.

The best way to solve the interference problem is to twist the gyros signal and return cable. The two conductors act like a loop which pick up the magnetic field from your motors. Twisting these two conductors will decrease the effective loop area and greatly reduce the interference. You can prevent common mode interference with a grounded shield on the conductors.

Increasing our switching frequency to 15khz makes interferences problems 15 times worse than the 1khz.

[ayeckley]

I don't think you'd need mu-metal to shield because it's a higher frequency magnetic field.

I intended to speak in very general terms only. I agree that mu-metal is of little benefit in the FRC context, but for different reasons than what you are referring to. Philso's approach (above) certainly offers the highest bang-to-buck ratio. The last time I had to buy mu-metal (~1994) I think the minimum order quantity was 1000 lb. It's also nearly the same density as lead.

The motors brushes create lots of really high frequency em fields that can be blocked by copper.

Would there not also be a "low" frequency (<2 KHz-ish) magnetic field associated with the fundamental brush-pass frequency, in addition to the broad, higher-frequency spectrum you described? I'm being wishy-washy on the exact frequency because I don't recall the armature design of the CIM. I don't believe I've ever had one apart, personally.

The best way to solve the interference problem is to twist the gyros signal and return cable. The two conductors act like a loop which pick up the magnetic field from your motors. Twisting these two conductors will decrease the effective loop area and greatly reduce the interference. You can prevent common mode interference with a grounded shield on the conductors.

Strongly agree. Also effective for E-field shielding.

Increasing our switching frequency to 15khz makes interferences problems 15 times worse than the 1khz.

Not sure I agree there, but that's off-topic.

[Jared]

Would there not also be a "low" frequency (<2 KHz-ish) magnetic field associated with the fundamental brush-pass frequency, in addition to the broad, higher-frequency spectrum you described? I'm being wishy-washy on the exact frequency because I don't recall the armature design of the CIM. I don't believe I've ever had one apart, personally.

You're probably right here. I know that brushes can radiate a lot of electromagnetic fields over a large range of frequencies including some higher frequencies (well over 15kHz), but I don't know about the lower end and how strong different frequencies are. If the lower frequency fields are the problem, then I agree, twist and try to move farther away.

For higher RF frequency, you don't need to have a high permeability to block magnetic fields. I think the 15kHz frequency is in this higher range where it's easy to shield with conductive metals.


Not sure I agree there, but that's off-topic.

A higher frequency magnetic field causes more interference, both common mode and differential mode.

The noise that's induced to the gyro's signal through differential mode interference (meaning your gyro's cable is acting like a loop, picking up the magnetic field) is proportional to the effective loop area, the strength of the magnetic field, and the frequency of the field. Each time the motor's power switches from on to off, faraday's law says that some voltage induced in your gyro's signal. If the event happens 15 times more often per unit of time, you get 15 times more noise.

For common mode interference, which is when both your return and signal are affected in the same way, a higher frequency magnetic field will provide more opportunity for parasitic capacitive coupling to ground.

However, the higher frequency may be easier to shield from, but I don't think I've ever seen an FRC team use shielded cables for anything before.

[Bryce2471]

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.
Sorry I'm a little late to the party on this thread. As far as this gyro goes (ADXRS453), it looks like there are two packaging options (ADXRS453BEYZ and ADXRS453BRGZ), I'm wondering which one you would recommend, and how you interface with it.

Thanks in advance.

[RyanCahoon]

As far as this gyro goes (ADXRS453), it looks like there are two packaging options (ADXRS453BEYZ and ADXRS453BRGZ), I'm wondering which one you would recommend, and how you interface with it.

Unless you're designing your own PCB, you probably want to just get an evaluation board - EVAL-ADXRS453Z. The SPI interface pins are broken-out to through-hole contacts that are easy to solder to.

digikey product page (http://www.digikey.com/product-detail/en/EVAL-ADXRS453Z/EVAL-ADXRS453Z-ND/2700448)

[seg9585]

Unless you're designing your own PCB, you probably want to just get an evaluation board - EVAL-ADXRS453Z. The SPI interface pins are broken-out to through-hole contacts that are easy to solder to.

digikey product page (http://www.digikey.com/product-detail/en/EVAL-ADXRS453Z/EVAL-ADXRS453Z-ND/2700448)

And you'll have 6 wires in total (labeled on the breakout board): PDD, GND, CS, MISO, MOSI,CLK (Pdd = 3.3-5V). CS is held low during read/write operations, and the other pins are wired to the SPI interface on the roboRio (or Arduino, or cRio)

[Matt10010010010]

What are you looking at price wise?

Available kickoff? Through andymark?

Hey AdamHeard,

The NavX is on Andymark website for $99.00.
http://www.andymark.com/product-p/am-3060.htm

[ayeckley]

The NavX is on Andymark website for $99.00.

They are currently showing "out of stock". Do you believe that is incorrect, or is it possible that they've sold out already? Will you be able to resupply them "quickly" if that's the case? To me, "quickly" (given that we're at the start of build season) would be within two weeks.

[slibert]

They are currently showing "out of stock". Do you believe that is incorrect, or is it possible that they've sold out already? Will you be able to resupply them "quickly" if that's the case? To me, "quickly" (given that we're at the start of build season) would be within two weeks.

They should be available at Andymark in about one week. Andymark is recommending interested parties click on the "email when available" link to be informed when they are available.

[juchong]

Figured I'd clear up a couple of responses in this thread.

Gyros are very sensitive to electromagnetic fields, this may be a problem so close to the roboRio.

Even if it wasn't, the chip I tried in particular is a single-axis gyro and will require more precise mounting on the robot. Many teams like to mount cRios/roboRios vertically or in a way convenient for troubleshooting or maintanence. Maybe an embedded 3-axis gyro would solve that problem, like the rRio's 3-axis accelerometer.

Incorrect. MEMS devices are manufactured using non-ferrous materials, thus making them immune to strong magnetic fields. A single axis gyro simplifies the mounting on the robot. You only have one axis to worry about! The ADXRS450/453 are "rate gyros" which mean that they are designed to only report back...rate... in one axis!

Sorry I'm a little late to the party on this thread. As far as this gyro goes (ADXRS453), it looks like there are two packaging options (ADXRS453BEYZ and ADXRS453BRGZ), I'm wondering which one you would recommend, and how you interface with it.

You probably want the ASXRS453BRGZ version since the sensor will be easier to solder onto a PCB and the measured axis is located through the center of the part. You would solder the sensor down to the PCB just like any other IC. I would recommend purchasing the breakout board, though!

The 450/453 differ from the gyros used on the AndyMark breakout board in that the Analog to Digital conversion is performed within the sensor. This makes them much less susceptible to EMI. In an ideal setting, you would want the accelerometer attached to a rigid portion of your robot, and the gyro would be located as close to the center as possible.

Although the 6-axis and 9-axis sensors are cool, they are not designed for precision navigation applications. Noise levels on those sensors are orders of magnitude greater than what's available on application-specific sensors. I would strongly suggest that teams invest some time looking into the 450/453 if they want to have a solid drive system.

Another caveat of systems such as the nav6 is that they are not calibrated. Each sensor is unique and will provide a slightly different response when used in different applications. In that case, an integrated IMU such as ADI's iSensor (http://www.analog.com/en/mems-sensors/mems-inertial-measurement-units/products/index.html) product line would be ideal.

[slibert]

Figured I'd clear up a couple of responses in this thread.



Incorrect. MEMS devices are manufactured using non-ferrous materials, thus making them immune to strong magnetic fields. A single axis gyro simplifies the mounting on the robot. You only have one axis to worry about! The ADXRS450/453 are "rate gyros" which mean that they are designed to only report back...rate... in one axis!



You probably want the ASXRS453BRGZ version since the sensor will be easier to solder onto a PCB and the measured axis is located through the center of the part. You would solder the sensor down to the PCB just like any other IC. I would recommend purchasing the breakout board, though!

The 450/453 differ from the gyros used on the AndyMark breakout board in that the Analog to Digital conversion is performed within the sensor. This makes them much less susceptible to EMI. In an ideal setting, you would want the accelerometer attached to a rigid portion of your robot, and the gyro would be located as close to the center as possible.

Although the 6-axis and 9-axis sensors are cool, they are not designed for precision navigation applications. Noise levels on those sensors are orders of magnitude greater than what's available on application-specific sensors. I would strongly suggest that teams invest some time looking into the 450/453 if they want to have a solid drive system.

Another caveat of systems such as the nav6 is that they are not calibrated. Each sensor is unique and will provide a slightly different response when used in different applications. In that case, an integrated IMU such as ADI's iSensor (http://www.analog.com/en/mems-sensors/mems-inertial-measurement-units/products/index.html) product line would be ideal.

I absolutely agree that there are much higher noise levels on 6/9-axis sensors, and the dedicated yaw-rate gyro like the ADXRS453 is a very good sensor for the field-oriented drive application. The 6/9-axis sensors in the nav6 are consumer-grade (e.g., iPhone, Oculus Rift), rather than the industrial grade of the ADXRS453.

However - please be aware that the nav6 is definitely calibrated, as it features factory-calibration of accel/gyro biases, and also continually re-calibrates the gyro biases during periods of non-motion (accounting for gyro temperature changes). This behavior, implemented in the Invensense digital motion processor (DMP) silicon and the on-board microcontroller, is what enables the yaw error rate of approximately 1 degree/minute. The navX MXP features the 2nd-gen MPU-9250 w/even lower gyro noise levels - so we're seeing this technology continue to improve and mature as the MEMS noise levels decrease, and the implementation of the data fusion and calibration algorithms continue to improve. More info on the gyro/accel calibration is available at: https://code.google.com/p/navx-mxp/wiki/GyroAccelCalibration

The nav6 technology does require about 16 seconds of calibration time before a match, during which the robot must be held still. The navX MXP lessens this period, but this may be a difference between the two approaches worth noting.

The nav6/navX MXP technology is cost-effective and viable for use in a field-oriented drive system. Several teams have been doing this successfully, and enjoying the ease of integration it provides. Sounds like a bake-off between a ADXRS453 and a navX MXP would be helpful to the CD community....

[Tom Line]

Ok - so when wiring up this Gyro, what goes where?

Gyro Ground to Roborio SPI Ground
Gyro Mosi to Roborio SPI Mosi
Gyro Miso to Roborio SPI Miso
Gyro PDD to Roborio SPI 5V power (datasheet says 3.3 to 5)
Gyro CS to Roborio SPI CS0
Gyro Clk to Roborio SPI Clk

Do I have this correct?

Since my experience is with analog gyros, what type of data am I going to see over the SPI interface that I will have to use to calculate bias and integrate to angle with?

[ArthurA]

Our team took up writing and providing decent drivers for the MPU6050 (http://www.gearbest.com/development-boards/pp_22492.html?currency=AUD&gclid=CjwKEAiAlvilBRC5ueCzkpXb4kgSJADxop1BoGSA6gcX mNgtS9vFE2T_U8PB8fGL48Jqs24T9vzQDRoCzQfw_wcB) as one of our offseason projects last year (2014) and had good results. We have very little drift (ie a couple of degrees every couple of hours, though we have yet to record exact results). We have a nice, cheap, solution that has been tested on a BBB and a raspberry pi, and we have half ported working code for the roboRIO (also working on using the MXP breakout board with it):
Links:
For BBB and Raspberry PI: https://github.com/thedropbears/DropBoneImu
For roboRIO (WIP, but it works): https://github.com/thedropbears/lib-4774

Documentation:
http://thedropbears.org.au/wiki/index.php/DropBone_IMU

Edit: Add link to documentation

[wireties]

Ok - so when wiring up this Gyro, what goes where?

Gyro Ground to Roborio SPI Ground
Gyro Mosi to Roborio SPI Mosi
Gyro Miso to Roborio SPI Miso
Gyro PDD to Roborio SPI 5V power (datasheet says 3.3 to 5)
Gyro CS to Roborio SPI CS0
Gyro Clk to Roborio SPI Clk

Do I have this correct?


We are wiring one up also. This pinout looks correct but I am unsure of one connection. Does MOSI connect to MISO on the other side? We'll find out this weekend I reckon. Has anyone written a class just for the ADXRS453 on the roboRio they might share? Will ADXL345_SPI (with relevant mods) work?

TIA

[Alan Anderson]

Does MOSI connect to MISO on the other side?

No, MOSI connects to MOSI. It stands for Master Out Slave In. It's an output from the roboRIO and an input to the connected device.

[wireties]

No, MOSI connects to MOSI. It stands for Master Out Slave In. It's an output from the roboRIO and an input to the connected device.

Thanks!

[juchong]

We are wiring one up also. This pinout looks correct but I am unsure of one connection. Does MOSI connect to MISO on the other side? We'll find out this weekend I reckon. Has anyone written a class just for the ADXRS453 on the roboRio they might share? Will ADXL345_SPI (with relevant mods) work?

TIA

There is demo software already written in LabVIEW for the 450/453, but I haven't seen anything for C++ or Java. Might want to check the examples!

I should also have a nice RoboRIO solution for the 345 & 453 that teams might be interested in looking at!