Labyrinth

The labyrinthgame is is a tilt controlled ball that roll in a wodden labyrinth.

Introduction

The game was initailly operational in 1999 using an analog camera, a framegrapper and a DOS operating system, controlling DC motors to perform the roll and tilt needed to follow a predefined route. The interface used a dedicated DA and digital interface board.

The present modification uses a firewire camera Guppy-36C connected to a Linux PC, controlling the same DC motors, in about the same way. The interface is now USB to an Atmel Mega32U4 (a Teensy-2 board) and a few external components.

A stepper motor crane can move the ball to the game.

Take camera images

The labyrinthgame application can be used to save sample images.

Login on the computer.

With a bit of luck, the labyrinth application is present in the home directory, otherwise it can be fetched by

cp /misc/vhome/jca/mobotware/labyrinthgame/trunk/labyrinthgame .
cp /misc/vhome/jca/mobotware/labyrinthgame/trunk/labyrinthgame.ini .

Run the application - to take images with automatic settings (shutter time and video gain)

./labyrinthgame 1 1000

The first parameter must be "1".

The second parameter is an image number (of the first image).

The application takes 8 images and saves them with names like this:

labyrinthgame_img_1000.bmp
labyrinthgame_img_1001.bmp
labyrinthgame_img_1002.bmp
labyrinthgame_img_1003.bmp
labyrinthgame_img_1004.bmp
labyrinthgame_img_1005.bmp
labyrinthgame_img_1006.bmp
labyrinthgame_img_1007.bmp

It is seen that the camera (or the driver) gets into a mode, where no images gets processed. To cure this situation start by removing the firewire cable from the back of the computer for a moment (to allow Linux to remove the driver and to power down the camera) and then plug it back in.

If this is not sufficient, then reboot the computer AND do the cable trick.

Then you could e.g. move then to your campusnet folder from an internet browser.

Description

The Labyrinth game consists of four major components:

Camera tracking

Finding the ball by analysing a picture of the playing field..

Route finding

Determining the direction the ball should be moved in.

Controller

Converting the desired velocity change to motor input.

Motors

Tilting the playing field with the mortors.

Camera tracking

The ball used is a polished steel ball. A polished ball will reflect light shining on it, and create a reflection of the light source above it. This enables the program to look for a bright spot against a darker background, easing detection of the ball.

Finding this blue spot is done by scanning the image for a concentration of blue pixels, due to the blue lightning from the LEDs. The blue lighting is chosen to be able to differentiate the reflection of the lighting source and sunlight shining through a window. The sunlight is white and therefore will create a peak of red, green and blue, where the source LEDs will only create a peak of blue. By having the LEDs placed above the playing field the reflection represent the approximate center of the ball.

The camera only sends a thin line (4-5 time the width of the ball) to the computer, instead of an entire picture. This is done to reduce processing power required to find the ball (less image to scan), and the speed of picture acquisition.

Route finding

The route is not determined from an initial picture from the camera, it is preset in a text file as a series of points (x,y coordinates). To create a route from the points a line is drawn from one point starting from the first, and the final point is then the end. The route is only regarded one line segment at a time, and one line segment is two points.

Finding the direction to the route, the point closest to the ball on the current route segment is found. If this point is more than 1.5cm away the game stops and should be reset. If the route is found to be closer than 1.5cm the game continues. To move along the route a point that is ahead of the ball on the route is needed. To find this point a circle around the ball is examined , this circle will intersect the route at two points, the forward most of these two points are chosen as the target. This target point is now the ‘Carrot point’ the point the ball will be moved towards. To make sure the ball keeps moving, the carrot point is continuously moved forward at a predetermined speed.

Once the carrot point has been found, it is a simple matter to create a vector from the ball to the carrot point. This vector is used to direct the ball, the length of the vector determines speed (up to a certain max speed) and the direction of the vector, the direction of the ball.

Controller

Having the position of the ball from the camera tracking procedure, and the time elapsed since last position. The current velocity (speed and direction) of the ball can be determined by calculating the ball X and Y velocity in this way:

X Velocity = (Ball X Position - Ball Old X Position) / Time since last position update Y Velocity = (Ball Y Position - Ball Old Y Position) / Time since last position update

With the carrot point (target coordinate) from the route finding routine, the desired velocity of the ball can be determined. This is done by subtracting the current velocity form the desired velocity( the speed and direction that will get the ball moving along the route). This value is the 'error velocity' or the difference in velocity from what is desired. This difference in velocity is what we want to add to the ball, to moving along the route.

To get this change in velocity to the ball the playing field needs to be tilted, the change in angle to achieve this is determined by the PID controller.

The PID controller takes the 'error velocity' and converts it to a set of angles the motors can use. The two angles (one for each axis) is then sent to the motor controller which turns the motors to the desired angle.

Motors

The motors controlling the playing field are stepper motors attached to a potentiometer. The potentiometer measures the current angle of the playing field, to prevent drift of the motors. The motors are turned by the computer by sending the desired angle to be turned to the motor controller.

Test results

Timing test camera and ball finder

The camera runs with a shutter time of 250 and a gain of 64 (both camera units), this gives a good image with no saturation in normal in-door light.

The firewire packetsize is set to 1600 bytes and this allows about 200 frames per second on a 60 lines by 752 columns image. Taking the slize with the ball.

The ball finder process shows (in a logfile transferred to file server over the wired net) a stable 5ms between each frame (i.e. full camera speed)

Timing test, USB interface to Atmel board

From a command is transmitted to a status reply is received, no more than 0.5ms is seen.

When sending 3 commands in one go, the reply of the first is within 0.5ms and remaing 2 replies are received with 0.05ms interval.

This suggests that most of the 0.5ms is spend on the USB connection (most likely on the link from PC to Atmel), rather than on the Atmel board.