kinematic a nd d ynamic analy sis in mathematicamedia.wolfram.com/documents/mechanicalsystems... ·...

KINEMATIC AND DYNAMIC ANALYSIS IN MATHEMATICA

MOTION ANALYSIS OF RIGID BODY SYSTEMS

September 2005Third editionIntended for use with Mathematica 5 or higher

Software and manual written by Robert Beretta

Partnerships manager: Joy CostaDeveloper support specialist: Nirmal MalapakaProject manager: Jennifer PetersonSoftware quality assurance: Rachelle Bergmann, Jay Hawkins, Cindie StraterDocument quality assurance: Rebecca Bigelow, Lorri Coey, Marcia Krause, Angela Latham, Wendy Leung, Carol Ordal, Jan Progen, Joyce TracewellDocument production: Richard MiskeGraphic design: Megan Gillette, Jody Jasinski, Kimberly MichaelMarketing 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, USAphone: +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, withoutlimitation, such aspects of the system as its code, structure, sequence, organization, “look and feel”, programming language, and compilation ofcommand names. Use of the system unless pursuant to the terms of a license granted by Wolfram Research or as otherwise authorized by law is aninfringement of the copyright.

Dynamic Modeling and Wolfram Research make no representations, express or implied, with respect to this documentation or the softwareit 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 iswilling to license MechanicalSystems is a provision that Wolfram Research and its distribution licensees, distributors, and dealers shall in noevent be liable for any indirect, incidental, or consequential damages, and that liability for direct damages shall be limited to the amountof the purchase price paid for MechanicalSystems.

In addition to the foregoing, users should recognize that all complex software systems and their documentation contain errors andomissions. Dynamic Modeling and Wolfram Research shall not be responsible under any circumstances for providing information on orcorrections to errors and omissions discovered at any time in this document or the software it describes, whether or not they are aware ofthe errors or omissions. Dynamic Modeling and Wolfram Research do not recommend the use of the software described in this documentfor 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 arethe 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 planarand spatial rigid body mechanisms. The package is written entirely in the Mathematica programming lan-guage and is completely portable and platform independent. The source code is written in the preferredpackage format as generally used by Wolfram Research, Inc. for the standard packages that are includedwith 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 itsbasic functionality. MechanicalSystems actually consists of two basic Mathematica packages; one for planarmechanisms, Modeler2D, and one for spatial mechanisms, Modeler3D. Throughout this manual, the planarand spatial components of MechanicalSystems are often referred to by their package names, Modeler2D andModeler3D, 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 variouscomputer systems. In Sections 1.2 and 1.3 two very basic kinematic models (one planar and one spatial) aredeveloped 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 twomodels are essentially identical to show the parallelism between Modeler2D and Modeler3D. Further explora-tion of the functions introduced in this chapter and all of the other functions provided for kinematic model-ing can be found in Chapter 2.

1.1 Starting MechanicalSystems

This section covers the loading of MechanicalSystems packages into a Mathematica session on various com-puter systems.

1.1.1 Main Package

The MechanicalSystems packages are loaded into Mathematica in the same manner as a standard Mathematicapackage; with a Get or Needs statement.

Get["MechanicalSystems`Modeler2D`"] load the Modeler2D package.

1.1.3 Clearing and Unloading

MechanicalSystems may be reset to its initial state, or removed Mech entirely from the current Mathematicasession 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@DAfter executing KillMech nothing remains of the Mech session except whatever definitions the user hadmade in the Global` context, and a few undefined symbols that Mech creates in the Global` context. TheMech 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 kinematicmodel of a very simple mechanism. The mechanism is a planar slider-crank mechanism with two movingbodies, the crankshaft and the piston. The mechanism is modeled using the most abbreviated techniquepossible with Modeler2D. Later chapters will delve into the many more complex variations on thesetechniques.

1.2.1 Mechanism Function

The Modeler2D package must be loaded before calling any Mech functions.

Chapter 1: Getting Started 5

This loads Modeler2D.

In[1]:= Needs@"MechanicalSystems`Modeler2D "̀DHere is a graphic of the 2D slider-crank model.

-4 -2 0 2 4 6

-5

-2.5

0

2.5

5

7.5

10

The following example analyzes the motion of a classic slider-crank mechanism. This mechanism is modeledwith a simple and intuitive set of mechanical constraints that are representative of how such a problemwould 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.

6 MechanicalSystems

Each independent body in a Mech model must be given a unique positive integer body number. The choiceof each body number is arbitrary, except for the ground body, which must be body 1. These body numbersare used throughout a Mech model to reference each body. The ground body, which is stationary by defini-tion, is used as the reference location and orientation for the rest of the model. All mechanism models musthave 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 thebodies in a mechanism, and then define each of these names to be equal to the integer body number of thebody. 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 andthe piston. However, in the kinematic model this entire part can be replaced by a simple distance constraintspecifying that the crank pin and the piston pin are a constant distance apart. This technique decreases theoverall size of the model.

Local Coordinates

Each body in a mechanism model must have a local coordinate system attached to it. How to place thiscoordinate system on the body is up to the user and is based on the needs of the model. It is not necessary toplace the local coordinate origin at the center of gravity of the body. The local coordinate system of eachbody is used to define points, lines, and other features on the body that are then tied together to make themechanical constraints.

The local coordinate system of body 1, the ground body, is always coincident with the global coordinatesystem. Therefore, the global coordinate system is referenced through the ground body, simply by specify-ing body 1.


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.

-4 -2 0 2 4 6

-5

-2.5

0

2.5

5

7.5

10

80,0<P1

80,4

Here is a graphic of the crankshaft.

-4 -2 0 2 4 6

-4

-2

0

2

4

6

80,0

1.2.3 2D Constraints

Now that the local point coordinates on each body are defined, building the model is simply a matter oftying the points together with the correct mechanical constraints. Modeler2D provides a small library ofmechanical constraint objects that translate desired physical conditions that are imposed on the model intomathematical equations.

Constraint Objects

Four constraint objects are used to model the slider-crank mechanism, constraining a total of six degrees offreedom (three degrees of freedom for each moving body).

Revolute2[cnum, point1, point2] constrains point1to be coincident with point2.

RotationLock1[cnum, bnum, ang] constrains the angular coordinate of body bnum to be ang

radians.

Translate2[cnum, axis1, axis2] constrains axis1 to be parallel and coincident with axis2.

RelativeDistance1[cnum, point1, point2, dist]

constrains point1 to lie dist units away from point2.

cnum 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 numberof degrees of freedom that it constrains.

The first argument to each constraint object, cnum, is the user-specified constraint number. This number isused to reference the constraint later in the modeling process, much like body numbers are used to referencespecific bodies.

The point and axis arguments of Modeler2D constraint objects are specified with Point, Line, or Axisobjects, 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.

10 MechanicalSystems

Building the Model

The Modeler2D constraint objects used to model the physical relationships in the slider-crank mechanism areas 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, “Con-strain 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.


Here is the entire slider-crank model built in one step.

In[5]:= crankangle =.SetConstraints@Revolute2@1,Point@ground, 80., 0.

A graphic of the model at crankangle = 0.

-4 -2 0 2 4 6

-5

-2.5

0

2.5

5

7.5

10

Big surprise! The trivial solution at crankangle = 0 corresponds to the local coordinate system of eachbody being aligned with the global coordinate system. This is because the model was defined such as tohave this perfect assembled configuration. The piston is defined such that its local origin lies at a point that isoutside of the piston body, directly on the global origin when crankangle = 0. Note also the 3-4-5 triangleformed 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 verticalcoordinate of the piston, Y3, has increased to 2.13. All of the other coordinates are still zero and will alwaysbe so because of the specific function of this mechanism model.




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.

-4 -2 0 2 4 6

-5

-2.5

0

2.5

5

7.5

10

1.3 Basic 3D Model

In this section the basic functionality of Modeler3D is demonstrated by building a kinematic model of a verysimple mechanism. The mechanism is a slider-crank mechanism with two moving bodies, the crankshaftand the piston, identical to the mechanism that was modeled with Modeler2D in Section 1.2. Even though itis simply a planar mechanism, the slider-crank is modeled with Modeler3D to demonstrate the parallelismbetween Modeler2D and Modeler3D.

1.3.1 Mechanism Function

The Modeler3D package must be loaded before calling any Modeler3D functions.


This loads the Modeler3D package.

In[1]:= Needs@"MechanicalSystems`Modeler3D "̀DHere is a graphic of the 3D slider-crank model.

The following example analyzes the motion of a classic slider-crank mechanism. This mechanism is modeledwith a simple and intuitive set of mechanical constraints that are representative of how such a problemwould 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 choiceof each body number is arbitrary except for the ground body, which must be body 1. These body numbersare used throughout a Mech model to reference each body. The ground body, which is stationary by defini-tion, is used as the reference location and orientation for the rest of the model. All mechanism models musthave some reference to the ground body to be adequately constrained.


To aid in the readability of the mechanism models created with Mech, it is customary to name each of thebodies in a mechanism, and then define each of these names to be equal to the integer body number of thebody. 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 andthe piston. However, in the kinematic model this entire part can be replaced by a simple distance constraintspecifying that the crank pin and the piston pin are to be a constant distance apart. This technique decreasesthe 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 thiscoordinate system on the body is up to the user and is based on the needs of the model. It is not necessary toplace the local coordinate origin at the center of gravity of the body. The local coordinate system of eachbody is used to define points, lines, planes, and other features on the body that are then tied together tomake 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.


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}.

P1

P2P3

P4

P5

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.


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

P2P3

Piston

The local coordinate system on the piston originates at a point that is four units below the attachment pointof the connecting rod. Thus, when the slider-crank mechanism is in its initial configuration, the local originof 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}.

P1

P2

P3


1.3.3 3D Constraints

Now that the local point coordinates on each 3D body are defined, building the model is simply a matter oftying the points together with the correct mechanical constraints. Modeler3D provides a library of mechanicalconstraint objects that translate the desired physical conditions that are imposed on the model into mathemat-ical equations.

Constraint Objects

Five constraint objects are used to model the slider-crank mechanism, constraining a total of 12 degrees offreedom (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] constrains axis1 to be colinear with axis2.



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 numberof degrees of freedom that it constrains.

The first argument to each constraint object, cnum, is the user-specified constraint number. This number isused to reference the constraint later in the modeling process, just as body numbers are used to referencespecific 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 graph-ics primitives, Point and Line. These objects are discussed in detail in Section 2.2.


Building the Model

The Modeler3D constraint objects used to model the physical relationships in the slider-crank model are asfollows.

• 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 con-straint 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 con-straint 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.


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

1.3.4 Running the Model

A single command is used to solve the constraint equations and return the coordinates of each of the bodiesthe 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 specifythe location of the origin of body 2, the crankshaft.

Eo2, Ei2, Ej2, and Ek2 are the Euler generalized parameters specifying the angular orientation of thecrankshaft. SolveMech returns a {Xn, Yn, Zn, Eon, Ein, Ejn, Ekn} set for each body in the system. Forthose unfamiliar with Euler parameters, suffice it to say that the four Euler parameters provide a numeri-cally robust means of specifying the three degrees of freedom of the angular orientation of a body in 3Dspace. Values of {1, 0, 0, 0} for the four parameters, respectively, correspond to alignment with the globalcoordinate system. It is not necessary to have an understanding of the Euler parameters to utilize Modeler3Dbecause postprocessing functions use the Euler parameters to generate more familiar output, such as therotation of a body about an axis or the angle between two vectors. Euler parameters are discussed further inChapter 4.


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 eachbody to be aligned with the global coordinate system. This is because the model was defined such as to havethis perfect assembled configuration. The piston is defined such that its local origin lies at a point that isoutside of the piston body. This point is coincident with the global origin when crankangle = 0. Note the3-4-5 triangle formed by the crankshaft, piston, and connecting rod when crankangle = 0.

Advancing crankangle results in a more interesting solution.



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 coordinateof the piston Y3 has increased to 2.13. All of the other coordinates have not changed, and never will, becauseof the specific function of this particular mechanism model.




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. Through-out this chapter the simplest and most commonly used forms of each MechanicalSystems command arepresented. 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 Mechanical-Systems often uses the same name for an option and for the name of a function that performs a servicerelated to the option. For example, PointList is the name of an option that is used to set the values of localpoint 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 mechanismbody. It is not necessary to use body objects in Mech kinematic models, as demonstrated in Sections 1.2 and1.3, but the use of body objects allows points to be defined once, inside the body object, and then to bereferenced throughout the Mech model. This can reduce the likelihood of error due to changing the defini-tion 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 ina mechanism model.

Body[bnum, options] returns a SysBody data object that contains properties of

body bnum (a positive integer). Each property of the body isspecified with an option.

A function to define body objects.

Body accepts three options for defining inertia properties of a body: Mass, Inertia, and Centroid. Theseoptions will be discussed further in Section 8.1. The options for Body that are relevant in the kinematicphase of analysis are the PointList and InitialGuess options.

2D

PointList → {{x1, y1}, ..., {xn, yn}}

specifies the local coordinates of n points on the body. The

points are referenced by their local point number n.

InitialGuess → {{X, Y}, Q} 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}}

specifies the local coordinates of n points on the body. The

points are referenced by their local point number n.

InitialGuess → {{X, Y, Z}, {Eo, Ei, Ej, Ek}}

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.


2D/3D

PointList → Automatic leaves the existing points on the body unchanged.

InitialGuess → Automatic 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 returnedbody 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 initialguesses are used the first time that a solution is sought with SolveMech. Each subsequent solution attemptuses the previous solution as its initial guess. When the initial guesses are set with SetGuess, they may beexplicitly set to user-specified values, or reset to the stored values of the permanent initial guesses.

Example


In[1]:= Needs@"MechanicalSystems`Modeler2D "̀DThe 2D example mechanism of Section 1.2 can be modified to use three body objects instead of repeatedlycalling out the several local point coordinates on the ground, crankshaft, and piston bodies. These bodyobjects store the local point definitions for future reference, through their integer point numbers, by otherMech functions.

Chapter 2: Kinematic Modeling 27

Here are the crankshaft-piston mechanism bodies.

-4 -2 0 2 4 6

-5

-2.5

0

2.5

5

7.5

10

{0,0}

P1

{0,4}

P2

{0,9}

P3

-4 -2 0 2 4 6

-5

-2.5

0

2.5

5

7.5

10

{0,0}

P1

{3,0}

P2

-4 -2 0 2 4 6

-5

-2.5

0

2.5

5

7.5

10

{0,4}

P1

{0,6}

P2

• 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.

This defines a body object for the piston.

In[6]:= piston = 3;bd@3D = Body@piston,

PointList → 880., 4.

If SetBodies is passed a body object with an InitialGuess specification other than Automatic, thecurrent 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 SetBodies is run with a new InitialGuess specification, the changed guess is immediately reflected in Mech’sinternal database. The same holds true for changing inertia properties with SetBodies; the mass matrix isimmediately updated.

However, changing the coordinates of a point with PointList must reflect a change throughout theconstraint equations defined with SetConstraints. This cannot be done without rebuilding the constraintequations. Therefore, if the constraint equations have already been built with SetConstraints whenSetBodies is passed a PointList specification other than Automatic, the constraint equations will all beautomatically rebuilt by SetConstraints the next time that a solution is sought, which may cause anoticeable delay in the operation of SolveMech.

The following command incorporates the three body objects that were defined in Section 2.1.1 into thecurrent model.

This starts a model with the three body objects.

In[10]:= SetBodies@bd@1D, bd@2D, bd@3DDSetBodies returns Null. All of the mechanism points and properties passed to SetBodies are stored inMech’s internal database.

Now that local point definitions have been added to the current model, they can be referenced by their localpoint numbers in any Mech function. Instead of using the local coordinates of a point, simply use the integerpoint number. For example, the Translate2 constraint in the crankshaft-piston model would use fourlocal 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, 2, 3D,Line@piston, 1, 2DD;

Translate2@3,Line@ground, 80, 4

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 propertiesalready defined.

This updates only the crankshaft’s initial guess.

In[13]:= SetBodies@Body@crank, InitialGuess → 881, 1

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 2Dor 3D point in global coordinates or in local coordinates on a specified body. Point objects may be given as2D 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} references a point with the specified global coordinates.

Methods of defining 2D point objects.


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 refer-enced through either its global coordinates, its local coordinates, or its local coordinate number. The follow-ing example shows several point objects that are functionally identical.


In[1]:= Needs@"MechanicalSystems`Modeler2D "̀DLocal points are defined on the ground body.

In[2]:= ground = 1;SetBodies@Body@ground, PointList → 880, 0

2.2.2 Vectors

The basic geometric entity specifying direction is the vector object. Vector objects reference the direction of a2D or 3D vector, in global coordinates or in local coordinates on a specified body. Vector objects may begiven as 2D or 3D vectors in global coordinates, or they may have the head Vector and be given in localcoordinates 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 direc-tion of the vector. A Plane (3D only) may also be used to specify a vector object, in which case the normaldirection of the Plane is used as the direction of the vector. See the following two subsections for furtherinformation 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 andmagnitude.

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.


Assuming that the appropriate body object definition has been made, any vector on any body can be refer-enced through either its global coordinates, its local coordinates, or its local point number. The followingexample 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

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 lpnt1on body bnum1 to local point lpnt2 on body bnum2.

Methods of defining 3D line objects.


Assuming that the appropriate body object definition has been made, any line spanning bodies or on asingle body can be referenced with a combination of global points, local points, or local point numbers. Thefollowing 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

Because a Plane object possesses the properties of direction and location, it can be used in place of a vectorobject or an axis object in any Mech function that calls for a vector or an axis. If a Plane object is used tospecify 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 Mechpoint 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, orthree bodies can be referenced with a combination of global points, local points, or local point numbers. Thefollowing example shows several plane objects that are functionally identical.



In[18]:= Needs@"MechanicalSystems`Modeler3D "̀DLocal points are defined on the two bodies.

In[19]:= ground = 1; crank = 2;SetBodies@Body@ground, PointList → 880, 0, 0

An axis object may have the head Axis, Line, or Plane. If a Line is used to specify an axis object, theorigin and direction of the Line are used as the origin and direction of the axis. Because a Line object hasno specific reference direction, a Line should not be used in place of a Modeler3D axis object in a functionwhere 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, thenormal direction of the Plane is used as the direction of the axis, and the line from point1 to point2 on thePlane 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 andhaving a direction vector equal to the coordinates of lpnt2

on body bnum2.

Methods of defining 2D axis objects.


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 oflpnt2 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 lpnt2on 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 directionspecified with coordinates on a single body or multiple bodies can be referenced with a combination ofglobal points, local points, or local point numbers. The following example shows several axis objects that arefunctionally identical.


In[26]:= Needs@"MechanicalSystems`Modeler2D "̀D


Local points are defined on the two bodies.

In[27]:= ground = 1;crank = 2;SetBodies@Body@ground, PointList → 880, 0

2.3 Constraint Objects

Constraint objects are used to define the mathematical relationships that make up the kinematic model interms of the physical relationships of the various mechanism bodies. All Mech constraint functions returnconstraint objects with the head SysCon. These constraint objects are passed to the SetConstraintsfunction 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 Constraint. 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 andconstrains 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 onmechanism bodies. Elementary relationships are used for the majority of simple mechanical joints. A shaftspinning in a bearing is modeled by specifying that two points are coincident. A connecting rod can bemodeled by specifying a constant distance between two points. A guide pin in a slot is modeled by specify-ing that a point on one body lies on a line on another body. A piston in a cylinder is modeled by specifyingthat two lines on two different bodies are colinear.


Many seemingly different mechanical joints are often modeled with the same constraint, such as a connect-ing rod versus a guide pin in a circular track; both are modeled by specifying the distance between twopoints on two different bodies. It is up to the user to determine the true nature of the kinematic relationshipsthat 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 thatis similar in form to the actual mechanical joint being modeled. Thus, the readability of the model can beimproved.

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]

constrains point1 to lie dist units away from point2, measured in the direction of vector.



Point-on-line constraints force a point on a body to travel along a specified line.


Revolute2[cnum, point1, point2] constrains point1 to be coincident with point2.

DirectedPosition2[cnum,

point1, point2, vector]

constrains the location of point1 to be equal to the location of

point2 plus vector.

PointOnLines2[cnum, point, axis1, axis2]

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] constrains vector1 to be parallel to vector2.



RelativeAngle1[cnum, vector1, vector2, ang]

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 inChapter 6.

To demonstrate the ambiguity in determining which constraint is the correct constraint, the set of fourconstraints used in the crankshaft-piston model are examined. The first constraint, Revolute2, could bemodeled with a pair of constraints with one degree of freedom each; a RelativeX1 to control the X coordi-nate of the crankshaft axis, and a RelativeY1 to control the Y coordinate.




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

2.3.3 3D Basic Constraints

The Modeler3D basic constraints specify elementary geometric relationships between points, lines, andplanes on mechanism bodies. Elementary relationships are used for the majority of mechanical joints. Ashaft spinning in a bearing is modeled by specifying that two axes are coincident. A connecting rod can bemodeled by specifying a constant distance between two points. A guide pin in a slot is modeled by specify-ing that a point on one body lies on a line on another body. A piston in a cylinder is modeled by specifyingthat two lines on two different bodies are colinear.

Many seemingly different mechanical joints are often modeled with the same constraint, such as a connect-ing rod versus a guide pin in a circular track; both are modeled by specifying the distance between twopoints on two different bodies. It is up to the user to determine the true nature of the kinematic relationshipsthat 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 issimilar in form to the actual mechanical joint being modeled. Thus, the readability of the model is improved.

OriginLock3[cnum, bnum, {x, y, z}]

locates the origin of body bnum at the global coordinates {x, y, z}.

RotationLock3[cnum, bnum, {ang, {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.


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 bythe 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]

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]

constrains point to lie rad units distant from axis.

PointOnCone1[cnum, point, axis, ang]

constrains point to lie on the surface of a cone revolved

about axis with half angle ang. The vertex of the cone lies atthe 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

about axis. The center of the circle lies at the origin of axis.

PointOnPlanes2[cnum, point, axis1, axis2]

constrains point to lie on the intersection of two planes. The

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.


Spherical3[cnum, point1, point2] constrains point1 to be coincident with point2.

DirectedPosition3[cnum,

point1, point2, vector]

constrains the location of point1 to be equal to the location of

point2 plus vector.

PointAtIntersection3[cnum, point, axis1, axis2]

constrains point to lie at the intersection of axis1 and a planethat is specified by axis2.

Point-at-position constraints control the position of a point.



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 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] constrains the two vectors to be parallel in 3D space.

Parallel constraint enforces parallelism between two vectors.


LineToLine1[cnum, axis1, axis2, dist]

constrains the perpendicular distance between the two axes

to be equal to dist.

LineToCircle1[cnum, axis1, axis2, rad]

constrains axis1 to pass through the perimeter of a circle of

radius rad, with the axis of the circle specified by axis2.

PlaneToCircle1[cnum, axis1,

axis2, rad]

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]

constrains axis1 to lie dist units away from, and parallel to, a

plane specified by axis2.

LineOnCylinder3[cnum, axis1, axis2, dist]

constrains the two axes to be parallel and dist units apart.

PlaneToPlane3[cnum, axis1, axis2, dist]

constrains two planes to be parallel and dist units apart. Theplanes are specified by their normals with axis1 and axis2,

which may be Plane objects.

Constraints that enforce more complex geometric relationships.


Cylindrical4[cnum, axis1, axis2] 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 twoaxes 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 inChapter 6.

To demonstrate the ambiguity in determining which constraint is the correct constraint, the set of five con-straints used in the crankshaft-piston model are reexamined. The first constraint, a Revolute5, could bemodeled 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.




Here is the original Revolute5 constraint.

In[12]:= ground = 1;crank = 2;piston = 3;Revolute5@1,Line@ground, 80, 0, 0

This constraint has no functional equivalent.

In[21]:= RelativeDistance1@4,Point@crank, 83, 0, 0

2.4.1 SetConstraints

SetConstraints is Mech’s core model building function. SetConstraints takes constraint objects thatrepresent the physical interactions in the mechanism model and processes them into a system of kinematicequations.

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 inthe current model, otherwise it leaves the guesses

unchanged.

SetGuess → False is the default setting.

An option for SetConstraints.


2.4.2 Constraints

The actual constraint expressions that are generated by SetConstraints can be extracted with Constraints. Constraints can be very useful for debugging a model because it is often possible to read theconstraint 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.


In[1]:= Needs@"MechanicalSystems`Modeler2D "̀DConsider the 2D crankshaft-piston model of Section 1.2. This model is built with various settings for theoptions for SetConstraints to show their affect on the resulting equations.


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 expression, 10 Sin[Θ3], constrains the rotation of the piston; this expression can be equal to zeroif Θ3 is any integer multiple of p. The reason that the solution Θ3 Ø 0 is found is because the default initialguess 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 anyvalue of Θ3 that satisfies the first expression, the second expression reduces to 2 X3 or −2 X3, either ofwhich 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 amodel’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 toreset 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.


LastSolve[] returns the values for the dependent variables that will be

used as the next set of initial guesses. The value returned byLastSolve[] 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 initialguess than the current one. For example, to turn the crankshaft 3/4 of a turn at once, it might be necessary toset 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

This shows the current guesses.

In[20]:= LastSolve@DOut[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 generatedby SetConstraints as they are created. The default setting, $MechProcessFunction = Chop, canreduce the size of the constraint expressions substantially if any of the constraints involve the local origins ofbodies in the model which have local coordinates of 80, 0< or 80, 0, 0

2.4.5 SetSymbols

The default symbols that appear in the solution rules returned by SolveMech can be changed with theSetSymbols function.

SetSymbols[options] sets the basis for the symbols that are created by Mech.

SymbolBasis 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"}, {"Ei", "Ej"}, "Θ", "Λ", "d"}

is the default setting for SymbolBasis in Modeler2D.

SymbolBasis Ø {"T", {"X", "Y",

"Z"}, {"Eo", "Ei", "Ej", "Ek"}, {"Ωx", "Ωy", "Ωz"}, "Λ", "d"}

is the default setting for SymbolBasis in Modeler3D.

Default settings.

Because SetSymbols changes the behavior of all Mech functions that return symbolic expressions, SetSymbols must be run before building any other part of the mechanism model with SetBodies or SetConstraints. SetSymbols has the effect of executing ClearMech[].

The Ωx, Ωy, and Ωz symbols are used by Modeler3D to represent angular velocities used in 3D velocityanalysis, which is discussed in Chapter 4. The Λ symbol is a Lagrange multiplier used in static and dynamicanalysis, which is discussed in Chapter 7. The d symbol is used in 2D and 3D velocity analysis to symboli-cally represent differentiation.

If the current model is rebuilt with a new setting for SymbolBasis, the solution rules returned by SolveMech are changed accordingly.

This causes new symbols to be used in all subsequent models.

In[24]:= SetSymbols@SymbolBasis → 8"Tm", 8"Xcoord", "Ycoord"

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]:= [email protected] Running the Model

This section covers the use of the SolveMech command, which is used to seek a solution to the mechanismmodel. The Mech commands covered in the previous sections were all concerned with building a mechanismmodel. 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 themodel at which all of the constraints are satisfied.

SolveMech[] seeks a solution to the current mechanism model.

Mech’s runtime command.


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 tech-nique that must be used in the velocity and acceleration portions of the analysis. It is not necessary to haveany dependency on T in a model used only for location analysis, but it is customary to make the primarydriving 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 arange 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 specifiedvalues 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 minusn 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 exam-ple 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.




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.

This seeks 6 solution points, including T = 0.223

In[8]:= First ê@ SolveMech@80, .223, .3

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] shouldreturn 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 theexecution of SolveMech. Note that all Mech system variables that can be set by the user have names of theform "$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, orto print the value of time that SolveMech is currently

working on. The default definition is $MechPreSolve =.

Controls for SolveMech.


Failure to Converge

The default setting for ZeroTest will suffice for many models, but may need to be changed for severalreasons.

If the numerical size of the dimensions of the model are very large or small, ZeroTest may need to bechanged accordingly. For example, if a typical point in the model is Point[2, {3400, -7800}], it mightbe 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 eachiteration 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 validsolution that is apparently correct, but an error message is generated claiming that convergence has failedafter n iterations. If the model fails to converge and returns a solution that is obviously not valid, try to findan 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 equationsolver, similar to the built-in Mathematica function FindRoot. In fact, Mech can be used to solve arbitrarysystems 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 alge-braic equation. The algebraic constraint can be incorporated into a mechanism model along with othergeometric 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 const

kinematic a nd d ynamic analy sis in mathematicamedia.wolfram.com/documents/mechanicalsystems... ·...

Documents