Discussing the ROS2 parameter API

Next Generation ROS
1

Hi all,

I wanted to open up a discussion around ROS2 parameters. I’ve tried using it as recommended as much as possible but am finding that it’s not a sustainable solution for a few reasons I outline below.

Here’s a screenshot of what the code currently looks like for the NASA-JPL Open Source Rover on ROS2 Foxy (using Python).

image
image2014×1890 846 KB

(FYI Roboclaws are a brand of motor controller)

I have to declare each parameter explicitly. It’s possible to allow_undeclared_parameters but that is not recommended if you know the parameters ahead of time and only removes the need for the first block.
This is live-able, but now I’m also trying to read in a priori unknown, generic parameters in the form of a dictionary for a different project. This is currently unsupported or needs to be hacked in, which in my opinion severely limits the usefulness of using ROS2 parameters. There are several use cases for allowing dictionaries or lists with different types, notably when you’re configuring a node that has an at compile time unknown number of parameters or when your parameters are nested in a tree structure.

Two other issues I see is the verbosity of getting a parameter and the need to strictly type it in Python, neither of which are very pythonic. Comparing to the code in the OSR repo above, ideally I’d like to do this:

try:
    self.roboclaw_mapping = self.get_parameter('roboclaw_mapping')
except ParameterNotFoundException: ...

and

try:
    addr = self.roboclaw_mapping["drive_left_front"]["address"]
except KeyError, ValueError:
    self.log("ERROR", "you messed up your yaml file...").  # actually do self.get_logger.log(...)

or

for name, connect_details in self.roboclaw_mapping.items():  # don't know how many there are!
    self.connect(connect_details)

This is a lot more compact and readable, and also allows me to practice duck typing.

The reasoning behind the support for exclusively basic types is listed in the design doc:

Only homogenous arrays of datatypes will be supported. This is to avoid the unnecessary complexity of the introspection needed to handle multidimensionality and heterogeneity within the arrays.

I’d argue that heterogeneity and having an a priori unknown set of parameters is necessary. I’m also not sure what complexity this demands.
That same article states:

byte[] is included to allow the storage of binary blobs. Its use is not recommended but can be very convenient, and explicitly supporting it is better than having people try to abuse other datatypes such as strings

My best solution to implement what I describe above is to squeeze a JSON message in a string. I’ve seen a fellow roboticist do this as well and I would be worried that this kind of abuse will become the default. I’m hoping that a discussion will lead us to a (better) solution for these issues or any ongoing efforts to improve this.

Relevant discussions/answers:

7 Likes