ardupilot/Tools/autotest/param_metadata/emit.py

"""
 The standard interface emitters must implement
"""

import re


class Emit:
    def __init__(self):
        pass

    prog_values_field = re.compile(r"-?\d*\.?\d+: ?[\w ]+,?")

    def close(self):
        pass

    def start_libraries(self):
        pass

    def emit(self, g):
        pass

    def should_emit_field(self, param, field):
        return field not in ['Legacy']
Tools: update python coding style Tools: update PrintVersion.py coding style autotest: update python coding style pysim: update python coding style jsb_sim: update Python coding style param_metadata: update Python coding style 2016-07-31 07:22:06 -03:00			`"""`
			`The standard interface emitters must implement`
			`"""`
Docs: Add XML emit to param_parse.py. See below for more details... I've refactored the param_parse tool to use various 'emitters'. An emitter can take parameter info and output it in a particular format. Currently the only supported emitters are the wiki and XML formats. The goal of these changes is to create a standard machine readable description of parameters - mainly for use by ground control stations, but it will also enable spiffy scripting environments where code can refer symbolically to vehicle parameters (reflectionish). Open issue: Is there any sort of Ardupilot build id which can be included in the generated XML? That would ensure that we select the correct paramdefs for the load on the target (possibly by asking the target for a SHA or somesuch). If that issue is resolved, then the filename for the XML file should probably be something like: arduplane-ca5742ac.pdef.xml. It is worth noting that I've proposed a suffix of ".pdef.xml" for these file types. This facilitates automated file handling on Android devices. On Android you can register 'handlers' for particular file extensions and if the user tries to open that extension in email or a web browser your app will be given a chance to do something about it. The 'outer' xml extension will allow naive editors to know that at least this is an xml file. I will include a sample of the XML format with the pull-request for this CL. 2013-02-16 18:01:55 -04:00
			`import re`

Tools: update python coding style Tools: update PrintVersion.py coding style autotest: update python coding style pysim: update python coding style jsb_sim: update Python coding style param_metadata: update Python coding style 2016-07-31 07:22:06 -03:00
Docs: Add XML emit to param_parse.py. See below for more details... I've refactored the param_parse tool to use various 'emitters'. An emitter can take parameter info and output it in a particular format. Currently the only supported emitters are the wiki and XML formats. The goal of these changes is to create a standard machine readable description of parameters - mainly for use by ground control stations, but it will also enable spiffy scripting environments where code can refer symbolically to vehicle parameters (reflectionish). Open issue: Is there any sort of Ardupilot build id which can be included in the generated XML? That would ensure that we select the correct paramdefs for the load on the target (possibly by asking the target for a SHA or somesuch). If that issue is resolved, then the filename for the XML file should probably be something like: arduplane-ca5742ac.pdef.xml. It is worth noting that I've proposed a suffix of ".pdef.xml" for these file types. This facilitates automated file handling on Android devices. On Android you can register 'handlers' for particular file extensions and if the user tries to open that extension in email or a web browser your app will be given a chance to do something about it. The 'outer' xml extension will allow naive editors to know that at least this is an xml file. I will include a sample of the XML format with the pull-request for this CL. 2013-02-16 18:01:55 -04:00			`class Emit:`
param_parse.py: emit SIM_ parameters along with everthing else 2023-01-06 20:59:44 -04:00			`def __init__(self):`
			`pass`
Tools: update python coding style Tools: update PrintVersion.py coding style autotest: update python coding style pysim: update python coding style jsb_sim: update Python coding style param_metadata: update Python coding style 2016-07-31 07:22:06 -03:00
Tools: Fix emit.py regex 2021-08-18 21:44:39 -03:00			`prog_values_field = re.compile(r"-?\d*\.?\d+: ?[\w ]+,?")`
Docs: Add XML emit to param_parse.py. See below for more details... I've refactored the param_parse tool to use various 'emitters'. An emitter can take parameter info and output it in a particular format. Currently the only supported emitters are the wiki and XML formats. The goal of these changes is to create a standard machine readable description of parameters - mainly for use by ground control stations, but it will also enable spiffy scripting environments where code can refer symbolically to vehicle parameters (reflectionish). Open issue: Is there any sort of Ardupilot build id which can be included in the generated XML? That would ensure that we select the correct paramdefs for the load on the target (possibly by asking the target for a SHA or somesuch). If that issue is resolved, then the filename for the XML file should probably be something like: arduplane-ca5742ac.pdef.xml. It is worth noting that I've proposed a suffix of ".pdef.xml" for these file types. This facilitates automated file handling on Android devices. On Android you can register 'handlers' for particular file extensions and if the user tries to open that extension in email or a web browser your app will be given a chance to do something about it. The 'outer' xml extension will allow naive editors to know that at least this is an xml file. I will include a sample of the XML format with the pull-request for this CL. 2013-02-16 18:01:55 -04:00
Tools: update python coding style Tools: update PrintVersion.py coding style autotest: update python coding style pysim: update python coding style jsb_sim: update Python coding style param_metadata: update Python coding style 2016-07-31 07:22:06 -03:00			`def close(self):`
Docs: Add XML emit to param_parse.py. See below for more details... I've refactored the param_parse tool to use various 'emitters'. An emitter can take parameter info and output it in a particular format. Currently the only supported emitters are the wiki and XML formats. The goal of these changes is to create a standard machine readable description of parameters - mainly for use by ground control stations, but it will also enable spiffy scripting environments where code can refer symbolically to vehicle parameters (reflectionish). Open issue: Is there any sort of Ardupilot build id which can be included in the generated XML? That would ensure that we select the correct paramdefs for the load on the target (possibly by asking the target for a SHA or somesuch). If that issue is resolved, then the filename for the XML file should probably be something like: arduplane-ca5742ac.pdef.xml. It is worth noting that I've proposed a suffix of ".pdef.xml" for these file types. This facilitates automated file handling on Android devices. On Android you can register 'handlers' for particular file extensions and if the user tries to open that extension in email or a web browser your app will be given a chance to do something about it. The 'outer' xml extension will allow naive editors to know that at least this is an xml file. I will include a sample of the XML format with the pull-request for this CL. 2013-02-16 18:01:55 -04:00			`pass`

			`def start_libraries(self):`
Tools: update python coding style Tools: update PrintVersion.py coding style autotest: update python coding style pysim: update python coding style jsb_sim: update Python coding style param_metadata: update Python coding style 2016-07-31 07:22:06 -03:00			`pass`

Tools: Allow specifying parameter metadata format Also removes unneeded passing of a file pointer 2018-12-06 05:07:51 -04:00			`def emit(self, g):`
Tools: update python coding style Tools: update PrintVersion.py coding style autotest: update python coding style pysim: update python coding style jsb_sim: update Python coding style param_metadata: update Python coding style 2016-07-31 07:22:06 -03:00			`pass`
Tools: param_metadata: do not emit Legacy fields to rst/Wiki 2024-09-04 08:02:52 -03:00
			`def should_emit_field(self, param, field):`
			`return field not in ['Legacy']`