Gazebo | Ignition | Community
Ask Your Question
0

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

asked 2022-01-31 13:04:58 -0500

simonsure gravatar image

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.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-03-16 11:24:31 -0500

shonigmann gravatar image

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)

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2022-01-31 13:04:58 -0500

Seen: 468 times

Last updated: Mar 16