The DOF velocities read using gym.acquire_dof_state_tensor are consistently wrong even when the joints are at a stand-still – this is making the PD controller exhibit very undesirable behavior. Changing the stiffness // damping on the joints seems to change the velocity value (even though the drive mode for all DOF is effort).
Read through replies to Inaccuracy of DOF state readings – tried all combinations of simulation-device // pipeline-device (CPU // CPU, CPU // GPU, GPU // CPU, GPU // GPU) and the bug persisted in all of them.
I also tried finite differencing: approximating dof_vel as (self.last_dof_vel - self.dof_vel) / self.dt. I verified the results with the joints clearly visually at zero velocity, and found on average across environments that the approximation is better – for example, here are some comparisons for one of the legs:
Joint | Avg. Vel. Approx. (rad/s) | Avg. Vel. Reported by DOF State (rad/s)
‘body_leg_1’ |-7.386238110029808e-08 | -1.239415496456786e-06
‘leg_1_1_2’ |-0.2129808217287063 | 0.7741525769233704
‘leg_1_2_3’ |-0.654631495475769 | 2.6179966926574707
However, this is still not good enough to use for torque PD control as in the legged gym examples, and these calculated torques and reported DOF velocities are also used in the reward function.
Reading 'Damping' and 'Stiffness' parameters effect on DRIVE_MODE_EFFORT has also been very helpful.
For DOF_MODE_POS and DOF_MODE_VEL there is a built-in PD controller that tracks target positions or target velocities using the stiffness and damping of the DOF set through gym.set_actor_dof_properties as p-gains and d-gains respectively.
In the legged_gym examples, they use torque PD control i.e. DOF_DRIVE_MODE is effort. There is no built-in PD controller for this drive mode so they explicitly write out their own PD controller in compute_torques and never set stiffness or damping when they call gym.set_actor_dof_properties. It’s worth noting that damping and friction of a DOF can also be read from the tag of the URDF file, but all of the examples have URDFs with no damping or friction in their tags. Stiffness isn’t a URDF element and can only be set through gym.set_actor_dof_properties.
I’ve found that even though stiffness // damping // friction aren’t used as PD gains in DOF_MODE_EFFORT they still have effects on the dynamics of the joints and so affect the estimated joint velocities. Setting friction to 1 gets my velocities to behave properly as far as I can tell right now.
Would like to clarify that I still haven’t resolved this issue. Once I unfixed the base mass and the robot came into contact with the ground plane velocities even with the friction solution became unreliable.
Setting stiffness and damping using gym.set_actor_dof_properties and using DOF_MODE_POS now instead of DOF_MODE_EFFORT is allowing me to hit target actions, but velocities are still erroneous which is making reward calculation, etc., unreliable.
Moved this discussion to DOF Velocity Offset at Rest