How to use STLs that are not body-centered when building a model?

[adamkewley]

AK: question ported from Slack. It has been edited to make it suitable for GitHub discussions.

Related: #869

I can’t figure out how to use StationDefinedFrames with STLs that dont have an origin at the center of their associated body . So right now we’re having to find body centers elsewhere, then re write the STLs before being able to use them in Opensim Creator.

Additionally, when I re assign a joint the StationDefinedFrame using OpenSim Creator's socket feature, it assumes the body is coming in at neutral and assigns an additional rotation. So to be able to use the function I have to find the body axes and reorient it to neutral before using. Is there a way to reorient the joint to match the position of my STL meshes (i.e. in sensor-space, where the patient may not be in a perfectly neutral position).

[adamkewley]

I think that an easier way to handle the problem of your STLs/OBJs not being body centered is something (roughly) like:

• Define the frame on the mesh data with a procedure like first (temporarily) adding the meshes into the model via a throwaway body or an offset frame, then load in your stations (however you're doing that)
• Then attach the stations to the same frame as the mesh, so that they're all attached to the same "base" frame (use the Re-express in new frame thing to stop the stations snapping around if the frames are at different locations)
• Then define a StationDefinedFrame from that, using one of the stations (on the surface of the mesh) as an origin for the StationDefinedFrame. This way you'll still have the "base" frame (there's no avoiding this in OpenSim - the mesh importer just calculates around it), but you'll also have a StationDefinedFrame that's in the correct location w.r.t. the mesh's surface.
• Then attach the joint to that frame (either by re-socketing an existing joint or attaching a new body to that frame) to the model. This will make it "snap" into place (a joint requires that both frames are co-located, plus any coordinate transforms)

If you find that the StationDefinedFrame somewhat "over-encodes" your topology (e.g. because the StationDefinedFrame is assuming some nonzero joint coordinate or similar) then one "trick" to this is to attach an offset frame "in between" the joint and the StationDefinedFrame, which gives you the ability to tweak it, but also enables the Re-zero joint feature, which does some maths to figure out how to re-transform offset frames such that they are in their current position, but with zeroed coordinates for the joint.

Alternatively, if your problem is that you need to play around with joint coordinates in order to reposition the resulting model to match sensor-space (e.g. because your StationDefinedFrame is valid for a neutral pose), then that's different. In that case, people have used the Inverse Kinematics tool in OpenSim GUI to shift the appropriate joint coordinates around to get the model into the correct "pose". This usually involves placing markers on the meshes in the "wrong" pose and then telling them to align with (usually, ground-based) stations/markers in the IK tool (vaguely speaking: I haven't done this myself).

[adamkewley]

Note: The above isn't really a great answer, but it's the best I've got at time of writing, because the user probably needs additional tooling for mapping between OpenSim-space and sensor-space. I wrote the following as a reflection on the problem:

I think another way of stating what you want is that you want the StationDefinedFrame's position+rotation, but you also want the joint's angle to be offset correctly based on how the patient was lying in the sensor? What I mean is that you want:

• The parent frame to be positioned as-per StationDefinedFrame
• But because the patient wasn't perfectly zeroed (they never will be), the StationDefinedFrame feels like it's "off", because your downstream marker locations (in this instance, the ones on the knee) are now separated by some angle
• But that angle isn't because the StationDefinedFrame of the parent is wrong (as in, the computed rotation would be correct if the patient somehow perfectly zeroed). The angle is wrong because the patient, in reality, isn't zeroed
• So what you actually want (if I'm understanding this) is to adjust the joint angles at the hip such that the distance between the knee (in this example) and the stations is minimized? I.e. a kind-of inverse-kinematic solution that figures out what the patient's actual hip angle was when they were lying in the sensor?
• The reason why this would be preferable to adding additional offset frames etc. to minimize that distance is that the solution would encode the correct joint angle, whereas I think that adding offset frames etc. would mean that the "zero" of this particular model isn't the same as the "zero" of another model (as-per ISB's official definition of joint angles on stations, cross products, etc. etc.)

I think there's something useful hiding in these problems, but I'm now wondering what the UX/design/maths would be to make it clear how to exploit each problem:

• You've got segmented meshes defined in sensor (i.e. real) space
• And you've got landmarks defined in the same space
• And now you want to make an OpenSim model in OpenSim's relative space by joining things with frames, joint constraints, etc. etc.
• But that's problematic, because all of your data is in some other space
• So now you're converting data into spaces that are nicer for OpenSim (body-centered meshes, and so on)
• And then encoding relationships between things to establish OpenSim-friendly coordinate systems (e.g. via StationDefinedFrame)
• And that's now creating new problems where those (physics-engine-friendly) spaces don't quite match up with reality (sensor-space)
• But the sensor space is de facto correct - the patient was literally lying in a sensor with that configuration

So it feels like 95 % of this problem is figuring out how we can take your sensor-space data and use it during the data-to-model mapping procedure. E.g. you've used a body-centered femur here for OpenSim's convenience but it has "deleted" the information that you also have both landmarks in sensor-space (original) and corresponding landmarks on the femur mesh (after attaching it to OpenSim with StationDefinedFrames) - the difference between those two must be resolvable via a joint transform (i.e. it's an inverse kinematic problem)