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
The `failsafe_kill_switch` parameter has been renamed to
`failsafe_switch_mode` and it determines what happens
when the Failsafe mode is activated with an AUX switch.
It takes one of three values:
0 - simulates RC signal loss - thus activates Stage1 failsafe
(former behavior when kill switch option was OFF)
1 - disarms immediately
(former behavior when kill switch option was ON)
2 - activates the failsafe procedure (Stage2) immediately (new)
* 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
Previously the code in subTaskRcCommand() was part of subTaskMainSubprocesses() which is set to FAST_CODE_NOINLINE. When it was split out into a separate function it inherited FAST_CODE from taskMainPidLoop() which made it get inlined and caused ITCM_RAM overflow.
In #5905 the ordering of rc interpolation processing was moved out of subTaskMainSubprocesses() and into a separate subTaskRcCommand() process that ran earlier in the PID loop. Previously the logic to handle stick arming yaw reset was immediately before the rc interpolation logic and after the previous change it ran later in the process and after rc interpolation.
This fix moves the related throttle/yaw processing into the subTaskRcCommand() before rc interpolation to match the ordering that existed previously. The fixes introduced by #5905 (throttle spikes) are still retained.
