Implicitly cast integer values for double parameters

[jacobperron]

Feature request

Feature description

If we try to pass an integer value to a double parameter from the command line or from a parameters YAML file we get a rclcpp::ParameterTypeException. For example, passing a parameter from the command line:

ros2 run foo_package foo_node --ros-args -p foo_arg:=1

results in the following error:

terminate called after throwing an instance of 'rclcpp::ParameterTypeException'
  what():  expected [double] got [integer]

and we can fix it by explicitly making our value a floating point number:

ros2 run foo_package foo_node --ros-args -p foo_arg:=1.0

But, it seems reasonable to me that if a user forgets to explicitly provide a floating point value that we should implicitly cast an integer to a float (as is done in many programming languages).

[ivanpauno]

@jacobperron you were assigned to this from waffle meeting.
I think @clalancette and @mabelzhang were also interested in this.

[maxlein]

Can you add the affecting parameters name to the exception when you tackle this pls?

For example if you load a yaml file or a list of parameters in a launch file, it can be really annoying finding the wrong parameter.

[jacobperron]

Can you add the affecting parameters name to the exception when you tackle this pls?

I'm not sure the best way to add the parameter name, since the exception is coming from ParamterValue, which has no notion of the parameter name. We can probably catch the exception higher up and throw a different exception with the parameter name.

[jacobperron]

See #1024 for a patch that allows integer values to be cast to double. This does not include arrays of integers being cast to arrays of double (for technical reasons).

Regarding improving the error message, two options come to mind:

1. Catch the ParameterTypeException wherever rclcpp is calling ParameterValue::get and re-throw a new exception (InvalidParameterTypeException) that has a message including the parameter name.
   • Con: Users can still get the less informative ParameterTypeException if they call ParameterValue::get directly.
2. Add a member to ParameterValue for the parameter name. Then this name can be used to improve the existing ParameterTypeException message.
   • Con: Having the name member in both Parameter and ParameterValue classes seems redundant.

I'm leaning towards (2), unless there's some unforeseen consequence to this approach.

@wjwwood Thoughts?

[jacobperron]

I looked into implementing both options. Option (2) certainly seems more intrusive as it requires touching all of the ParameterValue constructors for passing the parameter name and any code that is constructing ParameterValues. I'm starting to think that (1) might make more sense.

[jacobperron]

See #1027 for an implementation of (2).

[clalancette]

Given that we closed #1024, we can close this as well. @jacobperron feel free to reopen if you think this is in error.

[jacobperron]

I closed #1024 since there wasn't a clear path to a solution and I don't intend to spend more time working on it.
But maybe this is still something we want to tackle at some point in the future and worth leaving open; I'm not sure.