ros2 / rclc

ROS Client Library for the C language.
Apache License 2.0
119 stars 42 forks source link

Question about timeout_ns parameter in rclc_executor_spin_some #399

Closed ChoiYouJung closed 8 months ago

ChoiYouJung commented 9 months ago

Hello.


I have a question about the timeout_ns parameter of the rclc_executor_spin_some function.

As far as I know, the timeout_ns parameter of rclc_executor_spin_some is interpreted in two ways.

Can you tell me which of the two methods is correct?

First, the executor seems to run periodically when it times out.

The second is considered to be the time it takes to complete only the timeout period when executing the function.


And to understand the operation of the rclc_executor_spin_some function, we looked inside the rclc_executor_spin_some function in rclc/executor.c.


rclc/rclc/src/rclc/executor.c https://github.com/ros2/rclc/blob/humble/rclc/src/rclc/executor.c


I have two questions. The first question is: It seems that the timeout_ns parameter is used in the rcl_wait function inside rclc_executor_spin_some. At this time, does the function terminate after waiting for timeout_ns?

The second question is as follows. I understood that when rclc_executor_spin_some is executed, the waiting subscription callback function and Timer callback function are executed. Is it correct that all waiting subscription callback functions and Timer callback functions are processed and terminated before rclc_executor_spin_some terminates? Or is there a limited number?

thank you

JanStaschulat commented 9 months ago

Hi @ChoiYouJung

regarding your first question:

yes, but only if no new data is available (then rcl_wait will return after timeout_ns). But if there is data for some subscriptions, then all subscriptions will be processed, without considering the timeout parameter.

regarding second question: yes and no. If there are pending new data or timer events then each subscription/timer is executeded once. The reason is the wait_set structure. Only the "top-most" element of the wait set per (subscription/timer/service/...) is processed in one iteration of the spin_some function.

Reference to timing behavior of ROS 2 Executors See also the slides of the Real-Time Workshop at ROSCon, From slide 164ff the execution management of ROS 2 is explained.

rclc Timing Behavior explained The timing behavior of the rclc executor is the same as the default ROS 2 Executor. Therefore, you can learn about the behavior from that presentation too:

On slide 183 you see that there are two things involved:

The timeout_ns parameter in rclc_executor_spin_some defines the time, rcl_wait() will wait for new data (Polling Point (1)). If no new data is available for longer time, then, as you mentioned it looks like that the rclc_executor_spin_some is called periodically. But this is only because the funtion blocks for the specified timeout and does not process any callback.

If some new data is avaible for a subscription or a timer is ready, then rcl_wait returns immediately (ignoring the timeout). The duration of the rclc_executor_spin_some function is then the sum of all execution times of all processed callbacks (timers, subscriptions, ...). (second part (2) processing window).

To the contrarary, if you want to limit the processing time in ROS 2 C++ API, then you can use this function Executor::spin_all(max_duration). It checks after each callback processing, if already the max_duration had elapsed. And limits this way the total duration of this function.

Such a function does not exist in rclc.

Did this answer your question? Do you need such a function, which bounds the execution time of a spin_some in rclc? If so, what is your use-case?

Note: If you need some real-time behavior, you could also create two threads in your application, configure the thread priorities either with high and normal priority. Then have two executors, on running in the real-time thread, the other in a normal thread. With this construction, you could distribute real-time callbacks to a real-time processing thread; and non real-time stuff by the other Executor.

JanStaschulat commented 9 months ago

@ChoiYouJung could you give some feedback? Is the issue resolved in your view?

ChoiYouJung commented 8 months ago

hello? Sorry for the late feedback. The answer was helpful in solving the problem. thank you.