Suggestions for improvements to parameters in Plane 4.5

ArduPlane
1

I noticed a comment in the Dev Call minutes from April 3 2023, that * Big parameter changes for 4.5 is going to be the next big thing *.

I have some thoughts and suggestions, and I thought I’d put them out there for discussion.

  1. Remove reference to underlying architecture in parameter names.
    End users of the system should not need to know if a parameter is implemented in AHRS or EKF or TECS or whatever. Object Oriented “Encapsulation” is being compromised by the current parameter naming. Not to mention, it’s very confusing for end users.

Parameters should be named by purpose/function, not implementation.

  1. Provide a “tagging” /grouping mechanism
    When trying to do a particular thing - e.g. setup a plane for auto TKOFF, the parameters to be set are scattered all over the namespaces. Of course some parameters are used for multiple purposes. A way to “tag” parameters by usage would be very helpful to end users.

  2. Standardize abbreviations
    There are so many cases where different abbreviations are used for the same thing. I just came across this one yesterday.
    LAND_FLAP_PERCNT: Landing flap percentage
    TKOFF_FLAP_PCNT: Takeoff flap percentage

  3. Get rid of Centi Degrees/Centimeters
    I think I heard there is discussion about getting rid of centi-degrees. Centimeters vs meters causes the same potential for confusion and error. Please consider removing both.

  4. Fix the numbering of SERVOn, SERIALn, RCn
    These all start with a single digit n, but as soon as n > 9, the sort order for any display of the values is all out of whack. You get SERVO1, SERVO10, SERVO11 … SERVO2 etc. Add at least 1 digit for all of these. Also please include a separator, it is confusing and error prone to have the number hard up against the text, especially when “O” is the last letter in SERVO. (see below).

  5. Change the naming paradigm for inputs and outputs.
    “SERVO” outputs can actually be motors, cameras, VTX … so the name doesn’t suit the purpose.
    There are “special” names for things like CAN ports
    There is a proposal to create “virtual” SERIAL ports for ethernet that are not actually serial at all. IMO doing this will be very unfortunate and we will regret it for years to come.
    How about just use “OUT” or “IO”, or “PORT” for all input/outputs, with a type value to define what the output is for?
    PORT_001
    PORT_001_TYPE = servo
    PORT_001_FUNCTION = ailerons
    …
    PORT_015_TYPE = uart
    PORT_015_FUNCTION = RCIN
    …
    PORT_020_TYPE = tcpip
    PORT_020_FUNCTION = sftp
    …
    … open for discussion

4 Likes
2

percents should be an integer or decimal that is 100 at full scale.

FFT_WINDOW_OLAP is a 0-1 even though description says percent. Perhaps it could be a value of 0-90, with units of percent?

1 Like
3

I agree with the comments put forth - mainly with the need for more conformity amongst the parameters.

When it comes to “grouping” the parameters - I think we let the GCS handle that (alongside XXX_ENABLE parameters). We should push for common setups such as setting up a plane for auto takeoff to be a page/tab in the GCSs (MP, QGC, etc.) - as the ideal scenario (from my point of view) is to minimize the amount of direct parameter searching/modifying needed.

Although - one thing that needs to be figured out is how we ensure the conformity is kept as new parameters/features are integrated in the future as well.

1 Like
4

I also think the inclusion of more XXX_ENABLE parameters would be a good idea. Also using the ENABLE parameter as a non-binary input would be nice as well. For example, RNGNFD_ENABLE could be used to enable a certain amount of rangefinders dependent on the parameter value (1 through 10). Right now when I search for RNGFND, half the screen is full of parameters related to RNGNFD - but most users aren’t implementing more than one or two on common builds.

Another example could be a bitmask for a SERVO_ENABLE parameter that only shows parameters relevant to the servo numbers that are activated (instead of all 32 as shown now).

I don’t know if this is what the XXX_ENABLE parameters were initially drawn up for - but in my case I am basically using them to hide/show different parameters so that the list isn’t so exhaustive on a fresh build.

2 Likes
5

It is a good idea to configure parameters for functions, but it may be a bit difficult for developers because they have too many models to consider.

1 Like
6

Whatever changes happen, PLEASE make it to where the current parameter values automatically migrate from old to new version of firmware, and new parameters/functions are obviously flagged and displayed!
.
nothing like saying to yourself “hmmm, im heading out to the field to fly/try some setups, but i’d like to be sure im on the latest version (for various reasons)”, only to find out the update caused various unknown parameters to be reset to default, require a restoration process, and/or has new parameters that may cause adverse affects on a currently used function when left as the new default.
ideally, one has plenty of time and can do the update with plenty of time to get educated, investigate changes, assure proper operation, etc…but reality isn’t like that all the time. in the words of brad pitt (fury), “ideals are peaceful, but history is violent”.

3 Likes
7

The devs have been really good about this for the past years. You can even update from older 3.6.X versions with automatic parameter migration. It works so well you probably haven’t even noticed!

2 Likes
8

Can we also standardize the use of ARSPD and ARSP abbreviations?

1 Like
9

Lots of good suggestions here! I like the idea of revamping things to use consistent naming conventions for sure.

Also, use of “enable” bitmasks to hide unused parameters and peripherals from view and provide a “grouping” mechanism seems like a step in the right direction.

1 Like
10

What about all the numbered params from when there was only one originally but now N.
GPS_TYPE and GPS_TYPE2 change to GPS_TYPE1 and GPS_TYPE2
BATT_MONITOR and BATT2_MONITOR to BATT1_MONITOR and BATT2_MONITOR

1 Like
11

IMHO it should be [subject identifier] [number] [parameter name] as it makes configuring each device easier for example

BAT1_VOLT_SCALE
BAT1_AMP_SCALE
…
SRV01_PWM_TRIM
SRV01_PWM_MAX

For devices where there are more than 10 we should include leading 0 to keep 1x pooping up when looking for 1.

1 Like
12

To further simplify this - I think we should always add leading 0s. Even if there are no current plans to have more than 09 of the series.

2 Likes
13

Adding a leading 0 when it is highly unlikely to be needed wastes a character that can be used to have more descriptive parameter name.

14

Not adding a leading zero always leads to problems when listing or searching. e.g right now:
RC1
RC10, RC11, RC12… RC16
RC2

So to get to RC2 you have to start at 1, then 10, 11… then back to 2. It’s awkward, confusing and error prone.

In addition, having a fixed number of digits makes parsing and processing the numbers by scripts, or other code or programs much easier.

2 Likes
15

Yes - but its a bit confusing if some parameters use a leading 0 while others would not. Especially if a series could be expanded in the future. I am pretty sure most series have support for more than 9 at this point (if not they probably will in the future) - so why not just stick to a consistent series that will work for all series.

See my previous comment about XXX_ENABLE parameters that will help out with this issue as well. Using a bitmask to only show series numbers that are in use.

16

I’m agreeing with you!

17

Yes I know - I was replying directly to Lupus :joy:

18

There’s no way anyone would ever have 9 airspeed sensors…

1 Like
19

Maybe the same person running more than 9 battery monitors…

1 Like
20

Never say never! I’ve been doing this for 40 years and seen it happen so many times that someone says “oh we will NEVER need more than x of those” - and then it turns out that it is just shortsighted. Whatever number you think is way more than enough will get hit, and likely way sooner than you ever thought was the worst case.

1 Like