SRX encoder on toughbox issue

TLDR: If using an SRX magnetic endcoder, and linearity within each rotation is important, ensure that the mounting screws are not in contact with the shaft bearing. Edit - better yet, substitute brass screws for mounting.


Background: I am investigating the transient and steady-state performance of the 100W+ FRC brushed motors (BAG and more powerful)*. My mechanical portion is a gearbox (made up of 5 COTS gearboxes) with all the motors hooked up to the same flywheel, and a TALON SRX encoder mounted to a 3-motor AndyMark Toughbox (AM-2388) using the AndyMark Toughbox encoder mount pad (am-0208a) and the AndyMark SRX encoder mount kit (am-3565). My control system consists of an Arduino Pro Micro (Leonardo compatible, but smaller), Rev SPARK motor controller, and the encoder (with a cable and breakout), and high-level control from my desktop PC.

After getting all the hardware nominally working, my first critical system test was to look at the acceleration of a motor which was transitioned from 0 to 100% duty cycle against the friction and inertia of the system, to ensure that I could, in fact, measure what I expected. I fully expected something approximating an RC (resistor-capacitor) voltage saturating, overlaid with some random spiky noise. Instead, I got the first image below**:

Looking at the right end of the graph, I instantly noticed a strong CW (single-frequency) signal. (If you didn’t notice it, don’t feel bad; I’ve spent the last 30 years doing underwater acoustics, including at least half of that dealing with time series data.) As my eye swept back left, I could easily see the frequency decreasing/period increasing in a way that suggested that the ripple frequency was related to the output shaft frequency. I then added a “spike” to the data each full revolution (4096 samples), then adjusted this to each half revolution (2048 samples). The result follows:

With these spikes, it is clearly obvious that the oscillation is at twice the shaft frequency; each green spike intersects the blue time series near the center of the downstroke.

– More to come, probably tonight –

*My goal is to get a white paper out by year’s end to assist teams in designing their 2019 robots.

** I have the arduino sending a dump of the curve after the fact over USB, then I’m loading the data via notepad and gawk under cygwin into excel for visualization.







Interesting. In your tl;dr you say, “ensure that the mounting screws are not in contact with the shaft bearing.” But the body of the post doesn’t mention anything about mounting screws contacting bearings or any other possible reason for this phenomenon. Is that the more that’s coming later, or is that speculation for now?

To identify the systematic noise, I modified my arduino sketch to allow the motor to spin up to full speed for 2 seconds before taking the samples.

My goal at that point (Saturday noonish) was to reduce (and preferentially eliminate) the systematic noise. However, shortly after generating the second graphic above, I left for some family obligations, but as pereichi was driving, and conversation at mom’s is intermittent, I had a bit of time for thinking this out.

I recognized that much of this was a “predictable” problem that could be improved using post-processing, so I decided quickly to focus on issues that I could resolve/reduce with simple changes. If all or part of the issue was (for example) an encoder design issue, post-processing would be the only solution. So, let’s figure out what can cause an issue which is correctible.

The first correctible issue I identified was if the sensor and rotating magnet were misaligned from each other. However, I realized that a misaligned sensor would “be correct” at two angles, and at “maximum error” at to angles roughly 90 degrees away. The period would then be equal to the shaft frequency, not twice the shaft frequency. (I later eliminated a background magnetic field the same way.)

The first issue I identified which would generate a primary frequency twice that of the rotating shaft was that of sensor angular misalignment. My mental model of the magnetic encoder is that it is continuously calculating the arctangent of the ratios of the magnetic fields in two perpendicular directions (I’m sure there are shortcuts and approximations down inside, but that’s my model.) For argument/modeling sake, I assumed that the magnet was properly aligned. If the sensor was misaligned by an angle phi from the shaft axis, this would reduce the magnetic field by cos(phi) in the direction of misalignment. This would cause no issue in the direction of misalignment, nor perpendicular to it, but would cause an error at the semicardinals of about tan-1(1) - tan-1(cos(phi)).

I inspected the encoder, and found that I had, indeed, tightened one of the encoder-to-bracket mount screws about three turns farther than the other. Equalizing these, I found a minimal improvement. I then tried several different means of keeping the encoder perpendicular to the shaft, with decidedly mixed results - when I put nylon spacers under as well as above the bracket to force both axes to be parallel, the results were actually slightly worse than the original case.

It was only when I noticed just how far down those mounting screws extended when I saw a consistent improvement - they were actually touching the bearing, forming a single ferromagnetic keeper. I clipped them slightly, and again close to the inside of the bracket, and the noise signal fell to about 5dB below the original level at the initial cut, but did not reduce further when I cut them short or flush.

Anyway, still trying to figure out if I can beat the remaining signal, either physically or through signal processing.

A spreadsheet with the original data, original full-speed run, first fix attempt, and clipped-bolts (fix5) runs are attached [also the brass screws mentioned below]. Note that the full speed runs also show the Fourier transform of the data; the harmonic peak stands out well above everything else.

srx-encoder-issue.xlsx (752 KB)

Yes, I was already at the point I posted this morning before I made the original post. Anyway, the posts are now caught up with reality.

I’m going to get some brass or aluminum screws this evening and see if that helps.

Edit: Another improvement - using brass screws (I had to go to 4-40 to source them today), RMS deviation from the mean is now down 6.3 dB from the original full speed test. I also noted that the speed is still slowly increasing after 2 seconds at full speed, so I’ll lengthen that duration later. I have other obligations this evening, but I’ll get back to this tomorrow or Wednesday.