Boost Simulation Performance

[Darkproduct]

Gazebo Performance

Some people especially with lower hardware have problems with the simulation speed. This thread should help them to tweak there systems and gazebo to boost the performance of the simulation.

Physics Parameters

We found that the physics parameters specified in the gazebo world is the easiest to tweak and has big performance impacts.

The 3 parameters are found in the generated.world in line 21 - 25:

<physics name='default_physics' default='0' type='ode'>
  <max_step_size>0.001</max_step_size>
  <real_time_factor>1</real_time_factor>
  <real_time_update_rate>1000</real_time_update_rate>
</physics>

Performance gains:

All reported real time factors and fps values are while driving without the first 30 seconds real time simulation. This means the start of the simulation is not reported, because it is not representative. The robot is started after the first 30 seconds and stopped after the first row is completed.
System 1:

• CPU: AMD Ryzen 5 5600 X,
• GPU: Nvidia GTX 680 OC,
• RAM: Corsair 32 GB DDR4-3200

System	Description	max_step_size	real_time_update_rate	Real Time Factor [min/max]	FPS [min/max]
1	default task_1 without robot-plant collisions	0.001	1000	0.25 / 0.93	25 / 62
1	default task_1 with robot-plant collisions	0.001	1000	0.14 / 0.93	38 / 48
1	tweaked task_1 without robot-plant collisions	0.005	250	1.24 / 1.25	58 / 63
1	tweaked task_1 with robot-plant collisions	0.005	250	0.42 / 1.25	52 / 62

I'll add other system to this table as soon as I have the numbers. Feel free to try this yourself.

[ThijsRuigrok]

Nice table looks good. Since more people have the problem of the slow running simulation, and because I also encounter some problems during the dockers submitted for testing I made some fast worlds.

I just made some new commits. In the world template I changed the step_size to 0.005 and in the virtual_maize_fields/scripts I added generators for fast worlds. These fast worlds have a step size of 0.005 and a reduced resolution of the ground_plane to 15cm. To make this work also the maximum height of the soil model had to be lowered to 5cm.

I think this will help teams with less sufficient hardware, and will help for the event to run smoothly with a Realtime factor around 1. However, we do not know the exact parameters for the event yet, as we are still finetuning and because we want to expose the robots to a world with slightly different world parameters to test robustness of the robot algorithms.

keep up the good work with testing the simulation speeds :)!

[Darkproduct]

I think that the new physics parameters are not good enough for the environment during the competition.

When I run the simulation in our docker container with the world from task 1, the robot moves visibly on its own.

This is a screenshot from the simulation with only the a container running after a few minutes.

[Robatic2021]

For our team changing the step size to a higher value resulted in a poorer robot performance. We suspect the problem is due to the fact that the robot now doesn't meet the expected rate, as rosrate only tries to reach the set value, but doesn't slow the simulation down if it can't reach the desired rate. The other option is that the higher stepsize actually makes the simulation less reliable, which is also likely, because loading a world with the bigger step size and waiting a bit shows that objects like the robot move a lot even when no commands to move are given. We think this is maybe due to the interaction with the ground_plane.

So, for us the higher step size gives poorer results, but we believe that can't be blamed on us, so we would like to request to run the simulation on the competition with the original smaller step-size.

[Darkproduct]

I had the same suspension. The performance with the original values is better, but the difference isn't that big. For the competition environment, I suspect that it will be run with the original parameters. The speedup is only for rapid testing or on hardware that can't feasibly run the original environment.

[ThijsRuigrok]

Hi,

"We suspect the problem is due to the fact that the robot now doesn't meet the expected rate, as rosrate only tries to reach the set value, but doesn't slow the simulation down if it can't reach the desired rate. " I understand that here you refer to the rospy.rate() function in your code. Now that the simulation runs faster it can be the case that your programs cannot keep up with the simulation speed. This is realistic and would also be the case in a real world scenario. This problem depends on the computation power available on your hardware. It is possible that this problem is not present when you run the code on the competition pc(with lots of computation power), but for that you should send in a docker container for testing.

A solution to this problem would be to lower the rospy.rate() that you use and slow down the drive speed of the robot. In a real world you would also have control over these parameters.

[ThijsRuigrok]

I had the same suspension. The performance with the original values is better, but the difference isn't that big. For the competition environment, I suspect that it will be run with the original parameters. The speedup is only for rapid testing or on hardware that can't feasibly run the original environment.

We also aimed to used similar fast settings during the competition, so that we can reach a realtime factor of around 1 during the event. We will do some more tuning to improve the quality of the simulation while maintaining a high realtime factor.

I think we can reduce the stepsize to 0.003 maybe, but I have to try :).

[Robatic2021]

Thanks for your reactions. We were assuming we could keep the same rate in rospy.rate(), as that rate was in previous years achieved with the real robot hardware. Currently we are testing the effects of different step sizes, rospy.rates and actual robot speeds. We would of course like to keep both the rospy.rate and robot speed high, so we will see whether we can find a balance. Once we are satisfied we will send you a new docker image for testing.
A stepsize of for example 0.003 would indeed be better, as 0.005 seems to cause unrealistic artefacts in the behaviour of both physics and the robots.