The goal of this assignment is to write a planning or learning program for the
marble maze game that
takes advantage of corners and rolling along walls, and
improves policies or planning/learning efficiency as it is given new
boards to solve (we will give you more boards, and you can generate your own).
Programs will be evaluated by how many failures (falling into a hole)
in N trials, and in the absence of failures, how long the N trials take.
In the event of a failure, the ball should be restarted in the start location.
The C code maze1.c and maze1.h
defines the marble maze game. These two files should not be modified, except
to translate to another language if necessary. The rest of the files provided
are examples you can modify or ignore.
board2 are examples of maze specifications.
manual1.c is an example of a manual player.
path1.c is an example of a quasistatic planner, that does not
meet the assignment objectives.
path1-execute.c executes the plan generated by path1.c.
sidp1.c is an example of a dynamic planner, that does not
meet the assignment objectives, and does not work particularly well.
sidp1-execute.c executes the plan generated by sidp1.c.
The interface to maze1.c consists of the following functions:
int in_obstacle( BOARD *b, float *state ): returns TRUE if state is inside
an obstacle, FALSE otherwise.
int in_hole( BOARD *b, float *state ): returns TRUE if state is inside a
hole, FALSE otherwise.
int in_goal( BOARD *b, float *state ): returns TRUE if state is inside
goal region, FALSE otherwise.
int initialize_maze( char *board_file, BOARD *b ): reads in a maze description
file and initializes simulator. Returns TRUE if everything okay, FALSE
otherwise (actually it exits() if any problems).
int set_state( BOARD *b, float *state, int *status ): set the state
of the simulator. Returns FALSE if illegal state (status indicates
what went wrong), TRUE otherwise.
int apply_action( BOARD *b, float *u, float time_step, float *next_state,
int *status ): apply action for time time_step. Returns next_state.
Returns FALSE if in hole. TRUE otherwise. Status is currently redundant.
BOARD *create_board(): Mallocs a board structure.
float do_simulation( BOARD *b, float dt ); /* OLDER interface, do not use. */
maze1.c and maze1.h do not depend on any graphics, and should run on
windows and linux (compiled as C rather than C++ programs).
In order to make this more fun, ease debugging, and visualize results,
it is useful to incorporate some graphics. I have used the GLUT toolkit
on top of openGL. The Makefile in the tar file below and the project
definition in the zip file below show how to use GLUT.
On linux, try to use the freeglut package, since that does not force the use of a event loop
(rpms for RedHat 9).
Those of you who want to use windows, try to get freeglut to work.
An alternative is to use an older version of GLUT, modified along these lines.
Here is a tar file of the above programs:
Here is a zip file that has projects for the programs manual1.c,
path1.c, and path1-execute.c (all now .cpp to make Windows happy)
in a directory called "maze".
path1.c was modified so it would work with the older version of glut
(planner called by window event loop idle function).
manual1.c and path1-execute.c are already compatible with the older version
Here is a maze generator written by Martin Stolle.
Here are scans
of actual mazes. If someone can turn them into maze description files,
similar to board2, that would be very helpful.
Mazes that did not fit on the scanner have two scans,
mazeXa.jpg and mazeXb.jpg.
Here are some maze files and software
to digitize the above scans from
Dan, Rob, and Tom.
convert all the mazes because three of them were nearly identical. We've
also included the Matlab function that creates the maze files with the
user clicking on the maze image to locate obstacles. It's fairly
straight-forward to use - the instructions are printed above the image.
To start it just type createMaze('filename.jpg'). Anyway, no guarantees
on the accuracy of the maze files we've provided!"
You ask: So what do I turn in?
Turn this in by sending a URL in email to firstname.lastname@example.org, email@example.com, firstname.lastname@example.org and email@example.com.
Provide a writeup that describes what you did, and why you did it.
Provide your software in a form we can run. Assume we have linux and windows
Known bugs, simplifications:
The marble is controlled by forces directly applied to it (imagine rockets).
The real game has tilting dynamics of the board, rolling and slipping
dynamics of a ball, and the possibility to catapult the ball into the air.
A sensing system based on vision would have a sensing delay.
In the real system, finding where the board is level (what force value is
zero force) and how the control affects the system would need to be
estimated by a controller.
In this simulation,
the marble is actually square from the point of view of collisions with
In this simulation,
being in a hole is only checked at the beginning and end of each integration