Motors tab acc values over-estimate high frequency noise

[ctzsnooze]

I have noticed that motor/prop vibration/noise can be reported as 1G in the motors tab graphical display even though I am holding the frame quite still - it could not possibly actually be that high.

I think that the magnitude of the acceleration as displayed is subject to amplitude exaggeration the higher the frequency.

I am aware that the motors tab graphical is dependent on acc_lpf_factor; high values of acc_lpf_factor filter out high frequencies. This can be useful because it allows the user to figure out approximately what frequencies are involved in the display. But only if the user realises this is actually happening. Most do not. If the user is not aware that they are filtering the display with their acc_lpf_factor setting, they get a false impression of the true amount of noise. Worse, changing acc_lpf_factor to higher values will make noise look less of a problem, but actually it isn't reducing the amount of noise getting into the FC, nor is the noise itself actually being reduced. In fact it makes the display 'false' whenever acc_lpf_factor is not zero.

But that's not the only problem, nor is that the reason for the high frequency amplitude exaggeration issue.

< two paragraphs from original post deleted (incorrect) >

Let's say we have a signal generator with fixed amplitude and variable frequency. Let's say the signal reads 0.1G at 10Hz. The same amplitude noise signal at 100Hz will, I think, be displayed in the motors tab as 1.0G. That's because peak instantaneous acceleration of an oscillating object is the product of frequency and amplitude.

I wonder if it might be better to first order LPF filter the accSmooth values in configurator before displaying as acc data for the motors tab. This would stop high frequency exaggeration.

But at least some steps should be taken to display the correct noise amplitude in the motors tab.

Cheers

Chris

[ledvinap]

(please read https://github.com/cleanflight/cleanflight/issues/1014#issuecomment-112771200 first)

The acc output should not be frequency dependent (in sense you describe). IMO it is real higher-frequency noise. There is quite little low-frequency noise when quad is on bech, most of the noise will start at motor rotation frequency. Setting lower LPF cutoff filters motor frequencies more (about lineary), so seen noise is lower.

Value on motor tabs is taken from accelerometer, not gyro. And gyro output is angular rate, so sampling at different frequency wont change output anyway (there is no delta involved)

Setting higher MPU6050 cutoff frequency will allow you to see more of noise entering accelerometer/gyro. Checking both values (no LFP/flight LPF) makes perfect sense ..

As for generator example, measured value should be the same until you get to LPF frequency, then it will decrease linearly (doubling frequency will reduce value in half). Displayed graph will be some curve governed by aliasing effects.

If you use vibrating motor (or unbalanced propeller), acceleration caused by it will rise (prox. linearly) with frequency (=rpm). Filter effect will be applied on this curve, probably resulting in about constant amplitude after cutoff frequency. http://www.precisionmicrodrives.com/application-notes-technical-guides/application-bulletins/ab-004-understanding-erm-characteristics-for-vibration-applications

PID D term is differentiation, so it must amplify higher frequencies (frequency response of differentiation/derivation rises linearly). You usually don't want high-frequency components (mostly noise is in that band), so ideal response is modified to attenuate them. Low pass filtering (filtering before is the same as filtering after computing difference) is one option, Savitzky-Golay differentiation filter is another, or http://www.holoborodko.com/pavel/numerical-methods/numerical-derivative/smooth-low-noise-differentiators/ (see images there).

Filtering accel data before display will be counterproductive - you will simply discard interresting information. Implementing some min/max/avg filter in cleanflight and sending only aggregated values for display may help. Or sample few hundred samples and send them for display, so user seer real data without aliasing.

[ledvinap]

BTW: if you want to play with propeller vibrations, it is possible to use sound card to measure vibration witch much better resolution:

Get some small loudspeaker (some that you can sacrifice). I used one salvaged from some LCD monitor.

Connect loudspeaker wires to directly to microphone input of your sound card, one is shield, other is one of the channels. Extension cable with 3.5mm jacks on both ends helps a lot.

Install VISUAL ANALYSER (http://www.sillanumsoft.org/download.htm) Check that you get some signal from microphone input (enable mic output to speakers and lightly tap speaker cone. enable MIC preamplifier/sec MIC level if necessary). Repeat in Visual Analyser, check that you see signal in upper panel (don't forget to turn it on. Select correct channel). Set fft length to high value (try 32k samples). Maybe set FFT window to flat top (better amplitude resolution, bad frequency resolution).

Attach ~15cm of thin steel wire (about 0.2mm is fine, but not critical. Or use thin carbon rod.) to speaker cone center using hot glue. The speaker should be out of propeller downwash. The wire should ideally transmit only axial vibrations, so it must be thin but must not buckle.

Support loudspeaker so that it points directly at quad frame near motor mount (and is at same height). I use foam pads between frame and table, it may help to get consistent readings. Glue other end of wire to frame (if you have isopropyl alcohol around, use hot glue. It will fall off/get easily detached from most materials when IPA is applied. Test it first ...) Or use other attachment method.

Align the speaker distance so that the membrane is about in the center of travel. Be careful not to damage the speaker (my is surprisingly robust).

Start tested propeller and look at FFT window. Few peaks should appear, you are interested in leftmost one (it is at rotation frequency). Increase speed until it is easy to see. Try rebalancing propeller/motor and check again. The peak value should be quite stable, so it is quite easy to see change caused by balancing. Slight movement of loudspeaker may change results, so check that occasionally (measure - attach piece of tape - measure - remove tape - measure => first and third should be about the same).

There will be second peak on double the first frequency. In my case it is possible to balance propeller so that both peaks have about the same magnitude.

"balanced":

1x2mm of thin tape placed on one blade:

[ctzsnooze]

Wow great post! :-) Your ideas above for measuring noise are very clever indeed.

I had a strange idea, how about hot glueing a mobile phone microphone to an arm as a sensor, it would pick up noise but probably also vibration... :-)

Anyhow back to the original point. I apologies that the original post is wrong in asserting that accSmooth was derived from delta gyro, it comes direct from accADC. I was thinking of EstG, which is used as accelerometer data in pid.c, I got confused between the two. So I've edited the original post now and got the falsehoods out.

But my original point remains I think true.

Let's say I put an AfroMini FC onto a one end of an arm, and hinge the other end, so it can move freely up and down. I then devise a means by which that arm can be moved sinusoidally up and down at variable frequency but fixed amplitude. For example, an eccentric cam under the arm, connected to a variable speed motor, or something similar.

What I anticipate is that the measured acceleration of the flight controller will be linearly proportional to frequency, even if the actual amplitude of the movement of the flight control is fixed. I expect that measured acc values will depend on sampling considerations, obviously, and there will be aliasing issues at higher frequencies. However it is obvious that the peak acceleration at a vibration frequency of 2Hz is going to be twice that of 1Hz and four times that of 0.5Hz - even if the actual amplitude of the vibration is exactly the same at all frequencies.

I guess that's the issue I have with the current display in the motors tab. It isn't possible to see or compare the amplitude of the noise component in the motors tab; we see a value equal to amplitude * frequency.

I would sure love to see a spectrum analyser in the motors tab - especially if we could select the value being displayed - imagine seeing not just say acc data in a spectrum, but say Dterm or Pterm :-)

[ledvinap]

Actually in your case the acceleration will rise with frequency^2 (https://en.wikipedia.org/wiki/Circular_motion)

The value you measure (and are interested in) for vibration is acceleration. You may try to remove influence of rotation speed (calculating unbalance), but IMO it won't work. Transfer function from motor to accelerometer would be necessary.