Advanced LPF filtering

[SVentas]

the overshoot you noticed causes the noise to be amplified.

Very strange conclusion, I would say . The overshoot and ringing of Butterworth, Chebyshev and Elliptic filters is a response to a very special function – step or Heaviside function. All high frequencies from the step function are removed. Overshoot and ringing of the filter is in low frequency region so it is impossible for high frequency noise to get amplified.
The overshoot and ringing effect can be visualized during acc calibration process. When one places FC in level and hits CALIB_ACC button, ACC Z readings suddenly (during one sample) changes from 1G to 0 and stays at 0 for quite a long time. This is a step function and one can see overshoot + ringing on the ACC_Z graph. This is the price we have to pay for really good frequency separation and fast execution time. In the real world under normal conditions it is almost impossible to produce a step function. Therefore overshoot and ringing effect is negligible in filtering process of the real sensors data.
Yesterday I did some modeling and found out that previously proposed 6-th order Chebyshev filter using precision of the float variables rings/oscillates. Oscillations are not observed when using filters of the 4-th order.
To correct the oscillation problem and minimize overshoot in step function responce I calculated coefficients for Butterworth filter. This is the 4-th order IIR filter with 5Hz cut-off (looptime=5000) frequency (more then enough for complimentary filter with gyro_cmpf_factor = 400). Filter doesn’t oscillate using float precission and is implemented as a feature.
To enable Butterworth filter using CLI interface, one has to type “feature IIR_LPF” and acc_lpf_factor has to be greater than 0 (e.g. “set acc_lpf_factor = 10”).

[ABL]

I tested that.
Works great!
No tuning, just put old values here. Flying very well, much better compared to "original" baseflight. At least:
- wobbles on descent: not a lot
- yaw on descent: a bit, compared to ~90° on original baseflight

EDIT: Video about copter stability:
http://www.youtube.com/watch?feature=player_detailpage&v=sDCBvrkeJu0#t=65s
(gyro+acc+baro)
Also, by cropping 2.7K video i cut some oscillations, so they're not visible...
Actually, in fast-forward part it's swinging to sides. Does not visible on other modes (straight "throttle-up", level flying). I will try to lower P values on roll even more, didn't noticed such effect in baseflight.

My settings (not tuned - i just put old values, as said earlier):

Code: Select all

map taer1234
feature ppm
feature vbat
feature motor_stop
feature servo_tilt
feature iir_lpf
set gimbal_flags=16
set gimbal_pitch_gain = 25
set gimbal_roll_gain = -26
set gimbal_pitch_mid = 1350
set gimbal_roll_mid = 1650
set vbatscale = 112
set looptime=5000
set acc_lpf_factor = 10
set p_pitch = 64
set i_pitch = 18
set d_pitch = 30
set p_roll = 64
set i_roll = 18
set d_roll = 30
set p_yaw = 80
set i_yaw = 56
set d_yaw = 0
set p_alt = 18
set i_alt = 11
set d_alt = 7
set p_level = 58
set i_level = 10
set d_level = 20 

[brm]

the overshoot you noticed causes the noise to be amplified.

Very strange conclusion, I would say . The overshoot and ringing of Butterworth, Chebyshev and Elliptic filters is a response to a very special function – step or Heaviside function. All high frequencies from the step function are removed. Overshoot and ringing of the filter is in low frequency region so it is impossible for high frequency noise to get amplified.
The overshoot and ringing effect can be visualized during acc calibration process. When one places FC in level and hits CALIB_ACC button, ACC Z readings suddenly (during one sample) changes from 1G to 0 and stays at 0 for quite a long time. This is a step function and one can see overshoot + ringing on the ACC_Z graph. This is the price we have to pay for really good frequency separation and fast execution time. In the real world under normal conditions it is almost impossible to produce a step function. Therefore overshoot and ringing effect is negligible in filtering process of the real sensors data.
Yesterday I did some modeling and found out that previously proposed 6-th order Chebyshev filter using precision of the float variables rings/oscillates. Oscillations are not observed when using filters of the 4-th order.
To correct the oscillation problem and minimize overshoot in step function responce I calculated coefficients for Butterworth filter. This is the 4-th order IIR filter with 5Hz cut-off (looptime=5000) frequency (more then enough for complimentary filter with gyro_cmpf_factor = 400). Filter doesn’t oscillate using float precission and is implemented as a feature.
To enable Butterworth filter using CLI interface, one has to type “feature IIR_LPF” and acc_lpf_factor has to be greater than 0 (e.g. “set acc_lpf_factor = 10”).

having ripple in the passband is ...
what would you guess?

http://de.wikipedia.org/wiki/Butterworth-Filter
the german wiki entry uses as coment: beträchtliches Überschwingen bei der Sprungantwort, verschlechtert sich mit der Ordnung
maybe you will use google translate.
http://www.dspguide.com/ch20/3.htm

i don't know what kinda accelerometer you have.
but when it is quitly sitting on your desk and it shows +-1G changes i would say it is defect, isn't it
but inserting +- 1G as step response would be ok to me.

one of the later findings is: everything above 10hz can be viewed as noise and could be filtered out - this is for the accelerometer.

edit:
before i forget - there is a simpler approach.
use the digital filters in the accelerometer.

Code: Select all

#define BITS_DLPF_CFG_10HZ                              0x05

for the mpu-60x0 just activate the filter for the upper frequency and you are done.
in essence this means reducing the cut off frequency from 42 hz as currently defined to 10 hz.
for the other devices just have a look in the datasheet.

[SVentas]

I tested that.
Works great!

I am surprised.
To be honest, my quadcopter with IIR LPF filter activated hovers (I can’t fly indoors) only a little bit better compared to original baseflight.

Actually, in fast-forward part it's swinging to sides. Does not visible on other modes (straight "throttle-up", level flying).

I have no idea why this happens. I have to think...

Yesterday, I wrote a "toy". It displays acc data (one axis at a time) filtered by two different LP filters (baseflight hex and code attached).

Red - raw acc data;
Green – acc data filtered by first order low pass filter (default filter) configurable by acc_lpf_factor;
Blue – acc data filtered by fourth order Butterworth filter.
If angle mode is activated, toy displays acc_Y data (Y axis). If horizon mode is activated (angle mode deactivated), toy displays acc_Z data (Z axis). If angle mode and horizon mode are deactivated, toy displays acc_X data (X axis).
Feel free to play and compare performance of filters visually.

[brm]

>Actually, in fast-forward part it's swinging to sides. Does not visible on other modes (straight "throttle-up", level flying). I will try to lower P values on roll even more, didn't noticed >such effect in baseflight.

fast forward means having no smooth data stream - now you seeing the sideeffects
a filter with n-poles is ...

i found out the problem with only having the blue light being active.
the toolchain is optikmzed for an m4 - when i went back to codesourcery all is ok back again.

[brm]

>I have no idea why this happens. I have to think...
simple - lower the cutoff frequency for the digital filter and test again.

[ABL]

Yesterday, I wrote a "toy". It displays acc data (one axis at a time) filtered by two different LP filters (baseflight hex and code attached).

If i want "real-time" flight data, i need to attach second controller to multicopter frame, with radio telemetry, right?
Have everything, except some spare time ;-)

fast forward means having no smooth data stream - now you seeing the sideeffects ;)
a filter with n-poles is ...

Then why no oscillations on pitch axis, only roll (roll/pitch PID's are identical, copter CoG balanced)?

[brm]

the dynamics of a copter is quite complex.
to verify the test i would re-configure the digital filter inside the accelerometer.
pls. adjust the filter settings to match a 10hz filter.
then we will see.

to obtain flight data you need some sort of memory: an spi or qspi flash chip.
with highspeed telemetry you have not enough bandwith to collect real time data.

why mentions the wikipedia:
- beträchtliches Überschwingen bei der Sprungantwort, verschlechtert sich mit der Ordnung
- significant overshoot in the step response, deteriorates with the order

>Then why no oscillations on pitch axis, only roll (roll/pitch PID's are identical, copter CoG balanced)?
fyling fast forward means the wind acts as dampening force - if the system gets instable it will break away on the roll axe.

[SVentas]

to verify the test i would re-configure the digital filter inside the accelerometer.
pls. adjust the filter settings to match a 10hz filter.
then we will see.

WARNING! If someone is going to use and reconfigure ADXL345 accelerometer then it is fine. But if someone is going to reconfigure MPU6050 accelerometer then… "MPU-6000 and MPU-6050 Register Map and Descriptions Revision 3.2" page 11: "The DLPF is configured by DLPF_CFG. The accelerometer and gyroscope are filtered according to the value of DLPF_CFG as shown in the table below…".
IMHO it is not a good idea to fly with 10Hz DLPF on acc AND on gyro.

[brm]

RTFM - verify the current config and then scan for the exception - maybe you will understand.

[SVentas]

RTFM

.
Sorry, brm. Could You please, download the document "MPU-6000 and MPU-6050 Register Map and Descriptions Revision 4", scroll down to page 13 and read the chapter "4.3 Register 26 – Configuration".
It’s widely known limitation of MPU6000 and MPU6050 sensors discussed in many forums e.g. here
According to the table, currently MPU6050 is running at 1kHz sample rate and is configured for 42Hz bandwidth on gyro and 44Hz bandwidth on acc. That’s why I need a separate DLP filter in software.

If i want "real-time" flight data, i need to attach second controller to multicopter frame, with radio telemetry, right?
Have everything, except some spare time

Well… You can fly with toy’s firmware because it is still flyable . There is no need to attach the second board .
However, the purpose of the toy is to provide visual comparison of the signal filtered by different filters. You can shake multirotor as hard as you can or rotate multirotor as fast as you can and look for artifacts like overshoots, distorted signal, etc.
Fortunately, you will not notice any artifacts because Butterworth filter function or frequency response or transfer function (amplitude/gain vs. frequency represented by Bode diagram) is nice and has flat passband by definition:

However, step response (amplitude/gain vs. time) of the Butterworth filter has an overshoot. Overshoots can be visualized during acc calibration process where two step or Heaviside functions are generated:

There are one "negative" (a) and one "positive" (b) overshoots. As brm pointed out the overshoot gets bigger when order of the filter is increased.
Fortunately, step function has nothing to do with real world signals, because real world signals are smooth. So you are absolutely safe to use Butterworth filter.
Chebyshev type 2 filter is also fine because it has nice and flat passband, but has ripples in stopband:

In general, higher order filter is better because it has steeper cutoff compared to first order filter or in other words higher order filter separates noise from signal better. They are successfully used in ArduPilot, AeroQuad, PiCopter and probably other flight control software.

[brm]

ahh, as usual the readings cause a problem:

where Gyroscope Output Rate = 8kHz when the DLPF is disabled (DLPF_CFG = 0 or 7), and 1kHz when the DLPF is enabled (see Register 26).

is this clear?
the term dlpf disabled as well?

what looks great on the paper is sometimes not really usefull in the real world.
for example using baseflight plus i get crashes - reproducable - when having the cheby filter active.

the multiwii sensorfusion is more robust with regards to phase delays as in mahony, bachmann and magdwick type sensor fusion.
when you name the openpilot mahony type sensor fusion then there is a bug which makes it more sensitive to errors. in this case
between the given accelerometer measurements and the expected direction of the gravity.
also the i-term integrator makes the system vulnerable to problems on the measurement side.
having propellors and motors with not so nice vibrations and the i-term collectur sums up quickly until the copte rcrashes.

from a theoretical approach the papers are ok - but you need to talk with a real control law guy.
i assume you have no knowlegde about control laws. when you lok at the table you mentioned then you see the column delay.
the delay is 0 (zero) which means no filter active - your interpretation is that a filter is actice.

now you need to explain what type of filter can/could have zero delay?
there is a solution for that

[olaf45]

Hi ,

I can't understand how the acc_lp_factor works .

"accLPF32[axis] -= accLPF32[axis]>>(ACC_LPF_FACTOR);
accLPF32[axis] += accADC[axis];
accSmooth[axis] = accLPF32[axis]>>(ACC_LPF_FACTOR);"

For me a LFP should be like :

fXg = Xg * alpha + (fXg * (1.0 - alpha));

Someone can explain the functioning ?

Thank

Olivier

[timecop]

Are you talking about 8bit version here?
They're probably using shifts because their retarded platform doens't have divide or multiply instruction.

[olaf45]

Hello,

No, it's in multiwiiV2.2 but in an old release ( V1.9 ) the FLP was clearer :

"accLPF[axis] = accLPF[axis] * (1.0f - (1.0f/ACC_LPF_FACTOR)) + accADC[axis] * (1.0f/ACC_LPF_FACTOR);"

Regards

[Alexinparis]

Hi ,

I can't understand how the acc_lp_factor works .

"accLPF32[axis] -= accLPF32[axis]>>(ACC_LPF_FACTOR);
accLPF32[axis] += accADC[axis];
accSmooth[axis] = accLPF32[axis]>>(ACC_LPF_FACTOR);"

For me a LFP should be like :

fXg = Xg * alpha + (fXg * (1.0 - alpha));

Someone can explain the functioning ?

Thank

Olivier

imagine this function like this:
accLPF32[axis] = accLPF32[axis] + accADC[axis] - accLPF32[axis]>>(ACC_LPF_FACTOR)
= (accADC[axis]*(2^ACC_LPF_FACTOR))/(2^ACC_LPF_FACTOR) + accLPF32[axis]x(1-1/(2^ACC_LPF_FACTOR))

Xg = accADC[axis]*(2^ACC_LPF_FACTOR)
alpha = 2^ACC_LPF_FACTOR

accSmooth[axis] = accLPF32[axis]/(2^ACC_LPF_FACTOR)

probably less readable, but much more efficient than float calculations

[olaf45]

Hello,

Thank for your explanation. Mathematically it's correct but the weight of the ACC_LPF_FACTOR became very light. ( no impact on the result )

Regards

[milom]

Hello friends, all the files are corrupted, can you repost the right files? thanks

[milom]

Rar not work but 7zip open the files..