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.
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.
Adds a race start assistance system that allows the pilot to pitch forward and then release the sticks with the quad holding position for the race start.
Refactor iterm_relax to iterm_relax_axis
Isolate pidLevel test
Isolate pidHorizon tests
remove if UNIT_TEST
revert to iterm_relax from iterm_relax_axis
Refactor PID code Iterm Relax and Absolute control
Move defines for unittest to Makefile
Fix unittest isAirmodeActivated()
Absolute control unittests + optimizations
Fix dead code absolute control // unittests
Further optimizations to absolute control switch logic
Restructures the PID controller to decouple feedforward from D.
Cleaned up the structure of the PID controller; moved some feature-based enhancements out of the main structure.
Feedforward becomes a separate component of the PID controller and there is now:
f_pitch
f_roll
f_yaw
The default values of 60 for pitch and roll matches the default setpoint weight used in BF3.4. Yaw previously had no setpoint weight capability so the default here needs to be discussed. Currently it's also set to 60 and flight testing seems positive. Feedforward on yaw adds a lot of value so I don't think we want to default to 0. Instead we need decide on the default.
All occurences of setpoint weight have been replaced by feedforward. "setpoint_relax_ratio" has been renamed to "feedforward_transition".
The pidSum now consists of P + I + D + F.
D has been added back for yaw (disabled by default with d_yaw = 0). We've found little need for D for normal quads but it may have value for other configurations - particularly tricopters.
Updated CMS menus to support adjusting the feedforward for each axis.
Changed the default for "rc_interp_ch" to be "RPYT". Need yaw to be smoothed to support feedforward.
Open issues:
Needs BFC support
- Need to add support for the axis "F" gains.
- Remove "setpoint weight" slider.
- Rename "D Setpoint transition" to "Feedforward transition"
Needs BBE support
- Header "setpoint_relaxation_ratio" has been renamed "feedforward_transition"
- Header "dterm_setpoint_weight" has been replaced with an array named "feed_forward_weight".
example: H feed_forward_weight:65,60,60 (R,P,Y)
- PID component "AXISF" has been added for all axes. Should be handled like P, I and D values.
- PidSum calculation needs to include F.
Needs LUA script support
- Support the renamed "setpoint_relax_ratio".
- Support for feedforward weight on all 3 axes.
Open code issues:
- rc_adjustments.c - support for adjusting feedforward weight for all axes. Currently only supporting roll - needs coordination with BFC.
Adds in flight monitoring of the rx frame rate and adapts the filters if the frame rate changes. Primarily to add support for Crossfire with its ability to switch from 150hz to 50hz (and back) under some circumstances. Will work with any protocol - not CRSF specific. So if future receivers add the ability to switch frame rates dynamically the logic should support them.
If the current rx frame rate is more than +-20% from the previously detected rate, then the process will retrain for the next 50 samples as long as the rate continues to be outside the 20% tolerance. Once 50 samples are collected the new frame rate is updated and the filter cutoffs are adjusted. Only filters set with their cutoffs = 0 (auto) will be adjusted. There is a 2 second guard time after a successful update before retraining can start again to prevent rapid switching back and forth.
The logic is optimized to not perform any training if the filters are set to manual cutoffs. So there is an opportunity for advanced users to choose specific cutoffs and reduce the PID loop load slightly. However this is not recommended for Crossfire or other protocols that might change their rx frame rate.
Updated the output of the `rc_smoothing_info` cli command to match the revised logic.
