Open sanderux opened 5 years ago
A system wide "parameter lock" (excluding volatile perhaps) or would it be better to explicitly lock a subset?
I’ve used other systems in the past that had a global “configuration lock” feature. Any config/parameter changes at all, even things such as adjusting lost Comms timeout, required unlocking the config with an appropriate pop-up warning in the UI. Configuration lock defaults to ON every boot. Global configuration lock like this works fairly well for those that want that sort of thing.
I suppose we could do this quickly with a special parameter, but I think overall it would make more sense completely outside. Starting with something simple like param lock
and param unlock
on the command line plus mavlink command(s) to do the same and report locked status.
It also makes me wonder about additional levels of integrity check we could put in place, but I'll leave that for another issue.
I would propose a multiple choice option:
For our use case we would only need lock-reset as we allow our users to make changes, but find they assume a reset would be a good place to start and this is costing us a lot of time.
As discussed in the dev call: mavlink param to disable mavlink param reset
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.
I would like to add @james-modalai 's comment on this from discord as well:
Comment: So right now there is a 'volatile' flag that removes parameters from being included in the checksum. I think we need more flag or categories: Volatile, Calibration, Hardware-specific configuration, Flight Behavior-specific configuration.
For example, right now the QGC 'reset all to defaults' would be nice for me to go back to a starting point in my tune, but I don't want it to wipe my IMU, mag, and RC Radio Calibration.
I would also like to be able to save a param dump from QGC but not include all the calibration params since sharing these with someone else for them to try my tune would wipe their calibration.
I try to do something similar with our repo of PX4 params. I have a script to clean out all the Calibration stuff from a QGC param dump. And I keep subsets of param files full of comments sorted such that some param files set certain behaviors such as indoor/outdoor EKF2 settings. Or files specific to the PID tuning of one airframe.
https://gitlab.com/voxl-public/flight-core-px4/px4-parameters
So it seems that what we need is a better 'classification' of parameters, and they would each have a different param reset characteristics / be export-able in groups (e.g. export only Sensor / RC calibration / Mission / etc).
This in turn would enable better grouping of parameters in the QGC Parameter tab as well, as we would have a better 'structure' of parameters.
Which would in turn ultimately enable grouping of Multicopter Position Control / Attitud Control / etc together (although not directly related to James' comment). And in general better parameter handling.
@dagar any progress / plan / though on this? I would like to help implement :thinking:
Also @Igor-Misic since you have been doing parameter related things, I would like to get your feedback as well :wink:
@dagar here, as we discussed this again in the after-dev-call today!
This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:
https://discuss.px4.io/t/how-to-keep-rc-and-sensor-calibration-parameters-during-param-reset/33799/1
Several times we encountered clients that have, for whatever reason, reset their params to default from QGC. This makes them lose key configuration options such as mapping parameters (different models use different params), and some calibration parameters such as current/voltage sensor.
It would be nice to have a parameter disabling this functionality. Ideas? @RomanBapst @dagar
If agreed i can implement