simtk.org

Nice, congratulations! It always feels good to get it working after a long struggle.

The movement reminded me of Fernando Tatis "double-jump" last year:

https://www.youtube.com/watch?v=wl4A25cXBX4

Cool stuff! I'm planning on doing some jumping stuff in the near future, so good to hear that it's doable in moco!

Cheers,
Pasha

Thanks Ross and Pasha! All the support on the forum really helps!

The video is awesome. And opens a subject for another time about the motion of the limbs to compensate the center of mass parabolic motion. I was not able to create the "finalMarkerGoal" goal using the center of mass position, so I used the position of a marker at the top of the head. There might be something to do with it and also the loose ends on the time boundaries.

It reminded me this figure from Blazevich, A. J. (2013). Sports biomechanics: the basics: optimising human performance. A&C Black
Best regards.

Hi Carlos,

In reading up on CoordinateCouplerConstraint, I realised it's a constraint you add to the model itself. I thought I'd warn you that this is not a constraint function on the search space in the optimization, but a physical model constraint. This means that the constraint is enforced using generalized forces (in your case, probably knee moments). In other words, I think the physical interpretation of adding a CoordinateCouplerConstraint to the knees is that there is a knee moment from the left knee acting on the right (and vice-versa). You can think of both knees being placed in a single knee brace that doesn't allow each knee flexing separately. It may be worth your time to check that the constraint forces are in fact zero.

Cheers,
Pasha

Hi Pasha! Thansk a lot again!

You are totally right. I was not familiar with this behavior of the constraint forces. I ran a quick "Analyse" in the OpenSim GUI and got some results.
First, there is some kind of optimization of the head height during the jump. The graphs show that the center of mass speed decreases on a steady pace (gravity) and the top of the head in the end almost reaches a constant speed.

Second, the knee activation signals are pretty similar during the whole simulation, but the constraint forces appear greatly in the propulsion phase. . Funny how they disappear when the foot is off the ground but there are still knees motion.

I have one doubt though, neither the "Actuation" analysis nor the "OutputReporter" shows the torque from the coordinate actuators. The values are all zero. Anybody knows why?

Best regards.

Does the solution have non-zero controls for the coordinate actuators? That is possible, though seems unlikely.

I've had issues before where the GUI couldn't find muscles that weren't placed under the "ForceSet" tag in the .osim file.

Ross

Hi Ross,

The solution has controls between the min_control and max_control values, there are no NaN values. For analysis what is missing is multiplication, but it is still weird. Later on, I will run the analysis outside the GUI and compare the results.

The values for the contact forces were generated and appear to be correct. But they are not bilaterally symmetric.

So, it is a start but I still have some miles to cover with the torque-driven module. I will try to use the guess in a new simulation with the constraint disabled.

Best regards.

Hi Carlos,

If you can define the constraint force/moments as an output, you might be able to minimize them in the cost function, but I don't think it's possible if they're output as a SpatialVec. If not, I don't think there are straightforward ways (within the confines of Moco in its current state) to achieve bilateral symmetry for a jump, but I could be wrong.

Cheers,
Pasha

Hello Pasha,

In the same rationale of what you pointed out, maybe in the future where multiple controllers could run alongside Moco trajectory optimization, this could be implemented.

Until that, I simulated the jump with the previous "constrained" result as a guess and got an "ok" solution. The movement is not 100% symmetric but, as you mentioned, it is in the "luck space" of the solution. If the performance goal is greatly impacted by the off-symmetry, maybe it has a good point of improving.

https://youtu.be/ZSA0C-guhnc

Pasha, and what if the MocoFrameDistanceConstraint() is used in order to keep the relative position of the joints as in the initial pose?! It is a feature that is implemented in Moco, and with set as a tight range, it would keep them in the same position related to each other across the whole simulation.

What you all think?

Since this is part of my PhD, I will reach out for my supervisor about creating a SimTk project about it.

Best regards.

Hi Carlos,

MocoFrameDistantConstraint seems to be a constraint on the search space, so that shouldn't introduce unwanted generalized forces/moments. If all the joints are pin joints with perfect alignment to the z axis, then you could probably constrain the distance between each leg segment to be what it is at the start of the simulation, and you might get something that is close to symmetric movements.

This is very much a workaround though, perhaps you should consider asking Nick if a proper symmetry constraint on controls and states could be considered for a future version of Moco. I actually don't know if there is a formal way to do a feature request for moco, or if the forum even is the right place for this.

Cheers,
Pasha