Automated foosball table

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  (more…)

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.

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…

Redid the physics part of the simulator. Now implemented with consideration of forces, instead of the pseudo realistic implementation. This will allow us to create more accurate simulations, in particular when we get interested in creating better simulations of inclining surfaces.
Also fixed some network connectivity bugs in the GUI.

We now have the simulator working. Screenshots will follow.
Also switched from a mix of floats and doubles to using doubles consistently.
If this has a negative effect performance-wise, a move to floats would be the solution.
Here’s a screenshot: The GUI

Today we worked on the socket interface on both ends. Also started on the simulation GUI which is to be integrated with the current GUI for viewing the game status.