Updates for finalize the flight performance.
Disable if GPS Rescue is active
Constrain the max setpoint calculated by the angle correction logic. To catch border cases where the user activates the feature while inverted and has a high gain which could result in excessively high setpoint rates.
Make sure internal states are reset when feature is activated via mode switch.
Adds a new angle limiting mode for pilots who are learning to fly in acro mode. Primarily targeted at new LOS acro pilots, but can be used with FPV as well.
The feature is activated with a new mode named "ACRO TRAINER". When the feature is active, the craft will fly in normal acro mode but will limit roll/pitch axes so that they don't exceed the configured angle limit. New pilots can start with a small angle limit and progressively increase as their skills improve.
The accelerometer must be enabled for the feature to be configured and function.
Also the feature will only be active while in acro flight and will disable if ANGLE or HORIZON modes are selected.
For most users all they need to do is simply configure the new mode to be active as desired on the "Modes" tab in the configurator and configure the desired angle limit in the cli.
Configuration parameters:
acro_trainer_angle_limit: (range 10-80) Angle limit in degrees.
acro_trainer_lookahead_ms: (range 10-200) Time in milliseconds that the logic will "look ahead" to help minimize overshoot and bounce-back if the limit is approached at high gyro rates. The default value of 50 should be good for most users. For low powered or unresponsive craft (micros or brushed) it may be helpful to increase this setting if you're seeing substantial overshoot.
acro_trainer_debug_axis: (ROLL, PITCH) The axis that will log information if debugging is active.
To enable debugging:
set debug_mode = ACRO_TRAINER
debug(0) - Current angle
debug(1) - The internal logic state
debug(2) - Modified setpoint
debug(3) - Projected angle based gyro rate and lookahead period
* through extensive testing prior to the beginning of the RC cycle, we have
discovered that the simplest combination of filters appears to be up to four
PT1 filters: two for gyro, and two for d-term.
* non-cascaded biquad filter plumbing is retained for noisy setups and the
dynamic notch bandpass, although gyro and d-term variants of the filtering may
eventually be removed in favor of pt1
* update all related unit tests
I'm flying race with betaflight and on all my race quads I have setpoint on maximum value 2.54. But I feel, that it's not enough. This calculation of setpoint is almost same as old method up to number 2.0 (previously 2.54) but numbers above 2.0 have more aggresive impact on Dterm RC stick commands. With this calculation i found, that value 2.3 is fine for me. 2.3 is equivalent to 6,35 with old calculation method (which was not possible of course, because there is 8bit limit). With higher values have quad much sharper responses and feel more "locked in".
I think, that most freestyle pilots have setpoint at values around 1, so there is almost no change and race pilots using higher values and for those, who are limited by the value 2.54 (like me and my friends) should be solution new setpoint calculation method.
This is my first pull request to betaflight, so I hope, that I did everything well according your rules
* PID controller unittest
* Clean code for yaw spin recovery
* Yaw spin recovery optimizations
* Flash size optimizations, use 50% throttle when airmode is off, and override pidsum_limit_yaw
Also rebasing from betaflight/master
* Added FAST_RAM_INITIALIZED for those who really want it
* Added the white crow of KISSFCV2F7
* Made initialized data LMAs robust
* Fixed indirection when initializing fast memory
* * Fixing the #5705 (D-Term spikes)
- For D-Term calculation I reverted back to use dT instead of jittery deltaT
- Moved calculation of deltaT to handleItermRotation because it is the only place now where it is used
* * Changed the constant expression per DieHertz request
* * Changed the type of argument to match the type from caller
* * Redone also the handleItermRotation to dT per @ledvinap request
* * Put PID variables into the structure
* Precalculate DTerm gyro filter outside the axis loop
* Removed unused variables PIDweight[3], airmodeWasActivated
* If zero throttle or gyro overflow, we can just set values and exit, this saves checks and jumps in axis loop
* Compute PIDSUM after the axis loop, this saves branching inside the loop because of Yaw has no D term
* * Incorporated review changes from DieHertz and fujin
* * Incorporated another review requests from DieHertz
- PidSum renamed to Sum
- pidData[3] redone to pidData[XYZ_AXIS_COUNT]
Adds new throttle_limit_type and throttle_limit_percent parameters that allow the pilot to limit the maximum commanded throttle seen by the flight controller by either scaling or clipping the maximum throttle. The default is 100 representing no limiting. So as an example, if a pilot was to set throttle_limit_type = SCALE and throttle_limit_percent = 80 the throttle input would scale from 0 to 80% based on full stick deflection from the radio.
This capability replaces the method of limiting throttle in the radio which some pilots are using to manage throttle on tight courses or reduce overall battery consumption when the extra power isn't needed.
There is no effect on the maximum throttle seen by the motors so the mixer still has full authority.
* ITerm rotation
* address requested changes
* now counting up
* scale errors according to Ki while rotating
* iterm_rotation profile setting
* revert to non scaled version, style related fixes
* Triggering a CI build.
