Automated foosball table

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.

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.

It turns up that making the network thing work correctly isn’t that easy. When the client is connected and the server quits, the recv call doesn’t terminate even though we send a signal to the thread.

However, when the client resets the connection (by quitting without disconnecting the proper way), the recv call terminates and sets errno to ECONNRESET.

Both cases should be handled correctly by the threads and the socket class. This includes joining the threads because one of the threads segfaults otherwise. Perhaps using different exception classes for different conditions (e.g. ECONNRESET) is a viable solution.

Apart from diagnosing this problem, a simple simulation was made to work today. It just moves the ball from side to side on the table.

Today we continued our work on the simulator. The user interface is now two-ways on the server-side, since we are planning on using the client GUI as a UI for the simulator. Which means setting the ball position. In practice this was accomplished by using two threads instead of one, because the socket implementation we are using doesn’t allow non-blocking receive calls.