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 ball-
launcher 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 1
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. 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
shows the large variations in landing ± 0.1 ±0 7
3.5 m/s @ 15°
locations due to small errors in the ±0 ±1 8
launch. As evident, a person or robot
trying to juggle should be able to ± 0.1 ±0 13
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, pole-
balancing, 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)
2
dy
By setting =0 and solving for t, the time to vertex is
dt
−v 0 sin 
t vertex = . (3)
g
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) Vertex height (m) Time to vertex Air time
@15° ⊥ (sec.) (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 Figure 4: In Energy State 2, the

launcher is at its lowest position launcher is moving at its fastest
and ready for launch. 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 = PE 2 spring PE 2 grav. KE 2
1 1 1 (5)
k  x init x travel 2 = k  x 2init mg  x travel  mv 2 .
2 2 2
Solving for the spring constant gives

k=
1
mg  x travel  mv 2
2
=

2
1
2 mg  x travel  mv 2
2  , (6)
1 2 2  x travel 2 xtravel⋅ x init
2
  xinit  x travel  − xinit 

while solving for the prestretch of the spring gives

mg mv2 1
 x init =  −  xtravel . (7)
k 2 k  x travel 2

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
(8)
= 368N/m 0.0944m 0.088m 13 N=80 N .
At 400 kPa (58 psi), the cylinder is able to pull
F cylinder = PA
2 (9)
=  0.4 MPa  421 mm =168 N ,
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 . (10)
2
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 . (11)
2
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
60 sec./min.
t air , min = =1.07sec. (12)
56 cycles/min.
Combining (3), (4), and (12) and solving for initial velocity (at =90−15 ) yields the
minimum launch speed that the shock absorber imposes:
−g t air , min
v min= . (13)
2 sin 
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) Vertex height (m) Time to vertex Air time
@15° ⊥ (sec.) (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
Fa
y max =  a−3⋅l  , (15)
6E I
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
F 6E I
k cantilever = = 2 . (16)
y max a a−3⋅l 

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
v
y max= .

 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
. (18)

Figure 5: Stress analysis of cantilever using

Pro/Engineer

9
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 computer- Air valve not fast

Catch/release mechanism for launch Implemented
controlled launch enough

Mostly solved
Baseboard
Fix baseboards together or to the floor with heavy
movement
weights

Landing Excessive vibration Not

Shorten cup and stiffen T-slot
repeatability of carriage and T-slot implemented

i. Reduce mass of spring

Excessive vibration Not
of spring ii. Dampen spring with absorber implemented
mechanism and/or time between launches

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

Figure 6: Originally, the cylinder fixed to the cylinder rod (not seen because
rod interfaced directly with the retracted)
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) 0.0500
be “friction-free.” In fact, the spring constant was now much mass_slideblock (kg) 0.0160
larger than it needed to be. As shown in Table 5, the spring mass_rod (kg) 0.0729
was designed assuming the cylinder rod would take part in the mass_cantilever (kg) 0.0260
launch. mass_angle (kg) 0.0180
mass_misc (kg) 0.0332
The mass of the balls also vary slightly (Table 6). mass_total (kg) 0.2161

Ball Mass (grams) Travel on linear bearing

dx (m) 0.088
Green 49.9
Red 52.4
Blue 48.6 Spring Constant
k (N/m) 390.0
Table 6: Ball Mass
k (lb/in) 2.23
Table 5: Spring Calculation
(see equations (6) and (7))

Part Part # Qty Cost Shipping&Tax Total Company

Linear Motion guide 1SRS9M C1 +135N 2 $0.00 $0.00 THK America
Airpel Anti-Stiction cylinder E 24 D 5.0 UM 2 $96.00 $8.94 $200.94 Airpot
Hacky Sack Balls 844 3 $3.50 $4.00 $14.50 World Footbag Assoc.
Extension Spring 80987 2 $18.23 $6.93 $43.39 Century Spring Corp.
T-Slot Extrusion 1020x47.5” 2 $11.40 $14.70 $37.50 eBay 8020 Garage Sale
Shock absorber 3740K12 2 $33.56 $4.50 $71.62 McMaster-Carr
Pneumatic Gripper (LH) MHZ2-20D 1 $0.00 $0.00 SMC
Pneumatic Gripper (RH) MHZ2-16D 1 $0.00 $0.00 SMC
Total $367.95
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 Figure 9: Determining parameters that did
angles (code in App. C) not result in ball collisions (code in App. C)

(a.) (b.)

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()) #x coord. of where 2nd
#launcher should be
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) #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

# This loop needs to be optimized. probably either using numpy's implicit loops or sending
#arrays
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 "closest_landing: " + str(closest_landing)

print "closest_flight: " + str(closest_flight)
print "@angle: " + str(best_angle)
print "@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 12 // Rung 23

// Address 22 // Address 56
ISG "sInitializer" STRN "iRBallCup"
// Rung 1 RST "oRetractRightCyl"
// Address 0 // Rung 13
ISG "s I/O Mapper" // Address 24 // Rung 24
STR "_On" // Address 58
// Rung 2 SET "oRetractRightCyl" STR "iRCylExtended"
// Address 2 SET "oRetractLeftCyl" SET "oRGrip"
STRN "oRetractRightCyl" JMP "sJuggleControl" TMRF "RightResetTimer" K1000
OUT Y4
// Rung 14 // Rung 25
// Rung 3 // Address 28 // Address 63
// Address 4 SG "sJuggleControl" STR "RightResetTimer"
STRN "oRetractLeftCyl" SET "oRetractRightCyl"
OUT Y3 // Rung 15 RST "cLaunchRight"
// Address 30 JMP "sRightLauncher"
// Rung 4 STR "_On"
// Address 6 TMRF "LeftLagTimer" K100 // Rung 26
STR X2 // Address 67
OUT "iRCylRetracted" // Rung 16 SG "sLeftLauncher"
// Address 34
// Rung 5 STR "_On" // Rung 27
// Address 8 TMRF "RightLaunchTimer" K1000 // Address 69
STR X0 STR "cLaunchLeft"
OUT "iRCylExtended" // Rung 17 AND "iLBallCup"
// Address 38 AND "iLCylRetracted"
// Rung 6 STR "LeftLagTimer" RST "oLGrip"
// Address 10 TMRF "LeftLaunchTimer" K1000 RST "LeftLaunchTimer"
STRN X1 JMP "sLeftResetter"
OUT "iRBallCup" // Rung 18
// Address 42 // Rung 28
// Rung 7 STR "RightLaunchTimer" // Address 75
// Address 12 SET "cLaunchRight" ISG "sLeftResetter"
STRN X5
OUT "iLBallCup" // Rung 19 // Rung 29
// Address 44 // Address 77
// Rung 8 STR "LeftLaunchTimer" STRN "iLBallCup"
// Address 14 SET "cLaunchLeft" RST "oRetractLeftCyl"
STR X4
OUT "iLCylRetracted" // Rung 20 // Rung 30
// Address 46 // Address 79
// Rung 9 SG "sRightLauncher" STR "iLCylExtended"
// Address 16 SET "oLGrip"
STR X3 // Rung 21 TMRF "LeftResetTimer" K1000
OUT "iLCylExtended" // Address 48
STR "cLaunchRight" // Rung 31
// Rung 10 AND "iRBallCup" // Address 84
// Address 18 AND "iRCylRetracted" STR "LeftResetTimer"
STR "oRGrip" RST "oRGrip" SET "oRetractLeftCyl"
OUT Y5 RST "RightLaunchTimer" RST "cLaunchLeft"
JMP "sRightResetter" JMP "sLeftLauncher"
// Rung 11
// Address 20 // Rung 22 // Rung 32
STR "oLGrip" // Address 54 // Address 88
OUT Y2 ISG "sRightResetter" END

20
 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