Duplicate ROS 2 nodes created due to CLaserOdometry2D inheriting from rclcpp::Node

[NTques]

Description

When CLaserOdometry2D inherits directly from rclcpp::Node, it results in the creation of duplicate nodes during execution.

Reproduction

When executed using ros2 run:

$ ros2 node list
/CLaserOdometry2D  
/CLaserOdometry2DNode  
/transform_listener_impl_5673af29ff20

When executed using a launch file:

$ ros2 node list
WARNING: Be aware that there are nodes in the graph that share an exact name, this can have unintended side effects.
/rf2o_laser_odometry  
/rf2o_laser_odometry  
/transform_listener_impl_5f5d1bb19450

Although there appear to be no functional issues, it is advisable to remove the inheritance from rclcpp::Node in CLaserOdometry2D. Instead, the class should be refactored to receive a rclcpp::Node::SharedPtr or specific dependencies such as rclcpp::Logger and rclcpp::Clock via constructor injection.

[BM-45]

I’m running into the same issue on ROS 2 Jazzy + Gazebo Harmonic.
The node reports “waiting for laser scans” even though /lidar publishes valid LaserScan messages.
Confirmed that two nodes named /rf2o_laser_odometry1 appear in ros2 node list.
It seems related to the duplicate‐node inheritance noted here—callbacks never trigger.