You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I try to increase the timer frequencies from autoware. Until 100 Hz it works fine. But above, the timer callbacks are still called with 100 Hz, and the CPU/memory usage does not increase anymore as well.
I derive the actual appearing frequencies during runtime with ros2_tracing. I checked if ros2_tracing cannot catch up with such high frequencies, but I created a minimal example where I create a timer with up to 4000 Hz and ros2_tracing tells me 4000 Hz as expected. So, it doesn't seem to be a limitation of ros2_tracing.
I also added an artifical delay in my timer callback in my minimal example of 5 ms. By specifying a frequency of 200 Hz (which is unrealistic with a 5 ms workload), I still measure frequencies of about 175 Hz. Therefore, the actual appearing frequencies are above 100 Hz for this case as well. But for autoware that doesn't seem to be possible somehow, even though I observe that the execution time of the timer callbacks in autoware are way shorter than 5 ms.
I use the replay simulation with the rosbag from Autoware.
Is there maybe an obvious reason that I'm missing? Or is it maybe a result from the complex autoware software system including all kinds of inderministic factors like scheduling?
These are the timer callback prototypes I observe:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I try to increase the timer frequencies from autoware. Until 100 Hz it works fine. But above, the timer callbacks are still called with 100 Hz, and the CPU/memory usage does not increase anymore as well.
I derive the actual appearing frequencies during runtime with ros2_tracing. I checked if ros2_tracing cannot catch up with such high frequencies, but I created a minimal example where I create a timer with up to 4000 Hz and ros2_tracing tells me 4000 Hz as expected. So, it doesn't seem to be a limitation of ros2_tracing.
I also added an artifical delay in my timer callback in my minimal example of 5 ms. By specifying a frequency of 200 Hz (which is unrealistic with a 5 ms workload), I still measure frequencies of about 175 Hz. Therefore, the actual appearing frequencies are above 100 Hz for this case as well. But for autoware that doesn't seem to be possible somehow, even though I observe that the execution time of the timer callbacks in autoware are way shorter than 5 ms.
I use the replay simulation with the rosbag from Autoware.
Is there maybe an obvious reason that I'm missing? Or is it maybe a result from the complex autoware software system including all kinds of inderministic factors like scheduling?
These are the timer callback prototypes I observe:
Beta Was this translation helpful? Give feedback.
All reactions