The lbr_ros2_control::SystemInterface always exposes all command interfaces regardless of the FRI client command mode

[mhubii]

Implementation scenarios

Two scenarios come to mind:

• Modification of existing code
• Proper abstraction

Scenario I: System interface modification

Can be added conditionally in lbr_system_interface.xacro.

1. Wrench command interface:

   lbr_fri_ros2_stack/lbr_description/ros2_control/lbr_system_interface.xacro

   Line 66 in 808bb07

   <command_interface name="force.x" />

2. Torque command interface:

   lbr_fri_ros2_stack/lbr_description/ros2_control/lbr_system_interface.xacro

   Line 86 in 808bb07

   <command_interface name="effort">

Note, this further requires switch cases in lbr_ros2_control::SystemInterface, e.g. in write:

lbr_fri_ros2_stack/lbr_ros2_control/src/system_interface.cpp

Line 250 in 808bb07

for (std::size_t i = 0; i < lbr_fri_ros2::N_JNTS; ++i) {

The advantage of a single system interface is that it might be used to establish an initial connection that reads the desired client command mode, to then load the appropriate command interface: https://github.com/lbr-stack/lbr_fri_ros2_stack/tree/jazzy/lbr_fri_ros2/src/interfaces. However, there would not be a way to tell the KUKA FRI server about user-defined command modes, i.e. command modes that are not FRI native (see below). Could this alternatively be achieved via system interface abstraction? In this case, automatically loading the right system interface would somehow be performed by the resource manager (if desired).

Scenario II: System interface abstraction

Alternatively, the system interface may be abstracted, which might be the cleaner design, but would require quite a few changes. Approximate changes in the case of abstraction:

1. Implement a lbr_ros2_control::SystemInterface per client command mode (potentially with base interface since states would still be shared in this case)
2. Modify system_interface.xml to include each interface
   

   lbr_fri_ros2_stack/lbr_ros2_control/plugin_description_files/system_interface.xml

   Line 4 in 14ecad8

   <class type="lbr_ros2_control::SystemInterface"

3. Modify lbr_system_interface.xacro to load the appropriate interface by client command mode

lbr_fri_ros2_stack/lbr_description/ros2_control/lbr_system_interface.xacro

Line 27 in 14ecad8

<plugin>lbr_ros2_control::SystemInterface</plugin>

This might help untangle the lbr_description file a little.

The question here is also whether the lbr_ros2_control::SystemInterface should expose command modes beyond KUKA's client command modes. As e.g. proposed in #304. The system interface modification scenario would not provide a clean way to facilitate extending command modes.

Thinking this through, scenario II might actually not be too much work whilst providing:

• Extendability
• Clear separation of concerns
• Runtime improvements (albeit absolutely little)

Future anticipated implications

A driving consideration here could be the potential command mode switch. Since this, however, this isn't supported natively by the FRI, one might thus expect quite some entanglement. A proper abstraction might thus be desirable, potentially with some orchestration above the controller manager.

However, the client_command_mode is fundamentally a server-side configuration, and should thus not need to be configured on the client side (as currently done):

lbr_fri_ros2_stack/lbr_description/ros2_control/lbr_system_config.yaml

Line 5 in 14ecad8

client_command_mode: position # the command mode specifies the user-sent commands. Available: [position, torque, wrench]

The system interface abstraction would not allow for easy automatic configuration (but neither does the xacro file). Essentially this logic:

lbr_fri_ros2_stack/lbr_fri_ros2/src/async_client.cpp

Line 21 in 14ecad8

switch (client_command_mode) {

Would then be handled by the lbr_fri_ros2::AsyncClient.