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.
* Dual-stage Gyro Filtering: PT1, FKF, and Biquad RC+FIR2
* Builds on the previous work of apocolipse.
* Fixes 'stage2'/'stage1' mis-naming to reflect where it is applied in the loop.
That is, the older Biquad, PT1, Denoise (FIR) filters are 'stage2' - applied
after dynamic and static notches (if enabled), and the controversial PT1,
'fast Kalman' filter, and Biquad RC+FIR2 filters, are 'stage1'. e.g. before
dynamic notch.
* FKF bruteforce Kalman gain removed. Calculate from half of PT1 RC constant,
automatically taking loop-time into account.
* New union type definition for stage1 filtering.
* New gyro sensor members for stage1 filter application function and states for
all three supported filter types
* New enum types for stage1 v. stage2. dterm lowpass type references 'stage2'.
* updates to CMS/MSP/FC to allow compilation (untested, probably breaks
MSP, Lua, and ~comms with BFC~).
* Refactors FKF initialization, update and associated structures to be faster by
not continuously calculating 'k'. Filter gain is calculated once during
initialization from RC constant as per PT1 and Biquad RC+FIR2. It was
discovered this converges to static value within 100 samples at 32kHz, so can
be removed. Remove related interface (CLI) settings.
* update dterm_lowpass_type to use new 'TABLE_LOWPASS2_TYPE' (biquad/pt1/FIR)
* Stage 1 defaults to PT1, 763Hz (equivalent to Q400 / R88 from quasi-kalman
filter) - suitable for 32kHz sampling modes. Can be switched to Biquad
RC+FIR2, and FKF.
* Update `#if defined(USE_GYRO_SLEW_LIMITER) to `#ifdef`.
* Includes optional Lagged Moving Average 'smoothing' pipeline step, applied (in
code) after the output of stage1.
* (diehertz): Removed redundant pointers from gyro filtering
* blackbox: fix indentation
* cms IMU menu: fix indentation
* filters: remove USE_GYRO_FIR_FILTER_DENOISE in filter type enum
* gyro sensors: go back to `if defined()` form. for slew limiter
* gyro sensors: increment parameter group version
* due to non-appending changes, the version must be bumped.
* Second PT1 on DTerm
This PR replaces the default biquad filter with a second PT1 set to
200Hz.
Basically allows the user to enable a second, set point configurable,
PT1 type first order low-pass filter on DTerm.
This is useful because most noise in most logs arises from D, not P.
The default is set to on, at twice the normal Dterm setpoint. This
provides greater Dterm cut than a single PT1, and twice the steepness
of cut above the second setpoint. Modelling shows significant
reductions in higher frequency Dterm noise with only minor additional
delay.
The improvement in noise performance will be less than for biquad, but
the delay is considerably less.
If with the default settings the overall noise improves a lot, it may
be possible bring D both filtering set points to higher numbers (e.g.
140/280), or alternatively remove other filters such as the notch
filters, while maintaining an adequate level of control over noise.
* Update names, old defaults, fix whitespace
Defaults restored to biquad with second PT1 off. ‘lpf’ retained as
abbreviation for values, otherwise generally remove ‘Filter’ where
redundant, replace ‘FilterLpf’ with ‘Lowpass’, etc, thanks Fujin and
DieHertz
* Remove underscore in lowpass_2, add hz to setpoint for lowpass
Thanks DieHertz
* completed replacing lpf with lowpass, added _hz to all lowpass set points in profile
Thanks DieHertz
* fix whitespace
fixed whitespace in settings.c
* whitespace attempt #57
* change lpf to lowpass where appropriate elsewhere
Note did not change OSD abbreviations, they are still LPF, and did not
change gyro_lpf anywhere.
* second attempt at a simple PT1 implementation
Basically copied from the DtermNotch implementation
* Second PT1 on DTerm
This PR replaces the default biquad filter with a second PT1 set to
200Hz.
Basically allows the user to enable a second, set point configurable,
PT1 type first order low-pass filter on DTerm.
This is useful because most noise in most logs arises from D, not P.
The default is set to on, at twice the normal Dterm setpoint. This
provides greater Dterm cut than a single PT1, and twice the steepness
of cut above the second setpoint. Modelling shows significant
reductions in higher frequency Dterm noise with only minor additional
delay.
The improvement in noise performance will be less than for biquad, but
the delay is considerably less.
If with the default settings the overall noise improves a lot, it may
be possible bring D both filtering set points to higher numbers (e.g.
140/280), or alternatively remove other filters such as the notch
filters, while maintaining an adequate level of control over noise.
* Rebase
* Remove underscore in lowpass_2, add hz to setpoint for lowpass
Thanks DieHertz
* completed replacing lpf with lowpass, added _hz to all lowpass set points in profile
Thanks DieHertz
* fix whitespace
fixed whitespace in settings.c
* whitespace attempt #57
* change lpf to lowpass where appropriate elsewhere
Note did not change OSD abbreviations, they are still LPF, and did not
change gyro_lpf anywhere.
* second attempt at a simple PT1 implementation
Basically copied from the DtermNotch implementation
* Whitespace fix - thanks, Ledvinap
* Fix PG issue
by moving added dterm_lowpass2_hz to bottom of struct
* Got rid of redundant indirection
* Fixed indentantion shifts
Removed parameters runaway_takeoff_threshold (hardcode to 60) and runaway_takeoff_activate_delay (hardcode to 75). The previous default values worked well and required no tuning.
Enhance the deactivate logic to remove the R/P/Y stick activity condition once throttle reaches 2X runaway_takeoff_deactivate_throttle_percent. Additionally reduce the runaway_takeoff_deactivate_delay by 50% when throttle exceeds 75%.
