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