Brax vs DMC Swimmer Example

[andrewwarrington]

Hi Brax,

I'm trying to use the swimmer environment, and am trying to understand the differences between the Brax implementation and the DMC implementation. I have made a script for procedurally generating Brax swimmers (BS) with different numbers of links, as the DMC Swimmer (DMCS) has environments with both six and fifteen links.

I am trying to understand how to match the two environments as much as possible, but there seem to be a multitude more parameters in BS than in DMCS. For instance, as far as I can tell at least, in DMCS xml file there is density, a gear (which I presume is the equivalent of a actuator), and a capsule mass.

In the BS implementation, there is capsule mass, density, viscosity, inertia, actuator strength, thruster_strength, body mass (somehow different to capsule mass?), friction and angular damping, some of which are in the python code, and some of which are in the _SYSTEM_CONFIG.

I was wondering if anyone has any ideas on how these values should be set to correlate with the DMCS, what each of these settings "do" etc. At the moment, my longer BS model moves with just random actions (as opposed to nice oscillatory movement under DMCS).

More generally, are there resources for trying to understand how Brax compares to DMC / the original MuJoCo.

Thanks for any help!

A

[btaba]

Hi @andrewwarrington, thanks for using brax!

We currently have a generalized physics engine similar to mujoco implemented in v2, example notebook.

We haven't implemented swimmer yet because we haven't added the viscosity term you mentioned. Otherwise the generalized backend would be quite similar to Mujoco if you wanted to implement swimmer. Here's an example for Ant - notice we read from a Mujoco xml.

As far as the other physics backends, spring and positional, the physics steps are very different in how they resolve constraints. You'll notice in v1 brax, there are two system configs, one for spring and one for pbd. Spring uses springs to resolve constraints (hence damping/stiffness), while pbd uses position based dynamics. The "thruster" in v1 was used to manually generate a viscosity term. So I wouldn't expect a training setting you have on Mujoco to work on spring/pbd. With that being said, we have spring/pbd backends implemented because they are much faster to run.

Hope that sheds some light, let us know if you have more questions!

[andrewwarrington]

Thanks for getting back to me! Looking forward to exploring V2!

Are you able to just expand on what you mean by a "generalised" physics backend vs a "spring"/"pbd" backend? My understanding is that there are various different ways to resolve forces, contacts etc, and that spring, pbd and generalised are three different approaches. Are you saying that spring and pbd are faster than generalised, but are some way less accurate or preferable to generalised? And that the generalised backend is more similar to the MuJoCo backend (that does feature viscous environments)?

Thanks!
A

[btaba]

Hi @andrewwarrington !

Viscosity can be implemented in any engine, as seen in v1. The generalized backend is similar to Mujoco, in that they both use featherstone's algorithm to create, and then resolve constraints in the system in a big linear equation. We have tests in v2 that compare generalized to Mujoco on humanoid, so the solvers are quite similar modulo different settings. Spring/pbd iteratively resolve constraints in parallel for the whole system, and with sufficiently small dt, these results converge.

[andrewwarrington]

okay, awesome, I think I understand. I will have a play around and see what I come up with! thanks for your help! :)