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
The dterm notch is disabled and dterm_notch_hz is already 0 by default. When the Configurator saves changes from the PID Tuning tab and the notch is disabled it sets both dterm_notch_hz and dterm_notch_cutoff to 0. Since the default was left at 160, this makes dterm_notch_cutoff appear in diff outputs. Ultimately it's just cosmetic since the dterm notch is disabled if either value is zero. But there's no reason for the dterm_notch_cutoff to remain set to the legacy 160 value.
Iterm Relax was inserted before crash recovery and this was causing the recovery to be ineffective or fail completely. The problem was that the subsequent iterm calculation was not using the calculated recovery error and instead was using the setpoint error. As such I ended up accumulating and opposing P based on recovery error. This prevented the efforts of crash recovery to level the quad and since it couldn't reach the level state crash recovery wouldn't shut off. This resulted in the pilot only having control over yaw and throttle while crash recovery was still ineffectually trying to control roll/pitch.
The fix is to move crash recovery handling ahead of the iterm relax calculations and make sure that iterm relax uses the error calculated from crash recovery if active. This also allows crash recovery to reset the iterm accumulation as originally designed.
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.
Improved the rx frame rate detection/training by delaying calculation to avoid loop time jitter during flight controller initialization.
For auto cutoffs calculate a value appropriate for BIQUAD or PT1 depending on the configuration.
Added a new rc_smoothing_info cli command to display internal details about its operation.
Adds options to select the filter type for both input and derivative.
rc_smoothing_input_type = PT1 | BIQUAD (default is BIQUAD)
rc_smoothing_derivative_type = OFF | PT1 | BIQUAD (default is OFF)
Adds an additional rc channel smoothing algorithm that can be used in place of the default rc interpolation. Utilizing a filter-based approach the smoothing has lower latency and is immune to loop time jitter that can introduce artifacts. Additionally a smoothing filter is added to the setpoint derivative used to produce D-term setpoint weight resulting in a smoother effect on D.
The default setting is to use the previous interpolation logic and there are no changes unless the optional method is selected.
Configuration:
rc_smoothing_type: (INTERPOLATION | FILTER) - defaults to INTERPOLATION
rc_smoothing_input_hz: (0-255) - sets the rc channel input filter cutoff in Hz. Default value of 0 will enable auto calculation based on received RX frame rate.
rc_smoothing_derivative_hz: (0-255) - sets the setpoint weight derivative filter cutoff in Hz. Default value of 0 will enable auto calculation based on received RX frame rate.
rc_smoothing_debug_axis: (ROLL | PITCH | YAW | THROTTLE) - determines which axis is logged in the debug fields
Debug logging:
set debug_mode = RC_SMOOTHING
debug(0) = raw un-smoothed rc channel data
debug(1) = raw un-smoothed setpoint derivative
debug(2) = filtered setpoint derivative before applied to setpoint weight
debug(3) = auto-calculated filter cutoff frequency base after sampling the rx frame rate
Notes:
Currently only enabled for F4/F7 due to flash size limitations
Uses the rc_inter_ch parameter to determine which channels are smoothed (same as default interpolation logic)
The auto filter cutoff calculation will set a cutoff frequency of 30Hz for typical SBUS frames (9ms). 11ms Spektrum will calculate to approximately 25Hz. The user can manually enter the filter cutoffs to be used instead of the auto calculation. The current default calculation was chosen as a good starting point but may be adjusted in the future.
Setting a lower cutoff frequency will result in more smoothing, but also more delay.
There currently isn't any support for receivers that change their rx frame rate dynamically. So for CRSF users wishing to use this alternate smoothing method should change their settings to lock the rx frame rate for now. Support for auto-adjusting to new frame rates in flight will likely be added.
