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
Can we also standardize the use of ARSPD and ARSP abbreviations?
1 Like
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
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
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
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
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.
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
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.
I’m agreeing with you!
Yes I know - I was replying directly to Lupus 
There’s no way anyone would ever have 9 airspeed sensors…
1 Like
Maybe the same person running more than 9 battery monitors…
1 Like
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
Found another one today.
DSPOILR and DSPOILER prefix. Seems some devs are at least in favor of dropping the E, since we can’t add it every where.
1 Like
Yes it seems like there is class of “user” parameters and another class of “back end” or “system” parameters that users would rarely if ever change (e.g. EKF). In most cases these are very separate (TECS and maybe AHRS seem to belong to both classes).
In an ideal case you never have to go into the full parameter list/tree for a basic aircraft and all the main “user” parameters are tied to a GUI in MP or QGC - but idk if that will ever happen.
1 Like
Also - given that this ties somewhat closely to GCS UI, I am going to link the open discussion for MP recommendations going on here: MP UI Open Discussion
We are getting close to 4.5 testing (i think 4.4 is pretty close to final release) - so I was wondering what the best way of collecting info for the devs would be. Continue posting on this forum post?
Also - I don’t know how the decision is made about jumping from 4.X to 5, but this seems like a pretty major change where jumping to 5 makes sense.
There is an issue in GitHub. A lot of suggestions have been included there. 4.5 parameter rename tracking list · Issue #23580 · ArduPilot/ardupilot · GitHub
1 Like