# Introduction to Artificial Intelligence

## Environment simulator and agents for the American traveler problem

In this first exercise you are asked to implement an environment simulator that runs a variant of the Canadian traveller problem (CTP). Then, you will implement some agents that live in the environment and evaluate their performance.

In the Canadian traveller problem, we are given a weighted graph, and the goal is to travel as cheaply as possible from a given start vertex to a given goal vertex. However, unlike standard shortest path in graph problems, which have easy known solutions (e.g. the Dijkstra algorithm), here the problem is that some of the edges (an edge being an abstraction of a road in the real world) may be blocked by snow or ice, this being the Canadian traveller problem.

In the open research problem version of CTP, the agent can only tell which edges are blocked when visiting an incedent vertex. This leads to a problem of shortest path under uncertainty, with which we are not ready to deal yet. Instead, we will introduce a variant, called the American traveller problem, with certain knowledge but also add ways to unblock paths, making this an interesting search problem.

### American TP Environment

The environment consists of a weighted graph. Each edge can be blocked by flood water from a hurricane, (a rather common state of affairs in the USA this last summer), or clear. Some vertices have amphibious vehicles that can be used to traverse a flooded road, and some contain standard vehicles that can be used. Each vertex may contain more than one vehicle. The environment can contain one or more agents, each with a known starting location, and a required goal location. For each agent, there are state variables designating it current location, and the type of vehicle it is in.

An agent can apply 2 types of action: drive (like move in the standard CTP), and switch vehicle. The results of a drive (from a current vertex V to a specific adjacent vertex U) action is as follows. If the edge E to be traversed is clear, the agent (and the vehicle the agent is driving, of course) reaches U. If E is blocked by a flood, and the agent is in an amphibious vehicle, agent traverses E, and again the agent and vehicle reach U. However, if E is blocked but the agent is not in an amphibious vehicle, the action fails, and the agent and vehicle remains at V. The switch action which places the agent in another car in the same vertex, if any is available, and takes some time Tswitch specified by the user.

Each vehicle has the following parameters: speed Vel (a positive integer), and an amphibian effectiveness factor Eff (a number from 0 to 1). Any vehicle with a non-zero Eff is considered amphibious, but its speed in a flooded edge is Vel*Eff, so effectiveness differs. The time to traverse an edge is its weight divided by the effective vehicle speed. We will also assume that a failed action wastes time weight/Vel, so as to discourage the agents from making stupid drive attempts. The simulator should keep track of score, i.e. the number of actions done by each agent, and the total time spent by the agent for traversing edges.

### Implementation part I: simulator + simple agents

Initially you will implement the environment simulator, and several simple (non-AI) agents. The environment simulator should start up by reading the graph from a file, in a format of your choice. We suggest using a simple adgencency list in an ASCII file, that initially specifies the number of vertices. For example (comments beginning with a semicolon):

```#V 4    ; number of vertices n in graph (from 1 to n)

#E 1 2 W1 C   ; Edge from vertex 1 to vertex 2, weight 1, clear
#E 3 4 W1 F   ; Edge from vertex 3 to vertex 4, weight 1, flooded
#E 2 3 W1 F   ; Edge from vertex 2 to vertex 3, weight 1, flooded
#E 1 3 W4 C   ; Edge from vertex 1 to vertex 3, weight 4, clear
#E 2 4 W5 C   ; Edge from vertex 2 to vertex 4, weight 5, clear

#V 1 100 0    ; Non-amphibious vehicle at vertex 1, speed 100
#V 2 80  0.5  ; Amphibious vehicle at vertex 1, speed 80, Eff=0.5 (speed in water 40)
```

The simulator should query the user about the number of agents and what agent program to use for each of them, from a list defined below. Initialization parameters for each agent (initial and goal position) are also to be queried from the user.

After the above initialization, the simulator should run each agent in turn, performing the actions retured by the agents, and update the world accordingly. Additionally, the simulator should be capable of displaying the state of the world after each step, with the appropriate state of the agents and their score. A simple screen display in ASCII is sufficient (no bonuses for fancy graphics - this is not the point in this course!).

Each agent program (a function) works as follows. The agent is called by the simulator, together with a set of observations. The agent returns a move to be carried out in the current world state. The agent is allowed to keep an internal state (for example, a computed optimal path, or anything else desired) if needed. In this assignment, the agents can observe the entire state of the world.

You should implement the following agents:

1. A human agent, i.e. read the next move from the user, and return it to the simulator.
2. A speed nut automaton. This agent will work as follows: select the edge with the highest weight from the current node. Transfer to the vehicle which is fastest for that edge, switch to it if needed, and drive. (If this is an edge that cannot be traversed, or an edge by which the agent has just arrived, select the next best option.) Keep doing this until reaching the same vertex for the 3rd time. Ties are broken in favor of always going for lower-numbered vertices.
3. A greedy agent, that works as follows: the agent should compute the shortest currently unblocked path to its target, switch to the fastest vehicle available, if needed, and traverse the first edge in that direction.

At this stage, you should run the environment with two agents participating in each run: speed nut automaton, and one other agent that can be chosen by the user. Your program should display and record the scores. In particular, you should run the greedy agent with various initial configurations, and various initial locations of the spped nut automaton. Also, test your environment with several agents in the same run, to see that it works correctly. You would be advised to do a good job here w.r.t. program extensibility, modularity, etc. much of this code may be used for some of the following assignments as well.

### Implementation part II: search agents

Now, after chapter 4, you will be implementing intelligent agents (this is part 2 of the assignment) that need to act in this environment. Each agent should assume that it is acting alone, regardless of whether it is true. You will be implementing a "search" agent as defined below. All the algorithms will use a heuristic evaluation function of your choice.

1. A greedy search agent, that picks the move with best immediate heuristic value.
2. An agent using A* search, with the same heuristic.
3. An agent using a simplified version of real-time A*.

The performance measure will be composed of two parts: S, the agent's score, and T, the number of search expansion steps performed by the search algorithm. The performance of an agent will be:

```   P = f * S + T
```

Clearly, a better agent will have P as small as possible. The parameter f is a weight constant. You should compare the performance of the three agents (each acting alone) for the following values of f: 1, 100, 10000. Note that the higher the f parameter, the more important it is to expend computational resources in order to get a better score!

Bonus version: construct a search agent as above, but in addition allow a known speed nut automaton to also acting in the environment. Your search agent needs to take this into account. Observe that although this seems to be a multi-agent problem, the fact that the speed nut is perfectly predictable makes this in essence a single agent search problem.

## Deliverables

The program and code sent to the grader, by e-mail or otherwise as specified by the grader, a printout of the code and results. A document stating the heuristic function you used and the rationale for selecting this function. Set up a time for frontal grading checking of the delivered assignment, in which both members of each team must demonstrate at least some familiarity with their program...

Due date for part 1 (recommended): Thursday, November 17.

For the complete assignment: Thursday, December 1.