Change both MC and FW PID controllers to P+I+D+FF

[digitalentity]

Currently MC is PID, FW is PIFF, while both MC and FW could benefit from having a full PIDFF controller.

[shellixyz]

Would be great indeed !

[DzikuVx]

I've been looking into BF FF implementation lately. Indeed, looks interesting and removes the need for dterm setpoint weight. Still, MC FF apparently should be setpoint derivative, not setpoint based like in FF. On the other hand, it might be intersting how setpoint FF would work on MC.

[Dronek]

I have been missing D on FW since it was removed. PIFF is beneficial for a more direct steering compared to PID on FW but not very effective when it comes to stabilization against external influence, like gusts.

[wojciechwas]

Awesome idea! I really could do with this feature for my FWs where I use twin motors for yaw. Also it would help getting smoother stab as missing D term does show every now and then.
Best I can get with PIFF on FW looks like that: https://www.youtube.com/watch?v=CeM5jza0vnQ&t=
Notice the tail waggle at few points and occasional 'jerkiness'.

[DzikuVx]

Pid bank and MSP frame will be done in #4326

[Avegawanderer]

Is there any chance for D term to be implemented for fixed wings? Stabilization would be much better with D term as it would let higher P gains.

[digitalentity]

Let's look into this for 2.6

[Avegawanderer]

Continuing PID/PIFF discussion - what is the reason for all the P, I, FF coefficients to depend on rate for fixed wings?
Wouldn't it be more straigtforward to decouple rate and PIFFs like in multirotors? I meen the following:

1. Rates are only used to convert RC command into setpoint (degrees per second).
2. FF coefficient is basically scale of RC command passed to controller output. A convenient way is expressing it into %. For example, 90% FF rate means 90% controller output ( = servo deflection), no need to guess FF value for any rate.
3. P, I, Ds (setpoint derivative, gyro derivative) are also scaled internally, not by rates.
   The PID set controls how fast plane gets to desired angular velocity and how stable plane keeps it. The PID controller is naturally independent from the maximum angular velocity of the plane (what actually a rate is). It just tries to keep error at zero.

The benefits are: clear understanding and simplified tuning.
What do you think?

[digitalentity]

What I notice a lot, that fixed-wing pilots tend to think in percentages of stick deflection (aka RC rate). INAV does not have such a thing at all. Units used by INAV internally are degrees and degrees per second. Parameters on the PID tab relate to that, regardless of the aircraft type.

PID/PIFF translates rate command into actuator commands. This is how it works on both multirotor and fixed-wing crafts. Rule of thumb for tuning airplanes:

1. Set max rate to max rotation rate your plane is capable of at 100% servo deflection at cruise throttle.
2. Set FF rate to get full servo deflection when that rotation rate is commanded.
3. Profit!

[rts18]

This is an area that iNav can not compare to other fixed wing software.
Any well performing controller needs a Derivative term to dampen over shoot.

I have been able to overcome roll axis wobble in turbulent wind, with other flight software that implement the Derivative term.
In their cases it quickly dampened to a small shimmy and not the eye ball shaking wobble that takes place in iNav.

Its common knowledge that a well designed airplane has good inherent stability. Due to this, a flight stabilizer can operate on a P I control system. Or even the Integral component alone, when flying in moderately windy conditions. As iNav does.

The real test of a flight stabilizer is seen when flying in gusty wind. This is where iNav fixed wing stabilization falls over badly.
Why a Derivative component was left out of this crucial control system baffles me.

It does not require much D term to dampen oscillations in gusty conditions. In fact it would be impossible to use any more than a few points at best. Due to slow servo control reaction rate. But this small amount of Derivative does help.

[avsaase]

Adding a D-term to the control loop on fixed wing to get a PIDFF (PIFFD?) controller seems trivial: 424ae8e. This raises the question of why this hasn't been done before. Is it just a matter of priority? Which is totally fine btw. Or are there caveats to doing this that I'm not seeing right now? @digitalentity, @DzikuVx?

Implementing this properly throughout the rest of the project will of course require more work than just the control loop: adjustments, OSD, configurator, black box log and explorer all need to be changed so that D and FF terms can be used at the same time. But these don't all have to be changed at the same time. I think it could be an interesting challenge.

[Dronek]

Why a Derivative component was left out of this crucial control system baffles me.

It wasn't left out. Early versions of inav used PID control for MC and FW. At some point the D-term was actually deliberately removed in FW and replaced by FF. As far as I recall, it was speculated that servos can't follow rapid changes caused by the D-term anyway and that FF would make steering of FW more direct.

It was a questionable move back then IMHO and it would have been a better decision to implement FF in addition to PID on FW. Please don't remove core features so easily in the future. Let's hope for a come-back of D on FW.