Continuity

Truth be told, I was going to write another essay of a post here. As is the case with most long blog posts, I spend the spare moments of the day, like standing in line to get food or walking from class to class, marshaling my thoughts and trying to come up with important themes.

Unfortunately, I don't have as much time as I once did, and so the ideas that I had come up with today can't be expressed in their usual format.

This post was going to be about A-Rod.

A-Rod, my friend from high school. Never a close one, but always a friend.

But as friends go, he's been a great one in CMU.

Basically, what it comes down to is the following:

A-Rod loves to play foosball, as do I. He's looking for new ways to get better, ways to measure improvement, and ways to quantify the game. Perhaps it's our computer science training kicking in, or even our research experience. We want a scientific approach to the game. And finally, we have the freedom and the resources to do it.

Here's the problem. Foosball shots are too fast to see with the naked eye. Too fast to see with a video camera, even. The standard 30 frames per second simply isn't good enough. Here's an example: pull shot

Note how entirely useless the slow motion is. Granted, our shots aren't that accurate, but they can be the same speed (depending on whether the defender is trying to react to our shot or simply blocking arbitrary holes in the goal).

We spent an entire dinner trying to figure out how we might increase the frames per second of our video. The discussion was pretty fruitless, but highly entertaining. Our only remotely feasible idea was to get two cameras recording, but one delayed by 1/60th of a second. That way we could interlace the frames and double the frame rate.

There are obvious problems. How do you offset the recording time by 1/60th of a second? Obviously this would have to be computerized and not manual. I was skeptical of the existence of software that would allow cameras to take pictures on command from computers. Ever the computer science major, A-Rod told me that messing around with firmware should be "no big deal." Still don't believe that.

Other problems exist as well. With two cameras, the two different viewpoints would cause problems when trying to interlace the two clips. Maybe those 2.5 years I spent at MITRE weren't entirely useless, because I thought we could use some sort of beamsplitter, one that divides the light based on wavelength. Of course, this entirely messes up the color, but that isn't important in the overall scheme of things.

The consummate photographer, A-Rod began worrying about things that I have no understanding of - the lighting of the game room, the reflection off the table and players, who knows. The discussion carried on. One of A-Rod's friends stopped by and thought of possible solutions. Plates were clean and napkins were piled high, but we sat there thinking and trying to come up with alternatives to a complex, costly, and horrendously inefficient plan.

In the end we decided we'd look around online and talk about it later. As soon as I get home, A-Rod links me to this

Well that was an hour of our lives wasted.

Not really, actually. Problem-solving, applying knowledge, getting better at foosball. Although it's at a low level on all three of those counts, it really does combine the best of many worlds. On top of that, to sit and debate the implementation with a close friend while making random jokes that probably aren't funny in the slightest is not time wasted.

This semester has been hard. This semester is hard.

But it's things like this that keep me afloat. Foosball. Solving awesome math problems. Playing chess.

And on top of that, getting to do it with friends.

Maybe that hour wasn't useless in any sense. A-Rod suggests that 60 frames per second might not be enough, and that we would be better suited to trying to take 120 frame-per-second clips. We'll have to discuss this another time...