PDA

View Full Version : Myoskeletal Inverse Dynamics (BIONET Topic 2)



Ton Van Den Bogert
01-22-2002, 12:09 AM
Prof. Hatze's has classified the responses as "progressive" or "conservative".
I will probably fall into the conservative camp because of my reservations
about adding more realism and complexity to models. On the other hand, I
also have some progressive ideas to improve the methods for doing inverse
dynamics.

Below is my response to Prof. Hatze's original five discussion points.

> 1. HUMAN BODY MODELS currently used in biomechanics are unrealistic and,
> for most investigations, inadequate.

I firmly believe that there is an appropriate model complexity for each
question. At Hof mentioned this already. I think mostly this is a
philosophical or intuitive argument: Occam's razor, or as Albert Einstein
said: "Make things as simple as possible - but no simpler". See also
http://www.nwmangum.com/Occam.html

This is why I think Occam's razor is an important principle. If a model has
more parameters than needed to explain the data, it becomes difficult to
understand how important each property of the model was for obtaining the results.
It also becomes risky to apply the model to situations where it was not
validated. These issues are somewhat analogous to having too many
parameters in a regression model. Try fitting a 10th order polynomial
to five data points, and you will see what I mean.

This applies mostly to forward dynamic analyses but there is also a more
practical issue that applies equally well to inverse dynamics. If we
painstakingly collect data to make our models more and more realistic, without
knowing that the added complexity will only change the result by 1%, and if the
uncertainty in the results was already 10% for other reasons, then we are
clearly not using our time effectively.

> 2. Current MOTION RECORDING TECHNIQUES rely almost exclusively on the
> detection of the spatial motion of passive or active position or (and)
> angular orientation sensors (markers, goniometers, magnetic field sensors,
> etc.)

I very much agree with Prof. Hatze's statement "We would be well advised
to begin thinking about what our motion sensors actually record.".

Specifically, I think we need to pay attention to designing protocols
(marker placement, and associated linked segment models) that give the
best information about skeleton movement. This is important because
joint moments are very sensitive to errors in joint center positions.

However, skeleton motion is not necessarily appropriate for the inertial
terms of the equations of motion. Most mass in the human body is not
in bone, but in soft tissue. So, I suggest that we need to think about
using some of the markers for skeleton motion, and other markers, which
may "wobble" relative to the skeleton, to obtain good data for the inertial
terms. Both sets of markers will need to be on the body during the gait
analysis.

Multiple measuring modalities should also be explored. If we apply model-based
parameter estimation techniques (i.e. nonlinear weighted least-squares), we
should be able to obtain the best possible estimate of, say, muscle forces, that
is consistent with simultaneously measured marker trajectories, ground reaction
forces, accelerometer signals, goniometer signals, and EMG. The more redundancy
in the set of measured variables, the better. We can include anything else
we can measure: earth-referenced magnetic inclination sensors, angular rate
sensors, foot pressure etc. Ideally, we should be able to get good results with
just body-mounted sensors, and no fixed equipment such as force platforms and
cameras.

> 3. Closely related to point 2 above is the problem of appropriately
> PROCESSING THE MOTION DATA (conditioning, filtering, and time derivative
> computation of noisy data).

This is very important. If we do not pay attention to this, we have the
risk of adding terms to the equations that contain more noise than
signal. For all variables, we should attempt to filter them optimally,
i.e. choose a filter that minimizes the total error which is the sum of
the signal that was removed and the noise that was not removed. If this is
consistently done, we protect ourselves against errors from overly complex
models. However, sometimes this criterion will result in a very low cut-off
frequency, and then we remove so much of the signal that we might as
well not have measured that variable. This is why appropriate model
complexity can save a lot of time. It makes no sense collecting data and
then filtering it out again.

An example would be the well-known fact that the knee joint axis does
not have a fixed position and orientation relative to either body segment.
So, one might attempt to derive the instantaneous helical axis from
gait data and compute the joint moment relative to that axis at each time.
Problem is that this analysis is very sensitive to noise and skin movement.
If we do not filter appropriately, the results become unreliable. If
we do filter optimally, we may find that the cut-off frequency needs to be
so low that the joint axis no longer moves. So in this case, I think that
the "naive" assumption of a fixed axis of rotation is perfectly fine.

> 4. Most present-day motion analysis systems compute, if at all, only the
> skeletal system characteristics (resultant joint moments, shear and
> compressive joint loads, etc.). The REAL AND DIAGNOSTICALLY MOST
> INTERESTING PROBLEM IS, HOWEVER, THE INVERSE SOLUTION OF THE MYOSKELETAL
> DYNAMICS.

This would depend on the purpose of the analysis. I agree in general that estimates
of muscle forces would be more useful, but these would probably always be less
reliable than estimates of joint moments. It is a trade-off that must be considered
for each application. With the current state of the methodology, we probably would
only consider estimating muscle forces when joint moments are not useful at all.
For example: estimating the load of the anterior cruciate ligament is not
really possible without estimates of forces in the patellar tendon and
hamstrings, and we need to just accept the large uncertainty in the analysis
(but I would like to see that uncertainty estimated also, too often these results
are presented without error estimates). For those questions where joint moments
may provide some useful information, I would not recommend taking the extra step
to estimate muscle forces.

Hopefully we can improve on the methods to estimate muscle forces so that
the trade-off decision may be more often made in favor of doing that type of
analysis. Such improvements should probably come from some form of EMG-assisted
static optimization. Also I would like to see muscle models (for force production)
used in static optimization methods, to ensure that solutions are consistent
with known muscle properties. If we do that, we may find that this reduces
the solution space considerably and the choice of optimization criterion is no
longer as critical. There was a thesis (Muscle Force Prediction During Human Gait,
Jan Thunnissen, University of Twente, Netherlands, 1993) but this idea has not
really been applied. Forward dynamic simulations that are optimized to match
a subject's gait data are another way to incorporate muscle properties in the
analysis, but at a much higher computational cost.

> 5. Incorrect values of SEGMENT PARAMETERS (segmental lengths, masses,
> volumes, principal moments of inertia, components of mass centroid
> locations, etc.) also significantly influence the quality of the motion
> analysis results.

I think that these issues can be resolved using sensitivity analysis,
as has been mentioned before. This is important so that we can direct
our efforts at improving those model properties that have the most
influence on the results.

Ton van den Bogert

--

A.J. (Ton) van den Bogert, PhD
Department of Biomedical Engineering
Cleveland Clinic Foundation
9500 Euclid Avenue (ND-20)
Cleveland, OH 44195, USA
Phone/Fax: (216) 444-5566/9198

---------------------------------------------------------------
To unsubscribe send SIGNOFF BIOMCH-L to LISTSERV@nic.surfnet.nl
For information and archives: http://isb.ri.ccf.org/biomch-l
---------------------------------------------------------------