feat(schema): variables and assignments for applications

[eeberhard]

Description

As based on internal design drafts, this PR introduces new properties for the application to define variables and assignments.

Variables act like top-level parameters in an application that store a value of a specific type, with an initial value when the application is loaded. Component and controller parameters can then reference that variable for the value instead of a hard-coded value. The backend implementation is responsible for applying the up-to-date variable value when the respective component / controller is loaded, and will also automatically set the parameter on loaded components / controller when the variable changes. Variables can also be associated with events to be triggered whenever the variable is changed.

Assignments are a new way for components / controllers to publish an output value at discrete intervals. Assignment values are typed like parameters. Assignments can then be bound to either a variable or parameter in the application, such that when the component / controller makes the assignment, the corresponding value is updated. If a variable is updated by an assignment, then any parameters that reference that variable will also be updated.

I also made some structural changes to the schema composition, moving some definitions into sub schemas and using more top-level defs to yield nicer bundling. As a general rule, I added a def for every subschema file.

I also spent a long time trying to make schema composition of parameter and assignment targets nicer, since there is a common repetition of component or controller identifier for loading / unload (no additional properties), for targeting with an assignment (additional property of the parameter name), or for targeting in a "set" event (additional property of the parameter name and value). This is a case of extending closed schemas, so I would have liked to use unevaluatedProperties. However, the VSCode yaml extension from RedHat does not support draft 2019, and therefore does not support unevaluatedProperties and certain invalid schemas would appear valid. Because that's the most common code editor used, I chose to have some duplication in these subschemas instead.

Supporting information

schema: 2-1-0
dependencies:
  core: v5.0.0

variables:
  foo:
    display_name: Foo
    description: Foo
    type: string
    value: foo
    events:
      load:
        component: foo
  bar:
    display_name: Bar
    description: Bar
    type: state
    state_type: cartesian_pose
    value: bar

components:
  foo:
    parameters:
      foo:
        type: string
        value: abc
      bar:
        variable: foo
    assignments:
      foo:
        variable: foo
      bar:
        component: foo
        parameter: bar
      baz:
        hardware: foo
        controller: foo
        parameter: bar
    events:
      predicates:
        foo:
          set:
            variable: foo
            value: foo

Review guidelines

Estimated Time of Review: x minutes

Checklist before merging:

• Confirm that the relevant changelog(s) are up-to-date in case of any user-facing changes

[domire8]

In common/signal.schema.json, the name of a topic should also be more permissive IMO, it could be the case that one wants to use an outside topic name that has capital letters

[domire8]

In this file on line 69, feels like the pattern properties should be as permissive as for other parameters

[eeberhard]

probably yes - in ros2_control convention we have only seen snake case names in the URDF tags but they could be anything. They also don't interface with ROS directly so don't strictly need to follow the ROS parameter name rules, but that would be a reasonable convention to follow

[domire8]

Users would create variables in Studio right? If so, we might want to be less restrictive with the naming rules?

[eeberhard]

Just as with other application elements (e.g. sequences, conditions), the name of the property is not directly user-facing, and is also not exposed on other interfaces (like ROS network). It just needs to be unique and it helps to follow our naming convention for readability. The display name property of the variable would then be used in Studio to make more visually appealing names

[eeberhard]

In common/signal.schema.json, the name of a topic should also be more permissive

This and other naming comments are unrelated to the variables feature, and are all relatively simple extensions to the schema so could be done separately before 2-1-0 release. I already mixed a structural refactor and a new feature in this PR but I don't want to change too much at once

[domire8]

all relatively simple extensions to the schema so could be done separately before 2-1-0 release

👍