feat(params): add board-level read-only parameter support#26522
feat(params): add board-level read-only parameter support#26522
Conversation
|
No broken links found in changed files. |
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 416 byte (0.02 %)]px4_fmu-v6x [Total VM Diff: 416 byte (0.02 %)]Updated: 2026-04-08T18:51:26 |
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. |
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. |
|
Whats missing here? it would be nice to get this merged, cool feature |
|
The one thing I should check is how/if this conflicts with ArduPilot, mostly concerning the QGC side. I wasn't aware of the fact that they already have it, or something like it. |
|
Did we get the QGC side figured out? I think this is a great feature and would love to get it in. |
|
Looking into what is going on now. |
ff4699c to
50d2442
Compare
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.
50d2442 to
ccb86d1
Compare
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 416 byte (0.02 %)]px4_fmu-v6x [Total VM Diff: 416 byte (0.02 %)]Updated: 2026-04-14T22:24:55 |
|
No broken links found in changed files. |
hamishwillee
left a comment
There was a problem hiding this comment.
Approving for the docs part. The mavlink bits look good too, but I haven't tested.


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.