ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Please add more context to your questions in the future. There's no links to which functions you're talking about, no mention of which language you're using nor what your use case is (what it is that you were trying to accomplish when you ran into this).


I guess you mean "what is the rclcpp::node_interfaces::NodeBaseInterface for"? (https://github.com/ros2/rclcpp/blob/7c1721a0b390be8242a6b824489d0bc861f6a0ad/rclcpp/include/rclcpp/node_interfaces/node_base_interface.hpp#L35-L36)

The rclcpp::Node class has lots of functionality in it, and that functionality is broken into a few pieces to make testing easier (mocking the "node base interface" is a lot easier than mocking the entire node interface) and to make supporting new kinds of nodes easier (the rclcpp_lifecycle::LifecycleNode is similar but different from the rclcpp::Node). The NodeBaseInterface has the most basic functionality of a node in it, like getting the node name or namespace, etc...

This question came up for not knowing when I should run spin using node or node_base_interface.

Again, guessing since there's no links, I guess you mean these functions:

https://github.com/ros2/rclcpp/blob/7c1721a0b390be8242a6b824489d0bc861f6a0ad/rclcpp/include/rclcpp/executors.hpp#L40-L48

You should always just use the second signature, which takes a rclcpp::Node, if possible.

Like this:

auto node = std::make_shared<rclcpp::Node>(...);
rclcpp::spin(node);

As is the case in the examples and demos, e.g.:

https://github.com/ros2/examples/blob/35674eb17494ab3f67cc5fbe5f127c614be2220b/rclcpp/minimal_subscriber/member_function.cpp#L42


However, if you are using something other than rclcpp::Node which provides a NodeBaseInterface pointer, then you may use the second signature, but this should only be exceptional cases, and normal users should never need to interact with any of the interfaces under normal circumstances. There are still cases where this isn't true, but we're working towards eliminating those cases.