KINEMATIC AND DYNAMIC ANALYSIS IN MATHEMATICA
MOTION ANALYSIS OF RIGID BODY SYSTEMS
September 2005 Third edition Intended for use with Mathematica 5 or higher Software and manual written by Robert Beretta Partnerships manager: Joy Costa Developer support specialist: Nirmal Malapaka Project manager: Jennifer Peterson Software quality assurance: Rachelle Bergmann, Jay Hawkins, Cindie Strater Document quality assurance: Rebecca Bigelow, Lorri Coey, Marcia Krause, Angela Latham, Wendy Leung, Carol Ordal, Jan Progen, Joyce Tracewell Document production: Richard Miske Graphic design: Megan Gillette, Jody Jasinski, Kimberly Michael Marketing product manager: Yezabel Dooley Special thanks to Karen Beretta, Joy Costa, Monica Davis, Ed Garner, Joe Grohens, Jay Hawkins, Gary Miller, Leszek Sczaniecki, Kristina Zack Published by Wolfram Research, Inc., 100 Trade Center Drive, Champaign, Illinois 61820-7237, USA phone: +1-217-398-0700; fax: +1-217-398-0747; email:
[email protected]; web: www.wolfram.com © 1994–2005 Dynamic Modeling. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, elec tronic, mechanical, photocopying, recording, or otherwise, without prior written permission of Dynamic Modeling and Wolfram Research, Inc. Dynamic Modeling is the holder of the copyright to the MechanicalSystems software system described in this document, including, without limitation, such aspects of the system as its code, structure, sequence, organization, “look and feel”, programming language, and compilation of command names. Use of the system unless pursuant to the terms of a license granted by Wolfram Research or as otherwise authorized by law is an infringement of the copyright. Dynamic Modeling and Wolfram Research make no representations, express or implied, with respect to this documentation or the software it describes, including, without limitation, any implied warranties of merchantability, interoperability, or fitness for a particular purpose, all of which are expressly disclaimed. Users should be aware that included in the terms and conditions under which Wolfram Research is willing to license MechanicalSystems is a provision that Wolfram Research and its distribution licensees, distributors, and dealers shall in no event be liable for any indirect, incidental, or consequential damages, and that liability for direct damages shall be limited to the amount of the purchase price paid for MechanicalSystems. In addition to the foregoing, users should recognize that all complex software systems and their documentation contain errors and omissions. Dynamic Modeling and Wolfram Research shall not be responsible under any circumstances for providing information on or corrections to errors and omissions discovered at any time in this document or the software it describes, whether or not they are aware of the errors or omissions. Dynamic Modeling and Wolfram Research do not recommend the use of the software described in this document for applications in which errors or omissions could threaten life, injury, or significant loss. Mathematica is a registered trademark of Wolfram Research, Inc. MechanicalSystems is a trademark of Dynamic Modeling. All other trademarks are the property of their respective owners. Mathematica is not associated with Mathematica Policy Research, Inc. or MathTech, Inc. T5244 318648 0905rcm
Table of Contents Preface.............................................................................................................................................................
1
1 Getting Started..........................................................................................................................................
3
1.1 Starting Mechanical Systems...........................................................................................................
3
1.2 Basic 2D Model.................................................................................................................................
5
1.3 Basic 3D Model.................................................................................................................................
14
2 Kinematic Modeling..................................................................................................................................
25
2.1 Body Objects.....................................................................................................................................
25
2.2 Points, Vectors, and Axes.................................................................................................................
31
2.3 Constraint Objects............................................................................................................................
43
2.4 Building the Model..........................................................................................................................
53
2.5 Running the Model..........................................................................................................................
61
2.6 Variable Management.....................................................................................................................
68
3 Output Functions.......................................................................................................................................
75
3.1 2D Output Functions........................................................................................................................
75
3.2 3D Output Functions........................................................................................................................
88
3.3 Plots and Graphs.............................................................................................................................. 103 3.4 2D Mechanism Images..................................................................................................................... 108 3.5 3D Mechanism Images..................................................................................................................... 124
4 Velocity and Acceleration........................................................................................................................ 145 4.1 Velocity and Acceleration Solutions................................................................................................ 145 4.2 Velocity and Acceleration Output................................................................................................... 164
5 Multistage Mechanisms........................................................................................................................... 183 5.1 Stage Switching Constraints............................................................................................................ 183 5.2 Time Switching Constraints............................................................................................................. 193
6 Cams and Gears......................................................................................................................................... 209 6.1 Cam Constraints............................................................................................................................... 209 6.2 Gear Constraints............................................................................................................................... 241
7 Loads and Reactions................................................................................................................................. 261 7.1 Load Objects..................................................................................................................................... 261 7.2 Static Solutions................................................................................................................................. 267 7.3 Resultant Forces............................................................................................................................... 274 7.4 Multistage Loads.............................................................................................................................. 281
8 Inverse Dynamics....................................................................................................................................... 289 8.1 Inertia Properties.............................................................................................................................. 289 8.2 Kinematic and Dynamic Solutions................................................................................................... 300 8.3 Friction and Damping...................................................................................................................... 306
9 Parametric Design..................................................................................................................................... 325 9.1 Coupled Models............................................................................................................................... 325 9.2 Multiple Configuration Couples...................................................................................................... 334 9.3 Velocity and Acceleration Couples.................................................................................................. 339 9.4 Load-Dependent Couples................................................................................................................ 342 9.5 Sensitivity.......................................................................................................................................... 347
10 Underconstrained Systems................................................................................................................... 353 10.1 Equilibrium Configuration............................................................................................................. 353 10.2 Equilibrium Velocity....................................................................................................................... 361 10.3 Free Acceleration........................................................................................................................... 365 10.4 Dynamic Motion Synthesis............................................................................................................. 375 10.5 Nonholonomic Systems.................................................................................................................. 393
11 Generalized Coordinates....................................................................................................................... 397 11.1 Generalized Coordinate Constraints............................................................................................. 398 11.2 Loads and Reactions....................................................................................................................... 417 11.3 Dynamic Modeling......................................................................................................................... 425
12 Performance Improvement................................................................................................................... 435 12.1 Updating Solutions........................................................................................................................ 435 12.2 Simplifying Expressions.................................................................................................................. 438 12.3 Compiling Expressions................................................................................................................... 440 12.4 Coordinate Systems........................................................................................................................ 441 12.5 Locking Variables........................................................................................................................... 445
13 Debugging Models................................................................................................................................. 449 13.1 Model Building Errors.................................................................................................................... 449 13.2 Failure to Converge....................................................................................................................... 455 13.3 Mathematical Anomalies............................................................................................................... 460 13.4 Equations of Motion...................................................................................................................... 462
Appendix: Reference Guide A. Modified Mathematica Built-in Symbols.......................................................................................... 465 B. MechanicalSystems Function Listing................................................................................................. 467
Preface MechanicalSystems is a set of Mathematica packages designed to assist in the analysis and design of planar and spatial rigid body mechanisms. The package is written entirely in the Mathematica programming language and is completely portable and platform independent. The source code is written in the preferred package format as generally used by Wolfram Research, Inc. for the standard packages that are included with Mathematica. MechanicalSystems is intended to run under Mathematica 5.0 or later.
1. Getting Started Overview This chapter is intended to familiarize the user with MechanicalSystems and to provide an overview of its basic functionality. MechanicalSystems actually consists of two basic Mathematica packages; one for planar mechanisms, Modeler2D, and one for spatial mechanisms, Modeler3D. Throughout this manual, the planar and spatial components of MechanicalSystems are often referred to by their package names, Modeler2D and Modeler3D, and the entire MechanicalSystems package is simply referred to as Mech. Section 1.1 describes the steps necessary to load MechanicalSystems into a Mathematica session on various computer systems. In Sections 1.2 and 1.3 two very basic kinematic models (one planar and one spatial) are developed to demonstrate the general functionality of Mech. Both models are of a slider-crank mechanism, such as a small internal combustion engine, and they are presented with minimal explanation. The two models are essentially identical to show the parallelism between Modeler2D and Modeler3D. Further exploration of the functions introduced in this chapter and all of the other functions provided for kinematic modeling can be found in Chapter 2.
1.1 Starting MechanicalSystems This section covers the loading of MechanicalSystems packages into a Mathematica session on various computer systems.
1.1.1 Main Package The MechanicalSystems packages are loaded into Mathematica in the same manner as a standard Mathematica package; with a Get or Needs statement.
MechanicalSystems
4
Get["MechanicalSystems`Modeler2D`"]
load the Modeler2D package.
<<MechanicalSystems`Modeler2D`
load the Modeler2D package.
Needs["MechanicalSystems`Modeler3D`"]
load the Modeler3D package if it has not already been loaded.
Loading the Mech packages.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
It is not possible to have both Modeler2D and Modeler3D loaded simultaneously because they use many of the same function names with different definitions. Attempting to load Modeler3D while Modeler2D is already loaded results in Modeler2D being unloaded and replaced with Modeler3D – and vice versa. The MechanicalSystems packages are not intended to be loaded twice. Thus, it is recommended that Needs be used to load the packages because Needs will not read the package if it has already been read. If Get is accidentally used to load one of the Mech packages after it has already been loaded, an error message is generated, and the Get operation is aborted.
1.1.2 Secondary Packages The MechanicalSystems secondary packages Dynamics2D/3D, Graphics2D/3D, and Utilities2D/3D need not be loaded explicitly. They are loaded automatically if any of the function definitions they contain are needed. However, if the Information or Definition functions are to work correctly with the functions in the secondary packages, these packages must be loaded into Mathematica. Note that requesting information about a MechanicalSystems function with ?functioname will not cause the associated packages to be autoloaded.
This causes all of the Modeler2D packages to be loaded, including Modeler2D itself. In[2]:= Needs@"MechanicalSystems`Dynamics2D`"D
Needs@"MechanicalSystems`Graphics2D`"D Needs@"MechanicalSystems`Utilities2D`"D
Chapter 1: Getting Started
5
1.1.3 Clearing and Unloading MechanicalSystems may be reset to its initial state, or removed Mech entirely from the current Mathematica session without quitting and restarting Mathematica, with the ClearMech or KillMech functions.
ClearMech[]
resets all internal Mech definitions to their initial states, as if Mech had just been loaded.
KillMech[]
removes all of the Mech functions and their contexts, as if Mech had never been loaded.
Resetting or removing Mech.
This removes the entire Modeler2D or Modeler3D package. In[5]:= KillMech@D
After executing KillMech nothing remains of the Mech session except whatever definitions the user had made in the Global` context, and a few undefined symbols that Mech creates in the Global` context. The Mech packages can be reloaded with Get or Needs after executing KillMech.
1.2 Basic 2D Model In this section the basic functionality of the Modeler2D package is demonstrated by building a kinematic model of a very simple mechanism. The mechanism is a planar slider-crank mechanism with two moving bodies, the crankshaft and the piston. The mechanism is modeled using the most abbreviated technique possible with Modeler2D. Later chapters will delve into the many more complex variations on these techniques.
1.2.1 Mechanism Function The Modeler2D package must be loaded before calling any Mech functions.
MechanicalSystems
6
This loads Modeler2D. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Here is a graphic of the 2D slider-crank model.
10
7.5
5
2.5
0
-2.5
-5 -4
-2
0
2
4
6
The following example analyzes the motion of a classic slider-crank mechanism. This mechanism is modeled with a simple and intuitive set of mechanical constraints that are representative of how such a problem would usually be modeled. Body Numbers • The slider-crank mechanism consists of three bodies. Body 1 is the ground body. Body 2 is the crankshaft. Body 3 is the piston.
Chapter 1: Getting Started
7
Each independent body in a Mech model must be given a unique positive integer body number. The choice of each body number is arbitrary, except for the ground body, which must be body 1. These body numbers are used throughout a Mech model to reference each body. The ground body, which is stationary by definition, is used as the reference location and orientation for the rest of the model. All mechanism models must have some reference to the ground body to be adequately constrained. To aid in the readability of the mechanism models created with Mech, a good practice is to name each of the bodies in a mechanism, and then define each of these names to be equal to the integer body number of the body. Each body can then be referenced by name instead of by a number.
Body names are defined to be used as references for each body. In[2]:= ground = 1;
crankshaft = 2; piston = 3;
A real slider-crank mechanism would have a fourth body, the connecting rod between the crankshaft and the piston. However, in the kinematic model this entire part can be replaced by a simple distance constraint specifying that the crank pin and the piston pin are a constant distance apart. This technique decreases the overall size of the model. Local Coordinates Each body in a mechanism model must have a local coordinate system attached to it. How to place this coordinate system on the body is up to the user and is based on the needs of the model. It is not necessary to place the local coordinate origin at the center of gravity of the body. The local coordinate system of each body is used to define points, lines, and other features on the body that are then tied together to make the mechanical constraints. The local coordinate system of body 1, the ground body, is always coincident with the global coordinate system. Therefore, the global coordinate system is referenced through the ground body, simply by specifying body 1.
MechanicalSystems
8
1.2.2 2D Bodies Ground The local coordinate system of the ground body originates at the rotational center of the crankshaft. • Three points are used on the ground body. P1 is a point at the global origin that is the rotational axis of the crankshaft. P2 and P3 are two points that define the vertical line upon which the piston translates. Here is a graphic of the ground body.
80,9<
10
P3 7.5
5
80,4<
P2 2.5
80,0<
0
P1
-2.5
-5 -4
-2
0
2
4
6
Crankshaft The local coordinate system of the crankshaft originates at its rotational center. • Two points are used on the crankshaft. P1 is a point at the local origin that is the rotational axis of the crankshaft. P2 is a point on the local x axis that is the attachment point of the connecting rod.
Chapter 1: Getting Started
9
Here is a graphic of the crankshaft. 6 4 2 P1
P2
80,0<
0
83,0<
-2 -4
-4
-2
0
2
4
6
Piston The local coordinate system of the piston originates four units below the attachment point of the connecting rod. Thus, when the mechanism is in its initial configuration, the local origin of the piston is coincident with the global origin. • Two points are used on the piston. P1 is the attachment point of the connecting rod. P2 is used with P1 to define the vertical translation line of the piston. Here is a graphic of the piston. 8
80,6<
6
P2 80,4<
P1
4 2
-4
-2
0
2
4
6
MechanicalSystems
10
1.2.3 2D Constraints Now that the local point coordinates on each body are defined, building the model is simply a matter of tying the points together with the correct mechanical constraints. Modeler2D provides a small library of mechanical constraint objects that translate desired physical conditions that are imposed on the model into mathematical equations. Constraint Objects Four constraint objects are used to model the slider-crank mechanism, constraining a total of six degrees of freedom (three degrees of freedom for each moving body).
Revolute2[cnum, point1, point2] RotationLock1[cnum, bnum, ang]
constrains point1to be coincident with point2. constrains the angular coordinate of body bnum to be ang radians.
Translate2[cnum, axis1, axis2] RelativeDistance1[cnum, point1, point2, dist] cnum
constrains axis1 to be parallel and coincident with axis2. constrains point1 to lie dist units away from point2. a unique positive integer constraint number.
Some 2D constraint objects.
Note that the last character in the name of any Mech constraint object is an integer that specifies the number of degrees of freedom that it constrains. The first argument to each constraint object, cnum, is the user-specified constraint number. This number is used to reference the constraint later in the modeling process, much like body numbers are used to reference specific bodies. The point and axis arguments of Modeler2D constraint objects are specified with Point, Line, or Axis objects, used in much the same manner as the built-in Mathematica graphics primitives Point and Line. These objects are discussed in detail in Section 2.2.
Chapter 1: Getting Started
11
Building the Model The Modeler2D constraint objects used to model the physical relationships in the slider-crank mechanism are as follows. • A Revolute2 constraint forces the axis of the crankshaft to be coincident with the global origin. This constrains the X and Y displacement of the crankshaft axis. The one degree of freedom left for the crankshaft is its rotation about its axis. The syntax of the constraint can be interpreted as, “Constrain a point at 80, 0< on the ground body to be coincident with point 80, 0< on the crankshaft.” • A RotationLock1 constraint specifies the angular coordinate of the crankshaft. The crankshaft is now completely constrained. The syntax of this constraint can be interpreted as, “Constrain the angular coordinate of the crankshaft to be equal to crankangle.” • A Translate2 constraint forces a vertical line on the piston to be coincident with a vertical line on the ground body. This constrains two degrees of freedom, horizontal translation and rotation of the piston. The one degree of freedom left is the vertical translation of the piston relative to the ground. • A RelativeDistance1 constraint forces an eccentric point on the crankshaft to lie five units distant from the origin of the piston. This single constraint takes the place of a connecting rod five units long. Since the crankshaft is already completely constrained, this completes the constraint of the piston. The Modeler2D constraint objects are finally assembled into a mechanism model with SetConstraints.
SetConstraints[constraints]
uses the constraints to build a mathematical system representing the mechanism model.
The fundamental model-building function.
MechanicalSystems
12
Here is the entire slider-crank model built in one step. In[5]:= crankangle =.
SetConstraints@ Revolute2@1, Point@ground, 80., 0.
SetConstraints returns nothing upon success. All of the constraint equations generated by SetCon straints are stored internally in the Modeler2D private context.
1.2.4 Running the Model A single command is used to solve the constraint equations and return a list of rules representing the coordinates of each body in the model.
SolveMech[]
seeks a solution to the current mechanism model.
The fundamental model-solving function.
This seeks a solution at crankangle = 0. In[7]:= crankangle = 0;
SolveMech@D
Out[8]= 8X2 → 0, Y2 → 0, Θ2 → 0, X3 → 0, Y3 → 0, Θ3 → 0<
SolveMech returns the global coordinates of the origin of each body in the system. The symbols X2 and Y2 specify the location of the origin of body 2, the crankshaft, and Θ2 specifies the rotation of the crankshaft. SolveMech returns a 8Xn, Yn, Θn< triplet for each body in the system.
Chapter 1: Getting Started
13
A graphic of the model at crankangle = 0.
10
7.5
5
2.5
0
-2.5
-5 -4
-2
0
2
4
6
Big surprise! The trivial solution at crankangle = 0 corresponds to the local coordinate system of each body being aligned with the global coordinate system. This is because the model was defined such as to have this perfect assembled configuration. The piston is defined such that its local origin lies at a point that is outside of the piston body, directly on the global origin when crankangle = 0. Note also the 3-4-5 triangle formed by the crankshaft, piston, and connecting rod when crankangle = 0. Advancing crankangle results in a more interesting solution.
This seeks a solution at crankangle = 1/10 revolution. In[9]:= crankangle = 0.1 × 2 π;
SolveMech@D
Out[10]= 8X2 → −1.39599 × 10−21 , Y2 → 2.06126 × 10−22 , Θ2 → 0.628319, X3 → 0., Y3 → 2.13479, Θ3 → 0.<
Now the angular coordinate of the crankshaft, Θ2, has advanced to 2 p ê 10, as specified, and the vertical coordinate of the piston, Y3, has increased to 2.13. All of the other coordinates are still zero and will always be so because of the specific function of this mechanism model.
MechanicalSystems
14
This seeks a solution at crankangle = 3/10 revolution. In[11]:= crankangle = 0.3 × 2 π;
SolveMech@D
Out[12]= 8X2 → 8.22831 × 10−26 , Y2 → 1.56386 × 10−27 , Θ2 → 1.88496, X3 → 0., Y3 → 3.76648, Θ3 → 0.<
A graphic of the model at crankangle = 3/10 revolution.
10
7.5
5
2.5
0
-2.5
-5 -4
-2
0
2
4
6
1.3 Basic 3D Model In this section the basic functionality of Modeler3D is demonstrated by building a kinematic model of a very simple mechanism. The mechanism is a slider-crank mechanism with two moving bodies, the crankshaft and the piston, identical to the mechanism that was modeled with Modeler2D in Section 1.2. Even though it is simply a planar mechanism, the slider-crank is modeled with Modeler3D to demonstrate the parallelism between Modeler2D and Modeler3D.
1.3.1 Mechanism Function The Modeler3D package must be loaded before calling any Modeler3D functions.
Chapter 1: Getting Started
15
This loads the Modeler3D package. In[1]:= Needs@"MechanicalSystems`Modeler3D`"D
Here is a graphic of the 3D slider-crank model.
The following example analyzes the motion of a classic slider-crank mechanism. This mechanism is modeled with a simple and intuitive set of mechanical constraints that are representative of how such a problem would usually be modeled with Modeler3D. Body Numbers • The slider-crank mechanism consists of three bodies. Body 1 is the ground body. Body 2 is the crankshaft. Body 3 is the piston. Each independent body in a Mech model must be given a unique positive integer body number. The choice of each body number is arbitrary except for the ground body, which must be body 1. These body numbers are used throughout a Mech model to reference each body. The ground body, which is stationary by definition, is used as the reference location and orientation for the rest of the model. All mechanism models must have some reference to the ground body to be adequately constrained.
MechanicalSystems
16
To aid in the readability of the mechanism models created with Mech, it is customary to name each of the bodies in a mechanism, and then define each of these names to be equal to the integer body number of the body. Each body can then be referenced by name instead of by a number.
Define body names to be used to reference each body. In[2]:= ground = 1;
crankshaft = 2; piston = 3;
A real slider-crank mechanism would have a fourth body; the connecting rod between the crankshaft and the piston. However, in the kinematic model this entire part can be replaced by a simple distance constraint specifying that the crank pin and the piston pin are to be a constant distance apart. This technique decreases the overall size of the model. Local Coordinates Each body in a mechanism model must have a local coordinate system attached to it. How to place this coordinate system on the body is up to the user and is based on the needs of the model. It is not necessary to place the local coordinate origin at the center of gravity of the body. The local coordinate system of each body is used to define points, lines, planes, and other features on the body that are then tied together to make the mechanical constraints. The local coordinate system of the ground body is coincident with the global coordinate system. Therefore, the global coordinate system is referenced only through the ground body by specifying body 1.
1.3.2 3D Bodies Ground The local coordinate system of the ground body originates at the center of the crankshaft. • Five local point coordinates are used on the ground body. P1 and P2 are two points that define the rotational axis of the crankshaft. P1 is at the global origin and P2 is on the positive Z axis. P3 is a point on the positive X axis that is used (with point 1) to define a reference line to control the rotation of the crankshaft and the piston. P4 and P5 are two points on the positive Y axis that are used to define the vertical translation line of the piston.
Chapter 1: Getting Started
17
Here is a graphic of the ground body. The point coordinates on the ground body are P1 {0, 0, 0}, P2 {0, 0, 5}, P3 {3, 0, 0}, P4 {0, 4, 0}, and P5 {0, 9, 0}.
P5
P4
P1 P2 P3
Crankshaft The local coordinate system of the crankshaft originates at its rotational center. • Three local point coordinates are used on the crankshaft. P1 and P2 are two points that define the rotational axis of the crankshaft. P1 is on the local origin and P2 is on the positive local z axis. P3 is a point on the local x axis that is used as the attachment point of the connecting rod and as a reference point to control the rotation of the crank.
MechanicalSystems
18
Here is a graphic of the crankshaft. The local point coordinates on the crankshaft are P1 {0, 0, 0}, P2 {0, 0, 5}, and P3 {3, 0, 0}.
P1
P3
P2
Piston The local coordinate system on the piston originates at a point that is four units below the attachment point of the connecting rod. Thus, when the slider-crank mechanism is in its initial configuration, the local origin of the piston is coincident with the global origin. • Three local point coordinates are used on the piston. P1 is a point on the local y axis that is the attachment point of the connecting rod. P2 is another point on the local y axis that is the other end of the translation line of the piston. Here is a graphic of the piston. The local point coordinates on the piston are P1 {0, 4, 0}, P2 {0, 6, 0}, and P3 {0, 4, 5}.
P2
P1 P3
Chapter 1: Getting Started
19
1.3.3 3D Constraints Now that the local point coordinates on each 3D body are defined, building the model is simply a matter of tying the points together with the correct mechanical constraints. Modeler3D provides a library of mechanical constraint objects that translate the desired physical conditions that are imposed on the model into mathematical equations. Constraint Objects Five constraint objects are used to model the slider-crank mechanism, constraining a total of 12 degrees of freedom (6 degrees of freedom for each moving body).
Revolute5[cnum, axis1, axis2]
constrains axis1 to be colinear with axis2, and constrains the origins of the two axes to be coincident.
ProjectedAngle1[cnum, vector1, vector2, vector3, ang]
constrains the direction angle of vector1 to be ang radians greater than the direction angle of vector2, as projected onto a plane that is normal to vector3.
Cylindrical4[cnum, axis1, axis2] RelativeDistance1[cnum, point1, point2, dist]
constrains axis1 to be colinear with axis2. constrains point1 to lie dist units away from point2.
Orthogonal1[cnum, vector1, vector2]
constrains vector1 to be orthogonal to vector2.
cnum
a unique positive integer constraint number.
Some 3D constraint objects.
Note that the last character in the name of any Mech constraint object is an integer that specifies the number of degrees of freedom that it constrains. The first argument to each constraint object, cnum, is the user-specified constraint number. This number is used to reference the constraint later in the modeling process, just as body numbers are used to reference specific bodies. The point, vector, and axis arguments required by Modeler3D constraint objects are specified with Point, Vector, Line, Axis, and Plane objects, used in much the same manner as the built-in Mathematica graphics primitives, Point and Line. These objects are discussed in detail in Section 2.2.
MechanicalSystems
20
Building the Model The Modeler3D constraint objects used to model the physical relationships in the slider-crank model are as follows. • A Revolute5 constraint forces the rotational axis of the crankshaft to be coincident with an axis on the ground body. This constrains five degrees of freedom: X, Y, and Z displacement and rotation about the global X or Y axes. The one degree of freedom left for the crankshaft is rotation about the global Z axis. The syntax of this constraint can be interpreted as, “Constrain a line on the ground body spanning from {0, 0, 0} to {0, 0, 5} to be coincident with a line on the crankshaft spanning from {0, 0, 0} to {0, 0, 5}, and constrain the origins of the two lines to be coincident.” • A ProjectedAngle1 constraint specifies the rotational orientation of the crankshaft. This constraint works by projecting two vectors onto a specified plane, and then specifying the angle between the two vectors. The crankshaft is now completely constrained. The syntax of this constraint can be interpreted as, “Constrain the counterclockwise direction angle of the vector {3, 0, 0} on the crankshaft to be crankangle units greater than the direction angle of the vector {3, 0, 0} on the ground body, when the two vectors are projected on a plane on the ground body defined by the three points {0, 0, 0}, {3, 0, 0}, and {0, 4, 0}.” • A Cylindrical4 constraint forces a vertical (+Y) line on the piston to be colinear with a vertical line on the ground body. This constrains four degrees of freedom, X and Z displacement of the piston, and X and Z axis rotation of the piston. The two degrees of freedom left are the pistons vertical translation in the cylinder and rotation of the piston in the cylinder. • A RelativeDistance1 constraint forces an eccentric point on the crankshaft to lie five units distant from a point on the vertical axis of the piston. This models the length of the connecting rod. The syntax of this constraint can be interpreted as, “Constrain the absolute distance between a point {3, 0, 0} on the crankshaft and a point {0, 4, 0} on the piston to be equal to 5.0.” • An Orthogonal1 constraint forces a vector in the Z direction on the piston to be orthogonal to a vector in the X direction on the ground body. This constraint stops the piston from rotating in the cylinder, a function that would have been performed by the connecting rod in a real piston engine. This completes the constraint of the piston.
Chapter 1: Getting Started
21
The Modeler3D constraint objects are finally assembled into a mechanism model with SetConstraints.
SetConstraints[constraints]
uses the constraints to build a mathematical system representing the mechanism model.
The fundamental model-building function.
Here is the entire slider-crank model built in one step. In[5]:= crankangle =.
SetConstraints@ Revolute5@1, Line@ground, 80, 0, 0<, 80, 0, 5
SetConstraints returns Null. All of the mechanism equations generated by SetConstraints are stored internally in the Modeler3D private context.
MechanicalSystems
22
1.3.4 Running the Model A single command is used to solve the constraint equations and return the coordinates of each of the bodies the model.
SolveMech[]
seeks a solution to the current mechanism model.
The fundamental model-solving function.
This seeks a solution at crankangle = 0. In[7]:= crankangle = 0.0;
SolveMech@D
Out[8]= 8X2 → 0, Y2 → 0, Z2 → 0, Eo2 → 1, Ei2 → 0, Ej2 → 0,
Ek2 → 0, X3 → 0, Y3 → 0, Z3 → 0, Eo3 → 1, Ei3 → 0, Ej3 → 0, Ek3 → 0<
SolveMech returns the global coordinates of the origin of each body in the system. X2, Y2, and Z2 specify the location of the origin of body 2, the crankshaft. Eo2, Ei2, Ej2, and Ek2 are the Euler generalized parameters specifying the angular orientation of the crankshaft. SolveMech returns a {Xn, Yn, Zn, Eon, Ein, Ejn, Ekn} set for each body in the system. For those unfamiliar with Euler parameters, suffice it to say that the four Euler parameters provide a numerically robust means of specifying the three degrees of freedom of the angular orientation of a body in 3D space. Values of {1, 0, 0, 0} for the four parameters, respectively, correspond to alignment with the global coordinate system. It is not necessary to have an understanding of the Euler parameters to utilize Modeler3D because postprocessing functions use the Euler parameters to generate more familiar output, such as the rotation of a body about an axis or the angle between two vectors. Euler parameters are discussed further in Chapter 4.
Chapter 1: Getting Started
23
Here is a graphic of the slider-crank model at the initial configuration.
Not a very interesting solution! The solution at crankangle = 0 is for the local coordinate system of each body to be aligned with the global coordinate system. This is because the model was defined such as to have this perfect assembled configuration. The piston is defined such that its local origin lies at a point that is outside of the piston body. This point is coincident with the global origin when crankangle = 0. Note the 3-4-5 triangle formed by the crankshaft, piston, and connecting rod when crankangle = 0. Advancing crankangle results in a more interesting solution.
This seeks a solution at crankangle = 1/10 revolution. In[9]:= crankangle = 0.1 × 2 π;
SolveMech@D
Out[10]= 8X2 → −3.89741 × 10−25 , Y2 → −1.69395 × 10−25 , Z2 → 0., Eo2 → 0.951057, Ei2 → 0., Ej2 → 0.,
Ek2 → 0.309017, X3 → 0., Y3 → 2.13479, Z3 → 0., Eo3 → 1., Ei3 → 0., Ej3 → 0., Ek3 → 0.<
Now two of the Euler parameters of the crankshaft Eo2 and Ek2 have changed, and the vertical coordinate of the piston Y3 has increased to 2.13. All of the other coordinates have not changed, and never will, because of the specific function of this particular mechanism model.
MechanicalSystems
24
This seeks a solution at crankangle = 3/10 revolution. In[11]:= crankangle = 0.3 × 2 π;
SolveMech@D
Out[12]= 8X2 → 2.99367 × 10−20 , Y2 → −4.63258 × 10−21 , Z2 → 0., Eo2 → 0.587785, Ei2 → 0., Ej2 → 0.,
Ek2 → 0.809017, X3 → 0., Y3 → 3.76648, Z3 → 0., Eo3 → 1., Ei3 → 0., Ej3 → 0., Ek3 → 0.<
Here is a graphic of the model at crankangle = 3/10 revolution.
2. Kinematic Modeling Overview This chapter covers the building and running of basic kinematic models with MechanicalSystems. Throughout this chapter the simplest and most commonly used forms of each MechanicalSystems command are presented. For more detailed information on specific commands, consult the reference guide in the appendix. MechanicalSystems follows most of the conventions set by Mathematica as to its use of function names, options, and option settings. One significant deviation from standard Mathematica practice is that MechanicalSystems often uses the same name for an option and for the name of a function that performs a service related to the option. For example, PointList is the name of an option that is used to set the values of local point coordinates, and it is also the name of a function that queries the local point coordinates.
2.1 Body Objects A SysBody object is a Mech data object that is used to define the points and properties of a mechanism body. It is not necessary to use body objects in Mech kinematic models, as demonstrated in Sections 1.2 and 1.3, but the use of body objects allows points to be defined once, inside the body object, and then to be referenced throughout the Mech model. This can reduce the likelihood of error due to changing the definition of a point at one place on the model, while failing to change it elsewhere.
2.1.1 Body Mech SysBody objects are created by the Body function, and used to define specific properties of a body in a mechanism model.
MechanicalSystems
26
Body[bnum, options]
returns a SysBody data object that contains properties of body bnum (a positive integer). Each property of the body is specified with an option.
A function to define body objects.
Body accepts three options for defining inertia properties of a body: Mass, Inertia, and Centroid. These options will be discussed further in Section 8.1. The options for Body that are relevant in the kinematic phase of analysis are the PointList and InitialGuess options. 2D PointList → {{x1, y1}, ..., {xn, yn}} InitialGuess → {{X, Y}, Q}
specifies the local coordinates of n points on the body. The points are referenced by their local point number n. sets numeric initial guesses. An initial guess of {{0, 0}, 0} corresponds to alignment with the global coordinate system.
2D options for Body.
3D PointList → {{x1, y1, z1}, ..., {xn, yn, zn}} InitialGuess → {{X, Y, Z}, {Eo, Ei, Ej, Ek}}
specifies the local coordinates of n points on the body. The points are referenced by their local point number n. sets numeric initial guesses for a 3D body. A guess of {{0, 0, 0}, {1, 0, 0, 0}} corresponds to alignment with the global coordinate system.
3D options for Body.
Chapter 2: Kinematic Modeling
27
2D/3D PointList → Automatic InitialGuess → Automatic
leaves the existing points on the body unchanged. sets the guesses for a new body such that it is aligned with the global coordinate system, or leaves the guesses for an existing body unchanged.
Default option settings for Body.
Executing the Body function does not, in itself, have any affect on the current Mech model. The returned body objects must be added to the model with the SetBodies command, which is discussed in Section 2.1.2. Initial guesses specified with a body object are referred to as the permanent initial guesses. These initial guesses are used the first time that a solution is sought with SolveMech. Each subsequent solution attempt uses the previous solution as its initial guess. When the initial guesses are set with SetGuess, they may be explicitly set to user-specified values, or reset to the stored values of the permanent initial guesses. Example This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
The 2D example mechanism of Section 1.2 can be modified to use three body objects instead of repeatedly calling out the several local point coordinates on the ground, crankshaft, and piston bodies. These body objects store the local point definitions for future reference, through their integer point numbers, by other Mech functions.
MechanicalSystems
28
Here are the crankshaft-piston mechanism bodies.
10
10
7.5
10
7.5
7.5
5
5
5
2.5 0
{0,9} P3
P2 {0,4}
2.5
{0,0} P1
0 {0,0} {3,0}
-2.5
-5
-5 0
P2
0
-2.5
-4 -2
2.5 P1
{0,6} P2 P1 {0,4}
2
4
6
-2.5 -5 -4 -2
0
2
4
6
-4 -2
0
2
4
6
• The ground body object uses three local point definitions. P1 is a point at the global origin that is the rotational axis of the crankshaft. P2 and P3 are two points that define the vertical line upon which the piston translates. This defines a body object for the ground body. In[2]:= ground = 1;
bd@1D = Body@ground, PointList → 880., 0.<, 80., 4.<, 80., 9.<
D
• The crankshaft uses two local point definitions. P1 is a point at the local origin that is the rotational axis of the crankshaft. P2 is a point on the local x axis that is the attachment point of the connecting rod. This defines a body object for the piston. In[4]:= crank = 2;
bd@2D = Body@crank, PointList → 880., 0.<, 83., 0.<
• The piston also uses two local point definitions. P1 is a point on the local y axis that is the attachment point of the connecting rod. P2 is a point on the local y axis that is the upper end of the translation line of the piston.
Chapter 2: Kinematic Modeling
29
This defines a body object for the piston. In[6]:= piston = 3;
bd@3D = Body@piston, PointList → 880., 4.<, 80., 6.<
InitialGuess Alternately, the piston could have been defined with the local origin at the attachment point of the connecting rod. This would suggest that a different initial guess be used than the default of X3 = 0, Y3 = 0, Θ3 = 0.
Here is a body object for the piston with relocated origin and corresponding initial guess. In[8]:= piston = 3;
bd@3D = Body@piston, PointList → 880., 0.<, 80., 2.<<, InitialGuess → 880, 4<, 0
This body object functions identically to the first one, except the Y coordinate of the piston is always 4 units greater, because the origin of the body has moved 4 units upward. Note that each of these body objects must be added to the current model with SetBodies before they will have any effect on the model.
2.1.2 SetBodies The Mech SetBodies function is used to apply the data contained in body objects to the current kinematic model.
SetBodies[Body[bnum, options]...]
accepts SysBody data objects and adds the point and property data contained therein to Mech’s internal database.
The body object processing function.
All properties specified in a call to SetBodies overwrite properties that are currently defined unless the property specification is the default, Automatic, in which case the property is left unchanged.
MechanicalSystems
30
If SetBodies is passed a body object with an InitialGuess specification other than Automatic, the current initial guesses of each body are reset to the values of the permanent initial guesses. There is a subtle issue regarding the use of the PointList specification with SetBodies. When SetBod ies is run with a new InitialGuess specification, the changed guess is immediately reflected in Mech’s internal database. The same holds true for changing inertia properties with SetBodies; the mass matrix is immediately updated. However, changing the coordinates of a point with PointList must reflect a change throughout the constraint equations defined with SetConstraints. This cannot be done without rebuilding the constraint equations. Therefore, if the constraint equations have already been built with SetConstraints when SetBodies is passed a PointList specification other than Automatic, the constraint equations will all be automatically rebuilt by SetConstraints the next time that a solution is sought, which may cause a noticeable delay in the operation of SolveMech. The following command incorporates the three body objects that were defined in Section 2.1.1 into the current model.
This starts a model with the three body objects. In[10]:= SetBodies@bd@1D, bd@2D, bd@3DD
SetBodies returns Null. All of the mechanism points and properties passed to SetBodies are stored in Mech’s internal database. Now that local point definitions have been added to the current model, they can be referenced by their local point numbers in any Mech function. Instead of using the local coordinates of a point, simply use the integer point number. For example, the Translate2 constraint in the crankshaft-piston model would use four local point numbers instead of the four explicit 2D coordinates in the Line objects.
Here is a constraint with, and without, local point numbers. In[11]:= Translate2@3,
Line@ground, Line@piston, Translate2@3, Line@ground, Line@piston,
2, 3D, 1, 2DD; 80, 4<, 80, 9
Chapter 2: Kinematic Modeling
31
Updating Properties SetBodies only sets the values of the properties that are not specified with the default, Automatic. Thus, SetBodies can be used to update the value of individual body properties without affecting properties already defined.
This updates only the crankshaft’s initial guess.
In[13]:= SetBodies@Body@crank, InitialGuess → 881, 1<, 0
PointList Note that PointList, like many Mech options, can also be used as a function.
PointList[bnum, pnum]
returns the local coordinates of point pnum on body bnum.
Another usage of PointList.
Here are the local coordinates of point 2 on the piston. In[14]:= PointList@piston, 2D Out[14]= 80., 2.<
2.2 Points, Vectors, and Axes This section explains the functionality and syntax of Mech’s method of defining the basic geometric entities that make up a mechanism model: points, vectors, and axes. A look at the usage statements for most of Mech’ s functions shows that they take arguments of type point, vector, or axis. In all cases there are several ways to specify a point, vector, or axis, depending on whether the entity is defined in global or local coordinates, is located entirely on a single body, or spans across multiple bodies.
MechanicalSystems
32
A point argument is satisfied by a point object. A point object can be a list of coordinates, {x, y} or {x, y, z}, or an expression with the head Point. A point object is used to specify location. A vector argument is satisfied by a vector object. A vector object can be a list of the vector components, {x, y} or {x, y, z}, or an expression with the head Vector, Line, or Plane. A vector object is used to specify direction. An axis argument is satisfied by an axis object. An axis object can be an expression with the head Line, Plane, or Axis. An axis object is used to specify location and direction. The three basic types of Mech geometry objects.
2.2.1 Points The most basic geometric entity used by Mech is the point object. Point objects reference the location of a 2D or 3D point in global coordinates or in local coordinates on a specified body. Point objects may be given as 2D or 3D vectors, or they may have the head Point just like the built-in Mathematica graphics primitive. This does not lead to any conflict or require a redefinition of Point because it has no definition by default. The Point head is only used to hold its arguments in Mech, just as it is in standard Mathematica. Any Mech function that calls for a point object accepts either of the following syntax. 2D Point[bnum, lpnt]
references a point with local coordinates lpnt located on body bnum. Point lpnt can be a local coordinate pair {x, y} or a positive integer point number that references a local coordinate defined with SetBodies.
{x, y} Methods of defining 2D point objects.
references a point with the specified global coordinates.
Chapter 2: Kinematic Modeling
33
3D Point[bnum, lpnt]
references a point with local coordinates lpnt located on body bnum. Point lpnt can be a local coordinate triplet {x, y, z} or a positive integer point number that references a local coordinate defined with SetBodies.
{x, y, z}
references a point with the specified global coordinates.
Methods of defining 3D point objects.
Assuming that the appropriate body object definition has been made, any point on any body can be referenced through either its global coordinates, its local coordinates, or its local coordinate number. The following example shows several point objects that are functionally identical.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Local points are defined on the ground body. In[2]:= ground = 1;
SetBodies@Body@ground, PointList → 880, 0<, 82, −4<, 83, 6<
Here are three identical point specifications.
In[4]:= Point@ground, 82, −4
Point@ground, 2D; 82, −4<;
MechanicalSystems
34
2.2.2 Vectors The basic geometric entity specifying direction is the vector object. Vector objects reference the direction of a 2D or 3D vector, in global coordinates or in local coordinates on a specified body. Vector objects may be given as 2D or 3D vectors in global coordinates, or they may have the head Vector and be given in local coordinates on a specific body. A Line can be used to specify a vector object, in which case the direction of the Line is used as the direction of the vector. A Plane (3D only) may also be used to specify a vector object, in which case the normal direction of the Plane is used as the direction of the vector. See the following two subsections for further information on Line and Plane. Any Mech function that calls for a vector object accepts either of the following syntax. 2D Vector[bnum, lpnt]
references a vector from the origin of body bnum to point lpnt located on body bnum. Point lpnt can be a local coordinate pair {x, y} or a positive integer point number that references a local coordinate defined with SetBodies.
{x, y}
references a vector with the specified global direction and magnitude.
Methods of defining 2D vector objects.
3D Vector[bnum, lpnt]
references a vector from the origin of body bnum to point lpnt located on body bnum. Point lpnt can be a local coordinate triplet {x, y, z} or a positive integer point number that references a local coordinate defined with SetBodies.
{x, y, z}
references a vector with the specified global direction and magnitude.
Methods of defining 3D vector objects.
Chapter 2: Kinematic Modeling
35
Assuming that the appropriate body object definition has been made, any vector on any body can be referenced through either its global coordinates, its local coordinates, or its local point number. The following example shows several vector objects that are functionally identical.
This defines some coordinates on the crank. In[7]:= crank = 2;
SetBodies@Body@crank, PointList → 880, 0<, 82, −4<, 83, 6<
Here are two identical vector specifications.
In[9]:= Vector@crank, 83, 6
Vector@crank, 3D;
2.2.3 Lines The Line object is used by Mech to reference a line in 2D or 3D space. A Line is defined two points: an origin point and an end point. The two points may be on the same or two different bodies. Because a Line object possesses both direction and location, it can be used in place of a vector object or an axis object in any Mech function that calls for a vector or an axis object. Line objects have the same head as the built-in Mathematica Line graphics primitive. This does not lead to any conflict or require a redefinition of Line because it has no definition by default. The Line head is only used to hold its arguments in Mech, just as it is in standard Mathematica. Any Mech function that calls for a vector or axis object accepts any of the following syntax.
MechanicalSystems
36
2D Line[point1, point2]
references a line from point1 to point2, where the each of the pointi are any valid form of Mech point object.
Line[bnum, lpnt1, lpnt2]
references a line spanning from local point lpnt1 to lpnt2 on body bnum. The lpnti can be local coordinate pairs {x, y} or positive integer point numbers that reference local coordinates defined with SetBodies.
Line[bnum1, lpnt1, bnum2, lpnt2]
references a line spanning two bodies from local point lpnt1 on body bnum1 to local point lpnt2 on body bnum2.
Methods of defining 2D line objects.
3D Line[point1, point2]
references a line from point1 to point2, where each of the pointi are any valid form of Mech point object.
Line[bnum, lpnt1, lpnt2]
references a line spanning from local point lpnt1 to lpnt2 on body bnum. The lpnti can be local coordinate triplets {x, y, z} or positive integer point numbers that reference local coordinates defined with SetBodies.
Line[bnum1, lpnt1, bnum2, lpnt2]
references a line spanning two bodies from local point lpnt1 on body bnum1 to local point lpnt2 on body bnum2.
Methods of defining 3D line objects.
Chapter 2: Kinematic Modeling
37
Assuming that the appropriate body object definition has been made, any line spanning bodies or on a single body can be referenced with a combination of global points, local points, or local point numbers. The following example shows several line objects that are functionally identical.
This defines several points on the two bodies. In[11]:= ground = 1; crank = 2;
SetBodies@ Body@ground, PointList → 880, 0<, 82, −4<, 83, 6<
Here are three identical line definitions.
In[13]:= Line@ground, 82, −4<, crank, 84, −1
Line@ground, 2, crank, 3D; Line@Point@ground, 2D, Point@crank, 3DD;
Here are two more identical line definitions.
In[16]:= Line@ground, 80, 0<, ground, 82, −4
Line@ground, 1, 2D;
2.2.4 Planes The Plane object is used by Modeler3D to reference a planar surface in 3D space. A Plane is defined by three points and has a specific origin, normal direction, and reference direction (see Axis). The first of the three points is the origin, and the vector from the first point to the second point is the reference direction. The third coplanar point cannot be colinear with the first two points. The positive normal is given by the cross product of the vector from the first point to the second point and the vector from the first point to the third point.
MechanicalSystems
38
Because a Plane object possesses the properties of direction and location, it can be used in place of a vector object or an axis object in any Mech function that calls for a vector or an axis. If a Plane object is used to specify direction, the normal direction is used as the direction vector. Any Modeler3D function that calls for a vector or axis object accepts any of the following syntax. 3D Plane[point1, point2, point3]
references a plane defined by three coplanar points. The plane originates at point1 and the reference direction is the vector from point1 to point2. Each of the pointi must be Mech point objects.
Plane[bnum, lpnt1, lpnt2, lpnt3]
references a plane on body bnum with three defining coplanar points lpnt1, lpnt2, and lpnt3. The coordinates lpnti can be local coordinate triplets {x, y, z} or positive integer point numbers that reference local coordinates on body bnum defined with SetBodies.
Plane[bnum1, lpnt1, bnum2, lpnt2, bnum3, lpnt3]
references a plane with three defining points at Point[bnum1, lpnt1], Point[bnum2, lpnt2], and Point[bnum3, lpnt3].
Methods of defining plane objects.
Assuming that the appropriate body object definition has been made, a plane spanning any one, two, or three bodies can be referenced with a combination of global points, local points, or local point numbers. The following example shows several plane objects that are functionally identical.
Chapter 2: Kinematic Modeling
39
This loads the Modeler3D package. In[18]:= Needs@"MechanicalSystems`Modeler3D`"D
Local points are defined on the two bodies. In[19]:= ground = 1; crank = 2;
SetBodies@ Body@ground, PointList → 880, 0, 0<, 82, −4, 0<, 83, 6, 6<
Here are two identical plane definitions. In[21]:= Plane@Point@ground, 1D, Point@crank, 2D, Point@crank, 3DD;
Plane@ground, 1, crank, 2, crank, 3D; Here are three more identical plane definitions.
In[23]:= Plane@ground, 80, 0, 0<, ground, 82, −4, 0<, ground, 83, 6, 6
Plane@ground, 1, 2, 83, 6, 6
2.2.5 Axes The axis object is used by Mech to reference an axis in 2D or 3D space. An axis object is specified by origin and direction. Optionally, 3D axis objects may have a reference direction specified. The reference direction is a vector that is not parallel to the direction of the axis. The reference direction is used by some Modeler3D constraints to control rotation about the axis.
MechanicalSystems
40
An axis object may have the head Axis, Line, or Plane. If a Line is used to specify an axis object, the origin and direction of the Line are used as the origin and direction of the axis. Because a Line object has no specific reference direction, a Line should not be used in place of a Modeler3D axis object in a function where the reference direction is relevant. If a Plane is used to specify an axis object, the origin of the Plane is used as the origin of the axis, the normal direction of the Plane is used as the direction of the axis, and the line from point1 to point2 on the Plane is used as the reference direction of the axis. Any Mech function that calls for an axis object accepts any of the following syntax. 2D Axis[point, vector]
references an axis that originates at point and points in the direction of vector. point must be a Mech point object and vector must be a Mech vector object.
Axis[bnum, lpnt1, lpnt2]
references an axis originating at lpnt1 on body bnum and having a direction vector equal to the local coordinates of lpnt2 on body bnum. The lpnti can be local coordinate pairs {x, y} or positive integer point numbers that reference local coordinates defined with SetBodies.
Axis[bnum1, lpnt1, bnum2, lpnt2]
references an axis originating at lpnt1 on body bnum1 and having a direction vector equal to the coordinates of lpnt2 on body bnum2.
Methods of defining 2D axis objects.
Chapter 2: Kinematic Modeling
41
3D Axis[point, vector]
references an axis that originates at point and points in the direction of vector. point must be a Mech point object and vector must be a Mech vector object.
Axis[point, vector1, vector2]
references an axis that originates at point, points in the direction of vector1, and has reference direction vector2. point must be a Mech point object and the vectori must be Mech vector objects.
Axis[bnum, lpnt1, lpnt2]
references an axis originating at lpnt1 on body bnum and having a direction vector equal to the local coordinates of lpnt2 on body bnum. The lpnti can be local coordinate triplets {x, y, z} or positive integer point numbers that reference local coordinates defined with SetBodies.
Axis[bnum1, lpnt1, lpnt2, lpnt3]
references an axis originating at lpnt1 on body bnum, having a direction vector equal to the coordinates of lpnt2 on body bnum, and having a reference direction equal to the coordinates of lpnt3 on body bnum.
Axis[bnum1, lpnt1, bnum2, lpnt2, bnum3, lpnt3]
references an axis originating at lpnt1 on body bnum1, having a direction vector equal to the coordinates of lpnt2 on body bnum2, and having a reference direction equal to the coordinates of lpnt3 on body bnum3.
Methods of defining 3D axis objects.
Assuming that the appropriate body object definitions have been made, any axis with origin and direction specified with coordinates on a single body or multiple bodies can be referenced with a combination of global points, local points, or local point numbers. The following example shows several axis objects that are functionally identical.
This loads the Modeler2D package. In[26]:= Needs@"MechanicalSystems`Modeler2D`"D
MechanicalSystems
42
Local points are defined on the two bodies. In[27]:= ground = 1;
crank = 2; SetBodies@ Body@ground, PointList → 880, 0<, 82, −4<, 83, 6<
Here are three functionally identical axis definitions. In[30]:= Axis@Point@ground, 2D, Line@ground, 2, crank, 3DD;
Axis@ground, 2, crank, 8−1, −1
Here are three more identical axis definitions. In[33]:= Axis@Point@ground, 1D, Vector@ground, 2DD;
Axis@ground, 80, 0<, 82, −4
2.2.6 The Zeroth Point For convenience, local point 0 (zero) can be used to reference the local origin of any body, although point 0 is never defined. The zeroth point can always be used, regardless of whether or not any SysBody objects have been defined and passed to SetBodies. The following examples show the use of the zeroth point. 2D Here are two identical 2D point objects.
In[36]:= Point@3, 80, 0
Point@3, 0D;
3D Here are two identical 3D line objects.
In[38]:= Line@2, 80, 0, 0<, 81, 5.2, 0
Line@2, 0, 81, 5.2, 0
Chapter 2: Kinematic Modeling
43
2.3 Constraint Objects Constraint objects are used to define the mathematical relationships that make up the kinematic model in terms of the physical relationships of the various mechanism bodies. All Mech constraint functions return constraint objects with the head SysCon. These constraint objects are passed to the SetConstraints function to build the mathematical model.
2.3.1 General Format All arguments to any constraint function follow the same general format.
constraintfunction[cnum, points | vectors | axes, scalars] returns a Mech constraint object with the head SysCon. cnum is a positive integer constraint number that must be unique among all of the constraints in a single model. point, vector, and axis are Mech geometry objects as defined in Section 2.2. Some constraint functions require a scalar expression to specify an angle or distance. Format for all constraint functions.
Further, all constraint function names end with a single digit, except the general constraint function Con straint. This digit signifies the number of degrees of freedom constrained by the constraint. For example, the 2 in the Translate2 constraint function name signifies that it contains two constraint equations and constrains two degrees of freedom in a model.
2.3.2 2D Basic Constraints The Modeler2D basic constraints specify elementary geometric relationships between points and lines on mechanism bodies. Elementary relationships are used for the majority of simple mechanical joints. A shaft spinning in a bearing is modeled by specifying that two points are coincident. A connecting rod can be modeled by specifying a constant distance between two points. A guide pin in a slot is modeled by specifying that a point on one body lies on a line on another body. A piston in a cylinder is modeled by specifying that two lines on two different bodies are colinear.
MechanicalSystems
44
Many seemingly different mechanical joints are often modeled with the same constraint, such as a connecting rod versus a guide pin in a circular track; both are modeled by specifying the distance between two points on two different bodies. It is up to the user to determine the true nature of the kinematic relationships that make up a mechanism. The entire set of Modeler2D constraint functions is quite redundant; all basic 2D mechanisms could, in fact, be modeled with a small subset of the Modeler2D constraints. The goal in this is to provide a constraint that is similar in form to the actual mechanical joint being modeled. Thus, the readability of the model can be improved.
OriginLock2[cnum, bnum1, bnum2]
locks the origin of body bnum1 to that of body bnum2. The coordinates of the local origins of the two bodies are identical.
RotationLock1[cnum, bnum1, bnum2, ang]
constrains the angular coordinate of body bnum1 to be ang radians greater than the angular coordinate of body bnum2.
Local coordinate constraints directly control the local coordinates of specified bodies.
PointOnLine1[cnum, point, axis]
constrains point to lie on axis.
PointOnLine1[cnum, point, axis, dist]
places point dist units to the left of axis.
RelativeX1[cnum, point, dist]
sets the global X coordinate of point to be equal to dist.
RelativeY1[cnum, point, dist]
sets the global Y coordinate of point to be equal to dist.
DirectedDistance1[cnum, point1, point2, vector, dist] RelativeDistance1[cnum, point1, point2, dist]
constrains point1 to lie dist units away from point2, measured in the direction of vector. constrains point1 to lie dist units away from point2.
Point-on-line constraints force a point on a body to travel along a specified line.
Chapter 2: Kinematic Modeling
Revolute2[cnum, point1, point2] DirectedPosition2[cnum, point1, point2, vector] PointOnLines2[cnum, point, axis1, axis2]
45
constrains point1 to be coincident with point2. constrains the location of point1 to be equal to the location of point2 plus vector. constrains point to lie at the intersection of axis1 and axis2.
Point-at-position constraints force a point on a body to lie at a specified position.
Parallel1[cnum, vector1, vector2] Orthogonal1[cnum, vector1, vector2] RelativeAngle1[cnum, vector1, vector2, ang]
constrains vector1 to be parallel to vector2. constrains vector1 to be orthogonal to vector2. constrains the direction angle of vector1 to be ang radians greater than the direction angle of vector2.
Angular constraints control the angle between the direction vectors of two lines.
Translate2[cnum, axis1, axis2]
constrains axis1 to be parallel and coincident with axis2.
Compound constraints enforce multiple geometric relationships simultaneously.
There are several other compound constraints available for modeling gears and cams, these are discussed in Chapter 6. To demonstrate the ambiguity in determining which constraint is the correct constraint, the set of four constraints used in the crankshaft-piston model are examined. The first constraint, Revolute2, could be modeled with a pair of constraints with one degree of freedom each; a RelativeX1 to control the X coordinate of the crankshaft axis, and a RelativeY1 to control the Y coordinate.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
MechanicalSystems
46
The Revolute2 constraint is functionally identical to a pair of one degree of freedom constraints. In[2]:= ground = 1;
crank = 2; piston = 3; Revolute2@1, Point@ground, 80, 0
The second constraint, RotationLock1, could be modeled by constraining the angle between two lines, one on the crankshaft and one on the ground. Here are two equivalent constraints. In[8]:= RotationLock1@2, crank, crankangleD;
RelativeAngle1@2, Line@crank, 80, 0<, 81, 0
The RelativeDistance1 constraint, in this application, cannot be replaced by the use of any other constraint. It is somewhat unique, geometrically.
This constraint has no functional equivalent. In[10]:= RelativeDistance1@4,
Point@crank, 83, 0
Chapter 2: Kinematic Modeling
47
2.3.3 3D Basic Constraints The Modeler3D basic constraints specify elementary geometric relationships between points, lines, and planes on mechanism bodies. Elementary relationships are used for the majority of mechanical joints. A shaft spinning in a bearing is modeled by specifying that two axes are coincident. A connecting rod can be modeled by specifying a constant distance between two points. A guide pin in a slot is modeled by specifying that a point on one body lies on a line on another body. A piston in a cylinder is modeled by specifying that two lines on two different bodies are colinear. Many seemingly different mechanical joints are often modeled with the same constraint, such as a connecting rod versus a guide pin in a circular track; both are modeled by specifying the distance between two points on two different bodies. It is up to the user to determine the true nature of the kinematic relationships that make up a mechanism. The entire set of Modeler3D constraint functions is quite redundant; all basic 3D mechanisms could, in fact, be modeled with a small subset of Modeler3D constraints. The goal in this is to provide a constraint that is similar in form to the actual mechanical joint being modeled. Thus, the readability of the model is improved.
OriginLock3[cnum, bnum, {x, y, z}] RotationLock3[cnum, bnum, {ang, {x, y, z}}]
locates the origin of body bnum at the global coordinates {x, y, z}. rotates body bnum ang radians about the specified global axis {x, y, z}.
Local coordinate constraints directly control the local coordinates of specified bodies.
MechanicalSystems
48
PointOnPlane1[cnum, point, axis]
constrains point to lie on the surface of a plane defined by axis. The plane may be specified with a Plane object, or by the plane’s normal with an Axis or Line object.
RelativeX1[cnum, point, dist]
sets the global X coordinate of point to be equal to dist.
RelativeY1[cnum, point, dist]
sets the global Y coordinate of point to be equal to dist.
RelativeZ1[cnum, point, dist]
sets the global Z coordinate of point to be equal to dist.
DirectedDistance1[cnum, point1, point2, vector, dist] RelativeDistance1[cnum, point1, point2, dist]
constrains point1 to lie dist units away from point2, measured in the direction of vector. constrains point1 to lie dist units away from point2. Rela tiveDistance1 could have been named PointOnSphere1.
PointOnCylinder1[cnum, point, axis, rad] PointOnCone1[cnum, point, axis, ang]
constrains point to lie rad units distant from axis. constrains point to lie on the surface of a cone revolved about axis with half angle ang. The vertex of the cone lies at the origin of axis.
PointOnTorus1[cnum, point, axis, majr, minr]
constrains point to lie on the surface of a torus of major radius majr and minor radius minr. The major axis of the torus is specified by axis and the center of the torus lies at the origin of axis.
Point-on-surface constraints force a point to lie on a specified surface.
PointOnLine2[cnum, point, axis]
constrains point to lie on axis.
PointOnCircle2[cnum, point, axis, rad]
constrains point to lie on a circle of radius rad revolved
PointOnPlanes2[cnum, point, axis1, axis2]
constrains point to lie on the intersection of two planes. The
about axis. The center of the circle lies at the origin of axis. planes are specified by their normals with axis1 and axis2, which may be Plane objects.
Point-on-line constraints force a point to lie on a line or curve.
Chapter 2: Kinematic Modeling
Spherical3[cnum, point1, point2] DirectedPosition3[cnum, point1, point2, vector] PointAtIntersection3[cnum, point, axis1, axis2]
49
constrains point1 to be coincident with point2. constrains the location of point1 to be equal to the location of point2 plus vector. constrains point to lie at the intersection of axis1 and a plane that is specified by axis2.
Point-at-position constraints control the position of a point.
Orthogonal1[cnum, vector1, vector2] ProjectedAngle1[cnum, vector1, vector2, vector3, ang]
constrains vector1 to be orthogonal to vector2. constrains the angle of the projection of vector1, relative to the projection of vector2, to be equal to ang when the two vectors are projected on a plane that is normal to vector3.
RelativeAngle1[cnum, vector1, vector2, ang]
constrains the included angle between the vectori to be equal to ang. Note that RelativeAngle1 becomes singular as ang approaches zero. In this case use the Parallel2 constraint instead.
Angular constraints control the angle between two vectors.
Parallel2[cnum, vector1, vector2] Parallel constraint enforces parallelism between two vectors.
constrains the two vectors to be parallel in 3D space.
MechanicalSystems
50
LineToLine1[cnum, axis1, axis2, dist] LineToCircle1[cnum, axis1, axis2, rad] PlaneToCircle1[cnum, axis1, axis2, rad]
constrains the perpendicular distance between the two axes to be equal to dist. constrains axis1 to pass through the perimeter of a circle of radius rad, with the axis of the circle specified by axis2. constrains a plane, specified by normal with axis1, to lie tangent to a circle of radius rad. The axis of the circle is specified by axis2.
LineToPlane2[cnum, axis1, axis2, dist] LineOnCylinder3[cnum, axis1, axis2, dist] PlaneToPlane3[cnum, axis1, axis2, dist]
constrains axis1 to lie dist units away from, and parallel to, a plane specified by axis2. constrains the two axes to be parallel and dist units apart. constrains two planes to be parallel and dist units apart. The planes are specified by their normals with axis1 and axis2, which may be Plane objects.
Constraints that enforce more complex geometric relationships.
Chapter 2: Kinematic Modeling
Cylindrical4[cnum, axis1, axis2]
51
models a hinge that can translate along its axis and rotate about its axis. The two axes are constrained to be colinear.
Revolute5[cnum, axis1, axis2]
models a hinge or revolving joint. The two axes are constrained to be colinear, and their origins are constrained to be coincident.
Translate5[cnum, axis1, axis2]
models a linear slider that cannot rotate. The two axes are constrained to be colinear, and their reference directions are coplanar.
ParaRevolute4[cnum, axis1, axis2, dist]
models two side-by-side hinges. The two axes are constrained to be parallel, and dist units apart. Further, the origin of axis1 is constrained to lie directly adjacent to the origin of axis2.
OrthoRevolute4[cnum, axis1, axis2, dist]
models a pair of hinges with offset orthogonal axes. The two axes are constrained to be orthogonal, and dist units apart. Further, the origin of axis1 is constrained to lie directly adjacent to the origin of axis2.
Compound constraints enforce multiple geometric relationships simultaneously.
There are several other compound constraints available for modeling gears and cams; these are discussed in Chapter 6. To demonstrate the ambiguity in determining which constraint is the correct constraint, the set of five constraints used in the crankshaft-piston model are reexamined. The first constraint, a Revolute5, could be modeled instead with two constraints; a Spherical3 constraint to control the position of the crankshaft, and a Parallel2 constraint to control the direction vector of the crankshaft’s axis.
This loads the Modeler3D package. In[11]:= Needs@"MechanicalSystems`Modeler3D`"D
MechanicalSystems
52
Here is the original Revolute5 constraint. In[12]:= ground = 1;
crank = 2; piston = 3; Revolute5@1, Line@ground, 80, 0, 0<, 80, 0, 5
Here are an alternative pair of constraints that are functionally equivalent to the Revolute5 constraint. In[16]:= Spherical3@1,
Point@ground, 80, 0, 0
The third constraint, Cylindrical4, could be modeled by using two PointOnLine2 constraints.
Here is the original Cylindrical4 constraint. Line@ground, 80, 4, 0<, 80, 9, 0
In[18]:= Cylindrical4@3,
Here are two constraints that are equivalent to the Cylindrical4 constraint. Point@piston, 80, 4, 0
In[19]:= PointOnLine2@3,
The RelativeDistance1 constraint in this application cannot be replaced by the use of any other constraint. It is somewhat unique, geometrically.
Chapter 2: Kinematic Modeling
53
This constraint has no functional equivalent. Point@crank, 83, 0, 0
In[21]:= RelativeDistance1@4,
2.3.4 The General Constraint The general constraint allows the user to enter a mathematical relationship directly as an equation.
Constraint[cnum, equation]
adds the equation or list of equations (which must each have the head Equal) to the constraint vector of the current model. Constraint controls as many degrees of freedom as the number of equations provided.
The general constraint function.
For example, to constrain the origin of body 2 to lie on a paraboloid surface in the global coordinate system with its axis in the Z direction and Z intercept at {0, 0, 4}, Constraint would be used as follows.
Here is a general mathematical constraint. In[22]:= Constraint@1, 3 X22 + 2 Y22 + 4 == Z2D Out[22]= SysCon@Constraint, 1, <>D
2.4 Building the Model Constraint objects are processed into a kinematic model with the SetConstraints function. The system of equations generated by SetConstraints is not returned to the user; it is stored in several variables in Mech’s private context. Thus only one mechanism model can be current in Mech at any given time. Several means of accessing and modifying the model are provided by Mech; these are discussed in the following section.
MechanicalSystems
54
2.4.1 SetConstraints SetConstraints is Mech’s core model building function. SetConstraints takes constraint objects that represent the physical interactions in the mechanism model and processes them into a system of kinematic equations.
SetConstraints[constraints, options]
accepts constraint objects and builds a mathematical system representing the mechanism model. constraints can be a list or sequence of constraints. Each of the constraints must be a constraint object with the head SysCon, such as are returned by all of the standard Mech constraint functions.
The core model-building function.
SetConstraints accepts options that determine how certain parts of the mathematical model are built.
SetGuess
is an option for SetConstraints that determines whether or not to reset all of the initial guesses when SetCon straints is run.
SetGuess → True
causes SetConstraints to reset all initial guesses to the values of the permanent initial guesses specified with SetBodies.
SetGuess → False
resets the initial guesses only if the current initial guesses are not sufficient to cover all of the dependent variables in the current model, otherwise it leaves the guesses unchanged.
SetGuess → False An option for SetConstraints.
is the default setting.
Chapter 2: Kinematic Modeling
55
2.4.2 Constraints The actual constraint expressions that are generated by SetConstraints can be extracted with Con straints. Constraints can be very useful for debugging a model because it is often possible to read the constraint expressions directly and relate them to the function of the model.
Constraints[cnum]
returns the list of constraint expressions generated by SetConstraints from constraint cnum. Each expression should evaluate to a number when all of the dependent variables in the current model are defined. Each expression is expected to evaluate to zero when the constraint is satisfied.
Constraints[{cnum, {enum}}]
returns expression enum in constraint cnum, in a multiple degree of freedom constraint.
Constraints[All]
returns the entire constraint vector. The length of the constraint vector is equal to the number of degrees of freedom in the current model.
Constraints function.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Consider the 2D crankshaft-piston model of Section 1.2. This model is built with various settings for the options for SetConstraints to show their affect on the resulting equations.
MechanicalSystems
56
Here is the crankshaft-piston model rebuilt. In[2]:= ground = 1;
crank = 2; piston = 3; crankangle =. cs@1D = Revolute2@1, Point@ground, 80., 0.
The first constraint cs[1] is a two degree of freedom constraint that constrains the origin of the crankshaft to lie at the global origin.
Here is the expression generated by the Revolute2 constraint. In[11]:= Constraints@1D Out[11]= 8−X2, −Y2<
Obviously, when these two expressions are driven to zero, the desired result is achieved, the coordinates of the local origin of the crankshaft {X2, Y2} are zero. The third constraint cs[3] is a two degree of freedom constraint that allows the piston to translate along a vertical axis, but constrains its rotation and its translation in the X direction.
Here is the expression generated by the Translate2 constraint. In[12]:= Constraints@3D
Out[12]= 810. Sin@Θ3D, 2. Cos@Θ3D HX3 − 4. Sin@Θ3DL − 2. H4. − Y3 − 4. Cos@Θ3DL Sin@Θ3D<
Chapter 2: Kinematic Modeling
57
The first expression, 10 Sin[Θ3], constrains the rotation of the piston; this expression can be equal to zero if Θ3 is any integer multiple of p. The reason that the solution Θ3 Ø 0 is found is because the default initial guess is Θ3 Ø 0. If a different initial guess were used, such as Θ3 Ø 3, the model would converge to Θ3 Ø N[π] instead. The second expression in the list constrains the X coordinate of the piston to be zero. Notice that at any value of Θ3 that satisfies the first expression, the second expression reduces to 2 X3 or −2 X3, either of which will drive X3 to zero.
2.4.3 Initial Guesses SetGuess serves both as an option for several Mech functions, and as a function for temporarily setting a model’s initial guesses.
SetGuess[{rules}]
sets new initial guesses for the current model. These guesses are used only for the very next solution attempt.
SetGuess
is an option for SetConstraints that specifies whether to reset the current initial guesses to the values specified with SetBodies.
SetGuess[]
resets the current initial guesses to the values of the permanent initial guesses specified in the SysBody objects passed to SetBodies.
SetBodies[Body[bnum, Initial Guess → guess]]
sets a new permanent initial guess for body bnum, and resets all of the current initial guesses to the permanent initial guess values.
Various methods of setting initial guesses.
MechanicalSystems
58
LastSolve[]
returns the values for the dependent variables that will be used as the next set of initial guesses. The value returned by LastSolve[] is determined by the last solution rule obtained by SolveMech, or the last set of guesses set with SetGuess.
A SolveMech utility.
To advance the position for the model in large steps, it is sometimes necessary to specify a better initial guess than the current one. For example, to turn the crankshaft 3/4 of a turn at once, it might be necessary to set a new initial guess for Θ2 and Y3, the angular coordinate of the crankshaft and the height of the piston, respectively. This runs the model at its initial position. In[13]:= crankangle = 0;
SolveMech@D
Out[14]= 8X2 → 0, Y2 → 0, Θ2 → 0, X3 → 0, Y3 → 0, Θ3 → 0<
This sets new guesses for Θ2 and Y3. In[15]:= SetGuess@8Θ2 → 5, Y3 → −2.5
Out[15]= 8X2 → 0, Y2 → 0, Θ2 → 5, X3 → 0, Y3 → −2.5, Θ3 → 0<
This runs the model at 3/4 turn of the crank. In[16]:= crankangle = 1.5 π;
SolveMech@D
Out[17]= 8X2 → 0., Y2 → 1.30956 × 10−23 , Θ2 → 4.71239, X3 → 0., Y3 → −2., Θ3 → 0.<
If SetConstraints were to be run at this time with the default options, the initial guesses would remain at their current values, Θ2 → 4.71 and Y3 → −2. The SetGuess option resets the guesses to their defaults. The SetGuess option resets the initial guesses. In[18]:= crankangle =.
SetConstraints@cs@1D, cs@2D, cs@3D, cs@4D, SetGuess → TrueD
Chapter 2: Kinematic Modeling
59
This shows the current guesses. In[20]:= LastSolve@D
Out[20]= 8X2 → 0, Y2 → 0, Θ2 → 0, X3 → 0, Y3 → 0, Θ3 → 0<
2.4.4 $MechProcessFunction $MechProcessFunction is a function that is applied to all of the mechanism equations that are generated by SetConstraints as they are created. The default setting, $MechProcessFunction = Chop, can reduce the size of the constraint expressions substantially if any of the constraints involve the local origins of bodies in the model which have local coordinates of 80, 0< or 80, 0, 0<. Setting $MechProcessFunc tion = Identity disables this action.
Set $MechProcessFunction equal to Identity to disable chopping. In[21]:= $MechProcessFunction = Identity;
Here the model is built without chopping the constraints. In[22]:= SetConstraints@cs@1D, cs@2D, cs@3D, cs@4DD
Here is the Revolute2 constraint. In[23]:= Constraints@1D
Out[23]= 80. − X2 + 0. Cos@Θ2D + 0. Sin@Θ2D, 0. − Y2 + 0. Cos@Θ2D + 0. Sin@Θ2D<
Obviously, the run time of the model is increased by increasing the size of the constraint expressions. However, if the model contains very small physical dimensions, it may not be acceptable to apply Chop to the constraints.
MechanicalSystems
60
2.4.5 SetSymbols The default symbols that appear in the solution rules returned by SolveMech can be changed with the SetSymbols function.
SetSymbols[options] SymbolBasis
sets the basis for the symbols that are created by Mech. is an option for SetSymbols that specifies the basis for the symbols that are hard-coded into the Mech model.
A model set-up function.
SymbolBasis Ø {"T", {"X", "Y"},
is the default setting for SymbolBasis in Modeler2D.
{"Ei", "Ej"}, "Θ", "Λ", "d"} SymbolBasis Ø {"T", {"X", "Y",
is the default setting for SymbolBasis in Modeler3D.
"Z"}, {"Eo", "Ei", "Ej", "Ek"}, {"Ωx", "Ωy", "Ωz"}, "Λ", "d"} Default settings.
Because SetSymbols changes the behavior of all Mech functions that return symbolic expressions, SetSym bols must be run before building any other part of the mechanism model with SetBodies or SetCon straints. SetSymbols has the effect of executing ClearMech[]. The Ωx, Ωy, and Ωz symbols are used by Modeler3D to represent angular velocities used in 3D velocity analysis, which is discussed in Chapter 4. The Λ symbol is a Lagrange multiplier used in static and dynamic analysis, which is discussed in Chapter 7. The d symbol is used in 2D and 3D velocity analysis to symbolically represent differentiation. If the current model is rebuilt with a new setting for SymbolBasis, the solution rules returned by Solve Mech are changed accordingly.
This causes new symbols to be used in all subsequent models. SymbolBasis → 8"Tm", 8"Xcoord", "Ycoord"<, 8"Ei", "Ej"<, "Theta", "Lambda", "d"
In[24]:= SetSymbols@
Chapter 2: Kinematic Modeling
61
The model is rebuilt with SetConstraints. In[25]:= crankangle =.
SetConstraints@cs@1D, cs@2D, cs@3D, cs@4DD
This runs the model at crankangle = 0.5. In[27]:= crankangle = .5;
SolveMech@D
Out[28]= 8Xcoord2 → 0., Ycoord2 → 0., Theta2 → 0.5, Xcoord3 → 0., Ycoord3 → 1.689, Theta3 → 0.<
This returns MechanicalSystems to its initial state. In[29]:= ClearMech@AllD
2.5 Running the Model This section covers the use of the SolveMech command, which is used to seek a solution to the mechanism model. The Mech commands covered in the previous sections were all concerned with building a mechanism model. SolveMech is the sole function for running the model.
2.5.1 SolveMech The SolveMech command is used without arguments to seek a single solution to the mechanism model, with all of the current values of any user-defined variables in the model. When SolveMech seeks a solution, what it is really trying to do is numerically find the location and orientation of each of the bodies in the model at which all of the constraints are satisfied.
SolveMech[] Mech’s runtime command.
seeks a solution to the current mechanism model.
MechanicalSystems
62
Time Dependence Most mechanism models have some dependency on time that is specified (by default) by the symbol T. When T appears in a mechanism model, the model’s location becomes explicitly a function of time, a technique that must be used in the velocity and acceleration portions of the analysis. It is not necessary to have any dependency on T in a model used only for location analysis, but it is customary to make the primary driving expression a function of T anyway.
T
is a special symbol that represents time in a Mech model. Another symbol can be substituted for T with the SymbolBasis option.
The symbol for time.
SolveMech has several special invocations that are useful for finding a solution or many solutions at a range of values of T.
SolveMech[time]
seeks a solution to the mechanism model with the specified numerical value of time.
SolveMech[{t1, t2, …, tn}]
seeks n solutions to the mechanism model with n specified values of time ti. A nested list of solution rules is returned.
SolveMech[{t1, t2, …, tn}, m]
seeks m solutions to the mechanism model. The solution points include all of the specified times ti as well as m minus n more points in time evenly dispersed throughout the ti.
More arguments for SolveMech.
The 2D crankshaft-piston model is used to demonstrate the various forms of SolveMech. When this example was first used in Section 1.2, the symbol crankangle was used to specify the rotation of the crankshaft. Now crankangle is replaced with 2 π t so that the rotation of the crankshaft is a function of time. Thus, the crankshaft has an angular velocity of one revolution per second.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Chapter 2: Kinematic Modeling
63
Here is the crankshaft-piston model with a time-dependent driver. In[2]:= ground = 1;
crank = 2; piston = 3; SetConstraints@ Revolute2@1, Point@ground, 80., 0.
Now, instead of changing the value of crankangle to drive the model the value of time is changed directly with SolveMech. This runs the model at 1/10 turn of the crankshaft. In[6]:= [email protected]
Out[6]= 8T → 0.1, X2 → −1.39599 × 10−21 , Y2 → 2.06126 × 10−22 ,
Θ2 → 0.628319, X3 → 0., Y3 → 2.13479, Θ3 → 0.<
This seeks 3 solutions from 0 to 0.5 turns, inclusive. In[7]:= SolveMech@80, .5<, 3D
Out[7]= 88T → 0., X2 → 2.98079 × 10−22 ,
Y2 → 2.06126 × 10−22 , Θ2 → 0., X3 → 0., Y3 → 1.56175 × 10−12 , Θ3 → 0.<, 8T → 0.25, X2 → 0., Y2 → 1.81055 × 10−26 , Θ2 → 1.5708, X3 → 0., Y3 → 4., Θ3 → 0.<, 8T → 0.5, X2 → 0., Y2 → −9.23845 × 10−33 , Θ2 → 3.14159, X3 → 0., Y3 → 4.57465 × 10−15 , Θ3 → 0.<<
The unusual form of the iteration specifier in SolveMech is very useful if an even spread of data is desired, with a few particular data points specified in between. For example, the following example generates six solution points with the points T = 0., 0.223, and 0.3 included, and the other three points spread so as to fill the gaps as evenly as possible.
MechanicalSystems
64
This seeks 6 solution points, including T = 0.223
In[8]:= First ê@ SolveMech@80, .223, .3<, 6D
Out[8]= 8T → 0., T → 0.0743333, T → 0.148667, T → 0.223, T → 0.2615, T → 0.3<
Initial Guesses at Runtime
SolveMech[{rules}]
seeks a solution to the mechanism model, taking the value of time, and the values of all the initial guesses from rules.
SolveMech[{{rules1}, {rules2}, ...}]
seeks solutions as specified by each of the rulesi, and returns a nested list of solutions.
Setting initial guesses with SolveMech.
The primary reason for passing rules into SolveMech, instead of just specifying the value of time, is to accelerate the solution process. The supplied rules may be known to be very good initial guesses, such as rules obtained from a prior run with a slightly different value for a parameter. This calls SolveMech with a list of guesses. The value of time T = 0.2 is pulled from the guesses. In[9]:= SolveMech@8T → .2, X2 → 0, Y2 → 0, Θ2 → 1.2, X3 → 0, Y3 → 3, Θ3 → 0
Θ2 → 1.25664, X3 → 0., Y3 → 3.76648, Θ3 → 0.<
2.5.2 Controlling SolveMech The nonlinear equation solver used by SolveMech can be controlled by setting the values of several options. Many of these options are the same as those used by FindRoot, although SolveMech does not utilize FindRoot.
Chapter 2: Kinematic Modeling
65
DampingFactor
is an option for SolveMech as well as other built-in Mathematica functions. DampingFactor → n uses a damping factor of n in the Newton’s method solver. The default setting is DampingFactor → 1.
MaxIterations
is an option for SolveMech and other Mathematica functions. With MaxIterations → n, a maximum of n iterations are used to seek a solution to the model. The default setting is MaxIterations → 15.
ZeroTest
is an option for SolveMech that specifies a function that is applied to each constraint expressions at each iteration, to see if the model has converged. ZeroTest[number] should return True if the number is sufficiently close to zero. The default setting is ZeroTest → (Abs[#] < 10^-9 &).
Options for SolveMech.
The operation of SolveMech can be inspected by the use of two hook functions that are called during the execution of SolveMech. Note that all Mech system variables that can be set by the user have names of the form "$Mech*".
$MechPostIterate
is a function that is applied to the iteration counter at each iteration. Setting $MechPostIterate = Print causes the iteration counter to be printed at each iteration. The default definition is $MechPostIterate =.
$MechPreSolve
is a function that is applied to the numerical value of time before each solution attempt. $MechPreSolve can be used to automatically set initial guesses at each solution point, or to print the value of time that SolveMech is currently working on. The default definition is $MechPreSolve =.
Controls for SolveMech.
MechanicalSystems
66
Failure to Converge The default setting for ZeroTest will suffice for many models, but may need to be changed for several reasons. If the numerical size of the dimensions of the model are very large or small, ZeroTest may need to be changed accordingly. For example, if a typical point in the model is Point[2, {3400, -7800}], it might be necessary to specify ZeroTest → (Abs[#] < 10^-6 &). If the model is large (eight or more bodies for 2D, four or more for 3D) solving the linear equations at each iteration begins to suffer from numerical error. Thus, it may be necessary to lower the convergence criteria. The primary indication that the convergence criteria must be changed is that SolveMech returns a valid solution that is apparently correct, but an error message is generated claiming that convergence has failed after n iterations. If the model fails to converge and returns a solution that is obviously not valid, try to find an inconsistency in the constraint set or consult Chapter 13, Debugging Models.
2.5.3 Nonlinear Equation Solver At the core of Mech’s numerical solution block is a Newton-Rhapson simultaneous nonlinear equation solver, similar to the built-in Mathematica function FindRoot. In fact, Mech can be used to solve arbitrary systems of equations that have no relation to mechanism analysis. Mech’s general constraint function Constraint is used to build a constraint object from an arbitrary algebraic equation. The algebraic constraint can be incorporated into a mechanism model along with other geometric constraints, or an entire model can be built from general constraints.
Constraint[cnum, equation, {symbol, guess}]
returns a SysCon constraint object that can be used to add equation to the model’s constraint vector. The symbol is added to the vector of dependent variables in the model, with the associated initial guess. Constraint controls as many degrees of freedom as the number of equations provided.
The general constraint function.
Chapter 2: Kinematic Modeling
67
The following uses Mech to find the intersection of a parabola and a circle.
This prevents impending spelling errors. In[10]:= Off@General::"spell1"D
xvar; yvar; On@General::"spell1"D
This builds the nonmechanical model. In[13]:= SetConstraints@
Constraint@1, yvar == xvar2 − 1, 8yvar, 1
This plots the two functions, showing their intersection.
In[14]:= Plot@8xvar2 − 1, 2 + 3 xvar<, 8xvar, −1.5, 4.5
15
10
5
-1
1
2
This seeks a solution to the two equations. In[15]:= SolveMech@D Out[15]= 9yvar → −
22658 47956 , xvar → − = 60605 60605
3
4
MechanicalSystems
68
This looks for the other solution. In[16]:= SolveMech@8yvar → 10, xvar → 4
810523 229771 , xvar → = 60605 60605
2.6 Variable Management Mechanism models often need to have many adjustable parameters that can be tweaked between runs of the model. A Mech model may have any number of user-defined variables, provided that all such variables in a model have numerical values before SolveMech is called.
2.6.1 User-Defined Variables This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Symbolic parameters can enter a kinematic model in two ways. The coordinates of a local point can be given in symbolic form or the arguments of a constraint function that specify a distance or angle can be given as a symbolic expression. The following example shows how local point specifications can be symbolic.
This prevents impending spell check warnings. In[2]:= Off@General::"spell1"D
xaxis; yaxis; angle; On@General::"spell1"D All local coordinates can be specified symbolically. In[5]:= Clear@xaxis, yaxis, radius, angleD
Point@2, 8xaxis, yaxis
Chapter 2: Kinematic Modeling
69
The crankshaft-piston model can be built with several variables in the arguments to its constraint functions. The following example introduces symbols into the model to represent the frequency of the crankshaft rotation, the length of the connecting rod, and the stroke of the crankshaft.
Here are the crankshaft-piston body objects, with a symbol included in the points list. In[9]:= Clear@strokeD
ground = 1; crank = 2; piston = 3; bd@groundD = Body@ground, PointList → 880, 0<, 80, 4<, 80, 9<
This builds the constraint equations with two symbols embedded. In[17]:= Clear@crankfreq, rodlengthD
SetConstraints@ Revolute2@1, Point@ground, 1D, Point@crank, 1DD, RotationLock1@2, crank, 2. π crankfreq TD, Translate2@3, Line@ground, 2, 3D, Line@piston, 2, 3DD, RelativeDistance1@4, Point@crank, 2D, Point@piston, 2D, rodlengthDD
If SolveMech is called now to seek a solution, an error message is generated because some of the symbols in the model have not yet been defined.
This attempts to find a solution. In[19]:= SolveMech@0D
SolveMech::undef : SolveMech called with undefined variables present.
Out[19]= 8T → 0, X2 → 0, Y2 → 0, Θ2 → 0, X3 → 0, Y3 → 0, Θ3 → 0<
Use CheckSystem.
MechanicalSystems
70
CheckSystem[]
checks the model for errors such as stray variables or redundant constraints. CheckSystem returns False if any errors are found, and generates a message describing the error.
A debugging aid.
CheckSystem reports the names of any undefined symbols, as well as several other possible errors in the model.
This checks the integrity of the model. In[20]:= CheckSystem@D
CheckSystem::undef : The current system contains the following undefined Symbols: 8crankfreq, rodlength, stroke< Out[20]= False
This defines the undefined symbols, checks the model, and runs it. In[21]:= crankfreq = 2;
stroke = 5.5; rodlength = 4.1; CheckSystem@D SolveMech@0D Out[24]= True
Out[25]= 8T → 0, X2 → 0., Y2 → 0., Θ2 → 0., X3 → 0., Y3 → −0.95903, Θ3 → 0.<
Dependent Variables It is acceptable to use Mech dependent variables explicitly when defining local points or constraints. Highly abstract compound constraints can be specified in this manner.
This is an extremely obtuse constraint.
In[26]:= RelativeY1@1, Point@2, 81, 0
Chapter 2: Kinematic Modeling
71
This constraint would cause the Y coordinate of a point on body 2 to be equal to the X coordinate of the origin of body 3, squared. When using dependent variables in constraints, care must be taken to ensure that the dependence of the constraint on the variables is explicit at the time that SetConstraints is run. If not, differentiation with respect to those variables cannot occur, and the constraints will not be processed correctly. Note that the names of the dependent variables used by Mech are cleared and protected when SetCon straints is run. Thus, if there happens to be a definition in place such as Y2 = 3, it is removed by SetConstraints.
2.6.2 Parameters Another method of managing variables in a Mech model is to use the parameters functions. The parameters list is basically a list of rules stored in Mech’s internal database that is applied to the mechanism model immediately before the solution phase. By using parameters, problems can be avoided such as failing to define all of the symbols in a model or accidentally defining them before SetConstraints is run and hard coding them into the model.
SetParameters[{symbol Ø number... }] ClearParameters[{symbols}] Parameters[]
adds symbols with numerical values to the parameters list and protects symbols. clears symbols from the parameters list. returns a list of rules showing the values of all of the currently defined parameters.
Parameterize[defsyms]
accepts defined symbols defsyms, unsets them, and adds them to the parameters list with the numerical values of their previous definitions.
Parameter management functions.
Note that when a parameter is set with SetParameters or Parameterize, it is protected until it is unset with ClearParameters. This is to ensure that the parameter cannot be accidentally given a definition in the course of running the model. The crankshaft-piston model, which was built in Section 2.6.1, is used to demonstrate the use of parameters. The definitions of the three symbols in the model are cleared and then added to the parameters list.
MechanicalSystems
72
This adds three symbols to the parameters list. In[27]:= Clear@crankfreq, stroke, rodlengthD;
SetParameters@8crankfreq → 2, stroke → 5.5, rodlength → 4.1
Out[28]= 8crankfreq → 2, rodlength → 4.1, stroke → 5.5<
The crankshaft-piston model can now be built without worrying about the definitions of the parameters. SetParameters can be used at any time in the model-building process.
Here the crankshaft-piston model is rebuilt with reference to the body objects previously defined. In[29]:= SetConstraints@
Revolute2@1, Point@ground, 1D, Point@crank, 1DD, RotationLock1@2, crank, 2. π crankfreq TD, Translate2@3, Line@ground, 2, 3D, Line@piston, 2, 3DD, RelativeDistance1@4, Point@crank, 2D, Point@piston, 2D, rodlengthDD
The parameters are included in the solution rules returned by SolveMech. In[30]:= [email protected]
Out[30]= 8T → 0.1, crankfreq → 2, rodlength → 4.1, stroke → 5.5, X2 → 3.90937 × 10−22 ,
Y2 → −4.24407 × 10−23 , Θ2 → 1.25664, X3 → 0., Y3 → 2.62637, Θ3 → 0.<
Set a new value for crankfreq. Only the specified value is updated, the others are left unchanged. In[31]:= SetParameters@8crankfreq → 3
Out[31]= 8crankfreq → 3, rodlength → 4.1, stroke → 5.5<
Chapter 2: Kinematic Modeling
The parameters are protected. In[32]:= rodlength = 4;
Set::wrsym : Symbol rodlength is Protected. More…
This removes all of the parameters from the parameters list. In[33]:= ClearParameters@AllD Out[33]= 8<
73
3. Output Functions Overview This chapter covers MechanicalSystems’ numerical and graphical output functions. In general, Mech’s output functions are used to convert the symbolic coordinates that define the location and orientation of each body into more specialized quantities, such as the distance between two points or the angle between two lines. Graphical output functions use the symbolic coordinates to locate graphics primitives to reflect the location of the bodies in the model. Throughout this chapter, Mech output functions are used as supplements to, not replacements for, built-in Mathematica functions. Most output from Mech is generated through a mixture of both.
3.1 2D Output Functions Numerical output from a Modeler2D model can be generated with output functions that are defined in the auxiliary package Graphics2D. This package is autoloaded after the Modeler2D main package has been loaded if any of the output functions are called. Each output function returns a symbolic expression that represents the quantity being sought, in terms of the model’s dependent variables, X2, Y3, and so on. To achieve a numerical result, the dependent variables must be replaced with numbers, usually by applying a solution rule returned by SolveMech. More complicated and specific output functions can easily be defined by the user, making use of Mech’s basic output functions and Mathematica’s built-in vector algebra functions.
MechanicalSystems
76
3.1.1 Example Mechanism To demonstrate the use of Modeler2D output functions, a 2D model is developed that can have various geometric quantities measured. The model is a planar quick-return mechanism consisting of three moving bodies: the crank, drive arm, and slider. A real quick-return mechanism would have a fourth body, the connecting rod between the drive arm and the slider, but this body is simply modeled with a relative-distance constraint. The motion of the quick-return mechanism is driven by the rotation of the crank that, in turn, forces the drive arm to rock about its lower pivot point on the ground, via a pin on the crank that slides in a straight slot on the drive arm. The top of the drive arm is attached to a connecting rod, which is attached to the slider, which slides on horizontal path on the ground.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Here is a graphic of the 2D quick-return model.
Chapter 3: Output Functions
77
Bodies Four body objects are defined for the quick-return mechanism model. • The ground (body 1) requires four point definitions. P1 is the rotational axis of the drive arm. P2 is the rotational axis of the crank. P3 and P4 are two points that define the line upon which the slider slides. • The crank (body 2) requires two local point definitions. P1 is the crank’s rotational axis. P2 is the location of the pin on the crank that engages with the drive arm. • The drive arm (body 3) requires two local point definitions. P1 is the point on the drive arm where the drive arm pivots with respect to the ground. P2 is the point where the drive arm is attached to the pseudo-connecting rod. • The slider (body 4) requires two local point definitions. P1 and P2 are two points along the horizontal axis of the slider define its translation line. Here are the bodies in the quick-return model. {-5,10}
{12,10}
P3
P4 P1 P2
{0,5}
P2
Ground
Crank {0,0} {3,0}
P1 {0 0} P1
P2
{0,0} {3,0} {0,9}
P2
Slider
Drive Arm
{0,0}
P1
Names are defined for each of the body numbers in the mechanism. In[2]:= ground = 1;
crank = 2; drivearm = 3; slider = 4;
MechanicalSystems
78
Body objects are defined for each body. In[6]:= bd@groundD = Body@ground,
PointList → 880, 0<, 80, 5<, 8−5, 10<, 812, 10<
This incorporates the body properties into the current model. In[10]:= SetBodies@Array@bd, 4DD
Constraints Five constraints and one driving constraint are required to model the quick-return mechanism. • A Revolute2 constraint forces the axis of the crank to be coincident with its pivot point on the ground. This constrains two degrees of freedom, X and Y displacement of the crank axis. • A RotationLock1 constraint specifies the angular coordinate of the crank. This driving constraint is used to rotate the crank. • A Revolute2 constraint forces the lower pivot point of the drive arm to be coincident with the global origin. The drive arm can pivot about this point on the ground. • A PointOnLine1 constraint between the crank and the drive arm where the pin on the crank slides in a slot on the drive arm. • A RelativeDistance1 constraint between the drive arm and the slider replaces the pseudo-connecting rod, which is 5.0 units long. • A Translate2 constraint between the slider and the ground allows the slider to translate horizontally along a track on the ground.
Chapter 3: Output Functions
Here are five constraints for the quick-return model. In[11]:= cs@1D = Revolute2@1,
Point@ground, 2D, Point@crank, 1DD; cs@2D = RotationLock1@2, crank, 2. π TD; cs@3D = Revolute2@3, Point@ground, 1D, Point@drivearm, 1DD; cs@4D = PointOnLine1@4, Point@crank, 2D, Line@drivearm, 1, 2DD; cs@5D = RelativeDistance1@5, Point@drivearm, 2D, Point@slider, 1D, 5.0D; cs@6D = Translate2@6, Line@ground, 3, 4D, Line@slider, 1, 2DD;
This incorporates the constraints into the current model. In[17]:= SetConstraints@Array@cs, 6DD
Runtime This runs the model at T = 0.15 In[18]:= [email protected]
Out[18]= 8T → 0.15, X2 → 2.09657 × 10−32 , Y2 → 5., Θ2 → 0.942478,
X3 → 0., Y3 → 0., Θ3 → −0.233107, X4 → 6.92194, Y4 → 10., Θ4 → 0.<
79
MechanicalSystems
80
Here is the quick-return mechanism at T = 0.15.
3.1.2 Output Functions Modeler2D numerical output functions return expressions that evaluate to numbers or vectors, such as the distance between two points, the angle between two lines, or the coordinates of a point. These functions take point, vector, and axis objects as arguments, identical in structure to the geometry objects used when building constraints. When local point numbers are used, the local coordinates are taken from the current body objects, as specified with SetBodies. Each of the output functions are demonstrated in the context of the quick-return mechanism model defined in Section 3.1.1.
Chapter 3: Output Functions
81
Location[point]
returns the global coordinates {X, Y} of point.
Location[bnum]
returns the dependent variables associated with body bnum. If the current solution method setting is Angular (the default) Location returns the list {X, Y, Q} representing the origin location and rotation angle of the body. If the current solution method setting is Euler, Location returns {X, Y, Ei, Ej}.
Distance[point1, point2] Angle[vector]
returns the distance between the two points. returns the direction angle of vector, with respect to the global X axis.
Rotation[bnum] EulerParameters[bnum]
returns the global rotation angle of body bnum. returns the list of 2D Euler parameters {Ei, Ej} associated with body bnum.
EulerParameters[{ang}]
returns the list of 2D Euler parameters {Ei, Ej} = {Cos[ang], Sin[ang]}.
Output functions.
IncludedAngle[vector1, vector2]
returns the positive angle between the two vectors.
IntersectionPoint[axis1, axis2]
returns the point of intersection of the two axes.
PointToLineDistance[point, axis]
returns the distance from point to axis, measured perpendicular to axis.
ProjectOnLine[vector1, vector2]
returns the component of vector1 that is in the direction of vector2.
ProjectOnLine[point, axis]
returns the coordinates of point orthogonally projected onto axis.
More complex output functions.
MechanicalSystems
82
The Location function is used to convert a Mech Point object into the global coordinates of the point.
Here are the global coordinates of point 2 on the drive arm. In[19]:= Location@Point@drivearm, 2DD
Out[19]= 8X3 − 9 Sin@Θ3D, Y3 + 9 Cos@Θ3D<
Location assumes a point object if only the arguments of Point are given. In[20]:= Location@drivearm, 2D
Out[20]= 8X3 − 9 Sin@Θ3D, Y3 + 9 Cos@Θ3D<
This gets a numerical result from the output of Location.
In[21]:= % ê. [email protected]
%% ê. [email protected]
Out[21]= 8−1.05511, 8.93794< Out[22]= 8−3.03987, 8.47108<
The Distance function is used to find the absolute distance between any two points in space. The points can be on one body or on two different bodies. Here is the distance from the center of the crank to point 2 on the slider. In[23]:= Distance@Point@crank, 1D, Point@slider, 2DD Out[23]=
"#################################################################################################################### H−X2 + X4 + 3 Cos@Θ4DL2 + H−Y2 + Y4 + 3 Sin@Θ4DL2#
Here is the numerical result.
In[24]:= % ê. [email protected], .2
Chapter 3: Output Functions
83
Here is the length of the line from the center of the crank to the drive pin. In[25]:= Distance@Point@crank, 1D, Point@crank, 2DD Out[25]= 3
Note that it was not necessary to apply a solution rule to the last example to get a numerical result because the dimension being measured is not a function of the coordinates of each body.
Here is the minimum distance between the crank axis and the center line of the drive arm. In[26]:= PointToLineDistance@Point@crank, 1D, Line@drivearm, 1, 2DD Out[26]= H−X2 + X3L Cos@Θ3D − HY2 − Y3L Sin@Θ3D
Now get a numerical result.
In[27]:= % ê. [email protected], .25
Note that the distance is zero when the crank has turned 1/4 turn, and the drive arm is pointed straight up, through the axis of the crank.
Here is the direction angle of the center line of the connecting rod. In[28]:= Angle@Line@drivearm, 2, slider, 1DD Out[28]= ArcTan@−X3 + X4 + 9 Sin@Θ3D, −Y3 + Y4 − 9 Cos@Θ3DD
Now get a numerical result in degrees. In[29]:=
% ê. [email protected] N@DegreeD
Out[29]= 12.2638
MechanicalSystems
84
The Rotation function simply returns the angular coordinate of the specified body. Here is theta of the drive arm. In[30]:= Rotation@drivearmD Out[30]= Θ3
This returns the intersection of the connecting rod axis and a vertical line through the crank axis. In[31]:= IntersectionPoint@
Line@drivearm, 2, slider, 1D, Line@ground, 0, 80, 1
Out[31]= 80., 9.16729<
The ProjectOnLine function is used to find the projection of a point on one body onto a line located on another body (or bodies). This projects the crank’s drive pin onto the connecting rod. In[32]:= ProjectOnLine@
Point@crank, 2D, Line@drivearm, 2, slider, 1DD ê. LastSolve@D
Out[32]= 8−1.15799, 8.91557<
3.1.3 Vector Algebra Functions Modeler2D vector algebra functions perform many common vector algebra operations such as cross and dot products of vectors. These functions can be used to build more complicated functions that are not provided by Modeler2D. The output functions take point, vector, and axis objects as arguments, identical in structure to the geometry objects used when building constraint objects. When local point numbers are used, the local coordinates are taken from the current body objects, as specified with SetBodies. Each of the vector algebra functions are demonstrated in the context of the quick-return mechanism model defined at the beginning of this section.
Chapter 3: Output Functions
85
Direction[vector]
returns the global direction vector of the given vector.
Magnitude[vector]
returns the magnitude or length of vector.
Unit[vector] Cross[vector1, vector2] RotationMatrix[{ang}]
returns a unit vector in the direction of vector. returns the cross product of the vectori. returns the 2D rotation matrix associated with ang {{Cos[ang], -Sin[ang]}, {Sin[ang], Cos[ang]}}.
RotationMatrix[bnum]
returns the rotation matrix associated with body bnum. Note that RotationMatrix differentiates between ang and bnum by assuming that bnum is an integer.
PointToLocal[bnum, point] VectorToLocal[bnum, vector]
returns the local coordinates of point relative to body bnum. returns the local direction vector of vector relative to body bnum.
Vector algebra functions.
The Direction function is used to convert Modeler2D vector objects into 2D vectors in global coordinates. Note that Mech’s definition of Direction does not interfere with its use as a built-in Mathematica symbol.
Here is the direction vector of the connecting rod. In[33]:= Direction@Line@drivearm, 2, slider, 1DD
Out[33]= 8−X3 + X4 + 9 Sin@Θ3D, −Y3 + Y4 − 9 Cos@Θ3D<
Now get a numerical result.
In[34]:= % ê. [email protected] Out[34]= 84.62876, 1.89067<
Several Modeler2D output functions are textbook vector algebra functions that are capable of dealing with normal 2D vectors or Modeler2D line objects interchangeably.
MechanicalSystems
86
Magnitude can return the length of the line from one end of the connecting rod to the other.
In[35]:= Magnitude@Line@drivearm, 2, slider, 1DD ê. LastSolve@D Out[35]= 5.
Magnitude also works with simple vectors. In[36]:= Magnitude@89, 12
Unit also works with vectors or line objects. In[37]:= Unit@83, 5
Out[37]= 9 è!!!!!!! , è!!!!!!! =
3 34
5 34
The cross product of two vectors in 2D space is a scalar.
In[38]:= Line@drivearm, 2, slider, 1D 80, 3< Out[38]= 3 H−X3 + X4 + 9 Sin@Θ3DL
Now get a numerical result.
In[39]:= % ê. [email protected] Out[39]= 13.3458
Here is a 2D rotation matrix that will rotate a vector on the slider into global coordinates. In[40]:= RotationMatrix@sliderD
Out[40]= 88Cos@Θ4D, −Sin@Θ4D<, 8Sin@Θ4D, Cos@Θ4D<<
The global coordinates of a point specified in a local reference frame are equal to the coordinates of the origin of the reference frame plus the local coordinates of the point, rotated into the global reference frame.
Chapter 3: Output Functions
87
Here is a calculation of the global coordinates of the local point {3, 8} on the slider. In[41]:= Location@slider, 0D + [email protected], 8< Out[41]= 8X4 + 3 Cos@Θ4D − 8 Sin@Θ4D, Y4 + 8 Cos@Θ4D + 3 Sin@Θ4D<
The Location function performs effectively the same calculation, directly.
In[42]:= Location@slider, 83, 8
Out[42]= 8X4 + 3 Cos@Θ4D − 8 Sin@Θ4D, Y4 + 8 Cos@Θ4D + 3 Sin@Θ4D<
Now get a numerical result.
In[43]:= % ê. LastSolve@D Out[43]= 82.81812, 18.<
The PointToLocal function converts the global point back to local coordinates.
In[44]:= PointToLocal@slider, %D ê. LastSolve@D Out[44]= 83., 8.<
Two constant matrices that are commonly used in 2D vector algebra are also defined by Modeler2D.
RMatrix
returns the 2D orthogonal rotation matrix {{0, -1}, {1, 0}} that rotates a vector pi/2 in the counterclockwise sense.
IMatrix
returns the 2D identity matrix {{1, 0}, {0, 1}}.
Constant utilities.
Coordinate Conversions PolarToXY and XYToPolar are two conversion functions that do not accept Modeler2D geometry objects as arguments. These functions only accept 2D vectors of the form {x, y}.
MechanicalSystems
88
PolarToXY[{radius, angle}]
returns the Cartesian coordinates of a point specified in polar coordinates by radius and angle.
XYToPolar[{x, y}]
returns the polar coordinates of a point specified in Cartesian coordinates by x and y.
Coordinate conversions.
This converts a polar coordinate pair to Cartesian coordinates. In[45]:= PolarToXYA94, Out[45]= 82, 2
è!!!! 3<
π 3
=E
This converts it back. In[46]:= XYToPolar@%D Out[46]= 94,
π = 3
This converts a 2D vector to polar coordinates.
In[47]:= XYToPolar@Location@slider, 2DD ê. LastSolve@D Out[47]= 810.3895, 1.29611<
3.2 3D Output Functions Numerical output from a Modeler3D model can be generated with output functions that are defined in the auxiliary package Graphics3D. This package is autoloaded after the Modeler3D main package has been loaded if any of the output functions are called. Each output function returns a symbolic expression that represents the quantity being sought, in terms of the model’s dependent variables X2, Z3, Ei4, and so on. To achieve a numerical result, the dependent variables must be replaced with numbers, typically by applying a solution rule returned by SolveMech. More complicated and specific output functions can easily be defined by the user, making use of Mech’s basic output functions and Mathematica’s built-in vector algebra functions.
Chapter 3: Output Functions
89
3.2.1 Example Mechanism To demonstrate the use of Modeler3D output functions, a 3D model is developed that can be measured. The model is a spatial slider-crank mechanism consisting of two moving bodies, the crank and the slider. A real slider-crank mechanism would have a fourth body, the connecting rod between the crank and the slider. The motion of the slider-crank mechanism is driven by the rotation of the crank, which forces the slider to reciprocate in a straight track that is parallel to the axis of the crank. The crank is attached to the slider via a connecting rod that is modeled by a distance constraint.
This loads the Modeler3D package. In[1]:= Needs@"MechanicalSystems`Modeler3D`"D
Here is a graphic of the complete 3D slider-crank model.
MechanicalSystems
90
Bodies Three body objects are defined for the slider-crank mechanism model. Note that the zeroth point is used in this model to avoid repeatedly defining a point at coordinates {0, 0, 0}. • The ground (body 1) has four points defined in its body object. P1 and P2 are two points to define the rotational axis of the crank. P3 and P4 are two points that are used in conjunction with the origin of the ground body to define the translation axis and reference direction of the slider. P4 is also used with the local origin to define a reference direction for the crank’s rotation. • The crank (body 2) has two points defined in its body object. P1 is a point that is used with the crank’s local origin to define its rotational axis. P2 is the attachment point of the connecting rod, and also a reference for the crank’s rotation. • The slider (body 3) has two points defined in its body object. P0 is the attachment point of the connecting rod on the slider. P1 is used with the slider’s local origin to define its translation axis. P2 is used with the slider’s local origin to define a reference direction for the translational joint. Here are all the bodies in the slider-crank model.
z {0,10,12} P1 z
Ground P2 {10,10,12}
2
y P2 {0,8,0} x P1 {8,0,0}
y 1
x
Crank
Slider
z
3
y x
Connecting Rod
Chapter 3: Output Functions
Here are names for each of the body numbers in the model. In[2]:= ground = 1;
crank = 2; slider = 3;
Here are body objects for each body. In[5]:= bd@groundD = Body@ground,
PointList → 880, 10, 12<, 810, 10, 12<, 81, 0, 0<, 80, 1, 0<
This incorporates the body properties into the current model. In[8]:= SetBodies@Array@bd, 3DD
Constraints Four constraints are used to model the slider-crank mechanism. • A Revolute5 constraint forces the axis of the crank to be coincident with its pivot axis on the ground. This leaves only one degree of freedom for the crank, rotation about its axis. • A ProjectedAngle1 constraint specifies the angular relationship between a line on the ground body and a line on the crank. This driving constraint is used to rotate the crank. • A RelativeDistance1 constraint between the crank and the slider replaces the pseudo-connecting rod, which is 30 units long. • A Translate5 constraint between the slider and the ground leaves only one degree of freedom for the slider; horizontal translation along a track on the ground body. This constraint references two Modeler3D Axis objects that are constrained to be parallel and coincident, and the reference directions of the two axes are constrained to be coplanar.
91
MechanicalSystems
92
Here are the constraints for the slider-crank model. In[9]:= cs@1D = Revolute5@1,
Line@ground, 1, 2D, Line@crank, 0, 1DD; cs@2D = ProjectedAngle1@2, Line@crank, 0, 2D, Line@ground, 0, 4D, Line@ground, 0, 3D, 2. π TD; cs@3D = RelativeDistance1@3, Point@crank, 2D, Point@slider, 0D, 30.0D; cs@4D = Translate5@4, Axis@ground, 0, 3, 4D, Axis@slider, 0, 1, 2DD;
This incorporates the constraints into the current model. In[13]:= SetConstraints@Array@cs, 4DD
Runtime Now run the model at T = 0.05. In[14]:= [email protected]
Out[14]= 8T → 0.05, X2 → 4.76939 × 10−23 , Y2 → 10., Z2 → 12., Eo2 → 0.987688, Ei2 → 0.156434,
Ej2 → 0., Ek2 → 0., X3 → 19.5064, Y3 → 0., Z3 → 0., Eo3 → 1., Ei3 → 0., Ej3 → 0., Ek3 → 0.<
Chapter 3: Output Functions
93
Here is the slider-crank model at T = 0.05.
3.2.2 Output Functions Modeler3D numerical output functions return expressions that evaluate to numbers or vectors, such as the distance between two points, the angle between two lines, or the coordinates of a point. These functions take Modeler3D point, vector, and axis objects as arguments, identical in structure to the geometry objects used when building constraints. When local point numbers are used, the local coordinates are taken from the current body objects, as specified with SetBodies. Each of the output functions is demonstrated in the context of the quick-return mechanism model defined in Section 3.2.1.
MechanicalSystems
94
Location[point]
returns the global coordinates {X, Y, Z} of point.
Location[bnum]
returns {X, Y, Z, Eo, Ei, Ej, Ek} specifying the global location and orientation of body bnum.
Distance[point1, point2] Rotation[bnum]
returns the distance between the two points. returns the list {ang, {X, Y, Z}} associated with body bnum. The angle and axis imply that body bnum has been rotated ang radians about the specified axis, with respect to the global coordinate system.
VirtualRotation[bnum]
returns the virtual rotation vector {X, Y, Z} associated with body bnum. The angle of rotation of the body is equal to the magnitude of {X, Y, Z}.
EulerParameters[bnum]
returns the list of Euler parameters {Eo, Ei, Ej, Ek} associated with body bnum.
EulerParameters[{ang, vector}]
returns the list of Euler parameters {Eo, Ei, Ej, Ek} associated with a rotation of ang radians about vector.
IncludedAngle[vector1, vector2] IntersectionPoint[axis1, axis2]
returns the positive angle between the two vectori. returns the point of intersection of axis1 and a plane that is specified by axis2.
Output functions.
Chapter 3: Output Functions
PointToLineDistance[point, axis]
95
returns the distance from point to axis, measured perpendicular to axis.
PointToPlaneDistance[point, axis] ProjectedAngle[vector1, vector2, vector3]
returns the perpendicular distance from point to a plane that is normal to axis. The axis is typically a Plane object. returns the counterclockwise angle measured from the direction of vector2 to the direction of vector1, as projected on a plane that is normal to vector3.
ProjectOnLine[vector1, vector2]
returns the vector component of vector1 that is in the direction of vector2.
ProjectOnLine[point, axis]
returns the location of point, projected orthogonally onto axis.
ProjectOnPlane[vector1, vector2]
returns the vector component of vector1 that is orthogonal to vector2.
ProjectOnPlane[point, axis]
returns the location of point, projected orthogonally onto a plane that is specified by axis.
More output functions.
The Location function is used to convert a Mech point object into the global coordinates of the point.
Here are the global coordinates of the attachment point of the connecting rod on the crank. In[15]:= Location@Point@crank, 2DD
Out[15]= 916 HEi2 Ej2 − Ek2 Eo2L + X2, 16 J−
1 + Ej22 + Eo22 N + Y2, 16 HEj2 Ek2 + Ei2 Eo2L + Z2= 2
Location assumes a point object if only the arguments of Point are given. In[16]:= Location@crank, 2D
Out[16]= 916 HEi2 Ej2 − Ek2 Eo2L + X2, 16 J−
1 + Ej22 + Eo22 N + Y2, 16 HEj2 Ek2 + Ei2 Eo2L + Z2= 2
MechanicalSystems
96
Now get a numerical result.
In[17]:= % ê. [email protected]
%% ê. [email protected]
Out[17]= 8−1.17686 × 10−21 , 10., 20.<
Out[18]= 8−1.707 × 10−22 , 3.52786, 16.7023<
The Distance function is used to find the absolute distance between any two points in space. The two points can be on one body or two different bodies.
Here is the distance from a point on the axis of the crank to the origin of the slider. In[19]:= Distance@Point@crank, 1D, Point@slider, 0DD 2 1 Out[19]= - JJ−16 J− + Ei22 + Eo22 N − X2 + X3N +
H−16 HEi2 Ej2 + Ek2 Eo2L − Y2 + Y3L2 + H−16 HEi2 Ek2 − Ej2 Eo2L − Z2 + Z3L2 N 2
Now get a numerical result.
In[20]:= % ê. [email protected], .2
Here is the length of the line from the center of the crank to the drive pin. In[21]:= Distance@Point@crank, 0D, Point@crank, 2DD Out[21]= 8
Note that it was not necessary to apply a solution rule to the last example to get a numerical result because the dimension that was measured was a constant.
Here is the minimum distance between the crank axis and the center line of the connecting rod.
In[22]:= PointToLineDistance@Point@crank, 0D, Line@crank, 2, slider, 0DD ê. [email protected] Out[22]= 5.96285
Chapter 3: Output Functions
97
Here is the angle between the connecting rod and the crank axis. In[23]:= IncludedAngle@
Line@crank, 2, slider, 0D, Vector@crank, 1DD ê. [email protected] Out[23]= 0.775575
Now convert the previous result to degrees. In[24]:=
% N@DegreeD
Out[24]= 44.4372
The measure of an angle in 3D space requires a reference frame for measurement. ProjectedAngle allows the plane of projection of the angle to be specified.
Here is the angle of a line on the crank, relative to a line on the ground, as viewed looking down the crank axis. In[25]:= ProjectedAngle@
Vector@crank, 2D, Vector@ground, 4D, Line@ground, 1, 2DD
Out[25]= ArcTanA16000 J−
1 + Ej22 + Eo22 N, 16000 HEj2 Ek2 + Ei2 Eo2LE 2
Now get a numerical result at T = 0.35.
In[26]:= % ê. [email protected] Out[26]= 2.19911
This angle should be equal to 35/100 of a turn, since that is what we have specified with SolveMech. In[27]:=
% 2 N@πD
Out[27]= 0.35
MechanicalSystems
98
This finds the intersection of the connecting rod axis and a horizontal plane through the crank axis. In[28]:= IntersectionPoint@
Line@crank, 2, slider, 0D, Plane@ground, 1, 2, 80, 14, 12
Out[28]= 88.07162, 3.44154, 12<
The angular orientation of a body in 3D space can be uniquely specified by a single rotation about a fixed axis. Rotation returns the angle and axis associated with the current spatial orientation of a body. See Section 4.2 for more examples on the angular orientation of 3D bodies.
This finds the angle and axis of rotation of the crank. In[29]:= Rotation@crankD
Out[29]= 92 ArcCos@Eo2D, 9 è!!!!!!!!!!!!!!!!!!!! , è!!!!!!!!!!!!!!!!!!!! , è!!!!!!!!!!!!!!!!!!!! == 2 2 2
Ei2
Ej2
Ek2
1 − Eo2
1 − Eo2
1 − Eo2
Now get a numerical result.
In[30]:= % ê. [email protected]
Out[30]= 82.19911, 81., 0., 0.<<
3.2.3 Vector Algebra Functions Modeler3D vector algebra functions perform many common vector algebra operations, such as cross and dot products of vectors. These functions can be used to build more complicated functions that are not provided by Modeler3D. These functions take point, vector, and axis objects as arguments, just like the output functions described in Section 3.2.2. When local point numbers are used, the local coordinates are taken from the current body objects, as specified with SetBodies. Each of the vector algebra functions is demonstrated in the context of the slider-crank mechanism model defined at the beginning of this section.
Chapter 3: Output Functions
99
Direction[point1, point2]
returns the vector from point1 to point2.
Direction[vector]
returns the global direction vector of the given vector.
Magnitude[vector]
returns the magnitude or length of vector.
Unit[vector] Cross[vector1, vector2] RotationMatrix[{ang, vector}]
returns a unit vector in the direction of vector. returns the cross product of the vectori. returns the 3D rotation matrix representing a rotation of ang radians about the specified vector.
RotationMatrix[bnum] SkewSym[vector]
returns the matrix associated with body bnum. returns the skew symmetric matrix associated with the given vector. SkewSym[vector1] . vector2 is equal to Cross[vector1, vector2].
PointToLocal[bnum, point]
returns the coordinates of point relative to the local coordinate system of body bnum.
VectorToLocal[bnum, vector]
returns the direction vector of vector relative to the local coordinate system of body bnum.
Vector algebra functions.
The Direction function is used to convert Modeler3D vector objects into 3D vectors in global coordinates.
Here is the direction vector of the connecting rod. In[31]:= Direction@Line@crank, 2, slider, 0DD Out[31]= 9−16 HEi2 Ej2 − Ek2 Eo2L − X2 + X3,
−16 J−
1 + Ej22 + Eo22 N − Y2 + Y3, −16 HEj2 Ek2 + Ei2 Eo2L − Z2 + Z3= 2
Now get a numerical result.
In[32]:= % ê. [email protected]
Out[32]= 824.6696, −3.52786, −16.7023<
MechanicalSystems
100
Several Modeler3D output functions are textbook vector algebra functions that are capable of dealing with normal 3D vectors or Modeler3D vector/axis objects interchangeably. Magnitude can return the length of the line from one end of the connecting rod to the other.
In[33]:= Magnitude@Line@crank, 2, slider, 0DD ê. LastSolve@D Out[33]= 30.
Here is the length of a simple 3D vector. In[34]:= Magnitude@81, −12, 13
è!!!!!!!!! 314!
Unit also works with vectors or vector objects. In[35]:= Unit@83, 5, −1
3 35
5
1 35
The cross product of two vectors is found with the Cross function.
Here is the cross product of a Modeler3D Line object and a vector.
In[36]:= Line@crank, 2, slider, 0D 80, 3, 2< Out[36]= 92 J−16 J−
1 + Ej22 + Eo22 N − Y2 + Y3N + 3 H16 HEj2 Ek2 + Ei2 Eo2L + Z2 − Z3L, 2 2 H16 HEi2 Ej2 − Ek2 Eo2L + X2 − X3L, 3 H−16 HEi2 Ej2 − Ek2 Eo2L − X2 + X3L=
Now get a numerical result.
In[37]:= % ê. [email protected]
Out[37]= 832., −54.8452, 82.2679<
Chapter 3: Output Functions
101
Here is the 3D rotation matrix associated with the crank.
In[38]:= RotationMatrix@crankD ê. [email protected]
Out[38]= 881., 0., 0.<, 80., −0.809017, −0.587785<, 80., 0.587785, −0.809017<<
Here is the skew symmetric matrix operator. In[39]:= SkewSym@8a, b, c
Out[39]= 880, −c, b<, 8c, 0, −a<, 8−b, a, 0<<
The global coordinates of a point specified in a local reference frame are equal to the coordinates of the origin of the reference frame plus the local coordinates of the point, rotated into the global reference frame.
Here is a calculation of the global coordinates of the local point {3, 8} on the slider.
In[40]:= Location@crank, 0D + [email protected], 8, −4< ê. LastSolve@D Out[40]= 83., 5.87901, 19.9383<
The Location function performs effectively the same calculation.
In[41]:= Location@crank, 83, 8, −4
The PointToLocal function converts the global point back to local coordinates.
In[42]:= PointToLocal@crank, %D ê. LastSolve@D Out[42]= 83., 8., −4.<
IMatrix
returns the 3D identity matrix {{1, 0, 0}, {0, 1, 0}, {0, 0, 1}}.
A constant utility.
MechanicalSystems
102
Coordinate Conversions The following four conversion functions will not accept Modeler3D geometry objects as arguments. These functions only accept 3D vectors of the form {x, y, z}.
CylindricalToXYZ[{radius, angle, altitude}] XYZToCylindrical[{x, y, z}]
returns the Cartesian coordinates of a point specified in cylindrical coordinates by radius, angle, and altitude. returns the cylindrical coordinates of a point specified in Cartesian coordinates x, y, and z.
SphericalToXYZ[{radius, baseangle, altitudeangle}]
returns the Cartesian coordinates of a point specified in
XYZToSpherical[{x, y, z}]
returns the spherical coordinates of a point specified in
spherical coordinates by radius, baseangle, and altitudeangle. Cartesian coordinates x, y, and z.
Coordinate conversions.
Coordinates
an option for CylindricalToXYZ, XYZToCylindrical, SphericalToXYZ, and XYZToSpherical that specifies the XYZ, YZX, or ZXY right-handed coordinate systems. The default setting is XYZ.
Coordinate conversion options.
This converts a cylindrical coordinate triplet to Cartesian coordinates. In[43]:= CylindricalToXYZA94, Out[43]= 82, 2
è!!!! 3 , 2<
π 3
, 2=E
Chapter 3: Output Functions
103
This converts it back. In[44]:= XYZToCylindrical@%D Out[44]= 94,
π , 2= 3
This converts a 3D vector to polar coordinates.
In[45]:= XYZToCylindrical@Location@crank, 2DD ê. LastSolve@D Out[45]= 83.52786, 1.5708, 16.7023<
3.3 Plots and Graphs This section discusses various methods for generating plots of Mech output. Because Mech uses a numerical technique to solve the kinematic equations that make up a mechanism model, it is generally not possible to generate analytic expressions that represent geometric quantities in a model that are to be plotted. The best that can be done is to generate a series of discreet solutions to the mechanism model, and then use the solutions to create lists of numbers that are plotted using Mathematica’s built-in data plotting routines such as ListPlot, or interpolated using Mathematica’s InterpolatingFunction.
3.3.1 Example Mechanism The quick-return mechanism model that was developed in Section 3.1 is used here to demonstrate all of the plotting techniques in this chapter. The model is redefined as follows in abbreviated form. Note that a parameter crankarm has been added to the model to allow the position of the drive pin on the crank to be easily changed.
MechanicalSystems
104
Here is the entire quick-return model. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
ground = 1; crank = 2; drivearm = 3; slider = 4; crankarm =. SetBodies@ Body@ground, PointList → 880, 0<, 80, 5<, 8−5, 10<, 812, 10<
A graphic of the quick-return mechanism.
Chapter 3: Output Functions
105
3.3.2 Data Plots To generate a data plot, we must first generate some data. SolveMech is used to return 20 solution points as the crank is rotated through a full turn, with the crank arm length set to three units.
This generates a list of 20 solutions. In[9]:= crankarm = 3;
First@positiontable = SolveMech@80, 1<, 40DD
Out[10]= 8T → 0., X2 → −1.1964 × 10−30 , Y2 → 5., Θ2 → −2.01335 × 10−21 ,
X3 → −7.35949 × 10−22 , Y3 → 0., Θ3 → −0.54042, X4 → 9.07905, Y4 → 10., Θ4 → 0.<
Since the primary function of the quick return mechanism is to reciprocate the slider, the X position of the slider is plotted as a function of time. Each solution rule returned by SolveMech contains a rule specifying the value of time T so a list of {x, y} pairs for ListPlot can easily be obtained with one replacement operation.
Here is a plot of slider position versus time.
In[11]:= ListPlot@8T, X4< ê. positiontable, PlotJoined → TrueD
8 6 4 2
0.2 Out[11]=
0.4
0.6
0.8
1
Graphics
More complicated functions can also be plotted in this manner.
MechanicalSystems
106
Here is a plot of connecting rod angle versus time. 8T, Angle@Line@drivearm, 2, slider, 1DD< ê. positiontable, PlotJoined → TrueD
In[12]:= ListPlot@ 0.6
0.5
0.4
0.3
0.2 Out[12]=
0.4
0.6
0.8
1
Graphics
To create a series of plots while varying the value of crank arm, the Table function is used in conjunction with SolveMech to generate a nested list of solutions. Note that at each invocation of SolveMech the value of time T is taken from 0 to 1, which takes the angular coordinate of the crank Θ2 from 0 to 2 pi. This requires the value of Θ2 to jump from 2 pi back to 0 in one step at each new invocation of SolveMech, which is a rather large single step for the numerical solution method. To avoid possible numerical difficulties, the initial guesses are reset with SetGuess at each invocation of SolveMech.
This generates a nested list of solutions.
In[13]:= positiontable = Table@SetGuess@D; SolveMech@80, 1<, 40D, 8crankarm, 1.5, 3., 0.75
To generate a series of plots a rather obtuse invocation of ListPlot is used.
Chapter 3: Output Functions
107
This shows a plot of slider position at varying values of crankarm.
In[14]:= Show@HListPlot@#1, PlotJoined → True, DisplayFunction → IdentityD &L ê@
H8T, X4< ê. positiontableL, DisplayFunction → $DisplayFunctionD;
8 6 4 2
0.2
0.4
0.6
0.8
1
3.3.3 Interpolation Mathematica InterpolatingFunction objects can be used to improve the appearance of a ListPlot by smoothing out the data. Mech provides a function that facilitates the creation of InterpolatingFunction objects, by assuming a dependence on time.
TimeInterpolate[expr, {rules1, rules2, …, rulesn}]
returns an interpolating function representing expr as a function of time T. The expression expr must evaluate to a number when subject to rulesi, and each of the rulesi must contain a specification for time.
Mech interpolation utility.
Using the quick-return mechanism model that was defined in Section 3.3.1, the plot of the connecting rod angle is reproduced using TimeInterpolate to create an InterpolatingFunction.
This generates a list of solutions. In[15]:= crankarm = 3;
SetGuess@D; positiontable = SolveMech@80, 1<, 20D;
MechanicalSystems
108
This generates an InterpolatingFunction object. In[18]:= TimeInterpolate@Angle@Line@drivearm, 2, slider, 1DD, positiontableD Out[18]= InterpolatingFunction@880., 1.<<, <>D
Here is a plot of the connecting rod angle versus time.
In[19]:= Plot@%@TD, 8T, 0, 1
0.5
0.4
0.3
0.2 Out[19]=
0.4
0.6
0.8
1
Graphics
3.4 2D Mechanism Images This section demonstrates special Modeler2D graphics functions that are used to generate the mechanism images throughout this document. Modeler2D graphics functions return graphics primitives that are given as arguments to the Mathematica Graphics function and displayed with the Show command, just like the built-in Mathematica graphics primitives.
Chapter 3: Output Functions
109
The primary utility of the Modeler2D graphics functions is that they take their arguments in the form of local coordinates and automatically convert them to global. Thus, it is possible to create the image of a mechanism part using the same techniques as would be used with built-in Mathematica graphics primitives, and then have the part be positioned properly with respect to the other parts of the mechanism automatically, as specified by a Modeler2D solution rule returned by SolveMech.
3.4.1 Graphics Functions The Modeler2D graphics functions closely parallel the built-in Mathematica graphics primitives. Each graphics function generates Mathematica graphics primitives that represent points, lines, or polygons.
Vertex[bnum, {pnt1, pnt2, …, pntn}]
returns point graphics primitives at each of the pnti on body bnum. Each pnti can be either a local point coordinate {x, y} or a local point number.
Edge[bnum, {pnt1, pnt2, …, pntn}] Facet[bnum, {pnt1, pnt2, …, pntn}] Basic Mech graphics function.
returns line graphics primitives connecting each of the pnti on body bnum. returns a polygon graphics primitive with vertices at each of the pnti on body bnum.
MechanicalSystems
110
Box[bnum, {pnt1, pnt2}]
generates a rectangular box with two opposite corners at local points pnt1 and pnt2, on body bnum. The sides of the box are aligned with the local axes of body bnum. Box accepts the Faces option.
Bar[axis, ltdist, rtdist]
generates a rectangular bar spanning the two endpoints of axis. The left and right sides of the bar are placed ltdist and rtdist away from axis, respectively. Bar accepts the Faces option.
Tangent[point1, rad1, point2, rad2]
generates a pair of lines tangent to two implied circles centered at point1 and point2 of radius rad1 and rad2, respectively. The tangent lines may represent a belt running between two pulleys. Tangent accepts the Faces option.
Wheel[point, rad, segs]
generates an n-gon with segs sides and radius to vertices rad, centered at the specified point. Wheel accepts the Faces and Angle options.
Wheel[point, rin, rout, segs] Wheel[point, rad]
generates an n-gon of radius rout with a hole of radius rin. generates a disk of radius rad centered at point.
More 2D graphics functions.
Faces
is an option for certain Modeler2D graphics function that specifies whether to draw the graphic element as a filled polygon or as a perimeter of lines. The default setting for all applicable functions is Faces → True.
Angle
is an option for Wheel that is used to specify the start and end angles of the partial n-gon. The default setting is Angle → {0, 2 π}. If the span of the two angles is less than 2 p, the resulting wheel will be only a segment of a wheel.
Options for graphics functions.
Chapter 3: Output Functions
111
The Modeler2D Vertex, Edge, and Facet functions are analogous to the built-in Mathematica Point, Line, and Polygon functions. To demonstrate these functions, graphics objects are generated that are located on body 2, which is named body2.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
ground = 1; body2 = 2;
Here is a box with a diagonal and a couple of points. In[4]:= bdgraph = Graphics@8
Vertex@body2, 88.25, .75<, 8.25, 1.25<
The coordinates of the graphic just created bdgraph are functions of the Modeler2D variables that locate body2: X2, Y2, and Θ2. Therefore, these variables must be replaced with numeric values before the graphic can be displayed with Show.
This shows bdgraph rotated 0.5 radians counterclockwise.
In[5]:= Show@bdgraph ê. 8X2 → 0, Y2 → 0, Θ2 → .5
Graphics
0
0.5
1
1.5
2
MechanicalSystems
112
This shows bdgraph rotated 1 radian and translated 1 unit to the right.
In[6]:= Show@bdgraph ê. 8X2 → 1, Y2 → 0, Θ2 → 1
0
0.5
1
1.5
2
Graphics
The Box function is analogous to the built-in Rectangle function, with the exception that the sides of the Box graphic are aligned with the local coordinate system in which the graphic is located, instead of being aligned with the global coordinate system. The Bar function also generates a rectangular box, but instead of specifying two points on two opposite corners, two points on two opposing sides of the rectangle are specified. The Faces option is used with the Bar function to show only an outline of the bar. Unlike the Box function, Bar accepts an axis object as its first argument, to allow the two endpoints of the bar to lie on two different bodies. Here is a Box graphic on body2 and a Bar graphic spanning from body2 to the ground, with an Edge graphic down the middle. In[7]:= bdgraph = Graphics@8
Box@body2, 880, 0<, 80.5, 1.0<
Chapter 3: Output Functions
113
Here is the result.
In[8]:= Show@bdgraph ê. 8X2 → 0, Y2 → .2, Θ2 → .1
0
0.5
1
1.5
2
Graphics
The Wheel function is used here to generate an octagon with a hole in it. Note that the n-gon returned by Wheel is placed on the body that is referenced in the Point argument, and is located with that body as such.
This generates an octagon on body2. In[9]:= bdgraph = Graphics@8
Wheel@Point@body2, 80, 1
MechanicalSystems
114
Here is the result.
In[10]:= Show@bdgraph ê. 8X2 → 0, Y2 → .2, Θ2 → −.1
0
0.5
1
1.5
2
Graphics
3.4.2 Annotation Functions Three graphics functions are provided by Modeler2D specifically for annotation.
Arrow[axis, length]
generates an arrow of specified length that emanates from the origin of axis and points in the direction of axis.
PointLabel[bnum, {lpnt1, …, lpntn}] LocalAxes[bnum, size]
generates labels of the local coordinates of the lpnti on body bnum. generates a local coordinate axes on body bnum, labeled with the body number and the x and y direction vectors. The length of each arm of the axes is specified by size.
Graphics functions for annotation.
PointLabel and LocalAxes can be used to conveniently label points and bodies. The following input generates a triangle placed on body 2, with two of the points labeled with their body numbers and local coordinates.
Chapter 3: Output Functions
115
This generates a labeled triangle on body2. In[11]:= body2 = 2;
bdgraph = Graphics@8 Edge@body2, 880, 0<, 81, 0<, 81, 1<, 80, 0<
Here is the result.
In[13]:= Show@bdgraph ê. 8X2 → .5, Y2 → 0, Θ2 → .5<, AspectRatio → AutomaticD 1.4
<2,81, 1<
1.2 1 0.8 0.6 <2,81, 0< 0.4 y x
0.2 2
0.25 0.5 0.75 Out[13]=
1
1.25 1.5 1.75
2
Graphics
LocusPlot[point, {rules1, rules2, …, rulesn}]
returns a list of Mathematica graphics primitives representing a series of line segments connecting the location of point, when subject to rulesi.
A function for plotting the locus of a moving point.
The nested list of rules required by LocusPlot is of the form returned by SolveMech when given a range of times at which to seek solutions.
MechanicalSystems
116
3.4.3 Example Mechanism Graphics The quick-return mechanism model that was developed in Section 3.1 is used to demonstrate the Modeler2D graphics functions. The model is redefined as follows in abbreviated form.
The complete quick-return model. In[14]:= ground = 1;
crank = 2; drivearm = 3; slider = 4; In[18]:= SetBodies@
Body@ground, PointList → 880, 0<, 80, 5<, 8−5, 10<, 812, 10<
Revolute2@1, Point@ground, 2D, Point@crank, 1DD, RotationLock1@2, crank, 2 N@πD TD, Revolute2@3, Point@ground, 1D, Point@drivearm, 1DD, PointOnLine1@4, Point@crank, 2D, Line@drivearm, 1, 2DD, RelativeDistance1@5, Point@drivearm, 2D, Point@slider, 1D, 5.0D, Translate2@6, Line@ground, 3, 4D, Line@slider, 1, 2DDD
To demonstrate the use of the graphics functions, the image of the quick-return mechanism that was displayed in the preceding sections is built. These images are generated with a mix of Modeler2D graphics functions and built-in Mathematica graphics primitives.
Chapter 3: Output Functions
117
Ground The ground body of the quick-return mechanism is generated using Modeler2D graphics functions even though it does not move. This is done to take advantage of the easy referencing of local point coordinates that were defined with SetBodies. Note that the Edge function in the following graphic references points either by their {x, y} coordinates or by their local point numbers interchangeably.
Here is the ground body graphic. In[20]:= groundgraphic = Graphics@8
[email protected], Point@80, 0
The text that is shown with the ground body is generated entirely with the built-in Mathematica Text function.
Here is the ground body graphic annotation. In[21]:= groundtext = Graphics@8
Text@"80,0<", 80, 0<, 80, 1.8
MechanicalSystems
118
Here is the result.
In[22]:= plot1 = Show@8groundgraphic, groundtext<, PlotRange → 88−6, 15<, 8−1, 12<
812,10<
P3
P4
80,5<
P2
Ground
P1
80,0< Out[22]=
Graphics
Crank The crank graphic uses only built-in Mathematica graphics functions, with the exception of the Vertex function to plot two local points on the crank, the coordinates of which are defined in a body object. Note the use of the Location function inside of the Disk primitives. This places the disks at the correct global coordinates when the crank moves.
Here is the crank body graphic. In[23]:= crankgraphic = Graphics@8
[email protected], 8RGBColor@1, .6, .6D, Disk@Location@crank, 1D, 4.0D<, 8RGBColor@1, .4, .4D, Disk@Location@crank, 2D, .6D, Disk@Location@crank, 1D, .6D<, [email protected], Vertex@crank, 81, 2
The text that is displayed with the crank graphic also uses the Location function to specify the global coordinates of the text so that the text moves with the crank.
Chapter 3: Output Functions
119
Here is the crank graphic annotation. In[24]:= cranktext = Graphics@8
Text@"80,0<", Location@crank, 1D, 80, 2.4
Because the coordinates of some of the elements in crankgraphic and cranktext are now functions of Modeler2D dependent variables X2, Y2, and Θ2, a Modeler2D solution rule must be applied before they can be displayed. Note the use of SolveMech in the following input. Here is the result. In[25]:= plot2 =
Show@8crankgraphic, cranktext< ê. SolveMech@0D, PlotRange → 88−6, 15<, 8−1, 12<
Out[25]=
P1
P2
80,0<
83,0<
Crank
Graphics
Drive Arm The drive arm graphic uses mostly built-in Mathematica graphics functions. Note how the Bar and Vertex function are called using local points 1 and 2, while the Edge function is called with explicit local point coordinates {0, 2} and {0, 8}. Most Mech functions attempt to interpret integers as local point numbers and resolve them into coordinates.
MechanicalSystems
120
Here is the drive arm graphic. In[26]:= drivearmgraphic = Graphics@8
8RGBColor@0, 1, 0D, Disk@Location@ground, 1D, 0.6D, Disk@Location@drivearm, 2D, 0.6D, Bar@Line@drivearm, 1, 2D, 0.3, 0.3D<, [email protected], Vertex@drivearm, 81, 2
The text that was displayed with the drive arm graphic also used the Location function to specify the global coordinates of the text so that the text moves with the drive arm. Here is the drive arm graphic annotation. In[27]:= drivearmtext = Graphics@8
Text@"80,0<", Location@drivearm, 1D, 81.6, 0
Like the crank graphic, the coordinates in the drive arm graphic are functions of Modeler2D dependent variables. Thus, a solution rule must be applied to display the graphic.
Chapter 3: Output Functions
121
Here is the result.
In[28]:= plot3 = Show@8drivearmgraphic, drivearmtext< ê. SolveMech@0D,
PlotRange → 88−6, 15<, 8−1, 12<
80,9<
P2
Drive Arm
80,0< Out[28]=
P1
Graphics
Slider The slider graphic uses just one built-in Mathematica graphics primitive and one Modeler2D graphics function. Here is the slider graphic. In[29]:= slidergraphic = Graphics@8
[email protected], .5, 1D, Disk@Location@slider, 1D, 0.4D, Bar@Line@slider, 1, 2D, 1, 0D<, Vertex@slider, 81, 2
Here is the slider annotation. In[30]:= slidertext = Graphics@8
Text@"80,0<", Location@slider, 1D, 80, 2.0
MechanicalSystems
122
Here is the result. In[31]:= plot4 =
Show@8slidergraphic, slidertext< ê. SolveMech@0D, PlotRange → 88−6, 15<, 8−1, 12<
80,0<
P2
83,0<
Slider
Out[31]=
Graphics
Connecting Rod The connecting rod graphic is nothing more than a line connecting two points on two different bodies.
Here is the connecting rod graphic. In[32]:= conrodgraphic =
Graphics@[email protected], Line@8Location@drivearm, 2D, Location@slider, 1D
To show the complete quick-return mechanism, all of the graphics objects are combined and displayed subject to a single Modeler2D solution rule.
Chapter 3: Output Functions
Here is the complete mechanism at T = 0.15. 8groundgraphic, crankgraphic, drivearmgraphic, slidergraphic, conrodgraphic< ê. [email protected], PlotRange → 88−6, 15<, 8−1, 12<
In[33]:= Show@
Out[33]=
Graphics
Here is the mechanism at T = 0.55. In[34]:= Show@
8groundgraphic, crankgraphic, drivearmgraphic, slidergraphic, conrodgraphic< ê. [email protected], PlotRange → 88−6, 15<, 8−1, 12<
Out[34]=
Graphics
123
124
MechanicalSystems
3.5 3D Mechanism Images This section demonstrates the special Modeler3D graphics functions that are used to generate the mechanism images throughout this document. Modeler3D graphics functions return graphics primitives that are given as arguments to the Mathematica Graphics function and displayed with the Show command, just like the built-in Mathematica graphics primitives. The primary utility of the Modeler3D graphics functions is that they take their arguments in the form of local coordinates and automatically convert them to global. Thus, it is possible to create the image of a mechanism part using the same techniques as would be used with built-in Mathematica graphics primitives, and then have the part be positioned properly with respect to the other parts of the mechanism automatically, as specified by a Modeler3D solution rule.
3.5.1 Graphics Functions The elementary Modeler3D graphics functions closely parallel the built-in Mathematica graphics primitives. Each graphics function generates Mathematica graphics primitives that represent points, lines, or polygons. The Modeler3D compound graphics functions generate more complex shapes, such as spheres and cylinders.
Chapter 3: Output Functions
Vertex[bnum, {pnt1, pnt2, …, pntn}]
125
returns point graphics primitives at each of the pnti on body bnum. Each pnti can be either a local point coordinate {x, y, z} or a local point number.
Edge[bnum, {pnt1, pnt2, …, pntn}] Facet[bnum, {pnt1, pnt2, …,pntn}] Box[bnum, {pnt1, pnt2}]
returns line graphics primitives connecting each pnti on body bnum. returns a polygon graphics primitive with vertices at each pnti on body bnum. generates a cuboid with two opposite corners at local points pnt1 and pnt2, on body bnum. The sides of the cuboid are aligned with the local axes of body bnum. Box accepts the Faces option.
Wheel[axis, rad, segs]
generates a planar n-gon with segs sides and radius to vertices rad, centered at the origin of axis. The plane of the n-gon is normal to axis.
Wheel[axis, rin, rout, segs]
generates an n-gon of radius rout with a hole of radius rin. Wheel accepts the Faces and Angle options.
Basic 3D graphics functions.
MechanicalSystems
126
Cylinder[axis, rad, segs]
generates a cylindrical bar with radius rad and segs sides,
Cylinder[axis, rad1, rad2, segs]
generates a conical bar of radius rad1 at the origin of axis
spanning the endpoints of axis. Setting segs = 4 generates a è!!!! rectangular bar 2 rad across a face.
and radius rad2 at the end of axis. Cylinder accepts the Faces and Angle options. Sphere[axis, rad, segs]
generates a sphere with segs segments, of radius rad, centered at the origin of the axis. The polar axis of the sphere points in the direction of the axis.
Sphere[axis, rad, {circsegs, polarsegs}]
generates a sphere with circsegs segments around the equator and polarsegs segments looping over the poles. Sphere accepts the Faces and Angle options.
Torus[axis, majrad, minrad, segs]
generates a torus with segs segments, centered at the origin of axis. The major axis of the torus points in the direction of axis.
Torus[axis, majrad, minrad, {majsegs, minsegs}]
generates a torus with different numbers of major and minor axis segments. Torus accepts the Faces and Angle options.
Bar[axis, c]
generates a rectangular bar of width 2c spanning the endpoints of axis.
Bar[axis, w, h]
generates a rectangular bar of width 2w and height 2h specified independently.
More 3D graphics functions.
Chapter 3: Output Functions
127
Faces
is an option for certain Modeler3D graphics function that specifies whether to draw the graphic element as a filled polygon or as a perimeter of lines. The default setting for all applicable functions is Faces → True.
Angle
is an option for revolved Modeler3D graphic functions that is used to specify the start and end angles of revolution of the revolved shape. The default setting is Angle → {0, 2 π}. If the span of the two angles is less than 2 p, the resulting revolved object will be only a section of a full revolved object.
Ends
is an option for Cylinder that specifies whether to generate facets to close the ends of the bar, or to leave the ends open like a hollow pipe. The default setting is Ends → True.
Options for graphics functions.
The Modeler3D Vertex, Edge, and Facet functions are analogous to the built-in Mathematica Point, Line, and Polygon graphics primitives. To demonstrate these functions, graphics objects are generated on body 2, which is named body2.
This loads the Modeler3D package. In[1]:= Needs@"MechanicalSystems`Modeler3D`"D
ground = 1; body2 = 2;
Here is a pyramid with a filled floor. In[4]:= bdgraph = Graphics3D@8
Vertex@body2, 88−.5, −.5, 2<, 8.5, .5, 2<
MechanicalSystems
128
The coordinates of the graphic just created bdgraph are functions of the Modeler3D variables that locate body2: X2, Y2, Z2, Eo2, Ei2, Ej2, and Ek2. Therefore, these variables must be replaced with numeric values before trying to Show the graphic. Here is bdgraph located coincidentally with the local origin.
In[5]:= Show@bdgraph ê. 8X2 → 0, Y2 → 0, Z2 → 0, Eo2 → 1, Ei2 → 0, Ej2 → 0, Ek2 → 0
Out[5]=
Graphics3D
To show the pyramid in another orientation, a set of four Euler parameters are fabricated that represent the desired angular orientation. Normally, Modeler3D graphics functions are used in conjunction with a Modeler3D solution rule that contains the values of the Euler parameters needed, but in this case they are generated explicitly. The pyramid is now rotated 0.5 radians about the global Z axis. The EulerParameters function returns the Euler parameters required for this rotation. These Euler parameters represent a rotation of 0.5 radians about the {0, 0, 1} axis.
In[6]:= [email protected], 80, 0, 1<
Chapter 3: Output Functions
129
Now the parameters are turned into rules for Eo2, Ei2, Ej2, and Ek2. In[7]:= ang = Thread@EulerParameters@2D → %D
Out[7]= 8Eo2 → 0.968912, Ei2 → 0, Ej2 → 0, Ek2 → 0.247404<
Here is bdgraph rotated 0.5 radians about the Z axis.
In[8]:= Show@bdgraph ê. 8X2 → 0, Y2 → 0, Z2 → 0< ê. angD
Out[8]=
Graphics3D
The Box function is analogous to the built-in Cuboid function, with the exception that the sides of the Box graphic are aligned with the local coordinate system on which the graphic is located, instead of being aligned with the global coordinate system. The Cylinder function generates a faceted cylinder or cone, with endpoints located at the two ends of a Modeler3D line object. The Faces option is used with Cylinder to show only an outline of the cylinder.
Here is a Box graphic on body2 and a Cylinder graphic spanning from body2 to the ground. In[9]:= bdgraph = Graphics3D@8
Box@body2, 880, 0, 0<, 8.5, 1, 1<<, Faces → FalseD, RGBColor@1, 0, 0D, Cylinder@Line@body2, 8.5, 1, 1<, ground, 81, 2, 0
MechanicalSystems
130
Here is the result.
In[10]:= Show@bdgraph ê. 8X2 → 0, Y2 → .2, Z2 → .1, Eo2 → 1, Ei2 → 0, Ej2 → 0, Ek2 → 0
Out[10]=
Graphics3D
The Wheel function is used here to generate a part of an octagon with a hole in it. Note that the n-gon returned by Wheel is placed on the body that is referenced in the Point argument, and is located with that body as such.
This generates a piece of an octagon on body2. In[11]:= bdgraph = Graphics3D@
8Wheel@Line@body2, 80, 0, 0<, 80, 1, −1
Chapter 3: Output Functions
Here is the result.
In[12]:= Show@bdgraph ê. 8X2 → 0, Y2 → .2, Z2 → .1, Eo2 → 1, Ei2 → 0, Ej2 → 0, Ek2 → 0
Out[12]=
Graphics3D
The Sphere and Torus functions are used here to generate a sphere and a torus.
This generates a piece of a sphere and a torus on body2. In[13]:= bdgraph = Graphics3D@8
Sphere@Axis@body2, 80, 0, 0<, body2, 80, 0.5, 1<, ground, 81, 0, 0
131
MechanicalSystems
132
Here is the result.
In[14]:= Show@bdgraph ê. 8X2 → 0, Y2 → 0, Z2 → 0, Eo2 → 1, Ei2 → 0, Ej2 → 0, Ek2 → 0
Out[14]=
Graphics3D
Extrude[{pnt1, pnt2, …,pntn}, axis, dist]
extrudes the sequence of n−1 lines between the pnti dist units in the direction of axis. Extrude accepts the Faces option.
Revolve[{pnt1, pnt2, …,pntn}, axis, segs]
revolves the sequence of n−1 lines between the pnti about the specified axis. The surface of revolution is broken into segs segments. Revolve accepts the Faces and Angle options.
Functions to generate pseudo-solid objects.
Extrude is used to generate a sequence of faces that are defined by sweeping a sequence of connected lines through 3D space. The following example takes six points on body2 that define an hourglass form and extrudes them at an oblique angle into a set of six facets forming a canted hourglass.
Chapter 3: Output Functions
Here are the points for an hourglass graphic.
In[15]:= pntlist = 8
Point@body2, 80, 0, 0
The graphic is shown shifted 2 units in the Y direction off of the global origin.
In[17]:= Show@bdgraph ê. 8X2 → 0, Y2 → 2, Z2 → 0, Eo2 → 1, Ei2 → 0, Ej2 → 0, Ek2 → 0
Out[17]=
Graphics3D
The same list of points can be revolved about an axis specified on body2.
133
MechanicalSystems
134
Here is a revolution of the hourglass graphic. In[18]:= bdgraph =
Graphics3D@8Revolve@pntlist, Line@body2, 0, 80, 1, 0
Here is the result.
In[19]:= Show@bdgraph ê. 8X2 → 0, Y2 → 0, Z2 → 0, Eo2 → 1, Ei2 → 0, Ej2 → 0, Ek2 → 0
Out[19]=
Graphics3D
Chapter 3: Output Functions
135
3.5.2 Annotation Functions Three graphics functions are provided by Modeler3D specifically for annotation.
Arrow[axis, length]
generates an arrow of specified length that emanates from the origin of axis and points in the direction of axis.
PointLabel[bnum, {lpnt1, …, lpntn}] LocalAxes[bnum, size]
generates labels of the local coordinates of the lpnti on body bnum. generates a local coordinate axes on body bnum, labeled with the body number and the x, y, and z direction vectors. The length of each arm of the axes is specified by size.
Graphics functions for annotation.
PointLabel and LocalAxes can be used to conveniently label points and bodies. The following input generates a triangle placed on body 2, with two of the points labeled with their body numbers and local coordinates.
This generates the triangle graphic. In[20]:= body2 = 2;
bdgraph = Graphics3D@8 Edge@body2, 880, 0, 0<, 81, 0, 0<, 81, 1, 0<, 80, 0, 0<
MechanicalSystems
136
Here is the result.
In[22]:= Show@bdgraph ê. 8X2 → 0, Y2 → 0, Z2 → 0, Eo2 → 0, Ei2 → 0, Ej2 → 1, Ek2 → 0
<2,81, 0, 0< y x
2 z
Out[22]=
Graphics3D
LocusPlot[point, {rules1, rules2, …,rulesn}]
returns a list of Mathematica graphics primitives representing a series of line segments connecting the location of point, when subject to rulesi.
A function for plotting the locus of a moving point.
The nested list of rules required by LocusPlot is of the form returned by SolveMech.
Chapter 3: Output Functions
137
3.5.3 Example Mechanism Graphics The spatial slider-crank mechanism model that was developed in Section 3.2 is used to demonstrate the use of Modeler3D graphics functions to create an image of a mechanism model. Creating a complex mechanism image often requires more lines of Mathematica code than were used in the kinematic model of the mechanism. This is because of the terse nature of the data required to kinematically describe a mechanism. A kinematic model uses only a small number of points in space to define rotational and translational axes that tie the bodies together, while the mechanism image requires much more information about the shape of the bodies in the model. The spatial slider-crank model is redefined as follows in abbreviated form. See Section 3.2 for a full description of this mechanism model.
Here is the complete definition of the slider-crank model. In[23]:= ground = 1;
crank = 2; slider = 3; In[26]:= SetBodies@
Body@ground, PointList → 880, 10, 12<, 810, 10, 12<, 81, 0, 0<, 80, 1, 0<
Revolute5@1, Line@ground, 1, 2D, Line@crank, 0, 1DD, ProjectedAngle1@2, Line@crank, 0, 2D, Line@ground, 0, 4D, Line@ground, 0, 3D, 2. π TD, RelativeDistance1@3, Point@crank, 2D, Point@slider, 0D, 30.0D, Translate5@4, Axis@ground, 0, 3, 4D, Axis@slider, 0, 1, 2DDD
MechanicalSystems
138
To demonstrate the use of the graphics functions the image of the slider-crank mechanism that is displayed in the preceding sections is built. These images are generated with a mix of Modeler3D graphics functions and built-in Mathematica graphics primitives. Ground The ground body of the slider-crank mechanism was generated using mostly built-in Mathematica graphics primitives. The Modeler3D Edge function was used to generate a line on the crank axis referencing local points by their point numbers.
Here is the ground body graphic. In[28]:= groundgraphic = Graphics3D@8
[email protected], Line@88−1, −5, 0<, 8−1, 18, 0<, 835, 18, 0<, 835, −5, 0<, 8−1, −5, 0<, 8−1, −5, 22<, 8−1, 18, 22<, 8−1, 18, 0<
The text that was displayed with the ground body was generated entirely with the built-in Mathematica Text function, except for the axes at the global coordinate origin, generated with the Modeler3D LocalAxes function, and the use of the Location function to reference the global coordinates of local point numbers on the ground body.
Here is the ground body annotation. In[29]:= groundtext = Graphics3D@8
Text@"80,10,12<", Location@ground, 1D, 80.5, −1.6
Chapter 3: Output Functions
139
Here is the result.
In[30]:= plot1 = Show@8groundgraphic, groundtext<, PlotRange → 88−2, 37<, 8−10, 20<, 8−4, 24<
80,10,12< P1
Ground P2 810,10,12<
z y
1
Out[30]=
x
Graphics3D
Crank The crank graphic uses the Modeler3D Cylinder function to generate a very short cylinder. The cylinder is only one unit long because the line that defines its axis is one unit long, while the radius of the cylinder is ten units as specified. Here is the crank body graphic.
In[31]:= crankgraphic = Graphics3D@8Cylinder@Line@crank, 0, 8−1, 0, 0
The text that was displayed with the crank graphic also used the Location function to specify the global coordinates of the text so that the text moves with the crank.
MechanicalSystems
140
Here is the crank annotation. In[32]:= cranktext = Graphics3D@8
Text@"88,0,0<", Location@crank, 1D, 8−0.4, 1.6
Because the coordinates of some of the elements in crankgraphic and cranktext are now functions of Modeler3D dependent variables, X2, Y2, and so on, a Modeler3D solution rule must be applied before they can be displayed. Note the use of SolveMech in the following input. The rules that are returned by Solve Mech determine where the crank is located in 3D space.
Here is the result.
In[33]:= plot2 = Show@8crankgraphic, cranktext< ê. SolveMech@0D,
PlotRange → 88−2, 37<, 8−10, 20<, 8−4, 24<
z
2
y P2 80,8,0< x P1 88,0,0<
Crank
Out[33]=
Graphics3D
Chapter 3: Output Functions
141
Slider The slider graphic uses the Modeler3D Box function to generate the rectangular box form of the slider.
Here is the slider graphic.
In[34]:= slidergraphic = Graphics3D@8Box@slider, 88−4, −1.5, −2<, 84, 1.5, 2<
Here is the slider annotation. In[35]:= slidertext = Graphics3D@8LocalAxes@slider, 8D, Text@
StyleForm@"Slider", FontFamily → "Times−Bold", FontSize → 12D, 824, 4, 23
Like the crank graphic, the coordinates in the slider graphic are functions of Modeler3D dependent variables. Thus, a solution rule must be applied to display the graphic.
Show it.
In[36]:= plot3 = Show@8slidergraphic, slidertext< ê. SolveMech@0D,
PlotRange → 88−2, 37<, 8−10, 20<, 8−4, 24<
Slider
z y
3
Out[36]=
Graphics3D
x
MechanicalSystems
142
Connecting Rod The connecting rod graphic uses the Modeler3D Cylinder function again to generate a long, thin cylinder spanning from the crank to the slider.
Here is the connecting rod graphic. In[37]:= conrodgraphic = Graphics3D@8Cylinder@Line@crank, 2, slider, 0D, 1.0, 8D
Here is the connecting rod annotation. In[38]:= conrodtext =
Graphics3D@8Text@StyleForm@"Connecting Rod", FontFamily → "Times−Bold", FontSize → 12D, 825, 4, 23
In[39]:= plot4 = Show@8conrodgraphic, conrodtext< ê. SolveMech@0D,
PlotRange → 88−2, 37<, 8−10, 20<, 8−4, 24<
ConnectingRod
Out[39]=
Graphics3D
To show the complete quick-return mechanism, all of the graphics objects are put together and displayed subject to a Modeler3D solution rule.
Chapter 3: Output Functions
143
Here is the complete slider-crank mechanism at T = 0.10.
In[40]:= Show@8groundgraphic, crankgraphic, slidergraphic, conrodgraphic< ê. [email protected],
PlotRange → 88−2, 37<, 8−10, 20<, 8−4, 24<
Out[40]=
Graphics3D
Here is the mechanism at T = 0.25, shown from a different perspective.
In[41]:= Show@8groundgraphic, crankgraphic, slidergraphic, conrodgraphic< ê. [email protected],
PlotRange → 88−2, 37<, 8−10, 20<, 8−4, 24<<, ViewPoint → 81.273, 2.942, 1.083
Out[41]=
Graphics3D
4. Velocity and Acceleration Overview This chapter covers MechanicalSystems’ velocity and acceleration solution blocks, and issues related to the representation of angular orientation and velocity in spatial systems. Mech automatically differentiates the kinematic equations with respect to time and can solve for the velocity and acceleration of each body in a model without any further input from the user. Output functions are provided for utilizing the higher-order solution data, and definitions for the derivatives of Mech dependent variables are automatically made in the Global` context so that expressions containing Mech dependent variables can be properly differentiated.
4.1 Velocity and Acceleration Solutions MechanicalSystems calculates all velocities and accelerations with respect to the time variable (the symbol T by default). As was shown in Chapter 2, the use of the time variable in a model is optional, if the model is to be used to generate a location solution only. However, a model must have some explicit functional dependence on the time variable in order to have a nontrivial solution to the higher-order (velocity and acceleration) equations.
4.1.1 2D Example Mechanism To demonstrate the use of the Mech velocity and acceleration solutions, a 2D model is developed that can be measured. A 3D model is treated in the same manner as 2D with regard to higher-order solutions. The model is be a pull-rod and rocker rear suspension linkage for a car, consisting of three moving bodies: the chassis, the carrier, and the rocker. A real suspension linkage would have three more moving bodies: the upper and lower A-arms, and the pull-rod between the wheel carrier and the rocker.
MechanicalSystems
146
The input to the model is the chassis moving vertically relative to the ground. This model could have been reduced in size by making the ground body the chassis, and simply moving the wheel carrier relative to the chassis, but the chosen method allows more flexibility and makes for better graphics. The wheel carrier is attached to the chassis by two A-arms. These A-arms are not modeled as independent bodies because their function can be represented by a pair of relative distance constraints between the chassis and the wheel carrier. The rocker pivots about an axis on the chassis and is attached to the wheel carrier by the pull-rod, a connecting link in tension. This pull-rod is also modeled with a relative distance constraint, not a separate body. The shock absorber is connected between the other end of the rocker and the chassis. The damper is not actually part of the kinematic model at all, but the length of the damper as a function of wheel motion is a primary point of interest for any suspension linkage. Thus, the shock absorber exists only as a pair of mounting points on the chassis and the rocker, the separation of which can be measured as the car is bounced.
Here is a graphic of the 2D pull-rod suspension model. 20
15
10
5
0 0
5
10
15
20
25
Bodies Four body objects are defined for the pull-rod suspension model. • The ground body (body 1) requires two point definitions. P1 is the origin of the ground body. P2 is a point directly above the origin that defines a vertical translation line upon which the chassis slides.
Chapter 4: Velocity and Acceleration
147
The chassis (body 2) requires six local point definitions. P1 is the local origin, which is a point at the bottom of the chassis. P2 is a second point that, with P1, defines the vertical translation line of the chassis. P3 is the pivot point of the lower A-arm. P4 is the pivot point of the upper A-arm. P5 is the pivot point of the rocker. P6 is the upper mounting point of the shock absorber. • The wheel carrier (body 3) requires three local point definitions. P1 is the local origin, which is the attachment point of the lower A-arm. P2 is the attachment point of the upper A-arm and the pull-rod. P3 is the bottom of the tire where the tire contacts the road. • The rocker arm (body 4) requires three local point definitions. P1 is the local origin, which is the rotational axis of the rocker. P2 is the lower attachment point of the shock absorber. P3 is the attachment point of the connecting rod. Here are each of the bodies in the pull-rod model.
Shock
P6
Upper A−arm
P4 P2
Pull−Rod P3 P5
Lower A−arm
P1
P2
P2 P1 P1
P3
P3
MechanicalSystems
148
This loads the Modeler2D package and defines names for each of the bodies in the model. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
ground = 1; chassis = 2; carrier = 3; rocker = 4;
Here are the four body objects for the pull-rod model.
In[6]:= bd@groundD = Body@ground, PointList → 8
H∗P1∗L80, 0<, H∗P2∗L80, 10<
In[7]:= bd@chassisD = Body@chassis, PointList → 8
H∗P1∗L80, 0<, H∗P2∗L80, 10<, H∗P3∗L87.5, 4<, H∗P4∗L88, 10<, H∗P5∗L86, 3.125<, H∗P6∗L89.5, 12<<, InitialGuess → 880, 2.5<, 0
In[8]:= bd@carrierD = Body@carrier, PointList → 8
H∗P1∗L80, 0<, H∗P2∗L8−1, 9<, H∗P3∗L81.25, −5.5<<, InitialGuess → 8822.0, 5.5<, 0
Chapter 4: Velocity and Acceleration
149
In[9]:= bd@rockerD = Body@rocker, PointList → 8
H∗P1∗L80, 0<, H∗P2∗L84.1, 2.6<, H∗P3∗L82.5, 0<<, InitialGuess → 886.0, 6.6<, −0.7
The body objects must be incorporated into the current model with SetBodies. In[10]:= SetBodies@bd@groundD, bd@chassisD, bd@carrierD, bd@rockerDD
Constraints Seven constraints, one of which is a driving constraint with explicit dependence on time, are used to model the pull-rod suspension. • A RelativeY1 constraint, used as a driving constraint, controls the vertical position of the chassis. This constraint is a driving constraint because it is functionally dependent on the time variable T. • A Translate2 prismatic constraint controls the chassis rotation and horizontal position and allows the chassis to move only vertically relative to the ground. • A RelativeDistance1 constraint models the upper A-arm. • A RelativeDistance1 constraint models the lower A-arm. • A RelativeY1 constraint forces the bottom of the tire to remain in contact with the ground. • A Revolute2 constraint places the axis of the rocker arm. • A RelativeDistance1 constraint models the pull-rod. The length of the pull-rod is specified by rodlength, which must be given a numerical value before Modeler2D attempts to find a solution.
MechanicalSystems
150
Here are the seven constraint objects for the pull-rod model. In[11]:= rodlength =.
cs@1D = RelativeY1@1, Point@chassis, 1D, TD; cs@2D = Translate2@2, Line@ground, 2, 1D, Line@chassis, 2, 1DD; cs@3D = RelativeDistance1@3, Point@chassis, 3D, Point@carrier, 1D, H∗lower A−arm length=∗L14.6D; cs@4D = RelativeDistance1@4, Point@chassis, 4D, Point@carrier, 2D, H∗upper A−arm length=∗L13.0D; cs@5D = RelativeY1@5, Point@carrier, 3D, 0D; cs@6D = Revolute2@6, Point@chassis, 5D, Point@rocker, 1DD; cs@7D = RelativeDistance1@7, Point@carrier, 2D, Point@rocker, 3D, rodlengthD;
The constraint objects must be incorporated into the current model with SetConstraints. In[19]:= SetConstraints@Array@cs, 7DD
Note that the explicit symbol that is used to represent time in Modeler2D (T by default) may be changed. The SymbolBasis option for SetSymbols is a nested list of strings that determines the basis for all of the Global` symbols created by Modeler2D. Redefining the first element of SymbolBasis changes the symbol that is recognized as the time variable.
SymbolBasis is the basis for all Modeler2D global symbols.
In[20]:= SymbolBasis ê. Options@SetSymbolsD Out[20]= 8T, 8X, Y<, 8Ei, Ej<, Θ, Λ, d<
Chapter 4: Velocity and Acceleration
151
Runtime Before the model can be run, the symbol rodlength, which determines the length of the pull-rod, must be defined. Because of the presence of T in the driving constraint (constraint 1), the model can be run through its intended range of motion by varying T directly with the first argument to the SolveMech command. The way that this model is defined, the numerical value of T specifies the distance between the chassis and the ground.
The symbol rodlength must be defined. In[21]:= rodlength = 15.5;
Now the model is run at T = 2.5. In[22]:= [email protected]
Out[22]= 8T → 2.5, X2 → 1.93286 × 10−22 , Y2 → 2.5, Θ2 → 0., X3 → 22.0636,
Y3 → 5.46934, Θ3 → 0.0233305, X4 → 6., Y4 → 5.625, Θ4 → −0.193489<
Here is the pull-rod suspension model at T = 2.5. 20
15
10
5
0 0
5
10
15
20
25
MechanicalSystems
152
4.1.2 The Solution Option When a Mech model is constructed with a functional dependence on the time variable T its time-domain motion is fully defined. Thus, nothing further needs to be done to generate velocity and acceleration solutions other than to ask for them. This is done with the Solution option for SolveMech.
Solution
is an option for SolveMech and several other Mech functions used to specify the solution level sought.
Solution → Location
specifies that only the location of the mechanism bodies should be calculated.
Solution → Velocity
specifies that the location and velocity of each mechanism body should be calculated.
Solution → Acceleration
specifies that the location, velocity, and acceleration of each mechanism body should be calculated. The default setting is Solution → Location.
An option for SolveMech.
The Modeler2D pull-rod suspension model defined in Section 4.1.1 is used to demonstrate the velocity and acceleration solutions. The Solution → Velocity option causes SolveMech to calculate the location and velocity of each body in the model.
This finds the location and velocity of each body at T = 3.0. In[23]:= [email protected], Solution → VelocityD
Out[23]= 8T → 3., X2 → 3.0594 × 10−21 , Y2 → 3., Θ2 → 0., X3 → 22.0212,
Y3 → 5.48505, Θ3 → 0.0116616, X4 → 6., Y4 → 6.125, Θ4 → −0.311793, X2d → 1.52911 × 10−17 , Y2d → 1., Θ2d → 0., X3d → −0.101143, Y3d → 0.0305219, Θ3d → −0.0232273, X4d → 0., Y4d → 1., Θ4d → −0.231717<
Mech creates a new set of symbols to represent the velocities and accelerations by appending a lowercase d or dd to each of the symbols that were used to represent body locations. Thus, while {X2, Y2} represents the location of the origin of body 2, {X2d, Y2d} represents the velocity of the origin of body 2.
Chapter 4: Velocity and Acceleration
153
Note that in this case, {X2d, Y2d} is equal to {0, 1}. This is expected since the driving constraint forces the height of the chassis to be T; therefore, its vertical velocity is equal to one. The Solution → Acceleration option causes SolveMech to calculate the location, velocity, and acceleration of each body in the model.
This finds the location, velocity, and acceleration of each body at T = 3.0. In[24]:= [email protected], Solution → AccelerationD
Out[24]= 8T → 3., X2 → 3.0594 × 10−21 , Y2 → 3., Θ2 → 0., X3 → 22.0212,
Y3 → 5.48505, Θ3 → 0.0116616, X4 → 6., Y4 → 6.125, Θ4 → −0.311793, X2d → 1.52911 × 10−17 , Y2d → 1., Θ2d → 0., X3d → −0.101143, Y3d → 0.0305219, Θ3d → −0.0232273, X4d → 0., Y4d → 1., Θ4d → −0.231717, X2dd → −7.64554 × 10−18 , Y2dd → 1.23017 × 10−17 , Θ2dd → 0., X3dd → −0.0657943, Y3dd → −0.00349459, Θ3dd → 0.000407417, X4dd → −8.02921 × 10−18 , Y4dd → 0., Θ4dd → 0.0165601<
The location, velocity, and acceleration of the rocker (body 4) reflect the fact that its origin is stationary on the chassis, but its rotation is controlled in a nonlinear manner by the suspension linkage.
Here is the rocker location, velocity, and acceleration.
In[25]:= MatrixForm@88X4, Y4, Θ4<, 8X4d, Y4d, Θ4d<, 8X4dd, Y4dd, Θ4dd<< ê. LastSolve@DD
6. 6.125 −0.311793 y i z j j z j 0. 1. −0.231717 z z j z j j z −18 0. 0.0165601 { k −8.02921 × 10
Out[25]//MatrixForm=
When SetConstraints is called to build the mathematical model, all of the expressions required for the velocity and acceleration solutions are not immediately built. Some parts of the mathematical model are built only when they are needed for the first time by SolveMech. Thus, the first time that SolveMech is called requesting a velocity or acceleration solution, it may take much longer to return a result than in any subsequent calls. SetConstraints accepts the BuildMech option to force the modeling equations to be built to any level immediately, instead of waiting until they are needed.
MechanicalSystems
154
BuildMech
is an option for SetConstraints that specifies which parts of the mathematical model are built immediately. BuildMech → level specifies that the equations required by SolveMech[…, Solution → level] should be built immediately. Valid settings include None, Location, Velocity, and Acceleration. The default setting is BuildMech → Location.
BuildMech[level]
can be called to force a build of the modeling equations to the specified level at any time.
An option for SetConstraints.
BuildMech can be used to build a model’s velocity and acceleration equations before all of the symbolic parameters in the model have been defined, so that the parameters will remain variable in the model. If undefined parameters are present in a model, SolveMech cannot be called to seek a solution, but Build Mech can still build the required equations.
4.1.3 3D Example Mechanism A Modeler3D example model is developed to demonstrate the different angular velocity and acceleration formulations used by Modeler3D. This model is of a MacPherson strut automotive front suspension. The model consists of only two moving bodies: the chassis and the wheel carrier. The wheel carrier is attached to the chassis by a lower A-arm, a MacPherson strut, and a steering tie rod that controls the steer angle of the wheel carrier. The A-arm, strut, and tie rod are not modeled as independent bodies in the model. They are each modeled as constraints that entirely represent the function they perform in the suspension. The input to the model is the chassis being moved vertically relative to the ground. A MacPherson strut is attached to the chassis of a car by a ball joint, but it is attached to the wheel carrier in a cantilever fashion, not by another ball joint such as would be used in a more conventional double A-arm suspension. Thus, the MacPherson strut not only provides vertical support for the wheel carrier, it also provides the axis about which the wheel carrier pivots for steering. Since the strut cannot pivot with respect to the wheel carrier, it is modeled simply by forcing a ray on the wheel carrier to pass through a point on the chassis (the upper mounting point of the strut).
Chapter 4: Velocity and Acceleration
This loads the Modeler3D package. In[26]:= Needs@"MechanicalSystems`Modeler3D`"D
Here is a 3D MacPherson strut front suspension model graphic.
Bodies Three body objects are defined for the MacPherson strut front suspension model. • The ground body (body 1) requires four point definitions. P1 is the origin of the ground body. P2 is a point directly above P1 that is used in conjunction with P1 to define a vertical translation axis for the chassis. P3 is a point on the X axis that is used with P1 to define a longitudinal axis that references the rotational orientation of the chassis. P4 is a point on the Y axis that is used with P1 and P3 to define the horizontal plane of the ground upon which the tire rests.
155
MechanicalSystems
156
• The chassis (body 2) requires seven local point definitions. P1 is the origin of the chassis. This point lies at the center of the bottom of the chassis. P2 is used in conjunction with P1 to define the vertical translation line of the chassis. P3 is used with P1 to define a transverse axis on the chassis that is used to reference the rotational orientation of the chassis. P4 and P5 are the two attachment points of the lower A-arm. P6 is the upper mounting point of the MacPherson strut. P7 is the attachment point of the steering tie rod. This point has a symbolic definition so that it can be moved in a transverse direction to steer the car. • The wheel carrier (body 3) requires five local point definitions. P1 is the local origin, which is the attachment point of the lower A-arm. P2 is used with P1 to define the axis of the MacPherson strut on the carrier. P3 is the center of the tire. P4 is used with P3 to define the axis of the tire. P5 is the attachment point of the steering tie rod on the wheel carrier. Names for each of the body numbers in the model are defined. In[27]:= ground = 1;
chassis = 2; carrier = 3;
Here are the three body objects used in the MacPherson strut model.
In[30]:= bd@groundD = Body@ground, PointList → 8
H∗P1∗L80, H∗P2∗L80, H∗P3∗L81, H∗P4∗L80,
0, 0, 0, 1,
0<, 1<, 0<, 0<
In[31]:= bd@chassisD = Body@chassis, PointList → 8
H∗P1∗L80, 0, 0<, H∗P2∗L80, 0, 1<, H∗P3∗L80, 1, 0<, H∗P4∗L84., 7.5, 5.5<, H∗P5∗L8−4., 7.5, 4.5<, H∗P6∗L80, 15.0, 20.0<, H∗P7∗L8−6, 9., 8.0<<, InitialGuess → 880, 0, 2.5<, 81, 0, 0, 0<
Chapter 4: Velocity and Acceleration
157
In[32]:= bd@carrierD = Body@carrier, PointList → 8
H∗P1∗L80, 0, 0<, H∗P2∗L80, −2.2, 6.0<, H∗P3∗L80, 1.25, 4.5<, H∗P4∗L80, −0.5, 4.5<, H∗P5∗L8−6, −2, 4<<, InitialGuess → 880, 22., 5.0<, 81, 0, 0, 0<
The body objects are incorporated into the current model. In[33]:= SetBodies@bd@groundD, bd@chassisD, bd@carrierDD
Constraints Eight constraints, including a driving constraint that is explicitly dependent on the time variable, are required to model the MacPherson strut front suspension. • A Cylindrical4 constraint forces a vertical axis on the ground to be coincident with a vertical axis on the chassis, effectively allowing the chassis to slide up and down on a post. • An Orthogonal1 constraint forces a longitudinal line on the ground to be orthogonal to a transverse line on the chassis. This constraint prevents the chassis from rotating about the vertical axis of rotation allowed by constraint 1. • A RelativeZ1 constraint controls the vertical position of the chassis. This constraint is a function of the time variable T so it is the driving constraint. • A RelativeDistance1 constraint models the front of the lower A-arm. • A RelativeDistance1 constraint models the back of the lower A-arm. • A PointOnLine2 constraint forces the axis of the MacPherson strut to pass through its upper mounting point on the chassis. • A PlaneToCircle1 constraint forces the bottom of the tire to remain in contact with the ground. PlaneToCircle1 places the surface of a torus (or a circle) in contact with a plane. • A RelativeDistance1 constraint models the steering tie rod.
MechanicalSystems
158
Here are the eight constraint objects for the MacPherson strut model. In[34]:= cs@1D = Cylindrical4@1,
Line@ground, 1, 2D, Line@chassis, 1, 2DD; cs@2D = Orthogonal1@2, Line@ground, 1, 3D, Line@chassis, 1, 3DD; cs@3D = RelativeZ1@3, Point@chassis, 1D, TD; cs@4D = RelativeDistance1@4, Point@chassis, 4D, Point@carrier, 1D, 15.0D; cs@5D = RelativeDistance1@5, Point@chassis, 5D, Point@carrier, 1D, 15.0D; cs@6D = PointOnLine2@6, Point@chassis, 6D, Line@carrier, 1, 2DD; cs@7D = PlaneToCircle1@7, Plane@ground, 1, 3, 4D, Line@carrier, 3, 4D, 7.5, 2.5D; cs@8D = RelativeDistance1@8, Point@chassis, 7D, Point@carrier, 5D, 11D;
The constraints are incorporated into the current model. In[42]:= SetConstraints@Array@cs, 8DD
Note that the explicit symbol used to represent time in Modeler3D (T by default) may be changed. The SymbolBasis option for SetSymbols is a nested list of strings that determines the basis for all of the symbols created by Modeler3D in the Global` context. Changing the first element of SymbolBasis changes the symbol that is recognized as the time variable.
SymbolBasis specifies the basis for Modeler3D automatic symbols.
In[43]:= SymbolBasis ê. Options@SetSymbolsD
Out[43]= 8T, 8X, Y, Z<, 8Eo, Ei, Ej, Ek<, 8Ωx, Ωy, Ωz<, Λ, d<
Chapter 4: Velocity and Acceleration
159
Runtime Because of the presence of T in the driving constraint (constraint 3) the model can be run through its intended range of motion by varying T directly with the first argument to the SolveMech command. The way that this model is defined, the numerical value of T specifies the distance between the chassis and the ground.
Now the model is run at T = 2.5.
In[44]:= [email protected] êê Chop
Out[44]= 8T → 2.5, X2 → 0, Y2 → 0, Z2 → 2.5, Eo2 → 1., Ei2 → 0,
Ej2 → 0, Ek2 → 0, X3 → 0.254625, Y3 → 21.8016, Z3 → 5.463, Eo3 → 0.99967, Ei3 → 0.014333, Ej3 → 0.000731365, Ek3 → −0.0213151<
Here is the MacPherson strut front suspension image at T = 2.5.
MechanicalSystems
160
4.1.4 3D Euler and Angular Formulations Velocity and acceleration solutions are calculated in a 3D model in the same manner as in a 2D model. However, there are three options in a 3D model as to how the higher-order data is represented. Since the angular orientation of Modeler3D bodies is specified by four Euler generalized parameters, {Eon, Ein, Ejn, Ekn}, one way of representing the angular velocity and acceleration of a body in 3-space is with the first and second derivatives of the Euler parameters, {Eond, …} and {Eondd, …}. Another more familiar way of representing angular velocity and acceleration is with the angular velocity and acceleration vectors, {omegaX, omegaY, omegaZ} and {alphaX, alphaY, alphaZ}, in either global coordinates or local coordinates attached to each individual body. Modeler3D can formulate the higher-order solutions in any of these representations, each of which requires that different sets of equations be built by the SetConstraints function. Which formulation is used is specified with the Method and Coordinates options for SetSymbols.
SetSymbols[options]
is used to specify what symbolic form is used to represent angular coordinates in a Mech model.
A system set-up function.
The Method option for SetSymbols may also be used with Modeler2D to specify angular coordinates or a degenerate version of Euler coordinates, although the Euler coordinates are seldom used in 2D models. Specifying Method → Euler in a Modeler2D model causes the angular orientation of each body to be represented by a pair of coordinates {Ejn, Ekn} = {cos(Qn), sin(Qn)} instead of a single coordinate, Qn. Velocity and acceleration are also represented by the coordinate pairs {Ejnd, Eknd} and {Ejndd, Ekndd}. The inclusion of this feature in Modeler2D is largely academic; specifying Method → Euler causes four equations to be generated for each body, instead of only three, and usually slows down the solution phase. There are two advantages afforded by 2D degenerate Euler coordinates: no trigonometric functions are generated in the constraint expressions so all of the constraints are purely algebraic, and the second derivative of a 2D rotation matrix is very simple which leads to faster solutions in some dynamical systems.
Chapter 4: Velocity and Acceleration
161
2D/3D
Method
is an option for SetSymbols that is used to specify whether the higher-order solutions are represented by Angular velocities and accelerations or by derivatives of Euler parameters.
Euler
is a setting for Method that causes derivatives of Euler parameters to be used to represent angular velocity.
Angular
is a setting for Method that causes angular velocity and acceleration to be used directly for first- and second-order coordinates. The default setting is Method → Euler.
An option for SetSymbols.
3D
Coordinates
is an option for SetSymbols that specifies whether angular velocity and acceleration coordinates are calculated in the global or local reference frame.
Global
is the default setting for Coordinates that causes angular velocity and acceleration to be calculated in the global reference frame.
Local
is a setting for Coordinates that causes angular velocity and acceleration to be calculated in the local reference frame with respect to each individual body.
An option for SetSymbols.
The MacPherson strut front model defined in Section 4.1.3 is used to demonstrate the 3D velocity and acceleration solutions. The Solution → Velocity option causes SolveMech to calculate the location and velocity of each body in the model.
MechanicalSystems
162
This finds the location and velocity of each body at T = 2.5.
In[45]:= [email protected], Solution → VelocityD êê Chop
Out[45]= 8T → 2.5, X2 → 0, Y2 → 0, Z2 → 2.5, Eo2 → 1., Ei2 → 0, Ej2 → 0, Ek2 → 0,
X3 → 0.254625, Y3 → 21.8016, Z3 → 5.463, Eo3 → 0.99967, Ei3 → 0.014333, Ej3 → 0.000731365, Ek3 → −0.0213151, X2d → 0, Y2d → 0, Z2d → 1., Eo2d → 0, Ei2d → 0, Ej2d → 0, Ek2d → 0, X3d → 0.120626, Y3d → −0.139596, Z3d → 0.0349904, Eo3d → 0.00030941, Ei3d → −0.0132679, Ej3d → −0.0055323, Ek3d → 0.00539955<
Note that the angular velocity of each body is returned in the form of derivatives of Euler parameters. This is because the constraint equations were built with all default options for SetSymbols. If the model is rebuilt with the Method → Angular option for SetSymbols, the first derivatives of the Euler parameters will be replaced by angular velocities.
This rebuilds the constraints with angular velocity formulation. In[46]:= SetSymbols@Method → AngularD
SetConstraints@Array@cs, 8DD
Now find the velocity solution at T = 2.0.
In[48]:= [email protected], Solution → VelocityD êê Chop
Out[48]= 8T → 2., X2 → 0, Y2 → 0, Z2 → 2., Eo2 → 1., Ei2 → 0, Ej2 → 0,
Ek2 → 0, X3 → 0.194309, Y3 → 21.863, Z3 → 5.44553, Eo3 → 0.999494, Ei3 → 0.0208988, Ej3 → 0.00345311, Ek3 → −0.0237464, X2d → 0, Y2d → 0, Z2d → 1., Ωx2 → 0, Ωy2 → 0, Ωz2 → 0, X3d → 0.120638, Y3d → −0.106083, Z3d → 0.0348985, Ωx3 → −0.0262207, Ωy3 → −0.0102694, Ωz3 → 0.00853952<
The angular velocity of the chassis in global coordinates is represented by the symbols {Ωx2, Ωy2, Ωz2}. The Solution → Acceleration option causes SolveMech to calculate the location, velocity, and acceleration of each body in the model. Note that it takes more time to execute the following command the first time than it will on all subsequent executions. This is because the acceleration equations must be built the first time through.
Chapter 4: Velocity and Acceleration
163
Now find the acceleration of the bodies at T = 2.0.
In[49]:= [email protected], Solution → AccelerationD êê Chop
Out[49]= 8T → 2., X2 → 0, Y2 → 0, Z2 → 2., Eo2 → 1., Ei2 → 0, Ej2 → 0, Ek2 → 0,
X3 → 0.194309, Y3 → 21.863, Z3 → 5.44553, Eo3 → 0.999494, Ei3 → 0.0208988, Ej3 → 0.00345311, Ek3 → −0.0237464, X2d → 0, Y2d → 0, Z2d → 1., Ωx2 → 0, Ωy2 → 0, Ωz2 → 0, X3d → 0.120638, Y3d → −0.106083, Z3d → 0.0348985, Ωx3 → −0.0262207, Ωy3 → −0.0102694, Ωz3 → 0.00853952, X2dd → 0, Y2dd → 0, Z2dd → 0, Ωx2d → 0, Ωy2d → 0, Ωz2d → 0, X3dd → −0.0000235305, Y3dd → −0.0666247, Z3dd → 0.000188244, Ωx3d → −0.00106965, Ωy3d → −0.000779857, Ωz3d → 0.00421226<
Since angular acceleration is the first derivative of angular velocity, the angular acceleration vector of the carrier, is represented by the derivatives of the angular velocity {Ωx3d, Ωy3d, Ωz3d}. The model is now rebuilt with the Coordinates → Local option so that angular velocity is represented in local, instead of global, coordinates.
This rebuilds the constraints with a local angular velocity formulation. In[50]:= SetSymbols@Method → Angular, Coordinates → LocalD
SetConstraints@Array@cs, 8DD
Now find the velocity solution at T = 2.0.
In[52]:= [email protected], Solution → VelocityD êê Chop
Out[52]= 8T → 2., X2 → 0, Y2 → 0, Z2 → 2., Eo2 → 1., Ei2 → 0, Ej2 → 0, Ek2 → 0, X3 → 0.194309,
Y3 → 21.863, Z3 → 5.44553, Eo3 → 0.999494, Ei3 → 0.0208988, Ej3 → 0.00345311, Ek3 → −0.0237464, X2d → 0, Y2d → 0, Z2d → 1., Ωx2 → 0, Ωy2 → 0, Ωz2 → 0, X3d → 0.120638, Y3d → −0.106083, Z3d → 0.0348985, Ωx3 → −0.0257719, Ωy3 → −0.011142, Ωz3 → 0.0088076<
Note that the local angular velocity of body 3 is only slightly different from the global angular velocity. This is because the angular orientation of the wheel carrier is very close to being aligned with the global coordinate system.
MechanicalSystems
164
4.2 Velocity and Acceleration Output Now that the velocity and acceleration of each mechanism body has been calculated, useful output may be generated by developing expressions that are functions of Mech velocity and acceleration variables, and subjecting those expressions to the standard solution rules produced by SolveMech.
4.2.1 3D Example Mechanism The 3D MacPherson strut suspension model is used to demonstrate various methods of producing velocity and acceleration output with Mech. The model is redefined as follows in abbreviated form.
The complete MacPherson strut suspension model follows. In[1]:= Needs@"MechanicalSystems`Modeler3D`"D
ClearMech@AllD In[3]:= SetBodies@
Body@ground = 1, PointList → 880, 0, 0<, 80, 0, 1<, 81, 0, 0<, 80, 1, 0<
Chapter 4: Velocity and Acceleration
165
In[4]:= SetConstraints@cons = 8
Cylindrical4@1, Line@ground, 1, 2D, Line@chassis, 1, 2DD, Orthogonal1@2, Line@ground, 1, 3D, Line@chassis, 1, 3DD, RelativeZ1@3, Point@chassis, 1D, TD, RelativeDistance1@4, Point@chassis, 4D, Point@carrier, 1D, 15.0D, RelativeDistance1@5, Point@chassis, 5D, Point@carrier, 1D, 15.0D, PointOnLine2@6, Point@chassis, 6D, Line@carrier, 1, 2DD, PlaneToCircle1@7, Plane@ground, 1, 3, 4D, Line@carrier, 3, 4D, 7.5, 2.5D, RelativeDistance1@8, Point@chassis, 7D, Point@carrier, 5D, 11D
Here the model is run at T = 2.5 to prove that it still works. In[5]:= [email protected]
Out[5]= 8T → 2.5, X2 → 3.9715 × 10−21 , Y2 → −4.48901 × 10−21 ,
Z2 → 2.5, Eo2 → 1., Ei2 → −3.88298 × 10−22 , Ej2 → −1.01807 × 10−22 , Ek2 → 2.90037 × 10−23 , X3 → 0.254625, Y3 → 21.8016, Z3 → 5.463, Eo3 → 0.99967, Ei3 → 0.014333, Ej3 → 0.000731365, Ek3 → −0.0213151<
4.2.2 Output Functions While Mech provides a wide array of output functions that return various quantities related to body location or orientation, only a small subset of those output functions are available in versions that are related to body velocities or accelerations. The most basic of those are the two higher-order analogies of the Location function. For each of the following functions, the point argument can be a Mech point object or just the arguments to a Mech point object.
MechanicalSystems
166
Location[point]
returns the global coordinates of point.
Velocity[point]
returns the global velocity vector of point.
Acceleration[point]
returns the global acceleration vector of point.
Velocity and acceleration output functions.
The velocity of the steering tie rod attachment point on the wheel carrier is very near zero in the global reference frame because the chassis is allowed to move up and down while the bottom of the tire (the carrier body) remains in contact with the ground. Thus the motion of the carrier with respect to the ground is just a small tipping about the bottom of the tire.
This calculates the velocity of a point.
In[6]:= Velocity@Point@carrier, 5DD ê. [email protected], Solution → VelocityD Out[6]= 80.0960177, −0.0540237, 0.0219076<
RelativeVelocity[bnum, point]
returns the velocity of point, relative to body bnum, in global coordinates.
A related velocity function.
The velocity of the steering tie rod attachment point with respect to the chassis has a much larger vertical component, while the longitudinal and transverse components remain the same.
The velocity of a point, relative to another body, is shown here.
In[7]:= RelativeVelocity@chassis, Point@carrier, 5DD ê. LastSolve@D Out[7]= 80.0960177, −0.0540237, −0.978092<
Chapter 4: Velocity and Acceleration
167
Two functions provide the higher-order analogies to the Rotation function. 2D
Rotation[bnum]
returns the angular coordinate of body bnum.
Omega[bnum]
returns the angular velocity of body bnum.
Alpha[bnum]
returns the angular acceleration of body bnum.
2D angular velocity and acceleration functions.
3D
Rotation[bnum]
returns a list {angle, axis} of the rotation angle and axis that uniquely specifies the angular orientation of body bnum.
Omega[bnum]
returns the global angular velocity vector of body bnum.
Alpha[bnum]
returns the global angular acceleration vector of body bnum.
3D angular velocity and acceleration functions.
Note that all Mech output functions formulate expressions in terms of derivatives of Euler parameters, or global angular velocities and accelerations, or local angular velocities and accelerations. Which form is returned depends on the settings of the Method and Coordinates options for SetSymbols that were in effect the last time that the model was built. For example, the current model was built with the default Method → Euler setting in SetSymbols; therefore, all output functions will return expressions in terms of derivatives of Euler parameters that can be replaced by a solution rule.
Here is the angular velocity of the wheel carrier. In[8]:= Omega@carrierD
% ê. [email protected], Solution → VelocityD
Out[8]= 82 H−Ej3d Ek3 + Ej3 Ek3d + Ei3d Eo3 − Ei3 Eo3dL,
2 HEi3d Ek3 − Ei3 Ek3d + Ej3d Eo3 − Ej3 Eo3dL, 2 H−Ei3d Ej3 + Ei3 Ej3d + Ek3d Eo3 − Ek3 Eo3dL<
Out[9]= 8−0.0262207, −0.0102694, 0.00853952<
MechanicalSystems
168
The Method → Angular option is now used with SetSymbols. This changes the formulation of the Modeler3D output functions, but the numbers remain the same.
The model is rebuilt with the Angular option setting. In[10]:= SetSymbols@Method → AngularD
SetConstraints@consD
The angular velocity of the wheel carrier is the same. In[12]:= Omega@carrierD
% ê. [email protected], Solution → VelocityD
Out[12]= 8Ωx3, Ωy3, Ωz3<
Out[13]= 8−0.0262207, −0.0102694, 0.00853952<
Again, the internal representation of the angular velocity can be changed to local coordinates, but the numerical results from the output functions remain the same.
The model is rebuilt again with local angular velocity representation. In[14]:= SetSymbols@Method → Angular, Coordinates → LocalD
SetConstraints@consD
The angular velocity of the wheel carrier is still the same. In[16]:= Omega@carrierD
% ê. [email protected], Solution → VelocityD
Out[16]= 92 J−
1 + Ei32 + Eo32 N Ωx3 + 2 HEi3 Ej3 − Ek3 Eo3L Ωy3 + 2 HEi3 Ek3 + Ej3 Eo3L Ωz3, 2 1 2 HEi3 Ej3 + Ek3 Eo3L Ωx3 + 2 J− + Ej32 + Eo32 N Ωy3 + 2 HEj3 Ek3 − Ei3 Eo3L Ωz3, 2 1 2 HEi3 Ek3 − Ej3 Eo3L Ωx3 + 2 HEj3 Ek3 + Ei3 Eo3L Ωy3 + 2 J− + Ek32 + Eo32 N Ωz3= 2
Out[17]= 8−0.0262207, −0.0102694, 0.00853952<
Chapter 4: Velocity and Acceleration
169
The only other output functions that are defined by Mech are the higher-order analogies to the Distance function. These two functions are defined largely for academic reasons, because they can be reproduced simply by differentiating the Distance function, as is shown in Section 4.2.3.
Distance[point1, point2] DDistanceDT[point1, point2]
returns the absolute distance between the two pointi. returns the first time derivative of the absolute distance between the two pointi.
D2DistanceDT2[point1, point2]
returns the second time derivative of the absolute distance between the two pointi.
Two more higher-order output functions.
There is a slight difference between using the velocity output functions Velocity, DDistanceDT, and so on, and simply differentiating their first-order counterparts Location and Distance. The first- and second-order output functions use the Mathematica D operator to differentiate the local coordinates of each point, thereby assuming that the local coordinates are constant unless they are explicitly functions of time T. Here are the length, and the first and second derivatives of the length of the strut.
In[18]:= 8Distance@Point@chassis, 6D, Point@carrier, 2DD,
DDistanceDT@Point@chassis, 6D, Point@carrier, 2DD, D2DistanceDT2@Point@chassis, 6D, Point@carrier, 2DD< ê. [email protected], Solution → AccelerationD
Out[18]= 811.5311, 0.852157, −0.012795<
4.2.3 Differentiating Expressions Although Mech provides only a small number of predefined output functions that relate to velocity and acceleration, any expression that is written in terms of Mech dependent variables can be differentiated with Dt because definitions have been automatically made for Dt[X, T], where X is any Mech dependent variable. Now the model is rebuilt with the Method → Euler setting. In[19]:= SetSymbols@D
SetConstraints@consD
MechanicalSystems
170
Here is the rate of change of the camber angle.
In[21]:= IncludedAngle@Line@carrier, 3, 4D, Vector@ground, 80, 0, 1
Dt@%, TD
Out[21]= ArcCosA0.571429 J−3.5 HEj3 Ek3 + Ei3 Eo3L + 0. J− Out[22]= −
1 + Ek32 + Eo32 NNE 2
0.571429 H−3.5 HEj3d Ek3 + Ej3 Ek3d + Ei3d Eo3 + Ei3 Eo3dL + 0. H2 Ek3 Ek3d + 2 Eo3 Eo3dLL 2 "########################################################################################################################################################### 1 − 0.326531 H−3.5 HEj3 Ek3 + Ei3 Eo3L + 0. H− 1 + Ek32 + Eo32 LL 2
This generates a numerical result at T = 2.5.
In[23]:= 8%%, %< ê. [email protected], Solution → VelocityD Out[23]= 81.59943, −0.0262853<
Note that Dt automatically replaced derivatives of dependent variables with the appropriate symbols. This form of differentiation is valid even when crossing from Euler to angular coordinates. Consider the following example. With the Method → Euler setting for SetSymbols, differentiating the seven Modeler3D location coordinates associated with body 3 with respect to T has the apparent effect of appending a d to the name of each variable. These new symbols are explicitly included in the solution rules returned by SolveMech. However, with the Method → Angular option set, differentiating the seven Modeler3D symbols with respect to T produces different symbolic results. This shows the functional relationship between the Euler parameters and the angular velocity. After replacement with a SolveMech solution rule, the results are numerically identical.
This shows the derivatives of dependent variables. In[24]:= Location@carrierD
Dt@Location@carrierD, TD % ê. [email protected], Solution → VelocityD
Out[24]= 8X3, Y3, Z3, Eo3, Ei3, Ej3, Ek3<
Out[25]= 8X3d, Y3d, Z3d, Eo3d, Ei3d, Ej3d, Ek3d<
Out[26]= 80.120626, −0.139596, 0.0349904, 0.00030941, −0.0132679, −0.0055323, 0.00539955<
Chapter 4: Velocity and Acceleration
171
Now the model is rebuilt with the Method → Angular option. In[27]:= SetSymbols@Method → AngularD
SetConstraints@consD
The derivatives of dependent variables have changed form, but their values remain the same. In[29]:= Location@carrierD
Dt@Location@carrierD, TD % ê. [email protected], Solution → VelocityD
Out[29]= 8X3, Y3, Z3, Eo3, Ei3, Ej3, Ek3< Out[30]= 9X3d, Y3d, Z3d,
1 1 H−Ei3 Ωx3 − Ej3 Ωy3 − Ek3 Ωz3L, HEo3 Ωx3 + Ek3 Ωy3 − Ej3 Ωz3L, 2 2 1 1 H−Ek3 Ωx3 + Eo3 Ωy3 + Ei3 Ωz3L, HEj3 Ωx3 − Ei3 Ωy3 + Eo3 Ωz3L= 2 2
Out[31]= 80.120626, −0.139596, 0.0349904, 0.00030941, −0.0132679, −0.0055323, 0.00539955<
The same holds true for the local coordinate formulation. In[32]:= SetSymbols@Method → Angular, Coordinates → LocalD
SetConstraints@consD Location@carrierD Dt@Location@carrierD, TD % ê. [email protected], Solution → VelocityD
Out[34]= 8X3, Y3, Z3, Eo3, Ei3, Ej3, Ek3< Out[35]= 9X3d, Y3d, Z3d,
1 1 H−Ei3 Ωx3 − Ej3 Ωy3 − Ek3 Ωz3L, HEo3 Ωx3 − Ek3 Ωy3 + Ej3 Ωz3L, 2 2 1 1 HEk3 Ωx3 + Eo3 Ωy3 − Ei3 Ωz3L, H−Ej3 Ωx3 + Ei3 Ωy3 + Eo3 Ωz3L= 2 2
Out[36]= 80.120626, −0.139596, 0.0349904, 0.00030941, −0.0132679, −0.0055323, 0.00539955<
Note that the only difference between the derivatives of the Euler parameters in terms of global or local coordinates is that a few of the signs are swapped.
MechanicalSystems
172
4.2.4 Euler’s Angles As shown in Sections 4.2.2 and 4.2.3, Euler parameters and their derivatives are directly related to the angular velocity vector of a spatial body, and a direct conversion between angular velocity and the derivatives of Euler parameters is possible. However, there is no vector representation of spatial angular orientation so other representations must be used. One method of representing the angular orientation of a spatial body is to define a sequence of three finite rotations about three fixed axes that take a body from one orientation to another. These three rotations are called Euler’s angles. Angular orientations represented by Euler’s angles are readily converted to and from Euler parameters with a combination of Modeler3D output functions. Mech does not provide a single function to make this conversion, because there are many possible combinations of successive rotations that can be used to represent the angular orientation of a body. The following example shows the general procedure required to convert an angular orientation from a sequence of finite rotations to a set of Euler parameters. In this particular case, the sequence of rotations are the most commonly used Euler’s angles. • Rotation 1 is a rotation phi about the global Z axis. • Rotation 2 is a rotation theta about the X axis in the new reference frame created by rotation 1. • Rotation 3 is a rotation psi about the Z axis in the new reference frame created by rotation 2. Here are the three rotation angles, and vector constants for each axis. In[37]:= phi = 0.2;
theta = 1.1; psi = 1.7; X = 81, 0, 0<; Y = 80, 1, 0<; Z = 80, 0, 1<;
Chapter 4: Velocity and Acceleration
173
A single rotation matrix that combines the three successive rotations is created by multiplying the rotation matrices associated with each. In[43]:= MatrixForm@rotmat =
RotationMatrix@8phi, Z
Out[43]//MatrixForm=
The EulerParameters function is used to convert the rotation matrix to a set of Euler parameters. In[44]:= eulpars = EulerParameters@rotmatD
Out[44]= 80.495899, 0.382444, −0.356284, 0.693457<
The conversion of Euler parameters to a sequence of finite rotations is not such a straightforward process. The general procedure is to measure the angle between an appropriate pair of axes located in the global and local reference frames. The following example shows how to convert the Euler parameters eulpars back to three Euler’s angles.
Since Mech output functions that return expressions in terms of the symbolic Euler parameters are used, a list of replacement rules is needed. In[45]:= eulrule = Thread@EulerParameters@2D → eulparsD
Out[45]= 8Eo2 → 0.495899, Ei2 → 0.382444, Ej2 → −0.356284, Ek2 → 0.693457<
Here is the second Euler’s angle theta. It is the included angle between the two Z axes in the global and local reference frames. In[46]:= IncludedAngle@Z, Vector@2, ZDD
% ê. eulrule
Out[46]= ArcCosA2 J− Out[47]= 1.1
1 + Ek22 + Eo22 NE 2
MechanicalSystems
174
Here is the first Euler’s angle phi. It is the angle between the local Z axis and the global –Y axis, as viewed looking down onto the global X-Y plane. In[48]:= ProjectedAngle@Vector@2, ZD, −Y, ZD
% ê. eulrule
Out[48]= ArcTan@−2 HEj2 Ek2 − Ei2 Eo2L, 2 HEi2 Ek2 + Ej2 Eo2LD Out[49]= 0.2
Here is the last Euler’s angle psi. It is the angle between the local Y axis and the global Z axis, as viewed looking down onto the local X-Y plane. In[50]:= ProjectedAngle@Vector@2, YD, Z, Vector@2, ZDD
% ê. eulrule
Out[50]= ArcTan@2 HEj2 Ek2 + Ei2 Eo2L, 2 HEi2 Ek2 − Ej2 Eo2LD Out[51]= 1.7
Any angular orientation can be represented by a single finite rotation about a fixed axis. This single rotation angle and axis are directly related to the Euler parameters so a direct conversion can be made with the Rotation function.
Here is the single rotation about a fixed axis that is equivalent to the three successive rotations phi, theta, and psi. In[52]:= Rotation@rotmatD
Out[52]= 82.10385, 80.440411, −0.410286, 0.798563<<
Some readers may be more familiar with the use of quaternions to represent the orientations of spatial bodies. Quaternions are four-dimensional complex quantities, with associated rules for multiplication, that allow them to be used much like 3D rotation matrices. The numerical values of the four elements of the quaternion qw + qx i + qy j + qz k are equivalent to the numerical values of the four Euler parameters {eo, ei, ej, ek} representing the same orientation. Quaternions and Euler parameters are notationally and conceptually quite different, but they are computationally equivalent.
Chapter 4: Velocity and Acceleration
175
4.2.5 2D Example Mechanism The 2D pull-rod suspension model that was presented in Section 4.1 is used to demonstrate various methods of producing velocity and acceleration output with Mech. The model is redefined as follows in abbreviated form.
Here is the complete pull-rod suspension model. In[53]:= Needs@"MechanicalSystems`Modeler2D`"D In[54]:= SetBodies@
Body@ground = 1, PointList → 880, 0<, 80, 10<
SetConstraints@ RelativeY1@1, Point@chassis, 1D, TD, Translate2@2, Line@ground, 2, 1D, Line@chassis, 2, 1DD, RelativeDistance1@3, Point@chassis, 3D, Point@carrier, 1D, 14.6D, RelativeDistance1@4, Point@chassis, 4D, Point@carrier, 2D, 13.0D, RelativeY1@5, Point@carrier, 3D, 0D, Revolute2@6, Point@chassis, 5D, Point@rocker, 1DD, RelativeDistance1@7, Point@carrier, 2D, Point@rocker, 3D, rodlengthDD
MechanicalSystems
176
Here the model is run at T = 2.5 to prove that it still works. In[57]:= rodlength = 16.2;
[email protected]
Out[58]= 8T → 2.5, X2 → 2.68029 × 10−23 , Y2 → 2.5, Θ2 → 0., X3 → 22.0636,
Y3 → 5.46934, Θ3 → 0.0233305, X4 → 6., Y4 → 5.625, Θ4 → −0.418281<
4.2.6 Interpolation MechanicalSystems provides a function that enhances the functionality of the Mathematica Interpolation function when used with a Mech model. This function is described in Section 3.2, but this subsection covers its capability of automatically utilizing higher-order data to obtain higher accuracy the interpolated results.
TimeInterpolate[expr, {rules1, rules2, …, rulesn}]
returns an InterpolatingFunction object representing expr as a function of time T. Each of the rulesi must be a list of rules containing numerical replacements for all variables occurring in expr, as well as a numerical replacement for T. If velocity and acceleration terms are included in the rulesi, TimeInterpolate utilizes the higher-order data to generate a more accurate InterpolatingFunction.
Interpolation utilities.
To demonstrate the use of TimeInterpolate, we must have an expression to interpolate and a list of rules to interpolate it over.
shocklength is the length of the damper in the pull-rod suspension model. In[59]:= shocklength = Distance@Point@chassis, 6D, Point@rocker, 2DD;
Here is a list of three location solutions. In[60]:= loctab = [email protected], 0.0<, 3D;
Chapter 4: Velocity and Acceleration
177
The following plot shows a course representation of the shock length versus time. Only three data points were calculated by the previous call to SolveMech, T = 3, 1.5, and 0, so the ListPlot graphic consists of only two straight line segments.
Here is a plot of the shock length versus time.
In[61]:= plot1 = ListPlot@8T, shocklength< ê. loctab, Frame → True, PlotJoined → TrueD 12 11.5 11 10.5 10 9.5 9 8.5 0
Out[61]=
0.5
1
1.5
2
2.5
3
Graphics
If we use TimeInterpolate to interpolate among the three points, the curve looks much smoother, but it is still a very poor representation, because there is no way for the InterpolatingFunction to know that the curvature increases as T approaches zero.
Here we interpolate the shock length function with a default InterpolationOrder that is too high. In[62]:= intshocklen = TimeInterpolate@shocklength, loctabD
Interpolation::inhr : Requested order is too high; order has been reduced to 82<. More… Out[62]= InterpolatingFunction@880., 3.<<, <>D
MechanicalSystems
178
Here is a plot of the zeroth-order representation of shocklength.
In[63]:= plot2 = Plot@intshocklen@TD, 8T, 0, 3<, Frame → TrueD 12 11.5 11 10.5 10 9.5 9 8.5 0
Out[63]=
0.5
1
1.5
2
2.5
3
Graphics
A new table of three solution rules is calculated, but this time velocity and acceleration data is included. To avoid recalculating all of the location solution points, SolveMech is passed the list of location solutions that have already been generated.
This generates a new list of solution rules using the existing rules as initial guesses. In[64]:= acctab = SolveMech@loctab, Solution → AccelerationD;
The higher-order slope and curvature information contained in acctab is automatically included in the new InterpolatingFunction object returned by TimeInterpolate.
Again, we interpolate the shocklength function. In[65]:= intshocklen = TimeInterpolate@shocklength, acctabD;
Chapter 4: Velocity and Acceleration
179
Here is a plot of the second-order representation of shocklength.
In[66]:= plot3 = Plot@intshocklen@TD, 8T, 0, 3<, Frame → TrueD 12 11.5 11 10.5 10 9.5 9 8.5 0 Out[66]=
0.5
1
1.5
2
2.5
3
2
2.5
3
Graphics
Here are the three plots shown together. In[67]:= Show@8plot1, plot2, plot3
0.5
1
1.5
Graphics
Interpolating Solutions Another method of applying interpolation is to directly interpolate the rules returned by SolveMech. SolveMech accepts the symbol Interpolation as an option name to tell SolveMech to interpolate the rules it returns. Note that SolveMech does not interpolate variables that are constant.
MechanicalSystems
180
Interpolation
is an option for SolveMech to specify that the returned solution rules are to be interpolated. The default setting is Interpolation → False.
MakeRules
is an option for SolveMech that determines which dependent variables are interpolated. The default setting causes SolveMech to return InterpolatingFunction objects representing location only.
FunctionOfTime
is an option for SolveMech that causes returned Interpo latingFunction objects to be explicitly functions of time. The default setting is FunctionOfTime → True.
An option for SolveMech.
Because the Solution → Acceleration option is given in the following example, the Interpolating Function objects returned contain slope and curvature information from the velocity and acceleration solutions.
Here is a set of interpolated solution rules. In[68]:= SetGuess@D;
intrules = SolveMech@80, 3<, 5, Solution → Acceleration, Interpolation → TrueD
Out[69]= 8X2 → InterpolatingFunction@880., 3.<<, <>D@TD,
Y2 → InterpolatingFunction@880., 3.<<, <>D@TD, Θ2 → 0., X3 → InterpolatingFunction@880., 3.<<, <>D@TD, Y3 → InterpolatingFunction@880., 3.<<, <>D@TD, Θ3 → InterpolatingFunction@880., 3.<<, <>D@TD, X4 → InterpolatingFunction@880., 3.<<, <>D@TD, Y4 → InterpolatingFunction@880., 3.<<, <>D@TD, Θ4 → InterpolatingFunction@880., 3.<<, <>D@TD<
Chapter 4: Velocity and Acceleration
181
Here is another plot of shocklength.
In[70]:= Plot@shocklength ê. intrules, 8T, 0, 3
Graphics
1
1.5
2
2.5
3
5. Multistage Mechanisms Overview This chapter covers one of the more advanced methods of kinematic modeling supported by MechanicalSystems. Stage switches and time switches are Mech’s method of allowing a mechanism to jump from one constraint type to another as it moves through its range of motion. These functions enable the modeling of components such as a pin that slides in a track with a sharp jog in it, or a bumper that swings through an arc until it strikes a stationary pad and starts it in motion. Mech also supports multistage load functions, which are covered in Chapter 7.
5.1 Stage Switching Constraints A StageSwitch constraint is nothing more than a compound constraint that contains several normal Mech constraints and lets the user specify which one is active. This function can be used to model any mechanism that has more than one mode of operation, and it is desired to automatically switch the model from one mode to another.
5.1.1 StageSwitch StageSwitch[cnum, test1, constraint1, test2, constraint2, …]
returns a compound Mech constraint object that is used in place of a single constraint object. StageSwitch evaluates each of the testi in turn, and applies the constrainti corresponding to the first testi that returns True. Stage Switch functions analogously to Which.
A multistage mechanism constraint-switching function.
MechanicalSystems
184
A StageSwitch constraint returns an error if any of the test expressions fail to return either True or False at runtime. Because StageSwitch does evaluate its own arguments immediately, unlike Which or If, test expressions such as SameQ should not be used. This is because SameQ evaluates immediately to True or False instead of waiting until some future condition changes. Also, a StageSwitch constraint is invalid if all of the test expressions return False at runtime because no constraint is applied to the model. Each of the constraints supplied to the StageSwitch constraint are standard Mech constraint objects or lists of constraint objects. Each constraint or list of constraints must constrain the same number of degrees of freedom. Note that the constraint numbers of the constraints that are inside of the StageSwitch constraint are irrelevant. The constraint number of the entire StageSwitch constraint is the only one that is used to reference the constraint. Examples This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
The following example shows how StageSwitch (constraint 1) might be used to model a pin on a slider that slides in one of two straight tracks on the ground body. Which track to use is determined by the value of the user-defined symbol whichtrack, which must be either 1 or 2.
Here is a valid StageSwitch constraint. In[2]:= ground = 1;
slider = 2; StageSwitch@1, whichtrack == 1, PointOnLine1@1, Point@slider, 80, 1D
The following example shows how a StageSwitch constraint that constrains two degrees of freedom might be implemented. The first constraint in the StageSwitch constraint forces the origin of the slider to be coincident with the origin of the ground. If the value of the user-defined symbol pressure rises above
Chapter 5: Multistage Mechanisms
185
100 units, the second constraint pair becomes active and forces the origin of the slider to lie upon a line and be positioned as a function of the value of pressure.
Here is a valid StageSwitch constraint. In[5]:= StageSwitch@1,
pressure < 100, Revolute2@1, Point@slider, 80, 0D
5.1.2 Rocker Example Mechanism To demonstrate the use of the Modeler2D StageSwitch function, a 2D model of a rocker arm driven by an eccentric is developed. The model consists of two moving bodies, the eccentric and the rocker. This mechanism has two distinct modes of operation that are toggled via the StageSwitch function. The first mode of operation is for the eccentric to be rotated about a stationary axis, forcing the rocker to reciprocate by its contact with the eccentric. The second mode is for the eccentric to be rotated about an axis that is unconstrained in the vertical direction while the rocker is constrained to be stationary. This causes the eccentric to rise and fall as a result of its rotation.
MechanicalSystems
186
Here is the 2D rocker model graphic.
y 2 x
Bodies Three bodies are used in the rocker mechanism model. • The ground (body 1) requires two points. P1 is the rotational axis of the eccentric at {0, 0}. P2 is the rotational axis of the rocker at {– 2, – 1}. • The eccentric (body2) requires two points. P1 is the rotational axis of the eccentric at local coordinates {0, 0}. P2 is the center of the eccentric disk at local coordinates {0.5, 0}. • The rocker (body 3) requires two points. P1 is the rotational axis of the rocker at local coordinates {0, 0}. P2 is the right end of the rocker face at local coordinates {4, 0}.
Chapter 5: Multistage Mechanisms
187
Here are all of the bodies in the rocker model.
P1
80,0<
P1 P2
80,0< 8.5,0<
P1 80,0<
P2
8−2,−1<
P2
84,0<
Names are defined for each of the body numbers in the model. In[6]:= ground = 1;
eccentric = 2; rocker = 3;
SetBodies is used only to set a nonzero initial guess for the rocker.
In[9]:= SetBodies@Body@rocker, InitialGuess → 88−2, −1<, 0
Constraints Four regular constraints and one StageSwitch constraint are used to model the rocker mechanism. • A Revolute2 constraint forces the axis of the rocker to be coincident with its pivot point on the ground. This constrains two degrees of freedom, X and Y displacement of the rocker. • A RelativeX1 constraint specifies the X coordinate of the rotational axis of the eccentric. • A RotationLock1 constraint controls the angular coordinate of the eccentric. This driving constraint is used to specify the rotation of the eccentric as a function of T. • A PointOnLine1 constraint enforces that the surface of the eccentric disk, which has a radius of one unit, remains in contact with the face of the rocker.
MechanicalSystems
188
• A StageSwitch constraint with two stages constrains the remaining one degree of freedom. Which mode of operation is active is determined by the boolean value of rockerfree. å If rockerfree is True, a RelativeY1 constraint specifies the Y coordinate of the axis of the eccentric, leaving the rocker free to reciprocate. å If rockerfree is False, a RotationLock1 constraint enforces that the rocker does not rotate, leaving the eccentric free to reciprocate vertically. Here is the complete rocker mechanism, built in one step. In[10]:= rockerfree =.
SetConstraints@ Revolute2@1, Point@ground, 8−2, −1
Runtime The rocker mechanism model is first run with rockerfree set to True. This enables the first stage of the StageSwitch constraint.
The model is first run at T = 0.15 with the rocker free to rotate. In[12]:= rockerfree = True;
[email protected]
Out[13]= 8T → 0.15, X2 → 0., Y2 → 4.16931 × 10−26 , Θ2 → 0.942478, X3 → −2., Y3 → −1., Θ3 → 0.168469<
Chapter 5: Multistage Mechanisms
189
Here is the rocker mechanism with rockerfree = True.
x
y 2
Now the mechanism model is run with rockerfree set to False. This enables the second stage of the StageSwitch constraint.
The model is now run at T = 0.15 with the rocker fixed. In[14]:= rockerfree = False;
[email protected]
Out[15]= 8T → 0.15, X2 → 0., Y2 → −0.404508, Θ2 → 0.942478, X3 → −2., Y3 → −1., Θ3 → 0.<
MechanicalSystems
190
Here is the rocker mechanism with rockerfree = False.
x
y 2
5.1.3 Slider-Ramp Example Mechanism Another usage of the StageSwitch constraint is to switch from one stage of operation to another when such switching is the normal progression of operation of the mechanism. To demonstrate this usage a 2D model of a slider on a ramp is developed. The model has only one moving body, the slider. This mechanism has two distinct modes of operation. First, the slider travels across a horizontal surface until it encounters an inclined ramp. As the slider progresses further, its front edge leaves the horizontal plane and begins to slide up the inclined ramp. StageSwitch is used to switch between these modes by defining the test expressions in the StageSwitch constraint to test explicitly whether or not the corner of the slider has traveled beyond the bottom of the ramp.
Here is a graphic of the 2D slider-ramp model. 2.5 2 1.5 1 0.5 0 -0.5 0
1
2
3
4
5
6
7
Chapter 5: Multistage Mechanisms
191
Bodies Two bodies are needed in the slider-ramp mechanism model. • The ground (body 1) requires three points. P1 is the beginning of the horizontal ramp at {0, 0}. P2 is the end of the horizontal ramp and the beginning of the inclined ramp at {4, 0}. P3 is the end of the inclined ramp at {6, 2}. • The slider (body 2) requires two points. P1 is the left bottom corner of the slider at local coordinates {0, 0}. P2 is the right bottom corner of the slider at local coordinates {2, 0}. Here are both the bodies in the slider-ramp model. P3
86,2<
P1
P2
80,0<
84,0<
P1
80,0<
P2
82,0<
Names are defined for each of the body numbers in the model. In[16]:= ground = 1;
slider = 2;
MechanicalSystems
192
Constraints Two regular constraints and one StageSwitch constraint are used to model the slider-ramp mechanism. • A RelativeX1 constraint specifies the X coordinate of the left bottom corner of the slider as a function of time T. • A PointOnLine1 constraint enforces that the left bottom corner of the slider remains in contact with the horizontal surface of the ramp. • A StageSwitch constraint with two stages eliminates the one remaining degree of freedom: å A PointOnLine1 constraint is used to place the right bottom corner of the slider on the horizontal surface if it is still to the left of the ramp. å A PointOnLine1 constraint is used to place the right bottom corner of the slider on the inclined ramp if it has passed to the right of the ramp. Which stage of operation is active is determined by the value of a test expression that is a function of Modeler2D dependent variables. The test expression measures whether or not the right bottom corner of the slider has progressed far enough to the right to be on the inclined ramp. Here is the slider-ramp mechanism built in one step. In[18]:= SetConstraints@
RelativeX1@1, Point@slider, 0D, TD, PointOnLine1@2, Point@slider, 0D, Line@ground, 0, 84, 0
Runtime The slider-ramp mechanism model can be run at any time, T, up to T = 4 with valid results. After T = 4, the left bottom corner of the slider passes the inclined ramp, but it does not travel up the ramp because the constraints have not been written to accommodate this. This runs the model at T = 1. In[19]:= SolveMech@1D
Out[19]= 8T → 1, X2 → 1, Y2 → 0, Θ2 → 0<
Chapter 5: Multistage Mechanisms
193
The slider-ramp mechanism is still on the horizontal segment of the ramp. 2.5 2 1.5 1 0.5 0 0
1
2
3
4
5
6
7
Now the model is run at T = 2.5, which puts the slider part way up the ramp. In[20]:= [email protected]
Out[20]= 8T → 2.5, X2 → 2.5, Y2 → 0., Θ2 → 0.226408<
Here is the result. 2.5 2 1.5 1 0.5 0 0
1
2
3
4
5
6
7
5.2 Time Switching Constraints A TimeSwitch constraint is a compound constraint that contains several normal Mech constraints and determines which one is active by the value of time T. This function can be used to model any mechanism that switches from one mode of operation to another with the progression of time. A TimeSwitch constraint is basically a special case of a StageSwitch constraint that has switching capability explicitly dependent on time. All of the functionality of TimeSwitch can be duplicated with Stage Switch, except that the TimeSwitch constraint can be used with another special function, FindSwitch Time, that is used to seek the point in time at which two adjacent constraints should switch from one to the next.
MechanicalSystems
194
5.2.1 TimeSwitch TimeSwitch[cnum, constraint0, time1, constraint1, …, timen, constraintn]
returns a Mech constraint object that is used in place of a single constraint in a model. TimeSwitch applies constrainti when the value of time is greater than timei and less than time(i+1). The timei must evaluate to numbers in ascending order. The values of time0 and time(n+1) are taken to be -$MaxMachineNumber and +$MaxMachineNumber, respectively. TimeSwitch functions analogously to Which.
The time-dependent, stage-switching function.
Each of the constraints supplied to the TimeSwitch must be a Mech constraint object, or a list of constraint objects. Each constraint or list of constraints must constrain the same number of degrees of freedom. Note that the constraint numbers of the constraints that are inside of the TimeSwitch are irrelevant. The constraint number of the entire TimeSwitch is the only one used to reference the entire constraint. Examples This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
The following example shows how a TimeSwitch constraint (constraint 1) might be used to model a pin on a slider that slides along a horizontal track on the ground until the value of time reaches 2.0, at which time the pin begins to slide up an inclined track. This constraint could replace the StageSwitch constraint used in the slider-ramp model in Section 5.1. Here is a valid TimeSwitch constraint. In[2]:= ground = 1;
slider = 2; TimeSwitch@1, PointOnLine1@1, Point@slider, 82, 0D
Chapter 5: Multistage Mechanisms
195
The following example shows how a TimeSwitch constraint that constrains two degrees of freedom might be implemented. The first constraint in the TimeSwitch constraint forces the origin of the slider to be coincident with the origin of the ground. If the value of time rises above 4.0, the second constraint pair becomes active, which forces the origin of the slider to lie upon an inclined line, while the Y coordinate of the origin of the slider is a function of time.
Here is a valid TimeSwitch constraint. In[5]:= TimeSwitch@1,
Revolute2@1, Point@slider, 80, 0
Out[5]= SysCon@TimeSwitch, 1, <>D
5.2.2 Detent Mechanism Example To demonstrate the use of the Modeler2D TimeSwitch function a 2D model of a detent mechanism is developed. The model consists of two moving bodies, a slider and a detent plunger. The detent mechanism goes through seven distinct stages of operation as the detenter passes across the slider, down into the detent notch, and back out. These stages are progressively activated via the Time Switch function as follows. In stage 1 the detenter travels across the right top surface of the slider. In stage 2 the detenter travels around the corner that leads into the detent notch. In stage 3 the detenter travels down the inclined right side of the detent notch. In stage 4 the detenter travels around the round bottom of the detent notch. In stage 5 the detenter travels up the inclined left side of the detent notch. In stage 6 the detenter travels around the corner that leads out of the detent notch. In stage 7 the detenter travels across the left top surface of the slider.
MechanicalSystems
196
Here is the 2D detent model graphic.
Bodies Three body objects are defined for the detent mechanism model. • Four points are defined on the ground body (body 1). P1 and P2 are two points that define the horizontal line on which the slider translates. P3 and P4 are two points that define the vertical line on which the detenter translates. • Nine points are defined on the slider (body 2). P1 and P2 are two points that define the horizontal translation line of the slider. P3 to P8 are a series of points defining the detent notch in the top surface of the slider. P9 is the center point of the circular bottom of the detent notch. • Two points are defined on the detenter (body 3). P1 and P2 are two points defining the vertical translation axis of the detenter.
Chapter 5: Multistage Mechanisms
Names for each body number in the model are defined. In[6]:= ground = 1;
slider = 2; detenter = 3;
In[9]:= bd@groundD = Body@ground, PointList → 8
H∗P1∗L80, H∗P2∗L84, H∗P3∗L82, H∗P4∗L82,
0<, 0<, 2<, 3<
In[10]:= bd@sliderD = Body@slider, PointList → 8
H∗P1∗L80, 0<, H∗P2∗L84, 0<, H∗P3∗L80, 1<, H∗P4∗L81, 1<, H∗P5∗L81.5, 0.5<, H∗P6∗L82.5, 0.5<, H∗P7∗L83, 1<, H∗P8∗L84, 1<, H∗P9∗L82, 1<
In[11]:= bd@detenterD = Body@detenter, PointList → 8
H∗P1∗L80, 0<, H∗P2∗L80, 2<<, InitialGuess → 882.0, 0.6<, 0
197
MechanicalSystems
198
Here are all three bodies in the detent mechanism model. P4
82,3<
P3
82,2<
80,0<
84,0<
P1
P2
P3
P4
P9
P7
P8
P5 P6
P1
P2
P1
P2
80,2<
80,0<
The body objects are incorporated into the model. In[12]:= SetBodies@bd@groundD, bd@sliderD, bd@detenterDD
Constraints Three regular constraints and one TimeSwitch constraint are used to model the detent mechanism. • A Translate2 constraint forces a horizontal line on the slider to be coincident with a horizontal line on the ground, allowing the slider to translate in the X direction only. • A Translate2 constraint forces a vertical line on the detenter to be coincident with a vertical line on the ground, allowing the detenter to translate in the Y direction only.
Chapter 5: Multistage Mechanisms
199
• A RelativeX1 constraint controls the X coordinate of the slider. This driving constraint is used to specify the position of the slider as a function of time T. • The TimeSwitch constrains the one remaining degree of freedom: å Four of the seven stages of operation (1, 3, 5, and 7) are modeled by PointOnLine1 constraints that place the center of the detenter tip a specified distance (detenter tip radius) away from various lines on the slider. å The second and sixth stages, in which the detenter tip moves around sharp corners on the slider, are modeled with RelativeDistance1 constraints that place the center of the detenter tip a specified distance (detenter tip radius) away from the sharp corners on the slider. å The fourth stage, in which the detenter tip is traveling around the arc at the bottom of the detent notch, is also modeled with a RelativeDistance1 constraint that places the center of the detenter tip a specified distance (detent notch radius minus detenter tip radius) away from the center point of the arc. The exact values of the switch times given as arguments to the TimeSwitch constraint are not known. The symbols given in place of switch times (tm2, tm3, etc.) are set to approximate values before running the model. The exact switch times will be determined later with FindSwitchTime.
Here are the three regular constraints. In[13]:= tm2 =.; tm3 =.; tm4 =.; tm5 =.
cs@1D = Translate2@1, Line@ground, 1, 2D, Line@slider, 1, 2DD; cs@2D = Translate2@2, Line@ground, 3, 4D, Line@detenter, 1, 2DD; cs@3D = RelativeX1@3, Point@slider, 1D, TD;
MechanicalSystems
200
Here is the seven-stage TimeSwitch constraint. In[17]:= cs@4D = TimeSwitch@4,
PointOnLine1@1, Point@detenter, 1D, Line@slider, 7, 8D, .3D, −1, RelativeDistance1@2, Point@detenter, 1D, Point@slider, 7D, .3D, tm2, PointOnLine1@3, Point@detenter, 1D, Line@slider, 6, 7D, .3D, tm3, RelativeDistance1@4, Point@detenter, 1D, Point@slider, 9D, 1 ê [email protected] − .3D, tm4, PointOnLine1@5, Point@detenter, 1D, Line@slider, 4, 5D, .3D, tm5, RelativeDistance1@6, Point@detenter, 1D, Point@slider, 4D, .3D, 1, PointOnLine1@7, Point@detenter, 1D, Line@slider, 3, 4D, .3DD;
The constraints are incorporated into the current model. In[18]:= SetConstraints@cs@1D, cs@2D, cs@3D, cs@4DD
Runtime Before the detent model can be run, the switch times used in the TimeSwitch constraint (tm2, tm3, etc.) must be given numeric values.
Here are guesses for switch times. In[19]:= tm2 = −.8;
tm3 = −.4; tm4 = .4; tm5 = .8;
Now the model is run at T = – 1.3. In[23]:= SolveMech@−1.3D
Out[23]= 8T → −1.3, X2 → −1.3, Y2 → 0., Θ2 → 0., X3 → 2., Y3 → 1.3, Θ3 → 0.<
Chapter 5: Multistage Mechanisms
201
Here is the detent mechanism at T = – 1.3.
Now the model is run twice more at T = – 0.5 and T = – 0.1. In[24]:= postab = SolveMech@8−0.5, −0.1
Out[24]= 88T → −0.5, X2 → −0.5, Y2 → 0., Θ2 → 0., X3 → 2., Y3 → 0.924264, Θ3 → 0.<,
8T → −0.1, X2 → −0.1, Y2 → 0., Θ2 → 0., X3 → 2., Y3 → 0.605366, Θ3 → 0.<<
Here is the detent mechanism at the two new solution points.
Note again that the current values of the switch times (tm2, tm3, etc.) are merely guesses. If the model is run at values very close to those times, incorrect results will be generated whenever the model uses the wrong constraint. The exact values of the switch times are found in Section 5.2.3 with the FindSwitchTime function.
MechanicalSystems
202
5.2.3 Finding Switch Times The Mech FindSwitchTime function is used to seek the time at which two adjacent constraints in a Time Switch are simultaneously valid, that is, to numerically find the correct switch time.
FindSwitchTime[cnum, snum, options]
seeks a solution to the current mechanism model that simultaneously satisfies two adjacent constraints in a TimeSwitch constraint, while allowing time to vary. The constraint number of the TimeSwitch constraint is specified by cnum, and which pair of adjacent constraints in the TimeSwitch is considered is specified by snum. With snum = 1, the conjunction of the first and second stages of the TimeSwitch is sought.
A function for seeking stage transition times.
FindSwitchTime works by adding one degree of freedom to the model (T becomes a dependent variable) and adding one extra constraint by using the pair of adjacent constraints simultaneously. FindSwitchTime uses the same solution block as SolveMech so it uses the most recent solution returned by SolveMech (LastSolve[]) for its initial guess. FindSwitchTime accepts two options to deal with special situations that may arise in a pair of adjacent constraints, TangentConstraint and RequiredEquations.
Chapter 5: Multistage Mechanisms
TangentConstraint
203
is an option for FindSwitchTime that specifies that the pair of constraints being considered are a pair that come into conjunction tangentially. This implies that as the mechanism passes through the correct switch time, there is no discontinuity in the location or velocity of the mechanism components. When this is true, FindSwitchTime must use the velocity solution to seek the switch time. If Tangent Constraint → False is used when the constraints are in fact a tangent pair, FindSwitchTime may have trouble converging. The default setting is TangentConstraint → False.
RequiredEquations
is an option for FindSwitchTime that specifies which equations of a multiple degree of freedom constraint set are used to seek the switch time. RequiredEquations should be a two element list: the first element applies to the first set of equations of the TimeSwitch pair, the second element applies to the second set. Allowable values for each element are a list of integers (1 through the number of degrees of freedom in the constraint), All, or Sum. If All is specified, all of the constraints in that side of the TimeSwitch are used. Sum causes the sum of all the equations in the specified side of the TimeSwitch to be used as a single constraint, which may lead to a singularity. A list of integers uses the equations explicitly specified by their position in the constraint. The default setting is RequiredEquations → {All, Sum}.
Options for FindSwitchTime.
To understand the need for the RequiredEquations option, imagine a two degree of freedom Time Switch. If both sides of the adjacent two degree of freedom constraint pair are used simultaneously, two extra constraints are added to the model, but only one degree of freedom (time) is added. This results in an overconstrained model to which no solution can be found.
MechanicalSystems
204
The default setting RequiredEquations → {All, Sum} deals with this problem in a general but unsophisticated manner. All of the constraint equations from the first side of the TimeSwitch pair are used, as well as a single equation formed from the sum of all the equations from the second side, resulting in the required one extra constraint equation. This combination of constraints is valid if all of the equations in the second side of the constraint pair except one are redundant with respect to the equations in the first side. Thus the redundant equations in the sum are satisfied because of the first side of the constraint pair, and the one nonredundant equation is satisfied by the satisfying the sum. However, if there is no redundancy in the pair this will not work, and the solution will fail. If the default setting fails, the user must explicitly specify which equations to use to seek the switch time. For example, take the following TimeSwitch example that was given in the beginning of this section. Here is a TimeSwitch example. In[25]:= TimeSwitch@3,
Revolute2@1, Point@slider, 80, 0
To seek the correct value of the switch time, which is currently set to 3.5, the following FindSwitchTime example could be used with all of the default option settings. Note that the TimeSwitch constraint is constraint number 3. Here is a command to find the correct value of the switch time. FindSwitchTime@3, 1D
The default setting for RequiredEquations works fine in this case because the first constraint equation in the second side of the TimeSwitch constraint (PointOnLine1) is redundant with the first side of the TimeSwitch constraint (Revolute2), because PointOnLine1 must be satisfied for Revolute2 to be satisfied. The following example shows a setting for RequiredEquations that explicitly specifies which equations to use. This setting would cause only the RelativeY1 constraint to be used from the second side of the TimeSwitch constraint. Here is a setting of the RequiredEquations option.
FindSwitchTime@3, 1, RequiredEquations → 8All, 82<
Chapter 5: Multistage Mechanisms
205
When the RequiredEquations option is used with a TimeSwitch that contains multiple degree of freedom constraint functions, such as Revolute2 (2D) or Cylindrical4 (3D), it is necessary to know exactly what each of the 2, 3, 4, or 5 equations in the constraint are doing, so that you can know which ones need to be specified with the RequiredEquations option. To find out “which equation does what,” see the notes on the particular constraint function in the appendix. Detent Mechanism Example In the detent mechanism example in Section 5.2.2, the values given for the switch times that were assigned variable names (tm2 = – 0.8, tm3 = – 0.4, etc.) were merely guesses. FindSwitchTime is used to find the correct values of the switch times. The first and sixth switch times were set to values of – 1 and 1, respectively, which are exact values evident from the geometry of the detenter and notch. The value of the second switch time must be found with FindSwitchTime. This is the time at which the detenter stops traveling around the sharp corner on the upper-right side of the detent notch and passes onto the inclined right side of the notch. These two adjacent constraints come into conjunction tangentially because there is no velocity discontinuity as the detenter passes onto the inclined flat side of the detent notch. Thus, FindSwitchTime must actually search for the point of tangency. This requires that the option TangentConstraint → True be specified. Before FindSwitchTime is invoked, SolveMech is used to move the mechanism close to the correct position to provide better initial guesses.
This finds switch time 2 in constraint 4. In[26]:= SolveMech@−1.1D;
FindSwitchTime@4, 2, TangentConstraint → TrueD
Out[27]= 8T → −0.787868, X2 → −0.787868, Y2 → 0., Θ2 → 0., X3 → 2., Y3 → 1.21213,
Θ3 → 0., X2d → 1., Y2d → 0., Θ2d → 0., X3d → 0., Y3d → −1., Θ3d → 0.<
This sets the value of tm2.
In[28]:= tm2 = T ê. % Out[28]= −0.787868
206
MechanicalSystems
Here is the detent mechanism at the tangency point associated with tm2.
The third switch point occurs when the detenter passes from the inclined right side of the detent notch onto the round bottom of the notch. This is also a tangent constraint pair, so TangentConstraint → True is used again.
This finds and sets switch time 3 in constraint 4.
In[29]:= tm3 = T ê. FindSwitchTime@4, 3, TangentConstraint → TrueD Out[29]= −0.287868
Here is the detent mechanism at the tangency point associated with tm3.
Chapter 5: Multistage Mechanisms
207
Because of symmetry, the values of tm4 and tm5 are known to be the negatives of tm3 and tm2, respectively. With all of the switch times set to valid values, the detent mechanism model can be run at any value of time.
Set the last two switch times. In[30]:= tm4 = −tm3;
tm5 = −tm2;
6. Cams and Gears Overview This chapter covers the modeling of contacting cam surfaces and gear trains with MechanicalSystems. Cam constraints allow the definition of arbitrary curves or surfaces that operate in tangent contact with other curves, surfaces, or points in a Mech model. Cams are supported in 2D or 3D models, and 3D cams may be spatial curves or surfaces. Gear constraints are used to model several types of nominal gear relationships, such as a pair of spur gears, a rack and pinion, or a lead screw. These constraints are referred to as nominal gear constraints because only the nominal rotary motion is modeled, not the tooth-to-tooth interactions of an involute gear set.
6.1 Cam Constraints A cam relationship is considered to be any relationship in which an arbitrarily defined space curve or surface is constrained to be in intimate contact with another point, curve, or surface. MechanicalSystems provides several special constraint functions that allow such arbitrary geometric elements to be used in the mechanism model. The definitive characteristic of cam constraints is that they force two surfaces to be simultaneously in contact with each other and, in most cases, tangent with each other at the point of contact.
6.1.1 2D Cam Constraints The 2D cam constraints provided by Modeler2D cover four elementary cases of a cam and follower mechanism. In each case, the cam surface is defined by the locus of a single 2D point that is a function of one symbolic parameter. For example, the following 2D points are defined parametrically as functions of the symbol s. Each of these locuspointi would be valid as a Modeler2D cam profile.
MechanicalSystems
210
Here is a valid Modeler2D cam profile.
In[1]:= locuspoint1 = 8s, Sin@s2 D<;
ParametricPlot@Evaluate@locuspoint1D, 8s, −2, 2
-1
1
2
-0.25 -0.5 -0.75
Out[2]=
Graphics
Here is another Modeler2D cam profile. In[3]:= locuspoint2 = 9IfA
N@πD
<s<
3 N@πD
, 1, 1 + Cos@sDE Cos@sD, Sin@sD=; 2 2 ParametricPlot@Evaluate@locuspoint2D, 8s, 0, 2 π
0.5
-1
-0.5
0.5
1
1.5
2
-0.5
-1
Out[4]=
Graphics
Note that although the Modeler2D cam constraints constrain one degree of freedom in the mechanism model, they actually add two (or three, as in CamToCam1) equations to the model. This is because each cam constraint also adds one (or two) symbols to the model’s dependent variable list for a net loss of one degree of freedom. This anomaly is of no consequence to the user except when a cam constraint is used within Time Switch or StageSwitch. In these cases, the added symbol in the cam constraint must be dealt with in the
Chapter 6: Cams and Gears
211
other stages of the switch function, usually by using the Modeler2D Constraint function to set the added symbol equal to a constant.
CamToPoint1[cnum, locuspoint, {alpha, guess}, point]
models a cam profile with a point follower point. The locus of locuspoint defines the cam profile as a function of the symbol alpha (locuspoint must be defined as a differentiable parametric function of alpha). CamToPoint1 enforces that the specified point lies in contact with the cam profile.
CamToCircle1[cnum, locuspoint, {alpha, guess}, point, rad]
models a cam profile with a circular follower. The locus of locuspoint defines the cam profile as a function of the symbol alpha. CamToCircle1 enforces that the cam profile lies tangent to a circle of radius rad centered at point. The circular follower lies on the left side of the cam profile (rad positive) when traveling along the locus in the direction of increasing alpha.
CamToLine1[cnum, locuspoint, {alpha, guess}, axis]
models a cam profile with a flat follower. The locus of locuspoint defines the cam profile as a function of the symbol alpha. CamToLine1 enforces that the cam profile lies tangent to the specified axis.
CamToCam1[cnum, locuspoint1, {alpha, guess}, locuspoint2, {beta, guess}]
models two cam profiles that lie in contact with each other. The locus of locuspoint1 defines the first cam profile as a function of the symbol alpha, while locuspoint2 defines the second cam profile as a function of the symbol beta. CamTo Cam1 enforces that the two cam profiles lie tangent to and in contact with each other.
2D cam constraints.
The locus point that is passed to a Modeler2D cam constraint must be a valid Modeler2D point object containing the parametrically defined point. Also, the point must evaluate to a two-element list of differentiable expressions that are functionally dependent on the parameter alpha at the time the constraints are processed with SetConstraints. This is because the locus point is differentiated with respect to the parameter alpha by SetConstraints. Thus, if the locus point is not a function of alpha when passed to SetConstraints its derivative will be zero.
MechanicalSystems
212
A special graphics function CamPlot is provided to parametrically plot the cam profiles in global coordinates. Note that CamPlot returns a Mathematica graphics object with the head Graphics, not a graphics primitive like most other Modeler2D graphics functions.
CamPlot[locuspoint, {alpha, min, max}, options]
returns a graphics object representing the cam profile that is defined by the locus of locuspoint, which must be a parametric function of the symbol alpha. The SysPlot object returned by CamPlot is not evaluated until numeric values are available for Xn, Yn, and so on, where n is the body number of the cam body.
CamPlot[bnum, {lpnt…}, {alpha, min, max}]
plots several point loci lpnti on body bnum. CamPlot accepts the same options as ParametricPlot, with some different defaults.
A cam-specific graphics function.
CamPlot produces the same output as would the built-in Mathematica ParametricPlot, except that CamPlot transforms the local cam profile into the global coordinate system. CamPlot does not evaluate directly to a Graphics object unless numeric values for the coordinate transformation are available. Instead, CamPlot evaluates to a SysPlot object that evaluates to a Graphics object when numbers are available for the transformation.
This loads the Modeler2D package. In[5]:= Needs@"MechanicalSystems`Modeler2D`"D
CamPlot returns a SysPlot object.
In[6]:= CamPlot@Point@2, locuspoint2D, 8s, 0, 2 π<, Frame → True, AspectRatio → AutomaticD Out[6]= SysPlot@8X2, Y2<, 88Cos@Θ2D, −Sin@Θ2D<, 8Sin@Θ2D, Cos@Θ2D<<,
88Cos@sD [email protected] < s < 4.71239, 1, 1 + Cos@sDD, Sin@sD<<, <>D
When numbers are available for X2, Y2, and Θ2, the SysPlot object evaluates to a Graphics object.
Chapter 6: Cams and Gears
213
Here is the repositioned cam.
In[7]:= Show@% ê. 8X2 → 1, Y2 → −2, Θ2 → 0.5
-1.5
-2
-2.5
-3 0
Out[7]=
0.5
1
1.5
2
2.5
Graphics
6.1.2 Example 2D Cam Mechanism To demonstrate the use of Modeler2D cam functions a 2D model of a rotating cam with a flat follower is developed. The model consists of two moving bodies, the cam and the follower.
Here is the 2D cam-follower mechanism.
MechanicalSystems
214
Cam Profile The cam profile used for this mechanism is defined in terms of trigonometric functions of the symbol alpha. The cam profile expression may contain user-defined parameters that are defined at runtime, but all of the functional dependence on the controlling parameter alpha must be present when the cam constraint is processed with SetConstraints. Thus, it is not possible to leave the cam profile defined as simply a two-element list of symbols, such as {xcam, ycam}, and then define xcam and ycam as functions of alpha at runtime.
Here are two parametric expressions defining the locus of the cam profile. In[8]:= Off@General::"spell1"D
alpha; beta; On@General::"spell1"D camprof = 83 Cos@alphaD, 3 Sin@alphaD + Sin@2 alphaD<;
Here is a plot of the cam profile.
In[12]:= ParametricPlot@Evaluate@camprofD, 8alpha, 0, 2 π<, AspectRatio → AutomaticD
3
2
1
-3
-2
-1
1 -1
-2
-3
Out[12]=
Graphics
2
3
Chapter 6: Cams and Gears
215
Bodies Three bodies are used for the cam-follower model.
Names are defined for each of the body numbers in the model. In[13]:= ground = 1;
cam = 2; follower = 3;
• Two points are required on the ground (body 1). P1 is the rotational axis of the cam at {0, 0}. P2 is the pivot axis of the follower at {– 3.5, 4.0}. • Two points are required on the cam (body 2). P1 is the rotational axis of the cam at local coordinate {0, 0}. P2 is the locus point of the cam that was previously defined and named camprof. • Three points are required on the follower (body 3). P1 is the pivot axis of the follower at local coordinate {0, 0}. P2 is the left end {0.5, – 1} of the flat surface that contacts the cam. P3 is the right end {6.5, – 1} of the flat surface that contacts the cam. Here are all of the bodies in the cam-follower model. P2 {-3.5,4} P2 at alpha=0 P1 {0,0} P1
P1
P2
P3
MechanicalSystems
216
This is to set a nonzero initial guess for the rocker.
In[16]:= SetBodies@Body@follower, InitialGuess → 88−3.5, 4.0<, 0.0
Constraints Three regular constraints and one CamToLine1 constraint are required to model the cam-follower mechanism. • A Revolute2 constraint forces the center of the cam to be coincident with its rotational axis on the ground. • A Revolute2 constraint forces the pivot point of the follower to be coincident with its axis on the ground. • A RotationLock1 constraint controls the angular coordinate of the cam. This driving constraint is used to specify the rotation of the cam as a function of T. • A CamToLine1 constraint controls the single remaining degree of freedom. The point and line arguments are given in the same manner as would be used with any other constraint, except for the requirement that the local coordinates of the point be a function of the symbol alpha. Note that while CamToLine1 constrains one degree of freedom in the model, it actually adds two equations (one that forces the locus point to lie on the line and one that forces the line to be tangent to the cam at the point of contact) and one unknown alpha to the model.
Here are the constraints for the cam-follower mechanism. In[17]:= SetConstraints@
Revolute2@1, Point@cam, 0D, Point@ground, 0DD, Revolute2@2, Point@follower, 0D, Point@ground, 8−3.5, 4
Runtime The cam-follower mechanism model can now be run in the usual manner. Note the presence of the cam parameter alpha in the solution rule. At this value of alpha the cam locus point is placed at the point of contact between the cam and the follower.
Chapter 6: Cams and Gears
Now we run the model at T = 0.15. In[18]:= [email protected]
Out[18]= 8T → 0.15, X2 → −9.51972 × 10−23 , Y2 → 1.84027 × 10−24 ,
Θ2 → 0.942478, X3 → −3.5, Y3 → 4., Θ3 → 0.261379, alpha → 0.836663<
Here is the cam-follower mechanism at T = 0.15.
Now run the model at T = 0.30. In[19]:= [email protected]
Out[19]= 8T → 0.3, X2 → 0., Y2 → 3.03648 × 10−24 , Θ2 → 1.88496,
X3 → −3.5, Y3 → 4., Θ3 → 0.0476971, alpha → −0.39127<
217
218
MechanicalSystems
Here is the cam-follower mechanism at T = 0.30.
6.1.3 3D Cam Constraints The 3D cam constraints provided by Modeler3D cover eight elementary cases of a cam and follower relationship. The 3D cam profiles used by Modeler3D fall into two basic categories: spatial surfaces and spatial curves. Spatial surfaces are defined by the locus of a single 3D point, the coordinates of which are a function of two independent parameters. Space curves are defined by a point that is a function of a single parameter. In practice many 3D cam profiles are 2D in nature, in which case they are modeled using the techniques that were developed in Section 6.1.2 on 2D cams. Any 2D cam profile can be converted to a 3D space curve by inserting or appending a third constant coordinate to the 2D locus point. Even when a true 3D surface profile is required, it can often be built up from the sum of two 2D curves that are functions of two different parameters. The following example uses one of the 2D cam profiles that was developed in Section 6.1.1 to generate a 3D cam surface. The only change to the 2D cam is the addition of the parameter t that directly specifies the local y coordinate of the cam. This example would serve as a valid cam profile for any Modeler3D cam constraint function.
Chapter 6: Cams and Gears
219
Here is a valid Modeler3D cam profile. In[20]:= locuspoint = 9IfA
N@πD 2
<s<
3 N@πD 2
, 1, 1 + Cos@sDE Cos@sD, t, Sin@sD=;
Here is a plot of the cam profile.
In[21]:= ParametricPlot3D@Evaluate@locuspointD, 8s, 0, 2 π<, 8t, 0, 2<, PlotPoints → 835, 2
Graphics3D
Note that although the Modeler3D cam constraints constrain one degree of freedom in the model (or two in the case of CurveToPoint2), they actually add between two and five equations to the model. This is because each cam constraint also adds one to four symbols to the model’s dependent variable list (two parameters for each surface and one for each curve) for a net loss of one or two degrees of freedom. This anomaly is of no consequence to the user except when a cam constraint is used within TimeSwitch or StageSwitch. In these cases the added symbols in the cam constraint must be dealt with in the other stages of the switch function, usually by using the Modeler3D Constraint function to set the added symbols equal to a constant.
MechanicalSystems
220
CurveToPoint2[cnum, locuspoint, {alpha, guess}, point]
models a space curve with a point follower. The locus of locuspoint defines the space curve as a function of the symbol alpha (locuspoint must be a differentiable parametric function of alpha). CurveToPoint2 enforces that point lies on the locus of the space curve, constraining two degrees of freedom.
CurveToPlane1[cnum, locuspoint, {alpha, guess}, axis]
constrains a space curve to lie in contact with a plane that is normal to axis. The locus of locuspoint defines the space curve as a function of the symbol alpha.
CurveToCylinder1[cnum, locuspoint, {alpha, guess}, axis, rad]
contains a space curve to be in tangent contact with a cylinder with specified axis and radius rad. The locus of locuspoint defines the space curve as a function of the symbol alpha.
CurveToCam1[cnum, locuspoint1, {alpha, guess}, locuspoint2, {gamma, guess}, {delta, guess}]
constrains a space curve to be in tangent contact with a spatial surface. The locus of locuspoint1 defines the space curve as a function of the symbol alpha, and the locus of locuspoint2 defines the spatial surface as a function of gamma and delta.
Space curve constraints.
Chapter 6: Cams and Gears
CamToPoint1[cnum, locuspoint, {alpha, guess}, {beta, guess}, point]
221
models a spatial surface with a point follower. The locus of locuspoint defines the cam surface as a function of alpha and beta. CamToPoint1 enforces that point lie directly on the cam surface.
CamToSphere1[cnum, locuspoint, {alpha, guess}, {beta, guess}, point, rad]
models a spatial surface with a spherical follower. The locus of locuspoint defines the cam surface as a function of alpha and beta. CamToSphere1 enforces that the surface is in contact with a sphere of radius rad centered at point.
CamToPlane1[cnum, locuspoint, {alpha, guess}, {beta, guess}, axis]
models a spatial cam surface with a planar follower. The locus of locuspoint defines the cam surface as a function of alpha and beta. CamToPlane1 enforces that the cam surface lie in tangent contact with a plane specified by axis.
CamToCam1[cnum, locuspoint1, {alpha, guess}, {beta, guess}, locuspoint2, {gamma, guess}, {delta, guess}]
models two spatial cam surfaces in tangent contact with each other. The loci of the locuspointi define the cam surfaces as functions of alpha, beta, gamma, and delta.
Spatial surface constraints.
Note that each symbol in a cam constraint must be accompanied by a numerical initial guess, guess. The locus point that is passed to a Modeler3D cam constraint must be a valid Modeler3D point object containing the parametrically defined point. Also, the point must evaluate to a three-element list of differentiable expressions that are functionally dependent on the parameter alpha, at the time that the constraints are processed with SetConstraints. This is because the locus point is differentiated with respect to its controlling parameters by the SetConstraints function. Thus, if the locus point is not an explicit function of its parameters when passed to SetConstraints its derivative will be zero. Note that all cam relationships are restricted to being in point contact. If two cam surfaces are defined such that they instantaneously have line contact instead of point contact, a singularity will result. Some cam constraints are sensitive to which side of the cam surface the follower is on. The outside of a surface is defined as the side of the positive normal, which is the cross product of the direction of the surface gradient with respect to the first parameter and the direction of the surface gradient with respect to the second parameter.
MechanicalSystems
222
CamPlot is a special graphics function provided to parametrically plot the cam profiles in global coordinates. Note that CamPlot returns a Mathematica graphics object, with the head Graphics, not a graphics primitive like most of the other Modeler3D graphics functions.
CamPlot[locuspoint, {alpha, min, max}, options]
returns a graphics object representing the space curve that is defined by the locus of locuspoint, which must be a parametric function of the symbol alpha. The SysPlot object returned by CamPlot is not evaluated until numeric values are available for Xn, Yn, and so on, where n is the body number of the cam body.
CamPlot[locuspoint, {alpha, min, max}, {beta, min, max}] CamPlot[bnum, {lpnt, …}, {alpha, min, max}, …]
plots a spatial surface that is a parametric function of alpha and beta. plots several point loci lpnti on body bnum. CamPlot accepts the same options as ParametricPlot with some different defaults.
A cam-specific graphics function.
CamPlot produces the same output as would ParametricPlot, except that CamPlot transforms the cam profile into the global coordinate system. CamPlot does not evaluate directly to a Graphics object because numeric values for the coordinate transformation are not available. Instead, CamPlot returns a SysPlot object that evaluates to a Graphics object when numbers are available for the transformation.
This loads the Modeler3D package. In[22]:= Needs@"MechanicalSystems`Modeler3D`"D
Chapter 6: Cams and Gears
CamPlot returns a SysPlot object.
In[23]:= CamPlot@Point@2, locuspointD, 8s, 0, 2 π<,
8t, 0, 2<, PlotPoints → 835, 2<, Boxed → TrueD
Out[23]= SysPlotA8X2, Y2, Z2<,
1 + Ei22 + Eo22 N, 2 HEi2 Ej2 − Ek2 Eo2L, 2 HEi2 Ek2 + Ej2 Eo2L=, 2 1 92 HEi2 Ej2 + Ek2 Eo2L, 2 J− + Ej22 + Eo22 N, 2 HEj2 Ek2 − Ei2 Eo2L=, 2 1 92 HEi2 Ek2 − Ej2 Eo2L, 2 HEj2 Ek2 + Ei2 Eo2L, 2 J− + Ek22 + Eo22 N==, 2 88Cos@sD [email protected] < s < 4.71239, 1, 1 + Cos@sDD, t, Sin@sD<<, <>E
992 J−
When numbers are available for X2, Y2, and so on, the SysPlot object evaluates to a Graphics object.
Here we show the repositioned cam surface.
In[24]:= Show@% ê. 8X2 → 1, Y2 → −2, Z2 → 0.5, Eo2 → .7, Ei2 → .7, Ej2 → 0, Ek2 → 0
Out[24]=
Graphics3D
223
224
MechanicalSystems
6.1.4 Example 3D Cam Mechanism To demonstrate the use of Modeler3D cam functions, a 3D model of a rotating cam with a spherical follower is developed. The model consists of two moving bodies, the cam and the follower.
Here is the 3D cam-follower model.
Cam Profile The cam profile used for this mechanism is defined in terms of trigonometric functions of the symbols alpha and beta. The cam profile expression may contain user-defined parameters that are defined at runtime, but all of the functional dependence on the controlling parameters, alpha and beta, must be present when the cam profile is processed with SetConstraints. Thus, it is not possible to leave the cam profile defined as simply a three element list of symbols, such as {xcam, ycam, zcam}, and then define xcam, ycam, and zcam as functions of alpha and beta at runtime. The cam surface is the same as the one developed and plotted in Section 6.1.3.
Chapter 6: Cams and Gears
225
Here are the parametric expressions defining the locus of the cam surface. In[25]:= camsurf = 9IfA
N@πD 2
< alpha <
3 N@πD 2
, 1, 1 + Cos@alphaDE Cos@alphaD, beta, Sin@alphaD=;
Bodies Three bodies are used for the cam-follower model.
Names are defined for each of the body numbers in the model. In[26]:= ground = 1;
cam = 2; follower = 3;
• Four points are required on the ground (body 1). P1 and P2 are the two ends of the rotational axis of the cam at local coordinates {0, 0, 0} and {0, 2, 0}. P3 and P4 are the two ends of the rotational axis of the follower at local coordinates {– 2, 0, 2} and {– 2, 2, 2}. • Three points are required on the cam (body 2). P1 and P2 are the two ends of the rotational axis of the cam at local coordinates {0, 0, 0} and {0, 2, 0}. P3 is the locus point of the cam that was previously defined and named camsurf. • Three points are required on the follower (body 3). P1 and P2 are the two ends of the rotational axis of the follower at local coordinates {0, 0, 0} and {0, 2, 0}. P3 is the center of the spherical cam follower at {2, 1, 0}.
MechanicalSystems
226
Here are all of the bodies in the cam model. P4 P3
P2
P2
P1 P1
P2
P1
P3
SetBodies is used here only to set a nonzero initial guess for the follower.
In[29]:= SetBodies@Body@follower, InitialGuess → 88−2, 0, 2<, 81, 0, 0, 0<
Constraints Three regular constraints and one cam constraint are required to model the cam-follower mechanism. • A Revolute5 constraint forces the axis of the cam to be coincident with its rotational axis on the ground. • A Revolute5 constraint forces the pivot axis of the follower to be coincident with its axis on the ground.
Chapter 6: Cams and Gears
227
• A ProjectedAngle1 constraint controls the angular coordinate of the cam. This driving constraint specifies the rotation of the cam as a function of T. • A CamToSphere1 constraint controls the one remaining degree of freedom. The point arguments to CamToSphere1 are given in the same syntax as would be used with any other Modeler3D constraint, except for the requirement that the local coordinates of the locuspoint be a function of the symbols, alpha and beta. Note that while CamToSphere1 constrains one degree of freedom in the model, it actually adds three equations (one that forces the spherical follower to lie a specified distance away from the cam surface, and two more that force the cam surface to be tangent at the point of contact) and two unknowns, alpha and beta, to the model.
Here are the constraints for the cam-follower mechanism. In[30]:= SetConstraints@
Revolute5@1, Line@cam, 0, 80, 2, 0
Runtime The cam-follower mechanism model can now be run in the usual manner. Note the presence of the cam parameters, alpha and beta, in the solution rule. At these values of alpha and beta the cam locus point is placed at the point of contact between the cam and the follower.
MechanicalSystems
228
Now the model is run at T = 0.10. In[31]:= [email protected]
Out[31]= 8T → 0.1, X2 → 9.98657 × 10−24 , Y2 → 0., Z2 → 2.87634 × 10−24 , Eo2 → 0.951057,
Ei2 → 0., Ej2 → −0.309017, Ek2 → 0., X3 → −2., Y3 → 0., Z3 → 2., Eo3 → 0.995552, Ei3 → 0., Ej3 → 0.0942108, Ek3 → 0., alpha → 1.0276, beta → 1.<
Here is the cam-follower mechanism at T = 0.1.
The model is run again at T = 0.20. In[32]:= [email protected]
Out[32]= 8T → 0.2, X2 → 8.3336 × 10−27 , Y2 → 0., Z2 → −1.1674 × 10−25 , Eo2 → 0.809017,
Ei2 → 9.36335 × 10−97 , Ej2 → −0.587785, Ek2 → −4.68168 × 10−97 , X3 → −2., Y3 → 0., Z3 → 2., Eo3 → 0.997727, Ei3 → 0., Ej3 → −0.0673925, Ek3 → 0., alpha → 0.359376, beta → 1.<
Chapter 6: Cams and Gears
229
Here is the cam-follower at T = 0.20.
6.1.5 Splined Cams In designing an arbitrary cam mechanism it is necessary to be able to describe an arbitrary cam surface, one that is not constrained to be a series of piecewise continuous functions each coded in by the user, such as the examples in Sections 6.1.2 and 6.1.4. One way to define such an arbitrary curve or surface is with Mathematica’s InterpolatingFunction objects built with the Interpolation function. Thus, the required sequence of piecewise continuous functions is assembled by Mathematica, while the user merely inputs discrete data. While a cam surface so defined may work in a Mech model, it may also create some numerical problems. One basic requirement for a valid Mech cam profile is that it have zeroth- and first-order continuity. The Interpolation function uses cubic interpolation to fit the polynomials to the supplied data. This results in a curve that has zeroth-order, not first-order, continuity. Since the first-order discontinuities in an Inter polatingFunction cam are typically small, such a cam usually works fine until it happens to seek a solution point that has its point of contact on the cam directly on a cusp in the interpolating function. To get around this difficulty Mech provides a function for creating cubic spline objects that have zeroth-, first-, and second-order continuity at each knot point. Mech’s SplineFit function is similar to the Spline
MechanicalSystems
230
Fit function that is included with the standard Mathematica packages, but it has been enhanced to allow 3D space curves, and the SplineFunction objects it returns are differentiable.
SplineFit[data, options]
returns a SplineFunction object representing data as a continuous cubic spline. data may be a list of 2D or 3D point coordinates.
SplineFunction[range, <>][number]
evaluates the SplineFunction object with the independent parameter set to number.
The function for creating splines.
Parameters
is an option for SplineFit that explicitly specifies the values of the spline’s parameter at each knot point. Parame ters may be a list of numbers in ascending order. The default setting Parameters → Automatic implies Parame ters → {0, 1, 2, …}.
EndConditions
is an option for SplineFit that is used to specify the end conditions of the spline.
Natural
is a setting for EndConditions that specifies zero curvature at both ends of the spline.
Closed
is a setting for EndConditions that specifies identical slope and curvature at both ends of the spline.
EndConditions → {vec, vec}
specifies the direction vector at each end of the spline.
Options for SplineFit.
Note that it is necessary to provide a list of data points with identical first and last points if a Closed spline is desired. The EndConditions → Closed setting only ensures that the slope and curvature are continuous at the ends. The supplied data must provide zeroth-order continuity.
Chapter 6: Cams and Gears
231
A closed cam profile in 2D space could be defined with a SplineFunction object.
This loads the Modeler2D package. In[33]:= Needs@"MechanicalSystems`Modeler2D`"D
Here is some data to be splined.
In[34]:= knotpoints = 880, 1.5<, 8.75, .75<, 81, 0<, 8.707, −.707<,
80, −1<, 8−.707, −.707<, 8−1, 0<, 8−.75, .75<, 80, 1.5<<;
Now we generate a SplineFunction object. In[35]:= splinelocus = SplineFit@knotpoints, EndConditions → ClosedD Out[35]= SplineFunction@80, 8<, <>D
Here is a plot of the spline.
In[36]:= ParametricPlot@splinelocus@sD, 8s, 0, 8<, AspectRatio → AutomaticD 1.5
1
0.5
-1
-0.5
0.5
-0.5
-1
Out[36]=
Graphics
1
MechanicalSystems
232
If it were desired to use this cam profile in a Modeler2D model with a circular cam follower, the following constraint syntax could be used. This constraint implies that the cam is on body 2, the circular follower is on the origin of body 3 and has a radius of 0.2, the constraint is constraint 4, and the initial guess for the cam parameter s is 2.0.
Here is a cam constraint that uses a splined cam.
In[37]:= CamToCircle1@4, Point@2, splinelocus@sDD, 8s, 2.0<, Point@3, 80, 0D
6.1.6 Rolling Contact In order to have rolling contact between two cams, the arc length along the cam profile must be known as a function of the cam’s controlling parameter. For cams that are built up from a sequence of piecewise continuous analytic functions, such as those shown in Section 6.1.1, it is often possible to build up a similar function that exactly represents the arc length of the cam. If a SplineFunction cam was used, the arc length cannot be explicitly stated, but Mech provides a function for approximating the arc length with another cubic spline.
ArcLength[splinefunc]
returns a 1D SplineFunction object representing the arc length of the supplied SplineFunction.
A spline utility.
Example Mechanism The following example models a snail-shaped cam profile rolling on a stationary line. The cam is defined with a SplineFunction, and it is the single moving body in the mechanism. Note how the EndCondi tions option for SplineFit is used to specify the direction vector at the ends of the spline.
Here are data points for a snail profile.
In[38]:= data = PolarToXY ê@ Table@84 − i, i N@πD<, 8i, 1, 3, .2
Chapter 6: Cams and Gears
233
SplineFit is applied to the data.
In[39]:= splinelocus = SplineFit@data, EndConditions → 88.106, −.994<, 8.152, −.476<D
Here is a plot of the spline.
In[40]:= ParametricPlot@splinelocus@sD, 8s, 0, 10<, AspectRatio → AutomaticD
1
-3
-2
-1
1
2
-1
-2
Out[40]=
Graphics
To constrain the snail-wheel to be in rolling contact, the arc length function of both contacting surfaces must be known. Since one of the two surfaces in this model is flat and has a trivial arc length function, only the arc length function of the snail-wheel must be determined. The Mech ArcLength function may work quite slowly, because it involves numerically integrating each segment of the SplineFunction object.
Here is the arc length function of the snail spline. In[41]:= splinearc = ArcLength@splinelocusD Out[41]= SplineFunction@80, 10<, <>D
MechanicalSystems
234
Constraints The snail-wheel is modeled with just three constraints. • A CamToLine1 constraint places the snail-wheel in contact with the surface of the ground. Note the initial guess for the cam parameter s that sets the initial contact point at the bottom of the cam. • A RotationLock1 constraint controls the angular orientation of the snail-wheel. • A Constraint sets the arc length along the snail-wheel equal to the arc length along the flat surface. The arc length along the flat surface is simply the X coordinate of the cam contact point. Names are defined for each body. In[42]:= ground = 1;
cam = 2;
Here are the snail-wheel constraints. In[44]:= SetConstraints@
CamToLine1@1, Point@cam, splinelocus@sDD, 8s, 2<, Line@ground, 80, 0<, 81, 0
Reasonable initial guesses are set for the snail-wheel. In[45]:= SetGuess@8X2 → 4, Y2 → 2.5
Now we run the model at three positions. In[46]:= SolveMech@80, −0.2, −0.4
Out[46]= 88T → 0, X2 → 4.34519, Y2 → 2.50884, Θ2 → −4.27426 × 10−24 , s → 2.28682<,
8T → −0.2, X2 → 7.26072, Y2 → 2.12282, Θ2 → −1.25664, s → 4.26194<, 8T → −0.4, X2 → 9.68032, Y2 → 1.72878, Θ2 → −2.51327, s → 6.21262<<
Chapter 6: Cams and Gears
235
Snail-wheel graphic at each solution point. y 2
x y
2 x
2 x
y
Analytic Snail-Wheel In fact, this particular mechanism could have been modeled without the use of SplineFunction at all. The snail-wheel cam profile can be built from analytic functions and its arc length can be found using Mathematica’s symbolic integration capability.
Here is the definition of an analytic snail-wheel. In[47]:= ansplinelocus = PolarToXY@84 − s, s N@πD
Out[47]= 8H4 − sL [email protected] sD, H4 − sL [email protected] sD<
Here is the exact arc length function of the snail-wheel. In[48]:= ansplinearc = ‡
i
"##################################################################### # Plus @@ H∂s ansplinelocusL2
j Out[48]= 3.14159 j jH−2. + 0.5 sL
s
è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! HH−4. − 0.31831 L + sL HH−4. + 0.31831 L + sL +
k è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! HH−4. − 0.31831 L + sL HH−4. + 0.31831 L + sL + è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! H−4. − 0.31831 L + s H−4. + 0.31831 L + s è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I0.0506606 HH−4. − 0.31831 L + sL HH−4. + 0.31831 L + sL è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! LogA−4. + H−4. − 0.31831 L + s H−4. + 0.31831 L + s + sEM ë 0.
è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! y z I H−4. − 0.31831 L + s H−4. + 0.31831 L + s Mz z {
MechanicalSystems
236
Here is a plot of the exact arc length function and the approximate arc length function, normalized to the same parameter scale and offset.
In[49]:= Plot@Evaluate@8ansplinearc − Hansplinearc ê. s → 1L, splinearc@5 Hs − 1LD
1.5 Out[49]=
2
2.5
3
Graphics
6.1.7 Fourier Cams Another method of modeling arbitrary cam profiles is by approximating the cam profile with a Fourier series of sine and cosine functions. This method guarantees a continuously differentiable cam profile and also may evaluate more quickly than a SplineFunction object, provided only a relatively small number of terms are retained. One disadvantage of a Fourier series based cam profile is that it does not pass exactly through the data points used to generate it. The following example uses a series of points in Cartesian coordinates that are to lie on the surface of a closed cam profile. The profile has a protruding lobe for 1/4 of a turn and is approximately circular with a radius of 3.0 for the next 3/4 of a turn. The built-in Mathematica Fourier function is used to generate the Fourier series.
Here is the data to be transformed.
In[50]:= data = JoinA883.08599, 0.61384<, 83.23358, 1.33939<, 83.20411, 2.14091<,
82.82843, 2.82843<, 82.14092, 3.20411<, 81.33939, 3.23358<, 80.61384, 3.08599<<, N@πD 3 N@πD TableA3 8Cos@iD, Sin@iD<, 9i, , 2 N@πD, =EE; 2 2 24 len = Length@dataD;
Chapter 6: Cams and Gears
237
Fourier is used to transform the data. Note that the zero-frequency term in each series must be divided by two to map correctly back into the time domain with Sin and Cos functions. In[52]:= fourierdata =
Fourier ê@ Transpose@dataD 2 ; è!!!!!!!!!! NA len E
fourierdataP1, 1T ê= 2; fourierdataP2, 1T ê= 2;
Here are the first 10 terms of the approximate periodic function. In[55]:= terms = 10;
fourierlocus = HTake@Re@#1D, termsD.Table@Cos@i sD, 8i, 0, terms − 1
Here is a plot of the Fourier profile along with the data points.
In[57]:= Show@Graphics@[email protected], Point ê@ data
ParametricPlot@Evaluate@fourierlocusD, 8s, 0, 2 π<, DisplayFunction → IdentityD, AspectRatio → AutomaticD
Out[57]=
Graphics
MechanicalSystems
238
6.1.8 Cam Constraints within a Multistage Constraint When a cam constraint is used within a TimeSwitch or StageSwitch function, the extra degrees of freedom that are introduced by the cam constraint must be dealt with when the cam constraint is not active. The following example shows how a TimeSwitch constraint might be used with a Modeler2D CamTo Plane1 constraint.
Here is an example of a TimeSwitch with a cam constraint.
In[58]:= H∗
TimeSwitch@1, CamToPlane1@1,Point@cam,camsurfD,8alpha,1.2<, 8beta,2.4<,Plane@follower,80,0,0<,80,2,0<,82,1,0
When the value of time exceeds 2.5 the one mechanical degree of freedom that was constrained by CamTo Plane1 is constrained by RelativeAngle1, while the values of the two cam surface parameters alpha and beta are constrained to be equal to two constants. If this technique were not used, the values of alpha and beta would be unconstrained after T = 2.5 and the model would not run.
6.1.9 Involute Gears A single pair of involute gear teeth can be modeled with Modeler2D as a pair of cam surfaces. Modeler2D provides a function for generating the involute profiles based on the standard gear tooth specifications.
Chapter 6: Cams and Gears
239
Involute[alpha, {x, y}, baserad, pitchrad, ang]
returns a parametric function representing an involute gear tooth, as a function of the symbol alpha. The involute has a base circle radius of baserad and a pitch circle radius of pitchrad centered at {x, y}. The involute profile is rotationally located such that the point where the profile intersects the pitch circle lies on a ray that passes through {x, y} in the direction of the specified angle ang. If pitchrad is negative, the profile spirals outward in the clockwise direction. The involute locus travels from the base circle to the pitch circle as alpha goes from 0 to sqrt(pitchrad ^ 2 - baserad ^ 2) / baserad.
The involute gear tooth function.
Interference
is an option for Involute. Setting Interference → True specifies that the Involute locus shall blend into a straight line from the point where the involute profile meets the base circle to the center of the base circle.
An option for Involute.
The following example uses two gear tooth loci (functions of the symbols g1 and g2) located on a pair of mating gears. Note that the coordinates of the center point and the rotation angle of the involute are given in local coordinates. The tooth loci are not placed onto their respective bodies until they are put into Modeler2D point objects.
Here is a pair of tooth loci.
In[59]:= locuspoint1 = Involute@g1, 80, 0<, 4.0, 5.0, 0D;
locuspoint2 = Involute@g2, 80, 0<, 5.6, 7.0, N@πDD
Out[60]= 85.6 [email protected] + g2D + g2 [email protected] + g2DL,
5.6 H−g2 [email protected] + g2D + [email protected] + g2DL<
MechanicalSystems
240
Four constraints are used to model the two gear teeth. • A Revolute2 constraint forces the center of gear 1 to be located at {0, 0}. • A RotationLock1 constraint rotates gear 1. • A Revolute2 constraint forces the center of gear 2 to be located at {12, 0}. • A CamToCam1 constraint is used to enforce the contact of the gear teeth. Here are the involute gear model constraints. In[61]:= ground = 1;
gear1 = 2; gear2 = 3; SetConstraints@ Revolute2@1, Point@ground, 80, 0
The model is run at T = 0.01. In[65]:= [email protected], Solution → VelocityD
Out[65]= 8T → 0.01, X2 → 0., Y2 → 0., Θ2 → 0.0628319, X3 → 12., Y3 → 0.,
Θ3 → −0.0448799, g1 → 0.687168, g2 → 0.79488, X2d → 0., Y2d → 0., Θ2d → 6.28319, X3d → 0., Y3d → 0., Θ3d → −4.48799, g1d → −6.28319, g2d → 4.48799<
Chapter 6: Cams and Gears
241
Here are the two gear teeth.
Note that the angular velocity ratio of the two gears is equal to the ratio of the radii of the base circles. In[66]:= 9−
Θ2d Θ3d
ê. %,
Out[66]= 81.4, 1.4<
5.6 4.0
=
6.2 Gear Constraints Mech provides several special constraint functions for modeling gear-type relationships. These constraints do not, in fact, model the interactions of the individual gear teeth. They simply enforce the nominal rotational relationship that is expected of a pair of gears. An example of involute gear tooth modeling can be found in Section 6.1.
6.2.1 2D Gear Constraints The 2D gear constraints provided by Modeler2D cover three elementary cases of a gear-drive relationship. In each case, a simple rotational relationship is enforced between two bodies.
MechanicalSystems
242
TwoGears2[cnum, point1, rad1, point2, rad2, C]
models a gear set. The centers of the two gears, point1 and point2, are constrained to be rad1 + rad2 units apart, and the rotational positions of the gears are related as per their respective radii. The constant C, which sets the initial positions of the gears, is given by the formula C = rad1 e1 + rad2 e2.
TwoPulleys2[cnum, point1, rad1, point2, rad2, dist, C]
models a pulley and belt set. The centers of the two pulleys, point1 and point2, are constrained to be dist units apart, and the rotational positions of the pulleys are related as per their respective radii. TwoPulleys2 becomes singular if rad1 = rad2. The constant C, which sets the initial positions of the pulleys, is given by the formula C = rad1 e1 - rad2 e2. In each of the above constraints, e1 and e2 are determined by the following: Place the two gears in any valid position. Construct a vector v from point1 to point2. e1 is the angle measured in radians from v to the local x axis of the first gear. e2 is the angle measured from v to the local x axis of the second gear.
TwoGears1[cnum, point1, rad1, point2, rad2, C] TwoPulleys1[cnum, point1, rad1, point2, rad2, C] Two gear constraints.
is identical to TwoGears2, except that the distance between the centers of the two gears is not constrained. is identical to TwoPulleys2, except that the distance between the centers of the two pulleys is not constrained.
Chapter 6: Cams and Gears
RackAndPinion2[cnum, point, rad, axis, C]
243
models a rack and pinion gear set. The center of the pinion point is constrained to lie rad units to the left of the axis of the rack (axis). The angular orientation of the rack and pinion are related as per the pinion radius. The constant C is the distance, measured parallel to the axis, from the origin of the axis to point when the x axis of the pinion is parallel to axis.
RackAndPinion1[cnum, point, rad, axis, C] ReelToReel1[cnum, point1, rad1, {alpha, guess}, point2, rad2, {beta, guess}, C]
is identical in function to RackAndPinion2 except that the distance between the rack and the pinion is not constrained. models a pair of pulleys connected by a single cable. This constraint is functionally identical to TwoPulleys1 except that the angular orientation of the two pulleys is effected by their separation distance. The {symbol, guess} pairs are used to specify the names and initial guesses for two new symbols that will be added to the model.
Special gear constraints.
Each gear constraint requires an initial position constant to set the initial relative rotational positions of the two gears. Physically, the constant C specifies which gear teeth are mating when the gears are first assembled, on a continuum. The following TwoGears2 constraint would be used to model a pair of gears with pitch radii of 4.0 and 6.0, respectively, and local origins at {0, 0}. This method of setting the initial position constant causes the two gears to have angular coordinates of zero simultaneously, regardless of the relative positions of the centers of the gears.
MechanicalSystems
244
Note that using Angle[gear1, 0, gear2, 0] in the orientation constant would produce invalid results if the centers of the gears were to move relative to each other, because the orientation constant is not constant.
Here is an example of a gear constraint. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
gear1 = 2; gear2 = 3; TwoGears2@1, Point@gear1, 0D, 4.0, Point@gear2, 0D, 6.0, −H4.0 + 6.0L Angle@gear1, 0, gear2, 0DD Out[4]= SysCon@TwoGears2, 1, <>D
When an Euler solution method is used in a 2D model (Method → Euler option for SetSymbols), an extra symbol must be added to the model to keep track of the gross rotations of each gear. This is because the degenerate Euler parameters can only uniquely represent rotations from 0 to 2 pi. The extra symbol can be generated automatically by SetConstraints, or it can be specified with an optional argument to each gear constraint. These extra symbols, and their initial guesses, are analogous to the extra symbols introduced by all cam constraints and the Modeler2D gear constraints.
TwoGears2[cnum, point1, rad1, {alpha, guess}, point2, rad2, C]
is the format for specifying explicitly the extra symbol that is used to track the gross rotation of the gears with the Euler solution method. The symbol alpha represents the total rotation of the first gear with respect to a ray that passes through the centers of both gears. Extra symbols that are not explicitly specified are created in the form Θcnum.
Optional arguments for gear constraints with the Euler method.
Chapter 6: Cams and Gears
245
See the appendix for the optional arguments to other gear constraints.
6.2.2 Example 2D Gear Mechanism To demonstrate the use of Modeler2D gear constraints a 2D model is developed that uses a pair of gears, a pair of pulleys and a belt, and a rack and pinion. The input to the model is the specified rotation of the drive gear. This, in turn, rotates the driven gear, which is the same body as the drive pulley. The drive pulley rotates the driven pulley, which is the same body as the pinion. The rotation of the pinion causes the rack to translate.
Here is a 2D gear-drive mechanism graphic. y 5 y 4
y
y
x
y
x 21
x
x
3 x
Bodies Five bodies are used in the gear-drive model. No body objects are defined because no explicit point coordinates are used in the model.
MechanicalSystems
246
Names are defined for each of the body numbers in the model. In[5]:= ground = 1;
drivegear = 2; drivepulley = 3; pinion = 4; rack = 5;
Constraints Eight constraints are required to model the gear-drive mechanism. • A Revolute2 constraint locates the center of the drive gear at the origin of the ground body. • A RotationLock1 constraint controls the rotation of the drive gear. • A TwoGears2 constraint controls the rotation of the drive pulley and specifies the distance between the drive gear and the drive pulley. • A RelativeY1 constraint prevents the drive pulley from orbiting the drive gear. • A TwoPulleys2 constraint controls the rotation of the pinion and specifies the distance between the drive pulley and the pinion. • A RelativeY1 constraint prevents the pinion from orbiting the drive pulley. • A RackAndPinion2 constraint controls the translation of the rack and specifies the orthogonal distance between the rack axis and the pinion center. • A Parallel1 constraint forces the rack axis to be parallel to a horizontal line on the ground, which prevents the rack from orbiting the pinion.
Chapter 6: Cams and Gears
247
Here are the constraints for the gear model. In[10]:= SetConstraints@
Revolute2@1, Point@drivegear, 0D, Point@ground, 0DD, RotationLock1@2, drivegear, ground, 2 N@πD TD, TwoGears2@3, Point@drivegear, 0D, 2.0, Point@drivepulley, 0D, 3.0, 0D, RelativeY1@4, Point@drivepulley, 0D, 0D, TwoPulleys2@5, Point@drivepulley, 0D, 2.0, Point@pinion, 0D, 3.0, 7.0, Angle@drivepulley, 0, pinion, 0DD, RelativeY1@6, Point@pinion, 0D, 4D, RackAndPinion2@7, Point@pinion, 0D, −1.5, Axis@rack, 0, 81, 0
Runtime Initial guesses for the drive pulley, rack, and pinion must be set or the model will not converge. Almost any guesses greater than zero will do.
This sets the initial guesses for the next solution attempt only. In[11]:= SetGuess@8X3 → 5, X4 → 10, Y4 → 4, X5 → 10, Y5 → 6
Θ3 → 0, X4 → 10, Y4 → 4, Θ4 → 0, X5 → 10, Y5 → 6, Θ5 → 0<
Because of the presence of time T in the driving constraint, the model can be run through its intended range of motion by varying T directly with the SolveMech command. The numerical value of T specifies the angular coordinate of the drive gear.
MechanicalSystems
248
Now run the model at T = 0.05. In[12]:= [email protected]
Out[12]= 8T → 0.05, X2 → 0., Y2 → 0., Θ2 → 0.314159, X3 → 5., Y3 → 0., Θ3 → −0.20944,
X4 → 10.7446, Y4 → 4., Θ4 → −0.139626, X5 → 10.954, Y5 → 5.5, Θ5 → 0.<
Now run the model at T = 0.25. In[13]:= [email protected], 7, 10
Out[13]= 8Θ2 → 1.5708, Θ3 → −1.0472, Θ4 → −0.698132<
Here is the gear-drive mechanism at T = 0.25. y 5 y
x
4 x xy y
21
x
y 3 x
6.2.3 3D Gear Constraints The 3D gear constraints provided by Modeler3D cover six elementary cases of a gear-drive relationship. In each case the gear constraints simply enforce a nominal rotational relationship between two bodies. The interactions of individual teeth on the gears are not modeled. Each of the gear constraints must be passed an additional symbol alpha that is used by Modeler3D to keep track of the relative rotations of the gears. These symbols can be arbitrarily chosen, as long as all symbols in all gear constraints in a single model are unique. The values of these symbols are calculated by Modeler3D at runtime and included in the solution rules. Essentially, each new symbol is another dependent variable to be solved for, just like the coordinates of each body. The numerical values of the added symbols correspond to the rotation of the first of the two gears in each pair, relative to the mutual orientation of the pair of gears in space.
Chapter 6: Cams and Gears
ParallelGears5[cnum, axis1, rad1, {alpha, guess}, axis2, rad2, C]
249
models a gear set. The axes of the two gears axis1 and axis2 are constrained to be parallel and rad1 + rad2 units apart, and the origins of the two axes are constrained to be adjacent. The rotational positions of the gears are related as per their respective radii. The constant C, which sets the initial positions of the gears, is given by the formula C = rad1 e1 + rad2 e2.
ParallelGears4[cnum, axis1, rad1, {alpha, guess}, axis2, rad2, C]
is identical to ParallelGears5 except that the origins of the two axes are not constrained to be adjacent. Thus, the two gears are free to slide on their axes, relative to each other.
TwoPulleys5[cnum, axis1, rad1, {alpha, guess}, axis2, rad2, dist, C]
models a pair of pulleys and a belt. The axes of the two pulleys, axis1 and axis2, are constrained to be parallel and dist units apart, and the origins of these two axes are constrained to be adjacent. The rotational positions of the two pulleys are related as per their respective radii. The constant C, which sets the initial positions of the pulleys, is given by the formula C = rad1 e1 – rad2 e2.
TwoPulleys4[cnum, axis1, rad1, {alpha, guess}, axis2, rad2, dist, C]
is identical to TwoPulleys5 except that the origins of the two axes are not constrained to be adjacent. In each of these constraints, e1 and e2 are determined by the following: Place the two gears in any valid position. Construct a vector v from the origin of axis1 to that of axis2. e1 is the angle measured in radians from v to the reference direction of axis1, as projected on a plane that is normal to axis1. e2 is the angle measured from v to the reference direction of axis2, as projected on a plane that is normal to axis2.
Two gear constraints.
MechanicalSystems
250
Each gear constraint requires an initial orientation constant to set the initial relative rotations of the two gears. In most simple gear trains the gears are initially aligned so the orientation constant can be zero. The only significant differences between ParallelGears5 and TwoPulleys5 are that the separation distance of the two gears can be set independently from the gear radii with TwoPulleys5 and that the direction of relative rotation of the two gears is reversed. The direction of rotation constrained by Two Pulleys5 can be reversed by negating one of the two pulley radii.
RackAndPinion5[cnum, axis1, rad, {alpha, guess}, axis2, C]
models a rack and pinion gear set. axis1 represents the rotational axis of the pinion, and axis2 represents the rack. axis2 is parallel to the cut of the teeth of the rack, and axis2 and its reference direction lie in the plane of the rack. The axis of the pinion is constrained to lie rad units away from, and parallel to, the axis of the rack, and the origins of the two axes are constrained to be adjacent. The rotational orientation of the pinion is related to that of the rack as per the pinion radius.
RackAndPinion4[cnum, axis1, rad, {alpha, guess}, axis2, C]
is identical to RackAndPinion5 except that the origins of the axes are not constrained to be adjacent. The constant C is the distance from the origin of axis2 to the origin of axis1, measured in the direction of the rack (the reference direction of axis2) when the reference direction of the pinion is parallel to the reference direction of the rack.
A special gear constraint.
Chapter 6: Cams and Gears
OrthogonalGears5[cnum, axis1, teeth1, {alpha, guess}, axis2, teeth2, dist, C]
251
models a pair of gears on orthogonal axes, such as a worm gear or bevel gear set. The axes of the two gears, axis1 and axis2, are constrained to be orthogonal and dist units apart, and the origins of the two axes are constrained to be adjacent. The rotational positions of the worm and gear are related as per their respective tooth counts teeth1 and teeth2. If dist is omitted it defaults to zero. The constant C, which sets the initial positions of the two gears, is given by the formula C = teeth1 e1 + teeth2 e2. e1 and e2 are determined by the following: Place the two gears in any valid position. e1 is the projected angle, in radians, measured from axis2 to the reference direction of axis1, as projected on a plane that is normal to axis1. e2 is the angle measured from axis1 to the reference direction of axis2.
Another special gear constraint.
As with TwoPulleys5, the direction of relative rotation specified by OrthogonalGears5 can be reversed by negating teeth1 or teeth2.
LeadScrew5[cnum, axis1, {alpha, guess}, axis2, pitch, C]
models a lead screw. axis1 is constrained to be parallel and coincident with axis2, and the axial translation of the two axes is controlled per the pitch and relative rotation of the two screws. The relative angular orientation of the two screws is determined by the angle between the reference directions of axis1 and axis2. The symbol alpha tracks the rotation of axis1, relative to axis2. The constant C is the distance from the origin of axis2 to the origin of axis1, measured in the direction of axis2, when the relative rotation between the two parts of the screw is zero.
A screw constraint.
MechanicalSystems
252
ConstantVelocity4[cnum, axis1, {alpha, guess}, axis2, ratio, C]
models a constant velocity joint. The origin of axis1 is constrained to be coincident with the origin of axis2, and the relative spin of axis2 is constrained to be equal to ratio times the spin of axis1. The relative spin of the axes is determined by the angle between the reference directions of each axis, and the cross product of the two axes. If ratio is omitted it defaults to 1. The symbol alpha tracks the relative spin of axis1. The constant C is the relative spin of axis2 when the spin of axis1 is zero.
A constant velocity joint.
Note that the ConstantVelocity4 constraint is not stable when the two axes are parallel. The included angle between the two axes must be kept sufficiently far from 0 or p to remain stable. If the two axes in a model need to be parallel or nearly so it may be useful to use the OrthoRevolute4 constraint instead. The following ParallelGears5 constraint models a pair of gears with pitch radii of 4.0 and 6.0 respectively, and axis origins at local {0, 0, 0} on each body. The rotational axis of each gear is in its local z direction, and the local x direction on each gear is used as its reference direction. Setting the initial position constant to zero causes the reference directions of the two gears, the local x axes, and the vector from the center of gear1 to the center of gear2 to be simultaneously parallel.
This loads the Modeler3D package. In[14]:= Needs@"MechanicalSystems`Modeler3D`"D
Chapter 6: Cams and Gears
253
Here is a gear constraint example. In[15]:= gear1 = 2;
gear2 = 3; ParallelGears5@1, Axis@gear1, 0, 80, 0, 1<, 81, 0, 0D
6.2.4 Example 3D Gear Mechanism To demonstrate the use of Modeler3D gear constraints a 3D model is developed that uses a pair of orthogonal bevel gears, a pair of parallel spur gears, and a rack and pinion gear set. The input to the model is the specified rotation of the first bevel gear, the drive bevel. This, in turn, rotates the driven bevel gear, which is the same body as the drive spur gear. The drive spur rotates the driven spur, which is the same body as the pinion. The rotation of the pinion causes the rack to translate.
Here is the 3D gear-drive mechanism. y
y x z 5
y
y
4 z x
2 z
3 z
x
x
MechanicalSystems
254
Bodies Five bodies are used in the gear-drive model. No body objects are defined because no explicit point coordinates are used in the model.
Names are defined for each of the body numbers in the model. In[18]:= ground = 1;
drivebevel = 2; drivespur = 3; pinion = 4; rack = 5; X = 81, 0, 0<; Y = 80, 1, 0<; Z = 80, 0, 1<;
Constraints Eight constraints are required to model the gear-drive mechanism. • A Revolute5 constraint controls the rotational axis of the drive bevel. The drive bevel rotates about an axis originating at the global origin and pointing in the global X direction, which is coincident with the drive bevel’s local x axis. • A ProjectedAngle1 constraint specifies the rotation of the drive bevel. • An OrthogonalGears5 constraint enforces the gear relationship between the drive bevel and the driven bevel (drive spur). The Axis objects that are used to specify the axes of each gear contain several important elements. The origins of the two axes are to be adjacent, thus they are located on the gear axes at the intended point of intersection of the axes. The local coordinate axes of the drive spur are initially rotationally aligned with the local axes of the drive bevel. Thus, the reference direction of each gear is initially parallel to the rotational axis of its neighbor, which results in an orientation constant of zero. Note also that these are straight cut bevel gears, so the offset distance between their axes is also zero. • A RelativeY1 constraint removes the one remaining degree of freedom from the drive spur, its freedom to orbit drive bevel. • A ParallelGears5 constraint enforces the gear relationship between the drive spur and the driven spur (pinion). The rotational axes of these two gears are to be parallel, so they both point in the local z direction. The orientation constant allows the two gears to be initially aligned with the global axes. • A RelativeY1 constraint prevents the pinion from orbiting the drive spur.
Chapter 6: Cams and Gears
• A RackAndPinion5 constraint controls the translation of the rack and the orthogonal distance between the rack axis and the pinion center. The radius of the rack is specified as -3.0 to put the pinion on the correct side of the rack for this model. • A Orthogonal1 constraint prevents the rack from orbiting the pinion. Here is the complete constraint set for the gear-drive model. In[24]:= SetConstraints@
Revolute5@1, Axis@drivebevel, 0, XD, Axis@ground, 0, XDD, ProjectedAngle1@2, Vector@drivebevel, YD, Vector@ground, YD, Vector@ground, XD, 2 N@πD TD, OrthogonalGears5@3, Axis@drivebevel, 82, 0, 0<, X, ZD, 2, 8rotSym1, 0<, Axis@drivespur, 0, Z, XD, 3, 0D, RelativeY1@4, Point@drivespur, 80, 0, −2
Runtime Initial guesses for the rack and pinion must be set or the model will not converge.
This sets the necessary initial guesses. In[25]:= SetGuess@8X3 → 2, Y3 → 0, Z3 → 0, X4 → 6,
Y4 → 2.25, Z4 → 0, X5 → 6, Y5 → 5.25, Z5 → 0, rotSym2 → .5
255
MechanicalSystems
256
Because of the presence of T in the driving constraint, the model can be run through its intended range of motion by varying T directly with the SolveMech command. The numerical value of T specifies the angular coordinate of the drive bevel.
Now run the model at T = 0.05. In[26]:= [email protected]
Out[26]= 8T → 0.05, X2 → 0., Y2 → 0., Z2 → 0., Eo2 → 0.987688, Ei2 → 0.156434,
Ej2 → 7.24056 × 10−25 , Ek2 → 5.33583 × 10−24 , X3 → 2., Y3 → 2.15325 × 10−23 , Z3 → 4.79022 × 10−25 , Eo3 → 0.994522, Ei3 → −1.26643 × 10−23 , Ej3 → 1.06786 × 10−23 , Ek3 → −0.104528, X4 → 5.89711, Y4 → 2.25, Z4 → −1.44275 × 10−22 , Eo4 → 0.99863, Ei4 → 1.14484 × 10−23 , Ej4 → 3.58837 × 10−24 , Ek4 → 0.052336, X5 → 5.58296, Y5 → 5.25, Z5 → −7.41751 × 10−23 , Eo5 → 1., Ei5 → 3.0363 × 10−24 , Ej5 → 3.59861 × 10−24 , Ek5 → −6.44658 × 10−24 , rotSym1 → −0.314159, rotSym2 → 0.733038, rotSym3 → −0.10472<
Now run the model at T = 0.25.
In[27]:= 8rotSym1, rotSym2, rotSym3< ê. [email protected] Out[27]= 8−1.5708, 1.5708, −0.523599<
Here is the gear-drive mechanism at T = 0.25. y
y z 5
x x
y 4 z x
2
3
y
z z
x
Chapter 6: Cams and Gears
257
From the sizes of the gears in this model and the fact that the drive bevel is turning at one revolution per second, we can calculate what the velocity of the rack should be. This can also be found directly from the velocity of the rack in the Modeler3D model. Rack velocity = drivebevel angular velocity * drivebevel radius / drivenbevel radius * drivespur radius / drivenspur radius * pinion radius
Here is the rack velocity, calculated explicitly and from the model. In[28]:=
1.0 2 N@πD 2.0 1.5 3.0 3.0 3.0 Magnitude@Velocity@rack, 0DD ê. [email protected], Solution → VelocityD
Out[28]= 6.28319 Out[29]= 6.28319
6.2.5 General Rotational Relationships If the spatial gear constraints provided by Modeler3D will not serve to model a more abstract rotational relationship, similar constraints can be built up from the basic kinematic constraints. The following example shows how to duplicate the function of the ParallelGears5 constraint with a set of other Modeler3D constraints. This model consists of one moving body, the gear, and one stationary body, the pinion. The radius 3.0 gear orbits the stationary radius 1.0 pinion. The ParallelGears5 constraint is effectively replaced by the set of the following six constraints. • A Parallel2 constraint forces the axes of the two gears to be parallel. • A PointOnPlane1 constraint forces the origins of the two gear axes to be adjacent. • A RelativeDistance1 constraint holds the gears the correct distance apart. • A ProjectedAngle1 constraint sets the relative rotation of the pinion equal to the value of an extra symbol that is added to the model.
MechanicalSystems
258
• A ProjectedAngle1 constraint sets the relative rotation of the gear equal to another extra symbol that is added to the model. • A general Constraint object relates the two extra symbols that control the relative rotation of the two gears to each other. This combination constrains seven degrees of freedom, but it adds two degrees of freedom by adding two variables to the model. Thus, a total of five degrees of freedom are constrained. Here are names for the body numbers. In[30]:= pinion = 1;
gear = 2; Here is the equivalent ParallelGears5 constraint.
In[32]:= cs@1D = 8
Parallel2@1, Vector@pinion, 80, 0, 1
Chapter 6: Cams and Gears
259
SetConstraints must be passed a flat constraint list. In[34]:= SetConstraints@Flatten@8cs@1D, cs@2D
One initial guess is needed. In[35]:= SetGuess@8X2 → 4
Now run the model at T = 1.0. In[36]:= SolveMech@1D
Out[36]= 8T → 1, X2 → 3.87298, Y2 → 1., Z2 → 0., Eo2 → 0.985845, Ei2 → 0.,
Ej2 → 0., Ek2 → 0.167658, rSym1 → −0.25268, rSym2 → 0.0842268<
Here is the two-gear model at T = 1.0. y y
x
1
z
2 x
z
In general, this method of constraining the relative rotation between two moving bodies can be used to model any type of rotational linkage. The Constraint function that is used to relate the two extra variables can contain an algebraic expression that is arbitrarily complex. This allows abstract or nonlinear relationships to be modeled.
7. Loads and Reactions Overview This chapter describes how MechanicalSystems is used to apply forces and moments to a mechanism model, and how the resulting reaction forces in the constraints are resolved. Mech uses a Lagrange multiplier method to resolve the applied and reaction loads on each body, and solves for a generalized force associated with each constraint. These generalized forces can then be converted back into the force and moment applied by a selected constraint to each body in the model with a standard Mech output function.
7.1 Load Objects Load objects are used to define the forces and moments that are to be applied to a Mech model. All Mech load functions return load objects with the head SysLoad. To apply the loads to the mechanism model, the load objects are passed to the SetLoads function. This syntax is analogous to the way that constraint objects are passed to SetConstraints to incorporate them into the model.
7.1.1 2D Load Functions The Modeler2D load functions are used to specify forces and moments applied to specific bodies in the mechanism model. In general, moments are specified by magnitude, and forces are specified by magnitude and line of action. By using Modeler2D axis objects to define the line of action, a force can be applied to a point attached to any body in the mechanism, and the direction of the force can be a global or local vector, or a line from one body to another. The magnitude of a force or moment applied to a static model can be a constant, or it can be a function of location or velocity-dependent variables or even a function of the reaction forces at specified constraints. An applied load that is a function of constraint reaction forces is often used to model friction.
MechanicalSystems
262
Moment[bnum, mag]
returns a Modeler2D load object that applies a moment of magnitude mag to body bnum.
Moment[bnum1, bnum2, mag]
applies the moment to body bnum1 and also applies a second moment in the opposite sense to body bnum2.
Force[bnum, axis, mag, options]
returns a Modeler2D load object that applies a force to body bnum of magnitude mag along a line of action specified by axis.
Force[bnum1, bnum2, axis, mag, options]
applies the force to body bnum1 and also applies a second force in the opposite direction, on the same line of action, to body bnum2.
Gravity[vector, G]
returns a list of load objects that applies forces of magnitude mass times G to the centroid of each body in the current model in the direction of vector.
Gravity[vector, G, {bnum1, bnum2, …}]
applies the gravitational force only to the bodies specified by their body numbers.
2D load functions.
Magnitude
is an option for Force that specifies whether the magnitude of the applied force is relative to the magnitude of the line of action of the force.
Magnitude → Absolute
is the default setting that causes the magnitude of the applied force to be equal to mag.
Magnitude → Relative
causes the magnitude of the applied force to be equal to mag times the length of the direction vector of the force.
An option for Force.
Modeler2D load objects are typically used in a similar manner to Modeler2D constraint objects. They are defined prior to adding them to the model and then passed to SetLoads. Some examples of valid load objects follow.
Chapter 7: Loads and Reactions
263
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Here is a moment of magnitude 4 applied to the crank. In[2]:= ground = 1;
crank = 2; Moment@crank, 4D Out[4]= SysLoad@Moment, 2, <>D
Here is a moment applied to the crank with magnitude equal to twice the rotation angle of the crank. In[5]:= Moment@crank, 2 Rotation@crankDD;
Here is a force applied to the crank passing through point {1,1} on the crank and pointing in the global X direction, with magnitude equal to k times the distance from the point of application to the global origin. In[6]:= Force@crank,
Axis@Point@crank, 81, 1
The Gravity function needs to know the mass and the location of the centroid of each body to apply the gravitational force. These properties are defined with the Mass and Centroid options for the Modeler2D Body function, and added to the model with SetBodies. See Section 8.1.
7.1.2 3D Load Functions The Modeler3D load functions are used to specify forces and moments applied to specific bodies in the mechanism model. In general, moments are specified by magnitude and direction, and forces are specified by magnitude and line of action. By using Modeler3D axis objects to define the line of action of forces, and Modeler3D vector objects to define the direction of moments, a force can be applied to a point attached to any body in the mechanism, and the direction of a force or moment can be a global or local vector, a line from one body to another, or even the normal of a plane. The magnitude of a force or moment applied to a static model can be a constant, or it can be a function of location or velocity-dependent variables or even a function of the reaction forces at particular constraints.
MechanicalSystems
264
Moment[bnum, vector, mag, options]
returns a Modeler3D load object that applies a moment of magnitude mag to body bnum in the direction of vector.
Moment[bnum1, bnum2, vector, mag, options]
applies the moment to body bnum1 and also applies a
Force[bnum, axis, mag, options]
returns a Modeler3D load object that applies a force of
second moment in the opposite sense to body bnum2. magnitude mag to body bnum along a line of action specified by axis.
Force[bnum1, bnum2, axis, mag, options] Gravity[vector, G]
applies the force to body bnum1 and also applies a second force in the opposite direction to body bnum2. returns a list of load objects that applies forces of magnitude mass times G to the centroid of each body in the current model in the direction of vector.
Gravity[vector, G, {bnum1, bnum2, …}]
applies the gravitational force only to the bodies specified by their body numbers.
3D load functions.
Magnitude
is an option for Force and Moment that specifies whether the magnitude of the applied load is relative to the magnitude of the line of action of the load.
Magnitude → Absolute
is the default setting that causes the magnitude of the applied load to be equal to mag.
Magnitude → Relative
causes the magnitude of the applied load to be equal to mag times the length of the direction vector of the load.
An option for Force and Moment.
Modeler3D load objects are typically used in a similar manner to Modeler3D constraint objects, they are defined prior to adding them to the model and then passed to SetLoads. Some examples of valid load objects follow.
Chapter 7: Loads and Reactions
265
This loads the Modeler3D package. In[7]:= Needs@"MechanicalSystems`Modeler3D`"D
Here is a moment of magnitude 4 and a direction vector in the global Z direction applied to the crank. In[8]:= ground = 1;
crank = 2; Moment@crank, Vector@ground, 80, 0, 1D
Here is a moment applied to the crank with magnitude equal to twice the rotation angle of the crank, relative to the global reference frame, and direction vector on the local x axis. In[11]:= Moment@crank,
Vector@crank, 81, 0, 0
Here is a force applied to the crank passing through point {1,1,0} on the crank and pointing in the global X direction, with magnitude equal to k times the distance from the point of application to the global origin. Axis@Point@crank, 81, 1, 0
In[12]:= Force@crank,
The Gravity function needs to know the mass and the location of the centroid of each body to apply the gravitational force. These properties are defined with the Mass and Centroid options for the Modeler3D Body function, and added to the model with SetBodies. See Section 8.1.
7.1.3 Generalized Load Function The Load function is analogous to the Mech Constraint function. Load allows the user to specify an algebraic expression to be added directly to the model’s load vector, just as Constraint allows an algebraic constraint to be added to the constraint list.
MechanicalSystems
266
Load[sym, mag]
returns a Mech load object that applies a load of magnitude mag directly to the coordinate sym.
The generalized load function.
The Load function is typically used only when special generalized coordinates have been added to the model, and it is necessary to apply a load directly to those coordinates. Load basically allows expressions to be added directly to a model’s load vector. Using Load to apply a load to a model’s Cartesian coordinates is equivalent to applying a force or moment to a body in the model.
Here are Load and Force objects that are functionally equivalent. In[13]:= Load@X2, 10D
Force@crank, Axis@crank, 80, 0, 0<, ground, 81, 0, 0
Out[13]= SysLoad@Load, X2, <>D Out[14]= SysLoad@Force, 2, <>D
In 3D models, the sym argument to Load has a special caveat: if the Angular solution method was specified with SetSymbols, loads cannot be directly applied to the Euler parameters, because the load vector is formulated in terms of angular velocity. However, loads can be applied directly to the angular velocity coordinates, which is equivalent to applying a pure moment.
Here are Load and Moment objects that are functionally equivalent, when the SetSymbols settings are as specified. In[15]:= SetSymbols@Method → AngularD;
Load@Ωy2, 10D Moment@crank, Vector@ground, 80, 1, 0D Out[17]= SysLoad@Moment, 2, <>D
Chapter 7: Loads and Reactions
267
7.2 Static Solutions Load objects are applied to the current model with the SetLoads function. The actual load vector developed by SetLoads is not returned to the user, rather it is stored in several variables in the `Private` context of the Mech packages. The use of load objects and SetLoads in Mech is analogous to the use of constraint objects and SetConstraints. Mech uses a Lagrange multiplier method to resolve the constraint reaction forces in a mechanism model. There is one Lagrange multiplier named Λ1, Λ2, and so on for each degree of freedom in the model. Thus, when Mech solves a loaded model what is returned to the user are the numerical values of the Lagrange multipliers. The Lagrange multipliers are actually the generalized forces related to a set of generalized coordinates in which each coordinate corresponds to the magnitude of the violation of a kinematic constraint. While the numerical values of the Lagrange multipliers are not directly very useful, they are converted into the reaction forces and moments that are applied by the constraints to each body in the model with the Reaction function. This is discussed in Section 7.3.
7.2.1 2D Example Mechanism To demonstrate the use of Mech’s static force solution method a 2D model is developed that is subject to applied loads. A 3D model would be treated in the same manner as 2D with regard to the application of forces. The model is a simple ladder sliding down a wall consisting of one moving body, the ladder. The input to the mechanism is to push the bottom of the ladder across the horizontal floor, in either direction. The ladder is constrained such that the bottom of the ladder must contact the floor and the top of the ladder must contact the vertical wall.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
MechanicalSystems
268
Here is a graphic of the 2D ladder-on-wall model. P3 10 P2 8
6
4
2
P1 0 P2 P1 -10
-8
-6
-4
-2
0
Bodies Two body objects are defined for the ladder-on-wall model.
Names are defined for each of the body numbers in the model. In[2]:= ground = 1;
ladder = 2;
• The ground (body 1) uses three point definitions. P1 is the origin of the ground body. P2 is a point at {– 10, 0} that defines the horizontal line of the floor. P3 is a point at {0, 10} that defines the vertical line of the wall. • The ladder (body 2) uses two local point definitions. P1 is the center of the bottom of the ladder at local coordinate {0, 0}. P2 is the center of the top of the ladder at local coordinate {0, 10}.
Chapter 7: Loads and Reactions
269
Here are the body objects for the ladder-on-wall model.
In[4]:= bd@groundD = Body@ground, PointList → 8
H∗P1∗L80, 0<, H∗P2∗L8−10, 0<, H∗P3∗L80, 10<
SetBodies incorporates the body properties into the current model. In[6]:= SetBodies@bd@groundD, bd@ladderDD
Constraints Three constraints, one of which is a driving constraint, are required to model the ladder-on-wall. The top and bottom tips of the ladder, which slide on the wall and floor, each have a small radius. • A RelativeX1 constraint is used as a driving constraint to push the bottom of the ladder across the floor. This constraint is a driving constraint because it is functionally dependent on the time variable, T. • A PointOnLine1 constraint places the bottom of the ladder in contact with the floor. PointOn Line1 is used with its optional argument to specify offset. This models the 0.4 radius at the bottom of the ladder. • A PointOnLine1 constraint places the top of the ladder in contact with the wall, also with a 0.4 radius. Here are the constraint objects for the ladder-on-wall model. In[7]:= cs@1D = RelativeX1@1,
Point@ladder, 1D, −TD; cs@2D = PointOnLine1@2, Point@ladder, 1D, Line@ground, 2, 1D, 0.4D; cs@3D = PointOnLine1@3, Point@ladder, 2D, Line@ground, 1, 3D, 0.4D; SetConstraints incorporates the constraint objects into the current model. In[10]:= SetConstraints@Array@cs, 3DD
MechanicalSystems
270
7.2.2 Applying Loads SetLoads is the core function for applying loads to a Mech model. SetLoads takes load objects that represent the physical loads applied to the model and builds them into a global load vector that represents the total force and moment applied at the origin of each body in the model.
SetLoads[loads, options]
accepts Mech load objects and applies them to the current mechanism model. The loads can be a nested list or sequence of loads. Each of the loads must be load objects with the head SysLoad, such as are returned by the Mech load functions. SetLoads returns Null upon success.
The load application function.
Mech uses a Lagrange multiplier method to resolve the static and dynamic forces on a model, which will be discussed further in Section 7.3. It is usually not necessary to specify initial guesses for the Lagrange multipliers, because the equations of motion are linear in the Lagrange multipliers unless friction forces are applied. If initial guesses are needed, they can be specified with the LambdaGuess option for SetLoads.
LambdaGuess
is an option for SetLoads that specifies the initial guesses for all Lagrange multipliers.
LambdaGuess → number LambdaGuess → {n1, n2, …}
uses number for the initial guess for all Lagrange multipliers. takes a list of numbers equal in length to the number of degrees of freedom in the model to specify initial guesses for each Lagrange multiplier.
LambdaGuess → Automatic
is the default setting that leaves the current guesses unchanged. All guesses are initially set to 1.0.
An option for SetLoads.
Because forces and moments are additive quantities, it is not necessary to apply all of the loads to the model simultaneously. With the AddLoads option, loads can be applied to the model sequentially.
Chapter 7: Loads and Reactions
271
AddLoads
is an option for SetLoads that determines whether the specified loads are to be added to the currently defined loads, or to replace the current loads.
AddLoads → True AddLoads → False
causes the new loads to be added to the current ones. is the default setting that causes the new loads to replace the current ones.
An option for SetLoads.
Loads for the Model Three loads are defined for the model developed in Section 7.2.1. • A Force of 10 units is applied downward to the top of the ladder. • A Force of 100 units is applied downward at the center of the ladder. • A Moment of 5 units is applied to the ladder in the counterclockwise sense. Here are the load objects for the ladder-on-wall model. In[11]:= ld@1D = Force@ladder,
Axis@Point@ladder, 2D, Vector@ground, 80, −1
Out[13]= SysLoad@Moment, 2, <>D
Initially, only the two Force objects are applied. SetLoads incorporates the loads into the model. In[14]:= SetLoads@ld@1D, ld@2DD
By using the AddLoads option for SetLoads, additional loads can be applied to the model at any time. Thus, the Moment can simply be added to the current loading.
This adds the Moment object to the ladder-on-wall model. In[15]:= SetLoads@ld@3D, AddLoads → TrueD
MechanicalSystems
272
Mech load objects can contain dependencies on other dependent variables. For example, to model the force applied by a linear spring, it is necessary to have the magnitude of the force be a function of the distance between two points. The Force of an extension spring with a free length of 2 units and a spring constraint k attached between the top of the ladder and the top of the wall could be modeled as follows.
Here is a spring force. In[16]:= ld@4D = Force@ladder,
Line@ladder, 2, ground, 3D, k HMagnitude@ladder, 2, ground, 3D − 2LD;
7.2.3 Running the Loaded Model Because of the presence of T in the driving constraint cs[1], the model can be run through its intended range of motion by varying T directly with the SolveMech command. The numerical value of T specifies the distance between the bottom of the ladder and the wall. Although loads have been added to the model, the SolveMech default option setting Solution → Loca tion solves only for the location variables.
Now run the model at T = 7.5. In[17]:= [email protected]
Out[17]= 8T → 7.5, X2 → −7.5, Y2 → 0.4, Θ2 → −0.789498<
Mech must be told to solve for the static forces in the model with the Solution option for SolveMech.
Chapter 7: Loads and Reactions
273
is an option for SolveMech that determines which model
Solution
variables are solved for. Solution → Static
causes SolveMech to solve for the static reaction forces in the model. SolveMech will calculate the location of the mechanism bodies and the numeric values of the Lagrange multipliers with all mechanism velocities and accelerations set to zero so that no dynamic forces are calculated.
An option for SolveMech.
The Solution → Static option causes SolveMech to resolve the forces applied to the model into Lagrange multipliers.
Now run the model at T = 8.5. In[18]:= [email protected], Solution → StaticD
Out[18]= 8T → 8.5, X2 → −8.5, Y2 → 0.4, Θ2 → −0.944152, Λ1 → −82.0217, Λ2 → −11., Λ3 → −8.20217<
Here is the ladder-on-wall image at T = 8.5. P3 10
8 P2 6
4
2
P1 0 P2 P1 -10
-8
-6
-4
-2
0
MechanicalSystems
274
The numeric values of the Lagrange multipliers returned by SolveMech are not directly very useful, unless one has a very good understanding of the exact form of the constraints. However, the set of Lagrange multipliers associated with a mechanism model completely determines all of the reaction forces in the constraints in the model. To find the actual reaction forces and moments at a specific constraint it is necessary to use the Mech Reaction function, which is described in Section 7.3.
7.3 Resultant Forces This section describes the usage of the two Mech functions that are used to convert the Lagrange multipliers into reaction forces on specific bodies in a model, Reaction and Loads.
7.3.1 2D Example Mechanism To demonstrate the use of Mech’s Reaction function, the 2D ladder-on-wall model that was developed in Section 7.2 is used. The bodies and constraints of the model are redefined here in abbreviated form.
The following loads the Modeler2D package and completely defines the ladder-on-wall model. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
ground = 1; ladder = 2; In[4]:= SetBodies@
Body@ground, PointList → 8 H∗P1∗L80, 0<, H∗P2∗L8−10, 0<, H∗P3∗L80, 10<
In[5]:= SetConstraints@
RelativeX1@1, Point@ladder, 1D, −TD, PointOnLine1@2, Point@ladder, 1D, Line@ground, 2, 1D, 0.4D, PointOnLine1@3, Point@ladder, 2D, Line@ground, 1, 3D, 0.4DD
Chapter 7: Loads and Reactions
275
The model is run to prove that it works. In[6]:= SolveMech@7D
Out[6]= 8T → 7, X2 → −7., Y2 → 0.4, Θ2 → −0.720819<
7.3.2 Reaction The Reaction function is used to convert the Lagrange multipliers that are returned by SolveMech into specific reaction forces and moments that are applied to each body by the constraints in the mechanism model.
Reaction[cnum, bnum]
returns the reaction force and moment applied to body bnum by constraint cnum calculated about the local origin of body bnum. Reaction returns a list of the form {force, moment}.
Reaction[cnum, Point[bnum, lpnt]]
returns the reaction force and moment applied by constraint cnum to body bnum calculated about local point lpnt on body bnum.
Reaction[cnum, bnum, point]
returns the reaction force and moment applied by constraint cnum to body bnum calculated about point. Only the reaction moment is affected by the point about which it is calculated, the reaction force is not a function of the location of point.
Reaction[cnum, symbol]
returns the generalized reaction applied to a single coordinate or parameter symbol that occurs in the model.
Reaction[{cnum1, cnum2}, …]
returns the sum of the reactions applied by several constraints cnumi.
Reaction[{cnum, {eqn1, eqn2, …}, …] The function for finding constraint reaction forces.
returns the sum of the reactions applied by several specific equations eqni in constraint cnum.
MechanicalSystems
276
Coordinates
is an option for Reaction that specifies whether the forces and moments returned are to be in global or local coordinates. In 2D models, reaction moments are scalars and are unaffected by the Coordinates option.
Coordinates → Local
causes Reaction to return force and moment vectors in the local coordinate system attached to the body to which the reaction load is applied.
Coordinates → Global
is the default setting that causes Reaction to return forces and moments in global coordinates.
An option for Reaction.
To demonstrate the use of Reaction, loads are applied to the ladder-on-wall model that was redefined in Section 7.3.1. • A Force of 10 units is applied downward to the top of the ladder. • A Force of 100 units is applied downward at the center of the ladder. • A Moment of 5 units is applied to the ladder in the counterclockwise sense. Here are the load objects for the ladder-on-wall model. In[7]:= ld@1D = Force@ladder,
Axis@Point@ladder, 2D, Vector@ground, 80, −1
Only the first two loads are added to the model initially; the other load will be added later. The model can then be run with the Solution → Static option to solve for the Lagrange multipliers.
Load 1 and load 2 are applied to the current model. In[10]:= SetLoads@ld@1D, ld@2DD
Chapter 7: Loads and Reactions
277
Now run the model at T = 6.0. In[11]:= [email protected], Solution → StaticD
Out[11]= 8T → 6., X2 → −6., Y2 → 0.4, Θ2 → −0.594386, Λ1 → −40.5556, Λ2 → −11., Λ3 → −4.05556<
Because the Reaction function references constraints by number, names are given to each of the constraints for clarity.
Names are defined for each of the constraints in the model. In[12]:= Off@General::"spell1"D
driver = 1; floor = 2; wall = 3; On@General::"spell1"D
The horizontal force at the bottom of the ladder that is required to hold the ladder in its current position is the reaction to constraint 1, the driving constraint. Note that the Y force and the moment sustained by the driving constraint are both zero, and always will be, because the driving constraint (RelativeX1) does not constrain motion in the Y or theta directions, therefore, it cannot sustain any load in those directions.
Here is the reaction to the driver.
In[17]:= Reaction@driver, Point@ladder, 1DD ê. LastSolve@D Out[17]= 8840.5556, 0<, 0<
For the ladder to be in equilibrium, the force at the driver must be balanced by the force against the wall. Note that the Reaction function, like all other Mech output functions, returns a symbolic expression in terms of dependent variables.
Here is the reaction against the wall. In[18]:= Reaction@wall, Point@ladder, 2DD
% ê. LastSolve@D
Out[18]= 8810 Λ3, 0<, 0<
Out[19]= 88−40.5556, 0<, 0<
278
MechanicalSystems
Note that if a different point is chosen about which to calculate the reaction, only the moment is changed. A reaction force is not a function of the point about which the reaction is calculated, therefore, the choice of a calculation point never affects the force, only the moment.
Here is the reaction against the wall calculated about a point on the ground.
In[20]:= Reaction@wall, ladder, Point@ground, 82., 3.
Since there is no friction in this model, the sum of all of the vertical forces is applied to the floor.
Here is the reaction against the floor.
In[21]:= Reaction@floor, Point@ladder, 1DD ê. LastSolve@D Out[21]= 880, 110.<, 0<
When the applied moment, load 3, is added to the model, it shows up as added reaction force against the driver and the wall.
The moment that was previously defined is added to the model. In[22]:= SetLoads@ld@3D, AddLoads → TrueD
Here is the reaction against the wall.
In[23]:= Reaction@wall, Point@ladder, 2DD ê. [email protected], Solution → StaticD Out[23]= 88−39.9521, 0<, 0<
7.3.3 Loads The actual load vector that is generated by SetLoads can be directly accessed with Loads. Loads can be very useful for debugging a model because it is often possible to read the load expressions directly and relate them to the function of the model.
Chapter 7: Loads and Reactions
279
Loads[bnum]
returns the part of the current load vector associated with the specified body. The load vector is formed with respect to the current velocity coordinate system. Thus, if the current model uses the Euler coordinate system, the moment component of the applied loads are returned in Euler coordinates and have no direct physical meaning.
Loads[{bnum1, bnum2, …}]
returns the part of the current load vector associated with the specified bodies.
Loads[All] Loads[bnum, Coordinates → coordsys]
returns the entire load vector of the current model. returns the list {force, moment} representing the total force and moment applied to body bnum. The force and moment are formed with respect to coordsys, either Global or Local.
The load inspection function.
Type
is an option for Loads that specifies whether to return applied, reaction, or dynamic loads.
Type → Applied
is the default setting that causes Loads to return the total externally applied load on the body.
Type → Reaction
causes Loads to return the total load applied to the body by the constraints.
Type → Dynamic
causes Loads to return the total dynamic loads on the body. Given that F = ma, the dynamic loads are equal to – ma.
An option for Loads.
If the Coordinates option is not specified, Loads returns forces that are generalized to the current velocity coordinate system. Since velocity in the current model is represented by {Xnd, Ynd, Qnd} the returned loads are {Fx, Fy, M}, calculated about the local origin. Consider the 2D ladder-on-wall model of Section 7.3.2. Loads can be used to find the total load applied to the ladder resolved into a force applied to the origin of the ladder, and a moment.
MechanicalSystems
280
Here is the total load applied to the ladder. % ê. [email protected], Solution → StaticD
In[24]:= Loads@ladderD
Out[24]= 80, −110, 5 + 600 Sin@Θ2D< Out[25]= 80, −110, −331.<
In all cases, the sum of the applied, reaction, and dynamic loads on any body must be zero. Since there are no dynamic loads in this model, the total reaction loads on all constraints must be equal to the total applied loads.
Here is the total reaction load applied by the constraints to the ladder. In[26]:= Loads@ladder, Type → ReactionD
% ê. LastSolve@D
Out[26]= 8−Λ1 + 10 Λ3, −10 Λ2, −100 Λ3 Cos@Θ2D< Out[27]= 80., 110., 331.<
The dynamic, or inertial, loads on the ladder are identically zero because there are no masses or moments of inertia defined. If there were, the dynamic loads would be functions of the model’s acceleration variables, X3dd, Y3dd, and so on.
Here are the inertial loads on the ladder. In[28]:= Loads@ladder, Type → DynamicD Out[28]= 80, 0, 0<
Note that the numerical sum of the loads is zero, but the algebraic terms are quite different. This basically shows part of the system of equations that was solved by SolveMech when the numeric values of the Lagrange multipliers were found.
Chapter 7: Loads and Reactions
281
7.4 Multistage Loads This section demonstrates how to use StageSwitch and TimeSwitch in the context of a loaded mechanism model. The use of StageSwitch and TimeSwitch in a kinematic model is covered in Chapter 5. In general, switching forces on and off is treated in the same way as switching constraints on and off.
7.4.1 Stage and Time Switches StageSwitch The Mech StageSwitch function is used for loads in the same manner as it is used for constraints, with one important difference. Because loads are cumulative, StageSwitch can apply more than one of the switched loads at a time, or no loads at all.
StageSwitch[test1, loads1, test2, loads2, …]
returns a Mech load object that is used in place of a normal load object in a model. StageSwitch evaluates all of the testi, and applies the sum of each of the loadsi corresponding to each of the testi that return True.
The multistage mechanism load-switching function.
Unlike most built-in Mathematica switching functions, StageSwitch does evaluate its arguments immediately. This means that test functions such as SameQ cannot be used because SameQ evaluates to True or False immediately, without waiting for some future condition to change and make it True or False in the context of the mechanism model. StageSwitch will fail if any of the test expressions fail to return True or False at runtime. Each of the loads supplied to the StageSwitch must be a Mech load object with the head SysLoad, or a nested list of load objects. Example This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
MechanicalSystems
282
The following example shows how a StageSwitch might be used to model a force that is either a constant force in one direction or a function of T in another direction. Which force is applied is determined by the value of the user-defined symbol whichload.
Here is a valid StageSwitch load object. In[2]:= ground = 1;
slider = 2; whichload =. StageSwitch@ whichload 1, Force@slider, Line@ground, 80, 0<, 81, 0
Out[5]= SysLoad@8Force, Force<, 82, 2<, <>D
TimeSwitch The TimeSwitch function is also used to apply loads in much the same way it is used to apply constraints. The primary difference is that the load object TimeSwitch may have a leading time, before which no load is applied, and a trailing time, after which no load is applied.
TimeSwitch[time0, load0, time1, load1, …, timen, loadn, time(n+1)]
returns a list of Mech load objects that are used in place of a normal load object in a model. TimeSwitch applies loadsi when the value of time is greater than timei and less than time(i+1). The timei must evaluate to numbers in ascending order. time0 and time(n+1) are optional. The default values of time0 and time(n+1) are -$MaxMachineNumber and +$MaxMachineNumber, respectively. TimeSwitch functions analogously to Which.
The time-dependent, load switching function.
Each of the loads supplied to the TimeSwitch must be a Mech load object or a nested list of load objects.
Chapter 7: Loads and Reactions
283
Example The following example shows how a TimeSwitch might be used to model a force applied to the slider that is to remain constraint in magnitude until the value of time reaches 2.0, at which time the force begins to increase linearly with time.
Here is a valid TimeSwitch load object. In[6]:= ground = 1;
slider = 2; In[8]:= TimeSwitch@
Force@slider, Line@ground, 80, 0<, 84, 0
Out[8]= SysLoad@8Force, Force<, 82, 2<, <>D
7.4.2 2D Example Mechanism To demonstrate the use of Mech’s StageSwitch function, a 2D model is developed that is subject to a variable applied load. The model is a simple piston-pump that has a nonlinear compression function applied to the piston. The input to the model is to rotate the crankshaft. The pressure on the piston increases slowly but nonlinearly until near the end of its stroke, at which time the pressure decreases very rapidly back to zero. The pressure then remains at zero through the return stroke of the piston.
Here is the 2D piston-pump graphic. 2
1
0
-1
-2 -2
0
2
4
6
MechanicalSystems
284
Constraints Four constraints, one of which is a driving constraint, are required to model the piston-pump. Body objects are not defined for this model. The coordinates of the local points are simply entered directly in the point and axis objects in the constraints. • A Revolute2 constraint constrains the center of the crank to be coincident with the global origin. • A RelativeDistance1 constraint models the connecting rod by placing the piston a constant distance from an eccentric point on the crank. • A Translate2 constraint models the piston and cylinder by constraining the piston to translate along a horizontal line on the ground body. • A RotationLock1 constraint is the driving constraint that makes the crank angle a function of time. Names are defined for each of the bodies in the model. In[9]:= ground = 1;
crank = 2; piston = 3;
Here are the constraint objects for the model. In[12]:= cs@1D = Revolute2@1,
Point@ground, 0D, Point@crank, 0DD; cs@2D = RelativeDistance1@2, Point@crank, 82, 0
Here is a reasonable initial guess for the piston. In[17]:= SetGuess@8X3 → 4
Chapter 7: Loads and Reactions
285
Loads Only one load is applied to the piston-pump model, but this one load will be a two-stage StageSwitch load. Since the piston is initially at the top of its stroke and proceeds toward the bottom, there is no load on the piston for the first half turn of crank rotation. The two segments of the StageSwitch load are defined as follows. • Stage one is a Force on the piston that rises from zero at bottom-dead-center to seven units when the X coordinate of the piston is equal to 5.0. • Stage two is a Force on the piston that falls from seven units back to zero as the X coordinate of the piston goes from 5.0 to 5.5. Here are the two forces on the piston. 9.0 − 2.0; 6.0 − X3 f2 = 3.5 H1 − Sin@2 N@πD HX3 − 5.25LDL;
In[18]:= f1 =
The StageSwitch load must switch between f1 and f2 at the proper time. This is done by testing the value of the X coordinate of the piston X3 and the angular coordinate of the crank Θ2.
Here is the StageSwitch load object for the pump. In[20]:= ld@1D = StageSwitch@
X3 < 5.0 && Sin@Θ2D < 0, Force@piston, Line@piston, 0, 8−1, 0 5.0 && Sin@Θ2D < 0, Force@piston, Line@piston, 0, 8−1, 0
Out[20]= SysLoad@8Force, Force<, 83, 3<, <>D
The loads are incorporated into the model. In[21]:= SetLoads@ld@1DD
Running the Model The loaded model can now be run with the Solution → Static option for SolveMech. Note that all of the loads are zero at T = 0.1 because the force is turned off.
MechanicalSystems
286
Now run the model at T = 0.1. In[22]:= [email protected], Solution → StaticD
Out[22]= 8T → 0.1, X2 → 1.88944 × 10−22 , Y2 → 0., Θ2 → 0.628319, X3 → 4.9147,
Y3 → 0., Θ3 → 0., Λ1 → 0., Λ2 → 0., Λ3 → 0., Λ4 → 0., Λ5 → 0., Λ6 → 0.<
Here is the piston-pump model at T = 0.1. 2
1
0
-1
-2 -2
0
2
4
6
By creating a large table of solution points, plots can be made of various forces, moments, and reactions in the model using ListPlot.
Here is a list of 81 solutions. In[23]:= statictab = SolveMech@80, 1<, 81, Solution → StaticD;
The Loads function returns the total load on the piston.
In[24]:= Loads@pistonD ê. statictabP70T Out[24]= 8−3.81102, 0., 0<
Chapter 7: Loads and Reactions
287
The force on the piston can be plotted as a function of piston travel.
In[25]:= ListPlot@8X3, −Loads@pistonDP1, 1T< ê. statictab, PlotRange → All, PlotJoined → TrueD 6 5 4 3 2 1
3
Out[25]=
4
5
Graphics
The reaction forces at the constraints can be found with the Reaction function. Constraint 4 is the Rota tionLock1 driving constraint, so its reaction is the moment applied to the crank. Constraint 1 is the Revolute2 constraint that positions the crank axis, so its reactions are the X and Y forces supporting the crank axis.
Here is the moment required to rotate the crank.
In[26]:= Reaction@4, crankD ê. statictabP70T Out[26]= 880, 0<, 8.18398<
MechanicalSystems
288
Here is the reaction at the crank as a function of time.
In[27]:= ListPlot@8T, Reaction@4, crankDP2T< ê. statictab, PlotRange → All, PlotJoined → TrueD 10 8 6 4 2
0.2
Out[27]=
0.4
0.6
0.8
1
Graphics
Because ListPlot is not able to plot two lists simultaneously, Mathematica graphics primitives are used directly to plot the X and Y reactions.
Here are the X and Y reaction forces at the crank axis as a function of time. In[28]:= Show@Graphics@8
Line@8T, Reaction@1, crankDP1, 1T< ê. statictabD, Line@8T, Reaction@1, crankDP1, 2T< ê. statictabD
7 6 5 4 3 2 1 0.2
Out[28]=
0.4
Graphics
0.6
0.8
1
8. Inverse Dynamics Overview This chapter covers MechanicalSystems basic dynamic modeling capabilities for fully constrained models. If mass properties are defined for the bodies in a model, Mech can calculate the inertial loads on the model and the resulting reaction forces. Because the inertial loads are a function of the velocity and acceleration of the bodies, a model must have some dependence on time in order to have nonzero inertial loads. The forces that result from an inverse dynamic analysis are represented in the same manner as those of a static analysis, in the form of Lagrange multipliers (generalized forces). The free response dynamics of underconstrained systems is covered in Chapter 10.
8.1 Inertia Properties In order for any inertial loads to exist in a mechanism model, the bodies of the mechanism must have nonzero inertia properties, mass and inertia. The inertia properties of the bodies in a model are defined in Mech body objects, and then added to the current model with the SetBodies command.
8.1.1 Body Options Mech body objects are used to define specific properties of a body in a mechanism model. Properties are defined with options to the Body function.
Body[bnum, options]
returns a SysBody data object that defines the properties of body bnum. Each property of the body is specified with an option.
The body object builder.
MechanicalSystems
290
Two of the options for Body that are used for basic kinematic models are PointList and InitialGuess, which are discussed in Section 2.1. The remaining three options for Body are used to define the inertia properties of a body. 2D Mass → M
specifies the mass of the body. Mass must be specified by a number or an expression that evaluates to a number at runtime.
Inertia → I
specifies the centroidal moment of inertia of the body. Inertia must be specified by a number or an expression that evaluates to a number at runtime.
Centroid → {x, y}
specifies the location of the centroid of the body, in local coordinates. Centroid must be specified by a list of two numbers or two expressions that evaluate to numbers at runtime.
Automatic
is the default setting for all options for Body. This setting leaves the current value of the property unchanged. If unspecified, the Mass, Inertia, and Centroid of a body are 0, 0, and {0, 0}, respectively.
2D inertia property options for Body.
Chapter 8: Inverse Dynamics
291
3D Mass → M
specifies the mass of the body. Mass must be specified by a number or an expression that evaluates to a number at runtime.
Inertia → {Ixx, Iyy, Izz, Ixy, Iyz, Izx}
specifies the centroidal moments and products of inertia of the body. Inertia must be specified by a list of six numbers or six expressions that evaluate to numbers at runtime. These numbers are used to build the local inertia matrix of the body: {{Ixx, Ixy, Izx}, {Ixy, Iyy, Iyz}, {Izx, Iyz, Izz}}
Centroid → {x, y, z}
specifies the location of the centroid of the body, in local coordinates. Centroid must be specified by a list of three numbers or three expressions that evaluate to numbers at runtime.
Automatic
is the default setting for all options for Body. This setting leaves the current value of the property unchanged. If unspecified, the Mass, Inertia, and Centroid of a body are 0, {0, 0, 0, 0, 0, 0}, and {0, 0, 0}, respectively.
3D inertia property options for Body.
Executing the Body function does not, in itself, have any affect on the current Mech model. The returned SysBody data objects must be added to the model with the SetBodies command.
SetBodies[Body[bnum, options], …] The body object processing function.
adds the inertia and geometry data contained in the body objects to Mech’s internal database.
MechanicalSystems
292
8.1.2 Examples To use the 2D example mechanism of Section 1.2 in a dynamic analysis, inertia properties would be added with body objects and the SetBodies function. The crankshaft-piston mechanism used three Modeler2D bodies: the ground, crankshaft, and piston.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Names are defined for each of the bodies in the model. In[2]:= ground = 1;
crankshaft = 2; piston = 3;
For this example, it is assumed that the constraints of the crankshaft-piston model have already been defined as they were in Section 1.2. There is no use in adding inertia properties to the ground body, as it cannot move, and therefore can sustain no inertial loads. The inertia properties of the crankshaft and piston are defined and added to the model.
Here are the mass and inertia properties for the crankshaft and piston. In[5]:= bd@2D = Body@crankshaft,
Mass → 10, Inertia → 0.4D; bd@3D = Body@piston, Mass → 2, Inertia → 0.01D;
The inertia properties must be incorporated into the model. In[7]:= SetBodies@bd@2D, bd@3DD
Because the default setting for all options for Body is Automatic, which leaves the current values of properties unchanged, a single inertia property can be changed without affecting the rest of the model. An example is changing the location of the centroid of the piston without changing any other body properties.
Chapter 8: Inverse Dynamics
293
This moves the centroid of the piston only.
In[8]:= SetBodies@Body@piston, Centroid → 80, 0.1
Each of the inertia property options for Body can be interrogated to find the current settings of a body property.
Mass[bnum] Inertia[bnum]
returns the mass of body bnum. returns the moment of inertia (2D) or inertia properties (3D) of body bnum.
Centroid[bnum]
returns the local coordinates of the centroid of body bnum.
Inertia property functions.
Here is the mass of the crankshaft. In[9]:= Mass@crankshaftD Out[9]= 10
8.1.3 Compound Inertia Properties The centroidal inertia properties of a 3D body in a mechanism model must be determined before the dynamic reaction forces in a model can be found. For complex 3D bodies, the values of the moments and products of inertia can be quite difficult to determine manually. This problem is alleviated by the availability of 3D solid modeling systems that can generally calculate the inertia properties of any solid body that they are capable of modeling. If the inertia properties of a body must be found manually, the body can be subdivided into several elementary geometrical components such as spheres, cylinders, or plates. Modeler3D provides several functions to aid in manipulating the inertia properties of a body or multiple bodies. These functions can make the task of determining the inertia properties of a slightly complex body more manageable.
MechanicalSystems
294
ParallelAxis[{x, y, z}, mass, {Ixx, Iyy, Izz, Ixy, Iyz, Izx}]
uses the parallel axis theorem to transform the inertia properties of a body into or out of a centroidal reference frame. Assuming that the {Ixx, Iyy, …} are centroidal inertia properties of a body, ParallelAxis returns the list {Ixx', Iyy', …} of inertia properties with respect to a noncentroidal reference frame in which {x, y, z} is the vector from the origin of the noncentroidal frame to the centroid.
ParallelAxis[centroid, mass, inertia, {ang, {x, y, z}}]
specifies that the centroidal reference frame in which the specified inertia properties are calculated is rotated ang radians about the axis {x, y, z} with respect to the noncentroidal frame.
CompositeInertia[{centroid1, mass1, inertia1, rotation1}, … , {centroidn, massn, inertian, rotationn}]
returns the list {centroid, mass, inertia} of the centroidal inertia properties of a composite body, made up of n subcomponents. Given a local reference frame affixed to the composite body, each argument to CompositeInertia specifies the centroidal inertia properties of a subcomponent of the composite body, with respect to the local reference frame. If a rotationi is omitted, it is assumed to be {0, {x, y, z}}, that is, no rotation.
PrincipalAxes[{Ixx, Iyy, Izz, Ixy, Iyz, Izx}]
returns the list {{I1, I2, I3}, {axis1, axis2, axis3}}, where I1–I3 are the principal moments of inertia and axis1–axis3 are the corresponding principal axes of the body represented by the given inertia properties. {axis1, axis2, axis3} is effectively the rotation matrix from the reference frame in which the Ixx… were specified to the principal axes reference frame.
InertiaMatrix[{Ixx, Iyy, Izz, Ixy, Iyz, Izx}]
Utilities for manipulating 3D inertia properties.
returns the inertia matrix: {{Ixx, Ixy, Izx}, {Ixy, Iyy, Iyz}, {Izx, Iyz, Izz}}
Chapter 8: Inverse Dynamics
295
Inertia Transformations The following example takes the inertia properties of a triangular plate that are calculated in a noncentroidal reference frame and convert them to a centroidal frame. The plate is an isosceles right triangle with two one-unit sides.
Triangular plate 1.5
z
1
0.5
0 1
y 0
x 0.5 1
0 0.5 1
1.5 1.5
The inertia properties of the plate, in the shown reference frame, can be integrated directly or found in an engineering or mathematics handbook.
Here are the basic inertia properties of the plate.
i j‡ In[10]:= ixx = ‡ j j 1
0
Out[10]=
k
1−x
y2
0
1 12
iyy is known by symmetry. In[11]:= iyy = ixx;
y z x yz {
MechanicalSystems
296
i j In[12]:= izz = ‡ j j‡ 1
0
Out[12]=
k
1−x
0
y Hx2 + y2 L yz z x {
1 6
i j In[13]:= ixy = ‡ j j‡ 1
0
Out[13]= −
k
1−x
0
y z x −x y yz {
1 24
iyz and izx are zero because the plate has zero thickness. In[14]:= iyz = izx = 0;
The location of the centroid of the plate can also be found by direct integration, knowing that the mass of the plate is 1/2 because the density of the plate is one unit mass per unit area.
Here are the mass and centroid location. In[15]:= bmass =
1 2
;
Ÿ0 IŸ0 1
In[16]:= cent =
1 1 Out[16]= 9 , , 0= 3 3
1−x
8x, y, 0< yM x bmass
This loads the Modeler3D package. In[17]:= Needs@"MechanicalSystems`Modeler3D`"D
To use the ParallelAxis function to transform noncentroidal inertia properties into a centroidal reference frame, instead of vice versa, the vector from the centroid to the origin of the noncentroidal frame is specified in the centroidal reference frame coordinates, and a negative mass is specified. Note that the sign of the centroid vector is irrelevant, but it must be given in the correct reference frame if there is any relative rotation between the frames. ParallelAxis returns the centroidal inertias {Ixx, Iyy, …} that are reduced in magnitude relative to the noncentroidal properties.
Chapter 8: Inverse Dynamics
297
Here are the centroidal inertia properties of the plate.
In[18]:= centinertia = ParallelAxis@cent, −bmass, 8ixx, iyy, izz, ixy, iyz, izx
1 1 1 1 , , , , 0, 0= 36 36 18 72
The principal axes of inertia of the plate can be found with the PrincipalAxes function. Note that the list of the three principal axes of inertia forms the rotation matrix from the local reference frame of the inertia properties to the principal reference frame.
Here are the principal inertias and axes of the plate. In[19]:= princeaxis = PrincipalAxes@centinertiaD Out[19]= 99
1 1 1 1 1 1 1 , , =, 980, 0, 1<, 9 è!!!! , è!!!! , 0=, 9− è!!!! , è!!!! , 0=== 18 24 72 2 2 2 2
This rotates the original inertia matrix into the principal frame. In[20]:= [email protected]@princeaxisP2TD Out[20]= 99
1 1 1 , 0, 0=, 90, , 0=, 90, 0, == 18 24 72
Composite Bodies The CompositeInertia function is used to add the inertia properties of several bodies together and return the centroidal inertia properties of their superset. In the following example, the inertia properties of the triangular plate are added to the inertia properties of a cylinder that is attached to the plate and rotated through a 30-degree angle about the local x axis, as shown below. The radius of the cylinder is 0.25 and the length is 1 unit. The bottom surface of the cylinder is coplanar with the local x axis of the plate.
MechanicalSystems
298
A composite body 1.5 z
1
0.5
0 y
1
0 0.5
x 1 -0.5
0
0.5
1.5 1.5
1
The centroidal inertia properties of a cylinder in an axial reference frame can be found in an engineering manual. These properties have been determined and are given in the following example.
Here are the inertia properties of the cylinder. In[21]:= rad = 0.25; height = 1.0; density = 10.0;
cylmass = N@πD rad2 height density Out[22]= 1.9635 In[23]:= cylcent = 90.5, −0.25,
Out[23]= 80.5, −0.25, 0.433013< In[24]:= cylcentinertia = 9
1 12
è!!!!!!!!!! 3.0 4
=
H3 rad2 + height2 L,
Out[24]= 80.194304, 0.194304, 0.0613592, 0, 0, 0<
1 12
H3 rad2 + height2 L,
rad2 2
, 0, 0, 0= cylmass
CompositeInertia can now be used to combine the inertia properties of the plate and the cylinder into one set of centroidal inertia properties. Note that the optional rotation argument is used for the cylinder since the reference frame in which its inertia properties were calculated was not aligned with the local reference frame.
Chapter 8: Inverse Dynamics
299
Here are the inertia properties of the combined thin plate and cylinder. In[25]:= CompositeInertiaA
8cent, bmass, centinertia<,
9cylcent, cylmass, cylcentinertia, 9
N@πD 6
Out[25]= 880.466173, −0.131605, 0.345127<, 2.4635,
, 81, 0, 0<==E
80.432411, 0.274638, 0.296828, 0.0526337, 0.158229, −0.0287606<<
2D Inertia Functions Modeler2D also provides two inertia transformation functions that parallel those in Modeler3D, although the calculations they perform are trivial by comparison.
ParallelAxis[{x, y}, mass, inertia]
uses the parallel axes theorem to transform the moment of inertia of a body into or out of a centroidal reference frame. Assuming that the given inertia is centroidal, Parallel Axis returns the moment of inertia with respect to a noncentroidal reference frame in which {x, y} is the vector from the origin of the noncentroidal frame to the centroid. Negative mass can be given to transform a noncentroidal moment of inertia into a centroidal reference frame.
CompositeInertia[{centroid1, mass1, inertia1}, …, {centroidn, massn, inertian}]
returns the list {centroid, mass, inertia} of the centroidal inertia properties of a composite body made up of n components. Given a local reference frame affixed to the composite body, each argument to CompositeInertia specifies the centroidal inertia properties of a component of the composite body with respect to the local reference frame. Negative massi can be specified for components that are voids.
Utilities for manipulating 2D inertia properties.
MechanicalSystems
300
8.2 Kinematic and Dynamic Solutions This section describes the function of Mech’s inverse dynamics solution block. Inverse dynamics allows the dynamic reaction forces in a fully kinematically constrained model to be found. The motion of such a model is completely defined by the kinematics of the model, only the reaction forces that result from the constrained motion are found through inverse dynamics. To find the free response of a model with one or more degrees of dynamic freedom, consult Chapter 10.
8.2.1 Dynamics Options Once the kinematic constraints and the inertia properties of a body have been defined, the dynamic forces in a mechanism can be determined. The Solution option to SolveMech is used to tell Mech to calculate the generalized reaction forces in the model and to include the forces due to inertia.
Solution
is an option for SolveMech that specifies the solution level sought.
Solution → Static
finds the location of each body, and the generalized reaction forces due to static loads. If any forces in the model depend on velocity terms, they will be set to zero.
Solution → Kinematic
finds the location and velocity of each body, and the generalized reaction forces due to static or velocity-dependent loads.
Solution → Dynamic
finds the location, velocity, and acceleration of each body, and the generalized reaction forces due to all loads, including inertial loads.
An option for SolveMech.
The purpose of the Kinematic setting is to allow for velocity-dependent loading, such as damping, while still not including the dynamic loading. Note that using the Static setting does not necessarily produce an error in a model that has velocity-dependent loading, because Static sets the velocities to zero. This condition may result in an incidental error, however, if the velocity-dependent terms happen to blow up at zero velocity.
Chapter 8: Inverse Dynamics
301
The Dynamic setting calculates the mechanism accelerations and then adds the inertial loads due to the acceleration of each body to the model’s applied load vector before calculating the generalized reaction forces. Note that the Dynamic setting must be used to include the centrifugal forces, even though they depend on velocity and not acceleration.
8.2.2 3D Example Mechanism A Modeler3D example model is developed to demonstrate a simple gyroscopic inertial loading condition. The model is a flywheel with an angular velocity vector with a changing direction. The model consists of only one moving body, the flywheel. The flywheel spins about an axis that is attached to the ground at one point. The axis of rotation of the flywheel is then rotated about another nonparallel axis affixed to the ground. Thus, the direction of the axis of rotation of the flywheel changes with time.
This loads the Modeler3D package. In[1]:= Needs@"MechanicalSystems`Modeler3D`"D
Here is a graphic of the flywheel model. z
z
y 1 2 x x
y
MechanicalSystems
302
The Method → Angular option is given to SetSymbols before building any other part of the flywheel model. This is done so that the angular velocity and angular acceleration of the flywheel is calculated directly, instead of being calculated in terms of derivatives of Euler parameters. Note that this is not a necessary step to obtain the dynamic forces.
This causes angular velocities to be calculated directly so that it won’t be necessary to convert the Euler parameters into angular velocity. In[2]:= SetSymbols@Method → AngularD
Inertia The flywheel is modeled by four one-unit point masses, symmetrically placed about the axis of rotation. The Modeler3D CompositeInertia function can be used, trivially, to find the net inertia properties of the flywheel. In[3]:= Off@General::"spell1"D
8fcent, fmass, finertia< = CompositeInertia@ 881, 0, 0<, 1, 80, 0, 0, 0, 0, 0<<, 880, 1, 0<, 1, 80, 0, 0, 0, 0, 0<<, 88−1, 0, 0<, 1, 80, 0, 0, 0, 0, 0<<, 880, −1, 0<, 1, 80, 0, 0, 0, 0, 0<
Out[4]= 880, 0, 0<, 4, 82, 2, 4, 0, 0, 0<<
Bodies One body object is defined for the flywheel model. The ground body does not have a body object because it has no inertia or required point definitions. The body object for the flywheel contains the inertia properties and the locations of each of the four point masses.
Names are defined for each of the body numbers in the model. In[6]:= ground = 1;
flywheel = 2;
Chapter 8: Inverse Dynamics
303
Here is the body object for the flywheel. In[8]:= SetBodies@bd@flywheelD =
Body@flywheel, PointList → 8 H∗P1∗L81, 0, 0<, H∗P2∗L80, 1, 0<, H∗P3∗L8−1, 0, 0<, H∗P4∗L80, −1, 0<<, Centroid → fcent, Mass → fmass, Inertia → finertiaDD
Constraints Three constraints, two of which are functionally dependent on time, are required to model the flywheel mechanism. A Spherical3 constraint places the center of the flywheel at the global origin. A Parallel2 constraint forces the axis of rotation of the flywheel to be parallel with a specified vector on the ground body. The direction of the axis vector on the ground body is explicitly a function of time T. This constraint effectively causes the axis of rotation of the flywheel to change direction with time. A ProjectedAngle1 constraint rotates the flywheel about its axis. Note the choice of the vector that was used on the ground body. The vector in the Y direction on the ground body is always normal to the axis of rotation of the flywheel. If a vector in the X direction was chosen instead, the constraint would become singular at T = 0.25. Note also that the flywheel is spinning 10 times more rapidly about its symmetry axis than its axis is rotating with respect to the ground.
Here are the constraint objects for the flywheel. In[9]:= SetConstraints@
cs@1D = Spherical3@1, Point@ground, 0D, Point@flywheel, 0DD, cs@2D = Parallel2@2, Vector@flywheel, 80, 0, 1
MechanicalSystems
304
Runtime Because of the presence of T in the constraints, the model can be run through its intended range of motion by varying T directly with the SolveMech command.
Now run the model at T = 0.02. In[10]:= [email protected]
Out[10]= 8T → 0.02, X2 → 0., Y2 → 0., Z2 → 0., Eo2 → −0.807421,
Ei2 → −0.0369073, Ej2 → −0.0507986, Ek2 → −0.586625<
Here is the flywheel at T = 0.02. z
z y
1 2
x
y
x
8.2.3 Inertial Loading No forces are applied to the model with SetLoads because only the inertial loading of the flywheel is being considered. All of the inertia properties have already been defined, so all that must be done to find the dynamic solution is to request it of SolveMech with the solution option.
Chapter 8: Inverse Dynamics
305
The dynamic solution at T = 0. In[11]:= [email protected], Solution → DynamicD
Out[11]= 8T → 0., X2 → 0., Y2 → 0., Z2 → 0., Eo2 → 1., Ei2 → 9.11493 × 10−16 ,
Ej2 → 1.25456 × 10−15 , Ek2 → −6.15066 × 10−13 , X2d → 0., Y2d → 0., Z2d → 0., Ωx2 → 7.88264 × 10−14 , Ωy2 → 6.28319, Ωz2 → 62.8319, X2dd → 0., Y2dd → 0., Z2dd → 0., Ωx2d → 394.784, Ωy2d → 2.47641 × 10−12 , Ωz2d → −4.95281 × 10−13 , Λ1 → 0., Λ2 → 0., Λ3 → 0., Λ4 → −3158.27, Λ5 → −1.97226 × 10−9 , Λ6 → 2.35086 × 10−24 <
The angular velocity and acceleration of the flywheel can be read directly from the solution rules returned by SolveMech, or Modeler3D output functions can be used. Note that the angular acceleration is orthogonal to the angular velocity. Here are the angular velocity and acceleration of the flywheel.
In[12]:= Chop@8Omega@flywheelD, Alpha@flywheelD< ê. LastSolve@DD Out[12]= 880, 6.28319, 62.8319<, 8394.784, 0, 0<<
The moment that is applied to the flywheel to enforce the specified rotation is the reaction force to constraint 2, the constraint that controls the direction of the axis of the flywheel. Note that the reaction to constraint 3 is zero. No moment is required to spin the flywheel about its primary axis, only to change the direction of the axis. Here are the moments that are applied to the flywheel by the constraints.
In[13]:= Reaction@2, flywheelD ê. LastSolve@D
Out[13]= 880, 0, 0<, 81579.14, 1.48584 × 10−11 , −1.98112 × 10−12 << In[14]:= Reaction@3, flywheelD ê. LastSolve@D
Out[14]= 880, 0, 0<, 8−5.8986 × 10−39 , 0, −2.35086 × 10−24 <<
As the position of the flywheel is advanced in time, the components of the angular velocity change, and the components of the angular acceleration and the applied moment follow. This calculates the dynamic solution at T = 0.01. In[15]:= [email protected], Solution → DynamicD;
306
MechanicalSystems
Here are the angular velocity and acceleration.
In[16]:= 8Omega@flywheelD, Alpha@flywheelD< ê. LastSolve@D
Out[16]= 883.94524, 6.28319, 62.7079<, 8394.005, 1.80099 × 10−11 , −24.7887<<
Here is the applied moment.
In[17]:= Reaction@2, Point@flywheel, 1DD ê. LastSolve@D
Out[17]= 880, 0, 0<, 81576.02, 1.07775 × 10−10 , −99.1548<<
8.3 Friction and Damping This section demonstrates various techniques of applying friction and damping forces to a mechanism model with MechanicalSystems.
8.3.1 Types of Friction Loads that can be applied to a Mech model fall into four basic categories with considerable overlap between them. An applied load is a load in which the magnitude and/or direction depends on the configuration of the model, on time, or is constant. Applied loads may or may not be conservative. Loads of this type are discussed throughout Chapter 7. A damping load is a nonconservative load in which the magnitude and/or direction depends on the velocity of the model. These loads are modeled by giving an expression for the load magnitude or direction that is functionally dependent on velocity terms, and then using the Kinematic or Dynamic option settings for SolveMech. A frictional load is a nonconservative load in which the magnitude and/or direction depends on the reaction forces applied by the constraints. These loads are modeled by giving an expression for the load magnitude or direction that is functionally dependent on the Lagrange multipliers, usually by using the Reac tion function to find the reaction force at a constraint.
Chapter 8: Inverse Dynamics
307
An inertial load is a load in which the magnitude and/or direction depends on the linear and angular acceleration and angular velocity of bodies in the model. Inertial loads are applied to the model automatically by specifying inertia properties for each body, and then using the Dynamic option setting for Solve Mech, as discussed in Section 8.2. Damping Damping loads are usually applied to a model in a relatively simple manner. To apply linear damping to a point on a moving body, a force is applied to the body that is inversely proportional to the velocity of the point. The magnitude of the force is proportional to the magnitude of the velocity of the point (relative to whatever the point is in contact with) and the direction vector of the force is opposite the velocity vector of the point.
This loads the Modeler3D package. In[1]:= Needs@"MechanicalSystems`Modeler3D`"D
Velocity[point]
returns the global velocity vector, {dX/dt, dY/dt, dZ/dt} of point.
The velocity of a point.
The following example shows how damping with a damping constant of 4.0 would be applied to a point at local coordinates {1, 0, 0} on body 2 in a 3D model.
Here is an example of an applied damping load. In[2]:= ld@1D = Force@2,
Axis@Point@2, 81, 0, 0
Out[2]= SysLoad@Force, 2, <>D
The line of action of the force passes through Point[2, {1,0,0}], which is not dependent on velocity, and points in the direction of the velocity of the point. The negation of the velocity vector causes the applied force to oppose the motion of the point, and the Magnitude → Relative setting causes the magnitude of the force to be 4.0 times the magnitude of the velocity vector, instead of a constant magnitude of 4.0.
MechanicalSystems
308
To model point damping that occurs at an interface between two moving bodies, the velocity of the point to which damping is applied must be known relative to the body that the point is in contact with. The Mech RelativeVelocity function returns this vector quantity.
RelativeVelocity[bnum, point]
returns {dX/dt, dY/dt, dZ/dt}, the global velocity vector of point relative to body bnum.
The velocity of a point relative to another body.
The following example shows how damping that exists between body 2 and body 3, with a damping constant of 4.0, would be applied to body 2 at local coordinates {0, 1, 0} in a 3D model.
Here is a load object that models point damping between two bodies. In[3]:= ld@1D = Force@2,
Axis@Point@2, 80, 1, 0
Out[3]= SysLoad@Force, 2, <>D
Note that the preceding example only applies the frictional force to body 2. An equal and opposite force should also be applied to body 3. Friction A Coulombic friction load is functionally dependent on reaction forces in the model. Such a load is usually applied by making the magnitude of the load a function of reaction forces by using the Mech Reaction function.
Reaction[cnum, Point[bnum, lpnt]]
returns the reaction force and moment that constraint cnum applies to body bnum, calculated about the specified point.
The reaction load from a constraint.
Coulombic friction forces may also be dependent on velocity terms to establish the direction of the frictional force.
Chapter 8: Inverse Dynamics
309
The following example shows how the friction of a point sliding on a plane might be modeled. The model uses a PointOnPlane1 constraint to place a point on body 2 in contact with a plane on body 3, and a coefficient of friction between the point and the plane is 0.3. The frictional force would be modeled in the general case by using the velocity vector of the point, relative to the plane, to define the direction of the force, and the reaction to the constraint times the coefficient of friction to define the magnitude. The second constraint in the following SetConstraints call is just a dummy constraint to fill out the needed 12 degrees of freedom.
Here is a dummy SetConstraints call with a PointOnPlane1 constraint. In[4]:= SetConstraints@
PointOnPlane1@1, Point@2, 81, 0, 0
The optional second argument of Force is used here to apply a force to body 2 and an equal and opposite force to body 3.
Here is a general method for modeling Coulombic friction on a PointOnPlane1 constraint. The coefficient of friction is 0.3. In[5]:= Force@2, 3,
Axis@Point@2, 81, 0, 0
Out[5]= SysLoad@8Force, Force<, 82, 3<, <>D
8.3.2 Damping Example To demonstrate the application of damping to a Mech model, a 2D model of a simple four-bar linkage is developed. The model consists of three moving bodies: the drive bar, the driven bar, and the center bar. The kinematic input to the model is the rotation of the drive bar. Damping is first applied to the model at a point on the center bar that traces out an eccentric path in the 2D plane. Coulombic friction is then applied to the rotational axis of the drive bar.
MechanicalSystems
310
This loads the Modeler2D package. In[6]:= Needs@"MechanicalSystems`Modeler2D`"D
Here is the four-bar mechanism, with a moving point locus. 4
3
2
1
0
-1
-2
-1
0
1
2
Bodies Four body objects are required for the four-bar model. Each bar is attached to another bar at its local origin and at a point at the other end of the bar on the local X or Y axis.
Names are defined for each of the body numbers in the model. In[7]:= Off@General::"spell1"D
ground = 1; drivebar = 2; drivenbar = 3; centerbar = 4; On@General::"spell1"D
Chapter 8: Inverse Dynamics
311
Here are the body objects for the four-bar model. In[13]:= bd@groundD = Body@ground,
PointList → 88−2, 3<
The body properties are incorporated into the current model. In[17]:= SetBodies@bd@groundD, bd@drivebarD, bd@drivenbarD, bd@centerbarDD
Constraints Five constraints, one of which is a driving constraint, are required to model the four-bar mechanism. A RotationLock1 constraint is used as a driving constraint to rotate the drive bar. Four Revolute2 constraints model the four pivot points in the four-bar mechanism.
Here are the constraint objects for the four-bar model. In[18]:= cs@1D = RotationLock1@1, drivebar, 2 N@πD TD;
cs@2D = Revolute2@2, cs@3D = Revolute2@3, cs@4D = Revolute2@4, cs@5D = Revolute2@5,
Point@drivebar, 0D, Point@ground, 0DD; Point@drivenbar, 0D, Point@ground, 1DD; Point@drivebar, 1D, Point@centerbar, 0DD; Point@drivenbar, 1D, Point@centerbar, 1DD;
The constraints are incorporated into the current model. In[23]:= SetConstraints@cs@1D, cs@2D, cs@3D, cs@4D, cs@5DD
Damping Load A damping force is applied to point 2 on the center bar relative to the ground. The direction of the frictional force opposes the global velocity of point 2, and the coefficient of damping is 5.0.
MechanicalSystems
312
Here is a damping load. In[24]:= ld@1D = Force@centerbar,
Axis@Point@centerbar, 2D, −Velocity@centerbar, 2DD, 5.0, Magnitude → RelativeD;
The load is incorporated into the current model. In[25]:= SetLoads@ld@1DD
Runtime Because of the presence of T in the driving constraint cs[1], the model can be run through its intended range of motion by varying T directly with the SolveMech command. The numerical value of T specifies the angle of rotation of the drive bar in revolutions.
Now run the model at T = 0.3. In[26]:= [email protected]
Out[26]= 8T → 0.3, X2 → 0., Y2 → 0., Θ2 → 1.88496, X3 → −2., Y3 → 3.,
Θ3 → 0.231291, X4 → −0.309017, Y4 → 0.951057, Θ4 → −0.422136<
Here is the four-bar model at T = 0.3. 4
3
2
1
0
-1
-2
-1
0
1
2
Chapter 8: Inverse Dynamics
313
Because the loading in this model is dependent on velocity terms, the Solution → Kinematic option must be used with SolveMech to solve for the reaction forces. If Solution → Static were used, SolveMech would assume that all velocities were zero, thus, the applied damping would have zero magnitude and zero reactions would result.
Here is the solution, including the generalized reaction forces. In[27]:= [email protected], Solution → KinematicD
Out[27]= 8T → 0.4, X2 → 0., Y2 → 0., Θ2 → 2.51327, X3 → −2., Y3 → 3., Θ3 → −0.00631963,
X4 → −0.809017, Y4 → 0.587785, Θ4 → −0.647238, X2d → 0., Y2d → 0., Θ2d → 6.28319, X3d → 0., Y3d → 0., Θ3d → −2.61247, X4d → −3.69316, Y4d → −5.0832, Θ4d → −1.52246, Λ1 → −56.4364, Λ2 → 40.2949, Λ3 → 40.4833, Λ4 → −29.3845, Λ5 → 0.185701, Λ6 → −40.2949, Λ7 → −40.4833, Λ8 → 29.3845, Λ9 → −0.185701<
The reaction moment at the rotational driver is the moment required to rotate the drive bar.
In[28]:= Reaction@1, drivebarD ê. LastSolve@D Out[28]= 880, 0<, 56.4364<
Here is the reaction force at the drive bar axis.
In[29]:= Reaction@2, drivebarD ê. LastSolve@D Out[29]= 88−40.2949, −40.4833<, 0<
Plots To generate a plot of the torque required to turn the drive bar, the four-bar model is run from T = 0 to T = 1 in 21 steps, a full turn of the drive bar, while requesting that SolveMech interpolate the results.
This generates an interpolated solution set and returns one part of the solution.
In[30]:= Hirules = SolveMech@80, 1<, 21,
Solution → Kinematic, Interpolation → TrueDLP10T Out[30]= Λ1 → InterpolatingFunction@880., 1.<<, <>D@TD
MechanicalSystems
314
Here is an explicit expression for the drive torque. In[31]:= drivetorque = Reaction@1, drivebarDP2T Out[31]= −Λ1
Here is a plot of the drive torque as a function of time.
In[32]:= Plot@Evaluate@drivetorque ê. irulesD, 8T, 0, 1
0.2
Out[32]=
0.4
0.6
0.8
1
Graphics
A parametric plot of the x-y reaction at the axis of the drive bar can be easily created. The plot ranges only from T = 0 to T = 0.95 so the start and end points are apparent.
Here is the drive arm axis reaction vector. In[33]:= axisreact = Reaction@2, drivebarDP1T Out[33]= 8−Λ2, −Λ3<
Chapter 8: Inverse Dynamics
315
Here is a parametric plot of the drive arm axis reaction vector.
In[34]:= ParametricPlot@Evaluate@axisreact ê. irulesD, 8T, 0, .95
-30
-20
-10
10 -10 -20 -30 -40
Out[34]=
Graphics
Friction Load A very simple Coulombic friction load is applied to the rotational axis of the drive bar, with respect to the ground. The load is a pure moment resisting the direction of motion, the magnitude of which is proportional to the magnitude of the reaction vector at the drive bar axis. A coefficient of friction of 0.5 is assumed and is applied to a journal bearing with radius 0.4.
Here is a simple Coulombic friction load. In[35]:= ld@2D = Moment@drivebar,
−0.5 0.4 Magnitude@Reaction@2, drivebarDP1TDD;
The load is added to the current model. In[36]:= SetLoads@ld@1D, ld@2DD
More Plots This generates another interpolated solution set. In[37]:= irules = SolveMech@80, 1<, 21,
Solution → Kinematic, Interpolation → TrueD;
MechanicalSystems
316
The drive torque function that was developed earlier can be plotted again with the new solution rules. Note that the required drive torque is slightly higher.
Here is a plot of the drive torque with friction at the drivebar axis.
In[38]:= Plot@Evaluate@drivetorque ê. irulesD, 8T, 0, 1
Out[38]=
0.4
0.6
0.8
1
Graphics
8.3.3 Friction Example To demonstrate the application of Coulombic friction to a Mech mechanism model, a 2D model of a slider on an inclined ramp is developed. The model consists of one moving body, the slider. As the slider is pushed along its track on the ground body, it travels along the initial horizontal part of the track until the tip of the slider encounters the upward turn of the track. The tip then progresses up the inclined ramp while the heel of the slider stays on the horizontal section. Coulombic friction is modeled at the two sliding interfaces at the tip and the heel of the slider. The Modeler2D TimeSwitch function is used to switch between the different friction forces as the tip of the slider passes from one section of the ramp to the next.
This loads the Modeler2D package. In[39]:= Needs@"MechanicalSystems`Modeler2D`"D
Chapter 8: Inverse Dynamics
317
Here is a graphic of the 2D slider-ramp model. 2
1.5
1 y
0.5 x
2
0
-0.5 0
1
2
3
4
Bodies Two body objects are defined for the slider-ramp model. • The ramp (body 1) requires five point definitions. P1 is the origin of the ramp. P2 is a point directly to the right of the origin to define the lower flat of the ramp. P3 is the center point of the curved section of the ramp. P4 and P5 are two points that define the upper flat of the ramp. • The slider (body 2) requires two local point definitions. P1 is the center of the heel of the slider, which is the local origin. P2 is the center of the tip of the slider. Note that points 3, 4, and 5 on the ramp are defined as functions of two user-defined variables radius and incline, so that the radius at the curve of the ramp and the angle of the incline can be changed easily. Because a gravitational force will be applied to the slider, the mass and centroid location are defined in the slider’s body object.
Names are defined for each of the bodies in the model. In[40]:= ramp = 1;
slider = 2;
MechanicalSystems
318
Here are the body objects for the slider-ramp. In[42]:= radius =.
incline =.
In[44]:= bd@rampD = Body@ramp, PointList → 8
H∗P1∗L80, 0<, H∗P2∗L82, 0<, H∗P3∗L82, radius<, H∗P4∗L82 + radius ∗ Sin@inclineD, radius − radius ∗ Cos@inclineD<, H∗P5∗L82 + radius ∗ Sin@inclineD, radius − radius ∗ Cos@inclineD< + PolarToXY@82, incline
In[45]:= bd@sliderD = Body@slider, PointList → 8
H∗P1∗L80, 0<, H∗P2∗L81.5, 0<<, InitialGuess → 88.5, .25<, 0<, Mass → 1.0, Centroid → 8.75, 0
The body properties are added to the current model. In[46]:= SetBodies@bd@rampD, bd@sliderDD
Constraints Three constraints, one of which is a driving constraint, are required to model the slider-ramp mechanism. • A RelativeX1 constraint controls the horizontal position of the heel of the slider. This constraint is a driving constraint because it is functionally dependent on the time variable T. • A RelativeY1 constraint keeps the heel of the slider in contact with the ramp. • A TimeSwitch constraint keeps the tip of the slider in contact with the ramp. The TimeSwitch constraint has three stages: 1. A PointOnLine1 constraint keeps the tip of the slider in contact with the horizontal section of the ramp. 2. A RelativeDistance1 constraint keeps the tip of the slider in contact with the curved section of the ramp. 3. A PointOnLine1 constraint keeps the tip of the slider in contact with the inclined section of the ramp.
Chapter 8: Inverse Dynamics
319
The value of the initial switch time determined by inspection is 0.5. However, the value of the second switch time is more difficult to determine analytically, so it is left as the symbol swtime and the FindSwitchTime function is used to find a numeric value.
Here are the constraint objects for the slider-ramp model. In[47]:= swtime =.
cs@1D = RelativeX1@1, Point@slider, 0D, TD; cs@2D = RelativeY1@2, Point@slider, 0D, .25D; cs@3D = TimeSwitch@3, PointOnLine1@1, Point@slider, 2D, Line@ramp, 1, 2D, .25D, 0.50, RelativeDistance1@2, Point@ramp, 3D, Point@slider, 2D, .25D, swtime, PointOnLine1@3, Point@slider, 2D, Line@ramp, 4, 5D, .25DD;
Here, the constraints are added to the current model. In[51]:= SetConstraints@cs@1D, cs@2D, cs@3DD
Runtime Before the model can be run the undefined symbols, incline, radius, and swtime, must be defined. $MechVariables returns the names of any symbols that have been recognized as being part of the current model.
Here is a Mech utility. In[52]:= $MechVariables
Out[52]= 8incline, radius, swtime<
The embedded symbols are explicitly defined. In[53]:= incline = 45 N@°D;
radius = 0.5; swtime = 0.7;
MechanicalSystems
320
Now the model is run at T = 0.65. In[56]:= [email protected]
Out[56]= 8T → 0.65, X2 → 0.65, Y2 → 0.25, Θ2 → 0.0329343<
Here is the slider-ramp model at T = 0.65. 2
1.5
1 y
0.5 x
2
0
-0.5 0
1
2
3
4
Switch Time Now the exact value of swtime can be found with FindSwitchTime. Because the slider passes tangentially from the curved section of the ramp onto the inclined section (which implies that there is no discontinuity in the velocity of the slider at the transition), the TangentConstraint option must be used with Find SwitchTime. This option tells FindSwitchTime to look for the point of velocity equality instead of just location equality.
Find switch time 2 in constraint 3.
In[57]:= swtime = T ê. FindSwitchTime@3, 2, TangentConstraint → TrueD Out[57]= 0.678565
Chapter 8: Inverse Dynamics
321
Loads The goal of this example is to determine the force required to push the slider around the curved section of the ramp and up the incline, with gravity pulling down on the slider, and friction between the slider and the ramp at both ends. First, gravity is applied without any friction forces. A plot of the force required to push the slider is made from a list of solutions returned by SolveMech.
Here is a gravitational load. In[58]:= SetLoads@ld@1D = Gravity@80, −1<, 9.81DD
The model is run from T = 0.0 to 1.8.
In[59]:= Hstattab = SolveMech@80, 1.8<, 30, Solution → StaticDLP1T
Out[59]= 8T → 0., X2 → 0., Y2 → 0.25, Θ2 → 1.95608 × 10−14 , Λ1 → 0., Λ2 → −4.905, Λ3 → −2.4525<
Here is a plot of the driving force.
In[60]:= ListPlot@8T, Reaction@1, sliderDP1, 1T< ê. stattab, Frame → True, PlotJoined → TrueD
4 3 2 1 0 0
Out[60]=
0.25
0.5
0.75
1
1.25
1.5
1.75
Graphics
Now a friction force is added to the left end of the slider. This is fairly straightforward, as the line of action of the force is constant throughout the motion of the slider. The force is applied to the slider and the line of action is along the surface of the ramp. The magnitude of the force is equal to the coefficient of friction times the normal force at the left end of the slider, which is the Y reaction to constraint 2.
MechanicalSystems
322
Here is the left end friction load. The symbol cf is the coefficient of friction. In[61]:= cf = 0.4;
ld@2D = Force@slider, Line@ramp, 2, 1D, cf Reaction@2, sliderDP1, 2TD;
Now a friction force is added to the right end of the slider. This is rather complicated, as the line of action of the friction force changes as the slider passes from one section of the ramp to another. The friction force is applied to the slider, but the line of action is along the surface of the ramp. On the two flat sections of the ramp, the friction force is applied in the same manner as the force on the left end of the slider. However, the line of action of the force around the curve on the ramp has to be developed directly with vector algebra. Although the line of action changes as the slider moves through the different stages of the ramp, the magnitude of the normal force is always equal to the coefficient of friction times the magnitude of the reaction force of constraint 3, even though constraint 3 is changing from one constraint type to another. TimeSwitch is used to switch between the forces in exactly the same manner as it is used to switch constraints, without the constraint number argument. Since the forcing functions switch at the same times as the constraints, the same switch times can be used.
Here is the right end friction load In[63]:= rightnormal = Magnitude@Reaction@3, sliderDP1TD;
ld@3D = TimeSwitch@ Force@slider, Line@ramp, 2, 1D, cf rightnormalD, 0.50, Force@slider, Axis@Location@ramp, 3D + radius Unit@ramp, 3, slider, 2D, RMatrix.Direction@slider, 2, ramp, 3DD, cf rightnormalD, swtime, Force@slider, Line@ramp, 5, 4D, cf rightnormalDD;
All of the defined loads are added here to the current model. In[65]:= SetLoads@ld@1D, ld@2D, ld@3DD
Chapter 8: Inverse Dynamics
323
SolveMech is called with intermediate times in between the beginning and end times that are explicitly included in the points in time that are solved for. This ensures that a data point is included exactly at the peak of the force plot.
The model is now run through a range of 30 points in time, including the two switch times.
In[66]:= Hstattab = SolveMech@80, 0.5, swtime, 1.8<, 30, Solution → StaticDLP1T
Out[66]= 8T → 0., X2 → 0., Y2 → 0.25, Θ2 → −2.03456 × 10−11 , Λ1 → −3.924, Λ2 → −4.251, Λ3 → −2.7795<
Here is a plot of the driving force.
In[67]:= ListPlot@8T, Reaction@1, sliderDP1, 1T< ê. stattab, Frame → True, PlotJoined → TrueD 14 12 10 8 6 4 0
Out[67]=
0.25
Graphics
0.5
0.75
1
1.25
1.5
1.75
9. Parametric Design Overview This chapter covers the use of MechanicalSystems’ parametric design synthesis functions, SetCouple and SolveCouple. These functions allow the user to specify one or more geometric conditions that are to be satisfied, along with the names of parameters that are to be varied in an attempt to satisfy them. Coupled systems can be used to satisfy several geometric conditions that are specified at different configurations of the model, or conditions that are dependent on velocity, acceleration, or constraint reactions. The SetSensitivity and SolveSensitivity functions find the linearized sensitivity of all of the dependent variables in a model to variations in specified parameters. These functions are used to perform a linearized tolerance analysis on a multibody system.
9.1 Coupled Models The simplest invocation of the SetCouple and SolveCouple functions is to allow a model parameter or parameters to be varied in an attempt to satisfy some geometric condition at one point in time. In this section a planar model of a four-bar mechanism is developed, and the lengths of the links in the four-bar mechanism are adjusted to achieve various desired geometric design goals.
9.1.1 2D Example Mechanism This subsection develops a planar model of a classic four-bar mechanism. The driving input to the model is to specify the rotation of bar 2, the drive bar. Because the drive bar is the shortest link in the model, the driven bar and center bar simply oscillate as the drive bar progresses through each full turn. Driven in this manner the model has no singular configurations.
MechanicalSystems
326
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Off@General::"spell1"D Off@General::"spell"D
Here is a graphic of the four-bar model. 4
3
2
1
0
-1
-2
-1.5
-1
-0.5
0
0.5
1
Bodies Four body objects are defined for the four-bar mechanism model. Each body in the model is simply a twoended bar, so only two local points are defined on each body. Each body is attached to one neighboring body at its local origin and another neighboring body at an offset point on the local x or y axis. Body 4, the center bar, has a third point defined that is used only as a point of reference to measure the motion of the model. The body objects are defined such that the length of each bar is a symbolic parameter that can be changed at a later time.
Chapter 9: Parametric Design
327
Names are defined for each of the body numbers in the model. In[4]:= ground = 1;
drivebar = 2; drivenbar = 3; centerbar = 4;
Here are the four body objects for the four-bar model. In[8]:= Clear@bar2, bar3, bar4D
bd@groundD = Body@ground, PointList → 8 H∗P1∗L80, 0<, H∗P2∗L8−2, 3<
bd@drivebarD = Body@drivebar, PointList → 8 H∗P1∗L80, 0<, H∗P2∗L8bar2, 0<<, InitialGuess → 880, 0<, 0
The body objects are incorporated into the current model with SetBodies. In[13]:= SetBodies@bd@groundD, bd@drivebarD, bd@drivenbarD, bd@centerbarDD
Constraints Five constraints, one of which is a driving constraint with explicit dependence on time, are used to model the four-bar mechanism. A RotationLock1 constraint controls the rotation of the drive bar as a function of T. Four Revolute2 constraints model the revolute joints at each end of the four bars.
MechanicalSystems
328
Here are the five constraint objects for the four-bar model. In[14]:= cs@1D = RotationLock1@1, drivebar, ground, 2 N@πD TD;
cs@2D = Revolute2@2, cs@3D = Revolute2@3, cs@4D = Revolute2@4, cs@5D = Revolute2@5,
Point@drivebar, 1D, Point@ground, 1DD; Point@drivenbar, 1D, Point@ground, 2DD; Point@drivebar, 2D, Point@centerbar, 1DD; Point@drivenbar, 2D, Point@centerbar, 2DD;
The constraint objects are incorporated into the current model with SetConstraints. In[19]:= SetConstraints@Array@cs, 5DD
Runtime Before the model can be run, the symbols bar2, bar3, and bar4 that determine the length of the each bar must be defined. The SetParameters function is used to make the symbols formal parameters so that they are recognized by SetCouple.
The symbolic lengths of each bar are defined. In[20]:= SetParameters@8bar2 → 1, bar3 → 3, bar4 → 3
Now the model is run at T = 0.05. In[21]:= [email protected], Solution → VelocityD
Out[21]= 8T → 0.05, bar2 → 1, bar3 → 3, bar4 → 3, X2 → 0., Y2 → 0., Θ2 → 0.314159,
X3 → −2., Y3 → 3., Θ3 → 0.103128, X4 → 0.951057, Y4 → 0.309017, Θ4 → −0.0110018, X2d → 0., Y2d → 0., Θ2d → 6.28319, X3d → 0., Y3d → 0., Θ3d → 1.99764, X4d → −1.94161, Y4d → 5.97566, Θ4d → −0.441583<
Chapter 9: Parametric Design
329
Here is a plot of the four-bar mechanism with the locus of a point on the center bar. 4
3
2
1
0
-1
-2 -1.5 -1 -0.5 0
0.5
1
9.1.2 Solving for One Parameter SetCouple[symbol, equation]
builds a CoupleSystem object that seeks the value of symbol that satisfies the equation and all of the constraints in the current model. All required initial guesses and the value of time are taken from the current initial guess LastSolve[].
SolveCouple[cpsys]
attempts to solve the CoupleSystem object cpsys and returns a list of rules representing the solution.
The coupled system building and solving functions.
Mech’s SetCouple and SolveCouple functions are now used to adjust the length of the drive bar bar2. In the four-bar’s current configuration, the X coordinate of point 3 on the center bar is 0.898 at T = 0.1. The following example uses a coupled system to find the length of the drive bar that causes the X coordinate of point 3 to be equal to 0.8 at T = 0.1.
MechanicalSystems
330
Here is the current X coordinate of point 3 on the center bar. Location@centerbar, 3DP1T ê. [email protected]
In[22]:= SetGuess@D;
Out[23]= 0.89797
SetCouple basically adds a degree of freedom to the mechanism model by allowing a parameter to become a dependent variable, and also adds an equation to constrain the new degree of freedom. The following command essentially says “adjust the value of bar2 such that the X coordinate of point 3 on the center bar is equal to 0.8 at the current default time T = 0.1.” The current default initial guesses obtained from LastSolve[] are used as the initial guesses for the CoupleSystem, unless otherwise specified. The current value of the parameter bar2 is used for its initial guess.
This builds the CoupleSystem object. In[24]:= cpsys = SetCouple@bar2, Location@centerbar, 3DP1T
0.8D
Out[24]= CoupleSystem@8bar2<, <>D
SetCouple returns a CoupleSystem object that is solved with SolveCouple. The CoupleSystem object contains a new set of constraint equations that include all of the constraints in the current model, plus one. The list of rules returned by SolveCouple is of the same form as the rules returned by SolveMech.
This solves the CoupleSystem object and finds a new value of bar2. In[25]:= SolveCouple@cpsysD
Out[25]= 8T → 0.1, bar2 → 0.52057, bar3 → 3, bar4 → 3, X2 → 0., Y2 → 0., Θ2 → 0.628319,
X3 → −2., Y3 → 3., Θ3 → 0.0839882, X4 → 0.42115, Y4 → 0.305983, Θ4 → −0.190577<
The new value of the parameters bar2 is added to the current parameters list. In[26]:= SetParameters@%P82, 3, 4
Out[26]= 8bar2 → 0.52057, bar3 → 3, bar4 → 3<
Chapter 9: Parametric Design
331
This shows that the desired condition is satisfied.
In[27]:= Location@centerbar, 3DP1T ê. [email protected] Out[27]= 0.8
InitialCondition
is an option for SolveCouple that sets a new value of time at which the CoupleSystem is solved. InitialCondi tion → (Time → t) specifies the new value of time t. InitialCondition → Automatic is the default setting that leaves the values of time t unchanged.
SetParameters
is an option for SolveCouple that specifies whether the values in the current parameters list should be updated with the new values found by SolveCouple. SetParame ters → False is the default setting that leaves the parameters unchanged. The following three options have the same usage as they have with SolveMech, with the same default settings.
DampingFactor
is an option for SolveCouple that gives the damping factor for Newton’s method. The default setting is Damping Factor → 1.
MaxIterations
is an option for SolveCouple that gives the maximum number of iterations for Newton’s method. The default setting is MaxIterations → 15.
ZeroTest
is an option for SolveCouple that gives a convergence test function. The default setting is ZeroTest → (Abs[#]<10^(-9)&).
Options for SolveCouple.
Without building a new CoupleSystem object, cpsys can be re-solved at a new value of time by using the InitialCondition option. Note that the InitialCondition option expects a setting of the form Time → t, not T → t.
MechanicalSystems
332
The CoupleSystem is solved again with a new value of time. In[28]:= SolveCouple@cpsys, InitialCondition → Time → 0.11, SetParameters → TrueD
Out[28]= 8T → 0.11, bar2 → 0.559534, bar3 → 3, bar4 → 3, X2 → 0., Y2 → 0., Θ2 → 0.69115,
X3 → −2., Y3 → 3., Θ3 → 0.101908, X4 → 0.431129, Y4 → 0.356661, Θ4 → −0.185498<
The contents of the current parameters list are updated. In[29]:= Parameters@D
Out[29]= 8bar2 → 0.559534, bar3 → 3, bar4 → 3<
9.1.3 Solving for Multiple Parameters SetCouple[{sym1, …, symn}, {eq1, …, eqn}, options]
builds a CoupleSystem object that seeks the values of n symi that satisfy n eqi.
Building coupled systems with multiple parameters.
Multiple parameter values are solved for by supplying an equal number of geometric conditions to be satisfied. A coupled system is used here to find the values of bar2 and bar3 that simultaneously cause the X coordinate of point 3 on the center bar to be 0.8 and the distance from the global origin to point 2 on the center bar to be 3.5, both at T = 0.1.
This finds the X coordinate of point 3 and the distance from the origin to point 2 at T = 0.1.
In[30]:= 8Location@centerbar, 3DP1T,
Distance@Point@ground, 1D, Point@centerbar, 2DD< ê. [email protected]
Out[30]= 80.808768, 3.42614<
This builds the CoupleSystem object.
In[31]:= cpsys = SetCouple@8bar2, bar3<, 8
Location@centerbar, 3DP1T 0.8, Distance@Point@ground, 1D, Point@centerbar, 2DD Out[31]= CoupleSystem@8bar2, bar3<, <>D
3.5
Chapter 9: Parametric Design
333
This solves the CoupleSystem object and finds new values for bar2 and bar3. In[32]:= SolveCouple@cpsys, SetParameters → TrueDP82, 3, 4
This shows that the desired conditions have been satisfied.
In[33]:= 8First@Location@centerbar, 3DD,
Distance@Point@ground, 1D, Point@centerbar, 2DD< ê. [email protected]
Out[33]= 80.8, 3.5<
In all the preceding examples, the value of time T at which the coupled model has been solved has been taken from the default initial guess list. The Time option is used to explicitly set the value of time in the CoupleSystem object, or to specify that time is a dependent variable.
Time
is an option for SetCouple that is used to specify the value of time at which the CoupleSystem object is to be solved or to cause time to be treated as an unknown.
Time → t
is used to set the value of time T = t at which the Couple System object is solved.
Time → None
is used to set time to the current value of time from the default initial guesses, LastSolve[], if the model has any time dependency.
Time → Free
is used to omit the time specification so that time becomes a dependent variable to be solved for. If Time → Free is specified, SetCouple requires that one extra equation be given to constrain the resulting extra degree of freedom.
An option for SetCouple.
MechanicalSystems
334
Instead of fixing time at 0.1, time can be a dependent variable to be solved for. The following example seeks the values of bar2 and T that satisfy the same pair of conditions that were used in the previous example.
The parameter bar3 is reset to its original value before building the new CoupleSystem. In[34]:= SetParameters@8bar3 → 3
cpsys = SetCouple@8bar2<, 8 Location@centerbar, 3DP1T 0.8, Distance@Point@ground, 1D, Point@centerbar, 2DD
3.5<, Time → FreeD
Out[35]= CoupleSystem@8bar2<, <>D
Here is the solution for T and bar2.
In[36]:= Hsol = SolveCouple@cpsysDLP81, 2, 3, 4
Out[36]= 8T → 0.11848, bar2 → 0.602986, bar3 → 3, bar4 → 3<
The desired conditions are satisfied.
In[37]:= 8Location@centerbar, 3DP1T, Distance@Point@ground, 1D, Point@centerbar, 2DD< ê. sol Out[37]= 80.8, 3.5<
9.2 Multiple Configuration Couples The SetCouple and SolveCouple functions can be used to find the values of several parameters that simultaneously satisfy several geometric conditions at different configurations of the model, at different points in time.
Chapter 9: Parametric Design
335
9.2.1 Solving for Two Parameters SetCouple[{sym1, …, symn}, {eqs1, options1}, {eqs2, options2}, …, options]
builds a CoupleSystem object that seeks the values of n symi that satisfy the eqsi at several different points in time, or different configurations of the mechanism. Each eqsi must be an equation or list of equations, and the total number of equations must be equal to n plus the number of occurrences of Time → Free in the optionsi.
Compiled
is an option for SetCouple that causes the constraint equations to be compiled. The default setting is Compiled → False.
InitialGuess
is an option for SetCouple that is used to specify initial guesses for each different mechanism configuration. The default setting, InitialGuess → Automatic, takes all initial guesses from the current initial guess list as returned by LastSolve[].
Time
is an option for SetCouple that is used to specify the value of time at each different configuration. The default setting, Time → None, takes the value of time from the current default initial guess list.
Building coupled systems across multiple configurations.
The InitialGuess and Time options are used somewhat differently than standard Mathematica option usage because one specification for time and one set of initial guesses must be given for each separate mechanism configuration. The Time option must be specified for a multiple configuration CoupleSystem because the default setting sets the value of time to be the same for all configurations, making all configurations identical. Since the Compiled option applies to the entire CoupleSystem, it can appear in any part of the SetCouple command. The following example uses the four-bar model that was developed in Section 9.1. A coupled system is used to adjust the lengths of both the drive and driven bars so as to meet two geometric conditions that are satisfied at two different points in time. The X coordinate of point 3 on the center bar is set to 0.8 at T = 0.1, and the distance from the global origin to point 2 on the center bar is set to 3.8 at T = 0.3.
MechanicalSystems
336
Because the coupled system is simultaneously solved in two different mechanism configurations, the same initial guess for both configurations may not be acceptable. Therefore, the InitialGuess option is used to explicitly specify initial guesses for each configuration.
Here are two initial guesses for the two configurations. In[38]:= SetGuess@D;
guess1 = [email protected]; guess2 = [email protected];
Here are parts of the two conditions at the two initial configurations.
In[41]:= 8Location@centerbar, 3DP1T ê. guess1,
Distance@Point@ground, 1D, Point@centerbar, 2DD ê. guess2<
Out[41]= 80.83464, 3.53917<
This builds the CoupleSystem object. In[42]:= cpsys = SetCouple@8bar2, bar3<,
8Location@centerbar, 3DP1T 0.8, Time → 0.1, InitialGuess → guess1<, 8Distance@Point@ground, 1D, Point@centerbar, 2DD 3.8, Time → 0.3, InitialGuess → guess2
A CoupleSystem object that spans multiple configurations has a unique solution at each configuration. Thus, SolveCouple returns a nested list of solution rules with each list corresponding to one configuration of the mechanism.
This solves the CoupleSystem object and finds new values for bar2 and bar3. In[43]:= sol = SolveCouple@cpsysD
Out[43]= 88T → 0.1, bar2 → 0.965874, bar3 → 2.86606, bar4 → 3,
X2 → −1.2326 × 10−32 , Y2 → 0., Θ2 → 0.628319, X3 → −2., Y3 → 3., Θ3 → 0.199359, X4 → 0.781408, Y4 → 0.567726, Θ4 → −0.00929608<, 8T → 0.3, bar2 → 0.965874, bar3 → 2.86606, bar4 → 3, X2 → 0., Y2 → 0., Θ2 → 1.88496, X3 → −2., Y3 → 3., Θ3 → 0.254053, X4 → −0.298471, Y4 → 0.9186, Θ4 → −0.365603<<
Chapter 9: Parametric Design
337
This shows that the desired condition is satisfied.
In[44]:= 8Location@centerbar, 3DP1T ê. solP1T,
Distance@Point@ground, 1D, Point@centerbar, 2DD ê. solP2T<
Out[44]= 80.8, 3.8<
9.2.2 Solving for Multiple Parameters It is possible to specify any number of geometric conditions to be satisfied at any number of different mechanism configurations, however, it is certainly not possible to satisfy any arbitrary set of conditions. A Couple System object built by SetCouple may have no solution, or it may have stiff singularities at points very close to a valid solution, making it difficult to converge the model. The following example demonstrates a useful technique for slowly coaxing a model towards a desired solution with SolveCouple. In the following example, a coupled system is used to find the values of bar2, bar3, bar4, and T that satisfy four different geometric conditions at two different points in time. The X and Y coordinates of point 3 on the center bar are specified at T = 0.1, and the X and Y coordinates of point 3 on the center bar are specified at an arbitrary time T > 0.1, effectively specifying that point 3 on the center bar must pass through a given point in the global reference frame.
Here is the current location of point 3 at T = 0.1 and T = 0.3. In[45]:= SetParameters@8bar2 → 1, bar3 → 3, bar4 → 3
Location@centerbar, 3D ê. Hguess1 = [email protected] Location@centerbar, 3D ê. Hguess2 = [email protected]
Out[46]= 80.89797, 2.58581<
Out[47]= 80.510403, 2.77549<
First, a CoupleSystem object is built that has very unambitious goals. This system simply tries to satisfy a set of conditions that are already approximately satisfied. Then, the coordinate goals k1, k2, k3, and k4 are changed, slowly pulling the solution of the model away from its original configuration.
MechanicalSystems
338
The new parameters, k1 to k4, are added to the parameters list. In[48]:= SetParameters@8k1 → 0.90, k2 → 2.59, k3 → 0.51, k4 → 2.78
cpsys = SetCouple@8bar2, bar3, bar4<, 88Location@centerbar, 3DP1T k1, Location@centerbar, 3DP2T k2<, Time → 0.1, InitialGuess → guess1<, 88Location@centerbar, 3DP1T k3, Location@centerbar, 3DP2T k4<, Time → Free, InitialGuess → guess2
Note that the parameters bar2, bar3, and bar4 are approximately equal to their original values.
In[50]:= SolveCouple@cpsysDP81, 2<, 81, 2, 3, 4
Out[50]= 88T → 0.1, bar2 → 1.00687, bar3 → 3.00046, bar4 → 2.99732<,
8T → 0.300268, bar2 → 1.00687, bar3 → 3.00046, bar4 → 2.99732<<
When SolveCouple is called with a symbol that evaluates to a CoupleSystem object as its first argument, SolveCouple updates the initial guesses contained within the CoupleSystem object to the new values found to be the solution. Therefore, independent parameters can be slightly tweaked between successive runs of SolveCouple, with each run nudging the model slightly closer to the desired solution.
The parameters are repeatedly changed and the model is re-solved. In[51]:= SetParameters@8k1 → 0.8
SolveCouple@cpsysDP81, 2<, 81, 2, 3, 4
Out[52]= 88T → 0.1, bar2 → 1.00383, bar3 → 2.80732, bar4 → 2.66193<,
8T → 0.299737, bar2 → 1.00383, bar3 → 2.80732, bar4 → 2.66193<<
In[53]:= SetParameters@8k2 → 2.5
SolveCouple@cpsysDP81, 2<, 81, 2, 3, 4
Out[54]= 88T → 0.1, bar2 → 0.855598, bar3 → 2.91249, bar4 → 3.06524<,
8T → 0.256046, bar2 → 0.855598, bar3 → 2.91249, bar4 → 3.06524<<
In[55]:= SetParameters@8k3 → 0.4
SolveCouple@cpsysDP81, 2<, 81, 2, 3, 4
Out[56]= 88T → 0.1, bar2 → 0.855598, bar3 → 3.05297, bar4 → 3.51109<,
8T → 0.271639, bar2 → 0.855598, bar3 → 3.05297, bar4 → 3.51109<<
Chapter 9: Parametric Design
339
In[57]:= SetParameters@8k4 → 2.2
SolveCouple@cpsys, SetParameters → TrueDP81, 2<, 81, 2, 3, 4
Out[58]= 88T → 0.1, bar2 → 0.855598, bar3 → 2.8704, bar4 → 2.86849<,
8T → 0.396612, bar2 → 0.855598, bar3 → 2.8704, bar4 → 2.86849<<
Here is the four-bar mechanism at T = 0.1 and T = 0.396, with the locus of point 3 on the center bar. 4
3
2
1
0
-1
-2 -1.5 -1 -0.5 0
0.5
1
The k1–k4 parameters are removed from the parameters list. In[59]:= ClearParameters@8k1, k2, k3, k4
9.3 Velocity and Acceleration Couples Coupled systems are not limited to geometric conditions that involve only mechanism body location and orientation. Velocity and acceleration terms may be included in the conditions to be satisfied. However, the parameters that are varied in attempting to satisfy the conditions are assumed to be constant. Mech parameters never have nonzero derivatives.
MechanicalSystems
340
9.3.1 Solving for Two Parameters To demonstrate the use of coupled systems to satisfy higher-order conditions, the four-bar model developed in Section 9.1 is used again. In the following example, the lengths of the drive bar and the driven bar are adjusted to satisfy two geometric conditions that are specified in two different mechanism configurations. One of the conditions is a first-order expression, specifying a component of the velocity of a point. In the following example, bar2 and bar3 are adjusted so that the X coordinate of point 3 on the center bar is 0.4 at T = 0.3, and the Y velocity of point 3 on the center bar is 6.0 at T = 0.1. Initial guesses are specified for each configuration, and the initial guess for configuration 1, which contains the velocity condition, includes velocity terms.
Here are two initial guesses for the two configurations. In[60]:= SetParameters@8bar2 → 1, bar3 → 2, bar4 → 3
SetGuess@D; guess1 = [email protected], Solution → VelocityD; guess2 = [email protected];
This builds the CoupleSystem object. In[64]:= cpsys = SetCouple@8bar2, bar3<,
8Velocity@centerbar, 3DP2T 6.0, Time → .1, InitialGuess → guess1<, 8Location@centerbar, 3DP1T 0.4, Time → .3, InitialGuess → guess2
This solves the CoupleSystem object. In[65]:= SolveCouple@cpsys, SetParameters → TrueD
Out[65]= 88T → 0.1, bar2 → 1.1669, bar3 → 2.91756, bar4 → 3, X2 → −4.23516 × 10−21 ,
Y2 → 0., Θ2 → 0.628319, X3 → −2., Y3 → 3., Θ3 → 0.236627, X4 → 0.944042, Y4 → 0.685887, Θ4 → 0.0359339, X2d → 0., Y2d → 0., Θ2d → 6.28319, X3d → 0., Y3d → 0., Θ3d → 2.12752, X4d → −4.30955, Y4d → 5.93159, Θ4d → −0.952093<, 8T → 0.3, bar2 → 1.1669, bar3 → 2.91756, bar4 → 3, X2 → 0., Y2 → 0., Θ2 → 1.88496, X3 → −2., Y3 → 3., Θ3 → 0.307969, X4 → −0.360592, Y4 → 1.10979, Θ4 → −0.390116<<
Chapter 9: Parametric Design
341
The nested list of rules returned by SolveCouple has one complete solution for each of the two mechanism configurations. Note that SolveCouple automatically determined that a velocity solution was needed for the first configuration by the presence of first-order terms in the geometric condition.
This shows that the desired goal has been achieved.
In[66]:= 8Velocity@centerbar, 3DP2T ê. [email protected], Solution → VelocityD,
Location@centerbar, 3DP1T ê. [email protected]<
Out[66]= 86., 0.4<
9.3.2 Solving for Multiple Parameters This last example of the use of coupled systems with velocity dependence uses two geometric conditions that are satisfied in one configuration, and one condition that is satisfied in another configuration. One of the conditions is an expression involving velocity. bar2, bar3, and bar4 are adjusted so that the X coordinate of point 3 on the center bar is 0.4 at T = 0.3, the Y velocity of point 3 is 5.5, at T = 0.1, and the Y coordinate of point 2 on the center bar is 3.7, also at T = 0.1.
Here are the current values of the coordinates that are to be specified.
In[67]:= 8Velocity@centerbar, 3DP2T ê. guess1,
Location@centerbar, 2DP2T ê. guess1, Location@centerbar, 3DP1T ê. guess2<
Out[67]= 85.54844, 3.46101, −0.263121<
This builds the CoupleSystem object. In[68]:= cpsys = SetCouple@8bar2, bar3, bar4<,
88Velocity@centerbar, 3DP2T 5.5, Location@centerbar, 2DP2T 3.7<, Time → .1, InitialGuess → guess1<, 8Location@centerbar, 3DP1T 0.4, Time → .3, InitialGuess → guess2
MechanicalSystems
342
This solves the CoupleSystem object.
In[69]:= SolveCouple@cpsys, SetParameters → TrueDP1, 82, 3, 4
This shows that the conditions are now satisfied.
In[70]:= 8Velocity@centerbar, 3DP2T ê. [email protected], Solution → VelocityD,
Location@centerbar, 2DP2T ê. LastSolve@D, Location@centerbar, 3DP1T ê. [email protected]<
Out[70]= 85.5, 3.7, 0.4<
9.4 Load-Dependent Couples Coupled systems may be built with mathematical conditions that depend on reaction forces in the mechanism, instead of geometric conditions that depend on body locations and velocities. Such expressions contain the Lagrange multiplier terms (Λ1, Λ2, …) that are used to resolve static and dynamic reaction forces in a model. The four-bar mechanism is used to demonstrate this, after adding applied forces and gravity to the model so that the joint reactions are nonzero.
9.4.1 Loads on the Four-Bar Model The four-bar mechanism defined in Section 9.1 now has a constant moment applied to the driven bar and gravitational force applied to all bodies. This sets nonzero masses for each body. In[71]:= SetBodies@
Body@drivebar, Mass → 0.05D, Body@drivenbar, Mass → 0.10, Centroid → 80.50, 0
Chapter 9: Parametric Design
343
9.4.2 Solving for a Parameter A coupled system is used to find the length of the drive bar that causes the reaction moment at the driving constraint to be equal to 0.5. The driving constraint, number 1, is a RotationLock1 constraint constraining the rotation of the drive bar. Since this constraint only controls the rotation of the drive bar it can support no forces, only a moment. Thus, the reaction force at the constraint is exactly zero.
Here is the reaction force and moment that the driving constraint applies to the drive arm. In[73]:= SetParameters@8bar2 → 1, bar3 → 3, bar4 → 3
Reaction@1, drivebarD ê. [email protected], Solution → StaticD
Out[74]= 880, 0<, 0.652542<
At T = 0.2, the driving constraint must apply a 0.65 unit moment to the drive bar to counteract the gravitational forces and the moment applied to the driven bar. A CoupleSystem object is built that seeks the value of bar2 that results in a reaction moment of 0.5 units at T = 0.2.
This builds the CoupleSystem object. In[75]:= cpsys = SetCouple@bar2, Reaction@1, drivebarDP2T
0.5D
Out[75]= CoupleSystem@8bar2<, <>D
This solves the CoupleSystem object.
In[76]:= bar2 ê. SolveCouple@cpsysD Out[76]= 0.893655
As with the examples given in Section 9.2, coupled systems can be built that couple multiple mechanism configurations. The conditions to be satisfied in such a system can be a mix of geometric conditions and algebraic conditions based on reaction forces.
MechanicalSystems
344
9.4.3 Dynamic Solutions Solution
is an option for SetCouple that specifies the solution level used in each configuration of the CoupleSystem object. The default setting Automatic causes SetCouple to pick a solution level that is sufficient to solve for the terms appearing in the equations given to SetCouple. Valid settings are Automatic, Location, Velocity, Acceleration, Static, Kinematic, and Dynamic.
An option for SetCouple.
In all of the preceding examples, SetCouple has been called with the default setting for the Solution option, Solution → Automatic. SetCouple automatically upgrades the Solution setting to Velocity when first-order terms are encountered in the equations, or to Acceleration when second-order terms are encountered. SetCouple chooses the Static setting if Lagrange multipliers are encountered due to reaction forces in the equations. However, SetCouple does not automatically choose the Kinematic or Dynamic settings for Solution unless first- or second-order terms and Lagrange multiplier terms appear in the equations, even though a dynamic solution (that includes inertial forces) may be desired. In the following example a CoupleSystem object is built with exactly the same inputs as in the previous example, but the Solution → Dynamic option causes inertial forces to be included, resulting in a different solution.
Here is the reaction that the driving constraint applies to the drive arm, including dynamic forces. In[77]:= SetParameters@8bar2 → 1, bar3 → 3, bar4 → 3
Reaction@1, drivebarD ê. [email protected], Solution → DynamicD
Out[78]= 880, 0<, 0.483505<
Chapter 9: Parametric Design
345
With dynamic forces included, the reaction moment at the drive bar is reduced to only 0.48 units at T = 0.2. A new CoupleSystem object is built that seeks the value of bar2 that results in a reaction moment of 0.5 units at T = 0.2, the same reaction moment that was sought in the previous example.
This builds the CoupleSystem object with a dynamic formulation. In[79]:= cpsys = SetCouple@bar2, Reaction@1, drivebarDP2T
0.5, Solution → DynamicD
Out[79]= CoupleSystem@8bar2<, <>D
Note that the resulting length of the drive bar is quite different than was calculated using only static forces.
This solves the CoupleSystem object.
In[80]:= bar2 ê. SolveCouple@cpsysD Out[80]= 1.01542
9.4.4 Dependent Time FindTime[equation]
seeks a solution to the current model that satisfies equation with time T treated as a dependent variable. equation must have the head Equal.
A combined form of SetCouple and SolveCouple.
MechanicalSystems
346
Solution
is an option for FindTime that specifies what level of solution is needed. Solution → Automatic is the default setting that chooses the highest solution level that could have any affect on the result.
DampingFactor
is an option for FindTime that gives the damping factor for Newton’s method. The default setting is DampingFactor → 1.
MaxIterations
is an option for FindTime that gives the maximum number of iterations for Newton’s method. The default setting is MaxIterations → 15.
ZeroTest
is an option for FindTime that gives a convergence test function. The default setting is ZeroTest → (Abs[#]<10^(-9)&).
FindTime options.
FindTime is essentially a special combined form of the SetCouple and SolveCouple functions that accepts only one condition to be satisfied, and considers time to be the only new dependent variable.
This seeks the time at which the reaction on the drive bar is equal to 8. In[81]:= FindTime@Reaction@1, drivebarDP2T
1D
Out[81]= 8T → 0.189728, bar2 → 1, bar3 → 3, bar4 → 3, X2 → 0., Y2 → 0.,
Θ2 → 1.1921, X3 → −2., Y3 → 3., Θ3 → 0.30046, X4 → 0.369712, Y4 → 0.929146, Θ4 → −0.166059, Λ1 → −1., Λ2 → −0.653042, Λ3 → −4.83651, Λ4 → 0.653042, Λ5 → 2.87451, Λ6 → 0.653042, Λ7 → 4.34601, Λ8 → −0.653042, Λ9 → −3.85551<
FindTime automatically pulls its initial guesses from the current default initial guess list LastSolve[] and it updates the initial guess list with the new solution that it finds.
This shows that the specified condition has been met.
In[82]:= Reaction@1, drivebarD ê. LastSolve@D Out[82]= 880, 0<, 1.<
Chapter 9: Parametric Design
347
This clears the parameters list. In[83]:= ClearParameters@AllD;
9.5 Sensitivity MechanicalSystems’ sensitivity analysis functions are used to perform linearized tolerance analysis on multibody mechanisms. Similar to the SetCouple and SolveCouple functions discussed in the previous sections, SetSensitivity and SolveSensitivity are used as a pair to build and solve Sensitivity System objects. A planar example mechanism is developed in this section that is used to demonstrate the use of these functions.
9.5.1 Example Mechanism The quick-return mechanism model that was developed in Section 3.1 is used here to demonstrate the use of sensitivity systems. The model is redefined as follows in abbreviated form.
Here is the entire quick-return model. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
ground = 1; crank = 2; drivearm = 3; slider = 4; Clear@crankarm, drivex, driveyD SetConstraints@ Revolute2@1, Point@ground, 80, 5
MechanicalSystems
348
Note that three parameters were added to the model that are used in the following sensitivity analysis: crankarm, which is the local x coordinate of the crankpin on the crank, drivex and drivey, which are the X and Y coordinates of the attachment point of the drive arm to the ground, respectively.
Here is a graphic of the quick-return mechanism.
9.5.2 Sensitivity to Parameter Variations The quick-return model contains three undefined parameters: crankarm, drivex, and drivey. We wish to find the sensitivity of the location of each body in the mechanism to small changes in these parameters, about some operating point. The sensitivities are not constant, they change as the mechanism moves through a complete cycle. Thus, the maximum sensitivity at any point in a cycle is of interest.
The values of the parameters are set and the body locations are found at the initial operating point. In[9]:= SetParameters@8crankarm → 3, drivex → 0, drivey → 0
SolveMech@0D
Out[10]= 8T → 0, crankarm → 3, drivex → 0, drivey → 0,
X2 → −1.87648 × 10−35 , Y2 → 5., Θ2 → −1.25283 × 10−22 , X3 → −4.1978 × 10−25 , Y3 → 0., Θ3 → −0.54042, X4 → 9.07905, Y4 → 10., Θ4 → 0.<
Chapter 9: Parametric Design
SetSensitivity[symbol]
349
builds the equations necessary to find the sensitivity of the current mechanism to changes in the value of symbol. Set Sensitivity returns a SensitivitySystem object.
SetSensitivity[{symbols, …}] SolveSensitivity[sensys]
builds a SensitivitySystem object for several symbols. solves the SensitivitySystem object sensys and returns a list of rules representing the sensitivities to variations in symbol as velocities.
InitialCondition
is an option for SetSensitivity and SolveSensitiv ity that specifies the operating point about which the sensitivities are calculated. If InitialCondition is unspecified, the operating point is taken from the current initial guess list, LastSolve[]. The default setting is Automatic.
The sensitivity functions.
First, the sensitivity to variations in the crankarm parameter are found.
This builds the SensitivitySystem object. In[11]:= sensys = SetSensitivity@crankarmD Out[11]= SensitivitySystem@8crankarm<, <>D
This solves the SensitivitySystem object. In[12]:= sol = SolveSensitivity@sensysD
Out[12]= 8T → 0, crankarm → 3, drivex → 0, drivey → 0, X2 → −1.87648 × 10−35 ,
Y2 → 5., Θ2 → −1.25283 × 10−22 , X3 → −4.1978 × 10−25 , Y3 → 0., Θ3 → −0.54042, X4 → 9.07905, Y4 → 10., Θ4 → 0., X2d → 0., Y2d → 0., Θ2d → 6.16791 × 10−17 , X3d → −9.98271 × 10−17 , Y3d → 0., Θ3d → −0.147059, X4d → 0.785522, Y4d → 0., Θ4d → 0.<
The solution returned by SolveSensitivity is identical in form to the solution returned by Solve Mech[time, Solution → Velocity]. The difference is that the velocity terms X2d, Θ3d, and so on, do not represent dX2/dT and dΘ3/dT; they represent dX2/dcrankarm and dΘ3/dcrankarm. Because the results
MechanicalSystems
350
from SolveSensitivity are returned in this form, it is possible to use any of the MechanicalSystems’ output functions, differentiated once, to find the sensitivity of more complicated quantities to changes in the parameter.
Here is the sensitivity of the distance from the crank center to the slider origin to changes in crankarm. In[13]:= Dt@Magnitude@crank, 0, slider, 0D, TD
% ê. sol
Out[13]=
2 H−X2 + X4L H−X2d + X4dL + 2 H−Y2 + Y4L H−Y2d + Y4dL è!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 2 H−X2 + X4L2 + H−Y2 + Y4L2
Out[14]= 0.688078
9.5.3 Multiple Parameters If multiple symbols are passed to SetSensitivity, SolveSensitivity returns a nested list of solutions, one for each symbol.
Here a SensitivitySystem object is built and solved with three parameters. In[15]:= sensys = SetSensitivity@8crankarm, drivex, drivey
sol = SolveSensitivity@sensysD;
Here is the sensitivity of the slider location to variations in each of the parameters.
In[17]:= Dt@Location@slider, 0DP1T, TD ê. sol Out[17]= 80.785522, 0.214478, 0.984412<
To plot the sensitivity of the slider location to changes in these three parameters, a set of solutions at several operating points is generated and used as initial conditions for SolveSensitivity.
This resets the initial guesses and seeks 25 solution points through a full turn of the crank. In[18]:= SetGuess@8Y2 → 5, Θ2 → 0, Θ3 → −0.5, X4 → 9, Y4 → 10
postab = SolveMech@80, 1<, 25D;
Chapter 9: Parametric Design
351
Now SolveSensitivity is applied with each of the position solutions serving as an initial condition.
In[20]:= senstab = Transpose@HSolveSensitivity@sensys, InitialCondition → #1D &L ê@ postabD;
Here is a plot of the sensitivities.
In[21]:= Show@Graphics@HLine@8T, X4d< ê. #1D &L ê@ senstabD,
Frame → True, AspectRatio → 1 ê GoldenRatioD 2 1 0 -1 -2 -3 0
Out[21]=
0.2
0.4
0.6
0.8
1
Graphics
Note that the sensitivities are rather large near 3/4 turn of the crank. This is to be expected with a quick-return mechanism because of the high leverage ratio between the crank and the slider during the return stoke. The largest negative sensitivity is the sensitivity to the X coordinate of the drive arm rotational axis drivex, when the crank is at 3/4 turn.
Here is the quick-return mechanism at 3/4 turn of the crank.
10. Underconstrained Systems Overview This chapter covers MechanicalSystems’ SetFree and SolveFree functions, which are used to synthesize the dynamic motion of underconstrained mechanical systems. SolveFree uses an adaptive multistep integration algorithm to integrate the equations of motion built by SetFree, and returns the dynamic motion profile of the model in the form of standard Mathematica interpolating functions. SetFree and SolveFree are also used to find the equilibrium configuration of underconstrained models that are subject to conservative static loading, or the equilibrium velocity of underconstrained models subject to velocity-dependent loading. The SetPath and SolvePath functions are used to find the motion trajectories of models with one or more nonholonomic constraints. All Mech models must first be defined as fully constrained systems with SetCon straints before they can be modified with SetFree or SetPath.
10.1 Equilibrium Configuration This section describes the use of the SetFree and SolveFree functions to find the equilibrium configuration of an underconstrained mechanism subject to static forces. A planar model of a pendulum sliding on a massless rope is used to demonstrate the use of SetFree and SolveFree.
10.1.1 Example Mechanism The pendulum-on-a-rope model in the following example consists of two planar bodies, a slider that moves without friction along an infinitely flexible, inextensible, massless rope, and a pendulum that hangs below the slider and is attached to the ground by a spring. Before an equilibrium analysis can be done, the model must have a full set of kinematic constraints so that it can be assembled and each body can be moved to a reasonable position to use as an initial guess for the equilibrium analysis. Some of these kinematic constraints are then dropped to make the model underconstrained.
MechanicalSystems
354
This loads the Modeler2D package and turns off the general spelling warnings. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Off@General::"spell1"D Off@General::"spell"D
Bodies Three body objects are defined for the pendulum model. Note that the zeroth point, which is defined to be {0,0} by default, is used in each body. • The ground (body 1) requires three point definitions. P0 is the origin of the ground body and the attachment point of the left end of the rope. P1 is the attachment point of the right end of the rope. P2 is the attachment point of a spring that is used to pull the pendulum to one side. • The slider (body 2) requires three point definitions. P0 is the origin of the slider and the point where the pendulum is attached. P1 is the point where the rope exits the left side of the slider. P2 is the point where the rope exits the right side of the slider. • The pendulum (body 3) requires two point definitions. P0 is the origin of the pendulum and its center of mass. P1 is the point where the pendulum is attached to the slider. Names are defined for each of the body numbers. In[4]:= ground = 1;
slider = 2; pendulum = 3;
Chapter 10: Underconstrained Systems
355
Here are the three body objects, including inertia properties. Body@ground, PointList → 8 H∗P1∗L84, 0<, H∗P2∗L85, −3<
In[7]:= SetBodies@
Constraints Seven constraints are used to model the pendulum-on-a-rope model. • A RelativeDistance1 constraint is used to model the left side of the rope. Since only the total length of the rope is known, the distance from the left end of the slider to the attachment point of the rope on the ground is simply constrained to be the unknown s. The symbol s is then added to the model as a dependent variable with the Constraint function. • Another RelativeDistance1 constraint models the right side of the rope. The length of the right side of the rope is simply the total length of the rope minus the length of the slider and the length of the left side, 5 – 1 – s. • A Constraint function is used only to introduce the variable s, and its initial guess, into the model as a dependent variable. The Constraint has no constraint equation, so it constrains zero degrees of freedom, but it does add one degree of freedom to the model by introducing s. • A Revolute2 constraint attaches the pendulum to the slider. • A RelativeX1 constraint initially controls the X coordinate of the slider. This constraint is dropped for the equilibrium analysis.
MechanicalSystems
356
• A RotationLock1 constraint initially controls the rotation of the slider. This constraint is dropped for the equilibrium analysis. • A RotationLock1 constraint initially controls the rotation of the pendulum. This constraint is dropped for the equilibrium analysis. Here are the seven constraint objects for the pendulum-on-a-rope model. In[8]:= SetConstraints@
RelativeDistance1@1, Point@ground, 0D, Point@slider, 1D, sD, RelativeDistance1@2, Point@ground, 1D, Point@slider, 2D, 4 − sD, Constraint@3, 8<, 8s, 2.5
Runtime Because there is no occurrence of time T in the model, the model can be run with the SolveMech command with no time argument. Since there are no other symbolic parameters, the model can only achieve one configuration, the one specified by the constraints.
Now the model is run with SolveMech. In[9]:= SolveMech@D
Out[9]= 8X2 → 2., Y2 → −1.62288, Θ2 → 0., X3 → 2., Y3 → −3.42288, Θ3 → 0., s → 2.<
Chapter 10: Underconstrained Systems
357
Here is the pendulum-on-a-rope model in its initial configuration. 0 -0.5 -1 -1.5 -2
G
-2.5
F
-3 -3.5 -4 1
2
3
4
5
Forces A model must have some nonzero loads applied to it in order to have a unique equilibrium position. The pendulum-on-a-rope model has three forces applied to it: a spring force applied to the pendulum, and gravity applied to the pendulum and the slider.
Here are the loads applied to the pendulum and slider. In[10]:= SetLoads@
Force@pendulum, Line@pendulum, 0, ground, 2D, 10 HMagnitude@pendulum, 0, ground, 2D − 1LD, Gravity@80, −1<, 9.81DD
Here is the reaction to constraint 7 that prevents the pendulum from rotating. The constraint applies a clockwise moment to the pendulum to constrain it against the force of the spring.
In[11]:= Reaction@7, pendulumD ê. SolveMech@Solution → StaticD Out[11]= 880, 0<, −36.1762<
MechanicalSystems
358
10.1.2 Finding Equilibrium To find the equilibrium configuration of a mechanism, a FreeSystem object is built that contains a new set of equations of motion with one or more constraints removed from the model.
SetFree[dropcon]
builds the mathematical equations required to find equilibrium position of the current model, and returns them in a FreeSystem object. The dropcon argument is used to specify the constraint number(s) to be dropped to make the model underconstrained.
SolveFree[freesys]
solves a FreeSystem object and returns a list of rules representing the location and generalized forces at the equilibrium position.
Finding equilibrium configuration.
The pendulum-on-a-rope model has three constraints that are present only to complete the kinematic model, constraints 5, 6, and 7. Each of these constraints is dropped, one at a time, and the equilibrium position is found with each new degree of freedom. The first constraint to be dropped is constraint 7, which locks the rotation of the pendulum relative to the slider. This allows the pendulum to rotate, but the slider stays locked at the center of the rope.
This drops constraint 7. In[12]:= fsys = SetFree@7D Out[12]= FreeSystem@Static, <>D
This solves the FreeSystem object. In[13]:= sol = SolveFree@fsysD
Out[13]= 8T → 0, X2 → 2., Y2 → −1.62288, Θ2 → −8.26764 × 10−22 , X3 → 2.90923,
Y3 → −3.17636, Θ3 → 0.529531, s → 2., Λ1 → 5.38731, Λ2 → 5.38731, Λ3 → −10.9431, Λ4 → 18.697, Λ5 → 10.9431, Λ6 → 1.39313 × 10−16 , Λ7 → 0<
Chapter 10: Underconstrained Systems
359
Here is the pendulum model with constraint 7 dropped. 0 -0.5 -1 -1.5 -2
G
-2.5
F
-3 -3.5 -4 1
2
3
4
5
Next, constraint 5 is dropped, allowing the slider to move along the rope. Finally, constraint 6 is dropped, allowing the slider to rotate. The InitialGuess option is used to pass SetFree the solution to the last FreeSystem, which is named sol. This solution is a better initial guess than the defaults pulled from LastSolve[].
InitialGuess
is an option for SetFree that specifies the initial guesses that are used by the equilibrium solution routine. The default, InitialGuess → Automatic, uses the default initial guesses obtained from LastSolve[]. When Solve Free[freesys] is run, the initial guesses contained within freesys are updated to the new solution, if freesys is a symbol that evaluates to a FreeSystem.
An option for SetFree.
Here is another FreeSystem object with constraints 5 and 7 dropped. In[14]:= fsys = SetFree@85, 7<, InitialGuess → solD;
MechanicalSystems
360
This solves the FreeSystem object. Note that X2 has increased because the slider has moved to the right. In[15]:= sol = SolveFree@fsysD
Out[15]= 8T → 0, X2 → 2.69024, Y2 → −1.5416, Θ2 → 1.12896 × 10−27 ,
X3 → 3.31629, Y3 → −3.22922, Θ3 → 0.355232, s → 2.51768, Λ1 → 4.25124, Λ2 → 7.22059, Λ3 → −6.92849, Λ4 → 18.6768, Λ6 → 5.76529, Λ5 → 0, Λ7 → 0<
Here is the equilibrium position with constraints 5 and 7 dropped. 0 -0.5 -1 -1.5 -2
G
-2.5
F
-3 -3.5 -4 1
2
3
4
5
Here a FreeSystem object with constraints 5, 6, and 7 dropped is built and solved. In[16]:= fsys = SetFree@85, 6, 7<, InitialGuess → solD;
sol = SolveFree@fsysD
Out[17]= 8T → 0, X2 → 2.81609, Y2 → −1.53438, Θ2 → 0.234578,
X3 → 3.3866, Y3 → −3.24158, Θ3 → 0.322515, s → 2.63708, Λ1 → 4.02673, Λ2 → 7.79126, Λ3 → −6.24422, Λ4 → 18.685, Λ5 → 0, Λ6 → 0, Λ7 → 0<
Chapter 10: Underconstrained Systems
361
Here is the complete equilibrium position of the pendulum-on-a-rope model. 0 -0.5 -1 -1.5 -2
G
-2.5
F
-3 -3.5 -4 1
2
3
4
5
This returns MechanicalSystems to its initial state. In[18]:= ClearMech@AllD
10.2 Equilibrium Velocity This section covers the use of the SetFree and SolveFree functions to find the equilibrium velocity of a mechanism that has velocity-dependent loading. A mechanism must have some loading that is a direct function of velocity for it to have a defined equilibrium velocity. Note that the centrifugal forces in a model, although they are explicitly functions of velocity, are inertial forces and do not appear in a velocity equilibrium analysis.
MechanicalSystems
362
10.2.1 Example Mechanism This simple planar slider-crank model is presented with little explanation because all of the techniques used in the model have been explored in previous chapters. The one feature of interest in this model is the velocity-dependent applied loading. Two loads are applied, a driving moment on the crank and a viscous friction on the slider. Note that the driving moment applied to the crank is a function of velocity such that the moment drops to zero as velocity increases. This is done so that the velocity will not approach infinity when the piston is not moving at top-dead-center and bottomdead-center.
This loads the Modeler2D package and defines names for each of the body numbers. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
ground = 1; crank = 2; slider = 3;
Here are the constraints for the slider-crank model. In[5]:= SetConstraints@
Revolute2@1, Point@ground, 0D, Point@crank, 0DD, RotationLock1@2, crank, 2 N@πD TD, Translate2@3, Line@ground, 0, 81, 0
Here are the velocity-dependent applied loads. Note that the force on the slider always opposes its direction of motion. In[7]:= SetLoads@
Moment@crank, 5 H10 − Velocity@crankDP3TLD, Force@slider, Axis@slider, 0, 8−1, 0
Here is the moment that is applied to the crank by the rotational constraint at T = 0.2.
In[8]:= Reaction@2, crankD ê. [email protected], Solution → KinematicD Out[8]= 880, 0<, 51.263<
Chapter 10: Underconstrained Systems
363
Here is the slider-crank model at T = 0.2.
x
y
y 2
3
x
10.2.2 Finding Equilibrium Velocity To find the equilibrium velocity of a mechanism, a FreeSystem object is built that contains a new set of equations of motion with one or more constraints removed from the model.
SetFree[dropcon, Solution → Kinematic]
builds the mathematical equations required to find equilibrium velocity of the current model, and returns them in a FreeSystem object. The dropcon argument is used to specify the constraint numbers that are dropped to make the model underconstrained.
Velocity equilibrium.
The driving constraint is dropped from the slider-crank model to give the model one degree of freedom.
This drops the constraint that controls rotation of the crank. In[9]:= fsys = SetFree@2, Solution → KinematicD;
MechanicalSystems
364
This solves the FreeSystem object. Note that the angular velocity of the crank Θ2d is less than the driven angular velocity of 2 pi. In[10]:= sol = SolveFree@fsysD
Out[10]= 8T → 0.2, X2 → −2.37265 × 10−23 , Y2 → 0., Θ2 → 1.25664, X3 → 3.15427, Y3 → 0., Θ3 → 0.,
X2d → −2.49729 × 10−15 , Y2d → 0., Θ2d → 3.10241, X3d → −3.27102, Y3d → 0., Θ3d → 0., Λ1 → −32.7102, Λ2 → 10.9337, Λ4 → 34.488, Λ5 → −10.9337, Λ6 → 5.7482, Λ3 → 0<
To find the equilibrium velocity at a sequence of positions through a full cycle of the mechanism, the Ini tialCondition option is used to pass SolveFree a new set of initial conditions at each position where the equilibrium velocity is to be found. Thus, it is not necessary to create a new FreeSystem object for each solution point.
InitialCondition
is an option for SetFree and SolveFree that specifies the initial conditions needed to solve for equilibrium velocity or acceleration. For equilibrium velocity, InitialCondition should be a list of rules specifying the location of each body in the model. For equilibrium acceleration, InitialCondi tion must specify the location and velocity of each body. The default InitialCondition Ø Automatic uses the default initial guesses obtained from LastSolve[] for initial conditions.
An option for SetFree and SolveFree.
This generates a list of 20 rules to be used as initial conditions for the equilibrium velocity solution. In[11]:= SetGuess@D;
postab = SolveMech@80, 1<, 21D;
This solves the FreeSystem object at each initial condition in postab.
In[13]:= eqtab = HSolveFree@fsys, InitialCondition → #1D &L ê@ postab;
Chapter 10: Underconstrained Systems
365
Here is a plot of the equilibrium velocity of the crank through a full cycle of the mechanism.
In[14]:= ListPlot@8T, Θ2d< ê. eqtab, PlotJoined → TrueD 10 9 8 7 6 5 4 0.2
Out[14]=
0.4
0.6
0.8
1
Graphics
10.3 Free Acceleration This section covers the use of the SetFree function to build the dynamic equations of motion of an underconstrained model, and the use of the SolveFree function to find the instantaneous free acceleration. To find the time-domain free response of an underconstrained model, the free acceleration is integrated with respect to time. Integration of the equations of motion is covered in Section 10.4.
10.3.1 2D Example Mechanism A model of a two-link planar robot arm is developed to demonstrate the use of SetFree and SolveFree to find the instantaneous free acceleration of a mechanism. The robot arm has a force of unit magnitude, but varying direction, applied to the tip of the second link, while the two revolute joints in the arm are free to rotate. By finding the acceleration vector of the tip that results from a 1-unit applied force at a particular configuration of the arm, the “ellipse of mobility” can be plotted. Of the four constraints that make up the robot arm model, two are Revolute2 constraints that model the joints between the ground and link 1, and between link 1 and link 2. The other two RelativeAngle1 constraints are present only to set up the initial position of the arm. They are dropped by SetFree to provide two unconstrained degrees of freedom. The parameter loadangle is used to change the direction of the applied load at the tip of link 2.
MechanicalSystems
366
This loads the Modeler2D package and defines names for each of the body numbers. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
ground = 1; link1 = 2; link2 = 3;
Here are the constraints, bodies, and loads for the robot arm model. In[5]:= SetParameters@8loadangle → 0
SetConstraints@ Revolute2@1, Point@ground, 0D, Point@link1, 8−3, 0
Body@link1, Mass → 1.0, Inertia → 3.0, InitialGuess → 883, 1<, 0.5
In[8]:= SetLoads@
Force@link2, Axis@link2, 8−3, 0<, ground, PolarToXY@81, loadangle
In[9]:= Reaction@3, link1D ê. SolveMech@Solution → KinematicD Out[9]= 880, 0<, 6.<
Chapter 10: Underconstrained Systems
367
Here is the robot arm at its initial configuration. 7 y
6
F
5
3
4 x
y
3
x
2
2
1 0 -1 -2
0
2
4
6
10.3.2 Instantaneous Free Acceleration To find the free acceleration of an underconstrained mechanism a FreeSystem object is built that contains a new set of equations of motion with one or more constraints dropped from the model.
SetFree[dropcon, Solution Ø Dynamic]
builds the equations of motion required to find the free acceleration of the current model and returns them in a FreeSystem object. The dropcon argument is used to specify the constraint numbers that are to be dropped to make the model underconstrained.
Instantaneous free acceleration.
The two RelativeAngle1 constraints are now dropped from the robot arm to give the model two degrees of freedom. If initial conditions are not specified, SetFree takes them from the current default initial guesses LastSolve[].
This drops the constraints that lock the rotation of the joints. In[10]:= fsys = SetFree@83, 4<, Solution → DynamicD;
MechanicalSystems
368
This solves the FreeSystem object. In[11]:= sol = SolveFree@fsysD;
Here is the resultant acceleration vector at the tip of link 2.
In[12]:= Acceleration@link2, 8−3, 0
To find the free acceleration corresponding to a sequence of different values of loadangle, SetParame ters could be used between each successive run of SolveFree, or the InitialCondition option can be used to pass SolveFree the new parameter values. SolveFree reads all its initial conditions from the InitialCondition option, Parameters[], and the initial conditions contained in the FreeSystem object, in that order.
This solves the FreeSystem object at 21 different values of loadangle. In[13]:= freetab =
Table@SolveFree@fsys, InitialCondition → loadangle → iD, 8i, 0, 2 N@πD, N@πD ê 10
Here is a parametric plot of the X and Y components of the resulting acceleration at the tip of link 2. The diagonal line across the plot crosses the ellipse at loadangle = 0.
In[14]:= ListPlot@acc = Acceleration@link2, 8−3, 0
Epilog → Line@880, 0<, accP1T
1
-1.5
-1
-0.5
0.5 -1
-2
Out[14]=
Graphics
1
1.5
Chapter 10: Underconstrained Systems
369
10.3.3 3D Example Mechanism The following mechanism is a simple gyroscope that, dynamically, is not a very simple mechanism. The gyroscope consists of three moving bodies: the base, the gimbal, and the rotor. The base is constrained to rotate about a vertical axis affixed to the ground, while the gimbal rotates about a horizontal axis affixed to the base, and the rotor is constrained to rotate about a fixed axis on the gimbal that is orthogonal to the gimbal’s horizontal rotational axis on the base. The model is defined so that the origins of each body are always coincident, and so that each body is initially aligned with the global coordinate system, therefore no initial guesses are required because the default initial guesses are exact. The two Orthogonal1 constraints 2 and 4 are present only so that the model can be assembled in a fixed state. They will be dropped to find the free response. A single parameter freq is included in the model to specify the angular speed of the rotor, relative to the gimbal. The gyroscope is modeled in local, angular coordinates so that the angular velocities of interest appear directly in the solution rules. All of the bodies are massless except the rotor. This makes the results much easier to interpret. The moments of inertia of the rotor are representative of a thin disk. Only one load is applied to the model, a moment applied to the base in the Z direction. Initially this moment has no effect because the base is prevented from rotating by constraint 2. However, when the constraints that prevent the base and gimbal from rotating are dropped, the orthogonal reaction to the moment applied to the base can be observed at the rotor.
This loads the Modeler3D package and defines names for each of the body numbers. In[15]:= Needs@"MechanicalSystems`Modeler3D`"D
ground = 1; base = 2; gimbal = 3; rotor = 4; X = 81, 0, 0<; Y = 80, 1, 0<; Z = 80, 0, 1<;
MechanicalSystems
370
Here are the constraints, bodies, and loads for the gyroscope model. In[21]:= SetSymbols@Method → Angular, Coordinates → LocalD
SetParameters@8freq → 20 N@πD
Here is the gyroscope with the gimbal rotated to make a better picture.
Chapter 10: Underconstrained Systems
371
The model is run at T = 0.1 so that initial conditions are available for SolveFree.
In[26]:= Omega@rotorD ê. SolveMech@0, Solution → AccelerationD Out[26]= 862.8319, 0., 0.<
10.3.4 Instantaneous Free Acceleration To find the free acceleration of the gyroscope, one or more constraints must be dropped. The constraint that prevents rotation of the base, constraint 2, is dropped first. The rotor cannot precess in this state because the gimbal is still locked to the base, but the reaction torques applied to the base that accelerate the rotor can be measured. No initial conditions are explicitly given. Initial guesses are taken from the default initial guesses that were set by the last run of SolveMech.
This drops the constraint that locks the base relative to the ground. In[27]:= fsys = SetFree@2, Solution → DynamicD;
This solves the FreeSystem object. In[28]:= sol = SolveFree@fsysD;
The angular acceleration of the rotor is 1.0 in the Z direction. This corresponds to the 1.0 applied moment divided by the 1.0 moment of inertia about the Z axis.
In[29]:= 8Omega@rotorD, Alpha@rotorD, Alpha@gimbalD< ê. sol Out[29]= 8862.8319, 0., 0.<, 80., 0., 1.<, 80., 0., 1.<<
There is no gyroscopic torque applied to the base by the Revolute5 constraint because the base has zero angular velocity at this instant.
In[30]:= Reaction@1, baseD ê. sol
Out[30]= 880., 0., 0.<, 80., 0., 0<<
MechanicalSystems
372
To make this model a little more interesting, the base is given a nonzero angular velocity with the Initial Condition option for SolveFree. This induces gyroscopic torques in the base constraint. To be consistent with the constraints the Z components of the initial angular velocity of each body must be identical.
This solves the FreeSystem object with a new partial initial condition. The rest of the initial conditions are taken from LastSolve[].
In[31]:= sol = SolveFree@fsys, InitialCondition → 8Ωz2 → 1, Ωz3 → 1, Ωz4 → 1
The angular acceleration of the rotor now has a component in the Y direction corresponding to the changing direction of the angular velocity vector.
In[32]:= 8Omega@rotorD, Alpha@rotorD, Alpha@gimbalD< ê. sol Out[32]= 8862.8319, 0., 1<, 80., 62.8319, 1.<, 80., 0., 1.<<
Now there is a gyroscopic torque applied to the base by the Revolute5 constraint.
In[33]:= Reaction@1, baseD ê. sol
Out[33]= 880., 0., 0.<, 80., 125.664, 0<<
Now the FreeSystem is rebuilt with both the base and the gimbal unlocked. The same initial velocity for the base, gimbal, and rotor is used so that the gyroscope precesses.
This builds and solves the FreeSystem object with constraints 2 and 4 dropped. In[34]:= fsys = SetFree@82, 4<, Solution → DynamicD;
sol = SolveFree@fsys, InitialCondition → 8Ωz2 → 1, Ωz3 → 1, Ωz4 → 1
Without the constraint forces applied by constraint 4, the gimbal has an angular acceleration about its Y axis induced by the gyroscopic forces.
In[36]:= 8Omega@rotorD, Alpha@rotorD, Alpha@gimbalD< ê. sol
Out[36]= 8862.8319, 0., 1<, 80., −62.8319, 1.<, 80., −125.664, 1.<<
Chapter 10: Underconstrained Systems
373
Again, there is no gyroscopic torque applied to the base by the Revolute5 constraint because the gimbal is free to rotate.
In[37]:= Reaction@1, baseD ê. sol
Out[37]= 880., 0., 0.<, 80., 0., 0<<
10.3.5 Gyroscopic Moments Gyroscopic forces and moments modeled as per the example in Section 10.3.4 work well for single point analyses. However, if the time-domain free response is desired, such a modeling technique has a serious computational problem. While the rotor is spinning rapidly, the Euler parameters that represent the angular orientation of the rotor are changing sinusoidally and very rapidly. To numerically integrate such a system, the integrator must faithfully track very many periods of the sinusoidal Euler parameters to cover only a few periods of the motion of the more interesting parts of the gyroscope. If the period of the rotor’s local rotation is much, much shorter than the period of interest, the integration becomes computationally infeasible. The way around this problem is to introduce a special forcing function that mimics the gyroscopic torque of a spinning axially symmetric body and apply it to the rotor. This allows the rotor to be rotationally static.
GyroMoment[bnum, vec, omega]
applies a moment to body bnum to simulate the gyroscopic effects of the body spinning with angular speed omega, about an axis originating at the centroid of the body, parallel to vec. The constant angular velocity is relative to the local reference frame of body bnum.
Inertia
is an option for GyroMoment that is used to specify the inertia tensor of the gyroscoping body. The default setting Automatic uses the inertia tensor from body bnum.
A function to simulate gyroscopic moments.
GyroMoment has two important caveats attached to its use: the gyroscopic motion that it models is that of a body rotating about a principal axis of inertia and the two principle moments not associated with the axis of rotation must be equal. For most practical purposes, this means that the body is axially symmetric, and it is rotating about its axis of symmetry.
MechanicalSystems
374
To demonstrate the use of GyroMoment, the gyroscope model that was presented in Section 10.3.3 is modified to remove the large angular velocity of the rotor and replace it with a GyroMoment load.
Here the gyroscopic moment simulation is added to the applied loads, the angular speed of the rotor body is reduced to zero, and the model is run at T = 0 so initial conditions are available to SetFree. In[38]:= SetLoads@
Moment@base, Z, 1D, GyroMoment@rotor, X, 20 N@πDDD SetParameters@8freq → 0
Out[40]= 80, 0, 0<
First, the constraint that locks the base to the ground is dropped and SolveFree is run with the Z direction angular velocity set to 1. In[41]:= fsys = SetFree@2, Solution → DynamicD;
sol = SolveFree@fsys, InitialCondition → 8Ωz2 → 1, Ωz3 → 1, Ωz4 → 1
The resulting angular velocities and accelerations are missing the large components that were due to the rotation of the rotor.
In[43]:= 8Omega@rotorD, Alpha@rotorD, Alpha@gimbalD< ê. sol Out[43]= 880, 0, 1<, 80., 0., 1.<, 80., 0., 1.<<
But the reaction at the base still reflects the gyroscopic torques.
In[44]:= Reaction@1, baseD ê. sol
Out[44]= 880., 0., 0.<, 80., 125.664, 0<<
This builds and solves the FreeSystem object with constraints 2 and 4 dropped. In[45]:= fsys = SetFree@82, 4<, Solution → DynamicD;
sol = SolveFree@fsys, InitialCondition → 8Ωz2 → 1, Ωz3 → 1, Ωz4 → 1
Chapter 10: Underconstrained Systems
375
Without the rotation of the rotor, the angular accelerations of the rotor and gimbal are equal.
In[47]:= 8Omega@rotorD, Alpha@rotorD, Alpha@gimbalD< ê. sol Out[47]= 880, 0, 1<, 80., −125.664, 1.<, 80., −125.664, 1.<<
There is still no gyroscopic torque applied to the base when the gimbal is free to rotate.
In[48]:= Reaction@1, baseD ê. sol
Out[48]= 880., 0., 0.<, 80., 0., 0<<
The constraint reaction forces that result from using this method are identical to the reaction forces that result from the normal procedure, without the use of GyroMoment. The true values of alpha and omega for the simulated rotor are reproduced by the following calculation. omegalocal is the local angular velocity vector that was passed to GyroMoment. Note that omegatrue and alpha true match the angular velocity and acceleration components of the rotor in the previous analysis.
In[49]:= omegalocal = 820 N@πD, 0, 0<;
omegatrue = omegalocal + Omega@rotorD ê. sol alphatrue = Omega@rotorD omegalocal + Alpha@rotorD ê. sol
Out[50]= 862.8319, 0, 1<
Out[51]= 80., −62.8319, 1.<
The equations of motion that are produced by this method are essentially equivalent to the equations of motion without the spinning rotor simulation, with one important difference, these equations of motion can be easily integrated to obtain the time-domain motion of the entire gyroscope assembly without an overwhelming computational burden.
10.4 Dynamic Motion Synthesis This section covers the use of the SolveFree function to numerically integrate the equations of motion built by SetFree, which is done to find the time-domain dynamic motion of underconstrained systems. The FreeSystem objects that contain the equations of motion to be integrated are built using the same procedure that would be used if only the instantaneous free response was desired. Building such FreeSys tem objects is covered in Sections 10.2 and 10.3.
MechanicalSystems
376
10.4.1 Numerical Integration SolveFree[freesys, endtime, options]
finds the time-domain solution to a FreeSystem object built with SetFree. SolveFree integrates the equations of motion in freesys from the initial time (that is contained in freesys or set with the InitialCondition option) to endtime. SolveFree returns a list of rules representing the solution in the form of Mathematica InterpolatingFunction objects.
Numerical integration with SolveFree.
There are several issues that are specifically associated with the numerical solution of the constrained equations of motion generated by MechanicalSystems. The equations of motion are a nonminimal differentialalgebraic system of equations, that may or may not be linear in the highest-order terms. One important issue is constraint violation. The equations of motion do not include the actual kinematic constraints, they only include the second time derivatives of the constraint equations. Because of this, small errors in the numerical integration of the equations of motion can accumulate into large violations of the kinematic constraints and their first derivatives. To deal with this problem, the equations can be algebraically reduced to a minimal set, but this is not generally possible with the type of constraints allowed by Mech. Alternatively, the numerical values of the dependent variables can be corrected as the integration progresses so as to continuously satisfy the constraints. This method is implemented in SolveFree. Another issue is the transformation of angular velocity and acceleration in 3D models. If a model is built with angular coordinates (the Method → Angular option in SetSymbols) the first and second derivatives of angular orientation are represented by the angular velocity, omega, and the angular acceleration, alpha. Unfortunately, omega is not the first derivative of the Euler parameters used to represent angular orientation. Thus, a coordinate transformation must occur at each time step to allow the Euler parameters to be integrated. SolveFree handles this transformation automatically, so models built in any coordinate system can be integrated. The equations of motion are not necessarily linear in their highest-order terms, depending on the form of the applied loads. SolveFree automatically switches to an iterative solution method for nonlinear systems that allows them to be solved, albeit slowly.
Chapter 10: Underconstrained Systems
377
Initialization Options The only option that is concerned with the initialization of the integrator is the InitialCondition option. All other information needed to integrate the equations of motion is contained in the FreeSystem object. This option is most useful for repeatedly integrating the same FreeSystem with different sets of initial conditions without having to rerun SetFree.
InitialCondition Ø rules
is used to set the initial conditions for numerical integration. The rules should be a list of rules specifying the location, or location and velocity, of each body in the model. The initial value of time should be included. Any dependent variables not specified in InitialCondition are taken from the rules contained in the FreeSystem object passed into SolveFree. The default setting is InitialCondition Ø Automatic.
An initialization option for SolveFree.
The list of rules required by InitialCondition is of the form returned by SolveMech. Using Solve Mech to generate the initial conditions (which is essentially what is done by the default setting) guarantees that the initial conditions constitute a valid solution to the constraint equations. If initial conditions that do not satisfy the constraints are passed to SolveFree, the integration will proceed without difficulty, producing results that satisfy the differential equations of motion, but do not satisfy the kinematic constraints. Note that a sufficient set of initial conditions for integrating a free acceleration system is returned by Solve Mech[time, Solution → Velocity], while a sufficient set of initial conditions for integrating an equilibrium velocity system is returned by SolveMech[time]. Integration Options The following options are used to control the actual integration algorithm used by SolveFree. The default settings for these options are intended to produce reasonable results in the shortest possible time with a well-behaved system. Some tweaking may be required to get the best result from models with large accelerations or force discontinuities.
MechanicalSystems
378
ConstraintCorrection Ø True
enables an algorithm that corrects the location and velocity of each body at each time step so as to be consistent with the kinematic constraints. ConstraintCorrection should be used if the solution returned by SolveFree appears to drift away from satisfying the constraints. Using constraint correction approximately doubles the time required to run the integration. The default setting is False.
FitDegree Ø sym
specifies the degree of polynomial that is used to approximate each segment of the integrand at each time step. Valid settings for FitDegree are Linear, Quadratic, Cubic, and Quartic. Settings of lower degree work well on models that exhibit acceleration discontinuities. The default setting is Cubic.
MaxError Ø num
is used to specify the maximum estimated error allowed in any dependent variable in a single time step. If the maximum error in the current step goes above num, the time step size is halved. Setting MaxError to a smaller number than the default, 0.0001, effectively tightens the error tolerance, producing a more accurate result.
MaxSteps Ø integer
specifies the maximum number of time steps that will be taken by the numerical integrator. If MaxSteps is exceeded before reaching the final time, SolveFree stops and returns as much of the result as was completed. The default setting is MaxSteps Ø 500.
MaxStepSize Ø number
specifies the maximum step size that is used by the integrator. MaxStepSize has no effect if StepSize is not set to Automatic. The default setting is Infinity.
Options for controlling the SolveFree integrator.
Chapter 10: Underconstrained Systems
Method Ø Predictor
379
causes SolveFree to use an Adams-Bashforth predictive integration algorithm that requires one evaluation of the integrand at each time step.
Method Ø Corrector
causes SolveFree to use an Adams-Moulton predictor-corrector algorithm that requires two integrand evaluations per time step. Method Ø Automatic, the default, enables automatic switching between predictive and corrective steps, depending on the current error estimate, as the integration proceeds.
StartingStepSize Ø num
specifies the starting step size that is used by the integrator. StartingStepSize has no effect if StepSize is not set to the default setting, Automatic.
StepSize Ø num
specifies a constant time step size num that is used throughout the integration. The default setting, Auto matic, allows the time step size to be automatically increased or decreased by a factor of 2 as required by the current error estimate.
More options for controlling the integrator.
The error estimation used by SolveFree makes an assumption that the approximate magnitude of each of the dependent variables is near to 1. While this assumption is certainly valid for Euler parameters that are between –1 and 1, and the 2D angular coordinate that has units of radians, it is up to the user to choose a system of units such that the linear dimensions of the model are not extremely large or small. While the error estimation routine does not look at the Lagrange multipliers (Λ1, Λ2, …) it is best to keep the units of force and mass such that the Lagrange multipliers are not extremely large or small, because other parts of the numerical solution method begin to produce significant errors when dealing with a wide range of numerical magnitudes. When step size switching is enabled, SolveFree basically limits the maximum error in any dependent variable at a single time step to be less than the MaxError setting. If this is exceeded at a time step, the integrator backs up, halves the step size, and proceeds forward again. This error limit seems rather loose. If the same variable exhibited the maximum signed error at each time step, the cumulative error in that variable after 1000 time steps would be 0.1! In reality, the large errors occur at discrete points in the motion of a model, so the cumulative error is normally smaller.
MechanicalSystems
380
The MaxError option can also be used to explicitly specify the error magnitude limits at which the time step size is halved, doubled, or when a corrective versus predictive step is taken. MathError Ø {a, b, c} specifies that the time step size will be doubled if the sum of the maximum errors in the last four steps drops below c, it will be halved if the error in the current step goes above a, and an Adams-Moulton corrective step will be taken if the error is between a and b. Thus, MaxError Ø {0.0001, 0.00001, 0.000001} is equivalent to the default setting of MaxError Ø 0.0001. Iterative Solution Options The following options are used only to control the iterative solution block used for nonlinear models. These options have no effect on linear models.
MaxIterations Ø integer
sets the maximum number of iterations that are used by the Newton-Rhapson solution block. The default setting is 15.
ZeroTest Ø func
specifies a function to be applied to the values of the constraint expressions to determine if they are sufficiently close to zero. The default setting is ZeroTest Ø ( Abs[#] < 10^(-9)& ).
Options for the Newton-Rhapson solution block in SolveFree.
Free acceleration models are always linear in the acceleration variables (X2dd, Y3dd, …) but they may be nonlinear in the Lagrange multipliers (Λ1, Λ2, … ) if there are loads applied that are algebraically dependent on reaction forces, such as friction. Equilibrium velocity models can be nonlinear in the Lagrange multipliers, and they can also be nonlinear in velocity variables (X2d, Y3d, …) if the applied loads are nonlinear functions of velocity. The second element in a FreeSystem object tells whether the model is linear or not. FreeSystem[…][[2]] returns True for nonlinear models. Output Control Options The following options are used to determine what data is returned by SolveFree, and what format is used to returned it.
Chapter 10: Underconstrained Systems
FunctionOfTime Ø False
381
causes SolveFree to return pure functions that must have a single numeric argument to be evaluated, instead of InterpolatingFunction objects that are explicitly functions of time T. The default setting is True.
Interpolation Ø False
causes SolveFree to return the results in raw form, as lists of real numbers representing the value of each variable at each time step. The default setting is True.
InterpolationOrder Ø integer
specifies the order of the interpolating polynomials that are used to interpolate the results. A lower setting than the default, 3, may cause the interpolating functions to evaluate more quickly.
MakeRules Ø {syms}
is used to specify which dependent variables to include in the results. {syms} can be any subset of the list: {Parag meters, Location, Velocity, Acceleration, Generalized, Diagnostics}. The default setting, {Parameters, Location}, includes Interpolatingg Function objects for the location solution and any parameters. Constants are not interpolated.
Diagnostics
is an optional element of the setting for MakeRules. Including Diagnostics causes SolveFree to return two extra InterpolatingFunction objects, MaxError Ø intfunc and StepSize Ø intfunc, that represent the maximum error in any dependent variable and the current time step size as functions of time.
Output options for SolveFree.
The StepSize data returned by the Diagnostics setting can be useful to help determine what should be chosen for a constant step size, if one is desired. The MaxError data included by Diagnostics is the measure of error used by the adaptive time step adjustment algorithm to decide when to change the step size.
MechanicalSystems
382
10.4.2 Planar Example Mechanism The following example uses the pendulum-on-a-rope model that was developed in Section 10.1. The pendulum is released from a constrained zero velocity position, that is not in static equilibrium, and the free response is found. The spring force that was used to pull the pendulum off to one side is removed from the model, but gravity is retained. Also, nonzero moments of inertia are defined for each body, since the moments of inertia are relevant to the dynamics of the system, while they were not relevant to the equilibrium analysis.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Here are the three body objects, including the new inertia properties. In[2]:= SetBodies@
Body@ground = 1, PointList → 8 H∗P1∗L84, 0<, H∗P2∗L85, −3<
The pendulum-on-a-rope model uses seven constraint objects. The constraints that fix the initial position of the model have been altered so that the pendulum may be released from an offset position.
Chapter 10: Underconstrained Systems
383
Here are the constraints. In[3]:= SetConstraints@
RelativeDistance1@1, Point@ground, 0D, Point@slider, 1D, sD, RelativeDistance1@2, Point@ground, 1D, Point@slider, 2D, 4 − sD, Constraint@3, 8<, 8s, 2.5
Here is the gravitational load applied to the pendulum and slider. In[4]:= SetLoads@Gravity@80, −1<, 9.81DD
Now the model is run with SolveMech. In[5]:= SolveMech@0D
Out[5]= 8T → 0, X2 → 2.5, Y2 → −1.58087, Θ2 → 0., X3 → 3.36297, Y3 → −3.16052, Θ3 → 0.5, s → 2.375<
Here is the pendulum-on-a-rope model in its initial configuration. 0 -0.5 -1 -1.5 -2
G
-2.5 -3 -3.5 -4 1
2
3
4
5
MechanicalSystems
384
10.4.3 Free Response To find the free acceleration of the pendulum, a FreeSystem object is built that contains a new set of equations of motion with constraints 5, 6, and 7 dropped from the model. Note that no initial conditions are yet available for the velocity of the bodies in the model. SetFree sets all of the initial velocities to zero if none are specified with the InitialCondition option.
This drops the constraints that lock the position of the pendulum. SetFree needs initial conditions for the velocity of each body. Since none are available zero is assumed. In[6]:= fsys = SetFree@85, 6, 7<, Solution → DynamicD;
SetFree::zcond : Warning: Initial conditions for velocity are not available. Zero initial velocity assumed.
This integrates the FreeSystem object from T = 0 to T = 4.5, which is approximately a full period of the pendulum. The MakeRules option includes the velocity solution in the result.
In[7]:= sol = SolveFree@fsys, 4.5, MakeRules → 8Location, Velocity
Here is a plot of the X coordinates of the slider and the pendulum.
In[8]:= Plot@Evaluate@8X2, X3< ê. solD, 8T, 0, 4.5
3 2.5 2 1.5
1
Out[8]=
2
3
4
Graphics
Since the pendulum model is a conservative system, the sum of the kinetic and potential energy in the system should remain constant. This fact can be used to measure the accuracy of the numerical integrator.
Chapter 10: Underconstrained Systems
385
BodyEnergy[bnum]
returns the total kinetic energy possesed by body bnum.
A special output function.
The kinetic energy of each body is given by the BodyEnergy function, and the potential energy is simply the gravitational potential energy mass G altitude. The following plot shows that the numerical error in the integration has allowed the total energy of the model to increase by about 0.04% over 4.5 seconds.
Here is the total energy in the pendulum model. In[9]:= Plot@[email protected] Mass@sliderD Location@Centroid@sliderDDP2T +
9.81 Mass@pendulumD Location@Centroid@pendulumDDP2T + BodyEnergy@sliderD + BodyEnergy@pendulumD ê. solD, 8T, 0, 4.5<, PlotRange → AllD
-75.54
-75.545
1
2
3
4
-75.555
Out[9]=
Graphics
Tightening the error budget by a factor of 100 by specifying the MaxError Ø 0.000001 option for Solve Free will reduce the total energy rise to only 0.0007%, over the same time period, with an associated doubling of run time. Using the ConstraintCorrection Ø True option, with the default error budget, will reduce the total energy rise to 0.002% with a slightly smaller increase in run time. In this case, either constraint correction or reducing step size (which is the result of decreasing the error budget) gives similar returns on computer time investment. Changing the FitDegree setting can also affect the integration error. Setting FitDegree to Quadratic for this example will increase the net energy rise to 0.08%, while setting FitDegree to Quartic will reverse the sign of the error, changing the net energy rise to – 0.04%. Specifying a higher FitDegree setting often produces unexpected results because the automatic time step size adjustment works to counteract the
386
MechanicalSystems
higher degree setting. The integrator measures a smaller error in each step so it chooses a larger step size, resulting in the same net error.
Here is the pendulum-on-a-rope model at T = 1, 2, and 3 seconds.
Here is an animation of the pendulum-on-a-rope model.
10.4.4 Gyroscopic Example The following example integrates the motion of the gyroscope model that was presented in Section 10.3. The model uses the GyroMoment function, which was also presented in Section 10.3, to reduce the numerical burden of integrating the motion of the rotor. The angular local coordinate system is used, which requires SolveFree to use a coordinate transformation during the integration.
Chapter 10: Underconstrained Systems
387
This loads the Modeler3D package and defines names for each of the body numbers. In[10]:= Needs@"MechanicalSystems`Modeler3D`"D
ground = 1; base = 2; gimbal = 3; rotor = 4; X = 81, 0, 0<; Y = 80, 1, 0<; Z = 80, 0, 1<;
Here are the constraints, bodies, and loads for the gyroscope model. In[16]:= SetSymbols@Method → Angular, Coordinates → LocalD
SetConstraints@ Revolute5@1, Axis@ground, 0, ZD, Axis@base, 0, ZDD, Orthogonal1@2, Vector@base, XD, Vector@ground, YDD, Revolute5@3, Axis@base, 0, YD, Axis@gimbal, 0, YDD, Orthogonal1@4, Vector@gimbal, ZD, Vector@base, XDD, Revolute5@5, Axis@gimbal, 0, XD, Axis@rotor, 0, XDD, ProjectedAngle1@6, Vector@rotor, ZD, Vector@gimbal, ZD, Vector@gimbal, XD, 0DD SetBodies@ Body@rotor, Inertia → 82.0, 1.0, 1.0, 0, 0, 0
The model is run to prepare the initial conditions for SetFree. Note that the rotor has no angular velocity because it is modeled in the GyroMoment load.
In[20]:= Omega@rotorD ê. SolveMech@0, Solution → AccelerationD Out[20]= 80, 0, 0<
MechanicalSystems
388
10.4.5 Free Response To find the unconstrained motion of the gyroscope, a FreeSystem object is built that contains a new set of equations of motion with constraints 2, 4, and 6 dropped from the model. Constraint 6, the constraint that locks the rotation of the rotor to that of the gimbal, is dropped in this simulation because the gross motion of the rotor results in some relative angular acceleration between these two bodies. If constraint 6 was not dropped, the model would represent an enforced constant angular velocity between the rotor and the gimbal, as if the rotor had a constant velocity motor attaching it to the gimbal. The constant moment that was applied to the base is retained, so the model is expected to gain energy with the passage of time.
This drops the constraints that lock the three rotational axes of the gyroscope. In[21]:= fsys = SetFree@82, 4, 6<, Solution → DynamicD;
This integrates the FreeSystem object from T = 0 to T = endt. The MakeRules option includes the velocity solution in the result.
In[22]:= sol = SolveFree@fsys, endt = 1.0, MakeRules → 8Location, Velocity
Here is a plot of the three components of the angular velocity of the gimbal. The Z component is simply oscillating about zero, so the applied torque is producing no net motion of the gimbal. The Y component, however, is consistently negative, so the gimbal is precessing in an oscillatory manner.
In[23]:= Plot@Evaluate@Omega@gimbalD ê. solD, 8T, 0, endt<,
PlotStyle → 88<, [email protected], .03
0.05
0.2 -0.05 -0.1 -0.15
Out[23]=
Graphics
0.4
0.6
0.8
1
Chapter 10: Underconstrained Systems
389
Here is a plot of the rotation angle of the base.
In[24]:= Plot@Evaluate@ProjectedAngle@Vector@base, XD, X, ZD ê. solD, 8T, 0, endt
Out[24]=
0.4
0.6
0.8
1
Graphics
Note that the Rotation function was not used in the preceding example to resolve the rotation angle of the base from the Euler parameters, but ProjectedAngle was used instead. This was done because the small numerical errors in the integration caused one of the Euler parameters to drift slightly above 1.0. The Euler parameters are not meaningful for absolute values greater than 1, so the Rotation function would return an error. The ProjectedAngle function uses vector algebra, instead of a mathematical identity, and it does not care if the values of the Euler parameters stray above 1. Since the gyroscope model is a conservative system (if the applied moment is recognized as a conservative force) the sum of the kinetic and potential energy in the model should be constant. The potential energy stored by the constant applied moment is the work done by the gyroscope on the applied moment, which is the negative of the magnitude of the applied moment times the is rotation of the base. The following plot shows that the numerical error in the integration has allowed the total energy of the model to decrease by about 2% of the maximum kinetic energy over the integration period.
MechanicalSystems
390
Here is the total energy in the gyroscope, including the energy stored in the constant applied moment.
In[25]:= Plot@Evaluate@BodyEnergy@rotorD − 1 ProjectedAngle@Vector@base, XD, X, ZD ê. solD,
8T, 0, endt
0.4
0.6
0.8
1
-0.00005 -0.0001 -0.00015 -0.0002 -0.00025
Out[25]=
Graphics
This is near to the maximum kinetic energy of the body.
In[26]:= BodyEnergy@rotorD ê. sol ê. T → .26 Out[26]= 0.0125909
Tightening the error budget by a factor of 10 with MaxError Ø 0.00001 will reduce the total energy rise to only 0.12% over the same period, with an associated increase in run time. Using the ConstraintCorrec tion Ø True option, with the default error budget, will have virtually no effect on the error in the total energy. This is because the error stems from the deviation in the Euler parameters that are very close to 1, an error on which constraint correction has little effect. Using the FitDegree Ø Quartic option, with the default error budget, will reduce the total energy rise to 0.71%, with only a small increase in run time.
10.4.6 Reducing Gyroscopic Models There is one more technique that can be applied to 3D gyroscopic models to reduce their size and thereby reduce their run time. This technique can be very useful to models with more than one rotor.
Chapter 10: Underconstrained Systems
GyroFilter[{Ixx, Iyy, Izz, Ixy, Iyz, Izx}, {x, y, z}]
391
returns a new set of inertia properties that have zero inertia in the direction of {x, y, z} . {x, y, z} must be a principle axis of the body represented by the inertia properties, and the two principal moments not associated with {x, y, z} must be equal.
A function for modifying an inertia tensor.
The restrictions that apply to the use of GyroFilter are identical to the restrictions that apply to the use of GyroMoment. The body represented by the inertia properties must be axially symmetric. The purpose of GyroFilter is to make it possible to add a zero-torque spinning body to a model without actually adding a body to the model at all. To demonstrate, the rotor body is deleted from the previously defined gyroscope model, and replaced with a special load and inertia properties on the gimbal. This time, the model is built in Euler coordinates, just to show that the results are the same.
Here is the gyroscope constraint set with the rotor deleted. In[27]:= SetSymbols@Method → EulerD
SetConstraints@ Revolute5@1, Axis@ground, 0, ZD, Axis@base, 0, ZDD, Orthogonal1@2, Vector@base, XD, Vector@ground, YDD, Revolute5@3, Axis@base, 0, YD, Axis@gimbal, 0, YDD, Orthogonal1@4, Vector@gimbal, ZD, Vector@base, XDDD
Here is the body object for the gimbal. It now carries the inertia of what was the rotor with the component in the direction of the spin axis (the local X axis) of the rotor filtered out. Note the return from GyroFilter; the X component of the inertia is gone. In[29]:= SetBodies@
Body@gimbal, Inertia → [email protected], 1.0, 1.0, 0, 0, 0<, XDDD [email protected], 1.0, 1.0, 0, 0, 0<, XD
Out[30]= 80., 1., 1., 0., 0., 0.<
MechanicalSystems
392
Here are the load objects. They are unchanged, except that GyroMoment uses the inertia option to explicitly specify the inertia properties. If this was not done, GyroMoment would pull the inertia properties from the body object that has previously had the X component filtered out. In[31]:= SetLoads@
Moment@base, Z, 1D, GyroMoment@gimbal, X, 2 N@πD, Inertia → 82.0, 1.0, 1.0, 0, 0, 0
The model is now functionally equivalent to the previously defined model. The model can be integrated with SolveFree, after dropping constraints 2 and 4. Constraint 6 was previously dropped and is no longer part of the model.
The model is integrated from T = 0 to 1. In[32]:= SolveMech@0, Solution → AccelerationD;
fsys = SetFree@82, 4<, Solution → DynamicD; sol = SolveFree@fsys, endt = 1.0, MakeRules → 8Location, Velocity
Here is a plot of the angular velocity components of the gimbal. It is identical to the response of the previous model, with only two bodies required to create it.
In[35]:= Plot@Evaluate@Omega@gimbalD ê. solD, 8T, 0, endt<,
PlotStyle → 88<, [email protected], .03
0.05
0.2 -0.05 -0.1 -0.15 Out[35]=
Graphics
0.4
0.6
0.8
1
Chapter 10: Underconstrained Systems
393
10.5 Nonholonomic Systems Nonholonomic systems, or systems that have a kinematic constraint that is an explicit function of velocity, are dealt with using the SetPath and SolvePath functions. SetPath is used to take a normally constrained kinematic model and replace one of its constraints with a constraint that is a function of mechanism velocities. SolvePath then integrates the resulting first-order system to obtain a time history of the motion of the mechanism.
10.5.1 Example Mechanism The following planar example is probably one of the more common nonholonomic systems, a caster, such as a wheel on a shopping cart. The caster is modeled in two dimensions by viewing the caster from above, like looking down through the shopping cart. The steady state motion of a caster is for the wheel to trail directly behind the pivot point of the caster. What is modeled here is the motion of the caster when the direction of travel of the pivot is reversed. The caster swings out to one side of the pivot and then settles in behind the pivot again. The wheel of the caster is modeled as a single nonholonomic constraint that constrains the direction of travel of the wheel to be parallel to the direction that the wheel is pointed. In vector algebra terms the velocity vector of the wheel is perpendicular to a vector through the wheel’s axis of rotation. Normal Mech constraint functions can be used to model first-order relationships such as this by making at least one of the geometry specifications in the constraint a function of velocity. Before the velocity constraint can be put in place by SetPath the model must be built in a normal kinematically constrained way. This requires a dummy constraint that will be replaced by SetPath later. The dummy constraint is a RotationLock1 constraint to lock the rotation of the caster relative to the ground. The other constraint in the model, constraint 1, simply constrains the pivot point of the caster to move steadily along the global X axis.
MechanicalSystems
394
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Here is a pair of constraints for the 2D caster model. The second constraint will be replaced with a velocity relationship by SetPath. In[2]:= ground = 1;
caster = 2; SetConstraints@OriginLock2@1, caster, 8T, 0
The model is run just to make initial conditions available to SetPath. In[5]:= SolveMech@0D;
Here is the caster with zero initial angle. 2 1 0 -1 0
2
4
6
8
10
Chapter 10: Underconstrained Systems
395
10.5.2 Nonholonomic Constraints SetPath[constraint]
builds the differential equations necessary to find the time-domain motion of a nonholonomic system. The given velocity-dependent constraint replaces the kinematic constraints in the current mechanism that have the same constraint number. SetPath returns the new equations in a PathSystem object.
SolvePath[pathsys, endtime]
finds the solution to the nonholonomic system built by SetPath. SolvePath integrates the equations of motion from the initial time contained in pathsys or given with the InitialCondition option, to endtime. SolvePath uses the same integration block that is used by SolveFree, and accepts all of the same options.
The nonholonomic system solving functions.
This builds the PathSystem object. The second argument of the Orthogonal1 constraint is interpreted as a vector, in global coordinates, that is constrained to be orthogonal to the Vector on the caster.
In[6]:= psys = SetPath@Orthogonal1@2, Velocity@caster, 82, 0D
The InitialCondition option is used to give the caster a nonzero initial angle. Otherwise, it is simply pushed along in front of the pivot indefinitely, instead of swinging around behind the pivot as expected. In[7]:= sol = SolvePath@psys, 10, InitialCondition → Θ2 → 0.1D Out[7]= 8X2 → InterpolatingFunction@880., 10.<<, <>D@TD,
Y2 → 0, Θ2 → InterpolatingFunction@880., 10.<<, <>D@TD<
MechanicalSystems
396
Here is a plot of the caster angle as a function of time. Note that T is equal to the X coordinate of the caster.
In[8]:= Plot@Evaluate@Θ2 ê. solD, 8T, 0, 10<, Frame → TrueD
2.5 2 1.5 1 0.5 0 0 Out[8]=
2
4
6
8
10
Graphics
Here is a graphic of the caster at five positions between T = 1 and T = 10. 2 1 0 -1 0
2
4
6
8
10
11. Generalized Coordinates Overview This chapter covers the use of user-defined generalized coordinates to represent the location of some or all of the bodies in a MechanicalSystems model, replacing the reference point coordinates that are used by default. The primary utility of this technique is to increase the performance of multibody models by reducing the total number of symbolic coordinates used. Standard Mech models are made up of one or more independent bodies, each of which is represented by three, four, or seven Cartesian and Euler coordinates. While this representation is very general, and allows bodies to be interconnected in an unrestricted manner, it inevitably causes many more symbolic coordinates to be included in the model than are required to represent its motion. For example, a 3D body that is attached to the ground with a revolute joint (a Revolute5 constraint in MechanicalSystems) would normally be represented by seven coordinates. While all these coordinates are necessary to completely define the location and orientation of the body, we are really concerned with only one of them; the single coordinate representing rotation about the revolute axis. The other coordinates may be just excess baggage, conveying trivial, constant information that we do not need. Using generalized coordinates allows such a body to be represented by a single coordinate, supplied by the user. Note that there are pros and cons to using generalized coordinates. Some information, such as constraint reaction forces, are lost when a constraint is eliminated from the model with generalized coordinates. This notebook contains general guidelines to help determine when to use generalized coordinates, and when to use Mech’s standard representation.
398
MechanicalSystems
11.1 Generalized Coordinate Constraints The generalized coordinate constraints are not, in fact, constraints at all. Each generalized coordinate constraint is named like a standard constraint, takes approximately the same arguments as a standard constraint, returns a SysCon constraint object that is passed to SetConstraints, and generally appears in a mechanism model in exactly the same way as the standard Modeler2D and Modeler3D constraints. The difference between them is best illustrated by an example. Consider a standard Modeler2D model containing a Translate2 constraint that models a translational joint between body 2 and the ground. The presence of the constraint object causes SetConstraints to do two things: three degrees of freedom (the symbols X2, Y2, and Θ2) are added to the model to represent body 2, and two degrees of freedom are removed from the model by the two constraint equations in the constraint. The net effect, then, is to add one degree of freedom to the model that must be constrained by some other constraint. If the Translate2 constraint is replaced with a GenTranslate2 constraint, SetConstraints does only one thing: one degree of freedom is added to the model by adding a single symbol to the dependent variable list. The name of the symbol is specified in the GenTranslate2 constraint object. Body 2, which was represented by three symbols, is now represented by only one. All of Mech’s other constraint, load, output, and graphics functions can recognize and access body 2 just as if it were a standard body; the only difference is that the symbolic representation of all geometry on the body is a function of just one symbol, not three. Note that generalized coordinate constraints cannot be used within the multistage constraint objects, Time Switch or StageSwitch. This is simply because including them in a multistage constraint would have no effect on the model; the generalized coordinate constraints contain no constraint equations, so there is nothing to switch on and off.
11.1.1 2D Constraints There are only two 2D generalized coordinate constraints. The wide variety of standard 2D constraints cannot be meaningfully converted to generalized constraints; only constraints which attach exactly two bodies together such that only one degree of freedom remains between them are generally useful.
Chapter 11: Generalized Coordinates
399
The arguments given to the generalized coordinate constraints are of the same form as the arguments given to the standard constraints. However, each of these constraints requires an additional argument to specify the name of, and an initial guess for, the new symbol that represents the added degree of freedom.
GenRevolute2[cnum, axis1, axis2, {sym, guess}]
returns a constraint object that introduces a slave body into the model represented by a single generalized coordinate sym. The axis1 body is a slave to the axis2 body with one degree of rotational freedom. The origins of the two axes are constrained to be coincident, and the counterclockwise angle from axis2 to axis1 is represented by sym.
GenTranslate2[cnum, axis1, axis2, {sym, guess}]
returns a constraint object that introduces a slave body into the model represented by a single generalized coordinate sym. The axis1 body is a slave to the axis2 body with one degree of translational freedom. The two axes are constrained to be colinear, and the distance from the origin of axis2 to that of axis1, in the direction of axis2, is represented by sym.
The 2D generalized coordinate constraints.
Note that there is a clear distinction between a master and slave bodies. The slave body is the one that will be represented by the single new generalized coordinate. Thus, the slave body cannot be the ground body. The master body may be the ground body, another body represented by standard coordinates, or another body represented by generalized coordinates that was created with another generalized constraint. The master-slave relationship cannot be circular; the master-slave chain must originate from the ground, or from a standard body. Also, a slave body cannot be a slave to more than one master body. Another restriction on the arguments to generalized coordinate constraints is that the axis objects, axis1 and axis2, must each be defined entirely on a single body. While standard constraints allow axis objects to span multiple bodies (such as a line originating on one body and ending on another) generalized coordinate constraints do not.
MechanicalSystems
400
Example The following example shows a standard constraint and a generalized coordinate constraint that could be used to perform exactly the same function in a model.
Here are two functionally equivalent constraints. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
ground = 1; body2 = 2; Translate2@2, Line@body2, 80, 0<, 80, 1D Out[5]= SysCon@GenTranslate2, 2, <>D
11.1.2 3D Constraints There are only four 3D generalized coordinate constraints. The wide variety of standard 3D constraints cannot be meaningfully converted to generalized constraints; only constraints that attach exactly two bodies together such that only one or two degrees of freedom remain between them are generally useful. The arguments given to the generalized coordinate constraints are of the same form as the arguments given to the standard constraints. However, each of these constraints requires additional arguments to specify the names of, and an initial guesses for, the new symbol or symbols that represent the added degrees of freedom.
Chapter 11: Generalized Coordinates
GenCylindrical4[cnum, axis1, axis2, {alpha, guess}, {beta, guess}]
401
returns a constraint object that introduces a slave body represented by two generalized coordinates alpha and beta. The axis1 body is a slave to the axis2 body with one degree of rotational freedom and one degree of translational freedom. The two axes are constrained to be colinear and the distance from the origin of axis2 to that of axis1, in the direction of axis2, is represented by alpha. The angle from the projection of the reference direction of axis2 to that of axis1, in the right-hand sense, is represented by beta.
GenOrthoRevolute4[cnum, axis1, axis2, {alpha, guess}, {beta, guess}]
returns a constraint object that introduces a slave body represented by two generalized coordinates alpha and beta. The axis1 body is a slave to the axis2 body with two degrees of rotational freedom. The origins of the two axes are constrained to be coincident, and the axes are constrained to be orthogonal. The symbol alpha represents the angle between axis1 and the reference direction of axis2, and beta represents the angle between axis2 and the reference direction of axis1.
GenRevolute5[cnum, axis1, axis2, {sym, guess}]
returns a constraint object that introduces a slave body represented by a single generalized coordinate sym. The axis1 body is a slave to the axis2 body with one degree of rotational freedom. The two axes are constrained to be parallel and their origins are constrained to be coincident. The angle from the projection of the reference direction of axis2 to that of axis1, in the right-hand sense, is represented by sym.
GenTranslate5[cnum, axis1, axis2, {sym, guess}]
returns a constraint object that introduces a slave body represented by a single generalized coordinate sym. The axis1 body is a slave to the axis2 body with one degree of translational freedom. The two axes are constrained to be colinear, and the distance from the origin of axis2 to that of axis1, in the direction of axis2, is represented by sym. The projections of the reference directions of the two axes are constrained to be parallel.
The 3D generalized coordinate constraints.
MechanicalSystems
402
Note that there is a clear distinction between a master and slave bodies. The slave body is the one that will be represented by the single new generalized coordinate. Thus, the slave body cannot be the ground body. The master body may be the ground body, another body represented by standard coordinates, or another body represented by generalized coordinates that was created with another generalized constraint. The master-slave relationship cannot be circular; the master-slave chain must eventually lead back to the ground, or to a standard body. Another restriction on the arguments to generalized coordinate constraints is that the axis objects, axis1 and axis2, must each be defined entirely on a single body. While standard constraints allow axis objects to span multiple bodies (such as a line originating on one body and ending on another) generalized coordinate constraints do not. Example The following example shows a standard constraint and a generalized coordinate constraint that could be used to perform exactly the same function in a model.
Here are two functionally equivalent constraints. In[6]:= Needs@"MechanicalSystems`Modeler3D`"D
ground = 1; body2 = 2; Revolute5@2, Line@body2, 80, 0, 0<, 80, 1, 0D Out[10]= SysCon@GenRevolute5, 2, <>D
11.1.3 User-Defined Generalized Constraint If the selection of predefined generalized coordinate constraints is not sufficient, the GenConstraint function can be used to create constraints with any number of generalized coordinates representing any geometric relationship between two bodies that can be written algebraically.
Chapter 11: Generalized Coordinates
GenConstraint[cnum, point1, point2, rotation, {sym, guess}]
403
returns a constraint object which introduces a slave body represented by generalized coordinates into the model. A point on the slave body, point1, is constrained to be coincident with a point on the master, point2. The angular orientation of the slave with respect to the master is specified by rotation. {sym, guess}, or {{sym1, guess}, …}, are generalized coordinate symbols and their associated initial guesses that are added to the model.
The user-defined generalized coordinate constraint.
In Modeler2D, rotation is a counterclockwise angle. In Modeler3D, rotation is specified in the {ang, axis} format, and it can be a single rotation or a sequence of rotations of the form used by RotationLock3. The trick to creating a valid constraint with GenConstraint is to make the pointi and rotation arguments symbolic functions of the generalized coordinate symbols symi. For example, the following constraint object would introduce a slave body that is constrained so that its origin lies on a parabola in the Y-Z plane, and its rotation is about the Z axis only. The position of the body along the parabola is represented by tau, and the rotation angle of the body about the Z axis is represented by phi.
Here is a GenConstraint example. In[11]:= GenConstraint@1,
Point@body2, 80, 0, 0
Out[11]= SysCon@GenConstraint, 1, <>D
11.1.4 Four-Bar Example Mechanism To demonstrate the use of generalized coordinate constraints in a Modeler2D model, a 2D model of a simple four-bar mechanism is developed. The model consists of three moving bars and one stationary bar, the ground. This same model is also used in Section 8.3 and Chapter 9, so it is presented very briefly here.
MechanicalSystems
404
This loads the Modeler2D packages. In[12]:= Needs@"MechanicalSystems`Modeler2D`"D
Off@General::"spell1"D X = 81, 0<; Y = 80, 1<;
Here is the four-bar mechanism, shown with the locus of a moving point. 4
3
2
1
0
-1
-2
-1
0
1
2
Bodies Four body objects are required for the four-bar model. Each bar is attached to another bar at its local origin and at a point at the other end of the bar on the local X or Y axis. • The ground (body 1) uses two points. P0 is the attachment point of the drive bar. P1 is the attachment point of the driven bar. • The drive bar (body2) uses two points. P0 is the rotational axis of the drive bar. P1 is the attachment point of the center bar.
Chapter 11: Generalized Coordinates
405
• The driven bar (body3) uses two points. P0 is the rotational axis of the driven bar. P1 is the attachment point of the center bar. • The center bar (body 4) uses three points. P0 is the attachment point of the drive bar. P1 is the attachment point of the driven bar. P2 is an offset point used for tracking a point locus. Here are the body objects for the four-bar model.
In[16]:= bd@1D = Body@ground = 1, PointList → 88−2, 3<
bd@2D = Body@drivebar = 2, PointList → 881, 0<
The body properties are incorporated into the model. In[20]:= SetBodies@bd@groundD, bd@drivebarD, bd@drivenbarD, bd@centerbarDD
Constraints Five constraints, one of which is a driving constraint, are used to model the four-bar mechanism. These constraints are simply standard Mech constraints that will be replaced with generalized coordinate constraints shortly. • A RotationLock1 constraint is used as a driving constraint to rotate the drive bar. • Four Revolute2 constraints model the four pivot points in the four-bar mechanism. Here are the constraint objects for the four-bar. In[21]:= cs@1D = RotationLock1@1, drivebar, 2 N@πD TD;
cs@2D = Revolute2@2, cs@3D = Revolute2@3, cs@4D = Revolute2@4, cs@5D = Revolute2@5,
Point@drivebar, 0D, Point@ground, 0DD; Point@centerbar, 0D, Point@drivebar, 1DD; Point@drivenbar, 1D, Point@centerbar, 1DD; Point@drivenbar, 0D, Point@ground, 1DD;
The constraints are incorporated into the current model. In[26]:= SetConstraints@Array@cs, 5DD
MechanicalSystems
406
Runtime Because of the presence of T in the driving constraint cs[1], the model can be run through its intended range of motion by varying T directly with the SolveMech command. The numerical value of T specifies the angle of rotation of the drive bar in revolutions.
The model is run at T = 0.3. In[27]:= [email protected]
Out[27]= 8T → 0.3, X2 → 0., Y2 → 0., Θ2 → 1.88496, X3 → −2., Y3 → 3.,
Θ3 → 0.231291, X4 → −0.309017, Y4 → 0.951057, Θ4 → −0.422136<
Here is the four-bar model at T = 0.3. 4
3
2
1
0
-1
-2
-1
0
1
2
Generalized Coordinate Constraints Now one of the standard constraints is replaced with a generalized coordinate constraint. Constraint 2, the revolute joint at the drive bar origin, is replaced first, and body 2 becomes a slave to the ground body, represented by the single coordinate alpha.
Here is the new constraint.
In[28]:= cs@2D = GenRevolute2@2, Axis@drivebar, 0, XD, Axis@ground, 0, XD, 8alpha, 0.0
SetConstraints@Array@cs, 5DD
Chapter 11: Generalized Coordinates
407
The modified model is run again at T = 0.3. In[30]:= [email protected]
Out[30]= 8T → 0.3, X3 → −2., Y3 → 3., Θ3 → 0.231291,
X4 → −0.309017, Y4 → 0.951057, Θ4 → −0.422136, alpha → 1.88496<
Note that the symbols X2, Y2, and Θ2 are no longer included in the solution rules returned by SolveMech. The location of body 2 is represented entirely by alpha, which has the same numerical value as Θ2 used to have. The numerical value of alpha would be different from Θ2 if the direction vectors of the two axes in the GenRevolute2 constraint were not identical (X and X). Two more of the Revolute2 constraints can also be replaced, but not the fourth one. This is because each generalized coordinate constraint creates a slave body, and a slave body can be a slave to only one master body. Thus, there is no way to use four generalized coordinate constraints in a model with only three bodies. Any three of the four revolute constraints can be replaced, but not all of them.
Here are two more new constraints.
In[31]:= cs@3D = GenRevolute2@3, Axis@centerbar, 0, XD, Axis@drivebar, 1, XD, 8beta, 0.0
In[32]:= cs@4D = GenRevolute2@4, Axis@drivenbar, 1, XD, Axis@centerbar, 1, XD, 8gamma, 0.0
The modified model is run again at T = 0.3. In[34]:= [email protected]
Out[34]= 8T → 0.3, alpha → 1.88496, beta → −2.30709, gamma → 0.653428<
Now all of the Cartesian coordinates have been replaced with the generalized coordinates alpha, beta, and gamma. A quick degree of freedom count shows that this all makes sense: the three generalized coordinate constraints each add one degree of freedom to the model, while the two standard constraints Revolute2 and RotationLock1 constrain a total of three degrees of freedom. The physical meaning of the new coordinates is quite clear: alpha is the angle between the X axis of the ground and the local x axis of the drive bar, beta is the angle between the local x axes of the drive and center bars, and gamma is the angle between the local x axes of the center and driven bars.
MechanicalSystems
408
Output and Graphics Functions Now that we have a solution in terms of the generalized coordinates, all of the standard Mech output and graphics functions allow it to be used in the same manner as a solution in Cartesian coordinates. For example, the location of a point is still found with the Location function and the rotation angle of a body is found with Rotation. The symbolic expressions returned by these functions reflect the new coordinate system being used, but the numerical results are equivalent.
Here are the Cartesian coordinates of point 2 on the center bar. In[35]:= Location@centerbar, 2D
% ê. LastSolve@D
Out[35]= 8Cos@alphaD + Cos@alpha + betaD − 2 Sin@alpha + betaD,
2 Cos@alpha + betaD + Sin@alphaD + Sin@alpha + betaD<
Out[36]= 81.42262, 2.36578<
Here is the global rotation angle of the driven bar. Note that it is numerically equal to the Θ3 coordinate from the first set of solution rules. % ê. LastSolve@D
In[37]:= Rotation@drivenbarD
Out[37]= alpha + beta + gamma Out[38]= 0.231291
The location of point 2 on the center bar is a function of alpha and beta, but not gamma. This is because of the master-slave relationship of the generalized coordinate bodies; the center bar is a slave to the drive bar, which is a slave to the ground. Thus, the location of any point on the driven bar is a function of all three generalized coordinates, and the location of any point on the drive bar is a function of only alpha. Mech graphics functions also operate without regard to the use of generalized coordinates. The following graphics object will generate the same image with any of the three constraint formulations used previously.
Chapter 11: Generalized Coordinates
409
Here is the graphics object representing the four-bar model. H∗Ground∗L8Point@8−2, 3
In[39]:= graph := Graphics@[email protected], [email protected],
This shows the graphic at T = 0.45.
In[40]:= Show@graph ê. [email protected], AspectRatio → AutomaticD 4
3
2
1
0
-1
-2
-1
Out[40]= h Graphics h
0
1
2
MechanicalSystems
410
11.1.5 Space-Crank Example Mechanism To demonstrate the use of generalized coordinate constraints in a Modeler3D model, a 3D model of a spatial slider-crank mechanism is developed. The model consists of three moving bodies; a slider, crank, and connecting rod. A geometrically similar model is presented in Section 3.2. The model presented here differs in that it uses a separate body to represent the connecting rod, instead of simply replacing it with a relativedistance constraint.
This loads the Modeler3D packages. In[41]:= Needs@"MechanicalSystems`Modeler3D`"D
Off@General::"spell1"D X = 81, 0, 0<; Y = 80, 1, 0<; Z = 80, 0, 1<;
Here is the complete space-crank graphic.
Chapter 11: Generalized Coordinates
411
Bodies Four body objects are defined for the space-crank model. Note the use of the zeroth point to avoid having to define {0, 0, 0}. • The ground (body 1) has one point defined in its body object. P1 is a point to locate the rotational axis of the crank. • The crank (body 2) has one point defined in its body object. P1 is the attachment point of the connecting rod. The center of the crank is at the local origin. • The connecting rod (body 3) has one point defined in its body object. P1 is the attachment point of the connecting rod to the slider, while the connecting rod is attached to the crank at P0. • The slider (body 4) has no points in its body object, only an initial guess, because only the local origin P0 is used. Here are the body objects for the space-crank model.
In[46]:= bd@1D = Body@ground = 1, PointList → 880, 10, 12<
bd@2D = Body@crank = 2, PointList → 880, 8, 0<<, InitialGuess → 880, 10, 12<, 81, 0, 0, 0<
The body properties are incorporated into the model. In[50]:= SetBodies@bd@groundD, bd@crankD, bd@conrodD, bd@sliderDD
Constraints Five constraints, one of which is a driving constraint, are used to model the space-crank mechanism. These constraints are simply standard Mech constraints that will be replaced with generalized coordinate constraints shortly. • A ProjectedAngle1 constraint specifies the angular relationship between a line on the ground body and a line on the crank. This driving constraint is used to rotate the crank. • A Revolute5 constraint forces the axis of the crank to be coincident with its pivot axis on the ground.
MechanicalSystems
412
• A Spherical3 constraint between the crank and the connecting rod models a ball joint. • An OrthoRevolute4 constraint between the slider and the connecting rod models a universal joint. This is used instead of a Spherical3 constraint so as to constrain the spin of the connecting rod about its own longitudinal axis. • A Translate5 constraint between the slider and the ground allows translation of the slider. Here are the constraint objects for the space-crank mechanism. In[51]:= cs@1D = ProjectedAngle1@1, Vector@crank, YD,
Vector@ground, YD, Vector@ground, XD, 2 N@πD TD; cs@2D = Revolute5@2, Axis@crank, 0, XD, Axis@ground, 1, XDD; cs@3D = Spherical3@3, Point@crank, 1D, Point@conrod, 0DD; cs@4D = OrthoRevolute4@4, Axis@conrod, 1, YD, Axis@slider, 0, ZDD; cs@5D = Translate5@5, Axis@slider, 0, X, YD, Axis@ground, 0, X, YDD;
The constraints are incorporated into the model. In[56]:= SetConstraints@Array@cs, 5DD
Runtime The model can now be run through its range of motion by varying T with the SolveMech command. The numerical value of T specifies the angle of rotation of the crank in revolutions.
The model is run at T = 0.05. In[57]:= [email protected]
Out[57]= 8T → 0.05, X2 → 0., Y2 → 10., Z2 → 12., Eo2 → 0.987688, Ei2 → 0.156434,
Ej2 → −8.28157 × 10−24 , Ek2 → 5.22878 × 10−23 , X3 → −8.47033 × 10−22 , Y3 → 17.6085, Z3 → 14.4721, Eo3 → 0.903944, Ei3 → 0.0893987, Ej3 → 0.232451, Ek3 → −0.347649, X4 → 19.5064, Y4 → 0., Z4 → 0., Eo4 → 1., Ei4 → 0., Ej4 → 0., Ek4 → 0.<
Chapter 11: Generalized Coordinates
413
Here is the slider-crank model at T = 0.05.
Generalized Coordinate Constraints Now one of the standard constraints is replaced with a generalized coordinate constraint. Constraint 2, the revolute joint that models the rotational axis of the crank, is replaced first, and body 2 becomes a slave to the ground body, represented by the single coordinate alpha. Note that the arguments to the GenRevolute5 constraint are exactly the same as the arguments to the Revolute5 constraint, with the addition of the new symbol alpha and its initial guess.
Here is the new constraint.
In[58]:= cs@2D = GenRevolute5@2, Axis@crank, 0, XD, Axis@ground, 1, XD, 8alpha, 0.0
SetConstraints@Array@cs, 5DD
MechanicalSystems
414
The modified model is run again at T = 0.05. In[60]:= [email protected]
Out[60]= 8T → 0.05, X3 → 0., Y3 → 17.6085, Z3 → 14.4721, Eo3 → 0.903944,
Ei3 → 0.0893987, Ej3 → 0.232451, Ek3 → −0.347649, X4 → 19.5064, Y4 → 0., Z4 → 0., Eo4 → 1., Ei4 → 0., Ej4 → 0., Ek4 → 0., alpha → 0.314159<
Note that all of the symbols associated with body 2 are no longer included in the solution rules returned by SolveMech. The location of body 2 is represented entirely by alpha, which is the rotation angle of the crank in full revolutions. The definition (and hence the numerical value) of alpha is dependent on the relative reference directions of the two axis objects passed to GenRevolute5. Since the reference directions were not explicitly specified in the axis objects, default reference directions were assumed by Mech (the local y axes of each body, in this case). Only two more of the standard Mech constraints in this model can be replaced with generalized coordinate constraints. This is because each generalized coordinate constraint creates a slave body, and a slave body can be a slave to only one master body. Thus, there is no way to use more than three generalized coordinate constraints in a model with only three bodies.
Here are two more new constraints. In[61]:= cs@4D = GenOrthoRevolute4@4, Axis@conrod, 1, YD,
Axis@slider, 0, ZD, 8beta, −1.0<, 8gamma, 1.0
The modified model is run again at T = 0.05. In[64]:= [email protected]
Out[64]= 8T → 0.05, alpha → 0.314159, beta → −0.836491, gamma → 0.503398, delta → 19.5064<
Now the 21 Cartesian and Euler coordinates have been replaced with the four generalized coordinates alpha, beta, gamma, and delta. A quick degree of freedom count shows that this all makes sense: the three generalized coordinate constraints add a total of four degrees of freedom to the model, while the two remaining standard constraints Spherical3 and ProjectedAngle1 constrain a total of four degrees of freedom. The physical meaning of the new coordinates is somewhat confusing: alpha is simply the angle between the global Y axis and the local y axis of the crank, and delta is the X direction distance from the global
Chapter 11: Generalized Coordinates
415
origin to the origin of the slider. beta and gamma are two angles that represent the rotation of the connecting rod with respect to the slider: beta is the altitude angle, the angle between a horizontal plane and a vector down the axis of the connecting rod, and gamma is the azimuth angle, the rotation of the connecting rod axis about the global Z axis. Finally, to reduce the mathematical model of the space-crank mechanism to the absolute minimum size, constraint 1 (the ProjectedAngle1 constraint) must be reexamined. This constraint uses a rather complicated expression relating the directions of three vectors to specify the rotation of the crank, but it is known that the rotation of the crank can be directly specified by alpha. While Mech attempts to simplify constraint expressions to some extent, the algebraic expression generated by constraint 1 is more complicated than it could be.
Here is the expression that results from constraint 1. In[65]:= Constraints@1D
Out[65]= 8−[email protected] TD Sin@alphaD + Cos@alphaD [email protected] TD<
Constraint 1 really just sets alpha equal to 2 Pi T, which can be done more directly with the all-purpose constraint function Constraint.
Here is a simplified functional replacement for constraint 1. In[66]:= Constraint@1, alpha
2 N@πD TD
Out[66]= SysCon@Constraint, 1, <>D
Output and Graphics Functions Now that we have a solution in terms of generalized coordinates, all of the standard Mech output and graphics functions allow it to be used in the same manner as a solution in terms of Cartesian and Euler coordinates. For example, the location of a point is still found with the Location function and the spatial orientation of a body is found with Rotation. The symbolic expressions returned by these functions reflect the new coordinate system being used, but the numerical results are equivalent.
MechanicalSystems
416
Here are the Cartesian coordinates of a point at the center of the connecting rod.
In[67]:= Location@conrod, 815, 0, 0
% ê. LastSolve@D
Out[67]= 8delta + 15 Cos@gammaD Sin@betaD, 15 Cos@betaD Cos@gammaD, 15 Sin@gammaD< Out[68]= 89.7532, 8.80423, 7.23607<
The location of the point on the connecting rod is a function of beta, gamma, and delta, but not alpha. This is because of the master-slave relationship of the generalized coordinate bodies; the connecting rod is a slave to the slider, which is a slave to the ground. Thus, the location of any point on the connecting rod is a function of the generalized coordinates of the slider and the connecting rod, while the location of any point on the crank is a function of only alpha.
Here is the global rotation angle of the crank. In[69]:= crrot = Rotation@crankD
crrot ê. LastSolve@D
Out[69]= 8alpha, 81, 0, 0<<
Out[70]= 80.314159, 81, 0, 0<<
Mech graphics functions also operate without regard to the use of generalized coordinates. The following graphics object will generate the same image with any of the three constraint formulations used in the preceding example.
Here is the graphics object representing the space-crank model. [email protected], Line@88−1, −5, 0<, 8−1, 18, 0<, 835, 18, 0<, 835, −5, 0<, 8−1, −5, 0<, 8−1, −5, 22<, 8−1, 18, 22<, 8−1, 18, 0<
In[71]:= graph := Graphics3D@8
Chapter 11: Generalized Coordinates
417
This shows the graphic at T = 0.15.
In[72]:= Show@graph ê. [email protected]
Out[72]= h Graphics3D h
11.2 Loads and Reactions This section deals with issues related to applying loads to mechanisms modeled with generalized coordinates, and finding the reaction forces associated with those coordinates.
11.2.1 Applied Loads Using generalized coordinates has almost no effect on the modeling of applied loads. The standard Mech load functions Force, Moment, Gravity, and GyroMoment are used to apply loads to a generalized coordinate slave body in exactly the same way as they are used with standard bodies. The one load function that is affected by the use of generalized coordinates is Load, which is used to apply a load directly to a specified coordinate.
MechanicalSystems
418
Since Load references the coordinates in a model directly by their symbolic name, it can be used to apply a load directly to a generalized coordinate. Conversely, Load cannot be used to apply a load directly to a Cartesian coordinate of a slave body because a slave body doesn’t have any explicit Cartesian coordinates. For example, suppose a model has two bodies, 2 and 3, and body 3 is a slave to body 2. The two bodies are joined by a revolute joint and the symbol alpha represents the rotation of the slave, relative to the master. The Force function may be used to apply a force in the global X direction to the slave, but the Load function may not.
This loads the Modeler2D packages and defines names for bodies 2 and 3. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
master = 2; slave = 3;
Here is a load object that applies a 10-unit force to the slave body.
In[4]:= Force@slave, Axis@slave, 0, 81, 0D
This load object does not apply the 10-unit force to the slave body, because X3 is not a coordinate in the model. In[5]:= Load@X3, 10D Out[5]= SysLoad@Load, X3, <>D
However, the Load function can be used to apply a moment to the slave body because the generalized coordinate alpha is an angular coordinate. A load applied directly to alpha essentially applies a counterclockwise moment to the slave body, and a clockwise moment to the master.
Here is a load object that applies a 10-unit moment to the slave, and an equal and opposite moment to the master. In[6]:= Moment@slave, master, 10D
Out[6]= SysLoad@8Moment, Moment<, 83, 2<, <>D
Chapter 11: Generalized Coordinates
419
Here is a simpler load object that applies the same 10-unit couple between the slave and master. In[7]:= Load@alpha, 10D Out[7]= SysLoad@Load, alpha, <>D
In general, the Load function should be used instead of Force or Moment whenever possible because the resulting algebraic expressions that are added to the model can be much simpler.
11.2.2 Constraint Reactions While the use of generalized coordinates has little effect on the application of loads to a model, finding constraint reaction forces is another matter. When a constraint is eliminated from a model by using generalized coordinates, information regarding the reaction forces at the constraint is lost. This is one basic disadvantage of a reduced coordinate system; by algebraically eliminating coordinates from a model we lose information about those coordinates. Thus, three restrictions are placed on models using generalized coordinates: the Reaction function cannot be used to find the reaction forces applied by a generalized coordinate constraint to any body (because it is not really a constraint), the Reaction function cannot be used to find the reaction forces applied by any constraint to a generalized coordinate slave body (because the body doesn’t have Cartesian coordinates), and the Loads function cannot be used to find the loads applied to a slave body (for the same reason). Both the Reaction and Loads functions may still be used with generalized coordinates, but they must be used to access the coordinates directly.
MechanicalSystems
420
Reaction[cnum, sym]
returns the generalized reaction applied by constraint cnum to generalized coordinate sym. The physical meaning of the returned scalar load is dependent on the nature of the generalized coordinate sym.
Loads[sym]
returns the total external generalized load applied to generalized coordinate sym.
Loads[sym, Type → Reaction]
returns the total generalized reaction load applied by all constraints to coordinate sym.
Loads[sym, Type → Dynamic]
returns the total generalized inertial load applied to coordinate sym.
Alternate usages of Reaction and Loads.
The physical meaning of the quantities returned by Reaction and Loads is quite clear, in the context of the simple generalized coordinate constraints. If the generalized coordinate sym represents an angle in radians, then the loads on the coordinate are in consistent units of moment. If the coordinate sym represents a distance, then the loads on the coordinate are in consistent units of force. However, if abstract user-defined generalized coordinate constraints are used, the generalized loads may have little physical meaning, just like the generalized loads associated with each constraint (Λ1, Λ2, …) sometimes have little physical meaning. The one meaning that always applies to a generalized load is this: a generalized load multiplied by a small variation in its associated generalized coordinate is equal to a small variation in work, in consistent energy units.
11.2.3 Slider-Crank Example Mechanism To demonstrate the use of the Reaction and Loads functions with generalized coordinates a planar model of a simple slider-crank mechanism is developed. This model uses only two bodies, the slider and crank, and it is modeled with two generalized coordinates, the rotation angle of the crank and the X displacement of the slider.
Chapter 11: Generalized Coordinates
421
This loads the Modeler2D packages and defines some useful constants. In[8]:= Needs@"MechanicalSystems`Modeler2D`"D
Off@General::"spell1"D X = 81, 0<; Y = 80, 1<;
Here is the slider-crank mechanism.
y
y x 2
3
x
Bodies Two body objects are defined for the slider-crank model. Inertia properties are defined for each moving body so that the dynamic reaction forces can be calculated. No local point definitions are made in the body objects. All necessary point coordinates in this model are given explicitly in the constraint functions.
Here are the body objects for the slider-crank model. In[12]:= ground = 1;
bd@2D = Body@crank = 2, Mass → 200.0, Inertia → 450.0D; bd@3D = Body@slider = 3, Mass → 25.0, Inertia → 0.02D;
The body properties are incorporated into the model. In[15]:= SetBodies@bd@crankD, bd@sliderDD
MechanicalSystems
422
Constraints Four constraints are used to model the slider-crank mechanism. Two generalized coordinate constraints are used along with two standard constraints. • A GenRevolute2 constraint defines the symbol alpha as the angular coordinate of the crank. • A RotationLock1 constraint controls the rotation of the crank. • A GenTranslate2 constraint defines the symbol beta as the displacement coordinate of the slider. • A RelativeDistance1 constraint models the connecting rod between the crank and the slider. Here are the constraint objects for the slider-crank mechanism.
In[16]:= cs@1D = GenRevolute2@1, Axis@crank, 0, XD, Axis@ground, 0, XD, 8alpha, 0.0
cs@2D = RotationLock1@2, crank, 2 N@πD TD; cs@3D = GenTranslate2@3, Axis@slider, 0, XD, Axis@ground, 0, XD, 8beta, 5.0
The constraints are incorporated into the current model. In[20]:= SetConstraints@Array@cs, 4DD
Loads A force that is a linear function of slider position is applied to the slider to simulate a simple spring. The spring has a spring constant of 10, and it is placed so that the spring force is zero when the X displacement of the slider is three units.
Here is a spring force applied to the slider.
In[21]:= SetLoads@ld@1D = Load@beta, −10 Hbeta − 3LDD
The model is run at T = 0.1 with the Static option to cause the Lagrange multipliers to be calculated. In[22]:= [email protected], Solution → StaticD
Out[22]= 8T → 0.1, alpha → 0.628319, beta → 4.9147, Λ1 → 33.5562, Λ2 → −2.904<
Chapter 11: Generalized Coordinates
423
Reactions Because generalized coordinates were used in this model, Mech’s ability to find constraint reaction forces is limited. Normally, Reaction could be used to find the reaction force vector that the revolute joint applies to the crank, but with this model only the moment applied to the crank by constraint 2 can be found. Note that Reaction cannot directly find the moment applied to body 2, it can only find the generalized force associated with the symbol alpha. Since alpha is an angular coordinate, its associated load is a moment. Here is the moment applied to the crank by the driving constraint.
In[23]:= Reaction@2, alphaD ê. LastSolve@D Out[23]= −33.5562
Of course constraint 4, the RelativeDistance1 constraint, applies an equal and opposite moment to the crank. Here is the moment applied to the crank by the connecting rod. % ê. LastSolve@D
In[24]:= Reaction@4, alphaD Out[24]= −Λ2 H8 Cos@alphaD Sin@alphaD − 4 H−beta + 2 Cos@alphaDL Sin@alphaDL Out[25]= 33.5562
Constraint 4 also applies a reaction force to the slider. Again, the restraining force and torque that would be applied to the slider by a normal Translate2 constraint cannot be found. Only the generalized force associated with beta can be found, which is the X direction force on the slider. Here is the force applied to the slider by the connecting rod.
In[26]:= Reaction@4, betaD ê. LastSolve@D Out[26]= 19.147
Here are the external loads applied to the coordinates alpha and beta. In[27]:= Loads@AllD
Out[27]= 80, −10 H−3 + betaL<
MechanicalSystems
424
The inertia terms are automatically converted into the proper coordinate system so that the dynamic reaction forces may be calculated. The Solution → Dynamic option causes SolveMech to include the inertial loads and calculate the reaction forces.
Here is a plot of the torque required to drive the crank through a full cycle.
In[28]:= ListPlot@8alpha, Reaction@2, alphaD< ê. SolveMech@80, 1<, 41, Solution → DynamicD,
PlotJoined → TrueD
3000 2000 1000 1
2
3
4
5
6
-1000 -2000 -3000
Out[28]=
Graphics
Here is the graphics function that generates the image of the slider-crank mechanism. In[29]:= graph := Graphics@8
[email protected], Line@881, −2.2<, 80, 0<, 8−1, −2.2<, 85.5, −2.2<, 85.5, −.25<, 81.5, −.25<
Chapter 11: Generalized Coordinates
425
Here is the slider-crank mechanism at T = 0.35.
In[30]:= Show@graph ê. [email protected]
y x 2
3
x
y
Out[30]= h Graphics h
11.3 Dynamic Modeling This section covers topics related to generalized coordinate modeling of dynamic systems. Dynamic motion synthesis is often where generalized coordinates have their greatest payoff. Using a coordinate system that is closer to being a minimal and independent set can drastically reduce the size of the mass matrix and centrifugal force vector, resulting in reduced runtimes for the numerical integration routine. The reduced mass matrix, in terms of generalized coordinates, is often useful in its own right for certain types of analysis. Examples of various mass matrix manipulations are presented in this section, including the conversion of an open-loop mass matrix to endpoint coordinates, and the reduction of a closed loop mass matrix to minimal coordinates.
11.3.1 Two-Link Manipulator Example It is often useful to find the mass matrix of a model with respect to an alternative coordinate system. When generalized coordinates are used, Mech automatically generates the model’s mass matrix in terms of the specified coordinates, and converting the mass matrix to another consistent coordinate system is a straightforward process.
MechanicalSystems
426
An open-loop two-link manipulator model is developed to demonstrate the conversion of a mass matrix from one coordinate system to another. The model has two moving bodies, link 1 and link 2, which are represented by two generalized coordinates, alpha and beta. The alpha coordinate represents the rotation angle of link 1 relative to the ground and beta represents the rotation of link 2 relative to link 1.
This loads the Modeler2D packages and defines some useful constants. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Off@General::"spell1"D X = 81, 0<; Y = 80, 1<;
Here is a graphic of the two-link manipulator model. 7 y
6
F
5
3
4 x
y
3
x
2
2
1 0 -1 -2
0
2
4
6
Bodies Two body objects are used in the manipulator model. Each body object is used only to define inertia properties for the body, no local point definitions are made. Thus the ground (body 1) needs no body object because its inertia is immaterial. Note that the lengths of the links are left as parameters L1 and L2, causing the resulting mass matrix to be completely general.
Chapter 11: Generalized Coordinates
427
Here are the body objects for the manipulator model. In[5]:= ground = 1;
link1 = 2; link2 = 3; bd@2D = Body@link1, Mass → 1, Inertia → 3, Centroid → 8L1 ê 2, 0
The inertia properties are incorporated into the model. In[10]:= SetBodies@bd@link1D, bd@link2DD
Constraints Four constraint objects are used to model the manipulator. Two constraints are generalized coordinate constraints that introduce the two degrees of freedom, alpha and beta, and the other two constraints simply constrain these two degrees of freedom. • A GenRevolute2 constraint sets up the relationship between link 1 and the ground. • A GenRevolute2 constraint sets up the relationship between link 2 and link 1. • Two Constraint objects constrain alpha and beta to be equal to the parameters q1 and q2. Note that L1 appears explicitly in constraint 3 to locate the tip of link 1 where it is attached to link 2.
Here are the constraint objects for the manipulator.
In[11]:= cs@1D = GenRevolute2@1, Axis@link1, 0, XD, Axis@ground, 0, XD, 8alpha, 0
cs@2D = Constraint@2, alpha q1D; cs@3D = GenRevolute2@3, Axis@link2, 0, XD, Axis@link1, 8L1, 0<, XD, 8beta, 0
The constraints are incorporated into the current model. In[15]:= SetConstraints@Array@cs, 4DD
MechanicalSystems
428
Mass Matrix The kinematics of this model are truly trivial. The entire constraint set is nothing more than a pair of expressions setting alpha and beta equal to q1 and q2. There is really no point in running the model at all, in the normal sense in which other Mech models are run because the configuration of the model can be specified directly by alpha and beta. The usefulness of the model lies in the other definitions that have been made by Mech for inertia properties and coordinate transformations.
Here is the constraint vector. In[16]:= Constraints@AllD
Out[16]= 8alpha − q1, beta − q2<
Here is the global location of the tip of link 2.
In[17]:= link2tip = Location@link2, 8L2, 0
Out[17]= 8L1 Cos@alphaD + L2 Cos@alpha + betaD, L1 Sin@alphaD + L2 Sin@alpha + betaD<
Here is the 2 µ 2 system mass matrix. In[18]:= m = Simplify@MassMatrix@AllDD Out[18]= 99
1 1 H24 + 5 L12 + L22 + 4 L1 L2 Cos@betaDL, H12 + L22 + 2 L1 L2 Cos@betaDL=, 4 4 L22 1 == 9 H12 + L22 + 2 L1 L2 Cos@betaDL, 3 + 4 4
Chapter 11: Generalized Coordinates
429
Endpoint Mobility Now we wish to find the ellipse of mobility of the endpoint of link 2. The ellipse of mobility of an equivalent two-link manipulator model was found in Section 10.3. In that example, a one unit force was applied to the endpoint of link 2 while varying the direction of the force through 360 degrees, and the resulting free acceleration vector of the endpoint was found with the SetFree and SolveFree functions. This section presents a more elegant method of finding the ellipse of mobility directly from the mass matrix. The method presented in Section 10.3 is much more general than this one in that this method (as it is presented here) is restricted to finding the mobility of the endpoint at zero velocity, and is restricted to models that have the same total number of coordinates as the number of physical degrees of freedom of the endpoint. The basic trick here is to convert the mass matrix from the generalized (joint angle) coordinates to endpoint coordinates. The mass matrix m, in the context of f = m.a, transforms accelerations of the generalized coordinates a, which are the relative angular accelerations of each of the joints, into forces on the generalized coordinates f, which are moments applied at the joints. We need to have a matrix P in P.F = A, which transforms a force vector F applied to the endpoint into the linear acceleration vector A of the endpoint. First, we need a transformation matrix J from generalized coordinates to endpoint coordinates such that A = J.a. Then P = J.Inverse[m].Transpose[J]. The matrix J is the Jacobian of the global coordinates of the endpoint.
Here is the transformation matrix J.
In[19]:= J = Outer@D, link2tip, 8alpha, beta
pha + betaD, −L2 Sin@alpha + betaD<, ha + betaD, L2 Cos@alpha + betaD<<
Here is the inverse endpoint mass matrix P, a rather large symbolic matrix. In[20]:= P = [email protected]@JD;
We can now find the acceleration of the endpoint that results from any force vector at any particular configuration simply by multiplying P times the force vector.
MechanicalSystems
430
Here is the acceleration vector resulting from an applied force {0, 2}. In[21]:= config = 9alpha →
N@πD
P.80, 2< ê. config
6
, beta →
2 N@πD 3
, L1 → 6, L2 → 6=;
Out[22]= 82.26741, 4.58182<
Now finding the ellipse of mobility is simply a matter of applying a unit force vector that revolves through a full circle and plotting the components of the resulting acceleration.
Here is the ellipse of mobility.
In[23]:= ParametricPlot@[email protected]@81, ang
Epilog → 8Line@880, 0<, P.X ê. config
-1.5
-1
-0.5
0.5 -1 -2
Out[23]=
Graphics
1
1.5
Chapter 11: Generalized Coordinates
431
11.3.2 Four-Bar Example Another useful manipulation of the mass matrix is to find a minimal mass matrix for a model with a nonminimal coordinate system. While this can theoretically be done with or without generalized coordinates, it often becomes intractable when modeling in Cartesian coordinates because of the need to invert a large symbolic matrix. The four-bar model that was developed previously in this section is used again here to demonstrate the formulation of a minimal mass matrix. In this case, the minimal mass matrix is a 1 µ 1 matrix because the four-bar model has only one degree of freedom. Since the four-bar mechanism is modeled with three generalized coordinates alpha, beta, and gamma, the default mass matrix generated by Mech is a 3 µ 3 matrix; the task at hand is to reduce it to 1 µ 1. Note that inertia properties are included in the body objects of this version of the four-bar.
This clears all data in the current Mech model. In[24]:= ClearMech@D
Bodies and Constraints The entire four-bar model is redefined without explanation here, because its kinematics are completely documented in Section 8.3.2.
Here are the body objects for the four-bar model. In[25]:= SetBodies@
bd@1D = Body@ground = 1, PointList → 88−2, 3<
MechanicalSystems
432
Here are the generalized coordinate constraint objects. In[26]:= SetConstraints@
cs@1D = RotationLock1@1, drivebar, 2 N@πD TD, cs@2D = GenRevolute2@2, Axis@drivebar, 0, XD, Axis@ground, 0, XD, 8alpha, 0.0
Mass Matrix We intend to transform the 3 µ 3 system mass matrix M into a 1 µ 1 mass matrix m where f = m.alphadd and f is the generalized force in the direction of alpha, which is simply a counterclockwise moment applied to the drive bar. This transformation is of the form m = Transpose[J] . M . J. The necessary transformation matrix J converts motions in all three generalized coordinates into motions of the single coordinate alpha. This matrix J is created by inverting the part of the model’s Jacobian associated with beta and gamma and multiplying it by the part associated with alpha. The resulting 2 µ 1 matrix converts alpha only into beta and gamma, so it must be prepended with a 1 to convert alpha into all three coordinates. Only the part of the Jacobian associated with constraint 5 is included in the calculation because the driving constraint (constraint 1) must be dropped for the model to have more than zero degrees of freedom, and the other three generalized coordinate constraints contribute no constraint equations. Here is the 3 µ 1 transformation matrix J.
In[27]:= J = Prepend@−Inverse@Jacobian@5, 8beta, gamma
Here is the 3 µ 3 system mass matrix. In[28]:= M = Simplify@MassMatrix@AllDD
Out[28]= 88−2 H−29 + 6 Cos@beta + gammaD + 6 Sin@betaD + 18 Sin@gammaDL,
52 − 6 Cos@beta + gammaD − 6 Sin@betaD − 36 Sin@gammaD, 22 − 6 Cos@beta + gammaD − 18 Sin@gammaD<, 852 − 6 Cos@beta + gammaD − 6 Sin@betaD − 36 Sin@gammaD, 52 − 36 Sin@gammaD, 22 − 18 Sin@gammaD<, 822 − 6 Cos@beta + gammaD − 18 Sin@gammaD, 22 − 18 Sin@gammaD, 22<<
Chapter 11: Generalized Coordinates
433
Here is the 1 µ 1 mass matrix in terms of the coordinate alpha. In[29]:= m = [email protected];
Since m is a 1 µ 1 matrix it may as well be a scalar, and the acceleration that results from applying a moment to the drive bar is simply alphadd = f/m. Remember that m is still a function of alpha, beta, and gamma, and not just any set of alpha, beta and gamma will do (unlike the two-link manipulator in which any values of the coordinates could be specified). SolveMech must be used to find a set of coordinates that represents a valid configuration of the four-bar model. The 1 µ 1 matrix m is converted to a scalar. In[30]:= m = mP1, 1T;
Here is the configuration of the four-bar model at 1/8 turn of the drive bar. In[31]:= config = SolveMechA Out[31]= 9T →
1 8
E
1 , alpha → 0.785398, beta → −0.855504, gamma → 0.305521= 8
Here is the acceleration that results from a 10-unit moment applied to the drive bar. In[32]:= a =
10 m
ê. config
Out[32]= 2.16888
Dynamic Motion The constrained dynamic motion profile of the four-bar model can be found with the SetFree and Solve Free functions, as described in Chapter 10. In this example, the drive bar is given an initial angular velocity of 2 pi radians/second, a condition that is inherent in the definition of constraint 1. Constraint 1 is dropped from the model, and the free motion of the underconstrained system is found.
The model is run at T = 0 to make initial conditions available to SetFree. In[33]:= SolveMech@0, Solution → VelocityD;
MechanicalSystems
434
Here is the FreeSystem object that contains the dynamical equations of motion, with constraint 1 dropped. In[34]:= fsys = SetFree@1, Solution → DynamicD Out[34]= FreeSystem@Dynamic, <>D
The FreeSystem object fsys is integrated in the time domain from T = 0.0 to 2.0 with SolveFree. All initial conditions for the integration are taken from the most recent solution returned by SolveMech.
Here is the time domain solution. In[35]:= sol = SolveFree@fsys, 1.0D
Out[35]= 8alpha → InterpolatingFunction@880., 1.<<, <>D@TD,
beta → InterpolatingFunction@880., 1.<<, <>D@TD, gamma → InterpolatingFunction@880., 1.<<, <>D@TD<
Here is a plot of the angular velocity of the drive bar through approximately one full revolution of the drive bar.
In[36]:= Plot@Evaluate@∂T Halpha ê. solLD, 8T, 0., 1.
6.2
0.2 5.8 5.6 5.4 5.2 Out[36]=
Graphics
0.4
0.6
0.8
1
12. Performance Improvement Overview This chapter is intended to help the user improve the performance of kinematic and dynamic models built with MechanicalSystems. The symbolic mathematical systems that are generated by Mech can become quite large, causing their evaluation to proceed very slowly. There is no single trick that will speed up the evaluation of all Mech models, except buying a faster computer, and a technique that successfully accelerates one type of model may have the opposite affect on another. However, attention to the guidelines in the following sections will generally prevent the user from building a particularly bad model, and may lead to large reductions in run time.
12.1 Updating Solutions The simplest way to get a MechanicalSystems model to run faster is to ask it to do less work. This is usually accomplished by keeping track of and reusing results that have already been obtained, instead of generating them again. When mechanism velocity or acceleration data is needed, or static or dynamic constraint reaction forces, the complete location solution must first be calculated. If this has already been done, the CheckRules option prevents Mech from doing it again.
CheckRules
is an option for SolveMech that determines whether or not solution rules passed into SolveMech are assumed to be an approximate solution, and are thus to be used as initial guesses, or are assumed to constitute a valid solution to the model. The default setting is CheckRules → True.
An option for SolveMech.
MechanicalSystems
436
If CheckRules → False is specified, the solution rules that are passed to SolveMech are not checked against the constraints, they are simply passed to the next phase of the solution block. This is useful if a set of lower-order solution rules has already been obtained (e.g., location solution) and a set of higher-order (i.e., velocity or acceleration) rules is desired. The following example uses a spatial slider-crank model to demonstrate the time savings that can be realized by updating higher-order solutions without regenerating lower-order data. The example mechanism consists of two bodies, a crank and a slider, and a connecting rod that is simply a distance constraint. No initial guesses are needed for the model because both the crank and the slider are initially coincident with the local origin.
Here is an entire slider-crank model built in one step. In[1]:= Needs@"MechanicalSystems`Modeler3D`"D
ground = 1; crank = 2; slider = 3; SetConstraints@cs = 8 Revolute5@1, Axis@crank, 0, 81, 0, 0
Here is a solution to the model near T = 0. In[6]:= [email protected]
Out[6]= 8T → 0.05, X2 → 0., Y2 → 0., Z2 → 0., Eo2 → 0.987688, Ei2 → 0.156434, Ej2 → 0.,
Ek2 → 0., X3 → −0.0817955, Y3 → 0., Z3 → 0., Eo3 → 1., Ei3 → 0., Ej3 → 0., Ek3 → 0.<
To show the difference between regenerating solutions, updating solutions, and updating solutions without checking validity, a series of location solutions are generated and then updated to velocity solutions.
Chapter 12: Performance Improvement
437
This generates 21 solutions to the model as time goes from 0 to 1. In[7]:= postab = SolveMech@80, 1<, 21D;
This generates the complete location and velocity solution at 21 points. In[8]:= SetGuess@D;
Timing@veltab = SolveMech@80, 1<, 21, Solution → VelocityD;D
Out[9]= 80.28 Second, Null<
This generates the complete location and velocity solution using the location rules already calculated as initial guesses at each step. In[10]:= Timing@veltab = SolveMech@postab, Solution → VelocityD;D Out[10]= 80.11 Second, Null<
This generates only the new velocity solution using the location rules already calculated without checking that they in fact satisfy the constraints. In[11]:= Timing@veltab = SolveMech@postab, Solution → Velocity, CheckRules → FalseD;D Out[11]= 80.07 Second, Null<
This same technique can be used to update a location solution to a static solution, or any other combination of the solution levels generated by SolveMech. If CheckRules → False is specified, the only part of the solution that is actually calculated anew is the part explicitly requested by the solution option, and any parts of the solution that are not present in the solution rules that are to be updated.
MechanicalSystems
438
12.2 Simplifying Expressions This section covers some of the ways that a MechanicalSystems model can be algebraically simplified to improve performance.
12.2.1 Local Coordinate Choices MechanicalSystems allows considerable flexibility in defining geometric constraints and forcing functions. The points and lines that are used to make up these elements can be located anywhere in the local coordinate system of any body in the model. However, all points are not created equal, in terms of efficiency, and choosing a more complicated representation of a geometric relationship over a simpler one can result in large changes in the time required to run a model. In general, it is best to use the local origin of a body whenever possible in defining constraint or load functions because the local origin is represented by a much simpler expression than a non-origin point. When the local origin cannot be used, the more zeros there are in the local coordinates of a point, the better. Here are the symbolic representations of three points on the crank.
In[12]:= Location@crank, 80, 0, 0
Location@crank, 81, 0, 0
Out[12]= 8X2, Y2, Z2< Out[13]= 92 J−
1 + Ei22 + Eo22 N + X2, 2 HEi2 Ej2 + Ek2 Eo2L + Y2, 2 HEi2 Ek2 − Ej2 Eo2L + Z2= 2
Out[14]= 96 HEi2 Ek2 + Ej2 Eo2L + 4 HEi2 Ej2 − Ek2 Eo2L + 2 J−
1 + Ei22 + Eo22 N + X2, 2 1 6 HEj2 Ek2 − Ei2 Eo2L + 2 HEi2 Ej2 + Ek2 Eo2L + 4 J− + Ej22 + Eo22 N + Y2, 2 1 4 HEj2 Ek2 + Ei2 Eo2L + 2 HEi2 Ek2 − Ej2 Eo2L + 6 J− + Ek22 + Eo22 N + Z2= 2
Obviously, it takes less time to evaluate the first of these three expressions than it does to evaluate the others. Further, since all points on the ground body are constant, use points on the ground body over points on other bodies whenever possible, even over the local origins of the other bodies.
Chapter 12: Performance Improvement
439
These guidelines also apply to the definition of Line, Plane, and Axis objects; use the ground body if possible. However, it is usually better to use two or three points on the same body to define a Line or Plane object than it is to use one point on the ground and other points on another body. Finally, one point where the relative simplicity of the local origin is of great importance is in the location of the centroid of a dynamic model. While Mech does allow the centroid to be placed arbitrarily on a body, moving the centroid off of the local origin of a body results in a great increase in the complexity of the model’s mass matrix. The mass matrix of a 3D body in local coordinates is a 6 µ 6 block diagonal constant matrix (completely diagonal if the products of inertia are zero), if the centroid is located at the local origin. If the centroid is moved off of the local origin, the mass matrix becomes a 6 µ 6 nonconstant full matrix. This is especially important when integrating the equations of motion, when the mass matrix must be evaluated at every time step.
12.2.2 Constraint and Load Choices The entire set of constraint functions provided by Mech is quite redundant. Almost any geometric constraint can be duplicated by some other constraint or combination of constraints. However, the algebraic expressions generated by functionally identical constraints can be quite different. It is important to use the simplest possible representation of a mechanism joint to reduce the size of the model. The one time when a more complicated constraint set should be considered is when it is possible to remove a body from a model by replacing the entire body with a compound constraint. The OrthoRevolute4 and ParaRevolute4 constraints in Modeler3D are good candidates for replacing entire bodies in a model, as is the RelativeDistance1 constraint that is commonly used to replace a connecting rod. It is often possible to eliminate multiple bodies, even interlinked bodies, with a correctly chosen compound constraint. A body cannot be eliminated from a mechanism when the inertia of the body is relevant to the analysis. But even this has an exception: the gyroscopic forces associated with a body that is spinning rapidly about an axis of symmetry can be duplicated by a GyroMoment forcing function, thus eliminating the body itself from the model.
440
MechanicalSystems
12.2.3 Simplifying with Mathematica After the constraints and loads used to build the Mech model have been chosen as carefully as possible to simplify the model, Mathematica’s Simplify or Expand functions can be applied to all of the internal expressions generated by Mech by setting $MechProcessFunction equal to Simplify, Expand, TrigEx pand, or any other routine designed to simplify expressions or optimize them for efficient evaluation. Because many of the internal expressions generated by MechanicalSystems are very large, applying Sim plify to all of them can be quite computationally expensive in itself. The performance of SetCon straints and related model-building functions can be degraded significantly in exchange for better performance from SolveMech.
This will cause Simplify and Chop to be applied to all internal expressions generated by Mech. In[15]:= $MechProcessFunction = Chop@Simplify@#DD & Out[15]= Chop@Simplify@#1DD &
12.3 Compiling Expressions Most MechanicalSystems functions that use an iterative Newton-Rhapson solver or numerical integration accept the Compiled option. Setting Compiled → True can result in a substantial reduction in runtime, at the expense of some increase in the time required to build the model. However, Mathematica’s ability to compile expressions is not universal. There are some types of algebraic expressions that cannot be compiled. If an algebraic expression within a Mech model contains such a form, it cannot be compiled. The spatial slider-crank model is rebuilt with the Compiled option to demonstrate the speed increase that is realized by compiling the model.
This rebuilds the constraints in compiled form. The BuildMech option forces an immediate build of the velocity equations, which prevents the time required to build them from being included in the timing. In[16]:= SetConstraints@cs, Compiled → True, BuildMech → VelocityD
Chapter 12: Performance Improvement
441
This generates the complete location and velocity solution at 21 points in about half the time that was required without the Compiled option. In[17]:= SetGuess@D;
Timing@veltab = SolveMech@80, 1<, 21, Solution → VelocityD;D
Out[18]= 80.19 Second, Null<
12.4 Coordinate Systems MechanicalSystems allows models to be built in several different coordinate systems: Euler and Angular in two dimensions, and Euler, Global Angular, and Local Angular in three dimensions. If the mechanism is planar, use a planar model because 2D models run much faster than 3D models.
12.4.1 2D Coordinate Systems There is no clear rule for the best choice of coordinate systems in planar or spatial models, with respect to minimizing run time. In 2D, it would seem that Angular would always be better, because only three constraint expressions are required per body, instead of four. But, this is largely offset by the fact that the 2D degenerate Euler coordinate system uses no trigonometric functions in the formulation of geometric constraints, and that the first and second derivatives of expressions written in terms of 2D Euler parameters are very simple.
This sets the 2D coordinate system to Angular and defines a bogus constraint so that the symbolic derivatives of the coordinates of body 2 are defined by SetConstraints. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Off@General::"spell1"D SetSymbols@Method → AngularD SetConstraints@bc = Constraint@1, 8X2
0, Y2
0, Θ2
0<, 82
MechanicalSystems
442
Here are the location and velocity of an arbitrary point in angular coordinates.
In[5]:= Location@2, 8x, y
Acceleration@2, 8x, y
Out[5]= 8X2 + x Cos@Θ2D − y Sin@Θ2D, Y2 + y Cos@Θ2D + x Sin@Θ2D<
Out[6]= 8X2dd + y H−Θ2dd Cos@Θ2D + Θ2d2 Sin@Θ2DL + x H−Θ2d2 Cos@Θ2D − Θ2dd Sin@Θ2DL,
Y2dd + x HΘ2dd Cos@Θ2D − Θ2d2 Sin@Θ2DL + y H−Θ2d2 Cos@Θ2D − Θ2dd Sin@Θ2DL<
Now the coordinate system is changed to Euler. In[7]:= SetSymbols@Method → EulerD
SetConstraints@bcD Here are the location and velocity of an arbitrary point in 2D Euler coordinates.
In[9]:= Location@2, 8x, y
Acceleration@2, 8x, y
Out[9]= 8Ei2 x + X2 − Ej2 y, Ej2 x + Ei2 y + Y2<
Out[10]= 8Ei2dd x + X2dd − Ej2dd y, Ej2dd x + Ei2dd y + Y2dd<
In conclusion, models that are to be used for acceleration analysis may run faster if the degenerate Euler coordinates are used, but they may not.
12.4.2 3D Coordinate Systems In 3D models, there is no difference between the respective coordinate systems with regard to the constraint equations alone because all 3D models must use Euler parameters to represent the angular orientation of each body. Thus, the choice of coordinate systems comes down to differences in first- and second-order expressions, and in the dynamic equations of motion. As with 2D coordinates, the first and second derivatives of expressions written in terms of 3D Euler parameters are simpler than the same expressions written in terms of angular velocities and accelerations.
Chapter 12: Performance Improvement
443
This sets the 3D coordinate system to Angular and defines a bogus constraint so that the symbolic derivatives of the coordinates of body 2 are defined by SetConstraints. In[11]:= Needs@"MechanicalSystems`Modeler3D`"D
SetSymbols@Method → AngularD SetConstraints@bc = Constraint@1, Thread@8X2, Y2, Z2, Ei2, Ej2, Ek2<
0D, 82
Here are the location and velocity of an arbitrary point in angular coordinates.
In[14]:= ByteCount@Acceleration@2, 8x, y, z
Now the coordinate system is changed to Euler. In[15]:= SetSymbols@Method → EulerD
SetConstraints@bcD Here are the location and velocity of an arbitrary point in Euler coordinates.
In[17]:= ByteCount@Acceleration@2, 8x, y, z
However, the relative sizes of the expressions generated by applied forces and moments in a static or dynamic model are also affected by the choice of coordinate system. Usually, the expressions that are generated by applied forces and moments are simpler in angular coordinates than they are in Euler coordinates.
Here is the expression that results from an applied moment in angular coordinates. In[18]:= SetSymbols@Method → AngularD
SetConstraints@bcD SetLoads@Moment@2, 81, 2, 3<, 10, Magnitude → RelativeDD Loads@2D
Out[21]= 80, 0, 0, 10, 20, 30<
MechanicalSystems
444
Here is the expression that results from the same applied moment in Euler coordinates. In[22]:= SetSymbols@Method → EulerD
SetConstraints@bcD SetLoads@Moment@2, 81, 2, 3<, 10, Magnitude → RelativeDD Loads@2D
Out[25]= 80, 0, 0, 2 H−10 Ei2 − 20 Ej2 − 30 Ek2L, 2 H−30 Ej2 + 20 Ek2 + 10 Eo2L,
2 H30 Ei2 − 10 Ek2 + 20 Eo2L, 2 H−20 Ei2 + 10 Ej2 + 30 Eo2L<
However, here is the expression that results from the same applied moment in local angular coordinates. In[26]:= SetSymbols@Method → Angular, Coordinates → LocalD
SetConstraints@bcD SetLoads@Moment@2, 81, 2, 3<, 10, Magnitude → RelativeDD Loads@2D
Out[29]= 90, 0, 0, 60 HEi2 Ek2 − Ej2 Eo2L + 40 HEi2 Ej2 + Ek2 Eo2L + 20 J−
60 HEj2 Ek2 + Ei2 Eo2L + 20 HEi2 Ej2 − Ek2 Eo2L + 40 J−
1 + Ei22 + Eo22 N, 2
1 + Ej22 + Eo22 N, 2 1 40 HEj2 Ek2 − Ei2 Eo2L + 20 HEi2 Ek2 + Ej2 Eo2L + 60 J− + Ek22 + Eo22 N= 2
If this is not yet sufficiently murky, consider that if the applied moment in the previous example was specified as a constant moment in local coordinates on body 2, the conditions of the moment expressions in local versus global angular coordinates would be reversed. The moment would be a constant in local coordinates and a function of the Euler parameters in global coordinates. In conclusion, the fastest run times usually result from matching the coordinate system to the types of applied forces and moments on the body. If the applied loads are in global coordinates, use the global coordinate system, and visa versa.
Chapter 12: Performance Improvement
445
12.5 Locking Variables The LockMech function is a special function provided by MechanicalSystems that allows the values of constant dependent variables in a model to be retained to accelerate the evaluation of large models.
LockMech[t]
finds a solution to the mechanism equations at time t and then embeds the numerical values of the model’s dependent variables into the mechanism equations so that they cannot be changed until a new model is built with SetConstraints.
Solution
is an option to specify what level of dependent variables are to be locked in. Valid settings for Solution are Location, Velocity, or Acceleration. The default setting is Solution → Location.
A special function for locking dependent variables.
LockMech replaces the dependent variables in the constraint equations with constant values so that they cannot be changed until the constraints are rebuilt. This function is useful when the model must be solved many times with different applied loads or different inertia properties, all at the same physical configuration. After LockMech has been run, the dependent variables (X2, Y2, …) in a model are replaced by numeric values so that they no longer need to be replaced at runtime, essentially eliminating the time required to replace them. To demonstrate the use of LockMech, the 3D slider-crank model that was used in Section 12.1 is redefined with applied forces.
MechanicalSystems
446
Here is an entire slider-crank model built in one step. In[1]:= Needs@"MechanicalSystems`Modeler3D`"D
ground = 1; crank = 2; slider = 3; SetConstraints@cs = 8 Revolute5@1, Axis@crank, 0, 81, 0, 0
And here are the locations of each body at T = 0.1. In[6]:= pos = [email protected]
Out[6]= 8T → 0.1, X2 → −4.7998 × 10−22 , Y2 → 0., Z2 → 0., Eo2 → 0.951057,
Ei2 → 0.309017, Ej2 → −1.92066 × 10−24 , Ek2 → 5.91117 × 10−24 , X3 → −0.321756, Y3 → 0., Z3 → 0., Eo3 → 1., Ei3 → 0., Ej3 → 0., Ek3 → 0.<
We can now add an applied force to the model and solve for the static reaction forces at several values of a parameter that affects the direction of the applied force. A valid location solution pos is passed into Solve Mech with the CheckRules → False option so that regeneration of the location solution does not occur.
This applies force to the origin of the slider with constant magnitude and variable direction.
In[7]:= SetLoads@Force@slider, Axis@slider, 0, 81, k, 0
Now the model is solved for the static reaction forces at 11 different values of k. In[8]:= Timing@
statab = Table@SolveMech@pos, Solution → Static, CheckRules → FalseD, 8k, 0, 1, .1
Out[8]= 80.05 Second, Null<
Chapter 12: Performance Improvement
447
LockMech is run to embed the location coordinates of the model into all of the equations of motion, including the load vector. In[9]:= [email protected]
BuildMech@StaticD
The model is solved again for the static reaction forces at 11 different values of k. It is not necessary to use the Check Rules option now because the constraint equations are constant.
In[11]:= Timing@statab = Table@[email protected], Solution → StaticD, 8k, 0, 1, 0.1
13. Debugging Models Overview This chapter is intended to help MechanicalSystems users to diagnose and repair common errors in mechanism models. There is a penalty to be paid for the tremendous flexibility available within any symbolic Mathematica model, that is, an equally tremendous number of ways that a model can fail. This chapter can only scratch the surface of the full breadth of possible modeling errors that can occur in a Mech model, but the basic debugging methods presented should be applicable to all models that are so afflicted.
13.1 Model Building Errors This section deals with model building errors that prevent Mech from building the constraint or load expressions or prevent the completed model from running.
13.1.1 Bad Arguments Mech functions are written with as much type checking as is possible without restricting the user from incorporating arbitrary mathematical expressions into a model. Unfortunately, this caveat means that there can be essentially no type checking on any symbolic argument that is intended to evaluate to a number. Many arguments to Mech functions are type checked, such as point and vector arguments, but since point objects and vector objects may also contain symbolic expressions buried in their local coordinates, these items cannot be rigorously type checked until runtime. The following examples show where Mech’s type checking catches bad arguments and where others slip through.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
MechanicalSystems
450
A Mech body, constraint, or load function is returned unevaluated if it is called with invalid arguments. For example, the Translate2 constraint expects a pair of axis objects that have the head Axis or Line. If Translate2 recognizes that these arguments are incorrect, the entire constraint function is returned unevaluated.
Here is a misspelled axis object. In[2]:= cs = Translate2@1,
Axxx@2, 80, 0<, 82, 0
Mech::argmcaaqe : Translate2 called with invalid arguments. Translate2@cnum, axis1, axis2D or Translate2@cnum, axis1, axis2, exprD is expected. Axes are specified by point and direction with an Axis object or by two points with a Line object. Expr must evaluate to a number.
Out[2]= Translate2@1, Axxx@2, 80, 0<, 82, 0
If a constraint function is passed the correct argument types, but the contents of these arguments are invalid, a constraint object is returned with some assumptions made about what to do with the invalid arguments. In the following example, the 3D point specification is not recognized by Modeler2D, so Point[2, {1,0,0}] is replaced with Point[2, {0,0}]. This is certainly not what the user intended, but it causes a valid constraint object to be returned.
Here is a constraint with a 3D local coordinate that should be 2D. In[3]:= cs = Revolute2@1,
Point@1, 80, 0
Mech::badlpnt : A local point spec is expected instead of 81, 0, 0< in Point@2, 81, 0, 0D
The types of errors shown above are diagnosed fairly easily. More elusive problems result when a bad value is given for arguments of type expr. When a Mech usage statement specifies that an argument of type expr is required, it means any expression that will evaluate to a number at runtime may be used. Mathematica has no way of telling in advance whether or not an expression will evaluate to a number, so these arguments cannot be type checked at all.
Chapter 13: Debugging Models
451
Here is a constraint with an unchecked expression argument. In[4]:= cs = RelativeDistance1@1,
Point@1, 80, 0
Out[4]= SysCon@RelativeDistance1, 1, <>D
The last argument to the RelativeDistance1 constraint (2 a) is supposed to evaluate to a number. If, at runtime, the symbol a evaluates to a number, then the constraint is valid. If the symbol a has no definition, or it evaluates to a List or other function at runtime, then Mech will fail. Mathematica has no way of knowing what the symbol a will do at runtime, so it cannot be type checked. Note that the first argument of a SysCon object is a list of the constraint expressions contained in the object.
Here are the constraint expressions contained in cs. In[5]:= csP1T
Out[5]= 8−4 a2 + H−X2 − Cos@Θ2DL2 + H−Y2 − Sin@Θ2DL2 <
13.1.2 Constraint Inspection When an expression in a Mech model is supposed to evaluate to a number but it does not, it can often be caught by the CheckSystem function. CheckSystem evaluates the constraint expressions in the current model, subject to the current initial guesses and parameters, and reports any nonnumeric expressions found. Consider the following simple model of a reciprocating slider. If CheckSystem is run before the symbols amp and freq are defined, they are identified.
Here is a reciprocating slider model. In[6]:= Clear@amp, freqD;
SetConstraints@ Translate2@1, Axis@1, 80, 0<, 81, 0
CheckSystem::undef : The current system contains the following undefined Symbols: 8amp, freq<
MechanicalSystems
452
If the symbols amp and freq are defined at runtime, but not defined in such a way that the expression amp Sin[freq T] evaluates to a number, CheckSystem cannot determine exactly what is wrong.
Here is a bogus definition for the symbol freq. In[9]:= amp = 1;
freq = 82, 4<; CheckSystem@D;
CheckSystem::cnum : The vector of constraint expressions does not evaluate to a list of numbers when subject to the current initial guesses and parameters. Use Constraints to inspect the equations.
Constraints[cnum]
returns the list of constraint expressions that were generated by constraint cnum.
Constraints[{cnum, {eqn1, eqn2, …}}] Constraints[All]
returns a list of the constraint expressions generated by the equations eqni in constraint cnum. returns the entire vector of constraint expressions.
The constraint inspection function.
Constraints is a Mech function that is used to return all or part of the vector of constraint expressions in the current model. Often, direct inspection of the constraints immediately gives a clue as to the cause of an error. Usually, the constraints are inspected subject to the values of the current guesses and parameters, which shows exactly what CheckSystem saw to be an error.
Here is the entire current constraint vector.
In[12]:= Constraints@AllD ê. LastSolve@D Out[12]= 80, 0, 80, 0<<
In all cases, input such as this should return a vector of numbers. In this case, the third constraint expression evaluates to a list of numbers, instead of a single number. Obviously this is due to the bogus definition of freq = {2, 4} in the example.
Chapter 13: Debugging Models
453
We can repair the bogus definition and try again. In[13]:= freq = 2;
CheckSystem@D; Constraints@AllD ê. LastSolve@D
Out[15]= 80, 0, 0<
Now the constraints evaluate to a list of numbers, as is required. The fact that each of the constraint expressions evaluates to zero simply means that all of the constraints are perfectly satisfied at the current values of the initial guesses, which is not usually the case.
13.1.3 Load Inspection Mech load expressions may be rendered invalid by the presence of nonnumeric expressions in the same way as constraint expressions. CheckSystem evaluates the current load expressions, if any exist, subject to the current values of the initial guesses, parameters, and Lagrange multipliers, and reports any nonnumeric expressions found. To demonstrate, a simple load is added to the reciprocating slider model defined in Section 13.1.2.
A force applied to body 2. In[16]:= Clear@b, kD
SetLoads@Force@2, Axis@2, 80, 0<, 80, −1
In[18]:= CheckSystem@D;
CheckSystem::undef : The current system contains the following undefined Symbols: 8b, k<
If the symbols k and b are defined at runtime, but not defined in such a way that the expression Exp[k t + b] evaluates to a number, CheckSystem will not be able to determine exactly what is wrong. For example, CheckSystem is limited to recognizing raw symbols only. CheckSystem does not recognize a user-defined variable of the form c[n].
MechanicalSystems
454
In[19]:= b = c@1D;
k = c@2D; CheckSystem@D; CheckSystem::lnum : The vector of system loads does not evaluate to a list of numbers when subject to the current initial guesses, Lagrange multipliers, and parameters. Use Loads to inspect the loads.
Loads[{bnum1, bnum2, …}]
returns the part of the generalized load vector that is associated with the bodies bnumi.
Loads[All]
returns a list of the loads on all current bodies.
The load inspection function.
Loads is a Mech function that is used to return all or part of the vector of load expressions that are applied to the current model. Usually, the loads are inspected subject to the values of the current guesses, parameters, and Lagrange multipliers, which shows exactly what CheckSystem saw to be an error.
Here is the current vector of applied loads.
In[22]:= Loads@AllD ê. LastSolve@D Out[22]= 80, −
c@1D
, 0<
In all cases, the input shown should return a list of numbers. In this case, the second load expression, the Y component of the force applied to body 2, evaluates to a symbolic expression instead of a single number. Obviously this is due to the definition of b = c[1] given. However, c[2] does not appear in the applied loads. This is because c[2] (k) is multiplied by time T. The current initial guess for T is T → 0, so c[2] is canceled entirely. Thus, CheckSystem does not even recognize the presence of c[2] until the initial guesses are perturbed.
We can repair one of the bogus definitions, but the other still remains. In[23]:= b = 2.0;
CheckSystem@D Out[24]= True
Chapter 13: Debugging Models
455
CheckSystem thinks that all is well, which is definitely not the case. This is an often frustrating flaw in CheckSystem, but it cannot tell what is and is not a number until it evaluates it, and zero times anything is a number. If the value of time is perturbed, CheckSystem sees that the loads are not purely numeric.
If we change the current value of time with SetGuess, CheckSystem recognizes an error. In[25]:= SetGuess@8T → .001
CheckSystem@D; CheckSystem::lnum : The vector of system loads does not evaluate to a list of numbers when subject to the current initial guesses, Lagrange multipliers, and parameters. Use Loads to inspect the loads.
Now we repair the other bogus definition. In[27]:= k = 4.0;
CheckSystem@D; Loads@AllD ê. LastSolve@D
Out[29]= 80, −7.41867, 0<
Now the loads evaluate to a nested list of numbers, as is required.
13.2 Failure to Converge This section deals with mechanism modeling errors that prevent a Mech model from converging to a solution or cause it to converge to an incorrect solution.
13.2.1 Inconsistent Constraints The most basic error in kinematic modeling is to simply define a set of constraints that is not consistent with the mechanism that is being modeled. If a model to which no solution exists is defined, Mech must fail to converge.
MechanicalSystems
456
For example, consider a rotating crank with a single link between an eccentric point on the crank and a point on the ground. If the link is insufficiently long, it will not reach from the crank to the ground, regardless of the orientation of the crank. In this case, the link is only 1.75 units long, while the minimum possible distance between its two attachment points is 2 units. No assembled configuration of the mechanism exists, so the Newton-Rhapson solution block fails.
This loads the Modeler2D package. In[1]:= Needs@"MechanicalSystems`Modeler2D`"D
Here is a simple crank-with-link mechanism. In[2]:= len =.
SetConstraints@ Revolute2@1, Point@1, 0D, Point@2, 0DD, RelativeDistance1@2, Point@1, 83, 0
SolveMech attempts to find a solution, but it cannot. In[4]:= len = 1.75;
SolveMech@D Mech::noconverge : Newton's method failed to converge in 15 iterations.
Out[5]= 8X2 → 2.16457 × 10−17 , Y2 → 0., Θ2 → −4.45321<
The diagnosis of this type of problem can be quite difficult. No specific tool to help isolate such a problem is provided by Mech because Mathematica can only know what is said, not what is meant. The first thing to try is usually to make a quick sketch of the mechanism, and make sure that its assembly is feasible. If it is clear that the problem is a modeling error, not a conceptual one, then an examination of the constraint expressions can yield some insight.
Here are the current values of constraints 1 and 2.
In[6]:= Constraints@1D ê. LastSolve@D
Constraints@2D ê. LastSolve@D
Out[6]= 8−2.16457 × 10−17 , 0.< Out[7]= 812.7371<
Chapter 13: Debugging Models
457
Since the expressions in constraint 1 are equal to zero at the current values of the initial guesses, they are satisfied and are probably not the cause of the problem. Constraint 2, the RelativeDistance1 constraint, is not equal to zero, therefore it is the constraint that SolveMech was unable to satisfy. While this method may prove to be helpful in isolating a problem, there is no guarantee that a constraint that is not satisfied is actually the one that is in error. For example, it is possible that the length of the link in the example is correct and is what the designer intended, and what really needs correction is the location of the center of the crank. Another tool that can prove helpful is StepMech. This function causes the iterative solver to take a single Newton-Rhapson step toward the solution and return the result, regardless of any convergence criteria. This allows the solution to be inspected at each step, so that if it starts to diverge, the user can see “which way it goes”.
StepMech[t]
advances the current model through one Newton-Rhapson iteration at time t.
A debugging utility.
StepMech is equivalent to SolveMech with MaxIterations set to 1, and an infinitely accurate convergence criteria.
13.2.2 Bifurcation Another common modeling problem is bifurcation, a condition where more than one solution to the system of constraint equations exists, representing multiple possible assembled configurations. When the previously defined crank-with-link model is modified so that it can converge, it is able to converge to either of two solutions depending on the values of the initial guesses.
Here is one possible configuration of the crank-with-link model with a reasonable value of len. In[8]:= len = 2.25;
SetGuess@8Θ2 → 0
Out[10]= 8X2 → 4.55514 × 10−25 , Y2 → 0., Θ2 → −0.966526<
MechanicalSystems
458
And here is the other possible configuration of the crank-with-link model. In[11]:= SetGuess@8Θ2 → −N@PiD
SolveMech@D
Out[12]= 8X2 → −4.18873 × 10−25 , Y2 → 0., Θ2 → −2.17507<
Once a model is apparently functioning properly, the value of a graphic image of the model cannot be overemphasized. A rudimentary graphic image can immediately show errors that may have gone unnoticed, such as the fact that a model has converged on the wrong side of a bifurcation, or simply that the model has been defined incorrectly. Errors that are difficult to detect from the numbers alone are often easily seen in the graphic.
Here is a simple graphic of the crank-with-link model at both positions. In[13]:= Show@Graphics@[email protected], Circle@80, 0<, 1.2D, Point@83, 0
8Point@Location@2, 80, 1
Out[13]=
Graphics
13.2.3 Redundancy A mechanism model with a redundant constraint set can be thought of as having more than one constraint controlling the same degree of freedom. Since SetConstraints only allows models to be defined if they have equal numbers of constraints and degrees of freedom, the presence of one redundant constraint implies the presence of one unconstrained degree of freedom. CheckSystem may be used to detect such errors.
Chapter 13: Debugging Models
459
Here is a model with a redundant constraint set. Translate2@1, Axis@2, 0, 81, 1
In[14]:= SetConstraints@
CheckSystem::redund : Redundant constraints occur at positions 881, 1<, 82, 1<< in the constraints list. Better initial guesses may be needed.
The constraint position numbers given in the error message generated by CheckSystem refer to the position of the offending constraints in the current constraint list. For example, the current constraint vector has three expressions, the first two from Translate2 and the last from Orthogonal1. The positions {{1, 1}, {2, 1}} given by the error message refers to the first expression in constraint 1, the Translate2, and the first and only expression in constraint 2, the Orthogonal1. CheckSystem is usually, but not always, able to detect redundancies in a constraint set. Because of the Euler generalized parameters used in the 3D constraint formulation, it is possible for CheckSystem to be unable to detect a redundancy if the current initial guesses for the Euler parameters do not constitute a valid set. Specifically, a valid set of four Euler parameters representing an arbitrary angular orientation must satisfy the following relation. Ei2 + Ej2 + Ek2 + Eo2 n 1 If the Euler parameters in the current initial guesses do not satisfy this relationship, it is possible for Checkg System to be unable to detect a redundant constraint set. Another weakness in the redundancy checking used by Mech is that numerical inaccuracies may cause CheckSystem to report that more constraint expressions are participating in a redundancy than really are. This is only a problem in relatively large systems where numerical errors are more pronounced.
MechanicalSystems
460
13.3 Mathematical Anomalies In this section artifacts of the mathematical methods used by Mech are discussed.
13.3.1 Zero Unit Vectors If the concept of a zero-length unit vector seems a little strange, rest assured that Mech also finds it difficult. Unit vectors are used internally by Mech to generate an applied force vector when the magnitude of the force is specified, and the direction of the force is given as a vector based on mechanism geometry. The applied force vector, in this case, is the supplied direction vector divided by its own magnitude, times the specified force magnitude. If the magnitude of the supplied direction vector becomes zero at some point in the mechanism motion, a singularity results. The most common occurrence of this problem is in the application of frictional forces. If the negation of the velocity vector of a point is used to specify the direction of a force, the velocity of the point may not go to zero at any point in time when a solution is sought. If it does, Mathematica evaluates 0/0 and produces an error message. While this is to be expected since a zero vector makes no sense as a direction specification, it can be quite difficult to formulate a workaround. Setting the magnitude of the force equal to zero for all points in time at which the direction vector becomes zero may not work, because this still results in 0*0/0, which is no better than 0/0. In[1]:= 0 ∗ 0 ê 0
Power::infy : Infinite expression
1 encountered. More… 0
∞::indet : Indeterminate expression 0 ComplexInfinity encountered. More… Out[1]= Indeterminate
The simplest workaround is to use the CutOff option for Force and Moment.
Chapter 13: Debugging Models
461
CutOff
is an option for Force and Moment that specifies a cutoff value for the magnitude of an applied load. If CutOff is nonzero, the magnitude of the load drops to 1/2 of the specified magnitude when the length of the line of action is equal to CutOff, and the magnitude of the load drops to zero when the length of the line of action is zero. The default setting is CutOff → 0.
A fix for problems with zero-length force vectors.
The following example shows the effect that CutOff has on the force vector generated by a Mech Force function. The force is defined with a constant magnitude, but the direction vector of the force is a function of a. Clearly, the force is indeterminate if a goes to zero. Here is a force that fails if a = 0. In[2]:= Needs@"MechanicalSystems`Modeler3D`"D
Force@2, Axis@1, 0, 8a, 0, 0
Out[3]= VectorA1, 9 è!!!!!! , 0, 0=E 2
10 a a
Here is the same force using the CutOff option.
In[4]:= Force@2, Axis@1, 0, 8a, 0, 0
10 a è!!!!!! , 0, 0=E 0.0001 + a2
The value of CutOff should be extremely small so that it has a negligible effect on the magnitude of the load in the operating range of the variable a.
MechanicalSystems
462
13.4 Equations of Motion This section shows how to access the complete system of equations that is generated by a Mech model.
13.4.1 Internal Expression Access The following functions are used to access the symbolic expressions that are generated by MechanicalSystems.
Constraints[cnum]
returns the list of constraint expressions that were generated by constraint cnum. The expressions returned are set equal to zero to satisfy the constraint.
Jacobian[cnum, bnum]
returns the submatrix of the constraint Jacobian associated with constraint cnum and body bnum.
VelocityTerms[cnum]
returns a part of the right-hand term of the velocity constraint expressions associated with constraint cnum. The full velocity constraint expression is given by Velocity Terms[_] + Jacobian[_,_].Velocity[_].
AccelerationTerms[cnum]
returns a part of the right-hand term of the acceleration constraint expressions associated with constraint cnum. The full acceleration constraint is AccelerationTerms[_] + Jacobian[_,_].Acceleration[_].
Loads[bnum]
returns the total external load vector applied to body bnum.
Centrifugal[bnum]
returns the vector of centrifugal forces associated with body bnum.
MassMatrix[bnum]
returns the submatrix of the mass matrix associated with body bnum.
Functions to provide access to internally stored expressions.
Chapter 13: Debugging Models
Location[bnum]
463
returns the location coordinates X2, Y3, etc. associated with body bnum.
Velocity[bnum]
returns the velocity coordinates X2d, Y3d, etc. associated with body bnum.
Acceleration[bnum]
returns the acceleration coordinates X2dd, Y3dd, etc. associated with body bnum.
Generalized[cnum]
returns the Lagrange multipliers Λ1, Λ2, etc. associated with constraint cnum.
Functions that return a model’s dependent variables.
In all of these functions, the body number bnum can be a single positive integer, a list of integers, All, or Rest. The constraint number cnum can be a single positive integer constraint number, a list of integers, All, Euler, or any of the forms of partial constraint specifications accepted by Constraints. The complete set of equations that are solved by the Static solution block is given by Transpose [Jacobian[_,_]].Generalized[_] == Loads[_]. The equations of motion that are solved by the Dynamic solution block are the Static equations with Centrifugal[_] + MassMatrix[_] .Acceleration[_] added to the left-hand side.
13.4.2 Examples Here is a simple model to provide some values for the dependent variables. In[1]:= Needs@"MechanicalSystems`Modeler3D`"D
SetConstraints@ Spherical3@1, Point@2, 81, 0, 0
The model is run with the Dynamic solution option, and very tight convergence criteria.
In[5]:= sol = SolveMech@0, Solution → Dynamic, ZeroTest → H#
0 &LD êê Chop;
MechanicalSystems
464
Here are all the kinematic constraint equations.
In[6]:= Constraints@AllD ê. sol Out[6]= 80, 0, 0, 0, 0, 0, 0<
Here are the velocity constraints.
In[7]:= Jacobian@All, AllD.Velocity@AllD + VelocityTerms@AllD ê. sol Out[7]= 80, 0, 0., 0., 0., 0, 0<
Here are the acceleration constraints.
In[8]:= Jacobian@All, AllD.Acceleration@AllD + AccelerationTerms@AllD ê. sol Out[8]= 80., 0., 0, 0, 0, 0., 0.<
Here are the static reaction force equations. They are not satisfied because the model was solved with the Dynamic option.
In[9]:= Transpose@Jacobian@All, AllDD.Generalized@AllD − Loads@AllD ê. sol Out[9]= 8−0.05, 0.05, 0., 0.04, −0.015, 0.015, 0.01<
Here are the dynamic equations of motion. In[10]:= Transpose@Jacobian@All, AllDD.Generalized@AllD +
[email protected]@AllD + Centrifugal@AllD − Loads@AllD ê. sol
Out[10]= 80., 0., 0., 0., 0., 0., 0.<
A. Modified Mathematica Built-in Symbols Additional Function Definitions New definitions are made for the built-in Mathematica symbols Direction and Jacobian (options for Limit and FindRoot, respectively). The new functional definitions that are made for these symbols by MechanicalSystems do not interfere with their standard Mathematica usages as option names. MechanicalSystems also makes additional functional definitions for Cross and Dot. These new definitions do not interfere with the built-in definitions, they simply allow Cross and Dot to automatically convert MechanicalSystems vector objects (Vector, Line, Plane) into normal vectors so that the cross or dot product can be calculated. Further, Modeler2D defines the cross product of a pair of 2-vectors, which is not defined by the built-in definition of Cross. Additional Derivative Definitions Definitions are made by MechanicalSystems for the derivative functions of Abs, Sign, Mod, Round, Floor, and Ceiling. The new definitions disregard the discontinuous nature of these functions and they are not valid for complex numbers in general. H∂a Abs@aDL Sign@aD H∂a Sign@aDL 0 1 H∂a Mod@a, bDL H∂a Round@aDL 0 H∂a Floor@aDL 0 H∂a Ceiling@aDL 0
Additional Usage of Existing Symbols MechanicalSystems makes extensive use of a few built-in Mathematica symbols, such as Line and Point, and many standard option names, such as MaxIterations and InterpolationOrder. No new definitions are made for these symbols, they are simply used to carry their arguments or specify options as they are in standard Mathematica.
B. MechanicalSystems Function Listing Absolute 2D/3D † Absolute is the default setting for the Magnitude option for Force. † Magnitude->Absolute causes the magnitude of the applied load to be equal to the specified magnitude. † Absolute is also the default setting for the Magnitude option for Arrow. † In Modeler3D, Absolute is also the default setting for the Magnitude option for Moment and Extrude. † The alternative to the Absolute setting is Relative, which causes the magnitude of the applied load to be equal to the specified magnitude times the length of the vector used to specify the direction of the force or moment. † See also: CutOff.
Acceleration 2D/3D † Acceleration[point] returns the global acceleration vector, {ddX, ddY} (2D) or {ddX, ddY, ddZ} (3D) of the specified point. † Acceleration[bnum, lpnt] is interpreted as Acceleration[Point[bnum, lpnt]]. † Acceleration[bnum] returns the acceleration and angular acceleration coordinates of body bnum in a flat list. † The bnum argument can take any of the forms accepted by Loads to obtain the acceleration coordinates of multiple bodies.
MechanicalSystems
468
† Acceleration is also a setting for the Solution option for several Mech functions. † Solution->Acceleration causes such functions to seek a solution for the location, velocity, and acceleration of the current model. † Acceleration[All] returns the entire vector of acceleration coordinates. † The behavior of Acceleration[bnum] varies depending on whether the current solution method is Angular or Euler. † To use Acceleration[bnum], bnum must be the number of a body in the current model. † In Modeler2D with the Euler solution method, Acceleration[2] returns {X2dd, Y2dd, Ei2dd, Ej2dd}, but with the Angular solution method, Acceleration[2] returns {X2dd, Y2dd, Θ2dd}. † In Modeler3D with the Euler solution method, Acceleration[2] returns {X2dd, Y2dd, Z2dd, Eo2dd, Ei2dd, Ej2dd, Ek2dd}, but with the Angular solution method, Acceleration[2] returns {X2dd, Y2dd, Z2dd, Ωx2d, Ωy2d, Ωz2d}. † Acceleration[sym] or Acceleration[{sym, … }] returns the acceleration coordinates associated with the specified location coordinates sym. † The alternatives to the Acceleration setting for the Solution option are Location, Velocity, Static, Kinematic, and Dynamic. † See also: Alpha, SolveMech, SetCouple.
AccelerationTerms 2D/3D † AccelerationTerms[cnum] returns the part of the right-hand term of the current acceleration constraint expressions associated with constraint cnum. † The cnum argument can take any of the forms accepted by Constraints to obtain acceleration terms from multiple constraints. † AccelerationTerms[All] returns the entire vector of acceleration terms. † Jacobian[cnum, All] . Acceleration[All] + AccelerationTerms[cnum] returns the entire acceleration constraint expression associated with constraint cnum. † The AccelerationTerms are formed by differentiating the constraint vector twice with respect to time and discarding the components that are a linear function of the acceleration coordinates. † See also: VelocityTerms.
Appendix B: MechanicalSystems Function Listing
469
AddLoads 2D/3D † AddLoads is an option for SetLoads that specifies whether the supplied loads are to replace the existing load vector or be added to the existing load vector. † AddLoads->True causes SetLoads to add the specified loads to the loads that are currently set. † Errant load settings can be induced with AddLoads->True by accidentally running SetLoads more than once with the same loads, thereby multiplying their magnitude. † The default setting is AddLoads->False. † See also: Force, Moment.
Alpha 2D/3D † Alpha[bnum] returns the angular acceleration (2D) or angular acceleration vector (3D) of body bnum. † In Modeler2D, Alpha returns a scalar a. † In Modeler3D, Alpha returns the angular acceleration vector of the form: {ax, ay, az}. † If the Euler solution method is specified with SetSymbols, Alpha returns the angular acceleration in terms of Euler parameters and their second derivatives. With the Angular solution method Alpha simply returns Θbnumdd (2D) or {Ωxbnumd, Ωybnumd, Ωzbnumd} (3D). † In Modeler3D, Alpha accepts the Coordinates option to specify whether the angular acceleration should be returned in Global or body Local coordinates. The default setting is Coordinates->Global. † See also: Acceleration, Omega, Rotation.
MechanicalSystems
470
Angle 2D/3D † In Modeler2D, Angle[vector] returns the direction angle of vector relative to the global X axis. † Angle is also an option for Bar, Revolve, Sphere, Torus, and Wheel to specify the range of the revolution angle. Angle->{a, b} revolves the object from a to b radians. † In Modeler2D, Angle[bnum, lpnt] is interpreted as Angle[Vector[bnum, lpnt]]. † Other Angle[args, …] instances are interpreted as Angle[Line[args]]. † Angle->number is equivalent to Angle->{0, number}. † The default setting is Angle->{0, 2π}. † See also: Direction, Faces, ProjectedAngle, Rotation.
Angular 2D/3D † Angular is a setting for the Method option for SetSymbols that causes all subsequently built models to represent angular velocity and acceleration explicitly in their angular coordinates. † The alternative to the Angular setting is Euler. † In Modeler2D, the Angular solution method causes the angular orientation of a body to be represented by a single quantity—its angular coordinate theta (Θbnum), and the body’s angular velocity and acceleration are also specified by the single quantities omega and alpha (Θbnumd and Θbnumdd). † In Modeler3D the angular orientation of a body is always specified by four Euler parameters, but with the Angu lar solution method the angular velocity and acceleration are specified by the angular velocity and acceleration vectors, omega and alpha ({Ωxbnum, Ωybnum, Ωzbnum} and {Ωxbnumd, Ωybnumd, Ωzbnumd}) instead of derivatives of Euler parameters. † In Modeler2D, Method->Angular is the default setting. † See also: EulerParameters, Rotation.
Appendix B: MechanicalSystems Function Listing
471
Applied 2D/3D † Applied is the default setting for the Type option for Loads. † Type->Applied causes Loads to return the total external load applied to a body. † The alternatives to the Applied setting are Reaction or Dynamic, which cause Loads to return kinematic reaction forces or inertial loads, respectively. † See also: SetLoads.
ArcLength 2D/3D † ArcLength[spline] returns a 1D cubic SplineFunction object approximately representing the arc length of the given spline. The spline must be a 2D or 3D SplineFunction object such as is returned by SplineFit. † The spline must be a single SplineFunction of higher dimensionality, not a list of 1D SplineFunction objects. † ArcLength uses NIntegrate to approximate the arc length of each segment of the spline.
Arrow 2D/3D † Arrow[axis, len] returns a graphics object representing an arrow of length len emanating from the origin of axis and pointing in the direction of axis. † Arrow returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † The following options can be given: Reverse
False
reverse the direction of the arrow
HeadSize
Automatic
specifies the width of the arrowhead
Magnitude
Absolute
whether len is multiplied by the length of axis
MechanicalSystems
472
† Magnitude->Relative causes the length of the arrow to be equal to len times the length of axis. † In Modeler3D it is possible to control the rotation of the arrowhead about the axis by changing the reference direction of axis. † See also: Edge, LocalAxes, PointLabel.
Axis 2D/3D † Axis[point, vector] is a Mech data object that specifies an axis by origin and direction. The axis originates at point and points in the direction of vector. point must be a Mech Point object and vector must be a Mech Vector or Line object. † Axis[bnum, lpnt1, lpnt2] is interpreted as Axis[Point[bnum, lpnt1], Vector[bnum, lpnt2]]. The lpnti can be vectors, {x, y} or {x, y, z}, in the local coordinate system of body bnum or point numbers (positive integers) referencing coordinates that were defined with SetBodies. † Any function that takes an axis argument can accept an Axis object, a Line object, or a Plane object (3D) in its place. † In Modeler3D, vector may also be a Plane object, in which case the direction of the plane’s normal is used. † In Modeler3D, Axis[point, vector1, vector2] uses vector2 to explicitly specify the rotational reference vector of the axis (vector2 must be nonparallel to vector1). † In Modeler3D, Axis[bnum, lpnt1, lpnt2, lpnt3] is interpreted as Axis[Point[bnum, lpnt1], Vector[bnum, lpnt2], Vector[bnum, lpnt3]]. † In Modeler2D, Axis[bnum1, lpnt1, bnum2, lpnt2] is interpreted as Axis[Point[bnum1, lpnt1], Vector[bnum2, lpnt2]]. † In Modeler3D, Axis[bnum1, lpnt1, bnum2, lpnt2, bnum3, lpnt3] is interpreted as Axis[Point[bnum1, lpnt1], Vector[bnum2, lpnt2], Vector[bnum3, lpnt3]]. † See also: ReferenceDirection.
Appendix B: MechanicalSystems Function Listing
473
Bar 2D † Bar[axis, c] generates a rectangular bar of width 2c spanning from the origin to the end of axis. † In Modeler2D, Bar[axis, l, r] generates a rectangular bar that is asymmetrical about axis with left and right sides l and r units to either side of axis, relative to the direction of axis. † In Modeler3D, Bar[axis, w, h] generates a rectangular bar of width 2w and height 2h. † Bar returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † In Modeler2D, Bar[axis, lorg, rorg, lend, rend] generates an asymmetrical tapered bar with lorg and rorg placing the left and right sides at the origin, and lend and rend placing the left and right sides at the end. † In Modeler3D, Bar[axis, w+, h+, w–, h–] generates a rectangular bar that is asymmetrical about axis with the width and height in each direction specified independently. † In Modeler3D, the reference direction of axis gives the direction in which the width of the bar is measured. † The following option can be given: Faces
True
whether to draw with filled polygons or wire frames
† In Modeler3D, the following option can also be given: Ends
True
whether to cap the ends with two polygons
† See also: Box, Facet, Tangent, Wheel.
Body 2D/3D † Body[bnum, options] returns a SysBody data object that is used to define points and properties on a Mech body. After creation, the SysBody object is passed to SetBodies to alter the state of the current Mech model. † The bnum is a positive integer index number that is used to reference the body after it has been incorporated into the current model with SetBodies.
MechanicalSystems
474
† The following Modeler2D options can be given: PointList
Automatic
{{x1, y1}, {x2, y2}, … }
InitialGuess
Automatic
{{x, y}, Q}
Mass
Automatic
M
Inertia
Automatic
Ig
Centroid
Automatic
{xg, yg}
† The following Modeler3D options can be given: PointList
Automatic
{{x1, y1, z1}, {x2, y2, z2}, … }
InitialGuess
Automatic
{{x, y, z}, {eo, ei, ej, ek}}
Mass
Automatic
M
Inertia
Automatic
{Ixx, Iyy, Izz, Ixy, Iyz, Izx}
Centroid
Automatic
{xg, yg, zg}
† The Automatic setting for the options for Body has the effect of leaving the value of an option that has already been specified unchanged. Thus, running a command such as SetBodies[Body[bnum, Mass->M]] does not affect the current values of the other options for body bnum, or the current values of any options of any other bodies. † Each of the option names for Body can also be used as a function head to retrieve the option setting. † See also: Constraint, Force, Moment.
BodyEnergy 2D/3D † BodyEnergy[bnum] returns the kinetic energy possessed by body bnum. † The bnum argument can take any of the forms accepted by Loads to obtain energy terms from multiple bodies. † BodyEnergy[All] returns the total kinetic energy of the entire system. † BodyEnergy returns the body’s mass and inertia matrices pre- and post-multiplied by the body’s velocity and angular velocity vectors, resulting in v.m.v = m v2 = E. † See also: Omega, Velocity.
Appendix B: MechanicalSystems Function Listing
475
Box 2D/3D † Box[bnum, {lpnt1, lpnt2}] generates a box with two opposing corners located at local points lpnt1 and lpnt2, on body bnum. The sides of the box are aligned with the local axes of body bnum. † Box returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † In Modeler2D, the Box function is analogous to Rectangle. † In Modeler3D, the Box function is analogous to Cuboid. † The Faces option can be given to determine whether to draw the box with filled polygons or as a wire frame. The default setting is Faces->True. † See also: Bar, Facet, Wheel.
BuildMech 2D/3D † BuildMech[level] is used to force a build of the mechanism equations to the specified level at any time. † BuildMech is also an option for SetConstraints and SetLoads. BuildMech -> level specifies what parts of the mechanism model are built immediately. † level can be None, All, Location, Velocity, Acceleration, Static, Kinematic, or Dynamic. † BuildMech[Clear] clears all equations in the current model and releases their memory. † BuildMech[Clear] marks all parts of the current model so that they will be rebuilt the next time they are used, but nothing is rebuilt immediately. † BuildMech[None] does nothing. † BuildMech may also be called with Constraints, Jacobian, VelocityTerms, AccelerationTerms, Loads, Centrifugal, or MassMatrix as its argument to clear and rebuild the specified part of the model. † The default settings for BuildMech with SetConstraints and SetLoads are Location and Static, respectively. BuildMech can be used to force all of the system equations to be built before all of the user variables in the system have been defined. † If the user introduces variables into the model that are not explicitly symbols (such as c[1], c[2], …) they will
MechanicalSystems
476
not be identified by Mech and the delayed equation building that occurs when velocity or acceleration solutions are requested will fail. In such cases, specifying BuildMech->Dynamic will cause all of the system equations to be built immediately. † See also: CheckSystem, ClearMech.
CamPlot 2D/3D † CamPlot[locuspoint, {alpha, min, max}] returns a SysPlot object representing the cam profile, a 2D or 3D space curve, that is defined by the locus of locuspoint. † CamPlot[bnum, {lpnt1, lpnt2, … , lpntn}, {alpha, min, max}] plots several point loci on one body, all of which must be functions of alpha. † CamPlot[locuspoint, {alpha, min, max}, {beta, min, max}] returns a SysPlot object representing a 3D cam surface profile. The coordinates of locuspoint must be a function of the symbols alpha and beta. † The SysPlot object returned by CamPlot is not evaluated until numeric values are available for the Mech system variables associated with the body on which locuspoint is located. † SysPlot returns a Graphics object (2D) or Graphics3D object (3D), not a graphics primitive. † See also: LocusPlot.
CamToCam1 2D/3D † CamToCam1[cnum, locuspoint1, {alpha, guess}, locuspoint2, {beta, guess}] models two cam profiles that work against each other. † The locus of locuspoint1 defines the first cam surface as a function of the symbol alpha, while the locus of locuspoint2 defines the second cam surface as a function of the symbol beta. (locuspoint1 and locuspoint2 must be defined as functions of alpha and beta.) † CamToCam1 enforces that the surfaces of the two cam profiles lie tangent to each other. † In Modeler3D, two {symbol, guess} pairs must be provided in place of {alpha, guess}, and two more in place of {beta, guess}. † CamToCam1 constrains one degree of freedom.
Appendix B: MechanicalSystems Function Listing
477
† In Modeler3D, each locuspoint is a parametric function of two parameters, so as to define a surface in 3D space. † CamToCam1 generates three (2D) or five (3D) constraint equations and introduces two or four new variables, hence constraining one degree of freedom in 2D or 3D. † The first two (or three) equations constrain the points of contact on the two cams to be coincident, and the last one (or two) equation constrains the normal vectors of the two cams at the points of contact to be parallel, yielding three or five constraint equations. † See also: CamToPoint1, CurveToCam1, SetConstraints, SysCon.
CamToCircle1 2D † CamToCircle1[cnum, locuspoint, {alpha, guess}, point, radius] models a cam surface with a circular follower. † The locus of locuspoint defines the cam surface as a function of the symbol alpha (locuspoint must be defined as a function of alpha). † CamToCircle1 enforces that the surface of the cam profile lies tangent to a circle of specified radius centered at point. The circular follower lies on the left side of the cam profile if radius is positive, when traveling along the locus in the direction of increasing alpha. † CamToCircle1 constrains one degree of freedom. † CamToCircle1 generates two constraint equations and introduces one new variable, alpha, hence constraining one degree of freedom. † A vector that is normal to the cam profile at the point of contact, and has length equal to radius, is set equal to the vector from the point of contact to the center of the circular follower; yielding two coupled constraint equations. † See also: CamToSphere1, SetConstraints, SysCon.
CamToLine1 2D † CamToLine1[cnum, locuspoint, {alpha, guess}, axis] models a cam surface with a flat follower. † The locus of locuspoint defines the cam surface as a function of the symbol alpha (locuspoint must be defined as a function of alpha).
MechanicalSystems
478
† CamToLine1 enforces that the surface of the cam profile lies tangent to axis. † CamToLine1 constrains one degree of freedom. † CamToLine1 generates two constraint equations and introduces one new variable, alpha, hence constraining one degree of freedom. † The first equation constrains the point of contact to lie on the line, and the second equation constrains the normal to the cam profile at the contact point to be orthogonal to the line. † See also: CamToPlane1, SetConstraints, SysCon.
CamToPlane1 3D † CamToPlane1[cnum, locuspoint, {alpha, guess}, {beta, guess}, plane] models a cam surface with a planar follower. † The locus of locuspoint defines the cam surface as a function of the symbols alpha and beta (locuspoint must be defined as a parametric function of alpha and beta). † CamToPlane1 enforces that the surface of the 3D cam profile lies tangent to the plane. † CamToPlane1 constrains one degree of freedom. † CamToPlane1 generates three constraint equations and introduces two new variables, alpha and beta, hence constraining one degree of freedom. † The first equation constrains the point of contact to lie on the plane, and the second and third equations constrain the normal to the cam profile at the contact point to be orthogonal to the plane. † See also: CamToLine1, SetConstraints, SysCon.
CamToPoint1 2D/3D † CamToPoint1[cnum, locuspoint, {alpha, guess}, point] models a cam surface with a point follower. † The locus of locuspoint defines the cam surface as a function of the symbol alpha (locuspoint must be defined as a function of alpha).
Appendix B: MechanicalSystems Function Listing
479
† CamToPoint1 enforces that the specified point lies on the surface of the cam profile. † In Modeler3D, two {symbol, guess} pairs must be provided. † CamToPoint1 constrains one degree of freedom. † In Modeler3D, each locuspoint is a parametric function of two parameters, so as to define a surface in 3D space. † CamToPoint1 generates two (2D) or three (3D) constraint equations and introduces one or two new variables, hence constraining one degree of freedom in 2D or 3D. † The two (or three) equations constrain point to be coincident with the contact point on the cam profile. † See also: CamToCam1, SetConstraints, SysCon.
CamToSphere1 3D † CamToSphere1[cnum, locuspoint, {alpha, guess}, {beta, guess}, point, radius] models a cam surface with a spherical follower. † The locus of locuspoint defines the cam surface as a function of the symbols alpha and beta (locuspoint must be defined as a function of alpha and beta). † CamToSphere1 enforces that the surface of the spatial cam profile lies in tangent contact with a sphere of specified radius centered at point. † CamToSphere1 constrains one degree of freedom. † CamToSphere1 generates three constraint equations and introduces two new variables, alpha and beta, hence constraining one degree of freedom. † A vector that is normal to the cam profile at the point of contact, and has length equal to radius, is set equal to the vector from the point of contact to the center of the spherical follower; yielding three linked constraint equations. † See also: CamToCircle1, SetConstraints, SysCon.
MechanicalSystems
480
Centrifugal 2D/3D † Centrifugal[bnum] returns the vector of centrifugal forces associated with body bnum. † The bnum argument can take any of the forms accepted by Loads to obtain centrifugal force terms from multiple bodies. † Centrifugal[All] returns the entire centrifugal load vector, in current velocity coordinates. † Centrifugal[All] + MassMatrix[All] . Acceleration[All] returns the entire dynamic load vector. † The loads returned by Centrifugal are not converted into {force, moment} coordinates. If the current solution method is set to Euler the loads returned by Centrifugal will be in Euler coordinates. † See also: Loads.
Centroid 2D/3D † Centroid is an option for Body that specifies the location of the centroid of a body. † Centroid[bnum] returns a point object corresponding to the centroid of body bnum. † The centroid of each body is initially located at the local origin of the body, unless otherwise specified. † The default setting Centroid->Automatic leaves the current centroid location unchanged. † See also: Inertia, Mass, SetBodies.
CheckRules 2D/3D † CheckRules is an option for SolveMech that determines whether solution rules passed into SolveMech are assumed to be correct, or are checked against the constraints to see if they constitute a valid solution. † When a list of rules is passed to SolveMech at runtime, the rules are normally used as initial guesses for the next solution attempt.
Appendix B: MechanicalSystems Function Listing
481
† If CheckRules->False is given with Solution->Velocity, the supplied rules are assumed to constitute a valid location solution and only the velocity solution will actually be calculated. † If CheckRules->False is given with Solution->Acceleration, the supplied rules are assumed to constitute valid location and velocity solutions and only the acceleration solution will actually be calculated. † If CheckRules->False is given with Solution set to Static, Kinematic, or Dynamic, only the Lagrange multipliers will actually be calculated. † The default setting is CheckRules->True. † See also: CheckSystem, StepMech.
CheckSystem 2D/3D † CheckSystem[] checks the current model for undefined variables or inconsistent constraint sets. CheckSystem returns True if all is well, False and an error message otherwise. † CheckSystem goes through the following procedure to test the current mechanism model: 1. Look for new dependencies on location variables or the time variable in the constraint equations. If the user introduces a symbol s into the model and then defines s to be a function of Mech location variables (such as s = X2 Y2) after SetConstraints is used to build the constraint equations, the model will fail because symbolic differentiation with respect to X2 and Y2 was not possible in SetConstraints. 2. Look for new dependencies on velocity, acceleration, or generalized force variables in the constraint equations. If the user introduces a symbol s into the model and then defines s to be a function of other Mech variables (such as s = X2d Λ3), the model will fail. Systems that are kinematically dependent on higher-order terms are nonholonomic, and they are handled by SetPath, and systems that are kinematically dependent on generalized forces are underconstrained, and handled by SetFree. 3. Look for new dependencies on any Mech system variables in the mass matrix. Such a dependency makes no physical sense. 4. Look for new dependencies on any Mech system variables in the applied load vector. Such dependencies are allowed, but they will confuse Mech’s variable tracking if they appear after SetLoads is used to build the load vector. New dependencies on generalized force terms will cause the model to fail. 5. Look for undefined symbols that are not Mech system variables in any part of the model. 6. Check to see that the vector of constraint equations evaluates to a vector of numbers at the current values of the initial guesses. If this fails, examine the result of Constraints[All]/.LastSolve[] to see what the nonnumeric quantities are.
MechanicalSystems
482
7. Check to see that the constraint derivatives are numeric at the current values of the initial guesses. This may fail because differentiation resulted in an indeterminate expression, even though the constraints were OK. Examine Jacobian, VelocityTerms, or AccelerationTerms for nonnumeric quantities. 8. Check to see that the total applied load vector evaluates to a vector of numbers at the current values of the initial guesses. If this fails, examine the result of Loads[All]/.LastSolve[] to see what the nonnumeric quantities are. 9. Check to see that the load vector derivatives are numeric at the current values of the initial guesses. This may fail because differentiation resulted in indeterminate expressions, or because the current guesses are unacceptable. Lagrange multiplier guesses should usually be nonzero. 10. Check that the constraint set shows some dependence on each of the dependent variables at the current initial guess state. If not, the model is singular. This may mean that the constraint set is inherently singular, or merely that better initial guesses are needed. 11. Check to see if the Jacobian of the current model is singular. If it is, Mech attempts to find the set of equations that are redundant and return their equation numbers. This may be due to poor initial guesses or inherently redundant constraints. † See also: SetBodies.
ClearMech 2D/3D † ClearMech[] clears the entire Mech database and resets all internal variables to their initial states. † ClearMech[All] is equivalent to (ClearMech[]; SetSymbols[]). † ClearMech[Constraints] clears only the internal variables associated with the constraints. ClearMech[Loads] clears only the loads. † ClearMech clears all variables that are directly created by Mech, but definitions made outside of the MechanicalSystems contexts are not cleared. † Settings made with SetSymbols are not affected by ClearMech unless the All argument is given. † See also: BuildMech, ClearParameters, KillMech.
Appendix B: MechanicalSystems Function Listing
483
ClearParameters 2D/3D † ClearParameters[symbols] deletes the rules from the current parameters list that are associated with the given list of symbols. † ClearParameters[All] deletes all rules in the current parameters list. † See also: Parameters, SetParameters.
Closed 2D/3D † Closed is a setting for the EndConditions option for SplineFit that specifies that the slope and curvature of the spline at the two ends will be equal. † To actually close the spline upon itself, the EndConditions->Closed option must be given and the last data point given to SplineFit must be identical to the first. † The alternatives to Closed are Natural or a list of two direction vectors. † See also: SplineFunction.
CompositeInertia 2D/3D † CompositeInertia[{centroid1, mass1, inertia1}, … , {centroidn, massn, inertian}] returns the list {centroid, mass, inertia} of the inertia properties of a composite body B made up of the n specified subcomponents. † In Modeler3D, arguments to CompositeInertia can have the form {centroidn, massn, inertian, rotationn} to specify subcomponents that are rotated relative to the composite body B. † Given a local reference frame XYZ_B affixed to the composite body B, each argument to CompositeInertia specifies the inertia properties of a subcomponent of B, in the XYZ_B reference frame. † Each centroidi is specified by {x, y} or {x, y, z} and each massi by a scalar.
MechanicalSystems
484
† In Modeler2D each inertiai is specified by a scalar, while in Modeler3D each inertiai is given as a list of the elements of the inertia matrix, {Ixx, Iyy, Izz, Ixy, Iyz, Izx} or a full inertia matrix. † All given inertia properties are assumed to be centroidal. † If the inertia properties of a 3D subcomponent are known in a non-XYZ_B reference frame xyz_B, the rotationi argument is used to specify the rotation of the xyz_B reference frame, relative to XYZ_B. The rotationi are specified by {angle, axis}, a virtual rotation vector, or a set of Euler parameters. † If any of the subcomponents are voids, their mass and inertia properties must be negated so that the inertia of the subcomponent is subtracted from the composite body. † See also: ParallelAxis, PrincipalAxes.
ConstantVelocity4 3D † ConstantVelocity4[cnum, axis1, axis2, C] models a constant velocity joint. † The origin of axis1 is constrained to be coincident with the origin of axis2, and the relative spin of the two axes is constrained to be equal. The relative spin of the axes is the angle between the reference directions of each axis, and the cross product of the two axes. † ConstantVelocity4[cnum, axis1, {alpha, guess}, axis2, C] models a constant velocity joint with a symbol alpha used to track the relative spin of axis1. † ConstantVelocity4 constrains four degrees of freedom. † ConstantVelocity4[cnum, axis1, {alpha, guess}, axis2, ratio, C] causes the relative spin of axis2 to be ratio multiplied by the spin of axis1. This form, with the extra symbol alpha, must be used to have a spin ratio other than 1. † The constant C, which sets the initial relative spin, is equal to the relative spin of axis2 when the spin of axis1 is zero. † Without the extra symbol, ConstantVelocity4 generates four constraint equations. In this case the first three equations constrain the origins of the two axes to be coincident, and the fourth equation relates the relative spins of the two parts of the constant velocity joint. † If the extra symbol form is used, ConstantVelocity4 generates five constraint equations and introduces one new variable, hence constraining four degrees of freedom. In this case the first three equations constrain the origins of the two axes to be coincident, and the fourth and fifth equations relate the relative spin of the two parts of the constant velocity joint to the value of the variable alpha.
Appendix B: MechanicalSystems Function Listing
485
† If the form with the extra symbol alpha is used, the constraint becomes singular when the two axes become parallel; use RelativeAngle1 or a gear constraint. † See also: OrthoRevolute4, SetConstraints, Spherical3, SysCon.
Constraint 2D/3D † Constraint[cnum, equation, {bnum, … }, {{extravar, guess}, … } returns a SysCon data object that is used to add a user-defined constraint equation to a Mech model. The equation can be a single equation or a list of equations, each of which must have the head Equal. After creation, the SysCon object is passed to SetConstraints to alter the state of the current Mech model. † The bnumi are an optional list of the body numbers of those bodies that are constrained by the equation. † {extravar, guess} (or {{extravar, guess}, … } ) is an optional list of symbols that appear in the model (and their associated initial guesses), that are added to the model’s dependent variable list and solved for. † This function is used to enter constraints directly as equations when the desired relation is not attainable with the standard Mech mechanical constraints. † The list of body numbers, {bnum, … } can be omitted if the same bodies are also constrained by other system constraints. † An {extravar, guess} pair associated with a particular extravar may appear in only one constraint in a model. The same extravar in more than one constraint will generate an error in SetConstraints. † See also: Body, GenConstraint, Load.
ConstraintCorrection 2D/3D † ConstraintCorrection is an option for SolveFree. With ConstraintCorrection->True, each body’s location and velocity are corrected at each integration step so as to be consistent with the constraints. † The default setting is ConstraintCorrection->False. † The equations of motion solved by SolveFree do not explicitly contain the kinematic constraints, therefore the
MechanicalSystems
486
cumulative errors in numerical integration may result in a solution that violates the constraints. Constraint Correction->True causes SolveFree to correct the integration at each time step so that the result does not violate the constraints. † ConstraintCorrection->True slows SolveFree by approximately a factor of two. † See also: FitDegree.
Constraints 2D/3D † Constraints[cnum] returns the list of constraint expressions that were generated by constraint cnum. † Constraints[{cnum1, cnum2, … , cnumn}] returns a list of all of the expressions in all of the specified constraints, cnumi. † Constraints[{cnum, {enum1, … }}] returns the specified subset of the equations, enumi, in constraint cnum. † Constraints[{{cnum1, {enum, … }}, {cnum2}, {cnum3, {enum, … }}}] returns several parts to several different constraints. † Constraints[All] returns the entire constraint vector. † Constraints[Euler] returns the Euler generalized constraints, if any exist. † The expressions returned are numerically equal to zero when the constraints are satisfied. † See also: AccelerationTerms, Generalized, Loads, VelocityTerms.
Coordinates 2D/3D † Coordinates is an option for Reaction and Loads that specifies whether the force and moment vectors returned are in Global or Local coordinates. † Coordinates is also an option for RelativeVelocity and InstantCenter that specifies whether the results are returned in Global or Local coordinates. † In Modeler3D, Coordinates is also an option for SetSymbols that determines whether angular velocity and acceleration are calculated in Global or Local coordinates.
Appendix B: MechanicalSystems Function Listing
487
† In Modeler3D, Coordinates is also an option for Alpha and Omega that specifies whether angular velocity and acceleration are returned in Global or Local coordinates. † In Modeler2D, the setting of the Coordinates option for Reaction affects only the value of the force; the moment is a scalar, unaffected by the coordinate system. † In Modeler3D, the setting of the Coordinates option for Reaction affects the direction, but not the magnitude, of both the force and moment vectors. † The default setting is Coordinates->Global for all functions accept Loads. The default setting for Loads is Coordinates->Automatic, which causes results to be returned in the modeling coordinate system specified with SetSymbols. † In Modeler3D, Coordinates is also an option for cylindrical and spherical coordinate conversion functions that specifies the base reference frame for the right-hand rule Cartesian coordinate system. Settings are XYZ, YZX, and ZXY. † The default setting for coordinate conversion functions is Coordinates->XYZ. † See also: CylindricalToXYZ, SphericalToXYZ, XYZToCylindrical, XYZToSpherical.
Corrector 2D/3D † Corrector is a setting for the Method option for SolveFree and SolvePath. The Corrector method uses an Adams-Moulton predictor-corrector integration algorithm. † When Method->Corrector is given instead of the default setting of Automatic, the integrator will always take a corrective Adams-Moulton step at each time step, regardless of the error estimate of the current step. † The alternatives to the Corrector setting are Predictor and Automatic. † See also: FitDegree.
CoupleSystem 2D/3D † CoupleSystem is the head of the data object returned by SetCouple. † The format of the CoupleSystem data object: CoupleSystem[counters, initialconditions, initialguesses, equations, Jacobian, compsyms].
MechanicalSystems
488
† CoupleSystem is not intended to be used external to Mech. † See also: SolveCouple.
Cross 2D/3D † Cross[vector1, vector2] returns the cross product of the direction vectors of the two Mech vector objects. † In Modeler2D, Cross returns a scalar. † In Modeler3D, Cross returns a vector. † Mech’s overloading of the built-in Cross symbol has no effect on its usage in other Mathematica code. † See also: Cross, Direction, Dot, Magnitude, SkewSym, Unit.
Cubic 2D/3D † Cubic is the default setting for the FitDegree option for SolveFree and SolvePath. Cubic specifies a cubic approximation of each section of the integrand. † Lower settings than Cubic may work better if the system being integrated exhibits sharp discontinuities in acceleration. † The Cubic setting uses cubic interpolation for the predictor step, and quartic interpolation for the corrector step. † See also: Linear, Quadratic, Quartic.
Appendix B: MechanicalSystems Function Listing
489
CurveToCam1 3D † CurveToCam1[cnum, locuspoint1, {alpha, guess}, locuspoint2, {gamma, guess}, {delta, guess}] constrains the space curve defined by locuspoint1 to lie tangent to the spatial surface defined by locuspoint2 (locuspoint1 and locuspoint2 must be defined as parametric functions of alpha, gamma, and delta). † CurveToCam1 constrains one degree of freedom. † CurveToCam1 generates four constraint equations and introduces three new variables, alpha, gamma, and delta, hence constraining one degree of freedom. † The points of contact on the cam surface and on the space curve are constrained to be coincident (three degrees of freedom) and the normal to the cam surface is constrained to be orthogonal to the direction vector of the space curve at the point of contact (one degree of freedom) yielding four constraint equations. † See also: SetConstraints, SysCon.
CurveToCylinder1 3D † CurveToCylinder1[cnum, locuspoint, {alpha, guess}, axis, radius] constrains the space curve defined by locuspoint to lie in tangent contact with a cylinder of specified axis and radius. The locuspoint must be defined as a parametric function of alpha. † CurveToCylinder1 constrains one degree of freedom. † CurveToCylinder1 generates two constraint equations and introduces one new variable, alpha, hence constraining one degree of freedom. † The first equation constrains the point of contact to lie radius units away from the cylinder’s axis, and the second equation constrains the direction vector of the curve at the point of contact to be orthogonal to normal vector from the surface of the cylinder at the point of contact, yielding two constraint equations. † See also: CurveToPoint2, SetConstraints, SysCon.
MechanicalSystems
490
CurveToPlane1 3D † CurveToPlane1[cnum, locuspoint, {alpha, guess}, axis] constrains the space curve defined by locuspoint to lie tangent to a plane specified by axis. The locuspoint must be defined as a parametric function of alpha. † CurveToPlane1 constrains one degree of freedom. † CurveToPlane1 generates two constraint equations and introduces one new variable, alpha, hence constraining one degree of freedom. † The first equation constrains the point of contact to lie in the plane, and the second equation constrains the direction vector of the curve at the point of contact to be orthogonal to axis, yielding two constraint equations. † See also: CurveToCylinder1, SetConstraints, SysCon.
CurveToPoint2 3D † CurveToPoint2[cnum, locuspoint, {alpha, guess}, point] constrains point to lie on the space curve defined by locuspoint. The locuspoint must be defined as a parametric function of alpha. † CurveToPoint2 constrains two degrees of freedom. † CurveToPoint2 generates three constraint equations and introduces one new variable, alpha, hence constraining two degrees of freedom. † The point of contact on the space curve is coincident with the point, yielding three linked constraint equations. † See also: CurveToPlane1, SetConstraints, SysCon.
CutOff 2D/3D † CutOff is an option for Force (and Moment in Modeler3D) that specifies a cutoff value for the magnitude of an applied load.
Appendix B: MechanicalSystems Function Listing
491
† If CutOff is nonzero, the magnitude of the load drops to one half of the specified magnitude when the length of the direction vector of the load is equal to CutOff, and the magnitude of the load drops to zero when the length of the direction vector is zero. † CutOff makes the magnitude of the applied force or moment equal to (mag †vec§) / (cutoff + †vec§), which is approximately equal to mag for †vec§ p cutoff. † A very small positive number is normally specified for CutOff so that divide by zero errors will not occur if the length of the line of action goes to zero. † CutOff has no effect if Magnitude->Relative is also given.
Cylinder 3D † Cylinder[axis, rad, facets] generates a cylinder of radius rad spanning the length of axis, with the specified number of facets. † Cylinder[axis, rad1, rad2, facets] generates a conical or tapered cylinder with radius rad1 at the origin of axis, and a radius of rad2 at the end. † Cylinder returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † Either or both radii may be replaced with a list {rx, ry} to produce a cylinder with an elliptical cross section. † The following options can be given: Angle
{0, 2π}
the start and end of the swept angle of revolution
Ends
True
whether to cap the ends with two polygons
Faces
True
whether to draw with filled polygons or wire
† A value of 4 for facets yields a square bar, rad ë
frames
è!!!! 2 across the flats.
† The Angle option allows a length-wise slice of the entire revolved bar to be drawn. † See also: Revolve, Sphere, Wheel.
MechanicalSystems
492
Cylindrical4 3D † Cylindrical4[cnum, axis1, axis2] constrains axis1 and axis2 to be parallel and coincident. † Cylindrical4 constrains four degrees of freedom. † Cylindrical4 models a hinge or revolving bearing that can translate along its axis of rotation. † The first two equations constrain the origin of axis2 to lie on axis1, and the second two equations constrain the two axes to be parallel. † See also: GenCylindrical4, ParaRevolute4, Revolute5, SetConstraints, SysCon.
CylindricalToXYZ 3D † CylindricalToXYZ[{radius, angle, altitude}] converts the given point from cylindrical to Cartesian coordinates and returns {x, y, z}. † CylindricalToXYZ accepts the Coordinates option to specify the relationship between the two coordinate systems. By default, altitude is measured in the Z direction and an angle of zero puts the point in the Y = 0 plane. Coordinates->YZX causes altitude to be measured in the X direction, and so on. † More complicated coordinate reorientations require a rotation matrix. † See also: SphericalToXYZ, XYZ, XYZToCylindrical, XYZToSpherical, ZXY.
D2DistanceDT2 2D/3D † D2DistanceDT2[point1, point2] returns the second time derivative of the absolute distance between the two points. † D2DistanceDT2[point1, point2] is equivalent to Dt[Distance[point1, point2], {T, 2}] except that the local coordinates of the points are assumed to have no implicit dependence on any Mech system variables. † See also: Distance, DDistanceDT.
Appendix B: MechanicalSystems Function Listing
493
DDistanceDT 2D/3D † DDistanceDT[point1, point2] returns the time derivative of the absolute distance between the two points. † DDistanceDT[point1, point2] is equivalent to Dt[Distance[point1, point2], T], except that the local coordinates of the points are assumed to have no implicit dependence on any Mech system variables. † See also: Distance, D2DistanceDT2.
Diagnostics 2D/3D † Diagnostics is an element of the MakeRules option setting for SolveFree or SolvePath. † Including Diagnostics in the list of symbols specified by MakeRules causes two InterpolatingFunction objects to be included in the solution returned by SolveFree that represent the maximum error in any one of the integration variables at a given time, and the step size at that time. † See also: MaxError, StepSize.
DirectedDistance1 2D/3D † DirectedDistance1[cnum, point1, point2, vector, dist] constrains point1 to lie dist units away from point2, measured in the direction of vector. † DirectedDistance1[cnum, point1, point2, vector] uses the magnitude of vector for the distance specification. † DirectedDistance1 constrains one degree of freedom. † If point2 is omitted, it is assumed to be the global origin. † See also: DirectedPosition2, PointOnLine1, PointOnPlane1, SetConstraints, SysCon.
MechanicalSystems
494
DirectedPosition2 2D † DirectedPosition2[cnum, point1, point2, vector, dist] constrains the location of point1 to be equal to the location of point2 plus a vector that is parallel to the given vector and dist units long. † DirectedPosition2[cnum, point1, point2, vector] constrains the location of point1 to be equal to the location of point2 plus the given vector. † DirectedPosition2 constrains two degrees of freedom. † If point2 is omitted, it is assumed to be the global origin. † See also: DirectedPosition3, Revolute2, SetConstraints, SysCon.
DirectedPosition3 3D † DirectedPosition3[cnum, point1, point2, vector, dist] constrains the location of point1 to be equal to the location of point2 plus a vector that is parallel to the given vector and dist units long. † DirectedPosition3[cnum, point1, point2, vector] constrains the location of point1 to be equal to the location of point2 plus the given vector. † DirectedPosition3 constrains three degrees of freedom. † If point2 is omitted, it is assumed to be the global origin. † See also: DirectedPosition2, Spherical3, SetConstraints, SysCon.
Direction 2D/3D † Direction[vector] returns the direction vector of vector in global coordinates. † Direction[axis] returns the direction vector of the specified axis. † vector may be a simple vector or a Mech vector object with head Vector, Line, or Plane (3D).
Appendix B: MechanicalSystems Function Listing
† Direction[bnum, lpnt] is interpreted as Direction[Vector[bnum, lpnt]]. † Other Direction[args, … ] instances are interpreted as Direction[Line[args]]. † Mech’s overloading of the built-in Direction symbol has no effect on its usage in other Mathematica code. † See also: Angle, Direction, Location, Magnitude, Unit.
Distance 2D/3D † Distance[point1, point2] returns the absolute distance between the two points. † Distance[point1, point2] returns the same result as Magnitude[point1, point2]. † See also: DDistanceDT, D2DistanceDT2.
Dot 2D/3D † Dot[vector1, vector2] returns the scalar dot product of the direction vectors of the two Mech vector objects. † Dot[…, vector, …] converts the Mech vector object into a normal Mathematica vector and allows Dot to proceed normally. † Mech’s overloading of the built-in Dot symbol has no effect on its usage in other Mathematica code. † See also: Cross, Direction, Dot, Magnitude, SkewSym, Unit.
495
MechanicalSystems
496
Dynamic 2D/3D † Dynamic is a setting for the Solution option for several Mech functions. † Solution->Dynamic causes such functions to seek a solution for the location, velocity, acceleration, and dynamic loading of the current model. † Dynamic is also a setting for the Type option for Loads. Type->Dynamic causes Loads to return the total inertial load on a body. † The alternatives to the Dynamic setting for the Solution option are Location, Velocity, Acceleration, Static, and Kinematic. † The alternatives to the Dynamic setting for the Type option are Applied and Reaction, which cause Loads to return external loads or kinematic reaction forces, respectively. † See also: SolveMech, SetFree.
Edge 2D/3D † Edge[bnum, {lpnt1, lpnt2, … , lpntn}] generates n – 1 lines passing from each local point to the next on body bnum. Each lpnti can be either a local point number or local point coordinate {x, y} (2D) or {x, y, z} (3D). † Edge[bnum, {lpnts1 … }, {lpnts2...}, … ] generates several sequences of lines. † Edge[{point1, … , pointn}] generates n – 1 lines spanning several different bodies. † Edge returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † The Edge function is analogous to the built-in Mathematica Line primitive. † See also: Facet, Vertex.
Appendix B: MechanicalSystems Function Listing
497
EndConditions 2D/3D † EndConditions is an option for SplineFit that is used to specify the end conditions of the spline. † EndConditions can be set to Natural, Closed, or a list of two vectors {{x1, y1}, {x2, y2}} (2D) or {{x1, y1, z1}, {x2, y2, z2}} (3D) specifying the tangency direction at the beginning and end of the spline, respectively. † If a list of two vectors is given, both their magnitude and direction are significant. † The default setting is EndConditions->Natural. † See also: SplineFunction.
Ends 3D † Ends is an option for Cylinder that specifies whether or not the ends of the cylinder are to be capped with two polygons. † Ends->False causes Cylinder to generate an open ended hollow cylinder. † The default setting is Ends->True. † See also: Faces.
Euler 2D/3D † Euler is a setting for the Method option for SetSymbols that causes all subsequently built models to use Euler parameters and their derivatives to represent angular orientation and velocity. † The alternative to the Euler setting is Angular. † In Modeler2D, the Euler solution method causes the angular orientation of a body to be represented by two parameters ei and ej, which are related to the single angular coordinate Q by ei = cos(Q) and ej = sin(Q). The angular velocity and acceleration are also represented by pairs of parameters, eind, ejnd and eindd, ejndd.
MechanicalSystems
498
† In Modeler3D, the angular orientation of a body is always represented by four Euler parameters, and with the Euler solution method the angular velocity and acceleration are also represented by derivatives of the Euler parameters. † See also: EulerParameters, Rotation.
EulerInverse 2D/3D † EulerInverse[epars] returns a list of two (2D) or four (3D) Euler parameters corresponding to the inverse of the rotation represented by epars. The function of EulerInverse is analogous to the inversion of a rotation matrix. † EulerInverse simply negates all terms but the first in the list of Euler parameters. † See also: EulerMultiply, EulerParameters.
EulerMultiply 2D/3D † EulerMultiply[epars1, epars2, … ] returns a list of two (2D) or four (3D) Euler parameters corresponding to the result of two or more sequential rotations represented by epars1, epars2, etc. The function of EulerMultiply is analogous to the noncommutative multiplication of rotation matrices. † EulerMultiply is substantially more efficient than converting two sets of Euler parameters to rotation matrices, multiplying them, and converting the result back to a set of Euler parameters. † See also: EulerInverse, EulerParameters.
EulerParameters 2D/3D † EulerParameters[bnum] returns the Euler parameters {ei, ej} (2D) or {eo, ei, ej, ek} (3D) associated with body bnum.
Appendix B: MechanicalSystems Function Listing
499
† EulerParameters[{ang}] (2D) or EulerParameters[{ang, vector}] (3D) returns Euler parameters associated with ang or ang and vector. † EulerParameters[matrix] returns the Euler parameters associated with the given 2D or 3D rotation matrix. † In Modeler2D, if the Angular solution method is specified with SetSymbols, EulerParameters returns the parameters in terms of the body’s rotation angle. With the Euler solution method EulerParameters simply returns {Eibnum, Ejbnum}. † Degenerate 2D Euler parameters are defined as 8cosHangL, sinHangL< in terms of a given angle ang.
† Euler parameters are defined as eo = cosH ÅÅÅÅ2ÅÅÅÅÅ L, and 8ei, ej, ek< = 8x, y, z< sinH ÅÅÅÅ2ÅÅÅÅÅ L í "########################## x2 + y2 + z2# in terms of an ang
ang
angle and axis of rotation. † When transforming a rotation, {ang, vector}, the Assumptions->Normalized option may be given to cause EulerParameters to assume that vector is a unit vector, thus simplifying the result. The default setting is Assumptions->None. † In Modeler3D, EulerParameters[vector] returns the four Euler parameters associated with the given virtual rotation vector. † When EulerParameters is used to transform a virtual rotation or an angle-axis, vector may be a simple vector or a Mech vector object with head Vector, Line, or Plane. † See also: Rotation, RotationMatrix, VirtualRotation.
Extrude 3D † Extrude[{point1, point2, … , pointn}, vector, dist] extrudes the sequence of n – 1 lines between the given points dist units in the direction of vector. † Extrude[bnum, {lpnt1, … , lpntn}, vector, dist] extrudes the n – 1 lines connecting the local points lpnti located on body bnum. † Extrude returns a list of Mathematica graphics primitives that are functions of mechanism location variables.
MechanicalSystems
500
† The following options can be givens: Faces
True
whether to draw with filled polygons or wire frames
Magnitude
Absolute
whether dist is multiplied by the length of vector
† Magnitude->Relative causes the extrusion distance to be equal to the length of vector times dist. † See also: Facet, Revolve.
Faces 2D/3D † Faces is an option for Bar, Box, Extrude, Revolve, Sphere, Torus, and Wheel to specify whether faces of polygons should be filled or rendered as wire frames. † Faces->False causes graphics objects to be rendered as wire frames. † The default setting is Faces->True. † See also: Angle.
Facet 2D/3D † Facet[bnum, {lpnt1, lpnt2, … , lpntn}] generates a filled polygon with vertices at each of the lpnti on body bnum. Each lpnti can be either a local point number or local point coordinate {x, y} (2D) or {x, y, z} (3D). † Facet[bnum, {lpnts1, … }, {lpnts2, … }, … ] generates several polygons. † Facet[{point1, … , pointn}] generates an n-sided polygon with vertices on several different bodies. † Facet returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † The Facet function is analogous to the built-in Mathematica Polygon primitive. † See also: Bar, Box, Edge, Extrude, Vertex, Wheel.
Appendix B: MechanicalSystems Function Listing
501
FindSwitchTime 2D/3D † FindSwitchTime[cnum, snum, options] seeks the point in time at which the two constraints in TimeSwitch number cnum separated by switch time number snum are both satisfied. † The switch time number snum specifies which stage of the TimeSwitch is under consideration. For example, a TimeSwitch constraint with three constraints has two switch times, numbers 1 and 2, between the three constraints. † The following options can be givens: DampingFactor
1
damping factor applied at each iteration step
MaxIterations
15
the maximum number of iterations allowed
RequiredEquations
{All, Sum}
which equations to consider in a multi-equation constraint
TangentConstraint
False
whether to seek a solution where two constraints approach each other tangentially
ZeroTest
{Abs[#]<10^-9&)
a test to determine when a solution is sufficiently close to zero
† See also: FindTime.
FindTime 2D/3D † FindTime[eqn] seeks the solution to the current model that satisfies the given equation eqn with time treated as a dependent variable. The equation must have the head Equal.
MechanicalSystems
502
† The following options can be given: DampingFactor
1
damping factor applied at each iteration step
MaxIterations
15
the maximum number of iterations allowed
Solution
Automatic
what solution level to seek
ZeroTest
{Abs[#]<10^-9&)
a test to determine when a solution is sufficiently close to zero
† The default setting for the Solution option, Automatic, causes FindTime to examine the symbols in eqn and choose a Solution setting that is sufficient to provide values for the symbols found. † If symbols are found in eqn that would not be satisfied by the requested Solution level, the Solution level is overridden with a higher-order solution level than is requested. For example, if the equation supplied to FindTime contains velocity and lambda terms and Solution->Location is given, FindTime uses the Kinematic setting to satisfy all of the symbols in eqn. † If the equation contains only location and lambda terms and a dynamic solution is desired, Solution->DyÖ namic must be given because FindTime would choose to use Static by default. † See also: FindSwitchTime, SetCouple, SolveCouple.
FitDegree 2D/3D † FitDegree is an option for SolveFree and SolvePath that specifies the degree of polynomial that is used to approximate each section of the integrand at each time step. † Valid settings for FitDegree are Linear, Quadratic, Cubic, and Quartic. † The default setting is FitDegree->Cubic. † See also: Method.
Force 2D/3D † Force[bnum, axis, mag] returns a SysLoad data object that applies a force to body bnum of magnitude mag along the specified axis.
Appendix B: MechanicalSystems Function Listing
503
† Force[bnum1, bnum2, … ] applies the force to body bnum1 and also applies a force in the opposite direction to body bnum2. † After creation, the SysLoad object is passed to SetLoads to alter the state of the current Mech model. † The following options can be given: CutOff
0
allow the length of axis to approach zero without a singularity
Magnitude
Absolute
whether dist is multiplied by the length of vector
† Magnitude->Relative causes the magnitude of the applied force to be equal to the specified mag times the length of axis. † See also: Body, Gravity, Load, Moment.
Free 2D/3D † Free is a setting for the Time option for SetCouple that is used to omit the time specification so that time becomes a dependent variable to be solved for. † The alternative to Free is to specify a numerical value for time, † The Free setting can be used only in SetCouple when the system is built, not in SolveCouple. † See also: FindTime.
FreeSystem 2D/3D † FreeSystem is the head of the data object returned by SetFree. † The output format of the FreeSystem data object is FreeSystem[solution, <>], where solution is the setting for the Solution option in SetFree. † The second element of a FreeSystem object is True for nonlinear systems, and False for linear ones.
MechanicalSystems
504
† FreeSystem is not intended to be used external to Mech. † See also: SolveFree.
FunctionOfTime 2D/3D † FunctionOfTime is an option for SolveMech and other Mech functions that causes returned InterpolatingFunction objects to be explicitly functions of the current time variable. † If FunctionOfTime->True is given, a list of the form {var->InterpolatingFunction[<>][T], … } is returned. † If FunctionOfTime->False is given, the resulting rules will give functions that must each be given a numerical argument before it evaluates to a number. † The default setting is FunctionOfTime->True. † See also: SolveFree, SolvePath, TimeInterpolate.
GenConstraint 2D/3D † GenConstraint[cnum, point1, point2, rot, {sym, guess}] returns a constraint object that introduces a slave body represented by generalized coordinates into the model. A point on the slave body, point1, is constrained to be coincident with a point on the master, point2. The angular orientation of the slave with respect to the master is specified by rot. † In Modeler2D, rot is a counterclockwise angle or a list of two degenerate Euler parameters {ei, ej}. † In Modeler3D, rot is specified by an angle and an axis of rotation in the {ang, axis} format. † {sym, guess} or {sym1, guess1}, {sym2, guess2}, … are generalized coordinate symbols and their associated initial guesses that are added to the model. The number of degrees of freedom added to the model is equal to the number of sym-guess pairs. † GenConstraint is used to create user-defined generalized coordinate relationships. Mech generalized coordinate constraints do not actually constrain any degrees of freedom or add any algebraic constraints to the model, they simply set up the necessary coordinate transformations so that a new slave body can be recognized appropriately by Mech’s modeling engine.
Appendix B: MechanicalSystems Function Listing
505
† In Modeler2D, the rotation may also be specified by a list of degenerate Euler parameters {ei, ej}. † In Modeler3D, rot can be a single rotation or a sequence of rotations of the form used by RotationLock3. † In Modeler3D, each successive rotation may also be specified by a list of Euler parameters {eo, ei, ej, ek} or a virtual rotation vector {vx, vy, vz}. † See also: Constraint.
GenCylindrical4 3D † GenCylindrical4[cnum, axis1, axis2, {alpha, guess}, {beta, guess}] returns a constraint object that introduces a slave body into the model represented by two generalized coordinates alpha and beta. † The axis1 body is a slave to the axis2 body with one degree of rotational freedom and one degree of translational freedom. The two axes are constrained to be colinear and the distance from the origin of axis2 to that of axis1, in the direction of axis2, is represented by alpha. The angle from the projection of the reference direction of axis2 to that of axis1, in the right-hand sense, is represented by beta. † Note that GenCylindrical4 actually adds two degrees of freedom to the model, as opposed to constraining four. † See also: Cylindrical4, SetConstraints, SysCon.
Generalized 2D/3D † Generalized[cnum] returns the list of generalized forces, or Lagrange multipliers (Λ1, Λ2, … ) associated with constraint cnum in the current model. † The cnum argument can take any of the forms accepted by Constraints to obtain velocity terms from multiple constraints. † Generalized is also an element of the MakeRules option setting. † MakeRules->{… , Generalized, … } causes the generalized forces to be included in the interpolated rules returned.
MechanicalSystems
506
† Generalized[All] returns the entire vector of Lagrange multipliers. † The generalized force vector contains one Lagrange multiplier, Λn, for each constraint equation in the current system. † Transpose[Jacobian[cnum, All]].Generalized[cnum] == Loads[All] returns the entire static force balance equation associated with constraint cnum. † The value of the Lagrange multipliers cannot be directly interpreted as a force or moment without some understanding of the explicit form of the mechanism equations. Use the Reaction function to convert generalized loads into the reaction forces at each constraint. † See also: Centrifugal.
GenOrthoRevolute4 3D † GenOrthoRevolute4[cnum, axis1, axis2, {alpha, guess}, {beta, guess}] returns a constraint object that introduces a slave body into the model represented by two generalized coordinates alpha and beta. † The axis1 body is a slave to the axis2 body with two degrees of rotational freedom. The origins of the two axes are constrained to be coincident, and the axes are constrained to be orthogonal. The symbol alpha represents the angle between axis1 and the reference direction of axis2, and beta represents the angle between axis2 and the reference direction of axis1. † Note that GenOrthoRevolute4 actually adds two degrees of freedom to the model, as opposed to constraining four. † See also: OrthoRevolute4, SetConstraints, SysCon.
GenRevolute2 2D † GenRevolute2[cnum, axis1, axis2, {sym, guess}] returns a constraint object that introduces a slave body into the model represented by a single generalized coordinate sym. † The axis1 body is a slave to the axis2 body with one degree of rotational freedom. The origins of the two axes are constrained to be coincident, and the counterclockwise angle from axis2 to axis1 is represented by sym.
Appendix B: MechanicalSystems Function Listing
† Note that GenRevolute2 actually adds one degree of freedom to the model, as opposed to constraining two degrees of freedom like Revolute2. † See also: Revolute2, SetConstraints, SysCon.
GenRevolute5 3D † GenRevolute5[cnum, axis1, axis2, {sym, guess}] returns a constraint object that introduces a slave body into the model represented by a single generalized coordinate sym. † The axis1 body is a slave to the axis2 body with one degree of rotational freedom. The two axes are constrained to be parallel and their origins are constrained to be coincident. The angle from the projection of the reference direction of axis2 to that of axis1, in the right-hand sense, is represented by sym. † Note that GenRevolute5 actually adds one degree of freedom to the model, as opposed to constraining five degrees of freedom like Revolute5. † See also: Revolute5, SetConstraints, SysCon.
GenTranslate2 2D † GenTranslate2[cnum, axis1, axis2, {sym, guess}] returns a constraint object that introduces a slave body into the model represented by a single generalized coordinate sym. † The axis1 body is a slave to the axis2 body with one degree of translational freedom. The two axes are constrained to be colinear, and the distance from the origin of axis2 to that of axis1, in the direction of axis2, is represented by sym. † Note that GenTranslate2 actually adds one degree of freedom to the model, as opposed to constraining two degrees of freedom like Translate2. † See also: SetConstraints, SysCon, Translate2.
507
MechanicalSystems
508
GenTranslate5 3D † GenTranslate5[cnum, axis1, axis2, {sym, guess}] returns a constraint object that introduces a slave body into the model represented by a single generalized coordinate sym. † The axis1 body is a slave to the axis2 body with one degree of translational freedom. The two axes are constrained to be colinear, and the distance from the origin of axis2 to that of axis1, in the direction of axis2, is represented by sym. The projections of the reference directions of the two axes are constrained to be parallel. † Note that GenTranslate5 actually adds one degree of freedom to the model, as opposed to constraining five degrees of freedom like Translate5. † See also: SetConstraints, SysCon, Translate5.
Global 2D/3D † Global is a setting for the Coordinates option that causes results to be returned in the global coordinate system. † The alternative to the Global setting is Local. † See also: Reaction, SetSymbols.
Gravity 2D/3D † Gravity[vector, G] returns a list of SysLoad data objects that apply a force of magnitude mass × G in the direction of vector to the centroid of each body in the current model. † Gravity[vector, G, {bnum1, bnum2, … }] applies the gravitational force only to the bodies specified by their body numbers. † The value of mass is taken from the current inertia properties of each body, as specified with the Mass option to Body.
Appendix B: MechanicalSystems Function Listing
509
† Gravity accepts the Magnitude option to determine whether the magnitude of the gravitational force is equal to G, or equal to the magnitude of vector times G. The default setting is Magnitude->Absolute. † After creation, the SysLoad object is passed to SetLoads to alter the state of the current Mech model. † When Gravity is called without an explicit body number specification, a list load objects is returned corresponding to each body in the current model. If new bodies are added to the model, Gravity must be rerun to reflect the changes. † See also: Force, Load, Relative.
GyroFilter 3D † GyroFilter[{Ixx, Iyy, Izz, Ixy, Iyz, Izx}, {x, y, z}] returns a new set of inertia properties that have zero inertia in the direction of {x, y, z}. † The vector {x, y, z} must be a principal axis of the inertia properties, and the two principal moments not associated with {x, y, z} must be equal. † Inertia[GyroFilter[inertia, vector]] . vector always returns the zero vector, which shows that a body represented by the new inertia properties has no angular momentum if rotating about vector. † GyroFilter is normally used to filter out components of the inertia tensor that are modeled as zero-torque spinning motion with GyroMoment. † It is never necessary to use GyroFilter if the gyro body is attached to the rest of the model by a zero-torque constraint, like a revolute or cylindrical joint. † Use Inertia->GyroFilter[inertia, vector] as an option for Body to eliminate the axial torques related to angular acceleration of the body, and then use the unfiltered inertia properties with GyroMoment to model the gyroscopic torques. † The inertia properties may also be given as a full inertia matrix. † See also: ParallelAxis, PrincipalAxes.
MechanicalSystems
510
GyroMoment 3D † GyroMoment[bnum, vec, omega] returns a SysLoad data object that applies a moment to body bnum to simulate the gyroscopic effects of the axially symmetric body spinning with angular speed omega, about an axis originating from the centroid of the body, parallel to vec. The constant angular velocity omega is relative to the local reference frame of bnum. † After creation, the SysLoad object is passed to SetLoads to alter the state of the current Mech model. † GyroMoment accepts the Inertia option to specify the inertia properties of the spinning body. † If Inertia is unspecified, the inertia properties are taken from body bnum. † GyroMoment produces meaningful results only if the vector vec is parallel to a principal moment of inertia of the body, and if the other two principal moments are equal in magnitude. This implies that the body must be axially symmetric about the vector vec. † GyroMoment essentially models body bnum as if it were spinning at a constant velocity relative to its own local coordinates system. † To model zero-torque motion, instead of constant velocity, use GyroFilter to remove the components of the inertia tensor that are aligned with vec from the body’s inertia tensor. † See also: Body, Load, Moment.
HeadSize 2D/3D † HeadSize is an option for Arrow that specifies the width of the arrowhead. † The default setting HeadSize->Automatic makes the head of the arrow 1/5 of its length. † See also: Magnitude.
Appendix B: MechanicalSystems Function Listing
511
HelpModel2D 2D † HelpModel2D is a package containing the model that is used throughout the MechanicalSystems help to demonstrate various functionality. † <<MechanicalSystems`HelpModel2D` defines and loads the 2D help model. † See the Details section below to see a listing of the specific parts of the help model. † The help model defines the following functions: DefineHelpModel[]
define all of the body, constraint, and load objects in the help model
BuildHelpModel[]
load the bodies, constraints, and loads into the current model
ShowHelpModel[rules, graphicsoptions]
show a graphic of the help model, locating the bodies according to
ClearHelpModel[]
clear the current model and clear all variables defined by the help model
rules
† Loading the HelpModel2D package automatically calls DefineHelpModel[] and BuildHelpModel[]. † The model is ready to be solved with SolveMech after calling BuildHelpModel. † To make small changes to the help model, make the required changes to the body/constraint/load objects and then call BuildHelpModel again. † If the rules are omitted from ShowHelpModel, LastSolve[] is used. † If the rules are a nested list of rules, ShowHelpModel generates a sequence of graphics that can be used as an animation. † See also: HelpModel3D.
HelpModel3D 3D † HelpModel3D is a package containing the model that is used throughout the MechanicalSystems help to demonstrate various functionality. † <<MechanicalSystems`HelpModel3D` defines and loads the 3D help model.
MechanicalSystems
512
† See the Details section below to see a listing of the specific parts of the help model. † The help model defines the following functions: DefineHelpModel[]
define all of the body, constraint, and load objects in the help model
BuildHelpModel[]
load the bodies, constraints, and loads into the current model
ShowHelpModel[rules, graphicsoptions]
show a graphic of the help model, locating the bodies according to
ClearHelpModel[]
clear the current model and clear all variables defined by the help model
rules
† Loading the HelpModel3D package automatically calls DefineHelpModel[] and BuildHelpModel[]. † The model is ready to be solved with SolveMech after calling BuildHelpModel. † To make small changes to the help model, make the required changes to the body/constraint/load objects and then call BuildHelpModel again. † If the rules are omitted from ShowHelpModel, LastSolve[] is used. † If the rules are a nested list of rules, ShowHelpModel generates a sequence of graphics that can be used as an animation. † See also: HelpModel2D.
IMatrix 2D/3D † IMatrix returns the 2D (2D) or 3D (3D) identity matrix. † See also: RMatrix, RotationMatrix.
IncludedAngle 2D/3D † IncludedAngle[vector1, vector2] returns the positive angle between the global direction vectors of the two Mech vector objects.
Appendix B: MechanicalSystems Function Listing
† The range of IncludedAngle is [0, p]. † See also: Angle, Direction, Rotation.
Inertia 2D/3D † Inertia is an option for Body that specifies the centroidal rotational inertia of a body. † The polar moment of inertia is specified by a scalar in Modeler2D. † In Modeler3D, the inertia is given as a list of six expressions corresponding to {Ixx, Iyy, Izz, Ixy, Iyz, Izx} for the body. The inertia matrix is then of the form {{Ixx, Ixy, Izx}, {Ixy, Iyy, Iyz}, {Izx, Iyz, Izz}}. Inertia can also be given as the full inertia matrix. † Inertia[bnum] returns the inertia (2D) or inertia properties (3D) of body bnum. † The inertia of each body is initially zero, unless otherwise specified. † The default setting Inertia->Automatic leaves the current inertia properties unchanged. † In Modeler3D, Inertia is also an option for GyroMoment. † See also: Centroid, InertiaMatrix, Mass, SetBodies.
InertiaMatrix 3D † InertiaMatrix[inertia] returns the symmetric inertia matrix associated with the given inertia properties. ij Ixx Ixy Izx yz jj zz † InertiaMatrix[{Ixx, Iyy, Izz, Ixy, Iyz, Izx}] returns jjjj Ixy Iyy Iyz zzzz. jj zz k Izx Iyz Izz { † See also: Inertia, MassMatrix, SkewSym.
513
MechanicalSystems
514
InitialCondition 2D/3D † InitialCondition is an option for several Mech functions that specifies initial conditions to be used in subsequent solutions. InitialCondition should specify rules giving the values of current system-dependent variables, or current parameters, or time. † The default setting InitialCondition->Automatic takes the initial conditions from the current default initial guess from LastSolve. † Any variables omitted from the InitialCondition setting are given values taken from the current initial guess or parameters lists. † The setting for the InitialCondition option takes a special form for SolveCouple. † See also: InitialGuess, SetFree, SetPath, SetSensitivity, SolveCouple, SolveFree.
InitialGuess 2D/3D † InitialGuess is an option for Body that specifies the initial guesses for a body’s location coordinates in the form InitialGuess->{{x, y}, q} (2D) or InitialGuess->{{x, y, z}, {eo, ei, ej, ek}} (3D). † InitialGuess[bnum] returns the current initial guesses of body bnum in the formats noted above. † InitialGuess is also an option for SetCouple that specifies initial guess for all coordinates as a list of rules. Rules are given in the same format as rules for SetGuess. † InitialGuess is also an option for SetFree that specifies initial guesses for the dependent variables in the system as a list of rules. Lower-order terms (independent variables) are given with InitialCondition. Rules are given in the same format as rules for SetGuess. † If no initial guess is specified for a body, the initial guess is in alignment with the global coordinate system. † The default setting InitialGuess->Automatic leaves the current guesses unchanged. † In Modeler2D, initial guesses may also be specified in the format {{x, y}, {ei, ej}} where the degenerate Euler parameters ei and ej are immediately converted to Q.
Appendix B: MechanicalSystems Function Listing
515
† In Modeler3D, initial guesses may also be specified in the format {{x, y, z}, {vx, vy, vz}} where the second element is a virtual rotation vector, or the format {{x, y, z}, {q, {x, y, z}}} where the second element is an angle and axis of rotation. The given rotation is immediately converted to a set of Euler parameters. † See also: Centroid, Inertia, PointList, Mass, SetBodies.
InstantCenter 2D/3D † InstantCenter[bnum] returns the coordinates of the instant center of zero velocity of body bnum. † InstantCenter accepts the Coordinates option to determine whether to return the result in Global or body Local coordinates. † In Modeler3D, InstantCenter returns a point on the instant axis of rotation. † The default option setting is Coordinates->Global. † In general, a spatial body will not have an instant center of zero velocity, but it will have an instant axis of rotation. The direction vector of the instant axis of rotation is equal to the angular velocity vector of the body, Omega[bnum]. All points on this axis will have identical velocity vectors. † See also: Omega, RelativeVelocity, Velocity.
Interference 2D † Interference is an option for Involute. † Interference->True specifies that the involute locus will blend into a straight line from the point where the involute meets the base circle to the center of the base circle. † The default setting is Interference->False. † If Interference is set to False, the natural equation of an involute tooth profile goes through a first-order singularity at the point where the tooth profile meets the base circle (when the value of the controlling parameter is zero) and then forms a mirror image of the tooth for negative values of the controlling parameter. † See also: Constraint.
MechanicalSystems
516
IntersectionPoint 2D/3D † IntersectionPoint[axis1, axis2] returns the point of intersection of axis1 and axis2 in global 2D space, or the point of intersection of axis1 and a plane that is normal to axis2 in global 3D space. In 3D, axis2 is typically a Plane object. † In Modeler2D, IntersectionPoint[axis1, axis2, offset] returns a point that is located offset units to the left of both axes (such as the center point of a fillet between the two axes). † See also: Location.
Involute 2D † Involute[sym, {x, y}, baseradius, pitchradius, angle] returns the equation of an involute gear tooth as a function of the parameter sym. The involute has a base circle of baseradius centered at {x, y}. † The involute profile is rotationally located such that the point where the profile intersects the pitch circle lies on a ray that passes through {x, y} in the direction of the specified angle. † If pitchradius is negative then the profile spirals in the clockwise direction, otherwise it spirals in the counterclockwise direction. † The involute locus travels from the base circle to the pitch circle, as sym goes from 0 to "########################################################## pitchradius2 - baseradius2 í baseradius. † Involute accepts the Interference option. † With the Interference option the locus travels from the base circle to the center of the gear as sym goes from 0 to –1. † See also: CamToCam1.
Appendix B: MechanicalSystems Function Listing
Jacobian 2D/3D † Jacobian[cnum, bnum] returns the submatrix of the current Jacobian associated with constraint cnum and body bnum. † The cnum argument can take any of the forms accepted by Constraints to obtain Jacobian terms from multiple constraints. † The bnum argument can take any of the forms accepted by Loads to obtain Jacobian terms from multiple bodies. † Jacobian[All, All] returns the entire Jacobian matrix. † See also: Constraint.
JoinRows 2D/3D † JoinRows[mat1, mat2, … ] returns a new matrix composed of the mati with their rows joined. The mati must all have the same number of rows. † JoinRows effectively joins matrices left-to-right, instead of top-to-bottom. † See also: Join, MapThread.
KillMech 2D/3D † KillMech[] completely removes the Mech packages from the current Mathematica session. All the symbols in the MechanicalSystems`Modeler2D` or MechanicalSystems`Modeler3D` contexts are removed, as well as the contexts themselves. † Using KillMech allows Mech to be reloaded with Get or Needs without error. † See also: ClearMech.
517
MechanicalSystems
518
Kinematic 2D/3D † Kinematic is a setting for the Solution option for several Mech functions. † Solution->Kinematic causes such functions to seek a solution for the location, velocity, and velocity-dependent loading of the current model. † The alternatives to the Kinematic setting are Location, Velocity, Acceleration, Static, and Dynamic. † The Kinematic setting should be used when a model contains applied loads that are functions of mechanism velocity. If the Static setting is used in such cases, all velocities are set to zero. † See also: SolveMech, SetFree.
LambdaGuess 2D/3D † LambdaGuess is an option for SetLoads that specifies the initial guesses for the Lagrange multipliers. † LambdaGuess->number specifies the same guess for all Lagrange multipliers. † LambdaGuess->{rules} sets the values of specific Lagrange multipliers given in rules. † LambdaGuess->{numbers} sets the values of all Lagrange multipliers. The list of numbers must be of the same length as Generalized[All]. † Unspecified guesses for the Lagrange multipliers are initially set to one. † LambdaGuess->Automatic leaves the current values of the guesses unchanged. † The default setting is LambdaGuess->Automatic. † See also: InitialGuess, SetGuess.
Appendix B: MechanicalSystems Function Listing
519
LastSolve 2D/3D † LastSolve[] returns the last solution rule returned by SolveMech. The values returned by LastSolve[] are used as the initial guesses at the next invocation of SolveMech. † LastSolve[All] includes the values that will be used the next time that initial guesses for the Lagrange multipliers are needed, regardless of whether or not they were part of the last solution returned by SolveMech. † See also: SetGuess.
LeadScrew5 3D † LeadScrew5[cnum, axis1, {alpha, guess}, axis2, pitch, C] models a lead screw. axis1 is constrained to be parallel and coincident with axis2, and the axial translation of the two axes is controlled per the pitch and relative rotation of the two parts of the screw. † The relative angular orientation of the two parts is determined by the angle between the reference directions of axis1 and axis2. † LeadScrew5 constrains five degrees of freedom. † The symbol alpha tracks the spin of axis1, relative to axis2. † The constant C is the distance from the origin of axis2 to the origin of axis1 when the relative rotation between the two parts of the screw is zero. † LeadScrew5 generates six constraint equations and introduces one new variable, hence constraining five degrees of freedom. † The first two equations in LeadScrew5 constrain the origin of axis2 to lie on axis1, the next two equations constrain the two axes to be parallel, the fifth equation relates the axial displacement of the screw to the rotational displacement, and the sixth relates the value of the variable alpha to the rotational displacement. † See also: Cylindrical4, ParallelGears5, SetConstraints, SysCon.
MechanicalSystems
520
Line 2D/3D † Line[point1, point2] is a Mech data object that specifies an axis by endpoints. The axis originates at point1 and terminates at point2. The pointi must be Mech Point objects. † Line[bnum, lpnt1, lpnt2] is interpreted as Line[Point[bnum, lpnt1], Point[bnum, lpnt2]]. The lpnti can be points, {x, y} (2D) or {x, y, z} (3D), in the local coordinate system of body bnum or point numbers (positive integers) referencing coordinates that were defined with SetBodies. † If a Line object is used in place of a Mech Vector object, the vector from point1 to point2 provides the direction of the vector. † If a Line object is used in place of a Mech Axis object, the line’s origin (point1) provides the origin of the axis and the direction of the line provides the direction of the axis. † The rotational reference direction of a Line object cannot be explicitly specified. † Mech’s overloading of the built-in Line symbol has no effect on its usage in other Mathematica code. † See also: Line, Plane, ReferenceDirection.
Linear 2D/3D † Linear is a setting for the FitDegree option for SolveFree and SolvePath. Linear specifies a linear approximation of each section of the integrand. † Linear is generally less accurate than the higher-degree fits. † Linear works well with systems that have many force discontinuities because fewer back-steps are required to auto-adjust the time step size when a discontinuity is encountered. † See also: Cubic, Quadratic, Quartic.
Appendix B: MechanicalSystems Function Listing
521
LineOnCylinder3 3D † LineOnCylinder3[cnum, axis1, axis2, rad] constrains axis1 to lie parallel to axis2, and rad units away from axis2. † LineOnCylinder3 constrains three degrees of freedom. † LineOnCylinder3 becomes singular if rad is set to zero. Cylindrical4 should be used instead. † The first two equations constrain the two axes to be parallel, the third equation constrains the two axes to lie rad units apart. † See also: LineToLine1, ParaRevolute4, SetConstraints, SysCon.
LineToCircle1 3D † LineToCircle1[cnum, axis1, axis2, rad] constrains axis1 to pass through the perimeter of a circle of radius rad. The axis of the circle is specified by axis2 and the center of the circle lies at the origin of axis2. † LineToCircle1 constrains one degree of freedom. † LineToCircle1 can be used to model a shaft in a bearing with specified clearance. † See also: PlaneToCircle1, PointOnCircle2, SetConstraints, SysCon.
LineToLine1 3D † LineToLine1[cnum, axis1, axis1, dist] constrains the minimum orthogonal distance between the two axes to be equal to dist units. † LineToLine1[cnum, axis1, axis2] constrains the two axes to intersect. † LineToLine1 constrains one degree of freedom.
MechanicalSystems
522
† The LineToLine1 constraint could also be thought of as a “LineToCylinder1” constraint in which a line in space is constrained to be in contact with a cylindrical surface with a specified axis and radius dist. † See also: LineToPlane2, PointOnLine2, SetConstraints, SysCon.
LineToPlane2 3D † LineToPlane2[cnum, axis1, axis2, dist] constrains the direction of axis1 to be orthogonal to the direction of axis2, and constrains the origin of axis1 to lie dist units away from the origin of axis2, measured in the direction of axis2. † LineToPlane2 constrains two degrees of freedom. † LineToPlane2[cnum, axis1, axis2] constrains axis1 to lie within the plane normal to axis2. axis2 is typically given as a Modeler3D Plane object. † The first equation constrains axis1 and axis2 to be orthogonal, the second constrains the origin of axis1 to lie in a plane normal to axis2. † See also: PlaneToPlane3, PointOnPlane1, SetConstraints, SysCon.
Load 2D/3D † Load[sym, mag] returns a SysLoad data object that applies a load of magnitude mag directly to coordinate sym. † After creation, the SysLoad object is passed to SetLoads to alter the state of the current Mech model. † The Load function is used to add expressions directly to the model’s load vector without any coordinate transformation so that loads may be applied directly to generalized coordinates. † For example, if a coordinate len in a model represented the distance between two points, Load[len, 2] would apply a two-unit force tending to separate the two points. † If the Angular solution method is current in a Modeler3D model, Load can be used to apply a moment directly to an angular velocity coordinate. In this case the setting of Coordinates solution method also effects the result. † If the Euler solution method is current in a Modeler3D model, Load can be used to apply a load directly to the Euler coordinates only.
Appendix B: MechanicalSystems Function Listing
523
† For example, if the Angular, Local solution method is current, Load[Ωx2, 3] applies a 3 unit moment to body 2 directed along the local X axis. † See also: Constraint, Force, Gravity, Moment.
Loads 2D/3D † Loads[bnum] returns the total external load applied to body bnum. † Loads[{bnum1, bnum2, … }] returns the subset of the applied load vector associated with the bnumi. † Loads[All] returns the entire applied load vector. † Loads[Rest] returns the subset of the applied load vector that is associated with derivatives of generalized coordinates, such as the extra variables introduced by cam constraints. † Loads[sym] returns the element of the load vector associated with coordinate sym. † Loads[{sym1, … , symn}] returns the subset of the applied load vector associated with several coordinate symbols. † The symi must be location coordinates as returned by Location[bnum] or, if the current Modeler3D solution method is Angular, angular velocity coordinates as returned by Omega[bnum]. † The following options can be givens: Coordinates
Automatic
whether the result should be in Local or Global coordinates
Type
Applied
whether to return Applied, Reaction, or Dynamic loads
† The default setting Coordinates->Automatic returns the loads in the current default coordinate system. † If Coordinates->Automatic is given and the current coordinate system is Euler, a list of seven loads is returned in Euler coordinates. † If either the Global or Local setting is given for Coordinates, the argument must be a single body number bnum. In this case Loads returns a two-element list of the form {force, moment}. † Type->Reaction may be given to return the total reaction force applied by all constraints to the body. † Type->Dynamic may be given to return the total inertial load on the body.
MechanicalSystems
524
† For example: Loads[n, Type->Applied] + Loads[n, Type->Dynamic] + Loads[n, Type->Reac tion] /. SolveMech[ … , Solution->Dynamic] should always return a zero vector. † See also: Constraints.
Local 2D/3D † Local is a setting for the Coordinates option that causes results to be returned relative to the local coordinate system of a body. † The alternative to the Local setting is Global. † See also: Reaction, SetSymbols.
LocalAxes 2D/3D † LocalAxes[bnum, size] returns a graphics object placing local xy or xyz axes of specified size at the origin of body bnum. † LocalAxes[{bnum1, bnum2, … }, size] places axes on several bodies. † LocalAxes[All, size] places axes on all bodies in the current model. † LocalAxes returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † See also: Arrow, PointLabel.
Location 2D/3D † Location[point] returns the global coordinates, {x, y} or {x, y, z}, of the specified point. † Location[axis] returns the global coordinates of the origin of the specified axis. † Location[bnum, lpnt] is interpreted as Location[Point[bnum, lpnt]]. † Location[bnum] returns the location and angular orientation coordinates of body bnum in a flat list.
Appendix B: MechanicalSystems Function Listing
525
† The bnum argument can take any of the forms accepted by Loads to obtain the location coordinates of multiple bodies. † Location is also a setting for the Solution option for several Mech functions. † Solution->Location causes such functions to seek a solution for only the location of the current model. † Location[All] returns the entire vector of dependent variables. † To use Location[bnum], bnum must be the number of a body in the current model. † In Modeler2D, the behavior of Location[bnum] varies depending on whether the current solution method is Angular or Euler. With the Euler solution method, Location[2] returns {X2, Y2, Ei2, Ej2}, while with the Angular solution method, Location[2] returns {X2, Y2, Θ2}. † Modeler3D always represents angular orientation with four Euler parameters. † The alternatives to the Location setting for the Solution option are Velocity, Acceleration, Static, Kinematic, and Dynamic. † See also: Rotation, SolveMech, SetCouple.
LockMech 2D/3D † LockMech[t] finds a solution to the mechanism equations at time t and then embeds the numerical values of the dependent variables into the mechanism equations so that they cannot be changed until a new system is built with SetConstraints. † The LockMech command is useful when a mechanism is to be analyzed repeatedly through changing velocities, accelerations, or forces, at a constant location, velocity, or acceleration. † The Solution option can be given to specify what order of dependent variables to lock. † Valid settings for Solution are Location, Velocity, and Acceleration. † For example, Solution->Velocity locks the position and velocity of the model, so that accelerations and loads can still be calculated. † The default option is Solution->Location. † Using LockMech significantly accelerates the operation of the higher-order and load solution blocks as it is no longer necessary to perform the replacement and evaluation of the unchanging variables. † See also: CheckRules, Compiled.
MechanicalSystems
526
LocusPlot 2D/3D † LocusPlot[point, {{rules1}, {rules2}, … , {rulesn}}] returns a graphics primitive representing the locus of point as it moves through successive locations specified by the rulesi. † LocusPlot simply returns a list of Mathematica Line primitives. † The required list of rulesi is of the form returned by SolveMech[{t1, t2, ti}, n]. † See also: CamPlot.
MakeRules 2D/3D † MakeRules is an option for SolveMech and other functions that is used to specify which dependent variables to generate InterpolatingFunction objects for. † The default setting MakeRules->{Parameters, Location, Generalized} generates rules for the location coordinates (X2, Y3, …) and the generalized forces (Λ1, Λ2, …), if they are present, and also any system parameters. † Settings for MakeRules may be any subset of {Parameters, Location, Velocity, Acceleration, Generalized, Diagnostics}. † MakeRules has no effect unless Interpolation->True is given. † The parameters and other constants are not interpolated. † See also: Interpolation.
Magnitude 2D/3D † Magnitude[vector] returns the length of vector. † vector may be a simple vector or a Mech vector object with head Vector, Line, or Plane (3D). † Magnitude is also an option for Force and Moment (3D). Magnitude->Relative causes the magnitude of the applied load to be multiplied by the length of the load vector.
Appendix B: MechanicalSystems Function Listing
† Magnitude is also an option for Extrude (3D). Magnitude->Relative causes the extrusion distance to be multiplied by the length of the extrusion vector. † Magnitude->Absolute causes the magnitude of the applied load or the extrusion distance to be equal to the specified magnitude. † Magnitude[bnum, lpnt] is interpreted as Magnitude[Vector[bnum, lpnt]]. † Other Magnitude[args, … ] instances are interpreted as Magnitude[Line[args]]. † The default setting is Magnitude->Absolute. † See also: Direction, Distance, Unit.
Mass 2D/3D † Mass is an option for Body that specifies the mass of a body. † Mass[bnum] returns the mass of body bnum. † The mass of each body is initially zero, unless otherwise specified. † The default setting Mass->Automatic leaves the current mass unchanged. † See also: Centroid, Inertia, SetBodies.
527
MechanicalSystems
528
MassMatrix 2D/3D † MassMatrix[bnum] returns the submatrix of the current system mass matrix associated with body bnum. † The bnum argument can take any of the forms accepted by Loads to obtain a submatrix associated with multiple bodies. † MassMatrix[All] returns the entire system mass matrix. † Centrifugal[All] + MassMatrix[All] . Acceleration[All] returns the entire dynamic load vector. † In Modeler3D, if and only if the current solution method is Angular and the current coordinate system is Local will the system mass matrix be a matrix of constants. Otherwise it will generally be a function of Euler coordinates. † See also: Loads.
MaxError 2D/3D † MaxError is an option for SolveFree and SolvePath that is used to specify the maximum allowable estimated error in any dependent variable in a single time step. † If MaxError is exceeded at any time step, the time step size is halved. † The default error estimation algorithm used by SolveFree assumes that the average magnitude of each of the dependent variables is near to one (which is clearly true for the Euler parameters or angular variables in units of radians). † Setting MaxError to a larger value effectively relaxes the error estimation criteria that are used to adjust the time step size. † The MaxError option can also be used to explicitly specify the error limits at which the time step size is halved or doubled, or when a corrective versus predictive step is taken. † MaxError->{a, b, c} specifies that the time step size will be halved if the maximum error in the current step is greater than a. The step size will be doubled if the maximum error in any of the last 2n steps drops below c, where n is the degree of the integrand fitting polynomial. An Adams-Moulton corrective step will be taken if the error in the current step is between a and b.
Appendix B: MechanicalSystems Function Listing
† The default setting is MaxError->0.0001. † MaxError->{0.0001, 0.00001, 0.000001} is equivalent to the default setting. † See also: Diagnostics.
Mech 2D/3D † Mech is the symbol name for all MechanicalSystems general messages. † See also: General.
Method 2D/3D † Method is an option for SetSymbols that is used to specify whether Euler or Angular coordinates will be used to represent angular orientation (2D) or angular velocity (3D). † Method is an option for SolveFree and SolvePath that is used to specify whether a Predictor, Corrector, or Automatic integration algorithm is used. † The default setting is Method->Angular for Modeler2D and Method->Euler for Modeler3D. † The default setting is Method->Automatic for SolveFree and SolvePath. † See also: Coordinates, FitDegree, Method.
529
MechanicalSystems
530
Moment 2D/3D † Moment[bnum, mag] (2D) returns a SysLoad data object that applies a moment to body bnum of magnitude mag. † Moment[bnum, vector, mag] (3D) returns a SysLoad data object that applies a moment to body bnum of magnitude mag in the direction of vector. † Moment[bnum1, bnum2, … ] applies the moment to body bnum1 and also applies a moment in the opposite sense to body bnum2. † After creation, the SysLoad object is passed to SetLoads to alter the state of the current Mech model. † The following options can be given: CutOff
0
allow the length of axis to approach zero without a singularity
Magnitude
Absolute
whether dist is multiplied by the length of vector
† In Modeler3D, Magnitude->Relative causes the magnitude of the applied moment to be equal to the specified mag times the length of vector. † See also: Body, Force, GyroMoment, Load.
Natural 2D/3D † Natural is a setting for the EndConditions option for SplineFit that specifies that the curvature of the spline will be zero at the ends. † The alternatives to Natural are Closed or a list of two direction vectors. † See also: SplineFunction.
Appendix B: MechanicalSystems Function Listing
531
Normalized 3D † Normalized is an option for Rotation that specifies whether vector in the returned {ang, vector} is to be normalized. † Normalized is also a setting for the Assumptions option for several Mech functions. † Normalized->False allows Rotation to return an axis of rotation that is not normalized. † Assumptions->Normalized allows functions to assume that the given axis of rotation is normalized, hence allowing them to avoid the burden of normalizing it again. † The default setting for Rotation is Normalized->True. † See also: Normalized, Unit.
Omega 2D/3D † Omega[bnum] returns the angular velocity (2D) or angular velocity vector (3D) of body bnum. † In Modeler2D, Omega returns a scalar w. † In Modeler3D, Omega returns the angular velocity is a vector of the form: {wx, wy, wz}. † If the Euler solution method is specified with SetSymbols, Omega returns the angular velocity in terms of Euler parameters and their derivatives. With the Angular solution method Omega simply returns Θbnumd (2D) or {Ωxbnum, Ωybnum, Ωzbnum} (3D). † In Modeler3D, Omega accepts the Coordinates option to specify whether the angular velocity should be returned in Global or body Local coordinates. The default setting is Coordinates->Global. † See also: Alpha, Rotation, Velocity.
Origin 2D/3D † Origin[bnum] returns the global coordinates of the origin of body bnum.
MechanicalSystems
532
† Origin[bnum] is equivalent to Location[bnum, 0]. † See also: Location, Rotation.
OriginLock2 2D † OriginLock2[cnum, bnum1, bnum2] locks the position of body bnum1 to that of body bnum2. The local origins of the two bodies are coincident. If bnum2 is omitted, bnum1 is located relative to the global origin. † OriginLock2 constrains two degrees of freedom. † OriginLock2[cnum, bnum1, bnum2, vector] forces the origin location of body bnum1 to be equal to the origin location of body bnum2 plus the given vector. † The first equation constrains the X coordinate and the second constrains the Y coordinate. † See also: Revolute2, RotationLock1, SetConstraints, SysCon.
OriginLock3 3D † OriginLock3[cnum, bnum1, bnum2] locks the position of body bnum1 to that of body bnum2. The local origins of the two bodies are coincident. If bnum2 is omitted, bnum1 is located relative to the global origin. † OriginLock3 constrains three degrees of freedom. † OriginLock3[cnum, bnum1, bnum2, vector] forces the origin location of body bnum1 to be equal to the origin location of body bnum2 plus the given vector. † The three equations in OriginLock3 constrain the X, Y, and Z coordinates, respectively. † See also: Spherical3, RotationLock3, SetConstraints, SysCon.
Appendix B: MechanicalSystems Function Listing
533
OrthogonalGears5 3D † OrthogonalGears5[cnum, axis1, teeth1, {alpha, guess}, axis2, teeth2, C] models a pair of gears on orthogonal axes, such as a bevel gear set. † The axes of the two gears, axis1 and axis2, are constrained to be orthogonal, and the origins of these two axes are constrained to be coincident. The rotational positions of the two gears are related as per their respective tooth counts, teeth1 and teeth2. † Negating teeth1 or teeth2 reverses the relative direction of rotation of the gears. † OrthogonalGears5 constrains five degrees of freedom. † OrthogonalGears5[cnum, axis1, teeth1, {alpha, guess}, axis2, teeth2, dist, C] offsets the axes of the gears by dist units, such as the offset in a worm gear or spiral bevel gear set. † The symbol alpha tracks the relative spin of axis1. † The constant C, which sets the initial positions of the two gears, is given by the formula C = teeth1 e1 + teeth2 e2. e1 and e2 are determined in the following way. Place the two gears in any valid position. e1 is the projected angle, in radians, measured from axis2 to the reference direction of axis1, and e2 is the angle from axis1 to the reference direction of axis2. † OrthogonalGears5 generates six constraint equations and introduces one new variable, hence constraining five degrees of freedom. † The first equation in OrthogonalGears5 constrains axis1 to be orthogonal to axis2, the next two equations constrain the origins of the two axes to be adjacent, the fourth equation constrains the axes to be dist units apart, and the fifth and sixth equations relate the value of the variable alpha to the relative rotation of the two gears. † See also: ConstantVelocity4, Orthogonal1, ParallelGears5, SetConstraints, SetSymbols, SysCon.
Orthogonal1 2D/3D † Orthogonal1[cnum, vector1, vector2] constrains vector1 to be orthogonal to vector2. † Orthogonal1 constrains one degree of freedom. † See also: Parallel1, Parallel2, RelativeAngle1, SetConstraints, SysCon.
MechanicalSystems
534
OrthoRevolute4 3D † OrthoRevolute4[cnum, axis1, axis2, dist] constrains axis1 to lie dist units away from axis2, and to be orthogonal to axis2. Further, the origin of axis1 is constrained to lie directly adjacent to the origin of axis2. † OrthoRevolute4 constrains four degrees of freedom. † OrthoRevolute4 models a pair of hinges with orthogonal axes and a specified offset distance separating the two axes. † OrthoRevolute4[cnum, axis1, axis2] assumes the separation distance to be zero. † The first equation in OrthoRevolute4 constrains the origin of axis2 to be adjacent to axis1, the second equation constrains the origin of axis1 to be adjacent to axis2, the third constrains the separation distance to be dist units, the fourth constrains the two axes to be orthogonal. † See also: GenOrthoRevolute4, ParaRevolute4, Revolute5, SetConstraints, SysCon.
Parallel1 2D † Parallel1[cnum, vector1, vector2] constrains vector1 to be parallel to vector2. † Parallel1 constrains one degree of freedom. † Parallel1 is not sensitive to the sign of the vectori. † The constraint is satisfied if the two vectors are pointing in exact opposite directions. † See also: Orthogonal1, Parallel2, SetConstraints, SysCon.
Parallel2 3D † Parallel2[cnum, vector1, vector2] constrains the vectori to be parallel in 3D space. † Parallel2 constrains two degrees of freedom.
Appendix B: MechanicalSystems Function Listing
535
† Parallel2 is not sensitive to the sign of the vectori. † The constraint is satisfied if the two vectors are pointing in exact opposite directions. † See also: Orthogonal1, Parallel1, SetConstraints, SysCon.
ParallelAxis 2D/3D † ParallelAxis[vec, mass, inertia] uses the parallel axes theorem to transform the inertia properties of a body into or out of a centroidal reference frame. Assuming that the given inertia properties are centroidal, ParallelAxis returns the inertia properties relative to a noncentroidal reference frame in which vec is the vector from the origin of the noncentroidal frame to the centroid of the body. † The sign of the specified vector pointing to the centroid of the body is irrelevant. † In Modeler2D, inertia is specified by a scalar and the return value is a scalar. † In Modeler2D, simply negate mass to transform noncentroidal properties into a centroidal reference frame. † In Modeler3D, the inertia of the body is specified by a list of the elements of the inertia matrix: {Ixx, Iyy, Izz, Ixy, Iyz, Izx} or a full inertia matrix. ParallelAxis then returns the list {Ixx', Iyy', … } of inertia properties relative to the noncentroidal reference frame. † In Modeler3D, ParallelAxis[centroid, mass, inertia, rotation] is used to specify that the centroidal reference frame in which the specified inertia properties are calculated is rotated relative to the noncentroidal frame. The rotation of the centroidal frame is specified by {angle, axis}, a virtual rotation vector, or a set of Euler parameters. † In Modeler3D, to transform noncentroidal inertia properties into a centroidal reference frame: vec is the vector (in the centroidal reference frame) from the centroid to the origin of the noncentroidal reference frame, rotation specifies the relative rotation (in the centroidal reference frame) of the noncentroidal frame, and a negative mass is specified. † See also: CompositeInertia, GyroFilter, PrincipalAxes.
ParallelGears4 3D † ParallelGears4[cnum, axis1, rad1, {alpha, guess}, axis2, rad2, C] models a gear set.
MechanicalSystems
536
† This constraint is identical to ParallelGears5 except that the heads of the two axes are not constrained to be adjacent. Thus, the two gears can slide on their axes, relative to each other. † ParallelGears4 constrains four degrees of freedom. † ParallelGears4 is essentially ParallelGears5 with the third equation dropped. † See also: OrthogonalGears5, Parallel2, SetConstraints, SetSymbols, SysCon.
ParallelGears5 3D † ParallelGears5[cnum, axis1, rad1, {alpha, guess}, axis2, rad2, C] models a gear set. † The axes of the two gears, axis1 and axis2 are constrained to be parallel and rad1+rad2 units apart, and the heads of the two axes are constrained to be adjacent. The rotational positions of the gears are related as per their respective radii. † ParallelGears5 constrains five degrees of freedom. † The symbol alpha tracks the spin of axis1, relative to a vector spanning from axis1 to axis2. † The constant C, which sets the initial positions of the gears, is given by the formula C = rad1 e1 + rad2 e2. e1 and e2 are determined in the following way. Place the two gears in any valid position and construct a vector from the origin of axis1 to that of axis2. e1 is the angle, in radians, measured from the constructed vector to the reference direction of axis1, and e2 is measured from the vector to the reference direction of axis2. † ParallelGears5 generates six constraint equations and introduces one new variable, hence constraining five degrees of freedom. † The first two equations in ParallelGears5 constrain axis1 to be parallel to axis2, the third equation constrains the origin of axis2 to lie adjacent to axis1, the fourth equation constrains the axes to be rad1+rad2 units apart, and the fifth and sixth equations relate the value of the variable alpha to the rotational displacements of the gears. † See also: OrthogonalGears5, Parallel2, SetConstraints, SetSymbols, SysCon.
Appendix B: MechanicalSystems Function Listing
537
Parameterize 2D/3D † Parameterize[symbols] takes the given list of symbols (each of which must have a numeric value defined) unsets them and puts them in the parameters list with a current value equal to their previously defined value. † For example, (c = 3.5; Parameterize[{c}]) has the same effect as SetParameters[{c->3.5}]. † Upon success, Parameterize returns the entire parameters list. † See also: SetParameters.
Parameters 2D/3D † Parameters[] returns the current Mech parameters list. † Parameters is also an element of the setting for the MakeRules option. MakeRules->{Parame ters, … } causes the current parameters to be included in the returned rules. † Parameters is also an option for SplineFit that is used to specify the value of the spline parameter at each knot point. † As an option for SplineFit, Parameters can be either a list of numbers in ascending order, equal in length to the number of data points given, or Automatic, which is equivalent to specifying a list of integers ascending from zero. † Specifying the Parameters option for SplineFit allows the spacing of the knot points for the spline independent variable to be altered. † See also: ClearParameters, Reaction, SetParameters.
MechanicalSystems
538
ParaRevolute4 3D † ParaRevolute[cnum, axis1, axis2, dist] constrains axis1 to lie dist units away from, and parallel to axis2. Further, the origin of axis1 is constrained to lie directly adjacent to the origin of axis2. † ParaRevolute constrains four degrees of freedom. † ParaRevolute4 models a pair of hinges with parallel axes and a specified offset distance separating the two axes. † ParaRevolute4 becomes singular if the separation distance is zero; use Revolute5. † The first two equations in ParaRevolute4 constrain axis1 and axis2 to be parallel, the third constrains the origins of the two axes to be adjacent, and the fourth constrains the separation distance to be equal to dist. † See also: OrthoRevolute4, Cylindrical4, SetConstraints, SysCon.
PathSystem 2D/3D † PathSystem is the head of the data object returned by SetPath. † The format of the PathSystem data object is PathSystem[equations, timesym, variables, initialconditions, parameters, primerules]. † PathSystem is not intended to be used external to Mech. † See also: SolvePath.
Plane 3D † Plane[point1, point2, point3] is a Modeler3D data object that uses three points to define a plane. The plane originates at point1 and is fully defined by point2 and point3 that also lie in the plane. The pointi must be Mech Point objects.
Appendix B: MechanicalSystems Function Listing
539
† Plane[bnum, lpnt1, lpnt2, lpnt3] is interpreted as Plane[Point[bnum, lpnt1], Point[bnum, lpnt2], Point[bnum, lpnt3]]. The lpnti can be points, {x, y, z}, in the local coordinate system of body bnum or point numbers (positive integers) referencing coordinates that were defined with SetBodies. † If a Plane object is used in place of a Modeler3D Vector object, the plane’s normal provides the direction of the vector. † If a Plane object is used in place of a Modeler3D Axis object, the plane’s origin (point1) provides the origin of the axis, the plane normal provides the direction vector, and the line from point1 to point2 provides the rotational reference vector of the axis. † See also: Line, ReferenceDirection.
PlaneToCircle1 3D † PlaneToCircle1[cnum, axis1, axis2, rad] constrains a plane that is normal to axis1 to lie tangent to a circle of radius rad, centered at the origin of axis2, with its normal vector in the direction of axis2. † PlaneToCircle1 constrains one degree of freedom. † PlaneToCircle1[cnum, axis1, axis2, majrad, minrad] constrains the plane that is normal to axis1 to lie tangent to the surface of a torus of major radius majrad and minor radius minrad, centered at the origin of axis2 with major axis specified by axis2. † See also: LineToCircle1, SetConstraints, SysCon.
PlaneToPlane3 3D † PlaneToPlane3[cnum, axis1, axis2, dist] constrains axis1 to be parallel to axis2, and constrains the origin of axis1 to lie dist units away from the origin of axis2, in the direction of axis2. † PlaneToPlane3 constrains three degrees of freedom.
MechanicalSystems
540
† PlaneToPlane3[cnum, axis1, axis2] constrains two planes that are normal to the two specified axes to be coincident. † See also: PointOnPlane1, SetConstraints, SysCon.
Point 2D/3D † Point[bnum, lpnt] is a Mech data object that specifies a point in the local coordinate system of body bnum. † The lpnt can be a vector, {x, y} (2D) or {x, y, z} (3D), or a point number (positive integer) referencing coordinates that were defined with SetBodies. † A simple vector {x, y} or {x, y, z} given in place of a Point object is interpreted as Point[1, {x, y}] or Point[1, {x, y, z}]. † Mech’s overloading of the built-in Point symbol has no effect on its usage in other Mathematica code. † See also: Axis, Line, Plane, Point, Vector.
PointAtIntersection3 3D † PointAtIntersection3[cnum, point, axis1, axis2] constrains point to lie at the intersection of axis1 and a plane that is specified by axis2. † PointAtIntersection3 constrains three degrees of freedom. † axis2 is typically a Modeler3D Plane object, but the plane may be specified by its origin and normal direction with any Modeler3D axis object. † See also: SetConstraints, Spherical3, SysCon.
PointLabel 2D/3D † PointLabel[bnum, {lpnt1, lpnt2, … , lpntn}] labels several points on body bnum with their body numbers and local coordinates.
Appendix B: MechanicalSystems Function Listing
541
† PointLabel[bnum, All] labels all of the points on body bnum that were defined with a body object. † PointLabel[{point1, … , pointn}] labels several points on different bodies. † PointLabel returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † The point label generated is of the form "
PointList 2D/3D † PointList is an option for Body that is used to specify a list of local point coordinates on a body. † PointList->{{x1, y1}, {x2, y2}, … , {xn, yn}} (2D) or PointList->{{x1, y1, z1}, … , {xn, yn, zn}} (3D) specifies n points on the body that are referenced by their point numbers 1 through n. † PointList[bnum, lpnt] returns the local coordinates of point lpnt on body bnum. † PointList[bnum] returns a list of all the point coordinates on body bnum. † If no points are specified for a body, no default values are set for the points; unspecified points are not set to zero. † The specified list replaces any points that are currently defined on the body. Thus PointList->{} removes all points currently on the body. † Referencing a point number of a point that has not been specified generates an error. † The default setting PointList->Automatic leaves the current points table unchanged. † See also: InitialGuess, SetBodies.
MechanicalSystems
542
PointOnCircle2 3D † PointOnCircle2[cnum, point, axis, rad] constrains point to lie on the perimeter of a circle of radius rad, with axis specified by axis. The center of the circle lies at the origin of axis. † PointOnCircle2 constrains two degrees of freedom. † axis may be specified by a Modeler3D Line, Plane, or Axis object. † If a Plane object is used, the circle lies in the plane, centered at the origin of the plane. † PointOnCircle2 is singular if rad becomes equal to zero; use Spherical3. † The first equation constrains point to lie in the plane of the circle, the second equation constrains the distance between point and the origin of axis to be equal to rad. † See also: PointOnLine2, PointOnPlanes2, SetConstraints, SysCon.
PointOnCone1 3D † PointOnCone1[cnum, point, axis, ang] constrains point to lie on the surface of a cone of half angle ang. The axis of the cone is specified by axis and the vertex of the cone lies at the origin of axis. † PointOnCone1 constrains one degree of freedom. † PointOnCone1 becomes singular as ang approaches zero or as point passes though the vertex of the cone. † Use PointOnLine2 instead. † See also: PointOnCylinder1, PointOnLine2, SetConstraints, SysCon.
PointOnCylinder1 3D † PointOnCylinder1[cnum, point, axis, rad] constrains point to lie on the surface of a cylinder of radius rad. The axis of the cylinder is specified by axis. † PointOnCylinder1 constrains one degree of freedom.
Appendix B: MechanicalSystems Function Listing
543
† axis may be a Modeler3D Line, Plane, or Axis object. † PointOnCylinder1 is singular if rad becomes equal to zero; use PointOnLine2. † See also: LineOnCylinder3, PointOnCone1, PointOnTorus1, SetConstraints, SysCon.
PointOnLines2 2D † PointOnLines2[cnum, point, axis1, axis2] constrains point to lie at the intersection of axis1 and axis2. † PointOnLines2 constrains two degrees of freedom. † PointOnLines2 is essentially the same as two PointOnLine1 constraints. † The first equation constrains point to lie on axis1, and the second constrains point to lie on axis2. † See also: PointAtIntersection3, Revolute2, SetConstraints, SysCon.
PointOnLine1 2D † PointOnLine1[cnum, point, axis] models a planar slider in which point is constrained to lie on axis. The axis may be a Modeler2D Line or Axis object. † PointOnLine1 constrains one degree of freedom. † PointOnLine1[cnum, point, axis, dist] places point dist units to the left of axis. † PointOnLine1[cnum, point, axis, dist, ang] constrains point to move along a line that is rotated ang radians counterclockwise relative to axis, and located dist units to the left of the origin of axis, measured perpendicular to axis. † See also: DirectedDistance1, PointOnLines2, SetConstraints, SysCon.
MechanicalSystems
544
PointOnLine2 3D † PointOnLine2[cnum, point, axis] models a spatial slider in which point is constrained to lie on axis. † PointOnLine2 constrains two degrees of freedom. † axis may be specified by a Modeler3D Line, Plane, or Axis object. † The two equations constrain a vector from point to the origin of axis to be orthogonal to a pair of vectors that are mutually perpendicular to axis. † See also: PointOnCircle2, PointOnPlanes2, SetConstraints, SysCon.
PointOnPlanes2 3D † PointOnPlanes2[cnum, point, axis1, axis2] constrains point to lie on the intersection of two planes specified by their axes. † PointOnPlanes2 constrains two degrees of freedom. † PointOnPlanes2 is essentially just two PointOnPlane1 constraints. † The two axes are typically specified by Modeler3D Plane objects. † The first equation constrains point to lie on the plane normal to axis1, and the second constrains point to lie on the plane normal to axis2. † See also: PointOnCircle2, PointOnLine2, SetConstraints, SysCon.
PointOnPlane1 3D † PointOnPlane1[cnum, point, axis] constrains point to lie within a plane specified by axis. The axis is typically given as a Modeler3D Plane object. † PointOnPlane1 constrains one degree of freedom.
Appendix B: MechanicalSystems Function Listing
† PointOnPlane1[cnum, point, axis, dist] constrains point to lie dist units away from the plane specified by axis, in the direction of the plane’s positive normal. † See also: DirectedDistance1, SetConstraints, SysCon.
PointOnTorus1 3D † PointOnTorus1[cnum, point, axis, majrad, minrad] constrains point to lie on the surface of a torus of major radius majrad and minor radius minrad that has its major axis specified by axis. The center of the torus is at the origin of axis. † PointOnTorus1 constrains one degree of freedom. † Note that PointOnTorus1 is inherently a very nonlinear constraint, and as such very good initial guesses are usually required. † PointOnTorus1 is singular if majrad or minrad become equal to zero; use Spherical3 or PointOnCircle2. † See also: PointOnCylinder1, RelativeDistance1, SetConstraints, SysCon.
PointToLineDistance 2D/3D † PointToLineDistance[point, axis] returns the shortest distance from point to axis. † In Modeler2D, a negative return value indicates that point lies to the right of axis. † If axis is specified with a Modeler3D Plane object, the shortest distance from point to the plane’s normal is returned. † See also: PointToPlaneDistance.
PointToLocal 2D/3D † PointToLocal[bnum, point] returns the local coordinates of point, in the coordinate system of body bnum.
545
MechanicalSystems
546
† When called with a point specified in global coordinates, PointToLocal is essentially the inverse function of Location. † See also: VectorToLocal.
PointToPlaneDistance 3D † PointToPlaneDistance[point, axis] returns the shortest distance from point to a plane. The plane’s normal is specified by axis. † axis is typically a Modeler3D Plane object, but may be any axis object specifying the plane’s normal and origin. † See also: PointToLineDistance.
PolarToXY 2D † PolarToXY[{radius, angle}] converts the given point from polar to Cartesian coordinates and returns {x, y}. † PolarToXY simply returns: radius {cos(angle), sin(angle)}. † See also: PointToLocal, XYToPolar.
Predictor 2D/3D † Predictor is a setting for the Method option for SolveFree and SolvePath. The Predictor method uses an Adams-Bashforth predictor integration algorithm. † When Method->Predictor is given instead of the default setting Automatic, the integrator never takes a corrective Adams-Moulton step regardless of the error estimate of the current step. † The alternatives to the Predictor setting are Corrector and Automatic. † See also: FitDegree.
Appendix B: MechanicalSystems Function Listing
547
PrincipalAxes 3D † PrincipalAxes[{Ixx, Iyy, Izz, Ixy, Iyz, Izx}] returns the list {{I1, I2, I3}, {axis1, axis2, axis3}}, where {I1, I2, I3} are the principal moments of inertia and {axis1, axis2, axis3} are the corresponding principal axes of the body represented by the given inertia properties. † {axis1, axis2, axis3} is actually the rotation matrix from the reference frame in which the inertia properties were specified to the principal axes reference frame. † See also: CompositeInertia, GyroFilter, ParallelAxis.
ProjectedAngle 3D † ProjectedAngle[vector1, vector2, vector3] returns the counterclockwise angle measured from the direction of vector2 to the direction of vector1, as projected on a plane that is orthogonal to vector3. † ProjectedAngle returns values in the range {–p, p}. † See also: Angle, IncludedAngle.
ProjectedAngle1 3D † ProjectedAngle1[cnum, vector1, vector2, vector3, ang] constrains the angle of the projection of vector1, relative to the projection of vector2, to be equal to ang, when the two vectors are projected onto a plane that is normal to vector3. † The sense of the angle is determined by the right-hand rule, relative to vector3. † ProjectedAngle1 constrains one degree of freedom. † ProjectedAngle1[cnum, vector, axis, ang] uses the direction vector of axis in place of vector3, and uses the reference direction of axis in place of vector2. This alternate form is useful for projecting the vector onto a plane specified by axis, and measuring the angle relative to the primary axis of the plane. † See also: RelativeAngle1, SetConstraints, SysCon.
MechanicalSystems
548
ProjectOnLine 2D/3D † ProjectOnLine[vector1, vector2] projects vector1 onto vector2 and returns the vector component of vector1 that is in the direction of vector2. † ProjectOnLine[point, axis] returns the coordinates of point orthogonally projected onto axis. † ProjectOnLine[vector1, vector2] returns the dot product of the vectori, divided by the magnitude of vector2. † See also: IntersectionPoint, PointToLineDistance, ProjectOnPlane.
ProjectOnPlane 3D † ProjectOnPlane[vector1, vector2] projects vector1 onto a plane that is normal to vector2 and returns the vector component of vector1 that is orthogonal to vector2. † ProjectOnPlane[point, axis] returns the coordinates of point orthogonally projected onto a plane that is normal to axis. † axis, or vector2, is typically specified with a Modeler3D Plane object. † See also: PointToPlaneDistance, ProjectOnLine.
Quadratic 2D/3D † Quadratic is a setting for the FitDegree option for SolveFree and SolvePath. Quadratic specifies a quadratic approximation of each section of the integrand. † Quadratic is generally less accurate than Cubic, but faster. † Quadratic uses quadratic interpolation for the predictor step, and cubic interpolation for the corrector step. † See also: Linear, Quartic.
Appendix B: MechanicalSystems Function Listing
549
Quartic 2D/3D † Quartic is a setting for the FitDegree option for SolveFree and SolvePath. Quartic specifies a quartic approximation of each section of the integrand. † Quartic is generally more accurate than Cubic, but slower. † Quartic uses quartic interpolation for the predictor step, and quintic interpolation for the corrector step. † See also: Linear, Quadratic.
RackAndPinion1 2D † RackAndPinion1[cnum, point, rad, axis, C] models a rack and pinion gear set where axis represents the rack and point is the center of the pinion. The angular orientation of the rack and pinion are related as per the pinion radius rad and the displacement between the origin of axis and point, measured in the direction of axis. † The constant C sets the initial orientation of the rack and pinion. † RackAndPinion1 constrains one degree of freedom. † The constant C is the distance, in the direction of axis, from the origin of axis to point when the x axis of the pinion body is parallel to the rack. † RackAndPinion1 is functionally identical to RackAndPinion2 except that the distance between the rack and the pinion is not constrained, only their angular orientation. † If the Euler solution method is specified, RackAndPinion1 generates two constraints, and adds one extra variable to the model. RackAndPinion1[cnum, point, rad, {alpha, guess}, axis, C] can be used to explicitly specify the name of the extra variable alpha, and its initial guess. Otherwise, a symbol of the form Θcnum is used. † RackAndPinion1[cnum, point, rad, {sym1, guess}, axis, C] can be used to explicitly specify the name of the extra variable and its initial guess. Otherwise, a symbol of the form Θcnum is used. † The first, and optional second, equations in RackAndPinion1 relate the relative displacement of the rack and pinion to their relative rotation. † See also: SetConstraints, SetSymbols, SysCon, TwoGears1, TwoPulleys1.
MechanicalSystems
550
RackAndPinion2 2D † RackAndPinion2[cnum, point, rad, axis, C] models a rack and pinion gear set. The center of the pinion (point) is constrained to lie rad units to the left of the rack (axis) and the angular orientation of the rack and pinion are related as per the pinion radius. † The constant C sets the initial orientation of the rack and pinion. † RackAndPinion2 constrains two degrees of freedom. † The constant C is the distance, in the direction of axis, from the origin of axis to point when the x axis of the pinion body is parallel to the rack. † If the Euler solution method is specified, RackAndPinion2 generates three constraints, and adds one extra variable to the model. RackAndPinion2[cnum, point, rad, {alpha, guess}, axis, C] can be used to explicitly specify the name of the extra variable alpha, and its initial guess. Otherwise, a symbol of the form Θcnum is used. † RackAndPinion2[cnum, point, rad, {sym1, guess}, axis, C] can be used to explicitly specify the name of the extra variable and its initial guess. Otherwise, a symbol of the form Θcnum is used. † The first equation in RackAndPinion2 constrains point to lie rad units to the left of axis. The second, and optional third, equations relate the axial displacement of the rack to the rotation of the pinion. † See also: RackAndPinion1, SetConstraints, SetSymbols, SysCon, TwoGears2, TwoPulleys2.
RackAndPinion4 3D † RackAndPinion4[cnum, axis1, rad, {alpha, guess}, axis2, C] is identical to RackAndPinion5 except that the heads of the two axes are not constrained to be adjacent. Thus, the pinion is free to slide on its axis, relative to the rack. † RackAndPinion4 constrains four degrees of freedom. † RackAndPinion4 is essentially RackAndPinion5 with the fourth equation dropped. † The symbol alpha is used as the pinion rotation variable. † The two equations in RackAndPinion5 constrain axis2 to be parallel to axis1, the third equation places the pinion axis rad units away from the rack, the fourth equation relates the axial displacement of the rack to the
Appendix B: MechanicalSystems Function Listing
551
rotation of the pinion, and the fifth relates the value of the variable alpha to the rotation of the pinion. † See also: Cylindrical4, LeadScrew5, ParallelGears5, SetConstraints, SetSymbols, SysCon.
RackAndPinion5 3D † RackAndPinion5[cnum, axis1, rad, {alpha, guess}, axis2, C] models a rack and pinion gear set. axis1 represents the rotational axis of the pinion, and axis2 represents the rack. axis2 is parallel to the cut of the teeth of the rack, and axis2 and its reference direction lie in the plane of the rack. axis1 is constrained to lie rad units away from, and parallel to, axis2, and the origins of the two axes are constrained to be adjacent. The rotational orientation of the pinion is related to that of the rack as per the pinion radius. † RackAndPinion5 constrains five degrees of freedom. † The symbol alpha is used as the pinion rotation variable. † RackAndPinion5 generates six constraint equations and introduces one new variable, hence constraining five degrees of freedom. † The two equations in RackAndPinion5 constrain axis2 to be parallel to axis1, the third equation places the pinion axis rad units away from the rack, the fourth equation constrains the origin of the pinion to be adjacent to the origin of the rack, the fifth equation relates the axial displacement of the rack to the rotation of the pinion, and the sixth relates the value of the variable alpha to the rotation of the pinion. † See also: Cylindrical4, LeadScrew5, RackAndPinion4, ParallelGears5, SetConstraints, SetSymÖ bols, SysCon.
Reaction 2D/3D † Reaction[cnum, bnum, point] returns the reaction loads applied by constraint cnum to body bnum, calculated about the specified point. Loads are returned in the format: {force, moment}. † Reaction[cnum, bnum] returns the reaction loads calculated about the local origin of body bnum. † Reaction accepts the Coordinates option specify whether the resulting load vectors are in Global or body Local coordinates.
MechanicalSystems
552
† Reaction is also a setting for the Type option for Loads. † Type->Reaction causes Loads to return the total kinematic reaction forces applied to a body. † Reaction[cnum, Point[bnum, lpnt]] returns the reaction force applied by constraint cnum to body bnum, calculated about local point lpnt on body bnum. † The constraint number specification, cnum, can be replaced with any of the specific constraint equation specifications accepted by Constraints. † Note that only the reaction moment is a function of the location of point. Reaction forces are not dependent on the point about which they are calculated. † The default option setting is Coordinates->Global. † Reaction[cnum, symbol] returns the reaction applied by constraint cnum to a particular symbol, in consistent force or moment units. The symbol must be a coordinate or parameter that occurs in the current model’s constraint equations. † The meaning of the quantity returned by Reaction[cnum, symbol] depends on the nature of the occurrence of symbol in the model. For example, if a parameter named len specifies the length of a simple connecting link in the mechanism, the value of Reaction[All, len] corresponds to the tension in the connecting link. † If symbol occurs in the model in a very complicated and interlinked manner the value returned by Reaction has little physical meaning. † The alternatives to the Reaction setting for the Type option are Applied and Dynamic, which cause Loads to return external loads or inertial loads, respectively. † See also: SetLoads.
ReelToReel1 2D † ReelToReel1[cnum, point1, rad1, point2, rad2, dist, C] models a pair of pulleys connected by a single cable. The rotational positions of the pulleys are related as per their respective radii and their separation distance. † The constant C sets the initial rotational position of the pulleys. † ReelToReel1 constrains one degree of freedom.
Appendix B: MechanicalSystems Function Listing
553
† The constant C, which sets the initial rotation of the pulleys, is given by the formula C = (rad1 e1 – rad2 e2) where e1 and e2 are determined in the following way. Place the two sprockets in any valid position and construct a vector from point1 to point2. e1 is the angle, measured in radians, from the constructed vector to the local x axis of the first sprocket and e2 is the angle from the constructed vector to the x axis of the second sprocket. † ReelToReel1 is functionally identical to TwoPulleys1 except that the angular orientation of the two pulleys is effected by their separation distance. † If the Euler solution method is specified, ReelToReel1 generates two constraints, and adds one extra variable to the model. † ReelToReel1[cnum, point1, rad1, {sym, guess}, point2, rad2, dist, C] can be used to explicitly specify the name of the extra variable, and its initial guess. Otherwise, a symbol of the form Θcnum is used. † The second, and optional third, equation in ReelToReel1 relates the rotation angles of the two pulleys. † See also: RackAndPinion1, SetConstraints, SetSymbols, SysCon, TwoGears1.
ReferenceDirection 3D † ReferenceDirection[axis] returns the reference direction associated with axis. This is a vector that is not parallel to the direction of axis. † The reference direction of an axis may be explicitly specified with Axis[origin, direction, refdir]. † If direction is specified with Plane[p1, p2, p3] and refdir is unspecified then the reference direction of the axis is Line[p1, p2]. † Reference directions are used by some constraints to control the spin of a body about axis. † Unspecified reference directions are chosen automatically. For example, ReferenceDirection[Axis[{0, 0, 0}, {1, 0, 0}]] returns {0, 1, 0} † See also: Axis, Line, Plane.
Relative 2D/3D † Relative is a setting for the Magnitude option for Force. † Magnitude->Relative causes the magnitude of the applied load to be equal to the specified magnitude times the length of the vector used to specify the direction of the load.
MechanicalSystems
554
† Absolute is also a setting for the Magnitude option for Arrow. † In Modeler3D, Relative is also a setting for the Magnitude option for Moment and Extrude. † The alternative to the Relative setting is Absolute, which causes the magnitude of the applied load to be equal to the specified magnitude. † See also: CutOff.
RelativeAngle1 2D/3D † RelativeAngle1[cnum, vector1, vector2, ang] constrains the angle between vector1 and vector2 to be equal to ang. † RelativeAngle1 constrains one degree of freedom. † In Modeler2D, RelativeAngle1 is sensitive to the sign of ang; the direction angle of vector1 is explicitly constrained to be ang radians greater than the direction angle of vector2, in the counterclockwise sense. † In Modeler2D, if vector2 is omitted it is assumed to be the global X axis. † In Modeler3D, RelativeAngle1 is not sensitive to the sign of ang; the included angle between vector1 and vector2 is constrained to be equal to |ang|. † See also: ProjectedAngle1, RotationLock1, SetConstraints, SysCon.
RelativeDistance1 2D/3D † RelativeDistance1[cnum, point1, point2, dist] models a connecting link. The absolute distance from point1 to point2 is constrained to be equal to dist. † RelativeDistance1 constrains one degree of freedom. † In Modeler2D, RelativeDistance1 effectively constrains point1 to lie on a circle of radius dist that is centered about point2. † In Modeler3D, RelativeDistance1 constrains point1 to lie on a sphere of radius dist that is centered at point2. † RelativeDistance1 is singular if dist becomes equal to zero; use Revolute2 or Spherical3 instead. † See also: PointOnCircle2, SetConstraints, SysCon.
Appendix B: MechanicalSystems Function Listing
555
RelativeVelocity 2D/3D † RelativeVelocity[bnum, point] returns the velocity of point, relative to body bnum, in global coordinates. † RelativeVelocity accepts the Coordinates option to determine whether to return the result in Global or body Local coordinates. † The default option setting is Coordinates->Global. † RelativeVelocity is a generalization of the Velocity function that can return the velocity of a point relative to some reference frame other than the global reference frame. † RelativeVelocity[1, point] is identical to Velocity[point]. † See also: Acceleration, Location.
RelativeX1 2D/3D † RelativeX1[cnum, point1, point2, dist] constrains the global X coordinate of point1 to be dist units greater than the global X coordinate of point2. † RelativeX1 constrains one degree of freedom. † If point2 is omitted, the offset distance is measured relative to the global origin. † Note that a RelativeX1 constraint applied between two points on nonground bodies still introduces an implicit kinematic relationship with the ground body because the direction of measurement is in the global reference frame. This can introduce spurious reaction moments to the model. Use DirectedDistance1 to avoid this. † See also: PointOnLine1, PointOnPlane1, RelativeY1, SetConstraints, SysCon.
MechanicalSystems
556
RelativeY1 2D/3D † RelativeY1[cnum, point1, point2, dist] constrains the global Y coordinate of point1 to be dist units greater than the global Y coordinate of point2. † RelativeY1 constrains one degree of freedom. † If point2 is omitted, the offset distance is measured relative to the global origin. † Note that a RelativeY1 constraint applied between two points on nonground bodies still introduces an implicit kinematic relationship with the ground body because the direction of measurement is in the global reference frame. This can introduce spurious reaction moments to the model. Use DirectedDistance1 to avoid this. † See also: PointOnLine1, PointOnPlane1, RelativeZ1, SetConstraints, SysCon.
RelativeZ1 3D † RelativeZ1[cnum, point1, point2, dist] constrains the global Z coordinate of point1 to be dist units greater than the global Z coordinate of point2. † RelativeZ1 constrains one degree of freedom. † If point2 is omitted, the offset distance is measured relative to the global origin. † Note that a RelativeZ1 constraint applied between two points on nonground bodies still introduces an implicit kinematic relationship with the ground body because the direction of measurement is in the global reference frame. This can introduce spurious reaction moments to the model. Use DirectedDistance1 to avoid this. † See also: PointOnPlane1, RelativeX1, SetConstraints, SysCon.
Appendix B: MechanicalSystems Function Listing
RequiredEquations 2D/3D † RequiredEquations is an option for FindSwitchTime that specifies which equations, of a constraint that restrains more than one degree of freedom, are to be retained in seeking the switch time. RequiredEquations should be a two element list; the first element applies to the first set of equations of the TimeSwitch pair, the second element applies to the second set. † Allowable values for each element are the following: an integer, a list of integers (1 through the number of degrees of freedom in the constraint), All, or Sum. † The total number of equations specified must be equal to one plus the number of degrees of freedom constrained by the TimeSwitch. † If All is given, all the constraints in the associated side of the TimeSwitch constraint are included. † Sum takes the sum of all equations in the associated side of the TimeSwitch constraint and uses the sum for a single constraint. † Using the Sum setting can lead to a singularity. † The normal method of specifying RequiredEquations is to specify All for one side and specify a single integer equation number for the other. † The default setting is RequiredEquations->{All, Sum}. † See also: TangentConstraint.
Reverse 2D/3D † Reverse is an option for Arrow that reverses the direction of the arrow. † The default setting Reverse->False makes the arrow point in the direction of the specified vector. † See also: HeadSize, Magnitude, Reverse.
557
MechanicalSystems
558
Revolute2 2D † Revolute2[cnum, point1, point2] models a rotational joint. point1 is constrained to be coincident with point2. † Revolute2 constrains two degrees of freedom. † Revolute2 is used in 2D models to model a shaft in a bearing, or a revolving hinge. † The two equations constrain the X and Y coordinates of the two points to be coincident. † See also: GenRevolute2, SetConstraints, SysCon, Translate2.
Revolute5 3D † Revolute5[cnum, axis1, axis2] constrains axis1 to be parallel to axis2 and constrains the origin of axis1 to be coincident with the origin of axis2. † Revolute5 constrains five degrees of freedom. † Revolute5 models a hinge or revolving bearing. † The first three equations constrain the X, Y, and Z coordinates of the origins of the two axes to be coincident, and the last two equations constrain the two axes to be parallel. † See also: GenRevolute5, Cylindrical4, SetConstraints, SysCon, Translate5.
Revolve 3D † Revolve[{point1, point2, … , pointn}, axis, facets] revolves the sequence of n – 1 lines between the specified pointi about axis, using facets segments. † Revolve[bnum, {lpnt1, … , lpntn} axis, facets] revolves the n – 1 lines connecting the local points lpnti located on body bnum.
Appendix B: MechanicalSystems Function Listing
559
† Revolve returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † Revolve does not close the ends of the surface of revolution unless point1 and pointn lie on the axis of revolution. † The following options can be given: Angle
{0, 2π}
the start and end of the swept angle of revolution relative to the reference direction of axis
Faces
True
whether to draw with filled polygons or wire frames
† See also: Cylinder, Extrude, Sphere, Torus.
RMatrix 2D † RMatrix returns the 2D orthogonal rotation matrix {{0, -1}, {1, 0}}. † See also: IMatrix, RotationMatrix.
Rotation 2D/3D † Rotation[bnum] returns the angle of rotation (2D) or the angle and axis of rotation (3D) of body bnum. † Rotation[{ei, ej}] (2D) or Rotation[{eo, ei, ej, ek}] (3D) returns the angle-axis of rotation associated with the given Euler parameters. † Rotation[matrix] returns the angle or angle-axis of rotation associated with the given 2D or 3D rotation matrix. † In Modeler2D, Rotation returns scalar angle of rotation q. † In Modeler3D, Rotation returns the angle-axis of rotation in the form: {q, {x, y, z}}. † In Modeler2D, if the Euler solution method is specified with SetSymbols, Rotation[bnum] returns the angle of rotation in terms of Euler parameters. With the Angular solution method Rotation[bnum] simply returns Θbnum.
MechanicalSystems
560
† In Modeler3D, Rotation[{q, vector}] returns the given angle-axis after potentially normalizing the axis and transforming it to the global reference frame. † In Modeler3D, Rotation[vector] returns the angle-axis of rotation associated with the given virtual rotation vector. † When Rotation is used to transform a virtual rotation or an angle-axis, vector may be a simple vector or a Mech vector object with head Vector, Line, or Plane. † In Modeler3D, the Normalized option can be given to determine whether the resulting axis of rotation is normalized. The default setting is Normalized->True. † With Normalized->True an Indeterminate result is returned for the axis of rotation if the angle of rotation is zero. † See also: Alpha, Angle, EulerParameters, Omega, Origin, RotationMatrix, VirtualRotation.
RotationLock1 2D † RotationLock1[cnum, bnum1, bnum2] locks the rotation angle of body bnum1 to be equal to the rotation angle of body bnum2. † RotationLock1[cnum, bnum1, bnum2, ang] constrains the rotation angle of body bnum1 to be ang units greater than the rotation angle of body bnum2. † If bnum2 is omitted, bnum1 is oriented relative to the global coordinate system. † RotationLock1 constrains one degree of freedom. † A list of degenerate Euler parameters {ei, ej} may be given in place of ang. † Note that RotationLock1[cnum, bnum, integer] interprets integer as bnum2, not ang. † See also: RelativeAngle1, RotationLock3, SetConstraints, SysCon.
RotationLock3 3D † RotationLock3[cnum, bnum1, bnum2] locks the angular orientation of body bnum1 to be equal to the angular orientation of body bnum2.
Appendix B: MechanicalSystems Function Listing
561
† RotationLock3[cnum, bnum1, bnum2, {ang, {x, y, z}}] constrains the angular orientation of body bnum1 to be rotated ang radians about the specified axis {x, y, z} relative to bnum2. † If bnum2 is omitted, bnum1 is oriented relative to the global coordinate system. † RotationLock3 constrains three degrees of freedom. † The axis of rotation is specified in the local coordinate system of body bnum2. † RotationLock3[cnum, bnum1, bnum2, {ang1, axis1}, … , {angn, axisn}] successively rotates body bnum1 by {ang1, axis1}, then {ang2, axis2}, and so on. axis1 is specified in the local coordinates of body bnum2, but axis2 is specified in a new coordinate system created by rotating bnum2 through the first rotation; thus axis3 is specified in the local coordinates created by rotating bnum2 through the first then the second rotation, etc. † Another way to describe the resulting rotation of bnum1 is to say that bnum1 is first rotated angn about axisn, specified in bnum2 coordinates, then rotated ang(n – 1) about axis(n – 1), also specified in bnum2 coordinates, etc. † Each successive rotation may also be specified by a list of Euler parameters {eo, ei, ej, ek} or a virtual rotation vector {vx, vy, vz}. † See also: OriginLock3, ProjectedAngle1, RelativeAngle1, RotationLock1, SetConstraints, SysCon.
RotationMatrix 2D/3D † RotationMatrix[bnum] returns the 2D/3D rotation matrix associated with body bnum. † In Modeler2D, RotationMatrix[{ang}] or RotationMatrix[{ei, ej}] returns the rotation matrix associated with the given angle or Euler parameters. † In Modeler3D, RotationMatrix[{ang, vector}] or RotationMatrix[{eo, ei, ej, ek}] returns the rotation matrix associated with the given angle and axis of rotation, or associated with the given Euler parameters. † The 2D rotation matrix in terms of a rotation ang is defined as ij cosHangL -sinHangL zy jj zz k sinHangL cosHangL {
MechanicalSystems
562
† In terms of 2D Euler parameters, the rotation matrix is simply ij ei -ej yz jj zz k ej ei { † The 3D rotation matrix in terms of Euler parameters is defined as ij ei2 + eo2 - ÅÅÅÅ12 ei ej - eo ek ei ek + ej eo yz zz jj zz jj ej2 + eo2 - ÅÅÅÅ12 ej ek - eo ei zzz 2 jjj ei ej + ek eo zz jj z jj 1 z 2 2 + eo ÅÅÅÅ ei ek eo ej ej ek + ei eo ek k 2 { † When transforming an angle-axis, the Assumptions->Normalized option may be given to cause RotationMa trix to assume that vector is a unit vector, thus simplifying the result. The default setting is Assumptions-> None. † In Modeler3D, RotationMatrix[vector] returns the rotation matrix associated with the given virtual rotation vector {vx, vy, vz}. † When RotationMatrix is used to transform a virtual rotation or an angle-axis, vector may be a simple vector or a Mech vector object with head Vector, Line, or Plane. † See also: EulerParameters, Rotation, VirtualRotation.
SaveMech 2D/3D † SaveMech["file"] saves the entire state of the current Mech system in file such that it can be restored with Get["file"]. † When reloading a model has been saved with SaveMech it is not necessary to first call Needs on Modeler2D or Modeler3D. The necessary Mech packages are reloaded by simply by loading the saved model with Get. † SaveMech attempts to save all references to user-defined variables upon which the current model depends. † See also: KillMech.
SensitivitySystem 2D/3D † SensitivitySystem is the head of the data object returned by SetSensitivity.
Appendix B: MechanicalSystems Function Listing
563
† The format of the SensitivitySystem data object is SensitivitySystem[symbols, initialconditions, Jacobian, derivatives, variables]. † SensitivitySystem is not intended to be used external to Mech. † See also: SolveSensitivity.
SetBodies 2D/3D † SetBodies[bodies] incorporates the local coordinates, initial guesses, and inertia properties provided by the bodies into the current mechanism model. The bodies must be a list or sequence of SysBody data objects that are built by the Body function. † If any of the SysBody objects received by SetBodies contains a PointList option, SetBodies automatically rebuilds the entire system of constraint expressions in the current model so that the changed coordinates are reflected in the current model. † If none of the SysBody objects contains the PointList option, SetBodies only updates the necessary mass properties or initial guesses. † See also: SetConstraints, SetLoads.
SetConstraints 2D/3D † SetConstraints[constraints] builds the mathematical mechanism model represented by constraints. The constraints must be a list or sequence of SysCon data objects that are returned by any of the standard Mech constraint functions. † SetConstraints goes through the following steps in testing the constraints for validity: 1. Check that all of the extra variables in special constraints (cam constraints, 3D gear constraints, and the user-defined Constraint) are unique. 2. Check that each constraint has a unique constraint number, cnum. 3. Check that the number of degrees of freedom constrained is equal to the number of dependent variables.
MechanicalSystems
564
4. Check that all of the local points that are specified by point number have been defined, unless BuildMech-> None is specified. 5. Check that all of the symbols that are to be used as dependent variables are not protected and have no definition or attributes. † The following options can be given: BuildMech
Location
which system equations are built immediately
Compiled
False
whether to compile the resulting expressions
SetGuess
False
whether to reset all initial guesses to default values
† The following Modeler3D option can be given: Virtual
True
whether to use virtual displacements to build the Jacobian
† With BuildMech->Location, SetConstraints does not immediately build the equations necessary for the velocity and acceleration solutions, or the generalized force solution; these equations are built automatically when SolveMech is called with nondefault settings for the Solution option. † BuildMech->Dynamic should be used to immediately build all possible equations. † BuildMech->None can be used to prevent any equation building. If constraints are given that contain local point numbers of points that are not yet defined, BuildMech is automatically set to None with a warning. † Compiled->True can decrease run time by more than a factor of two for large systems. † Some types of expressions cannot be compiled. If the evaluation of the compiled constraints fails, incorrect results will be returned by SolveMech because Mech does not store the symbolic form of the constraints along with the compiled form. † See also: CheckSystem, SetBodies, SetLoads.
SetCouple 2D/3D † SetCouple[sym, eqn] builds a CoupleSystem object in which the value of the symbol sym is sought that satisfies the equation eqn. † SetCouple[{sym1, sym2, … , symn}, {eqn1, eqn2, … , eqnn}] uses the n equations to try to solve for n symbols.
Appendix B: MechanicalSystems Function Listing
565
† SetCouple[{syms, … }, {equations1, options1}, {equations2, options2}, … ] attempts to find the values of the syms that satisfy all of the equationsi at different configurations. This usage is only meaningful if Time is included in the optionsi. † The CoupleSystem object is solved with SolveCouple. † The following options can be given: Compiled
False
whether to compile the resulting expressions
InitialGuess
Automatic
initial guesses to use at each configuration
Solution
Automatic
what solution level to seek
Time
None
the value of time, or an indication that time is independent
† The Time option specifies the value of time, T. The Time option must be present if SetCouple is used with a system that is time dependent. † Time->Free causes time to be treated as a dependent variable, which adds one degree of freedom to the model and requires one additional equation for each occurrence of Time->Free. † SetCouple[{syms, … }, {equations1, Time->t1, options1}, {equations2, Time->t2, options2}, … ] attempts to find the values of the syms that satisfy all of the equationsi at different points in time. † If InitialGuess is unspecified, SetCouple uses the initial guesses from the current model, as obtained from LastSolve. † The Compiled and Solution options should only be specified at the end of the argument list, not among the sublists of equationsi, because their effect is global. † If the Solution option is specified with too low a setting (such as if Solution->Location is specified but the equations eqni contains velocity terms), SetCouple automatically adjusts to a higher-order solution. † See also: FindTime, SetFree.
MechanicalSystems
566
SetFree 2D/3D † SetFree[dropcon, options] builds a FreeSystem object containing the mathematical equations required to find equilibrium conditions of the current model. The dropcon argument is used to specify the constraint(s) that are dropped to make the system underconstrained. † The format of dropcon is identical to that used by the Constraints function. † The FreeSystem object is solved with SolveFree. † The following options can be given: Compiled
False
whether to compile the resulting expressions
InitialCondition
Automatic
initial conditions for the integration
InitialGuess
Automatic
initial guesses to use at each configuration
Solution
Static
whether to seek Static, Kinematic, or Dynamic equilibrium
† If InitialGuess or InitialCondition is unspecified, SetFree uses the current model initial guesses, as obtained from LastSolve. † InitialCondition can also be specified in SolveFree. † If Solution->Static is given, the model must have some nonzero applied loads for a static equilibrium position to exist. † If Solution->Kinematic is given, the model must have velocity-dependent loads applied, or no equilibrium velocity can exist. † If Solution->Dynamic is given, the model must have nonzero masses applied to at least one moving body with SetBodies. † See also: SetCouple.
Appendix B: MechanicalSystems Function Listing
567
SetGuess 2D/3D † SetGuess[rules] sets the current values of the system initial guesses. Guesses are given as a list of rules specifying the new values of the variables that are to have their current guesses changed. † SetGuess[] restores all of the initial guesses to their default values as specified with SetBodies. † SetGuess does not change the values of any of the permanent guesses set with SetBodies. Only the guesses that will be used for the very next solution attempt are changed. † SetGuess accepts the SetParameters option to determine whether parameters in rules are used to change the values of system parameters. The default setting is SetParameters->False. † SetGuess can be used to change the values of existing parameters with SetParameters->True, but not to introduce new ones; use SetParameters as a separate function call. † See also: InitialGuess, LastSolve.
SetLoads 2D/3D † SetLoads[loads] prepares the applied load vector and incorporates the given loads into the current model. Each of the loads must be a SysLoad data objects returned by a Mech load function. † SetLoads[] removes any existing loads from the current model. † Loads applied to a body number that is not a member of the current model are ignored with a warning message. † The following options can be given: AddLoads
False
whether to add the loads to the load vector or replace it
BuildMech
Static
which system equations are built immediately
LambdaGuess
Automatic
initial guesses for the Lagrange multipliers
† BuildMech->None can be used to prevent any equation building. If loads are given that contain local point numbers of points that are not yet defined, BuildMech is automatically set to None with a warning. † BuildMech can be set to None, Static, Kinematic, or Dynamic.
MechanicalSystems
568
† LambdaGuess can be set to a number, which is as the guess for all of the Lagrange multipliers, or a list of numbers equal in length to the number of degrees of freedom in the current model. † See also: Force, Moment, SetBodies, SetConstraints.
SetParameters 2D/3D † SetParameters[rules] sets the values of existing parameters or adds new parameters to the current parameters list. Parameters are given as a list of rules. Each element of rules must be of the form symbol->number. SetParameters returns the entire parameters list. † SetParameters is also an option for SetGuess and SolveCouple. † New rules that are associated with the same symbols as rules that are currently in the parameters list replace those in the current list. † New parameters are given the Protected and Constant attributes. † The Constant attribute allows expressions containing parameters to be differentiated with Dt. † See also: ClearParameters, Parameterize, Parameters.
SetPath 2D/3D † SetPath[constraints] builds a PathSystem object containing the differential equations necessary to find the time domain motion of a fully constrained nonholonomic system. Kinematic constraints in the current mechanism are replaced with the given velocity-dependent constraints. † The PathSystem object is solved with SolvePath. † The constraint number of the constraint that is passed to SetPath must match the constraint number of a constraint that is a member of the current system. Compiled
False
whether to compile the resulting expressions
InitialCondition
Automatic
initial conditions given as a list of rules
† See also: SetFree.
Appendix B: MechanicalSystems Function Listing
569
SetSensitivity 2D/3D † SetSensitivity[symbols] builds a SensitivitySystem object containing the equations necessary to find the sensitivity of the current model to changes in the symbols. † SetSensitivity returns a SensitivitySystem object that is solved with SolveSensitivity. † The SensitivitySystem object is solved with SolveSensitivity. † SetSensitivity accepts the InitialCondition option to specify the configuration of the mechanism at which the sensitivity is determined. The default setting is InitialCondition->Automatic. † See also: SetFree.
SetSymbols 2D/3D † SetSymbols[options] is used to set fundamental properties of Mech’s modeling engine. † SetSymbols should be run at the beginning of a Mech session because the properties it sets are reflected throughout the function of Mech. It is necessary to rebuild the entire model after calling SetSymbols. † Running SetSymbols has the effect of clearing the entire model. SetSymbols calls ClearMech[Con straints] and ClearMech[Loads]. † The following Modeler2D options can be given: Method
Angular
whether to represent angular orientation with an angle or Euler parameters
SymbolBasis
{"T", {"X", "Y"}, {"Ei", "Ej"}, "Θ", "Λ", "d"}
the basis for all symbols generated by Mech
MechanicalSystems
570
† The following Modeler3D options can be given: Coordinates
Global
whether to use Global or Local coordinates to represent angular velocity and acceleration
Method
Euler
whether to represent angular velocity with a vector or derivatives of Euler parameters
SymbolBasis
{"T", {"X", "Y", "Z"},
the basis for all symbols generated by Mech
{"Eo", "Ei", "Ej", "Ek"}, {"Ωx", "Ωy", "Ωz"}, "Λ", "d"} † The setting of the Coordinates option has no effect unless Method->Angular is also given because Euler parameters are neither global nor local. † In Modeler3D the angular orientation of a body is always represented by four Euler parameters. The setting of Method affects only the choice of how to represent angular velocity and acceleration. † See also: SetConstraints.
SkewSym 3D † SkewSym[vector] returns the skew-symmetric matrix associated with the direction vector of the Modeler3D vector object. ij 0 -a3 a2 yz jj zz 0 -a1 zzz. † SkewSym[{a1, a2, a3}] returns jjjj a3 zz jj z 0 { k -a2 a1 † SkewSym[bnum, lpnt] is interpreted as SkewSym[Vector[bnum, lpnt]]. † Other SkewSym[args, … ] instances are interpreted as SkewSym[Line[args]]. † SkewSym[u].v is equivalent to Cross[u, v] for vectors u and v. † See also: Cross, InertiaMatrix.
Appendix B: MechanicalSystems Function Listing
571
Solution 2D/3D † Solution is an option for SolveMech, StepMech, SetCouple, SetFree, FindTime, and LockMech that specifies the level of solution considered. † Solution may be set to Location, Velocity, Acceleration, Static, Kinematic, or Dynamic. † Solution->Location considers only the model’s location variables. † Solution->Velocity considers the model’s location and velocity variables. † Solution->Acceleration considers the model’s location, velocity, and acceleration variables. † Solution->Static considers the model’s location and generalized force variables. † Solution->Kinematic considers the model’s location, velocity, and generalized force variables. † Solution->Dynamic considers the model’s location, velocity, acceleration, and generalized force variables. † See also: SetSymbols.
SolveCouple 2D/3D † SolveCouple[cpsys, options] solves the CoupleSystem object cpsys built by SetCouple. SolveCouple returns a list of rules representing the solution to cpsys. † If cpsys is a symbol that evaluates to a CoupleSystem object, cpsys is updated with a new set of initial guesses as specified by the current solution of cpsys.
MechanicalSystems
572
† The following options can be given: SetParameters
False
whether system parameter values should be updated to the new values found in the solution of cpsys
InitialCondition
Automatic
the value of time for each configuration
DampingFactor
1
damping factor applied at each iteration step
MaxIterations
15
the maximum number of iterations allowed
ZeroTest
(Abs[#]<10^-9&)
a test to determine when a solution is sufficiently close to zero
† InitialCondition must be a list of rules of length n for an n configuration CoupleSystem. The list of rules is of the form InitialCondition->{Time->t1, Time->t2, … }. † See also: SolveFree.
SolveFree 2D/3D † SolveFree[freesys, options] finds the solution to the FreeSystem object built by SetFree. SolveFree returns a list of rules representing the solution to freesys. † SolveFree[freesys, endtime, options] integrates the equations of motion in freesys and returns the time domain free response. † When finding the time domain free response, SolveFree returns a list of InterpolatingFunction rules representing the solution. † When finding the time domain free response, the start time is taken from the initial conditions.
Appendix B: MechanicalSystems Function Listing
573
† The following options can be given: ConstraintCorrection
False
use the lower-order constraints to correct errors in the numerical integration at each time step
FitDegree
Cubic
the degree of polynomial that is used to approximate the integrand
FunctionOfTime
True
whether the returned InterpolatingFunc tion objects are explicitly functions of the time variable, T
InitialCondition
Automatic
initial conditions for the integration
Interpolation
True
whether to use InterpolatingFunction objects to represent the solution
InterpolationOrder
3
the polynomial order of the interpolation
MakeRules
{Location, Parameters}
which dependent variables to generate InterpolatingFunction objects for
MaxError
0.0001
the error magnitude that will trigger an adjustment of step size
MaxIterations
15
the maximum number of iterations allowed at each time step
MaxSteps
500
the maximum number of time steps allowed
MaxStepSize
Infinity
the maximum time step size allowed
Method
Automatic
whether to use a Predictor or Corrector integration algorithm
StartingStepSize
Automatic
the initial time step size
StepSize
Automatic
if given, the fixed time step size
ZeroTest
(Abs[#]<10^-9&)
a test to determine when a solution is sufficiently close to zero
MechanicalSystems
574
† The InitialCondition option is used to specify the initial location variables for a FreeSystem object that is to be solved for free velocity, or the initial location and velocity for a FreeSystem object that is to be solved for free acceleration. † Values for parameters can be set with the InitialCondition option, in which case they override the values given in the current parameters list or contained in the FreeSystem object. † The StartingStepSize option is effective only if StepSize->Automatic is given. † The MaxIterations option is used only when the system is nonlinear in terms of the Lagrange multipliers, so that an iterative solution must be used at each time step. † If Interpolation->False is given, the solution data is returned as lists of numbers instead of Interpolat ingFunction objects. † See also: SolvePath.
SolveMech 2D/3D † SolveMech[t] attempts to find a location solution to the current model at time t. SolveMech returns a list of rules containing the global coordinates of each body. † SolveMech[{t1, t2, … , tn}] returns a nested list of solution rules containing solution points at all of the ti. † SolveMech[{t1, t2, … , tm}, n], n >= m, returns a nested list of solution rules containing solution points at all of the ti, with the remaining n-m solution points interspersed evenly throughout the ti. † SolveMech[rules] takes the supplied list (or nested list) of rules and uses them as initial guesses for the next solution attempt. In this case the value of time t is also taken from rules. † SolveMech[None] or SolveMech[] attempts to find a single location solution to the current non-time-dependent model. † For models that are not time-dependent, the time specification None can be omitted.
Appendix B: MechanicalSystems Function Listing
575
† The following options can be given: CheckRules
True
whether to examine the given rules to see if they constitute a valid solution
DampingFactor
1
damping factor applied at each iteration step
FunctionOfTime
True
whether the returned InterpolatingFunc tion objects are explicitly functions of the time variable, T
Interpolation
False
whether to use InterpolatingFunction objects to represent the solution
InterpolationOrder
Automatic
the polynomial order of the interpolation
MakeRules
{Location, Generalized, Parameters}
which dependent variables to generate
15
the maximum number of iterations allowed at
MaxIterations
InterpolatingFunction objects for
each time step Solution
Location
what order of solution to seek
ZeroTest
(Abs[#]<10^-9&)
a test to determine when a solution is sufficiently close to zero
† Solution may be set to Location, Velocity, Acceleration, Static, Kinematic, or Dynamic. † For example, SolveMech[t, Solution->Velocity] returns the complete set of location and velocity solution rules, etc. † The CheckRules option can be used to prevent SolveMech from testing supplied initial guesses to see if they are valid, thus, SolveMech[rules, Solution->Acceleration, CheckRules->False] calculates the acceleration solution based on the location and velocity specified in the supplied rules, regardless of their validity. † The ZeroTest option should specify a function that returns True if applied to a number that is sufficiently close to zero. † Interpolation->True causes SolveMech to interpolate the solution rules, which is only meaningful if more than one solution point is requested. † If the Interpolation option is specified, the InterpolatingFunction objects returned incorporate the firstor second-order information contained in the solution, if a velocity or acceleration solution was specified.
MechanicalSystems
576
† The FunctionOfTime option is used to cause the InterpolatingFunction objects returned to be explicitly functions of the time variable, T. † See also: BuildMech.
SolvePath 2D/3D † SolvePath[pathsys, endtime, options] finds the solution to the PathSystem object built by SetPath. † SolvePath integrates the equations of motion from the initial time to endtime † SolvePath returns a list of InterpolatingFunction rules representing the solution. † SolvePath accepts all of the options to SolveFree. † The integration block used by SolvePath is the same as that used by SolveFree. † See also: SolveMech.
SolveSensitivity 2D/3D † SolveSensitivity[senssys, options] finds the solution to the SensitivitySystem object built by SetSensitivity. † SolveSensitivity returns a list of rules representing the solution. † The solution returned by SolveSensitivity is apparently identical to the velocity solution returned by SolveMech[ … , Solution->Velocity], but the values do not represent derivatives with respect to time, they represent derivatives with respect to the symbols supplied to SetSensitivity. † See also: SolveFree.
Appendix B: MechanicalSystems Function Listing
577
Sphere 3D † Sphere[axis, rad, facets] generates a sphere of radius rad, centered at the origin of axis, with facets divisions along either circumference. The axis of revolution of the sphere points in the direction of axis. † Sphere[axis, rad, {circfacets, polarfacets}] generates a sphere with circfacets segments around the equator, and polarfacets segments looping over the poles. † Sphere returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † rad may be replaced with a list {rx, ry, rz} to produce an ellipsoid. † The following options can be given: Angle
{0, 2π}
the start and end of the swept angle of revolution
Faces
True
whether to draw with filled polygons or wire frames
† The Angle option specifies the swept angle about the major axis. † Mech’s overloading of the built-in Sphere symbol has no effect on its usage in other Mathematica code. † See also: Bar, Revolve, Torus, Wheel.
Spherical3 3D † Spherical3[cnum, point1, point2] constrains point1 to be coincident with point2 in 3D space. † Spherical3 constrains three degrees of freedom. † Spherical3 essentially models a 3D ball-and-socket joint. † The three equations in Spherical3 constrain the X, Y, and Z coordinates of the pointi to be equal. † See also: DirectedPosition3, Revolute2, SetConstraints, SysCon.
MechanicalSystems
578
SphericalToXYZ 3D † SphericalToXYZ[{radius, baseangle, altitudeangle}] converts the given point from spherical to Cartesian coordinates and returns {x, y, z}. † SphericalToXYZ accepts the Coordinates option to specify the relationship between the two coordinate systems. By default, altitudeangle is measured in the Z direction, and a baseangle of zero puts the point in the Y = 0 plane. Coordinates->YZX causes altitudeangle to be measured in the X direction, and so on. † More complicated coordinate reorientations require a rotation matrix. † See also: CylindricalToXYZ, XYZ, XYZToCylindrical, XYZToSpherical, ZXY.
SplineFit 2D/3D † SplineFit[data, options] generates a SplineFunction object representing the data as a cubic spline. † data is given as rectangular matrix of numbers, that is, a list of coordinates. † For a 2D spline curve data is given as a list of 2D vectors; for a 3D spline data is a list of 3D vectors. † SplineFit works with data of any dimensionality, not only 2D or 3D. † The following options can be given: Parameters
Automatic
specify the knot points of the spline
EndConditions
Natural
indicate Natural, Closed, or tangent ends
† See also: ArcLength.
Appendix B: MechanicalSystems Function Listing
579
SplineFunction 2D/3D † SplineFunction[range, internal] represents a spline created by SplineFit. † The SplineFunction accepts an argument within the range of the spline for evaluation at some point along the curve. † When given a single symbolic argument, an n-dimension SplineFunction evaluates to a list of n SplineFunc tion objects. This is useful when the spline is to be passed to a function that requires two or three separate parametric functions in a list. † SplineFunction objects can be used for Mech cam profiles. † Cubic splines have zeroth-, first-, and second-order continuity. † See also: ArcLength.
StageSwitch 2D/3D † StageSwitch[cnum, test1, const1, test2, const2, … ] can be used in place of a single constraint supplied to SetConstraints. StageSwitch evaluates each of the testi in turn, and applies the consti corresponding to the first testi that returns True. † StageSwitch[test1, load1, test2, load2, … ] can be used in place of a load supplied to SetLoads. † StageSwitch functions analogously to Which when used with constraints. † Each of the consti must be Mech constraint objects that have the head SysCon. † StageSwitch produces an error if any of the testi fail to return True or False at runtime, or if all the testi return False. † When used with load objects, the loadi may be single loads or lists of loads. † StageSwitch applies all of the loadi to the model for which the corresponding testi returns True (unlike the behavior of Which). † If all of the testi return False, no loads are applied. † See also: Constraint, Load, TimeSwitch.
MechanicalSystems
580
Static 2D/3D † Static is a setting for the Solution option for several Mech functions. † Solution->Static causes such functions to seek a solution for the location and static loading of the current model. † The alternatives to the Static setting are Location, Velocity, Acceleration, Kinematic, and Dynamic. † If Solution->Static is specified with a model that has velocity-dependent loads, all velocities are set to zero. † See also: SolveMech, SetFree.
Step 3D † Step[n, i, j, k] represents a special step function. Step returns 1 if the member of {i, j, k} indicated by index n is greater than the other members, 0 otherwise. † Step is used to develop the piecewise continuous expressions used to represent the transformation of an axis with an unspecified reference direction. † Step is not defined for complex numbers. † See also: ReferenceDirection.
StepMech 2D/3D † StepMech[t] steps the constraint equations through one iteration of the Newton-Rhapson solution block with time set to t, regardless of any convergence criteria. † StepMech[] uses no value of time. † StepMech[rules] takes the supplied list of rules and uses them as initial values for the next step.
Appendix B: MechanicalSystems Function Listing
581
† StepMech can be used to help diagnose nonconvergent models by examining the direction that Newton’s method steps the solution vector. † The following options can be given: DampingFactor
1
damping factor applied at each iteration step
Solution
Location
what order of solution to seek
† See also: SolveMech.
StepSize 2D/3D † StepSize is an option for SolveFree that sets the constant time-step size used by the numerical integration algorithm. † The default, StepSize->Automatic, uses an adaptive algorithm that adjusts the time-step size up or down by a factor of two when necessary. † Specifying a setting other than Automatic disables the automatic adjustment of step size and uses the specified step size for the entire integration. † See also: MaxError, StartingStepSize.
SymbolBasis 2D/3D † SymbolBasis is an option for SetSymbols that is given as a nested list of strings that specifies the basis for the symbol names that will be generated and included in all models. † In Modeler2D the default setting is SymbolBasis->{"T", {"X", "Y"}, {"Ei", "Ej"}, "Θ", "Λ", "d"}. † In Modeler3D the default setting is SymbolBasis->{"T", {"X", "Y", "Z"}, {"Eo", "Ei", "Ej", "Ek"}, {"Ωx", "Ωy", "Ωz"}, "Λ", "d"}. † The last element in the SymbolBasis list "d" is the postfix applied to symbol names to imply a time derivative. † See also: SetSymbols.
MechanicalSystems
582
SysBody 2D/3D † SysBody is the head of a system body data object returned by the Body function. † The format of the SysBody object is SysBody[{ptcoord1, ptcoord2, … }, initialguesses, mass, inertia, centroid, bnum]. † The print format of a SysBody object is SysBody[bnum, <>] † SysBody is not intended to be used external to Mech. † See also: SysCon, SysLoad.
SysCon 2D/3D † SysCon is the head of a system constraint object returned by all Mech constraint functions. † The format of the SysCon data object is SysCon[{expr1, expr2, … , exprn}, {Point[bnum, pnum], … }, {{xvar1, guess1}, … }, cnum, n, {swtime1, … }, "name"]. † n is the number of degrees of freedom of the constraint. † SysCon is not intended to be used external to Mech. † See also: Constraint, SysBody, SysLoad.
SysLoad 2D/3D † SysLoad is the head of a system load object returned by all Mech load functions. † The format of the SysLoad data object is SysLoad[{force, moment}, {Point[bnum, pnum], … }, bnum, "name"]. † SysLoad is not intended to be used external to Mech. † See also: Force, Gravity, Load, Moment, SysBody, SysCon.
Appendix B: MechanicalSystems Function Listing
SysPlot 2D/3D † SysPlot is used by CamPlot to carry a plot object that evaluates to a Graphics object when numerical values are available for the coordinates of the cam body. † SysPlot returns a Graphics object (or Graphics3D object), not a graphics primitive. † SysPlot is not intended to be used external to Mech. † See also: SysPrimitive.
SysPrimitive 2D/3D † SysPrimitive is the head of the Graphics primitive generating functions that are returned by some Mech graphics functions. † SysPrimitive functions will evaluate to a list of Mathematica graphics primitives when all of the Mech system symbols on which they depend are replaced by numbers. † Several Mech graphics functions return SysPrimitive objects of the form: SysPrimitive[name, boolean, arg3, arg4, … ]. † All of the arguments of SysPrimitive from argument three on must evaluate to numbers or lists of numbers for the entire SysPrimitive to evaluate to Mathematica graphics primitives. † SysPrimitive is not intended to be used external to Mech. † See also: Arrow, Bar, Extrude, Revolve, Sphere, SysPlot, Torus, Wheel.
Tangent 2D † Tangent[point1, rad1, point2, rad2] generates a pair of lines tangent to two implied circles. † If a circle of radius rad1 is centered at point1, and another of radius rad2 is centered at point2, then Tangent generates two lines tangent to both circles representing a belt or chain between two pulleys.
583
MechanicalSystems
584
† Tangent returns a list of two Mathematica Line objects, so if only one of the two tangent lines is desired, one of the two parts of the list may be extracted. † The list of Mathematica graphics primitives returned are functions of mechanism location variables. † See also: Edge, Wheel.
TangentConstraint 2D/3D † TangentConstraint is an option for FindSwitchTime that specifies whether or not the constraint pair in question comes into conjunction tangentially. † TangentConstraint->True implies that at the discreet point in time where both constraints are simultaneously valid, both the location and the velocity solutions are identical for either constraint. † If this condition exists, TangentConstraint->True must be used to find a valid solution. † When TangentConstraint->True is given, FindSwitchTime returns the location and velocity solutions at the switch point. † The default setting is TangentConstraint->False. † See also: RequiredEquations.
Time 2D/3D † Time is an option for SetCouple that is used to specify the value of time. † Time->Free specifies that time is a dependent variable. † The numeric value of time can also be specified with the InitialGuess option by including a rule for the current time variable. † Time->Free cannot be specified within the InitialGuess option, but must be given as a separate option. † The default setting is Time->None. † See also: Free.
Appendix B: MechanicalSystems Function Listing
585
TimeInterpolate 2D/3D † TimeInterpolate[expr, {rules1, rules2, … }] returns an InterpolatingFunction object representing expr as a function of time. † Each of the rulesi must be a list of rules containing numerical replacements for all of the subexpressions in expr, as well as a rule for the value of time T. † TimeInterpolate accepts the InterpolationOrder option. † If higher-order (velocity or acceleration) terms are included in the rulesi, TimeInterpolate automatically calculates the time derivatives of expr and uses the values of the higher-order terms supplied in rulesi to produce a higher-order InterpolatingFunction. † The default option InterpolationOrder->Automatic is equivalent to three for zeroth- and first-order data and five for second-order data. † See also: Interpolation, SolveMech.
TimeSwitch 2D/3D † TimeSwitch[cnum, con0, time1, con1, … , timen, conn] can be used in place of a single constraint supplied to SetConstraints. TimeSwitch applies coni if timei < T < time(i+1). The first and last constraints are applied when T < time1 or T >timen. † TimeSwitch[load0, time1, load1, … , timen, loadn] can be used in place of a single forcing function supplied to SetLoads. TimeSwitch applies loadi if timei < T < time(i+1). The first and last loadi are applied when T < time1 or T > timen. † The timei must evaluate to numbers in ascending order. † When used with load objects, if a time0 precedes load0 then no load is applied by the TimeSwitch before time0. † Similarly, if a time(n+1) comes after loadn, then no load is applied after time(n+1). † See also: Constraint, Load, StageSwitch.
MechanicalSystems
586
Torus 3D † Torus[axis, majrad, minrad, facets] generates a torus of specified major and minor radii, centered at the origin of axis, with its major axis in the direction of axis, and facets segments around either axis. † Torus[axis, majrad, minrad, {majfacets, minfacets}] uses majfacets segments along the major circumference and minfacets segments along the minor circumference. † Torus returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † Either majrad or minrad may be replaced with a list {rx, ry} to produce a torus with an elliptical major radius or an elliptical cross section. † Given Torus[axis, {majrx, majry}, {minrx, minry}, … ] the torus will self-intersect if minrx > majry2 ê majrx. † The following options can be given: Angle
{0, 2π}
the start and end of the swept angle of revolution
Faces
True
whether to draw with filled polygons or wire frames
† The Angle option specifies the swept angle about the major axis only. † See also: Bar, Revolve, Sphere, Wheel.
Translate2 2D † Translate2[cnum, axis1, axis2] constrains axis1 to be parallel and coincident with axis2. † Translate2 constrains two degrees of freedom. † Translate2 is used to model a prismatic joint, such as a piston in a cylinder. † The first equation constrains to two axes to be parallel, the second constrains the origin of axis1 to lie on axis2. † See also: GenTranslate2, Revolute2, SetConstraints, SysCon.
Appendix B: MechanicalSystems Function Listing
587
Translate5 3D † Translate5[cnum, axis1, axis2] constrains the two axes to be parallel and coincident, and constrains the projections of the reference directions of the two axes to be parallel. † Translate5 constrains five degrees of freedom. † Translate5 models a prismatic joint; a slider that cannot rotate about any axis. † The first two equations constrain the two axes to be parallel, the third and fourth equations constrain the origin of axis2 to lie on axis1, and the fifth equation constrains the reference directions of the two axes to be aligned. † See also: Cylindrical4, GenTranslate5, Revolute5, SetConstraints, SysCon.
TwoGears1 2D † TwoGears1[cnum, point1, rad1, point2, rad2, C] models a gear set. The rotational positions of the gears are related as per their respective radii. † The constant C sets the initial rotational positions of the gears. † TwoGears1 constrains one degree of freedom. † The constant C, which sets the initial rotation of the gears, is given by the formula C = (rad1 e1 + rad2 e2) where e1 and e2 are determined in the following way. Place the two gears in any valid position and construct a vector from point1 to point2. e1 is the angle, measured in radians, from the constructed vector to the local x axis of gear 1 and e2 is the angle from the constructed vector to the x axis of gear 2. † TwoGears1 is functionally identical to TwoGears2 except that the distance between the two gears is not constrained, only their angular orientation. † If the Euler solution method is specified, TwoGears1 generates two constraints, and adds one extra variable to the model. † TwoGears1[cnum, point1, rad1, {sym1, guess}, point2, rad2, C] can be used to explicitly specify the name of the extra variable and its initial guess. Otherwise, a symbol of the form Θcnum is used. † TwoGears1 is used primarily when other constraints are already constraining the location of the axes of the two gears so that TwoGears2 would be redundant.
MechanicalSystems
588
† The first, and optional second, equation in TwoGears1 relates the rotation angles of the two gears. † See also: RackAndPinion1, SetConstraints, SetSymbols, SysCon, TwoPulleys1.
TwoGears2 2D † TwoGears2[cnum, point1, rad1, point2, rad2, C] models a gear set. The axes of the two gears point1 and point2 are constrained to be rad1 + rad2 units apart, and the rotational positions of the gears are related as per their respective radii. † The constant C sets the initial rotational positions of the gears. † TwoGears2 constrains two degrees of freedom. † The constant C, which sets the initial rotation of the gears, is given by the formula C = (rad1 e1 + rad2 e2) where e1 and e2 are determined in the following way. Place the two gears in any valid position and construct a vector from point1 to point2. e1 is the angle, measured in radians, from the constructed vector to the local x axis of gear 1 and e2 is the angle from the constructed vector to the x axis of gear 2. † If the Euler solution method is specified TwoGears2 generates three constraints and add one extra variable to the model. † TwoGears2[cnum, point1, rad1, {sym1, guess}, point2, rad2, C] can be used to explicitly specify the name of the extra variable and its initial guess. Otherwise, a symbol of the form Θcnum is used. † The first equation in TwoGears2 constrains the two points to lie rad1 + rad2 units apart; the second, and optional third, equation relates the rotation angles of the two gears. † See also: RackAndPinion2, SetConstraints, SetSymbols, SysCon, TwoGears1, TwoPulleys2.
TwoPulleys1 2D † TwoPulleys1[cnum, point1, rad1, point2, rad2, dist, C] models a chain and sprocket or belt set. The rotational positions of the sprockets are related as per their respective radii. † The constant C sets the initial rotational position of the pulleys. † TwoPulleys1 constrains one degree of freedom.
Appendix B: MechanicalSystems Function Listing
589
† The radii of the two sprockets cannot be equal; use RotationLock1. † The constant C, which sets the initial rotation of the pulleys, is given by the formula C = (rad1 e1 – rad2 e2) where e1 and e2 are determined in the following way. Place the two sprockets in any valid position and construct a vector from point1 to point2. e1 is the angle, measured in radians, from the constructed vector to the local x axis of the first sprocket and e2 is the angle from the constructed vector to the x axis of the second sprocket. † TwoPulleys1 is functionally identical to TwoPulleys2 except that the distance between the two pulleys is not constrained, only their angular orientation. † If the Euler solution method is specified, TwoPulleys1 generates two constraints, and adds one extra variable to the model. † TwoPulleys1[cnum, point1, rad1, {sym1, guess}, point2, rad2, dist, C] can be used to explicitly specify the name of the extra variable, and its initial guess. Otherwise, a symbol of the form Θcnum is used. † The first, and optional second, equation in TwoPulleys1 relates the rotation angles of the two pulleys. † See also: RackAndPinion1, SetConstraints, SetSymbols, SysCon, TwoGears1.
TwoPulleys2 2D † TwoPulleys2[cnum, point1, rad1, point2, rad2, dist, C] models a chain and sprocket or belt set. The axes of the two sprockets point1 and point2 are constrained to be dist units apart, and the rotational positions of the sprockets are related as per their respective radii. † The constant C sets the initial rotational position of the pulleys. † TwoPulleys2 constrains two degrees of freedom. † The radii of the two sprockets cannot be equal; use RotationLock1. † The constant C, which sets the initial rotation of the pulleys, is given by the formula C = (rad1 e1 – rad2 e2) where e1 and e2 are determined in the following way. Place the two sprockets in any valid position and construct a vector from point1 to point2. e1 is the angle, measured in radians, from the constructed vector to the local x axis of the first sprocket and e2 is the angle from the constructed vector to the x axis of the second sprocket. † If the Euler solution method is specified, TwoPulleys2 generates three constraints, and add one extra variable to the model. † TwoPulleys2[cnum, point1, rad1, {sym1, guess}, point2, rad2, dist, C] can be used to explicitly specify the name of the extra variable, and its initial guess. Otherwise, a symbol of the form Θcnum is used.
MechanicalSystems
590
† The first equation in TwoPulleys2 constrains the two points to lie dist units apart; the second, and optional third, equation relates the rotation angles of the two pulleys. † See also: RackAndPinion2, SetConstraints, SetSymbols, SysCon, TwoGears2.
TwoPulleys4 3D † TwoPulleys4[cnum, axis1, rad1, {alpha, guess}, axis2, rad2, dist, C] is identical to TwoPulleys5 except that the heads of the two axes are not constrained to be adjacent. Thus, the two pulleys are free to slide on their axes, relative to each other. † TwoPulleys4 constrains four degrees of freedom. † TwoPulleys4 is essentially TwoPulleys5 with the third equation dropped. † The symbol alpha tracks the spin of axis1, relative to a vector spanning from axis1 to axis2. † The constant C, which sets the initial positions of the pulleys, is given by the formula C = rad1 e1 – rad2 e2. e1 and e2 are determined in the following way. Place the two pulleys in any valid orientation and construct a vector from the origin of axis1 to that of axis2. e1 is the angle, in radians, measured from the constructed vector to the reference direction of axis1, and e2 is the angle from the vector to the reference direction of axis2. † TwoPulleys4 generates five constraint equations and introduces one new variable, hence constraining four degrees of freedom. † The first two equations in TwoPulleys5 constrain axis1 to be parallel to axis2, the third equation constrains the axes to be dist units apart, and the fourth and fifth equations relate the value of the variable alpha to the rotational displacements of the pulleys. † See also: ParallelGears4, SetConstraints, SetSymbols, SysCon.
TwoPulleys5 3D † TwoPulleys5[cnum, axis1, rad1, {alpha, guess}, axis2, rad2, dist, C] models a pair of pulleys and a belt. The axes of the two pulleys, axis1 and axis2, are constrained to be parallel and dist units apart, and the origins of these two axes are constrained to be adjacent. † The rotational positions of the two pulleys are related as per their respective radii. † TwoPulleys5 constrains five degrees of freedom.
Appendix B: MechanicalSystems Function Listing
591
† The symbol alpha tracks the spin of axis1, relative to a vector spanning from axis1 to axis2. † The constant C, which sets the initial positions of the pulleys, is given by the formula C = rad1 e1 – rad2 e2. e1 and e2 are determined in the following way. Place the two pulleys in any valid orientation and construct a vector from the origin of axis1 to that of axis2. e1 is the angle, in radians, measured from the constructed vector to the reference direction of axis1, and e2 is the angle from the vector to the reference direction of axis2. † TwoPulleys5 generates six constraint equations and introduces one new variable, hence constraining five degrees of freedom. † The first two equations in TwoPulleys5 constrain axis1 to be parallel to axis2, the third equation constrains the origin of axis2 to lie adjacent to axis1, the fourth equation constrains the axes to be dist units apart, and the fifth and sixth equations relate the value of the variable alpha to the rotational displacements of the pulleys. † See also: OrthogonalGears5, ParallelGears5, SetConstraints, SetSymbols, SysCon, TwoPulleys4.
Type 2D/3D † Type is an option for Loads that specifies whether Applied, Reaction, or Dynamic loads are returned. † The default setting is Type->Applied. † See also: Coordinates.
Unit 2D/3D † Unit[vector] returns a unit vector pointed in the direction of vector. † vector may be a simple vector or a Mech vector object with head Vector, Line, or Plane (3D). † Unit[bnum, lpnt] is interpreted as Unit[Vector[bnum, lpnt]]. † Other Unit[args, … ] instances are interpreted as Unit[Line[args]]. † See also: Direction, Magnitude.
MechanicalSystems
592
Vector 2D/3D † Vector[bnum, lpnt] is a Mech data object that represents a vector in the local coordinate system of body bnum. The lpnt can be a vector, {x, y} (2D) or {x, y, z} (3D), or a point number (positive integer) referencing coordinates that were defined with SetBodies. † Any function that takes an vector argument can accept a Vector object, a Line object, or a Plane object (3D) in its place. † A simple vector {x, y} or {x, y, z} given in place of a Vector object is interpreted as Vector[1, {x, y}] or Vector[1, {x, y, z}]. † See also: Axis, Line, Plane, Point.
VectorToLocal 2D/3D † VectorToLocal[bnum, vector] returns the local direction vector of vector, in the coordinate system of body bnum. † When called with a vector specified in global coordinates, VectorToLocal is essentially the inverse function of Direction. † See also: PointToLocal.
Velocity 2D/3D † Velocity[point] returns the global velocity vector, {dX, dY} (2D) or {dX, dY, dZ} (3D) of the specified point. † Velocity[bnum, lpnt] is interpreted as Velocity[Point[bnum, lpnt]]. † Velocity[bnum] returns the velocity and angular velocity coordinates of body bnum in a flat list. † The bnum argument can take any of the forms accepted by Loads to obtain the velocity coordinates of multiple bodies.
Appendix B: MechanicalSystems Function Listing
593
† Velocity is also a setting for the Solution option for several Mech functions. † Solution->Velocity causes such functions to seek a solution for the location and velocity of the current model. † Velocity[All] returns the entire vector of velocity coordinates. † The behavior of Velocity[bnum] varies depending on whether the current solution method is Angular or Euler. † To use Velocity[bnum], bnum must be the number of a body in the current model. † In Modeler2D with the Euler solution method, Velocity[2] returns {X2d, Y2d, Ei2d, Ej2d}, but with the Angular solution method, Velocity[2] returns {X2d, Y2d, Θ2d}. † In Modeler3D with the Euler solution method, Velocity[2] returns {X2d, Y2d, Z2d, Eo2d, Ei2d, Ej2d, Ek2d}, but with the Angular solution method, Velocity[2] returns {X2d, Y2d, Z2d, Ωx2, Ωy2, Ωz2}. † Velocity[sym] or Velocity[{sym, … }] returns the velocity coordinates associated with the specified location coordinates sym. † The alternatives to the Velocity setting for the Solution option are Location, Acceleration, Static, Kinematic, and Dynamic. † See also: BodyEnergy, Omega, RelativeVelocity, SolveMech.
VelocityTerms 2D/3D † VelocityTerms[cnum] returns the part of the right-hand term of the current velocity constraint expressions associated with constraint cnum. † The cnum argument can take any of the forms accepted by Constraints to obtain velocity terms from multiple constraints. † VelocityTerms[All] returns the entire vector of velocity terms. † Jacobian[cnum, All] . Velocity[All] + VelocityTerms[cnum] returns the entire velocity constraint expression associated with constraint cnum. † The VelocityTerms are formed by differentiating the constraint vector with respect to time and discarding the components that are a linear function of the velocity coordinates. † See also: AccelerationTerms.
MechanicalSystems
594
Vertex 2D/3D † Vertex[bnum, {lpnt1, lpnt2, … , lpntn}] generates Point graphics primitives at each of the lpnti, on body bnum. Each lpnti can be either a local point number or local point coordinate {x, y} (2D) or {x, y, z} (3D). † Vertex[{point1, … , pointn}] generates n points on several different bodies. † Vertex returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † The Vertex function is analogous to the built-in Mathematica Point primitive. † See also: Edge, Facet.
Virtual 3D † Virtual is an option for SetConstraints that causes a Jacobian matrix based on virtual displacements to be generated, rather than a Jacobian based on an Euler transformation. † Setting Virtual->False causes SolveMech to run more slowly, but SetConstraints builds the model equations more quickly. † Virtual has no effect unless the current solution method is Angular. † The default setting is Virtual->True. † See also: Euler.
VirtualRotation 3D † VirtualRotation[bnum] returns the virtual rotation vector of angle of body bnum. The angle of rotation, in radians, of the body is equal to the magnitude of the resulting vector, and the axis of rotation is parallel to the vector. † VirtualRotation[{eo, ei, ej, ek}]returns the virtual rotation vector associated with the given Euler parameters.
Appendix B: MechanicalSystems Function Listing
595
† VirtualRotation[matrix] returns the virtual rotation vector associated with the given rotation matrix. † VirtualRotation[{q, vector}] returns the virtual rotation vector associated with given angle-axis. † VirtualRotation[vector] returns the given vector potentially converted to the global coordinate system. † When VirtualRotation is used to transform a virtual rotation or an angle-axis, vector may be a simple vector or a Mech vector object with head Vector, Line, or Plane. † Assumptions->Normalized can be given to cause VirtualRotation to assume that vector in an angle-axis pair is a unit vector. The default setting is Assumptions->None. † See also: Alpha, EulerParameters, Omega, Rotation, RotationMatrix.
Wheel 2D/3D † Wheel[point, rad] (2D) generates a Circle or Disk primitive (depending on the Faces setting) of radius rad centered at point. † Wheel[point, rad, facets] (2D) generates a circular disk of radius rad, with facets segments on the perimeter, centered at point. † Wheel[point, rin, rout, facets] (2D) generates an annular ring with the specified inner and outer radii. † Wheel[axis, rad, facets] (3D) generates a circular disk with the axis vector of the disk defined by axis and the center of the disk located at the origin of axis. † Wheel[axis, rin, rout, facets] (3D) generates an annular ring with the specified inner and outer radii. † In all cases, rad may be replaced with a list {rx, ry} to produce an elliptical disk or an elliptical hole. † Wheel returns a list of Mathematica graphics primitives that are functions of mechanism location variables. † The perimeter of the disk is composed of facets straight line segments. Thus a facets value of 4 yields a square. † In all cases, the radii may be replaced with a list {rx, ry} to produce an elliptical disk and/or an elliptical hole. † In Modeler2D, an axis can be given in place of point for a faceted wheel, in which case the direction of axis is used as the reference direction for the Angle option and the primary axis direction for an ellipse.
MechanicalSystems
596
† In Modeler3D, the reference direction of axis is always used as the reference direction for the Angle option and the local primary axis direction for an ellipse. † The following options can be given: Angle
{0, 2π}
the start and end of the swept angle of revolution
Faces
True
whether to draw with filled polygons or wire frames
† The Angle option allows a pie-slice of the entire wheel to be drawn. † See also: Bar, Box, Facet, Sphere, Torus.
XYToPolar 2D † XYToPolar[{x, y}] converts the given point from Cartesian to polar coordinates and returns {radius, angle}. † XYToPolar simply returns: :"################ x2 + y2# , tan-1 Hx, yL> † See also: PointToLocal, PolarToXY.
XYZ 3D † XYZ is a setting for the Coordinates option that is used with coordinate conversion functions to specify the right-handed coordinate system X-Y-Z. † See also: CylindricalToXYZ, SphericalToXYZ, XYZToCylindrical, XYZToSpherical.
Appendix B: MechanicalSystems Function Listing
XYZToCylindrical 3D † XYZToCylindrical[{x, y, z}] converts the given point from Cartesian to cylindrical coordinates and returns {radius, angle, altitude}. † XYZToCylindrical accepts the Coordinates option to specify the relationship between the two coordinate systems. By default, altitude is measured in the Z direction, and an angle of zero results from a Y coordinate of zero. Coordinates->YZX causes altitude to be measured in the X direction, etc. † More complicated coordinate reorientations require a rotation matrix. † See also: CylindricalToXYZ, SphericalToXYZ, XYZ, XYZToSpherical, ZXY.
XYZToSpherical 3D † XYZToSpherical[{x, y, z}] converts the given point from Cartesian to spherical coordinates and returns {radius, baseangle, altitudeangle}. † XYZToSpherical accepts the Coordinates option to specify the relationship between the two coordinate systems. By default, altitudeangle is measured in the Z direction and a baseangle of zero results from a Y coordinate of zero. Coordinates->YZX causes altitudeangle to be measured in the X direction, etc. † More complicated coordinate reorientations require a rotation matrix. † See also: CylindricalToXYZ, SphericalToXYZ, XYZ, XYZToCylindrical, ZXY.
YZX 3D † YZX is a setting for the Coordinates option that is used with coordinate conversion functions to specify the right-handed coordinate system Y-Z-X. † See also: CylindricalToXYZ, SphericalToXYZ, XYZToCylindrical, XYZToSpherical.
597
MechanicalSystems
598
ZXY 3D † ZXY is a setting for the Coordinates option that is used with coordinate conversion functions to specify the right-handed coordinate system Z-X-Y. † See also: CylindricalToXYZ, SphericalToXYZ, XYZToCylindrical, XYZToSpherical.
$MechBodyList 2D/3D † $MechBodyList returns a list of the integer body numbers of all the bodies in the current model, not including the ground body, body 1. † The value of $MechBodyList is altered when SetConstraints is run. † See also: SolveMech, $MechConstraintList, $MechPreSolve.
$MechConstraintList 2D/3D † $MechConstraintList returns a list of the integer constraint numbers of all the constraints in the current model. † The value of $MechConstraintList is altered when SetConstraints is run. † See also: SolveMech, $MechBodyList, $MechPreSolve.
$MechPostIterate 2D/3D † $MechPostIterate is a function that is applied to the iteration counter at each iteration of Mech’s iterative solution block.
Appendix B: MechanicalSystems Function Listing
599
† $MechPostIterate has no definition by default. † Setting $MechPostIterate = Print causes the iteration count to be printed at each step. † See also: SolveMech, $MechPreSolve.
$MechPreSolve 2D/3D † $MechPreSolve is applied to the numeric value of the time variable before each run of the location solution block. † $MechPreSolve has no definition by default. † Setting $MechPreSolve = Print causes the value of time to be printed each time SolveMech converges one solution. † $MechPreSolve can be used to perform various tasks before a solution is sought, such as to update the initial guesses with SetGuess to predetermined values that are known to be close to the solution being sought. † See also: $MechPostIterate.
$MechPrimeRules 2D/3D † $MechPrimeRules returns a list of replacement rules for all of the current Mech dependent variables to convert them to explicit functions of time with the Derivative operator replacing Mech’s symbolic derivatives. † $MechPrimeRules returns a list of the form {X2->X2[T], … , Y3d->Y3'[T], … }. † See also: $MechTimeRules.
$MechProcessFunction 2D/3D † $MechProcessFunction is a function that is applied to Mech’s internal lists of modeling equations as they are generated. $MechProcessFunction is initially set equal to Chop.
MechanicalSystems
600
† $MechProcessFunction is set to Chop by default. † See also: SolveMech, ZeroTest.
$MechTimeRules 2D/3D † $MechTimeRules returns a list of replacement rules for all of the current Mech dependent variables to convert them to explicit functions of time. † $MechTimeRules returns a list of the form {X2->X2[T], … , Y3d->Y3d[T], … }. † See also: $MechPrimeRules.
$MechTimeSymbol 2D/3D † $MechTimeSymbol returns the symbol that represents time in the current model. † The time symbol defaults to T. † The time symbol may be changed with SetSymbols.
$MechUseEulerMassTerm 3D † $MechUseEulerMassTerm can be set to True to include a term in the mass matrix that affects only the values of the generalized forces associated with the Euler generalized constraints. These forces have no physical meaning and are orthogonal to real forces. † The default setting of $MechUseEulerMassTerm is False. † See also: Angular, Euler.
Appendix B: MechanicalSystems Function Listing
601
$MechUseMinimalRotation 3D † $MechUseMinimalRotation can be set to True to cause Modeler3D to use a minimal rotation formulation to transform axes that have no specified reference direction. † The default setting of $MechUseMinimalRotation is False. † The minimal rotation formulation rotates the given axis through the minimal rotation required to be aligned with + Z. † The minimal rotation formulation produces a symbolic result that is much simpler, but becomes singular when the axis is pointed in the – Z direction. † The default formulation uses the Step function to generate a more complex piecewise continuous result that is nonsingular for any configuration. † Whether or not the symbolic axis transformation becomes singular is irrelevant if axes are specified entirely numerically, as they typically are. † See also: ReferenceDirection.
$MechVariables 2D/3D † $MechVariables returns a list of the names of all of the user variables that are present in the current model. Changes in the values of these variables affect the model. † The names returned by $MechVariables represent all of the symbols that have been recognized by the Mech variable management scheme. † Variables that are not listed by $MechVariables are not made local when Mech generates constraint and load equations, thus any assignments for such variables become embedded in new internal expressions as they are generated. † See also: BuildMech.
MechanicalSystems
602
$MechVersion 2D/3D † $MechVersion returns the version number of the Mech packages. † For the version referenced in this manual, $MechVersion returns the string "2.0".
