Question about the default PD drive in reduced coordinate articulation

[arpspoof]

Hi,

I'm trying to compare PhysX's default articulation PD drive (reduced coordinate) with a standard handwritten PD controller (tau = kp(targetP - p) - kdv). The default one works very well. It is stable even with super large kp parameters and large time steps.

Looks like the default controller calculation is in FeatherstoneArticulation::setupInternalConstraintsRecursive. However, the calculation code seems neither to be a standard PD controlling algorithm nor a standard stable PD control algorithm (SPD) mentioned in this paper https://www.cc.gatech.edu/~turk/my_papers/stable_pd.pdf . Seems like some pose stabilization method is integrated to the calculation to make it stable. For research purposes, may I consult you some technical details behind this calculation ? I.e, which exact algorithm is used for the PD control calculation ? Is there document available for the public to read ?

I'm not sure if this is the correct place to ask this question. If it is not, may I get some contact info about the correct person to ask this question (is possible)?

Thank you.

[zijiaozeng]

I'am facing the same problem, have you got the answer?

[kstorey-nvidia]

The approach being used is an internally-derived implicit spring formula that is used not only in the reduced coordinate articulations, but also in the D6 joints (for both soft limits and drives).

The approach being used allows us to solve both hard and soft constraints using the same code with only variations in the parameters. As such, when the stiffness or damping terms become very large, the results become numerically equivalent to a hard constraint rather than becoming unstable.

I have asked internally to see if we can get our internal white paper on it included in future public documentation.

[zijiaozeng]

The approach being used is an internally-derived implicit spring formula that is used not only in the reduced coordinate articulations, but also in the D6 joints (for both soft limits and drives).

The approach being used allows us to solve both hard and soft constraints using the same code with only variations in the parameters. As such, when the stiffness or damping terms become very large, the results become numerically equivalent to a hard constraint rather than becoming unstable.

I have asked internally to see if we can get our internal white paper on it included in future public documentation.

Thank you very much for your reply, but I still have some doubts about default PD drive.

The implicit spring formula in PxD6Joint.h is force = spring (target position - position) + damping (targetVelocity - velocity), amazing control performance the approach optimized by some constraints, even much better than Stable PD, can you tell me where is the implementation of the algorithm?

Thank you.