[Example 10] RRbot with GPIO interfaces #256
Conversation
github-actions
bot
requested review from
aprotyas,
bmagyar,
destogl,
livanov93,
mcbed and
progtologist
christophfroehlich
force-pushed
the
example_10
branch
from
c0c4888 to
520e95d
Compare
Co-authored-by: Emiliano Borghi <[email protected]>
Co-authored-by: Sai Kishor Kothakota <[email protected]>
Co-authored-by: Sai Kishor Kothakota <[email protected]>
Co-authored-by: Sai Kishor Kothakota <[email protected]>
|
@Mergifyio backport humble |
✅ Backports have been created
|
* gpio controller for single interface * Use consistent topics for gpio_controller * Add parameters for gpio_controller interface names * Add URDF checks to hw interface * Add example_10 to CI * Add readme in example folder (cherry picked from commit 60b788f) # Conflicts: # .github/workflows/ci-coverage-build.yml # .github/workflows/ci-ros-lint.yml
* gpio controller for single interface * Use consistent topics for gpio_controller * Add parameters for gpio_controller interface names * Add URDF checks to hw interface * Add example_10 to CI * Add readme in example folder (cherry picked from commit 60b788f) # Conflicts: # .github/workflows/ci-coverage-build.yml # .github/workflows/ci-ros-lint.yml Co-authored-by: Christoph Fröhlich <[email protected]>
| for (auto state_if : info_.gpios.at(i).state_interfaces) | ||
| { | ||
| state_interfaces.emplace_back(hardware_interface::StateInterface( | ||
| info_.gpios.at(i).name, state_if.name, &hw_gpio_in_[ct++])); |
There was a problem hiding this comment.
I see that for GPIOs we don't really have a standard interface name so we're using whatever name is specified in the URDF. Would it make sense to create a new HW_IF_BOOLEAN interface type? I can create the issue.
I found myself needing this interface also when controlling an actuator so I think it could be generally useful. Opinions?
There was a problem hiding this comment.
we discussed something related to this in the last WG meeting: GPIO is now only for semantic reasons, and is of type double. Supporting other datatypes (boolean, or even ROS msgs) is a repeating topic but no one made a sustainable suggestion on how to implement it yet (or had time to make a PR)
You mean that we add a dedicated boolean GPIO in addition to "position", "velocity",..? then we would have only one possible boolean-gpio-interface per gpio-tag. Or you'd like to add a boolean-gpio-interface to the joints?
There was a problem hiding this comment.
Let me clarify by using the example 10, more specifically
<gpio name="flange_vacuum">
<command_interface name="vacuum"/>
<state_interface name="vacuum"/> <!-- Needed to know current state of the input -->
</gpio>
It doesn't make much sense to me how the command and state interface names of this GPIO are vacuum. Correct me if I'm wrong but to me a command/state interface is the "physics" type of the value (position, velocity.... possibly voltage, temperature....).
vacuum is ambiguous; does the value represent the suction strength? or whether it's on or off?
What I'm proposing is adding in hardware_interface_type_values.hpp a HW_IF_BOOLEAN (or similarly named) to represent a common state/command interface not only for GPIOs, but also to joints and sensors.
I guess this leads to what you mentioned then:
Supporting other datatypes (boolean, or even ROS msgs) is a repeating topic but no one made a sustainable suggestion on how to implement it yet (or had time to make a PR)
There was a problem hiding this comment.
I totally agree, the interface vacuum could be named more specifically.
But by just adding a boolean to the list would only allow one state- or command interface of this type per sensor/joint/GPIO component in this form:
<gpio name="flange_vacuum">
<command_interface name="boolean"/>
<state_interface name="boolean"/>
</gpio>
Using a component with a set of boolean gpios is not possible then (think of an 8 bit digital input card)
I took the description from a ros2_control test and added a simple GPIO controller.
Is there anything more to present with GPIO interfaces?
Closes #149