You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tvdbogert edited this page Sep 2, 2014
·
1 revision
[by TvdB]
This is not an urgent issue, but more a long term goal. Anne won't need any of this, as far as we know now.
Jason is already developing control system identification for a torque-driven model. Sandy will eventually need to do this for a muscle-driven model which is what we have here. The muscle-based controller identification may evolve from Jason's tool, or from optim2d. Here I am discussing the latter option.
The optim.m code is close to what is needed, but some of the required changes will be:
We need to be able to do this at (for instance) 24000 nodes which would be 50 nodes per second for 8 minutes. Does the performance of the code scale well? This is already easy to test, simply set N=24000 and optimize a full or half gait cycle. The time-critical part may be filling the constraint Jacobian in the "conjac" function in optim.m.
We need to be able to turn off the periodicity constraints (which are only needed if we only simulate a full or half gait cycle).
We need a cost function that only tracks the human data, probably joint angles. I think we may already have this.
We need capability to optimize controller parameters along with the state and control trajectories. Controller should be added as a "path constraint" that says that u is a function of x with parameters p.