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.
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.
