Add method to set many parameters by passing a single string
For integrating with https://github.com/robotology/wb-toolbox, we need some way to pass arbitrary parameters (as we do not know in advance the parameters that will be available in a given solver) via single string.
For example, in place of:
// Set osqp-specific parameters
solver.setBooleanParameter("verbose", true);
if (solver.getSolverName() == "osqp")
{
solver.setRealNumberParameter("alpha", 1.0);
// See https://github.com/robotology/osqp-eigen/pull/172
solver.setBooleanParameter("polish", true);
}
we could use either a json string:
solver.setParametersViaJsonString("{\"verbose\": true, \"alpha\": 1.0, \"polish\": true}");
or toml inline table (https://toml.io/en/v1.0.0#inline-table):
solver.setParametersViaTomlString("parameters = { verbose = true, alpha = 1.0, polish=true }");
I am inclined more to the toml inline table, as there are less double quotes involved (none if you do not use string parameters) and potentially is more easy to integrate (and copy&paste back and forth) parameters from BLF's ParamHandler Toml backend.
Probably we can also provide a setting on either ignore or raise an error if an unknown setting is passed, as there are use case for both cases: one one hand ignoring unknown parameters make it simple to have a single string with settings for multiple solvers, so switching solvers only requires changing the solver name, but it opens the door of bugs caused by typos, that can be prevented if one specifies that unknown parameters should raise an error.
fyi @S-Dafarra @mfussi66 @giulioromualdi @gio-ds
Probably we can also provide a setting on either ignore or raise an error if an unknown setting is passed, as there are use case for both cases: one one hand ignoring unknown parameters make it simple to have a single string with settings for multiple solvers, so switching solvers only requires changing the solver name, but it opens the door of bugs caused by typos, that can be prevented if one specifies that unknown parameters should raise an error.
This is a behavior that can enabled/disabled by with an additional parameter I guess
Yes,
I also vote for the toml parser. If I'm not mistaken toml is already a dependency of the superbuild
I also vote for the toml parser. If I'm not mistaken toml is already a dependency of the superbuild
I think in the superbuild we pull also somehow (I think with apt/conda) nlohmann-json, but indeed toml seems a better option.
I wonder if this may be also useful to easily pass a group parameters in a structured way between a BipedalLocomotion::ParametersHandler and a QpSolversEigen::Solver without having to add any mutual dependency. Or perhaps they could only share some logic (such as the methods that get all the supported parameters for a given type for each solver, that for sure is required by this functionality).