Problem Statement
Video games today play significant role of our or our children’s life. Therefore, I considered
verifying some of its properties that should mimic real life, specifically, the gravitational
acceleration. I used a game called FIFA 15 which is a soccer game and can be played in PS4
console. Throughout the project, I will try to analyze a video from the game to come up with a
number of the acceleration in the anticipated direction of gravity.
The Approach
The method I will use is digitizing a short video of the game and using Savistky-Golay
interpolants to predict the gravitational acceleration.
Video Capturing
There are multiple obstacles in digitizing the video. Thankfully, the console of the game has its
own recording tool. However, the camera is moving in two directions, up and down and
sideways, and rotating about these axes as well which will break down the 2D planar assumption
we used in the Howitzer cart problem. I was able to prevent rotation about both axes from the
setting of the game as well as moving up and down, in the axial direction. However, moving
along the longitudinal direction was built in the game. Therefore, I needed to find a range of
snapshots at which the camera is not moving along that direction. Fortunately, the range was
large enough for the Savistky-Golay interpolants to predict the velocity and acceleration in the
axial direction.
Analyzing The Clip
The first step now to analyze the video is to find the frame rate. The easiest way to find that was
using software called Media Player Classes, which extracts the frame rate of the clip. Then,
TPSDIG was used to trace the ball. Finally, Savitsky-Golay interplants were used to predict the
acceleration in the axial direction, which should be close to the gravitational acceleration. One
last step is needed to convert pixels to meter that require a known dimension of an object in the
clip. I chose that to be the height of one of the players which was easily determined from a quick
search from Google.
Verifying The Results
One of the most important skills I learned in this course is to verify my work. Hence, I digitized
a real video from YouTube and followed the same procedure described above. The result was
really close to the results previously found from the game clip which indicates the consistency
among them. Fortunately, their results were within engineering limits of gravitational
acceleration 9.81 m/s^2.
ME 481
Final Project
Henry Arneson
Mantis Shrimp Striking Mechanism Analysis
The Mantis Shrimp is an incredible creature that has one of the most optimized linkage mechanisms
found in nature. The linkage allows the Mantis Shrimp to strike its prey (or unfortunate victims) with
around 1500 N of instantaneous strike force, not to mention the shockwave caused by the cavitation
bubbles because the strike is so fast. It is so fast that the initial acceleration is in excess of 10,000 g’s.
The study of this mechanism and the materials involved can lead to tougher materials, improved joint
and mechanism design among other innovations. To get a better idea of how fantastic this mechanism
is, the mantis shrimp’s mechanism is analyzed using both Working Model simulation and Matlab analysis
utilizing kinematic joint constraints and also applying inverse dynamics principles to better understand
the forces at play.
To begin the analysis, the motion of the club must first be understood. According to sources, the
incredible strike of the Mantis Shrimp is composed of the following parameters
~10,400 g’s of Acceleration
~23 m/s Peak Speed
~1500 N of Instantaneous Strike Force
~800 μs Duration
According to most other widely available analysis, the mantis shrimp appendage can be approximated
using a simple 4-bar linkage. With the right dimensions and the right constraints, the actual motion of
the appendage can be estimated. A figure similar to the one used to approximate the linkage
dimensions are shown in Figure 1. For those familiar with linkage analysis, it can be seen that for a small
input angle, there is a large output angle. This is used to the shrimp’s advantage to generate the
massive acceleration.
Figure 1. Schematic of a Mantis Shrimp claw. A generalized linkage is superimposed over it to show the
general 4-bar analogy.
To get a first estimate of the motion, the linkage is modeled first in Working Model using the
approximated dimensions of the links and output length. This is shown in Figure 2. However, to have an
accurate simulation the external forces must be considered. Because the linkage is under water and
ME 481
Final Project
Henry Arneson
because the linkage undergoes such drastic changes in velocity, it is not correct to assume that the
viscous drag of water is negligible (and it usually isn’t).
Figure 2. Working Model Drawing of the strike linkage
To simulate the force of drag, the standard equation for drag is used shown by Equation 1. This
equation shows a direct relationship of the opposing drag force to the square of the velocity. Given the
scale of the velocity and despite the small size of the accelerating component, the drag force is a major
contributor to the dynamics of the linkage. In fact, the drag force is calculated to be ~19.5 N which is
almost 10 times the actual weight of the shrimp!
Where FD is the viscous drag force, ρ is the density of water, CD is the drag coefficient (here I assumed it
to be that of a sphere ~0.47) and A is the area.
It is not enough to have just the drag force. In designing the simulation, how the force is applied is
critical. While drag is applied across all moving bodies, for the sake of simplicity, the magnitude of the
drag force is assumed to happen at the end of the club, which is reasonable given that it is the fastest
moving component. The direction of the force is normal to the moving face. In the beginning the force
was modeled as a constant force (the drag force at maximum velocity). A plot of the resulting velocity
and acceleration are shown in Figure 3. It can be seen that this is incorrect for a few reasons. For one,
the velocity vastly overshoots 23 m/s. What is also important to note is that the acceleration starts at a
base value of 9000 g’s and continues to increase, which is incorrect (it should start high and decrease as
the drag ‘increases’). One small benefit to this method is that the force can be defined as being
perpendicular to the face of the club, which is why it was one of the initial options.
ME 481
Final Project
Henry Arneson
Figure 3. Kinematics of the club using a constant opposing force
Another way to simulate the drag on the club is to use the air-resistance option supplied by WM. This
option is structured similar to the form of viscous fluid drag and is shown in Equation 2 along with the
equivalent parameters to make it similar to water viscous drag. However, this option had problems as
well. Using the machine available at the time, this simulation initially showed almost infinite
accelerations at start-up, which led to distrust of this method (the assumption was that because if the
“fluid” was still air, there would be errors for such large initial accelerations). However, subsequent
simulations on more capable machines have shown this method to be very capable. A plot of the
resulting velocities and accelerations is shown in Figure 4.
Where k is a drag coefficient with units of kg/cm2
ME 481
Final Project
Henry Arneson
Figure 4. Kinematics of the club using WM “air resistance” simulation
It is because of the initial issues with the air-resistance that the third option was chosen. Looking at the
motion of the linkage in the accelerating range, it is apparent that there is only a small change in the
vertical displacement of the club. Using that advantage, a damper can reasonably be used to simulate
viscous drag. Equation 3 is used as the parameters for the damper to match the viscous drag force of
19.5 N at the peak velocity calculated in Equation 1. The resulting velocities and accelerations are
shown in Figure 5.
Figure 5. Kinematics of the club using a damper to simulate viscous drag
ME 481
Final Project
Henry Arneson
Another force to note is the internal driving force. Most sources concur that a big factor of driving the
mechanism is a special saddle shaped spring that is flexed as the appendage “winds” up. This is not
entirely accurate as it turns out that there are many other components that store energy such as
deflection in some of the joints and linkages as well as energy being stored in tissues surrounding the
mechanism. However, for the purpose of this simulation, a spring is used to simulate the saddle. What
is incredible is that for an estimated stroke of the spring of about 0.3-0.4 cm, the required spring
constant to achieve the motion turned to be ~9000 N/cm!
There are many reasons to use a numerical analysis in Matlab. It is a good sanity check and it can also
be extended to solve for other parameters such as joint force. To perform the joint constraint
kinematics in Matlab, there are a few assumptions that must be established. These assumptions are
shown in Figure 6. The first is the constant acceleration of the input link, which is taken from the results
of the Working Model simulation. This assumption holds true until the output reaches the peak velocity,
but until that point (which is roughly 550 μs), this can still give good insight to the kinematics and
dynamics of the linkage. The next assumption is the drag force which is simulated to be directly
perpendicular to the end of the output link. This force uses the same relationship as the damper chosen
before. For the inverse dynamics the input force is pure torque. It is also good to note that the entire
mass of link 3 is assumed to be at the end. This is to analyze forces at the end of the link.
Figure 6. A schematic of the dimensions and assumptions used for the Matlab analysis
The final results of the Matlab simulation of the kinematics and dynamics are shown in Figures 7 and 8
respectively. They are overlaid with the Working Model for comparison.
ME 481
Final Project
Henry Arneson
Figure 7. Kinematics results of Matlab (blue) juxtaposed with the Working Model (red) simulation
Figure 8. Dynamic results of Matlab (blue) juxtaposed with the Working Model (red) simulation
Comparison
Before Given the nature of the simulations, the correlations are striking. For the most part, the
kinematics of the linkage matches very well. It is important to note that the differences in the position
ME 481
Final Project
Henry Arneson
are due to the nature of the club, in Matlab it is in line; for Working Model, it is offset. The difference
between the output vs. input plots are very small and probably due to the starting position of the
linkages, which results in the separate starting points and the difference in slope. The velocity matches
very well, until ~5.5 μs (which is the expected limit of the Matlab analysis because of the constant
acceleration assumption). However, it is unexpected that the initial acceleration is smaller than the
Working Model acceleration. An initial hypothesis may be that the misalignment between the damper
in Working Model may allow for higher acceleration, but at zero velocity, they should be closer. Another
assumption (and more likely) is the allocation of mass. In the Matlab simulation, for the purpose of
measuring dynamics at the club, the mass is assumed to be concentrated right at the end, which is likely
why the magnitude of the initial acceleration is smaller.
For the Dynamics, there are more pronounced differences. Specifically, this is apparent when it comes
to the joint forces. For the Matlab simulation, joints 1.2 and 2.3 are over lapping perfectly as are joints
3.4 and 4.1. This is because of the assumptions of pure torque input (Matlab) vs. the input of the spring.
This affects the link forces for 1.2 and 2.3 in the Working model simulation. Because joints 3.4 and 4.1
are more removed from this spring force, they overlap similar to how the Matlab calculations overlap. It
can be seen that the difference in the location of the center of mass for link 3 show up in the dynamics
as the forces are higher. This is especially noticeable in the input torque. Despite the differences in
these plots, it is reassuring that the trends and magnitudes are similar and lends confidence to these
models.
Comparisons aside, the magnitude of the internal forces of the joints experienced is astounding. These
values definitely do not lend themselves to a scale design of the linkage using conventional materials.
However it is important to remember that the shrimp is an optimized mechanism that isn’t perfectly
modeled using a simple 4-bar linkage. In reality there are likely many links and inputs to the linkage that
allow for the appendage to perform the way that it does.
Conclusion and Future Work
Making a perfect simulation of a biological mechanism is no simple task, but the results shown here
show great correlation to the real life parameters of the mantis shrimp strike. Improvements to the
simulation would be to add more links and inputs to both the Working Model and Matlab simulations.
One optimization to the Matlab problem would be to take the Working Model acceleration and fit a
time-based polynomial curve to the profile and see how well the improved Matlab analysis matches
Working Model. Another fascinating possibility is to predict the appearance of cavitation based upon
the Matlab results and fluid dynamics parameters.
ME 481
Final Project
Henry Arneson
Appendix: Matlab Code
Attached Code: Used to simulate the and compare the results with the WM simulation
%Simulate the shrimp punching mechanism and compare the kinematic and
%dynamic results with the WM solution.
%define the linkage (constants)
clear;
clc;
clf;
AB = 1.2193;
%length of the driver, R
phi1 = 55*(pi/180);
%radians
BC = 0.3380;
%length of the arm, L
BE = 3.5;
%length from joint B to the center of gravity of link
3
CD = 1.5269;
AD = 1.3304;
% alpha = 1.73*10^7*(pi/180);
%acceleration of the driver, R
alpha = 3.5*10^7*(pi/180);
t_step = 0.000010;
%specified time step
M = 80;
% total number of steps
E = 0.000000001;
%specified error in radians and centimeters
phi2_start = 2.1454;
%~122.88 degrees
dA = [0 -1;1 0];
R = AB;
L = BC;
alpha2 = alpha;
%rough estimates of coordinates for (1)
% q = [0;
%
2.0;
%
5.0;
0;
0.5;
0;
0.4363;
-.1745;
0];
%in the format of x,y,radians
q = [0;
0;
2.1454;
%in the format of x,y,radians
1.1258;
-1.3974;
2.1294;
-0.0199;
1.1788;
3.0486];
q_total = q;
v_total = zeros(9,1);
a_total = zeros(9,1);
f12 = zeros(M+1,1); f23 = zeros(M+1,1); f34 = zeros(M+1,1); f14 =
zeros(M+1,1);
f_drag = zeros(M+1,1);
T12 = zeros(M+1,1);
for i=1: M+1
t = (i-1)*t_step;
k = 0;
BIGphi = ones(9,1);
while max(abs(BIGphi))>E
ME 481
Final Project
Henry Arneson
r2 = [q(1);q(2)];
r3 = [q(4);q(5)];
r4 = [q(7);q(8)];
phi2 = q(3);
phi3 = q(6);
phi4 = q(9);
A2 = [cos(phi2), -sin(phi2);
sin(phi2), cos(phi2)];
A3 = [cos(phi3), -sin(phi3);
sin(phi3), cos(phi3)];
A4 = [cos(phi4), -sin(phi4);
sin(phi4), cos(phi4)];
B2 = dA * A2;
B3 = dA * A3;
B4 = dA * A4;
%configure the blueprint information
s2pa = [0;0];
s2pb = [R;0];
s3pb = [BE;0];
s3pc = [L+BE;0];
s4pc = [-CD/2;0];
s4pd = [CD/2;0];
r1a = [0;0];
r2a = r2 + A2*s2pa;
r2b = r2 + A2*s2pb;
r3b = r3 + A3*s3pb;
r3c = r3 + A3*s3pc;
r4c = r4 + A4*s4pc;
r1d = [AD*cos(phi1);AD*sin(phi1)];
r4d = r4 + A4*s4pd;
%define the Capital PHI
BIGphi = [r2a-r1a ; r3b-r2b ; r4c - r3c ; r4d - r1d ; phi2 - phi2_start alpha2*t^2];
%define the Jacobian for the problem
JAC = zeros(9,9);
JAC(1:2,1:3) = [ eye(2) B2*s2pa];
JAC(3:4,1:3) = [-eye(2) -B2*s2pb];
JAC(3:4,4:6) = [eye(2) B3*s3pb];
JAC(5:6,4:6) = [-eye(2) -B3*s3pc];
JAC(5:6,7:9) = [eye(2) B4*s4pc];
JAC(7:8,7:9) = [eye(2) B4*s4pd];
JAC(9,3) = 1;
%implement the algorithm
dq = inv(JAC)*BIGphi;
if k==0
dq = zeros(9,1);
ME 481
Final Project
Henry Arneson
end
q = q-dq;
k = k+1;
if k==30
break;
end
end
q_total = horzcat(q_total,q);
%determine the velocity and acceleration RHS's
v_rhs =
[0;
0; 0;
0;
0; 0;
0;
0; alpha2*t];
q_vel
phi2p
phi3p
phi4p
=
=
=
=
a_rhs =
inv(JAC)*v_rhs;
q_vel(3);
q_vel(6);
q_vel(9);
[phi2p^2*A2*s2pa;
phi3p^2*A3*s3pb-phi2p^2*A2*s2pb;
phi4p^2*A4*s4pc-phi3p^2*A3*s3pc;
phi4p^2*A4*s4pd;
alpha2];
q_accel = inv(JAC)*a_rhs;
%Begin the Force Analysis
%Define the parameters
m3 = 0.003005;%kg
m2 = 0.0000017;%kg
m4 = 0.000022;%kg
jg2 = 1.5625*10^-7;%kgcm^2
jg3 = 3.2994*10^-4;%kgcm^2
jg4 = 5.625*10^-6;%kgcm^2
%extract from the dynamic data
theta2 = q(3); theta3 = q(6); theta4 = q(9);
omega2 = q_vel(3); omega3 = q_vel(6); omega4 = q_vel(9);
alpha2 = q_accel(3); alpha3 = q_accel(6); alpha4 = q_accel(9);
vg2x = q_vel(1); vg2y = q_vel(2); vg3x = q_vel(4); vg3y = q_vel(5); vg4x =
q_vel(7); vg4y = q_vel(8);
ag2x = q_accel(1); ag2y = q_accel(2); ag3x = q_accel(4); ag3y = q_accel(5);
ag4x = q_accel(7); ag4y = q_accel(8);
vg3 = (vg3x^2+vg3y^2)^0.5;
ag3 = (ag3x^2+ag3y^2)^0.5;
F = 0.000004*vg3^2;
%Construct the internal forces A matrix
A_f = zeros(9);
A_f(1:2,1:4) = [eye(2) -eye(2)];
A_f(3,3:4) = [AB*sin(theta2) -AB*cos(theta2)];
A_f(3,9) = 1;
A_f(4:5,3:6) = [eye(2) -eye(2)];
ME 481
Final Project
Henry Arneson
A_f(6,3:6) = [-BE*sin(theta3) BE*cos(theta3) (BE+BC)*sin(theta3) (BE+BC)*cos(theta3)];
A_f(7:8,5:8) = [eye(2) eye(2)];
A_f(9,5:8) = [-CD/2*sin(theta4) CD/2*cos(theta4) CD/2*sin(theta4) CD/2*cos(theta4)];
%Construct the external forces B vector
B_f = zeros(9,1);
B_f(2) = -(m2*981)/100;
B_f(3) = jg2*alpha2;
B_f(4) = (m3*ag3x)/100-F*cos(pi/2-theta3);
B_f(5) = (m2*ag3y)/100-F*sin(pi/2-theta3)-(m3*981)/100;
B_f(6) = jg3*alpha3;
B_f(7) = (m4*ag4x)/100;
B_f(8) = (m4*ag4y-m4*981)/100;
B_f(9) = jg4*alpha4;
%perform matrix magic
forces = A_f\B_f;
%extract values
f12x = forces(1); f12y = forces(2); f23x = forces(3); f23y = forces(4);
f34x = forces(5); f34y = forces(6); f14x = forces(7); f14y = forces(8);
f12(i) = (f12x^2+f12y^2)^0.5;
f23(i) = (f23x^2+f23y^2)^0.5;
f34(i) = (f34x^2+f34y^2)^0.5;
f14(i) = (f14x^2+f14y^2)^0.5;
T12(i) = forces(9);
f_drag(i) = F;
%consolidate velocity and acceleration data
v_total = horzcat(v_total,q_vel);
a_total = horzcat(a_total,q_accel);
club_vel = (q_vel(4)^2+q_vel(5)^2)^0.5;
club_acc = (q_accel(4)^2+q_accel(5)^2)^0.5;
club_accGs = club_acc/981;
end
q_total = q_total(1:end,2:end);
v_total = v_total(1:end,2:end);
a_total = a_total(1:end,2:end);
time = (0:t_step:M*t_step).*1000000;
x_pos
x_pos
y_pos
y_pos
=
=
=
=
q_total(4,:)';
x_pos-x_pos(1);
q_total(5,:)';
y_pos-y_pos(1);
input = q_total(3,:)'; input = input-input(1);
output = q_total(6,:)'; output = output-output(1);
x_vel = v_total(4,:)';
y_vel = v_total(5,:)';
ME 481
Final Project
total_vel = (x_vel.^2 + y_vel.^2).^0.5/100;
x_acc = a_total(4,:)';
y_acc = a_total(5,:)';
total_acc = ((x_acc.^2 + y_acc.^2).^0.5)./981;
calc_acc = zeros((M-1),1);
for i=1:M
calc_acc(i) = (total_vel(i+1)-total_vel(i))/t_step/9.81;
end
load MantisPunchDragFinal.dta
tF = MantisPunchDragFinal(:,1).*1000000;
inF = MantisPunchDragFinal(:,2); inF = inF-inF(1);
outF = MantisPunchDragFinal(:,4); outF = outF-outF(1);
velF = MantisPunchDragFinal(:,12)./100;
accF = (MantisPunchDragFinal(:,17)./981);
inFacc = (MantisPunchDragFinal(:,20));
xF = MantisPunchDragFinal(:,6);
xF = xF-xF(1);
yF = MantisPunchDragFinal(:,7);
yF = yF-yF(1);
TF = MantisPunchDragFinal(:,22).*sind(65);
dragF = MantisPunchDragFinal(:,24);
impactfF = m3*velF/(t_step*5);
pin12 = MantisPunchDragFinal(:,28);
pin23 = MantisPunchDragFinal(:,32);
pin34 = MantisPunchDragFinal(:,36);
pin41 = MantisPunchDragFinal(:,40);
figure(1)
subplot(1,4,1)
plot(x_pos,y_pos,'b',xF,yF,'r')
title('Position')
xlabel('Lateral (cm)')
ylabel('Vertical (cm)')
legend('Matlab','W.Model')
axis([-2 0 -3 3])
axis('equal')
subplot(1,4,2)
plot(input.*(180/pi),output.*(180/pi),'b',inF,outF,'r')
title('Output Vs Input')
xlabel('Degrees')
ylabel('Degrees')
legend('Matlab','W.Model')
axis([0 10 -40 0])
axis('equal')
Henry Arneson
ME 481
Final Project
Henry Arneson
subplot(1,4,3)
plot(time,total_vel,'b',tF,velF,'r')
title('Velocity')
xlabel('Time (us)')
legend('Matlab','W.Model')
ylabel('Velocity (m/s)')
axis([0 800 0 50])
subplot(1,4,4)
plot(time,total_acc,'b',tF,accF,'r')
title('Acceleration')
xlabel('Time (us)')
ylabel('Acceleration (g_s)')
legend('Matlab','W.Model')
axis([0 800 0 10000])
figure(2)
subplot(1,4,1)
plot(time,f12,'k',time,f23,'b',time,f34,'m',time,f14,'g',tF,pin12,'k-',tF,pin23,'b--',tF,pin34,'m--',tF,pin41,'g--')
xlabel('Time (us)')
ylabel('Force (N)')
legend('1.2 Matlab','2.3 Matlab','3.4 Matlab','4.1 Matlab','1.2 W.M.','2.3
W.M.','3.4 W.M.','4.1 W.M.')
title('Joint Force')
axis([0 800 0 5000])
subplot(1,4,2)
plot(time,T12,'b',tF,-TF,'r')
xlabel('Time (ms)')
ylabel('Torque(Ncm)')
legend('Matlab','W.Model')
title('Input Torque')
axis([0 800 0 5000])
subplot(1,4,3)
plot(time,f_drag,'b',tF,-dragF,'r')
xlabel('Time (us)')
ylabel('Force (N)')
legend('Matlab','W.Model')
title('Drag')
axis([0 800 0 40])
subplot(1,4,4)
plot(time,m3*total_vel/(t_step*5),'b',tF,impactfF,'r')
xlabel('Time (us)')
ylabel('Striking Force(N)')
legend('Matlab','W.Model')
title('Impact Force')
axis([0 800 0 1500])
%end of code
Joseph Bartolai
ME 481
Project Report
Introduction
I became interested in comparing the kinematics of my knee to the Breg Fusion XT knee brace
after learning that the human knee can be modeled as a four bar mechanism. I tore my left
Anterior Cruciate Ligament (ACL) in spring of 2013 and underwent ACL reconstruction surgery to
replace the damaged ligament. I wear a Breg Fusion XT on my left knee for athletic activities as
a means of preventing another injury. The brace often becomes misaligned during athletic
activity, particularly when running and changing direction. This misalignment is usually the brace
sliding down my leg, toward the tibia. To determine what was causing this misalignment, the
kinematics of my knee and the brace were compared. The results of this comparison are detailed
in this report.
Model Development: Human Knee
To create an analytical model, a post-surgery x-ray image of my knee was used to approximate
the endpoints of the ACL and Posterior Cruciate Ligament (PCL). This x-ray is shown in Figure 1.
These ligament endpoints were placed with the assistance of a graduate student studying
physical therapy with a concentration in athletic rehabilitation. The ligament endpoints were
used to create the four-bar mechanism. The thickness of the patella was used as a reference
dimension. According to the CDC, the average American Non-Hispanic White male between the
ages of 20 and 39 years is 70.2 inches tall and weighs 194.7 pounds.[1] At 70 inches tall and 190
pounds, I assumed myself close enough to the mean values to use the mean patella thickness as
a basis for scaling the x-ray image. As reported by Iranpour et al, the average male Patella
thickness is 22.4 millimeters.[2] The link lengths determined with this method are shown in Table
1.
ACL
PCL
Figure 1: Post-surgery x-ray of left knee. Approximate ACL location
shown in green. Approximate PCL location shown in yellow.
Table 1: Knee four-bar mechanism initial link lengths
Link
Length
Tibia
10.7 mm
PCL
15.14 mm
Femur
10.7 mm
ACL
18.53 mm
To create the four-bar mechanism, the Tibia between the PCL and ACL attachment points was
used as the ground link. The PCL was used as link 2, which was used to analytically drive the
mechanism. Link 3 was the Femur between the PCL and ACL attachment points. The ACL was
link 4. To allow the mechanism to more accurately simulate the motion of the human knee, the
length of link 4 (ACL) was reduced linearly with PCL rotation, with a total reduction of 30% of
initial length.
The complex number vector loop method was used to analyze the kinematics of the knee fourbar. The vector loop can be seen in Figure 2. These equations were evaluated using MATLAB.
Using the PCL as the driver link, the mechanism was driven to result in an 85 degree rotation of
the femur relative to the Tibia. Initial and final mechanism positions can be seen in Figures 3 and
4.
Figure 3: Knee four-bar linkage and vector loop diagrams.
20
Tibia
PCL
Femur
ACL
18
16
14
Y (mm)
12
10
8
6
4
2
0
-5
0
5
10
X (mm)
Figure 2: Knee four-bar, initial position: extended
15
20
16
Tibia
PCL
Femur
ACL
14
12
Y (mm)
10
8
6
4
2
0
-2
-10
-5
0
5
10
X (mm)
Figure 4: Knee four-bar, final position: retracted 85 degrees
Model Development: Breg Fusion XT
The Breg Fusion XT knee brace, shown mounted to my leg in Figure 5, operates as a three link
open loop mechanism. For similarity with the knee analytical model, the link mounted adjacent
to the Tibia was used as the ground link. The upper link, mounted adjacent to the femur, is
connected to the ground link by a connector link with rotational joints at each end and by a nonslip rotation. This non-slip rotation is caused by meshed gears at the interface between the upper
and lower links. The connector link connects the upper and lower link at the center of these
gears, ensuring the center to center distance remains constant. In the analytical model, the angle
of the upper link was kept the same as the femur angle for each calculation step in the knee fourbar model. This resulted in the same 85 degree rotation. Initial and final mechanism positions
can be seen in Figures 6 and 7.
Figure 6: Breg Fusion XT knee brace, shown mounted to left leg
20
Y (mm)
15
10
5
0
-5
0
5
10
15
20
X (mm)
Figure 5: Analytical Breg Fusion XT knee brace, shown in initial position: extended
25
20
Y (mm)
15
10
5
0
-10
-5
0
5
X (mm)
10
15
20
Figure 7: Analytical Breg Fusion XT knee brace, shown in final position: retracted 85 degrees
Kinematic Comparison
Initial and final positons of the knee brace are projected over the knee four-bar in Figures 8 and
9. The relative positions of the femur in the knee for-bar and upper link in the knee brace are
shown to change 5.6 mm between the initial and finial positions. This is likely the cause of the
misalignment of the knee brace relative to my leg. If friction between the upper brace and my
leg is greater than that of the lower brace, the brace would move relative to my leg. This
movement is likely the cause of the misalignment.
30
25
20
Y (mm)
15
10
5
0
-5
-10
-20
-15
-10
-5
0
X (mm)
5
10
15
20
Figure 8: Initial position analytical solution comparison
25
20
Y (mm)
15
10
5
0
-15
-10
-5
0
5
10
15
X (mm)
Figure 9: Final position analytical solution comparison
20
Instant Center of Rotation Comparison
In the ideal case, the upper and lower parts of the knee brace would rotate about the same point
as the tibia and femur. These points of rotation, known as instant centers, can be found for a
four-bar mechanism using the Kennedy-Aronhold theorem. Instant centers for the knee four-bar
are shown in Figure 10. For rolling contact, the instant center of rotation is always at the point
of contact. Instant centers for the knee brace are shown in Figure 11. A comparison of the locus
of instant centers of the knee four-bar and the knee brace is shown in Figure 12. As shown, the
instant centers of rotation do not match. If a brace were to be constructed so that the instant
center matched for each tibia-femur angle, any misalignments would be prevented.
15
Y (mm)
10
5
0
-8
-6
-4
-2
0
2
X (mm)
4
6
8
10
Figure 10: Analytical knee four-bar in final position with instant centers for each calculation point shown with a black "x"
25
20
Y (mm)
15
10
5
0
-10
-5
0
5
X (mm)
10
15
20
Figure 11: Analytical knee brace in final position with instant centers for each calculation point shown with a black "x"
knee four-bar
knee brace
10
9
Y (mm)
8
7
6
5
4
3
-1
0
1
2
3
4
5
X (mm)
6
7
8
9
Figure 12: Locus of instant centers for both analytical knee four-bar (x) and analytical knee brace (o)
Conclusion
The 5.6mm difference in position between similar points on the femur and the knee brace at full
retraction is likely the cause of the misalignments I have experienced. A smaller pitch diameter
for the geared sections of the brace would improve the fit, but a brace that matches the locus of
instant centers of the knee four-bar would perform best. However, this may require that the
brace also be a four bar mechanism. This would be more expensive to produce but I feel that the
improvement in performance would justify the additional expense.
Suggestions for Further Analysis
The analytical model presented here could be improved in two key areas. The first is the ACL
shortening algorithm. The shortening of the ACL was assumed to be linear. This may not be the
case. A comparison of both extended and retracted x-rays would help build a better model. As
both were not available at the time of this analysis, linear length reduction was assumed. The
PCL will also change length. This change in length was not considered in this analysis.
Sources
1. Fryar CD, Gu Q, Ogden CL. Anthropometric reference data for children and adults: United
States, 2007–2010. National Center for Health Statistics. Vital Health Stat 11(252). 2012.
2. Iranpour, Farhad, MD, Azhar M. Merican, MS, Andrew A. Amis, DSc, and Justin P. Cobb, MCh,
FRCS. "The Width : thickness Ratio of the Patella." Clinical Orthopaedics and Related Research
466.5 (2008): 1198-1203. Web
3. Sommer, H. J., III, Ph.D. ME 481 Computer-Aided Analysis of Machine Dynamics - Spring. The
Pennsylvania
State
University,
n.d.
Web.
06
May
2015.
<http://www.mne.psu.edu/sommer/me481/>.
4. Norton, Robert L. Design of Machinery: An Introduction to the Synthesis and Analysis of
Mechanisms and Machines. New York: McGraw-Hill, 2012. Print.
Appendix – MATLAB code
% Joseph Bartolai
% ME 481
% Project Knee four bar / breg XL brace comparison
%% Knee Dimensions
% pixel locations
Apx=[183 786];
%PCL,
Bpx=[244 665];
%PCL,
Cpx=[160 619];
%ACL,
Dpx=[269 744];
%ACL,
tibia
femur
femur
tibia
Hdir=[98 353; 78 312]; %femur direction, pixels
Tdir=[116 240; 89 169]; %tibia direction, pixels
%scale form pixels to mm
pttpx=[464 596; 392 579]; %patella thicnkess endpoints, pixels
ptavg=22.4;
%average patella thickness, mm
SR=ptavg/(sqrt((pttpx(2,1)-pttpx(1,1))^2+(pttpx(2,2)-pttpx(2,1))^2)); %pixels
to mm ratio
%tibia global unit vector
Tu=(Tdir(2,:)-Tdir(1,:));
Tu(2)=-Tu(2);
%correct for mspaint y inversion
Tu=Tu/sqrt(Tu(1)^2+Tu(2)^2); %tibia unit vector wrt image coords y axis
%tibia mechanism local unit vector
Lu=(Dpx-Apx);
Lu(2)=-Lu(2); %correct for mspaint inverted y
Lu=Lu/sqrt(Lu(1)^2+Lu(2)^2); %mechanism local unit vector wrt image coords
%mechanism to global (tibia based) coordinates rotation matrix
Gxy=[cos(atan2(Lu(2),Lu(1))-atan2(-Tu(1),Tu(2))) -sin(atan2(Lu(2),Lu(1))atan2(-Tu(1),Tu(2))); %note:Tu inverted in atan2 to switch y unit vector to
x unit vector
sin(atan2(Lu(2),Lu(1))-atan2(-Tu(1),Tu(2))) cos(atan2(Lu(2),Lu(1))atan2(-Tu(1),Tu(2)))];
%femur global unit vector
Hu=(Hdir(2,:)-Hdir(1,:));
Hu(2)=-Hu(2);
%correct for mspaint y inversion
Hu=Hu/sqrt(Hu(1)^2+Hu(2)^2); %femur unit vector wrt image coords y axis
HLu=(Bpx-Cpx);
HLu(2)=-HLu(2); %correct for mspaint inverted y
HLu=HLu/sqrt(HLu(1)^2+HLu(2)^2); %mechanism local unit vector wrt image
coords
%femur link to global femur rotation matrix
Hxy=[cos(atan2(HLu(2),HLu(1))-atan2(Hu(2),Hu(1))) -sin(atan2(HLu(2),HLu(1))atan2(Hu(2),Hu(1)));
sin(atan2(HLu(2),HLu(1))-atan2(Hu(2),Hu(1))) cos(atan2(HLu(2),HLu(1))atan2(Hu(2),Hu(1)))];
%link lengths
r1 = SR*sqrt((Dpx(2)-Apx(2))^2+(Dpx(1)-Apx(1))^2); %tibia, distance between
ACL and PCL
r2 = SR*sqrt((Bpx(2)-Apx(2))^2+(Bpx(1)-Apx(1))^2); %PCL length
r3 = SR*sqrt((Cpx(2)-Bpx(2))^2+(Cpx(1)-Bpx(1))^2); %femur, distance between
ACL and PCL
r4 = SR*sqrt((Dpx(2)-Cpx(2))^2+(Dpx(1)-Cpx(1))^2); %ACL length
%% Knee four bar - vector loop solution
r4 = SR*sqrt((Dpx(2)-Cpx(2))^2+(Dpx(1)-Cpx(1))^2);
%mechanism orgin at tibia-PCL joint
O=[0 0];
%PCL angle used as driver
t2min=32;
%min PCL angle,degrees
t2max=93;
%max PCL angle,degrees
cpd=1;
%calc points per degree
%kk=1
for kk=1:((t2max-t2min+1)*cpd)
t2(kk)=t2min+((kk-1)/cpd);
%r4 retraction factor
r4t=0.3;
r4=r4-r4t*((kk-1)/((t2max-t2min)*cpd));
K1=r1/r2;
K2=r1/r4;
K3=(r2^2-r3^2+r4^2+r1^2)/(2*r2*r4);
K4=r1/r3;
K5=(r4^2-r1^2-r2^2-r3^2)/(2*r2*r3);
AA=cosd(t2(kk))-K1-K2*cosd(t2(kk))+K3;
%ACL length
BB=-2*sind(t2(kk));
CC=K1-(K2+1)*cosd(t2(kk))+K3;
DD=cosd(t2(kk))-K1+K4*cosd(t2(kk))+K5;
EE=BB;
FF=K1+(K4-1)*cosd(t2(kk))+K5;
t3(kk)=2*atan2(2*DD,(-EE-sqrt(EE^2-(4*DD*FF))))*180/pi;
t4(kk)=2*atan2(2*AA,(-BB-sqrt(BB^2-(4*AA*CC))))*180/pi;
Ap(kk,:)=[O(1) O(2)];
%position of point A
Bp(kk,:)=O+[r2*cosd(t2(kk)) r2*sind(t2(kk))]*Gxy;
%position of point B
Cp(kk,:)=Bp(kk,:)+[r3*cosd(t3(kk)) r3*sind(t3(kk))]*Gxy;
%position of
point C
Dp(kk,:)=O+[r1 0]*Gxy;
%position of point D
%find tibia - femur instant center
if (((Ap(kk,1)-Bp(kk,1))*(Cp(kk,2)-Dp(kk,2)))-((Ap(kk,2)Bp(kk,2))*(Cp(kk,1)-Dp(kk,1)))) ~= 0
ICk(kk,1)=((((Ap(kk,1)*Bp(kk,2))-(Ap(kk,2)*Bp(kk,1)))*(Cp(kk,1)Dp(kk,1)))-(((Ap(kk,1)-Bp(kk,1))*((Cp(kk,1)*Dp(kk,2))(Cp(kk,2)*Dp(kk,1))))))/(((Ap(kk,1)-Bp(kk,1))*(Cp(kk,2)-Dp(kk,2)))((Ap(kk,2)-Bp(kk,2))*(Cp(kk,1)-Dp(kk,1))));
ICk(kk,2)=((((Ap(kk,1)*Bp(kk,2))-(Ap(kk,2)*Bp(kk,1)))*(Cp(kk,2)Dp(kk,2)))-(((Ap(kk,2)-Bp(kk,2))*((Cp(kk,1)*Dp(kk,2))(Cp(kk,2)*Dp(kk,1))))))/(((Ap(kk,1)-Bp(kk,1))*(Cp(kk,2)-Dp(kk,2)))((Ap(kk,2)-Bp(kk,2))*(Cp(kk,1)-Dp(kk,1))));
end
%femur y-axis unit vector
Huy(kk,:)=Bp(kk,:)-Cp(kk,:);
Huy(kk,:)=(Huy(kk,:)/sqrt(Huy(kk,1)^2+Huy(kk,2)^2))*Hxy;
end
figure(1)
hold on
xlabel('X (mm)')
ylabel('Y (mm)')
axis equal
plot([Ap(1,1) Dp(1,1)], [Ap(1,2) Dp(1,2)],'k')
plot([Ap(1,1) Bp(1,1)],[Ap(1,2) Bp(1,2)],'b')
plot([Cp(1,1) Bp(1,1)], [Cp(1,2) Bp(1,2)],'k')
plot([Cp(1,1) Dp(1,1)],[Cp(1,2) Dp(1,2)],'g')
%plot(ICk(1,1),ICk(1,2),'kx')
legend('Tibia','PCL','Femur','ACL')%,'Instant Center')
plot([Cp(1,1) Cp(1,1)+Huy(1,1)*5],[Cp(1,2) Cp(1,2)+Huy(1,2)*5],'r')
figure(2)
hold on
axis equal
xlabel('X (mm)')
ylabel('Y (mm)')
plot([Ap(kk,1) Dp(kk,1)], [Ap(kk,2) Dp(kk,2)],'k')
plot([Ap(kk,1) Bp(kk,1)],[Ap(kk,2) Bp(kk,2)],'b')
plot([Cp(kk,1) Bp(kk,1)], [Cp(kk,2) Bp(kk,2)],'k')
plot([Cp(kk,1) Dp(kk,1)],[Cp(kk,2) Dp(kk,2)],'g')
%plot(ICk(kk,1),ICk(kk,2),'kx')
legend('Tibia','PCL','Femur','ACL')%,'Instant Center')
plot([Cp(kk,1) Cp(kk,1)+Huy(kk,1)*5],[Cp(kk,2) Cp(kk,2)+Huy(kk,2)*5],'r')
%% Knee Brace Kinematics
Bcent=[7 -4]; %brace link 1 center
Br2=24.08; %link 2 length,mm
Br1=Br2/2; %link 1 pitch radius, mm
Br3=Br1; %link 3 pitch radius, mm
Bt3=atan2(Huy(:,2),Huy(:,1))*180/pi; %link 3 angle same as humorous
%Bt3=100;
Bt2=(Bt3-90)/2+90;
%no-slip rolling between link 1
and link 3, link 2 angle is half of link 2 angle
%draw semicircle
for kk=1:length(Bt3)
for zz=1:181
cir1(zz,:,kk)=[cosd(zz-1) sind(zz-1)];
cir2(zz,:,kk)=[cosd(zz-1+(Bt3(kk)+90)) sind(zz-1+(Bt3(kk)+90))];
end
Bc1(:,1,kk)=cir1(:,1,kk)*Br1+Bcent(1);
Bc1(:,2,kk)=cir1(:,2,kk)*Br1+Bcent(2);
Bc3(:,1,kk)=cir2(:,1,kk)*Br3+Bcent(1)+Br2*cosd(Bt2(kk));
Bc3(:,2,kk)=cir2(:,2,kk)*Br3+Bcent(2)+Br2*sind(Bt2(kk));
ICb(kk,:)=[Bcent(1)+Br2*cosd(Bt2(kk))/2 Bcent(2)+Br2*sind(Bt2(kk))/2];
end
figure(4)
hold on
axis equal
xlabel('X (mm)')
ylabel('Y (mm)')
plot(Bc1(:,1,1),Bc1(:,2,1))
plot([Bcent(1) Bcent(1)+Br2*cosd(Bt2(1))],[Bcent(2)
Bcent(2)+Br2*sind(Bt2(1))])
plot(Bc3(:,1,1),Bc3(:,2,1))
plot(ICb(1,1),ICb(1,2),'ko')
figure(5)
hold on
axis equal
xlabel('X (mm)')
ylabel('Y (mm)')
plot(Bc1(:,1,kk),Bc1(:,2,kk))
plot([Bcent(1) Bcent(1)+Br2*cosd(Bt2(kk))],[Bcent(2)
Bcent(2)+Br2*sind(Bt2(kk))])
plot(Bc3(:,1,kk),Bc3(:,2,kk))
plot(ICb(kk,1),ICb(kk,2),'ko')
%% figures
figure(6)
hold on
axis equal
xlabel('X (mm)')
ylabel('Y (mm)')
axis ([-20 20 -10 30])
plot([Ap(1,1) Dp(1,1)], [Ap(1,2) Dp(1,2)],'k')
plot([Ap(1,1) Bp(1,1)],[Ap(1,2) Bp(1,2)],'b')
plot([Cp(1,1) Bp(1,1)], [Cp(1,2) Bp(1,2)],'k')
plot([Cp(1,1) Dp(1,1)],[Cp(1,2) Dp(1,2)],'g')
plot(Bc1(:,1,1),Bc1(:,2,1))
plot([Bcent(1) Bcent(1)+Br2*cosd(Bt2(1))],[Bcent(2)
Bcent(2)+Br2*sind(Bt2(1))])
plot(Bc3(:,1,1),Bc3(:,2,1))
%plot(ICk(1,1),ICk(1,2),'kx')
%legend('Tibia','PCL','Humorous','ACL')%,'Instant Center')
plot([Cp(1,1) Cp(1,1)+Huy(1,1)*5],[Cp(1,2) Cp(1,2)+Huy(1,2)*5],'r')
figure(7)
hold on
axis equal
xlabel('X (mm)')
ylabel('Y (mm)')
plot([Ap(kk,1) Dp(kk,1)], [Ap(kk,2) Dp(kk,2)],'k')
plot([Ap(kk,1) Bp(kk,1)],[Ap(kk,2) Bp(kk,2)],'b')
plot([Cp(kk,1) Bp(kk,1)], [Cp(kk,2) Bp(kk,2)],'k')
plot([Cp(kk,1) Dp(kk,1)],[Cp(kk,2) Dp(kk,2)],'g')
plot(Bc1(:,1,kk),Bc1(:,2,kk))
plot([Bcent(1) Bcent(1)+Br2*cosd(Bt2(kk))],[Bcent(2)
Bcent(2)+Br2*sind(Bt2(kk))])
plot(Bc3(:,1,kk),Bc3(:,2,kk))
%plot(ICk(kk,1),ICk(kk,2),'kx')
%legend('Tibia','PCL','Humorous','ACL','Instant Center')
plot([Cp(kk,1) Cp(kk,1)+Huy(kk,1)*5],[Cp(kk,2) Cp(kk,2)+Huy(kk,2)*5],'r')
figure(8)
hold on
axis equal
xlabel('X (mm)')
ylabel('Y (mm)')
plot([Ap(kk,1) Dp(kk,1)], [Ap(kk,2) Dp(kk,2)],'k')
plot([Ap(kk,1) Bp(kk,1)],[Ap(kk,2) Bp(kk,2)],'b')
plot([Cp(kk,1) Bp(kk,1)], [Cp(kk,2) Bp(kk,2)],'k')
plot([Cp(kk,1) Dp(kk,1)],[Cp(kk,2) Dp(kk,2)],'g')
plot(ICk(:,1),ICk(:,2),'kx')
figure(9)
hold on
axis equal
xlabel('X (mm)')
ylabel('Y (mm)')
plot(Bc1(:,1,kk),Bc1(:,2,kk))
plot([Bcent(1) Bcent(1)+Br2*cosd(Bt2(kk))],[Bcent(2)
Bcent(2)+Br2*sind(Bt2(kk))])
plot(Bc3(:,1,kk),Bc3(:,2,kk))
plot(ICb(:,1),ICb(:,2),'kx')
figure(10)
hold on
axis equal
xlabel('X (mm)')
ylabel('Y (mm)')
plot(ICk(:,1),ICk(:,2),'kx')
plot(ICb(:,1),ICb(:,2),'bo')
legend('knee four-bar','knee brace')
%% movie1
Mv1=VideoWriter('kn4b.avi');
open(Mv1);
figure(11)
axis ([-15 15 -10 20])
xlabel('X (mm)')
ylabel('Y (mm)')
for zz=1:(length(Ap(:,1))*2)
if zz ==(length(Ap(:,1))*2)
kk=1;
elseif zz > length(Ap(:,1))
kk = 2*length(Ap(:,1))-zz;
else
kk=zz;
end
clf
hold on
axis ([-10 20 -10 20])
xlabel('X (mm)')
ylabel('Y (mm)')
plot([Ap(kk,1) Dp(kk,1)], [Ap(kk,2) Dp(kk,2)],'k')
plot([Ap(kk,1) Bp(kk,1)],[Ap(kk,2) Bp(kk,2)],'b')
plot([Cp(kk,1) Bp(kk,1)], [Cp(kk,2) Bp(kk,2)],'k')
plot([Cp(kk,1) Dp(kk,1)],[Cp(kk,2) Dp(kk,2)],'g')
plot([Cp(kk,1) Cp(kk,1)+Huy(kk,1)*5],[Cp(kk,2) Cp(kk,2)+Huy(kk,2)*5],'r')
M1(kk)=getframe;
writeVideo(Mv1,M1(kk));
end
close(Mv1);
%% movie2
Mv2=VideoWriter('kn4br.avi');
open(Mv2);
figure(12)
xlabel('X (mm)')
ylabel('Y (mm)')
for zz=1:(length(Ap(:,1))*2)
if zz ==(length(Ap(:,1))*2)
kk=1;
elseif zz > length(Ap(:,1))
kk = 2*length(Ap(:,1))-zz;
else
kk=zz;
end
clf
hold on
axis ([-15 20 -10 25])
xlabel('X (mm)')
ylabel('Y (mm)')
plot(Bc1(:,1,kk),Bc1(:,2,kk))
plot([Bcent(1) Bcent(1)+Br2*cosd(Bt2(kk))],[Bcent(2)
Bcent(2)+Br2*sind(Bt2(kk))])
plot(Bc3(:,1,kk),Bc3(:,2,kk))
M2(kk)=getframe;
writeVideo(Mv2,M2(kk));
end
close(Mv2);
%% movie2
Mv3=VideoWriter('kn4b_all.avi');
open(Mv3);
figure(12)
xlabel('X (mm)')
ylabel('Y (mm)')
for zz=1:(length(Ap(:,1))*2)
if zz ==(length(Ap(:,1))*2)
kk=1;
elseif zz > length(Ap(:,1))
kk = 2*length(Ap(:,1))-zz;
else
kk=zz;
end
clf
hold on
axis ([-15 20 -10 25])
xlabel('X (mm)')
ylabel('Y (mm)')
plot([Ap(kk,1) Dp(kk,1)], [Ap(kk,2) Dp(kk,2)],'k')
plot([Ap(kk,1) Bp(kk,1)],[Ap(kk,2) Bp(kk,2)],'b')
plot([Cp(kk,1) Bp(kk,1)], [Cp(kk,2) Bp(kk,2)],'k')
plot([Cp(kk,1) Dp(kk,1)],[Cp(kk,2) Dp(kk,2)],'g')
plot([Cp(kk,1) Cp(kk,1)+Huy(kk,1)*5],[Cp(kk,2) Cp(kk,2)+Huy(kk,2)*5],'r')
plot(Bc1(:,1,kk),Bc1(:,2,kk))
plot([Bcent(1) Bcent(1)+Br2*cosd(Bt2(kk))],[Bcent(2)
Bcent(2)+Br2*sind(Bt2(kk))])
plot(Bc3(:,1,kk),Bc3(:,2,kk))
M3(kk)=getframe;
writeVideo(Mv3,M3(kk));
end
close(Mv3);
Hannah Goldberg and Carlos Tirado
H.J. Sommer III, Ph.D.
ME 481
06 May 2015
Final Project Report
For our ME481 final project, we decided to focus on a seemingly simple device and
investigate its inner workings. Contemplating this took time, and we thought, what
if there was no way to track time. How would we know when we have a meeting,
or an exam, or a wedding reception? Our questions led us to the idea of the clock.
So simple in its function, yet so complicated in its mechanics. We researched how
a clock works and found that there are many different types of clocks, all with one
similar part. There is a vibration of some sort that oscillates back and forth at a
constant frequency. This can be done with a pendulum, a tuning fork, a quartz
crystal, or even the vibration of electrons as they emit microwaves. As technology
improves, clocks are becoming more and more advanced. The process of making a
clock is being simplified, with less parts, and almost no more man power. The
pocket watch, developed in the 16th century, was still popular in the time of our
grandparents. The wristwatch was developed next, during the time of World War I,
for those in the military. Since then, the idea of a clock has become a seemingly
simple invention of the past, and people have forgotten that time was not always
tracked with such precision.
Only recently have clocks become as accurate as they are today. Up until the
1720’s, all clock and watch movement was based on verge escapement. This type
of movement was very high in friction and created much wear and tear on the
gears, which were not machined to prevent this. Because of this, verge
escapement was not very accurate, and usually ran fast, gaining about an hour per
day. Then the cylinder escapement and later the lever escapement in the 1820’s
were improvements that brought accuracy to about a minute per day too fast.
Some watches still use the lever escapement method today.
We decided to build an enlarged clock to display to our classmates just what goes
into a simple pendulum clock. We wanted to learn ourselves and believed that we
can inspire others to look into the mechanisms behind simple objects such as the
stapler, or mechanical pencil. The clock is a
complicated system of gears, with teeth that
create movement of 60 seconds per minute
and 60 minutes per hour and 24 hours per
day movement. The pendulum clock takes
the constant frequency oscillation of the
pendulum and transfers the motion through
the pallet to the escape wheel as seen in
figure 1. The escape wheel then turns a
system of gears, which stores the energy in a
spring that ultimately turns minute and hour
Figure 1: Pendulum Escapement Mechanism
hands.
To build the pendulum clock, we found a reasonable model to base our clock from
the web and set to analyzing it. The CAD model may be seen in figure 2. We
wanted to make our clock reasonably simple to understand by looking at it. The
gears are different colors in order to easily distinguish them from one another and
see how the gears move with ease. We 3D printed the clock gears as a way to
connect the old to the new. It proved to be very difficult when putting the clock
together, as 3D printers are not great at producing accurate pieces that fit
together. Although our 3D CAD parts fit together well in an assembly, the actual
3D printed parts were short of perfect. Aside from the inaccuracy of the
dimensions, excess support material had to be removed from the printed parts,
which was a time-intensive process. We decided to go with what we had instead of
printing out new pieces, because the printing on the MNE Department Makerbot 3D
printers in the Reber building took over two weeks to complete.
Figure 2: SolidWorks CAD Pendulum Clock Model
After taking inventory of our parts before assembling the clock, we noticed one of
the cog wheels was missing. There was only one place in town that we know of
that would be able the print the part in a timely manner and for free, the
MakeSpace. We were able to print the missing gear after numerous printing errors.
To assemble the clock, we used bolts, locking washers, and nuts to attach the 3D
printed parts to the clear acrylic structure. This was very difficult and we ran into
many issues. First, we attempted to attach it to a thick piece of wood, which did
not work because it was too thick and we wanted to be able to see through it. The
acrylic was a perfect alternative, but was very hard to drill through, and it cracked
on us a couple of times. Many clever ideas were put into the clocks components to
reduce the cost of the clock. In order to create the spring for the clock, a sliver of
aluminum about 0.25” wide was trim off a Chevy Camaro hood and wound up. A
weight was created for the pendulum using an old film canister filled with
washers. The weight of the washer is adjustable by adding and subtracting
washers.
As we made progress we came to a screeching halt when we noticed the printed
gears were not the same as in the model. In all, four cogwheels were required but
all with slight variations from each other. For our model, four identical cogwheels
were printed, this led to an error with the fitting and movement of gears. Even
with this setback, we attempted to fix our model without having to print new
parts, but ultimately this is where our physical model came to a halt.
The pendulum motion was simulated in Working Model as seen in figure 3. The
simulation was a bit troublesome to create as the importing of our escape wheel
.DXF file failed many times due unrecognizable shape by Working Model. There was
a problem with the splines in our drawing, which were ultimately converted to
polylines. Various weight values were tested to see the effects of the weight on
the system. The data was then plotted in MATLAB in a similar format as our
homework.
Figure 3: Working Model 2D Pendulum Simulation
Data was taken from the Working Model simulation on rotational position, velocity,
and acceleration of the pendulum and escape wheel. This data was plotted
together to show the respective movements of the clock’s components as seen in
figure 4. The pendulum displayed oscillatory movement, as the escape wheel
moves in repetitive step-like motions. The translation of the pendulum’s
oscillation into the mechanical start-stop rotation of the escape wheel creates the
measurement of a second. In an ideal world, pendulum clocks would oscillate
forever, but this is not the case due to rotational friction.
Figure 4: MATLAB Pendulum Data Plots
Looking back, we wish we would have begun the project sooner. As the semester
came to a close, all of our final projects were piled on us, and as we waited two
and a half weeks for our 3D printed parts, we had no idea that we were waiting for
the wrong parts! The engineering design principal of prototype fast and prototype
often really come into play here. Putting together a working model before printing
could have helped to avoid this problem, or simply by printing the parts a couple
of weeks earlier.
Although this project did not turn out exactly how we had hoped, throughout the
process so much critical experience was gained that normally would not have been
taught in the classroom. Hannah had her first experience 3D printing in the
MakeSpace downtown, and Carlos used his shop skills to try to make the
mismatched gears work even though they were printed incorrectly.
We used
machines to drill holes, cut acrylic, 3D print clock parts, and sand down low
tolerance pieces. We also learned a few points to keep in mind for the future.
Things that are free should not always be trusted. We will definitely look deeper
into what we are getting for our (lack of) money before going with it next time.
3D printers, once like clocks, are still a new invention, and they still have a long
ways to go before they have enough precision and accuracy to be reliable printers.
Until then, we must understand that 3D printers are finding their place in this
world. Another big lesson that we took out of this project is that not completing
your task is not failing, only if you give up is that failure. When we realized we
had printed the wrong parts, we didn’t give up. We pushed hard to find a solution,
first by printing another gear, and later by dealing with what we had. Not once
did we give up, until it became clear that we could not go any further.
May 5, 2015
Kite Mechanism
ME 481 Final Report
Michael Rissmiller & Kelly Johnson
Contents
Introduction ................................................................................................................................................. 2
Background Information............................................................................................................................ 2
MatLab Analysis ......................................................................................................................................... 2
Working Model Analysis ............................................................................................................................ 3
SolidWorks Analysis ................................................................................................................................... 4
Manufacturing............................................................................................................................................. 4
Appendix A: Matlab Analysis Script ........................................................................................................ 5
Appendix B: Matlab Analysis Graphs ...................................................................................................... 7
Appendix C: Working Model Figures....................................................................................................... 9
Appendix D: SolidWorks Photos ............................................................................................................. 11
Appendix E: Final Photos ........................................................................................................................ 13
1
Introduction
The objective of this project was to design, analyze and build a kite mechanism using the different methods
learned during the semester. The mechanism design constraints were analyzed with matlab, motion analysis
performed with solidworks and working model and force analysis performed with working model. The
force analysis consisted of static force analysis as well as dynamic applied motor torque analysis under
load. The purpose of this report is to describe results of the project and the steps that were necessary to
reach those results.
Background Information
A mechanical kite mechanism had been around for many years. Old
metal elevator gates are an example of kite mechanisms. These gates
represent a 5c kite mechanisms which is basically many 5b kite
mechanisms combined in series. The purpose of these mechanisms are
to transfer horizontal force input into vertical force output. The three
beams which connect the links; remain parallel when the device is being
retracted or advance. All the links are proportional, so the mechanism
can be scales for different circumstances. Recently, these mechanisms
have been used in production processes. A motor would be attached to
one end of the beams and links to allow for controlled movement. This
process can be used to move products from a higher process line to a
lower one.
Figure 1: 5c Kite Mechanism
Figure 2: 5b Kite Mechanism
MatLab Analysis
Matlab was utilized to determine the design of link 3 based on the constraints that links 1, 7 and
10 must remain parallel and link 1 undergoes purely vertical motion. The two design parameters
for link 3 were the position of the revolute V controlled by distance x from revolute Q and the
length of link 3. When the equations for the revolute joints were determined it was found that
there was 6 equations and 7 unknowns meaning that either x or the length of 3 would have to be
chosen before solving for the other. X was chosen to be half of the length of link 2. The resulting
equations of motion were solved to determine alpha, beta, theta and eta. These angles were then
in turn used to determine the length of link 3.
2
Figure 3: Free Body Diagram of Mechanism
Working Model Analysis
Working Model was used to validate that the link length and x value determined in the Matlab analysis was
valid for the motion and the constraints. By locking links 1 and 10 in the same slot, link 1 was proven to
undergo only vertical motion while remaining parallel to links 7 and 10. The slot constraint was then
relaxed so static contact force as a function of theta could be analyzed. An anchored block was placed
directly above link 1 with a horizontal force of 1000 N applied in the negative x direction on link 7 at
revolute T. The simulation was performed for angles of 15, 30, 45, 60, 75, and 85 degrees. The contact
force between link 1 and the immovable block was measured for each theta. A similar simulation was run
using a constant torque motor at revolutes O and U respectively. Contact force was again measured for
different angles. Figure 7 in the appendix shows the results for the contact force for the three different
drivers at different values of theta. The data shows that the contact force increases exponentially with
increasing theta for all three drivers. Applied torque at the origin resulted in lower contact force than
applied torque at U for all values of theta except 85 degrees. Required motor torque analysis was performed
on revolutes O and U for values of theta between 15 and 90 degrees. A 10 kg block was placed on top of
link 1. The output of this simulation was the applied motor torque as the mechanism extended. This
analysis resulted in a higher magnitude of required motor torque at revolute O than at revolute U (see Figure
6 in appendix. This means that for a more efficient system it would be advantageous to place a driving
motor at revolute U rather than O.
3
SolidWorks Analysis
The Solidworks model compiled the data taken from the Matlab and
Working Model portions. The SolidWorks model gave us a chance to see
what the kite mechanism would look like in 3D. In addition, it allowed for
the pin joints to be added to the holes. These additions allowed for the
model to be moved to verify the previous calculations are accurate. The
final model was saved off as a dxf file so the Learning Factory could read
the drawings during the manufacturing process.
Figure 4: Solidworks Isometric View
Manufacturing
The manufacturing process started by picking materials to make the beams and linkage arms.
Ideally, everything would be made out of aluminum or steel depending on the application.
Additionally, all the joints would be properly connected by non-interfering pins. Be that as it may,
we didn’t have a large budget for this project, so we tried to spend as little as possible for this
prototype. The components came free from the Learning Factory, Hammond machine shop, and
the Instrument room in Reber.
The seven linkage arms were made out of
1/16 inch sheet metal. For precision, the
linkage arms were cut using the water jet in
the Learning Factory. Many of the edges were
sharp and or had fraying, so they had to be
filed. The three horizontal beams were made
out of polycarbonate. These pieces were also
cut using the water jet to assure everything
would line up. After everything was cut, the
components were taken to the instrument
room to obtain nuts, bolts, and washers. The
assembly required number 5 flat head screws
and bolts to put everything together.
Figure 5: Final Mechanism
4
Appendix A: Matlab Analysis Script
%ME 481 Final Project
%Kelly Johnson, Michael Rissmiller
%Define Known Varibles y (total mech height at current orientation),
%Standard Link Length A
%Coordinate locations of revolute joints are with repect to the global
%origin located at revolute joint at lower left corner of mechanism.
%This solution is for a design with given x hole location.
Y=.5
A=1
x6=.5*A
Theta=asin((Y/2)/A); %Common Main link angle relative to horizontal members
Rx=A*cos(Theta);
Ry=A*sin(Theta);
Px=0; %Due to vertical motion constraint of Link P relative to O.
Py=Y;
Qx=2*A;
Qy=Y;
Tx=2*A+A*cos(Theta);
Ty=A*sin(Theta);
syms a
alpha=solve(Ty+A*sin(acos((Tx/A)-2*cos(a)))-2*A*sin(a)==0,a) %{rad}
Beta=acos((Tx/A)-2*cos(alpha)) %{rad}
syms n
Eta=solve(2*A*sin(alpha)+((-(2*Qx*cos(n)-2*Qy*sin(n)-2*x6*cos(n))+sqrt((2*Qx*cos(n)-2*Qy*sin(n)2*x6*cos(n))^2-(4*((Qy^2)+(Qx^2)+(x6^2)-2*x6*Qx-4))))/(2))*sin(n)-Qy,n)
B=((-(2*Qx*cos(Eta)-2*Qy*sin(Eta)-2*x6*cos(Eta))+sqrt((2*Qx*cos(Eta)-2*Qy*sin(Eta)-2*x6*cos(Eta))^2(4*((Qy^2)+(Qx^2)+(x6^2)-2*x6*Qx-4))))/(2))
%%
%Part 2. Working Model Position Analysis
%Mechanism CG postition profiles are mapped with global coordinates with
%respect to origin O represented in the free body diagram.
load Kite_Mechanism_Position.txt;
Values=Kite_Mechanism_Position;
x1=Values(:,2);
x2=Values(:,6);
x3=Values(:,10);
x4=Values(:,14);
x5=Values(:,18);
x6=Values(:,22);
x7=Values(:,26);
x8=Values(:,30);
x9=Values(:,34);
y1=Values(:,3);
y2=Values(:,7);
y3=Values(:,11);
y4=Values(:,15);
y5=Values(:,19);
5
y6=Values(:,23);
y7=Values(:,27);
y8=Values(:,31);
y9=Values(:,35);
figure (1)
p=plot(x1,y1,'b',x2,y2,'r',x3,y3,'k',x4,y4,'r',x5,y5,'g',xf,y6,'k-.',x7,y7,'k--',x8,y8,'k:',x9,y9,'g');
xlabel('Global X Position (m)')
ylabel('Global Y Position (m)')
title('Position Profile of CG of Mechanism Links')
legend('Link 1','Link 2','Link 3','Link 4','Link 5','Link 6','Link 7','Link 8','Link 9')
%%
%Motor Torque Analysis
%Motor at the Origin
load Kite_Mechanism_Motor_Torque_Origin.txt
Values2=Kite_Mechanism_Motor_Torque_Origin;
T1=abs(Values2(:,2));
Theta1=Values2(:,4);
%Motor Torque at Joint U
load Kite_Mechanism_Motor_Torque_Joint_U.txt
Values3=Kite_Mechanism_Motor_Torque_Joint_U;
T2=abs(Values3(:,2));
Theta2=Values3(:,4);
figure (2)
plot(Theta1,T1,'r',Theta2,T2,'b');
xlabel('Angle (degrees)')
ylabel('Magnitude of Applied Motor Torque (N-m)')
title('Magnitude of Applied Motor Torque vs Theta')
legend('Motor at Origin','Motor at Joint U')
6
Appendix B: Matlab Analysis Graphs
Figure 6: Applied Motor Torque
7
Figure 7: Contact Force
Figure 8: Position Profile of CG
8
Appendix C: Working Model Figures
Figure 9: Free Body Diagram
9
Figure 10: Contact Force with Linear Force Input
Figure 11: Contact Force with Torque Input
10
Appendix D: SolidWorks Photos
Figure 12: Front View Closed
Figure 13: Front View Open
11
Figure 14: Isometric View Open
12
Appendix E: Final Photos
Figure 15: Final Design Closed
13
ME 481
Computer-Aided Analysis of Machine Dynamics
Final Report
Simple Application of Collision Detection Algorithms to Analyze
The Interaction between a Robotic Gripper Arm End Effector and a
Circular Object
Author: Jean-Pierre LaGuerre
May 6, 2015
ME 481
Computer-Aided Analysis of Machine Dynamics
Introduction
A robotic gripper arm end effector is a mechanism that can be used for an array of tasks; grasping,
holding, lifting, moving and controlling other materials. Gripper arms have become increasingly
important in the manufacturing industry due to the tremendous advancement in technology in
manufacturing companies. This being said I found it appropriate to use this mechanism as a model to
apply collision detecting algorithms like the ones presented in lecture. The robotic arm that will be
modeled is composed of two four bar linkage systems that are ultimately driven by a stepper motor. All
though the mechanism has the potential to be very useful it is ultimately blind and will need input in order
to operate the way it is intended.
Purpose
As stated before, robotic arm end effectors are virtually blind. Although tolerances are inherent within
the design this does not fully eliminate the potential for damage to occur. Thusly collision detection
methods can be implemented to help mitigate the damage that the object may incur. These collision
detection methods can be simulated though software, thus decrease experimental costs. This is exactly
what has been done here. The collision detection methods were simulated and analyzed to show their
similarities and differences. Ultimately the ideal collision detection method would be chosen.
Methods
The process in which the project was conducted was split into three phases. After an ideal model from a
real working application was chosen it was then modeled in solid works. This required an extensive
amount of time and solid understanding of basic Solidworks procedures. After the 3D design was
completed a 2D simplified version of the model was created in Working model. This would allow for the
creation of simulation data which would then be used in Matlab to conduct collision detection
algorithms. Finally as previously stated the data form Working model was imported into Matlab for
further processing and the results would then be extrapolated from the collision detection algorithms.
Solidworks
Going into more details of what was actually done I will start with Solidworks. The robotic arm end
effector was broken down into its individual parts, each one being modeled separately. Once each part
had been modeled the parts were then brought together in an assembly. Figure 1 shows each individual
part. The mechanism is composed of a base upon which the other parts placed, a stepper motor,
stepper motor rod, a worm gear (the driving part of the model), two spur gears, 6six bars composed of
three sets of varying sizes, and two end effectors.
ME 481
Computer-Aided Analysis of Machine Dynamics
Figure 1: Exploded view of robotic arm end effector
A fully mated model of the robotic arm end effector is depicted in figure 2 below. Although it cannot be
seen in figure 2, the spur gears and the worm gear are mated via mechanical gear mates. This allows for
the simulation of realistic motion and interaction between the parts.
Figure 2: View of fully mated mechanism
ME 481
Computer-Aided Analysis of Machine Dynamics
Figure 3: Mechanical Gear mates
The mechanical gear mates are made by selecting the pitch diameter of both parts. This gives the
necessary ratio to simulate the realistic interaction between the two mated parts. In this case the ration
of the spur gear to worm gear was 36 to 2.
Once the 3D model was finished a 2D model would have to be created for further simulation and
processing.
Working model
Using the 2D application software a simplified version of the model was created. Only the main parts
were included in the simulation, eliminating base. The stepper moto and all its component (stepper
motor rod and worm gear) we replaced with a gear system. A finished product of the model is shown in
figure 4 below.
Figure 4: Final 2D model of robotic arm end effector
To build this model required a decent amount of planning in order for all of the necessary parts to mate
correctly. The mates had to be done in levels in order to insure that the intended parts interacted
correctly with their intended mates. If one wanted three parts to interact with one another multiple
joints would have to be layered at that point. For example the gear system used to drive the simulation
ME 481
Computer-Aided Analysis of Machine Dynamics
had to be first added to the circles (which represented the spur gears) before the circles could be joined
with anything else. This acted as the basis of the system, the driving force. Once this was in place all
dependent constraints could be later added.
Figure 5: Zoomed in image depicting gear system (black gears)
After successfully creating the 2-D model in working model, I then began prepping for data analysis. I set
up the model to record the motions of point A and point B as shown in image. I then ran the simulation
until the arms intersected the circular object. I then stopped the simulation and exported the data and
saved as a text file for further processing in matlab.
A
B
Figure 6: Point A is located dead center at the bottom of the
rectangular shape and point B is located dead center of circular
shape
ME 481
Computer-Aided Analysis of Machine Dynamics
Matlab
The data exported into Matlab is composed of motion data recorded at different time steps. This data
would then be used by various collision detection methods. The data imported can be seen in the
Appendices section. Three different detection methods were used to analyze the data. The three
methods are as follows;



Bounding Bodies collision detection method
Point in Polygon collision detection method
Edge intersection collision detection method
The Bounding bodies method was done by following the steps listed in figure 7 below
Figure 7: Bounding bodies method. From notes_10_04
The Point in polygon method was done using the inpolygon Matlab function. Finally the Edge
intersection method was done following the steps listed in figure 8
Figure 8: Edge intersection method. From notes_10_04
ME 481
Computer-Aided Analysis of Machine Dynamics
Results
The results are four graphs shown in figure 9. The first one depicts simply the motion of the two objects.
The second through fourth graph show the results of the various collision detection methods
Figure 9: Depiction of the various testing methods
The graph on the top left is simple input data and plot and manually find points of intersection method.
As you can probably tell that would be a pretty tedious task. The graph on the top right is the result of
bounding circle detection. As you can see I modified the code to highlight green when there is no
intersection and red when there is. The end effector highlights red prematurely because it is considering
maximum radius. The graphs on the bottom left and right more accurately depict the motion. The point
in polygon method accurately shows where the two objects would collide. My code also outputs text
indicating at which time step the two objects collide (see Appendices for results). The edge intersection
does a similar method but requires a great deal more of computation. The major difference is that Edge
intersection tells you exactly which edges are intersecting one another.
Conclusions
Running through the various methods I was able to verify that bounding circle detection methods work
best for centroidal origins and objects with low aspect ratio. Also point-in polygon method must be used
with caution when it is used for thin bodies, although it was a lower computational complexity than
ME 481
Computer-Aided Analysis of Machine Dynamics
edge intersection. Edge intersection is by far the most exhaustive method. However it too has its
limitations, like when one object is inside another. So personally for me I’d first use the point in polygon
method followed by the edge intersection and then lastly bounding circles.
ME 481
Computer-Aided Analysis of Machine Dynamics
References
[1] Kurfess, Thomas R. "Sensors and Control Considerations." Robotics and Automation Handbook.
Boca Raton: CRC, 2005. 17. Print.
[2] Sah, Deeptam T., Subhajit Sanfui, Rajat Kabiraj, and Santanu Das. "Design and Implementation of
a 4-Bar Linkage Gripper." IOSR Journal of Mechanical and Civil Engineering (IOSR-JMCE) (n.d.): 1.
Web. 6 May 2015.
[3] Singh, Puran, Anil Kumar, and Mahesh Vashisth. "Design of a Robotic Arm with Gripper & End
Effector for Spot Welding." Design of a Robotic Arm with Gripper & End Effector for Spot
Welding (n.d.): 1. Web. 6 May 2015.
<http://www.hrpub.org/download/201310/ujme.2013.010303.pdf>.
ME 481
Computer-Aided Analysis of Machine Dynamics
Appendices
CODE:
% M3481FinalProject.m - show and analyze motion for collision detection for
% Robotic Arm End Effector interracting with circular object
% JPFL, 05.06.15
%-------------------------CODE FOR: MANUAL METHOD-------------------------%
clear
clc
% this sections purpose is to import WM data and simply show graphically
% interaction between end effector and circular object
% motion data of robot arm effector and circular object imported from WM.
all = [0.000000
20.000002
14.000000
0.000000
29.500000
0.000000
0.000000;
0.050000
20.499794
13.987502
3.185368e-010 29.500000
0.000000
0.000000;
0.100000
20.998336
13.950041
1.798906e-011 29.500000
0.000000
0.000000;
0.150000
21.494384
13.887710
-8.937564e-010 29.500000
0.000000
0.000000;
0.200000
21.986695
13.800665
-2.420500e-009 29.500000
0.000000
0.000000;
0.250000
22.474042
13.689124
-4.573314e-009 29.500000
0.000000
0.000000;
0.300000
22.955204
13.553364
-7.370726e-009 29.500000
0.000000
0.000000;
0.350000
23.428980
13.393726
-1.083910e-008 29.500000
0.000000
0.000000;
0.400000
23.894185
13.210609
-1.501324e-008 29.500000
0.000000
0.000000;
0.450000
24.349657
13.004470
-1.992799e-008 29.500000
0.000000
0.000000;
0.500000
24.794257
12.775825
-2.581470e-008 29.500000
0.000000
0.000000;
0.550000
25.226874
12.525244
-3.259202e-008 29.500000
0.000000
0.000000;
0.600000
25.646427
12.253355
-4.034171e-008 29.500000
0.000000
0.000000;
0.650000
26.051866
11.960837
-4.916091e-008 29.500000
0.000000
0.000000;
0.700000
26.442179
11.648420
-5.916519e-008 29.500000
0.000000
0.000000;
0.750000
26.816389
11.316887
-7.049137e-008 29.500000
0.000000
0.000000;
0.800000
27.173562
10.967065
-8.330077e-008 29.500000
0.000000
0.000000;
0.850000
27.512806
10.599830
-9.778220e-008 29.500000
0.000000
0.000000;
0.900000
27.833270
10.216098
-1.141541e-007 29.500000
0.000000
ME 481
Computer-Aided Analysis of Machine Dynamics
0.000000;
0.950000
28.134156
0.000000;
1.000000
28.414711
0.000000;
1.050000
28.674233
0.000000;
1.100000
28.912075
0.000000;
1.150000
29.127640
0.000000;
1.200000
29.320392
0.000000;
1.250000
29.489847
0.000000;
1.300000
29.635582
0.000000;
1.350000
29.757234
0.000000;
1.400000
29.854498
0.000000;
1.450000
29.927130
0.000000];
9.816829
-1.326635e-007 29.500000
0.000000
9.403021
-1.535784e-007 29.500000
0.000000
8.975709
-1.771621e-007 29.500000
0.000000
8.535959
-2.030871e-007 29.500000
0.000000
8.084872
-2.317825e-007 29.500000
0.000000
7.623575
-2.625255e-007 29.500000
0.000000
7.153221
-2.930591e-007 29.500000
0.000000
6.674986
-3.168388e-007 29.500000
0.000000
6.190065
-3.151219e-007 29.500000
0.000000
5.699669
-2.290014e-007 29.500000
0.000000
5.205026
1.649726e-007
0.000000
29.500000
time = all(:,1)';
% size 1 x nt
r2_all = all(:,2:3)'; % size 2 x nt
phi2_all = all(:,4)'; % size 1 x nt
ntime = length( time );
% define object 2 (end effector) in local coordinates
s2p_poly = [ 3.5
3.5 -3.5 -3.5 ;
% local x2p [in]
2 0 0
2 ];
% local y2p [in]
% maximum radius rho_i = max(norm{s_i}'^P
rho2 = max( sqrt( diag( s2p_poly'*s2p_poly ) ) ); % maximum radius
[ nr, n2 ] = size( s2p_poly );
% number of pts for body 2
r3_all = all(:,5:6)';
phi3_all = all(:,7)';
% size 2 x nt
% size 1 x nt
% define object 2 in local coordinates (circular object redfined as
% traingle)
s3p_poly = [ 0
7.36121593
-7.36121593 ;
% local x3p [in]
8.5
-4.25
-4.25 ];
% local y3p [in]
% maximum radius rho_i = max(norm{s_i}'^P
rho3 = max( sqrt( diag( s3p_poly'*s3p_poly ) ) ); % maximum radius
[ nr2, n3 ] = size( s3p_poly );
% number of pts for body 3
% new figure
figure( 1 )
clf
ME 481
Computer-Aided Analysis of Machine Dynamics
% plot origin and outline at each time sample
for itime = 1 : ntime,
t = time(itime);
% body 2
r2 =
phi2
A2 =
= red
r2_all(:,itime);
= phi2_all(itime);
[ cos(phi2) -sin(phi2) ;
sin(phi2)
cos(phi2) ];
r2_poly = r2*ones(1,n2) + A2*s2p_poly;
plot( r2(1),r2(2),'ro' )
axis equal
hold on
r3 = r3_all(:,itime);
phi3 = phi3_all(itime);
A3 = [ cos(phi3) -sin(phi3) ;
sin(phi3)
cos(phi3) ];
r3_poly = r3*ones(1,n3) + A3*s3p_poly;
plot( r3(1),r3(2),'ro' )
axis equal
% origin
% angle
% attitude matrix (rotation)
% global locations for vertices
% plot origin
% origin
% angle
% attitude matrix (rotation)
% global locations for vertices
% plot origin
plot( [r2_poly(1,:) r2_poly(1,1)], [r2_poly(2,:) r2_poly(2,1)], 'r',...
[r3_poly(1,:) r3_poly(1,1)], [r3_poly(2,:) r3_poly(2,1)], 'b' )
% closed curve
end
% bottom - for itime
ME 481
Computer-Aided Analysis of Machine Dynamics
%-------------------CODE FOR: METHOD OF BOUNDING CIRCLES------------------%
rhoij = rho2+rho3;
% sum of maximum radii
figure(2)
clf
q = [];
% empty set to load results in
% employ bounding circle quick check to locate collisions
for itime = 1 : ntime,
t = time(itime);
% body 2
r2 =
phi2
A2 =
= red
r2_all(:,itime);
= phi2_all(itime);
[ cos(phi2) -sin(phi2) ;
sin(phi2)
cos(phi2) ];
r2_poly = r2*ones(1,n2) + A2*s2p_poly;
plot( r2(1),r2(2),'ro' )
axis equal
hold on
r3 = r3_all(:,itime);
phi3 = phi3_all(itime);
A3 = [ cos(phi3) -sin(phi3) ;
sin(phi3)
cos(phi3) ];
r3_poly = r3*ones(1,n3) + A3*s3p_poly;
% origin
% angle
% attitude matrix
% global locations for vertices
% plot origin
% origin
% angle
% attitude matrix
% global locations for vertices
ME 481
Computer-Aided Analysis of Machine Dynamics
plot( r3(1),r3(2),'ro' )
axis equal
% plot origin
rij = r2-r3;
cij = sqrt(rij'*rij);
% center distance norm({ri}-{rj})
%loop to indicate when collision occurs. 0 means no collision 1 means
%collision occurs
if cij>rhoij
h = 0;
q = [q h];
else
k = 1;
q = [q k];
end
if sum(q)>=1
plot( [r2_poly(1,:) r2_poly(1,1)], [r2_poly(2,:) r2_poly(2,1)], 'r',...
[r3_poly(1,:) r3_poly(1,1)], [r3_poly(2,:) r3_poly(2,1)], 'b' )
else
plot( [r2_poly(1,:) r2_poly(1,1)], [r2_poly(2,:) r2_poly(2,1)], 'g',...
[r3_poly(1,:) r3_poly(1,1)], [r3_poly(2,:) r3_poly(2,1)], 'b' )
end
% closed curve
end % bottom - for itime
q = find(q);
fprintf('Objects are candidates for collision at stage(s) %d via bounding objects method\n', q
)
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
Objects
are
are
are
are
are
are
are
are
are
are
are
are
are
are
are
are
are
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
candidates
for
for
for
for
for
for
for
for
for
for
for
for
for
for
for
for
for
collision
collision
collision
collision
collision
collision
collision
collision
collision
collision
collision
collision
collision
collision
collision
collision
collision
at
at
at
at
at
at
at
at
at
at
at
at
at
at
at
at
at
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
via
via
via
via
via
via
via
via
via
via
via
via
via
via
via
via
via
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
bounding
objects
objects
objects
objects
objects
objects
objects
objects
objects
objects
objects
objects
objects
objects
objects
objects
objects
method
method
method
method
method
method
method
method
method
method
method
method
method
method
method
method
method
ME 481
Computer-Aided Analysis of Machine Dynamics
%------------------CODE FOR: METHOD OF POINT IN POLYGON-------------------%
figure(3)
clf
u = [];
% empty set to load results in
v = [];
% empty set to load results in
R = [0 -1;
% rotation matrix
1 0];
% employ Point in polygon to locate collisions
for itime = 1 : ntime,
t = time(itime);
% body 2
r2 =
phi2
A2 =
= red
r2_all(:,itime);
= phi2_all(itime);
[ cos(phi2) -sin(phi2) ;
sin(phi2)
cos(phi2) ];
r2_poly = r2*ones(1,n2) + A2*s2p_poly;
plot( r2(1),r2(2),'ro' )
axis equal
hold on
r3 = r3_all(:,itime);
phi3 = phi3_all(itime);
A3 = [ cos(phi3) -sin(phi3) ;
% origin
% angle
% attitude matrix
% global locations for vertices
% plot origin
% origin
% angle
% attitude matrix
ME 481
Computer-Aided Analysis of Machine Dynamics
sin(phi3)
cos(phi3) ];
r3_poly = r3*ones(1,n3) + A3*s3p_poly;
plot( r3(1),r3(2),'ro' )
axis equal
% global locations for vertices
% plot origin
inside2 = inpolygon(r3_poly(1,:),r3_poly(2,:), r2_poly(1,:), r2_poly(2,:));
inside3 = inpolygon(r2_poly(1,:),r2_poly(2,:), r3_poly(1,:), r3_poly(2,:));
if inside2 == [0 0 0 ]
h = 0;
u = [u h];
else
h = 1;
u = [u h];
end
if inside3 == [0 0 0 0]
b = 0;
v = [v b];
else
b = 1;
v = [v b];
end
if sum(u)>=1
plot( [r2_poly(1,:) r2_poly(1,1)], [r2_poly(2,:) r2_poly(2,1)], 'r',...
[r3_poly(1,:) r3_poly(1,1)], [r3_poly(2,:) r3_poly(2,1)], 'b' )
else
plot( [r2_poly(1,:) r2_poly(1,1)], [r2_poly(2,:) r2_poly(2,1)], 'g',...
[r3_poly(1,:) r3_poly(1,1)], [r3_poly(2,:) r3_poly(2,1)], 'b' )
end
end % bottom - for itime
u2 = find(u);
fprintf('\nObject three is inside object two at stage(s) %d via in-polygon method', u2 )
u3 = find(v);
fprintf('\nObject two is inside object three at stage(s) %d via in-polygon method\n \n', u3 )
Object
Object
Object
Object
Object
three is inside object two
three is inside object two
three is inside object two
three is inside object two
two is inside object three
at
at
at
at
at
stage(s)
stage(s)
stage(s)
stage(s)
stage(s)
24 via in-polygon method
25 via in-polygon method
26 via in-polygon method
27 via in-polygon method
via in-polygon method
ME 481
Computer-Aided Analysis of Machine Dynamics
%------------------CODE FOR: METHOD OF EDGE INTERSECTION------------------figure(4)
clf
% EDGE 1
u = [];
v = [];
R = [0 -1;
1 0];
% empty set to load results in
% empty set to load results in
% rotation matrix
% empty sets to load values in
a = [];
a2 = [];
b = [];
b2 = [];
c = [];
c2 = [];
d = [];
d2 = [];
for itime = 1 : ntime,
t = time(itime);
% body 2 = red
r2 = r2_all(:,itime);
% origin
ME 481
Computer-Aided Analysis of Machine Dynamics
phi2 = phi2_all(itime);
A2 = [ cos(phi2) -sin(phi2) ;
sin(phi2)
cos(phi2) ];
r2_poly = r2*ones(1,n2) + A2*s2p_poly;
plot( r2(1),r2(2),'ro' )
axis equal
hold on
% angle
% attitude matrix
r3 = r3_all(:,itime);
phi3 = phi3_all(itime);
A3 = [ cos(phi3) -sin(phi3) ;
sin(phi3)
cos(phi3) ];
r3_poly = r3*ones(1,n3) + A3*s3p_poly;
plot( r3(1),r3(2),'ro' )
axis equal
% origin
% angle
% attitude matrix
% global locations for vertices
% plot origin
% global locations for vertices
% plot origin
delii = diff(r2_poly(:,[1,2]),1,2); % 2x1 matrix composed of delx_i and dely_i
a = [];
for l = 1:3
if l<3
q = l+1;
deljj = diff(r3_poly(:,[l,q]),1,2); % 2x1 matrix composed of delx_j and dely_j
delij = r3_poly(:,1)-r2_poly(:,1); % 2x1 matrix composed of delx_ij and dely_ij
delx_i = delii(1,1);
dely_i = delii(2,1);
delx_j = deljj(1,1);
dely_j = deljj(2,1);
delx_ij = delij(1,1);
dely_ij = delij(2,1);
di = ((delx_j)*(dely_ij)
((delx_j)*(dely_i) dj = ((delx_i)*(dely_ij)
((delx_j)*(dely_i) if di >= 0 && di <= 1 &&
h = 1;
a = [a h];
else
h = 0;
a = [a h];
end
- (dely_j)*(delx_ij))/...
(delx_i)*(dely_j));
- (dely_i)*(delx_ij))/...
(delx_i)*(dely_j));
dj >= 0 && dj <= 1
elseif l == 3
q = 1;
deljj = diff(r3_poly(:,[l,q]),1,2); % 2x1 matrix composed of delx_j and dely_j
delij = r3_poly(:,l)-r2_poly(:,1); % 2x1 matrix composed of delx_ij and dely_ij
delx_i = delii(1,1);
dely_i = delii(2,1);
delx_j = deljj(1,1);
ME 481
Computer-Aided Analysis of Machine Dynamics
dely_j = deljj(2,1);
delx_ij = delij(1,1);
dely_ij = delij(2,1);
di = ((delx_j)*(dely_ij)
((delx_j)*(dely_i) dj = ((delx_i)*(dely_ij)
((delx_j)*(dely_i) if di >= 0 && di <= 1 &&
h = 1;
a = [a h];
else
h = 0;
a = [a h];
end
- (dely_j)*(delx_ij))/...
(delx_i)*(dely_j));
- (dely_i)*(delx_ij))/...
(delx_i)*(dely_j));
dj >= 0 && dj <= 1
end
end
a2 = [a2; a];
% EDGE 2
%
delii = diff(r2_poly(:,[2,3]),1,2); % 2x1 matrix composed of delx_i and dely_i
b = [];
for l = 1:3
if l<3
q = l+1;
deljj = diff(r3_poly(:,[l,q]),1,2); % 2x1 matrix composed of delx_j and dely_j
delij = r3_poly(:,l)-r2_poly(:,2); % 2x1 matrix composed of delx_ij and dely_ij
delx_i = delii(1,1);
dely_i = delii(2,1);
delx_j = deljj(1,1);
dely_j = deljj(2,1);
delx_ij = delij(1,1);
dely_ij = delij(2,1);
di = ((delx_j)*(dely_ij)
((delx_j)*(dely_i) dj = ((delx_i)*(dely_ij)
((delx_j)*(dely_i) if di >= 0 && di <= 1 &&
h = 1;
b = [b h];
else
h = 0;
b = [b h];
- (dely_j)*(delx_ij))/...
(delx_i)*(dely_j));
- (dely_i)*(delx_ij))/...
(delx_i)*(dely_j));
dj >= 0 && dj <= 1
ME 481
Computer-Aided Analysis of Machine Dynamics
end
elseif l == 3
q = 1;
deljj = diff(r3_poly(:,[l,q]),1,2); % 2x1 matrix composed of delx_j and dely_j
delij = r3_poly(:,l)-r2_poly(:,2); % 2x1 matrix composed of delx_ij and dely_ij
delx_i = delii(1,1);
dely_i = delii(2,1);
delx_j = deljj(1,1);
dely_j = deljj(2,1);
delx_ij = delij(1,1);
dely_ij = delij(2,1);
di = ((delx_j)*(dely_ij)
((delx_j)*(dely_i) dj = ((delx_i)*(dely_ij)
((delx_j)*(dely_i) if di >= 0 && di <= 1 &&
h = 1;
b = [b h];
else
h = 0;
b = [b h];
end
- (dely_j)*(delx_ij))/...
(delx_i)*(dely_j));
- (dely_i)*(delx_ij))/...
(delx_i)*(dely_j));
dj >= 0 && dj <= 1
end
end
b2 = [b2; b];
% EDGE 3
%
delii = diff(r2_poly(:,[3,4]),1,2); % 2x1 matrix composed of delx_i and dely_i
c = [];
for l = 1:3
if l<3
q = l+1;
deljj = diff(r3_poly(:,[l,q]),1,2); % 2x1 matrix composed of delx_j and dely_j
delij = r3_poly(:,l)-r2_poly(:,3); % 2x1 matrix composed of delx_ij and dely_ij
delx_i = delii(1,1);
dely_i = delii(2,1);
delx_j = deljj(1,1);
dely_j = deljj(2,1);
delx_ij = delij(1,1);
ME 481
Computer-Aided Analysis of Machine Dynamics
dely_ij = delij(2,1);
di = ((delx_j)*(dely_ij)
((delx_j)*(dely_i) dj = ((delx_i)*(dely_ij)
((delx_j)*(dely_i) if di >= 0 && di <= 1 &&
h = 1;
c = [c h];
else
h = 0;
c = [c h];
end
- (dely_j)*(delx_ij))/...
(delx_i)*(dely_j));
- (dely_i)*(delx_ij))/...
(delx_i)*(dely_j));
dj >= 0 && dj <= 1
elseif l == 3
q = 1;
deljj = diff(r3_poly(:,[l,q]),1,2); % 2x1 matrix composed of delx_j and dely_j
delij = r3_poly(:,l)-r2_poly(:,3); % 2x1 matrix composed of delx_ij and dely_ij
delx_i = delii(1,1);
dely_i = delii(2,1);
delx_j = deljj(1,1);
dely_j = deljj(2,1);
delx_ij = delij(1,1);
dely_ij = delij(2,1);
di = ((delx_j)*(dely_ij)
((delx_j)*(dely_i) dj = ((delx_i)*(dely_ij)
((delx_j)*(dely_i) if di >= 0 && di <= 1 &&
h = 1;
c = [c h];
else
h = 0;
c = [c h];
end
- (dely_j)*(delx_ij))/...
(delx_i)*(dely_j));
- (dely_i)*(delx_ij))/...
(delx_i)*(dely_j));
dj >= 0 && dj <= 1
end
end
c2 = [c2; c];
% EDGE 4
%
delii = diff(r2_poly(:,[4,1]),1,2); % 2x1 matrix composed of delx_i and dely_i
d = [];
ME 481
Computer-Aided Analysis of Machine Dynamics
for l = 1:3
if l<3
q = l+1;
deljj = diff(r3_poly(:,[l,q]),1,2); % 2x1 matrix composed of delx_j and dely_j
delij = r3_poly(:,l)-r2_poly(:,4); % 2x1 matrix composed of delx_ij and dely_ij
delx_i = delii(1,1);
dely_i = delii(2,1);
delx_j = deljj(1,1);
dely_j = deljj(2,1);
delx_ij = delij(1,1);
dely_ij = delij(2,1);
di = ((delx_j)*(dely_ij)
((delx_j)*(dely_i) dj = ((delx_i)*(dely_ij)
((delx_j)*(dely_i) if di >= 0 && di <= 1 &&
h = 1;
d = [d h];
else
h = 0;
d = [d h];
end
- (dely_j)*(delx_ij))/...
(delx_i)*(dely_j));
- (dely_i)*(delx_ij))/...
(delx_i)*(dely_j));
dj >= 0 && dj <= 1
elseif l == 3
q = 1;
deljj = diff(r3_poly(:,[l,q]),1,2); % 2x1 matrix composed of delx_j and dely_j
delij = r3_poly(:,l)-r2_poly(:,4); % 2x1 matrix composed of delx_ij and dely_ij
delx_i = delii(1,1);
dely_i = delii(2,1);
delx_j = deljj(1,1);
dely_j = deljj(2,1);
delx_ij = delij(1,1);
dely_ij = delij(2,1);
di = ((delx_j)*(dely_ij)
((delx_j)*(dely_i) dj = ((delx_i)*(dely_ij)
((delx_j)*(dely_i) if di >= 0 && di <= 1 &&
h = 1;
d = [d h];
else
h = 0;
d = [d h];
end
end
end
- (dely_j)*(delx_ij))/...
(delx_i)*(dely_j));
- (dely_i)*(delx_ij))/...
(delx_i)*(dely_j));
dj >= 0 && dj <= 1
ME 481
Computer-Aided Analysis of Machine Dynamics
d2 = [d2; d];
e = [a2 b2 c2 d2];
if sum(sum(e))>=1
plot( [r2_poly(1,:) r2_poly(1,1)], [r2_poly(2,:) r2_poly(2,1)], 'r',...
[r3_poly(1,:) r3_poly(1,1)], [r3_poly(2,:) r3_poly(2,1)], 'b' )
else
plot( [r2_poly(1,:) r2_poly(1,1)], [r2_poly(2,:) r2_poly(2,1)], 'g',...
[r3_poly(1,:) r3_poly(1,1)], [r3_poly(2,:) r3_poly(2,1)], 'b' )
end
end
% edges are edges of the square
% resultant values are 3x length of time matrix
% each of the three rows corresponds to a triangle edge
a2 = [a2; a];
fprintf('Edge 1\n')
disp(a2)
b2 = [b2; b];
fprintf('Edge 2\n')
disp(b2)
c2 = [c2; c];
fprintf('Edge 3\n')
disp(c2)
d2 = [d2; d];
fprintf('Edge 4\n')
disp(d2)
A = find(a2);
AA= find(A<40 & A>20);
AAA = A(AA,:)
B = find(b2);
BB= find(B<40 & B>20);
BBB = B(BB,:)
C = find(c2);
CC= find(C<40 & C>20);
CCC = C(CC,:)
D = find(d2);
DD= find(D<40 & D>20);
DDD = D(DD,:)
Edge 1
0
0
0
0
0
0
0
0
0
0
0
0
ME 481
Computer-Aided Analysis of Machine Dynamics
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Edge 2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
ME 481
Computer-Aided Analysis of Machine Dynamics
1
1
1
1
1
1
0
0
0
0
0
0
1
1
1
1
1
1
Edge 3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Edge 4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
ME 481
Computer-Aided Analysis of Machine Dynamics
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
AAA =
Empty matrix: 0-by-1
BBB =
24
25
26
27
28
29
30
31
CCC =
Empty matrix: 0-by-1
DDD =
28
29
30
31
ME 481
Computer-Aided Analysis of Machine Dynamics
Published with MATLAB® R2014a
Christopher Varghese
ME481 Final Paper
Jeung Hun Lee
Dr.Sommer
May 6, 2015
Rotary Engine
Intro
The rotary engine is a type of internal combustion engine invented by a German engineer,
Felix Wankel. It occurs in a moving combustion chamber inside of an oval shaped housing and a
rotor. The crankshaft remains fixed. Only the crankcase(triangular shape) attached inside rotates.
Mechanical Design
There are different designs for Rotary Engine. Here are some of them
Applications
Rotary engines were used in many different applications
here are some examples
•
Automobile engines
Ex)Mazda RX-7
•
Motorcycle engines
Ex) Suzuki RE5
•
Aircraft engines
Ex) Piper Turbo Arrow III
Although there are many advantages that rotary engines have over piston engines, rotary engines
are not practically used these days in cars, motor cycles, aircrafts, etc. Because there are many
limitations.
Advantages & Disadvantages
Advantages:

High Revolution

Less moving parts than conventional engines

Very high Weight-to-Power ratio (13B-MSP renesis from RX-8 1.3 liter produces 232
HP)

Smooth, less vibration than conventional engines
Disadvantages:

Maintenance

Low Fuel Efficiency (Mazda RX-7 has about 5-7 MPG fuel efficiency)

Short term use

Combustion chamber oil leakage

Pollution

Limited to gasoline
Computer Analysis
SolidWorks:
In SolidWorks, we were able to do a motion analysis on the rotary engine. We picked one of the
tips out of the three of the rotor and generated a plot of the linear displacement of the tip of the
rotor as shown below in Figure 1. The rotor was set to run at a constant speed of 100 RPM
(SolidWorks would only run smoothly at this speed).
Figure 1. Linear Displacement Plot of Rotary Engine at Constant Speed of 100 RPM (SolidWorks Model)
After obtaining the linear displacement plot over 5 seconds, we then generated plots of the linear
velocity and acceleration as well. In the linear velocity plot, as shown in Figure 2 below, there
was a spike at around 0.49 seconds, but we assumed this to be some kind of error in SolidWorks
although it showed the same result each time we plotted this graph. This spike is irrelevant
information as it does not occur in the rest of the plot.
Figure 2. Linear Velocity Plot of Rotary Engine at Constant Speed of 100 RPM (SolidWorks Model)
In Figure 3, the linear acceleration was plotted. Below the linear acceleration plot shows two
irrelevant spikes as well at around 0.1 seconds and 0.49 seconds
Figure 3. Linear Acceleration Plot of Rotary Engine at Constant Speed of 100 RPM (SolidWorks Model)
MATLAB:
While rotating on the ellipse-shaped base of the rotary engine we were able to calculate the linear
position of the tips of the rotor. Figure 4 shows the plot where the parametric equations were
derived from to determine the linear position of the tips of the rotor.
Figure 4. Physical Position Plot for Epitrochoid Parametric Equations
The equations for the x and y position of the tips of the rotor are shown below following the
notation as shown in Figure 1:
x = e cos (3α) + R cosα
y = e sin (3α) + R sinα
where e is the eccentricity of the ellipse and R is the distance from the center of the rotor to the
tip of the rotor. Using MATLAB, we were able to plot the linear position, velocity, and
acceleration of the tip incorporating the parametric equations based on the ellipse-shaped base
for the rotary engine. Below is the code that we used to create the plot for the linear position.
clc
clear
%Eccentricity of the ellipse
e = 0.92857;
a = 0:1:1080; % degrees
alpha = a * (pi / 180); % radians
t = 0:(5/1080):5; % seconds
d = 177.8; % mm
r = d / 2; % mm
R = r - e; % mm
% Linear Position of tips of rotor
Px = e * cos (3 * alpha) + R * cos (alpha);
Py = e * sin (3 * alpha) + R * sin (alpha);
P = sqrt (Px .^ 2 + Py .^ 2);
Vx = -3 * e * sin (3 * alpha) - R * sin (alpha);
Vy = 3 * e * cos (3 * alpha) + R * cos (alpha);
V = sqrt (Vx .^ 2 + Vy .^ 2);
Ax = -9 * e * cos (3 * alpha) - R * cos (alpha);
Ay = -9 * e * sin (3 * alpha) - R * sin (alpha);
A = sqrt (Ax .^ 2 + Ay .^ 2);
figure (1)
plot (t, P)
title ('Linear Position of the Tips of Rotor')
xlabel ('Time (s)')
ylabel ('Linear Position (mm)')
figure (2)
plot (t, V)
title ('Linear Velocity of the Tips of Rotor')
xlabel ('Time (s)')
ylabel ('Linear Velocity (mm / s)')
figure (3)
plot (t, A)
title ('Linear Acceleration of the Tips of Rotor')
xlabel ('Time (s)')
ylabel ('Linear Acceleration (mm / s ^ 2)')
% CR calculation
a = (pi .* ((e ./ R) .^ 2 + (1 / 3))) - ((3 ^ 0.5) / 4);
b = (3 * (3 ^ 0.5) * (e ./ R) / 2);
CR = (a + b) ./ (a - b)
Results:
CR = 1.0934
Figure 5. Linear Displacement Plot of Rotary Engine (MATLAB Model)
Figure 6. Linear Velocity Plot of Rotary Engine (MATLAB Model)
Figure 7. Linear Acceleration Plot of Rotary Engine (MATLAB Model)
Conclusion
Comparing the two sets of plots between the SolidWorks model and the MATLAB model there
are big differences in the results. There are some reasons as to why this has occurred. One of
the most important things to note is that in the MATLAB model we used a perfect ellipse case
for the model. In SolidWorks we used an ellipse, but it had inward bounding curves along the
minor vertices of the ellipse as shown with the red arrows in Figure 8 below.
Figure 8. Inward Bounding Curves at Minor Vertices of Ellipse of Rotary Engine
These curves can cause some differences in the position, velocity, and acceleration in the
SolidWorks model compared to the MATLAB model. Also we believe that we incorrectly
calculated for the velocity and acceleration of the tips of the rotor. The plots we obtained from
MATLAB were completely off from what we obtained from SolidWorks.
References
http://en.wikipedia.org/wiki/Epitrochoid
www.personal.utulsa.edu/~kenneth-weston/chapter7.pdf
http://nationalspeedinc.com/advantages-and-disadvantages-of-a-rotary-engine/
https://grabcad.com/library/rotary-engine--1
http://www.americanrotaryengine.com/
http://zmotauto.com/wpz/birth-wankel-rotary-engine/
http://www.rotronuav.com/engines/rt-300hfe
Katherine Leshkow
ME 481
Spring 2015
May 6, 2015
BACKGROUND
In mechanisms you can come across a wide variety of complex arrangements. Some of these
include the Stewart-Gough platform or the inner workings of a clock. However, one of the most
interesting things about mechanisms is what can be accomplished with the simplest of designs.
For mechanisms, it almost does not get simpler than the 4-bar mechanism. As shown in Figure
1, the 4-bar can be made into four different main configurations, where the configurations are
based upon the relative link lengths of the mechanism.
Figure 1 – Various configurations of the four-bar mechanism [1]
The Grashof criterion helps to define these configurations. The criterion states that a link within
a four-bar configuration will be able to make a full revolution if the sum of the lengths of the
shortest and longest links is less than the sum of the lengths of the other two links. A special
case is when the sum of the lengths of the longest and shortest links is equal to the sum of the
other two links. As shown in Figure 1, the different configurations are named “drag link”,
“crank-rocker”, “double-rocker”, and “parallelogram linkage”.
One application of analyzing the double rocker is shown in Figure 2 below. Here, the double
rocker is being used in order to analyze the transfer of power from the muscles of the hip and
pelvis to the leg.
Figure 2 – Using a double rocker to model biological systems [2]
One application of the parallelogram linkage is in amusement park rides. As shown in Figure 3,
this can include the ride, Da Vinci’s Cradle, in Busch Gardens Williamsburg.
Figure 3 – Da Vinci’s Cradle in Busch Gardens Williamsburg [3]
DESIGN & ANALYSIS
Useful devices can also be made with a combination of simple mechanisms. For this project, a
box-pushing prototype consisting of 4-bar and slider crank mechanisms was created and
analyzed. As shown in Figure 4, one application of a box-pushing device is to move packages
off a conveyer belt, or onto a different conveyor belt. Figures 5 and 6 show the prototype and
linkage sketch, respectively.
Figure 4 – Box Pusher [4]
Figure 5 – Working Prototype
Figure 6 – Diagram of prototype
In order to analyze the position and velocity of the pushing block (link 6), links 2, 3, 4, and
ground were analyzed as a 4-bar mechanism. In turn, links 4, 5, and 6 were treated as a slidercrank. The angular position of link 4 was analyzed using MATLAB, the results are shown below
in Figure 7 and the respective code is in Appendix A. The fact that the crank makes a full
revolution while link 4 rocks back-and-forth is consistent with a 4-bar crank-rocker.
The Angular Position of Link 4 as a Function of Crank Angle
110
Angular Position of Link 4, deg
105
100
95
90
85
80
75
70
65
0
50
100
150
200
250
Crank Angle, deg
300
350
400
Figure 7 – Position of Link 4 as a Function of the Crank Angle
After determining the angular positions of Link 4, the position and velocity of the block were found. The
block’s position was a focus because it impacts the conveyor’s design. As shown in Figure 4 the box
pusher needs to be capable of removing a package from the initial conveyor. One way to accomplish
this is to make the distance traveled by the block equivalent to the width of the conveyor. The block
position as a function of the angular position of link 4 is shown in Figure 8 below.
The velocity of the block was also analyzed because it has a direct impact upon the efficiency of any
operation in which it and the conveyor are being used. Additionally, the velocity needs to be considered
along with conveyor speed and the distances between packages to ensure that the conveyor process
functions as desired. The velocity of the block, when link 4 is at 70°, was found to be 12 in/s using the
method of instant centers. The accompanying calculations can be found in Appendix C.
Position of the Pushing Block as a Function of the Angular Positon of Link 4
5
Block Position, in
4.5
4
3.5
3
2.5
2
65
70
75
80
85
90
95
Angular Position of Link 4, deg
100
105
Figure 8 – Piston Position as a Function of the Angular Position of Link 4
CONCLUSION
In mechanisms, even the simplest of devices can prove very useful. One such device is the four-bar
mechanism, which can be used in a wide variety of applications, including the modeling of biological
systems and amusement park rides. In this project a box-pushing mechanism consisting of 4-bar and
slider-crank mechanisms was examined. From the data it was found that a conveyor belt accompanying
the prototype would need to be no greater than 2.2 inches wide to ensure that an item would be fully
removed from the conveyor belt. While it’s hard to imagine an actual factory utilizing such a small scale
in its facility, this data could be used alongside dimensional analysis to help construct a more realisticsized operation.
APPENDIX A – CODE FOR FOUR BAR
%PLACE position, velocity and acceleration codes into one code
%DEFINE constants
phi2_start = 0*(180/pi);
%radians
omega2 = 4*pi;
%radians
t = 0;
%seconds
tpr = 2*pi/omega2;
dt = tpr / 200;
%DEFINE initial values
r1Ap = [0 0]'; r1Dp = [3.7
-2]';
s2primeAp = [0 0]';
s3primeBp = [0 0]';
s4primeCp = [0 0]';
s2primeBp = [1 0]';
s3primeCp = [4 0]';
s4primeDp = [3 0]';
%DEFINE
%
%
%
x2 y2 and phi2 etc with Haug
where r2 (x2 y2),etc
where q = [x2 y2 phi2 x3 y3 phi3 x4 y4 phi4];
here, phi2 = 90
q = [ 0 0 pi/6
0.819 0.574 7*pi/360
4.758 .1268 1.449]';
% in,radians
keep=[];
for t = 0:dt:tpr;
for i = 1:6
r2 = q(1:2);
r3 = q(4:5);
r4 = q(7:8);
phi2 = q(3);
phi3 = q(6);
phi4 = q(9);
%DEFINE rotation matrixes
%
where R = [0 -1; 1 0] is the orthogonal rotation matrix p.31
%
and A = [cos(phi) -sin(phi); sin(phi) cos(phi)]
%
is the rotation transformation matrix p. 33
R = [0 -1; 1 0];
A2 = [ cos(phi2) -sin(phi2); sin(phi2) cos(phi2)];
A3 = [ cos(phi3) -sin(phi3); sin(phi3) cos(phi3)];
A4 = [ cos(phi4) -sin(phi4); sin(phi4) cos(phi4)];
%CREATE constraint vector (CV) or PHI
%REFERENCE p.33 (2.4.8)
r2Ap = r2 + A2*s2primeAp; %Link 2 origin
r2Bp = r2 + A2*s2primeBp; %x2,y2
r3Bp = r3 + A3*s3primeBp;
r3Cp = r3 + A3*s3primeCp;
r4Cp = r4 + A4*s4primeCp;
r4Dp = r4 + A4*s4primeDp;
%Link3 origin
%x3,y3
%x4,y4
%REFERENCE notes 04_05 2/8 "desire"
PHI(1:2,1) =
PHI(3:4,1) =
BC.*sin(t3);
PHI(5:6,1) =
PHI(7:8,1) =
PHI(9,1)
=
r2Ap - r1Ap; %
r3Bp - r2Bp; %
x2-AB.*cos(t2); y2-AB.*sin(t2);
x3-AB.*cos(t2)-BC.*cos(t3); y3-AB.*sin(t2)-
r4Cp - r3Cp; % x3+CD.*cos(t4)-ADx; y3-CD.*sin(t4)+ADy;
r4Dp - r1Dp; % x4-ADx; y4+ADy;
phi2 - phi2_start - omega2*t; % t2-(pi./6)-2.*pi.*t]
%CREATE jacobian
R = [0 -1; 1 0];
B2 = R*A2;
B3 = R*A3;
B4 = R*A4;
%p.31 (2.3.6) &
04_01 4/4 bottom
%p. 30
%REFERENCE 04_05 4/8 second
%(columns,rows)
Jac = zeros(9,9);
%Jac=jacobian(PHI,[r2Ap r2Bp r3Bp r3Cp r3Pp r4Cp r4Dp
r4Qp])
Jac(1:2,1:3) = [ eye(2) B2*s2primeAp];
Jac(3:4,1:3) = [-eye(2) -B2*s2primeBp];
Jac(3:4,4:6) = [ eye(2) B3*s3primeBp];
Jac(5:6,4:6) = [-eye(2) -B3*s3primeCp];
Jac(5:6,7:9) = [ eye(2) B4*s4primeCp];
Jac(7:8,7:9) = [ eye(2) B4*s4primeDp];
Jac(9,3)
= 1;
PHI;
inv(Jac);
resid = -inv(Jac)*PHI;
q = q+resid ;
end
%DEFINE constants
nu = [ 0 0 0
0 0 0
0 0 2*pi]';
%SOLVE for qdot
qdot = inv(Jac)*nu;
%
****ACCELERATION****
GAMMA(1:2,1)=
GAMMA(3:4,1)=
GAMMA(5:6,1)=
GAMMA(7:8,1)=
GAMMA(9,1) =
qdot(3)*qdot(3)*A2*s2primeAp;
qdot(6)*qdot(6)*A3*s3primeBp - qdot(3)*qdot(3)*A2*s2primeBp;
qdot(9)*qdot(9)*A4*s4primeCp - qdot(6)*qdot(6)*A3*s3primeCp;
qdot(9)*qdot(9)*A4*s4primeDp;
2*pi;
%SOLVE for qdotdot
qdotdot = inv(Jac)*GAMMA;
phi4=q(9);
keep = [keep; phi2 phi4
];
end
phi2 = keep(:,1)*(180/pi);
phi4 = keep(:,2);
phi4deg = phi4*(180/pi);
phi4degdeg=phi4deg+180;
figure;
plot(phi2, phi4degdeg);
%axis([ 0 360 -250 -100])
xlabel('Crank Angle, deg')
ylabel('Angular Position of Link 4, deg')
title('The Angular Position of Link 4 as a Function of Crank Angle')
APPENDIX B – CODE FOR SLIDER-CRANK
%Newton-Raphson
%DEFINE constants
phi2_start = 0;
omega2 = 4*pi;
t = 0.0;
%radians
%radians
%seconds
%DEFINE initial values
r1Ap = [0 0]';
s2primeAp = [0 0]';
s3primeBp = [0 0]';
s4primeCp = [0 0]';
%DEFINE
%
%
%
%
s2primeBp = [3
s3primeCp = [4.33
0]';
0]';
x2 y2 and phi2 etc with Haug
where r2 (x2 y2),etc
where q = [x2 y2 phi2 x3 y3 phi3 x4 y4 phi4];
q is the constraint vector
q is your estimated global coordinates
q = [ 0 0 4*pi/9
0.521
2.954
-0.1387
4.33
0
0]';
% cm,radians
keep = [];
for t = 0:0.01:1;
for i = 1:5
r2 = q(1:2);
r3 = q(4:5);
r4 = q(7:8);
phi2 = q(3);
phi3 = q(6);
phi4 = q(9);
%DEFINE rotation matrixes
%
where R = [0 -1; 1 0] is the orthogonal rotation matrix p.31
%
and A = [cos(phi) -sin(phi); sin(phi) cos(phi)]
%
is the rotation transformation matrix p. 33
R = [0 -1; 1 0];
A2 = [ cos(phi2) -sin(phi2); sin(phi2) cos(phi2)];
A3 = [ cos(phi3) -sin(phi3); sin(phi3) cos(phi3)];
A4 = [ cos(phi4) -sin(phi4); sin(phi4) cos(phi4)];
%CREATE constraint vector (CV) or PHI
%REFERENCE p.33 (2.4.8)
r2Ap = r2 + A2*s2primeAp; %Link 2 origin
r2Bp = r2 + A2*s2primeBp; %x2,y2
r3Bp = r3 + A3*s3primeBp; %Link3 origin
r3Cp = r3 + A3*s3primeCp; %x3,y3
r4Cp = r4 + A4*s4primeCp; %x4,y4
%REFERENCE
PHI(1:2,1)
PHI(3:4,1)
PHI(5:6,1)
PHI(7,1)
PHI(8,1)
notes 04_05 2/8 "desire"
= r2Ap - r1Ap;
= r3Bp - r2Bp;
= r4Cp - r3Cp;
= q(9); % angle_4
= q(8); % y_4
PHI(9,1)
= phi2 - phi2_start - omega2*t;
%CREATE jacobian
R = [0 -1; 1 0];
%p.31 (2.3.6) & 04_01 4/4 bottom
B2 = R*A2;
%p. 30
B3 = R*A3;
B4 = R*A4;
%REFERENCE 04_05 4/8 second
%(columns,rows)
Jac = zeros(9,9);
%Jac=jacobian(PHI,[r2Ap r2Bp r3Bp r3Cp r3Pp r4Cp r4Dp
r4Qp])
Jac(1:2,1:3) = [ eye(2) B2*s2primeAp];
Jac(3:4,1:3) = [-eye(2) -B2*s2primeBp];
Jac(3:4,4:6) = [ eye(2) B3*s3primeBp];
Jac(5:6,4:6) = [-eye(2) -B3*s3primeCp];
Jac(5:6,7:9) = [ eye(2) B4*s4primeCp];
Jac(7,1:9)
= [0 0 0
0 0 0
0 0 1];
Jac(8,1:9)
= [ 0 0 0
0 0 0
0 1 0];
Jac(9,3)
= 1;
inv(Jac);
resid = -inv(Jac)*PHI;
q = q+resid ;
end
resid;
q;
%VELOCITY
nu = [0 0
0 0
0 0
0 0
104.72]';
qdot = inv(Jac)*nu;
%ACCELERATION
GAMMA(1:2,1)= qdot(3)*qdot(3)*A2*s2primeAp;
GAMMA(3:4,1)= qdot(6)*qdot(6)*A3*s3primeBp - qdot(3)*qdot(3)*A2*s2primeBp;
GAMMA(5:6,1)= - qdot(6)*qdot(6)*A3*s3primeCp; %
GAMMA(7,1) = qdot(9)*qdot(9);
GAMMA(8,1) = 0;
GAMMA(9,1) = 0;
qdotdot = inv(Jac)*GAMMA;
Theta2 = q(3);
Pos4x = q(7);
keep = [keep; Theta2 Pos4x];
end
Theta2 = keep(:,1)*(180/pi);
Pos4x = keep(:,2);
plot(Theta2,Pos4x)
xlabel('Angular Position of Link 4,
deg')
ylabel('Piston Position, in')
title('Position of Piston as a Function of the Angular Positon of Link 4')
axis([65 105 2 5])
APPENDIX C – INSTANTANEOUS CENTERS
𝑉𝐼24 =ω2 x rI24/I12 = ω4 x rI24/rI14
(4*pi)(1.69) = ω4*(5.875)
ω4 = 3.615 rad/s
𝑉𝐼45 =ω4 x rI45/I14 = ω5 x rI45/rI15
(3.615)(3) = ω5* (18.81)
ω5 = 0.576 rad/s
𝑉𝐼56 =ω5 x rI56/I15
𝑉𝐼56 = 12 in/s
WORKS CITED
[1] http://vlabs.iitkgp.ernet.in/Experiment7/Introduction/four_bar.jpg
[2] https://www.youtube.com/watch?v=wWvB3lNYXB0
[3]
https://www.google.com/search?q=aladdin%27s+carpet+busch+gardens&source=lnms&tbm=isc
h&sa=X&ei=BnNJVemcFMGdgwTuYCQDQ&ved=0CAcQ_AUoAQ&biw=1252&bih=602#tbm=isch&q=davinci%27s+cradle+bus
ch+gardens&imgrc=NxrJ02J9PsCjdM%253A%3BMLNkg1ZihEHHM%3Bhttps%253A%252F%252Fc2.staticflickr.com%252F8%252F7257%252F7718093250
_e3fc412142_b.jpg%3Bhttps%253A%252F%252Fwww.flickr.com%252Fphotos%252F872903
2%2540N06%252F7718093250%252F%3B1024%3B768
[4]
https://www.google.com/search?q=package+pusher&source=lnms&tbm=isch&sa=X&ei=0PhIV
cvIJczTsAXekIH4CQ&ved=0CAgQ_AUoAg&biw=1525&bih=734&dpr=0.9#imgrc=XxurfS_u
0ggIgM%253A%3BDwvDLWD3e1DWgM%3Bhttp%253A%252F%252Fwww.innovativeps.co
m%252FImages%252FDownload.aspx%253Fid%253D796%2526refType%253DPage%3Bhttp
%253A%252F%252Fwww.innovativeps.com%252FProduct%252FItem.aspx%253Fid%253D16
0%2526ParentCatID%253D42%3B400%3B280
Jeff Lettman
May 5th, 2015
Optimization of a 12-bar Linkage to Produce a Station Dwell
Final Project for M E 481
Problem Statement
Following the huge success of the London Eye in 2000, giant Ferris wheel projects have experienced a popularity
surge across the globe. There are now three wheels larger than the London Eye with three more in the design
phase. The Orlando Eye, which opens this week will be just 40 feet shy of its counterpart in London. Most of the
existing giant wheels, including the London Eye, the Las Vegas High Roller, and the Orlando Eye use a continuous
loading scheme similar to that of chairlifts or escalators. The passenger boards on a curved platform while the
passenger cab translates horizontally relative to the ground, at a low rate of speed. Having the wheel rotate
continuously offers multiple a variety of benefits. It is less disruptive mechanically, creates a smoother passenger
ride for the passengers, and makes it possible to adhere to a ticket schedule. However, the chairlift loading scheme
still requires that the wheel be stopped to accommodate disabled passengers and large groups. The goal of this
project is to design a kinematic linkage that will attach the passenger cab to the Ferris wheel. When the linkage is
driven it will trace out a path of motion that temporality stabilizes the cab relative to a stationary platform.
Path Description
In order to determine the desired path, the first step was
to establish the required dwell time at the boarding
location. In looking for an appropriate analog to use for
setting the dwell time, subways jumped out as an obvious
choice. Both would be dealing with a car/cab full of people
looking to both disembark and embark within the same
window. Other important parallels existed as well. Both
400 ft.
had to accommodate tourists, disabled riders, and the
elderly, and both aim to keep to a given schedule. Though
adherence to a schedule might not initially seem important
to the purveyors of the Orlando Eye, it is a foundation of
their business plan. Riders will not have to wait in line, but
10 ft.
instead buy tickets for a specified time slot for arrival.
Therefore adherence to a schedule directly impacts both
customer satisfaction, and the company’s bottom line.
Diagram Key
According to the Transit Capacity and Quality of Service
Mechanism
Origin: Rotates with wheel
Manual, which conducted a study of passenger trains
Global Origin:
Position fixed to ground
across the US and Canada, dwell time related to passenger
alighting and boarding varied between 11.7 and 23.4 sec. Figure 1: Ferris wheel coordinate system definition and
optimal dwell point location
The report also indicated that special events like football
games and rock concerts increased the alighting time. For this reason, and since the wheel will be dealing
exclusively with tourists, the dwell time for this projected was selected as 37.5 seconds, which allowed for an
additional 2 standard deviations from the worst case mean (TTC in Toronto).
The Orlando Eye rotates at a rate of 1 revolution per half hour, so a 37.5
second dwell time corresponds to 7.5 degrees of rotation. Through these 7.5
degrees of rotation, the desired position of the passenger cab would be
stationary. The coordinate system for the mechanism was fixed to the
rotating wheel, and the distance relative to this coordinate system to the
station platform at each discrete increment of wheel rotation (from 266.25°
to 273.75°), would establish the desired path. One point was recorded every
1.875 seconds or 0.375° of wheel rotation. This produced an ideal path
consisting of 21 X-Y position points at equally spaced time intervals from 0 to Figure 2: SolidWorks sketch of the
37.5 seconds. These points are illustrated in relative to the mechanism origin mechanism origin to platform origin
distance. Used to obtain the X-Y
in the figure below.
coordinates of the ideal path.
Figure 3: Illustration of the ideal mechanism path of motion, defined by 21 distinct X-Y locations at equally spaced
time intervals over 37.5 sec
Mechanism Description
To achieve this path a four bar mechanism would be designed. The original goal was to design a four-bar crankrocker mechanism, with a coupler point which would trace out the desired path. The coupler link in the four-bar
mechanism is not pinned to the ground. A coupler curve is generated by tracing the path of a point anchored to
the coupler. The coupler point will be the output of the linkage, and will be the anchor point of the passenger car.
The crank-rocker would be driven by a constant angular velocity motor.
Early optimizer results pointed to the best solution for the coupler four bar mechanism being a double rocker.
While this could produce the desired motion by oscillating the drive motors, it was not the desired solution.
Therefore, the mechanism under consideration was modified. The first effort was to drive the coupler
mechanism’s crank link using a second four-bar mechanism constrained to be a crank-rocker. However, the change
from the original continuous velocity rotational input, to a sinusoidal input, resulted in less than optimal designs.
As a solution, a third four bar was added in series. The results from this optimization produced more encouraging
results. The mechanism as developed for this optimization problem is shown in the illustration below. It consists
of three four-bar loops and has a single degree of freedom.
Coupler Point, C
Loop 1
Loop 2
Figure 4: Mechanism illustration and component breakdown. The 12-bar mechanism has a
single degree of freedom. The angle inputs to Link 9 will be equally spaced so that a constant
speed motor can be used to drive the crank.
Loop 3
Optimizer Setup
In order to arrive at the optimal design, a method of numerical synthesis was employed. The goal is for the coupler
curve is to pass as close as possible through 21 specified points at evenly spaced time intervals. This numerical
synthesis involves a repeated analysis of randomly generated mechanisms, in a search for the best possible
combination. The mechanisms are generated by randomly populating the variable design elements of the
mechanism. These design elements consist of the link lengths, crank angle and coupler point coordinates, which
are necessary for the mechanisms generation. The optimization algorithm then consists of an objective function,
variable bonds, and a set of constraints.
For this project, MATLAB’s built-in genetic algorithm was employed to optimize the path generation of this
mechanism. The genetic algorithm is a method for solving constrained optimization problems based on a natural
selection process that mimics biological evolution. The algorithm continually modifies a population of individual
solutions. At each progressive step in the process, the genetic algorithm selects individuals from a generated
population and uses the most successful as parents to produce the children for the next generation. Similar to the
natural selection process found in nature, the population “evolves” over successive generations toward an optimal
solution. The genetic algorithm is well suited to this problem, since it is not gradient based, it can handle the highly
non-linear nature of the objective function. In addition, the MATLAB built-in genetic algorithm can handle the
nonlinear constraints and variable boundary conditions without the need to employ a separate penalty function.
Design Variables
This optimization problem made use of fourteen design variables which are provided in the table below, along
with their specified upper and lower bounds. Ten of these fourteen variables were the lengths of the links which
make up this mechanism. These links were bounded so that the length of each link remained positive, and so that
the link length did not reach proportions which would be unrealistic for installation onto a 400 foot diameter
wheel, which needed to have space for 30 passenger cars along its perimeter. Design variables N5 and N6 represent
the x and y coordinates respectively of the coupler point, with respect to the local crank-couple coordinate system.
Thus this point’s motion is tied to the motion of the coupler link. The remaining variables, N7 and N8, are the
angular position of 𝜃9 (positioning of the driver link) at time T = 0 and T = 37.5 sec respectively.
Table 1: Design variables used to construct the randomly generated mechanisms
DESIGN
VARIABLE
DESCRIPTION
N4
Link 2
Link 3
Link 4
Link 1
N5
Cu,
N6
Cv,
N7
𝜃9 ,
𝜃9 ,
N1
N2
N3
N8
N9
N10
N11
N12
N13
N14
Link 6
Link 7
Link 5
Link 9
Link 10
Link 8
BOUNDS
Lower
Upper
1 ft.
30 ft.
1 ft.
30 ft.
1 ft.
30 ft.
1 ft.
30 ft.
-40 ft.
30 ft.
-40 ft.
30 ft.
Rotation Angle at time T = 0 sec
-2π
2π
Rotation Angle at time T = 37.5 sec
-2π
2π
1 ft.
30 ft.
1 ft.
30 ft.
1 ft.
30 ft.
1 ft.
30 ft.
1 ft.
30 ft.
1 ft.
30 ft.
x coordinate for coupler point w.r.t.
crank-coupler coordinate system, (x3, y3)
y coordinate for coupler point w.r.t.
crank-coupler coordinate system, (x3, y3)
Objective Function Formulation
The desired path was specified earlier and is defined by 21 points, each with an associated time stamp. In this case
the time stamps are equally spaced since the Ferris wheel is rotating at a constant rate. Each of the 21 increments
of the location of the coupler curve, 𝐶𝑥 and 𝐶𝑦 are generated by calling subroutines. The subroutines provide the
position data of the mechanism, and do so using the position equations of four bar linkages. The method for
running the objective function was as follows:
-
Generate the 21 increments of the driver link rotation angle
o Design variables N7 and N8 represent the driver links rotation angle at the beginning and end
of the 37.5 second dwell. Since the desired motion of the driver link is of continuous, constant
velocity rotation, this span was simply divided into 21 equally spaced increments.
o As a consequence of this methodology, the driver links’ rotational speed is a derived variable.
The required rotational speed of the motor attached to the optimized mechanism will simply
be calculated as:
𝑁8 −𝑁7

-
-
-
37.5 𝑠𝑒𝑐
A for loop is established to run through the 21 required increments.
The four bar subroutine Coupler_Rocker.m is called and is supplied the linkage lengths of Loop 3 along
with the driver angle 𝜃9 for the associated step.
o Coupler_Rocker.m uses the geometric kinematic equations of motion to determine the angle
of the Link 6 rocker, 𝜃6 .
The four bar subroutine Coupler_Rocker.m is called a second time, and is now supplied the linkage
lengths of Loop 2 along with the calculated rocker/crank angle 𝜃6 .
o The output of this subroutine is the angle of the Link 2 rocker, 𝜃2 .
The coupler curve subroutine Coupler.m is called and supplied the linkages of Loop 1 along with the
calculated rocker/crank angle 𝜃2 and the local coordinates Cu and Cv of the coupler point.
o The output of this subroutine is the position of the coupler point relative to the mechanism
origin, 𝐶𝑥 and 𝐶𝑦.
The objective function is set up as the absolute value of the difference between the X and Y coordinates of the
mechanism coupler point, and the ideal point. In the objective function, 𝐶𝑥 and 𝐶𝑦 are the x and y coordinates of
the coupler point relative to the mechanisms’ origin. 𝑃𝑥 and 𝑃𝑦 are the x and y coordinates of the ideal specified
path. The objective function can then be expressed as:
21
1
𝑜𝑏𝑗𝑓𝑢𝑛(𝐶𝑥, 𝐶𝑦, 𝑃𝑥, 𝑃𝑦) = ∑ [ |𝐶𝑥𝑖 − 𝑃𝑥𝑖 | + |𝐶𝑦𝑖 − 𝑃𝑦𝑖 |]
2
𝑖=1
The difference in the X location is multiplied by ½ in order to place a higher level of importance on the vertical
positioning of the optimized mechanism. The reason for this weighting comes from the mass transit study cited
previously, which found that the alighting process was significantly slowed if passengers had to deal with an
elevation change. The function objfun was then minimized using the genetic algorithm.
As an important caveat, there is a potential for the optimizer to generate link lengths for which a mechanism
cannot be constructed. If this is the case, the subroutine Coupler.m provides a default value of 𝐶𝑥 and 𝐶𝑦 equal
to 1000. This high value when incorporated in to the minimization problem, prompts the optimizer to eliminate
this combination from consideration. This method also adds to the non-linearity of the objective function and
further solidifies the selection of a non-gradient based optimizer like the genetic algorithm employed.
Constraints
In addition to the boundary constraints on the size of the design variables N1- N14, additional constraints were
needed to ensure that the optimized mechanism would produce the required motion. In order to achieve the
possibility of continuous motion with the mechanism being designed, Loop 3 needs to be a crank-rocker, with Link
9 functioning as the driver for the mechanism. To meet this requirement, Grashof’s theorem would be employed:
-
-
The crank, Link 9, needs to be the shortest link in Loop 3.
o 𝐿𝑖𝑛𝑘 9 − 𝐿𝑖𝑛𝑘 6 ≤ 0
o 𝐿𝑖𝑛𝑘 9 − 𝐿𝑖𝑛𝑘 8 ≤ 0
o 𝐿𝑖𝑛𝑘 9 − 𝐿𝑖𝑛𝑘 10 ≤ 0
The sum of the lengths of the shortest and longest links needs to be less than the sum of the two
intermediate lengths
o 𝑙 = length of the longest link,
𝑠 = length of the shortest length
𝑝, 𝑞 = length of the two intermediate links
o (𝑙 + 𝑠) − (𝑝 + 𝑞) ≤ 0
The design optimization process will make sure that the crank
is capable of rotation through the range specified by N7 and N8.
However, for continuous rotation, an additional constraint is
needed to make sure that the span of Link 3 and Link 4 is long
enough to allow for continuous rotation of the crank-rocker
mechanism of Loop 3. As Link 9 rotates through a complete 360
degrees of revolution, the diagonal span, d, created by the
angle 𝜃2 , needs to be smaller than the sum of Link 3 and Link 4.
If the sum of Link 3 and Link 4 were shorter than the diagonal,
Link 9 would be stopped short of making a complete rotation.
This constraint is calculated by using the law of cosines to
Link 1
compute the length of the diagonal, d, from known values of
𝜃2 , Link 1, and Link 2. Since the law of cosines is being employed Figure 5: Illustrates the need for the constraint function to
ensure that Link 9 is capable of rotating continuously
and the genetic algorithm is randomly generating the link
lengths, there is a potential for the calculation of the diagonal, d, to yield a complex number. If the result is
complex, the value of this particular constraint was set at a nominal value, outside of the acceptable constraint
tolerance set in the genetic algorithm options. This would force the optimizer to rule out any mechanisms which
result in complex lengths of the diagonal.
-
The diagonal, d, needs to be shorter than the sum of Link 3 and Link 4.
o
𝑚𝑎𝑥(√(𝐿𝑖𝑛𝑘 2)2 + (𝐿𝑖𝑛𝑘 1)2 − 2(𝐿𝑖𝑛𝑘 2)(𝐿𝑖𝑛𝑘 1) cos 𝜃2 ) − (𝐿𝑖𝑛𝑘 3 + 𝐿𝑖𝑛𝑘 4) ≤ 0
 The maximum value is determined by computing the value of the diagonal for every 𝜃2
which results from rotating Link 9 between 0 and 180 degrees in increments of 1
degree.
Due to the previously mentioned highly non-linear nature of this design problem, the optimizer was set to run 10
times, with the best result stored during each successive run, thus incorporating select elements of simulated
annealing optimizers.
Optimizer Results
The best result from the optimizer is provided below:
Table 2: Optimizer results
DESIGN
VARIABLE
N1
N2
N3
N4
N5
N6
N7
N8
N9
N10
N11
N12
N13
N14
DESCRIPTION
OPTIMIZED RESULTS
Link 2
Link 3
Link 4
Link 1
25.8867
ft.
7.6627
ft.
28.5485
ft.
17.0383
ft.
Cu
Cv
-4.8298
ft.
𝜃9 , @ T = 0 sec
𝜃9 , @ T = 37.5 sec
-0.8785
Link 6
Link 7
Link 5
Link 9
Link 10
Link 8
17.2173
ft.
26.5617
ft.
19.4259
ft.
3.9644
ft.
29.9998
ft.
20.7687
ft.
-35.5662 ft.
-2.8251
Working Model Simulation
A simulation of the optimized mechanism was created using Working Model. Unlike the illustrations above, the
loops were not laid out end to end. For space saving reasons, the links were arranged folded back on one another.
This reduced the span of the mechanism from 57.23 ft. to 20.77 ft. a reduction of 36.3%. With the optimized
values of N7 and N8 established, the required speed of the motor attached to Link 9 was calculated as 0.4957 rpm
CW. Position, velocity and acceleration data of the coupler point, C, was recorded and exported to MATLAB for
comparison with the other simulations
Link 1
Link 5
0.496 RPM CW
Link 8
Coupler Point, C
Figure 6: Working Model simulation of the optimized mechanism, identifying the links and illustrating
space saving changes which reduced the span from 57.2 feet to 20.8 feet.
Figure 7: Shows the position of the working model simulation at the start and stop of
the dwell. The image of the mechanism at the end of the dwell also includes a trace of
the coupler curve.
Pro/Engineer Scale Model
Using the optimized results for the mechanism, a 1/100 scale
model was created as a 3D model using Pro/Engineer CREO 2.
Unlike the Working Model simulation, the Pro/E model took the
linkage overlap and potential interference into account so that a
scale model of the assembly could actually be constructed. The
model was designed so that the mechanism could be driven at Link
9 by a constant velocity motor. For this project a ServocCity
precision planetary gear motor operating at 3VDC was used to
drive Link 9. Links 4, 2 and 10 include counter bores which serve to
keep the head of the shoulder bolts flush with the surface of the
links. This was necessary to account for the overlap of the link
lengths and avoid contact between the moving parts. All of the
links with the exception of Link 7, include embossed features Figure 8: Pro/E CREO 1/100th Scale model assembly
around the location of the pin, this limits the links contact surfaces
to just the area immediately around the pin, and avoids frictional contact between the link spans during travel.
Scale Model Creation and Assembly
Once the 3D model was created, and its functionality was checked using
Pro/Engineer Creo’s mechanism simulation, the model was converted to a
stereolithography (.stl) file. Due to station availability, the model was printed
using a MakerBot Replicator 3D Printer. While this printer has substantially
lower dimensional accuracy when
compared to the Somos or Stratasys
models, the ± 150 micron tolerance stack
up and 100 micron layer resolution are Figure 10: CREO part files arranged to
more than sufficient for the purposes of take maximum advantage of the
this model project. The ± 150 micron printable space on the build plate
tolerance stack up has a number of sources, thermal shrink, stepper motor
calibration error, backlash, gantry rod sag, build plate warp and variation in
the filament diameter. The material selected for this project was
NatureWorks® Polyactide Resin (PLA), a reliable 3D printing material which
exhibits less warping and curling then ABS. The anticipated thermal shrink
of this material, approximately 0.6% was compensated for during the
creation of the 3D model.
Figure 9: Assembled 1/100 scale model
with the drive motor attached
Digitized Scale Model Movement
With the scale model constructed, 3.5 seconds of the mechanism movement was recorded. The drive motors
speed at 3 VDC was estimated at 50 rev/min, so 3.5 seconds would provide more than two full revolutions of the
motor. The model was marked with a white marker at the two locations of interest, the mechanism origin and the
coupler point. The dot would make it easier to track the coupler point’s location in the still frames. The video was
recorded using a Canon Rebel T3i and shooting in 1,280 x 720 resolution at 60 fps. Using a MATLAB script published
online, the 211 individual frames were extracted from the video file. The specific frames of interest were frames
3 through 48. These frames followed the path of the coupler point through the full range of its positive velocity xaxis (horizontal) motion. The pixel position of the coupler point for these 46 frames was recorded using Microsoft
Paint. The pixel position was then modified to use the mechanism origin as the axis rather than the edge of the
frame. The pixel position was converted to units of length using the ruler to establish the necessary scaling. Finally
this measurement was increased by the scale of the model 1/100, in order to match the positions used throughout
the rest of this report.
Figure 11: Digitized still frames from four equally spaced times spans tracking the mechanism’s coupler point as it
moves with positive x-direction (horizontal) velocity.
Savitzky-Golay Filter
In order to generate the velocity and acceleration plots of the scale model’s movement, the position data collected
from the digitized frames was filtered using the Savitzky-Golay 7-point cubic interpolant and derivatives code
provided in Notes 05_01. The Savitzky-Golay filter uses the best least squares polynomial fits to approximate the
provided data. Those polynomials are then used to estimate the derivatives. The filter is used to smooth the data,
and thus increase the signal to noise ratio. The Savitzky-Golay code provided in Notes 05_01 works for data which
is equally spaced with time. In this case, the time spacing is the recording rate of the camera equipment, 60 fps,
or one frame every 1/60th of a second. However, the rotational velocity of this scale model is significantly faster
than the optimized mechanism. For comparisons purposes with the other models in this report, the time sampling
interval, h, was scaled so that the rotational speed of the scale model would match that of the optimized
mechanism. The driving crank link attached to the motor was positioned vertically (90° CCW from the horizontal)
in frame 34 and then again in frame 116. Using this information, a more accurate estimate of the drive motor
rotational speed was determined, 43.9 RPM. Thus the sampling interval, h, was scaled up by a factor of 88.566 to
match the optimized mechanisms exceedingly slow 0.4957 RPM CW rotational speed.
Results
In order to study the motion of the optimized mechanism, three different models have been created:
-
-
-
Matlab Model
o Based on the geometric equations of motion for a four bar mechanism and coupler curve
o Used in the objective function of the optimizer
Working Model Simulation
o Uses the 14 optimized design variables to construct the mechanism
o Position, Velocity and Acceleration Data Recorded for the coupler curve point
Scale Model
o Printed from a 1/100 scale model generated in Pro/Engineer CREO
o Position data recorded from digitized video frames
o Velocity and Acceleration calculated through the use of Savitzky-Golay 7-point cubic interpolant
and derivatives
Figure 12: Coupler Point Y-Axis vs. X-Axis Position, Cy vs. Cx.
Figure 13: Coupler Point X-Axis Position (Cx) vs. Time. Root mean square error between the MATLAB and Working Model
simulations and the Ideal Path – 1.096%
Figure 14: Coupler Point Y-Axis Position (Cy) vs. Time. Root mean square error between the MATLAB and Working Model
simulations and the Ideal Path – 1.378%
Figure 15: Coupler Point X-Axis Velocity vs. Time. RMS between the Working Model simulation and the Ideal Path – 0.1044
Figure 16: Coupler Point Y-Axis Velocity vs. Time. RMS between the Working Model simulation and the Ideal Path – 0.0049
Figure 17: Coupler Point X-Axis Acceleration vs. Time. RMS between the Working Model simulation and the Ideal Path – 0.0174
Figure 18: Coupler Point Y-Axis Acceleration vs. Time. RMS between the Working Model simulation and the Ideal Path – 0.0013
Global Model Verification
As a final verification of the success of this optimized model, the Working Model mechanism was secured to a
wheel 400 feet in diameter and rotating at 1/30 RPM. The position of the coupler curve relative to the global
coordinate system could then be determined relative to the ideal. The ideal position in this case is (0, 0), which is
the location of the boarding/alighting platform. The ideal velocity and acceleration, both in X and Y is also zero.
Time = 0 sec
Time = 13.4 sec
Time = 48.1 sec
Time = 57.2 sec
Time = 91.5 sec
Time = 97.6 sec
Time = 114.8 sec
Time = 132.7 sec
Figure 19: Selected frames from a Working Model simulation showing the mechanism installed on a rotating
Ferris wheel and producing a 37.5 second station dwell
Global Model Verification Results
Figure 20: Global Y-Axis Coupler Point Position vs. Time. RMS between the Working Model simulation and the Ideal Path – 0.090
Figure 21: Global Y-Axis Coupler Point Position vs. Time. RMS between the Working Model simulation and the Ideal Path – 0.005
Figure 22: Coupler Point X-Axis Velocity vs. Time. RMS between the Working Model simulation and the Ideal Path – 0.2857
Figure 23: Coupler Point Y-Axis Velocity vs. Time. RMS between the Working Model simulation and the Ideal Path – 0.0185
Conclusion
In conclusion, the functionality of the optimized mechanism to provide a stationary dwell was verified through
the use of three separate simulations. The MATLAB, Working Model and Scale Model simulations all verified the
ability of the design to accurately reproduce the specified ideal path.
Work Cited
"Chapter 3. Station Dwell Times." Transit Capacity and Quality of Service Manual. Washington, D.C.:
Transportation Research Board, 2003. N. pag. Print.
Belegundu, Ashok D., and Tirupathi R. Chandrupatla. "Chapter 7 - Direct Search Methods for Nonlinear
Optimization." Optimization Concepts and Applications in Engineering. New York: Cambridge UP, 2011. N.
pag. Print.
Mehdigholi, Hamid, and Saeed Akbarnejad. "Optimization of Watt’s Six-bar Linkage to Generate Straight and
Parallel Leg Motion." Journal of Humanoids 9.22 (2012): n. pag. Print.
"Genetic Algorithm." - MATLAB. N.p., n.d. Web. 17 Apr. 2015.
Analyst, Image. Demo Macro to Extract Frames and Get Frame Means from an Avi Movie and save Individual
Frames to Separate Image Files. Computer software. MATLAB Central. MathWorks, 1 Mar. 2012. Web.
Saadeh, Mohammad. Four_Bar_Linkage.m. Computer software. MATLAB Central. Vers. 2. MathWorks, 26
July 2011. Web.
Natesan, Arun K., "Kinematic analysis and synthesis of four-bar mechanisms for straight line coupler curves"
(1994). Thesis. Rochester Institute of Technology. Accessed from
Sommer, H. J., III. Filt_7pt_mat.m. Computer software. The Pennsylvania State University, 08 Feb. 2011.
Web. <www.mne.psu.edu/sommer/>.
Petroski, Henry. "Millennium Legacies." Pushing the Limits: New Adventures in Engineering. New York: Knopf,
2004. N. pag. Print.
Appendix A
MATLAB Code
Main Optimizer Program
function [] = ME481_Project_2()
clear all;
close all;
format long;
%Establish ideal points
ns = 21;
PX(1) = -13.734657;
PX(2) = -12.362869;
PX(3) = -10.990551;
PX(4) = -9.617762;
PX(5) = -8.244561;
PX(6) = -6.871007;
PX(7) = -5.497159;
PX(8) = -4.123075;
PX(9) = -2.748815;
PX(10) = -1.374437;
PX(11) = 0;
PX(12) = 1.374437;
PX(13) = 2.748815;
PX(14) = 4.123075;
PX(15) = 5.497159;
PX(16) = 6.871007;
PX(17) = 8.244561;
PX(18) = 9.617762;
PX(19) = 10.990551;
PX(20) = 12.362869;
PX(21) = 13.734657;
PY(1) = -9.550374;
PY(2) = -9.635778;
PY(3) = -9.712202;
PY(4) = -9.779643;
PY(5) = -9.838098;
PY(6) = -9.887563;
PY(7) = -9.928038;
PY(8) = -9.959521;
PY(9) = -9.982009;
PY(10) = -9.995502;
PY(11) = -10;
PY(12) = -9.995502;
PY(13) = -9.982009;
PY(14) = -9.959521;
PY(15) = -9.928038;
PY(16) = -9.887563;
PY(17) = -9.838098;
PY(18) = -9.779643;
PY(19) = -9.712202;
PY(20) = -9.635778;
PY(21) = -9.550374;
% Bounds for the design variables
xL = [1
xU = [30
1
30
1
30
1
30
-40
30
-40
30
-2*pi()
2*pi()
-2*pi()
2*pi()
1
30
1
30
1
1
30
1 1];
30 30
30];
fmin_best = 100;
for n=1:10;
% Genetic Algorithm Optimization Callout
[ Xopt, fmin ] = ga( @(X)obj(X, PX, PY, ns), 14, [], [], [], [], xL, xU, @(X)ctr(X));
% Loop optimizer to search for best design
if fmin < fmin_best
fmin_best = fmin;
Xopt_best = Xopt;
Xopt_best
fmin_best
end
disp(sprintf('n = %0.0f
fmin best =
%0.1f ', n, fmin_best));
end
Xopt_best
fmin_best
function [ J ] = obj( X, PX, PY, ns )
%Establish the objective function
f = 0;
th1 = linspace(X(7),X(8),ns);
FourBar1 = [X(1) X(2) X(3) X(4) X(5)
FourBar2 = [X(9) X(10) X(1) X(11)];
FourBar3 = [X(12) X(13) X(9) X(14)];
X(6)];
for ks = 1:ns
[th4_1] = Coupler_Rocker(FourBar3, th1(ks));
[th4_2] = Coupler_Rocker(FourBar2, th4_1);
[Cx, Cy] = Coupler(FourBar1,th4_2);
f = f + .5*abs(Cx-PX(ks));
f = f + abs(Cy-PY(ks));
end
J = f;
function [ c, ceq ] = ctr( X )
%Generate the constraint functions
ceq = [];
c(1) = X(12)-X(9);
c(2) = X(12)-X(13);
c(3) = X(12)-X(14);
%Grashoff's Theorem for Crank Rocker
XLink = [X(9) X(12) X(13) X(14)];
XSift = sort(XLink);
c(4) = (XSift(4)+XSift(1))-(XSift(2)+XSift(3));
FourBar2 = [X(9) X(10) X(1) X(11)];
FourBar3 = [X(12) X(13) X(9) X(14)];
%Constraint to allow for continuous rotation of Link 9
theta = linspace(0,pi,180);
for ks = 1:180
[th4_1] = Coupler_Rocker(FourBar3, theta(ks));
[th4_2] = Coupler_Rocker(FourBar2, th4_1);
b = X(1);
c_tri = X(4);
a = X(2)+X(3);
hyp(ks) = b^2+c_tri^2-2*b*c_tri*cos(th4_2);
end
if isreal(max(hyp)) > 0
c(5) = max(hyp)-a^2;
else
c(5) = .1;
end
Crank_Rocker.m Subroutine
function [ th4 ] = Coupler_Rocker( X, TH1)
%Specify the Links
r2 = X(1); %Crank
r3 = X(2); %Coupler
r4 = X(3); %Rocker
r1 = X(4); %Frame
%Geometric Equations of a Four-Bar
e = sqrt( r1*r1 + r2*r2 - 2*r1*r2*cos(TH1) );
alpha = asin( r2 * sin(TH1) / e );
gamma = acos( ( r3*r3 + r4*r4 - e*e ) /2 /r3 /r4 );
beta = asin( r3 * sin(gamma) / e );
th4 = pi - alpha - beta;
Coupler.m Subroutine
function [ Cx, Cy ] = Coupler( X, TH1)
%
%
%
%
%
%
r1:
r2:
r3:
r4:
Cu:
Cv:
Crank
Coupler
Rocker
Frame
x coordinate for coupler point wrt crank-coupler point
y coordinate for coupler point wrt crank-coupler point
%% check the geometry
P = X(1:4);
check = P;
[L locL] = max(check);
check(locL) = [];
[S locS] = min(check);
check(locS) = [];
R = check;
flag = 0;
if S==X(4) & sum(check)>(L+S)
%TITLE = 'This is a Double-Crank Mechanism';
elseif (S==X(1)|S==X(3)) & sum(check)>(L+S)
%TITLE = 'This is a Rocker-Crank Mechanism';
elseif S==X(2) & sum(check)>(L+S)
%TITLE = 'This is a Double-Rocker Mechanism';
flag = 1;
elseif sum(check)==(L+S)
%TITLE = 'This is a Change Point Mechanism';
elseif sum(check)<(L+S)
flag = 1;
%TITLE = 'This is a Double-Rocker Mechanism';
end
%%
%TH1 = linspace(0,2*pi,INCREMENTS);% Input angle theta1
dig = 10;% divide links into this number
R1 = X(1); r1 = linspace(0,R1,dig);
R2 = X(2); r2 = linspace(0,R2,dig);
R3 = X(3); r3 = linspace(0,R3,dig);
R4 = X(4); r4 = linspace(0,R4,dig);
Cu = X(5); cu = linspace(0,Cu,dig);
Cv = X(6); cv = linspace(0,Cv,dig);
%% check valid region
D = sqrt(R1^2 + R4^2 - 2*R1*R4*cos(TH1));% diagonal distance between
%
crank-coupler point and rocker-frame point
TH5 = acos((R3^2+D.^2-R2^2)./(2*R3*D));% angle between rocker and diagonal
%
link (d)
IMAG = imag(TH5);
[VALUES LOCATION] = find(IMAG==0);
%%
IMAG = imag(TH5);
LOCATION = IMAG==0;
LOCATION1 = find(IMAG==0);
LOC = LOCATION;
n = length(LOCATION);
n1 = length(LOCATION1);
Check = 0;
direction = 1;
for i=1:n-1
if LOC(i+1)~=LOC(i)
if Check==0
direction = LOC(i);
end
Check = Check+1;
end
end
%%
Rotate = 0;
if isempty(LOCATION1)
% Return unusable values if mechanism cannot be constructed
Cx = 1000;
Cy = 1000;
return
elseif direction==0 & Check==2
LOC1 = find(LOCATION==1);
th1 = [TH1(LOC1) TH1(fliplr(LOC1))];
elseif n1==n
th1 = TH1;
elseif direction==1 & Check==2
Rotate = 1;
loc1 = LOC(1:end-1);
loc2 = LOC(2:end);
[Value deadpoint] = find((loc2-loc1)~=0);
deadp = deadpoint + [0 1];
LOC2 = [deadp(2):n 1:deadp(1)];
th1 = [TH1(LOC2) TH1(fliplr(LOC2))];
elseif Check==4
Rotate = 1;
loc1 = LOC(1:end-1);
loc2 = LOC(2:end);
[Value deadpoint] = find((loc2-loc1)~=0);
deadp1 = deadpoint(1:2) + [1 0];
deadp2 = deadpoint(3:4) + [1 0];
fprintf('This mechanism has two disconnected upper and lower regions\n');
DIREC = 1;
DIREC = input('Select [1] for upper, [2] for lower
Default = [1] ');
if DIREC == 1
LOC3 = [deadp1(1):deadp1(2)];
else
LOC3 = [deadp2(1):deadp2(2)];
end
th1 = [TH1(LOC3) TH1(fliplr(LOC3))];
end
d = sqrt(R1^2 + R4^2 - 2*R1*R4*cos(th1));
th5 = acos((R3^2+d.^2-R2^2)./(2*R3*d));% angle between rocker and
%%
if Rotate == 1
d = sqrt(R1^2 + R4^2 - 2*R1*R4*cos(th1));
th5 = acos((R3^2+d.^2-R2^2)./(2*R3*d));% angle between rocker and diagonal link (d)
th5 = [th5(1:end/2) -th5(end/2+1:end)];
end
Ax = R1*cos(th1);% x coordinate for the crank-coupler point
Ay = R1*sin(th1);% y coordinate for the crank-coupler point
a = R4 - R1*cos(th1);% horizontal distance between rocker-frame point and
%
projection of crank-coupler point
b = Ay;% vertical projection of crank-coupler point
th6 = atan2(b,a);% angle between frame and diagonal link (d)
th4 = pi - th5 - th6;% angle the rocker makes with horizon
Bx = R3*cos(th4) + R4;% horizontal distance between frame-crank point and
%
projection of coupler-rocker point
By = R3*sin(th4);% vertical projection of coupler-rocker point
th2 = atan2((By-Ay),(Bx-Ax));% angle the coupler makes with the horizon
Cx = Ax + Cu*cos(th2) - Cv*sin(th2);% horizontal projection of coupler
%
point wrt coupler
Cy = Ay + Cu*sin(th2) + Cv*cos(th2);% vertical projection of coupler
%
point wrt coupler
Results/Plots Generation Program
close all;
X = [25.886708287314995
7.662669225727093 28.548482676508119 ...
17.038343453626993 -4.829793937429081 -35.566234720237951 ...
-0.878496745204756 -2.825134609276901 17.217345550477422 ...
26.561669336798424 19.425896622459771
3.964412479214395 ...
29.999793871337470 20.768686006325492];
%Load the optimized values into the respective loops
FourBar1 = [X(1) X(2) X(3) X(4) X(5) X(6)];
FourBar2 = [X(9) X(10) X(1) X(11)];
FourBar3 = [X(12) X(13) X(9) X(14)];
%Ideal point path
PX(1) = -13.734657;
PX(2) = -12.362869;
PX(3) = -10.990551;
PX(4) = -9.617762;
PX(5) = -8.244561;
PX(6) = -6.871007;
PX(7) = -5.497159;
PX(8) = -4.123075;
PX(9) = -2.748815;
PX(10) = -1.374437;
PX(11) = 0;
PX(12) = 1.374437;
PX(13) = 2.748815;
PX(14) = 4.123075;
PX(15) = 5.497159;
PX(16) = 6.871007;
PX(17) = 8.244561;
PX(18) = 9.617762;
PX(19) = 10.990551;
PX(20) = 12.362869;
PX(21) = 13.734657;
PY(1) = -9.550374;
PY(2) = -9.635778;
PY(3) = -9.712202;
PY(4) = -9.779643;
PY(5) = -9.838098;
PY(6) = -9.887563;
PY(7) = -9.928038;
PY(8) = -9.959521;
PY(9) = -9.982009;
PY(10) = -9.995502;
PY(11) = -10;
PY(12) = -9.995502;
PY(13) = -9.982009;
PY(14) = -9.959521;
PY(15) = -9.928038;
PY(16) = -9.887563;
PY(17) = -9.838098;
PY(18) = -9.779643;
PY(19) = -9.712202;
PY(20) = -9.635778;
PY(21) = -9.550374;
ns = 21;
%Create theta nine from equally space increments of the span between
%design variable N7 and N8
th1 = linspace(X(7),X(8),ns);
t = linspace(0,37.5, 21);
%Calculate the opmitmized mechanims position at each of the 21 points
for ks = 1:21
[th4_1] = Coupler_Rocker(FourBar3, th1(ks));
[th4_2] = Coupler_Rocker(FourBar2, th4_1);
[Cx, Cy] = Coupler(FourBar1,th4_2);
X_matlab(ks) = Cx;
Y_matlab(ks) = Cy;
end
%Load the data from the Working Model Simulation
WM_data = load ('C:\Users\jeffl_000\Desktop\M E 481\Project\Project Crank 15.dta');
time = WM_data(:,3);
x_coupler = WM_data(:,4);
y_coupler = WM_data(:,5);
xd_coupler = WM_data(:,10);
yd_coupler = WM_data(:,11);
xdd_coupler = WM_data(:,15);
ydd_coupler = WM_data(:,16);
h = (1/60)/0.011291;
ideal_data = horzcat(PX',PY');
h_ideal = 1.875;
%Determine the velocity and acceleration associated with the ideal path
[ideal_p, ideal_v, ideal_a] = filt_7pt_mat(ideal_data',h_ideal);
ideal_X7p = ideal_p(1,:);
ideal_Y7p = ideal_p(2,:);
ideal_Xd7p = ideal_v(1,:);
ideal_Yd7p = ideal_v(2,:);
ideal_Xdd7p = ideal_a(1,:);
ideal_Ydd7p = ideal_a(2,:);
%Load the Digitized results
XYdata = load('C:\Users\jeffl_000\Desktop\M E 481\Project\Digitized Mechanism.txt');
%Run the Solitzky-Golay code on the digitied data
[p, v, a] = filt_7pt_mat(XYdata',h);
X7p = p(1,:);
Y7p = p(2,:);
Xd7p = v(1,:);
Yd7p = v(2,:);
Xdd7p = a(1,:);
Ydd7p = a(2,:);
T = linspace(0,h*47,48);
%Load the optimized mechanism global simulation data from Working Model
WM_data_wheel = load ('C:\Users\jeffl_000\Desktop\M E 481\Project\Project9.dta');
time_wheel = WM_data_wheel(:,1);
x_c_wheel = WM_data_wheel(:,7);
y_c_wheel = WM_data_wheel(:,8);
xd_c_wheel = WM_data_wheel(:,2);
yd_c_wheel = WM_data_wheel(:,3);
%Ideal Data of for Global simulation comparison
t1 = [0 37.5];
x1 = [0
0];
y1 = [0
0];
Global_Ideal = zeros(1,21);
%Load Abbreviated working model data for calculation of RMS values
WM_Cor = load ('C:\Users\jeffl_000\Desktop\M E 481\Project\WM_Cor.txt');
WM_Cor_X = WM_Cor(:,1);
WM_Cor_Xd = WM_Cor(:,3);
WM_Cor_Yd = WM_Cor(:,4);
WM_Cor_Xdd = WM_Cor(:,5);
WM_Cor_Ydd = WM_Cor(:,6);
Global_Cor = load ('C:\Users\jeffl_000\Desktop\M E 481\Project\Global_Cor.txt');
Global_Cor_X = Global_Cor(:,1);
Global_Cor_Y = Global_Cor(:,2);
Global_Cor_Xd = Global_Cor(:,3);
Global_Cor_Yd = Global_Cor(:,4);
%Calculate the normalized and standardized RMS for curve fitting error
% estimation
posx_R1 = rms(PX-X_matlab)/(max(X_matlab)-min(X_matlab))*100
posy_R2 = rms(PY-Y_matlab)/(max(Y_matlab)-min(Y_matlab))*100
velx_R3 = rms(ideal_Xd7p-WM_Cor_Xd')/(std(WM_Cor_Xd))
vely_R4 = rms(ideal_Yd7p-WM_Cor_Yd')/(std(WM_Cor_Yd))
accx_R5 = rms(ideal_Xdd7p-WM_Cor_Xdd')/(std(WM_Cor_Xdd))
accy_R6 = rms(ideal_Ydd7p-WM_Cor_Ydd')/(std(WM_Cor_Ydd))
globalposx_R1 = rms(Global_Ideal-Global_Cor_X')/(std(Global_Cor_X))
globalposy_R1 = rms(Global_Ideal-Global_Cor_Y')/(std(Global_Cor_Y))
globalvelx_R1 = rms(Global_Ideal-Global_Cor_Xd')/(std(Global_Cor_Xd))
globalvely_R1 = rms(Global_Ideal-Global_Cor_Yd')/(std(Global_Cor_Yd))
posx_R1 = rms(PX-X_matlab)
posy_R2 = rms(PY-Y_matlab)
velx_R3 = rms(ideal_Xd7p-WM_Cor_Xd')
vely_R4 = rms(ideal_Yd7p-WM_Cor_Yd')
accx_R5 = rms(ideal_Xdd7p-WM_Cor_Xdd')
accy_R6 = rms(ideal_Ydd7p-WM_Cor_Ydd')
globalposx_R1 = rms(Global_Ideal-Global_Cor_X')
globalposy_R1 = rms(Global_Ideal-Global_Cor_Y')
globalvelx_R1 = rms(Global_Ideal-Global_Cor_Xd')
globalvely_R1 = rms(Global_Ideal-Global_Cor_Yd')
%Create Plots
% Create figure
figure1 = figure;
% Create axes
axes1 = axes('Parent',figure1,'XTick',[-13.75 -8.25 -2.75 2.75 8.25 13.75],...
'XMinorTick','on',...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes1,[-13.75 13.75]);
%% Uncomment the following line to preserve the Y-limits of the axes
ylim(axes1,[-10.1 -9.4]);
box(axes1,'on');
hold(axes1,'all');
% Create plot
plot(PX,PY,'Parent',axes1,'MarkerFaceColor',[0 0.498039215803146 0],...
'Marker','o',...
'LineWidth',1.5,...
'Color',[0 0.498039215803146 0],...
'DisplayName','Ideal Path');
% Create plot
plot(x_coupler, y_coupler,'Parent',axes1,'LineWidth',2,'Color',[0 0 1],...
'DisplayName','Working Model Simulation');
% Create plot
plot(X_matlab, Y_matlab,'Parent',axes1,'MarkerFaceColor',[1 0 0],'Marker','square',...
'LineWidth',1.5,...
'DisplayName','Matlab Simulation');
% Create plot
plot(X7p, Y7p,'Parent',axes1,'LineWidth',2,...
'DisplayName','Scale Model, Savitsky-Golay Interpolants');
% Create xlabel
xlabel('Coupler Point X-Axis Position, Cx, (ft)','FontSize',12);
% Create ylabel
ylabel('Coupler Point Y-Axis Position, Cy, (ft)','FontSize',12);
% Create title
title('Coupler Point X-Axis vs Y-Axis Position, Cx vs Cy','FontSize',12);
% Create legend
legend1 = legend(axes1,'show');
set(legend1,...
'Position',[0.663789682539685 0.770445463326846 0.206448412698412 0.13477366255144],...
'FontSize',12);
figure2 = figure (2);
% Create axes
axes2 = axes('Parent',figure2,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes2,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
box(axes2,'on');
hold(axes2,'all');
% Create plot
plot(t,PX,'Parent',axes2,'MarkerFaceColor',[0 0.498039215803146 0],...
'Marker','o',...
'LineWidth',1.5,...
'Color',[0 0.498039215803146 0],...
'DisplayName','Ideal Path');
% Create plot
plot(time-22.75, x_coupler,'Parent',axes2,'LineWidth',2,'Color',[0 0 1],...
'DisplayName','Working Model Simulation');
% Create plot
plot(t, X_matlab,'Parent',axes2,'MarkerFaceColor',[1 0 0],'Marker','square',...
'LineWidth',1.5,...
'DisplayName','Matlab Simulation');
% Create plot
plot(T-19.63, X7p,'Parent',axes2,'LineWidth',2,...
'DisplayName','Scale Model, Savitsky-Golay Interpolants');
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Coupler Point X-Axis Position, Cx, (ft)','FontSize',12);
% Create title
title('Coupler Point X-Axis Position (Cx) vs Time','FontSize',12);
% Create legend
legend1 = legend(axes2,'show');
set(legend1,...
'Position',[0.663789682539685 0.770445463326846 0.206448412698412 0.13477366255144],...
'FontSize',12);
figure3 = figure (3);
% Create axes
axes3 = axes('Parent',figure3,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes3,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
box(axes3,'on');
hold(axes3,'all');
% Create plot
plot(t,PY,'Parent',axes3,'MarkerFaceColor',[0 0.498039215803146 0],...
'Marker','o',...
'LineWidth',1.5,...
'Color',[0 0.498039215803146 0],...
'DisplayName','Ideal Path');
% Create plot
plot(time-22.75, y_coupler,'Parent',axes3,'LineWidth',2,'Color',[0 0 1],...
'DisplayName','Working Model Simulation');
% Create plot
plot(t, Y_matlab,'Parent',axes3,'MarkerFaceColor',[1 0 0],'Marker','square',...
'LineWidth',1.5,...
'DisplayName','Matlab Simulation');
% Create plot
plot(T-19.63, Y7p,'Parent',axes3,'LineWidth',2,...
'DisplayName','Scale Model, Savitsky-Golay Interpolants');
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Coupler Point Y-Axis Position, Cy, (ft)','FontSize',12);
% Create title
title('Coupler Point Y-Axis Position (Cy) vs Time','FontSize',12);
% Create legend
legend1 = legend(axes3,'show');
set(legend1,...
'Position',[0.663789682539685 0.770445463326846 0.206448412698412 0.13477366255144],...
'FontSize',12);
figure4 = figure (4);
% Create axes
axes4 = axes('Parent',figure4,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes4,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
box(axes4,'on');
hold(axes4,'all');
% Create plot
plot(t,ideal_Xd7p,'Parent',axes4,'MarkerFaceColor',[0 0.498039215803146 0],...
'Marker','o',...
'LineWidth',1.5,...
'Color',[0 0.498039215803146 0],...
'DisplayName','Ideal Path');
% Create plot
plot(time-22.75, xd_coupler,'Parent',axes4,'LineWidth',2,'Color',[0 0 1],...
'DisplayName','Working Model Simulation');
% Create plot
plot(T-19.63, Xd7p,'Parent',axes4,'LineWidth',2,...
'DisplayName','Scale Model, Savitsky-Golay Interpolants');
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Coupler Point X-Axis Velocity, (ft/sec)','FontSize',12);
% Create title
title('Coupler Point X-Axis Velocity vs Time','FontSize',12);
% Create legend
legend1 = legend(axes4,'show');
set(legend1,...
'Position',[0.663789682539685 0.770445463326846 0.206448412698412 0.13477366255144],...
'FontSize',12);
figure5 = figure (5);
% Create axes
axes5 = axes('Parent',figure5,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes5,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
box(axes5,'on');
hold(axes5,'all');
% Create plot
plot(t,ideal_Yd7p,'Parent',axes5,'MarkerFaceColor',[0 0.498039215803146 0],...
'Marker','o',...
'LineWidth',1.5,...
'Color',[0 0.498039215803146 0],...
'DisplayName','Ideal Path');
% Create plot
plot(time-22.75, yd_coupler,'Parent',axes5,'LineWidth',2,'Color',[0 0 1],...
'DisplayName','Working Model Simulation');
% Create plot
plot(T-19.63, Yd7p,'Parent',axes5,'LineWidth',2,...
'DisplayName','Scale Model, Savitsky-Golay Interpolants');
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Coupler Point Y-Axis Velocity, (ft/sec)','FontSize',12);
% Create title
title('Coupler Point Y-Axis Velocity vs Time','FontSize',12);
% Create legend
legend1 = legend(axes5,'show');
set(legend1,...
'Position',[0.663789682539685 0.770445463326846 0.206448412698412 0.13477366255144],...
'FontSize',12);
figure6 = figure (6);
% Create axes
axes6 = axes('Parent',figure6,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes6,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
box(axes6,'on');
hold(axes6,'all');
% Create plot
plot(t,ideal_Xdd7p,'Parent',axes6,'MarkerFaceColor',[0 0.498039215803146 0],...
'Marker','o',...
'LineWidth',1.5,...
'Color',[0 0.498039215803146 0],...
'DisplayName','Ideal Path');
% Create plot
plot(time-22.75, xdd_coupler,'Parent',axes6,'LineWidth',2,'Color',[0 0 1],...
'DisplayName','Working Model Simulation');
% Create plot
plot(T-19.63, Xdd7p,'Parent',axes6,'LineWidth',2,...
'DisplayName','Scale Model, Savitsky-Golay Interpolants');
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Coupler Point X-Axis Acceleration, (ft/sec^2)','FontSize',12);
% Create title
title('Coupler Point X-Axis Acceleration vs Time','FontSize',12);
% Create legend
legend1 = legend(axes6,'show');
set(legend1,...
'Position',[0.663789682539685 0.770445463326846 0.206448412698412 0.13477366255144],...
'FontSize',12);
figure7 = figure (7);
% Create axes
axes7 = axes('Parent',figure7,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes7,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
box(axes7,'on');
hold(axes7,'all');
% Create plot
plot(t,ideal_Ydd7p,'Parent',axes7,'MarkerFaceColor',[0 0.498039215803146 0],...
'Marker','o',...
'LineWidth',1.5,...
'Color',[0 0.498039215803146 0],...
'DisplayName','Ideal Path');
% Create plot
plot(time-22.75, ydd_coupler,'Parent',axes7,'LineWidth',2,'Color',[0 0 1],...
'DisplayName','Working Model Simulation');
% Create plot
plot(T-19.63, Ydd7p,'Parent',axes7,'LineWidth',2,...
'DisplayName','Scale Model, Savitsky-Golay Interpolants');
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Coupler Point Y-Axis Acceleration, (ft/sec^2)','FontSize',12);
% Create title
title('Coupler Point Y-Axis Acceleration vs Time','FontSize',12);
% Create legend
legend1 = legend(axes7,'show');
set(legend1,...
'Position',[0.663789682539685 0.770445463326846 0.206448412698412 0.13477366255144],...
'FontSize',12);
figure8 = figure (8);
% Create axes
axes8 = axes('Parent',figure8,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes8,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
% ylim(axes1,[-1 0.6]);
box(axes8,'on');
hold(axes8,'all');
% Create plot
plot(time_wheel,x_c_wheel,'Parent',axes8,'LineWidth',2,'DisplayName','Optimized Mechanism');
% Create plot
plot(t1, x1,'Parent',axes8,'LineWidth',2,'DisplayName','Ideal Path');
% Create title
title('Global X-Axis Coupler Point Position vs Time','FontSize',12);
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Global X-Axis Coupler Point Position, (ft)','FontSize',12);
% Create legend
legend1 = legend(axes8,'show');
set(legend1,...
'Position',[0.766269841269842 0.832304526748971 0.126785714285714 0.0709876543209876],...
'FontSize',12);
figure9 = figure (9);
% Create axes
axes9 = axes('Parent',figure9,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes9,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
% ylim(axes1,[-1 0.6]);
box(axes9,'on');
hold(axes9,'all');
% Create plot
plot(time_wheel,y_c_wheel,'Parent',axes9,'LineWidth',2,'DisplayName','Optimized Mechanism');
% Create plot
plot(t1, y1,'Parent',axes9,'LineWidth',2,'DisplayName','Ideal Path');
% Create title
title('Global Y-Axis Coupler Point Position vs Time','FontSize',12);
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Global Y-Axis Coupler Point Position, (ft)','FontSize',12);
% Create legend
legend1 = legend(axes9,'show');
set(legend1,...
'Position',[0.766269841269842 0.832304526748971 0.126785714285714 0.0709876543209876],...
'FontSize',12);
figure10 = figure (10);
% Create axes
axes10 = axes('Parent',figure10,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes10,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
% ylim(axes1,[-1 0.6]);
box(axes10,'on');
hold(axes10,'all');
% Create plot
plot(time_wheel,xd_c_wheel,'Parent',axes10,'LineWidth',2,'DisplayName','Optimized Mechanism');
% Create plot
plot(t1, x1,'Parent',axes10,'LineWidth',2,'DisplayName','Ideal Path');
% Create title
title('Global X-Axis Coupler Point Velocity vs Time','FontSize',12);
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Global X-Axis Coupler Point Velocity, (ft/sec)','FontSize',12);
% Create legend
legend1 = legend(axes1,'show');
set(legend1,...
'Position',[0.766269841269842 0.832304526748971 0.126785714285714 0.0709876543209876],...
'FontSize',12);
figure11 = figure (11);
% Create axes
axes11 = axes('Parent',figure11,'XTick',[0 5.5 11 16.5 22 27.5 33 37.5],...
'XGrid','on');
%% Uncomment the following line to preserve the X-limits of the axes
xlim(axes11,[0 37.5]);
%% Uncomment the following line to preserve the Y-limits of the axes
% ylim(axes1,[-1 0.6]);
box(axes11,'on');
hold(axes11,'all');
% Create plot
plot(time_wheel,yd_c_wheel,'Parent',axes11,'LineWidth',2,'DisplayName','Optimized Mechanism');
% Create plot
plot( t1, y1,'Parent',axes11,'LineWidth',2,'DisplayName','Ideal Path');
% Create title
title('Global Y-Axis Coupler Point Velocity vs Time','FontSize',12);
% Create xlabel
xlabel('Time, (sec)','FontSize',12);
% Create ylabel
ylabel('Global Y-Axis Coupler Point Velocity, (ft/sec)','FontSize',12);
% Create legend
legend1 = legend(axes11,'show');
set(legend1,...
'Position',[0.766269841269842 0.832304526748971 0.126785714285714 0.0709876543209876],...
'FontSize',12);
M E 481 Final Project Report
Daniel Lutz
An Analysis of a Sickle Bar Drive System
The purpose of this project was to model and analyze the behavior of a sickle drive mechanism,
and in doing so compare the use of Working Model 2D and SolidWorks for the analysis of a 3D
mechanism. This mechanism is used to convert rotary motion into a reciprocating linear motion parallel
to the rotary axis of rotation of the power source. A primary application of this mechanism is older
combine heads used for the harvesting of grains. A combine is a machine used for cutting, threshing and
separating grain from the undesirable residue. On the front of a combine an attachment, called a head,
is used to cut and feed crops into the main machine. An example of a combine and head is shown in
Figure 1. For cutting crops such as wheat or soybeans a sickle bar is used to cut the crops off of the roots
and lower parts of the stem.
Figure 1: Combine harvesting soybeans
A sickle bar functions in a similar manner to a pair of scissors. Sharpened knives, A-Figure 2, are
attached to a reciprocating bar, #7-Figure 2. These knives together with stationary pieces known as
guards, B-Figure 2, shear the stems of crops, allowing them to be fed into the combine to be threshed.
For crops such as wheat where the grain is found in heads that are typically more than a foot off the
ground, the sickle bar is rigidly mounted to the head and is kept at a fairly consistent height off the
ground during a normal pass through the field. When harvesting soybeans however, the pods containing
the soybeans can often be one or two inches off of the ground. Therefore before electronic control
systems were invented to automatically adjust the height of the head, the cutter bar was designed with
vertical floating capability to allow it to follow the ground contours. One mechanism implemented to
drive this floating cutter bar is the focus of this project.
6
7
A
B
Figure 2: Sickle Bar Components: A-Sharpened Knife, B-Guard, 6-Sickle Drive Arm, 7-Sickle Bar
Typically, most drive shafts in a combine as well as the engine’s crankshaft will be mounted
perpendicular to the direction of travel. Therefore, the belts and chain used to transmit power
throughout the machine will be in the direction of travel. This along with the requirement that the sickle
bar must be allowed to move independently of the rest of the head make the use of a traditional slider
crank mechanism to provide the reciprocating motion of the sickle bar difficult. Additionally, it is
desirable to have the drive mechanism for the sickle maintain a low profile so it does not knock over
uncut crop next to the head.
2
7
3
4
5
Figure 3: Sickle Bar Drive Components: 2-Main Drive Pulley, 3-Eccentrically Mounted Bearing,
4-Driver Arm, 5-Rocker Arm, 7-Floating Sickle Bar
One mechanism designed to meet the aforementioned requirements is shown in Figure 3. A
drive shaft coming from the combine, #1-Figure 4, drives the main drive pulley, #2-Figure 3 & 4.
Mounted on this pulley is an eccentrically mounted bearing, #3-Figure 3 & 4. This bearing is connected
to the driver arm, #4-Figure 3 & 4, which is in turn connected to the rocker arm, #5-Figure 3. The rocker
arm is a curved piece that rotates about a vertical axis. The eccentric bearing, driver arm and rocker arm
together produce a rotary reciprocating motion. The rocker arm is also connected to the sickle drive
arm, #3-Figure 4 & #4-Figure 2, which drives the sickle bar in a reciprocating linear fashion.
1
4
3
2
Figure 4: 1-Main Head Drive Shaft, 2-Main Sickle Drive Pulley, 3-Eccentrically Mounted Bearing,
4-Driver Arm
4
7
6
5
Figure 5: 4-Driver Arm, 5-Rocker Arm, 6-Sickle Drive Arm, 7-Floating Sickle Bar
Table 1 provides relevant dimensions of the mechanism. Figure 6 provides a skeletal diagram of
the mechanism as modified for analysis in two dimensions. Because the software package Working
Model is limited to operating in three dimensions, it was necessary to project the original 3D mechanism
into two dimensions. The mechanism consists of 6 links with 7 J1 single degree-of-freedom (DOF) joints.
Therefore, according to the 2D mobility equation, Equation 1, the mechanism has the anticipated single
degree of freedom. Figure 7 illustrates the modeling of this mechanism in Working Model.
Table 1: Relevant Dimensions of Mechanism
Dimension
Value
Main Drive Pulley Speed
466 RPM
Main Drive Pulley Eccentricity
1.5 in
Driver Arm Length
24.25 in
Rocker Arm
Pivot to Driver Arm Attachment
6 in
Radius
Pivot to Sickle Drive Arm Radius
8 in
Angle Between Driver Arm and
105°
Sickle Drive Arm Attachment
Sickle Drive Arm Length
30.5 in
Center of Main Drive Pulley to
26 in
Rocker Arm Pivot
Center of Main Drive Pulley to Sickle
39 in
7
F
6
E
D
5
4
B
2
A
C
Figure 6: Skeletal diagram of sickle drive mechanism modified to two dimensions
𝑀𝑜𝑏𝑖𝑙𝑖𝑡𝑦 = 3(𝑁𝑢𝑚. 𝐿𝑖𝑛𝑘𝑠 − 1) − 2(𝑁𝑢𝑚. 𝐽1) − 𝑁𝑢𝑚. 𝐽2
(1)
Figure 7: Modeling of sickle drive mechanism in Working Model 2D
Working Model was used to find the relationship between the position of the constant 466 RPM
speed of the main drive pulley and the position, velocity and acceleration of the sickle bar which is in
turn operating at 466 cycles per minute. Figures 8-10 illustrate that the sickle has a roughly sinusoidal
plot of position which translates to sinusoidal velocity and acceleration plots as well.
Driver vs. Sickle Position
4.5
4
3.5
Sickle Position (in)
3
2.5
2
1.5
1
0.5
0
-0.5
0
100
200
300
400
500
600
700
Rotation of Drive Pulley (°)
800
900
1000
Figure 8: Plot of sickle position in relation to rotation of the main drive pulley
using results from Working Model
Driver Position vs. Sickle Velocity
150
Sickle Velocity (in/s)
100
50
0
-50
-100
-150
0
100
200
300
400
500
600
700
Rotation of Drive Pulley (°)
800
900
1000
Figure 9: Plot of sickle velocity in relation to rotation of the main drive pulley
using results from Working Model
Driver Position vs. Sickle Acceleration
5000
4000
Sickle Acceleration (in/s 2)
3000
2000
1000
0
-1000
-2000
-3000
-4000
-5000
0
100
200
300
400
500
600
700
Rotation of Drive Pulley (°)
800
900
1000
Figure 10: Plot of sickle acceleration in relation to rotation of the main drive pulley
using results from Working Model
In addition to analyzing the mechanism in Working Model, SolidWorks was used to analyze the
mechanism in three dimensions as illustrated in Figure 11. Results of the analysis are shown in Figures
12-14. The results show similar results to those generated with Working Model with roughly sinusoidal
motion.
Figure 11: Modeling of sickle drive mechanism in SolidWorks
Driver Position vs. Sickle Position
4
3.5
Sickle Position (in)
3
2.5
2
1.5
1
0.5
0
-0.5
0
100
200
300
400
500
600
700
Rotation of Drive Pulley (°)
800
900
1000
Figure 12: Plot of sickle position in relation to rotation of the main drive pulley
using results from SolidWorks
Driver Position vs. Sickle Velocity
100
80
60
Sickle Velocity (in/s)
40
20
0
-20
-40
-60
-80
-100
0
100
200
300
400
500
600
700
Rotation of Drive Pulley (°)
800
900
1000
Figure 13: Plot of sickle velocity in relation to rotation of the main drive pulley
using results from SolidWorks
Driver Position vs. Sickle Acceleration
5000
4000
Sickle Acceleration (in/s 2)
3000
2000
1000
0
-1000
-2000
-3000
-4000
-5000
0
100
200
300
400
500
600
700
Rotation of Drive Pulley (°)
800
900
1000
Figure 14: Plot of sickle acceleration in relation to rotation of the main drive pulley
using results from SolidWorks
While the plots generated from results from Working Model and SolidWorks demonstrate
similar behavior, the results do have noticeable differences when compared side by side. These
differences are shown in Figures 15-17. It can be seen that the Working Model results appear to lag the
SolidWorks results by approximately 25° of rotation of the main drive pulley. This despite both
simulations being set with the 0° mark as the main drive pulley being rotated so as to place the
eccentricity as close to the rocker arm as possible. Additionally, the Working Model results show a
slightly larger stroke of the sickle at 4.1” vs. 3.9” or about 16% more as compared to the SolidWorks
model. As expected, this time lag and difference in stroke carries through to the plots of velocity and
acceleration.
From the comparison of results between SolidWorks and Working Model one significant
conclusion can be reached. By design, Working Model is not capable of analyzing 3D mechanisms. One
might attempt to work around this limitation by projecting a simple 3D mechanism into two dimensions.
This was the approach taken in this project. However, as demonstrated by this project, this does not
necessarily lead to accurate results. In some cases, the error demonstrated in this project may be
acceptable if one is looking for a quick and simple overview of how a mechanism operates and prefers
to use Working Model over a true 3D simulation package. However, for truly accurate results one must
analyze a 3D mechanism in a package that is designed for doing so, such as SolidWorks.
Driver Position vs. Sickle Position
4.5
SolidWorks
Working Model
4
3.5
Sickle Position (in)
3
2.5
2
1.5
1
0.5
0
-0.5
0
100
200
300
400
500
600
700
Rotation of Drive Pulley (°)
800
900
1000
Figure 15: Plot of differences in results between Working Model and SolidWorks results for driver
position vs. sickle position
Driver Position vs. Sickle Velocity
150
SolidWorks
Working Model
Sickle Velocity (in/s)
100
50
0
-50
-100
-150
0
100
200
300
400
500
600
700
Rotation of Drive Pulley (°)
800
900
1000
Figure 16: Plot of differences in results between Working Model and SolidWorks results for driver
position vs. sickle velocity
Driver Position vs. Sickle Acceleration
5000
SolidWorks
Working Model
4000
Sickle Acceleration (in/s 2)
3000
2000
1000
0
-1000
-2000
-3000
-4000
-5000
0
100
200
300
400
500
600
700
Rotation of Drive Pulley (°)
800
900
1000
Figure 17: Plot of differences in results between Working Model and SolidWorks results for driver
position vs. sickle acceleration
In a comparison between SolidWorks and Working Model, Working Model does still retain some
advantages for motion analysis despite being limited to two dimensions. Working Model allows for
easier integration of gravity and friction into a simulation. Additionally, Working Model provides easier
means of data export and measuring of the movement of members in a mechanism. Depending on
one’s comfort level with each package, there is no significant advantage to either in terms of ease of use
for modeling purposes. Therefore, it is the conclusion of this project that Working Model is a capable
package for 2D motion analysis, but is not practical for accurate analysis of a mechanism that operates
in three dimensions.
Alyssa Minnier
ME 481 Final Project
Analysis of Hydro-turbine Wicket Gate Linkage Assembly
Introduction
The wicket gate assembly of a hydro-turbine is key to the operation of the unit. One advantage of
hydropower is that power can be generated on very short notice due to the ease and accuracy of water
flow control; for this reason, the timing of gate opening and closing is critical to unit operation.
Hydropower units can produce any power output (up to its maximum rated output) required to stabilize
the grid, but every unit has a particular “ideal operating range”, in which it operates most efficiently.
The wicket gate opening and closing speeds are designed such that exposure to “rough” operating
ranges is limited. This report summarizes analysis of the wicket gate linkage lengths and the effect on
gate opening/closing times.
Working Model Simulation
Working Model software was utilized to simulate the motion of the wicket gates and linkage assembly.
Every wicket gate and the linkages for each wicket gate are identical, and the arrangement of the links
on the operating ring ensures that the movement of every gate will also be identical. For simplicity, only
one wicket gate and linkage assembly was modeled. See Figure 1.
Depending on the size of the unit, many wicket gate operating mechanism assemblies include 2
servomotors, one pushing and one pulling for both opening and closing actions. For this simulation, only
one servomotor is modeled and only gate closing action is simulated.
Page 1 of 4
Alyssa Minnier
ME 481 Final Project
Linkage
Wicket Gate
Operating Ring
Hydraulic
Servomotor
Figure 1: Working Model simulation model
The unit governor system controls the flow of water through the turbine by opening and closing the
wicket gates. The wicket gates are connected to an operating ring by the wicket gate linkage
assemblies, which is driven by hydraulic servomotors.
For this analysis, the servomotors apply a constant velocity to the operating ring. Additional
assumptions for the analysis are listed below:



Wicket gates range of operation (fully open to fully closed) is 45 degrees of rotation
External force of water flow on wicket gate is neglected for simplicity
Gravitational force in the z-direction is neglected in the 2D model
The simulation was run for 11 scenarios in which only the length of the wicket gate linkages were
changed. See Figure 2 for the description of each iteration.
A
B
Length of
Length of
Link A [mm] Link B [mm]
1
750
750
2
750
800
3
750
900
4
750
1000
5
800
750
6
800
800
7
800
900
8
800
1000
9
900
750
10
900
800
11
900
900
Figure 2: Simulation iterations
Page 2 of 4
Alyssa Minnier
ME 481 Final Project
The simulation was started with the initial wicket gate angle at 25 degrees for each iteration. For
consistency of this analysis, the wicket gate is considered fully closed at an angle of 70 degrees in the
Working Model simulation. The data collected for each iteration was the rotation of the wicket gate
with respect to time. See Figure 3 for an example graph from Working Model.
Figure 3: Example of rotation data
Results
After running the simulation, the results of each iteration were exported to Excel for processing. The
relationship between wicket gate rotation angle and time was found to be nearly linear and a linear
trend line was created for each iteration. See Figure 4.
Figure 4: Graph of rotation vs. time, with linear trend line
From each trend line, the exact time when the wicket gate reached 70 degrees (fully closed) was
interpolated. See the chart below for a summary of the data. Figure 5 shows a graphical representation
of the data.
Page 3 of 4
Alyssa Minnier
ME 481 Final Project
1
2
3
4
5
6
7
8
9
10
11
A [mm]
750
750
750
750
800
800
800
800
900
900
900
B [mm]
750
800
900
1000
750
800
900
1000
750
800
900
Time to
close [sec]
11.72
11.38
10.85
10.45
12.22
11.89
11.40
11.04
13.11
12.83
12.44
Figure 5: Wicket gate closing times
Figure 5 shows that as the length of the linkages increase, so does the gate closing time. This makes
sense, as the connection point between the linkages has further to travel to achieve the same wicket
gate rotation angle.
Conclusion
In conclusion, this analysis shows that the length of the wicket gate linkages has a direct effect on the
gate closing time when the servomotor velocity is constant. Reducing the length of either link (Link A,
Link B, or both) will reduce the time required to close the wicket gates. This relationship can aid in the
optimization of linkage design for a pre-determined wicket gate opening/closing speed.
Page 4 of 4
Richard 1
Josh Richard
ME 481
May 6th, 2015
Peaucellier-Lipkin Linkage: From Extra Credit Problem to Final Project
The Peaucellier-Lipkin linkage has been around since the 1860’s and has been used as a
model ever since for how rotary motion can be transformed through linkage into linear motion
[1]. Variations have been built over the years, and those variations have been built upon to be
used for various mechanical applications. However, the most basic version of the linkage that is
used in mathematics and engineering classes around the world, as seen in Figure 1, is rarely seen
in a physical form. I decided to determine if that model could physically be made for my final
project, as well as determine if a second driver link could be added to the mechanism to make
movement easier for a user while still allowing the linkage to rotate in its full possible range of
motion.
Figure 1: Widely used version of Peaucellier-Lipkin Linkage [1]
I began my project by understanding the mathematics behind the linkage. There are three
conditions that need to be met in order for the linkage to work as intended. The first condition is
Richard 2
that the points O, A, and E as seen in the example in Figure 2 are collinear. If the one can
Figure 2: Linkage with labeled points [2]
assume that the linkage geometry is symmetric around a line drawn between O, A, and E, then
these three points can be assumed to be collinear. The second condition that needs to be met is
that point traces the inverse of point A with respect to a determined circle. Through a derivation
that can be found in Appendix A, it is determined that the product of the lengths of distances OA
and OE are equal to a constant, k. Since the first condition has been proven and therefore A and
E are collinear, it can be assumed E is the inverse of point A with respect to a circle at center O
and radius k. The final condition is that point A must trace out a circle if point E is to trace a
straight line. Since E is the inverse of A, if point A traces a circle then point E traces the inverse
of a circle which is a straight line [3].
The first model used to prove the linkage’s physical capability was in Working Model
(Figure 3a). The first difficulty of the project began with determining the lengths of each links.
The derivations from Appendix A show that there is a relation between the lengths of links OB
and BE and segments OA, and OE (references to link names will be determined from Figure 2
from now on). A quick search on the internet does not result in any helpful references from
anyone else who has made variations of the original linkage. The initial guess used for link
Richard 3
lengths that would satisfy the linkage were 12 inches for the longest links, 6 inches for the
middle length links, and 4 inches for the shortest links. Fortunately, this configuration was able
to work and no changes were made in regards to length for the rest of the project. A motor with a
sinusoidal movement of 1.3sin(πt) radians was attached at point OA to the driver link to create
the arc motion of the link. The amplitude of the function was determined to be around 1.3
radians, as the linkage at this position is the point where all the links are collinear and the linkage
locks up. The model’s validity as an accurate model of the linkage can be found in Figure 3b,
which shows that the x position of point E stays constant through an entire cycle.
Figures 3a & 3b: Working Model version of the linkage (a, left), position graph of point E (b, right)
A second model of the linkage was made in SolidWorks to determine the layering of the
linkage. In order for the linkage to work in a 3D space, the links must not, for the most part,
collide during the full motion as described by the model in Working Model. One issue that arose
while creating the linkage in SolidWorks is that SolidWorks does not have a ‘ground’ that links
can be connected to. The linkage requires two points to be attached to the ground. The first
solution to this problem used was to include a ground link in the middle of the linkage, as shown
in Figure 4a. It is considered to be ‘in the middle’ since link OB is layered on top of the ground
and link OC is layered below it. A motor was attached at point OA to rotate the driver link in a
Richard 4
similar fashion to the one used in Working Model. Motion of the model turned out very similar
to the motion in Working Model, as seen in the position of point D in Figure 4b.
Figures 4a & 4b: SolidWorks model of the linkage (a, left), position graph of point E (b, right)
Finally, the physical model of the SolidWorks model was made out of clear acrylic and 832 screws with washers, as seen in Figure 5. The lengths used in Working Model and
SolidWorks are the distances between the holes in each of the links and the screws were used as
pins between the joints. A couple of unforeseen issues came about creating the model outside of
a computer model. Unfortunately, the motion of linkage was inhibited by the screw heads and
the ends of the screws colliding with the other links as the linkage tried to rotate. It was also
difficult for a user to rotate the driver link while needing to keep the ground link stationary. The
user was also unable to rotate the driver link in a large range due to the user’s hand colliding
with the longer links. Lastly, the motion of point D was not exactly linear as there was some
relative motion between the links at the joints.
Richard 5
Figure 5: Physical model of linkage made out of 8 acrylic links
A redesign of the layering was needed in order to get a better range of motion for the
linkage. The ground link was moved to below links OB and OC, as shown in Figure 6a. Small
round pieces of acrylic were used to make up for the height difference in layers for certain points
in the linkage. Once re-layered in SolidWorks, a new physical model could be created (Figure
6b). This model had much greater range of motion than the first, as the user was able to rotate the
driver link through a greater range of motion before any colliding occurred. This model finally
represented, for the most part, an accurate physical representation of the Peaucellier-Lipkin
linkage concept, therefore successfully completing the first aspect of the project.
Figures 6a & 6b: SolidWorks model of new layering (a, left), new physical model (b, right)
Richard 6
The second aspect of the project was more difficult to complete, however. The second
goal was to add a second driver link to the linkage so that the linkage may move through its
entire range of motion. A quick search on the internet results in one example of an extra driver
link added to this type of Peaucellier-Lipkin Linkage (shown in Figure 7), however it does not
allow for a full range of motion. The goal of a second driver link added to the linkage needs to
Figure 7: Example of second driver added to linkage [4]
allow the point that the first and second driver link share to move in its full arc. In theory, a
second Peaucellier-Lipkin linkage could be added to the system to become the second driver
link. However, adding another linkage to one linkage just to make the first linkage move is
redundant. A second concept for making the linkage move without a user would be to use a
motor that could rotate the driver link in a sinusoidal motion, similar to that of the ones used in
Working Model and SolidWorks. However, a motor that could complete that type of motion
would become extremely complex and was beyond my capabilities for this project. Therefore, a
second driver link added onto this linkage is essentially unnecessary as it just increases the
complexity of a rather simple mechanism.
This project ultimately got results for both of its purposes. It is possible to build the
linkage into a 3D world, however adding a second driver link just adds unnecessary complexity
Richard 7
to the linkage. The use of computer models before jumping into building a physical
representation aided the process of discovering how the physical model should be built and what
it is capable of doing. Albeit for some slight non-linear movement from point D, I was able to
make an accurate model of the linkage that works as it is intended.
Richard 8
References:
[1] "Straight Line and Its Construction." Math Images RSS. N.p., n.d. Web. 06 May 2015.
[2] "GIM Examples: Peaucellier Mechanism." COMPMECH RESEARCH GROUP. N.p., 18
Dec. 2013. Web. 06 May 2015.
[3] Scott, Paul. "6. Peaucellier - Lipkin Linkage." 6. Peaucellier - Lipkin Linkage. N.p., n.d.
Web. 06 May 2015.
[4] "Peaucellier–Lipkin Linkage." Wikipedia. Wikimedia Foundation, n.d. Web. 06 May 2015.
Richard 9
Appendix A: Derivations of Peaucellier-Lipkin Linkage Link Length Relations
𝐼𝑓 𝑝𝑜𝑖𝑛𝑡 𝑃 𝑖𝑠 𝑡ℎ𝑒 𝑖𝑛𝑡𝑒𝑟𝑠𝑒𝑐𝑡𝑖𝑜𝑛 𝑜𝑓 𝑙𝑖𝑛𝑒𝑠 𝐴𝐸 𝑎𝑛𝑑 𝐵𝐶, 𝑎𝑛𝑑 𝑡ℎ𝑒 𝑐𝑒𝑛𝑡𝑒𝑟 𝑜𝑓 𝑟ℎ𝑜𝑚𝑏𝑢𝑠 𝐴𝐵𝐸𝐶, 𝑙𝑒𝑡:
𝐴𝑃 = 𝑥 = 𝑃𝐸, 𝐵𝑃 = ℎ, 𝑂𝐴 = 𝑦
𝑂𝐴 ∙ 𝑂𝐸 = 𝑦(𝑦 + 2𝑥) = 𝑦 2 + 2𝑥𝑦
𝐵𝑦 𝑃𝑦𝑡ℎ𝑎𝑔𝑜𝑟𝑒𝑎𝑛 𝑇ℎ𝑒𝑜𝑟𝑒𝑚, (𝑦 + 𝑥)2 + ℎ2 = 𝑂𝐵 2 𝑎𝑛𝑑 𝑥 2 + ℎ2 = 𝐵𝐸 2
𝑂𝐵 2 − 𝐵𝐸 2 = (𝑦 + 𝑥)2 + ℎ2 − 𝑥 2 − ℎ2 = 𝑦 2 + 2𝑥𝑦 = 𝑂𝐴 ∙ 𝑂𝐸
𝑆𝑖𝑛𝑐𝑒 𝑂𝐵 𝑎𝑛𝑑 𝐵𝐸 𝑎𝑟𝑒 𝑓𝑖𝑥𝑒𝑑 𝑙𝑒𝑛𝑔𝑡ℎ𝑠, 𝑂𝐴 ∙ 𝑂𝐸 = 𝑘 2
BRIAN SEVILLA
ME452
SPRING 15
PIANO: MECHANISMS OF MUSIC
In the realm of music, very clever uses of mechanisms have been implemented to create
beautiful aural treats for humanity. One of the great examples is the piano. Several intertwined
mechanisms give the piano the flexibility to do so many things, which is why it is the backbone of so
much classical music and one of the most popular instruments to learn. Hundreds of individual
mechanisms give the maestro the ability to create a masterpiece. Each of the 88 keys has a closed
multiloop mechanism operating it. On top of this, there are three pedals each with its own closed
multiloop mechanism. In this investigation, the keys, sustain pedal, and una corda pedal were examined
to see how these mechanisms create such wonderful music.
To perform the simulation and modeling of the piano in this investigation, a Steinway baby
grand piano from the Peabody Conservatory of Music in Baltimore, Maryland was measured. The piano
was partially able to be disassembled for examination, however some estimations had to be made as
many of the components are under the strings within the body and could not be reached. Additionally,
the masses of all parts could not be measured for the same
reason. The piano’s body and the mechanisms in question
were then modeled in Solidworks, as shown in Figure 1, to
provide images of the mechanisms as well as to have record of
the dimensioning and arrangement of the parts. For
simulations, estimates were made within the Working Model
software package based on apparent materials used in the
actual piano when possible. Therefore, all forces associated
with the simulations performed and presented herein are
estimates and are used to present a picture of how the
mechanisms operate to create the sounds that have captured
Figure 1: Solidworks Model of Piano measured
the imaginations of so many people for many years. To aid in
the process, pictures and video were taken to ensure that the
models performed in much the same way as seen in reality, to be able to demonstrate that the models
are reasonably valid and useful.
Assumptions
In the modeling of the mechanisms herein, several assumptions have been made. The first is
that the piano only works in one orientation, standing on the ground with three legs of the baby grand
piano perpendicular to the ground and the strings parallel to the ground. This is important as two of the
mechanisms are gravity dependent and do not operate in the way intended in any other orientation.
The only change of orientation can be in rotation about the vertical z axis. Rotation about the X or Y axis
removes the gravitational forces which determine much of the motion.
The second, and most important, is that I have assumed all of the mechanisms are closed loop.
This is not true in the strictest sense, as the mechanisms all have what I refer to as sliding surfaces. At
these sliding surfaces, the links are not actually connected, but due to gravity the links are forced
downward at rest and remain in contact. These surfaces are modeled as a pin in slot joint to account for
the movements which are occurring in the mechanism and to allow gravity to pull down the hammer
without staying in the air.
Page 1 of 7
Third, the assumption of closed loop mechanisms ties to the assumption in that all of the
mechanisms have a mobility of one. This is because the intended effect of the mechanisms is for a single
link moving in a single degree of freedom. This is the Hammer striking the string, the sustain damper
being lifted off the strings or the keyboard and hammers all being slid aside. Each of these movements is
in a single degree of freedom and when the keys or pedals are released, they return to their rest
position. This is a subtle assumption as it ties into the fact that all mechanisms are closed loop.
Technically, the key and sustain mechanisms have a mobility higher than 1, but practically, this is not the
case. Practically, the mechanisms have one movement thus we are assuming and modeling for a
mobility of one in each case.
Finally, I have assumed that all of the mechanisms are two dimensional. This is generally not the
case, and in the actual piano that was modeled here as with most pianos, the Una Corda pedal actuates
the keyboard perpendicular to its own movement.
The Key Mechanism
The keyboard is a widely known iconic pattern that almost everyone is familiar with. It is those
88 black and white keys which when operated
produce the beautiful tones that form some of the
most widely loved music on earth. Figure 3 shows an
example section of the keyboard with a single hammer
linkage assembly, also known as an action, attached to
key 42. Key 42 was chosen to be modeled for the fact
that it had a completely straight key lever which is not
the case for all keys on the piano. Each key of the
piano is the controlling link of a closed, two loop,
double inverse slider crank. Each loop has a small felt
lined flat spot which slides along the shaft of the link
above. For the second loop, the link being moved is
Figure 3: Key mechanism Solidworks model
the hammer which strikes the strings. The mechanism
has a mobility of one, with the hammer link swinging
from its ground point, seen at the opposite end of the hammer link from the felt covered mallet.
Figure 2: Working Model simulation of the key Mechanism
The Topology and connectivity of the key mechanisms are shown in Figure 4 and Figure 5. These
diagrams both show that the mechanism is made up of four links (one being the ground/body of the
piano). Also, both demonstrate that there are three J1 revolute joints and two J2 pin-in-slot joints which
Page 2 of 7
make up the mechanism. Figure 2 shows the working model simulation of the mechanism. The model is
operated by an analog of a hand which presses the key end at the left. The hand mechanism is operated
Figure 4: Connectivity Diagram of Key Mechanism
Figure 5: Topology Diagram of Key Mechanism
to give a hard press like a piano player
would while performing, however the press is performed at even intervals which is not often the case in
songs. The model simplifies the mechanism as it assumes a pin in slot joint rather than the disconnected
links in the real action. This is important as it ignores a part of the motion in which when the key is held,
the hammer actually comes back to rest a short distance below the string it struck. Additionally, the key
actuates the sustain damper when pressed, but this was left out for simplicity, and to focus on the
primary movement of the mechanism.
The mechanism’s primary function is as a velocity multiplier for the hammer. The mechanism
takes the velocity of the key being pushed
down and uses the geometry to increase
the velocity input and make the output
velocity higher to strike the strings and
create the tone. The velocity gain from the
press of the key is approximately 14.7
times. So when each key is pressed, the
hammer it is associated with strikes the
string at almost 15 times the speed.
Looking at the input and output speeds
from two presses of the keys in the plot of
Figure 6: Input and Output Velocity from Working Model
Figure 6, it becomes much more obvious
how massive the velocity gain is. Unlike the velocity, the force is reduced from key to hammer. The force
reduction factor is 8.5.
The combination of speed multiplication and force reduction allows the hammer to be more
responsive to the smallest keystroke by the player. This is especially helpful as human fingers are
dexterous and this makes it possible to have very fine and minute differences between keystrokes
depending on input from the player.
Page 3 of 7
The action modeled here is a simple one known as an English action. There are several other
types of actions that come from the evolution of the instrument throughout the years. The most
common today is the Grand action which is made up of 6 links and is even more responsive to allow for
repetitive key strikes by pulling the hammer down more quickly and forcing the key lever back to its rest
position more quickly.
The Sustain Mechanism
The piano is not simply a collection of single notes played on sets of
strings. There are several modifers that are available to the player. One of
these is the sustain which removes a damping effect from the strings which
allows them to ring for much longer. This is crucial to allow the player to
play longer notes rather than just the single notes brief tones. The sustain is
one of three pedals underneath the piano, operated with the feet to modify
the tones created by the instrument. This is typically the rightmost pedal
and is by far the most commonly used of the three and is modeled in
Solidworks and shown separate from the rest of the piano in Figure 9.
Unlike the key mechanism, the sustain is operated by foot, so it
takes a much more coarse movement. In conjunction with this, the lifting of
the damper off of the strings is a much smaller movement as it only needs to
be, at a minimum, a few milimeters off of the top of the strings. So, by
utilizing longer links, over longer distances from the floor, the mechanism
smoothes and reduces the movement and raises the damper only a small
amount. Since the necessary movement is small, the reduction keeps the
mechanism very simple. The mechanism is a two loop mechanism made of
Figure 8: Connectivity Diagram of Sustain Mechanism
Figure 9: Sustain Mechanism
Solidworks model
Figure 7: Topology Diagram of Sustain Mechanism
five links in two loops as seen in the topology and connectivity diagrams in Figure 8 and Figure 7. The
first loop is a simple four bar. The second loop is a three bar with a pin in slot joint which raises the
damper. This follows with the assumption that the mechanism has a mobility of one, as the pin in slot
Page 4 of 7
joint is for modeling purposes and is not truly there at the surface where the link slides across the base
of the damper as seen in the Working Model simulation in Figure 10.
The mechanism can be examined further using
Working Model with the topology and connectivity of the
mechanism. Here we see again the composition of five links
with five revolute joints and one pin in slot joint. The Working
Model simulation demonstrates the motion of the sustain. The
mechanism is operated by an analog of a foot at the left. The
mechanism takes input of a large movement to give a small
movement in the lift of the damper. If we use the model to
look at the movement of the pedal end and the movement of
Figure 10: Working Model Simulation of
Sustain Mechanism
the damper, we can see that the
difference in motion is significant. Shown
in Figure 11 is the plot of the vertical
position of the damper head and pedal
end from their rest position. The change
in vertical position is reduced by a factor
of 2.27 due by the mechanism as seen in
Figure 11: Plot of Vertical position of Pedal and Damper
the plot. This reduction is due to the
shorter are of the pedal lever opposite the foot. This small motion does a number of subtle things. The
smaller movement minimizes the distance the player needs to move to operate other things. This helps
conserve energy as a concert can go on for a hours. This reduction on player movement aslo makes it
possible to be more active and makes the player move more smoothly from one section in a song to the
next as this may require the player to shift themself.
The interesting consideration is that the model used only considers a single damper. Each time
the pedal is operated, the entire set of 88 dampers lifts from the strings. The force required to operate
the pedal is not very large, but it is multiplied as the back end of the pedal which moves the rest of the
links is shorter than the side the foot steps on. So a small force gain is seen in the final lift of the
dampers. The small distance of travel allows the large number of parts to move smoothly and reliably
when needed.
The Una Corda/Soft Pedal Mechanism
The una corda or “soft” pedal is the leftmost pedal on a piano and is much less commonly used
than the sustain. The pedal mechanism, for which the solidworks model is show in Figure 12, moves the
Page 5 of 7
Figure 12: Solidworks Model of Una Corda Pedal and
Keyboard
Figure 13: Working Model Simulation of Una Corda Mechanism
entire action of the piano including the keys and hammer mechanisms a small distance so that instead
of striking all three strings as normal, it only strikes two strings. This causes a softer sound as would be
expected. Another effect of this shift is that it also
dulls the sound as a different part of the hammer
head strikes the strings. This means a part of the
hammer felt which is not compressed and hardened
from normal playing is striking the strings which also
affects the tone and further softens it. The action is
sprung to return it to the normal position after
operation.
The simulation of this mechanism, as seen in
Figure 13, shows the mechanism simplified. First, it
only shows the keyboard and not the hammer
mechanisms attached. Obviously, this is for
simplicity and to make everything more easily visible
in the model and the same was done in Figure 12.
Figure 15: Connectivity Diagram of Una Corda
Mechanism
Figure 14: Plot of displacement of Pedal and Keyboard
Figure 16:Topology Diagram of Una Corda Mechanism
Page 6 of 7
Second, the model is constructed entirely in two dimensions. In reality, the keyboard and hammers all
move from left to right in front of the player while the motion though the mechanism from the pedal is
transmitted outward from the player. So for this, the model has the keyboard moving out from the
player. The motion is unchanged despite the change in direction.
In the Simulation, we see a similar result in the reduction of motion as in the sustain pedal
mechanism. The large displacement, imparted by foot, into the pedal is translated into a small
displacement of the keyboard as seen in Figure 16. The keyboard only moves about an eighth of an inch,
just enough to miss the third of the three strings for each note. The mechanism provides a tenfold
decrease in movement.
Looking at the topology and connectivity of the mechanism in Figure 15 and Figure 14, we see
the composition of the mechanism as five links with five revolutes and a pin in slot joint much like the
sustain mechanism. Again, the mechanism is modeled as closed and two loop. The first loop, like the
sustain is a simple four bar mechanism which operates a three bar.
Conclusion
The piano is a glorious instrument which seems so complicated when a virtuoso plays it, but at
its heart are simple mechanisms which do wonders to intertwine and help create the magic of music.
Through an up close and personal examination of this instrument, I have found that the perception of
complexity is quite false. It is the magic of creativity from people that make the complexity in music. The
piano is but a simple collection of mechanisms that allow someone to channel their creativity and share
it. But without the very clever and considered design, we wouldn’t have any of it. Using basic principles
of design and an understanding of dynamics, we have the instrument that has helped create so much.
Page 7 of 7
Stewart Platform Design Report
ME 445 & ME 481 Final Project
Jeremy Canonge
Jonathan Russell
Zachary Shiner
The Pennsylvania State University
May 6, 2015
Table of Contents
1
Introduction ............................................................................................................................. 3
2
Design Criteria ......................................................................................................................... 3
3
Technical Approach ................................................................................................................. 3
3.1
Dynamixel Robot Actuators ............................................................................................. 3
3.2
Inverse Kinematics ........................................................................................................... 4
3.3
MATLAB Script and GUI .................................................................................................. 4
4
Mechanical Design .................................................................................................................. 6
5
Moving Forward ...................................................................................................................... 6
6
Bibliography ............................................................................................................................ 7
7
Appendix ................................................................................................................................. 8
7.1
Local Coordinate Frames & Geometry ............................................................................ 8
7.2
Equations ........................................................................................................................ 11
7.3
Mechanical Drawings ..................................................................................................... 12
7.4
Code ............................................................................................................................... 15
– 2 –
1 Introduction
A suitable final project was needed to satisfy course requirements for ME 445: Microcontrollers
and ME 481: Computer Analysis of Mechanisms at Penn State. Our initial proposal was to design
and construct a desktop-scale Arduino controlled Stewart Platform.
A Stewart platform is a six degree-of-freedom parallel manipulator. That is, it is capable of
moving in three linear directions, and three angular directions. The platform is named after its
inventor, D. Stewart. Stewart worked in conjunction with V. E. Gough to design a mechanism
primarily to simulate flight conditions for the safe training of helicopter pilots. However, other
uses such as general handling problems in cargo manipulation, the medical field, and earth
removal were noted. (Stewart 1965–1966)
The goal of our project changed when were connected with Dr. Langelaan of Penn State’s
Aerospace Department. Dr. Langelaan’s research concerns planning and control algorithms to
enable high performance autonomy, focused mainly on robotic flight vehicles. Dr. Langelaan
plans to use the platform to simulate wave motion similar to what a ship at sea would experience.
He has cameras on the bottom of quadcopters which interpret the deck’s movement from the
waves. This allows the aircraft to compensate and adjust its landing. As of now they can only
perform static tests, but the Stewart platform would allow for both static and dynamic testing.
2 Design Criteria
To meet the needs of Dr. Langelaan, the Stewart Platform must be able to:




Support a 7 lb load
Travel 12 inches vertically (heave)
Demonstrate 30 degrees of roll and pitch
Accept multiple term Fourier series to each degree of freedom
These criterion will allow the platform to be fully utilized in Dr. Langelaan’s research and allow
for scaled testing of quadcopter landings.
3 Technical Approach
3.1 Dynamixel Robot Actuators
Some initial calculations from the project requirements show that substantial mechatronics
components are required for the project. 12 inches of heave requires a minimum of a 6 inch lever
arm. Worst case scenario of 100% load on a single strut yields 672 ozf-in of torque.
To satisfy this requirement, Dynamixel MX-64 Robot Actuators were selected to drive our
platform. These actuators provide 849 ozf-in at 12V at stall conditions. The Dynamixel platform
also offers a number of brackets and fixtures to facilitate construction and design.
– 3 –
3.2 Inverse Kinematics
There are two types of kinematic solutions typically applied to robotics. Forward Kinematics
refers to the use of kinematic equations to solve for the end location of a linkage or mechanism
when the individual positions of each link are known. Inverse Kinematics refers to the use of
kinematic equations to solve for the positions of each link when the end location of the linkage
or mechanism is known. Typically Forward Kinematic solutions are much simpler than their
inverse counterparts. However, in the case of a parallel manipulator like the Stewart Platform,
Inverse Kinematic solutions are not only desired, but simpler to perform.
First a coordinate transformation is performed to place the top plate in its desired position and
pose.
GIVEN - global location of top plate {𝑟7 }
GIVEN - z about global z yaw - y about intermediate y roll - x about local x pitch|
use Euler angle ZYX sequence to calculate attitude
𝐶𝜃𝑥 𝐶𝜃𝑦
[𝐴7 ] = [𝐴𝑒𝑍 ][𝐴𝑒𝑌 ][𝐴𝑒𝑋 ] = [ 𝑆𝜃𝑥 𝐶𝜃𝑦
−𝑆𝜃𝑦
𝐶𝜃𝑥 𝑆𝜃𝑦 𝑆𝜃𝑧 − 𝑆𝜃𝑥 𝐶𝜃𝑧
−𝑆𝜃𝑥𝑆𝜃𝑦 𝑆𝜃𝑧 + 𝐶𝜃𝑥 𝐶𝜃𝑧
𝐶𝜃𝑦 𝑆𝜃𝑧
𝐶𝜃𝑥 𝑆𝜃𝑦 𝐶𝜃𝑧 + 𝑆𝜃𝑥 𝑆𝜃𝑧
−𝑆𝜃𝑥 𝑆𝜃𝑦 𝐶𝜃𝑧 − 𝐶𝜃𝑥 𝑆𝜃𝑧 ]
𝐶𝜃𝑦 𝐶𝜃𝑧
𝐶
Global locations of C1 computed through C6 using {𝑟7 }𝐶 = {𝑟7 } + [𝐴7 ]{𝑠7 }′
Then transform global locations C into local locations {𝑠𝐶 } relative to respective servo frames
Servo angles are then solved knowing {𝑠𝐶 } and {𝑠𝐵 } through the derivation presented in
Appendix 7.2.
3.3 MATLAB Script and GUI
The MATLAB script was written to create smooth operation of the Stewart Platform. The
beginning sections of the code initialize the Dynamixel library and contain variables that define
the platforms geometry, speed, baud rate, and other attributes. The script then tells the platform
to slowly move from its resting position to the local origin of the platform. A switch is used with
cases of transient and static to determine which set of code to run. Once this is known, the script
waits for the press of the start button. After a start button press, the code reads the input values
and checks to see if they will be invalid at any point along the motion path. If all points are valid,
the zero-time position of the platform for the given sequence is calculated and the platform is
told to move there. The given transient motion path is then run, or the platform stays in the zerotime position for the static case. The code runs a loop and uses a toc value to determine where
the platform should be on each loop. The loop is always checking to see if the stop button has
been pressed. When the stop button is pressed, the current loop is stopped and the platform is
returned to its local origin. Code returns to the beginning of the switch and the start button can be
pressed again to perform another motion sequence. If the GUI window is ever closed, the code
breaks the while loop that insures code repetition and the platform is instructed to move to its
resting position and all motor's torque is shut off.
– 4 –
The graphical user interface that was created for the Stewart Platform was designed to increase
ease of operation for the user. This being our primary goal, we still wanted to ensure that the
GUI could control the platform however the user desired. To accomplish this we included an
option to select transient or static mode, allowing the user to place the platform in an oscillatory
motion or at a stationary location respectively. To provide the user with sufficient control over
the transient state the inputs for amplitude, frequency, and phase shift were user-definable for
three terms of a cosine Fourier series for each degree of freedom. The static mode was defined
by entering a value for each of the six degrees of freedom. After the motion type and appropriate
user-defined values were entered, the start button can be pressed to translate the platform to its
zero-time position and start the defined motion sequence. All GUI buttons, aside from stop and
abort, become disabled at this time to prevent the user from adjusting the motion sequence and
altering the devices path. If any problems occur during motion, the abort button was created to
disable torque on the motors and allow the user to reset the platform in its resting location. To
end the current sequence when no problems have occurred, the stop button can be pressed. The
stop button returns the platform to the local origin and enables all motion editing inputs on the
GUI. At this time, a new motion sequence can be defined and started. A value control panel was
also added to ensure that motion sequences can be saved and later loaded. To save the current
motion sequence, the user must enter a filename without an extension, and click the store values
button. These values can be loaded by entering the same filename and clicking the load values
button. A reset button was also created for the user’s convenience. This button returns all current
values to zero. With the current features of the GUI, the user can easily perform any Stewart
Platform action that the user desires.
Figure 1: MATLAB User Interface
– 5 –
4 Mechanical Design
A substantial frame was required to provide the strength and rigidity needed for precise
movements. A 3/8 inch 6061-T6 Aluminum plate was chosen to serve as the base. A tri-wing
design provides mounting positions for each servo, whose planes align with an equilateral
triangle. See Figure 7: Servo Mounting Plate Drawing for details.
The upper plate was fabricated from the same material and shares the same tri-wing design.
To provide the range of motion specified in Section 2, the following lengths were utilized.






Radius of Base, rB: 5.61 inches
Eccentricity of Base, eB: 2 inchs
Radius of Plate, rT: 5.64 inches
Eccentricity of Plate, eT: 1 inch
Radius of Arm: 7 inches
Length of Rod Links: 8.5 inches
5 Moving Forward
In the current state of production, the platform is ready to be used for dynamic testing in Dr.
Langelaan’s lab. However, there are clear areas where additional features can be added. The
Dynamixel motors being used are very versatile in what they can do, one of the features that has
yet to be utilized is the data relaying capability. The information that can be read from them is
current temperature, position, torque, %usage, and they also have dynamic PID controllers.
Implementing some form of programming to capture any relevant data for the test would be a
good step forward. It would also be possible in the GUI to allow the user to manually begin
recording whatever information they deem relevant during a live test.
Additionally, putting an Arduino interface to take the information from MATLAB and send it to
the platform would improve things. In the current state, MATLAB is performing the calculations
in real-time. If there is ever an error in the calculations, MATLAB will just skip over it, and that
causes the platform to also skip, which causes a sudden jerk in the otherwise smooth motion. If
an Arduino was placed as an intermediary, then MATLAB could perform the calculations at
whatever speed and the Arduino would act as a cache of sorts feeding out the information in the
real-time domain and the skips would not be an issue anymore.
– 6 –
6 Bibliography
Stewart, D. 1965–1966. "A Platform with Six Degrees of Freedom." Proceedings of the
Institution of Mechanical Engineers 180 (Pt 1, No 15).
– 7 –
7 Appendix
7.1 Local Coordinate Frames & Geometry






lower rod ends at points B
global z axis straight up
servo origins in plane of rod ends at height of servo shafts
servo x axes horizontal along shafts
servo y axes horizontal perpendicular to shafts
servo z axes straight up
Figure 2: Lower Plate - Local Axes
– 8 –
Figure 3: Lower Plate - Geometry & Dimension
– 9 –
Figure 4: Upper Plate - Geometry & Dimensions
– 10 –
7.2 Equations
Derivation to solve for servo angles, θ (positive up CCW in local frame), when upper rod-end’s
location, sc, is known in the motor shaft’s coordinate frame, C.
𝑎 = arm length,
𝑥𝑐
{𝑠𝐶 } = {𝑦𝑐 } ,
𝑧𝑐
𝑑 = rod length
0
{𝑠𝐵 } = {𝑎 cos 𝜃}
𝑎 sin 𝜃
𝑥𝐶2 + (𝑦𝐶 − 𝑎 cos 𝜃)2 + (𝑧𝐶 − 𝑎 sin 𝜃)2 = 𝑑 2
𝑥𝐶2 + 𝑦𝐶2 − 2𝑎 𝑦𝐶 cos 𝜃 + 𝑎2 cos 2 𝜃 + 𝑧𝐶2 − 2𝑎 𝑧𝐶 sin 𝜃 + 𝑎2 sin2 𝜃 = 𝑑 2
𝑥𝐶2 + 𝑦𝐶2 + 𝑧𝐶2 + 𝑎2 − 𝑑 2 = 2𝑎 (𝑦𝐶 cos 𝜃 + 𝑧𝐶 sin 𝜃)
𝑦𝐶 cos 𝜃 + 𝑧𝐶 sin 𝜃 =
𝜃
𝑢 = tan ,
2
𝑦𝐶 (
𝑥𝐶2 + 𝑦𝐶2 + 𝑧𝐶2 + 𝑎2 − 𝑑 2
=𝑄
2𝑎
2𝑢
sin 𝜃 =
,
1 + 𝑢2
1 − 𝑢2
cos 𝜃 =
1 + 𝑢2
1 − 𝑢2
2𝑢
) + 𝑧𝐶 (
)=𝑄
2
1+𝑢
1 + 𝑢2
𝑦𝐶 − 𝑦𝐶 𝑢2 + 2 𝑧𝐶 𝑢 = 𝑄 + 𝑄 𝑢2
(𝑄 + 𝑦𝐶 ) 𝑢2 + (−2 𝑧𝐶 ) 𝑢 + (𝑄 − 𝑦𝐶 ) = 0
𝑢=
2 𝑧𝐶 ± √4 𝑧𝐶2 − 4 (𝑄 + 𝑦𝐶 )(𝑄 − 𝑦𝐶 ) 𝑧𝐶 ± √𝑦𝐶2 + 𝑧𝐶2 − 𝑄 2
=
2 (𝑄 + 𝑦𝐶 )
𝑄 + 𝑦𝐶
𝜃 = 2 tan−1 𝑢
– 11 –
7.3 Mechanical Drawings
A full complement of drawings are included with the SolidWorks model. Not-to-scale drawings
are included here for reference.
Figure 5: Motor Arm Drawing - Flat
– 12 –
Figure 6: Motor Arm Drawing - Bent
– 13 –
Figure 7: Servo Mounting Plate Drawing
– 14 –
7.4 Code
%% FILE DETAILS-----------------------------------------------------------% Authors: Jeremy Canonge and Zach Shiner
% Origination Date: 4/14/2015
% Last Updated Date: 4/29/2015 (Updated comments and removed unnecessary code)
% Description: This script controls 6 servo motors that are used to drive a
% six degree of freedom parallel axis manipulator. The code opens a
% graphical user interface that allows the user to input values for each
% degree of freedom in static or transient cases.
%% CLEANING MATLAB BEFORE RUNNING SCRIPT----------------------------------clear % Clearing all previously stored values
close all % Closing all previously opened figures
format shortg % Setting a format for all values
%% LOAD THE DYNAMIXEL LIBRARY---------------------------------------------addpath('.\dxl_sdk_win32_v1_02\bin', '.\dxl_sdk_win32_v1_02\import');
baudRate = 1000000; % 1Mbps
Dynamixel = MX64(31,baudRate);
%% MOTOR DETAILS----------------------------------------------------------parkAngle = 2065; % angle before shutting off the platform
originAngle = 2448; % angle that locates the plate at its origin
absoluteLowerLimit = 1425; % min servo value that a motor can ever have
absoluteUpperLimit = 3069; % max servo value that a motor can ever have
operatingMotorSpeed = 200; % speed used during transient platform operation
maxTorqueLimit = 768; % max torque that a servo provides before shut down
% SOFT LIMITS-------------------------------------------------------------% The virtual cylinder that rod ends of the plate may not exit [inches]
lowerPlateLimit = 3.25; % z-axis lower limit
upperPlateLimit = 15.25; % z-axis upper limit
maxPlateOffset = 7.75;
maxBallFlex = 30; % ball joints have maximum allowable flex [degrees]
% PLATFORM GEOMETRY-------------------------------------------------------% mechanism geometry, units [inch]
arm = 7.00; % radius from servo shaft to rod end
rod = 8.50; % length between balls of rod ends
rad_base = 5.61; % radius to plane for lower rod end centers
ecc_base = 2.00; % shaft offset from radial line
rad_plate = 5.64; % radius to cross center-line for upper rod ends
ecc_plate = 1.00; % upper rod end offset from radial line
% SET ATTRIBUTES OF THE MOTORS--------------------------------------------% Sending the predefined limits to the motors
for id = 1:6
Dynamixel.setAngleLimit(id,absoluteLowerLimit,absoluteUpperLimit);
pause(0.01);
end
% Setting the PID values for the servos
Dynamixel.setPID(254,40,22,18) % (ServoID, P, I, D)
% Dynamixel.setPID(254,52,12,8) % (Good Load Bearing Case)
%% SET MOTORS TO RESTING POSITION
disp('Move all motors to origin.'); % Letting the user know action
– 15 –
Dynamixel.setSpeed(254,40); % Setting a new servo speed
Dynamixel.syncWritePosition(originAngle .* ones(1,6)); % Sending platform to origin
Dynamixel.waitMoveComplete(6); % Checking if platform is done moving
%% INITIALIZE INVERSE KINEMATIC MODEL
Stewart = StewartKinematics(arm,rad_base,ecc_base,rod,rad_plate,ecc_plate);% Creating the
stewart platform object
%% PRIMARY MOTOR OPERATION WITH GRAPHICAL USER INTERFACE
handles = guihandles(GUI); % Initializing the control GUI
h = GUI; % Initializing the control GUI
Dynamixel.setSpeed(254,operatingMotorSpeed); % Setting the motor speed to the predefined
operating speed
while 1 == 1 % Run code until a break condition is satisfied
if ishandle(h) == 1 % Checking to see if the GUI window is open
rad_on = get(handles.uipanel14,'Selectedobject');% Determining the Communication Style
switch rad_on % Setting cases for communication type
case handles.transient % Defining the code for the transient case
control = get(handles.uipanel8,'Selectedobject'); % Determining the selected button in the
control panel
switch control % Setting cases for control buttons
case handles.start % Code executed for start button
% Read and define all of the values from the GUI
xaa1 = str2double(get(handles.xaa1,'String'));
xaa2 = str2double(get(handles.xaa2,'String'));
xaa3 = str2double(get(handles.xaa3,'String'));
xaf1 = str2double(get(handles.xaf1,'String'));
xaf2 = str2double(get(handles.xaf2,'String'));
xaf3 = str2double(get(handles.xaf3,'String'));
xap1 = str2double(get(handles.xap1,'String'));
xap2 = str2double(get(handles.xap2,'String'));
xap3 = str2double(get(handles.xap3,'String'));
yaa1 = str2double(get(handles.yaa1,'String'));
yaa2 = str2double(get(handles.yaa2,'String'));
yaa3 = str2double(get(handles.yaa3,'String'));
yaf1 = str2double(get(handles.yaf1,'String'));
yaf2 = str2double(get(handles.yaf2,'String'));
yaf3 = str2double(get(handles.yaf3,'String'));
yap1 = str2double(get(handles.yap1,'String'));
yap2 = str2double(get(handles.yap2,'String'));
yap3 = str2double(get(handles.yap3,'String'));
zaa1 = str2double(get(handles.zaa1,'String'));
zaa2 = str2double(get(handles.zaa2,'String'));
zaa3 = str2double(get(handles.zaa3,'String'));
zaf1 = str2double(get(handles.zaf1,'String'));
zaf2 = str2double(get(handles.zaf2,'String'));
zaf3 = str2double(get(handles.zaf3,'String'));
zap1 = str2double(get(handles.zap1,'String'));
zap2 = str2double(get(handles.zap2,'String'));
zap3 = str2double(get(handles.zap3,'String'));
% Angle values are converted to radians
xra1 = str2double(get(handles.xra1,'String'))*pi/180;
– 16 –
xra2 = str2double(get(handles.xra2,'String'))*pi/180;
xra3 = str2double(get(handles.xra3,'String'))*pi/180;
xrf1 = str2double(get(handles.xrf1,'String'));
xrf2 = str2double(get(handles.xrf2,'String'));
xrf3 = str2double(get(handles.xrf3,'String'));
xrp1 = str2double(get(handles.xrp1,'String'));
xrp2 = str2double(get(handles.xrp2,'String'));
xrp3 = str2double(get(handles.xrp3,'String'));
% Angle values are converted to radians
yra1 = str2double(get(handles.yra1,'String'))*pi/180;
yra2 = str2double(get(handles.yra2,'String'))*pi/180;
yra3 = str2double(get(handles.yra3,'String'))*pi/180;
yrf1 = str2double(get(handles.yrf1,'String'));
yrf2 = str2double(get(handles.yrf2,'String'));
yrf3 = str2double(get(handles.yrf3,'String'));
yrp1 = str2double(get(handles.yrp1,'String'));
yrp2 = str2double(get(handles.yrp2,'String'));
yrp3 = str2double(get(handles.yrp3,'String'));
% Angle values are converted to radians
zra1 = str2double(get(handles.zra1,'String'))*pi/180;
zra2 = str2double(get(handles.zra2,'String'))*pi/180;
zra3 = str2double(get(handles.zra3,'String'))*pi/180;
zrf1 = str2double(get(handles.zrf1,'String'));
zrf2 = str2double(get(handles.zrf2,'String'));
zrf3 = str2double(get(handles.zrf3,'String'));
zrp1 = str2double(get(handles.zrp1,'String'));
zrp2 = str2double(get(handles.zrp2,'String'));
zrp3 = str2double(get(handles.zrp3,'String'));
i = 1;
% calculate all positions that will be encountered by the platform throughout its movement
sequence converting positions to ball joint locations to determine if the platform has exited
bounds
transient_prose_test = zeros(length(0:1.01:10*pi),6);
for range = 0:0.01:10*pi
transient_prose_test(i,1) =
xaa1*sin(2*pi()*xaf1*range+xap1)+xaa2*sin(2*pi()*xaf2*range+xap2)+xaa3*sin(2*pi()*xaf3*range+x
ap3);
transient_prose_test(i,2) =
yaa1*sin(2*pi()*yaf1*range+yap1)+yaa2*sin(2*pi()*yaf2*range+yap2)+yaa3*sin(2*pi()*yaf3*range+y
ap3);
transient_prose_test(i,2) = -transient_prose_test(i,2); % invert the y axis to create a right
hand coordinate system
transient_prose_test(i,3) =
zaa1*sin(2*pi()*zaf1*range+zap1)+zaa2*sin(2*pi()*zaf2*range+zap2)+zaa3*sin(2*pi()*zaf3*range+z
ap3) + 9.25; %center of z travel
transient_prose_test(i,4) =
xra1*sin(2*pi()*xrf1*range+xrp1)+xra2*sin(2*pi()*xrf2*range+xrp2)+xra3*sin(2*pi()*xrf3*range+x
rp3);
transient_prose_test(i,5) =
yra1*sin(2*pi()*yrf1*range+yrp1)+yra2*sin(2*pi()*yrf2*range+yrp2)+yra3*sin(2*pi()*yrf3*range+y
rp3);
– 17 –
transient_prose_test(i,6) =
zra1*sin(2*pi()*zrf1*range+zrp1)+zra2*sin(2*pi()*zrf2*range+zrp2)+zra3*sin(2*pi()*zrf3*range+z
rp3);
[balls, B_angle, C_angle] = Stewart.checkAngles(transient_prose_test(i,:)');
C_angle*180/pi
if ((max(B_angle*180/pi) > maxBallFlex) || (max(C_angle*180/pi) > maxBallFlex))
warning('The current settings over extend the ball joints. Please change your settings and try
again.')
set(handles.stop,'Value',1);
break;
end
if max(sqrt(balls(1,:).^2+balls(2,:).^2)) > maxPlateOffset
warning('The current settings move the plate too far in the XY plane. Please change your
settings and try again.')
% set(handles.stop,'Value',1);
break;
end
if ((max(balls(3,:)) > upperPlateLimit) || (min(balls(3,:)) < lowerPlateLimit))
warning('The current settings move the plate too high or low in the Z plane. Please change
your settings and try again.')
% set(handles.uipanel8,'SelectedObject',handles.stop);
break;
end
i = i+1;
end
if get(handles.uipanel8,'SelectedObject') == handles.start
Dynamixel.setSpeed(254,40); % Setting the motor speed to slowly move to the zero time position
of the user defined sequence
%Moving the platform to the zero time position of the user defined sequence
transient_prose(1) =
xaa1*sin(2*pi()*xaf1*0+xap1)+xaa2*sin(2*pi()*xaf2*0+xap2)+xaa3*sin(2*pi()*xaf3*0+xap3);
transient_prose(2) =
yaa1*sin(2*pi()*yaf1*0+yap1)+yaa2*sin(2*pi()*yaf2*0+yap2)+yaa3*sin(2*pi()*yaf3*0+yap3);
transient_prose(2) = -transient_prose(2); % inverting the y axis to create a right hand
coordinate system
transient_prose(3) =
zaa1*sin(2*pi()*zaf1*0+zap1)+zaa2*sin(2*pi()*zaf2*0+zap2)+zaa3*sin(2*pi()*zaf3*0+zap3) + 9.25;
%center of z travel
transient_prose(4) =
xra1*sin(2*pi()*xrf1*0+xrp1)+xra2*sin(2*pi()*xrf2*0+xrp2)+xra3*sin(2*pi()*xrf3*0+xrp3);
transient_prose(5) =
yra1*sin(2*pi()*yrf1*0+yrp1)+yra2*sin(2*pi()*yrf2*0+yrp2)+yra3*sin(2*pi()*yrf3*0+yrp3);
transient_prose(6) =
zra1*sin(2*pi()*zrf1*0+zrp1)+zra2*sin(2*pi()*zrf2*0+zrp2)+zra3*sin(2*pi()*zrf3*0+zrp3);
drawnow; % Updating the code to prevent the platform from jumping
angleArray = Stewart.calcAngles(transient_prose'); % Calculating the servo angles from the
calculated prose
drawnow; % Updating the code to prevent the platform from jumping
angleArray = angleArray .* 4095./(2*pi) + 2048; % Converting the servo angles from radians to
servo step units
drawnow; % Updating the code to prevent the platform from jumping
Dynamixel.syncWritePosition(angleArray); % Sending the servo angles to the motors
drawnow; % Updating the code to prevent the platform from jumping
– 18 –
Dynamixel.waitMoveComplete(6); % Waiting for the motors to go to the origin
drawnow; % Updating the code to prevent the platform from jumping
pause(0.25) % Slight pause between the time the platform arives at zero time position and time
of movement start
Dynamixel.setSpeed(254,operatingMotorSpeed); % Setting the motor speed to the predefined
operating speed
transienttic = tic; % Starting the timer used in prose calculation
while get(handles.uipanel8,'Selectedobject') == handles.start % Setting code to be run while
the start button is selected
% Calculation of the value for each degree for each degree of freedom for the platform
(X,Y,Z,ROLL,PITCH,YAW)
transient_prose(1) =
xaa1*sin(2*pi()*xaf1*toc(transienttic)+xap1)+xaa2*sin(2*pi()*xaf2*toc(transienttic)+xap2)+xaa3
*sin(2*pi()*xaf3*toc(transienttic)+xap3);
transient_prose(2) =
yaa1*sin(2*pi()*yaf1*toc(transienttic)+yap1)+yaa2*sin(2*pi()*yaf2*toc(transienttic)+yap2)+yaa3
*sin(2*pi()*yaf3*toc(transienttic)+yap3);
transient_prose(2) = -transient_prose(2); % inverting the y axis to create a right hand
coordinate system
transient_prose(3) =
zaa1*sin(2*pi()*zaf1*toc(transienttic)+zap1)+zaa2*sin(2*pi()*zaf2*toc(transienttic)+zap2)+zaa3
*sin(2*pi()*zaf3*toc(transienttic)+zap3) + 9.25; %center of z travel
transient_prose(4) =
xra1*sin(2*pi()*xrf1*toc(transienttic)+xrp1)+xra2*sin(2*pi()*xrf2*toc(transienttic)+xrp2)+xra3
*sin(2*pi()*xrf3*toc(transienttic)+xrp3);
transient_prose(5) =
yra1*sin(2*pi()*yrf1*toc(transienttic)+yrp1)+yra2*sin(2*pi()*yrf2*toc(transienttic)+yrp2)+yra3
*sin(2*pi()*yrf3*toc(transienttic)+yrp3);
transient_prose(6) =
zra1*sin(2*pi()*zrf1*toc(transienttic)+zrp1)+zra2*sin(2*pi()*zrf2*toc(transienttic)+zrp2)+zra3
*sin(2*pi()*zrf3*toc(transienttic)+zrp3);
drawnow; % Updating the code to prevent the platform from jumping
angleArray = Stewart.calcAngles(transient_prose'); % Calculating the servo angles from the
calculated prose
drawnow; % Updating the code to prevent the platform from jumping
angleArray = angleArray .* 4095./(2*pi) + 2048; % Converting the servo angles from radians to
servo step units
drawnow; % Updating the code to prevent the platform from jumping
Dynamixel.syncWritePosition(angleArray); % Sending the servo angles to the motors
drawnow; % Updating the code to prevent the platform from jumping
end
end
case handles.stop % Setting code to be run while the start button is selected
Dynamixel.setSpeed(254,30); % Setting the speed at which the platform is to return to the
origin
drawnow; % Updating the code to prevent the platform from jumping
Dynamixel.syncWritePosition(originAngle .* ones(1,6)); % Telling the platform to move to the
origin
Dynamixel.waitMoveComplete(6); % Waiting for the motors to go to the origin
drawnow; % Updating the code to prevent the platform from jumping
Dynamixel.setSpeed(254,operatingMotorSpeed); % Reseting the motor speed to the predefined
operating speed
case handles.abort % ABORT
Dynamixel.torqueEnable(254,0); % Turning off the torque to the motors
– 19 –
clear Dynamixel;
close hidden; % Close GUI.
error('Abort pressed. Motor torque disabled and program teminated.')
otherwise
break
end
drawnow; % Updating the code to prevent the platform from jumping
case handles.static % Defining the code for the transient case
control = get(handles.uipanel8,'Selectedobject'); % Determining the selected button in the
control panel
switch control % Setting cases for control buttons
case handles.start % Defining the code to run when the start button is pressed
Dynamixel.setSpeed(254,25); % Setting the motor speed to the predefined operating speed
% Reading and Defining variables for the values defined by the user in the GUI
sx = str2double(get(handles.sx,'String'));
sy = -str2double(get(handles.sy,'String'));
sz = str2double(get(handles.sz,'String'));
% Angle values are converted to radians
sroll = str2double(get(handles.sroll,'String'))*pi/180;
spitch = str2double(get(handles.spitch,'String'))*pi/180;
syaw = str2double(get(handles.syaw,'String'))*pi/180;
static_prose = [sx,sy,sz+9.25,sroll,spitch,syaw]; % Creating the array that contains the
platform prose
angleArray = Stewart.calcAngles(static_prose'); % Calculating the required servo angles to
satisfy the given prose
angleArray = angleArray .* 4095./(2*pi) + 2048; % Converting the servo angles from radians to
servo count units
Dynamixel.syncWritePosition(angleArray); % Writing all calculated servo angles to the motors
while control == handles.start % Checking to see if the selected control button has changed
control = get(handles.uipanel8,'Selectedobject'); % Reading the currently selected control
button
drawnow; % Updating the code to prevent the platform from jumping
end
case handles.stop
Dynamixel.setSpeed(254,24);
pause(0.01);
Dynamixel.syncWritePosition(originAngle .* ones(1,6));
Dynamixel.waitMoveComplete(6);
pause(0.01);
Dynamixel.setSpeed(254,operatingMotorSpeed);
case handles.abort % ABORT
Dynamixel.torqueEnable(254,0); % Turning off the torque to the motors
pause(10);
break
otherwise
break % Telling the code to break if neither control button is selected (Should never happen)
end
drawnow;
otherwise
break % Telling the code to break if neither communication button is selected (Should never
happen)
– 20 –
end
drawnow; % Updating the code to prevent the platform from jumping
else
break % Breaking the code if the GUI window has been closed by the user
end
end
%% CLOSE CONNECTION TO THE SERVOS
close all hidden
disp('Move all motors to park position.'); % Letting the user know that the servos are
shutting down
Dynamixel.setSpeed(254,40); % Setting the speed for the servos to return to park position
Dynamixel.syncWritePosition(parkAngle .* ones(1,6)); % Writing the predefined park position
angle to the servos
Dynamixel.waitMoveComplete(6); % Waiting for the servos to finish moving to the park position
pause(.25); % Pausing after the motors have made it to the park position
Dynamixel.torqueEnable(254,0); % Turning off the torque to the motors after they have arrived
at the park position
disp('Torque Disabled.'); % Notify the user that the servo torque will be disabled
clear Dynamixel; % Clear the dynamixel serial port connection
disp('Connection Closed.'); % Notifying the user that the serial connection has been
terminated
– 21 –
Justin Smith
5/6/15
ME481 Final Project Report
Trebuchet Construction and Analysis
I chose to build and analyze a standard trebuchet setup for my
final project. Although fairly simple to design it was overall and
very fun and interesting project to take part in.
Trebuchets accelerate their projectiles by combining a dual
lever system that generates mechanical advantage through a
lever arm and then uses this to accelerate a sling. The sling
uses centripetal motion to accelerate the projectile, and is
designed to release at a tangent to the circular motion as the
one end detaches from the launch pin.
Although there are internal stresses in the system, the
majority of the analysis was done on parameters that could be
completely related in 2D motion. I chose to use WorkingModel
to analyze how different input parameters affected launch
performance.
My model shown to the left is a fairly simplified 2D
model of a trebuchet. I had five input parameters
that I adjusted: x-offset for the lever arm,
counterweight mass, projectile mass, sling length,
and starting counterweight height. The systems
with high counterweight: projectile mass ratios
and high mechanical advantage from the lever arm
performed the best. The projectile also flew much
further when the sling length was the same length
as the arm.
I used a simplified model by controlling the time at
which the ball was released. By rerunning
simulations and plotting velocity vectors of the
projectile, counterweight, and lever arm I was able
to analyze the momentum transfer through the system. I would note the time in which the
system seemed most promising to launch the projectile and then rerun it with the string
detaching at that time.
It seemed that the point in which the counterweight and lever arm velocities approached zero
was the point in which the ball was launched the furthest. This only occurred in situations when
the trebuchet was set up properly. It was interesting to observe how awkwardly it threw the
momentum around when it was set up improperly. It’s easy to see how these machines used to
by such deadly war machines when you see all the trajectories interacting with each other.
Simulation Results:
Mass Ratios
200
150
Height
100
-100
50
100
0
80
-50
0
100
200
300
-100
-150
Distance
400
500
600
700
60
Mech Adv Ratio
200
150
4
100
3
50
2
0
-100
0
100
200
300
400
500
600
700
1
-50
-100
Sling Length
200
150
100
4
50
12
0
-100
0
100
200
300
400
500
600
700
8
-50
-100
-150
From observing my trebuchet fire it appears to release at the right time. It does happen pretty
quickly so to be absolutely sure I would have to capture video footage and analyze it frame by
frame.
Bioloid Construction / Battlewalker Quadruped Exploration
Project
ME 481 Final Report
Ken Swidwa, Raveen Fernando, Collin Farrell
Introduction
The purpose of this project was to accumulate knowledge with regard to many-DOF walking robots
driven by Dynamixel actuators with the end goal of constructing a quadruped walker. To achieve this
goal, a kit Bioloid robot was constructed, debugged and programmed. The basic functionalities were
explored and the challenges and limitations of such a system were examined.
Robotis Dynamixel
The Robotis Dynamixel platform is popular among hobbyists and researchers alike due to its ease of use
and wide range of capabilities. As such there is existing work and multiple development environments
with pre-existing support for these actuators. Among these resources, the Trossen robotics community
forum and the Humanoid Robot Lab were the most helpful with the project providing many reference
materials and models. The Robotis support pages were also very useful, both in providing specification
sheets for the AX-12A actuators and in providing assembly instruction and example code for more than
twenty different predesigned build configurations. Figure 1 shows the three humanoid configurations
and four examples of different configurations that can be built with the kit.
F IGURE 1: B IOLOID KIT WITH E XAMPLE CONFIGURATIONS
1
RoboPlus and Control
The Bioloid kit is based around the Robotis RoboPlus platform, which is composed of three main
components: RoboPlus Manager, RoboPlus Task, and RoboPlus Motion. RoboPlus manager is used to
communicate directly with the Bioloid controller and each of the servos. From within the manager, the
parameters saved within each motor control unit such as servo ID, mode (wheel or joint) and torque
limit can be modified. The Bioloid controller sends commands to specific servo ID’s on the bus, allowing
the servos to be connected in series. RoboPlus Motion is the pose utility, allowing a user to create more
than 200 poses which are stored within the Bioloid controller. Multiple poses can be referenced in
succession, creating a motion. Separate from the motion table is the program executed which calls these
different motions based on control inputs and desired functionality. This program is modified and
uploaded via RoboPlus Task.
While each of these environment components work well, they are system specific and in many cases are
limited in their capabilities as a result of their simplicity. Fortunately there are many options for
interacting with and controlling the Dynamixels. The Dynamixel SDK is a standardized library provided by
Robotis which allows for a wide variety of C-based platforms to be used with the provided Bioloid
controller. Alternatively, the Arbotix-M provides direct interfacing with the Dynamixels and is
compatible with the Arduino IDE. There are also pre-existing libraries and examples to assist in
developing Arduino-based code for the Arbotix-M.
The use of separate motor control unit (MCU) microprocessors within each servo allows for much
simpler code development without having to worry about timing complications but also limits the
overall control flexibility. In joint mode, the MCU accepts desired position as the input and uses a
proportional controller to convert the position error to output torque. While not ideal, this does provide
a predictable linear relationship between position error and output torque such that position error
could be used as a control input when operating sufficiently far from the min and max positions (see
Figure 3: Servo Mode Range of Motion). This linear relationship, however, exists only between the
compliance margin (essentially a dead zone around the desired position) and the maximum torque.
Figure 2 shows parameters configurable in RoboPlus Manager and how the impact torque output in
joint mode. A similar relationship exists in wheel mode and is explored in detail on the Humanoid Robot
Lab page. This relationship could also allow the output torque to be used as a control input linearly
related to requested velocity.
2
F IGURE 2: R ELATIONSHIP BETWEEN OUTPUT TORQUE AND P OSITION E RROR IN JOINT MODE
F IGURE 3: SERVO MODE R ANGE OF MOTION
The most complex problem is the issue of inverse kinematics with so many degrees of freedom when
trying to implement a gait algorithm. To address this, much of the Robotis RoboPlus platform is built
around posing maneuvers, where the programmer manually articulates the joints and RoboPlus records
the servo positions. While this allows for much faster programming of robot motion it is also very
limiting. While more in depth control would allow for greater versatility, for the purposes of studying
actuator characteristics and capabilities, as well as the challenges of such large scale coordination, it is
still useful. By stringing together different similar poses macroscopic motions can be implemented with
speeds controlled by the delays between each of the poses.
3
Next Steps: Gait Algorithm and Quadruped Configuration
Moving beyond simple combinations of poses, parameterized posing is the next step in providing
dynamic and robust actuation for a wider range of situations. Also useful is the ability of the robot to
react to a variety of inputs, including disturbances to the expected states. One of the most useful
applications of this is for the maintenance of geometry stability with unplanned disturbances. When
implementing a gait algorithm based on poses, it is easy for a robot to tip itself if the terrain is uneven.
Utilizing sensors such as gyroscopes and accelerometers as well as the actuator torque measurements
to identify the start of imbalance and coding remediation strategies to keep the robot from tipping.
F IGURE 4: C ONCEPTUAL B ATTLE WALKER
Having utilized the Biped configuration as a means for becoming familiar with the hardware, the next
step will be to build the 1/6th scale quadruped and implement a gait algorithm. The final full scale walker
will resemble Figure 4. In terms of model design, the hip and shoulder structure will be very similar to
the current Bioloid configuration. The primary difference in the legs will be with the addition of the hock
or pastern (back or front) as an extra degree of freedom. To remain geometrically stable while walking,
an actuated midsection will swing to shift the center of gravity over the three legs remaining on the
4
ground (see Figure 5). This allows for stability without needing to move the enter body (including the
head).
F IGURE 5: R IGID BODY VS A RTICULATED BODY CG WEIGHT SHIFT DURING A STEP
The first step to achieve this goal will be to implement a static swinging motion, which will require
motion in the legs to accommodate for the change in body length due to the swinging motion. Because
each hip and shoulder is on the edge of the frame, the top of the legs will need to move horizontally and
vertically during the swinging motion for the feet to remain planted. For the benefit of eventual forward
walking motion, the hips will move toward the shoulders. Once the movement of the hips is mapped to
the swinging angle, the angle can be varied as necessary to balance the system during the lifting and
movement of the foot.
After utilizing the swing motion in a full gait algorithm, the eventual goal is to enable the walker to react
dynamically to disturbance inputs and terrain variation. In this scaled model this is possible using both
the torque feedback from the actuators and separate sensor readouts, though relying solely on
independent sensors provides a more versatile approach.
5
Sources:
Humanoid Robot Lab
http://humanoids.dem.ist.utl.pt/humanoid/overview.html
Robotis Dynamixel
http://www.robotis.com/xe/dynamixel_en
Arbotix-M Documentation
http://www.trossenrobotics.com/p/arbotix-robot-controller.aspx
Trossen Robotics Community
http://forums.trossenrobotics.com/
6
Stationary Bicycle Analysis
A simplified approximation
A Technical Report By:
Luke Winand
Date:
May 5th, 2015
Technical Report of Stationary Bicycle
1. Abstract
This study included the analysis of a stationary bicycle modeled as a four bar mechanism. The
main objective evaluated was the approximation of the calories burned per hour by a 250 pound
subject. The analysis was carried out by means of several methods:



Video of Bicycle motion further analyzed using Excel
Theoretical, mathematical calculations using MATLAB
Model Simulation with Software Packages:
o SolidWorks
o Working Model
The final results revealed an extremely high difference of calories burned in comparison to the
output reading of the exercise bicycle. With a 63% difference, systematic and random errors
need to be directly addressed. Oversimplification and necessary approximations are the main
contributors to this tremendously different result.
2. Introduction
In society, the necessity of a healthy lifestyle has been growing over the past few decades.
Reason being is that the obesity rate in America has been on a steady rise ever since the late
1980’s. Luckily schools and universities have been striving to influence the younger generations
to get active. In order to properly document one’s physical activity it is important to have a
source for accurate evaluation of performance.
Thus, this project was developed in order to test the validity of the reading on a stationary
bicycle exercise machine. More so, it also addresses the question of whether or not a simplified
approximation of the mechanism used to describe the motion can be applied. If the results are
too skewed from the bicycle’s approximation, then it can be concluded that a more
sophisticated analysis should be considered.
Technical Report of Stationary Bicycle
3.
Methodology
3.1 Measured Dimensions
Leg - Femoral Condyles » Medial Malleolus = 18.5”
Thigh- Greater Trochanter » Femoral Condyles = 18”
Crank- Center Axis » Pedal = 7.5” x 5/8” x 56/64”
Ground- Crank Axis » Greater Trochanter = 34.3”
3.2 Initial Assumptions and Approximations
It must first be noted that a list of approximations and simple assumption were made before the
analysis took place. Those being:
3.2.1
Four Bar vs Five Bar
Referring to Figure 1, it is noted that a bicycle model is
actually a five bar mechanism, four physical links and a
ground. For reasons of simplification of calculations and data
acquisition, this project will approximate the system as four
bar, three physical links and a ground.
Figure 1: Five Bar Mechanism
Technical Report of Stationary Bicycle
3.2.2
Grashof Condition Compliance
Figure 2: Grashof Condition For Crank-Rocker
According to Figure 2 and the dimensions from section 3.1, in order to satisfy the Grashof
Condition for a Crank Rocker there must be modifications to my dimensions. As will be
addressed later, the location of the center of mass for the anatomical links, thigh and leg,
depend on the length of the segments. It is for that reason that I decided to alter only the crank
and the ground link. The way I reduced the lengths of these two links was by deducting equal
percentages of both links until my y vs. x position plots for the knee joint from the experimental
and theoretical analyses matched.
Table 1: Link Reduction Data
Crank Length (in)
Original
7.5
Percent diff
Reduced
6.10644
19
Ground Length (in)
Original
34.3
Percent diff
Reduced
27.94356
19
Technical Report of Stationary Bicycle
3.3 Video Capture and Analysis
To increase the accuracy of the entire analysis I saw it fit to observe and study a clip of video of the
stationary bicycle motion. Visiting a local gym I captured 15 seconds of motion. Although I only
used 2 seconds in my analysis, with the rate of 30 fps, I was required to study 60 frames of motion.
Observing Figure 3, although the quality is poor, you will notice that there are two marked nodes.
One is on the knee and the other on the ankle. From Figure 4 you can see four points on each node.
Averaging the position of the left and right and top and bottom I found the center position of each
node. From this data I was then able to approximate positions and velocities for each point.
Figure 4: Video Capture Image
Figure 3: Node Points
3.4 Solidworks model
I constructed a basic four bar model with SolidWorks and used the animation tool to analyze the
kinematics. Figure 5 shows the model.
Figure 4: SolidWorks Model
Technical Report of Stationary Bicycle
3.5 Dempster Chart
Before moving on to the Working Model rendering I must mention a few points about the
Dempster chart. The Dempster chart was constructed in order to approximate segment mass,
length and moment of inertia based off the total length of the segment and the total mass of
the subject alone. In table 2, I have shown the relevant portion of the chart for this study. The
entire chart is available in the Appendix
Table 2: Dempster Information
Segment Name
Endpoints (Proximal to Distal)
Seg. Mass/ Total Mass
Leg
Thigh
Femoral Condyles to Medial Malleolus
Greater Trochanter to Femoral Condyles
(P)
0.0465
0.1
COM/ Seg. Length
(Rprox)
0.433
0.433
(Rdist)
0.567
0.567
Radius of Gyration / Seg Length
(Kcg)
0.302
0.323
(Kprox)
0.528
0.54
(Kdist)
0.643
0.653
Table 3: Data for Anatomical Links
Total Mass (kg)
Leg Length (m)
Thigh Length (m)
113.40
0.47
0.46
Mass of Leg (kg)
Mass of Thigh (kg)
Prox Distance to Leg COM (m)
5.27
11.34
0.20
Prox Distance to Thigh COM (m)
Moment of Inertia Leg (N*m^2)
Moment of Inertia Thigh (N*m^2)
3.6 Working model
In addition to SolidWorks, I also constructed a Working Model rendering of the four bar. From
this model I analyzed both the kinematics and the dynamics of the system. Figure 6 shows the
model.
Figure 6: Working Model Rendering
0.20
0.11
0.25
Technical Report of Stationary Bicycle
3.7 MATLAB
All of my calculations from here on out were performed in MATLAB. The calculations include:


Kinetic data: Complex Number equations, SolidWorks data, Working Model data
Dynamics data: Matrix constructed from Notes 8_02 curtesy of Dr. H. J. Sommer, Working
Model data.
4. Results
3.8 Excel Plots from Video Capture
25
Crank Angle vs Time
0.4
0.35
0.3
0.25
0.2
0.15
0.1
0.05
0
Angle (rad)
20
15
10
y = 9.1845x + 1.9223
5
0.2
0.3
0.4
0.5
0
0.6
0
X position (m)
0.5
1
1.5
Time (sec)
Figure 8: Crank Angle vs Time
Figure 7: Y vs X Position of Ankle Point
Y vs X position (knee)
0.85
0.8
0.75
Y position (m)
Y position (m)
Y vs X position (ankle)
0.7
0.65
0.6
0.55
0.5
0.45
0.4
0.54
0.56
0.58
0.6
0.62
0.64
X position (m)
Figure 9: Y vs X position of Knee Point
0.66
2
2.5
Technical Report of Stationary Bicycle
Figures 7-9 show the results from the video capture analysis. Commenting on the general shape of
Figure 7, had this been an actual four bar the plot would have been more circular. Due to the five
bar nature it is more elliptical. Figure 8 completes the approximation for the average RPM. Figure
shows the three approximations for the RPM. The manual calculation was estimated by counting the
RPMexcel= 87.7
RPMmanually= 86
RPMmachine= 90
Figure 10: RPM approximations
number of rotations over the 15 second video. Furthermore the RMPmachine was what the machine
read while I pedaled. Finally, Figure 9 shows the shape of the path that the knee joint follows. I
found this plot important in determining the reduction amount from the ground and crank lengths
by comparing its shape to the kinematic results from the four bar. Figure 11 shows these plots for
five different reduction amounts. The third path from the right seemed to match the Excel data the
closest.
Figure 11: Y vs X Position of the Knee point from Four Bar
Technical Report of Stationary Bicycle
3.9 Plots for Kinematic results
Figure 12: Angle of Leg and Thigh vs Crank Angle
Figure 13: Angluar Velocity of Leg and Thigh vs Crank Angle
Figure 14: Angular Acceleration of Leg and Thigh vs Crank Angle
Figures 12-14 show that the Angular Position, Velocity, and Acceleration for the Theoretical
Complex number equations and for the SolidWorks match precisely. Working Model’s
Kinematic results are the same, although not included in plots. The codes from the index
include working model kinematic data files.
Technical Report of Stationary Bicycle
3.10
Plots for Dynamic results
Torque vs Crank Angle
Normal Crank Force vs Crank Angle
20
200
Equations
Working Model
15
Equations
Working Model
150
Normal Crank Force (N)
10
Torque (N-m)
5
0
-5
-10
100
50
0
-50
-15
-100
-20
-25
-150
0
50
100
150
200
250
Crank Angle (degrees)
300
350
400
0
50
100
150
200
250
Crank Angle (deg)
300
350
400
Figure 16: Normal Crank Force vs Crank Angle
Figure 15: Torque vs Crank Angle
F12y vs Crank Angle
F12x vs Crank Angle
250
200
Equations
Working Model
Equations
Working Model
200
150
150
F12x (N)
F12y (N)
100
100
50
50
0
0
-50
-100
-50
0
50
100
150
200
250
Crank Angle (degrees)
300
350
0
50
100
150
200
250
Crank Angle (degrees)
400
300
350
400
Figure 18: F12y vs Crank Angle
Figure 17: F12x vs Crank Angle
F23x vs Crank Angle
F23y vs Crank Angle
200
250
Equations
Working Model
Equations
Working Model
200
150
150
F23y (N)
F23x (N)
100
50
100
50
0
0
-50
-50
0
50
100
150
200
250
Crank Angle (degrees)
300
350
Figure 19: F23x vs Crank Angle
400
-100
0
50
100
150
200
250
Crank Angle (degrees)
300
Figure 20: F23y vs Crank Angle
350
400
Technical Report of Stationary Bicycle
F34x vs Crank Angle
F34y vs Crank Angle
180
140
Equations
Working Model
160
Equations
Working Model
120
140
100
120
80
F34y (N)
F34x (N)
100
80
60
40
60
20
40
0
20
-20
0
-20
-40
0
50
100
150
200
250
Crank Angle (degrees)
300
350
400
0
50
100
150
200
250
Crank Angle (degrees)
300
350
400
Figure 22: F34y vs Crank Angle
Figure 21: F34x vs Crank Angle
F14x vs Crank Angle
F14y vs Crank Angle
50
90
Equations
Working Model
Equations
Working Model
85
0
80
75
-50
F14y (N)
F14x (N)
70
-100
65
60
55
-150
50
45
-200
0
50
100
150
200
250
Crank Angle (degrees)
300
350
400
40
0
Figure 23: F14x vs Crank Angle
Figure 25: Crank Normal Angle
50
100
150
200
250
Crank Angle (degrees)
300
Figure 24: F14y vs Crank Angle
350
400
Technical Report of Stationary Bicycle
Figures 15-24 illustrate that Torque and Forces Between the Joints in the model. Figure 25 shows
the method of calculating the angle between the resultant force F12 and the normal to the crank. In
the next section the equation explaining why we need this angle will be observed.
3.11
Calorie Estimation
By definition 1 kcal= 4.184 kJ. If the human body were 100% efficient then this would be the
conversion factor between mechanical work and calories burned. Since about 80% of the energy
from ingested food is converted into wasted heat, it is generally accepted that 1kcal = 1 kJ. Also,
keep in mind that the unit kcal is actually what is commonly referred to as a calorie in terms of
consumption.
3.12
Calorie estimation
𝜃2
𝑊 = ∫𝜃1 𝐹⊥ 𝑅 𝑑𝜃 = 𝐹̅12 cos((90 − 𝜃) + 𝛼) 𝑅 𝑑𝜃
𝐽
𝑊𝑤𝑚 = 35.3
𝑟𝑒𝑣
𝑟𝑒𝑣
𝑘𝐽
𝑐𝑎𝑙
𝑊𝑡𝑜𝑡𝑎𝑙 = 2𝑊𝑤𝑚 ∗
= 368.7
= 368.7
ℎ𝑟
𝐻𝑟
𝐻𝑟
𝐽
𝑊𝐸𝑞 = 33.5
𝑟𝑒𝑣
𝑟𝑒𝑣
𝑘𝐽
𝑐𝑎𝑙
𝑊𝑡𝑜𝑡𝑎𝑙 = 2𝑊𝐸𝑞 ∗
= 350.7
= 350.7
ℎ𝑟
𝐻𝑟
𝐻𝑟
In order to estimate the calories burned we first must apply the top equation to both the Equation
evaluation along with Working Model’s. This equation for work is the reason for calculating the
angle from the crank normal. Assuming that this is the energy required for one rotation, to
calculate the total energy per hour one must account for the other leg and multiply the Joules per
revolution by two. Finally the Joules per revolution must be multiplied by the number of rotations
per hour in order to estimate calories burned per hour. In order to evaluate the intergral I used
MATLAB’s built-in “trapz” function to estimate the area under the curve.
Technical Report of Stationary Bicycle
5. Discussion and Conclusion
When video capture of the stationary bicycle was taken, the readings for RPM and calories burned
per hour were 90 and 135. In terms of the RPM my analysis provided, only a 2.5% difference
resulted. On the other hand, my final calorie estimation overshot the machine reading
tremendously. With a 63% difference a few sources for this difference must be mentioned.
As with any experiment, there is always the possibility for error. In this particular study, it should be
noted that possibility for both systematic and random error were present. In terms of random error,
the measurements I took on my body could have caused discrepancies in the results.
Systematically, it can be assumed that the four bar approximation had a large impact on the results.
With this such a difference, the conclusion is that in order appropriately approximate the rate of
calories burned per hour the five bar model must be implemented.
Technical Report of Stationary Bicycle
Appendix
Excel Spreadsheets
Table 4: Video Capture point data (first 30 points)
Time
0
0.033333333
0.066666667
0.1
0.133333333
0.166666667
0.2
0.233333333
0.266666667
0.3
0.333333333
0.366666667
0.4
0.433333333
0.466666667
0.5
0.533333333
0.566666667
0.6
0.633333333
0.666666667
0.7
0.733333333
0.766666667
0.8
0.833333333
0.866666667
0.9
0.933333333
0.966666667
xLank
69
61
53
47
45
49
50
60
71
81
89
97
104
109
115
119
121
118
110
101
88
80
70
52
46
45
47
51
58
70
xRank
83
76
68
55
53
55
65
73
84
93
102
109
118
121
126
129
129
124
119
115
104
92
84
71
59
54
55
61
72
79
yTank
118
123
132
144
156
169
179
186
197
184
178
171
163
154
145
136
132
124
118
113
113
114
122
137
146
156
166
178
189
193
yBank
128
136
144
155
169
180
194
197
186
195
192
183
176
169
160
152
144
134
127
122
123
127
133
148
157
166
179
191
199
199
xLknee
133
129
127
126
124
125
124
125
125
125
125
127
126
129
130
131
133
135
138
140
140
138
134
127
126
125
124
126
127
126
xRknee
140
136
133
131
130
129
132
132
131
131
131
132
134
135
136
138
141
142
144
145
146
144
142
135
133
131
131
132
131
132
yTknee
28
36
49
59
74
86
93
96
94
88
80
71
66
56
48
40
32
24
17
16
17
24
32
51
65
75
82
94
100
99
yBknee
37
49
60
74
85
95
101
103
101
97
89
82
74
69
60
52
43
36
26
23
25
32
41
64
75
83
97
103
105
106
Technical Report of Stationary Bicycle
Table 5: Adjusted Y axis (first 30)
yTank
82
77
68
56
44
31
21
14
3
16
22
29
37
46
55
64
68
76
82
87
87
86
78
63
54
44
34
22
11
7
yBank
72
64
56
45
31
20
6
3
14
5
8
17
24
31
40
48
56
66
73
78
77
73
67
52
43
34
21
9
1
1
yTknee
172
164
151
141
126
114
107
104
106
112
120
129
134
144
152
160
168
176
183
184
183
176
168
149
135
125
118
106
100
101
yBknee
163
151
140
126
115
105
99
97
99
103
111
118
126
131
140
148
157
164
174
177
175
168
159
136
125
117
103
97
95
94
Technical Report of Stationary Bicycle
Table 6: Averaged location in pixels (first 30)
Pixels
xank
76
68.5
60.5
51
49
52
57.5
66.5
77.5
87
95.5
103
111
115
120.5
124
125
121
114.5
108
96
86
77
61.5
52.5
49.5
51
56
65
74.5
85.5
yank
77
70.5
62
50.5
37.5
25.5
13.5
8.5
8.5
10.5
15
23
30.5
38.5
47.5
56
62
71
77.5
82.5
82
79.5
72.5
57.5
48.5
39
27.5
15.5
6
4
6.5
xknee
136.5
132.5
130
128.5
127
127
128
128.5
128
128
128
129.5
130
132
133
134.5
137
138.5
141
142.5
143
141
138
131
129.5
128
127.5
129
129
129
129
yknee
167.5
157.5
145.5
133.5
120.5
109.5
103
100.5
102.5
107.5
115.5
123.5
130
137.5
146
154
162.5
170
178.5
180.5
179
172
163.5
142.5
130
121
110.5
101.5
97.5
97.5
102
Technical Report of Stationary Bicycle
Table 7: Average Location in meters (first 30)
Meters
xank
yank
xknee
yknee
0.334734722
0.30170169
0.266466456
0.224624616
0.215815808
0.22902902
0.253253244
0.292892882
0.341341328
0.383183169
0.420620605
0.453653636
0.48888887
0.506506487
0.530730711
0.546146125
0.55055053
0.532932913
0.504304285
0.475675658
0.422822807
0.378778764
0.339139126
0.270870861
0.231231222
0.21801801
0.224624616
0.246646637
0.286286275
0.328128116
0.339139126
0.310510499
0.273073063
0.222422414
0.165165159
0.112312308
0.059459457
0.037437436
0.037437436
0.046246244
0.066066064
0.101301297
0.134334329
0.169569563
0.209209201
0.246646637
0.273073063
0.312712701
0.341341328
0.36336335
0.361161147
0.350150137
0.319319307
0.253253244
0.213613606
0.171771765
0.121121117
0.068268266
0.026426425
0.017617617
0.601201
0.583584
0.572573
0.565966
0.559359
0.559359
0.563764
0.565966
0.563764
0.563764
0.563764
0.57037
0.572573
0.581381
0.585786
0.592392
0.603403
0.61001
0.621021
0.627628
0.62983
0.621021
0.607808
0.576977
0.57037
0.563764
0.561562
0.568168
0.568168
0.568168
0.737738
0.693694
0.640841
0.587988
0.530731
0.482282
0.453654
0.442643
0.451451
0.473473
0.508709
0.543944
0.572573
0.605606
0.643043
0.678278
0.715716
0.748749
0.786186
0.794995
0.788388
0.757558
0.72012
0.627628
0.572573
0.532933
0.486687
0.447047
0.429429
0.429429
ankle to
crank
0.189502
0.14847
0.100468
0.046602
0.023699
0.065358
0.119048
0.1509
0.174965
0.196919
0.215369
0.230357
0.256325
0.27043
0.29627
0.317628
0.328636
0.326192
0.314332
0.303287
0.262005
0.224093
0.175429
0.083519
0.036673
0.018984
0.057334
0.10951
0.158953
0.18424
Technical Report of Stationary Bicycle
Table 8: Data for crank position (first 30)
x from crank cent
0.098548545
0.065515513
0.030280279
-0.011561561
-0.02037037
-0.007157157
0.017067066
0.056706705
0.105155151
0.146996991
0.184434427
0.217467459
0.252702693
0.27032031
0.294544533
0.309959948
0.314364352
0.296746736
0.268118108
0.23948948
0.18663663
0.142592587
0.102952949
0.034684683
-0.004954955
-0.018168167
-0.011561561
0.01046046
0.050100098
0.091941938
y from crank
cent
0.161861856
0.133233228
0.095795792
0.045145143
-0.012112112
-0.064964963
-0.117817813
-0.139839835
-0.139839835
-0.131031026
-0.111211207
-0.075975973
-0.042942941
-0.007707707
0.031931931
0.069369367
0.095795792
0.13543543
0.164064058
0.186086079
0.183883877
0.172872866
0.142042037
0.075975973
0.036336335
-0.005505505
-0.056156154
-0.109009005
-0.150850845
-0.159659654
Technical Report of Stationary Bicycle
Table 9: Data for angle of crank (first 30)
Time
0
0.033333
0.066667
0.1
0.133333
0.166667
0.2
0.233333
0.266667
0.3
0.333333
0.366667
0.4
0.433333
0.466667
0.5
0.533333
0.566667
0.6
0.633333
0.666667
0.7
0.733333
0.766667
0.8
0.833333
0.866667
0.9
0.933333
0.966667
theta (rad)
1.02
1.11
1.26
-1.32
0.54
1.46
-1.43
-1.19
-0.93
-0.73
-0.54
-0.34
-0.17
-0.03
0.11
0.22
0.30
0.43
0.55
0.66
0.78
0.88
0.94
1.14
-1.44
0.29
1.37
-1.48
-1.25
-1.05
Technical Report of Stationary Bicycle
MATLAB codes
% fourbar_kin.m - four bar kinematics
%
geometric and complex number methods
% HJSIII, 04.03.15
clc,clear
% general constants
d2r = pi / 180;
% link lengths and coupler angle
data= xlsread('solid.xlsx');
%Solid Works Data
swth2= data(:, 2); %deg
swth3= data(:, 4); %deg
swth3d= data(:,7); %rad/s
swth3dd= data(:,9); %rad/s/s
swth4= data(:,10); %deg
swth4d= data(:,13); %rad/s
swth4dd= data(:, 15); %rad/s/s1.147612188
data2= xlsread('WM_disp.xlsx');
wmth2= data2(:,2);
wmth3= data2(:,3);
wmth4= data2(:,4);
%Working Model angles
wmth2= wmth2/d2r -180;
%Working model angles adjusted to prescrbed
%coordinate system
wmth3= wmth3/d2r + 180;
wmth4= wmth4/d2r +180;
data3= xlsread('WM_vel.xlsx');
%WM velocity
wmth3d= data3(:,2);
wmth4d= data3(:,3);
data4= xlsread('WM_acc.xlsx'); %WM acceleration
wmth3dd= data4(:,2);
wmth4dd= data4(:,3);
r1
r2
r3
r4
=
=
=
=
27.94356026;
6.106439735;
18.5;
18;
r1= r1*(2.54/100);
r2= r2*(2.54/100);
%Link lengths (inches)
%Link Lengths (meters)
Technical Report of Stationary Bicycle
r3= r3*(2.54/100);
r4= r4*(2.54/100);
th1=27.61697412;
th1= th1*d2r;
% crank
w2 = 9.126766157;
a2= 0;
%ground angle deg
%ground angle rad
% [rad/sec]
% reduced motion
th2min_deg = -th1/d2r;
th2max_deg =-th1/d2r+360;
th1= 27.61697412;
% allocate empty array to hold values
keep_m = [];
keep_g = [];
% crank angle
for th2_deg = th2min_deg : 1 : th2max_deg,
%for th2_deg = 65 : 65,
th2 = th2_deg * d2r ;
% geometric position equations
e = sqrt( r1*r1 + r2*r2 - 2*r1*r2*cos(th2) );
alpha = asin( r2 * sin(th2) / e );
gamma = acos( ( r3*r3 + r4*r4 - e*e ) /2 /r3 /r4 );
beta = asin( r3 * sin(gamma) / e );
th4 = pi - alpha - beta;
th3 = th4 - gamma;
% matrix velocity equations
JAC = [ -r3*sin(th3)
r4*sin(th4) ;
r3*cos(th3) -r4*cos(th4) ];
vrhs = [
r2*w2*sin(th2) ;
-r2*w2*cos(th2) ];
vsol = inv(JAC) * vrhs;
w3 = vsol(1);
w4 = vsol(2);
% geometric velocity solutions
th2d = w2;
ed = r1*r2*th2d*sin(th2) / e;
ad = ( r2*th2d*cos(th2) - ed*sin(alpha) ) /e /cos(alpha);
gd = e*ed /r3 /r4 /sin(gamma);
bd = ( r3*gd*cos(gamma) - ed*sin(beta) ) /e / cos(beta);
th4d = -ad - bd;
Technical Report of Stationary Bicycle
th3d = th4d - gd;
% matrix acceleration equations
arhs = [ r2*a2*sin(th2)+r2*w2*w2*cos(th2)+r3*w3*w3*cos(th3)r4*w4*w4*cos(th4) ;
-r2*a2*cos(th2)+r2*w2*w2*sin(th2)+r3*w3*w3*sin(th3)r4*w4*w4*sin(th4) ];
asol = inv(JAC) * arhs;
a3 = asol(1);
a4 = asol(2);
% geometric acceleration solutions
th2dd = a2;
edd = ( r1*r2*(th2d*th2d*cos(th2) + th2dd*sin(th2)) - ed*ed ) / e;
add = ( -r2*th2d*th2d*sin(th2) +r2*th2dd*cos(th2) - edd*sin(alpha) ...
-2*ed*ad*cos(alpha) + e*ad*ad*sin(alpha) ) /e /cos(alpha);
gdd = ( ed*ed +e*edd - r3*r4*gd*gd*cos(gamma) ) /r3 /r4 /sin(gamma);
bdd = ( -r3*gd*gd*sin(gamma) +r3*gdd*cos(gamma) -edd*sin(beta) ...
-2*ed*bd*cos(beta) +e*bd*bd*sin(beta) ) /e / cos(beta);
th4dd = -add - bdd;
th3dd = th4dd - gdd;
keep_m = [ keep_m ; (th2)
keep_g = [ keep_g ; (th2)
(th3) (th4) w3
w4
a3
a4
(th3) (th4) th3d th4d th3dd th4dd
];
];
end
th2_deg = (keep_m(:,1) / d2r) +th1;
th3_deg = (keep_m(:,2) / d2r) +th1;
th4_deg = (keep_m(:,3) / d2r) +th1;
w3
w4
a3
a4
=
=
=
=
keep_m(:,4);
keep_m(:,5);
keep_m(:,6);
keep_m(:,7);
th3d = keep_g(:,4);
th4d = keep_g(:,5);
th3dd = keep_g(:,6);
th4dd = keep_g(:,7);
figure( 1 )
clf
plot( th2_deg,th3_deg,'r', th2_deg,th4_deg,'g', swth2, swth3, 'bo', swth2,
swth4, 'co')
xlabel( 'Theta 2 [deg]' )
ylabel( 'Angle [deg]' )
legend( 'link 3 complex', 'link 4 complex', 'link 3 solidworks', 'link 4
solidworks' )
title( 'Four bar r1=27.9, r2=6.10, r3=18.5, r4=18' )
Technical Report of Stationary Bicycle
figure( 2 )
clf
plot( th2_deg,th3d,'b', th2_deg,th4d,'k', swth2, swth3d, 'bo', swth2,
swth4d, 'co' )
xlabel( 'Theta 2 [deg]' )
ylabel( 'Angular velocity [rad/sec]' )
legend( 'link 3 complex ', 'link 4 complex ', ...
'link 3 solidworks', 'link 4 solidworks' )
title( 'Four bar r1=27.9, r2=6.10, r3=18.5, r4=18' )
figure( 3 )
clf
plot( th2_deg,th3dd,'b', th2_deg,th4dd,'k', swth2, swth3dd, 'bo', swth2,
swth4dd, 'co' )
xlabel( 'Theta 2 [deg]' )
ylabel( 'Angular acceleration [rad/sec/sec]' )
legend( 'link 3 complex ', 'link 4 complex ', ...
'link 3 solidworks', 'link 4 solidworks' )
title( 'Four bar r1=27.9, r2=6.10, r3=18.5, r4=18' )
%finding path of knee joint
x1= r2*cos(th2_deg*d2r);
%accounting for crank movement
y1= r2*sin(th2_deg*d2r);
x2= r3*cos(th3_deg*d2r);
y2= r3*sin(th3_deg*d2r);
X=(x1+x2);
Y=(y1+y2);
figure(4)
%accounting for knee movement
%finding x and y point of knee joint
plot(X,Y)
hold on
figure(5)
clf
plot(wmth2, wmth3, wmth2,wmth4);
xlabel( 'Theta 2 [deg]' )
ylabel( 'Angle [deg]' )
legend('Link 3 Working Model', 'Link 4 Working Model')
figure(6)
clf
plot(wmth2, wmth3d, wmth2, wmth4d)
xlabel( 'Theta 2 [deg]' )
ylabel( 'Angular velocity [rad/sec]' )
legend('Link 3 Working Model', 'Link 4 Working Model')
Technical Report of Stationary Bicycle
figure(7)
clf
plot(wmth2, wmth3dd, wmth2, wmth4dd)
xlabel( 'Theta 2 [deg]' )
ylabel( 'Angular acceleration [rad/sec/sec]' )
legend('Link 3 Working Model', 'Link 4 Working Model')
title( 'Four bar r1=27.9, r2=6.10, r3=18.5, r4=18' )
% Force Analysis of Four Bar (bicycle simulation)
% Luke Winand
clc,clear
data= xlsread('WM_F12.xlsx');
wmF12x= data(:,2);
wmF12y= data(:,3);
data2= xlsread('WM_F23.xlsx');
wmF23x= data2(:,2);
wmF23y= data(:,3);
data3= xlsread('WM_T12.xlsx');
wmT12= data3(:,2);
data4= xlsread('WM_F34.xlsx');
wmF34x= data4(:,2);
wmF34y= data4(:,3);
data5= xlsread('WM_F14.xlsx');
wmF14x= data5(:,2);
wmF14y= data5(:,3);
load('data_kin.mat')
grav= -9.807; %acceleration due to gravity
g2d= r2/2;
%Distance from ground revolute to COM of crank
g3d= 0.2664333; % this is the distance from the distal end of the
g4d= 0.2592324; %shin to the calculated center of gravity position from
%Dempster
Technical Report of Stationary Bicycle
g2p= r2-g2d;
g3p= r3-g3d;
g4p= r4-g4d;
%Proximal distance to center of mass
Pshin= 0.0465; %segment mass over total mass
Pthigh= 0.1;
rho= 2685; %density of crank
tcrank= 16e-3; %meters
wcrank= 48e-3;
lcrank= r2;
Vcrank= tcrank*lcrank*wcrank;
mtot= 113.398073; %total mass kg
m2= rho*Vcrank;
m3= mtot*Pshin;
m4= mtot*Pthigh;
Kcgshin=0.302; %Radius of Gyration/Segment Length (from Dempster)
Kcgthigh= 0.323;
Jg2p= (1/12)*m2*(wcrank^2+lcrank^2); %Moments of inertia of links
Jg3p= m3*(Kcgshin*r3)^2;
Jg4p= m4*(Kcgthigh*r4)^2;
th2=th2_deg*d2r;
th3= th3_deg*d2r;
th4= th4_deg*d2r;
W2= m2*grav; %Force of Gravity on links
W3= m3*grav;
W4= m4*grav;
keep_m= [];
for i=1:length(th2_deg)
ag2x(i)= -g2d*w2^2*cos(th2(i))-g2d*a2*sin(th2(i)); %accelerations COM
ag2y(i)= -g2d*w2^2*sin(th2(i))+g2d*a2*cos(th2(i));
ag3x(i)= -r2*w2^2*cos(th2(i))-r2*a2*sin(th2(i))-g3d*th3d(i)^2*cos(th3(i))...
-g3d*th3dd(i)*sin(th3(i));
ag3y(i)= -r2*w2^2*sin(th2(i))+r2*a2*cos(th2(i))-g3d*th3d(i)^2*sin(th3(i))...
+g3d*th3dd(i)*cos(th3(i));
ag4x(i)= -g4d*th4d(i)^2*cos(th4(i))-g4d*th4dd(i)*sin(th4(i));
ag4y(i)= -g4d*th4d(i)^2*sin(th4(i))+g4d*th4dd(i)*cos(th4(i));
Ag2(i)= complex(ag2x(i),ag2y(i));
Ag3(i)= complex(ag3x(i),ag3y(i));
Ag4(i)= complex(ag4x(i),ag4y(i));
Technical Report of Stationary Bicycle
g2dx(i)=
g2dy(i)=
g3dx(i)=
g3dy(i)=
g4dx(i)=
g4dy(i)=
g2d*cos(th2(i));
g2d*sin(th2(i));
g3d*cos(th3(i));
g3d*sin(th3(i));
g4d*cos(th4(i));
g4d*sin(th4(i));
g2px(i)=
g2py(i)=
g3px(i)=
g3py(i)=
g4px(i)=
g4py(i)=
g2p*cos(th2(i));
g2p*sin(th2(i));
g3p*cos(th3(i));
g3p*sin(th3(i));
g4p*cos(th4(i));
g4p*sin(th4(i));
phi=
[1 0 -1 0 0 0 0 0 0; 0 1 0 -1 0 0 0 0 0; g2dy(i) -g2dx(i) g2py(i)...
-g2px(i) 0 0 0 0 1; 0 0 1 0 -1 0 0 0 0; 0 0 0 1 0 -1 0 0 0; 0 0
g3dy(i)...
-g3dx(i) g3py(i) -g3px(i) 0 0 0; 0 0 0 0 1 0 1 0 0 ;0 0 0 0 0 1 0 1 0;
...
0 0 0 0 -g4dy(i) g4dx(i) +g4py(i) -g4px(i) 0];
rhs= [m2*ag2x(i); m2*ag2y(i)-W2; Jg2p*a2; m3*ag3x(i); m3*ag3y(i)- W3; ...
Jg3p*th3dd(i); m4*ag4x(i); m4*ag4y(i)-W4; Jg4p*th4dd(i)];
OUT= inv(phi)*rhs;
F12x= OUT(1);
F12y= OUT(2);
F23x= OUT(3);
F23y= OUT(4);
F34x= OUT(5);
F34y= OUT(6);
F14x= OUT(7);
F14y= OUT(8);
T12= OUT(9);
keep_m= [keep_m; F12x F12y F23x F23y F34x F34y F14x F14y T12];
end
% OUT= keep_m(:,1);
F12x= keep_m(:,1);
F12y= keep_m(:,2);
F23x= keep_m(:,3);
F23y= keep_m(:,4);
F34x= keep_m(:,5);
F34y= keep_m(:,6);
F14x= keep_m(:,7);
F14y= keep_m(:,8);
T12= keep_m(:,9);
Technical Report of Stationary Bicycle
wmF12= sqrt(wmF12x.^2+ wmF12y.^2);
figure(1)
plot(th2_deg, T12, 'b', wmth2, wmT12, 'g')
title('Torque vs Crank Angle')
xlabel('Crank Angle (degrees)')
ylabel('Torque (N-m)')
legend('Equations', 'Working Model')
figure(2)
plot(th2_deg, F12x, 'b', wmth2, wmF12x, 'g')
title('F12x vs Crank Angle')
xlabel('Crank Angle (degrees)')
ylabel('F12x (N)')
legend('Equations', 'Working Model')
figure(3)
plot(th2_deg, F12y, 'b', wmth2, wmF12y, 'g')
title('F12y vs Crank Angle')
xlabel('Crank Angle (degrees)')
ylabel('F12y (N)')
legend('Equations', 'Working Model')
figure(4)
plot(th2_deg, F23x, 'b', wmth2, wmF23x, 'g')
title('F23x vs Crank Angle')
xlabel('Crank Angle (degrees)')
ylabel('F23x (N)')
legend('Equations', 'Working Model')
figure(5)
plot(th2_deg, F23y, 'b', wmth2, wmF23y, 'g')
title('F23y vs Crank Angle')
xlabel('Crank Angle (degrees)')
ylabel('F23y (N)')
legend('Equations', 'Working Model')
figure(6)
plot(th2_deg, F34x, 'b', wmth2, wmF34x, 'g')
title('F34x vs Crank Angle')
xlabel('Crank Angle (degrees)')
ylabel('F34x (N)')
legend('Equations', 'Working Model')
figure(7)
plot(th2_deg, F34y, 'b', wmth2, wmF34y, 'g')
title('F34y vs Crank Angle')
Technical Report of Stationary Bicycle
xlabel('Crank Angle (degrees)')
ylabel('F34y (N)')
legend('Equations', 'Working Model')
figure(8)
plot(th2_deg, F14x, 'b', wmth2, -wmF14x, 'g')
title('F14x vs Crank Angle')
xlabel('Crank Angle (degrees)')
ylabel('F14x (N)')
legend('Equations', 'Working Model')
figure(9)
plot(th2_deg, F14y, 'b', wmth2, -wmF14y, 'g')
title('F14y vs Crank Angle')
xlabel('Crank Angle (degrees)')
ylabel('F14y (N)')
legend('Equations', 'Working Model')
keep_F= [];
wmkeep_F= [];
for i=1:length(F23x) %Finding force normal to crank end
F23= sqrt(F23x(i)^2+F23y(i)^2)
alph= atan(F23y(i)/F23x(i));
keep_F= [keep_F; F23, alph];
end
alpha= keep_F(:,2);
F23= keep_F(:,1);
%Angle between original coordinate system and F23
%magnitude
%F23 magnitude
zet= ((pi/2)-th2)+alpha;
Fnorm= F23.*cos(zet);
M= Fnorm*r2;
work= trapz(th2,M)
% new found normal angle
%normal force to crank
% moment on crank
%integrated curve of moment
for i= 1:length(wmF23x) %Finding force normal to crank end in working model
wmF23= sqrt(wmF23x(i)^2+wmF23y(i)^2);
wmalph= atan(wmF23y(i)/wmF23x(i));
wmkeep_F= [wmkeep_F; wmF23, wmalph];
Technical Report of Stationary Bicycle
end
wmalpha= wmkeep_F(:,2);
wmF23= wmkeep_F(:,1);
wmzet= ((pi/2)-wmth2*d2r)+wmalpha;
wmFnorm= wmF23.*cos(wmzet);
wmM= wmFnorm*r2;
wmwork= trapz(wmth2*d2r,wmM)
figure(10)
plot(th2/d2r,Fnorm, wmth2, wmFnorm)
title('Normal Crank Force vs Crank Angle')
xlabel('Crank Angle (deg)')
ylabel('Normal Crank Force (N)')
legend('Equations', 'Working Model')
Technical Report of Stationary Bicycle
Technical Report of Stationary Bicycle
The Napier Deltic By Ross Wingard 5/6/15 The Napier Deltic
The Napier Deltic is a complicated engine that was designed to be used in trains, boats,
and power generation. It can be assembled in several different configurations such as a 9
cylinder configuration known as the baby Deltic, and the 18 cylinder configuration that
had a total of 32 separate pistons and could generate over 1500 hp.
While the Napier Deltic is big, at the time of its creation, it had one of the best power to
weight ratios of any other engine. This coupled to the fact that it ran a 2 stroke
configuration meant that it was capable of very high power for its relative size.
Coupled to this is the fact that since it had an entire gear system just to keep the engine
timed correctly, it had a very large rotating mass which helped give the engine a very
smooth power delivery. This also was helped by the fact that the engine was perfectly self
balancing with just the geometry alone which helped make the engine run smooth as silk.
For my analysis, I decided to use the simulation program Algoodo for the fact that is
capable of running this high body system accurately in real time. Unfortunately, it is
incapable of exporting values to an outside program; however, it has an already very
capable graphing mechanism included.
One Piston at a Time
First I analyzed the position, velocity, acceleration, force and jerk of a single piston on
the engine. This would give me an idea of what kind of forces a typical engine of this size
is dealing with. The engine parameters I would be testing were to have a stroke of 60cm,
a connecting rod that weighed 10kg, and a piston that weighed 20kg. I used these
parameters because this engine was typically used in very large displacements so I
wanted a fairly accurate representation of the forces.
Figure 1: Single piston from the engine that I analyzed.
Figure 2: position vs time plot which shows a stroke of 60 cm.
Figure 3: velocity vs time plot that shows the highest velocity achieved by the piston at
200RPM was about 7m/s.
Figure 4: Acceleration vs time plot shows the acceleration the piston undergoes
throughout its cycle. Here we can also se that Algoodos grapher solved for the derivative
of the acceleration as well giving us jerk. The jerk is 3200m/s3 which means that this
single cylinder does a lot of shaking on its own.
Figure 5: Force vs time shows us that the average shaking force that this engine would
experience is roughly about 650N which is a very large shaking force.
Next I was curious about how much shaking force that the connecting rod would create
on its own. This would be important as well because in just one layer of the Napier Deltic
engine it has 6 separate connecting rods that can all individually cause a shaking force.
So I proceeded to plot the shaking forces in the vertical direction of the connecting rod on
the single cylinder engine.
Figure 6: Acceleration vs time of the connecting rod in the vertical direction. As can be
seen here, the acceleration of the connecting rod alone is about 80m/s2. That coupled to
the fact that the jerk from the connecting rods alone is 1300m/s3 makes for a rather large
vibration from the connecting rods.
Figure 7: Force vs time graph of the connecting rod in the vertical direction. Again we
can see that just from the connecting rods alone we generated almost a 200N force which
would end up causing some considerable vibrations.
2 is better then 1
Next I decided to see what kind of forced would be created with a twin opposing piston
system. This is the main concept design behind the Napier Deltic engine that supposedly
makes it so smooth. This I wanted to put to the test.
Figure 8: Twin opposing piston setup which is the main design behind the Napier Deltic
engine.
First I decided to test the vibrations created by the pistons in the twin opposing piston
setup. To do so I plotted the average position, velocity, acceleration, jerk, and force of the
two pistons. If the engine is as balanced as they claim, then the two pistons values should
cancel each other and give very low numbers in the plots.
Figure 9: Average Position vs time plot of the twin opposing piston setup. As predicted,
the two pistons nearly perfectly cancel each other out to create almost no average
deviation from the starting point.
Figure 10: Average velocity vs time plot of the twin opposing piston setup. Again as
predicted, the two pistons nearly perfectly cancel each other out so that the average
velocity’s between the two are nearly 0.
Figure 11: Average acceleration vs time plot of the twin opposing piston setup. Here we
can see that a lot of noise is created in the simulation, but with noting the y axis, the
highest acceleration recorded is just 0.0005m/s2 which is almost nonexistent. Also, the
jerk at one of the noisiest parts of the graph is still just 0.015m/s3 which, again, is almost
no vibration.
Figure 12: Average force vs time plot of the twin opposing piston setup. The low
vibration theory is also backed up by the fact that the largest vibration force crated is only
0.0025N.
So the pistons are very well balanced in this setup, but what about the connecting rods?
They also move in opposite directions just like the pistons, so I was curious if they were
self balancing as well.
Figure 13: Average acceleration vs time plot of the twin opposing piston connecting rods.
As predicted, the average acceleration in the vertical direction is very low leading to a
jerk of just 0.009m/s3.
Figure 14: Average force vs time plot of the twin opposing piston connecting rods. Again
this is backed up by the fact that the average shaking force between the two connecting
rods is just 0.001N.
The Napier Deltic experiance
Now that I had found how smooth the twin opposed piston setup was, I decided to turn
my attention to the full engine (only one layer of it that is) to see what the average forces
between all 6 pistons and connecting rods. Unfortunately, the program got a little mad at
me so the graphs did end up being shakier than I was expecting, but I still believe that it
still got some very good data despite the problems.
Figure 15: Full engine assembly in Algoodo.
Figure 16: Average Position vs time of all 6 pistons. Since I could only graph the
positions in the x and y graphs and not just an average overall, the graph looks rather
shaky, but in actuality, all 3 cylinder banks are out of time with each other, so the average
position should move in a circular motion which is exactly what we see here.
Figure 17: Average Velocity vs time of all 6 pistons. Compounding on that, the average
velocity directly reflects the circular motion created by the average position.
Figure 18: Average Acceleration vs time of all 6 pistons. Since the average velocity was
so low, that in turn made for a fairly low acceleration as well giving us a jerk of only
1.026m/s3. That is very low and a rather good sign in terms of suppressing vibrations.
Figure 18: Average Force vs time of all 6 pistons. Since the average acceleration was so
low, the resulting force of vibration is also quite low. Even with my mediocre setup that
probably wasn’t timed perfectly at all, the engine still managed to suppress internal
vibrations till there was only a shaking force of 10N. On an engine of this size, that is
almost nothing.
Again, I was curious about how the connecting rods would end up balancing out in the
engine. So I followed up by analyzing all 6 connecting rods and averaging the values
together to come up with a graph and some data.
Figure 19: Average Acceleration vs time of all 6 connecting rods. As we can see, just like
with the pistons, the average acceleration is very low across all 6 connecting rods leading
to a jerk of just 0.591m/s3.
Figure 20: Average Force vs time of all 6 connecting rods. Again, we can se that the
vibration forces are relatively low in and that even with my bad timing setup, all six
connecting rods to a pretty good job of canceling themselves out.
Conclusion
In conclusion I discovered that not only was the Napier Deltic a very powerful and
complex engine, but was also very well thought out in terms of design. This triple
crankshaft engine cancels out early all internal forces with just geometry alone. That
means that as long as all the pistons weigh the same, and all the connecting rods weigh
the same (which they all should anyways) then the engine needs no other kind of
counterbalance to balance it out. It will automatically be self balancing no matter how big
or small it is making it an extremely smooth running design.
Analysis of Theo Jansen Mechanism
ME 481 – Final Project
Kevin Wright
5/6/2015
Abstract
The Theo Jansen mechanism is a leg mechanism that can be utilized in walking robots. It was
analyzed using a 2D modeling package called Working Model in an effort to improve upon the original
design by increasing the height and length of its step path. The impact of changing individual links was
observed and used to determine which combinations of lengths could be used to alter the step path.
Three alternative designs were created and their step paths analyzed. The energy cost of these designs
was determined by analyzing the torque curves against that of the original.
Introduction
The Jansen mechanism was developed by kinetic artist Theo Jansen. These legs were used to
propel wind power walking sculptures called “Strandbeests”. The dimensions for the linkages were
derived by an evolutionary computer algorithm. 1500 sets of lengths were randomly generated and the
resulting step path was compared against an idealized foot path. The 100 sets that best matched the
ideal step path were used to generate 1500 more sets of lengths. This process was repeated until the
lengths eventually converged to the values listed in Table 1. [1]
The Jansen mechanism was modeled in the “Working Model” software for the analysis. The
initial dimensions of the mechanism came from Jansen’s original work. An image of the model with the
links and joints labeled is shown in Figure 1. The mechanism consists of two 4-bar mechanisms that are
connected to the same crank shaft and fixed at points A and E. The motor at A drives the mechanism
counterclockwise, causing the foot to also move in a counterclockwise fashion
Link
2
3
4
5
6
7
8
9
10
11
12
A-E (x,y)
Orig Length (in)
15
50
41.5
55.8
40.1
39.4
39.3
36.7
65.7
49
61.9
(38.0, 7.8)
1
Figure 1 and Table 1. Drawing of Original Janesn Mechanism and List of Link Lengths
Methods
The step profile was determined by tracking the position foot of the mechanism (Point G). The
profile is characterized by the length and the height of the step. The length of the step was calculated
by measuring the difference between the minimum and maximum x positions where the step was less
than 0.5 inch from the bottom of the step. The height of the step was calculated by finding the
difference between the minimum and maximum y values. For the original design, the step height is
22.46 inches and the step length is 49.84 inches.
Initially each link was individually shortened and lengthened to observe its impact on the step
profile. These observations were used to make judgements on which links to adjust in order to improve
the step profile. The object was to create a mechanism that had a higher and longer step while
maintaining the levelness of the profile. In addition, the torque output of the motor was measured for
each mechanism configuration and plotted as a function of crank angle.
Results and Discussion
Figure 2 shows the impact of moving the fixed point E away from the motor at point A. Moving
point E vertically causes the angle of the step to tilt. The step height also increases when the distance
between points A and E decrease. When point E moves horizontally away from point A, then entire step
collapses. Point E can’t be moved any closer horizontally without preventing the mechanism from
completing a full rotation.
Figure 2. Step Profile Changes by Adjusting Location of point E
Figure 3 shows how the step profile changes when Link 2 is shortened or lengthened. The blue
plot represents when the link is lengthened while the red plot is when the link is shortened. This
convention is maintained for the remaining step profiles in Figures 3-6. The step length increases when
Link 2 is lengthened and the step length shrinks when the link is shortened. The step height becomes
very high with the longer link.
2
Figure 3. Step Profile Changes by Adjusting Link 2
Figure 4 shows the changes in step profile from altering the links 3, 4, 8 and 12. These are the
links that are a part of the 4-bars. Increasing the length of Link 3 causes the step height to increase and
the step angle to tilt down. Reducing the length has an opposite effect. Comparing the step profiles of
link 3 and link 4, they have opposite reactions since they are a part of the same internal 4-bar. This
equal and opposite feature is also noticeable in links 8 and 12.
Figure 4. Step Profile Changes by Adjusting Links 3, 4, 8, 12
Figure 5 shows the step profiles links 5, 6, 7, and 9. Link 5 had a similar change to the step
profile as Link 3. The step height increased and the step angle dipped down when the link was
lengthened. When the link was shortened, the step height shrunk and step angle tilted up. Links 7 had
a very similar response to link 5 and Link 9 had an opposite response to link 5. Link 6 appeared to have a
much smaller response than the other links.
3
Figure 5. Step Profile Changes by Adjusting Links 3, 4, 8, 12
Figure 6 shows the step profiles of links 10 and 11, the links connected to the foot. They also
demonstrate a similar and opposite relationship. The step height increased and the step angle dipped
down when link 10 was lengthened and vice versa when it was shortened.
Figure 6. Step Profile Changes by Adjusting Links 10, 11
One key observation while making these profiles is the existence of a boundary condition that
prevents the mechanism from functioning. The step height increases dramatically when the
parallelogram link collapses. The mechanism locks up in this position and will prevent the motion from
being completed. This scenario is illustrated in Figure 7. When optimizing the mechanism, this
boundary condition needed to be avoided.
4
Figure 7. Comparing Original Jansen Model (Left) to model with Link 2 = 16 in (Right)
The First optimization was created by trying to avoid the observed boundry condition. To that
end, Links 8, 10 and 12 were shrunk. The length of link 11 had to be increased to accommodate the
change in step angle. The resulting mechanisim and dimensions can be seen in Figure 8 and Table 2.
The step profile of this design is shown in Figure 9. The step length was 60.7 inches and the step height
was 10.9 inches. This is a 10.8 inch increase in step length and a 11.5 inch decrease in step height as
compared to the original design. The overall horizontal boundries appear to be the same, but the
vertical compression of Opt A step profile leads to the increased step length.
Link
2
3
4
5
6
7
8
9
10
11
12
A-E (x,y)
Orig Length (in)
15
50
41.5
55.8
40.1
39.4
39.3
36.7
65.7
49
61.9
(38.0, 7.8)
Opt A
15
50
41.5
55.8
40.1
39.4
38
36.7
64
50
59
(38.0, 7.8)
Figure 8 and Table 2. Optimization A and Link Dimensions
5
Figure 9. Comparing Step Profile of Opt A with Original Jansen
Optimization B aimed to increase the step length by increasing the crank length (link 2). The
resulting mechanism and dimensions are seen in Figure 10 and Table 3. The step profile is shown in
Figure 11 shows a step length of 63.4 inches and a height of 12.6 inches. The profile appears much
longer than Opt A, but the similar step lengths are caused by ends of the profile being very curved in Opt
B. This removes a significant portion of the curve from being considered as a part of the step length.
Link
2
3
4
5
6
7
8
9
10
11
12
A-E (x,y)
Orig Length (in)
15
50
41.5
55.8
40.1
39.4
39.3
36.7
65.7
49
61.9
(38.0, 7.8)
Opt B
19.5
48
39
58
42
40.5
40.4
42
65.7
49
59
(40, 6)
Figure 10 and Table 3. Optimization B and Link Dimensions
6
Figure 11. Comparing Step Profile of Opt B with Original Jansen
The final optimization aimed to increase the step height of the step profile. The mechanism and
it’s dimensions can be seen in Figure 12 and Table 4. While the profile is slightly higher than the original,
the curve as it reaches the peak of the step has a sharper curve to it. The overall step height is 24.3
inches and the step length is 47.7 inches, as shown in the step profile displayed in Figure 13. A summary
of each design’s step heights and lengths are available for comparison in Table 5.
Link
2
3
4
5
6
7
8
9
10
11
12
A-E (x,y)
Orig Length (in)
15
50
41.5
55.8
40.1
39.4
39.3
36.7
65.7
49
61.9
(38.0, 7.8)
Opt C
17.4
50
38.3
58
42
40.1
40
42
65.7
49
61.5
(40, 6)
Figure 12 and Table 4. Optimization C and Link Dimensions
7
Figure 13. Comparing Step Profile of Opt C with Original Jansen
Design
Original
Opt A
Opt B
Opt C
Step Length (in)
49.8
60.7
63.4
47.7
Step Height (in)
22.4
10.9
12.6
24.3
Table 5. Comparison of Design Step Lengths and Heights
In addition to the step profiles, the motor torque was plotted as a function of crank angle for
each design. Opt A has a lowest peak torque since it has the most compressed step profile with fewest
large turns. Opt B has the highest peak at just less than 0 degrees because of the sharp turn in the far
right portion of its step. Opt C has the highest and sharpest spike in torque due to the rise to the peak
of its profile.
Figure 14. Motor Torque vs. Crank Angle for each Optimization
8
The Jansen Mechanism was also constructed in Solid Works. The model built in the 3D
environment was able to match the profile generated in Working Model. However there was limited
value in pursuing further modeling in Solid Works since the mechanism was entirely 2D.
Figure 15. SolidWorks Model and Step Profile
Conclusion
The Theo Jansen mechanism is a leg mechanism that can be utilized in walking robots. It was
analyzed using a 2D modeling package called “Working Model” in an effort to improve upon the original
design by increasing the height and length of its step path. 3 different optimized alternative designs
were generated by utilizing the observations made by varying individual links. While the different
designs were able to increase step height or length, the improvements came at the cost of increased
torque required to move the foot around a step path with sharper angles.
References
[1]T. Jansen, 'STRANDBEEST', Strandbeest.com, 2015. [Online]. Available: http://www.strandbeest.com.
[Accessed: 06- May- 2015].
[2]D. Giesbrecht, C. Wu and N. Sepehri, 'Design and Optimization of an Eight-Bar Legged Walking
Mechanism Imitating a Kinetic Sculpture, "Wind Beast"', Transactions of the Canadian Society for
Mechanical Engineering, vol. 36, no. 4, pp. 343-355, 2012.
9