Revision history [back]

Forced to use EffortJointInterface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify if we are forced to use EffortJointInterface when using the transmission tag in URDF?

And is the transmission tag required when working with ros_control?

According to the C++ API documentation:

The transmission_interface is not used by controllers themselves (it does not implement a HardwareInterface) but instead operates before or after the controllers update, in the read() and write() methods (or equivalents) of the robot abstraction.

Forced to use EffortJointInterface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify if why we are forced to should use EffortJointInterface when using the transmission tag in URDF?

And is the transmission tag required when working with ros_control?

According to the C++ API documentation:

The transmission_interface is not used by controllers themselves (it does not implement a HardwareInterface) but instead operates before or after the controllers update, in the read() and write() methods (or equivalents) of the robot abstraction.

Forced to use EffortJointInterface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify why we should use EffortJointInterface when using the transmission tag in URDF?

And When and why is the transmission tag required when working with ros_control?

According to the C++ API documentation:

The transmission_interface is not used by controllers themselves (it does not implement a HardwareInterface) but instead operates before or after the controllers update, in the read() and write() methods (or equivalents) of the robot abstraction.

Forced to use EffortJointInterface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify why we should use EffortJointInterface when using the transmission tag in URDF?

When and why is the transmission tag required when working with ros_control?

According to the C++ API documentation:

The transmission_interface is not used by controllers themselves (it does not implement a HardwareInterface) but instead operates before or after the controllers update, in the read() and write() methods (or equivalents) of the robot abstraction.

Can the transmision tag be omitted or is it always required?

Forced to use EffortJointInterface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify why we should use EffortJointInterface when using the transmission tag in URDF?

When and why is the transmission tag required when working with ros_control?

According to the C++ API documentation:

The transmission_interface is not used by controllers themselves (it does not implement a HardwareInterface) but instead operates before or after the controllers update, in the read() and write() methods (or equivalents) of the robot abstraction.

Can the transmision tag be omitted or is it always required?

Forced to Why should we use EffortJointInterface as hardware_interface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify why we should use EffortJointInterface when using the transmission tag in URDF?

When and why is the transmission tag required when working with ros_control?

According to the C++ API documentation:

The transmission_interface is not used by controllers themselves (it does not implement a HardwareInterface) but instead operates before or after the controllers update, in the read() and write() methods (or equivalents) of the robot abstraction.

Can the transmision tag be omitted or is it always required?

Actuators are connected to joints via mechanical transmissions, and you need to use them if you want ros_control to handle the mapping between joint and actuator spaces.

Why should we use EffortJointInterface as hardware_interface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify why we should use EffortJointInterface when using the transmission tag in URDF?

When and why is the transmission tag required when working with ros_control?

According to the C++ API documentation:

The transmission_interface is not used by controllers themselves (it does not implement a HardwareInterface) but instead operates before or after the controllers update, in the read() and write() methods (or equivalents) of the robot abstraction.

Can the transmision tag be omitted or is it always required?

Actuators are connected to joints via mechanical transmissions, and you need to use them if you want ros_control to handle the mapping between joint and actuator spaces.

This raises a new questions: How does ROS define joint and actuator space? And is it possible to work only in the joint space using just JointCommandInterface and JointStateInterface?

Why should we use EffortJointInterface as hardware_interface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify why we should use EffortJointInterface when using the transmission tag in URDF?

When and why is the transmission tag required when working with ros_control?

According to the C++ API documentation:

The transmission_interface is not used by controllers themselves (it does not implement a HardwareInterface) but instead operates before or after the controllers update, in the read() and write() methods (or equivalents) of the robot abstraction.

Can the transmision tag be omitted or is it always required?

Actuators are connected to joints via mechanical transmissions, and you need to use them if you want ros_control to handle the mapping between joint and actuator spaces.

This raises a new questions: How does ROS define joint and actuator space? And is it possible to work only in the joint space using just JointCommandInterface and JointStateInterface?

Why should we use EffortJointInterface as hardware_interface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify why we should use EffortJointInterface when using the transmission tag in URDF?

When and why is the transmission tag required when working with ros_control?

According to the C++ API documentation:

The transmission_interface is not used by controllers themselves (it does not implement a HardwareInterface) but instead operates before or after the controllers update, in the read() and write() methods (or equivalents) of the robot abstraction.

Can the transmision tag be omitted or is it always required?

Actuators are connected to joints via mechanical transmissions, and you need to use them if you want ros_control to handle the mapping between joint and actuator spaces.

This raises new questions: How does ROS define joint and actuator space? And is it possible to work only in the joint space using just JointCommandInterface and JointStateInterface?

Why should we use EffortJointInterface as hardware_interface for transmission in URDF?

Reading the urdf/Transmission documentation, I am confused by the following statement:

<hardwareInterface> (one or more occurrences)

Specifies a supported joint-space hardware interface. Note that the value of this tag should be EffortJointInterface when this transmission is loaded in Gazebo and hardware_interface/EffortJointInterface when this transmission is loaded in RobotHW.

To me this reads as if we are forced to use EffortJointInterface when working with Gazebo and hardware_interface/EffortJointInterface when working with real robot hardware. However, I know that there are other hardware interfaces, inheriting also from CommandJointInterface such as PositionJointInterface and VelocityJointInterface.

Could someone please clarify why we should use EffortJointInterface when using the transmission tag in URDF?