Change the logic to not modify rcCommand directly and instead apply the additional throttle directly in the mixer.
Also move the logic to the attitude task instead of having it calculate in the PID loop. The logic relies on an angle that's only updated in the attitude task so there was no point in running the calculation every PID loop.
Injecting new values directly into rcCommand to override pilot inputs does not work correctly when rc interpolation or smoothing is enabled. This is because the smoothing functions maintain an internal state that is used to produce the final rcCommand values. So in effect it re-overrides the values set by GPS Rescue.
Additionally, modifying rcCommand directly is undesirable because:
- It happens before rates are applied. So the pilot's rates will effect the control commanded by GPS Rescue.
- rcCommand values are used for more than input in the flight control. They also are used for stick commands, etc.
- In the case of throttle, various modifications can be additionally applied like throttle boost and throttle limit that may negatively effect GPS Rescue.
These changes revise the logic to only modify the commanded values used in the PID controller (yaw) and mixer (throttle) rather than attempting to override rcCommand.
Tries to prevent DSHOT beacon commands from interfering with commands to set the motor direction.
Adds a 2 second delay after disarming before DSHOT beacon commands will be sent. This attempts to prevent the beacon commands from interfering with the motor direction reset that happens after using crash flip mode.
During arming if a DSHOT beacon command has been sent within 2 seconds the arming will be delayed until the 2 seconds have passed. This attempts to prevent interference with the motor direction commands sent at arming.
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
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.
Fixes an issue with motor "spikes" when rc interpolation was enabled for throttle. The problem was that the smoothing was happening too late in the sequence and the earlier process subTaskMotorUpdate() would use the unsmoothed throttle value in the mixer if new rx data had come in between the last and current PID loop. Also because the setPointRate was calculated at the end of the smoothing, the PID controller would always be using the value from the previous loop iteration.
During team relay races it's unsafe to retrieve crashed quads because the course is continuously hot. In order to safely fly a backup quad with the primary quad crashed in the field (but powered up) it's necessary to:
* Disable arming, so that the crashed quad doesn't unintentionally arm as well. This is specifically a problem when a transmitter can send signals to all powered up receivers (like FrSky and others).
* Change VTX to an unused channel with low power output
* Turn off telemetry
This change introduces a new mode called paralyze which disables arming and prevents mode changes (except beeper). It can only be invoked while the quad isn't armed. Once it's invoked, the FC has to be power cycled. In order to invoke it, the mode needs to be in a disengaged state at least once, so that forgetting to flip the switch back after crashing doesn't immediately invoke graveyard on the backup quad.
_Legal disclaimer: I am making my contributions/submissions to this project solely in my personal capacity and am not conveying any rights to any intellectual property of any third parties._
* Revert "Revert "Rewritten F7 dshot to LL (draft)" (#5430)"
This reverts commit aa42a69d2f.
* Reworked F7 linker scripts to maximize performance of both F74x and F72x
* Some comments and changes from original F7 HAL DSHOT
* Prohibit inlining of some functions to place them in ITCM-RAM
* Fixed usartTargetConfigure implicit declaration
* Moved back to SRAM1 as main RAM
* Added SRAM2 attribute
* Fixed LL DSHOT FOR SPRF7DUAL and probably other adv TIM users
* Fixed SPRF7DUAL rev. A motor order
* Enabled CCM for data on F40x
* Fixed F7 startup assembly symbols
* Fixed KISSFCV2F7 linker script
* Added a quick way of building F7 targets only
* Got rid of the useless F7 target script
* Added NOINLINE and got rid of useless __APPLE__ define
* Added some important functions to ITCM
* Added NOINLINE macro for tests
* Copy to ITCM before passing execution into it
* Minimized cache footprint of motor output code
* Evicted low-impact functions from ITCM
* Switched MATEKF722 and SPRACINGF7DUAL to burst DSHOT
* Switched CLRACINGF7 to burst DSHOT
* Moved UART RX&TX buffers to DTCM-RAM to avoid cache incoherency
* Marked taskMainPidLoop for ITCM-RAM, disallowed inlining per-function
* Revert "Added a quick way of building F7 targets only"
This reverts commit 2294518998.
* * 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]
Previously the flag was only set during arming so after crash flip mode was used the flag would stay active until the next arming. This caused the "CRASH FLIP" warning message to erroneously display on the OSD when disarmed.
