Automated foosball table

During the last few weeks a new motor-controller software was implemented and tested.
The new motor-controller software detects when something is preventing the rods from moving, ie. when the remains of a child’s hand has gotten caught in the mechanics. Rather than continuing the molesting, the rod stops after 0.2 seconds of stalling.

This is also relevant if the rods should move too far sideways. Instead of a circuit burn off, the doubling of current happens for 0.2 seconds, before the board cuts the power. The following video demonstrates rod sideways movement and in the end a sidecrash. The LED indicates the power has been cut.

This also happends should the ball get stuck between a shooting man and the floor:

This has been implemented in the following way:

If the rod hasn’t moved for 0.2 seconds and the wanted position isn’t the current position, go into emergency stall mode.

This emergency stall mode has to be exited by a hard reset or a soft reset sent by the server controlling the motor-controller boards, before the motor-controller responds to any set position calls.

To prevent a rod from moving too far sideways. Two switches are located at each rod. These are supposed to be hit whenever a rod moves too far. But these switches are attached with double tape, and have a tendency of falling off. It is a problem mounting them properly, because for them to be effective without being a limitation, they have to be placed with great precision, and holes have to be drilled.
Since the switches fall off, we had an accident with one of the rods moving too far, resulting in a burned out circuit on one of the motor-controller boards. The rod had moved to the end of the possible moving range for the rod, and the engine was still fully powered, resulting in doubling of the current for about 2-3 seconds.

Also in seperate incident, a timing belt snapped (see picture). Unfortunately, they are old and have lost their flexibility.

They aren’t steelwire enforced, so should the problem reoccur, stellwire enforced timing belts would make good substitutes.

Instead of mounting the switches properly, we’ve decided to create a software fix, and remove them entirely, more on this later.

A number of improvements have been made to the imaging software. 

Using almost hardcoded values for the position of rods in the picture, the position of the human men on the rods can now be found. For each rod the algorithm works by starting to look at the rod from one end and progressing towards the other, pixel by pixel. In each pixel row it measures the number of pixels that look like a man. Then a weighted average of these values is made to find the actual position of the man.

The ball finding algorithm now uses a weighted average of the color values in each pixel to find the exact position of the ball. This should give sub pixel precision but measurements of the variance in the found position with and without a weighted average should be made.

When playing, the camera shakes back and forth. To compensate for this when trying to find the ball and men, we have made an antishaking algorithm that continually looks at one edge of the table. When this edge moves the antishaker changes the corner pixels of the table accordingly.

On the calibration picture you can see where the program has found the white sticker in the corner, where it thinks the corner of the actual playing field is, where it thinks the rods are and where it finds the edge of the table (for the antishaker).

The big black box shows the area within it looks for the white sticker. The smaller black boxes indicate where the antishaker looks for the white to dark transition and thereby the table border.

Our AI has come so far that it doesn’t make sense to do any more work on it before the enemy men can be recognized. Before this can happen however, the camera should calibrate itself automatically. We’ve chosen to do this by attaching little white stickers to the red corners of the table. These are easy to recognize and with a little bit of math, the program will calculate the position of the corners of the actual playing field.

These stickers are only used once on startup – there’s no reason to do this every frame. Especially not since the opponent and spectators might stand in the way of the camera when playing. You can see one of the stickers here:

The next step is to find out where the actual rods are at. This serves two purposes:

• We know at which pixels not to look for the ball. This is important since the rods can easily be very light and be mistaken for the ball.
• We know where to look for the human players.

After this we might want to look into also recognizing the angle of the human players. Also some hardware work needs to be done, and advanced features of the AI can be implemented.

Work on the actual AI has begun now. But first we had to make a big decision on which approach to use. There are two main options:

1. A purely reactionary AI, with all strategies hardcoded.
2. A more advanced AI that can learn from its mistakes, invent new things on the fly etc.

Each option has its pros and cons:

1. A reactional AI is easy to create – just put your own strategies into code. It basically looks like hundreds of if-statements about the position and velocity of the ball and the players. If something doesn’t work, you can pinpoint the exact line where it fails and correct it. On the other hand, if the opponent figures out a way to outsmart the AI, it will have no chance of winning since it doesn’t learn from its mistakes.
2. This is very difficult to create. You have to come up with a system that can learn from it’s own mistakes and it has to be general enough to cover all situations in the game. It’s not at all obvious how to do this. A neural network could be an idea but the downfall of this, we think, is that an error in the code or simply a wrong approach to the whole thing would be difficult to find and correct. If we could get it to work however, it would have the potential to be much better than the reactional AI.

We decided to use option 1. Our reason is that option 2 is too risky. We could easily end up not having a working AI at all when our project is due. With option 1 we are sure that the AI can play, at least to some degree.

Also, by recording the number of successes and failures of different strategies – both the strategies that the AI and its opponent uses, a reactional AI can learn at least a little bit. Not much but perhaps enough to seem like an intelligence and not just a bunch of if-statements.

Today we gave up the plans of compiling the ai on other systems. It was simply too much trouble compared to the setup we’ve created now:

The project is in VSS (microsoft visual source safe) on our windows pc. From there we can retrieve the files on the same computer and from the macbook. When someone wants to compile it, he copies his source files to rt14 (takes a couple of seconds) and compiles and runs it from there. This way we can both edit the files at the same time and we don’t have to wait for the other guy to have some code that compiles – the code in vss must always work.

This way we also have no trouble merging our projects, vs and vss takes care of most of it. We only have to resolve the conflicts that may arise.

Another thing we found out today was that using ssh tunneling through rt14, we can do remote desktopping on the windows machine. This means that we can work from home as long as we are not using the actual foosball table.

Today we succesfully compiled and ran the main program on Mac OS X.
The compiler on rt14 is very old, and apparently allows some syntax faults like forgetting inclusion of namespaces. The newer compiler on Mac OS X didn’t eat those, so they had to be fixed.
Two real problems arose. First, the semaphore implementations on Mac OS X are different. As far as we know, semaphore creation is only allowed by name. So that had to be implemented, unfortunately if they aren’t deleted properly, they will stay in the filesystem, and be a pain on the next run. This has to be fixed tomorrow.
Also, SIGRTMIN and SIGRTMAX aren’t defined in Mac OS X. Apparently it works with a setting of 0 and 40.

The run showed that the speed of the simulation is a bit hardware dependent. The ball now moves around and comes to a stop a bit faster, this is also a job for tomorrow to fix.
It will be interesting to see wether or not the newly fixed implementations still compile on rt14.

Added lighting to the OpenGl GUI.
Rod-angles are now sent and showed correctly at the GUI (we had a format conflict radians vs. degrees).
Created a physics class to support the simulator and the prophet.
Created an algorithm to detect the foosman which is closest to the ball at any given point for any rod.

Some improvements on the simulation were made today, making our model look pretty nice. Here’s what’s been done: 

The inclining surfaces near the borders and corners of the table are now simulated quite nicely. For some reason they apply too great a force to the ball still. Maybe due to the rotational inertia of the ball, which we don’t simulate at present?

The rolling friction on the ball seems pretty accurate now.

A bug was corrected in the rod update function, so the rods don’t move instantaneously anymore.

The most important feature missing in the simulator now is collision detection and the corresponding change in ball velocity. I wonder how we’re gonna do that…

The graphical user interface connects to the computer controlling the table. It then shows where the ball is located in a nice 3D view.
Using the new simulator, the camera and other hardware can be bypassed and be controlled via the GUI. Here’s a screenshot.