Gazebo | Ignition | Community
Ask Your Question
0

What could cause a decrease in Real Time Factor to 0.07

asked 2021-03-22 04:15:18 -0600

igricart gravatar image

updated 2021-03-22 04:29:08 -0600

Currently, I have a simulation of a heavy machine and I import its stl model as a collision.

I basically have a joint on top of a car, that, when lifting up above 12 degrees causes my Real Time Factor to decrease from 0.47 to 0.07, and when I remove the collision tag (or add a small box instead) for that joint, it works smoothly. By visual inspection, I couldn't find any source of collision. I have tried solving by using those parameters as well:

    <physics type="ode">
        <real_time_factor>1</real_time_factor>
        <real_time_update_rate>1000</real_time_update_rate>
        <max_step_size>0.001</max_step_size>
        <max_contacts>1</max_contacts>
        <ode>
            <solver>
                <type>quick</type>
            </solver>
            <constraints>
                <contact_surface_layer>0.001</contact_surface_layer>
            </constraints>
            <use_dynamic_moi_rescaling>1</use_dynamic_moi_rescaling>
        </ode>
    </physics>

I am having issues understanding what / where could be causing this issue.

Any tips on how to debug/solve friction?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2021-03-22 07:15:01 -0600

updated 2021-03-22 07:31:31 -0600

... when I remove the collision tag (or add a small box instead) for that joint, it works smoothly.

This sounds a lot like your STL mesh contains excessive geometry, i.e. too many triangles. To make your simulation step faster, you could decrease the complexity of the geometry. You can do that in several different ways; manually remodel the mesh in your favourite 3D graphics software (e.g. Blender) or use algorithm that does this for you automatically (e.g. Blender's Decimate Modifier or something like Open3D's simplify_quadric_decimation() if you want to do it programatically). If your model requires a lot of detail in certain parts (e.g. gripper where correct representation is important), manual remodel might work better for you because it allows you to only simplify parts of the mesh that matter less. It can often be desirable to have two different versions for each model - one for visual (detailed, with material) and one for collision (simplistic).

By visual inspection, I couldn't find any source of collision.

I don't have insight into the concrete implementation details, but collision checking is usually optimised in a way where bounding boxes around links are checked first (often axis-aligned bounding boxes). Collision checking with the mesh itself is performed as a fine-tuning step afterwards only if collision with the bounding box is detected. This assures that limited resources are wasted on objects that are far away, while still keeping all the detail up close. This could explain why your simulation suddenly slows down even if there is no visible collision happening yet (it was just being optimised). Please correct me if someone who worked in such area reads this.

edit flag offensive delete link more

Comments

Thanks for the quick reply! That solved my issue. I guess 500k as face count is not a good idea

igricart gravatar imageigricart ( 2021-03-22 08:22:47 -0600 )edit

Question Tools

2 followers

Stats

Asked: 2021-03-22 04:15:18 -0600

Seen: 365 times

Last updated: Mar 22 '21