Hi!
If I build make parameters_metadata for, say, PX4 v1.13.3, the output file build/px4_sitl_default/docs/parameters.xml does not seem to contain all parameters. In particular, serial port config params defined in various driver’s module.yaml files don’t seem to show up. For instance GPS_1_CONFIG. However, it does show up in the markdown file (docs/parameters.md).
I want to make sure these parameters, and other parameters I’ve added in my custom PX4 build, show up in QGC. Am I doing something wrong?
(I’ve asked roughly the same question on the DroneCode Discord previously.)
Hmm weird, is it the same even when you generate in the main branch, instead of v1.13 release?
I tested this now, and yes, on main (95b3005679) I’m getting the same result. After make parameters_metadata, I can see e.g. GPS_1_CONFIG in build/px4_sitl_default/docs/parameters.md, but not in the generated XML file (or JSON for that matter).
However, if I build for a hardware target, say make px4_fmu-v5, then I do get GPS_1_CONFIG and seemingly all the others in the parameter metadata files that are generated to build/px4_fmu-v5_default. Both in the XML and the JSON.
Ahh then it must be because in SITL we don’t use that parameter, as we don’t really have the concept of GPS instances, and thus it is getting eliminated automatically from the build.
And for hardware targets, yes you would get those parameters, since they are mapped in the board configuration file .px4board, as I briefly mentioned in this post: Confusion on which USART ports are connected to which TELEM ports
Hope that clarifies things!
Thank you, yeah, that seems to be the case. But if I want to generate parameter metadata for QGC, is it possible to generate metadata that includes all parameters across the entire PX4 firmware, all targets and SITL? I had the impressian that that was what parameters_metadata was meant to do. Otherwise I’d need separate QGC builds for each vehicle and for simulation.
A workaround could be for me to build parameter metadata for SITL and the boards I use, and merge them before updating QGC.
Component Metadata Protocol
The parameter metadata is intended to be different for different flight controllers / builds. And that is why there is a Component Metadata protocol in MAVLink, to fetch parameter metadata (the .json file you generated, but compressed to be smaller size) from the flight controller to QGC side.
https://mavlink.io/en/services/component_information.html
Metadata for different targets
This is as far as I know already the case for simulated targets, and depending on the flight controller you use, this feature may be excluded if it doesn’t have enough flash memory to store the metadata.
Therefore, unless you notice that certain parameter definitions are missing / out of sync in QGC (will only happen to boards that doesn’t have parameter metadata in the flash), you don’t need to worry about having a single .xml file to keep track of all parameters.
Aha! That’s very interesting. I see that MAVLink considers this feature to be work in progress. Do you know which versions of QGC and PX4 support the component metadata protocol?
