AnyBody Modeling System FAQ
You can actually specify ligaments and other (passive element) forces that depend on position and velocity (in general springs and dampers with almost any explicit expression you can come up with). In particular, we have a ligament object class which is specially designed for ligament, but in general it is nothing else than an applied force. The downside is that the ligament forces cannot be a function of the muscle forces in this way, since they merely enters the inverse dynamics solution as applied forces. We hope to resolve this problem in a future version. One could currently model ligaments as simple muscles. This has, as far a I know, been done in some studies in the literature.
The input for AnyBody is simple STL files. They are converted by AnyBody to ease subsequent handling of the data, so you are not able to find STL files in the repository, but that is all you need to input your own geometry data. The STL files can also represent the environment such as wheelchairs, floors, tools, and other model elements.
They are from 3D scans from plastic skeletons. They are actually not in a very good quality and we would like to get access to better data, but of course they need to be without all sorts of restrictions about their use; this is both due to our own usage and due our desire to place them in the public domain in the model repository.
You can imagine a number of different methods, and we have been trying them all on different models while we were developing the technology.
- EMG versus activity. The advantage is that we are measuring on the individual muscles directly. The disadvantage is the problem of correlating EMG to muscle force and the fact that it is difficult or impossible to measure all muscles.
- Moment arm validation. It is possible to compute the moment arm of the model's muscles and compare them to values from cadaver studies.
- Prediction versus measured forces between the body and the environment. This is not a good method for gait, but in many other cases it works well. For instance, in pedaling, the pedal force can be divided into a radial and a tangential component. With two feet this gives us four forces to produce a single crank torque. There are infinitely many combinations of these four forces that can produce the correct crank torque, and the four forces are functions of the muscle recruitment. If the system predicts the correct pedal forces, then this indicated that the muscle recruitment is also reasonable.
The model predicts muscle activations that are mathematically defined as the muscle force divided by the strength of the muscle. We use the current strength of the muscle, which depends on the muscle model you apply in the muscle definition. The simplest muscle model use isometric MVC for all configurations of the muscle, but we also have a more complex 3-element Hill-type muscle model, where the strength depends on muscle length and contraction velocity.
From this mathematical definition of Muscle Activation, it is obvious that it is not equivalent to EMG, though their variation patterns must be alike. You can import EMG data for visualization along with computed data. You can also use EMG data to apply forces on the model, which will be a kind of prescribed muscle forces. But you cannot drive the model completely by EMG since it is an inverse dynamics model. To make an EMG driven model, you must apply a forward dynamics simulation, which is currently not available in AnyBody.
The kernel of AnyBody's mechanical module uses what we often refer to as a Full Cartesian Formulation using a rigid-body set of coordinates for each segment (rigid body). The dynamic equations are basically the Newton-Euler equations, but they are transformed during the analysis. We believe that any approach for setting up the equations should produce the same results; efficiency and flexibility are the main issues here.
Our approach largely follows the textbook of Nikravesh (University of Arizona).
Forward dynamics simulations are not possible in AnyBody (yet). It is our hope to be able to include it at some point in the future. We have the whole mechanical engine but still there is some way to go. The requirements for making good inverse and forward dynamic solutions are somewhat different.
This is not easy to answer accurately. Of course, all major muscles are important, their strength properties as well as their moment arms. In order to model moment arms reasonably, it is necessary to divide larger muscle into branches, so that the combined effort of the branches match the one of a complicated muscle complex. We believe that the model we have presented cannot be much simpler and still be a meaningful 3D model. On the other hand it is very difficult to find proper data for a more accurate model. There is certainly room for adjustments and improvements, which is also one of the ideas of the public repository, namely that all users can help each other improve the models.
Muscles can interact with bones at fixed points (so-called via-points) and by wrapping surfaces. Currently, muscle lines can wrap over primitives such as spheres, ellipsoids, and cylinders. You can make any set of primitives for a given muscle.
The ground force is measured in the gait experiment. It is measured by a force plate and the measurement is converted into a 3D force vector and the associated point of application (center of pressure). Pressure data measure by any other measurement system can similarly be converted into point loads. A point load is adequate in the model, where the foot is a single rigid segment. The position of the center of pressure is defined in the data set. We simply create a force plate (as a segment) in the model and add the measured forces to this segment. The position of the force plate is controlled by the measured data. The contact between the foot and the force plate is made using a reaction force that transfers all forces applied to the force plate to the foot.
No not directly. AnyBody is not a FEA code. You can export force data from AnyBody which you may be able to apply to a FE model.
Both yes and no! We do not have an interface (exit) that allows you to program your own bit of the analysis in like C or FORTRAN and link that to AnyBody. We would like to do so of course, but it is not on the here-and-now-to-do list. We have a few close collaborators where we made special arrangements though, but we have not yet done so in a more formal way. We do however plan to open as much as possible for customization of objects from the interface and muscle models is indeed one issue where we will. Another issue is the definition of the objective function for muscle recruitment.
We are currently working on a new feature to the system that will allow the user to define his/her own muscle model. If the user can formulate the muscle strength as an analytical function of length and contraction velocity, then he can code it into his own muscle model and use it in the analysis.
We are always very open for suggestions on model features, we ought to include. Any feedback on desired customization options and maybe even plug-ins are very welcome.
Yes. A very important point of our technology is that it is a MODELING system. This means that the users defines/constructs the models, and as such the user also has complete access to make any modification of the existing repository models.
In fact, we are hoping that our users will continually add new models and modifications to the repository.
The user can change all model properties. Typically, we operate with more general properties than actual material properties since we are not modeling the material itself as in a FE model. The muscle properties (and the properties of all other objects in the models) are in the (open) AnyScript text files. The software itself does not contain a fixed model, neither parameters nor topology.
It is not. The muscle activation is allowed to change instantaneously, so we are assuming - like most other inverse dynamics approaches - that the activation dynamics is "fast enough".
A model needs an underlying data structure. In systems with graphical interfaces such as CAD systems, the norm is that this data structure is hidden from the user, and he or she only sees the model through the graphical interface. This can work very well for many problems. However, a body model can be a very complicated set of data, and users will quickly find themselves in a situation where they desire a closer relationship with the data they are working on. So we have decided to let the user work directly on the data of the system. To help in this job, we will continue to develop better editing and browsing facilities in the system. This is much the same philosophy as well-known and popular systems such as Matlab and Tex.
The short answer is no. AnyBody is a rigid body dynamics system, and the basic assumption is that all elements are non-elastic. However, the system's muscle model does include the effects of the serial-elastic and parallel-elastic elements of the muscles. Ligaments can in principle be modeled as muscles with no active element, but this is very difficult, and the model will be extremely sensitive to small variations in length of these ligament elements. AnyBody Technology is investigating better methods for modeling of such passive elastic elements.
Yes. In the chart view, when you click the "Copy to clipboard" icon, you are presented with a menu that allows you to choose to export data as text. If you do so, simply paste the data into your spreadsheet, and you get the curves in the picture represented as columns of numbers in the spreadsheet.
No. AnyBody is based on inverse dynamics, so it computes the movement first and afterwards recruits the muscle forces to realize it. Inherent to this process is the assumption that muscle forces are available as quickly as they are needed. AnyBody also assumes that the body recruits muscles "optimally". More precisely, this means that AnyBody makes the muscles cooperate maximally in such a way that fatigue is postponed as far as possible.
Oops, that's a difficult one. The fact is that we don't. What we know is that if a number of conditions are fulfilled, then the results are not way off. These conditions are:
The model must correspond to the mechanics of the muscle system you want to investigate. What "correspond" means is a matter for the skilled user to determine. As with all computer modeling of natural phenomena, there is a level of model complexity that will give you the desired accuracy, but only experience can tell you in advance what that level is. If you have no experience, consult the literature. If there is no literature, try different levels of complexity and estimate the convergence of the result.
The movement you are modeling must be skilled. This is because AnyBody to resolve the inherent indeterminacies of the living body assumes that the body operates optimally. This requires some level of skill.
The movement must be so slow that the muscles have time to activate and de-activate as quickly as the simulation predicts. Muscle activation is an electro-chemical process. and it takes time. AnyBody does not take this time into consideration when it recruits muscle forces, so there is a danger that it may predict onset and offset of muscles faster than what the organism can really accomplish.
Why do we know that, given these conditions, the result is not way off? Because the muscle recruitment of AnyBody honors a number of known properties of musculoskeletal systems:
These systems are subject to the laws of nature, more specifically the laws of mechanics. Certain principles of equilibrium, motion, power, and energy are given by the laws of mechanics, and the simulations of AnyBody are entirely built on these.
Muscles collaborate when they can. This means that if several muscles are spanning the same joint, then they share the load between them in such a way that stronger muscles carry more load than weaker muscles. This principle is honored by the simulations of AnyBody.
Antagonistic muscles are a fact of life. They are muscles that appear to be working against the movement in the sense that they perform negative work. AnyBody predicts the presence of antagonistic muscles when they are necessary and even explains their purpose.
When the load is increased, the muscles will collaborate in such a way that no muscle is loaded above its physiological strength, if there is another way of carrying the load. AnyBody honors this principle. If you get muscle activations above 1, then it is because there is no way to carry the applied load with the muscle configuration you have specified.
The fact of the matter is that the simulation result of AnyBody as all other numerical analysis is inaccurate to a certain extent. But this does not mean that it is without value. You will find when you use AnyBody that detailed models of the musculoskeletal system can provide you with much, much more information than you can find from qualitative or experimental investigations alone.
In principle it does, since it completely resolves all mechanical aspects of the problem. But you are probably thinking whether the system initially computes joint moments and then proceeds to distribute them on the muscles spanning each joint. This is not the way the AnyBody Modeling System does it. Contrary to popular belief, it is really not a viable solution. The explanation is that because we have many bi-articular muscles, there is not unique solution to the joint moment distribution problem. Depending on the actions of the bi-articular muscles, net moment may be transferred from one joint to the other.
Instead, the AnyBody Modeling System sets up a redundant system of equilibrium for the entire system including the muscles. This redundant system is subsequently solved uniquely via the system's advanced muscle recruitment algorithms.
But the fact of the matter is that for joints with bi-articular muscles. the concept of joint moments really does not exist.
Bicycling is a typical closed-chain example. The legs and crank together form a closed mechanical chain. The AnyBody Modeling System handles closed chains in the mechanism, but it is true that many other systems for mechanism analysis do not.
There are really two distinct problems connected with closed chains. The first problem is in the kinematics where closed chains complicate the solution algorithm because make it impossible to resolve the positions by stepping from one joint to the next until the free ends of the mechanism are reached. The AnyBody Modeling System employs a very general method for position analysis and does not rely on assumptions of open chains.
The second problem is in the computation of muscle forces. The classical way of doing inverse dynamics is to compute joint moments and subsequently distribute them onto the individual muscles. When there are closed chains present, the problem of resolving joint moments may not have a unique solution.
However the AnyBody Modeling System does not go via joint moments. Instead it sets up a redundant system of equilibrium for the entire system including the muscles. This redundant system is subsequently solved uniquely via the system's advanced muscle recruitment algorithms.
The system computes reaction forces automatically. If your model is supported in a statically determinate fashion, then there is only one unique set of reaction forces that balances the system correctly, and AnyBody will compute if for you.
What happens then if the system is not statically determinate? Just to give you an idea of such a situation, consider a body standing on hands and knees on the floor. It needs only three support points to be stable, but it has four points. AnyBody handles this case through its muscle recruitment. There are infinitely many combinations of the four support forces that balance the model, and the human body distributes the force between the two hands and two knees by contracting and relaxing muscles until a reasonable equilibrium is attained. You can think of a situation where the majority of the support force was carried by one of the hands. The body is likely to feel that this hand is overloaded and seek to redistribute the force to the two legs and the other hand until a more even load distribution was found. This is exactly what the AnyBody Modeling System does. It looks at all the muscle loads in the system and finds the distribution of muscle forces that optimizes the load distribution.
In some cases it can improve the accuracy of the analysis tremendously if you have measured reaction forces available and impose them on the model rather than let the system compute them. This is particularly the case for gait and other very dynamic problems where a large part of the reaction force comes from balancing of inertia in the system. If you are modeling a measured gait cycle, then you have essentially measured positions, and they must be differentiated twice to get the accelerations the system needs to resolve the inertia forces upon which the ground forces will eventually depend. Every time you differentiate measured data you increase the inevitable measurement inaccuracy by an order of magnitude, so ground reaction forces are not strictly necessary, but they help a lot for dynamical problems.
Yes, the AnyStdJoint locks all mutual degrees of freedom between the segments it connects.
The initial positions, only serves as the initial guess on the segments positions. This means that if the model assembles correctly one can be satisfied with the initial positions. They will have no influence on any analysis results. If the model is a closed chain mechanism then there might be several kinematic solutions that will fulfill the kinematic constraints on the model. In such a case the initial position can be used to ensure that the model chooses the correct solution, simply by providing initial positions which are close to the correct one.