Current logic produces excessive load because it updates the filter cutoffs every PID loop based on the throttle value.
The throttle values only change based on receive RX packets so they change relatively infrequently compared to the PID loop. However with rc smoothing on throttle the value can change every PID loop. But in reality we don't really need to adjust the filter cutoffs for every tiny change to the floating point throttle value.
This change quantizes the throttle in to 100 steps and uses that to compare to the previous value to decide if the filter cutoffs need to be updated. While this reduces the resolution of the filter cutoffs it in turn dramatically reduces the processing overhead. IF needed the quantization steps can be increased for more resolution but at the cost of some performance.
Adds a race start assistance system that allows the pilot to pitch forward and then release the sticks with the quad holding position for the race start.
The MOTOR_STOP logic is designed to stop the motors if:
1. MOTOR_STOP feature is enabled
2. Airmode is disabled
3. Throttle is at minimum
The problem is that this also applied during GPS Rescue and if the pilot had these conditions the motors would stop. Changed to disable MOTOR_STOP while GPS Rescue is active.
Also if stick-arming is used the MOTOR_STOP logic also will auto-disarm after 5 seconds (auto_disarm_delay). Disable this also when GPS Rescue is active.
When using switched 3D modes the throttle stick ranges from 0-100% controlling the motors in only one direction. The problem was that the 3D Throttle Deadband was being applied to the minimum throttle making a much larger throttle deadband from zero throttle. So in the case of the default deadband of 50, the throttle stick movement would be equivalent to 100us of deadband (output is halved so requires double the input). This would be like trying to fly with `min_check` set to 1100.
The fix uses `min_check` to set the deadband when in switched 3D modes. This produces the same throttle deadband as normal non-3D flight.
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.
The telemetry data provides eRPM/100. Added a `motor_poles` parameter (defaulting to 14) that is used to calculate the physical RPM.
RPM = (telemetry_rpm * 100) / (motor_poles / 2)
Most motors we commonly use are 14 poles, but the user can adjust if needed for their setup.
Also calculate actual RPM for DEBUG_ESC_SENSOR_RPM, but to fit with in int16 the log value will be RPM/10.
* 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
* 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]
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.
* Fix for minthrottle when feature 3d and pwm enabled
* add parameters for min and max 3d output
* bug fix
* remove new parameters from msp
* remove new parameters again
* fixed indentation
