Visualizer is afraid of model

[Ross Miller]

Hi all,

I am having a strange problem with the Visualizer recently:

Normally when a simulation finished I send the MocoSolution to the Visualizer and it animates the solution from a sensible default camera view. Recently however, it has been animating the solution with the camera zoomed out very far away from the model (example attached).

The only change I've made recently is that the graphics are a mix of VTP and STL files. The STLs are some meshes for a lower limb prosthesis.

Any solutions/guesses on why this is happening and how to get it to default to a more useful view?

Ross

Screen Shot 2021-03-19 at 9.15.24 AM.png (698.24 KiB) Viewed 418 times

[Nicholas Bianco]

Hi Ross,

I think the visualizer will zoom out to fit all visible graphics in the model. I saw similar thing happen when trying to visualize GRFs and I scaled the force visualization to be too large. You've double checked that all graphics added to the model are being added in the correct place? Also, perhaps your simulation is generating super high GRFs at some point during the simulation.

-Nick

[Ross Miller]

Thanks Nick. The GRF are normal-sized in this simulation. There must a rogue pixel in one of the STL files. When I animate it without those files the camera view is normal.

Ross

[Aaron Fox]

Hi Ross,

It looks like there's something in the foreground of that view - the little blue dot on the ground looks out of place.

Aaron

[Ross Miller]

I noticed that as well. It doesn't appear in the video, just in screenshots, and there's no similar artifacts in the STL files I added. The mystery continues.

[Aaron Fox]

Hi Ross,

Where's the origin (0,0,0) in this context? I've noticed sometimes that my marker data or force data when there is 'nothing' becomes zeros, and if this is the case perhaps the visualiser views this as 'data' that needs to be encompassed in the visualisation? I'd be surprised if your origin was this far away though.

Aaron

[Ross Miller]

It visualizes these same data normally when I hide the STL files I added to the model (they are for a prosthesis). It then doesn't animate the prosthesis of course but the view/angle of the visualizer is normal. So I think it's something with those STL files.

Ross

[Carlos Gonçalves]

Hello everyone,

I just searched this forum entry right now because my models also started to be afraid of the screen.

For me was the case of really scary GRFs ... (the contact spheres are magically going under the floor)

Ross, if you still have a problem with the STL, maybe check it using Meshmixer (https://www.meshmixer.com/). It has a diagnostic tool that can quickly identify errors or floating triangles. Perhaps you already tried it.

About the GRFs, does anyone knows a way to restrain the feet over the ground? I thought of creating an auxiliary joint linking to toes to the ground and constrain it using problem.SetStateInfo.

Best regards.

[Aaron Fox]

Hi Carlos,

I assumed this relates to walking, and I can hopefully relate some of my issues from running simulations to your problem. I found that getting accurate pelvis_ty kinematics combined with appropriate contact sphere size and locations to be the best way to get good contact tracking, without too much sphere-floor penetration. At times my experimental data needs a bit of re-working via RRA to ensure the kinematics best align with the ground reaction forces - and I've found doing this before any contact tracking/prediction with Moco can be a useful step. Where I haven't done this, I think Moco struggles to change the pelvis_ty kinematics too much (i.e. adds too much to the tracking cost vs. contact cost) to get things right.

Aaron

[Carlos Gonçalves]

Thanks a lot for sharing your thoughts Aaron. Predictive simulation is an ocean of doubts sometimes.

Your comments follow my first experience with predictive simulation of 3D gait. I studied a patient gait and managed to get some really good results in both tracking and predicting.

"Some say, the model could identify hamstrings spasticity during stance" (Jeremy Clarkson voice).

Now I'm trying to compute a full predictive simulation, starting from my model, some initial constraints, and hoping for the best. The takeaway so far is that the states are way more than just the coordinate values, activations, and muscle lengths. The coordinate speeds were "loose" in my initial bounds, and the solver was trying to use a trampoline effect, pushing the heels in the ground. Maybe that's what I was missing ...

I tried to create additional joints with <is_free_to_satisfy_constraints>true</is_free_to_satisfy_constraints>, but it is not possible to connect the ground to the multibody in more than one joint. I thought of trying to create 3 PointOnLineConstraint for each heel so that it could always stay above ground, but it seems kind of extreme

After this endeavor, I will create a decent forum topic about this subject. Maybe it can help others.

Best regards.

Carlos