:BAD-SENTENCE

:INFEASIBLE-COMMAND

:OK

The World:

• the objects in the world will be the truck, road signs, fuel drum dispensers, recyclers, glasses, rocks, fuel drums, and garbage
• recyclers can recycle any object except for fuel drum dispensers, road signs, the truck, and recyclers (interesting though that concept might be)
• rocks, glasses, fuel drums, and garbage all have a color property, which will be one of red, orange, yellow, green, blue, purple
• glasses also have a STATUS property which is either BROKEN or UNBROKEN
• fuel drums also have a LEVEL property which is either FULL or EMPTY
• a full fuel drum will fill the fuel tank completely
• each trip takes a full tank of gas
• each cargo bay can hold at most two objects (positions 0 and 1)
• each arm can hold at most one object at a time (position 0)
• each external location can hold at most 16 objects at a time (positions 0 to 15)

1. The command START initializes the Truckworld
2. The command STOP terminates the Truckworld

[USE arm-specifier TO] PICK UP object

PICK UP object [USING arm-specifier]

where object is a phrase that uniquely identifies an object. At most one arm specifier is allowable. You should define GRASP as a synonym for PICK UP. To be feasible, the object description must refer to exactly one object (subject to an arbitrary choice, as in "A RED GLASS"). That object must be somewhere that can be reached from the truck's current location, the arm (if specified) must not be holding anything, and the object must be graspable. You must also support the IT pronoun (see discussion below), so the following sentences are also syntactically valid, for example:

PICK IT UP USING ARM 1

GRASP IT

In most cases, the word IT can refer to an object. It means "the object that was manipulated in the last command." For example, "it" might be the last object picked up, or put down, or the fuel drum used for refueling. If the last command was a travel command, the IT pronoun becomes undefined. Note that in PICK UP and PUT DOWN, the IT pronoun changes the syntax of the sentence (IT goes before UP or DOWN).

PUT DOWN object [position-specifier] [IN container]

where container could refer to a cargo bay or to a recycler and position-specifier identifies a position in that container. This could be "AT position", or "NEXT TO object". DROP should be synonymous with PUT DOWN. As before, the object may come before or after the DOWN. Omitting the container means put the object down outside at the current location. Omitting the position means put down the object at any empty position in the container. Preconditions for this action include: object can be resolved to a single object, if the position-specifier is included, the container cannot be a recycler, the position must be empty, the container must be a valid container, the object must be held by one of the arms.

Again, the IT pronoun is available, so the following sentences are syntactically valid:

PUT IT DOWN

PUT IT DOWN NEXT TO THE RECYCLER

There are two forms of the REFUEL command:

REFUEL USING [arm-specifier AND] object

USE [arm-specifier AND] object TO REFUEL

where in either case the object described must describe a full fuel drum. The only precondition for this command is that the arm chosen must not currently be holding anything, unless that object is the fuel drum in question. As always, the IT pronoun is on hand:

USE IT TO REFUEL

TRAVEL TO location-name

GO direction

In the first case, the location-name must be directly accessible to the truck's current location. In the second case, there must be a road going in the specified direction.

The following commands are part of the "truckworld execution" subsystem defined in the file
truckworld-execution.lsp

1. You can propose any extension to the language you want for extra credit. Just check with us first.
2. The current interaction with the command processor is quite primitive: if something goes wrong, it simply returns an error symbol. Enhance this capability by making the command processor explain why it couldn't execute a command (i.e. which precondition(s) were violated).
3. A common form of execution error is that an object description does not uniquely identify an object. For example, (PICK UP THE RED GLASS) might be ambiguous because there are two red glasses. The command processor should print a message to that effect, prompt for information from the user that would determine which one, and proceed with execution.
4. It is fairly easy to extend the language to accept compound commands like:
   (PICK UP THE RED GLASS AND RECYCLE IT)
   (PICK UP A GLASS THEN GO TO THE WAREHOUSE)
5. Another minor cosmetic improvement would be to change the interface so it accepts punctuated character strings as input:
   "Pick up a glass, then go to the warehouse."
   Define an alternative version of execute-command that accepts a string, parses, and executes it.
6. It turns out that in this version of the world, if you SET a glass, the glass will break. Extend the command syntax to allow glasses to be broken. It should be flagged as an error (infeasible) to set any object other than a glass or a fuel-drum dispenser, and if the user tries to SET a glass that is already broken, you should generate an appropriate warning message.
7. Extend the functionality so the command processor has to "think" about how to execute a command. For example, (TAKE ALL THE GLASSES TO THE DEPOT) might require several actions, and in fact could be looked at as a problem-solving task. So you could take the command, translate it into a symbolic goal like (FORALL (GLASS ?G) (AT ?G DEPOT)), call UCPOP or Graphplan which would produce solution actions, then execute the resulting plan. (Warning! This one is very difficult and very open ended, so it is not for the faint of heart!)