Please offer compatibility with classic .params files, and ability to SAVE as classic file by default

[AndKe]

Feature Description

the QGC format for .params is not compatible with other GCS's , and hard to compare(diff) readability is not helped by lines like this:

1 1 ATC_RAT_YAW_FLTD 0.000000000000000000 9 1 1 ATC_RAT_YAW_FLTE 1.000000000000000000 9 1 1 ATC_RAT_YAW_FLTT 20.000000000000000000 9 1 1 ATC_RAT_YAW_I 0.091200001537799835 9 1 1 ATC_RAT_YAW_IMAX 0.500000000000000000 9 1 1 ATC_RAT_YAW_P 0.912000000476837158 9 1 1 AUTO_OPTIONS 0 6

This many decimals is .. not needed and just bad for comparing/diff/version tracking for exaxmple is clearly set to be: ATC_RAT_YAW_I 0.0912

Flight Stacks

ArduPilot, PX4

Vehicle Types

Multirotor, Fixed-wing, VTOL, Submarine

[DonLakeFlyer]

So this was changed 9 years ago: https://github.com/mavlink/qgroundcontrol/issues/2951. The rational behind it which is to save in the file the actual value with full precision I think still makes sense.

[AndKe]

The full precision is an illusion :) - as you see/know that the last digits were not actually entered, so in most cases the later decimals is just an error caused by the binary approximation due to limited mantissa bits of the fraction. If we had actual interest in precision that far out we would store the values as decimal.Decimal - so I do understand the idea of storing "everything" - but there are no parameters that I can think of where this is useful.

There are additional reasons for supporting the classic .param (regardless of number of digits):

APMPlanner 2 and mavproxy can compare .param with actual settings / this is useful for configuration check, or copying parts of the configuration between vehicles, or checking configuration against earlier "known good" state.

• for that one needs to have a compatible format. It would be nice is QGC was one of the tools that could at least export to such file - and preferably read such files.

The simpler .param format is also the one "universal" format across GCS software. It is odd that QGC is the only GCS that is not compatible with it. :)

[DonLakeFlyer]

I thought it was just decimal places were the problem. Not sure where QGC's param format differs. Can you detail?

Also FYI: QGC 5.0 supports showing you the diff between vehicle and param files when you load and allows you to selectively include/exclude.

[AndKe]

MAVProxy format: (space(es) at delimiter LF at the EOL)

ACRO_BAL_PITCH   1.000000
ACRO_BAL_ROLL    1.000000
ACRO_OPTIONS     0
ACRO_RP_EXPO     0.300000
ACRO_RP_RATE     360.000000
ACRO_RP_RATE_TC  0.000000

APMPlanner2: #=comment , comma as delimiter, CRLF at the EOL

#NOTE: 2/12/2025 1:23:1 P.M.: be4upgrade
ACRO_BAL_PITCH,1.00000000
ACRO_BAL_ROLL,1.00000000
ACRO_OPTIONS,0
ACRO_RP_EXPO,0.30000001
ACRO_RP_RATE,360.00000000

MissionPlanner also uses comma, and only LF at the EOL (please note how it trims/rounds the values)

ATC_RAT_PIT_D,0.0036
ATC_RAT_PIT_D_FF,0
ATC_RAT_PIT_FF,0
ATC_RAT_PIT_FLTD,20
ATC_RAT_PIT_FLTE,0
ATC_RAT_PIT_FLTT,20
ATC_RAT_PIT_I,0.135
ATC_RAT_PIT_IMAX,0.5
ATC_RAT_PIT_NEF,0
ATC_RAT_PIT_NTF,0
ATC_RAT_PIT_P,0.135
ATC_RAT_PIT_PDMX,0
ATC_RAT_PIT_SMAX,0

Summary: the format is simple: PARAM_NAME then VALUE Ignore or display comments (lines starting with "#") delimiter is "," or SPACE(es) EOL is LF or CRLF

Now that you mention that QGC also does compare/selective loading - I remember to have seen it before. (and I LOVE it) :)
And this leads me directly to:

Please consider changing the wording - it sounds ... dangerous and final :) "Load,Compare,select" or "Compare and load" , "compare with file" - "load chosen parameters" or something like that would clearly indicate that there is no risk of suddenly overwriting the whole config.

Also:

If you for example want to copy PID's /tuning parameters from a similar machine, not RC calibration and servo min/max - then you will find that a "toggle all" button would be very useful as unchecking some hundreds of params is no fun :)

[DonLakeFlyer]

So I've been looking at the QGC format, which is: Vehicle id, componentId, paramName, value, type. It's been this way over 10 years, predates any of my work. That said there are advantages to this format:

• QGC save all parameters including params from vehicle components and could load them back into components
• Having the vehicle id allows you to warn about loading a file from the wrong vehicle

Adding the ability to save in the MP format makes sense, but I don't see that as the default since it would be a loss of functionality with respect to saving component parameters.

Also a bit too late in the game for 5.0, but I"ll tag most of this as 5.1. I will change the "Load File" wording to be more clear.

[AndKe]

Having the vehicle id allows you to warn about loading a file from the wrong vehicle

I'd say that is mainly covered by when I load(compare) and see lots of differences - then I know something is off if the intention was to load a previous config for the same vehicle. Also: most use the same SYSID - so that is far from foolproof - unless in swarms, exactly where you would cross-import config When speaking about comparing/importing - if you would add a button for "hide dynamic parameters" - and the logic for that then I would provide you with all the params I filter for in my tools (there are lots or read-only and dynamic parameters that are only cluttering comparisons, and not useful to import.)

I appreciate that you are willing to add .param as an option, please disregard my idea of making it default, as long as we have .param and .params to choose from, which is default is of no importance.

Thank you - keep up the great work.

[DonLakeFlyer]

@AndKe And thank you for always reporting problems and helping to make QGC better for so long now.