Advanced Rotational Components¶

Modeling Backlash¶

Let’s start our exploration of more advanced component models by looking at a rotational backlash element. The equation for a backlash model is very simple:

In Modelica (where is phi_rel), this component can be described as follows:

within ModelicaByExample.Components.Rotational.Components;
model Backlash "A rotational backlash model"
  parameter Modelica.SIunits.RotationalSpringConstant c "Torsional stiffness";
  parameter Modelica.SIunits.Angle b(final min=0) "Total lash";
  extends ModelicaByExample.Components.Rotational.Interfaces.Compliant;
equation
  if phi_rel>b/2 then
    tau = c*(phi_rel-b/2);
  elseif phi_rel<-b/2 then
    tau = c*(phi_rel+b/2);
  else
    tau = 0 "In the lash region";
  end if;
end Backlash;

We can add an instance of this backlash model into our previous model by placing it in parallel with the spring and the damper, i.e.,

If we use the inheritance mechanism in Modelica, the resulting Modelica model is quite simple:

within ModelicaByExample.Components.Rotational.Examples;
model SMD_WithBacklash "The spring-mass-damper system with backlash"
  extends SMD(inertia2(phi(fixed=true, start=0)), inertia1(phi(fixed=true, start=0), w(start=5)));
  Components.Backlash backlash(c=1000, b(displayUnit="rad") = 0.5)
    annotation ...
equation
  connect(inertia1.flange_b, backlash.flange_a) annotation ...
  connect(backlash.flange_b, inertia2.flange_a) annotation ...
end SMD_WithBacklash;

In this case, if the relative angle between inertia1 and inertia2 is more than 0.5 radians (i.e., the value of b in our backlash instance), then the torque from the backlash element will be introduced.

If we simulate this model, we can see the impact that the backlash’s presence has on the response of the system:

Another thing worth looking at (which we will delve into much more in the next topic) is the force felt by the mechanical ground element. Looking at our schematic, it is clear that the role of the mechanical ground element is to fix the angular position on one side of our system. An equation to constrain the motion (or lack of motion, in this case) of a point in the system is called a kinematic constraint.

When a kinematic constraint is imposed on a system, the component imposing the constraint must generate some kind of force or torque in order to affect the motion of the system. This is called a reaction force or reaction torque.

The following plot shows the reaction torque that the mechanical ground element must impose on the system in order to fix the angular position:

Grounding and Reaction Torques¶

As we saw in the previous example, the behavior of the mechanical ground element is such that it must exert a reaction torque on the system to constrain the motion of the system. In this section, we will examine this effect a bit closer.

To demonstrate some of the complexities of kinematic constraints, we need to create a mechanical gear model. In this model, we will ignore the inertia of the gear elements, efficiency losses in the gear and any backlash that might exist between the teeth in the gear. Recall our discussion about Digging Deeper earlier in this chapter where we mentioned that component models should focus on individual physical effects. That same principle applies here. Inertia, friction and backlash can all be modeled as individual effects (as we’ve already seen in this chapter). There is no need to lump them into our gear model. Instead, we will focus only on the relationship between gear input speed and output speed.

In a typical system dynamics class, the equations that describe the behavior of a gear are derived as follows. First, we start with the understanding that a gear introduces a relationship between the input speed and the output speed, i.e.,

where is the gear ratio. Recall that we assume the gear to be perfectly efficient. This means that the power going into the gear must equal the power going out which we can express mathematically as:

Note we are using the Modelica sign conventions here where a positive value for the flow of a conserved quantity means a flow into the component. In this case, is the flow of mechanical power into the gear from flange_a and is the flow of mechanical power into the gear from flange_b. Therefore, their sum must be zero, since our gear model does not include the inertia of the gear elements and, therefore, no way to store energy or momentum within the gear model.

Given these two facts, we can substitute the relationship between the speeds into the relationship between the powers and get:

This allows us to cancel out from the equation and rearranging terms gives us:

Such a derivation will probably look very familiar to most engineers. But it is important to recognize that there is something missing here. More specifically, there is something implicitly assumed that is not necessarily a reasonable assumption.

To understand the issue, let’s first consider Euler’s second law:

In other words, the sum of the torques on a body should be equal to the amount of angular momentum being accumulated by the body. Recall that our gear model doesn’t include the inertia of the gear elements. As such, it has no capacity to store energy or angular momentum. If that is the case the previous equation simplifies to:

Our gear has only two external torques, and . Using the relationships we derived earlier, we know that their sum is:

This equation implies that for any gear ratio, , not equal to 1.0, the torque at flange_a (and consequently, the torque at flange_b as well) must be zero. But this cannot be correct if our gear is to function as a gear.

What this mathematical relationship is showing us about the physical behavior of the system is more clearly demonstrated in this relationship:

The first term, is the torque entering the gear from flange_a. The second term, is the torque entering the gear from flange_b. This equation tells us that these two torques will never sum to zero (for ). It appears that we have proven, mathematically, that . But in fact, what we are really demonstrating is that there is an imbalance in the equation. This imbalance is the result of having forgotten something in our formulation. What is missing is the reaction torque.

If you aren’t already familiar with this issue, you might be puzzled about where this reaction torque comes from. After all, we have only two mechanical connections to this gear and we have expressions for the torque at both of these points. But along the way, there was an implicit assumption that the housing of the gear is grounded. In reality, a gear has three mechanical connections. The third connection is the one between the housing of the gear and whatever the gear is mounted to. If the housing is connected to a mechanical ground, then our equations so far are correct as we can capture the behavior of such a (grounded) gear as follows:

within ModelicaByExample.Components.Rotational.Components;
model GroundedGear "An ideal non-reversing gear with grounded housing"
  parameter Real ratio "Ratio of phi_a/phi_b";
  extends Interfaces.TwoFlange;
equation
  ratio*flange_a.tau + flange_b.tau = 0 "No storage";
  flange_a.phi = ratio*flange_b.phi "Kinematic constraint";
  annotation ...
end GroundedGear;

Note that instead of using the relationship in the GroundedGear model, we instead used the relationship . This is actually more accurate since, once assembled, the teeth of the gear really do constrain the angular positions of the two shafts. Furthermore, there may be some applications (e.g. stepper motors) where preserving this relationship between positions, and not just velocities, could be very important.

Using the GroundedGear model, we can then build a system model using this gear as follows:

Note this system has two parallel mechanisms. The first one uses the gear model we just developed. The second one replaces the assembly of the gear and inertias with a single inertia. This single inertia was specifically chosen to have the “effective inertia” of the assembly. As a result, when we simulate this system, we see that inertia2 and inertia3 have the same response:

Comparison¶

As previously mentioned, the issue with the GroundedGear model is that it is implicitly assumed to be grounded. This assumption may not always be a reasonable one (e.g., in an automotive transmission where gears are generally connected to compliant mounts). To understand how much different the response of a system can be between grounded and ungrounded gears we will first create a more complete gear model that is not implicitly grounded and then compare its performance, side by side, with gears that are grounded.

Without the implicit assumption that the housing of the gear is grounded, the kinematic relationship between the two shafts and the housing is more completely expressed as:

Although it is beyond the scope of this discussion, we can derive the following two equations using conservation of energy and conservation of momentum:

Combining these relationships and adding an additional mechanical connector to represent the housing, we get the following Modelica model for an ideal gear:

within ModelicaByExample.Components.Rotational.Components;
model UngroundedGear "An ideal non-reversing gear with a free housing"
  parameter Real ratio "Ratio of phi_a/phi_b";
  extends Interfaces.TwoFlange;
  Modelica.Mechanics.Rotational.Interfaces.Flange_b housing
    "Connection for housing"
    annotation ...
equation
  (1-ratio)*housing.phi = flange_a.phi - ratio*flange_b.phi;
  flange_b.tau = -ratio*flange_a.tau;
  housing.tau = -(1-ratio)*flange_a.tau;
end UngroundedGear;

Now, let us build a system model with three different mechanisms. In each mechanism the parameters for the gear, inertia, spring and damper are all identical. The only difference is whether we use an implicit grounded gear, an explicitly grounded gear or a gear that is not directly connected to ground, but is instead connected through a very stiff mounting system. The schematic for our system looks like this when rendered:

The first thing we would expect is that the response of the mechanism with the implicitly grounded gear should be identical to the response of the mechanism with the explicitly grounded gear. This is verified by the following plot:

But the question still remains, how much difference would it make if we assumed that a gear was implicitly grounded when, in fact, it wasn’t? This is clearly demonstrated in the following plot:

Optional Ground Connector¶

So far in our discussion of rotational systems, we’ve created two different gear models, GroundedGear, which is implicitly grounded, and UngroundedGear, which includes a mechanical connector for the housing. Ultimately, the equations used by these two components are quite similar and there is a considerable amount of common code between them. As we’ve talked about before, redundancy like this should be avoided.

One way that we can avoid redundancy in this case is to combine these two models. It might seem like this is impractical since they have very different underlying assumptions and, more importantly, different interfaces (i.e., different connectors). Nevertheless, it is possible to combine these models by making use of something called a conditional declaration.

Consider the following ConfigurableGear model:

within ModelicaByExample.Components.Rotational.Components;
model ConfigurableGear
  "An ideal non-reversing gear which can be free or grounded"
  parameter Real ratio "Ratio of phi_a/phi_b";
  parameter Boolean grounded(start=false) "Set if housing should be grounded";
  extends Interfaces.TwoFlange;
  Modelica.Mechanics.Rotational.Interfaces.Flange_b housing(phi=housing_phi,
  tau = -flange_a.tau-flange_b.tau) if not grounded "Connection for housing"
    annotation ...
protected
  Modelica.SIunits.Angle housing_phi;
equation
  if grounded then
    housing_phi = 0;
  end if;
  (1-ratio)*housing_phi = flange_a.phi - ratio*flange_b.phi;
  flange_b.tau = -ratio*flange_a.tau;
end ConfigurableGear;

In particular, notice that the declaration of housing ends with if not grounded. When if appears at the end of a declaration, it indicates that the variables only exists if the condition following the if is true. So when the grounded parameter is true, there is no housing connector in this model. Furthermore, the equations included, as modifications, in the declaration of housing (i.e., phi=housing_phi and tau=-flange_a.tau-flange_b.tau) also disappear with the declaration.

Meanwhile, in the equation section, we see that the if statement there provides an additional equation, housing_phi=0, in the case when the model is grounded. This is necessary because the variable housing_phi is always present (i.e., there is no if at the end of its declaration) so there must be an equation for it.

To understand more completely what is going on here, recall that the number of equations required by a component model is equal to the number of flow variables across all the component’s connectors + the number of (non-parameter) variables declared in the model.

The following table summarizes how these things add up for the case where grounded is true and the case where it isn’t:

When using conditional declarations, it is very important to make sure that the number of equations provided balances with the number of equations required for all possible conditions. In this case, we have only two conditions to concern ourselves with and we can clearly see from this table that we have met this requirement in both cases.

The following model demonstrates how we can now use the ConfigurableGear models as both an implicitly and explicitly grounded gear:

And, as we would expect, the response for inertia1 and inertia4 are identical: