No version for distro humble showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro ardent showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro bouncy showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro crystal showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro eloquent showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro dashing showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro galactic showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro foxy showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro iron showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro lunar showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro jade showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro indigo showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro hydro showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro kinetic showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro melodic showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange

No version for distro noetic showing jazzy. Known supported distros are highlighted in the buttons above.

Package Summary

Version 1.1.0
License Apache License 2.0
Build type AMENT_CMAKE
Use RECOMMENDED

Repository Summary

Checkout URI https://github.com/ros-controls/topic_based_hardware_interfaces.git
VCS Type git
VCS Version main
Last Updated 2026-09-10
Dev Status DEVELOPED
Released RELEASED
Contributing Help Wanted (-)
Good First Issues (-)
Pull Requests to Review (-)

Package Description

ros2_control hardware interface for JointCommand topic based control

Additional Links

Maintainers

  • Marq Rasmussen
  • Bence Magyar
  • Christoph Froehlich

Authors

  • Kamalkant Thangaraju

Joint Command Topic Based System

The Joint Command Topic Based System implements a ros2_control hardware_interface::SystemInterface supporting command and state interfaces through the ROS topic communication layer. It publishes commands as control_msgs/JointCommand messages, one topic per interface type. Only position, velocity and effort command interfaces are supported, anything else is ignored with a warning.

ros2_control urdf tag

The joint_command_topic_hardware_interface has a few ros2_control urdf tags to customize its behavior.

Parameters

  • joint_commands_topic: (default: “/robot_joint_commands”). Base topic for the joint command topics. Example: <param name="joint_commands_topic">/my_topic_joint_commands</param>.
  • joint_states_topic: (default: “/robot_joint_states”). Example: <param name="joint_states_topic">/my_topic_joint_states</param>.
  • trigger_joint_command_threshold: (default: 1e-5). Used to avoid spamming the joint command topic when the difference between the current joint state and the joint command is smaller than this value, set to -1 to always send the joint command. Example: <param name="trigger_joint_command_threshold">0.001</param>.
  • sum_wrapped_joint_states: (default: “false”). Used to track the total rotation when the position values reported on the joint_states_topic wrap from 2pi to -2pi when rotating in the positive direction. (Isaac Sim only reports joint states from 2pi to -2pi) Only position states are affected. Example: <param name="sum_wrapped_joint_states">true</param>.

Mimic joints

Often used with parallel grippers. The relation is declared in the URDF, not with ros2_control params:

<joint name="joint2" type="revolute">
    <mimic joint="joint1" multiplier="-2" offset="0"/>
    ...
</joint>

Then mark the joint with mimic="true" and give it state interfaces only. Its states come from the mimicked joint instead of the joint_states_topic:

<joint name="joint2" mimic="true">
    <state_interface name="position"/>
    <state_interface name="velocity"/>
</joint>

offset only applies to position. velocity and acceleration use multiplier alone.

Example

        <ros2_control name="name" type="system">
            <hardware>
              <plugin>joint_command_topic_hardware_interface/JointCommandTopicSystem</plugin>
              <param name="joint_commands_topic">/topic_based_joint_commands</param>
              <param name="joint_states_topic">/topic_based_joint_states</param>
            </hardware>
            <joint name="joint_1">
                <command_interface name="position"/>
                <command_interface name="velocity"/>
                <state_interface name="position">
                  <param name="initial_value">0.0</param>
                </state_interface>
                <state_interface name="velocity"/>
            </joint>
            ...
        </ros2_control>

Topics

Each write() publishes one control_msgs/JointCommand per interface type, on topics derived from joint_commands_topic:

  • <joint_commands_topic>/position: joints with a driven position command.
  • <joint_commands_topic>/velocity: joints with a driven velocity command.
  • <joint_commands_topic>/effort: joints with a driven effort command.

joint_names and values line up, interface_name repeats the interface. With the defaults, a joint with position and velocity commands publishes to /robot_joint_commands/position and /robot_joint_commands/velocity.

Command interfaces that no controller writes to hold NaN. Those joints are dropped from the message, and if nothing drives an interface type at all its topic stays quiet. Declaring a command interface is not enough to get traffic on the matching topic.

Nothing is published while the summed state-command difference stays at or below trigger_joint_command_threshold, which is the normal case once a controller has converged. Set it to -1 to publish every cycle.

QoS

Command publishers are reliable with a depth of 1, so don’t count on them to buffer.

The joint_states_topic subscription uses SensorDataQoS (best effort, depth 5), which any joint state publisher can match.

CHANGELOG
No CHANGELOG found.

Dependant Packages

No known dependants.

Launch files

No launch files found

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged joint_command_topic_hardware_interface at Robotics Stack Exchange