Geometric Constraint Programming (GCP) Implemented Through GeoGebra to Study/Design Planar Linkages

Abstract

In the study and design of planar mechanisms, graphical techniques for solving kinematic analysis/synthesis and kinetostatics problems have regained interest due to the availability of advanced drawing tools (e.g., CAD software). These techniques offer a deeper physical understanding of a mechanism’s behavior, which can enhance a designer’s intuition and help students develop their skills. Geometric Constraint Programming (GCP) is the term used to describe this modern approach to implementing these techniques. GeoGebra is an open-source platform designed for the interactive learning and teaching of mathematics and related STEM disciplines. It offers an object-oriented programming language and a wide range of geometric tools that can be leveraged to implement GCP. This work presents a systematic technique for studying and designing planar linkages, based on Assur’s groups and GeoGebra’s tools. Although some kinematic analyses and syntheses of planar linkages using GeoGebra have been previously introduced, the proposed systematic approach is novel and could serve as a guide for implementing similar problem-solving methods in other graphical environments. Several case studies will be presented to illustrate this novel approach in detail.

1. Introduction

Graphical techniques [1] were the primary tools used for kinematic analysis and synthesis of planar mechanisms until about the mid-twentieth century [2], when the first kinematic synthesis programs for digital computers appeared [3]. From then on, many software packages for the kinematic analysis and synthesis of planar linkages were developed during the second half of the twentieth century. Such programs moved the central interest of researchers from graphical to numerical techniques. Unfortunately, even though numerical techniques fully exploited the power of digital computers, they were less prone than graphical ones to guide the intuition of students and designers toward a full understanding of the practicable solutions of kinematic problems.

In the meantime, solid-modeling software packages enhanced both their user interfaces and their integrated numerical solvers. These tools, together with the greatly increased computational speeds of digital computers, created advanced drafting platforms where the parametric programming of linkage sketches [1] made implementing graphical techniques for solving kinematic problems easy and fast through trial-and-error procedures. In these software packages, imposing geometric conditions (e.g., coincidence, parallelism, etc.) on points and lines does not require any computation, and redrawing the whole sketch, after the value of a parameter changes, is automatic and fast.

The evolution of solid-modeling software packages led, in the first decade of the twenty-first century, to the rediscovery of graphical techniques as central tools for solving kinematics and kinetostatics problems. In 2006, Kinzel et al. [4] referred to the implementation of graphical techniques for solving kinematic synthesis problems using the sketchers of CAD software as ‘Geometric Constraint Programming’ (GCP). Since then, a body of literature [5,6,7,8,9,10,11,12,13,14,15] has emerged, focusing on GCP-based solution methods for both classical and novel kinematic synthesis problems.

By extension, the term GCP can be used to indicate the implementation of any graphical technique related to kinematic or kinetostatic problems using any advanced graphical platform [1,16,17]. GeoGebra (geogebra.org (accessed on 31 October 2024)) [18] is an open-source environment designed for interactively learning and teaching mathematics and related STEM disciplines. It features an object-oriented programming language and a wide array of geometric tools, which can be used for implementing GCP.

In the context of planar mechanism sketches, GeoGebra allows users to insert geometric objects (e.g., points, lines, vectors, etc.) containing variable parameters and then generate additional objects through geometric operations (e.g., intersection of curves, etc.) on the inserted objects. These features are sufficient to build and animate mechanism sketches where the variable parameters allow both the definition of motion inputs (i.e., actuated-joint variables) and the mechanism geometry changes needed for matching design requirements.

Moreover, by defining geometric constraints (e.g., parallelism/perpendicularity between a line and a vector, etc.) among the objects, GeoGebra allows for drawing vector diagrams, tied to the mechanism sketch, which dynamically vary during the mechanism animation or because of a geometric constant change. Such a property is sufficient to draw velocity/acceleration vector diagrams corresponding to the velocity/acceleration loop equations of the mechanism and static-equilibrium vector diagrams of the forces applied to the mechanism’s links. On this point, it is worth noting that sketchers of CAD software are not able to insert vectors [2], which makes building vector diagrams much more difficult/uncertain in those platforms than it is in GeoGebra.

Eventually, GeoGebra contains a long list of predefined functions and algebraic operators that are usable to state (even cumbersome) math relationships among geometric parameters (i.e., analytic constraints).

Drawing a mechanism’s sketch is the prerequisite for implementing, manually or through GCP, any graphical technique. Such an operation involves the translation of the kinematic constraints into geometric relationships among relevant points/lines/segments used to build the sketch. From a conceptual point of view, once the sketch is completed, the position analysis of the mechanism is graphically solved at a particular configuration of the mechanism. Therefore, formulating the position analysis solution as a sequence of geometric operations to implement is the central task to address using either traditional drafting tools or any advanced graphical platform.

The decomposition of a planar linkage into Assur groups [19,20,21,22] is a technique proposed in the literature for transforming the position analysis solution of planar linkages into a sequence of modular operations [23,24,25,26,27,28]. An Assur group is a kinematic chain with zero mobility that does not contain any smaller zero-mobility kinematic chain. Artobolevskii [21] stated that any linkage is obtainable by connecting a number of Assur groups.

The position analysis solution through linkage decomposition starts from the data of the frame and of the input links (driving links), whose poses (positions and orientations) are known. Successively, it solves the position analysis of the Assur groups adjacent to the driving links, and it continues by solving the position analysis of the Assur groups adjacent to the already-solved part of the linkage until covering the whole linkage. It is applicable and has advantages when the solution algorithms of the smaller modules (i.e., the Assur groups) are known and simpler than the solution of the whole linkage. This is true for the Assur groups named dyads (Figure 1), which feature two binary links (links i and j in Figure 1) connected through single-degree-of-freedom (DOF) lower kinematic pairs (i.e., either a revolute (R) pair or a prismatic (P) pair) both to one another at one end and to the remaining part of the linkage at the other end. A large family of planar linkages, which contains the most common and studied ones, are decomposable by using only dyads over driving links and frame.

This paper addresses the kinematic analysis/synthesis and kinetostatic analysis of this family of linkages using GeoGebra. In particular, firstly, how dyads’ kinematic analysis is solvable by using purely geometric conditions, which are easy to implement through GeoGebra, is shown. Secondly, how such geometric solutions allow building parametric sketches of linkages, which can also be animated, and the associated vector diagrams necessary to study/design the linkage from kinematic and kinetostatic points of view, is also addressed. Eventually, a number of case studies is presented to better illustrate the novel GCP methodology. Even though the kinematic analyses/syntheses of some planar linkages with GeoGebra have already been presented, the proposed systematic approach is novel and could guide the implementation of the solutions of the same problems even in other graphical environments. The results of these works are useful both to mechanism designers and to conceiving a novel teaching methodology for higher education courses.

The paper is organized as follows. Section 2 presents the methodology together with some background materials. Section 3 illustrates a number of relevant case studies. Successively, Section 4 discusses the obtained results and Section 5 draws the conclusions.

2. Materials and Methods

In GeoGebra (see [18] and the options “Manual” or “Tutorial” of the “Help & Feedback” menu of https://www.geogebra.org/classic (accessed on 31 October 2024)), geometric object and geometric operations can be introduced either by typing commands in the “Algebra” menu or by choosing on a graphic menu, named “Tools”, the specific object (e.g., point or line symbols) or operation, and, then, clicking, with the mouse, on the position of the Cartesian plane window where the object/operation must be located/executed. Here, for the sake of clarity, the procedures are illustrated through the commands of the “Algebra” menu. The use of the graphic menu “Tools” is intuitive, and the reader can autonomously master it after having understood the commands of the “Algebra” menu.

Also, in GeoGebra, scalar parameters are introducible by typing the command “SliderName = Slider(minimum value, maximum value, increment)” or, simply, “SliderName”. They are, by definition, variable and are usable for animating the drawing (i.e., as joint variable) or for changing the geometry of the introduced objects (i.e., as a design parameter to adjust according to the design requirements).

Eventually, in the Cartesian plane window of GeoGebra, by right-clicking on an already-introduced geometric object, a submenu appears where the option “Show Trace” can be chosen to provide the trace of the object during the animation (e.g., the path of a point of a link during the link motion). In the same submenu, by choosing the option “Settings”, another window appears on the right where all the properties of the object can be modified. In this window, by deselecting the option “Show Object”, the object remains defined, but it is not shown in the Cartesian plane window. Such a choice is useful, when a linkage has multiple assembly modes, to hide all the assembly modes the user is not interested in.

2.1. Building the Linkage and Generating Its Motion

The planar linkages of the family under study contain only dyads, driving links and the frame.

In GeoGebra, modeling the frame corresponds to the introduction of the geometric objects that define the joints connecting the links to the frame. Such joints are either R-pairs or P-pairs. Consequently, for R-pairs, the coordinates of the R-pair centers must be introduced through the command “PointName = Point({x,y})” or, simply, “PointName = (x,y)”, where x and y can be either numeric values or names of scalar parameters. For P-pairs, the lines parallel to the P-pair sliding directions, chosen as joint axis, must be introduced through the command “LineName = Line(<Point>, <Point>)” or “LineName = Line(<Point>, <Direction>)”, where the points belong to the joint axis and the direction is assigned by means of a vector or a line/segment parallel to the joint axis. Since the frame is at rest, all these points and lines have null velocity and acceleration during the linkage animation, even though their position can be modified by using the scalar parameters that have been introduced during the object definitions.

Differently, the introduction of dyads and driving links can be achieved through the short command lists presented below.

2.1.1. Dyads

Considering all the possible combinations of R- and P-pairs in a dyad brings one to the conclusion that there are only five types of dyads (Figure 1): (a) RRR, (b) RRP, (c) RPR, (d) PRP, and (e) RPP. From a kinematic point of view, each type of dyad is considerable as a module whose inputs and outputs are the kinematic data of the two free endings (i.e., the green elements in Figure 1) and of the intermediate joint between the two links (i.e., the black joint in Figure 1), respectively. For an R-pair, such data refer to the position, velocity and acceleration of the R-pair center, whereas, for a P-pair, they are pose, velocity characteristics (e.g., a given point velocity and the angular velocity) and the acceleration characteristics (e.g., a given point acceleration and the angular acceleration) of the line parallel to the P-pair slider direction that has been chosen as the joint axis. The analytic relationships that express the kinematic data outputs as functions of the kinematic data inputs are known and used in analytical/numerical modular solution algorithms for planar linkages (see [16], for instance). Reinterpreting such relationships in term of geometric conditions easy to implement in GeoGebra is feasible, as follows. In the zipped file “GGB files.zip” uploaded as “Supplementary Materials”, the folder “Dyads” contains the GeoGebra files (extension ggb) with the GeoGebra programs that build the five types of dyads together with their velocity/acceleration vector diagrams. In Appendix A, these GeoGebra programs are reported together with comments that explain what each command line generates in the Cartesian plane window of GeoGebra.

2.1.1.a. RRR Dyad

For RRR dyads, with reference to Figure 1a, the data inputs are the coordinates of the R-pair centers at the free endings, that is, points A and B, and the link lengths, that is, r_c and r_d, whereas the data outputs are the coordinates of the center of the intermediate R-pair, that is, point C.

Since point C must keep a constant distance r_c (r_d) from A (from B) during motion, point C must be located at one of the two possible intersections of two circumferences (c and d in Figure 1a), one centered at A with radius r_c and the other centered at B with radius r_d. Accordingly, the list of GeoGebra commands that implement this geometric condition is reported in Appendix A. Such a GeoGebra program generates in the Cartesian plane window of GeoGebra the RRR dynamic sketch of Figure 1a, where the style properties (colors of lines and points, etc.) of the introduced objects have been modified by selecting the object and clicking on “Settings”, as explained above.

In this draft, the dyad configuration is modifiable by clicking on one free ending A or B and moving the mouse. Also, the dyad geometry is modifiable through the defined “Sliders” r_c and r_d. When an RRR dyad is added to an already-built linkage, points A and B are already defined as linkage points, and the first two commands of the above cited list must be omitted.

2.1.1.b. RRP Dyad

For RRP dyads, with reference to Figure 1b, the data inputs are the coordinates of the R-pair center at the left free ending, that is, point A; the pose data of the P-pair joint axis at the right free ending, that is, line f; the length of link i, that is, r_c, and the distance from line f of the center of the intermediate R-pair, that is, d_gf. The data outputs are the coordinates of the center of the intermediate R-pair, that is, point C.

Since point C must keep a constant distance r_c (d_gf) from point A (from line f) during motion, point C must be located at one of the two possible intersections between the circumference (c in Figure 1b) centered at A with radius r_c and a line (line g in Figure 1b) parallel to the P-pair joint axis and distant d_gf from it. Accordingly, the list of GeoGebra commands that implement this geometric condition is reported in Appendix A. Such a GeoGebra program generates in the Cartesian plane window of GeoGebra the RRP dynamic sketch of Figure 1b, where the style properties (colors of lines and points, etc.) of the introduced objects have been modified by selecting the object and clicking on “Settings”, as explained above.

In this draft, the dyad configuration is modifiable by clicking on one free ending A or D and moving the mouse, and by acting on the defined “Slider” θ to change the slope of line f. Also, the dyad geometry is modifiable through the defined “Sliders” r_c and d_gf. When an RRP dyad is added to an already built linkage, point A and line f are already defined as linkage parts and the first three commands of the above-cited list must be omitted.

2.1.1.c. RPR Dyad

For RPR dyads, with reference to Figure 1c, the data inputs are the coordinates of the R-pair centers at the free endings, that is, points A and B, and their distances from the P-pair joint axis, that is, d_Ak and d_Bk, whereas the data outputs are the pose of P-pair joint axis, line k, and the position on this axis of the P-pair’s slider (i.e., of point C).

Since line k must keep at a constant distance d_Ak (d_Bk) from A (from B) during motion, line k must be always tangential to two circumferences (c and d in Figure 1c), one centered at A with radius d_Ak and the other centered at B with radius d_Bk. Once the pose of line k is determined, the pose of the P-pair slider immediately comes out from the geometry of the two links i and j. Accordingly, the list of GeoGebra commands that implement this geometric condition is reported in Appendix A. Such a GeoGebra program generates in the Cartesian plane window of GeoGebra the RPR dynamic sketch of Figure 1c, where the style properties (colors of lines and points, etc.) of the introduced objects have been modified by selecting the object and clicking on “Settings”, as explained above.

In this draft, the dyad configuration is modifiable by clicking on one free ending A or B and moving the mouse. Also, the dyad geometry is modifiable through the defined “Sliders” d_Ak, d_Bk, x_k, and y_k. When an RPR dyad is added to an already built linkage, points A and B are already defined as linkage points, and the first two commands of the above-cited list must be omitted.

2.1.1.d PRP Dyad

For PRP dyads, with reference to Figure 1d, the data inputs are the pose data of the two P-pair joint axes at the free endings, that is, lines c and f, and the distance from line c (line f) of the center of the intermediate R-pair, that is, d_cn (d_gf). The data outputs are the coordinates of the center of the intermediate R-pair, that is, point C.

Since point C must keep a constant distance d_cn (d_gf) from line c (from line f) during motion, point C must be located at the intersection between two lines, one (line n in Figure 1d) parallel to line c and distant d_cn from it and the other (line g in Figure 1d) parallel to line f and distant d_gf from it. Accordingly, the list of GeoGebra commands that implement this geometric condition is reported in Appendix A. Such a GeoGebra program generates in the Cartesian plane window of GeoGebra the PRP dynamic sketch of Figure 1d, where the style properties (colors of lines and points, etc.) of the introduced objects have been modified by selecting the object and clicking on “Settings”, as explained above.

In this draft, the dyad configuration is modifiable by clicking on one free ending E or D and moving the mouse, and by acting on the defined “Slider” θ (φ) to change the slope of line f (line c). Also, the dyad geometry is modifiable through the defined “Sliders” d_cn and d_gf. When a PRP dyad is added to an already built linkage, lines c and f are already defined as linkage parts, and the first four commands of the above-cited list must be omitted.

2.1.1.e. RPP Dyad

For RPP dyads, with reference to Figure 1e, the data inputs are the coordinates of the R-pair center at the left free ending, that is, point A; the pose data of the P-pair joint axis at the right free ending, that is, line f; the distance, d_Am, from A of the joint axis (line m in Figure 1e) of the intermediate P-pair and the angle, δ, that the same joint axis forms with line f. The data outputs are the pose data of the joint axis of the intermediate P-pair, that is, line m, and the positions of the two P-pair sliders on lines f and m.

During motion, line m must keep a constant distance, d_Am, from point A, that is, it must be tangential to a circle (circle c in Figure 1e) centered at A with radius d_Am, because of the R-pair; and it must keep a constant slope angle, δ, with respect to line f, since lines f and m are both fixed to link j. Accordingly, the list of GeoGebra commands that implement this geometric condition is reported in Appendix A. Such a GeoGebra program generates in the Cartesian plane window of GeoGebra the RPP dynamic sketch of Figure 1e, where the style properties (colors of lines and points, etc.) of the introduced objects have been modified by selecting the object and clicking on “Settings”, as explained above.

In this draft, the dyad configuration is modifiable by clicking on one free ending A or D and moving the mouse, and by acting on the defined “Slider” θ to change the slope of line f. Also, the dyad geometry is modifiable through the defined “Sliders” d_Am and δ, whereas the links’ geometry is modifiable through the defined “Sliders” d_BF, x_j and d_j, for link j, and x_i, for link i. When an RPP dyad is added to an already-built linkage, point A and line f are already defined as linkage parts, and the first three commands of the above-cited list must be omitted.

2.1.2. Driving Links

The driving link (link j in Figure 2) is a binary link that at one ending is connected to a link (link i in Figure 2) of the linkage, whose motion is known, through either an actuated R-pair (Figure 2a) or an actuated P-pair (Figure 2b), and at the other ending (free ending) through a non-actuated joint. These two cases can be modeled in GeoGebra as follows. In the zipped file “GGB files.zip” uploaded as “Supplementary Material”, the folder “Driving Link” contains the GeoGebra files (extension ggb) with the GeoGebra programs that build the two types of driving links. In Appendix B, these GeoGebra programs are reported together with comments that explain what each command line generates in the Cartesian plane window of GeoGebra.

2.1.2.a. Driving Link with Actuated R-pair

For a driving link with actuated R-pair (see Figure 2a), the input data are the value of the actuated-joint variable, that is, the angle θ_ji, and the positions of points A and P of link i, whereas the output data are the coordinates of point B, that is, of the free ending of link j. Moreover, the length, say r, of the segment AB is a geometric parameter of link j. Accordingly, the list of GeoGebra commands that generates point B and link j as functions of the data input is reported in Appendix B.

The parametric draft of Figure 2a was generated in GeoGebra through the above-cited command list followed by the adjustment of the style properties (colors of lines and points, etc.) of the introduced objects. When this driving link is added to an already-built linkage, points A and P and link i, together with their motion, are already defined as linkage parts, and the first three commands of the list must be omitted.

2.1.2.b. Driving Link with Actuated P-pair

For a driving link with an actuated P-pair (see Figure 2b), the input data are the value of the actuated joint variable, that is, the length of segment AC, and the positions of points A and B of link i, whereas the output data are the position of the P-pair slider, that is of point C, and the coordinates of the free ending of link j, that is, of point D. Moreover, the distance, say d, of point D from the segment AB is a geometric parameter of link j. Accordingly, the list of GeoGebra commands that generates point C and link j as functions of the data input is reported in Appendix B.

The parametric draft of Figure 2b was generated in GeoGebra through the above-cited command list followed by the adjustment of the style properties (colors of lines and points, etc.) of the introduced objects. When this driving link is added to an already-built linkage, points A and B and link i, together with their motion, are already defined as linkage parts, and the first three commands of the list must be omitted.

2.1.3. Position Analysis’ Geometric Solution

The geometric solution of the position analysis through linkage decomposition starts from the data of the frame and of the driving links adjacent to the frame, and builds them in GeoGebra through the above-described lists of commands. This is always possible since their poses (positions and orientations) and motion are known. Successively, by using the same lists of GeoGebra commands, it builds the dyads/driving links adjacent to the frame and to the already-inserted driving links, and it continues by building the dyads/driving links adjacent to the already-built part of the linkage until completing the GeoGebra sketch of the linkage.

Once the linkage sketch has been completed, all the poses of the links are known, that is, the position analysis has been geometrically solved. Also, the GeoGebra sketch can be animated by selecting “Animation on” in the properties of the “Slider()” used to define the actuated joint variables. Eventually, the geometric constants can be adjusted by selecting “Show object” in the properties of the “Slider()” used to define the geometric constants, and by clicking on the slider that appears in the Cartesian plane window and then moving the mouse. The positions of points assigned with coordinates that are parameters of the object can be moved by simply clicking on the points and then moving the mouse.

2.2. Velocity and Acceleration Analyses’ Vector Diagrams

After the linkage’s dynamic sketch has been built, the geometric solution of velocity and acceleration analyses, that is, the construction of the velocity and acceleration vector diagrams, proceeds by following the same sequence of substructure analyses used to build the linkage sketch.

Indeed, it starts from the velocity/acceleration data of the frame and of the driving links adjacent to the frame, and draws the velocity/acceleration vectors of their free endings. Successively, it uses these vectors to geometrically determine the velocity/acceleration vectors of the reference points/lines of the intermediate joint (for dyads) or of the output endings (for driving links) of the dyads/driving links adjacent to the frame and to the already solved driving links. Then, it continues by drawing velocity/acceleration vector diagrams of the dyads/driving-links adjacent to the already-solved part of the linkage until covering the whole linkage. Therefore, the modules to repeatedly implement in this methodology are velocity/acceleration analyses of frame, driving links and dyads.

Velocity/acceleration analyses are linear problems. As a consequence, the geometric determination of the output velocity/acceleration vectors involves only intersections of lines and the introduction of dependent variables related to the already-determined vectors by simple analytic formulas. Moreover, the motion input data of a linkage are the time histories of the actuated joint variables, and the frame is assumed either at rest or with known motion. Consequently, the velocity/acceleration analyses of frame and driving links are straightforward; they only involve the introduction of well-known simple analytic formulas reported in textbooks (see, for instance, [29]). For the sake of brevity, such formulas are not recalled, and the following part of this subsection is devoted to the graphical implementation in GeoGebra of the velocity/acceleration analyses of the dyads.

Hereafter, the following notations are used:

-

v_P,g (a_P,g) denotes the velocity (acceleration) of point P considered fixed to link g when measured from the frame;

-

v_PR,g (a_PR,g) denotes the velocity (acceleration) difference v_P,g − v_R,g (a_P,g − a_R,g);

-

v_P,gm (a_P,gm) denotes the velocity (acceleration) of point P considered fixed to link g when measured from link m;

-

ω_g (α_g) denotes the signed magnitude, positive if counterclockwise, of the angular velocity (acceleration) of link g when measured from the frame;

-

ω_gm (α_gm) denotes the signed magnitude, positive if counterclockwise, of the angular velocity (acceleration) of link g when measured from link m.

With these notations, the following relationships hold:

$${\mathrm{v}}_{\mathrm{PR},\mathrm{g}}={\mathrm{\omega }}_g|P-R|{\mathrm{v}}_{\mathrm{g}}; {\mathrm{a}}_{\mathrm{PR},\mathrm{g}}={\mathrm{\alpha }}_g|P-R|{\mathrm{v}}_{\mathrm{g}}-{\mathrm{\omega }}_g^2|P-R|{\mathrm{u}}_{\mathrm{g}}={\mathrm{a}}_{\mathrm{PR}\perp ,\mathrm{g}}+{\mathrm{a}}_{\mathrm{PR}\parallel ,\mathrm{g}};$$

(1a)

$${\mathrm{v}}_{\mathrm{P},\mathrm{gm}}={\mathrm{v}}_{\mathrm{P},\mathrm{g}}-{\mathrm{v}}_{\mathrm{P},\mathrm{m}}; {\mathrm{a}}_{\mathrm{P},\mathrm{gm}}={\mathrm{a}}_{\mathrm{P},\mathrm{g}}-{\mathrm{a}}_{\mathrm{P},\mathrm{m}}-2{\mathrm{\omega }}_m(\mathrm{k}\times {\mathrm{v}}_{\mathrm{P},\mathrm{gm}});$$

(1b)

$${\mathrm{\omega }}_{gm}={\mathrm{\omega }}_g-{\mathrm{\omega }}_m; {\mathrm{\alpha }}_{gm}={\mathrm{\alpha }}_g-{\mathrm{\alpha }}_m;$$

(1c)

where k is a unit vector perpendicular to the sheet and pointing toward the reader, and the following definitions have been introduced:

$${\mathrm{u}}_{\mathrm{g}}={\displaystyle \frac{P-R}{|P-R|}}; {\mathrm{v}}_{\mathrm{g}}=\mathrm{k}\times {\mathrm{u}}_{\mathrm{g}}; {\mathrm{a}}_{\mathrm{PR}\perp ,\mathrm{g}}={\mathrm{\alpha }}_g|P-R|{\mathrm{v}}_{\mathrm{g}}; {\mathrm{a}}_{\mathrm{PR}\parallel ,\mathrm{g}}=-{\mathrm{\omega }}_g^2|P-R|{\mathrm{u}}_{\mathrm{g}}.$$

(2)

2.2.1. RRR Dyad

Figure 3 shows the reference sketch of the RRR dyad (Figure 3a) previously built in GeoGebra and the vector diagrams of the velocity/acceleration loops (Figure 3b,c) built in GeoGebra, with the lists of commands reported below.

2.2.1.a. Vector Diagram of RRR Dyad’s Velocities

The intermediate R-pair with center at C (Figure 3a) brings one to write the following velocity loop equation:

$${\mathrm{v}}_{\mathrm{C},\mathrm{i}}={\mathrm{v}}_{\mathrm{C},\mathrm{j}}\hspace{1em}\Rightarrow \hspace{1em}{\mathrm{v}}_{\mathrm{A},\mathrm{i}}+{\mathrm{v}}_{\mathrm{CA},\mathrm{i}}={\mathrm{v}}_{\mathrm{B},\mathrm{j}}+{\mathrm{v}}_{\mathrm{CB},\mathrm{j}}$$

(3)

where v_A,i and v_B,j are the known velocities (i.e., the data inputs) of points A and B, respectively, whereas v_CA,i and v_CB,j are velocity differences whose directions must be always perpendicular to segment AC and BC (i.e., they have known directions), respectively, and whose signed magnitudes must be determined by solving Equation (3). The vector diagram that geometrically solves Equation (3) in GeoGebra can be generated with the list of commands reported in Appendix A.

The vector diagram of Figure 3b has been generated in GeoGebra by implementing the above-cited list of commands, and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point O, and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad, and automatically changes its shape when either the dyad changes its configuration and/or its geometry or the data inputs (i.e., v_A,i and v_B,j) change their values.

2.2.1.b. Vector Diagram of RRR Dyad’s Accelerations

The intermediate R-pair with center at C (Figure 3a) brings one to write the following acceleration loop equation:

$${\mathrm{a}}_{\mathrm{C},\mathrm{i}}={\mathrm{a}}_{\mathrm{C},\mathrm{j}}\hspace{1em}\Rightarrow \hspace{1em}{\mathrm{a}}_{\mathrm{A},\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA},\mathrm{i}}={\mathrm{a}}_{\mathrm{B},\mathrm{j}}+{\mathrm{a}}_{\mathrm{CB},\mathrm{j}}\hspace{1em}\Rightarrow \hspace{1em}{\mathrm{a}}_{\mathrm{A},\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA}\parallel ,\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA}\perp ,\mathrm{i}}={\mathrm{a}}_{\mathrm{B},\mathrm{j}}+{\mathrm{a}}_{\mathrm{CB}\parallel ,\mathrm{j}}+{\mathrm{a}}_{\mathrm{CB}\perp ,\mathrm{j}}$$

(4)

where a_A,i and a_B,j are the known accelerations (i.e., the data inputs) of points A and B, respectively, and the vector component a_CA‖,i (a_CB‖,j) is computable by using the already-computed ω_i (ω_j) and the last of Formulas (2). Also, the vector component a_CA⊥,i (a_CB⊥,j) must always be perpendicular to segment AC (BC), that is, it has a known direction. As a consequence, only the signed magnitudes of a_CA⊥,i and a_CB⊥,j are unknown and must be determined by solving Equation (4). The vector diagram that geometrically solves Equation (4) in GeoGebra can be generated with the list of commands reported in Appendix A.

The vector diagram of Figure 3c has been generated in GeoGebra by implementing the above-cited list of commands, and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point P and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad and automatically changes its shape when either the dyad changes its configuration and/or its geometry or the data inputs (i.e., a_A,i and a_B,j) change their values.

2.2.2. RRP Dyad

Figure 4 shows the reference sketch of the RRP dyad (Figure 4a) previously built in GeoGebra and the vector diagrams of the velocity/acceleration loops (Figure 4b,c) built in GeoGebra, with the lists of commands reported below.

2.2.2.a. Vector Diagram of RRP Dyad’s Velocities

The intermediate R-pair with center at C (Figure 4a) connecting links j and i and the P-pair with line f as the joint axis bring one to write the following velocity loop equation:

$$\left.\begin{array}{l}{\mathrm{v}}_{\mathrm{C},\mathrm{i}}={\mathrm{v}}_{\mathrm{C},\mathrm{j}}\Rightarrow {\mathrm{v}}_{\mathrm{A},\mathrm{i}}+{\mathrm{v}}_{\mathrm{CA},\mathrm{i}}={\mathrm{v}}_{\mathrm{B},\mathrm{j}}+{\mathrm{v}}_{\mathrm{CB},\mathrm{j}}\\ {\mathrm{\omega }}_j={\mathrm{\omega }}_f\\ {\mathrm{v}}_{\mathrm{B},\mathrm{j}}={\mathrm{v}}_{\mathrm{B},\mathrm{f}}+{\mathrm{v}}_{\mathrm{B},\mathrm{jf}}\\ {\mathrm{v}}_{\mathrm{B},\mathrm{f}}={\mathrm{v}}_{\mathrm{D},\mathrm{f}}+{\mathrm{v}}_{\mathrm{BD},\mathrm{f}}\end{array}\right\}\Rightarrow {\mathrm{v}}_{\mathrm{A},\mathrm{i}}+{\mathrm{v}}_{\mathrm{CA},\mathrm{i}}={\mathrm{v}}_{\mathrm{D},\mathrm{f}}+{\mathrm{v}}_{\mathrm{BD},\mathrm{f}}+{\mathrm{v}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{v}}_{\mathrm{CB},\mathrm{j}}$$

(5)

where v_A,i, v_D,f and ω_f (=ω_j) are known (i.e., they are the data inputs) and the velocity difference v_BD,f (v_CB,j) is computable by using the known ω_f (ω_j) and Formula (2). Also, the velocity difference v_CA,i (the relative velocity v_B,jf) has a known direction since it must be always perpendicular to segment AC (parallel to line f). As a consequence, the signed magnitudes of v_CA,i and v_B,jf are the unknowns of Equation (5) and are determinable by solving Equation (5). The vector diagram that geometrically solves Equation (5) in GeoGebra can be generated with the list of commands reported in Appendix A.

The vector diagram of Figure 4b has been generated in GeoGebra by implementing the above-cited list of commands, and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point O, and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad and automatically changes its shape when the dyad changes its configuration and/or its geometry or the data inputs (i.e., v_A,i, v_D,f and ω_f) change their values.

2.2.2.b. Vector Diagram of RRP Dyad’s Acceleration

The intermediate R-pair with center at C (Figure 4a) connecting links j and i, and the P-pair with line f as the joint axis bring one to write the following acceleration loop equation:

$$\left.\begin{array}{l}{\mathrm{a}}_{\mathrm{C},\mathrm{i}}={\mathrm{a}}_{\mathrm{C},\mathrm{j}}\Rightarrow {\mathrm{a}}_{\mathrm{A},\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA}\parallel ,\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA}\perp ,\mathrm{i}}={\mathrm{a}}_{\mathrm{B},\mathrm{j}}+{\mathrm{a}}_{\mathrm{CB},\mathrm{j}}\\ {\mathrm{\alpha }}_j={\mathrm{\alpha }}_f;\hspace{1em}{\mathrm{a}}_{\mathrm{cor}}=2{\mathrm{\omega }}_f(\mathrm{k}\times {\mathrm{v}}_{\mathrm{B},\mathrm{jf}})\\ {\mathrm{a}}_{\mathrm{B},\mathrm{j}}={\mathrm{a}}_{\mathrm{B},\mathrm{f}}+{\mathrm{a}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{a}}_{\mathrm{cor}}\\ {\mathrm{a}}_{\mathrm{B},\mathrm{f}}={\mathrm{a}}_{\mathrm{D},\mathrm{f}}+{\mathrm{a}}_{\mathrm{BD},\mathrm{f}}\end{array}\right\}\Rightarrow {\mathrm{a}}_{\mathrm{A},\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA}\parallel ,\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA}\perp ,\mathrm{i}}={\mathrm{a}}_{\mathrm{D},\mathrm{f}}+{\mathrm{a}}_{\mathrm{BD},\mathrm{f}}+{\mathrm{a}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{a}}_{\mathrm{cor}}+{\mathrm{a}}_{\mathrm{CB},\mathrm{j}}$$

(6)

where a_A,i, a_D,f and α_f (=α_j) are known (i.e., they are the data inputs) and the accelerations a_BD,f, a_CB,j, a_cor, and a_CA‖,i are computable by using ω_f, α_f, ω_j, α_j and v_B,jf, which are either data inputs or already-computed data, and Formulas (1) and (2). Also, the acceleration difference component a_CA⊥,i (the relative acceleration a_B,jf) has a known direction, since it must be always perpendicular to segment AC (parallel to line f). As a consequence, the signed magnitudes of a_CA⊥,i and a_B,jf are the unknowns of Equation (6) and are determinable by solving Equation (6). The vector diagram that geometrically solves Equation (6) in GeoGebra can be generated with the list of commands reported in Appendix A.

The vector diagram of Figure 4c has been generated in GeoGebra by implementing the above-cited list of commands, and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point P, and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad and automatically changes its shape when either the dyad changes its configuration and/or its geometry, or the data inputs (i.e., a_A,i, a_D,f and α_f) change their values.

2.2.3. RPR Dyad

Figure 5 shows a reference sketch of the RPR dyad (Figure 5a) previously built in GeoGebra and the vector diagrams of the velocity/acceleration loops (Figure 5b,c) built in GeoGebra, with the lists of commands reported below.

2.2.3.a. Vector Diagram of RPR Dyad’s Velocities

The intermediate P-pair joining links i and j (Figure 5a) brings one to write the relationships

$${\mathrm{v}}_{\mathrm{A},\mathrm{ji}}={\mathrm{v}}_{\mathrm{C},\mathrm{ji}}=-{\mathrm{v}}_{\mathrm{C},\mathrm{ij}};\hspace{1em}{\mathrm{\omega }}_j={\mathrm{\omega }}_i$$

(7)

and the equations

$$\left.\begin{array}{l}{\mathrm{v}}_{\mathrm{A},\mathrm{j}}={\mathrm{v}}_{\mathrm{A},\mathrm{i}}+{\mathrm{v}}_{\mathrm{A},\mathrm{ji}}\\ {\mathrm{v}}_{\mathrm{A},\mathrm{j}}={\mathrm{v}}_{\mathrm{B},\mathrm{j}}+{\mathrm{v}}_{\mathrm{AB},\mathrm{j}}\end{array}\right\}\Rightarrow {\mathrm{v}}_{\mathrm{A},\mathrm{i}}+{\mathrm{v}}_{\mathrm{A},\mathrm{ji}}={\mathrm{v}}_{\mathrm{B},\mathrm{j}}+{\mathrm{v}}_{\mathrm{AB},\mathrm{j}}$$

(8a)

$${\mathrm{v}}_{\mathrm{C},\mathrm{j}}={\mathrm{v}}_{\mathrm{A},\mathrm{j}}+{\mathrm{v}}_{\mathrm{CA},\mathrm{j}}={\mathrm{v}}_{\mathrm{B},\mathrm{j}}+{\mathrm{v}}_{\mathrm{CB},\mathrm{j}}\Rightarrow {\mathrm{v}}_{\mathrm{AB},\mathrm{j}}={\mathrm{v}}_{\mathrm{CB},\mathrm{j}}-{\mathrm{v}}_{\mathrm{CA},\mathrm{j}}$$

(8b)

$${\mathrm{v}}_{\mathrm{C},\mathrm{i}}={\mathrm{v}}_{\mathrm{C},\mathrm{j}}+{\mathrm{v}}_{\mathrm{C},\mathrm{ij}}$$

(8c)

where v_A,i and v_B,j are the known velocities (i.e., the data inputs) of points A and B, respectively, whereas the relative velocity v_A,ji (=v_C,ji = −v_C,ij) must always be parallel to the P-pair joint axis and the velocity differences v_AB,j, v_CA,j and v_CB,j must always be perpendicular to segments AB, CA, and CB, respectively. Consequently, only the signed magnitudes of v_A,ji and v_AB,j are unknown in Equation (8a) and can be determined by solving Equation (8a). Then, by introducing the so-determined v_AB,j into Equation (8b), v_CA,j, v_CB,j and v_C,j can also be determined and, eventually, the introduction of the so-determined v_A,ji (=v_C,ji = −v_C,ij) and v_C,j into Equation (8c) gives v_C,i. This solution procedure can be geometrically implemented through vector diagrams that can be built in GeoGebra with the list of commands reported in Appendix A.

The vector diagram of Figure 5b has been generated in GeoGebra by implementing the above cited list of commands, and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point O and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad, and automatically changes its shape when either the dyad changes its configuration and/or its geometry, or the data inputs (i.e., v_A,i and v_B,j) change their values.

2.2.3.b. Vector Diagram of RPR Dyad’s Acceleration

The intermediate P-pair joining links i and j (Figure 5a) brings one to write the following relationships

$${\mathrm{a}}_{\mathrm{A},\mathrm{ji}}={\mathrm{a}}_{\mathrm{C},\mathrm{ji}}=-{\mathrm{a}}_{\mathrm{C},\mathrm{ij}};\hspace{1em}{\mathrm{\alpha }}_j={\mathrm{\alpha }}_i$$

(9)

and the following equations

$$\left.\begin{array}{l}{\mathrm{a}}_{\mathrm{A},\mathrm{j}}={\mathrm{a}}_{\mathrm{A},\mathrm{i}}+{\mathrm{a}}_{\mathrm{A},\mathrm{ji}}+{\mathrm{a}}_{\mathrm{cor}}\\ {\mathrm{a}}_{\mathrm{cor}}=2{\mathrm{\omega }}_i(\mathrm{k}\times {\mathrm{v}}_{\mathrm{A},\mathrm{ji}})\\ {\mathrm{a}}_{\mathrm{A},\mathrm{j}}={\mathrm{a}}_{\mathrm{B},\mathrm{j}}+{\mathrm{a}}_{\mathrm{AB},\mathrm{j}}\\ {\mathrm{a}}_{\mathrm{AB},\mathrm{j}}={\mathrm{a}}_{\mathrm{AB}\perp ,\mathrm{j}}+{\mathrm{a}}_{\mathrm{AB}\parallel ,\mathrm{j}}\\ {\mathrm{a}}_{\mathrm{AB}\parallel ,\mathrm{j}}=-{\mathrm{\omega }}_j^2(A-B)\end{array}\right\}\Rightarrow {\mathrm{a}}_{\mathrm{A},\mathrm{i}}+{\mathrm{a}}_{\mathrm{A},\mathrm{ji}}+{\mathrm{a}}_{\mathrm{cor}}={\mathrm{a}}_{\mathrm{B},\mathrm{j}}+{\mathrm{a}}_{\mathrm{AB}\perp ,\mathrm{j}}+{\mathrm{a}}_{\mathrm{AB}\parallel ,\mathrm{j}}$$

(10a)

$$\left.\begin{array}{l}{\mathrm{a}}_{\mathrm{C},\mathrm{j}}={\mathrm{a}}_{\mathrm{A},\mathrm{j}}+{\mathrm{a}}_{\mathrm{CA},\mathrm{j}}={\mathrm{a}}_{\mathrm{B},\mathrm{j}}+{\mathrm{a}}_{\mathrm{CB},\mathrm{j}}\\ \\ {\mathrm{\alpha }}_j={\displaystyle \frac{{\mathrm{a}}_{\mathrm{AB}\perp ,\mathrm{j}}\cdot [\mathrm{k}\times (A-B)]}{{‖A-B‖}^2}}\\ {\mathrm{\beta }}_j=\arctan \left({\displaystyle \frac{{\mathrm{\alpha }}_j}{{\mathrm{\omega }}_j^2}}\right)\end{array}\right\}\Rightarrow {\mathrm{a}}_{\mathrm{AB},\mathrm{j}}={\mathrm{a}}_{\mathrm{CB},\mathrm{j}}-{\mathrm{a}}_{\mathrm{CA},\mathrm{j}}$$

(10b)

$${\mathrm{a}}_{\mathrm{C},\mathrm{i}}={\mathrm{a}}_{\mathrm{C},\mathrm{j}}+{\mathrm{a}}_{\mathrm{C},\mathrm{ij}}+{\mathrm{a}}_{\mathrm{cor}}$$

(10c)

where a_A,i and a_B,j are the known accelerations (i.e., the data inputs) of points A and B, respectively, and a_cor (a_AB‖,j) is computable from the velocity analysis results. Moreover, the relative acceleration a_A,ji (=a_C,ji = −a_C,ij) must always be parallel to the P-pair joint axis and the acceleration differences a_AB,j, a_CA,j and a_CB,j must always form the angle β_j with segments AB, CA, and CB, respectively. Consequently, only the signed magnitudes of a_A,ji and a_AB⊥,j are unknown in Equation (10a), and can be determined by solving Equation (10a). Then, introducing the so-determined a_AB⊥,j into Equation (10b) brings one firstly to compute α_j and β_j, and then, to determine a_CA,j, a_CB,j and a_C,j. Eventually, the introduction of the so-determined a_A,ji (=a_C,ji = −a_C,ij) and a_C,j into Equation (10c) gives a_C,i. This solution procedure can be geometrically implemented through vector diagrams that can be built in GeoGebra with the list of commands reported in Appendix A.

The vector diagram of Figure 5c has been generated in GeoGebra by implementing the above-cited list of commands, and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point P, and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad, and automatically changes its shape when the dyad changes its configuration and/or its geometry or the data inputs (i.e., a_A,i and a_B,j) change their values.

2.2.4. PRP Dyad

Figure 6 shows the reference sketch of the PRP dyad (Figure 6a) previously built in GeoGebra and the vector diagrams of the velocity/acceleration loops (Figure 6b,c) built in GeoGebra, with the lists of commands reported below.

2.2.4.a. Vector Diagram of PRP Dyad’s Velocities

The intermediate R-pair with center at C (Figure 6a) connecting links j and i and the P-pairs with line f and line c as joint axes bring one to write the following velocity loop equation:

$$\left.\begin{array}{l}{\mathrm{v}}_{\mathrm{C},\mathrm{i}}={\mathrm{v}}_{\mathrm{C},\mathrm{j}}\Rightarrow {\mathrm{v}}_{\mathrm{A},\mathrm{i}}+{\mathrm{v}}_{\mathrm{CA},\mathrm{i}}={\mathrm{v}}_{\mathrm{B},\mathrm{j}}+{\mathrm{v}}_{\mathrm{CB},\mathrm{j}}\\ {\mathrm{\omega }}_j={\mathrm{\omega }}_f;\hspace{1em}{\mathrm{\omega }}_i={\mathrm{\omega }}_c;\\ {\mathrm{v}}_{\mathrm{B},\mathrm{j}}={\mathrm{v}}_{\mathrm{B},\mathrm{f}}+{\mathrm{v}}_{\mathrm{B},\mathrm{jf}};\hspace{1em}{\mathrm{v}}_{\mathrm{A},\mathrm{i}}={\mathrm{v}}_{\mathrm{A},\mathrm{c}}+{\mathrm{v}}_{\mathrm{A},\mathrm{ic}};\\ {\mathrm{v}}_{\mathrm{B},\mathrm{f}}={\mathrm{v}}_{\mathrm{D},\mathrm{f}}+{\mathrm{v}}_{\mathrm{BD},\mathrm{f}};\hspace{0.33em}\hspace{0.33em}{\mathrm{v}}_{\mathrm{A},\mathrm{c}}={\mathrm{v}}_{\mathrm{E},\mathrm{c}}+{\mathrm{v}}_{\mathrm{AE},\mathrm{c}};\end{array}\right\}\Rightarrow {\mathrm{v}}_{\mathrm{E},\mathrm{c}}+{\mathrm{v}}_{\mathrm{AE},\mathrm{c}}+{\mathrm{v}}_{\mathrm{A},\mathrm{ic}}+{\mathrm{v}}_{\mathrm{CA},\mathrm{i}}={\mathrm{v}}_{\mathrm{D},\mathrm{f}}+{\mathrm{v}}_{\mathrm{BD},\mathrm{f}}+{\mathrm{v}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{v}}_{\mathrm{CB},\mathrm{j}}$$

(11)

where v_E,c, v_D,f, ω_c (=ω_i) and ω_f (=ω_j) are known (i.e., they are the data inputs) and the velocity differences v_BD,f and v_CB,j (v_AE,c and v_CA,i) are computable by using the known ω_f (ω_c) and Formulas (2). Also, the relative velocity v_A,ic (the relative velocity v_B,jf) has a known direction since it must always be parallel to line c (to line f). As a consequence, the signed magnitudes of v_A,ic and v_B,jf are the unknowns of Equation (11) and are determinable by solving Equation (11). The vector diagram that geometrically solves Equation (11) in GeoGebra can be generated with the list of commands reported in Appendix A.

The vector diagram of Figure 6b has been generated in GeoGebra by implementing the above-cited list of commands, and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point O and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad and automatically changes its shape when either the dyad changes its configuration and/or its geometry, or the data inputs (i.e., v_E,c, v_D,f, ω_c and ω_f) change their values.

2.2.4.b. Vector Diagram of PRP Dyad’s Acceleration

The intermediate R-pair with center at C (Figure 6a) connecting links j and i and the P-pairs with line c and f as joint axes bring one to write the following acceleration loop equation:

$$\left.\begin{array}{l}{\mathrm{a}}_{\mathrm{C},\mathrm{i}}={\mathrm{a}}_{\mathrm{C},\mathrm{j}}\Rightarrow {\mathrm{a}}_{\mathrm{A},\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA},\mathrm{i}}={\mathrm{a}}_{\mathrm{B},\mathrm{j}}+{\mathrm{a}}_{\mathrm{CB},\mathrm{j}}\\ {\mathrm{\alpha }}_j={\mathrm{\alpha }}_f;\hspace{1em}{\mathrm{a}}_{\mathrm{cor},\mathrm{f}}=2{\mathrm{\omega }}_f(\mathrm{k}\times {\mathrm{v}}_{\mathrm{B},\mathrm{jf}})\\ {\mathrm{a}}_{\mathrm{B},\mathrm{j}}={\mathrm{a}}_{\mathrm{B},\mathrm{f}}+{\mathrm{a}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{f}}\\ {\mathrm{a}}_{\mathrm{B},\mathrm{f}}={\mathrm{a}}_{\mathrm{D},\mathrm{f}}+{\mathrm{a}}_{\mathrm{BD},\mathrm{f}}\\ {\mathrm{\alpha }}_i={\mathrm{\alpha }}_c;\hspace{1em}{\mathrm{a}}_{\mathrm{cor},\mathrm{c}}=2{\mathrm{\omega }}_c(\mathrm{k}\times {\mathrm{v}}_{\mathrm{A},\mathrm{ic}})\\ {\mathrm{a}}_{\mathrm{A},\mathrm{i}}={\mathrm{a}}_{\mathrm{A},\mathrm{c}}+{\mathrm{a}}_{\mathrm{A},\mathrm{ic}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{c}}\\ {\mathrm{a}}_{\mathrm{A},\mathrm{c}}={\mathrm{a}}_{\mathrm{E},\mathrm{c}}+{\mathrm{a}}_{\mathrm{AE},\mathrm{c}}\end{array}\right\}\Rightarrow {\mathrm{a}}_{\mathrm{E},\mathrm{c}}+{\mathrm{a}}_{\mathrm{AE},\mathrm{c}}+{\mathrm{a}}_{\mathrm{A},\mathrm{ic}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{c}}+{\mathrm{a}}_{\mathrm{CA},\mathrm{i}}={\mathrm{a}}_{\mathrm{D},\mathrm{f}}+{\mathrm{a}}_{\mathrm{BD},\mathrm{f}}+{\mathrm{a}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{f}}+{\mathrm{a}}_{\mathrm{CB},\mathrm{j}}$$

(12)

where a_E,c, a_D,f, α_c (=α_i) and α_f (=α_j) are known (i.e., they are the data inputs) and the accelerations a_BD,f, a_CB,j, a_cor,f, a_AE,c, a_CA,i and a_cor,c are computable using ω_f, α_f, ω_c, α_c, v_B,jf, and v_A,ic, which are either data inputs or already-computed data, along with Formulas (1) and (2). Also, the relative acceleration a_A,ic (a_B,jf) has a known direction since it must always be parallel to line c (line f). As a consequence, the signed magnitudes of a_A,ic and a_B,jf are the unknowns of Equation (12) and are determinable by solving Equation (12). The vector diagram that geometrically solves Equation (12) in GeoGebra can be generated with the list of commands reported in Appendix A.

The vector diagram of Figure 6c has been generated in GeoGebra by implementing the above-cited list of commands and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point P and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad and automatically changes its shape when either the dyad changes its configuration and/or its geometry or the data inputs (i.e., a_E,c, a_D,f, α_f and α_f) change their values.

2.2.5. RPP Dyad

Figure 7 shows the reference sketch of the RPP dyad (Figure 7a) previously built in GeoGebra and the vector diagrams of the velocity/acceleration loops (Figure 7b,c) built in GeoGebra, with the list of commands reported below.

2.2.5.a. Vector Diagram of RPP Dyad’s Velocities

The intermediate P-pair with line m as joint axis (Figure 7a) connecting links j and i and the P-pair with line f as joint axis bring one to write the following velocity loop equation

$$\left.\begin{array}{l}{\mathrm{v}}_{\mathrm{C},\mathrm{i}}={\mathrm{v}}_{\mathrm{C},\mathrm{j}}+{\mathrm{v}}_{\mathrm{C},\mathrm{ij}}\Rightarrow {\mathrm{v}}_{\mathrm{A},\mathrm{i}}+{\mathrm{v}}_{\mathrm{CA},\mathrm{i}}={\mathrm{v}}_{\mathrm{B},\mathrm{j}}+{\mathrm{v}}_{\mathrm{CB},\mathrm{j}}+{\mathrm{v}}_{\mathrm{C},\mathrm{ij}}\\ {\mathrm{\omega }}_i={\mathrm{\omega }}_j={\mathrm{\omega }}_f\\ {\mathrm{v}}_{\mathrm{B},\mathrm{j}}={\mathrm{v}}_{\mathrm{B},\mathrm{f}}+{\mathrm{v}}_{\mathrm{B},\mathrm{jf}}\\ {\mathrm{v}}_{\mathrm{B},\mathrm{f}}={\mathrm{v}}_{\mathrm{D},\mathrm{f}}+{\mathrm{v}}_{\mathrm{BD},\mathrm{f}}\end{array}\right\}\Rightarrow {\mathrm{v}}_{\mathrm{A},\mathrm{i}}+{\mathrm{v}}_{\mathrm{CA},\mathrm{i}}={\mathrm{v}}_{\mathrm{D},\mathrm{f}}+{\mathrm{v}}_{\mathrm{BD},\mathrm{f}}+{\mathrm{v}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{v}}_{\mathrm{CB},\mathrm{j}}+{\mathrm{v}}_{\mathrm{C},\mathrm{ij}}$$

(13)

where v_A,i, v_D,f and ω_f (=ω_i = ω_j) are known (i.e., they are the data inputs) and the velocity differences v_CA,i, v_BD,f, and v_CB,j are computable by using the known ω_f (=ω_i = ω_j) along with Formulas (2). Also, the relative velocity v_C,ij (v_B,jf) has a known direction since it must be always parallel to line m (parallel to line f). As a consequence, the signed magnitudes of v_C,ij and v_B,jf are the unknowns of Equation (13), and are determinable by solving Equation (13). The vector diagram that geometrically solves Equation (13) in GeoGebra can be generated with the list of commands reported in Appendix A.

The vector diagram of Figure 7b has been generated in GeoGebra by implementing the above-cited list of commands, and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point O and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad and automatically changes its shape when either the dyad changes its configuration and/or its geometry or the data inputs (i.e., v_A,i, v_D,f and ω_f) change their values.

2.2.5.b. Vector Diagram of RPP Dyad’s Acceleration

The intermediate P-pair with line m as joint axis (Figure 7a) connecting links j and i and the P-pair with line f as joint axis bring one to write the following acceleration loop equation:

$$\left.\begin{array}{l}{\mathrm{a}}_{\mathrm{C},\mathrm{i}}={\mathrm{a}}_{\mathrm{C},\mathrm{j}}+{\mathrm{a}}_{\mathrm{C},\mathrm{ij}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{j}}\Rightarrow {\mathrm{a}}_{\mathrm{A},\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA},\mathrm{i}}={\mathrm{a}}_{\mathrm{B},\mathrm{j}}+{\mathrm{a}}_{\mathrm{CB},\mathrm{j}}+{\mathrm{a}}_{\mathrm{C},\mathrm{ij}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{j}}\\ \left.\begin{array}{l}{\mathrm{a}}_{\mathrm{B},\mathrm{j}}={\mathrm{a}}_{\mathrm{B},\mathrm{f}}+{\mathrm{a}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{f}}\\ {\mathrm{a}}_{\mathrm{B},\mathrm{f}}={\mathrm{a}}_{\mathrm{D},\mathrm{f}}+{\mathrm{a}}_{\mathrm{BD},\mathrm{f}}\end{array}\right\}\Rightarrow {\mathrm{a}}_{\mathrm{B},\mathrm{j}}={\mathrm{a}}_{\mathrm{D},\mathrm{f}}+{\mathrm{a}}_{\mathrm{BD},\mathrm{f}}+{\mathrm{a}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{f}}\\ {\mathrm{a}}_{\mathrm{cor},\mathrm{j}}=2{\mathrm{\omega }}_j(\mathrm{k}\times {\mathrm{v}}_{\mathrm{C},\mathrm{ij}});\hspace{1em}{\mathrm{a}}_{\mathrm{cor},\mathrm{f}}=2{\mathrm{\omega }}_f(\mathrm{k}\times {\mathrm{v}}_{\mathrm{B},\mathrm{jf}})\\ {\mathrm{\omega }}_i={\mathrm{\omega }}_j={\mathrm{\omega }}_f;\hspace{1em}{\mathrm{\alpha }}_i={\mathrm{\alpha }}_j={\mathrm{\alpha }}_f\end{array}\right\}\Rightarrow {\mathrm{a}}_{\mathrm{A},\mathrm{i}}+{\mathrm{a}}_{\mathrm{CA},\mathrm{i}}={\mathrm{a}}_{\mathrm{D},\mathrm{f}}+{\mathrm{a}}_{\mathrm{BD},\mathrm{f}}+{\mathrm{a}}_{\mathrm{B},\mathrm{jf}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{f}}+{\mathrm{a}}_{\mathrm{CB},\mathrm{j}}+{\mathrm{a}}_{\mathrm{C},\mathrm{ij}}+{\mathrm{a}}_{\mathrm{cor},\mathrm{j}}$$

(14)

where a_A,i, a_D,f and α_f (=α_i = α_j) are known (i.e., they are the data inputs). The acceleration differences a_CA,i, a_BD,f, and a_CB,j together with the Coriolis accelerations a_cor,j and a_cor,f are computable by using ω_f (=ω_i = ω_j), α_f (=α_i = α_j), v_B,jf, and v_C,ij, which are either data inputs or already-computed data, and Formulas (1) and (2). Also, the relative acceleration a_C,ij (a_B,jf) has a known direction since it must be always parallel to line m (parallel to line f). As a consequence, the signed magnitudes of a_C,ij and a_B,jf are the unknowns of Equation (14) and are determinable by solving Equation (14). The vector diagram that geometrically solves Equation (14) in GeoGebra can be generated with the list of commands reported in Appendix A.

The vector diagram of Figure 7c has been generated in GeoGebra by implementing the above-cited list of commands and then adjusting the properties (i.e., colors, captions, etc.) of the introduced objects. The so-generated vector diagram can be rigidly moved on the Cartesian plane window by clicking on point P and then moving the mouse. Also, it is geometrically constrained to the dynamic sketch of the dyad, and automatically changes its shape when either the dyad changes its configuration and/or its geometry or the data inputs (i.e., a_A,i, a_D,f and α_f) change their values.

2.3. Kinetostatics Analysis’ Vector Diagram

Kinetostatics analysis (KA) of a linkage is the determination of the generalized torques, applied by the actuators in the actuated joints, when the external forces applied to the linkage and the linkage motion (i.e., the inertial forces) are known. The classic approaches for solving this problem are two: (a) the free-body method and (b) the virtual work principle. Both these approaches are graphically implementable when the mechanism sketch is available, the first one using free-body diagrams [29] and the latter with active-load diagrams [30,31,32]. Since both the methods require only sums of vectors and intersections of lines, they can be easily implemented in GeoGebra.

2.3.1. Free-Body Method

The graphic solution of the free-body method is based on graphically solving the force equilibrium equation of each link, when separated from the rest of the linkage and loaded by the external forces and the constraint reactions coming from the joints, after having satisfied the moment equilibrium equation by imposing geometric conditions on the line of actions of those forces. In particular, the conditions that make the moment equilibrium equation satisfied [29] are as follows:

(a)

in the case of only two forces, if the two forces share the same line of action;

(b)

in the case of two forces and a pure moment, if the two forces have parallel and non-coincident lines of action;

(c)

in the case of only three forces, if the lines of action of the three forces share a common intersection point;

(d)

in the case of four forces, if the four forces, separated into two subsystems of two forces, gives two resultants, one for each subsystem, that are aligned along the line passing through the two intersections of the two lines of action of each subsystem.

The analysis of the joint types provides the known pieces of information regarding the action line of the constraint reaction forces, that is, in ideal constraints, the center of an R-pair (the direction perpendicular to the P-pair sliding direction) belongs to (is the direction of) the line of action of the R-pair’s (P-pair’s) constraint reaction force.

It is worth remembering that a planar system of forces with non-null resultant (with null resultant and non-null resultant moment) can always be reduced to a unique force on the system’s central axis (to a unique pure moment).

This method is always applicable to directly solve the linkage’s static analysis when only one link is loaded by either one external force, which replaces a general system of planar forces with non-null resultant, or by one pure moment, which replaces a general system of planar forces with null resultant and non-null resultant moment. Also, it is able to indirectly solve any case of a linkage static analysis with the superposition principle, that is, by summing up the results obtained when only one loaded link at a time is analyzed.

2.3.2. Method Based on Active Load Diagrams

The method based on active-load diagrams has been recently proposed [30,31,32]. This method analyzes any multi-degrees-of-freedom (DOF) linkage passing through the single-DOF linkages generated from it by locking all the actuated joints but one. In doing so, it uses the velocity coefficients, expressed using the instant centers (ICs), of the so-generated single-DOF linkages together with suitable moment arms to write the geometric and the analytic formulas that give the generalized torques. The interested reader can refer to [30,31,32] for details.

Since, in the vast majority of single-DOF linkages, the IC locations are geometrically determinable by intersecting suitable couples of lines [32] that move with the mechanism sketch, this approach is easily implementable in GeoGebra after the dynamic sketch of the linkage has been built.

3. Results

In this section, the systematic approach presented above to build dynamic sketches of planar linkages and to study their kinematics and kinetotostatics is applied to three case studies: a) generation of coupler curves, b) four-bar kinetostatics, and c) kinematic analysis of shaper mechanisms. In the zipped file “GGB files.zip” uploaded as “Supplementary Material”, the folder “Case Studies” contains the GeoGebra files (extension ggb) with the GeoGebra programs of the three case studies. In Appendix C, these GeoGebra programs are reported together with comments that explain what each command line generates in the Cartesian plane window of GeoGebra.

3.1. Generation of Coupler Curves

Four-bar linkages’ coupler curves play a role in designing four-bar and six-bar (Stephenson) linkages that satisfy a number of design requirements (one or two dwells, path with an about-linear arc, etc.). In [2], the graphical procedures for solving these design problems using coupler curves are illustrated; all those graphical procedures can be implemented in GeoGebra after having built a four-bar dynamic sketch that parametrically generates the coupler curves.

With the above illustrated methodology, such a sketch is buildable in GeoGebra by recognizing that a four-bar linkage is obtained through the assemblage of one driving link (the crank) with actuated R-pair (Figure 2a) and one dyad of RRR type (Figure 1a) constituted by the coupler and the rocker of the four bar. Also, in GeoGebra, the coupler point, say E, that traces the coupler curve is parametrically generable, for instance, as follows. Two mutually perpendicular unit vectors, say u_c and v_c, fixed to the coupler are introduced, and the position of point E is defined as E = C + x_c*u_c + y_c*v_c, where C is the moveable ending of the crank, whereas x_c and y_c are two scalar parameters defined through “Slider” commands. Eventually, by setting “Show Trace” in the properties of point E, when the crank is animated, the coupler curve is generated. The commented list of GeoGebra commands that build this dynamic sketch is reported in Appendix C.

Figure 8 shows the dynamic sketch and the generated coupler curve together with the “Sliders” necessary to change the mobile links’ geometry and to animate the sketch. In this sketch, the frame geometry can be modified by clicking on point A or B and moving the mouse.

3.2. Four-Bar Kinetostatics

A four-bar dynamic sketch, built as illustrated in the previous subsection, can be exploited to make graphical analyses of four-bar linkages’ kinetostatics. Indeed, the mass distribution data of the mobile links can be assigned through “Slider” commands; moreover, the barycenter accelerations and the angular accelerations of the same links can be graphically determined with the proposed methodology and successively used to apply the inertia forces to the mobile links; eventually, the kinetostatic analysis of the so-loaded four bar can be graphically solved. In GeoGebra, such a procedure is implementable, for instance, with the list of commands reported in Appendix C. Hereafter, F_ij denotes the constraint reaction force applied by link i to link j, while F_ij._n denotes the contribution to F_ij due to the inertial and external load applied to link n.

Figure 9 shows a dynamic sketch and the velocity/acceleration diagrams generated in GeoGebra for the case of the constant angular velocity of the crank (ω₂ = 2π/3 rad/s and α₂ = 0 rad/s²) at the instant of motion t = 0.5 s (all the measurement units are in SI).

Figure 10 shows the geometric solution of the kinetostatic analysis of four-bar linkages, at the instant of motion t = 0.54 s (all the measurement units are in SI), built in GeoGebra with the above-cited list of commands, after having adjusted the properties (i.e., colors, captions, etc.) of the introduced objects in their “Settings” menu. The motion inputs are as follows: the crank rotates at a constant angular velocity (ω₂ = 2π/3 rad/s and α₂ = 0 rad/s²). The static inputs are as follows: only the inertial forces load the links. M₁₂ is the generalized torque that must be computed; it is applied by the unique actuator mounted in the R-pair centered at A. On the linkage sketch, the blue (green (violet)) lines of action and forces refer to the case in which only link 3 (link 4 (link 2)) is loaded, whereas the red forces are the resultants obtained through the superposition principle. The sketch is animated by the “Slider” t, which is the time in seconds. The zipped file uploaded as “Supplementary Material” contains the video “4-bar_KinetostaticsAnimation.wmv” that shows this animation. The mobile links’ lengths can be modified through the “Slider”s a₂ (for link 2), a₃ (for link 3), and a₄ (for link 4). The frame geometry can be modified by clicking on point A (point B) and then moving the mouse.

In GeoGebra (version geogebra.org/classic), one “SpreadSheet” window and a second graphic window, named “Graphic2”, can be generated. The values assumed during animation by the introduced independent or dependent variables are recordable on the “SpreadSheet” window, and then are usable to generate a polyline (“Polyline” command) in the window “Graphic2”, which represents their diagrams. Figure 11 shows the diagram of the generalized torque M₁₂ as a function of time, t, during one full cycle of crank motion, that is, for t ranging from 0 s to 3 s, generated in GeoGebra with this procedure (the recorded variables are t and M₁₂, and the polyline refers to the sequence of points with coordinates (t, M₁₂)).

3.3. Shaper Mechanism’s Kinematic Analysis

A shaper mechanism (see Figure 12) is a single-DOF two-looped linkage obtainable by assembling in sequence one driving link, the frame and two dyads, one of RPR type and the other of RRP type. The driving link is a crank (link 2 in Figure 12) hinged to the frame (link 1 in Figure 12) at one ending (point A in Figure 12) through an actuated R-pair, and to the RPR dyad (the one constituted by links 3 and 4 in Figure 12) on the other ending (point C in Figure 12) through a passive R-pair. The RPR dyad, at its other ending (point B in Figure 12), is joined to the frame. Also, the same RPR dyad, through a third passive R-pair (the one centered at point D in Figure 12), is joined to the RRP dyad (the one constituted by links 5 and 6 in Figure 12). The RRP dyad closes the second loop of the mechanism through its P-pair (the one with horizontal sliding direction in Figure 12) that joins it to the frame.

Figure 12 shows the dynamic sketch and the velocity/acceleration diagrams generated in GeoGebra for the case of constant angular velocity of the crank (ω₂ = 1 rad/s and α₂ = 0 rad/s²) at the instant of motion t = 4.27 s (all the measurement units are in SI). With reference to Figure 12, the geometric parameters, introduced through “Slider” commands, are the following ones: a₁, a₂, a₄, and a₅ are the lengths of segments AB, AC, BD, and DE, respectively, and b₁ is the distance of point A from the black dash-dot line. Also, the slider T assigns the motion period (i.e., ω₂ = 2π/T rad/s) in seconds and the sketch is animated through the slider t, which is the time in seconds. The zipped file uploaded as “Supplementary Material” contains the video “ShaperMechanismAnimation.wmv” that shows this animation. The list of GeoGebra commands used to generate the dynamic sketch and the velocity/acceleration diagrams of Figure 12 are reported in Appendix C.

4. Discussion

The presented technique for building dynamic sketches in GeoGebra is applicable to all the planar linkages decomposable into driving links, frame and dyads. This approach is extendable to planar mechanisms that also contain other types of Assur groups (e.g., triads, etc.) provided that the position analysis of those other groups be solved in analytical form. Indeed, for complex Assur groups, the geometric construction starting from the free endings’ data is cumbersome and needs to be bypassed by directly inserting formulas. Once the dynamic sketch has been built, either geometrically or with specific formulas, all the other (velocity/acceleration/kinetostatic) analyses are geometrically implementable since they always correspond to the solution of linear problems (i.e., they only need to find the intersections of suitable lines).

The presented case studies show that the systematic fully graphic solution of kinematic and kinetostatic problems based on dynamic sketches of mechanisms with dyads is able to provide pieces of information useful during design that are not easy to extract from purely analytic/numeric approaches. In particular, it is worth noting that the diagrams of Figure 10 immediately show how to change the external loads on the links to modify particular components of the constraint reactions, and how accelerations directly influence the loads on the links. Indeed (see Figure 10), the acceleration diagrams generate the loads on the links, which, for each link, are reduced to one resultant force lying on the central axis. Then, the static analysis of the mechanism is graphically solved considering only one force at a time, which generates the green, the blue and the violet action lines and constraint reactions for F₄, F₃, and F₂, respectively. Eventually, by using the superposition principle, the actual (red) constraint reactions and generalized torque are determined by summing up their green, blue and violet components.

The usefulness of these diagrams is mainly related to the fact that they are constrained to follow the mechanism motion. In fact, their manual construction was not suitable to make them an efficient design tool, as they are when they automatically follow a dynamic sketch whose geometry can also be varied. As far as these authors are aware, this is the first time that the fully graphical solution, tied to a dynamic sketch, of four bars’ kinetostatic analysis has been presented; also, the adopted methodology is general, and can be used for any linkage decomposable into dyads, frame and driving links.

Regarding linkages’ synthesis, the possibility of tracing the paths of points (e.g., the coupler curves built in Section 3.1) and of other geometric objects during the mechanism animation allows the implementation of all the synthesis techniques that use those paths [2]. Also, since the eight geometric constraint tools listed in [2] as necessary to implement all the GCP synthesis procedures reported in the literatures are present in GeoGebra, together with the possibility of writing equations [4], all these synthesis techniques can also be implemented in GeoGebra.

Differently from CAD platforms, vectors and captions are easy to generate in GeoGebra, which greatly facilitates building vector diagrams and finding graphical solutions of vector equations.

5. Conclusions

Geometric constraint programming (GCP) has enabled us to rediscover graphic techniques for solving the kinematics/kinetostatics analysis/synthesis of planar linkages. Such techniques, when easy to implement, are superior with respect to analytic/numeric techniques both in a design context and in the higher-education didactic. Indeed, over the numeric solution of the specific problem, they provide a clear physical representation of linkages’ behavior that helps designers to satisfy design requirements and students to reach a deeper comprehension of linkages’ mechanics.

The use of GeoGebra for implementing GCP has been explored in this work. In particular, the systematic construction of dynamic sketches of linkages composed by frame, driving links and dyads has been presented together with how to use them for graphically solving kinematics and kinetostatics problems.

This study proves that GeoGebra has all the tools necessary for implementing any GCP synthesis procedure already presented in the literature for this type of linkage, and for building any vector diagram that solves kinematic/kinetostatic analysis problems. This result is useful both to designers and in mechanical engineering higher education.

The three case studies, which have been illustrated, show the effectiveness of the proposed approach and of GeoGebra for GCP implementations.

As far as these authors are aware, the proposed systematic approach for the graphical implementation of the analytic techniques that solve the kinematic/kinetostatic analyses of these linkages is presented here for the first time.