DOF effort maybe incorrect

A positional controlled rotational DOF appears to deliver too much torque. Is this a mistake on my end or is there a bug in Isaac Gym?

A joint is targeted to hold a rigid body in a 90 degree angle with gravity.
Arm length: 0.08. Verified using get_actor_rigid_body_properties, the COM is 0.08 indeed. I assume meters.
Gravity: [0,0,-9.81]. Set in sim_params.gravity (gymapi.SimParams), up axis Z. I assume m/s^2.
Effort of joint: 0.948. Verified in the isaac gym UI. I assume Nm.

I would expect this system to hold steady about 1.2kg. However, the system confidently holds up over a 100kg. For larger values the system finally gives in.



Switching from the GPU pipeline to the CPU pipeline may give the correct value.

Do you know if that is a bug in Isaac Gym? (I assume so?) If not, do you know how I can fix that?

No. But you should rewrite the “pipeline” in config.yaml from “gpu” to “cpu” and see what happens when you run it. If it displays the correct value, then there is a bug.

Ah I don’t use the config yaml, I directly use the python interface. I use the CPU pipeline. I will try if there is a difference when running on GPU.

I recently tested isaacgym with a simple pendulum and it seems that the limitation for effort never works for simulation. Maybe that’s the reason why the torque is much larger than expected: it is just controlling it with PD controller without torque limitation. Considering the large stiffness of your controller, it might explain what you have experienced. Seems like a bug of isaacgym and I have no idea about how to fix it.

1 Like

I still encounter the same problem as well.

If Isaac gym works like other softwares (Matlab SimScape) Stiffness should be zero unless you have a spring in your system. That 600 damping is too much as well, 0.1 make sense. Another thing I noticed is that the type of the joint in the URDF file should be revolute not continuous, continuous joints show different behaviors.
I did the same thing while ago and it was working perfectly, I managed to replace a simple PID controller with a NN which was trained using RL, I used effort control.
Another thing you can check is the times steps, see if it’s small enough (0.001 s), otherwise the simulation might not converge.

check this post here :

1 Like

From the documentation:
The controller will apply DOF forces that are proportional to posError * stiffness + velError * damping.
Stiffness corresponds to the positional error, so I assume it must be nonzero. Damping could be set to 0.

The values I use for drivemode DOF_MODE_EFFORT come from the following part of the documentation:

props = gym.get_actor_dof_properties(env, actor_handle)
gym.set_actor_dof_properties(env, actor_handle, props)

Maybe the values are indeed to large, but the max effort is not actually functioning as maximum effort and should be unrelated to the PD controller?

As I remember max effort doesn’t work when you are working in effort mode, but should be in effect when you are using velocity or position control. In effort mode the Damping is viscous friction, which in reality is around 0.001 N.m/(Rad/s). In other modes damping is a combination of physical friction + virtual friction or in total Kd.
I think In effort mode the stiffness works like a spring, in other modes it’s Kp.
Those numbers in the example are for position control, but they are still high for a real controller. check this post here:

Sorry I made a copy paste mistake. I am indeed using DOF_MODE_POS. I am under the impression that max effort functions similarly to force=min(max_effort, desired_force_by_controller). Do you think my understanding is incorrect?

Yes, when in the Position control mode the maximum efforts are in effect. I did a test to confirm it.