Some form of this needs to exist in a runtime configurable way.
Currently, selecting exact_volts as the voltage source for pid voltage comp in config.h will hard set a type of TPA for initial testing. I feel it has dramatically improved the behavior of higher thrust to weight ratio crafts. The behavior of this initial test algorithm is to monitor throttle for cresting a cut value, and then to apply a linearly sloped decrease factor against the entire pidsum. Both the throttle cut and the max attenuation percentage @100% throttle can be made runtime adjustable. Its behavior is smooth and it is an easy feature to use. Unknow is how this plays with pid voltage compensation if both features are calculating at the same time as they both directly modify the total pidsum calculation. Does it matter which one is calculated first ... or do we even want to allow two features which modify the total pidsum in different directions to be active at the same time? These are things to think about.
However, we may not want to hijack the pid sum directly after its calculation for TPA.
Traditionally Silverware used something called motor curves and these functioned very similarly to TPA. Silver would map the thrust response of different brushed motors and create an "curve" which was directly applied to pwm motor outputs effectively making their response linear across the entire range of PWM commands. This sort of linear response is exactly what a PID controller is designed for. Intercepting the requested motor commands is essentially an equivalent approach to hijacking the pidsums and may keep the pid controller code cleaner and easier to follow if less is happening there.
In summary we need to determine what approach is going to work best for us and also be easiest to use.
What shape of curve to we want. Flat then a linear decline past a certain throttle point or a smooth curve across the entire range.
-What sort of user prameters do we want to make available. Is it possible to create a thrust linearization algorithm where a user need only input a thrust to weight ratio?
Some form of this needs to exist in a runtime configurable way.
Currently, selecting exact_volts as the voltage source for pid voltage comp in config.h will hard set a type of TPA for initial testing. I feel it has dramatically improved the behavior of higher thrust to weight ratio crafts. The behavior of this initial test algorithm is to monitor throttle for cresting a cut value, and then to apply a linearly sloped decrease factor against the entire pidsum. Both the throttle cut and the max attenuation percentage @100% throttle can be made runtime adjustable. Its behavior is smooth and it is an easy feature to use. Unknow is how this plays with pid voltage compensation if both features are calculating at the same time as they both directly modify the total pidsum calculation. Does it matter which one is calculated first ... or do we even want to allow two features which modify the total pidsum in different directions to be active at the same time? These are things to think about.
However, we may not want to hijack the pid sum directly after its calculation for TPA.
Traditionally Silverware used something called motor curves and these functioned very similarly to TPA. Silver would map the thrust response of different brushed motors and create an "curve" which was directly applied to pwm motor outputs effectively making their response linear across the entire range of PWM commands. This sort of linear response is exactly what a PID controller is designed for. Intercepting the requested motor commands is essentially an equivalent approach to hijacking the pidsums and may keep the pid controller code cleaner and easier to follow if less is happening there.
In summary we need to determine what approach is going to work best for us and also be easiest to use.