Caveat: Mag encoders near motors susceptible to EM noise

This is obviously a problem in theory, but it’s still nice to have empirical verification that it matters in practice:

I’ve now gotten characterization data from two different teams using mag encoder mounts right next to their CIM motors, and the data show an unmistakeable pattern of velocity noise proportional to motor speed. The only parsimonious explanation for this is electromagnetic interference from the motors.


Teams should keep this in mind when deciding which encoders to use, and where to mount them.

Thanks to @Redrield and @anon12642235 for sharing their drive data!

Edit: If anyone wants to investigate this with motors other than CIMs, it would be appreciated. The plot above is generated by the frc-characterization toolsuite.

13 Likes

Based on that picture, I wonder if the problem isn’t due more to the encoder cable draped over the motor, as opposed to the encoder itself.

5 Likes

Very possible. Here’s a pic of the other team’s setup:

More investigation would always be a good thing!

2 Likes

Have you looked at the same results with an optical encoder? Depending on how the velocity is sampled, the effect of quantization error can grow with the velocity. This was very obvious with the encoder decoding in the cRIO, less obvious with the higher sample rates in the roboRIO.

2 Likes

I’ve looked at more characterization data plots from optical encoders than I can keep track of, and never seen this noise pattern there. It is almost certainly EM noise.

1 Like

This is really interesting. My first guess would have been that if the velocities are being pulled from Talons over CAN and the default status frame rates / velocity sampling periods are used, it would cause some inaccuracies in the recorded data, but I suppose you’d see a more piece wise looking graph in that case?

I might see if I can borrow a nice fancy DSO from my dad’s EE lab to see if I can capture some of this noise in more detail and determine if it’s EMI screwing with the hall sensor, or noise being picked up by the data cables.

4 Likes

If this is a case of EM interference, would placing a running motor next to a static encoder produce noise in the position measurement?

3 Likes

Are you connecting the encoder to the Roborio or to a Talon SRX?

If you are really getting EMI, you can try wrapping aluminum foil around the lenght of the ribbon cable to form a shield. The shield should be connected to the 0V at the Roborio or motor controller. This should reduce the noise pickup. It would also help to route the cables away from the motors and the wires between the motor and motor controller as much as possible.

You can also try running an AC powered drill near the ribbon cable (no shield) to see if the noise gets worse. The brushes from the drill throws off quite a bit of EMI.

One last test is to disconnect the motors from the motor controller and push the chassis across the floor as fast as possible. This eliminates the PWM at the motor controller as a possible source of EMI. If you still get noise in your data, it could be quantization noise in the timer circuits connected to the encoder inputs.

Do the optical encoders pass their information into the TalonSRX before being sent through CAN to the roboRIO?

Have you tried shielding the encoder wiring and re-running the tests?

It’s very hard to draw conclusions from this data without having a control data set. Some data with the encoders (and wires) far away from the motors would make this more scientifically robust.

By popular demand, here are some corresponding plots from other setups:

Neo:

Talon w/ encoder not near motors:

Optical encoder going to the RIO:

The noise pattern from the setups with the encoders next to the motors is unique and extremely robust.

Note also that the structured nature of the EMI appears to cause much bigger corresponding artifacts in calculated acceleration than the more or less random noise of the other setups. This is interesting, and probably deserves more investigation.

4 Likes

I am going to reiterate the suggestion that you repeat the test with the motor controller output inactive so that there is no EMI to evaluate how much quantization noise you get in the circuitry that measures the timing of the signals coming from the encoder. You are digitizing the output of the encoder and the timer circuits in the Roborio or the Talon SRX do not have infinite resolution so at some point, the quantization noise will become evident as noise in the values measured.

Repeat the test, but just take the pinions off the CIMs.

You’ll still get the EMI, but you won’t be confounding it with motor velocity measurements. Anything non-zero the encoder measures will be directly attributable to EMI noise.

4 Likes

As I mentioned in the OP, this is not my data so I’m not in a position to run another test at the moment.

Regardless, it is almost certainly not quantization error as there’s no reason that would scale the way this noise does, there’s no such noise in the NEO plot (even though the NEO encoder resolution is much lower), and the magnitude of the noise is not consistent with the scale of the quantization error.

Anybody happen to know what rates the Rio can reliably measure?

The default RIO loop frequency is 50Hz.

Thanks. Apparently, I wasn’t that clear. I’m asking a somewhat different question.

Let’s say my encoder generates pulses at a rate of 10 kHz. Well the Rio pick up all 10,000 in a second? What if it’s 100 kHz?

This isn’t academic. The Rev hex encoder will generate 4096 pulses/8192 transitions per revolution. Put that on a 4" wheel going at 14 ft/sec, and you’re already at 54 kHz/108 kHz.

1 Like

The rio decodes encoders at 40 MHz. We’ve hooked a 256 PPR encoder directly up to a 775 Pro and it could read it no problem. There is no way you will be outrunning the FPGA with current hardware. And it can do 8 of these in parallel.

3 Likes

Wow. I wish I had seen this about 16 months ago. I actually abandoned a project to measure torque vs speed curves for partial throttle positions because I couldn’t get rid of this noise for nearly a year. I verified I was centered, used brass screws on the encoder, tried a steel spacer to clean up the fields, but nothing hardware I tried worked enough to make any difference.
After about a year break and another month of occasional evenings, I finally worked out a way to integrate through it (full revolution samples), and am nearing the end of rebuilding my test rig to produce longer timelines (bigger, faster flywheel). In the rebuild, I did reconfigure to get the encoder away from the big motors on a hunch, but I haven’t run anything with it yet; I’m waiting on a couple of parts from AndyMark to resolve some mechanical interference resulting from the lower gear ratio I figured out how to solve this issues with less than $1 in hardware from my local Ace this afternoon.

Doing the math: looking at my gear ratio from the old setup, the CIM vane rate (rate at which CIM coils pass a given angle, 3x the CIM shaft rate) was 6.43x the output shaft rate; the CIM shaft rate was 2.14x the OSR. My highest speed tests didn’t energize the CIM or mini-CIM, but the RedLIne. (I have six motors on this gearbox, and I energize one in each test and will later short another in my load tests.) As such, I think it was likely the fixed magnetic field of the nearby CIM and mini-CIM that caused the issue. In the new configuration, the encoder is on the RedLine/775Pro/BAG side, where it is further away from the magnets due to VP gearboxes on those motors shifting them away from the motor plate of the TB 3 motor gearbox.