You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently it is not supported to implement these nodes in a lifecycle node implementation as lifecycle does not simply inherit from a regular node. We want to implement a BT in a lifecycle node and I am happy to perform this refactor, but want some feedback on direction before I start.
Regular and lifecycle variants of nodes implement a shared set of interfaces that implement the underlying behaviour. The implicit interface of how to retrieve each of these abstract interfaces is shared, and this is how rclcpp_action solves this by using a templated constructor that will then extract the interfaces which are shared.
I think that pattern would be best, storing the interfaces inside the params struct rather than the node itself. There could then be a templated convenience function/constructor that accepts either node type in order to extract the interface set. This would mean however that there is no longer a familiar node handle in the BT nodes, but a set of relevant interface handles.
The alternative is to template the params struct and the node classes making everything a bit more fragile and libraries would either need to build both variants, or built for a specific node type, both which don't seem ideal. However the familiar node handle would be available within the node.
Currently it is not supported to implement these nodes in a lifecycle node implementation as lifecycle does not simply inherit from a regular node. We want to implement a BT in a lifecycle node and I am happy to perform this refactor, but want some feedback on direction before I start.
Regular and lifecycle variants of nodes implement a shared set of interfaces that implement the underlying behaviour. The implicit interface of how to retrieve each of these abstract interfaces is shared, and this is how rclcpp_action solves this by using a templated constructor that will then extract the interfaces which are shared.
I think that pattern would be best, storing the interfaces inside the
params
struct rather than the node itself. There could then be a templated convenience function/constructor that accepts either node type in order to extract the interface set. This would mean however that there is no longer a familiar node handle in the BT nodes, but a set of relevant interface handles.The alternative is to template the params struct and the node classes making everything a bit more fragile and libraries would either need to build both variants, or built for a specific node type, both which don't seem ideal. However the familiar node handle would be available within the node.
@facontidavide thoughts?
The text was updated successfully, but these errors were encountered: