Conversation
| <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface> | ||
| <hardwareInterface>awesome_interface/FooJointInterface</hardwareInterface> | ||
| <role></role> | ||
| <actuator> |
There was a problem hiding this comment.
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
| 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`. |
There was a problem hiding this comment.
The "Note the..." sentence was supposed to highlight an important difference, let's keep it.
| ... | ||
| 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). |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
If you wanna reference another doc, please link it.
|
ping @Karsten1987 to move this over to a new design draft about a new URDF tag for ros_control |
2 participants
A first take on refining the transmission schema. It basically picks up the nomenclature from introduced in #10 to separate a robot hardware into actuators and sensors.
the
hardware_interfacetag takes an optionalname(alternativelyidentifierto go on pair with the flexible joint state design doc) attribute which allows for a custom identifier to be chosen.I've also removed details for the robot hardware because I think this part should live within #10.