gazebo unreasonably slow with simple world and robot (on GPU PC)
Hello
goal
I aim to simulate a (somewhat) complex world with a very simple robot model.
problem
The real time factor drops to values between 0.1 and 0.01. This makes the simulation unusable. Furthermore, when doing basic movements such as turning the robot, the robot partly falls into the ground, is pushed back up, and tips over. This jumping behavior makes the simulation unrealistic and unusable.
When only simulation the world and not the robot, the real time factor is at 1. There are no problems, which also is to be expected in a static world. When only simulation the robot and not the world, the real time factor also is at 1. There are no constraints to driving. The described jumping does not occur.
the simulation
I use the following robot model: https://github.com/fieldrobot/field_r...
This is the world file: https://github.com/fieldrobot/field_r...
This is my launch file: https://github.com/fieldrobot/field_r...
This script spawns the robot model: https://github.com/fieldrobot/field_r...
The maize models, height map, textures, etc. can be found here: https://github.com/fieldrobot/field_r...
Everything and more is included in this package: https://github.com/fieldrobot/field_r...
what I have already tried & my thoughts
I already tried to optimize the world's physics parameters but did not achieve good results. Either the quality of the simulation decreases drastically (even more jumping), or the real time factor gets so low that I can not even check whether anything is working.
Tuning (as far as I understand each value) the robot parameters (friction, maxVel, etc.) also did not lead to significantly better results. The values in the robot model are not chosen according to a physical model. I just tried to make it work.
As you see in the world file, the world is entirely static. So the robot can not knock over maize plants. They just stay as they are. It would be best if the maize plants could be dynamic. But I made them static with the hope of increasing performance as the physics engine does not have to consider the interactions between the ground and the plants.
To me, it seems unlikely that such a 'simple' simulation can not perform better. After all, it is just ground with a few basic shapes.
Any help would be very much appreciated!
my system
- Compute Engine in the Google Compute Cloud with an Nvidia Tesla K80 GPU (connected via VirtualGL and TurboVNC)
- Ubuntu 20.04
- ROS2 Foxy Fitzroy, latest version via apt
- Gazebo 11, installed as a dependency via ROS2
I initially suspected that the remote system causes my problems. But I consider this unlikely now as the same effect can be observed on native local Ubuntu installations. Because my robot model currently does not use any lidars or cameras (disabled for testing), the GPU is only utilized by the gazebo UI but not the physics engine.
.png "shonigmann"){kind=small}
this question is probably best asked on Gazebo Answers, since ROS is likely not the culprit. If you want to post over there, I'd be happy to offer some suggestions
Thanks for the suggestion. I have just posted the question on Gazebo Answers, and it awaits moderation. I will send the link to my question here as soon as it is accepted.
I still think its worth moving the discussion to Gazebo Answers eventually, but no sense waiting to try and help. I can just move my feedback afterwards.
If the sim is slow but stable, my hunch is that the issue is with the heightmap that you are using. You are using the same 1025x1025 px image for the visual and collision models. That will generate a mesh with millions of vertices and faces, which could be a nightmare for the collision checker. I would suggest down-sampling the image to something like 205x205px for the collision model and seeing how your performance changes.
Another tip to see what is causing the slowdown is to run the Gazebo server only. This will rule out computational impact from the Gazebo client GUI and renderer.
Last tid-bit is that your world file's time step settings are a bit odd. The step size is ...(more)
I tried what you suggested.
Downsampling the collision heightmap made a huge difference. Now the simulation easily runs with a real time factor of 1. While testing, I also removed the friction, stiffness, maxVel, ... configurations. And I adjusted the physics parameters as you suggested.
However, I noticed the following: There are also sudden robot jumps with this configuration. Fortunately, they are so small that they do not disturb the simulation. But when only making minor changes to any parameter, the following happens:
Besides, when I made all plants dynamic again (removed the static tag), the simulation continued to work correctly. But the real time factor dropped to about 0.15. Is there any way to enhance performance? Or is this caused by the sheer amount of meshes and a limitation of the computing power?
The jumping is caused by numerical instability at the interface between the wheels and the ground mesh. There are a number of ways you can try to fix this. For each link's collision tag, setting the
restitution_coefficientto a small or zero value will help prevent bouncing, reducing themax_vel(andcontact_max_correcting_velwithin the physics tag) contact parameter will help maintain contact between two surfaces. You can also try modifying themin_depth, stiffness and damping (kpandkd) of the wheels / the heightmap to make the connection "squishier". All those fixes might be "free" in terms of computation speed. If your model is still unstable, then you will likely need to make yourmax_step_sizesmaller. I did some benchmarking a while back and results were pretty "strange" for step sizes greater than 1e-3. If your computer can handle it, I have found that a step size of 1e-4 is ...(more)For the maize models I would suggest using
populationtags to cleanup your world file.Regarding making them "dynamic", presumably you want the tractor to "knock over" the maize models? I think because of the number of models / contacts, it will be hard to get this to be "fast". A few things that may help performance: reducing the number of contacts in the maize models to something like 4 (default is 10). adding joints at the base of each model so that they pivot about the base rather than being fully free to move in space might help, but I'm not certain.
If the contact dynamics aren't very important, I think an approach that is more likely to be successful would be to create a world plugin that uses the position of the tractor to either set the pose of, or delete, the maize model that would be contacted.
What does the restitution_coefficient do? I could not find any details.
I tried setting max_vel, kp, and kd. But I am unsure about the magnitude. What are the default values, and would you recommend increasing or decreasing the values? And by how much would you change them?
Also, thank you for the suggestions on optimizing the maize integration. I will try that sometime soon.
The sdformat.org has descriptions and default values for different tags (e.g. for kp or for resitution_coefficient)
Restitution coefficient refers to how "elastic" collisions are. A perfectly elastic collision (value of 1) would conserve momentum (think billiards balls hitting each other). A perfectly inelastic collision (value of 0) would be the two bodies "sticking together" essentially.
For starting points, I would suggest max_vel < 10, but you could go lower if you dont expect/want things to bounce around. kp could be something like 1e8, kd could be something like 1e4, but they may take some tuning.
This link also gives a decent overview of different parameters and some video examples of how they impact the sim.