ElasticFoundationForce question

[Heard-of-Checkerboard]

How do I establish the objects that should act under an Elastic Foundation Force?

When assembling my own model, I can't seem to keep my meshes from overlapping under simulation. I've established Contact Meshes for each object/body and I've attempted to use Elastic Foundation Force to provide the necessary force for my meshes/bodies to interact (as described in Tutorial 2). However, nothing I do seems to create the desired interaction, and alternative forces (like Cross Huxley Force) either does equally nothing or threatens to crash the program when I try to apply it. Is there a step I'm missing to establish the relationship between the forces and objects?

[adamkewley]

@Heard-of-Checkerboard , sorry for the delay - I sometimes don't get notifications for discussions 😢

You're correct: OpenSim usually works by separating ContactGeometry (e.g. ContactMesh) from Forces (e.g. HuntCrossleyForce).

Contact forces usually require listing the ContactGeometry that they're interacting with, but the list isn't usually a direct property of the force. E.g. in HuntCrossleyForce, there's a HuntCrossleyForce::ContactParameterSet, which is what contains the list of geometry:

<!-- From ToyLandingModel.osim, line 8223 -->
<HuntCrossleyForce name="foot_r">
	<!--Flag indicating whether the force is disabled or not. Disabled means that the force is not active in subsequent dynamics realizations.-->
	<isDisabled>false</isDisabled>
	<!--Material properties.-->
	<HuntCrossleyForce::ContactParametersSet name="contact_parameters">
		<objects>
			<HuntCrossleyForce::ContactParameters>
				<!--Names of geometry objects affected by these parameters.-->
				<geometry>platform_surface heel_r ball_big_toe_r small_toe_r</geometry>
				<stiffness>100000000</stiffness>
				<dissipation>0.5</dissipation>
				<static_friction>0.9</static_friction>
				<dynamic_friction>0.9</dynamic_friction>
				<viscous_friction>0.6</viscous_friction>
			</HuntCrossleyForce::ContactParameters>
		</objects>
		<groups />
	</HuntCrossleyForce::ContactParametersSet>
	<!--Slip velocity (creep) at which peak static friction occurs.-->
	<transition_velocity>0.1</transition_velocity>
</HuntCrossleyForce>

OpenSim Creator currently doesn't support editing nested properties like HuntCrossleyForce::ContactParameterSet (it's on my long TODO list) so, instead, it has a hack that detects if the thing being edited is a HuntCrossleyForce and it exposes the inner geometry node via the property editor so that you can add geometry to it - this is why you can add contact geometry to a HuntCrossleyForce but not to a ElasticFoundationForce (sorry about this: the codebase is very large and some things are missing).

The same ContactParameterSet property is exposed by ElasticFoundationForce. The parameters are described in the C++ here, the equivalent XML is something like this:

<!-- example, hand-written -->
<ElasticFoundationForce name="foot_r">
	<!--Flag indicating whether the force is disabled or not. Disabled means that the force is not active in subsequent dynamics realizations.-->
	<isDisabled>false</isDisabled>
	<!--Material properties.-->
	<ElasticFoundationForce::ContactParametersSet name="contact_parameters">
		<objects>
			<ElasticFoundationForce::ContactParameters>
				<!--Names of geometry objects affected by these parameters.-->
				<geometry>platform_surface heel_r ball_big_toe_r small_toe_r</geometry>
				<stiffness>100000000</stiffness>
				<dissipation>0.5</dissipation>
				<static_friction>0.9</static_friction>
				<dynamic_friction>0.9</dynamic_friction>
				<viscous_friction>0.6</viscous_friction>
			</ElasticFoundationForce::ContactParameters>
		</objects>
		<groups />
	</ElasticFoundationForce::ContactParametersSet>
	<!--Slip velocity (creep) at which peak static friction occurs.-->
	<transition_velocity>0.1</transition_velocity>
</ElasticFoundationForce>

This version appears to load in OSC, you'll have to add the XML into a relevant part of the osim file. Alternatively, OpenSim GUI may be able to edit the parameters, because it supports property hierarchies.

Mesh colliders might also be a problem, though. Other discussions on here have asked about them and, IIRC, there's very strict requirements that your mesh data must meet in order for mesh collisions to work correctly. The relevant documentation is here