4.5 parameter rename tracking list

[Hwurzburg]

As we are considering renaming many params in 4.5, I thought I would start a tracking list:

• [ ] LIM_ROLL_CD, LIM_PITCH_CD
• [ ] DSPOILR/DSPOILER
• [ ] STAB_PITCH_DOWN_CD
• [ ] TRIM_PITCH_CD
• [ ] LAND_PITCH_CD
• [ ] Consolidate LAND and TECS_LAND params
• [ ] ARSPD/ARSP

feel free to add to the list

[tridge]

i planned on creating the list by finding all params with units of cm, cm/s, cd and cd/s to start with

[tridge]

a --units option to param_parse.py to produce docs only for the listed unit types would be a big help

[tridge]

we also need methods like: param_convert_cm(my_param) to auto-convert

[IamPete1]

I would like to do the COMPASS -> MAG as part of the compass move to AP_Vehicle.

THR_FAILSAFE on plane to RC_FAILSAFE

[timtuxworth]

Percent vs Pcnt vs PERCNT - how about no abbreviation? Does it add value? LAND_FLAP_PERCNT: Landing flap percentage TKOFF_FLAP_PCNT: Takeoff flap percentage FLAP_1_PERCNT: Flap 1 percentage FLAP_2_PERCNT: Flap 2 percentage ARSPD_OFF_PCNT: Maximum offset cal speed error

[timtuxworth]

Use a fixed number of digits for SERVO and RC numbering and put in a separator to make parsing easier. Fixes the current UI issue where the servo numbers in lists like the full parameter list or search results are out of order. SERVO_01, SERVO_02 ... or even SERVO_001, SERVO_002. RC_001, RC_002 ...

Somewhat a separate item, but SERVO defines outputs from the board that may or may not be servos. They could be VTX power, relays etc. So how about instead of using SERVO, use "OUT" - only 3 characters and more generic than SERVO - so

OUT_001, OUT_001 ...

[timtuxworth]

• [ ] Consolidate LAND and TECS_LAND params

As per my notes here ( https://discuss.ardupilot.org/t/suggestions-for-improvements-to-parameters-in-plane-4-4/99165/2 ), consider removing TECS from all the TECS parameters. It adds zero value to end users and only causes confusion to have TECS in the parameter name.

[timtuxworth]

standardize various spellings of "pitch" - ideally no abbreviation as PTCH only saves one character, so PITCH is good, but if it really has to be abbreviated use "PIT" and make it worthwhile by saving 2 characters. STAB_PITCH_DOWN: Low throttle pitch down trim LIM_PITCH_MAX: Maximum Pitch Angle LIM_PITCH_MIN: Minimum Pitch Angle MAN_EXPO_PITCH: Manual input expo for pitch CUST_ROT1_PITCH: Custom pitch CUST_ROT2_PITCH: Custom pitch TKOFF_LVL_PITCH: Takeoff mode altitude initial pitch TKOFF_GND_PITCH: Takeoff run pitch demand ACRO_PITCH_RATE: ACRO mode pitch rate TRIM_PITCH_CD: Pitch angle offset LAND_PITCH_CD: Landing Pitch MNT1_PITCH_MIN: Mount Pitch angle minimum MNT1_PITCH_MAX: Mount Pitch angle maximum MNT2_PITCH_MIN: Mount Pitch angle minimum MNT2_PITCH_MAX: Mount Pitch angle maximum MNT2_LEAD_PTCH: Mount Pitch stabilization lead time OSD[12345]_PITCH_EN: PITCH_EN OSD[12345]_PITCH_X: PITCH_X OSD[11235]_PITCH_Y: PITCH_Y Q_TRIM_PITCH: Quadplane AHRS trim pitch TECS_PITCH_MAX: Maximum pitch in auto flight TECS_PITCH_MIN: Minimum pitch in auto flight STAB_PITCH_DOWN: Low throttle pitch down trim KFF_THR2PTCH: Throttle to Pitch Mix PTCH2SRV_TCONST: Pitch Time Constant PTCH2SRV_RMAX_UP: Pitch up max rate PTCH2SRV_RMAX_DN: Pitch down max rate PTCH2SRV_RLL: Roll compensation PTCH_RATE_P: Pitch axis rate controller P gain PTCH_RATE_I: Pitch axis rate controller I gain PTCH_RATE_IMAX: Pitch axis rate controller I gain maximum PTCH_RATE_D: Pitch axis rate controller D gain PTCH_RATE_FF: Pitch axis rate controller feed forward PTCH_RATE_FLTT: Pitch axis rate controller target frequency in Hz PTCH_RATE_FLTE: Pitch axis rate controller error frequency in Hz PTCH_RATE_FLTD: Pitch axis rate controller derivative frequency in Hz PTCH_RATE_SMAX: Pitch slew rate limit

[timtuxworth]

OPTION vs OPTIONS vs OPTS vs OPT mostly we use _OPTIONS but there is CAN_Dn_UC_OPTION and DSPOILER_OPTS and SCR_DEBUG_OPTS and INS_HNTCn_OPTS and INS_LOG_BAT_OPT oh and RCn_OPTION

[amilcarlucas]

@timtuxworth I'm sure there is a limit on how long the parameter names can be. That is the reason for mixing non abreviations and abreviations, to keep the parameter length under a limit.

[IamPete1]

Params are a max of 16 characters. Its baked into MAVLink ect, we could increase but it would be quite a big job.

[timtuxworth]

@timtuxworth I'm sure there is a limit on how long the parameter names can be. That is the reason for mixing non abreviations and abreviations, to keep the parameter length under a limit.

It would be far better to choose a standard abbreviation and use it consistently in all cases.

[timtuxworth]

Inconsistent use of ROLL and RLL. I'd vote for ROLL but consistency is so important that I'd say RLL in all cases if the alternative was to have a mix of ROLL and RLL. (but seriously - one character?)

[timtuxworth]

Use of THROTTLE, THR and TH for throttle. IMO standardizing on THR would provide the best balance of meaning, #characters and consistency.

[timtuxworth]

Params are a max of 16 characters. Its baked into MAVLink ect, we could increase but it would be quite a big job.

Perhaps it's worth having this conversation. Once upon a time file names were limited to 14 characters on Unix and 8+3 characters on windows, industry experience is that increasing or removing these limits has always worked out well. Perhaps not for this exercise I guess, but if it's a long process it might be a good idea to start it sooner than later. 256 or 1024 would be a far more useful limit.

[andyp1per]

@timtuxworth I'm sure there is a limit on how long the parameter names can be. That is the reason for mixing non abreviations and abreviations, to keep the parameter length under a limit.

Then it would be better to choose a standard abbreviation and use it consistently in all cases.

Disagree. The abbreviations are forced on us by the character limit. If we follow this logic then all motor parameters should just be M_ since that is what quadplane does - but I think we can agree that this would be a retrograde step :)

[timtuxworth]

TECS_LAND_SPDWGT vs TECS_SPDWEIGHT - should at least be consistent, but it's actually Speed vs Pitch weighting. Also "SPD" is wrong because it's airspeed so should be ARSPD. IMO having TECS at the front adds no value, so how about: PITCH_ARSPD_WGT LAND_PITCH_ARSPD_WGT I'm suggesting this way around because there are a number of other "pitch" parameters and this will get PTCH_ARSPD_WGT to display with them, but the same argument could be made about airspeed (hence my suggestion about a grouping or tagging mechanism). ARSPD_PITCH_WGT LAND_ARSPD_PITCH_WGT

[timtuxworth]

@timtuxworth I'm sure there is a limit on how long the parameter names can be. That is the reason for mixing non abreviations and abreviations, to keep the parameter length under a limit.

Then it would be better to choose a standard abbreviation and use it consistently in all cases.

Disagree. The abbreviations are forced on us by the character limit. If we follow this logic then all motor parameters should just be M_ since that is what quadplane does - but I think we can agree that this would be a retrograde step :)

So fix the core problem (as per my comment above). Your suggestion is just layering one bandaid on another.

[timtuxworth]

Oh here's a good one, some parameters that use centidegrees that don't even have _CD in the name!!! LIM_PITCH_MIN LIM_PITCH_MAX FLOW_ORIENT_YAW Q_ANGLE_MAX Q_A_SLEW_YAW STEER2SRV_IMAX STEER2SRV_DRTMIN

[amilcarlucas]

The units are in the extra metadata of the parameters, so having units in the parameter name is both duplication and redundant.

[timtuxworth]

The units are in the extra metadata of the parameters, so having units in the parameter name is both duplication and redundant.

I understood one of the goals of this exercise was to eliminate the use of centidegrees (and centimeters) - was I wrong about that?

I'm suggesting all these as candidates to be converted to degrees.

[timtuxworth]

Parameters that use centimeters (to be converted to meters): ALT_HOLD_RTL: RTL altitude (cm) ALT_HOLD_FBWCM: Minimum altitude for FBWB mode (cm) Q_VELZ_MAX: Pilot maximum vertical speed up (cm/s) Q_VELZ_MAX_DN: Pilot maximum vertical speed down (cm/s) Q_ACCEL_Z: Pilot vertical acceleration (cm/s) Q_LAND_SPEED: Land speed (cm/s) Q_LOIT_SPEED: Loiter Horizontal Maximum Speed (cm/s) Q_LOIT_ACC_MAX: Loiter maximum correction acceleration (cm/s/s) Q_LOIT_BRK_ACCEL: Loiter braking acceleration (cm/s/s) Q_LOIT_BRK_JERK: Loiter braking jerk (cm/s/s/s) Q_P_VELXY_IMAX: Velocity (horizontal) integrator maximum (cm/s/s) Q_WP_SPEED: Waypoint Horizontal Speed Target (cm/s) Q_WP_RADIUS: Waypoint Radius (cm) Q_WP_SPEED_UP: Waypoint Climb Speed Target (cm/s) Q_WP_SPEED_DN: Waypoint Descent Speed Target (cm/s) Q_WP_ACCEL: Waypoint Acceleration (cm/s/s) Q_WP_ACCEL_Z: Waypoint Vertical Acceleration (cm/s/s) Q_WP_ACCEL_C: Waypoint Cornering Acceleration (cm/s/s) SIM_PLD_HEIGHT: Precland device center's height above sealeve (cm) TRIM_ARSPD_CM: Target airspeed (cm) MIN_GNDSPD_CM: Minimum ground speed

These rangefinder options might arguablely be left in cm (but should be renamed to remove the _CM) RNGFNDn_OFFSET: rangefinder offset (Offset added to distance in centimeters for PWM lidars) RNGFNDn_MIN_CM: Rangefinder minimum distance (cm) RNGFNDn_MAX_CM: Rangefinder maximum distance (cm) RNGFNDn_GNDCLEAR: Distance (in cm) from the range finder to the ground

[timtuxworth]

TECS_FLARE_HGT and LAND_FLARE_ALT, not only the confusion between using "HGT" and "ALT" for basically the same thing (height above ground), but also these two parameters seem to be doing similar things.

There are a large number of parameters that use HGT for "height above ground" - but also many "ALT" parameters. Does this make sense? Should it not just be ALT all the way down?

[Hwurzburg]

TECS_FLARE_HGT and LAND_FLARE_ALT, not only the confusion between using "HGT" and "ALT" for basically the same thing (height above ground), but also these two parameters seem to be doing similar things.

There are a large number of parameters that use HGT for "height above ground" - but also many "ALT" parameters. Does this make sense? Should it not just be ALT all the way down?

they are different parms and control different parts of the flare

[timtuxworth]

BATT_VLT_OFFSET (whereas all other BATT_VOLT parameters are not abbreviated)

[Hwurzburg]

BATT_VLT_OFFSET (whereas all other BATT_VOLT parameters are not abbreviated)

16 char limit....BATT2_VLT_OFFSET....

[timtuxworth]

BATT_VLT_OFFSET (whereas all other BATT_VOLT parameters are not abbreviated)

16 char limit....BATT2_VLT_OFFSET....

Best practice when abbreviating is to drop characters from the right (least significant first). This would be better to do by abbreviating "OFFSET" so that VOLT can be consistent. Good options are probably:

BATT_VOLT_OFFST or BATT_VOLT_OFS (seems to be commonly used)

If we do this BATT[0-9]*_VOLT* will match all relevant values, and be much easier for users searching to find all the values they are looking for.

[timtuxworth]

I'm not sure if this belongs here, but it just threw me off on a new build. All the RC channel functions are set by RCx_OPTION except 2 special cases RCMAP_ROLL and RCMAP_PITCH. I'm guessing this is historical, but is this time to fix this? Could the Roll and Yaw channel not just be set using RCx_OPTION (x = 1 and 4 by default) just like any other channel?

[Hwurzburg]

@timtuxworth not true...and RCMAP(ie axis inputs) are not ANY RCx_OPTIONS at this time.. but 201=Roll 202=Pitch 203=Throttle 204=Yaw are reserved in the code...eventually the RCMAP function will be removed and those options activated and used..

[timtuxworth]

@timtuxworth not true...and RCMAP(ie axis inputs) are not ANY RCx_OPTIONS at this time.. but 201=Roll 202=Pitch 203=Throttle 204=Yaw are reserved in the code...eventually the RCMAP function will be removed and those options activated and used..

Yes I know - that's my point. I'm saying maybe its time to implement 201=Roll 202=Pitch 203=Throttle 204=Yaw and drop RCMAP_ROLL, RCMAP_PITCH, RCMAP_THROTTLE and RCMAP_YAW.

I think FLIGHTMODE_CH falls in the same category - should be an RCx_OPTION, it's confusing (for newcomers at least), to have these special cases, everything uses RCx_OPTION ... oh except for this.

[tridge]

for airspeed I want:

• AIRSPEED_CRUISE
• AIRSPEED_MIN
• AIRSPEED_MAX

for TRIM_PITCH_CD I want TRIM_PITCH_DEG