Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

input_throttle_calc() uses Betaflight throttle curve #122

Merged

Conversation

mwegner
Copy link

@mwegner mwegner commented Jan 12, 2025

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):

Screenshot 2025-01-12 at 08 35 24

However, Quicksilver's math means that the throttle curve no longer reaches 100%:

Screenshot 2025-01-12 at 09 10 13

This is even more pronounced with lower midpoints. A throttle mid of 0.25 results in a maximum throttle output of 50%:

Screenshot 2025-01-12 at 09 11 37

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:

Screenshot 2025-01-12 at 09 16 49

Stick midpoint no longer has any special meaning, and will depend on curve settings:

Screenshot 2025-01-12 at 09 16 57

Crucially, 100% input always results in 100% throttle:

Screenshot 2025-01-12 at 09 17 04

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:

Screenshot 2025-01-12 at 09 19 03

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:

  • Allow user to choose a throttle curve mode, similar to rate calculation modes
  • Keep existing math, but somehow lerp/blend so that 100% input still results in 100% output. At least for me, truncating max throttle output is a no-go on my 1S setups and is the thing I care most about here (using Betaflight's curve is just one way to achieve this easily)

@mwegner
Copy link
Author

mwegner commented Jan 12, 2025

There's a matching configurator PR here: BossHobby/Configurator#19

"Midpoint" is expo origin/pivot, not a remap where X=0.5 results in Y=mid
@bkleiner bkleiner force-pushed the feature-betaflight-throttle-curve branch from f1eb5a7 to d91b3ff Compare January 13, 2025 11:51
@bkleiner
Copy link
Collaborator

lets give this a try. we gonna have to warn users about the change in behaviour when it comes time and then wait for feedback.

@bkleiner bkleiner merged commit 9c1d5d3 into BossHobby:develop Jan 13, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants