For the Chevron STEM Zone at the 2013 Superbowl in New Orleans, we teamed up with John Murray Productions to create an interactive field goal simulator. Inspired by Ben Kokes’ throw analyzer system, our rig let visitors kick a real football into a practice net and see the speed, angle and trajectory of the kick displayed on a 10″ tablet. The custom app we wrote for the exhibit received real-time data from sensors in the football via bluetooth, allowing users to get instant feedback on their field goal stats.

Kicking a ball seems like a reasonably simple thing to do. The catch, however, is that there are immense forces at work. Based on our initial research, we found that the typical contact time for a football kick was on the order of 15 milliseconds. That means a football accelerates from 0 to around 75mph in 15 milliseconds, giving it an acceleration of around 228g’s.

### How We Did It

The first thing we had to do was figure out what a kick actually looked like in terms of acceleration data. We found some high speed video online, but that only gave us rough numbers to work from. We built the first of several footballs, with sensors in it, including a fairly standard +/- 3g 3-axis sensor to get us positioning data (that is, which way gravity was pointing) and a 3-axis 250g sensor constructed from three Sparkfun 250g single-axis sensors. We set up a fairly simple program on an Arduino Fio that spit out the data from the 6 axes as quickly as possible, so we were able to get about 800 readings per second. We then coordinated with Carnegie Mellon’s football team and got their freshman kicker to come stress-test the football. In 4 sensored kicks, he saturated all three axes every time, but we did get good data. We also shot high speed video of his kicks in order to compare the sensor data with visual observations of the kicks.

We also shot wide video of the whole field in order to get flight path data, including how far down-field the kick went, based on the initial impact.

This gave us three data points to work from:

- What our sensors were spitting out
- What the high speed video showed
- What the wide video showed in terms of where the ball landed in the field

This is a familiar pattern if you’ve ever watched Mythbusters:

- What does the sensor data say?
- How fast did the high speed video say the turkey was going?
- What happened to the windshield when the turkey hit it?

Once we had these data points for several kicks, we were able to dig into the data and find out what we were seeing.

It turns out we didn’t really care about the actual acceleration profile of the kick; over about 15 milliseconds, the ball accelerated from rest to some exit velocity, and then it was in a ballistic trajectory, the input for which is just a vector: direction and magnitude.

The magnitude is the speed, and you integrate acceleration to get speed. This is pretty complicated to do in calculus if you’re working theoretically, but it’s actually very easy to do from sensor data.

### Warning: Lots of math ahead…

If we read the sensor once per millisecond (1000 times per second), each reading is actually speed, per g: **9.8 m/s^2 * 0.001 s**

So if our readings are:

100g

50g

25g

1g

0g

For 100g, that’s 980 m/s^2 * 0.001s or about 0.98 m/s. Following the rest of them we get:

**0.98 + 0.49 + 0.25 + 0.0098 = 1.73 m/s**

So we had a magnitude, and now we needed a direction. Using a three-axis acceleration sensor, we had two vectors: one was the force vector from the foot impacting the ball; the other told us the original orientation of the ball before it was kicked (this was a vector pointing at the center of the earth).

The theory was that we could take the difference between these two vectors and use that as our exit angle. The problem was that it didn’t work – the angle calculated was significantly flatter than the real angle. Once we had all this data and video, we were able to see why. When the kicker kicks the ball, his whole leg pivots around his hip, and his contact time with the ball rotates the ball, meaning that the initial vector and the exit vector are rotated. While the ball is being kicked, there’s no way to see the relatively tiny gravitational acceleration.

While there was a possibility of doing some sort of complicated thing with gyroscopes measuring the rotation and some sensor fusion, we realized we could get pretty close by just modeling the kick. Based on our high speed video (and some more we took with non-professional kickers), we were able to come up with a translation function that calculated an exit angle from the contact time.

Because it was a field-goal simulator, and not just a kick simulator, we were able to say, “Given your field-goal try, this is an accurate estimate of exit angle.” Obviously, squib kicks wouldn’t be read correctly.

### The Final Results

The final design had the football transmitting “events” – from rest to high acceleration and back to free-fall, the ball transmitted a short little blip of data containing the speed of the ball and the total contact time.

The app then took these two data points (a speed and a direction) and turned it into a calculation of the speed, angle and total distance kicked (taking into account air resistance!). The If the kicker managed to get the ball over our on-screen field goal, the app played a little cheering sound for them.

The original football’s electronics didn’t last very long – getting kicked was ripping components off them. The exhibit was used many times, though, so we continued working with John Murray to improve the design for future events. The final solution that we settled on was to design custom boards that securely mounted all of the electronics; we then cast the boards in hard epoxy that held everything together and allowed the footballs to be kicked repeatedly without fail.