New params interface
There are some features that should be very useful regarding the user parameter interface (ParamServer
and ParserYaml
:
- Generating list of needed parameters by an specific class (sensor, processor...).
- Minimal documentation of each parameter.
- Error specifying all missing parameters (not one by one like now).
- Generate a list of registered classes, its parameters and documentation.
- Allow the
ParamServer
to be used to create sensors and processors (not the whole setup) to get rid of the old YAML classes.
Potentiallities
- This is definitely a feature that would improve the user experience.
- Documentation: The point 4 could be integrated to the CI of the documentation page.
- All sensors and processors would be available to be created using YAML (useful for tests).
Difficulties
- Now there are some parameters that are requested depending on the value of another parameter. Either all the parameters are required to be specified (even the not necessary ones) or a solution is found to implement this.
- ?
Ideas
- The Parser should have less knowledge about the requirements in WOLF. It stores everything in the parameters map (
map<string,value>
like "config/problem/print/print_states"), then the elements in lists (for example sensors, processors...) need a solution. It may be requiring that all elements in a list should have "name" parameter. Then, they would be added to the map with the name (for example "config/sensors/laser_left/extrinsics..."). - This would imply to redesign the
ParamServer
andParserYaml
. Also, the parameters struct would have to evolve to a more complex class having some sort of list of triplets "name", "type" and "documentation". Or maybe encapsulating this in a new classParamsSet
, I'm not sure. (consider #318)
(includes #426 (closed), #428 (closed) and maybe #318)
Edited by Joan Vallvé Navarro