-
Notifications
You must be signed in to change notification settings - Fork 523
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
Adding support for lifecycle nodes #1538
Comments
Hello @JohnTGZ thank you very much for bringing up this topic! I liked the first solution and I would be happy to support you in the process of contributing it. I think this topic has been brought up a few times in our weekly standups and was not prioritized, but would be a very meaningful addition to MoveIt. Pinging @tylerjw, @henningkayser, @JafarAbdi and @AndyZe for additional thoughts. |
@vatanaksoytezer That's great to hear! If I were to make a pull request, should it be on the rolling or humble branch? Perhaps I can make some preliminary changes and test it out first |
@JohnTGZ thank you so much! PRs should be to the main branch and we will backport to the older distros with the handy mergify bot if requested and does not break API. |
There have already been some related efforts here #1329. The node is passed with a wrapper class that provides getter functions for the node interfaces. I would prefer that solution over constructor overloads, especially since future refactorings would be more straight forward. I'll see if we can get this other PR in soon. However, this is clearly an API break which will make it very difficult to backport to other distros. |
I'm writing a lifecycle node that uses the robot_model_loader::RobotModelLoader,
planning_pipeline and planning_scene_monitor::PlanningSceneMonitor API. However, the constructor to these clases only take in a
std::shared_ptr<rclcpp::Node>
type node in their arguments.The case for using lifecycle nodes is so that an external orchestrator can control the instantiation and execution of individual nodes (such as the node using parts of the moveit library). There is also the ability to incorporate recovery behaviours for unresponsive nodes or error states.
Some ideas on how it could be implemented would be:
rclcpp::node_interfaces::NodeBaseInterface::SharedPtr
andrclcpp::node_interfaces::NodeBaseInterface::SharedPtr
node interfaces, which are the components shared by both the regular node and the lifecycle node.std::shared_ptr<rclcpp::Node>
regular node.std::shared_ptr<rclcpp_lifecycle::LifecycleNode>
type nodeAn issue of interest might be ros2/geometry2#94, with the corresponding pull fix ros2/geometry2#108
Adding support for lifecycle nodes within the moveit API would definitely extend the utility of lifecycle nodes to MoveIt components, and I would be keen to contribute to such efforts. Discussion and suggestions are most welcome :)
The text was updated successfully, but these errors were encountered: