Has anyone looked into implementing a pseudo-rigid body model in the AnyBody Modeling System? Essentially, as an example, a pseudo-rigid body model replaces a cantilever beam with two shorter beams coupled by a torsional spring whose stiffness is a variable parameter. So, is it feasible to model a torsional spring that couples two rigid beams? I suspect it should be (and hence the first question up front).
Here is a reference that talks about pseudo-rigid body models:
It’s no problem to make a rotational spring - one can make a spherical joint between 2 segments, define an AnyForce object based on the underlying rotational measure. But the problem is to prescribe the right amount of ‘deflection’ (rotation) to drive rotation between these 2 segments (we do an inverse dynamics analysis - motion to forces, not forward dynamics). It cannot be a function of the joint reaction forces, because those will be found in the muscle recruitment optimization of the simulation in every timestep.
It’s, of course, theoretically possible using an inverse-inverse dynamics, FDK, or iterative schemes, where you compute everything for a single timestep, evaluate deflection, continue with the adjusted values. The latter could even be done using FEA and be applied to the full bone without a spherical joint.
But these approaches are quite difficult to implement - one would need to separate existing segments into necessary number of components, which might be quite tricky. An introduced ‘knee’ is not necessary the same for different components of bending moments. The question is how much accuracy one would gain by implementing all of that.
Kind regards,
Pavel
P.S. I presumed that we are talking about a long bone that deflects, but possibly you had something else in mind. If possible try to elaborate on the actual application.
I have devices like deformable tubing, catheters, wires, etc. in my mind, not bones. I would like a technique like pseudo-rigid body modeling to modeling such deformable devices.
I should have stated that motion (from MoCap) is already available so, unless I am missing something, it seems there is no need for additional analyses (such as inv-inv dynamics, FDK, etc.). Correct?