Safety first (or somewhere in between)

November 20th, 2006




This has been implemented in the following way:



Broken parts

November 20th, 2006



Snapped timing belt



Rod, ball, and shakiness detection

November 20th, 2006

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





Calibration picture



October 9th, 2006

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.

The AI

October 3rd, 2006

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.

Remote connections and VSS

September 30th, 2006

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.

Compiling the beast on other systems

September 28th, 2006

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.

Misc misc

September 27th, 2006

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.

Simulator updates

September 25th, 2006



The rolling friction on the ball seems pretty accurate now.



GUI showoff

September 25th, 2006

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.