Tuning any sort of non linear system is hard. Really hard.
While we do have the 2 PIDs inbuilt within each of the autopilot modes, and tuning them in-flight is easily doable, we don't have any similar comfort available for Vizy scripts.
Building a PID in Vizy is not just "a bit hard" - it's plain out not possible for most of the users. They don't understand what a PID is composed of, foremost how the time components are tied in.
So why don't we just get a PID as a Vizy block?
There are a couple of things to consider:
- PIDs are stateful. So a PID block is going to need a variable to persist the state.
- PIDs require tuning. Tuning means a PID block needs easily accessible , grouped and properly labeled sliders. Best placed in the parts menu of the controller running the script. Or at least a proper tutorial on how to build an UI containing sliders and labels with a minimum of Vizy blocks.
So what do we have in terms of Vizy block interface?
Float PID(Float Input, Float I = 0, Float P = 1, Float D = 0, Var History)
The history is going to need 3 values:
- Timestamp
- Last Input
- Current Integral
So the History should fit nicely in a regular Vec3 variable.
I don't quite understand, as long as the function does have a way of computing (physics) dt, both differential (gradient) and integral components (sum over dt) are well defined. And the PID should be able to tolerate both fluctuating dt, as well as update rates much lower than once per physics update.
The PIDs when used in the input controllers don't run at a fixed rate either, with behavior noticably changing between e.g. 1/4 and 4x simulation speed - but that is still perfectly fine as long as the PIDs update interval doesn't exceed 8-16x of the period of the highest frequency oscillation it's supposed to counter.
Edit: forgotten about the forbidden case of dt=0 where the PID can't update, and which we might face in Vizy context.