Skip to content
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

Add description of "gpio"-tag #38

Merged
merged 1 commit into from
Apr 7, 2021
Merged

Add description of "gpio"-tag #38

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
133 changes: 133 additions & 0 deletions design_drafts/non_joint_command_interfaces.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,133 @@
# Definition of command interfaces for non-joint related information

## Motivation
Already multiple times, users raised the question about the handling of non-joint-related interfaces.
Such interfaces are not considerd during [design of the ros2_control URDF-tag structure](./components_architecture_and_urdf_examples.md).
The design proposes two possibilities to classify (group) the interfaces, using `<joint>` and `<sensor>` tags.
`<joint>`-tag groups the interfaces associated with the joints of physical robots and actuators.
They have command and state interfaces to set the goal values for hardware and read its current state.
`<sensor>`-tag groups multiple state interfaces describing, e.g., internal states of hardware.

Most modern robots, especially industrial manipulators, also have other physical ports to control external hardware.
The most usual ones are General Purpose Inputs/Outputs (GPIOs).
Although the strict definition considers only digital ports, the term GPIO in this document describes any (one-dimensional) input/output port of physical hardware, e.g., digital or analog input/output.

## Problem
To use GPIOs in the ros2_control framework, they have to be listed in the robot's URDF: inputs (state interfaces) under a `<sensor>`-tag and output (command and state interfaces) under a `<joint>`-tag.
This could lead to confusion since non-existing (virtual) joints have to be defined in the ros2_control part of the URDF structure.
"Joint" is a well-defined term in robotics. Therefore this naming should be avoided, i.e., another keyword should be used describing GPIOs, semantically separating them from the kinematics joints.

## Proposed solution
Use of keyword "gpio" when describing input and output ports of a robotic device that cannot be associated with any joint or sensor.
Parsing of `<gpio>-tag` is similar to this of a `<joint>`-tag having command and state interfaces.
The tag must have at least one `<command>`- or `<state>`-tag as a child.

The keyword "gpio" is chosen for its generality.
Although strictly used for digital signals, in this document describes any electrical analog, digital signal, or physical value.
Comment on lines +25 to +26
Copy link

Choose a reason for hiding this comment

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

GPIO as an acronym has a fairly well established meaning. See wikipedia/GPIO for instance.

Is the intention to use it like that in ros2_control, or is it even more general?

The text is slightly ambiguous, as in some places it states that the gpio tag should/could be used for anything which is not a joint or a sensor, but in other places (like here) it limits it to the more traditional meaning of the term (ie: "an uncommitted digital signal pin on an integrated circuit or electronic circuit board which may be used as an input or output, or both, and is controllable by the user at runtime" (Wikipedia)).

Copy link
Member Author

Choose a reason for hiding this comment

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

@gavanderhoorn This is a very good point.

For clarification. We would like to use it for everything which has not "a physical" signal. The usual use-case would be digital and analog input outputs on a robot that can not be related to any joint or sensors.

Is the intention to use it like that in ros2_control, or is it even more general?

The use is more general because it also describes analog signals.

Copy link

@gavanderhoorn gavanderhoorn Mar 10, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

We would like to use it for everything which has not "a physical" signal.

That seems to contradict what's in the document right now (emphasis mine):

Although strictly used for digital signals, in this document describes any electrical analog, digital signal, or physical value.

Perhaps you mean something else?

The usual use-case would be digital and analog input outputs on a robot that can not be related to any joint or sensors.

well, anything which you connect to a digital computer in the end is represented by digital input outputs. So this doesn't seem to say very much.

I understand why you went with gpio, but to me, it it's either not specific enough, or it's too generic.

And the given rationale and use-case seem a bit narrow as well: why only robots? What about using ros2_control for something which is not (directly) considered a robot?


The `<gpio>` tag can be used as a child of all three types of hardware interfaces, i.e., system, sensor, or actuator.
Semantically, they describe values that can not be associated with a joint or a sensor.

### Examples

1. Robot with multiple GPIO interfaces
- RRBot System
- Digital: 4 inputs and 2 outputs
- Analog: 2 inputs and 1 output
- Vacuum valve at the flange (on/off)

```
<ros2_control name="RRBotSystemMutipleGPIOs" type="system">
<hardware>
<plugin>ros2_control_demo_hardware/RRBotSystemPositionOnlyHardware</plugin>
<param name="example_param_hw_start_duration_sec">2.0</param>
<param name="example_param_hw_stop_duration_sec">3.0</param>
<param name="example_param_hw_slowdown">2.0</param>
</hardware>
<joint name="joint1">
<command_interface name="position">
<param name="min">-1</param>
<param name="max">1</param>
</command_interface>
<state_interface name="position"/>
</joint>
<joint name="joint2">
<command_interface name="position">
<param name="min">-1</param>
<param name="max">1</param>
</command_interface>
<state_interface name="position"/>
</joint>
<gpio name="flange_digital_IOs>
<command_interface name="digital_output1"/>
<state_interface name="digital_output1"/> <!-- Needed to know current state of the output -->
<command_interface name="digital_output2"/>
<state_interface name="digital_output2"/>
<state_interface name="digital_input1"/>
<state_interface name="digital_input2"/>
</gpio>
<gpio name="flange_analog_IOs>
<command_interface name="analog_output1"/>
<state_interface name="analog_output1"/> <!-- Needed to know current state of the output -->
<state_interface name="analog_input1"/>
<state_interface name="analog_input2"/>
</gpio>
<gpio name="flange_vacuum>
<command_interface name="vacuum"/>
<state_interface name="vacuum"/> <!-- Needed to know current state of the output -->
</gpio>
</ros2_control>
```

2. Gripper with electrical and suction grasping possibilities
- Multimodal gripper
- 1-DoF parallel gripper
- suction on/off

```
<ros2_control name="MultimodalGripper" type="actuator">
<hardware>
<plugin>ros2_control_demo_hardware/MultimodalGripper</plugin>
</hardware>
<joint name="parallel_fingers">
<command_interface name="position">
<param name="min">0</param>
<param name="max">100</param>
</command_interface>
<state_interface name="position"/>
</joint>
<gpio name="suction>
<command_interface name="suction"/>
<state_interface name="suction"/> <!-- Needed to know current state of the output -->
</gpio>
</ros2_control>
```

3. Force-Torque-Sensor with temperature feedback and adjustable calibration
- 2D FTS
- Temperature feedback in °C
- Choice between 3 calibration matrices, i.e., calibration ranges

```
<ros2_control name="RRBotForceTorqueSensor2D" type="sensor">
<hardware>
<plugin>ros2_control_demo_hardware/ForceTorqueSensor2DHardware</plugin>
<param name="example_param_read_for_sec">0.43</param>
</hardware>
<sensor name="tcp_fts_sensor">
<state_interface name="fx"/>
<state_interface name="tz"/>
<param name="frame_id">kuka_tcp</param>
<param name="fx_range">100</param>
<param name="tz_range">100</param>
</sensor>
<sensor name="temp_feedback">
<state_interface name="temperature"/>
</sensor>
<gpio name="calibration">
<command_interface name="calibration_matrix_nr"/>
<state_interface name="calibration_matrix_nr"/>
</gpio>
</ros2_control>
```