Using SCONE excitations for forward dynamics in OpenSim

[Jan Grutters]

Hi Thomas,

For my project I am trying to do a forward dynamics simulation from standstill to walking in OpenSim 3.3. Therefore, I used SCONE to optimize a scenario for performing this task. Using the SCONE excitations from the .sto output I want to do a forward dynamics simulation on the same model in OpenSim 3.3.

However, if I try to do a forward dynamics simulation in OpenSim 3.3 using the excitations from the .sto file, I get very different results. (This also happens when I try to run 'simpler' tasks like the high jump.)

For the standstill-walking scenario I used:
- human0914.osim model (in an upright position).
- the GH2010asym controller.
- the MeasureGait05 objective function.

After scenario optimization this creates a standstill to walking motion in SCONE. However, the model seems do something very different using the excitations from SCONE in the forward dynamics tool from OpenSim.

I already checked:
- That models where equal in both SCONE and OpenSim
- That Initial conditions where equal
- That integration settings where equal

My questions:
- Are there differences in the forward dynamics used in SCONE and OpenSim?
- Can the differences be caused by differences in muscle force calculation or other assumptions in either SCONE or OpenSim?
- Is using SCONE excitations in OpenSim forward dynamics possible? Or will this always lead to accumulation of integrator error and result in a deviating model.
- Do you have any idea for a possible solution?

Thank you in advance for any help,
Jan Grutters

[Thomas Geijtenbeek]

Hi Jan,

If you perform a forward dynamics simulation based on the resulting excitations, there will always be deviation as a result of errors accumulating. This is especially true for motions where contacts change continuously and constant subtle corrections are crucial, such as gait.

That said, for simpler motions, such as jumping, the deviations shouldn't be as large as you suggest (even though I can't exactly tell how much they deviate without seeing the results).

Possible causes that come to mind:
[*] The data stored in the .sto typically has a lower frequency than the Controller updates the excitations. Make sure they match (see Preferences -> Advanced -> Data Output Frequency versus fixed_control_step_size)
[*] The initial vertical position of the model is adjusted in SCONE to based on ground reaction force -- make sure you use the first line of the .sto file for the initial state and not the one from state_init_file
[*] You mention the integration settings are equal, but AFAIR you can't change the integrator type in the OpenSim GUI (default is SemiExplicitEuler2 in SCONE), are you sure they are the same?

If those are all in order, at least the jumping example should be somewhat the same.

Finally, may I ask why you wish to redo the simulation using feed forward excitation patterns in OpenSim? If I understand what your goal is I may be able to help with an alternative solution.

[Jan Grutters]

Hi Thomas,

Thank you for your response.

[*] I checked the Data Output Frequency versus fixed_control_step_size, they were equal. Lowering the fixed_control_step_size/increasing the Data Output Frequency improved the forward dynamics in OpenSim.
[*] I checked the initial conditions and used the first line of the .sto file as initial condition.
[*] I checked the OpenSim integrator. I believe OpenSim uses the Runge Kutta Merson method as default for their GUI. So I changed the SCONE integrator to this and optimized a scenario, however this did not improve the forward dynamic in OpenSim.

For my project I eventually want to pre-train a reinforcement learning algorithm with training data in the osim-rl environment. For the training data I wanted to use the data from the SCONE simulation. However, implementing the SCONE excitations as model actions shows a simulation that behaves very divergent from the SCONE simulation. Consequently, I wanted to check first if forward dynamics of OpenSim would give a walking model using the SCONE excitation. This issue seems to be improved now by lowering the fixed_control_step_size, and increasing the output frequency (though this might not be the most convenient solution for training a RL algorithm). However, the new simulation results from SCONE seem not to result in an improvement of the osim-rl simulation yet.

Any possible suggestions for solving this problem or working around it are welcome.

Kind regard,
Jan

[Thomas Geijtenbeek]

I see, that should be a valid approach. However, if you're using the data to pre-train a neural network, then it shouldn't matter that the simulation isn't 100% perfect -- this is something the reinforcement learning algorithm should take care of during actual training. If RL performance doesn't improve, this is an indication of an issue with your RL setup. What are the inputs and outputs of your network, and what reward function do you use?

[Jan Grutters]

Hi Thomas,

Thank you for your response. You are right about that the simulation does not have to be 100% perfect to train the policy, as this will be solved by the reinforcement learning part. However, it would improve the performance of my algorithm if the excitations of SCONE would directly translate to the same model movements in the osim-rl environment.

Currently, the inputs of the network will be state observations of the model, the output of the network are the excitations to the muscles of the model. The reward function for gait is currently the horizontal position of the pelvis, but might be adapted for future experiments.

One note on the state observations between OpenSim and SCONE: I noticed that SCONE outputs the position of the center of mass of the body segments. However, the osimr-l environment outputs for some body segments (e.g. Torso /toes) very different results for the body part position. Do you have any suggestion how this difference can be originated?

Kind regards,

Jan

[Thomas Geijtenbeek]

I believe OpenSim outputs the position of the body coordinate frame, which is usually the parent joint position instead of the center of mass.

[Jan Grutters]

Ahh okay,

Thank you for your help!