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.
This code cuts D by a specified percentage durning normal flight.
It lets D smoothly rise up to normal during rapid gyro moves like flips and rolls, and increase during prop wash events.
D should now be tuned to values the 'normal' 30-45 range.
If D is 40, a dterm_cut_percentage of 65 will cut D to 14 in normal flight, but the quad will still get full 40 of D to control bounce-back after flips and about 25 of D during strong prop wash.
The dterm_cut_percentage can be adjusted via the OSD, from the D filtering page.
Adding d_cut results in cooler motors, lower amounts of noise in motor traces and faster reactions to quick stick inputs.
Too high a dterm_cut_percentage may bring out P oscillation from lack of D. Values of 70% are generally OK.
Input is gyro differential (delta). Frequencies above 40hz (above propwash) are attenuated with a configurable (dterm_cut_range_hz) biquad filter. Lower values for range can be used if the quad is very noisy or gets low frequency D resonant oscillation. Up to 50 or 60hz may suit clean quads where prop wash control is the main priority. Too high a range value results in D being boosted from noise in normal flight.
The boost signal is 'integrated, smoothed and delayed' with a 7hz PT1 'dterm_cut_lowpass_hz' filter. The default of 7Hz gives about the right amount of smoothing and delay. Higher numbers cause the boost to come on faster, with less delay. Lower values delay the boost effect and cause it to last longer.
The dterm_cut_gain amount controls the strength of the boost effect by amplifying the input to the boosting effect. If the quad is flow gently, a higher gain value may be needed to gain full boost.
Logging with set debug_mode = D_CUT allows recording of realtime D values on roll and pitch into debug 2 and 3. The reatime D value should reach its set maximum during rapid turns, ideally at about the time D itself peaks. If it fails to reach the maximum, gain should be increased.
The D_Cut feature is not enabled on LUXV2RACE, OMNIBUS, SPRACINGF3NEO because there isn't enough flash space.
