Hi, I'm working with the MoBL_ARMS upper limb model and am having trouble getting CMC to run. We have joint angles for each coordinate in the model and are attempting to find the torques necessary to have the model track the measured motion. Using Inverse Dynamics gets an approximation, but we want to have the model follow the motion a bit closer. Our thinking was that we could create actuators for each joint as "reserves" and disable or remove all the muscles, then run CMC to get torques in a control file that control the model very well.
OpenSim never is able to get past the first time step and pops up with the familiar message:
"CMC.computeControls: ERROR- Optimizer could not find a solution.
Unable to find a feasible solution at time = 0.
Model cannot generate the forces necessary to achieve the target acceleration.
Possible issues: 1. not all model degrees-of-freedom are actuated,
2. there are tracking tasks for locked coordinates, and/or
3. there are unnecessary control constraints on reserve/residual actuators."
I've attached my actuators file containing the reserves actuators as well as the control constraints and tracking tasks files. They are pretty generic, basically like the ones listed in the documentation but adjusted to match the models coordinates and I've allowed the controls to be boundless with the plan to work it down from there. Thanks in advance for any help you can provide!
-Daniel
CMC troubles with MoBL_ARMS model
-
Ross Miller
- Posts: 375
- Joined: Tue Sep 22, 2009 2:02 pm
Re: CMC troubles with MoBL_ARMS model
Hi Daniel,
I've gotten this error for gait simulations when I'm sure none of the three suggested issues are occurring (all DoF are actuated, no tracking tasks are defined for locked coordinates, and the actuator control bounds are sufficiently wide). The source of the problem ended up being that for some muscles in the model, the length parameters (optimal fiber length Lo, unloaded tendon length Lu) were either way too short or way too long for CMC to find initial values for them at the first timestep.
I identified which muscles were the problem by calculating Lo+Lu for each muscle and comparing this length to the muscle origin-to-insertion length Lm when the model was in its default pose. To fix the issue, for muscles where Lo+Lu was very different from Lm, I scaled Lo and Lu such that Lo+Lu = Lm. The problem muscles were all custom muscles that I had added to the original model I was working with.
Edit: Also, another related issue can be if the muscle's ActiveForceLengthCurve is too narrow. The typical range of ~ 0.5-1.5 Lo from muscle fiber experiments is too narrow in many cases for movement simulations.
Hope this helps,
Ross
I've gotten this error for gait simulations when I'm sure none of the three suggested issues are occurring (all DoF are actuated, no tracking tasks are defined for locked coordinates, and the actuator control bounds are sufficiently wide). The source of the problem ended up being that for some muscles in the model, the length parameters (optimal fiber length Lo, unloaded tendon length Lu) were either way too short or way too long for CMC to find initial values for them at the first timestep.
I identified which muscles were the problem by calculating Lo+Lu for each muscle and comparing this length to the muscle origin-to-insertion length Lm when the model was in its default pose. To fix the issue, for muscles where Lo+Lu was very different from Lm, I scaled Lo and Lu such that Lo+Lu = Lm. The problem muscles were all custom muscles that I had added to the original model I was working with.
Edit: Also, another related issue can be if the muscle's ActiveForceLengthCurve is too narrow. The typical range of ~ 0.5-1.5 Lo from muscle fiber experiments is too narrow in many cases for movement simulations.
Hope this helps,
Ross
-
Josh Baxter
- Posts: 29
- Joined: Fri Mar 11, 2016 12:29 pm
Re: CMC troubles with MoBL_ARMS model
Ross makes a really good point that I think gets over looked a lot. Simulations are super sensitive to MTU length - especially tendon slack length. Rajagopal+ 2016 describes how the opensim MTUs are tuned. This is also sensitive to the joint position when tendon slack length is adjusted.
One way to diagnose these slack length problems is to run the CMC, let it fail, and then plot the muscle activation from the computed states file. This will show which muscles are 100%... it may be that their tendon slack lengths are too long or the antagonist muscle tendons are too short, which increases the passive moment during movement and requires greater muscle excitation to counteract.
One way to diagnose these slack length problems is to run the CMC, let it fail, and then plot the muscle activation from the computed states file. This will show which muscles are 100%... it may be that their tendon slack lengths are too long or the antagonist muscle tendons are too short, which increases the passive moment during movement and requires greater muscle excitation to counteract.
-
Dimitar Stanev
- Posts: 1096
- Joined: Fri Jan 31, 2014 5:14 am
Re: CMC troubles with MoBL_ARMS model
Hi Ross,
Could you upload the updated MoBL model somewhere?
Regards
Could you upload the updated MoBL model somewhere?
Regards
-
Ross Miller
- Posts: 375
- Joined: Tue Sep 22, 2009 2:02 pm
Re: CMC troubles with MoBL_ARMS model
Hi Dimitar,
In my example I was not using the MoBL_ARMS model, I was working with the Rajagopal full-body model.
Still making some tweaks but I will probably upload our version later this week: https://simtk.org/projects/umdnrc
Ross
In my example I was not using the MoBL_ARMS model, I was working with the Rajagopal full-body model.
Still making some tweaks but I will probably upload our version later this week: https://simtk.org/projects/umdnrc
Ross
-
Daniel Free
- Posts: 2
- Joined: Fri Jul 28, 2017 1:52 pm
Re: CMC troubles with MoBL_ARMS model
Thanks everyone for your replies!
Turns out my initial problem was with my Tasks file. At least, a colleague was able to get it to run and when we compared files that was the only difference. In case you are interested in what was different, my tasks file included all the internal joints that are dependent on the main coordinates that you can control through the GUI. My colleague's task file didn't contain those and ran smoothly.
I'm sure I'll run into more issues, so thanks for the heads up on some of these possible traps!
Best,
Daniel
Turns out my initial problem was with my Tasks file. At least, a colleague was able to get it to run and when we compared files that was the only difference. In case you are interested in what was different, my tasks file included all the internal joints that are dependent on the main coordinates that you can control through the GUI. My colleague's task file didn't contain those and ran smoothly.
I'm sure I'll run into more issues, so thanks for the heads up on some of these possible traps!
Best,
Daniel