What’s a good way to compute a relatively smooth acceleration profile using velocity readings from the SRX Mag encoder?
Acceleration is just the change in velocity over time. So, if you take the difference between two velocity data points and divide by the time between those two points, you will get acceleration.
I don’t have any experience with the SRX encoder velocity data. If it is noisy, it will produce noisy acceleration data. There are ways to smooth the data by taking averages over a number of readings and by using overlapping “windows” of data. But I would try the simple method first and see how the results look before deciding whether you need smoothing.
If you can try taking a derivative
7 Likes
FYI: You have actually asked about two things. To break it down:
Taking a Derivative
The Derivative is the mathematical operation which calculates the rate of change of a function. By calculating the rate of change of velocity, we by definition compute acceleration.
It will take many different forms. However, in software, I prefer this definition:
Assume a periodic loop update at a rate of T_s seconds. For a certain sample index n, given a velocity reading from the encoder v[n], the acceleration a[n] is calculated by the formula:
a[n] = \frac{v[n] - v[n-1]}{T_s}
Smoothing the Result
Can you quantify, or further describe, what “relatively smooth” implies in your application? Averaging, Median, and Low-Pass filters can help reduce noise in the reading, but can also add inaccuracy and phase delay. Choosing a filter requires knowledge of the situation to know if its appropriate or not.
2 Likes
The SRX magnetic encoder is really noisy when it comes to trying to find acceleration, apparently due to magnetic interference from the motor; I’ve been working on it off and on for a year. The best solution I’ve found so far (I’m using an arduino in register mode, not via the libraries.) is to record the time in microseconds the encoder moves 1024 quadrature ticks (1/4 turn), then use the change in speed across one turn. This works pretty well down to at least 5 rev/s (300rpm), but at that speed your acceleration will be 0.2 seconds time late (less at higher speed); this wasn’t a problem for my application. The acceleration is then really clean from 300 rpm to 1000 rpm, but picks up some ripple which isn’t too bad until past 2000rpm.
The reason I went with a full revolution is that the magnetic speed variation I see when operating at a constant throttle has significant Fourier components at 2x and 4x the output shaft rate.
2 Likes
Thank you! These are helpful observations, Gus.
The 2x and 4x harmonics are caused by deviations from ideal roundness and concentricity between the stationary sensor circle and the rotating target circle. When those circles have small diameter, those kinds of positioning errors can be caused by variation in the placement of printed wiring assemblies relative to the motor’s rotation axis, and by variation of component locations on those assemblies relative to their true design positions. There are several design techniques and signal processing algorithms aimed at mitigating the effects of roundness and concentricity errors, but all of them are compromised by miniaturization. It’s an engineering trade-off; smaller and cheaper vs. less usable bandwidth.
If you want to use the acceleration for feedforward, it is almost always a better idea to compute it from velocity setpoints rather than from velocity measurements, as they will be far less noisy.
The 4x is by far the largest component. At 915 RPM, the 2x component is 7dB down, 3x is about 10db down, and 1x is 11dB down. Below that, broadband noise seems to dominate, though other even multiples stick up a couple of dB.
Ugh. I went all acoustician again. 10dB is defined as a 10x multiple of energy. 1dB is around 5/4 or 4/5, and 3dB is close to 2/1 or 1/2. 7dB is basically a factor of 5, 10dB a factor of 10, and 11dB a factor of 12.5 in energy.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.