Skip to content

Extend transmission urdf schema #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Karsten1987 wants to merge 1 commit into from
Closed

Extend transmission urdf schema #19

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 39 additions & 31 deletions design_drafts/joint_interfaces_and_transmissions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,49 +35,57 @@ and ties in with the use of the [flexible joint states message](https://github.c
## Proposal

### urdf
Over the years we didn't receive any feedback about the URDF notation being good/bad which means it's not currently a pain point for anyone at the moment, this design will not propose any changes to that.
Let's stick with the notation:

```
<transmission name="extended_simple_trans">
<type>transmission_interface/ExtendedSimpleTransmission</type>
<joint name="joint1">
<offset>0.0</offset>
<hardwareInterface>hardware_interface/PositionJointInterface</hardwareInterface>
<hardwareInterface>hardware_interface/VelocityJointInterface</hardwareInterface>
<hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
<hardwareInterface>awesome_interface/FooJointInterface</hardwareInterface>
<role></role>
<actuator>
Copy link
Copy Markdown
Member

@bmagyar bmagyar May 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This updated version is a little too ad-hoc.

You gotta have joints and actuators. With names and all that which you forgot to add. Also, I added an example of simpletransmission here as this one only defines a 1-to-1 relationship, we can highlight additional sensors but let's not have multiple joints and actuators in it.

Here's a ref you can use to establish a more complex example: https://github.com/pal-robotics/tiago_robot/blob/kinetic-devel/tiago_description/urdf/arm/wrist.transmission.xacro#L28

<!-- control input (u) for the joint, i.e. effort/torque value -->
<hardwareInterface>hardware_interface/EffortJointCommandInterface</hardwareInterface>
</actuator>
<sensor>
<!-- output state (x) from the joint, e.g. position -->
<hardwareInterface>hardware_interface/PositionJointInterface</hardwareInterface>
<!-- output state (x_dot) from the joint, e.g. velocity -->
<hardwareInterface>hardware_interface/VelocityJointInterface</hardwareInterface>
<!-- output state (x_dot_dot) from the joint, e.g. acceleration -->
<hardwareInterface>hardware_interface/AccelerationJointInterface</hardwareInterface>
</sensor>
</joint>
<joint name="joint2">
<actuator>
<hardwareInterface>hardware_interface/EffortJointCommandInterface</hardwareInterface>
</actuator>
<sensor>
<hardwareInterface>hardware_interface/PositionJointInterface</hardwareInterface>
<hardwareInterface>hardware_interface/VelocityJointInterface</hardwareInterface>
<hardwareInterface>hardware_interface/AccelerationJointInterface</hardwareInterface>
</actuator>
</joint>
<joint>
<actuator>
<!-- control input (u) for the joint, i.e. velocity value -->
<hardwareInterface>hardware_interface/VelocityJointCommandInterface</hardwareInterface>
</actuator>
<sensor>
<!-- custom output state (x) for the joint, i.e. some custom value such as current
<hardwareInterface name="current_joint_interface">hardware_interface/CustomValueInterface</hardwareInterface>
</sensor>
</joint>
<actuator name="actuator1">
<mechanicalReduction>50</mechanicalReduction>
</actuator>
</transmission>
```
The content of a `hardwareInterface` XML attribute should match up with strings provided by `ros2_control` in the shape of familiar names:

The content of a `hardwareInterface` XML tag should match up with strings provided by `ros2_control` in the shape of familiar names:
`hardware_interface::PositionJointInterface, hardware_interface::VelocityJointInterface, hardware_interface::EffortJointInterface`.
By relying on strings internally in the framework but using them mostly through shared names, a standard nomenclature is kept all the while allowing custom extensions in an easy and transparent way.
Note the in the example above, since all names are merely strings, `awesome_interface/FooJointInterface` - a custom interface - can be used if it is provided by the `RobotHardware`.
Copy link
Copy Markdown
Member

@bmagyar bmagyar May 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "Note the..." sentence was supposed to highlight an important difference, let's keep it.

By relying on strings internally in the framework but using them mostly through shared names, a standard nomenclature is kept all the while allowing custom extensions in an easy and transparent way.

### RobotHardware

```
void RobotHardware::declareInterface(string name);
```
or
```
void RobotHardware::registerInterface(string interface_name, string joint_name);
```

a possible automated way adding these to the `RobotHardware` is to declare them when
```
template<class... interfaces>
class RobotHardware{};
...
MyRobotHW : public RobotHardware<hardware_interface::PositionJointInterface, hardware_interface::VelocityJointInterface>
```
Based on the URDF snippet above, the instance of a robot hardware can be generated as described in the [hardware interface design doc](hardware_interface.md).
Copy link
Copy Markdown
Member

@bmagyar bmagyar May 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is largely misleading. The role of transmission parsing was never to set up an instance of robothw but to check whether a required transmission's requirements are met by the robothw which in this case serves as a HAL (hardware abstraction layer) and if it's green-lit, instantiate transmissions by "wiring" all relevant joint and actuator handles up.

However we provide a ton of tools for it and even reference (boilerplate) implementations for it, whoever implements ros2_control for their robot still holds the responsibility of setting up this HAL as that's territory we can't reasonably guess the details of.

I agree though that the content in this section is a bit of a braindump of mine.


Initially, controller and transmission loader checks could happen through a list of registered interfaces.
Once all requirements are there, this can also manifest in a few entries being added to the shared flexible joint state message instance, removing the need for a separate "registry" of interfaces.
The transmission parser is being used to set up and configure the robot hardware accordingly.
Refer to the design doc for more information.
Copy link
Copy Markdown
Member

@bmagyar bmagyar May 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you wanna reference another doc, please link it.


### Transmissions

Expand Down