This content is specific to Simscape™ Multibody™ First Generation software. First-generation features are slated to be deprecated and should be avoided.

The Simscape Multibody Constraints & Drivers library provides a set of blocks to model constraints on the relative motions of two bodies. You model the constraint by connecting the appropriate Constraint or Driver block between the two bodies. As with joints, the blocks each have a base and follower connector port, with the body connected to the follower port viewed as moving relative to the body connected to the base port. For example, the following model constrains Body2 to move along a track that is parallel to the track of Body1.

Constraint and Driver blocks enable you to model time-independent
**constraints** or time-dependent **drivers**.

Constraint and unactuated Driver blocks model

*scleronomic*(time-independent) constraints.Actuated Driver blocks (see Actuating a Driver) model

*rheonomic*(time-dependent) constraints.

Scleronomic constraints lack explicit time dependence; that
is, their time dependence appears only implicitly through the coordinates ** x**. Rheonomic constraints have explicit time
dependence as well, in addition to implicit time dependence through
the

*Holonomic* constraint functions depend only
on body positions, not velocities:

$$f({x}_{B},{x}_{F};t)=0$$

Constraints of the form

$$g({x}_{B},{\dot{x}}_{B},{x}_{F},{\dot{x}}_{F};t)=0$$

can sometimes be integrated into a form dependent only on positions;
but if not, they are *nonholonomic*. For example,

The one-dimensional rolling of a wheel of radius

*R*along a line (the*x*-axis) imposes a holonomic constraint,*x*=*R*θ.The two-dimensional rolling of a sphere of radius

*R*on a plane (the*xy*-plane) imposes a nonholonomic constraint, d*s*=*R*·dθ, with d*s*^{2}= d*x*^{2}+ d*y*^{2}. This constraint is nonholonomic because there is not enough information to solve the constraint independently of the dynamics.

Constrained and driven bodies are still free to respond to externally imposed forces/torques, but only in a way consistent with the constraints.

Constraints and drivers can only remove **degrees of freedom** from a machine.
Constraints and unactuated Drivers prevent the machine from moving
in certain ways. Unactuated Drivers hold the constrained degrees of
freedom between the connected pair of bodies in their initial state.
Actuated Drivers externally impose a relative motion between pairs
of bodies, starting with the bodies' initial state. See Counting Model Degrees of Freedom.

This section discusses modeling constraints and drivers in a general way.

The section ends with two examples, Constraint Example: Gear Constraint and Driver Example: Angle Driver.

See the reference pages for information on the specific constraint that a Constraint or Driver block imposes.

Like joints, constraints and drivers have **directionality**. The sequence of base
to follower body determines the directionality of the constraint or
driver. The directionality determines how the sign of Driver Actuator
signals affects the motion of the follower relative to the base and
the sign of signals output by constraint and driver sensors.

A Simscape Multibody simulation uses a constraint solver to find the motion, given the model's Constraint and Driver blocks. You can specify both the constraint solver type and the constraint tolerances used to find the constraint solution. See Maintaining Constraints for more information.

Some constraints, whether time-independent (Constraints) or time-dependent (Drivers), can become singular when the constrained bodies take on certain relative configurations; for example, if the two body axes line up when the Bodies are connected by an Angle Driver. The simulation slows down as a constraint becomes singular.

If you find a constrained model running slowly, consider selecting
the **Use robust singularity handling** option
in the **Constraints** tab of your machine's
Machine Environment block dialog. See Handling Motion Singularities.

The following restrictions apply to the use of Constraint and Driver blocks in a model:

Constraint and Driver blocks can appear only in closed loops. A closed loop cannot contain more than one Constraint or Driver block.

A Constraint or Driver must connect exactly two Bodies.

The `mech_gears`

model
illustrates the Gear Constraint. Open the Body and Gear Constraint
blocks.

Body1 and Body2 have their CG positions 2 meters apart. CS1
and CS2 on Body1 are **collocated** with
the Body1 CG, and similarly, CS1 and CS2 on Body2 are collocated with
the Body2 CG.

The Gear Constraint between them has two pitch circles. One is centered on the CS2 at the base Body, which is Body1, and has radius 1.5 meters. The other is centered on CS1 at the follower Body, which is Body2, and has radius 0.5 meters. The distance between CS2 on Body1 and CS1 on Body2 is 2 meters. The sum of the pitch circle radii equals this distance, as it must.

When you run a simulation, the 3-D visualization window opens automatically, displaying your multibody model as a system of convex hulls. Start the simulation and watch the CG CS axis triads spin around. The CG triad at Body2 rotates three times faster than the CG triad at Body1, because the pitch circle centered on Body2 is three times smaller.

You can see the same behavior in the Scope. The upper plot shows
the motion of Revolute2, and the lower plot the motion of Revolute1.
Note that angular motion is mapped to the interval (-180^{o},
+180^{o}) degrees.

The Gear Constraint is inside a closed loop formed by

Ground_1–Revolute1–Body1–Gear Constraint–Body–Revolute2–Ground_2

Although Ground_1 and Ground_2 are distinct blocks, they represent different points on the same immobile ground at rest in World. So the blocks form a loop.

The following two models illustrate the Angle Driver, both without and with a Driver Actuator.

The first is `mech_angle_unact`

.
Open the Body2 block.

The bodies form a double pendulum of two rods. The Body Sensor is connected to Body2 at CS3 = CS2 and measures all three components of Body2's angular velocity vector with respect to the ground.

The Angle Driver is connected between Body2 and Ground_2. Because the Angle Driver is not actuated in this model, it acts during the simulation as a time-independent constraint to hold the angle between Body2 and Ground_2 constant at its initial value.

When you run a simulation, the 3-D visualization window opens up, displaying your model as a system of convex hulls.

Start the simulation. The upper body swings like a pendulum, but the lower body maintains its horizontal orientation with respect to the horizontal ground. The Scope measures Body2's angular velocity with respect to ground, and this remains at zero.

The second model is `mech_angle_act`

.
Open the Driver Actuator block.

The Driver Actuator drives the Angle Driver block. Here, the
Actuator accepts a constant angular velocity signal from the Simulink^{®} blocks.
The Actuator also requires the angle itself and the angular acceleration,
together with the angular velocity, in a vector signal format. The
Angle Driver's angle signal is added to the angle's initial value.

The Body Sensor again measures three components of Body2's angular
velocity with respect to the ground. Constant1 drives the angle at
15^{o}/second. While the simulation is running,
this angle changes at the constant rate. At the same time, the assembly
and the constant length of the two pendulum rods must be maintained
by Simulink, while both rods are subject to gravity. As the two
axes line up, the mutual constraint between the bodies enforced the
Driver becomes singular. The simulation slows down.

As in the Gear Constraint model, the two Ground blocks in these models represent points on the same immobile ground at rest in World, so the Angle Driver is part of a closed loop.

Was this topic helpful?