rcS: add airframe parameter versioning and extend SYS_AUTOCONFIG

[bkueng]

It is currently not easy for downstream adopters to update airframe parameters, while still allowing for some other customizations.
This PR provides a minimal solution for that, by adding an (optional) airframe parameter versioning variable, that is compared against SYS_PARAM_VER. Airframe defaults are reloaded if they don't match.
While this has limitations, it has proven to be useful and effective in practice.
Ideally on an update we could show a param diff to the user, and let him/her decide which values to use.

To use it for an airframe, add set PARAM_DEFAULTS_VER 2 to the airframe config, and whenever one of the parameters change, also increase that number.

This reuses SYS_PARAM_VER, which is currently unused (in QGC as well).

[dagar]

I'm fine with this solution if we treat airframe and vehicle type defaults appropriately.

For example we'd need to stop setting parameters like this that are perhaps good starting values for most multicopters, but certainly not safe to reset if changed by a user. https://github.com/PX4/Firmware/blob/0b548fa6849e7a608b4c120fb66a760e51806056/ROMFS/px4fmu_common/init.d/rc.mc_defaults#L18-L20

[dagar]

TODO: review vehicle defaults

• FW https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.fw_defaults
• MC https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.mc_defaults
  • default min 1075, max 1950 are ESC specific
  • default PWM_RATE is already 400 Hz
• UGV https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.ugv_defaults
• VTOL https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.vtol_defaults
  • controller tuning should be moved to specific airframes

[bkueng]

For example we'd need to stop setting parameters like this that are perhaps good starting values for most multicopters, but certainly not safe to reset if changed by a user.

The use-case is a bit different for these: they are not meant to be changed by a user, since it's a fixed & finished airframe. Like the teal one for example. It also overrides these in its own airframe config.

For others like RTL parameters, I agree, they should not be there.

[dagar]

For example we'd need to stop setting parameters like this that are perhaps good starting values for most multicopters, but certainly not safe to reset if changed by a user.

The use-case is a bit different for these: they are not meant to be changed by a user, since it's a fixed & finished airframe. Like the teal one for example. It also overrides these in its own airframe config.

For others like RTL parameters, I agree, they should not be there.

Ok that's fine, I thought it was going to be an overall version number we could increment, but I see the intended usage now.

Ultimately we still need a solution for handling upgrades on generic setups.