Automated foosball table

Further development on the project stopped in February, 2007. But new video material has been uploaded by request.

Head for the videos section.

The report is available (in danish) here.

Here’s another video:

We have almost finished documenting the robots current abillities.
Here’s a little video treat:

We are currently in the process of testing the robot against many different human opponents.
So far it has beaten all opponents except one. All people describe their own skills within the range newbies-average, except the one opponent who calls himself “pro”.
Our initial goal with this project was beating a 7-year old, and since we have achived this and far more, we have stopped improving the AI for now, and are focusing on writing a report due 1. Feb.
Videos will follow…

With the christmas being done the work continues. We will mainly be working on our report from now on although minor improvements have to be made on the table. Click below for a preview of how the defense is handling right now.

It should stand a chance against newbies.

The antishaker is finally working again, using the new calibration. It has been improved to work with subpixel precision. Also, for a long time it was known to compensate too little compared to the found ball position. This has been fixed, it seems, by multiplying the found shakiness by about 1.1.

Measurements have been made, showing that the found ball and man positions were slightly off in every second picture. This is due to the coarseness of the u and v channels. Fixed by adding or subtracting a value for every second scan picture to the found position.

A rather simple DefenseAttack mode has been implemented. It tries to move the man around the ball and shoot. Nothing more, nothing less. It works ok in the simulator but could be a lot smarter.

Various updates for the MCs were implemented. The rotation MC software lacked precision, because our regul algorithm didn’t work when the precision was set below 30 ticks-+ (1000 ticks = 2pi). The motor was oscillating around the wanted position if the precision was set lower. This has been fixed now, (with a nasty hack), simply shifting the regul results 3 bits down, when wanted position is less than 30 ticks away.

Also another problem was fixed. We noticed that the motors heated even though they weren’t in use.

When they weren’t in use the MC software set the engine voltages at 128. But tests showed that the zero voltage wasn’t 128 for the motors, in fact, they were all different, but within 128 +- 5. As a result a fix was implemented that turns the power off completely (PWM_OFF) if the motor voltage is within 128+- 15 because the rods won’t move for voltages closer to 128 value anyway.

Now the motors are nice & cool (when they aren’t in use).

The test results are attached  Read the rest of this entry »

At random points in time our program was found to skip frames. After some investigation 3 factors turned out to cause the lag:

• Logging text to more than one file per frame. I.e. it’s not possible to do both profiling and value logging as we tended to do it before.
• Not having a sleep() in CommunicatorThread when not using the serial port. This is because the loop in that thread otherwise consumes 100% CPU.
• Running other programs on rt14 at the same time, even just the “top” program which shows a list of the running processes.

The powersupply we use cannot supply the whole table, but at most a single rod.
We measured the current at a single motor running full speed to 10A, which means we need to buy a bigger powersupply.
Right now we are running with 2×10 amps and 1×20 amps supplies.
To test wether the circuit would burnout from a sidecrash, now that greater currents are available, a full speed sidecrash was tested (see video).

The board stall detection system worked like a charm, but the timing belt was strained so much that it snapped eventually. The conclusion is, the board wont burn-out in case of an error, but timing belts (at least the old ones) will snap, either way, this was probably the last full speed side crash test we will ever do.

The objective of the reset procedure is to locate the moving range for the rod. This is done by moving the rod as far as possible to one side. Earlier this was done using the rod switches. They have been removed, and the motor-controller detects the end purely using software now.
The rod moves slowly, because it is expecting a crash with the side, to calibrate for zero (see video).