Add setpoint derivative feed forward term to PID controller

[DzikuVx]

As part of this PR:

• Dterm is always computed from measurement
• Control Derivative is computed from filtered setpoint
• Removed Dterm FIR filter
• Removed Dterm notch
• Omnibus F3 removed from release list

[digitalentity]

So, this is not a feed-forward itself, it's a multiplier for one of the components of the D-term

[DzikuVx]

No it's not. And it's a shame BF called that a feed forward. It's not done, the goal is to comoute dterm only from measurement. From the math level it's the same as now, only tuning is simpler since instead of setpoint weight you separately tune "damping" and acceleration from the stick movement wt., 28 kwi 2020, 17:42 użytkownik Konstantin Sharlaimov < notifications@github.com> napisał:

…

So, this is not a feed-forward itself, it's a multiplier for one of the components of the D-term — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5642 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHMBG2EESH3Z5TIDDRMQCDRO32NJANCNFSM4MS3M5YA> .

[digitalentity]

Maybe we should then separate D/setpoint and D/measurement into two PID parameters and deprecate setpoint weight?

We'll end up with P, I, D/setpoint, D/meas and FF, may be a lot, but it will in fact may tuning simpler. D/setpoint and FF will only affect reaction to the stick.

[DzikuVx]

That would mean we will need 5th gain in each bank, new frames for MSP, Configurator support and so on.
So, in general I agree that would be good, but quite complicated. As long as possible I want to avoid adding a 5th gain to each PID bank, even if naming will be not quite right.
Also, pilots on MC are used to BF FF and that another reason not to overcomplicate.

[digitalentity]

Makes sense, but can we please not call it "feed-forward" to avoid confusion with real FF-term on fixed wings?

[DzikuVx]

DS maybe? śr., 29 kwi 2020, 13:32 użytkownik Konstantin Sharlaimov < notifications@github.com> napisał:

…

Makes sense, but can we please not call it "feed-forward" to avoid confusion with real FF-term on fixed wings? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5642 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHMBGZBBT2BCWBZYWFSFM3RPAF4DANCNFSM4MS3M5YA> .

[DzikuVx]

First flight tests completed and result are very appealing. There is less vibrations due to better behaving Dterm that now is measured only from measurement. The amount of control on fast strick movements was better than before. Unfortunatley I do not have a log with CDterm recorded.

DVR: https://youtu.be/tFXFGss8aFE

It still needs some check but seems like a good feature

[digitalentity]

Happy to hear. Finally we're getting rid of dterm_setpoint_weight in favor of more intuitive tuning.

[Avegawanderer]

Maybe let's call the derivative of setpoint not DS but DFF (Differential Feed-Forward, or Differentiated Feed Forward) People have got used to "Feed Forward" name and it would be easier to explain that Betaflight's FF is actually DFF in iNav and the real feed-forward is just FF in iNav. At least both FF and DFF names describe their impact for the system. DS does not.

[digitalentity]

IMO "feed-forward" has nothing to do with how this works (neither in INAV nor in BF).
The behavior is exactly about taking a derivative of setpoint (control) and propagating that straight to the motors. This is exactly what dterm_setpoint_weight does, just having a dedicated gain, decoupled from derivative of measurement (gyro).

[Avegawanderer]

Yes, what is called FF in Betaflight and iNav is different from true FF in a control system theory. But speaking about iNav, FF for fixed-wings simply propagates setpoint (control) to output (servos). While such FF is not used for multirotors, it's derivative is used, and, as I understand (please correct me if I'm wrong) Pawel in this PR brings it to PID controller settings, dropping dterm_setpoint_weight. The question is to name it properly. My proposal is to keep FF as it is for FW and name new component DFF instead of DS. It directly explains what it does (takes FF (=setpoint) and gets it's derivative). The goal is to use familiar FF name.

[digitalentity]

I see, so the idea is to avoid adding a new term "setpoint" to prevent user confusion. @DzikuVx WDYT?

[DzikuVx]

Actually I think that Control Derivative which is the name used in the code right now is exactly what this functionality is.
I'm even thinking about renaming D in configurator to Gyro Derivative so there is zero confusion what is what

The base branch was changed.