James,

Please see my replies below.

> I wish to import MoCap data into AnyBody. As is widely

> acknowldeged,

> the issue of DoF vs Constraints requires the careful selection of

> driven measures. Therefore I was considering using joint

> angles (and

> 3 translations eg pelvis) as the generalised co-ordinates as it

> appears easier to select a non-redunadant, non-overconstrain set.

> And because these angles can be readily calculated within Vicon’s

> BodyBuilder and dumped to C3D. The structure of FreePostureMove

> appears to be very close to this approach.

Yes, this is true.

> Naturally I will have to use a model with muscle for the inverse

> dynamics and therefore the question is…what modifications

should

> I make to FreePostureMove.main.any to include either a simple or 3-

> element Hill type muscle?

>

> I have tried commenting

>

>

#include “…\BRep\Aalborg\BodyModels\FullBodyModel\BodyModel_N

o Muscles.any”

>

> and uncommenting

>

> //#include “…\BRep\Aalborg\BodyModels\FullBodyModel\BodyMod

el.

> any”

>

> or

>

> //#include “…\BRep\Aalborg\BodyModels\FullBodyModel\BodyMod

el_

> Mus3E.any”

>

> but this causes an error.

You are doing it correctly.

I tried your model as well as the model directly from the

repository. In the repository model it is necessary to rename

PelvisThoraxFlexion.any to PelvisThoraxExtension.any, but you

already worked that out.

Both your model and the repository version fail in step 24 of the

analysis with a recruitment error. This error happens when there are

insufficient muscle forces or supports to balance the model, and in

spite of having more than 500 muscles on the model, this can still

happen in some postures because the mechanism is so complicated. The

problem is that the equilibrium equations become singular and hence

have no solution.

In numerical analysis, singularity is rarely an absolute property.

We use an optimization algorithm to solve the muscle recruitment

problem, and it can sometimes get “confused” by problems that are

too symetric or where the load in certain directions is very small

(thus requiring it to solve the problem 0 = 0). So this little trick

will make your model run:

Go to the study section of the main file and locate Gravity

specification. Then replace it by this:

```
Gravity = {0.001, -9.81, 0.001};
```

As you can see, this imposes are very small and entirely

insignificant gravity in the hrizontal directions. This is enough to

give the optimizer a road to solve the problem and it proceeds to

step 84 or so before failing with a similar error.

But this is very problem and movement dependent, so instead of

spending a lot of time making this version of the model run I

propose you go ahead and impose the movement you like on the model,

and if there is a problem with it after you have imposed the correct

movement and load, then we take it from there.

Also, I replaced the specification of the solver by this:

```
RecruitmentSolver = MinMaxSimplex;
```

It makes the analysis run a bit faster.

Finally, your version of the model seems to have too many reaction

forces compared to the number of degrees of freedom. This should not

make the solution fail, but it can cause instability in the muscle

forces the system computes. I have not analyzed where the additional

reaction forces come from, but they do not seem to be present in the

original version of the model.

Best regards,

John