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

Opened new branch [edo] for the inverse dynamics solver #32

Open
edoardolamon opened this issue May 6, 2019 · 3 comments
Open

Opened new branch [edo] for the inverse dynamics solver #32

edoardolamon opened this issue May 6, 2019 · 3 comments
Labels
bug Something isn't working

Comments

@edoardolamon
Copy link

Hi,
in the [edo] branch you can find the integration of the inverse dynamics solver OpenSotAcc with the Cartesian Interface. Tested on fixed base robots, there are some issues with the velocity limits (added in the constraints of the stack.yaml file). In this case, the solver seems to not to converge, while removing them seems to improve the convergence. Moreover, it is needed to fix the lambda values, that are not consistent with the kinematic version of the solver and to add the lambda_1 and lambda_2 variables.

@EnricoMingo
Copy link
Contributor

EnricoMingo commented May 7, 2019

Ok so let's use the power of markdown, we have three issues at the moment:

  1. Velocity Limits which looks like should be tuned for the acceleration level control
  2. lambda consistency with the velocity level control
  3. lambda1 and lambda2 tuning

I will add check boxes as well to track the ones which are done:

  • Velocity Limits
  • lambda
  • lambda1 & lambda2

@EnricoMingo EnricoMingo added the bug Something isn't working label May 7, 2019
@EnricoMingo
Copy link
Contributor

For what concern issue 2: the lambda in the velocity level control is independent from the control rate, while te one of the acceleration is dependent. I suppose that to make the second one independent and equivalent we should divide the value by dt^2 (and for lambda2 by dt).

@edoardolamon
Copy link
Author

The values of lambda1 and lambda2 are now set correctly but in the stack file we read lambda that is consistent with the kinematic version of the solver. In a future update we wil be able to set them directly in the stack file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants