We already had runnables on the old API. These can be used to group publishers and subscribers. E.g. it is already used by rmw_iceoryx to represent ROS nodes. We need this functionality also for the new C++ and C APIs
Detailed information
One OS process can contain 1..x SW modules which maybe are related to each other but can be treated as individual deliveries with an own responsibility and interface. In the Autosar world this is often called a runnable, in the ROS world a node. Iceoryx does not really need this information (as DDS) but having this grouping of publisher and subscriber entities makes it easier for the user to deal with nodes or runnables. We already introduced runnables some time ago for supporting the ROS tools with rmw_iceoryx. With the old API runnables could be created and when creating publishers and subscribers the runnable could be provided as optional parameter (see here. The runnable information is also already included in the introspection topics but so far was not displayed by the introspection client (e.g. here
The proposal would be to name this API element node, as this is also the name in ROS and with Publisher and Subscriber we are already aligned to the names there.
[x] Check how Nodes, Publishers and Subscriptions are related with the current ROS2 rclcpp API. Do we want to have a similar look and feel?
[x] Design the iceoryx API. (Can publishers and subscribers only be created with a node? If no, do we have something like a default node if no one is created by the user?
[x] Adaptation of runtime, introspection, RouDi. Runnable -> Node
[x] Introduce nodes in new C++ API
[x] Introduce nodes in new C API
[x] Extend introspection client to also show node information (Please check that if there are two nodes with the same subscriber, both appear in the introspection client. This was not the case so far, only one appeared)
[x] Extend an existing or create a new example, whatever makes more sense
Brief feature description
We already had runnables on the old API. These can be used to group publishers and subscribers. E.g. it is already used by rmw_iceoryx to represent ROS nodes. We need this functionality also for the new C++ and C APIs
Detailed information
One OS process can contain 1..x SW modules which maybe are related to each other but can be treated as individual deliveries with an own responsibility and interface. In the Autosar world this is often called a runnable, in the ROS world a node. Iceoryx does not really need this information (as DDS) but having this grouping of publisher and subscriber entities makes it easier for the user to deal with nodes or runnables. We already introduced runnables some time ago for supporting the ROS tools with rmw_iceoryx. With the old API runnables could be created and when creating publishers and subscribers the runnable could be provided as optional parameter (see here. The runnable information is also already included in the introspection topics but so far was not displayed by the introspection client (e.g. here The proposal would be to name this API element node, as this is also the name in ROS and with Publisher and Subscriber we are already aligned to the names there.
[x] Check how Nodes, Publishers and Subscriptions are related with the current ROS2 rclcpp API. Do we want to have a similar look and feel?
[x] Design the iceoryx API. (Can publishers and subscribers only be created with a node? If no, do we have something like a default node if no one is created by the user?
[x] Adaptation of runtime, introspection, RouDi. Runnable -> Node
[x] Introduce nodes in new C++ API
[x] Introduce nodes in new C API
[x] Extend introspection client to also show node information (Please check that if there are two nodes with the same subscriber, both appear in the introspection client. This was not the case so far, only one appeared)
[x] Extend an existing or create a new example, whatever makes more sense