{'fraction_non_alphanumeric': 0.04440970945200441, 'fraction_numerical': 0.0051489518205222505, 'mean_word_length': 4.262215771649734, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 1, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Using Abstraction for Interpretable Robot Programs in Stochastic Domains

A robot's actions are inherently stochastic, as its sensors are noisy and its actions do not always have the intended effects. For this reason, the agent language Golog has been extended to models with degrees of belief and stochastic actions. While this allows more precise robot models, the resulting programs are much harder to comprehend, because they need to deal with the noise, e.g., by looping until some desired state has been reached with certainty, and because the resulting action traces consist of a large number of actions cluttered with sensor noise. To alleviate these issues, we propose to use abstraction. We define a high-level and nonstochastic model of the robot and then map the high-level model into the lower-level stochastic model. The resulting programs are much easier to understand, often do not require belief operators or loops, and produce much shorter action traces.


Introduction
Classical approaches to model robot behavior such as Golog [7] assume complete knowledge of the word state as well as deterministic actions. However, both assumptions are often violated on real robots: the robot's sensor cannot completely capture the world, thus requiring some way to represent incomplete knowledge, and a robot's sensors and effectors are inherently noisy, necessitating a model of stochastic actions. Consider a simple robot equipped with a sonar sensor that is driving towards a wall (inspired from [1]). The sensor reading is imprecise and may produce incorrect sensor reading. Additionally, when doing a move action, the robot may get stuck with some probability. One approach to model such systems is an extension of the situation calculus [9] with stochastic actions and degrees of belief [1,3]. The core idea is to model the agent's belief with possible worlds, where each world has a certain weight, defining the probability that this world is the actual world. This allows to model degrees of belief, e.g., saying "the robot beliefs to be 2 m away with certainty 0.5". An action may then possibly have several outcomes, each specified with some likelihood.
While there has been progress on reasoning about belief-based programs [8] and programming languages such as Allegro [4] allow to write belief-based programs, including stochastic actions in the model has the disadvantage that the resulting programs become significantly harder to understand. Dealing with noisy actions often requires many actions and loops to reach a desired state with certainty. Additionally, such stochastic programs often have many possible traces, making it more difficult to interpret one particular run of a program.
In this paper, we illustrate how abstraction can be used to deal with these issues. Extending on abstraction of basic action theories (BATs) in the classical situation calculus [2], we propose to use abstractions of stochastic domains, where the resulting abstract BAT does not contain any noisy sensors or effectors and is therefore nonstochastic. The resulting programs are easier to write and understand and the resulting traces are free of stochastic effects, thus making them much easier to comprehend.
The remainder of the paper is structured as follows 3 : In Section 2, we introduce belief-based programs based on the logic DS [3]. We present an example for the robot described above and we show how even simple programs induce traces that are non-trivial to understand. In Section 3, we define a more abstract and nonstochastic model that can be mapped to the lower-level model, resulting in more comprehensible programs. We conclude in Section 4.

Belief-Based Programs with Stochastic Actions
is a modal variant of the situation calculus with degrees of belief and stochastic actions. Similar to ES [6], it is based on a possible worlds semantics, where worlds are part of the semantics and do not occur as terms in the language. In DS, all worlds have a weight, which defines the probability of each world being the true world. The modal operator B(α : r) expresses that α is believed with degree r, e.g., B(Loc(2) : 0.5) expresses that the agent believes "the distance to the wall is 2 m" with degree 0.5. We also write Know(α) for B(α : 1).
DS has two action modalities: [a] and , where [a]α is to be read as "α holds after doing action a" and α is to be read as "α holds after any sequence of actions". As in the situation calculus, a BAT defines a domain by axiomatizing the initial situation, action preconditions, and effects. Additionally, noisy actions are modeled with the action likelihood l, where l(a, u) expresses that the likelihood of action a is u. After doing an action, the agent may not always distinguish which instance of the action has actually been executed. This is expressed with observational indistinguishability (oi) axioms, where oi (a, a ′ ) expresses that the agent cannot distinguish the actions a and a ′ .
We do not present a full account of DS, but rather present an example. We model the robot's movement with the action move(x, y), where x is the intended distance and y is the distance that the robot actually moved, and with a single fluent predicate Loc(x) that describes the position of the robot. A BAT Σ move defining the scenario from above may look as follows: -After doing action a, the robot is at position x if a is a move action that moves the robot to location x, if a is a sonar action that measures distance x, or if a is neither of the two actions and the robot was at location x before 4 : [a]Loc(x) ≡ ∃y, z, (a = move(y, z) ∧ Loc(l) ∧ x = l + z) ∨ a = sonar (x) ∨ ¬∃y, z (a = move(y, z) ∨ a = sonar (y)) ∧ Loc(x) -A move action is possible if the robot moves either one step to the back or to the front. A sonar action is always possible: -Action likelihood axioms: For the sonar action, the likelihood that the robot measures the correct distance is 0.8, the likelihood that it measures a distance with an error of ±1 is 0.1. Furthermore, for the move action, the likelihood that the robot moves the intended distance x is 0.6, the likelihood that the actual movement y is off by ±1 is 0.2: -The robot cannot detect the distance that it has actually moved, i.e., any two actions move(x, y) and move(x, z) are o.i.: oi(a, a ′ ) ≡ ∃x, y, z (a = move(x, y) ∧ a ′ = move(x, z)) ∨ a = a ′ -Initially, the robot is 3 m away from the wall: ∀x(Loc(x) ≡ x = 3) Based on this BAT, we define a program that first moves the robot close to the wall and then back 5 : The robot first measures its distance to the wall and then moves closer until it knows that its distance to the wall is less than 2 m. Afterwards, it moves away until it knows that is more than 5 m away from the wall. As the robot's move action is noisy, each move is followed by sonar to measure how far it is away from the wall. One possible execution trace of this program may look as follows: First, the robot (correctly) senses that it is 3 m away from the wall and starts moving. However, the first move does not have the desired effect: the robot intended to move by 1 m but actually did not move (indicated by the second argument being 0). After the second move, the robot is at Loc (2), as it started at Loc(3) and moved successfully once. However, as its sensor is noisy and it measured sonar (2), it believes that it could also be at Loc (3). For safe measure, it executes another move and then senses sonar (1), after which it knows for sure that it is at a distance ≤ 2 m. In the second part, the robot moves back until it knows that it has reached a distance > 5 m. As this simple example shows, the trace z l is already quite hard to understand. While it is clear from the BAT what each action does, the robot's intent is not immediately obvious and the trace is cluttered with noise and low-level details.

Using Abstraction to Obtain Interpretable Programs
To hide away the low-level details such as noisy move actions, we propose to use abstraction. Similar to [2], abstraction in DS is a mapping of a high-level BAT to a low-level BAT. We first define the high-level BAT and then map each fluent and action to the lower level. Continuing our example, we can define a second, high-level BAT that consists of the locations near and far , the fluent At that specifies the current location of the robot, and the single action goto, which is an idealized move action without noise. The high-level BAT Σ goto looks as follows: -After doing action a, the robot is at location l if a is the action goto(l) or if a is no goto action and the robot has been at l before: [a]At(l) ≡ a = goto(l) ∨ ¬∃x (a = goto(x)) ∧ At(l) -The robot may do action a if a is a goto action to a valid location: -The goto action is not noisy: l(a, u) ≡ ∃x (a = goto(x)) ∧ u = 1.0 ∨ ¬∃x (a = goto(x)) ∧ u = 0.0 -The agent can distinguish all actions: oi (a, a ′ ) ≡ a = a ′ -Initially, the robot is at the location near : ∀l(At(l) ≡ l = near ) Next, we define a refinement mapping that maps each high-level fluent to a low-level formula and each high-level action to a low-level program: -The high-level fluent At(l) is mapped to a low-level formula by translating the distance to the two locations near and far : -The action goto is mapped to a program that guarantees that the robot reaches the right position: Using the refinement mapping, we can translate a high-level program based on the BAT Σ goto to a low-level program based on the BAT Σ move . As Σ goto does not contain any sensing or noisy actions, we obtain a nonstochastic program that is much simpler to understand than the low-level program shown above. The program that first moves close to the wall and then moves back only needs two actions and does not require any belief operators: goto(near ); goto(far ) Note that when the program is executed, each goto action is translated into a corresponding low-level program, as defined by the mapping above. However, from the high-level perspective, the program only allows a single trace z h = goto(near ), goto(far ) . Compared to the low-level trace z l from Equation 1, z h is much easier to understand. It only consists of two actions, which are exactly the two actions from the program. It does not contain any noise, which is the reason why the trace is also unique. Furthermore, we were able to abstract away all sensing actions, further simplifying the resulting traces.

Conclusion
In this paper, we demonstrated how abstraction can be used to map a lowlevel Golog program with stochastic actions to a high-level program that is nonstochastic, does not require any sensing or belief operators, and thus is much easier to understand. While this requires some additional work to define the mapping between the two models, the mapping is not specific for a given program and thus can be re-used for other programs in the same domain.