Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic Creation of Handles in HW, Adding Getters/Setters (variant support) #1688

Conversation

mamueluth
Copy link
Member

@mamueluth mamueluth commented Aug 16, 2024

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() and set_state()methods based on the interfaces full name.

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.

  • @bmagyar it will get smaller as soon as the parts before is merged but it will still remain a quite big PR. Can you please check if you think we should split this up further?

Copy link
Member

@saikishor saikishor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 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 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?

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

Copy link
Contributor

mergify bot commented Aug 21, 2024

This pull request is in conflict. Could you fix it @mamueluth?

doc/Iron.rst Outdated Show resolved Hide resolved
doc/Iron.rst Outdated Show resolved Hide resolved
doc/Iron.rst Outdated Show resolved Hide resolved
doc/Iron.rst Outdated Show resolved Hide resolved
doc/Iron.rst Outdated Show resolved Hide resolved
doc/Iron.rst Outdated Show resolved Hide resolved
destogl
destogl previously approved these changes Sep 24, 2024
Copy link
Member

@destogl destogl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some small cosmetic changes, but don't have to be done from my side. We should follow up on them in the future.

hardware_interface/src/resource_manager.cpp 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();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we use this method also for hardware? If yes, then we can avoid completely having add_state_interface and compatible method for commands?

Comment on lines 614 to 620
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));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 😄

Copy link
Member

@bmagyar bmagyar Sep 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need here to dereference this? Don't we provide also a SharedPtr to the Loaned interfaces, as they manage the access?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this moved from another file? If not, please adjust the license.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this moved from another file? If not, please adjust the license.

Copy link
Contributor

@christophfroehlich christophfroehlich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should fix the precommit issues.

Co-authored-by: Christoph Fröhlich <christophfroehlich@users.noreply.github.com>
bmagyar and others added 4 commits September 25, 2024 19:01
Co-authored-by: Dr. Denis <denis@stoglrobotics.de>
Co-authored-by: Christoph Fröhlich <christophfroehlich@users.noreply.github.com>
bmagyar
bmagyar previously approved these changes Sep 25, 2024
Co-authored-by: Christoph Fröhlich <christophfroehlich@users.noreply.github.com>
Copy link
Contributor

@christophfroehlich christophfroehlich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now CI looks good. And I tested it with ros-controls/ros2_control_demos#396

Copy link
Member

@saikishor saikishor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bmagyar bmagyar merged commit ce5c35a into ros-controls:master Sep 26, 2024
19 of 21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants