Currently, ManagedNitrosPublisher and ManagedNitrosSubscriber cannot be used with ROS 2 Lifecycle nodes. This limits their usability in modern ROS 2 systems, where Lifecycle support is increasingly standard.
Problem Description
ROS 2 introduced the Lifecycle node model to enable managed startup, shutdown, and state transitions. This feature is widely adopted and considered best practice in many production systems.
At the moment, ManagedNitrosPublisher and ManagedNitrosSubscriber require a raw rclcpp::Node* to be passed to their constructors.
Publisher:
ManagedNitrosPublisher(
rclcpp::Node * node,
const std::string & topic,
const std::string & format,
const NitrosDiagnosticsConfig & diagnostics_config = {},
const rclcpp::QoS qos = rclcpp::QoS(1))
Subscriber:
explicit ManagedNitrosSubscriber(
rclcpp::Node * node,
const std::string & topic_name,
const std::string & format,
std::function<void(const NitrosMsgView & msg_view)> callback = nullptr,
const NitrosDiagnosticsConfig & diagnostics_config = {},
const rclcpp::QoS qos = rclcpp::QoS(1))
This design prevents them from being used with rclcpp_lifecycle::LifecycleNode, since Lifecycle nodes are not directly compatible with APIs expecting a plain rclcpp::Node*.
Prior Art
A similar limitation previously existed in image_transport. That issue is documented here:
It was resolved (starting with ROS 2 Kilted) by switching to the use of NodeInterfaces instead of requiring a direct rclcpp::Node*:
This approach allows compatibility with both standard rclcpp::Node and rclcpp_lifecycle::LifecycleNode.
Proposed Improvement
Refactor ManagedNitrosPublisher and ManagedNitrosSubscriber to accept the appropriate NodeInterfaces (e.g., NodeBaseInterface, NodeTopicsInterface, etc.) rather than a raw rclcpp::Node*.
This would:
- Enable compatibility with Lifecycle nodes
- Align with modern ROS 2 design patterns
- Improve integration with frameworks such as Nav2
- Future-proof the API
Motivation and Impact
Lifecycle nodes are becoming increasingly important in ROS 2 ecosystems and are already heavily used in mature stacks such as Nav2. Lack of Lifecycle support in core transport/publisher components creates friction for developers building managed systems.
Currently,
ManagedNitrosPublisherandManagedNitrosSubscribercannot be used with ROS 2 Lifecycle nodes. This limits their usability in modern ROS 2 systems, where Lifecycle support is increasingly standard.Problem Description
ROS 2 introduced the Lifecycle node model to enable managed startup, shutdown, and state transitions. This feature is widely adopted and considered best practice in many production systems.
At the moment,
ManagedNitrosPublisherandManagedNitrosSubscriberrequire a rawrclcpp::Node*to be passed to their constructors.Publisher:
Subscriber:
This design prevents them from being used with
rclcpp_lifecycle::LifecycleNode, since Lifecycle nodes are not directly compatible with APIs expecting a plainrclcpp::Node*.Prior Art
A similar limitation previously existed in
image_transport. That issue is documented here:It was resolved (starting with ROS 2 Kilted) by switching to the use of
NodeInterfacesinstead of requiring a directrclcpp::Node*:This approach allows compatibility with both standard
rclcpp::Nodeandrclcpp_lifecycle::LifecycleNode.Proposed Improvement
Refactor
ManagedNitrosPublisherandManagedNitrosSubscriberto accept the appropriateNodeInterfaces(e.g.,NodeBaseInterface,NodeTopicsInterface, etc.) rather than a rawrclcpp::Node*.This would:
Motivation and Impact
Lifecycle nodes are becoming increasingly important in ROS 2 ecosystems and are already heavily used in mature stacks such as Nav2. Lack of Lifecycle support in core transport/publisher components creates friction for developers building managed systems.