Big Brother Foosball
Dennis Crowley // dens@dodgeball.com

As seen on Slashdot! (Jan 2003)

Interactive Telecommunications Program @ NYU
End of Semester Project // December 16, 2002

 

Description
Take a standard foosball table and make it a little bit smarter.

1. The table should be aware of who's playing, the score and the status of the game.
2. Take the data from the game and use it to create a stats engine and player ranking system.
3. Project all relevant information about gameplay onto a flat screen.
4. Spend under $50 so I can afford to buy Christmas gifts. :)

Audience
Any ITP'ers who got caught up in the foosball tourney this semester.

Ingredients
- 1 foosball table
- 2 coin switch sensors ($3.00 each, from Happ Controls)
- 1 magnetic card reader ($30, from ID Innovations)
- BX-24, breadboard, a handful of resistors, lots of wire :)

How it Works
There are four basic parts to Big Brother Foosball...

1. Scoring System

My first task was to find someway to make the table smart enough to know when a goal has been scored. Sounds simple enough - throw a sensor that detects motion in the goal, right? I ran into three main problems: (1) there's not much room in the goal to install sensors, (2) it is impossible to disassemble the table without using a crowbar or drill, thus making it hard to install anything and (3) there is no guaranteed/consistent point of contact between the ball and the goal that I could reliably detect in an attempt to determine when a goal has been scored.

This third problem is the most interesting and the one that required the most research. You see, while ITP foosball rules state that a goal is scored whenever the ball gets past the goalie, not all goals are alike. Sometimes the ball hits the metal plate in the back of the goal. Sometimes the ball trickles in without ever touching the back plate. Sometimes the ball is hit so hard, it hits the plate and bounces out.

I researched a number of different type of sensors before actually installing anything:

Round 1 - Photosensors at the goal line
Tom Igoe had tried using photo sensors and laser pointers only to find that sometimes the ball moved too quickly past the photo sensor for the reading to be accurately described as a goal. I ruled out this method pretty early based on both Tom's findings as well as the fact that there just isn't enough room inside the goal to install that type of hardware. In addition, I found that sometimes the ball enters the goal in the air (no joke), suggesting that I would need to install two photo sensors in each goal (upper and lower) to make sure that the goal was covered.

Round 2 - Flex sensors behind the metal plate
After realized that I wouldn't be able to monitor the ball at the goal line, I looked at installing hardware behind the goal line. Inside the goal there's a metal plate which is hit about 90% of the time when a player scores. I played around with the idea of installing a flex sensor behind the plate to measure the moment the ball hit the plate, but soon realized that goals that trickled in (didn't hit the plate) would not be counted.

Round 3 - Touch sensors in the Z-chute
Getting more desperate, I started thinking about putting the hardware in the ball return. After the ball crosses the goal line, it drops into a Z-shaped chute that returns the ball to the player on both sides of the goal. I thought about installing touch sensors at the top of the Z-chute that could detect when the ball dropped into the chute. Problem is, while these sensors are great at detecting a human touch (via electrical impulses in one's fingers) they won't detect a plastic ball dropping into the chute. I thought about putting the touch sensors in the ball return (e.g. the player goes to pick up the ball after a goal and sets off the sensor) but figured there must be a more elegant solution.

Round 4 - Vending machine switches in the ball return
After starting to get worried about how I was actually pull this off, Alex Rainert was showing off the sensors he was using for his lollypop machine. His sensors were purchased from a vending machine company and are traditionally used to sense when coins are dropped into a pinball machine (etc.) Each sensor is on a piece of plastic about 1 inch x � inch off of which a thin metal rod extends. By taking these sensors, bending the rod into an "L" shape and installing them at the bottom of the ball return, I was able to accurately and consistently determine when the ball was returning to the user and thus when a goal has been scored. While this method does not solve the problem of the ball popping in and out of the goal, I believe it's the more reliable solution for now.

 

The next trick was installing the sensors into the goal. My original plan was to disassemble the table and install them in the middle of the Z-chute (so that the player's fingers wouldn't be able to get to them). After wrestling with the table for a few hours, chatting with the foosball dealer in Union Square, and getting the opinions of various ITP'ers, I realized there was no way to disassemble the table without using a crowbar and drill. The end result was abandoning the plan to install the sensors far inside the Z-chute, but instead to put them at the bottom of the chute.

One of my primary concerns was that people constantly reaching into the ball return to get the ball back after a goal would interfere with the sensors possibly rigging the score or rendering the sensors useless. Not until I installed did I realize how unobtrusive they would be. In fact, the user has to go out of their way to find them in the goal.

The sensors will originally taped to the chute with electrical tape. The tape held them in position, but as I was testing the scoring system, I realized that every now and then the L-shaped rod extending from the sensor would fall off requiring me to tilt the table on it's end, remove the tape attaching the sensor and reattaching the rod. Mark Argo came to my rescue with some well-timed strips of Velcro that are now used to hold the sensors in place and enable to the sensors to be easily removed and reinstalled in the case that the rod falls off.

Note: I need to fix this whole 'rod falling off' problem next semester. I think a dab of hot glue may do it. The sensors are pretty sensitive - the rod has to be just the right weight to be able to set of the sensor and then spring back to it's original position. I'll have to carefully figure out whether the glue will affect the sensor in any way.

   

2. Front-end: Macromedia Director Movie

The sensors in the goal talk to he BX-24 which is mounted in a Tupperware container under the table. The BX is programmed so that it knows exactly when a goal has been scored (on either side) and will not allow another score for 2 seconds after the goal has been counted (to prevent the sensor going off twice for one goal).

This information is sent via the serial cable into Director where the score is being broadcast scoreboard-style onto a computer monitor. The Director movie is responsible for all of the game's logic - remember, the BX is only sending Director a constant stream of 1s and 0s.

In addition to displaying the current score, the Director piece is tied to a database that both sends and receives stats on current players and the game scenario. More on that below.

3. Login System: Magnetic Stripe Card Reader

So, it's one thing to be able to move data about the game from the table to the screen, but the real interesting stuff happens when the table actually knows who's playing whom. I figured if I could attach a magnetic card reader to the table, then players could swipe their NYU IDs to login.

When I was home for Thanksgiving, I was lucky enough to "stumble across" (don't ask) a magnetic card reader. I brought it back to NYC, dissected it in the PhysComp lab, got a spec sheet from the manufacturer and spent hours trying to figure out how to extract any data at all from the reader.

Frustrated with trying to connect the reader to my BX, I searched eBay and found a card reader that connected to a computer via a PS2 port and sends data to via keystrokes just as a keyboard would. I had the reader FedEx'ed to me from California, it arrived on Tuesday afternoon and much to my surprise and relief, worked exactly as advertised. When hooked up to a computer with Microsoft Word running, any card with a magnetic stripe can we swiped though the reader and the data encoded in the card magically appears on screen. In the case of the NYU ID, the card contains the student's social security number (er, hence "Big Brother Foosball"), a mystery four digit code (which I am assuming is tired to the program or year the student is enrolled) and header and trailing characters.

With a little luck, I was able to use Director to listen for keystrokes (which are actually being sent from the card reader) and use Lingo to parse out the relevant information in the card. I'm still amazed that it actually works. :)

 

4. Database: IIS/SQL/MS Access

In my opinion, the most interesting part of the project is the database that ties everything together. When the user swipes his or her NYU card, Director takes this information and sends it to a ASP script (running on an Windows 2000 box that is tied to an Access database). This ASP script runs a SQL query through Access and spits back XML that contains information on the player (wins, loss, average points per game, number of games played, etc) . This XML is passed back into Director via getNetText and put into global variables which are then fed to the screen at the appropriate time.

At the end of the game, Director connects to another ASP script, this time reporting the stats of the recently completed game back to the database. A SQL statement is executed and all of the information is inserted into the database. Once the script has been completed, the database automatically updated the player rankings (which are stored in a separate database table). These rankings are then sent back to Director and are displayed on screen - screensaver style - when no one is using the foosball table.

 

Source Code
+ download BasicX code + Director code (not supported - seriously, I have no idea what this code even looks like anymore)
+ demo of scoreboard (broken- sorry, database is no longer running)

(c) 2002, dennis crowley