Constrain Center of Mass to Follow Projectile motion

[Tylan Templin]

Quick update if I increase pelvis actuators to be small but not zero the kinematics match much better and pretty decent projectile motion results.

image (20).png (52.38 KiB) Viewed 2023 times

Guessing this is helping to account for wind resistance. Are there any OpenSim examples with wind resistance so I can put the actuators back to 0?

[Aaron Fox]

Hi Tylan,

Glad you could work it out. Are you running a tracking problem to track kinematics from the markers? I did some testing with this and found I encountered similar problems to you, where the segments lagged behind/in front of the markers a little bit. I figured this was to do with weightings, balancing out the need to match marker positions while minimise the effort of the torque actuators (and the pelvis actuators you've identified). I didn't feel the balance was right for the time it took to optimise this process vs. the benefit over something like inverse kinematics - so recently have shifted my process a little to doing a base run of IK, using RRA to adjust to the kinematics relative to GRF (if applicable), and then shift across to Moco for torque or muscle driven sims. For those subsequent tracking simulations I still allow the kinematics to change - but track those I have more confidence from IK more tightly.

Aaron

[Tylan Templin]

Hi Aaron,

I had similar outcomes from what you are describing. I had better results tracking the IK motion (I didn't run the additional step of RRA because I am focusing on the flight phase) than just tracking the marker trajectories. I ultimately ended up also tracking a few of the markers in addition to the IK results to get the best solution.

My question now is: is it possible within MOCO to constrain the kinematics to match the IK results and make adjustments to the mass distribution (location of segment COMs and relative weights of the segments) rather than the kinematics to minimize the pelvis actuator output and follow projectile motion?

Thanks!

Ty

[Aaron Fox]

Hi Tylan,

Yes I think that's possible - there are some potential cost-benefit trade-offs to consider though. I'd perhaps start by looking at the 'exampleOptimizeMass' function that comes with the OpenSim Moco resources. I think this optimises the mass of a body attached to a simple joint so that it follows a provided trajectory. It is a simple example and I don't know whether anyone has expanded on this to apply similar concepts in a human model - I haven't seen any further examples but others might chip in.

You'll notice that this example uses the Tropter solver, which I think is the first change that you would likely need to make (vs. Casadi). A 2nd thing to consider, is that the time that these parameter optimisations take can largely inflate depending on what parameters are being optimised. From what I've heard Nick/Chris describe, if the change in parameter requires the model state to be re-initialised (i.e. initSystem() I think?) - then this will make the problem take a much longer time. I believe there's an option you can include within the Moco problem to turn this init aspect on/off depending on the parameter. Segment mass and CoM may be able to avoid this (it seems as if mass at least does based on the example) so it might not be an issue.

The only query I'd pose here is what data you have more/less confidence in and then use that to guide what should be changed in the problem (i.e. if you're more confident that the kinematics are correct, then it makes sense to alter the body properties; and vice versa).

Keep us updated how you go. I think a more detailed parameter optimisation example like this would be useful for the wider Moco community.

Aaron

[Nicholas Bianco]

Thanks for the great info Aaron. Just a few things to clarify.

1) The issue with long optimization times for parameters that require initSystem() calls is only relevant for the CasADi solver (that's why we often recommend using Tropter for these problems, if Tropter is suitable).

2) If the parameters do not require initSystem() calls then use can use CasADi and set the property `parameters_require_initsystem()` property to true:

Code: Select all

solver = study.initCasADiSolver();
solver.set_parameters_require_initsystem(true);

[Tylan Templin]

We already have a MocoOutputGoal, which allows you to minimize any OpenSim Model output value. OpenSim Models provide an output for the whole-body center-of-mass position, velocity, and acceleration

Can you explain in a little more detail how you would minimize/maximize the velocity of center-of-mass of one body in the model using MocoOutputGoal? Or point to any examples that do something similar?

I know this can be done in C++ (OptimizationExample_Arm26) but curious how you would do this using MOCO.

Thanks!

Ty

[Mohammad RahimiGoloujeh]

Hi everyone,

Awesome discussion here! All of the above points are great.

Regarding a MocoGoal for tracking projectile motion: what you'd need would be a MocoOutputTrackingGoal. We already have a MocoOutputGoal, which allows you to minimize any OpenSim Model output value. OpenSim Models provide an output for the whole-body center-of-mass position, velocity, and acceleration, so you could have these outputs track a projectile motion with a such tracking goal.

Not sure when we'll add this in to Moco, but it seems like it would be a generally useful goal.

-Nick

thanks for the information. I am wondering how I can know all OpenSim model output values for a specific model. i don't know if there is a specific object defined for that

[Tylan Templin]

I am not sure if there is a way to get all the outputs of the model, but you can use the API reference to look up the outputs of specific components of a model. For example, bodies inherit frame outputs (https://simtk.org/api_docs/opensim/api_ ... Frame.html), joint outputs are listed here https://simtk.org/api_docs/opensim/api_ ... Joint.html, muscle outputs are listed here https://simtk.org/api_docs/opensim/api_ ... uscle.html.

Hope this helps!

Ty

[Nicholas Bianco]

Hi guys,

Apologies, Moco doesn't currently only supports scalar Output types with MocoOutputGoal. As Tylan pointed out, you can reference the API documentation to see which objects have scalar (double) Output types.

Hopefully soon we'll add support for non-scalar types.

-Nick