Is your feature request related to a problem? Please describe.
In our systems, for most of our devices we have to report software/firmware/hardware version information. For example motor controller configuration checksums, version information for our PLCs, battery serial number, etc.
In our stack we read strings, over CAN, CANopen, Modbus, EtherNet/IP, etc.
In our current system, we publish topics from hardware plugins (note this is primarily still ROS 1). But as we progress to ROS 2, I think it would be preferable if we could define command/state interfaces as strings so we can map them directly into controllers.
For example, the battery state controller PR ros-controls/ros2_controllers#1888, would enable publishing battery states from our hardware components based battery drivers. But there is currently no way to map the serial number from the hardware. You'd have to specify it in the controller configuration file.
Primarily my needs for this are for state interfaces. I do have one example where we had to integrate a Modbus based text display and used strings as commands. Though this is not something we currently use on our robots. But the use case has existed for us.
Describe the solution you'd like
I'd like the option to define command and state interfaces as strings.
<command_interface name="str_cmd" data_type="string"/>
<state_interface name="firmware_version" data_type="string"/>
Such that we can use them to define the interface to our hardware components.
Describe alternatives you've considered
We are currently on jazzy. And do not have the message control_msgs/msg/GenericHardwareStatus available.
Populating the firmware_version or state_details fields might be sufficient for our needs. However, that seems like a bit of a separate system that doesn't enable me to handle the above example of the serial_number in the battery state, or some custom message types we will have to support.
The other option would be publishing from a topic in the hardware component plugin. This feels like the most obvious, make it work type of solution, but it doesn't feel as cohesive to me.
Additional context
Understanding there is probably some implication here on how the data is copied / moved in a real time way. My co-workers and myself should have some bandwidth coming up to implement this, if we can decide on a general direction (if reasonable to add).
Is your feature request related to a problem? Please describe.
In our systems, for most of our devices we have to report software/firmware/hardware version information. For example motor controller configuration checksums, version information for our PLCs, battery serial number, etc.
In our stack we read strings, over CAN, CANopen, Modbus, EtherNet/IP, etc.
In our current system, we publish topics from hardware plugins (note this is primarily still ROS 1). But as we progress to ROS 2, I think it would be preferable if we could define command/state interfaces as strings so we can map them directly into controllers.
For example, the battery state controller PR ros-controls/ros2_controllers#1888, would enable publishing battery states from our hardware components based battery drivers. But there is currently no way to map the serial number from the hardware. You'd have to specify it in the controller configuration file.
Primarily my needs for this are for state interfaces. I do have one example where we had to integrate a Modbus based text display and used strings as commands. Though this is not something we currently use on our robots. But the use case has existed for us.
Describe the solution you'd like
I'd like the option to define command and state interfaces as strings.
Such that we can use them to define the interface to our hardware components.
Describe alternatives you've considered
We are currently on jazzy. And do not have the message control_msgs/msg/GenericHardwareStatus available.
Populating the
firmware_versionorstate_detailsfields might be sufficient for our needs. However, that seems like a bit of a separate system that doesn't enable me to handle the above example of theserial_numberin the battery state, or some custom message types we will have to support.The other option would be publishing from a topic in the hardware component plugin. This feels like the most obvious, make it work type of solution, but it doesn't feel as cohesive to me.
Additional context
Understanding there is probably some implication here on how the data is copied / moved in a real time way. My co-workers and myself should have some bandwidth coming up to implement this, if we can decide on a general direction (if reasonable to add).