Fallible Actions

Fallible actions are a feature in PDDLSIM that problems can use via the :fallible-actions requirement. These allow problems to specify conditions to have actions possibly fail, and not have any effect on the environment. Fallible actions are one of two features in PDDLSIM (the other being Revealables) that are considered "hidden information", i.e., the agent will know they are used, but not in which actual way (by default). Fallible actions are used whenever there is some need to add unpredictability to actions in a way that isn't supported by the used domain.

An example with honey

To illustrate the usage of fallible actions, Let's augment a simple navigation problem with "sticky floors", that sometimes prevent movement. First, let us define our domain:

(define (domain rooms)
        (:requirements :typing :equality :disjunctive-preconditions :negative-preconditions)
        (:types person room)
        (:predicates (at ?p - person ?r - room)
                     (connected ?a ?b - room))
        (:action move
        :parameters (?p - person ?from ?to - room)
        :precondition (and (at ?p ?from)
                           (not (= ?from ?to))
                           (or (connected ?from ?to)
                               (connected ?to ?from)))
        :effect (and (at ?p ?to)
                     (not (at ?p ?from)))))

Now, let's first construct a simple problem for this domain, and then we will show to add fallible actions to it:

(define (problem straight-line)
    (:domain rooms)
    (:objects start-room
              room-1
              room-2
              room-3
              goal-room - room
              bob - person)
    (:init (at bob start-room)
           (connected start-room room-1)
           (connected room-1 room-2)
           (connected room-2 room-3)
           (connected room-3 goal-room))
    (:goal (at bob goal-room)))

Here we have a navigation problem consisting of a chain of interconnected rooms, where the goal of the agent is to reach the chain's other side, i.e., the goal-room. With this problem in mind, let's now make rooms 2 and 3 "sticky":

(define (problem straight-line)
    (:domain rooms)
    (:requirements :fallible-actions)
    (:objects start-room
              room-1
              room-2
              room-3
              goal-room - room
              bob - person)
    (:fails (:action (move ?x ?y ?z) :on 0.5 (at bob room-2))
            (:action (move ?x ?y ?z) :on 0.6 (at bob room-3)))
    (:init (at bob start-room)
           (connected start-room room-1)
           (connected room-1 room-2)
           (connected room-2 room-3)
           (connected room-3 goal-room))
    (:goal (at bob goal-room)))

As one can see from the definitions in the :fails section, whenever bob is in a sticky room, any move action, as the variables specify the value for that parameter in the grounded action doesn't matter, will have some probability to fail (the number specified).

Naturally, instead of variables, we can use actual objects, to constrain the actions that the fallibility applies to. Let's add additional requirements, so that only moves from the sticky room, to the room up ahead, will have the ability to fail:

(define (problem straight-line)
    (:domain rooms)
    (:requirements :fallible-actions)
    (:objects start-room
              room-1
              room-2
              room-3
              goal-room - room
              bob - person)
    (:fails (:action (move ?x ?y room-3) :on 0.5 (at bob room-2))     ; Note the change
            (:action (move ?x ?y goal-room) :on 0.6 (at bob room-3))) ; Note the change
    (:init (at bob start-room)
           (connected start-room room-1)
           (connected room-1 room-2)
           (connected room-2 room-3)
           (connected room-3 goal-room))
    (:goal (at bob goal-room)))

Here, we constrain the ?to parameter of move to the room ahead: For room-2, we constrain to room-3, and for room-3, we constrain to goal-room.

Syntax and semantics

To specify fallible actions, the :fails section is used. Each item in the section represents a separate case for action fallibility, which are written like so:

(:action <GROUNDED-ACTION-SCHEMATIC> :on >PROBABILITY> <CONDITION>)

where <GROUNDED-ACTION-SCHEMATIC> a grounded action (written as the action name, followed by its grounding, enclosed in parentheses), where some parameters may be replaced by variables, and <PROBABILITY> is the failure probability, which, assuming <CONDITION> holds, specifies the probability to actually fail the action.