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