Repository Summary
| Description | A ros_control implementation that adopts layered scheme |
| Checkout URI | https://github.com/yoshito-n-students/layered_hardware.git |
| VCS Type | git |
| VCS Version | jazzy |
| Last Updated | 2025-02-04 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| layered_hardware | 0.0.0 |
README
layered_hardware
A ros2_control implementation that adopts layered scheme
The layered scheme
- every ros2_control’s component (ex. joint_limits, transmissions) is implemented as a layer plugin (base_class: layered_hardware::LayerInterface)
- plugins of non-actuator-specific layers can be reused for different actuators
- multiple layers for different vendors’ actuators can be used in the same hardware

Hardware Plugin: layered_hardware/LayeredHardware
Hardware parameters
layers (yaml, required)
- sequence of layers to be loaded by this ros2_control hardware
layers[*].name (string, required)
- arbitary name of the layer
layers[*].type (string, required)
- valid type name of the layer
- the type must be exported to the layered_hardware package
- the base class of the type must be layered_hardware::LayerInterface
Example of ros2_control tag in your robot description
<ros2_control name="LayeredHardware" type="system">
<hardware>
<plugin>layered_hardware/LayeredHardware</plugin>
<param name="layers">
- name: example_layer_1
type: layered_hardware/ExampleLayer
- name: example_layer_2
...
...
</param>
...
</hardware>
...
</ros2_control>
Layer plugin: layered_hardware/CommandClamperLayer
- loads lower and upper limits on command interfaces of joints, sensors and gpios from the
ros2_controltag in the robot description - clamps commands within the
write()function (e.g. limits position command using only min and max position limits, ignoring velocity and acceleration limits)
Layer plugin: layered_hardware/JointSaturationLimiterLayer
- based on
joint_limits::JointSaturationLimiter<joint_limits::JointLimits> - applies limits to all joint command interfaces within the
write()function
Hardware parameters
___
- map of parameter names and values for this layer
___
- topic name for robot description, from which joint limits are loaded
Layer plugin: layered_hardware/TransmissionLayer
- based on
transmittion_interface::Transmission - converts joint commands to actuator commands based on reduction ratio of transmission within
write()function - converts actuator states to joint states within
read()function
Layer plugin: layered_hardware/MockActuatorLayer
- implements mock {position, velocity, effort}-controlled actuators
- switches mock actuators’ command modes within
perform_command_mode_swtich()function when controllers using associated interfaces activate - changes actuator states based on commands within
write()function - useful to debug your command generation, state visualization nodes, or transmissions without physical actuators and dynamics simulators
Hardware parameters
___
- map of parameter names and values for this layer
___
- map of parameters for each mock actuator
___
- map to actuator command mode names (
position,velocity,effort) from associated interface names (typically joint interfaces)
Example of parameter description
<param name="example_mock_actuator_layer">
actuators:
example_actuator_1:
command_mode_map:
example_joint_1/position: position
...
example_actuator_2:
...
</param>
Layer plugin: layered_hardware/MonitorLayer
- prints changes on commands and states within
read()function for debug or logging purpose
Examples
Related packages
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | A ros_control implementation that adopts layered scheme |
| Checkout URI | https://github.com/yoshito-n-students/layered_hardware.git |
| VCS Type | git |
| VCS Version | jazzy |
| Last Updated | 2025-02-04 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| layered_hardware | 0.0.0 |
README
layered_hardware
A ros2_control implementation that adopts layered scheme
The layered scheme
- every ros2_control’s component (ex. joint_limits, transmissions) is implemented as a layer plugin (base_class: layered_hardware::LayerInterface)
- plugins of non-actuator-specific layers can be reused for different actuators
- multiple layers for different vendors’ actuators can be used in the same hardware

Hardware Plugin: layered_hardware/LayeredHardware
Hardware parameters
layers (yaml, required)
- sequence of layers to be loaded by this ros2_control hardware
layers[*].name (string, required)
- arbitary name of the layer
layers[*].type (string, required)
- valid type name of the layer
- the type must be exported to the layered_hardware package
- the base class of the type must be layered_hardware::LayerInterface
Example of ros2_control tag in your robot description
<ros2_control name="LayeredHardware" type="system">
<hardware>
<plugin>layered_hardware/LayeredHardware</plugin>
<param name="layers">
- name: example_layer_1
type: layered_hardware/ExampleLayer
- name: example_layer_2
...
...
</param>
...
</hardware>
...
</ros2_control>
Layer plugin: layered_hardware/CommandClamperLayer
- loads lower and upper limits on command interfaces of joints, sensors and gpios from the
ros2_controltag in the robot description - clamps commands within the
write()function (e.g. limits position command using only min and max position limits, ignoring velocity and acceleration limits)
Layer plugin: layered_hardware/JointSaturationLimiterLayer
- based on
joint_limits::JointSaturationLimiter<joint_limits::JointLimits> - applies limits to all joint command interfaces within the
write()function
Hardware parameters
___
- map of parameter names and values for this layer
___
- topic name for robot description, from which joint limits are loaded
Layer plugin: layered_hardware/TransmissionLayer
- based on
transmittion_interface::Transmission - converts joint commands to actuator commands based on reduction ratio of transmission within
write()function - converts actuator states to joint states within
read()function
Layer plugin: layered_hardware/MockActuatorLayer
- implements mock {position, velocity, effort}-controlled actuators
- switches mock actuators’ command modes within
perform_command_mode_swtich()function when controllers using associated interfaces activate - changes actuator states based on commands within
write()function - useful to debug your command generation, state visualization nodes, or transmissions without physical actuators and dynamics simulators
Hardware parameters
___
- map of parameter names and values for this layer
___
- map of parameters for each mock actuator
___
- map to actuator command mode names (
position,velocity,effort) from associated interface names (typically joint interfaces)
Example of parameter description
<param name="example_mock_actuator_layer">
actuators:
example_actuator_1:
command_mode_map:
example_joint_1/position: position
...
example_actuator_2:
...
</param>
Layer plugin: layered_hardware/MonitorLayer
- prints changes on commands and states within
read()function for debug or logging purpose
Examples
Related packages
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | A ros_control implementation that adopts layered scheme |
| Checkout URI | https://github.com/yoshito-n-students/layered_hardware.git |
| VCS Type | git |
| VCS Version | jazzy |
| Last Updated | 2025-02-04 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| layered_hardware | 0.0.0 |
README
layered_hardware
A ros2_control implementation that adopts layered scheme
The layered scheme
- every ros2_control’s component (ex. joint_limits, transmissions) is implemented as a layer plugin (base_class: layered_hardware::LayerInterface)
- plugins of non-actuator-specific layers can be reused for different actuators
- multiple layers for different vendors’ actuators can be used in the same hardware

Hardware Plugin: layered_hardware/LayeredHardware
Hardware parameters
layers (yaml, required)
- sequence of layers to be loaded by this ros2_control hardware
layers[*].name (string, required)
- arbitary name of the layer
layers[*].type (string, required)
- valid type name of the layer
- the type must be exported to the layered_hardware package
- the base class of the type must be layered_hardware::LayerInterface
Example of ros2_control tag in your robot description
<ros2_control name="LayeredHardware" type="system">
<hardware>
<plugin>layered_hardware/LayeredHardware</plugin>
<param name="layers">
- name: example_layer_1
type: layered_hardware/ExampleLayer
- name: example_layer_2
...
...
</param>
...
</hardware>
...
</ros2_control>
Layer plugin: layered_hardware/CommandClamperLayer
- loads lower and upper limits on command interfaces of joints, sensors and gpios from the
ros2_controltag in the robot description - clamps commands within the
write()function (e.g. limits position command using only min and max position limits, ignoring velocity and acceleration limits)
Layer plugin: layered_hardware/JointSaturationLimiterLayer
- based on
joint_limits::JointSaturationLimiter<joint_limits::JointLimits> - applies limits to all joint command interfaces within the
write()function
Hardware parameters
___
- map of parameter names and values for this layer
___
- topic name for robot description, from which joint limits are loaded
Layer plugin: layered_hardware/TransmissionLayer
- based on
transmittion_interface::Transmission - converts joint commands to actuator commands based on reduction ratio of transmission within
write()function - converts actuator states to joint states within
read()function
Layer plugin: layered_hardware/MockActuatorLayer
- implements mock {position, velocity, effort}-controlled actuators
- switches mock actuators’ command modes within
perform_command_mode_swtich()function when controllers using associated interfaces activate - changes actuator states based on commands within
write()function - useful to debug your command generation, state visualization nodes, or transmissions without physical actuators and dynamics simulators
Hardware parameters
___
- map of parameter names and values for this layer
___
- map of parameters for each mock actuator
___
- map to actuator command mode names (
position,velocity,effort) from associated interface names (typically joint interfaces)
Example of parameter description
<param name="example_mock_actuator_layer">
actuators:
example_actuator_1:
command_mode_map:
example_joint_1/position: position
...
example_actuator_2:
...
</param>
Layer plugin: layered_hardware/MonitorLayer
- prints changes on commands and states within
read()function for debug or logging purpose
Examples
Related packages
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | A ros_control implementation that adopts layered scheme |
| Checkout URI | https://github.com/yoshito-n-students/layered_hardware.git |
| VCS Type | git |
| VCS Version | jazzy |
| Last Updated | 2025-02-04 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| layered_hardware | 0.0.0 |
README
layered_hardware
A ros2_control implementation that adopts layered scheme
The layered scheme
- every ros2_control’s component (ex. joint_limits, transmissions) is implemented as a layer plugin (base_class: layered_hardware::LayerInterface)
- plugins of non-actuator-specific layers can be reused for different actuators
- multiple layers for different vendors’ actuators can be used in the same hardware

Hardware Plugin: layered_hardware/LayeredHardware
Hardware parameters
layers (yaml, required)
- sequence of layers to be loaded by this ros2_control hardware
layers[*].name (string, required)
- arbitary name of the layer
layers[*].type (string, required)
- valid type name of the layer
- the type must be exported to the layered_hardware package
- the base class of the type must be layered_hardware::LayerInterface
Example of ros2_control tag in your robot description
<ros2_control name="LayeredHardware" type="system">
<hardware>
<plugin>layered_hardware/LayeredHardware</plugin>
<param name="layers">
- name: example_layer_1
type: layered_hardware/ExampleLayer
- name: example_layer_2
...
...
</param>
...
</hardware>
...
</ros2_control>
Layer plugin: layered_hardware/CommandClamperLayer
- loads lower and upper limits on command interfaces of joints, sensors and gpios from the
ros2_controltag in the robot description - clamps commands within the
write()function (e.g. limits position command using only min and max position limits, ignoring velocity and acceleration limits)
Layer plugin: layered_hardware/JointSaturationLimiterLayer
- based on
joint_limits::JointSaturationLimiter<joint_limits::JointLimits> - applies limits to all joint command interfaces within the
write()function
Hardware parameters
___
- map of parameter names and values for this layer
___
- topic name for robot description, from which joint limits are loaded
Layer plugin: layered_hardware/TransmissionLayer
- based on
transmittion_interface::Transmission - converts joint commands to actuator commands based on reduction ratio of transmission within
write()function - converts actuator states to joint states within
read()function
Layer plugin: layered_hardware/MockActuatorLayer
- implements mock {position, velocity, effort}-controlled actuators
- switches mock actuators’ command modes within
perform_command_mode_swtich()function when controllers using associated interfaces activate - changes actuator states based on commands within
write()function - useful to debug your command generation, state visualization nodes, or transmissions without physical actuators and dynamics simulators
Hardware parameters
___
- map of parameter names and values for this layer
___
- map of parameters for each mock actuator
___
- map to actuator command mode names (
position,velocity,effort) from associated interface names (typically joint interfaces)
Example of parameter description
<param name="example_mock_actuator_layer">
actuators:
example_actuator_1:
command_mode_map:
example_joint_1/position: position
...
example_actuator_2:
...
</param>
Layer plugin: layered_hardware/MonitorLayer
- prints changes on commands and states within
read()function for debug or logging purpose
Examples
Related packages
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | A ros_control implementation that adopts layered scheme |
| Checkout URI | https://github.com/yoshito-n-students/layered_hardware.git |
| VCS Type | git |
| VCS Version | jazzy |
| Last Updated | 2025-02-04 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| layered_hardware | 0.0.0 |
README
layered_hardware
A ros2_control implementation that adopts layered scheme
The layered scheme
- every ros2_control’s component (ex. joint_limits, transmissions) is implemented as a layer plugin (base_class: layered_hardware::LayerInterface)
- plugins of non-actuator-specific layers can be reused for different actuators
- multiple layers for different vendors’ actuators can be used in the same hardware

Hardware Plugin: layered_hardware/LayeredHardware
Hardware parameters
layers (yaml, required)
- sequence of layers to be loaded by this ros2_control hardware
layers[*].name (string, required)
- arbitary name of the layer
layers[*].type (string, required)
- valid type name of the layer
- the type must be exported to the layered_hardware package
- the base class of the type must be layered_hardware::LayerInterface
Example of ros2_control tag in your robot description
<ros2_control name="LayeredHardware" type="system">
<hardware>
<plugin>layered_hardware/LayeredHardware</plugin>
<param name="layers">
- name: example_layer_1
type: layered_hardware/ExampleLayer
- name: example_layer_2
...
...
</param>
...
</hardware>
...
</ros2_control>
Layer plugin: layered_hardware/CommandClamperLayer
- loads lower and upper limits on command interfaces of joints, sensors and gpios from the
ros2_controltag in the robot description - clamps commands within the
write()function (e.g. limits position command using only min and max position limits, ignoring velocity and acceleration limits)
Layer plugin: layered_hardware/JointSaturationLimiterLayer
- based on
joint_limits::JointSaturationLimiter<joint_limits::JointLimits> - applies limits to all joint command interfaces within the
write()function
Hardware parameters
___
- map of parameter names and values for this layer
___
- topic name for robot description, from which joint limits are loaded
Layer plugin: layered_hardware/TransmissionLayer
- based on
transmittion_interface::Transmission - converts joint commands to actuator commands based on reduction ratio of transmission within
write()function - converts actuator states to joint states within
read()function
Layer plugin: layered_hardware/MockActuatorLayer
- implements mock {position, velocity, effort}-controlled actuators
- switches mock actuators’ command modes within
perform_command_mode_swtich()function when controllers using associated interfaces activate - changes actuator states based on commands within
write()function - useful to debug your command generation, state visualization nodes, or transmissions without physical actuators and dynamics simulators
Hardware parameters
___
- map of parameter names and values for this layer
___
- map of parameters for each mock actuator
___
- map to actuator command mode names (
position,velocity,effort) from associated interface names (typically joint interfaces)
Example of parameter description
<param name="example_mock_actuator_layer">
actuators:
example_actuator_1:
command_mode_map:
example_joint_1/position: position
...
example_actuator_2:
...
</param>
Layer plugin: layered_hardware/MonitorLayer
- prints changes on commands and states within
read()function for debug or logging purpose
Examples
Related packages
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | A ros_control implementation that adopts layered scheme |
| Checkout URI | https://github.com/yoshito-n-students/layered_hardware.git |
| VCS Type | git |
| VCS Version | jazzy |
| Last Updated | 2025-02-04 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| layered_hardware | 0.0.0 |
README
layered_hardware
A ros2_control implementation that adopts layered scheme
The layered scheme
- every ros2_control’s component (ex. joint_limits, transmissions) is implemented as a layer plugin (base_class: layered_hardware::LayerInterface)
- plugins of non-actuator-specific layers can be reused for different actuators
- multiple layers for different vendors’ actuators can be used in the same hardware

Hardware Plugin: layered_hardware/LayeredHardware
Hardware parameters
layers (yaml, required)
- sequence of layers to be loaded by this ros2_control hardware
layers[*].name (string, required)
- arbitary name of the layer
layers[*].type (string, required)
- valid type name of the layer
- the type must be exported to the layered_hardware package
- the base class of the type must be layered_hardware::LayerInterface
Example of ros2_control tag in your robot description
<ros2_control name="LayeredHardware" type="system">
<hardware>
<plugin>layered_hardware/LayeredHardware</plugin>
<param name="layers">
- name: example_layer_1
type: layered_hardware/ExampleLayer
- name: example_layer_2
...
...
</param>
...
</hardware>
...
</ros2_control>
Layer plugin: layered_hardware/CommandClamperLayer
- loads lower and upper limits on command interfaces of joints, sensors and gpios from the
ros2_controltag in the robot description - clamps commands within the
write()function (e.g. limits position command using only min and max position limits, ignoring velocity and acceleration limits)
Layer plugin: layered_hardware/JointSaturationLimiterLayer
- based on
joint_limits::JointSaturationLimiter<joint_limits::JointLimits> - applies limits to all joint command interfaces within the
write()function
Hardware parameters
___
- map of parameter names and values for this layer
___
- topic name for robot description, from which joint limits are loaded
Layer plugin: layered_hardware/TransmissionLayer
- based on
transmittion_interface::Transmission - converts joint commands to actuator commands based on reduction ratio of transmission within
write()function - converts actuator states to joint states within
read()function
Layer plugin: layered_hardware/MockActuatorLayer
- implements mock {position, velocity, effort}-controlled actuators
- switches mock actuators’ command modes within
perform_command_mode_swtich()function when controllers using associated interfaces activate - changes actuator states based on commands within
write()function - useful to debug your command generation, state visualization nodes, or transmissions without physical actuators and dynamics simulators
Hardware parameters
___
- map of parameter names and values for this layer
___
- map of parameters for each mock actuator
___
- map to actuator command mode names (
position,velocity,effort) from associated interface names (typically joint interfaces)
Example of parameter description
<param name="example_mock_actuator_layer">
actuators:
example_actuator_1:
command_mode_map:
example_joint_1/position: position
...
example_actuator_2:
...
</param>
Layer plugin: layered_hardware/MonitorLayer
- prints changes on commands and states within
read()function for debug or logging purpose
Examples
Related packages
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | A ros_control implementation that adopts layered scheme |
| Checkout URI | https://github.com/yoshito-n-students/layered_hardware.git |
| VCS Type | git |
| VCS Version | jazzy |
| Last Updated | 2025-02-04 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| layered_hardware | 0.0.0 |
README
layered_hardware
A ros2_control implementation that adopts layered scheme
The layered scheme
- every ros2_control’s component (ex. joint_limits, transmissions) is implemented as a layer plugin (base_class: layered_hardware::LayerInterface)
- plugins of non-actuator-specific layers can be reused for different actuators
- multiple layers for different vendors’ actuators can be used in the same hardware

Hardware Plugin: layered_hardware/LayeredHardware
Hardware parameters
layers (yaml, required)
- sequence of layers to be loaded by this ros2_control hardware
layers[*].name (string, required)
- arbitary name of the layer
layers[*].type (string, required)
- valid type name of the layer
- the type must be exported to the layered_hardware package
- the base class of the type must be layered_hardware::LayerInterface
Example of ros2_control tag in your robot description
<ros2_control name="LayeredHardware" type="system">
<hardware>
<plugin>layered_hardware/LayeredHardware</plugin>
<param name="layers">
- name: example_layer_1
type: layered_hardware/ExampleLayer
- name: example_layer_2
...
...
</param>
...
</hardware>
...
</ros2_control>
Layer plugin: layered_hardware/CommandClamperLayer
- loads lower and upper limits on command interfaces of joints, sensors and gpios from the
ros2_controltag in the robot description - clamps commands within the
write()function (e.g. limits position command using only min and max position limits, ignoring velocity and acceleration limits)
Layer plugin: layered_hardware/JointSaturationLimiterLayer
- based on
joint_limits::JointSaturationLimiter<joint_limits::JointLimits> - applies limits to all joint command interfaces within the
write()function
Hardware parameters
___
- map of parameter names and values for this layer
___
- topic name for robot description, from which joint limits are loaded
Layer plugin: layered_hardware/TransmissionLayer
- based on
transmittion_interface::Transmission - converts joint commands to actuator commands based on reduction ratio of transmission within
write()function - converts actuator states to joint states within
read()function
Layer plugin: layered_hardware/MockActuatorLayer
- implements mock {position, velocity, effort}-controlled actuators
- switches mock actuators’ command modes within
perform_command_mode_swtich()function when controllers using associated interfaces activate - changes actuator states based on commands within
write()function - useful to debug your command generation, state visualization nodes, or transmissions without physical actuators and dynamics simulators
Hardware parameters
___
- map of parameter names and values for this layer
___
- map of parameters for each mock actuator
___
- map to actuator command mode names (
position,velocity,effort) from associated interface names (typically joint interfaces)
Example of parameter description
<param name="example_mock_actuator_layer">
actuators:
example_actuator_1:
command_mode_map:
example_joint_1/position: position
...
example_actuator_2:
...
</param>
Layer plugin: layered_hardware/MonitorLayer
- prints changes on commands and states within
read()function for debug or logging purpose
Examples
Related packages
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | A ros_control implementation that adopts layered scheme |
| Checkout URI | https://github.com/yoshito-n-students/layered_hardware.git |
| VCS Type | git |
| VCS Version | jazzy |
| Last Updated | 2025-02-04 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| layered_hardware | 0.0.0 |
README
layered_hardware
A ros2_control implementation that adopts layered scheme
The layered scheme
- every ros2_control’s component (ex. joint_limits, transmissions) is implemented as a layer plugin (base_class: layered_hardware::LayerInterface)
- plugins of non-actuator-specific layers can be reused for different actuators
- multiple layers for different vendors’ actuators can be used in the same hardware

Hardware Plugin: layered_hardware/LayeredHardware
Hardware parameters
layers (yaml, required)
- sequence of layers to be loaded by this ros2_control hardware
layers[*].name (string, required)
- arbitary name of the layer
layers[*].type (string, required)
- valid type name of the layer
- the type must be exported to the layered_hardware package
- the base class of the type must be layered_hardware::LayerInterface
Example of ros2_control tag in your robot description
<ros2_control name="LayeredHardware" type="system">
<hardware>
<plugin>layered_hardware/LayeredHardware</plugin>
<param name="layers">
- name: example_layer_1
type: layered_hardware/ExampleLayer
- name: example_layer_2
...
...
</param>
...
</hardware>
...
</ros2_control>
Layer plugin: layered_hardware/CommandClamperLayer
- loads lower and upper limits on command interfaces of joints, sensors and gpios from the
ros2_controltag in the robot description - clamps commands within the
write()function (e.g. limits position command using only min and max position limits, ignoring velocity and acceleration limits)
Layer plugin: layered_hardware/JointSaturationLimiterLayer
- based on
joint_limits::JointSaturationLimiter<joint_limits::JointLimits> - applies limits to all joint command interfaces within the
write()function
Hardware parameters
___
- map of parameter names and values for this layer
___
- topic name for robot description, from which joint limits are loaded
Layer plugin: layered_hardware/TransmissionLayer
- based on
transmittion_interface::Transmission - converts joint commands to actuator commands based on reduction ratio of transmission within
write()function - converts actuator states to joint states within
read()function
Layer plugin: layered_hardware/MockActuatorLayer
- implements mock {position, velocity, effort}-controlled actuators
- switches mock actuators’ command modes within
perform_command_mode_swtich()function when controllers using associated interfaces activate - changes actuator states based on commands within
write()function - useful to debug your command generation, state visualization nodes, or transmissions without physical actuators and dynamics simulators
Hardware parameters
___
- map of parameter names and values for this layer
___
- map of parameters for each mock actuator
___
- map to actuator command mode names (
position,velocity,effort) from associated interface names (typically joint interfaces)
Example of parameter description
<param name="example_mock_actuator_layer">
actuators:
example_actuator_1:
command_mode_map:
example_joint_1/position: position
...
example_actuator_2:
...
</param>
Layer plugin: layered_hardware/MonitorLayer
- prints changes on commands and states within
read()function for debug or logging purpose
Examples
Related packages
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | A ros_control implementation that adopts layered scheme |
| Checkout URI | https://github.com/yoshito-n-students/layered_hardware.git |
| VCS Type | git |
| VCS Version | jazzy |
| Last Updated | 2025-02-04 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| layered_hardware | 0.0.0 |
README
layered_hardware
A ros2_control implementation that adopts layered scheme
The layered scheme
- every ros2_control’s component (ex. joint_limits, transmissions) is implemented as a layer plugin (base_class: layered_hardware::LayerInterface)
- plugins of non-actuator-specific layers can be reused for different actuators
- multiple layers for different vendors’ actuators can be used in the same hardware

Hardware Plugin: layered_hardware/LayeredHardware
Hardware parameters
layers (yaml, required)
- sequence of layers to be loaded by this ros2_control hardware
layers[*].name (string, required)
- arbitary name of the layer
layers[*].type (string, required)
- valid type name of the layer
- the type must be exported to the layered_hardware package
- the base class of the type must be layered_hardware::LayerInterface
Example of ros2_control tag in your robot description
<ros2_control name="LayeredHardware" type="system">
<hardware>
<plugin>layered_hardware/LayeredHardware</plugin>
<param name="layers">
- name: example_layer_1
type: layered_hardware/ExampleLayer
- name: example_layer_2
...
...
</param>
...
</hardware>
...
</ros2_control>
Layer plugin: layered_hardware/CommandClamperLayer
- loads lower and upper limits on command interfaces of joints, sensors and gpios from the
ros2_controltag in the robot description - clamps commands within the
write()function (e.g. limits position command using only min and max position limits, ignoring velocity and acceleration limits)
Layer plugin: layered_hardware/JointSaturationLimiterLayer
- based on
joint_limits::JointSaturationLimiter<joint_limits::JointLimits> - applies limits to all joint command interfaces within the
write()function
Hardware parameters
___
- map of parameter names and values for this layer
___
- topic name for robot description, from which joint limits are loaded
Layer plugin: layered_hardware/TransmissionLayer
- based on
transmittion_interface::Transmission - converts joint commands to actuator commands based on reduction ratio of transmission within
write()function - converts actuator states to joint states within
read()function
Layer plugin: layered_hardware/MockActuatorLayer
- implements mock {position, velocity, effort}-controlled actuators
- switches mock actuators’ command modes within
perform_command_mode_swtich()function when controllers using associated interfaces activate - changes actuator states based on commands within
write()function - useful to debug your command generation, state visualization nodes, or transmissions without physical actuators and dynamics simulators
Hardware parameters
___
- map of parameter names and values for this layer
___
- map of parameters for each mock actuator
___
- map to actuator command mode names (
position,velocity,effort) from associated interface names (typically joint interfaces)
Example of parameter description
<param name="example_mock_actuator_layer">
actuators:
example_actuator_1:
command_mode_map:
example_joint_1/position: position
...
example_actuator_2:
...
</param>
Layer plugin: layered_hardware/MonitorLayer
- prints changes on commands and states within
read()function for debug or logging purpose
Examples
Related packages
File truncated at 100 lines see the full file