Most people who have tested IllusionFPV's expo on the dynamic D lowpass filter have found it to improve propwash without adverse effects.
It achieves this reducing D lowpass delay more quickly on throttling up.
This allows us to retain, at idle, the strong lowpass filtering we currently have, but quickly reduce lowpass delay and improve propwash by mid throttle.
A value of 5-7 is OK I'm proposing 5 as a conservative start.
I know this is a new feature but it is really good . It would be great if it could be made active by default, if possible, in 4.2.
Now with the motor protocol defaulting to DISABLED we can reimplement this.
Remove dependence on gyro type and base on MCU type.
The previous logic was based on expecting an 8K sampling gyro and would set an inappropriate loop time for other gyro types.
Change the logic to be based on the capabilities of the MCU which is more appropriate. We set the pid_process_denom default to the maximum recommended value for a given MCU.
The `pid_process_denom` will be defaulted as follows (assuming a 8khz gyro) based on MCU type:
MCU `pid_process_denom`
F1: 8 (1khz)
F3: 4 (2khz)
F411: 2 (4khz)
Others: 1 (8khz)
Of course the final PID loop rate will be based on the native sample rate of the gyro.
First draft
Change method to percentage compensation
fast sag filter with fast battery updates
Renaming, moving factors to init where possible
Names changed, display update frequency reverted to 50hz as it was
50Hz ESC Voltage sampling, battery sag lowpass for PID compensation.
increment PG_PID_PROFILE, element added to end of batteryConfig_t
all HZ_TO_INTERVALs set back to 200 to match battery task frequency of 200hz.
Add a flag to control vbat comp
Flag vbat_sag_comp_enabled allows battery compensation to be enabled or
disabled from the CLI. When disabled the battery voltage task is run at
50Hz and the battery compensation code is not run. When enabled the
voltage task is run at 200Hz and the compensation code runs. Constants
for the fast and slow rates are added to tasks.h. The default value for
vbat_sag_compensation is changed to 100 as we no longer need to use it
to disable the feature.
Fixed variable task frequency setting.
Added config validation to disable sag compensation unless ADC is used as the voltage data source.
Added conditionals, fixed naming.
Fixed build.
This is a revision and partial revert of #9545.
While the previous version improved the behavior for non-8K gyros, it had some unfortunate side effects on the defaults and how they affected the output of the `diff`. Basically the problem is that in most cases the default value will end up getting adjusted during the first boot to work with the default low-speed motor protocol ONESHOT125. So if an appropriate default was originally set (like in the other PR) it shows up changed in the `diff` with default settings. The only workaround is to set the default to be the expected "corrected" value when ONESHOT125 is taken into account. This unfortunately reverts to the not so great behavior for gyros that have a sample rate < 8K, but that's unavoidable.
The inappropriate logic based on the `USE_` for various gyros being defined is still removed. This makes no sense in the unified targets context and was trying to determine if there's an SPI-connected gyro so that means it's going to run at 8K, but if not then it's going to be I2C and 2K, etc. This no longer makes sense.
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.
