Labyrinth - Revision history

Jca: /* Description */

2017-10-24T15:07:42Z

Description

← Older revision		Revision as of 17:07, 24 October 2017
Line 61:		Line 61:
	:Tilting the playing field with the mortors.		:Tilting the playing field with the mortors.

			Software
			:The software is part of the mobotware package, in a subdirectory called "mobotware/trunk"

	===Camera tracking===		===Camera tracking===

2017-10-24T15:04:27Z

Take camera images

← Older revision		Revision as of 17:04, 24 October 2017
Line 42:		Line 42:

	If this is not sufficient, then reboot the computer AND do the cable trick.		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==		== Description==

2017-10-24T15:01:42Z

Take camera images

← Older revision		Revision as of 17:01, 24 October 2017
Line 42:		Line 42:

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



	~~- with auto settings - and save as BMP files~~

	== Description==		== Description==

2017-10-24T15:01:19Z

Take camera images

← Older revision		Revision as of 17:01, 24 October 2017
Line 24:		Line 24:
	./labyrinthgame 1 1000		./labyrinthgame 1 1000

	The first parameter must be "1"		The first parameter must be "1".

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

2017-10-24T15:00:25Z

← Older revision		Revision as of 17:00, 24 October 2017
Line 8:		Line 8:

	A stepper motor crane can move the ball to the game.		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.



			- with auto settings - and save as BMP files

	== Description==		== Description==

2016-06-07T07:20:18Z

Route finding

← Older revision		Revision as of 09:20, 7 June 2016
Line 36:		Line 36:

	===Route finding===		===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===		===Controller===

2016-06-07T07:04:53Z

Description

@@ Line 11: / Line 11: @@
 == Description==
-@todo
+The Labyrinth game consists of four major components:
-[[camera sensor]]
+Camera tracking
 == Test results==

2015-09-07T10:45:31Z

2013-08-22T09:38:44Z

Timing test camera and ball finder

← Older revision		Revision as of 11:38, 22 August 2013
Line 19:		Line 19:
	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 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 ~~1250~~ bytes and this allows about 200 frames per second on a 60 lines by 752 columns image. Taking the slize with the ball.		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)		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)

2013-08-22T08:15:40Z

Timing test, USB interface to Atmel board

← Older revision		Revision as of 10:15, 22 August 2013
Line 25:		Line 25:
	=== Timing test, USB interface to Atmel board ===		=== 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. ~~Sending~~ 3 commands in one go, the reply of the first is within 0.5ms and remaing 2 are received with 0.05ms interval~~, suggesting~~ that most of the 0.5ms is spend on the USB connection, rather than on the 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.