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