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

edit

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 ... (more)