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

Compatibility with ROS 2 Components #1704

Open
jcarpinelli-bdai opened this issue Aug 21, 2024 · 6 comments
Open

Compatibility with ROS 2 Components #1704

jcarpinelli-bdai opened this issue Aug 21, 2024 · 6 comments

Comments

@jcarpinelli-bdai
Copy link

Summary

Can we use rclcpp_components, and Components more generally, to more effectively separate manager node / managed node semantics in the ControllerManager class?

Issue

When using the ControllerManager class in a new process (not the project-provided ros2_control_node process), renaming the controller manager might cause every underlying controller to have its private member variable node to change its name to the name of the controller manager. This is a known issue, and is described in the ros2_control documentation.

Composition

In ROS 2, Node Composition seems to be the general solution to the issue described above. Components can be renamed independently of the component manager.

Question

Does composition (in the ROS 2 sense of the word) offer any benefits over the existing design of the controller manager, and the controller interface? Instead of inheriting a std::shared_ptr<rclcpp_lifecycle::LifecycleNode> in the controller interface, could controllers act as Node components? Could the controller manager be a component manager? Thank you for reading!

Warning

I am not a ROS 2 expert, so my understanding could definitely be incorrect. Please let me know if I'm misunderstanding ros2_control, or ROS 2 features more broadly.

@saikishor
Copy link
Member

saikishor commented Aug 21, 2024

Hello @jcarpinelli-bdai!

This is no longer a problem because the issue you are describing is solved with the #1694. The ros2 components that you are describing internally use the same approach of setting use_global_arguments to false.

Let us know if this fixes your issue.

Thank you!

@jcarpinelli-bdai
Copy link
Author

Thanks for the quick reply! In my own testing, setting use_global_arguments(false) does solve the re-naming issue, but it also disables parameter setting for the composed nodes. I am using humble, so perhaps this behavior has changed in more recent ROS versions?

@saikishor
Copy link
Member

Thanks for the quick reply! In my own testing, setting use_global_arguments(false) does solve the re-naming issue, but it also disables parameter setting for the composed nodes. I am using humble, so perhaps this behavior has changed in more recent ROS versions?

Well that's true, that part will be affected. That's why the changes are not backported to older distros. However, in order to have it working use --param-file option from spawner, and this will help you set it to the controller nodes

@christophfroehlich
Copy link
Contributor

Thanks for the detailed summary of your issue.
@saikishor Isn't the part in docs outdated after #1694?

@saikishor
Copy link
Member

Thanks for the detailed summary of your issue. @saikishor Isn't the part in docs outdated after #1694?

Yes, it is outdated as now such individual node remapping is no longer needed, even though the same trick will still work. Should we cleanup this part of the docs?

@jcarpinelli-bdai
Copy link
Author

Well that's true, that part will be affected. That's why the changes are not backported to older distros. However, in order to have it working use --param-file option from spawner, and this will help you set it to the controller nodes

Ah, I understand. Thank you for the clarification. I have been using global arguments passed to the controller manager node to configure each of the controllers, as shown in this humble demo. In demos for later releases, the --params-file argument is used instead. This all fully addresses my issue. Thanks again.

I am also interested, just to learn, how these "composed lifecycle nodes" used in ros2_control relate to rclcpp_components. If anyone is feeling like explaining... do components address the same needs as this pattern of "composing full lifecycle nodes"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants