Kurfess T.R. Robotics and Automation Handbook

Подождите немного. Документ загружается.

-10 Robotics and Automation Handbook

collision detection, kinematic constraints) can be directly answered using kinematic simulation. Inclusion

of the dynamics becomes important when the engineer is interested in more detailed information such as

reaction forces, sizing motors/actuators, sensor selection, control design, estimating power consumption

and determining how contacting parts behave. We consider two approaches to simulation of the robot

dynamics. First is the canned approach that handles the computation of the dynamic equations of motion

based on a CAD model of the system. The second approach is based on using a time domain simulation

package such as Matlab’s Simulink or MatrixX’s SystemBuild

.Theﬁrst approach is generally much easier

and provides sufﬁcient information to answer fundamental questions. In addition, in many cases, it is

possible to integrate the dynamic simulation package with a control package such as Simulink or System-

Build. The second approach requires a deeper understanding of the system’s dynamics but enables greater

ﬂexibility in terms of modeling the system (including control algorithms, sensory feedback, arbitrary

inputs).

21.3.4.1 Multibody Dynamic Packages

Two examples of multibody dynamic simulation packages are LMS International’s Dynamic Motion Sim-

ulation (DADS) and MSC Software’s Adams. With both packages, you begin by either building a pa-

rameterized model of the robot or importing the model from a CAD system, much like the simulation

packages described earlier. The software automatically formulates and solves the dynamic equations of

motion. Both MSC Adams and DADS

have integration capabilities with control simulation software

such as Simulink and SystemBuild. The engineer can take the geometrically deﬁned models and easily

incorporate them within block diagrams created with the control system software. It is then possible to

evaluate a wide class of mechanical and control designs and estimate the system’s performance prior to

ever cutting metal.

SolidWorks provides an option for integrating the Adams simulation technology directly into the

SolidWorks environment. This interface, CosmosMotion

, is a physics-based motion simulation pack-

age that is fully embedded into the SolidWorks environment. The part’s geometry and mass properties

are deﬁned inside SolidWorks. CosmosMotion reads these characteristics, along with all of the deﬁned

constraints. The engineer speciﬁes joint motion or forces, and the software displays the resulting forces

and/or motion of the system based on fundamental physical principles. The advantage of this approach

is twofold. First, the design and simulation is embedded in the same interface. The user is not concerned

with ﬁle transfers or compatability issues. Second, the same software package that the engineer uses to

design the robot is used to deﬁne the geometry and mass properties for the simulation. These advantages

come at a cost. A professional version of SolidWorks, at the time of this writing, is $4000. Likewise, the

CosmosMotion package is $6000.

Another option is to import the CAD model into a time domain simulation package such as Matlab

and Simulink. SimMechanics

provides an effortless importation of SolidWorks CAD assemblies into

the Simulink time domain simulation environment. This approach enables the ability to simulate the

behavior of mechanical, control, and other dynamic systems. As an example, we constructed a sim-

ple three-degrees-of-freedom manipulator in the SolidWorks environment. This model, shown in

Figure 21.9, consists of four parts: a base and three links. These four parts are combined in an as-

sembly. The assembly includes the ability to deﬁne constraints (what SolidWorks calls Mates) between

parts. In the case of the robot which has three revolute joints, we require six constraints: three con-

straints forcing the joints on adjoining parts to be collinear and three constraints forcing each face on

adjoining parts to be as close as possible. Now, when moving a part, the whole assembly moves, il-

lustrating the constrained motion due to the robot’s kinematics. It is also possible to include collision

detection and restrict motion when constraints are reached. At this point, SolidWorks is restricted to

constraint detection and ranges of motion. However, when deﬁning parts, you can include not only

the geometry but the types of materials as well (speciﬁcally the material’s density). SolidWorks, like

many CAD packages, includes the ability to compute, based upon the geometry and materials, the

resulting mass properties for each part (mass, location of center of mass, principal axes of inertia,

Robot Simulation 21

-11

FIGURE 21.9 SolidWorks robot model (courtesy Oak Ridge National Laboratory).

moments of inertia...). SimMechanics takes this information, along with the constraints, derives the

dynamic equations of motion, and exports the results into a Simulink model. It is then straightforward

to include actuation forces, sensors, and control to enable a high ﬁdelity numerical simulation of the

robot.

The minimum requirements for this approach is the cost associated with SolidWorks in addition to

Matlab ($1900), Simulink ($2800), and SimMechanics ($4000). If these prices are beyond budgetary

constraints, there are other options. First, there are software packages that are lower cost. In terms of

dynamic simulation, a professional license for ProgramCC

®,6

is $750. The lower cost is offset by reduced

ﬂexibility. There is no graphical interface for developing simulation block diagrams as there is in Simulink

or SystemBuild. The basic package is predominately script based. It is possible to construct sophisticated

dynamic models and simulate the response of the system to various inputs, but it is not as straightforward

as with Simulink.

21.4 Build Your Own

One last possibility is to build your own simulation capabilities. The clear disadvantage is time and know-

how. Our motivation in this last section is to provide some insight into the know-how. There are a few

obvious, and not so obvious, advantages to building your own simulation package. Clearly, cost is one

consideration. If you already have a good understanding of programming, there are quite a few free or

inexpensive utilities available that can ease the process of writing a robot simulation package. Another

reason is ﬂexibility. It is quite possible that there are no robot simulation packages available that exactly

answer your needs. If this is the case, you may need to develop your own program.

http://www.programcc.com/

-12 Robotics and Automation Handbook

21.4.1 Graphical Animation

There are a number of different ways to visually display robot motion. In this section, we will focus on

where to begin if we wish to develop a package similar to the systems covered in the previous section. Many

of these packages exploit the OpenGL interface. OpenGL was originally developed by Silicon Graphics, Inc.

(SGI) as a multi-purpose, platform-independent graphical API. OpenGL is a collection of approximately

150 distinct commands that you can use to specify objects and operations needed to produce interactive

three-dimensional applications. To provide a starting point, note that OpenGL is based on object oriented

programming, C++. To efﬁciently develop a robot simulation package, you develop a set of classes that can

constructsimple objects such as spheres, cylinders, rectangles, andwhatever basic objects you need to deﬁne

a robot. OpenGL uses a number of vector and matrix operations to deﬁne objects in three-dimensional

space. As a simple example, the following function would draw a cube.

Void DrawCube(float x, float y, float z)

{

glPushMatrix();

glTranslatef(x,y,z);

glBegin(GL\_POLYGON);

glVertex3f(0.0f, 0.0f, 0.0f); // top face

glVertex3f(0.0f, 0.0f, -1.0f);

glVertex3f(-1.0f, 0.0f, -1.0f);

glVertex3f(-1.0f, 0.0f, 0.0f);

glVertex3f(0.0f, 0.0f, 0.0f); // front face

glVertex3f(-1.0f, 0.0f, 0.0f);

glVertex3f(-1.0f, -1.0f, 0.0f);

glVertex3f(0.0f, -1.0f, 0.0f);

glVertex3f(0.0f, 0.0f, 0.0f); // right face

glVertex3f(0.0f, -1.0f, 0.0f);

glVertex3f(0.0f, -1.0f, -1.0f);

glVertex3f(0.0f, 0.0f, -1.0f);

glVertex3f(-1.0f, 0.0f, 0.0f); // left face

glVertex3f(-1.0f, 0.0f, -1.0f);

glVertex3f(-1.0f, -1.0f, -1.0f);

glVertex3f(-1.0f, -1.0f, 0.0f);

glVertex3f(0.0f, 0.0f, 0.0f); // bottom face

glVertex3f(0.0f, -1.0f, -1.0f);

glVertex3f(-1.0f, -1.0f, -1.0f);

glVertex3f(-1.0f, -1.0f, 0.0f);

glVertex3f(0.0f, 0.0f, 0.0f); // back face

glVertex3f(-1.0f, 0.0f, -1.0f);

glVertex3f(-1.0f, -1.0f, -1.0f);

glVertex3f(0.0f, -1.0f, -1.0f);

glEnd();

glPopMatrix();

}

OpenGL uses what is called a matrix stack to construct complicated models of many simple objects. In

the case of the cube, the function ﬁrst gets the most recent coordinate frame, possibly pushed onto the

stack prior to this function call. Then the function glTranslate() performs a translation on the coordinate

frame. Likewise there are functions such as glRotate() and glScale() that provide the ability to rotate and

scale the object. The glBegin() and glEnd() functions provide bounds on the deﬁnition of the verticies,

deﬁned by the glVertex3f() function, of the object.

Your robot will consist of a number of these primitives, thus the motivation for object-oriented pro-

gramming. Animation of motion will require the coordination of these primitives. It is now clear that a

visual robot simulation program requires a combination of programming for animation (using utilities

such as OpenGL) and an understanding of robot kinematics. There are a number of references, includ-

ing this handbook, that provide excellent guidelines for writing the algorithms necessary for providing

Robot Simulation 21

-13

FIGURE 21.10 OpenSim simulation of vehicle and arm (courtesy of Oak Ridge National Laboratory).

coordinated motion of a robot (Asada and Slotine, 1989; Craig, 1989; Spong and Vidyasagar, 1989; and

Yoshikawa, 1990). Basically, you will have some form of interface that provides a desired motion for your

robot. This can be from a script ﬁle, mouse motion, slider bars on a dialog box, or any basic form of input

into your application. The kinematic routines will transform the desired motion of the robot into the

required transformations for each primitive or link on your robot. The results of these transformations

are passed to functions such as glTranslate() and glRotate() to provide the animation of the coordinated

motion.

Clearly, the above description is not sufﬁcient to enable you to immediately start writing software for

robot animation. However, it does provide a good starting point. There are many examples where research

groups have used OpenGL to develop their own robot simulation package.

7,8

In addition, there are a

number of good references on programming in OpenGL (Hawkings and Astle, 2001; Woo et al., 1999).

These references, combined with the above robotics references, provide guidance on exactly how to write

software that animates objects, for example, the robot shown in Figure 21.10.

21.4.2 Numerical Simulation

InSection 21.3,webrieﬂy describedthe utilityofprogramssuchas Simulinkand SystemBuildfor simulating

the motion of a robotic system. However, this approach required the use of a secondary software package

for computing the dynamic equations of motion. In this ﬁnal section, we will describe a simple procedure

for computing the equations of motion for a serial link manipulator and embedding the dynamics in a

Simulink simulation. The basic methodology requires the use of a symbolic software package and a deeper

understanding of dynamics. The approach is based on using homogenous transforms to describe key

points on the robot: joint locations and centers of mass. Using the transformations, we construct linear

and angular velocity vectors about each center of mass. The displacement terms are used to construct a

potential energy term while the velocity terms are used in the computation of the kinetic energy. We use the

LaGrange approach to compute the resulting equations of motion. We then describe how to include joint

ORNL’s simulation package: http://marvin.ornl.gov/opensim/

Georgia Tech’s simulation package: http://www.imdl.gatech.edu/mbsim/index.html

-14 Robotics and Automation Handbook

and tip forces as well as partitioning the equations so that they are suitable for any numerical integration

routine. While this approach is presently limited to serial link manipulators, it should give the reader a

better understanding of the mechanics associated with simulation of robot dynamics.

Two primary elements in any time domain simulation consist of the state equations and an integration

routine. The state equations are derived using basic principles in dynamics. Our objective is to formulate

the dynamics into a general form, given in Equation (21.1), where

x represents a vector of states for the

system and

u is a vector of control inputs. In the case of a robot, the vector

x could represent the position

and velocities of each of the joints. The vector

u would contain the joint forces due to the actuators driving

the robot. The equation is derived from the system’s dynamic equations of motion.

x = F (

u, t)

(21.1)

During each time step of the simulation, we compute the forces driving the robot, possibly due to a

control law, and compute the derivative of the state using Equation (21.1). We then use an integration

routine to compute the state of the system,

x, for the next time step. The basic elements are shown in

Figure 21.11.

Clearly, the computation of the state equations requires quite a bit of effort. The following section

provides a basic procedure for computing the dynamic equation of motion, in the state equation format

described above, for a general serial link manipulator. The approach is based on computing, symbolically,

the position and orientation of each joint and center of mass of the robot. While not necessary, we

use the Denavit-Hartenburg approach. First, as a review, the homogeneous transform is expressed using

the traditional Denavit-Hartenberg (D-H) representation found in most robotics texts where the four

quantities θ

(angle), α

(twist), d

(offset), l

(length) are parameters of link and joint i.







θi

−s

θi

αi

θi

αi

θi

αi

−c

θi

αi

θi

0 s

αi

00 0 1







(21.2)

The conventional use of the homogeneous transform treats each subsequent transformation as a body

ﬁxed rotation and translation.

We also assume that we can deﬁne an additional set of homogeneous transforms from each joint to

a point on each link where the associated mass properties (mass and inertia matrix) are known. So,

our basic methodology consists of using two sets of homogeneous transformations; one to describe the

pose of the arm and one to identify the displacements and velocities, both translation and rotation, of

the center of mass of each link and payload with respect to the manipulators state (joint position and

velocity). We extract from the transforms the vertical displacement of each center of mass of each link for

an expression of the total potential energy of the system. Likewise, computation of the system’s kinetic

energy is based on computing the linear and angular and velocity of each links center of gravity with

respect to the inertial frame. Once the kinetic and potential energy terms are derived, we simply use

the Matlab jacobian() command to symbolically calculate the mass matrix and nonlinear dynamic

des

Controller

(

)

t–Ts

(t) = ∫ F(

)

(

–

)

FIGURE 21.11 General simulation block diagram.

Robot Simulation 21

-15

terms following the Lagrange formulation. Symbolic packages such as Maple and Mathmatica do all the

rest.

First, the position of the center of mass for each link, with respect to the system’s inertial coordinate

system, is computed by iteratively postmultiplying each of the homogeneous transforms, starting from

the base and working to the tip of the robot.

base

= H

i−1

base

i−1



i−1

base

i−1

base



i−1





base



base











base











(21.3)

The potential energy due to gravity for link i is the vertical component (z

base

in direction of gravity) of

base

times the mass of the link.

= m

base

(21.4)

To compute the kinetic energy, we must ﬁrst derive expressions for the linear and angular velocity of the

center of gravity for each link as a function of the states of the manipulator. We have an expression,

base

in Equation (21.3), for the position of the center of gravity of link i with respect to the base inertial frame.

The velocity vector

is computed by multiplying the Jacobian (with respect to the combined states of the

manipulator

base

)of

base

, J (

base

q), by the state velocity vector,

q. Note from Equation (21.5), based

on the chain rule, that

base

is a vector of robot joint displacements from the base of the robot (joint q

)

to the ith joint (q

∂

∂t



j=1

∂

∂q

(21.5)

= J (

q where

q = [q

...q

]

The rotational velocity is a little more involved but can be simpliﬁed by again using the homogeneous

transform. Starting at the base of the robot, project the net rotational velocity vector forward to the center

of mass of each link using the rotational matrix R

base

. Each subsequent joint consists of projecting the total

angular velocity vector of the previous joint to the current joint’s coordinate system, using the rotational

component of that joint’s homogenous transform, and adding the joint angular velocity.

+ R

i−1

(21.6)

We now have expressions for the linear and angular velocity of the center of mass for each link. The

total kinetic energy of the system is

T =



i=1

+ R

base

]

(21.7)

where m

is the mass of link i and I

is the inertia matrix of link i about the center of gravity. As a ﬁnal

step, we add external forces applied to the system. For now, we assume forces are applied only to the joints

-16 Robotics and Automation Handbook

and tip of the robot. We use the principle of virtual work to lump these terms together.

∂W =



i=1

∂q

tip

∂

tip

∂θ

tip



τ + J

tip

(



tip



∂

Q∂

(21.8)

tip

(

q) =

∂

tip

base

∂

Equation (21.4) and Equation (21.7) provide expressions for the kinetic and potential energy of the

system. We start with the classic deﬁnition of the Lagrange equations of motion.

∂

∂t



∂T

∂



−

∂T

∂q

∂V

∂q

(21.9)

The ﬁrst term in Equation (21.9) can be expanded using the chain rule.

∂

∂t

∂

∂t

∂

∂t

(21.10)

Substituting Equation (21.10) into Equation (21.9),

∂



∂T

∂



q +

∂



∂T

∂



q −

∂T

∂

∂V

∂

(21.11)

As with the velocity computation in Equation (21.5), we can exploit the jacobian() function in

Matlab for the evaluation of many of the terms in Equation (21.11). First, the term ∂ T/∂

q is the differential

of the scalar kinetic energy term with respect to the full state velocity vectordeﬁned in Equation (21.5). This

results in the vector, L

, in the script ﬁles shown below. The ﬁrst term in Equation (21.11) represents the

mass matrix. This expression is easily computed by taking the Jacobian on L

with respect to the full state

velocity vector. The remaining elements in Equation (21.11) represent the nonlinear dynamics (coriolis,

centripetal, gravitational) of the system. Thus, it should be clear that once the kinetic and potential energy

terms are deﬁned, it is straightforward to symbolically evaluate the dynamic equations. The Jacobian for

projecting external forces to the generalized coordinates can similarly be computed using the tip position

of the robot and the Matlab jacobian() function.

This basic methodology was developed to compute the dynamics of a class of robots operating on

the deck of a ship (a moving platform). We provide two examples to verify this methodology: a simple

one-degree-of-freedom (dof) system operating on a three-dof moving platform and a three-dof system

experiencing all six degrees of motion from the sea state. The ﬁrst example is simple enough to verify

through hand calculations. The second example is more complex, yet practical. Figure 21.12 shows the

basic kinematic model of the one degree of freedom system experiencing three sea states in the X-Y plane.

We are assuming a one-dof system with mass M and rotary inertia I

located at the tip of a link of length L.

The system is experiencing only three of the six sea states: surge (x

), heave (y

), and pitch (θ

). The only

external force applied to the system is a joint torque τ , applied at joint 1. Appendix A shows the listing of

Matlab code used to generate the dynamic equations of motion. The two output variables of interest are

the MassMatrix and NLT (nonlinear terms). The resulting output is listed in Equation (21.12) and can be

Robot Simulation 21

-17

M, I

FIGURE 21.12 One DOF model.

easily veriﬁed by the reader. Clearly, for this simple case, there is not a great advantage to using a symbolic

package over hand calculations.

MassMatrix = ML1

+ I

NLT = ML1

+ I

+ ML1 cos(θ

+ θ

)

− ML1 sin(θ

+ θ

)

+MgL1 cos(θ

+ θ

)

combining

(21.12)

(ML1

+ I

)(

) +ML1 cos(θ

+ θ

)

− ML1 sin(θ

+ θ

)

+MgL1 cos(θ

+ θ

) = τ

The power of this approach is more evident as we progress to more complex systems. First, all that is

required is the deﬁnition of joint transformations. All of the differentiation for velocity and acceleration

terms is handled by the symbolic computational package (such as Maple or Mathematica). As a second

example, we derive the dynamic equations of motion for the three-dof system, shown in Figure 21.12,

with the full six-dof from the sea state. A listing of the Matlab code used for computing the dynamics of

this system on the deck of a ship is shown in Appendix B. It should be clear comparing the listings in

Appendix A and Appendix B that there is only a slight difference in the formulation of the transformations,

but the methodology for deriving the dynamics is the same. The resulting equations of motion can be

partitioned into a compact form, Equation (21.13),









NLT









ext



(21.13)

where M

is the 3×3 mass matrix for the robot with respect to the robot’s state acceleration, M

is the 6×6

mass matrix of the robot with respect to the sea state acceleration, M

is the inertial coupling of the sea

state to the robot state, NLT

is a 3 ×1 vector of the nonlinear terms (gravitational, Coriolis, centripetal)

as a function of both the robot’s state and the sea state, Q

is the joint force input vector to the system, F

ext

is an external force vector applied to the end effector, and J

) is the Jacobian from the end effector to

the joint space. In order to include the dynamic equations of motion in Simulink, we use Equation (21.14)

to solve for the acceleration of the robot’s state vector as a function of all of the inputs (external forces and

joint torques), system state (position and velocity), and external disturbances (sea state position, velocity,

-18 Robotics and Automation Handbook

FIGURE 21.13 Force controlled hydraulic manipulator (courtesy Oak Ridge National Laboratory).

and acceleration). This expression is in the same form as Equation (21.1).

= M

−1

{

+ J

(

)

ext

− NLT

− M

} (21.14)

While the output of the single degree of freedom case can be listed in Equation (21.12), the results of

the dynamic equations of motion for the second system generates 84 pages of C code and would require

considerable effort to derive by hand. Fortunately, the code can be directly imported into Simulink through

the S-Function builder. The motivation for computing the dynamics equations of motion are threefold.

First, by having the dynamics in a symbolic form, it is possible to aid in the design process, changing

parameters to optimize the system. Second, a model of the system dynamics can aid in increasing the

ﬁdelity of simulation for control design and analysis. Finally, there is no doubt about how the simulation

derived the system’s equations of motion.

The system modeled in this investigation is displayed in Figure 21.13. This system has a 500-lb payload

capacity and has threeactivedegrees of freedom.The actuator models include nonlinear dynamic modeling

of the hydraulic system (servo-valve oriﬁce equations, asymetric cylinders, ﬂuid compliance ...),controls,

and the dynamic equations of motion computed above.

The hydraulic actuator models generate force as a function of the servovalve current, actuator position,

and velocity. The Simulink model of the full system, including the sea state inputs, hydraulic models,

controls, and dynamic equations of motion, is shown in Figure 21.14.

-c-

k- ku

-c-

Sine Wave

Sine Wave1

Sine Wave2

×1

Human Hand

Position

−−

Human

Stiffness

In1

Out1

In1

Out1

Subsystem

Subsystem 3

Subsystem 2

Subsystem1

Human

Force

To Workspace

alfa

accomodation

calo LDRD Joint Velocity

MATLAB

Function

MATLAB

Function

MATLAB

Function

Des Tip

Position

Des Joint

Position

Joint

States

Joint

States

TipForce

Tip Force

Tip

Position

Tip

Position

switch 3

switch1

switch

[time,sea_state]

Sea State

Out 1

Comp Force

Comp Sea Force1

Tip Pos.

Env. Force

atrix

Sea State

Ext Tip

Force

ID_

command

Actuator

Force

LDRD Arm

–

FIGURE 21.14 HAT simulation model (courtesy Oak Ridge National Laboratory).

Robot Simulation 21

-19

Step

ID_command

Des Joint

Position

External Forces

applied to tip of robot

Ext Tip Force

Sea State

Double click

here for

information on

this demonstration

−

Out1

Joint Controllers

Gc 1

Gc 2

Gc 3

Hydraulics

xv1

xv2

xv3

q1&

q1_d

x2&

x2_d

x3&

x3_d

Gain 2

Actuator

Force

S-function that

has full nonlinear

equations of motion

Torques States

Ext Forces

Tip

Force

Tip Force

Sea State

Subsystem

Joint

States

theta_to_L

S-Function

Builder 1

S-Function

Builder

Jt1 Angle

Jt2 Angle

Jt3 Angle

xv4

Tip Position

MATLAB

Function

FIGURE 21.15 Details of HAT controller and manipulator model.

The nonlinear model of the hydraulic manipulator, shown as the LDRD arm block in Figure 21.14,

is expanded in Figure 21.15. The inputs to the model include the desired joint positions, the eighteen

elements of the sea state (displacement, velocity, and acceleration of roll, pitch, yaw, heave, surge, and

sway), and the external force applied to the robot. In addition, this model includes auxiliary inputs for

system identiﬁcation.

There are two primary blocks to note in Figure 21.15. The ﬁrst is the system dynamics block. This

contains the C code generated previously that represents the forward dynamics of the LDRD arm. The

second is the hydraulics block. From the expanded hydraulics block, each of the three joints has two

primary elements: the servo valve and the actuator. In the case of the second and third joints, there is

also a transmission associated with the coupling of the linear actuator with the joint (the two “theta

to L”

blocks in the upper right). The servo valve models are based on the full nonlinear oriﬁce equations and

regulate the ﬂuid ﬂow to the actuators as a function of excitation signal (command to the moving coil

on the servo vavle), the supply, and return pressure, as well as the pressure on both sides of the actua-

tor. The actuator model generates a force based on the position, velocity, and bulk modulus (stiffness)

of the ﬂuid. The position and velocity of the actuator come from the dynamic model of the manipu-

lator. The force from the actuator is the excitation to the dynamic model of the manipulator. It should

now be clear that the full nonlinear behavior of the manipulator is embodied in the simulation of the

manipulator.

To complete our example, we now consider the impact sea state has on the performance of a force

controlled system. Inputs to the system consist of a human command regulating about a single point and

a sea state with conditions commensurate with a destroyer moving at 20 knots in sea state 5. Figure 21.16

shows the force provided by the human while attempting to regulate the tip position. There is the expected

DC bias on the Z-direction force required to offset the gravitational load. The system is used for strength

ampliﬁcation. The human only senses a fraction of the total payload weight. For this example, the payload

weight is 2224 N which projects to a human force of 22.4 N when in static equilibrium with a 100:1

force ampliﬁcation ratio. However, during the 120 sec simulation run, the maximum perturbation felt by