input_throttle_calc() uses Betaflight throttle curve #122
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR changes the throttle curve calculation to match Betaflight's.
Quicksilver's Throttle Curve
Currently in Quicksilver, throttle mid shifts the curve so that Y=mid when X=0.5. All of these graphs use mid=0.38 and expo=0.85 (no special meaning; just happens to be current settings):
However, Quicksilver's math means that the throttle curve no longer reaches 100%:
This is even more pronounced with lower midpoints. A throttle mid of 0.25 results in a maximum throttle output of 50%:
Betaflight Throttle Curve
"Mid" is probably a confusing name for Betaflight's implementation. It's made worse by this setting lacking a ? tooltip in their configurator, along with somewhat muddy community explanations over the years.
In Betaflight's throttle curve, mid is where the expo is applied. It's more like the center pivot point where throttle input equals throttle output. The same mid=0.38 and expo=0.85 values:
Stick midpoint no longer has any special meaning, and will depend on curve settings:
Crucially, 100% input always results in 100% throttle:
In Betaflight's throttle curve, mid has no effect if expo is 0.
Existing Implementation Mid > 0.5 Values
I do not have any heavy-enough whoops to require a >0.5 values for throttle mid, but it's worth pointing out that the throttle clips. Here is mid=0.8 on existing Quicksilver:
Motivation and Ramifications
For my use case, I am flying a 1S whoop where I am unable to give up any throttle headroom in my motor settings. I began investigating the throttle curve math in Quicksilver to see if I could work around the lowered throttle ceiling issue with some other settings. I don't see how I can, hence the code change.
For pilots that may be using larger craft with a motor limit already in place, they should be able to adjust their motor limit to compensate by raising their motor limit whenever they adjust their throttle curve.
Transmitters can also set throttle curves, although I do tend to tweak my curves per-quadcopter based on slight weight differences, which means I would need a different radio model per quad.
I don't have a clear idea of whether racers (or some other subset?) very specifically want this sort of "make stick midpoint map to different position on throttle curve" implementation that Quicksilver has now. Maybe? Although throttle curve clipping at mid values >0.5 and maximum throttle loss at <0.5 values seems like a poor tradeoff.
Merging this behavior will result in a different throttle curve for existing profiles with non-default mid/expo throttle curve values. At minimum this might require some adjustment (regardless of whether that pilot realized the curve limitations described above), or worse will remove the ability to remap their throttle in this different way.
My personal opinion is that the vast majority of people will expect Betaflight's throttle behavior. But there are other possibilities for implementing this PR: