params: add board-level read-only parameter support#26522
params: add board-level read-only parameter support#26522
Conversation
|
No broken links found in changed files. |
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 424 byte (0.02 %)]px4_fmu-v6x [Total VM Diff: 432 byte (0.02 %)]Updated: 2026-02-19T18:05:10 |
hamishwillee
left a comment
hamishwillee
left a comment
There was a problem hiding this comment.
Docs are great, but we really need the read-only field to be injected into parameter metadata so that a GCS doesn't have to try to read it, and doesn't offer the option. Once it is in the metadata I can also read it.
You'd have to update src/lib/parameters/px_generate_params.py to add a new property like the following to generated parameters.
* @read-only True
We can then update the src parser and markdown out exc to generate appropriate XML and markdown.
|
Ah yes, we can add that. |
If you can add to the generated params stuff I can fix up the markdown output. |
Integrators can declare read-only parameters in a per-board YAML file: readonly_params.yaml. There are two ways to define the read-only params: - "block": default writable, explicitly list params to be locked - "allow": default readonly, explicitly list params to be writable Enforcement is activated by `param lock` in rcS after all startup scripts have run, so board defaults and airframe scripts can still set params during init. The feedback via MAVLink uses the new MAV_PARAM_ERROR_READ_ONLY as part of the PARAM_ERROR message.
This adds a readOnly flag for read only parameters to the json and xml.
julianoes
force-pushed
the
pr-readonly-params
branch
from
9dd8094 to
ff4699c
Compare
|
@hamishwillee is this ok? 
QGC PR: mavlink/qgroundcontrol#14007
What do you mean exactly? |
To my mind the QGC change would be that the read only parameters
I can't see what you have done in the background list, and to me an icon or colour change would be much more visually obvious than this text. So yes, this is OK, but would prefer optimal.
I mean for the parameter metadata rendering in docs the readonly information needs to be captured in the parameter source parser. You must have done this though or you wouldn't be able to generate parameters.xml. So what I am saying is that once this merges, I can take on the update to generate the updates to the documentation. Unless you want to do that. |
|
This is so good! |
Yeah, I can try that.
I think it's just ignored. There are no locked parameters for the upstream version, so this really only applies to integrator forks that would use it. |
|
@hamishwillee something like this? 
|
|
@julianoes Yes - that's what I was thinking. Lovely. |
4 participants
Integrators can declare read-only parameters in a per-board YAML file: readonly_params.yaml.
There are two ways to define the read-only params:
Enforcement is activated by
param lockin rcS after all startup scripts have run, so board defaults and airframe scripts can still set params during init.The feedback via MAVLink uses the new
MAV_PARAM_ERROR_READ_ONLY as part of the PARAM_ERROR message.
This also includes an extension to
param show:Closes #12429.
Closes #14493.