Closed articulation simulation problem

Did you see better behavior with the knee vs paw break?

I would setup the non-actuated joints with a joint drive with zero velocity target and some damping (and zero stiffness).

No not really.

We are now just modeling one of the legs. This is because we have done some real-world jumping tests on just an one-legged setup (only one motorhousing + leg), and we now want to checkout the sim-to-real gap of our model. The real-world leg was hold in place with a rig, which we just model with a vertical prismatic joint between “world” and motorhousing. It looks like this:

image

This is a lot more stable than the full quadruped. It seems to work fine with angular drives on the hips and just some friction on the knees. But since we need to model some springs as well, we need to make our own motor drives. We try to use the “apply_action” method from the articulationview instance, but this is results in less stable simulations even though our own PD controller has the same stiffness and damping values as when using the build-in angular drives. Is there a better way to implement our own controller?

Yes, please check out the actuator network that was successfully used to model actuator dynamics: https://arxiv.org/pdf/1901.08652.pdf

A key is also to run much higher simulation frequency to capture the high-bandwidth actuator dynamics.

Thanks, we will check it out!

I experimented with various settings and I found that it is possible to create a stable outcome.

Solver type : PGS
Enable gpu dynamics : ticked
Minimum position iteration count : 4
Minimum velocity iteration count : 1
Maxumum position iteration count : 4
Maximum velocity iteration count : 1
Timesteps per second: 480

The key change is timesteps per second. I appreciate this is computationally expensive. With a value of 240, I had a stable outcome but there was some unwanted oscillation. Smaller timesteps (smaller than 1/60) appear to lead to better outcomes.

It’s very hard to tell if we just need very small timesteps for this asset or if there is a bug lurking somewhere in physx. There is some joint separation visible at larger timesteps and that points to a bug in physx because this should not happen with an articulation. We’ll need to really dig in to this to determine the true source of the problem.

Hi @gyeoman,

What robot are you talking about?
My ANYmal with adaptive feet, or @finn.gross.maurer 's four bar linkage quadruped?

Thanks a lot.

Antonello

Sorry, I should have been more specific. I was referring to the four bar linkage quadruped.

@gyeoman Thanks for the information. We will check it out!

It’s been a while since the last answer but I tested a bit with the simplified quad leg robot that was shared in this thread. I suspect that the mass ratios present in that scene are too extreme for the solver. This might improve in future versions but so far I can only give a work around: Switching to the PGS solver helped. That solver has a bit a slower convergence but is more forgiving in scenarios of big impacts that can cause an instability and an explosion (making the robot disappear) for the TGS solver. Increasing the sim steps per second from 60 to 120 does also help. Both settings can be found on the physics scene object in the Stage view. If the TGS solver should be used, less extreme mass ratios can help. I created a file that allows to control the masses through densities of 3 rigid body materials in the scene instead of setting them through the mass API.
quadruped_closed_loop_modified_mass.zip (25.0 KB)

Thank you very much. We are currently running on PGS with 480Hz, since we are also simulating a nonlinear spring in the setup. We will try to look at the mass ratios and check if they are correct.