-
Notifications
You must be signed in to change notification settings - Fork 522
Description
In ROS 1, there's a construct in roscpp called a NodeHandle, and it has most of the interface of the Node singleton, but can additionally have "extra" namespace. Having a node handle instance with a namespace does not affect the node namespace/name combo, but all things created using the namespace node handle will have the extra namespace added to it, e.g. publishers, subscriptions, services, parameters, etc...
From https://wiki.ros.org/roscpp/Overview/NodeHandles:
The ros::NodeHandle class serves two purposes. First, it provides RAII-style startup and shutdown of the internal node inside a roscpp program. Second, it provides an extra layer of namespace resolution that can make writing subcomponents easier.
In rclcpp, the Node class provides the RAII style lifecycle of the node, so this issue is just about having a new concept in rclcpp that satisfies the "provides an extra layer of namespace resolution that can make writing subcomponents easier" part.
However, there is a question about lifetime of the node handle: should it be up to the user to ensure that the node instance out lives all node handles, or should node handles have a weak reference to the node?
Unlike the constructible ros::NodeHandle, this new object would be generated by a factor function of the original Node. e.g. node->get_node_handle("namespace", remapping args, additional parameters, etc.).
Again, like the node handles in roscpp, it should be possible to build a hierarchy of these objects, something like this:
auto node_ptr = std::make_shared<rclcpp::Node>("my_node", "my_ns");
auto sub_node = node_ptr->create_sub_node("foo_ns");
auto another_sub_node = sub_node->create_sub_node("bar_ns");
// topic would be '/my_ns/foo_ns/bar_ns/chatter'
auto sub = another_sub_node->create_subscription<...>("chatter", ...);This request is being driven by existing use cases in the porting of gazebo ros packages, and is especially useful if you have components which may be "attached" to nodes in arbitrary configurations. These components would take something that looks like a node and use it to create pub/sub, services, etc... but ideally would not need to manually apply namespaces itself.
Summary of design issues and goals:
- Provide API of node, but modify namespace of topics, services, parameters, etc...
- Provide custom but scoped remappings
- Provide additional parameter value initialization/declaration (see: )
rclcpp/rclcpp/include/rclcpp/node.hpp
Line 101 in 6b34bcc
const std::vector<Parameter> & initial_parameters, - Nestable
- Name bikesheding, how to call it?
- considerations: it's not a Node, how to indicate? can provide extra namespace, but also other things
- ideas:
NodeHandle,NodeProxy,SubNode,NodeView,NodeNamespace
- How to handle lifecycle of handle with respect to lifecycle of actual node?
- How to avoid extensive boilerplate required to implement our composition design (Node, "NodeHandle", LifeCycleNode, etc...)?