Using Moco to calculate the kinematics of a DOF/coordinate

[Sietse Achterop]

Ha, progress!
The trajectory now looks a little bit as intended, so I switched back to the model with the ElasticFoundationForces and the weights for the boat set to zero.
After some fiddling with the weights i now have objective_state_tracking between 0.2 and 1, so it follows the trajectory fairly well.
But the position of the blade is a little bit higher than intended, and consequently there is no friction that would propel the boat. I haven't been able to move the boat at all. Also created a trajectory that has the blade a few cm lower in the stroke, but still no firm contact/friction with the ground. In CMC it works as expected, there the boat is lifted a bit "out of the water".
Somehow gravity doesn't come enough into play with moco. Or it seems that the optimization process avoids the contacts.
Is there something to be done?

I have to set the global weight 100 of so, but to avoid the limit of 3000 iterations the simulation time has to be set at 0.4 seconds or so. That doesn't bode well for larger models.

Thanks, Sietse

PS.I also did an experiment with 2 muscles in the kneejoint. It works fine with CMC, but with moco I get the following runtime error:

Code: Select all

MocoTrack::solve()': No info available for state '/forceset/vastus/fiber_length'.

vastus is one of the knee muscles in the model Pusher_muscle.osim.

[Nicholas Bianco]

Great! Now that the tracking goal is working as expected we can start trying to solve your problem.

I think the main problem is that you're still tracking the degrees-of-freedom between the boat and the ground, and you still have actuators at these DOFs so they will offset any friction force you're creating with the pusher.

Now you should set the tracking weights for the boat joints to zero (both values and speeds) and remove actuators from those joints as well. You want the only the only forces between the boat and the ground/course to be created by the contact elements.

[Sietse Achterop]

Great, its working! After adding zero weights for the speed it works perfectly.
And with that working I tried a simplified version of the final model.

bootbaan

bootbaan.png (162.16 KiB) Viewed 419 times

This model and mocotrack results can be found at https://github.com/SietseAchterop/Rowin ... tBaan/Moco.
This also works with mocotrack!

Before I go any further, note that the simulation time cannot be much larger then 0.2 seconds considering the number of iterations needed.
When the model is more complete (including a lot of muscles) this will probably even less. To be able to learn from these simulations I need a simulation time of at least 3 seconds. That is one rowing cycle at a stroke rate of 20. The interesting rates are between 20 and 40.
So the question becomes, can this be done with more complex models?

Thanks again!
Sietse

[Sietse Achterop]

Next step, also almost works!

first complete model

b.png (130.09 KiB) Viewed 410 times

This is the simplest complete model. In the trajectory the blades are not "touching the water" yet, so no contacts there.
The movement looks OK, only the boat moves in the wrong direction I think. I have to figure that out.
And objective_state_tracking=11.1, so we are not there yet.
The code is in https://github.com/SietseAchterop/Rowin ... aan/Moco_2

The mocotrack optimization does not need more iterations than the simpler model, so that is good.
During the optimization there are about 50 errors, all the same, but the optimization seems to finish ok.

Code: Select all

[error] Model unable to assemble: AssemblySolver::assemble() Failed: SimTK Exception thrown at Assembler.cpp:895:
  Method Assembler::assemble() failed because:
Unable to achieve required assembly error tolerance.
Assembly error tolerance achieved: 9.451158453077646e-09 required: 1e-10..Model relaxing constraints and trying again.

I sometimes see this error when using opensim, but only a few. Is this a problem, what can I do about it?

Sietse

PS. the next step is using the custom blades and try a trajectory where the blade make contact with the ground/water.

[Sietse Achterop]

I think we have to take a stap back to the model from https://github.com/SietseAchterop/Rowin ... tBaan/Moco.
It seems to move, but in a wrong direction. The more complicated model above (in Moco_2) does something similar.

I played a bit with the weights, but that did not make much of a difference.
The objective_state_tracking mostly is around 4, so not that good.
My guess is that I first have a really good solution for this model before making it more complicated.
But I don't have any ideas left on what to do, so what can I do next?

Thanks again, Sietse

[Nicholas Bianco]

Hi Sietse,

This type of problem can definitely be difficult to solve and getting the right initial guess is always tricky.

One suggestion is to try again removing the vertical coordinate for the boat and only have the oars have contact with the ground.

[Sietse Achterop]

Hi Nick,

What exactly do you mean by the initial guess? I don't see any guess here, only the intended trajectory.

The example in directory Moco does NOT have any oars in it, only a basic leg and torso, see the picture above.
I now also removed the riggers and oarlock to make it even more simple, see github, but now there is no solution found even when the final time is set to 0.1 seconds, so only 5 steps of the trajectory.

Following your suggestion and removing the vertical coordinate doesn't help.
There is also not a solution within 3000 iterations.

But also something strange. To remove the coordinate I only remove it from the customjoint, so I only remove the next 4 lines.

Code: Select all

bj_4 = osim.ArrayStr()                                                                                                                                                                                
bj_4.append("bJoint_4")                                                                                                                                                                               
boattf.updTransformAxis(4).setCoordinateNames(bj_4)                                                                                                                                                   
boattf.updTransformAxis(4).set_function(osim.LinearFunction())

But when the model is loaded in OpenSim, the coordinates cannot be changed at all in the gui.
Also when doing IK it does not work at all, the model does not move at all, and I don't see why, the coordinate that was removed was not stay at 0 anyway. Strange.
What I do see is that removing the constraint in the lower leg does help a lot, but it really is needed.

Sietse

[Nicholas Bianco]

Hi Sieste,

I mean the initial guess for the optimization problem (e.g., solver.setGuessFile("initial_guess_file.sto")). You could use the kinematics you're tracking to create an initial guess for the coordinates to give a "hot start" to the problem.

The GUI can only load an existing model, it doesn't support model building/modifying yet.

If removing the constraint really helped, then that could explain some of the issues. If the model starts in a configuration far away from a configuration that obeys the constraints, then the model might have issues resolving the constraint. This is what the AssemblySolver errors you were seeing before mean; the AssemblySolver is what "assembles" the model including resolving all kinematic constraint errors.

I am a little confused about what problem you're currently working on. So there's no contact model being currently used? How is the boat able to move? Do you have actuators between the boat and the ground?

Here's another idea (for when you get back to use ground-contact models) -- when we generate tracking simulations of walking, we typically track both kinematics and measured ground reaction forces. You could try adding tracking a force trajectory that the oars track that should move the boat in the correct direction. You could also try tracking a kinematics trajectory of the boat that's in the direction you want to incentivize the oars to push you in the correct direction.

-Nick

[Sietse Achterop]

Hi Nick,

> The GUI can only load an existing model, it doesn't support model building/modifying yet
I meant that, after loading the model in opensim, that the sliders to control the coordinates do not work at all. Nothing to do with moco.

I tried to add an initial guess file. I used the same trajectory.mot that I want anyway.
I am a bit confused of how to add it; below is my best try. But I get an error:

Code: Select all

RuntimeError: std::exception in 'OpenSim::MocoSolution OpenSim::MocoStudy::solve() const': Key 'num_states' not found.

The current problem only consists of the boat-box, leg and torso. The only contact is between boot and ground. Moving leg and torso should move the boat a bit. Probably get that working first before making it more complicated.


Thanks again, Sietse

Code: Select all

import opensim as osim

def muscleDrivenStateTracking():
    track = osim.MocoTrack()
    track.setName("muscle_driven_state_tracking")
    modelProcessor = osim.ModelProcessor("BootBaan.osim")
    track.setModel(modelProcessor)

    coordWeights = osim.MocoWeightSet()
    coordWeights.cloneAndAppend(osim.MocoWeight("/jointset/boatJoint/bJoint_3/value", 0))
    coordWeights.cloneAndAppend(osim.MocoWeight("/jointset/boatJoint/bJoint_3/speed", 0))
    coordWeights.cloneAndAppend(osim.MocoWeight("/jointset/boatJoint/bJoint_4/value", 0))
    coordWeights.cloneAndAppend(osim.MocoWeight("/jointset/boatJoint/bJoint_4/speed", 0))

    track.set_states_weight_set(coordWeights)
    track.set_states_global_tracking_weight(30)
    track.set_allow_unused_references(True)
    track.set_track_reference_position_derivatives(True)
    track.set_initial_time(0.02)
    track.set_final_time(0.1)
    track.set_mesh_interval(0.025)

    tableProcessor = osim.TableProcessor("trajectory.mot")
    tableProcessor.append(osim.TabOpUseAbsoluteStateNames())
    track.setStatesReference(tableProcessor)

    study = track.initialize()

    solver = study.initCasADiSolver()
    solver.set_num_mesh_intervals(25)
    solver.setGuessFile('trajectory.mot')

    solution = study.solve()
    solution.write("mocotrack_solution.sto")

    return

muscleDrivenStateTracking()

[Nicholas Bianco]

Hi Sietse,

I meant that, after loading the model in opensim, that the sliders to control the coordinates do not work at all. Nothing to do with moco.

Ah, I see. You've tried restarting the GUI when the model is frozen? The visualizer sometimes gets disconnected since it uses a web-based connection.

setGuessFile() expects a file created from a MocoTrajectory, so you can't input a generic states file there. If you want to simply apply the trajectory you're tracking to the guess, you can use the following MocoTrack property:

Code: Select all

track.set_apply_tracked_states_to_guess(True)

The approach you're taking with the simple model is the right way to go.

-Nick