Gazebo resources: Tutorials | Q&A | Documentation | Blog

Limits of the Simulation


Hi there!

I working on a simulation of train using Gazebo. The idea is to import a track from openstreetmap (or openrailwaymap) and create and load the needed models dynamically. In other words I planning to create the railway from waypoints (x y z roll pitch) and place objects around the railway like houses, bridges, signs, etc… Also the surface should be roughly created. It is not important to have a photo realistic simulation. At least I will mount some sensors in front of the train to be able to test assistant systems, up to a autonomous train.

So my questions to the community are now:

  • How big a world can be? Is the memory the only limitation or is/are there more. For example will the FPS drops if the world is to big?
  • My basic approach is to spawn objects in front of the train (~700m in front of) and delete the objects behind the train. Do I run in trouble? Can I use dynamically spawning or is it better to load all objects at the begin?
  • I not sure about if I should simulate the railway itself or just move the train (without physics, static object). What do you think? I guess to simulate a normal train driving on a railway will end up in some problems. At least I need swinging and bumping train for the sensor quality. I think it is possible to apply forces to the sensor without do it to the whole train. Of course then the sensors and the train would be different objects.

What do you think about the planned simulation? Is Gazebo the right tool? I’d appreciate your view!


Christian Merkl


Hi Christian,

That sounds like a fun project, I’ve never seen a train on Gazebo :slightly_smiling_face:

  • The FPS will drop depending on how many models you have on the camera’s frustum. You should be able to tweak the camera’s near and far clipping planes to limit how many models it is trying to process.

  • Another number which will drop as you add more models is the physics’ real time factor (RTF). You should make sure the models you add to the sides of the track are marked as <static>, so the physics engine ignores them for dynamics purposes. Depending on the sensors you’ll be using, you could also get rid of <collision>s so there is no collision checking against them.

  • Dynamically spawning and deleting objects on demand sounds like the right way to go for your use case. We did that in a smaller scale for the Space Robotics Challenge and it worked well.

  • If you’ll have a lot of sensors of different types which should be generating data that is consistent across them, I think it makes sense to let the physics simulation take care of the train. Of course, the simulation can be made arbitrarily complex, so it will be up to you on how much fidelity you want to put in. For example, you won’t have the train just sliding on a prismatic joint because there won’t be any swinging, but on the other hand, modeling the real track parts and the mechanical interactions between them could be overkill. It’s all about finding the right balance for your use-case.

Hope this helps!


Thank you for the reply,

Your answer helps me. I performed some performance tests and it seems only the memory is a limit in the simulation (without using the GUI. I think the camera of the GUI has no frustum limitation). But I got problems during the model spawning. Every time a model is spawned the simulation halts for short moment. I’m using a ROS service for spawning.

Is there a better way to spawn objects? Maybe I can use a plugin. How do you would spawn the models?




You can change the near and far clipping planes on the left panel under GUI, or you could have a plugin change it programmatically.

That would need some deeper investigation. I can’t think of a reason for the ROS to service to be less efficient than other methods unless it is blocking for some reason. The most likely reason is that the model is large and takes a bit to spawn. You could try spawning with the gz model command line tool and see if it makes a difference. Also, make sure you’re not using meshes which are more complex than they need to be.


Thanks again! Ok according your answer I think it is not a good idea to spawn continuously models, because I don’t know the final model size. Btw I used for the performance tests “house 1”, “house 2” and “house 3” from the gazebo model database.

Maybe it is better to pause the simulation after specific distances and spawn a group of models. Then go on with simulation. FYI I spawned a 10km long railway. On left and right side houses were placed. I moved a train on the railway including a lidar and camera up to velocity of 100m/s and it looks great. The camera published constant with the expected frequency.