gazebo unreasonably slow with simple world and robot (on GPU PC)

Question

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_robot/blob/simulation/dev_ws/src/field_robot/models/robot/robot.urdf

This is the world file: https://github.com/fieldrobot/field_robot/blob/simulation/dev_ws/src/field_robot/models/worlds/main.sdf

This is my launch file: https://github.com/fieldrobot/field_robot/blob/simulation/dev_ws/src/field_robot/launch/simulation.launch.py

This script spawns the robot model: https://github.com/fieldrobot/field_robot/blob/simulation/dev_ws/src/field_robot/scripts/robot_spawner.py

The maize models, height map, textures, etc. can be found here: https://github.com/fieldrobot/field_robot/tree/simulation/dev_ws/src/field_robot/models

Everything and more is included in this package: https://github.com/fieldrobot/field_robot/tree/simulation/dev_ws/src/field_robot

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.

---

Originally posted by simonsure on Gazebo Answers with karma: 3 on 2022-01-31

Post score: 0

Answer 1

This was discussed a bit on ROS Answers already, but I'm moving my commentary here as it ended up being Gazebo related.

My comment 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 4ms, but you set the update rate to 1000 (so 4x speed). Also note that the real_time_factor tag doesn't do anything to my knowledge.

@simonsure 's response 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:

https://youtu.be/g0k68n2qNIA https://youtu.be/lyT6lPNSK-Q 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?

My reply 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_coefficient to a small or zero value will help prevent bouncing, reducing the max_vel (and contact_max_correcting_vel within the physics tag) contact parameter will help maintain contact between two surfaces. You can also try modifying the min_depth, stiffness and damping (kp and kd) 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 your max_step_size smaller. 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 a lot more reliable.

For the maize models I would suggest using population tags 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.

@simonsure 's response 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.

My reply The sdformat.org has descriptions and default values for different tags (e.g. for kp or for restitution_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.

---

Originally posted by shonigmann with karma: 16 on 2022-03-16

This answer was ACCEPTED on the original site

Post score: 0