Assignment #1-1 - PDDL

Your first task is to model a problem called Grid-Mario in PDDL. The modeled problem is supposed to be a representation of a game Grid-Mario that we want to solve in the means of classical planning. Detailed description of the game's mechanics is given below.

Everyone has to model the world representation including the agent’s movement on the grid with all known obstacles. Additionally, everyone gets a random selection of 2 other features from the problem domain they have to model as well. For every combination of features you get 4 problem instances to model. One for each individual mechanic and then a complex one to test all modeled mechanics at once.

We recommend using online editor for modelling the PDDLs but the choice is yours.

To find your features, check out this table of assigned features.

Download images of the assigned problem instances

• Boxes + keys
• Boxes + springs
• Teleports + keys
• Teleports + springs
• Levers + keys
• Levers + springs

To better understand the image representation of the problem instances, check out legend.

This task is mandatory and you can recieve maximum of 5 points.

Model the domain and 4 given problem instances in PDDL and submit all PDDL files in a .zip file to BRUTE. In total, you should submit one archive with 5 PDDL files.

Filenames

• domain.pddl - modeled domain
• p01.pddl - problem instance that tests movement
• p02.pddl - second problem instance (lever / box / teleport)
• p03.pddl - third problem instance (keys / springs)
• p04.pddl - last given problem instance testing all modeled mechanics

There is no automatic evaluation for this task.

This task will be assigned during the 2. week of tutorials. You have one week to submit it.

Deadline for Monday tutorials: 6.3.2023 - 23:59

Deadline for Wednesday tutorials: 8.3.2023 - 23:59

Map

• Map is represented by a grid
• Size of the map is arbitrary (n x m)

Agent

• Fits exactly one tile
• Can move from one tile to another in 4 directions (up, down, left, right)
• Cannot walk into boxes, walls, holes (he is very careful)
• Can share a tile with levers or items
• The inventory has capacity of one item

Items

• There are two types of items in the game - keys, springs
• They both (surprisingly) fit into agent’s inventory
• Only one item can be carried by the agent
• Items cannot share a tile
• Agent can swap item from their inventory for a different item located on the same tile

Push box

• Agent can push one box at a time
• Agent cannot stand on the box or pull it
• Box has to be pushed in one line (agent → box → clear spot) to a tile that is not hole / wall
• Box can be pushed onto an item / lever but the item cannot be picked up / used as long as the box is on top of the item

Teleport

• Teleport is located on a tile
• In order to use the teleport, agent has to stand on the same tile
• Teleports are linked in fixed pairs and work bidirectionally
• They can be used as many times as needed
• Using the teleport is optional

Levers

• Lever is located on a grid tile, it can share a tile with the agent
• Once lever is pulled it fills in a designated hole that turns into regular tile
• One lever is linked to a one hole
• Lever cannot be un-pulled and pulling it again doesn’t have any effects

Keys

• Keys are items that can be placed on a tile together with an agent
• Key can be picked up, put down and used to unlock doors that block paths between tiles
• To unlock a door, the agent has to stand next to the door
• Every key is universal (fits to any door) but once used it disappears
• Doors are located between tiles (not placed on tiles), path between tiles gets restored once the door is open
• Door cannot be locked or closed again

Springs

• Spring is an item that allows the agent to jump over holes and walls of width equal to one tile
• Spring can be picked up, carried by agent and put down
• Once spring is down agent can use it to jump over one hole/wall in front of them
• The jump is performed in straight line (agent + spring → hole/wall → clear spot)

• Grid can be modelled both using coordinates or tiles as objects
• Go one action at a time and always debug on the smallest possible problem instances
• All predicates not stated in the initial state definition will be set to false automatically (if you put (at agent t1) to init, every other (at agent ?t) will be not true)
• All types without a parent will have ‘object’ type as their parent
• The editor can smell fear
• You can save your session + get its ID so it can be restored in the online editor

• incorrect pairing of parentheses
• typos in types, predicates, arguments
• missing predicate from a long list of repeating ones (tile x1 y1, tile x2 y2, …)
• domain name doesn’t match in problem and domain definitions
• some features of the world are not defined in :init (grid connections, clear tiles, item positions, …)

For the purpose of this homework, please use only PDDL requirements provided in the template, no extra ones are necessary to model grid-Mario. Using types is optional (predicates can be used instead). Please use only conjunctions of predicates for defining actions.

For simpler writing here are templates for both domain definition (also provided in the online editor ) and problem definition.

Domain definition in PDDL

(define (domain domainName)

    (:requirements
        :negative-preconditions
        :typing
    )

    (:types

    )

    (:predicates
    
    )

    (:action actionName
        :parameters (?x - foo)
        :precondition (and 
		(foo) 
		(fuu)
	)
        :effect (and 
		(fii)
		(not (fee))
	)
    )
)

Problem definition in PDDL

(define (problem problemName) (:domain domainName)

(:objects
    x - type
)

(:init
    (fee)
)   

(:goal
    (and
        (foo)
    )
)
)