The main project goal was to complete a working prototype for an Autonomous Foosball Table (AFT), where a human player faces a robotic opponent. From the human perspective of the game, the foosball table is very similar to a regular table. The player(s) on the human side are controlled via a series of four handles that can be moved in and out and rotated to move the players linearly across the playing field and to kick the ball towards the opponent's goal. The autonomous side consists of:

> Eight servo motors used to manipulate the handles of the foosball table
> A microcontroller to activate the servo motors and communicate with the computer
> An over-head mounted webcam to track the ball and players
> A computer to process the webcam images, implement artificial intelligence, and communicate with the microcontroller

Budget constraints for the prototype slowed the project some and kept its functionality to a minimum. Proper motors to move the players at a competitive speed were found to be very expensive, so lower-end servos had to be used.

While this particular implementation was limited by cost and time, a larger gear ratio would yield a faster playing robot, although doing so would cost more than the $500 base price (price without power supply & computer).

Step 1: Assembling the Motor Control Board

The attached images are a full circuit schematic as well as a picture of the final product for the motor control board. All of these required parts may be purchased at most major online electronics stores (including Digi-Key and Mouser. As a side note, all of the parts used here were through hole, and thus, the parts may be assembled on a protoboard/breadboard, or using the attached PCB design. A much smaller package could be created by using a number of surface mount parts.

When we implemented, the design, we split the motor controls into 2 circuits, though there is no advantage to doing so other than any particular cabling scheme used. The small blue board implements the PWM control circuitry, which is basically just a clocked PIC-12F with some specialized code.

Step 2: Servo Motor Assembly

Two different types of servos are used. First, the lateral motion is controlled by a group of four high-torque servos: Robotis Dynamixel Tribotix AX-12. These four run on a single serial line and provide amazing functionality. The high torque enables these servos to be geared in such a way that provides a high tangential velocity for lateral movement. We were able to find a set of 3.5 inch gears and tracks to go with them from Grainger at a cost of about $10 for each. The servos provide torque overload protection, an individual servo addressing scheme, quick communications, internal temperature monitoring, two-way communications, etc. The downside of these servos is that they're expensive and not very fast (though gearing helps them). So in order to get faster motion for kicking, Hitec HS-81s are used. The HS-81s are relatively inexpensive, have a decently fast angular velocity, and are easy to interface (standard PWM). The HS-81s only rotate 90 degrees, however (though it is possible -- and not recommended -- to attempt to modify them to 180 degrees). Additionally, they have internal nylon gears that strip easily if you attempt to modify the servo. It would be worth the money to find a 180 degree rotating servo that has this type of angular velocity.

The entire system is tied together with pieces of medium-density fiberboard (MDF) and high-density fiberboard (HDF). This was chosen for its low cost (~$5 for a 6'x4' sheet), ease of cutting, and ability to interface with virtually any surface. A more permanent solution would be to machine aluminum brackets to hold everything together. The screws holding the PWM servos in place are standard machine screws (#10s) with hex nuts holding them from the other side. 1mm metric machine screws, about 3/4" in length, hold the AX-12 into the MDF that connects the two servos together. A double-action drawer track holds the entire assembly down and in-line with the track.

Step 3: Software

The last step is to install all of the software used on the machine. This consists of a few individual pieces of code:

> The code run on the image processing PC
> The code run on the PIC-18F microcontroller
> The code run on each of the PIC-12F microcontrollers

There are two prerequisites to install on the image processing PC. The image processing is done through the Java Media Framework (JMF), which is available through Sun here. Also available through Sun, the Java Communications API is used to communicate to the motor control board, across the serial port on the computer. The beauty of using Java is that it *should* run on any operating system, though we used Ubuntu, a linux distribution. Contrary to popular opinion, the processing speed in Java isn't too bad, especially in basic looping (which vision analysis uses quite a bit).

As seen in the screenshot, both the ball and the opponent players are tracked on each frame update. In addition, the outline of the table is located visually, which is why blue painters tape was used to create a visual outline. Goals are registered when the computer cannot locate the ball for 10 consecutive frames, typically indicating the ball fell into the goal, off the playing surface. When this happens, the software initiates a sound-byte to either cheer itself or boo the opponent, depending on the direction of the goal. A better system, though we did not have the time to implement it, would be to use a simple infrared emitter/sensor pair to detect the ball falling into the goal.

All of the software used in this project is available in a single zip file, here. To compile the Java code, use the javac command. The PIC-18F and PIC-12F code is distributed with Microchip's MPLAB software.

Step 4: Webcam Mount

A Philips SPC-900NC webcam was used, though it is not recommended. The specs for this camera were falsified either by the engineering or sales staff at Philips. Instead, any cheap webcam would do, so long as it is supported by the operating system. For more information regarding the use of webcams under linux, check out this page.

We measured the distance required by the webcam's focal length to fit the entire foosball table in the frame. For this camera model, that number turned out to be just over 5 feet. We used shelving racks available from any major hardware store to build a mount for the camera. The shelving racks extend upward from each of the four corners of the table and are cross-braced by angled aluminum brackets. It is very important that the camera is centered and has no angular rotation, since the software assumes the x- and y-axis are aligned to the table.

Step 5: Conclusion

All of the related project files can be downloaded at this site. A backup of the majority of the site content can be found here, at my personal web host. This includes the final report, which has a marketing analysis as well as things we would change, our original goals and a list of what specs were actually attained. The project is NOT meant to be the most competitive player in the world. It is a good tool to show more of the steps used in designing such a beast as well as a decent prototype of this type of robot built for an incredibly low cost. There are other such robots in the world, and certainly, many of them would "beat" this robot. This project was designed by a group of four electrical/computer engineers at Georgia Tech as a senior design project. No help was received by any mechanical engineers and no third-party funding was used. It was a great learning process for us all and a decent use of senior design course time.

I would like to thank
> Dr. James Hamblen, our section advisor, for his continuous help in technical strategies
> Dr. Jennifer Michaels, the lead professor, for not discouraging us from attempting a more ambitious project
> James Steinberg and Edgar Jones, the senior design lab administrators, for constant help in ordering parts, troubleshooting, and the finding the "cool stuff" to throw into the project at low cost and high functionality
> And of course, the other three members of my team, of which, none of this would have been possible: Michael Aeberhard, Evan Tarr, and Nardis Walker.