remove logical components, move hardware resources #201
Conversation
Signed-off-by: Karsten Knese <Karsten1987@users.noreply.github.com>
Karsten1987
force-pushed
the
remove_logical_components
branch
from
114e8b4
to
f566057
Compare
hardware_interface/include/hardware_interface/components/system.hpp
Outdated
Show resolved
Hide resolved
|
Please wait for my review this evening... thanks! |
hardware_interface/include/hardware_interface/components/system.hpp
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I have a few questions before merging:
- I see there are read/write functions missing? How are you planning to enable those?
- Since the hardware is parsing its interfaces, they should be somehow returned to the ResourceManager. I do not see those functions. Or are you planning to do something different?
- We agreed, we want to enable some kind of logical components, how we should call them then? Just "Joint"/"Sensor"?
| */ | ||
| HARDWARE_INTERFACE_PUBLIC | ||
| virtual | ||
| return_type read_joint(std::shared_ptr<components::Joint> joint) const = 0; |
There was a problem hiding this comment.
How the read is done now? Shouldn't we read to the "handles" here?
| HARDWARE_INTERFACE_PUBLIC | ||
| std::vector<std::string> get_state_interface_names() const; |
There was a problem hiding this comment.
Shouldn't we have those now in hardware? Or how are we doing interface-matching?
#164 depicts the roadmap I am planning to implement. The read functions are introduced in the second PR here: #203
The resource loaning is going to be implemented similar to #187 in which handles loaned to the controllers are unregistering themselves upon scope exit.
I think we agreed on the opposite to remove logical components (as the title of this PR says) and consider only hardware resources as components. The access to these handles is then done by re-using the existing "handles" we currently have. |
There was a problem hiding this comment.
I think we agreed on the opposite to remove logical components (as the title of this PR says) and consider only hardware resources as components. The access to these handles is then done by re-using the existing "handles" we currently have.
I think we are talking about the same thing, but currently I don't see anymore how we will implement those, or even better to say, how we should call them.
Just for the record:
- I am not 100% happy/convinced with renaming and removing "hardware" from the name, even though it is hardware representation on the end.
- I am afraid, we are getting to lock us in again as in ROS1
These are just my "feelings" and I cannot give you any sensible reason not to do this change, so I am approving this.
Thanks for the work and the explanations!
bmagyar
added this to In progress
in ros2_control new HW Interfaces design and examples in demo repository
via automation
bmagyar
moved this from In progress
to Done
in ros2_control new HW Interfaces design and examples in demo repository
Addresses the first block of #164
The logical components such as Joint and Sensors are removed. There are only physical components now, namely Actuator, Sensor and System. These three are moved under the
componentsnamespace accordingly.