Adds angle setpoint roll/pitch expo for self-level modes.
Previously the angle setpoint was a simple linear calculation based on the stick deflection percentage and the angle limit. This makes control very jumpy around center stick and people would often resort to adding expo in their radios to compensate. This then adds the complication of wanting expo in the radio when in self-level but not when in acro - leading to complicated mixes, virtual switches, etc.
This PR adds separate self-level expo settings for roll/pitch so the user can customize the axis behavior. Yaw is excluded because this axis uses normal rates and expo controlling the rotational rate around the yaw axis and not an angle setpoint. The roll/pitch expo can range from 0 (off) to 100 (max) like other RC expo settings. For example:
```
set roll_level_expo = 30
set pitch_level_expo = 40
```
The default values are 0 which disables any expo and behaves as before.
The settings are available in the CMS rate profile menu.
- all CLI parameters related to dynamic idle alone re-named with the `dyn_idle_` prefix
- when linear throttle scaling is active, the user's set idle value is now correct whether dynamic idle is on or off. Previously, the idle value fell when dynamic idle was activated at the same time as linear throttle scaling.
- enabling dynamic idle no longer causes a deadband at full throttle
- the setpoint throttle value sent to Blackbox does not include the dynamic idle offset
- the throttle value sent to the antigravity and dynamic lowpass code includes throttle scaling, but no other modifiers, to avoid false elevation of the apparent throttle position from dynamic idle and unnecessary transient changes in their filter cutoffs
- Dynamic Idle now uses a modified PI controller during active rpm control phase
- the D factor provides early detection of rapid falls in rpm, e.g. in hard chops. It is filtered heavily. Inadequate `dyn_idle_d_gain` may lead to a transient drop in rpm immediately after cutting throttle. Default is 50.
- the P factor provides fast control over rpm during the active control phase. Too much `dyn_idle_p_gain` may cause oscillation in that phase. Note enough and a slow drop in rpm will be inadequately corrected. Default is 50. Needs to be higher with heavier larger props.
- An integral element does most of the work. It prevents enduring offsets from the set rpm. The I gain is high when increasing responding to low rpm, and slow to release. The slow release makes a huge difference and avoids I oscillation. Not enough `dyn_idle_i_gain` and there may be wobble in rpm during the control phase, or the idle value may rise too slowly; too much may cause wobble. Default is 50. Needs to be higher with heavier larger props.
- The DYN_IDLE debug shows idle P, I and D in debugs 0, 1 and 2. minRps stays in debug 3.
- Interactions between throttle and thrust linear, dynamic idle, throttle scaling and throttle boost have been checked and work as they should.
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.
