WORCESTER POLYTECHNIC INSTITUTE
    Computer Science Department

    CS4341 ❏ Artificial Intelligence ❏ B07

    Mon, Tue, Thu, Fri - 1:00 - AK 233
    Prof. David C. Brown, Fuller Lab 131, (508) 831-5618, dcb at cs.wpi.edu

    Version: Tue Dec 4 20:01:13 EST 2007

    PROJECT 3 - Finding the Best Search Team

    Due Date

    This project is due on Thursday 6th December 2007

    Overview:

    The task is to write a simple Genetic Algorithm (GA) learning system that will work on teams of search vehicles and will improve them. That is, the best team that result from GA processing should produce better results than any of the the original teams. This requires some procedure for evaluating the quality (performance/effectiveness) of each team. This evaluation procedure is used to help guide the learning, causing teams which produce better results to be favored.

    Inspiration:

      This project was inspired by some experiments that Doug Lenat did after he discovered some weaknesses with his AM system. The new system, called Eurisko, was used to successfully evolve a fleet of ships for a "futuristic war game called Traveller".

    The Project:

    The goal of this project is to use a genetic algorithm to produce a high performance team of search vehicles. The search is carried out on a landscape of the type that you have already used. A particular landscape will be provided. A team is searching for two lost children who have become separated from their parents and from each other.

    A team is a set of different types of vehicles. Different types of vehicles have different abilities. By varying the mix of types in the team the effectiveness of the team's overall searching ability is altered. Teams can have between one and three types of vehicles, and may have between zero and two of each type.

    A GA works on a population of candidate solutions (See the Winston text, Chapter 25). Each member of the population is a team. In each step of the GA activity new teams will be generated from the existing ones by crossover and mutation. Based on evaluations of quality, a fixed number of teams will be selected for survival through to the next generation. The process repeats itself from one generation to another until one or more teams with high performance are generated.

    The specifications of the vehicles available to be team members are as follows:

    Type Distance See Hear
    Sprinter 8 2 8
    Walker 6 5 6
    Crawler 4 6 5
    Sitter 3 8 2

    Distance, See and Hear are attributes of each type of vehicle. The Distance value is how far a vehicle type can travel (in cells) in a unit time period. The See value is how far a vehicle type can see around them. The Hear value is how far a vehicle type can hear around them. These values are used during team evaluation.

    Each team is described by:

    ((Sprinter count-1)
     (Walker   count-2)
     (Crawler  count-3)
     (Sitter   count-4))
    
    Count-1 to count-4 can each be one of {0, 1, 2}. They represent how many of that type of vehicle are in the team. Note that there can not be more than three types on a team, so one of the four counts must be zero for each team.

    So, for example, a sample team might be:

    ((Sprinter 2)
     (Walker   0)
     (Crawler  1)
     (Sitter   0))
    
    representing a team consisting of two Sprinter vehicles and one Crawler vehicle.

    You do not need to use this data structure exactly. For example, (2 0 1 0) would be just fine.

    Your program must use the GA principles described in Chapter 25 of Winston's AI textbook.

    The genetic algorithm performs two types of transformations on teams -- mutation and crossover.

    • A mutation is defined by randomly selecting a vehicle type from a team and changing its count. This produces a new team. Randomly decide which of the four types to change. Change that type by randomly changing its count to another allowable value: e.g., (Sprinter 0) is changed to (Sprinter 2). If the resulting team is legal, the mutation is complete. If not, mutate the original team again until a legal team is found.
    • A crossover involves two teams. It produces two new teams. A crossing point is selected in a random manner and the vehicle counts in the two teams which are beyond this point are interchanged. The crossing point can be between Sprinter & Walker, Walker & Crawler, or Crawler & Sitter. For example, if the crossing point is between Walker & Crawler then the counts for Crawler and Sitter are affected. If the resulting team is legal, the crossover is complete. If not, pick another random crossover point and repeat until a legal team is found, or until all crossover points have been tried for that pair.

    Follow the general process shown in the text on page 524. The program should start with one team. That team (the initial population) is acted on by mutation (and crossover which does nothing) to form a second population. In each additional step you are supposed to generate, by using mutation and also crossover on the current generation, all possible new teams. Discard any duplicate teams that were already generated by this transformation process.

    Note that you apply a mutation transformation to each member of the current population, to produce new teams. You also do crossovers between all possible pairs of the current teams, to produce new teams.

    The initial team in your population is:

    ((Sprinter 0)
     (Walker   0)
     (Crawler  0)
     (Sitter   1))
    

    Evaluation of the quality of a team would normally be done by extensive simulation or by real trials in an actual landscape. In this project we "cheat" (to drastically reduce run time) and "fake" a simulation by evaluating the ability to find the children by taking five pseudo-random placements of the vehicles in a team.

    The 10x10 landscape with the starting position (S), the positions of the children (c1 and c2), and the obstacles (black), are as follows:







    c1










    c2






































































    S








    Every team is assumed to start in the "lower left corner" of the landscape. The children are too frightened to move and will stay in their positions. Vehicles can move in all 8 directions. Teams know roughly where the children are (i.e., the top right quadrant) but not exactly. Consequently, you should bias the "pseudo-random" placement (used below) in some way to make it more realistic. Remember to describe the biasing method in your documentation.

    Seeing & Hearing: Note that seeing is blocked by obstacles, while hearing is not. Vehicles and children are also considered to be obstacles. In order to avoid "line of sight" geometric calculations use the following approximation:

    • IF xd = xc AND yd = yc THEN child found.
    • IF xd = xc THEN move vertically.
    • IF yd = yc THEN move horizontally.
    • IF (xd - xc) approx equal (yd - yc) THEN move diagonally.
    • IF (xd - xc) greater than (yd - yc) THEN move horizontally.
    • IF (xd - xc) less than (yd - yc) THEN move vertically.
    • IF blocked and seeing THEN stop.
    • IF blocked and hearing THEN continue as if the obstacle was not present.

    where (xd, yd) is the destination (a child), and (xc, yc) is the "current" location of the path of viewing or hearing (starting at the location of the vehicle in question). The intent is to "grow" the viewing/hearing path from the vehicle towards the child. The "approx equal" relation tests for equality plus or minus one. The general assumption is that all moves will be heading from the bottom left towards the top right. In any specific situation only one diagonal move is relevant.

    To determine the quality of a team, you must:

    • Do the following process five times
      • Put the team vehicles at the starting point.
      • Assume a unit time period has elapsed and pseudo-randomly place the team members at the distance they can travel. If that puts a vehicle on an obstacle, or another vehicle, randomly re-place the vehicle until that isn't the case. Note that having a vehicle on a child is a good thing in this world, and represents finding the child, not running it over.
      • For every child, if a vehicle can see the child it can add 10 points to its score, and if it can hear the child it can add 6 points to its score. Clearly, if it is sharing a cell with the child it gets 10+6 points.
      • The team score is the sum of the scores of the vehicles in that team.
    • The final team score, its quality, is the average of the five team scores found.

    Only four teams survive into the next generation. In order to select these four you need to use the rank-space method (p. 520) based on quality rank and diversity rank.

    • The quality rank will be based on the quality measure of each team.
    • The diversity rank can be determined once you have defined a distance function between two teams.

    Select the highest quality team to be the first to include in your next generation population. Compute the diversity rank of each team relative to the one selected. Select the next by combined rank. To select the third and fourth teams compute the diversity rank relatively to the teams which already have been selected. You should break rank-sum ties by choosing the team with better diversity.

    In each case calculate the fitness and store it with the teams in the new population. The fitness (probability) usually influences which teams take part in crossovers. But, for this problem, you can try all of them, given that there are only four members in the population. As in the book, use p=0.66. The next fitness value will be 0.66 of the .33 that remains, and so on, for all four selections.

    The algorithm should be made to stop after producing a good team. You need to decide how that is to be determined. In case no such team is produced, the algorithm should stop after a specified number of generations. You can determine that value by experimentation.

    Your program must produce an output file containing, in a condensed form, a record of the the teams selected in each generation with their corresponding quality measure, and quality and diversity ranks. A condensed team representation could be something like:

      2 0 1 0 / 10 / 1 1 /
    where each 4-tuple entry stands for the counts in the team, the next entry is the quality measure, and the last two entries are the ranks.

    Submit

    You must submit:

    • On paper and via turnin:
      • Brief, clear documentation (external to the program) that describes the design of your GA system.
        What special algorithms or data structures were used?
      • A description of how you biased the pseudo-random placement during team evaluation.
      • A description of, and rationale for, your team diversity measure.
      • A description of, and rationale for, your stopping condition.

    • Via turnin only:
      • The code for the system (which must be well commented).
      • The clear, readable output from the test/demonstration runs. These should not be annotated as they should be self-explanatory. Separate the runs from the code.
        -- Given the possibly large amount of output, have the demonstration output turn itself off after 1-2 populations. Normal, necessary output is still needed however, so that every run can be understood.

    How to submit:

    • make sure that your username and name is associated with all items submitted.

    • on paper: in class
    • via turnin: http://web.cs.wpi.edu/~kfisler/turnin.html


    Please note:

    1. Clearly label all printed work with your name and username.
    2. Clearly label each file with a helpful name.
    3. ZIP your entire project directory. Make sure it only contains the files to be submitted. Use "zip" and not some other compression tool.
    4. Name the file as your user name + "-proj3.zip"   For example, "jsbach-proj3.zip"
    5. Submit the zipped project using web turnin.
    6. The project's turnin assignment name is "project3".
    7. While we will do not intend to run your program, we reserve the right to do so.

    Please let us know if you have problems.