Due: Monday 1/29

At class on Monday, please turn in a thorough description of your submarine detection avoidance problem definition.  It can be less than a page and should not be more than two pages.  Your formal description should

• communicate the problem clearly and concisely -  Any other English-speaking person in any part of the world should be able to read your description and be working on exactly  the same problem as you.  As you read your description, think critically and see if you can spot possible misinterpretations and ambiguities.  It's OK (and encouraged) to have another student look over your problem statement to spot possible mistakes, omissions, ambiguities, etc.  Include all relevant constants.  These can be changed at a later point, but it import to specify all constants and parameters of your problem.  In formulating your problem, consider the parts necessary to define a search problem.  In particular, how will you measure cost/utility, and how will you define success?
• provide a scalable benchmark for algorithm development - As better algorithms are developed and as hardware resources improve, it should be easy to adjust the difficulty of your problem so that it remains a relevant benchmark for future research.
• not require simulation that is computationally expensive - Since we're going to be applying search techniques, we'll be doing a lot of simulation.  The speed of simulation with directly affect the speed of search and thus the amount of search that's feasible for assisting navigation in real time.
• provide a problem which is applicable to the general problem - A solution to your problem should be useful in computing a solution to the general given problem.

Due: Monday 2/5

By class on Monday, you will submit documented code that simulates sub and ship trajectories for your problem formulation.  Your search code will rely on this code in order to expand nodes and evaluate the relative merits of possible trajectories.  For this reason, you should also evolve some measure of cost/utility in your simulation.

It's probably a good idea to make a separate class for your state or search node.  Time spent up front with good object-oriented design will pay off in less recoding necessary in later stages.  Even if we're rapid-prototyping, care taken for reusable code can help here too.

Numerical integration: If you're using differential equations to express the evolution of your system, you'll need a way to numerically integrate the equations for simulation.  Happily, I've ported some code for this purpose from the well-known Numerical Methods book "Numerical Recipes in C" by Press et al.  The code can be copied from ~tneller/public_html/cs392/proj1/odeint, and javadoc documentation can be browsed here.  Look at the code in Tests.java for an example of how the classes are used to simulate the motion of a simple pendulum.

Visualization software: It will be helpful to visualize how your simulated system is actually evolving in this part of the work and the following parts.  The current version of the code is here.

Search code example:  The example code for depth-first search with the bucket problem is here.
 

Due: Monday 2/12

By class on Monday, you will be expected to submit (as "hw2") an implementation of iterative-deepending A* which can be used via your visualization interface. This does not mean that your IDA* code must find solutions to difficult problems. You should, however, be able to demonstrate it working for easy problems with a suitably large delta T. (We'll talk of possible improvements next week.)

You should use a Node representation similar to that of the illustrative bucket problem above. In fact, you should be able to have your IDA* code be general enough that it could be used for the Bucket problem with little modification (e.g. the addition of a Node method for evaluating f).

It's probably wise to limit your IDA* in some way (e.g. time, number of node expansions, etc.) When IDA* fails to find a solution under such constraints, it's your decision whether or not to return any trajectory to the animator. If you do, please document the significance of the trajectory returned.

In class on Monday, you should be prepared to give a brief presentation of your IDA* code, describing how well it works for your problem as you vary the difficulty of the problem.