Automatic Creation of Handles in HW, Adding Getters/Setters (variant support) #1688
Conversation
github-actions
bot
requested review from
aprotyas,
bmagyar,
DasRoteSkelett,
destogl,
fmauch,
olivier-stasse and
peterdavidfagan
mamueluth
changed the title
There was a problem hiding this comment.
@mamueluth I have a question wrt to new way to exporting interfaces, how are they going to integrate now if we use Transmissions?, because earlier, the I believe the current approach is they have pointers to separate variables and then they are swapped later, so I believe we do it same way but using the getter and setter methods?JointHandle of Transmission and that of the StateInterface or CommandInterface share the same variable pointer, so, Just calling the methods actuator_to_joint and joint_to_actuator to have the transformations and it would be directly reflected on the respective interface data
Could you please explain what would be the procedure for those who use transmissions?. I'm asking because we are one of the active users of Transmissions on our robots
|
This pull request is in conflict. Could you fix it @mamueluth? |
hardware_interface/include/hardware_interface/actuator_interface.hpp
Outdated
Show resolved
Hide resolved
| @@ -608,46 +608,71 @@ class ResourceStorage | |||
| template <class HardwareT> | |||
| void import_state_interfaces(HardwareT & hardware) | |||
| { | |||
| try | |||
| std::vector<std::string> interface_names; | |||
| std::vector<StateInterface::SharedPtr> interfaces = hardware.export_state_interfaces(); | |||
There was a problem hiding this comment.
can here an exception happen? If yes, we should handle it. I would anyway handle it as the user might cause an exception with their custom implementation.
We should probably do it as before and put everything into try-catch block.
| { | ||
| interface_ptrs.push_back(std::make_shared<StateInterface>(interface)); | ||
| } | ||
| auto interface_names = resource_storage_->add_state_interfaces(interface_ptrs); |
There was a problem hiding this comment.
can we use this method also for hardware? If yes, then we can avoid completely having add_state_interface and compatible method for commands?
| interface_names.reserve(interfaces.size()); | ||
| for (auto const & interface : interfaces) | ||
| { | ||
| auto interfaces = hardware.export_state_interfaces(); | ||
| std::vector<std::string> interface_names; | ||
| interface_names.reserve(interfaces.size()); | ||
| for (auto & interface : interfaces) | ||
| try | ||
| { | ||
| interface_names.push_back(add_state_interface(interface)); | ||
| } |
There was a problem hiding this comment.
I think we don't have to itterate here, but can just use:
add_state_interfaces(interfaces);
Then we can remove the add_state_interface method, to peel off one layer 😄
There was a problem hiding this comment.
done, boss!
I kept the add_state_interface() method for now though
| @@ -1389,7 +1465,7 @@ LoanedCommandInterface ResourceManager::claim_command_interface(const std::strin | |||
| resource_storage_->claimed_command_interface_map_[key] = true; | |||
| std::lock_guard<std::recursive_mutex> guard(resource_interfaces_lock_); | |||
| return LoanedCommandInterface( | |||
| resource_storage_->command_interface_map_.at(key), | |||
| *(resource_storage_->command_interface_map_.at(key)), | |||
There was a problem hiding this comment.
why do we need here to dereference this? Don't we provide also a SharedPtr to the Loaned interfaces, as they manage the access?
There was a problem hiding this comment.
Is this moved from another file? If not, please adjust the license.
There was a problem hiding this comment.
Is this moved from another file? If not, please adjust the license.
hardware_interface/test/test_component_interfaces_custom_export.cpp
Outdated
Show resolved
Hide resolved
hardware_interface/test/test_component_interfaces_custom_export.cpp
Outdated
Show resolved
Hide resolved
hardware_interface/test/test_component_interfaces_custom_export.cpp
Outdated
Show resolved
Hide resolved
hardware_interface/test/test_component_interfaces_custom_export.cpp
Outdated
Show resolved
Hide resolved
hardware_interface/test/test_component_interfaces_custom_export.cpp
Outdated
Show resolved
Hide resolved
hardware_interface/test/test_component_interfaces_custom_export.cpp
Outdated
Show resolved
Hide resolved
hardware_interface/test/test_component_interfaces_custom_export.cpp
Outdated
Show resolved
Hide resolved
Co-authored-by: Christoph Fröhlich <christophfroehlich@users.noreply.github.com>
Co-authored-by: Dr. Denis <denis@stoglrobotics.de> Co-authored-by: Christoph Fröhlich <christophfroehlich@users.noreply.github.com>
Co-authored-by: Christoph Fröhlich <christophfroehlich@users.noreply.github.com>
There was a problem hiding this comment.
Now CI looks good. And I tested it with ros-controls/ros2_control_demos#396
This PR is the fourth part of multiple breaking down #1240 in smaller changes. For an overview explanation and a lot of comments/discussion, please refer to #1240.
This PR is the main work of preparing the Handles, ControllerManager (cm) and ResourceManager (rm) for the full variant support. This PR introduces the creation of Command-/StateInterfaces (ci/si) by the Framework itself rather than by the a user who want to implement a HardwareInterface. The ci/si are created by the base class e.g. ActuatorInterface, SensorInterface or SystemInterface. The ci/si are now created as shared_ptr and a shared_ptr is passed to rm. This needs to be done since in future the pointer of the value from each ci/si is replaced by a value inside the handle itself. In order for the hardware still be able to set/get values from a handle they need to have access to them. Since we decided not to share back loans to the hardware as is done with controllers we now pass shared_ptrs to rm and keep a shared_ptr of the ci/si in the hardwares base class (ActuatorInterface, SensorInterface or SystemInterface) inside a unordered_map. The hardware can then access the ci/si through
get_state()andset_state()methods based on the interfaces full name.Needs Adapt test to new way of exporting reference interfaces (Related to #1240 in ros2_control) ros2_controllers#1103 to be merged as wellThis was fake news. 😅 Only needed in followup PR.NOTE: Everything is fully backward compatible at this point. The old way of exporting and creating handles with pointers is still available. Variant supports only double at this point. Only if InterfaceDescription for creation of Hanles is used the ptr is set to the internal variant.