Is your feature request related to a problem? Please describe.
As far as my understanding of the controller architectures goes
When chaining controllers, the export_reference_interfaces of one controller are consumed by command_interface_configuration of another controller.
Command interfaces have a 1:1 relation, meaning, each command interface can only have one producer (write) and can be claimed by only one consumer (read). State interfaces have a 1:n relation, meaning each state interface can only have one producer, but multiple consumer.
This 1:N relation for state interfaces makes it very easy to implement and use state broadcasters.
It would be very useful for logging and debugging, when command interfaces would also follow this 1:N relation too, meaning that there could be multiple consumers of a command interface.
Describe the solution you'd like
Either allow ControllerInterfaceBase::state_interface_configuration to treat a command interface (ControllerInterfaceBase::command_interface_configuration) as "state" with read-only access, or allow a multiple ChainableControllerInterface to use one command interface as reference (ChainableControllerInterface::export_reference_interfaces).
Overall, I think it would be easier if there would be only a single controller interface with read and write interfaces to state and command "topics".
Describe alternatives you've considered
A workaround is to create a custom chainable controller, that export_reference_interfaces a command interfaces, reads from it, publishes the values, and forwards these values via command_interface_configuration to the actual controller.
But this makes the configuration more complicated and also adds additional delay as this broadcaster has to sit in between two controllers, which are supposed to communicate directly.
Is your feature request related to a problem? Please describe.
As far as my understanding of the controller architectures goes
ControllerInterfaceBasecan:ControllerInterfaceBase::state_interface_configuration)ControllerInterfaceBase::command_interface_configuration)ChainableControllerInterfacecan additionally:ChainableControllerInterface::export_state_interfaces)ChainableControllerInterface::export_reference_interfaces)When chaining controllers, the
export_reference_interfacesof one controller are consumed bycommand_interface_configurationof another controller.Command interfaces have a 1:1 relation, meaning, each command interface can only have one producer (write) and can be claimed by only one consumer (read). State interfaces have a 1:n relation, meaning each state interface can only have one producer, but multiple consumer.
This 1:N relation for state interfaces makes it very easy to implement and use state broadcasters.
It would be very useful for logging and debugging, when command interfaces would also follow this 1:N relation too, meaning that there could be multiple consumers of a command interface.
Describe the solution you'd like
Either allow
ControllerInterfaceBase::state_interface_configurationto treat a command interface (ControllerInterfaceBase::command_interface_configuration) as "state" with read-only access, or allow a multipleChainableControllerInterfaceto use one command interface as reference (ChainableControllerInterface::export_reference_interfaces).Overall, I think it would be easier if there would be only a single controller interface with read and write interfaces to state and command "topics".
Describe alternatives you've considered
A workaround is to create a custom chainable controller, that
export_reference_interfacesa command interfaces, reads from it, publishes the values, and forwards these values viacommand_interface_configurationto the actual controller.But this makes the configuration more complicated and also adds additional delay as this broadcaster has to sit in between two controllers, which are supposed to communicate directly.