- 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.
In the PR adding P to antigravity, the default value was changed so that zero now meant no antigravity, whereas before 1000 meant none. Unfortunately, `ITERM_ACCELERATOR_GAIN_OFF` remained at 1000. This was an oversight.
Note also that the default value of 3500 now results in more antigravity effect than previously; it is equivalent to 4500 in the previous system.
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.
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.
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.
Default threshold 40 deg/sec
Anotations provided to explain
- cutoff independence factor when calculating itermRelaxSetpointThreshold
- meaning of ITERM_RELAX_SETPOINT_THRESHOLD
The original setpoint based iTerm Relax code attenuated the amount of iTerm added per loop by a relax factor based on an HPF of setpoint.
At some point the code was re-factored and the relax factor multiplied the accumulating iterm error itself, such that almost any relax factor below 1.0 would quickly zero out iTerm.
This was bad for racing because when making sustained tight turns, I would abrubtly be zeroed when the setpoint for the starting of some relax was close to the threshold.
This was never the intent of the original proposal, which was for a smoother attenuation of iTerm, and for retention of some accumulation of iTerm during spirals around poles etc.
This PR fixes that error.
It also changes the default threshold up from 30 deg/s to 40 deg/s which better suits racing.
Also included us a form of simple cutoff independence. In the initial form, lowering cutoff would reduce the effectiveness but draw out the duration. Now cutoff only really affects duration.
Lower cutoff values are better for quads with greater motor delay, faster values are better for quicker quads. For most of my quads a cutoff of 30 works best.
I've also removed newlines.
set to current cutoff maybe fix unit test
default cutoff set to current value
in unit test add itermRelaxSetpointThreshold as float
in unit test add itermRelaxSetpointThreshold as float, because ITERM_RELAX_SETPOINT_THRESHOLD doesn't exist any more
Move itermRelaxFactor limit, remove from fast ram
remove unncessary max, revert unit test changes, restore original defaults.
remove max from debug
restore old defaults and revert unit test changes temporarily to see if will pass unit test with defaults
whoops
lets see if unit test passes when cutoff is 20
lets see if unit test passes when cutoff is 20
raise dc offset immediately
Add airmode noise fix
no filter when inactive and slightly more throttle
hpf throttle to avoid large moves increasing throttle persistently
fix ws
fix ununsed variable and default to off
include airmode throttle offset in loggingThrottle
Change to using an array of `uint8_t` for the `d_min_` axis parameters. Simplifies the code.
The CMS menu entries were incorrectly placed under the `FILTER PP` submenu. Moved to the `MISC PP` submenu.
Directly and easily set the minimum value for D on pitch and roll.
- Boost back to the primary D setting is generated from gyro or setpoint inputs.
- Setpoint input is stick derived, faster by 10ms approx, and does not respond to propwash.
- Gyro input is motor derived and slower, but responds to propwash
- timing value sets balance between gyro (100) and setpoint (0) boost factors
- gain value sets overall sensitivity
- default D mins are 20 roll 22 pitch
- default D is 35, 38; if undefined then normal 30, 32 values
TUNING
- D value to flip overshoot control
- D_min to noise, lower values mean cooler motors but perhaps more propwash.
- Advance, higher values bring the boost in earlier, and stronger overall, useful for very high flip rates, but dampen stick responsiveness slightly.
- Gain value adjust against logs, checking maximal boost with flips and some rise with propwash, should be edging to get up from the min value in normal flight.
Currently only rcCommand values are included in the log data and the configurator calculates the actual setpoint values based on rates values added to the blackbox header. The problem with this is that the rates information is only written at arming so if the rates change during the log (rateprofile change, in-flight adjustments, etc.) then the calculated setpoints will be incorrect. There's no way to tell from the log that this happened. This often causes confusion because it will suddenly make it appear in the log that the PID controller is not acheiving the requested rates when it's just a presentation error. Also the rates will be incorrectly calculated when the user selects Raceflight style rates as the rates type is not supplied in the log header (and the viewer doesn't have the forumla for them anyway).
This change adds the actual setpoint values for each axis as used by the PID controller, removing the necessity for the viewer to perform any calculations. In addition to showing any rate changes, it will also show any cases where other flight features have modified the setpoints from the user's input. These were invisible previously (examples include level modes, Acro Trainer, GPS Rescue, yaw spin recovery, etc.).
Also the throttle value used in the mixer is included in the throttle axis. This allow visualization of things that affect the commanded throttle like throttle boost, throttle limit, GPS Rescue, angle level strength, etc.
Having the iterm resetting happening in the rx loop causes a sawtooth PID/motor effect while idling since the PID loop is running at a much higher rate and iterm is allowed to grow during this, and then only reset at a much lower rate in the rx loop. This can potentially lead to some oscillation and/or resonance while idling before takeoff as the sawtooth signal can make it through to the motor outputs.
