Picking a gyro for field-centric swerve control
 

In 2009, we created a field-centric turret system that let the gunner push the joystick in the direction he wanted the turret to face, no matter what direction the robot was pointing in. The only issue we had with the system was a hard impact would knock the gyro angle off.

In the off season, we've planning on developing a swerve drive, and I'd like to set the controls up the same way. As a result, I already know one of my primary controls problems is going to be how to keep that gyro from jumping out of alignment.

Now, I'm a mechanical guy pressed into work as a controls guy, so I haven't dealt with much of the high level control stuff. I'm sure other teams have dealt with this same issue, but I'll start by breaking it down into possible solutions:

1. First, you could try to use some other system to double check and remove the error. Wheel angle / distance encoders doing dead reckoning would be my first thought, but because the absolute angle of the wheels to the field would be dependent on the gyro they would quickly build up error and not a be a good source of correlation.

2. You could try to sense out-of-bounds conditions and simply ignore them. You could remove changes that exceed the spin-rate of the gyro, or any other odd fluctuations by putting a series of case-statement checks inline that create a correction factor.

3. You could continue to try to improve the gyro itself. I see that sparkfun now sells 1500 degree/second gyros. While I haven't dug into their specs to check if their resolution and drift is still suitable, it seems like you'll reach a point where you simply don't have the issue anymore.

4. A hyrbid of 1: completely remove the gyro from the robot and do angle dead-reckoning using only the absolute wheel angle encoders and transmission encoders.

Has anyone else found a solution to this issue?

Re: Picking a gyro for field-centric swerve control
 

My team built a robot that did something similar to what yours did. However, ours was effective because no matter how many times we bumped into walls, in a two minute time frame our gyro was off at most 5 degrees.

This year we decided to buy a kind of gyro that gives gyros a bad name. Its horribleness could not be put into words.

If you, like we, think that the gyro was programmed and wired correctly, maybe you should try a completely different gyro just to see how that works.

Re: Picking a gyro for field-centric swerve control
 

My solution is to train drivers to drive robot-centric. :)

There are plenty of very good character-centric video games out there, most notably the GBA versions of the Tony Hawk series, that make training for this sort of thing possible.

Not what you're looking for I bet, but the one year I had an omnidirectional robot to drive (in Vex), it got me up to speed fast enough.

Re: Picking a gyro for field-centric swerve control
 

Team 20 did a field-centric swerve drive this year. We used 10 turn pots to sense wheel angle (to allow multiple rotations and remember the position between matches) and the kit gyro. I believe it had about 2 degrees of error at the end of a match. Our driver was great at dealing with error though. He could keep going through 10 minutes plus during practice.

Re: Picking a gyro for field-centric swerve control
 

There's a current bug in the cRIO FPGA image that prevented me from using it in the 2010 BreakAway game, but I am going to be prototyping with this thing like crazy in the off-season:

http://www.sparkfun.com/commerce/product_info.php?products_id=8656

I've been promised that the guys who work on the FPGA will fix it for 2011, so that I can get I2C communication with it working - the compass does clock skewing and the current cRIO implementation doesn't like that. With this sensor, and some well-placed encoders on the drivetrain, I should be able to drive any type of robot anywhere on the field during autonomous AND make the robot do whatever I want during the game (including field-oriented driving). With its integrated 3D accelerometers and the tilt-compensated heading, what more can you ask? :)

-Danny

Re: Picking a gyro for field-centric swerve control
 

Keep us posted, I was planning on playing with a cheaper one this summer myself. I think the one I have interfaces over SPI but we were planning on making it and several other sensors run on a coprocessor anyway.

Re: Picking a gyro for field-centric swerve control
 

Sure, I was thinking of putting it into a white-paper or something if everything works out - including wiring schematics and a parts list. I personally like this rather integrated solution, everything runs off the I2C port on the digital sidecar so I don't even have to document any "custom circuits." I also don't have to write any custom PIC code or anything like that, which makes documentation and replication of my sensor module much easier.

Anyway, I'll certainly document my findings!

-Danny

Re: Picking a gyro for field-centric swerve control
 

That's a pretty awesome unit, but I noticed that it uses 3 mems accelerometers as well. They don't list the maximum DPS of those - but won't they have the same issues we already have with Gyros in collisions?

Re: Picking a gyro for field-centric swerve control
 

I see two relatively simple things that might be done, that are sort of device-agnostic. Rather than focusing on eliminating gyro error, perhaps you could instead make it easier to tolerate.

The first solution (the higher-tech route) would be to use the accelerometers in conjunction with the gyro. Since the majority of the gyro error is accumulated during gross impacts (as opposed to "normal" robot vibration), preserve the "good" value of the gyro until each impact is over. Then, compensate for the FPGA-produced value via addition or subtraction. A more sophisticated version of this approach might calculate the impact vector, and adjust the heading output based on the gyro's directional impact sensitivity (which I suspect you'd have to measure yourself). Dunno, never tried that before; probably not worth the effort frankly.

The second (lower tech) solution is to give your turret operator the ability to re-zero the heading when necessary. For example, whenever the turret passes through an "observed" orientation (0 deg, 90 deg, etc.), give them a button to press which forces the gyro-based heading value to "agree" to that orientation. The upside is that this is easy to program, the downside is that it takes a little more work for the turret operator; ideally it would still result in an easy-to-operate system. We did something functionally equivalent on our Breakaway bot, wherein if things got hinky for the driver he could look at the indicated heading on the dashboard (to verify that it had indeed drifted) and manually re-zero the gyro heading by momentarily reorienting the robot and hitting a "re-zero" button. It sounds a lot more complicated than it was. In the end our competition driver decided that he preferred to operate things robo-centric rather than field-centric but at least he had the option available. Other drivers preferred the field-centric approach.

I'm sure there are other, probably even better ways to do this. I don't think there's a "perfect" gyro out there that will eliminate the problem - best to find a way to work around it instead.

Re: Picking a gyro for field-centric swerve control
 

If the field is flat, I say do away with the gyro and put two encoders on follower wheels. Using this method we get better than one-tenth of a degree of accuracy over many minutes of driving. If the field isn't level (like this year), this becomes a little trickier from a mechanical standpoint of keeping the encoder wheels in contact with the floor.

What we did this year is incorporate a gyro with our encoders. While we were using the encoders for heading calculation (the normal mode of operation), we constantly updated a gyro correction term that forced the gyro heading to be equal to the encoder heading. This corrects for any gyro drift during the time when the encoders are being used to calculate the heading.

When the robot's calculated X coordinate was within an area that we knew an encoder could leave the ground, we switched to the gyro-calculated heading. While using the gyro calculated heading, the encoders were correlated with the gyro to determine if an encoder lost contact with the floor. If so, we calculated an encoder correction term to force the encoder data to agree with the gyro. Once the X coordinate left the trouble area of the field, the robot would switch back to using encoder based headings (using the corrections from the gyro).

Like the previous poster said, you can also include a "Heading Sync" button or a heading trim pot. Those work pretty well when needed.

Re: Picking a gyro for field-centric swerve control
 

We used a vector-based system for our drivetrain this year. We used an X and Y gyro to calculate our first vector, and joystick data to calculate the second. By using wheel encoders rather than the joystick data, theoretically you should get a vector that would be more useful in getting absolute position. (We were only compensating for drifts in the joystick and the tenancy of the wheels to drift.)

Of course, redundancy is good. finding the average value of these, we were recording a 1.8% Margin of Error throughout the CT regional and a 2.1% in Atlanta. While not perfect, it's certainly better than we expected, as we know that our gyros had a 1% drift on the X axis and an 8% drift on the Y. (Found by graphing signal over 100 reads on a stable surface.)

Re: Picking a gyro for field-centric swerve control
 

You lost me there; did you mean X and Y accelerometers? If you really did mean gyro (meaning yaw rate gyro), what axes did X and Y correspond with? Z seems to be the only one of interest...

Re: Picking a gyro for field-centric swerve control
 

Three unpowered omniwheels in a "kiwi" configuration (as the sides of an equilateral triangle, e.g. at 120 degree angles to each other).

An encoder on each wheel.

The entire assembly on a suspension to ensure that it never leaves the ground (assuming a flat-ish field).

Such an arrangement would theoretically give you drift-free position and velocity in R2, and would be robust to collision (as long as the wheels don't leave the ground).

Re: Picking a gyro for field-centric swerve control
 

My team used the kit gyro this year for field-centric control along with 6" mecanum wheels.

We foresaw the issue of the gyro drifting too far that the robot would become difficult to control, so we instructed the driver that if that's the case, to square the robot up against a field element and reset the gyro using a button on the controller.

I don't think we ever got to the point where the driver needed to reset. I know when we tested in a classroom (and were hammering the robot to the point where one of the AM mecanum wheels broke), the gyro didn't drift any noticeable amount (we ran it for about 20 minutes before having to replace the battery, thus resetting the system).

By the way, 2-5 degrees of drift is very hard to notice. Unless you were trying to score a ball from the far zone this year, you'll never need to be *that* precise.

Re: Picking a gyro for field-centric swerve control
 

Worth noting (to anybody that may have missed it) is that the mid-season LabVIEW update included a new WPILIB version of the HolonomicDrive.VI which featured a gyro input to allow for easy field-centric driving. To make it robot centric, the input could be left unwired or forced to "0". Not directly applicable to swerve control, but conceptually relevant nonetheless.

Re: Picking a gyro for field-centric swerve control
 

If your problem is due to gyro saturation caused by bumps then you might
consider another hybrid solution with coarse and fine scaled gyros. Coarse is a high-max-rate-low-resolution gyro and the fine is a low-max-rate-high resolution gyro. Simply switch the heading integrator input from the fine gryo to the coarse when saturation is detected on the fine gyro. This is added complexity, but gives you the best of both worlds of precision and dynamic range.

I would use the encoder heading over this if they are on the robot.....if not , this might prove cost effective.

Re: Picking a gyro for field-centric swerve control
 

One was mounted as documented on the X axis, while the other was oriented 90 degrees to the X, on the Y axis (we used that to do an inverse-pendulum system, so we could balance and travel across the bump)

Re: Picking a gyro for field-centric swerve control
 

What about using a compass. Wouldn't this give absolute position, without the need for gyros? Sure, they're a little more expensive, but their accuracy would be much more than that of a gyroscope.

Re: Picking a gyro for field-centric swerve control
 

Others have reported (and it makes a lot of sense) that the compass modules they've used are very sensitive to the "natural" EMI environment around the permanent magnet motors in our bots. My own limited experience with such modules outside of a FRC environment matches their observations, so I don't have a high degree of confidence in that approach.

Re: Picking a gyro for field-centric swerve control
 

What if you created a "calibrate" mode, where the driver can push a button to recalibrate a gyro to what the compass sensor is outputting when they think there is a significant amount of drift. That way you don't have the interference but you still have the consistency.

Re: Picking a gyro for field-centric swerve control
 

This little 1 deg compass is sure affordable. http://www.sparkfun.com/commerce/pro...oducts_id=7915. Not sure what the output 2.5 deg rms error spectral characteristics are like.

In the short term, the fine gyro could beat this for accuracy given a good initial alignment... but that's tough to do in FRC competitions.
Edit:
I too have not used a compass on an FRC and had this concern. I would guess the EMI noise would be amenable to low pass filtering and used for longer term automatic updating of the integrated rate. But again, we have introduced a two sensor complexity.

Re: Picking a gyro for field-centric swerve control
 

Sounds pretty reasonable to me. The next step would probably be to parse through the compass module (magnetometer module, technically) data sheet to see if there are any "gotchas". I seem to recall that the update rate on such devices might be a little on the slow side, but that may have changed over the years since I did my initial research. Let us know how well it works if you try it...

Re: Picking a gyro for field-centric swerve control
 

The update rate on most compasses I have worked with recently is between 1 and 20 hz.

I may investigate a dual-gyro approach. I tend to think that the fewer moving parts you have touching the ground the better - replacing a gyro is an easy task if it gets broken (and we've never had that happen).

So here's the scheme I intend to use:

ADXRS610 - 300°/s (5 volt supply) $59.95
http://www.sparkfun.com/commerce/pro...oducts_id=9058

Gyro Breakout Board - LPR5150AL Dual 1500°/s (2.7-3.3V supply)
http://www.sparkfun.com/commerce/pro...oducts_id=9412

Adjustable Voltage regulator for 1500 deg/s gyro $1.95
http://www.sparkfun.com/commerce/pro...roducts_id=527

I will monitor the actual rate of the 300 deg/s gyro in code (fast loop). When the values jump within 10% of the upper range, I'll check it against the baseline of the 1500 degree per second gyro. If there is a substantial difference, I'll calculate a correction factor to apply to the 300 deg/s gyro.

So here come the "electrical" type questions. Am I choosing a good voltage regulator for that 1500 dps gyro? What type of drift should I expect out of the 1500 dps gyro, and how accurate will it be over time? Should I be worried about the CRIO being able to accurately measure the .67 mV/deg/s value, or is it capable?

Remember - I'm not a controls guy but I did stay in a Holiday Inn Express last night....

Re: Picking a gyro for field-centric swerve control
 

Are you sure you want a pitch and roll gyro? If you use it to track field orientation you'll have to mount it sideways and "throw away" one output (unless like Golto you have some use for an inclination angle).

If you choose to go with the LM317 you'll need more external components than you might otherwise. I'd consider using the COM-00526 that they offer instead (fixed 3.3V). Be sure to check the reference design shown on the data sheet to see what external parts (typically capacitors) you'll need in either case.

Regarding drift, the only clues are in the datasheet. The "rate noise density" and "sensitivity change vs. temperature" are the parameters of interest based on your question. In theory you can predict drift vs. time based on those parameters, but as a practical matter the answers you get would only apply in laboratory settings. Even if you place very little dollar value on your time, you'll quickly have spent more in doing a formal analysis than in just buying the part and having fun with it. Analog purists who do noise analysis for fun will surely disagree. If one offers to help, by all means accept.

The resolution of the cRIO NI-9201 analog module is 12 bits over a 20V span, which equates to 4.88mv/bit, so even using the 4X output you'll want to add a gain stage to the output of the module if you *really* want the lower end of the 1500 deg/sec. The downside is that any gyro output noise will also be amplified. You might choose to use a gain of about 20 (resulting in 13.4mv/deg/sec, or about 3 LSB). You'll then also need to be careful about how you prototype the circuit (proper grounding, signal routing, filtering, etc.) to minimize its susceptibility to noise pickup from external sources (like motor controllers).

Before you go to the lengths of adding a non-unity gain stage, you might want to try using the 4X output directly into the NI-9201 despite the resolution mis-match, just to see if you can live without the slow rate resolution you are "throwing away". You might be surprised. For what it's worth, we've never been able to saturate even a 150 deg/sec gyro on a real robot, so 1500 deg/sec could indeed be overkill unless you are planning to do something really exotic.

Hope that helps...

Re: Picking a gyro for field-centric swerve control
 

I had considered the LM317, but the 'optimal' input to the gyro is 3 volts, even though it can handle 2.6-3.7 or something near that.

One of the problems we have with older gyros we have in the shop is that we don't know their gains. How to FIND those gains is a mystery to me, so we have several gyros that are really not usable because I don't know how to find the gains to put into labview to get accurate readings.

I was concerned that changing the input voltage will also change the gain requirement: I believe in the datasheet I read that it would, but I might be mistaken. If it does, how do I go about find the correct gain value? Trial and error hasn't worked very well for our other gyros. You get some VERY strange readings even with just small changes in gain.

I like the idea of not having to worry about resistors to get the voltage regulator to the correct voltage: if there's an easy way to find the gain I should be using that sounds like a homerun.

I didn't see a gyro listed in sparkfun that was single-axis 1500 dps. I'm not really worried about that second axis, and for whatever reason the 1500 dps gyro is half the cost of the 300 dps gyro, so wasting one axis on it really wasn't much of a concern.

Re: Picking a gyro for field-centric swerve control
 

Typically:
* Give the gyro an arbitrary gain.
* Zero the gyro.
* Rotate a large, known angle. Typically a dozen revolutions or so.
* Divide actual rotation by measured rotation.
* Apply this to the arbitrary gain.
* Profit!

Varying input voltage will usually affect gain AND offset, so be mindful. Offset error is likely to have a bigger impact.

Resistors are pretty stable over time, but have large birth error. So, I hate using them to set voltages in production ( and almost always go for fixed regulators if I have the choice ), but don't mind them in one-off situations.

As a reminder, you can see what choices I made for the KoP gyro by looking here: http://usfirst.org/roboticsprograms/....aspx?id=16337
To be honest, the unity gain stages are more to protect against mis-wiring than anything else. If I were to do this as a one off or for a more controlled audience, I'd probably skip the output buffering entirely.

Re: Picking a gyro for field-centric swerve control
 

Tom, the approach you describe may or may not work depending upon the requirements you are trying to meet. What is the max rate you expect to see and for how long? Lets say the bump transient is .1 sec constant rate upset... if the upset is only 90 deg we are talking 900 deg/s then what you have is probably ok. If its only 500 deg/s then I would choose a 100 deg/s fine gyro and say 500 deg/s coarse gyro.

The CRIO a/d's have a 5mv resolution without oversampling. For the 5150 this means about 7.5 deg/s resolution. Also, this is really a 6000 deg/s gyro with the amplified output at 4x. The noise density is .175 deg/s/(sqrt(HZ). I believe this is at 1x so with the 140 HZ BW the the 4x noise is 4*.175*sqrt(140) = 8.3 deg/s rms. So you have a total rss accuracy of about 11 deg/s. This could be reduced with oversampling and if you are running at 200 Hz loop rate, you have an averaging reduction of 1/sqrt(20) so the average bias error would be around 2 deg/s. This isn't too bad for a .1 sec interval. But what may kill you is the nonlinearity error of 1%FS= 60 deg/s. This cannot be helped with averaging, so you might be off as much as 6 deg here from the .1 sec transient so the compass is looking better.

If however, you could live with the (fine,coarse) = (100 deg/s,500 deg/s) you could probably beat the compass.

The adj regulator would be fine, but you could save a resistor if you just bought a 3v fixed regulator.

I would also sync the long term average of the coarse gyro to the fine gyro average to mitigate the drift. This is easily done with a low pass (10 sec time constant?) on the error between the two gyros whose output corrects the coarse gyro input.

Opps... this is probably a redundant reply since I didn't see Alex' reply first.

Re: Picking a gyro for field-centric swerve control
 

Unfortunately, estimating the duration and impulse of an impact of FRC robots would be quite difficult - how they hit eachother and what angle would all contribute to the amount the robot spins and how quickly. That's why I took a shotgun approach. A good solid gyro for my 'fine' and the highest dps gyro I could find for my coarse.

The quick calculations you performed are exactly where I need help. If you want gear ratios or bending moments or torques I'm your man.... but I absolutely hated system design, fourier, etc. and I'm afraid I blotted it out of my mind rather quickly after school :D

A benefit of the 500 dps is that it runs on 5V and the voltage regulator could be eliminated.

Just so I'm clear - the higher rate gyro is going to drift more, so you're suggesting using the lower rate gyro to correct the higher rate one. Essentially, saying that when the lower rate gyro isn't turning at a rate that's above it's maximum, you would constantly update a correction factor to minimize the high dps gyro's error from zero. Is that right?

Regarding the compass: what are the rate sensors used for in the compass? Wouldn't they be knocked off-kilter just as much because of a collision?

Re: Picking a gyro for field-centric swerve control
 

Here are my random thoughts on a few things brought up in this thread:

-You should probably integrate the 1500 deg/s gyro in a very fast loop (1 ms if you can) and the 300 deg/s gyro in a slower loop. Doing this will provide plenty of oversampling to gain a few bits of resolution to make it nearly as accurate as the 300 deg/s gyro at a slower sample rate. The only thing is that you'll need to guarantee a very accurate bias calculation for the 1500 deg/s gyro with a lot of samples - you may not want to use the stock bias routine.

-due to noise in the angular rate signal, you'll probably want to check against the 1500 deg/s gyro when above 70% of saturation value of the 300 deg/s gyro (or thereabouts depending on the noise level). Any noise causing saturation of the output voltage will cause your calculated integral to have a permanent offset, and you really don't want that. On top of that, you can get some strange effects when internal op-amps saturate before the on-board filter. I don't want to get too deep into that but I had to do a big study on these affect in accelerometers for a past job - these issues can be pretty hard to track down, so be conservative when getting anywhere near saturation.

- If the A/D converter uses the same reference voltage as the angular rate sensor (i.e. gyro), you're usually good to go. By sharing the same reference voltage, the A/D conversion will be ratiometric to the the gyro signal (i.e. as the gyro signal changes, so will the A/D conversion and the errors will cancel out).

That's all I can think of for now - the commercial is almost over, so it's back to my TV show for now.

Re: Picking a gyro for field-centric swerve control
 

Yes... you are estimating the bias of the coarse relative to the reference rate which is the fine gyro. During start up, the reference rate is zero for both gyros. Once you are going, use the best gyro to be your reference. The averaging time should be enough to give a large number of samples... I would use an averaging time constant at least 100 times the sample period. This would give a mean estimate that is roughly a factor 10 better than the combined noise error rms.
The pseudo code might look like this:

if(abs(fine)> sat_value) // check for saturation
{rate = coarse + bias;} //use corrected coarse if saturated
else
{
bias = bias + .01*(fine - coarse -bias); // compute the bias with an exponential filter tau = 100*dt
rate = fine;// use fine gyro
}

angle = angle + rate*dt; //Integrate rate

Typically, accelerometer sensors rather than rates sensors are used to calculate compass tilt which is needed to determine the horizontal component of the earths magnetic field. Horizontal plane rotations from a robot bump will not cause any compass tilt errors of significance. Low, steady state accelerations however can cause tilt errors.

Having done our simple analysis, the compass solution seems more cost effective since only one cheap sensor (http://www.chiefdelphi.com/forums/sh...d=1#post956268) can be used with no added regulators. Its accuracy is adequate for the field-centric task provided a location can be found on the robot that is free from strong magnetic disturbances. Maybe someone can chime in with some real life FRC testing experience.

But it would be fun to fool with the dual gyro project.

Re: Picking a gyro for field-centric swerve control
 

If you are going to use two gyros, I don't think you should pick and choose between which one you should look at - you should look at both of them!

Somebody a few posts back mentioned using high-pass and low-pass filtering, something I heartily recommend. Subjecting a coarse gyro to a low-pass filter and a fine gyro to a high-pass filter and combining the values should lead you to a value that is extremely accurate, assuming the coarse gyro can handle shocks (robot getting slammed around) appropriately.

Ideally, you'd want a sensor that does not accumulate drift (like a compass) in place of the coarse gyro, but it sounds like the EM situation on the robot is too intense to use magnetic compasses.

Re: Picking a gyro for field-centric swerve control
 

I'd like to caution against live-match calibration. The drivers already have a bit to worry about with the game itself and 2 minutes FLIES BY like there's no tomorrow. Having to line up and recalibrate a sensor on the fly seems simple enough, yet getting the calibration correct during a match will be near impossible without taking many many seconds of match time.

Re: Picking a gyro for field-centric swerve control
 

I feel the same way. It's a good option but I want our drivers focussed on one thing and one thing only - winning the game. Having to worry about our robot malfunctioning is hopefully the last thing on their minds.

Re: Picking a gyro for field-centric swerve control
 

We used the Honeywell HMC6352 compass (I2C), with a look-up compensation table, and two gyros (different sensitivities).

The general scheme for the look-up table was to put the robot on a rotating table outfitted with an encoder on it's shaft. The (encoder - compass) errors were written to the table. The table was indexed using the actual compass reading.

The compass ran at a max of 20 Hz, but the idea was to read it when the rotation rate was low, reset the gyros, and use the gyros (+ last compass) between compass readings.

On the table we were within +/- 3 degs at our max robot rotation rate. And at those rates the compass alone at 20 Hz was almost as good (eliminates a chunk of coding).

The compass needs to be several inches away from the nearest ferrous (or magnetic) component; and some mu metal shielding can be used if needed. Keep the mu metal away from the compass too!

The key is to find a mounting location where the compass readings change monotonically as the robot rotates, otherwise you have a multi-valued function that can't be easily compensated (if at all).

Knowing absolute field heading is of course only one part of this control system.

David

Re: Picking a gyro for field-centric swerve control
 

Enlighten me please, mu metal?

Re: Picking a gyro for field-centric swerve control
 

Mu Metal is used for shielding against magnetic fields.

When I was doing RF, we kept a bunch on hand.

Re: Picking a gyro for field-centric swerve control
 

Product of Carpenter Specialty Alloys [correction: looks like "Mu-Metal" and "Mumetal" are trademarks owned by Telcon Metals; Carpenter produces a higher-performance variant of it]. High magnetic-permeability metal typically in sheet form design to intercept magnetic fields. Loses its effectiveness when work-hardened. Usually has to be ordered by the ton (in my experience, your mileage may vary), so not really practical for teams to use unless they have some alternate means of obtaining it. Oh, and did I mention that it's very heavy...

Re: Picking a gyro for field-centric swerve control
 

I assume it would be used to keep the RF noise from the motors/wires away from the magnetic compass then? What is a good distance to keep it away from the compass? (Other than as far as possible)

Re: Picking a gyro for field-centric swerve control
 

Actually, it attenuates low frequency B-fields (magnetic fields) not the radio-frequency (high frequency) E-field (electrical fields). Similar concept, just different embodiments. Mu-metal can become magnetically saturated if the field strength is high enough, so it's not a fix-all. In the FRC application, the main B-field sources are the permanent magnets in the DC motors. Unlike RF noise, the wires will emit very little in the way of magnetic fields (consult Lenz's Law).

Re: Picking a gyro for field-centric swerve control
 

And here I thought you were talking about Limp Bizkit and Korn.

Re: Picking a gyro for field-centric swerve control
 

Here is what we used:

http://www.lessemf.com/mag-shld.html#276

To use it effectively you should read up on it a bit before using it.

David

Re: Picking a gyro for field-centric swerve control
 

+1 for finding a small-quantity supplier!