what ist better: n times 1 node with 1 client vs 1 node with n clients

[mbaaba]

Hello, I am new to ROS/ROS2 and have bought a create 3, to learn it.
While playing around, one question came up in my mind:

To control the create3, I need a lot of topic-/action-/service-clients. As far as I have seen now, I have two possibilities:

1. I have 1 node and this node uses many clients, for example to read messages or send goals
2. I have many nodes and each node uses 1 client

What ist the better way, or have I something totally misunderstood?

[alsora]

There isn't a definitive answer to your question, however I can give you some ideas to help you take the decision depending on your specific use-cases.

ROS nodes should be independent computational entities in your system that perform a certain task.
ROS nodes can usually be fully characterized in terms of their input and output ros connections.
Common examples of ROS nodes in mobile Robotics may be the following:

• camera node: a node implementing a camera driver, publishes camera images and implements ROS servers to control the camera hardware
• SLAM node: a node performing Localization and Mapping tasks. It subscribes to the robot inertial pose estimate (odometry), to camera images and publishes an optimized robot pose. It exposes services to control the slam algorithm.
• path planning node: subscribes to map and robot pose and exposes a server that can be used to compute paths
• behaviors node: subscribes to map and robot pose, exposes servers to execute behaviors, uses clients to request paths, publishes motion commands to move the robot.

This will inevitably result in duplicating some ROS entities: there will be multiple ROS nodes subscribing to the same topic for example or having the same client.
Note that when hardware is involved, it's highly recommended that there's only a single node that has ownership/control over that piece of hardware.
This means only one node will access the camera hardware and publish images.

The main purpose is modularity.
Lets say that you have the above described system. You want to test a new slam algorithm and now you can do that touching only one node in your system.
This wouldn't be possible if you had a single node for your whole system.

The extreme examples that you made (1 node for everything vs 1 node for each service/action/topic) are most of the times both wrong.

ROS communication entities (topics, services, actions) entirely define the relations between different nodes.
ROS node must not communicate between each others through other means outside of those entities.
Thus, you need to understand where it's suitable to use them or not.
This means whether two functionalities should be part of the same ROS node (i.e. they interact using standard C++ syntax, such as methods and member variables) or in different ROS nodes (i.e. they interact only using ROS).

Besides these considerations, there are also many more advanced topics.
Nodes are not the only way to achieve separation and modularity: indeed there are also ROS plugins or many other standard C++ tools.
Performance may be something to take into account: publishing data on a ros topic is a lot more computationally expensive than just calling a get() API.

I hope that this gives you a general idea of the topic.
ROS is ultimately a communication framework and a tool to design modular software architecture.
It's important to understand all its tools and how to best apply them to a problem

[mbaaba]

Thank you very much for your answer!

What do you mean by "calling a get() API"?
How would I let the create3 drive 1m or turn 90 degree without using ActionClients?

[alsora]

I'm talking about using standard c++ functions.
You can't do that to communicate with other ROS nodes