Forward State Controller

[Nibanovic]

Forward State Controller

Takes a list of state interfaces, and forwards them to command interfaces.
A single state interface can be forwarded to multiple command interfaces.

Seems like a natural addition alongside "forward command controller", so I'm opening a PR.
In structure, it is very similar to forward command controller

Example config:

    state_interfaces:
      - joint1/position
      - joint1/velocity
    forward_state:
      joint1/position:
        to_command: 
          - joint2/position
          - joint3/position
      joint1/velocity:
        to_command:
          - joint2/velocity

[saikishor]

I personally don't see the need for this at all.

Can you please give some context on why and when this is needed?. Thank you

[Nibanovic]

I wanted to showcase controlling ethercat semaphore lights from OPCUA server.
had one hardware interface which read states from OPCUA server, and another which took command interfaces via ethercat.
The simplest way for me to connect this without changing the hardware interfaces was just to mirror OPCUA states to ethercat commands. That is about it.
This controller then seemed similar to forward_command_controller, so I thought it might be useful to others as well.

[saikishor]

I wanted to showcase controlling ethercat semaphore lights from OPCUA server. had one hardware interface which read states from OPCUA server, and another which took command interfaces via ethercat. The simplest way for me to connect this without changing the hardware interfaces was just to mirror OPCUA states to ethercat commands. That is about it. This controller then seemed similar to forward_command_controller, so I thought it might be useful to others as well.

I personally don't think it makes sense here. Let's see what other maintainers say

[Juliaj]

I changed the test YAML in the hope that it would better represent the use case.

test_forward_state_controller:
  ros__parameters:
    state_interfaces:
      - opcua_stack_green/status
    forward_state:
      opcua_stack_green/status:
        to_command: ["ethercat_stack_green/status"]

If that reading is correct, this boils down to make a single controller to deal with state from hardware A + commands on hardware B. This pattern may be rare for upstream to support. With such controller, the mapping is mostly in configuration, so you don’t have to teach each driver about the other in code.