Thanks, Nick. Your suggestions worked. It makes some sense that solveAndVisualize fails to visualize when the solution is sealed. There was already a comment in the code that suggested using track.solve to skip the visualization, and that allowed me to unseal before saving and plotting the results. ...

Thanks, Ayman. To keep the issue as simple as possible, I went back to the original simple arm example, removed the ConsoleReporter, and added the TableReporter and plotting code. See attached build_and_simulate_simple_arm_modified.m. I had to rename to .txt because the forum did not accept a .m fil...

It took me a while to get back to this, but Nick's suggestion worked. Thanks, Nick! I tried the example in OpenSim 4.4 and it still needs this same fix to work correctly. When the solution was visualized, there were markers but no bones. I assumed that the visualizer would look in the main OpenSim G...

We're experimenting with a simple arm model, based on build_and_simulate_simple_arm.m which comes with the OpenSim installation. A TableReporter is used to report some variables, and the plots have some strange glitches in the muscle variables. This happens for both muscle models we tried; DeGrooteF...

It could be the constraints, but it sounds like you already checked that. Make sure the pelvis_rotation (rotation about a vertical axis) has a range of -180 to +180 to allow all possible walking directions. If the walking direction varies around 180 degrees, a range of 0 to 360 would be better, othe...

It definitely looks like something is wrong with the GOAT results. It is supposed to be the same as HBM, so you should contact Motek support and have them look at it. The lower peak, and the overshoot to negative moment after push-off, are important clues. It almost seems as if GOAT used a filter wi...

Your external moment (cross product of ground reaction force and position vector) sounds like a quasi-static analysis. This can be a good approximation for the joint loading, but it neglects the inertial and gravitational effects on the body segments between the joint and the ground. If you included...

I did not have any problems with the 2D walking examples, but this 3D example does not seem to work for me. The torque-driven marker tracking example finishes in about 650 iterations with an objective value of 99.821. IPOPT says the problem is solved. But I don't think this is a valid solution. The ...

After your experiments with the filter settings, I totally agree it is not a filtering issue. Something is probably wrong in the OpenSim model. You may have done this already, but I would visualize the skeleton motion and the GRF vector in OpenSim, and make sure that the center of pressure is in the...

Hi Lars, This is an interesting observation. Normally the ankle moment is very reliable and not sensitive to modeling assumptions. When Antoine Falisse compared HBM results to OpenSim for walking, the ankle moments were almost exactly the same. Link to the article: https://pubmed.ncbi.nlm.nih.gov/29...