Constrain Center of Mass to Follow Projectile motion

[Tylan Templin]

Hi everyone,

I have kinematics for a somersaulting motion. However, when I run a Body Kinematics analysis on the flight phase of this motion, the center of mass deviates from projectile motion (only gravity acting on the body). The slope of vertical velocity for example fluctuates about the ideal slope of -9.8 as shown below:

vertical_COM_velocity_comparison.PNG (18.08 KiB) Viewed 635 times

I was curious if MOCO would be a useful tool to help constrain the model such that it more closely matches projectile motion. My idea would be to set up a tracking problem that tracks the measured kinematics but also has a penalty if the COM deviates from 9.8m/s^2 acceleration. It looks like there is a built-in goal (MocoAccelerationTrackingGoal) that tracks the acceleration of single segments, and a goal (MocoAverageSpeedGoal) that tries to matches a set COM speed.

But I don't think either of these is what I am looking for. Would I need to write a custom goal to match projectile motion (constant vertical COM acceleration, constant horizontal COM velocity, constant whole body angular momentum)?

Thanks!

[Ton van den Bogert]

Hi Tylan,

That is an interesting observation, and it's good you are checking and questioning this!

You should not need any custom goal to improve this. Moco uses a model of the system dynamics, and will only produce solutions that satisfy the laws of physics.

But, like any numerical method, solutions are only an approximation to the true solution.

Since your "physics violation" is noisy, I suspect that you need to lower the solver tolerances. For example, in the example2DWalking.m, they are set like this:

Code: Select all

solver.set_optim_convergence_tolerance(1e-4);
solver.set_optim_constraint_tolerance(1e-4);

You can experiment with those numbers and see how they affect the solution. Lower tolerance gives a more accurate solution, but takes more time to calculate.

If the physics violation is smooth or systematic, the error would probably come from translating the continuous time problem into discrete time. To make that more accurate, you can increase the number of mesh points, which is done like this:

Code: Select all

solver.set_num_mesh_intervals(50);

Please report back to share what you found.

Ton van den Bogert

[Aaron Fox]

Hi Tylan,

A random addition here but I've had a lingering interest in applying predictive simulation methods to answer some gymnastics-related questions - so if this is something you might be interested in let me know as I'd be keen to have a discussion about it.

Aaron

[Ton van den Bogert]

(at the risk of going off topic)

Yes, I think there a huge potential for predictive simulation in gymnastics. New maneuvers could be discovered.

I don't work on gymnastics, but once for fun, I changed the periodicity constraint for a half gait cycle to include a 360 degree rotation. I had to make the muscles stronger to make that feasible, but then the optimization discovered how to walk with a somersault in each step. If you want to see it, my Dynamic Walking 2013 presentation is on Youtube.

Ton

[Tylan Templin]

Hi Dr. Bogert,

Thank you for your response! The initial plot I posted was just the body kinematics results using IK results as input (I had not yet used MOCO). I have since modified an example MOCO script to track my data: solution

Moco_track.txt

(3.67 KiB) Downloaded 15 times

When I ran this code I got the following results for the COM vertical velocity during the flight phase:

moco_tracking_com_vel.PNG (40.89 KiB) Viewed 582 times

I also tried cutting the mesh interval by a factor of 10 in response to you comment regarding smooth/systematic physics violations (which appears to be the case here) but got essentially the same curve.

Then I tried to edit the solver, as you suggested, to change the num_thresh_intervals to 50 (this is the commented out portion of the code in lines 57-60). This simulation gave these results:

moco_study_com_vel.PNG (49.2 KiB) Viewed 582 times

Which showed even larger periodic errors (I also tried 300 as the num_thresh_intervals which didn't improve results).

I haven't tried modifying "set_optim_convergence/constraint_tolerance" because I am getting smooth errors rather than noisy errors. Would you recommend still trying to do so? Any other recommendations?

And yes absolutely would be interested in moving into predictive simulations to optimize gymnastics performance! But want to make sure I can get a simulation running that isn't breaking the laws of physics first

Thanks!

Ty

[Ton van den Bogert]

I did not realize that your initial results were from IK (before Moco). In that case it's not bad at all.

Moco should produce a straight line for vertical velocity vs. time. Your results are indeed breaking the laws of physics. This oscillatory pattern does not look like a numerical error, more like a fundamental issue in how the problem was defined.

It may be that Moco also applies external torques and forces to the pelvis. These would be the first 6 (3D) or the first 3 (2D) degrees of freedom. Those external forces and torques are sometimes known as the "hand of god". Then you no longer are guaranteed to get projectile motion and conservation of angular momentum.

The problem may be: modelProcessor.append(osim.ModOpAddReserves(1000))

This creates reserve actuators on all degrees of freedom. In exampleMocoTrack.m, it says:

Code: Select all

% Add CoordinateActuators to the model degrees-of-freedom. This
% ignores the pelvis coordinates which already have residual 
% CoordinateActuators.
modelProcessor.append(ModOpAddReserves(250));

So reserve actuators are added for all degrees of freedom, except those that already have one! Indeed, in subject_walk_armless.osim, the first 6 DOFs already have an actuator, for example:

Code: Select all

                <CoordinateActuator name="tau_pelvis_tilt">
                    <!--Name of the generalized coordinate to which the actuator applies.-->
                    <coordinate>pelvis_tilt</coordinate>
                    <!--The maximum generalized force produced by this actuator.-->
                    <optimal_force>1</optimal_force>
                </CoordinateActuator>

You should probably make sure that your OpenSim model has those weak "hand of god" actuators also. Otherwise, your code would add very strong actuators there, with optimal_force=1000.

Note the optimal force value of 1. This is a lot weaker than the 250 they use for the other reserve actuators. Consequently, a very high cost would be associated with having substantial forces and moments in those 6 actuators, and the optimizer would keep them low. But not exactly zero. And some violation of physics would occur. Hopefully Moco would accept optimal force values of 0 for those actuators, to keep them exactly at zero.

Another way to keep them zero (even when optimal_force is not zero) would be to give the optimizer upper and lower bounds of zero for those control inputs. I'm not sure how that would be done. That might actually be easier to solve, because the optimizer can use the hand of god early in the optimization process, making it easy to track the markers, but then gradually reduce them to zero while it solves the optimization problem.

Ton

[Aaron Fox]

To add to Ton's great points, there is some code in one of the Moco gait examples (the 3D one I think) that increases the weights on those pelvis actuators as another solution to minimise the forces/torques produced by them.

Another solution would be to have no reserve actuators on the pelvis to avoid it happening at all - again I believe some of the gait examples with Moco employ this approach and can produce dynamically consistent simulations.

Last point I just thought of now would be that if your IK solution that you're tracking has that 'noise' in it, and you're asking Moco to track that (potentially with high weights) - it may be trying to achieve that noisy motion in the first place. As an experiment you could try and set the linear orange line you presented in your first plot as the pelvis_ty kinematics to track (with a high weight even) and that might encourage the solution to sit closer to what you expect.

Aaron

[Ross Miller]

Hi Tylan,

In addition to the points raised already: are you certain that the variable on the y-axis in your plots that show the center_of_mass_Y movement is the whole-body center of mass? My thought here was, a particular body segment does not necessarily need to undergo projectile motion, e.g. I can jump and wave my hand up and down and the hand center of mass motion will not be projectile motion.

If those data are indeed the whole-body center of mass then I think Ton's suggestion that the model probably has reserve actuators on the pelvis translational DoF is most likely. I think it's good to first try simulations without those actuators and see how well the model can track the target data without them. I think in most cases of optimal control simulations, reserve actuators should not be needed to get good results.

Hope this helps,
Ross

[Nicholas Bianco]

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

[Tylan Templin]

Hi everyone,

Thank you for the very helpful pointers! When I set the pelvis actuators to be 0 MOCO was able to find a very reasonable solution!

image (19).png (52.66 KiB) Viewed 478 times

Still not EXACTLY perfect (maybe this is because I didn't constrain the control of the pelvis actuators even though the optimal force is 0? maybe something else?) but I am very pleased with this result!

And in general the motion tracks the experimental marker data very well. However, there are a couple of exceptions. For example, here is an example frame where the MOCO solution (model pose) is noticeably different than the experimental data (blue dots):

moco_solution_vs_marker_data.PNG (8.18 KiB) Viewed 478 times

I would like to match the experimental data a little better in every situation.

My thought is instead of only adjusting the kinematics to ensure projectile motion as I have done (with your help!!), I would like also to adjust some of the model inertial parameters (segment masses, segment center of mass locations) within the optimization.

I believe this would let me track the kinematics even better AND maintain the laws of projectile motion. Is it possible to modify the inertial parameters within the MOCO optimization? Any other suggestions or approaches would be much appreciated!

Thanks again!

Ty