CMC does not work with some muscle/no-muscle models.
Posted: Sat Feb 25, 2023 9:17 am
Hello List,
It seems that CMC does not always work if there are joints not controlled by muscles but only with coordinate actuators (think motors).
Like with an exo-skeleton, or someone with an artificial arm or leg.
In my use case, a rower in a rowing boat, I come across it in developing it, because for simplicity I started with a simple model without muscles at all.
Because that didn't work I simplified it but still couldn't get it to work, see my issue #3345 on opensim-core.
The static optimization does not work properly for the model there, please find it attached.
What seems to happen is that there are 2 actuators that interact with each other in such a way that the constraints C_j keep being met but the performance (objective function) J increases all the time as seen by the movement of at least one joint in an incorrect way.
Look at the controls calculated in each step.
At one point a force is exceeding its maximum value and the optimization ends the tool.
The trajectory in the attachment keeps the model completely fixed in the same position the entire time.
The first few seconds it works perfectly, but after a few seconds, probably due to rounding errors, the model starts to oscillate.
Other trajectories perform in a similar fashion, see below.
Maybe we need a different formulation of the optimization problem, taking into account the joints with only coordinate actuators?
Keeping the no-muscle actuators out of the optimization somehow?
I would of course like to make it work, maybe by creating a (more general) version of CMC that can cope with this situation.
But first I need to know whether I am right in concluding that CMC is not working correct here and why!
When I understand that I probably am able to correct it.
Is there anybody with some experience in this area that can help me a bit further?
Thanks in advance, Sietse
PS. Setting all values in the 5-th column of the trajectory to 17 (instead of 117) creates a trajectory that is stable.
Using trajectory.trc you can get a "normal" trajectory that also fails after a few seconds.
PS. I have already created a version of CMC.cpp where the SO step is completely removed, meaning that the error value of the PD part is send directly to the actuator.
The algorithm is now reduced to a collection of simple PD controllers.
I think that this should work in this case. Am I correct?
But I cannot get it to become stable, so maybe I am missing something.
It seems that CMC does not always work if there are joints not controlled by muscles but only with coordinate actuators (think motors).
Like with an exo-skeleton, or someone with an artificial arm or leg.
In my use case, a rower in a rowing boat, I come across it in developing it, because for simplicity I started with a simple model without muscles at all.
Because that didn't work I simplified it but still couldn't get it to work, see my issue #3345 on opensim-core.
The static optimization does not work properly for the model there, please find it attached.
What seems to happen is that there are 2 actuators that interact with each other in such a way that the constraints C_j keep being met but the performance (objective function) J increases all the time as seen by the movement of at least one joint in an incorrect way.
Look at the controls calculated in each step.
At one point a force is exceeding its maximum value and the optimization ends the tool.
The trajectory in the attachment keeps the model completely fixed in the same position the entire time.
The first few seconds it works perfectly, but after a few seconds, probably due to rounding errors, the model starts to oscillate.
Other trajectories perform in a similar fashion, see below.
Maybe we need a different formulation of the optimization problem, taking into account the joints with only coordinate actuators?
Keeping the no-muscle actuators out of the optimization somehow?
I would of course like to make it work, maybe by creating a (more general) version of CMC that can cope with this situation.
But first I need to know whether I am right in concluding that CMC is not working correct here and why!
When I understand that I probably am able to correct it.
Is there anybody with some experience in this area that can help me a bit further?
Thanks in advance, Sietse
PS. Setting all values in the 5-th column of the trajectory to 17 (instead of 117) creates a trajectory that is stable.
Using trajectory.trc you can get a "normal" trajectory that also fails after a few seconds.
PS. I have already created a version of CMC.cpp where the SO step is completely removed, meaning that the error value of the PD part is send directly to the actuator.
The algorithm is now reduced to a collection of simple PD controllers.
I think that this should work in this case. Am I correct?
But I cannot get it to become stable, so maybe I am missing something.