Add rates type selection #1909

fgiudice98 · 2020-03-07T22:07:41Z

Discussion / screen shots in: #1906

mikeller · 2020-03-07T22:22:06Z

Looks like it's still not working. Working on it.

mikeller · 2020-03-08T00:06:04Z

Ok, now the Sonar checks are working. Sonar got confused by the branch the pull request is on being identical to master in the fork it was made on. :-(

mikeller

Re-added my comments from #1906.

src/js/tabs/pid_tuning.js

mikeller · 2020-03-08T00:24:50Z

src/js/tabs/pid_tuning.js

+    }
+}
+
+TABS.pid_tuning.changeRatesTypeLogo = function() {


While this looks great, I am not sure how much value it is, especially for users with small screens. So we might drop the rates logos at some point in the future.

I think maybe they are too big. I like the logos but maybe a little smaller will fit in big and small screens.

The logos occupy an unused space in the rates type selection tab, and scale accordingly, so no space wasted. They are a late addition to the code. If you see the screenshots you will clearly see that they are in empty and wasted space

If then there are problems they can be removed, but i think it's better this way
(And i personally tested the app all the time in a 1366x768 screen with the smallest possible windows size without problems)

What I say is that it does not need to occupy all the space. Maybe smaller looks cleaner. But it always depends on the taste of the developer 😉

Will do a little smaller then

mikeller · 2020-03-08T00:25:54Z

src/js/tabs/pid_tuning.js

@@ -779,6 +841,7 @@ TABS.pid_tuning.initialize = function (callback) {
            ADVANCED_TUNING.motorOutputLimit = parseInt($('.pid_tuning input[name="motorLimit"]').val());
            ADVANCED_TUNING.autoProfileCellCount = parseInt($('.pid_tuning input[name="cellCount"]').val());
            ADVANCED_TUNING.idleMinRpm = parseInt($('input[name="idleMinRpm-number"]').val());
+            RC_tuning.rates_type = $('select[id="ratesType"]').val();


One important aspect of making this configurable in the UI is that this allows us to track how many users select each rates type by adding analytics tracking for this.
Can you please add something like this:

let value = parseInt($('select[id="ratesType"]').val()); let newValue = undefined; if (value !== RC_tuning.rates_type) { newValue = $('select[id="ratesType"]').find('option:selected').text(); } self.analyticsChanges['RatesType'] = newValue; RC_tuning.rates_type = value;

This will cause the selected rates type to be sent as analytics data.

I need to add anything beside this?

fgiudice98 · 2020-03-08T00:32:38Z

Thanks @mikeller. Will fix all asap

mikeller · 2020-03-08T02:26:44Z

@fgiudice98: I think the 'Actual Rates' type needs a a conversion of the values entered in the UI as well - please make sure you get feedback from @ctzsnooze on this.

src/js/tabs/pid_tuning.js

McGiverGim · 2020-03-08T08:42:40Z

src/js/tabs/pid_tuning.js

+    }
+}
+
+TABS.pid_tuning.changeRatesTypeLogo = function() {


I think maybe they are too big. I like the logos but maybe a little smaller will fit in big and small screens.

src/tabs/pid_tuning.html

ctzsnooze · 2020-03-08T08:44:12Z

Hi @fgiudice98 this looks great. I have built it for mac and will check later when I am home. Asizon has shown me screen dumps that look correct for Actual mode.
I like the logos, myself :-)
My only comment is that for Actual and Quick rates, it would be good to limit the max input to say 2000 deg/s.
Also I would personally really like it that if I am entering a rate, I enter it as the degrees per second. So, for the maximum rate of 400 deg/s, I would enter 400, not 0.4.
I would be very grateful if that could be done, but only if it is possible.
I note that the 'Max Vel' column will still be useful for situations where someone sets the centre rate higher than the max rate.
Note also that the resolution in Actual mode for rates is 10deg/s, so it would need to round values entered to the nearest 10.
In Quick rates mode the resolution is better, steps of 2 deg/s.
This is looking really great!

fgiudice98 · 2020-03-08T09:23:59Z

My only comment is that for Actual and Quick rates, it would be good to limit the max input to say 2000 deg/s.

For Quickrates this is done into the betaflight code, and i think it's better this way just to prevent errors when setting up from cli

Also I would personally really like it that if I am entering a rate, I enter it as the degrees per second. So, for the maximum rate of 400 deg/s, I would enter 400, not 0.4.

Yeah, just tell me what scale and min, max, step values i need to put in the code

Note also that the resolution in Actual mode for rates is 10deg/s, so it would need to round values entered to the nearest 10.
In Quick rates mode the resolution is better, steps of 2 deg/s.

If you have the rate in deg/s the step is always 10deg/s, even in quickrates

mikeller · 2020-03-08T12:30:48Z

@fgiudice98:

For Quickrates this is done into the betaflight code, and i think it's better this way just to prevent errors when setting up from cli

There are other places where the scale of parameters set in CLI is different from what is displayed in the UI - for example in cases where the actual value has got fractions, which are not supported in CLI.

Here the issue is that in the firmware the parameters for all rates types are stored in the same parameters, and CLI does not support scaling of parameters based on other parameter values. In the UI we can do this, and we should.

fgiudice98 · 2020-03-08T12:46:17Z

@fgiudice98:

For Quickrates this is done into the betaflight code, and i think it's better this way just to prevent errors when setting up from cli

There are other places where the scale of parameters set in CLI is different from what is displayed in the UI - for example in cases where the actual value has got fractions, which are not supported in CLI.

Here the issue is that in the firmware the parameters for all rates types are stored in the same parameters, and CLI does not support scaling of parameters based on other parameter values. In the UI we can do this, and we should.

Yes, i know, i even do it in my code. But i was talking about the hard limit of the 2000deg/s of the angleRate, i think i missread.
For me there is no problem to change the scale and/or min max values. It's a must to have good values in the configurator, so looking forward to change the configuration of actual rates in the next commit

fgiudice98 · 2020-03-08T16:52:25Z

@mikeller @McGiverGim apart from the const var that i sure need to change. What to do with the other sonar issues? Need to make all the literals in variables? Is it really needed even if they are in completely different functions?
Another issue seems to be the functions complexity, what to do here?

By the way, here the latest build for testing:
WINDOWS
CHROMEOS

McGiverGim · 2020-03-08T17:21:35Z

Not all. The literals we transform in variables if it is clearer, but sometimes it is worst than the literal form. At least for me I let you decide this part.

fgiudice98 · 2020-03-08T17:42:05Z

@McGiverGim just what i was thinking about the literals

mikeller · 2020-03-09T00:17:44Z

Good progress @fgiudice98!

Looking at the remaining items in the Sonar report:

the bugs are all good and can be left as is, they are informational only because they pertain to improve accessibility for vision impaired users, which is not a good match to our target audience of RC pilots (we'd remove them from the checks, but Sonar does not allow this);
the cyclomatic complexity smell is often just an indication for code that could be broken up to make it more maintainable. Looking at rcCommandRawToDegreesPerSecond() I think a good way in this case would be to extract the different cases in the switch() statement into functions that each calculate the rates for one rates type - this is analogue to what is done in the firmware, and will it make much more obvious how the rates calculation will have to be updated if it is ever changed in the firmware, increasing the chance of this pushing through into configurator;
changeRatesType() will probably refactor enough if you pull changeRatesSystem() out of the closure;
for the variable naming smells, I think using snake_case in places where the name is used to reference a DOM element that is snake_case as well this is acceptable, like pitch_rate_e = $('.pid_tuning input[name="pitch_rate"]'), but for places where this is not the case, like let ratesList_e = $('select[id="ratesType"]') this should be changed to ratesListElement, or even better ratesTypeListElement;
the rest of the smells seem to be reasonable to me and I think they should be addressed.

ctzsnooze · 2020-03-09T01:53:37Z

It looks really good now from the user perspective with current firmware.
Need to check how it handles earlier code that only has three rates types, in which there is no MSP support for rates type.

fgiudice98 · 2020-03-09T07:45:45Z

@mikeller thanks for the advice! will fix and test all in a while

@ctzsnooze I tested earlier when working on it and all seems good, but as i said in the description other tests are always welcome

asizon · 2020-03-09T07:49:20Z

Works fine with previous MSP versions 1.42. Good job! Also smallers logos looks better, warning message cosmetic also now is perfect, looking forward to see it in 4.2 and 10.7.0

TheIsotopes · 2020-03-09T08:56:28Z

tested now all the latest fixes.
after selecting a rate type, the betaflight logo is always displayed and not the logo of the selected type. the logo will only be updated when I change another tab and then go back to the pid tuning tab.

@fgiudice98 can you check this

fgiudice98 · 2020-03-09T09:11:12Z

@TheIsotopes will be fixed in the next commit, thanks for the report

asizon · 2020-03-09T09:11:25Z

yes i can reproduce it, not efect at all when changing type, only changes rates type, no efect in values,graphics,image, all tab

asizon · 2020-03-09T09:14:45Z

Don't know if it's a .change problem @fgiudice98 , when you restart configurator, it loads everything perfectly, except the values that were previously saved

fgiudice98 · 2020-03-09T09:32:41Z

Should be all working now

Edit: @asizon there was a problem with the value step validation, strange that i didn't found out when testing before commit

Latest build for testing:
WINDOWS
CHROMEOS

asizon · 2020-03-09T09:36:50Z

ok tested, only one problem, I cant goes with previoues saved values and rate type, i get a warning message also for change to my previous saved settings

fgiudice98 · 2020-03-09T10:22:41Z

Guys, me and @asizon were talking about the change rates type warning. For now it shows when changing to a rates type that is not the one saved in the eeprom. This warning has two buttons, one to proceed with the change and one to return to the saved configuration. What do you thing about it? Is better this way to prevent configuration error by the user or it needs some changes?

mikeller · 2020-03-09T10:36:43Z

@fgiudice98: I just had a look at the warning popup in the latest version, and to me this looks good.

fgiudice98 · 2020-03-09T10:47:55Z

@mikeller Perfect! Tell me when i need to make the rebase and squash

McGiverGim

Only two minor "cosmetic" changes...

Good work!!

src/js/tabs/pid_tuning.js

fgiudice98 · 2020-03-09T14:32:15Z

For now the KISS logo is a placeholder text, i will update it in the future, after i have talked with the guys from KISS

Don't know why travis failed building, seems like a travis error

McGiverGim

True, Travis seems to be failing...

For the rest, the code seems good enough to me!

Add rates type selection with working graphs and max angular speed Fix deadband MSP changes and fix actual rates limit Small style changes and fixes Fixes Fixed the code pointed out in the review Various sonar fixes Updated the values of actual rates setting Reduced logo size Added analytics to rates type Minor fix + rounding by step value Now the calculation of the angle rate takes into account the values rounded by the step value (especially visible with values that are in deg/s) Various fixes Angle rate calculation in different functions Fix for value step validation Sonar fixes (mostly variables) Force refresh to prevent errors ... ... when changing rates type after saving to eeprom Logos refinement + minor changes Touch to trigger travis Fix Raceflight rate

mikeller · 2020-03-10T11:56:46Z

Looks mostly good now - there are still a lot of constant expressions left that are defined with let. Is there a reason you are doing this?

fgiudice98 · 2020-03-10T12:52:31Z

@mikeller the let defined variables that sonar recommend to define with const are not changed for now, but in case of new rates types added they could be modified. This is the main reason why i left them as let and not changed to const, i can even insert directly without using variables for now, just seems to me that the code is more easily editable and more readable. If i need to insert directly or define as const i will do the edit no problem, let me know

mikeller · 2020-03-10T13:40:38Z

@fgiudice98: Building code 'for future use' is a fallacy, as it implies that we are any good at predicting the future - unfortunately, the reality in software engineering is that we are not.
Having constant values defined as variables makes the code hard to read as the reader will be forced to scan through the following code to determine if something is reassigned, or if it will stay the same.
It also prevents bugs caused by accidental modification of variables that are expected by code further down to not be changed.
So const is a good way to improve the readability and maintainability.
Please fix these Sonar issues.

sonarcloud · 2020-03-10T14:27:31Z

Kudos, SonarCloud Quality Gate passed!

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

No Coverage information
0.0% Duplication

mikeller · 2020-03-11T00:09:21Z

This is still missing the analytics, but I can add these in a second pull request.

mikeller added this to the 10.7.0 milestone Mar 8, 2020

mikeller added the RN: IMPROVEMENT label Mar 8, 2020

mikeller reviewed Mar 8, 2020

View reviewed changes

McGiverGim requested changes Mar 8, 2020

View reviewed changes

McGiverGim requested changes Mar 9, 2020

View reviewed changes

src/js/tabs/pid_tuning.js Outdated Show resolved Hide resolved

src/js/tabs/pid_tuning.js Outdated Show resolved Hide resolved

McGiverGim previously approved these changes Mar 9, 2020

View reviewed changes

fgiudice98 dismissed McGiverGim’s stale review via dfa1474 March 9, 2020 20:39

McGiverGim previously approved these changes Mar 9, 2020

View reviewed changes

fgiudice98 dismissed McGiverGim’s stale review via 70a8364 March 10, 2020 11:52

Fixed variable declaration

054b1ee

mikeller approved these changes Mar 11, 2020

View reviewed changes

mikeller merged commit 758ce36 into betaflight:master Mar 11, 2020

mikeller added RN: UI and removed RN: IMPROVEMENT labels Apr 26, 2020

nerdCopter mentioned this pull request Aug 20, 2021

MSP 1.51 UI emuflight/EmuConfigurator#389

Merged

Add rates type selection #1909

Add rates type selection #1909

Conversation

fgiudice98 commented Mar 7, 2020 • edited Loading

mikeller commented Mar 7, 2020

mikeller commented Mar 8, 2020

mikeller left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fgiudice98 commented Mar 8, 2020 • edited Loading

mikeller commented Mar 8, 2020

Choose a reason for hiding this comment

ctzsnooze commented Mar 8, 2020 • edited Loading

fgiudice98 commented Mar 8, 2020 • edited Loading

mikeller commented Mar 8, 2020

fgiudice98 commented Mar 8, 2020 • edited Loading

fgiudice98 commented Mar 8, 2020

McGiverGim commented Mar 8, 2020

fgiudice98 commented Mar 8, 2020

mikeller commented Mar 9, 2020

ctzsnooze commented Mar 9, 2020

fgiudice98 commented Mar 9, 2020

asizon commented Mar 9, 2020

TheIsotopes commented Mar 9, 2020

fgiudice98 commented Mar 9, 2020

asizon commented Mar 9, 2020

asizon commented Mar 9, 2020

fgiudice98 commented Mar 9, 2020 • edited Loading

asizon commented Mar 9, 2020

fgiudice98 commented Mar 9, 2020

mikeller commented Mar 9, 2020

fgiudice98 commented Mar 9, 2020

McGiverGim left a comment

Choose a reason for hiding this comment

fgiudice98 commented Mar 9, 2020

McGiverGim left a comment

Choose a reason for hiding this comment

mikeller commented Mar 10, 2020

fgiudice98 commented Mar 10, 2020

mikeller commented Mar 10, 2020

sonarcloud bot commented Mar 10, 2020

mikeller commented Mar 11, 2020

fgiudice98 commented Mar 7, 2020 •

edited

Loading

fgiudice98 commented Mar 8, 2020 •

edited

Loading

ctzsnooze commented Mar 8, 2020 •

edited

Loading

fgiudice98 commented Mar 8, 2020 •

edited

Loading

fgiudice98 commented Mar 8, 2020 •

edited

Loading

fgiudice98 commented Mar 9, 2020 •

edited

Loading