Problem Description


Pulldown type after firing 
Pullup "Oops" type after firing 
Here's a "cup" type catapult simulator
(no sling). It simulates tensional or torsional driving
forces with user specified design parameters.
Background & Techniques
Jim Corley, a retired engineer friend of mine, sponsors an annual
competition for the high school Physics classes in his home
town of
Lucedale Mississippi. Past year's competitions have included
bridge building and trebuchets and, last year, cup type
catapults. He had asked me then about writing a simulator program
the to help students in their design phase, but I just didn't get to
it. I did promise him one for this year, so here it
is.
Early catapults looked like most catapults seen in movies with a cup or
bucket on top of the beam containing the projectile until it was
fired.. The development of the sling proved to be more efficient and
apparently came into common use. For current purposes, we'll stick
with the "slingfree" type.
Real catapults evolved with two types of driving force, tensional were
spring type and commonly took on the look of giant crossbows.
Torsional versions used multiple strands of rope wrapped around the
axle of the beam in such a way that pulling the beam into a horizontal
position twisted the ropes to provide the driving force. Most
models today will probably use springs or rubber bands and be of the
tensional type. The simulator models either. Since the
end of the beam must move upward to fling the projectile, spring forces
may be applied on the same side of the beam as the projectile and pull
upward, or on the opposite side of the pivot and pull
downwards. Our simulator accommodates both
"pullup" and "pulldown" spring arrangements.
By convention, our catapults throw from left to right with horizontal
(X) coordinates increasing to the right and vertical (Y) coordinates
increasing upward. The beam pivot point is the origin of the coordinate
system.
With that background, here are the parameters required to define a
catapult:
Catapult Parameters

Pivot height above ground
(so we can tell when the projectile hits the ground). 

Beam Length 

Distance from Pivot to projectile end of beam
(negative values = left of pivot) 

Distance from Pivot to Force point  may be negative, (left of
pivot), or positive (right of pivot) 

Mass of projectile 

Force type (torsion or tension) 

For Tension (spring) force

Spring Fixed end point coordinates 

Spring Constant :
Force per unit length of the driving spring. Compression
springs may be modeled by specifying a negative spring
constant.i 


For Torsion force

Force value. 


Mass of
beam (On Advanced tab sheet) 

Air frictional drag coefficient (On Advanced tab sheet) 
Units Choices

Large Metric: Length in Meters (m); Mass in kilograms
(kg); Force in newtons (N). One newton is the force required to
accelerate one kilogram at one meter per second per second. 

Small Metric: Length in centimeters (cm), Mass in grams
(g), Force in grams force (gf) Note that 1 gram force
is approximately equal to 1 centinewton. (1
gram force = 0.980665 centinewton = 0.00980665 newtons =
approximate force of earth's gravity on a 1 gram mass ). 

Large English: Length in feet (ft), Mass in pounds (lb);
Force in poundsforce (lbf). One pound force = 4.44822 newtons
= approximate force of earth's gravity on a 1 pound mass
). 

Small English: Length in inches (in); Mass in ounces (oz),
Force in ounces force (ozf). . One ounce force = 28.35 gf =
0.278 N = approximate force of earth's gravity on a 1 ounce mass ). 
Here's a
link to the force conversion chart I used. When changing
unit systems, the user can convert existing values or leave them
numerically unchanged.
Simulation parameters
Each of the following parameters can be set for either phase of the
simulation: Firing while the projectile is being accelerated, and Free
flight after the projectile leaves the beam.

Max
simulated run seconds: Simulation stops after this many
simulated seconds. Prevent infinite loops in case of program
bugs or design errors (for example setting gravity <=0). 

Returned
samples per second: This controls the resolution of the
simulated results. Higher values will more accurately
determine the stopping point. 

Calculated
points per returned point: Acceleration values due to outside
forces acting on the projectile (the beam, air drag, and gravity)
are assumed to be constant throughout the calculation
interval. Calculating more points for each returned
point will increase accuracy slightly. The default values of
20 returned samples per second and 10 calculated points for each
returned point provide a reasonable compromise between run
speed and accuracy. 
The program can save and reload catapult definition files (with
".cat" extension). The downloadable files include
several sample catapult designs.
I need to go work on my real model catapult now. Have some
fun!
Nonprogrammers are welcome to read on, but may
want to skip to the bottom of this page to
download executable version of the program.
The RungeKutta unit previously introduced here
on DFF is used to calculate the acceleration forces.
During the firing phase we need to calculate an angular acceleration value
at each calculation time. Without the details, acceleration is a function of the driving
force, the angle that the force is applied and it's distance from the
pivot, the mass of the projectile and it's distance from the pivot point,
the moment of inertia of the projectile and the inertia of
the beam. See the source code for details..
For each returned point, we get to check the
status of the simulation and decide when the projectile is fired.
We'll stop when the beam hits it's stop or when the velocity of the
projectile decreases (i.e. acceleration becomes negative).
The free flight phase evaluates differential
equations for horizontal and vertical movement of a projectile
fired and some initial angle and velocity. This initial trajectory
plus gravity and the air drag coefficient influence the path
followed. Simulation stops when the projectile reaches ground
level.
Each of the returned point exits save some data
concerning the state of the projectile in an array of position
records. When simulations end, the saved results are used to animate
the firing sequence and to display the values at each time interval.
Clicking a Units conversion radio button calls an
exit that recalculates unit values, conversions factors and unit
names. All values are converted from user input fields to large
metric units internally and results are converted back to the selected
units system before display to the user.
Addendum August 21, 2005: I
completed my model catapult and got to fire the first test shots
today! It's still clamped rather than screwed together and I just
approximated the firing angle, spring constant and distance, so there may
still be some computational errors in the program, but my
approximations were different enough from the test cases to uncover
a couple of minor bugs: Projectile location on the animation was offset
vertically between the firing phase to the flight phase. Also the
units label was incorrect for the spring constant  it showed mass
per unit length instead of force per unit length. There may be
additional updates in the coming weeks as I test it against my real
catapult.
Addendum: August 24, 2005: The
version from a few days ago introduced some problems that had been fixed
in the original posting  converting from one unit's system to
another changed the catapult's operation. Fixed today as Version
4.11.
I'm still having problems verifying the
calculations against my physical model. Either I'm measuring
the spring constant incorrectly or there's an error in calculating the
Moment of Inertia for the beam and mass. Observed flight distances
are about 1/10th the calculated
values.
Addendum: August 24, 2005:
Completed the first round of catapult testing this morning. The
results are in the ball park with program results, although there are some
anomalies. Version 4.12 of the program was posted with a small
change or two.
I defined efficiency as average observe throw
distance divided by program distance. For the spring constant as I
originally measured it, some efficiencies were over 100%, obviously not
possible. I suspect that the inertia of the throwing beam may be
underestimated. When I increased the input Spring constant value by 25%,
the efficiencies ranged from 77% to 97% with the extremes occurring when
using the small (5 gram) weight. So there may be some issue
with the pin that holds the weight on the beam. I'm not done
experimenting, but it looks like results are ballpark, at least for this
version. I can provide some construction and usage tips for
anyone planning to build a cat similar to this one. Just
drop me a line.
Addendum November 7, 2006: I had
some interesting exchanges with Joe L. and his daughter as they worked
on building a catapult for her high school Physics project this
fall. Their construction was quite different from my model, so I
asked Joe to write it up for me.
The resulting page is here.
Running/Exploring the Program
Suggestions for Further Explorations

Add pivot bearing friction. 

Add second driving force. 

Add additional beam shapes for Moment Inertia
calculation. 

Add sling option. 
Original Date: August 01, 2005 
Modified:
February 18, 2016

