Inconsistent usage of non-numeric validator arguments

[sven-hoek]

I would like to refer to variables that I already have in code (in an underlying driver library) to define bounds of a parameter.

I.e., doing something like this

gain:
    type: double
    default_value: 0.0
    read_only: false
    description: "The amplifier gain in dB"
    validation:
      bounds<>: [device_params::Gain::min, device_params::Gain::max]

In the generated header file, it does work how I want it at the declaration of the parameter: it puts the unquoted arguments there, resulting in properly working code:

descriptor.read_only = false;
descriptor.floating_point_range.resize(1);
descriptor.floating_point_range.at(0).from_value = device_params::Gain::min;
descriptor.floating_point_range.at(0).to_value = device_params::Gain::max;

However, at the validation part of the generated code, it quotes the arguments, leading to compile errors:

param = parameters_interface_->get_parameter(prefix_ + "gain");
RCLCPP_DEBUG_STREAM(logger_, param.get_name() << ": " << param.get_type_name() << " = " << param.value_to_string());
if(auto validation_result = bounds<double>(param, "device_params::Gain::min", "device_params::Gain::max"); validation_result) {
    throw rclcpp::exceptions::InvalidParameterValueException(fmt::format("Invalid value set during initialization for parameter 'gain': {}", validation_result.error()));
}

Could it be an easy fix if it's just the quoting?

[christophfroehlich]

Wouldn't be your solution be dependent on the include order in a way that the generated file will only be compilable if it is included after your driver?
Wouldn't it be safer if you write a custom validator, where you explicitly include the necessary files?

[sven-hoek]

Wouldn't be your solution be dependent on the include order in a way that the generated file will only be compilable if it is included after your driver?
Wouldn't it be safer if you write a custom validator, where you explicitly include the necessary files?

Well, that's what I'm doing right now: I am currently using custom validators. However, the min-max values are accessible in the validator-header, so they are also accessible from the generated parameter-header without explicitly including anything more.

This works all good and well but a big chunk of my validators are merely checking for min/max bounds. However: when inspecting the parameters via the describe_parameters services or ros2 param describe, these bounds are not listed in either floating_point_range or integer_range. But I would like them to be.

The reason I went with the custom validators (instead of bounds<>, gt<>, etc) is that I do have the validators available from the underlying driver-library, so I simply reused them instead of repeating the bounds in the parameter-YAML. So, then I thought - if I have the validator functions available, I also have their min/max values and could refer to those when using bounds<> to have the best of both worlds.

[christophfroehlich]

I see, ros2 param describe is a major argument for your use case.

To have that reliable and included in the generated library: Would it work to include the driver header file in the generate_parameter_library() library instead of the validator, and just use the built-in validators (fixing the templates somehow)?

[sven-hoek]

Well, that is what I tried. I mean indirectly, I already have the driver header file in the generated parameter-library because my validator-header includes it (any difference if I include it directly at the CMake generate_parameter_library() call?

Then, when I refer to it using gt<> or bounds<>, it actually puts the right (unquoted) token at the parameter declaration, which seems to successfully have access to it.
However, when it inserts the token at the validation of the parameters, it puts my variables in quotes, which makes them C++ string-literals which then obviously throws off the bounds<double>-function, which expects doubles.

[christophfroehlich]

Well, that is what I tried. I mean indirectly, I already have the driver header file in the generated parameter-library because my validator-header includes it (any difference if I include it directly at the CMake generate_parameter_library() call?

I am just thinking of having a best practice example for doing things like this, if it is possible without creating an (empty) validation file just to include the driver header.

Then, when I refer to it using gt<> or bounds<>, it actually puts the right (unquoted) token at the parameter declaration, which seems to successfully have access to it. However, when it inserts the token at the validation of the parameters, it puts my variables in quotes, which makes them C++ string-literals which then obviously throws off the bounds<double>-function, which expects doubles.

Sure, someone has to fix the templates for this.

[sven-hoek]

I am just thinking of having a best practice example for doing things like this, if it is possible without creating an (empty) validation file just to include the driver header.

I'd say it should be no problem to pass the driver-library header to the CMake function call instead of passing a validation file, at least in my case. Or are there any requirements for files to be included there?

Sure, someone has to fix the templates for this.

I briefly tried to check and saw the Jija code for the place where it gets quoted looks something like this:

if(auto validation_result = {{validation_function}};

So, I assume that validation_function is already a string with the complete validation-function-call. I haven't yet gotten to see where this one is assembled. But it seems like get_python_val_to_str_func is involved and I guess it will be hard to have it not convert strings to quoted strings but leave them unquoted because in most other cases, you'd want string values quoted.
But not even sure if that was the right place.