Get internal forces for a MobilizedBody

[Simone Hendriks]

Hello!

Is there any function in Simbody that calculates the "net internal wrench" applied to a MobilizedBody? By that I mean the following: if a MobilizedBody is subject to a series of constraints, then this net force would be the sum of both the mobilizer force and the constraint forces, both obviously expressed in a common frame, but not the external forces that are applied through SimTK::Force.

Thanks a lot for your time and support!

Best regards,
Simone

[Michael Sherman]

Hi, Simone.

I don't think there is a pre-existing function that would provide exactly the quantity you want. That might be a nice addition! However I can think of a few ways to get it:
- thinking of a free-body diagram, use F=MA to obtain the net spatial force F from the body's spatial inertia M and spatial acceleration A. That will include everything -- you would have to subtract off applied forces if you don't want them included. MobilizedBody has method for getting SpatialInertia and SpatialAcceleration -- make sure they are in the same frame.
- if you know all the mobilizers and constraints affecting the body, obtain the reaction forces for each of them (from the MobilizedBody or Constraint), shift to the body origin, and sum. Simbody provides the necessary reaction force and shift methods.

Regards,
Sherm

[Simone Hendriks]

Hi Sherm,

Thank you for the prompt response. Indeed, both options could work. I would opt for the second one, given that I have many SimTK::Force components and just one SimTK::Constraint::CoordinateCoupler acting on each mobilized body. For the mobilizer reactions, I can use for instance findMobilizerReactionOnBodyAtOriginInGround(), and for the constraint forces, calcConstraintForcesFromMultipliers(). However, I am unsure about the latter:

-When using SimTK::Constraint::CoordinateCoupler, should I expect only mobility forces?
-In general, what is the reference frame for the output quantity 'Vector_< SpatialVec > & bodyForcesInA', and how can I know which body each component refers to?

Sorry if it is too obvious, but I cannot figure out how to get the information I need from the constraints. I really appreciate your help!

Best regards,
Simone

[Michael Sherman]

Yes, the coordinate coupler will only produce mobility forces. Those forces will already be included in the mobilizer reaction forces (converted to spatial forces) so you might not need to get them explicitly. (Mobility forces from any source are always included in reaction forces.)

If you want to see the mobility forces from the constraint, likely Constraint::getConstrainedMobilityForcesAsVector() is the easiest way.

This probably goes without saying, but I highly recommend testing this carefully on some simple system where you know the answer! I'm sure the final solution is just a few lines but getting there could be tricky.

BTW internally Simbody computes constraints in an "ancestor" frame A, which is the body frame of the highest-numbered body that is common to everything being constrained. That's not necessarily Ground, and I believe there are convenience methods that report in Ground -- if you see a function that is returning things in the "A" frame, keep looking!

Sherm

[Simone Hendriks]

Hi Sherm,

I think I understand it now. I falsely assumed the mobilizer reaction forces only included the mobility forces when directly specifying a motion, but it turns out it also applies for constraints acting directly on the generalized coordinates. That means, for example, that SimTK::Constraint::ConstantAcceleration and SimTK::Constraint::CoordinateCoupler will "appear" in findMobilizerReactionOnBodyAtOriginInGround(), but not SimTK::Constraint::Ball or SimTK::Constraint::ConstantAngle, is that right? I tested it on a minimal system with two sliders, and it seems to hold true.

Thanks again for your help!

Best regards,
Simone

[Michael Sherman]

Right!

[Simone Hendriks]

Hi Sherm,

I still have not found a convenient solution for the problem I am trying to solve, I would appreciate if you could shed more light upon it. Let me state the problem with a simpler equivalent system.

• The system has two mobilized bodies, each one of the same type, with one generalized coordinate.
• A Constraint::CoordinateCoupler constrains both generalized coordinates to obey a certain relationship.
• A Force::Custom acts upon each body. In the implementation, several calls to applyOneMobilityForce() are made (because in this case, it is more convenient to apply a mobilized force than a body force).
• One of the forces, however, depends on the reactions (friction-like). Therefore, I am computing it inside Force::Custom::Implementation::realizeAcceleration() and applying it "later" in Force::Custom::Implementation::calcForce(). By the way, is that a correct approach?
• These reaction-dependent forces, as mentioned in the previous posts, must be computed from the reaction force both imposed by the constraint and the mobilizer itself. Therefore, the other applied mobility forces must be subtracted somehow from the "net" mobilizer reaction.

My question is, how can I subtract these forces? And where should I take the value of these forces from? Because if I store the value in the Force::Custom class, how can I make sure this force actually corresponds to the previous time step?

Thanks a lot!

Best regards,
Simone

[Michael Sherman]

Hi, Simone.

A few thoughts:

- To get reaction force dependent friction, it makes sense to use the previous-step reactions to avoid an intractable mutual dependence among forces & accelerations. That means you need to remember the previous-step reaction forces, and memory == state! The best way to do that in Simbody is to have a state variable that is updated automatically whenever a step completes -- see auto update state variables. Then you have your friction force depend on that state variable. That is the correct approach, rather than computing it in your custom force.
- I'm not sure I understand what you are trying to do by subtracting out forces. The reaction forces at joints in Simbody are defined to be exactly what you would feel if you cut the joint and then had to hold it together. Typically that is what you would want to work with for friction at a joint. For example, if you model friction at a pin joint as being dependent on the radial reaction force, I would use take the (previous step) reaction force, project it onto the pin joint axis, and subtract the result from the total reaction to get just the radial component.

Not sure if that's helpful -- please LMK if not.

Regards,
Sherm

[Simone Hendriks]

Hi Sherm,

Regarding the reaction force, where should I be setting the allocated auto-update discrete variables? And by auto-update does it mean that, no matter when I set the value, it will be updated only after a step finishes?

As for the actual friction force calculation, it does not directly depend on any of the physical reaction forces, but on the reaction force of the mobilizer. Let's say for example that a system is composed of two sliders with generalized coordinates q1 and q2, constrained so that q1-q2=0. Upon each slider, a friction force is acting that depends on the mobilizer reaction and the coordinate coupler constraint forces (included in the mobilizer reaction as discussed earlier). The issue is, upon the sliders several mobilizer forces are applied, and therefore they are included in the mobilizer reaction, so they must be subtracted somehow. I know this example may sound weird, but the actual mobilized bodies are custom mobilizers that simplify the real system a lot, and the drawback is that these "fictive" mobilizer and coordinate coupler constraint forces must be converted into the reaction forces that develop in the real system. In summary, I need to calculate the body forces due to the mobilizer alone and the coordinate coupler.

I hope I made the problem clearer, and thanks again for your help!

Best regards,
Simone

[Michael Sherman]

You can read about auto update state variables in the doxygen for State::allocateAutoUpdateStateVariable(). Basically you get a state variable and a matching cache entry. You write to the cache entry and then that gets used to update the state variable at the end of every step.

There are several examples that use them, but a good model for what you're doing might be the ExponentialSpringForce element recently added by Clay Anderson. If you look at the implementation in Simbody/src/ExponentialSpringForce.cpp you can see how he used those. In your case you would calculate reaction forces in realizeAcceleration(), writing the result into the auto-update cache entry. Then your friction force element will see that value in the auto-update state variable.

Sherm