Using Moco to calculate the kinematics of a DOF/coordinate

[Sietse Achterop]

Hi Nick,
Setting set_apply_tracked_states_to_guess helped.
The trajectory.mot is for about 6 seconds of movement. Then there still is no solution in 3000 iterations.
If I truncate trajectory.mot after, say 30 lines, then there is a solution.
Note that set_final_time(0.1) is called, corresponding to only 10 steps of data. I was a bit surprised by the fact that data from after 0.3 second had so much influence on the result for the first 0.1 second.

But the output is wrong in the sense that the movement is physical wrong. If the rower pushes the boat (no blades in the water) with its legs then, more or less, the rower should move in one direction and the boat in the other. But the boat moves in the wrong direction.

I only can calculate about 0.1 seconds at the time, and this model is still fairly simple with no muscles at all, so how can I calculate a complete trajectory?
Can I stitch 0.1 second pieces together? I can make them, but is there a way to get a proper initial value for the next 0.1 second piece so together they form a complete coherent large piece of say 5 seconds?

Sietse

[Nicholas Bianco]

Hi Sietse,

Even when you set a final time, the problem will load all the data from trajectory.mot. Since it contains 6 seconds of data, that data table is fairly large which could be slowing down the problem. Truncating the input data was a good call.

Note that set_final_time(0.1) is called, corresponding to only 10 steps of data. I was a bit surprised by the fact that data from after 0.3 second had so much influence on the result for the first 0.1 second.

I'm not sure what you mean by this, unless you are referring to the speed up you saw, then see my comment above.

If the rower pushes the boat (no blades in the water) with its legs then, more or less, the rower should move in one direction and the boat in the other. But the boat moves in the wrong direction.

What do the contact forces between the ground and the boat look like? These forces should dictate everything about the resulting motion. These forces are very sensitive to the contact parameters and the predicted motion.

Is there anything in the problem that is incentivizing the boat to move in the direction that you want? I know you are tracking kinematics that "should" push the boat in the correct direction, but it's very possible for the optimizer to find a local minimum that deviates slightly from the kinematics data leading to undesired behavior. I would recommend setting bounds on the final position of the boat such that the optimizer must move the boat in the correct direction, otherwise the problem won't converge. You might have better luck with this approach.

Can I stitch 0.1 second pieces together? I can make them, but is there a way to get a proper initial value for the next 0.1 second piece so together they form a complete coherent large piece of say 5 seconds?

You could do this, use the final state from one problem to constrain the initial state of the next problem. But hopefully you'll be able to simulate closer to 1-2 seconds at a time. If the motion is relatively periodic, you might try imposing periodicity constraint so that you only need to simulate one rowing "cycle".

Best,
Nick

[Sietse Achterop]

In the current model the boat is "in contact" with the water: the contact-box is laying on the halfspace.
In that case the maximum time I can use for the final time is 0.1 second.
If I move the halfspace away from the box, the final time can be set to, say, 2 seconds.
But I need the contact because it is used to model friction.
Also a single rowing cycle that I need to simulate is up to 3 seconds.
Eventually I want to optimize this rowing cycle: getting the maximum speed given a rower.

I can stitch small portions together to get a complete cycle, but then it is not possible to use the optimizations that can be done within Moco. This because the criteria I have are for a complete cycle.
Is that correct?

[Nicholas Bianco]

Hi Sietse,

In that case the maximum time I can use for the final time is 0.1 second.
If I move the halfspace away from the box, the final time can be set to, say, 2 seconds.

You mean that, when including contact between the ground and the boat, the problem doesn't converge? Have you tried removing all the cost terms from the problem to see if will converge? I sometimes do this when dealing with contact model to get a solution that meets the dynamics constraints. That solution can then be used as an initial guess for your full tracking problem.

Even for simple models, it's often necessary to "chain" together solutions that incrementally increase tracking weights and weights for other cost functions to get the desired solution.

I can stitch small portions together to get a complete cycle, but then it is not possible to use the optimizations that can be done within Moco. This because the criteria I have are for a complete cycle.

This might be true, depending on the constraints for your problem. It might be better to try my suggestion above to simplify the problem while solving for the entire time range that you need. Once you get the first problem without cost terms to solve, then you can introduce cost terms (starting with low weights) and other boundary conditions that you need.

Does this approach make sense? Essentially, start as simple as you can to get the problem to converge (even if the kinematics are wrong), and then introduce complexity incrementally. I know you've already tried to simplify the model, but any model with contact can have difficulties if you don't have a good initial guess.

-Nick