Doesn't adjust threshold upwards when cutoff is reduced below default.
This reverts to original setpoint code behaviour.
Probably better to go back entirely to the original code.
Add changed max on iterm_relax_cutoff to CMS
Restore ITERM_RELAX_SETPOINT_THRESHOLD to float to fix Travis error
In recent releases we have been increasing PID I.
We haven't reduced the antigravity gain value in the same proportion.
Low authority / low P quads can get I wobbles that are apparent on throttling up.
A lower default anti-gravity gain is likely to work alright and be a fraction less likely to cause I wobbles.
1. Excludes yaw from ff_boost.
2. Removes suppression for 3x greater up-steps in FF to reduce boost glitching around zero sticks
3. Spike detection gets cleaner passband and tighter rejection above threshold; higher threshold is now possible with better suppression of large spikes.
The feed forward boost concept improves stick response by adding a stick acceleration factor to feed forward. Generating spikes when there are steps in the RC signal is the main problem.
This PR makes one small change to how the spike suppression method is determined.
It no longer uses the 'jerk' signal to generate the spike suppression 'clip' value. Instead it just uses the magnitude of the boost signal itself.
We originally used jerk because it is more sensitive to spikes. Detailed testing shows that jerk is that it has an unwanted impact one full RC step after the spike.
If we use the boost (acceleration) signal as the attenuator, that delayed impact does not occur, making the boost component more precise.
The threshold value for suppression needs to be a bit higher to achieve equivalence.
I've re-named the function to reflect it being related to spike suppression and removed 'jerk' since we aren't using that any more.
Higher feed forward improves stick responsiveness and reduces bounce back on lower authority quads.
Feed forward defaults in 4.0 were slightly conservative even for typical quads.
In association with ff_boost and ff_max_rate_limit, overshoot with even higher feed forward is less of a problem than before.
I think these values should be about right for 4.1
The feed forward changes in 4.1 will bring, to all quads of reasonable control authority, reduced setpoint to gyro delay and less error. iTerm will tend to accumulate less during fast inputs so there will be less of a problem with iTerm-windup and iTerm related bounce-back.
Higher I values lead to better control during tight turns and greater stability in wind. Higher I doesn't increase the absolute amount of iTerm accumulating in the PID loop, but does allow it to change more quickly and to more quickly zero out the residual errors that are strong in tight turns.
I think this modest increase will optimise performance of the default 4.1 PIDs for most quads.
Lower authority quads will need to either reduce their I setting, or, preferably, lower the iterm_relax value to 10 or even 5, to avoid wind-up.
Abs control accidentally was defaulted up from 0 to 5 in #7907. It is still experimental and still can cause oscillations even with these changes. Should be off by default until fully tested.
Evolutionary changes to the original 4.0 defaults.
Intended to reduce chance of D-mediated flyaways on arming.
Also seems to fly better due to less gyro delay.
CHanges:
- Gyro filtering dynamic reverts back to PT1, to provide less delay, and in recognition that gyro filtering was more than adequate with the biquad. Setpoints are higher due to lower reach of PT1. The static gyro biquad at 150 was lower than really needed. Markedly less gyro delay.
- Stronger D term filtering, especially at low throttle, to greatly reduce risk arming flyaways. The Dynamic D biquad is now set almost twice as low, with strong cut at 100hz where D resonance flyaways seemed to be driven from. This filter array results in a D noise contribution that is typically not much greater than the P contribution, keeping very cool motors despite the lesser gyro filters. This has been well tested using PID Toolbox.
Although there is more delay in D, this is offset by the reduced gyro delay.
Removes the custom CLI commands to update or display the PID and Rate profile names. Moves the storage into the pidProfile and controlRateProfile PG's.
Names can now be set with:
set profile_name = NAME
set rate_profile_name = NAME
Also added profile name display to the profile and rate CMS menus.
Some users have reported flyaways on arming/throttling up with betaflight 4.0, in quads that fiy alright on 3.5.
This PR changes the default filtering so that D transmission more closely approximates that of 3.5.
With these defaults, quads that fly OK on 3.5 should not take-off vertically due to uncontrolled D oscillation.
Change to a state machine that tracks the progress of each dshot command in the queue as it moves through the various phases. Simplifies the code to make it easier to understand and maintain.
Transition to timing based on motor output cycle counts calculated from desired delays instead of using direct time comparisons. Since the output timing is always based on the motor update schedule, there were cases where if the time between motor updates was a significant percentage of the desired dshot command timing, then the output could get irregular and skip cycles (for example trying to use 2K pid loop with 500us timing conflicting with 1ms timing between dshot command outputs).
Defaults will be the same regardless of whether the target has `USE_DYN_LPF` included. Previously the defaults would vary and it wouldn't be obvious why.
Defaults are as follows:
gyro lowpass 1: 150/BIQUAD
gyro lowpass 2: OFF
dterm lowpass 1: 150/BIQUAD
dterm lowpass 2: 150/BIQUAD
Nothing has changed int eh dynamic lowpass logic. If it's enabled those settings will be used in place of the static lowpass cutoff.
Needs coordination with the Configurator to change the defaults used when re-eanbling the lowpass filters as they are currently based on previous version settings and will dfault to inappropriate values.
