Low simulation performance (Low real-time factor)

ROSDS Support
, , , ,
1

Dear Community,

I made a ROSject with a custom Gazebo environment using ROS 2 Humble and Ignition Gazebo Fortress. The ROSject is called “Leo Rover LunaLab”.

I seem to have performance issues when running it. The real-time factor jumps between 5% and 30% at best. I equipped the Leo Rover default URDF for the simulation with an added 3D LiDAR. I tried lowering the sensor resolution (number of lines) and the frequency, and yet, the real-time factor did not change. I also reduced the resolution (polygon count) of the environment, and I do not see a difference on the real-time factor.

My question is, how can I improve this real-time factor in the simulation inside the ROSject? When running in on my Ubuntu laptop, it is running with 90% real-time factor on 32GB RAM on an Intel Xeon CPU. I do not expect the same performance in the VM of the ROSject, but I do not seem to find a way to improve the performance.

The terminal does not give any errors that could point to any issues for the performance.

Let me know if you need additional information. Also, feel free to have a look at my public ROSject to investigate.

With kind regards,
Dave

2

Hi @dave.vandermeer1,

we did some tests like a month ago with a Leo Rover simulation, and indeed that RTF (Real Time Factor) was very low.

We noticed that if we ran the simulation in an empty world, the RTF would go better.

The main reason for this is that, by default, we assign ~2 cores and ~3.75GB of RAM for normal licenses.

For Enterprise licenses we assign ~8 cores and ~16GB of RAM, but if we compare it with your 32GB RAM, which probably also has more than 8 cores, I have to admit that our platform is not yet ready for resource-intensive simulations.

But even on your PC, using htop you may see that not all RAM or CPU or your computer is used when launching the simulation. That happens also because Gazebo physics doesn’t run in parallel. It’s a sequential task, and this happens with all the Physics Engines used by Gazebo (Gazebo supports 3 physics engines).

The best advice I can give for now would be to simplify the Leo Rover world. Test launching Leo Rover in an empty world to see the difference.

3

Hi @ralves ,

Thanks for your reply. I have seen the Mars simulation you created for the Leo Rover, and I think this scene looks quite complex compared to my LunaLab world. I do notice that you do not use any additional sensors in that simulation, and you ported it back to classic Gazebo.

I was wondering how I could improve the simulation performance. I have the following questions:

  • Should I look more into reducing the output of the sensors (lowering resolution and/or publish rate, or rather focus on reducing the complexity of the scene?
  • Are there any impacts on the simulation performance when using many visual elements with lots of polygons but without collisions (pure aesthetics), or is only the physics simulation with collisions impacting the performance?
  • Do LiDARs in Gazebo use the visual meshes or the collision meshes?

With kind regards,
Dave

4

HI,

I’ll try to answer your questions:

Should I look more into reducing the output of the sensors (lowering resolution and/or publish rate, or rather focus on reducing the complexity of the scene?

I’ve seen that reducing the resolution of the cameras has a great impact, also reducing the laser points and Pointcloud number. Also, the rates at which the publish also affects, the less the better.
I would reduce at least the sensors to sensible levels.

Are there any impacts on the simulation performance when using many visual elements with lots of polygons but without collisions (pure aesthetics), or is only the physics simulation with collisions impacting the performance?

Yes, polygons affect for sure, visually and in physics. The rule of thumb is: visual meshes reduce the polygon count but more importantly the collision meshes. It also helps to deduce the number of maximum contacts for each model. There is a tag for it. The less the better. And if you are not going to touch the objects, remove their collision tags entirely if you can

Do LiDARs in Gazebo use the visual meshes or the collision meshes?

Sadly yeah, the collisions are the ones that regulate the readings, so unless you need a super complex shape to be detected, there is no point in using complex collisions.

Also, static objects always help, and one thing that will also reduce consumption is replacing the complex terrain with the ground plane. Remove the ground plane visual element and that way you can replace it with a visually appealing 3D model.

Hope this helps, if you have any issue , please let me know :wink:

1 Like
5

Hi @dave.vandermeer1,

Miguel answered in the comment above, since the simulation I used was modified by him.

6

Hi there,
Thanks for the reply.

  1. and 2. are clear to me.

For 3. how do I make objects static?

And when changing the terrain to a ground place, I lose the geometry I would need for my environment. I do not want a flat terrain.
Do you know if DEMs are more resource efficient than meshes for the terrain?

One more question: for educational licenses, do they found as what you refer to “normal licenses” or do these count as “enterprise license”?

With kind regards,
Dave

7

Hi Dave,

To make a mesh static you just have to place the static tag to 1 in the sdf model definition. Here you ave an example:

<?xml version='1.0'?>
<sdf version='1.6'>
  <model name='keyboard'>
    <link name='link_1'>
         <visual name='visual'>
        <pose frame=''>0 0 0 0 -0 0</pose>
        <geometry>
          <mesh>
            <uri>model://keyboard/meshes/keyboard.dae</uri>
            <scale>0.2 0.2 0.2</scale>
          </mesh>
        </geometry>
        <cast_shadows>1</cast_shadows>
        <transparency>0</transparency>
      </visual>
    
    </link>

    <static>1</static>
    <allow_auto_disable>1</allow_auto_disable>
  </model>
</sdf>

Probably the mars terrain is already like that.

I understand the flat plane issue. DEMS form my experience are a bit more efficient but depend on the resolution also, and meshes give a very nice appearance an docntrol over it. Its worth the try.
Also reducing the number of contacts in each wheel can improve the performance.

Also take into account that in theocnstruct if you use a free licence or similar, you instance is really tiny, its like working with an intel pentium of the old days. Upgrading to the licensed that give you more power could improve a lot the performance. Also remember that sensors, field of view and number of data points affect a lot.

As for the licences topic I’m not sure, let me relay the message to someone that knows more about that :wink:

1 Like
8

Hi @dave.vandermeer1 , the courses included in the Educational Licenses are the same as for Normal licenses but at a lower price for educational institutions. The Enterprise courses are not included in the Educational pack

9

Dear all,

I will check if I can optimise the simulation environment.
Regarding the license, I have understood now.

Thanks for your help. Though I cannot tell, how much this will improve the performance, I will give it a try.

With kind regards,
Dave