Note: This page has been translated by MathWorks. Please click here

To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

This section explains the essential details of modeling the Stewart platform in the Simscape™ Multibody™ environment. To understand the section better, use any top-level model from the case studies, except the models of Trimming and Linearizing Through Inverse Dynamics. These are different because they lack a controller subsystem and consist of a plant model alone.

The control design model, `mech_stewart_control`

,
is this section's example.

In three of the case studies, a larger control system model contains a Plant subsystem that incorporates the platform.

The Plant subsystem models the Stewart platform's moving parts, the legs and top plate. Open this subsystem.

**Stewart Platform Model (Control Design Version)**

Each of the legs is an instance of a library block located in
another library model,` mech_stewartplatform_leg`

or `mech_stewart_control_equil_leg`

.

Select one of the leg subsystems and right-click. Select

**Link Options**, then**Go To Library Block**, to open this library.Open the masked library block, Leg Subsystem, and the individual Body and Joint blocks that make up a whole leg.

Now close the blocks, subsystems, and linked libraries and return to the top-level model.

Except in the Trimming and Linearizing Through Inverse Dynamics study,
the Stewart platform models contain controllers imposing actuating
forces that guide the platform's motion to follow as closely as possible
a *nominal* or *reference* trajectory.
Implementing a controller requires computing the motion errors, the
difference of the reference and actual motions of the platform. All
the case study models use proportional-integral-derivative (PID) control.

Each model controller requires a reference trajectory.

Open the Leg Reference Trajectory subsystem.

This set of blocks generates the set of six leg lengths, as functions of time, corresponding to a desired trajectory for the top plate.

Open the subsystem called Top Plate Reference. This set of blocks generates a reference trajectory in terms of linear position and three orientation angles, as a function of time. The workspace variable

`freq`

sets the frequency of the reference motion.**Stewart Platform Reference Trajectory Subsystem (Control Design Version)**The reference trajectory provided uses sinusoidal functions of time to define the rotational and translational degrees of freedom.

If you want, you can design and implement another reference trajectory of your choosing and replace this sub-subsystem.

Whatever comes out of Top Plate Reference, the subsystem Leg Reference Trajectory assumes the translational position/three-angle form for the top plate. The rest of the Leg Reference Trajectory subsystem transforms these six degrees of freedom (DoFs) into the equivalent set of six DoFs expressed as the lengths of the six platform legs. The reference trajectory output of the subsystem is a six-vector of these leg lengths.

The actuating force on leg * r* is a function
of the motion error. The error requires finding the instantaneous
length of each leg from the positions of that leg's top and bottom
connection points.

**Defining the Length of a Stewart Platform
Leg**

The motion error is the difference of the desired or reference length of the leg and its instantaneous or actual length:

$$\begin{array}{l}\text{Error}={E}_{r}=\text{referencelengthofleg}-\text{actuallengthofleg}\\ ={L}_{\text{traj,}r}(t)-|(R\cdot {p}_{\text{t,}r})-{p}_{\text{b,}r}|\end{array}$$

The reference length *L*_{traj}(* t*)
is given as a function of time by the output of the Leg Reference
Trajectory subsystem. The vectors

All the Stewart platform models use a simple PID controller and Joint Sensor blocks to measure motion. The simplest implementation of trajectory control is to apply forces to the plant proportional to the motion error. PID feedback is a common form of linear control.

A PID control law is a linear combination of a variable detected
by a sensor, its time integral, and its first derivative. This Stewart
platform's PID controller uses the leg position errors *E*_{r} and their integrals and velocities. The
control law for each leg * r* has the form:

$${\text{F}}_{\text{act,}r}\text{}=\text{}{K}_{p}{\text{E}}_{r}\text{}+\text{}{K}_{i}{\displaystyle {\int}_{\text{0}}^{\text{t}}{\text{E}}_{r}\text{}dt}+\text{}{K}_{d}(d{\text{E}}_{r}/dt)$$

The controller applies the actuating force *F*_{act,}_{r} along the leg.

If

*E*_{r}is positive, the leg is too short, and*F*_{act,}_{r}is positive (expansive).If

*E*_{r}is negative, the leg is too long, and*F*_{act,}_{r}is negative (compressive).If

*E*_{r}is zero, the leg has exactly the desired length, and*F*_{act,}_{r}is zero.

The real, nonnegative *K*_{p}, *K*_{i},
and *K*_{d} are, respectively,
the proportional, integral, and derivative gains that modulate the
feedback sensor signals in the control law:

The first term is proportional to the instantaneous leg position error, or deviation from reference.

The second term is proportional to the integral of the leg position error.

The third term is proportional to the derivative of the leg position error.

The result is *F*_{act,}_{r}, the actuator force (input) applied by
the controller to the legs. The proportional, integral, and derivative
terms tend to make the legs' top attachment points *p*_{t,}_{r} follow the reference trajectories by suppressing
the motion error.

The case study, About Controllers and Plants, discusses controlling platform motion in greater detail. In that study, you also use an H-infinity controller, as well as use transfer functions to take motion derivatives.

In addition, consult References.

When representing the physical components of the Stewart platform
model with Simscape Multibody blocks and the control components with Simulink^{®} blocks,
you must define the geometry of its initial state and the mass parameters
of the Stewart platform bodies. Although each case study uses a variant
model, all initialize the platform and controller configuration in
a common way.

Geometric, mass, dynamical, and controller information is specified
in the block dialogs by referencing variables in your MATLAB^{®} workspace.
A script accompanies the Stewart platform models and sets these values.

Running this script configures the blocks in their starting geometric state, with the correct mass properties for the bodies. When you open it, each model uses the same initialization script as a pre-load function. To see this setting,

Go to the

**File**menu and select**Model Properties**.Then in the dialog, select the

**Callbacks**tab and find the**Model pre-load function**field.

**Stewart Platform Initialization Files**

File | Purpose |
---|---|

`mech_stewart_studies_setup` | Script to fill the workspace with geometric, dynamical, and controller data. |

`inertiaCylinder` | Function called by `mech_stewart_studies_setup` .
Computes the principal inertias of a solid cylinder. |

The script first defines basic angular unit conversions and axes. The World coordinate system (CS) is located at the center of the immobile base plate. The connection points on the base and top plate are defined with respect to World. These definitions include the offset angle of 60 degrees between the base and top plates, the radii of both the base and top plates, the initial position height of the top plate, and the vectors pointing along the legs. The array of top points is permuted so that the same index represents the top and bottom connection points for the same leg.

The script calculates the revolute and cylindrical axes used in the joint blocks of the leg subsystems. There are two revolute axes for each Universal joint that connects an upper leg to the top plate, one cylindrical and one revolute axis for the linear motion of the Cylindrical joint connecting upper and lower legs, and two revolute axes for each Universal block that connects a lower leg to the base plate. The script then configures all 13 moving bodies by defining coordinate systems at the center of gravity (CG) of each.

The top plate's home configuration is symmetric
equilibrium: flat, with equal leg lengths specified by the workspace
vector `leg_length`

.

The script defines the mass properties of all bodies. These
comprise the inertia
tensors and masses for
the top plate, the bottom plate, and the legs. The mass properties
calculation assumes that the platform is made with steel. The script
calls the function `inertiaCylinder`

to calculate
the inertia tensors and masses of the legs and the top and base plates,
given the material density, the length and inner and outer radii of
the leg cylinders, and the thicknesses and radii of the top and base
plates.

In its final steps, the script defines motion and control constants as workspace variables: motion frequency, derivative filtering cutoff, leg actuator force saturation, and controller gains. Each case study model uses some or all of these constants, which you can change as desired.

Real force actuators are saturate at a specific force level.
The Force Saturation block limits the actuating force to the value
of the workspace variable `force_act_max`

.

The integral (I) part of the PID controller exhibits an extended
response time whose overall effect is controlled by the ratio of *K*_{i} to *K*_{p}.
The Integrator for the I part has a nonzero **Initial
condition** field, specified by the workspace variable `initCondI`

,
adjustable to compensate for initial transient behavior. The script
initializes its value to

(upper_leg_mass+lower_leg_mass+(top_mass*1.3/6))*9.81/Ki

corresponding to the leg forces in symmetric equilibrium.

**Motion and Filtering Constants**

Dynamical Feature | Workspace Variable | Associated Natural Frequency | Associated Time Scale |
---|---|---|---|

Top plate motion | `freq` = π rad/s | `freq` /2π = 0.5 Hz | 2π/`freq` = 2 s |

Filtered derivative cutoff | `A` = 100*`freq` = 100π
rad/s | `A` /2π = 50 Hz | 2π/`A` = 0.02 s |

**PID Controller Constants**

Dynamical Constant | Workspace Variable |
---|---|

Force saturation | `force_act_max` = 3e5 newtons (N) |

Integral (I) gain | `Ki` = 1e4 (newtons/meter/second) (N/m-s) |

Proportional (P) gain | `Kp` = 2e6 newtons/meter (N/m) |

Derivative (D) gain | `Kd` = 4.5e4 newtons-seconds/meter (N-s/m) |

For the purposes of Simscape Multibody motion analysis, you need to know the model's Simulink and mechanical states. These are distinct from the system's degrees of freedom (DoFs) and depend on the analysis mode you choose.

If you use a controller or other subsystem made up of pure Simulink blocks with your Stewart platform, your model might contain Simulink states. For example, Integrator and Transfer Fcn blocks each have an associated state, and State-Space blocks can have many.

The default Stewart platform controller is a PID subsystem, which integrates six feedback signals and thus has six Simulink states. In the Analyzing Controllers and Designing and Improving Controllers studies, you can also choose to use the filtered derivative, which has 12 transfer functions and thus adds 12 Simulink states.

A mechanical system modeled with Joint blocks contains mechanical states distinct from Simulink states that include both joint position and velocity. In Forward Dynamics mode, the Stewart platform contains 52 tree states, of which 12 are independent.

The joints and their related DoFs are discussed in Counting Degrees of Freedom in the Stewart Platform.

**Joint Primitives and States. **Each Joint consists of one or more primitives. The position
and velocity of a joint primitive each have a state. The Stewart platform
has 36 joint primitives and thus potentially 72 states.

**Cutting Joints and Obtaining the Tree States. **Because the Stewart platform has closed topology, Simscape Multibody model
will cut five of the Joints to arrive at an equivalent open-topology
or tree machine. These Joints are replaced internally by equivalent
cutting constraints.

Five Universals and 5*2*2 = 20 joint primitives are eliminated this way. The equivalent open machine thus has 72 - 20 = 52 tree states.

**Counting the Cutting Constraints. **Not all these states are independent. There are 40 equivalent
constraints that replace the cut Joints.

Each cut Universal imposes one rotational and three position constraints.

Each constraint also constrains the corresponding velocity.

There are five cut Joints.

Thus there are 5*2*4 = 40 invisible constraints generated by the cutting.

**Finding the Independent States. **Thus the Stewart platform model has 52 - 40 = 12 independent
mechanical states, corresponding to the six independent DoFs and their
velocities.

You can also analyze the Stewart platform's motion in inverse dynamics and locate steady-state operating points.

Because the Stewart platform is a closed-loop machine, you must simulate its inverse dynamics in the Kinematics mode.

You can find operating points in the Trimming mode with the Simulink

`trim`

command.

In both the inverse dynamics and trimming cases, the Simulink states
associated with the Simscape Multibody joint primitives are *not* the
DoFs, but the *(invisible) joint-cutting constraints* that
reduce the tree states to independent states. The state values measure
how well the constraints are satisfied. A zero value means a constraint
is satisfied perfectly.

In the mechanical part of the Stewart platform model, there are 52 tree states and 12 independent states. Thus the Simscape Multibody model counts 52 - 12 = 40 cutting constraints. In the Kinematics and Trimming modes, these 40 constraints are the mechanical states.

**Open Topology and Inverse Dynamics Mode. **If the Stewart platform had an open topology, you would simulate
its inverse dynamics in Inverse Dynamics mode instead. However, there
would be no closed loops, and the simulation would not cut any Joints.
With no cutting constraints, an open topology machine has no states
in Inverse Dynamics or Trimming mode.

For more information about states and loops, review the following sections:

You can also review the command reference documentation for `mech_stateVectorMgr`

.

For more information about analysis modes, see Simulating and Analyzing Mechanical Motion.

With the Simscape Multibody visualization window open, you can
view the platform motion from different perspectives. View the platform
in the * xy*-plane, from above. Then switch the view
to the

The initial state of motion specified by the reference trajectory is slightly different from the home configuration and generates an initial transient.

Was this topic helpful?