Questions regarding the "InMemoryMesh" function module and the closed-loop structure

[collin-kkk]

When attempting to couple Rajagopal2015 with the hip exoskeleton, since the human-machine closed-loop structure can only be established through Constraints, and attempts to establish "weldconstraint" and "PointConstraint" between the human body and the exoskeleton always trigger an Assembly error (Infeasible Problem), currently only "ConstraintCouplerConstraint" does not trigger this issue. However, setting the primary and secondary relationship of the Coordinate has its limitations. I am trying to find a better alternative solution. I wonder if there is a corresponding solution.
In addition, I noticed a "InMemoryMesh" function module. I don't know its specific usage method. I don't know if it can be used as a corresponding solution. I haven't found any relevant documentation or usage cases. And when setting InMemoryMesh in OCO and attempting to modify or call the code in the.osim file (even with an empty line), the Navigator in OCO no longer shows the added InMemoryMesh.

[adamkewley]

I am guessing that you're trying to weld the hip exoskeleton to both the pelvis (as pictured) and some other part of the model, but your exo is probably modeled as a fixed-width device that you're trying to also weld (in addition to the pelvis) at a "looser" width on another body on the hip/upper-leg or similar.

Physics-engine-wise, what you want is only possible if the two weld points are precisely located (precise, here, meaning "within the assembly accuracy", which can be micrometers). Otherwise, it'll either fail to assemble (what you see here) or be constrained in such a way that the degrees of freedom between the two weld points can no longer do anything.

Stated this way, I would guess you have a few choices to make:

• Add degrees of freedom into your exo that reflect the fact that it isn't fixed-width device
  • E.g. if it has a slider with a spring that lets it extend a little bit for different subjects, the degree of freedom offered by the slider would make assembly possible.
• Attach the fixed-size exo the subject with something "looser" than a weld.
  • A weld joint is "I want my exo to behave as-if I literally screwed one side of it into their pelvis and the other side into their femur". In this example, if the required distance cannot be created by rotating the hip joint, you would see assembly errors.
  • If what you actually want to model is "It's strapped on the subject's flesh around the pelvis and strapped onto their femur", that's a little bit different. You should think carefully about things like the orientation between the pelvis, exo, and whatever your second attachment point is. What part of the position/orientation is dictated by joint frames (i.e. how it's attached)? What part of the position/orientation is actually a degree of freedom?
  • E.g. pretend that the pelvis part is welded to the subject (it isn't, but it's a useful simplification). If you do this, you might immediately notice that, even before you attach the other side, the orientation/placement of the exo is problematic if the other bodies cannot rotate into the correct location with their existing degrees of freedom. That's an indication that the joint frame placement is initially wrong and adding more constraints will not fix it.
  • E.g. (cont.) Assuming the initial weld is correct, you might find that, even if the model can be re-posed to align everything, welding the other side doesn't work because the distance between the two is wrong. In that case, you either need to calculate (via python/MATLAB) the perfect location for the other joint (unlikely), or you need a degree of freedom that (e.g.) runs along the side of the subject's leg, a little bit like a SliderJoint (but perhaps without the explicit degree of freedom that a SliderJoint would expose). If that sounds like a possibility, then you might want to try a PointOnLineConstraint for the second part of your closed loop. That way, the model will be able to assemble with the exo along the subject's leg. The fact that it's "free" along that line might not actually be a problem if you have a fixed-size exo that's welded/pin-jointed to the other body (there's no way for it to get closer or father away from the first attachment location).
  • If constraints still feel a little bit too rigid (i.e. you can't think of a way to do it without over-/under-constraining), then you're exiting the realm of model assembly (e.g. solving your model's initial configuration/state) and perhaps entering the realm of forces. E.g. you could, in principle, not constrain the exo at all on one side and instead just slap a very strong spring between the two. That'd have much more freedom, but would require running an integrator (e.g. forward dynamic) in order to figure out what would actually happen in such a scenario. OpenSim won't just automatically know how to initially pose the model in this case, because no integration occurs during model assembly.

---

In addition, I noticed a "InMemoryMesh" function module. I don't know its specific usage method. I don't know if it can be used as a corresponding solution. I haven't found any relevant documentation or usage cases. And when setting InMemoryMesh in OCO and attempting to modify or call the code in the.osim file (even with an empty line), the Navigator in OCO no longer shows the added InMemoryMesh.

I'm not sure what OCO is, or what you mean by "function module", or what "modify/call the code in the osim file" means when discussing a GUI application with no coding interface, but an InMemoryMesh isn't something you can load from a osim file. It's an experimental component (labelled/categorized as such in the UI) and is used by other parts of OpenSim Creator (or, OSC), to provide support for algorithms that temporarily need to be visualized, but cannot write their mesh data to disk (e.g. the model warper).