Components architecture and examples.#22
Conversation
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Karsten1987
left a comment
There was a problem hiding this comment.
In principle this looks good to me. I think we need more flesh to this though to describe things in more detail.
I think use-cases can be shifted around, maybe even combined - thinking about 1 & 4 as well as 6 & 7 & 8. Within these blocks, only the difference could be then highlighted.
|
|
||
| ![ros2_control Components Achitecture][ros2_control_arch_resource_manager] | ||
|
|
||
| [ros2_control_arch_resource_manager]: images/components_architecture.png "ROS2 Control - Components Architecture" |
There was a problem hiding this comment.
Not sure how to comment on the image, so I'll do it here:
I think it's an implementation detail to mention "ActuatorHardwareInterface" and would remove that row of boxes with "template to implement ..."
There was a problem hiding this comment.
As for wording, I know it's a constant bike shedding, but I don't see the point to add "Hardware" to "ActuatorHardware". Same for sensors and systems.
However, what this document lacks in my opinion is a general introduction/motivation and explanation of wording. Basically saying what's meant with "actuator", what's a system etc. Basically explaining the vision. Saying that a robot hardware with a basic main loop had to be written for ROS1, the goal here with ROS2 is to create an architecture to dynamically compose a robot.
There was a problem hiding this comment.
Not sure how to comment on the image, so I'll do it here:
I think it's an implementation detail to mention "ActuatorHardwareInterface" and would remove that row of boxes with "template to implement ..."
I wanted to have this implementation detail in it. The image is something between implementation UML and architecture and I hope for a user would be clear where to starts its implementation.
As for wording, I know it's a constant bike shedding, but I don't see the point to add "Hardware" to "ActuatorHardware". Same for sensors and systems.
I did it mainly to make a difference between "Joint" and "Sensor" on the right side, and those implementations of interfacing the hardware directly. This wording is in line with ROS1 ros_control with RobotHardware and RobotHardwareInterface.
However, what this document lacks in my opinion is a general introduction/motivation and explanation of wording. Basically saying what's meant with "actuator", what's a system etc.
I agree with you. My intention of current state of PR is to clarify the URDF structures, so we can start implement this in the main repository.
|
|
||
| ## URDF Examples | ||
|
|
||
| ros2_control implementation examples are presented for the following robot/robot-cell architectures: |
There was a problem hiding this comment.
What is the proper English term for a fenced area where robot is, usually with other machines like feeders, doing his thing? image
In German is called "RoboterZellle". Therefore, I thought "cell" is a good term.
There was a problem hiding this comment.
Caged robots is the common term in English I believe
|
|
||
| Note: | ||
| * Everything within the `<classType>` tag is implemented as a plugin. | ||
| * The examples below have some `<param>` tags defined for each plugin which are primarily for demonstration, not part of a pre-defined xml schema. Components can define their own parameters. |
There was a problem hiding this comment.
I don't understand this. The param tag should be part of the xml schema - otherwise this tag wouldn't be allowed. I think what you want to mention is that the attributes and values are free to be chosen per plugin, is that right?
But we have to maybe clarify how these parameters are being used. Saying how each plugin is supposed to obtain these parameters.
There was a problem hiding this comment.
I reword this. Is it better now?
But we have to maybe clarify how these parameters are being used.
This would be done in the example implementation.
| <param name="example_param_write_for_sec">2</param> | ||
| <param name="example_param_read_for_sec">2</param> | ||
| </hardware> | ||
| <joint name="joint1"> |
There was a problem hiding this comment.
I know we've talked about this and you don't like it, but I think it is clearer here to replace "joint" with "joint_handle" or something similar to emphasize that this joint is purely virtual and abstract to any hardware specific implementation.
There was a problem hiding this comment.
this joint is purely virtual and abstract to any hardware specific implementation
I do not agree. On this level, in the RessourceManager all joints are actually the real joints of the hardware. First when we go into ControllerManager virtual joints are used. (This is also shown, not in full detail, in the image)
There was a problem hiding this comment.
Then I still don't understand what's happening with joints. In my understanding, the term joint here described something abstract which encapsulates common pattern like joint limits etc before these values are then finally passed to the system implementation.
There was a problem hiding this comment.
There's the forward facing XML format we are trying to set up and the code that this will eventually tie into. I would 100% consider joint_handle an implementation detail nobody should care about when defining/reading a URDF. No matter how this is implemented, the URDF should never refer to handles, let's keep it at the abstract terms level.
| Note: | ||
| * `ros2_control_components/PositionJoint`type has implicitly: | ||
| ```xml | ||
| <commandInterfaceType>position</commandInterfaceType> | ||
| <stateInterfaceType>position</stateInterfaceType> | ||
| ``` |
There was a problem hiding this comment.
I wonder if this note should come later in the document as we've never mentioned "commandInterface" up to this point.
There was a problem hiding this comment.
We should add some general description at the beginning.
| <param name="max_values">1</param> | ||
| </joint> | ||
| </ros2_control> | ||
| <ros2_control name="2DOF_System_Robot_ForceTorqueSensor" type="sensor"> |
There was a problem hiding this comment.
I think it deserves a bit more context or description that we have two separate ros2_control tags in here and thus treat the two components individually.
Co-authored-by: Karsten Knese <Karsten1987@users.noreply.github.com>
Co-authored-by: Karsten Knese <Karsten1987@users.noreply.github.com>
Co-authored-by: Karsten Knese <Karsten1987@users.noreply.github.com>
after testing them with parser in ros-controls/ros2_control#127
|
follow-up: #23 |
No description provided.