1
$\begingroup$

I am doing a very complex calculation inside a node using some other libraries. The node is...

  • doing the calculation in an endless loop
  • it is calculating from the last calculation to ROS::Timer::Now()
  • Example: 
    while(true){
    do_some_expensive_calculation_and_publish(from=last_calculation_point, to=ROS::Time::Now());
    last_calculation_point = ROS::Time::Now();
}

Unfortunately ROS time is running way faster than I can do the calculation. Therefore I would need to slow down ROS/Gazebo somehow in order to get the result of the calculation before the next one should begin. Otherwise it takes longer an longer to get the calculation results since the time since the last calculation increases.

How to do that properly?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
2
$\begingroup$

Since you're using gazebo already and it should then be generating simulated time you can ask gazebo to run slower than realtime.

In the physics section of your world you can ajdust the maximum realtime factor to tell gazebo to run slower than realtime using the real_time_factor parameter.

There's a tutorial on the physics parameters here which you may find helpful.

If you're running the gazebo gui you can adjust it in realtime to experiment before embedding it into your world sdf file.

As a side note this will get you working for this use case, but if you're looking to make this run outside of simulation where you can't slow down time. You may want to look at adjusting your algorithm to allow it to skip forward in time by dropping information to keep it current instead of running on older and older data.

Improve this answer
$\endgroup$
8
  • $\begingroup$ Thanks! Is there maybe a way to tell gazebo to automatically slow down as much as necessary? Sth like "if it is too fast: divide rtf by 2, otherwise multiply by 1.5" $\endgroup$
    – tollo
    Nov 25, 2021 at 7:49
  • $\begingroup$ Please explain the info in the posted link briefly. If the link is broken, the answer may not be informative any more. $\endgroup$
    – CroCo
    Nov 25, 2021 at 21:31
  • $\begingroup$ The link is to a tutorial for tuning physics parameters and is not necessary for understanding the post. I provided it as a jumping off point for someone seeking a deeper understanding. $\endgroup$
    – Tully
    Nov 26, 2021 at 15:38
  • $\begingroup$ @tollo You can do that with gazebo by writing a plugin which will regulate the update frequency. It's a much more complicated solution but it's completely doable. It can't be done trivially because the process where you are waiting is separate from the gazebo process so you have to setup a mechanism to communicate between those processes. $\endgroup$
    – Tully
    Nov 26, 2021 at 15:43
  • $\begingroup$ Links may be removed/broken any time. Without having short description (i.e. you can quote it from the link), the answer will may not be as its original version. $\endgroup$
    – CroCo
    Nov 26, 2021 at 17:41
-1
$\begingroup$

1- You can slow the execution time using sleep() from ros::Rate class. Also, Gazebo allows you do so using real_time_factor.

2- While Gazebo and ROS allow you to slow down the execution time, but it seems to me you're missing a good feature in ROS which is "ROS Action Protocol". The protocol is one-to-one, and reliable communication mode between nodes which differs from services in the sense that the client “doesn’t block” waiting on the server to respond. Actions are a form of asynchronous communication in ROS. Let's say you have two nodes. One node runs heavy computational process (i.e. big fibonacci number) and the second node is interested in the current/final result, feedback about the current process, or stopping the process at any particular time without blocking the client. This protocol is perfect for this scenario. Think about it as running each node with multi-threading.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Sleeping in your ROS process is going the wrong way and will slow down the processing but the simulation will continue at pace. $\endgroup$
    – Tully
    Nov 26, 2021 at 15:45
  • $\begingroup$ @Tully you can run your node at any particular speed but if the OP is looking for slowing down the entire ROS network, then there is a fundamental misunderstanding here. Also, I've suggested another solution which perfectly valid in this case. $\endgroup$
    – CroCo
    Nov 26, 2021 at 16:25
  • $\begingroup$ For the downvoters, please spend a minute to express your consider. $\endgroup$
    – CroCo
    Nov 26, 2021 at 16:25
  • $\begingroup$ I was the one who down voted your question. As I commented above your first answer is straight up the opposite of what the question asks. To that end i down voted it because I didn't want future readers to think that it might solve their problem if they have the same one. In my answer i have a coda which addresses that I think this approach implied by the question might be an XY problem where they are looking to fix the wrong side of the problem. $\endgroup$
    – Tully
    Nov 27, 2021 at 6:56
  • $\begingroup$ Your second proposed answer of using Actions is tangential to the stated problem. Your reinterpretation of the system into a multinode asynchronous system in the beginning of your answer ignores the stated problem. I generally agree that considering multithreading is something that the OP might want to consider assuming they have extra computation resources available. But Actions themselves do not inherently provide that and there are much lower overhead ways to do it if you're local to one node, like the problem description. $\endgroup$
    – Tully
    Nov 27, 2021 at 7:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.