Motor Output Limit and Profile Cell Count

[asizon]

Added motor_output_limit and auto_profile_cell_count configurable parameters. I know there is no place at all appropriate to add it, happy to hear opinions and discuss this :)

[dridsfpv]

LIMIT: limits the maximum output signal for the motors. In order to use batteries with more cells than those the motor theoretically supports (make sure the electronics supports the voltage). Less than 100% limit causes a linear reduction in the motor drive signal.
LIMIT =desired KV / real KV * 100
Example: LIMIT=1800/2700*100=67

CELL COUNT: it allows to assign profiles for different type batteries (with different number of cells). Betaflight automatically detects de voltage of the battery when plugged in the quad and it will select the according profile.

[mikeller]

Just a cosmetic remark: Wouldn't it be better to add the tooltips to the fields themselves:

This will also make it easier to maintain when fields are moved around.

[asizon]

Yes @mikeller ,much better like that, thanks!

[mikeller]

@McGiverGim: What do you think about the Sonar 'bugs' reported on this pull request?

[McGiverGim]

Until now we have ignored this HTML bugs but we can try to fix them. @asizon can you look at the Sonar link and try to fix them? If you click on the issue there is an explanation about the problem and how to fix it.

[asizon]

I will try it now! And need to revise the tootltip, what do you think about the above @dridsfpv proposal?

[mikeller]

@McGiverGim: Not 100% sure this is the right approach. Pretty much all of these 'bugs' seem to be aiming at making content and applications available to vision impaired users through screen readers. While this is a good and important thing for general purpose users, I am reasonably sure that there is only very little overlap between users who can not read text on a screen and users who fly racing drones, therefore I am not sure it is good use of time to fix these 'bugs' - maybe we should just ignore them in the sonar config?

[McGiverGim]

True. We can disable them in Sonar to limit this kind of errors.

[asizon]

@mikeller what do you think about these ctzsnooze suggested names??

[mikeller]

@asizon: Looks good to me - I think for these settings it is important that the help texts are good, as the things that are controlled by them are relatively complex.

[ctzsnooze]

This is really great!
Although it's called motor_output_limit in the CLI, it's a linear attenuation of motor outputs, and at max there is a limit. But it's important to know that it attenuates below the limit. Hence suggesting that we write 'Attenuation %' to indicate that it isn't a simple 'hard cutoff' limit. Maybe that will convey a bit better what it actually achieves.

[mikeller]

@ctzsnooze: The CLI name is not very good in reality - we should flog they guy who put it in in the first place in betaflight/betaflight#7482 - oh wait. 🤔
'Attenuation' is much better indeed. In CLI I'd have concerns about this being a term that isn't necessarily familiar with non-English speakers, whereas in the UI we can address this with translations.

[ctzsnooze]

For the info messages, maybe something like:
LIMIT: Attenuates motor commands by the set percentage. Reduces ESC current and motor heat when using higher cell count batteries, e.g. for similar performance from a 6S battery on a 4S build, try 66%; for a 4S battery on a 3S build, try 75%.
CELL COUNT: Automatically activates the first profile that has a cell count equal to the connected battery.

[mikeller]

@ctzsnooze: Looks good - we probably don't need the 'LIMIT' / 'CELL COUNT' headers in the tooltip - it is clear enough what they belong to.
@asizon: Do you want to change the texts to @ctzsnooze's proposals?

[sonarcloud]

SonarCloud Quality Gate failed.

8 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
0.0% Duplication

[asizon]

Yes @mikeller i have updated to ctzsnooze suggested texts :) and squashed. Thanks for your text suggestions @ctzsnooze and @dridsfpv

[Juzzle1]

The new tool tip states:
LIMIT: Attenuates motor commands by the set percentage.

Surely this should read
LIMIT: Attenuates motor commands to the set percentage.

In my mind the current wording implies a value of 100% will attenuate the output by 100% and therefore be zero?

[mikeller]

@Juzzle1: You are correct - calling this 'attenuation' is actually not a good term for it anyway, as this is 'the amount of reduction'.

[Juzzle1]

I think the term 'limit' is also very confusing, as this suggests a cap on the peak output power, rather than linear scaling.

I'd suggest:

Frame title:
Motor Output Scaling

Setting label:
Scale Factor (%)

Tip text:
Motor output linear scale factor (as percentage). Reduces ESC current and motor heat when using higher cell count batteries, e.g. When using a 6S battery on a craft that has motors, props and tuning designed for 4S, try setting the value at 66%; when using a 4S battery on a craft intended for 3S, try 75%.
Always make sure that all of your components can support the voltage of the battery you are using.

[mikeller]

@Juzzle1: Yes, that sounds better - can I get you to open a pull request for these changes?

[asizon]

Sure that we want to change now all feature name?maybe we should keep the feature name and change only the setting name. Also @Juzzle1 take acount that the current tooltip is on #1977

[mikeller]

For what I can see this is only used in 2 places, pidTuningMotorLimit and pidTuningMotorLimitHelp, so the fallout should be benign. And @Juzzle1 is right, 'attenuation' is the wrong term for this - e.g. if you attenuate the output by 20% you are left with 80% of the output.

[asizon]

Yes, i agree that attenuation is wrong and we must change it. But I see that @Juzzle1 also want to change Motor Output Limit to Motor Output Scaling? .

[Juzzle1]

'Limit' is also used in the CLI (motor_output_limit) , so don't want to make things more confusing, however I don't think this is the correct terminology for what the feature actually does.