simtk.org

Hi guys,

Currently, I was planning to evaluate the effect of computing walking muscle states using CMC and MocoInverse. My aim was to use the same model and experimental data to have a clear picture of how different both algorithms are.

Since Moco necessarily needs DeGrooteFregly2016 muscle model, I decided to convert the actuators of the model I am using (Rajagopal2016) to such type and then employ the converted model as an input to CMC, and I did it. However, when I opened the converted model in Opensim the following warning comes up:

Object type DeGrooteFregly2016Muscle not recognized
Object::newInstanceOfType(): object type 'DeGrooteFregly2016Muscle' is not a registered Object!

In addition, CMC does not work because it does not recognized the muscle type (as expected). Thus, I would like to ask if there is a way that the muscle type DeGrooteFregly2016 is supported for CMC. I am using Opensim 4.1.

Any comments will be appreciated!

Hi Israel,

This is a great question. The DeGrooteFregly2016Muscle does not currently live in the main OpenSim repository, which the GUI uses, so trying to use this muscle in the GUI won't work. However, if you wanted to try using it via scripting you could do your comparison.

However, there is one problem with this: we have yet to get the DGF muscle to work reliable with tendon compliance dynamics enabled in explicit mode. Explicit tendon compliance dynamics is necessary for CMC and the ForwardTool which rely on time-marching forward integration.

You might be able to use the muscle CMC with tendon compliance disabled; I would actually be interested to hear how that works as I am currently working on the DGF muscle to support explicit dynamics.

-Nick

Hi Nick,

it is good to know that. I will do the simulations and will post the results in the Forum. I may take me some weeks since I expect it to do it with the experimental data from our lab and I have not done this before (Vicon and force place data to Opensim). I am also considering using data from literature perhaps, let see. Any news I will write them down here.

Israel Luis

Hi,

It has been more than a year since this discussion started. Since the Moco is officially in OpenSim and explicit tendon compliance is the default option, I assume that the two issues mentioned in Nick's previous post should have been resolved by now.

So, I wonder whether there is an definitive answer to whether DGF2016Muscle can be used in CMC? Has any one done any test on it?

Thanks!

Hi Xiao,

Yes, the DeGrooteFregly2016Muscle has been moved into the main OpenSim repository as you say, so you can give CMC with this muscle a shot now.

We added a few tests to OpenSim that use the DGF muscle with CMC, but these are only for very simple models, so your mileage may vary when running more complicated problems.

Best,
-Nick

I can confirm that the DeGrooteFregly muscle works just fine in CMC with OpenSim 4.3. I did a little experiment where I grafted the right vasti muscles from Ross Miller's 3D walking model (which are DeGrooteFregly muscles) onto the Rajagopal model (which has Millard muscles) and ran through CMC for walking with the setup files and data provided along with the Rajagopal model.

Initially I was getting warnings about exceeding maximum contractile velocity and tendon buckling, but these went away after I realized I hadn't adjusted fiber length and tendon slack length to match the scaled model.

I used Luca Modenese's muscle parameter optimizer to tweak the fiber and tendon slack lengths, and everything worked great. A nice byproduct of this was learning that Luca's tool works great even if the generic model has Millard muscles, but the target model has DeGrooteFregly muscles.

I ran CMC with Millard vasti muscles and with DeGrooteFregly vasti muscles to compare; results are in the plot below and look pretty reasonable. The only complaints or errors from OpenSim were during muscle fiber equilibration in the first timestep (during which CMC results aren't valid anyways).

Thanks John! It's great to confirm that it works for more complex problems.

Hi John,

Thanks for sharing your results. How many muscles were the DGF Muscle in the CMC simulation you ran? Were they only the three heads of vasti?

I have been able to get CMC to run in the simpler models (Gait10dof18musc and Gait2354_Simbody) coming with the OpenSim4.3 installation with all muscles replaced by DGF Muscle. There were warnings about exceeding maximum contractile velocity and tendon buckling, too. However, I could not get the Gait2392_Simbody to run CMC with all muscles replaced by DGF Muscle. CMC could not initialize. Any thoughts on that?

Hmm you seem to be right--it doesn't work with all the muscles replaced! In fact it looks like it's highly dependent on which muscles are replaced. I did some playing around with gradually replacing Millard muscles with DGF muscles to see if I can figure out what triggers the failure to initialize.

If I replace any (or all) the vasti muscles with their DGF equivalent, CMC works fine (as above). Ditto for some other muscles. But if I replace the rectus femoris, I get the same failure to initialize that you report (even if all the other muscles in the model are Millard muscles). It looks like this line of code is what's triggering the message about the muscle exceeding its maximum contraction velocity, which is what shows up during a failure to equilibrate.

I'll poke around and see if I can spot any trends that dictate whether a muscle will or will not fail to equilibrate. As I mentioned above, sometimes it looks like DGF muscles can fail to equilibrate but CMC starts just fine, while in other cases if enough muscles fail, the initialization as a whole fails and CMC can't start.

Hi all,

Some thoughts here on DGF and CMC:

(1) CMC even for a "very sub-max" movement like walking generally will not work well without reserve actuators at the joints and magic actuators on the pelvis (or whatever segment is the "base" segment). This is because the CMC workflow imposes generalized forces on the model that the model itself didn't and often can't produce (Hatze's "Fundamental Problem of Inverse Dynamics": https://doi.org/10.1016/S0021-9290(01)00158-0). So if you are trying CMC with a model that doesn't have those things, I would try adding them. Or similarly, try increasing the maximum muscle excitation bound to something above 1.0

(2) CMC I believe involves "inverting the force-velocity relationship", meaning it takes Fcc = f(Vcc) and solves for Vcc so that the CC length can be iterated forward in time. For this to work well in practice, the function needs to have a unique value of Fcc at every value of Vcc. Continuous functions like DGF often don't meet this requirement at fast velocities (they approach asymptotes). This is why some muscle models e.g. McLean et al. (2003) have special conditions for "fast eccentric velocities" to avoid this. I haven't looked at the code in OpenSim for the Millard muscle model but the text of Millard et al. (2013) sounds like it also did some tricks to avoid things like this. If a muscle model doesn't have a trick for this, it can combine with issue (1) above: model is moving in a way that is not possible for the muscles and is computing an impossibly fast Vcc or a negative Fcc or [some other bizarre case].

(3) MocoInverse is a nice CMC-type method (determine muscle forces for an inverse dynamics problem) that allows time-dependent cost functions, e.g. you can minimize metabolic cost over the entire movement rather than minimizing sum of squared forces/stresses/activations/etc. at each timestep independently. This is the application the DGF muscle model was initially created for: https://link.springer.com/article/10.10 ... 016-1591-9 (you will generally still need reserve actuators or supra-maximal excitations for this approach to work well; Fundamental Problem).

It would be great to get CMC working well and consistently with DGF muscles because CMC would be a great way of quickly (relatively) generating a "good" initial guess for an optimal control problem with a complex model. This is in my experience the hardest part of optimal control with complex models.

Ross