Open Loop Juggling Machine

Open-loop Juggling Machine

Kevin Christman June 2006

Senior Design Project as required for the degree of Bachelor of Science in Engineering Walla Walla College School of Engineering College Place, Washington

Contents Abstract......................................................................................................................................iv Acknowledgments......................................................................................................................iv Juggling Basics............................................................................................................................1 Juggling Methods........................................................................................................................1 Open/closed loop control.......................................................................................................1 Anthropomorphic..................................................................................................................2 Pingpongomorphic.................................................................................................................2 Pinballomorphic.....................................................................................................................2 Snapshot of Juggling Robots.....................................................................................................2 Motivation for Juggling Robots.............................................................................................2 First Juggling Machine..........................................................................................................3 First Programmable Juggling Robot.....................................................................................3 Exploring Non-Traditional Programming............................................................................3 My Design...................................................................................................................................4 Project Summary....................................................................................................................4 Kinematics..............................................................................................................................5 Spring Design.........................................................................................................................6 Cylinder Design......................................................................................................................7 Ball Design..............................................................................................................................7 Shock Absorber......................................................................................................................7 Cantilever Design...................................................................................................................9 Programmable Logic Controller (PLC) Input/Output........................................................10 Testing & Conclusion................................................................................................................10 Launch Issue.........................................................................................................................10 Landing Repeatability Issue.................................................................................................11 Final Thoughts......................................................................................................................12 Appendix A—Part Specifications .............................................................................................13 Appendix B—Pictures & Graphs...............................................................................................14 Appendix C—Python Code........................................................................................................16 1. Juggle.py...........................................................................................................................16 2. JuggleAnalysis.py.............................................................................................................18 Appendix D—PLC Code...........................................................................................................20 Bibliography..............................................................................................................................21

ii

Index of Tables Table 1: Result of deviation in launch velocity (code in Appendix C-2).......................................1 Table 2: Limits used for Spring Design.........................................................................................5 Table 3: Limits for safe operation of Shock Absorber..................................................................8 Table 4: Issues encountered during testing.................................................................................10 Table 5: Spring Calculation (see equations (6) and (7)) .............................................................13 Table 6: Ball Mass.........................................................................................................................13 Table 7: Acquired off-the-shelf parts (not including PLC, sensors, and air valves which I borrowed from the manufacturing lab)........................................................................................13

Index of Figures Figure 1: 3-Ball Cascade Pattern....................................................................................................1 Figure 2: Launch Apparatus...........................................................................................................5 Figure 3: In Energy State 1, the launcher is at its lowest position and ready for launch............6 Figure 4: In Energy State 2, the launcher is moving at its fastest speed, the instant before being slowed to a stop.....................................................................................................................6 Figure 5: Stress analysis of cantilever using Pro/Engineer...........................................................9 Figure 6: Originally, the cylinder rod interfaced directly with the carriage................................11 Figure 7: The solution: The gripper was fixed to the cylinder rod (not seen because retracted) ........................................................................................................................................................11 Figure 8: Determining launch speeds and angles (code in App. C)............................................14 Figure 9: Determining parameters that did not result in ball collisions (code in App. C).........14 Figure 10: Final Design (not shown: funnel, catch/release mechanism, and sensors)..............14 Figure 11: Final Product................................................................................................................15 Figure 12: Ready for launch..........................................................................................................15

iii

ABSTRACT Humans can learn basic juggling in hours or days. Making a machine or robot that will juggle, however, takes more effort. While others have achieved robotic juggling using anthropomorphic robot linkages and complicated control systems, my focus is to achieve the essence of juggling as easily as possible. The aim of my project is to design, model, and build a machine that juggles a modified three-ball cascade pattern. The one degree-of-freedom balllauncher is powered by an extension spring and air cylinder, and guided by a linear bearing. The machine has an open-loop controller that consists of a PLC (Programmable Logic Controller) and several sensors. Result: The machine launches and catches balls. Three-ball juggling was not obtained, however, because launches done in rapid succession suffer repeatability issues.

ACKNOWLEDGMENTS This project might still be on the drawing board if it weren't for the helpfulness and generosity of certain people: THK America, especially James Lee of the Western Regional Sales Office, and Rich Lundin, manager of the Pacific Northwest district, were generous in their support. THK America donated the high-quality linear motion guides for the project. I thank Prof. Ralph Stirling, Projects Engineer at WWC and my advisor. Prof. Stirling was instrumental in guiding me to certain manufacturers and he also gave me free license to use equipment and materials in the robotics and manufacturing labs. This project would have suffered much without the advice of my friend Philip Schmehl, a 2005 WWC engineering graduate. Philip was always willing to talk about the project and was especially helpful in brainstorming of the actuator design. I thank Ben Altrogge for his help— especially during testing. I also thank all of my friends and family who were always eager to hear the latest update, or would drop by the lab to see the progress (or lack thereof). I thank Technical Support Services at WWC, specifically Jim Forsyth (manager) and Derek Lee (machinist). Derek skillfully made several parts with tight tolerances. Also supportive of my project was the Fastenal store in Walla Walla, Washington. iv

JUGGLING BASICS While many people think that the simplest way to juggle is by throwing balls in a circular pattern (known as a shower), it is easier to throw balls alternately from each hand into the other (known as a cascade). To cascade, one throws ball #1 from the right hand. When that ball climaxes at its vertex, ball #2 is thrown from the left hand just underneath ball #1. When ball #2 climaxes, throw ball #3 from the right hand. Catching the balls at the appropriate times, of course, is vital.

1

2

3

The slower balls are thrown, the less time Figure 1: 3-Ball Cascade Pattern between throws. Throwing faster balls, however, creates other Targeted Speed Angle Landing problems: launch errors can cause launch velocity (m/s) (deg.) location range balls to land significantly away from (cm) their intended target. In fact, Table 1 ± 0.1 ±0 7 shows the large variations in landing 3.5 m/s @ 15° locations due to small errors in the ±0 ±1 8 launch. As evident, a person or robot ± 0.1 ±0 13 trying to juggle should be able to 6.5 m/s @ 15° launch balls with a high degree of ±0 ±1 26 accuracy, unless one allows large distances between the balls and is a Table 1: Result of deviation in launch velocity (code very good catcher. in Appendix C-2)

JUGGLING METHODS Open/closed loop control The majority of juggling robots have closed-loop control. In other words, they monitor the flying balls and attempt to correct errors. Humans also juggle using closed-loop control by sensing with eyes and hands. Very skilled jugglers are able to juggle while blindfolded by an acute sense of touch and hand manipulation. When humans juggle, the patterns are “...intrinsically variable: however solid a run, no two throws and no two catches are exactly the same” (Beek 1995, 95). Although trying to be as consistent as possible, jugglers are always compromising and changing their throws slightly to avoid ball collisions due to introduced errors. Unlike juggling done by humans and most robots, my project uses an open-loop controller making it blind to the position of the balls while in flight. Since there is no ball-tracking and actuators to adjust for differing ball trajectories, it is crucial that balls be launched repeatably. The key is for each launcher to launch a ball perfectly into the opposing target, and then repeat that same launch again and again. 1

Anthropomorphic Many visualize juggling robots as always having anthropomorphic manipulators—these seem the most natural and in the true spirit of juggling. Anthropomorphic manipulators consist of at least two links that have rotational joints and some kind of hand or ball receptacle at the end. To launch the ball, the joints are moved in such a way to give a ball its correct initial velocity vector when it is released. Catching is throwing in reverse: the hand meets with the ball with a matching velocity and then, over a small distance, the ball is brought to a stop (Donner 1986, 251-252). A major difficulty with using anthropomorphic manipulators for juggling is that most are designed for precision position control and not velocity control (Donner 1986, 251). Since it is difficult to precisely control the velocity of an anthropomorphic manipulator, it follows why most research with this type of juggler is closed-loop. Pingpongomorphic Another approach is to use paddles to strike the ball in the desired direction. With this system, catching and throwing operations are combined. Close-loop control is usually necessary here, in that the incoming ball's velocity vector must be known in order to calculate the angle of the paddle at impact (Donner 1986, 252). Also note that this method yields a non-conventional form of juggling because there is no “dead-time” between catching and throwing. Pinballomorphic The goal of this type of launcher is to transfer momentum from a striker to the ball. An advantage here is that the actual launch is a one degree-of-freedom operation (Donner 1986, 252). If there is the luxury of another d.o.f., it will likely only be actuated between launches and will not require precise velocity control. My particular project could be classed as a variation of the described pinballomorphic manipulator. However, instead of transferring momentum to the ball by striking, a cup is brought to the desired launch speed and then slowed down, allowing the ball to freely continue.

SNAPSHOT OF JUGGLING ROBOTS Motivation for Juggling Robots While at first glance juggling robots may seem a trivial pursuit, they do have interesting mechanical and control parallels. From a mechanical and control point of view, juggling and legged locomotion are very similar (Buehler 1990, 3). In fact, walking/hopping can be described as a type of juggling. Imagine a robot attempting to launch an immovable ball in a particular direction. Since the ball cannot be moved, then the entire juggling apparatus is moved in the opposite direction. That is the essence of walking: consecutively launching the human body off of a massive ball— the earth. Juggling and walking merely differ with the mass of their respective balls; hence, conservation of momentum dictates which object significantly moves (Rizzi 1994, 8). 2

Juggling, like walking, can be classified as a hard real-time problem because of the constant deadlines that must be met (catching and throwing) to continue juggling. At a given juggling height, one cannot juggle arbitrarily slow or fast. For closed-loop controllers, this limits the amount of time that ball-position data is taken, processed, and feedback given to the actuators. Donner and Jameson note that with hard real-time problems “getting the right answer too late is indistinguishable from getting the wrong answer” (1986, 249). First Juggling Machine Claude Shannon, the mastermind of digital circuit design, is also considered the pioneer of juggling machines (Beek and Lewbel 1995, 97). His machine did not launch balls with a high velocity; rather, it dropped the balls onto a surface—known as bounce juggling. Bounce juggling has several useful properties: i.) during the catch the ball is near its vertex and therefore traveling at its slowest, and ii.) no high-speed launch is required, because the balls only need to be raised a few inches before they fall (Kalvan 1996). The “hands” on Shannon's machine were glorified levers. When a ball landed in one hand, that hand would go down and the opposite hand would go up and launch the opposing ball. Shannon's juggling machine required no computer; its passive design allowed it to toss/catch balls in an intrinsic rocking motion. First Programmable Juggling Robot The first programmable robot to juggle (in two dimensions) was probably created by Martin Buehler at Yale. It consisted of a near-vertical frictionless sliding board that constrained the two pucks to a plane. While humanoid juggling requires multiple degrees of freedom, this robot was able to juggle pingpongomorphically with only one degree of freedom: a single motor with a cushioned bar attached in a see-saw fashion. Unlike Shannon's machine, this robot had closed-loop control and tracked the position of the pucks. Instead of using a video system with image analysis, the inclined plane was fitted with a sensing grid to detect an electromagnetic field emitted from the pucks. (Buehler 1990, 1-2 & 32-33) Exploring Non-Traditional Programming While traditional programming has its place, robots that learn by experience are a promising field. Aboaf, Drucker, and Atkeson researched this area by using a robot that attempted to juggle one ball by bouncing it up vertically with a large paddle. The robot was composed of a multitude of models used in succession: • forward ballistics to estimate the ball's landing, • inverse ballistics to determine a desired outgoing trajectory to get the ball back to the goal (usually the center of the paddle), • restitution model to determine the angle and velocity that the paddle should hit the ball, • kinematics model to relate the desired angle and velocity to joint angles and velocities of the robotic arm, • trajectory model for the motion of the robotic joints,

3

and finally a dynamics model to relate the desired joint trajectory into motor torques (Aboaf et al. 1989, 1291-1292). Due to errors in each model, the above-mentioned robot could only juggle, on average, two consecutive hits before the ball would miss the paddle. Instead of tedious calibration of each model, these researchers used task-level learning to get the robot to juggle. By experiencing successes and failures, it “learned” to juggle with less mistakes by adjusting its juggling goals. In basketball terms, a player that consistently overshoots when throwing from a certain location will try to undershoot to get the ball into the basket. For the robot, the ultimate goal is to land the ball at the center of the paddle, in that this minimizes failure. Instead of always aiming for the center of the paddle, the robot would dynamically adjust its goal to account for known errors. For example, when the ball was projected to land at a certain place that, from past experience did not accurately launch the ball back to the center, the robot would statistically adjust for this error by changing its goal to a location other than the center. In this way the ball would more likely land in the center. By learning to correct its performance errors, the robot increased its juggling capability from an average of two to an average of 21 consecutive hits (Aboaf et al. 1989, 1291-1295). •

While learning from experience is impressive, some research has moved even further away from traditional programming by making robots that learn from demonstration. For example, after watching several human demonstrations of the desired task (e.g. juggling, polebalancing, dancing), the robot attempts to do the same. “The robot can either mimic the motion of the demonstrator, or learn how the demonstrator acts, reacts, and handles errors in many situations (a policy)” (Atkeson and Schaal, 1). For example, the Dynamic Brain is one such robot that learns by demonstration. It accomplishes tasks by attempting to imitate the examples that it is fed. After showing the Dynamic Brain a person folk-dancing or juggling, it attempts to imitate the task. While the first few tries might be unsuccessful, the Dynamic Brain learns from each failure, and eventually is dancing or juggling (Atkeson et al. 2000, 52). Unlike other robotic jugglers, my particular project is not designed to be a test bed for research into robot control. Due to the limited scope of this senior project, my purpose has been to capture the essence of machine juggling via more feasible methods.

MY DESIGN Project Summary In my project proposal I outlined the following objectives: Design and build a machine1 that “juggles” three balls • Portable • Cost < $500 This project does not attempt to reproduce the form of a human juggler. In other words, this would not be a humanoid robot with moving arms. Neither will there be a ball-tracking system and a corresponding feedback & control system. As evident, a true robotic juggler would require an intricate combination of these complicated systems. •

1 I do not consider this machine to be a robot. I might think otherwise if it had mechanical arm linkages or a closed-loop controller that tracked balls through the air.

4

The key to my design is: • •

fix the launching and catching locations repeatedly launch the balls in the same way

The launch apparatus is composed of the following (see Figure 2): • Linear motion guide • Spring • Cylinder • Carriage = Cantilever + Interface angle • Ball and Cup • Shock absorber

Figure 2: Launch Apparatus

Kinematics The ball's position for any time t (since launch) is given as: x=v 0 t cos x 0

(1)

1 y=v 0 t sin  g t 2 y 0 . 2 By setting

(2)

dy =0 and solving for t, the time to vertex is dt t vertex =

−v 0 sin  . g

(3)

Since both launchers are at the same height, the air time for each ball is t air =2⋅t vertex .

(4)

I designed the machine according to upper and lower bound specifications. Faster launch speeds cause more concern with linear bearings, stopping the launcher, and stress on the parts. Slower launch speeds are also problematic due to ball collisions and a decrease in time between launches. Table 2 outlines lower and upper limits used for the design of the spring and cylinder. Launch speed (m/s) @15° ⊥

Vertex height (m) Time to vertex (sec.)

Air time (sec.)

Minimum

3.5

≈ 0.6

≈ 0.35

≈ 0.7

Maximum

6.5

≈ 2.0

≈ 0.64

≈ 1.3

Table 2: Limits used for Spring Design 5

Spring Design

Figure 3: In Energy State 1, the launcher is at its lowest position and ready for launch.

Figure 4: In Energy State 2, the launcher is moving at its fastest speed, the instant before being slowed to a stop.

I designed the spring using the conservation of energy principle. The spring was designed to operate within the range of speeds shown in Table 2. Figures 3 and 4 show the energy states used to determine the potential and kinetic energy balance, which is PE 1 spring = 1 k  x init x travel 2 2

PE 2 spring PE 2 grav. KE 2 1 1 = k  x 2init mg  x travel  mv 2 . 2 2

(5)

Solving for the spring constant gives

k=

1 mg  x travel  mv 2 2 1 2 2  xinit  x travel  − xinit   2





1 2 mg  x travel  mv 2 2 = , 2  x travel 2 xtravel⋅ x init

(6)

while solving for the prestretch of the spring gives  x init =

mg mv2 1  −  xtravel . k 2 k  x travel 2

(7)

To calculate the spring constant k, use (6) and assume minimum launch speed with no prestretch on the spring (  x init =0 ). Once the spring constant is determined, the prestretch needed for maximum launch speed is found using (7). The result is that the spring will be

6

“weak” enough to launch the ball at the lower-bound speed, but it will also be able to launch the ball at the upper-bound speed by giving the spring a prestretch  x init . Cylinder Design In the spring design calculations, the mass of the cylinder rod was accounted for in the energy states relations. However, the frictional forces between the rod/piston and cylinder, while having no place in energy-states relations, certainly affects the dynamics of the situation. Since I could not account for the friction (at least from the energy-states paradigm), I simply tried to make it negligible by using very-low friction Airpel cylinders. As described later, the necessity of very-low friction cylinders was later removed. When the spring is extended to its maximum design limit, the spring pulls with F spring = =

k  x init  x travelF init 368N/m 0.0944m 0.088m 13 N=80 N .

(8)

At 400 kPa (58 psi), the cylinder is able to pull F cylinder = PA 2 =  0.4 MPa  421 mm =168 N ,

(9)

which is ample force to hold the spring. Ball Design While most balls bounce by design, for this project bounce is to be minimized for two reasons: 1. Balls should settle quickly after being caught because time duration between catch and launch may be as small as 0.35 seconds. In any case, the ball must not bounce out of the launching apparatus! 2. Balls should not compress during launch (due to rapid acceleration). Compression would result in the ball recoiling, which might vary from launch to launch. While certain solid-foam balls have very little bounce, their mass to surface area ratio is low and suggests greater sensitivity to air friction. From a qualitative perspective, footbag (hacky sack) balls were selected because of their minimal bounce and ideal mass. Shock Absorber The carriage (the moving apparatus) undergoes a large acceleration imparted from the spring as it travels up the linear guide. The carriage experiences an even greater acceleration as it is brought to a complete stop. Assuming that frictional forces between the cup and ball are negligible, the ball will start to leave the cup when the carriage begins to slow down.2 Some think that a sudden stop is necessary to snap the ball into the air, but this is not the case.

2 Incidentally, balls fit the cup so snugly that air holes had to be drilled near the bottom of the cup to relieve the partial vacuum and allow the balls to leave freely.

7

In any case, the carriage develops kinetic energy that must be safely dissipated for it to stop: 1 2 KE= m v . 2

(10)

Discounting the mass of the ball, the maximum kinetic energy developed by the carriage is 1 2 KE= 0.2 kg 6.5 m/s =4.225 Joules . 2

(11)

The acquired shock absorbers have an energy capacity of 8.5 Joules. However, the factor of safety is less than two because the spring continues to act as a driving force and is not accounted for in (10). This means that the shock absorber experiences a full displacement even for the smallest of impacts. The maximum rated frequency of the shock absorber is 56 cycles/min., resulting in a minimum air time for each ball of t air , min =

60 sec./min. =1.07sec. 56 cycles/min.

(12)

Combining (3), (4), and (12) and solving for initial velocity (at =90−15 ) yields the minimum launch speed that the shock absorber imposes: v min=

−g t air , min . 2 sin 

(13)

The maximum launch speed allowed by the shock absorber is found by rearranging (10): v max=



2⋅KE . m

(14)

Table 3 shows the minimum and maximum design characteristics imposed by the acquired shock absorber. Launch speed (m/s) @15° ⊥

Vertex height (m) Time to vertex (sec.)

Air time (sec.)

Minimum

5.1

≈ 1.2

≈ 0.50

≈ 1.0

Maximum

9.2

≈ 4.0

≈ 0.91

≈ 1.8

Table 3: Limits for safe operation of Shock Absorber

8

Cantilever Design The cantilever receives its greatest load when the ball lands in the cup. As noted earlier, the cantilever beam should have minimal deflection to avoid the ball from springing out. The maximum deflection of a cantilever beam with an intermediate point load F is 2

y max =

Fa  a−3⋅l  , 6E I

(15)

where l is the length of the beam and a is the distance from load point to the beam's fixed point (Shigley et al. 2004, App. A-9-2). Using Hooke's Law (15) can be rewritten as the cantilever's spring rate k cantilever =

F 6E I = 2 . y max a a−3⋅l 

(16)

Assuming a massless beam, Shigley et al. show that the the maximum deflection due to the impact of a moving mass on the cantilever (2004, 228-229) is y max=

v



k cantilever m

.

(17)

Combining equations (16, 17) yield the maximum deflection of the cantilever as a function of velocity: y max =a v



m a−3⋅l . 6E I

Figure 5: Stress analysis of cantilever using Pro/Engineer

9

(18)

Programmable Logic Controller (PLC) Input/Output I used three sensors for each launcher. Two Hall-effect sensors determine when the recharge cylinder is fully retracted or extended. The third was a through-beam optical sensor to primarily determine if the ball is in the cup. In the original design, each launcher had one actuator: the recharge cylinder that stretched the spring. Launch location, angle, and speed were manually adjusted whenever necessary. I later added, however, another set of actuators to solve the problem with the air valves opening too slowly, as described next.

TESTING & CONCLUSION After manufacturing the machine, several issues were encountered and are summarized in Table 4. Symptom

Cause

Solution

Status

No computercontrolled launch

Air valve not fast enough

Catch/release mechanism for launch

Implemented

Baseboard movement

Fix baseboards together or to the floor

Mostly solved with heavy weights

Excessive vibration of carriage and T-slot

Shorten cup and stiffen T-slot

Not implemented

Landing repeatability

Excessive vibration of spring

i. Reduce mass of spring ii. Dampen spring with absorber mechanism and/or time between launches

Not implemented

Table 4: Issues encountered during testing Launch Issue I found a disturbing discrepancy during initial testing: When I manually pulled down the carriage and released my grip, the ball would launch. When the PLC attempted a ball launch, however, the ball would not gain enough speed to launch. Initially I thought that the tubing and air valves were too small, therefore restricting the dissipating air. After further testing, I traced the problem to the valves that supplied air to the cylinders: The air valves were not opening fast enough. Before launch, the cylinder rod is retracted in order to extend the spring. At launch time, the pressurized air in the cylinder needed to quickly evacuate to allow the carriage to go up. The air valve takes a finite amount of time to open, and air was greatly restricted as it tried to flow though the opening valve. Simultaneously, the spring began to move the carriage up but was impeded by the “slowly” escaping air. While all of this happens in a few milliseconds, it is enough to greatly reduce the energy imparted from the spring to the carriage. 10

The air valve problem was solved by using a gripper actuator to act as a catch/release mechanism. This gripper makes a clean and instantaneous release when the PLC calls for a launch. While the gripper holds onto the bolt, the carriage cannot begin to slide up until the gripper has fully disengaged the bolt. See Figure 7 (without the gripper) and Figure 6 (with the gripper).

Figure 7: The solution: The gripper was fixed to the cylinder rod (not seen because retracted)

Figure 6: Originally, the cylinder rod interfaced directly with the carriage.

Landing Repeatability Issue A major design focus was ensuring a repeatable launch in order to reliably deliver the balls to the opposing funnel, as noted earlier (see p. 1). The collective landing deviations of the balls should not be larger than the funnel, which has a diameter of 20 cm. Tests of the machine, however, showed larger landing deviations than expected. One culprit for the landing deviations was the “walking” of the baseboards due to recoil. While desirable for locomotion projects, this feature was not desired for this project. The problem was mostly solved by placing heavy weights on the baseboards. Fixing the baseboards together or onto the floor are other possible solutions. More repeatability issues were observed by analyzing the launch. Since the travel up the linear bearing occurs in less than 20 milliseconds, a high-speed camera was necessary to 11

record the motion. Taking 250 frames-per-second, the camera shows the carriage assembly vibrating excessively during launch due to the quick slow-down. Unfortunately, the momentum developed in the spring and cup causes the carriage and cup to oscillate. Although difficult to confirm, this vibration could possibly modify the ball's velocity or, give it a slight spin as it leaves the cup. Even if the standing waves developed in the spring have little effect on the current launch, they don't dissipate quickly. They are likely to be present during the next launch. Therefore, the state of the spring at each launch varies. Without conclusive evidence, I am led to believe that these varying spring states are the primary source of the launch variations. Indeed, when more time is given for the spring's vibrations to dissipate, the launches are much more consistent. Final Thoughts This project encompassed many areas. The following is a brief summary of this project's work. • • • • • • • •

Kinematics/juggling simulation using Python (code in Appendix C) Actuator design Machine design and solid-modeling using Pro/Engineer Stress analysis on various parts Manufacturing Pneumatic plumbing, PLC wiring and programming (code in Appendix D) Testing Written and oral report

Although the machine launches and catches balls, the original goal of 3-ball juggling was not attained due to the unresolved repeatability issue. As noted above, adding time between launches allowed the spring to settle enough for more consistent launches. So while 3-ball or even 2-ball juggling was not successful, 1-ball juggling was. Since repeatability was a primary design factor, my design attempted to minimize deformation and vibrations. I did not, however, do any sort of vibrational analysis for the design. For a next-generation machine juggler, it would be wise to reconsider using a spring as part of the launching mechanism. Besides the vibrating spring, the rest of the components of the machine performed well.

12

APPENDIX A—PART SPECIFICATIONS Note that my solution to the air valve issue no longer required the cylinder rod to take part in the actual launch. With that Mass of components change, the machine no longer requires that the air cylinders mass_ball (kg) be “friction-free.” In fact, the spring constant was now much mass_slideblock (kg) mass_rod (kg) larger than it needed to be. As shown in Table 5, the spring was designed assuming the cylinder rod would take part in the mass_cantilever (kg) mass_angle (kg) launch. mass_misc (kg) mass_total (kg)

The mass of the balls also vary slightly (Table 6). Ball Green Red Blue

0.0500 0.0160 0.0729 0.0260 0.0180 0.0332 0.2161

Travel on linear bearing

Mass (grams) 49.9 52.4 48.6

dx (m)

0.088

Spring Constant k (N/m) k (lb/in)

Table 6: Ball Mass

390.0 2.23

Table 5: Spring Calculation (see equations (6) and (7))

Part

Part #

Linear Motion guide Airpel Anti-Stiction cylinder Hacky Sack Balls Extension Spring T-Slot Shock absorber Pneumatic Gripper (LH) Pneumatic Gripper (RH)

1SRS9M C1 +135N E 24 D 5.0 UM 844 80987 Extrusion 1020x47.5” 3740K12 MHZ2-20D MHZ2-16D

Qty 2 2 3 2 2 2 1 1

Cost $0.00 $96.00 $3.50 $18.23 $11.40 $33.56 $0.00 $0.00

Shipping&Tax $8.94 $4.00 $6.93 $14.70 $4.50

Total

Total $0.00 $200.94 $14.50 $43.39 $37.50 $71.62 $0.00 $0.00 $367.95

Company THK America Airpot World Footbag Assoc. Century Spring Corp. eBay 8020 Garage Sale McMaster-Carr SMC SMC

Table 7: Acquired off-the-shelf parts (not including PLC, sensors, and air valves which I borrowed from the manufacturing lab)

13

APPENDIX B—PICTURES & GRAPHS

Figure 8: Determining launch speeds and angles (code in App. C)

Figure 9: Determining parameters that did not result in ball collisions (code in App. C)

(b.)

(a.)

Figure 10: Final Design (not shown: funnel, catch/release mechanism, and sensors)

14

(a.)

(b.)

Figure 11: Final Product

Figure 12: Ready for launch 15

APPENDIX C—PYTHON CODE Juggle.py contains the Ball and Juggle objects, which are used by JuggleAnalysis.py to

create simulations. The Python code requires NumPy (for arrays) and matplotlib (for plotting). 1. Juggle.py #Juggle.py, Kevin Christman, April 2006 from numpy import * class Ball(object): g = 9.81 def init_conditions(self, speed, angle, x=0, y=0): # Launch parameters self.exit_velocity = speed self.exit_angle = (90 + angle)*pi/180 self.x = x self.y = y def time2vertex(self): """Time when ball is at max height (Ball.y_velocity = 0).""" return self.exit_velocity*sin(self.exit_angle)/Ball.g def time2ground(self): """Time when ball reaches back to ground, where ground has the same y value as the launch's""" A = -.5*Ball.g B = self.exit_velocity*sin(self.exit_angle) C = self.y t1 = (-B + math.sqrt(B**2 - 4*A*C))/(2*A) t2 = (-B - math.sqrt(B**2 - 4*A*C))/(2*A) return max(t1,t2) def position(self, ctime=0): cx = self.exit_velocity*cos(self.exit_angle)*ctime + self.x cy = self.exit_velocity*sin(self.exit_angle)*ctime - (Ball.g*ctime**2)/2 + self.y return (cx, cy) def velocity(self, ctime): xdot = self.exit_velocity*cos(self.exit_angle) ydot = self.exit_velocity*sin(self.exit_angle) - Ball.g*self.ctime cvelocity = math.sqrt(xdot**2 + ydot**2) return cvelocity class Juggle(object): def __init__(self, step=0.01, ball_diam=0.06): self.step = step # The length of each time interval self.diameter = ball_diam # This assumes that all balls have same diam. self.b = [] # b is a list that holds the multiple Ball objects for easy access self.qty_balls = 0 # Number of balls is initially zero def addBall(self, speed, angle, x='Default'): """Add a new ball to the list of balls to be juggled.""" self.qty_balls += 1 # If sign of angle is the same as the 1st ball's, then (for x) it uses the 1st ball's # starting position. Otherwise, it uses the landing spot of the 1st ball as its starting pos. if x == 'Default': if self.qty_balls == 1: self.firstangle = angle self.firstx = 0 x_init = 0

16

elif sign(angle) != sign(self.firstangle): x_init, dummy = self.b[0].position(self.b[0].time2ground()) else: x_init = self.firstx else: if self.qty_balls ==1: self.firstangle = angle self.firstx = x x_init = x self.b.append(Ball()) # Add another Ball to the list self.b[-1].init_conditions(speed=speed, angle=angle, x=x_init)

#x coord. of where 2nd #launcher should be

#Put in the new parameters

def calcTraj(self): """Calculate the trajectories of the balls. A ball is thrown when the previous climaxes.""" step = self.step self.totaltime = 0 # the totaltime of balls in the air for dummy in self.b: self.totaltime += dummy.time2vertex() self.totaltime += self.b[-1].time2vertex() #add a bit more time for last ball num_steps = int(round(self.totaltime/step)) + 1 self.x = zeros((self.qty_balls,num_steps),float) #stores x coords. for all balls self.y = zeros((self.qty_balls,num_steps),float) ctime = zeros((self.qty_balls,1),float) #(currenttime) Time since launch for each ball gtime = 0 #(global time) Time since 1st ball launched #arrays

# This loop needs to be optimized. probably either using numpy's implicit loops or sending for i in range(num_steps): for j in range(len(self.b)): if j == 0: walla = 0 else: walla = walla + self.b[j-1].time2vertex()

#next ball is launched when gtime = #walla if gtime >= walla and ctime[j] <= self.b[j].time2ground(): ctime[j] = ctime[j] + step self.x[j,i], self.y[j,i] = self.b[j].position(ctime[j]) gtime = gtime + step

def plotTraj(self): """Plot the trajectories of the balls. (calcTraj must be called first)""" import pylab pylab.figure(1) pylab.hold(True) # Plot the x,y coords. for each ball's flight for j,k in zip(self.x,self.y): pylab.plot(j[:],k[:]) pylab.xlabel('Meters') pylab.ylabel('Meters') pylab.show() def collisionAnalysis(self,return_mins=False,plot=True): """Return the distances between balls. Set return_mins option for minimums only.""" import pylab # x,y distance formula distance = math.sqrt((self.x[1:] - self.x[:-1])**2 + (self.y[1:] - self.y[:-1])**2) distance = distance - self.diameter #make distance surface-to-surface and not center-to#center min_distance = array([min(d) for d in distance]) #an array with the minimum of each row #print "Minimum distance between balls (in meters):" #print min_distance

17

if plot: gtime = linspace(0,self.totaltime,size(self.x,1)) pylab.figure(2) for j in distance: pylab.plot(gtime, j) pylab.xlabel('Time (seconds)') pylab.ylabel('Distance (meters)') pylab.title('Distance between balls') pylab.show() if return_mins: return min_distance else: return distance

2. JuggleAnalysis.py # JuggleAnalysis.py has some design/analysis tools, Kevin Christman, April 2006 from Juggle import * from numpy import * def reliability(): """Find the change in landing locations due to launching speed/angle variations.""" speed = 3.5 #desired speed s_var = 0 #variation in speed (due to inconsistency in machine) angle = 15 #desired angle a_var = 2 #variation in angle steps = 20 #num of steps speed_array = linspace(speed-s_var, speed+s_var, steps) angle_array = linspace(angle-a_var, angle+a_var, steps) landings = zeros((int(steps**2)),float) #create array of the landing locations k = 0 for i in range(steps): for j in range(steps): b = Ball() b.init_conditions(speed=speed_array[i],angle=angle_array[j]) landings[k], dummy = b.position(b.time2ground()) del b #because there is no 'change_conditions' function in Ball() k += 1 #print landings print "Max Min Diff" print max(landings),min(landings),(max(landings)-min(landings)) def optimalLaunch(): """Find optimal launching parameters (ie no collisions, hit target,etc).""" # Limits for launching angles/speeds for left launcher angle_1 = -40 angle_2 = -10 angle_step = 1 speed_1 = 2 speed_2 = 6 speed_step = 1 # Launching angle/speed for right launcher. r_angle = 25 r_speed = 4.5 max_size = (angle_1-angle_2)*(speed_1-speed_2)/(angle_step*speed_step) print max_size good_param = zeros((3,int(max_size)),float) #this will hold good launching params. m=0 # arbitrary large numbers to start the cycle. If a smaller value comes along, then it replaces. closest_landing = 10.0 #holds the current smallest distance to where it should have landed closest_flight = 10.0 #hold the current smallest distance to where the balls will not,but #almost touch

18

for c_angle in arange(angle_1,angle_2,angle_step): for c_speed in arange(speed_1,speed_2,speed_step): j = Juggle() j.addBall(speed=r_speed,angle=r_angle) #using params. from right launcher j.addBall(speed=c_speed,angle=c_angle) #trying the current angles of this cycle j.addBall(speed=r_speed,angle=r_angle) #identical because same launcher as 1st ball j.calcTraj() #this needs to be called before collisionAnalysis() mins = j.collisionAnalysis(return_mins=True,plot=False) #an array with the min's for each #ball's flight if alltrue(greater(mins,0)): #if no collisions landing2 = j.x[1,-1] #landing location for 2nd ball if abs(landing2) < abs(closest_landing) and sum(mins) < closest_flight: closest_landing = landing2 closest_flight = sum(mins) best_speed = c_speed best_angle = c_angle print "Got a winner" #print c_speed,c_angle,landing2 good_param[0,m] = c_speed good_param[1,m] = c_angle good_param[2,m] = landing2 else: #print 'too far' pass print c_speed,c_angle,landing2,closest_flight else: print 'Collision' del j # to clear that object m += 1 print print print print

"closest_landing: " + str(closest_landing) "closest_flight: " + str(closest_flight) "@angle: " + str(best_angle) "@speed: " + str(best_speed)

if __name__ == '__main__': # Uncomment one of the following to run that particular tool reliability() #optimalLaunch()

19

APPENDIX D—PLC CODE The following PLC code was tested on a DirectLogic DL05 and is shown in Simplex form rather than Ladder Logic form. The seemingly long timer constants were used for testing the machine and not necessarily for juggling. As a coding convention, I prefixed inputs with i, outputs with o, stages with s, and other remaining coils with c. PLC 05 // Rung 1 // Address 0 ISG "s I/O Mapper" // Rung 2 // Address 2 STRN "oRetractRightCyl" OUT Y4 // Rung 3 // Address 4 STRN "oRetractLeftCyl" OUT Y3 // Rung 4 // Address 6 STR X2 OUT "iRCylRetracted" // Rung 5 // Address 8 STR X0 OUT "iRCylExtended" // Rung 6 // Address 10 STRN X1 OUT "iRBallCup" // Rung 7 // Address 12 STRN X5 OUT "iLBallCup" // Rung 8 // Address 14 STR X4 OUT "iLCylRetracted" // Rung 9 // Address 16 STR X3 OUT "iLCylExtended" // Rung 10 // Address 18 STR "oRGrip" OUT Y5 // Rung 11 // Address 20 STR "oLGrip" OUT Y2

// Rung 12 // Address 22 ISG "sInitializer" // Rung 13 // Address 24 STR "_On" SET "oRetractRightCyl" SET "oRetractLeftCyl" JMP "sJuggleControl" // Rung 14 // Address 28 SG "sJuggleControl" // Rung 15 // Address 30 STR "_On" TMRF "LeftLagTimer" K100 // Rung 16 // Address 34 STR "_On" TMRF "RightLaunchTimer" K1000 // Rung 17 // Address 38 STR "LeftLagTimer" TMRF "LeftLaunchTimer" K1000 // Rung 18 // Address 42 STR "RightLaunchTimer" SET "cLaunchRight"

// Rung 23 // Address 56 STRN "iRBallCup" RST "oRetractRightCyl" // Rung 24 // Address 58 STR "iRCylExtended" SET "oRGrip" TMRF "RightResetTimer" K1000 // Rung 25 // Address 63 STR "RightResetTimer" SET "oRetractRightCyl" RST "cLaunchRight" JMP "sRightLauncher" // Rung 26 // Address 67 SG "sLeftLauncher" // Rung 27 // Address 69 STR "cLaunchLeft" AND "iLBallCup" AND "iLCylRetracted" RST "oLGrip" RST "LeftLaunchTimer" JMP "sLeftResetter" // Rung 28 // Address 75 ISG "sLeftResetter"

// Rung 19 // Address 44 STR "LeftLaunchTimer" SET "cLaunchLeft"

// Rung 29 // Address 77 STRN "iLBallCup" RST "oRetractLeftCyl"

// Rung 20 // Address 46 SG "sRightLauncher"

// Rung 30 // Address 79 STR "iLCylExtended" SET "oLGrip" TMRF "LeftResetTimer" K1000

// Rung 21 // Address 48 STR "cLaunchRight" AND "iRBallCup" AND "iRCylRetracted" RST "oRGrip" RST "RightLaunchTimer" JMP "sRightResetter" // Rung 22 // Address 54 ISG "sRightResetter"

20

// Rung 31 // Address 84 STR "LeftResetTimer" SET "oRetractLeftCyl" RST "cLaunchLeft" JMP "sLeftLauncher" // Rung 32 // Address 88 END

BIBLIOGRAPHY Aboaf, Eric W., Steven M. Drucker, and Christopher G. Atkeson. “Task-Level Robot Learning: Juggling a Tennis Ball More Accurately.” In 1989 IEEE International Conference on Robotics and Automation Held in Scottsdale, Arizona 14-19 May 1989, vol. 3, 1290-1295. Washington, D.C.: IEEE Computer Society Press, 1989. Atkeson, Christopher G., Joshua G. Hale, Mitsuo Kawato, Shinya Kotosaka, Frank Pollick, Marcia Riley, Stefan Schaal, Tomohiro Shibata, Gaurav Tevatia, Ales Ude, and Sethu Vijayakumar. “Using Humanoid Robots to Study Human Behavior.” IEEE Intelligent Systems 15 (2000), no. 4: 46-56. Beek, Peter J. and Arthur Lewbel. “The Science of Juggling.” Scientific American, November 1995: 92-97. Buehler, Martin. “Robotic Tasks with Intermittent Dynamics.” Ph.D. diss., Yale University, 1990. Donner, Marc D. and David H. Jameson. “A Real-Time Juggling Robot.” In Proceedings of the 7th IEEE Real-Time Systems Symposium Held in New Orleans, Louisiana 2-4 December 1986, 249-256. Washington, D.C.: IEEE Computer Society Press, 1986. Kalvan, Jack. “Optimal Juggling: The Analysis and Over-analysis of Juggling Patterns.” Juggling Papers. http://www.juggling.org/papers/OJ/, 1996. Rizzi, Alfred Anthony. “Dexterous Robot Manipulation.” Ph.D. diss., Yale University, 1994. Shigley, Joseph E., Charles R. Mischke, and Richard G. Budynas. Mechanical Engineering Design, 7th ed. New York: McGraw-Hill, 2004.

21