Automated foosball table

Videos and report

Anders Chr. Myrup — Tue, 11 Dec 2007 15:00:20 +0000

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.

Another video

Anders Chr. Myrup — Sat, 27 Jan 2007 15:19:24 +0000

Here’s another video:

Click here to view the embedded video.

Testing and documenting…

Anders Chr. Myrup — Thu, 25 Jan 2007 21:28:06 +0000

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

Click here to view the embedded video.

Good news

Anders Chr. Myrup — Fri, 12 Jan 2007 13:50:22 +0000

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…

Status

Martin Ã˜rding-Thomsen — Thu, 04 Jan 2007 18:12:28 +0000

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.

Click here to view the embedded video.

It should stand a chance against newbies.

Picture and AI stuff

Martin Ã˜rding-Thomsen — Mon, 04 Dec 2006 10:56:43 +0000

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.

Cool Motors

Anders Chr. Myrup — Fri, 01 Dec 2006 15:56:39 +0000

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Â

-,164: 129
-,111: 130
-,07:Â 131
-,039:Â 132
0,006:133
0,054:134

20 amps offense
10 apms (II) offense
0,04:134
-0,003:133
-0,041:132

CENTER
0,206:128
0.325:130
0.220:127
0,144:125
0,061:123
0,030:122<—-
0,060:121

DEFENSE
0,065:135
0,45:133
0,39:132
0,29:131
0,21:130
0,05:128
-0,03:127<—-
-0,11:126
-0,19:125

CENTER2
0,27:128
-0,07:123
-0,04:122
-0,05:121

OFFENSE2
0,04:134
-0,001:133<—-
-0,03:132
-0,08:131

GOALIE
0,19:128
0,12:127
0,036:126<—–
-0,06:125
-0,15:123

Random lag

Martin Ã˜rding-Thomsen — Mon, 27 Nov 2006 10:33:30 +0000

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.

More power

Anders Chr. Myrup — Thu, 23 Nov 2006 10:00:33 +0000

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).

Click here to view the embedded 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.

New reset procedure

Anders Chr. Myrup — Mon, 20 Nov 2006 11:32:37 +0000

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).

Click here to view the embedded video.