Euler rigid body equations

[EelcoHoogendoorn]

Trying to digest the internals of brax's integrator, it does not seem like there are are any terms in the integrator accounting for the nonlinear terms in Eulers rigid body equations; the torques that the body applies to itself as a result of its own rotation, and its quest for momentum conservation.

Making a rectangular box with three different inertia components, and spinning it around its medial axis with a little perturbation, shows that it indeed does not obey the tennis racket theorem. It does spin in a stable manner about its medial axis; which it isnt supposed to.

I was curious if this is a deliberate simplification of the dynamics, since this higher-order consequence of momentum conservation is rarely relevant in RL research; or if its be useful to try and fix that deviation from reality?

[EelcoHoogendoorn]

Reflecting on this a little; I suppose the current implementation can be viewed as a linearized version of the equations of motion; the missing terms are only those quadratic in the angular velocities. So for 'small' angular velocities, it should not matter. However, that doesnt mean you might not notice the difference in everyday situations though; you can experience the real world consequences yourself by tossing a tennis racket into the air so you hardly need super exotic conditions for this to be a relevant factor.

Still, I suspect it wouldnt make much of a noticeable difference for any of the RL benchmarks ive seen. Then again I cant say ive tried. But also, it wouldnt be very hard to get the physics right either, nor do I think it would lead to much of a noticable runtime overhead.

[btaba]

MJ supports various integration schemes, demo:
https://youtu.be/0Cxl67X5wfg?si=0vEs0-9usTLcJwnC

[cdfreeman-google]

Hello!

You're absolutely right, we're missing this term--this came up in an old issue where I very confidently proclaimed that this was not an issue, but was completely wrong, which I cannot for the life of me find, right now.

It's been on my todolist to check whether introducing this term is actually bad for perf. PRs welcome if you get to it before I do :)

[AlessandroZavoli]

What is the problem with fixing this issue? If you point me the file/function I can try to add this term.

[EelcoHoogendoorn]

The problem for me is that my employer is still working out its open source contribution policy.

On the technical side, on the surface there isnt much to it. Digging a little deeper, one subtlety is that a straightforward integrator of these nonlinear terms tend to accumulate energy. Nothing that cant be fixed with some rotational damping I suppose; but im not sure whats considered best practice at the moment; I guess some diggin in the source of other rigid body physics engines might help. I doubt its a problem for any of the actual scenes implemented thus far, since they all deal with constrained bodies anyway, not with freely and fast rotating ones.

There might be RL/gradient propagation specific issues pertaining to this; I dont know, I guess this will be one of the first tests of those questions. But I doubt it; we are talking about smooth functions here.

[AlessandroZavoli]

The problem for me is that my employer is still working out its open source contribution policy.

Ok, I understand this

Digging a little deeper, one subtlety is that a straightforward integrator of these nonlinear terms tend to accumulate energy.

I don't get this one. you probably want to change the integration scheme according to the dynamics, not the other way around.
If classical runge-kutta-4 is not suitable in this application, one might consider implicit schemes. This could be left as an option for the user, according to his needs. I mean, in certain application if the physic is not "physic" (i.e., you miss second-order terms) it is not useful having something that do 1M steps per second.

[EelcoHoogendoorn]

RK4 is definitely more energy-stable from what ive gathered; but it does not provide any guarantees. should be easier to find a balance with some minimal damping though.

I agree, youd want to adapt the integrator to the needs of the dynamics; but there are other things to consider. How will such an integrator interact with the velocity/impulse type constraint resolution, for instance? Maybe its actually trivial, not sure. Also RK4 might add meaningful overhead to consider, to brax as a whole? I doubt it though; the per-body updates seem like they shouldnt dominate the compute for any reasonable scenario.