Static Optimization moments

[Jacob J. Banks]

I am looking for some clarity on how SOpt determines the moments it balances. I have read in the documentation and in a previous posts about some of the subtle differences between how the SOpt and Inverse Dynamics moments are calculated, but they do not explain the issue I am having.

I am using a modified lower back full-body model, the BeaucageGauvreau 2019 model, with all the coupling constraints removed. I am unable to run the RRA tool, due to the equipment limitations of single instrumented treadmill belt. Therefore, I was interested to see if there was a difference between Lower Back moments when using a top-down vs. a bottom-up approach. To test, I switch the segment referenced to ground from the pelvis to the thorax, along with modifying some joint assignments etc. This is based on my hypothesis that the Inverse Dynamics tool solves from distal segments towards the grounded body. This is similar to how Visual3D would solve things. Similarly, since I only have 1 GRF vector and I am concerned with the lower back moments and not so much those of the lower limb, I apply the GRF vector to the pelvis. After running Inverse Dynamics on both models during a lifting task, I was pleased to see that the models behaved as I had anticipated: the bottom-up moments were inverted and smoother, but such differences are what one expects. In addition, I ran several other tests such as removing the GRF for the bottom-up and artificially adding weights to the hands etc. that supported my understanding.

So, the issue I encounter involves SOpt. When comparing the solutions from the 2 aforementioned models, the moments are both apparently balanced by a top-down approach, regardless of the model setup. I determine the SOpt moments by summing of all muscle forces x their respective moment arm. The moments calculated from the model with the thorax referenced to ground, the bottom up, are the same even in the absence of the GRFs and these moment aligns with that from top down setup. This, along with other tests, such as artificially adding or removing hand mass which should not impact the results for the bottom-up model, suggest that unlike the Inverse Dynamics Tool, SOpt is using a top-down approach and NOT using the GRFs to calculate muscle forces for either of the aforementioned models. Which is expected for the top-down, but not the bottom-up model.

Therefore, I am wondering why this may be and can I change something in the model to force it to use the GRFs? Obviously, in other models the GRFs are being used in SOpt. Does the direction of solving, the approach of TD vs. BU, that SOpt utilizes dependent upon the ordering of my bodies or joints in my models .osim or actuator file and not its location relative to the grounded body (admittedly, I have not tried this because with the number of bodies and joints the ordering possibilities are too large without some possibility it may work)?

Any insights would be appreciated. Thank you advance.
Jake Banks

[Dimitar Stanev]

Hi,

The implementation of OpenSim's static optimization (SO) does not balance the joint moments induced by the muscles with the one calculated from inverse dynamics. The problem is solved differently so that SO is more generic and can be applied to models with constraints. The explanation of the user guide is misleading:

https://simtk-confluence.stanford.edu/d ... tion+Works

If you look at the implementation:

https://github.com/opensim-org/opensim- ... t.cpp#L607

https://github.com/opensim-org/opensim- ... t.cpp#L660

you will realize that the optimization is solved by comparing the induced acceleration by the muscles to the target from the kinematics:

minimize_am sum |am|^p

subject to qddot(am) = qddot_desired
0 <= am <= 1

am -> muscle activation, qddot generalized coordinate accelerations. Abs is used in the objective since residual actuators might be added, which induce both negative and positive forces.

In other words the parameters of the optimization are used to activate the actuators. Then the state is realized to acceleration level to calculate the induced generalized coordinate accelerations (like forward dynamics but without numerical integration). This acceleration is directly compared to the target from inverse kinematics. When this difference is minimized a solution is obtained by the optimizer.

External forces should be applied as they will induce an acceleration. Otherwise, their contribution will not be balanced by the muscles.

[Jacob J. Banks]

Thank you very much for the timely response. It helps explain what SOpt is doing, but it still does not explain (to me anyways) the results I am getting. How could my GRFs not be contributing to my SOpt solution?

I am getting the same results regardless of applying a GRF or not. I can even make the GRF artificially very large and it will not impact the lower back moments. However, if I apply an external force to the upper body, it will impact the SOpt solution. This would indicate that SOpt is solving things via a Top-Down type approach (or whatever the equivalent is when matching actuators to accelerations). While my rudimentary understanding from the docs and your response is that SOpt should not be solving things in this manner. Rather, SOpt should be taking the body and external forces together as a whole and then matching their computed accelerations with the available muscles/actuators (regardless of where or what is referenced to the ground).
Jake Banks

[Marvin Zedler]

Hi Jacob,

did you solve your problem?

Regards,
Marvin