Blog

Artificial Intelligence and Intelligent Agents Coursework 1 A* Search, Knowledge Representation, and Automated Planning You should complete this coursework individually. Coursework 1 has three parts (A* search, knowledge representation in Prolog, and automated planning using PDDL) and is worth 17.5% of your overall F29AI mark. Details of what you should do and hand in, and how you will be assessed, are described below and on Canvas. Part 1: A* Search problem description The above grids represent two problem environments where an agent is trying to find a path from the start location (S) to the goal location (G). The agent can move to an adjacent square provided the square is white or grey. The agent cannot move to a black square which represents a wall. No diagonal movement is allowed. Moving into a white square has a cost of 1. Moving into a grey square has a cost of 3. What to do: Undergraduate students, 1-year Edinburgh postgraduate students, and all Dubai postgraduate students (full time and part time) Implement a solution to the grid problem using A* search. You have two programming language options for this question: Java or Python. Starter code is provided for you in both languages. Programming language option: Java Starter code can be found in the package uk.ac.hw.macs.search, which is a set of classes that can be used to represent a search problem. To implement a specific search problem, you will need to do the following: 1. Define a class that implements the State interface. This should include the following: a. A method for determining whether a state is a goal state (isGoal()) b. A method for computing the heuristic value of a state (getHeuristic()) 2. Define a class that implements the SearchOrder interface. This interface has one public method, addToFringe, that is used to add a set of nodes to the frontier. You can use the costs and/or heuristic values to determine the order that nodes are added to the frontier The classes in the uk.ac.hw.macs.search.example package show examples of these two interfaces being used to implement depth-first search and breadth-first search, as well as a simple integer-based state. The Main class in this package shows an example of how to use the classes.To solve the problem, you will need to implement the following: 1. An encoding of the state in the grid by implementing the State interface appropriately, including methods for detecting a goal state and computing a heuristic value. You should use the Manhattan distance heuristic for generating heuristic values in your search. 2. A class implementing A* search by implementing the SearchOrder interface and implementing addToFringe appropriately. Programming language option: Java A Python implementation of the Java classes has also been provided as an alternative to using Java: the file hwu_search.py contains Python versions of the classes in uk.ac.hw.macs.search, while the file example.py contains a Python version of the code from uk.ac.hw.macs.search.example. You should consult the Java source files for full documentation of these classes. If you choose to work in Python, you should follow the above two steps, but using the provided Python classes and following the Python example: that is, you should implement an encoding of the state and heuristic in the grid via the State interface, and an implementation of A* using the SearchOrder interface. What to hand in Test your code on the two grid problems provided by running A* search on them and capture the output. Submit the code for the implementation as well as the output. Make sure your code includes appropriate comments in the parts of the code you implemented. Do not change any of the classes in the uk.ac.hw.macs.search package or the hwu_search.py file: we will test your implementation against the provided versions of these classes. What to do: 2-year Edinburgh postgraduate students only Provide a solution to the grid problem by applying A*search by hand. In particular, you should do the following: 1. Draw a graph (with nodes and edges) to represent each of the grid problems as a search problem. Label each of the nodes in your graph and include appropriate costs on the edges. 2. Use the Manhattan distance heuristic and calculate appropriate heuristic values for each of the nodes in your graph. 3. Apply A* search to each grid and list the final set of states expanded and the goal path for each grid. You do not need to provide a full derivation for each search (unless you wish to do so), however, you should provide at least the first 5 steps of each derivation with calculations for the f values to demonstrate you understand the application of the A* algorithm in your graph. What to hand in Submit your answers in a report in PDF format. You do not need to write or submit any code.Part 2: Knowledge Representation problem description A popular fictional monster battling game features a type system that is used to determine the effectiveness of a monster’s ability to attack or defend against another monster. In this coursework you will write a short Prolog program to represent knowledge about this system and to answer queries using the resulting knowledge base. The version of the game we will use includes five monsters: annihilape, espathra, flamigo, lechonk, and mabosstiff. Each monster can be one of five basic types: psychic, fighting, dark, ghost, and normal. Each monster has four moves that it can use. Each move is also assigned one of the basic types. The details of each monster, its type, its moves, and the move types are given in the following table: Monster Monster type Move Move type annihilape ghost lowKick shadowPunch rageFist bodySlam fighting ghost ghost normal espathra psychic psybeam quickAttack lowKick shadowBall psychic normal fighting ghost flamigo fighting lowKick payback megaKick closeCombat fighting dark normal fighting lechonk normal tackle takeDown zenHeadbutt bodySlam normal normal psychic normal mabosstiff dark snarl lick bite bodySlam dark ghost dark normal E.g., annihilape is a ghost type monster with 4 moves: lowKick (a fighting type move), shadowPunch (a ghost type move), rageFist (a ghost type move), and bodySlam (a normal type move). The effectiveness of a monster’s move when used on another monster depends on the move type (of the monster using the move) and the monster type (of the monster the move is being used on). Certain moves are strong against certain types of monsters while other moves are weak or superweak against other monster types. The effectiveness of a move type against a monster type is represented in the following table: move monster psychic fighting dark ghost normal psychic weak strong superweak ordinary ordinary fighting weak ordinary strong superweak strong dark strong weak weak strong ordinary ghost strong ordinary weak strong superweak normal ordinary ordinary ordinary superweak ordinary E.g., a fighting type move is weak against psychic type monsters but a dark type move is strong against ghost type monsters. Combinations that aren’t strong, weak, or superweak are ordinary.What to do Write a Prolog program to represent the knowledge in the monster game according to the following specification: 1. Encode information about the monsters and their moves using Prolog facts of the following form: − basicType(t): to represent the idea that t is a basic type. − monster(mo,t): to represent the idea that mo is a monster of type t. − move(mv,t): to represent the idea that mv is a move of type t. − monsterMove(mo,mv): to represent the idea that monster mo has a move mv. 2. Encode effectiveness information using Prolog facts of the form typeEffectiveness(e,t1,t2): a move of type t1 used again monsters of type t2 has effectiveness e. 3. Encode basic effectiveness relationships using Prolog facts of the form moreEffective(e1,e2): e1 is more effective than e2. You should only encode the strict ordering on effectiveness in this way, i.e., strong is more effective than ordinary, ordinary is more effective than weak, and weak is more effective than superweak. 4. Encode transitive effectiveness information using a Prolog rule of the form moreEffectiveThan(E1,E2): E1 is more effective than E2. The rule should cover the basic effectiveness information above but also information not represented by the facts in part 3, e.g., strong is more effective than weak, ordinary is more effective than superweak, etc. E1 and E2 should be variables in your rule definition. 5. Define a Prolog rule called monsterMoveMatch(T,MO1,MO2,MV) which represents the idea that monster MO1 and monster MO2 both have a move MV which has type T. MO1, MO2, MV, and T should be variables in your rule definition. 6. Define a Prolog rule called moreEffectiveMoveType(MV1,MV2,T) to represent the idea that move MV1 is more effective than move MV2 against monsters of type T. MV1, MV2, and T should be variables in your rule definition. 7. Define a Prolog rule called moreEffectiveMove(MO1,MV1,MO2,MV2) to represent the idea that if monster MO1 performs move MV1 against MO2, and monster MO2 performs move MV2 against MO1, then MV1 is more effective than MV2. MO1, MV1, MO2, and MV2 should be variables in your rule definition. Note that the monsters should actually be capable of performing their respective moves. NOTE: For parts 4-7 of the specification, ensure that you write Prolog rules. You should not implement Prolog facts as your solution for these parts and you will lose marks if you do this. However, it is okay if need to write multiple rules for each definition. If you are interested, the game mechanics in this coursework are based on information from londonessays.com What to hand in • Prolog program file: Submit a single Prolog program file with all your Prolog facts and rules. Ensure that the file is a plain text file with the name monster.pl or monster.pro. Make sure there are comments in your program file to describe the different parts of your program. • Output file: Test your program by selecting a series of Prolog queries to demonstrate the various facts and rules you have implemented. Capture the queries and output to a text file. Include at least 10 queries in your output file. Ensure that the file is a plain text file with the name output.txt.Part 3: Automated Planning problem description Heriot-Watt Underwater has decided to continue its exploration activities in the sea. Mission operations will be controlled by plans generated using an automated planner that will direct the activities of personnel and underwater vehicles. The area of operation is divided into a series of grid-based locations involving land and water. A command centre, which acts as a base of operations, is in one of the water locations near the land. Several types of personnel serve at the command centre, including engineers, scientists, and pilots. The main activities are performed by advanced subs, which can travel underwater and perform various types of exploration and construction tasks. All personnel and subs initially begin at the command centre. Some of the operations of the underwater mission are described in the following list (which isn’t exhaustive): 1. Each location in the area of operation can be either land, shallow water, or deep water. 2. A sub can only move in shallow or deep water and must have a pilot on board in order to move. A sub can only move to an adjacent location from its current location (i.e., it may take multiple moves to reach distant locations). 3. Subs are big enough to carry two people at a time. 4. Subs can carry at most one construction kit at a time: a structure kit or an energy cable kit. Kits can be loaded or unloaded to/from subs by engineers at the command centre. 5. A sub can perform two types of underwater scans. A sub can perform a subsea survey of a location, to make sure the location is safe for construction. A sub can also perform a more intensive research scan of a location, to gather data for further analysis. A scientist must be on board the sub to perform a scan and only one type of scan can be performed at a time. 6. A tidal power generator can be constructed by a sub provided the location has been surveyed and an engineer is on the sub. A tidal power generator can only be built in shallow water in a location adjacent to land. The sub must be carrying a structure kit which is used up by constructing the power generator. 7. An offshore energy cable can be installed by a sub in a water location (deep or shallow) provided the location has been surveyed and an engineer is on the sub. An energy cable can only be installed in a location provided the location is adjacent to a tidal power generator or another energy cable. The sub must also be carrying an energy cable kit, but the kit can be re

used any number of times. 8. An underwater research base can be constructed by two subs operating in the same deep water location. The location must have been surveyed and both subs must have engineers on board. An offshore energy cable must also be in the location before the research base can be built. Each sub must also be carrying a structure kit which is used up by constructing the research base. 9. Some locations of shallow and deep water are marine protected areas. Subs are permitted to travel through marine protected areas, but no construction or installation of offshore energy cables is permitted in a marine protected area. 10. Personnel can move between the command centre and a sub, or an underwater research base and a sub, provided the command centre/research base and sub are in the same location. 11. The results of a research scan can be transferred from a sub into the computer system of an underwater research base if the sub is at the same location as the base. The results of a research scan can be analysed by a scientist at an underwater research base if the results have been transferred to the base computers. 12. A sub has a protective energy shield that can be turn on or off by the pilot. 13. Several locations are home to a kraken. If a sub passes through a location with a kraken without having its energy shield on, then the sub will be destroyed by the kraken. 14. If two underwater research bases are operational then a special sonar array can be turned on by an engineer at one of the bases. The sonar array confuses any kraken, allowing subs to pass through a location with a kraken, even if their energy shield is turned off. 15. All personnel, subs, and kits start at the command centre. The command centre must be situated in a water location adjacent to a land location. There are a finite number of personnel, subs, and kits. No tidal power generators, offshore energy cables, or underwater research bases are initially built/installed. At least one location must contain a kraken and at least one location must be a marine protected area. At the start of operations, the command centre is given a series of missions to complete that involve setting up structures and analysing particular locations in the area of operation.What to do: all students 1. PDDL implementation: You must model the underwater exploration domain in PDDL by defining the properties, objects, and actions that are needed to describe the domain. Note that the planning domain is described at an abstract level and is somewhat incomplete, with certain pieces of information missing. You must make design decisions as to how you will represent the knowledge and actions necessary to encode this scenario as a planning problem. Some requirements are more difficult than others. It is strongly recommended that you try to implement the domain incrementally, ensuring that some parts of the domain work correctly before moving on to others. Use the example domains from the PDDL lectures as a starting point for your solutions. You may also find that the planning time increases as you add more complexity. You may have to consider whether an alternative knowledge representation leads to a better solution. You may use the planning tools available at londonessays.com, the Fast Forward (FF) planner, or the Fast Downward planner. You should ensure that your solution works with one of these planners. Note that the performance of certain planners may outperform that of the web-based planner. Do not use any features of PDDL that we have not covered in the course. Make sure you test your solution on a series of different problem scenarios. Include comments in your PDDL files to describe important sections of your code. You do not need PDDL features that we have not covered in the course. 2. PDDL report: Write a short report (maximum 2 pages) briefly discussing how you structured your domain. Show the different types of locations in your domain and the location of the command centre. Also list in your report the particular problem instances you have included in your code and what planner you have used to test your domain/problems. The report will be used by the markers to help understand your code. What to do: 1-year Edinburgh postgraduate students and all Dubai postgraduate students (full time and part time) In addition to the above instructions for all students, 1-year Edinburgh postgraduate students and all Dubai postgraduate students (full time and part time) should design an additional feature in PDDL to add to the domain (e.g., new personnel that can perform some task, a new activity, etc.) that isn’t included in the above domain description. Add this feature to your domain and test it. Your new features should not simplify or remove any of the existing requirements. Include a description of the additional feature in your report (maximum 1 extra page). What to hand in: all students • PDDL source files: Submit your PDDL source files consisting of a single domain file and at least 4 different problem files. Make sure your source files have comments describing the properties and actions you’ve defined. Your solution should illustrate the different scenarios that are supported by your domain. You should aim for comprehensive scenarios that support multiple missions in each problem file. Your source files will be checked for plagiarism and tested to see if they are operational. For 1-year Edinburgh postgraduate students and all Dubai postgraduate students (full time and part time): one of the problem files must test your additional feature. • PDDL report: Submit your report as a PDF file. Your report will be checked for plagiarism. Declaration of Authorship: Students are also required to sign and include a standard declaration of authorship with each submission. This is a mandatory part of the assessment submission. Links to the standard declaration can be found on the Canvas site for F29AI.Deadlines The deadline for submitting Coursework 1 (all parts) is Thursday, 26 October 2023. Submissions are due by 15:30 (Edinburgh time) for the Edinburgh Campus, 23:59 (Dubai time) for the Dubai Campus, and 17:00 (Malaysia time) for the Malaysia Campus. Details on how to submit your coursework will be posted on Canvas. Feedback Individual written feedback will be provided to students approximately three working weeks after the submission of Coursework 1. Additional notes This is an individual coursework assignment. All submitted files will be checked for plagiarism. You must confirm to the naming conventions described in this document. If files are unreadable or code does not run, you will receive 0 marks on that part of the assessment. You are not permitted to use generative AI tools for any part of this coursework.Assessment This coursework will count towards 17.5% of your overall mark for F29AI and will be marked out of 40 marks. A* Search: Java/Python code (10 marks) Your Java/Python code will primarily be marked on its correctness with respect to the two grid problems. We will also check the implementation of the heuristic in your solution. 0 None 1-2 Poor 3-4 Fair 5-6 Good 7-8 Very good 9-10 Excellent No code submitted. Major problems with code. Solution is incorrect and/or code does not run. Code partially works but there are major problems with code structure, solution, and/or heuristic. Good code and solution. Code runs almost perfectly but there are problems with code structure, solution, or heuristic. Very good code and solution. Code runs perfectly. Small problems with code structure, solution, or heuristic. Exceptional code and solution. Code runs perfectly. Heuristic is well defined. A* Search: Non-coding solution (10 marks) Your solution will primarily be marked on its correctness with respect to the two grid problems. We will also check your graph and heuristic values you are using in your solution. 0 None 1-2 Poor 3-4 Fair 5-6 Good 7-8 Very good 9-10 Excellent No solution submitted. Major problems with solution. Solution is incorrect and/or many parts of the solution are wrong or missing. Major problems with solution. Some parts of the solution partially incorrect or missing. Description of the solution could be improved in many places. Good solution. Solution is mainly correct but there are some minor problems. Description of the solution could be improved. Very good solution. All parts of the solution are described and the solution is correct but there are some small problems with the description that could be improved. Exceptional solution. All parts of the solution are well described and solution is perfect. Knowledge Representation (10 marks) You will be assessed on the correctness of your Prolog program and the output it produces. 0 None 1-2 Poor 3-4 Fair 5-6 Good 7-8 Very good 9-10 Excellent No source code or minimal source code submitted. Weak solution. Many important requirements of the specification or important parts of the output missing. Comments missing. Adequate solution. Some requirements of the specification implemented but important parts missing. Output cases do not provide complete coverage and/or missing many comments. Thorough solution. Majority of program meets specification. Some small problems with the program, missing cases in the output file, and/or missing comments. Very thorough solution. Program almost works perfectly. There might be very small problems with the program, some missing cases in the output file, and/or missing comments. Program works perfectly. Output illustrates all important cases. Comments in code are descriptive.Automated Planning (20 marks) The automated planning mark will primarily be based on the PDDL code you have supplied and how correctly it implements the coursework specification. You should submit a single PDDL domain file and multiple PDDL problem files. The supplied files should provide coverage of the various scenario requirements and demonstrate correct behaviour. The marker will test a selection of the specified PDDL files for plan correctness. You should clearly indicate in your report what planner you have used to test your solution. PDDL files will only be tested on editor.planning.domains, FF, or Fast Downward. Correctness will be assessed not only against the coursework requirements but also with respect to the specific implemented solution. (I.e., non-obvious or incorrect/missing action preconditions or effects may lead to strange plan output and mark deductions.) Usual program quality criteria (e.g., use of whitespace, comments, naming conventions, etc.) will apply here to assess the readability of the code. The marker will be looking to see if you understand how to write PDDL domains and problems and have made good use of the language features that are available. Deductions for poor code quality (up to 5 marks, depending on severity) may be made even if your domain works perfectly. 1-year Edinburgh postgraduate students and all Dubai postgraduate students (full time and part time): Up to 2 marks will be allocated for the correctness of the additional feature. The additional feature should be similar in terms of complexity to the requirements in the main specification (and may be more complex if you’d like), and you are encouraged to be creative in your solutions. Trivial additional features will receive very few marks. 0 None 1-4 Poor 5-8 Fair 9-12 Good 13-16 Very good 17-20 Excellent No source code submitted. Weak solution. Many important requirements or test cases missing and/or not working perfectly. Basic domain features. PDDL code is not understandable Adequate solution. Some requirements implemented but important requirements missing. Test cases do not provide complete coverage. Some test cases may not work perfectly. Mostly basic domain features. PDDL code is very difficult to understand. Thorough solution. Majority of requirements are met. Choice of test cases is convincing. Very few test cases do not work perfectly. A good quality solution overall with a mix of basic and advanced domain features. PDDL code is mainly well written, clear, and understandable. Very thorough solution. All requirements met and choice of test cases provides maximum coverage of requirements. Solution plans are quite convincing. Everything works perfectly. A good mix of domain features, with advanced features enhancing the overall approach. PDDL code is very well written, completely clear and understandable. Exceptional solution. All requirements are easily met and well demonstrated. Test cases are comprehensive and demonstrate robust behaviour. Everything works perfectly. Excellent design designs and use of advanced features which enhance the overall approach. PDDL code is excellent, with all aspects of the code easily understandable.Learning Objectives