-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forward projection in PD control (GetSPDForces) #20
Comments
Hi koonyook, please refer to the paper : Quick answer: Main reason why we use such kind of implementation is for the stability. Stable pd control enable us to simulate physics with large time step, reducing computational cost for the simulation. It is definitely possible to use other types of controller such as simple pd control, pid control, or some basic position-based control. |
Thank you for your prompt reply. I've found that implementations in this repository are fundamentally different from the formulas in your SIGGRAPH paper and I'm not sure which one is the better version. Should the loss_target compare "acceleration at joints" [q_dot_dot_d(u) vs q_dot_dot(a)] like being stated in the paper? or Should the loss_target compare internal force (generalized force generated by muscle) [tau_des vs Jt(Aa+p)] like being implemented in this repository? In the code, it is simply L=JtA and b=Jtp which is not the L and b defined by the paper. This difference seems to link tightly to the origin of the target of SPD formulation. The function GetSPDForces in this repository follows the SPD paper and produce mDesiredTorque which become tau_des later on. tau_des is then compared to Jt(Aa+p) which is just the internal force (and not q_dot_dot). |
I'm comparing equation 10 in the paper and the function GetSPDForces in Character.cpp.
I've found that p_diff is from a comparison between the p_desired and the linear estimation of q to the next time step (q + dq*dt).
I also assume that the term v_diff - dt*mKv.cwiseProduct(ddq) is using a forward projection of dq to the next time step (dq + ddq*dt). This projection seems to cause some significant complication to the calculation of ddq.
Main question:
These forward projection of q and dq are uncommon in PD control. Is there any specific reason not to use just q and dq of the current time step without the projection?
Additional questions:
Why dt*mKv.asDiagonal() is needed to calculate M_inv ?
Why p_diff+v_diff is used in the calculation of ddq ?
The text was updated successfully, but these errors were encountered: