Rotating-Arm Launcher — Model Against Measurement
The model said it would overshoot by 6 m; the real launcher could not release the ball
What I did on this
I did the polar kinematics and projectile analysis, wrote the MATLAB for the Euler integration, and drafted a substantial share of the report. The launcher was operated in class by the instructor; the five of us recorded the results together.
predicted overshoot at the commanded speed
the launcher did not release the ball at all
commanded speed actually needed
against the 20 rad/s the model assumed
error in the supplied geometry
the given 12 in was the diameter, not the radius
The problem
A rotating arm carries a ball outward along a spiral slot, r = cθ, and releases it at θ = π/2.
After release it is a projectile, and it has to land in a hopper 1 m away horizontally and 0.5 m
down — an opening 0.25 m wide, so the acceptable band is 0.875 m to 1.125 m.
The question was whether the supplied design does that. The framing was the instructor's — the whole thing was themed around a sweet factory — but the mechanics underneath are ordinary polar kinematics.
What I did
I solved it analytically first. Differentiating r = cθ gives the radial velocity, the polar
velocity relation gives the transverse component, and at the release angle those convert to
Cartesian:
| Value at release | |
|---|---|
| Radial velocity | 4.064 m/s |
| Transverse velocity | 6.384 m/s |
| Time to fall 0.5 m | 0.938 s |
| Horizontal distance | 5.99 m |
Against a target band of 0.875–1.125 m, that is not close. The supplied design overshoots by about 6 m.
Then I wrote the same problem in MATLAB using Euler integration, at two step sizes, to check the
hand result rather than trust it. h = 0.01 landed at 5.95 m and h = 0.001 at 5.99 m —
converging on the analytical answer as the step shrinks, which is what Euler's method should do
and is the reason for running both.
So two independent methods agreed. That felt like the end of the problem.
How it turned out
Then we measured the actual launcher, and the first thing we found was that the supplied geometry
was wrong. The specification gave 12 inches, and 12 inches was the diameter — the radius was
6. That changes the slot equation from r = 8θ to r = 3.82θ, and the predicted overshoot from
6 m to 0.64 m. The hopper height was off by about 6 mm as well.
Rerunning everything with the measured geometry still said the ball would sail past the hopper.
It did not. At 20 rad/s the ball did not leave the launcher at all. Nor at 25. It barely cleared at 30, and only reached the hopper between 40 and 45 rad/s.
| Commanded speed | Landing distance |
|---|---|
| 20 rad/s | did not exit |
| 25 rad/s | did not exit |
| 30 rad/s | 0 m |
| 35 rad/s | 0.787 m |
| 40 rad/s | 0.965 m |
| 45 rad/s | 1.092 m |
| 50 rad/s | 1.448 m |
The commanded speed is not the speed the motor reaches. Under the load of the arm and the ball it turns considerably slower, and the analytical model has no term for that — it assumes constant angular velocity and ideal energy transfer, which is exactly the assumption that fails.
Interpolating the two measurements either side of centre gives 41.4 rad/s to land at 1 m, with anything from 37.5 to 45.5 rad/s landing inside the hopper.
What I'd do next
The interpolation gives a number that works, but it does not explain the motor. We assumed the arm's load was the dominant cause of the slowdown without measuring it, and friction and air resistance are unquantified. Characterising the motor under load — torque against speed — would turn a fitted number into an actual model, and would let the same launcher be resized for a different ball or a different distance without another round of trial and error.
The other thing worth saying: nobody would have caught the diameter-for-radius error without putting calipers on the hardware. Two methods agreeing with each other is not the same as either of them being right.