Feature request

The goal of this ticket is to discuss the parameter refactor in rcl as well as the design and implementation considerations

Feature description

Provide C parameters by implementing parameters in rcl.
Relevant resources:

• Parameter design document
• C parameters initial PR : C parameters rcl#54

Design

• Non-parameter design decisions impacting parameter implementation:
  • Node name uniqueness + Services addressing
    • How to address services belonging to a specific node?
    • Below I will consider that nodes can be accessed uniquely by their name and that services used for parameters are known names not used to name nodes
• Parameter design decisions
  • Parameter addressing: how to address a parameter under a given node without ambiguity?
    • the current assumption is to use <NODE_FQN>/<PARAMETER_NAME_NAMESPACED_USING_DOT_SEPARATOR>
  • Uniqueness of parameters under a given node and parameter restrictions
    • Assuming that parameter names are unique under a given node
    • we will need to decide how the system should behave on parameter change:
      • adding a new parameter matching an existing name
      • deleting a parameter defined by the node itself (notion of required parameters)
      • how to change the type of a parameter
      • What changes are allowed within a node's code vs via ROS interfaces

Interfaces

• Homogenize interface definition ([rcl_interfaces] Homogenize iface definition rcl_interfaces#23)

• Add array for all parameter types defined in Adding information for array parameters design#152 once merged (https://github.com/ros2/rcl_interfaces/compare/paremeter_type_array)

• Parameter Events:

  • parameter_event topic location (applies to parameter_event_descriptors as well)
    • Right now the Design document (section Parameter Events) as well as rcl_interfaces documentation specify that the parameter event topic should be located in the node namespace.
    • Some discussion during implementation changed it to being a unique topic in the global namespace that all topics pubish to (Parameter Events should be node specific rclcpp#243)
    • should the parameter_events topic be under the node namespace? or a single topic /parameter_event shared by all?
      • Single topic:
        • convenient for introspection as there is no need to establish N connections to get the parameter events from N nodes
        • security risk: a rogue node (or malicious actor) can get a lot of information about the state of the system just by sniffing this topic
        • If using a single shared topic: How should the parameter events provide information about which node is sending the event?
  • Should parameter events have a timestamp field?

• Parameter description: Update ParameterDescriptor.msg to actually provide a parameter description (define metadata to be included in a ParameterDescriptor)

  • Suggested metadata:
    • Description String
    • Valid set of parameter values (min, max, range, enums, something more complex?) This will allow 2 things:
      • generate parameter validation functions automatically ala dynamic_reconfigure and .cfg files
      • allow other nodes to query this information to know a request is invalid before sending it over the wire
        • How should external nodes access this information?

Implementation

Possible approaches:

• rcl defines parameter interfaces (service topics) and provide data as C structures. The client libraries will need to convert this data as well as implementing the logic of parameter validation and stoe theparameters on success or roll-back on failure.
• rcl processes parameter "requests" and store parameters, rclcpp register callbacks for parameter validation and parameter change event. Also need to provide numerous c utilities (array conversion, array resizing etc). rclcpp will provide conversion functions to provide c++ representations of the parameters (for arrays).

I'm considering prototyping option 2, pending feedback on this, as this would provide the least code duplication in case of multiple client libraries.