simtk.org

Hi,

Thanks for the great project. I'm trying to use MocoTrack with a marker trajectory .trc file that I collected myself and solve for the muscle activations that tracks the trajectory. However, after following the tutorial and examples, I'm having a hard time getting the solver to converge. It would either error out with: in the beginning, or with: during the optimization process.

I would hugely appreciate any help or pointers to resolve this problem. Would this be related to the model itself, the marker alignment, optimizer configs, or something that I did wrong in my code?

What I have tried:
- scaling the model using the scaling tool, adjusting marker placement to match experimental markers
- tuning objective weights
- tuning optimizer parameters
- trying different initial time steps
- trying different initial guesses using the createGuess and randomizeAdd functions

Some strange observations:
- Using the exact same code, some times it works if I pipe the std output to a file instead of in the terminal.
- Using the exact same code, it works if I truncate the .trc file to 6 time steps (t = [0.0, 0.031]), but it doesn't work if I use the full .trc file with 800+ time steps but only set the time range for MocoTrack to (t = [0.0, 0.031]) using set_initial_time and set_final_time

Here is a link (https://github.com/RealZiangLiu/opensim-moco-issue) to the .osim model and .trc files.

Code structure:
- testMocoTrack.py: main script
- model.osim: model file, scaled using OpenSim according to .trc file
- motion_[1/2/3]_modified.trc: mocap marker trajectory files
- motion_[1/2/3]_log.txt: log files from my attempts at running the optimization

Thank you in advance.

Hi Ziang,

Have you tried using the default guess (i.e., "bounds") without randomization? The randomization might be putting the model in "bad" configurations causing NaNs due to constrain violations or extreme muscle states.

You could at least try visualizing the guesses you're getting from randomization to see if something looks incorrect.

Best,
Nick

Hi Nicholas,

Thank you for your reply. I have experimented with the default guess, and the randomization is only my attempt to debug the issue after many failures with the default "bounds" guess. I will try visualizing the muscle/model state using the default initial guesses, which I believe is the midpoint of the bounds according to the C++ source. I will report back with the results.

In the mean time, I also tried providing a reference coordinates trajectory that's generated from running torque driven MocoTrack on the same motion, which unfortunately didn't help.

Hi Ziang,

I think these errors are typically from things in the model that violate IPOPT's expectations of the state equations being "smooth and continuous". I would guess in your model the best candidates for where things might not be smooth and continuous are the wrapping geometries.

Echoing Nick's suggestion on the initial guess. These problems are very sensitive to the initial guess, especially when the model is complex. This looks like this is a fairly complex model. I've not had good results with Moco or with direct collocation in general trying to start from a complex model with an arbitrary initial guess. The only way I was able to get good results with complex models was to start with a much simpler model (I used Brian Umberger's 2D walking example with metabolic), get a good solution there, then make a small change/addition to the model, used the old solution from the simpler model as the initial guess, get another good solution, then gradually repeat this process, adding complexity one piece at a time until the model and approach was at the level I needed.

For example, the first thing I did was replace Brian's tracking target data with my own data. I got that working, then I added tracking of GRF. I got that working, then I changed the foot to a two-segment foot. Then I added some more muscles. Then I added arms, then I started gradually adding 3-D motions, then more muscles, etc. Each one of these steps involved running full simulations, getting a good result, and using that result as the initial guess for a new simulation with a (slightly) more complex model.

I guess in summary, it could be the case that nothing is wrong with the model or your code, it just needs a better initial guess.

Ross

Hi Ross,

Thank you for the suggestions. I will try out the progressive approach you mentioned and report back. Seems like a very cool idea that makes a lot of sense