Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Array parameters wierdness #128

Open
sprenger120 opened this issue Jun 28, 2023 · 1 comment
Open

Array parameters wierdness #128

sprenger120 opened this issue Jun 28, 2023 · 1 comment
Labels
bug Something isn't working

Comments

@sprenger120
Copy link
Contributor

There seem to be some issues with the handling of array parameters. I'm encountering problems with setting parameters and getting my application terminated, because of

Wrong parameter type, parameter {myParam} is of type {integer}, setting it to {integer_array} is not allowed.

Working configuration:

parameters.yaml

  myParam: {
    type: int_array_fixed_2,
    description: "myDescription",
    default_value: [ 0, 0],
    validation: {
      element_bounds<>: [ 0, 10000 ]
    }
  }

config.yaml

node:
  ros__parameters:
    myParam: [0, 1]

bounds demoting array to single integer

parameters.yaml

  myParam: {
    type: int_array_fixed_2,
    description: "myDescription",
    default_value: [ 0, 0],
    validation: {
      bounds<>: [ 0, 10000 ]
    }
  }

Changing out element_bounds to bounds will demote the parameter to a single integer and cause the error at the start. Removing the validation block will fix the problem.

No default_value demotes to single integer

parameters.yaml

  myParam: {
    type: int_array_fixed_2,
    description: "myDescription",
    validation: {
      element_bounds<>: [ 0, 10000 ]
    }
  }

Removing the default_value key will also demote the array. Removing the validation block will change nothing.

Something fishy is going on here, could you have a look? Thank you <3

@tylerjw
Copy link
Contributor

tylerjw commented Jul 17, 2023

For the second case, I used the example code in this repo to reproduce and I traced the error to these lines of code (in the generated output):

      param = parameters_interface_->get_parameter(prefix_ + "three_numbers_of_five");
      RCLCPP_DEBUG_STREAM(logger_, param.get_name() << ": " << param.get_type_name() << " = " << param.value_to_string());
      if(auto validation_result = bounds<int64_t>(param, 0, 10000);

The debug output is this:

[DEBUG] [1689616694.024382816] [admittance_controller]: three_numbers_of_five: integer_array = [3, 3, 3]

This means that the correct type (integer_array) is being set in that param variable that is then sent to the bounds function: https://github.com/PickNikRobotics/RSL/blob/91c445b283c5c74a23be0a62f8e6ca07f1fb1e5a/include/rsl/parameter_validators.hpp#L204

This uses the method rclcpp::Parameter::get_value with the template argument passed into the bounds method. The problem is that the template argument is int64_t and the parameter type is correctly integer_array. This is the reason for the separate bounds and element_bounds validation methods as you have discovered.

How do we make this error more useful (or earlier, maybe compile time?). The error message correctly states that the types don't match but doesn't say where the error occurred.

For a better run-time error, we could catch that exception in the validator functions and add to the text explaining where the error occurred (and what the user could do about it).

Ideally, we'd catch this at compile time, though, or better-yet make the problem disappear and eliminate the need for the user to know about bounds and element_bounds. All the information is there at compile time to insert the code that does what the user expects.

@tylerjw tylerjw added the bug Something isn't working label Aug 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants