rclcpp::WaitSet vs rclc executor?

edit

Hi @JanStaschulat, thank you for your answer. I wasn't clear when I said "rclcpp::WaitSet can also provide those functionalities". What I meant is the user can implement the message handling with rclcpp::WaitSet, which can be seen in the [example], which has the same logic as the SingleThreadedExecutor based on the documentation and the trigger condition can be achieved using sub1_has_data, sub2_has_data, sub3_has_databoolean variables. (https://github.com/ros2/examples/blob...) So please correct me if I'm wrong, is the rclcpp::WaitSet example actually what happened in the underlying code of the rclc executor with the exception that the memory allocation is static?

Hi @vutran1410, yes. The WaitSet enables a greater flexibility of execution management, like the example with three bool variables. I agree, that the functionality of such a hand-written Executor using WaitSets is equivalent to the rclc-Executor, regarding execution behavior. The difference is memory allocation at runtime (rclcpp: dynamic, rclc: no dynamic).

I would like to add the feature of the rclc-Executor to configure scheduling parameters for callbacks. (though published in 2021, but not in mainline yet). You could achieve this with the existing ROS 2 functionality e.g. by creating a thread with user-defined scheduling parameters and inside calling an Executor. However, this would require more knowledge about operating systems, that most robotics engineers probably do not want to get into. I my opinion, ROS 2 should provide a proper API instead.

Since the multi-thread rclc executor isn't in mainline yet, is it possible to create multiple single-thread rclc executor and then run each of the executor in a separate OS thread to achieve the effect of a multi-thread executor?

Yes, you can do that. Also the micro-ROS client is thread-safe. So you can run multiple threads (with the rclc-Executor) on a micro-controller in parallel.

The difference is, that if you have multiple entities in an Executor (ROS 2 or rclc), then new data is always processed sequentially (this is similarly the case for the MultiThreadedExecutor (just one wait_set and a thread pool with n threads is processing n messages in parallel.) In the multi-threaded Executor, you could cherry-pick callbacks to threads with user-defined scheduling parameters.

So if you have a high-priority topic, you would have to create a thread with a high priority and have the rclc-Executor only with this high priority callback, to make sure that the operating system prioritizes over all other callbacks (in other Executors/threads).

Hi @JanStaschulat, sorry for the late question. When I run multiple executors with each executor in one thread, if the executor in the higher priority thread runs a blocking spin continuously (not the spin_period with sleep() function), does this mean that all other executors in lower threads cannot run at all? I think the same case happens with the rclcpp executor.

Hi @vutran1410, no.

The micro-ROS library is thread-safe. That means, the middleware can be simultaneously accessed from different threads (with a different thread-priority). The spin() function blocks only the thread in which the executor is created. This has no impact on other spin-calls of other executors (in different threads) to the rclc-library / XRCE-DDS middleware.

What do you mean with "I think the same case happens with the rclcpp executor."? There are several examples with multiple threads, in which each an executor is created (e..g SingleThreadedExecutor or MultiThreadedExecutor) and they will access DDS middleware simultaneously.

For example see the callback-group level executor (rclcpp): https://github.com/ros2/examples/blob...