Kalman on d

[Quick-Flash]

This PR takes upon the work done in the kalman non-covariance code and adds more to it. This code takes the kalman filter used on the gyro and puts another kalman filter on the dterm. More testing is needed but it does fly!

[adrianmiriuta]

@Quick-Flash
using the kalman filter after the pid is a good ideea
but using it only on the dterm is not.

You increase the phase delay between PI and D components, this cripples the PID .

I already implemented this approach about half a year ago, (PID->KALMAN->BIQAD)
but I use it only for lightweight tubular builds (it works very good for them).

see
https://github.com/3x8/sulaco/

[Quick-Flash]

@Quick-Flash
using the kalman filter after the pid is a good ideea
but using it only on the dterm is not.

You increase the phase delay between PI and D components, this cripples the PID .

I already implemented this approach about half a year ago, (PID->KALMAN->BIQAD)
but I use it only for lightweight tubular builds (it works very good for them).

see
https://github.com/3x8/sulaco/

If this be the case, is there an advantage in changing the current dterm filters and replacing them with identical pidsum filters?

[adrianmiriuta]

@Quick-Flash
No , it only works for Kalman filter

1. you can scrap all gyro filtering (less delay)
2. simplify configuration (only one kalman filter after the PID)

As to practical flight ... I do not know !
I like the feel, it is locked and responsive, but I fly mostly ultralight tubular builds (LOS),
my other builds are also very light ...
It has to be tested in field for FPV ... so i cannot really tell.

My implementation is a quick hack of Butterflight,
where if kalman filter is chosen for dterm it applies to the PIDsum. (not to dTerm)

Although it only works with the kalman filter,
because the output of the PID has much higher noise with higher frequency,
PT1, BIQUAD and other frequency domain filters cannot handle it.

logAndConfig_PIDsumKalman.zip

[Quick-Flash]

Looking at your logs, this is your filtered pidsum

Yet your motors look like this

Your logging isn't looking at everything correctly or you've changed something between your pidsum and motor mixer.

[adrianmiriuta]

@Quick-Flash
That is Incorrect.

The logged PID traces are before the filter, that is standard Butterflight (betaflight) behavior.

I made no changes there.
I can record a flight with a debug trace,
where the debug values are the filtered PID outputs/ axix.
If that is what you are interested in.

[gretel]

@adrianmiriuta you figured the temeletry bug, didn't you :)

[adrianmiriuta]

@gretel
yea, that's a long time ago.

[nerdCopter]

closing due another branch is more up to date