Skip to content
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

Open
koonyook opened this issue Nov 25, 2019 · 2 comments
Open

Forward projection in PD control (GetSPDForces) #20

koonyook opened this issue Nov 25, 2019 · 2 comments

Comments

@koonyook
Copy link

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 ?

@lsw9021
Copy link
Owner

lsw9021 commented Nov 25, 2019

Hi koonyook, please refer to the paper :
https://www.cc.gatech.edu/~turk/my_papers/stable_pd.pdf

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.

@koonyook
Copy link
Author

koonyook commented Nov 26, 2019

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.
In the given SPD paper, equations 9 and 10, the SPD formulation is used to target the internal force (generalized force generated by muscle) in the Lagrangian dynamics. Instead, equation 10 in your SIGGRAPH paper seems to target the q_dot_dot (desired acceleration at joints) in the Lagrangian dynamics. Which one is the correct target?

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants