Param reset excludes

[LorenzMeier]

@AndreasAntener As I have no push-fu on UAVenture I've pushed the branch with fixed compilation here.

[AndreasAntener]

Thanks! Ah, that's were this should have been fixed :)

[AndreasAntener]

@LorenzMeier how about something like that?
I talked to @thomasgubler about abstracting the whole parameter stuff last week, once this is done the testing should be easier. But I guess this is not priority 1 so the directive might be an option?

[thomasgubler]

@AndreasAntener I guess the exclusion should work also below/without the abstraction layer

[AndreasAntener]

@thomasgubler Yes of course. It's just about being able to do unit-tests.

[bansiesta]

This is awesome! Don't you want to exclude SENS* as well?

[AndreasAntener]

@bansiesta We discussed part of this, the problem is that if you use autoconf because you really switched the airframes, it makes sense to do the calibration again. Although I'm not sure if it would be necessary for all sensors?

[LorenzMeier]

Developers can avoid the reset, and users really don't want or need this. Changing the airframe changes so many things. Even the RC config is not obvious that it stays the same.
The params are part of the flight setup the same way the code is, and so avoiding stale configs has to be our primary priority.

[bansiesta]

I saw your arguments, and I disagree because it is a hassle to recalibrate all sensors. I think users should be advised to recalibrate the mag and accel whenever they completely switch airframes but not when they go from e.g. a F330 to a F450.

[LorenzMeier]

I'm sorry, but the argument still makes no sense to me. The static mag offset depends on nearby components and the F330 and F450 frames for sure have soft iron in proximity of the autopilot, and there is no indication that two different setups (with different payload / components) should have the exact same soft iron offsets. Why should we skip the calibration then?

To me this is really developer feature creep, and you're arguing about the GUI setup method. It would be trivial to store whatever parameters you like to keep in a param file via QGC and re-apply after you've switched frames. But doing this safely without introducing e.g. toilet-bowling requires a lot of contextual knowledge and great care in the physical airframe layout, which the average user certainly doesn't have. Still, its trivial for developers to do, and so I don't see why we should put the flight performance for average Joe at risk when you can simply load a param file after reconfiguring.

The RC config is the only aspect which is more or less stable between airframes. I can see that this is the one piece that is most stable after a frame switch, and I think it makes some sense to retain it.

[LorenzMeier]

That said, it might make sense for QGC to warn about the impending reset and offering to store a file with the current parameters. We also could think about storing multiple files (e.g. all, sensor config, RC config) so users don't have to edit the text files manually to get individual groups of params.

[LorenzMeier]

Rebased on master - is this good to merge?

[AndreasAntener]

Not yet. The param exclude in systemlib works but I haven't tested the change to the systemcmd yet.

[bansiesta]

@LorenzMeier I like the idea about a warning in QGC.
And I see why you'd have to recalibrate the mag but not the gyro and (usually) neither the accel.

I guess I see the SYS_AUTOCONFIG param more like a "apply the default params for that airframe" instead of a "start from scratch".

[LorenzMeier]

I guess I see the SYS_AUTOCONFIG param more like a "apply the default params for that airframe" instead of a "start from scratch".

Which would mean that you would need to unroll your previous airframe-specific changes back to the defaults before you can configure the defaults for another frame. I'm sorry, but it really doesn't work in practice like that. There is no other approach than to reset to default. The alternative would be to set each and every parameter for a specific frame, but I hope we can agree that this would lead to massive bit-rot of configurations. Right now unchanged params track the defaults in the code, so if you change the default value in code to a better value, all configs which want the default auto-update.

Also, the accel calibration does account for misalignment of frame and autopilot mounting in e.g. a plane when used correctly. Its not really static either, in particular if you did calibrate the previous frame with the autopilot mounted.

All the "static" config arguments you make need a lot of contextual knowledge and a bunch of assumptions to hold - only very experienced developers will ever get those right, and I have described above how to work as experienced developer with or without the GUI 😈

[AndreasAntener]

Tested, systemcmd works, SYS_AUTOCONFIG resets everything but RC*.

[bansiesta]

@LorenzMeier: yes good point about the default params, I give up :)

[LorenzMeier]

Merged via rebase, thanks!