Refactor PID configuration/PID control

[digitalentity]

Currently we have P, I and D gains in our PID array. This is enough for current PID controller, but definitely not enough for VTOLs which will require two sets of PIDs - one for takeoff/landing (similar to multirotor PIDs), the other for fixed-wing flight.

I suggest that we have for each axis 6 gains in total:

MC_P, MC_I, MC_D - for milticopter FW_P, FW_I, FW_FF - for fixed wing

This will also imply significant reworking of PID controller itself - we'll have to split it into two controllers - one for MC part, the other for FW part. This will also allow us to change the behavior of FW controller to perform better on airplanes.

[martinbudden]

Are you suggesting 2 separate PID controllers, or two instances of a PID controller each with a different set of PID parameters?

[digitalentity]

Two separate PID controllers with different set of PID parameters. These PIDs may share some logic. MC_PID will be active when multirotor mixer is used, similarly FW_PID will be active for a fixed-wing mixer. For VTOL both will be used depending on flight mode.

[digitalentity]

Simplest thing would be to extend current PID_ITEM_COUNT by 3 more items.

[martinbudden]

Yes, that makes sense. The related configurator compatibility changes would be straightforward to handle.

[DzikuVx]

what about output fusion if any control surface can act in both flight scenarios?

[digitalentity]

That's probably up to the mixer. For transition we'll probably have to have both PID controllers active for some time. Anyway VTOLs are distant future.

Instant benefit from two separate PID parameter sets is better defaults for airplanes. Similar thing we have for NavR which is used for FW and Pos/PosR which is used for MC.

[digitalentity]

Another solution is to extend each PID (pitch/roll/yaw/level etc) to have 6 values instead of 3.

This way we can not only have pitch/fw and pitch/mc parts in one row, but also collapse some PIDs into one (i.e. merge ALT/VEL and POS/POSR).

This will also give us some flexibility for LEVEL PID - I have some extensitions for self-leveling in mind (one being something similar to what @ethomas999 did with his HORIZON modifier, the other being smoother ANGLE mode - attenuated self-leveling response when stick is not moved)

[digitalentity]

At the moment I'm unsure what approach to take.

[martinbudden]

I'd be inclined to push this to 1.7. There's already a lot in 1.6 and I'd like to keep up a rapid release cycle. That will also give us more time to think about it.

[digitalentity]

After 1.5 we'll decide what will go into 1.6 - currently I've been moving quite a lot to 1.6 instead of 2.0. However you are probably right, it's better to have such a drastic change in 1.7. For 1.6 it might be beneficital to refactor PID controller for airplanes per https://github.com/iNavFlight/inav/issues/970

[digitalentity]

Not relevant anymore since we created banks for FW/MC PIDs