Refactor dMin to dMax

[mituritsyn]

Configurator part for betaflight/betaflight#13908

[netlify]

✅ Deploy Preview for origin-betaflight-app ready!

Name	Link
🔨 Latest commit	bad319a
🔍 Latest deploy log	https://app.netlify.com/sites/origin-betaflight-app/deploys/66f035896e87f20008121a6f
😎 Deploy Preview	https://deploy-preview-4173.dev.app.betaflight.com
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[nerdCopter]

needs to be backward compatible (gated) labeling.

i'd suggest if/then to swap labels only irregardless of other logic.

[ctzsnooze]

Maybe make the 'D' in 'Derivative' label bold, also?

[ctzsnooze]

Also, in image above, D Max values are shown as being smaller than Derivative values, whereas they should always be greater. Perhaps update the image ?

[haslinghuis]

Backwards compatibility

[mituritsyn]

i'd suggest if/then to swap labels only irregardless of other logic.

I'm not sure I've made the best implementation.

2b30712

[haslinghuis]

• Normally only have to change english locale only - other locales get overwritten by crowdin but it does not hurt to have them updated.
• Backwards compatibilty looks to be resolved except for the sliderWarning
• In PR with 4.5.2:
  
• In master with 4.5.2:
  

[haslinghuis]

Perhaps (need to import semver)

Suggested change

	const enableWarning = FC.PIDS[0][0] > WARNING_P_GAIN || FC.PIDS[0][1] > WARNING_I_GAIN || FC.PIDS[0][2] > WARNING_D_GAIN || FC.ADVANCED_TUNING.dMaxRoll > WARNING_D_MAX_GAIN;
	const enableWarning = semver.lt(FC.CONFIG.apiVersion, '1.47.0')
	? FC.PIDS[0][0] > WARNING_P_GAIN || FC.PIDS[0][1] > WARNING_I_GAIN || FC.PIDS[0][2] > WARNING_D_MAX_GAIN || FC.ADVANCED_TUNING.dMaxRoll > WARNING_D_GAIN
	: FC.PIDS[0][0] > WARNING_P_GAIN || FC.PIDS[0][1] > WARNING_I_GAIN || FC.PIDS[0][2] > WARNING_D_GAIN || FC.ADVANCED_TUNING.dMaxRoll > WARNING_D_MAX_GAIN;

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.8% Duplication on New Code

See analysis details on SonarCloud

[mituritsyn]

• Normally only have to change english locale only

nice to know)
there is duplicate pidTuningDerivativeHelp key, I'm sure there should be only one but they have similar text.

[haslinghuis]

Last edition 2672:

Controls the strength of dampening to ANY motion on the craft. For stick moves, the D-term dampens the command. For an outside influence (prop wash OR wind gust) the D-term dampens the influence.<br><br>Higher gains provide more dampening and reduce overshoot by P-term and FF.<br>However, the D-term is VERY sensitive to gyro high frequency vibrations (noise | magnifies by 10x to 100x).<br><br>High frequency noise can cause motor heat and burn out motors if D-gains are too high or the gyro noise is not filtered well (see Filters tab).<br><br>Think of the D-term as the shock absorber on your car, but with the negative inherent property of magnifying high frequency gyro noise.

Previous edition 2572 line 1861 should probably be removed - BUT seems currently in use:

Baseline damping of ANY motion of the craft. <br /><br />Opposes movement whether caused by stick inputs or external influences (e.g. prop-wash or wind gusts)<br /><br />Higher D gains provide more stability and reduce overshoot.<br /><br />D amplifies noise (magnifies by 10x to 100x). This can burn out motors if gains are too high or D isn't filtered well.<br /><br />D-term is a bit like the shock absorber on your car.

[haslinghuis]

@mituritsyn

• noticed D_MAX calculation has changed (an improvement as D_MAX is allowed below D while D_MIN could not be lower than D) as we no longer use dminRatio in firmware calc.
• this better represents gain factor for amount of gyro / setpoint activity required to boost D ?

PR with 13908:

Master:

EDIT: resolved in betaflight/betaflight@2bb6cef

[mituritsyn]

@mituritsyn

• noticed D_MAX calculation has changed (an improvement as D_MAX is allowed below D while D_MIN could not be lower than D) as we no longer use dminRatio in firmware calc.

No, I'm trying to keep the old behaviour. I've updated the calculation formula in the firmware.