CMC still failing on non-muscular model

[Sietse Achterop]

I have asked this before, also as an opensim issue 3679 , but still no solution. Hopefully this time around someone will find something!
The model, a few trajectories, IK and CMC setups can be found in

CMCerror_2.zip

(111.34 KiB) Downloaded 20 times

.

CMCerror.png (98.71 KiB) Viewed 1051 times

Think rower in a rowing boat. The model contains:

• A custom joint acting as a slider to move the boat

• A number of pinjoints

• Two custom joints acting a balljoints to model the shoulders

• A weldcontraint in the upper leg to close a kinematic loop

The custom joints are used because CMC seems to have problems with balljoints.
To get a feel for the model just simulate it after loading.
Using the IK setup the trajectory.mot can be created.

The problem is that CMC fails immediately with something like:

Code: Select all

[2024-01-14 16:56:45.428] [error] SimTK Exception thrown at InteriorPointOptimizer.cpp:264:
  Optimizer failed: Ipopt: Infeasible problem detected (status 2)
[2024-01-14 16:56:45.428] [error] OPTIMIZATION FAILED...
[2024-01-14 16:56:45.428] [error] CMC::computeControls: Optimizer could not find a solution.
Unable to find a feasible solution at time = 0.02.
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 don't think the given possible issues are relevant here because I can easily make it to work.
If for example I simplify the trajectory by copying the data of the first step (t=0) to ALL next timesteps,
effectively keeping the model still, everything works! Only very small pErr and vErr's.

What could be wrong? Is there an (undocumented) fundamental flaw/restriction in the CMC system, or
a bug in its implementation?
Is the someone that is familiar with the internals of CMC that can help?
I am willing and able to help, but on my own it is too much to handle.

Regards, Sietse

tr1.csv is a trajectory that keeps the model still and slowly starts moving the model after 0.31 seconds.
If fails almost immediately at that point. Up to that point also only small pErr and vErr's.
I can't find anything in the way of "control theory" that could explain this.

[hu hu]

I think I found the cause of the CMC tool crashing. To run CMC correctly, you should disable constraints. However, when using the FD tool, make sure to enable them. Also, be sure to lock `bJoint_3` and set its value to 0. I hope this information is helpful to you.

[Sietse Achterop]

Thanks very much for responding!!
I am afraid I don't fully understand.
1. You are talking about first disabling contraints and then enabling them? How do I do that in one single call to the CMC tool?
I assume you main the FD algorithm as part of the CMC tool. Otherwise I don't understand it.
2. Which constraints are you talking about? I only have a single WeldConstraint in the leg that should be there.
3. The whole idea of this simulation is to determine the values of 'bJoint_3', to see how the boat slides through the "water".
So it should not be constrainted.
I have seen this work perfectly, see here, where you find under "Pusher" a model that works.
You also can find a video there that shows this.

So I am a bit confused.
Thanks again, Sietse

[hu hu]

1. You are talking about first disabling contraints and then enabling them? How do I do that in one single call to the CMC tool?
I assume you main the FD algorithm as part of the CMC tool. Otherwise I don't understand it.
2. Which constraints are you talking about? I only have a single WeldConstraint in the leg that should be there.

When you use CMC, disable constraints. I am specifically referring to the only WeldConstraint here. As for how to disable it, you can click on 'legconstraint' in the OpenSim GUI, then disable it, making sure that 'isEnforced' is not checked.

Then, when performing forward dynamics using the controls obtained from CMC, enable the constraint. Just like when you disabled it earlier, make sure that 'isEnforced' is checked.

3. The whole idea of this simulation is to determine the values of 'bJoint_3', to see how the boat slides through the "water".

Looking at the motion file `trajectory.mot`, the value of `bJoint_3` is consistently 0. I assumed that this is the result you wanted. Therefore, you no longer need to fix `bJoint_3`.

[Sietse Achterop]

Thanks again for seriously looking into this!

I have made some progress, but not much, alas.
After setting isEnforced to off, it works! See below for the "but".

When it works, CMC delivers its result in ResultsCMC in several sto-files.
Then why are you saying:

Then, when performing forward dynamics using the controls obtained from CMC...

I don't see the need for a FD at all, I think I'm done after the CMC.

Also, although isEnforced is off, the Weldconstraint is working perfectly.
I cannot find anything in the Opensim docs about having to do such things when having
a kinematic loop or constraint.
Note that when doing a IK to create a mot-file from the trc-file the enforcing is needed.

But...
When I set the simulation endtime to, say, 7 seconds, then it will fail after about 3 seconds.
The trc-file has data for 7 seconds, so the mot-file can easily be created using IK and also
setting that endvalue in CMC.
UPDATE: the setup for IF points to the wrong trc-file, but thats trivially fixed.
The error is the same and just before that some errors explode, see e.g. uarmright_out for example:

Code: Select all

[warning] Task 'uarmright_out': pErr = -3.58869, vErr = -2402.74.
[info] 
[warning] Task 'uarmright_trn': pErr = -0.315268, vErr = 0.230614.
[info] 

Sometimes there are visible instabilities just before the "crashing".
The trajectory it is supposed to follow is very smooth, as can be seen in the IK results.
I don't see any reason for problems looking at the model.

Any ideas?
Regards, Sietse

PS. Concerning the bJoint_3, because it is no CMC-task the value is ignored without a problem
as is shown in the working examples.
And removing that column from the mot-file has no effect.

[Sietse Achterop]

For completeness here the updated zip-file.
It now calculates for the complete 7 seconds.

CMC_error2.zip

(434.37 KiB) Downloaded 84 times

I included the trajectories in both 100Hz en 200Hz variants, using trajectory.py.
The 200Hz variant fails already after 1 second.

[Sietse Achterop]

Another point.
the Joints uarml and uarmr are CustomJoints, but are actually BallJoints.
In this opensim issue we found that CMC does not cope well with BallJoints.
Therefore I changed then to there CustomJoint equivalent, and that worked.

If I change these CustomJoints back to BallJoints, the simulation fails earlier, now after 0,44 seconds.
But now there are no large pErr or vErr's.

[Sietse Achterop]

I have been struggling for more than a year with using this model with CMC, and I am now more or less at my whits end.
Is there no-one with in-depth knowledge of CMC? Who else can I ask?
I really think that my intended model is a relevant use case, think exosceloton.

In the accompanying OpenSim issue 3679 I summarized the problem.
See the last part and zipfile.

Still hoping for some help!
Sietse

[Tom Van Wouwe]

Sietse and I have been in touch through e-mail but I am writing a short summary here for our community.

(1) kinematic loop requires only one of the determining degrees of freedom to be in the tracking tasks (adding more makes CMC crash immediately). This was mentioned in a related post as well by Nicos.

(2) gimbal lock gives issues when experienced encountered during a (CMC) tracking simulation (ill-posed optimization? poor finite difference derivative info?). A change in the Euler angle order from what Sietse had originally XYZ to the more common ZXY allowed me to run CMC without issues.