Can lost time when using 'waitfor(rate)' function be used for other tasks?

The 'rosrate' object can be used to contol the rate of execution of a block of code. This is typically done by including the code in a loop and invoking the 'waitfor(rate)' function to insert delays to achieve the target rate of execution. Can the time delay be used to execute other parts of the code?

Answer 1

[Cam Salzberger]

Hello Mohan,

Generally the way to use rosrate is to put it at the end of a "control loop" - code that you execute every iteration. In this way, the "waitfor" will act as a sort of "sponge" - any remaining time left over after you've run all the code you want to run will be absorbed in rosrate. There currently isn't any kind of "while waiting, run this low-priority code, but kill it if it hits the wait limit" functionality.

One thing to note is that rosrate can be treated similiarly to a simple "pause". If you have code that runs on a timer or as part of a callback, this code will continue executing even while the main program is "paused". The same thing can apply to rosrate. So if you want to have some code running in that background that continues while waitfor is waiting, you could work up some kind of callback.

-Cam

[Mohan]

Thanks for the response, Cam. The second paragraph of your response has increased my insight, though I am not fully certain right now about the details of the structure that will enable this.

However, I do have a follow-up question on the base usage mode of just controlling the frequency of execution of the loop by killing time at the end of the loop. Is the advantage here then, just the ability to give the system being controlled (typically a slower mechanical system) a chance to react to control commands? As a corollary to this question, what can we expect physically if we excluded use of the 'rosrate' command to control the loop execution frequency?

[Cam Salzberger]

It is a pretty common workflow to have a control loop executing at a fixed rate - it is the entire basis for Simulink, after all. The purpose of this varies from application to application. One reason could be to allow a physical robot time to react. Another would be to avoid overloading a network with ROS messages that aren't needed as frequently. Another could be to release processor time on the local system for handling callbacks and the like.

You may be able to get an idea of what frequency you should be looking for sensor data at by determining the minimum frequency to still allow accurate state estimation. It's common that different sensors use different rates (e.g. odometry and IMU readings are needed often, but GPS and camera data can provide less-frequent "true-ups" of the position). You may also be able to determine the frequency you need to do the state estimation at and send control commands based on the characteristics of your system (to ensure stability of your control scheme). There's not really any one physical thing that can happen based on different rates - it really depends on how you use it and what your application is.

If you are not looking to execute your loop at a specific frequency, and are instead looking to execute various code at different priority levels, then rosrate probably isn't the tool for that. I'm not familiar with any built-in feature that has a defined prioritization system, so you would probably need to implement your own.

-Cam

[Mohan]

Thank you!