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