Support complex parameter values.

[balthasarschuess]

Assuming the following yaml configuration.

/**:
    ros__parameters:
      param: 
        sub_param_foo: "foo"
        sub_param_bar: "bar"

Currently this fails, because key/value ParameterValues are not implemented yet:

let node = executor.create_node("test")?;
let w2mo_config: MandatoryParameter<Arc<str>> = node.declare_parameter("param").mandatory()?;
// --> Error: 
//      parameter was declared as non-optional but no value was available, 
//      either through a user specified default, a command-line override, or a previously set value

Most useful to me would be something like the following to work:

use serde::Deserialize;

#[derive(Deserialize, Clone)]
pub struct MyParam {
  pub sub_param_foo : String,
  pub sub_param_foo: String, 
}

let node = executor.create_node("test")?;
let w2mo_config: MandatoryParameter<MyParam> = node.declare_parameter("param").mandatory()?;

But I also would be happy if I could parse my struct from the Arc<str> somehow.

[balthasarschuess]

Won't do, because the idiomatic way is to access the parameter with dot notation

[mxgrey]

Structured parameters (which is what you're asking for with MyParam) is definitely something we would like to support. It's only a matter of who will have time to work on it and when.

I believe the way it's meant to work under the hood is there would be two parameters in your case:

param.sub_param_foo: Arc<str>
param.sub_param_bar: Arc<str>

That's how they would be stored in the internal parameter map. But then you could define

#[derive(Parameters)]
struct MyParam {
    sub_param_foo: MandatoryParameter<Arc<str>>,
    sub_param_bar: MandatoryParameter<Arc<str>>,
}

Then we'd offer an API along the lines of node.declare_parameters::<P: Parameters>("my_param")? (note that it's plural). The Parameters macro would work recursively, for example you could add:

#[derive(Parameters)]
struct MyNestedParam {
    my_param: MyParam,
    my_other_param: OptionalParameter<f64>,
}

I don't think we'd use serde for this since we still need to manage access to the individual parameter values. Although we could certainly provide something like a .get_all() method for the struct that returns a cloned struct of all the raw values. We'll need the Parameters macro to autogenerate the raw struct.

I'm familiar enough with procedural macros that I know how to implement all of this, but I'm planning on prioritizing actions before this since I think actions are the more crucial missing piece at the moment.

[balthasarschuess]

Hey @mxgrey thanks for the answer.

This sounds like a nice way to do it. I was toying with writing a serde deserializer implementation using the meta information from the struct to declare the parameters during deserialization.
The proposed solution fits the use case a bit better, because it natively supports changing parameters.
However, the main reason for closing this issue was that Map<str, Type> configurations can't be supported, because the ros2 standard appears to purposefully forbid such parameters.

So for my use case I can either, load json strings as parameter values and decode them at runtime at the cost of extra boilerplate, or sidestep the ros ecosystem and load such configs directly form json/yaml/toml.
I need to discuss this with my supervisor. Maybe I can contribute to this feature if we decide to go for the former solution.