Fidelity comparison with MBDyn (or even MSC ADAMS) for very loopy kinematics structure, e.g. car suspension?

[lddllddl]

I have a use case for multibody dynamics that is more in the mechanical engineering sense, while I am also in the AI circle which makes me want to invest more time in MuJoCo than all those "Computer-aided engineering" software.

As far as I understand, game physics (e.g. Bullet, PhysX, Havok, Open Dynamics Engine), robotics simulation (MuJoCo, Gazebo), and tiltular "multibody dynamics simulation" (MBDyn, and the go-to commercial software MSC ADAMS) with their most representative use case in vehicle engineering, all carry out multibody dynamics simulation in principle, but with different design trade-offs and thus different underlying math.

Suppose that we want to engineer an actual car suspension system, and for some reason we just want to use MuJoCo instead of the most proven choice MSC ADAMS (or its open source alternative MBDyn). Perhaps, we want to use reinforcement learning to search for a better solution. Or maybe we need to engineer a parallel robot which is to be built economically (thus working much closer to the elastic limit of the material than typical expensively built robots).

In these cases, would some design choices of MuJoCo, even with solver parameters set in favor of fidelity, make it less useful than MBDyn/ADAMS?

One particular worry that I had from the official documentation was from

Among other applications, equality constraints can be used to create “loop joints”, i.e., joints that cannot be modeled via the kinematic tree. Gaming engines represent all joints in this way. The same can be done in MuJoCo but is not recommended - because it leads to both slower and less accurate simulation, effectively turning MuJoCo into a gaming engine. The only reason to represent joints with equality constraints would be to model soft joints - which can be done via the constraint solver but not via the kinematic tree.

A car suspension has a lot of kinematic loops, as well as hard joints. That said, all "hard" joint can be also considered "soft" with very large stiffness, so it might still work.

In particular, if all joints are modeled as in the quote, would generalized coordinates be reduced to Cartesian coordinates? If this is the case, could high-fidelity simulation still be possible at the price of computational efficiency by adjusting the solver configuration?

Search for similar discussions:

I have looked up a lot of reading materials, and surprisingly failed to find anyone including MBDyn (let alone ADAMS) in comparisons like Simulation Tools for Model-Based Robotics: Comparison of Bullet, Havok, MuJoCo, ODE and PhysX, not even a forum post bringing up both together. I am otherwise very convinced that MuJoCo is superior to other so-called "physics engines" in terms of fidelity.

Edit: Actually there is a paper bringing both ADAMS and MuJoCo into discussion:

Finally, by comparison with CAD/CAM/CAE, simulation in robotics poses unique and truly multidisciplinary challenges, some of them summarized in this document. While established commercial CAD/CAM/CAE solution providers, e.g., MSC.ADAMS, Siemens, Dassault Systèms, etc., are anticipated to gradually address the needs of the robotics community, our near-term hopes are pinned on nimbler and more focused platforms, e.g., Bullet (25), Chrono (36), DART (26), Drake (55), MuJoCo (35), ODE (24), and SOFA (56).

-On the use of simulation in robotics: Opportunities, challenges, and suggestions for moving forward

But the discussion is so general, not even getting into kinematic tree vs loop as far as in this post.

Since car suspension is the most representative use case, I was able to find one paper that used MuJoCo to model vehiclal suspension.

Ming, Liu & Yibin, Li & Xuewen, Rong & Shuaishuai, Zhang & Yanfang, Yin. (2020). Semi-Active Suspension Control Based on Deep Reinforcement Learning. IEEE Access. PP. 1-1. 10.1109/ACCESS.2020.2964116.

However the paper only contained simulation output from MuJoCo, no comparison to physical experiment or even simulation results from other software.

There are a few papers evaluating MuJoCo simulation against physical experiments, addressing the "Reality gap". However they are geared toward typical tree-like robots. MuJoCo did not out perform Bullet in these experiments, either.

Quantifying the Reality Gap in Robotic Manipulation Tasks

Validating Robotics Simulators on Real-World Impacts

[yuvaltassa]

In particular, if all joints are modeled as in the quote, would generalized coordinates be reduced to Cartesian coordinates?

Yes.

This introduces several complications. The biggest one being that there is no easy way to apply forces from springs, dampers and joint limits, which are often critical. One could do limits with colliding geoms which would work but be inefficient, and springs and dampers would require custom code implemented in a callback (though a fairly straightforward one).

If this is the case, could high-fidelity simulation still be possible at the price of computational efficiency by adjusting the solver configuration?

Yes, modulo the above qualifiers.

But as in the quote, it is not obvious why someone would want to do this. To clarify, the reason this is interesting to you is that you want some subset of the comparison between {MuJoCo reduced coords + few constraints, MuJoCo Cartesian + lots of constraints, some other engine (e.g. ADAM)}. Is this correct?

Check out the Robotiq gripper. This is a model with two 4-bar linkages, implemented with connect constraints (one per linkage is enough since the thing is coplanar).

Happy to hear your thoughts.

[lddllddl]

Here is a more concrete scenario about potential fidelity concerns.

Let's say our robot contains a steel tube, which is constrained by two spherical joints on both ends. So the steel tube is either compressed or pulled apart on two ends.

Then I want to explore how thin a tube I can replace this particular part with.
So I model this tube as a spring with a very large spring constant. Or maybe two rigid bodies with a 1-DoF prismatic joint in-between, but you have the idea. By "a very large spring constant", I mean that the elongation or compression would appear insignificant (if visible at all) to the naked eye, even in the real world, let alone in a visualized simulation. However, I am still very concerned about how much this minuscule elongation/compression exactly is, as the deformation is proportional to the mechanical stress the steel experiences (the coefficient depends on the exact dimensions of the tube, which we deal with separately). Note that the computed deformation could be very wrong even if the visualized simulation looks convincing.

So for a given spring stiffness, as well as mass/moment of inertia of this tube, I would like to simulate the robot in a variety of situations, and record the maximum absolute value of elongation or compression. If such a recorded maximum is beyond a certain value, it means that the tube is too thin and that we need to try a thicker one.

Note that such a mechanical element under pure tension/compression is both the easiest to model with, and the most efficient use of material in reality. And it can only exist in a kinematic loop to be fully constrained.

Traditionally this is done with e.g. ADAMS, for mechanical assemblies with moving parts. But what if we wanted to search for the thinnest tube that won't break, with reinforcement learning? Or maybe we wanted to train the control strategy of a robot that is built with such flimsy tubes (yet very powerful actuators), so that the robot moves in a way that it does not break itself.

[quagla]

That's certainly a very interesting scenario but I think it's more of a design problem which requires flexible multibody / FE simulations. I'm not sure Bullet or other physical engines would give reliable results.

What MuJoCo can offer is a plugin infrastructure, where you could implement your self-contained custom elastic material that can interact with the rest of the physics engine. So say that you define the open kinematics in joint coordinates (for everything that is assumed rigid) and you want to study a single flexible element (i.e. your cylinder) that closes the loop, you would define a new passive force component that takes in the displacement and velocity at the connecting points, computes the internal stress using a potentially expensive FE calculation, and then returns the forces at the connecting point. This would enable you to simulate the interaction accurately. Would this be what you are looking for?

EDIT: note that for the purpose of inertia calculations, MuJoCo would treat your new flexible component as if it was rigid (or made of primitive rigid geometries).

[quagla]

Hi @lddllddl are you still interested in your proposed scenario? I could give some help in writing a plugin if you are interested in that nonlinear spring.

[lddllddl]

Thanks @quagla . Sorry this has not been my priority for a while.
In general I don't think flexible body or non-linearity is necessary.
What I am looking into is more like trusses or space frames, but also with moving parts (somewhat related, and quite interesting from a robotics perspective, see https://www.youtube.com/watch?v=N_sndY-Aqvk , albeit with low stiffness and non-linear elements). And they can be modeled as a network of (very stiff) (linear) springs and mass distributions.

Where possible, I would like to avoid custom implementation or coupling with other simulation software, which kind of defeats the purpose of using an open-source, high-performance, easy-to-use library. It is also computationally wasteful to treat a steel tube loaded on two ends as further-divisible flexible body. In fact, even when flexible bodies are necessary, in place of external finite element calculation, a network of springs with mass distributions attached is itself a finite element model.

It should be also possible to compose structural elements other than struts, like simply-supported beams, out of a combination of joints, springs and masses, rather than with custom implementation. Note that while there is no such thing as material stress in MuJoCo, mechanical load can be equivalently obtained from springs or constraint forces.

Anyway, apart from closed kinematic loops, I now suspect that the situations where fidelity might be a problem are also characterized by

1. high stiffness (so that you can't tell if things are right by looking at visualization), or
2. high number of springs (or just constraints) on "load paths" (where errors might accumulate)

I would highly appreciate any pointers you could give, about why or why not these two situations may be a worry.

I have also come to realize that it is possible to design numerical (or even physical) experiments to exaggerate and measure the errors. E.g. we may see big differences across dynamic engines on a long cantilever truss. This could be suitable for publications that offset the effort invested in such validation or benchmark, so it might be a good idea for me to actually do the experiments - certainly with credits to people in this discussion.

[quagla]

I think it's useful to clear out some common misconceptions:

• A network of springs is not more efficient than a finite element simulation, provided that the two have the same resolution.
• In fact, piecewise linear finite elements can be seen as a network of springs where the stiffness depends on the shape of triangles/tetrahedra they belong to. The geometry dependence on the stiffness ensures that the result is much more accurate (i.e. less dependent on where you place the springs) and allows to separate volumetric and shear deformations, which is impossible with mass-spring systems.
• The only similarity between mass-spring and finite elements is that they have the same kinematics, i.e. they can indeed be discretised using the same degrees of freedom.

Concerning the other two questions:

1. High stiffness is mostly a numerical problem, i.e. it leads to ill-conditioned problems and requires small time steps. It's important to remember that deformations are important, but so are stresses. Indeed, you could see a large difference in stresses even for simulations where the displacements are visually nearly identical.
2. This is related to my previous list above. I don't think modelling a continuum with springs is correct, unless the continuum is indeed nearly 1D (e.g. a string). The underlying physical problem is smooth and we have to build a discretisation, not create some discrete model that might not converge to any limit as the number of springs is increased (see https://en.wikipedia.org/wiki/Schwarz_lantern for a fun example of failed convergence). This is why convergence under refinement is such an important test when comparing different methods.

So in general, I would think that most engines would not perform well when simulating a continuum using primitive objects. We have released the first true continuum model (see the examples in https://github.com/deepmind/mujoco/tree/main/model/plugin). Maybe this is a good starting point for comparing different engines? It would be really cool if you found that we are more accurate than other engines for these 1D continua simulations. Note that we haven't used joint springs for this, but the underlying model uses a 4th order differential operator (the same that you would need for a cantilever beam and indeed we recover the exact solution, see CantileverIntoCircle in https://github.com/deepmind/mujoco/blob/main/test/plugin/elasticity/elasticity_test.cc). I am working on 3D plugin that I hope I will be able to release soon.