Pardon? Too noisy, can’t hear you!

The difference between Chloe’s flight in the video, and the ones I tested the day before is the digital low pass filter, or to be more specific the accelerometer’s dlpf since the MPU-9250 provides independent filters for gyro and accelerometer data.

This isn’t the anti-aliasing filter which is applied prior to digital sampling of the analogue  accelerometer at 1kHz – the dlpf is aimed solely at getting the data you want, and not the noise you don’t.  I don’t know what the anti-aliasing filter is set to, but it must be less that 500Hz in the same way music is sampled at 44.1kHz even though what’s nominally audible is below 20kHz – there’s a high-order low-pass anti-aliasing filter just above 20kHz,

Anyway, for the previous flights, Chloe’s accelerometer filter was set to 184Hz on the basis that the higher the filter frequency, the lesser the delay in processing the filter (5.8ms according to the spec).  I dropped it to 92Hz (7.8ms delay), and the improvement was dramatic.

And that suggests the primary cause of my drift now is possibly noise: higher frequency vibrations from the motors (for example) are irrelevant to the flight speeds, but could cause errors in velocity integration because the pass band of the DLPF is set too high.

There’s clearly a balance however which is that if the DLPF is set too low (41, 20, 10 and 5Hz are the other options), while the noise will be filtered out, the risk of filtering out the good stuff increases as does the lag (11.8, 19.8, 35.7 and 66.9ms respectively) i.e. how out of date the filtered data is!  Perhaps that’s where Kalman steps in as it offers a level of prediction (so I’ve read) which could overcome this lag.  But for now, Kalman can continue sitting on the back-burner while I play with the dlpf values to find that magic number between noisy and necessary data samples.

Noise from insufficient anti-aliasing?

CDs store their digital data at 44.1kHz, and when recorded, the analogue to digital converter (ADC) runs with a 20kHz high-order low-pass filter to ensure the 44.1kHz digitization does not introduce low frequency noise through aliasing (sampling at a frequency less than the signal being sampled).

Pretty much all of the noise that’s spoiling the accelerometer readings is generated by Phoebe’s motors and propellers.  That’s proven both by the pre-flight tilt angle calculation which works out the angle of the takeoff platform using Euler angles, and the gravity calibration, both of which work very well because no motors are spinning.  The propellers spin at roughly 5000 RPM or 83Hz.

On the MPU-6050, there are also low-pass filters akin to the CD recording.  From the data sheet, it’s not at all clear whether these are applied before the sensor ADCs (like analogue audio digitizing), nor what order the filters are.

In the code currently, the DLPF filter is set to 20Hz; sensor data registers are updated at 250Hz.  Phoebe reads the output at 50Hz.  At a simplistic level, that says I shouldn’t have any aliasing problems.  So where’s this noise coming from?

I guess that depends on the order of the MPU-6050 low pass filter.  It’s not at all clear from the MPU-6050 spec what order the filter is.  If the LPF is only first order, then 40Hz signals come through at -6dB and 80Hz signals come through at -12dB (I think).  Which means Phoebe’s sampling the data at 50Hz could cause low frequency noise.  She may well be better without the sleep, and so sampling the digital output at 170Hz, or perhaps dropping the LPF to 5 or 10Hz?

At the same time, I need to consider lengthening the complementary filter frequency from it’s current 0.25s to 0.5s or more since it currently seems to filter out much of the useful gyro input to the angle calculations.

And that’s the plan for tomorrow’s good weather testing.