exampleSquatToStand- MocoPeriodicityGoal

[Mouaad BOUFADNA]

Hi Nick

I finally found what can be the main problem of my simulation.

It comes from the fixed flexion axis of the knees in the 2D_gait.osim model of Umberger.
Since this axis can only rotate on its own axis, others degrees of freedom are deleted.

In the real desired motion, knees can have rotation and forward translation.

Since the model should respect this fixed knee axis, the feet trajectory is forced as I explained to keep this model property.

I have not the motion I wanted.
So now I'm thinking of how to remove this fixed flexion axis ?

Thank you

Mouaad

[Carlos Gonçalves]

Hello Mouaad,

I wonder if you had solved your problem. I'm planning a new series of predictive simulations with bilateral symmetry as in jumping, so it is very similar to what you want.

I could manage something useful in predictive simulations of rowing, https://www.linkedin.com/posts/carlos-g ... 73632-jnEM, but I used many constraints: toes at footrest (PointOnLineConstraint), hands at the bar (PointOnLineConstraint), and for bilateral symmetry of lower limbs a CoordinateCouplerConstraint.

@everyone, there is another way to enforce bilateral symmetry? I looked for some goal for it but couldn't find them. There are some methods for setting constraints to the path (like MocoFrameDistanceConstraintPair) but I still need to use constraints in the model.

My issue with my current solution is the simulation's convergence time. It is taking ages...

Does it make a difference if the path constraints are set in the model or in the NLP solver?

Best regards.

Carlos

[Pasha van Bijlert]

Hi Carlos,

This might not be the type of suggestion you're looking for, because it might require you to overhaul the way you've constructed your model, but perhaps not so I thought I'd mention it anyway. If you want a bilaterally symmetric model that also moves (and is controlled) in a symmetric way, could you not build a single side, double up on all the segment masses, make a single set of muscles twice as strong, and then simulate that? This halves your search space.

Cheers,
Pasha

[Carlos Gonçalves]

Thanks for the feedback Pasha, I can't go with this approach.

Predictive simulations of jumping were already done with direct collocation (https://pubmed.ncbi.nlm.nih.gov/26715209/ ) using a model with two legs. A model with just one leg would be hard to defend in the future. My research will also be focused on comparing results with vertical jump routines in athletes. And maybe doing some tracking simulations with them.

Since using CoordinateCouplerConstraint worked with rowing, I expect it to work with jumping. My issue is simulation time.

One other thing is that I found about the MocoFrameDistanceConstraintPair going through UMocov2 code. Maybe there was something out there that I didn't see.

If there is a "symmetrical goal" that will help further on the road while researching for asymmetries. If there is not, I will have to give it a try and create one.

Best regards.

[Pasha van Bijlert]

Hi Carlos,

If you're doing a pure sagittal plane analysis and are enforcing perfect symmetry, I don't think two legs are better than a single "double" leg, unless you want to incorporate movement/actuator asymmetry or off-plane movements at some point. I will concede that sometimes we also have to make modelling choices based on what people outside the field might think.

I found bilaterally symmetric (essentially hopping) gaits when I'd incorrectly set the periodicity constraints. I think what I'd done was set each muscle's begin state to be equal to its end state, and also equal to the mirrored muscle's end state. However, this probably won't work for non periodic motions.

Cheers,
Pasha

[Carlos Gonçalves]

That is exactly the point Pasha. Thanks for the answer.

One good friend of mine has a good joke about this situation: "You don't need to make a good article. You need to make one that the reviewers will understand"

I will try my best to post the insights here, or on another topic. Hope it helps the Moco community in the future.

Best regards.

[Ross Miller]

Hi Carlos,

I don't think there's a way in Moco currently to enforce the symmetry you're describing (e.g., you'd like the left and right knee angle trajectories to be identical, if I'm understanding right).

I think what Pasha suggested is worth a try if the optimizations aren't working well right now. It would dramatically reduce the complexity of the solution space and would make the optimizations much faster to run and troubleshoot.

My experience early on with Moco was it works best to start as simple as possible and build up from there, e.g. I knew I eventually wanted the model to do a full stride (two consecutive steps) but started out simulating a single step because this was much faster and easier to troubleshoot. With a good result for one step, it's then easy to create a good initial guess for simulation of a full stride.

Similarly here, if you get a good result for a one-legged model, it should then be easy to create a good initial guess from it for a two-legged model.

Ross

[Ross Miller]

Also, concerning the question above on the knee axis:

To make a 2-D (sagittal plane only) simulation, all the axes for all the model's DoF have to be defined so that they are all in the global sagittal plane and only in that plane at all times. A skewed knee axis, even if it's a single DoF, will produce non-sagittal motion in the global frame and non-sagittal GRF in the ground contact elements, and there's no motion of the model in that direction (in other words, it's impossible to meet the system dynamics constraint, F cannot equal m*a). Same story if adding a multi-segment foot in 2-D, the MTP joint axis has to be in the global sagittal plane, can't be the usual skewed axis along the metatarsal heads.

Alternatively, you can add a medial/lateral translation DoF to the pelvis (or to whatever segment is the base segment), although I'm not certain that will fix this issue (haven't tried it myself).

Ross

[Carlos Gonçalves]

Thanks a lot for the feedback Ross.

And I agree with the "simulation learning curve". There are millions of ways to go wrong (with an error), some that go frustrating (with undesired motion), and a few where it works and you soon start the process over again after a celebration with a mug of coffee.

I totally agree with your concerns about the complexity in maintaining all the motion in 2D space. So far in my rowing model I had to deal with it, and it seems to work well. I started with a single lower limb, than moved on to one lower limb and one upper limb, and so on...

Focusing on lower limbs, the hip, knee, ankle are pin joints. Subtalar and mtp are weld joints. The rowing seat is a slide joint, and it has a pin joint connecting the pelvis. Both are set true for parameter <is_free_to_satisfy_constraints>. Then I set a PointOnLineConstraint for both toes on the footrest, and also the CoordinateCouplerConstraint for both knees to move in synch.

That was the end of the story, after some months of work. Mr Bones can row now with a good technic. The vertical jump would be the next chapter. Hope for the best, prepare for the worst.

Hope next year starts with a 'EUREKA' post.

Best regards.

[Carlos Gonçalves]

EUREKA!

https://www.linkedin.com/posts/carlos-g ... 98944-N-M7

After some days of tuning, I got the first jump and a simulation that converged. Still need to work on the "final time" goals and the usage of contact spheres, but is a useful result. The pelvis has a 6DoF, but the hip, knee and ankle are 1DoF. The CoordinateCouplerConstraint for the knees was enough for the bilateral symmetry. Ideal torque actuators are used in the back and lower limb.

Thanks everyone for the feedback, and I will continue customizing the guess files when new actuators (muscles) are added. That is really the way to go.

Best regards.