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

Static Optimisation using muscle equilibrium #2404

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

pariterre
Copy link
Contributor

@pariterre pariterre commented Jan 21, 2019

Fixes issue #500

Brief summary of changes

Static optimisation (without linearization) now solves for muscle equilibrium when calculating the acceleration. So instead of solving the "realize acceleration" via a an infinite tendon stiffness assumption, it now solves for the proper equilibrium.

Testing I've completed

None, this breaks the previous values that were considered as reference.
In that sense, I will need your opinion on what I've done.

CHANGELOG.md (choose one)

  • added the following mention sentence into the "Other changes" section:
  • Static optimization now solves for muscle equilibrium.

This change is Reviewable

@pariterre pariterre changed the title Fixing Static Optimisation [WIP] Static Optimisation using muscle equilibrium Jan 22, 2019
@pariterre pariterre changed the title [WIP] Static Optimisation using muscle equilibrium Static Optimisation using muscle equilibrium Mar 18, 2019
@pariterre
Copy link
Contributor Author

Up?

@aymanhab
Copy link
Member

@aseth1 Can you comment on whether this functionality needs to be supported by mainstream OpenSim rather than as a plugin?
@pariterre can you say whether this would change previous results of staticOptimization and if so how?

@pariterre
Copy link
Contributor Author

pariterre commented May 17, 2019

@aymanhab
Thanks for you comment! It would definitely change previous results as it computes for muscle equilibrium unlike the previous implementation.

The idea is to linearize at the point of previous activation instead of full activation. My implementation doesn't fully mimic what happens if you don't linearize at all (that is commenting the line that defines USE_LINEAR_CONSTRAINT_MATRIX), but is way closer than the actual linearization. For instance, for the arm26, the actual implementation shows differences up to 30% while this new linearization method show differences up to 2%.

As an outside project, I've also coded a way to use the non-linearize method by approaching the constraint jacobian by series of cublic spline. It therefore constructs the Jacobian at the beginning of the optimization and then approximates it using the derivatives of the spline. Using this method, I get almost no difference with the non-linearized method. However, it takes about twice the time than the linearized method (which is still almost 500X faster than original non-linear method). I did not planned to PR this method to OpenSim though, unless you guys think that it would make sense to do so..

Thanks!

@pariterre
Copy link
Contributor Author

Up?

@pariterre
Copy link
Contributor Author

@aymanhab
I fast-forwarded the PR to fit the master
thanks :)

@chrisdembia
Copy link
Member

@jimmyDunne I'm happy to help review this after discussing with the dev team what we want to do.

@jenhicks
Copy link
Member

@pariterre Thank you for making this (and other) pull requests! It is great to have contributions from the community. Since this is a pretty large addition to the code, could we set-up a time to talk via Skype about how best to incorporate this work? You can email us at opensim@stanford.edu and we can arrange a time to chat. Thanks again!

ScalarActuator* act = dynamic_cast<ScalarActuator*>(&fs.get(i));
if (act) {
if (act->getMinControl() != -INFINITY)
_parameters[j++] = act->getMaxControl();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean act ->getMinControl()?

Copy link
Contributor Author

@pariterre pariterre Dec 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the error is in the if. Unfortunately, contrary to what is previously done, the initial guess on the first frame has to be maxControl. The reason is that I linearize between 0 (actually MinControl) and value from previous frame. If we set the previous frame to be minimal, it is a singularity. Setting it to max solves to the same value as the previous linear version : the problem being quadratic when p=2 and therefore the solver finds a good optimal solution even though I initialize at max.

@pariterre
Copy link
Contributor Author

Up? :)

@pariterre
Copy link
Contributor Author

Up? @aymanhab

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

Successfully merging this pull request may close these issues.

None yet

4 participants